From: Alan Cox
There are still some mysteries left, in particular how (and in
fact if) the EDID is supposed to work on the HDMI port. However
the basic stuff now works and I can plug my Q550 into an HDMI
display and get the expected results.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500
r then I'll send you a couple of follow up patches to
clean up the driver further fairly soon.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, 14 Sep 2012 14:38:10 +0200
Laurent Pinchart wrote:
> Hi Dave,
>
> The SH Mobile DRM driver is now (in my opinion) ready for mainline. It
> requires GEM and KMS/FB helpers that have been reviewed on the list and
> tested. Sascha is waiting for them to reach your tree to send a pull requ
On Fri, 14 Sep 2012 15:05:44 +0200
Laurent Pinchart wrote:
> Hi Alan,
>
> On Friday 14 September 2012 13:47:33 Alan Cox wrote:
> > On Fri, 14 Sep 2012 14:38:10 +0200 Laurent Pinchart wrote:
> > > Hi Dave,
> > >
> > > The SH Mobile DRM driver is
use the common section numbers for the rest.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.f
> This happens _only in X_ and not on the console. My system and Xorg is
> very old. (Ubuntu 9.10).
Make sure you have the framebuffer driver in use not the vesa one if
you are using an old X11. If you use the vesa driver then randomness
will occur.
;s a fairly drastic and non-obvious API change for all the other
drivers. Have you tested this widely on other hardware ?
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Alan Cox
There are still some mysteries left, in particular how (and in
fact if) the EDID is supposed to work on the HDMI port. However
the basic stuff now works and I can plug my Q550 into an HDMI
display and get the expected results.
[v2: cleans up space/tab and other formatting as per
On Sun, 7 Oct 2012 21:56:45 +0800
Wei Yongjun wrote:
> From: Wei Yongjun
>
> The dereference should be moved below the NULL test.
The !dev check just wants removing I think - it's a bogus check in the
first place.
___
dri-devel mailing list
dri-devel
as a (and the view
of many other) rights holder to the kernel likely to be in breach
of the GPL requirements for a derivative work. You may consider that
formal notification of my viewpoint. Your corporate legal team can
explain to you why the fact you are now aware of my view
> As long as dmabuf uses EXPORT_SYMBOL_GPL that is definitely correct. Does your
> statement also hold if dmabuf would use EXPORT_SYMBOL? (Just asking)
Yes. The GPL talks about derivative works (as does copyright law).
Alan
___
dri-devel mailin
accept the risk of ignoring EXPORT_SYMBOL_GPL and
calling into it anyway can't they. Your argument makes no rational sense
of any kind.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
rs corporate legal contacts
and then work down the call tree involved.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
en why do they care about
the _GPL being significant ?
Nouveau can call the DMA buf methods.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
rporate attorneys. If you want to relicense components of the code
then please take the matter up with the corporate attorneys of the rights
holders concerned.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mai
> > Please go and discuss estoppel, wilful infringement and re-licensing with
> > your corporate attorneys. If you want to relicense components of the code
> > then please take the matter up with the corporate attorneys of the rights
> > holders concerned.
>
> Al
On Wed, 17 Oct 2012 20:22:04 +1000
Dave Airlie wrote:
> On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox wrote:
> >> > Please go and discuss estoppel, wilful infringement and re-licensing with
> >> > your corporate attorneys. If you want to relicense components of the code
oo at heart - would this be better as a helper in
the PCI and arch PCI code ?
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Alan Cox
There are still some mysteries left, in particular how (and in
fact if) the EDID is supposed to work on the HDMI port. However
the basic stuff now works and I can plug my Q550 into an HDMI
display and get the expected results.
[v2: cleans up space/tab and other formatting as per
or some of the other interfaces like the dumb fb api it's even more
important the code doesn't know.
I don't however think the helper should know about padding because I
think a driver can implement its own function which wraps the helper and
t
On Thu, 29 Sep 2011 16:26:32 +0100
Dave Airlie wrote:
> From: Dave Airlie
>
> 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 intel/radeon which support the dumb
> >
> > If you need something really fancy you should be writing a real X.org
> > driver.
>
> Would prefer_shadow ever be 0?
Devices which are fully cache coherent with the CPU are probably a good
example. No point running back buffers then. Also any device w
it may well be best if the X server
simply does some timings.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ans a modern X will not care about the hardware cursor ?
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
> Thats fine as long as you don't want to do acceleration or object
> migration between GTT
> and VRAM type memory. Now I expect when you give out this advice you
Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
It's all effectively in the GART with the 'stolen' pages pre
devices (and compliant devices can always stretch the clock is
> needed.)
That depends on your cable, drive and signal quality. It's not something
you just turn up because it seems a good idea. Reliability is MUCH more
important than shaving microseconds off monito
ng, fb moving etc are ugly issues, refcount shouldn't
be, and the tty layer also refcounts so we can only have the fb objects
themselves to worry about as we can defer fb destruction to tty close or
drm last unref even for those with consoles on them.
Alan
e and form).
I think the idea of sharing kernel drm code is pretty much dead, yeah.
We are still trying to keep it alive, despite what some may think.
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window S
> 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
nvered in the documentation is the handling of
fencing between cards. Eg if you wanted to do display on one card fed
into a second to do effects processing (think about TV type stuff)
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Alan Cox
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
Begin by adding the
From: Alan Cox
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
intensively at
From: Alan Cox
This fits alongside the GEM support to manage our resources on the card
itself. It's not actually clear we need to configure the MMU at all.
Further research is needed before removing it entirely. For now we suck it
in (slightly abused) from the old semi-free driver.
Signe
From: Alan Cox
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
---
drivers/gpu/drm
From: Alan Cox
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
---
drivers/gpu/drm/gma500/backlight.c | 49 ++
drivers/gpu/drm/gma500/power.c
From: Alan Cox
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
---
drivers/gpu/drm/gma500/intel_bios.c | 303 ++
drivers/gpu/drm
From: Alan Cox
Again this might be a candidate for sharing later.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/intel_i2c.c | 169
1 files changed, 169 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/gma500/intel_i2c.c
diff --git
From: Alan Cox
Signed-off-by: Alan Cox
---
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 100644
--- a/drivers/gpu/drm/Kconfig
er - that one should use Xv or some fancy EGLImage extension.
Or quite likely in many embedded circumstances be working directly with
buffers and FourCC. Just like happens now with V4L. FourCC has its ugly
corners but its trivial to turn it into a table if you have a driver that
requires this. Old hat,
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 b
> 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
> 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 confusin
with the idea that you can pass in a
FourCC *or* a format specifying structure, or with an internal API where
a fourCC is always internally turned into a struct of offsets and other
useful info before hitting the drivers)
Alan
___
dri-devel mailing list
From: Alan Cox
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
---
drivers/gpu/drm/gma500/psb_drm.h | 159 ++--
drivers/gpu/drm/gma500/psb_drv.c |
From: Alan Cox
Signed-off-by: Alan Cox
---
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 deletions(-)
diff --git a/drivers/gpu/drm
From: Alan Cox
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
---
drivers/gpu/drm/gma500/psb_drm.h |3 ---
drivers/gpu/drm/gma500/psb_drv.h |2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff
From: Alan Cox
Finally move the API where it can be seen
Signed-off-by: Alan Cox
---
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/drm/gma500/mid_bios.c|2
;lets both use this buffer
format') or 'I can render then convert' is one thing. Dealing with two
GPUs firing into the same buffer while scanning it out I just pray
doesn't ever need shared fences.
Alan
___
dri-devel mailing l
On Sun, 27 Nov 2011 11:08:31 -0500
Ilija Hadzic 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.
>
>
On Mon, 5 Dec 2011 19:19:22 -0600
Rob Clark 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 = PAGE_SIZE >> i;
> +
eal with, it requires high level
knowledge.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Alan Cox
Oaktrail Atom E620 has a different PCI identifier we need to cover
Signed-off-by: Alan Cox
---
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/drivers/gpu/drm/gma500/psb_drv.c
index
From: Alan Cox
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
---
drivers/gpu/drm/gma500/Kconfig |7
From: Alan Cox
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
---
drivers/gpu/drm/gma500/p
From: Alan Cox
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
---
drivers/gpu/drm/gma500/Kconfig |7
On Tue, 3 Jan 2012 19:04:00 +0100
Michel Dänzer wrote:
> From: Michel Dänzer
>
> 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 distinguishes between normality and nast
On Tue, 03 Jan 2012 19:25:46 +0100
Michel Dänzer wrote:
> On Die, 2012-01-03 at 18:09 +0000, Alan Cox wrote:
> > On Tue, 3 Jan 2012 19:04:00 +0100
> > Michel Dänzer wrote:
> >
> > > From: Michel Dänzer
> > >
> > > It can be called from at
ut it's not just a theoretical concern, see the
> bug report.
The bug report is a single specific case. Figure out the calling
paths afflicted by it, don't be lazy and just dump on everyone on every
path because of a special case you appare
> 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
___
dri-devel mailing list
dri-dev
so means any accidental changes
that affect this will result in spewage and debugging not silent trashing
of performance for stuff like machine control, music and some gaming.
It should only be for panic, although accel calls for printk spewage can
hit in atomic context in some sit
mdelay(count);
}
}
so that we know it isn't getting hit in places we've not carefully
considered the impact of a huge stall.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
e need the mark up.
If some vendor puts a 100ms delay in a connector related hotplug check we
are going to have a horrible time debugging 'bugzilla #zillion, 'poor
performance in OpenGL game with Radeon foozillion'
Alan
___
dr
bad cess pit, every time you poke it the
smell drives you back to other things.
> But as I've said I like the WARN_ON you want to add, but otoh hand think
> it shouldn't be used to stall the small&hackish fix of adding the relevant
Signed-off-by: Patrik Jakobsson
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_crt.c |6 ++
drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 14 ++
drivers/gpu/drm/gma500/oaktrail_hdmi.c |6 ++
drivers/gpu/drm/gma500/psb_intel_sdvo.c |6 ++
4 fi
From: Alan Cox
GMA500 did it the old way and it's been on the TODO list to fix. Current kernels
will now blow up if we use the old way so we need this change in.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/gtt.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
On Tue, 17 Jan 2012 16:08:17 -0800
Robert Morell wrote:
> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> issue, and not really an interface". The dma-buf infrastructure is
> explicitly intended as an interface between modules/drivers, so it
> should use EXPORT_SYMBOL
lly outside the GPL and I am doubtful that in most cases a work
containing binary modules for a Linux kernel is compatible with the
licensing, although I accept there may be some cases that it is.
Alan
___
dri-devel mailing list
dri-devel@lists.freedeskt
e somehow
magically outside the GPL and I am doubtful that in most cases a work
containing binary modules for a Linux kernel is compatible with the
licensing, although I accept there may be some cases that it is.
Alan
___
dri-devel mailing list
dri-devel
sation of fb.
>
> Signed-off-by: Ryan Mallon
Yes that wants fixing
Acked-by: Alan Cox
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
;fbops = &psbfb_unaccel_ops;
and see if that fixes it.
If so I know what is going on.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
mp.video.dri.devel/5455/focus=6779
There stills seems to be five uses that should be checked.
src/gallium/drivers/r600/r600_pipe.c
src/gallium/drivers/nouveau/nouveau_fence.c
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
src/gallium/winsys/radeon/
if test "x$INTEL" != "xno"; then
- case $host_os in
- i?86-*|x86_64-*) INTEL=yes ;;
+ case $host_cpu in
+ i?86|x86_64) INTEL=yes ;;
*) INTEL=no ;;
esac
e the hostnames
to resolve to 131.252.210.176 instead of the DNS reported 131.252.210.161.
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
___
dri-devel mailing list
dri-
quot;all KMS" - but for any given card either/or seems
perfectly reasonable.
The big thing that is needed is someone crazy enough to write a KMS
driver to replace vesa/uvesafb and the like.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.
From: Alan Cox
This was reported a long time ago (and I apologize to whoever it was that
reported it as I've lost the original report).
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gp
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/framebuffer.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 791c0ef..97d5b80 100644
--- a/drivers/gpu/drm
(Resending in two bits to avoid stgit breakage)
From: Alan Cox
This was reported a long time ago (and I apologize to whoever it was that
reported it as I've lost the original report).
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.c |1 +
1 files changed, 1 insertions(
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/framebuffer.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 791c0ef..97d5b80 100644
--- a/drivers/gpu/drm
From: Alan Cox
Some this is Medfield stuff that may reappear in some form later, other
bits are just dead stuff
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/oaktrail_crtc.c |3 -
drivers/gpu/drm/gma500/psb_drv.h | 94 +---
2 files changed, 2
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 27 ++-
drivers/gpu/drm/gma500/cdv_intel_lvds.c|6 -
drivers/gpu/drm/gma500/oaktrail_device.c | 204 +
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 72
From: Alan Cox
Update this to better reflect the status
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/Kconfig |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 754e14b..f92a7f4 100644
--- a
ector:'
label - kfree() deals gracefully with NULL pointers, so it is not
needed.
Signed-off-by: Jesper Juhl
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_intel_lvds.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_
Signed-off-by: Alan Coopersmith
---
include/drm/drm_fourcc.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index b1107cb..85facb0 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -24,10
On Fri, 3 Feb 2012 10:15:41 +
Dave Airlie wrote:
> On Thu, Feb 2, 2012 at 3:17 PM, Alan Cox wrote:
> > (Resending in two bits to avoid stgit breakage)
>
> Hi Alan,
>
> Any of these important enough for -fixes? or -next good enough?
The cache one maybe the others can
> My system boots up, loads drm, loads gma500_gfx, and then my monitor's
> OSD says "Out of Frequency". Pretty much the same behavior with the
> old psb_gfx module and the new gma500_gfx module.
They are all basically the same logic until the most recent release which
at least queries the monitor
On Fri, 10 Feb 2012 20:04:52 +0800
Axel Lin wrote:
> The first parameter should be "number of elements" and the second parameter
> should be "element size".
>
> Signed-off-by: Axel Lin
Acked-by: Alan Cox
___
you: Should system_nrt_wq be made freezable, or
should I create a new workqueue that is both freezable and
non-reentrant? And if I do, which of the usages above should be
converted to the new workqueue?
Thanks,
Alan Stern
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, 16 Feb 2012, Tejun Heo wrote:
> Hello, (cc'ing Rafael and Jens)
>
> On Thu, Feb 16, 2012 at 09:41:34AM -0500, Alan Stern wrote:
> > My question to all of you: Should system_nrt_wq be made freezable, or
> > should I create a new workqueue that is both freeza
e's my proposed patch. If nobody objects, I'll submit it to Rafael
with an appropriate patch description. Then anybody who wants can
convert over to the new workqueue.
Alan Stern
block/genhd.c | 10 +-
include/linux/workqueue.h |
On Thu, 16 Feb 2012, Tejun Heo wrote:
> Hello,
>
> On Thu, Feb 16, 2012 at 11:37:33AM -0500, Alan Stern wrote:
> > Um. I don't think I can audit all the calls in the kernel that submit
> > block requests and determine which ones need to be allowed while a
>
-events polling.
Signed-off-by: Alan Stern
CC: Tejun Heo
CC:
---
I'm not sure who to send this patch to, since it is relevant to both
the block and PM subsystems. Jens, is it okay if Rafael takes it?
block/genhd.c | 10 +-
include/linux/workqueue.h |4
uffers.
The end result is faster than most accelerated 2D scrolls unsurprisingly.
Even faster would be to map enough of the start of the object on the end
of the range in repeat and just roll the frame buffer base. That would
get it down to a couple of 32bit I/O writes..
From: Alan Cox
[Resending with correct address for Linus]
Production GMA3600/3650 hardware turns out to be subtly different to the
development platforms. This combined with a minor driver bug is causing
the kernel to hang on these platforms.
This patch does the following
- turn down a couple
Start the clean up work and add Medfield support
---
Alan Cox (6):
gma500: rework register stuff sanely
gma500: re-order calling on the fix setup so we set up after the DRM layer
gma500: Kconfig documentation tweak
gma500: now move the Oaktrail save state into its own
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/framebuffer.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index c1c4dc1..9738229 100644
--- a/drivers/gpu/drm
From: Alan Cox
Some this is Medfield stuff that may reappear in some form later, other
bits are just dead stuff
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/oaktrail_crtc.c |3 -
drivers/gpu/drm/gma500/psb_drv.h | 94 +---
2 files changed, 2
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 27 ++-
drivers/gpu/drm/gma500/cdv_intel_lvds.c|6 -
drivers/gpu/drm/gma500/oaktrail_device.c | 204 +
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 72
From: Alan Cox
Update this to better reflect the status
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/Kconfig |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 754e14b..f92a7f4 100644
--- a
ector:'
label - kfree() deals gracefully with NULL pointers, so it is not
needed.
Signed-off-by: Jesper Juhl
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_intel_lvds.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_
401 - 500 of 1417 matches
Mail list logo
