attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130814/e24568fa/attachment.html>
On Thu, Aug 08, 2013 at 09:10:38AM +0200, Daniel Vetter wrote:
> Makes it more obviously correct what tricks we play by reusing the drm
> prime release helper.
>
> Reviewed-by: Chris Wilson
> Signed-off-by: Daniel Vetter
Ok, to get things going I've merged the two i915 patches to dinq.
-Daniel
rg/archives/dri-devel/attachments/20130814/76884254/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130814/067c2677/attachment.html>
org/archives/dri-devel/attachments/20130814/8e870d0b/attachment.html>
ks to always recovering successfully.
--
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/20130814/9e58554c/attachment.html>
From: vkannan
Populate bar information, colorimetry, IT content, quantization range fields
of AVI infoframe based on CEA 861-D spec.
Signed-off-by: Vandana Kannan
---
drivers/gpu/drm/i915/intel_drv.h |4
drivers/gpu/drm/i915/intel_hdmi.c | 39 +++--
From: vkannan
Populate picture aspect ratio field of AVI infoframe.
If there is a custom value to be set for aspect ratio, it takes highest
priority, followed by a check in the CEA mode list. If the mode is not
found in the standard mode list, aspect ratio is calculated based on aspect
ratio.
Pr
This patch adds dt support to hdmiphy config settings
as it is board specific and depends on the signal pattern
of board.
Signed-off-by: Shirish S
---
.../devicetree/bindings/video/exynos_hdmi.txt | 18 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 191 +++-
2 f
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-arndale.dts | 120 ++
1 file changed, 120 insertions(+)
This patch moves the hdmi phy setting to smdk5250
dts,as its more of a per board configuration and
also shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 120 +
1 file changed, 120 insertions(+)
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
On 14/08/2013 05:02, Pali Rohár wrote:
On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
On 13/08/2013 09:53, Pali Rohár wrote:
On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres
wrote:
On 13/08/2013 09:23, Pali Rohár wrote:
On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
send me the result along with the temperature reported by nvidia
at the time of the peek.
Martin
PS: This patch has only be compile-tested, I don't have access to an
nv4x right now.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-nv40-therm-set-default-calibration-values-if-nee.patch
Type: text/x-patch
Size: 4953 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130814/12c01c4e/attachment.bin>
From: Darren Etheridge
Add a fixup function that will flip the hsync priority and
add a hskew value that is used to shift the tda998x to the
right by a variable number of pixels depending on the mode.
This works around an issue with the sync timings that tilcdc
is outputing.
Signed-off-by: Darre
Some LCD controller cannot provide valid VESA style sync, i.e. coincident
HS/VS edges. First, this patch adds hskew passed from the adjusted_mode to
reference pixel calculation to allow those controllers to add an offset
relative to the expected reference pixel.
Signed-off-by: Darren Etheridge
Si
This fixes the wrong sync generation and sync calculation of TDA998x
for HS/VS-based sync detection.
Signed-off-by: Sebastian Hesselbarth
Tested-by: Darren Etheridge
---
Changelog:
v1->v2:
- revert calculation of hs/de_pix_s/e (Reported by Russell King)
Cc: David Airlie
Cc: Darren Etheridge
C
From: Russell King
This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.
Signed-off-by: Russell King
Signed-off-by: Sebastian Hesselbarth
Tested-by: Darren Etherid
From: Russell King
The video-input-port (VIP) is highly configurable. This prepares
current driver to allow to configure VIP configuration, as some
boards connect lcd controller and TDA998x "pin-swapped" and depend
on VIP to swap the pins by register configuration.
Signed-off-by: Russell King
T
From: Russell King
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: Russell King
Tested-by: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren
From: Russell King
When switching between various drivers for this device, it's possible
that some critical registers are left containing values which affect
the device operation. One such case encountered is the VIP output
mux register. This defaults to 0x24 on powerup, but other drivers may
s
From: Russell King
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King
Signed-off-by: Rob Clark
Tested-by: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc
This patch set picks up several patches sent during the past months
related with NXP TDA998x HDMI transmitter driver. The patches have
been tested on Marvell Dove (Armada DRM) on several HDMI and DVI modes
with audio playing on S/PDIF.
I bumped all patches to v2, although only patches 2, 5, and 6
On Wed, Aug 14, 2013 at 06:19:03PM +0100, Damien Lespiau wrote:
> Follow up on v2:
> http://lists.freedesktop.org/archives/dri-devel/2013-August/043604.html
>
> With the quick and nice reviews from Ville and Simon, it's time for a v3:
> - Fix embarrassing hmdi typo
> - Fix the sending of ven
On Wed, Aug 14, 2013 at 06:19:10PM +0100, Damien Lespiau wrote:
> Provide the same programming model than the other infoframe types.
>
> The generic _pack() function can't handle those yet as we need to move
> the vendor OUI in the generic hdmi_vendor_infoframe structure to know
> which kind of ve
https://bugzilla.kernel.org/show_bug.cgi?id=60523
Tobias Droste changed:
What|Removed |Added
Kernel Version|drm-fixes-3.11 |drm-next-3.12-wip
Summary|Lock
On Wed, Aug 14, 2013 at 12:30:21PM -0400, Alex Deucher wrote:
> This adds a helper function to extract the speaker allocation
> data block from the EDID. This data block describes what speakers
> are present on the display device.
>
> v2: update per Ville Syrj?l?'s comments
> v3: fix copy/paste t
(CC'ing the proper people since I'm still on parental leave).
On 08/13/2013 11:44 PM, David Herrmann wrote:
Please see inline comments.
> Hi
>
> On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann
> wrote:
>> Correctly allow and revoke buffer access on each open/close via the new
>> VMA offset man
On Wed, Aug 14, 2013 at 12:08:13PM -0400, Alex Deucher wrote:
> This adds a helper function to extract the speaker allocation
> data block from the EDID. This data block describes what speakers
> are present on the display device.
>
> v2: update per Ville Syrj?l?'s comments
>
> Signed-off-by: Al
2013/8/14 Alex Deucher :
> +static u32 dce6_endpoint_rreg(struct radeon_device *rdev,
> + u32 block_offset, u32 reg)
> +{
> + u32 r;
> +
> + WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset, reg);
> + r = RREG32(AZ_F0_CODEC_ENDPOINT_DATA + block_offset)
With all the common infoframe bits now in place, we can finally write
the vendor specific infoframes in our driver.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 28
2 file
This can then be used by DRM drivers to setup their vendor infoframes.
v2: Fix hmdi typo (Simon Farnsworth)
Signed-off-by: Damien Lespiau
Reviewed-by: Simon Farnsworth
Reviewed-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_edid.c | 36
include/drm/drm_edid.h
With this last bit, hdmi_infoframe_pack() is now able to pack any
infoframe we support.
At the same time, because it's impractical to make two commits out of
this, we get rid of the version that encourages the open coding of the
vendor infoframe packing. We can do so because the only user of this
We'll need the HDMI OUI for the HDMI vendor infoframe data, so let's
move the DRM one to hdmi.h, might as well use the hdmi header to store
some hdmi defines.
(Note that, in fact, infoframes are part of the CEA-861 standard, and
only the HDMI vendor specific infoframe is special to HDMI, but
detai
I just wrote the bits to define and pack HDMI vendor specific infoframe.
Port the host1x driver to use those so I can refactor the infoframe code
a bit more.
This changes the length of the infoframe payload from 6 to 5, which is
enough for the "frame packing" stereo format.
v2: Pimp up the commit
Provide the same programming model than the other infoframe types.
The generic _pack() function can't handle those yet as we need to move
the vendor OUI in the generic hdmi_vendor_infoframe structure to know
which kind of vendor infoframe we are dealing with.
v2: Fix the value of Side-by-side (ha
Just like:
Author: Damien Lespiau
Date: Mon Aug 12 11:53:24 2013 +0100
video/hdmi: Don't let the user of this API create invalid infoframes
But this time for the horizontal/vertical bar data present bits.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrj?l?
---
drivers/video
To set the active aspect ratio value in the AVI infoframe today, you not
only have to set the active_aspect field, but also the active_info_valid
bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
_valid bit. This was fixed in:
Author: Damien Lespiau
Date: Tue Aug 6 20:3
v2: Fix hmdi typo (Simon Farnsworth, Ville Syrj?l?)
Suggested-by: Ville Syrj?l?
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrj?l?
Reviewed-by: Simon Farnsworth
---
drivers/gpu/drm/drm_edid.c | 68 ++
1 file changed, 62 insertions(+), 6 deleti
HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.
With this commit, we now parse this block and expose the 4k modes that
we find there.
v2: Fix the "4096x2160" string (nice catch!), add comments about
do_hdmi_vsdb_modes() arguments and make it clearer that offset is
re
A few styles issues have crept in here, fix them before touching this
code again.
v2: constify arguments that can be (Ville Syrj?l?)
v3: constify, but better (Ville Syrj?l?)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 12 +++-
1 file changed, 7 insertions(+), 5 deleti
This function is only used inside drm_edid.c.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_edid.c | 5 ++---
include/drm/drm_crtc.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid
Follow up on v2:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043604.html
With the quick and nice reviews from Ville and Simon, it's time for a v3:
- Fix embarrassing hmdi typo
- Fix the sending of vendor specific infoframes for side-by-side half modes
- Smaller changes here
Hi Dave,
Just two small fixes for radeon. One fixes an array overrun
that can cause garbage to get written to registers on some r7xx boards,
the other is a small UVD fix.
The following changes since commit e42f5814212079aecd5826dba10588a896ac0862:
Merge tag 'drm-intel-fixes-2013-08-08' of
gi
https://bugs.freedesktop.org/show_bug.cgi?id=67981
--- Comment #4 from Roland Scheidegger ---
FWIW maybe that patch really is a good idea. I don't really look at r200 much
these days, and since it doesn't really seem possible to change the format
later so we can render to it if necessary sacrific
Hi,
when changing the refresh rate of my laptop display with xrandr on 3.11.0-rc5,
like:
xrandr --output LVDS1 --rate 59.9 --mode 1920x1080
The following WARNING is generated:
[ 50.018055] [drm:intel_pipe_config_compare] *ERROR* mismatch in
adjusted_mode.flags (expected 1, found 0)
[ 50.01
hin 5 seconds of starting: bfgminer -v1 --benchmark
--
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/20130814/8bc5517a/attachment.html>
From: Darren Etheridge
Add a fixup function that will flip the hsync priority and
add a hskew value that is used to shift the tda998x to the
right by a variable number of pixels depending on the mode.
This works around an issue with the sync timings that tilcdc
is outputing.
Signed-off-by: Darre
This fixes the wrong sync generation and sync calculation of TDA998x
for HS/VS-based sync detection.
Signed-off-by: Sebastian Hesselbarth
Tested-by: Darren Etheridge
---
Changelog:
v1->v2:
- revert calculation of hs/de_pix_s/e (Reported by Russell King)
Cc: David Airlie
Cc: Darren Etheridge
C
Some LCD controller cannot provide valid VESA style sync, i.e. coincident
HS/VS edges. First, this patch adds hskew passed from the adjusted_mode to
reference pixel calculation to allow those controllers to add an offset
relative to the expected reference pixel.
Signed-off-by: Darren Etheridge
Si
From: Russell King
This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.
Signed-off-by: Russell King
Signed-off-by: Sebastian Hesselbarth
Tested-by: Darren Etherid
From: Russell King
The video-input-port (VIP) is highly configurable. This prepares
current driver to allow to configure VIP configuration, as some
boards connect lcd controller and TDA998x "pin-swapped" and depend
on VIP to swap the pins by register configuration.
Signed-off-by: Russell King
T
This patch set picks up several patches sent during the past months
related with NXP TDA998x HDMI transmitter driver. The patches have
been tested on Marvell Dove (Armada DRM) on several HDMI and DVI modes
with audio playing on S/PDIF.
I bumped all patches to v2, although only patches 2, 5, and 6
From: Russell King
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: Russell King
Tested-by: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren
From: Russell King
When switching between various drivers for this device, it's possible
that some critical registers are left containing values which affect
the device operation. One such case encountered is the VIP output
mux register. This defaults to 0x24 on powerup, but other drivers may
s
From: Russell King
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King
Signed-off-by: Rob Clark
Tested-by: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc
Hi,
when changing the refresh rate of my laptop display with xrandr on 3.11.0-rc5,
like:
xrandr --output LVDS1 --rate 59.9 --mode 1920x1080
The following WARNING is generated:
[ 50.018055] [drm:intel_pipe_config_compare] *ERROR* mismatch in
adjusted_mode.flags (expected 1, found 0)
[ 50.01
On Tue, Aug 06, 2013 at 12:20:16AM +0200, Sebastian Hesselbarth wrote:
> This fixes the wrong sync generation and sync calculation of TDA998x
> for HS/VS-based sync detection.
>
> Signed-off-by: Sebastian Hesselbarth
The plus point with this is that interlaced modes (1080i) do work with
the TDA9
On 08/14/13 14:41, Russell King - ARM Linux wrote:
On Tue, Aug 06, 2013 at 12:20:16AM +0200, Sebastian Hesselbarth wrote:
+ de_pix_s = mode->htotal - mode->hdisplay;
+ de_pix_e = de_pix_s + mode->hdisplay;
+ hs_pix_s = mode->hsync_start - mode->hdisplay;
+ hs_
On 08/14/13 16:12, Russell King - ARM Linux wrote:
On Tue, Aug 06, 2013 at 12:20:15AM +0200, Sebastian Hesselbarth wrote:
@@ -0,0 +1,23 @@
+#ifndef __TDA998X_H__
+#define __TDA998X_H__
+
+enum tda998x_audio_format {
+ AFMT_I2S,
+ AFMT_SPDIF,
+};
+
+struct tda998x_encoder_params {
+
On Tue, Aug 06, 2013 at 12:20:15AM +0200, Sebastian Hesselbarth wrote:
> @@ -0,0 +1,23 @@
> +#ifndef __TDA998X_H__
> +#define __TDA998X_H__
> +
> +enum tda998x_audio_format {
> + AFMT_I2S,
> + AFMT_SPDIF,
> +};
> +
> +struct tda998x_encoder_params {
> + int audio_cfg;
> + int audio_
On Tue, Aug 06, 2013 at 12:20:16AM +0200, Sebastian Hesselbarth wrote:
> + de_pix_s = mode->htotal - mode->hdisplay;
> + de_pix_e = de_pix_s + mode->hdisplay;
> + hs_pix_s = mode->hsync_start - mode->hdisplay;
> + hs_pix_e = hs_pix_s + mode->hsync_end - mode->hsync_s
On Tue, Aug 06, 2013 at 12:20:15AM +0200, Sebastian Hesselbarth wrote:
> - also calculate CTS
This is wrong...
> + /*
> + * HDMI 1.3a, 7.2.2 CTS parameter:
> + * (avg cts) = (fTMDS * N) / (128 * fS)
> + */
> + cts = n * mode->clock / p->audio_sample_rate;
> + cts *= 10
On Tue, Aug 06, 2013 at 12:20:11AM +0200, Sebastian Hesselbarth wrote:
> From: Russell King
>
> TDA19988 devices need their RAM enabled in order to read EDID
> information. Add support for this.
>
> Signed-off-by: Russell King
> Tested-by: Sebastian Hesselbarth
There was some debate about wh
On Tue, Aug 06, 2013 at 12:20:12AM +0200, Sebastian Hesselbarth wrote:
> switch (mode) {
> case DRM_MODE_DPMS_ON:
> + /* Write the default value MUX register */
> + reg_write(encoder, REG_MUX_VP_VIP_OUT, 0x24);
This looks like an old version of my patch. I ende
devm_kzalloc can fail. Hence check the pointer to avoid NULL pointer
dereferencing.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_iommu.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
b/drivers/gpu/drm/exynos/exynos
kzalloc already has built-in error messages. Hence remove
additional ones.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_buf.c |4 +---
drivers/gpu/drm/exynos/exynos_drm_connector.c |4 +---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |4 +---
drivers/gpu/
Add of.h explicitly for of_* APIs.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_ddc.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_fimc.c |1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c |1 +
drivers/gpu/drm/exynos/exynos_hdmi.c |1 +
drivers/gpu/drm/exynos/e
kfree handles null pointers. Hence this check is not necessary.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_buf.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index b8ac06d..7f4
From: Julia Lawall
Remove unneeded error handling on the result of a call to
platform_get_resource when the value is passed to devm_ioremap_resource.
Move the call to platform_get_resource adjacent to the call to
devm_ioremap_resource to make the connection between them more clear.
A simplified
devm_ioremap_resource often uses the result of a call to
platform_get_resource as its last argument. devm_ioremap_resource does
appropriate error handling on this argument, so error handling can be
removed from the call site. To make the connection between the call to
platform_get_resource and th
On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
> On 13/08/2013 09:53, Pali Rohár wrote:
> > On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres
wrote:
> >> On 13/08/2013 09:23, Pali Rohár wrote:
> >>> On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
> >> ...
> >>
> >> You can c
AFAICS, there are more updates needed to be in sync with recent kernel-drm.
I fell over the misspelling when digging into an issue in Linux-next.
The spelling should be consistent in kernel-drm, libdrm, intel-ddx, etc.
Here, I had a look especially at the defined macros (defines).
Signed-off-by:
https://bugzilla.kernel.org/show_bug.cgi?id=60674
--- Comment #9 from Yves G. (theYinYeti) ---
Sorry for the long time without an answer; I was on holidays. Just to be clear:
the kernel (and associated packages for my setup) is the only component that
changes; here?s the exact list: linux, linux-
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130814/01afe448/attachment.html>
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
d
This patch adds the notion of a drm_bridge. A bridge is a chained
device which hangs off an encoder. The drm driver using the bridge
should provide the association between encoder and bridge. Once a
bridge is associated with an encoder, it will participate in mode
set, and dpms (via the enable/disa
This patchset adds the drm_bridge abstraction as well as the PTN3460
DisplayPort to LVDS bridge driver (using drm_bridge, of course).
Changed in v2:
- Added PTN3460 driver to show drm_bridge usage
- Removed connector detect() re-route in favor of implementing the connector
in the bridge drive
https://bugs.freedesktop.org/show_bug.cgi?id=66805
--- Comment #24 from Tom Stellard ---
This should be fixed now. Can you try they latest versions of llvm and mesa?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-de
devm_kzalloc can fail. Hence check the pointer to avoid NULL pointer
dereferencing.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_iommu.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
b/drivers/gpu/drm/exynos/exynos
kzalloc already has built-in error messages. Hence remove
additional ones.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_buf.c |4 +---
drivers/gpu/drm/exynos/exynos_drm_connector.c |4 +---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |4 +---
drivers/gpu/
Add of.h explicitly for of_* APIs.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_ddc.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_fimc.c |1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c |1 +
drivers/gpu/drm/exynos/exynos_hdmi.c |1 +
drivers/gpu/drm/exynos/e
kfree handles null pointers. Hence this check is not necessary.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_buf.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index b8ac06d..7f4
On 08/14/13 16:12, Russell King - ARM Linux wrote:
> On Tue, Aug 06, 2013 at 12:20:15AM +0200, Sebastian Hesselbarth wrote:
>> @@ -0,0 +1,23 @@
>> +#ifndef __TDA998X_H__
>> +#define __TDA998X_H__
>> +
>> +enum tda998x_audio_format {
>> +AFMT_I2S,
>> +AFMT_SPDIF,
>> +};
>> +
>> +struct tda99
Op 14-08-13 15:07, David Herrmann schreef:
> There is no reason to keep the gem object separately allocated. nouveau is
> the last user of gem_obj->driver_private, so if we embed it, we can get
> rid of 8bytes per gem-object.
>
> The implementation follows the radeon driver. bo->gem is only valid,
https://bugs.freedesktop.org/show_bug.cgi?id=68125
--- Comment #3 from Andreas Bombe ---
(In reply to comment #1)
> Can you bisect?
I will have a go at it tomorrow then. That is going to be very time consuming,
I expect, what with the bug only showing itself after quite some time.
What I also
On 08/14/13 14:41, Russell King - ARM Linux wrote:
> On Tue, Aug 06, 2013 at 12:20:16AM +0200, Sebastian Hesselbarth wrote:
>> +de_pix_s = mode->htotal - mode->hdisplay;
>> +de_pix_e = de_pix_s + mode->hdisplay;
>> +hs_pix_s = mode->hsync_start - mode->hdisplay;
>> +hs_p
https://bugs.freedesktop.org/show_bug.cgi?id=68125
--- Comment #2 from Andreas Bombe ---
Created attachment 84076
--> https://bugs.freedesktop.org/attachment.cgi?id=84076&action=edit
associated Xorg.log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=68125
--- Comment #1 from Alex Deucher ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.f
https://bugs.freedesktop.org/show_bug.cgi?id=68125
Priority: medium
Bug ID: 68125
Assignee: dri-devel@lists.freedesktop.org
Summary: Radeon HD6950: Failed to parse relocation -35 (Linux
3.11-rc regression)
Severity: major
> >> > Turning to DRM/KMS, it seems the supported formats of a plane
> >> > can be queried using drm_mode_get_plane. However, there doesn't
> >> > seem to be a way to query the supported formats of a crtc? If
> >> > display HW only supports scanning out from a single buffer
> >> > (like pl111 d
> >> > > > So in the above, after X receives the second DRI2SwapBuffers,
> >> > > > it doesn't need to get scheduled again for the next frame to
> >> > > > be both rendered by the GPU and issued to the display for
> >> > > > scanout.
> >> > >
> >> > > well, this is really only an issue if you ar
Hi Dave,
Just two small fixes for radeon. One fixes an array overrun
that can cause garbage to get written to registers on some r7xx boards,
the other is a small UVD fix.
The following changes since commit e42f5814212079aecd5826dba10588a896ac0862:
Merge tag 'drm-intel-fixes-2013-08-08' of
gi
... not only when the dma-buf is freshly created. In contrived
examples someone else could have exported/imported the dma-buf already
and handed us the gem object with a flink name. If such on object gets
reexported as a dma_buf we won't have it in the handle cache already,
which breaks the guarant
On Tue, Aug 06, 2013 at 12:20:16AM +0200, Sebastian Hesselbarth wrote:
> This fixes the wrong sync generation and sync calculation of TDA998x
> for HS/VS-based sync detection.
>
> Signed-off-by: Sebastian Hesselbarth
The plus point with this is that interlaced modes (1080i) do work with
the TDA9
... and move it to the top of the function to avoid a forward
declaration.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 29 +++--
include/drm/drmP.h | 1 -
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_pri
with the reworking semantics and locking of the obj->dma_buf pointer
this pointer is always set as long as there's still a gem handle
around and a dma_buf associated with this gem object.
Also, the per file-priv lookup-cache for dma-buf importing is also
unified between foreign and native objects.
The export dma-buf cache is semantically similar to an flink name. So
semantically it makes sense to treat it the same and remove the name
(i.e. the dma_buf pointer) and its references when the last gem handle
disappears.
Again we need to be careful, but double so: Not just could someone
race and
On Wed, Aug 14, 2013 at 03:07:13PM +0200, David Herrmann wrote:
> Hi
>
> This series removes any access to gem_obj->driver_private from all drivers and
> then drops drm_gem_object_alloc() with its ->gem_init_object() driver
> callback.
>
> All this is only needed if a gem object is not embedded
The gem flink name holds a reference onto the object itself, and this
self-reference would prevent an flink'ed object from every being
freed. To break that loop we remove the flink name when the last
userspace handle disappears, i.e. when obj->handle_count reaches 0.
Now in gem_open we drop the de
1 - 100 of 279 matches
Mail list logo
