ry time ?
If yes what do you do exactly ? I would like to try that.
--
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/20140407/68ef3149/attachment.html>
Jesse's BIOS fb reconstruction code actually relies on the -ENOSPC
return value to detect overlapping framebuffers (which the bios uses
always when lighting up more than one screen). All this fanciness
happens in intel_alloc_plane_obj in intel_display.c.
Since no one else uses this we can savely r
On Mon, 7 Apr 2014 23:25:20 +0200
Daniel Vetter wrote:
> Jesse's BIOS fb reconstruction code actually relies on the -ENOSPC
> return value to detect overlapping framebuffers (which the bios uses
> always when lighting up more than one screen). All this fanciness
> happens in intel_alloc_plane_ob
On Mon, Apr 7, 2014 at 7:23 PM, Rob Clark wrote:
> On Mon, Apr 7, 2014 at 6:05 AM, Thierry Reding
> wrote:
>> On Fri, Mar 28, 2014 at 10:04:09PM +0100, Daniel Vetter wrote:
>>> On Tue, Mar 18, 2014 at 05:22:57PM -0700, Matt Roper wrote:
>>> > Add cursor plane as a parameter to drm_crtc_init() an
On Mon, Apr 7, 2014 at 4:35 PM, Alex Deucher wrote:
> On Mon, Apr 7, 2014 at 5:37 AM, Jani Nikula wrote:
>> To support bare address requests used by the drm dp helpers.
>>
>> Signed-off-by: Jani Nikula
>>
>> ---
>>
>> Hi Alex, similar to Thierry's patch for i915.
>>
>
> Looks good to me.
>
> Rev
On Mon, Apr 7, 2014 at 5:19 PM, Ian Romanick wrote:
> On 04/05/2014 02:44 AM, Daniel Vetter wrote:
>> ttm_bo_unref unconditionally calls kref_put on it's argument, so the
>> thing can't be NULL without already causing Oopses.
>
> Doesn't this mean the NULL check is in the wrong place (rather than
On Mon, Apr 7, 2014 at 5:28 PM, Ian Romanick wrote:
> On 04/05/2014 02:44 AM, Daniel Vetter wrote:
>> The outer if already checks for data != 0, so it can't really be
>> 0. Hence remove it.
>>
>> Now I don't have specs or anything for this beast, so I have no
>> idea whether this was actually inte
nd HEAD
4ccff1499c956b51f18710c7308cbce883f64cd9.
--
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/20140407/d5d56cf5/attachment.html>
On Mon, Apr 07, 2014 at 10:22:36AM +0200, Philipp Zabel wrote:
> The decoder mux id is equal to the port id of the encoder's input port
> that is connected to the given crtc, not to the endpoint id (which is
> arbitrary and usually zero).
>
> Signed-off-by: Philipp Zabel
It fixes a color corrupt
On Mon, Apr 07, 2014 at 12:05:35PM +0200, Philipp Zabel wrote:
> > Did you get any chance to reproduce this dual display issue? Now it
> > shows on mainline kernel.
>
> I have not yet reproduced, but I've sent a patch today ("imx-drm:
> imx-drm-core: Fix imx_drm_encoder_get_mux_id") that might fi
On Mon, Apr 07, 2014 at 10:09:27AM +0100, Russell King - ARM Linux wrote:
> So no EDID. Did you update the "ddc" property to "ddc-i2c-bus" ?
Ah, right. This is exactly the cause. Thanks, Russell.
Shawn
unsaved work on the screen.
--
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/20140407/68ec22d5/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/2a430f4b/attachment.html>
re 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/20140407/e996c122/attachment.html>
gnee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/8bd2a89f/attachment-0001.html>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/b912535e/attachment-0001.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/459f1d1b/attachment.html>
is 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/20140407/3c030c5a/attachment.html>
g 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/20140407/9d1b7980/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #18 from Alex Deucher ---
(In reply to Tom Yan from comment #16)
> I tried to remove the DisplayPort-specific code in
> radeon_connector_hotplug() of radeon_connector.c and everything seems to
> work like a charm. What is the code supp
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/6377f175/attachment.html>
s 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/20140407/2bc40304/attachment.html>
On Mon, Apr 7, 2014 at 5:51 PM, David Herrmann wrote:
> On Sat, Apr 5, 2014 at 11:44 AM, Daniel Vetter
> wrote:
>> The context_dtor callback is only called once we've successfully loaded
>> the driver, which means dev->dev_private is set up. The check is hence
>> pointless.
>>
>> Also dev->dev_p
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #17 from Tom Yan ---
One thing to add, unplugging it physically in X still makes it blank. It
happens no matter the code is removed or not.
Also, HDMI doesn't work all time yet, seems that if the TV is powered off and
it goes into DPM
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/d684ac95/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #16 from Tom Yan ---
I tried to remove the DisplayPort-specific code in radeon_connector_hotplug()
of radeon_connector.c and everything seems to work like a charm. What is the
code supposed to do actually?
Though, btw, it seems that o
On Mon, Apr 7, 2014 at 5:41 PM, Grazvydas Ignotas wrote:
> Gra?vydas
>
>
> On Mon, Apr 7, 2014 at 8:17 PM, Rob Clark wrote:
>> On Mon, Apr 7, 2014 at 6:32 AM, Grazvydas Ignotas
>> wrote:
>>> On Sun, Apr 6, 2014 at 12:45 AM, Rob Clark wrote:
On Sat, Apr 5, 2014 at 2:33 PM, Grazvydas Ignota
s.freedesktop.org/archives/dri-devel/attachments/20140407/ccb8f37f/attachment.html>
Hi
On Sat, Apr 5, 2014 at 11:44 AM, Daniel Vetter
wrote:
> Hi all,
>
> Rainy w/e here and I got a bit bored, so looked at coverity again. I've closed
> all outstanding issues in drivers/gpu now either as false positives or fixed
> in
> this series expect for vmwgfx/ttm stuff (not enough clue) a
Hi
On Sat, Apr 5, 2014 at 11:44 AM, Daniel Vetter
wrote:
> The context_dtor callback is only called once we've successfully loaded
> the driver, which means dev->dev_private is set up. The check is hence
> pointless.
>
> Also dev->dev_private is deref already above, so compilers are free
> to el
On 07.04.2014 17:16, Inki Dae wrote:
> Hi Andrzej,
>
> 2014-04-07 23:18 GMT+09:00 Andrzej Hajda :
>> Hi Inki and Tomasz,
>>
>> On 04/06/2014 05:15 AM, Inki Dae wrote:
>>
>> (...)
>>> The code creating the list of components to wait for
>>> (exynos_drm_add_components()) doesn't seem to consider whic
On Mon, 07 Apr 2014 14:25:28 +0200
Thomas Hellstrom wrote:
> Hi, Lauri.
>
> On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
> > Hi list, Thomas,
> >
> > I'd like to know if this is going in the right direction.
>
> This looks fine with me.
>
> However, if possible I'd like the drivers to enable b
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/39973576/attachment-0001.html>
In case user has specified an input for aspect ratio through the property,
then the user space value for PAR would take preference over the value from
CEA mode list.
Signed-off-by: Vandana Kannan
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 9 +++--
1 file changed,
Added a property to enable user space to set aspect ratio.
This patch contains declaration of the property and code to create the
property.
Signed-off-by: Vandana Kannan
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_crtc.c | 31 +++
include/drm/drm_cr
On 04/07/2014 04:39 PM, Lauri Kasanen wrote:
> On Mon, 07 Apr 2014 14:25:28 +0200
> Thomas Hellstrom wrote:
>
>> Hi, Lauri.
>>
>> On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
>>> Hi list, Thomas,
>>>
>>> I'd like to know if this is going in the right direction.
>> This looks fine with me.
>>
>> Ho
Hi Andrzej,
On 07.04.2014 16:18, Andrzej Hajda wrote:
> Hi Inki and Tomasz,
>
> On 04/06/2014 05:15 AM, Inki Dae wrote:
>
> (...)
>> The code creating the list of components to wait for
>> (exynos_drm_add_components()) doesn't seem to consider which sub-drivers are
>> actually enabled in kernel co
||
--
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/20140407/523bd4d7/attachment.html>
Hi Inki and Tomasz,
On 04/06/2014 05:15 AM, Inki Dae wrote:
(...)
> The code creating the list of components to wait for
> (exynos_drm_add_components()) doesn't seem to consider which sub-drivers are
> actually enabled in kernel config.
>
> Are you sure?
>
> exynos_drm_add_components() will try t
ot be garbled anymore, but scrolling in
Firefox (and possible other applications) is much slower/less smooth.
--
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/
There is actually quite a bit of variance based on
the asic.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/dce6_afmt.c | 14 ++
drivers/gpu/drm/radeon/radeon.h| 5 -
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/driver
On Mon, Apr 7, 2014 at 4:03 PM, Daniel Vetter wrote:
> On Mon, Apr 7, 2014 at 7:23 PM, Rob Clark wrote:
>> On Mon, Apr 7, 2014 at 6:05 AM, Thierry Reding
>> wrote:
>>> On Fri, Mar 28, 2014 at 10:04:09PM +0100, Daniel Vetter wrote:
On Tue, Mar 18, 2014 at 05:22:57PM -0700, Matt Roper wrote:
move the retry
> logic into drm_dp_i2c_xfer()? Do you mind if we do that in a follow
> up patch so we can keep it separate from the addition of the bare
> address packets?
No, looking at the code again, I don't see how we can do much better
without sacrificing much of the clarity of the code.
But perhaps this could be documented somewhere else than the I2C
helpers. Perhaps the struct drm_dp_aux comment should be updated, which
would cause the DRM docbook to automatically pick up that change as
well.
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/20140407/aa052f13/attachment-0001.sig>
y sys. :)
368 is much higher than 100. LMK if you need more. TIA.
--
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/20140407/6642275c/attachment-0001.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/15687069/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/cb58ec57/attachment.html>
In case user has specified an input for aspect ratio through the property,
then the user space value for PAR would take preference over the value from
CEA mode list.
Signed-off-by: Vandana Kannan
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 9 +++--
1 file changed,
Added a property to enable user space to set aspect ratio.
This patch contains declaration of the property and code to create the
property.
Signed-off-by: Vandana Kannan
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_crtc.c | 31 +++
include/drm/drm_cr
g/archives/dri-devel/attachments/20140407/256734dd/attachment.html>
On Apr-07-2014 3:33 PM, Kannan, Vandana wrote:
> Added a property to enable user space to set aspect ratio.
> This patch contains declaration of the property and code to create the
> property.
>
> Signed-off-by: Vandana Kannan
> Cc: dri-devel at lists.freedesktop.org
> ---
This patch series is be
The DRM_PANEL_SIMPLE is needed by the eukrea
mbimxsd51's displays.
Signed-off-by: Denis Carikli
---
ChangeLog v10->v11:
- New patch, splitting it would be overkill.
---
arch/arm/configs/imx_v6_v7_defconfig |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/imx_v6_v7_defcon
Signed-off-by: Denis Carikli
---
ChangeLog v9->v11:
- Now uses the drm-panel instead of the display-timings.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- The backlight is now on at boot.
ChangeLog v6->v7:
- Shrinked even more the Cc list.
ChangeLog v5->v6:
The CMO-QVGA, DVI-SVGA and DVI-VGA are added.
Signed-off-by: Denis Carikli
---
ChangeLog v10->v11:
- Now uses the drm-panel instead of the display-timings.
This is to get regulator support, which is lacking in
the imx-drm driver when using the display-timings.
ChangeLog v9->v10:
- Rebased
-
Signed-off-by: Denis Carikli
---
ChangeLog v11->v12:
- Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
ChangeLog v10->v11:
- New patch.
---
.../bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt |7 ++
.../bindings/panel/eukrea,mbimxsd51-dvi-svga.txt |7 ++
.../bindin
The previous hardware behaviour was kept if the
flags are not set.
Signed-off-by: Denis Carikli
---
ChangeLog v11->v12:
- Rebased: It now uses the following new flags defines names:
CLK_POL, ENABLE_POL
- The inversions in ipuv3-crtc.c are now fixed.
- ipuv3-crtc.c was still using mode->private_
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli
---
ChangeLog v11->v12:
- Rebased: This patch now applies against drm_modes.h
- Rebased: It now uses the new
The imx-drm driver can't use the de-active and
pixelclk-active display-timings properties yet.
Instead the data-enable and the pixel data clock
polarity are hardcoded in the imx-drm driver.
So theses properties are now set to keep
the same behaviour when imx-drm will start
using them.
Signed-off
Signed-off-by: Denis Carikli
---
ChangeLog 11->v12:
- Improved the define names to match the hardware:
ENABLE_POL is not a clock signal but instead an enable signal.
ChangeLog v9->v10:
- New patch which was splitted out from:
"staging: imx-drm: Use de-active and pixelclk-active display-timing
According to the datasheet, setting the di0_polarity_disp_clk
field in the GENERAL di register sets the output clock polarity
to active high.
Signed-off-by: Denis Carikli
---
ChangeLog v9->v10:
- New patch that is now needed by the
"staging: imx-drm: Use de-active and pixelclk-active" patch.
--
The current BGR666 is not consistent with the other color mapings like BGR24.
BGR666 should be in the same byte order than BGR24.
Signed-off-by: Denis Carikli
Acked-by: Philipp Zabel
---
ChangeLog v9->v10:
- Rebased.
- Added Philipp Zabel's Ack.
- Included Lothar Wa?mann's suggestion about imx-l
Signed-off-by: Denis Carikli
Acked-by: Philipp Zabel
---
ChangeLog v8->v9:
- Rebased.
- Added Philipp Zabel's ack.
- Shortened the patch title.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- Rebased.
ChangeLog v7->v8:
- Shrinked even more the Cc list.
Change
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Signed-off-by: Denis Carikli
Acked-by: Mauro Carvalho Chehab
Acked-by: Laurent Pinchart
Acked-by: Philipp Zabel
---
ChangeLog v9->v10:
- Rebased on top of:
"211e7f2 [media]
Am Montag, den 07.04.2014, 12:05 +0200 schrieb Philipp Zabel:
> Hi Shawn,
>
> Am Montag, den 07.04.2014, 12:23 +0800 schrieb Shawn Guo:
> > On Tue, Mar 11, 2014 at 11:46:11AM +0800, Shawn Guo wrote:
> > > I just came across a couple problems when testing the series on
> > > my imx6dl-sabresd board
Hi, Lauri.
On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
> Hi list, Thomas,
>
> I'd like to know if this is going in the right direction.
This looks fine with me.
However, if possible I'd like the drivers to enable both alloc_threshold
and priority queue on a per-memory-type basis.
That would me
On Sun, Apr 6, 2014 at 12:45 AM, Rob Clark wrote:
> On Sat, Apr 5, 2014 at 2:33 PM, Grazvydas Ignotas
> wrote:
>> Plane rotation with omapdrm is currently broken.
>> It seems omap_plane_mode_set() expects width and height in screen
>> coordinates, so pass it like that.
>>
>> Cc: Rob Clark
>> Si
On Mon, Apr 7, 2014 at 6:05 AM, Thierry Reding
wrote:
> On Fri, Mar 28, 2014 at 10:04:09PM +0100, Daniel Vetter wrote:
>> On Tue, Mar 18, 2014 at 05:22:57PM -0700, Matt Roper wrote:
>> > Add cursor plane as a parameter to drm_crtc_init() and update all
>> > existing DRM drivers to use a helper-pr
On Mon, Apr 7, 2014 at 6:32 AM, Grazvydas Ignotas wrote:
> On Sun, Apr 6, 2014 at 12:45 AM, Rob Clark wrote:
>> On Sat, Apr 5, 2014 at 2:33 PM, Grazvydas Ignotas
>> wrote:
>>> Plane rotation with omapdrm is currently broken.
>>> It seems omap_plane_mode_set() expects width and height in screen
On 04/07/2014 12:56 PM, Daniel Vetter wrote:
> On Mon, Apr 7, 2014 at 5:19 PM, Ian Romanick wrote:
>> On 04/05/2014 02:44 AM, Daniel Vetter wrote:
>>> ttm_bo_unref unconditionally calls kref_put on it's argument, so the
>>> thing can't be NULL without already causing Oopses.
>>
>> Doesn't this mea
rry
-- 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/20140407/ae3b2dc3/attachment.sig>
To support bare address requests used by the drm dp helpers.
Signed-off-by: Jani Nikula
---
Hi Alex, similar to Thierry's patch for i915.
BR,
Jani.
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
On Tue, Mar 11, 2014 at 11:46:11AM +0800, Shawn Guo wrote:
> I just came across a couple problems when testing the series on
> my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it
> using Russell's branch below, which I believe has all the pieces put
> together.
>
> git://ftp
---
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/20140407/a9808a95/attachment.sig>
Hi Shawn,
Am Montag, den 07.04.2014, 12:23 +0800 schrieb Shawn Guo:
> On Tue, Mar 11, 2014 at 11:46:11AM +0800, Shawn Guo wrote:
> > I just came across a couple problems when testing the series on
> > my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it
> > using Russell's bran
Loading cursors to the LCD controller's SRAM can be corrupted when the
configured pixel clock is relatively slow. This seems to be caused
when we write back-to-back to the SRAM registers.
There doesn't appear to be any status register we can read to check
when an access has completed.
Inserting
On 07.04.2014 11:41, Thierry Reding wrote:
> On Mon, Apr 07, 2014 at 11:34:22AM +0300, Terje Bergstr?m wrote:
>> On 07.04.2014 11:18, Thierry Reding wrote:
>>> If I understand correctly there's no immediate need for this to go to
>>> stable kernels, nor for it to be queued for 3.15, right? That is
On 07.04.2014 11:18, Thierry Reding wrote:
> If I understand correctly there's no immediate need for this to go to
> stable kernels, nor for it to be queued for 3.15, right? That is the
> potential extra write isn't causing any harm on actual hardware, is it?
>
> In that case I'll queue this up fo
On 05.04.2014 01:31, Stephen Warren wrote:
> From: Stephen Warren
>
> diff --git a/drivers/gpu/host1x/hw/intr_hw.c b/drivers/gpu/host1x/hw/intr_hw.c
> index db9017adfe2b..498b37e39058 100644
> --- a/drivers/gpu/host1x/hw/intr_hw.c
> +++ b/drivers/gpu/host1x/hw/intr_hw.c
> @@ -47,7 +47,7 @@ static
On Son, 2014-04-06 at 15:26 +0300, Lauri Kasanen wrote:
> Hi,
>
> Obviously old userspace + new kernel combo needs to be supported. But
> I'm not so sure about a mixed case, does old userspace + new userspace
> need to be supported to run at the same time?
>
> For example, a new 64-bit mesa+libdr
On Fri, 04 Apr 2014, Alex Deucher wrote:
> Needed for proper i2c over aux handling for certain
> monitors and configurations (e.g., dp bridges or
> adapters).
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/atombios_dp.c | 15 +++
> 1 file changed, 11 insertions(+), 4
hierry
-- 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/20140407/eb0a812c/attachment.sig>
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/77c9b71b/attachment.sig>
From: Thierry Reding
Certain types of I2C-over-AUX transactions require that only the address
is transferred. Detect this by looking at the AUX message's size and set
the address-only bit appropriately.
Signed-off-by: Thierry Reding
---
Hi Alex,
This patch is required to make eDP work properly
On Mon, Apr 7, 2014 at 5:37 AM, Jani Nikula wrote:
> To support bare address requests used by the drm dp helpers.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Hi Alex, similar to Thierry's patch for i915.
>
Looks good to me.
Reviewed-by: Alex Deucher
Do you want me to add this to the patch set?
Provides a nice cleanup in radeon.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 117 +
drivers/gpu/drm/radeon/radeon_connectors.c | 44 ++-
drivers/gpu/drm/radeon/radeon_display.c| 11 ++-
drivers/gpu/drm/radeon/radeon_i2c
If you are using the common dp over i2c functionality, it is
asumed that the aux transfer function does not modify the any
of the msg structure other than the reply field. Doing so
breaks the logic in the common code.
v2: update struct drm_dp_aux comments about assumptions
Signed-off-by: Alex De
We need bare address packets at the start and end of
each i2c over aux transaction to properly reset the connection
between transactions. This mirrors what the existing dp i2c
over aux algo currently does.
This fixes EDID fetches on certain monitors especially with
dp bridges.
v2: update as per
Needed for proper i2c over aux handling for certain
monitors and configurations (e.g., dp bridges or
adapters).
v2: add comments clarifying tx_size setting.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 23 ++-
1 file changed, 18 insertions(+), 5 del
Updated with Thierry's comments.
Alex Deucher (4):
drm/radeon/dp: handle zero sized i2c over aux transactions (v2)
drm/dp/i2c: send bare addresses to properly reset i2c connections (v4)
drm/dp/i2c: Update comments about common i2c over dp assumptions (v2)
drm/radeon/dp: switch to the commo
On Sun, 6 Apr 2014 19:58:48 +0200
Daniel Vetter wrote:
> On Sun, Apr 6, 2014 at 7:28 PM, Lauri Kasanen wrote:
> > This is related to my memory management work. As the VRAM queue is
> > global, it cannot be determined on a per-app basis. If at least one
> > client is running old userspace, the ne
The decoder mux id is equal to the port id of the encoder's input port
that is connected to the given crtc, not to the endpoint id (which is
arbitrary and usually zero).
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/imx-drm-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
t causing any harm on actual hardware, is it?
In that case I'll queue this up for 3.16.
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/20140407/c6c11806/attachment-0001.sig>
On Mon, Apr 07, 2014 at 12:23:37PM +0800, Shawn Guo wrote:
> And I see another HDMI regression with my testing on mainline kernel. I
> can have my HDMI work at 1920x1080 with v3.14 kernel, but it can only
> probes 1024x768 with the mainline today.
Works for me here.
> [20.606] (II) LoadModul
a comment that documents these assumptions, I don't see a reason
for these assumptions in the first place.
I'd prefer if we simply provided the complete message rather than rely
on drivers not to touch anything but the reply field.
Thierry
-- next part --
A non-text
On Mon, Apr 7, 2014 at 3:49 AM, Thierry Reding
wrote:
> On Fri, Apr 04, 2014 at 03:58:37PM -0400, Alex Deucher wrote:
>> We need bare address packets at the start and end of
>> each i2c over aux transaction to properly reset the connection
>> between transactions. This mirrors what the existing
On 04/07/2014 02:18 AM, Thierry Reding wrote:
> On Fri, Apr 04, 2014 at 04:31:05PM -0600, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> BIT_WORD() truncates rather than rounds, so the loops in
>> syncpt_thresh_isr() and _host1x_intr_disable_all_syncpt_intrs() use <=
>> rather than < in an at
On Mon, Apr 7, 2014 at 9:24 AM, Alex Deucher wrote:
> On Mon, Apr 7, 2014 at 3:57 AM, Jani Nikula
> wrote:
>> On Fri, 04 Apr 2014, Alex Deucher wrote:
>>> Needed for proper i2c over aux handling for certain
>>> monitors and configurations (e.g., dp bridges or
>>> adapters).
>>>
>>> Signed-off-b
On Mon, Apr 7, 2014 at 3:57 AM, Jani Nikula
wrote:
> On Fri, 04 Apr 2014, Alex Deucher wrote:
>> Needed for proper i2c over aux handling for certain
>> monitors and configurations (e.g., dp bridges or
>> adapters).
>>
>> Signed-off-by: Alex Deucher
>> ---
>> drivers/gpu/drm/radeon/atombios_dp.
On 04/05/2014 02:45 AM, Daniel Vetter wrote:
> This is C standard hair-splitting, but afaict
> - sum will be promoted to signed int in computation since
> uint8_t fits
> - signed overflow is undefined.
>
> No we need to add up an awful lot of bytes to actually make it
^^
Now
> overflow. But I
On 04/05/2014 02:45 AM, Daniel Vetter wrote:
> The ->gem_free_object never gets called with a NULL pointer, the check
> is redundant. Also checking after the upcast allows compilers to elide
> it anyway.
>
> Noticed while chasing coverity reports, somehow this one here was not
> flagged.
>
> Sign
On 04/05/2014 02:44 AM, Daniel Vetter wrote:
> The outer if already checks for data != 0, so it can't really be
> 0. Hence remove it.
>
> Now I don't have specs or anything for this beast, so I have no
> idea whether this was actually intended or whether the logic
> should be different. At least t
1 - 100 of 125 matches
Mail list logo
