Re: Indirect call in vesafb driver
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__ __volatile__( >74"call *(%%edi)" > > and in vesa_setpalette(): > > 113__asm__ __volatile__( > 114 "call *(%%esi)" > > Is there need to use CALL_NOSPEC ? Vesafb is from the time on the dinosaurs but yes any vesa bios code will not be speculatively hardened. I'd also doubt anyone is actually using vesafb in the first place but it should use nospec Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing
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 use fbdev (aka which driver isn't > > supported by drm that you want to enable this on). > > Hi, > > those would be at a minimum efifb, vesafb, xenfb > Those are obviously not sexy, but from a practical point of view > they are the minimum you need to support. I think it's more constructive to look at it the other way around. What drivers do we have that actually need to be used which don't have DRM equivalents - and how do we fix that instead ? Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 00/13] Kernel based bootsplash
> 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 uncompressed. Most displays need some time to stabilize clocks and PLLs so you have to get the mode set up really really early on embedded devices where in some cases you've got regulatory requirements to show something on the display really really quickly. Consumers perceive a second from on to displaying something as sluggish on a fixed function device. > probably is compiled for your exact hw, with pretty much everything > built in. Also, no fbcon, maybe even no vt subsystem at all. > Definitely not your general purpose distro. Probably no console or tty layer even present, no keyboard drivers, no mouse. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 00/13] Kernel based bootsplash
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 Linux. As long as > >> the bootsplash is shown, no fbcon drawing operations are executed, so > >> there is no expensive scrolling or such to hog the system. > > > > It's too big, and those folks tend to be super picky about space. > > I know, they really are. > > However, given just how big and clunky modern systems have become, I raise my > doubts about a few extra KB for fbcon code to be relevant. For embedded every KB counts. That is likely to remain the same for some time because at the end of the day small devices are constrained about the amount of SRAM you can put on die and the amount of power you can afford for DRAM. > > this by ignoring it an adding a hole new layer on top. That doesn't > > sound like any kind of good idea to me. > > Yes. It is a vast improvement over the status quo, and people are asking for > it. And the bootsplash layer can be moved elsewhere, just change the hooks > and keep the loading/rendering. > > Also, gfx driver loading isn't a dumpster fire, it mostly just works. It just > mustn't be done 100% carelessly. It's a total mess (the fbcon layer loading and locking that is). Doing all this extra kernel stuff is like sitting in a hole and instead of trying to climb out digging the hole bigger so you've got more room to sit in it. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/6] drm: Add Content Protection property
> 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-hdcp video streams 8) Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/6] drm: Add Content Protection property
> 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 have an open usable user space. Is the HDCP encryption feature useful on its own ? What do users get from it ? If this is just an enabler for a lump of binary stuff in ChromeOS then I don't think it belongs, if it is useful standalone then it seems it does belong ? Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Make fbcon a built-time depency for fbdev
On Wed, 28 Jun 2017 12:36:35 +0200 Daniel Vetter wrote: > There's a bunch of folks who're trying to make printk less > contended and faster, but there's a problem: printk uses the > console_lock, and the console lock has become the BKL for all things > fbdev/fbcon, which in turn pulled in half the drm subsystem under that > lock. That's awkward. Yes - very. Although if you implement your console printing method with sufficient cunning it shouldn't cause much latency in most cases but for unaccelerated fb it's really bad. It also makes it unnecessarily hard for a drm driver to accelerate console output. > 4. Push console_lock down the call-chain, until it is down in > console_register again. I don't think that's actually going to work out. To fix it is going to need more invasive changes so that you can 'create' 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 Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations
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 operations. > (mostly because I don't really understand the alpha architecture.) But this does not do the same thing as an ioread64 with regards to atomicity or side effects on the device. The same is true of the other hacks. You either have a real 64bit single read/write from MMIO space or you don't. You can't fake it. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available
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 accept you don't have one. > > Yes, I understand that. > > The thing is that every user that's currently using it right now is > patching in their own version that splits it on non-64bit systems. > > > It's not safe to split it. Possibly for some use cases you could add an > > ioread64_maysplit() > > I'm open to doing something like that. I think that makes sense for the platforms with that problem. I'm not sure there are many that can't do it for mmio at least. 486SX can't do it and I guess some ARM32 but I think almost everyone else can including most 32bit x86. What's more of a problem is a lot of platforms can do 64bit MMIO via ioread/write64 but not 64bit port I/O, and it's not clear how you represent that via an ioread/write API that abstracts it away. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available
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 such as those at the top of > > drivers/ntb/hw/intel/ntb_hw_intel.c > > This patch adds fallback implementations for when CONFIG_64BIT and > CONFIG_GENERIC_IOMAP are not set. These functions use two io32 based > calls to complete the operation. > > Note, we do not use the volatile keyword in these functions like the > others in the same file. It is necessary to avoid a compiler warning > on arm. This is a really really bad idea as per the Alpha comment. ioread64 and iowrite64 generate a single 64bit bus transaction. There is hardware where mmio operations have side effects so simply using a pair of 32bit operations blindly does not work (consider something as trivial as reading a 64bit performance counter or incrementing pointer). 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 accept you don't have one. It's not safe to split it. Possibly for some use cases you could add an ioread64_maysplit() but you cannot blindly break ioread64/write64() and expect it to magically allow you to use drivers that depend upon it. What btw is the actual ARM compiler warning ? Is the compiler also trying to tell you it's a bad idea ? Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] drm/gma500: add virtual mapping support for fbdev.
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 with fbcon for high resolution envirnment. The text mode console code can't support a non-linear mapping and trying to grab one used most or all of the vmalloc address space on a 32bit box (and most of those systems are only able to run 32bit). For the sake of a bootscreen loader (which could use DRM directly instead if it needed high resolution) it didn't seem worht it. Either way it's not IMHO a good idea for 32bit, 64bit maybe. Alan
[PATCH] gma500:Remove functions that are now deprecated and move to the newer functions in drm_dp_helper.c
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 alongside > the removal of setting other values in the function,cdv_intel_dp_i2c_init > to use the helper function, drm_dp_aux_register that can handle all this > work internally. Which devices have you tested this on ? Alan
[patch] drm/gma500: double free in psbfb_create()
On Thu, 2015-03-19 at 13:17 +0300, Dan Carpenter wrote:
> The psb_gtt_free_range() frees "backing" so calling it twice is a double
> free bug. I have fixed this by removing the first call.
>
> Fixes: 4d8d096e9ae8 ('gma500: introduce the framebuffer support code')
> Signed-off-by: Dan Carpenter
#facepalm
Acked-by: Alan Cox
[PATCH] gpu:drm:Change calls to mdelay to msleep in the functions,send_pkg_prepare and send_pkg_done for the file,mdfld_dsi_pkg_sender.c
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 > > > 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 duration instead of using the respectful delay function due > > > to the need to sleep rather then busy loop the CPU(s) and waste CPU cycles > > > on the system that could be used to handle other tasks. > > > > > > Signed-off-by: Nicholas Krause > > > > NAK > > > > Like every other TODO you've been mucking with at random this one is > > there for a reason. > > > > We can't sleep at this point. > > From a quick look it seems like the only reason why we can't sleep is > because sender->lock is a spinlock. But it would seem that it could > simply be a mutex, in which case the delays could become sleeps. > > Do you happen to remember if there were specific reasons to make this a > spinlock rather than a mutex? I don't remember the full details and since I don't currently have a test platform for it, and its obsolete I don't want to touch it. If someone else does fine, but they need to verify it on real hardware. Alan
[PATCH] gpu:drm:Change calls to mdelay to msleep in the functions,send_pkg_prepare and send_pkg_done for the file,mdfld_dsi_pkg_sender.c
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 duration instead of using the respectful delay function due > to the need to sleep rather then busy loop the CPU(s) and waste CPU cycles > on the system that could be used to handle other tasks. > > Signed-off-by: Nicholas Krause NAK Like every other TODO you've been mucking with at random this one is there for a reason. We can't sleep at this point.
[PATCH] drm/dp-helper: Move the legacy helpers to gma500
On Wed, 22 Oct 2014 16:32:52 +0200 Patrik Jakobsson wrote: > On Wed, Oct 22, 2014 at 11:16 AM, Daniel Vetter > wrote: > > Except for gma500 all drivers are converted to the new style helpers, > > which have much better abstraction of the underlying hw protocols and > > 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'll CC Alan as well. Reviewed-by: Alan Cox Please consider adding an __deprecated marker to one of the top functions so it irritates me or someone else into cleaning it up properly
[patch] gma500: remove duplicate FB_REG09 define
> 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 productive. A wise man indeed. I'll try and keep an eye on it for minor fixes but hopefully its "done". Apart from one person trying to port Linux to the Lenovo Tablet 2 I don't think there is anything that is likely to happen here new ? Alan
[PATCH 12/35] drm/gma500: use drm_modeset_lock_all
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 places to keep the locking > semantics as much as possible. Seems fine. The last close behaviour really ought to be in the core DRM code. Telling people to discover magic incantations with sysrq is a total fail, especially on tablets and other devices that don't *have* a sysrq key. Alan
Re: [PATCH 12/35] drm/gma500: use drm_modeset_lock_all
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 places to keep the locking > semantics as much as possible. Seems fine. The last close behaviour really ought to be in the core DRM code. Telling people to discover magic incantations with sysrq is a total fail, especially on tablets and other devices that don't *have* a sysrq key. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] drm/exynos: added hdcp driver for contents protection.
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. > Contains an integrated HDCP encryption engine for video/audio content > protection. > supports version HDCP v1.1. > Exynos AP supports embedded HDCP key system. > The HDCP key value is fused during fabrication, based on customer's request. For this code to go into the kernel it must do so in GPL form. Can you confirm Samsung has the necessary IPR and permissions to grant use of this to all third parties as the GPL requires not just to specific customers ? (whether they can use it usefully is a different question as obviously they need the key. I ask this because there are currently a lot of lawyers busy trying to sue makers of some HDCP aware devices. > + > + dev_info(dev, "drm hdcp registered successfully.\n"); This sort of stuff ought to be dev_dbg, minor item > diff --git a/drivers/gpu/drm/exynos/exynos_hdcp.h > b/drivers/gpu/drm/exynos/exynos_hdcp.h > new file mode 100644 > index 000..86d0c79 > --- /dev/null > +++ b/drivers/gpu/drm/exynos/exynos_hdcp.h > @@ -0,0 +1,47 @@ > +/* > + * Copyright (c) 2012 Samsung Electronics Co., Ltd. > + * > + * Authors: > + * Eunchul Kim > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice (including the next > + * paragraph) shall be included in all copies or substantial portions of the > + * Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ Two things strike me here - firstly kernel code is GPLv2 or later (or dual licensed) as per the Signed-off-by: certification. I don't see any problem in the above but to be sure you realise. Secondly - VA Linux systems ??? has this been copied from some random file and not updated correctly or does the old VA Linux Systems really own bits of this code. Other questions I'll look at later - in particular - I don't see how the work queue is locked against the main thread of execution within the driver - There is a general DRI question here about HDCP and interfaces - several out of tree drivers do HDCP and perhaps a common API would be sensible ? Alan
Re: [RFC] drm/exynos: added hdcp driver for contents protection.
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. > Contains an integrated HDCP encryption engine for video/audio content > protection. > supports version HDCP v1.1. > Exynos AP supports embedded HDCP key system. > The HDCP key value is fused during fabrication, based on customer's request. For this code to go into the kernel it must do so in GPL form. Can you confirm Samsung has the necessary IPR and permissions to grant use of this to all third parties as the GPL requires not just to specific customers ? (whether they can use it usefully is a different question as obviously they need the key. I ask this because there are currently a lot of lawyers busy trying to sue makers of some HDCP aware devices. > + > + dev_info(dev, "drm hdcp registered successfully.\n"); This sort of stuff ought to be dev_dbg, minor item > diff --git a/drivers/gpu/drm/exynos/exynos_hdcp.h > b/drivers/gpu/drm/exynos/exynos_hdcp.h > new file mode 100644 > index 000..86d0c79 > --- /dev/null > +++ b/drivers/gpu/drm/exynos/exynos_hdcp.h > @@ -0,0 +1,47 @@ > +/* > + * Copyright (c) 2012 Samsung Electronics Co., Ltd. > + * > + * Authors: > + * Eunchul Kim > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice (including the next > + * paragraph) shall be included in all copies or substantial portions of the > + * Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ Two things strike me here - firstly kernel code is GPLv2 or later (or dual licensed) as per the Signed-off-by: certification. I don't see any problem in the above but to be sure you realise. Secondly - VA Linux systems ??? has this been copied from some random file and not updated correctly or does the old VA Linux Systems really own bits of this code. Other questions I'll look at later - in particular - I don't see how the work queue is locked against the main thread of execution within the driver - There is a general DRI question here about HDCP and interfaces - several out of tree drivers do HDCP and perhaps a common API would be sensible ? Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 0/5] Common Display Framework
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 notifier with the CDF, which then calls the > >> notifier > >> when a matching display entity is registered. The framebuffer layer has some similar 'anyone can' type notifier behaviour and its not a good thing. That kind of "any one can" behaviour leads to some really horrible messes unless the connections and the locking are well defined IMHO. Alan
Re: [RFC v2 0/5] Common Display Framework
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 notifier with the CDF, which then calls the > >> notifier > >> when a matching display entity is registered. The framebuffer layer has some similar 'anyone can' type notifier behaviour and its not a good thing. That kind of "any one can" behaviour leads to some really horrible messes unless the connections and the locking are well defined IMHO. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] gma600: Enable HDMI support
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 Dave's
request]
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/oaktrail.h|6
drivers/gpu/drm/gma500/oaktrail_crtc.c |8 +
drivers/gpu/drm/gma500/oaktrail_device.c |2
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 365 +-
4 files changed, 365 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail.h
b/drivers/gpu/drm/gma500/oaktrail.h
index f2f9f38..30adbbe 100644
--- a/drivers/gpu/drm/gma500/oaktrail.h
+++ b/drivers/gpu/drm/gma500/oaktrail.h
@@ -249,3 +249,9 @@ extern void oaktrail_hdmi_i2c_exit(struct pci_dev *dev);
extern void oaktrail_hdmi_save(struct drm_device *dev);
extern void oaktrail_hdmi_restore(struct drm_device *dev);
extern void oaktrail_hdmi_init(struct drm_device *dev, struct
psb_intel_mode_device *mode_dev);
+extern int oaktrail_crtc_hdmi_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
+ struct drm_display_mode
*adjusted_mode, int x, int y,
+ struct drm_framebuffer *old_fb);
+extern void oaktrail_crtc_hdmi_dpms(struct drm_crtc *crtc, int mode);
+
+
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index cdafd2a..4ec2962 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -168,6 +168,11 @@ static void oaktrail_crtc_dpms(struct drm_crtc *crtc, int
mode)
const struct psb_offset *map = &dev_priv->regmap[pipe];
u32 temp;
+ if (pipe == 1) {
+ oaktrail_crtc_hdmi_dpms(crtc, mode);
+ return;
+ }
+
if (!gma_power_begin(dev, true))
return;
@@ -302,6 +307,9 @@ static int oaktrail_crtc_mode_set(struct drm_crtc *crtc,
uint64_t scalingType = DRM_MODE_SCALE_FULLSCREEN;
struct drm_connector *connector;
+ if (pipe == 1)
+ return oaktrail_crtc_hdmi_mode_set(crtc, mode, adjusted_mode,
x, y, old_fb);
+
if (!gma_power_begin(dev, true))
return 0;
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 010b8207..08747fd 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -544,7 +544,7 @@ const struct psb_ops oaktrail_chip_ops = {
.accel_2d = 1,
.pipes = 2,
.crtcs = 2,
- .hdmi_mask = (1 << 0),
+ .hdmi_mask = (1 << 1),
.lvds_mask = (1 << 0),
.cursor_needs_phys = 0,
.sgx_offset = MRST_SGX_OFFSET,
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 69e51e9..f036f1f 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -155,6 +155,345 @@ static void oaktrail_hdmi_audio_disable(struct drm_device
*dev)
HDMI_READ(HDMI_HCR);
}
+static void wait_for_vblank(struct drm_device *dev)
+{
+ /* Wait for 20ms, i.e. one cycle at 50hz. */
+ mdelay(20);
+}
+
+static unsigned int htotal_calculate(struct drm_display_mode *mode)
+{
+ u32 htotal, new_crtc_htotal;
+
+ htotal = (mode->crtc_hdisplay - 1) | ((mode->crtc_htotal - 1) << 16);
+
+ /*
+* 1024 x 768 new_crtc_htotal = 0x1024;
+* 1280 x 1024 new_crtc_htotal = 0x0c34;
+*/
+ new_crtc_htotal = (mode->crtc_htotal - 1) * 200 * 1000 / mode->clock;
+
+ DRM_DEBUG_KMS("new crtc htotal 0x%4x\n", new_crtc_htotal);
+ return (mode->crtc_hdisplay - 1) | (new_crtc_htotal << 16);
+}
+
+static void oaktrail_hdmi_find_dpll(struct drm_crtc *crtc, int target,
+ int refclk, struct oaktrail_hdmi_clock
*best_clock)
+{
+ int np_min, np_max, nr_min, nr_max;
+ int np, nr, nf;
+
+ np_min = DIV_ROUND_UP(oaktrail_hdmi_limit.vco.min, target * 10);
+ np_max = oaktrail_hdmi_limit.vco.max / (target * 10);
+ if (np_min < oaktrail_hdmi_limit.np.min)
+ np_min = oaktrail_hdmi_limit.np.min;
+ if (np_max > oaktrail_hdmi_limit.np.max)
+ np_max = oaktrail_hdmi_limit.np.max;
+
+ nr_min = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_max));
+ nr_max = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_min));
+ if (nr_min < oaktrail_hdmi_limit.nr.min)
+ nr_min = oaktrail_hdmi_limit.nr.min;
+ if (nr_max > oaktrail_hdmi_limit.nr.max)
+ nr_max = oaktrail_hdmi_limit.nr.max;
+
+ np = DIV_ROUND_UP((refclk * 1000), (target * 10 * nr_max));
+ nr = DI
[PATCH RESEND] gma600: Enable HDMI support
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 Dave's
request]
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/oaktrail.h|6
drivers/gpu/drm/gma500/oaktrail_crtc.c |8 +
drivers/gpu/drm/gma500/oaktrail_device.c |2
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 365 +-
4 files changed, 365 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail.h
b/drivers/gpu/drm/gma500/oaktrail.h
index f2f9f38..30adbbe 100644
--- a/drivers/gpu/drm/gma500/oaktrail.h
+++ b/drivers/gpu/drm/gma500/oaktrail.h
@@ -249,3 +249,9 @@ extern void oaktrail_hdmi_i2c_exit(struct pci_dev *dev);
extern void oaktrail_hdmi_save(struct drm_device *dev);
extern void oaktrail_hdmi_restore(struct drm_device *dev);
extern void oaktrail_hdmi_init(struct drm_device *dev, struct
psb_intel_mode_device *mode_dev);
+extern int oaktrail_crtc_hdmi_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
+ struct drm_display_mode
*adjusted_mode, int x, int y,
+ struct drm_framebuffer *old_fb);
+extern void oaktrail_crtc_hdmi_dpms(struct drm_crtc *crtc, int mode);
+
+
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index cdafd2a..4ec2962 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -168,6 +168,11 @@ static void oaktrail_crtc_dpms(struct drm_crtc *crtc, int
mode)
const struct psb_offset *map = &dev_priv->regmap[pipe];
u32 temp;
+ if (pipe == 1) {
+ oaktrail_crtc_hdmi_dpms(crtc, mode);
+ return;
+ }
+
if (!gma_power_begin(dev, true))
return;
@@ -302,6 +307,9 @@ static int oaktrail_crtc_mode_set(struct drm_crtc *crtc,
uint64_t scalingType = DRM_MODE_SCALE_FULLSCREEN;
struct drm_connector *connector;
+ if (pipe == 1)
+ return oaktrail_crtc_hdmi_mode_set(crtc, mode, adjusted_mode,
x, y, old_fb);
+
if (!gma_power_begin(dev, true))
return 0;
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 010b8207..08747fd 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -544,7 +544,7 @@ const struct psb_ops oaktrail_chip_ops = {
.accel_2d = 1,
.pipes = 2,
.crtcs = 2,
- .hdmi_mask = (1 << 0),
+ .hdmi_mask = (1 << 1),
.lvds_mask = (1 << 0),
.cursor_needs_phys = 0,
.sgx_offset = MRST_SGX_OFFSET,
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 69e51e9..f036f1f 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -155,6 +155,345 @@ static void oaktrail_hdmi_audio_disable(struct drm_device
*dev)
HDMI_READ(HDMI_HCR);
}
+static void wait_for_vblank(struct drm_device *dev)
+{
+ /* Wait for 20ms, i.e. one cycle at 50hz. */
+ mdelay(20);
+}
+
+static unsigned int htotal_calculate(struct drm_display_mode *mode)
+{
+ u32 htotal, new_crtc_htotal;
+
+ htotal = (mode->crtc_hdisplay - 1) | ((mode->crtc_htotal - 1) << 16);
+
+ /*
+* 1024 x 768 new_crtc_htotal = 0x1024;
+* 1280 x 1024 new_crtc_htotal = 0x0c34;
+*/
+ new_crtc_htotal = (mode->crtc_htotal - 1) * 200 * 1000 / mode->clock;
+
+ DRM_DEBUG_KMS("new crtc htotal 0x%4x\n", new_crtc_htotal);
+ return (mode->crtc_hdisplay - 1) | (new_crtc_htotal << 16);
+}
+
+static void oaktrail_hdmi_find_dpll(struct drm_crtc *crtc, int target,
+ int refclk, struct oaktrail_hdmi_clock
*best_clock)
+{
+ int np_min, np_max, nr_min, nr_max;
+ int np, nr, nf;
+
+ np_min = DIV_ROUND_UP(oaktrail_hdmi_limit.vco.min, target * 10);
+ np_max = oaktrail_hdmi_limit.vco.max / (target * 10);
+ if (np_min < oaktrail_hdmi_limit.np.min)
+ np_min = oaktrail_hdmi_limit.np.min;
+ if (np_max > oaktrail_hdmi_limit.np.max)
+ np_max = oaktrail_hdmi_limit.np.max;
+
+ nr_min = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_max));
+ nr_max = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_min));
+ if (nr_min < oaktrail_hdmi_limit.nr.min)
+ nr_min = oaktrail_hdmi_limit.nr.min;
+ if (nr_max > oaktrail_hdmi_limit.nr.max)
+ nr_max = oaktrail_hdmi_limit.nr.max;
+
+ np = DIV_ROUND_UP((refclk * 1000), (target * 10 * nr_ma
radeon: RFC speed cap detection on ppc64
> 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 better as a helper in the PCI and arch PCI code ? Alan
Re: radeon: RFC speed cap detection on ppc64
> 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 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
[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
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 > >> > then please take the matter up with the corporate attorneys of the rights > >> > holders concerned. > >> > >> Alan please stick with the facts. This isn't a relicense of anything. > > > > In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer > > - NO. Does my laywer disagree with you - YES. > > Okay then we should remove this code from the kernel forthwith, as I > showed it was illegally relicensed previously in your lawyers opinion. That would not be the same question I asked my lawyer. Anyway I refer you to the Developer's Certificate of Origin 1.1. Anything Signed off was submitted under the GPL and so is usable as part of a GPL derived work, but not as part of a non GPL derived work. Thus Nouveau can happily use it for example. Simples. And as I said before if Nvidia believe the _GPL makes no difference and their work is not derivative then it's clearly within their power to just ignore it, at which point *they* take the risk on their own.
[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
> > 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. This isn't a relicense of anything. In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer - NO. Does my laywer disagree with you - YES. > EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a > totally pointless thing, In your personal viewpoint. I disagree. I'm a rights holder too. Several rights holders have made it clear the change is not wanted. It's over, done, buried. If you want it can go as far as Linus and then he can get a copy of all the discussion and say that same as he did in the classic video. Should I start submitting all the Intel non-free user space X drivers at this point as there seems to be a dramatic policy change going on here ? Alan
[PATCH] dma-buf: Use EXPORT_SYMBOL
> 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 dependant code that forms the work. The rules and licence are quite clear, as I think are the views of several of the rights holders on both the interpretation and intent of the licensing of their 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
Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
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 > >> > then please take the matter up with the corporate attorneys of the rights > >> > holders concerned. > >> > >> Alan please stick with the facts. This isn't a relicense of anything. > > > > In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer > > - NO. Does my laywer disagree with you - YES. > > Okay then we should remove this code from the kernel forthwith, as I > showed it was illegally relicensed previously in your lawyers opinion. That would not be the same question I asked my lawyer. Anyway I refer you to the Developer's Certificate of Origin 1.1. Anything Signed off was submitted under the GPL and so is usable as part of a GPL derived work, but not as part of a non GPL derived work. Thus Nouveau can happily use it for example. Simples. And as I said before if Nvidia believe the _GPL makes no difference and their work is not derivative then it's clearly within their power to just ignore it, at which point *they* take the risk on their own. >From the fact this patch keeps getting resubmitted despite repeated objection I deduce they are in fact of the view it does matter and that therefore it is a licensing change and they are scared of the consequences of ignoring it. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
> > 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. This isn't a relicense of anything. In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer - NO. Does my laywer disagree with you - YES. > EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a > totally pointless thing, In your personal viewpoint. I disagree. I'm a rights holder too. Several rights holders have made it clear the change is not wanted. It's over, done, buried. If you want it can go as far as Linus and then he can get a copy of all the discussion and say that same as he did in the classic video. Should I start submitting all the Intel non-free user space X drivers at this point as there seems to be a dramatic policy change going on here ? Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
> 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 dependant code that forms the work. The rules and licence are quite clear, as I think are the views of several of the rights holders on both the interpretation and intent of the licensing of their 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
> > 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/k added as I imagine a few other peopel will want to see this who don't read driver specific lists, Greg especially I guess] 'estoppel' and because my legal advice is specifically to do so. If you don't understand why it matters then please get qualified legal advice. I'm also objecting to the failure to follow proper process. If this does make a difference as Nvidia seem to think then it is a clear requirement that you gain permission from every rightsholder affected, as with any other licensing change. So I would suggest Nvidia start by going through the call tree and all potential rightsholders and negotiating with all their corporate attorneys to get each of them to provide a Signed-off-by: line for that change and perhaps charge them for a license in the process. Now as it happens lots of other people have objected to this last time it was posted, and this time, so maybe they should just recognize the clear will of the rightsholders concerned and give up on it. It's very clear how most rights holders involved see the Nvidia situation. What was it Linus said.. http://www.youtube.com/watch?v=IVpOyKCNZYw so right from the top the opinion seems to be fairly clear. > Also really its just bullshit handwaving all of it, your objection, > _GPL etc. until someone grows a pair and sues someone, instead of > hiding behind their employment status. If you really believed you were > right, you could retire on the settlement payout. Unlikely as most of the code I've written belongs to Intel or Red Hat. I also have better things to do with life than sue Nvidia and start an all out copyright and patent war in Linuxspace. It's simple enough If Nvidia think their code is not derivative then why do they care about the _GPL being significant ? Nouveau can call the DMA buf methods. Alan
Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
> > 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/k added as I imagine a few other peopel will want to see this who don't read driver specific lists, Greg especially I guess] 'estoppel' and because my legal advice is specifically to do so. If you don't understand why it matters then please get qualified legal advice. I'm also objecting to the failure to follow proper process. If this does make a difference as Nvidia seem to think then it is a clear requirement that you gain permission from every rightsholder affected, as with any other licensing change. So I would suggest Nvidia start by going through the call tree and all potential rightsholders and negotiating with all their corporate attorneys to get each of them to provide a Signed-off-by: line for that change and perhaps charge them for a license in the process. Now as it happens lots of other people have objected to this last time it was posted, and this time, so maybe they should just recognize the clear will of the rightsholders concerned and give up on it. It's very clear how most rights holders involved see the Nvidia situation. What was it Linus said.. http://www.youtube.com/watch?v=IVpOyKCNZYw so right from the top the opinion seems to be fairly clear. > Also really its just bullshit handwaving all of it, your objection, > _GPL etc. until someone grows a pair and sues someone, instead of > hiding behind their employment status. If you really believed you were > right, you could retire on the settlement payout. Unlikely as most of the code I've written belongs to Intel or Red Hat. I also have better things to do with life than sue Nvidia and start an all out copyright and patent war in Linuxspace. It's simple enough If Nvidia think their code is not derivative then 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
[PATCH] dma-buf: Use EXPORT_SYMBOL
> > 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 with proprietary > > Kernelspace code as a possible GPL infringement. > > Though that does beg the question why you care about this patch :-) Because my legal advice is to object and remind people who suggest otherwise. There are specific reasons to do so around estoppel and willful infringement. It's not a case of objections anyway - if the _GPL matters then it's a licensing change so you need the approval of everyone whose code is involved. At that point I think Nvidia are starting in the wrong place and need to start with a collection of vendors corporate legal contacts and then work down the call tree involved. Alan
[PATCH] dma-buf: Use EXPORT_SYMBOL
> 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 their own incompatible API, > thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting > the closed source vendors worry about the legality. They are already using > such > functions (at least nvidia is), so they clearly accept that risk. 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. Alan
[PATCH] dma-buf: 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
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
> > 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 with proprietary > > Kernelspace code as a possible GPL infringement. > > Though that does beg the question why you care about this patch :-) Because my legal advice is to object and remind people who suggest otherwise. There are specific reasons to do so around estoppel and willful infringement. It's not a case of objections anyway - if the _GPL matters then it's a licensing change so you need the approval of everyone whose code is involved. At that point I think Nvidia are starting in the wrong place and need to start with a collection of vendors 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
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
> 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 their own incompatible API, > thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting > the closed source vendors worry about the legality. They are already using > such > functions (at least nvidia is), so they clearly accept that risk. 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. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: 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 dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: 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 instead. NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. Also I'd note if you are trying to do this for the purpose of combining it with proprietary code then you are still in my view 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 is important to them. Alan
Re: [PATCH] dma-buf: 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 instead. NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. Also I'd note if you are trying to do this for the purpose of combining it with proprietary code then you are still in my view 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 is important to them. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gma500: medfield: fix potential NULL pointer dereference in mdfld_dsi_output_init()
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.
Re: [PATCH] gma500: medfield: fix potential NULL pointer dereference in mdfld_dsi_output_init()
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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gma600: Enable HDMI support
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 Dave's
request]
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/oaktrail.h|6
drivers/gpu/drm/gma500/oaktrail_crtc.c |8 +
drivers/gpu/drm/gma500/oaktrail_device.c |2
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 365 +-
4 files changed, 365 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail.h
b/drivers/gpu/drm/gma500/oaktrail.h
index f2f9f38..30adbbe 100644
--- a/drivers/gpu/drm/gma500/oaktrail.h
+++ b/drivers/gpu/drm/gma500/oaktrail.h
@@ -249,3 +249,9 @@ extern void oaktrail_hdmi_i2c_exit(struct pci_dev *dev);
extern void oaktrail_hdmi_save(struct drm_device *dev);
extern void oaktrail_hdmi_restore(struct drm_device *dev);
extern void oaktrail_hdmi_init(struct drm_device *dev, struct
psb_intel_mode_device *mode_dev);
+extern int oaktrail_crtc_hdmi_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
+ struct drm_display_mode
*adjusted_mode, int x, int y,
+ struct drm_framebuffer *old_fb);
+extern void oaktrail_crtc_hdmi_dpms(struct drm_crtc *crtc, int mode);
+
+
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index cdafd2a..4ec2962 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -168,6 +168,11 @@ static void oaktrail_crtc_dpms(struct drm_crtc *crtc, int
mode)
const struct psb_offset *map = &dev_priv->regmap[pipe];
u32 temp;
+ if (pipe == 1) {
+ oaktrail_crtc_hdmi_dpms(crtc, mode);
+ return;
+ }
+
if (!gma_power_begin(dev, true))
return;
@@ -302,6 +307,9 @@ static int oaktrail_crtc_mode_set(struct drm_crtc *crtc,
uint64_t scalingType = DRM_MODE_SCALE_FULLSCREEN;
struct drm_connector *connector;
+ if (pipe == 1)
+ return oaktrail_crtc_hdmi_mode_set(crtc, mode, adjusted_mode,
x, y, old_fb);
+
if (!gma_power_begin(dev, true))
return 0;
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 010b8207..08747fd 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -544,7 +544,7 @@ const struct psb_ops oaktrail_chip_ops = {
.accel_2d = 1,
.pipes = 2,
.crtcs = 2,
- .hdmi_mask = (1 << 0),
+ .hdmi_mask = (1 << 1),
.lvds_mask = (1 << 0),
.cursor_needs_phys = 0,
.sgx_offset = MRST_SGX_OFFSET,
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 69e51e9..f036f1f 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -155,6 +155,345 @@ static void oaktrail_hdmi_audio_disable(struct drm_device
*dev)
HDMI_READ(HDMI_HCR);
}
+static void wait_for_vblank(struct drm_device *dev)
+{
+ /* Wait for 20ms, i.e. one cycle at 50hz. */
+ mdelay(20);
+}
+
+static unsigned int htotal_calculate(struct drm_display_mode *mode)
+{
+ u32 htotal, new_crtc_htotal;
+
+ htotal = (mode->crtc_hdisplay - 1) | ((mode->crtc_htotal - 1) << 16);
+
+ /*
+* 1024 x 768 new_crtc_htotal = 0x1024;
+* 1280 x 1024 new_crtc_htotal = 0x0c34;
+*/
+ new_crtc_htotal = (mode->crtc_htotal - 1) * 200 * 1000 / mode->clock;
+
+ DRM_DEBUG_KMS("new crtc htotal 0x%4x\n", new_crtc_htotal);
+ return (mode->crtc_hdisplay - 1) | (new_crtc_htotal << 16);
+}
+
+static void oaktrail_hdmi_find_dpll(struct drm_crtc *crtc, int target,
+ int refclk, struct oaktrail_hdmi_clock
*best_clock)
+{
+ int np_min, np_max, nr_min, nr_max;
+ int np, nr, nf;
+
+ np_min = DIV_ROUND_UP(oaktrail_hdmi_limit.vco.min, target * 10);
+ np_max = oaktrail_hdmi_limit.vco.max / (target * 10);
+ if (np_min < oaktrail_hdmi_limit.np.min)
+ np_min = oaktrail_hdmi_limit.np.min;
+ if (np_max > oaktrail_hdmi_limit.np.max)
+ np_max = oaktrail_hdmi_limit.np.max;
+
+ nr_min = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_max));
+ nr_max = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_min));
+ if (nr_min < oaktrail_hdmi_limit.nr.min)
+ nr_min = oaktrail_hdmi_limit.nr.min;
+ if (nr_max > oaktrail_hdmi_limit.nr.max)
+ nr_max = oaktrail_hdmi_limit.nr.max;
+
+ np = DIV_ROUND_UP((refclk * 1000), (target * 10 * nr_max));
+ nr = DI
[PATCH] gma600: Enable HDMI support
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 Dave's
request]
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/oaktrail.h|6
drivers/gpu/drm/gma500/oaktrail_crtc.c |8 +
drivers/gpu/drm/gma500/oaktrail_device.c |2
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 365 +-
4 files changed, 365 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail.h
b/drivers/gpu/drm/gma500/oaktrail.h
index f2f9f38..30adbbe 100644
--- a/drivers/gpu/drm/gma500/oaktrail.h
+++ b/drivers/gpu/drm/gma500/oaktrail.h
@@ -249,3 +249,9 @@ extern void oaktrail_hdmi_i2c_exit(struct pci_dev *dev);
extern void oaktrail_hdmi_save(struct drm_device *dev);
extern void oaktrail_hdmi_restore(struct drm_device *dev);
extern void oaktrail_hdmi_init(struct drm_device *dev, struct
psb_intel_mode_device *mode_dev);
+extern int oaktrail_crtc_hdmi_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
+ struct drm_display_mode
*adjusted_mode, int x, int y,
+ struct drm_framebuffer *old_fb);
+extern void oaktrail_crtc_hdmi_dpms(struct drm_crtc *crtc, int mode);
+
+
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index cdafd2a..4ec2962 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -168,6 +168,11 @@ static void oaktrail_crtc_dpms(struct drm_crtc *crtc, int
mode)
const struct psb_offset *map = &dev_priv->regmap[pipe];
u32 temp;
+ if (pipe == 1) {
+ oaktrail_crtc_hdmi_dpms(crtc, mode);
+ return;
+ }
+
if (!gma_power_begin(dev, true))
return;
@@ -302,6 +307,9 @@ static int oaktrail_crtc_mode_set(struct drm_crtc *crtc,
uint64_t scalingType = DRM_MODE_SCALE_FULLSCREEN;
struct drm_connector *connector;
+ if (pipe == 1)
+ return oaktrail_crtc_hdmi_mode_set(crtc, mode, adjusted_mode,
x, y, old_fb);
+
if (!gma_power_begin(dev, true))
return 0;
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 010b8207..08747fd 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -544,7 +544,7 @@ const struct psb_ops oaktrail_chip_ops = {
.accel_2d = 1,
.pipes = 2,
.crtcs = 2,
- .hdmi_mask = (1 << 0),
+ .hdmi_mask = (1 << 1),
.lvds_mask = (1 << 0),
.cursor_needs_phys = 0,
.sgx_offset = MRST_SGX_OFFSET,
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 69e51e9..f036f1f 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -155,6 +155,345 @@ static void oaktrail_hdmi_audio_disable(struct drm_device
*dev)
HDMI_READ(HDMI_HCR);
}
+static void wait_for_vblank(struct drm_device *dev)
+{
+ /* Wait for 20ms, i.e. one cycle at 50hz. */
+ mdelay(20);
+}
+
+static unsigned int htotal_calculate(struct drm_display_mode *mode)
+{
+ u32 htotal, new_crtc_htotal;
+
+ htotal = (mode->crtc_hdisplay - 1) | ((mode->crtc_htotal - 1) << 16);
+
+ /*
+* 1024 x 768 new_crtc_htotal = 0x1024;
+* 1280 x 1024 new_crtc_htotal = 0x0c34;
+*/
+ new_crtc_htotal = (mode->crtc_htotal - 1) * 200 * 1000 / mode->clock;
+
+ DRM_DEBUG_KMS("new crtc htotal 0x%4x\n", new_crtc_htotal);
+ return (mode->crtc_hdisplay - 1) | (new_crtc_htotal << 16);
+}
+
+static void oaktrail_hdmi_find_dpll(struct drm_crtc *crtc, int target,
+ int refclk, struct oaktrail_hdmi_clock
*best_clock)
+{
+ int np_min, np_max, nr_min, nr_max;
+ int np, nr, nf;
+
+ np_min = DIV_ROUND_UP(oaktrail_hdmi_limit.vco.min, target * 10);
+ np_max = oaktrail_hdmi_limit.vco.max / (target * 10);
+ if (np_min < oaktrail_hdmi_limit.np.min)
+ np_min = oaktrail_hdmi_limit.np.min;
+ if (np_max > oaktrail_hdmi_limit.np.max)
+ np_max = oaktrail_hdmi_limit.np.max;
+
+ nr_min = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_max));
+ nr_max = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_min));
+ if (nr_min < oaktrail_hdmi_limit.nr.min)
+ nr_min = oaktrail_hdmi_limit.nr.min;
+ if (nr_max > oaktrail_hdmi_limit.nr.max)
+ nr_max = oaktrail_hdmi_limit.nr.max;
+
+ np = DIV_ROUND_UP((refclk * 1000), (target * 10 * nr_ma
[PATCH] drm: call connector->dpms(OFF) when disabling
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 non-obvious API change for all the other drivers. Have you tested this widely on other hardware ? Alan
Re: [PATCH] drm: call connector->dpms(OFF) when disabling
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 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
Problem: Internal LVDS screen alignment: the display shows a black "frame" at the bottom and is cut off at the top in 3.6-rc5+ with gma500 (REGRESSION)
> 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
Re: Problem: Internal LVDS screen alignment: the display shows a black "frame" at the bottom and is cut off at the top in 3.6-rc5+ with gma500 (REGRESSION)
> 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] SH Mobile DRM driver for v3.7
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 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 > > > request for another new driver. > > > > > > The following changes since commit > 09e7dcf081b1100d1cdff57fa9eb25c3a834c9d6: > > > gma500: Remove unused variable (2012-09-13 11:40:05 +1000) > > > > > > are available in the git repository at: > > > git://linuxtv.org/pinchartl/fbdev.git drm-lcdc > > > > Wrong summary ?? > > The repository is oddly named because I've initially created it to hold fbdev > patches. The drm-lcdc branch contains DRM patches. Yeah but the only change in it is a gma500 change not an SH one ! >
Re: [PULL] SH Mobile DRM driver for v3.7
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 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 > > > request for another new driver. > > > > > > The following changes since commit > 09e7dcf081b1100d1cdff57fa9eb25c3a834c9d6: > > > gma500: Remove unused variable (2012-09-13 11:40:05 +1000) > > > > > > are available in the git repository at: > > > git://linuxtv.org/pinchartl/fbdev.git drm-lcdc > > > > Wrong summary ?? > > The repository is oddly named because I've initially created it to hold fbdev > patches. The drm-lcdc branch contains DRM patches. Yeah but the only change in it is a gma500 change not an SH one ! > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] SH Mobile DRM driver for v3.7
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 request > for another new driver. > > The following changes since commit 09e7dcf081b1100d1cdff57fa9eb25c3a834c9d6: > > gma500: Remove unused variable (2012-09-13 11:40:05 +1000) > > are available in the git repository at: > git://linuxtv.org/pinchartl/fbdev.git drm-lcdc Wrong summary ??
Re: [PULL] SH Mobile DRM driver for v3.7
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 request > for another new driver. > > The following changes since commit 09e7dcf081b1100d1cdff57fa9eb25c3a834c9d6: > > gma500: Remove unused variable (2012-09-13 11:40:05 +1000) > > are available in the git repository at: > git://linuxtv.org/pinchartl/fbdev.git drm-lcdc Wrong summary ?? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gma600: Enable HDMI support
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. > > Assumning this is for -next, and its got whitespace damage, > (checkpatch and git complain :-) It is indeed for -next. Whitespace damage of what kind, messed up space/tabbing or 'doesn't apply eaten by mail system' ? If it's the former then I'll send you a couple of follow up patches to clean up the driver further fairly soon. Alan
Re: [PATCH] gma600: Enable HDMI support
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. > > Assumning this is for -next, and its got whitespace damage, > (checkpatch and git complain :-) It is indeed for -next. Whitespace damage of what kind, messed up space/tabbing or 'doesn't apply eaten by mail system' ? If it's the former 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
[PATCH] gma600: Enable HDMI support
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/oaktrail.h|6
drivers/gpu/drm/gma500/oaktrail_crtc.c |8 +
drivers/gpu/drm/gma500/oaktrail_device.c |2
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 366 +-
4 files changed, 366 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail.h
b/drivers/gpu/drm/gma500/oaktrail.h
index f2f9f38..30adbbe 100644
--- a/drivers/gpu/drm/gma500/oaktrail.h
+++ b/drivers/gpu/drm/gma500/oaktrail.h
@@ -249,3 +249,9 @@ extern void oaktrail_hdmi_i2c_exit(struct pci_dev *dev);
extern void oaktrail_hdmi_save(struct drm_device *dev);
extern void oaktrail_hdmi_restore(struct drm_device *dev);
extern void oaktrail_hdmi_init(struct drm_device *dev, struct
psb_intel_mode_device *mode_dev);
+extern int oaktrail_crtc_hdmi_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
+ struct drm_display_mode
*adjusted_mode, int x, int y,
+ struct drm_framebuffer *old_fb);
+extern void oaktrail_crtc_hdmi_dpms(struct drm_crtc *crtc, int mode);
+
+
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index cdafd2a..4ec2962 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -168,6 +168,11 @@ static void oaktrail_crtc_dpms(struct drm_crtc *crtc, int
mode)
const struct psb_offset *map = &dev_priv->regmap[pipe];
u32 temp;
+ if (pipe == 1) {
+ oaktrail_crtc_hdmi_dpms(crtc, mode);
+ return;
+ }
+
if (!gma_power_begin(dev, true))
return;
@@ -302,6 +307,9 @@ static int oaktrail_crtc_mode_set(struct drm_crtc *crtc,
uint64_t scalingType = DRM_MODE_SCALE_FULLSCREEN;
struct drm_connector *connector;
+ if (pipe == 1)
+ return oaktrail_crtc_hdmi_mode_set(crtc, mode, adjusted_mode,
x, y, old_fb);
+
if (!gma_power_begin(dev, true))
return 0;
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index cf49ba5..a177082 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -544,7 +544,7 @@ const struct psb_ops oaktrail_chip_ops = {
.accel_2d = 1,
.pipes = 2,
.crtcs = 2,
- .hdmi_mask = (1 << 0),
+ .hdmi_mask = (1 << 1),
.lvds_mask = (1 << 0),
.cursor_needs_phys = 0,
.sgx_offset = MRST_SGX_OFFSET,
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 2eb3dc4..b0c83fa 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -155,6 +155,346 @@ static void oaktrail_hdmi_audio_disable(struct drm_device
*dev)
HDMI_READ(HDMI_HCR);
}
+static void wait_for_vblank(struct drm_device *dev)
+{
+ /* Wait for 20ms, i.e. one cycle at 50hz. */
+ mdelay(20);
+}
+
+static unsigned int htotal_calculate(struct drm_display_mode *mode)
+{
+ u32 htotal, new_crtc_htotal;
+
+ htotal = (mode->crtc_hdisplay - 1) | ((mode->crtc_htotal - 1) << 16);
+
+ /*
+* 1024 x 768 new_crtc_htotal = 0x1024;
+* 1280 x 1024 new_crtc_htotal = 0x0c34;
+*/
+ new_crtc_htotal = (mode->crtc_htotal - 1) * 200 * 1000 / mode->clock;
+
+ DRM_DEBUG_KMS("new crtc htotal 0x%4x\n", new_crtc_htotal);
+ return ((mode->crtc_hdisplay - 1) | (new_crtc_htotal << 16));
+}
+
+static void oaktrail_hdmi_find_dpll(struct drm_crtc *crtc, int target,
+ int refclk, struct oaktrail_hdmi_clock
*best_clock)
+{
+ int np_min, np_max, nr_min, nr_max;
+ int np, nr, nf;
+
+ np_min = DIV_ROUND_UP(oaktrail_hdmi_limit.vco.min, target * 10);
+ np_max = oaktrail_hdmi_limit.vco.max / (target * 10);
+ if (np_min < oaktrail_hdmi_limit.np.min)
+ np_min = oaktrail_hdmi_limit.np.min;
+ if (np_max > oaktrail_hdmi_limit.np.max)
+ np_max = oaktrail_hdmi_limit.np.max;
+
+ nr_min = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_max));
+ nr_max = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_min));
+ if (nr_min < oaktrail_hdmi_limit.nr.min)
+ nr_min = oaktrail_hdmi_limit.nr.min;
+ if (nr_max > oaktrail_hdmi_limit.nr.max)
+ nr_max = oaktrail_hdmi_limit.nr.max;
+
+ np = DIV_ROUND_UP((refclk * 1000), (target * 10 * nr_max));
+ nr = DIV_ROUND_UP((refclk * 1000), (target * 10 * np));
+ nf = DIV_ROUND_CLOS
[PATCH] gma600: Enable HDMI support
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/oaktrail.h|6
drivers/gpu/drm/gma500/oaktrail_crtc.c |8 +
drivers/gpu/drm/gma500/oaktrail_device.c |2
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 366 +-
4 files changed, 366 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail.h
b/drivers/gpu/drm/gma500/oaktrail.h
index f2f9f38..30adbbe 100644
--- a/drivers/gpu/drm/gma500/oaktrail.h
+++ b/drivers/gpu/drm/gma500/oaktrail.h
@@ -249,3 +249,9 @@ extern void oaktrail_hdmi_i2c_exit(struct pci_dev *dev);
extern void oaktrail_hdmi_save(struct drm_device *dev);
extern void oaktrail_hdmi_restore(struct drm_device *dev);
extern void oaktrail_hdmi_init(struct drm_device *dev, struct
psb_intel_mode_device *mode_dev);
+extern int oaktrail_crtc_hdmi_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
+ struct drm_display_mode
*adjusted_mode, int x, int y,
+ struct drm_framebuffer *old_fb);
+extern void oaktrail_crtc_hdmi_dpms(struct drm_crtc *crtc, int mode);
+
+
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index cdafd2a..4ec2962 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -168,6 +168,11 @@ static void oaktrail_crtc_dpms(struct drm_crtc *crtc, int
mode)
const struct psb_offset *map = &dev_priv->regmap[pipe];
u32 temp;
+ if (pipe == 1) {
+ oaktrail_crtc_hdmi_dpms(crtc, mode);
+ return;
+ }
+
if (!gma_power_begin(dev, true))
return;
@@ -302,6 +307,9 @@ static int oaktrail_crtc_mode_set(struct drm_crtc *crtc,
uint64_t scalingType = DRM_MODE_SCALE_FULLSCREEN;
struct drm_connector *connector;
+ if (pipe == 1)
+ return oaktrail_crtc_hdmi_mode_set(crtc, mode, adjusted_mode,
x, y, old_fb);
+
if (!gma_power_begin(dev, true))
return 0;
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index cf49ba5..a177082 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -544,7 +544,7 @@ const struct psb_ops oaktrail_chip_ops = {
.accel_2d = 1,
.pipes = 2,
.crtcs = 2,
- .hdmi_mask = (1 << 0),
+ .hdmi_mask = (1 << 1),
.lvds_mask = (1 << 0),
.cursor_needs_phys = 0,
.sgx_offset = MRST_SGX_OFFSET,
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 2eb3dc4..b0c83fa 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -155,6 +155,346 @@ static void oaktrail_hdmi_audio_disable(struct drm_device
*dev)
HDMI_READ(HDMI_HCR);
}
+static void wait_for_vblank(struct drm_device *dev)
+{
+ /* Wait for 20ms, i.e. one cycle at 50hz. */
+ mdelay(20);
+}
+
+static unsigned int htotal_calculate(struct drm_display_mode *mode)
+{
+ u32 htotal, new_crtc_htotal;
+
+ htotal = (mode->crtc_hdisplay - 1) | ((mode->crtc_htotal - 1) << 16);
+
+ /*
+* 1024 x 768 new_crtc_htotal = 0x1024;
+* 1280 x 1024 new_crtc_htotal = 0x0c34;
+*/
+ new_crtc_htotal = (mode->crtc_htotal - 1) * 200 * 1000 / mode->clock;
+
+ DRM_DEBUG_KMS("new crtc htotal 0x%4x\n", new_crtc_htotal);
+ return ((mode->crtc_hdisplay - 1) | (new_crtc_htotal << 16));
+}
+
+static void oaktrail_hdmi_find_dpll(struct drm_crtc *crtc, int target,
+ int refclk, struct oaktrail_hdmi_clock
*best_clock)
+{
+ int np_min, np_max, nr_min, nr_max;
+ int np, nr, nf;
+
+ np_min = DIV_ROUND_UP(oaktrail_hdmi_limit.vco.min, target * 10);
+ np_max = oaktrail_hdmi_limit.vco.max / (target * 10);
+ if (np_min < oaktrail_hdmi_limit.np.min)
+ np_min = oaktrail_hdmi_limit.np.min;
+ if (np_max > oaktrail_hdmi_limit.np.max)
+ np_max = oaktrail_hdmi_limit.np.max;
+
+ nr_min = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_max));
+ nr_max = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_min));
+ if (nr_min < oaktrail_hdmi_limit.nr.min)
+ nr_min = oaktrail_hdmi_limit.nr.min;
+ if (nr_max > oaktrail_hdmi_limit.nr.max)
+ nr_max = oaktrail_hdmi_limit.nr.max;
+
+ np = DIV_ROUND_UP((refclk * 1000), (target * 10 * nr_max));
+ nr = DIV_ROUND_UP((refclk * 1000), (target * 10 * np));
+ nf = DIV_ROU
[PATCH] gma500: Fix regression on Oaktrail devices
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/drm/gma500/oaktrail_device.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 0f9b7db..cf49ba5 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -476,6 +476,7 @@ static const struct psb_offset oaktrail_regmap[2] = {
.pos = DSPAPOS,
.surf = DSPASURF,
.addr = MRST_DSPABASE,
+ .base = MRST_DSPABASE,
.status = PIPEASTAT,
.linoff = DSPALINOFF,
.tileoff = DSPATILEOFF,
@@ -499,6 +500,7 @@ static const struct psb_offset oaktrail_regmap[2] = {
.pos = DSPBPOS,
.surf = DSPBSURF,
.addr = DSPBBASE,
+ .base = DSPBBASE,
.status = PIPEBSTAT,
.linoff = DSPBLINOFF,
.tileoff = DSPBTILEOFF,
[PATCH] gma500: Fix regression on Oaktrail devices
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/drm/gma500/oaktrail_device.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 0f9b7db..cf49ba5 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -476,6 +476,7 @@ static const struct psb_offset oaktrail_regmap[2] = {
.pos = DSPAPOS,
.surf = DSPASURF,
.addr = MRST_DSPABASE,
+ .base = MRST_DSPABASE,
.status = PIPEASTAT,
.linoff = DSPALINOFF,
.tileoff = DSPATILEOFF,
@@ -499,6 +500,7 @@ static const struct psb_offset oaktrail_regmap[2] = {
.pos = DSPBPOS,
.surf = DSPBSURF,
.addr = DSPBBASE,
+ .base = DSPBBASE,
.status = PIPEBSTAT,
.linoff = DSPBLINOFF,
.tileoff = DSPBTILEOFF,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm: Add initial dnyamic power off feature
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 interfaces, and fires a 5s timer to test if > we can power the GPU off. Is there a reason for basically re-inventing the existing Linux dynamic power management layer ? Alan
[PATCH 2/5] drm: Add initial dnyamic power off feature
> 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 oaktrail driver codebase but it's not enabled and I may well delete it rather than fix it. Alan
Re: [PATCH 2/5] drm: Add initial dnyamic power off feature
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 interfaces, and fires a 5s timer to test if > we can power the GPU off. Is there a reason for basically re-inventing the existing Linux dynamic power management layer ? Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm: Add initial dnyamic power off feature
> 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 oaktrail driver codebase but it's not enabled and I may well delete it rather than fix it. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Patch 0/1]drm_irq: Introducing the irq_thread support
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 stay in irq disable status. One case is: > when audio is playing, it sometimes effects the audio quality. This possibly ought to be submitted in parallel with the code that uses it so that the whole proposal can be evaluated as one thing ? Alan
Re: [Patch 0/1]drm_irq: Introducing the irq_thread support
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 stay in irq disable status. One case is: > when audio is playing, it sometimes effects the audio quality. This possibly ought to be submitted in parallel with the code that uses it so that the whole proposal can be evaluated as one thing ? Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gma500: remove references to drm_display_info raw_edid field
On Fri, 24 Aug 2012 09:42:44 +0300 Jani Nikula wrote: > Another reference to raw_edid field of struct drm_display_info was > added in gma500 while the whole field was being removed, causing build > failure. Remove the hopefully last references to raw_edid. > > Reported-by: Fengguang Wu > Signed-off-by: Jani Nikula Signed-off-by: Alan Cox
Re: [PATCH] gma500: remove references to drm_display_info raw_edid field
On Fri, 24 Aug 2012 09:42:44 +0300 Jani Nikula wrote: > Another reference to raw_edid field of struct drm_display_info was > added in gma500 while the whole field was being removed, causing build > failure. Remove the hopefully last references to raw_edid. > > Reported-by: 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
[PATCH] drm: gma500: Kill the GEM glue layer
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, 16 May 2012 16:59:44 +0200 Laurent Pinchart wrote: > > > > > The private gem_create_mmap_offset() function is now > > > > > implemented in the DRM core as drm_gem_create_mmap_offset(). > > > > > Use it and kill the private copy. > > > > > > > > That was always then plan so yes - I'll fold this into my tree > > > > and test it. > > > > > > Any update ? > > > > Sorry it fell off the bottom of the job list. I'll do it right now > > so it doesn't escape > > I still can't find the patch in drm-next. Does it have a bad tendency > to fell off ? :-) I sent to Dave along with the mode setting fixes and DP/eDP support. None of them are yet in the tree but I've not re-sent again as Dave seemed to be busy to trying to mend the -rc tree. Alan
Re: [PATCH] drm: gma500: Kill the GEM glue layer
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, 16 May 2012 16:59:44 +0200 Laurent Pinchart wrote: > > > > > The private gem_create_mmap_offset() function is now > > > > > implemented in the DRM core as drm_gem_create_mmap_offset(). > > > > > Use it and kill the private copy. > > > > > > > > That was always then plan so yes - I'll fold this into my tree > > > > and test it. > > > > > > Any update ? > > > > Sorry it fell off the bottom of the job list. I'll do it right now > > so it doesn't escape > > I still can't find the patch in drm-next. Does it have a bad tendency > to fell off ? :-) I sent to Dave along with the mode setting fixes and DP/eDP support. None of them are yet in the tree but I've not re-sent again as Dave seemed to be busy to trying to mend the -rc tree. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] console_lock debug improvements
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 indeed, by adding proper annotations to the console_lock it complains > about > the potential deadlock when exercising the entire driver life-cycle of just > one > fb driver (i.e. not even a handover required). While at it, I've replaced the > existing in_interrupt check with the more paranoid might_sleep. > > Comments, flames and review highly welcome. This will be an absolute godsend for DRI debugging. Definitely wants to go in. Alan
[PATCH] cdv: Fix call to cdv_intel_dp_set_m_n
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 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 4df1e72..3cfd093 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -1125,8 +1125,8 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
}
/* dpll |= PLL_REF_INPUT_DREFCLK; */
- if (is_dp) {
-/*FIXMEcdv_intel_dp_set_m_n(crtc, mode, adjusted_mode); */
+ if (is_dp || is_edp) {
+ cdv_intel_dp_set_m_n(crtc, mode, adjusted_mode);
} else {
REG_WRITE(PIPE_GMCH_DATA_M(pipe), 0);
REG_WRITE(PIPE_GMCH_DATA_N(pipe), 0);
Re: [PATCH 0/2] console_lock debug improvements
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 indeed, by adding proper annotations to the console_lock it complains > about > the potential deadlock when exercising the entire driver life-cycle of just > one > fb driver (i.e. not even a handover required). While at it, I've replaced the > existing in_interrupt check with the more paranoid might_sleep. > > Comments, flames and review highly welcome. This will be an absolute godsend for DRI debugging. Definitely wants to go in. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] cdv: Fix call to cdv_intel_dp_set_m_n
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 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 4df1e72..3cfd093 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -1125,8 +1125,8 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
}
/* dpll |= PLL_REF_INPUT_DREFCLK; */
- if (is_dp) {
-/*FIXMEcdv_intel_dp_set_m_n(crtc, mode, adjusted_mode); */
+ if (is_dp || is_edp) {
+ cdv_intel_dp_set_m_n(crtc, mode, adjusted_mode);
} else {
REG_WRITE(PIPE_GMCH_DATA_M(pipe), 0);
REG_WRITE(PIPE_GMCH_DATA_N(pipe), 0);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbcon: fix race condition between console lock and cursor timer
> 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 the proper fix but its clear and is probably the best thing to go in initially with a cc: stable. Can you at least stick a large + /* FIXME: we should sort out the unbind locking instead */ on the patch however. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
> 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 the proper fix but its clear and is probably the best thing to go in initially with a cc: stable. Can you at least stick a large + /* FIXME: we should sort out the unbind locking instead */ on the patch however. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: stop vmgfx driver explosion
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 "intriguing" possibilities. What it should do is an open question but that for the driver owners to sort out. Signed-off-by: Alan Cox --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index 6b0078f..c50724b 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -1688,15 +1688,19 @@ int vmw_du_page_flip(struct drm_crtc *crtc, struct vmw_private *dev_priv = vmw_priv(crtc->dev); struct drm_framebuffer *old_fb = crtc->fb; struct vmw_framebuffer *vfb = vmw_framebuffer_to_vfb(fb); - struct drm_file *file_priv = event->base.file_priv; + struct drm_file *file_priv ; struct vmw_fence_obj *fence = NULL; struct drm_clip_rect clips; int ret; + if (event == NULL) + return -EINVAL; + /* require ScreenObject support for page flipping */ if (!dev_priv->sou_priv) return -ENOSYS; + file_priv = event->base.file_priv; if (!vmw_kms_screen_object_flippable(dev_priv, crtc)) return -EINVAL;
[PATCH] drm: stop vmgfx driver explosion
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 "intriguing" possibilities. What it should do is an open question but that for the driver owners to sort out. Signed-off-by: Alan Cox --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index 6b0078f..c50724b 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -1688,15 +1688,19 @@ int vmw_du_page_flip(struct drm_crtc *crtc, struct vmw_private *dev_priv = vmw_priv(crtc->dev); struct drm_framebuffer *old_fb = crtc->fb; struct vmw_framebuffer *vfb = vmw_framebuffer_to_vfb(fb); - struct drm_file *file_priv = event->base.file_priv; + struct drm_file *file_priv ; struct vmw_fence_obj *fence = NULL; struct drm_clip_rect clips; int ret; + if (event == NULL) + return -EINVAL; + /* require ScreenObject support for page flipping */ if (!dev_priv->sou_priv) return -ENOSYS; + file_priv = event->base.file_priv; if (!vmw_kms_screen_object_flippable(dev_priv, crtc)) return -EINVAL; ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] gma500: Consider CRTC initially active.
[this one ideally should make 3.6 - it fixes the very annoying mode setting bug] From: Forest Bond This causes the pipe to be forced off prior to initial mode set, which roughly mirrors the behavior of the i915 driver. It fixes initial mode setting on my 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 --- drivers/gpu/drm/gma500/psb_intel_display.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c b/drivers/gpu/drm/gma500/psb_intel_display.c index 30dc22a..8033526 100644 --- a/drivers/gpu/drm/gma500/psb_intel_display.c +++ b/drivers/gpu/drm/gma500/psb_intel_display.c @@ -1362,6 +1362,9 @@ void psb_intel_crtc_init(struct drm_device *dev, int pipe, (struct drm_connector **) (psb_intel_crtc + 1); psb_intel_crtc->mode_set.num_connectors = 0; psb_intel_cursor_init(dev, psb_intel_crtc); + + /* Set to true so that the pipe is forced off on initial config. */ + psb_intel_crtc->active = true; } int psb_intel_get_pipe_from_crtc_id(struct drm_device *dev, void *data,
[PATCH 2/3] gma500: psb_intel_crtc: Drop crtc_enable flag.
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 changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 247ad7b..4df1e72 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -930,7 +930,6 @@ static void cdv_intel_crtc_dpms(struct drm_crtc *crtc, int
mode)
/* Give the overlay scaler a chance to enable
* if it's on this pipe */
/* psb_intel_crtc_dpms_video(crtc, true); TODO */
- psb_intel_crtc->crtc_enable = true;
break;
case DRM_MODE_DPMS_OFF:
if (!psb_intel_crtc->active)
@@ -981,7 +980,6 @@ static void cdv_intel_crtc_dpms(struct drm_crtc *crtc, int
mode)
/* Wait for the clocks to turn off. */
udelay(150);
- psb_intel_crtc->crtc_enable = false;
break;
}
cdv_intel_update_watermark(dev, crtc);
diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h
b/drivers/gpu/drm/gma500/psb_intel_drv.h
index c53e592..c9710ff 100644
--- a/drivers/gpu/drm/gma500/psb_intel_drv.h
+++ b/drivers/gpu/drm/gma500/psb_intel_drv.h
@@ -193,7 +193,6 @@ struct psb_intel_crtc {
u32 mode_flags;
bool active;
- bool crtc_enable;
/* Saved Crtc HW states */
struct psb_intel_crtc_state *crtc_state;
[PATCH 1/3] gma500: Fix comment mispelling in cdv_intel_limits definition.
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..247ad7b 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -76,7 +76,7 @@ static bool cdv_intel_find_dp_pll(const struct
cdv_intel_limit_t *limit, struct
#define CDV_LIMIT_DP_100 5
static const struct cdv_intel_limit_t cdv_intel_limits[] = {
- { /* CDV_SIGNLE_LVDS_96MHz */
+ { /* CDV_SINGLE_LVDS_96MHz */
.dot = {.min = 2, .max = 115500},
.vco = {.min = 180, .max = 360},
.n = {.min = 2, .max = 6},
[PATCH 3/3] gma500: Consider CRTC initially active.
[this one ideally should make 3.6 - it fixes the very annoying mode setting bug] From: Forest Bond This causes the pipe to be forced off prior to initial mode set, which roughly mirrors the behavior of the i915 driver. It fixes initial mode setting on my 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 --- drivers/gpu/drm/gma500/psb_intel_display.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c b/drivers/gpu/drm/gma500/psb_intel_display.c index 30dc22a..8033526 100644 --- a/drivers/gpu/drm/gma500/psb_intel_display.c +++ b/drivers/gpu/drm/gma500/psb_intel_display.c @@ -1362,6 +1362,9 @@ void psb_intel_crtc_init(struct drm_device *dev, int pipe, (struct drm_connector **) (psb_intel_crtc + 1); psb_intel_crtc->mode_set.num_connectors = 0; psb_intel_cursor_init(dev, psb_intel_crtc); + + /* Set to true so that the pipe is forced off on initial config. */ + psb_intel_crtc->active = true; } int psb_intel_get_pipe_from_crtc_id(struct drm_device *dev, void *data, ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] gma500: psb_intel_crtc: Drop crtc_enable flag.
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 changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 247ad7b..4df1e72 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -930,7 +930,6 @@ static void cdv_intel_crtc_dpms(struct drm_crtc *crtc, int
mode)
/* Give the overlay scaler a chance to enable
* if it's on this pipe */
/* psb_intel_crtc_dpms_video(crtc, true); TODO */
- psb_intel_crtc->crtc_enable = true;
break;
case DRM_MODE_DPMS_OFF:
if (!psb_intel_crtc->active)
@@ -981,7 +980,6 @@ static void cdv_intel_crtc_dpms(struct drm_crtc *crtc, int
mode)
/* Wait for the clocks to turn off. */
udelay(150);
- psb_intel_crtc->crtc_enable = false;
break;
}
cdv_intel_update_watermark(dev, crtc);
diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h
b/drivers/gpu/drm/gma500/psb_intel_drv.h
index c53e592..c9710ff 100644
--- a/drivers/gpu/drm/gma500/psb_intel_drv.h
+++ b/drivers/gpu/drm/gma500/psb_intel_drv.h
@@ -193,7 +193,6 @@ struct psb_intel_crtc {
u32 mode_flags;
bool active;
- bool crtc_enable;
/* Saved Crtc HW states */
struct psb_intel_crtc_state *crtc_state;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] gma500: Fix comment mispelling in cdv_intel_limits definition.
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..247ad7b 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -76,7 +76,7 @@ static bool cdv_intel_find_dp_pll(const struct
cdv_intel_limit_t *limit, struct
#define CDV_LIMIT_DP_100 5
static const struct cdv_intel_limit_t cdv_intel_limits[] = {
- { /* CDV_SIGNLE_LVDS_96MHz */
+ { /* CDV_SINGLE_LVDS_96MHz */
.dot = {.min = 2, .max = 115500},
.vco = {.min = 180, .max = 360},
.n = {.min = 2, .max = 6},
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] gma: psb_intel_crtc: Drop crtc_enable flag.
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 well. Alan
Re: [PATCH 2/3] gma: psb_intel_crtc: Drop crtc_enable flag.
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 well. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] From: Zhao Yakui
From: Zhao Yakui
Disable the clock gating of display controller to make DP/eDP work well
I don't know why the DP/eDP is affected by the clock gating. But the test
shows that it really fixes the DP/eDP clock issue during enabling DP/eDP.
Signed-off-by: Zhao Yakui
[Updated 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 --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index 0571ef9b..9bacce3 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -1778,6 +1778,28 @@ static bool cdv_intel_dpc_is_edp(struct drm_device *dev)
return false;
}
+/* Cedarview display clock gating
+
+ We need this disable dot get correct behaviour while enabling
+ DP/eDP. TODO - investigate if we can turn it back to normality
+ after enabling */
+static void cdv_disable_intel_clock_gating(struct drm_device *dev)
+{
+ u32 reg_value;
+ reg_value = REG_READ(DSPCLK_GATE_D);
+
+ reg_value |= (DPUNIT_PIPEB_GATE_DISABLE |
+ DPUNIT_PIPEA_GATE_DISABLE |
+ DPCUNIT_CLOCK_GATE_DISABLE |
+ DPLSUNIT_CLOCK_GATE_DISABLE |
+ DPOUNIT_CLOCK_GATE_DISABLE |
+ DPIOUNIT_CLOCK_GATE_DISABLE);
+
+ REG_WRITE(DSPCLK_GATE_D, reg_value);
+
+ udelay(500);
+}
+
void
cdv_intel_dp_init(struct drm_device *dev, struct psb_intel_mode_device
*mode_dev, int output_reg)
{
@@ -1841,6 +1863,8 @@ cdv_intel_dp_init(struct drm_device *dev, struct
psb_intel_mode_device *mode_dev
break;
}
+ cdv_disable_intel_clock_gating(dev);
+
cdv_intel_dp_i2c_init(psb_intel_connector, psb_intel_encoder, name);
/* FIXME:fail check */
cdv_intel_dp_add_properties(connector);
diff --git a/drivers/gpu/drm/gma500/psb_intel_reg.h
b/drivers/gpu/drm/gma500/psb_intel_reg.h
index 389e969..d914719 100644
--- a/drivers/gpu/drm/gma500/psb_intel_reg.h
+++ b/drivers/gpu/drm/gma500/psb_intel_reg.h
@@ -1313,6 +1313,10 @@ No status bits are changed.
# define VRHUNIT_CLOCK_GATE_DISABLE(1 << 28) /* Fixed value on CDV
*/
# define DPOUNIT_CLOCK_GATE_DISABLE(1 << 11)
# define DPIOUNIT_CLOCK_GATE_DISABLE (1 << 6)
+# define DPUNIT_PIPEB_GATE_DISABLE (1 << 30)
+# define DPUNIT_PIPEA_GATE_DISABLE (1 << 25)
+# define DPCUNIT_CLOCK_GATE_DISABLE(1 << 24)
+# define DPLSUNIT_CLOCK_GATE_DISABLE (1 << 13)
#define RAMCLK_GATE_D 0x6210
[PATCH 7/8] cdv: Add eDP support
From: Zhao Yakui
Introduce the eDP support into the driver.
This has been reworked a bit because kernel driver proper uses
encoder/connectors
while the legacy Intel driver uses the old output stuff.
It also diverges on the backlight handling. The legacy Intel driver 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/gpu/drm/gma500/backlight.c | 45 +++
drivers/gpu/drm/gma500/cdv_device.c|1
drivers/gpu/drm/gma500/cdv_intel_display.c | 42 ++-
drivers/gpu/drm/gma500/cdv_intel_dp.c | 468 +++-
drivers/gpu/drm/gma500/cdv_intel_lvds.c| 12 -
drivers/gpu/drm/gma500/framebuffer.c |3
drivers/gpu/drm/gma500/intel_bios.c| 101 ++
drivers/gpu/drm/gma500/intel_bios.h| 46 +++
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 13 -
drivers/gpu/drm/gma500/mid_bios.c |8
drivers/gpu/drm/gma500/opregion.c |3
drivers/gpu/drm/gma500/psb_drv.h | 19 +
drivers/gpu/drm/gma500/psb_intel_lvds.c| 13 -
drivers/gpu/drm/gma500/psb_intel_reg.h | 38 ++
14 files changed, 751 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/gma500/backlight.c
b/drivers/gpu/drm/gma500/backlight.c
index 2079395..143eba3 100644
--- a/drivers/gpu/drm/gma500/backlight.c
+++ b/drivers/gpu/drm/gma500/backlight.c
@@ -26,10 +26,55 @@
#include "intel_bios.h"
#include "power.h"
+static void do_gma_backlight_set(struct drm_device *dev)
+{
+#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ backlight_update_status(dev_priv->backlight_device);
+#endif
+}
+
+void gma_backlight_enable(struct drm_device *dev)
+{
+#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ dev_priv->backlight_enabled = true;
+ if (dev_priv->backlight_device) {
+ dev_priv->backlight_device->props.brightness =
dev_priv->backlight_level;
+ do_gma_backlight_set(dev);
+ }
+#endif
+}
+
+void gma_backlight_disable(struct drm_device *dev)
+{
+#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ dev_priv->backlight_enabled = false;
+ if (dev_priv->backlight_device) {
+ dev_priv->backlight_device->props.brightness = 0;
+ do_gma_backlight_set(dev);
+ }
+#endif
+}
+
+void gma_backlight_set(struct drm_device *dev, int v)
+{
+#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ dev_priv->backlight_level = v;
+ if (dev_priv->backlight_device && dev_priv->backlight_enabled) {
+ dev_priv->backlight_device->props.brightness = v;
+ do_gma_backlight_set(dev);
+ }
+#endif
+}
+
int gma_backlight_init(struct drm_device *dev)
{
#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
struct drm_psb_private *dev_priv = dev->dev_private;
+ dev_priv->backlight_enabled = true;
return dev_priv->ops->backlight_init(dev);
#else
return 0;
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index 68f100e..4882e64 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -170,6 +170,7 @@ static int cdv_backlight_init(struct drm_device *dev)
cdv_get_brightness(cdv_backlight_device);
backlight_update_status(cdv_backlight_device);
dev_priv->backlight_device = cdv_backlight_device;
+ dev_priv->backlight_enabled = true;
return 0;
}
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 3f11060..bfb0565 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -438,7 +438,8 @@ static const struct cdv_intel_limit_t
*cdv_intel_limit(struct drm_crtc *crtc,
limit = &cdv_intel_limits[CDV_LIMIT_SINGLE_LVDS_96];
else
limit = &cdv_intel_limits[CDV_LIMIT_SINGLE_LVDS_100];
- } else if (psb_intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
+ } else if (psb_intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT) ||
+ psb_intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP)) {
if (refclk == 27000)
limit = &cdv_intel_limits[CDV_LIMIT_DP_27];
else
@@ -1045,6 +1046,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
struct drm_connector *connector;
const struct cdv_intel_limit
[PATCH 6/8] cdv: enable the DisplayPort support
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..68f100e 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -58,10 +58,17 @@ static int cdv_output_init(struct drm_device *dev)
cdv_intel_lvds_init(dev, &dev_priv->mode_dev);
/* These bits indicate HDMI not SDVO on CDV */
- if (REG_READ(SDVOB) & SDVO_DETECTED)
+ if (REG_READ(SDVOB) & SDVO_DETECTED) {
cdv_hdmi_init(dev, &dev_priv->mode_dev, SDVOB);
- if (REG_READ(SDVOC) & SDVO_DETECTED)
+ if (REG_READ(DP_B) & DP_DETECTED)
+ cdv_intel_dp_init(dev, &dev_priv->mode_dev, DP_B);
+ }
+
+ if (REG_READ(SDVOC) & SDVO_DETECTED) {
cdv_hdmi_init(dev, &dev_priv->mode_dev, SDVOC);
+ if (REG_READ(DP_C) & DP_DETECTED)
+ cdv_intel_dp_init(dev, &dev_priv->mode_dev, DP_C);
+ }
return 0;
}
[PATCH 5/8] cdv: sync up and add the displayport code to the build
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/gma500/psb_intel_drv.h | 16 +
4 files changed, 260 insertions(+), 245 deletions(-)
diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index 81ff7e2..7a2d40a 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -30,7 +30,8 @@ gma500_gfx-$(CONFIG_DRM_GMA3600) += cdv_device.o \
cdv_intel_crt.o \
cdv_intel_display.o \
cdv_intel_hdmi.o \
- cdv_intel_lvds.o
+ cdv_intel_lvds.o \
+ cdv_intel_dp.o
gma500_gfx-$(CONFIG_DRM_GMA600) += oaktrail_device.o \
oaktrail_crtc.o \
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 2e0231e..3f11060 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -171,7 +171,7 @@ static const struct cdv_intel_limit_t cdv_intel_limits[] = {
#define wait_for(COND, MS) _wait_for(COND, MS, 1)
-static int cdv_sb_read(struct drm_device *dev, u32 reg, u32 *val)
+int cdv_sb_read(struct drm_device *dev, u32 reg, u32 *val)
{
int ret;
@@ -198,7 +198,7 @@ static int cdv_sb_read(struct drm_device *dev, u32 reg, u32
*val)
return 0;
}
-static int cdv_sb_write(struct drm_device *dev, u32 reg, u32 val)
+int cdv_sb_write(struct drm_device *dev, u32 reg, u32 val)
{
int ret;
static bool dpio_debug = true;
@@ -240,7 +240,7 @@ static int cdv_sb_write(struct drm_device *dev, u32 reg,
u32 val)
/* Reset the DPIO configuration register. The BIOS does this at every
* mode set.
*/
-static void cdv_sb_reset(struct drm_device *dev)
+void cdv_sb_reset(struct drm_device *dev)
{
REG_WRITE(DPIO_CFG, 0);
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index c6d545d..b29b602 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -33,7 +33,6 @@
#include "drm_crtc_helper.h"
#include "psb_drv.h"
#include "psb_intel_drv.h"
-#include "psb_drm.h"
#include "psb_intel_reg.h"
#include "drm_dp_helper.h"
@@ -45,7 +44,7 @@
#define CDV_FAST_LINK_TRAIN1
-struct psb_intel_dp {
+struct cdv_intel_dp {
uint32_t output_reg;
uint32_t DP;
uint8_t link_configuration[DP_LINK_CONFIGURATION_SIZE];
@@ -55,7 +54,7 @@ struct psb_intel_dp {
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[4];
- struct psb_intel_output *output;
+ struct psb_intel_encoder *encoder;
struct i2c_adapter adapter;
struct i2c_algo_dp_aux_data algo;
uint8_t train_set[4];
@@ -94,20 +93,20 @@ static uint32_t dp_vswing_premph_table[] = {
* If a CPU or PCH DP output is attached to an eDP panel, this function
* will return true, and false otherwise.
*/
-static bool is_edp(struct psb_intel_output *output)
+static bool is_edp(struct psb_intel_encoder *encoder)
{
- return output->type == INTEL_OUTPUT_EDP;
+ return encoder->type == INTEL_OUTPUT_EDP;
}
-static void psb_intel_dp_start_link_train(struct psb_intel_output *output);
-static void psb_intel_dp_complete_link_train(struct psb_intel_output *output);
-static void psb_intel_dp_link_down(struct psb_intel_output *output);
+static void cdv_intel_dp_start_link_train(struct psb_intel_encoder *encoder);
+static void cdv_intel_dp_complete_link_train(struct psb_intel_encoder
*encoder);
+static void cdv_intel_dp_link_down(struct psb_intel_encoder *encoder);
static int
-psb_intel_dp_max_lane_count(struct psb_intel_output *output)
+cdv_intel_dp_max_lane_count(struct psb_intel_encoder *encoder)
{
- struct psb_intel_dp *intel_dp = output->dev_priv;
+ struct cdv_intel_dp *intel_dp = encoder->dev_priv;
int max_lane_count = 4;
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11) {
@@ -123,9 +122,9 @@ psb_intel_dp_max_lane_count(struct psb_intel_output *output)
}
static int
-psb_intel_dp_max_link_bw(struct psb_intel_output *output)
+cdv_intel_dp_max_link_bw(struct psb_intel_encoder *encoder)
{
- struct psb_intel_dp *intel_dp = output->dev_priv;
+ struct cdv_intel_dp *intel_dp = encoder->dev_priv;
int max_link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE];
switch (max_link_bw) {
@@ -140,7 +139,7 @@ psb_intel_dp_max_link_bw(struct psb_intel_output *output)
}
static int
-psb_intel_dp_link_clock(uint8_t link_bw)
+cdv_intel_dp_link_clock(uint8_t link_bw)
{
if (link_bw == DP_LINK_BW_2_7)
return 27;
@@ -149,28 +148,28 @@ psb_intel_dp_link_clock(uint8_t link_bw)
}
static int
-psb_intel_dp_link_
[PATCH 4/8] cdv: add the bits that don't need the new code
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/cdv_intel_display.c | 99 +++-
drivers/gpu/drm/gma500/framebuffer.c |4 +
drivers/gpu/drm/gma500/psb_intel_drv.h |2 -
4 files changed, 161 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index b7e7b49..e2fff24 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -488,6 +488,65 @@ static void cdv_hotplug_enable(struct drm_device *dev,
bool on)
}
}
+static const char *force_audio_names[] = {
+ "off",
+ "auto",
+ "on",
+};
+
+void cdv_intel_attach_force_audio_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ struct drm_property *prop;
+ int i;
+
+ prop = dev_priv->force_audio_property;
+ if (prop == NULL) {
+ prop = drm_property_create(dev, DRM_MODE_PROP_ENUM,
+ "audio",
+ ARRAY_SIZE(force_audio_names));
+ if (prop == NULL)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(force_audio_names); i++)
+ drm_property_add_enum(prop, i, i-1,
force_audio_names[i]);
+
+ dev_priv->force_audio_property = prop;
+ }
+ drm_connector_attach_property(connector, prop, 0);
+}
+
+
+static const char *broadcast_rgb_names[] = {
+ "Full",
+ "Limited 16:235",
+};
+
+void cdv_intel_attach_broadcast_rgb_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ struct drm_property *prop;
+ int i;
+
+ prop = dev_priv->broadcast_rgb_property;
+ if (prop == NULL) {
+ prop = drm_property_create(dev, DRM_MODE_PROP_ENUM,
+ "Broadcast RGB",
+ ARRAY_SIZE(broadcast_rgb_names));
+ if (prop == NULL)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(broadcast_rgb_names); i++)
+ drm_property_add_enum(prop, i, i,
broadcast_rgb_names[i]);
+
+ dev_priv->broadcast_rgb_property = prop;
+ }
+
+ drm_connector_attach_property(connector, prop, 0);
+}
+
/* Cedarview */
static const struct psb_offset cdv_regmap[2] = {
{
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index f16169c..2e0231e 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -64,11 +64,16 @@ struct cdv_intel_limit_t {
static bool cdv_intel_find_best_PLL(const struct cdv_intel_limit_t *limit,
struct drm_crtc *crtc, int target, int refclk,
struct cdv_intel_clock_t *best_clock);
+static bool cdv_intel_find_dp_pll(const struct cdv_intel_limit_t *limit,
struct drm_crtc *crtc, int target,
+ int refclk,
+ struct cdv_intel_clock_t *best_clock);
#define CDV_LIMIT_SINGLE_LVDS_96 0
#define CDV_LIMIT_SINGLE_LVDS_100 1
#define CDV_LIMIT_DAC_HDMI_27 2
#define CDV_LIMIT_DAC_HDMI_96 3
+#define CDV_LIMIT_DP_274
+#define CDV_LIMIT_DP_100 5
static const struct cdv_intel_limit_t cdv_intel_limits[] = {
{ /* CDV_SIGNLE_LVDS_96MHz */
@@ -123,6 +128,30 @@ static const struct cdv_intel_limit_t cdv_intel_limits[] =
{
.p2 = {.dot_limit = 225000, .p2_slow = 10, .p2_fast = 5},
.find_pll = cdv_intel_find_best_PLL,
},
+ { /* CDV_DP_27MHz */
+.dot = {.min = 16, .max = 272000},
+.vco = {.min = 1809000, .max = 3564000},
+.n = {.min = 1, .max = 1},
+.m = {.min = 67, .max = 132},
+.m1 = {.min = 0, .max = 0},
+.m2 = {.min = 65, .max = 130},
+.p = {.min = 5, .max = 90},
+.p1 = {.min = 1, .max = 9},
+.p2 = {.dot_limit = 225000, .p2_slow = 10, .p2_fast = 10},
+.find_pll = cdv_intel_find_dp_pll,
+},
+ { /* CDV_DP_100MHz */
+.dot = {.min = 16, .max = 272000},
+.vco = {.min = 180, .max = 360},
+.n = {.min = 2, .max = 6},
+.m = {.min = 60, .max = 164},
+.m1 = {.min = 0, .max = 0},
+.m2 = {.min = 58, .
[PATCH 3/8] From: Zhao Yakui
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 | 1504
drivers/gpu/drm/gma500/psb_intel_drv.h |6
drivers/gpu/drm/gma500/psb_intel_reg.h | 155 +++
3 files changed, 1661 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/gma500/cdv_intel_dp.c
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
new file mode 100644
index 000..c6d545d
--- /dev/null
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -0,0 +1,1504 @@
+/*
+ * Copyright ? 2012 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Keith Packard
+ *
+ */
+
+#include
+#include
+#include "drmP.h"
+#include "drm.h"
+#include "drm_crtc.h"
+#include "drm_crtc_helper.h"
+#include "psb_drv.h"
+#include "psb_intel_drv.h"
+#include "psb_drm.h"
+#include "psb_intel_reg.h"
+#include "drm_dp_helper.h"
+
+
+#define DP_LINK_STATUS_SIZE6
+#define DP_LINK_CHECK_TIMEOUT (10 * 1000)
+
+#define DP_LINK_CONFIGURATION_SIZE 9
+
+#define CDV_FAST_LINK_TRAIN1
+
+struct psb_intel_dp {
+ uint32_t output_reg;
+ uint32_t DP;
+ uint8_t link_configuration[DP_LINK_CONFIGURATION_SIZE];
+ bool has_audio;
+ int force_audio;
+ uint32_t color_range;
+ uint8_t link_bw;
+ uint8_t lane_count;
+ uint8_t dpcd[4];
+ struct psb_intel_output *output;
+ struct i2c_adapter adapter;
+ struct i2c_algo_dp_aux_data algo;
+ uint8_t train_set[4];
+ uint8_t link_status[DP_LINK_STATUS_SIZE];
+};
+
+struct ddi_regoff {
+ uint32_tPreEmph1;
+ uint32_tPreEmph2;
+ uint32_tVSwing1;
+ uint32_tVSwing2;
+ uint32_tVSwing3;
+ uint32_tVSwing4;
+ uint32_tVSwing5;
+};
+
+static struct ddi_regoff ddi_DP_train_table[] = {
+ {.PreEmph1 = 0x812c, .PreEmph2 = 0x8124, .VSwing1 = 0x8154,
+ .VSwing2 = 0x8148, .VSwing3 = 0x814C, .VSwing4 = 0x8150,
+ .VSwing5 = 0x8158,},
+ {.PreEmph1 = 0x822c, .PreEmph2 = 0x8224, .VSwing1 = 0x8254,
+ .VSwing2 = 0x8248, .VSwing3 = 0x824C, .VSwing4 = 0x8250,
+ .VSwing5 = 0x8258,},
+};
+
+static uint32_t dp_vswing_premph_table[] = {
+0x55338954,0x4000,
+0x554d8954,0x2000,
+0x55668954,0,
+0x559ac0d4,0x6000,
+};
+/**
+ * is_edp - is the given port attached to an eDP panel (either CPU or PCH)
+ * @intel_dp: DP struct
+ *
+ * If a CPU or PCH DP output is attached to an eDP panel, this function
+ * will return true, and false otherwise.
+ */
+static bool is_edp(struct psb_intel_output *output)
+{
+ return output->type == INTEL_OUTPUT_EDP;
+}
+
+
+static void psb_intel_dp_start_link_train(struct psb_intel_output *output);
+static void psb_intel_dp_complete_link_train(struct psb_intel_output *output);
+static void psb_intel_dp_link_down(struct psb_intel_output *output);
+
+static int
+psb_intel_dp_max_lane_count(struct psb_intel_output *output)
+{
+ struct psb_intel_dp *intel_dp = output->dev_priv;
+ int max_lane_count = 4;
+
+ if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11) {
+ max_lane_count = intel_dp->dpcd[DP_MAX_LANE_COUNT] & 0x1f;
+ switch (max_lane_count) {
+ case 1: case 2: case 4:
+ break;
+ default:
+ max_lane_count = 4;
+ }
+ }
+ return max_lane_count;
+}
+
+static int
+psb_intel_dp_max_link_bw(struct psb_intel_
[PATCH 2/8] Program the DPLL lane based on the selected digitial port
From: Zhao Yakui
Based on the spec, the CRT output doesn't use the lane. And the HDMI B output
uses the Lane0/1 while the HDMI C output uses the Lane 2/3. But currently
it will program all the four lanes for the CRT/HDMI.
Signed-off-by: Zhao Yakui
[Ported to the in-kernel driver]
Signed-off-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/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 5c3a312..f16169c 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -57,8 +57,14 @@ struct cdv_intel_clock_t {
struct cdv_intel_limit_t {
struct cdv_intel_range_t dot, vco, n, m, m1, m2, p, p1;
struct cdv_intel_p2_t p2;
+ bool (*find_pll)(const struct cdv_intel_limit_t *, struct drm_crtc *,
+ int, int, struct cdv_intel_clock_t *);
};
+static bool cdv_intel_find_best_PLL(const struct cdv_intel_limit_t *limit,
+ struct drm_crtc *crtc, int target, int refclk,
+ struct cdv_intel_clock_t *best_clock);
+
#define CDV_LIMIT_SINGLE_LVDS_96 0
#define CDV_LIMIT_SINGLE_LVDS_100 1
#define CDV_LIMIT_DAC_HDMI_27 2
@@ -76,6 +82,7 @@ static const struct cdv_intel_limit_t cdv_intel_limits[] = {
.p1 = {.min = 2, .max = 10},
.p2 = {.dot_limit = 20,
.p2_slow = 14, .p2_fast = 14},
+ .find_pll = cdv_intel_find_best_PLL,
},
{ /* CDV_SINGLE_LVDS_100MHz */
.dot = {.min = 2, .max = 115500},
@@ -90,6 +97,7 @@ static const struct cdv_intel_limit_t cdv_intel_limits[] = {
* is 80-224Mhz. Prefer single channel as much as possible.
*/
.p2 = {.dot_limit = 20, .p2_slow = 14, .p2_fast = 14},
+ .find_pll = cdv_intel_find_best_PLL,
},
{ /* CDV_DAC_HDMI_27MHz */
.dot = {.min = 2, .max = 40},
@@ -101,6 +109,7 @@ static const struct cdv_intel_limit_t cdv_intel_limits[] = {
.p = {.min = 5, .max = 90},
.p1 = {.min = 1, .max = 9},
.p2 = {.dot_limit = 225000, .p2_slow = 10, .p2_fast = 5},
+ .find_pll = cdv_intel_find_best_PLL,
},
{ /* CDV_DAC_HDMI_96MHz */
.dot = {.min = 2, .max = 40},
@@ -112,6 +121,7 @@ static const struct cdv_intel_limit_t cdv_intel_limits[] = {
.p = {.min = 5, .max = 100},
.p1 = {.min = 1, .max = 10},
.p2 = {.dot_limit = 225000, .p2_slow = 10, .p2_fast = 5},
+ .find_pll = cdv_intel_find_best_PLL,
},
};
@@ -216,7 +226,7 @@ static void cdv_sb_reset(struct drm_device *dev)
*/
static int
cdv_dpll_set_clock_cdv(struct drm_device *dev, struct drm_crtc *crtc,
- struct cdv_intel_clock_t *clock, bool is_lvds)
+ struct cdv_intel_clock_t *clock, bool is_lvds,
u32 ddi_select)
{
struct psb_intel_crtc *psb_crtc = to_psb_intel_crtc(crtc);
int pipe = psb_crtc->pipe;
@@ -336,30 +346,33 @@ cdv_dpll_set_clock_cdv(struct drm_device *dev, struct
drm_crtc *crtc,
if (ret)
return ret;
- lane_reg = PSB_LANE0;
- cdv_sb_read(dev, lane_reg, &lane_value);
- lane_value &= ~(LANE_PLL_MASK);
- lane_value |= LANE_PLL_ENABLE | LANE_PLL_PIPE(pipe);
- cdv_sb_write(dev, lane_reg, lane_value);
-
- lane_reg = PSB_LANE1;
- cdv_sb_read(dev, lane_reg, &lane_value);
- lane_value &= ~(LANE_PLL_MASK);
- lane_value |= LANE_PLL_ENABLE | LANE_PLL_PIPE(pipe);
- cdv_sb_write(dev, lane_reg, lane_value);
-
- lane_reg = PSB_LANE2;
- cdv_sb_read(dev, lane_reg, &lane_value);
- lane_value &= ~(LANE_PLL_MASK);
- lane_value |= LANE_PLL_ENABLE | LANE_PLL_PIPE(pipe);
- cdv_sb_write(dev, lane_reg, lane_value);
-
- lane_reg = PSB_LANE3;
- cdv_sb_read(dev, lane_reg, &lane_value);
- lane_value &= ~(LANE_PLL_MASK);
- lane_value |= LANE_PLL_ENABLE | LANE_PLL_PIPE(pipe);
- cdv_sb_write(dev, lane_reg, lane_value);
-
+ if (ddi_select) {
+ if ((ddi_select & DDI_MASK) == DDI0_SELECT) {
+ lane_reg = PSB_LANE0;
+ cdv_sb_read(dev, lane_reg, &lane_value);
+ lane_value &= ~(LANE_PLL_MASK);
+ lane_value |= LANE_PLL_ENABLE | LANE_PLL_PIPE(pipe);
+ cdv_sb_write(dev, lane_reg, lane_value);
+
+ lane_reg = PSB_LANE1;
+ cdv_sb_read(dev, lane_reg, &lane_value);
+ lane_value &= ~(LANE_PLL_MASK);
+
[PATCH 1/8] Fix incorrect SR issue when disabling CRTC already in disabled state
From: Zhao Yakui Currently when trying to call the DPMS off again for one CRTC with DPMS off, it will firstly disable the SR and can't enable it again because of the incorrect check/logic. In such case the self refresh is still disabled although one CRTC pipe is active. This is wrong. Signed-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 index a68509b..5c3a312 100644 --- a/drivers/gpu/drm/gma500/cdv_intel_display.c +++ b/drivers/gpu/drm/gma500/cdv_intel_display.c @@ -791,7 +791,7 @@ static void cdv_intel_crtc_dpms(struct drm_crtc *crtc, int mode) case DRM_MODE_DPMS_STANDBY: case DRM_MODE_DPMS_SUSPEND: if (psb_intel_crtc->active) - return; + break; psb_intel_crtc->active = true; @@ -835,7 +835,6 @@ static void cdv_intel_crtc_dpms(struct drm_crtc *crtc, int mode) REG_WRITE(map->status, temp); REG_READ(map->status); - cdv_intel_update_watermark(dev, crtc); cdv_intel_crtc_load_lut(crtc); /* Give the overlay scaler a chance to enable @@ -845,7 +844,7 @@ static void cdv_intel_crtc_dpms(struct drm_crtc *crtc, int mode) break; case DRM_MODE_DPMS_OFF: if (!psb_intel_crtc->active) - return; + break; psb_intel_crtc->active = false; @@ -892,10 +891,10 @@ static void cdv_intel_crtc_dpms(struct drm_crtc *crtc, int mode) /* Wait for the clocks to turn off. */ udelay(150); - cdv_intel_update_watermark(dev, crtc); psb_intel_crtc->crtc_enable = false; break; } + cdv_intel_update_watermark(dev, crtc); /*Set FIFO Watermarks*/ REG_WRITE(DSPARB, 0x3F3E); }
[PATCH 8/8] From: Zhao Yakui
From: Zhao Yakui
Disable the clock gating of display controller to make DP/eDP work well
I don't know why the DP/eDP is affected by the clock gating. But the test
shows that it really fixes the DP/eDP clock issue during enabling DP/eDP.
Signed-off-by: Zhao Yakui
[Updated 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 --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index 0571ef9b..9bacce3 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -1778,6 +1778,28 @@ static bool cdv_intel_dpc_is_edp(struct drm_device *dev)
return false;
}
+/* Cedarview display clock gating
+
+ We need this disable dot get correct behaviour while enabling
+ DP/eDP. TODO - investigate if we can turn it back to normality
+ after enabling */
+static void cdv_disable_intel_clock_gating(struct drm_device *dev)
+{
+ u32 reg_value;
+ reg_value = REG_READ(DSPCLK_GATE_D);
+
+ reg_value |= (DPUNIT_PIPEB_GATE_DISABLE |
+ DPUNIT_PIPEA_GATE_DISABLE |
+ DPCUNIT_CLOCK_GATE_DISABLE |
+ DPLSUNIT_CLOCK_GATE_DISABLE |
+ DPOUNIT_CLOCK_GATE_DISABLE |
+ DPIOUNIT_CLOCK_GATE_DISABLE);
+
+ REG_WRITE(DSPCLK_GATE_D, reg_value);
+
+ udelay(500);
+}
+
void
cdv_intel_dp_init(struct drm_device *dev, struct psb_intel_mode_device
*mode_dev, int output_reg)
{
@@ -1841,6 +1863,8 @@ cdv_intel_dp_init(struct drm_device *dev, struct
psb_intel_mode_device *mode_dev
break;
}
+ cdv_disable_intel_clock_gating(dev);
+
cdv_intel_dp_i2c_init(psb_intel_connector, psb_intel_encoder, name);
/* FIXME:fail check */
cdv_intel_dp_add_properties(connector);
diff --git a/drivers/gpu/drm/gma500/psb_intel_reg.h
b/drivers/gpu/drm/gma500/psb_intel_reg.h
index 389e969..d914719 100644
--- a/drivers/gpu/drm/gma500/psb_intel_reg.h
+++ b/drivers/gpu/drm/gma500/psb_intel_reg.h
@@ -1313,6 +1313,10 @@ No status bits are changed.
# define VRHUNIT_CLOCK_GATE_DISABLE(1 << 28) /* Fixed value on CDV
*/
# define DPOUNIT_CLOCK_GATE_DISABLE(1 << 11)
# define DPIOUNIT_CLOCK_GATE_DISABLE (1 << 6)
+# define DPUNIT_PIPEB_GATE_DISABLE (1 << 30)
+# define DPUNIT_PIPEA_GATE_DISABLE (1 << 25)
+# define DPCUNIT_CLOCK_GATE_DISABLE(1 << 24)
+# define DPLSUNIT_CLOCK_GATE_DISABLE (1 << 13)
#define RAMCLK_GATE_D 0x6210
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8] cdv: Add eDP support
From: Zhao Yakui
Introduce the eDP support into the driver.
This has been reworked a bit because kernel driver proper uses
encoder/connectors
while the legacy Intel driver uses the old output stuff.
It also diverges on the backlight handling. The legacy Intel driver 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/gpu/drm/gma500/backlight.c | 45 +++
drivers/gpu/drm/gma500/cdv_device.c|1
drivers/gpu/drm/gma500/cdv_intel_display.c | 42 ++-
drivers/gpu/drm/gma500/cdv_intel_dp.c | 468 +++-
drivers/gpu/drm/gma500/cdv_intel_lvds.c| 12 -
drivers/gpu/drm/gma500/framebuffer.c |3
drivers/gpu/drm/gma500/intel_bios.c| 101 ++
drivers/gpu/drm/gma500/intel_bios.h| 46 +++
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 13 -
drivers/gpu/drm/gma500/mid_bios.c |8
drivers/gpu/drm/gma500/opregion.c |3
drivers/gpu/drm/gma500/psb_drv.h | 19 +
drivers/gpu/drm/gma500/psb_intel_lvds.c| 13 -
drivers/gpu/drm/gma500/psb_intel_reg.h | 38 ++
14 files changed, 751 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/gma500/backlight.c
b/drivers/gpu/drm/gma500/backlight.c
index 2079395..143eba3 100644
--- a/drivers/gpu/drm/gma500/backlight.c
+++ b/drivers/gpu/drm/gma500/backlight.c
@@ -26,10 +26,55 @@
#include "intel_bios.h"
#include "power.h"
+static void do_gma_backlight_set(struct drm_device *dev)
+{
+#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ backlight_update_status(dev_priv->backlight_device);
+#endif
+}
+
+void gma_backlight_enable(struct drm_device *dev)
+{
+#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ dev_priv->backlight_enabled = true;
+ if (dev_priv->backlight_device) {
+ dev_priv->backlight_device->props.brightness =
dev_priv->backlight_level;
+ do_gma_backlight_set(dev);
+ }
+#endif
+}
+
+void gma_backlight_disable(struct drm_device *dev)
+{
+#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ dev_priv->backlight_enabled = false;
+ if (dev_priv->backlight_device) {
+ dev_priv->backlight_device->props.brightness = 0;
+ do_gma_backlight_set(dev);
+ }
+#endif
+}
+
+void gma_backlight_set(struct drm_device *dev, int v)
+{
+#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ dev_priv->backlight_level = v;
+ if (dev_priv->backlight_device && dev_priv->backlight_enabled) {
+ dev_priv->backlight_device->props.brightness = v;
+ do_gma_backlight_set(dev);
+ }
+#endif
+}
+
int gma_backlight_init(struct drm_device *dev)
{
#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
struct drm_psb_private *dev_priv = dev->dev_private;
+ dev_priv->backlight_enabled = true;
return dev_priv->ops->backlight_init(dev);
#else
return 0;
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index 68f100e..4882e64 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -170,6 +170,7 @@ static int cdv_backlight_init(struct drm_device *dev)
cdv_get_brightness(cdv_backlight_device);
backlight_update_status(cdv_backlight_device);
dev_priv->backlight_device = cdv_backlight_device;
+ dev_priv->backlight_enabled = true;
return 0;
}
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 3f11060..bfb0565 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -438,7 +438,8 @@ static const struct cdv_intel_limit_t
*cdv_intel_limit(struct drm_crtc *crtc,
limit = &cdv_intel_limits[CDV_LIMIT_SINGLE_LVDS_96];
else
limit = &cdv_intel_limits[CDV_LIMIT_SINGLE_LVDS_100];
- } else if (psb_intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
+ } else if (psb_intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT) ||
+ psb_intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP)) {
if (refclk == 27000)
limit = &cdv_intel_limits[CDV_LIMIT_DP_27];
else
@@ -1045,6 +1046,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
struct drm_connector *connector;
const struct cdv_intel_limit_
[PATCH 6/8] cdv: enable the DisplayPort support
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..68f100e 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -58,10 +58,17 @@ static int cdv_output_init(struct drm_device *dev)
cdv_intel_lvds_init(dev, &dev_priv->mode_dev);
/* These bits indicate HDMI not SDVO on CDV */
- if (REG_READ(SDVOB) & SDVO_DETECTED)
+ if (REG_READ(SDVOB) & SDVO_DETECTED) {
cdv_hdmi_init(dev, &dev_priv->mode_dev, SDVOB);
- if (REG_READ(SDVOC) & SDVO_DETECTED)
+ if (REG_READ(DP_B) & DP_DETECTED)
+ cdv_intel_dp_init(dev, &dev_priv->mode_dev, DP_B);
+ }
+
+ if (REG_READ(SDVOC) & SDVO_DETECTED) {
cdv_hdmi_init(dev, &dev_priv->mode_dev, SDVOC);
+ if (REG_READ(DP_C) & DP_DETECTED)
+ cdv_intel_dp_init(dev, &dev_priv->mode_dev, DP_C);
+ }
return 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] cdv: sync up and add the displayport code to the build
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/gma500/psb_intel_drv.h | 16 +
4 files changed, 260 insertions(+), 245 deletions(-)
diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index 81ff7e2..7a2d40a 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -30,7 +30,8 @@ gma500_gfx-$(CONFIG_DRM_GMA3600) += cdv_device.o \
cdv_intel_crt.o \
cdv_intel_display.o \
cdv_intel_hdmi.o \
- cdv_intel_lvds.o
+ cdv_intel_lvds.o \
+ cdv_intel_dp.o
gma500_gfx-$(CONFIG_DRM_GMA600) += oaktrail_device.o \
oaktrail_crtc.o \
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 2e0231e..3f11060 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -171,7 +171,7 @@ static const struct cdv_intel_limit_t cdv_intel_limits[] = {
#define wait_for(COND, MS) _wait_for(COND, MS, 1)
-static int cdv_sb_read(struct drm_device *dev, u32 reg, u32 *val)
+int cdv_sb_read(struct drm_device *dev, u32 reg, u32 *val)
{
int ret;
@@ -198,7 +198,7 @@ static int cdv_sb_read(struct drm_device *dev, u32 reg, u32
*val)
return 0;
}
-static int cdv_sb_write(struct drm_device *dev, u32 reg, u32 val)
+int cdv_sb_write(struct drm_device *dev, u32 reg, u32 val)
{
int ret;
static bool dpio_debug = true;
@@ -240,7 +240,7 @@ static int cdv_sb_write(struct drm_device *dev, u32 reg,
u32 val)
/* Reset the DPIO configuration register. The BIOS does this at every
* mode set.
*/
-static void cdv_sb_reset(struct drm_device *dev)
+void cdv_sb_reset(struct drm_device *dev)
{
REG_WRITE(DPIO_CFG, 0);
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index c6d545d..b29b602 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -33,7 +33,6 @@
#include "drm_crtc_helper.h"
#include "psb_drv.h"
#include "psb_intel_drv.h"
-#include "psb_drm.h"
#include "psb_intel_reg.h"
#include "drm_dp_helper.h"
@@ -45,7 +44,7 @@
#define CDV_FAST_LINK_TRAIN1
-struct psb_intel_dp {
+struct cdv_intel_dp {
uint32_t output_reg;
uint32_t DP;
uint8_t link_configuration[DP_LINK_CONFIGURATION_SIZE];
@@ -55,7 +54,7 @@ struct psb_intel_dp {
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[4];
- struct psb_intel_output *output;
+ struct psb_intel_encoder *encoder;
struct i2c_adapter adapter;
struct i2c_algo_dp_aux_data algo;
uint8_t train_set[4];
@@ -94,20 +93,20 @@ static uint32_t dp_vswing_premph_table[] = {
* If a CPU or PCH DP output is attached to an eDP panel, this function
* will return true, and false otherwise.
*/
-static bool is_edp(struct psb_intel_output *output)
+static bool is_edp(struct psb_intel_encoder *encoder)
{
- return output->type == INTEL_OUTPUT_EDP;
+ return encoder->type == INTEL_OUTPUT_EDP;
}
-static void psb_intel_dp_start_link_train(struct psb_intel_output *output);
-static void psb_intel_dp_complete_link_train(struct psb_intel_output *output);
-static void psb_intel_dp_link_down(struct psb_intel_output *output);
+static void cdv_intel_dp_start_link_train(struct psb_intel_encoder *encoder);
+static void cdv_intel_dp_complete_link_train(struct psb_intel_encoder
*encoder);
+static void cdv_intel_dp_link_down(struct psb_intel_encoder *encoder);
static int
-psb_intel_dp_max_lane_count(struct psb_intel_output *output)
+cdv_intel_dp_max_lane_count(struct psb_intel_encoder *encoder)
{
- struct psb_intel_dp *intel_dp = output->dev_priv;
+ struct cdv_intel_dp *intel_dp = encoder->dev_priv;
int max_lane_count = 4;
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11) {
@@ -123,9 +122,9 @@ psb_intel_dp_max_lane_count(struct psb_intel_output *output)
}
static int
-psb_intel_dp_max_link_bw(struct psb_intel_output *output)
+cdv_intel_dp_max_link_bw(struct psb_intel_encoder *encoder)
{
- struct psb_intel_dp *intel_dp = output->dev_priv;
+ struct cdv_intel_dp *intel_dp = encoder->dev_priv;
int max_link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE];
switch (max_link_bw) {
@@ -140,7 +139,7 @@ psb_intel_dp_max_link_bw(struct psb_intel_output *output)
}
static int
-psb_intel_dp_link_clock(uint8_t link_bw)
+cdv_intel_dp_link_clock(uint8_t link_bw)
{
if (link_bw == DP_LINK_BW_2_7)
return 27;
@@ -149,28 +148,28 @@ psb_intel_dp_link_clock(uint8_t link_bw)
}
static in
[PATCH 4/8] cdv: add the bits that don't need the new code
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/cdv_intel_display.c | 99 +++-
drivers/gpu/drm/gma500/framebuffer.c |4 +
drivers/gpu/drm/gma500/psb_intel_drv.h |2 -
4 files changed, 161 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index b7e7b49..e2fff24 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -488,6 +488,65 @@ static void cdv_hotplug_enable(struct drm_device *dev,
bool on)
}
}
+static const char *force_audio_names[] = {
+ "off",
+ "auto",
+ "on",
+};
+
+void cdv_intel_attach_force_audio_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ struct drm_property *prop;
+ int i;
+
+ prop = dev_priv->force_audio_property;
+ if (prop == NULL) {
+ prop = drm_property_create(dev, DRM_MODE_PROP_ENUM,
+ "audio",
+ ARRAY_SIZE(force_audio_names));
+ if (prop == NULL)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(force_audio_names); i++)
+ drm_property_add_enum(prop, i, i-1,
force_audio_names[i]);
+
+ dev_priv->force_audio_property = prop;
+ }
+ drm_connector_attach_property(connector, prop, 0);
+}
+
+
+static const char *broadcast_rgb_names[] = {
+ "Full",
+ "Limited 16:235",
+};
+
+void cdv_intel_attach_broadcast_rgb_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_psb_private *dev_priv = dev->dev_private;
+ struct drm_property *prop;
+ int i;
+
+ prop = dev_priv->broadcast_rgb_property;
+ if (prop == NULL) {
+ prop = drm_property_create(dev, DRM_MODE_PROP_ENUM,
+ "Broadcast RGB",
+ ARRAY_SIZE(broadcast_rgb_names));
+ if (prop == NULL)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(broadcast_rgb_names); i++)
+ drm_property_add_enum(prop, i, i,
broadcast_rgb_names[i]);
+
+ dev_priv->broadcast_rgb_property = prop;
+ }
+
+ drm_connector_attach_property(connector, prop, 0);
+}
+
/* Cedarview */
static const struct psb_offset cdv_regmap[2] = {
{
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index f16169c..2e0231e 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -64,11 +64,16 @@ struct cdv_intel_limit_t {
static bool cdv_intel_find_best_PLL(const struct cdv_intel_limit_t *limit,
struct drm_crtc *crtc, int target, int refclk,
struct cdv_intel_clock_t *best_clock);
+static bool cdv_intel_find_dp_pll(const struct cdv_intel_limit_t *limit,
struct drm_crtc *crtc, int target,
+ int refclk,
+ struct cdv_intel_clock_t *best_clock);
#define CDV_LIMIT_SINGLE_LVDS_96 0
#define CDV_LIMIT_SINGLE_LVDS_100 1
#define CDV_LIMIT_DAC_HDMI_27 2
#define CDV_LIMIT_DAC_HDMI_96 3
+#define CDV_LIMIT_DP_274
+#define CDV_LIMIT_DP_100 5
static const struct cdv_intel_limit_t cdv_intel_limits[] = {
{ /* CDV_SIGNLE_LVDS_96MHz */
@@ -123,6 +128,30 @@ static const struct cdv_intel_limit_t cdv_intel_limits[] =
{
.p2 = {.dot_limit = 225000, .p2_slow = 10, .p2_fast = 5},
.find_pll = cdv_intel_find_best_PLL,
},
+ { /* CDV_DP_27MHz */
+.dot = {.min = 16, .max = 272000},
+.vco = {.min = 1809000, .max = 3564000},
+.n = {.min = 1, .max = 1},
+.m = {.min = 67, .max = 132},
+.m1 = {.min = 0, .max = 0},
+.m2 = {.min = 65, .max = 130},
+.p = {.min = 5, .max = 90},
+.p1 = {.min = 1, .max = 9},
+.p2 = {.dot_limit = 225000, .p2_slow = 10, .p2_fast = 10},
+.find_pll = cdv_intel_find_dp_pll,
+},
+ { /* CDV_DP_100MHz */
+.dot = {.min = 16, .max = 272000},
+.vco = {.min = 180, .max = 360},
+.n = {.min = 2, .max = 6},
+.m = {.min = 60, .max = 164},
+.m1 = {.min = 0, .max = 0},
+.m2 = {.min = 58, .
