From: Alan Cox <a...@linux.intel.com>
Some devices don't have a panel connected to LVDS and thus will never power up.
This patch checks the power sequence progress bits in PP_STATUS to prevent an
endless loop on such devices.
Signed-off-by: Patrik Jakobsson
Signed-off-by: Al
From: Alan Cox <a...@linux.intel.com>
Reported-by: Guillaume Cl?ment
Signed-off-by: Alan Cox
Cc:
---
drivers/gpu/drm/gma500/psb_device.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_device.c
b/drivers/gpu/drm/gma500/psb_de
On Fri, 25 May 2012 04:53:50 +0900
Greg KH wrote:
> On Mon, May 21, 2012 at 11:23:36PM +0800, Lee, Chun-Yi wrote:
> > In v3.3, the gma500 drm driver moved from staging to drm group by
> > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
> > brightness well and don't need gma500
From: Alan Cox <a...@linux.intel.com>
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 spa
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
From: Alan Cox <a...@linux.intel.com>
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 spa
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
> > 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
> > 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.
> 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
> > 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.
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 c
> 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
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
> 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
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
From: Alan Cox <a...@linux.intel.com>
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
---
d
From: Alan Cox <a...@linux.intel.com>
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: Al
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
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
> 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
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
ned-off-by: Dan Carpenter
#facepalm
Acked-by: Alan Cox
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
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 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
From: Alan Cox <a...@linux.intel.com>
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
From: Alan Cox <a...@linux.intel.com>
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
From: Alan Cox <a...@linux.intel.com>
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/
r adds a panel
abstraction 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/g
pdated to only 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
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 <forest.b...@rapidrollout.com>
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/
From: Forest Bond <forest.b...@rapidrollout.com>
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
Intel DN2800MT (Cedarview) board. 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
---
d
From: Alan Cox <a...@linux.intel.com>
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
> 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 <a...@linux.intel.com>
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 chan
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
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
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.
>
> 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
On Mon, 12 Sep 2011 14:21:26 -0500
Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
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 dri-devel so its ok).
It needs to be
> > 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
On Thu, 15 Sep 2011 10:50:32 -0500
Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
> wrote:
>
> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> > the plan is to make DRM the core Linux display framework, upon which
> > everything else is
> 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
> 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
> 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
> 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
> Okay, I see your problem. It's a bit strange you don't have acceleration. I
The hardware has 3D acceleration but not open so we can't support it.
There is no 2D acceleration - which seems to be increasingly common.
At some point I'll add hardware scrolling however by using the GTT to
> 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
> 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
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
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
> >
> 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
> the VT-emulation in the kernel. And then we still need to figure out a
> way to make the kernel spit console-log to the display while
> booting/etc. However, I plan to provide a prototype that works with
> CONFIG_VT=n to at least get some testing environment. I'll keep
> dri-devel informed if I
On Wed, 11 Apr 2012 14:10:26 +0200
Thierry Reding wrote:
> This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It
> currently only supports the RGB output and I've successfully tested it
> against the fbcon kernel module and the xf86-video-modesetting driver.
> The code uses the
> Hm, in that case it looks like your iommu works more like the gtt on intel
> chips
Don't overgeneralize there - on the GMA500/600 the GTT doesn't allow CPU
side access of the GTT map (ie you can't use it to linearise pages for
CPU view) and the 3600 is even stranger
Alan
> Maybe your question is answered by my reply to Alan's comment. The mapping
> is actually done to get a linear view for the display controller which
> doesn't support SG transfers. The kernel and user-space already have virtual
> linear buffers.
The framebuffer currently needs a physically
> Heh, vmap() is exactly what I do. =) Would you mind explaining why exactly it
> is hideous?
On x86 we don't have a vast amount of address space available for virtual
remappings and the framebuffer then eats over 8MB of it.
The ideal case is that the fb layer can be taught to do page/offset
> +static int sdrm_suspend(struct drm_device *drm, pm_message_t state)
> +{
> + /* TODO */
> +
> + return 0;
> +}
> +
> +static int sdrm_resume(struct drm_device *drm)
> +{
> + /* TODO */
> +
> + return 0;
> +}
These probably need to call into the sdrm device specific handling.
On Thu, 12 Apr 2012 00:05:29 +0200 (CEST)
Jesper Juhl wrote:
> drivers/gpu/drm/gma500/mdfld_dsi_output.h does not need to
> '#include ' - so don't.
>
> Signed-off-by: Jesper Juhl
Acked-by: Alan Cox
> How do you ensure that no device can do DMA on the buffer while it's mapped
> into user space in a noncoherent manner?
Why do we want to enforce that ? We provide the appropriate base service
but you need to know what you are doing. In reality a lot of use cases
are going to need far more than
> That frequency seems about the same as the one I'm experiences. All though
> some times it's more often, but I can't say I've done anything special at
> the same time.
>
> 3.3.2-1-ARCH
> Intel(R) Atom(TM) CPU Z520 @ 1.33GHz
>
> Attachment: dmesg ouput
>
What X display server are you using
> This driver has a slightly different design than other KMS drivers, but
> future server chips will probably share similiar setup. As these GPUs commonly
> have low video RAM, it doesn't make sense to put the kms console in VRAM
> always. This driver places the kms console into system RAM, and
> ends up in the in-VRAM object. I'll have to add defio support to make this
> work
> properly now that I think about it a bit more, but defio isn't a major
> amount of work.
Ok
> fbdev objects once exposed to userspace or to fbcon, thanks to some wonderful
> API design way back, the mmaps on
From: Alan Cox <a...@linux.intel.com>
We need to pull more stuff from the VBT in order to configure the clocking
correctly in all cases. Add the relevant bits from the other CDV driver work.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/intel_bios.c | 18
drive
From: Alan Cox <a...@linux.intel.com>
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 331 +++-
drivers/gpu/drm/gma500/psb_intel_drv.h |3
drivers/gpu/drm/gma500/psb_intel_reg.h | 25 ++
3 files changed, 294 insertions(+), 65 deletions(-)
diff
From: Alan Cox <a...@linux.intel.com>
Fixes the case where the modesetting driver is slower than /dev/fb.
Signed-off-by: Alan Cox
Cc: stable at kernel.org
---
drivers/gpu/drm/gma500/gtt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/gma500
From: Alan Cox <a...@linux.intel.com>
Pull in various i915 bits that we will need to begin tackling the LVDS detect
and ACPI events. We try and drift towards the i915 version of the code with
the long term goal that at least some of it can one day be unified.
Signed-off-by: Al
From: Alan Cox <a...@linux.intel.com>
Introduce a panel presence check for Cedartrail. Non netbook devices don't
necessarily have a panel attached.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 57 +++
1 files changed, 57 insertions
From: Alan Cox <a...@linux.intel.com>
Otherwise we keep a bogus pci reference to the GPU
Signed-off-by: Alan Cox
---
drivers/acpi/video.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 9577b6f..66e8f73
From: Alan Cox <a...@linux.intel.com>
Handle the GMA500/600/36x0 cases. Also stop it poking at random registers on
the i740 cards that may be out there still.
This should also allow the legacy gma500 stub driver to go away as the ACPI
video layer will now do the right thing rather than
From: Alan Cox <a...@linux.intel.com>
We are not yet ready for this and it makes a mess on some devices.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/g
From: Alan Cox <a...@linux.intel.com>
The problem in console mode is lack of linear memory. We can solve that by
dropping to 16bpp. The mode setting X server will allocate its own GEM
framebuffer in 32bpp and all will be well.
We could just do 16bpp anyway but that would be a regr
From: Alan Cox <a...@linux.intel.com>
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_crt.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index 1de27c7..1a82843
From: Alan Cox <a...@linux.intel.com>
In particular clean up the errata handling and correct the crtc masks. We do
this a bit differently using our device abstraction for neatness.
This doesn't address the ACPI opregion and hotplug plumbing, nor the IRQ related
changes that will need. It t
From: Alan Cox <a...@linux.intel.com>
This provides the needed callback hooks to add hotplug display support to
the GMA36x0 devices.
[The actual enabling device part will follow once I've figured out why it
breaks suspend/resume on some netbooks]
Signed-off-by: Alan Cox
---
drivers/g
From: Alan Cox <a...@linux.intel.com>
Some boards such as the Intel D2700MUD allow you to have over 4GB of RAM.
The GTT on the PVR based devices is 32bit however. Hugh Dickins points out
that we should therefore be setting the mapping gfp mask.
This is not the whole fix for the problem
On Tue, 24 Apr 2012 23:30:22 +0100
Matthew Garrett wrote:
> On Tue, Apr 24, 2012 at 11:31:17PM +0100, Alan Cox wrote:
> > On Tue, 24 Apr 2012 22:02:18 +0100
> > Matthew Garrett wrote:
> > > The PowerVR Intels I'd seen had the opregion address in the 0xfc
On Wed, 25 Apr 2012 12:31:52 +0100
Matthew Garrett wrote:
> On Wed, Apr 25, 2012 at 11:27:11AM +0100, Alan Cox wrote:
> > On Tue, 24 Apr 2012 23:30:22 +0100
> > Matthew Garrett wrote:
> > > Right now you seem to set opregion unconditionally on PVR, which seems
On Wed, 25 Apr 2012 13:40:18 +0100
Matthew Garrett wrote:
> On Wed, Apr 25, 2012 at 01:24:38PM +0100, Alan Cox wrote:
>
> > Because as I said before there are two drivers involved and you may only
> > have one compiled into your kernel. If you have
> >
From: Alan Cox <a...@linux.intel.com>
Signed-off-by: Alan Cox
---
drivers/acpi/video.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 9577b6f..66e8f73 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/v
From: Alan Cox <a...@linux.intel.com>
Stop it poking at random registers on the i740 cards that may be out there
still.
As per Matthew's feedback remove the conditional checks and never enable the
opregion handling unless an appropriate driver has been loaded.
Signed-off-by: Al
From: Alan Cox <a...@linux.intel.com>
We are not yet ready for this and it makes a mess on some devices.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/g
This version drops the backlight patch while I figure how it breaks some
systems. It adds the now fixed hotplug monitor code.
---
Alan Cox (12):
gma500: Set the mapping mask
gma500: Add the base elements of CDV hotplug support
gma500: Add ops for hotplug support.
cdv
From: Alan Cox <a...@linux.intel.com>
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
From: Alan Cox <a...@linux.intel.com>
We need to pull more stuff from the VBT in order to configure the clocking
correctly in all cases. Add the relevant bits from the other CDV driver work.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/intel_bios.c | 18
drive
From: Alan Cox <a...@linux.intel.com>
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 331 +++-
drivers/gpu/drm/gma500/psb_intel_drv.h |3
drivers/gpu/drm/gma500/psb_intel_reg.h | 25 ++
3 files changed, 294 insertions(+), 65 deletions(-)
diff
From: Alan Cox <a...@linux.intel.com>
We don't want them uncached, combining will do nicely and fixes the performance
problem with the generic modesetting X server.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/gtt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
From: Alan Cox <a...@linux.intel.com>
Pull in various i915 bits that we will need to begin tackling the LVDS detect
and ACPI events. We try and drift towards the i915 version of the code with
the long term goal that at least some of it can one day be unified.
Signed-off-by: Al
From: Alan Cox <a...@linux.intel.com>
Introduce a panel presence check for Cedartrail. Non netbook devices don't
necessarily have a panel attached.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 57 +++
1 files changed, 57 insertions
401 - 500 of 665 matches
Mail list logo
