1. 16 6月, 2014 1 次提交
    • B
      Revert "offb: Add palette hack for little endian" · 68986c9f
      Benjamin Herrenschmidt 提交于
      This reverts commit e1edf18b.
      
      This patch was a misguided attempt at fixing offb for LE ppc64
      kernels on BE qemu but is just wrong ... it breaks real LE/LE
      setups, LE with real HW, and existing mixed endian systems
      that did the fight thing with the appropriate device-tree
      property. Bad reviewing on my part, sorry.
      
      The right fix is to either make qemu change its endian when
      the guest changes endian (working on that) or to use the
      existing foreign endian support.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: <stable@vger.kernel.org> [v3.13+]
      ---
      68986c9f
  2. 10 6月, 2014 1 次提交
    • D
      drm/i915: Kick out vga console · a4de0526
      Daniel Vetter 提交于
      Touching the VGA resources on an IVB EFI machine causes hard hangs when
      we then kick out the efifb. Ouch.
      
      Apparently this also prevents unclaimed register errors on hsw and
      hard machine hangs on my i855gm when trying to unbind fbcon.
      
      Also, we want this to make I915_FBDEV=n safe.
      
      v2: Rebase and pimp commit message.
      
      v3: We also need to unregister the vga console, otherwise the unbind
      of the fb console before module unload might resurrect it again.
      
      v4: Ignore errors when the vga console is already unregistered - this
      can happen when e.g. reloading i915.ko.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: linux-fbdev@vger.kernel.org
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a4de0526
  3. 05 6月, 2014 1 次提交
    • T
      backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip · ab1e59b4
      Tony Lindgren 提交于
      If the GPIO for the backlight is on an I2C chip, we currently
      get nasty warnings like this during the boot:
      
      WARNING: CPU: 0 PID: 6 at drivers/gpio/gpiolib.c:2364 gpiod_set_raw_value+0x40/0x4c()
      Modules linked in:
      CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc4-12393-gcde9f4e #400
      Workqueue: deferwq deferred_probe_work_func
      [<c0014cbc>] (unwind_backtrace) from [<c001191c>] (show_stack+0x10/0x14)
      [<c001191c>] (show_stack) from [<c0566ae0>] (dump_stack+0x80/0x9c)
      [<c0566ae0>] (dump_stack) from [<c003f61c>] (warn_slowpath_common+0x68/0x8c)
      [<c003f61c>] (warn_slowpath_common) from [<c003f65c>] (warn_slowpath_null+0x1c/0x24)
      [<c003f65c>] (warn_slowpath_null) from [<c02f7e10>] (gpiod_set_raw_value+0x40/0x4c)
      [<c02f7e10>] (gpiod_set_raw_value) from [<c0308fbc>] (gpio_backlight_update_status+0x4c/0x74)
      [<c0308fbc>] (gpio_backlight_update_status) from [<c030914c>] (gpio_backlight_probe+0x168/0x254)
      [<c030914c>] (gpio_backlight_probe) from [<c0378fa8>] (platform_drv_probe+0x18/0x48)
      [<c0378fa8>] (platform_drv_probe) from [<c0377c40>] (driver_probe_device+0x10c/0x238)
      [<c0377c40>] (driver_probe_device) from [<c0376330>] (bus_for_each_drv+0x44/0x8c)
      [<c0376330>] (bus_for_each_drv) from [<c0377afc>] (device_attach+0x74/0x8c)
      [<c0377afc>] (device_attach) from [<c03771c4>] (bus_probe_device+0x88/0xb0)
      [<c03771c4>] (bus_probe_device) from [<c03775c8>] (deferred_probe_work_func+0x64/0x94)
      [<c03775c8>] (deferred_probe_work_func) from [<c00572e8>] (process_one_work+0x1b4/0x4bc)
      [<c00572e8>] (process_one_work) from [<c00579d0>] (worker_thread+0x11c/0x398)
      [<c00579d0>] (worker_thread) from [<c005dfd8>] (kthread+0xc8/0xe4)
      [<c005dfd8>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c)
      
      Fix this by using gpio_set_value_cansleep() as suggested in
      drivers/gpio/gpiolib.c:2364. This is what the other backlight drivers
      are also doing.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NJingoo Han <jg1.han@samsung.com>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      ab1e59b4
  4. 04 6月, 2014 1 次提交
  5. 29 5月, 2014 2 次提交
    • T
      console: Use explicit pointer type for vc_uni_pagedir* fields · e4bdab70
      Takashi Iwai 提交于
      The vc_data.vc_uni_pagedir filed is currently long int, supposedly to
      be served generically.  This, however, leads to lots of cast to
      pointer, and rather it worsens the readability significantly.
      
      Actually, we have now only a single uni_pagedir map implementation,
      and this won't change likely.  So, it'd be much more simple and
      error-prone to just use the exact pointer for struct uni_pagedir
      instead of long.
      
      Ditto for vc_uni_pagedir_loc.  It's a pointer to the uni_pagedir, thus
      it can be changed similarly to the exact type.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4bdab70
    • T
      vgacon: Fix & cleanup refcounting · 0f2893f0
      Takashi Iwai 提交于
      The vgacon driver prepares a two element array of uni_pagedir_loc and
      uses the second item as its own reference counter for sharing the
      uni_pagedir.  And the code assumes blindly that the second item is
      available if the assigned vc_uni_pagedir isn't the standard one, which
      might be wrong (although currently it's so).
      
      This patch fixes that wrong assumption, and gives a slight cleanup
      along with it: namely, instead of array, just give the uni_pagedir_loc
      and a separate refcount variable.  It makes the code a bit more
      understandable at first glance.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f2893f0
  6. 28 5月, 2014 1 次提交
  7. 27 5月, 2014 2 次提交
  8. 23 5月, 2014 8 次提交
  9. 21 5月, 2014 1 次提交
  10. 20 5月, 2014 6 次提交
  11. 19 5月, 2014 3 次提交
  12. 16 5月, 2014 2 次提交
  13. 15 5月, 2014 1 次提交
  14. 14 5月, 2014 1 次提交
  15. 09 5月, 2014 9 次提交
    • T
      OMAPDSS: Fix writes to DISPC_POL_FREQ · d80e02ef
      Tomi Valkeinen 提交于
      When omapdss writes to DISPC_POL_FREQ register, it always ORs the bits
      with the current contents of the register, never clearing the old ones,
      causing wrong signal polarity settings.
      
      As we write all the bits in DISPC_POL_FREQ, we don't need to care about
      the current contents of the register. So fix the issue by constructing
      new register value from scratch.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      d80e02ef
    • T
      OMAPDSS: HDMI: cleanup ioremaps · 59b3d38a
      Tomi Valkeinen 提交于
      Now that all the boards using OMAP HDMI are using DT boot, we can remove
      the hacks for getting the ioresources with non-DT boot.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      59b3d38a
    • T
      OMAPDSS: HDMI: Add OMAP5 HDMI support · f5bab222
      Tomi Valkeinen 提交于
      This adds a new driver to omapdss for OMAP5 HDMI. However, the new
      driver uses common HDMI files which are shared with OMAP4 HDMI driver.
      
      OMAP5 HDMI has a different HDMI core IP compared to OMAP4, but has very
      similar PLL and PHY IPs which can be handled with common code.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      f5bab222
    • A
      OMAPDSS: HDMI: PLL changes for OMAP5 · 2d64b1b3
      Archit Taneja 提交于
      Add a features struct to differentiate between the HDMI PLLs on OMAP4
      and OMAP5. The OMAP5 PLL is more sensitive when it comes to locking.  We
      need to ensure that the DCO freq isn't too low for lower pixel clocks.
      
      Modify the PLL computation slightly to ensure the HDMI PLL locks for lower
      frequencies. This will be later replaced by a more complex computation
      which makes sure all the PLL constraints are met.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      2d64b1b3
    • A
      OMAPDSS: HDMI: PHY changes for OMAP5 · 19289fdc
      Archit Taneja 提交于
      OMAP5 HDMI PHY has some differences compared to OMAP4 HDMI PHY. This
      patch creates a features struct which help the driver configure the PHY
      based on what SoC it is.
      
      Some of the features aren't currenlty used, but will come in use later.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      19289fdc
    • A
      OMAPDSS: HDMI: support larger register offsets for OMAP5 HDMI core · 8955b727
      Archit Taneja 提交于
      The HDMI core IP on OMAP5 has a wider address range for registers. The offsets
      for the later registers can't fit into the u16 type currently used for hdmi
      register read and write functions. Use u32 for offsets instead.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8955b727
    • T
      OMAPDSS: HDMI: move irq & phy pwr handling · dcf5f729
      Tomi Valkeinen 提交于
      HDMI IRQ handling was moved into hdmi_phy.c when restructuring the HDMI
      driver. While this worked fine, it's not correct.
      
      The HDMI IRQ handling should be either in the hdmi_wp, or in the main
      hdmi driver. This patch moves the handling to the main hdmi driver, as I
      feel it's a more appropriate choice.
      
      This move also requires changing the handling of the PHY power, as that
      was partly handled in the IRQ handler. The PHY power is handled via the
      WP module. An option would be to give HDMI PHY driver function pointers
      that it could use to manage the PHY power, but as the PHY power is not
      needed to access the PHY registers, the handling was also moved to the
      main HDMI driver. This could be changed later if need be.
      
      Note that there's slightly similar power issue with the PLL: the HDMI
      PLLs power is also handled via the WP module. For now, the PLL power
      handling is still done inside the PLL driver.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      dcf5f729
    • T
      OMAPDSS: HDMI: improve Makefile · 543e761f
      Tomi Valkeinen 提交于
      We'll soon add support for OMAP5 HDMI, which uses some of the same files
      as OMAP4 HDMI does.
      
      This patch adds a new config entry "OMAP2_DSS_HDMI_COMMON", which both
      OMAP4 and OMAP5 HDMI config entries can select. OMAP2_DSS_HDMI_COMMON
      will cause the common HDMI files to be compiled.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      543e761f
    • T
      OMAPDSS: DSI: Add OMAP5 DSI module IDs · bd3ad6a4
      Tomi Valkeinen 提交于
      Add OMAP5 DSI module ID support to the OMAP DSI driver.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      bd3ad6a4