[Bug 71067] [drm:r600] UVD not responding OR failed testing IB on GFX ring

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71067

Timoth?e Ravier  changed:

   What|Removed |Added

  Attachment #88381|0   |1
is obsolete||

--- Comment #3 from Timoth?e Ravier  ---
Created attachment 88383
  --> https://bugs.freedesktop.org/attachment.cgi?id=88383=edit
dmesg log freeze-boot-then-yellow

-- 
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/20131030/5b958391/attachment.html>

[Bug 71067] [drm:r600] UVD not responding OR failed testing IB on GFX ring

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71067

--- Comment #2 from Timoth?e Ravier  ---
Created attachment 88382
  --> https://bugs.freedesktop.org/attachment.cgi?id=88382=edit
dmesg log freeze-cursor

-- 
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/20131030/c1e21fc9/attachment.html>

[Bug 71067] [drm:r600] UVD not responding OR failed testing IB on GFX ring

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71067

--- Comment #1 from Timoth?e Ravier  ---
Created attachment 88381
  --> https://bugs.freedesktop.org/attachment.cgi?id=88381=edit
dmesg log

-- 
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/20131030/32b56978/attachment-0001.html>

[Bug 71067] [drm:r600] UVD not responding OR failed testing IB on GFX ring

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71067

Timoth?e Ravier  changed:

   What|Removed |Added

   Hardware|Other   |x86-64 (AMD64)
 OS|All |Linux (All)

-- 
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/20131030/662b84bc/attachment.html>

[Bug 71067] New: [drm:r600] UVD not responding OR failed testing IB on GFX ring

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71067

  Priority: medium
Bug ID: 71067
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [drm:r600] UVD not responding OR failed testing IB on
GFX ring
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: timothee.romain.ravier at gmail.com
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

When I boot 3.10 or 3.11 kernels, I get either one of those errors, apparently
at random :
  * UVD not responding, trying to reset the VCPU
-> Full log attached: *freeze-boot-then-yellow.log
The display turns yellow when the X server starts. I can still use VT and
there is no corruption there. I made sure that I got the latest firmware and I
also checked my initrd (following instructions in 65270);

  * GPU lockup CP stall for more than 1msec
GPU lockup (waiting for 0x020e last fence id
0x01ec)
r600_ib_test] *ERROR* radeon: fence wait failed (-35)
radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35)
-> Full log attached: *freeze-cursor.log
I can log into my graphical session, but quickly after that, everything
freeze and I can only move the cursor which displays as a "corrupted" square.
Again VT are fine.

I filed only one bug report as I get both issue using the same software and
boot command line.

At the beginning I had bug 67994, which turned into this one. I tried
downgrading the kernel without much success for now.

Booting with nomodeset works perfectly (with no accel/KMS obviously) and
booting under Windows 7 too.

-- 
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/20131030/22931253/attachment.html>

[PATCH] drm/sysfs: Do not drop device reference twice

[Thierry Reding]

On Wed, Oct 30, 2013 at 02:05:02PM -0200, Paulo Zanoni wrote:
> 2013/10/30 Thierry Reding :
> > device_unregister() already drops its reference to the struct device, so
> > explicitly calling put_device() before device_unregister() can cause the
> > device to have been freed before it can be unregistered.
> >
> > Signed-off-by: Thierry Reding 
> 
> I started investigating this problem yesterday and reached the same
> conclusion. The connector path can be easily reproduced on i915.ko:
> get a machine that has an eDP panel, physically disconnect the panel,
> boot the machine, "modprobe i915" and watch the segfault.
> 
> Reviewed-by: Paulo Zanoni 
> Tested-by: Paulo Zanoni 
> 
> I didn't really bisect, but I believe this is probably a regression
> from "drm/sysfs: sort out minor and connector device object
> lifetimes".

Yes, I think that's the one that broke it.

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/20131030/a401c97f/attachment.pgp>

[PATCH 29/51] DMA-API: ata: pata_octeon_cf: convert to use dma_coerce_mask_and_coherent()

[Geert Uytterhoeven]

On Thu, Sep 19, 2013 at 11:54 PM, Russell King
 wrote:
> diff --git a/drivers/ata/pata_octeon_cf.c b/drivers/ata/pata_octeon_cf.c
> index c51bbb9..6231d43 100644
> --- a/drivers/ata/pata_octeon_cf.c
> +++ b/drivers/ata/pata_octeon_cf.c
> @@ -1014,8 +1014,9 @@ static int octeon_cf_probe(struct platform_device *pdev)
> }
> cf_port->c0 = ap->ioaddr.ctl_addr;
>
> -   pdev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
> -   pdev->dev.dma_mask = >dev.coherent_dma_mask;
> +   rv = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(64));
> +   if (rv)
> +   return ret;

return rv;

http://kisskb.ellerman.id.au/kisskb/buildresult/9959184/

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

vddc phase shedding in smc tables

[Sylvain BERTRAND]

> unless I'm not understanding your question.

Nope, my bad, I miss-read and did not double-check.

:)

BTW, which generations/families/types(mobile...) do support phase shedding?

regards,

-- 
Sylvain

outcome of DRM/KMS DT bindings session

[Tomasz Figa]

On Wednesday 30 of October 2013 13:02:29 Sascha Hauer wrote:
> On Tue, Oct 29, 2013 at 01:52:57PM +1000, Dave Airlie wrote:
> > So we had a sessions at kernel summit to discuss the driver model and
> > DT interactions for a display pipeline,
> > 
> > we had good attendance from a few sides and I hope to summarise the
> > recommendations below,
> > 
> > a) Device Tree bindings
> > 
> > We should create a top-level virtual device binding that a top level
> > driver can bind to, like alsa asoc does.
> > 
> > We should separate the CDF device tree model from CDF as a starting
> > point and refine it outside of CDF, and produce a set of bindings that
> > cover the current drivers we have, exynos, imx, tegra, msm, armada
> > etc. This set of bindings should not be tied on CDF being merged or
> > anything else.
> > 
> > Display pipelines should be modelered in the device tree, but the
> > level of detail required for links between objects may be left up to
> > the SoC developer, esp wrt tightly coupled SoCs.
> > 
> > Externally linked devices like bridges and panels should be explicitly
> > linked.
> > 
> > b) Driver Model
> > 
> > The big thing here is that the device tree description we use should
> > not dictate the driver model we use. This is the biggest thing I
> > learned, so what does it mean?
> > 
> > We aren't required to write a device driver per device tree object.
> > 
> > We shouldn't be writing device drivers per device tree object.
> > 
> > For tightly-coupled SoCs where the blocks come from one vendor and are
> > reused a lot, a top level driver should use the DT as configuration
> > information source for the list of blocks it needs to initialise on
> > the card, not as a list of separate drivers. There may be some
> > external drivers required and the code should deal with this, like how
> > alsa asoc does.
> > 
> > To share code between layers we should refactor it into a helper
> > library not a separate driver, the kms/v4l/fbdev can use the library.
> > 
> > This should allow us to move forward a bit clearer esp with new
> > drivers and following these recommendations, and I think porting
> > current drivers to a sane model, especially exynos and imx.
> > 
> > Now I saw we here but I'm only going to be donating my use of a big
> > stick and review abilities to making this happen, but I'm quite
> > willing to enforce some of these rules going forward as I think it
> > will make life easier.
> > 
> > After looking at some of the ordering issues we've had with x86 GPUs
> > (which are really just a tightly coupled SoC) I don't want separate
> > drivers all having their own init, suspend/resume paths in them as I
> > know we'll have to start making special vtable entry points etc to
> > solve some random ordering issues that crop up.
> 
> The DRM device has to be initialized/suspended/resumed as a whole, no
> doubt about that. If that's not the case you indeed open up the door for
> all kinds of ordering issues.
> 
> Still the different components can be multiple devices, just initialize
> the drm device once all components are probed. Remove it again once a
> component is removed. Handle suspend in the DRM device, not in
> the individual component drivers. The suspend in the component drivers
> would only be called after the DRM device is completely quiesced.
> Similarly the resume in the component drivers would not reenable the
> components, this instead would be done in the DRM device when all
> components are there again.
>
> This way all components could be proper (driver model)devices with
> proper drivers without DRM even noticing that multiple components are
> involved.
> 
> Side note: We have no choice anyway. All SoCs can (sometimes must)
> be extended with external I2C devices. On every SoC the I2C bus master
> is a separate device, so we have a multicomponent device (in the sense
> of driver model) already in many cases.

+1

Best regards,
Tomasz

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Daniel Vetter]

On Wed, Oct 30, 2013 at 4:32 PM, Sean Paul  wrote:
> Once all required nodes have been "claimed", the main driver's probe
> would call drm_platform/pci_init to kick off load(). After load() has
> finished, the drm layer would then call the various standalone driver
> hooks that were previously registered when it claimed its node. These
> hooks would allow the driver to register its
> crtc/encoder/bridge/connector.

Just a quick comment on calling the ->driver_load callback: I plan to
look again my "kill drm midlayer" series so that drivers are in full
control of the load sequence. Then they could do whatever delayed
loading the need to do by calling into optional helpers (hopefully
shared with asoc and v4l and other aggregate devices madness) and the
drm core simply does not need to care: The driver only
registers/allocates the drm_device once it's ready to do so.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Laurent Pinchart]

On Wednesday 30 October 2013 11:32:24 Sean Paul wrote:
> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:

[snip]

> >> An example: exynos_drm_drv would be a platform_driver which implements
> >> drm_driver. On drm_load, it would enumerate the various dt nodes for
> >> its IP blocks and initialize them with direct calls (like
> >> exynos_drm_fimd_initialize). If the board uses a bridge (say for
> >> eDP->LVDS), that bridge driver would be a real driver with its own
> >> probe.
> >> 
> >> I think the ideal situation would be for the drm layer to manage the
> >> standalone drivers in a way that is transparent to the main driver,
> >> such that it doesn't need to know which type of hardware can hang off
> >> it. It will need to know if one exists since it might need to forego
> >> creating a connector, but it need not know anything else about it.
> >> 
> >> To accomplish this, I think we need:
> >> (1) Some way for drm to enumerate the standalone drivers, so it can
> >> know when all of them have been probed
> >> 
> >> (2) A drm registration function that's called by the standalone
> >> drivers once they're probed, and a hook with drm_device pointer called
> >> during drm_load for them to register their drm_* implementations
> >> 
> >> (3) Something that will allow for deferred probe if the main driver
> >> kicks off before the standalones are in, it would need to be called
> >> before drm_platform/pci_init
> >> 
> >> I think we'll need to expand on the media bindings to achieve (1).
> > 
> > Could you elaborate on why you think so?
> > 
> > I believe the video interface bindings contain everything needed for this
> > case, except, of course, some device/bus specific parts, but those are to
> > be defined by separate device/bus specific bindings.
> 
> AFAICT, there is no way for drm to enumerate all of the pieces that
> need probing before it loads (ie: how do you enumerate all device
> nodes with pipe {} subnode[s]). I've given this more thought, and I
> think the following could work without forcing unified/split drivers
> (ie: it can be left to the driver author to choose).
> 
> If there was some way for drm to know all of the pieces that need to
> be probed/initialized before calling drm_load, it could provide an API
> for various drivers to "claim" nodes. This API would accept the
> device_node being claimed as well as an initialize hook that will be
> called back to give the standalone driver a pointer to the drm_device.
> 
> The main drm driver, which is responsible for calling
> drm_platform/pci_init, would claim the nodes it plans on implementing
> in the probe. It would then check drm to see if all requred nodes had
> been claimed. If they have not been claimed, that probe would defer
> and try again later.
> 
> Once all required nodes have been "claimed", the main driver's probe
> would call drm_platform/pci_init to kick off load(). After load() has
> finished, the drm layer would then call the various standalone driver
> hooks that were previously registered when it claimed its node. These
> hooks would allow the driver to register its
> crtc/encoder/bridge/connector.
> 
> Multi-driver solutions could work within this framework, as could
> integrated ones. This would also allow things like bridge drivers to
> be completely transparent.

Have you all configured your spam filters to reject anything that is or has 
been related to CDF ?

Split in two patches, the first one adding the infrastructure, the second one 
adding OF support.

http://git.linuxtv.org/pinchartl/fbdev.git/commitdiff/2d19e74ab8d86aaf5d54c34c6bc940508f793512
http://git.linuxtv.org/pinchartl/fbdev.git/commitdiff/e8c4380ca4a6a62fa9d8bc340a6dcbd123b4f674

The code can be extracted as a stand-alone solution, either specific to DRM, 
or at the struct device level. As the problem is not DRM-specific, the later 
would probably make more sense (if I'm not mistaken Grant Likely - CCed- 
mentioned during the kernel summit was in favor of adding the code in the 
device core).

We've solved the exact same problem in V4L, do we *really* need to adopt the 
NIH approach and reinvent the wheel ?

> I hope that made sense ;)

-- 
Regards,

Laurent Pinchart

[PATCH] drm/radeon: don't use PACKET2 on CIK

[Christian König]

Am 30.10.2013 14:41, schrieb Marek Ol??k:
> From: Marek Ol??k 
>
> It is said to cause hangs.
>
> Signed-off-by: Marek Ol??k 

We should probably do so for SI as well.

Patch is Reviewed-by: Christian K?nig 

> ---
>   drivers/gpu/drm/radeon/cik.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 2cd2ac0..44507a4 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -7134,7 +7134,7 @@ static int cik_startup(struct radeon_device *rdev)
>   ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
>   r = radeon_ring_init(rdev, ring, ring->ring_size, 
> RADEON_WB_CP_RPTR_OFFSET,
>CP_RB0_RPTR, CP_RB0_WPTR,
> -  RADEON_CP_PACKET2);
> +  PACKET3(PACKET3_NOP, 0x3FFF));
>   if (r)
>   return r;
>   

[PATCH] drm/radeon: don't use PACKET2 on CIK

[Marek Olšák]

From: Marek Ol??k 

It is said to cause hangs.

Signed-off-by: Marek Ol??k 
---
 drivers/gpu/drm/radeon/cik.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 2cd2ac0..44507a4 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7134,7 +7134,7 @@ static int cik_startup(struct radeon_device *rdev)
ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size, 
RADEON_WB_CP_RPTR_OFFSET,
 CP_RB0_RPTR, CP_RB0_WPTR,
-RADEON_CP_PACKET2);
+PACKET3(PACKET3_NOP, 0x3FFF));
if (r)
return r;

-- 
1.8.1.2

vddc phase shedding in smc tables

[Alex Deucher]

On Wed, Oct 30, 2013 at 2:28 PM, Sylvain BERTRAND  wrote:
>> unless I'm not understanding your question.
>
> Nope, my bad, I miss-read and did not double-check.
>
> :)
>
> BTW, which generations/families/types(mobile...) do support phase shedding?

Southern Islands and Sea Islands dGPU parts as far as I know.

Alex

>
> regards,
>
> --
> Sylvain

[Bug 64471] Radeon HD6570 lockup in Brütal Legend with HyperZ

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64471

Alex Deucher  changed:

   What|Removed |Added

 CC||johannes.hirte at datenkhaos.d
   ||e

--- Comment #9 from Alex Deucher  ---
*** Bug 71046 has been marked as a duplicate of this bug. ***

-- 
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/20131030/e0f75e75/attachment.html>

[Bug 71046] GPU lockup on HD5470 with Brütal Legend

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71046

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 64471 ***

-- 
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/20131030/3a13af1d/attachment.html>

[Bug 71046] GPU lockup on HD5470 with Brütal Legend

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71046

--- Comment #3 from Johannes Hirte  ---
Yes, seems to be the same problem. Disabling hyperZ fixes the lockups but there
are still graphic corruptions.

-- 
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/20131030/e38fc6b0/attachment.html>

[PATCH] drm/sysfs: Do not drop device reference twice

[Paulo Zanoni]

2013/10/30 Thierry Reding :
> device_unregister() already drops its reference to the struct device, so
> explicitly calling put_device() before device_unregister() can cause the
> device to have been freed before it can be unregistered.
>
> Signed-off-by: Thierry Reding 

I started investigating this problem yesterday and reached the same
conclusion. The connector path can be easily reproduced on i915.ko:
get a machine that has an eDP panel, physically disconnect the panel,
boot the machine, "modprobe i915" and watch the segfault.

Reviewed-by: Paulo Zanoni 
Tested-by: Paulo Zanoni 

I didn't really bisect, but I believe this is probably a regression
from "drm/sysfs: sort out minor and connector device object
lifetimes".

And kudos to whoever invented CONFIG_DEBUG_KOBJECT :)

> ---
>  drivers/gpu/drm/drm_sysfs.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index dae42c7..db1c8f9 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -439,7 +439,6 @@ err_out_files:
> device_remove_file(connector->kdev, _attrs_opt1[i]);
> for (i = 0; i < attr_cnt; i++)
> device_remove_file(connector->kdev, _attrs[i]);
> -   put_device(connector->kdev);
> device_unregister(connector->kdev);
>
>  out:
> @@ -472,7 +471,6 @@ void drm_sysfs_connector_remove(struct drm_connector 
> *connector)
> for (i = 0; i < ARRAY_SIZE(connector_attrs); i++)
> device_remove_file(connector->kdev, _attrs[i]);
> sysfs_remove_bin_file(>kdev->kobj, _attr);
> -   put_device(connector->kdev);
> device_unregister(connector->kdev);
> connector->kdev = NULL;
>  }
> --
> 1.8.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Paulo Zanoni

[Linaro-mm-sig] thoughts of looking at android fences

[Maarten Lankhorst]

op 24-10-13 14:13, Maarten Lankhorst schreef:
> op 09-10-13 16:39, Maarten Lankhorst schreef:
>> Hey,
>>
>>  op 08-10-13 19:37, John Stultz schreef:
>>> On Wed, Oct 2, 2013 at 11:13 AM, Erik Gilling  
>>> wrote:
 On Wed, Oct 2, 2013 at 12:35 AM, Maarten Lankhorst
  wrote:
> Depending on feedback I'll try reflashing my nexus 7 to stock android, 
> and work on trying to convert android
> syncpoints to dma-fence, which I'll probably rename to syncpoints.
 I thought the plan decided at plumbers was to investigate backing
 dma_buf with the android sync solution not the other way around.  It
 doesn't make sense to me to take a working, tested, end-to-end
 solution with a released compositing system built around it, throw it
 out, and replace it with new un-tested code to
 support a system which is not yet built.
>>> Hey Erik,
>>>   Thanks for the clarifying points in your email, your insights and
>>> feedback are critical, and I think having you and Maarten continue to
>>> work out the details here will make this productive.
>>>
>>> My recollection from the discussion was that Rob was ok with trying to
>>> pipe the sync arguments through the various interfaces in order to
>>> support the explicit sync, but I think he did suggest having it backed
>>> by the dma-buf fences underneath.
>>>
>>> I know this can be frustrating to watch things be reimplemented when
>>> you have a pre-baked solution, but some compromise will be needed to
>>> get things merged (and Maarten is taking the initiative here), but its
>>> important to keep discussing this so the *right* compromises are made
>>> that don't hurt performance, etc.
>>>
>>> My hope is Maarten's approach of getting the dma-fence core
>>> integrated, and then moving the existing Android sync interface over
>>> to the shared back-end, will allow for proper apples-to-apples
>>> comparisons of the same interface. And if the functionality isn't
>>> sufficient we can hold off on merging the sync interface conversion
>>> until that gets resolved.
>>>
>> Yeah, I'm trying to understand the android side too. I think a unified 
>> interface would benefit both. I'm
>> toying a bit with the sw_sync driver in staging because it's the easiest to 
>> try out on my desktop.
>>
>> The timeline stuff looks like it could be simplified. The main difference 
>> that there seems to be is that
>> I didn't want to create a separate timeline struct for synchronization but 
>> let the drivers handle it.
>>
>> If you use rcu for reference lifetime management of timeline, the kref can 
>> be dropped. Signalling all
>> syncpts on timeline destroy to a new destroyed state would kill the need for 
>> a destroyed member.
>> The active list is unneeded and can be killed if only a linear progression 
>> of child_list is allowed.
>>
>> Which probably leaves this nice structure:
>> struct sync_timeline {
>> const struct sync_timeline_ops*ops;
>> charname[32];
>>
>> struct list_headchild_list_head;
>> spinlock_tchild_list_lock;
>>
>> struct list_headsync_timeline_list;
>> };
>>
>> Where name, and sync_timeline_list are nice for debugging, but I guess not 
>> necessarily required. so that
>> could be split out into a separate debugfs thing if required. I've moved the 
>> pointer to ops to the fence
>> for dma-fence, which leaves this..
>>
>> struct sync_timeline {
>> struct list_headchild_list_head;
>> spinlock_tchild_list_lock;
>>
>> struct  sync_timeline_debug {
>> struct list_headsync_timeline_list;
>> char name[32];
>> };
>> };
>>
>> Hm, this looks familiar, the drm drivers had some structure for protecting 
>> the active fence list that has
>> an identical definition, but with a slightly different list offset..
>>
>> struct __wait_queue_head {
>> spinlock_t lock;
>> struct list_head task_list;
>> };
>>
>> typedef struct __wait_queue_head wait_queue_head_t;
>>
>> This is nicer to convert the existing drm drivers, which already implement 
>> synchronous wait with a waitqueue.
>> The default wait op is in fact
>>
>> Ok enough of this little excercise. I just wanted to see how different the 2 
>> are. I think even if the
>> fence interface will end up being incompatible it wouldn't be too hard to 
>> convert android..
>>
>> Main difference is the ops, android has a lot more than what I used for 
>> dma-fence:
>>
>> struct fence_ops {
>>  bool (*enable_signaling)(struct fence *fence); // required, callback 
>> called with fence->lock held,
>>  // fence->lock is a pointer passed to __fence_init. Callback should 
>> make sure that the fence will
>>  // be signaled asap.
>>  bool (*signaled)(struct fence *fence); // optional, but if set to NULL 
>> fence_is_signaled is not
>>  // required to ever return true, unless enable_signaling is called, 
>> similar to has_signaled
>>  long (*wait)(struct fence *fence, bool intr, signed long 

outcome of DRM/KMS DT bindings session

[Sascha Hauer]

On Tue, Oct 29, 2013 at 01:52:57PM +1000, Dave Airlie wrote:
> So we had a sessions at kernel summit to discuss the driver model and
> DT interactions for a display pipeline,
> 
> we had good attendance from a few sides and I hope to summarise the
> recommendations below,
> 
> a) Device Tree bindings
> 
> We should create a top-level virtual device binding that a top level
> driver can bind to, like alsa asoc does.
> 
> We should separate the CDF device tree model from CDF as a starting
> point and refine it outside of CDF, and produce a set of bindings that
> cover the current drivers we have, exynos, imx, tegra, msm, armada
> etc. This set of bindings should not be tied on CDF being merged or
> anything else.
> 
> Display pipelines should be modelered in the device tree, but the
> level of detail required for links between objects may be left up to
> the SoC developer, esp wrt tightly coupled SoCs.
> 
> Externally linked devices like bridges and panels should be explicitly linked.
> 
> b) Driver Model
> 
> The big thing here is that the device tree description we use should
> not dictate the driver model we use. This is the biggest thing I
> learned, so what does it mean?
> 
> We aren't required to write a device driver per device tree object.
> 
> We shouldn't be writing device drivers per device tree object.
> 
> For tightly-coupled SoCs where the blocks come from one vendor and are
> reused a lot, a top level driver should use the DT as configuration
> information source for the list of blocks it needs to initialise on
> the card, not as a list of separate drivers. There may be some
> external drivers required and the code should deal with this, like how
> alsa asoc does.
> 
> To share code between layers we should refactor it into a helper
> library not a separate driver, the kms/v4l/fbdev can use the library.
> 
> This should allow us to move forward a bit clearer esp with new
> drivers and following these recommendations, and I think porting
> current drivers to a sane model, especially exynos and imx.
> 
> Now I saw we here but I'm only going to be donating my use of a big
> stick and review abilities to making this happen, but I'm quite
> willing to enforce some of these rules going forward as I think it
> will make life easier.
> 
> After looking at some of the ordering issues we've had with x86 GPUs
> (which are really just a tightly coupled SoC) I don't want separate
> drivers all having their own init, suspend/resume paths in them as I
> know we'll have to start making special vtable entry points etc to
> solve some random ordering issues that crop up.

The DRM device has to be initialized/suspended/resumed as a whole, no
doubt about that. If that's not the case you indeed open up the door for
all kinds of ordering issues.

Still the different components can be multiple devices, just initialize
the drm device once all components are probed. Remove it again once a
component is removed. Handle suspend in the DRM device, not in
the individual component drivers. The suspend in the component drivers
would only be called after the DRM device is completely quiesced.
Similarly the resume in the component drivers would not reenable the
components, this instead would be done in the DRM device when all
components are there again.

This way all components could be proper (driver model)devices with
proper drivers without DRM even noticing that multiple components are
involved.

Side note: We have no choice anyway. All SoCs can (sometimes must)
be extended with external I2C devices. On every SoC the I2C bus master
is a separate device, so we have a multicomponent device (in the sense
of driver model) already in many cases.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[Bug 71046] GPU lockup on HD5470 with Brütal Legend

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71046

--- Comment #2 from Alex Deucher  ---
Does disabling hyperZ help?  Set env var R600_HYPERZ=0

This is probably a duplicate of bug 64471.

-- 
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/20131030/c96a6090/attachment.html>

[PATCH 2/2] drm/radeon: fix UVD destroy IB size

[Christian König]

From: Christian K?nig 

The parameter is in bytes not dwords.

Signed-off-by: Christian K?nig 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_uvd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index a56dfe4..ab0a172 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -622,7 +622,7 @@ static int radeon_uvd_send_msg(struct radeon_device *rdev,
if (r) 
goto err;

-   r = radeon_ib_get(rdev, ring, , NULL, 16);
+   r = radeon_ib_get(rdev, ring, , NULL, 64);
if (r)
goto err;

-- 
1.8.1.2

[PATCH 1/2] drm/radeon: activate UVD clocks before sending the destroy msg

[Christian König]

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
---
 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, );
if (r) {
-- 
1.8.1.2

[PATCH 2/2] simplefb: use write-combined remapping

[Tomi Valkeinen]

On 2013-10-30 09:49, David Herrmann wrote:
> Hi Tomi
> 
> Ping?

Thanks, queued this and the 1/2 patch for 3.13.

 Tomi

> 
> Thanks
> David
> 
> On Wed, Oct 2, 2013 at 4:58 PM, David Herrmann  
> wrote:
>> Framebuffers shouldn't be cached and it is usually very uncommon to read
>> them. Therefore, use ioremap_wc() to get significant speed improvements on
>> systems which provide it. On all other systems it's aliased to
>> ioremap_nocache() which is also fine.
>>
>> Reported-by: Tom Gundersen 
>> Signed-off-by: David Herrmann 
>> Tested-by: Tom Gundersen 
>> Tested-by: Alexandre Courbot 
>> Tested-by: Stephen Warren 
>> ---
>>  drivers/video/simplefb.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
>> index 74b016c..64db54a 100644
>> --- a/drivers/video/simplefb.c
>> +++ b/drivers/video/simplefb.c
>> @@ -219,8 +219,8 @@ static int simplefb_probe(struct platform_device *pdev)
>>
>> info->fbops = _ops;
>> info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
>> -   info->screen_base = ioremap(info->fix.smem_start,
>> -   info->fix.smem_len);
>> +   info->screen_base = ioremap_wc(info->fix.smem_start,
>> +  info->fix.smem_len);
>> if (!info->screen_base) {
>> framebuffer_release(info);
>> return -ENODEV;
>> --
>> 1.8.4
>>


------ next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131030/1adbb290/attachment.pgp>

outcome of DRM/KMS DT bindings session

[Thierry Reding]

On Tue, Oct 29, 2013 at 01:52:57PM +1000, Dave Airlie wrote:
> So we had a sessions at kernel summit to discuss the driver model and
> DT interactions for a display pipeline,
> 
> we had good attendance from a few sides and I hope to summarise the
> recommendations below,
> 
> a) Device Tree bindings
> 
> We should create a top-level virtual device binding that a top level
> driver can bind to, like alsa asoc does.
> 
> We should separate the CDF device tree model from CDF as a starting
> point and refine it outside of CDF, and produce a set of bindings that
> cover the current drivers we have, exynos, imx, tegra, msm, armada
> etc. This set of bindings should not be tied on CDF being merged or
> anything else.
> 
> Display pipelines should be modelered in the device tree, but the
> level of detail required for links between objects may be left up to
> the SoC developer, esp wrt tightly coupled SoCs.
> 
> Externally linked devices like bridges and panels should be explicitly linked.

According to the above, the device tree bindings for simple panels that
I proposed earlier should be fine. However there was so much controversy
involved that I've decided not to make that part of my pull request this
cycle. Also they haven't been reviewed by DT bindings maintainers yes,
so according to our new rules they cannot be merged.

I think Laurent was more or less fine with them too, although he had
some objections to how DSI panels were represented and wanted those to
be sub-nodes of the DSI controller. I'll see if I can come up with
something to address that.

We should probably aim for a common binding for things like DSI.

> b) Driver Model
> 
> The big thing here is that the device tree description we use should
> not dictate the driver model we use. This is the biggest thing I
> learned, so what does it mean?
> 
> We aren't required to write a device driver per device tree object.
> 
> We shouldn't be writing device drivers per device tree object.

I may remember this wrongly, but that's the opposite recommendation that
I got back when I started to work on Tegra DRM.

> For tightly-coupled SoCs where the blocks come from one vendor and are
> reused a lot, a top level driver should use the DT as configuration
> information source for the list of blocks it needs to initialise on
> the card, not as a list of separate drivers. There may be some
> external drivers required and the code should deal with this, like how
> alsa asoc does.
> 
> To share code between layers we should refactor it into a helper
> library not a separate driver, the kms/v4l/fbdev can use the library.
> 
> This should allow us to move forward a bit clearer esp with new
> drivers and following these recommendations, and I think porting
> current drivers to a sane model, especially exynos and imx.
> 
> Now I saw we here but I'm only going to be donating my use of a big
> stick and review abilities to making this happen, but I'm quite
> willing to enforce some of these rules going forward as I think it
> will make life easier.
> 
> After looking at some of the ordering issues we've had with x86 GPUs
> (which are really just a tightly coupled SoC) I don't want separate
> drivers all having their own init, suspend/resume paths in them as I
> know we'll have to start making special vtable entry points etc to
> solve some random ordering issues that crop up.

Where does that leave the Tegra driver? I've spent a significant amount
of time to get it to some sane state where having multiple subdrivers
are handled fairly nicely (in my opinion). Rewriting all of it isn't
something that I look forward to at all.

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/20131030/25a3cc71/attachment-0001.pgp>

[Bug 71046] GPU lockup on HD5470 with Brütal Legend

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71046

--- Comment #1 from Johannes Hirte  ---
Forgotten: kernel is 3.12-rc7 and mesa is from git.

-- 
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/20131030/7b53812a/attachment.html>

[Bug 71046] New: GPU lockup on HD5470 with Brütal Legend

[bugzilla-dae...@freedesktop.org]

 are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131030/a0ac0be7/attachment-0001.html>

vddc phase shedding in smc tables

[Alex Deucher]

On Tue, Oct 29, 2013 at 2:20 PM, Sylvain BERTRAND  wrote:
> Hi,
>
> git branch drm-fixes-3.12, git commit
> cdf6e8058415ba4d808537e30a0a6be9fb29e95a
>
> In si_dpm.c, the vddc phase shedding mask does overwrite the vddc
> voltage mask (lines 3889 and 3920 in
> si_populate_smc_voltage_tables function). Expected?

They are different tables (voltageMaskTable and phaseMaskTable),
unless I'm not understanding your question.

table->voltageMaskTable.lowMask[SISLANDS_SMC_VOLTAGEMASK_VDDC] =
cpu_to_be32(eg_pi->vddc_voltage_table.mask_low);

table->phaseMaskTable.lowMask[SISLANDS_SMC_VOLTAGEMASK_VDDC] =
cpu_to_be32(si_pi->vddc_phase_shed_table.mask_low);


Alex

>
>
> (my tahiti based board seems not to have vddc phase shedding,
> then I could not check if the 2 masks could work together).
>
> regards,
>
> --
> Sylvain
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/sysfs: Do not drop device reference twice

[Thierry Reding]

device_unregister() already drops its reference to the struct device, so
explicitly calling put_device() before device_unregister() can cause the
device to have been freed before it can be unregistered.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_sysfs.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index dae42c7..db1c8f9 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -439,7 +439,6 @@ err_out_files:
device_remove_file(connector->kdev, _attrs_opt1[i]);
for (i = 0; i < attr_cnt; i++)
device_remove_file(connector->kdev, _attrs[i]);
-   put_device(connector->kdev);
device_unregister(connector->kdev);

 out:
@@ -472,7 +471,6 @@ void drm_sysfs_connector_remove(struct drm_connector 
*connector)
for (i = 0; i < ARRAY_SIZE(connector_attrs); i++)
device_remove_file(connector->kdev, _attrs[i]);
sysfs_remove_bin_file(>kdev->kobj, _attr);
-   put_device(connector->kdev);
device_unregister(connector->kdev);
connector->kdev = NULL;
 }
-- 
1.8.4

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Sean Paul]

On Wed, Oct 30, 2013 at 11:45 AM, Laurent Pinchart
 wrote:
> On Wednesday 30 October 2013 11:32:24 Sean Paul wrote:
>> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
>> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
>
> [snip]
>
>> >> An example: exynos_drm_drv would be a platform_driver which implements
>> >> drm_driver. On drm_load, it would enumerate the various dt nodes for
>> >> its IP blocks and initialize them with direct calls (like
>> >> exynos_drm_fimd_initialize). If the board uses a bridge (say for
>> >> eDP->LVDS), that bridge driver would be a real driver with its own
>> >> probe.
>> >>
>> >> I think the ideal situation would be for the drm layer to manage the
>> >> standalone drivers in a way that is transparent to the main driver,
>> >> such that it doesn't need to know which type of hardware can hang off
>> >> it. It will need to know if one exists since it might need to forego
>> >> creating a connector, but it need not know anything else about it.
>> >>
>> >> To accomplish this, I think we need:
>> >> (1) Some way for drm to enumerate the standalone drivers, so it can
>> >> know when all of them have been probed
>> >>
>> >> (2) A drm registration function that's called by the standalone
>> >> drivers once they're probed, and a hook with drm_device pointer called
>> >> during drm_load for them to register their drm_* implementations
>> >>
>> >> (3) Something that will allow for deferred probe if the main driver
>> >> kicks off before the standalones are in, it would need to be called
>> >> before drm_platform/pci_init
>> >>
>> >> I think we'll need to expand on the media bindings to achieve (1).
>> >
>> > Could you elaborate on why you think so?
>> >
>> > I believe the video interface bindings contain everything needed for this
>> > case, except, of course, some device/bus specific parts, but those are to
>> > be defined by separate device/bus specific bindings.
>>
>> AFAICT, there is no way for drm to enumerate all of the pieces that
>> need probing before it loads (ie: how do you enumerate all device
>> nodes with pipe {} subnode[s]). I've given this more thought, and I
>> think the following could work without forcing unified/split drivers
>> (ie: it can be left to the driver author to choose).
>>
>> If there was some way for drm to know all of the pieces that need to
>> be probed/initialized before calling drm_load, it could provide an API
>> for various drivers to "claim" nodes. This API would accept the
>> device_node being claimed as well as an initialize hook that will be
>> called back to give the standalone driver a pointer to the drm_device.
>>
>> The main drm driver, which is responsible for calling
>> drm_platform/pci_init, would claim the nodes it plans on implementing
>> in the probe. It would then check drm to see if all requred nodes had
>> been claimed. If they have not been claimed, that probe would defer
>> and try again later.
>>
>> Once all required nodes have been "claimed", the main driver's probe
>> would call drm_platform/pci_init to kick off load(). After load() has
>> finished, the drm layer would then call the various standalone driver
>> hooks that were previously registered when it claimed its node. These
>> hooks would allow the driver to register its
>> crtc/encoder/bridge/connector.
>>
>> Multi-driver solutions could work within this framework, as could
>> integrated ones. This would also allow things like bridge drivers to
>> be completely transparent.
>
> Have you all configured your spam filters to reject anything that is or has
> been related to CDF ?
>
> Split in two patches, the first one adding the infrastructure, the second one
> adding OF support.
>
> http://git.linuxtv.org/pinchartl/fbdev.git/commitdiff/2d19e74ab8d86aaf5d54c34c6bc940508f793512
> http://git.linuxtv.org/pinchartl/fbdev.git/commitdiff/e8c4380ca4a6a62fa9d8bc340a6dcbd123b4f674
>
> The code can be extracted as a stand-alone solution, either specific to DRM,
> or at the struct device level. As the problem is not DRM-specific, the later
> would probably make more sense (if I'm not mistaken Grant Likely - CCed-
> mentioned during the kernel summit was in favor of adding the code in the
> device core).
>
> We've solved the exact same problem in V4L, do we *really* need to adopt the
> NIH approach and reinvent the wheel ?
>

Laurent,
I really don't care how the functionality gets in, or what form it
takes. This isn't NIH, I just want something that can be merged.

When we talked about CDF at plumbers, I thought the plan was to split
it up into the logical pieces and integrate it into drm. I haven't
seen any movement on this front, is that still your intention? If so,
I look forward to the patch.

Sean



>> I hope that made sense ;)
>
> --
> Regards,
>
> Laurent Pinchart
>

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Sean Paul]

On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa  wrote:
> Hi Sean,
>
> On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
>> On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa 
> wrote:
>> > Hi,
>> >
>> > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
>> >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie 
> wrote:
>> >> > I think we need to start considering a framework where
>> >> > subdrivers
>> >> > just
>> >> > add drm objects themselves, then the toplevel node is
>> >> > responsible
>> >> > for
>> >> > knowing that everything for the current configuration is
>> >> > loaded.
>> >> 
>> >>  It would be nice to specify the various pieces in dt, then have
>> >>  some
>> >>  type of drm notifier to the toplevel node when everything has
>> >>  been
>> >>  probed. Doing it in the dt would allow standalone
>> >>  drm_bridge/drm_panel
>> >>  drivers to be transparent as far as the device's drm driver is
>> >>  concerned.
>> >> 
>> >>  Sean
>> >> 
>> >> > I realise we may need to make changes to the core drm to allow
>> >> > this
>> >> > but we should probably start to create a strategy for fixing
>> >> > the
>> >> > API
>> >> > issues that this throws up.
>> >> >
>> >> > Note I'm not yet advocating for dynamic addition of nodes once
>> >> > the
>> >> > device is in use, or removing them.
>> >> >>>
>> >> >>> I do wonder if we had some sort of tag in the device tree for any
>> >> >>> nodes
>> >> >>> involved in the display, and the core drm layer would read that
>> >> >>> list,
>> >> >>> and when every driver registers tick things off, and when the
>> >> >>> last
>> >> >>> one
>> >> >>> joins we get a callback and init the drm layer, we'd of course
>> >> >>> have
>> >> >>> the
>> >> >>> basic drm layer setup prior to that so we can add the objects as
>> >> >>> the
>> >> >>> drivers load. It might make development a bit trickier as you'd
>> >> >>> need
>> >> >>> to make sure someone claimed ownership of all the bits for init
>> >> >>> to
>> >> >>> proceed.>>
>> >> >>
>> >> >> Yeah, that's basically what the strawman looked like in my head.
>> >> >>
>> >> >> Instead of a property in each node, I was thinking of having a
>> >> >> separate gfx pipe nodes that would have dt pointers to the various
>> >> >> pieces involved in that pipe. This would allow us to associate
>> >> >> standalone entities like bridges and panels with encoders in dt
>> >> >> w/o
>> >> >> doing it in the drm code. I *think* this should be Ok with the dt
>> >> >> guys
>> >> >> since it is still describing the hardware, but I think we'd have
>> >> >> to
>> >> >> make sure it wasn't drm-specific.
>> >> >
>> >> > I suppose the question is how much dynamic pipeline construction
>> >> > there
>> >> > is,
>> >> >
>> >> > even on things like radeon and i915 we have dynamic clock generator
>> >> > to
>> >> > crtc to encoder setups, so I worry about static lists per-pipe, so
>> >> > I
>> >> > still think just stating all these devices are needed for display
>> >> > and
>> >> > a list of valid interconnections between them, then we can have the
>> >> > generic code model drm crtc/encoders/connectors on that list, and
>> >> > construct the possible_crtcs /possible_clones etc at that stage.
>> >>
>> >> I'm, without excuse, hopeless at devicetree, so there are probably
>> >> some violations, but something like:
>> >>
>> >> display-pipelines {
>> >>
>> >>   required-elements = <   
>> >>
>> >>  >;
>> >>
>> >>   pipe1 {
>> >>
>> >> bridge = <>;
>> >> encoder = <>;
>> >> crtc = <>;
>> >>
>> >>   };
>> >>   pipe2 {
>> >>
>> >> encoder = <>;
>> >> crtc = <>;
>> >>
>> >>   };
>> >>   pipe3 {
>> >>
>> >> panel = <>;
>> >> encoder = <>;
>> >> crtc = <>;
>> >>
>> >>   };
>> >>
>> >> };
>> >>
>> >> I'm tempted to add connector to the pipe nodes as well, so it's
>> >> obvious which connector should be used in cases where multiple
>> >> entities in the pipe implement drm_connector. However, I'm not sure
>> >> if
>> >> that would be NACKed by dt people.
>> >>
>> >> I'm also not sure if there are too many combinations for i915 and
>> >> radeon to make this unreasonable. I suppose those devices could just
>> >> use required-elements and leave the pipe nodes out.
>> >
>> > Just to put my two cents in, as one of the people involved into "the
>> > device tree movement", I'd say that instead of creating artifical
>> > entities, such as display-pipelines and all of the pipeX'es, device
>> > tree should represent relations between nodes.
>> >
>> > According to the generic DT bindings we already have for
>> > video-interfaces
>> > [1] your example connection layout would look as follows:
>> Hi Tomasz
>> Thanks for sending this along.
>>
>> I think the general consensus is that each drm driver should be
>> implemented as a singular driver. That is, N:1 binding to driver
>> mapping, where there are N IP blocks. Optional devices 

[PATCH] drm/sysfs: Do not drop device reference twice

[Ben Widawsky]

On Wed, Oct 30, 2013 at 11:59:05AM +0100, Thierry Reding wrote:
> device_unregister() already drops its reference to the struct device, so
> explicitly calling put_device() before device_unregister() can cause the
> device to have been freed before it can be unregistered.
> 
> Signed-off-by: Thierry Reding 

Thanks for fixing this. It was driving me nuts.
Tested-by: Ben Widawsky 

[snip]
-- 
Ben Widawsky, Intel Open Source Technology Center

[git pull] drm intel fixes

[Dave Airlie]

Hi Linus,

mainly Intel regression fixes and quirks, along with a simple one liner to 
fix rendernodes ioctl access (off by default, but testers want to test 
it).

Dave.

The following changes since commit 7314e613d5ff9f0934f7a0f74ed7973b903315d1:

  Fix a few incorrectly checked [io_]remap_pfn_range() calls (2013-10-29 
10:21:34 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 3d3b78c06c827bfc072a11056d7eb70aeb90e449:

  drm: allow DRM_IOCTL_VERSION on render-nodes (2013-10-30 14:41:56 +1000)


Daniel Vetter (1):
  drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb

Dave Airlie (1):
  Merge tag 'drm-intel-fixes-2013-10-29' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

David Herrmann (1):
  drm: allow DRM_IOCTL_VERSION on render-nodes

Jani Nikula (1):
  drm/i915/dp: workaround BIOS eDP bpp clamping issue

Rob Pearce (1):
  drm/i915: No LVDS hardware on Intel D410PT and D425KT

Ville Syrj?l? (2):
  drm/i915: Add support for pipe_bpp readout
  drm/i915: Add HSW CRT output readout support

 drivers/gpu/drm/drm_drv.c|   2 +-
 drivers/gpu/drm/i915/intel_crt.c |  30 ++--
 drivers/gpu/drm/i915/intel_ddi.c |  21 +-
 drivers/gpu/drm/i915/intel_display.c | 131 ++-
 drivers/gpu/drm/i915/intel_dp.c  |  20 ++
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_lvds.c|  16 +
 7 files changed, 168 insertions(+), 54 deletions(-)

[PATCH] drm/radeon: don't use PACKET2 on CIK

[Alex Deucher]

On Wed, Oct 30, 2013 at 9:41 AM, Marek Ol??k  wrote:
> From: Marek Ol??k 
>
> It is said to cause hangs.
>
> Signed-off-by: Marek Ol??k 


Applied!  Thanks.

> ---
>  drivers/gpu/drm/radeon/cik.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 2cd2ac0..44507a4 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -7134,7 +7134,7 @@ static int cik_startup(struct radeon_device *rdev)
> ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
> r = radeon_ring_init(rdev, ring, ring->ring_size, 
> RADEON_WB_CP_RPTR_OFFSET,
>  CP_RB0_RPTR, CP_RB0_WPTR,
> -RADEON_CP_PACKET2);
> +PACKET3(PACKET3_NOP, 0x3FFF));
> if (r)
> return r;
>
> --
> 1.8.1.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/radeon: activate UVD clocks before sending the destroy msg

[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!

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, );
> if (r) {
> --
> 1.8.1.2
>

[PATCH] drm/radeon: don't use PACKET2 on CIK

[Alex Deucher]

On Wed, Oct 30, 2013 at 9:50 AM, Christian K?nig
 wrote:
> Am 30.10.2013 14:41, schrieb Marek Ol??k:
>
>> From: Marek Ol??k 
>>
>> It is said to cause hangs.
>>
>> Signed-off-by: Marek Ol??k 
>
>
> We should probably do so for SI as well.
>

SI doesn't support single DW type 3 nop packets and AFAIK, there are
no bugs with type 2 packet handling on SI.

Alex

> Patch is Reviewed-by: Christian K?nig 
>
>
>> ---
>>   drivers/gpu/drm/radeon/cik.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
>> index 2cd2ac0..44507a4 100644
>> --- a/drivers/gpu/drm/radeon/cik.c
>> +++ b/drivers/gpu/drm/radeon/cik.c
>> @@ -7134,7 +7134,7 @@ static int cik_startup(struct radeon_device *rdev)
>> ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
>> r = radeon_ring_init(rdev, ring, ring->ring_size,
>> RADEON_WB_CP_RPTR_OFFSET,
>>  CP_RB0_RPTR, CP_RB0_WPTR,
>> -RADEON_CP_PACKET2);
>> +PACKET3(PACKET3_NOP, 0x3FFF));
>> if (r)
>> return r;
>>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/ttm: Handle in memory region copies

[Thomas Hellstrom]

On 10/18/2013 03:18 PM, Jakob Bornecrantz wrote:
> Reviewed-by: Thomas Hellstr?m 
> Signed-off-by: Jakob Bornecrantz 
> Cc: Dave Airlie 
> Cc: dri-devel at lists.freedesktop.org
> Cc: stable at vger.kernel.org
> ---
>   drivers/gpu/drm/ttm/ttm_bo_util.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 8be35c8..037f101 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -342,7 +342,9 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
>   if (old_iomap == NULL && ttm == NULL)
>   goto out2;
>   
> - if (ttm->state == tt_unpopulated) {
> + /* TTM might be null for moves within the same region.
> +  */
> + if (ttm && ttm->state == tt_unpopulated) {
>   ret = ttm->bdev->driver->ttm_tt_populate(ttm);
>   if (ret) {
>   /* if we fail here don't nuke the mm node

LGTM. There are a couple of other fixes needed in this function as well.

/Thomas

[PATCH 2/2] simplefb: use write-combined remapping

[David Herrmann]

Hi Tomi

Ping?

Thanks
David

On Wed, Oct 2, 2013 at 4:58 PM, David Herrmann  wrote:
> Framebuffers shouldn't be cached and it is usually very uncommon to read
> them. Therefore, use ioremap_wc() to get significant speed improvements on
> systems which provide it. On all other systems it's aliased to
> ioremap_nocache() which is also fine.
>
> Reported-by: Tom Gundersen 
> Signed-off-by: David Herrmann 
> Tested-by: Tom Gundersen 
> Tested-by: Alexandre Courbot 
> Tested-by: Stephen Warren 
> ---
>  drivers/video/simplefb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
> index 74b016c..64db54a 100644
> --- a/drivers/video/simplefb.c
> +++ b/drivers/video/simplefb.c
> @@ -219,8 +219,8 @@ static int simplefb_probe(struct platform_device *pdev)
>
> info->fbops = _ops;
> info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
> -   info->screen_base = ioremap(info->fix.smem_start,
> -   info->fix.smem_len);
> +   info->screen_base = ioremap_wc(info->fix.smem_start,
> +  info->fix.smem_len);
> if (!info->screen_base) {
> framebuffer_release(info);
> return -ENODEV;
> --
> 1.8.4
>

[PATCH 1/2] simplefb: fix unmapping fb during destruction

[David Herrmann]

Hi Tomi

Could we get this in -next before the merge-window starts? Stephen
already ack'ed it.

Thanks
David

On Wed, Oct 2, 2013 at 6:23 PM, David Herrmann  wrote:
> Hi
>
> On Wed, Oct 2, 2013 at 6:16 PM, Stephen Warren  
> wrote:
>> On 10/02/2013 08:58 AM, David Herrmann wrote:
>>> Unfortunately, fbdev does not create its own "struct device" for
>>> framebuffers. Instead, it attaches to the device of the parent layer. This
>>> has the side-effect that devm_* managed resources are not cleaned up on
>>> framebuffer-destruction but rather during destruction of the
>>> parent-device. In case of fbdev this might be too late, though.
>>> remove_conflicting_framebuffer() may remove fbdev devices but keep the
>>> parent device as it is.
>>>
>>> Therefore, we now use plain ioremap() and unmap the framebuffer in the
>>> fb_destroy() callback. Note that we must not free the device here as this
>>> might race with the parent-device removal. Instead, we rely on
>>> unregister_framebuffer() as barrier and we're safe.
>>
>> So, once the .fb_destroy callback has been executed, there's no other
>> callback to resurrect it? The framebuffer itself is still registered
>> until the device's remove, yet after .fb_destroy, the memory is
>> unmapped, which would be dangerous if the FB can be re-started.
>
> fbdev lifetime tracking is weird.. ->fb_destroy() is called by
> unregister_framebuffer() _after_ it got unlinked. So no, the
> framebuffer is gone and cannot be resurrected. However, the
> unregistered/dead fbdev object itself stays around until you call
> framebuffer_release(). We cannot call it from fb_destroy(), though as
> the platform_data in your platform device still points to the fbdev
> device. Therefore we keep it and wait for the platform-driver to be
> removed which then again calls unregister_framebuffer() (which will
> immediately return as the fbdev device is not registered) and then you
> can finally call framebuffer_release().
>
> Note that even though there's fb_get_info() and fb_put_info(), both
> are not exported and never used. So there is *no* fbdev ref-counting
> (which would be horribly broken anyway) and the driver is the sole
> owner of the fbdev object.
>
>> If that's not an issue, this patch seems fine, so
>> Acked-by: Stephen Warren 
>
> Thanks!
>
>>> I know that simplefb was supposed to stay "as simple as possible" but I 
>>> really
>>> think this series is the last set of fixes I have. Unfortunately 
>>> framebuffer DRM
>>> handover is mandatory so we cannot ignore it in simplefb.
>>
>> I don't think this patch adds any significant complexity, so I'm not
>> worried at least.
>
> Good to hear!
>
> Thanks
> David

fix for CRTC mutex corruption

[Ilija Hadzic]

On Tue, 29 Oct 2013, Daniel Vetter wrote:

> Oh right, I've forgotten that between the review and writing the mail
> ;-) I guess we could try to bend the stable rules a bit and just
> submit all 6. It's a regression fix after all, and at least personally
> I prefer the most minimal backports to avoid diverging between
> upstream and stable kernel branches.
>
> But I guess that's Dave's call to make.
>

How about taking the patch series into drm-next and marking patch #6 only 
with CC: stable@ and specifying hashes of the prerequisite 5 patches for 
cherry-pick?

I think that is fully compliant with stable rules (at least that's my 
understanding of line 41 of Documentation/stable_kernel_rules.txt) and 
would not be bending anything.

I presume that if this is acceptable, Dave would have to add stable@ tags 
for cherry-picking because hash values may change in his tree if drm-next 
changes relative to my base (which is state of drm-next as of yesterday 
PM).

-- Ilija

[git pull] drm intel fixes

[Alex Deucher]

On Wed, Oct 30, 2013 at 6:58 AM, Dave Airlie  wrote:
>
> Hi Linus,
>
> mainly Intel regression fixes and quirks, along with a simple one liner to
> fix rendernodes ioctl access (off by default, but testers want to test
> it).
>
> Dave.

Hi Dave,

I think you missed my fixes pull for radeon from last week:
http://lists.freedesktop.org/archives/dri-devel/2013-October/047873.html

Can we get that pulled in as well?

Alex

>
> The following changes since commit 7314e613d5ff9f0934f7a0f74ed7973b903315d1:
>
>   Fix a few incorrectly checked [io_]remap_pfn_range() calls (2013-10-29 
> 10:21:34 -0700)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~airlied/linux drm-fixes
>
> for you to fetch changes up to 3d3b78c06c827bfc072a11056d7eb70aeb90e449:
>
>   drm: allow DRM_IOCTL_VERSION on render-nodes (2013-10-30 14:41:56 +1000)
>
> 
> Daniel Vetter (1):
>   drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb
>
> Dave Airlie (1):
>   Merge tag 'drm-intel-fixes-2013-10-29' of 
> git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
>
> David Herrmann (1):
>   drm: allow DRM_IOCTL_VERSION on render-nodes
>
> Jani Nikula (1):
>   drm/i915/dp: workaround BIOS eDP bpp clamping issue
>
> Rob Pearce (1):
>   drm/i915: No LVDS hardware on Intel D410PT and D425KT
>
> Ville Syrj?l? (2):
>   drm/i915: Add support for pipe_bpp readout
>   drm/i915: Add HSW CRT output readout support
>
>  drivers/gpu/drm/drm_drv.c|   2 +-
>  drivers/gpu/drm/i915/intel_crt.c |  30 ++--
>  drivers/gpu/drm/i915/intel_ddi.c |  21 +-
>  drivers/gpu/drm/i915/intel_display.c | 131 
> ++-
>  drivers/gpu/drm/i915/intel_dp.c  |  20 ++
>  drivers/gpu/drm/i915/intel_drv.h |   2 +
>  drivers/gpu/drm/i915/intel_lvds.c|  16 +
>  7 files changed, 168 insertions(+), 54 deletions(-)
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 1/2] drm: Do not drop root privileges for a fancier younger process

[David Herrmann]

Hi

On Tue, Oct 29, 2013 at 9:55 AM, Chris Wilson  
wrote:
> When a second process opens the device and master transferrence is
> complete, we walk the list of open devices and remove their
> authentication. This also revokes our root privilege. Instead of simply
> dropping the authentication, this patch reverts the authenticated state
> back to its original value.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/drm_fops.c | 5 +++--
>  include/drm/drmP.h | 1 +
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index da1940ae9a2d..2f8b41c58d02 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -239,7 +239,8 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
>
> priv->ioctl_count = 0;
> /* for compatibility root is always authenticated */
> -   priv->authenticated = capable(CAP_SYS_ADMIN);
> +   priv->always_authenticated = capable(CAP_SYS_ADMIN);
> +   priv->authenticated = priv->always_authenticated;
> priv->lock_count = 0;
>
> INIT_LIST_HEAD(>lhead);
> @@ -523,7 +524,7 @@ int drm_release(struct inode *inode, struct file *filp)
> list_for_each_entry(temp, >filelist, lhead) {
> if ((temp->master == file_priv->master) &&
> (temp != file_priv))
> -   temp->authenticated = 0;
> +   temp->authenticated = 
> temp->always_authenticated;
> }
>
> /**
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 490534c990b7..3a90857bd0ee 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -412,6 +412,7 @@ struct drm_prime_file_private {
>
>  /** File private data */
>  struct drm_file {
> +   int always_authenticated;
> int authenticated;

I was going to say you can reuse "authenticated" here as it's an
"int". But your follow-up fixes this I think. Apart from that:
Reviewed-by: David Herrmann 

Please also tag this for stable via: Cc: 
Thanks
David

> struct pid *pid;
> kuid_t uid;
> --
> 1.8.4.rc3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 70715] radeonsi - Al textures are black in Football Manager 2014 in the 3D match

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=70715

Mike Lothian  changed:

   What|Removed |Added

 CC||mike at fireburn.co.uk

--- Comment #6 from Mike Lothian  ---
>From what I've read else where this isn't a rendering bug but is actually a
localisation one. 

There is a cache with floating point numbers in but on systems where the
decimal point isn't used to separate numbers the data isn't interpreted
properly

Try clearing the cache and launching the game with LC_MESSAGES=c

The above is from memory so it might be worth googling the solution if that
doesn't work

-- 
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/20131030/40022f7c/attachment.html>

[PATCH 4/4] drm/intel: Push get_scanout_position() timestamping into kms driver.

[Mario Kleiner]

Move the ktime_get() clock readouts and potential preempt_disable()
calls from drm core into kms driver to make it compatible with the
api changes in the drm core.

The intel-kms driver needs to take the uncore.lock inside
i915_get_crtc_scanoutpos() and intel_pipe_in_vblank().
This is incompatible with the preempt_disable() on a
PREEMPT_RT patched kernel, as regular spin locks must not
be taken within a preempt_disable'd section. Lock contention
on the uncore.lock also introduced too much uncertainty in vblank
timestamps.

Push the ktime_get() timestamping for scanoutpos queries and
potential preempt_disable_rt() into i915_get_crtc_scanoutpos(),
so these problems can be avoided:

1. First lock the uncore.lock (might sleep on a PREEMPT_RT kernel).
2. preempt_disable_rt() (will be added by the rt-linux folks).
3. ktime_get() a timestamp before scanout pos query.
4. Do all mmio reads as fast as possible without grabbing any new locks!
5. ktime_get() a post-query timestamp.
6. preempt_enable_rt()
7. Unlock the uncore.lock.

This reduces timestamp uncertainty on a low-end HP Atom Mini netbook
with Intel GMA-950 nicely:

Before: 3-8 usecs with spikes > 20 usecs, triggering query retries.
After : Typically 1 usec (98% of all samples), occassionally 2 usecs
(2% of all samples), with maximum of 3 usecs (a handful).

v2: Fix formatting of new multi-line code comments.

Signed-off-by: Mario Kleiner 
Reviewed-by: Ville Syrj?l? 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/i915/i915_irq.c |   54 +++
 1 file changed, 43 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 156a1a4..7cafe64 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -599,35 +599,40 @@ static u32 gm45_get_vblank_counter(struct drm_device 
*dev, int pipe)
return I915_READ(reg);
 }

-static bool intel_pipe_in_vblank(struct drm_device *dev, enum pipe pipe)
+/* raw reads, only for fast reads of display block, no need for forcewake etc. 
*/
+#define __raw_i915_read32(dev_priv__, reg__) readl((dev_priv__)->regs + 
(reg__))
+#define __raw_i915_read16(dev_priv__, reg__) readw((dev_priv__)->regs + 
(reg__))
+
+static bool intel_pipe_in_vblank_locked(struct drm_device *dev, enum pipe pipe)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
uint32_t status;
+   int reg;

if (IS_VALLEYVIEW(dev)) {
status = pipe == PIPE_A ?
I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT :
I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;

-   return I915_READ(VLV_ISR) & status;
+   reg = VLV_ISR;
} else if (IS_GEN2(dev)) {
status = pipe == PIPE_A ?
I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT :
I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;

-   return I915_READ16(ISR) & status;
+   reg = ISR;
} else if (INTEL_INFO(dev)->gen < 5) {
status = pipe == PIPE_A ?
I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT :
I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;

-   return I915_READ(ISR) & status;
+   reg = ISR;
} else if (INTEL_INFO(dev)->gen < 7) {
status = pipe == PIPE_A ?
DE_PIPEA_VBLANK :
DE_PIPEB_VBLANK;

-   return I915_READ(DEISR) & status;
+   reg = DEISR;
} else {
switch (pipe) {
default:
@@ -642,12 +647,17 @@ static bool intel_pipe_in_vblank(struct drm_device *dev, 
enum pipe pipe)
break;
}

-   return I915_READ(DEISR) & status;
+   reg = DEISR;
}
+
+   if (IS_GEN2(dev))
+   return __raw_i915_read16(dev_priv, reg) & status;
+   else
+   return __raw_i915_read32(dev_priv, reg) & status;
 }

 static int i915_get_crtc_scanoutpos(struct drm_device *dev, int pipe,
-int *vpos, int *hpos)
+int *vpos, int *hpos, ktime_t *stime, ktime_t 
*etime)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
@@ -657,6 +667,7 @@ static int i915_get_crtc_scanoutpos(struct drm_device *dev, 
int pipe,
int vbl_start, vbl_end, htotal, vtotal;
bool in_vbl = true;
int ret = 0;
+   unsigned long irqflags;

if (!intel_crtc->active) {
DRM_DEBUG_DRIVER("trying to get scanoutpos for disabled "
@@ -671,14 +682,27 @@ static int i915_get_crtc_scanoutpos(struct drm_device 
*dev, int pipe,

ret |= DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE;

+   /*
+* Lock uncore.lock, as we will do multiple timing critical raw
+* register reads, potentially with preemption 

[PATCH 3/4] drm/radeon: Push get_scanout_position() timestamping into kms driver.

[Mario Kleiner]

Move the ktime_get() clock readouts and potential preempt_disable()
calls from drm core into kms driver to make it compatible with the
api changes in the drm core.

This should not introduce any change in functionality or behaviour
in radeon-kms, just a reshuffling of code.

Signed-off-by: Mario Kleiner 
Reviewed-by: Ville Syrj?l? 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_display.c |   24 +---
 drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
 drivers/gpu/drm/radeon/radeon_mode.h|3 ++-
 drivers/gpu/drm/radeon/radeon_pm.c  |2 +-
 4 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 0d1aa05..ccd8751 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -306,7 +306,7 @@ void radeon_crtc_handle_flip(struct radeon_device *rdev, 
int crtc_id)
 */
if (update_pending &&
(DRM_SCANOUTPOS_VALID & radeon_get_crtc_scanoutpos(rdev->ddev, 
crtc_id,
-  , )) &&
+  , , 
NULL, NULL)) &&
((vpos >= (99 * 
rdev->mode_info.crtcs[crtc_id]->base.hwmode.crtc_vdisplay)/100) ||
 (vpos < 0 && !ASIC_IS_AVIVO(rdev {
/* crtc didn't flip in this target vblank interval,
@@ -1539,12 +1539,17 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc 
*crtc,
 }

 /*
- * Retrieve current video scanout position of crtc on a given gpu.
+ * Retrieve current video scanout position of crtc on a given gpu, and
+ * an optional accurate timestamp of when query happened.
  *
  * \param dev Device to query.
  * \param crtc Crtc to query.
  * \param *vpos Location where vertical scanout position should be stored.
  * \param *hpos Location where horizontal scanout position should go.
+ * \param *stime Target location for timestamp taken immediately before
+ *   scanout position query. Can be NULL to skip timestamp.
+ * \param *etime Target location for timestamp taken immediately after
+ *   scanout position query. Can be NULL to skip timestamp.
  *
  * Returns vpos as a positive number while in active scanout area.
  * Returns vpos as a negative number inside vblank, counting the number
@@ -1560,7 +1565,8 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc *crtc,
  * unknown small number of scanlines wrt. real scanout position.
  *
  */
-int radeon_get_crtc_scanoutpos(struct drm_device *dev, int crtc, int *vpos, 
int *hpos)
+int radeon_get_crtc_scanoutpos(struct drm_device *dev, int crtc, int *vpos, 
int *hpos,
+  ktime_t *stime, ktime_t *etime)
 {
u32 stat_crtc = 0, vbl = 0, position = 0;
int vbl_start, vbl_end, vtotal, ret = 0;
@@ -1568,6 +1574,12 @@ int radeon_get_crtc_scanoutpos(struct drm_device *dev, 
int crtc, int *vpos, int

struct radeon_device *rdev = dev->dev_private;

+   /* preempt_disable_rt() should go right here in PREEMPT_RT patchset. */
+
+   /* Get optional system timestamp before query. */
+   if (stime)
+   *stime = ktime_get();
+
if (ASIC_IS_DCE4(rdev)) {
if (crtc == 0) {
vbl = RREG32(EVERGREEN_CRTC_V_BLANK_START_END +
@@ -1650,6 +1662,12 @@ int radeon_get_crtc_scanoutpos(struct drm_device *dev, 
int crtc, int *vpos, int
}
}

+   /* Get optional system timestamp after query. */
+   if (etime)
+   *etime = ktime_get();
+
+   /* preempt_enable_rt() should go right here in PREEMPT_RT patchset. */
+
/* Decode into vertical and horizontal scanout position. */
*vpos = position & 0x1fff;
*hpos = (position >> 16) & 0x1fff;
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 22f6858..101e7c0 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -106,7 +106,8 @@ int radeon_gem_object_open(struct drm_gem_object *obj,
 void radeon_gem_object_close(struct drm_gem_object *obj,
struct drm_file *file_priv);
 extern int radeon_get_crtc_scanoutpos(struct drm_device *dev, int crtc,
- int *vpos, int *hpos);
+ int *vpos, int *hpos, ktime_t *stime,
+ ktime_t *etime);
 extern const struct drm_ioctl_desc radeon_ioctls_kms[];
 extern int radeon_max_kms_ioctl;
 int radeon_mmap(struct file *filp, struct vm_area_struct *vma);
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index ef63d3f..3bfa910 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -758,7 +758,8 @@ extern int radeon_crtc_cursor_move(struct drm_crtc *crtc,
   

[PATCH 2/4] drm: Push latency sensitive bits of vblank scanoutpos timestamping into kms drivers.

[Mario Kleiner]

A change in locking of some kms drivers (currently intel-kms) make
the old approach too inaccurate and also incompatible with the
PREEMPT_RT realtime kernel patchset.

The driver->get_scanout_position() method of intel-kms now needs
to aquire a spinlock, which clashes badly with the former
preempt_disable() calls in the drm, and it also introduces larger
delays and timing uncertainty on a contended lock than acceptable.

This patch changes the prototype of driver->get_scanout_position()
to require/allow kms drivers to perform the ktime_get() system time
queries which go along with actual scanout position readout in a way
that provides maximum precision and to return those timestamps to
the drm. kms drivers implementations of get_scanout_position() are
asked to implement timestamping and scanoutpos readout in a way
that is as precise as possible and compatible with preempt_disable()
on a PREMPT_RT kernel. A driver should follow this pattern in
get_scanout_position() for precision and compatibility:

spin_lock...(...);
preempt_disable_rt(); // On a PREEMPT_RT kernel, otherwise omit.
if (stime) *stime = ktime_get();
... Minimum amount of MMIO register reads to get scanout position ...
... no taking of locks allowed here! ...
if (etime) *etime = ktime_get();
preempt_enable_rt(); // On PREEMPT_RT kernel, otherwise omit.
spin_unlock...(...);

v2: Fix formatting of new multi-line code comments.

Signed-off-by: Mario Kleiner 
Reviewed-by: Ville Syrj?l? 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/drm_irq.c |   20 
 include/drm/drmP.h|   10 --
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 33ee515..d80d952 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -219,7 +219,7 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
for (i = 0; i < num_crtcs; i++)
init_waitqueue_head(>vblank[i].queue);

-   DRM_INFO("Supports vblank timestamp caching Rev 1 (10.10.2010).\n");
+   DRM_INFO("Supports vblank timestamp caching Rev 2 (21.10.2013).\n");

/* Driver specific high-precision vblank timestamping supported? */
if (dev->driver->get_vblank_timestamp)
@@ -586,14 +586,17 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev, int crtc,
 * code gets preempted or delayed for some reason.
 */
for (i = 0; i < DRM_TIMESTAMP_MAXRETRIES; i++) {
-   /* Get system timestamp before query. */
-   stime = ktime_get();
-
-   /* Get vertical and horizontal scanout pos. vpos, hpos. */
-   vbl_status = dev->driver->get_scanout_position(dev, crtc, 
, );
+   /*
+* Get vertical and horizontal scanout position vpos, hpos,
+* and bounding timestamps stime, etime, pre/post query.
+*/
+   vbl_status = dev->driver->get_scanout_position(dev, crtc, ,
+  , , 
);

-   /* Get system timestamp after query. */
-   etime = ktime_get();
+   /*
+* Get correction for CLOCK_MONOTONIC -> CLOCK_REALTIME if
+* CLOCK_REALTIME is requested.
+*/
if (!drm_timestamp_monotonic)
mono_time_offset = ktime_get_monotonic_offset();

@@ -604,6 +607,7 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device 
*dev, int crtc,
return -EIO;
}

+   /* Compute uncertainty in timestamp of scanout position query. 
*/
duration_ns = ktime_to_ns(etime) - ktime_to_ns(stime);

/* Accept result with <  max_error nsecs timing uncertainty. */
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2b954ad..48d15f0 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -835,12 +835,17 @@ struct drm_driver {
/**
 * Called by vblank timestamping code.
 *
-* Return the current display scanout position from a crtc.
+* Return the current display scanout position from a crtc, and an
+* optional accurate ktime_get timestamp of when position was measured.
 *
 * \param dev  DRM device.
 * \param crtc Id of the crtc to query.
 * \param *vpos Target location for current vertical scanout position.
 * \param *hpos Target location for current horizontal scanout position.
+* \param *stime Target location for timestamp taken immediately before
+*   scanout position query. Can be NULL to skip timestamp.
+* \param *etime Target location for timestamp taken immediately after
+*   scanout position query. Can be NULL to skip timestamp.
 *
 * Returns vpos as a positive number while in active scanout area.
 * Returns vpos as 

[PATCH 1/4] drm: Remove preempt_disable() from vblank timestamping code.

[Mario Kleiner]

Preemption handling will get pushed into the kms
drivers in followup patches, to make timestamping
more robust and PREEMPT_RT friendly.

Signed-off-by: Mario Kleiner 
Reviewed-by: Ville Syrj?l? 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/drm_irq.c |7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index f9af048..33ee515 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -586,11 +586,6 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev, int crtc,
 * code gets preempted or delayed for some reason.
 */
for (i = 0; i < DRM_TIMESTAMP_MAXRETRIES; i++) {
-   /* Disable preemption to make it very likely to
-* succeed in the first iteration even on PREEMPT_RT kernel.
-*/
-   preempt_disable();
-
/* Get system timestamp before query. */
stime = ktime_get();

@@ -602,8 +597,6 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device 
*dev, int crtc,
if (!drm_timestamp_monotonic)
mono_time_offset = ktime_get_monotonic_offset();

-   preempt_enable();
-
/* Return as no-op if scanout query unsupported or failed. */
if (!(vbl_status & DRM_SCANOUTPOS_VALID)) {
DRM_DEBUG("crtc %d : scanoutpos query failed [%d].\n",
-- 
1.7.10.4

Vblank timestamping improvements/fixes for Linux drm. [v2]

[Mario Kleiner]

Hi Dave,

this is v2 of the patch set for improving/restoring accuracy and
robustness of vblank timestamping and for fixing incompatibilities
with the PREEMPT_RT patches.

Could you please merge this for the next kernel? Would be good to have
the old accuracy restored as soon as possible. Thanks.

v2: Added the reviewed-by's of Ville and Alex, thanks for the review!
Fixed multi-line code formatting as suggested by Ville.

Successfully tested on Intel and AMD Radeon hardware.

thanks,
-mario

[PATCH 2/2] drm/ttm: Fix memory type compatibility check

[Thomas Hellstrom]

Also check the busy placements before deciding to move a buffer object.
Failing to do this may result in a completely unneccessary move within a
single memory type.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/ttm/ttm_bo.c |   32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f1a857e..7298053 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -986,24 +986,32 @@ out_unlock:
return ret;
 }

-static int ttm_bo_mem_compat(struct ttm_placement *placement,
-struct ttm_mem_reg *mem)
+static bool ttm_bo_mem_compat(struct ttm_placement *placement,
+ struct ttm_mem_reg *mem,
+ uint32_t *new_flags)
 {
int i;

if (mem->mm_node && placement->lpfn != 0 &&
(mem->start < placement->fpfn ||
 mem->start + mem->num_pages > placement->lpfn))
-   return -1;
+   return false;

for (i = 0; i < placement->num_placement; i++) {
-   if ((placement->placement[i] & mem->placement &
-   TTM_PL_MASK_CACHING) &&
-   (placement->placement[i] & mem->placement &
-   TTM_PL_MASK_MEM))
-   return i;
+   *new_flags = placement->placement[i];
+   if ((*new_flags & mem->placement & TTM_PL_MASK_CACHING) &&
+   (*new_flags & mem->placement & TTM_PL_MASK_MEM))
+   return true;
+   }
+
+   for (i = 0; i < placement->num_busy_placement; i++) {
+   *new_flags = placement->busy_placement[i];
+   if ((*new_flags & mem->placement & TTM_PL_MASK_CACHING) &&
+   (*new_flags & mem->placement & TTM_PL_MASK_MEM))
+   return true;
}
-   return -1;
+
+   return false;
 }

 int ttm_bo_validate(struct ttm_buffer_object *bo,
@@ -1012,6 +1020,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
bool no_wait_gpu)
 {
int ret;
+   uint32_t new_flags;

lockdep_assert_held(>resv->lock.base);
/* Check that range is valid */
@@ -1022,8 +1031,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
/*
 * Check whether we need to move buffer.
 */
-   ret = ttm_bo_mem_compat(placement, >mem);
-   if (ret < 0) {
+   if (!ttm_bo_mem_compat(placement, >mem, _flags)) {
ret = ttm_bo_move_buffer(bo, placement, interruptible,
 no_wait_gpu);
if (ret)
@@ -1033,7 +1041,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
 * Use the access and other non-mapping-related flag bits from
 * the compatible memory placement flags to the active flags
 */
-   ttm_flag_masked(>mem.placement, placement->placement[ret],
+   ttm_flag_masked(>mem.placement, new_flags,
~TTM_PL_MASK_MEMTYPE);
}
/*
-- 
1.7.10.4

[PATCH 1/2] drm/ttm: Fix ttm_bo_move_memcpy

[Thomas Hellstrom]

All error paths will want to keep the mm node, so handle this at the
function exit. This fixes an ioremap failure error path.
Also add some comments to make the function a bit easier to understand.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/ttm/ttm_bo_util.c |   28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 8369e35..4834c46 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -343,21 +343,25 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
if (ret)
goto out;

+   /*
+* Single TTM move. NOP.
+*/
if (old_iomap == NULL && new_iomap == NULL)
goto out2;
+
+   /*
+* Move nonexistent data. NOP.
+*/
if (old_iomap == NULL && ttm == NULL)
goto out2;

-   /* TTM might be null for moves within the same region.
+   /*
+* TTM might be null for moves within the same region.
 */
if (ttm && ttm->state == tt_unpopulated) {
ret = ttm->bdev->driver->ttm_tt_populate(ttm);
-   if (ret) {
-   /* if we fail here don't nuke the mm node
-* as the bo still owns it */
-   old_copy.mm_node = NULL;
+   if (ret)
goto out1;
-   }
}

add = 0;
@@ -383,11 +387,8 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
   prot);
} else
ret = ttm_copy_io_page(new_iomap, old_iomap, page);
-   if (ret) {
-   /* failing here, means keep old copy as-is */
-   old_copy.mm_node = NULL;
+   if (ret)
goto out1;
-   }
}
mb();
 out2:
@@ -405,7 +406,12 @@ out1:
ttm_mem_reg_iounmap(bdev, old_mem, new_iomap);
 out:
ttm_mem_reg_iounmap(bdev, _copy, old_iomap);
-   ttm_bo_mem_put(bo, _copy);
+
+   /*
+* On error, keep the mm node!
+*/
+   if (!ret)
+   ttm_bo_mem_put(bo, _copy);
return ret;
 }
 EXPORT_SYMBOL(ttm_bo_move_memcpy);
-- 
1.7.10.4

[PATCH 0/2] TTM fixes

[Thomas Hellstrom]

Patch 1 is an error path fix and depends on Jakob's previous fix for this
function.
Patch 2 fixes the code that decides whether a buffer object move to another
memory type is necessary

[PATCH v5 0/4] Fix Win8 backlight issue

[Rafael J. Wysocki]

On Wednesday, October 30, 2013 12:40:13 AM Matthew Garrett wrote:
> On Wed, 2013-10-16 at 01:33 +0200, Rafael J. Wysocki wrote:
> 
> > Since the next step will be to introduce a list of systems that need
> > video.use_native_backlight=1 *and* don't break in that configuration, I 
> > don't
> > see much point adding another Kconfig option for the default.
> 
> I'd still really prefer not to add such a list, because it almost
> inevitably means that we'll never fix this problem properly.

We have this list in blacklist.c anyway.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH v5 0/4] Fix Win8 backlight issue

[Matthew Garrett]

On Wed, 2013-10-16 at 01:33 +0200, Rafael J. Wysocki wrote:

> Since the next step will be to introduce a list of systems that need
> video.use_native_backlight=1 *and* don't break in that configuration, I don't
> see much point adding another Kconfig option for the default.

I'd still really prefer not to add such a list, because it almost
inevitably means that we'll never fix this problem properly.

-- 
Matthew Garrett 

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Laurent Pinchart]

Hello,

On Tuesday 29 October 2013 17:29:55 Rob Clark wrote:
> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
> > > On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa wrote:
> >> > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
> >> >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote:
> >> >> > I think we need to start considering a framework where
> >> >> > subdrivers just add drm objects themselves, then the toplevel
> >> >> > node is responsible for knowing that everything for the current
> >> >> > configuration is loaded.
> >> >>  
> >> >>  It would be nice to specify the various pieces in dt, then have
> >> >>  some type of drm notifier to the toplevel node when everything
> >> >>  has been probed. Doing it in the dt would allow standalone
> >> >>  drm_bridge/drm_panel drivers to be transparent as far as the
> >> >>  device's drm driver is concerned.
> >> >>  
> >> >>  Sean
> >> >>  
> >> >> > I realise we may need to make changes to the core drm to allow
> >> >> > this but we should probably start to create a strategy for
> >> >> > fixing the API issues that this throws up.
> >> >> > 
> >> >> > Note I'm not yet advocating for dynamic addition of nodes once
> >> >> > the device is in use, or removing them.
> >> >> >>> 
> >> >> >>> I do wonder if we had some sort of tag in the device tree for any
> >> >> >>> nodes involved in the display, and the core drm layer would read
> >> >> >>> that list, and when every driver registers tick things off, and
> >> >> >>> when the last one joins we get a callback and init the drm layer,
> >> >> >>> we'd of course have the basic drm layer setup prior to that so we
> >> >> >>> can add the objects as the drivers load. It might make development
> >> >> >>> a bit trickier as you'd need to make sure someone claimed
> >> >> >>> ownership of all the bits for init to proceed.
> >> >> >> 
> >> >> >> Yeah, that's basically what the strawman looked like in my head.
> >> >> >> 
> >> >> >> Instead of a property in each node, I was thinking of having a
> >> >> >> separate gfx pipe nodes that would have dt pointers to the various
> >> >> >> pieces involved in that pipe. This would allow us to associate
> >> >> >> standalone entities like bridges and panels with encoders in dt
> >> >> >> w/o doing it in the drm code. I *think* this should be Ok with the
> >> >> >> dt guys since it is still describing the hardware, but I think we'd
> >> >> >> have to make sure it wasn't drm-specific.
> >> >> > 
> >> >> > I suppose the question is how much dynamic pipeline construction
> >> >> > there is, even on things like radeon and i915 we have dynamic clock
> >> >> > generator to crtc to encoder setups, so I worry about static lists
> >> >> > per-pipe, so I still think just stating all these devices are needed
> >> >> > for display and a list of valid interconnections between them, then
> >> >> > we can have the generic code model drm crtc/encoders/connectors on
> >> >> > that list, and construct the possible_crtcs /possible_clones etc at
> >> >> > that stage.
> >> >> 
> >> >> I'm, without excuse, hopeless at devicetree, so there are probably
> >> >> some violations, but something like:
> >> >> 
> >> >> display-pipelines {
> >> >>   required-elements = <   
> >> >>  >;
> >> >> 
> >> >>   pipe1 {
> >> >> bridge = <>;
> >> >> encoder = <>;
> >> >> crtc = <>;
> >> >>   };
> >> >>   pipe2 {
> >> >> encoder = <>;
> >> >> crtc = <>;
> >> >>   };
> >> >>   pipe3 {
> >> >> panel = <>;
> >> >> encoder = <>;
> >> >> crtc = <>;
> >> >>   };
> >> >> };
> >> >> 
> >> >> I'm tempted to add connector to the pipe nodes as well, so it's
> >> >> obvious which connector should be used in cases where multiple
> >> >> entities in the pipe implement drm_connector. However, I'm not sure
> >> >> if that would be NACKed by dt people.
> >> >> 
> >> >> I'm also not sure if there are too many combinations for i915 and
> >> >> radeon to make this unreasonable. I suppose those devices could just
> >> >> use required-elements and leave the pipe nodes out.
> >> > 
> >> > Just to put my two cents in, as one of the people involved into "the
> >> > device tree movement", I'd say that instead of creating artifical
> >> > entities, such as display-pipelines and all of the pipeX'es, device
> >> > tree should represent relations between nodes.
> >> > 
> >> > According to the generic DT bindings we already have for
> >> > video-interfaces
> >> 
> >> > [1] your example connection layout would look as follows:
> >> Hi Tomasz
> >> Thanks for sending this along.
> >> 
> >> I think the general consensus is that each drm driver should be
> >> implemented as a singular driver. That is, N:1 binding to driver
> >> mapping, where there are N IP blocks. Optional devices (such as
> >> bridges, panels) probably make sense to spin off as standalone
> >> drivers.
> > 
> > 

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Laurent Pinchart]

Hello,

On Tuesday 29 October 2013 20:47:44 Sylwester Nawrocki wrote:
> On 29/10/13 20:23, Tomasz Figa wrote:
> > On Tuesday 29 of October 2013 12:19:35 Olof Johansson wrote:
> > > It's a very deeply nested structure, I'm not sure there's a need to
> > > make a ports {} subnode really.

Agreed, this can be simplified. We've introduced the ports node to group 
multiple ports when the device tree node that contains them also has child 
devices (which is a pretty uncommon case). When this happens, we need 
potentially different #address-cells values for the ports and for the child 
devices. In all other case the ports node can be omitted and the port nodes 
placed directly as children of the device node.

> > > Also, I don't know if it makes sense to always name it remote-endpoint,
> > > or to use a more flexible name depending on what is actually connected,
> > > over which bus, etc.
> 
> I have been thinking about a 'bus_type' as an 'endpoint' node property.
> Currently the data bus type is derived from selected properties in
> endpoint node, which is IMO not good enough.

I agree, a bus type would be useful. I've also been thinking about adding a 
direction property for ports, although that information could be considered as 
device driver knowledge.

> I'm not sure if naming 'remote-endpoint' differently would be helpful, as it
> is now it seems easier to write a generic links parser.
> 
> Nevertheless I wish we have defined a bit simplified option in this binding
> right from the beginning.

It's not too late to clean it up and create a v2 :-)

> >> > But overall this looks sane-ish.
> > 
> > I fully agree with you. Personally I would take a bit different design
> > decisions when designing this bindings, but here I'm just pointing an
> > already defined binding that should suit the needs described in this
> > thread, to avoid reinventing the wheel.
> 
> The 'ports' node is optional. It needs to be used only if, e.g. bridge-a
> node contains device child nodes and these sub-nodes use 'reg' property.
> In such case #address-cells, #size-cells properties for 'port' nodes could
> be conflicting with those for the device child nodes.

I should have read Sylwester's e-mail completely before writing the same 
explanation above :-)

-- 
Regards,

Laurent Pinchart