date:20110915

On Thu, 2011-09-15 at 19:55 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen  
> wrote:
> 
> > 2) panel drivers, handles panel specific things. Each panel may support
> > custom commands and features, for which we need a dedicated driver. And
> > this driver is not platform specific, but should work with any platform
> > which has the output used with the panel.
> 
> Right, we've got DDC ports (which are just i2c) and DisplayPort aux
> channel stuff.
> 
> The DDC stuff is abstracted out and shared across the drivers, but the
> DisplayPort aux channel code is not -- it's duplicated in every output
> driver. 

I feel that you are still talking about the output driver, not the
panel. DDC and DP aux are part of the connector-entity in DRM, right?
But there's no separate display-entity behind the connector, which would
handle the peculiarities for a particular panel/display, say DSI panel
model L33T from AcmeCorp.

So, as I see it, DDC and DP aux are on the output driver, and the panel
driver uses those to do whatever is needed for a particular panel.

> > DSI bus is a half-duplex serial bus, and while it's designed for
> > displays you could use it easily for any communication between the SoC
> > and the peripheral.
> 
> Yeah, HDMI uses DDC for all kinds of crazy stuff in the CE world.

But that is still more or less standard HDMI stuff, isn't it? So you
implement it once for HDMI, and then it works with all HDMI monitors?

Or is there some way to implement custom behavior for one particular
HDMI monitor? Is this custom behavior in a kernel driver or handled in
userspace?

> > The point is that we cannot have standard "MIPI DSI command mode panel
> > driver" which would work for all DSI cmd mode panels, but we need (in
> > the worst case) separate driver for each panel.
> 
> It sounds like we do want to share code for those bits, much like we
> have DDC split out now. And, we should do something about the
> DisplayPort aux channel stuff to avoid duplicating it everywhere.

Yep. What I had in mind for DSI with my low-level fmwk would be a
mipi_dsi component that offers services to use the DSI bus. Each
platform which supports DSI would implement the DSI support for their
HW. Then the DSI panel driver could do things like:

dsi->write(dev, virtual_channel_id, buf, len);

dsi->set_max_return_packet_size(dev, 10);
dsi->read(dev, virtual_channel_id, read_cmd, recv_buf, len);

An example DSI command mode panel driver can be found from
drivers/video/omap2/displays/panel-taal.c, which uses omapdss' dsi
functions directly but could quite easily use a common DSI interface and
thus be platform independent.

> I'm not sure a common interface to all of these different
> channels makes sense, but surely a DSI library and an aux channel
> library would fit nicely alongside the existing DDC library.

What do you mean with "channel"? Any video or command bus going to the
display? Yes, I think they are quite different and I don't see a point
in trying to make a common interface for them. 

DSI is in many ways a real bus. You can connect multiple peripherals to
one DSI bus (but it needs a DSI hub), and communicate with them by using
their virtual channel ID. And quite often there are DSI chips that
transform the DSI packets to some other form. Some real example
configurations:

Plain DSI panel:

[SoC] ---DSI--- [DSI panel]

DSI-2-DisplayPort converter chip:

[SoC] ---DSI--- [DSI chip] ---DP--- [DP monitor]

DSI buffer chip supporting to DSI panels:

[SoC] ---DSI--- [DSI chip] +--DSI--- [DSI panel 1]
   |--DSI--- [DSI panel 2]

It would be nice to be able to model this somehow neatly with device
drivers. For example, the DSI panel from the first example could be used
in the two-panel configuration, and if (and when) the panel requires
custom configuration, the same panel driver could be used in both cases.
In the first case the panel driver would use DSI support from the Soc,
in the third case the panel driver would use the DSI support from the
DSI chip (which would, in turn, use DSI support from the SoC).

 Tomi

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

Proposal for a low-level Linux display framework

> Okay, I see your problem. It's a bit strange you don't have acceleration. I

The hardware has 3D acceleration but not open so we can't support it.
There is no 2D acceleration - which seems to be increasingly common.

At some point I'll add hardware scrolling however by using the GTT to
implemnent scroll wrapping.

> sound like a big problem to me, but pretty inefficient, so probably copying 
> the
> existing ones and adjusting it to your needs would be preferred (just like the
> sys* implementations exist).

I did have a look at the current ones but fixing them up given scan lines
can span page boundaries looked pretty horrible so I deferred it until I
feel inspired.

Alan

Re: Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 18:39:21 +, Florian Tobias Schandinat 
 wrote:

> Well, I'm not against sharing the code and not against taking DRM's current
> implementation as a base but the steps required to make it generally 
> acceptable
> would be to split it of, probably as a standalone module and strip all DRM
> specific things off. Than all things that require EDID can use it, DRM can add
> DRM-specific things on top and fb can add fb-specific things.

The rendering portions of the DRM drivers are all device-specific. The
core DRM ioctls are largely about providing some sharing control over
the device, mapping memory around and mode setting.

> One of my biggest problems with KMS is that it has (naturally) a lot more
> complexity than the fb API which leads to instability.

The mode setting portions are of necessity the same. The KMS API exposes
more functionality for mode setting, but doesn't actually require any
additional hardware-specific knowledge. You still have to be able to
bring the hardware up from power on and light up every connected
monitor.

However, if you want acceleration, you're going to run into bugs that
crash the machine. It's a sad reality that graphics hardware just isn't
able to recover cleanly in all cases from programmer errors, and that
includes errors that come from user mode.

Hardware is improving in this area, and reset is getting more reliable
than it used to be. But, until we can context switch the graphics
hardware at arbitrary points during execution, we're kinda stuck with
using the really big reset hammer when programs go awry.

-- 
keith.pack...@intel.com

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

Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 18:39:21 +, Florian Tobias Schandinat 
 wrote:

> Well, I'm not against sharing the code and not against taking DRM's current
> implementation as a base but the steps required to make it generally 
> acceptable
> would be to split it of, probably as a standalone module and strip all DRM
> specific things off. Than all things that require EDID can use it, DRM can add
> DRM-specific things on top and fb can add fb-specific things.

The rendering portions of the DRM drivers are all device-specific. The
core DRM ioctls are largely about providing some sharing control over
the device, mapping memory around and mode setting.

> One of my biggest problems with KMS is that it has (naturally) a lot more
> complexity than the fb API which leads to instability.

The mode setting portions are of necessity the same. The KMS API exposes
more functionality for mode setting, but doesn't actually require any
additional hardware-specific knowledge. You still have to be able to
bring the hardware up from power on and light up every connected
monitor.

However, if you want acceleration, you're going to run into bugs that
crash the machine. It's a sad reality that graphics hardware just isn't
able to recover cleanly in all cases from programmer errors, and that
includes errors that come from user mode.

Hardware is improving in this area, and reset is getting more reliable
than it used to be. But, until we can context switch the graphics
hardware at arbitrary points during execution, we're kinda stuck with
using the really big reset hammer when programs go awry.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/c776a516/attachment.pgp>

[PATCH] io-mapping: ensure io_mapping_map_atomic _is_ atomic

2011-09-15 Thread Daniel Vetter

For the !HAVE_ATOMIC_IOMAP case the stub functions did not call
pagefault_disable/_enable. The i915 driver relies on the map
actually being atomic, otherwise it can deadlock with it's own
pagefault handler in the gtt pwrite fastpath.

This is exercised by gem_mmap_gtt from the intel-gpu-toosl gem
testsuite.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38115
Cc: stable at kernel.org
Signed-off-by: Daniel Vetter 
---
 include/linux/io-mapping.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index 8cdcc2a1..6b3bef1 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -138,12 +138,14 @@ static inline void __iomem *
 io_mapping_map_atomic_wc(struct io_mapping *mapping,
 unsigned long offset)
 {
+   pagefault_disable();
return ((char __force __iomem *) mapping) + offset;
 }

 static inline void
 io_mapping_unmap_atomic(void __iomem *vaddr)
 {
+   pagefault_enable();
 }

 /* Non-atomic map/unmap */
-- 
1.7.6

Re: Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen  
wrote:

> 2) panel drivers, handles panel specific things. Each panel may support
> custom commands and features, for which we need a dedicated driver. And
> this driver is not platform specific, but should work with any platform
> which has the output used with the panel.

Right, we've got DDC ports (which are just i2c) and DisplayPort aux
channel stuff.

The DDC stuff is abstracted out and shared across the drivers, but the
DisplayPort aux channel code is not -- it's duplicated in every output
driver. 

> DSI bus is a half-duplex serial bus, and while it's designed for
> displays you could use it easily for any communication between the SoC
> and the peripheral.

Yeah, HDMI uses DDC for all kinds of crazy stuff in the CE world.

> The point is that we cannot have standard "MIPI DSI command mode panel
> driver" which would work for all DSI cmd mode panels, but we need (in
> the worst case) separate driver for each panel.

It sounds like we do want to share code for those bits, much like we
have DDC split out now. And, we should do something about the
DisplayPort aux channel stuff to avoid duplicating it everywhere.

I'm not sure a common interface to all of these different
channels makes sense, but surely a DSI library and an aux channel
library would fit nicely alongside the existing DDC library.

I suspect helper functions would be a good model to follow, rather than
trying to create a whole new device infrastructure; some of the
communication paths aren't easily separable from the underlying output
devices.

Oh, I think you're also trying to get at how we expose some of these
controls outside of the display driver -- right now, they're mostly
exposed as properties on the output device. Things like backlight
brightness, a million analog TV output values, dithering control and
other more esoteric controls.

DRM properties include booleans, enumerations, integer ranges and chunks
of binary data. Some are read-only (like EDID data), some are writable
(like overscan values).

-- 
keith.pack...@intel.com

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

Whitespace cleanups in drm/i915


I've got this nice patch from Akshay Joshi that removes almost all of
the checkpatch.pl warnings from drm/i915. If I don't merge it now, it's
going to go stale and be useless; if I merge it only to drm-intel-next,
it will be the source of endless conflicts.

However, it's a huge patch (yes, the code was rather sloppy), and
doesn't exactly fit into the "critical patches only please" mode of the
current stage of 3.1 development.

I've checked the patch very carefully, using the obvious git diff -b to
make sure it really doesn't touch anything but whitespace, but also
using objdump -s to compare the output of the compiler. There were no
differences found with git-diff -b. The only differences found by
objdump are two whitespace changes in some debug output messages in
intel_bios.c.

I think I have three choices:

 1) merge the patch and expect complaints from upstream

 2) thank Akshay for his good intentions, discard the patch and hope
that he feels motivated enough to do it all over again in time for
the 3.2 merge window.

 3) thank Akshay for his good intentions and leave the code as-is,
forever to ease back-porting of fixes to older kernel versions.

Frankly, if we're ever going to merge whitespace fixups, this would be a
pretty darn good time; drm-intel-fixes and drm-intel-next are in-sync as
I haven't started pulling 3.2 code into -next.

-- 
keith.pack...@intel.com


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

Proposal for a low-level Linux display framework

> As you have DRM now and as I'm not interested in wayland I won't discuss this,
> but I guess it might be a good start for Geert's question what would be needed
> to use it on dumb framebuffers.

GMA500 is basically a 2D or dumb frame buffer setup but with a lot of
rather complicated output and memory management required due to the
hardware. With the latest changes to GEM (private objects) it's basically
trivial to use the frame buffer management interfaces.

> Yes, if you limit DRM to the functionality of the fb API I guess you could 
> reach
> the same stability level. But where can I do this? Where is a option to forbid
> all acceleration or at least limit to the acceleration that can be done 
> without
> any risk?

A driver can provide such module options as it wants.

> That's a really difficult question. Determining the users is difficult and 
> there
> are people that use their hardware very long, for example we are about to get 
> a
> new driver for i740. For the framebuffer infrastructure I guess you have to at
> least wait for my death.

I doubt it'll be that long - but you are right it will take time and
there isn't really any need to push or force it. These things take care
of themselves and in time nobody will care about the old fb stuff, either
because DRM covers it all or equally possibly because it doesn't support
3D holographic projection 8)

Alan

Proposal for a low-level Linux display framework

On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen  
> wrote:
> 
> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > the plan is to make DRM the core Linux display framework, upon which
> > everything else is built, and fb and v4l2 are changed to use DRM.
> 
> I'd like to think we could make DRM the underlying display framework;
> it already exposes an fb interface, and with overlays, a bit more of the
> v4l2 stuff is done as well. Certainly eliminating three copies of mode
> setting infrastructure would be nice...

Ok, sounds good to me. We (as in OMAP display people) are already
planning to take DRM into use, so no problem there.

> > But even if it was done like that, I see that it's combining two
> > separate things: 1) the lower level HW control, and 2) the upper level
> > buffer management, policies and userspace interfaces.
> 
> Those are split between the DRM layer and the underlying device driver,
> which provides both kernel (via fb) and user space interfaces.

I'm not so familiar with DRM, but with device driver you mean a driver
for the the hardware which handles display output (gfx cards or whatever
it is on that platform)?

If so, it sounds good. That quite well matches what omapdss driver does
currently for us. But we still have semi-complex omapdrm between omapdss
and the standard drm layer.

Rob, would you say omapdrm is more of a DRM wrapper for omapdss than a
real separate entity? If so, then we could possibly in the future (when
nobody else uses omapdss) change omapdss to support DRM natively. (or
make omapdrm support omap HW natively, which ever way =).

> > 2) It's missing the panel driver part. This is rather important on
> > embedded systems, as the panels often are not "dummy" panels, but they
> > need things like custom initialization, sending commands to adjust
> > backlight, etc.
> 
> We integrate the panel (and other video output) drivers into the device
> drivers. With desktop chips, they're not easily separable. None of the
> desktop output drivers are simple; things like DisplayPort require link
> training, and everyone needs EDID. We share some of that code in the DRM
> layer today, and it would be nice to share even more.

I don't think we speak of similar panel drivers. I think there are two
different drivers here:

1) output drivers, handles the output from the SoC / gfx card. For
example DVI, DisplayPort, MIPI DPI/DBI/DSI.

2) panel drivers, handles panel specific things. Each panel may support
custom commands and features, for which we need a dedicated driver. And
this driver is not platform specific, but should work with any platform
which has the output used with the panel.

As an example, DSI command mode displays can be quite complex:

DSI bus is a half-duplex serial bus, and while it's designed for
displays you could use it easily for any communication between the SoC
and the peripheral.

The panel could have a feature like content adaptive backlight control,
and this would be configured via the DSI bus, sending a particular
command to the panel (possibly by first reading something from the
panel). The panel driver would accomplish this more or less the same way
one uses, say, i2c, so it would use the platform's DSI support to send
and receive packets.

Or a more complex scenario (but still a realistic scenario, been there,
done that) is sending the image to the panel in multiple parts, and
between each part sending configuration commands to the panel. (and
still getting it done in time so we avoid tearing).

And to complicate things more, there are DSI bus features like LP mode
(low power, basically low speed mode) and HS mode (high speed), virtual
channel IDs, and whatnot, which each panel may need to be used in
particular manner. Some panels may require initial configuration done in
LP, or configuration commands sent to a certain virtual channel ID.

The point is that we cannot have standard "MIPI DSI command mode panel
driver" which would work for all DSI cmd mode panels, but we need (in
the worst case) separate driver for each panel.

The same goes to lesser extent for other panels also. Some are
configured via i2c or spi.

 Tomi

[PATCH 2/2] drm/radeon: Hold the CS mutex across suspend/resume.

From: Michel D?nzer 


Signed-off-by: Michel D?nzer 
---

Not sure the CS ioctl can actually run concurrently with suspend/resume, but
might be better safe than sorry?

 drivers/gpu/drm/radeon/radeon_device.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 5f3d02d..80b4799 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -881,6 +881,10 @@ int radeon_suspend_kms(struct drm_device *dev, 
pm_message_t state)
}
}
}
+
+   /* Prevent CS ioctl from interfering */
+   cs_mutex_lock(rdev);
+
/* evict vram memory */
radeon_bo_evict_vram(rdev);
/* wait for gpu to finish processing current batch */
@@ -944,6 +948,9 @@ int radeon_resume_kms(struct drm_device *dev)
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
}
+
+   cs_mutex_unlock(rdev);
+
return 0;
 }

-- 
1.7.6.3

[PATCH 1/2] drm/radeon: Make sure CS mutex is held across GPU reset.

From: Michel D?nzer 

This was only the case if the GPU reset was triggered from the CS ioctl,
otherwise other processes could happily enter the CS ioctl and wreak havoc
during the GPU reset.

This is a little complicated because the GPU reset can be triggered from the
CS ioctl, in which case we're already holding the mutex, or from other call
paths, in which case we need to lock the mutex. AFAICT the mutex API doesn't
allow nested locking or finding out the mutex owner, so we need to handle this
with some helper functions.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon.h|   60 
 drivers/gpu/drm/radeon/radeon_cs.c |   14 
 drivers/gpu/drm/radeon/radeon_device.c |   16 
 3 files changed, 83 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ef0e0e0..89304d9 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1203,6 +1203,8 @@ struct radeon_device {
struct radeon_pmpm;
uint32_tbios_scratch[RADEON_BIOS_NUM_SCRATCH];
struct mutexcs_mutex;
+   struct task_struct  *cs_mutex_owner;
+   struct mutexcs_mutex_owner_mutex;
struct radeon_wbwb;
struct radeon_dummy_pagedummy_page;
boolgpu_lockup;
@@ -1241,6 +1243,64 @@ struct radeon_device {
struct radeon_i2c_chan *i2c_bus[RADEON_MAX_I2C_BUS];
 };

+
+/*
+ * CS mutex helpers
+ */
+
+static inline void cs_mutex_lock(struct radeon_device *rdev)
+{
+   mutex_lock(&rdev->cs_mutex);
+
+   mutex_lock(&rdev->cs_mutex_owner_mutex);
+   rdev->cs_mutex_owner = current;
+   mutex_unlock(&rdev->cs_mutex_owner_mutex);
+}
+
+static inline void cs_mutex_unlock(struct radeon_device *rdev)
+{
+   mutex_lock(&rdev->cs_mutex_owner_mutex);
+   rdev->cs_mutex_owner = NULL;
+   mutex_unlock(&rdev->cs_mutex_owner_mutex);
+
+   mutex_unlock(&rdev->cs_mutex);
+}
+
+/*
+ * Check if this process locked the CS mutex already; if it didn't, lock it.
+ *
+ * Returns:
+ * true: This function locked the mutex.
+ * false: This function didn't lock the mutex (this process already locked it
+ * before), so the caller probably shouldn't unlock it.
+ */
+static inline int cs_mutex_ensure_locked(struct radeon_device *rdev)
+{
+   int took_mutex;
+   int have_mutex;
+
+   mutex_lock(&rdev->cs_mutex_owner_mutex);
+   took_mutex = mutex_trylock(&rdev->cs_mutex);
+   if (took_mutex) {
+   /* The mutex was unlocked before, so it's ours now */
+   rdev->cs_mutex_owner = current;
+   have_mutex = true;
+   } else {
+   /* Somebody already locked the mutex. Was it this process? */
+   have_mutex = (rdev->cs_mutex_owner == current);
+   }
+   mutex_unlock(&rdev->cs_mutex_owner_mutex);
+
+   if (!have_mutex) {
+   /* Another process locked the mutex, take it */
+   cs_mutex_lock(rdev);
+   took_mutex = true;
+   }
+
+   return took_mutex;
+}
+
+
 int radeon_device_init(struct radeon_device *rdev,
   struct drm_device *ddev,
   struct pci_dev *pdev,
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index fae00c0..61e3063 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -222,7 +222,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
struct radeon_cs_chunk *ib_chunk;
int r;

-   mutex_lock(&rdev->cs_mutex);
+   cs_mutex_lock(rdev);
/* initialize parser */
memset(&parser, 0, sizeof(struct radeon_cs_parser));
parser.filp = filp;
@@ -233,14 +233,14 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
if (r) {
DRM_ERROR("Failed to initialize parser !\n");
radeon_cs_parser_fini(&parser, r);
-   mutex_unlock(&rdev->cs_mutex);
+   cs_mutex_unlock(rdev);
return r;
}
r =  radeon_ib_get(rdev, &parser.ib);
if (r) {
DRM_ERROR("Failed to get ib !\n");
radeon_cs_parser_fini(&parser, r);
-   mutex_unlock(&rdev->cs_mutex);
+   cs_mutex_unlock(rdev);
return r;
}
r = radeon_cs_parser_relocs(&parser);
@@ -248,7 +248,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
if (r != -ERESTARTSYS)
DRM_ERROR("Failed to parse relocation %d!\n", r);
radeon_cs_parser_fini(&parser, r);
-   mutex_unlock(&rdev->cs_mutex);
+   cs_mutex_unlock(rdev);
return r;

Proposal for a low-level Linux display framework

> What is your problem with discontigous framebuffers? (I assume discontigous
> refers to the pages the framebuffer is composed of)
> Sounds to me like you should implement your own fb_mmap and either map it
> contigous to screen_base or implement your own fb_read/write.
> In theory you could even have each pixel at a completely different memory
> location although some userspace wouldn't be happy when it could no longer 
> mmap
> the framebuffer.

The mmap side is trivial, the problem is that the fb layer default
implementations of blits, fills etc only work on a kernel linear frame
buffer. And (for example) there is not enough linear stolen memory on
some Intel video for a 1080p console on HDMI even though the hardware is
perfectly capable of using an HDTV as its monitor. Nor - on a 32bit box-
is there enough space to vremap it.

Alan

Proposal for a low-level Linux display framework

> Well, I rather think that the fb API is more user centric to allow every 
> program
> to use it directly in contrast to the KMS/DRM API which aims to support every
> feature the hardware has. For this the fb API should not change much, but I
> understand some additions were needed for some special users, probably limited
> to X and wayland.

Wayland needs vblank frame buffer switching and the like. Likewise given
you want to composite buffers really any serious accelerated device ends
up needing a full memory manager and that ends up needing a buffer
manager. Wayland needs clients to be doing their own rendering into
objects which means authorisation and management of the render engine
which ends up looking much like DRM.

> One of my biggest problems with KMS is that it has (naturally) a lot more
> complexity than the fb API which leads to instability. Basically it's very

It shouldn't do - and a sample of one (your machine) is not a
statistically valid set. Fb is pretty much ununsable in contrast on my
main box, but that's not a statistically valid sample either.

I'm not that convinced by the complexity either. For a simple video card
setup such as those that the fb layer can kind of cope with (ie linear
buffer, simple mode changes, no client rendering, no vblank flipping,
limited mode management, no serious multi-head) a DRM driver is also
pretty tiny and simple.

> Well, I think it's too late to really fix this thing. We now have 3 APIs in 
> the
> kernel that have to be kept. Probably the best we can do now is figure out how
> we can reduce code duplication and do extensions to those APIs in a way that
> they are compatible with each other or completely independent and can be used
> across the APIs.

I think it comes down to 'when nobody is using the old fb drivers they can
drop into staging and oblivion'. Right now the fb layer is essentially
compatibility glue on most modern x86 platforms.

Alan

Proposal for a low-level Linux display framework

2011-09-15 Thread Geert Uytterhoeven

On Thu, Sep 15, 2011 at 19:52, Alex Deucher  wrote:
> While the DRM has historically targeted 3D acceleration, that is not a
> requirement to use the DRM KMS modesetting API. ?The current fb API
> has no concept of display controllers or connectors or overlays, etc.
> To match it to modern hardware, it needs a major overhaul. ?Why create
> a new modern fb interface that's largely the same as DRM KMS? ?What if
> we just consider the KMS API as the new fb API? ?If there are any
> inadequacies in the DRM KMS API we would be happy to work out any
> changes.

I admit I didn't look for it, but does there exist a sample DRM KMS driver
for dumb frame buffer hardware with one fixed video mode?

Gr{oetje,eeting}s,

? ? ? ? ? ? ? ? ? ? ? ? Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds

Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen  
wrote:

> 2) panel drivers, handles panel specific things. Each panel may support
> custom commands and features, for which we need a dedicated driver. And
> this driver is not platform specific, but should work with any platform
> which has the output used with the panel.

Right, we've got DDC ports (which are just i2c) and DisplayPort aux
channel stuff.

The DDC stuff is abstracted out and shared across the drivers, but the
DisplayPort aux channel code is not -- it's duplicated in every output
driver. 

> DSI bus is a half-duplex serial bus, and while it's designed for
> displays you could use it easily for any communication between the SoC
> and the peripheral.

Yeah, HDMI uses DDC for all kinds of crazy stuff in the CE world.

> The point is that we cannot have standard "MIPI DSI command mode panel
> driver" which would work for all DSI cmd mode panels, but we need (in
> the worst case) separate driver for each panel.

It sounds like we do want to share code for those bits, much like we
have DDC split out now. And, we should do something about the
DisplayPort aux channel stuff to avoid duplicating it everywhere.

I'm not sure a common interface to all of these different
channels makes sense, but surely a DSI library and an aux channel
library would fit nicely alongside the existing DDC library.

I suspect helper functions would be a good model to follow, rather than
trying to create a whole new device infrastructure; some of the
communication paths aren't easily separable from the underlying output
devices.

Oh, I think you're also trying to get at how we expose some of these
controls outside of the display driver -- right now, they're mostly
exposed as properties on the output device. Things like backlight
brightness, a million analog TV output values, dithering control and
other more esoteric controls.

DRM properties include booleans, enumerations, integer ranges and chunks
of binary data. Some are read-only (like EDID data), some are writable
(like overscan values).

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/731f7f2a/attachment.pgp>

Proposal for a low-level Linux display framework

On 09/15/2011 07:05 PM, Alan Cox wrote:
>> What is your problem with discontigous framebuffers? (I assume discontigous
>> refers to the pages the framebuffer is composed of)
>> Sounds to me like you should implement your own fb_mmap and either map it
>> contigous to screen_base or implement your own fb_read/write.
>> In theory you could even have each pixel at a completely different memory
>> location although some userspace wouldn't be happy when it could no longer 
>> mmap
>> the framebuffer.
> 
> The mmap side is trivial, the problem is that the fb layer default
> implementations of blits, fills etc only work on a kernel linear frame
> buffer. And (for example) there is not enough linear stolen memory on
> some Intel video for a 1080p console on HDMI even though the hardware is
> perfectly capable of using an HDTV as its monitor. Nor - on a 32bit box-
> is there enough space to vremap it.

Okay, I see your problem. It's a bit strange you don't have acceleration. I
guess you need either your own implementation of those or adding function
pointers like fb_read/write just without the __user and use those instead of
direct memory access in the cfb* implementation if screen_base is NULL. Does not
sound like a big problem to me, but pretty inefficient, so probably copying the
existing ones and adjusting it to your needs would be preferred (just like the
sys* implementations exist).

Best regards,

Florian Tobias Schandinat

Proposal for a low-level Linux display framework

On 09/15/2011 06:58 PM, Alan Cox wrote:
>> Well, I rather think that the fb API is more user centric to allow every 
>> program
>> to use it directly in contrast to the KMS/DRM API which aims to support every
>> feature the hardware has. For this the fb API should not change much, but I
>> understand some additions were needed for some special users, probably 
>> limited
>> to X and wayland.
> 
> Wayland needs vblank frame buffer switching and the like. Likewise given
> you want to composite buffers really any serious accelerated device ends
> up needing a full memory manager and that ends up needing a buffer
> manager. Wayland needs clients to be doing their own rendering into
> objects which means authorisation and management of the render engine
> which ends up looking much like DRM.

As you have DRM now and as I'm not interested in wayland I won't discuss this,
but I guess it might be a good start for Geert's question what would be needed
to use it on dumb framebuffers.

>> One of my biggest problems with KMS is that it has (naturally) a lot more
>> complexity than the fb API which leads to instability. Basically it's very
> 
> It shouldn't do - and a sample of one (your machine) is not a
> statistically valid set. Fb is pretty much ununsable in contrast on my
> main box, but that's not a statistically valid sample either.
> 
> I'm not that convinced by the complexity either. For a simple video card
> setup such as those that the fb layer can kind of cope with (ie linear
> buffer, simple mode changes, no client rendering, no vblank flipping,
> limited mode management, no serious multi-head) a DRM driver is also
> pretty tiny and simple.

Yes, if you limit DRM to the functionality of the fb API I guess you could reach
the same stability level. But where can I do this? Where is a option to forbid
all acceleration or at least limit to the acceleration that can be done without
any risk?

>> Well, I think it's too late to really fix this thing. We now have 3 APIs in 
>> the
>> kernel that have to be kept. Probably the best we can do now is figure out 
>> how
>> we can reduce code duplication and do extensions to those APIs in a way that
>> they are compatible with each other or completely independent and can be used
>> across the APIs.
> 
> I think it comes down to 'when nobody is using the old fb drivers they can
> drop into staging and oblivion'. Right now the fb layer is essentially
> compatibility glue on most modern x86 platforms.

That's a really difficult question. Determining the users is difficult and there
are people that use their hardware very long, for example we are about to get a
new driver for i740. For the framebuffer infrastructure I guess you have to at
least wait for my death.


Regards,

Florian Tobias Schandinat

Proposal for a low-level Linux display framework

On 09/15/2011 05:52 PM, Alex Deucher wrote:
> On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat
>  wrote:
>> On 09/15/2011 03:50 PM, Keith Packard wrote:
>>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen >> ti.com> wrote:
>>>
 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
 the plan is to make DRM the core Linux display framework, upon which
 everything else is built, and fb and v4l2 are changed to use DRM.
>>>
>>> I'd like to think we could make DRM the underlying display framework;
>>> it already exposes an fb interface, and with overlays, a bit more of the
>>> v4l2 stuff is done as well. Certainly eliminating three copies of mode
>>> setting infrastructure would be nice...
>>
>> Interesting that this comes from the people that pushed the latest mode 
>> setting
>> code into the kernel. But I don't think that this will happen, the exposed 
>> user
>> interfaces will be around for decades and the infrastructure code could be
>> shared, in theory.
>> For fb and V4L2 I think we'll develop some level of interoperability, share
>> concepts and maybe even some code. The FOURCC pixel formats and overlays are
>> such examples. As Laurent is really interested in it I think we can get some
>> nice progress here.
>> For fb and DRM the situation is entirely different. The last proposal I 
>> remember
>> ended in the DRM people stating that only their implementation is acceptable 
>> as
>> is and we could use it. Such attitude is not helpful and as I don't see any
>> serious intention of the DRM guys to cooperate I think those subsystems are 
>> more
>> likely to diverge. At least I'll never accept any change to the fb
>> infrastructure that requires DRM.
> 
> Not exactly.  This point was that the drm modesetting and EDID
> handling was derived from X which has had 20+ years of of quirks and
> things added to it to deal with tons of wonky monitors and such.  That
> information should be preserved.  As mode structs and EDID handling
> are pretty self contained, why not use the DRM variants of that code
> rather than writing a new version?

Well, I'm not against sharing the code and not against taking DRM's current
implementation as a base but the steps required to make it generally acceptable
would be to split it of, probably as a standalone module and strip all DRM
specific things off. Than all things that require EDID can use it, DRM can add
DRM-specific things on top and fb can add fb-specific things.

> While the DRM has historically targeted 3D acceleration, that is not a
> requirement to use the DRM KMS modesetting API.  The current fb API
> has no concept of display controllers or connectors or overlays, etc.
> To match it to modern hardware, it needs a major overhaul.  Why create
> a new modern fb interface that's largely the same as DRM KMS?  What if
> we just consider the KMS API as the new fb API?  If there are any
> inadequacies in the DRM KMS API we would be happy to work out any
> changes.

Well, I rather think that the fb API is more user centric to allow every program
to use it directly in contrast to the KMS/DRM API which aims to support every
feature the hardware has. For this the fb API should not change much, but I
understand some additions were needed for some special users, probably limited
to X and wayland.
One of my biggest problems with KMS is that it has (naturally) a lot more
complexity than the fb API which leads to instability. Basically it's very
difficult to implement a framebuffer in a way that it crashes your machine
during operation which is quite a contrast to my KMS/DRM experience on my toy
(on my work machines I use framebuffer only). And I really hate it when I have
to type my passwords again just because the KMS/DRM thing allowed a program to
crash my machine. Yes, those are driver bugs but the API encourages them and I
did not yet find the feature/config option DOES_NOT_CRASH or SLOW_BUT_STABLE.
And as I said already, I think the fb API is a lot better for direct interaction
with userspace programs and certainly has more direct users at the moment.

> Please don't claim that the DRM developers do not want to cooperate.
> I realize that people have strong opinions about existing APIs, put
> there has been just as much, if not more obstinacy from the v4l and fb
> people.

Well, I think it's too late to really fix this thing. We now have 3 APIs in the
kernel that have to be kept. Probably the best we can do now is figure out how
we can reduce code duplication and do extensions to those APIs in a way that
they are compatible with each other or completely independent and can be used
across the APIs.

Best regards,

Florian Tobias Schandinat

[PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

2011-09-15 Thread Inki Dae

Hello, Konrad Rzeszutek Wilk.

Your review and comments are so very detail. it was very helpful. thank you
again.

> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk at oracle.com]
> Sent: Thursday, September 15, 2011 6:42 AM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> sw0312.kim at samsung.com; kyungmin.park at samsung.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
> 
> On Fri, Sep 09, 2011 at 08:38:53PM +0900, Inki Dae wrote:
> > This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
> > only FIMD yet but we will add HDMI support also in the future.
> >
> > from now on, I will remove RFC prefix because I think we have got
> comments
> > enough.
> >
> > this patch is based on git repository below:
> > git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
> > branch name: drm-next
> > commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
> >
> > you can refer to our working repository below:
> > http://git.infradead.org/users/kmpark/linux-2.6-samsung
> > branch name: samsung-drm
> >
> > We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
> > based on Linux framebuffer) but couldn't so because lowlevel codes
> > of s3c-fb.c are included internally and so FIMD module of this driver
> has
> > its own lowlevel codes.
> >
> > We used GEM framework for buffer management and DMA APIs(dma_alloc_*)
> > for buffer allocation. by using DMA API, we could use CMA later.
> >
> > Refer to this link for CMA(Continuous Memory Allocator):
> > http://lkml.org/lkml/2011/7/20/45
> >
> > this driver supports only physically continuous memory(non-iommu).
> >
> > Links to previous versions of the patchset:
> > v1: < https://lwn.net/Articles/454380/ >
> > v2: < http://www.spinics.net/lists/kernel/msg1224275.html >
> > v3: < http://www.gossamer-threads.com/lists/linux/kernel/1423684 >
> >
> > Changelog v2:
> > DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
> >
> > this feature maps user address space to physical memory region
> > once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl.
> >
> > DRM: code clean and add exception codes.
> >
> > Changelog v3:
> > DRM: Support multiple irq.
> >
> > FIMD and HDMI have their own irq handler but DRM Framework can
> regiter
> > only one irq handler this patch supports mutiple irq for Samsung
SoC.
> >
> > DRM: Consider modularization.
> >
> > each DRM, FIMD could be built as a module.
> >
> > DRM: Have indenpendent crtc object.
> >
> > crtc isn't specific to SoC Platform so this patch gets a crtc
> > to be used as common object.
> > created crtc could be attached to any encoder object.
> >
> > DRM: code clean and add exception codes.
> >
> > Changelog v4:
> > DRM: remove is_defult from samsung_fb.
> >
> > is_default isn't used for default framebuffer.
> >
> > DRM: code refactoring to fimd module.
> > this patch is be considered with multiple display objects and
> > would use its own request_irq() to register a irq handler instead of
> > drm framework's one.
> >
> > DRM: remove find_samsung_drm_gem_object()
> >
> > DRM: move kernel private data structures and definitions to driver
> folder.
> >
> > samsung_drm.h would contain only public information for userspace
> > ioctl interface.
> >
> > DRM: code refactoring to gem modules.
> > buffer module isn't dependent of gem module anymore.
> >
> > DRM: fixed security issue.
> >
> > DRM: remove encoder porinter from specific connector.
> >
> > samsung connector doesn't need to have generic encoder.
> >
> > DRM: code clean and add exception codes.
> >
> > Signed-off-by: Inki Dae 
> > Signed-off-by: Joonyoung Shim 
> > Signed-off-by: SeungWoo Kim 
> > Signed-off-by: kyungmin.park 
> > ---
> >  drivers/gpu/drm/Kconfig |2 +
> >  drivers/gpu/drm/Makefile|1 +
> >  drivers/gpu/drm/samsung/Kconfig |   18 +
> >  drivers/gpu/drm/samsung/Makefile|   11 +
> >  drivers/gpu/drm/samsung/samsung_drm_buf.c   |  109 
> >  drivers/gpu/drm/samsung/samsung_drm_buf.h   |   50 ++
> >  drivers/gpu/drm/samsung/samsung_drm_connector.c |  257 +
> >  drivers/gpu/drm/samsung/samsung_drm_connector.h |   34 ++
> >  drivers/gpu/drm/samsung/samsung_drm_core.c  |  213 
> >  drivers/gpu/drm/samsung/samsung_drm_crtc.c  |  329 
> >  drivers/gpu/drm/samsung/samsung_drm_crtc.h  |   38 ++
> >  drivers/gpu/drm/samsung/samsung_drm_drv.c   |  215 
> >  drivers/gpu/drm/samsung/samsung_drm_drv.h   |  194 +++
> >  drivers/gpu/drm/samsung/samsung_drm_encoder.c   |  261 +
> >  drivers/gpu/drm/samsung/samsung_drm_encoder.h   |   45 ++
> >  drivers/gpu/drm/samsung/samsung_drm_fb.c|  262 +
> >  drivers/gpu/drm/samsung/samsung_drm_fb.h|   47 ++
> >  drivers/gpu/drm

Whitespace cleanups in drm/i915

I've got this nice patch from Akshay Joshi that removes almost all of
the checkpatch.pl warnings from drm/i915. If I don't merge it now, it's
going to go stale and be useless; if I merge it only to drm-intel-next,
it will be the source of endless conflicts.

However, it's a huge patch (yes, the code was rather sloppy), and
doesn't exactly fit into the "critical patches only please" mode of the
current stage of 3.1 development.

I've checked the patch very carefully, using the obvious git diff -b to
make sure it really doesn't touch anything but whitespace, but also
using objdump -s to compare the output of the compiler. There were no
differences found with git-diff -b. The only differences found by
objdump are two whitespace changes in some debug output messages in
intel_bios.c.

I think I have three choices:

1) merge the patch and expect complaints from upstream

2) thank Akshay for his good intentions, discard the patch and hope
that he feels motivated enough to do it all over again in time for
the 3.2 merge window.

3) thank Akshay for his good intentions and leave the code as-is,
forever to ease back-porting of fixes to older kernel versions.

Frankly, if we're ever going to merge whitespace fixups, this would be a
pretty darn good time; drm-intel-fixes and drm-intel-next are in-sync as
I haven't started pulling 3.2 code into -next.

--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/af0bbef6/attachment-0001.pgp>

Proposal for a low-level Linux display framework

On Thu, 2011-09-15 at 09:59 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen  
> wrote:
> 
> > This was a very rough and quite short proposal, but I'm happy to improve
> > and extend it if it's not totally shot down.
> 
> Jesse Barnes has put together a proposal much like this to work within
> the existing DRM environment. This is pretty much the last piece of
> missing mode-setting functionality that we know of, making DRM capable
> of fully supporting existing (and planned) devices.
> 
> Here's a link to some older discussion on the issue, things have changed
> a bit since then and we had a long talk about this during the X
> Developers' Conference this week in Chicago. Expect an update to his
> proposal in the coming weeks.
> 
> http://lists.freedesktop.org/archives/dri-devel/2011-April/010559.html
> 

Thanks for the link.

Right, DRM has already components I described in my proposal, and adding
overlays brings it even closer. However, I think there are two major
differences:

1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
the plan is to make DRM the core Linux display framework, upon which
everything else is built, and fb and v4l2 are changed to use DRM.

But even if it was done like that, I see that it's combining two
separate things: 1) the lower level HW control, and 2) the upper level
buffer management, policies and userspace interfaces.

2) It's missing the panel driver part. This is rather important on
embedded systems, as the panels often are not "dummy" panels, but they
need things like custom initialization, sending commands to adjust
backlight, etc.

 Tomi

Curious experiences with a Radeon on the fritz

On Mon, Sep 12, 2011 at 2:13 PM, Michael Witten  wrote:
> I hope you find this adventure interesting, and I hope you
> provide me with some insight.
>
> Recently, I booted my computer, a Dell Latitude D810 that has a
> Radeon Mobility x600 (R300); all systems were waking up as normal:
>
> ?* The Dell logo popped up in some ancient VGA mode.
> ?* The GRUB menu appeared for 3 seconds as instructed.
> ?* Linux loaded and started spewing out log messages.
>
> and then:
>
> ? ?BAM!
>
> At around:
>
> ?2011-09-09 20:27:07 +
>
> the Darkness overcame me; my laptop's LCD panel went black with nary
> a sign of life. After poking around a bit via ssh, I couldn't figure
> out what was going on; I had been running all the relevant code
> without trouble for some time now, so it just didn't make sense, and
> I began suspecting hardware failure.
>
> I strolled on over to freenode/#radeon, where I explained that I was
> still getting graphics at early boot time, but that it was dying
> shortly after Linux loaded. A one named Tari suggested that I boot
> with `nomodeset' in order to avoid anything more complicated than
> the standards of the Ancients.
>
> And Lo! With that very kernel command line parameter, the boot
> process did indeed land me safely in a working, albeit cramped
> VGA-backed virtual console.
>
> Searching the logs a bit more revealed the following:
>
> ?[drm:drm_calc_timestamping_constants] *ERROR* crtc 10: Can't
> ?calculate constants, dotclock = 0!
>
> Then (skipping a few interesting adventures), I ultimately discovered
> this kernel message:
>
> ?[drm] Panel Size 1920x4095
>
> which is curious indeed!, because my laptop's panel size should be
> `1920x1200'. I booted into the computer's BIOS only to find that
> it too was being fooled into thinking that the display dimensions
> are `1920x4095'.
>
> Why might this have happened? Are bits stuck? Did something get fried?

Looks like your bios got corrupted somehow.  All of the vertical
timing in your panel modeline is bogus.  You'll need to patch up all
the vertical timing values the same way you patched up the vdisplay in
radeon_combios.c.  You'll have to try and find the native mode timing
for your panel.  Note that other data that the driver uses from the
vbios may also be corrupt.

The xserver defaults to 96dpi because there are too many broken EDIDs
out there and no good way to deal with different DPIs across different
monitors in multi-head desktops.  Also, a lot of users expect 96 dpi
and file bugs when it's something else.

Alex

Proposal for a low-level Linux display framework

> is and we could use it. Such attitude is not helpful and as I don't see any
> serious intention of the DRM guys to cooperate I think those subsystems are 
> more
> likely to diverge. At least I'll never accept any change to the fb
> infrastructure that requires DRM.

There are aspects of the fb code that want changing for DRM (and indeed
modern hardware) but which won't break for other stuff. Given the move to
using main memory for video and the need for the OS to do buffer
management for framebuffers I suspect a move to DRM is pretty much
inevitable, along with having to fix the fb layer to cope with
discontiguous framebuffers.

Alan

Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 10:50:32 -0500
Keith Packard  wrote:

> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen  
> wrote:
> 
> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > the plan is to make DRM the core Linux display framework, upon which
> > everything else is built, and fb and v4l2 are changed to use DRM.
> 
> I'd like to think we could make DRM the underlying display framework;
> it already exposes an fb interface, and with overlays, a bit more of the
> v4l2 stuff is done as well. Certainly eliminating three copies of mode
> setting infrastructure would be nice...

V4L2 needs to interface with the DRM anyway. Lots of current hardware
wants things like shared 1080i/p camera buffers with video in order to do
preview on video and the like.

In my semi-perfect world vision fb would be a legacy layer on top of DRM.
DRM would get the silly recovery fail cases fixed, and a kernel console
would be attachable to a GEM object of your choice.

Alan

[PATCH] drm/gem: add functions to get/put pages

From: Rob Clark 

This factors out common code from psb_gtt_attach_pages()/
i915_gem_object_get_pages_gtt() and psb_gtt_detach_pages()/
i915_gem_object_put_pages_gtt().

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_gem.c |   87 +
 include/drm/drmP.h|3 ++
 2 files changed, 90 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 396e60c..821ba8a 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -285,6 +285,93 @@ again:
 }
 EXPORT_SYMBOL(drm_gem_handle_create);

+/**
+ * drm_gem_get_pages - helper to allocate backing pages for a GEM object
+ * @obj: obj in question
+ * @gfpmask: gfp mask of requested pages
+ */
+struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask)
+{
+   struct inode *inode;
+   struct address_space *mapping;
+   struct page *p, **pages;
+   int i, npages;
+
+   /* This is the shared memory object that backs the GEM resource */
+   inode = obj->filp->f_path.dentry->d_inode;
+   mapping = inode->i_mapping;
+
+   npages = obj->size >> PAGE_SHIFT;
+
+   pages = drm_malloc_ab(npages, sizeof(struct page *));
+   if (pages == NULL)
+   return ERR_PTR(-ENOMEM);
+
+   gfpmask |= mapping_gfp_mask(mapping);
+
+   for (i = 0; i < npages; i++) {
+   p = shmem_read_mapping_page_gfp(mapping, i, gfpmask);
+   if (IS_ERR(p))
+   goto fail;
+   pages[i] = p;
+
+   /* There is a hypothetical issue w/ drivers that require
+* buffer memory in the low 4GB.. if the pages are un-
+* pinned, and swapped out, they can end up swapped back
+* in above 4GB.  If pages are already in memory, then
+* shmem_read_mapping_page_gfp will ignore the gfpmask,
+* even if the already in-memory page disobeys the mask.
+*
+* It is only a theoretical issue today, because none of
+* the devices with this limitation can be populated with
+* enough memory to trigger the issue.  But this BUG_ON()
+* is here as a reminder in case the problem with
+* shmem_read_mapping_page_gfp() isn't solved by the time
+* it does become a real issue.
+*
+* See this thread: http://lkml.org/lkml/2011/7/11/238
+*/
+   BUG_ON((gfpmask & __GFP_DMA32) &&
+   (page_to_pfn(p) >= 0x0010UL));
+   }
+
+   return pages;
+
+fail:
+   while (i--) {
+   page_cache_release(pages[i]);
+   }
+   drm_free_large(pages);
+   return ERR_PTR(PTR_ERR(p));
+}
+EXPORT_SYMBOL(drm_gem_get_pages);
+
+/**
+ * drm_gem_put_pages - helper to free backing pages for a GEM object
+ * @obj: obj in question
+ * @pages: pages to free
+ */
+void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
+   bool dirty, bool accessed)
+{
+   int i, npages;
+
+   npages = obj->size >> PAGE_SHIFT;
+
+   for (i = 0; i < npages; i++) {
+   if (dirty)
+   set_page_dirty(pages[i]);
+
+   if (accessed)
+   mark_page_accessed(pages[i]);
+
+   /* Undo the reference we took when populating the table */
+   page_cache_release(pages[i]);
+   }
+
+   drm_free_large(pages);
+}
+EXPORT_SYMBOL(drm_gem_put_pages);

 /**
  * drm_gem_free_mmap_offset - release a fake mmap offset for an object
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 43538b6..a62d8fe 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1624,6 +1624,9 @@ drm_gem_object_handle_unreference_unlocked(struct 
drm_gem_object *obj)
drm_gem_object_unreference_unlocked(obj);
 }

+struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask);
+void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
+   bool dirty, bool accessed);
 void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
 int drm_gem_create_mmap_offset(struct drm_gem_object *obj);

-- 
1.7.5.4

Proposal for a low-level Linux display framework

Hi Alan,

On 09/15/2011 05:18 PM, Alan Cox wrote:
>> is and we could use it. Such attitude is not helpful and as I don't see any
>> serious intention of the DRM guys to cooperate I think those subsystems are 
>> more
>> likely to diverge. At least I'll never accept any change to the fb
>> infrastructure that requires DRM.
> 
> There are aspects of the fb code that want changing for DRM (and indeed
> modern hardware) but which won't break for other stuff. Given the move to
> using main memory for video and the need for the OS to do buffer
> management for framebuffers I suspect a move to DRM is pretty much
> inevitable, along with having to fix the fb layer to cope with
> discontiguous framebuffers.

What is your problem with discontigous framebuffers? (I assume discontigous
refers to the pages the framebuffer is composed of)
Sounds to me like you should implement your own fb_mmap and either map it
contigous to screen_base or implement your own fb_read/write.
In theory you could even have each pixel at a completely different memory
location although some userspace wouldn't be happy when it could no longer mmap
the framebuffer.

Best regards,

Florian Tobias Schandinat

[PATCH 1/2] drm/radeon: Make sure CS mutex is held across GPU reset.

2011/9/15 Michel D?nzer :
> From: Michel D?nzer 
>
> This was only the case if the GPU reset was triggered from the CS ioctl,
> otherwise other processes could happily enter the CS ioctl and wreak havoc
> during the GPU reset.
>
> This is a little complicated because the GPU reset can be triggered from the
> CS ioctl, in which case we're already holding the mutex, or from other call
> paths, in which case we need to lock the mutex. AFAICT the mutex API doesn't
> allow nested locking or finding out the mutex owner, so we need to handle this
> with some helper functions.
>
> Signed-off-by: Michel D?nzer 

For both patches:

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/radeon/radeon.h ? ? ? ?| ? 60 
> 
> ?drivers/gpu/drm/radeon/radeon_cs.c ? ? | ? 14 
> ?drivers/gpu/drm/radeon/radeon_device.c | ? 16 
> ?3 files changed, 83 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index ef0e0e0..89304d9 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1203,6 +1203,8 @@ struct radeon_device {
> ? ? ? ?struct radeon_pm ? ? ? ? ? ? ? ?pm;
> ? ? ? ?uint32_t ? ? ? ? ? ? ? ? ? ? ? ?bios_scratch[RADEON_BIOS_NUM_SCRATCH];
> ? ? ? ?struct mutex ? ? ? ? ? ? ? ? ? ?cs_mutex;
> + ? ? ? struct task_struct ? ? ? ? ? ? ?*cs_mutex_owner;
> + ? ? ? struct mutex ? ? ? ? ? ? ? ? ? ?cs_mutex_owner_mutex;
> ? ? ? ?struct radeon_wb ? ? ? ? ? ? ? ?wb;
> ? ? ? ?struct radeon_dummy_page ? ? ? ?dummy_page;
> ? ? ? ?bool ? ? ? ? ? ? ? ? ? ? ? ? ? ?gpu_lockup;
> @@ -1241,6 +1243,64 @@ struct radeon_device {
> ? ? ? ?struct radeon_i2c_chan *i2c_bus[RADEON_MAX_I2C_BUS];
> ?};
>
> +
> +/*
> + * CS mutex helpers
> + */
> +
> +static inline void cs_mutex_lock(struct radeon_device *rdev)
> +{
> + ? ? ? mutex_lock(&rdev->cs_mutex);
> +
> + ? ? ? mutex_lock(&rdev->cs_mutex_owner_mutex);
> + ? ? ? rdev->cs_mutex_owner = current;
> + ? ? ? mutex_unlock(&rdev->cs_mutex_owner_mutex);
> +}
> +
> +static inline void cs_mutex_unlock(struct radeon_device *rdev)
> +{
> + ? ? ? mutex_lock(&rdev->cs_mutex_owner_mutex);
> + ? ? ? rdev->cs_mutex_owner = NULL;
> + ? ? ? mutex_unlock(&rdev->cs_mutex_owner_mutex);
> +
> + ? ? ? mutex_unlock(&rdev->cs_mutex);
> +}
> +
> +/*
> + * Check if this process locked the CS mutex already; if it didn't, lock it.
> + *
> + * Returns:
> + * true: This function locked the mutex.
> + * false: This function didn't lock the mutex (this process already locked it
> + * before), so the caller probably shouldn't unlock it.
> + */
> +static inline int cs_mutex_ensure_locked(struct radeon_device *rdev)
> +{
> + ? ? ? int took_mutex;
> + ? ? ? int have_mutex;
> +
> + ? ? ? mutex_lock(&rdev->cs_mutex_owner_mutex);
> + ? ? ? took_mutex = mutex_trylock(&rdev->cs_mutex);
> + ? ? ? if (took_mutex) {
> + ? ? ? ? ? ? ? /* The mutex was unlocked before, so it's ours now */
> + ? ? ? ? ? ? ? rdev->cs_mutex_owner = current;
> + ? ? ? ? ? ? ? have_mutex = true;
> + ? ? ? } else {
> + ? ? ? ? ? ? ? /* Somebody already locked the mutex. Was it this process? */
> + ? ? ? ? ? ? ? have_mutex = (rdev->cs_mutex_owner == current);
> + ? ? ? }
> + ? ? ? mutex_unlock(&rdev->cs_mutex_owner_mutex);
> +
> + ? ? ? if (!have_mutex) {
> + ? ? ? ? ? ? ? /* Another process locked the mutex, take it */
> + ? ? ? ? ? ? ? cs_mutex_lock(rdev);
> + ? ? ? ? ? ? ? took_mutex = true;
> + ? ? ? }
> +
> + ? ? ? return took_mutex;
> +}
> +
> +
> ?int radeon_device_init(struct radeon_device *rdev,
> ? ? ? ? ? ? ? ? ? ? ? struct drm_device *ddev,
> ? ? ? ? ? ? ? ? ? ? ? struct pci_dev *pdev,
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index fae00c0..61e3063 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -222,7 +222,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
> struct drm_file *filp)
> ? ? ? ?struct radeon_cs_chunk *ib_chunk;
> ? ? ? ?int r;
>
> - ? ? ? mutex_lock(&rdev->cs_mutex);
> + ? ? ? cs_mutex_lock(rdev);
> ? ? ? ?/* initialize parser */
> ? ? ? ?memset(&parser, 0, sizeof(struct radeon_cs_parser));
> ? ? ? ?parser.filp = filp;
> @@ -233,14 +233,14 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
> struct drm_file *filp)
> ? ? ? ?if (r) {
> ? ? ? ? ? ? ? ?DRM_ERROR("Failed to initialize parser !\n");
> ? ? ? ? ? ? ? ?radeon_cs_parser_fini(&parser, r);
> - ? ? ? ? ? ? ? mutex_unlock(&rdev->cs_mutex);
> + ? ? ? ? ? ? ? cs_mutex_unlock(rdev);
> ? ? ? ? ? ? ? ?return r;
> ? ? ? ?}
> ? ? ? ?r = ?radeon_ib_get(rdev, &parser.ib);
> ? ? ? ?if (r) {
> ? ? ? ? ? ? ? ?DRM_ERROR("Failed to get ib !\n");
> ? ? ? ? ? ? ? ?radeon_cs_parser_fini(&parser, r);
> - ? ? ? ? ? ? ? mutex_unlock(&rdev->cs_mutex);
> + ? ? ? ? ? ? ? cs_mutex_unlock(rdev);
> ? ? ? ? ? ? ? ?return r;
> ? ? ? ?}
> ? ? ? ?r = radeon_cs_parser_relocs(&parser);
> @@ -248,7 +248,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data,

Re: Curious experiences with a Radeon on the fritz

2011-09-15 Thread Michael Witten

On Thu, Sep 15, 2011 at 22:25, Alex Deucher  wrote:
> On Mon, Sep 12, 2011 at 2:13 PM, Michael Witten  wrote:
>> I hope you find this adventure interesting, and I hope you
>> provide me with some insight.
>>
>> Recently, I booted my computer, a Dell Latitude D810 that has a
>> Radeon Mobility x600 (R300); all systems were waking up as normal:
>>
>>  * The Dell logo popped up in some ancient VGA mode.
>>  * The GRUB menu appeared for 3 seconds as instructed.
>>  * Linux loaded and started spewing out log messages.
>>
>> and then:
>>
>>BAM!
>>
>> At around:
>>
>>  2011-09-09 20:27:07 +
>>
>> the Darkness overcame me; my laptop's LCD panel went black with nary
>> a sign of life. After poking around a bit via ssh, I couldn't figure
>> out what was going on; I had been running all the relevant code
>> without trouble for some time now, so it just didn't make sense, and
>> I began suspecting hardware failure.
>>
>> I strolled on over to freenode/#radeon, where I explained that I was
>> still getting graphics at early boot time, but that it was dying
>> shortly after Linux loaded. A one named Tari suggested that I boot
>> with `nomodeset' in order to avoid anything more complicated than
>> the standards of the Ancients.
>>
>> And Lo! With that very kernel command line parameter, the boot
>> process did indeed land me safely in a working, albeit cramped
>> VGA-backed virtual console.
>>
>> Searching the logs a bit more revealed the following:
>>
>>  [drm:drm_calc_timestamping_constants] *ERROR* crtc 10: Can't
>>  calculate constants, dotclock = 0!
>>
>> Then (skipping a few interesting adventures), I ultimately discovered
>> this kernel message:
>>
>>  [drm] Panel Size 1920x4095
>>
>> which is curious indeed!, because my laptop's panel size should be
>> `1920x1200'. I booted into the computer's BIOS only to find that
>> it too was being fooled into thinking that the display dimensions
>> are `1920x4095'.
>>
>> Why might this have happened? Are bits stuck? Did something get fried?
>
> Looks like your bios got corrupted somehow.  All of the vertical
> timing in your panel modeline is bogus.  You'll need to patch up all
> the vertical timing values the same way you patched up the vdisplay in
> radeon_combios.c.  You'll have to try and find the native mode timing
> for your panel.  Note that other data that the driver uses from the
> vbios may also be corrupt.
>
> The xserver defaults to 96dpi because there are too many broken EDIDs
> out there and no good way to deal with different DPIs across different
> monitors in multi-head desktops.  Also, a lot of users expect 96 dpi
> and file bugs when it's something else.

Thanks for the reply.

I did indeed end up hardcoding modeline values in that same function,
which basically solved the problem for the time being; I plan[ned] on
posting a follow-up email sometime soon (including my attempts to
thwart future corruption).

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

Proposal for a low-level Linux display framework

On 09/15/2011 03:50 PM, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen  
> wrote:
> 
>> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> the plan is to make DRM the core Linux display framework, upon which
>> everything else is built, and fb and v4l2 are changed to use DRM.
> 
> I'd like to think we could make DRM the underlying display framework;
> it already exposes an fb interface, and with overlays, a bit more of the
> v4l2 stuff is done as well. Certainly eliminating three copies of mode
> setting infrastructure would be nice...

Interesting that this comes from the people that pushed the latest mode setting
code into the kernel. But I don't think that this will happen, the exposed user
interfaces will be around for decades and the infrastructure code could be
shared, in theory.
For fb and V4L2 I think we'll develop some level of interoperability, share
concepts and maybe even some code. The FOURCC pixel formats and overlays are
such examples. As Laurent is really interested in it I think we can get some
nice progress here.
For fb and DRM the situation is entirely different. The last proposal I remember
ended in the DRM people stating that only their implementation is acceptable as
is and we could use it. Such attitude is not helpful and as I don't see any
serious intention of the DRM guys to cooperate I think those subsystems are more
likely to diverge. At least I'll never accept any change to the fb
infrastructure that requires DRM.

Regards,

Florian Tobias Schandinat

Proposal for a DRM-compliant GPU command scheduler

2011-09-15 Thread Shinpei KATO

Hi,

I am the main developer of the TimeGraph GPU command scheduler, which was
presented at XDC 2011 in Chicago a few days ago.
Please let me propose this approach to scheduling GPU-accelerated processes
with DRM.

This GPU scheduler will help to prioritize and isolate multiple
GPU-accelerated processes executing concurrently for protecting important
GPU workload in multi-tasking environments. It is designed and implemented
at the DRM level as a "drm_sched" component. Each architecture-dependent
driver (nouveau, radeon, i915, etc.) is also required to call the scheduling
functions provided by this drm_sched component accordingly. Nothing needs to
be changed in user-space runtimes.
The priorities and resource limits can be specified through
"/proc/driver/drm_sched/#PID/{sched_policy,resv_policy,priority,runtime,peri
od}" and/or "/etc/drm_sched.spec". Other user interfaces could also be
possible.
The impact of prioritization and isolation on protecting important
GPU-accelerated processes from competing GPU workload is quite significant
(e.g., 3-D games can run at a 10x~ faster rate, using our GPU scheduler,
when heavy workload is competing the GPU). Performance interference among
GPU-accelerated processes can also be well-controlled.
We can activate this GPU scheduler only when multiple processes use the GPU.
Hence *nothing* would be harmful for a standalone execution.
I felt that the audience at XDC 2011 was pretty supportive for this idea.

TimeGraph is developed in a collaborative project with Carnegie Mellon
University, University of California Santa Cruz, and University of Tokyo.
The project website is: http://rtml.ece.cmu.edu/projects/timegraph/

The documentation about how it works is:
http://rtml.ece.cmu.edu/projects/timegraph/raw-attachment/wiki/documentation
/drm_sched_rtgpu.pdf
More information is available at:
http://rtml.ece.cmu.edu/projects/timegraph/wiki/documentation

The instruction to install our Nouveau-based prototype driver is:
http://rtml.ece.cmu.edu/projects/timegraph/wiki/install
For convenience of development, the GPU scheduler is provided as an
independent kernel module (https://gitorious.org/rtgpu/timegraph), but it
can also be part of DRM.
You will also need the Nouveau-tree Linux kernel patched for drm_sched
(https://gitorious.org/rtgpu/linux-rtgpu). Please see the instruction above.
There are not so many changes applied to the current kernel code, as you can
quickly reference at:
http://rtml.ece.cmu.edu/projects/timegraph/attachment/wiki/install/linux-rtg
pu.patch

I would appreciate any comments and feedback from you.

Best Regards,
- Shinpei Kato

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

Proposal for a DRM-compliant GPU command scheduler

2011-09-15 Thread Shinpei KATO

Hi,

I am the main developer of the TimeGraph GPU command scheduler, which was
presented at XDC 2011 in Chicago a few days ago.
Please let me propose this approach to scheduling GPU-accelerated processes
with DRM.

This GPU scheduler will help to prioritize and isolate multiple
GPU-accelerated processes executing concurrently for protecting important
GPU workload in multi-tasking environments. It is designed and implemented
at the DRM level as a "drm_sched" component. Each architecture-dependent
driver (nouveau, radeon, i915, etc.) is also required to call the scheduling
functions provided by this drm_sched component accordingly. Nothing needs to
be changed in user-space runtimes.
The priorities and resource limits can be specified through
"/proc/driver/drm_sched/#PID/{sched_policy,resv_policy,priority,runtime,peri
od}" and/or "/etc/drm_sched.spec". Other user interfaces could also be
possible.
The impact of prioritization and isolation on protecting important
GPU-accelerated processes from competing GPU workload is quite significant
(e.g., 3-D games can run at a 10x~ faster rate, using our GPU scheduler,
when heavy workload is competing the GPU). Performance interference among
GPU-accelerated processes can also be well-controlled.
We can activate this GPU scheduler only when multiple processes use the GPU.
Hence *nothing* would be harmful for a standalone execution.
I felt that the audience at XDC 2011 was pretty supportive for this idea.

TimeGraph is developed in a collaborative project with Carnegie Mellon
University, University of California Santa Cruz, and University of Tokyo.
The project website is: http://rtml.ece.cmu.edu/projects/timegraph/

The documentation about how it works is:
http://rtml.ece.cmu.edu/projects/timegraph/raw-attachment/wiki/documentation
/drm_sched_rtgpu.pdf
More information is available at:
http://rtml.ece.cmu.edu/projects/timegraph/wiki/documentation

The instruction to install our Nouveau-based prototype driver is:
http://rtml.ece.cmu.edu/projects/timegraph/wiki/install
For convenience of development, the GPU scheduler is provided as an
independent kernel module (https://gitorious.org/rtgpu/timegraph), but it
can also be part of DRM.
You will also need the Nouveau-tree Linux kernel patched for drm_sched
(https://gitorious.org/rtgpu/linux-rtgpu). Please see the instruction above.
There are not so many changes applied to the current kernel code, as you can
quickly reference at:
http://rtml.ece.cmu.edu/projects/timegraph/attachment/wiki/install/linux-rtg
pu.patch

I would appreciate any comments and feedback from you.

Best Regards,
- Shinpei Kato

[PATCH] drm/gem: add functions to get/put pages

From: Rob Clark 

This factors out common code from psb_gtt_attach_pages()/
i915_gem_object_get_pages_gtt() and psb_gtt_detach_pages()/
i915_gem_object_put_pages_gtt().

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_gem.c |   87 +
 include/drm/drmP.h|3 ++
 2 files changed, 90 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 396e60c..821ba8a 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -285,6 +285,93 @@ again:
 }
 EXPORT_SYMBOL(drm_gem_handle_create);
 
+/**
+ * drm_gem_get_pages - helper to allocate backing pages for a GEM object
+ * @obj: obj in question
+ * @gfpmask: gfp mask of requested pages
+ */
+struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask)
+{
+   struct inode *inode;
+   struct address_space *mapping;
+   struct page *p, **pages;
+   int i, npages;
+
+   /* This is the shared memory object that backs the GEM resource */
+   inode = obj->filp->f_path.dentry->d_inode;
+   mapping = inode->i_mapping;
+
+   npages = obj->size >> PAGE_SHIFT;
+
+   pages = drm_malloc_ab(npages, sizeof(struct page *));
+   if (pages == NULL)
+   return ERR_PTR(-ENOMEM);
+
+   gfpmask |= mapping_gfp_mask(mapping);
+
+   for (i = 0; i < npages; i++) {
+   p = shmem_read_mapping_page_gfp(mapping, i, gfpmask);
+   if (IS_ERR(p))
+   goto fail;
+   pages[i] = p;
+
+   /* There is a hypothetical issue w/ drivers that require
+* buffer memory in the low 4GB.. if the pages are un-
+* pinned, and swapped out, they can end up swapped back
+* in above 4GB.  If pages are already in memory, then
+* shmem_read_mapping_page_gfp will ignore the gfpmask,
+* even if the already in-memory page disobeys the mask.
+*
+* It is only a theoretical issue today, because none of
+* the devices with this limitation can be populated with
+* enough memory to trigger the issue.  But this BUG_ON()
+* is here as a reminder in case the problem with
+* shmem_read_mapping_page_gfp() isn't solved by the time
+* it does become a real issue.
+*
+* See this thread: http://lkml.org/lkml/2011/7/11/238
+*/
+   BUG_ON((gfpmask & __GFP_DMA32) &&
+   (page_to_pfn(p) >= 0x0010UL));
+   }
+
+   return pages;
+
+fail:
+   while (i--) {
+   page_cache_release(pages[i]);
+   }
+   drm_free_large(pages);
+   return ERR_PTR(PTR_ERR(p));
+}
+EXPORT_SYMBOL(drm_gem_get_pages);
+
+/**
+ * drm_gem_put_pages - helper to free backing pages for a GEM object
+ * @obj: obj in question
+ * @pages: pages to free
+ */
+void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
+   bool dirty, bool accessed)
+{
+   int i, npages;
+
+   npages = obj->size >> PAGE_SHIFT;
+
+   for (i = 0; i < npages; i++) {
+   if (dirty)
+   set_page_dirty(pages[i]);
+
+   if (accessed)
+   mark_page_accessed(pages[i]);
+
+   /* Undo the reference we took when populating the table */
+   page_cache_release(pages[i]);
+   }
+
+   drm_free_large(pages);
+}
+EXPORT_SYMBOL(drm_gem_put_pages);
 
 /**
  * drm_gem_free_mmap_offset - release a fake mmap offset for an object
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 43538b6..a62d8fe 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1624,6 +1624,9 @@ drm_gem_object_handle_unreference_unlocked(struct 
drm_gem_object *obj)
drm_gem_object_unreference_unlocked(obj);
 }
 
+struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask);
+void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
+   bool dirty, bool accessed);
 void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
 int drm_gem_create_mmap_offset(struct drm_gem_object *obj);
 
-- 
1.7.5.4

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

Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 3:18 PM, Florian Tobias Schandinat
 wrote:
> On 09/15/2011 06:58 PM, Alan Cox wrote:
>>> Well, I rather think that the fb API is more user centric to allow every 
>>> program
>>> to use it directly in contrast to the KMS/DRM API which aims to support 
>>> every
>>> feature the hardware has. For this the fb API should not change much, but I
>>> understand some additions were needed for some special users, probably 
>>> limited
>>> to X and wayland.
>>
>> Wayland needs vblank frame buffer switching and the like. Likewise given
>> you want to composite buffers really any serious accelerated device ends
>> up needing a full memory manager and that ends up needing a buffer
>> manager. Wayland needs clients to be doing their own rendering into
>> objects which means authorisation and management of the render engine
>> which ends up looking much like DRM.
>
> As you have DRM now and as I'm not interested in wayland I won't discuss this,
> but I guess it might be a good start for Geert's question what would be needed
> to use it on dumb framebuffers.
>
>>> One of my biggest problems with KMS is that it has (naturally) a lot more
>>> complexity than the fb API which leads to instability. Basically it's very
>>
>> It shouldn't do - and a sample of one (your machine) is not a
>> statistically valid set. Fb is pretty much ununsable in contrast on my
>> main box, but that's not a statistically valid sample either.
>>
>> I'm not that convinced by the complexity either. For a simple video card
>> setup such as those that the fb layer can kind of cope with (ie linear
>> buffer, simple mode changes, no client rendering, no vblank flipping,
>> limited mode management, no serious multi-head) a DRM driver is also
>> pretty tiny and simple.
>
> Yes, if you limit DRM to the functionality of the fb API I guess you could 
> reach
> the same stability level. But where can I do this? Where is a option to forbid
> all acceleration or at least limit to the acceleration that can be done 
> without
> any risk?

Right now most of the KMS DRM drivers do not support accelerated fb,
so as long as you don't run accelerated X or a 3D app, it should be
just as stable as an fb driver.  You may run into modesetting fail in
certain cases due to wonky hardware or driver bugs, but you will hit
that with an fb driver as well.

Alex

[Bug 22030] r200: Texture loads fail randomly

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

--- Comment #6 from Stefan Dösinger  2011-09-15 
15:38:26 PDT ---
Yes, I did, and I did some retesting of the r200 driver a few days ago(See bug
27069, where I complained about performance 2 years ago and still complain
about performance today).

This specific problem seems to be gone. I can see no problems on the 2D
Desktop, and tuxracer / etracer work just fine. I think the max texture size
the driver reported was 2048 for normal textures and 256 for volume maps.

(The ultimate goal of warming up the r200 machine again was to get the Wine
unit tests working, but there are too many issues and I think there are better
ways to invest the time)

-- 
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

[Bug 22030] r200: Texture loads fail randomly

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

--- Comment #6 from Stefan D?singer  2011-09-15 
15:38:26 PDT ---
Yes, I did, and I did some retesting of the r200 driver a few days ago(See bug
27069, where I complained about performance 2 years ago and still complain
about performance today).

This specific problem seems to be gone. I can see no problems on the 2D
Desktop, and tuxracer / etracer work just fine. I think the max texture size
the driver reported was 2048 for normal textures and 256 for volume maps.

(The ultimate goal of warming up the r200 machine again was to get the Wine
unit tests working, but there are too many issues and I think there are better
ways to invest the time)

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

Re: Curious experiences with a Radeon on the fritz

On Mon, Sep 12, 2011 at 2:13 PM, Michael Witten  wrote:
> I hope you find this adventure interesting, and I hope you
> provide me with some insight.
>
> Recently, I booted my computer, a Dell Latitude D810 that has a
> Radeon Mobility x600 (R300); all systems were waking up as normal:
>
>  * The Dell logo popped up in some ancient VGA mode.
>  * The GRUB menu appeared for 3 seconds as instructed.
>  * Linux loaded and started spewing out log messages.
>
> and then:
>
>    BAM!
>
> At around:
>
>  2011-09-09 20:27:07 +
>
> the Darkness overcame me; my laptop's LCD panel went black with nary
> a sign of life. After poking around a bit via ssh, I couldn't figure
> out what was going on; I had been running all the relevant code
> without trouble for some time now, so it just didn't make sense, and
> I began suspecting hardware failure.
>
> I strolled on over to freenode/#radeon, where I explained that I was
> still getting graphics at early boot time, but that it was dying
> shortly after Linux loaded. A one named Tari suggested that I boot
> with `nomodeset' in order to avoid anything more complicated than
> the standards of the Ancients.
>
> And Lo! With that very kernel command line parameter, the boot
> process did indeed land me safely in a working, albeit cramped
> VGA-backed virtual console.
>
> Searching the logs a bit more revealed the following:
>
>  [drm:drm_calc_timestamping_constants] *ERROR* crtc 10: Can't
>  calculate constants, dotclock = 0!
>
> Then (skipping a few interesting adventures), I ultimately discovered
> this kernel message:
>
>  [drm] Panel Size 1920x4095
>
> which is curious indeed!, because my laptop's panel size should be
> `1920x1200'. I booted into the computer's BIOS only to find that
> it too was being fooled into thinking that the display dimensions
> are `1920x4095'.
>
> Why might this have happened? Are bits stuck? Did something get fried?

Looks like your bios got corrupted somehow.  All of the vertical
timing in your panel modeline is bogus.  You'll need to patch up all
the vertical timing values the same way you patched up the vdisplay in
radeon_combios.c.  You'll have to try and find the native mode timing
for your panel.  Note that other data that the driver uses from the
vbios may also be corrupt.

The xserver defaults to 96dpi because there are too many broken EDIDs
out there and no good way to deal with different DPIs across different
monitors in multi-head desktops.  Also, a lot of users expect 96 dpi
and file bugs when it's something else.

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

Proposal for a low-level Linux display framework

Hi,

I am the author of OMAP display driver, and while developing it I've
often felt that there's something missing in Linux's display area. I've
been planning to write a post about this for a few years already, but I
never got to it. So here goes at last!

---

First I want to (try to) describe shortly what we have on OMAP, to give
a bit of a background for my point of view, and to have an example HW.

The display subsystem (DSS) hardware on OMAP handles only showing pixels
on a display, so it doesn't contain anything that produces pixels like
3D stuff or accelerated copying. All it does is fetch pixels from SDRAM,
possibly do some modifications for them (color format conversions etc),
and output them to a display.

The hardware has multiple overlays, which are like hardware windows.
They fetch pixels from SDRAM, and output them in a certain area on the
display (possibly with scaling). Multiple overlays can be composited
into one output.

So we may have something like this, when all overlays read pixels from
separate areas in the memory, and all overlays are on LCD display:

 .-. .--.   .--.
 | mem |>| ovl0 |-.>| LCD  |
 '-' '--' | '--'
 .-. .--. |
 | mem |>| ovl1 |-|
 '-' '--' |
 .-. .--. | .--.
 | mem |>| ovl2 |-' |  TV  |
 '-' '--'   '--'

The LCD display can be rather simple one, like a standard monitor or a
simple panel directly connected to parallel RGB output, or a more
complex one. A complex panel needs something else than just
turn-it-on-and-go. This may involve sending and receiving messages
between OMAP and the panel, but more generally, there's need to have
custom code that handles the particular panel. And the complex panel is
not necessarily a panel at all, it may be a buffer chip between OMAP and
the actual panel.

The software side can be divided into three parts: the lower level
omapdss driver, the lower level panel drivers, and higher level drivers
like omapfb, v4l2 and omapdrm.

The omapdss driver handles the OMAP DSS hardware, and offers a kernel
internal API which the higher level drivers use. The omapdss does not
know anything about fb or drm, it just offers core display services.

The panel drivers handle particular panels/chips. The panel driver may
be very simple in case of a conventional display, basically doing pretty
much nothing, or bigger piece of code, handling communication with the
panel.

The higher level drivers handle buffers and tell omapdss things like
where to find the pixels, what size the overlays should be, and use the
omapdss API to turn displays on/off, etc.

---

There are two things that I'm proposing to improve the Linux display
support:

First, there should be a bunch of common video structs and helpers that
are independent of any higher level framework. Things like video
timings, mode databases, and EDID seem to be implemented multiple times
in the kernel. But there shouldn't be anything in those things that
depend on any particular display framework, so they could be implemented
just once and all the frameworks could use them.

Second, I think there could be use for a common low level display
framework. Currently the lower level code (display HW handling, etc.)
and higher level code (buffer management, policies, etc) seem to be
usually tied together, like the fb framework or the drm. Granted, the
frameworks do not force that, and for OMAP we indeed have omapfb and
omapdrm using the lower level omapdss. But I don't see that it's
anything OMAP specific as such.

I think the lower level framework could have components something like
this (the naming is OMAP oriented, of course):

overlay - a hardware "window", gets pixels from memory, possibly does
format conversions, scaling, etc.

overlay compositor - composes multiple overlays into one output,
possibly doing things like translucency.

output - gets the pixels from overlay compositor, and sends them out
according to particular video timings when using conventional video
interface, or via any other mean when using non-conventional video buses
like DSI command mode.

display - handles an external display. For conventional displays this
wouldn't do much, but for complex ones it does whatever needed by that
particular display.

This is something similar to what DRM has, I believe. The biggest
difference is that the display can be a full blown driver for a complex
piece of HW.

This kind of low level framework would be good for two purposes: 1) I
think it's a good division generally, having the low level HW driver
separate from the higher level buffer/policy management and 2) fb, drm,
v4l2 or any possible future framework could all use the same low level
framework.

---

Now, I'm quite sure the above framework could work quite well with any
OMAP like hardware, with unified memory (i.e. the video buffers are in
SDRAM) an

Re: Proposal for a low-level Linux display framework

> Okay, I see your problem. It's a bit strange you don't have acceleration. I

The hardware has 3D acceleration but not open so we can't support it.
There is no 2D acceleration - which seems to be increasingly common.

At some point I'll add hardware scrolling however by using the GTT to
implemnent scroll wrapping.

> sound like a big problem to me, but pretty inefficient, so probably copying 
> the
> existing ones and adjusting it to your needs would be preferred (just like the
> sys* implementations exist).

I did have a look at the current ones but fixing them up given scan lines
can span page boundaries looked pretty horrible so I deferred it until I
feel inspired.

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

Re: [PATCH 1/2] drm/radeon: Make sure CS mutex is held across GPU reset.

2011/9/15 Michel Dänzer :
> From: Michel Dänzer 
>
> This was only the case if the GPU reset was triggered from the CS ioctl,
> otherwise other processes could happily enter the CS ioctl and wreak havoc
> during the GPU reset.
>
> This is a little complicated because the GPU reset can be triggered from the
> CS ioctl, in which case we're already holding the mutex, or from other call
> paths, in which case we need to lock the mutex. AFAICT the mutex API doesn't
> allow nested locking or finding out the mutex owner, so we need to handle this
> with some helper functions.
>
> Signed-off-by: Michel Dänzer 

For both patches:

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/radeon.h        |   60 
> 
>  drivers/gpu/drm/radeon/radeon_cs.c     |   14 
>  drivers/gpu/drm/radeon/radeon_device.c |   16 
>  3 files changed, 83 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index ef0e0e0..89304d9 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1203,6 +1203,8 @@ struct radeon_device {
>        struct radeon_pm                pm;
>        uint32_t                        bios_scratch[RADEON_BIOS_NUM_SCRATCH];
>        struct mutex                    cs_mutex;
> +       struct task_struct              *cs_mutex_owner;
> +       struct mutex                    cs_mutex_owner_mutex;
>        struct radeon_wb                wb;
>        struct radeon_dummy_page        dummy_page;
>        bool                            gpu_lockup;
> @@ -1241,6 +1243,64 @@ struct radeon_device {
>        struct radeon_i2c_chan *i2c_bus[RADEON_MAX_I2C_BUS];
>  };
>
> +
> +/*
> + * CS mutex helpers
> + */
> +
> +static inline void cs_mutex_lock(struct radeon_device *rdev)
> +{
> +       mutex_lock(&rdev->cs_mutex);
> +
> +       mutex_lock(&rdev->cs_mutex_owner_mutex);
> +       rdev->cs_mutex_owner = current;
> +       mutex_unlock(&rdev->cs_mutex_owner_mutex);
> +}
> +
> +static inline void cs_mutex_unlock(struct radeon_device *rdev)
> +{
> +       mutex_lock(&rdev->cs_mutex_owner_mutex);
> +       rdev->cs_mutex_owner = NULL;
> +       mutex_unlock(&rdev->cs_mutex_owner_mutex);
> +
> +       mutex_unlock(&rdev->cs_mutex);
> +}
> +
> +/*
> + * Check if this process locked the CS mutex already; if it didn't, lock it.
> + *
> + * Returns:
> + * true: This function locked the mutex.
> + * false: This function didn't lock the mutex (this process already locked it
> + * before), so the caller probably shouldn't unlock it.
> + */
> +static inline int cs_mutex_ensure_locked(struct radeon_device *rdev)
> +{
> +       int took_mutex;
> +       int have_mutex;
> +
> +       mutex_lock(&rdev->cs_mutex_owner_mutex);
> +       took_mutex = mutex_trylock(&rdev->cs_mutex);
> +       if (took_mutex) {
> +               /* The mutex was unlocked before, so it's ours now */
> +               rdev->cs_mutex_owner = current;
> +               have_mutex = true;
> +       } else {
> +               /* Somebody already locked the mutex. Was it this process? */
> +               have_mutex = (rdev->cs_mutex_owner == current);
> +       }
> +       mutex_unlock(&rdev->cs_mutex_owner_mutex);
> +
> +       if (!have_mutex) {
> +               /* Another process locked the mutex, take it */
> +               cs_mutex_lock(rdev);
> +               took_mutex = true;
> +       }
> +
> +       return took_mutex;
> +}
> +
> +
>  int radeon_device_init(struct radeon_device *rdev,
>                       struct drm_device *ddev,
>                       struct pci_dev *pdev,
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index fae00c0..61e3063 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -222,7 +222,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
> struct drm_file *filp)
>        struct radeon_cs_chunk *ib_chunk;
>        int r;
>
> -       mutex_lock(&rdev->cs_mutex);
> +       cs_mutex_lock(rdev);
>        /* initialize parser */
>        memset(&parser, 0, sizeof(struct radeon_cs_parser));
>        parser.filp = filp;
> @@ -233,14 +233,14 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
> struct drm_file *filp)
>        if (r) {
>                DRM_ERROR("Failed to initialize parser !\n");
>                radeon_cs_parser_fini(&parser, r);
> -               mutex_unlock(&rdev->cs_mutex);
> +               cs_mutex_unlock(rdev);
>                return r;
>        }
>        r =  radeon_ib_get(rdev, &parser.ib);
>        if (r) {
>                DRM_ERROR("Failed to get ib !\n");
>                radeon_cs_parser_fini(&parser, r);
> -               mutex_unlock(&rdev->cs_mutex);
> +               cs_mutex_unlock(rdev);
>                return r;
>        }
>        r = radeon_cs_parser_relocs(&parser);
> @@ -248,7 +248,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data,

Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
 wrote:
> On Thu, Sep 15, 2011 at 19:52, Alex Deucher  wrote:
>> While the DRM has historically targeted 3D acceleration, that is not a
>> requirement to use the DRM KMS modesetting API. ?The current fb API
>> has no concept of display controllers or connectors or overlays, etc.
>> To match it to modern hardware, it needs a major overhaul. ?Why create
>> a new modern fb interface that's largely the same as DRM KMS? ?What if
>> we just consider the KMS API as the new fb API? ?If there are any
>> inadequacies in the DRM KMS API we would be happy to work out any
>> changes.
>
> I admit I didn't look for it, but does there exist a sample DRM KMS driver
> for dumb frame buffer hardware with one fixed video mode?

Not at the moment.  However, there drivers for AMD, Intel, and nvidia
chips as well patches for a number of ARM SoCs that are in the process
of moving upstream.  Also, Matt Turner wrote a KMS driver for 3D labs
glint hardware that is pretty simple (single display controller,
single DAC, etc.), however it hasn't been merged upstream yet.
http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz&can=2&q=
His kernel git tree was on kernel.org so it's down at the moment,
hence the link to the tarball.

Alex

Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat
 wrote:
> On 09/15/2011 03:50 PM, Keith Packard wrote:
>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen > ti.com> wrote:
>>
>>> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>>> the plan is to make DRM the core Linux display framework, upon which
>>> everything else is built, and fb and v4l2 are changed to use DRM.
>>
>> I'd like to think we could make DRM the underlying display framework;
>> it already exposes an fb interface, and with overlays, a bit more of the
>> v4l2 stuff is done as well. Certainly eliminating three copies of mode
>> setting infrastructure would be nice...
>
> Interesting that this comes from the people that pushed the latest mode 
> setting
> code into the kernel. But I don't think that this will happen, the exposed 
> user
> interfaces will be around for decades and the infrastructure code could be
> shared, in theory.
> For fb and V4L2 I think we'll develop some level of interoperability, share
> concepts and maybe even some code. The FOURCC pixel formats and overlays are
> such examples. As Laurent is really interested in it I think we can get some
> nice progress here.
> For fb and DRM the situation is entirely different. The last proposal I 
> remember
> ended in the DRM people stating that only their implementation is acceptable 
> as
> is and we could use it. Such attitude is not helpful and as I don't see any
> serious intention of the DRM guys to cooperate I think those subsystems are 
> more
> likely to diverge. At least I'll never accept any change to the fb
> infrastructure that requires DRM.

Not exactly.  This point was that the drm modesetting and EDID
handling was derived from X which has had 20+ years of of quirks and
things added to it to deal with tons of wonky monitors and such.  That
information should be preserved.  As mode structs and EDID handling
are pretty self contained, why not use the DRM variants of that code
rather than writing a new version?

While the DRM has historically targeted 3D acceleration, that is not a
requirement to use the DRM KMS modesetting API.  The current fb API
has no concept of display controllers or connectors or overlays, etc.
To match it to modern hardware, it needs a major overhaul.  Why create
a new modern fb interface that's largely the same as DRM KMS?  What if
we just consider the KMS API as the new fb API?  If there are any
inadequacies in the DRM KMS API we would be happy to work out any
changes.

Please don't claim that the DRM developers do not want to cooperate.
I realize that people have strong opinions about existing APIs, put
there has been just as much, if not more obstinacy from the v4l and fb
people.

Alex

[PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms

2011-09-15 Thread Inki Dae

Hi, Rob.

> -Original Message-
> From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf Of Rob
> Clark
> Sent: Thursday, September 15, 2011 4:42 AM
> To: Inki Dae
> Cc: linaro-dev at lists.linaro.org; dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
> 
> On Wed, Sep 14, 2011 at 12:44 AM, Inki Dae  wrote:
> > Hello Rob.
> > Sorry for being late. here was a national holiday.
> >
> >
> >> -Original Message-
> >> From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf Of 
> >> Rob
> >> Clark
> >> Sent: Thursday, September 08, 2011 3:44 AM
> >> To: Inki Dae
> >> Cc: linaro-dev at lists.linaro.org; dri-devel at lists.freedesktop.org
> >> Subject: Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
> >>
> >> On Wed, Sep 7, 2011 at 1:00 AM, Inki Dae  wrote:
> >> > Hello, Rob.
> >> >
> >> [snip]
> >> >> >> +static void page_flip_cb(void *arg)
> >> >> >> +{
> >> >> >> + ? ? struct drm_crtc *crtc = arg;
> >> >> >> + ? ? struct drm_device *dev = crtc->dev;
> >> >> >> + ? ? struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> >> >> >> + ? ? struct drm_pending_vblank_event *event = omap_crtc->event;
> >> >> >> + ? ? struct timeval now;
> >> >> >> + ? ? unsigned long flags;
> >> >> >> +
> >> >> >> + ? ? WARN_ON(!event);
> >> >> >> +
> >> >> >> + ? ? omap_crtc->event = NULL;
> >> >> >> +
> >> >> >> + ? ? update_scanout(crtc);
> >> >> >> + ? ? commit(crtc);
> >> >> >> +
> >> >> >> + ? ? /* wakeup userspace */
> >> >> >> + ? ? // TODO: this should happen *after* flip.. somehow..
> >> >> >> + ? ? if (event) {
> >> >> >> + ? ? ? ? ? ? spin_lock_irqsave(&dev->event_lock, flags);
> >> >> >> + ? ? ? ? ? ? event->event.sequence =
> >> >> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? drm_vblank_count_and_time(dev,
> >> >> > omap_crtc->id,
> >> >> >> &now);
> >> >> >> + ? ? ? ? ? ? event->event.tv_sec = now.tv_sec;
> >> >> >> + ? ? ? ? ? ? event->event.tv_usec = now.tv_usec;
> >> >> >> + ? ? ? ? ? ? list_add_tail(&event->base.link,
> >> >> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?
&event->base.file_priv->event_list);
> >> >> >> +
> >> > wake_up_interruptible(&event->base.file_priv->event_wait);
> >> >> >> + ? ? ? ? ? ? spin_unlock_irqrestore(&dev->event_lock, flags);
> >> >> >> + ? ? }
> >> >> >
> >> >> > How about moving codes above into interrupt handler for vblank?
> >> >> > ?maybe there
> >> >>
> >> >> I should mention a couple of things:
> >> >>
> >> >> 1) drm vblank stuff isn't really used currently.. it is actually
> DSS2
> >> >> layer that is registering for the display related interrupt(s). ?I'm
> >> >> not really sure how to handle this best. ?I suppose the DRM driver
> >> >> could *also* register for these interrupts, but that seems a bit
> odd..
> >> >>
> >> >
> >> > DRM Framework supports only one interrupt handler. this issue should
> be
> >> > resolved. and currently I made our driver to use its own request_irq,
> >> not
> >> > DRM Framework side. we only sets drm_device->irq_enabled to 1 and
> >> interrupt
> >> > handler is registered at display controller or hdmi driver
> respectively.
> >> but
> >> > I'm not sure that this way is best so I will look over more. Anyway
> >> current
> >> > drm framework should be fixed to be considered with multiple irq.
> >>
> >> Or perhaps even callbacks (some other driver handling the irq's
> directly)?
> >>
> >
> > Yes.
> >
> >> >> Also, I guess it is also worth mentioning.. when it comes to vblank,
> >> >> there are two fundamentally different sorts of displays we deal
with.
> >> >> Something like DVI/HDMI/etc which need constant refreshing. ?In
> these
> >> >> cases we constantly scan-out the buffer until the next page
> >> >> flip+vsync. ?And smart panels, where they get scanned out once and
> >> >> then DSS is no longer reading the scanout buffer until we manually
> >> >> trigger an update.
> >> >>
> >> >
> >> > Is the Smart panel CPU interface based lcd panel that has its own
> >> > framebuffer internally.?
> >>
> >> yes
> >>
> >
> > CPU Interface based lcd panel needs manual updating once all contents of
> > internal framebuffer are transferred to panel. thus, the Smart Panel(cpu
> > interface based lcd panel) has advantage of power consumption with
> > user-requested update. this means application should trigger display
> > controller to be transferred to lcd panel at framedone signal of lcd
> panel
> > because only the application is aware of this moment. this way would be
> > getting confused, especially on general os, such as linux system, based
> > platform so in case of using Smart Panel, I think we should make the
> panel
> > driver to be worked like RGB interface.
> >
> > - framedone interrupt handler of the panel should be placed in the
> driver.
> > - at booting time, display controller driver triggers just one time
> > - the panel driver triggers every time framedone interrupt handler is
> > called.
> >
> > and the order above would be repeated like RGB interface. thus I

Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 12:21 PM, Tomi Valkeinen  
wrote:
> On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen > ti.com> wrote:
>>
>> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> > the plan is to make DRM the core Linux display framework, upon which
>> > everything else is built, and fb and v4l2 are changed to use DRM.
>>
>> I'd like to think we could make DRM the underlying display framework;
>> it already exposes an fb interface, and with overlays, a bit more of the
>> v4l2 stuff is done as well. Certainly eliminating three copies of mode
>> setting infrastructure would be nice...
>
> Ok, sounds good to me. We (as in OMAP display people) are already
> planning to take DRM into use, so no problem there.
>
>> > But even if it was done like that, I see that it's combining two
>> > separate things: 1) the lower level HW control, and 2) the upper level
>> > buffer management, policies and userspace interfaces.
>>
>> Those are split between the DRM layer and the underlying device driver,
>> which provides both kernel (via fb) and user space interfaces.
>
> I'm not so familiar with DRM, but with device driver you mean a driver
> for the the hardware which handles display output (gfx cards or whatever
> it is on that platform)?

I think he is more referring to the DRM core and the individual device drivers..

We are (AFAIK) unique in having a two layer driver, where the DRM part
is more of a wrapper (for the KMS parts)... but I see that as more of
a transition thing.. eventually we should be able to merge it all into
the DRM layer.

> If so, it sounds good. That quite well matches what omapdss driver does
> currently for us. But we still have semi-complex omapdrm between omapdss
> and the standard drm layer.
>
> Rob, would you say omapdrm is more of a DRM wrapper for omapdss than a
> real separate entity? If so, then we could possibly in the future (when
> nobody else uses omapdss) change omapdss to support DRM natively. (or
> make omapdrm support omap HW natively, which ever way =).

Yeah, I think eventually it would make sense to merge all into one.
Although I'm not sure about how best to handle various different
custom DSI panels..

BR,
-R


>> > 2) It's missing the panel driver part. This is rather important on
>> > embedded systems, as the panels often are not "dummy" panels, but they
>> > need things like custom initialization, sending commands to adjust
>> > backlight, etc.
>>
>> We integrate the panel (and other video output) drivers into the device
>> drivers. With desktop chips, they're not easily separable. None of the
>> desktop output drivers are simple; things like DisplayPort require link
>> training, and everyone needs EDID. We share some of that code in the DRM
>> layer today, and it would be nice to share even more.
>
> I don't think we speak of similar panel drivers. I think there are two
> different drivers here:
>
> 1) output drivers, handles the output from the SoC / gfx card. For
> example DVI, DisplayPort, MIPI DPI/DBI/DSI.
>
> 2) panel drivers, handles panel specific things. Each panel may support
> custom commands and features, for which we need a dedicated driver. And
> this driver is not platform specific, but should work with any platform
> which has the output used with the panel.
>
> As an example, DSI command mode displays can be quite complex:
>
> DSI bus is a half-duplex serial bus, and while it's designed for
> displays you could use it easily for any communication between the SoC
> and the peripheral.
>
> The panel could have a feature like content adaptive backlight control,
> and this would be configured via the DSI bus, sending a particular
> command to the panel (possibly by first reading something from the
> panel). The panel driver would accomplish this more or less the same way
> one uses, say, i2c, so it would use the platform's DSI support to send
> and receive packets.
>
> Or a more complex scenario (but still a realistic scenario, been there,
> done that) is sending the image to the panel in multiple parts, and
> between each part sending configuration commands to the panel. (and
> still getting it done in time so we avoid tearing).
>
> And to complicate things more, there are DSI bus features like LP mode
> (low power, basically low speed mode) and HS mode (high speed), virtual
> channel IDs, and whatnot, which each panel may need to be used in
> particular manner. Some panels may require initial configuration done in
> LP, or configuration commands sent to a certain virtual channel ID.
>
> The point is that we cannot have standard "MIPI DSI command mode panel
> driver" which would work for all DSI cmd mode panels, but we need (in
> the worst case) separate driver for each panel.
>
> The same goes to lesser extent for other panels also. Some are
> configured via i2c or spi.
>
> ?Tomi
>
>
> ___
> dri-devel mailing list
> dri-devel at l

Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 17:12:43 +, Florian Tobias Schandinat 
 wrote:

> Interesting that this comes from the people that pushed the latest mode 
> setting
> code into the kernel. But I don't think that this will happen, the exposed 
> user
> interfaces will be around for decades and the infrastructure code could be
> shared, in theory.

We moved mode setting code from user space to kernel space -- the DRM
stuff comes directly from X, which has a fairly long history of
complicated display environments.

The DRM code does expose fb interfaces to both kernel and user mode,
figuring out how to integrate v4l2 and drm seems like the remaining
challenge.

> For fb and V4L2 I think we'll develop some level of interoperability, share
> concepts and maybe even some code. The FOURCC pixel formats and overlays are
> such examples. As Laurent is really interested in it I think we can get some
> nice progress here.

Jesse's design for the DRM overlay code will expose the pixel formats as
FOURCC codes so that DRM and v4l2 can interoperate -- we've got a lot of
hardware that has both video decode and 3D acceleration, so those are
going to get integrated somehow. And, we have to figure out how to share
buffers between these APIs to avoid copying data with the CPU.

DRM provides fb interfaces, so you don't need to change fb at all --
hardware that requires the capabilities provided by DRM will use that
and not use any of the other fb code in the kernel.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/8e86dad1/attachment.pgp>

[PATCH] io-mapping: ensure io_mapping_map_atomic _is_ atomic

2011-09-15 Thread Daniel Vetter

For the !HAVE_ATOMIC_IOMAP case the stub functions did not call
pagefault_disable/_enable. The i915 driver relies on the map
actually being atomic, otherwise it can deadlock with it's own
pagefault handler in the gtt pwrite fastpath.

This is exercised by gem_mmap_gtt from the intel-gpu-toosl gem
testsuite.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38115
Cc: sta...@kernel.org
Signed-off-by: Daniel Vetter 
---
 include/linux/io-mapping.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index 8cdcc2a1..6b3bef1 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -138,12 +138,14 @@ static inline void __iomem *
 io_mapping_map_atomic_wc(struct io_mapping *mapping,
 unsigned long offset)
 {
+   pagefault_disable();
return ((char __force __iomem *) mapping) + offset;
 }
 
 static inline void
 io_mapping_unmap_atomic(void __iomem *vaddr)
 {
+   pagefault_enable();
 }
 
 /* Non-atomic map/unmap */
-- 
1.7.6

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

Re: Proposal for a low-level Linux display framework

On 09/15/2011 07:05 PM, Alan Cox wrote:
>> What is your problem with discontigous framebuffers? (I assume discontigous
>> refers to the pages the framebuffer is composed of)
>> Sounds to me like you should implement your own fb_mmap and either map it
>> contigous to screen_base or implement your own fb_read/write.
>> In theory you could even have each pixel at a completely different memory
>> location although some userspace wouldn't be happy when it could no longer 
>> mmap
>> the framebuffer.
> 
> The mmap side is trivial, the problem is that the fb layer default
> implementations of blits, fills etc only work on a kernel linear frame
> buffer. And (for example) there is not enough linear stolen memory on
> some Intel video for a 1080p console on HDMI even though the hardware is
> perfectly capable of using an HDTV as its monitor. Nor - on a 32bit box-
> is there enough space to vremap it.

Okay, I see your problem. It's a bit strange you don't have acceleration. I
guess you need either your own implementation of those or adding function
pointers like fb_read/write just without the __user and use those instead of
direct memory access in the cfb* implementation if screen_base is NULL. Does not
sound like a big problem to me, but pretty inefficient, so probably copying the
existing ones and adjusting it to your needs would be preferred (just like the
sys* implementations exist).

Best regards,

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

Re: Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 3:18 PM, Florian Tobias Schandinat
 wrote:
> On 09/15/2011 06:58 PM, Alan Cox wrote:
>>> Well, I rather think that the fb API is more user centric to allow every 
>>> program
>>> to use it directly in contrast to the KMS/DRM API which aims to support 
>>> every
>>> feature the hardware has. For this the fb API should not change much, but I
>>> understand some additions were needed for some special users, probably 
>>> limited
>>> to X and wayland.
>>
>> Wayland needs vblank frame buffer switching and the like. Likewise given
>> you want to composite buffers really any serious accelerated device ends
>> up needing a full memory manager and that ends up needing a buffer
>> manager. Wayland needs clients to be doing their own rendering into
>> objects which means authorisation and management of the render engine
>> which ends up looking much like DRM.
>
> As you have DRM now and as I'm not interested in wayland I won't discuss this,
> but I guess it might be a good start for Geert's question what would be needed
> to use it on dumb framebuffers.
>
>>> One of my biggest problems with KMS is that it has (naturally) a lot more
>>> complexity than the fb API which leads to instability. Basically it's very
>>
>> It shouldn't do - and a sample of one (your machine) is not a
>> statistically valid set. Fb is pretty much ununsable in contrast on my
>> main box, but that's not a statistically valid sample either.
>>
>> I'm not that convinced by the complexity either. For a simple video card
>> setup such as those that the fb layer can kind of cope with (ie linear
>> buffer, simple mode changes, no client rendering, no vblank flipping,
>> limited mode management, no serious multi-head) a DRM driver is also
>> pretty tiny and simple.
>
> Yes, if you limit DRM to the functionality of the fb API I guess you could 
> reach
> the same stability level. But where can I do this? Where is a option to forbid
> all acceleration or at least limit to the acceleration that can be done 
> without
> any risk?

Right now most of the KMS DRM drivers do not support accelerated fb,
so as long as you don't run accelerated X or a 3D app, it should be
just as stable as an fb driver.  You may run into modesetting fail in
certain cases due to wonky hardware or driver bugs, but you will hit
that with an fb driver as well.

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

Re: Proposal for a low-level Linux display framework

> As you have DRM now and as I'm not interested in wayland I won't discuss this,
> but I guess it might be a good start for Geert's question what would be needed
> to use it on dumb framebuffers.

GMA500 is basically a 2D or dumb frame buffer setup but with a lot of
rather complicated output and memory management required due to the
hardware. With the latest changes to GEM (private objects) it's basically
trivial to use the frame buffer management interfaces.

> Yes, if you limit DRM to the functionality of the fb API I guess you could 
> reach
> the same stability level. But where can I do this? Where is a option to forbid
> all acceleration or at least limit to the acceleration that can be done 
> without
> any risk?

A driver can provide such module options as it wants.

> That's a really difficult question. Determining the users is difficult and 
> there
> are people that use their hardware very long, for example we are about to get 
> a
> new driver for i740. For the framebuffer infrastructure I guess you have to at
> least wait for my death.

I doubt it'll be that long - but you are right it will take time and
there isn't really any need to push or force it. These things take care
of themselves and in time nobody will care about the old fb stuff, either
because DRM covers it all or equally possibly because it doesn't support
3D holographic projection 8)

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

Re: Proposal for a low-level Linux display framework

On 09/15/2011 06:58 PM, Alan Cox wrote:
>> Well, I rather think that the fb API is more user centric to allow every 
>> program
>> to use it directly in contrast to the KMS/DRM API which aims to support every
>> feature the hardware has. For this the fb API should not change much, but I
>> understand some additions were needed for some special users, probably 
>> limited
>> to X and wayland.
> 
> Wayland needs vblank frame buffer switching and the like. Likewise given
> you want to composite buffers really any serious accelerated device ends
> up needing a full memory manager and that ends up needing a buffer
> manager. Wayland needs clients to be doing their own rendering into
> objects which means authorisation and management of the render engine
> which ends up looking much like DRM.

As you have DRM now and as I'm not interested in wayland I won't discuss this,
but I guess it might be a good start for Geert's question what would be needed
to use it on dumb framebuffers.

>> One of my biggest problems with KMS is that it has (naturally) a lot more
>> complexity than the fb API which leads to instability. Basically it's very
> 
> It shouldn't do - and a sample of one (your machine) is not a
> statistically valid set. Fb is pretty much ununsable in contrast on my
> main box, but that's not a statistically valid sample either.
> 
> I'm not that convinced by the complexity either. For a simple video card
> setup such as those that the fb layer can kind of cope with (ie linear
> buffer, simple mode changes, no client rendering, no vblank flipping,
> limited mode management, no serious multi-head) a DRM driver is also
> pretty tiny and simple.

Yes, if you limit DRM to the functionality of the fb API I guess you could reach
the same stability level. But where can I do this? Where is a option to forbid
all acceleration or at least limit to the acceleration that can be done without
any risk?

>> Well, I think it's too late to really fix this thing. We now have 3 APIs in 
>> the
>> kernel that have to be kept. Probably the best we can do now is figure out 
>> how
>> we can reduce code duplication and do extensions to those APIs in a way that
>> they are compatible with each other or completely independent and can be used
>> across the APIs.
> 
> I think it comes down to 'when nobody is using the old fb drivers they can
> drop into staging and oblivion'. Right now the fb layer is essentially
> compatibility glue on most modern x86 platforms.

That's a really difficult question. Determining the users is difficult and there
are people that use their hardware very long, for example we are about to get a
new driver for i740. For the framebuffer infrastructure I guess you have to at
least wait for my death.


Regards,

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

[Bug 32326] [R200] DRM version check only looks at minor number.

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

--- Comment #6 from Matt Turner  2011-09-15 12:12:36 PDT ---
(In reply to comment #5)
> Created an attachment (id=41039)
 View: https://bugs.freedesktop.org/attachment.cgi?id=41039
 Review: https://bugs.freedesktop.org/review?bug=32326&attachment=41039

> [PATCH] Don't even consider enabling microtiling unless DRM major version is 
> 1.
> 
> If DRM v2.x doesn't support microtiling on R200 yet then the DRM version check
> in Mesa is no longer adequate.

Did you read/understand Dave's previous comment?

-- 
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

[Bug 32326] [R200] DRM version check only looks at minor number.

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

--- Comment #6 from Matt Turner  2011-09-15 12:12:36 PDT 
---
(In reply to comment #5)
> Created an attachment (id=41039)
 View: https://bugs.freedesktop.org/attachment.cgi?id=41039
 Review: https://bugs.freedesktop.org/review?bug=32326&attachment=41039

> [PATCH] Don't even consider enabling microtiling unless DRM major version is 
> 1.
> 
> If DRM v2.x doesn't support microtiling on R200 yet then the DRM version check
> in Mesa is no longer adequate.

Did you read/understand Dave's previous comment?

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

[Bug 22030] r200: Texture loads fail randomly

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

--- Comment #5 from Matt Turner  2011-09-15 12:10:31 PDT ---
Have you had access to that computer again any time in the last two years? :)

-- 
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

[Bug 22030] r200: Texture loads fail randomly

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

--- Comment #5 from Matt Turner  2011-09-15 12:10:31 PDT 
---
Have you had access to that computer again any time in the last two years? :)

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

Re: Proposal for a low-level Linux display framework

> What is your problem with discontigous framebuffers? (I assume discontigous
> refers to the pages the framebuffer is composed of)
> Sounds to me like you should implement your own fb_mmap and either map it
> contigous to screen_base or implement your own fb_read/write.
> In theory you could even have each pixel at a completely different memory
> location although some userspace wouldn't be happy when it could no longer 
> mmap
> the framebuffer.

The mmap side is trivial, the problem is that the fb layer default
implementations of blits, fills etc only work on a kernel linear frame
buffer. And (for example) there is not enough linear stolen memory on
some Intel video for a 1080p console on HDMI even though the hardware is
perfectly capable of using an HDTV as its monitor. Nor - on a 32bit box-
is there enough space to vremap it.

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

Re: Proposal for a low-level Linux display framework

> Well, I rather think that the fb API is more user centric to allow every 
> program
> to use it directly in contrast to the KMS/DRM API which aims to support every
> feature the hardware has. For this the fb API should not change much, but I
> understand some additions were needed for some special users, probably limited
> to X and wayland.

Wayland needs vblank frame buffer switching and the like. Likewise given
you want to composite buffers really any serious accelerated device ends
up needing a full memory manager and that ends up needing a buffer
manager. Wayland needs clients to be doing their own rendering into
objects which means authorisation and management of the render engine
which ends up looking much like DRM.

> One of my biggest problems with KMS is that it has (naturally) a lot more
> complexity than the fb API which leads to instability. Basically it's very

It shouldn't do - and a sample of one (your machine) is not a
statistically valid set. Fb is pretty much ununsable in contrast on my
main box, but that's not a statistically valid sample either.

I'm not that convinced by the complexity either. For a simple video card
setup such as those that the fb layer can kind of cope with (ie linear
buffer, simple mode changes, no client rendering, no vblank flipping,
limited mode management, no serious multi-head) a DRM driver is also
pretty tiny and simple.

> Well, I think it's too late to really fix this thing. We now have 3 APIs in 
> the
> kernel that have to be kept. Probably the best we can do now is figure out how
> we can reduce code duplication and do extensions to those APIs in a way that
> they are compatible with each other or completely independent and can be used
> across the APIs.

I think it comes down to 'when nobody is using the old fb drivers they can
drop into staging and oblivion'. Right now the fb layer is essentially
compatibility glue on most modern x86 platforms.

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

Re: Proposal for a low-level Linux display framework

On 09/15/2011 05:52 PM, Alex Deucher wrote:
> On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat
>  wrote:
>> On 09/15/2011 03:50 PM, Keith Packard wrote:
>>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen  
>>> wrote:
>>>
 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
 the plan is to make DRM the core Linux display framework, upon which
 everything else is built, and fb and v4l2 are changed to use DRM.
>>>
>>> I'd like to think we could make DRM the underlying display framework;
>>> it already exposes an fb interface, and with overlays, a bit more of the
>>> v4l2 stuff is done as well. Certainly eliminating three copies of mode
>>> setting infrastructure would be nice...
>>
>> Interesting that this comes from the people that pushed the latest mode 
>> setting
>> code into the kernel. But I don't think that this will happen, the exposed 
>> user
>> interfaces will be around for decades and the infrastructure code could be
>> shared, in theory.
>> For fb and V4L2 I think we'll develop some level of interoperability, share
>> concepts and maybe even some code. The FOURCC pixel formats and overlays are
>> such examples. As Laurent is really interested in it I think we can get some
>> nice progress here.
>> For fb and DRM the situation is entirely different. The last proposal I 
>> remember
>> ended in the DRM people stating that only their implementation is acceptable 
>> as
>> is and we could use it. Such attitude is not helpful and as I don't see any
>> serious intention of the DRM guys to cooperate I think those subsystems are 
>> more
>> likely to diverge. At least I'll never accept any change to the fb
>> infrastructure that requires DRM.
> 
> Not exactly.  This point was that the drm modesetting and EDID
> handling was derived from X which has had 20+ years of of quirks and
> things added to it to deal with tons of wonky monitors and such.  That
> information should be preserved.  As mode structs and EDID handling
> are pretty self contained, why not use the DRM variants of that code
> rather than writing a new version?

Well, I'm not against sharing the code and not against taking DRM's current
implementation as a base but the steps required to make it generally acceptable
would be to split it of, probably as a standalone module and strip all DRM
specific things off. Than all things that require EDID can use it, DRM can add
DRM-specific things on top and fb can add fb-specific things.

> While the DRM has historically targeted 3D acceleration, that is not a
> requirement to use the DRM KMS modesetting API.  The current fb API
> has no concept of display controllers or connectors or overlays, etc.
> To match it to modern hardware, it needs a major overhaul.  Why create
> a new modern fb interface that's largely the same as DRM KMS?  What if
> we just consider the KMS API as the new fb API?  If there are any
> inadequacies in the DRM KMS API we would be happy to work out any
> changes.

Well, I rather think that the fb API is more user centric to allow every program
to use it directly in contrast to the KMS/DRM API which aims to support every
feature the hardware has. For this the fb API should not change much, but I
understand some additions were needed for some special users, probably limited
to X and wayland.
One of my biggest problems with KMS is that it has (naturally) a lot more
complexity than the fb API which leads to instability. Basically it's very
difficult to implement a framebuffer in a way that it crashes your machine
during operation which is quite a contrast to my KMS/DRM experience on my toy
(on my work machines I use framebuffer only). And I really hate it when I have
to type my passwords again just because the KMS/DRM thing allowed a program to
crash my machine. Yes, those are driver bugs but the API encourages them and I
did not yet find the feature/config option DOES_NOT_CRASH or SLOW_BUT_STABLE.
And as I said already, I think the fb API is a lot better for direct interaction
with userspace programs and certainly has more direct users at the moment.

> Please don't claim that the DRM developers do not want to cooperate.
> I realize that people have strong opinions about existing APIs, put
> there has been just as much, if not more obstinacy from the v4l and fb
> people.

Well, I think it's too late to really fix this thing. We now have 3 APIs in the
kernel that have to be kept. Probably the best we can do now is figure out how
we can reduce code duplication and do extensions to those APIs in a way that
they are compatible with each other or completely independent and can be used
across the APIs.

Best regards,

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

Re: Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 12:21 PM, Tomi Valkeinen  wrote:
> On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen  
>> wrote:
>>
>> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> > the plan is to make DRM the core Linux display framework, upon which
>> > everything else is built, and fb and v4l2 are changed to use DRM.
>>
>> I'd like to think we could make DRM the underlying display framework;
>> it already exposes an fb interface, and with overlays, a bit more of the
>> v4l2 stuff is done as well. Certainly eliminating three copies of mode
>> setting infrastructure would be nice...
>
> Ok, sounds good to me. We (as in OMAP display people) are already
> planning to take DRM into use, so no problem there.
>
>> > But even if it was done like that, I see that it's combining two
>> > separate things: 1) the lower level HW control, and 2) the upper level
>> > buffer management, policies and userspace interfaces.
>>
>> Those are split between the DRM layer and the underlying device driver,
>> which provides both kernel (via fb) and user space interfaces.
>
> I'm not so familiar with DRM, but with device driver you mean a driver
> for the the hardware which handles display output (gfx cards or whatever
> it is on that platform)?

I think he is more referring to the DRM core and the individual device drivers..

We are (AFAIK) unique in having a two layer driver, where the DRM part
is more of a wrapper (for the KMS parts)... but I see that as more of
a transition thing.. eventually we should be able to merge it all into
the DRM layer.

> If so, it sounds good. That quite well matches what omapdss driver does
> currently for us. But we still have semi-complex omapdrm between omapdss
> and the standard drm layer.
>
> Rob, would you say omapdrm is more of a DRM wrapper for omapdss than a
> real separate entity? If so, then we could possibly in the future (when
> nobody else uses omapdss) change omapdss to support DRM natively. (or
> make omapdrm support omap HW natively, which ever way =).

Yeah, I think eventually it would make sense to merge all into one.
Although I'm not sure about how best to handle various different
custom DSI panels..

BR,
-R


>> > 2) It's missing the panel driver part. This is rather important on
>> > embedded systems, as the panels often are not "dummy" panels, but they
>> > need things like custom initialization, sending commands to adjust
>> > backlight, etc.
>>
>> We integrate the panel (and other video output) drivers into the device
>> drivers. With desktop chips, they're not easily separable. None of the
>> desktop output drivers are simple; things like DisplayPort require link
>> training, and everyone needs EDID. We share some of that code in the DRM
>> layer today, and it would be nice to share even more.
>
> I don't think we speak of similar panel drivers. I think there are two
> different drivers here:
>
> 1) output drivers, handles the output from the SoC / gfx card. For
> example DVI, DisplayPort, MIPI DPI/DBI/DSI.
>
> 2) panel drivers, handles panel specific things. Each panel may support
> custom commands and features, for which we need a dedicated driver. And
> this driver is not platform specific, but should work with any platform
> which has the output used with the panel.
>
> As an example, DSI command mode displays can be quite complex:
>
> DSI bus is a half-duplex serial bus, and while it's designed for
> displays you could use it easily for any communication between the SoC
> and the peripheral.
>
> The panel could have a feature like content adaptive backlight control,
> and this would be configured via the DSI bus, sending a particular
> command to the panel (possibly by first reading something from the
> panel). The panel driver would accomplish this more or less the same way
> one uses, say, i2c, so it would use the platform's DSI support to send
> and receive packets.
>
> Or a more complex scenario (but still a realistic scenario, been there,
> done that) is sending the image to the panel in multiple parts, and
> between each part sending configuration commands to the panel. (and
> still getting it done in time so we avoid tearing).
>
> And to complicate things more, there are DSI bus features like LP mode
> (low power, basically low speed mode) and HS mode (high speed), virtual
> channel IDs, and whatnot, which each panel may need to be used in
> particular manner. Some panels may require initial configuration done in
> LP, or configuration commands sent to a certain virtual channel ID.
>
> The point is that we cannot have standard "MIPI DSI command mode panel
> driver" which would work for all DSI cmd mode panels, but we need (in
> the worst case) separate driver for each panel.
>
> The same goes to lesser extent for other panels also. Some are
> configured via i2c or spi.
>
>  Tomi
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.free

Re: Proposal for a low-level Linux display framework

2011-09-15 Thread Kyungmin Park

Hi Tomi,

On Thu, Sep 15, 2011 at 9:07 PM, Tomi Valkeinen  wrote:
> Hi,
>
> I am the author of OMAP display driver, and while developing it I've
> often felt that there's something missing in Linux's display area. I've
> been planning to write a post about this for a few years already, but I
> never got to it. So here goes at last!
>
> ---
>
> First I want to (try to) describe shortly what we have on OMAP, to give
> a bit of a background for my point of view, and to have an example HW.
>
> The display subsystem (DSS) hardware on OMAP handles only showing pixels
> on a display, so it doesn't contain anything that produces pixels like
> 3D stuff or accelerated copying. All it does is fetch pixels from SDRAM,
> possibly do some modifications for them (color format conversions etc),
> and output them to a display.
>
> The hardware has multiple overlays, which are like hardware windows.
> They fetch pixels from SDRAM, and output them in a certain area on the
> display (possibly with scaling). Multiple overlays can be composited
> into one output.
>
> So we may have something like this, when all overlays read pixels from
> separate areas in the memory, and all overlays are on LCD display:
>
>  .-.         .--.           .--.
>  | mem |>| ovl0 |-.>| LCD  |
>  '-'         '--'     |     '--'
>  .-.         .--.     |
>  | mem |>| ovl1 |-|
>  '-'         '--'     |
>  .-.         .--.     |     .--.
>  | mem |>| ovl2 |-'     |  TV  |
>  '-'         '--'           '--'
>
Same feature at samsung display subsystem.

> The LCD display can be rather simple one, like a standard monitor or a
> simple panel directly connected to parallel RGB output, or a more
> complex one. A complex panel needs something else than just
> turn-it-on-and-go. This may involve sending and receiving messages
> between OMAP and the panel, but more generally, there's need to have
> custom code that handles the particular panel. And the complex panel is
> not necessarily a panel at all, it may be a buffer chip between OMAP and
> the actual panel.
>
> The software side can be divided into three parts: the lower level
> omapdss driver, the lower level panel drivers, and higher level drivers
> like omapfb, v4l2 and omapdrm.

Current omapdrm codes use the omapfb and omapdss codes even though
omapdrm is located drivers/staging, some time later it should be
drivers/gpu/gem/omap. but it still uses the drivers/video/omap2/dss
codes.
In case of samsung DRM, it has almost similar codes for lowlevel
access from the drivers/video/s3c-fb.c for FIMD and
drivers/media/video/s5p-tv for HDMI.


>
> The omapdss driver handles the OMAP DSS hardware, and offers a kernel
> internal API which the higher level drivers use. The omapdss does not
> know anything about fb or drm, it just offers core display services.
>
> The panel drivers handle particular panels/chips. The panel driver may
> be very simple in case of a conventional display, basically doing pretty
> much nothing, or bigger piece of code, handling communication with the
> panel.
>
> The higher level drivers handle buffers and tell omapdss things like
> where to find the pixels, what size the overlays should be, and use the
> omapdss API to turn displays on/off, etc.
>
> ---
>
> There are two things that I'm proposing to improve the Linux display
> support:
>
> First, there should be a bunch of common video structs and helpers that
> are independent of any higher level framework. Things like video
> timings, mode databases, and EDID seem to be implemented multiple times
> in the kernel. But there shouldn't be anything in those things that
> depend on any particular display framework, so they could be implemented
> just once and all the frameworks could use them.
>
> Second, I think there could be use for a common low level display
> framework. Currently the lower level code (display HW handling, etc.)
> and higher level code (buffer management, policies, etc) seem to be
> usually tied together, like the fb framework or the drm. Granted, the
> frameworks do not force that, and for OMAP we indeed have omapfb and
> omapdrm using the lower level omapdss. But I don't see that it's
> anything OMAP specific as such.

So I suggest the create the drivers/graphics for lowlevel codes and
each framework, DRM, V4L2 and FB uses these lowlevel codes.

Thank you,
Kyungmin Park
>
> I think the lower level framework could have components something like
> this (the naming is OMAP oriented, of course):
>
> overlay - a hardware "window", gets pixels from memory, possibly does
> format conversions, scaling, etc.
>
> overlay compositor - composes multiple overlays into one output,
> possibly doing things like translucency.
>
> output - gets the pixels from overlay compositor, and sends them out
> according to particular video timings when using conventional video
> interface, or via any other mean when using non-conventional vid

Re: [REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

Keith Packard, le Thu 15 Sep 2011 00:43:36 -0500, a écrit :
> On Thu, 15 Sep 2011 01:27:17 +0200, Samuel Thibault 
>  wrote:
> Non-text part: multipart/mixed
> > Hello,
> > 
> > I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
> > E6420, but dual head is broken. Here is the scenario:
> > 
> > - Turn computer on with VGA1 connected. Both LVDS1 and VGA1 show the
> >   text console fine.
> > - Start X. VGA1 shows X fine, but LVDS1 (1600x900 resolution) shows an
> >   odd screen: completely black on the left part (about 1060x900), sort
> >   of gray on the right part (about 540x900). Playing with xrandr doesn't
> >   help, I can at best make it completely black with --off, and not get
> >   it back again with --auto or anything else.
> 
> Can you try disabling frame buffer compression?
> 
> i915.i915_enable-fbc=0
> 
> I'm about to send a patch to disable this by default; I've gotten two
> people saying that this helps them already.

Absolutely. I have no issue any more, and the error messages are gone.

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

[PATCH 1/2] drm/radeon: Make sure CS mutex is held across GPU reset.

From: Michel Dänzer 

This was only the case if the GPU reset was triggered from the CS ioctl,
otherwise other processes could happily enter the CS ioctl and wreak havoc
during the GPU reset.

This is a little complicated because the GPU reset can be triggered from the
CS ioctl, in which case we're already holding the mutex, or from other call
paths, in which case we need to lock the mutex. AFAICT the mutex API doesn't
allow nested locking or finding out the mutex owner, so we need to handle this
with some helper functions.

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon.h|   60 
 drivers/gpu/drm/radeon/radeon_cs.c |   14 
 drivers/gpu/drm/radeon/radeon_device.c |   16 
 3 files changed, 83 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ef0e0e0..89304d9 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1203,6 +1203,8 @@ struct radeon_device {
struct radeon_pmpm;
uint32_tbios_scratch[RADEON_BIOS_NUM_SCRATCH];
struct mutexcs_mutex;
+   struct task_struct  *cs_mutex_owner;
+   struct mutexcs_mutex_owner_mutex;
struct radeon_wbwb;
struct radeon_dummy_pagedummy_page;
boolgpu_lockup;
@@ -1241,6 +1243,64 @@ struct radeon_device {
struct radeon_i2c_chan *i2c_bus[RADEON_MAX_I2C_BUS];
 };
 
+
+/*
+ * CS mutex helpers
+ */
+
+static inline void cs_mutex_lock(struct radeon_device *rdev)
+{
+   mutex_lock(&rdev->cs_mutex);
+
+   mutex_lock(&rdev->cs_mutex_owner_mutex);
+   rdev->cs_mutex_owner = current;
+   mutex_unlock(&rdev->cs_mutex_owner_mutex);
+}
+
+static inline void cs_mutex_unlock(struct radeon_device *rdev)
+{
+   mutex_lock(&rdev->cs_mutex_owner_mutex);
+   rdev->cs_mutex_owner = NULL;
+   mutex_unlock(&rdev->cs_mutex_owner_mutex);
+
+   mutex_unlock(&rdev->cs_mutex);
+}
+
+/*
+ * Check if this process locked the CS mutex already; if it didn't, lock it.
+ *
+ * Returns:
+ * true: This function locked the mutex.
+ * false: This function didn't lock the mutex (this process already locked it
+ * before), so the caller probably shouldn't unlock it.
+ */
+static inline int cs_mutex_ensure_locked(struct radeon_device *rdev)
+{
+   int took_mutex;
+   int have_mutex;
+
+   mutex_lock(&rdev->cs_mutex_owner_mutex);
+   took_mutex = mutex_trylock(&rdev->cs_mutex);
+   if (took_mutex) {
+   /* The mutex was unlocked before, so it's ours now */
+   rdev->cs_mutex_owner = current;
+   have_mutex = true;
+   } else {
+   /* Somebody already locked the mutex. Was it this process? */
+   have_mutex = (rdev->cs_mutex_owner == current);
+   }
+   mutex_unlock(&rdev->cs_mutex_owner_mutex);
+
+   if (!have_mutex) {
+   /* Another process locked the mutex, take it */
+   cs_mutex_lock(rdev);
+   took_mutex = true;
+   }
+
+   return took_mutex;
+}
+
+
 int radeon_device_init(struct radeon_device *rdev,
   struct drm_device *ddev,
   struct pci_dev *pdev,
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index fae00c0..61e3063 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -222,7 +222,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
struct radeon_cs_chunk *ib_chunk;
int r;
 
-   mutex_lock(&rdev->cs_mutex);
+   cs_mutex_lock(rdev);
/* initialize parser */
memset(&parser, 0, sizeof(struct radeon_cs_parser));
parser.filp = filp;
@@ -233,14 +233,14 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
if (r) {
DRM_ERROR("Failed to initialize parser !\n");
radeon_cs_parser_fini(&parser, r);
-   mutex_unlock(&rdev->cs_mutex);
+   cs_mutex_unlock(rdev);
return r;
}
r =  radeon_ib_get(rdev, &parser.ib);
if (r) {
DRM_ERROR("Failed to get ib !\n");
radeon_cs_parser_fini(&parser, r);
-   mutex_unlock(&rdev->cs_mutex);
+   cs_mutex_unlock(rdev);
return r;
}
r = radeon_cs_parser_relocs(&parser);
@@ -248,7 +248,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
if (r != -ERESTARTSYS)
DRM_ERROR("Failed to parse relocation %d!\n", r);
radeon_cs_parser_fini(&parser, r);
-   mutex_unlock(&rdev->cs_mutex);
+   cs_mutex_unlock(rdev);
return r;

[PATCH 2/2] drm/radeon: Hold the CS mutex across suspend/resume.

From: Michel Dänzer 


Signed-off-by: Michel Dänzer 
---

Not sure the CS ioctl can actually run concurrently with suspend/resume, but
might be better safe than sorry?

 drivers/gpu/drm/radeon/radeon_device.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 5f3d02d..80b4799 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -881,6 +881,10 @@ int radeon_suspend_kms(struct drm_device *dev, 
pm_message_t state)
}
}
}
+
+   /* Prevent CS ioctl from interfering */
+   cs_mutex_lock(rdev);
+
/* evict vram memory */
radeon_bo_evict_vram(rdev);
/* wait for gpu to finish processing current batch */
@@ -944,6 +948,9 @@ int radeon_resume_kms(struct drm_device *dev)
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
}
+
+   cs_mutex_unlock(rdev);
+
return 0;
 }
 
-- 
1.7.6.3

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

Re: Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 17:12:43 +, Florian Tobias Schandinat 
 wrote:

> Interesting that this comes from the people that pushed the latest mode 
> setting
> code into the kernel. But I don't think that this will happen, the exposed 
> user
> interfaces will be around for decades and the infrastructure code could be
> shared, in theory.

We moved mode setting code from user space to kernel space -- the DRM
stuff comes directly from X, which has a fairly long history of
complicated display environments.

The DRM code does expose fb interfaces to both kernel and user mode,
figuring out how to integrate v4l2 and drm seems like the remaining
challenge.

> For fb and V4L2 I think we'll develop some level of interoperability, share
> concepts and maybe even some code. The FOURCC pixel formats and overlays are
> such examples. As Laurent is really interested in it I think we can get some
> nice progress here.

Jesse's design for the DRM overlay code will expose the pixel formats as
FOURCC codes so that DRM and v4l2 can interoperate -- we've got a lot of
hardware that has both video decode and 3D acceleration, so those are
going to get integrated somehow. And, we have to figure out how to share
buffers between these APIs to avoid copying data with the CPU.

DRM provides fb interfaces, so you don't need to change fb at all --
hardware that requires the capabilities provided by DRM will use that
and not use any of the other fb code in the kernel.

-- 
keith.pack...@intel.com

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

Re: Proposal for a low-level Linux display framework

Wasn't there a driver for qemu cirrus "hardware"?

Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher"  wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
>  wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher 
wrote:
>>> While the DRM has historically targeted 3D acceleration, that is not a
>>> requirement to use the DRM KMS modesetting API.  The current fb API
>>> has no concept of display controllers or connectors or overlays, etc.
>>> To match it to modern hardware, it needs a major overhaul.  Why create
>>> a new modern fb interface that's largely the same as DRM KMS?  What if
>>> we just consider the KMS API as the new fb API?  If there are any
>>> inadequacies in the DRM KMS API we would be happy to work out any
>>> changes.
>>
>> I admit I didn't look for it, but does there exist a sample DRM KMS
driver
>> for dumb frame buffer hardware with one fixed video mode?
>
> Not at the moment. However, there drivers for AMD, Intel, and nvidia
> chips as well patches for a number of ARM SoCs that are in the process
> of moving upstream. Also, Matt Turner wrote a KMS driver for 3D labs
> glint hardware that is pretty simple (single display controller,
> single DAC, etc.), however it hasn't been merged upstream yet.
>
http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz&can=2&q=
> His kernel git tree was on kernel.org so it's down at the moment,
> hence the link to the tarball.
>
> Alex
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Proposal for a low-level Linux display framework

Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher"  wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
>  wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher 
wrote:
>>> While the DRM has historically targeted 3D acceleration, that is not a
>>> requirement to use the DRM KMS modesetting API.  The current fb API
>>> has no concept of display controllers or connectors or overlays, etc.
>>> To match it to modern hardware, it needs a major overhaul.  Why create
>>> a new modern fb interface that's largely the same as DRM KMS?  What if
>>> we just consider the KMS API as the new fb API?  If there are any
>>> inadequacies in the DRM KMS API we would be happy to work out any
>>> changes.
>>
>> I admit I didn't look for it, but does there exist a sample DRM KMS
driver
>> for dumb frame buffer hardware with one fixed video mode?
>
> Not at the moment. However, there drivers for AMD, Intel, and nvidia
> chips as well patches for a number of ARM SoCs that are in the process
> of moving upstream. Also, Matt Turner wrote a KMS driver for 3D labs
> glint hardware that is pretty simple (single display controller,
> single DAC, etc.), however it hasn't been merged upstream yet.
>
http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz&can=2&q=
> His kernel git tree was on kernel.org so it's down at the moment,
> hence the link to the tarball.
>
> Alex
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Proposal for a low-level Linux display framework

Wasn't there a driver for qemu cirrus "hardware"?

Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher"  wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
>  wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher 
wrote:
>>> While the DRM has historically targeted 3D acceleration, that is not a
>>> requirement to use the DRM KMS modesetting API.  The current fb API
>>> has no concept of display controllers or connectors or overlays, etc.
>>> To match it to modern hardware, it needs a major overhaul.  Why create
>>> a new modern fb interface that's largely the same as DRM KMS?  What if
>>> we just consider the KMS API as the new fb API?  If there are any
>>> inadequacies in the DRM KMS API we would be happy to work out any
>>> changes.
>>
>> I admit I didn't look for it, but does there exist a sample DRM KMS
driver
>> for dumb frame buffer hardware with one fixed video mode?
>
> Not at the moment. However, there drivers for AMD, Intel, and nvidia
> chips as well patches for a number of ARM SoCs that are in the process
> of moving upstream. Also, Matt Turner wrote a KMS driver for 3D labs
> glint hardware that is pretty simple (single display controller,
> single DAC, etc.), however it hasn't been merged upstream yet.
>
http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz&can=2&q=
> His kernel git tree was on kernel.org so it's down at the moment,
> hence the link to the tarball.
>
> Alex
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/10a16b54/attachment-0001.htm>

Proposal for a low-level Linux display framework

Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher"  wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
>  wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher 
wrote:
>>> While the DRM has historically targeted 3D acceleration, that is not a
>>> requirement to use the DRM KMS modesetting API.  The current fb API
>>> has no concept of display controllers or connectors or overlays, etc.
>>> To match it to modern hardware, it needs a major overhaul.  Why create
>>> a new modern fb interface that's largely the same as DRM KMS?  What if
>>> we just consider the KMS API as the new fb API?  If there are any
>>> inadequacies in the DRM KMS API we would be happy to work out any
>>> changes.
>>
>> I admit I didn't look for it, but does there exist a sample DRM KMS
driver
>> for dumb frame buffer hardware with one fixed video mode?
>
> Not at the moment. However, there drivers for AMD, Intel, and nvidia
> chips as well patches for a number of ARM SoCs that are in the process
> of moving upstream. Also, Matt Turner wrote a KMS driver for 3D labs
> glint hardware that is pretty simple (single display controller,
> single DAC, etc.), however it hasn't been merged upstream yet.
>
http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz&can=2&q=
> His kernel git tree was on kernel.org so it's down at the moment,
> hence the link to the tarball.
>
> Alex
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/55e6a43e/attachment.htm>

Re: Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
 wrote:
> On Thu, Sep 15, 2011 at 19:52, Alex Deucher  wrote:
>> While the DRM has historically targeted 3D acceleration, that is not a
>> requirement to use the DRM KMS modesetting API.  The current fb API
>> has no concept of display controllers or connectors or overlays, etc.
>> To match it to modern hardware, it needs a major overhaul.  Why create
>> a new modern fb interface that's largely the same as DRM KMS?  What if
>> we just consider the KMS API as the new fb API?  If there are any
>> inadequacies in the DRM KMS API we would be happy to work out any
>> changes.
>
> I admit I didn't look for it, but does there exist a sample DRM KMS driver
> for dumb frame buffer hardware with one fixed video mode?

Not at the moment.  However, there drivers for AMD, Intel, and nvidia
chips as well patches for a number of ARM SoCs that are in the process
of moving upstream.  Also, Matt Turner wrote a KMS driver for 3D labs
glint hardware that is pretty simple (single display controller,
single DAC, etc.), however it hasn't been merged upstream yet.
http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz&can=2&q=
His kernel git tree was on kernel.org so it's down at the moment,
hence the link to the tarball.

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

Re: Proposal for a low-level Linux display framework

2011-09-15 Thread Geert Uytterhoeven

On Thu, Sep 15, 2011 at 19:52, Alex Deucher  wrote:
> While the DRM has historically targeted 3D acceleration, that is not a
> requirement to use the DRM KMS modesetting API.  The current fb API
> has no concept of display controllers or connectors or overlays, etc.
> To match it to modern hardware, it needs a major overhaul.  Why create
> a new modern fb interface that's largely the same as DRM KMS?  What if
> we just consider the KMS API as the new fb API?  If there are any
> inadequacies in the DRM KMS API we would be happy to work out any
> changes.

I admit I didn't look for it, but does there exist a sample DRM KMS driver
for dumb frame buffer hardware with one fixed video mode?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Proposal for a low-level Linux display framework

On Thu, Sep 15, 2011 at 1:12 PM, Florian Tobias Schandinat
 wrote:
> On 09/15/2011 03:50 PM, Keith Packard wrote:
>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen  
>> wrote:
>>
>>> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>>> the plan is to make DRM the core Linux display framework, upon which
>>> everything else is built, and fb and v4l2 are changed to use DRM.
>>
>> I'd like to think we could make DRM the underlying display framework;
>> it already exposes an fb interface, and with overlays, a bit more of the
>> v4l2 stuff is done as well. Certainly eliminating three copies of mode
>> setting infrastructure would be nice...
>
> Interesting that this comes from the people that pushed the latest mode 
> setting
> code into the kernel. But I don't think that this will happen, the exposed 
> user
> interfaces will be around for decades and the infrastructure code could be
> shared, in theory.
> For fb and V4L2 I think we'll develop some level of interoperability, share
> concepts and maybe even some code. The FOURCC pixel formats and overlays are
> such examples. As Laurent is really interested in it I think we can get some
> nice progress here.
> For fb and DRM the situation is entirely different. The last proposal I 
> remember
> ended in the DRM people stating that only their implementation is acceptable 
> as
> is and we could use it. Such attitude is not helpful and as I don't see any
> serious intention of the DRM guys to cooperate I think those subsystems are 
> more
> likely to diverge. At least I'll never accept any change to the fb
> infrastructure that requires DRM.

Not exactly.  This point was that the drm modesetting and EDID
handling was derived from X which has had 20+ years of of quirks and
things added to it to deal with tons of wonky monitors and such.  That
information should be preserved.  As mode structs and EDID handling
are pretty self contained, why not use the DRM variants of that code
rather than writing a new version?

While the DRM has historically targeted 3D acceleration, that is not a
requirement to use the DRM KMS modesetting API.  The current fb API
has no concept of display controllers or connectors or overlays, etc.
To match it to modern hardware, it needs a major overhaul.  Why create
a new modern fb interface that's largely the same as DRM KMS?  What if
we just consider the KMS API as the new fb API?  If there are any
inadequacies in the DRM KMS API we would be happy to work out any
changes.

Please don't claim that the DRM developers do not want to cooperate.
I realize that people have strong opinions about existing APIs, put
there has been just as much, if not more obstinacy from the v4l and fb
people.

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

Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen  
wrote:

> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> the plan is to make DRM the core Linux display framework, upon which
> everything else is built, and fb and v4l2 are changed to use DRM.

I'd like to think we could make DRM the underlying display framework;
it already exposes an fb interface, and with overlays, a bit more of the
v4l2 stuff is done as well. Certainly eliminating three copies of mode
setting infrastructure would be nice...

> But even if it was done like that, I see that it's combining two
> separate things: 1) the lower level HW control, and 2) the upper level
> buffer management, policies and userspace interfaces.

Those are split between the DRM layer and the underlying device driver,
which provides both kernel (via fb) and user space interfaces.

> 2) It's missing the panel driver part. This is rather important on
> embedded systems, as the panels often are not "dummy" panels, but they
> need things like custom initialization, sending commands to adjust
> backlight, etc.

We integrate the panel (and other video output) drivers into the device
drivers. With desktop chips, they're not easily separable. None of the
desktop output drivers are simple; things like DisplayPort require link
training, and everyone needs EDID. We share some of that code in the DRM
layer today, and it would be nice to share even more.

We should figure out if the DRM interfaces are sufficient for your
needs; they're pretty flexible at this point.

Of course, backlight remains a mess in the desktop world; with many
custom backlight drivers along with generic ACPI and then
per-video-device drivers as well.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/99ece45c/attachment.pgp>

Re: Proposal for a low-level Linux display framework

Hi Alan,

On 09/15/2011 05:18 PM, Alan Cox wrote:
>> is and we could use it. Such attitude is not helpful and as I don't see any
>> serious intention of the DRM guys to cooperate I think those subsystems are 
>> more
>> likely to diverge. At least I'll never accept any change to the fb
>> infrastructure that requires DRM.
> 
> There are aspects of the fb code that want changing for DRM (and indeed
> modern hardware) but which won't break for other stuff. Given the move to
> using main memory for video and the need for the OS to do buffer
> management for framebuffers I suspect a move to DRM is pretty much
> inevitable, along with having to fix the fb layer to cope with
> discontiguous framebuffers.

What is your problem with discontigous framebuffers? (I assume discontigous
refers to the pages the framebuffer is composed of)
Sounds to me like you should implement your own fb_mmap and either map it
contigous to screen_base or implement your own fb_read/write.
In theory you could even have each pixel at a completely different memory
location although some userspace wouldn't be happy when it could no longer mmap
the framebuffer.

Best regards,

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

Re: Proposal for a low-level Linux display framework

On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen  
> wrote:
> 
> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > the plan is to make DRM the core Linux display framework, upon which
> > everything else is built, and fb and v4l2 are changed to use DRM.
> 
> I'd like to think we could make DRM the underlying display framework;
> it already exposes an fb interface, and with overlays, a bit more of the
> v4l2 stuff is done as well. Certainly eliminating three copies of mode
> setting infrastructure would be nice...

Ok, sounds good to me. We (as in OMAP display people) are already
planning to take DRM into use, so no problem there.

> > But even if it was done like that, I see that it's combining two
> > separate things: 1) the lower level HW control, and 2) the upper level
> > buffer management, policies and userspace interfaces.
> 
> Those are split between the DRM layer and the underlying device driver,
> which provides both kernel (via fb) and user space interfaces.

I'm not so familiar with DRM, but with device driver you mean a driver
for the the hardware which handles display output (gfx cards or whatever
it is on that platform)?

If so, it sounds good. That quite well matches what omapdss driver does
currently for us. But we still have semi-complex omapdrm between omapdss
and the standard drm layer.

Rob, would you say omapdrm is more of a DRM wrapper for omapdss than a
real separate entity? If so, then we could possibly in the future (when
nobody else uses omapdss) change omapdss to support DRM natively. (or
make omapdrm support omap HW natively, which ever way =).

> > 2) It's missing the panel driver part. This is rather important on
> > embedded systems, as the panels often are not "dummy" panels, but they
> > need things like custom initialization, sending commands to adjust
> > backlight, etc.
> 
> We integrate the panel (and other video output) drivers into the device
> drivers. With desktop chips, they're not easily separable. None of the
> desktop output drivers are simple; things like DisplayPort require link
> training, and everyone needs EDID. We share some of that code in the DRM
> layer today, and it would be nice to share even more.

I don't think we speak of similar panel drivers. I think there are two
different drivers here:

1) output drivers, handles the output from the SoC / gfx card. For
example DVI, DisplayPort, MIPI DPI/DBI/DSI.

2) panel drivers, handles panel specific things. Each panel may support
custom commands and features, for which we need a dedicated driver. And
this driver is not platform specific, but should work with any platform
which has the output used with the panel.

As an example, DSI command mode displays can be quite complex:

DSI bus is a half-duplex serial bus, and while it's designed for
displays you could use it easily for any communication between the SoC
and the peripheral.

The panel could have a feature like content adaptive backlight control,
and this would be configured via the DSI bus, sending a particular
command to the panel (possibly by first reading something from the
panel). The panel driver would accomplish this more or less the same way
one uses, say, i2c, so it would use the platform's DSI support to send
and receive packets.

Or a more complex scenario (but still a realistic scenario, been there,
done that) is sending the image to the panel in multiple parts, and
between each part sending configuration commands to the panel. (and
still getting it done in time so we avoid tearing).

And to complicate things more, there are DSI bus features like LP mode
(low power, basically low speed mode) and HS mode (high speed), virtual
channel IDs, and whatnot, which each panel may need to be used in
particular manner. Some panels may require initial configuration done in
LP, or configuration commands sent to a certain virtual channel ID.

The point is that we cannot have standard "MIPI DSI command mode panel
driver" which would work for all DSI cmd mode panels, but we need (in
the worst case) separate driver for each panel.

The same goes to lesser extent for other panels also. Some are
configured via i2c or spi.

 Tomi

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

[PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

2011-09-15 Thread Inki Dae

Hi, Thomas.

> -Original Message-
> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
> Sent: Wednesday, September 14, 2011 4:57 PM
> To: Inki Dae
> Cc: 'Rob Clark'; kyungmin.park at samsung.com; sw0312.kim at samsung.com; 
> linux-
> arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
> 
> On 09/14/2011 07:55 AM, Inki Dae wrote:
> >
> >
> >> -Original Message-
> >> From: Rob Clark [mailto:robdclark at gmail.com]
> >> Sent: Wednesday, September 14, 2011 11:26 AM
> >> To: Inki Dae
> >> Cc: Thomas Hellstrom; kyungmin.park at samsung.com;
sw0312.kim at samsung.com;
> >> linux-arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
> >> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
> >>
> >> On Tue, Sep 13, 2011 at 9:03 PM, Inki Dae  wrote:
> >>
> >>> Hi Thomas.
> >>>
> >>>
>  -Original Message-
>  From: Thomas Hellstrom [mailto:thomas at shipmail.org]
>  Sent: Monday, September 12, 2011 3:32 PM
>  To: Rob Clark
>  Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com;
> linux-
>  arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
>  Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC
> EXYNOS4210.
> 
>  On 09/11/2011 11:26 PM, Thomas Hellstrom wrote:
> 
> > On 09/10/2011 07:31 PM, Rob Clark wrote:
> >
> >> On Sat, Sep 10, 2011 at 9:04 AM, Thomas
> >> Hellstromwrote:
> >>
> >>> On 09/09/2011 01:38 PM, Inki Dae wrote:
> >>>
>  This patch is a DRM Driver for Samsung SoC Exynos4210 and now
> 
> >> enables
> >>
>  only FIMD yet but we will add HDMI support also in the future.
> 
>  from now on, I will remove RFC prefix because I think we have got
>  comments
>  enough.
> 
>  this patch is based on git repository below:
> 
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
>  branch name: drm-next
>  commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
> 
>  you can refer to our working repository below:
>  http://git.infradead.org/users/kmpark/linux-2.6-samsung
>  branch name: samsung-drm
> 
>  We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
>  based on Linux framebuffer) but couldn't so because lowlevel
> codes
>  of s3c-fb.c are included internally and so FIMD module of this
>  driver has
>  its own lowlevel codes.
> 
>  We used GEM framework for buffer management and DMA
> 
> >> APIs(dma_alloc_*)
> >>
>  for buffer allocation. by using DMA API, we could use CMA later.
> 
>  Refer to this link for CMA(Continuous Memory Allocator):
>  http://lkml.org/lkml/2011/7/20/45
> 
>  this driver supports only physically continuous
memory(non-iommu).
> 
>  Links to previous versions of the patchset:
>  v1:<  https://lwn.net/Articles/454380/>
>  v2:<  http://www.spinics.net/lists/kernel/msg1224275.html>
>  v3:<  http://www.gossamer-
> 
> >> threads.com/lists/linux/kernel/1423684>
> >>
>  Changelog v2:
>  DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
> 
>    this feature maps user address space to physical memory
> 
> >> region
> >>
>    once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP
> 
> >> ioctl.
> >>
>  DRM: code clean and add exception codes.
> 
>  Changelog v3:
>  DRM: Support multiple irq.
> 
>    FIMD and HDMI have their own irq handler but DRM Framework
> 
> >> can
> >>
>  regiter
>    only one irq handler this patch supports mutiple irq for
>  Samsung SoC.
> 
>  DRM: Consider modularization.
> 
>    each DRM, FIMD could be built as a module.
> 
>  DRM: Have indenpendent crtc object.
> 
>    crtc isn't specific to SoC Platform so this patch gets a
> crtc
>    to be used as common object.
>    created crtc could be attached to any encoder object.
> 
>  DRM: code clean and add exception codes.
> 
>  Changelog v4:
>  DRM: remove is_defult from samsung_fb.
> 
>    is_default isn't used for default framebuffer.
> 
>  DRM: code refactoring to fimd module.
>    this patch is be considered with multiple display objects
> and
>    would use its own request_irq() to register a irq handler
>  instead of
>    drm framework's one.
> 
>  DRM: remove find_samsung_drm_gem_object()
> 
>  DRM: move kernel private data structur

Re: Proposal for a low-level Linux display framework

> is and we could use it. Such attitude is not helpful and as I don't see any
> serious intention of the DRM guys to cooperate I think those subsystems are 
> more
> likely to diverge. At least I'll never accept any change to the fb
> infrastructure that requires DRM.

There are aspects of the fb code that want changing for DRM (and indeed
modern hardware) but which won't break for other stuff. Given the move to
using main memory for video and the need for the OS to do buffer
management for framebuffers I suspect a move to DRM is pretty much
inevitable, along with having to fix the fb layer to cope with
discontiguous framebuffers.

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

[PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

2011-09-15 Thread Thomas Hellstrom

On 09/15/2011 03:20 AM, Inki Dae wrote:
> Hi, Thomas.
>
>
>> -Original Message-
>> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
>> Sent: Wednesday, September 14, 2011 4:57 PM
>> To: Inki Dae
>> Cc: 'Rob Clark'; kyungmin.park at samsung.com; sw0312.kim at samsung.com; 
>> linux-
>> arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
>> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
>>
>> On 09/14/2011 07:55 AM, Inki Dae wrote:
>>  
>>>
>>>
 -Original Message-
 From: Rob Clark [mailto:robdclark at gmail.com]
 Sent: Wednesday, September 14, 2011 11:26 AM
 To: Inki Dae
 Cc: Thomas Hellstrom; kyungmin.park at samsung.com;
  
> sw0312.kim at samsung.com;
>
 linux-arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
 Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

 On Tue, Sep 13, 2011 at 9:03 PM, Inki Dae   wrote:

  
> Hi Thomas.
>
>
>
>> -Original Message-
>> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
>> Sent: Monday, September 12, 2011 3:32 PM
>> To: Rob Clark
>> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com;
>>  
>> linux-
>>  
>> arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
>> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC
>>  
>> EXYNOS4210.
>>  
>> On 09/11/2011 11:26 PM, Thomas Hellstrom wrote:
>>
>>  
>>> On 09/10/2011 07:31 PM, Rob Clark wrote:
>>>
>>>
 On Sat, Sep 10, 2011 at 9:04 AM, Thomas
 Hellstrom wrote:

  
> On 09/09/2011 01:38 PM, Inki Dae wrote:
>
>
>> This patch is a DRM Driver for Samsung SoC Exynos4210 and now
>>
>>  
 enables

  
>> only FIMD yet but we will add HDMI support also in the future.
>>
>> from now on, I will remove RFC prefix because I think we have got
>> comments
>> enough.
>>
>> this patch is based on git repository below:
>>
>>  
> git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
>
>> branch name: drm-next
>> commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
>>
>> you can refer to our working repository below:
>> http://git.infradead.org/users/kmpark/linux-2.6-samsung
>> branch name: samsung-drm
>>
>> We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
>> based on Linux framebuffer) but couldn't so because lowlevel
>>  
>> codes
>>  
>> of s3c-fb.c are included internally and so FIMD module of this
>> driver has
>> its own lowlevel codes.
>>
>> We used GEM framework for buffer management and DMA
>>
>>  
 APIs(dma_alloc_*)

  
>> for buffer allocation. by using DMA API, we could use CMA later.
>>
>> Refer to this link for CMA(Continuous Memory Allocator):
>> http://lkml.org/lkml/2011/7/20/45
>>
>> this driver supports only physically continuous
>>  
> memory(non-iommu).
>
>> Links to previous versions of the patchset:
>> v1:<   https://lwn.net/Articles/454380/>
>> v2:<   http://www.spinics.net/lists/kernel/msg1224275.html>
>> v3:<   http://www.gossamer-
>>
>>  
 threads.com/lists/linux/kernel/1423684>

  
>> Changelog v2:
>> DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
>>
>>this feature maps user address space to physical memory
>>
>>  
 region

  
>>once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP
>>
>>  
 ioctl.

  
>> DRM: code clean and add exception codes.
>>
>> Changelog v3:
>> DRM: Support multiple irq.
>>
>>FIMD and HDMI have their own irq handler but DRM Framework
>>
>>  
 can

  
>> regiter
>>only one irq handler this patch supports mutiple irq for
>> Samsung SoC.
>>
>> DRM: Consider modularization.
>>
>>each DRM, FIMD could be built as a module.
>>
>> DRM: Have indenpendent crtc object.
>>
>>crtc isn't specific to SoC Platform so this patch gets a
>>  
>> crtc
>>

[PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

2011-09-15 Thread Konrad Rzeszutek Wilk

On Thu, Sep 15, 2011 at 06:37:39PM +0900, Inki Dae wrote:
> Hello, Konrad Rzeszutek Wilk.
> 
> Your review and comments are so very detail. it was very helpful. thank you
> again.

.. snip ..
> > > + /* FIXME: error check */
> > 
> > You might as well do it now - before you do the next posting.
> > 
> 
> Ok, get it. you mean, send this patch modified now, not next posting.?

When you are ready to send V5 (hopefully the last version) of these patches.

.. snip..
> > > + * @ops: pointer to samsung_drm_overlay_ops.
> > > + *
> > > + * this structure is common to Samsung SoC and would be copied
> > > + * to hardware specific overlay info.
> > 
> > Uh?
> 
> This means that contents of samsung_drm_overlay object will copied to fimd's
> one, struct fimd_win_data.

Ok, lets use that comment instead then.
> 
> > > + */
> > > +struct samsung_drm_overlay {
> > > + unsigned int offset_x;
> > > + unsigned int offset_y;
> > > + unsigned int width;
> > > + unsigned int height;
> > > + unsigned int paddr;
> > 
> > You don't want to use 'dma_addr_t' ?
> > 
> 
> You are right. I will correct it. thank you.
> 
> > > + void __iomem *vaddr;
> > > + unsigned int buf_off;
> > > + unsigned int end_buf_off;
> > > + unsigned int buf_offsize;
> > > + unsigned int line_size;
> > > +
> > > + bool default_win;
> > > + bool color_key;
> > > + unsigned int index_color;
> > > + bool local_path;
> > > + bool transparency;
> > > + bool activated;
> > > +};
> > > +
> > > +/**
> > > + * Samsung DRM Display Structure.
> > > + *   - this structure is common to analog tv, digital tv and lcd 
> > > panel.
> > > + *
> > > + * @dev: pointer to specific device object.
> > 
> > ??
> 
> Ah, this should be removed. Thank you.
> 
> > > + * @is_connected: check for that display is connected or not.
> > > + * @get_edid: get edid modes from display driver.
> > > + * @get_timing: get timing object from display driver.
> > > + * @check_timing: check if timing is valid or not.
> > > + * @power_on: display device on or off.
> > > + */
> > > +struct samsung_drm_display {
> > > + unsigned int type;
> > > + bool (*is_connected)(struct device *dev);
> > > + int (*get_edid)(struct device *dev, struct drm_connector *connector,
> > > + u8 *edid, int len);
> > > + void *(*get_timing)(struct device *dev);
> > > + int (*check_timing)(struct device *dev, void *timing);
> > > + int (*power_on)(struct device *dev, int mode);
> > > +};
> > > +
> > > +/**
> > > + * Samsung drm manager ops
> > > + *
> > > + * @mode_set: convert drm_display_mode to hw specific display mode and
> > > + * would be called by encoder->mode_set().
> > > + * @commit: set current hw specific display mode to hw.
> > > + * @enable_vblank: specific driver callback for enabling vblank
> > interrupt.
> > > + * @disable_vblank: specific driver callback for disabling vblank
> > interrupt.
> > > + */
> > > +struct samsung_drm_manager_ops {
> > > + void (*mode_set)(struct device *subdrv_dev, void *mode);
> > > + void (*commit)(struct device *subdrv_dev);
> > > + int (*enable_vblank)(struct device *subdrv_dev);
> > > + void (*disable_vblank)(struct device *subdrv_dev);
> > > +};
> > > +
> > > +/**
> > > + * Samsung drm common manager structure.
> > > + *
> > > + * @dev: pointer to device object for subdrv device driver.
> > > + * @ops: ops pointer to samsung drm common framebuffer.
> > > + *ops of fimd or hdmi driver should be set to this ones.
> > > + */
> > > +struct samsung_drm_manager {
> > > + struct device *dev;
> > > + int pipe;
> > 
> > No comment for that?
> 
> Ok, get it. I will add some comment for that. thank you.
> 
> > > + struct samsung_drm_manager_ops *ops;
> > > + struct samsung_drm_overlay_ops *overlay_ops;
> > > + struct samsung_drm_display *display;
> > 
> > And you are missing the comments for these two.
> 
> Also.
> 
> > > +};
> > > +
> > > +/**
> > 
> > I just noticed it, but the '**' is not the kerneldoc
> > style comment. You might want to remove them from all the files.
> > 
> 
> Ok, get it. thank you.
> 
> > > + * Samsung drm private structure.
> > 
> > Ok, you are defining it in a public header so you should at
> > least document what the fields mean.
> > 
> 
> Ok, get it. I will add comments to all fields and thank you for your
> pointing.
> 
> > If you don't want the public to use it - make another header
> > file, helpfully called 'xxx_private.h'
> > 
> > 
> > > + */
> > > +struct samsung_drm_private {
> > > + struct drm_fb_helper *fb_helper;
> > > +
> > > + /* for pageflip */
> > > + struct list_head pageflip_event_list;
> > > + bool pageflip_event;
> > > +
> > > + struct drm_crtc *crtc[MAX_CRTC];
> > > +
> > > + /* add some structures. */
> > 
> > Umm, which ones?
> > 
> 
> This comment will be removed. Thank you.
> 
> > > +};
> > > +
> > > +struct samsung_drm_subdrv {
> > > + struct list_head list;
> > > + struct drm_device *drm_dev;
> > > +
> > > + /* driver ops */
> > > + int (*probe)(struct drm_device *dev);
> > > + vo

Re: Proposal for a low-level Linux display framework

On 09/15/2011 03:50 PM, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen  
> wrote:
> 
>> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> the plan is to make DRM the core Linux display framework, upon which
>> everything else is built, and fb and v4l2 are changed to use DRM.
> 
> I'd like to think we could make DRM the underlying display framework;
> it already exposes an fb interface, and with overlays, a bit more of the
> v4l2 stuff is done as well. Certainly eliminating three copies of mode
> setting infrastructure would be nice...

Interesting that this comes from the people that pushed the latest mode setting
code into the kernel. But I don't think that this will happen, the exposed user
interfaces will be around for decades and the infrastructure code could be
shared, in theory.
For fb and V4L2 I think we'll develop some level of interoperability, share
concepts and maybe even some code. The FOURCC pixel formats and overlays are
such examples. As Laurent is really interested in it I think we can get some
nice progress here.
For fb and DRM the situation is entirely different. The last proposal I remember
ended in the DRM people stating that only their implementation is acceptable as
is and we could use it. Such attitude is not helpful and as I don't see any
serious intention of the DRM guys to cooperate I think those subsystems are more
likely to diverge. At least I'll never accept any change to the fb
infrastructure that requires DRM.

Regards,

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

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

Samuel Thibault, le Thu 15 Sep 2011 09:41:06 +0200, a ?crit :
> Keith Packard, le Thu 15 Sep 2011 00:43:36 -0500, a ?crit :
> > On Thu, 15 Sep 2011 01:27:17 +0200, Samuel Thibault  > ens-lyon.org> wrote:
> > Non-text part: multipart/mixed
> > > I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
> > > E6420, but dual head is broken. Here is the scenario:
> > > 
> > > - Turn computer on with VGA1 connected. Both LVDS1 and VGA1 show the
> > >   text console fine.
> > > - Start X. VGA1 shows X fine, but LVDS1 (1600x900 resolution) shows an
> > >   odd screen: completely black on the left part (about 1060x900), sort
> > >   of gray on the right part (about 540x900). Playing with xrandr doesn't
> > >   help, I can at best make it completely black with --off, and not get
> > >   it back again with --auto or anything else.
> > 
> > Can you try disabling frame buffer compression?
> > 
> > i915.i915_enable-fbc=0
> > 
> > I'm about to send a patch to disable this by default; I've gotten two
> > people saying that this helps them already.
> 
> Absolutely. I have no issue any more, and the error messages are gone.

At home only. At work, with a different VGA screen, I'm still getting
the issue.

Samuel
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.1.0-rc6 (samy at type) (gcc version 4.6.1 
(Debian 4.6.1-4) ) #1 SMP Wed Sep 14 19:23:48 CEST 2011
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.1.0-rc6 
root=UUID=38e6e493-2f5f-4a98-b1d6-a9434f0683cc ro i915.i915_enable-fbc=0
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 00091400 (usable)
[0.00]  BIOS-e820: 00091400 - 000a (reserved)
[0.00]  BIOS-e820: 000e - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 2000 (usable)
[0.00]  BIOS-e820: 2000 - 2020 (reserved)
[0.00]  BIOS-e820: 2020 - 4000 (usable)
[0.00]  BIOS-e820: 4000 - 4020 (reserved)
[0.00]  BIOS-e820: 4020 - baa2a000 (usable)
[0.00]  BIOS-e820: baa2a000 - baa6e000 (reserved)
[0.00]  BIOS-e820: baa6e000 - badb7000 (usable)
[0.00]  BIOS-e820: badb7000 - bade7000 (reserved)
[0.00]  BIOS-e820: bade7000 - bafe7000 (ACPI NVS)
[0.00]  BIOS-e820: bafe7000 - bafff000 (ACPI data)
[0.00]  BIOS-e820: bafff000 - bb00 (usable)
[0.00]  BIOS-e820: bb80 - bfa0 (reserved)
[0.00]  BIOS-e820: fed1c000 - fed2 (reserved)
[0.00]  BIOS-e820: ffc0 - ffc2 (reserved)
[0.00]  BIOS-e820: 0001 - 00013e00 (usable)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.6 present.
[0.00] DMI: Dell Inc. Latitude E6420/032T9K, BIOS A05 05/24/2011
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] No AGP bridge found
[0.00] last_pfn = 0x13e000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 08000 mask FC000 write-back
[0.00]   2 base 0BC00 mask FFC00 uncachable
[0.00]   3 base 0BB00 mask FFF00 uncachable
[0.00]   4 base 1 mask FC000 write-back
[0.00]   5 base 13E00 mask FFE00 uncachable
[0.00]   6 base 0FFC0 mask FFFC0 write-protect
[0.00]   7 disabled
[0.00]   8 disabled
[0.00]   9 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] last_pfn = 0xbb000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [880f1b60] f1b60
[0.00] initial memory mapped : 0 - 2000
[0.00] Base memory trampoline at [8808c000] 8c000 size 20480
[0.00] init_memory_mapping: -bb00
[0.00]  00 - 00bb00 page 2M
[0.00] kernel direct mapping tables up to bb00 @ badb3000-badb7000
[0.00] init_memory_mapping: 0001-00013e00
[0.00]  01 - 013e00 page 2M
[0.00] kernel direct mapping tables up to 13e00 @ 
13dffa000-13e00
[0.00] RAMDISK: 3428c000 - 3613e000
[0.00] ACPI: RSDP 00

Re: Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 10:50:32 -0500
Keith Packard  wrote:

> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen  
> wrote:
> 
> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > the plan is to make DRM the core Linux display framework, upon which
> > everything else is built, and fb and v4l2 are changed to use DRM.
> 
> I'd like to think we could make DRM the underlying display framework;
> it already exposes an fb interface, and with overlays, a bit more of the
> v4l2 stuff is done as well. Certainly eliminating three copies of mode
> setting infrastructure would be nice...

V4L2 needs to interface with the DRM anyway. Lots of current hardware
wants things like shared 1080i/p camera buffers with video in order to do
preview on video and the like.

In my semi-perfect world vision fb would be a legacy layer on top of DRM.
DRM would get the silly recovery fail cases fixed, and a kernel console
would be attachable to a GEM object of your choice.

Alan

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

Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen  
wrote:

> This was a very rough and quite short proposal, but I'm happy to improve
> and extend it if it's not totally shot down.

Jesse Barnes has put together a proposal much like this to work within
the existing DRM environment. This is pretty much the last piece of
missing mode-setting functionality that we know of, making DRM capable
of fully supporting existing (and planned) devices.

Here's a link to some older discussion on the issue, things have changed
a bit since then and we had a long talk about this during the X
Developers' Conference this week in Chicago. Expect an update to his
proposal in the coming weeks.

http://lists.freedesktop.org/archives/dri-devel/2011-April/010559.html

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/628a25f8/attachment.pgp>

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

Keith Packard, le Thu 15 Sep 2011 00:43:36 -0500, a ?crit :
> On Thu, 15 Sep 2011 01:27:17 +0200, Samuel Thibault  ens-lyon.org> wrote:
> Non-text part: multipart/mixed
> > Hello,
> > 
> > I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
> > E6420, but dual head is broken. Here is the scenario:
> > 
> > - Turn computer on with VGA1 connected. Both LVDS1 and VGA1 show the
> >   text console fine.
> > - Start X. VGA1 shows X fine, but LVDS1 (1600x900 resolution) shows an
> >   odd screen: completely black on the left part (about 1060x900), sort
> >   of gray on the right part (about 540x900). Playing with xrandr doesn't
> >   help, I can at best make it completely black with --off, and not get
> >   it back again with --auto or anything else.
> 
> Can you try disabling frame buffer compression?
> 
> i915.i915_enable-fbc=0
> 
> I'm about to send a patch to disable this by default; I've gotten two
> people saying that this helps them already.

Absolutely. I have no issue any more, and the error messages are gone.

Samuel

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault  wrote:

> At home only. At work, with a different VGA screen, I'm still getting
> the issue.

You're still having a problem with the LVDS screen at work with FBC
disabled? Can you send along a kernel log with drm.debug=5?

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110915/e53b1005/attachment.pgp>

Re: Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen  
wrote:

> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> the plan is to make DRM the core Linux display framework, upon which
> everything else is built, and fb and v4l2 are changed to use DRM.

I'd like to think we could make DRM the underlying display framework;
it already exposes an fb interface, and with overlays, a bit more of the
v4l2 stuff is done as well. Certainly eliminating three copies of mode
setting infrastructure would be nice...

> But even if it was done like that, I see that it's combining two
> separate things: 1) the lower level HW control, and 2) the upper level
> buffer management, policies and userspace interfaces.

Those are split between the DRM layer and the underlying device driver,
which provides both kernel (via fb) and user space interfaces.

> 2) It's missing the panel driver part. This is rather important on
> embedded systems, as the panels often are not "dummy" panels, but they
> need things like custom initialization, sending commands to adjust
> backlight, etc.

We integrate the panel (and other video output) drivers into the device
drivers. With desktop chips, they're not easily separable. None of the
desktop output drivers are simple; things like DisplayPort require link
training, and everyone needs EDID. We share some of that code in the DRM
layer today, and it would be nice to share even more.

We should figure out if the DRM interfaces are sufficient for your
needs; they're pretty flexible at this point.

Of course, backlight remains a mess in the desktop world; with many
custom backlight drivers along with generic ACPI and then
per-video-device drivers as well.

-- 
keith.pack...@intel.com

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

Re: Proposal for a low-level Linux display framework

On Thu, 2011-09-15 at 09:59 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen  
> wrote:
> 
> > This was a very rough and quite short proposal, but I'm happy to improve
> > and extend it if it's not totally shot down.
> 
> Jesse Barnes has put together a proposal much like this to work within
> the existing DRM environment. This is pretty much the last piece of
> missing mode-setting functionality that we know of, making DRM capable
> of fully supporting existing (and planned) devices.
> 
> Here's a link to some older discussion on the issue, things have changed
> a bit since then and we had a long talk about this during the X
> Developers' Conference this week in Chicago. Expect an update to his
> proposal in the coming weeks.
> 
> http://lists.freedesktop.org/archives/dri-devel/2011-April/010559.html
> 

Thanks for the link.

Right, DRM has already components I described in my proposal, and adding
overlays brings it even closer. However, I think there are two major
differences:

1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
the plan is to make DRM the core Linux display framework, upon which
everything else is built, and fb and v4l2 are changed to use DRM.

But even if it was done like that, I see that it's combining two
separate things: 1) the lower level HW control, and 2) the upper level
buffer management, policies and userspace interfaces.

2) It's missing the panel driver part. This is rather important on
embedded systems, as the panels often are not "dummy" panels, but they
need things like custom initialization, sending commands to adjust
backlight, etc.

 Tomi

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

[Linaro-mm-sig] [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

2011-09-15 Thread Kyungmin Park

On Thu, Sep 15, 2011 at 6:53 AM, Rob Clark  wrote:
> On Wed, Sep 14, 2011 at 2:57 AM, Thomas Hellstrom  
> wrote:
>>
>> +static struct drm_ioctl_desc samsung_ioctls[] = {
>> + ? ? ? DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE,
>> samsung_drm_gem_create_ioctl,
>> + ? ? ? ? ? ? ? ? ? ? ? DRM_UNLOCKED | DRM_AUTH),
>>
>>
>
> Hi!
>
> With reference my previous security comment.
>
> Let's say you have a compromised video player running as a DRM
> client, that
> tries to repeatedly allocate huge GEM buffers...
>
> What will happen when all DMA memory is exhausted? Will this cause
> other
> device drivers to see an OOM, or only DRM?
>
> The old DRI model basically allowed any authorized DRI client to
> exhaust
> video ram or AGP memory, but never system memory. Newer DRI drivers
> typically only allow DRI masters to do that.
> as
>
> I don't think an authorized DRI client should be able to easily
>
>>
>> exhaust
>>
>
> resources (DMA memory) used by other device drivers causing them to
> fail.
>

 I'm not entirely sure what else can be done, other than have a
 threshold on max MB allocatable of buffer memory..

>>>
>>> Yes, I think that's what needs to be done, and that threshold should
>>> be low enough to keep other device drivers running in the worst
>>> allocation case.
>>>
>>>

 In the samsung driver case, he is only allocating scanout memory


 from


 CMA, so the limit will be the CMA region size.. beyond that you


 can't


 get physically contiguous memory. ?So I think this driver is safe.

>>>
>>> It's not really what well-behaved user-space drivers do that should
>>>

 be

>>>
>>> a concern, but what compromized application *might* do that is a
>>>
>
> concern.
>
>>
>> Hmm. I might have missed your point here. If the buffer allocation
>>

 ioctl

>>
>> only allows allocating CMA memory, then I agree the driver fits the old
>> DRI security model, as long as no other devices on the platform will
>> ever use CMA.
>>
>> But in that case, there really should be a way for the driver to say
>> "Hey, all CMA memory on this system is mine", in the same way
>> traditional video drivers can claim the VRAM PCI resource.
>>
>>
>
> CMA could reserve memory region for a specific driver so DRM Client
>

 could

>
> request memory allocation from only the region.
>
>
>>
>> This is to avoid the possibility that future drivers that need CMA will
>> be vulnerable to DOS-attacks from ill-behaved DRI clients.
>>
>>
>
> Thomas, if any application has root authority for ill-purpose then isn't
>

 it

>
> possible to be vulnerable to DOS-attacks? I think DRM_AUTH means root
> authority. I know DRM Framework gives any root application DRM_AUTH
> authority for compatibility.
>

 DRM_AUTH just means that the client has authenticated w/ X11 (meaning
 that it has permission to connect to x server)..


>>>
>>> Yes, I understood so. but see drm_open_helper() of drm_fops.c file please.
>>> in this function, you can see a line below.
>>> /* for compatibility root is always authenticated */
>>> priv->authenticated = capable(CAP_SYS_ADMIN)
>>>
>>> I think the code above says that any application with root permission is
>>> authenticated.
>>>
>>>
>>
>> Yes, that is true. A root client may be assumed to have AUTH permissions,
>> but the inverse does not hold, meaning that an AUTH client may *not* be
>> assumed to have root permissions. I think there is a ROOT_ONLY ioctl flag
>> for that.
>>
>> The problem I'm seeing compared to other drivers is the following:
>>
>> Imagine for example that you have a disc driver that allocates temporary
>> memory out of the same DMA pool as the DRM driver.
>>
>> Now you have a video player that is a DRM client. It contains a security
>> flaw and is compromized by somebody trying to play a specially crafted video
>> stream. The video player starts to allocate gem buffers until it receives an
>> -ENOMEM. Then it stops allocating and does nothing.
>>
>> Now the system tries an important disc access (paging for example). This
>> fails, because the video player has exhausted all DMA memory and the disc
>> driver fails to allocate.
>>
>> The system is dead.
>>
>> The point is:
>>
>> If there is a chance that other drivers will use the same DMA/CMA pool as
>> the DRM driver, DRM must leave enough DMA/CMA memory for those drivers to
>> work.
>
> ah, ok, I get your point
>
>
>> T

Re: Proposal for a low-level Linux display framework

On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen  
wrote:

> This was a very rough and quite short proposal, but I'm happy to improve
> and extend it if it's not totally shot down.

Jesse Barnes has put together a proposal much like this to work within
the existing DRM environment. This is pretty much the last piece of
missing mode-setting functionality that we know of, making DRM capable
of fully supporting existing (and planned) devices.

Here's a link to some older discussion on the issue, things have changed
a bit since then and we had a long talk about this during the X
Developers' Conference this week in Chicago. Expect an update to his
proposal in the coming weeks.

http://lists.freedesktop.org/archives/dri-devel/2011-April/010559.html

-- 
keith.pack...@intel.com

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

Re: [REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault 
 wrote:

> At home only. At work, with a different VGA screen, I'm still getting
> the issue.

You're still having a problem with the LVDS screen at work with FBC
disabled? Can you send along a kernel log with drm.debug=5?

-- 
keith.pack...@intel.com


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

Proposal for a low-level Linux display framework

Hi,

I am the author of OMAP display driver, and while developing it I've
often felt that there's something missing in Linux's display area. I've
been planning to write a post about this for a few years already, but I
never got to it. So here goes at last!

---

First I want to (try to) describe shortly what we have on OMAP, to give
a bit of a background for my point of view, and to have an example HW.

The display subsystem (DSS) hardware on OMAP handles only showing pixels
on a display, so it doesn't contain anything that produces pixels like
3D stuff or accelerated copying. All it does is fetch pixels from SDRAM,
possibly do some modifications for them (color format conversions etc),
and output them to a display.

The hardware has multiple overlays, which are like hardware windows.
They fetch pixels from SDRAM, and output them in a certain area on the
display (possibly with scaling). Multiple overlays can be composited
into one output.

So we may have something like this, when all overlays read pixels from
separate areas in the memory, and all overlays are on LCD display:

 .-. .--.   .--.
 | mem |>| ovl0 |-.>| LCD  |
 '-' '--' | '--'
 .-. .--. |
 | mem |>| ovl1 |-|
 '-' '--' |
 .-. .--. | .--.
 | mem |>| ovl2 |-' |  TV  |
 '-' '--'   '--'

The LCD display can be rather simple one, like a standard monitor or a
simple panel directly connected to parallel RGB output, or a more
complex one. A complex panel needs something else than just
turn-it-on-and-go. This may involve sending and receiving messages
between OMAP and the panel, but more generally, there's need to have
custom code that handles the particular panel. And the complex panel is
not necessarily a panel at all, it may be a buffer chip between OMAP and
the actual panel.

The software side can be divided into three parts: the lower level
omapdss driver, the lower level panel drivers, and higher level drivers
like omapfb, v4l2 and omapdrm.

The omapdss driver handles the OMAP DSS hardware, and offers a kernel
internal API which the higher level drivers use. The omapdss does not
know anything about fb or drm, it just offers core display services.

The panel drivers handle particular panels/chips. The panel driver may
be very simple in case of a conventional display, basically doing pretty
much nothing, or bigger piece of code, handling communication with the
panel.

The higher level drivers handle buffers and tell omapdss things like
where to find the pixels, what size the overlays should be, and use the
omapdss API to turn displays on/off, etc.

---

There are two things that I'm proposing to improve the Linux display
support:

First, there should be a bunch of common video structs and helpers that
are independent of any higher level framework. Things like video
timings, mode databases, and EDID seem to be implemented multiple times
in the kernel. But there shouldn't be anything in those things that
depend on any particular display framework, so they could be implemented
just once and all the frameworks could use them.

Second, I think there could be use for a common low level display
framework. Currently the lower level code (display HW handling, etc.)
and higher level code (buffer management, policies, etc) seem to be
usually tied together, like the fb framework or the drm. Granted, the
frameworks do not force that, and for OMAP we indeed have omapfb and
omapdrm using the lower level omapdss. But I don't see that it's
anything OMAP specific as such.

I think the lower level framework could have components something like
this (the naming is OMAP oriented, of course):

overlay - a hardware "window", gets pixels from memory, possibly does
format conversions, scaling, etc.

overlay compositor - composes multiple overlays into one output,
possibly doing things like translucency.

output - gets the pixels from overlay compositor, and sends them out
according to particular video timings when using conventional video
interface, or via any other mean when using non-conventional video buses
like DSI command mode.

display - handles an external display. For conventional displays this
wouldn't do much, but for complex ones it does whatever needed by that
particular display.

This is something similar to what DRM has, I believe. The biggest
difference is that the display can be a full blown driver for a complex
piece of HW.

This kind of low level framework would be good for two purposes: 1) I
think it's a good division generally, having the low level HW driver
separate from the higher level buffer/policy management and 2) fb, drm,
v4l2 or any possible future framework could all use the same low level
framework.

---

Now, I'm quite sure the above framework could work quite well with any
OMAP like hardware, with unified memory (i.e. the video buffers are in
SDRAM) an

[Bug 40904] New: Radeon 9100 (R200): GPU lockup using blender

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

   Summary: Radeon 9100 (R200): GPU lockup using blender
   Product: Mesa
   Version: 7.11
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: fron...@gmail.com


Created an attachment (id=51230)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51230)
dmesg with GPU lockup error

Blender doesn't work on my system. If I try to move the 3D blender scene with
the mouse the screen freezes, the cursor disappears and the system become
unusable for some seconds. The dmesg reports a "GPU lockup (waiting for
0x2034 last fence id 0x2030)" error.

My system configuration: 
Linux Slackware 13.37
Kernel 2.6.37.6 
libdrm-2.4.26 
mesa-7.11
xf86-video-ati-6.14.1
ATI Radeon 9100 (R200) AGP Video card

Steps to reproduce:

1. Start Blender 2.59:
$ blender

2. On the default scene with the cube, hold down the mouse wheel (middle mouse
button) and move the scene

3. A GPU lockup occurs quite immediately and the screen freezes.

The bug is very easy to reproduce on my system. 
Most of the time after few seconds I can use the system again (sometimes I have
to reset the system), but blender is unusable.
The same happens using blender 2.58a, 2.56, ...

-- 
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

[Bug 40904] New: Radeon 9100 (R200): GPU lockup using blender

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

   Summary: Radeon 9100 (R200): GPU lockup using blender
   Product: Mesa
   Version: 7.11
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: froncor at gmail.com


Created an attachment (id=51230)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51230)
dmesg with GPU lockup error

Blender doesn't work on my system. If I try to move the 3D blender scene with
the mouse the screen freezes, the cursor disappears and the system become
unusable for some seconds. The dmesg reports a "GPU lockup (waiting for
0x2034 last fence id 0x2030)" error.

My system configuration: 
Linux Slackware 13.37
Kernel 2.6.37.6 
libdrm-2.4.26 
mesa-7.11
xf86-video-ati-6.14.1
ATI Radeon 9100 (R200) AGP Video card

Steps to reproduce:

1. Start Blender 2.59:
$ blender

2. On the default scene with the cube, hold down the mouse wheel (middle mouse
button) and move the scene

3. A GPU lockup occurs quite immediately and the screen freezes.

The bug is very easy to reproduce on my system. 
Most of the time after few seconds I can use the system again (sometimes I have
to reset the system), but blender is unusable.
The same happens using blender 2.58a, 2.56, ...

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

[PATCH v2 4/5] DRI2: Expose API to set drawable swap limit.

2011-09-15 Thread Mario Kleiner

On Sep 15, 2011, at 12:54 AM, Francisco Jerez wrote:

> Mario Kleiner  writes:
>
>> On Sep 14, 2011, at 6:02 PM, Keith Packard wrote:
>>
>>> On Wed, 14 Sep 2011 10:05:29 -0500, Jesse Barnes
>>>  wrote:
>>>
 Ah thanks Mario, I blame Keith. :p   I agree we should integrate  
 this
 patch as it would allow us to do more fun stuff with swapping...
>>>
>>> That patch changes a ton of stuff; would be nice to see it split  
>>> into
>>> smaller chunks that could be reviewed easily.
>>>
>>
>> For reference, we're talking about this series, right?
>>
>> 
>>
>> As far as i can see, they were already split up in chunks and  
>> reviewed
>> by Jesse, me and Franzisco Jerez - assuming they still apply  to the
>> latest server version? At least 1/5, 4/5 and 5/5 looked simple   
>> enough
>> and 4/5 and 5/5, the swaplimit api, seem to be independent  from the
>> rest of the series?
>>
> Note that my r-b only goes to 4/5, I had some objections to 5/5 and  
> I'm
> not sure if 1/5-3/5 still make sense.

I haven't checked if the rest still makes sense. 5/5 was about why a  
driver who requests a dri2 swaplimit change should be called back to  
confirm it is ok with the swaplimit change, which you said seems  
totally redundant, right?

Ok, so we talk specifically about 4/5, which was reviewed by all of  
us, i think non-controversial, and a simple addition of a dri2  
swaplimit api.

Keith, what about that one for a start?

> BTW, is there any reason this is being discussed outside of the  
> mailing
> list?

No. It just started as a private conversation with Jesse and  
"drifted" into this. cc'ing dri-devel, all that was said is in this  
mail.

-mario

>> thanks,
>> -mario
>>
>>> --
>>> keith.packard at intel.com
>>
>> *
>> Mario Kleiner
>> Max Planck Institute for Biological Cybernetics
>> Spemannstr. 38
>> 72076 Tuebingen
>> Germany
>>
>> e-mail: mario.kleiner at tuebingen.mpg.de
>> office: +49 (0)7071/601-1623
>> fax:+49 (0)7071/601-616
>> www:http://www.kyb.tuebingen.mpg.de/~kleinerm
>> *
>> "For a successful technology, reality must take precedence
>> over public relations, for Nature cannot be fooled."
>> (Richard Feynman)

*
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany

e-mail: mario.kleiner at tuebingen.mpg.de
office: +49 (0)7071/601-1623
fax:+49 (0)7071/601-616
www:http://www.kyb.tuebingen.mpg.de/~kleinerm
*
"For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled."
(Richard Feynman)

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

Hello,

I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
E6420, but dual head is broken. Here is the scenario:

- Turn computer on with VGA1 connected. Both LVDS1 and VGA1 show the
  text console fine.
- Start X. VGA1 shows X fine, but LVDS1 (1600x900 resolution) shows an
  odd screen: completely black on the left part (about 1060x900), sort
  of gray on the right part (about 540x900). Playing with xrandr doesn't
  help, I can at best make it completely black with --off, and not get
  it back again with --auto or anything else.

I have attached the corresponding dmesgs and Xorg.0.logs: as you can
see, the Xorg log doesn't change, while the dmesg changes a bit, I'm
getting a few 

[drm:ironlake_update_pch_refclk] *ERROR* enabling SSC on PCH

the rest is the same.

Samuel
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.0.4 (samy at type) (gcc version 4.6.1 (Debian 
4.6.1-4) ) #2 SMP Tue Aug 30 11:04:23 CEST 2011
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.0.4 
root=UUID=38e6e493-2f5f-4a98-b1d6-a9434f0683cc ro
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 00091400 (usable)
[0.00]  BIOS-e820: 00091400 - 000a (reserved)
[0.00]  BIOS-e820: 000e - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 2000 (usable)
[0.00]  BIOS-e820: 2000 - 2020 (reserved)
[0.00]  BIOS-e820: 2020 - 4000 (usable)
[0.00]  BIOS-e820: 4000 - 4020 (reserved)
[0.00]  BIOS-e820: 4020 - baa2a000 (usable)
[0.00]  BIOS-e820: baa2a000 - baa6e000 (reserved)
[0.00]  BIOS-e820: baa6e000 - badb7000 (usable)
[0.00]  BIOS-e820: badb7000 - bade7000 (reserved)
[0.00]  BIOS-e820: bade7000 - bafe7000 (ACPI NVS)
[0.00]  BIOS-e820: bafe7000 - bafff000 (ACPI data)
[0.00]  BIOS-e820: bafff000 - bb00 (usable)
[0.00]  BIOS-e820: bb80 - bfa0 (reserved)
[0.00]  BIOS-e820: fed1c000 - fed2 (reserved)
[0.00]  BIOS-e820: ffc0 - ffc2 (reserved)
[0.00]  BIOS-e820: 0001 - 00013e00 (usable)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.6 present.
[0.00] DMI: Dell Inc. Latitude E6420/032T9K, BIOS A05 05/24/2011
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] No AGP bridge found
[0.00] last_pfn = 0x13e000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 08000 mask FC000 write-back
[0.00]   2 base 0BC00 mask FFC00 uncachable
[0.00]   3 base 0BB00 mask FFF00 uncachable
[0.00]   4 base 1 mask FC000 write-back
[0.00]   5 base 13E00 mask FFE00 uncachable
[0.00]   6 base 0FFC0 mask FFFC0 write-protect
[0.00]   7 disabled
[0.00]   8 disabled
[0.00]   9 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] last_pfn = 0xbb000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [880f1b60] f1b60
[0.00] initial memory mapped : 0 - 2000
[0.00] Base memory trampoline at [8808c000] 8c000 size 20480
[0.00] init_memory_mapping: -bb00
[0.00]  00 - 00bb00 page 2M
[0.00] kernel direct mapping tables up to bb00 @ badb3000-badb7000
[0.00] init_memory_mapping: 0001-00013e00
[0.00]  01 - 013e00 page 2M
[0.00] kernel direct mapping tables up to 13e00 @ 
13dffa000-13e00
[0.00] RAMDISK: 2db08000 - 32d7c000
[0.00] ACPI: RSDP 000fe300 00024 (v02 DELL  )
[0.00] ACPI: XSDT baffde18 0007C (v01 DELLCBX306222004 
MSFT 00010013)
[0.00] ACPI: FACP baf87d98 000F4 (v04 DELLCBX306222004 
MSFT 00010013)
[0.00] ACPI Warning: 32/64 FACS address mismatch in FADT - two FACS 
tables! (20110413/tbfadt-369)
[0.00] ACPI Warning: 32/64X FACS address mismatch in FADT - 
0xBAFE4E40/0xBAFE4D40, using 32 (20110413/tbfadt-489)
[

Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

2011-09-15 Thread Thomas Hellstrom


On 09/15/2011 03:20 AM, Inki Dae wrote:

Hi, Thomas.

   

-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org]
Sent: Wednesday, September 14, 2011 4:57 PM
To: Inki Dae
Cc: 'Rob Clark'; kyungmin.p...@samsung.com; sw0312@samsung.com; linux-
arm-ker...@lists.infradead.org; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

On 09/14/2011 07:55 AM, Inki Dae wrote:
 


   

-Original Message-
From: Rob Clark [mailto:robdcl...@gmail.com]
Sent: Wednesday, September 14, 2011 11:26 AM
To: Inki Dae
Cc: Thomas Hellstrom; kyungmin.p...@samsung.com;
 

sw0312@samsung.com;
   

linux-arm-ker...@lists.infradead.org; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

On Tue, Sep 13, 2011 at 9:03 PM, Inki Dae   wrote:

 

Hi Thomas.


   

-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org]
Sent: Monday, September 12, 2011 3:32 PM
To: Rob Clark
Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com;
 

linux-
 

arm-ker...@lists.infradead.org; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC
 

EXYNOS4210.
 

On 09/11/2011 11:26 PM, Thomas Hellstrom wrote:

 

On 09/10/2011 07:31 PM, Rob Clark wrote:

   

On Sat, Sep 10, 2011 at 9:04 AM, Thomas
Hellstrom wrote:

 

On 09/09/2011 01:38 PM, Inki Dae wrote:

   

This patch is a DRM Driver for Samsung SoC Exynos4210 and now

 

enables

 

only FIMD yet but we will add HDMI support also in the future.

from now on, I will remove RFC prefix because I think we have got
comments
enough.

this patch is based on git repository below:

 

git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
   

branch name: drm-next
commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922

you can refer to our working repository below:
http://git.infradead.org/users/kmpark/linux-2.6-samsung
branch name: samsung-drm

We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
based on Linux framebuffer) but couldn't so because lowlevel
 

codes
 

of s3c-fb.c are included internally and so FIMD module of this
driver has
its own lowlevel codes.

We used GEM framework for buffer management and DMA

 

APIs(dma_alloc_*)

 

for buffer allocation. by using DMA API, we could use CMA later.

Refer to this link for CMA(Continuous Memory Allocator):
http://lkml.org/lkml/2011/7/20/45

this driver supports only physically continuous
 

memory(non-iommu).
   

Links to previous versions of the patchset:
v1:<   https://lwn.net/Articles/454380/>
v2:<   http://www.spinics.net/lists/kernel/msg1224275.html>
v3:<   http://www.gossamer-

 

threads.com/lists/linux/kernel/1423684>

 

Changelog v2:
DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.

   this feature maps user address space to physical memory

 

region

 

   once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP

 

ioctl.

 

DRM: code clean and add exception codes.

Changelog v3:
DRM: Support multiple irq.

   FIMD and HDMI have their own irq handler but DRM Framework

 

can

 

regiter
   only one irq handler this patch supports mutiple irq for
Samsung SoC.

DRM: Consider modularization.

   each DRM, FIMD could be built as a module.

DRM: Have indenpendent crtc object.

   crtc isn't specific to SoC Platform so this patch gets a
 

crtc
 

   to be used as common object.
   created crtc could be attached to any encoder object.

DRM: code clean and add exception codes.

Changelog v4:
DRM: remove is_defult from samsung_fb.

   is_default isn't used for default framebuffer.

DRM: code refactoring to fimd module.
   this patch is be considered with multiple display objects
 

and
 

   would use its own request_irq() to register a irq handler
instead of
   drm framework's one.

DRM: remove find_samsung_drm_gem_object()

DRM: move kernel private data structures and definitions to
 

driver
 

folder.

   samsung_drm.h would contain only public information for

 

userspace

   

   ioctl interface.

DRM: code refactoring to gem modules.
   buffer module isn't dependent of gem module anymore.

DRM: fixed security issue.

DRM: remove encoder porinter from specific connector.

   samsung connector doesn't need to have generic encoder.

DRM: code clean and add exception codes.

Signed-off-by: Inki Dae
Signed-off-by: Joonyoung Shim
Signed-off-by: SeungWoo Kim
Signed-off-by: kyungmin.park
---

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*