1. 28 Oct, 2015 2 commits
    • Tony Lindgren's avatar
      usb: musb: omap2430: Fix regression caused by driver core change · 8f2279d5
      Tony Lindgren authored
      Commit ddef08dd ("Driver core: wakeup the parent device before trying
      probe") started automatically ensuring the parent device is enabled when
      the child gets probed.
      
      This however caused a regression for MUSB omap2430 interface as the
      runtime PM for the parent device needs the child initialized to access
      the MUSB hardware registers.
      
      Let's delay the enabling of PM runtime for the parent until the child
      has been properly initialized as suggested in an earlier patch by
      Grygorii Strashko <grygorii.strashko@ti.com>.
      
      In addition to delaying pm_runtime_enable, we now also need to make sure
      the parent is enabled during omap2430_musb_init. We also want to propagate
      an error from omap2430_runtime_resume if struct musb is not initialized.
      
      Note that we use pm_runtime_put_noidle here for both the child and parent
      to prevent an extra runtime_suspend/resume cycle.
      
      Let's also add some comments to avoid confusion between the
      two different devices.
      
      Fixes: ddef08dd ("Driver core: wakeup the parent device before
      trying probe")
      Suggested-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Reviewed-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Acked-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      8f2279d5
    • Aaro Koskinen's avatar
      ARM: OMAP1: fix incorrect INT_DMA_LCD · 1bd5dfe4
      Aaro Koskinen authored
      Commit 685e2d08 ("ARM: OMAP1: Change interrupt numbering for
      sparse IRQ") turned on SPARSE_IRQ on OMAP1, but forgot to change
      the number of INT_DMA_LCD. This broke the boot at least on Nokia 770,
      where the device hangs during framebuffer initialization.
      
      Fix by defining INT_DMA_LCD like the other interrupts.
      
      Cc: stable@vger.kernel.org # v4.2+
      Fixes: 685e2d08 ("ARM: OMAP1: Change interrupt numbering for sparse IRQ")
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      1bd5dfe4
  2. 19 Oct, 2015 1 commit
    • Tony Lindgren's avatar
      ARM: OMAP2+: Fix imprecise external abort caused by bogus SRAM init · 57df5380
      Tony Lindgren authored
      Some omaps are producing imprecise external aborts because we are
      wrongly trying to init SRAM for device tree based booting. Only
      omap3 is still using the legacy SRAM code, so we need to make it
      omap3 specific. Otherwise we can get errors like this on at least
      dm814x:
      
      Unhandled fault: imprecise external abort (0xc06) at 0xc08b156c
      ...
      (omap_rev) from [<c08b12e0>] (omap_sram_init+0xf8/0x3e0)
      (omap_sram_init) from [<c08aca0c>] (omap_sdrc_init+0x10/0xb0)
      (omap_sdrc_init) from [<c08b581c>] (pdata_quirks_init+0x18/0x44)
      (pdata_quirks_init) from [<c08b5478>] (omap_generic_init+0x10/0x1c)
      (omap_generic_init) from [<c08a57e0>] (customize_machine+0x1c/0x40)
      (customize_machine) from [<c00098a4>] (do_one_initcall+0x80/0x1dc)
      (do_one_initcall) from [<c08a2ec4>] (kernel_init_freeable+0x218/0x2e8)
      (kernel_init_freeable) from [<c063a554>] (kernel_init+0x8/0xec)
      (kernel_init) from [<c000f890>] (ret_from_fork+0x14/0x24)
      
      Let's fix the issue by making sure omap_sdrc_init only gets called for
      omap3. To do that, we need to have compatible "ti,omap3" in the dts
      files. And let's also use "ti,omap3630" instead of "ti,omap36xx" like
      we're supposed to.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      57df5380
  3. 16 Oct, 2015 1 commit
    • Tony Lindgren's avatar
      ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory · 6a3b764b
      Tony Lindgren authored
      On boards with more than 2GB of RAM booting goes wrong with things not
      working and we're getting lots of l3 warnings:
      
      WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147
      l3_interrupt_handler+0x260/0x384()
      44000000.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle):
      Data Access in User mode during Functional access
      ...
      [<c044e158>] (scsi_add_host_with_dma) from [<c04705c8>]
      (ata_scsi_add_hosts+0x5c/0x18c)
      [<c04705c8>] (ata_scsi_add_hosts) from [<c046b13c>]
      (ata_host_register+0x150/0x2cc)
      [<c046b13c>] (ata_host_register) from [<c046b38c>]
      (ata_host_activate+0xd4/0x124)
      [<c046b38c>] (ata_host_activate) from [<c047f42c>]
      (ahci_host_activate+0x5c/0x194)
      [<c047f42c>] (ahci_host_activate) from [<c0480854>]
      (ahci_platform_init_host+0x1f0/0x3f0)
      [<c0480854>] (ahci_platform_init_host) from [<c047c9dc>]
      (ahci_probe+0x70/0x98)
      [<c047c9dc>] (ahci_probe) from [<c04220cc>]
      (platform_drv_probe+0x54/0xb4)
      
      Let's fix the issue by enabling ZONE_DMA for LPAE. Note that we need to
      limit dma_zone_size to 2GB as the rest of the RAM is beyond the 4GB limit.
      
      Let's also fix things for dra7 as done in similar patches in the TI tree
      by Lokesh Vutla <lokeshvutla@ti.com>.
      Reviewed-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      6a3b764b
  4. 12 Oct, 2015 4 commits
    • Tony Lindgren's avatar
      Documentation: ARM: List new omap MMC requirements · d8e1f5ed
      Tony Lindgren authored
      Earlier the PBIAS regulator was optional, not so with recent
      omap_hsmmc changes. To make things easier for people with
      custom .config files, let's add minimal documentation for it
      as suggested by Russell King <rmk+kernel@arm.linux.org.uk>.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      d8e1f5ed
    • Uwe Kleine-König's avatar
      memory: omap-gpmc: dump "before" state before first modification · fd820a1e
      Uwe Kleine-König authored
      When gpmc_cs_show_timings is called in gpmc_cs_set_timings()
      gpmc_cs_program_settings() was already run which modifies the CONFIG1
      register. So to be more useful do the "before" dump earlier.
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Acked-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      fd820a1e
    • Tony Lindgren's avatar
      memory: omap-gpmc: Fix unselectable debug option for GPMC · be59b619
      Tony Lindgren authored
      Commit 63aa945b ("memory: omap-gpmc: Add Kconfig option for debug")
      added a debug option for GPMC, but somehow managed to keep it unselectable.
      
      This probably happened because I had some uncommitted changes and the
      GPMC option is selected in the platform specific Kconfig.
      
      Let's also update the description a bit, it does not mention that
      enabling the debug option also disables the reset of GPMC controller
      during the init as pointed out by Uwe Kleine-König
      <u.kleine-koenig@pengutronix.de> and Roger Quadros <rogerq@ti.com>.
      
      Fixes: 63aa945b ("memory: omap-gpmc: Add Kconfig option for debug")
      Reported-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Acked-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      be59b619
    • Tomi Valkeinen's avatar
      ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on · 7e381ec6
      Tomi Valkeinen authored
      LDO1 regulator (VDD_SD) is connected to SoC's vddshv8. vddshv8 needs to
      be kept always powered (see commit 5a0f93c6 ("ARM: dts: Add
      am57xx-beagle-x15"), but at the moment VDD_SD is enabled/disabled
      depending on whether an SD card is inserted or not.
      
      This patch sets LDO1 regulator to always-on.
      
      This patch has a side effect of fixing another issue, HDMI DDC not
      working when SD card is not inserted:
      
      Why this happens is that the tpd12s015 (HDMI level shifter/ESD
      protection chip) has LS_OE GPIO input, which needs to be enabled for the
      HDMI DDC to work. LS_OE comes from gpio6_28. The pin that provides
      gpio6_28 is powered by vddshv8, and vddshv8 comes from VDD_SD.
      
      So when SD card is not inserted, VDD_SD is disabled, and LS_OE stays
      off.
      
      The proper fix for the HDMI DDC issue would be to maybe have the pinctrl
      framework manage the pin specific power.
      
      Apparently this fixes also a third issue (copy paste from Kishon's
      patch):
      
      ldo1_reg in addition to being connected to the io lines is also
      connected to the card detect line. On card removal, omap_hsmmc
      driver does a regulator_disable causing card detect line to be
      pulled down. This raises a card insertion interrupt and once the
      MMC core detects there is no card inserted, it does a
      regulator disable which again raises a card insertion interrupt.
      This happens in a loop causing infinite MMC interrupts.
      
      Fixes: 5a0f93c6 ("ARM: dts: Add am57xx-beagle-x15")
      Cc: Kishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Reported-by: default avatarLouis McCarthy <compeoree@gmail.com>
      Acked-by: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      7e381ec6
  5. 11 Oct, 2015 8 commits
  6. 10 Oct, 2015 12 commits
  7. 09 Oct, 2015 10 commits
  8. 08 Oct, 2015 2 commits
    • Mikulas Patocka's avatar
      crash in md-raid1 and md-raid10 due to incorrect list manipulation · a452744b
      Mikulas Patocka authored
      The commit 55ce74d4 (md/raid1: ensure
      device failure recorded before write request returns) is causing crash in
      the LVM2 testsuite test shell/lvchange-raid.sh. For me the crash is 100%
      reproducible.
      
      The reason for the crash is that the newly added code in raid1d moves the
      list from conf->bio_end_io_list to tmp, then tests if tmp is non-empty and
      then incorrectly pops the bio from conf->bio_end_io_list (which is empty
      because the list was alrady moved).
      
      Raid-10 has a similar bug.
      
      Kernel Fault: Code=15 regs=000000006ccb8640 (Addr=0000000100000000)
      CPU: 3 PID: 1930 Comm: mdX_raid1 Not tainted 4.2.0-rc5-bisect+ #35
      task: 000000006cc1f258 ti: 000000006ccb8000 task.ti: 000000006ccb8000
      
           YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      PSW: 00001000000001001111111000001111 Not tainted
      r00-03  000000ff0804fe0f 000000001059d000 000000001059f818 000000007f16be38
      r04-07  000000001059d000 000000007f16be08 0000000000200200 0000000000000001
      r08-11  000000006ccb8260 000000007b7934d0 0000000000000001 0000000000000000
      r12-15  000000004056f320 0000000000000000 0000000000013dd0 0000000000000000
      r16-19  00000000f0d00ae0 0000000000000000 0000000000000000 0000000000000001
      r20-23  000000000800000f 0000000042200390 0000000000000000 0000000000000000
      r24-27  0000000000000001 000000000800000f 000000007f16be08 000000001059d000
      r28-31  0000000100000000 000000006ccb8560 000000006ccb8640 0000000000000000
      sr00-03  0000000000249800 0000000000000000 0000000000000000 0000000000249800
      sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      
      IASQ: 0000000000000000 0000000000000000 IAOQ: 000000001059f61c 000000001059f620
       IIR: 0f8010c6    ISR: 0000000000000000  IOR: 0000000100000000
       CPU:        3   CR30: 000000006ccb8000 CR31: 0000000000000000
       ORIG_R28: 000000001059d000
       IAOQ[0]: call_bio_endio+0x34/0x1a8 [raid1]
       IAOQ[1]: call_bio_endio+0x38/0x1a8 [raid1]
       RP(r2): raid_end_bio_io+0x88/0x168 [raid1]
      Backtrace:
       [<000000001059f818>] raid_end_bio_io+0x88/0x168 [raid1]
       [<00000000105a4f64>] raid1d+0x144/0x1640 [raid1]
       [<000000004017fd5c>] kthread+0x144/0x160
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Fixes: 55ce74d4 ("md/raid1: ensure device failure recorded before write request returns.")
      Fixes: 95af587e ("md/raid10: ensure device failure recorded before write request returns.")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      a452744b
    • Srinivas Pandruvada's avatar
      cpufreq: prevent lockup on reading scaling_available_frequencies · 55582bcc
      Srinivas Pandruvada authored
      When scaling_available_frequencies is read on an offlined cpu, then
      either lockup or junk values are displayed. This is caused by
      freed freq_table, which policy is using.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      55582bcc