https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #30 from perry3d at gmail.com ---
I also tried the drm-next-3.14 branch mentioned in comment 3 and got the same
results as kilobug in comment 4. So it has to be something else. I will try to
bisect it when i have some time.
--
You are
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140210/4063273f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #29 from Alex Deucher ---
There was also a dpm restructuring in 3.14 that may have helped, but as
reported in comment 4, it didn't seem to help kilobug. You could try
bisecting.
--
You are receiving this mail because:
You are watchi
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #28 from perry3d at gmail.com ---
DPM is enabled by passing radeon.dpm=1 to the kernel paramters:
root at perry64 # cat /sys/kernel/debug/dri/64/radeon_pm_info
uvdvclk: 0 dclk: 0
power level 2sclk: 93000 mclk: 105000 vddc: 1185
On Mon, Feb 10, 2014 at 04:26:31PM +, Russell King - ARM Linux wrote:
[...]
> Why is this loop soo complicated? Why do you need to mess around with
> this "last_ep" stuff - you don't actually end up using it.
The last_ep dance is necessary because v4l2_of_get_next_endpoint(node,prev)
does not
races/BrutalLegend.trace.tar.xz
With this one i can reproduce the lockup.
--
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/20140210/
2014-02-10 20:06 GMT+01:00 Ilia Mirkin :
> On Mon, Feb 10, 2014 at 10:12 AM, Rafa? Mi?ecki wrote:
>> 2014-02-09 23:12 GMT+01:00 Ilia Mirkin :
>>> On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki wrote:
Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and
noticed nasty display
gameoverlay
starts.
--
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/20140210/43a4ff62/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/34a33a59/attachment.html>
From: Fabio Estevam
devm_request_and_ioremap() is deprecated, so use devm_ioremap_resource()
instead.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/armada/armada_crtc.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drive
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/b153a9e8/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/d4fe6a8f/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/97faad65/attachment.html>
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/4a2cf4fd/attachment.html>
On 02/10/2014 06:29 PM, Russell King - ARM Linux wrote:
> On Mon, Feb 10, 2014 at 06:29:45PM +0800, Liu Ying wrote:
>> This patch removes an unnecessary local variable defined
>> in the function imx_drm_driver_unload() so as to fix the
>> following build warning.
>>
>> drivers/staging/imx-drm/imx-d
at people at the 2013 kernel summit
drm/dt discussion were aware of those bindings and kind of agreed on
(or at least did not oppose) them:
Documentation/devicetree/bindings/media/video-interfaces.txt
The first patch of the above patchset adds the i.MX6 specific connections
for
the output paths according to this binding:
http://archive.arm.linux.org.uk/lurker/message/20140106.145200.24ed4a48.en.html
regards
Philipp
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/9bfbbe00/attachment-0001.html>
On Mon, Feb 10, 2014 at 04:29:45PM +0200, Ville Syrj?l? wrote:
> On Mon, Feb 10, 2014 at 02:14:54PM +, One Thousand Gnomes wrote:
> > > > Does this mean it should also handle horizontal mirroring in
> > > > hardware (180? rotate, and scan lines backwards combined) ?
> > >
> > > Our hardware do
This patch removes an unnecessary local variable defined
in the function imx_drm_driver_unload() so as to fix the
following build warning.
drivers/staging/imx-drm/imx-drm-core.c: \
In function ?imx_drm_driver_unload?:
drivers/staging/imx-drm/imx-drm-core.c:87:25: \
warning: unused variable ?imxdrm
https://bugzilla.kernel.org/show_bug.cgi?id=70171
--- Comment #40 from Andreas ---
(In reply to Alex Deucher from comment #39)
> In addition to the module parameter, you can adjust audio support at runtime
> per connector with xrandr, e.g.,
Thanks, I?ll try it on the next reboot. I tried it now
On Mon, Feb 10, 2014 at 06:37:26PM +0100, Philipp Zabel wrote:
> I'd like all of them to go through, too. If you don't want to have the DT
> changes integrated, I'd appreciate if you could have a look at my
> patches on top of your series and possibly append them to your
> series or let me synchro
https://bugzilla.kernel.org/show_bug.cgi?id=70171
--- Comment #39 from Alex Deucher ---
In addition to the module parameter, you can adjust audio support at runtime
per connector with xrandr, e.g.,
xrandr --output HDMI-0 --set audio off
or
xrandr --output HDMI-0 --set audio auto
--
You are rec
On Mon, 10 Feb 2014 15:18:21 +
Russell King - ARM Linux wrote:
> Now, mind explaining what "v4l2 style device tree bindings" means? I've
> no idea since I'm relatively new to DT.
Documentation/devicetree/bindings/media/video-interfaces.txt
For the Cubox, I have:
tda998x: hdmi-enco
On Fri, Feb 07, 2014 at 06:47:54PM +0200, Imre Deak wrote:
> Ok, not sure why the sdvo initialization fails, but the lockdep
> warning is probably fixed by the below patch. Could you try it and
> send a dmesg with drm.debug=0xe?
Yep, FWIW, the issue is fixed in -rc2, as it got cleared in the other
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/f5038273/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/db91eef1/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/9517c0c0/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=70171
--- Comment #38 from Andreas ---
(In reply to Takashi Iwai from comment #34)
> For the tick-broadcast.c, try to bisect.
To summarize:
[SOLVED] sound issue
[SOLVED] overscan issue
[ ] kernel/time/tick-broadcast.c:668
The thing is: I don?t kn
https://bugzilla.kernel.org/show_bug.cgi?id=70171
--- Comment #37 from Andreas ---
One more info with "nice to know" character:
Without radeon.audio=0 I also no longer see the color settings menu from the
monitor ? it is grayed out. Seems that this is covered by the radeon driver and
the HDMI st
2014-02-08 11:52 GMT+09:00 Tomasz Figa :
> Hi,
>
>
> On 30.01.2014 22:19, Sean Paul wrote:
>>
>> From: Daniel Kurtz
>>
>> The i2c client was previously being passed into the hdmi driver via a
>> dedicated i2c driver, and then a global variable. This patch removes all
>> of that and just uses the d
On Mon, Feb 10, 2014 at 02:14:54PM +, One Thousand Gnomes wrote:
> > > Does this mean it should also handle horizontal mirroring in
> > > hardware (180? rotate, and scan lines backwards combined) ?
> >
> > Our hardware doesn't support mirroring (h or v). Well, unless you
> > count h+v mirrorin
https://bugzilla.kernel.org/show_bug.cgi?id=70171
--- Comment #36 from Andreas ---
(In reply to Alex Deucher from comment #35)
> appending radeon.audio=0 to the kernel command line in grub.
Thanks!
Actually I have to apologize for my incompetence. With the new radeon driver
from 3.13+ my monito
On Mon, Jan 06, 2014 at 03:52:01PM +0100, Philipp Zabel wrote:
> @@ -438,24 +453,21 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
> struct drm_encoder *encoder, struct device_node *np)
> {
> struct imx_drm_device *imxdrm = drm->dev_private;
> + struct device_node *ep, *la
2014-02-09 23:12 GMT+01:00 Ilia Mirkin :
> On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki wrote:
>> Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and
>> noticed nasty display corruptions when using nouveau. It seems that
>> changing parts of the screen are appearing for a fraction o
Am Montag, den 10.02.2014, 12:28 + schrieb Russell King - ARM Linux:
> This is the latest revision of my series cleaning up imx-drm and
> hopefully getting it ready to be moved out of drivers/staging.
> This series is updated to v3.14-rc2.
>
> Since the last round of patches were posted, the c
From: Ville Syrj?l?
Make drm_property_create_bitmask() a bit more generic by allowing the
caller to specify which bits are in fact supported. This allows multiple
callers to use the same enum list, but still create different versions
of the same property with different list of supported bits.
v2
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/fa577bfb/attachment.html>
On Mon, Feb 10, 2014 at 10:41:30AM +, One Thousand Gnomes wrote:
> On Fri, 7 Feb 2014 19:15:05 +0530
> sagar.a.kamble at intel.com wrote:
>
> > From: Sagar Kamble
> >
> > These patches will enable 180 degree rotation for CRTC and Sprite planes.
> > Changelog:
> > 1. drm/i915: Add 180 degree
On Mon, Feb 10, 2014 at 01:01:09PM +0530, sagar.a.kamble at intel.com wrote:
> From: Ville Syrj?l?
>
> Make drm_property_create_bitmask() a bit more generic by allowing the
> caller to specify which bits are in fact supported. This allows multiple
> callers to use the same enum list, but still cr
On Mon, 10 Feb 2014 13:12:33 +
Russell King - ARM Linux wrote:
> I've NAK'd these patches already - I believe they're based on a
> mis-understanding of how this should be used. I believe Jean-Francois
> has only looked at the core, rather than looking at the imx-drm example
> it was posted w
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/45351eb9/attachment.html>
On Mon, Feb 10, 2014 at 01:01:18PM +0530, sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> With clipped sprites these transformations are not working. these
> functions transform complete sprite irrespective of clipping present.
> This leads to invisible portion of sprite show up when
Just like we have for connector type etc.
v2: drop static array (Chris)
v3: add kdoc (Daniel)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 23 +++
include/drm/drm_crtc.h |1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.
On Mon, Feb 10, 2014 at 01:01:17PM +0530, sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> Primary planes support 180 degree rotation. Expose the feature
> through rotation drm property.
>
> v2: Calculating linear/tiled offsets based on pipe source width and
> height. Added 180 degree
|rendering tees in Dota 2|rendering trees in Dota 2
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/f9198
https://bugzilla.kernel.org/show_bug.cgi?id=70171
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #35 f
On Mon, Feb 10, 2014 at 01:01:14PM +0530, sagar.a.kamble at intel.com wrote:
> From: Ville Syrj?l?
>
> The sprite planes (in fact all display planes starting from gen4)
> support 180 degree rotation. Add the relevant low level bits to the
> sprite code to make use of that feature.
>
> The upper
On Mon, Feb 10, 2014 at 04:12:19PM +0100, Philipp Zabel wrote:
> Am Montag, den 10.02.2014, 12:28 + schrieb Russell King - ARM Linux:
> > This is the latest revision of my series cleaning up imx-drm and
> > hopefully getting it ready to be moved out of drivers/staging.
> > This series is update
On Mon, Feb 10, 2014 at 03:35:51PM +0100, Jean-Francois Moine wrote:
> On Mon, 10 Feb 2014 13:12:33 +
> Russell King - ARM Linux wrote:
>
> > I've NAK'd these patches already - I believe they're based on a
> > mis-understanding of how this should be used. I believe Jean-Francois
> > has only
pm_runtime_get*() may return -EACCESS to indicate a device does not have
runtime PM enabled. This is the case when the nouveau.runpm parameter is
set to 0, and is not an error in that context. Handle this case without
failure.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/dispnv04
Memory was always allocated for 4096 channels. Change this to allocate
what we actually need according to the number of channels we use.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dr
Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead
of PCI to which Nouveau is tightly dependent. This patch allows Nouveau
to handle platform devices by:
- abstracting PCI-dependent functions that were typically used for
resource querying and page mapping,
- introducing a n
On Mon, Feb 10, 2014 at 6:51 AM, Ilia Mirkin wrote:
> The ffsll function is a lot slower than the __ffs64 built-in which
> compiles to a single instruction on 64-bit. It's also nice to avoid
> custom versions of standard functions. Note that __ffs == ffs - 1.
>
> Signed-off-by: Ilia Mirkin
Merged
On Sun, Feb 9, 2014 at 1:35 PM, Ilia Mirkin wrote:
> Commit ea7dce901 ("drm/nv50/gr: print mpc trap name when it's not an mp
> trap") added an nv_error call that was missing the priv parameter. This
> causes GPFs if the error is ever hit.
>
> Signed-off-by: Ilia Mirkin
Merged, thanks :)
> ---
>
On Fri, Feb 7, 2014 at 11:22 PM, Alexandre Courbot
wrote:
> Address of the ENG_RUNLIST register should be 0x002284 + (engine * 8),
> not 0x002284 + (engine * 4).
>
> Signed-off-by: Alexandre Courbot
> ---
> Stumbled upon this one and I'm quite certain the offset was not correct.
> This is incons
> > Does this mean it should also handle horizontal mirroring in
> > hardware (180? rotate, and scan lines backwards combined) ?
>
> Our hardware doesn't support mirroring (h or v). Well, unless you
> count h+v mirroring since that's 180 degree rotation :)
>
> Anyways IIRC the old video overlay (
e
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/701df8e5/attachment.pgp>
On Mon, Feb 10, 2014 at 10:12 AM, Rafa? Mi?ecki wrote:
> 2014-02-09 23:12 GMT+01:00 Ilia Mirkin :
>> On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki wrote:
>>> Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and
>>> noticed nasty display corruptions when using nouveau. It seems that
>
>dev, data);
Same here.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/0969c543/attachment.pgp>
certainly encountered the
same warning when building nouveau on ARM, so:
Reviewed-by: Thierry Reding
-- 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/20140210/67591e97/attachment.pgp>
able_depth to remain at -1 and therefore runtime PM
helpers return -EACCES.
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/20140210/5f88f505/attachment.pgp>
From: Rob Clark
Signed-off-by: Rob Clark
---
src/gallium/targets/pipe-loader/Makefile.am | 16
src/gallium/targets/pipe-loader/pipe_msm.c | 21 +
2 files changed, 37 insertions(+)
create mode 100644 src/gallium/targets/pipe-loader/pipe_msm.c
diff --git a/
From: Rob Clark
DRM_API_HANDLE_TYPE_SHARED is zero, so doesn't actually fix anything.
But we shouldn't rely on SHARED handle type being zero.
Signed-off-by: Rob Clark
---
src/gallium/state_trackers/xa/xa_tracker.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/x
From: Rob Clark
This lets multiple gallium drivers use XA.
Signed-off-by: Rob Clark
---
configure.ac | 9 ++--
src/gallium/state_trackers/xa/Makefile.am | 1 +
src/gallium/state_trackers/xa/xa_priv.h | 1 +
src/gallium/state_trackers/xa/xa_tracker.
From: Rob Clark
Build two versions of pipe-loader, with only the client version linking
in x11 client side dependencies. This will allow the XA state tracker
to use pipe-loader.
Signed-off-by: Rob Clark
---
configure.ac | 14 +++--
src/gallium/aux
From: Rob Clark
Original patchset:
http://lists.freedesktop.org/archives/mesa-dev/2014-February/053632.html
v1: original
v2: moves xa target into targets/xa, and fixes various issues spotted
by Emil
Rob Clark (4):
pipe-loader: split out "client" version
st/xa: use pipe-loader to get scr
available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/96c146ce/attachment-0001.pgp>
On Mon, Feb 10, 2014 at 01:53:08PM +0100, Thierry Reding wrote:
> On Fri, Feb 07, 2014 at 04:55:00PM +0100, Jean-Francois Moine wrote:
> > Some simple components don't need to do any specific action on
> > bind to / unbind from a master component.
> >
> > This patch permits such components to omit
From: Ville Syrj?l?
The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.
The upper layers are not yet plugged in.
v2: HSW handles the rotated buffer offset automagically
Cc
From: Sagar Kamble
With clipped sprites these transformations are not working. these
functions transform complete sprite irrespective of clipping present.
This leads to invisible portion of sprite show up when rotate 180 if
it was out of visible area before.
v4: Moved rotate transform for source
From: Sagar Kamble
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issueing
From: Ville Syrj?l?
Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.ke
From: Ville Syrj?l?
Propagate the error from intel_update_plane() up through
intel_plane_restore() to the caller. This will be used for
rollback purposes when setting properties fails.
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel a
From: Ville Syrj?l?
The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.
The upper layers are not yet plugged in.
v2: HSW handles the rotated buffer offset automagically
Cc
From: Ville Syrj?l?
drm_rotation_simplify() can be used to eliminate unsupported rotation
flags. It will check if any unsupported flags are present, and if so
it will modify the rotation to an alternate form by adding 180 degrees
to rotation angle, and flipping the reflect x and y bits. The hope
From: Ville Syrj?l?
Add some helper functions to move drm_rects between different rotated
coordinate spaces. One function does the forward transform and
another does the inverse.
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ville Syr
From: Ville Syrj?l?
Use the new drm_mode_create_rotation_property() in omapdrm.
v5: Fixed conflict due to change in the prior patch in call to
drm_property_create_bitmask()
Cc: David Airlie
Cc: Rob Clark
Cc: Sagar Kamble
Cc: "Ville Syrj?l?"
Cc: Tomi Valkeinen
Cc: Greg Kroah-Hartman
Cc: dr
From: Ville Syrj?l?
Add a function to create a standards compliant rotation property.
v4: For creating rotation bitmask property send number of values
as only number of set rotations
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Vill
From: Ville Syrj?l?
Make drm_property_create_bitmask() a bit more generic by allowing the
caller to specify which bits are in fact supported. This allows multiple
callers to use the same enum list, but still create different versions
of the same property with different list of supported bits.
v5
From: Ville Syrj?l?
The rotation property stuff should be standardized among all drivers.
Move the bits to drm_crtc.h from omap_drv.h.
Cc: David Airlie
Cc: Tomi Valkeinen
Cc: Dave Airlie
Cc: Rob Clark
Cc: Daniel Vetter
Cc: Archit Taneja
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kern
--
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/20140210/ddfc4ab3/attachment.pgp>
),
> +dev_name(&pdev->dev), nouveau_config,
> + nouveau_debug, &device);
> +
> + ret = drm_platform_init(&driver, pdev);
> + if (ret) {
> + nouveau_object_ref(NULL, (struct nouveau_object **)&device);
> + return ret;
> + }
> +
> + return ret;
> +}
I think we should move the whole of gk20a probing into nouveau. Keeping
one part in tegra-drm and one part in nouveau is confusing, and I can't
see a reason why we'd have to keep it that way.
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/20140210/089f341e/attachment.pgp>
On Fri, Feb 7, 2014 at 7:28 AM, Rob Clark wrote:
> On Thu, Feb 6, 2014 at 9:53 PM, Sean Paul wrote:
>> On Wed, Jan 29, 2014 at 8:44 AM, Rob Clark wrote:
>>> On Tue, Jan 28, 2014 at 4:52 PM, Sean Paul wrote:
On Mon, Nov 25, 2013 at 9:47 AM, Rob Clark wrote:
> Break the mutable state of
This is the latest revision of my series cleaning up imx-drm and
hopefully getting it ready to be moved out of drivers/staging.
This series is updated to v3.14-rc2.
Since the last round of patches were posted, the component support
has been merged into mainline, and thus dropped from this series.
https://bugzilla.kernel.org/show_bug.cgi?id=69901
Christoph Haag changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Sean,
On 01/30/2014 10:19 PM, Sean Paul wrote:
> This patch uses the mode passed into mode_set to configure fimd instead
> of directly using the panel from context. This will allow us to move
> the exynos_drm_display implementation out of fimd, where it doesn't
> belong.
>
> Signed-off-by: Sea
||
--
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/20140210/685c45c5/attachment.html>
On Mon, Feb 10, 2014 at 06:42:57PM +0800, Liu Ying wrote:
> On 02/10/2014 06:29 PM, Russell King - ARM Linux wrote:
> > On Mon, Feb 10, 2014 at 06:29:45PM +0800, Liu Ying wrote:
> >> This patch removes an unnecessary local variable defined
> >> in the function imx_drm_driver_unload() so as to fix t
> fbcon is loaded so it isn't an issue.
>
> I tried 3.10 kernel initially (the above messages are from it), next
> I tried 3.13 kernel too, and that one behaves exactly the same.
>
> As far as I remember, this system never worked with graphics well.
> Previous kernel (from which I updated) was 3.
On Fri, 7 Feb 2014 19:15:05 +0530
sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> These patches will enable 180 degree rotation for CRTC and Sprite planes.
> Changelog:
> 1. drm/i915: Add 180 degree primary plane rotation support
> Addressed review comments for CRTC rotation from FB
||
--
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/20140210/084b6d37/attachment.html>
eed anything else, just ask.
--
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/20140210/4238604e/attachment-0001.html>
On Mon, Feb 10, 2014 at 10:14 AM, Marek Ol??k wrote:
> Hi Dave,
>
> You bumped the UMS driver version instead of the KMS one.
>
> Sorry for the late review, I actually noticed it when reading the code.
Oh I noticed, so I should just revert the bump here, as it just
happened a kernel released with
On Mon, Feb 10, 2014 at 06:29:45PM +0800, Liu Ying wrote:
> This patch removes an unnecessary local variable defined
> in the function imx_drm_driver_unload() so as to fix the
> following build warning.
>
> drivers/staging/imx-drm/imx-drm-core.c: \
> In function ?imx_drm_driver_unload?:
> drivers/
https://bugzilla.kernel.org/show_bug.cgi?id=70171
Takashi Iwai changed:
What|Removed |Added
Component|Sound(ALSA) |Video(DRI - non Intel)
Assignee|
dri-devel/attachments/20140210/4f12c0a6/attachment.html>
||
--
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/20140210/ed3de262/attachment.html>
to go back to catalyst, which require me to downgrade xorg server,
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/
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/2c189c0b/attachment.html>
dri-devel/attachments/20140210/55e96ca0/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/f4e9703a/attachment.html>
1 - 100 of 112 matches
Mail list logo
