1. 19 4月, 2012 7 次提交
    • P
      ARM: OMAP2+: hwmod: provide a function to return the address space of the MPU RT · c9aafd23
      Paul Walmsley 提交于
      A subsequent patch will need to know the struct omap_hwmod_addr_space
      record corresponding to the module's register target, used by the MPU.
      So, convert _find_mpu_rt_base() into _find_mpu_rt_addr_space().  Then
      modify its sole current user, _populate_mpu_rt_base(), to extract the
      MPU RT base address itself from the struct omap_hwmod_addr_space record.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      c9aafd23
    • P
      ARM: OMAP2+: hwmod: revise hardreset behavior · 747834ab
      Paul Walmsley 提交于
      Change the way that hardreset lines are handled by the hwmod code.
      Hardreset lines are generally associated with initiator IP blocks.
      Prior to this change, the hwmod code expected to control hardreset
      lines itself, asserting them on shutdown and deasserting them upon
      enable.  But driver authors inside TI have commented to us that their
      drivers require direct control over these lines.  Unfortunately, these
      drivers haven't been posted publicly yet, so it's hard to determine
      exactly what is needed, a priori.  This change attempts to set forth
      some reasonable semantics that should be an improvement over the
      current code.
      
      The semantics implemented by this patch are as follows:
      
      - If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
        associated hardreset lines during IP block setup.  This is intended
        to place the IP blocks into a known state that will not interfere
        with other devices during kernel boot.
      
      - IP blocks with hardreset lines will not be automatically enabled or
        idled during setup.  Instead, they will be left in the INITIALIZED
        state.
      
      - When the hwmod code is asked to enable, idle, or shutdown an IP
        block with asserted hardreset lines, the hwmod code will do nothing.
        The driver integration code must do the remaining work needed to
        control these IP blocks.  Once this driver integration code is posted
        to the lists, hopefully we can consolidate it and move it inside the
        hwmod code.
      
      Custom reset functions for IP blocks with hardreset lines still should
      be supported and are strongly endorsed.  It is intended that every
      subsystem with hardreset lines should have a custom reset function
      that can place their subsystem into quiescent idle with the hardreset
      lines deasserted.
      
      This reverts most of commit 5365efbe
      ("OMAP: hwmod: Add hardreset management support").  Later code
      reorganizations caused the sequencing of the code from this patch to
      be changed, anyway.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      747834ab
    • P
      ARM: OMAP2+: hwmod: reorganize and document the reset and configuration process · 64813c3f
      Paul Walmsley 提交于
      Reorganize the code involved in resetting and configuring an IP block
      to make it easier to read and maintain.  This involves improving
      documentation, splitting some large functions up into smaller ones to
      better conform with Documentation/CodingStyle, and removing some
      unnecessary code.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      64813c3f
    • P
      ARM: OMAP2+: hwmod: reorganize and document the initialization process · 381d033a
      Paul Walmsley 提交于
      Reorganize the code involved in initializing the internal data for
      each hwmod to make it easier to read and maintain.  This involves
      improving documentation and removing some duplicated and unnecessary
      code.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      381d033a
    • P
      ARM: OMAP2+: hwmod: revise the IP block reset process · 30e105c0
      Paul Walmsley 提交于
      Revise the IP block reset process.  This patch ensures that the
      OCP_SYSCONFIG registers are reloaded after a custom reset.  Since
      OCP_SYSCONFIG bits are cleared during reset, they should be
      reprogrammed unless the IP block is being left in reset.  (The only IP
      blocks that are left in reset are IP blocks with hardreset lines and
      no custom reset function.)  If the IP block is left in reset, then it
      is inaccessible to the MPU, and an access to the OCP_SYSCONFIG
      register will cause an abort.
      
      This version incorporates comments from Omar Ramirez Luna
      <omar.ramirez@ti.com> to skip the OCP_SYSCONFIG access after asserting
      hardreset lines.  This allows the MMU (IOMMU) IP block, which has
      both hardreset lines and an OCP_SYSCONFIG register.
      
      Also, ignore _ocp_softreset() errors if the IP block doesn't include a
      softreset bit.  This is needed since a subsequent patch will start
      taking the return value of the _reset() function seriously.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      30e105c0
    • 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
    • P
      ARM: OMAP2+: hwmod: control all hardreset lines attached to a hwmod · 9c8b0ec7
      Paul Walmsley 提交于
      Parts of the hwmod code test to see if a module has one and only one
      hardreset line before taking an action.  It seems more appropriate
      to control all hardreset lines associated with a hwmod, not just one.
      
      It so happens that with the current hwmod data, this patch will not
      change any behavior, since hwmods with hardreset lines have only one
      hardreset line associated with them, and 'pseudo-hwmods' are used to
      handle the other hardreset lines.  But future hwmod data patches to
      remove the pseudo-hwmods will change this.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      9c8b0ec7
  2. 13 4月, 2012 3 次提交
    • A
      ARM: OMAP2/3: VENC hwmods: Remove OCPIF_SWSUP_IDLE flag from VENC slave interface · 1f5e6247
      Archit Taneja 提交于
      The clocks for all DSS slave interfaces were recently changed to "dss_ick" on
      OMAP2 and OMAP3, this clock can be autoidled by PRCM. The VENC interface
      previously had "dss_54m_fck" as it's clock which couldn't be autoidled, and
      hence the OCPIF_SWSUP_IDLE flag was needed.
      
      Remove the OCPIF_SWSUP_IDLE flag from VENC interfaces as it's clock is
      now "dss_ick".  This allows the PRCM hardware to autoidle the VENC
      interface clocks when they are not active, rather than relying on the
      software to do it, which can keep the interface clocks active
      unnecessarily.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      [paul@pwsan.com: add a short description of the fix to the commit log]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      1f5e6247
    • P
      ARM: OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status" · 3c55c1ba
      Paul Walmsley 提交于
      This reverts commit f9a2f9c3.  This
      commit caused a regression in the I2C hwmod reset on OMAP2/3/4,
      logging messages similar to these during boot:
      
      [    0.200378] omap_hwmod: i2c1: softreset failed (waited 10000 usec)
      [    0.222076] omap_hwmod: i2c2: softreset failed (waited 10000 usec)
      
      While the original patch was intended to fix some reset-related timing
      issues, it's believed that these problems were actually fixed by
      commit 2800852a ("ARM: OMAP2+: hwmod:
      Restore sysc after a reset"):
      
          http://marc.info/?l=linux-arm-kernel&m=133410322617245&w=2
      
      Cc: Rajendra Nayak <rnayak@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      3c55c1ba
    • 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
  3. 07 4月, 2012 3 次提交
    • L
      Make the "word-at-a-time" helper functions more commonly usable · f68e556e
      Linus Torvalds 提交于
      I have a new optimized x86 "strncpy_from_user()" that will use these
      same helper functions for all the same reasons the name lookup code uses
      them.  This is preparation for that.
      
      This moves them into an architecture-specific header file.  It's
      architecture-specific for two reasons:
      
       - some of the functions are likely to want architecture-specific
         implementations.  Even if the current code happens to be "generic" in
         the sense that it should work on any little-endian machine, it's
         likely that the "multiply by a big constant and shift" implementation
         is less than optimal for an architecture that has a guaranteed fast
         bit count instruction, for example.
      
       - I expect that if architectures like sparc want to start playing
         around with this, we'll need to abstract out a few more details (in
         particular the actual unaligned accesses).  So we're likely to have
         more architecture-specific stuff if non-x86 architectures start using
         this.
      
         (and if it turns out that non-x86 architectures don't start using
         this, then having it in an architecture-specific header is still the
         right thing to do, of course)
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f68e556e
    • S
      xen/smp: Remove unnecessary call to smp_processor_id() · e8c9e788
      Srivatsa S. Bhat 提交于
      There is an extra and unnecessary call to smp_processor_id()
      in cpu_bringup(). Remove it.
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      e8c9e788
    • K
      xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries' · 2531d64b
      Konrad Rzeszutek Wilk 提交于
      The above mentioned patch checks the IOAPIC and if it contains
      -1, then it unmaps said IOAPIC. But under Xen we get this:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
      IP: [<ffffffff8134e51f>] xen_irq_init+0x1f/0xb0
      PGD 0
      Oops: 0002 [#1] SMP
      CPU 0
      Modules linked in:
      
      Pid: 1, comm: swapper/0 Not tainted 3.2.10-3.fc16.x86_64 #1 Dell Inc. Inspiron
      1525                  /0U990C
      RIP: e030:[<ffffffff8134e51f>]  [<ffffffff8134e51f>] xen_irq_init+0x1f/0xb0
      RSP: e02b: ffff8800d42cbb70  EFLAGS: 00010202
      RAX: 0000000000000000 RBX: 00000000ffffffef RCX: 0000000000000001
      RDX: 0000000000000040 RSI: 00000000ffffffef RDI: 0000000000000001
      RBP: ffff8800d42cbb80 R08: ffff8800d6400000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 00000000ffffffef
      R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000010
      FS:  0000000000000000(0000) GS:ffff8800df5fe000(0000) knlGS:0000000000000000
      CS:  e033 DS: 0000 ES: 0000 CR0:000000008005003b
      CR2: 0000000000000040 CR3: 0000000001a05000 CR4: 0000000000002660
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper/0 (pid: 1, threadinfo ffff8800d42ca000, task ffff8800d42d0000)
      Stack:
       00000000ffffffef 0000000000000010 ffff8800d42cbbe0 ffffffff8134f157
       ffffffff8100a9b2 ffffffff8182ffd1 00000000000000a0 00000000829e7384
       0000000000000002 0000000000000010 00000000ffffffff 0000000000000000
      Call Trace:
       [<ffffffff8134f157>] xen_bind_pirq_gsi_to_irq+0x87/0x230
       [<ffffffff8100a9b2>] ? check_events+0x12+0x20
       [<ffffffff814bab42>] xen_register_pirq+0x82/0xe0
       [<ffffffff814bac1a>] xen_register_gsi.part.2+0x4a/0xd0
       [<ffffffff814bacc0>] acpi_register_gsi_xen+0x20/0x30
       [<ffffffff8103036f>] acpi_register_gsi+0xf/0x20
       [<ffffffff8131abdb>] acpi_pci_irq_enable+0x12e/0x202
       [<ffffffff814bc849>] pcibios_enable_device+0x39/0x40
       [<ffffffff812dc7ab>] do_pci_enable_device+0x4b/0x70
       [<ffffffff812dc878>] __pci_enable_device_flags+0xa8/0xf0
       [<ffffffff812dc8d3>] pci_enable_device+0x13/0x20
      
      The reason we are dying is b/c the call acpi_get_override_irq() is used,
      which returns the polarity and trigger for the IRQs. That function calls
      mp_find_ioapics to get the 'struct ioapic' structure - which along with the
      mp_irq[x] is used to figure out the default values and the polarity/trigger
      overrides. Since the mp_find_ioapics now returns -1 [b/c the IOAPIC is filled
      with 0xffffffff], the acpi_get_override_irq() stops trying to lookup in the
      mp_irq[x] the proper INT_SRV_OVR and we can't install the SCI interrupt.
      
      The proper fix for this is going in v3.5 and adds an x86_io_apic_ops
      struct so that platforms can override it. But for v3.4 lets carry this
      work-around. This patch does that by providing a slightly different variant
      of the fake IOAPIC entries.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      2531d64b
  4. 06 4月, 2012 10 次提交
  5. 05 4月, 2012 17 次提交