1. 09 Feb, 2012 1 commit
  2. 04 Feb, 2012 2 commits
  3. 03 Feb, 2012 3 commits
  4. 02 Feb, 2012 6 commits
    • Catalin Marinas's avatar
      ARM: 7302/1: Add TLB flushing for both entries in a PMD · 6d3ec1ae
      Catalin Marinas authored
      
      
      Linux uses two PMD entries for a PTE with the classic page table format,
      covering 2MB range. However, the __pte_free_tlb() function only adds a
      single TLB flush corresponding to 1MB range covering 'addr'. On
      Cortex-A15, level 1 entries can be cached by the TLB independently of
      the level 2 entries and without additional flushing a PMD entry would be
      left pointing at the wrong PTE. The patch limits the TLB flushing range
      to two 4KB pages around the 1MB boundary within PMD.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      6d3ec1ae
    • Will Deacon's avatar
      ARM: 7303/1: perf: add empty NODE event definitions for Cortex-A5 and Cortex-A15 · 91756acb
      Will Deacon authored
      Commit 89d6c0b5
      
       ("perf, arch: Add generic NODE cache events") added
      empty NODE event definitions for the ARM PMU implementations. This was
      merged along with Cortex-A5 and Cortex-A15 PMU support, so they missed
      out on the original patch.
      
      This patch adds the empty definitions to Cortex-A5 and Cortex-A15.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      91756acb
    • Will Deacon's avatar
      ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers · 8130b9d7
      Will Deacon authored
      
      
      If we are context switched whilst copying into a thread's
      vfp_hard_struct then the partial copy may be corrupted by the VFP
      context switching code (see "ARM: vfp: flush thread hwstate before
      restoring context from sigframe").
      
      This patch updates the ptrace VFP set code so that the thread state is
      flushed before the copy, therefore disabling VFP and preventing
      corruption from occurring.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      8130b9d7
    • Dave Martin's avatar
      ARM: 7307/1: vfp: fix ptrace regset modification race · 247f4993
      Dave Martin authored
      
      
      In a preemptible kernel, vfp_set() can be preempted, causing the
      hardware VFP context to be switched while the thread vfp state is
      being read and modified.  This leads to a race condition which can
      cause the thread vfp state to become corrupted if lazy VFP context
      save occurs due to preemption in between the time thread->vfpstate
      is read and the time the modified state is written back.
      
      This may occur if preemption occurs during the execution of a
      ptrace() call which modifies the VFP register state of a thread.
      Such instances should be very rare in most realistic scenarios --
      none has been reported, so far as I am aware.  Only uniprocessor
      systems should be affected, since VFP context save is not currently
      lazy in SMP kernels.
      
      The problem was introduced by my earlier patch migrating to use
      regsets to implement ptrace.
      
      This patch does a vfp_sync_hwstate() before reading
      thread->vfpstate, to make sure that the thread's VFP state is not
      live in the hardware registers while the registers are modified.
      
      Thanks to Will Deacon for spotting this.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarDave Martin <dave.martin@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      247f4993
    • Will Deacon's avatar
      ARM: 7306/1: vfp: flush thread hwstate before restoring context from sigframe · 2af276df
      Will Deacon authored
      
      
      Following execution of a signal handler, we currently restore the VFP
      context from the ucontext in the signal frame. This involves copying
      from the user stack into the current thread's vfp_hard_struct and then
      flushing the new data out to the hardware registers.
      
      This is problematic when using a preemptible kernel because we could be
      context switched whilst updating the vfp_hard_struct. If the current
      thread has made use of VFP since the last context switch, the VFP
      notifier will copy from the hardware registers into the vfp_hard_struct,
      overwriting any data that had been partially copied by the signal code.
      
      Disabling preemption across copy_from_user calls is a terrible idea, so
      instead we move the VFP thread flush *before* we update the
      vfp_hard_struct. Since the flushing is performed lazily, this has the
      effect of disabling VFP and clearing the CPU's VFP state pointer,
      therefore preventing the thread from being updated with stale data on
      the next context switch.
      
      Cc: stable <stable@vger.kernel.org>
      Tested-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      2af276df
    • Russell King's avatar
      Revert "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping" · 97f10409
      Russell King authored
      This reverts commit 3c424f35.
      
      Joachim Eastwood reports:
      | "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping"
      | Commit: 3c424f35
      
       in Linus master
      |
      | Breaks booting on my custom AT91RM9200 board.
      | There isn't any error messages or anything that indicates what goes
      | wrong it just stops after; Uncompressing Linux... done, booting the
      | kernel.
      |
      | Reverting it makes my board boot again.
      
      and further debugging reveals:
      
      ioremap: pfn=fffff phys=fffff000 offset=400 size=1000
      ioremap: area c3ffdfc0: phys_addr=200000 pfn=200 size=4000
      ioremap: found: addr fef74000 => fed73000 => fed73400
      
      Clearly, an area for pfn 0x200, 16K can't ever satisfy a request for pfn
      0xfffff.  This happens because the changed if statement becomes:
      
                      if (0x00200 > 0xfffff ||
                          0xfffff000 + 0x400 + 0x1000-1 > 0x00200000 + 0x4000-1)
      and therefore:
                      if (0x00200 > 0xfffff ||
                          0x000003ff > 0x00203fff)
      
      The if condition fails, and so we _believe_ that the SRAM mapping fits
      our request.  Clearly that's totally bogus.
      
      Moreover, the original premise of the 'fix' patch was wrong:
      |    The condition checking boundaries of the requested and existing
      |    mappings didn't take in-page offset into consideration though,
      |    which lead to obscure and hard to debug problems when requested
      |    mapping crossed end of the static one.
      
      as the code immediately above this loop does:
      
              size = PAGE_ALIGN(offset + size);
      
      so 'size' already contains the requested offset into the page.
      
      So, revert the broken 'fix'.
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      97f10409
  5. 01 Feb, 2012 5 commits
  6. 31 Jan, 2012 3 commits
  7. 30 Jan, 2012 2 commits
    • Michael D Labriola's avatar
      x86/reboot: Remove VersaLogic Menlow reboot quirk · e6d36a65
      Michael D Labriola authored
      This commit removes the reboot quirk originally added by commit
      e19e074b ("x86: Fix reboot problem on VersaLogic Menlow boards").
      
      Testing with a VersaLogic Ocelot (VL-EPMs-21a rev 1.00 w/ BIOS
      6.5.102) revealed the following regarding the reboot hang
      problem:
      
      - v2.6.37 reboot=bios was needed.
      
      - v2.6.38-rc1: behavior changed, reboot=acpi is needed,
        reboot=kbd and reboot=bios results in system hang.
      
      - v2.6.38: VersaLogic patch (e19e074b "x86: Fix reboot problem on
        VersaLogic Menlow boards") was applied prior to v2.6.38-rc7.  This
        patch sets a quirk for VersaLogic Menlow boards that forces the use
        of reboot=bios, which doesn't work anymore.
      
      - v3.2: It seems that commit 660e34ce
      
       ("x86: Reorder reboot method
        preferences") changed the default reboot method to acpi prior to
        v3.0-rc1, which means the default behavior is appropriate for the
        Ocelot.  No VersaLogic quirk is required.
      
      The Ocelot board used for testing can successfully reboot w/out
      having to pass any reboot= arguments for all 3 current versions
      of the BIOS.
      Signed-off-by: default avatarMichael D Labriola <michael.d.labriola@gmail.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Michael D Labriola <mlabriol@gdeb.com>
      Cc: Kushal Koolwal <kushalkoolwal@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/87vcnub9hu.fsf@gmail.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e6d36a65
    • Michael D Labriola's avatar
      x86/reboot: Skip DMI checks if reboot set by user · 5955633e
      Michael D Labriola authored
      
      
      Skip DMI checks for vendor specific reboot quirks if the user
      passed in a reboot= arg on the command line - we should never
      override user choices.
      Signed-off-by: default avatarMichael D Labriola <michael.d.labriola@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Michael D Labriola <mlabriol@gdeb.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/87wr8ab9od.fsf@gmail.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5955633e
  8. 28 Jan, 2012 1 commit
  9. 27 Jan, 2012 2 commits
  10. 26 Jan, 2012 15 commits
    • Julia Lawall's avatar
      ARM: OMAP2+: arch/arm/mach-omap2/smartreflex.c: add missing iounmap · 14ea9601
      Julia Lawall authored
      Add missing iounmap in error handling code, in a case where the function
      already preforms iounmap on some other execution path.
      
      A simplified version of the semantic match that finds this problem is as
      follows: (http://coccinelle.lip6.fr/
      
      )
      
      // <smpl>
      @@
      expression e;
      statement S,S1;
      int ret;
      @@
      e = \(ioremap\|ioremap_nocache\)(...)
      ... when != iounmap(e)
      if (<+...e...+>) S
      ... when any
          when != iounmap(e)
      *if (...)
         { ... when != iounmap(e)
           return ...; }
      ... when any
      iounmap(e);
      // </smpl>
      Signed-off-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      14ea9601
    • Julia Lawall's avatar
      ARM: OMAP2+: arch/arm/mach-omap2/devices.c: introduce missing kfree · e0feca89
      Julia Lawall authored
      pdata needs to be freed before leaving the function in an error case.
      
      A simplified version of the semantic match that finds the problem is as
      follows: (http://coccinelle.lip6.fr
      
      )
      
      // <smpl>
      @r exists@
      local idexpression x;
      statement S;
      identifier f1;
      position p1,p2;
      expression *ptr != NULL;
      @@
      
      x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
      ...
      if (x == NULL) S
      <... when != x
           when != if (...) { <+...x...+> }
      x->f1
      ...>
      (
       return \(0\|<+...x...+>\|ptr\);
      |
       return@p2 ...;
      )
      
      @script:python@
      p1 << r.p1;
      p2 << r.p2;
      @@
      
      print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
      // </smpl>
      Signed-off-by: default avatarJulia Lawall <julia@diku.dk>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      e0feca89
    • Grazvydas Ignotas's avatar
      ARM: OMAP: fix MMC2 loopback clock handling · d82e5190
      Grazvydas Ignotas authored
      
      
      Currently MMC2 setup code can only enable loopback clock and
      relies on reset value for boards that need to have it disabled.
      This causes a problem with certain bootloaders that always enable
      that clock, resulting with unwanted bootloader dependencies.
      
      Fix this by making it disable the clock if board data says so.
      Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Acked-by: default avatarIgor Grinberg <grinberg@compulab.co.il>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      d82e5190
    • Grazvydas Ignotas's avatar
      ARM: OMAP: fix erroneous mmc2 clock change on mmc3 setup · ffa1e4ed
      Grazvydas Ignotas authored
      
      
      hsmmc23_before_set_reg() can set MMCSDIO2ADPCLKISEL bit, which
      enables internal clock for MMC2. Currently this function is also called
      by code handling MMC3, and if .internal_clock is set in platform data
      (by default it currently is), it will set MMCSDIO2ADPCLKISEL for MMC2
      instead of MMC3 (MMC3 doesn't have such bit so nothing actually needs to
      be done). This breaks 2nd SD slot on pandora.
      
      Fix this by changing hsmmc23_before_set_reg() to only handle MMC2.
      Note that this removes .remux() call for MMC3, but no board currently
      needs it and it's also not called for MMC4 and MMC5.
      Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      ffa1e4ed
    • Yegor Yefremov's avatar
      ARM: OMAP2+: GPMC: fix device size setup · 8ef5d844
      Yegor Yefremov authored
      
      
      following statement can only change device size from 8-bit(0) to 16-bit(1),
      but not vice versa:
      
      regval |= GPMC_CONFIG1_DEVICESIZE(wval);
      
      so as this field has 1 reserved bit, that could be used in future,
      just clear both bits and then OR with the desired value
      Signed-off-by: default avatarYegor Yefremov <yegorslists@googlemail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      8ef5d844
    • Vaibhav Hiremath's avatar
      ARM: OMAP2+: timer: Fix crash due to wrong arg to __omap_dm_timer_read_counter · dbc3982a
      Vaibhav Hiremath authored
      Commit 2f0778af
      
       (ARM: 7205/2: sched_clock: allow sched_clock to be
      selected at runtime) had a typo for the case when CONFIG_OMAP_32K_TIMER
      is not set.
      
      In dmtimer_read_sched_clock(), wrong argument was getting passed to
      __omap_dm_timer_read_counter() function call; instead of "&clksrc",
      we were passing "clksrc.io_base", which results into kernel crash.
      
      To reproduce kernel crash, just disable the CONFIG_OMAP_32K_TIMER config
      option (and DEBUG_LL) and build/boot the kernel.
      This will use dmtimer as a kernel clocksource and lead to kernel
      crash during boot  -
      
      [    0.000000] OMAP clocksource: GPTIMER2 at 26000000 Hz
      [    0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every
      165191ms
      [    0.000000] Unable to handle kernel paging request at virtual address
      00030ef1
      [    0.000000] pgd = c0004000
      [    0.000000] [00030ef1] *pgd=00000000
      [    0.000000] Internal error: Oops: 5 [#1] SMP
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0    Not tainted  (3.3.0-rc1-11574-g0c76665-dirty #3)
      [    0.000000] PC is at dmtimer_read_sched_clock+0x18/0x4c
      [    0.000000] LR is at update_sched_clock+0x10/0x84
      [    0.000000] pc : [<c00243b8>]    lr : [<c0018684>]    psr: 200001d3
      [    0.000000] sp : c0641f38  ip : c0641e18  fp : 0000000a
      [    0.000000] r10: 151c3303  r9 : 00000026  r8 : 76276259
      [    0.000000] r7 : 00028547  r6 : c065ac80  r5 : 431bde82  r4 : c0655968
      [    0.000000] r3 : 00030ef1  r2 : fb032000  r1 : 00000028  r0 : 00000001
      Signed-off-by: default avatarVaibhav Hiremath <hvaibhav@ti.com>
      [tony@atomide.com: updated comments]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      dbc3982a
    • Prarit Bhargava's avatar
      bugs, x86: Fix printk levels for panic, softlockups and stack dumps · b0f4c4b3
      Prarit Bhargava authored
      
      
      rsyslog will display KERN_EMERG messages on a connected
      terminal.  However, these messages are useless/undecipherable
      for a general user.
      
      For example, after a softlockup we get:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Stack:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Call Trace:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Code: ff ff a8 08 75 25 31 d2 48 8d 86 38 e0 ff ff 48 89
       d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e0 0f 01 c9 <e8> ea 69 dd ff 4c 29 e8 48 89 c7 e8 0f bc da ff 49 89 c4 49 89
      
      This happens because the printk levels for these messages are
      incorrect. Only an informational message should be displayed on
      a terminal.
      
      I modified the printk levels for various messages in the kernel
      and tested the output by using the drivers/misc/lkdtm.c kernel
      modules (ie, softlockups, panics, hard lockups, etc.) and
      confirmed that the console output was still the same and that
      the output to the terminals was correct.
      
      For example, in the case of a softlockup we now see the much
      more informative:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 10:18:06 ...
       BUG: soft lockup - CPU4 stuck for 60s!
      
      instead of the above confusing messages.
      
      AFAICT, the messages no longer have to be KERN_EMERG.  In the
      most important case of a panic we set console_verbose().  As for
      the other less severe cases the correct data is output to the
      console and /var/log/messages.
      
      Successfully tested by me using the drivers/misc/lkdtm.c module.
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Cc: dzickus@redhat.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1327586134-11926-1-git-send-email-prarit@redhat.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b0f4c4b3
    • Jan Beulich's avatar
      x86: Properly parenthesize cmpxchg() macro arguments · fc395b92
      Jan Beulich authored
      
      
      Quite oddly, all of the arguments passed through from the top
      level macros to the second level which didn't need parentheses
      had them, while the only expression (involving a parameter)
      needing them didn't.
      
      Very recently I got bitten by the lack thereof when using
      something like "array + index" for the first operand, with
      "array" being an array more narrow than int.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/4F2183A9020000780006F3E6@nat28.tlf.novell.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      fc395b92
    • Greg Kroah-Hartman's avatar
      Revert "tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip" · af681cad
      Greg Kroah-Hartman authored
      This reverts commit 43cf7c0b
      
       as Paul
      wants to redo it.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Govindraj Raja <govindraj.r@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      af681cad
    • Julia Lawall's avatar
      arch/arm/mach-imx/mach-mx53_ard.c: add missing iounmap · 945f82f2
      Julia Lawall authored
      Add missing iounmap in error handling code, in a case where the function
      already preforms iounmap on some other execution path.
      
      A simplified version of the semantic match that finds this problem is as
      follows: (http://coccinelle.lip6.fr/
      
      )
      
      // <smpl>
      @@
      expression e;
      statement S,S1;
      int ret;
      @@
      e = \(ioremap\|ioremap_nocache\)(...)
      ... when != iounmap(e)
      if (<+...e...+>) S
      ... when any
          when != iounmap(e)
      *if (...)
         { ... when != iounmap(e)
           return ...; }
      ... when any
      iounmap(e);
      // </smpl>
      Signed-off-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      945f82f2
    • Fabio Estevam's avatar
      ARM: imx: iomux-v1.h: Fix build error due to __init annotation · 7c0c3454
      Fabio Estevam authored
      
      
      Fix the following build error found when building imx_v4_v5_defconfig:
      
        CC      arch/arm/mach-imx/mach-imx27ipcam.o
      In file included from arch/arm/plat-mxc/include/mach/iomux-mx27.h:23,
                       from arch/arm/mach-imx/mach-imx27ipcam.c:22:
      arch/arm/plat-mxc/include/mach/iomux-v1.h:99: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'imx_iomuxv1_init'
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      7c0c3454
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI: PHY burnout fix · c49d005b
      Tomi Valkeinen authored
      
      
      A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
      if the HDMI PHY is kept powered on when the cable is not connected.
      
      This patch solves the problem by adding hot-plug-detection into the HDMI
      IP driver. This is not a real HPD support in the sense that nobody else
      than the IP driver gets to know about the HPD events, but is only meant
      to fix the HW bug.
      
      The strategy is simple: If the display device is turned off by the user,
      the PHY power is set to OFF. When the display device is turned on by the
      user, the PHY power is set either to LDOON or TXON, depending on whether
      the HDMI cable is connected.
      
      The reason to avoid PHY OFF when the display device is on, but the cable
      is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
      "ticking" and thus the DISPC does not receive pixel clock from the HDMI
      IP. This would, for example, prevent any VSYNCs from happening, and
      would thus affect the users of omapdss. By using LDOON when the cable is
      disconnected we'll avoid the HW bug, but keep the HDMI working as usual
      from the user's point of view.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      c49d005b
    • Tomi Valkeinen's avatar
      OMAP: 4430SDP/Panda: add HDMI HPD gpio · aa74274b
      Tomi Valkeinen authored
      
      
      Both Panda and 4430SDP use GPIO 63 as HDMI hot-plug-detect. Configure
      this GPIO in the board files.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      aa74274b
    • Tomi Valkeinen's avatar
      OMAP: 4430SDP/Panda: setup HDMI GPIO muxes · 78a1ad8f
      Tomi Valkeinen authored
      
      
      The HDMI GPIO pins LS_OE and CT_CP_HPD are not currently configured.
      This patch configures them as output pins.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      78a1ad8f
    • Tomi Valkeinen's avatar
      OMAPDSS: remove wrong HDMI HPD muxing · 7bb122d1
      Tomi Valkeinen authored
      
      
      "hdmi_hpd" pin is muxed to INPUT and PULLUP, but the pin is not
      currently used, and in the future when it is used, the pin is used as a
      GPIO and is board specific, not an OMAP4 wide thing.
      
      So remove the muxing for now.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      7bb122d1