[PATCH v3 25/32] drm/exynos: Clean up FIMD power on/off routines
Hi Sean, On Tuesday 29 of October 2013 12:13:11 Sean Paul wrote: > This patch separates the fimd_activate function into poweron/poweroff > functions to be more consistent with the other drivers in exynos drm. It > also properly cleans up after failures in poweron. The functions have > also been shuffled around such that they are all in the same > spot in the file and poweron/poweroff can be called from the dpms function. > > Signed-off-by: Sean Paul > --- > > Changes in v2: > - Added to the patchset > Changes in v3: None > > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 247 > +-- > 1 file changed, 135 insertions(+), 112 deletions(-) Reviewed-by: Tomasz Figa Best regards, Tomasz
[Bug 64781] RV630 bad video playback (too fast) when HDMI audio output is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=64781 Giannis changed: What|Removed |Added Kernel Version|3.10-RC1|3.10-RC1+ Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 24/32] drm/exynos: Implement dpms display callback in DP
Hi Sean,
On Tuesday 29 of October 2013 12:13:10 Sean Paul wrote:
> This patch implements the dpms display callback for the DP driver.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2:
> - Added to the patchset
> Changes in v3: None
>
> drivers/gpu/drm/exynos/exynos_dp_core.c | 173
>
> drivers/gpu/drm/exynos/exynos_dp_core.h | 1 +
> 2 files changed, 85 insertions(+), 89 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 13ea8b7..476d3b0 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
[snip]
> @@ -1190,26 +1205,17 @@ static int exynos_dp_probe(struct platform_device
> *pdev)
>
> dp->video_info = pdata->video_info;
>
> - if (pdev->dev.of_node) {
> - if (dp->phy_addr)
> - exynos_dp_phy_init(dp);
> - } else {
> - if (pdata->phy_init)
> - pdata->phy_init();
> - }
> -
> - exynos_dp_init_dp(dp);
> -
> ret = devm_request_irq(&pdev->dev, dp->irq, exynos_dp_irq_handler, 0,
> "exynos-dp", dp);
> if (ret) {
> dev_err(&pdev->dev, "failed to request irq\n");
> return ret;
> }
> -
> - platform_set_drvdata(pdev, dp);
> + disable_irq(dp->irq);
>
> exynos_dp_display.ctx = dp;
> +
> + platform_set_drvdata(pdev, &exynos_dp_display);
This is probably more a comment to previous patch, but what about multiple
instances of display port controller? The solution would be something
I proposed in my reply to one of HDMI related patches.
Otherwise the patch looks fine.
Best regards,
Tomasz
[PATCH v3 25/32] drm/exynos: Clean up FIMD power on/off routines
> -Original Message- > From: Tomasz Figa [mailto:tomasz.figa at gmail.com] > Sent: Monday, November 11, 2013 11:09 AM > To: Inki Dae > Cc: 'Sean Paul'; dri-devel at lists.freedesktop.org; airlied at linux.ie; > marcheu at chromium.org > Subject: Re: [PATCH v3 25/32] drm/exynos: Clean up FIMD power on/off > routines > > On Thursday 31 of October 2013 19:54:18 Inki Dae wrote: > > > > As I mentioned already, I'll not merge eDP related codes yet. So can you > > rebase patche 25 through 26 to top of patch 20? > > Why not? IMHO Exynos DRM is already the only way to support Exynos DP > and it should simplify things. Of course, only if done properly and not > breaking other things. > Your late comment. I wanted to merge only the re-factoring patch series because Sean missed CCing proper person and I was not sure that moving eDP driver into Exynos drm is good way or not _for the moment_. So I just wanted to have time enough about merging this patch and watch out how other maintainers will handle the similar thing. However, s3c-fb driver wouldn't be used anymore and Jingoo commented enough - for this, see the original email thread - so the moving is reasonable to me. Thanks, Inki Dae > Best regards, > Tomasz
[PATCH v3 27/32] drm/exynos: Add create_connector callback
On Tuesday 29 of October 2013 12:13:13 Sean Paul wrote: > This creates a new display hook called create_connector. The purpose is > to allow the display driver to create its own drm_connector instead of > using the exynos_drm_connector. This moves things closer to completely > removing the exynos_drm_connector abstraction. > > Signed-off-by: Sean Paul > --- > > Changes in v2: None > Changes in v3: > - Added to the patchset > > drivers/gpu/drm/exynos/exynos_drm_core.c | 3 +++ > drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 ++ > 2 files changed, 5 insertions(+) Reviewed-by: Tomasz Figa Best regards, Tomasz
[Bug 64781] New: RV630 bad video playback (too fast) when HDMI audio output is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=64781 Bug ID: 64781 Summary: RV630 bad video playback (too fast) when HDMI audio output is enabled Product: Drivers Version: 2.5 Kernel Version: 3.10-RC1 Hardware: i386 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: karzisss at hotmail.com Regression: No Bug appeared from 3.10-RC1 kernel version and later. Still is unsolved with 3.12 kernel release. Last known good kernel was 3.9.11. Ati Radeon 2600 PRO 512mb (Asus) Gigabyte GA-MA790X-DS4 (BIOS F9) Bug is reported to Launchpad too and seems affecting many users. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1239233 -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 20/32] drm/exynos: Remove unused/useless fimd_context members
Hi Sean, On Tuesday 29 of October 2013 12:13:06 Sean Paul wrote: > This patch removes a few fimd_context members which are either entirely > unused or unneeded. > > Signed-off-by: Sean Paul > --- > > Changes in v2: None > Changes in v3: None > > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 13 + > 1 file changed, 1 insertion(+), 12 deletions(-) Reviewed-by: Tomasz Figa Best regards, Tomasz
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #5 from Christian K?nig --- (In reply to comment #4) > FATAL: get_bits failed : No backend implementation could be loaded.!! > > There's some problem with your build. That message is normal, just a function we haven't implemented yet. But I agree the numbers look like you are on the bootup clocks for UVD/graphics or something is going wrong with dpm. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/ca718c73/attachment.html>
[Bug 71431] radeon graphics stopped working since kernel 3.10 on AMD a4-3300
https://bugs.freedesktop.org/show_bug.cgi?id=71431 --- Comment #5 from ka.nick at mail.ru --- Yes, within few days... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131111/ac049136/attachment.html>
[PATCH 0/3] Deprecate legacy crap
Hi all, Spurred by Ian's abuse of drmAgpSize I've figued it's time we accelerate the demisse of the fake agp stuff and our ums code a bit. The idea is to send out the same probe the radone guys have done and deprecate legacy stuff for now. Then (presuming we don't get any reports from hurt users) we can rip the code out after a few releases. In both cases (killing fake agp and killing ums) we can just keep doing what we've done thus far as contingency. But for ums I expect that we need to copy-paste the driver long term to stay sane. Just removing it is obviously easier ;-) Cheers, Daniel Daniel Vetter (3): drm/i915: Make AGP=n work even on gen3 drm/i915: Kill legeacy AGP for gen3 kms drm/i915: Deprecated UMS support drivers/gpu/drm/i915/Kconfig| 24 +++- drivers/gpu/drm/i915/i915_drv.c | 14 ++ 2 files changed, 21 insertions(+), 17 deletions(-) -- 1.8.4.rc3
[PATCH 1/3] drm/i915: Make AGP=n work even on gen3
Most platforms din't hit this condition, but if we want to allow
building without agp we should also make this allowed on gen3.
Cc: Ville Syrj?l?
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 38a344694e35..d7c922051c89 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -158,7 +158,7 @@ static struct drm_driver driver;
#if IS_ENABLED(CONFIG_AGP_INTEL)
extern int intel_agp_enabled;
#else
-static int intel_agp_enabled;
+static int intel_agp_enabled = 1;
#endif
static const struct intel_device_info intel_i830_info = {
--
1.8.4.rc3
[PATCH 2/3] drm/i915: Kill legeacy AGP for gen3 kms
Thus far we've tried to carefully work around the fact that old
userspace relied on the AGP-backed legacy buffer mapping ioctls for a
bit too long. But it's really horribly, and now some new users for it
started to show up again:
http://www.mail-archive.com/mesa-dev at lists.freedesktop.org/msg45547.html
This uses drmAgpSize to figure out the GTT size, which is both the
wrong thing to inquire and also might force us to keep this crap
around for another few years.
So I want to stop this particular zombie from raising ever again. Now
it's only been 4 years since XvMC was fixed for gen3, so a bit early
by the usual rules. But since Linus explicitly said that an ABI
breakage only counts if someone actually observes it I want to tempt
fate an accelarate the demise of AGP.
We probably need to wait 2-3 kernel releases with this shipping until
we go on a killing spree code-wise.
Cc: Ville Syrj?l?
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d7c922051c89..93a8e0316bd0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -797,17 +797,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (PCI_FUNC(pdev->devfn))
return -ENODEV;
- /* We've managed to ship a kms-enabled ddx that shipped with an XvMC
-* implementation for gen3 (and only gen3) that used legacy drm maps
-* (gasp!) to share buffers between X and the client. Hence we need to
-* keep around the fake agp stuff for gen3, even when kms is enabled. */
- if (intel_info->gen != 3) {
- driver.driver_features &=
- ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);
- } else if (!intel_agp_enabled) {
- DRM_ERROR("drm/i915 can't work without intel_agp module!\n");
- return -ENODEV;
- }
+ driver.driver_features &= ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);
return drm_get_pci_dev(pdev, ent, &driver);
}
--
1.8.4.rc3
[PATCH 3/3] drm/i915: Deprecated UMS support
It's been 5 years since kms support was merged and roughly 4 years since UMS support was ripped out from userspace drivers. Thus far it's not been a big burden to keep the ums paths alive, and we've made some good progress in better separating it from the kms code by sprinkling DRIVER_MODESET checks all over the place. But now that the drm demidlayering is within reach this changes. I want to make the driver loading code more robust using devres.c and other cool tricks. But that doesn't work with ums due to the shadow-attach trick. Which means we either a) need to split out a complete ums codebase like radeon has b) kill it for good. The 2nd option is obviously much less work than the first, so I think it's time to test the waters and see how many people out there still use ums. I've decided that silently failing to initialize the driver (and not e.g. failing to load the module) is the right thing. That way we should only get reports from users that actually care about some ums features (like accelerated gl or support for secondary outputs). Everyone else will just fall back to the vesa X driver. For developers there's a small info level dmesg output. The plan is to drop this Kconfig option after 3.16 (so gives us 2 full releases) and then start killing code for real 2-3 releases afterwards. That should be more than enough time for users to pipe up. Of course if anyone does we need to revisit this plan and maybe go with option a) above. Also enable the KMS support by default in Kconfig and polish the help texts a bit. Cc: Dave Airlie Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/Kconfig | 24 +++- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index b0f61679c598..b0fa4c4055ee 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -37,12 +37,11 @@ config DRM_I915 config DRM_I915_KMS bool "Enable modesetting on intel by default" depends on DRM_I915 + default y help - Choose this option if you want kernel modesetting enabled by default, - and you have a new enough userspace to support this. Running old - userspaces with this enabled will cause pain. Note that this causes - the driver to bind to PCI devices, which precludes loading things - like intelfb. + Choose this option if you want kernel modesetting enabled by default. + + If in doubt, say "Y". config DRM_I915_FBDEV bool "Enable legacy fbdev support for the modesettting intel driver" @@ -57,9 +56,12 @@ config DRM_I915_FBDEV support. Note that this support also provide the linux console support on top of the intel modesetting driver. + If in doubt, say "Y". + config DRM_I915_PRELIMINARY_HW_SUPPORT bool "Enable preliminary support for prerelease Intel hardware by default" depends on DRM_I915 + default n help Choose this option if you have prerelease Intel hardware and want the i915 driver to support it by default. You can enable such support at @@ -67,3 +69,15 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT option changes the default for that module option. If in doubt, say "N". + +config DRM_I915_UMS + bool "Enable userspace modesetting on Intel hardware (DEPRECATED)" + depends on DRM_I915 + default n + help + Choose this option if you still need userspace modesetting. + + Userspace modesetting is deprecated for quite some time now, so + enable this only if you have ancient versions of the DDX drivers. + + If in doubt, say "N". -- 1.8.4.rc3
[PATCH v3 13/32] drm/exynos: hdmi: remove the i2c drivers and use devtree
On Sun, Nov 10, 2013 at 09:46:02PM +0100, Tomasz Figa wrote:
[...]
> On Tuesday 29 of October 2013 12:12:59 Sean Paul wrote:
[...]
> [snip]
> > @@ -1957,21 +1943,30 @@ static int hdmi_probe(struct platform_device *pdev)
> > }
> >
> > /* DDC i2c driver */
> > - if (i2c_add_driver(&ddc_driver)) {
> > - DRM_ERROR("failed to register ddc i2c driver\n");
> > - return -ENOENT;
> > + ddc_node = of_find_node_by_name(NULL, "hdmiddc");
>
> This is wrong. You shall not reference a device tree node by its name,
> except some very specific well-defined cases, such as cpus or memory
> nodes.
>
> A solution closest to yours, but correct, would be to use the same match
> table as in the I2C driver you are removing and call
> of_find_matching_node().
Isn't the correct solution to use a phandle? That might need the binding
to change in a backwards incompatible way. Then again, if something as
simple as specifying a DDC I2C bus causes the binding to change in a
backwards incompatible way then it can't have been a very good binding
in the first place, right? +1 for unstable DT bindings...
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2013/22afc651/attachment.pgp>
[PATCH RFC RESEND] dma-buf/fs Add get_[file|dma_buf]_unless_doomed
Resending since it appears this RFC never got to the dri-devel lkml lists.
In this context, a "doomed" object is an object whose refcount has reached
zero, but that has not yet been freed.
To avoid mutual refcounting vmwgfx need to have a non-refcounted pointer to
a dma-buf in a lookup structure. The pointer is removed in the dma-buf
destructor. To allow lookup-structure private locks we need
get_dma_buf_unless_doomed(). This common refcounting scenario is described
with examples in detail in the kref documentaion.
The solution with local locks is under kref_get_unless_zero().
See also kobject_get_unless_zero() and its commit message.
Since dma-bufs are using the attached file for refcounting,
get_dma_buf_unless_doomed maps directly to a get_file_unless_doomed.
Signed-off-by: Thomas Hellstrom
---
include/linux/dma-buf.h | 16
include/linux/fs.h | 15 +++
2 files changed, 31 insertions(+)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index dfac5ed..6e58144 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -162,6 +162,22 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
get_file(dmabuf->file);
}
+/**
+ * get_dma_buf_unless_doomed - convenience wrapper for get_file_unless_doomed
+ *
+ * @dmabuf:[in]pointer to dma_buf
+ *
+ * Obtain a dma-buf reference from a lookup structure that doesn't refcount
+ * the dma-buf, but synchronizes with its release method to make sure it has
+ * not been freed yet. See for example kref_get_unless_zero documentation.
+ * Returns true if refcounting succeeds, false otherwise.
+ */
+static inline bool __must_check
+get_dma_buf_unless_doomed(struct dma_buf *dmabuf)
+{
+ return get_file_unless_doomed(dmabuf->file);
+}
+
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
void dma_buf_detach(struct dma_buf *dmabuf,
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3f40547..a96c333 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -824,6 +824,21 @@ static inline struct file *get_file(struct file *f)
atomic_long_inc(&f->f_count);
return f;
}
+
+/**
+ * get_file_unless_doomed - convenience wrapper for get_file_unless_doomed
+ * @file: [in]pointer to file
+ *
+ * Obtain a file reference from a lookup structure that doesn't refcount
+ * the file, but synchronizes with its release method to make sure it has
+ * not been freed yet. See for example kref_get_unless_zero documentation.
+ * Returns true if refcounting succeeds, false otherwise.
+ */
+static inline bool __must_check get_file_unless_doomed(struct file *f)
+{
+ return atomic_long_inc_not_zero(&f->f_count) != 0L;
+}
+
#define fput_atomic(x) atomic_long_add_unless(&(x)->f_count, -1, 1)
#define file_count(x) atomic_long_read(&(x)->f_count)
--
1.7.10.4
[Intel-gfx] [PATCH v2 0/7] drm/i915: Baytrail MIPI DSI support Updated
On Sat, Nov 09, 2013 at 11:28:16AM +0100, Daniel Vetter wrote: > On Sat, Nov 09, 2013 at 03:19:01PM +0530, Shobhit Kumar wrote: > > Hi All - > > These patches enhance the current support for MIPI DSI for Baytrail. They > > continue on the sub-encoder design and adds few more dev_ops to handle > > sequence correctly. Major changes are - > > > > 1. DSI Clock calculation based on pixel clock > > 2. Add new dev_ops for better sequencing the enable/disable path > > 3. Parameterized the hardcoded DSI parameters. These also forms building > >block for the generic MIPI driver to come in future based on enhancements > >in VBT. All these parameters are initialized or computed in the > > sub-encoder > >driver. Some of them might look unneccesary for now. > > > > I am also aware of the drm_bridge support now comming in and will in future > > migrate from sub-encoder design to drm_bridge. > > Just a quick aside: Thierry Reding from nvidia is also working on a DSI > design for the tegra driver. Atm he seems to aim for a full-blown DSI bus > based on his drm_panel patches for getting the panel metadata out of an > ARM DT (we'd use VBT instead). Iirc there's no patches anywhere yet, but > maybe Thierry could share a git branch somewhere with the wip stuff? > > Cc'ing Thierry and dri-devel in case a bigger discussion develops. I've been cleaning up the patches and was going to post them today. The implementation really isn't as "full-blown" as you make it sound =), primarily because the DSI panel that I have doesn't support things such as reading out the DDB, so I cannot test most of the functionality that I planned to. However I think introducing a DSI bus type is the right thing and it's been suggested recently that we have too few bus types. Furthermore it seems to be playing out rather nicely with the DRM panel work, so it would be really nice if Intel could test-drive this within their driver to see if it's good enough for their purposes as well. Is everyone working on that subscribed to dri-devel or should I Cc the intel-gfx mailing list (or someone in particular) when posting the patches? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/c945a078/attachment.pgp>
[PATCH 1/2] drm/radeon: activate UVD clocks before sending the destroy msg
Am 30.10.2013 15:29, schrieb Alex Deucher:
> On Wed, Oct 30, 2013 at 7:56 AM, Christian K?nig
> wrote:
>> From: Christian K?nig
>>
>> Make sure the UVD clocks are still active before sending
>> the destroy message, otherwise the hw might hang.
>>
>> Signed-off-by: Christian K?nig
>> Cc: stable at vger.kernel.org
> Both applied!
On which branch? Those two where intended for drm-fixes-3.12, but they
didn't showed up in 3.12.0.
Could you apply them to drm-fixes-3.12 as well? They prevent hw lockups
in case of crashed userspace applications and should also go into older
stable kernels.
Christian.
> Alex
>
>> ---
>> drivers/gpu/drm/radeon/radeon_uvd.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
>> b/drivers/gpu/drm/radeon/radeon_uvd.c
>> index 308eff5..a56dfe4 100644
>> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
>> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
>> @@ -240,6 +240,8 @@ void radeon_uvd_free_handles(struct radeon_device *rdev,
>> struct drm_file *filp)
>> if (handle != 0 && rdev->uvd.filp[i] == filp) {
>> struct radeon_fence *fence;
>>
>> + radeon_uvd_note_usage(rdev);
>> +
>> r = radeon_uvd_get_destroy_msg(rdev,
>> R600_RING_TYPE_UVD_INDEX, handle, &fence);
>> if (r) {
>> --
>> 1.8.1.2
>>
[PATCH 05/12] drm: shmob_drm: Convert to clk_prepare/unprepare
On Sat, Nov 09, 2013 at 01:51:04PM +0100, Laurent Pinchart wrote:
> Hi Dave,
>
> Could you please pick this patch up ?
>
> On Monday 28 October 2013 23:49:22 Laurent Pinchart wrote:
> > Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
> > clk_disable_unprepare() to get ready for the migration to the common
> > clock framework.
> >
> > Cc: David Airlie
> > Cc: dri-devel at lists.freedesktop.org
> > Signed-off-by: Laurent Pinchart > ideasonboard.com>
> > ---
> > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> > b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c index 54bad98..562f9a4 100644
> > --- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> > +++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> > @@ -40,7 +40,7 @@
> > static void shmob_drm_clk_on(struct shmob_drm_device *sdev)
> > {
> > if (sdev->clock)
> > - clk_enable(sdev->clock);
> > + clk_prepare_enable(sdev->clock);
Sorry for jumping in so late, but shouldn't this be split into two
separate calls, clk_prepare() in .probe() and clk_enable() here?
Also note that both clk_prepare() and clk_enable() (and therefore
clk_prepare_enable() as well) can fail, so you should really check
the return values here.
> > #if 0
> > if (sdev->meram_dev && sdev->meram_dev->pdev)
> > pm_runtime_get_sync(&sdev->meram_dev->pdev->dev);
> > @@ -54,7 +54,7 @@ static void shmob_drm_clk_off(struct shmob_drm_device
> > *sdev) pm_runtime_put_sync(&sdev->meram_dev->pdev->dev);
> > #endif
> > if (sdev->clock)
> > - clk_disable(sdev->clock);
> > + clk_disable_unprepare(sdev->clock);
Similarily I'd expect this to be clk_disable() only, with the
clk_unprepare() in .remove(). Or perhaps there's a very good reason to
do both here?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2013/c35318a2/attachment.pgp>
[patch] drm/tegra: small leak on error in tegra_fb_alloc()
On Sat, Nov 09, 2013 at 09:34:06PM -0800, Dan Carpenter wrote:
> If we don't have enough memory for ->planes then we leak "fb".
>
> Signed-off-by: Dan Carpenter
Hi Dan,
Thanks for catching this. Perhaps tweak the commit subject to:
drm/tegra: fix small leak on error in tegra_fb_alloc()
?
One additional comment below.
> diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
> index 490f771..1362d78 100644
> --- a/drivers/gpu/drm/tegra/fb.c
> +++ b/drivers/gpu/drm/tegra/fb.c
> @@ -98,8 +98,10 @@ static struct tegra_fb *tegra_fb_alloc(struct drm_device
> *drm,
> return ERR_PTR(-ENOMEM);
>
> fb->planes = kzalloc(num_planes * sizeof(*planes), GFP_KERNEL);
> - if (!fb->planes)
> - return ERR_PTR(-ENOMEM);
> + if (!fb->planes) {
> + err = -ENOMEM;
> + goto free_fb;
> + }
>
> fb->num_planes = num_planes;
>
> @@ -112,12 +114,17 @@ static struct tegra_fb *tegra_fb_alloc(struct
> drm_device *drm,
> if (err < 0) {
> dev_err(drm->dev, "failed to initialize framebuffer: %d\n",
> err);
> - kfree(fb->planes);
> - kfree(fb);
> - return ERR_PTR(err);
> + goto free_planes;
> }
>
> return fb;
> +
> +free_planes:
> + kfree(fb->planes);
> +free_fb:
> + kfree(fb);
> +
> + return ERR_PTR(err);
> }
I think in this case I'd actually prefer for the kfree(fb) to be
duplicated and not have this error unwind. It's actually shorter
to do it that way in this case.
What I mean is:
if (!fb->planes) {
kfree(fb);
return ERR_PTR(-ENOMEM);
}
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2013/245bd0e4/attachment.pgp>
[patch] drm/tegra: small leak on error in tegra_fb_alloc()
Sure. I will resend. regards, dan carpenter
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #6 from darkbasic --- dpm is enabled of course (because I set radeon.dpm=1 and because 3.13 should have dpm enabled by default afaik). When using UVD with dpm set to auto it switches from the lowest state to the highest lots of times, again and again. *Anyway* when I did run the attached benchmark I forced dpm to "high" before starting. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/f63c9907/attachment.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #7 from darkbasic --- Myke I'm upgrading to 1.14.4 and patching with glx: Add support for the new DRI loader entrypoint: http://cgit.freedesktop.org/xorg/xserver/commit/?id=7ecfab47eb221dbb996ea6c033348b8eceaeb893 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/b8fc3fdf/attachment.html>
[Intel-gfx] [PATCH v2 0/7] drm/i915: Baytrail MIPI DSI support Updated
On 11/11/2013 02:20 PM, Thierry Reding wrote: > On Sat, Nov 09, 2013 at 11:28:16AM +0100, Daniel Vetter wrote: >> On Sat, Nov 09, 2013 at 03:19:01PM +0530, Shobhit Kumar wrote: >>> Hi All - >>> These patches enhance the current support for MIPI DSI for Baytrail. They >>> continue on the sub-encoder design and adds few more dev_ops to handle >>> sequence correctly. Major changes are - >>> >>> 1. DSI Clock calculation based on pixel clock >>> 2. Add new dev_ops for better sequencing the enable/disable path >>> 3. Parameterized the hardcoded DSI parameters. These also forms building >>> block for the generic MIPI driver to come in future based on >>> enhancements >>> in VBT. All these parameters are initialized or computed in the >>> sub-encoder >>> driver. Some of them might look unneccesary for now. >>> >>> I am also aware of the drm_bridge support now comming in and will in >>> future >>> migrate from sub-encoder design to drm_bridge. >> >> Just a quick aside: Thierry Reding from nvidia is also working on a DSI >> design for the tegra driver. Atm he seems to aim for a full-blown DSI bus >> based on his drm_panel patches for getting the panel metadata out of an >> ARM DT (we'd use VBT instead). Iirc there's no patches anywhere yet, but >> maybe Thierry could share a git branch somewhere with the wip stuff? >> >> Cc'ing Thierry and dri-devel in case a bigger discussion develops. > > I've been cleaning up the patches and was going to post them today. The > implementation really isn't as "full-blown" as you make it sound =), > primarily because the DSI panel that I have doesn't support things such > as reading out the DDB, so I cannot test most of the functionality that > I planned to. > > However I think introducing a DSI bus type is the right thing and it's > been suggested recently that we have too few bus types. Furthermore it > seems to be playing out rather nicely with the DRM panel work, so it > would be really nice if Intel could test-drive this within their driver > to see if it's good enough for their purposes as well. Interesting. Would be nice to have a look. > > Is everyone working on that subscribed to dri-devel or should I Cc the > intel-gfx mailing list (or someone in particular) when posting the > patches? > Will keep an eye for your patches in dri-devel. Regards Shobhit
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #8 from darkbasic --- I applied 'glx: Add support for the new DRI loader entrypoint' to xorg-server-1.14.4 and I updated the rest of the graphic stack to latest snapshot from git master: nothing changes. While the test was running I got a "Bus error": Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. qvdpautest 0.5.2 Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz Unknown GPU VDPAU API version : 1 VDPAU implementation : G3DVL VDPAU Driver Shared Library version 1.0 FATAL: get_bits failed : No backend implementation could be loaded.!! MPEG DECODING (1920x1080): 8 frames/s MPEG DECODING (1280x720): 5 frames/s Errore di bus Also I noticed that despite I did "echo high > /sys/devices/pci:00/:00:1c.6/:03:00.0/power_dpm_force_performance_level" I still get lots of power states switching in dmesg. Please see attached dmesg. I also noticed lots of "HDMI: ELD buf size is 0, force 128" and "HDMI: invalid ELD data byte 0" in my dmesg. Maybe something audio related? Monitor is attached using DVI, not HDMI. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/58c7743f/attachment-0001.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #9 from darkbasic --- Created attachment 89017 --> https://bugs.freedesktop.org/attachment.cgi?id=89017&action=edit dmesg dmesg after running qvdpautest -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/99406131/attachment.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #10 from Vadim Girlin --- This is probably related to dpm and gpu clocks - if I run "vblank_mode=0 glxgears" in parallel with the benchmark the results are significantly better for me: w/o gears: MPEG DECODING (1920x1080): 13 frames/s MPEG DECODING (1280x720): 13 frames/s H264 DECODING (1920x1080): 12 frames/s H264 DECODING (1280x720): 13 frames/s with gears: MPEG DECODING (1920x1080): 77 frames/s MPEG DECODING (1280x720): 118 frames/s H264 DECODING (1920x1080): 51 frames/s H264 DECODING (1280x720): 92 frames/s (In reply to comment #6) > *Anyway* when I did run the attached benchmark I forced dpm to "high" before > starting. Setting power_dpm_force_performance_level to "high" doesn't really work for me in this case - AFAICS the driver resets it back to "auto" when the benchmark starts, probably when switching to uvd state. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/eef6f762/attachment.html>
[Bug 71488] New: RadeonSI :Regression: Massive Desktop corruption observed on starting the X server
https://bugs.freedesktop.org/show_bug.cgi?id=71488 Priority: medium Bug ID: 71488 Assignee: dri-devel at lists.freedesktop.org Summary: RadeonSI :Regression: Massive Desktop corruption observed on starting the X server Severity: critical Classification: Unclassified OS: All Reporter: hysvats at gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 89018 --> https://bugs.freedesktop.org/attachment.cgi?id=89018&action=edit xorg.log Driver Stack Details: = 1)Kernel-3.11.0-12-generic 2)drm-2.4.46 3)Mesa-10.0.0-devel(git-6c6f4aa-11thNov) 4)Xorg-server-1.14.3 5)xf86-video-ati- git 6)glamor-0.5.1 7)LLVM-3.3 System Configuration: = Asic : Cape Veede Pro-683F O.S. : Ubuntu-13.10 (64 bit) Observation: Massive Desktop corruption observed on starting the Xserver. Desktop becomes unusable as unable launch any application(Screenshot attached -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/83851b09/attachment.html>
[PATCH v3 0/7] drm/tegra: Add DSI and panel support
Hi, This third version of the series reworks some aspects of DSI and panel support. There is now a DSI bus type, which can be used to instantiate devices that represent DSI peripherals and register controllers as DSI hosts. This is currently somewhat DT-centric, but all hardware that I have access to boots from DT, so I couldn't test any other code anyway and decided to leave that up until someone actually needs it. Patch 1 adds the DSI bus type, which provides functions to instantiate DSI peripherals as devices that can be tied into Linux' driver model. Similarly a DSI host can be created (or embedded within the private structure of a DSI controller driver), which DSI peripherals can talk to. It also exposes a DSI driver, which is essentially a very think wrapper around the standard struct device_driver and allows to easily match DSI drivers to DSI devices (again, only DT-style matching is supported so far). Patch 2 adds the DRM panel framework. Not much has changed since the previous version. Mostly smaller fixes and a way to control the panel brightness, which would usually be tied to a struct backlight_device but doesn't necessarily have to be, so I provided separate accessors that can be used by drivers as they see fit. Patch 3 implements the simple panel driver. The most notable changes since v2 are that the brightness accessors are now implemented if a backlight device is associated with the panel. Furthermore the driver now supports DSI devices using the new DSI infrastructure, which at the same time sharing most of the code with the platform driver for panels not connected via a bus, such as dumb RGB/LVDS panels. An implementation of the panel support for Tegra is provided in patch 4. Due to how DSI devices are instantiated (namely as children of the DSI controller after it has been probed), panels are now hotpluggable at runtime. This sounds less scary than it actually is. It merely means that the code can deal with a panel not being present at probe time (which will never be the case for DSI). Depending on load order the panel might become available only until rather late, and there is code to deal with that as well (by leveraging the hotplug detection mechanism in DRM). I haven't been able to produce this case yet, so that that code path is currently untested, but it should work... Furthermore this patch exposes a "brightness" property to userspace that can be used to control the backlight associated with a panel. The aim is to provide a standard way for userspace to access the correct backlight and not rely on some heuristic to determine the correct sysfs path to use for backlight control. Patch 5 implements a driver for the MIPI pad calibration hardware found on Tegra SoCs. It isn't very relevant to the DSI patches but is included here for the sake of completeness. The DSI host implementation for Tegra SoCs is provided in patch 6. That contains some code to configure the MIPI D-PHY which might be useful in other drivers, but I've kept it in the Tegra driver for now. It is nicely split into separate files so would be easy to move out if needed. Patch 7 contains a work-in-progress implementation of DSI command mode for Tegra. This isn't cleaned up yet and contains various hacks to make it work. Also when run while the controller is in video mode and sending image data, the switch back to video mode after the message has been transferred doesn't work properly and causes the display to no longer work. When run before switching to video mode, however, this seems to work properly. Things like short writes respond with the proper trigger message and such. The goal for this was to be able to identify panels using their device descriptor block (DDB). Unfortunately the display panel that I have reads back only zeros (the framing of the messages looks correct, though), so I somewhat lost interest in making this work correctly. Eventually I could envision turning this into something much bigger. If for instance somebody has access to a panel from which a proper DDB can be read, generic helpers could be written around this and panels probed not via DT but also directly by matching against the supplier and other data found in the DDB. In the meantime I'll try to find out if I can get access to such hardware so that I can finish this up properly. Thierry Thierry Reding (7): drm: Add DSI bus infrastructure drm: Add panel support drm/panel: Add simple panel support drm/tegra: Implement panel support gpu: host1x: Add MIPI pad calibration support drm/tegra: Add DSI support WIP: drm/tegra: Implement DSI transfers .../bindings/gpu/nvidia,tegra20-host1x.txt | 16 + .../bindings/misc/nvidia,tegra114-mipi.txt | 37 + .../devicetree/bindings/panel/auo,b101aw03.txt |7 + .../bindings/panel/chunghwa,claa101wb03.txt|7 + .../bindings/panel/panasonic,vvx10f004b00.txt |7 + .../devicetree/bindings/panel/simple-panel.txt | 21 + drivers/gpu/
[PATCH v3 1/7] drm: Add DSI bus infrastructure
In order to support DSI peripherals, add a DSI bus type that devices and
drivers can be registered with.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/Kconfig | 4 +
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/drm_dsi.c | 306 ++
include/drm/drm_dsi.h | 206 +++
4 files changed, 518 insertions(+)
create mode 100644 drivers/gpu/drm/drm_dsi.c
create mode 100644 include/drm/drm_dsi.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f86427591167..7faefcdd6854 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -20,6 +20,10 @@ menuconfig DRM
details. You should also select and configure AGP
(/dev/agpgart) support if it is available for your platform.
+config DRM_DSI
+ bool
+ depends on DRM
+
config DRM_USB
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index cc08b845f965..eef34abc1e45 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -19,6 +19,7 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
drm-$(CONFIG_PCI) += ati_pcigart.o
+drm-dsi-y := drm_dsi.o
drm-usb-y := drm_usb.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
@@ -31,6 +32,7 @@ obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
CFLAGS_drm_trace_points.o := -I$(src)
obj-$(CONFIG_DRM) += drm.o
+obj-$(CONFIG_DRM_DSI) += drm_dsi.o
obj-$(CONFIG_DRM_USB) += drm_usb.o
obj-$(CONFIG_DRM_TTM) += ttm/
obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/drm_dsi.c b/drivers/gpu/drm/drm_dsi.c
new file mode 100644
index ..bead3cc0e9e3
--- /dev/null
+++ b/drivers/gpu/drm/drm_dsi.c
@@ -0,0 +1,306 @@
+/*
+ * Copyright (C) 2013 NVIDIA Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static int dsi_device_match(struct device *dev, struct device_driver *drv)
+{
+ if (of_driver_match_device(dev, drv))
+ return 1;
+
+ return 0;
+}
+
+static struct bus_type dsi_bus_type = {
+ .name = "dsi",
+ .match = dsi_device_match,
+};
+
+static void dsi_device_release(struct device *dev)
+{
+ struct dsi_device *dsi = to_dsi_device(dev);
+
+ of_node_put(dsi->dev.of_node);
+ dsi_host_put(dsi->host);
+ kfree(dsi);
+}
+
+static struct dsi_device *dsi_device_alloc(struct dsi_host *host)
+{
+ struct dsi_device *dsi;
+
+ if (!dsi_host_get(host))
+ return ERR_PTR(-EINVAL);
+
+ dsi = kzalloc(sizeof(*dsi), GFP_KERNEL);
+ if (!dsi) {
+ dsi_host_put(host);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ dsi->host = dsi_host_get(host);
+
+ dsi->dev.parent = host->dev;
+ dsi->dev.bus = &dsi_bus_type;
+ dsi->dev.release = dsi_device_release;
+
+ device_initialize(&dsi->dev);
+
+ return dsi;
+}
+
+static int dsi_device_add(struct dsi_device *dsi)
+{
+ struct dsi_host *host = dsi->host;
+ int err;
+
+ dev_set_name(&dsi->dev, "%s.%u", dev_name(host->dev), dsi->channel);
+
+ err = device_add(&dsi->dev);
+ if (err < 0) {
+ dsi_device_put(dsi);
+ return err;
+ }
+
+ return 0;
+}
+
+static int of_dsi_host_register(struct dsi_host *host)
+{
+ if (!host->dev->of_node)
+ return -ENODEV;
+
+ return 0;
+}
+
+static int of_dsi_register_devices(struct dsi_host *host)
+{
+ struct device_node *np;
+
+ if (!host->dev->of_node)
+ return -ENODEV;
+
+ for_each_available_child_of_node(host->dev->of_node, np) {
+ struct dsi_device *dsi;
+ u32 value;
+ int err;
+
+
[PATCH v3 3/7] drm/panel: Add simple panel support
Add a driver for simple panels. Such panels can have a regulator that
provides the supply voltage and a separate GPIO to enable the panel.
Optionally the panels can have a backlight associated with them so it
can be enabled or disabled according to the panel's power management
mode.
Support is added for three panels: An AU Optronics 10.1" WSVGA, a
Chunghwa Picture Tubes 10.1" WXGA and a Panasonic 10.1 WUXGA TFT LCD
panel.
Signed-off-by: Thierry Reding
---
Changes in v3:
- propagate errors from .enable() and .disable()
- implement backlight brightness accessors
- allow building as a module
- add DSI device support
- fixup license string
Changes in v2:
- fixup pixel clock for Panasonic VVX10F004B00
.../devicetree/bindings/panel/auo,b101aw03.txt | 7 +
.../bindings/panel/chunghwa,claa101wb03.txt| 7 +
.../bindings/panel/panasonic,vvx10f004b00.txt | 7 +
.../devicetree/bindings/panel/simple-panel.txt | 21 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/panel/Kconfig | 15 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-simple.c | 467 +
8 files changed, 526 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/auo,b101aw03.txt
create mode 100644
Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
create mode 100644
Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
create mode 100644 Documentation/devicetree/bindings/panel/simple-panel.txt
create mode 100644 drivers/gpu/drm/panel/Makefile
create mode 100644 drivers/gpu/drm/panel/panel-simple.c
diff --git a/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
new file mode 100644
index ..72e088a4fb3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 10.1" WSVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,b101aw03"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
new file mode 100644
index ..0ab2c05a4c22
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
@@ -0,0 +1,7 @@
+Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "chunghwa,claa101wb03"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
new file mode 100644
index ..d328b0341bf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
@@ -0,0 +1,7 @@
+Panasonic Corporation 10.1" WUXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "panasonic,vvx10f004b00"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/panel/simple-panel.txt
b/Documentation/devicetree/bindings/panel/simple-panel.txt
new file mode 100644
index ..1341bbf4aa3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/simple-panel.txt
@@ -0,0 +1,21 @@
+Simple display panel
+
+Required properties:
+- power-supply: regulator to provide the supply voltage
+
+Optional properties:
+- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+- enable-gpios: GPIO pin to enable or disable the panel
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+ panel: panel {
+ compatible = "cptt,claa101wb01";
+ ddc-i2c-bus = <&panelddc>;
+
+ power-supply = <&vdd_pnl_reg>;
+ enable-gpios = <&gpio 90 0>;
+
+ backlight = <&backlight>;
+ };
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f521f4a71fd2..38acfa0471da 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -62,3 +62,4 @@ obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-$(CONFIG_DRM_TEGRA) += tegra/
obj-y += i2c/
+obj-y += panel/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d1db4ef626fd..4f40d198f93d 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -3,3 +3,18 @@ config DRM_PANEL
depends on DRM
help
Panel registration and lookup framework.
+
+menu "Display Panels"
+ depends on DRM_PANEL
+
+config DRM_PANEL_SIMPLE
+ tristate "support for simple panels"
+ depends on DRM && DRM_PANEL
+ d
[PATCH v3 4/7] drm/tegra: Implement panel support
Use the DRM panel framework to attach a panel to an output. If the panel
attached to a connector supports supports the backlight brightness
accessors, a property will be available to allow the brightness to be
modified from userspace.
Signed-off-by: Thierry Reding
---
Changes in v3:
- allow panels to be hotplugged
- add brightness property
.../bindings/gpu/nvidia,tegra20-host1x.txt | 2 +
drivers/gpu/drm/tegra/Kconfig | 1 +
drivers/gpu/drm/tegra/drm.h| 3 +
drivers/gpu/drm/tegra/output.c | 90 +-
4 files changed, 92 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
index b4fa934ae3a2..24f026e20154 100644
--- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
@@ -67,6 +67,7 @@ of the following host1x client modules:
- nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- nvidia,edid: supplies a binary EDID blob
+ - nvidia,panel: phandle of a display panel
- hdmi: High Definition Multimedia Interface
@@ -81,6 +82,7 @@ of the following host1x client modules:
- nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- nvidia,edid: supplies a binary EDID blob
+ - nvidia,panel: phandle of a display panel
- tvo: TV encoder output
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 8961ba6a34b8..da34dd1b9ddb 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -5,6 +5,7 @@ config DRM_TEGRA
select TEGRA_HOST1X
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
+ select DRM_PANEL
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 7da0b923131f..5aa7f2065c02 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -183,6 +183,7 @@ struct tegra_output {
const struct tegra_output_ops *ops;
enum tegra_output_type type;
+ struct drm_panel *panel;
struct i2c_adapter *ddc;
const struct edid *edid;
unsigned int hpd_irq;
@@ -190,6 +191,8 @@ struct tegra_output {
struct drm_encoder encoder;
struct drm_connector connector;
+
+ struct drm_property *brightness;
};
static inline struct tegra_output *encoder_to_output(struct drm_encoder *e)
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 2cb0065e0578..c5e0a2a97bc8 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -9,6 +9,7 @@
#include
+#include
#include "drm.h"
static int tegra_connector_get_modes(struct drm_connector *connector)
@@ -17,6 +18,9 @@ static int tegra_connector_get_modes(struct drm_connector
*connector)
struct edid *edid = NULL;
int err = 0;
+ if (output->panel)
+ return output->panel->funcs->get_modes(output->panel);
+
if (output->edid)
edid = kmemdup(output->edid, sizeof(*edid), GFP_KERNEL);
else if (output->ddc)
@@ -60,6 +64,39 @@ static const struct drm_connector_helper_funcs
connector_helper_funcs = {
.best_encoder = tegra_connector_best_encoder,
};
+static void tegra_output_add_panel_properties(struct tegra_output *output)
+{
+ struct drm_device *drm = output->connector.dev;
+ uint64_t min, max, value;
+ int err;
+
+ if (output->brightness)
+ return;
+
+ err = drm_panel_get_brightness_range(output->panel, &min, &max);
+ if (err < 0)
+ return;
+
+ err = drm_panel_get_brightness(output->panel, &value);
+ if (err < 0)
+ return;
+
+ output->brightness = drm_property_create_range(drm, 0, "brightness",
+ min, max);
+ drm_object_attach_property(&output->connector.base, output->brightness,
+ value);
+}
+
+static void tegra_output_remove_panel_properties(struct tegra_output *output)
+{
+ struct drm_device *drm = output->connector.dev;
+
+ if (output->brightness) {
+ drm_property_destroy(drm, output->brightness);
+ output->brightness = NULL;
+ }
+}
+
static enum drm_connector_status
tegra_connector_detect(struct drm_connector *connector, bool force)
{
@@ -72,6 +109,14 @@ tegra_connector_detect(struct drm_connector *connector,
bool force)
else
status = connector_status_connected;
} else {
+ if (!output->panel) {
+ t
[PATCH v3 7/7] WIP: drm/tegra: Implement DSI transfers
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dsi.c | 147
1 file changed, 147 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index effd0b5a5554..a100719b3d0c 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -774,6 +774,131 @@ static void tegra_dsi_initialize(struct tegra_dsi *dsi)
tegra_dsi_writel(dsi, 0, DSI_GANGED_MODE_SIZE);
}
+static int tegra_dsi_set_lp_clk(struct tegra_dsi *dsi, unsigned long pclk)
+{
+ unsigned long bclk, timeout, value;
+ struct clk *clk, *parent, *base;
+ unsigned int mul, div;
+ int err;
+
+ err = tegra_dsi_get_muldiv(dsi->format, &mul, &div);
+ if (err < 0)
+ return err;
+
+ bclk = pclk * 8;
+
+ clk = clk_get_parent(dsi->clk);
+ parent = clk_get_parent(clk);
+ base = clk_get_parent(parent);
+
+ err = clk_set_rate(base, pclk * 2);
+ if (err < 0)
+ return err;
+
+ /* one frame high-speed transmission timeout */
+ timeout = bclk / 512;
+ value = DSI_TIMEOUT_LRX(0x2000) | DSI_TIMEOUT_HTX(timeout);
+ tegra_dsi_writel(dsi, value, DSI_TIMEOUT_0);
+
+ /* 2 ms peripheral timeout for panel */
+ timeout = 2 * bclk / 512 * 1000;
+ value = DSI_TIMEOUT_PR(timeout) | DSI_TIMEOUT_TA(0x2000);
+ tegra_dsi_writel(dsi, value, DSI_TIMEOUT_1);
+
+ value = DSI_TALLY_TA(0) | DSI_TALLY_LRX(0) | DSI_TALLY_HTX(0);
+ tegra_dsi_writel(dsi, value, DSI_TO_TALLY);
+
+ return 0;
+}
+
+static ssize_t tegra_dsi_host_transfer(struct dsi_host *host,
+ struct dsi_msg *msg)
+{
+ struct tegra_dsi *dsi = dsi_host_to_tegra(host);
+ unsigned long value, timeout;
+ unsigned int count = 0, i;
+ const u8 *tx = msg->tx;
+ int err;
+
+ dev_info(dsi->dev, "> %s(host=%p, msg=%p)\n", __func__, host, msg);
+
+ /* XXX */
+ drm_panel_enable(dsi->output.panel);
+
+ value = tegra_dsi_readl(dsi, DSI_POWER_CONTROL);
+ value |= DSI_POWER_CONTROL_ENABLE;
+ tegra_dsi_writel(dsi, value, DSI_POWER_CONTROL);
+ usleep_range(300, 1000);
+
+ err = tegra_dsi_set_lp_clk(dsi, 1000);
+ if (err < 0) {
+ dev_err(dsi->dev, "failed to setup low-power clock: %d\n", err);
+ return err;
+ }
+
+ tegra_dsi_writel(dsi, DSI_HOST_FIFO_DEPTH, DSI_MAX_THRESHOLD);
+
+ value = tegra_dsi_readl(dsi, DSI_CONTROL);
+ value = 0x3031;
+ tegra_dsi_writel(dsi, value, DSI_CONTROL);
+
+ value = tegra_dsi_readl(dsi, DSI_HOST_CONTROL);
+ value = 0x00102003;
+ tegra_dsi_writel(dsi, value, DSI_HOST_CONTROL);
+
+ if (msg->rx && msg->rx_len > 0) {
+ value = tegra_dsi_readl(dsi, DSI_HOST_CONTROL);
+ value |= DSI_HOST_CONTROL_BTA;
+ tegra_dsi_writel(dsi, value, DSI_HOST_CONTROL);
+ }
+
+ value = ((msg->channel & 0x3) << 6) | (msg->type & 0x3f);
+
+ value |= tx[0] << 8;
+ value |= tx[1] << 16;
+
+ tegra_dsi_writel(dsi, value, DSI_WR_DATA);
+
+ tegra_dsi_writel(dsi, 0x0002, DSI_TRIGGER);
+
+ timeout = jiffies + msecs_to_jiffies(250);
+
+ while (true) {
+ value = tegra_dsi_readl(dsi, DSI_TRIGGER);
+ if ((value & 0x0002) == 0)
+ break;
+
+ if (time_after(jiffies, timeout))
+ return -ETIMEDOUT;
+
+ usleep_range(25, 100);
+ }
+
+ timeout = jiffies + msecs_to_jiffies(250);
+
+ while (true) {
+ usleep_range(1000, 2000);
+
+ value = tegra_dsi_readl(dsi, DSI_STATUS);
+ count = value & 0x1f;
+
+ if (count > 0)
+ break;
+
+ if (time_after(jiffies, timeout))
+ return -ETIMEDOUT;
+ }
+
+ for (i = 0; i < count; i++)
+ tegra_dsi_readl(dsi, DSI_RD_DATA);
+
+ /* XXX */
+ drm_panel_disable(dsi->output.panel);
+
+ dev_info(dsi->dev, "< %s()\n", __func__);
+ return 0;
+}
+
static int tegra_dsi_host_attach(struct dsi_host *host,
struct dsi_device *device)
{
@@ -784,6 +909,27 @@ static int tegra_dsi_host_attach(struct dsi_host *host,
if (output->panel) {
if (output->connector.dev)
drm_helper_hpd_irq_event(output->connector.dev);
+
+ if (0) {
+ struct dsi_msg msg;
+ u8 tx[2], rx[2];
+ ssize_t err;
+
+ rx[0] = rx[1] = 0;
+ tx[0] = tx[1] = 0;
+
+ memset(&msg, 0, sizeof(msg));
+ msg.channel = 0;
+ msg.type = 0x05;
+ msg.tx_len = 2;
+
[PATCH v3 5/7] gpu: host1x: Add MIPI pad calibration support
This driver adds support to perform calibration of the MIPI pads for CSI
and DSI.
Signed-off-by: Thierry Reding
---
Changes in v3:
- rename calibrate and #calibrate-cells properties to nvidia,mipi-calibrate
and #nvidia,mipi-calibrate-cells, respectively
- split API into tegra_mipi_{request,free,calibrate}() to allow DT to be
parsed only once and to better support deferred probing
.../bindings/misc/nvidia,tegra114-mipi.txt | 37 +++
drivers/gpu/host1x/Makefile| 1 +
drivers/gpu/host1x/dev.c | 17 +-
drivers/gpu/host1x/dev.h | 2 +
drivers/gpu/host1x/mipi.c | 272 +
include/linux/host1x.h | 6 +
6 files changed, 331 insertions(+), 4 deletions(-)
create mode 100644
Documentation/devicetree/bindings/misc/nvidia,tegra114-mipi.txt
create mode 100644 drivers/gpu/host1x/mipi.c
diff --git a/Documentation/devicetree/bindings/misc/nvidia,tegra114-mipi.txt
b/Documentation/devicetree/bindings/misc/nvidia,tegra114-mipi.txt
new file mode 100644
index ..beb75ec7f6fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/nvidia,tegra114-mipi.txt
@@ -0,0 +1,37 @@
+NVIDIA Tegra MIPI pad calibration controller
+
+Required properties:
+- compatible: "nvidia,tegra-mipi"
+- reg: Physical base address and length of the controller's registers.
+- clocks: The clock consumed by the controller.
+- #nvidia,mipi-calibrate-cells: Should be 1. The cell is a bitmask of the pads
+ that need to be calibrated for a given device.
+
+User nodes need to contain an nvidia,mipi-calibrate property that has a
+phandle to refer to the calibration controller node and a bitmask of the pads
+that need to be calibrated.
+
+Example:
+
+ mipi: mipi at 700e3000 {
+ compatible = "nvidia,tegra114-mipi";
+ reg = <0x700e3000 0x100>;
+ clocks = <&tegra_car TEGRA114_CLK_MIPI_CAL>;
+ #nvidia,mipi-calibrate-cells = <1>;
+ };
+
+ ...
+
+ host1x at 5000 {
+ ...
+
+ dsi at 5430 {
+ ...
+
+ nvidia,mipi-calibrate = <&mipi 0x060>;
+
+ ...
+ };
+
+ ...
+ };
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index afa1e9e4e512..de305c2d510e 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -7,6 +7,7 @@ host1x-y = \
channel.o \
job.o \
debug.o \
+ mipi.o \
hw/host1x01.o \
hw/host1x02.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 80da003d63de..646a333b069a 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -210,17 +210,26 @@ static int __init tegra_host1x_init(void)
return err;
err = platform_driver_register(&tegra_host1x_driver);
- if (err < 0) {
- host1x_bus_exit();
- return err;
- }
+ if (err < 0)
+ goto unregister_bus;
+
+ err = platform_driver_register(&tegra_mipi_driver);
+ if (err < 0)
+ goto unregister_host1x;
return 0;
+
+unregister_host1x:
+ platform_driver_unregister(&tegra_host1x_driver);
+unregister_bus:
+ host1x_bus_exit();
+ return err;
}
module_init(tegra_host1x_init);
static void __exit tegra_host1x_exit(void)
{
+ platform_driver_unregister(&tegra_mipi_driver);
platform_driver_unregister(&tegra_host1x_driver);
host1x_bus_exit();
}
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index a61a976e7a42..0b6e8e9629c5 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -306,4 +306,6 @@ static inline void host1x_hw_show_mlocks(struct host1x
*host, struct output *o)
host->debug_op->show_mlocks(host, o);
}
+extern struct platform_driver tegra_mipi_driver;
+
#endif
diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
new file mode 100644
index ..78a74d69c8ee
--- /dev/null
+++ b/drivers/gpu/host1x/mipi.c
@@ -0,0 +1,272 @@
+/*
+ * Copyright (C) 2013 NVIDIA Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD
[PATCH v3 6/7] drm/tegra: Add DSI support
This commit adds support for both DSI outputs found on Tegra. Only very
minimal functionality is implemented, so advanced features like ganged
mode won't work.
Due to the lack of other test hardware, some sections of the driver are
hardcoded to work with Dalmore.
Signed-off-by: Thierry Reding
---
Changes in v3:
- select DRM_DSI symbol to pull in DSI bus infrastructure
- implement DSI host .attach() and .detach() callbacks
- move register definitions to separate file
- move MIPI D-PHY code to separate file
- add support for low-power clocks
Changes in v2:
- cope with modes that have a 0 Hz refresh rate
.../bindings/gpu/nvidia,tegra20-host1x.txt | 14 +
drivers/gpu/drm/tegra/Kconfig | 1 +
drivers/gpu/drm/tegra/Makefile | 2 +
drivers/gpu/drm/tegra/dc.h | 2 +
drivers/gpu/drm/tegra/drm.c| 10 +-
drivers/gpu/drm/tegra/drm.h| 2 +
drivers/gpu/drm/tegra/dsi.c| 940 +
drivers/gpu/drm/tegra/dsi.h| 134 +++
drivers/gpu/drm/tegra/mipi-phy.c | 137 +++
drivers/gpu/drm/tegra/mipi-phy.h | 65 ++
drivers/gpu/drm/tegra/output.c | 5 +
11 files changed, 1311 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tegra/dsi.c
create mode 100644 drivers/gpu/drm/tegra/dsi.h
create mode 100644 drivers/gpu/drm/tegra/mipi-phy.c
create mode 100644 drivers/gpu/drm/tegra/mipi-phy.h
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
index 24f026e20154..3f14e81c55bd 100644
--- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
@@ -96,6 +96,20 @@ of the following host1x client modules:
Required properties:
- compatible: "nvidia,tegra-dsi"
- reg: Physical base address and length of the controller's registers.
+ - clocks: Should contain phandle and clock specifiers for two clocks:
+the DSI controller clock and the parent clock of the controller.
+ - clock-names: A list of strings containing the name for each clock in
+the clocks property. Must contain the following two entries:
+- "dsi": the DSI controller clock
+- "parent": parent of the DSI controller clock
+ - calibrate: Should contain a phandle and a specifier specifying which
+pads are used by this DSI output and need to be calibrated.
+
+ Optional properties:
+ - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+ - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
+ - nvidia,edid: supplies a binary EDID blob
+ - nvidia,panel: phandle of a display panel
Example:
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index da34dd1b9ddb..032e2c2b21ef 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -3,6 +3,7 @@ config DRM_TEGRA
depends on ARCH_TEGRA || ARCH_MULTIPLATFORM
depends on DRM
select TEGRA_HOST1X
+ select DRM_DSI
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
select DRM_PANEL
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index edc76abd58bb..8d220afbd85f 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -9,6 +9,8 @@ tegra-drm-y := \
output.o \
rgb.o \
hdmi.o \
+ mipi-phy.o \
+ dsi.o \
gr2d.o \
gr3d.o
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index 91bbda291470..788627a060d7 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -28,6 +28,7 @@
#define DISP_CTRL_MODE_STOP (0 << 5)
#define DISP_CTRL_MODE_C_DISPLAY (1 << 5)
#define DISP_CTRL_MODE_NC_DISPLAY (2 << 5)
+#define DISP_CTRL_MODE_MASK (3 << 5)
#define DC_CMD_SIGNAL_RAISE0x033
#define DC_CMD_DISPLAY_POWER_CONTROL 0x036
#define PW0_ENABLE (1 << 0)
@@ -116,6 +117,7 @@
#define DC_DISP_DISP_WIN_OPTIONS 0x402
#define HDMI_ENABLE (1 << 30)
+#define DSI_ENABLE (1 << 29)
#define DC_DISP_DISP_MEM_HIGH_PRIORITY 0x403
#define CURSOR_THRESHOLD(x) (((x) & 0x03) << 24)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 28e178137718..ed86f2b3c0d7 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -649,6 +649,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra30-hdmi", },
{ .compatible = "nvidia,tegra30-gr2d", },
{ .compatible = "nvidia,tegra30-gr3d", },
+ { .compatible = "nvidia,tegra114-dsi", },
{ .compatible = "nvidia,tegra114-hdmi", },
{ .compatible = "nvidia,tegra114-gr3d", },
{ /* sentinel */ }
@@ -673,10 +674,14 @@ static int
[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server
https://bugs.freedesktop.org/show_bug.cgi?id=71488 --- Comment #1 from samit vats --- Created attachment 89019 --> https://bugs.freedesktop.org/attachment.cgi?id=89019&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/3ee0b098/attachment.html>
[PATCH v3 2/7] drm: Add panel support
Add a very simple framework to register and lookup panels. Panel drivers
can initialize a DRM panel and register it with the framework, allowing
them to be retrieved and used by display drivers. Currently only support
for DPMS and obtaining panel modes is provided. However it should be
sufficient to enable a large number of panels. The framework should also
be easily extensible to support more sophisticated kinds of panels such
as DSI.
The framework hasn't been tied into the DRM core, even though it should
be easily possible to do so if that's what we want. In the current
implementation, display drivers can simple make use of it to retrieve a
panel, obtain its modes and control its DPMS mode.
Note that this is currently only tested on systems that boot from a
device tree. No glue code has been written yet for systems that use
platform data, but it should be easy to add.
Signed-off-by: Thierry Reding
---
Changes in v3:
- depend on DRM (reported by Randy Dunlap)
- propagate errors from .enable() and .disable()
- add backlight brightness accessors
- hide DRM_PANEL Kconfig symbol
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_panel.c | 100
drivers/gpu/drm/panel/Kconfig | 5 ++
include/drm/drm_panel.h | 114 ++
5 files changed, 222 insertions(+)
create mode 100644 drivers/gpu/drm/drm_panel.c
create mode 100644 drivers/gpu/drm/panel/Kconfig
create mode 100644 include/drm/drm_panel.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 7faefcdd6854..28407af6e642 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -195,3 +195,5 @@ source "drivers/gpu/drm/qxl/Kconfig"
source "drivers/gpu/drm/msm/Kconfig"
source "drivers/gpu/drm/tegra/Kconfig"
+
+source "drivers/gpu/drm/panel/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index eef34abc1e45..f521f4a71fd2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,6 +18,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o
drm_cache.o \
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
drm-$(CONFIG_PCI) += ati_pcigart.o
+drm-$(CONFIG_DRM_PANEL) += drm_panel.o
drm-dsi-y := drm_dsi.o
drm-usb-y := drm_usb.o
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
new file mode 100644
index ..2ef988e037b7
--- /dev/null
+++ b/drivers/gpu/drm/drm_panel.c
@@ -0,0 +1,100 @@
+/*
+ * Copyright (C) 2013, NVIDIA Corporation. All rights reserved.
+ *
+ * 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, sub license,
+ * 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 NON-INFRINGEMENT. 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.
+ */
+
+#include
+#include
+
+#include
+#include
+
+static DEFINE_MUTEX(panel_lock);
+static LIST_HEAD(panel_list);
+
+void drm_panel_init(struct drm_panel *panel)
+{
+ INIT_LIST_HEAD(&panel->list);
+}
+EXPORT_SYMBOL(drm_panel_init);
+
+int drm_panel_add(struct drm_panel *panel)
+{
+ mutex_lock(&panel_lock);
+ list_add_tail(&panel->list, &panel_list);
+ mutex_unlock(&panel_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_panel_add);
+
+void drm_panel_remove(struct drm_panel *panel)
+{
+ mutex_lock(&panel_lock);
+ list_del_init(&panel->list);
+ mutex_unlock(&panel_lock);
+}
+EXPORT_SYMBOL(drm_panel_remove);
+
+int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
+{
+ if (panel->connector)
+ return -EBUSY;
+
+ panel->connector = connector;
+ panel->drm = connector->dev;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_panel_attach);
+
+int drm_panel_detach(struct drm_panel *panel)
+{
+ panel->connector = NULL;
+ panel->drm = NULL;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_panel_detach);
+
+#ifdef CONFIG_OF
+struct drm_panel *of_drm_find_panel(struct device_node *np)
+{
+ struct drm_panel *panel;
+
+
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #11 from Grigori Goronzy --- (In reply to comment #5) > (In reply to comment #4) > > FATAL: get_bits failed : No backend implementation could be loaded.!! > > > > There's some problem with your build. > > That message is normal, just a function we haven't implemented yet. > As far as I can see it's actually illegal API usage in qvdpautest. It's trying to read from uninitialized video surfaces, which is not guaranteed to work. Swapping around the order of tests so that it does the PutBits test first fixes it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/f4256791/attachment.html>
[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server
https://bugs.freedesktop.org/show_bug.cgi?id=71488 samit vats changed: What|Removed |Added Priority|medium |high -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131111/54fc1099/attachment.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #12 from Christian K?nig --- (In reply to comment #8) > Also I noticed that despite I did "echo high > > /sys/devices/pci:00/:00:1c.6/:03:00.0/ > power_dpm_force_performance_level" I still get lots of power states > switching in dmesg. As Vadim correctly noted forcing any power state doesn't work here, because we need to switch to the UVD power state anyway. BTW: Is this a regression? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/d250c16b/attachment.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #13 from Christian K?nig --- (In reply to comment #10) > This is probably related to dpm and gpu clocks - if I run "vblank_mode=0 > glxgears" in parallel with the benchmark the results are significantly > better for me: > > w/o gears: > > MPEG DECODING (1920x1080): 13 frames/s > MPEG DECODING (1280x720): 13 frames/s > H264 DECODING (1920x1080): 12 frames/s > H264 DECODING (1280x720): 13 frames/s > > with gears: > > MPEG DECODING (1920x1080): 77 frames/s > MPEG DECODING (1280x720): 118 frames/s > H264 DECODING (1920x1080): 51 frames/s > H264 DECODING (1280x720): 92 frames/s ^^ very valuable comment, thx. So do I get that right that generation 3D load affects UVD decoding performance here? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/96c36bc3/attachment-0001.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #14 from Christian K?nig --- (In reply to comment #11) > (In reply to comment #5) > > (In reply to comment #4) > > > FATAL: get_bits failed : No backend implementation could be loaded.!! > > > > > > There's some problem with your build. > > > > That message is normal, just a function we haven't implemented yet. > > > > As far as I can see it's actually illegal API usage in qvdpautest. It's > trying to read from uninitialized video surfaces, which is not guaranteed to > work. Swapping around the order of tests so that it does the PutBits test > first fixes it. Thx for the into. qvdpautest is badly written in many aspects (takes to many time, is inaccurate etc...). Would be nice if somebody could sit down and either write something new from scratch or start to improve it. Some rather stupid command-line tool with a couple of options for testing different decoding profile and output methods should be perfectly sufficient. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/f915f452/attachment.html>
[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server
https://bugs.freedesktop.org/show_bug.cgi?id=71488 --- Comment #2 from samit vats --- Created attachment 89021 --> https://bugs.freedesktop.org/attachment.cgi?id=89021&action=edit screenshot -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/535ea9ef/attachment.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #15 from darkbasic --- Here is mine while running glxgears: MPEG DECODING (1920x1080): 77 frames/s MPEG DECODING (1280x720): 117 frames/s H264 DECODING (1920x1080): 16 frames/s H264 DECODING (1280x720): 91 frames/s Profile unsupported. MPEG4 DECODING (1920x1080): 72 frames/s No, it isn't a reggression: it never worked for me. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/41b83322/attachment.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #16 from Vadim Girlin --- (In reply to comment #13) > So do I get that right that generation 3D load affects UVD decoding > performance here? Yes, I think the explanation of the difference in benchmark results is that glxgears triggers higher gpu power level, probably the benchmark alone simply doesn't provide enough load for that or maybe something is wrong with dpm logic. Here is what I see while running the benchmark: w/o gears: power level 0sclk: 45000 mclk: 12 vddc: 900 vddci: 975 pcie gen: 2 with gears: power level 2sclk: 10 mclk: 12 vddc: 1219 vddci: 975 pcie gen: 2 uvd clocks are the same in both cases: uvdvclk: 72000 dclk: 56000 when the system is completely idle I see the following values: uvdvclk: 0 dclk: 0 power level 0sclk: 3 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/9947fc49/attachment.html>
[PATCH 05/12] drm: shmob_drm: Convert to clk_prepare/unprepare
Hi Thierry,
On Monday 11 November 2013 09:55:24 Thierry Reding wrote:
> On Sat, Nov 09, 2013 at 01:51:04PM +0100, Laurent Pinchart wrote:
> > Hi Dave,
> >
> > Could you please pick this patch up ?
> >
> > On Monday 28 October 2013 23:49:22 Laurent Pinchart wrote:
> > > Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
> > > clk_disable_unprepare() to get ready for the migration to the common
> > > clock framework.
> > >
> > > Cc: David Airlie
> > > Cc: dri-devel at lists.freedesktop.org
> > > Signed-off-by: Laurent Pinchart
> > >
> > > ---
> > >
> > > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> > > b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c index 54bad98..562f9a4
> > > 100644
> > > --- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> > > +++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> > > @@ -40,7 +40,7 @@
> > > static void shmob_drm_clk_on(struct shmob_drm_device *sdev)
> > > {
> > > if (sdev->clock)
> > > - clk_enable(sdev->clock);
> > > + clk_prepare_enable(sdev->clock);
>
> Sorry for jumping in so late, but shouldn't this be split into two
> separate calls, clk_prepare() in .probe() and clk_enable() here?
The clock prepare and enable operations are split to allow clock
implementations to sleep. Clocks should be kept disable whenever possible, the
clk_enable() and clk_disable() calls should be as close as possible to the
time range during which the clock needs to be enabled. This means that those
calls might happen in a context where sleeping isn't allowed. If a clock
implementation needs to sleep to enable the clock (by performing an I2C access
for instance), that operation should be performed at prepare time.
>From a clock user point of view, both clk_prepare() and clk_enable() should be
called as late as possible. If clk_enable() needs to be called in an atomic
context clk_prepare() must be called earlier, in a non-atomic context().
Otherwise there'e no point in splitting the two calls.
> Also note that both clk_prepare() and clk_enable() (and therefore
> clk_prepare_enable() as well) can fail, so you should really check
> the return values here.
Yes, that's a good point. I'd like to fix that in a separate patch in order to
avoid delaying this one.
> > > #if 0
> > > if (sdev->meram_dev && sdev->meram_dev->pdev)
> > > pm_runtime_get_sync(&sdev->meram_dev->pdev->dev);
> > > @@ -54,7 +54,7 @@ static void shmob_drm_clk_off(struct shmob_drm_device
> > > *sdev)
> > > pm_runtime_put_sync(&sdev->meram_dev->pdev->dev);
> > > #endif
> > > if (sdev->clock)
> > > - clk_disable(sdev->clock);
> > > + clk_disable_unprepare(sdev->clock);
>
> Similarily I'd expect this to be clk_disable() only, with the
> clk_unprepare() in .remove(). Or perhaps there's a very good reason to
> do both here?
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2013/5974b5a4/attachment.pgp>
[Bug 64781] RV630 bad video playback (too fast) when HDMI audio output is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=64781 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 64781] RV630 bad video playback (too fast) when HDMI audio output is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=64781 --- Comment #2 from Alex Deucher --- What application are you using to play back the movies? Do it work properly with different apps? What API (Xv, X11, vdpau, etc.) are you using to play back the movie? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 64721] Radeon HD6450 fails on all distro's out of box.
https://bugzilla.kernel.org/show_bug.cgi?id=64721 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. What kernels have you tested with? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/2] drm/radeon: activate UVD clocks before sending the destroy msg
On Mon, Nov 11, 2013 at 3:54 AM, Christian K?nig
wrote:
> Am 30.10.2013 15:29, schrieb Alex Deucher:
>>
>> On Wed, Oct 30, 2013 at 7:56 AM, Christian K?nig
>> wrote:
>>>
>>> From: Christian K?nig
>>>
>>> Make sure the UVD clocks are still active before sending
>>> the destroy message, otherwise the hw might hang.
>>>
>>> Signed-off-by: Christian K?nig
>>> Cc: stable at vger.kernel.org
>>
>> Both applied!
>
>
> On which branch? Those two where intended for drm-fixes-3.12, but they
> didn't showed up in 3.12.0.
>
> Could you apply them to drm-fixes-3.12 as well? They prevent hw lockups in
> case of crashed userspace applications and should also go into older stable
> kernels.
It was too late for 3.12. They'll be in 3.13 and I cc'ed stable:
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=c154a76311293f9671439286834aa325b7ef59fe
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=727ddc84a1373bf06b2fa261f44e38fb0faf5340
I can push to my fdo drm-fixes-3.12 branch too if you want.
Alex
>
> Christian.
>
>> Alex
>>
>>> ---
>>> drivers/gpu/drm/radeon/radeon_uvd.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
>>> b/drivers/gpu/drm/radeon/radeon_uvd.c
>>> index 308eff5..a56dfe4 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
>>> @@ -240,6 +240,8 @@ void radeon_uvd_free_handles(struct radeon_device
>>> *rdev, struct drm_file *filp)
>>> if (handle != 0 && rdev->uvd.filp[i] == filp) {
>>> struct radeon_fence *fence;
>>>
>>> + radeon_uvd_note_usage(rdev);
>>> +
>>> r = radeon_uvd_get_destroy_msg(rdev,
>>> R600_RING_TYPE_UVD_INDEX, handle,
>>> &fence);
>>> if (r) {
>>> --
>>> 1.8.1.2
>>>
>
[Bug 64781] RV630 bad video playback (too fast) when HDMI audio output is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=64781 --- Comment #3 from Giannis --- The problem exist from web video playback (HTML5 or Flash video) to VLC and Parole. It is affecting everything. Playback settings are the default on (X)ubuntu. I already bisect kernel versions but I can't with commit bisect. I am novice user and build a custom kernel to find the commit is too hard for me. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #17 from darkbasic --- Anyway even with glxgears it's far from being perfect. See this video: http://www.youtube.com/watch?v=aM3aRiKgxwM -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/f68abbdc/attachment.html>
[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server
https://bugs.freedesktop.org/show_bug.cgi?id=71488 --- Comment #3 from Alex Deucher --- Does updating libdrm to 2.4.47 help? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131111/ab1f6cec/attachment.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #18 from Alex Deucher --- With kernel 3.13, the driver retains the user selected performance level across state changes. Additionally, when using a UVD state, the sclk and mclk are always forced to their highest levels. This isn't reflected in the debugfs output since that just prints the unpatched power state. Does plain video playback work ok (i.e., not qvdpautest)? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/262a2470/attachment.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #19 from darkbasic --- Alex from the tests I did 3.13 doesn't seem to behave the way you described. With power state set to "high", desktop effect OFF and no glxgears: MPEG DECODING (1920x1080): 5 frames/s MPEG DECODING (1280x720): 21 frames/s H264 DECODING (1920x1080): 8 frames/s H264 DECODING (1280x720): 5 frames/s With power state set to "high", desktop effect OFF and glxgears: MPEG DECODING (1920x1080): 77 frames/s MPEG DECODING (1280x720): 117 frames/s H264 DECODING (1920x1080): 16 frames/s H264 DECODING (1280x720): 91 frames/s With power state set to "high", desktop effect ON and glxgears: MPEG DECODING (1920x1080): 77 frames/s MPEG DECODING (1280x720): 117 frames/s H264 DECODING (1920x1080): 51 frames/s H264 DECODING (1280x720): 91 frames/s It seems even glxgears wasn't able to keep highest power state in all tests: enabling desktop effects was enough to keep higher state in the second-last test. What do you mean by "plain video playback"? If you mean without using vdpau it works flawlessly. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/1fb9c29a/attachment.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #20 from Alex Deucher --- (In reply to comment #19) > > What do you mean by "plain video playback"? If you mean without using vdpau > it works flawlessly. Just play a video with vdpau using mplayer or some other app that supports vdpau. I'm wondering if perhaps the way qvdpautest works causes the driver to switch between power states too often so the clocks never get a chance to stablize. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/d4855840/attachment-0001.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #21 from darkbasic --- No, I have the very same problem with mplayer2 + vdapu and adobe flash + vdpau. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131111/147d7359/attachment.html>
[PATCH 1/2] drm/radeon/audio: write audio/video latency info for DCE4/5
On Fri, Nov 8, 2013 at 6:24 AM, Anssi Hannula wrote: > 18.10.2013 23:41, Alex Deucher kirjoitti: >> Needed by the hda driver to properly set up synchronization >> on the audio side. >> >> Signed-off-by: Alex Deucher >> --- >> drivers/gpu/drm/radeon/evergreen_hdmi.c | 37 >> >> drivers/gpu/drm/radeon/evergreend.h | 38 >> + >> 2 files changed, 75 insertions(+) >> >> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c >> b/drivers/gpu/drm/radeon/evergreen_hdmi.c >> index 5fbe486..abdc893 100644 >> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c >> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c > [...] >> + if (connector->latency_present[0]) >> + tmp = VIDEO_LIPSYNC(connector->video_latency[0]) | >> + AUDIO_LIPSYNC(connector->audio_latency[0]); >> + else >> + tmp = VIDEO_LIPSYNC(255) | AUDIO_LIPSYNC(255); >> + } >> + WREG32(AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_LIPSYNC, tmp); > [...] >> +#define AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_LIPSYNC 0x5fe8 >> +# define VIDEO_LIPSYNC(x) (((x) & 0xff) << >> 0) >> +# define AUDIO_LIPSYNC(x) (((x) & 0xff) << >> 8) >> +/* VIDEO_LIPSYNC, AUDIO_LIPSYNC >> + * 0 = invalid >> + * x = legal delay value >> + * 255 = sync not supported >> + */ > > Hmm, AMD_HDA_verbs_v2.pdf says that: > 0 = unknown latency > > HDMI spec 1.4 says that: > 0 = not valid or unknown latency > 1..251 = valid delay value > 255= video not supported / audio not supported > > Are you sure you shouldn't use 0 instead for unknown (no latency_present)? I'm not sure. The comment in the code above is what the register spec says which seems to match the HDMI spec. I can dig around a bit more internally. Alex
drm/nouveau contiguous bo check produces lots of output
op 11-11-13 16:31, Jerry Cooperstein schreef: > Hi: > > commit bd9c5a2016307164c419c5e24a46921c10e620a0 > > (drm/nouveau: require contiguous bo for framebuffer) > produces about 2000 lines of > > nouveau E[ DRM] framebuffer requires contiguous bo > > on system boot and more on shutdown, but I don't see other > negative effects. I tried deploying a trivial patch removing the check and > saw > no other problems. > > Is this a problem you have heard about? > > My hardware is an NVIDIA Geoforce G98 (8400 GS), lspci -v gives: > > 01:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS] > (rev a1) (prog-if 00 [VGA controller]) > Subsystem: ASUSTeK Computer Inc. Device 8278 > Flags: bus master, fast devsel, latency 0, IRQ 16 > Memory at fd00 (32-bit, non-prefetchable) [size=16M] > Memory at d000 (64-bit, prefetchable) [size=256M] > Memory at fa00 (64-bit, non-prefetchable) [size=32M] > I/O ports at cc00 [size=128] > Expansion ROM at fe9e [disabled] [size=128K] > Capabilities: [60] Power Management version 3 > Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ > Capabilities: [78] Express Endpoint, MSI 00 > Capabilities: [100] Virtual Channel > Capabilities: [128] Power Budgeting > Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 > Kernel driver in use: nouveau > Kernel modules: nouveau > > This appeared in the 3.12 rc kernels and is in 3.12.0 > > If there is anything I can do to help you debug this please let me know. > I don't understand the drm code well enough to dive in deep on my own. It's a paranoia patch and any bo should not be created with NOUVEAU_GEM_TILE_NONCONTIG flag. Even if it happens to work it will fail on any sufficiently fragmented vram. What driver versions do you use? ~Maarten
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #22 from Vladimir Ysikov --- (In reply to comment #14) > Some rather stupid command-line tool with a couple of options for testing > different decoding profile and output methods should be perfectly sufficient. mplayer -benchmark ? http://www.w6rz.net/1080p25.zip kwin desktop effect ON and no glxgears mplayer -vo gl -benchmark -nosound 1080p25.ts ... BENCHMARKs: VC: 79.531s VO: 27.184s A: 0.000s Sys: 2.558s = 109.273s BENCHMARK%: VC: 72.7814% VO: 24.8773% A: 0.% Sys: 2.3413% = 100.% kwin desktop effect ON and no glxgears mplayer -benchmark -vo vdpau -vc ffmpeg12vdpau -nosound 1080p25.ts ... BENCHMARKs: VC: 2.425s VO: 38.371s A: 0.000s Sys: 3.190s = 43.986s BENCHMARK%: VC: 5.5141% VO: 87.2335% A: 0.% Sys: 7.2523% = 100.% kwin desktop effect ON and glxgears mplayer -benchmark -vo vdpau -vc ffmpeg12vdpau -nosound 1080p25.ts ... BENCHMARKs: VC: 2.449s VO: 38.074s A: 0.000s Sys: 3.748s = 44.271s BENCHMARK%: VC: 5.5325% VO: 86.0010% A: 0.% Sys: 8.4665% = 100.% -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/e088b4b6/attachment.html>
[pull] radeon drm-next-3.13
Hi Dave, One last patch I keep forgetting to include. Fix for EDID quirk handling. Been on the list and reviewed for several months now, I just keep forgetting about it. The following changes since commit cf0613d242805797f252535fcf7bb019512beb46: Merge branch 'gma500-next' of git://github.com/patjak/drm-gma500 into drm-next (2013-11-11 07:25:33 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-3.13 for you to fetch changes up to 339d202cde8e63113124d8931203f5bdb3343f27: drm/edid: compare actual vrefresh for all modes for quirks (2013-11-11 11:08:12 -0500) Alex Deucher (1): drm/edid: compare actual vrefresh for all modes for quirks drivers/gpu/drm/drm_edid.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-)
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #23 from darkbasic --- I used to use mplayer benchmark before switching to qvdpautest, unfortunately results are not comparable because other peoples have to have the very same videos (which tends to go offline after some months). vdpautest is the right way to go in my opinion, we just need someone to fix the remaining bugs. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131111/66135bcd/attachment.html>
drm/nouveau contiguous bo check produces lots of output
op 11-11-13 17:05, Jerry Cooperstein schreef: > On 11/11/2013 09:57 AM, Maarten Lankhorst wrote: >> op 11-11-13 16:31, Jerry Cooperstein schreef: >>> Hi: >>> >>> commit bd9c5a2016307164c419c5e24a46921c10e620a0 >>> >>> (drm/nouveau: require contiguous bo for framebuffer) >>> produces about 2000 lines of >>> >>> nouveau E[ DRM] framebuffer requires contiguous bo >>> >>> on system boot and more on shutdown, but I don't see other >>> negative effects. I tried deploying a trivial patch removing the check and >>> saw >>> no other problems. >>> >>> Is this a problem you have heard about? >>> >>> My hardware is an NVIDIA Geoforce G98 (8400 GS), lspci -v gives: >>> >>> 01:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS] >>> (rev a1) (prog-if 00 [VGA controller]) >>> Subsystem: ASUSTeK Computer Inc. Device 8278 >>> Flags: bus master, fast devsel, latency 0, IRQ 16 >>> Memory at fd00 (32-bit, non-prefetchable) [size=16M] >>> Memory at d000 (64-bit, prefetchable) [size=256M] >>> Memory at fa00 (64-bit, non-prefetchable) [size=32M] >>> I/O ports at cc00 [size=128] >>> Expansion ROM at fe9e [disabled] [size=128K] >>> Capabilities: [60] Power Management version 3 >>> Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ >>> Capabilities: [78] Express Endpoint, MSI 00 >>> Capabilities: [100] Virtual Channel >>> Capabilities: [128] Power Budgeting >>> Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 >>> >>> Kernel driver in use: nouveau >>> Kernel modules: nouveau >>> >>> This appeared in the 3.12 rc kernels and is in 3.12.0 >>> >>> If there is anything I can do to help you debug this please let me know. >>> I don't understand the drm code well enough to dive in deep on my own. >> It's a paranoia patch and any bo should not be created with >> NOUVEAU_GEM_TILE_NONCONTIG flag. >> Even if it happens to work it will fail on any sufficiently fragmented vram. >> >> What driver versions do you use? >> >> ~Maarten >> >> > > I'm just using vanilla 3.12 kernel. Been using the nouveau driver > for a long time, no problems until this printout due to the > contiguous check. Not using any of the "nvidia" related modules etc. > CONFIG_AGP is set. Sorry I meant userspace, libdrm, mesa, xserver-xorg-video-nouveau? Using Xorg, mir or wayland?
[PATCH 2/2] intel: Silence warning in non-Valgrind build
From: Ian Romanick
Previously GCC was squaking about:
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_map_unsynchronized':
intel_bufmgr_gem.c:1325:20: warning: unused variable 'bo_gem'
[-Wunused-variable]
Wrapping with VG(); replaced that warning with:
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_map_unsynchronized':
intel_bufmgr_gem.c:1326:2: warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement]
Which, looking at the definition of the VG macro, seems a bit weird.
It's caused by the dangling ";" left from the empty macro.
Signed-off-by: Ian Romanick
Cc: Chia-I Wu
---
intel/intel_bufmgr_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 5b64a7f..dbadc52 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1322,7 +1322,9 @@ int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo)
int drm_intel_gem_bo_map_unsynchronized(drm_intel_bo *bo)
{
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
+#ifdef HAVE_VALGRIND
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+#endif
int ret;
/* If the CPU cache isn't coherent with the GTT, then use a
--
1.8.1.4
[PATCH 1/2] intel: Add accessor to get HW context ID from a drm_intel_context
From: Ian Romanick
The drm_intel_context structure is, wisely, opaque. However, libdrm
users may want to know the hardware context ID associated with the
structure.
Signed-off-by: Ian Romanick
Cc: Ben Widawsky
---
intel/intel_bufmgr.h | 1 +
intel/intel_bufmgr_gem.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 15f818e..7b28a70 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -194,6 +194,7 @@ drm_intel_context
*drm_intel_gem_context_create(drm_intel_bufmgr *bufmgr);
void drm_intel_gem_context_destroy(drm_intel_context *ctx);
int drm_intel_gem_bo_context_exec(drm_intel_bo *bo, drm_intel_context *ctx,
int used, unsigned int flags);
+unsigned int drm_intel_gem_context_get_hw_context_id(const drm_intel_context
*);
int drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, int *prime_fd);
drm_intel_bo *drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr *bufmgr,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 029ca5d..5b64a7f 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3020,6 +3020,12 @@ drm_intel_gem_context_destroy(drm_intel_context *ctx)
free(ctx);
}
+unsigned int
+drm_intel_gem_context_get_hw_context_id(const drm_intel_context *ctx)
+{
+ return ctx->ctx_id;
+}
+
int
drm_intel_reg_read(drm_intel_bufmgr *bufmgr,
uint32_t offset,
--
1.8.1.4
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #24 from darkbasic --- kwin desktop effects ON and glxgears mplayer2 -benchmark -vo vdpau -vc ffmpeg12vdpau -nosound 1080p25.ts BENCHMARKs: VC: 5.073s VO: 105.829s A: 0.000s Sys: 3.263s = 114.164s BENCHMARK%: VC: 4.4433% VO: 92.6989% A: 0.% Sys: 2.8578% = 100.% Mplayer better shows the behaviour I wanted to show with the previous video: it takes *ALOT* of time to start the benchmark, but then it's quite fast. At least while glxgears is running: in fact without glxgears it takes ages. Here is a second video showing the lag I'm talking about: http://www.youtube.com/watch?v=BDhB61U9S0A As you can see when it starts decoding is quite fast. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/08d5e42e/attachment.html>
[Bug 63101] Hard lockup whel launching games like TF2 on kernels 3.11.5 and 3.12 rc4 and above if radeon.dpm=1 is used
https://bugzilla.kernel.org/show_bug.cgi?id=63101 --- Comment #17 from Alex Deucher --- Created attachment 114241 --> https://bugzilla.kernel.org/attachment.cgi?id=114241&action=edit disable various dpm features You might try disabling trinity dpm features to see if you can narrow down what's causing the stability problems. Try the attached patch and see if it helps, and if so, try enabling additional features to narrow down the problem. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929 Laurent carlier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131111/47d9c5a0/attachment.html>
[Bug 64721] Radeon HD6450 fails on all distro's out of box.
https://bugzilla.kernel.org/show_bug.cgi?id=64721 --- Comment #2 from stanleyk --- LinuxMint15 Kernel 3.8.0-19-64 was fine on the laptop. On my desktop with the HD6450 I gave up trying to get a live boot. Linux debian Kernel 3.2.0-4-64 but need vga=771 to get a video and 1600:900 resolution. dmsg attached. Linux Knoppix kernel 3.6.11-64 Log attached, vga=771 okay, 791 left and right of screen crossed. Could not get 1600:900 resolution. Linux debian wheezy kernel 3.2.0.4 log attached, would only boot with vga=791, looks good but not used it, hardly at all. I hope that I have given you the logs that you need. If not please let me know where to find them. I'm sure that this is a problem with the boot process, all that the vga=xxx does is kick it into the right condition to load the driver. Thanks for you attention. Regards Ian. On 11/11/2013 08:17 AM, bugzilla-daemon at bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=64721 > > Alex Deucher changed: > > What|Removed |Added > > CC||alexdeucher at gmail.com > > --- Comment #1 from Alex Deucher --- > Please attach your xorg log and dmesg output. What kernels have you tested > with? > -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/2] intel: Add accessor to get HW context ID from a drm_intel_context
Ian Romanick writes: > From: Ian Romanick > > The drm_intel_context structure is, wisely, opaque. However, libdrm > users may want to know the hardware context ID associated with the > structure. We've had a bunch of our other structures be partially transparent. The context id to be passed to the kernel could easily be public just like the gem handle in a BO is public. I would lean slightly toward that. But I don't feel strongly either way, so these two are: Reviewed-by: Eric Anholt -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/58ba2c89/attachment.pgp>
possible regression Radeon RV280 (R3xx/R4xx ?) card freeze, re-apply old patch ?
On Fri, Nov 8, 2013 at 2:35 AM, Jochen Rollwagen
wrote:
>
> Hello there,
>
> i *think* i found a regression (card/system freeze in AGP mode) that must
> have been in the drm code for quite some time (since the switch to kms
> drivers) and possibly also the potential solution (re-apply an old patch from
> pre-kms-days). Affected seem to be older cards (actually, very old cards :-)
> before R600. I mailed this to the ati driver mailing list, but was told that
> this is a kernel/drm subject now, so i forward the mail interchange to this
> list. Details below, one has to start reading from the end upwards to get the
> chronological order, of course.
>
> Could somebody give me a hint on how to re-apply the old patch or whether the
> info i found is valid ? The next step i would take is to insert some
> diagnostic messages in radeon_vram_location (see below) and build a new
> kernel.
>
I'm not entirely sure what you are proposing to change, but none of
the stuff you mentioned below has to do with AGP. AGP is unstable
because AGP sucks. KMS unfortunately exacerbates that since it makes
much greater use of AGP memory than UMS ever did. To really fix AGP
with KMS, we'd probably need to manage two pools of memory, one
non-cache-coherent pool for AGP and one cache coherent pool that used
the on-chip gart, then fix up the kernel and userspace accel drivers
to use the appropriate pools.
Alex
> Cheers
>
> Jochen
>
>
> Original-Nachricht
> Betreff: Fwd: Fwd: Fwd: Re: regression on RV280 card freeze, patch not
> applicable any more
> Datum: Fri, 25 Oct 2013 15:04:33 +0200
> Von: Jochen Rollwagen
> An: xorg-driver-ati at lists.x.org
>
> more info (and possible solution):
>
> void radeon_vram_location in radeon_device.c says
>
> * Note: GTT start, end, size should be initialized before calling this
> * function on AGP platform.
> *
> * Note: We don't explicitly enforce VRAM start to be aligned on VRAM size,
> * this shouldn't be a problem as we are using the PCI aperture as a
> reference.
> * Otherwise this would be needed for rv280, all r3xx, and all r4xx, but
> * not IGP.
> *
>
> so does this mean i just have to re-apply the old patch i found ? struct
> radeon_mc in radeon.h contains aper_base as a member which could be
> set/aligned to VRAM size using the code snippet below.
>
> Cheers
>
> Jochen
>
>
> Original-Nachricht
> Betreff: Fwd: Fwd: Re: regression on RV280 card freeze, patch not applicable
> any more
> Datum: Fri, 25 Oct 2013 11:31:32 +0200
> Von: Jochen Rollwagen
> An: xorg-driver-ati at lists.x.org
>
> I've done some more researching and found the following:
>
> - There's another follow-on-patch ("Extend the alignment workaround to
> post-rv280 chips as well") to the one indicated below
> (http://cgit.freedesktop.org/~agd5f/xf86-video-ati/commit/?id=b2145aea36bb035bff048366c607b967d70fff49)
> that applies to not only RV280 but "rv280, all r3xx, and all r4xx, but not
> IGP".
>
> - the piece of code affected seems to be (IMHO) in drivers/gpu/drm/radeon/:
> The (Radeon ?) Register RADEON_CONFIG_APER_0_BASE is defined in radeon_reg.h
> but never used in the driver:
>
> radeon_reg.h:#define RADEON_CONFIG_APER_0_BASE 0x0100
>
> in r100.c there's
>
> static u32 r100_get_accessible_vram(struct radeon_device *rdev)
> {
> u32 aper_size;
> u8 byte;
>
> aper_size = RREG32(RADEON_CONFIG_APER_SIZE);
>
> /* Set HDP_APER_CNTL only on cards that are known not to be broken,
> * that is has the 2nd generation multifunction PCI interface
> */
> if (rdev->family == CHIP_RV280 ||
> rdev->family >= CHIP_RV350) {
> WREG32_P(RADEON_HOST_PATH_CNTL, RADEON_HDP_APER_CNTL,
>~RADEON_HDP_APER_CNTL);
> DRM_INFO("Generation 2 PCI interface, using max accessible memory\n");
> return aper_size * 2;
> }
>
> That's the code executed on my machine according to dmesg. Missing (from the
> original patch, not applicable any more because of driver reorganization)
> seems to be
>
> CARD32 aper0_base = INREG(RADEON_CONFIG_APER_0_BASE);
> aper0_base &= ~(mem_size - 1);
> info->mc_fb_location = (aper0_base >> 16);
>
> The patch that seems to have removed/overridden this code is:
>
> http://www.mail-archive.com/dri-devel at lists.sourceforge.net/msg41307.html
>
> According to that patch, it was "booted on PCI r100, PCIE rv370, IGP rs400".
> So IMHO this could be a classical regression for an AGP RV280 card (like
> mine) and might explain why PCI mode works. this is Additionally corroborated
> by this post (http://comments.gmane.org/gmane.comp.freedesktop.xorg/5429):
>
> * The above doesn't necessarily work. For example, I've seen machines * with
> 128Mb configured as 2x64Mb apertures. I'm now _always_ setting *
> RADEON_HOST_PATH_CNTL. OUTREGP (RADEON_HOST_PATH_CNTL, RADEON_HDP_APER_CNTL,
> ~RADEON_HDP_APER_CNTL); (which was previously done only on some chip
> families).
>
> I _think
drm/nouveau contiguous bo check produces lots of output
On 11/11/2013 09:57 AM, Maarten Lankhorst wrote: > op 11-11-13 16:31, Jerry Cooperstein schreef: >> Hi: >> >> commit bd9c5a2016307164c419c5e24a46921c10e620a0 >> >> (drm/nouveau: require contiguous bo for framebuffer) >> produces about 2000 lines of >> >> nouveau E[ DRM] framebuffer requires contiguous bo >> >> on system boot and more on shutdown, but I don't see other >> negative effects. I tried deploying a trivial patch removing the check and >> saw >> no other problems. >> >> Is this a problem you have heard about? >> >> My hardware is an NVIDIA Geoforce G98 (8400 GS), lspci -v gives: >> >> 01:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS] >> (rev a1) (prog-if 00 [VGA controller]) >> Subsystem: ASUSTeK Computer Inc. Device 8278 >> Flags: bus master, fast devsel, latency 0, IRQ 16 >> Memory at fd00 (32-bit, non-prefetchable) [size=16M] >> Memory at d000 (64-bit, prefetchable) [size=256M] >> Memory at fa00 (64-bit, non-prefetchable) [size=32M] >> I/O ports at cc00 [size=128] >> Expansion ROM at fe9e [disabled] [size=128K] >> Capabilities: [60] Power Management version 3 >> Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ >> Capabilities: [78] Express Endpoint, MSI 00 >> Capabilities: [100] Virtual Channel >> Capabilities: [128] Power Budgeting >> Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 >> >> Kernel driver in use: nouveau >> Kernel modules: nouveau >> >> This appeared in the 3.12 rc kernels and is in 3.12.0 >> >> If there is anything I can do to help you debug this please let me know. >> I don't understand the drm code well enough to dive in deep on my own. > It's a paranoia patch and any bo should not be created with > NOUVEAU_GEM_TILE_NONCONTIG flag. > Even if it happens to work it will fail on any sufficiently fragmented vram. > > What driver versions do you use? > > ~Maarten > > I'm just using vanilla 3.12 kernel. Been using the nouveau driver for a long time, no problems until this printout due to the contiguous check. Not using any of the "nvidia" related modules etc. CONFIG_AGP is set. lsmod | grep nouveau nouveau 895494 2 ttm67720 1 nouveau drm_kms_helper 38367 1 nouveau drm 258311 4 nouveau,ttm,drm_kms_helper i2c_algo_bit5122 1 nouveau mxm_wmi 1769 1 nouveau wmi 9036 2 nouveau,mxm_wmi no other hardware other than built in intel hda sound, ahci disk, and marvel GB NIC's. Asus motherboard. -- Jerry Cooperstein, PhD Training Program Director Linux Foundation coop at linuxfoundation.org (608) 848-1507 (Madison, WI, USA)
[PATCH] drm/tegra: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERO
On Wed, Nov 06, 2013 at 05:49:55PM +0100, Stephen Warren wrote: > On 11/06/2013 12:53 AM, Duan Jiong wrote: > > This patch fixes coccinelle error regarding usage of IS_ERR and > > PTR_ERR instead of PTR_ERR_OR_ZERO. > > > diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c > > > @@ -199,10 +199,7 @@ int tegra_bo_dumb_create(struct drm_file *file, struct > > drm_device *drm, > > > > bo = tegra_bo_create_with_handle(file, drm, args->size, 0, > > &args->handle); > > - if (IS_ERR(bo)) > > - return PTR_ERR(bo); > > - > > - return 0; > > + return PTR_ERR_OR_ZERO(bo); > > } > > I suppose that's fine, although I wonder if it'll cause churn should we > ever need to add code to the tail end of the function. It's unlikely that we'll ever need to add to this function. But I'm not a big fan of PTR_ERR_OR_ZERO to be honest, so I'll let this sink in for a bit before applying. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/b62f1a74/attachment.pgp>
[Linaro-mm-sig] thoughts of looking at android fences
I ran some benchmarks and things seem to be running about the same. No one on our graphics team seemed concerned about the change. The only concern I heard was about the increased complexity of the new sync code as opposed to the old sync framework which tried to keep things straightforward. On Fri, Nov 8, 2013 at 3:43 AM, Maarten Lankhorst < maarten.lankhorst at canonical.com> wrote: > op 07-11-13 22:11, Rom Lemarchand schreef: > > Hi Maarten, I tested your changes and needed the attached patch: behavior > > now seems equivalent as android sync. I haven't tested performance. > > > > The issue resolved by this patch happens when i_b < b->num_fences and i_a > >> = a->num_fences (or vice versa). Then, pt_a is invalid and so > > dereferencing pt_a->context causes a crash. > > > Yeah, I pushed my original fix. I intended to keep android userspace > behavior the same, and I tried to keep the kernelspace the api same as much > as I could. If peformance is the same, or not noticeably worse, would there > be any objections on the android side about renaming dma-fence to > syncpoint, and getting it in mainline? > > ~Maarten > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2013/8632187b/attachment.html>
vblank_count count jumps backwards and then forwards across system suspend
I'm getting some weird results when using vblank_count on my Ivybridge machine across suspend/resume. With glxgears running, I suspend the machine. At resume, I see vblank_count temporarily jump back by a fairly large amount (usually between 1 and 2 frames). After a short while, it recovers and jumps back to something that looks like it's back on track with values
