Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 29 4月, 2016 5 次提交
  3. 23 4月, 2016 1 次提交
  5. 07 4月, 2016 1 次提交
  7. 08 3月, 2016 1 次提交
  9. 07 3月, 2016 1 次提交
  11. 01 3月, 2016 1 次提交
  13. 22 2月, 2016 1 次提交
  15. 17 2月, 2016 1 次提交
  17. 11 2月, 2016 1 次提交
  19. 29 1月, 2016 1 次提交
  21. 12 1月, 2016 1 次提交
  23. 30 12月, 2015 1 次提交
  25. 23 12月, 2015 1 次提交
  27. 22 12月, 2015 2 次提交
  29. 21 12月, 2015 1 次提交
    • G
      drm/i915: Correct max delay for HDMI hotplug live status checking · 61fb3980
      由 Gary Wang 提交于 
      The total delay of HDMI hotplug detecting with 30ms have already
been split into a resolution of 3 retries of 10ms each, for the worst
cases. But it still suffered from only waiting 10ms at most in
intel_hdmi_detect(). This patch corrects it by reading hotplug status
with 4 times at most for 30ms delay.

v2:
- straight up to loop execution for more clear in code readability
- mdelay will replace with msleep by Daniel's new patch

	drm/i915: mdelay(10) considered harmful

- suggest to re-evaluate try times for being compatible to old HDMI monitor
Reviewed-by: NCooper Chiou <cooper.chiou@intel.com>
Tested-by: NGary Wang <gary.c.wang@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Gavin Hindman <gavin.hindman@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NGary Wang <gary.c.wang@intel.com>
[danvet: fixup conflict with s/mdelay/msleep/ patch.]
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      61fb3980
  31. 17 12月, 2015 2 次提交
  33. 11 12月, 2015 1 次提交
  35. 10 12月, 2015 2 次提交
  37. 02 12月, 2015 2 次提交
  39. 01 12月, 2015 1 次提交
  41. 20 11月, 2015 2 次提交
  43. 18 11月, 2015 2 次提交
    • V
      drm/i915: Type safe register read/write · f0f59a00
      由 Ville Syrjälä 提交于 
      Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.

This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.

The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.

As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
  lea    0x70024(%rdx,%rax,1),%r9d
  mov    $0x1,%edx
- movslq %r9d,%r9
- mov    %r9,%rsi
- mov    %r9,-0x58(%rbp)
- callq  *0xd8(%rbx)
+ mov    %r9d,%esi
+ mov    %r9d,-0x48(%rbp)
 callq  *0xd8(%rbx)

So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.

v2: i915_mmio_reg_{offset,equal,valid}() helpers added
    s/_REG/_MMIO/ in the register defines
    mo more switch statements left to worry about
    ring_emit stuff got sorted in a prep patch
    cmd parser, lrc context and w/a batch buildup also in prep patch
    vgpu stuff cleaned up and moved to a prep patch
    all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
      f0f59a00
    • V
      drm/i915: Introduce a gmbus power domain · f0ab43e6
      由 Ville Syrjälä 提交于 
      Currently the gmbus code uses intel_aux_display_runtime_get/put in an
effort to make sure the hardware is powered up sufficiently for gmbus.
That function only takes the runtime PM reference which on VLV/CHV/BXT
is not enough. We need the disp2d/pipe-a well on VLV/CHV and power well
2 on BXT. So add a new power domnain for gmbus and kill off the now
unused intel_aux_display_runtime_get/put. And change
intel_hdmi_set_edid() to use the gmbus power domain too since that's all
we need there.

Also toss in a BUILD_BUG_ON() to catch problems if we run out of
bits for power domains. We're already really close to the limit...

[Patrik: Add gmbus string to debugfs output]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-5-git-send-email-patrik.jakobsson@linux.intel.com
      f0ab43e6
  45. 10 11月, 2015 1 次提交
  47. 21 10月, 2015 2 次提交
  49. 13 10月, 2015 1 次提交
  51. 09 10月, 2015 1 次提交
  53. 06 10月, 2015 2 次提交
    • S
      drm/i915: Add hot_plug hook for hdmi encoder · 0b5e88dc
      由 Sonika Jindal 提交于 
      This patch adds a separate probe function for HDMI
EDID read over DDC channel. This function has been
registered as a .hot_plug handler for HDMI encoder.

The current implementation of hdmi_detect()
function re-sets the cached HDMI edid (in connector->detect_edid) in
every detect call.This function gets called many times, sometimes
directly from userspace probes, forcing drivers to read EDID every
detect function call.This causes several problems like:

1. Race conditions in multiple hot_plug / unplug cases, between
   interrupts bottom halves and userspace detections.
2. Many Un-necessary EDID reads for single hotplug/unplug
3. HDMI complaince failures which expects only one EDID read per hotplug

This function will be serving the purpose of really reading the EDID
by really probing the DDC channel, and updating the cached EDID.

The plan is to:
1. i915 IRQ handler bottom half function already calls
   intel_encoder->hotplug() function. Adding This probe function which
   will read the EDID only in case of a hotplug / unplug.
2. During init_connector this probe will be called to read the edid
3. Reuse the cached EDID in hdmi_detect() function.

The "< gen7" check is there because this was tested only for >=gen7
platforms. For older platforms the hotplug/reading edid path remains same.

v2: Calling set_edid instead of hdmi_probe during init.
Also, for platforms having DDI, intel_encoder for DP and HDMI is same
(taken from intel_dig_port), so for DP also, hot_plug function gets called
which is not intended here. So, check for HDMI in intel_hdmi_probe
Rely on HPD for updating edid only for platforms gen > 8 and also for VLV.

v3: Dropping the gen < 8 || !VLV  check. Now all platforms should rely on
hotplug or init for updating the edid.(Daniel)
Also, calling hdmi_probe in init instead of set_edid

v4: Renaming intel_hdmi_probe to intel_hdmi_hot_plug.
Also calling this hotplug handler from intel_hpd_init to take care of init
resume scenarios.

v5: Moved the call to encoder hotplug during init to separate patch(Daniel)
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
[danvet: Mark intel_hdmi_hot_plug as static.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0b5e88dc
    • V
      drm/i915: Don't bypass LRC on CHV · 9571b190
      由 Ville Syrjälä 提交于 
      The docs are unclear as usual, so it's not clear whether LRC should be
bypassed, performed normally or GRC code should be used as the LRC code.
Some old docs stated that LRC bypass ought to be used, more recent ones
no longer say that. Some docs indicated that we could use GRC as the LRC
code on CHV, but the BIOS doesn't do that, so let's not do it either.

Besides to enable LRC bypass properly, I believe we should set the bit
already before deasserting cmnreset.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9571b190
  55. 30 9月, 2015 1 次提交