On Wed, 13 Mar 2019 17:54:18 +0300
Alexander Pateenok wrote:
> Hi,
>
> There're several indirect calls in inline assembly in vesafb driver
> (drivers/video/fbdev/vesafb.c), and these calls cannot be automatically
> changed to retpolines. It's in vesafb_pan_display():
>
>73__asm__ __
On Thu, 22 Jun 2017 10:48:13 -0600
Logan Gunthorpe wrote:
> Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y
> and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not
> universally available, it makes them unusable for driver developers.
> This leads to ugly hacks suc
On Thu, 22 Jun 2017 14:24:58 -0600
Logan Gunthorpe wrote:
> On 6/22/2017 2:14 PM, Alan Cox wrote:
> > If a platform doesn't support 64bit I/O operations from the CPU then you
> > either need to use some kind of platform/architecture specific interface
> > if present or
On Thu, 22 Jun 2017 10:48:14 -0600
Logan Gunthorpe wrote:
> Alpha implements its own io operation and doesn't use the
> common library. Thus to make ioread64 and iowrite64 globally
> available we need to add implementations for alpha.
>
> For this, we simply use calls that chain two 32-bit opera
; a console and set it
up separately to actually 'enabling' it when you make it visible and
start scribbling. I don't see any other way to make the changeover
locking saner at this point without still having huge potential stalls in
printk().
Reviewed-by: Alan Cox
On Tue, 2016-09-06 at 19:28 +0800, jiang.biao2 at zte.com.cn wrote:
> Hi,Â
>
> I found current gma500 fbdev driver does not support the virtualÂ
> mapping for the fb pages, instead it only uses stolen pages andÂ
> supports high resolution console by reducing the color depth. ItÂ
> works well w
> Adding an entry would make people think that I have time to spend on gma500
> development or is in some way responsible for it. At the moment, that is sadly
> not the case. I have a few things on my todo-list which I intend to fix but
> after that I would much rather work on something more produc
> If you want to actually lock down a machine to implement content
> protection, then you need secure boot without unlockable boot-loader and a
> pile more bits in userspace.
So let me take my Intel hat off for a moment.
The upstream policy has always been that we don't merge things which
don't
> How about for sensitive video streams in government offices where you
> want to avoid a spy potentially tapping the cable to see the video
> stream?
Last time I checked HDCP did not meet government security requirements -
which is hardly surprising since you can buy $10 boxes from China to
de-hd
On Tue, 19 Dec 2017 19:40:12 +0100
Max Staudt wrote:
> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
> > On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote:
> >> Well, those could enable fbcon if they want the bootsplash. Shouldn't make
> >> a difference anyway if they're powerful enough to run
> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
> But most likely you want this on a highly embedded system, which
It wouldn't be in kernel on such a device, it'll be in the bootstrap
before (or on a dual core device quite possibly while) the kernel data is
being uncompress
On Tue, 19 Dec 2017 15:07:53 +0100
Oliver Neukum wrote:
> Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter:
> > > Would you like me to extend the FB API or not?
> >
> > Yes. Well for real I'd like you to do kms, so maybe you need to explain
> > why exactly you absolutely have to
On Sat, 24 Nov 2012 09:15:51 +0200
Tomi Valkeinen wrote:
> On 2012-11-23 21:56, Thierry Reding wrote:
> > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> > [...]
> >> Display entities are accessed by driver using notifiers. Any driver can
> >> register a display entity notifie
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.
On Wed, 10 Oct 2012 08:56:32 -0700
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
> 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
> The whole purpose of this API is to let DRM and V4L drivers share buffers for
> zero-copy pipelines. Unfortunately it is a fact that several popular DRM
> drivers
> are closed source. So we have a choice between keeping the export symbols GPL
> and forcing those closed-source drivers to make the
> > So, developers implicitly or explicitly copied in this thread that might be
> > considering the usage of dmabuf on proprietary drivers should consider
> > this email as a formal notification of my viewpoint: e. g. that I consider
> > any attempt of using DMABUF or media core/drivers together wi
> > Then they can 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.
>
> But then why object to the change, your objection makes sense, naking
> the patch makes none, if you believe in your objection.
[l/
> I believe that the developers and maintainers of dma-buf have provided
> the needed signoff, both in person and in this thread. If there are any
> objections from that group, I'm happy to discuss any changes necessary to get
> this merged.
You need the permission of the owners of all the depend
> > 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.
>
> Alan please stick with the facts. Thi
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
> That (walking all parent nodes) is probably the safest thing to do. I'm
> not sure whether it's optimal. It would likely depend on whether you
> can meaningfully have a bridge that's faster on the downstream side than
> on the upstream.
This is architecture goo at heart - would this be bett
On Wed, 5 Sep 2012 01:53:44 +
"Liu, Chuansheng" wrote:
> This patch is for introducing the irq thread support in drm_irq.
>
> Why we need irq thread in drm_irq code?
> In our GPU system, the gpu interrupt handler need some time even > 1ms to
> finish,
> in that case, the whole system will s
> fine grained suspend/resume. Not sure if that concept helps here, but it
> may be worth digging around to see how they went about waking up
> individual devices.
Badly. I don't believe the code ever worked properly. It certainly was
full of races. I've reworked chunks of it in the GMA500 oaktrai
On Mon, 10 Sep 2012 14:31:52 +1000
Dave Airlie wrote:
> From: Dave Airlie
>
> For secondary GPUs in laptops, i.e. optimus or powerxpress, we have
> methods for powering down the GPU completely. This adds support
> to the drm core for powering back up the GPU on any access from
> ioctls or sysfs
From: Alan Cox
The register map patches didn't set one value for the GMA600 which
means the Fujitsu Q550 dies on boot with the GMA500 driver enabled.
Add the map entry so we don't read from the device MMIO + 0 by mistake.
Signed-off-by: Alan Cox
Cc: Horses
---
drivers/gpu/
On Sat, 24 Nov 2012 09:15:51 +0200
Tomi Valkeinen wrote:
> On 2012-11-23 21:56, Thierry Reding wrote:
> > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> > [...]
> >> Display entities are accessed by driver using notifiers. Any driver can
> >> register a display entity notifie
On Fri, 21 Dec 2012 18:47:57 +0900
Eunchul Kim wrote:
> HDCP stands for High-bandwidth Digital Content Protection.
> This is a newer form of Digital Rights Management(secure DRM)
was.. the master key was leaked long ago 8)
> that was designed to control digital video and audio content.
> Contai
On Thu, 10 Jan 2013 21:47:53 +0100
Daniel Vetter wrote:
> Only two places:
> - suspend/resume
> - Some really strange mode validation tool with too much funny-lucking
> hand-rolled conversion code.
> - The recently-added lastclose fbdev restore code.
>
> Better safe than sorry, so convert both
On Sun, 12 Aug 2012 10:04:47 -0400
Forest Bond wrote:
> Hi,
>
> > Subject: Re: [PATCH 2/3] gma: psb_intel_crtc: Drop crtc_enable flag.
>
> So obviously this should have read "gma500: ..." Let me know if I should
> resend.
No need. I'll pick these up and test them on the problem board here as
From: Forest Bond
Signed-off-by: Forest Bond
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index bfb0565
From: Forest Bond
This is set when setting DPMS on and off, but it isn't checked anywhere,
so just remove it.
Signed-off-by: Forest Bond
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c |2 --
drivers/gpu/drm/gma500/psb_intel_drv.h |1 -
2 files chang
. Without it, mode
setting triggers an out-of-range error from the monitor for most modes,
but only on initial configuration (i.e. they can be configured
successfully from userspace after that).
Signed-off-by: Forest Bond
Signed-off-by: Alan Cox
Cc: Stables
---
drivers/gpu/drm/gma500
From: Alan Cox
If you do a page flip with no flags set then event is NULL. If event is
NULL then the vmw_gfx driver likes to go digging into NULL and extracts
NULL->base.file_priv.
On a modern kernel with NULL mapping protection it's just another oops,
without it there are some &qu
> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful), I think I found the race.
Direct netconsole write would be a useful patch to have mainline I think
8)
> Hopefully this fixes the problem for anyone seeing vesafb->kms
> driver handoff.
Not really
From: Alan Cox
We should be making this call not praying that the values are right.
In addition as noted by Josiah Standing we should be calling this
for eDP as well.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c |4 ++--
1 file changed, 2 insertions(+), 2
On Wed, 22 Aug 2012 00:34:30 +0200
Daniel Vetter wrote:
> Hi all,
>
> After Dave Airlie blew through a few days to track down a deadlock at boot-up
> when handing over from the firmware fb to the kms/drm framebuffer driver (1),
> I've
> figured that lockdep /should/ have caught this.
>
> And i
On Thu, 23 Aug 2012 12:03:59 +0200
Laurent Pinchart wrote:
> Hi Alan,
>
> On Tuesday 17 July 2012 17:21:06 Alan Cox wrote:
> > On Tue, 17 Jul 2012 17:09:25 +0200 Laurent Pinchart wrote:
> > > On Wednesday 16 May 2012 16:10:37 Alan Cox wrote:
> > > > On Wed
y: Fengguang Wu
> Signed-off-by: Jani Nikula
Signed-off-by: Alan Cox
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, 5 Sep 2012 01:53:44 +
"Liu, Chuansheng" wrote:
> This patch is for introducing the irq thread support in drm_irq.
>
> Why we need irq thread in drm_irq code?
> In our GPU system, the gpu interrupt handler need some time even > 1ms to
> finish,
> in that case, the whole system will s
> fine grained suspend/resume. Not sure if that concept helps here, but it
> may be worth digging around to see how they went about waking up
> individual devices.
Badly. I don't believe the code ever worked properly. It certainly was
full of races. I've reworked chunks of it in the GMA500 oaktrai
On Mon, 10 Sep 2012 14:31:52 +1000
Dave Airlie wrote:
> From: Dave Airlie
>
> For secondary GPUs in laptops, i.e. optimus or powerxpress, we have
> methods for powering down the GPU completely. This adds support
> to the drm core for powering back up the GPU on any access from
> ioctls or sysfs
From: Alan Cox
The register map patches didn't set one value for the GMA600 which
means the Fujitsu Q550 dies on boot with the GMA500 driver enabled.
Add the map entry so we don't read from the device MMIO + 0 by mistake.
Signed-off-by: Alan Cox
Cc: Horses
---
drivers/gpu/
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
On Thu, 13 Sep 2012 11:38:20 +1000
Dave Airlie wrote:
> > 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.
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
> 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.
Alan
__
On Fri, 28 Sep 2012 09:27:18 +0200
Rob Clark wrote:
> From: Rob Clark
>
> When disabling unused connectors, be sure to call connector->dpms(OFF),
> so if there is actually some IP to turn off (such as external bridge
> chips, etc), these actually do get turned off.
That's a fairly drastic and
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
On Wed, 10 Oct 2012 08:56:32 -0700
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
> 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 mailing list
dr
> The whole purpose of this API is to let DRM and V4L drivers share buffers for
> zero-copy pipelines. Unfortunately it is a fact that several popular DRM
> drivers
> are closed source. So we have a choice between keeping the export symbols GPL
> and forcing those closed-source drivers to make the
> > So, developers implicitly or explicitly copied in this thread that might be
> > considering the usage of dmabuf on proprietary drivers should consider
> > this email as a formal notification of my viewpoint: e. g. that I consider
> > any attempt of using DMABUF or media core/drivers together wi
> > Then they can 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.
>
> But then why object to the change, your objection makes sense, naking
> the patch makes none, if you believe in your objection.
[l/
> I believe that the developers and maintainers of dma-buf have provided
> the needed signoff, both in person and in this thread. If there are any
> objections from that group, I'm happy to discuss any changes necessary to get
> this merged.
You need the permission of the owners of all the depend
> > 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.
>
> Alan please stick with the facts. Thi
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
> That (walking all parent nodes) is probably the safest thing to do. I'm
> not sure whether it's optimal. It would likely depend on whether you
> can meaningfully have a bridge that's faster on the downstream side than
> on the upstream.
This is architecture goo at heart - would this be bett
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
> 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
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
On Thu, 29 Sep 2011 09:43:12 -0700
Eric Anholt wrote:
> 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
> > prefe
> 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 bes
> the front buffer. The problem was the buffer offset for the second
> allocation was the same as the VQ buffer. I'm stump to what I'm doing
> wrong, so does anyone have a idea?
I gave up trying to understand TTM (they don't make happy pills that big)
and used GEM and a simple allocator. The pri
> 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
On Fri, 21 Oct 2011 09:08:30 +0200
Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. A
> value of 40 as the nouveau driver has is even slower at 12.5 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and com
> 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 dro
> 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.
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
> 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 acce
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
> 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
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
> 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 r
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.
>
> The first is a trivial oversight, but
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;
> +
> 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
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
1 - 100 of 716 matches
Mail list logo
