[Bug 64021] nouveau: Second card output corrupted after suspend / resume

https://bugzilla.kernel.org/show_bug.cgi?id=64021 thomas.bettler at gmail.com changed: What|Removed |Added Kernel Version|3.11|3.12_rc7 -- You are

[Bug 64021] nouveau: Second card output corrupted after suspend / resume

https://bugzilla.kernel.org/show_bug.cgi?id=64021 thomas.bettler at gmail.com changed: What|Removed |Added Attachment #112691|0 |1 is obsolete|

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

Hi Sean, On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote: > On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa wrote: > > Hi, > > > > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote: > >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote: > >> > I think we need to start

drm/exynos: change callback argument of sub driver with device

2013/10/28 Sean Paul : > Hi Inki, > I noticed that you merged "drm/exynos: change callback argument of sub > driver with device" to your tree without posting it to me, or > dri-devel, first. I think it would have been prudent to send for > review/comments considering that: > > a) we don't agree on

fix for CRTC mutex corruption

On Tue, Oct 29, 2013 at 8:22 PM, Ilija Hadzic wrote: > >>> The actual fix is implemented in patch #6; preceding >>> 5 patches are necessary prerequisites. >> >> >> Hm, I don't really see why patches 1,2&4 are required. If we reorder them >> to the end of the series as follow-up cleanups then we'd

[Bug 64021] nouveau: Second card output corrupted after suspend / resume

https://bugzilla.kernel.org/show_bug.cgi?id=64021 thomas.bettler at gmail.com changed: What|Removed |Added Kernel Version|linux-3.11 |3.11 -- You are receiving

[Bug 69081] [radeonsi] Incorrect rendering of textures

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131029/5e890fb8/attachment.html>

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

Hi, On 29/10/13 20:23, Tomasz Figa wrote: >> It's a very deeply nested structure, I'm not sure there's a need to >> > make a ports {} subnode really. >> > >> > Also, I don't know if it makes sense to always name it >> > remote-endpoint, or to use a more flexible name depending on what is >> >

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

nate. If you have separate drivers, everything needs to be synchronized, but also has to account for potentially different loading order. It seems you're only thinking about the basic case, where you only support a single resolution, no dpms, no suspend to ram... But when you want full fledged functionality, then the issues I described become much more prevalent. St?phane > > Unless there is a misunderstanding here, I think this is broken. > > > An example: exynos_drm_drv would be a platform_driver which implements > > drm_driver. On drm_load, it would enumerate the various dt nodes for > > its IP blocks and initialize them with direct calls (like > > exynos_drm_fimd_initialize). If the board uses a bridge (say for > > eDP->LVDS), that bridge driver would be a real driver with its own > > probe. > > > > I think the ideal situation would be for the drm layer to manage the > > standalone drivers in a way that is transparent to the main driver, > > such that it doesn't need to know which type of hardware can hang off > > it. It will need to know if one exists since it might need to forego > > creating a connector, but it need not know anything else about it. > > > > To accomplish this, I think we need: > > (1) Some way for drm to enumerate the standalone drivers, so it can > > know when all of them have been probed > > (2) A drm registration function that's called by the standalone > > drivers once they're probed, and a hook with drm_device pointer called > > during drm_load for them to register their drm_* implementations > > (3) Something that will allow for deferred probe if the main driver > > kicks off before the standalones are in, it would need to be called > > before drm_platform/pci_init > > > > I think we'll need to expand on the media bindings to achieve (1). > > Could you elaborate on why you think so? > > I believe the video interface bindings contain everything needed for this > case, except, of course, some device/bus specific parts, but those are to > be defined by separate device/bus specific bindings. > > Best regards, > Tomasz > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/1f1d1739/attachment.html>

[Bug 64021] nouveau: Second card output corrupted after suspend / resume

https://bugzilla.kernel.org/show_bug.cgi?id=64021 thomas.bettler at gmail.com changed: What|Removed |Added URL||https://bugs.freedesktop.or

[Bug 64021] nouveau: Second card output corrupted after suspend / resume

https://bugzilla.kernel.org/show_bug.cgi?id=64021 --- Comment #3 from thomas.bettler at gmail.com --- Created attachment 112691 --> https://bugzilla.kernel.org/attachment.cgi?id=112691=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH] drm: delete unconsumed pending event list in drm_events_release

When there are unconsumed pending events, the events are destroyed by calling destroy callback, but the events list are remained, because there is no list_del(). It is possible that the page flip request is handled after drm_events_release() is called and before drm_fb_release(). In this case a

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

On Tuesday 29 of October 2013 12:19:35 Olof Johansson wrote: > On Mon, Oct 28, 2013 at 4:13 PM, Tomasz Figa wrote: > > Hi, > > > > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote: > >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote: > >> > I think we need to start

[PATCH 5/5] drm/radeon: clear the page directory using the DMA

From: Christian K?nig Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_gart.c | 34 +- 1 file changed, 29 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_gart.c

[PATCH 4/5] drm/radeon: initially clear page tables

From: Christian K?nig Clear page tables after allocating them in case we don't completely fill them later. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_gart.c | 10 ++ 1 file changed, 10 insertions(+) diff --git

[PATCH 3/5] drm/radeon: drop CP page table updates & cleanup v2

From: Christian K?nig The DMA ring seems to be stable now. v2: remove pt_ring_index as well Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/cik.c | 61 - drivers/gpu/drm/radeon/cik_sdma.c| 21 --

[PATCH 2/5] drm/radeon: add vm_set_page tracepoint

From: Christian K?nig Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/cik_sdma.c | 3 +++ drivers/gpu/drm/radeon/ni_dma.c | 3 +++ drivers/gpu/drm/radeon/radeon_trace.h | 24 drivers/gpu/drm/radeon/si_dma.c | 3 +++

[PATCH 1/5] drm/radeon: rework and fix reset detection v2

From: Christian K?nig Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT. Consolidate the two wait sequence implementations into just one function. Activate all waiters and remember if the reset was already done instead of trying to reset from only

[Bug 64021] nouveau: Second card output corrupted after suspend / resume

https://bugzilla.kernel.org/show_bug.cgi?id=64021 --- Comment #2 from thomas.bettler at gmail.com --- Created attachment 112681 --> https://bugzilla.kernel.org/attachment.cgi?id=112681=edit expected screen -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 64021] nouveau: Second card output corrupted after suspend / resume

https://bugzilla.kernel.org/show_bug.cgi?id=64021 --- Comment #1 from thomas.bettler at gmail.com --- Created attachment 112671 --> https://bugzilla.kernel.org/attachment.cgi?id=112671=edit corrupted screen (image) -- You are receiving this mail because: You are watching the assignee of the

[Bug 64021] New: nouveau: Second card output corrupted after suspend / resume

https://bugzilla.kernel.org/show_bug.cgi?id=64021 Bug ID: 64021 Summary: nouveau: Second card output corrupted after suspend / resume Product: Drivers Version: 2.5 Kernel Version: linux-3.11 Hardware: x86-64

[PATCH 14/14] drm/i915: Add a kludge for DSL incrementing too late and ISR not working

From: Ville Syrj?l? On pre-PCH platforms ISR doesn't seem to be an actual ISR, at least as far as display interrupts are concerned. Instead it sort of looks like some ISR bits just directly reflect the corresponding bit from PIPESTAT. The bit appears in the ISR

[PATCH 13/14] drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos()

From: Ville Syrj?l? i915 doesn't need this kludge for most platforms. Although we do appear to need something similar on certain platforms, but we can be more accurate when we apply the adjustment since we know exactly why the scanline counter doesn't always quite

[PATCH 12/14] drm: Pass 'flags' from the caller to .get_scanout_position()

From: Ville Syrj?l? Preparation for moving the early vblank IRQ logic into radeon_get_crtc_scanoutpos(). Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_irq.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 3 ++-

[PATCH 11/14] drm: Fix vblank timestamping constants for interlaced modes

From: Ville Syrj?l? We're currently miscalculating the line and pixel durations for interlaced modes. crtc_htotal and crtc_vtotal are the full frame timings, and so is crtc_clock, so we can compute the line and pixel durations from those w/o any extra adjustments.

[PATCH 10/14] drm/i915: Fix scanoutpos calculations for interlaced modes

From: Ville Syrj?l? The scanline counter counts lines in the current field, not the entire frame. But the crtc_ timings are the values for the entire frame. Divide the vertical timings by 2 to make them match the scanline counter. The rounding was carefully chosen

[PATCH 09/14] drm: Change {pixel,line,frame}dur_ns from s64 to int

From: Ville Syrj?l? Using s64 for the timestamping constants is wasteful. Signed 32bit integers get us a range of over +-2 seconds. Presuming that no-one wants to a vrefresh rate less than 0.5, we can switch to using int for the timestamping constants. We save a

[PATCH 08/14] drm: Use crtc_clock in drm_calc_timestamping_constants()

From: Ville Syrj?l? drm_calc_timestamping_constants() computes the pixel/line/frame durations based on the crtc_ timing values. The corresponding pixel clock is in mode->crtc_clock, so we need to use that instead of mode->clock. This should fix

[PATCH 07/14] drm/radeon: Populate crtc_clock in radeon_atom_get_tv_timings()

From: Ville Syrj?l? crtc_clock is now supposed to be the actual pixel clock corresponding to the other crtc_ timing values. Populate crtc_clock appropriately in radeon_atom_get_tv_timings(). This was the only obvious place where we frob with the crtc_ timigns

[PATCH 06/14] drm: Simplify the math in drm_calc_timestamping_constants()

From: Ville Syrj?l? drm_calc_timestamping_constants() makes the math more complex than necessary. - multipying the dotclock by 1000 is pointless, just makes all the numbers bigger - div64_u64() is also pointless, div_u64 is enough - pixeldur_ns doesn't need any

[PATCH 05/14] drm: Improve drm_calc_timestamping_constants() documentation

From: Ville Syrj?l? Move the long blurp to into the body of the comment, leaving only a short summary line at the top. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_irq.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git

[PATCH 04/14] drm/i915: Call drm_calc_timestamping_constants() earlier

From: Ville Syrj?l? Update the pixel/line/frame duration information when we switch to the new pipe config. This will keep the timestamping constants in better sync with the real hardware state. Signed-off-by: Ville Syrj?l? ---

[PATCH 03/14] drm/i915: Kill hwmode save/restore

From: Ville Syrj?l? drm core no longer uses crtc->hwmode, and neither does i915, so we can totally ignore it in i915. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_display.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-)

[PATCH 02/14] drm: Pass the display mode to drm_calc_vbltimestamp_from_scanoutpos()

From: Ville Syrj?l? Rather than using crtc->hwmode, just pass the relevant mode to drm_calc_vbltimestamp_from_scanoutpos(). This removes the last hwmode usage from core drm. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_irq.c | 6 +++---

[PATCH 01/14] drm: Pass the display mode to drm_calc_timestamping_constants()

From: Ville Syrj?l? We don't really use hwmode anymore in i915, so eliminating its use from the core code seems prudent. Just pass the appropriate mode to drm_calc_timestamping_constants(). Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc_helper.c|

[PATCH 00/14] drm: Some more vblank timestampi changes

So I took another look at the vblank timestamping code, and got a bit excited. The result is this patchset. Summary of changes: - kill crtc->hwmode dependency - eliminate a bunch of 64bit math - fix timestamps for stereo and interlaced modes (on i915 at least) - move the "early vbl irq" hack into

[Bug 70715] radeonsi - Al textures are black in Football Manager 2014 in the 3D match

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/9a557dcf/attachment.html>

fix for CRTC mutex corruption

On Tue, Oct 29, 2013 at 11:09:40AM -0400, Ilija Hadzic wrote: > The following patch series fixes the mutex corruption problem > due to bit-copying of drm_crtc structure that happens when > drm_crtc_helper_set_config function takes the error-recovery > path. The patch series is the alternative

vddc phase shedding in smc tables

Hi, git branch drm-fixes-3.12, git commit cdf6e8058415ba4d808537e30a0a6be9fb29e95a In si_dpm.c, the vddc phase shedding mask does overwrite the vddc voltage mask (lines 3889 and 3920 in si_populate_smc_voltage_tables function). Expected? (my tahiti based board seems not to have vddc phase

[PATCH] drm: shmobile: Add dependency on BACKLIGHT_CLASS_DEVICE

From: Laurent Pinchart The driver registers a backlight device and thus requires BACKLIGHT_CLASS_DEVICE to be selected to avoid compilation breakages. Cc: stable at vger.kernel.org Reported-by: Russell King Signed-off-by: Laurent Pinchart ---

Build failure: shmobile drm driver references backlight symbols

Hi Russell, On Tuesday 29 October 2013 10:04:13 Russell King - ARM Linux wrote: > My build system picked up on this failure: > > drivers/built-in.o: In function `shmob_drm_backlight_init': > fmc-chardev.c:(.text+0x9f2d0): undefined reference to > `backlight_device_register' drivers/built-in.o:

[PATCH v3] intel: Add support for GPU reset status query ioctl

From: Ian Romanick I would have just used the drmIoctl interface directly in Mesa, but the ioctl needs some data from the drm_intel_context that is not exposed outside libdrm. v2: Update based on Mika's kernel work. v3: Fix compile failures from last-minute typos.

[PATCH] intel: Add support for GPU reset status query ioctl

From: Ian Romanick I would have just used the drmIoctl interface directly in Mesa, but the ioctl needs some data from the drm_intel_context that is not exposed outside libdrm. v2: Update based on Mika's kernel work. Signed-off-by: Ian Romanick Cc: Mika Kuoppala Cc:

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote: > Hi Sean, > > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote: >> On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa > wrote: >> > Hi, >> > >> > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote: >> >> On Wed, Oct 23, 2013 at 11:53 AM,

drm/exynos: change callback argument of sub driver with device

> >> to DT nodes, but it isn't essential. So I'd like to move away from the >> 1:1 DT node/driver >> model as it seriously over complicates things. We have agreed we >> should possibly add >> a display virtual node in the DT bindings for a single driver to use >> as a binding point. > > Got it and

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa wrote: > Hi, > > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote: >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote: >> > I think we need to start considering a framework where subdrivers >> > just >> > add drm objects

drm/exynos: change callback argument of sub driver with device

Hi Dave, 2013/10/29 Dave Airlie : > On Tue, Oct 29, 2013 at 12:56 PM, Inki Dae wrote: >> Hi, >> >> 2013/10/29 Olof Johansson : >>> On Mon, Oct 28, 2013 at 6:35 AM, Inki Dae wrote: This patch makes callback funtions of each sub driver to be called with device object instead of display

drm/exynos: vidi: fix build error

2013/10/28 Sean Paul : > On Mon, Oct 28, 2013 at 9:35 AM, Inki Dae wrote: >> This patch fixes build error incurred by the re-factoring patch applying. >> >> The re-factoring patch set from Sean missed to apply the update to vidi >> module so this patch applies the update so that vidi module is

[PATCH v5 0/4] Fix Win8 backlight issue

On 10/28/2013 04:09 PM, Jani Nikula wrote: > On Mon, 28 Oct 2013, Aaron Lu wrote: >> +static int __init video_set_use_native_backlight(const struct dmi_system_id >> *d) >> +{ >> +use_native_backlight = true; >> +return 0; >> +} > > Hi Aaron, it might be beneficial to make

[Bug 70934] [Regression] Problem with colors (depth?) on DCE5 Barts (HD69xx)

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/7f7d7fab/attachment.html>

[PATCH] drm/ttm: Make NO_EVICT bos available to shrinkers pending destruction

On Thu, Oct 10, 2013 at 8:22 PM, Thomas Hellstrom wrote: > NO_EVICT bos that are not idle when all references are dropped are put on > the delayed destroy list. However, since they are not on LRU lists, they > are not available to shrinkers at that point, and buffers on the delayed > destroy

[PATCH] drm/ttm: Allow vm fault retries

On Thu, Oct 10, 2013 at 8:22 PM, Thomas Hellstrom wrote: > Make use of the FAULT_FLAG_ALLOW_RETRY flag to allow dropping the > mmap_sem while waiting for bo idle. > > FAULT_FLAG_ALLOW_RETRY appears to be primarily designed for disk waits > but should work just as fine for GPU waits.. > >

[Bug 63941] Can't control brightness with ATI 5650/Intel Ironlake when switched to radeon

https://bugzilla.kernel.org/show_bug.cgi?id=63941 Jani Nikula changed: What|Removed |Added Attachment #112661|0 |1 is obsolete|

fix for CRTC mutex corruption

On Tue, 29 Oct 2013, Daniel Vetter wrote: > Aside: The horribly ad-hoc calling convetions with some of the (x, y, fb, > mode) parameters being set before calling a lower-level functions, some > being restored, some of them being the old backup value and some of them > being expected to be

[PULL] drm-intel-fixes

On Tue, Oct 29, 2013 at 11:29:29AM +0100, Daniel Vetter wrote: > On Mon, Oct 28, 2013 at 08:49:45AM +0100, Daniel Vetter wrote: > > Hi Dave, > > > > Please do _not_ pull this. The pipe bpp readout stuff this crucially > > relies on is only partially backported from -next to -fixes and apparently

outcome of DRM/KMS DT bindings session

So we had a sessions at kernel summit to discuss the driver model and DT interactions for a display pipeline, we had good attendance from a few sides and I hope to summarise the recommendations below, a) Device Tree bindings We should create a top-level virtual device binding that a top level

[Bug 63941] Can't control brightness with ATI 5650/Intel Ironlake when switched to radeon

https://bugzilla.kernel.org/show_bug.cgi?id=63941 --- Comment #6 from Nikolay Amiantov --- Comment on attachment 112661 --> https://bugzilla.kernel.org/attachment.cgi?id=112661 attachment-21199-0.html Replied from GMail and this happened, sorry. -- You are receiving this mail because: You

[Bug 63941] Can't control brightness with ATI 5650/Intel Ironlake when switched to radeon

https://bugzilla.kernel.org/show_bug.cgi?id=63941 --- Comment #5 from Nikolay Amiantov --- Is there any way to trace ACPI calls and Intel card state (enabled or not) on Windows? It works there, so maybe I can get some information. 29.10.2013 17:32 ???: >

[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings

This patch adds dt support to hdmiphy config settings as it is board specific and depends on the signal pattern of board. Signed-off-by: Shirish S --- .../devicetree/bindings/video/exynos_hdmi.txt | 34 + drivers/gpu/drm/exynos/exynos_hdmi.c | 79

[PATCH 3/4] ARM: exynos: dts: cros5250: Add hdmi phy settings

This patch moves the hdmi phy setting to arndale dts, as its more of a per board configuration and also shall be easier for supporting future chipsets. Signed-off-by: Shirish S --- arch/arm/boot/dts/cros5250-common.dtsi | 75 1 file changed, 75 insertions(+)

[PATCH 2/4] ARM: dts: arndale: Add hdmi phy settings

This patch moves the hdmi phy setting to arndale dts, as its more of a per board configuration and also shall be easier for supporting future chipsets. Signed-off-by: Shirish S --- arch/arm/boot/dts/exynos5250-arndale.dts | 75 ++ 1 file changed, 75 insertions(+)

[PATCH 1/4] ARM: dts: smdk5250: Add hdmi phy settings

This patch moves the hdmi phy setting to smdk5250 dts,as its more of a per board configuration and also shall be easier for supporting future chipsets. Signed-off-by: Shirish S --- arch/arm/boot/dts/exynos5250-smdk5250.dts | 75 + 1 file changed, 75 insertions(+)

[PATCH 0/4] Add dt support for exynos hdmiphy settings

For various revisions of a chipset if the signal pattern is changed for every revision, then the phy setting need to be updated correspondingly by measuring the signal. For getting correct signals the clock level and data de-emphasis levels needs to be adjusted. Since only these 2 values

drm/exynos: change callback argument of sub driver with device

On Tue, Oct 29, 2013 at 12:56 PM, Inki Dae wrote: > Hi, > > 2013/10/29 Olof Johansson : >> On Mon, Oct 28, 2013 at 6:35 AM, Inki Dae wrote: >>> This patch makes callback funtions of each sub driver to be called >>> with device object instead of display and manager. >>> >>> Exynos drm framework

[Bug 63941] Can't control brightness with ATI 5650/Intel Ironlake when switched to radeon

https://bugzilla.kernel.org/show_bug.cgi?id=63941 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #4

[PATCH 3/3] drm: exynos: hdmi: Add dt support for hdmiphy settings

On Tue, Oct 29, 2013 at 4:08 AM, Mark Rutland wrote: > On Mon, Oct 28, 2013 at 10:15:00AM +, Shirish S wrote: >> Hi Mark, >> Firstly thanks for reviewing. > > Hi, > > Please could you refrain from replying in HTML and use plaintext, it's rather > difficult to respond sensibly. > Sorry for

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

On Mon, Oct 28, 2013 at 4:13 PM, Tomasz Figa wrote: > Hi, > > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote: >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote: >> > I think we need to start considering a framework where subdrivers >> > just >> > add drm objects

[PATCH v3 32/32] drm/exynos: Remove the exynos_drm_connector shim

This path removes the exynos_drm_connector code since it was just passing hooks through display_ops. The individual device drivers are now responsible for implementing drm_connector directly. Signed-off-by: Sean Paul --- Changes in v3: - Added to the patchset

[PATCH v3 31/32] drm/exynos: Move lvds bridge discovery into DP driver

This patch moves the lvds bridge discovery and connector pre-emption code from exynos common code into the dp driver (since the bridge is only applicable for dp). Signed-off-by: Sean Paul --- Changes in v3: - Added to the patchset drivers/gpu/drm/exynos/exynos_dp_core.c | 41

[PATCH v3 30/32] drm/exynos: Implement drm_connector directly in vidi driver

This patch implements drm_connector directly in the vidi driver, this will allow us to move away from the exynos_drm_connector layer. Signed-off-by: Sean Paul --- Changes in v3: - Added to the patchset drivers/gpu/drm/exynos/exynos_drm_vidi.c | 163 --- 1

[PATCH v3 29/32] drm/exynos: Implement drm_connector directly in dp driver

This patch implements drm_connector directly in the dp driver, this will allow us to move away from the exynos_drm_connector layer. Signed-off-by: Sean Paul --- Changes in v3: - Added to the patchset drivers/gpu/drm/exynos/exynos_dp_core.c | 99 ++---

[PATCH v3 28/32] drm/exynos: Implement drm_connector in hdmi directly

This patch implements drm_connector in the hdmi driver directly, instead of using exynos_drm_connector. Signed-off-by: Sean Paul --- Changes in v3: - Added to the patchset drivers/gpu/drm/exynos/exynos_hdmi.c | 126 +++ 1 file changed, 85 insertions(+),

[PATCH v3 27/32] drm/exynos: Add create_connector callback

This creates a new display hook called create_connector. The purpose is to allow the display driver to create its own drm_connector instead of using the exynos_drm_connector. This moves things closer to completely removing the exynos_drm_connector abstraction. Signed-off-by: Sean Paul ---

[PATCH v3 26/32] drm/exynos: Consolidate suspend/resume in drm_drv

This patch removes all of the suspend/resume logic from the individual drivers and consolidates it in drm_drv. This consolidation reduces the number of functions which enable/disable the hardware to just one -- the dpms callback. This ensures that we always power up/down in a consistent manner.

[PATCH v3 25/32] drm/exynos: Clean up FIMD power on/off routines

This patch separates the fimd_activate function into poweron/poweroff functions to be more consistent with the other drivers in exynos drm. It also properly cleans up after failures in poweron. The functions have also been shuffled around such that they are all in the same spot in the file and

[PATCH v3 24/32] drm/exynos: Implement dpms display callback in DP

This patch implements the dpms display callback for the DP driver. Signed-off-by: Sean Paul --- Changes in v2: - Added to the patchset Changes in v3: None drivers/gpu/drm/exynos/exynos_dp_core.c | 173 drivers/gpu/drm/exynos/exynos_dp_core.h | 1 + 2

[PATCH v3 23/32] ARM: dts: Move display-timings node from fimd to dp

This patch moves the display-timings node from fimd to dp to reflect the device tree bindings change. Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None arch/arm/boot/dts/exynos5250-arndale.dts | 7 --- arch/arm/boot/dts/exynos5250-smdk5250.dts | 7 ---

[PATCH v3 22/32] drm/exynos: Move display implementation into dp

This patch moves the exynos_drm_display implementation from fimd into the dp driver. This will allow for tighter integration of the dp driver into the exynos drm driver. Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None .../devicetree/bindings/video/exynos_dp.txt|

[PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/

This patch moves the code from video/ to drm/ Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None drivers/gpu/drm/exynos/Kconfig |7 + drivers/gpu/drm/exynos/Makefile |1 + drivers/gpu/drm/exynos/exynos_dp_core.c | 1213 ++

[PATCH v3 20/32] drm/exynos: Remove unused/useless fimd_context members

This patch removes a few fimd_context members which are either entirely unused or unneeded. Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None drivers/gpu/drm/exynos/exynos_drm_fimd.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git

[PATCH v3 19/32] drm/exynos: Use mode_set to configure fimd

This patch uses the mode passed into mode_set to configure fimd instead of directly using the panel from context. This will allow us to move the exynos_drm_display implementation from fimd into the DP driver where it belongs. Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None

[PATCH v3 18/32] drm/exynos: Implement mode_fixup manager operation

This patch adds a new manager callback for mode_fixup and pipes it through exynos_drm_crtc. Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None drivers/gpu/drm/exynos/exynos_drm_crtc.c | 7 ++- drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 2 files changed, 10

[PATCH v3 17/32] drm/exynos: Add mode_set manager operation

This patch adds a mode_set callback to the manager operations which sets the crtc's current mode to the manager driver. Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 +++ 2

[PATCH v3 16/32] drm/exynos: Disable unused crtc planes from crtc

This patch moves the code which disables unused crtc planes from the encoder to the crtc. Since there is a 1:1 encoder/crtc mapping in exynos, the only valid crtc change the pre-existing code could catch is disconnecting an active crtc from the encoder. Thus it is functionally equivalent to just

[PATCH v3 15/32] drm/exynos: Use drm_mode_copy to copy modes

This patch changes the manual copying of mode to adjusted_mode in mode_fixup to use drm_mode_copy instead of handling things manually. Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +- 1 file changed, 1 insertion(+), 9

[PATCH v3 14/32] drm/exynos: Remove exynos_drm_hdmi shim

This patch trims exynos_drm_hdmi out of the driver. The reason it existed in the first place was to make up for the mixture of display/overlay/manager ops being spread across hdmi and mixer. With that code now rationalized, mixer and hdmi map directly to exynos_drm_crtc and exynos_drm_encoder,

[PATCH v3 13/32] drm/exynos: hdmi: remove the i2c drivers and use devtree

From: Daniel Kurtz The i2c client was previously being passed into the hdmi driver via a dedicated i2c driver, and then a global variable. This patch removes all of that and just uses the device tree to get the i2c_client. This patch also properly references the client so

[PATCH v3 12/32] drm/exynos: Split manager/display/subdrv

This patch splits display and manager from subdrv. The result is that crtc functions can directly call into manager callbacks and encoder functions can directly call into display callbacks. This will allow us to remove the exynos_drm_hdmi shim and support mixer/hdmi & fimd/dp with common code.

[PATCH v3 11/32] drm/exynos: Use unsigned long for possible_crtcs

Change all instances of possible_crtcs in the exynos drm driver to be unsigned long. This matches the type used in the drm layer. Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-

[PATCH v3 10/32] drm/exynos: Don't keep dpms state in encoder

This patch removes the dpms state tracking in encoder. This state is at best confusing and at worst incorrect since the display drivers can turn on and off without propagating the value. Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None

[PATCH v3 09/32] drm/exynos: Rename display_op power_on to dpms

This patch renames the display_op power_on to dpms to accurately reflect what the function does. The side-effect of this patch is that the new hdmi dpms callback is now invoked twice in the dpms path. This is safe and will be dealt with when the exynos_drm shim goes away. Signed-off-by: Sean

[PATCH v3 08/32] drm/exynos: Remove dpms link between encoder/connector

This patch removes the call from encoder dpms into connector dpms (which will then call back into encoder dpms through the helper function). The callback is likely to keep connector->dpms in the right state when initiating dpms from crtc or encoder, but this isn't the right way to do it. This

[PATCH v3 07/32] drm/exynos: Remove apply manager callback

This patch removes the apply() manager callback in favor of putting the relevant commits in the individual drivers. This will mitigate some of the difference between the suspend/resume path and the dpms path Signed-off-by: Sean Paul --- Changes in v2: - This was previously in another

[PATCH v3 06/32] drm/exynos: Pass exynos_drm_manager in manager ops instead of dev

This patch changes the manager ops callbacks from accepting the subdrv device pointer to taking a pointer to the manager. This will allow us to move closer to decoupling manager/display from subdrv, and subsequently decoupling the crtc/plane from the encoder. Signed-off-by: Sean Paul ---

[PATCH v3 05/32] drm/exynos: hdmi: Implement initialize op for hdmi

This patch implements the initialize callback in the hdmi and mixer manager. This allows us to get rid of drm_dev in the drm_hdmi level and track it in the mixer and hdmi drivers. This is one of the things holding back the complete removal of the drm_hdmi layer. Signed-off-by: Sean Paul ---

[PATCH v3 04/32] drm/exynos: Use manager_op initialize in fimd

This patch implements the intitialize manager op in fimd. Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git

[PATCH v3 03/32] drm/exynos: Add an initialize function to manager and display

This patch adds an initialize function to the manager and display operations. This allows them to keep track of drm_device in their local context, as well as adds an initialization hook right after the encoder is created. Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None

[PATCH v3 02/32] drm/exynos: Merge overlay_ops into manager_ops

This patch merges overlay_ops into manager_ops. In all cases, overlay_ops is implemented in the same place as manager ops, it doesn't serve a functional purpose, and doesn't make things more clear. Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None

[PATCH v3 01/32] drm/exynos: Remove useless slab.h include

From: St?phane Marchesin Signed-off-by: St?phane Marchesin Signed-off-by: Sean Paul --- Changes in v2: None Changes in v3: None drivers/video/exynos/exynos_dp_core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/exynos/exynos_dp_core.c

[PATCH v3 00/32] drm/exynos: Refactor parts of the exynos driver

This patchset refactors parts of the exynos driver to move it closer to a proper drm driver (rather than just implementing a drm layer on top of the hardware drivers). The hope is to get to a point where the dp/hdmi drivers can implement drm_connector/drm_encoder directly, and fimd/mixer can

  1   2   >