[RFC v2] Revive the work on render-nodes branch

[Ville Syrjälä]

On Thu, Apr 12, 2012 at 02:19:25PM -0400, Ilija Hadzic wrote:
> The following set of patches is the reword of the series
> sent two weeks ago [2] that will revive the drm-render-nodes [1]
> branch. Details of the original series are described in [2].
> 
> Patches in this series have been reworked (and a few prep patches
> have been added) to address the comment about the planes support
> (planes can now be included in the resource list for the render
> node).
> 
> Consequently, the ioctls have changed to include plane support
> so the libdrm side is also affected (patches for libdrm will be sent
> in the series following this one).

Didn't have time for a detailed look yet, but at least one thing 
missing from your patch set is handling of possible_crtcs and
possible_clones for getplane and getencoder ioctls. AFAICT the
bits in those are supposed to tell you the index of the object ID
in the getresources reply. So when queried via a "render node",
some form of remapping must be performed.

Also the name "render node" is still very confusing. How about just
callling it a partition or something. Or maybe someone could suggest
a more self explanatory name for this stuff.

-- 
Ville Syrj?l?
Intel OTC

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

[Rodrigo Vivi]

Hi Ajax and Takashi,

Thanks for your comments.

> The intent here is great, but I don't like the way this is phrased, or
> the implementation.

To be honest I don't like this implementation as well. I just tried to
follow the way it wasa already there.

> CVT monitors _must_ accept GTF as well, EDID says so.  So functionally
> there's nothing wrong with the existing code.

Actually the current code just check for gtf flag... so if a monitor
is gtf2 or cvt this dmt modes are not being added.

>The thing you're trying
> to sneak in here is a 1600x900 timing that doesn't correspond to
> anything in DMT (at least, not in the copy of DMT that I have handy).
> It's fine to want to add more modes - although I'm still unclear exactly
> which machine you're trying to compensate for here - but not if it comes
> by sacrificing the DMT list, which is there for a reason.

There are customers complaining about lots of missing modes that are
supported by windows and/or other drivers and we are missing. If this
modes are ok on edid spec I se no problem in add them... ok.. I don't
like hardcoded as well... I think we could find another way to invent
this modes and use the cvt function to calculate timings... or
something like that.

>> + /* 900x600 at 60Hz */
>> + { DRM_MODE("900x600", DRM_MODE_TYPE_DRIVER, 45250, 960, 992,
>> +1088, 1216, 0, 600, 603, 609, 624, 0,
>> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },

This one I copied from windows...

>> + /* 1024x576 at 60Hz */
>> + { DRM_MODE("1024x576", DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
>> +1160, 1296, 0, 576, 579, 584, 599, 0,
>> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
>> + /* 2560x1600 at 60Hz */
>> + { DRM_MODE("2560x1600", DRM_MODE_TYPE_DRIVER, 348500, 2560, 2760,
>> +3032, 3504, 0, 1600, 1603, 1609, 1658, 0,
>> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },

These ones came as request from HP.
I'll check how they made that list.

> I tested the patch but it doesn't detect the desired resolutions such
> as 1600x900 or 1366x768, unfortunately.

:( That is said...
So I see no other way of doing this hardcoded...
add them for any monitor isn't good...

>
> Also, about the patch:
>
>
>> +static const struct drm_display_mode drm_cvt_inferred_modes[] = {
>> + ? ? /* 640x480 at 60Hz */
>> + ? ? { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 23750 ?640, 664,
>
> A missing comma here.

Sorry, I fixed here and ammend to my commit but forgot to format-patch
again before send-email

Thanks
Rodrigo.

[RFC 4/4] drm: Add NVIDIA Tegra support

[Thierry Reding]

* Stephen Warren wrote:
> On 04/12/2012 12:50 AM, Thierry Reding wrote:
> > drm {
> > compatible = "nvidia,tegra20-drm";
> 
> I'm don't think having an explicit "drm" node is the right approach; drm
> is after all a SW term and the DT should be describing HW. Having some
> kind of top-level node almost certainly makes sense, but naming it
> something related to "tegra display" than "drm" would be appropriate.

In this case there really isn't a HW device that can be represented. But in
the end it's still the DRM driver that needs to bind to the device. However
the other graphics devices (MPE, VI/CSI, EPP, GR2D and GR3D) probably need
to be bound against.

Would it be possible for someone at NVIDIA to provide some more details about
what those other devices are? GR2D and GR3D seem obvious, MPE might be video
decoding, VI/CSI video input and camera interface? As to EPP I have no idea.

Maybe one solution would be to have a top-level DRM device with a register
map from 0x5400 to 0x547f, which the TRM designates as "host
registers". Then subnodes could be used for the subdevices.

> > lvds {
> > compatible = "...";
> > dc = <>;
> > };
> 
> Aren't the outputs separate HW blocks too, such that they would have
> their own compatible/reg properties and their own drivers, and be
> outside the top-level drm/display node?

The RGB output is programmed via the display controller registers. For HDMI,
TVO and DSI there are indeed separate sets of registers in addition to the
display controller's. So perhaps for those more nodes would be required:

hdmi : hdmi at 5428 {
compatible = "nvidia,tegra20-hdmi";
reg = <0x5428 0x0004>;
};

And hook that up with the HDMI output node of the "DRM" node:

drm {
hdmi {
compatible = "...";
connector = <>;
dc = <>;
};
};

Maybe with this setup we no longer need the "compatible" property since it
will already be inherent in the "connector" property. There will have to be
special handling for the RGB output, which could be the default if the
"connector" property is missing.

> I believe the mapping between the output this node represents and the
> display controller ("dc" above) that it uses is not static; the
> connectivity should be set up at runtime, and possibly dynamically
> alterable via xrandr or equivalent.

I think the mapping is always static for a given board. There is no way to
switch an HDMI port to LVDS at runtime. But maybe I misunderstand what you're
saying.

> >> Instead, the active platform data should probably be stored in a
> >> tegra_drm struct that's stored in the dev's private data.
> >> tegra_drm_probe() might then look more like:
> >>
> >> struct tegra_drm *tdev;
> >>
> >> tdev = devm_kzalloc();
> >> tdev->pdata = pdev->dev.platform_data;
> >> if (!tdev->pdata)
> >> tdev->pdata = tegra_drm_parse_dt();
> >> if (!tdev->pdata)
> >> return -EINVAL;
> >>
> >> dev_set_drvdata(dev, tdev);
> >>
> >> This is safe, since probe() will never assume that dev_get_drvdata()
> >> might contain something valid before probe() sets it.
> > 
> > I prefer my approach over storing the data in an extra field because the
> > device platform_data field is where everybody would expect it. Furthermore
> > this wouldn't be relevant if we decided not to support non-DT setups.
> 
> Drivers are expected to use pre-existing platform data, if provided.
> This might happen in order to work around bugs in device tree content.

Okay I see. I'll have to store it in a separate field in the private
structure then.

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

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

mostly exynos and intel,

intel has 3 regression fixers (more info in intel merge commit), along 
with some other make hw work fixes,
exynos has some cleanups and an ioctl fix

couple of radeon fixes, couple of build fixes, and a savage userspace 
interface possible overflow fix.

Dave.

The following changes since commit 258f742635360175564e9470eb060ff4d4b984e7:

  modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 -0700)

are available in the git repository at:
  git://people.freedesktop.org/~airlied/linux drm-fixes

Alex Deucher (2):
  drm/radeon/kms: fix DVO setup on some r4xx chips
  drm/radeon: only add the mm i2c bus if the hw_i2c module param is set

Arnd Bergmann (1):
  drm/radeon: replace udelay with mdelay for long timeouts

Chris Wilson (2):
  drm/i915: Finish any pending operations on the framebuffer before 
disabling
  drm/i915/ringbuffer: Exclude last 2 cachlines of ring on 845g

Daniel Vetter (4):
  drm/i915: properly compute dp dithering for user-created modes
  Revert "drm/i915: reenable gmbus on gen3+ again"
  drm/i915: implement ColorBlt w/a
  drm/i915: clear fencing tracking state when retiring requests

Dave Airlie (2):
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-intel-fixes
  Merge branch 'exynos-drm-fixes' of 
git://git.infradead.org/users/kmpark/linux-samsung into drm-intel-fixes

Inki Dae (3):
  drm/exynos: fixed page align and code clean.
  drm/exynos: fixed duplicated page allocation bug.
  drm/exynos: fixed exynos broken ioctl

Jesse Barnes (1):
  drm/i915: make rc6 module parameter read-only

Joonyoung Shim (6):
  drm/exynos: remove unnecessary type conversion of hdmi and mixer
  drm/exynos: remove unused codes in hdmi and mixer
  drm/exynos: rename s/HDMI_OVERLAY_NUMBER/MIXER_WIN_NR
  drm/exynos: use define instead of default_win member in struct 
mixer_context
  drm/exynos: fix struct for operation callback functions to driver name
  drm/exynos: fix to pointer manager member of struct exynos_drm_subdrv

Randy Dunlap (1):
  vgaarb.h: fix build warnings

Seung-Woo Kim (1):
  drm/exynos: add format list of plane

Xi Wang (1):
  drm/savage: fix integer overflows in savage_bci_cmdbuf()

acreese (1):
  drm/i915: Removed IVB forced enable of sprite dest key.

 drivers/gpu/drm/exynos/exynos_drm_buf.c |   47 +++---
 drivers/gpu/drm/exynos/exynos_drm_core.c|   14 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   10 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   20 +++--
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   45 --
 drivers/gpu/drm/exynos/exynos_drm_gem.h |2 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|  107 ++-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h|   23 ++---
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |4 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|   20 +++--
 drivers/gpu/drm/exynos/exynos_hdmi.c|   42 -
 drivers/gpu/drm/exynos/exynos_mixer.c   |   40 -
 drivers/gpu/drm/i915/i915_drv.c |2 +-
 drivers/gpu/drm/i915/i915_gem.c |2 +
 drivers/gpu/drm/i915/i915_reg.h |3 +
 drivers/gpu/drm/i915/intel_display.c|   69 +++
 drivers/gpu/drm/i915/intel_dp.c |   49 ---
 drivers/gpu/drm/i915/intel_i2c.c|2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |2 +-
 drivers/gpu/drm/i915/intel_sprite.c |1 -
 drivers/gpu/drm/radeon/atombios_encoders.c  |4 +
 drivers/gpu/drm/radeon/r100.c   |2 +-
 drivers/gpu/drm/radeon/r600.c   |2 +-
 drivers/gpu/drm/radeon/r600_cp.c|6 +-
 drivers/gpu/drm/radeon/radeon_clocks.c  |   24 +++---
 drivers/gpu/drm/radeon/radeon_combios.c |8 +-
 drivers/gpu/drm/radeon/radeon_i2c.c |4 +
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |   12 ++--
 drivers/gpu/drm/savage/savage_state.c   |6 +-
 include/drm/exynos_drm.h|5 +-
 include/linux/vgaarb.h  |2 +
 31 files changed, 325 insertions(+), 254 deletions(-)

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

[Takashi Iwai]

At Wed, 11 Apr 2012 21:59:28 -0300,
Rodrigo Vivi wrote:
> 
> There are many bugs open on fd.o regarding missing modes that are supported 
> on Windows and other closed source drivers.
> >From EDID spec we can (might?) infer modes using GTF and CVT when monitor 
> >allows it trough range limited flag... obviously limiting by the range.
> >From our code:
>  * EDID spec says modes should be preferred in this order:
>  * - preferred detailed mode
>  * - other detailed modes from base block
>  * - detailed modes from extension blocks
>  * - CVT 3-byte code modes
>  * - standard timing codes
>  * - established timing codes
>  * - modes inferred from GTF or CVT range information
>  *
>  * We get this pretty much right.
> 
> Not actually so right... We were inferring just using GTF... not CVT or even 
> GTF2.
> This patch not just add some common cvt modes but also allows some modes been 
> inferred when using gtf2 as well.

I tested the patch but it doesn't detect the desired resolutions such
as 1600x900 or 1366x768, unfortunately.

Also, about the patch:


> +static const struct drm_display_mode drm_cvt_inferred_modes[] = {
> + /* 640x480 at 60Hz */
> + { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 23750  640, 664,

A missing comma here.


> +720, 800, 0, 480, 483, 487, 500, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> + /* 800x600 at 60Hz */
> + { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 38250, 800, 832,
> +912, 1024, 0, 600, 603, 607, 624, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> + /* 900x600 at 60Hz */
> + { DRM_MODE("900x600", DRM_MODE_TYPE_DRIVER, 45250, 960, 992,
> +1088, 1216, 0, 600, 603, 609, 624, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> + /* 1024x576 at 60Hz */
> + { DRM_MODE("1024x576", DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
> +1160, 1296, 0, 576, 579, 584, 599, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> + /* 1024x768 at 60Hz */
> + { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 63500, 1024, 1072,
> +1176, 1328, 0, 768, 771, 775, 798, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> + /* 1152x864 at 60Hz */
> + { DRM_MODE("1152x864", DRM_MODE_TYPE_DRIVER, 81750, 1152, 1216,
> +1336, 1520, 0, 864, 867, 871, 897, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> + /* 1280x720 at 60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74500, 1280, 1344,
> +1472, 1664, 0, 720, 723, 728, 748, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> + /* 1280x768 at 60Hz */
> + { DRM_MODE("1280x768", DRM_MODE_TYPE_DRIVER, 79500, 1280, 1344,
> +1472, 1664, 0, 768, 771, 781, 798, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> + /* 1280x800 at 60Hz */
> + { DRM_MODE("1280x800", DRM_MODE_TYPE_DRIVER, 83500, 1280, 1352,
> +1480, 1680, 0, 800, 803, 809, 831, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> + /* 1280x1024 at 60Hz */
> + { DRM_MODE("1280x1024", DRM_MODE_TYPE_DRIVER, 109000, 1280, 1368,
> +1496, 1712, 0, 1024, 1027, 1034, 1063, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> + /* 1360x768 at 60Hz */
> + { DRM_MODE("1360x768", DRM_MODE_TYPE_DRIVER, 84750, 1360, 1432,
> +1568, 1776, 0, 768, 771, 781, 798, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
> + /* 1366x768 at 60Hz */
> + { DRM_MODE("1366x768", DRM_MODE_TYPE_DRIVER, 85250, 1368, 1440,

Here the hdisplay is 1368, not 1366.


thanks,

Takashi

[RFC 4/4] drm: Add NVIDIA Tegra support

[Thierry Reding]

* Alex Deucher wrote:
> On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher  
> wrote:
> > On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
> >> Then again, having user-space control this may be more flexible. 
> >> Performance-
> >> wise both should be about the same, right? What I don't quite understand 
> >> yet
> >> is how the DMABUF would be synchronized on both ends. Is there some infra-
> >> structure to account for it or would I have to export two buffers and flip
> >> them during the vblank of the "consumer"?
> >
> > Performance should be about the same. ?The tricky part is
> > synchronization. ?dma_buf is for sharing. ?There are ideas to make
> > generic sync objects, but for now, it's up to the userspace components
> > to handle it.
> 
> Some example code:
> http://lists.freedesktop.org/archives/dri-devel/2012-April/021182.html

I saw that post too and it looks really nice. From what you're saying there
really doesn't seem to be any advantage to making the connection in the DRM
framework. Using DRM PRIME seems like a promising option and it seems to have
quite a lot of momentum. Of course I'll need to get the DRM driver up and
running properly first.

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

PCI resources above 4GB

[Steven Newbury]

On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu  wrote:

> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury 
> wrote:
> > Thanks, that fixed it! :) I had a similar patch I've been working on
> > but I had my fix in the wrong place!
> > 
> > In the working case, initially the BIOS has set GMA to within the low
> > system DRAM 0xC000 obviously invalid. ?This conflict is detected
> > and it's relallocated to 0x1200.
> > 
> > I've attempted to modify probe.c to disable 64-bit BARs not allocated
> > above 4G so they get reallocated above when possible later. ?It seemed
> > to work, but again broke GMA despite the BAR originally containing an
> > invalid address as mentioned above, it seems for some reason something
> > is different when the conflict is detected and rellocated, compared to
> > disabling it early then allocating a valid value..?
> > 
> > It would be useful to preserve as much low PCI memory address space as
> > possible for hotplug devices (like my Radeon), but the other problem
> > is small regions get allocated at the bottom, resulting in the
> > inability to find large aligned regions later on. ?I see code to
> > default to top-down allocation was reverted, I guess I'm going to have
> > to dig into the archive to find out why...
> 
> for hotplug case, You can work around like:
> after hotplug add,
> 1. use lspci and /proc/iomem to find out offending device and bridge.
> 2. use /sys/.../unbind etc to stop driver for those devices.
> 3. use setpci to clear related BAR
> 4. use /sys/devices/pci000/remove to remove those devices
> 5. echo 1 > /sys/bus/pci/rescan
> 
> then it should work...
> 
Good idea, I can easily hook that up into the dock event. Is it possible to 
disable the auto bus scan on hotplug, then trigger it manually as above? But it 
still leaves me needing to have at least the Intel GMA cleanly reallocated high 
from boot.

[PATCH 7/7] drm/edid: Fix some comment typos in the DMT mode list

[Adam Jackson]

Signed-off-by: Adam Jackson 
---
 drivers/gpu/drm/drm_edid_modes.h |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index 4be9c1a..ab3a051 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -197,15 +197,15 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE("1400x1050", DRM_MODE_TYPE_DRIVER, 101000, 1400, 1448,
   1480, 1560, 0, 1050, 1053, 1057, 1080, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
-   /* 1440x1050 at 60Hz */
+   /* 1400x1050 at 60Hz */
{ DRM_MODE("1400x1050", DRM_MODE_TYPE_DRIVER, 121750, 1400, 1488,
   1632, 1864, 0, 1050, 1053, 1057, 1089, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
-   /* 1440x1050 at 75Hz */
+   /* 1400x1050 at 75Hz */
{ DRM_MODE("1400x1050", DRM_MODE_TYPE_DRIVER, 156000, 1400, 1504,
   1648, 1896, 0, 1050, 1053, 1057, 1099, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
-   /* 1440x1050 at 85Hz */
+   /* 1400x1050 at 85Hz */
{ DRM_MODE("1400x1050", DRM_MODE_TYPE_DRIVER, 179500, 1400, 1504,
   1656, 1912, 0, 1050, 1053, 1057, 1105, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
@@ -281,7 +281,7 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE("1792x1344", DRM_MODE_TYPE_DRIVER, 204750, 1792, 1920,
   2120, 2448, 0, 1344, 1345, 1348, 1394, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
-   /* 1729x1344 at 75Hz */
+   /* 1792x1344 at 75Hz */
{ DRM_MODE("1792x1344", DRM_MODE_TYPE_DRIVER, 261000, 1792, 1888,
   2104, 2456, 0, 1344, 1345, 1348, 1417, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
@@ -289,7 +289,7 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE("1792x1344", DRM_MODE_TYPE_DRIVER, 333250, 1792, 1840,
   1872, 1952, 0, 1344, 1347, 1351, 1423, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
-   /* 1853x1392 at 60Hz */
+   /* 1856x1392 at 60Hz */
{ DRM_MODE("1856x1392", DRM_MODE_TYPE_DRIVER, 218250, 1856, 1952,
   2176, 2528, 0, 1392, 1393, 1396, 1439, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
-- 
1.7.7.6

[PATCH 6/7] drm/edid: Add the reduced blanking DMT modes to the DMT list

[Adam Jackson]

Copied from the list in xserver.

Signed-off-by: Adam Jackson 
---
 drivers/gpu/drm/drm_edid_modes.h |   94 +-
 1 files changed, 93 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..4be9c1a 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -30,7 +30,6 @@
 /*
  * Autogenerated from the DMT spec.
  * This table is copied from xfree86/modes/xf86EdidModes.c.
- * But the mode with Reduced blank feature is deleted.
  */
 static const struct drm_display_mode drm_dmt_modes[] = {
/* 640x350 at 85Hz */
@@ -81,6 +80,10 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 56250, 800, 832,
   896, 1048, 0, 600, 601, 604, 631, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 800x600 at 120Hz RB */
+   { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 73250, 800, 848,
+  880, 960, 0, 600, 603, 607, 636, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 848x480 at 60Hz */
{ DRM_MODE("848x480", DRM_MODE_TYPE_DRIVER, 33750, 848, 864,
   976, 1088, 0, 480, 486, 494, 517, 0,
@@ -106,10 +109,18 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 94500, 1024, 1072,
   1168, 1376, 0, 768, 769, 772, 808, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1024x768 at 120Hz RB */
+   { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 115500, 1024, 1072,
+  1104, 1184, 0, 768, 771, 775, 813, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1152x864 at 75Hz */
{ DRM_MODE("1152x864", DRM_MODE_TYPE_DRIVER, 108000, 1152, 1216,
   1344, 1600, 0, 864, 865, 868, 900, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1280x768 at 60Hz RB */
+   { DRM_MODE("1280x768", DRM_MODE_TYPE_DRIVER, 68250, 1280, 1328,
+  1360, 1440, 0, 768, 771, 778, 790, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x768 at 60Hz */
{ DRM_MODE("1280x768", DRM_MODE_TYPE_DRIVER, 79500, 1280, 1344,
   1472, 1664, 0, 768, 771, 778, 798, 0,
@@ -122,6 +133,14 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE("1280x768", DRM_MODE_TYPE_DRIVER, 117500, 1280, 1360,
   1496, 1712, 0, 768, 771, 778, 809, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1280x768 at 120Hz RB */
+   { DRM_MODE("1280x768", DRM_MODE_TYPE_DRIVER, 140250, 1280, 1328,
+  1360, 1440, 0, 768, 771, 778, 813, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 1280x800 at 60Hz RB */
+   { DRM_MODE("1280x800", DRM_MODE_TYPE_DRIVER, 71000, 1280, 1328,
+  1360, 1440, 0, 800, 803, 809, 823, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x800 at 60Hz */
{ DRM_MODE("1280x800", DRM_MODE_TYPE_DRIVER, 83500, 1280, 1352,
   1480, 1680, 0, 800, 803, 809, 831, 0,
@@ -134,6 +153,10 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE("1280x800", DRM_MODE_TYPE_DRIVER, 122500, 1280, 1360,
   1496, 1712, 0, 800, 803, 809, 843, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1280x800 at 120Hz RB */
+   { DRM_MODE("1280x800", DRM_MODE_TYPE_DRIVER, 146250, 1280, 1328,
+  1360, 1440, 0, 800, 803, 809, 847, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x960 at 60Hz */
{ DRM_MODE("1280x960", DRM_MODE_TYPE_DRIVER, 108000, 1280, 1376,
   1488, 1800, 0, 960, 961, 964, 1000, 0,
@@ -142,6 +165,10 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE("1280x960", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1344,
   1504, 1728, 0, 960, 961, 964, 1011, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1280x960 at 120Hz RB */
+   { DRM_MODE("1280x960", DRM_MODE_TYPE_DRIVER, 175500, 1280, 1328,
+  1360, 1440, 0, 960, 963, 967, 1017, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x1024 at 60Hz */
{ DRM_MODE("1280x1024", DRM_MODE_TYPE_DRIVER, 108000, 1280, 1328,
   1440, 1688, 0, 1024, 1025, 1028, 1066, 0,
@@ -154,10 +181,22 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE("1280x1024", DRM_MODE_TYPE_DRIVER, 157500, 1280, 1344,
   1504, 1728, 0, 1024, 1025, 1028, 1072, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1280x1024 at 120Hz RB */
+   { 

[PATCH 5/7] drm/edid: Armor drm_dmt_modes_for_range for reduced blanking modes

[Adam Jackson]

Require that the monitor support rb for rb modes to be added.

Signed-off-by: Adam Jackson 
---
 drivers/gpu/drm/drm_edid.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 83c51d6..0fc63ca 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1016,10 +1016,6 @@ mode_in_range(const struct drm_display_mode *mode, 
struct edid *edid,
return true;
 }

-/*
- * XXX If drm_dmt_modes ever regrows the CVT-R modes (and it will) this will
- * need to account for them.
- */
 static int
 drm_dmt_modes_for_range(struct drm_connector *connector, struct edid *edid,
struct detailed_timing *timing)
@@ -1030,6 +1026,10 @@ drm_dmt_modes_for_range(struct drm_connector *connector, 
struct edid *edid,

for (i = 0; i < drm_num_dmt_modes; i++) {
if (mode_in_range(drm_dmt_modes + i, edid, timing)) {
+   if (mode_is_rb(_dmt_modes[i]) &&
+   !drm_monitor_supports_rb(edid))
+   continue;
+
newmode = drm_mode_duplicate(dev, _dmt_modes[i]);
if (newmode) {
drm_mode_probed_add(connector, newmode);
-- 
1.7.7.6

[PATCH 4/7] drm/edid: s/drm_gtf_modes_for_range/drm_dmt_modes_for_range/

[Adam Jackson]

Slightly more honest naming.

Signed-off-by: Adam Jackson 
---
 drivers/gpu/drm/drm_edid.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4f52103..83c51d6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1021,7 +1021,7 @@ mode_in_range(const struct drm_display_mode *mode, struct 
edid *edid,
  * need to account for them.
  */
 static int
-drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
+drm_dmt_modes_for_range(struct drm_connector *connector, struct edid *edid,
struct detailed_timing *timing)
 {
int i, modes = 0;
@@ -1049,7 +1049,7 @@ do_inferred_modes(struct detailed_timing *timing, void *c)
int gtf = (closure->edid->features & DRM_EDID_FEATURE_DEFAULT_GTF);

if (gtf && data->type == EDID_DETAIL_MONITOR_RANGE)
-   closure->modes += drm_gtf_modes_for_range(closure->connector,
+   closure->modes += drm_dmt_modes_for_range(closure->connector,
  closure->edid,
  timing);
 }
-- 
1.7.7.6

[PATCH 3/7] drm/edid: Allow drm_mode_find_dmt to hunt for reduced-blanking modes

[Adam Jackson]

It won't find any, yet.  Fix up callers to match: standard mode codes
will look prefer r-b modes for a given size if present, EST3 mode codes
will look for exactly the r-b-ness mentioned in the mode code.  This
might mean fewer modes matched for EST3 mode codes between now and when
the DMT mode list regrows the r-b modes, but practically speaking EST3
codes don't exist in the wild.

Signed-off-by: Adam Jackson 
---
 drivers/gpu/drm/drm_edid.c  |   37 -
 drivers/gpu/drm/drm_fb_helper.c |2 +-
 include/drm/drm_crtc.h  |3 ++-
 3 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0a23ee5..4f52103 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -486,18 +486,29 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
preferred_mode->type |= DRM_MODE_TYPE_PREFERRED;
 }

+static bool
+mode_is_rb(const struct drm_display_mode *mode)
+{
+   return (mode->htotal - mode->hdisplay == 160) &&
+  (mode->hsync_end - mode->hdisplay == 80) &&
+  (mode->hsync_end - mode->hsync_start == 32) &&
+  (mode->vsync_start - mode->vdisplay == 3);
+}
+
 /*
  * drm_mode_find_dmt - Create a copy of a mode if present in DMT
  * @dev: Device to duplicate against
  * @hsize: Mode width
  * @vsize: Mode height
  * @fresh: Mode refresh rate
+ * @rb: Mode reduced-blanking-ness
  *
  * Walk the DMT mode list looking for a match for the given parameters.
  * Return a newly allocated copy of the mode, or NULL if not found.
  */
 struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
-  int hsize, int vsize, int fresh)
+  int hsize, int vsize, int fresh,
+  bool rb)
 {
int i;

@@ -509,6 +520,8 @@ struct drm_display_mode *drm_mode_find_dmt(struct 
drm_device *dev,
continue;
if (fresh != drm_mode_vrefresh(ptr))
continue;
+   if (rb != mode_is_rb(ptr))
+   continue;

return drm_mode_duplicate(dev, ptr);
}
@@ -742,10 +755,17 @@ drm_mode_std(struct drm_connector *connector, struct edid 
*edid,
}

/* check whether it can be found in default mode table */
-   mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate);
+   if (drm_monitor_supports_rb(edid)) {
+   mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate,
+true);
+   if (mode)
+   return mode;
+   }
+   mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, false);
if (mode)
return mode;

+   /* okay, generate it */
switch (timing_level) {
case LEVEL_DMT:
break;
@@ -920,15 +940,6 @@ static struct drm_display_mode *drm_mode_detailed(struct 
drm_device *dev,
 }

 static bool
-mode_is_rb(const struct drm_display_mode *mode)
-{
-   return (mode->htotal - mode->hdisplay == 160) &&
-  (mode->hsync_end - mode->hdisplay == 80) &&
-  (mode->hsync_end - mode->hsync_start == 32) &&
-  (mode->vsync_start - mode->vdisplay == 3);
-}
-
-static bool
 mode_in_hsync_range(const struct drm_display_mode *mode,
struct edid *edid, u8 *t)
 {
@@ -1073,8 +1084,8 @@ drm_est3_modes(struct drm_connector *connector, struct 
detailed_timing *timing)
mode = drm_mode_find_dmt(connector->dev,
 est3_modes[m].w,
 est3_modes[m].h,
-est3_modes[m].r
-/*, est3_modes[m].rb 
*/);
+est3_modes[m].r,
+est3_modes[m].rb);
if (mode) {
drm_mode_probed_add(connector, mode);
modes++;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a0d6e89..6e19dd1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1083,7 +1083,7 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,

/* try and find a 1024x768 mode on each connector */
can_clone = true;
-   dmt_mode = drm_mode_find_dmt(fb_helper->dev, 1024, 768, 60);
+   dmt_mode = drm_mode_find_dmt(fb_helper->dev, 1024, 768, 60, false);

for (i = 0; i < fb_helper->connector_count; i++) {

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e250eda..2be73d7 100644
--- a/include/drm/drm_crtc.h
+++ 

[PATCH 2/7] drm/edid: Rewrite drm_mode_find_dmt search loop

[Adam Jackson]

No functional change, but will make an upcoming change clearer.

Signed-off-by: Adam Jackson 
---
 drivers/gpu/drm/drm_edid.c |   19 ++-
 1 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 79a3637..0a23ee5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -499,20 +499,21 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
 struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
   int hsize, int vsize, int fresh)
 {
-   struct drm_display_mode *mode = NULL;
int i;

for (i = 0; i < drm_num_dmt_modes; i++) {
const struct drm_display_mode *ptr = _dmt_modes[i];
-   if (hsize == ptr->hdisplay &&
-   vsize == ptr->vdisplay &&
-   fresh == drm_mode_vrefresh(ptr)) {
-   /* get the expected default mode */
-   mode = drm_mode_duplicate(dev, ptr);
-   break;
-   }
+   if (hsize != ptr->hdisplay)
+   continue;
+   if (vsize != ptr->vdisplay)
+   continue;
+   if (fresh != drm_mode_vrefresh(ptr))
+   continue;
+
+   return drm_mode_duplicate(dev, ptr);
}
-   return mode;
+
+   return NULL;
 }
 EXPORT_SYMBOL(drm_mode_find_dmt);

-- 
1.7.7.6

[PATCH 1/7] drm/edid: Document drm_mode_find_dmt

[Adam Jackson]

Signed-off-by: Adam Jackson 
---
 drivers/gpu/drm/drm_edid.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a18b0d..79a3637 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -486,6 +486,16 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
preferred_mode->type |= DRM_MODE_TYPE_PREFERRED;
 }

+/*
+ * drm_mode_find_dmt - Create a copy of a mode if present in DMT
+ * @dev: Device to duplicate against
+ * @hsize: Mode width
+ * @vsize: Mode height
+ * @fresh: Mode refresh rate
+ *
+ * Walk the DMT mode list looking for a match for the given parameters.
+ * Return a newly allocated copy of the mode, or NULL if not found.
+ */
 struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
   int hsize, int vsize, int fresh)
 {
-- 
1.7.7.6

[PATCH 0/7] drm/edid: Add the reduced-blanking modes to the DMT list

[Adam Jackson]

These should have been there since day one.

This series cleans up the few places that touch the DMT list to handle rb
modes correctly, and then imports the modes from xserver's list, along with
a few cosmetic changes.

- ajax

PCI resources above 4GB

[Steven Newbury]

On Thu, 12 Apr 2012, 12:22:34 BST, Steven Newbury  
wrote:
> I've attempted to modify probe.c to disable 64-bit BARs not allocated
> above 4G so they get reallocated above when possible later.?  It seemed
> to work, but again broke GMA despite the BAR originally containing an
> invalid address as mentioned above, it seems for some reason something
> is different when the conflict is detected and rellocated, compared to
> disabling it early then allocating a valid value..?
I understand now why it didn't work.  Memory decoding was enabled in the GMA 
device.  When it's detected as in conflict with system RAM it gets reallocated 
cleanly, but setting the BAR to 0 prevents that from happening.  Somehow I need 
to get the resources I want moved onto a realloc list, but I can't work out 
where or how...

exynos broken ioctl

[InKi Dae]

Oh, I am sorry. I fixed it and now you can pull.

Thanks,
Inki Dae.

2012? 4? 12? ?? 4:20, Dave Airlie ?? ?:
> please before submitting ioctl's can someone review them to make sure
> they have no pointers in them ever.
>
> struct drm_exynos_vidi_connection {
>unsigned int connection;
>unsigned int extensions;
>uint64_t *edid;
> };
>
> gets passed into DRM_EXYNOS_VIDI_CONNECTION ioctl.
>
> Can you remove the point, it should be just a uint64_t most likely.
>
> I don't think this has been in a released kernel so should be okay to fix.
>
> Dave.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 4/4] drm: Add NVIDIA Tegra support

[Daniel Vetter]

On Thu, Apr 12, 2012 at 11:18:19AM +, Arnd Bergmann wrote:
> On Thursday 12 April 2012, Marek Szyprowski wrote:
> > Scatter lists were initially designed for the disk based block io 
> > operations, 
> > hence the presence of the in-page offsets and lengths for each chunk. For 
> > multimedia use cases providing an array of struct pages and asking 
> > dma-mapping 
> > to map them into contiguous memory is probably all we need. I wonder if 
> > introducing such new calls is a good idea. Anrd, what do think? It will 
> > definitely simplify the drivers and improve the code understanding. On the 
> > other hand it requires a significant amount of work in the dma-mapping 
> > framework for all architectures, but that's not a big issue for me.
> 
> My feeling is that it's too much like the existing _sg version, so I wouldn't
> add yet another variant. While having a simple page array is definitely
> simpler and potentially faster, I think the API is already too complex
> and we need to be very careful with new additions.

I concur here. For VT-d support we wrestle the pages through an sg list in
drm/i915, too. It's not beautiful, and because our gpu internal pagetables
need 2 loops to walk the sg lists, one for the sg segments, one to loop
over all pages in a segment. And additional a WARN_ON if the segment
dma address isn't page-aligned. It's ugly, but imo adding some helpers to
easier deal with this common case (like the drm_prime_pages_to_sg)
function is better than creating an entirely new interface.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[RFC 4/4] drm: Add NVIDIA Tegra support

[Marek Szyprowski]

Hi Thierry,

On Thursday, April 12, 2012 3:42 PM Thierry Reding wrote:

> > > Also this doesn't yet solve the vmap() problem that is needed for the 
> > > kernel
> > > virtual mapping. I did try using dma_alloc_writecombine(), but that only
> > > works for chunks of 2 MB or smaller, unless I use 
> > > init_consistent_dma_size()
> > > during board setup, which isn't provided for in a DT setup. I couldn't 
> > > find
> > > a better alternative, but I admit I'm not very familiar with all the VM 
> > > APIs.
> > > Do you have any suggestions on how to solve this? Otherwise I'll try and 
> > > dig
> > > in some more.
> >
> > Yes, I'm aware of this issue I'm currently working on solving it. I hope to 
> > use
> > standard vmalloc range for all coherent/writecombine allocations and get 
> > rid of
> > the custom 'consistent_dma' region at all.
> 
> Does your work aim at removing the 2 MB limitation or at remapping non-
> contiguous memory to a virtually linear buffer? I have some trouble
> understanding how removing the 2 MB limit would help, because if all buffers
> can be allocated contiguously then there wouldn't be any need for the IOMMU,
> right?

I would like to remove 2MiB limitation by moving these mapping to generic 
vmalloc
area. Please notice that this 2MiB limit is only applied to CPU virtual address
space and no physical memory is preallocated for consistent dma. 

ARM linear dma mapping implementation allocates coherent buffers by calling 
alloc_pages() and then creating a coherent mapping for the allocated buffer.

With IOMMU you can allocate chunks of memory and create a contiguous DMA 
mapping.
To fulfill dma mapping request you also need to create a cpu coherent mapping 
for 
them and right now my core uses the same remapping function as linear version.

The only limitation here will be vmalloc space and its fragmentation.

Best regards
-- 
Marek Szyprowski
Samsung Poland R Center

[PATCH] drm/radeon/si: add missing radeon_bo_unreserve in si_rlc_init()

[alexdeuc...@gmail.com]

From: Alex Deucher 

Forget to unreserve after pinning.  This can lead to problems in
soft reset and resume.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/si.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index ac7a199..23a114c 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -3005,6 +3005,7 @@ int si_rlc_init(struct radeon_device *rdev)
si_rlc_fini(rdev);
return r;
}
+   radeon_bo_unreserve(rdev->rlc.save_restore_obj);

/* clear state block */
if (rdev->rlc.clear_state_obj == NULL) {
@@ -3024,12 +3025,12 @@ int si_rlc_init(struct radeon_device *rdev)
r = radeon_bo_pin(rdev->rlc.clear_state_obj, RADEON_GEM_DOMAIN_VRAM,
  >rlc.clear_state_gpu_addr);
if (r) {
-
radeon_bo_unreserve(rdev->rlc.clear_state_obj);
dev_warn(rdev->dev, "(%d) pin RLC c bo failed\n", r);
si_rlc_fini(rdev);
return r;
}
+   radeon_bo_unreserve(rdev->rlc.clear_state_obj);

return 0;
 }
-- 
1.7.7.5

[RFC 4/4] drm: Add NVIDIA Tegra support

[Stephen Warren]

On 04/12/2012 11:44 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/12/2012 12:50 AM, Thierry Reding wrote:
>>> drm {
>>> compatible = "nvidia,tegra20-drm";
>>
>> I'm don't think having an explicit "drm" node is the right approach; drm
>> is after all a SW term and the DT should be describing HW. Having some
>> kind of top-level node almost certainly makes sense, but naming it
>> something related to "tegra display" than "drm" would be appropriate.
> 
> In this case there really isn't a HW device that can be represented. But in
> the end it's still the DRM driver that needs to bind to the device. However
> the other graphics devices (MPE, VI/CSI, EPP, GR2D and GR3D) probably need
> to be bound against.

Well, everything graphics-related appears to be grouped within some
container. In the memory map, there's the range 0x5400-547f, and
in the Tegra20 TRM, the first diagram in section 29 "Display Controller"
again lumps all the modules together into one box.

I'd say it's perfectly legitimate to create a device tree node to
represent this aggregate display/graphics-related engine. So, I think
that yes there is a real HW device to represent.

And given that, I don't think we should name the node after some
OS-specific software concept. Device tree is intended to model hardware.

> Would it be possible for someone at NVIDIA to provide some more details about
> what those other devices are? GR2D and GR3D seem obvious, MPE might be video
> decoding, VI/CSI video input and camera interface? As to EPP I have no idea.

MPE is something video encode/decode related. VI/CSI are indeed camera
related. I'm afraid I don't personally know any more details than that,
and even if I did, I'm only allowed to discuss what's in the TRM:-(

I don't think those modules should have much impact on the DRM driver
design if that's what you're worried about. I /believe/ they all just
interact directly with memory rather than the other components,
irrespective of what that first diagram in section 29 might imply.

> Maybe one solution would be to have a top-level DRM device with a register
> map from 0x5400 to 0x547f, which the TRM designates as "host
> registers". Then subnodes could be used for the subdevices.

Ah yes, just what I was thinking above:-)

I don't think you'd /have/ to make the nodes sub-nodes; you could use
phandles to refer from the top-level node to the other components. One
might end up having to use phandles anyway to represent the routing from
DCA or DCB to MIPI or HDMI anyway, so it's possible that using phandles
everywhere might be simpler and more consistent than parent/child
relationships for some things and phandles for other things.

>>> lvds {
>>> compatible = "...";
>>> dc = <>;
>>> };
>>
>> Aren't the outputs separate HW blocks too, such that they would have
>> their own compatible/reg properties and their own drivers, and be
>> outside the top-level drm/display node?
> 
> The RGB output is programmed via the display controller registers. For HDMI,
> TVO and DSI there are indeed separate sets of registers in addition to the
> display controller's. So perhaps for those more nodes would be required:
> 
>   hdmi : hdmi at 5428 {
>   compatible = "nvidia,tegra20-hdmi";
>   reg = <0x5428 0x0004>;
>   };

Yes, looks reasonable.

> And hook that up with the HDMI output node of the "DRM" node:
> 
>   drm {
>   hdmi {
>   compatible = "...";
>   connector = <>;
>   dc = <>;
>   };
>   };
>
> Maybe with this setup we no longer need the "compatible" property since it
> will already be inherent in the "connector" property. There will have to be
> special handling for the RGB output, which could be the default if the
> "connector" property is missing.

I suspect you'd have something more like:

tegra-graphics {
output-resources = <   ... >;
display-controllers = < >;
};

i.e. just a list of all extant devices. Each should provide some common
API so you could just map from phandle to of_node to device object, and
call the appropriate APIs on it.

Finally note that although I didn't really represent it correct above,
there are at least 3 levels of object/hierarchy here:

Display controllers reads from RAM and form a set of pixels to display.
I believe things like cursors, overlays, pan-scan, etc. are resolved
entirely at this level.

Output resources drive certain pins on Tegra in some specific format
such as HDMI, VGA, etc. I think all output resources can actually
display the data from either display controller. Probably even 2 ORs can
show an image from the same DC at once for mirrored display.

Finally, there are the user connectors. I suspect it's plausible for
muxes to exist between the ORs and user connectors, although that's
probably a lot less likely. I believe 

[PATCH libdrm] exynos: add exynos drm support

[InKi Dae]

Please, give me any comments and I hope this patch would be applied to
libdrm if there is any problem.

Thanks,
Inki Dae.


2012? 4? 2? ?? 9:08, Inki Dae ?? ?:
> this patch adds libdrm_exynos helper layer that inclues some intefaces
> for exynos specific gem and virtual display driver and also adds exynos
> module name to modtest and vbltest.
>
> this patch is based on a link below:
>git://anongit.freedesktop.org/mesa/drm
>commit id: e057a56448e2e785f74bc13dbd6ead8572ebed91
>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  Makefile.am|6 +-
>  configure.ac   |   13 ++
>  exynos/Makefile.am |   22 +++
>  exynos/exynos_drm.c|  324 
> 
>  exynos/exynos_drm.h|  127 +
>  exynos/exynos_drmif.h  |   60 
>  exynos/libdrm_exynos.pc.in |   11 ++
>  tests/modetest/modetest.c  |2 +-
>  tests/vbltest/vbltest.c|2 +-
>  9 files changed, 564 insertions(+), 3 deletions(-)
>  create mode 100644 exynos/Makefile.am
>  create mode 100644 exynos/exynos_drm.c
>  create mode 100644 exynos/exynos_drm.h
>  create mode 100644 exynos/exynos_drmif.h
>  create mode 100644 exynos/libdrm_exynos.pc.in
>
> diff --git a/Makefile.am b/Makefile.am
> index 4f625a1..256a8cc 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -45,7 +45,11 @@ if HAVE_OMAP
>  OMAP_SUBDIR = omap
>  endif
>
> -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
> $(RADEON_SUBDIR) $(OMAP_SUBDIR) tests include
> +if HAVE_EXYNOS
> +EXYNOS_SUBDIR = exynos
> +endif
> +
> +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
> $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) tests include
>
>  libdrm_la_LTLIBRARIES = libdrm.la
>  libdrm_ladir = $(libdir)
> diff --git a/configure.ac b/configure.ac
> index 1ba7eba..ae84817 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -88,6 +88,11 @@ AC_ARG_ENABLE(omap-experimental-api,
>  [Enable support for OMAP's experimental API (default: 
> disabled)]),
>  [OMAP=$enableval], [OMAP=no])
>
> +AC_ARG_ENABLE(exynos-experimental-api,
> + AS_HELP_STRING([--enable-exynos-experimental-api],
> + [Enable support for EXYNOS's experimental API (default: 
> disabled)]),
> + [EXYNOS=$enableval], [EXYNOS=no])
> +
>  dnl 
> ===
>  dnl check compiler flags
>  AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
> @@ -191,6 +196,11 @@ if test "x$OMAP" = xyes; then
>AC_DEFINE(HAVE_OMAP, 1, [Have OMAP support])
>  fi
>
> +AM_CONDITIONAL(HAVE_EXYNOS, [test "x$EXYNOS" = xyes])
> +if test "x$EXYNOS" = xyes; then
> +   AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support])
> +fi
> +
>  PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
>  if test "x$HAVE_CAIRO" = xyes; then
>AC_DEFINE(HAVE_CAIRO, 1, [Have cairo support])
> @@ -302,6 +312,8 @@ AC_CONFIG_FILES([
>nouveau/libdrm_nouveau.pc
>omap/Makefile
>omap/libdrm_omap.pc
> +   exynos/Makefile
> +   exynos/libdrm_exynos.pc
>tests/Makefile
>tests/modeprint/Makefile
>tests/modetest/Makefile
> @@ -322,4 +334,5 @@ echo "  vmwgfx API $VMWGFX"
>  echo "  Radeon API $RADEON"
>  echo "  Nouveau API$NOUVEAU"
>  echo "  OMAP API   $OMAP"
> +echo "  EXYNOS API $EXYNOS"
>  echo ""
> diff --git a/exynos/Makefile.am b/exynos/Makefile.am
> new file mode 100644
> index 000..e782d34
> --- /dev/null
> +++ b/exynos/Makefile.am
> @@ -0,0 +1,22 @@
> +AM_CFLAGS = \
> +   $(WARN_CFLAGS) \
> +   -I$(top_srcdir) \
> +   -I$(top_srcdir)/exynos \
> +   $(PTHREADSTUBS_CFLAGS) \
> +   -I$(top_srcdir)/include/drm
> +
> +libdrm_exynos_la_LTLIBRARIES = libdrm_exynos.la
> +libdrm_exynos_ladir = $(libdir)
> +libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
> +libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
> +
> +libdrm_exynos_la_SOURCES = exynos_drm.c
> +
> +libdrm_exynoscommonincludedir = ${includedir}/exynos
> +libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
> +
> +libdrm_exynosincludedir = ${includedir}/libdrm
> +libdrm_exynosinclude_HEADERS = exynos_drmif.h
> +
> +pkgconfigdir = @pkgconfigdir@
> +pkgconfig_DATA = libdrm_exynos.pc
> diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
> new file mode 100644
> index 000..778321a
> --- /dev/null
> +++ b/exynos/exynos_drm.c
> @@ -0,0 +1,324 @@
> +/*
> + * Copyright (C) 2012 Samsung Electronics Co., Ltd.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is 

[RFC 4/4] drm: Add NVIDIA Tegra support

[Thierry Reding]

* Marek Szyprowski wrote:
> Hi Thierry,
> 
> On Thursday, April 12, 2012 9:18 AM Thierry Reding wrote:
> > Also this doesn't yet solve the vmap() problem that is needed for the kernel
> > virtual mapping. I did try using dma_alloc_writecombine(), but that only
> > works for chunks of 2 MB or smaller, unless I use init_consistent_dma_size()
> > during board setup, which isn't provided for in a DT setup. I couldn't find
> > a better alternative, but I admit I'm not very familiar with all the VM 
> > APIs.
> > Do you have any suggestions on how to solve this? Otherwise I'll try and dig
> > in some more.
> 
> Yes, I'm aware of this issue I'm currently working on solving it. I hope to 
> use 
> standard vmalloc range for all coherent/writecombine allocations and get rid 
> of
> the custom 'consistent_dma' region at all.

Does your work aim at removing the 2 MB limitation or at remapping non-
contiguous memory to a virtually linear buffer? I have some trouble
understanding how removing the 2 MB limit would help, because if all buffers
can be allocated contiguously then there wouldn't be any need for the IOMMU,
right?

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

[git pull] updated exynos-drm-fixes

[Inki Dae]

Hi Dave,

Please pull from
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes

this branch is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git drm-fixes
commit-id: 62fb376e214d3c1bfdf6fbb77dac162f6da04d7e

this patch set includes page align and allocation bug fixes and
some code cleanup and also Joonyoung's patch set v2 like below.

v2: Split "[PATCH 2/4] drm/exynos: remove unused codes in hdmi and mixer
   driver" patch of patchset v1.

Please let me know if there is any problem.
Thanks.

Inki Dae (2):
  drm/exynos: fixed page align and code clean.
  drm/exynos: fixed duplicated page allocation bug.

Joonyoung Shim (6):
  drm/exynos: remove unnecessary type conversion of hdmi and mixer
  drm/exynos: remove unused codes in hdmi and mixer
  drm/exynos: rename s/HDMI_OVERLAY_NUMBER/MIXER_WIN_NR
  drm/exynos: use define instead of default_win member in struct
mixer_context
  drm/exynos: fix struct for operation callback functions to driver
name
  drm/exynos: fix to pointer manager member of struct exynos_drm_subdrv

Seung-Woo Kim (1):
  drm/exynos: add format list of plane

 drivers/gpu/drm/exynos/exynos_drm_buf.c   |   47 -
 drivers/gpu/drm/exynos/exynos_drm_core.c  |   14 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   10 ++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   20 +++--
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |   45 ++---
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |2 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |  107 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |   23 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.c |4 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   20 +++--
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   42 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c |   40 +--
 include/drm/exynos_drm.h  |3 +-
 13 files changed, 191 insertions(+), 186 deletions(-)

-- 
1.7.4.1

[RFC 4/4] drm: Add NVIDIA Tegra support

[Thierry Reding]

* Marek Szyprowski wrote:
[...]
> We already have dma_map_page() and dma_map_single() which are very similar. 
> Maybe adding dma_map_pages() won't be such a bad idea? 
> 
> If not maybe we should provide some kind of helper functions which converts 
> page array to scatterlist and then maps them.

drm_prime_pages_to_sg() seems to do exactly that.

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

[RFC 4/4] drm: Add NVIDIA Tegra support

[Marek Szyprowski]

Hi Arnd,

On Thursday, April 12, 2012 1:18 PM Arnd Bergmann wrote:

> On Thursday 12 April 2012, Marek Szyprowski wrote:
> > Scatter lists were initially designed for the disk based block io 
> > operations,
> > hence the presence of the in-page offsets and lengths for each chunk. For
> > multimedia use cases providing an array of struct pages and asking 
> > dma-mapping
> > to map them into contiguous memory is probably all we need. I wonder if
> > introducing such new calls is a good idea. Anrd, what do think? It will
> > definitely simplify the drivers and improve the code understanding. On the
> > other hand it requires a significant amount of work in the dma-mapping
> > framework for all architectures, but that's not a big issue for me.
> 
> My feeling is that it's too much like the existing _sg version, so I wouldn't
> add yet another variant. While having a simple page array is definitely
> simpler and potentially faster, I think the API is already too complex
> and we need to be very careful with new additions.

You are right, the API is already complex. The idea of adding page array came 
after
explaining once again how the _sg functions work and how to use them for this
specific use case.

There is one more point for page array. Scatter-lists are also very inefficient
in terms of the used memory. In the worst case we create a single scatterlist 
entry for every single page of the large buffer. For each entry we really use 
only a page pointer, leaving offset at zero and size set to 4KiB, dma_address
and dma_length entries are usually used only for the first element in the list.

On the other hand scatter lists are the only way to describe a complex block IO
requests which is spread across multiple io buffers, which are smaller than a
single page.

Having a specialized set of functions in the API is not bad in general. Maybe
the obscurity of the current _sg functions was the reason that almost every 
developer involved in gfx/multimedia and memory management tried to provide 
his own solution instead of using the dma-mapping api. 

We already have dma_map_page() and dma_map_single() which are very similar. 
Maybe adding dma_map_pages() won't be such a bad idea? 

If not maybe we should provide some kind of helper functions which converts 
page array to scatterlist and then maps them.

Best regards
-- 
Marek Szyprowski
Samsung Poland R Center

[RFC 4/4] drm: Add NVIDIA Tegra support

[Thierry Reding]

* Alex Deucher wrote:
> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
>  wrote:
> > In other words I would like to use the Tegra hardware to render content into
> > a framebuffer (using potentially the 3D engine or HW accelerated video
> > decoding blocks) but display that framebuffer with a CRTC registered by a
> > different driver (perhaps provided by a PCIe or USB device).
> >
> > I think such a setup would be possible if the CRTC registration can be
> > decoupled from the DRM driver. Perhaps sdrm even supports that already?
> 
> You should be able to do something like that already with dma_buf and
> the drm prime infrastructure.  There's even a drm driver for the udl
> USB framebuffer devices.

Using DRM PRIME requires user-space to be involved. I was thinking more along
the lines of allowing a dumb DRM driver that only provides a CRTC to register
with another driver so that it shows up as an output for the latter DRM
device.

Then again, having user-space control this may be more flexible. Performance-
wise both should be about the same, right? What I don't quite understand yet
is how the DMABUF would be synchronized on both ends. Is there some infra-
structure to account for it or would I have to export two buffers and flip
them during the vblank of the "consumer"?

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

[PATCH 3/4] drm: Add drm_format_{horz, vert}_chroma_subsampling() utility functions

[Ville Syrjälä]

On Wed, Apr 11, 2012 at 08:53:08PM +0200, Roland Scheidegger wrote:
> Am 05.04.2012 20:35, schrieb ville.syrjala at linux.intel.com:
> > From: Ville Syrj?l? 
> > 
> > These functions return the chroma subsampling factors for the specified
> > pixel format.
> Hmm not really related but looking at it this reminds me these formats
> always look a bit underspecified wrt chroma subsample positions. Are
> these fixed, undefined, or what (even mpeg1 and mpeg2 differ there, and
> let's not even talk about the big mess that interlaced mpeg2 is)?

My thinking is that the sample positions can be configured through
some other means. It doesn't affect the in memory layout at all so
tying it to the format isn't necessary.

This also depends on the hardware. On some hardware you can configure
it quite freely, but on some you may be left with just the one option,
which is often not even documented.

I sent another patch [1] some time ago which provides a helper function
for drivers dealing with good hardware.

[1] http://lists.freedesktop.org/archives/dri-devel/2011-December/017585.html

-- 
Ville Syrj?l?
Intel OTC

[PATCH 2/2] tests: add render_node tests

[Ilija Hadzic]

Add two simple programs (render_node_add and render_node_rm)
that can be used to add and remove render nodes from a shell
command or a script.

v2: - add planes

Signed-off-by: Ilija Hadzic 
---
 .gitignore   |2 +
 configure.ac |1 +
 tests/Makefile.am|2 +-
 tests/render_nodes/Makefile.am   |   16 
 tests/render_nodes/render_node_add.c |  158 ++
 tests/render_nodes/render_node_rm.c  |   88 +++
 6 files changed, 266 insertions(+), 1 deletions(-)
 create mode 100644 tests/render_nodes/Makefile.am
 create mode 100644 tests/render_nodes/render_node_add.c
 create mode 100644 tests/render_nodes/render_node_rm.c

diff --git a/.gitignore b/.gitignore
index 243457e..3d2afe8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -76,3 +76,5 @@ tests/modeprint/modeprint
 tests/modetest/modetest
 tests/kmstest/kmstest
 tests/vbltest/vbltest
+tests/render_nodes/render_node_add
+tests/render_nodes/render_node_rm
diff --git a/configure.ac b/configure.ac
index 1ba7eba..797a4bf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -308,6 +308,7 @@ AC_CONFIG_FILES([
tests/kmstest/Makefile
tests/radeon/Makefile
tests/vbltest/Makefile
+   tests/render_nodes/Makefile
include/Makefile
include/drm/Makefile
libdrm.pc])
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a3a59bd..f916a38 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -10,7 +10,7 @@ check_PROGRAMS = \
dristat \
drmstat

-SUBDIRS = modeprint
+SUBDIRS = modeprint render_nodes

 if HAVE_LIBKMS
 SUBDIRS += kmstest modetest
diff --git a/tests/render_nodes/Makefile.am b/tests/render_nodes/Makefile.am
new file mode 100644
index 000..133d792
--- /dev/null
+++ b/tests/render_nodes/Makefile.am
@@ -0,0 +1,16 @@
+AM_CFLAGS = \
+   -I$(top_srcdir)/include/drm \
+   -I$(top_srcdir)
+
+noinst_PROGRAMS = \
+   render_node_add render_node_rm
+
+render_node_add_SOURCES = \
+   render_node_add.c
+render_node_add_LDADD = \
+   $(top_builddir)/libdrm.la
+
+render_node_rm_SOURCES = \
+   render_node_rm.c
+render_node_rm_LDADD = \
+   $(top_builddir)/libdrm.la
diff --git a/tests/render_nodes/render_node_add.c 
b/tests/render_nodes/render_node_add.c
new file mode 100644
index 000..ec64247
--- /dev/null
+++ b/tests/render_nodes/render_node_add.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright 2012 Alcatel-Lucent, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, 
DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Ilija Hadzic 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "config.h"
+
+void print_usage()
+{
+   fprintf(stderr, "Render Node Add\n");
+   fprintf(stderr, "Usage:\n");
+   fprintf(stderr, "\trender_node_add -? | [-n control_node_path] "
+   "[-c num_crtc] [-e num_encoders] [-p num_connectors] "
+   "[-o num_planes] [-l id_list]\n");
+}
+
+int parse_id_list(char *in_list, uint32_t *out_list, int list_size)
+{
+   int i;
+   char *list_elem;
+
+   if (!in_list)
+   return 0;
+   list_elem = strtok(in_list, ",");
+   out_list[0] = strtol(list_elem, NULL, 0);
+   for (i = 1; list_elem && i < list_size; i++) {
+   list_elem = strtok(NULL, ",");
+   if (!list_elem)
+   break;
+   out_list[i] = strtol(list_elem, NULL, 0);
+   }
+   return 0;
+}
+
+int main(int argc, char **argv)
+{
+   int r;
+   int i;
+   int minor;
+   int fd;
+   int num_crtc, num_encoder, num_connector, num_plane;
+   uint32_t *id_list;
+   char *id_list_arg;
+   char *control_node;
+   int id_list_size;
+
+   num_crtc = 0;
+   num_encoder = 0;
+   num_connector = 0;
+   num_plane = 0;
+   

[PATCH 1/2] libdrm: add functions for render node manipulation

[Ilija Hadzic]

Implement the user-space side of drm_render_node_create
and drm_render_node_remove ioctls. The new functions
are drmCreateRenderNode and drmRemoveRenderNode.

v2: - add planes

Signed-off-by: Ilija Hadzic 
---
 include/drm/drm.h  |2 +
 include/drm/drm_mode.h |   17 ++
 xf86drm.c  |   58 
 xf86drm.h  |6 +
 4 files changed, 83 insertions(+), 0 deletions(-)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 753d2fc..7d82130 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -650,6 +650,8 @@ struct drm_prime_handle {
 #define DRM_IOCTL_GEM_FLINKDRM_IOWR(0x0a, struct drm_gem_flink)
 #define DRM_IOCTL_GEM_OPEN DRM_IOWR(0x0b, struct drm_gem_open)
 #define DRM_IOCTL_GET_CAP  DRM_IOWR(0x0c, struct drm_get_cap)
+#define DRM_IOCTL_RENDER_NODE_CREATEDRM_IOWR(0x0d, struct 
drm_render_node_create)
+#define DRM_IOCTL_RENDER_NODE_REMOVEDRM_IOWR(0x0e, struct 
drm_render_node_remove)

 #define DRM_IOCTL_SET_UNIQUE   DRM_IOW( 0x10, struct drm_unique)
 #define DRM_IOCTL_AUTH_MAGIC   DRM_IOW( 0x11, struct drm_auth)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index f36c61a..5e719fd 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -437,4 +437,21 @@ struct drm_mode_destroy_dumb {
__u32 handle;
 };

+/*
+ * render node create and remove functions
+ * if crtc/encoders/connectors all == 0 then gpgpu node
+ */
+struct drm_render_node_create {
+   __u32 node_minor_id;
+   __u32 num_crtc;
+   __u32 num_encoder;
+   __u32 num_connector;
+   __u32 num_plane;
+   __u64 id_list_ptr;
+};
+
+struct drm_render_node_remove {
+   __u32 node_minor_id;
+};
+
 #endif
diff --git a/xf86drm.c b/xf86drm.c
index 7def2b3..eb813e0 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2552,3 +2552,61 @@ char *drmGetDeviceNameFromFd(int fd)
 out:
return strdup(name);
 }
+
+/**
+ * Create a new render node.
+ *
+ * \param fd file descriptor.
+ * \param minor pointer where to put the minor of the new node.
+ * \param num_crtc number of CRTCs to assign to the new node.
+ * \param num_encoder number of encoders to assign to the new node.
+ * \param num_connector number of connectors to assign to the new node.
+ * \param id_list list of CRTC/encoder/connector IDs.
+ *
+ * \return zero on success, or a negative value on failure.
+ *
+ * \internal
+ * Issues an ioctl to the kernel to create a new render node
+ * and popluates the variable pointed by *minor with the new minor
+ * device number.
+ */
+int drmCreateRenderNode(int fd, int *minor,
+   int num_crtc, int num_encoder,
+   int num_connector, int num_plane,
+   uint32_t *id_list)
+{
+   struct drm_render_node_create node;
+   int r;
+
+   node.num_crtc = num_crtc;
+   node.num_encoder = num_encoder;
+   node.num_connector = num_connector;
+   node.num_plane = num_plane;
+   node.id_list_ptr = (uint64_t)(unsigned long)id_list;
+   r = drmIoctl(fd, DRM_IOCTL_RENDER_NODE_CREATE, );
+   if (!r)
+   *minor = node.node_minor_id;
+   return r;
+}
+
+/**
+ * Remove the render node.
+ *
+ * \param fd file descriptor.
+ * \param minor minor device number to remove.
+ *
+ * \return zero on success, or a negative value on failure.
+ *
+ * \internal
+ * Issues an ioctl to the kernel to remove a new render node
+ * identified by the file descriptor and the minor device number.
+ */
+int drmRemoveRenderNode(int fd, int minor)
+{
+   struct drm_render_node_remove node;
+   int r;
+
+   node.node_minor_id = minor;
+   r = drmIoctl(fd, DRM_IOCTL_RENDER_NODE_REMOVE, );
+   return r;
+}
diff --git a/xf86drm.h b/xf86drm.h
index 76eb94e..0658a85 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -701,6 +701,12 @@ extern void drmMsg(const char *format, ...);
 extern int drmSetMaster(int fd);
 extern int drmDropMaster(int fd);

+extern int drmCreateRenderNode(int fd, int *minor,
+  int num_crtc, int num_encoder,
+  int num_connector, int num_plane,
+  uint32_t *id_list);
+extern int drmRemoveRenderNode(int fd, int minor);
+
 #define DRM_EVENT_CONTEXT_VERSION 2

 typedef struct _drmEventContext {
-- 
1.7.8.5

[RFC v2] libdrm part of the render-node patch series

[Ilija Hadzic]

The following two patches are the rework of the patch series sent two weeks
ago [1] that add libdrm support for render node manipulation. All notes
described in [1] apply. A new option to render_node_add utility has
been added to specify the number of planes and plane IDs are supposed to
be the last in the ID list.

Regards,
-- Ilija



[1] http://lists.freedesktop.org/archives/dri-devel/2012-March/020782.html

[PATCH 19/19] drm: hold mutex in critical sections of render-node code

[Ilija Hadzic]

Critical sections are parts of the code where we claim or
release resources (we don't want two render-node create or
remove ioctl called in the context of different processes
to claim part of requested resources because of the race).
Another critical section is manipulating the render node
list. We can use dev->mode_config.mutex for both.

v2: - Use dev->mode_config.mutex instead of dev->struct_mutex
  because we are also racing against drm_mode_getresources()
  and drm_mode_getplane_res() functions.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_stub.c |   15 ++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 13ff4c8..a5fd905 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -486,6 +486,7 @@ static void drm_release_render_node_resources(struct 
drm_device *dev,
int *render_node_owner;
int s, e, i, j;

+   /* no lock, assume we were called with mode_config mutex grabbed */
for (e = 0, j = 0; j < DRM_RN_NUM_EXP_TYPES; j++) {
s = e;
e += resource_count[j];
@@ -509,6 +510,7 @@ static int drm_claim_render_node_resources(struct 
drm_device *dev,
int s, e, i, j;
int ret = 0;

+   mutex_lock(>mode_config.mutex);
for (e = 0, j = 0; j < DRM_RN_NUM_EXP_TYPES; j++) {
s = e;
e += resource_count[j];
@@ -529,10 +531,12 @@ static int drm_claim_render_node_resources(struct 
drm_device *dev,
*render_node_owner = minor;
}
}
+   mutex_unlock(>mode_config.mutex);
return ret;

 out_release:
drm_release_render_node_resources(dev, id_list, resource_count, minor);
+   mutex_unlock(>mode_config.mutex);
return ret;
 }

@@ -553,7 +557,9 @@ int drm_create_render_node(struct drm_device *dev, struct 
drm_minor **minor_p)
}
render_node->minor = minor;
*minor_p = minor;
+   mutex_lock(>mode_config.mutex);
list_add_tail(_node->list, >render_node_list);
+   mutex_unlock(>mode_config.mutex);
return 0;
 }

@@ -561,13 +567,16 @@ int drm_destroy_render_node(struct drm_device *dev, int 
index)
 {
struct drm_render_node *node, *tmp;

+   mutex_lock(>mode_config.mutex);
list_for_each_entry_safe(node, tmp, >render_node_list, list) {
if (node->minor->index == index) {
struct drm_mode_group *group;
int resource_count[DRM_RN_NUM_EXP_TYPES];

-   if (node->minor->open_count)
+   if (node->minor->open_count) {
+   mutex_unlock(>mode_config.mutex);
return -EBUSY;
+   }
group = >minor->mode_group;
list_del(>list);
resource_count[0] = group->num_crtcs;
@@ -577,12 +586,14 @@ int drm_destroy_render_node(struct drm_device *dev, int 
index)
drm_release_render_node_resources(dev, group->id_list,
  resource_count,
  node->minor->index);
+   mutex_unlock(>mode_config.mutex);
drm_put_minor(>minor);
drm_mode_group_fini(group);
kfree(node);
return 0;
}
}
+   mutex_unlock(>mode_config.mutex);
return -ENODEV;
 }

@@ -590,6 +601,7 @@ void drm_destroy_all_render_nodes(struct drm_device *dev)
 {
struct drm_render_node *node, *tmp;

+   mutex_lock(>mode_config.mutex);
list_for_each_entry_safe(node, tmp, >render_node_list, list) {
struct drm_mode_group *group;
int resource_count[DRM_RN_NUM_EXP_TYPES];
@@ -607,6 +619,7 @@ void drm_destroy_all_render_nodes(struct drm_device *dev)
drm_mode_group_fini(group);
kfree(node);
}
+   mutex_unlock(>mode_config.mutex);
 }

 /**
-- 
1.7.8.5

[PATCH 18/19] drm: keep track of which node holds which resource

[Ilija Hadzic]

Add fields to drm_crtc, drm_encoder, drm_connector, and drm_plane
that keep track of which render node owns it. Assign ownership
when resource is added and revoke it when resource is destroyed.
Do not allow creation of a node that tries to claim resources
that are already in use by another node.

v2: - track planes too

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_crtc.c |4 ++
 drivers/gpu/drm/drm_stub.c |  111 
 include/drm/drm_crtc.h |5 ++
 3 files changed, 120 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cce3d25..45a2925 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -375,6 +375,7 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,

crtc->dev = dev;
crtc->funcs = funcs;
+   crtc->render_node_owner = -1;

mutex_lock(>mode_config.mutex);

@@ -483,6 +484,7 @@ int drm_connector_init(struct drm_device *dev,

connector->dev = dev;
connector->funcs = funcs;
+   connector->render_node_owner = -1;
connector->connector_type = connector_type;
connector->connector_type_id =
++drm_connector_enum_list[connector_type].count; /* TODO */
@@ -553,6 +555,7 @@ int drm_encoder_init(struct drm_device *dev,
if (ret)
goto out;

+   encoder->render_node_owner = -1;
encoder->dev = dev;
encoder->encoder_type = encoder_type;
encoder->funcs = funcs;
@@ -594,6 +597,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,

plane->dev = dev;
plane->funcs = funcs;
+   plane->render_node_owner = -1;
plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
  GFP_KERNEL);
if (!plane->format_types) {
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 340a7e4..13ff4c8 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -447,6 +447,95 @@ static int drm_get_render_node_resources(struct drm_device 
*dev,
return 0;
 }

+static int *drm_get_render_node_owner(struct drm_device *dev,
+ uint32_t id, uint32_t type)
+{
+   struct drm_mode_object *obj;
+   struct drm_crtc *crtc;
+   struct drm_encoder *encoder;
+   struct drm_connector *connector;
+   struct drm_plane *plane;
+
+   obj = drm_mode_object_find(dev, id, type);
+   if (!obj)
+   return NULL;
+   switch (type) {
+   case DRM_MODE_OBJECT_CRTC:
+   crtc = container_of(obj, struct drm_crtc, base);
+   return >render_node_owner;
+   case DRM_MODE_OBJECT_ENCODER:
+   encoder = container_of(obj, struct drm_encoder, base);
+   return >render_node_owner;
+   case DRM_MODE_OBJECT_CONNECTOR:
+   connector = container_of(obj, struct drm_connector, base);
+   return >render_node_owner;
+   case DRM_MODE_OBJECT_PLANE:
+   plane = container_of(obj, struct drm_plane, base);
+   return >render_node_owner;
+
+   default:
+   return NULL;
+   }
+}
+
+static void drm_release_render_node_resources(struct drm_device *dev,
+ uint32_t *id_list,
+ int *resource_count,
+ int minor)
+{
+   int *render_node_owner;
+   int s, e, i, j;
+
+   for (e = 0, j = 0; j < DRM_RN_NUM_EXP_TYPES; j++) {
+   s = e;
+   e += resource_count[j];
+   for (i = s; i < e; i++) {
+   render_node_owner =
+   drm_get_render_node_owner(dev, id_list[i],
+   expected_type_list[j]);
+   if (render_node_owner &&
+   *render_node_owner == minor)
+   *render_node_owner = -1;
+   }
+   }
+}
+
+static int drm_claim_render_node_resources(struct drm_device *dev,
+  uint32_t *id_list,
+  int *resource_count,
+  int minor)
+{
+   int *render_node_owner;
+   int s, e, i, j;
+   int ret = 0;
+
+   for (e = 0, j = 0; j < DRM_RN_NUM_EXP_TYPES; j++) {
+   s = e;
+   e += resource_count[j];
+   for (i = s; i < e; i++) {
+   render_node_owner =
+   drm_get_render_node_owner(dev, id_list[i],
+   expected_type_list[j]);
+   if (!render_node_owner) {
+   /* list was validated, not supposed to fail */
+   WARN_ON(1);
+

[PATCH 17/19] drm: validate id list when creating a render node

[Ilija Hadzic]

Render node ioctl requires a list of DRM mode objects
in specific order: first all CRTCs, then all encoders,
followed by all connectors. Check that the IDs passed
from userland are in conformance with this requirement
and that they are consistent with specified num_crtc,
num_encoder and num_connector values.

Return -EINVAL to if the check fails. Otherwise, accept
the list and create the requested render node.

v2: - also check planes

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_stub.c |   68 ++-
 1 files changed, 60 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 7aa54fb..340a7e4 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -399,6 +399,54 @@ err_idr:
return ret;
 }

+static int drm_get_id_from_user(struct drm_device *dev,
+   uint32_t *id_dst,
+   uint32_t __user *id_src,
+   uint32_t expected_type)
+{
+   struct drm_mode_object *drmmode_obj;
+   uint32_t id;
+
+   if (get_user(id, id_src))
+   return -EFAULT;
+   drmmode_obj = drm_mode_object_find(dev, id, expected_type);
+   if (!drmmode_obj)
+   return -EINVAL;
+   *id_dst = id;
+   return 0;
+}
+
+#define DRM_RN_NUM_EXP_TYPES 4
+static const uint32_t expected_type_list[DRM_RN_NUM_EXP_TYPES] = {
+   DRM_MODE_OBJECT_CRTC,
+   DRM_MODE_OBJECT_ENCODER,
+   DRM_MODE_OBJECT_CONNECTOR,
+   DRM_MODE_OBJECT_PLANE
+};
+
+static int drm_get_render_node_resources(struct drm_device *dev,
+uint32_t *id_list,
+uint32_t __user *ids_ptr,
+int *resource_count)
+
+{
+   int s, e, i, j;
+   int ret;
+
+   for (e = 0, j = 0; j < DRM_RN_NUM_EXP_TYPES; j++) {
+   s = e;
+   e += resource_count[j];
+   for (i = s; i < e; i++) {
+   ret = drm_get_id_from_user(dev, _list[i],
+  _ptr[i],
+  expected_type_list[j]);
+   if (ret)
+   return ret;
+   }
+   }
+   return 0;
+}
+
 int drm_create_render_node(struct drm_device *dev, struct drm_minor **minor_p)
 {
int ret;
@@ -558,8 +606,10 @@ int drm_render_node_create_ioctl(struct drm_device *dev, 
void *data,
struct drm_render_node_create *args = data;
int ret;
struct drm_minor *new_minor;
-   int total_ids, i;
+   int total_ids;
+   int resource_count[DRM_RN_NUM_EXP_TYPES];
uint32_t __user *ids_ptr;
+   uint32_t *id_list;

/* allow access through control node only */
if (file_priv->minor != dev->control)
@@ -592,14 +642,16 @@ int drm_render_node_create_ioctl(struct drm_device *dev, 
void *data,
ret = drm_mode_group_init(_minor->mode_group, total_ids);
if (ret)
goto out_del;
-
+   resource_count[0] = args->num_crtc;
+   resource_count[1] = args->num_encoder;
+   resource_count[2] = args->num_connector;
+   resource_count[3] = args->num_plane;
ids_ptr = (uint32_t __user *)(unsigned long)args->id_list_ptr;
-   for (i = 0; i < total_ids; i++) {
-   if (get_user(new_minor->mode_group.id_list[i], _ptr[i])) {
-   ret = -EFAULT;
-   goto out_del;
-   }
-   }
+   id_list = new_minor->mode_group.id_list;
+   ret = drm_get_render_node_resources(dev, id_list, ids_ptr,
+   resource_count);
+   if (ret)
+   goto out_del;
new_minor->mode_group.num_crtcs = args->num_crtc;
new_minor->mode_group.num_encoders = args->num_encoder;
new_minor->mode_group.num_connectors = args->num_connector;
-- 
1.7.8.5

[PATCH 16/19] drm: more elaborate check for resource count

[Ilija Hadzic]

User space can send us all kinds of nonsense for num_crtc, num_encoder,
num_connector, or num_plane. So far, we have been checking only for
presence of at least one CRTC/encoder/connector (barring the trivial
case of a render node with no display resources, i.e., GPGPU node).

This patch makes the ioctl fail if user space requests more resources
than the physical GPU has. This is primarily to protect the kmalloc
in drm_mode_group_init from hogging a big chunk of memory if some
bozo sends us a request for some huge number of CRTCs, encoders,
or connectors.

v2: - fail when user space asks for more planes than available
  from physical device, but still allow zero planes
  (which is a legitimate case)

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_stub.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 20c72b0..7aa54fb 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -574,9 +574,12 @@ int drm_render_node_create_ioctl(struct drm_device *dev, 
void *data,
return ret;
}

-   /* if we have display resources, then we need at least
-* one CRTC, one encoder and one connector */
-   if (args->num_crtc == 0 ||
+   /* sanity check for requested num_crtc/_encoder/_connector/_plane */
+   if (args->num_crtc > dev->mode_config.num_crtc ||
+   args->num_encoder > dev->mode_config.num_encoder ||
+   args->num_encoder > dev->mode_config.num_connector ||
+   args->num_plane > dev->mode_config.num_plane ||
+   args->num_crtc == 0 ||
args->num_encoder == 0 ||
args->num_connector == 0)
return -EINVAL;
-- 
1.7.8.5

[PATCH 15/19] drm: call drm_mode_group_fini on primary node

[Ilija Hadzic]

In drm_put_dev, the whole device is being destroyed, so id_list
of the primary (legacy) node should also be cleaned up.
This plugs a memory leak that has probably existed even without
the render-node work.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_stub.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index d427316..20c72b0 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -540,6 +540,7 @@ void drm_put_dev(struct drm_device *dev)
if (driver->driver_features & DRIVER_GEM)
drm_gem_destroy(dev);

+   drm_mode_group_fini(>primary->mode_group);
drm_put_minor(>primary);

list_del(>driver_item);
-- 
1.7.8.5

[PATCH 14/19] drm: properly free id_list when a render node is removed

[Ilija Hadzic]

id_list is dynamically allocated when a render node is
created. Consequently, if must be freed when the render node
is removed, otherwise we have a memory leak.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_stub.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 93746b7..d427316 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -426,10 +426,13 @@ int drm_destroy_render_node(struct drm_device *dev, int 
index)

list_for_each_entry_safe(node, tmp, >render_node_list, list) {
if (node->minor->index == index) {
+   struct drm_mode_group *group;
if (node->minor->open_count)
return -EBUSY;
+   group = >minor->mode_group;
list_del(>list);
drm_put_minor(>minor);
+   drm_mode_group_fini(group);
kfree(node);
return 0;
}
@@ -442,8 +445,11 @@ void drm_destroy_all_render_nodes(struct drm_device *dev)
struct drm_render_node *node, *tmp;

list_for_each_entry_safe(node, tmp, >render_node_list, list) {
+   struct drm_mode_group *group;
+   group = >minor->mode_group;
list_del(>list);
drm_put_minor(>minor);
+   drm_mode_group_fini(group);
kfree(node);
}
 }
-- 
1.7.8.5

[PATCH 13/19] drm: add drm_mode_group_fini function

[Ilija Hadzic]

This is the opposite function of drm_mode_group_init. It will
be needed to properly cleanup the render node after removing it.

v2: - add planes

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_crtc.c |   11 +++
 include/drm/drm_crtc.h |1 +
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 78f2b96..cce3d25 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -947,6 +947,17 @@ int drm_mode_group_init(struct drm_mode_group *group, int 
total_objects)
 }
 EXPORT_SYMBOL(drm_mode_group_init);

+void drm_mode_group_fini(struct drm_mode_group *group)
+{
+   kfree(group->id_list);
+   group->id_list = NULL;
+   group->num_crtcs = 0;
+   group->num_connectors = 0;
+   group->num_encoders = 0;
+   group->num_planes = 0;
+}
+EXPORT_SYMBOL(drm_mode_group_fini);
+
 int drm_mode_group_init_legacy_group(struct drm_device *dev,
 struct drm_mode_group *group)
 {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 939fed1..7c1227b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -852,6 +852,7 @@ extern char *drm_get_tv_subconnector_name(int val);
 extern char *drm_get_tv_select_name(int val);
 extern void drm_fb_release(struct drm_file *file_priv);
 extern int drm_mode_group_init(struct drm_mode_group *group, int 
total_objects);
+extern void drm_mode_group_fini(struct drm_mode_group *group);
 extern int drm_mode_group_init_legacy_group(struct drm_device *dev, struct 
drm_mode_group *group);
 extern struct edid *drm_get_edid(struct drm_connector *connector,
 struct i2c_adapter *adapter);
-- 
1.7.8.5

[PATCH 12/19] drm: allocate correct id_list size for a render node

[Ilija Hadzic]

When a new render node is created, the number of elements
of id_list allocated in drm_mode_group_init function should
not be the sum of all CRTCs, encoders, and connectors that
the device has, but the one specified by the ioctl that
created the node.

v2: - add planes

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_crtc.c |   18 --
 drivers/gpu/drm/drm_stub.c |7 +++
 include/drm/drm_crtc.h |2 +-
 3 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4fc7c5f..78f2b96 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -933,15 +933,8 @@ void drm_mode_config_init(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_config_init);

-int drm_mode_group_init(struct drm_device *dev, struct drm_mode_group *group)
+int drm_mode_group_init(struct drm_mode_group *group, int total_objects)
 {
-   uint32_t total_objects = 0;
-
-   total_objects += dev->mode_config.num_crtc;
-   total_objects += dev->mode_config.num_connector;
-   total_objects += dev->mode_config.num_encoder;
-   total_objects += dev->mode_config.num_plane;
-
group->id_list = kzalloc(total_objects * sizeof(uint32_t), GFP_KERNEL);
if (!group->id_list)
return -ENOMEM;
@@ -961,9 +954,14 @@ int drm_mode_group_init_legacy_group(struct drm_device 
*dev,
struct drm_encoder *encoder;
struct drm_connector *connector;
struct drm_plane *plane;
-   int ret;
+   int ret, total_objects;

-   if ((ret = drm_mode_group_init(dev, group)))
+   total_objects = dev->mode_config.num_crtc;
+   total_objects += dev->mode_config.num_connector;
+   total_objects += dev->mode_config.num_encoder;
+   total_objects += dev->mode_config.num_plane;
+   ret = drm_mode_group_init(group, total_objects);
+   if (ret)
return ret;

list_for_each_entry(crtc, >mode_config.crtc_list, head)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 5ebc8bc..93746b7 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -577,14 +577,13 @@ int drm_render_node_create_ioctl(struct drm_device *dev, 
void *data,
ret = drm_create_render_node(dev, _minor);
if (ret)
return ret;
-
-   ret = drm_mode_group_init(dev, _minor->mode_group);
+   total_ids = args->num_crtc + args->num_encoder +
+   args->num_connector + args->num_plane;
+   ret = drm_mode_group_init(_minor->mode_group, total_ids);
if (ret)
goto out_del;

ids_ptr = (uint32_t __user *)(unsigned long)args->id_list_ptr;
-   total_ids = args->num_crtc + args->num_encoder +
-   args->num_connector + args->num_plane;
for (i = 0; i < total_ids; i++) {
if (get_user(new_minor->mode_group.id_list[i], _ptr[i])) {
ret = -EFAULT;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 2b9d062..939fed1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -851,7 +851,7 @@ extern char *drm_get_dvi_i_select_name(int val);
 extern char *drm_get_tv_subconnector_name(int val);
 extern char *drm_get_tv_select_name(int val);
 extern void drm_fb_release(struct drm_file *file_priv);
-extern int drm_mode_group_init(struct drm_device *dev, struct drm_mode_group 
*group);
+extern int drm_mode_group_init(struct drm_mode_group *group, int 
total_objects);
 extern int drm_mode_group_init_legacy_group(struct drm_device *dev, struct 
drm_mode_group *group);
 extern struct edid *drm_get_edid(struct drm_connector *connector,
 struct i2c_adapter *adapter);
-- 
1.7.8.5

[PATCH 11/19] drm: do not remove a render node in use

[Ilija Hadzic]

Keep track of per-node open count and do not allow removal
of a render node in use.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_fops.c |2 ++
 drivers/gpu/drm/drm_stub.c |2 ++
 include/drm/drmP.h |1 +
 3 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 4498d76..686236f 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -136,6 +136,7 @@ int drm_open(struct inode *inode, struct file *filp)
retcode = drm_open_helper(filp, minor);
if (!retcode) {
atomic_inc(>counts[_DRM_STAT_OPENS]);
+   minor->open_count++;
if (!dev->open_count++)
retcode = drm_setup(dev);
}
@@ -573,6 +574,7 @@ int drm_release(struct inode *inode, struct file *filp)
 */

atomic_inc(>counts[_DRM_STAT_CLOSES]);
+   file_priv->minor->open_count--;
if (!--dev->open_count) {
if (atomic_read(>ioctl_count)) {
DRM_ERROR("Device busy: %d\n",
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 6629dd7..5ebc8bc 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -426,6 +426,8 @@ int drm_destroy_render_node(struct drm_device *dev, int 
index)

list_for_each_entry_safe(node, tmp, >render_node_list, list) {
if (node->minor->index == index) {
+   if (node->minor->open_count)
+   return -EBUSY;
list_del(>list);
drm_put_minor(>minor);
kfree(node);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 1131fd4..981f005 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -983,6 +983,7 @@ struct drm_info_node {
 struct drm_minor {
int index;  /**< Minor device number */
int type;   /**< Control or render */
+   int open_count;
dev_t device;   /**< Device number for mknod */
struct device kdev; /**< Linux device */
struct drm_device *dev;
-- 
1.7.8.5

[PATCH 10/19] drm: only allow render node ioctls through control node

[Ilija Hadzic]

The render-node manipulation ioctls are supposed to be
issued through control node only. Add a check and return
-EPERM to user space if access is attempted through a
node other than a control node.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_stub.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index d7ec39c..6629dd7 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -552,6 +552,10 @@ int drm_render_node_create_ioctl(struct drm_device *dev, 
void *data,
int total_ids, i;
uint32_t __user *ids_ptr;

+   /* allow access through control node only */
+   if (file_priv->minor != dev->control)
+   return -EPERM;
+
/* trivial case: render node with no display resources */
if (args->num_crtc == 0 && args->num_encoder == 0 &&
args->num_connector == 0 && args->num_plane == 0) {
@@ -603,6 +607,10 @@ int drm_render_node_remove_ioctl(struct drm_device *dev, 
void *data,
struct drm_render_node_remove *args = data;
int ret;

+   /* allow access through control node only */
+   if (file_priv->minor != dev->control)
+   return -EPERM;
+
ret = drm_destroy_render_node(dev, args->node_minor_id);
return ret;
 }
-- 
1.7.8.5

[PATCH 09/19] drm: cleanup render node ioctls

[Ilija Hadzic]

Fix a few bugs in render node create and destroy ioctl
(mostly handling of error cases). Also separate some
common code into a new function for destroying
the render node.

v2: - support planes

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_stub.c |   81 +++
 1 files changed, 51 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index c6a0e71..d7ec39c 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -420,17 +420,30 @@ int drm_create_render_node(struct drm_device *dev, struct 
drm_minor **minor_p)
return 0;
 }

-int drm_destroy_all_render_nodes(struct drm_device *dev)
+int drm_destroy_render_node(struct drm_device *dev, int index)
 {
-   struct drm_render_node *render_node, *tmp;
+   struct drm_render_node *node, *tmp;
+
+   list_for_each_entry_safe(node, tmp, >render_node_list, list) {
+   if (node->minor->index == index) {
+   list_del(>list);
+   drm_put_minor(>minor);
+   kfree(node);
+   return 0;
+   }
+   }
+   return -ENODEV;
+}

-   list_for_each_entry_safe(render_node, tmp,
->render_node_list, list) {
-   list_del(_node->list);
-   drm_put_minor(_node->minor);
-   kfree(render_node);
+void drm_destroy_all_render_nodes(struct drm_device *dev)
+{
+   struct drm_render_node *node, *tmp;
+
+   list_for_each_entry_safe(node, tmp, >render_node_list, list) {
+   list_del(>list);
+   drm_put_minor(>minor);
+   kfree(node);
}
-   return 0;
 }

 /**
@@ -538,25 +551,30 @@ int drm_render_node_create_ioctl(struct drm_device *dev, 
void *data,
struct drm_minor *new_minor;
int total_ids, i;
uint32_t __user *ids_ptr;
-   ret = drm_create_render_node(dev, _minor);
-   if (ret)
-   goto out;
-
-   args->node_minor_id = new_minor->index;

+   /* trivial case: render node with no display resources */
if (args->num_crtc == 0 && args->num_encoder == 0 &&
-   args->num_connector == 0 && args->num_plane == 0)
-   goto out;
+   args->num_connector == 0 && args->num_plane == 0) {
+   ret = drm_create_render_node(dev, _minor);
+   if (!ret)
+   args->node_minor_id = new_minor->index;
+   return ret;
+   }
+
+   /* if we have display resources, then we need at least
+* one CRTC, one encoder and one connector */
if (args->num_crtc == 0 ||
args->num_encoder == 0 ||
-   args->num_connector == 0) {
-   ret = -EINVAL;
-   goto out;
-   }
+   args->num_connector == 0)
+   return -EINVAL;
+
+   ret = drm_create_render_node(dev, _minor);
+   if (ret)
+   return ret;

ret = drm_mode_group_init(dev, _minor->mode_group);
if (ret)
-   goto out;
+   goto out_del;

ids_ptr = (uint32_t __user *)(unsigned long)args->id_list_ptr;
total_ids = args->num_crtc + args->num_encoder +
@@ -564,12 +582,18 @@ int drm_render_node_create_ioctl(struct drm_device *dev, 
void *data,
for (i = 0; i < total_ids; i++) {
if (get_user(new_minor->mode_group.id_list[i], _ptr[i])) {
ret = -EFAULT;
-   goto out_put;
+   goto out_del;
}
}
-out_put:
-   drm_put_minor(_minor);
-out:
+   new_minor->mode_group.num_crtcs = args->num_crtc;
+   new_minor->mode_group.num_encoders = args->num_encoder;
+   new_minor->mode_group.num_connectors = args->num_connector;
+   new_minor->mode_group.num_planes = args->num_plane;
+
+   args->node_minor_id = new_minor->index;
+   return 0;
+out_del:
+   drm_destroy_render_node(dev, new_minor->index);
return ret;
 }

@@ -577,11 +601,8 @@ int drm_render_node_remove_ioctl(struct drm_device *dev, 
void *data,
 struct drm_file *file_priv)
 {
struct drm_render_node_remove *args = data;
-   struct drm_render_node *del_node, *tmp;
+   int ret;

-   list_for_each_entry_safe(del_node, tmp, >render_node_list, list) {
-   if (del_node->minor->index == args->node_minor_id)
-   drm_put_minor(_node->minor);
-   }
-   return 0;
+   ret = drm_destroy_render_node(dev, args->node_minor_id);
+   return ret;
 }
-- 
1.7.8.5

[PATCH 08/19] drm: separate render node descriptor from minor

[Ilija Hadzic]

drm_minor structure had a list_head pointer that was
used only for render nodes. control and primary nodes
do not live in the list and had this list pointer unused.

Create a separate drm_render_node structure that is used
to build the render node list and that points to the
coresponding minor. This avoids having fields that are used
only in some cases and also to allows adding render node
specific fields that primary and control minor may not care
about.

Also fix a few minor things:
 * change the names of functions that create and delete
   render nodes to more logical ones.
 * make create_render_node actually populate minor_p
   pointer passed to it so that the ioctl has
   some chance of working

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_stub.c |   45 +--
 drivers/gpu/drm/drm_vm.c   |9 ---
 include/drm/drmP.h |9 ++-
 3 files changed, 38 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 5ef0e46..c6a0e71 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -269,7 +269,7 @@ int drm_fill_in_dev(struct drm_device *dev,
INIT_LIST_HEAD(>vmalist);
INIT_LIST_HEAD(>maplist);
INIT_LIST_HEAD(>vblank_event_list);
-   INIT_LIST_HEAD(>render_minor_list);
+   INIT_LIST_HEAD(>render_node_list);

spin_lock_init(>count_lock);
spin_lock_init(>event_lock);
@@ -356,7 +356,6 @@ int drm_get_minor(struct drm_device *dev, struct drm_minor 
**minor, int type)
new_minor->dev = dev;
new_minor->index = minor_id;
INIT_LIST_HEAD(_minor->master_list);
-   INIT_LIST_HEAD(_minor->render_node_list);

idr_replace(_minors_idr, new_minor, minor_id);

@@ -400,25 +399,36 @@ err_idr:
return ret;
 }

-int drm_create_minor_render(struct drm_device *dev, struct drm_minor **minor_p)
+int drm_create_render_node(struct drm_device *dev, struct drm_minor **minor_p)
 {
int ret;
struct drm_minor *minor;
+   struct drm_render_node *render_node;
+
+   render_node = kmalloc(sizeof(struct drm_render_node), GFP_KERNEL);
+   if (!render_node)
+   return -ENOMEM;

ret = drm_get_minor(dev, , DRM_MINOR_RENDER);
-   if (ret)
+   if (ret) {
+   kfree(render_node);
return ret;
-
-   list_add_tail(>render_node_list, >render_minor_list);
+   }
+   render_node->minor = minor;
+   *minor_p = minor;
+   list_add_tail(_node->list, >render_node_list);
return 0;
 }

-int drm_destroy_minor_render(struct drm_device *dev)
+int drm_destroy_all_render_nodes(struct drm_device *dev)
 {
-   struct drm_minor *minor, *tmp;
+   struct drm_render_node *render_node, *tmp;

-   list_for_each_entry_safe(minor, tmp, >render_minor_list, 
render_node_list) {
-   drm_put_minor();
+   list_for_each_entry_safe(render_node, tmp,
+>render_node_list, list) {
+   list_del(_node->list);
+   drm_put_minor(_node->minor);
+   kfree(render_node);
}
return 0;
 }
@@ -439,8 +449,6 @@ int drm_put_minor(struct drm_minor **minor_p)

DRM_DEBUG("release secondary minor %d\n", minor->index);

-   list_del(>render_node_list);
-
if (minor->type == DRM_MINOR_LEGACY)
drm_proc_cleanup(minor, drm_proc_root);
 #if defined(CONFIG_DEBUG_FS)
@@ -505,8 +513,7 @@ void drm_put_dev(struct drm_device *dev)

if (drm_core_check_feature(dev, DRIVER_MODESET)) {
drm_put_minor(>control);
-
-   drm_destroy_minor_render(dev);
+   drm_destroy_all_render_nodes(dev);
}

if (driver->driver_features & DRIVER_GEM)
@@ -531,7 +538,7 @@ int drm_render_node_create_ioctl(struct drm_device *dev, 
void *data,
struct drm_minor *new_minor;
int total_ids, i;
uint32_t __user *ids_ptr;
-   ret = drm_create_minor_render(dev, _minor);
+   ret = drm_create_render_node(dev, _minor);
if (ret)
goto out;

@@ -570,11 +577,11 @@ int drm_render_node_remove_ioctl(struct drm_device *dev, 
void *data,
 struct drm_file *file_priv)
 {
struct drm_render_node_remove *args = data;
-   struct drm_minor *del_minor, *tmp;
+   struct drm_render_node *del_node, *tmp;

-   list_for_each_entry_safe(del_minor, tmp, >render_minor_list, 
render_node_list) {
-   if (del_minor->index == args->node_minor_id)
-   drm_put_minor(_minor);
+   list_for_each_entry_safe(del_node, tmp, >render_node_list, list) {
+   if (del_node->minor->index == args->node_minor_id)
+   drm_put_minor(_node->minor);
}
return 0;
 }
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 7cf67dd..73146e3 100644
--- a/drivers/gpu/drm/drm_vm.c

[PATCH 07/19] drm: initial multiple nodes ioctl work.

[Ilija Hadzic]

From: Dave Airlie 

just adds some unchecked ioctls to setup the nodes.

Signed-off-by: Dave Airlie 

v2: - original ioctl numbers are now taken, use next available
- resolve some trivial conflicts due to bit-rot that
  occurred since the original patch was created

v3: - added planes to ABI to address a comment from Ville Syrjala

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_drv.c  |4 ++-
 drivers/gpu/drm/drm_stub.c |   56 
 include/drm/drm.h  |3 ++
 include/drm/drmP.h |6 
 include/drm/drm_mode.h |   15 +++
 5 files changed, 83 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a4d7d44..dd04322 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -159,7 +159,9 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DIRTYFB, drm_mode_dirtyfb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_DUMB, drm_mode_create_dumb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_MAP_DUMB, drm_mode_mmap_dumb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED)
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_RENDER_NODE_CREATE, 
drm_render_node_create_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_RENDER_NODE_REMOVE, 
drm_render_node_remove_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED)
 };

 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 53033d3..5ef0e46 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -522,3 +522,59 @@ void drm_put_dev(struct drm_device *dev)
kfree(dev);
 }
 EXPORT_SYMBOL(drm_put_dev);
+
+int drm_render_node_create_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
+{
+   struct drm_render_node_create *args = data;
+   int ret;
+   struct drm_minor *new_minor;
+   int total_ids, i;
+   uint32_t __user *ids_ptr;
+   ret = drm_create_minor_render(dev, _minor);
+   if (ret)
+   goto out;
+
+   args->node_minor_id = new_minor->index;
+
+   if (args->num_crtc == 0 && args->num_encoder == 0 &&
+   args->num_connector == 0 && args->num_plane == 0)
+   goto out;
+   if (args->num_crtc == 0 ||
+   args->num_encoder == 0 ||
+   args->num_connector == 0) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   ret = drm_mode_group_init(dev, _minor->mode_group);
+   if (ret)
+   goto out;
+
+   ids_ptr = (uint32_t __user *)(unsigned long)args->id_list_ptr;
+   total_ids = args->num_crtc + args->num_encoder +
+   args->num_connector + args->num_plane;
+   for (i = 0; i < total_ids; i++) {
+   if (get_user(new_minor->mode_group.id_list[i], _ptr[i])) {
+   ret = -EFAULT;
+   goto out_put;
+   }
+   }
+out_put:
+   drm_put_minor(_minor);
+out:
+   return ret;
+}
+
+int drm_render_node_remove_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
+{
+   struct drm_render_node_remove *args = data;
+   struct drm_minor *del_minor, *tmp;
+
+   list_for_each_entry_safe(del_minor, tmp, >render_minor_list, 
render_node_list) {
+   if (del_minor->index == args->node_minor_id)
+   drm_put_minor(_minor);
+   }
+   return 0;
+}
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 34a7b89..d2a893b 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -639,6 +639,9 @@ struct drm_get_cap {
 #define DRM_IOCTL_GEM_OPEN DRM_IOWR(0x0b, struct drm_gem_open)
 #define DRM_IOCTL_GET_CAP  DRM_IOWR(0x0c, struct drm_get_cap)

+#define DRM_IOCTL_RENDER_NODE_CREATEDRM_IOWR(0x0d, struct 
drm_render_node_create)
+#define DRM_IOCTL_RENDER_NODE_REMOVEDRM_IOWR(0x0e, struct 
drm_render_node_remove)
+
 #define DRM_IOCTL_SET_UNIQUE   DRM_IOW( 0x10, struct drm_unique)
 #define DRM_IOCTL_AUTH_MAGIC   DRM_IOW( 0x11, struct drm_auth)
 #define DRM_IOCTL_BLOCKDRM_IOWR(0x12, struct drm_block)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d9eee26..3bc5c71 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1458,6 +1458,12 @@ extern void drm_master_put(struct drm_master **master);

 extern void drm_put_dev(struct drm_device *dev);
 extern int drm_put_minor(struct drm_minor **minor);
+
+extern int 

[PATCH 06/19] drm: add support for render nodes

[Ilija Hadzic]

Add support for creating multiple render nodes on the same
physical GPU.

Patch derived from 7c5cc4f63556e351e9e5980ed22accad410e3fdc
originally authored by Dave Airlie.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_crtc.c |1 +
 drivers/gpu/drm/drm_stub.c |   32 +++-
 drivers/gpu/drm/drm_vm.c   |7 +++
 include/drm/drmP.h |4 +++-
 include/drm/drm_crtc.h |1 +
 5 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index eafb49d..4fc7c5f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -952,6 +952,7 @@ int drm_mode_group_init(struct drm_device *dev, struct 
drm_mode_group *group)
group->num_planes = 0;
return 0;
 }
+EXPORT_SYMBOL(drm_mode_group_init);

 int drm_mode_group_init_legacy_group(struct drm_device *dev,
 struct drm_mode_group *group)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 6d7b083..53033d3 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -269,6 +269,7 @@ int drm_fill_in_dev(struct drm_device *dev,
INIT_LIST_HEAD(>vmalist);
INIT_LIST_HEAD(>maplist);
INIT_LIST_HEAD(>vblank_event_list);
+   INIT_LIST_HEAD(>render_minor_list);

spin_lock_init(>count_lock);
spin_lock_init(>event_lock);
@@ -355,6 +356,7 @@ int drm_get_minor(struct drm_device *dev, struct drm_minor 
**minor, int type)
new_minor->dev = dev;
new_minor->index = minor_id;
INIT_LIST_HEAD(_minor->master_list);
+   INIT_LIST_HEAD(_minor->render_node_list);

idr_replace(_minors_idr, new_minor, minor_id);

@@ -398,6 +400,29 @@ err_idr:
return ret;
 }

+int drm_create_minor_render(struct drm_device *dev, struct drm_minor **minor_p)
+{
+   int ret;
+   struct drm_minor *minor;
+
+   ret = drm_get_minor(dev, , DRM_MINOR_RENDER);
+   if (ret)
+   return ret;
+
+   list_add_tail(>render_node_list, >render_minor_list);
+   return 0;
+}
+
+int drm_destroy_minor_render(struct drm_device *dev)
+{
+   struct drm_minor *minor, *tmp;
+
+   list_for_each_entry_safe(minor, tmp, >render_minor_list, 
render_node_list) {
+   drm_put_minor();
+   }
+   return 0;
+}
+
 /**
  * Put a secondary minor number.
  *
@@ -414,6 +439,8 @@ int drm_put_minor(struct drm_minor **minor_p)

DRM_DEBUG("release secondary minor %d\n", minor->index);

+   list_del(>render_node_list);
+
if (minor->type == DRM_MINOR_LEGACY)
drm_proc_cleanup(minor, drm_proc_root);
 #if defined(CONFIG_DEBUG_FS)
@@ -476,9 +503,12 @@ void drm_put_dev(struct drm_device *dev)

drm_ctxbitmap_cleanup(dev);

-   if (drm_core_check_feature(dev, DRIVER_MODESET))
+   if (drm_core_check_feature(dev, DRIVER_MODESET)) {
drm_put_minor(>control);

+   drm_destroy_minor_render(dev);
+   }
+
if (driver->driver_features & DRIVER_GEM)
drm_gem_destroy(dev);

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index bcd15b0..7cf67dd 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -691,8 +691,15 @@ EXPORT_SYMBOL(drm_mmap);
 void drm_unmap_mapping(struct drm_device *dev, loff_t const holebegin,
   loff_t const holelen)
 {
+   struct drm_minor *minor;
if (dev->primary->dev_mapping)
unmap_mapping_range(dev->primary->dev_mapping,
holebegin, holelen, 1);
+
+   list_for_each_entry(minor, >render_minor_list, render_node_list) {
+   if (minor->dev_mapping)
+   unmap_mapping_range(minor->dev_mapping,
+   holebegin, holelen, 1);
+   }
 }
 EXPORT_SYMBOL(drm_unmap_mapping);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index eeb377a..d9eee26 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -999,6 +999,8 @@ struct drm_minor {
struct drm_mode_group mode_group;

struct address_space *dev_mapping;
+
+   struct list_head render_node_list;
 };

 /* mode specified on the command line */
@@ -1162,7 +1164,7 @@ struct drm_device {
unsigned int agp_buffer_token;
struct drm_minor *control;  /**< Control node for card */
struct drm_minor *primary;  /**< render type primary screen 
head */
-
+   struct list_head render_minor_list;
 struct drm_mode_config mode_config;/**< Current mode config */

/** \name GEM information */
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4aa793e..2b9d062 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -851,6 +851,7 @@ extern char *drm_get_dvi_i_select_name(int val);
 extern char *drm_get_tv_subconnector_name(int val);
 extern char 

[PATCH 05/19] drm: move dev_mapping to the minor node

[Ilija Hadzic]

Make dev_mapping per-minor instead of per device. This is
a preparatory patch for introducing render nodes. This
will allow per-node instead of per-device mapping range,
once we introduce render nodes.

Patch derived from 7c5cc4f63556e351e9e5980ed22accad410e3fdc
originally authored by Dave Airlie.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_drv.c  |1 -
 drivers/gpu/drm/drm_fops.c |8 
 drivers/gpu/drm/drm_vm.c   |9 +
 drivers/gpu/drm/i915/i915_gem.c|7 +++
 drivers/gpu/drm/nouveau/nouveau_gem.c  |4 ++--
 drivers/gpu/drm/radeon/radeon_object.c |4 ++--
 drivers/gpu/drm/radeon/radeon_ttm.c|6 +++---
 drivers/gpu/drm/ttm/ttm_bo.c   |7 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|5 ++---
 drivers/staging/omapdrm/omap_gem.c |   10 --
 include/drm/drmP.h |3 ++-
 include/drm/drm_mem_util.h |3 +++
 include/drm/ttm/ttm_bo_driver.h|3 ++-
 13 files changed, 40 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index d166bd0..a4d7d44 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -236,7 +236,6 @@ int drm_lastclose(struct drm_device * dev)
!drm_core_check_feature(dev, DRIVER_MODESET))
drm_dma_takedown(dev);

-   dev->dev_mapping = NULL;
mutex_unlock(>struct_mutex);

DRM_DEBUG("lastclose completed\n");
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 98cb064..4498d76 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -141,10 +141,10 @@ int drm_open(struct inode *inode, struct file *filp)
}
if (!retcode) {
mutex_lock(>struct_mutex);
-   if (minor->type == DRM_MINOR_LEGACY) {
-   if (dev->dev_mapping == NULL)
-   dev->dev_mapping = inode->i_mapping;
-   else if (dev->dev_mapping != inode->i_mapping)
+   if (minor->type == DRM_MINOR_LEGACY || minor->type == 
DRM_MINOR_RENDER) {
+   if (minor->dev_mapping == NULL)
+   minor->dev_mapping = inode->i_mapping;
+   else if (minor->dev_mapping != inode->i_mapping)
retcode = -ENODEV;
}
mutex_unlock(>struct_mutex);
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 55cd615..bcd15b0 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -687,3 +687,12 @@ int drm_mmap(struct file *filp, struct vm_area_struct *vma)
return ret;
 }
 EXPORT_SYMBOL(drm_mmap);
+
+void drm_unmap_mapping(struct drm_device *dev, loff_t const holebegin,
+  loff_t const holelen)
+{
+   if (dev->primary->dev_mapping)
+   unmap_mapping_range(dev->primary->dev_mapping,
+   holebegin, holelen, 1);
+}
+EXPORT_SYMBOL(drm_unmap_mapping);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 19a06c2..5eb0294 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1215,10 +1215,9 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
if (!obj->fault_mappable)
return;

-   if (obj->base.dev->dev_mapping)
-   unmap_mapping_range(obj->base.dev->dev_mapping,
-   
(loff_t)obj->base.map_list.hash.key<base.size, 1);
+   drm_unmap_mapping(obj->base.dev,
+ (loff_t)obj->base.map_list.hash.key<base.size);

obj->fault_mappable = false;
 }
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 7ce3fde..63521af 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -202,8 +202,8 @@ nouveau_gem_ioctl_new(struct drm_device *dev, void *data,
struct nouveau_bo *nvbo = NULL;
int ret = 0;

-   if (unlikely(dev_priv->ttm.bdev.dev_mapping == NULL))
-   dev_priv->ttm.bdev.dev_mapping = dev_priv->dev->dev_mapping;
+   if (unlikely(dev_priv->ttm.bdev.mapping_priv == NULL))
+   dev_priv->ttm.bdev.mapping_priv = (void *)dev;

if (!dev_priv->engine.vram.flags_valid(dev, req->info.tile_flags)) {
NV_ERROR(dev, "bad page flags: 0x%08x\n", req->info.tile_flags);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 342deac..837c7eb 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -115,8 +115,8 @@ int radeon_bo_create(struct radeon_device *rdev,

size = ALIGN(size, PAGE_SIZE);

-   if 

[PATCH 04/19] drm: do not push inode down into drm_open_helper

[Ilija Hadzic]

Push minor number instead. This is a preparatory
patch for introducing render nodes. It has been derived
from 7c5cc4f63556e351e9e5980ed22accad410e3fdc originally
created by Dave Airlie.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_fops.c |   19 ++-
 1 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 6263b01..98cb064 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -43,8 +43,8 @@
 DEFINE_MUTEX(drm_global_mutex);
 EXPORT_SYMBOL(drm_global_mutex);

-static int drm_open_helper(struct inode *inode, struct file *filp,
-  struct drm_device * dev);
+static int drm_open_helper(struct file *filp,
+  struct drm_minor *minor);

 static int drm_setup(struct drm_device * dev)
 {
@@ -133,7 +133,7 @@ int drm_open(struct inode *inode, struct file *filp)
if (!(dev = minor->dev))
return -ENODEV;

-   retcode = drm_open_helper(inode, filp, dev);
+   retcode = drm_open_helper(filp, minor);
if (!retcode) {
atomic_inc(>counts[_DRM_STAT_OPENS]);
if (!dev->open_count++)
@@ -226,10 +226,10 @@ static int drm_cpu_valid(void)
  * Creates and initializes a drm_file structure for the file private data in \p
  * filp and add it into the double linked list in \p dev.
  */
-static int drm_open_helper(struct inode *inode, struct file *filp,
-  struct drm_device * dev)
+static int drm_open_helper(struct file *filp,
+  struct drm_minor *minor)
 {
-   int minor_id = iminor(inode);
+   struct drm_device *dev = minor->dev;
struct drm_file *priv;
int ret;

@@ -240,7 +240,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
if (dev->switch_power_state != DRM_SWITCH_POWER_ON)
return -EINVAL;

-   DRM_DEBUG("pid = %d, minor = %d\n", task_pid_nr(current), minor_id);
+   DRM_DEBUG("pid = %d, minor = %d\n", task_pid_nr(current), minor->index);

priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -250,7 +250,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
priv->filp = filp;
priv->uid = current_euid();
priv->pid = task_pid_nr(current);
-   priv->minor = idr_find(_minors_idr, minor_id);
+   priv->minor = minor;
priv->ioctl_count = 0;
/* for compatibility root is always authenticated */
priv->authenticated = capable(CAP_SYS_ADMIN);
@@ -558,7 +558,8 @@ int drm_release(struct inode *inode, struct file *filp)
}

/* drop the reference held my the file priv */
-   drm_master_put(_priv->master);
+   if (file_priv->master)
+   drm_master_put(_priv->master);
file_priv->is_master = 0;
list_del(_priv->lhead);
mutex_unlock(>struct_mutex);
-- 
1.7.8.5

[PATCH 03/19] drm: use drm_mode_group in drm_mode_getplane_res

[Ilija Hadzic]

drm_mode_group structure now tracks planes, so use it in
in drm_mode_getplane_res(ources) IOCTL.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_crtc.c |   46 +--
 1 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 29ede0a..eafb49d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1564,7 +1564,6 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
*data,
struct drm_file *file_priv)
 {
struct drm_mode_get_plane_res *plane_resp = data;
-   struct drm_mode_config *config;
struct drm_plane *plane;
uint32_t __user *plane_ptr;
int copied = 0, ret = 0;
@@ -1573,25 +1572,50 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
*data,
return -EINVAL;

mutex_lock(>mode_config.mutex);
-   config = >mode_config;

/*
 * This ioctl is called twice, once to determine how much space is
 * needed, and the 2nd time to fill it.
 */
-   if (config->num_plane &&
-   (plane_resp->count_planes >= config->num_plane)) {
-   plane_ptr = (uint32_t __user *)(unsigned 
long)plane_resp->plane_id_ptr;
+   plane_ptr = (uint32_t __user *)(unsigned long)plane_resp->plane_id_ptr;
+   if (file_priv->minor->type == DRM_MINOR_CONTROL) {
+   struct drm_mode_config *config = >mode_config;

-   list_for_each_entry(plane, >plane_list, head) {
-   if (put_user(plane->base.id, plane_ptr + copied)) {
-   ret = -EFAULT;
-   goto out;
+   if (config->num_plane &&
+   (plane_resp->count_planes >= config->num_plane)) {
+   list_for_each_entry(plane, >plane_list, head) {
+   if (put_user(plane->base.id,
+plane_ptr + copied)) {
+   ret = -EFAULT;
+   goto out;
+   }
+   copied++;
+   }
+   }
+   plane_resp->count_planes = config->num_plane;
+   } else {
+   int i;
+   struct drm_mode_group *mode_group =
+   _priv->minor->mode_group;
+
+   if (mode_group->num_planes &&
+   (plane_resp->count_planes >= mode_group->num_planes)) {
+   int start;
+
+   start = mode_group->num_crtcs;
+   start += mode_group->num_encoders;
+   start += mode_group->num_connectors;
+   for (i = start; i < start + mode_group->num_planes; 
i++) {
+   if (put_user(mode_group->id_list[i],
+plane_ptr + copied)) {
+   ret = -EFAULT;
+   goto out;
+   }
+   copied++;
}
-   copied++;
}
+   plane_resp->count_planes = mode_group->num_planes;
}
-   plane_resp->count_planes = config->num_plane;

 out:
mutex_unlock(>mode_config.mutex);
-- 
1.7.8.5

[PATCH 02/19] drm: track planes in drm_mode_group structure

[Ilija Hadzic]

drm_mode_group structure (meant for subgrouping) of display
resources didn't include planes, which made it impossible to
do any subgrouping of planes. This patch rectifies the problem.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_crtc.c |8 
 include/drm/drm_crtc.h |2 ++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d2e5560..29ede0a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -940,6 +940,7 @@ int drm_mode_group_init(struct drm_device *dev, struct 
drm_mode_group *group)
total_objects += dev->mode_config.num_crtc;
total_objects += dev->mode_config.num_connector;
total_objects += dev->mode_config.num_encoder;
+   total_objects += dev->mode_config.num_plane;

group->id_list = kzalloc(total_objects * sizeof(uint32_t), GFP_KERNEL);
if (!group->id_list)
@@ -948,6 +949,7 @@ int drm_mode_group_init(struct drm_device *dev, struct 
drm_mode_group *group)
group->num_crtcs = 0;
group->num_connectors = 0;
group->num_encoders = 0;
+   group->num_planes = 0;
return 0;
 }

@@ -957,6 +959,7 @@ int drm_mode_group_init_legacy_group(struct drm_device *dev,
struct drm_crtc *crtc;
struct drm_encoder *encoder;
struct drm_connector *connector;
+   struct drm_plane *plane;
int ret;

if ((ret = drm_mode_group_init(dev, group)))
@@ -973,6 +976,11 @@ int drm_mode_group_init_legacy_group(struct drm_device 
*dev,
group->id_list[group->num_crtcs + group->num_encoders +
   group->num_connectors++] = connector->base.id;

+   list_for_each_entry(plane, >mode_config.plane_list, head)
+   group->id_list[group->num_crtcs + group->num_encoders +
+  group->num_connectors + group->num_planes++] =
+   plane->base.id;
+
return 0;
 }

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 9595c2c..4aa793e 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -696,6 +696,7 @@ struct drm_mode_config_funcs {
  * @num_crtcs: CRTC count
  * @num_encoders: encoder count
  * @num_connectors: connector count
+ * @num_planes: connector count
  * @id_list: list of KMS object IDs in this group
  *
  * Currently this simply tracks the global mode setting state.  But in the
@@ -708,6 +709,7 @@ struct drm_mode_group {
uint32_t num_crtcs;
uint32_t num_encoders;
uint32_t num_connectors;
+   uint32_t num_planes;

/* list of object IDs for this group */
uint32_t *id_list;
-- 
1.7.8.5

[PATCH 01/19] drm: simplify dereferencing of node type

[Ilija Hadzic]

file_priv->master->minor is equivalent to file_priv->minor
http://lists.freedesktop.org/archives/dri-devel/2011-October/015511.html

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/drm_crtc.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d2d9dc5..d2e5560 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1160,8 +1160,8 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
list_for_each(lh, _priv->fbs)
fb_count++;

-   mode_group = _priv->master->minor->mode_group;
-   if (file_priv->master->minor->type == DRM_MINOR_CONTROL) {
+   mode_group = _priv->minor->mode_group;
+   if (file_priv->minor->type == DRM_MINOR_CONTROL) {

list_for_each(lh, >mode_config.crtc_list)
crtc_count++;
@@ -1202,7 +1202,7 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
if (card_res->count_crtcs >= crtc_count) {
copied = 0;
crtc_id = (uint32_t __user *)(unsigned 
long)card_res->crtc_id_ptr;
-   if (file_priv->master->minor->type == DRM_MINOR_CONTROL) {
+   if (file_priv->minor->type == DRM_MINOR_CONTROL) {
list_for_each_entry(crtc, >mode_config.crtc_list,
head) {
DRM_DEBUG_KMS("[CRTC:%d]\n", crtc->base.id);
@@ -1229,7 +1229,7 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
if (card_res->count_encoders >= encoder_count) {
copied = 0;
encoder_id = (uint32_t __user *)(unsigned 
long)card_res->encoder_id_ptr;
-   if (file_priv->master->minor->type == DRM_MINOR_CONTROL) {
+   if (file_priv->minor->type == DRM_MINOR_CONTROL) {
list_for_each_entry(encoder,
>mode_config.encoder_list,
head) {
@@ -1260,7 +1260,7 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
if (card_res->count_connectors >= connector_count) {
copied = 0;
connector_id = (uint32_t __user *)(unsigned 
long)card_res->connector_id_ptr;
-   if (file_priv->master->minor->type == DRM_MINOR_CONTROL) {
+   if (file_priv->minor->type == DRM_MINOR_CONTROL) {
list_for_each_entry(connector,
>mode_config.connector_list,
head) {
-- 
1.7.8.5

[RFC v2] Revive the work on render-nodes branch

[Ilija Hadzic]

The following set of patches is the reword of the series
sent two weeks ago [2] that will revive the drm-render-nodes [1]
branch. Details of the original series are described in [2].

Patches in this series have been reworked (and a few prep patches
have been added) to address the comment about the planes support
(planes can now be included in the resource list for the render
node).

Consequently, the ioctls have changed to include plane support
so the libdrm side is also affected (patches for libdrm will be sent
in the series following this one).

regards,
-- Ilija


[1] http://airlied.livejournal.com/72187.html

[2] http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html

[RFC v2] Revive the work on render-nodes branch

[Ilija Hadzic]

On Thu, 12 Apr 2012, Ville [iso-8859-1] Syrj?l? wrote:

> Didn't have time for a detailed look yet, but at least one thing
> missing from your patch set is handling of possible_crtcs and
> possible_clones for getplane and getencoder ioctls.

Yes I agree and I know. That is still work in progress. The ioctl for 
constructing the node should do more checks not only for possible_crtcs 
and possible_clones, but also whether a particular encoder can match the 
connector and not allow creation of the node with incompatible resources. 
I have all that on the TODO list, but I wanted to get the patches out 
early so that I can get some feedback (and hopefully motivate others to 
contribute).

There will definitely be v3 (and beyond) that will include stuff on my 
TODO list along with any feedback that I receive.

> Also the name "render node" is still very confusing. How about just
> callling it a partition or something. Or maybe someone could suggest
> a more self explanatory name for this stuff.
>

Dave has chosen the name two years ago when he did the initial demo work. 
I am just keeping this name for now (the advantage is that others know of 
this work by this name, so they know what it is about). However, if there 
is a concensus for a better name I'll be glad to adopt it.

-- Ilija

[PATCH libdrm] exynos: add exynos drm support

[Rob Clark]

On Mon, Apr 2, 2012 at 7:08 AM, Inki Dae  wrote:
> this patch adds libdrm_exynos helper layer that inclues some intefaces
> for exynos specific gem and virtual display driver and also adds exynos
> module name to modtest and vbltest.
>
> this patch is based on a link below:
> ? ? ? ?git://anongit.freedesktop.org/mesa/drm
> ? ? ? ?commit id: e057a56448e2e785f74bc13dbd6ead8572ebed91

Reviewed-by: Rob Clark 

>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
> ?Makefile.am ? ? ? ? ? ? ? ?| ? ?6 +-
> ?configure.ac ? ? ? ? ? ? ? | ? 13 ++
> ?exynos/Makefile.am ? ? ? ? | ? 22 +++
> ?exynos/exynos_drm.c ? ? ? ?| ?324 
> 
> ?exynos/exynos_drm.h ? ? ? ?| ?127 +
> ?exynos/exynos_drmif.h ? ? ?| ? 60 
> ?exynos/libdrm_exynos.pc.in | ? 11 ++
> ?tests/modetest/modetest.c ?| ? ?2 +-
> ?tests/vbltest/vbltest.c ? ?| ? ?2 +-
> ?9 files changed, 564 insertions(+), 3 deletions(-)
> ?create mode 100644 exynos/Makefile.am
> ?create mode 100644 exynos/exynos_drm.c
> ?create mode 100644 exynos/exynos_drm.h
> ?create mode 100644 exynos/exynos_drmif.h
> ?create mode 100644 exynos/libdrm_exynos.pc.in
>
> diff --git a/Makefile.am b/Makefile.am
> index 4f625a1..256a8cc 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -45,7 +45,11 @@ if HAVE_OMAP
> ?OMAP_SUBDIR = omap
> ?endif
>
> -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
> $(RADEON_SUBDIR) $(OMAP_SUBDIR) tests include
> +if HAVE_EXYNOS
> +EXYNOS_SUBDIR = exynos
> +endif
> +
> +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
> $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) tests include
>
> ?libdrm_la_LTLIBRARIES = libdrm.la
> ?libdrm_ladir = $(libdir)
> diff --git a/configure.ac b/configure.ac
> index 1ba7eba..ae84817 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -88,6 +88,11 @@ AC_ARG_ENABLE(omap-experimental-api,
> ? ? ? ? ? ? ?[Enable support for OMAP's experimental API (default: 
> disabled)]),
> ? ? ? ? ? ? ?[OMAP=$enableval], [OMAP=no])
>
> +AC_ARG_ENABLE(exynos-experimental-api,
> + ? ? ? ? ? ? AS_HELP_STRING([--enable-exynos-experimental-api],
> + ? ? ? ? ? ? [Enable support for EXYNOS's experimental API (default: 
> disabled)]),
> + ? ? ? ? ? ? [EXYNOS=$enableval], [EXYNOS=no])
> +
> ?dnl 
> ===
> ?dnl check compiler flags
> ?AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
> @@ -191,6 +196,11 @@ if test "x$OMAP" = xyes; then
> ? ? ? ?AC_DEFINE(HAVE_OMAP, 1, [Have OMAP support])
> ?fi
>
> +AM_CONDITIONAL(HAVE_EXYNOS, [test "x$EXYNOS" = xyes])
> +if test "x$EXYNOS" = xyes; then
> + ? ? ? AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support])
> +fi
> +
> ?PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
> ?if test "x$HAVE_CAIRO" = xyes; then
> ? ? ? ?AC_DEFINE(HAVE_CAIRO, 1, [Have cairo support])
> @@ -302,6 +312,8 @@ AC_CONFIG_FILES([
> ? ? ? ?nouveau/libdrm_nouveau.pc
> ? ? ? ?omap/Makefile
> ? ? ? ?omap/libdrm_omap.pc
> + ? ? ? exynos/Makefile
> + ? ? ? exynos/libdrm_exynos.pc
> ? ? ? ?tests/Makefile
> ? ? ? ?tests/modeprint/Makefile
> ? ? ? ?tests/modetest/Makefile
> @@ -322,4 +334,5 @@ echo " ?vmwgfx API ? ? $VMWGFX"
> ?echo " ?Radeon API ? ? $RADEON"
> ?echo " ?Nouveau API ? ?$NOUVEAU"
> ?echo " ?OMAP API ? ? ? $OMAP"
> +echo " ?EXYNOS API ? ? $EXYNOS"
> ?echo ""
> diff --git a/exynos/Makefile.am b/exynos/Makefile.am
> new file mode 100644
> index 000..e782d34
> --- /dev/null
> +++ b/exynos/Makefile.am
> @@ -0,0 +1,22 @@
> +AM_CFLAGS = \
> + ? ? ? $(WARN_CFLAGS) \
> + ? ? ? -I$(top_srcdir) \
> + ? ? ? -I$(top_srcdir)/exynos \
> + ? ? ? $(PTHREADSTUBS_CFLAGS) \
> + ? ? ? -I$(top_srcdir)/include/drm
> +
> +libdrm_exynos_la_LTLIBRARIES = libdrm_exynos.la
> +libdrm_exynos_ladir = $(libdir)
> +libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
> +libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
> +
> +libdrm_exynos_la_SOURCES = exynos_drm.c
> +
> +libdrm_exynoscommonincludedir = ${includedir}/exynos
> +libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
> +
> +libdrm_exynosincludedir = ${includedir}/libdrm
> +libdrm_exynosinclude_HEADERS = exynos_drmif.h
> +
> +pkgconfigdir = @pkgconfigdir@
> +pkgconfig_DATA = libdrm_exynos.pc
> diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
> new file mode 100644
> index 000..778321a
> --- /dev/null
> +++ b/exynos/exynos_drm.c
> @@ -0,0 +1,324 @@
> +/*
> + * Copyright (C) 2012 Samsung Electronics Co., Ltd.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright 

PCI resources above 4GB

[Steven Newbury]

On Thu, 12 Apr 2012, 01:57:17 BST, Yinghai Lu  wrote:

> On Tue, Apr 10, 2012 at 2:19 PM, Steven Newbury 
> wrote:
> > Another thought, normally the integrated graphics has an "AGP"
> > aperture of 256M @0xe000, which is detected by agpgart-intel, this
> > will need to be moved up above 4G to free up 0xe000 for the
> > radeon, assuming the "agp_bridge" has a 64bit base register... ?I
> > noticed in my docked dmesg, "AGP aperture is 256M @ 0x2000", but
> > the PCI base: "12000-12fff : :00:02.0" so only 32bits have
> > been set in agpgart-intel. ?Explains why i915 wasn't initialised.
> 
> Attached patch should fix that high 32bit missing problem.

Thanks, that fixed it! :) I had a similar patch I've been working on but I had 
my fix in the wrong place!

In the working case, initially the BIOS has set GMA to within the low system 
DRAM 0xC000 obviously invalid.  This conflict is detected and it's 
relallocated to 0x1200.

I've attempted to modify probe.c to disable 64-bit BARs not allocated above 4G 
so they get reallocated above when possible later.  It seemed to work, but 
again broke GMA despite the BAR originally containing an invalid address as 
mentioned above, it seems for some reason something is different when the 
conflict is detected and rellocated, compared to disabling it early then 
allocating a valid value..?

It would be useful to preserve as much low PCI memory address space as possible 
for hotplug devices (like my Radeon), but the other problem is small regions 
get allocated at the bottom, resulting in the inability to find large aligned 
regions later on.  I see code to default to top-down allocation was reverted, I 
guess I'm going to have to dig into the archive to find out why...

Thanks for all your help so far, I've been learning a lot over the last few 
days.

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

[Adam Jackson]

"2560x1600", DRM_MODE_TYPE_DRIVER, 348500, 2560, 2760,
> +3032, 3504, 0, 1600, 1603, 1609, 1658, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },

lol no.  Nobody does a size this large without also doing reduced
blanking.

I have a patch somewhere to fix the DMT list to re-include the reduced
blanking modes (as should have been done in the first place).  I'll send
that along.

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120412/81cc067d/attachment.pgp>

[RFC 4/4] drm: Add NVIDIA Tegra support

[Jon Mayo]

On 04/11/2012 05:48 AM, Daniel Vetter wrote:
> On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
>> This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
>> currently has rudimentary GEM support and can run a console on the
>> framebuffer as well as X using the xf86-video-modesetting driver.
>> Only the RGB output is supported. Quite a lot of things still need
>> to be worked out and there is a lot of room for cleanup.
>
> Indeed, after a quick look there are tons of functions that are just stubs
> ;-) One thing I wonder though is why you directly use the iommu api and
> not wrap it up into dma_map? Is arm infrastructure just not there yet or
> do you plan to tightly integrate the tegra drm with the iommu (e.g. for
> process space switching or similarly funky stuff)?
>
> Yours, Daniel

An abstraction to access iommu is preferable since Tegra2 and Tegra3 are 
quite a bit different when it comes to iommu.

But so far I'm pretty pleased with the driver Thierry has done. I'm 
hoping we can start using this as a base instead of the fb based driver 
that never made it upstream. (even if I have had a bit of a debate about 
GEM v. TTM v. ION v. ...)

- Jon

[Bug 48599] New: Fix compiler warnings in tests/radeon/radeon_ttm.c

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

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

 Bug #: 48599
   Summary: Fix compiler warnings in tests/radeon/radeon_ttm.c
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: libdrm
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vuntz at gnome.org


Created attachment 59852
  --> https://bugs.freedesktop.org/attachment.cgi?id=59852
Fix compiler warnings in tests/radeon/radeon_ttm.c

The patch from openSUSE solves compiler warnings about use of implicit
declared-functions.

radeon_ttm.c: In function 'radeon_open_fd':
radeon_ttm.c:58:5: warning: implicit declaration of function 'drmOpen'
[-Wimplicit-function-declaration]
radeon_ttm.c: In function 'main':
radeon_ttm.c:73:5: warning: implicit declaration of function 'close'
[-Wimplicit-function-declaration]
radeon_ttm.c: At top level:

It was written by Jan Engelhardt 

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[RFC 4/4] drm: Add NVIDIA Tegra support

[Thierry Reding]

* Sascha Hauer wrote:
> You might want to have a look at the sdrm patches I recently posted to
> dri-devel and arm Linux Kernel. Among other things they allow to
> register crtcs/connectors/encoders seperately so that each of them can
> have its own representation in the devicetree. I haven't looked into
> devicetree support for DRM, but with or without devicetree the problem
> that we do not have a single PCI card for registering all DRM components
> is the same.

I'll do that. One interesting use-case that's been on my mind for some time
is if it would be possible to provide a CRTC via DRM that isn't part of the
SoC or DRM "device" but which can display a framebuffer prepared by the DRM
framework.

In other words I would like to use the Tegra hardware to render content into
a framebuffer (using potentially the 3D engine or HW accelerated video
decoding blocks) but display that framebuffer with a CRTC registered by a
different driver (perhaps provided by a PCIe or USB device).

I think such a setup would be possible if the CRTC registration can be
decoupled from the DRM driver. Perhaps sdrm even supports that already?

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

[RFC 4/4] drm: Add NVIDIA Tegra support

[Sascha Hauer]

On Wed, Apr 11, 2012 at 12:12:14PM -0600, Stephen Warren wrote:
> On 04/11/2012 06:10 AM, Thierry Reding wrote:
> > This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
> > currently has rudimentary GEM support and can run a console on the
> > framebuffer as well as X using the xf86-video-modesetting driver.
> > Only the RGB output is supported. Quite a lot of things still need
> > to be worked out and there is a lot of room for cleanup.
> 
> I'll let Jon Mayo comment on the actual driver implementation, since
> he's a lot more familiar with Tegra's display hardware. However, I have
> some general comments below.
> 
> >  .../devicetree/bindings/gpu/drm/tegra.txt  |   24 +
> >  arch/arm/mach-tegra/board-dt-tegra20.c |3 +
> >  arch/arm/mach-tegra/tegra2_clocks.c|8 +-
> >  drivers/gpu/drm/Kconfig|2 +
> >  drivers/gpu/drm/Makefile   |1 +
> >  drivers/gpu/drm/tegra/Kconfig  |   10 +
> >  drivers/gpu/drm/tegra/Makefile |5 +
> >  drivers/gpu/drm/tegra/tegra_drv.c  | 2241 
> > 
> >  drivers/gpu/drm/tegra/tegra_drv.h  |  184 ++
> >  include/drm/tegra_drm.h|   44 +
> 
> Splitting this patch into two, between arch/arm and drivers/gpu would be
> a good idea.
> 
> > diff --git a/Documentation/devicetree/bindings/gpu/drm/tegra.txt 
> > b/Documentation/devicetree/bindings/gpu/drm/tegra.txt
> 
> > +   drm at 5420 {
> > +   compatible = "nvidia,tegra20-drm";
> 
> This doesn't seem right; there isn't a "DRM" hardware module on Tegra,
> since "DRM" is a Linux/software-specific term.
> 
> I'd at least expect to see this compatible flag be renamed to something
> more like "nvidia,tegra20-dc" (dc==display controller).
> 
> Since Tegra has two display controller modules (I believe identical?),
> and numerous other independent(?) blocks, I'd expect to see multiple
> nodes in device tree, one per hardware block, such that each block gets
> its own device and driver. That said, I'm not familiar enough with
> Tegra's display and graphics HW to know if this makes sense. Jon, what's
> your take here? The clock change below, and in particular the original
> code there that we use downstream, lends weight to my argument.
> 
> > +   reg = < 0x5420 0x0004/* display A */
> > +   0x5424 0x0004/* display B */
> > +   0x5800 0x0200 >; /* GART aperture */
> > +   interrupts = < 0 73 0x04/* display A */
> > +  0 74 0x04 >; /* display B */
> > +
> > +   lvds {
> > +   type = "rgb";
> 
> These sub-nodes probably want a "compatible" property rather than a
> "type" property.
> 
> > +   size = <345 194>;
> > +
> > +   default-mode {
> > +   pixel-clock = <61715000>;
> > +   vertical-refresh = <50>;
> > +   resolution = <1366 768>;
> > +   bits-per-pixel = <16>;
> > +   horizontal-timings = <4 136 2 36>;
> > +   vertical-timings = <2 4 21 10>;
> > +   };
> > +   };
> 
> I imagine that quite a bit of thought needs to be put into the output
> part of the binding in order to:
> 
> * Model the outputs/connectors separately from display controllers.
> * Make sure that the basic infra-structure for representing an output is
> general enough to be extensible to all the kinds of outputs we support,
> not just the LVDS output.
> * We were wondering about putting an EDID into the DT to represent the
> display modes, so that all outputs had EDIDs rather than "real" monitors
> having EDIDs, and fixed internal displays having some other
> representation of capabilities.

You might want to have a look at the sdrm patches I recently posted to
dri-devel and arm Linux Kernel. Among other things they allow to
register crtcs/connectors/encoders seperately so that each of them can
have its own representation in the devicetree. I haven't looked into
devicetree support for DRM, but with or without devicetree the problem
that we do not have a single PCI card for registering all DRM components
is the same.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Fwd: [pull] drm-intel-next for 3.5

[Daniel Vetter]

Forwarding the pull request to Dave to intel-gfx and dri-devel, I've
fumbled the cc list on the original mail.
-Daniel

-- Forwarded message --
From: Daniel Vetter 
Date: Thu, Apr 12, 2012 at 11:17
Subject: [pull] drm-intel-next for 3.5
To: Dave Airlie 


Hi Dave

First pull request for 3.5-next, slightly large than usual because new
things kept coming in since the last pull for 3.4.
Highlights:
- first batch of hw enablement for vlv (Jesse et al) and hsw (Eugeni). pci
?ids are not yet added, and there's still quite a few patches to merge
?(mostly modesetting). To make QA easier I've decided to merge this stuff
?in pieces.
- loads of cleanups and prep patches spurred by the above. Especially vlv
?is a real frankenstein chip, but also hsw is stretching our driver's
?code design. Expect more to come in this area for 3.5.
- more gmbus fixes, cleanups and improvements by Daniel Kurtz. Again,
?there are more patches needed (and some already queued up), but I wanted
?to split this a bit for better testing.
- pwrite/pread rework and retuning. This series has been in the works for
?a few months already and a lot of i-g-t tests have been created for it.
?Now it's finally ready to be merged. ?Note that one patch in this series
?touches include/pagemap.h, that patch is acked-by akpm.
- reduce mappable pressure and relocation throughput improvements from
?Chris.
- mmap offset exhaustion mitigation by Chris Wilson.
- a start at figuring out which codepaths in our messy dri1/ums+gem/kms
?driver we actually need to support by bailing out of unsupported case.
?The driver now refuses to load without kms on gen6+ and disallows a few
?ioctls that userspace never used in certain cases. More of this will
?definitely come.
- More decoupling of global gtt and ppgtt.
- Improved dual-link lvds detection by Takashi Iwai.
- Shut up the compiler + plus fix the fallout (Ben)
- Inverted panel brightness handling (mostly Acer manages to break things
?in this way).
- Small fixlets and adjustements and some minor things to help debugging.

Regression-wise QA reported quite a few issues on ivb, but all of them
turned out to be hw stability issues which are already fixed in
drm-intel-fixes (QA runs the nightly regression tests on -next alone,
without -fixes automatically merged in). There's still one issue open on
snb, it looks like occlusion query writes are not quite as cache coherent
as we've expected. With some of the pwrite adjustements we can now
reliably hit this. Kernel workaround for it is in the works.

QA (and myself) also had some fun with resume regressions introduced by
upstream 3.4-rc1, but they all seem to be fixed in -rc2.

Yours, Daniel

The following changes since commit c501ae7f332cdaf42e31af30b72b4b66cbbb1604:

?drm/i915: Only clear the GPU domains upon a successful finish
(2012-03-01 21:36:13 +0100)

are available in the git repository at:

?git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2012-04-09

for you to fetch changes up to ec34a01de31128e5c08e5f05c47f4a787f45a33c:

?drm/i915: VCS is not the last ring (2012-04-09 18:04:10 +0200)


Adam Jackson (2):
? ? ?drm/i915: Pull MTRR setup to its own function
? ? ?drm/i915: Don't do MTRR setup if PAT is enabled

Ben Widawsky (5):
? ? ?drm/i915: [dinq] shut up two instances -Wunitialized
? ? ?drm/i915: [dinq] shut up six instances of -Warray-bounds
? ? ?drm/i915: ring irq cleanups
? ? ?drm/i915: open code gen6+ ring irqs
? ? ?drm/i915: VCS is not the last ring

Carsten Emde (3):
? ? ?drm/i915: panel: invert brightness via parameter
? ? ?drm/i915: panel: invert brightness via quirk
? ? ?drm/i915: panel: invert brightness acer aspire 5734z

Chris Wilson (5):
? ? ?drm/i915: Release the mmap offset when purging a buffer
? ? ?drm/i915: Batch copy_from_user for relocation processing
? ? ?drm/i915: Avoid using mappable space for relocation processing
through the CPU
? ? ?drm/i915: Initialise GTT MTRR to -1
? ? ?drm/i915/sdvo: Include YRPB as an additional TV output type

Daniel Kurtz (7):
? ? ?drm/i915/intel_i2c: refactor gmbus_xfer
? ? ?drm/i915/intel_i2c: cleanup error messages and comments
? ? ?drm/i915/intel_i2c: assign HDMI port D to pin pair 6
? ? ?drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfers
? ? ?drm/i915/intel_i2c: refactor using intel_gmbus_get_adapter
? ? ?drm/i915/intel_i2c: gmbus disabled and reserved ports are invalid
? ? ?drm/i915/intel_i2c: allocate gmbus array as part of drm_i915_private

Daniel Vetter (38):
? ? ?drm/i915: split out dma mapping from global gtt bind/unbind functions
? ? ?drm/i915: bind objects to the global gtt only when needed
? ? ?drm/i915: implement SNB workaround for lazy global gtt
? ? ?drm/i915: enable lazy global-gtt binding
? ? ?drm/i915: add HAS_ALIASING_PPGTT parameter for userspace
? ? ?drm/i915/sdov: switch IS_SDVOB to a flag
? ? ?drm/i915: add an explict mmio base for gpio/gmbus io
? ? 

[RFC 4/4] drm: Add NVIDIA Tegra support

[Arnd Bergmann]

On Thursday 12 April 2012, Marek Szyprowski wrote:
> Scatter lists were initially designed for the disk based block io operations, 
> hence the presence of the in-page offsets and lengths for each chunk. For 
> multimedia use cases providing an array of struct pages and asking 
> dma-mapping 
> to map them into contiguous memory is probably all we need. I wonder if 
> introducing such new calls is a good idea. Anrd, what do think? It will 
> definitely simplify the drivers and improve the code understanding. On the 
> other hand it requires a significant amount of work in the dma-mapping 
> framework for all architectures, but that's not a big issue for me.

My feeling is that it's too much like the existing _sg version, so I wouldn't
add yet another variant. While having a simple page array is definitely
simpler and potentially faster, I think the API is already too complex
and we need to be very careful with new additions.

Arnd

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Sascha Hauer]

On Wed, Apr 11, 2012 at 09:22:47PM +0100, Alan Cox wrote:
> > +static int sdrm_suspend(struct drm_device *drm, pm_message_t state)
> > +{
> > +   /* TODO */
> > +
> > +   return 0;
> > +}
> > +
> > +static int sdrm_resume(struct drm_device *drm)
> > +{
> > +   /* TODO */
> > +
> > +   return 0;
> > +}
> 
> These probably need to call into the sdrm device specific handling.
> 
> 
> > +static int sdrm_get_irq(struct drm_device *dev)
> > +{
> > +   /*
> > +* Return an arbitrary number to make the core happy.
> > +* We can't return anything meaningful here since drm
> > +* devices in general have multiple irqs
> > +*/
> > +   return 1234;
> > +}
> 
> If there isn't a meaningful IRQ then surely 0 should be returned.
> Actually I'd suggest returning sdrm->irq or similar, because some simple
> DRM type use cases will have a single IRQ (notably 2 on older PC hardware)

Hm, At the moment I can't even trigger this function to be called. I can
simply return 0 here. Returning a real irq does not sound sane since I
want the interrupt handled internally. Noone else has any business using
it.

> 
> > + * sdrm_device_get - find or allocate sdrm device with unique name
> > + *
> > + * This function returns the sdrm device with the unique name 'name'
> > + * If this already exists, return it, otherwise allocate a new
> > + * object.
> 
> This naming is a bit confusing because the kernel mid layers etc tend to
> use _get and _put for ref counting not lookup ?

Ok, lookup sounds better. Will rename it.

> 
> 
> > +   /*
> > +* enable drm irq mode.
> > +* - with irq_enabled = 1, we can use the vblank feature.
> > +*
> > +* P.S. note that we wouldn't use drm irq handler but
> > +*  just spsdrmific driver own one instead bsdrmause
> > +*  drm framework supports only one irq handler and
> > +*  drivers can well take care of their interrupts
> > +*/
> > +   drm->irq_enabled = 1;
> 
> We've got a couple of assumptions here I think I'd question for generality
> 
> 1. That its a platform device
> 2. That it can't use the standard IRQ helpers in some cases.
> 
> Probably it should take a struct device and a struct of the bits you'd
> fish out from platform or pci or other device type. And yes probably
> there would be a platform_ version that wraps it.

I had a look and it turned out that I don't need anything specific to a
platform_device, so I can simply pass in a regular struct device here.
Having a platform_device here seems to be a leftover from earlier
versions in which I used the drm_platform stubs.

> 
> 
> > +static int sdrm_fb_dirty(struct drm_framebuffer *fb,
> > +   struct drm_file *file_priv, unsigned flags,
> > +   unsigned color, struct drm_clip_rect *clips,
> > +   unsigned num_clips)
> > +{
> > +   /* TODO */
> > +
> > +   return 0;
> > +}
> 
> Probably a helper method.

Yes.

> 
> > +static struct fb_ops sdrm_fb_ops = {
> > +   .owner  = THIS_MODULE,
> > +   .fb_fillrect= cfb_fillrect,
> > +   .fb_copyarea= cfb_copyarea,
> > +   .fb_imageblit   = cfb_imageblit,
> > +   .fb_check_var   = drm_fb_helper_check_var,
> > +   .fb_set_par = drm_fb_helper_set_par,
> > +   .fb_blank   = drm_fb_helper_blank,
> > +   .fb_pan_display = drm_fb_helper_pan_display,
> > +   .fb_setcmap = drm_fb_helper_setcmap,
> > +};
> 
> If you re assuming any kind of gtt then you should probably allow for gtt
> based scrolling eventually, but thats an optimisation.

I'll keep that for later.

> 
> 
> > +int sdrm_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> > +{
> > +   struct drm_gem_object *obj = vma->vm_private_data;
> > +   struct sdrm_gem_obj *sdrm_gem_obj = to_sdrm_gem_obj(obj);
> > +   struct drm_device *dev = obj->dev;
> > +   unsigned long pfn;
> > +   pgoff_t page_offset;
> > +   int ret;
> 
> For dumb hardware take a look how gma500 and some other bits do this -
> you can premap the entire buffer when you take the first fault, which for
> a dumb fb is a good bet.
> 
> 
> 
> Looking at it from the point of view of x86 legacy devices then the
> things I see are
> 
> - Device is quite possibly PCI (but may be platform eg vesa)
> - Memory will probably be allocated in the PCI space
> - Mappings are probably write combining but not on all hardware
> 
> There's probably a case for pinning/unpinning scanout buffers according
> to whether they are used. On some hardware the io mapping needed is a
> precious resource. Also for stuff with a fixed fb space it means you can
> combine it with invalidating the mmap mappings of an object and copying
> objects in/out of the frame buffer to provide the expected interfaces to
> allocate/release framebuffers.

I'll have a look. Unfortunately my knowledge of these things is quite
limited. I am hoping a bit for Thierry here since he has a iommu on
Tegra and maybe this helps making the GEM support more generic.

Sascha

-- 
Pengutronix e.K.   |   

[PATCH 1/4] drm/radeon: make radeon_gpu_is_lockup a per ring function

[Alex Deucher]

2012/4/11 Christian K?nig :
> Different rings have different criteria to test
> if they are stuck.
>
> Signed-off-by: Christian K?nig 

For the series:

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/radeon/radeon.h ? ? ? | ? ?4 +-
> ?drivers/gpu/drm/radeon/radeon_asic.c ?| ? 36 +---
> ?drivers/gpu/drm/radeon/radeon_fence.c | ? ?2 +-
> ?3 files changed, 22 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index d2870a0..4ee9a1a 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1128,7 +1128,6 @@ struct radeon_asic {
> ? ? ? ?int (*resume)(struct radeon_device *rdev);
> ? ? ? ?int (*suspend)(struct radeon_device *rdev);
> ? ? ? ?void (*vga_set_state)(struct radeon_device *rdev, bool state);
> - ? ? ? bool (*gpu_is_lockup)(struct radeon_device *rdev, struct radeon_ring 
> *cp);
> ? ? ? ?int (*asic_reset)(struct radeon_device *rdev);
> ? ? ? ?/* ioctl hw specific callback. Some hw might want to perform special
> ? ? ? ? * operation on specific ioctl. For instance on wait idle some hw
> @@ -1157,6 +1156,7 @@ struct radeon_asic {
> ? ? ? ? ? ? ? ?void (*ring_start)(struct radeon_device *rdev, struct 
> radeon_ring *cp);
> ? ? ? ? ? ? ? ?int (*ring_test)(struct radeon_device *rdev, struct 
> radeon_ring *cp);
> ? ? ? ? ? ? ? ?int (*ib_test)(struct radeon_device *rdev, struct radeon_ring 
> *cp);
> + ? ? ? ? ? ? ? bool (*is_lockup)(struct radeon_device *rdev, struct 
> radeon_ring *cp);
> ? ? ? ?} ring[RADEON_NUM_RINGS];
> ? ? ? ?/* irqs */
> ? ? ? ?struct {
> @@ -1677,7 +1677,6 @@ void radeon_ring_write(struct radeon_ring *ring, 
> uint32_t v);
> ?#define radeon_suspend(rdev) (rdev)->asic->suspend((rdev))
> ?#define radeon_cs_parse(rdev, r, p) (rdev)->asic->ring[(r)].cs_parse((p))
> ?#define radeon_vga_set_state(rdev, state) 
> (rdev)->asic->vga_set_state((rdev), (state))
> -#define radeon_gpu_is_lockup(rdev, cp) (rdev)->asic->gpu_is_lockup((rdev), 
> (cp))
> ?#define radeon_asic_reset(rdev) (rdev)->asic->asic_reset((rdev))
> ?#define radeon_gart_tlb_flush(rdev) (rdev)->asic->gart.tlb_flush((rdev))
> ?#define radeon_gart_set_page(rdev, i, p) (rdev)->asic->gart.set_page((rdev), 
> (i), (p))
> @@ -1686,6 +1685,7 @@ void radeon_ring_write(struct radeon_ring *ring, 
> uint32_t v);
> ?#define radeon_ib_test(rdev, r, cp) (rdev)->asic->ring[(r)].ib_test((rdev), 
> (cp))
> ?#define radeon_ring_ib_execute(rdev, r, ib) 
> (rdev)->asic->ring[(r)].ib_execute((rdev), (ib))
> ?#define radeon_ring_ib_parse(rdev, r, ib) 
> (rdev)->asic->ring[(r)].ib_parse((rdev), (ib))
> +#define radeon_ring_is_lockup(rdev, r, cp) 
> (rdev)->asic->ring[(r)].is_lockup((rdev), (cp))
> ?#define radeon_irq_set(rdev) (rdev)->asic->irq.set((rdev))
> ?#define radeon_irq_process(rdev) (rdev)->asic->irq.process((rdev))
> ?#define radeon_get_vblank_counter(rdev, crtc) 
> (rdev)->asic->display.get_vblank_counter((rdev), (crtc))
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index 479c89e..a99fc2b 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -134,7 +134,6 @@ static struct radeon_asic r100_asic = {
> ? ? ? ?.suspend = _suspend,
> ? ? ? ?.resume = _resume,
> ? ? ? ?.vga_set_state = _vga_set_state,
> - ? ? ? .gpu_is_lockup = _gpu_is_lockup,
> ? ? ? ?.asic_reset = _asic_reset,
> ? ? ? ?.ioctl_wait_idle = NULL,
> ? ? ? ?.gui_idle = _gui_idle,
> @@ -152,6 +151,7 @@ static struct radeon_asic r100_asic = {
> ? ? ? ? ? ? ? ? ? ? ? ?.ring_start = _ring_start,
> ? ? ? ? ? ? ? ? ? ? ? ?.ring_test = _ring_test,
> ? ? ? ? ? ? ? ? ? ? ? ?.ib_test = _ib_test,
> + ? ? ? ? ? ? ? ? ? ? ? .is_lockup = _gpu_is_lockup,
> ? ? ? ? ? ? ? ?}
> ? ? ? ?},
> ? ? ? ?.irq = {
> @@ -208,7 +208,6 @@ static struct radeon_asic r200_asic = {
> ? ? ? ?.suspend = _suspend,
> ? ? ? ?.resume = _resume,
> ? ? ? ?.vga_set_state = _vga_set_state,
> - ? ? ? .gpu_is_lockup = _gpu_is_lockup,
> ? ? ? ?.asic_reset = _asic_reset,
> ? ? ? ?.ioctl_wait_idle = NULL,
> ? ? ? ?.gui_idle = _gui_idle,
> @@ -226,6 +225,7 @@ static struct radeon_asic r200_asic = {
> ? ? ? ? ? ? ? ? ? ? ? ?.ring_start = _ring_start,
> ? ? ? ? ? ? ? ? ? ? ? ?.ring_test = _ring_test,
> ? ? ? ? ? ? ? ? ? ? ? ?.ib_test = _ib_test,
> + ? ? ? ? ? ? ? ? ? ? ? .is_lockup = _gpu_is_lockup,
> ? ? ? ? ? ? ? ?}
> ? ? ? ?},
> ? ? ? ?.irq = {
> @@ -282,7 +282,6 @@ static struct radeon_asic r300_asic = {
> ? ? ? ?.suspend = _suspend,
> ? ? ? ?.resume = _resume,
> ? ? ? ?.vga_set_state = _vga_set_state,
> - ? ? ? .gpu_is_lockup = _gpu_is_lockup,
> ? ? ? ?.asic_reset = _asic_reset,
> ? ? ? ?.ioctl_wait_idle = NULL,
> ? ? ? ?.gui_idle = _gui_idle,
> @@ -300,6 +299,7 @@ static struct radeon_asic r300_asic = {
> ? ? ? ? ? ? ? ? ? ? ? ?.ring_start = _ring_start,
> ? ? ? ? ? ? ? ? ? ? ? ?.ring_test = _ring_test,
> ? ? ? ? ? ? ? ? ? ? ? ?.ib_test = _ib_test,
> + ? ? ? ? ? ? ? ? ? ? ? .is_lockup = 

[RFC 4/4] drm: Add NVIDIA Tegra support

[Marek Szyprowski]

Hi Thierry,

On Thursday, April 12, 2012 9:18 AM Thierry Reding wrote:

> * Arnd Bergmann wrote:
> > On Wednesday 11 April 2012, Thierry Reding wrote:
> > > Daniel Vetter wrote:
> > > > Well, you use the iommu api to map/unmap memory into the iommu for 
> > > > tegra,
> > > > whereas usually device drivers just use the dma api to do that. The 
> > > > usual
> > > > interface is dma_map_sg/dma_unmap_sg, but there are quite a few variants
> > > > around. I'm just wondering why this you've choosen this.
> > >
> > > I don't think this works on ARM. Maybe I'm not seeing the whole picture 
> > > but
> > > judging by a quick look through the kernel tree there aren't any users 
> > > that
> > > map DMA memory through an IOMMU.
> >
> > dma_map_sg is certainly the right interface to use, and Marek Szyprowski has
> > patches to make that work on ARM, hopefully going into v3.5, so you could
> > use those.
> 
> I've looked at Marek's patches but I don't think they'll work for Tegra 2 or
> Tegra 3. The corresponding iommu_map() functions only set one PTE, regardless
> of the number of bytes passed to them. However, the Tegra TRM indicates that
> mapping needs to be done on a per-page basis so contiguous regions cannot be
> combined. I suppose the IOMMU driver would have to be fixed to program more
> than a single page in that case.

I assume you want to map a set of pages into contiguous chunk in io address 
space.
This can be done with dma_map_sg() call once IOMMU aware implementation has been
assigned to the given device. DMA-mapping implementation is able to merge 
consecutive chunks of the scatter list in the dma/io address space if possible
(i.e. there are no in-page offsets between the chunks). With my implementation 
of IOMMU aware dma-mapping you usually you get a single DMA chunk from the 
provided scatter-list.

I know that this approach causes a lot of confusion at the first look, but that
how dma mapping api has been designed. The scatter list based approach has some
drawbacks - it is a bit oversized for most of the typical use cases for the 
gfx/multimedia buffers, but that's all we have now. 

Scatter lists were initially designed for the disk based block io operations, 
hence the presence of the in-page offsets and lengths for each chunk. For 
multimedia use cases providing an array of struct pages and asking dma-mapping 
to map them into contiguous memory is probably all we need. I wonder if 
introducing such new calls is a good idea. Anrd, what do think? It will 
definitely simplify the drivers and improve the code understanding. On the 
other hand it requires a significant amount of work in the dma-mapping 
framework for all architectures, but that's not a big issue for me.

> Also this doesn't yet solve the vmap() problem that is needed for the kernel
> virtual mapping. I did try using dma_alloc_writecombine(), but that only
> works for chunks of 2 MB or smaller, unless I use init_consistent_dma_size()
> during board setup, which isn't provided for in a DT setup. I couldn't find
> a better alternative, but I admit I'm not very familiar with all the VM APIs.
> Do you have any suggestions on how to solve this? Otherwise I'll try and dig
> in some more.

Yes, I'm aware of this issue I'm currently working on solving it. I hope to use 
standard vmalloc range for all coherent/writecombine allocations and get rid of
the custom 'consistent_dma' region at all.

Best regards
-- 
Marek Szyprowski
Samsung Poland R Center

[RFC 4/4] drm: Add NVIDIA Tegra support

[Alex Deucher]

On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher  wrote:
> On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
>  wrote:
>> * Alex Deucher wrote:
>>> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
>>>  wrote:
>>> > In other words I would like to use the Tegra hardware to render content 
>>> > into
>>> > a framebuffer (using potentially the 3D engine or HW accelerated video
>>> > decoding blocks) but display that framebuffer with a CRTC registered by a
>>> > different driver (perhaps provided by a PCIe or USB device).
>>> >
>>> > I think such a setup would be possible if the CRTC registration can be
>>> > decoupled from the DRM driver. Perhaps sdrm even supports that already?
>>>
>>> You should be able to do something like that already with dma_buf and
>>> the drm prime infrastructure. ?There's even a drm driver for the udl
>>> USB framebuffer devices.
>>
>> Using DRM PRIME requires user-space to be involved. I was thinking more along
>> the lines of allowing a dumb DRM driver that only provides a CRTC to register
>> with another driver so that it shows up as an output for the latter DRM
>> device.
>
> Even then it could get tricky with synchronization depending on the hw.
>
>>
>> Then again, having user-space control this may be more flexible. Performance-
>> wise both should be about the same, right? What I don't quite understand yet
>> is how the DMABUF would be synchronized on both ends. Is there some infra-
>> structure to account for it or would I have to export two buffers and flip
>> them during the vblank of the "consumer"?
>
> Performance should be about the same. ?The tricky part is
> synchronization. ?dma_buf is for sharing. ?There are ideas to make
> generic sync objects, but for now, it's up to the userspace components
> to handle it.

Some example code:
http://lists.freedesktop.org/archives/dri-devel/2012-April/021182.html

Alex

[RFC 4/4] drm: Add NVIDIA Tegra support

[Alex Deucher]

On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
 wrote:
> * Alex Deucher wrote:
>> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
>>  wrote:
>> > In other words I would like to use the Tegra hardware to render content 
>> > into
>> > a framebuffer (using potentially the 3D engine or HW accelerated video
>> > decoding blocks) but display that framebuffer with a CRTC registered by a
>> > different driver (perhaps provided by a PCIe or USB device).
>> >
>> > I think such a setup would be possible if the CRTC registration can be
>> > decoupled from the DRM driver. Perhaps sdrm even supports that already?
>>
>> You should be able to do something like that already with dma_buf and
>> the drm prime infrastructure. ?There's even a drm driver for the udl
>> USB framebuffer devices.
>
> Using DRM PRIME requires user-space to be involved. I was thinking more along
> the lines of allowing a dumb DRM driver that only provides a CRTC to register
> with another driver so that it shows up as an output for the latter DRM
> device.

Even then it could get tricky with synchronization depending on the hw.

>
> Then again, having user-space control this may be more flexible. Performance-
> wise both should be about the same, right? What I don't quite understand yet
> is how the DMABUF would be synchronized on both ends. Is there some infra-
> structure to account for it or would I have to export two buffers and flip
> them during the vblank of the "consumer"?

Performance should be about the same.  The tricky part is
synchronization.  dma_buf is for sharing.  There are ideas to make
generic sync objects, but for now, it's up to the userspace components
to handle it.

Alex

[RFC 4/4] drm: Add NVIDIA Tegra support

[Stephen Warren]

On 04/12/2012 12:50 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/11/2012 06:10 AM, Thierry Reding wrote:
>>> This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
>>> currently has rudimentary GEM support and can run a console on the
>>> framebuffer as well as X using the xf86-video-modesetting driver.
>>> Only the RGB output is supported. Quite a lot of things still need
>>> to be worked out and there is a lot of room for cleanup.
...
>>> diff --git a/Documentation/devicetree/bindings/gpu/drm/tegra.txt 
>>> b/Documentation/devicetree/bindings/gpu/drm/tegra.txt
...
>> This doesn't seem right, and couples back to my assertion above that the
>> two display controller modules probably deserve separate device objects,
>> named e.g. tegradc.*.
> 
> I think I understand where you're going with this. Does the following look
> more correct?
> 
>   disp1 : dc at 5420 {
>   compatible = "nvidia,tegra20-dc";
>   reg = <0x5420, 0x0004>;
>   interrupts = <0 73 0x04>;
>   };
> 
>   disp2 : dc at 5424 {
>   compatible = "nvidia,tegra20-dc";
>   reg = <0x5424, 0x0004>;
>   interrupts = <0 74 0x04>;
>   };

Those look good.

>   drm {
>   compatible = "nvidia,tegra20-drm";

I'm don't think having an explicit "drm" node is the right approach; drm
is after all a SW term and the DT should be describing HW. Having some
kind of top-level node almost certainly makes sense, but naming it
something related to "tegra display" than "drm" would be appropriate.

>   lvds {
>   compatible = "...";
>   dc = <>;
>   };

Aren't the outputs separate HW blocks too, such that they would have
their own compatible/reg properties and their own drivers, and be
outside the top-level drm/display node?

I believe the mapping between the output this node represents and the
display controller ("dc" above) that it uses is not static; the
connectivity should be set up at runtime, and possibly dynamically
alterable via xrandr or equivalent.

>   hdmi {
>   compatible = "...";
>   dc = <>;
>   };
>   };

>>> +static int tegra_drm_parse_dt(struct platform_device *pdev)
>>> +{
>> ...
>>> +   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>>> +   if (!pdata)
>>> +   return -ENOMEM;
>> ...
>>> +   dev->platform_data = pdata;
>>
>> I don't think you should assign to dev->platform_data. If you do, then I
>> think the following could happen:
>>
>> * During first probe, the assignment above happens
>> * Module is removed, hence device removed, hence dev->platform_data
>> freed, but not zero'd out
>> * Module is re-inserted, finds that dev->platform_data!=NULL and
>> proceeds to use it.
> 
> Actually the code does zero out platform_data in tegra_drm_remove(). In fact
> I did test module unloading and reloading and it works properly. But it
> should probably be zeroed in case drm_platform_init() fails as well.
>
>> Instead, the active platform data should probably be stored in a
>> tegra_drm struct that's stored in the dev's private data.
>> tegra_drm_probe() might then look more like:
>>
>> struct tegra_drm *tdev;
>>
>> tdev = devm_kzalloc();
>> tdev->pdata = pdev->dev.platform_data;
>> if (!tdev->pdata)
>> tdev->pdata = tegra_drm_parse_dt();
>> if (!tdev->pdata)
>> return -EINVAL;
>>
>> dev_set_drvdata(dev, tdev);
>>
>> This is safe, since probe() will never assume that dev_get_drvdata()
>> might contain something valid before probe() sets it.
> 
> I prefer my approach over storing the data in an extra field because the
> device platform_data field is where everybody would expect it. Furthermore
> this wouldn't be relevant if we decided not to support non-DT setups.

Drivers are expected to use pre-existing platform data, if provided.
This might happen in order to work around bugs in device tree content.

[pull] drm-intel-fixes for 3.4-rc3

[Daniel Vetter]

Hi Dave

3 regression fixes:
- disable gmbus again, too broken for 3.4, we'll try again for 3.5
- dp bandwidth computation fix, we've lost the 6bpc dithering flag
  sometimes, this is a 3.3 regression (maybe even earlier for some
  configurations).
- fix resume regression caused by the gen2/3 fencing fix merged into -rc2.

And a few other fixes:
- gpu hang fix for i845 (Chris)
- sprite fix (Armin Reese)
- crtc disable vs. scanlinewait race fix (Chris)
- rc6 module option read-only, it confused testers (Jesse)
- fbc related blitter death hw workaround, note that we disable fbc on snb
  by default anyway.

With these fixes we have one 3.4 regression outstanding: One of the
cleanup patches for the interlaced support managed to confuse the lvds
panel fitter when upscaling. The root-cause is still unclear, but test
patches are awaiting feedback from the reporter.

Yours, Daniel

The following changes since commit 0034102808e0dbbf3a2394b82b1bb40b5778de9e:

  Linux 3.4-rc2 (2012-04-07 18:30:41 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to 15a13bbdffb0d6288a5dd04aee9736267da1335f:

  drm/i915: clear fencing tracking state when retiring requests (2012-04-12 
09:02:37 +0200)


Chris Wilson (2):
  drm/i915: Finish any pending operations on the framebuffer before 
disabling
  drm/i915/ringbuffer: Exclude last 2 cachlines of ring on 845g

Daniel Vetter (4):
  drm/i915: properly compute dp dithering for user-created modes
  Revert "drm/i915: reenable gmbus on gen3+ again"
  drm/i915: implement ColorBlt w/a
  drm/i915: clear fencing tracking state when retiring requests

Jesse Barnes (1):
  drm/i915: make rc6 module parameter read-only

acreese (1):
  drm/i915: Removed IVB forced enable of sprite dest key.

 drivers/gpu/drm/i915/i915_drv.c |2 +-
 drivers/gpu/drm/i915/i915_gem.c |2 +
 drivers/gpu/drm/i915/i915_reg.h |3 +
 drivers/gpu/drm/i915/intel_display.c|   69 ++
 drivers/gpu/drm/i915/intel_dp.c |   49 --
 drivers/gpu/drm/i915/intel_i2c.c|2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |2 +-
 drivers/gpu/drm/i915/intel_sprite.c |1 -
 8 files changed, 93 insertions(+), 37 deletions(-)
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH libdrm] exynos: add exynos drm support

[Alex Deucher]

2012/4/12 InKi Dae :
> Please, give me any comments and I hope this patch would be applied to
> libdrm if there is any problem.

Looks good to me.

Reviewed-by: Alex Deucher 

If you need an fdo account, you can request one here:
http://www.freedesktop.org/wiki/AccountRequests

Alex

>
> Thanks,
> Inki Dae.
>
>
> 2012? 4? 2? ?? 9:08, Inki Dae ?? ?:
>> this patch adds libdrm_exynos helper layer that inclues some intefaces
>> for exynos specific gem and virtual display driver and also adds exynos
>> module name to modtest and vbltest.
>>
>> this patch is based on a link below:
>>git://anongit.freedesktop.org/mesa/drm
>>commit id: e057a56448e2e785f74bc13dbd6ead8572ebed91
>>
>> Signed-off-by: Inki Dae 
>> Signed-off-by: Kyungmin Park 
>> ---
>>  Makefile.am|6 +-
>>  configure.ac   |   13 ++
>>  exynos/Makefile.am |   22 +++
>>  exynos/exynos_drm.c|  324 
>> 
>>  exynos/exynos_drm.h|  127 +
>>  exynos/exynos_drmif.h  |   60 
>>  exynos/libdrm_exynos.pc.in |   11 ++
>>  tests/modetest/modetest.c  |2 +-
>>  tests/vbltest/vbltest.c|2 +-
>>  9 files changed, 564 insertions(+), 3 deletions(-)
>>  create mode 100644 exynos/Makefile.am
>>  create mode 100644 exynos/exynos_drm.c
>>  create mode 100644 exynos/exynos_drm.h
>>  create mode 100644 exynos/exynos_drmif.h
>>  create mode 100644 exynos/libdrm_exynos.pc.in
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 4f625a1..256a8cc 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -45,7 +45,11 @@ if HAVE_OMAP
>>  OMAP_SUBDIR = omap
>>  endif
>>
>> -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
>> $(RADEON_SUBDIR) $(OMAP_SUBDIR) tests include
>> +if HAVE_EXYNOS
>> +EXYNOS_SUBDIR = exynos
>> +endif
>> +
>> +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
>> $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) tests include
>>
>>  libdrm_la_LTLIBRARIES = libdrm.la
>>  libdrm_ladir = $(libdir)
>> diff --git a/configure.ac b/configure.ac
>> index 1ba7eba..ae84817 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -88,6 +88,11 @@ AC_ARG_ENABLE(omap-experimental-api,
>>  [Enable support for OMAP's experimental API (default: 
>> disabled)]),
>>  [OMAP=$enableval], [OMAP=no])
>>
>> +AC_ARG_ENABLE(exynos-experimental-api,
>> + AS_HELP_STRING([--enable-exynos-experimental-api],
>> + [Enable support for EXYNOS's experimental API (default: 
>> disabled)]),
>> + [EXYNOS=$enableval], [EXYNOS=no])
>> +
>>  dnl 
>> ===
>>  dnl check compiler flags
>>  AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
>> @@ -191,6 +196,11 @@ if test "x$OMAP" = xyes; then
>>AC_DEFINE(HAVE_OMAP, 1, [Have OMAP support])
>>  fi
>>
>> +AM_CONDITIONAL(HAVE_EXYNOS, [test "x$EXYNOS" = xyes])
>> +if test "x$EXYNOS" = xyes; then
>> +   AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support])
>> +fi
>> +
>>  PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
>>  if test "x$HAVE_CAIRO" = xyes; then
>>AC_DEFINE(HAVE_CAIRO, 1, [Have cairo support])
>> @@ -302,6 +312,8 @@ AC_CONFIG_FILES([
>>nouveau/libdrm_nouveau.pc
>>omap/Makefile
>>omap/libdrm_omap.pc
>> +   exynos/Makefile
>> +   exynos/libdrm_exynos.pc
>>tests/Makefile
>>tests/modeprint/Makefile
>>tests/modetest/Makefile
>> @@ -322,4 +334,5 @@ echo "  vmwgfx API $VMWGFX"
>>  echo "  Radeon API $RADEON"
>>  echo "  Nouveau API$NOUVEAU"
>>  echo "  OMAP API   $OMAP"
>> +echo "  EXYNOS API $EXYNOS"
>>  echo ""
>> diff --git a/exynos/Makefile.am b/exynos/Makefile.am
>> new file mode 100644
>> index 000..e782d34
>> --- /dev/null
>> +++ b/exynos/Makefile.am
>> @@ -0,0 +1,22 @@
>> +AM_CFLAGS = \
>> +   $(WARN_CFLAGS) \
>> +   -I$(top_srcdir) \
>> +   -I$(top_srcdir)/exynos \
>> +   $(PTHREADSTUBS_CFLAGS) \
>> +   -I$(top_srcdir)/include/drm
>> +
>> +libdrm_exynos_la_LTLIBRARIES = libdrm_exynos.la
>> +libdrm_exynos_ladir = $(libdir)
>> +libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
>> +libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
>> +
>> +libdrm_exynos_la_SOURCES = exynos_drm.c
>> +
>> +libdrm_exynoscommonincludedir = ${includedir}/exynos
>> +libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
>> +
>> +libdrm_exynosincludedir = ${includedir}/libdrm
>> +libdrm_exynosinclude_HEADERS = exynos_drmif.h
>> +
>> +pkgconfigdir = @pkgconfigdir@
>> +pkgconfig_DATA = libdrm_exynos.pc
>> diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
>> new file mode 100644
>> index 000..778321a
>> --- /dev/null
>> +++ b/exynos/exynos_drm.c
>> @@ -0,0 +1,324 @@
>> +/*
>> + * Copyright (C) 2012 Samsung Electronics Co., Ltd.
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of 

[RFC 4/4] drm: Add NVIDIA Tegra support

[Thierry Reding]

* Arnd Bergmann wrote:
> On Wednesday 11 April 2012, Thierry Reding wrote:
> > Daniel Vetter wrote:
> > > Well, you use the iommu api to map/unmap memory into the iommu for tegra,
> > > whereas usually device drivers just use the dma api to do that. The usual
> > > interface is dma_map_sg/dma_unmap_sg, but there are quite a few variants
> > > around. I'm just wondering why this you've choosen this.
> > 
> > I don't think this works on ARM. Maybe I'm not seeing the whole picture but
> > judging by a quick look through the kernel tree there aren't any users that
> > map DMA memory through an IOMMU.
> 
> dma_map_sg is certainly the right interface to use, and Marek Szyprowski has
> patches to make that work on ARM, hopefully going into v3.5, so you could
> use those.

I've looked at Marek's patches but I don't think they'll work for Tegra 2 or
Tegra 3. The corresponding iommu_map() functions only set one PTE, regardless
of the number of bytes passed to them. However, the Tegra TRM indicates that
mapping needs to be done on a per-page basis so contiguous regions cannot be
combined. I suppose the IOMMU driver would have to be fixed to program more
than a single page in that case.

Also this doesn't yet solve the vmap() problem that is needed for the kernel
virtual mapping. I did try using dma_alloc_writecombine(), but that only
works for chunks of 2 MB or smaller, unless I use init_consistent_dma_size()
during board setup, which isn't provided for in a DT setup. I couldn't find
a better alternative, but I admit I'm not very familiar with all the VM APIs.
Do you have any suggestions on how to solve this? Otherwise I'll try and dig
in some more.

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

[RFC 4/4] drm: Add NVIDIA Tegra support

[Alex Deucher]

On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
 wrote:
> * Sascha Hauer wrote:
>> You might want to have a look at the sdrm patches I recently posted to
>> dri-devel and arm Linux Kernel. Among other things they allow to
>> register crtcs/connectors/encoders seperately so that each of them can
>> have its own representation in the devicetree. I haven't looked into
>> devicetree support for DRM, but with or without devicetree the problem
>> that we do not have a single PCI card for registering all DRM components
>> is the same.
>
> I'll do that. One interesting use-case that's been on my mind for some time
> is if it would be possible to provide a CRTC via DRM that isn't part of the
> SoC or DRM "device" but which can display a framebuffer prepared by the DRM
> framework.
>
> In other words I would like to use the Tegra hardware to render content into
> a framebuffer (using potentially the 3D engine or HW accelerated video
> decoding blocks) but display that framebuffer with a CRTC registered by a
> different driver (perhaps provided by a PCIe or USB device).
>
> I think such a setup would be possible if the CRTC registration can be
> decoupled from the DRM driver. Perhaps sdrm even supports that already?

You should be able to do something like that already with dma_buf and
the drm prime infrastructure.  There's even a drm driver for the udl
USB framebuffer devices.

Alex

PCI resources above 4GB

[Yinghai Lu]

On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury  
wrote:
> Thanks, that fixed it! :) I had a similar patch I've been working on but I 
> had my fix in the wrong place!
>
> In the working case, initially the BIOS has set GMA to within the low system 
> DRAM 0xC000 obviously invalid. ?This conflict is detected and it's 
> relallocated to 0x1200.
>
> I've attempted to modify probe.c to disable 64-bit BARs not allocated above 
> 4G so they get reallocated above when possible later. ?It seemed to work, but 
> again broke GMA despite the BAR originally containing an invalid address as 
> mentioned above, it seems for some reason something is different when the 
> conflict is detected and rellocated, compared to disabling it early then 
> allocating a valid value..?
>
> It would be useful to preserve as much low PCI memory address space as 
> possible for hotplug devices (like my Radeon), but the other problem is small 
> regions get allocated at the bottom, resulting in the inability to find large 
> aligned regions later on. ?I see code to default to top-down allocation was 
> reverted, I guess I'm going to have to dig into the archive to find out why...

for hotplug case, You can work around like:
after hotplug add,
1. use lspci and /proc/iomem to find out offending device and bridge.
2. use /sys/.../unbind etc to stop driver for those devices.
3. use setpci to clear related BAR
4. use /sys/devices/pci000/remove to remove those devices
5. echo 1 > /sys/bus/pci/rescan

then it should work...

Yinghai

[Intel-gfx] [PATCH] drm/i915: clear fencing tracking state when retiring request

[Daniel Vetter]

On Thu, Apr 12, 2012 at 12:38:09AM +0100, Chris Wilson wrote:
> On Thu, 12 Apr 2012 01:27:57 +0200, Daniel Vetter  
> wrote:
> > This fixes a regression introduce in
> s/introduce/introduced/
>  
> > commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
> > Author: Chris Wilson 
> > Date:   Wed Mar 21 10:48:18 2012 +
> > 
> > drm/i915: Mark untiled BLT commands as fenced on gen2/3
> > 
> > which fixed fencing tracking for untiled blt commands.
> > 
> > A side effect of that patch was that now also untiled objects have a
> > non-zero obj->last_fenced_seqno to track when a fence can be set up
> > after a pipelined tiling change. Unfortunately this was only cleared
> > by the fence setup and teardown code, resulting in tons of untiled but
> > inactive objects with non-zero last_fenced_seqno.
> > 
> > Now after resume we completely reset the seqno tracking, both on the
> > driver side (by setting dev_priv->next_seqno = 1) and on the hw side
> > (by allocating a new hws page, which contains the seqnos). Hilarity
> > and indefinite waits ensued from the stale seqnos in
> > obj->last_fenced_seqno from before the suspend.
> > 
> > The fix is to properly clear the fencing tracking state like we
> > already do for the normal gpu rendering while moving objects off the
> > active list.
> > 
> > Reported-and-tested-by: "Rafael J. Wysocki" 
> > Cc: Jiri Slaby 
> > Signed-Off-by: Daniel Vetter 
> 
> I spent sometime discussing whether or not we could hit a similar bug
> with a well placed change of tiling after resume, and the outcome is
> that as the fences are reset during freeze then all tiled objects that
> had been used for rendering would have been flushed (and their
> last_fenced_seqno set to 0).
> 
> So this is a new regression caused by the aforementioned patch and this
> is the cleanest fix,
> Reviewed-by: Chris Wilson 
Picked up for -fixes, thanks for the review.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[RFC 3/4] drm: fixed: Add dfixed_frac() macro

[Thierry Reding]

* Stephen Warren wrote:
> On 04/11/2012 06:10 AM, Thierry Reding wrote:
> > This commit is taken from the Chromium tree and was originally written
> > by Robert Morell.
> 
> Maybe just cherry-pick it from there? That way, the git authorship will
> show up as Robert.

I can do that. Though I'll have to remove the Chromium-specific tags.

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

[RFC 2/4] iommu: tegra/gart: Add device tree support

[Thierry Reding]

* Stephen Warren wrote:
> On 04/11/2012 06:10 AM, Thierry Reding wrote:
> > This commit adds device tree support for the GART hardware available on
> > NVIDIA Tegra 20 SoCs.
> > 
> > Signed-off-by: Thierry Reding 
> > ---
> >  arch/arm/boot/dts/tegra20.dtsi |6 ++
> >  arch/arm/mach-tegra/board-dt-tegra20.c |1 +
> >  drivers/iommu/tegra-gart.c |   10 ++
> >  3 files changed, 17 insertions(+)
> 
> I think I'd prefer at least the tegra20.dtsi change split out into a
> separate patch so I can queue it in a "dt" topic branch in the Tegra repo.
> 
> It might be a good idea to split this into two on an arch/arm vs.
> drivers/iommu boundary. Looking at Olof's branches for 3.4, that split
> is what happened there.
> 
> Finally, there should be a binding documentation file in
> Documentation/devicetree/bindings in order to specify the number of reg
> property entries needed, and their meaning, since there's more than 1
> (even though you did comment it nicely in the .dtsi file)

Okay, I'll do that.

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

[RFC 4/4] drm: Add NVIDIA Tegra support

[Thierry Reding]

  NULL,   27, 0x138,  
> > 6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and 
> > process_id */
> > -   PERIPH_CLK("disp2", "tegradc.1",NULL,   26, 0x13c,  
> > 6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and 
> > process_id */
> > +   PERIPH_CLK("disp1", "tegra-drm",NULL,   27, 0x138,  
> > 6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and 
> > process_id */
> > +   PERIPH_CLK("disp2", "tegra-drm",NULL,   26, 0x13c,  
> > 6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and 
> > process_id */
> 
> This doesn't seem right, and couples back to my assertion above that the
> two display controller modules probably deserve separate device objects,
> named e.g. tegradc.*.

I think I understand where you're going with this. Does the following look
more correct?

disp1 : dc at 5420 {
compatible = "nvidia,tegra20-dc";
reg = <0x5420, 0x0004>;
interrupts = <0 73 0x04>;
};

disp2 : dc at 5424 {
compatible = "nvidia,tegra20-dc";
reg = <0x5424, 0x0004>;
interrupts = <0 74 0x04>;
};

drm {
compatible = "nvidia,tegra20-drm";

lvds {
compatible = "...";
dc = <>;
};

hdmi {
compatible = "...";
dc = <>;
};
};

> > +static int tegra_drm_parse_dt_mode(struct device *dev,
> ...
> > +   err = of_property_read_u32(node, "pixel-clock", );
> > +   if (err < 0)
> > +   return err;
> 
> Is it useful to call dev_err() when the DT is present but can't be
> parsed, to give some clue what the problem is?

Yes, that might be a good idea.

> > +static int tegra_drm_parse_dt(struct platform_device *pdev)
> > +{
> ...
> > +   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> > +   if (!pdata)
> > +   return -ENOMEM;
> ...
> > +   dev->platform_data = pdata;
> 
> I don't think you should assign to dev->platform_data. If you do, then I
> think the following could happen:
> 
> * During first probe, the assignment above happens
> * Module is removed, hence device removed, hence dev->platform_data
> freed, but not zero'd out

Actually the code does zero out platform_data in tegra_drm_remove(). In fact
I did test module unloading and reloading and it works properly. But it
should probably be zeroed in case drm_platform_init() fails as well.

> * Module is re-inserted, finds that dev->platform_data!=NULL and
> proceeds to use it.
> 
> Instead, the active platform data should probably be stored in a
> tegra_drm struct that's stored in the dev's private data.
> tegra_drm_probe() might then look more like:
> 
> struct tegra_drm *tdev;
> 
> tdev = devm_kzalloc();
> tdev->pdata = pdev->dev.platform_data;
> if (!tdev->pdata)
> tdev->pdata = tegra_drm_parse_dt();
> if (!tdev->pdata)
> return -EINVAL;
> 
> dev_set_drvdata(dev, tdev);
> 
> This is safe, since probe() will never assume that dev_get_drvdata()
> might contain something valid before probe() sets it.

I prefer my approach over storing the data in an extra field because the
device platform_data field is where everybody would expect it. Furthermore
this wouldn't be relevant if we decided not to support non-DT setups.

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

exynos broken ioctl

[Dave Airlie]

please before submitting ioctl's can someone review them to make sure
they have no pointers in them ever.

struct drm_exynos_vidi_connection {
unsigned int connection;
unsigned int extensions;
uint64_t *edid;
};

gets passed into DRM_EXYNOS_VIDI_CONNECTION ioctl.

Can you remove the point, it should be just a uint64_t most likely.

I don't think this has been in a released kernel so should be okay to fix.

Dave.

[Bug 48535] Spurious GL_INVALID_OPERATION error generated by glColor()

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

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

Alex Deucher  changed:

   What|Removed |Added

 AssignedTo|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org
  Component|Drivers/DRI/Radeon  |Mesa core

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] gma500: Don't needlessly include version.h in mdfld_dsi_output.h

[Kirill A. Shutemov]

On Thu, Apr 12, 2012 at 12:05:29AM +0200, Jesper Juhl wrote:
> drivers/gpu/drm/gma500/mdfld_dsi_output.h does not need to
> '#include ' - so don't.
> 
> Signed-off-by: Jesper Juhl 

Acked-by: Kirill A. Shutemov 

-- 
 Kirill A. Shutemov
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120412/322c0391/attachment.pgp>

[PATCH 4/8 v7] drm/i915/intel_i2c: use WAIT cycle, not STOP

[Daniel Kurtz]

On Wed, Apr 11, 2012 at 5:34 AM, Chris Wilson  
wrote:
> On Tue, 10 Apr 2012 17:03:04 +0200, Daniel Vetter  wrote:
>> On Tue, Apr 10, 2012 at 06:56:15PM +0800, Daniel Kurtz wrote:
>> > On Tue, Apr 10, 2012 at 6:41 PM, Daniel Vetter  wrote:
>> > > On Tue, Apr 10, 2012 at 12:37:46PM +0200, Daniel Vetter wrote:
>> > >> On Fri, Mar 30, 2012 at 07:46:39PM +0800, Daniel Kurtz wrote:
>> > >> > The i915 is only able to generate a STOP cycle (i.e. finalize an i2c
>> > >> > transaction) during a DATA or WAIT phase. ?In other words, the
>> > >> > controller rejects a STOP requested as part of the first transaction 
>> > >> > in a
>> > >> > sequence.
>> > >> >
>> > >> > Thus, for the first transaction we must always use a WAIT cycle, 
>> > >> > detect
>> > >> > when the device has finished (and is in a WAIT phase), and then either
>> > >> > start the next transaction, or, if there are no more transactions,
>> > >> > generate a STOP cycle.
>> > >> >
>> > >> > Note: Theoretically, the last transaction of a multi-transaction 
>> > >> > sequence
>> > >> > could initiate a STOP cycle. ?However, this slight optimization is 
>> > >> > left
>> > >> > for another patch. ?We return -ETIMEDOUT if the hardware doesn't
>> > >> > deactivate after the STOP cycle.
>> > >> >
>> > >> > Signed-off-by: Daniel Kurtz 
>> > >>
>> > >> I've re-read gmbus register spec and STOP seems to be allowed even in 
>> > >> the
>> > >> first cycle. Does this patch solve an issue for you? If not, I prefer we
>> > >> just drop it.
>> >
>> > STOP does not work in the first cycle, hence the patch.
>>
>> Ok, I've picked this patch up and extended the comment a bit to that
>> effect. Just to avoid anyone else trying to 'fix' things because bspec
>> sounds like it should work.
>>
>> I've also picked up the other patches safe for the last one, thanks a lot
>> for digging through the gmbus code and fixing it all up.
>>
>> Now can I volunteer you for a (hopefully) last set of gmbus patches?
>> Afaics there are a few small things left to fix:
>> - zero-length reads can blow up the kernel, like zero-length writes could.
>> ? See: https://bugs.freedesktop.org/show_bug.cgi?id=48269
>> - Chris Wilson suggested on irc that we should wait for HW_READY even for
>> ? zero-length writes (and also reads), currently we don't.
>> - atm the debug output is too noisy. I think we can leave the fallback to
>> ? gpio bitbanging at info (or maybe error) level, but all the other
>> ? messages should be tuned down to DRM_DEBUG_KMS - these can easily be hit
>> ? when userspace tries to probe the i2c with nothing connected or if the
>> ? driver code tries to do the same. See:
>> ? https://bugs.freedesktop.org/show_bug.cgi?id=48248
>>
>> Chris, anything you want to add to the wishlist?
>
> The last major item on the wishlist is solving how to drive the SDVO i2c
> over gmbus. I think it is just a matter of massaging in the channel
> switch as msg[0].

I noticed that random other i2c adapter, but haven't looked at it to
know why it is so different than the others.  What is it?

> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre

[PATCH 4/8 v7] drm/i915/intel_i2c: use WAIT cycle, not STOP

[Daniel Kurtz]

On Tue, Apr 10, 2012 at 11:03 PM, Daniel Vetter  wrote:
> On Tue, Apr 10, 2012 at 06:56:15PM +0800, Daniel Kurtz wrote:
>> On Tue, Apr 10, 2012 at 6:41 PM, Daniel Vetter  wrote:
>> > On Tue, Apr 10, 2012 at 12:37:46PM +0200, Daniel Vetter wrote:
>> >> On Fri, Mar 30, 2012 at 07:46:39PM +0800, Daniel Kurtz wrote:
>> >> > The i915 is only able to generate a STOP cycle (i.e. finalize an i2c
>> >> > transaction) during a DATA or WAIT phase. ?In other words, the
>> >> > controller rejects a STOP requested as part of the first transaction in 
>> >> > a
>> >> > sequence.
>> >> >
>> >> > Thus, for the first transaction we must always use a WAIT cycle, detect
>> >> > when the device has finished (and is in a WAIT phase), and then either
>> >> > start the next transaction, or, if there are no more transactions,
>> >> > generate a STOP cycle.
>> >> >
>> >> > Note: Theoretically, the last transaction of a multi-transaction 
>> >> > sequence
>> >> > could initiate a STOP cycle. ?However, this slight optimization is left
>> >> > for another patch. ?We return -ETIMEDOUT if the hardware doesn't
>> >> > deactivate after the STOP cycle.
>> >> >
>> >> > Signed-off-by: Daniel Kurtz 
>> >>
>> >> I've re-read gmbus register spec and STOP seems to be allowed even in the
>> >> first cycle. Does this patch solve an issue for you? If not, I prefer we
>> >> just drop it.
>>
>> STOP does not work in the first cycle, hence the patch.
>
> Ok, I've picked this patch up and extended the comment a bit to that
> effect. Just to avoid anyone else trying to 'fix' things because bspec
> sounds like it should work.
>
> I've also picked up the other patches safe for the last one, thanks a lot
> for digging through the gmbus code and fixing it all up.
>
> Now can I volunteer you for a (hopefully) last set of gmbus patches?
> Afaics there are a few small things left to fix:
> - zero-length reads can blow up the kernel, like zero-length writes could.
> ?See: https://bugs.freedesktop.org/show_bug.cgi?id=48269

Got it.  Will Fix.

> - Chris Wilson suggested on irc that we should wait for HW_READY even for
> ?zero-length writes (and also reads), currently we don't.

I don't think so.  We just need to wait for (GMBUS_SATOER |
GMBUS_HW_WAIT_PHASE).
Why would we wait for HW_READY, too?

> - atm the debug output is too noisy. I think we can leave the fallback to
> ?gpio bitbanging at info (or maybe error) level, but all the other
> ?messages should be tuned down to DRM_DEBUG_KMS - these can easily be hit
> ?when userspace tries to probe the i2c with nothing connected or if the
> ?driver code tries to do the same. See:
> ?https://bugs.freedesktop.org/show_bug.cgi?id=48248

OK...  we can change the logging level.
However, the log in the bug to which you link seems to indicate a more
serious issue in this case.  It says to me that something on his
system is trying to talk to the disabled dpc i2c port 5 times every 10
seconds.  Each time it fails due with a time out, and each timeout
takes 50ms.  I would argue that the INFO message here is pointing out
that the hotplug code might want to check the corresponding
PORT_ENABLED bit before attempting a read over a particular DP/HDMI
gmbus port.  Perhaps I am mistaken, but if there was really nothing on
the bus, shouldn't that be a NAK, not a timeout?

>
> Chris, anything you want to add to the wishlist?
>
> Thanks, Daniel
> --
> Daniel Vetter
> Mail: daniel at ffwll.ch
> Mobile: +41 (0)79 365 57 48

[PATCH] drm/i915: clear fencing tracking state when retiring requests

[Daniel Vetter]

This fixes a regression uncovered by

commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
Author: Chris Wilson 
Date:   Wed Mar 21 10:48:18 2012 +

drm/i915: Mark untiled BLT commands as fenced on gen2/3

which fixed fencing tracking for untiled blt commands.

A side effect of that patch was that now also untiled objects have a
non-zero obj->last_fenced_seqno to track when a fence can be set up
after a pipelined tiling change. Unfortunately this was only cleared
by the fence setup and teardown code, resulting in tons of untiled but
inactive objects with non-zero last_fenced_seqno.

Now after resume we completely reset the seqno tracking, both on the
driver side (by setting dev_priv->next_seqno = 1) and on the hw side
(by allocating a new hws page, which contains the seqnos). Hilarity
and indefinite waits ensued from the stale seqnos in
obj->last_fenced_seqno from before the suspend.

The fix is to properly clear the fencing tracking state like we
already do for the normal gpu rendering while moving objects off the
active list.

Reported-and-tested-by: "Rafael J. Wysocki" 
Cc: Jiri Slaby 
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 71934dd..cf50fbc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1415,6 +1415,7 @@ i915_gem_object_move_off_active(struct 
drm_i915_gem_object *obj)
 {
list_del_init(>ring_list);
obj->last_rendering_seqno = 0;
+   obj->last_fenced_seqno = 0;
 }

 static void
@@ -1443,6 +1444,7 @@ i915_gem_object_move_to_inactive(struct 
drm_i915_gem_object *obj)
BUG_ON(!list_empty(>gpu_write_list));
BUG_ON(!obj->active);
obj->ring = NULL;
+   obj->last_fenced_ring = NULL;

i915_gem_object_move_off_active(obj);
obj->fenced_gpu_access = false;
-- 
1.7.9.1

[PATCH] drm/i915: clear fencing tracking state when retiring request

[Daniel Vetter]

This fixes a regression introduce in

commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
Author: Chris Wilson 
Date:   Wed Mar 21 10:48:18 2012 +

drm/i915: Mark untiled BLT commands as fenced on gen2/3

which fixed fencing tracking for untiled blt commands.

A side effect of that patch was that now also untiled objects have a
non-zero obj->last_fenced_seqno to track when a fence can be set up
after a pipelined tiling change. Unfortunately this was only cleared
by the fence setup and teardown code, resulting in tons of untiled but
inactive objects with non-zero last_fenced_seqno.

Now after resume we completely reset the seqno tracking, both on the
driver side (by setting dev_priv->next_seqno = 1) and on the hw side
(by allocating a new hws page, which contains the seqnos). Hilarity
and indefinite waits ensued from the stale seqnos in
obj->last_fenced_seqno from before the suspend.

The fix is to properly clear the fencing tracking state like we
already do for the normal gpu rendering while moving objects off the
active list.

Reported-and-tested-by: "Rafael J. Wysocki" 
Cc: Jiri Slaby 
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 71934dd..cf50fbc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1415,6 +1415,7 @@ i915_gem_object_move_off_active(struct 
drm_i915_gem_object *obj)
 {
list_del_init(>ring_list);
obj->last_rendering_seqno = 0;
+   obj->last_fenced_seqno = 0;
 }

 static void
@@ -1443,6 +1444,7 @@ i915_gem_object_move_to_inactive(struct 
drm_i915_gem_object *obj)
BUG_ON(!list_empty(>gpu_write_list));
BUG_ON(!obj->active);
obj->ring = NULL;
+   obj->last_fenced_ring = NULL;

i915_gem_object_move_off_active(obj);
obj->fenced_gpu_access = false;
-- 
1.7.9.1

[Intel-gfx] [PATCH] drm/i915: clear fencing tracking state when retiring request

[Chris Wilson]

On Thu, 12 Apr 2012 01:27:57 +0200, Daniel Vetter  
wrote:
> This fixes a regression introduce in
s/introduce/introduced/

> commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
> Author: Chris Wilson 
> Date:   Wed Mar 21 10:48:18 2012 +
> 
> drm/i915: Mark untiled BLT commands as fenced on gen2/3
> 
> which fixed fencing tracking for untiled blt commands.
> 
> A side effect of that patch was that now also untiled objects have a
> non-zero obj->last_fenced_seqno to track when a fence can be set up
> after a pipelined tiling change. Unfortunately this was only cleared
> by the fence setup and teardown code, resulting in tons of untiled but
> inactive objects with non-zero last_fenced_seqno.
> 
> Now after resume we completely reset the seqno tracking, both on the
> driver side (by setting dev_priv->next_seqno = 1) and on the hw side
> (by allocating a new hws page, which contains the seqnos). Hilarity
> and indefinite waits ensued from the stale seqnos in
> obj->last_fenced_seqno from before the suspend.
> 
> The fix is to properly clear the fencing tracking state like we
> already do for the normal gpu rendering while moving objects off the
> active list.
> 
> Reported-and-tested-by: "Rafael J. Wysocki" 
> Cc: Jiri Slaby 
> Signed-Off-by: Daniel Vetter 

I spent sometime discussing whether or not we could hit a similar bug
with a well placed change of tiling after resume, and the outcome is
that as the fences are reset during freeze then all tiled objects that
had been used for rendering would have been flushed (and their
last_fenced_seqno set to 0).

So this is a new regression caused by the aforementioned patch and this
is the cleanest fix,
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 28940] rv515 (Mobility x1400) Display corruption after some time

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

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

--- Comment #6 from Michel D?nzer  2012-04-12 00:20:12 
UTC ---
(In reply to comment #5)
> it's a very long time I'm wrestling with the very same issue with my mobility
> x1400.

I don't think it's the very same issue:


> Option "EXAPixmaps""off"

This is a very big hammer which basically prevents 2D acceleration from
occuring in most cases, so it doesn't narrow down your problem very much
unfortunately.

Moreover, the original report here mentioned 'The effect does not show in
screenshots', which means this option can't really work around it. So your
problem is probably not exactly the same and should be tracked elsewhere.


> Option "AccelDFS""off"
> Option "MigrationHeuristic""greedy"

These options don't have any effect with KMS.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

No subject

No subject

No subject

[PATCH] gma500: Don't needlessly include version.h in mdfld_dsi_output.h

[Jesper Juhl]

drivers/gpu/drm/gma500/mdfld_dsi_output.h does not need to
'#include ' - so don't.

Signed-off-by: Jesper Juhl 
---
 drivers/gpu/drm/gma500/mdfld_dsi_output.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.h 
b/drivers/gpu/drm/gma500/mdfld_dsi_output.h
index 21071ce..36eb074 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.h
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.h
@@ -29,7 +29,6 @@
 #define __MDFLD_DSI_OUTPUT_H__

 #include 
-#include 
 #include 
 #include 
 #include 
-- 
1.7.10


-- 
Jesper Juhlhttp://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

[PATCH] gma500: Don't needlessly include version.h in mdfld_dsi_output.h

[Alan Cox]

On Thu, 12 Apr 2012 00:05:29 +0200 (CEST)
Jesper Juhl  wrote:

> drivers/gpu/drm/gma500/mdfld_dsi_output.h does not need to
> '#include ' - so don't.
> 
> Signed-off-by: Jesper Juhl 

Acked-by: Alan Cox 

[Bug 48535] Spurious GL_INVALID_OPERATION error generated by glColor()

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

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

--- Comment #2 from Vadim  2012-04-11 16:08:59 PDT ---
I guess it's a mesa core problem. Debug build of the mesa also prints the
following error message when running the attached test app:

"Mesa: User error: GL_INVALID_OPERATION in Inside glBegin/glEnd"

It's printed from the ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL macro in the
_mesa_GetError(), called from gl-bug.c:6823. Though it's not inside Begin/End.

Probably the error reported later after the glColor call at the line 7353 is
just a consequence of the real bug somewhere in the display list handling.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: [PATCH] gma500: Don't needlessly include version.h in mdfld_dsi_output.h

[Kirill A. Shutemov]

On Thu, Apr 12, 2012 at 12:05:29AM +0200, Jesper Juhl wrote:
 drivers/gpu/drm/gma500/mdfld_dsi_output.h does not need to
 '#include linux/version.h' - so don't.
 
 Signed-off-by: Jesper Juhl j...@chaosbits.net

Acked-by: Kirill A. Shutemov kirill.shute...@linux.intel.com

-- 
 Kirill A. Shutemov


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

[git pull] updated exynos-drm-fixes

[Inki Dae]

Hi Dave,

Please pull from
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes

this branch is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git drm-fixes
commit-id: 62fb376e214d3c1bfdf6fbb77dac162f6da04d7e

this patch set includes page align and allocation bug fixes and
some code cleanup and also Joonyoung's patch set v2 like below.

v2: Split [PATCH 2/4] drm/exynos: remove unused codes in hdmi and mixer
   driver patch of patchset v1.

Please let me know if there is any problem.
Thanks.

Inki Dae (2):
  drm/exynos: fixed page align and code clean.
  drm/exynos: fixed duplicated page allocation bug.

Joonyoung Shim (6):
  drm/exynos: remove unnecessary type conversion of hdmi and mixer
  drm/exynos: remove unused codes in hdmi and mixer
  drm/exynos: rename s/HDMI_OVERLAY_NUMBER/MIXER_WIN_NR
  drm/exynos: use define instead of default_win member in struct
mixer_context
  drm/exynos: fix struct for operation callback functions to driver
name
  drm/exynos: fix to pointer manager member of struct exynos_drm_subdrv

Seung-Woo Kim (1):
  drm/exynos: add format list of plane

 drivers/gpu/drm/exynos/exynos_drm_buf.c   |   47 -
 drivers/gpu/drm/exynos/exynos_drm_core.c  |   14 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   10 ++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   20 +++--
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |   45 ++---
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |2 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |  107 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |   23 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.c |4 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   20 +++--
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   42 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c |   40 +--
 include/drm/exynos_drm.h  |3 +-
 13 files changed, 191 insertions(+), 186 deletions(-)

-- 
1.7.4.1

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

Re: [Intel-gfx] [PATCH] drm/i915: clear fencing tracking state when retiring request

[Daniel Vetter]

On Thu, Apr 12, 2012 at 12:38:09AM +0100, Chris Wilson wrote:
 On Thu, 12 Apr 2012 01:27:57 +0200, Daniel Vetter daniel.vet...@ffwll.ch 
 wrote:
  This fixes a regression introduce in
 s/introduce/introduced/
  
  commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
  Author: Chris Wilson ch...@chris-wilson.co.uk
  Date:   Wed Mar 21 10:48:18 2012 +
  
  drm/i915: Mark untiled BLT commands as fenced on gen2/3
  
  which fixed fencing tracking for untiled blt commands.
  
  A side effect of that patch was that now also untiled objects have a
  non-zero obj-last_fenced_seqno to track when a fence can be set up
  after a pipelined tiling change. Unfortunately this was only cleared
  by the fence setup and teardown code, resulting in tons of untiled but
  inactive objects with non-zero last_fenced_seqno.
  
  Now after resume we completely reset the seqno tracking, both on the
  driver side (by setting dev_priv-next_seqno = 1) and on the hw side
  (by allocating a new hws page, which contains the seqnos). Hilarity
  and indefinite waits ensued from the stale seqnos in
  obj-last_fenced_seqno from before the suspend.
  
  The fix is to properly clear the fencing tracking state like we
  already do for the normal gpu rendering while moving objects off the
  active list.
  
  Reported-and-tested-by: Rafael J. Wysocki r...@sisk.pl
  Cc: Jiri Slaby jsl...@suse.cz
  Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
 I spent sometime discussing whether or not we could hit a similar bug
 with a well placed change of tiling after resume, and the outcome is
 that as the fences are reset during freeze then all tiled objects that
 had been used for rendering would have been flushed (and their
 last_fenced_seqno set to 0).
 
 So this is a new regression caused by the aforementioned patch and this
 is the cleanest fix,
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Picked up for -fixes, thanks for the review.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] exynos: add exynos drm support

[InKi Dae]

Please, give me any comments and I hope this patch would be applied to
libdrm if there is any problem.

Thanks,
Inki Dae.


2012년 4월 2일 오후 9:08, Inki Dae inki@samsung.com님의 말:
 this patch adds libdrm_exynos helper layer that inclues some intefaces
 for exynos specific gem and virtual display driver and also adds exynos
 module name to modtest and vbltest.

 this patch is based on a link below:
git://anongit.freedesktop.org/mesa/drm
commit id: e057a56448e2e785f74bc13dbd6ead8572ebed91

 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  Makefile.am|6 +-
  configure.ac   |   13 ++
  exynos/Makefile.am |   22 +++
  exynos/exynos_drm.c|  324 
 
  exynos/exynos_drm.h|  127 +
  exynos/exynos_drmif.h  |   60 
  exynos/libdrm_exynos.pc.in |   11 ++
  tests/modetest/modetest.c  |2 +-
  tests/vbltest/vbltest.c|2 +-
  9 files changed, 564 insertions(+), 3 deletions(-)
  create mode 100644 exynos/Makefile.am
  create mode 100644 exynos/exynos_drm.c
  create mode 100644 exynos/exynos_drm.h
  create mode 100644 exynos/exynos_drmif.h
  create mode 100644 exynos/libdrm_exynos.pc.in

 diff --git a/Makefile.am b/Makefile.am
 index 4f625a1..256a8cc 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -45,7 +45,11 @@ if HAVE_OMAP
  OMAP_SUBDIR = omap
  endif

 -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
 $(RADEON_SUBDIR) $(OMAP_SUBDIR) tests include
 +if HAVE_EXYNOS
 +EXYNOS_SUBDIR = exynos
 +endif
 +
 +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
 $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) tests include

  libdrm_la_LTLIBRARIES = libdrm.la
  libdrm_ladir = $(libdir)
 diff --git a/configure.ac b/configure.ac
 index 1ba7eba..ae84817 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -88,6 +88,11 @@ AC_ARG_ENABLE(omap-experimental-api,
  [Enable support for OMAP's experimental API (default: 
 disabled)]),
  [OMAP=$enableval], [OMAP=no])

 +AC_ARG_ENABLE(exynos-experimental-api,
 + AS_HELP_STRING([--enable-exynos-experimental-api],
 + [Enable support for EXYNOS's experimental API (default: 
 disabled)]),
 + [EXYNOS=$enableval], [EXYNOS=no])
 +
  dnl 
 ===
  dnl check compiler flags
  AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
 @@ -191,6 +196,11 @@ if test x$OMAP = xyes; then
AC_DEFINE(HAVE_OMAP, 1, [Have OMAP support])
  fi

 +AM_CONDITIONAL(HAVE_EXYNOS, [test x$EXYNOS = xyes])
 +if test x$EXYNOS = xyes; then
 +   AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support])
 +fi
 +
  PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
  if test x$HAVE_CAIRO = xyes; then
AC_DEFINE(HAVE_CAIRO, 1, [Have cairo support])
 @@ -302,6 +312,8 @@ AC_CONFIG_FILES([
nouveau/libdrm_nouveau.pc
omap/Makefile
omap/libdrm_omap.pc
 +   exynos/Makefile
 +   exynos/libdrm_exynos.pc
tests/Makefile
tests/modeprint/Makefile
tests/modetest/Makefile
 @@ -322,4 +334,5 @@ echo   vmwgfx API $VMWGFX
  echo   Radeon API $RADEON
  echo   Nouveau API$NOUVEAU
  echo   OMAP API   $OMAP
 +echo   EXYNOS API $EXYNOS
  echo 
 diff --git a/exynos/Makefile.am b/exynos/Makefile.am
 new file mode 100644
 index 000..e782d34
 --- /dev/null
 +++ b/exynos/Makefile.am
 @@ -0,0 +1,22 @@
 +AM_CFLAGS = \
 +   $(WARN_CFLAGS) \
 +   -I$(top_srcdir) \
 +   -I$(top_srcdir)/exynos \
 +   $(PTHREADSTUBS_CFLAGS) \
 +   -I$(top_srcdir)/include/drm
 +
 +libdrm_exynos_la_LTLIBRARIES = libdrm_exynos.la
 +libdrm_exynos_ladir = $(libdir)
 +libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
 +libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
 +
 +libdrm_exynos_la_SOURCES = exynos_drm.c
 +
 +libdrm_exynoscommonincludedir = ${includedir}/exynos
 +libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
 +
 +libdrm_exynosincludedir = ${includedir}/libdrm
 +libdrm_exynosinclude_HEADERS = exynos_drmif.h
 +
 +pkgconfigdir = @pkgconfigdir@
 +pkgconfig_DATA = libdrm_exynos.pc
 diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
 new file mode 100644
 index 000..778321a
 --- /dev/null
 +++ b/exynos/exynos_drm.c
 @@ -0,0 +1,324 @@
 +/*
 + * Copyright (C) 2012 Samsung Electronics Co., Ltd.
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining a
 + * copy of this software and associated documentation files (the Software),
 + * to deal in the Software without restriction, including without limitation
 + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
 + * and/or sell copies of the Software, and to permit persons to whom the
 + * Software is furnished to do so, subject to the following conditions:
 + *
 + * The above copyright notice and 

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

[Thierry Reding]

* Arnd Bergmann wrote:
 On Wednesday 11 April 2012, Thierry Reding wrote:
  Daniel Vetter wrote:
   Well, you use the iommu api to map/unmap memory into the iommu for tegra,
   whereas usually device drivers just use the dma api to do that. The usual
   interface is dma_map_sg/dma_unmap_sg, but there are quite a few variants
   around. I'm just wondering why this you've choosen this.
  
  I don't think this works on ARM. Maybe I'm not seeing the whole picture but
  judging by a quick look through the kernel tree there aren't any users that
  map DMA memory through an IOMMU.
 
 dma_map_sg is certainly the right interface to use, and Marek Szyprowski has
 patches to make that work on ARM, hopefully going into v3.5, so you could
 use those.

I've looked at Marek's patches but I don't think they'll work for Tegra 2 or
Tegra 3. The corresponding iommu_map() functions only set one PTE, regardless
of the number of bytes passed to them. However, the Tegra TRM indicates that
mapping needs to be done on a per-page basis so contiguous regions cannot be
combined. I suppose the IOMMU driver would have to be fixed to program more
than a single page in that case.

Also this doesn't yet solve the vmap() problem that is needed for the kernel
virtual mapping. I did try using dma_alloc_writecombine(), but that only
works for chunks of 2 MB or smaller, unless I use init_consistent_dma_size()
during board setup, which isn't provided for in a DT setup. I couldn't find
a better alternative, but I admit I'm not very familiar with all the VM APIs.
Do you have any suggestions on how to solve this? Otherwise I'll try and dig
in some more.

Thierry


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

[Bug 28940] rv515 (Mobility x1400) Display corruption after some time

[bugzilla-daemon]

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

--- Comment #6 from Michel Dänzer mic...@daenzer.net 2012-04-12 00:20:12 UTC 
---
(In reply to comment #5)
 it's a very long time I'm wrestling with the very same issue with my mobility
 x1400.

I don't think it's the very same issue:


 Option EXAPixmapsoff

This is a very big hammer which basically prevents 2D acceleration from
occuring in most cases, so it doesn't narrow down your problem very much
unfortunately.

Moreover, the original report here mentioned 'The effect does not show in
screenshots', which means this option can't really work around it. So your
problem is probably not exactly the same and should be tracked elsewhere.


 Option AccelDFSoff
 Option MigrationHeuristicgreedy

These options don't have any effect with KMS.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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

exynos broken ioctl

[Dave Airlie]

please before submitting ioctl's can someone review them to make sure
they have no pointers in them ever.

struct drm_exynos_vidi_connection {
unsigned int connection;
unsigned int extensions;
uint64_t *edid;
};

gets passed into DRM_EXYNOS_VIDI_CONNECTION ioctl.

Can you remove the point, it should be just a uint64_t most likely.

I don't think this has been in a released kernel so should be okay to fix.

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

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

[Thierry Reding]

* Stephen Warren wrote:
 On 04/11/2012 06:10 AM, Thierry Reding wrote:
  This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
  currently has rudimentary GEM support and can run a console on the
  framebuffer as well as X using the xf86-video-modesetting driver.
  Only the RGB output is supported. Quite a lot of things still need
  to be worked out and there is a lot of room for cleanup.
 
 I'll let Jon Mayo comment on the actual driver implementation, since
 he's a lot more familiar with Tegra's display hardware. However, I have
 some general comments below.
 
   .../devicetree/bindings/gpu/drm/tegra.txt  |   24 +
   arch/arm/mach-tegra/board-dt-tegra20.c |3 +
   arch/arm/mach-tegra/tegra2_clocks.c|8 +-
   drivers/gpu/drm/Kconfig|2 +
   drivers/gpu/drm/Makefile   |1 +
   drivers/gpu/drm/tegra/Kconfig  |   10 +
   drivers/gpu/drm/tegra/Makefile |5 +
   drivers/gpu/drm/tegra/tegra_drv.c  | 2241 
  
   drivers/gpu/drm/tegra/tegra_drv.h  |  184 ++
   include/drm/tegra_drm.h|   44 +
 
 Splitting this patch into two, between arch/arm and drivers/gpu would be
 a good idea.

I can certainly do that.

  diff --git a/Documentation/devicetree/bindings/gpu/drm/tegra.txt 
  b/Documentation/devicetree/bindings/gpu/drm/tegra.txt
 
  +   drm@5420 {
  +   compatible = nvidia,tegra20-drm;
 
 This doesn't seem right; there isn't a DRM hardware module on Tegra,
 since DRM is a Linux/software-specific term.
 
 I'd at least expect to see this compatible flag be renamed to something
 more like nvidia,tegra20-dc (dc==display controller).
 
 Since Tegra has two display controller modules (I believe identical?),
 and numerous other independent(?) blocks, I'd expect to see multiple
 nodes in device tree, one per hardware block, such that each block gets
 its own device and driver. That said, I'm not familiar enough with
 Tegra's display and graphics HW to know if this makes sense. Jon, what's
 your take here? The clock change below, and in particular the original
 code there that we use downstream, lends weight to my argument.
 
  +   reg =  0x5420 0x0004/* display A */
  +   0x5424 0x0004/* display B */
  +   0x5800 0x0200 ; /* GART aperture */
  +   interrupts =  0 73 0x04/* display A */
  +  0 74 0x04 ; /* display B */
  +
  +   lvds {
  +   type = rgb;
 
 These sub-nodes probably want a compatible property rather than a
 type property.

compatible suggests that a driver would bind to it. However the data really
is only passed to the DC driver for configuration.

  +   size = 345 194;
  +
  +   default-mode {
  +   pixel-clock = 61715000;
  +   vertical-refresh = 50;
  +   resolution = 1366 768;
  +   bits-per-pixel = 16;
  +   horizontal-timings = 4 136 2 36;
  +   vertical-timings = 2 4 21 10;
  +   };
  +   };
 
 I imagine that quite a bit of thought needs to be put into the output
 part of the binding in order to:
 
 * Model the outputs/connectors separately from display controllers.
 * Make sure that the basic infra-structure for representing an output is
 general enough to be extensible to all the kinds of outputs we support,
 not just the LVDS output.

I haven't played around with HDMI at all yet, so I don't know of the
requirements. I'm pretty sure the above isn't anywhere near complete
though.

 * We were wondering about putting an EDID into the DT to represent the
 display modes, so that all outputs had EDIDs rather than real monitors
 having EDIDs, and fixed internal displays having some other
 representation of capabilities.

That's an interesting approach. I like it.

 I'm hoping that Jon will drive this.
 
  diff --git a/arch/arm/mach-tegra/tegra2_clocks.c 
  b/arch/arm/mach-tegra/tegra2_clocks.c
 
  -   PERIPH_CLK(disp1, tegradc.0,NULL,   27, 0x138,  
  6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and 
  process_id */
  -   PERIPH_CLK(disp2, tegradc.1,NULL,   26, 0x13c,  
  6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and 
  process_id */
  +   PERIPH_CLK(disp1, tegra-drm,NULL,   27, 0x138,  
  6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and 
  process_id */
  +   PERIPH_CLK(disp2, tegra-drm,NULL,   26, 0x13c,  
  6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and 
  process_id */
 
 This doesn't seem right, and couples back to my assertion above that the
 two 

Re: [RFC 3/4] drm: fixed: Add dfixed_frac() macro

[Thierry Reding]

* Stephen Warren wrote:
 On 04/11/2012 06:10 AM, Thierry Reding wrote:
  This commit is taken from the Chromium tree and was originally written
  by Robert Morell.
 
 Maybe just cherry-pick it from there? That way, the git authorship will
 show up as Robert.

I can do that. Though I'll have to remove the Chromium-specific tags.

Thierry


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