[PATCH V4] drm/exynos: fimd: calculate the correct address offset

[Leela Krishna Amudala]

Calculate the correct address offset values for alpha and color key
control registers based on exynos4 and exynos5 user manuals.
Also remove VIDOSD_C_SIZE_W0 macro and fix comments about registers for
size and alpha.

Signed-off-by: Leela Krishna Amudala 
Acked-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..f5f2b25 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -38,11 +38,12 @@
 /* position control register for hardware window 0, 2 ~ 4.*/
 #define VIDOSD_A(win)  (VIDOSD_BASE + 0x00 + (win) * 16)
 #define VIDOSD_B(win)  (VIDOSD_BASE + 0x04 + (win) * 16)
-/* size control register for hardware window 0. */
-#define VIDOSD_C_SIZE_W0   (VIDOSD_BASE + 0x08)
-/* alpha control register for hardware window 1 ~ 4. */
-#define VIDOSD_C(win)  (VIDOSD_BASE + 0x18 + (win) * 16)
-/* size control register for hardware window 1 ~ 4. */
+/*
+ * size control register for hardware windows 0 and alpha control register
+ * for hardware windows 1 ~ 4
+ */
+#define VIDOSD_C(win)  (VIDOSD_BASE + 0x08 + (win) * 16)
+/* size control register for hardware windows 1 ~ 2. */
 #define VIDOSD_D(win)  (VIDOSD_BASE + 0x0C + (win) * 16)

 #define VIDWx_BUF_START(win, buf)  (VIDW_BUF_START(buf) + (win) * 8)
@@ -50,9 +51,9 @@
 #define VIDWx_BUF_SIZE(win, buf)   (VIDW_BUF_SIZE(buf) + (win) * 4)

 /* color key control register for hardware window 1 ~ 4. */
-#define WKEYCON0_BASE(x)   ((WKEYCON0 + 0x140) + (x * 8))
+#define WKEYCON0_BASE(x)   ((WKEYCON0 + 0x140) + ((x - 1) * 8))
 /* color key value register for hardware window 1 ~ 4. */
-#define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + (x * 8))
+#define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + ((x - 1) * 8))

 /* FIMD has totally five hardware windows. */
 #define WINDOWS_NR 5
@@ -581,7 +582,7 @@ static void fimd_win_commit(struct device *dev, int zpos)
if (win != 3 && win != 4) {
u32 offset = VIDOSD_D(win);
if (win == 0)
-   offset = VIDOSD_C_SIZE_W0;
+   offset = VIDOSD_C(win);
val = win_data->ovl_width * win_data->ovl_height;
writel(val, ctx->regs + offset);

-- 
1.8.0

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

misc radeon, nouveau, mgag200 and intel fixes,

the intel fixes should contain the fix for the touchpad on the Chromebook 
- hey I'm an input maintainer now!

Dave.

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

  Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-fixes

for you to fetch changes up to 36c1813bb453dd078e49bc5b3c1bf7d13535d9ff:

  drm/tegra: drop "select DRM_HDMI" (2013-03-08 08:36:01 +1000)


Alex Deucher (3):
  drm/radeon: don't set hpd, afmt interrupts when interrupts are disabled
  drm/radeon: add primary dac adj quirk for R200 board
  drm/radeon: skip MC reset as it's probably not hung

Ben Skeggs (4):
  drm/nve0/graph: some random reg moved on kepler
  drm/nv84: fix regression in page flipping
  drm/nouveau/i2c: drop parent refcount when creating ports
  drm/nv50-: prevent some races between modesetting and page flipping

Christopher Harvey (3):
  drm/mgag200: 'fbdev_list' in 'struct mga_fbdev' is not used
  drm/mgag200: Reject modes that are too big for VRAM
  drm: Documentation typo fixes

Daniel Vetter (1):
  drm/i915: enable irqs earlier when resuming

Dave Airlie (3):
  Merge branch 'drm-nouveau-fixes-3.9' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next
  Merge branch 'drm-fixes-3.9' of git://people.freedesktop.org/~agd5f/linux 
into drm-next

Egbert Eich (1):
  DRM/i915: On G45 enable cursor plane briefly after enabling the display 
plane.

Francisco Jerez (2):
  drm/nouveau: Disable AGP on PowerPC again.
  drm/nouveau: Fix typo in init_idx_addr_latched().

Julia Lemire (1):
  drm/mgag200: Bug fix: Renesas board now selects native resolution.

Kenneth Graunke (1):
  drm/i915: Fix Haswell/CRW PCI IDs.

Marek Ol??k (1):
  drm/radeon: don't check mipmap alignment if MIP_ADDRESS is FMASK

Patrik Jakobsson (2):
  drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bits
  drm/i915: Turn off hsync and vsync on ADPA when disabling crt

Paul Bolle (1):
  drm/tegra: drop "select DRM_HDMI"

Paulo Zanoni (2):
  drm/i915: wait_event_timeout's timeout is in jiffies
  drm/i915: also disable south interrupts when handling them

St?phane Marchesin (1):
  drm/i915: Increase the RC6p threshold.

Syam Sidhardhan (1):
  drm/i915: Fix missing variable initilization

Ville Syrj?l? (1):
  drm/i915: Don't clobber crtc->fb when queue_flip fails

 drivers/gpu/drm/i915/i915_drv.c  |  25 +++-
 drivers/gpu/drm/i915/i915_irq.c  |  26 +++-
 drivers/gpu/drm/i915/i915_reg.h  |   4 +-
 drivers/gpu/drm/i915/intel_crt.c |   2 +-
 drivers/gpu/drm/i915/intel_ddi.c |   2 +-
 drivers/gpu/drm/i915/intel_display.c |  37 -
 drivers/gpu/drm/i915/intel_dp.c  |   3 +-
 drivers/gpu/drm/i915/intel_pm.c  |   2 +-
 drivers/gpu/drm/mgag200/mgag200_drv.h|   1 -
 drivers/gpu/drm/mgag200/mgag200_i2c.c|   1 +
 drivers/gpu/drm/mgag200/mgag200_mode.c   |  27 
 drivers/gpu/drm/nouveau/core/engine/graph/nve0.c |   2 +-
 drivers/gpu/drm/nouveau/core/subdev/bios/init.c  |   2 +-
 drivers/gpu/drm/nouveau/core/subdev/i2c/base.c   |   1 +
 drivers/gpu/drm/nouveau/nouveau_agp.c|  12 ++
 drivers/gpu/drm/nouveau/nv50_display.c   | 173 +--
 drivers/gpu/drm/radeon/evergreen.c   |   6 +
 drivers/gpu/drm/radeon/evergreen_cs.c|   2 +-
 drivers/gpu/drm/radeon/ni.c  |   6 +
 drivers/gpu/drm/radeon/r600.c|   6 +
 drivers/gpu/drm/radeon/radeon_combios.c  |   9 ++
 drivers/gpu/drm/radeon/radeon_drv.c  |   3 +-
 drivers/gpu/drm/radeon/radeon_irq_kms.c  |  12 ++
 drivers/gpu/drm/radeon/si.c  |   6 +
 drivers/gpu/drm/tegra/Kconfig|   1 -
 include/drm/drm_crtc.h   |   6 +-
 26 files changed, 275 insertions(+), 102 deletions(-)

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[H. Peter Anvin]

On 03/07/2013 09:28 PM, Tejun Heo wrote:
> On Thu, Mar 7, 2013 at 9:27 PM, Yinghai Lu  wrote:
>> They are not using memblock_find_in_range(), so 1ULL<< will not help.
>>
>> Really hope i915 drm guys could clean that hacks.
> 
> The code isn't being used.  Just leave it alone.  Maybe add a comment.
>  The change is just making things more confusing.
> 

Indeed, but...

Daniel: can you guys clean this up or can we just remove the #if 0 clause?

-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

[Bug 58042] [bisected] Garbled UI in Team Fortress 2 and Counter-Strike: Source

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=58042

dev at stuffit.at changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #32 from dev at stuffit.at ---
Tested and works for me!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130307/e0d3a38a/attachment.html>

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Tejun Heo]

On Thu, Mar 7, 2013 at 9:27 PM, Yinghai Lu  wrote:
> They are not using memblock_find_in_range(), so 1ULL<< will not help.
>
> Really hope i915 drm guys could clean that hacks.

The code isn't being used.  Just leave it alone.  Maybe add a comment.
 The change is just making things more confusing.

-- 
tejun

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

On Thu, Mar 7, 2013 at 9:25 PM, Tejun Heo  wrote:
> On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu  wrote:
>> On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo  wrote:
>>> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index 69d97cb..7f9380b 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
 drm_device *dev)
   base -= dev_priv->mm.gtt->stolen_size;
   } else {
   /* Stolen is immediately above Top of Memory */
 - base = max_low_pfn_mapped << PAGE_SHIFT;
 + base = __REMOVED_CRAZY__ << PAGE_SHIFT;
>>>
>>> Huh?
>>
>> Whole function:
>
> Yeah, but can't we still just do 1LLU << 32 like other places? Or at
> least explain what was there before? It's gonna confuse the hell out
> of future readers of the code.

They are not using memblock_find_in_range(), so 1ULL<< will not help.

Really hope i915 drm guys could clean that hacks.

Thanks

Yinghai

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Tejun Heo]

On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu  wrote:
> On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo  wrote:
>> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
>>> b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>> index 69d97cb..7f9380b 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>> @@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
>>> drm_device *dev)
>>>   base -= dev_priv->mm.gtt->stolen_size;
>>>   } else {
>>>   /* Stolen is immediately above Top of Memory */
>>> - base = max_low_pfn_mapped << PAGE_SHIFT;
>>> + base = __REMOVED_CRAZY__ << PAGE_SHIFT;
>>
>> Huh?
>
> Whole function:

Yeah, but can't we still just do 1LLU << 32 like other places? Or at
least explain what was there before? It's gonna confuse the hell out
of future readers of the code.

-- 
tejun

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo  wrote:
> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
>> b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> index 69d97cb..7f9380b 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> @@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
>> drm_device *dev)
>>   base -= dev_priv->mm.gtt->stolen_size;
>>   } else {
>>   /* Stolen is immediately above Top of Memory */
>> - base = max_low_pfn_mapped << PAGE_SHIFT;
>> + base = __REMOVED_CRAZY__ << PAGE_SHIFT;
>
> Huh?

Whole function:

static unsigned long i915_stolen_to_physical(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct pci_dev *pdev = dev_priv->bridge_dev;
u32 base;

/* On the machines I have tested the Graphics Base of Stolen Memory
 * is unreliable, so on those compute the base by subtracting the
 * stolen memory from the Top of Low Usable DRAM which is where the
 * BIOS places the graphics stolen memory.
 *
 * On gen2, the layout is slightly different with the Graphics Segment
 * immediately following Top of Memory (or Top of Usable DRAM). Note
 * it appears that TOUD is only reported by 865g, so we just use the
 * top of memory as determined by the e820 probe.
 *
 * XXX gen2 requires an unavailable symbol and 945gm fails with
 * its value of TOLUD.
 */
base = 0;
if (INTEL_INFO(dev)->gen >= 6) {
/* Read Base Data of Stolen Memory Register (BDSM) directly.
 * Note that there is also a MCHBAR miror at 0x1080c0 or
 * we could use device 2:0x5c instead.
*/
pci_read_config_dword(pdev, 0xB0, );
base &= ~4095; /* lower bits used for locking register */
} else if (INTEL_INFO(dev)->gen > 3 || IS_G33(dev)) {
/* Read Graphics Base of Stolen Memory directly */
pci_read_config_dword(pdev, 0xA4, );
#if 0
} else if (IS_GEN3(dev)) {
u8 val;
/* Stolen is immediately below Top of Low Usable DRAM */
pci_read_config_byte(pdev, 0x9c, );
base = val >> 3 << 27;
base -= dev_priv->mm.gtt->stolen_size;
} else {
/* Stolen is immediately above Top of Memory */
base = __REMOVED_CRAZY__ << PAGE_SHIFT;
#endif
}

return base;
}

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Tejun Heo]

On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 69d97cb..7f9380b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
> drm_device *dev)
>   base -= dev_priv->mm.gtt->stolen_size;
>   } else {
>   /* Stolen is immediately above Top of Memory */
> - base = max_low_pfn_mapped << PAGE_SHIFT;
> + base = __REMOVED_CRAZY__ << PAGE_SHIFT;

Huh?

-- 
tejun

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not
be used anymore.

Only user is ACPI_OVERRIDE, and it should not use that, as later
accessing is using early_remap. Change to try to 4G below and
then 4G above.

Other user is in drm/i915, but it is commented out.

Should use arch_pfn_mapped or just 1<<(32-PAGE_SHIFT) instead.

Suggested-by: H. Peter Anvin 
Signed-off-by: Yinghai Lu 
Cc: Thomas Renninger 
Cc: "Rafael J. Wysocki" 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Jacob Shin 
Cc: linux-acpi at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
---
 arch/x86/include/asm/page_types.h  |1 -
 arch/x86/kernel/setup.c|4 +---
 arch/x86/mm/init.c |4 
 drivers/acpi/osl.c |9 ++---
 drivers/gpu/drm/i915/i915_gem_stolen.c |2 +-
 5 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/page_types.h 
b/arch/x86/include/asm/page_types.h
index 54c9787..b012b82 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -43,7 +43,6 @@

 extern int devmem_is_allowed(unsigned long pagenr);

-extern unsigned long max_low_pfn_mapped;
 extern unsigned long max_pfn_mapped;

 static inline phys_addr_t get_max_mapped(void)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 90d8cc9..4dcaae7 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -113,13 +113,11 @@
 #include 

 /*
- * max_low_pfn_mapped: highest direct mapped pfn under 4GB
- * max_pfn_mapped: highest direct mapped pfn over 4GB
+ * max_pfn_mapped: highest direct mapped pfn
  *
  * The direct mapping only covers E820_RAM regions, so the ranges and gaps are
  * represented by pfn_mapped
  */
-unsigned long max_low_pfn_mapped;
 unsigned long max_pfn_mapped;

 #ifdef CONFIG_DMI
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 59b7fc4..abcc241 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -313,10 +313,6 @@ static void add_pfn_range_mapped(unsigned long start_pfn, 
unsigned long end_pfn)
nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);

max_pfn_mapped = max(max_pfn_mapped, end_pfn);
-
-   if (start_pfn < (1UL<<(32-PAGE_SHIFT)))
-   max_low_pfn_mapped = max(max_low_pfn_mapped,
-min(end_pfn, 1UL<<(32-PAGE_SHIFT)));
 }

 bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 586e7e9..c9e36d7 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -624,9 +624,12 @@ void __init acpi_initrd_override(void *data, size_t size)
if (table_nr == 0)
return;

-   acpi_tables_addr =
-   memblock_find_in_range(0, max_low_pfn_mapped << PAGE_SHIFT,
-  all_tables_size, PAGE_SIZE);
+   /* under 4G at first, then above 4G */
+   acpi_tables_addr = memblock_find_in_range(0, 1ULL<<32,
+   all_tables_size, PAGE_SIZE);
+   if (!acpi_tables_addr)
+   acpi_tables_addr = memblock_find_in_range(1ULL<<32, -1ULL,
+   all_tables_size, PAGE_SIZE);
if (!acpi_tables_addr) {
WARN_ON(1);
return;
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 69d97cb..7f9380b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
drm_device *dev)
base -= dev_priv->mm.gtt->stolen_size;
} else {
/* Stolen is immediately above Top of Memory */
-   base = max_low_pfn_mapped << PAGE_SHIFT;
+   base = __REMOVED_CRAZY__ << PAGE_SHIFT;
 #endif
}

-- 
1.7.10.4

[Bug 61979] backlight adjustment doesn't work on HP Pavilion m6-1035dx

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61979

Alex Deucher  changed:

   What|Removed |Added

   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
 QA Contact|xorg-team at lists.x.org   |
Product|xorg|DRI
  Component|Driver/Radeon   |DRM/Radeon

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130307/c95adb66/attachment.html>

[PATCH] drm: call drm_device_set_unplugged in drm_put_dev

[Maarten Lankhorst]

This prevents the device from being reopened after drm_put_dev is called.

Signed-off-by: Maarten Lankhorst driver;

+   drm_device_set_unplugged(dev);
+
drm_lastclose(dev);

if (drm_core_has_MTRR(dev) && drm_core_has_AGP(dev) &&
@@ -499,11 +501,10 @@ void drm_unplug_dev(struct drm_device *dev)

mutex_lock(_global_mutex);

-   drm_device_set_unplugged(dev);
-
-   if (dev->open_count == 0) {
+   if (dev->open_count)
+   drm_device_set_unplugged(dev);
+   else
drm_put_dev(dev);
-   }
mutex_unlock(_global_mutex);
 }
 EXPORT_SYMBOL(drm_unplug_dev);

[PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver

[Inki Dae]

> -Original Message-
> From: ??? [mailto:sw0312.kim at samsung.com]
> Sent: Thursday, March 07, 2013 4:04 PM
> To: Rahul Sharma
> Cc: Inki Dae; linux-samsung-soc at vger.kernel.org; Sean Paul; sunil joshi;
> dri-devel at lists.freedesktop.org; Rahul Sharma; sw0312.kim at samsung.com
> Subject: Re: [PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to
> hdmiphy driver
> 
> 
> 
> On 2013? 03? 07? 15:45, Rahul Sharma wrote:
> > Thanks Seung Woo, Mr. Dae,
> >
> > On Thu, Mar 7, 2013 at 10:13 AM, Inki Dae  wrote:
> >> 2013/3/7 ??? :
> >>>
> >>>
> >>> On 2013? 03? 04? 23:05, Rahul Sharma wrote:
>  Thanks Sean,
> 
>  On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul 
> wrote:
> > On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma
>  wrote:
> >> Right now hdmiphy operations and configs are kept inside hdmi
> driver. hdmiphy related
> >> code is tightly coupled with hdmi ip driver. Physicaly they are
> different devices and
> >
> > s/Physicaly/Physically/
> >
> >> should be instantiated independently.
> >>
> >> In terms of versions/mapping/configurations Hdmi and hdmiphy are
> independent of each
> >> other. It is preferred to isolate them and maintained
independently.
> >>
> >> This implementations is tested for:
> >> 1) Resolutions supported by exynos4 and 5 hdmi.
> >> 2) Runtime PM and S2R scenarions for exynos5.
> >>
> >
> > I don't like the idea of spawning off yet another driver in here. It
> > adds more globals, more suspend/resume ordering issues, and more
> > implicit dependencies. I understand, however, that this is the
> Chosen
> > Way for the exynos driver, so I will save my rant.
> >
> 
>  I agree to it. splitting phy to a new driver will complicate the
> power related
>  scenarios. But in upcoming SoC,s, Phy is changing considerably in
> terms of
>  config values, mapping (i2c/platform bus) etc. Handling this
> diversity
>  inside hdmi driver is complicating it with unrelated changes.
> >>>
> >>> Basically, I agree with the idea to split hdmiphy from hdmi. And it
> >>> seems that already existing hdmiphy i2c device is just reused and
> >>> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even
> calling
> >>> flow of power operations is reordered.
> >>>
> >>> But I'm not sure exynos_hdmiphy_driver_register() really need to be
> >>> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough
> to
> >>> call exynos_hdmiphy_driver_register() from hdmi_probe() because
> hdmiphy
> >>> is only used from hdmi.
> >>>
> >>
> >> I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem.
> >>
> >
> > I agree to the Seung Woo's point that hdmi-phy used to be solely
> accessed by
> > hdmi driver.  But in this RFC, hdmi-phy is not called by hdmi driver
> > anymore. Phy
> > ops will be called from drm-common-hdmi platform driver along with mixer
> and
> > hdmi ops.
> 
> Considering this, exynos_drm_hdmi_probe() is more proper position.
> 
> >
> > The rational behind my implementation is that I am projecting hdmi-phy
> as
> > a device which is peer to hdmi ip and mixer. These 3 devices together
> makes
> > DRM HDMI subsystem.
> >
> > Even physically hdmi-phy doesn't seems to be a part of hdmi ip though
> > configurations are listed under hdmi ip user manual. It looks like a
> > isolated module accessed by i2c.
> >
> > Though I don't find anything wrong with Seung Woo suggestion but above
> > placement of hdmi-phy (parallel to hdmi and mixer) makes more sense
> > to me.
> >
> > Please have a another look at it and let me know your opinion.
> >
> > Another things which bothers me is registering mixer, hdmi driver inside
> > exynos_drm_init(). If we strictly follow the hierarchy inside drm,
> > exynos_drm_init()
> > should register drm-common-hdmi only. drm-common-hdmi should register
> > mixer and hdmi (or hdmi-phy as well).
> 
> Yes, it makes sense. All real hw blocks for hdmi including mixer, hdmi,
> and hdmiphy shoulde be registered in exynos_drm_hdmi (drm-common-hdmi
> for exynos).
> 

Ideally, right. But the reason I designed and implemented hdmi subsystem
framework like this, is that there was one issue that
platform_device_register() can't be called at probe(). On other words, when
one platform device driver is being probed, anyone can't be probed. Anyway,
existing way needs to be improved. So let's find better way and improve the
hdmi subsystem framework this time. :)

Thanks,
Inki Dae

> Thanks and Regards,
> - Seung-Woo Kim
> 
> >
> > regards,
> > Rahul Sharma.
> >
> >> Thanks,
> >> Inki Dae
> >>
> >>> Thanks and Regards,
> >>> - Seung-Woo Kim
> >>>
> 
>  I have tested this RFC for Runtime PM / S2R. But if we see any major
> roadblock
>  we should re-factor this by explicitly calling power related
> callbacks
>  of mixer, phy,
>  hdmi drivers in a required order. We can call them from exynos-drm-
> hdmi plf
>  device. AFAIR something 

[PATCH v12 2/2] drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm fimd

[Inki Dae]

> -Original Message-
> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
> owner at vger.kernel.org] On Behalf Of Vikas Sajjan
> Sent: Thursday, March 07, 2013 4:40 PM
> To: dri-devel at lists.freedesktop.org
> Cc: linux-media at vger.kernel.org; kgene.kim at samsung.com;
> inki.dae at samsung.com; l.krishna at samsung.com; joshi at samsung.com; 
> linaro-
> kernel at lists.linaro.org
> Subject: [PATCH v12 2/2] drm/exynos: enable OF_VIDEOMODE and
> FB_MODE_HELPERS for exynos drm fimd
> 
> patch adds "select OF_VIDEOMODE" and "select FB_MODE_HELPERS" when
> EXYNOS_DRM_FIMD config is selected.
> 
> Signed-off-by: Vikas Sajjan 
> ---
>  drivers/gpu/drm/exynos/Kconfig |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/Kconfig
> b/drivers/gpu/drm/exynos/Kconfig
> index 046bcda..bb25130 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -25,6 +25,8 @@ config DRM_EXYNOS_DMABUF
>  config DRM_EXYNOS_FIMD
>   bool "Exynos DRM FIMD"
>   depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM

Again, you missed 'OF' dependency. At least, let's have build testing surely
before posting :)

Thanks,
Inki Dae

> + select OF_VIDEOMODE
> + select FB_MODE_HELPERS
>   help
> Choose this option if you want to use Exynos FIMD for DRM.
> 
> --
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Wrong vsync offset calculation in drm_edid.c

[Peter Blum]

This patch is a bug fix for the file drm_edid.c of the kernel 3.8.

The vsync offset is calculated wrong from the EDID set because of the 
wrong shift direction.
We could measure the bad old setting and also the good new setting after 
the bug fix.


Signed-off-by: Peter Blum 


diff -Naur a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
--- a/drivers/gpu/drm/drm_edid.c2013-02-19 00:58:34.0 +0100
+++ b/drivers/gpu/drm/drm_edid.c2013-03-07 12:04:24.527609783 +0100
@@ -893,7 +893,7 @@
 unsigned vblank = (pt->vactive_vblank_hi & 0xf) << 8 | 
pt->vblank_lo;
 unsigned hsync_offset = (pt->hsync_vsync_offset_pulse_width_hi 
& 0xc0) << 2 | pt->hsync_offset_lo;
 unsigned hsync_pulse_width = 
(pt->hsync_vsync_offset_pulse_width_hi & 0x30) << 4 | 
pt->hsync_pulse_width_lo;
-   unsigned vsync_offset = (pt->hsync_vsync_offset_pulse_width_hi & 
0xc) >> 2 | pt->vsync_offset_pulse_width_lo >> 4;
+   unsigned vsync_offset = (pt->hsync_vsync_offset_pulse_width_hi & 
0xc) << 2 | pt->vsync_offset_pulse_width_lo >> 4;
 unsigned vsync_pulse_width = 
(pt->hsync_vsync_offset_pulse_width_hi & 0x3) << 4 | 
(pt->vsync_offset_pulse_width_lo & 0xf);

 /* ignore tiny modes */

[PATCH] drm/exynos: modify the compatible string for exynos fimd

[Inki Dae]

Already merged. :)

> -Original Message-
> From: Vikas Sajjan [mailto:vikas.sajjan at linaro.org]
> Sent: Thursday, March 07, 2013 4:09 PM
> To: InKi Dae
> Cc: dri-devel at lists.freedesktop.org; linux-media at vger.kernel.org;
> kgene.kim at samsung.com; Joonyoung Shim; sunil joshi
> Subject: Re: [PATCH] drm/exynos: modify the compatible string for exynos
> fimd
> 
> Hi Mr Inki Dae,
> 
> On 28 February 2013 08:12, Joonyoung Shim  wrote:
> > On 02/27/2013 07:32 PM, Vikas Sajjan wrote:
> >>
> >> modified compatible string for exynos4 fimd as "exynos4210-fimd" and
> >> exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible
> >> value should be named after first specific SoC model in which this
> >> particular IP version was included as discussed at
> >> https://patchwork.kernel.org/patch/2144861/
> >>
> >> Signed-off-by: Vikas Sajjan 
> >> ---
> >>   drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 ++--
> >>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >> index 9537761..433ed35 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >> @@ -109,9 +109,9 @@ struct fimd_context {
> >> #ifdef CONFIG_OF
> >>   static const struct of_device_id fimd_driver_dt_match[] = {
> >> -   { .compatible = "samsung,exynos4-fimd",
> >> +   { .compatible = "samsung,exynos4210-fimd",
> >>   .data = _fimd_driver_data },
> >> -   { .compatible = "samsung,exynos5-fimd",
> >> +   { .compatible = "samsung,exynos5250-fimd",
> >>   .data = _fimd_driver_data },
> >> {},
> >>   };
> >
> >
> > Acked-by: Joonyoung Shim 
> 
> Can you please apply this patch.
> 
> >
> > Thanks.
> 
> 
> 
> --
> Thanks and Regards
>  Vikas Sajjan

[PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver

[김승우]

On 2013? 03? 07? 15:45, Rahul Sharma wrote:
> Thanks Seung Woo, Mr. Dae,
> 
> On Thu, Mar 7, 2013 at 10:13 AM, Inki Dae  wrote:
>> 2013/3/7 ??? :
>>>
>>>
>>> On 2013? 03? 04? 23:05, Rahul Sharma wrote:
 Thanks Sean,

 On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul  wrote:
> On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma  samsung.com> wrote:
>> Right now hdmiphy operations and configs are kept inside hdmi driver. 
>> hdmiphy related
>> code is tightly coupled with hdmi ip driver. Physicaly they are 
>> different devices and
>
> s/Physicaly/Physically/
>
>> should be instantiated independently.
>>
>> In terms of versions/mapping/configurations Hdmi and hdmiphy are 
>> independent of each
>> other. It is preferred to isolate them and maintained independently.
>>
>> This implementations is tested for:
>> 1) Resolutions supported by exynos4 and 5 hdmi.
>> 2) Runtime PM and S2R scenarions for exynos5.
>>
>
> I don't like the idea of spawning off yet another driver in here. It
> adds more globals, more suspend/resume ordering issues, and more
> implicit dependencies. I understand, however, that this is the Chosen
> Way for the exynos driver, so I will save my rant.
>

 I agree to it. splitting phy to a new driver will complicate the power 
 related
 scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of
 config values, mapping (i2c/platform bus) etc. Handling this diversity
 inside hdmi driver is complicating it with unrelated changes.
>>>
>>> Basically, I agree with the idea to split hdmiphy from hdmi. And it
>>> seems that already existing hdmiphy i2c device is just reused and
>>> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling
>>> flow of power operations is reordered.
>>>
>>> But I'm not sure exynos_hdmiphy_driver_register() really need to be
>>> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to
>>> call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy
>>> is only used from hdmi.
>>>
>>
>> I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem.
>>
> 
> I agree to the Seung Woo's point that hdmi-phy used to be solely accessed by
> hdmi driver.  But in this RFC, hdmi-phy is not called by hdmi driver
> anymore. Phy
> ops will be called from drm-common-hdmi platform driver along with mixer and
> hdmi ops.

Considering this, exynos_drm_hdmi_probe() is more proper position.

> 
> The rational behind my implementation is that I am projecting hdmi-phy as
> a device which is peer to hdmi ip and mixer. These 3 devices together makes
> DRM HDMI subsystem.
> 
> Even physically hdmi-phy doesn't seems to be a part of hdmi ip though
> configurations are listed under hdmi ip user manual. It looks like a
> isolated module accessed by i2c.
> 
> Though I don't find anything wrong with Seung Woo suggestion but above
> placement of hdmi-phy (parallel to hdmi and mixer) makes more sense
> to me.
> 
> Please have a another look at it and let me know your opinion.
> 
> Another things which bothers me is registering mixer, hdmi driver inside
> exynos_drm_init(). If we strictly follow the hierarchy inside drm,
> exynos_drm_init()
> should register drm-common-hdmi only. drm-common-hdmi should register
> mixer and hdmi (or hdmi-phy as well).

Yes, it makes sense. All real hw blocks for hdmi including mixer, hdmi,
and hdmiphy shoulde be registered in exynos_drm_hdmi (drm-common-hdmi
for exynos).

Thanks and Regards,
- Seung-Woo Kim

> 
> regards,
> Rahul Sharma.
> 
>> Thanks,
>> Inki Dae
>>
>>> Thanks and Regards,
>>> - Seung-Woo Kim
>>>

 I have tested this RFC for Runtime PM / S2R. But if we see any major 
 roadblock
 we should re-factor this by explicitly calling power related callbacks
 of mixer, phy,
 hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf
 device. AFAIR something like this is already in place in chrome-kernel.

> I've made some comments below.
>
>> This patch is dependent on
>> http://www.mail-archive.com/dri-devel at 
>> lists.freedesktop.org/msg34733.html
>> http://www.mail-archive.com/dri-devel at 
>> lists.freedesktop.org/msg34861.html
>> http://www.mail-archive.com/dri-devel at 
>> lists.freedesktop.org/msg34862.html
>>
>> Signed-off-by: Rahul Sharma 
>> ---
>> It is based on exynos-drm-next-todo branch at
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   8 +
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   6 +
>>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c |  58 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  11 +
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++--
>>  drivers/gpu/drm/exynos/exynos_hdmi.h |   1 -
>>  

[PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver

[Rahul Sharma]

On Thu, Mar 7, 2013 at 12:37 PM, St?phane Marchesin
 wrote:
> On Wed, Mar 6, 2013 at 8:43 PM, Inki Dae  wrote:
>> 2013/3/7 ??? :
>>>
>>>
>>> On 2013? 03? 04? 23:05, Rahul Sharma wrote:
 Thanks Sean,

 On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul  wrote:
> On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma  samsung.com> wrote:
>> Right now hdmiphy operations and configs are kept inside hdmi driver. 
>> hdmiphy related
>> code is tightly coupled with hdmi ip driver. Physicaly they are 
>> different devices and
>
> s/Physicaly/Physically/
>
>> should be instantiated independently.
>>
>> In terms of versions/mapping/configurations Hdmi and hdmiphy are 
>> independent of each
>> other. It is preferred to isolate them and maintained independently.
>>
>> This implementations is tested for:
>> 1) Resolutions supported by exynos4 and 5 hdmi.
>> 2) Runtime PM and S2R scenarions for exynos5.
>>
>
> I don't like the idea of spawning off yet another driver in here. It
> adds more globals, more suspend/resume ordering issues, and more
> implicit dependencies. I understand, however, that this is the Chosen
> Way for the exynos driver, so I will save my rant.
>

 I agree to it. splitting phy to a new driver will complicate the power 
 related
 scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of
 config values, mapping (i2c/platform bus) etc. Handling this diversity
 inside hdmi driver is complicating it with unrelated changes.
>>>
>>> Basically, I agree with the idea to split hdmiphy from hdmi. And it
>>> seems that already existing hdmiphy i2c device is just reused and
>>> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling
>>> flow of power operations is reordered.
>>>
>>> But I'm not sure exynos_hdmiphy_driver_register() really need to be
>>> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to
>>> call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy
>>> is only used from hdmi.
>>>
>>
>> I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem.
>>
>
> But this is probably going to break dpms and/or suspend/resume
> functionality. Has that been tested?
>
> St?phane
>
Hi St?phane

This has been tested for dpms and suspend/resume scenarios for exynos5. I
have yet to try with hdmi, mixer, phy driver registration moved to
common-drm-hdmi.

regards,
Rahul Sharma.

>> Thanks,
>> Inki Dae
>>
>>> Thanks and Regards,
>>> - Seung-Woo Kim
>>>

 I have tested this RFC for Runtime PM / S2R. But if we see any major 
 roadblock
 we should re-factor this by explicitly calling power related callbacks
 of mixer, phy,
 hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf
 device. AFAIR something like this is already in place in chrome-kernel.

> I've made some comments below.
>
>> This patch is dependent on
>> http://www.mail-archive.com/dri-devel at 
>> lists.freedesktop.org/msg34733.html
>> http://www.mail-archive.com/dri-devel at 
>> lists.freedesktop.org/msg34861.html
>> http://www.mail-archive.com/dri-devel at 
>> lists.freedesktop.org/msg34862.html
>>
>> Signed-off-by: Rahul Sharma 
>> ---
>> It is based on exynos-drm-next-todo branch at
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   8 +
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   6 +
>>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c |  58 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  11 +
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++--
>>  drivers/gpu/drm/exynos/exynos_hdmi.h |   1 -
>>  drivers/gpu/drm/exynos/exynos_hdmiphy.c  | 586 
>> ++-
>>  drivers/gpu/drm/exynos/regs-hdmiphy.h|  61 
>>  8 files changed, 738 insertions(+), 368 deletions(-)
>>  create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>>
>>>
>>> 
>>>
>>> --
>>> Seung-Woo Kim
>>> Samsung Software R Center
>>> --
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Regards,
Rahul Sharma,
email to: rahul.sharma at samsung.com
Samsung India.

[PATCH v5 4/9] video: Add generic HDMI infoframe helpers

[Thierry Reding]

On Thu, Mar 07, 2013 at 02:32:51PM +0100, Lucas Stach wrote:
> Am Montag, den 04.03.2013, 16:02 +0100 schrieb Thierry Reding:
> > On Mon, Mar 04, 2013 at 04:49:46PM +0200, Ville Syrj?l? wrote:
> > > On Fri, Feb 22, 2013 at 08:03:26AM +0100, Thierry Reding wrote:
> > [...]
> > > > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > > > new file mode 100644
> > > > index 000..ab23c9b
> > > > --- /dev/null
> > > > +++ b/drivers/video/hdmi.c
> > > > @@ -0,0 +1,308 @@
> > > > +/*
> > > > + * Copyright (C) 2012 Avionic Design GmbH
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or modify
> > > > + * it under the terms of the GNU General Public License version 2 as
> > > > + * published by the Free Software Foundation.
> > > > + */
> > > 
> > > BTW was there any discussion about the license? drm is generally MIT.
> > > Are people OK with depending on GPL code for infoframe support?
> > 
> > I wasn't aware of that. I don't know how much of an issue it is really
> > since all symbols are exported non-GPL.
> > 
> > Thierry
> 
> It's not about the export of the symbols, but more about porting DRM to
> other UNIXes like BSD. Using the GPL here makes life for the BSD guys a
> lot harder and they are already struggling really hard to keep up with
> the pace of Linux. So if you don't care too much it would be nice to use
> MIT here.

Sure, I'll relicense it under MIT then.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130307/a8dbd324/attachment.pgp>

[PATCH v5 4/9] video: Add generic HDMI infoframe helpers

[Lucas Stach]

Am Montag, den 04.03.2013, 16:02 +0100 schrieb Thierry Reding:
> On Mon, Mar 04, 2013 at 04:49:46PM +0200, Ville Syrj?l? wrote:
> > On Fri, Feb 22, 2013 at 08:03:26AM +0100, Thierry Reding wrote:
> [...]
> > > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > > new file mode 100644
> > > index 000..ab23c9b
> > > --- /dev/null
> > > +++ b/drivers/video/hdmi.c
> > > @@ -0,0 +1,308 @@
> > > +/*
> > > + * Copyright (C) 2012 Avionic Design GmbH
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + */
> > 
> > BTW was there any discussion about the license? drm is generally MIT.
> > Are people OK with depending on GPL code for infoframe support?
> 
> I wasn't aware of that. I don't know how much of an issue it is really
> since all symbols are exported non-GPL.
> 
> Thierry

It's not about the export of the symbols, but more about porting DRM to
other UNIXes like BSD. Using the GPL here makes life for the BSD guys a
lot harder and they are already struggling really hard to keep up with
the pace of Linux. So if you don't care too much it would be nice to use
MIT here.

Regards,
Lucas

[PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver

[Inki Dae]

2013/3/7 ??? :
>
>
> On 2013? 03? 04? 23:05, Rahul Sharma wrote:
>> Thanks Sean,
>>
>> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul  wrote:
>>> On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma  
>>> wrote:
 Right now hdmiphy operations and configs are kept inside hdmi driver. 
 hdmiphy related
 code is tightly coupled with hdmi ip driver. Physicaly they are different 
 devices and
>>>
>>> s/Physicaly/Physically/
>>>
 should be instantiated independently.

 In terms of versions/mapping/configurations Hdmi and hdmiphy are 
 independent of each
 other. It is preferred to isolate them and maintained independently.

 This implementations is tested for:
 1) Resolutions supported by exynos4 and 5 hdmi.
 2) Runtime PM and S2R scenarions for exynos5.

>>>
>>> I don't like the idea of spawning off yet another driver in here. It
>>> adds more globals, more suspend/resume ordering issues, and more
>>> implicit dependencies. I understand, however, that this is the Chosen
>>> Way for the exynos driver, so I will save my rant.
>>>
>>
>> I agree to it. splitting phy to a new driver will complicate the power 
>> related
>> scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of
>> config values, mapping (i2c/platform bus) etc. Handling this diversity
>> inside hdmi driver is complicating it with unrelated changes.
>
> Basically, I agree with the idea to split hdmiphy from hdmi. And it
> seems that already existing hdmiphy i2c device is just reused and
> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling
> flow of power operations is reordered.
>
> But I'm not sure exynos_hdmiphy_driver_register() really need to be
> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to
> call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy
> is only used from hdmi.
>

I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem.

Thanks,
Inki Dae

> Thanks and Regards,
> - Seung-Woo Kim
>
>>
>> I have tested this RFC for Runtime PM / S2R. But if we see any major 
>> roadblock
>> we should re-factor this by explicitly calling power related callbacks
>> of mixer, phy,
>> hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf
>> device. AFAIR something like this is already in place in chrome-kernel.
>>
>>> I've made some comments below.
>>>
 This patch is dependent on
 http://www.mail-archive.com/dri-devel at 
 lists.freedesktop.org/msg34733.html
 http://www.mail-archive.com/dri-devel at 
 lists.freedesktop.org/msg34861.html
 http://www.mail-archive.com/dri-devel at 
 lists.freedesktop.org/msg34862.html

 Signed-off-by: Rahul Sharma 
 ---
 It is based on exynos-drm-next-todo branch at
 git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   8 +
  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   6 +
  drivers/gpu/drm/exynos/exynos_drm_hdmi.c |  58 ++-
  drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  11 +
  drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++--
  drivers/gpu/drm/exynos/exynos_hdmi.h |   1 -
  drivers/gpu/drm/exynos/exynos_hdmiphy.c  | 586 
 ++-
  drivers/gpu/drm/exynos/regs-hdmiphy.h|  61 
  8 files changed, 738 insertions(+), 368 deletions(-)
  create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h

>
> 
>
> --
> Seung-Woo Kim
> Samsung Software R Center
> --
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon drm-fixes-3.9

[alexdeuc...@gmail.com]

From: Alex Deucher 

Hi Dave,

  Radeon fixes pull.  Not much to it.
  - fix some splatter if the interrupt handler isn't registered
  - Add a quirk for an old R200 board to fix washed out colors on the DAC
  - Don't try and soft reset the MC when we reset the GPU.  It usually doesn't
need it and doesn't always work reliably.
  - A CS checker fix from Marek

The following changes since commit 2cc79544bd0aabb4b3cf467ead5df526d9134c64:

  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2013-03-07 
11:12:14 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.9

Alex Deucher (3):
  drm/radeon: don't set hpd, afmt interrupts when interrupts are disabled
  drm/radeon: add primary dac adj quirk for R200 board
  drm/radeon: skip MC reset as it's probably not hung

Marek Ol??k (1):
  drm/radeon: don't check mipmap alignment if MIP_ADDRESS is FMASK

 drivers/gpu/drm/radeon/evergreen.c  |6 ++
 drivers/gpu/drm/radeon/evergreen_cs.c   |2 +-
 drivers/gpu/drm/radeon/ni.c |6 ++
 drivers/gpu/drm/radeon/r600.c   |6 ++
 drivers/gpu/drm/radeon/radeon_combios.c |9 +
 drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
 drivers/gpu/drm/radeon/radeon_irq_kms.c |   12 
 drivers/gpu/drm/radeon/si.c |6 ++
 8 files changed, 48 insertions(+), 2 deletions(-)

[PATCH v12 2/2] drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm fimd

[Vikas Sajjan]

patch adds "select OF_VIDEOMODE" and "select FB_MODE_HELPERS" when
EXYNOS_DRM_FIMD config is selected.

Signed-off-by: Vikas Sajjan 
---
 drivers/gpu/drm/exynos/Kconfig |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 046bcda..bb25130 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -25,6 +25,8 @@ config DRM_EXYNOS_DMABUF
 config DRM_EXYNOS_FIMD
bool "Exynos DRM FIMD"
depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
+   select OF_VIDEOMODE
+   select FB_MODE_HELPERS
help
  Choose this option if you want to use Exynos FIMD for DRM.

-- 
1.7.9.5

[PATCH v12 1/2] video: drm: exynos: Add display-timing node parsing using video helper function

[Vikas Sajjan]

Add support for parsing the display-timing node using video helper
function.

The DT node parsing is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.

Signed-off-by: Leela Krishna Amudala 
Signed-off-by: Vikas Sajjan 
Acked-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..e323cf9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,7 @@
 #include 
 #include 

+#include 
 #include 
 #include 

@@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)

DRM_DEBUG_KMS("%s\n", __FILE__);

-   pdata = pdev->dev.platform_data;
-   if (!pdata) {
-   dev_err(dev, "no platform data specified\n");
-   return -EINVAL;
+   if (pdev->dev.of_node) {
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   DRM_ERROR("memory allocation for pdata failed\n");
+   return -ENOMEM;
+   }
+
+   ret = of_get_fb_videomode(dev->of_node, >panel.timing,
+   OF_USE_NATIVE_MODE);
+   if (ret) {
+   DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
+   return ret;
+   }
+   } else {
+   pdata = pdev->dev.platform_data;
+   if (!pdata) {
+   DRM_ERROR("no platform data specified\n");
+   return -EINVAL;
+   }
}

panel = >panel;
-- 
1.7.9.5

[PATCH v12 0/2] Add display-timing node parsing to exynos drm fimd

[Vikas Sajjan]

Add display-timing node parsing to drm fimd and depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

changes since v11:
- Oops, there was a build error, fixed that.

changes since v10:
- abandoned the pinctrl patch, as commented by Linus Walleij

- added new patch to enable the OF_VIDEOMODE and FB_MODE_HELPERS for
EXYNOS DRM FIMD.

changes since v9:
- replaced IS_ERR_OR_NULL() with IS_ERR(), since IS_ERR_OR_NULL()
will be depreciated, as discussed at

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140543.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg78030.html

changes since v8:
- replaced IS_ERR() with IS_ERR_OR_NULL(),
because devm_pinctrl_get_select_default can return NULL,
If CONFIG_PINCTRL is disabled.
- modified the error log, such that it shall NOT cross 80 column.
- added Acked-by.

changes since v7:
- addressed comments from Joonyoung Shim 
to remove a unnecessary variable.

changes since v6:
addressed comments from Inki Dae  to
separated out the pinctrl functionality and made a separate patch.

changes since v5:
- addressed comments from Inki Dae ,
to remove the allocation of 'fbmode' and replaced
'-1'in "of_get_fb_videomode(dev->of_node, fbmode, -1)" with
OF_USE_NATIVE_MODE.

changes since v4:
- addressed comments from Paul Menzel
, to modify the commit message

changes since v3:
- addressed comments from Sean Paul , to 
modify
the return values and print messages.

changes since v2:
- moved 'devm_pinctrl_get_select_default' function call under
'if (pdev->dev.of_node)', this makes NON-DT code unchanged.
(reported by: Rahul Sharma )

changes since v1:
- addressed comments from Sean Paul 

Vikas Sajjan (2):
  video: drm: exynos: Add display-timing node parsing using video
helper function
  drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm
fimd

 drivers/gpu/drm/exynos/Kconfig   |2 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   27 +++
 2 files changed, 25 insertions(+), 4 deletions(-)

-- 
1.7.9.5

[PATCH] drm/exynos: modify the compatible string for exynos fimd

[Vikas Sajjan]

Thanks.

On 7 March 2013 12:47, Inki Dae  wrote:
> Already merged. :)
>
>> -Original Message-
>> From: Vikas Sajjan [mailto:vikas.sajjan at linaro.org]
>> Sent: Thursday, March 07, 2013 4:09 PM
>> To: InKi Dae
>> Cc: dri-devel at lists.freedesktop.org; linux-media at vger.kernel.org;
>> kgene.kim at samsung.com; Joonyoung Shim; sunil joshi
>> Subject: Re: [PATCH] drm/exynos: modify the compatible string for exynos
>> fimd
>>
>> Hi Mr Inki Dae,
>>
>> On 28 February 2013 08:12, Joonyoung Shim  wrote:
>> > On 02/27/2013 07:32 PM, Vikas Sajjan wrote:
>> >>
>> >> modified compatible string for exynos4 fimd as "exynos4210-fimd" and
>> >> exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible
>> >> value should be named after first specific SoC model in which this
>> >> particular IP version was included as discussed at
>> >> https://patchwork.kernel.org/patch/2144861/
>> >>
>> >> Signed-off-by: Vikas Sajjan 
>> >> ---
>> >>   drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 ++--
>> >>   1 file changed, 2 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> >> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> >> index 9537761..433ed35 100644
>> >> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> >> @@ -109,9 +109,9 @@ struct fimd_context {
>> >> #ifdef CONFIG_OF
>> >>   static const struct of_device_id fimd_driver_dt_match[] = {
>> >> -   { .compatible = "samsung,exynos4-fimd",
>> >> +   { .compatible = "samsung,exynos4210-fimd",
>> >>   .data = _fimd_driver_data },
>> >> -   { .compatible = "samsung,exynos5-fimd",
>> >> +   { .compatible = "samsung,exynos5250-fimd",
>> >>   .data = _fimd_driver_data },
>> >> {},
>> >>   };
>> >
>> >
>> > Acked-by: Joonyoung Shim 
>>
>> Can you please apply this patch.
>>
>> >
>> > Thanks.
>>
>>
>>
>> --
>> Thanks and Regards
>>  Vikas Sajjan
>



-- 
Thanks and Regards
 Vikas Sajjan

[PATCH 3/4] drm/omap: Make fixed resolution panels work

[Archit Taneja]

On Wednesday 06 March 2013 06:15 AM, Rob Clark wrote:
> On Tue, Mar 5, 2013 at 9:17 AM, Archit Taneja  wrote:
>> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
>> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, 
>> DSI
>> and SDI drivers. At some places, there are no checks to see if the panel 
>> driver
>> has these ops or not, and that leads to a crash.
>>
>> The following things are done to make fixed panels work:
>>
>> - The omap_connector's detect function is modified such that it considers 
>> panel
>>types which are generally fixed panels as always connected(provided the 
>> panel
>>driver doesn't have a detect op). Hence, the connector corresponding to 
>> these
>>panels is always in a 'connected' state.
>>
>> - If a panel driver doesn't have a check_timings op, assume that it supports 
>> the
>>mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper 
>> function)
>>
>> - The function omap_encoder_update shouldn't really do anything for fixed
>>resolution panels, make sure that it calls set_timings only if the panel
>>driver has one.
>>
>> Signed-off-by: Archit Taneja 
>> ---
>>   drivers/gpu/drm/omapdrm/omap_connector.c |   10 --
>>   drivers/gpu/drm/omapdrm/omap_encoder.c   |6 --
>>   2 files changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
>> b/drivers/gpu/drm/omapdrm/omap_connector.c
>> index c451c41..c952324 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
>> @@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
>>  ret = connector_status_connected;
>>  else
>>  ret = connector_status_disconnected;
>> +   } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
>> +   dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
>> +   dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
>> +   dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
>> +   ret = connector_status_connected;
>>  } else {
>>  ret = connector_status_unknown;
>>  }
>> @@ -189,12 +194,13 @@ static int omap_connector_mode_valid(struct 
>> drm_connector *connector,
>>  struct omap_video_timings timings = {0};
>>  struct drm_device *dev = connector->dev;
>>  struct drm_display_mode *new_mode;
>> -   int ret = MODE_BAD;
>> +   int r, ret = MODE_BAD;
>>
>>  copy_timings_drm_to_omap(, mode);
>>  mode->vrefresh = drm_mode_vrefresh(mode);
>>
>> -   if (!dssdrv->check_timings(dssdev, )) {
>> +   r = dssdrv->check_timings ? dssdrv->check_timings(dssdev, ) 
>> : 0;
>> +   if (!r) {
>>  /* check if vrefresh is still valid */
>>  new_mode = drm_mode_duplicate(dev, mode);
>>  new_mode->clock = timings.pixel_clock;
>> diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c 
>> b/drivers/gpu/drm/omapdrm/omap_encoder.c
>> index d48df71..9aed178 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_encoder.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
>> @@ -135,13 +135,15 @@ int omap_encoder_update(struct drm_encoder *encoder,
>>
>>  dssdev->output->manager = mgr;
>>
>> -   ret = dssdrv->check_timings(dssdev, timings);
>> +   ret = dssdrv->check_timings ?
>> +   dssdrv->check_timings(dssdev, timings) : 0;
>>  if (ret) {
>>  dev_err(dev->dev, "could not set timings: %d\n", ret);
>>  return ret;
>>  }
>>
>> -   dssdrv->set_timings(dssdev, timings);
>> +   if (dssdrv->set_timings)
>> +   dssdrv->set_timings(dssdev, timings);
>
> maybe either here or _mode_valid(), for panels that don't have
> set_timings(), we should double check that the new timings match what
> we get from the panel's get_timings().  Other than that, it looks
> fine.

Yeah, we should do that. I guess it makes more sense to do it earlier, 
i.e, in mode_vaild.

Archit

[PATCH] drm/exynos: modify the compatible string for exynos fimd

[Vikas Sajjan]

Hi Mr Inki Dae,

On 28 February 2013 08:12, Joonyoung Shim  wrote:
> On 02/27/2013 07:32 PM, Vikas Sajjan wrote:
>>
>> modified compatible string for exynos4 fimd as "exynos4210-fimd" and
>> exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible
>> value should be named after first specific SoC model in which this
>> particular IP version was included as discussed at
>> https://patchwork.kernel.org/patch/2144861/
>>
>> Signed-off-by: Vikas Sajjan 
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 9537761..433ed35 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -109,9 +109,9 @@ struct fimd_context {
>> #ifdef CONFIG_OF
>>   static const struct of_device_id fimd_driver_dt_match[] = {
>> -   { .compatible = "samsung,exynos4-fimd",
>> +   { .compatible = "samsung,exynos4210-fimd",
>>   .data = _fimd_driver_data },
>> -   { .compatible = "samsung,exynos5-fimd",
>> +   { .compatible = "samsung,exynos5250-fimd",
>>   .data = _fimd_driver_data },
>> {},
>>   };
>
>
> Acked-by: Joonyoung Shim 

Can you please apply this patch.

>
> Thanks.



-- 
Thanks and Regards
 Vikas Sajjan

nouveau lockdep splat

[Arend van Spriel]

On 03/04/13 22:16, Borislav Petkov wrote:
> New -rc1, so let the stabilization games begin.
>
> I see the following on rc1, let me know if you need more info.
>
>
> [0.633617] =
> [0.633618] [ INFO: possible recursive locking detected ]
> [0.633618] 3.9.0-rc1 #2 Not tainted
> [0.633619] -
> [0.633619] swapper/0/1 is trying to acquire lock:
> [0.633623]  (>lock){+.+...}, at: [] 
> evo_wait+0x43/0xf0
> [0.633624]
> [0.633624] but task is already holding lock:
> [0.633626]  (>lock){+.+...}, at: [] 
> evo_wait+0x43/0xf0
> [0.633626]
> [0.633626] other info that might help us debug this:
> [0.633626]  Possible unsafe locking scenario:
> [0.633626]
> [0.633626]CPU0
> [0.633627]
> [0.633627]   lock(>lock);
> [0.633628]   lock(>lock);

I am getting the same on my Dell Latitude e6410 and as a bonus I get 
abundant amount of nouveau error messages. These are not all as my 
system hangs after this.

  Ubuntu 12.04.2 LTS (GNU/Linux 
3.9.0-rc1-wl-testing-lockdep-2-gc181dcd i686)

01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [NVS 3100M] 
(rev a2)

Gr. AvS

c$ dmesg
[  753.201712] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x0f04 data 0x0480
[  753.215281] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.224605] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x0f04 data 0x00010360
[  753.238198] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.247167] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x0f04 data 0x0300
[  753.260757] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.269919] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x0f04 data 0x
[  753.283456] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.292705] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x155c data 0x
[  753.306231] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.315505] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x1560 data 0x20034000
[  753.329049] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.338221] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x1564 data 0x
[  753.351752] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.360716] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x1280 data 0x
[  753.374255] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.383226] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x1284 data 0x20034000
[  753.396780] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.405741] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x1288 data 0x4000
[  753.419278] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.428535] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x0f00 data 0x
[  753.442069] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.451006] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x0f04 data 0x000240db
[  753.464549] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.473505] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x0f04 data 0x0051
[  753.487058] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.495994] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x0f04 data 0x
[  753.509213] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.518160] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x0f04 data 0x
[  753.531370] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.540630] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x0f04 data 0x
[  753.554170] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.563113] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x0f04 data 0x
[  753.576643] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.585897] nouveau E[  PGRAPH][:01:00.0] ch -1 [0x001fb34000 
unknown] subc 5 class 0x mthd 0x0f04 data 0x
[  753.599430] nouveau E[  PGRAPH][:01:00.0]  ILLEGAL_MTHD ILLEGAL_CLASS
[  753.608365] nouveau E[  PGRAPH][:01:00.0] ch -1 

[PATCH v11 2/2] drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm fimd

[Vikas Sajjan]

patch adds "select OF_VIDEOMODE" and "select FB_MODE_HELPERS" when
EXYNOS_DRM_FIMD config is selected.

Signed-off-by: Vikas Sajjan 
---
 drivers/gpu/drm/exynos/Kconfig |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 046bcda..bb25130 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -25,6 +25,8 @@ config DRM_EXYNOS_DMABUF
 config DRM_EXYNOS_FIMD
bool "Exynos DRM FIMD"
depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
+   select OF_VIDEOMODE
+   select FB_MODE_HELPERS
help
  Choose this option if you want to use Exynos FIMD for DRM.

-- 
1.7.9.5

[PATCH v11 1/2] video: drm: exynos: Add display-timing node parsing using video helper function

[Vikas Sajjan]

Add support for parsing the display-timing node using video helper
function.

The DT node parsing is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.

Signed-off-by: Leela Krishna Amudala 
Signed-off-by: Vikas Sajjan 
Acked-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..f322ec3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,7 @@
 #include 
 #include 

+#include 
 #include 
 #include 

@@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)

DRM_DEBUG_KMS("%s\n", __FILE__);

-   pdata = pdev->dev.platform_data;
-   if (!pdata) {
-   dev_err(dev, "no platform data specified\n");
-   return -EINVAL;
+   if (pdev->dev.of_node) {
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   DRM_ERROR("memory allocation for pdata failed\n");
+   return -ENOMEM;
+   }
+
+   ret = of_get_fb_videomode(dev->of_node, >panel.timing,
+   OF_USE_NATIVE_MODE);
+   if (ret) {
+   DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);"
+   return ret;
+   }
+   } else {
+   pdata = pdev->dev.platform_data;
+   if (!pdata) {
+   DRM_ERROR("no platform data specified\n");
+   return -EINVAL;
+   }
}

panel = >panel;
-- 
1.7.9.5

[PATCH v11 0/2] Add display-timing node parsing to exynos drm fimd

[Vikas Sajjan]

Add display-timing node parsing to drm fimd and depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

changes since v10:
- abandoned the pinctrl patch, as commented by Linus Walleij

- added new patch to enable the OF_VIDEOMODE and FB_MODE_HELPERS for
EXYNOS DRM FIMD.

changes since v9:
- replaced IS_ERR_OR_NULL() with IS_ERR(), since IS_ERR_OR_NULL()
will be depreciated, as discussed at

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140543.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg78030.html

changes since v8:
- replaced IS_ERR() with IS_ERR_OR_NULL(),
because devm_pinctrl_get_select_default can return NULL,
If CONFIG_PINCTRL is disabled.
- modified the error log, such that it shall NOT cross 80 column.
- added Acked-by.

changes since v7:
- addressed comments from Joonyoung Shim 
to remove a unnecessary variable.

changes since v6:
addressed comments from Inki Dae  to
separated out the pinctrl functionality and made a separate patch.

changes since v5:
- addressed comments from Inki Dae ,
to remove the allocation of 'fbmode' and replaced
'-1'in "of_get_fb_videomode(dev->of_node, fbmode, -1)" with
OF_USE_NATIVE_MODE.

changes since v4:
- addressed comments from Paul Menzel
, to modify the commit message

changes since v3:
- addressed comments from Sean Paul , to 
modify
the return values and print messages.

changes since v2:
- moved 'devm_pinctrl_get_select_default' function call under
'if (pdev->dev.of_node)', this makes NON-DT code unchanged.
(reported by: Rahul Sharma )

changes since v1:
- addressed comments from Sean Paul 

Vikas Sajjan (2):
  video: drm: exynos: Add display-timing node parsing using video
helper function
  drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm
fimd

 drivers/gpu/drm/exynos/Kconfig   |2 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   27 +++
 2 files changed, 25 insertions(+), 4 deletions(-)

-- 
1.7.9.5

[PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver

[Rahul Sharma]

Thanks Seung Woo, Mr. Dae,

On Thu, Mar 7, 2013 at 10:13 AM, Inki Dae  wrote:
> 2013/3/7 ??? :
>>
>>
>> On 2013? 03? 04? 23:05, Rahul Sharma wrote:
>>> Thanks Sean,
>>>
>>> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul  wrote:
 On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma >>> samsung.com> wrote:
> Right now hdmiphy operations and configs are kept inside hdmi driver. 
> hdmiphy related
> code is tightly coupled with hdmi ip driver. Physicaly they are different 
> devices and

 s/Physicaly/Physically/

> should be instantiated independently.
>
> In terms of versions/mapping/configurations Hdmi and hdmiphy are 
> independent of each
> other. It is preferred to isolate them and maintained independently.
>
> This implementations is tested for:
> 1) Resolutions supported by exynos4 and 5 hdmi.
> 2) Runtime PM and S2R scenarions for exynos5.
>

 I don't like the idea of spawning off yet another driver in here. It
 adds more globals, more suspend/resume ordering issues, and more
 implicit dependencies. I understand, however, that this is the Chosen
 Way for the exynos driver, so I will save my rant.

>>>
>>> I agree to it. splitting phy to a new driver will complicate the power 
>>> related
>>> scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of
>>> config values, mapping (i2c/platform bus) etc. Handling this diversity
>>> inside hdmi driver is complicating it with unrelated changes.
>>
>> Basically, I agree with the idea to split hdmiphy from hdmi. And it
>> seems that already existing hdmiphy i2c device is just reused and
>> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling
>> flow of power operations is reordered.
>>
>> But I'm not sure exynos_hdmiphy_driver_register() really need to be
>> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to
>> call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy
>> is only used from hdmi.
>>
>
> I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem.
>

I agree to the Seung Woo's point that hdmi-phy used to be solely accessed by
hdmi driver.  But in this RFC, hdmi-phy is not called by hdmi driver
anymore. Phy
ops will be called from drm-common-hdmi platform driver along with mixer and
hdmi ops.

The rational behind my implementation is that I am projecting hdmi-phy as
a device which is peer to hdmi ip and mixer. These 3 devices together makes
DRM HDMI subsystem.

Even physically hdmi-phy doesn't seems to be a part of hdmi ip though
configurations are listed under hdmi ip user manual. It looks like a
isolated module accessed by i2c.

Though I don't find anything wrong with Seung Woo suggestion but above
placement of hdmi-phy (parallel to hdmi and mixer) makes more sense
to me.

Please have a another look at it and let me know your opinion.

Another things which bothers me is registering mixer, hdmi driver inside
exynos_drm_init(). If we strictly follow the hierarchy inside drm,
exynos_drm_init()
should register drm-common-hdmi only. drm-common-hdmi should register
mixer and hdmi (or hdmi-phy as well).

regards,
Rahul Sharma.

> Thanks,
> Inki Dae
>
>> Thanks and Regards,
>> - Seung-Woo Kim
>>
>>>
>>> I have tested this RFC for Runtime PM / S2R. But if we see any major 
>>> roadblock
>>> we should re-factor this by explicitly calling power related callbacks
>>> of mixer, phy,
>>> hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf
>>> device. AFAIR something like this is already in place in chrome-kernel.
>>>
 I've made some comments below.

> This patch is dependent on
> http://www.mail-archive.com/dri-devel at 
> lists.freedesktop.org/msg34733.html
> http://www.mail-archive.com/dri-devel at 
> lists.freedesktop.org/msg34861.html
> http://www.mail-archive.com/dri-devel at 
> lists.freedesktop.org/msg34862.html
>
> Signed-off-by: Rahul Sharma 
> ---
> It is based on exynos-drm-next-todo branch at
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   8 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   6 +
>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c |  58 ++-
>  drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  11 +
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++--
>  drivers/gpu/drm/exynos/exynos_hdmi.h |   1 -
>  drivers/gpu/drm/exynos/exynos_hdmiphy.c  | 586 
> ++-
>  drivers/gpu/drm/exynos/regs-hdmiphy.h|  61 
>  8 files changed, 738 insertions(+), 368 deletions(-)
>  create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>
>>
>> 
>>
>> --
>> Seung-Woo Kim
>> Samsung Software R Center
>> --
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> 

[Bug 61965] Kernel panics drm_fb_helper_restore_fbdev_mode when using Chromium

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61965

Mike Lothian  changed:

   What|Removed |Added

 CC||mike at fireburn.co.uk

--- Comment #3 from Mike Lothian  ---
Sorry Chris - I did do some googling but couldn't find this will try searching
for pstates - Cheers

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130307/7af66445/attachment.html>

[Bug 61965] Kernel panics drm_fb_helper_restore_fbdev_mode when using Chromium

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61965

--- Comment #2 from Mike Lothian  ---
I'm going to hazzard a guess that either
4d53233a36fdda567cd4d080e27e1ee4b669ddd1  and / or
2e928815c1886fe628ed54623aa98d0889cf5509 are most probably where the problem
lies

I can't seem to  CC Tejun Heo  - am I reporting this bug to 
the
right place?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130307/0ce11d57/attachment.html>

[Bug 61965] Kernel panics drm_fb_helper_restore_fbdev_mode when using Chromium

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61965

Chris Wilson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #1 from Chris Wilson  ---
Known bug in intel_pstate.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130307/67d880a6/attachment.html>

[Bug 61965] Kernel panics drm_fb_helper_restore_fbdev_mode when using Chromium

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61965

Chris Wilson  changed:

   What|Removed |Added

  Attachment #76113|text/plain  |image/jpeg
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130307/21fcc3d6/attachment.html>

[PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver

[김승우]

On 2013? 03? 04? 23:05, Rahul Sharma wrote:
> Thanks Sean,
> 
> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul  wrote:
>> On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma  
>> wrote:
>>> Right now hdmiphy operations and configs are kept inside hdmi driver. 
>>> hdmiphy related
>>> code is tightly coupled with hdmi ip driver. Physicaly they are different 
>>> devices and
>>
>> s/Physicaly/Physically/
>>
>>> should be instantiated independently.
>>>
>>> In terms of versions/mapping/configurations Hdmi and hdmiphy are 
>>> independent of each
>>> other. It is preferred to isolate them and maintained independently.
>>>
>>> This implementations is tested for:
>>> 1) Resolutions supported by exynos4 and 5 hdmi.
>>> 2) Runtime PM and S2R scenarions for exynos5.
>>>
>>
>> I don't like the idea of spawning off yet another driver in here. It
>> adds more globals, more suspend/resume ordering issues, and more
>> implicit dependencies. I understand, however, that this is the Chosen
>> Way for the exynos driver, so I will save my rant.
>>
> 
> I agree to it. splitting phy to a new driver will complicate the power related
> scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of
> config values, mapping (i2c/platform bus) etc. Handling this diversity
> inside hdmi driver is complicating it with unrelated changes.

Basically, I agree with the idea to split hdmiphy from hdmi. And it
seems that already existing hdmiphy i2c device is just reused and
hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling
flow of power operations is reordered.

But I'm not sure exynos_hdmiphy_driver_register() really need to be
called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to
call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy
is only used from hdmi.

Thanks and Regards,
- Seung-Woo Kim

> 
> I have tested this RFC for Runtime PM / S2R. But if we see any major roadblock
> we should re-factor this by explicitly calling power related callbacks
> of mixer, phy,
> hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf
> device. AFAIR something like this is already in place in chrome-kernel.
> 
>> I've made some comments below.
>>
>>> This patch is dependent on
>>> http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg34733.html
>>> http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg34861.html
>>> http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg34862.html
>>>
>>> Signed-off-by: Rahul Sharma 
>>> ---
>>> It is based on exynos-drm-next-todo branch at
>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   8 +
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   6 +
>>>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c |  58 ++-
>>>  drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  11 +
>>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++--
>>>  drivers/gpu/drm/exynos/exynos_hdmi.h |   1 -
>>>  drivers/gpu/drm/exynos/exynos_hdmiphy.c  | 586 
>>> ++-
>>>  drivers/gpu/drm/exynos/regs-hdmiphy.h|  61 
>>>  8 files changed, 738 insertions(+), 368 deletions(-)
>>>  create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>>>



-- 
Seung-Woo Kim
Samsung Software R Center
--

[Bug 61965] New: Kernel panics drm_fb_helper_restore_fbdev_mode when using Chromium

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61965

  Priority: medium
Bug ID: 61965
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Kernel panics drm_fb_helper_restore_fbdev_mode when
using Chromium
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: mike at fireburn.co.uk
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/other
   Product: DRI

Created attachment 76113
  --> https://bugs.freedesktop.org/attachment.cgi?id=76113=edit
Screenshot

I've seen this twice now so thought I'd take a screen shot

It's only appeared since the merge window and I'm not sure how to reproduce it

Both times have mentioned Chromium

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130307/db38645e/attachment-0001.html>

[PATCH 2/2] drm: Documentation typo fixes

[Christopher Harvey]

Signed-off-by: Christopher Harvey 
---
 include/drm/drm_crtc.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 00d78b5..7294403 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -429,12 +429,12 @@ struct drm_crtc {
  * @dpms: set power state (see drm_crtc_funcs above)
  * @save: save connector state
  * @restore: restore connector state
- * @reset: reset connector after state has been invalidate (e.g. resume)
+ * @reset: reset connector after state has been invalidated (e.g. resume)
  * @detect: is this connector active?
  * @fill_modes: fill mode list for this connector
- * @set_property: property for this connector may need update
+ * @set_property: property for this connector may need an update
  * @destroy: make object go away
- * @force: notify the driver the connector is forced on
+ * @force: notify the driver that the connector is forced on
  *
  * Each CRTC may have one or more connectors attached to it.  The functions
  * below allow the core DRM code to control connectors, enumerate available 
modes,
-- 
1.7.12.4

[PATCH 1/2] drm/mgag200: Bug fix: Renesas board now selects native resolution.

[Julia Lemire]

Renesas boards were consistently defaulting to the 1024x768 resolution,
regardless of the native resolution of the monitor plugged in.  It was
determined that the EDID of the monitor was not being read.  Since the
DAC is a shared line, in order to read from or write to it we must take
control of the DAC clock.  This can be done by setting the proper
register to one.

This bug fix sets the register MGA1064_GEN_IO_CTL2 to one.  The DAC
control line can be used to determine whether or not a new monitor has
been plugged in.  But since the hotplug feature is not one we will
support, it has been decided to simply leave the register set to one.

Signed-off-by: Julia Lemire 
---
 drivers/gpu/drm/mgag200/mgag200_i2c.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mgag200/mgag200_i2c.c 
b/drivers/gpu/drm/mgag200/mgag200_i2c.c
index 5a88ec5..d3dcf54 100644
--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -92,6 +92,7 @@ struct mga_i2c_chan *mgag200_i2c_create(struct drm_device 
*dev)
int ret;
int data, clock;

+   WREG_DAC(MGA1064_GEN_IO_CTL2, 1);
WREG_DAC(MGA1064_GEN_IO_DATA, 0xff);
WREG_DAC(MGA1064_GEN_IO_CTL, 0);

-- 
1.7.12.4

[PATCH 0/2] mgag200 fix plus documentation typo fixes

[Christopher Harvey]

This is a fix for mgag200 cards that is well documented in the commit
message. Also includes some typo fixes that were bugging me.

Christopher Harvey (1):
  drm: Documentation typo fixes

Julia Lemire (1):
  drm/mgag200: Bug fix: Renesas board now selects native resolution.

 drivers/gpu/drm/mgag200/mgag200_i2c.c | 1 +
 include/drm/drm_crtc.h| 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)

-- 
1.7.12.4

[PATCH] drm/mgag200: Reject modes that are too big for VRAM

[Dave Airlie]

On Wed, Feb 27, 2013 at 1:55 AM, Christopher Harvey  
wrote:
> A monitor or a user could request a resolution greater than the
> available VRAM for the backing framebuffer. This change checks the
> required framebuffer size against the max VRAM size and rejects modes
> if they are too big. This change can also remove a mode request passed
> in via the video= parameter.

I can't say I like the bpp finding code, but my brain is failing to
come up with something better,

so yeah I think this is fine, those cards with 1.5MB VRAM always piss me off :-)

I'll apply these, send on any others!
Dave.

Black screen with nouveau in 3.8.x (regression)

[Nick Bowler]

Hi folks,

Yesterday I upgraded one of my machines to 3.8.2 from 3.6.6.  This
machine has an old NV36 AGP board.  With the new kernel, as soon as
nouveau takes over the console the display connected via DVI goes dark
(the monitor goes into standby mode).  The display connected via VGA
continues to work fine.

Starting Xorg does not correct the problem.  Nouveau seems to know
that the display is connected:

  % cat /sys/class/drm/card0-DVI-I-1/status
  connected

I don't see anything unusual in the log either (full log attached):

  % dmesg -t | grep -iE 'drm|nouveau'
  [drm] Initialized drm 1.1.0 20060810
  nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x436200a1
  nouveau  [  DEVICE][:01:00.0] Chipset: NV36 (NV36)
  nouveau  [  DEVICE][:01:00.0] Family : NV30
  nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
  nouveau  [   VBIOS][:01:00.0] ... appears to be valid
  nouveau  [   VBIOS][:01:00.0] using image from PRAMIN
  nouveau  [   VBIOS][:01:00.0] BMP version 5.28
  nouveau  [   VBIOS][:01:00.0] version 04.36.20.21
  nouveau W[  PTIMER][:01:00.0] unknown input clock freq
  nouveau  [ PFB][:01:00.0] RAM type: DDR1
  nouveau  [ PFB][:01:00.0] RAM size: 256 MiB
  nouveau :01:00.0: putting AGP V3 device into 8x mode
  nouveau  [ DRM] VRAM: 255 MiB
  nouveau  [ DRM] GART: 64 MiB
  nouveau  [ DRM] BMP BIOS found
  nouveau  [ DRM] BMP version 5.40
  nouveau  [ DRM] Bios version 04.36.20.21
  nouveau  [ DRM] DCB version 2.2
  nouveau  [ DRM] DCB outp 00: 01000300 9c40
  nouveau  [ DRM] DCB outp 01: 02010310 9c40
  nouveau  [ DRM] DCB outp 02: 04000302 
  nouveau  [ DRM] DCB outp 03: 02020321 0303
  nouveau  [ DRM] Loading NV17 power sequencing microcode
  nouveau  [ DRM] Saving VGA fonts
  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
  [drm] No driver support for vblank timestamp query.
  nouveau  [ DRM] 0xE51A: Parsing digital output script table
  nouveau  [ DRM] 0 available performance level(s)
  nouveau  [ DRM] c: core 425MHz memory 501MHz voltage 1350mV
  nouveau  [ DRM] MM: using M2MF for buffer copies
  nouveau  [ DRM] Setting dpms mode 3 on vga encoder (output 0)
  nouveau  [ DRM] Setting dpms mode 3 on vga encoder (output 1)
  nouveau  [ DRM] Setting dpms mode 3 on tmds encoder (output 2)
  nouveau  [ DRM] Setting dpms mode 3 on TV encoder (output 3)
  nouveau  [ DRM] allocated 1280x1024 fb: 0x9000, bo 88007b6ae000
  fbcon: nouveaufb (fb0) is primary device
  nouveau  [ DRM] 0xE51A: Parsing digital output script table
  nouveau  [ DRM] Setting dpms mode 0 on tmds encoder (output 2)
  nouveau  [ DRM] Output DVI-I-1 is running on CRTC 0 using output C
  nouveau  [ DRM] Setting dpms mode 0 on vga encoder (output 1)
  nouveau  [ DRM] Output VGA-1 is running on CRTC 1 using output B
  fb0: nouveaufb frame buffer device
  drm: registered panic notifier
  [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on minor 0

I started a bisection... here's the first steps so far.  I will try to
finish the procedure over the next couple days but I'm reporting this
now in case someone needs me to get some other info.

  git bisect start 'drivers/gpu/drm'
  # good: [3820288942d1c1524c3ee85cbf503fee1533cfc3] Linux 3.6.6
  git bisect good 3820288942d1c1524c3ee85cbf503fee1533cfc3
  # bad: [19b00d2dc9bedf0856e366cb7b9c7733ded659e4] Linux 3.8.2
  git bisect bad 19b00d2dc9bedf0856e366cb7b9c7733ded659e4
  # good: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6
  git bisect good a0d271cbfed1dd50278c6b06bead3d00ba0a88f9
  # bad: [daed2dbb7ea4d179e472396ce46377fe758d5faf] drm/i915: use the CPU and 
PCH transcoders on lpt_pch_enable
  git bisect bad daed2dbb7ea4d179e472396ce46377fe758d5faf
  # good: [df86b5765a48d5f557489577652bd6df145b0e1b] drm/savage: re-add 
busmaster enable, regression fix
  git bisect good df86b5765a48d5f557489577652bd6df145b0e1b
  # bad: [39df01cd6ce9f6dd755ace0030e2bebe75da7727] Merge branch 
'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
  git bisect bad 39df01cd6ce9f6dd755ace0030e2bebe75da7727

Thanks,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
-- next part --
A non-text attachment was scrubbed...
Name: nouveau-black-lcd.log.xz
Type: application/x-xz
Size: 10880 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130307/56055089/attachment.bin>

[Intel-gfx] [PATCH 6/8] drm/i915: Enable/Disable PSR

[Jesse Barnes]

On Tue, 26 Feb 2013 14:48:33 +0200
Ville Syrj?l?  wrote:

> On Mon, Feb 25, 2013 at 07:55:20PM -0300, Rodrigo Vivi wrote:
> > Adding Enable and Disable PSR functionalities. This includes setting the
> > PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
> > enabling PSR in the sink via DPCD register and finally enabling PSR on
> > the host.
> > 
> > This patch is heavily based on initial PSR code by Sateesh Kavuri and
> > Kumar Shobhit but in a different implementation.
> > 
> > Credits-by: Sateesh Kavuri 
> > Credits-by: Shobhit Kumar 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  40 +
> >  drivers/gpu/drm/i915/intel_dp.c  | 183 
> > +++
> >  drivers/gpu/drm/i915/intel_drv.h |   3 +
> >  3 files changed, 226 insertions(+)
> > 
> 
> > +void intel_edp_write_vsc_psr(struct intel_dp* intel_dp,
> > +struct edp_vsc_psr *vsc_psr)
> > +{
> > +   struct drm_device *dev =  intel_dp_to_dev(intel_dp);
> > +   struct drm_i915_private *dev_priv = dev->dev_private;
> > +   struct intel_crtc *intel_crtc =  
> > to_intel_crtc(intel_dp_to_crtc(intel_dp));
> > +   u32 ctl_reg = HSW_TVIDEO_DIP_CTL(intel_crtc->cpu_transcoder);
> > +   u32 data_reg = HSW_TVIDEO_DIP_VSC_DATA(intel_crtc->cpu_transcoder);
> > +   uint32_t *data = (uint32_t *)vsc_psr;
> > +   unsigned int i;
> > +   u32 val = I915_READ(ctl_reg);
> > +
> > +   if (data_reg == 0)
> > +   return;
> > +
> > +   /* As per eDP spec, wait for vblank to send SDP VSC packet */
> > +   intel_wait_for_vblank(dev, intel_crtc->pipe);
> > +
> > +   mmiowb();
> 
> I was curious about these mmiowb()s and apparently they were added to
> all infoframe writes "just in case". But AFAICS on x86 mmiowb() ends
> up as a compiler barrier, so this stuff seems to be a nop.
> 
> And if these writes can get reordered somewhere, why not everything
> else too? I'm sure we have places where we write a bunch of registers,
> and the final write enables something which requires the earlier
> writes to have landed beforehand.

Yeah we shouldn't need mmiowb() anywhere in our driver (until our
on-chip topology gets really complicated anyway).

-- 
Jesse Barnes, Intel Open Source Technology Center

[PATCH] mgag200: some cleanup and a fix for corrupted output

[Dave Airlie]

On Thu, Mar 7, 2013 at 4:51 AM, Christopher Harvey  
wrote:
> On Tue, Feb 26, 2013 at 10:52:55AM -0500, Christopher Harvey wrote:
>> Patches 1 to 4 are just cleanup. Maybe these should should be rolled
>> into one patch?
>>
>> Patch 5 is a bit more complicated.
>> On cards with very little video memory, (e.g 8MB) higher resolutions
>> at 32bit framebuffer depths will get corrupted because the required
>> memory is larger than what the framebuffer has. DRM has "max_height"
>> and "max_width" but no "max_bytes" for limiting resolutions, so the
>> patch is a little hacky. The first for loop tries to associate a
>> connector with the mode being tested. From the connector I can get the
>> bpp if the user specified one on the video= commandline. After that I
>> do 2 things:
>>  1) Invalidate the requested mode from the video= parameter
>>  2) Return MODE_BAD if the framebuffer would be too large
>> I feel this patch plays with structures it shouldn't have to touch to
>> get the bpp. An alternative fix would be to include a "max_bytes" in
>> the DRM core and then do these checks there.
>>
>> I'm also wondering, did I miss the 3.9.0 merge window?
>>
>> Thanks,
>>
>> Christopher Harvey (5):
>>   drm/mgag200: Cleanup: Remove pointless call to drm_fb_get_bpp_depth
>>   drm/mgag200: Cleanup: 'fbdev_list' in 'struct mga_fbdev' is not used
>>   drm/mgag200: Cleanup: Pass driver specific mga_device in driver
>> functions
>>   drm/mgag200: Cleanup: Remove extra variable assigns
>>   drm/mgag200: Reject modes that are too big for VRAM
>>
>>  drivers/gpu/drm/mgag200/mgag200_drv.h  |  1 -
>>  drivers/gpu/drm/mgag200/mgag200_fb.c   |  3 ---
>>  drivers/gpu/drm/mgag200/mgag200_main.c |  2 --
>>  drivers/gpu/drm/mgag200/mgag200_mode.c | 34 
>> ++
>>  4 files changed, 30 insertions(+), 10 deletions(-)
>>
>> --
>> 1.7.12.4
>>
>
> Ping.
>
> I've got more patches queuing up. Should I re-submit these along with
> the new ones?
>
> So far I've only gotten commit message feedback.
>

Sorry been off sick, and this fell off my radar, I'll get to it today,
the first 4 seem fine,

I'll check the last one today., they all look like fixes so I can
probably merge them at any time.

Thanks,
Dave.

[PATCH V3] drm/exynos: fimd: calculate the correct address offset

[Leela Krishna Amudala]

Calculate the correct address offset values for alpha and color key
control registers based on exynos4 and exynos5 user manuals.

Signed-off-by: Leela Krishna Amudala 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..f5f2b25 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -38,11 +38,12 @@
 /* position control register for hardware window 0, 2 ~ 4.*/
 #define VIDOSD_A(win)  (VIDOSD_BASE + 0x00 + (win) * 16)
 #define VIDOSD_B(win)  (VIDOSD_BASE + 0x04 + (win) * 16)
-/* size control register for hardware window 0. */
-#define VIDOSD_C_SIZE_W0   (VIDOSD_BASE + 0x08)
-/* alpha control register for hardware window 1 ~ 4. */
-#define VIDOSD_C(win)  (VIDOSD_BASE + 0x18 + (win) * 16)
-/* size control register for hardware window 1 ~ 4. */
+/*
+ * size control register for hardware windows 0 and alpha control register
+ * for hardware windows 1 ~ 4
+ */
+#define VIDOSD_C(win)  (VIDOSD_BASE + 0x08 + (win) * 16)
+/* size control register for hardware windows 1 ~ 2. */
 #define VIDOSD_D(win)  (VIDOSD_BASE + 0x0C + (win) * 16)

 #define VIDWx_BUF_START(win, buf)  (VIDW_BUF_START(buf) + (win) * 8)
@@ -50,9 +51,9 @@
 #define VIDWx_BUF_SIZE(win, buf)   (VIDW_BUF_SIZE(buf) + (win) * 4)

 /* color key control register for hardware window 1 ~ 4. */
-#define WKEYCON0_BASE(x)   ((WKEYCON0 + 0x140) + (x * 8))
+#define WKEYCON0_BASE(x)   ((WKEYCON0 + 0x140) + ((x - 1) * 8))
 /* color key value register for hardware window 1 ~ 4. */
-#define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + (x * 8))
+#define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + ((x - 1) * 8))

 /* FIMD has totally five hardware windows. */
 #define WINDOWS_NR 5
@@ -581,7 +582,7 @@ static void fimd_win_commit(struct device *dev, int zpos)
if (win != 3 && win != 4) {
u32 offset = VIDOSD_D(win);
if (win == 0)
-   offset = VIDOSD_C_SIZE_W0;
+   offset = VIDOSD_C(win);
val = win_data->ovl_width * win_data->ovl_height;
writel(val, ctx->regs + offset);

-- 
1.8.0

RE: [PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver

[Inki Dae]

 -Original Message-
 From: 김승우 [mailto:sw0312@samsung.com]
 Sent: Thursday, March 07, 2013 4:04 PM
 To: Rahul Sharma
 Cc: Inki Dae; linux-samsung-...@vger.kernel.org; Sean Paul; sunil joshi;
 dri-devel@lists.freedesktop.org; Rahul Sharma; sw0312@samsung.com
 Subject: Re: [PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to
 hdmiphy driver
 
 
 
 On 2013년 03월 07일 15:45, Rahul Sharma wrote:
  Thanks Seung Woo, Mr. Dae,
 
  On Thu, Mar 7, 2013 at 10:13 AM, Inki Dae inki@samsung.com wrote:
  2013/3/7 김승우 sw0312@samsung.com:
 
 
  On 2013년 03월 04일 23:05, Rahul Sharma wrote:
  Thanks Sean,
 
  On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul seanp...@google.com
 wrote:
  On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma
 rahul.sha...@samsung.com wrote:
  Right now hdmiphy operations and configs are kept inside hdmi
 driver. hdmiphy related
  code is tightly coupled with hdmi ip driver. Physicaly they are
 different devices and
 
  s/Physicaly/Physically/
 
  should be instantiated independently.
 
  In terms of versions/mapping/configurations Hdmi and hdmiphy are
 independent of each
  other. It is preferred to isolate them and maintained
independently.
 
  This implementations is tested for:
  1) Resolutions supported by exynos4 and 5 hdmi.
  2) Runtime PM and S2R scenarions for exynos5.
 
 
  I don't like the idea of spawning off yet another driver in here. It
  adds more globals, more suspend/resume ordering issues, and more
  implicit dependencies. I understand, however, that this is the
 Chosen
  Way for the exynos driver, so I will save my rant.
 
 
  I agree to it. splitting phy to a new driver will complicate the
 power related
  scenarios. But in upcoming SoC,s, Phy is changing considerably in
 terms of
  config values, mapping (i2c/platform bus) etc. Handling this
 diversity
  inside hdmi driver is complicating it with unrelated changes.
 
  Basically, I agree with the idea to split hdmiphy from hdmi. And it
  seems that already existing hdmiphy i2c device is just reused and
  hdmiphy_power_on is reorganized to hdmiphy dpms operation: even
 calling
  flow of power operations is reordered.
 
  But I'm not sure exynos_hdmiphy_driver_register() really need to be
  called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough
 to
  call exynos_hdmiphy_driver_register() from hdmi_probe() because
 hdmiphy
  is only used from hdmi.
 
 
  I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem.
 
 
  I agree to the Seung Woo's point that hdmi-phy used to be solely
 accessed by
  hdmi driver.  But in this RFC, hdmi-phy is not called by hdmi driver
  anymore. Phy
  ops will be called from drm-common-hdmi platform driver along with mixer
 and
  hdmi ops.
 
 Considering this, exynos_drm_hdmi_probe() is more proper position.
 
 
  The rational behind my implementation is that I am projecting hdmi-phy
 as
  a device which is peer to hdmi ip and mixer. These 3 devices together
 makes
  DRM HDMI subsystem.
 
  Even physically hdmi-phy doesn't seems to be a part of hdmi ip though
  configurations are listed under hdmi ip user manual. It looks like a
  isolated module accessed by i2c.
 
  Though I don't find anything wrong with Seung Woo suggestion but above
  placement of hdmi-phy (parallel to hdmi and mixer) makes more sense
  to me.
 
  Please have a another look at it and let me know your opinion.
 
  Another things which bothers me is registering mixer, hdmi driver inside
  exynos_drm_init(). If we strictly follow the hierarchy inside drm,
  exynos_drm_init()
  should register drm-common-hdmi only. drm-common-hdmi should register
  mixer and hdmi (or hdmi-phy as well).
 
 Yes, it makes sense. All real hw blocks for hdmi including mixer, hdmi,
 and hdmiphy shoulde be registered in exynos_drm_hdmi (drm-common-hdmi
 for exynos).
 

Ideally, right. But the reason I designed and implemented hdmi subsystem
framework like this, is that there was one issue that
platform_device_register() can't be called at probe(). On other words, when
one platform device driver is being probed, anyone can't be probed. Anyway,
existing way needs to be improved. So let's find better way and improve the
hdmi subsystem framework this time. :)

Thanks,
Inki Dae

 Thanks and Regards,
 - Seung-Woo Kim
 
 
  regards,
  Rahul Sharma.
 
  Thanks,
  Inki Dae
 
  Thanks and Regards,
  - Seung-Woo Kim
 
 
  I have tested this RFC for Runtime PM / S2R. But if we see any major
 roadblock
  we should re-factor this by explicitly calling power related
 callbacks
  of mixer, phy,
  hdmi drivers in a required order. We can call them from exynos-drm-
 hdmi plf
  device. AFAIR something like this is already in place in chrome-
 kernel.
 
  I've made some comments below.
 
  This patch is dependent on
  http://www.mail-archive.com/dri-
 de...@lists.freedesktop.org/msg34733.html
  http://www.mail-archive.com/dri-
 de...@lists.freedesktop.org/msg34861.html
  http://www.mail-archive.com/dri-
 

Re: [PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver

[Rahul Sharma]

On Thu, Mar 7, 2013 at 12:37 PM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:
 On Wed, Mar 6, 2013 at 8:43 PM, Inki Dae inki@samsung.com wrote:
 2013/3/7 김승우 sw0312@samsung.com:


 On 2013년 03월 04일 23:05, Rahul Sharma wrote:
 Thanks Sean,

 On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul seanp...@google.com wrote:
 On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma rahul.sha...@samsung.com 
 wrote:
 Right now hdmiphy operations and configs are kept inside hdmi driver. 
 hdmiphy related
 code is tightly coupled with hdmi ip driver. Physicaly they are 
 different devices and

 s/Physicaly/Physically/

 should be instantiated independently.

 In terms of versions/mapping/configurations Hdmi and hdmiphy are 
 independent of each
 other. It is preferred to isolate them and maintained independently.

 This implementations is tested for:
 1) Resolutions supported by exynos4 and 5 hdmi.
 2) Runtime PM and S2R scenarions for exynos5.


 I don't like the idea of spawning off yet another driver in here. It
 adds more globals, more suspend/resume ordering issues, and more
 implicit dependencies. I understand, however, that this is the Chosen
 Way for the exynos driver, so I will save my rant.


 I agree to it. splitting phy to a new driver will complicate the power 
 related
 scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of
 config values, mapping (i2c/platform bus) etc. Handling this diversity
 inside hdmi driver is complicating it with unrelated changes.

 Basically, I agree with the idea to split hdmiphy from hdmi. And it
 seems that already existing hdmiphy i2c device is just reused and
 hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling
 flow of power operations is reordered.

 But I'm not sure exynos_hdmiphy_driver_register() really need to be
 called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to
 call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy
 is only used from hdmi.


 I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem.


 But this is probably going to break dpms and/or suspend/resume
 functionality. Has that been tested?

 Stéphane

Hi Stéphane

This has been tested for dpms and suspend/resume scenarios for exynos5. I
have yet to try with hdmi, mixer, phy driver registration moved to
common-drm-hdmi.

regards,
Rahul Sharma.

 Thanks,
 Inki Dae

 Thanks and Regards,
 - Seung-Woo Kim


 I have tested this RFC for Runtime PM / S2R. But if we see any major 
 roadblock
 we should re-factor this by explicitly calling power related callbacks
 of mixer, phy,
 hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf
 device. AFAIR something like this is already in place in chrome-kernel.

 I've made some comments below.

 This patch is dependent on
 http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html
 http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html
 http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
 It is based on exynos-drm-next-todo branch at
 git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   8 +
  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   6 +
  drivers/gpu/drm/exynos/exynos_drm_hdmi.c |  58 ++-
  drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  11 +
  drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++--
  drivers/gpu/drm/exynos/exynos_hdmi.h |   1 -
  drivers/gpu/drm/exynos/exynos_hdmiphy.c  | 586 
 ++-
  drivers/gpu/drm/exynos/regs-hdmiphy.h|  61 
  8 files changed, 738 insertions(+), 368 deletions(-)
  create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h


 snip

 --
 Seung-Woo Kim
 Samsung Software RD Center
 --

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Regards,
Rahul Sharma,
email to: rahul.sha...@samsung.com
Samsung India.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61965] New: Kernel panics drm_fb_helper_restore_fbdev_mode when using Chromium

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61965

  Priority: medium
Bug ID: 61965
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Kernel panics drm_fb_helper_restore_fbdev_mode when
using Chromium
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: m...@fireburn.co.uk
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/other
   Product: DRI

Created attachment 76113
  -- https://bugs.freedesktop.org/attachment.cgi?id=76113action=edit
Screenshot

I've seen this twice now so thought I'd take a screen shot

It's only appeared since the merge window and I'm not sure how to reproduce it

Both times have mentioned Chromium

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61965] Kernel panics drm_fb_helper_restore_fbdev_mode when using Chromium

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61965

Chris Wilson ch...@chris-wilson.co.uk changed:

   What|Removed |Added

  Attachment #76113|text/plain  |image/jpeg
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61965] Kernel panics drm_fb_helper_restore_fbdev_mode when using Chromium

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61965

--- Comment #2 from Mike Lothian m...@fireburn.co.uk ---
I'm going to hazzard a guess that either
4d53233a36fdda567cd4d080e27e1ee4b669ddd1  and / or
2e928815c1886fe628ed54623aa98d0889cf5509 are most probably where the problem
lies

I can't seem to  CC Tejun Heo t...@kernel.org - am I reporting this bug to the
right place?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61965] Kernel panics drm_fb_helper_restore_fbdev_mode when using Chromium

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=61965

Mike Lothian m...@fireburn.co.uk changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #3 from Mike Lothian m...@fireburn.co.uk ---
Sorry Chris - I did do some googling but couldn't find this will try searching
for pstates - Cheers

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 4/9] video: Add generic HDMI infoframe helpers

[Lucas Stach]

Am Montag, den 04.03.2013, 16:02 +0100 schrieb Thierry Reding:
 On Mon, Mar 04, 2013 at 04:49:46PM +0200, Ville Syrjälä wrote:
  On Fri, Feb 22, 2013 at 08:03:26AM +0100, Thierry Reding wrote:
 [...]
   diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
   new file mode 100644
   index 000..ab23c9b
   --- /dev/null
   +++ b/drivers/video/hdmi.c
   @@ -0,0 +1,308 @@
   +/*
   + * Copyright (C) 2012 Avionic Design GmbH
   + *
   + * This program is free software; you can redistribute it and/or modify
   + * it under the terms of the GNU General Public License version 2 as
   + * published by the Free Software Foundation.
   + */
  
  BTW was there any discussion about the license? drm is generally MIT.
  Are people OK with depending on GPL code for infoframe support?
 
 I wasn't aware of that. I don't know how much of an issue it is really
 since all symbols are exported non-GPL.
 
 Thierry

It's not about the export of the symbols, but more about porting DRM to
other UNIXes like BSD. Using the GPL here makes life for the BSD guys a
lot harder and they are already struggling really hard to keep up with
the pace of Linux. So if you don't care too much it would be nice to use
MIT here.

Regards,
Lucas

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 4/9] video: Add generic HDMI infoframe helpers

[Thierry Reding]

On Thu, Mar 07, 2013 at 02:32:51PM +0100, Lucas Stach wrote:
 Am Montag, den 04.03.2013, 16:02 +0100 schrieb Thierry Reding:
  On Mon, Mar 04, 2013 at 04:49:46PM +0200, Ville Syrjälä wrote:
   On Fri, Feb 22, 2013 at 08:03:26AM +0100, Thierry Reding wrote:
  [...]
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
new file mode 100644
index 000..ab23c9b
--- /dev/null
+++ b/drivers/video/hdmi.c
@@ -0,0 +1,308 @@
+/*
+ * Copyright (C) 2012 Avionic Design GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
   
   BTW was there any discussion about the license? drm is generally MIT.
   Are people OK with depending on GPL code for infoframe support?
  
  I wasn't aware of that. I don't know how much of an issue it is really
  since all symbols are exported non-GPL.
  
  Thierry
 
 It's not about the export of the symbols, but more about porting DRM to
 other UNIXes like BSD. Using the GPL here makes life for the BSD guys a
 lot harder and they are already struggling really hard to keep up with
 the pace of Linux. So if you don't care too much it would be nice to use
 MIT here.

Sure, I'll relicense it under MIT then.

Thierry


pgpGWILTvYYlX.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v11 0/2] Add display-timing node parsing to exynos drm fimd

[Vikas Sajjan]

Add display-timing node parsing to drm fimd and depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

changes since v10:
- abandoned the pinctrl patch, as commented by Linus Walleij
linus.wall...@linaro.org
- added new patch to enable the OF_VIDEOMODE and FB_MODE_HELPERS for
EXYNOS DRM FIMD.

changes since v9:
- replaced IS_ERR_OR_NULL() with IS_ERR(), since IS_ERR_OR_NULL()
will be depreciated, as discussed at

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140543.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg78030.html

changes since v8:
- replaced IS_ERR() with IS_ERR_OR_NULL(),
because devm_pinctrl_get_select_default can return NULL,
If CONFIG_PINCTRL is disabled.
- modified the error log, such that it shall NOT cross 80 column.
- added Acked-by.

changes since v7:
- addressed comments from Joonyoung Shim jy0922.s...@samsung.com
to remove a unnecessary variable.

changes since v6:
addressed comments from Inki Dae inki@samsung.com to
separated out the pinctrl functionality and made a separate patch.

changes since v5:
- addressed comments from Inki Dae inki@samsung.com,
to remove the allocation of 'fbmode' and replaced
'-1'in of_get_fb_videomode(dev-of_node, fbmode, -1) with
OF_USE_NATIVE_MODE.

changes since v4:
- addressed comments from Paul Menzel
paulepan...@users.sourceforge.net, to modify the commit message

changes since v3:
- addressed comments from Sean Paul seanp...@chromium.org, to modify
the return values and print messages.

changes since v2:
- moved 'devm_pinctrl_get_select_default' function call under
'if (pdev-dev.of_node)', this makes NON-DT code unchanged.
(reported by: Rahul Sharma r.sh.o...@gmail.com)

changes since v1:
- addressed comments from Sean Paul seanp...@chromium.org

Vikas Sajjan (2):
  video: drm: exynos: Add display-timing node parsing using video
helper function
  drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm
fimd

 drivers/gpu/drm/exynos/Kconfig   |2 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   27 +++
 2 files changed, 25 insertions(+), 4 deletions(-)

-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v11 1/2] video: drm: exynos: Add display-timing node parsing using video helper function

[Vikas Sajjan]

Add support for parsing the display-timing node using video helper
function.

The DT node parsing is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..f322ec3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,7 @@
 #include linux/of_device.h
 #include linux/pm_runtime.h
 
+#include video/of_display_timing.h
 #include video/samsung_fimd.h
 #include drm/exynos_drm.h
 
@@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)
 
DRM_DEBUG_KMS(%s\n, __FILE__);
 
-   pdata = pdev-dev.platform_data;
-   if (!pdata) {
-   dev_err(dev, no platform data specified\n);
-   return -EINVAL;
+   if (pdev-dev.of_node) {
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   DRM_ERROR(memory allocation for pdata failed\n);
+   return -ENOMEM;
+   }
+
+   ret = of_get_fb_videomode(dev-of_node, pdata-panel.timing,
+   OF_USE_NATIVE_MODE);
+   if (ret) {
+   DRM_ERROR(failed: of_get_fb_videomode() : %d\n, ret);
+   return ret;
+   }
+   } else {
+   pdata = pdev-dev.platform_data;
+   if (!pdata) {
+   DRM_ERROR(no platform data specified\n);
+   return -EINVAL;
+   }
}
 
panel = pdata-panel;
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v11 2/2] drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm fimd

[Vikas Sajjan]

patch adds select OF_VIDEOMODE and select FB_MODE_HELPERS when
EXYNOS_DRM_FIMD config is selected.

Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
 drivers/gpu/drm/exynos/Kconfig |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 046bcda..bb25130 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -25,6 +25,8 @@ config DRM_EXYNOS_DMABUF
 config DRM_EXYNOS_FIMD
bool Exynos DRM FIMD
depends on DRM_EXYNOS  !FB_S3C  !ARCH_MULTIPLATFORM
+   select OF_VIDEOMODE
+   select FB_MODE_HELPERS
help
  Choose this option if you want to use Exynos FIMD for DRM.
 
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: modify the compatible string for exynos fimd

[Vikas Sajjan]

Hi Mr Inki Dae,

On 28 February 2013 08:12, Joonyoung Shim jy0922.s...@samsung.com wrote:
 On 02/27/2013 07:32 PM, Vikas Sajjan wrote:

 modified compatible string for exynos4 fimd as exynos4210-fimd and
 exynos5 fimd as exynos5250-fimd to stick to the rule that compatible
 value should be named after first specific SoC model in which this
 particular IP version was included as discussed at
 https://patchwork.kernel.org/patch/2144861/

 Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
 ---
   drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index 9537761..433ed35 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -109,9 +109,9 @@ struct fimd_context {
 #ifdef CONFIG_OF
   static const struct of_device_id fimd_driver_dt_match[] = {
 -   { .compatible = samsung,exynos4-fimd,
 +   { .compatible = samsung,exynos4210-fimd,
   .data = exynos4_fimd_driver_data },
 -   { .compatible = samsung,exynos5-fimd,
 +   { .compatible = samsung,exynos5250-fimd,
   .data = exynos5_fimd_driver_data },
 {},
   };


 Acked-by: Joonyoung Shim jy0922.s...@samsung.com

Can you please apply this patch.


 Thanks.



-- 
Thanks and Regards
 Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: modify the compatible string for exynos fimd

[Vikas Sajjan]

Thanks.

On 7 March 2013 12:47, Inki Dae inki@samsung.com wrote:
 Already merged. :)

 -Original Message-
 From: Vikas Sajjan [mailto:vikas.saj...@linaro.org]
 Sent: Thursday, March 07, 2013 4:09 PM
 To: InKi Dae
 Cc: dri-devel@lists.freedesktop.org; linux-me...@vger.kernel.org;
 kgene@samsung.com; Joonyoung Shim; sunil joshi
 Subject: Re: [PATCH] drm/exynos: modify the compatible string for exynos
 fimd

 Hi Mr Inki Dae,

 On 28 February 2013 08:12, Joonyoung Shim jy0922.s...@samsung.com wrote:
  On 02/27/2013 07:32 PM, Vikas Sajjan wrote:
 
  modified compatible string for exynos4 fimd as exynos4210-fimd and
  exynos5 fimd as exynos5250-fimd to stick to the rule that compatible
  value should be named after first specific SoC model in which this
  particular IP version was included as discussed at
  https://patchwork.kernel.org/patch/2144861/
 
  Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
  ---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  index 9537761..433ed35 100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  @@ -109,9 +109,9 @@ struct fimd_context {
  #ifdef CONFIG_OF
static const struct of_device_id fimd_driver_dt_match[] = {
  -   { .compatible = samsung,exynos4-fimd,
  +   { .compatible = samsung,exynos4210-fimd,
.data = exynos4_fimd_driver_data },
  -   { .compatible = samsung,exynos5-fimd,
  +   { .compatible = samsung,exynos5250-fimd,
.data = exynos5_fimd_driver_data },
  {},
};
 
 
  Acked-by: Joonyoung Shim jy0922.s...@samsung.com

 Can you please apply this patch.

 
  Thanks.



 --
 Thanks and Regards
  Vikas Sajjan




-- 
Thanks and Regards
 Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v12 0/2] Add display-timing node parsing to exynos drm fimd

[Vikas Sajjan]

Add display-timing node parsing to drm fimd and depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

changes since v11:
- Oops, there was a build error, fixed that.

changes since v10:
- abandoned the pinctrl patch, as commented by Linus Walleij
linus.wall...@linaro.org
- added new patch to enable the OF_VIDEOMODE and FB_MODE_HELPERS for
EXYNOS DRM FIMD.

changes since v9:
- replaced IS_ERR_OR_NULL() with IS_ERR(), since IS_ERR_OR_NULL()
will be depreciated, as discussed at

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140543.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg78030.html

changes since v8:
- replaced IS_ERR() with IS_ERR_OR_NULL(),
because devm_pinctrl_get_select_default can return NULL,
If CONFIG_PINCTRL is disabled.
- modified the error log, such that it shall NOT cross 80 column.
- added Acked-by.

changes since v7:
- addressed comments from Joonyoung Shim jy0922.s...@samsung.com
to remove a unnecessary variable.

changes since v6:
addressed comments from Inki Dae inki@samsung.com to
separated out the pinctrl functionality and made a separate patch.

changes since v5:
- addressed comments from Inki Dae inki@samsung.com,
to remove the allocation of 'fbmode' and replaced
'-1'in of_get_fb_videomode(dev-of_node, fbmode, -1) with
OF_USE_NATIVE_MODE.

changes since v4:
- addressed comments from Paul Menzel
paulepan...@users.sourceforge.net, to modify the commit message

changes since v3:
- addressed comments from Sean Paul seanp...@chromium.org, to modify
the return values and print messages.

changes since v2:
- moved 'devm_pinctrl_get_select_default' function call under
'if (pdev-dev.of_node)', this makes NON-DT code unchanged.
(reported by: Rahul Sharma r.sh.o...@gmail.com)

changes since v1:
- addressed comments from Sean Paul seanp...@chromium.org

Vikas Sajjan (2):
  video: drm: exynos: Add display-timing node parsing using video
helper function
  drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm
fimd

 drivers/gpu/drm/exynos/Kconfig   |2 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   27 +++
 2 files changed, 25 insertions(+), 4 deletions(-)

-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v12 1/2] video: drm: exynos: Add display-timing node parsing using video helper function

[Vikas Sajjan]

Add support for parsing the display-timing node using video helper
function.

The DT node parsing is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..e323cf9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,7 @@
 #include linux/of_device.h
 #include linux/pm_runtime.h
 
+#include video/of_display_timing.h
 #include video/samsung_fimd.h
 #include drm/exynos_drm.h
 
@@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)
 
DRM_DEBUG_KMS(%s\n, __FILE__);
 
-   pdata = pdev-dev.platform_data;
-   if (!pdata) {
-   dev_err(dev, no platform data specified\n);
-   return -EINVAL;
+   if (pdev-dev.of_node) {
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   DRM_ERROR(memory allocation for pdata failed\n);
+   return -ENOMEM;
+   }
+
+   ret = of_get_fb_videomode(dev-of_node, pdata-panel.timing,
+   OF_USE_NATIVE_MODE);
+   if (ret) {
+   DRM_ERROR(failed: of_get_fb_videomode() : %d\n, ret);
+   return ret;
+   }
+   } else {
+   pdata = pdev-dev.platform_data;
+   if (!pdata) {
+   DRM_ERROR(no platform data specified\n);
+   return -EINVAL;
+   }
}
 
panel = pdata-panel;
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v12 2/2] drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm fimd

[Vikas Sajjan]

patch adds select OF_VIDEOMODE and select FB_MODE_HELPERS when
EXYNOS_DRM_FIMD config is selected.

Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
 drivers/gpu/drm/exynos/Kconfig |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 046bcda..bb25130 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -25,6 +25,8 @@ config DRM_EXYNOS_DMABUF
 config DRM_EXYNOS_FIMD
bool Exynos DRM FIMD
depends on DRM_EXYNOS  !FB_S3C  !ARCH_MULTIPLATFORM
+   select OF_VIDEOMODE
+   select FB_MODE_HELPERS
help
  Choose this option if you want to use Exynos FIMD for DRM.
 
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V3] drm/exynos: fimd: calculate the correct address offset

[Leela Krishna Amudala]

Calculate the correct address offset values for alpha and color key
control registers based on exynos4 and exynos5 user manuals.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..f5f2b25 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -38,11 +38,12 @@
 /* position control register for hardware window 0, 2 ~ 4.*/
 #define VIDOSD_A(win)  (VIDOSD_BASE + 0x00 + (win) * 16)
 #define VIDOSD_B(win)  (VIDOSD_BASE + 0x04 + (win) * 16)
-/* size control register for hardware window 0. */
-#define VIDOSD_C_SIZE_W0   (VIDOSD_BASE + 0x08)
-/* alpha control register for hardware window 1 ~ 4. */
-#define VIDOSD_C(win)  (VIDOSD_BASE + 0x18 + (win) * 16)
-/* size control register for hardware window 1 ~ 4. */
+/*
+ * size control register for hardware windows 0 and alpha control register
+ * for hardware windows 1 ~ 4
+ */
+#define VIDOSD_C(win)  (VIDOSD_BASE + 0x08 + (win) * 16)
+/* size control register for hardware windows 1 ~ 2. */
 #define VIDOSD_D(win)  (VIDOSD_BASE + 0x0C + (win) * 16)
 
 #define VIDWx_BUF_START(win, buf)  (VIDW_BUF_START(buf) + (win) * 8)
@@ -50,9 +51,9 @@
 #define VIDWx_BUF_SIZE(win, buf)   (VIDW_BUF_SIZE(buf) + (win) * 4)
 
 /* color key control register for hardware window 1 ~ 4. */
-#define WKEYCON0_BASE(x)   ((WKEYCON0 + 0x140) + (x * 8))
+#define WKEYCON0_BASE(x)   ((WKEYCON0 + 0x140) + ((x - 1) * 8))
 /* color key value register for hardware window 1 ~ 4. */
-#define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + (x * 8))
+#define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + ((x - 1) * 8))
 
 /* FIMD has totally five hardware windows. */
 #define WINDOWS_NR 5
@@ -581,7 +582,7 @@ static void fimd_win_commit(struct device *dev, int zpos)
if (win != 3  win != 4) {
u32 offset = VIDOSD_D(win);
if (win == 0)
-   offset = VIDOSD_C_SIZE_W0;
+   offset = VIDOSD_C(win);
val = win_data-ovl_width * win_data-ovl_height;
writel(val, ctx-regs + offset);
 
-- 
1.8.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Black screen with nouveau in 3.8.x (regression)

[Nick Bowler]

Hi folks,

Yesterday I upgraded one of my machines to 3.8.2 from 3.6.6.  This
machine has an old NV36 AGP board.  With the new kernel, as soon as
nouveau takes over the console the display connected via DVI goes dark
(the monitor goes into standby mode).  The display connected via VGA
continues to work fine.

Starting Xorg does not correct the problem.  Nouveau seems to know
that the display is connected:

  % cat /sys/class/drm/card0-DVI-I-1/status
  connected

I don't see anything unusual in the log either (full log attached):

  % dmesg -t | grep -iE 'drm|nouveau'
  [drm] Initialized drm 1.1.0 20060810
  nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x436200a1
  nouveau  [  DEVICE][:01:00.0] Chipset: NV36 (NV36)
  nouveau  [  DEVICE][:01:00.0] Family : NV30
  nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
  nouveau  [   VBIOS][:01:00.0] ... appears to be valid
  nouveau  [   VBIOS][:01:00.0] using image from PRAMIN
  nouveau  [   VBIOS][:01:00.0] BMP version 5.28
  nouveau  [   VBIOS][:01:00.0] version 04.36.20.21
  nouveau W[  PTIMER][:01:00.0] unknown input clock freq
  nouveau  [ PFB][:01:00.0] RAM type: DDR1
  nouveau  [ PFB][:01:00.0] RAM size: 256 MiB
  nouveau :01:00.0: putting AGP V3 device into 8x mode
  nouveau  [ DRM] VRAM: 255 MiB
  nouveau  [ DRM] GART: 64 MiB
  nouveau  [ DRM] BMP BIOS found
  nouveau  [ DRM] BMP version 5.40
  nouveau  [ DRM] Bios version 04.36.20.21
  nouveau  [ DRM] DCB version 2.2
  nouveau  [ DRM] DCB outp 00: 01000300 9c40
  nouveau  [ DRM] DCB outp 01: 02010310 9c40
  nouveau  [ DRM] DCB outp 02: 04000302 
  nouveau  [ DRM] DCB outp 03: 02020321 0303
  nouveau  [ DRM] Loading NV17 power sequencing microcode
  nouveau  [ DRM] Saving VGA fonts
  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
  [drm] No driver support for vblank timestamp query.
  nouveau  [ DRM] 0xE51A: Parsing digital output script table
  nouveau  [ DRM] 0 available performance level(s)
  nouveau  [ DRM] c: core 425MHz memory 501MHz voltage 1350mV
  nouveau  [ DRM] MM: using M2MF for buffer copies
  nouveau  [ DRM] Setting dpms mode 3 on vga encoder (output 0)
  nouveau  [ DRM] Setting dpms mode 3 on vga encoder (output 1)
  nouveau  [ DRM] Setting dpms mode 3 on tmds encoder (output 2)
  nouveau  [ DRM] Setting dpms mode 3 on TV encoder (output 3)
  nouveau  [ DRM] allocated 1280x1024 fb: 0x9000, bo 88007b6ae000
  fbcon: nouveaufb (fb0) is primary device
  nouveau  [ DRM] 0xE51A: Parsing digital output script table
  nouveau  [ DRM] Setting dpms mode 0 on tmds encoder (output 2)
  nouveau  [ DRM] Output DVI-I-1 is running on CRTC 0 using output C
  nouveau  [ DRM] Setting dpms mode 0 on vga encoder (output 1)
  nouveau  [ DRM] Output VGA-1 is running on CRTC 1 using output B
  fb0: nouveaufb frame buffer device
  drm: registered panic notifier
  [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on minor 0

I started a bisection... here's the first steps so far.  I will try to
finish the procedure over the next couple days but I'm reporting this
now in case someone needs me to get some other info.

  git bisect start 'drivers/gpu/drm'
  # good: [3820288942d1c1524c3ee85cbf503fee1533cfc3] Linux 3.6.6
  git bisect good 3820288942d1c1524c3ee85cbf503fee1533cfc3
  # bad: [19b00d2dc9bedf0856e366cb7b9c7733ded659e4] Linux 3.8.2
  git bisect bad 19b00d2dc9bedf0856e366cb7b9c7733ded659e4
  # good: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6
  git bisect good a0d271cbfed1dd50278c6b06bead3d00ba0a88f9
  # bad: [daed2dbb7ea4d179e472396ce46377fe758d5faf] drm/i915: use the CPU and 
PCH transcoders on lpt_pch_enable
  git bisect bad daed2dbb7ea4d179e472396ce46377fe758d5faf
  # good: [df86b5765a48d5f557489577652bd6df145b0e1b] drm/savage: re-add 
busmaster enable, regression fix
  git bisect good df86b5765a48d5f557489577652bd6df145b0e1b
  # bad: [39df01cd6ce9f6dd755ace0030e2bebe75da7727] Merge branch 
'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
  git bisect bad 39df01cd6ce9f6dd755ace0030e2bebe75da7727

Thanks,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)


nouveau-black-lcd.log.xz
Description: application/xz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] mgag200 fix plus documentation typo fixes

[Christopher Harvey]

This is a fix for mgag200 cards that is well documented in the commit
message. Also includes some typo fixes that were bugging me.

Christopher Harvey (1):
  drm: Documentation typo fixes

Julia Lemire (1):
  drm/mgag200: Bug fix: Renesas board now selects native resolution.

 drivers/gpu/drm/mgag200/mgag200_i2c.c | 1 +
 include/drm/drm_crtc.h| 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)

-- 
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm: Documentation typo fixes

[Christopher Harvey]

Signed-off-by: Christopher Harvey char...@matrox.com
---
 include/drm/drm_crtc.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 00d78b5..7294403 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -429,12 +429,12 @@ struct drm_crtc {
  * @dpms: set power state (see drm_crtc_funcs above)
  * @save: save connector state
  * @restore: restore connector state
- * @reset: reset connector after state has been invalidate (e.g. resume)
+ * @reset: reset connector after state has been invalidated (e.g. resume)
  * @detect: is this connector active?
  * @fill_modes: fill mode list for this connector
- * @set_property: property for this connector may need update
+ * @set_property: property for this connector may need an update
  * @destroy: make object go away
- * @force: notify the driver the connector is forced on
+ * @force: notify the driver that the connector is forced on
  *
  * Each CRTC may have one or more connectors attached to it.  The functions
  * below allow the core DRM code to control connectors, enumerate available 
modes,
-- 
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/mgag200: Bug fix: Renesas board now selects native resolution.

[Julia Lemire]

Renesas boards were consistently defaulting to the 1024x768 resolution,
regardless of the native resolution of the monitor plugged in.  It was
determined that the EDID of the monitor was not being read.  Since the
DAC is a shared line, in order to read from or write to it we must take
control of the DAC clock.  This can be done by setting the proper
register to one.

This bug fix sets the register MGA1064_GEN_IO_CTL2 to one.  The DAC
control line can be used to determine whether or not a new monitor has
been plugged in.  But since the hotplug feature is not one we will
support, it has been decided to simply leave the register set to one.

Signed-off-by: Julia Lemire jlem...@matrox.com
---
 drivers/gpu/drm/mgag200/mgag200_i2c.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mgag200/mgag200_i2c.c 
b/drivers/gpu/drm/mgag200/mgag200_i2c.c
index 5a88ec5..d3dcf54 100644
--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -92,6 +92,7 @@ struct mga_i2c_chan *mgag200_i2c_create(struct drm_device 
*dev)
int ret;
int data, clock;
 
+   WREG_DAC(MGA1064_GEN_IO_CTL2, 1);
WREG_DAC(MGA1064_GEN_IO_DATA, 0xff);
WREG_DAC(MGA1064_GEN_IO_CTL, 0);
 
-- 
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Wrong vsync offset calculation in drm_edid.c

[Peter Blum]

This patch is a bug fix for the file drm_edid.c of the kernel 3.8.

The vsync offset is calculated wrong from the EDID set because of the 
wrong shift direction.
We could measure the bad old setting and also the good new setting after 
the bug fix.



Signed-off-by: Peter Blum peter.b...@lxco.com


diff -Naur a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
--- a/drivers/gpu/drm/drm_edid.c2013-02-19 00:58:34.0 +0100
+++ b/drivers/gpu/drm/drm_edid.c2013-03-07 12:04:24.527609783 +0100
@@ -893,7 +893,7 @@
unsigned vblank = (pt-vactive_vblank_hi  0xf)  8 | 
pt-vblank_lo;
unsigned hsync_offset = (pt-hsync_vsync_offset_pulse_width_hi 
 0xc0)  2 | pt-hsync_offset_lo;
unsigned hsync_pulse_width = 
(pt-hsync_vsync_offset_pulse_width_hi  0x30)  4 | 
pt-hsync_pulse_width_lo;
-   unsigned vsync_offset = (pt-hsync_vsync_offset_pulse_width_hi  
0xc)  2 | pt-vsync_offset_pulse_width_lo  4;
+   unsigned vsync_offset = (pt-hsync_vsync_offset_pulse_width_hi  
0xc)  2 | pt-vsync_offset_pulse_width_lo  4;
unsigned vsync_pulse_width = 
(pt-hsync_vsync_offset_pulse_width_hi  0x3)  4 | 
(pt-vsync_offset_pulse_width_lo  0xf);


/* ignore tiny modes */




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon drm-fixes-3.9

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Hi Dave,

  Radeon fixes pull.  Not much to it.
  - fix some splatter if the interrupt handler isn't registered
  - Add a quirk for an old R200 board to fix washed out colors on the DAC
  - Don't try and soft reset the MC when we reset the GPU.  It usually doesn't
need it and doesn't always work reliably.
  - A CS checker fix from Marek

The following changes since commit 2cc79544bd0aabb4b3cf467ead5df526d9134c64:

  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2013-03-07 
11:12:14 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.9

Alex Deucher (3):
  drm/radeon: don't set hpd, afmt interrupts when interrupts are disabled
  drm/radeon: add primary dac adj quirk for R200 board
  drm/radeon: skip MC reset as it's probably not hung

Marek Olšák (1):
  drm/radeon: don't check mipmap alignment if MIP_ADDRESS is FMASK

 drivers/gpu/drm/radeon/evergreen.c  |6 ++
 drivers/gpu/drm/radeon/evergreen_cs.c   |2 +-
 drivers/gpu/drm/radeon/ni.c |6 ++
 drivers/gpu/drm/radeon/r600.c   |6 ++
 drivers/gpu/drm/radeon/radeon_combios.c |9 +
 drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
 drivers/gpu/drm/radeon/radeon_irq_kms.c |   12 
 drivers/gpu/drm/radeon/si.c |6 ++
 8 files changed, 48 insertions(+), 2 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58042] [bisected] Garbled UI in Team Fortress 2 and Counter-Strike: Source

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=58042

d...@stuffit.at changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #32 from d...@stuffit.at ---
Tested and works for me!

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V3] drm/exynos: fimd: calculate the correct address offset

[Joonyoung Shim]

On 03/07/2013 06:42 PM, Leela Krishna Amudala wrote:

Calculate the correct address offset values for alpha and color key
control registers based on exynos4 and exynos5 user manuals.


+ remove VIDOSD_C_SIZE_W0 macro and fix comments about registers for
size and alpha.


Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +
  1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..f5f2b25 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -38,11 +38,12 @@
  /* position control register for hardware window 0, 2 ~ 4.*/
  #define VIDOSD_A(win) (VIDOSD_BASE + 0x00 + (win) * 16)
  #define VIDOSD_B(win) (VIDOSD_BASE + 0x04 + (win) * 16)
-/* size control register for hardware window 0. */
-#define VIDOSD_C_SIZE_W0   (VIDOSD_BASE + 0x08)
-/* alpha control register for hardware window 1 ~ 4. */
-#define VIDOSD_C(win)  (VIDOSD_BASE + 0x18 + (win) * 16)
-/* size control register for hardware window 1 ~ 4. */
+/*
+ * size control register for hardware windows 0 and alpha control register
+ * for hardware windows 1 ~ 4
+ */
+#define VIDOSD_C(win)  (VIDOSD_BASE + 0x08 + (win) * 16)
+/* size control register for hardware windows 1 ~ 2. */
  #define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
  
  #define VIDWx_BUF_START(win, buf)	(VIDW_BUF_START(buf) + (win) * 8)

@@ -50,9 +51,9 @@
  #define VIDWx_BUF_SIZE(win, buf)  (VIDW_BUF_SIZE(buf) + (win) * 4)
  
  /* color key control register for hardware window 1 ~ 4. */

-#define WKEYCON0_BASE(x)   ((WKEYCON0 + 0x140) + (x * 8))
+#define WKEYCON0_BASE(x)   ((WKEYCON0 + 0x140) + ((x - 1) * 8))
  /* color key value register for hardware window 1 ~ 4. */
-#define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + (x * 8))
+#define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + ((x - 1) * 8))
  
  /* FIMD has totally five hardware windows. */

  #define WINDOWS_NR5
@@ -581,7 +582,7 @@ static void fimd_win_commit(struct device *dev, int zpos)
if (win != 3  win != 4) {
u32 offset = VIDOSD_D(win);
if (win == 0)
-   offset = VIDOSD_C_SIZE_W0;
+   offset = VIDOSD_C(win);
val = win_data-ovl_width * win_data-ovl_height;
writel(val, ctx-regs + offset);
  


Acked-by: Joonyoung Shim jy0922.s...@samsung.com

Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not
be used anymore.

Only user is ACPI_OVERRIDE, and it should not use that, as later
accessing is using early_remap. Change to try to 4G below and
then 4G above.

Other user is in drm/i915, but it is commented out.

Should use arch_pfn_mapped or just 1(32-PAGE_SHIFT) instead.

Suggested-by: H. Peter Anvin h...@linux.intel.com
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Thomas Renninger tr...@suse.de
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: David Airlie airl...@linux.ie
Cc: Jacob Shin jacob.s...@amd.com
Cc: linux-a...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
 arch/x86/include/asm/page_types.h  |1 -
 arch/x86/kernel/setup.c|4 +---
 arch/x86/mm/init.c |4 
 drivers/acpi/osl.c |9 ++---
 drivers/gpu/drm/i915/i915_gem_stolen.c |2 +-
 5 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/page_types.h 
b/arch/x86/include/asm/page_types.h
index 54c9787..b012b82 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -43,7 +43,6 @@
 
 extern int devmem_is_allowed(unsigned long pagenr);
 
-extern unsigned long max_low_pfn_mapped;
 extern unsigned long max_pfn_mapped;
 
 static inline phys_addr_t get_max_mapped(void)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 90d8cc9..4dcaae7 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -113,13 +113,11 @@
 #include asm/prom.h
 
 /*
- * max_low_pfn_mapped: highest direct mapped pfn under 4GB
- * max_pfn_mapped: highest direct mapped pfn over 4GB
+ * max_pfn_mapped: highest direct mapped pfn
  *
  * The direct mapping only covers E820_RAM regions, so the ranges and gaps are
  * represented by pfn_mapped
  */
-unsigned long max_low_pfn_mapped;
 unsigned long max_pfn_mapped;
 
 #ifdef CONFIG_DMI
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 59b7fc4..abcc241 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -313,10 +313,6 @@ static void add_pfn_range_mapped(unsigned long start_pfn, 
unsigned long end_pfn)
nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);
 
max_pfn_mapped = max(max_pfn_mapped, end_pfn);
-
-   if (start_pfn  (1UL(32-PAGE_SHIFT)))
-   max_low_pfn_mapped = max(max_low_pfn_mapped,
-min(end_pfn, 1UL(32-PAGE_SHIFT)));
 }
 
 bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 586e7e9..c9e36d7 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -624,9 +624,12 @@ void __init acpi_initrd_override(void *data, size_t size)
if (table_nr == 0)
return;
 
-   acpi_tables_addr =
-   memblock_find_in_range(0, max_low_pfn_mapped  PAGE_SHIFT,
-  all_tables_size, PAGE_SIZE);
+   /* under 4G at first, then above 4G */
+   acpi_tables_addr = memblock_find_in_range(0, 1ULL32,
+   all_tables_size, PAGE_SIZE);
+   if (!acpi_tables_addr)
+   acpi_tables_addr = memblock_find_in_range(1ULL32, -1ULL,
+   all_tables_size, PAGE_SIZE);
if (!acpi_tables_addr) {
WARN_ON(1);
return;
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 69d97cb..7f9380b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
drm_device *dev)
base -= dev_priv-mm.gtt-stolen_size;
} else {
/* Stolen is immediately above Top of Memory */
-   base = max_low_pfn_mapped  PAGE_SHIFT;
+   base = __REMOVED_CRAZY__  PAGE_SHIFT;
 #endif
}
 
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Tejun Heo]

On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index 69d97cb..7f9380b 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
 drm_device *dev)
   base -= dev_priv-mm.gtt-stolen_size;
   } else {
   /* Stolen is immediately above Top of Memory */
 - base = max_low_pfn_mapped  PAGE_SHIFT;
 + base = __REMOVED_CRAZY__  PAGE_SHIFT;

Huh?

-- 
tejun
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo t...@kernel.org wrote:
 On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index 69d97cb..7f9380b 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
 drm_device *dev)
   base -= dev_priv-mm.gtt-stolen_size;
   } else {
   /* Stolen is immediately above Top of Memory */
 - base = max_low_pfn_mapped  PAGE_SHIFT;
 + base = __REMOVED_CRAZY__  PAGE_SHIFT;

 Huh?

Whole function:

static unsigned long i915_stolen_to_physical(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct pci_dev *pdev = dev_priv-bridge_dev;
u32 base;

/* On the machines I have tested the Graphics Base of Stolen Memory
 * is unreliable, so on those compute the base by subtracting the
 * stolen memory from the Top of Low Usable DRAM which is where the
 * BIOS places the graphics stolen memory.
 *
 * On gen2, the layout is slightly different with the Graphics Segment
 * immediately following Top of Memory (or Top of Usable DRAM). Note
 * it appears that TOUD is only reported by 865g, so we just use the
 * top of memory as determined by the e820 probe.
 *
 * XXX gen2 requires an unavailable symbol and 945gm fails with
 * its value of TOLUD.
 */
base = 0;
if (INTEL_INFO(dev)-gen = 6) {
/* Read Base Data of Stolen Memory Register (BDSM) directly.
 * Note that there is also a MCHBAR miror at 0x1080c0 or
 * we could use device 2:0x5c instead.
*/
pci_read_config_dword(pdev, 0xB0, base);
base = ~4095; /* lower bits used for locking register */
} else if (INTEL_INFO(dev)-gen  3 || IS_G33(dev)) {
/* Read Graphics Base of Stolen Memory directly */
pci_read_config_dword(pdev, 0xA4, base);
#if 0
} else if (IS_GEN3(dev)) {
u8 val;
/* Stolen is immediately below Top of Low Usable DRAM */
pci_read_config_byte(pdev, 0x9c, val);
base = val  3  27;
base -= dev_priv-mm.gtt-stolen_size;
} else {
/* Stolen is immediately above Top of Memory */
base = __REMOVED_CRAZY__  PAGE_SHIFT;
#endif
}

return base;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Tejun Heo]

On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu ying...@kernel.org wrote:
 On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo t...@kernel.org wrote:
 On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index 69d97cb..7f9380b 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
 drm_device *dev)
   base -= dev_priv-mm.gtt-stolen_size;
   } else {
   /* Stolen is immediately above Top of Memory */
 - base = max_low_pfn_mapped  PAGE_SHIFT;
 + base = __REMOVED_CRAZY__  PAGE_SHIFT;

 Huh?

 Whole function:

Yeah, but can't we still just do 1LLU  32 like other places? Or at
least explain what was there before? It's gonna confuse the hell out
of future readers of the code.

-- 
tejun
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

On Thu, Mar 7, 2013 at 9:25 PM, Tejun Heo t...@kernel.org wrote:
 On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu ying...@kernel.org wrote:
 On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo t...@kernel.org wrote:
 On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index 69d97cb..7f9380b 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
 drm_device *dev)
   base -= dev_priv-mm.gtt-stolen_size;
   } else {
   /* Stolen is immediately above Top of Memory */
 - base = max_low_pfn_mapped  PAGE_SHIFT;
 + base = __REMOVED_CRAZY__  PAGE_SHIFT;

 Huh?

 Whole function:

 Yeah, but can't we still just do 1LLU  32 like other places? Or at
 least explain what was there before? It's gonna confuse the hell out
 of future readers of the code.

They are not using memblock_find_in_range(), so 1ULL will not help.

Really hope i915 drm guys could clean that hacks.

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Tejun Heo]

On Thu, Mar 7, 2013 at 9:27 PM, Yinghai Lu ying...@kernel.org wrote:
 They are not using memblock_find_in_range(), so 1ULL will not help.

 Really hope i915 drm guys could clean that hacks.

The code isn't being used.  Just leave it alone.  Maybe add a comment.
 The change is just making things more confusing.

-- 
tejun
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v12 2/2] drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm fimd

[Vikas Sajjan]

Hi Mr. Dae,

On 7 March 2013 13:34, Inki Dae inki@samsung.com wrote:


 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Vikas Sajjan
 Sent: Thursday, March 07, 2013 4:40 PM
 To: dri-devel@lists.freedesktop.org
 Cc: linux-me...@vger.kernel.org; kgene@samsung.com;
 inki@samsung.com; l.kris...@samsung.com; jo...@samsung.com; linaro-
 ker...@lists.linaro.org
 Subject: [PATCH v12 2/2] drm/exynos: enable OF_VIDEOMODE and
 FB_MODE_HELPERS for exynos drm fimd

 patch adds select OF_VIDEOMODE and select FB_MODE_HELPERS when
 EXYNOS_DRM_FIMD config is selected.

 Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
 ---
  drivers/gpu/drm/exynos/Kconfig |2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/gpu/drm/exynos/Kconfig
 b/drivers/gpu/drm/exynos/Kconfig
 index 046bcda..bb25130 100644
 --- a/drivers/gpu/drm/exynos/Kconfig
 +++ b/drivers/gpu/drm/exynos/Kconfig
 @@ -25,6 +25,8 @@ config DRM_EXYNOS_DMABUF
  config DRM_EXYNOS_FIMD
   bool Exynos DRM FIMD
   depends on DRM_EXYNOS  !FB_S3C  !ARCH_MULTIPLATFORM

 Again, you missed 'OF' dependency. At least, let's have build testing surely
 before posting :)

 Surely will add  depends on OF  DRM_EXYNOS  !FB_S3C 
!ARCH_MULTIPLATFORM 
and repost.

 Thanks,
 Inki Dae

 + select OF_VIDEOMODE
 + select FB_MODE_HELPERS
   help
 Choose this option if you want to use Exynos FIMD for DRM.

 --
 1.7.9.5

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html




-- 
Thanks and Regards
 Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V4] drm/exynos: fimd: calculate the correct address offset

[Leela Krishna Amudala]

Calculate the correct address offset values for alpha and color key
control registers based on exynos4 and exynos5 user manuals.
Also remove VIDOSD_C_SIZE_W0 macro and fix comments about registers for
size and alpha.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..f5f2b25 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -38,11 +38,12 @@
 /* position control register for hardware window 0, 2 ~ 4.*/
 #define VIDOSD_A(win)  (VIDOSD_BASE + 0x00 + (win) * 16)
 #define VIDOSD_B(win)  (VIDOSD_BASE + 0x04 + (win) * 16)
-/* size control register for hardware window 0. */
-#define VIDOSD_C_SIZE_W0   (VIDOSD_BASE + 0x08)
-/* alpha control register for hardware window 1 ~ 4. */
-#define VIDOSD_C(win)  (VIDOSD_BASE + 0x18 + (win) * 16)
-/* size control register for hardware window 1 ~ 4. */
+/*
+ * size control register for hardware windows 0 and alpha control register
+ * for hardware windows 1 ~ 4
+ */
+#define VIDOSD_C(win)  (VIDOSD_BASE + 0x08 + (win) * 16)
+/* size control register for hardware windows 1 ~ 2. */
 #define VIDOSD_D(win)  (VIDOSD_BASE + 0x0C + (win) * 16)
 
 #define VIDWx_BUF_START(win, buf)  (VIDW_BUF_START(buf) + (win) * 8)
@@ -50,9 +51,9 @@
 #define VIDWx_BUF_SIZE(win, buf)   (VIDW_BUF_SIZE(buf) + (win) * 4)
 
 /* color key control register for hardware window 1 ~ 4. */
-#define WKEYCON0_BASE(x)   ((WKEYCON0 + 0x140) + (x * 8))
+#define WKEYCON0_BASE(x)   ((WKEYCON0 + 0x140) + ((x - 1) * 8))
 /* color key value register for hardware window 1 ~ 4. */
-#define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + (x * 8))
+#define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + ((x - 1) * 8))
 
 /* FIMD has totally five hardware windows. */
 #define WINDOWS_NR 5
@@ -581,7 +582,7 @@ static void fimd_win_commit(struct device *dev, int zpos)
if (win != 3  win != 4) {
u32 offset = VIDOSD_D(win);
if (win == 0)
-   offset = VIDOSD_C_SIZE_W0;
+   offset = VIDOSD_C(win);
val = win_data-ovl_width * win_data-ovl_height;
writel(val, ctx-regs + offset);
 
-- 
1.8.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[H. Peter Anvin]

On 03/07/2013 09:28 PM, Tejun Heo wrote:
 On Thu, Mar 7, 2013 at 9:27 PM, Yinghai Lu ying...@kernel.org wrote:
 They are not using memblock_find_in_range(), so 1ULL will not help.

 Really hope i915 drm guys could clean that hacks.
 
 The code isn't being used.  Just leave it alone.  Maybe add a comment.
  The change is just making things more confusing.
 

Indeed, but...

Daniel: can you guys clean this up or can we just remove the #if 0 clause?

-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel