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 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
> 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 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
> 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
> 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
; 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 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
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: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 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
On Mon, 2015-05-04 at 18:29 -0400, Nicholas Krause wrote:
> This removes the deprecated functions,i2c_dp_aux_add_bus and
> i2c_dp_aux_prepare_bus and the only call in the function,
> cdv_intel_dp_i2c_init to i2c_dp_aux_add_bus respectfully.
> The call and use of these functions is now replaced al
)
> Signed-off-by: Dan Carpenter
#facepalm
Acked-by: Alan Cox
On Mon, 2015-01-12 at 17:12 +0100, Thierry Reding wrote:
> On Mon, Jan 12, 2015 at 01:29:27PM +0000, Alan Cox wrote:
> > On Sat, 2015-01-10 at 23:31 -0500, Nicholas Krause wrote:
> > > Changes various calls in the functions,send_pkg_prepare and send_pkg_done
> > >
On Sat, 2015-01-10 at 23:31 -0500, Nicholas Krause wrote:
> Changes various calls in the functions,send_pkg_prepare and send_pkg_done
> for mdelay to msleep. These changes are needed due to use working with
> various sleep modes supported by this hardware and thus needing to sleep
> for a small dur
already much more helper functions (including the entire mst library)
> > on top of them. Since no one seems to work on converting gma500 let's
> > just move the code away so that new drivers don't end up accidentally
> > using this.
>
> Thanks for doing this! I&#x
> 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
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 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 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 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 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 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
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
> 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
> 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, 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
> > 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
> 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
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
> > 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
> 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
> > 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/
> > 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/
> > 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
> 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
> 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
> > 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
> 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
> 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
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
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
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 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
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
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 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
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
> 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
> 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, 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
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
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 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 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 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.
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
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
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
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 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
> 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
> 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 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
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
y: Fengguang Wu
> Signed-off-by: Jani Nikula
Signed-off-by: Alan Cox
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 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
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
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
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
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
> 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
> 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
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
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
. 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: 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
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
. 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: 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
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
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
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
y the workaround if the device has DP. We don't want
to do this on netbooks]
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 24
drivers/gpu/drm/gma500/psb_intel_reg.h |4
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/
based upon the i915 one. It's only really used for backlight bits
and we have a perfectly good backlight abstraction which can extend instead.
Signed-off-by: Zhao Yakui
[ported to upstream driver, redid backlight abstraction]
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/backli
From: Alan Cox
This will give the basic support only
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_device.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index e2fff24
From: Alan Cox
This is mostly just aligning bits of behaviour
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/Makefile|3
drivers/gpu/drm/gma500/cdv_intel_display.c |6
drivers/gpu/drm/gma500/cdv_intel_dp.c | 480 ++--
drivers/gpu/drm
From: Alan Cox
Based on bits from Yakui
We can import various little bits of code before we plumb it all
in and hopefully this way catch any regressions more easily.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_device.c| 59 +
drivers/gpu/drm/gma500
From: Alan Cox
Add the support of display port on CDV
Import the pieces we need in order to do DisplayPort. Don't wire them
up yet as there is work to do to integrate them.
Signed-off-by: Zhao Yakui
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_dp.c |
ff-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 82 +---
drivers/gpu/drm/gma500/cdv_intel_hdmi.c|2 +
drivers/gpu/drm/gma500/psb_intel_drv.h |5 ++
3 files changed, 58 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/g
igned-off-by: Zhao Yakui
[Ported to in kernel driver]
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
apply the workaround if the device has DP. We don't want
to do this on netbooks]
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 24
drivers/gpu/drm/gma500/psb_intel_reg.h |4
2 files changed, 28 insertions(+)
diff --git a/drive
based upon the i915 one. It's only really used for backlight bits
and we have a perfectly good backlight abstraction which can extend instead.
Signed-off-by: Zhao Yakui
[ported to upstream driver, redid backlight abstraction]
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/backli
From: Alan Cox
This will give the basic support only
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_device.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index e2fff24
From: Alan Cox
This is mostly just aligning bits of behaviour
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/Makefile|3
drivers/gpu/drm/gma500/cdv_intel_display.c |6
drivers/gpu/drm/gma500/cdv_intel_dp.c | 480 ++--
drivers/gpu/drm
From: Alan Cox
Based on bits from Yakui
We can import various little bits of code before we plumb it all
in and hopefully this way catch any regressions more easily.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_device.c| 59 +
drivers/gpu/drm/gma500
1 - 100 of 716 matches
Mail list logo
