and I can't see what makes this safe if the drm_release for the master
and a client occur at the same time ?
lock_kernel in drm_release. We probably need to clean that up.
I don't think that works. drm_open_helper doesn't appear to be under the
BKL merely the struct mutex.
The
Note if it is known that x and y are less than or equal to 7 it can be
done in 11 operations.
And bsr is one instruction for x86, cntlzw for ppc
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
My argument was based around that the current system is designed as a
directory of opaque objects and so the extended attributes should be
kept opaque to the kernel as well and left open to interpretation by
userland. What I am most unclear about is under which circumstances is
this
net/appletalk:
net/ipx/af_ipx.c:
net/irda/af_irda.c:
Can probably be saved from retirement in drivers/staging if the
maintainers still care.
IPX and Appletalk both have active users. They also look fairly fixable
as the lock_kernel just maps to a stack private mutex, or in
you still need to switch off preemption.
Hm, how would you do that from within a driver?
Do we care - unless I misunderstand the current intel DRM driver handles
the i810 as well ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
void kref_get(struct kref *kref)
{
WARN_ON(!atomic_read(kref-refcount));
atomic_inc(kref-refcount);
smp_mb__after_atomic_inc();
}
which causes havoc when you are trying to keep a list of unreferenced
objects. That's all I'm trying to avoid.
You cannot have a list
My point which people keep missing is that graphics stacks are a
single entity, that span kernel and userspace, one cannot exist
without the other, and there are interfaces that join them.
As a copyright holder on the kernel I'll also remind the people concerned
that the definition of a
I also do not think that it is at all kernel policy to disallow kernel
drivers which do not have opensource userspace components. In fact,
Wrong. The PVR graphics (as used by some Intel embedded for example) is
also not in the kernel for the same reason, ditto some sensor and GPS
devices which
The GPLv2 is written such that the if you're interfacing the kernel
or compiler you don't need to opensource that bit with your app
I would suggest you re-read the license. It says nothing of the sort.
Indeed the gcc compiler licensing for the compiler support library is
actually rather
way to behave. The best way to get companies to change their behaviour is
to find them and support them. Making threatening GPL noises in email does
not help them in any way.
I would disagree based on years of history.
The best way to get a company to change behaviour is for a situation
1) inertia: fbdev has been around a lot longer, and provides most of
what embedded devices need anyway
2) feature set: why bother doing a full KMS driver if you're not
going to use any of the additional features it would provide (output
management, memory management, execution
It's nothing fantastic, but I've had a number of people tell me that
it was useful for them.
It does document some stuff nicely - not alas the bits I need to figure
out at the moment but its definitely a nice reference to the basic setup.
(ponders Voodoo2 DRI)
On Wed, 13 Apr 2011 19:33:40 -0700
Linus Torvalds torva...@linux-foundation.org wrote:
On Wednesday, April 13, 2011, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wednesday, April 13, 2011, H. Peter Anvin h...@zytor.com wrote:
Yes. However, even if we *do* revert (and the time
So has this been benchmarked - intuitively I'd agree and expect that a
shadowfb driver ought to give best performance.
+/* Map the framebuffer from the card and configure the core */
+static int cirrus_vram_init(struct cirrus_device *cdev)
+{
+ int ret;
+
+ /* BAR 0 is VRAM */
+
I was planning on adding a new fb ioctl to allow us to create fbs with
specific surface format types. We could either enumerate all of the
ones we support (a list which will grow as drivers and devices are
added) or try to factor out commit bits into a separate surface struct:
struct
A lot of older hardware had one overlay that could be sourced to any
crtc, just not simultaneously. The tricky part is the formats and
capabilities: alpha blending, color/chromakey, gamma correction, etc.
Even the current crtc gamma stuff is somewhat lacking in in terms of
what hardware is
having a list per hardware. uint32_t would give enough room to add all
formats even if one format is only supported by one hardware only (at
It would indeed. A point realised by the Amiga designers in 1985 and
turned into a standard of sorts with a registry and process and adopted
by folks like
I think 4cc it bit useless with RGB stuff (or maybe i just don't
understand 4cc). For instance i think we want uniq different id for
RGB555, RGB565,RGBX, RGBA, BGRA ... it seems 4cc just says
rgb and than rely on additional informations for color order or
components size.
Yes -
And what if you don't have a default plane as such. For example, OMAP3
has one graphics plane and two video planes, and two output paths. Each
of the planes can be assigned to zero or one outputs. To accomodate this,
the design should allow for CRTCs without any scanout buffers.
Some TV type
On both cases, the requirement is to pass a framebuffer between two
entities,
and not a video stream.
It may not even be a framebuffer. In many cases you'll pass a framebuffer
or some memory target (in DRI think probably a GEM handle), in fact in
theory you can do much of this now.
use
If we change from 2.6.X to 3.X, then if we don't change anything else,
then successive stable release will cause the LINUX_VERSION_CODE to be
incremented. This isn't necessary bad, but it would be a different
from what we have now.
I think I prefer 3 digits. Otherwise we will have to pass
Can we drop most of MCA, EISA and ISA bus if we are going to have a big
version change ? A driver spring clean is much overdue and it's all in
git in case someone wishes to sneak out at midnight and bring some crawly
horror back from the dead.
Alan
___
I have GEM allocation working on the GMA 500 and I can scribble in a
framebuffer (minus an odd 'last page' bug which is an off by one
somewhere I imagine) and display it with nice modetest stripes.
If I kill the program however it all goes kerblam
drm_release calls into fb_release which duely
On Sat, 28 May 2011 09:54:01 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, 27 May 2011 14:37:45 -0700, Segovia, Benjamin
benjamin.sego...@intel.com wrote:
Hello gurus,
I have two question mostly regarding libdrm_intel
1/ What is the difference between drm_intel_bo_map
The window system needs support for splitting rendering and display.
In X these are currently tied together. The only real obstacle is
fixing this in X. However, this is a lot of work. Dave Airlie has
started working on this, but it's not really usable yet. See:
I'd much rather be able to just hand that memory off to the kernel to
use along with everything else and have there be nothing magic about it.
But as I recall, the mtrr mappings of that memory was often goofy, so it
may take some work to clean it up.
That also depends where it is located -
Currently I don't use any sophisticated memory allocater like GEM
or similar. I helped myself with simple dma_alloc where needed. At
GEM is actually pretty sane when you get your head around it a spot. The
main thing it took me a bit of time to get my head around is that it
allocates backing
From: Alan Cox a...@linux.intel.com
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/staging/gma500/psb_gtt.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/gma500/psb_gtt.c b/drivers/staging/gma500/psb_gtt.c
index 74c5a65..1d0e242 100644
for this before enabling it.
Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/staging/gma500/psb_drv.c| 15 ++-
drivers/staging/gma500/psb_intel_bios.c | 13 +
2 files changed, 23 insertions(+), 5
: 4410f3910947dcea8672280b3adecd53cec4e85e
Signed-off-by: Michael Chang mch...@novell.com
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/staging/gma500/psb_fb.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/gma500/psb_fb.c b/drivers/staging
From: Alan Cox a...@linux.intel.com
If we get a user frame buffer destroyed which is being displayed then clean
up the mess nicely. We can now run a slightly modified modetest including
setting
modes, and handling crashes.
Modetest still blows up but this is because libdrm 2.4.25 is busted
From: Alan Cox a...@linux.intel.com
We don't seem to need this for our task.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/staging/gma500/psb_drv.c |6
drivers/staging/gma500/psb_gtt.c | 62 --
2 files changed, 19 insertions(+), 49
From: Alan Cox a...@linux.intel.com
Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal
drivers if and when we need debug on stuff.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/staging/gma500/mrst_crtc.c | 23 ++
drivers/staging/gma500
From: Alan Cox a...@linux.intel.com
We are using the underlying kref in the GEM object so we don't need our own
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/staging/gma500/psb_fb.c |1 -
drivers/staging/gma500/psb_gtt.c | 41 ++
drivers
On Thu, 9 Jun 2011 03:10:03 +0200
Patrik Jakobsson patrik.r.jakobs...@gmail.com wrote:
Hi Alan
Just a thought. Shouldn't we use the DRM macros for printing debug info?
Linux has perfectly good printing functions and using them means we can
use dev_dbg() which supports things like nice
On Thu, 09 Jun 2011 14:05:59 +1000
Dave Airlie airl...@redhat.com wrote:
On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote:
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl
You also don't need a headwer with a complete list of fourcc names in it,
that is the half the point of FourCC.
#define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8
RGB-3-3-2 */
See that V4L2 and v4l2? I'd rather not have them used in the drm
They are just helpers.
Though if psb wants to be different to other drm drivers it can lead the
way, though it'll be a total nightmare for all the people who follow
documentation on how to debug drm drivers using drm.debug=1,2,4,8. for
various code paths.
Actually it seems to work out nicely because you can debug
Yes, my concern was about drm.debug and use of all the DRM portability stuff
(like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...)
The portability might not be important at this point but I just wanted to
raise
the question so I know what is right / wrong.
The gma500 driver uses a
Given that I've mucked around in drm_mm quite a bit I'd be very interested
in your opinion about what's weird in it (and presumably what could be
improved). Can you elaborate?
Mostly the API, which is also somewhat poorly documented. I've not dug
into the internals beyond trying to figure out
Found this going over intel_bios.c and cross comparing it with the
Intel/IMG driver intel_bios.c
temp_mode = kzalloc(sizeof(*temp_mode), GFP_KERNEL);
temp_downclock = panel_fixed_mode-clock;
/*
* enumerate the LVDS panel timing info entry in VBT to check
On Mon, 18 Jul 2011 19:20:56 -0500
Rob Clark r...@ti.com wrote:
In the process of adding GEM support for OMAP DRM driver, I noticed that
I was adding code for creating/freeing mmap offsets which was virtually
identical to what was already duplicated in i915 and gma500 drivers.
The gma500 one
ahh, ok.. I should check this out (although I'm not entirely sure
where your gma500 staging tree is)
Its in GregKH's staging tree or linux-next. It's basically what you've
done so if your patch is submitted it'll take me 2 minutes to fix the
gma500 tree.
I'm already using your patch to add
Not something that directly affects this patchset.. I'm thinking more
along the lines of having a way to create a drm_framebuffer w/ more
than one GEM buffer, one per color plane. The other option is to bury
this all behind a single GEM buffer.. although that seems like it
could get
Ah, I didn't realise this would run as root. Would /run (or /var/run)
be ok then? Alternately, use an abstract domain socket to not have to
care about the underlying filesystem.
Abstract sockets are a bit of a Linux specific feature. You also don't
want sockets in /home as it may well be NFS
On Mon, 1 Aug 2011 20:47:42 +0100
Dave Airlie airl...@gmail.com wrote:
Hmmm, what's about the opposite approach?
To me, it sounds simpler and more logical when the kernel always creates
one device node per output (or maybe dynamically per connected output),
without any need for
But I believe this is a problem of all approaches which provide
multiple hardware-accelerated (or Xv-enabled) seats on a single GPU,
no matter if based on multiple DRM devices, on Xephyr or Xnest
with some kind of OpenGL or DRI passthrough, or on Wayland:
If one has direct access to the
if so, I am aware of it but his patch isn't applied to drm-next yet and
so my drm driver doesn't include his patch. of course I will reuse it
and remove the samsung_ namespace as you pointed out if the patch is
applied to drm-next.
It would be nice it was as its also the same as the code
Sorry, I won't submit a patch. If there is a need to find/fix/cleanup
obvious things after company's developers, I have better things to do,
and a todo item to re-evaluate hardware for my next project.
You seem confused. If you have a support contract of some form with a
Linux supplier or
On Thu, 4 Aug 2011 12:07:40 -0500
Rob Clark r...@ti.com wrote:
I'm happy with these but it will need contributing with your
Signed-off-by: to progress upstream of course
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
From: Alan Cox a...@linux.intel.com
Kirill Shutemov found problems with the non-upstream IMG driver where the
use of extra DRM encoder/connector types caused random crashes when the DRM
layer tried to display their matching name. This removes the MIPI types
matching the changes Pauli Nieminen
To sum up, the KGI folks mostly had the right ideas more than a decade
earlier -- but they totally failed to present them in a viable form :-(
Bit more complex IMHO
In the KGI era graphics cards didn't really use main memory much, didn't
have long DMA engine command queues and that made a lot
On Mon, 12 Sep 2011 14:21:26 -0500
Rob Clark rob.cl...@linaro.org wrote:
From: Rob Clark r...@ti.com
Signed-off-by: Rob Clark r...@ti.com
Generally looks sensible but:
1. This is a staging driver, so good practise is to cc the staging
maintainer and preferably the author (though I'm on
3. GMA500 used the old way of doing things because last mail conversation
I had with Hugh the cleaned up interfaces could not guarantee the page is
mapped in the low 32bits and for any of the GMA500/600 series devices.
Has that changed ? I think I'd also prefer it if the methods had a
On Thu, 15 Sep 2011 10:50:32 -0500
Keith Packard kei...@keithp.com wrote:
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkei...@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
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
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
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
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
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.
DSI and the various other MIPI bits tend to be horribly panel and device
specific. In one sense yes its a
Just tell the X driver to not use acceleration, and it you won't get
any acceleration used, then you get complete stability. If a driver
writer wants to turn off all accel in the kernel driver, it can, its
In fact one thing we actually need really is a dumb KMS X server to
replace the fbdev X
This would leave us with the issue of controlling formats and other
parameters
on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that,
There are some other differences that matter. The exact state and
behaviour of memory, sequencing of accesses, cache control and
Well I think for this case the solution is simple: Tiling not allowed
if userspace is too dumb to properly round the buffer up so it
fulfills whatever odd requirement the hw has. I think hiding the fact
that certain buffers need more backing storage than a naive userspace
might assume is ripe
On Thu, 29 Sep 2011 16:26:32 +0100
Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
For the simple KMS driver case we need some more info about argb cursor
limits and a preferred depth and if shadowed framebuffer access is preferred.
I've only added this for
On Thu, 29 Sep 2011 09:43:12 -0700
Eric Anholt e...@anholt.net wrote:
On Thu, 29 Sep 2011 16:26:32 +0100, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
For the simple KMS driver case we need some more info about argb cursor
limits and a preferred depth and if
I don't think that matters for this driver, its totally not for
acceleration, write a real driver if you have some case where copying
algorithms are going to matter.
It will matter if you want a generic dumb server that can handle stuff
like PCI cards as well, but in fact it may well be best
As discussed with Jesse on irc, drm fb handling is fragile. Current rules:
- fbs are not reference counted, hence when destroying we need to disable
all crtcs (and now also planes) that use them. drm_framebuffer_cleanup
does that atm
- drivers that hold onto fbs after the kms core drops
In short decoding these fourcc values with all their implicit assumptions
about offset, strides and whatnotelse will be one giant switch mess. Not
my idea of a nice kernel interface. Also practically guaranteed to result
in slightly different behaviour in each driver.
So you'd rather make
Well the current plan I had for this was to do it in userspace, I don't think
the kernel
has any business doing it and I think for the simple USB case its fine but
will fallover
when you get to the non-trivial cases where some sort of acceleration is
required to move
pixels around. But
From: Alan Cox a...@linux.intel.com
This driver supports unaccelerated KMS display, and accelerated console
handling on the Intel Poulsbo, Oaktrail, Cedarview and Medfield hardware.
For the initial merge Medfield will be left out as it needs considerable
further work to reach a decent standard
From: Alan Cox a...@linux.intel.com
The driver uses GEM along with a couple of small bits of wrapping of its
own. The only real oddity here is the support for using the 'stolen' memory
rather than wasting several MB.
We use a simple resource manager as we don't need to manage our space
From: Alan Cox a...@linux.intel.com
We support 2D acceleration on some devices but we try and do tricks with
the GTT as a starting point as this is far faster. The GTT logic could be
improved further but for most display sizes it already makes a pretty good
decision.
Signed-off-by: Alan Cox
From: Alan Cox a...@linux.intel.com
The devices have various internal differences so we have some abstractions
to hide the ugly differences and we then wrap them up in standard
interfaces. Add these bits
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/gpu/drm/gma500/backlight.c | 49
From: Alan Cox a...@linux.intel.com
Some of this should one day become a library shared by i915 and gma500 I
suspct. Best however to deal with that later once it is all nice and
stably merged.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/gpu/drm/gma500/intel_bios.c | 303
From: Alan Cox a...@linux.intel.com
Again this might be a candidate for sharing later.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/gpu/drm/gma500/intel_i2c.c | 169
1 files changed, 169 insertions(+), 0 deletions(-)
create mode 100644 drivers
From: Alan Cox a...@linux.intel.com
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/gpu/drm/Kconfig |3 +++
drivers/gpu/drm/Makefile |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b493663..7c1cb0d
We're talking about gpus, there's no way an application will talk to them
than through some nice cozy abstraction layer like OpenGl, X, ... Even
Wayland has gbm to do the low-level kms scanout allocation.
You are talking about scanouts. Nothing more. Nothing in KMS/DRM even
requires GPU
The ioremap for stolen RAM is about 8MB - we do actually need that mapped
for the console framebuffer. The GTT tables are pretty small (64K or so)
and the rest of the GTT space if ever used doesn't get an ioremap.
It's a bit different to the i915 world because the CPU cannot indirect
via the GTT
The first poulsbos used to crash badly when attempting to map the GTT
write-combined, and IIRC it didn't even advertise write-combining
capabilities on the PCI BAR. Has this been improved on lately or how is
this handled currently?
It seems to be reliable in the current driver. Whether
So generally we need to provide a userspace interface via ioctls, we
do this with a shared header file that goes in include/drm/ with the
Kbuild bits
At the moment the only public API is the generic bits.
Now I'm assuming psb_drm.h is meant to be this file? but as-is its not
really what I'd
If anyone has problems with the way the formats are defined, please
speak up now! Since only Jesse has bothered to comment on my rantings
I can only assume people are happy with my approach to things.
Umm .. no. I don't see why they are needed. Its just an extra layer of
gratuitious confusing
I think the only format in my list where I didn't use an existing fourcc
is I420/IYUV. And BTW, for that one I used the same fake fourcc that
Right but you redefine all sorts of stuff in the driver in your patch to
non FourCC names which is just confusing (and painful given the format
picked)
From: Alan Cox a...@linux.intel.com
At this point we won't add an external set of definitions. We want to get
everything out before we admit to a public API beyond the standardised
ones.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/gpu/drm/gma500/psb_drm.h | 159
From: Alan Cox a...@linux.intel.com
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/gpu/drm/gma500/gem.c |4 ++--
drivers/gpu/drm/gma500/psb_drm.h | 20 ++--
drivers/gpu/drm/gma500/psb_drv.c | 16
3 files changed, 20 insertions(+), 20
From: Alan Cox a...@linux.intel.com
We don't want this external in case someone adds more to the hardware. We
want it out of the ABI.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/gpu/drm/gma500/psb_drm.h |3 ---
drivers/gpu/drm/gma500/psb_drv.h |2 ++
2 files changed, 2
From: Alan Cox a...@linux.intel.com
Finally move the API where it can be seen
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/gpu/drm/gma500/cdv_device.c |2 -
drivers/gpu/drm/gma500/gem.c |2 -
drivers/gpu/drm/gma500/intel_bios.c |2 -
drivers/gpu
The thing is this is how optimus works, the nvidia gpus have an engine
that you can program to move data from the nvidia tiled VRAM format to
This is even more of a special case than DisplayLink ;-)
Probably a good idea to do some more research on intel/nvidia GPUs.
With intel you can't read
On Sun, 27 Nov 2011 11:08:31 -0500
Ilija Hadzic ihad...@research.bell-labs.com wrote:
Dave Alan:
Maybe I am goofing up something on my end, but gma500 driver on drm-next
branch
won't compile for me. I have to apply the two patches that follow this
note to make it work.
The first is a
On Mon, 5 Dec 2011 19:19:22 -0600
Rob Clark rob.cl...@linaro.org wrote:
+ usergart = kzalloc(3 * sizeof(*usergart), GFP_KERNEL);
+
+ /* reserve 4k aligned/wide regions for userspace mappings: */
+ for (i = 0; i ARRAY_SIZE(fmts); i++) {
+ uint16_t h = 1, w =
I still don't think that's possible. Please explain how you expect
to change the semantics of the streaming mapping API to allow multiple
mappers without having explicit serialization points that are visible
to all users. For simplicity, let's assume a cache coherent system
I would agree.
From: Alan Cox a...@linux.intel.com
Oaktrail Atom E620 has a different PCI identifier we need to cover
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/gpu/drm/gma500/psb_drv.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b
From: Alan Cox a...@linux.intel.com
And update to the actual product naming as the press release is now out.
http://newsroom.intel.com/docs/DOC-2553#pressmaterials
- Fixes the wrong ifdef check
- Fixes the missing crtc count declaration
Signed-off-by: Alan Cox a...@linux.intel.com
From: Alan Cox a...@linux.intel.com
This doesn't work and isn't of any use. It was inherited from the older
driver code and can go away. Kill it off before it becomes part of mainstream
as we don't want to support it in future.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/gpu/drm
From: Alan Cox a...@linux.intel.com
And update to the actual product naming as the press release is now out.
http://newsroom.intel.com/docs/DOC-2553#pressmaterials
- Fixes the wrong ifdef check
- Fixes the missing crtc count declaration
Signed-off-by: Alan Cox a...@linux.intel.com
On Tue, 3 Jan 2012 19:04:00 +0100
Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
It can be called from atomic context, e.g. when switching to console for panic
output.
Is this only special cases like a panic - if so can it not be called in a
way that
On Tue, 03 Jan 2012 19:25:46 +0100
Michel Dänzer mic...@daenzer.net wrote:
On Die, 2012-01-03 at 18:09 +, Alan Cox wrote:
On Tue, 3 Jan 2012 19:04:00 +0100
Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
It can be called from atomic
So lets stick to practice, and the real world. Screwing up everything
else because of a crappy problem in your Atom BIOS code sucks but hey it
happens. screwing up everything because of a theoretical concern is just
dumb.
Thanks for the flowers, but it's not just a theoretical concern,
...@oracle.com
---
Compile tested only.
It's actually a non-bug (no 64bit boxes and we always take from within
the low 32bits). I guess gcc would have to extremely smart to figure
that out though.
Acked-by: Alan Cox a...@linux.intel.com
___
dri-devel
I think Alan's simply wrong.
In what way ? You stated this, then go on below to say what I did ?
Splattering the entire driver for
these two corner cases which don't happen at all under normal
circumstances is imho utter nonsense.
Which is what I said
| Is this only special cases like a
Every modesetting operation can happen in atomic context or not in
atomic context, thanks to the wonder of oops printing and also kgdb,
trying to figure out which table in this one person's bios is the
root cause and special casing for it is insane since tomorrow 20
other BIOSes could contain
1 - 100 of 665 matches
Mail list logo
