drm-next-4.1-wip: NI/Turks *ERROR* chosen encoder in use 4
On 26 February 2015 at 06:22, Alex Deucher wrote: > On Tue, Feb 24, 2015 at 11:20 PM, Dieter Nützel > wrote: >> Hello Alex, >> >> I get this in dmesg: >> >> [ 26.001926] [drm:radeon_atom_pick_dig_encoder [radeon]] *ERROR* chosen >> encoder in use 4 >> >> What do you need? > > The message is harmless I think. It's just debugging output from the > DP MST patches. I think what's happening is that when you change the > mode on an encoder that is already enabled, it see that the encoder is > already in use (by itself). I think the fix would be to call > radeon_atom_release_dig_encoder() in the encoder prepare callback, but > I'm not sure if that will negatively affect MST or not. Dave? well we can drop the message down to debug_kms, I'll have a look to see if we need to do a release there, its probably safe but I'd have to test it. Dave.
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit 62e537f8d568
("drm/i915: Fix frontbuffer false positve") from the drm-intel-fixes
tree and commit 6a418fcd84d6 ("drm/i915: Use fb modifiers in
intel_check_cursor_plane") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index 3117679299a6,2ac93909cfc5..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -2371,11 -2376,8 +2376,12 @@@ intel_alloc_plane_obj(struct intel_crt
struct drm_device *dev = crtc->base.dev;
struct drm_i915_gem_object *obj = NULL;
struct drm_mode_fb_cmd2 mode_cmd = { 0 };
+ struct drm_framebuffer *fb = &plane_config->fb->base;
- u32 base = plane_config->base;
+ u32 base_aligned = round_down(plane_config->base, PAGE_SIZE);
+ u32 size_aligned = round_up(plane_config->base + plane_config->size,
+ PAGE_SIZE);
+
+ size_aligned -= base_aligned;
if (plane_config->size == 0)
return false;
@@@ -6640,9 -6678,10 +6693,10 @@@ i9xx_get_initial_plane_config(struct in
fb->pitches[0] = val & 0xffc0;
aligned_height = intel_fb_align_height(dev, fb->height,
- plane_config->tiling);
+ fb->pixel_format,
+ fb->modifier[0]);
- plane_config->size = PAGE_ALIGN(fb->pitches[0] * aligned_height);
+ plane_config->size = fb->pitches[0] * aligned_height;
DRM_DEBUG_KMS("pipe/plane %c/%d with fb: size=%dx%d@%d, offset=%x,
pitch %d, size 0x%x\n",
pipe_name(pipe), plane, fb->width, fb->height,
@@@ -7677,9 -7721,10 +7736,10 @@@ skylake_get_initial_plane_config(struc
fb->pitches[0] = (val & 0x3ff) * stride_mult;
aligned_height = intel_fb_align_height(dev, fb->height,
- plane_config->tiling);
+ fb->pixel_format,
+ fb->modifier[0]);
- plane_config->size = ALIGN(fb->pitches[0] * aligned_height, PAGE_SIZE);
+ plane_config->size = fb->pitches[0] * aligned_height;
DRM_DEBUG_KMS("pipe %c with fb: size=%dx%d@%d, offset=%x, pitch %d,
size 0x%x\n",
pipe_name(pipe), fb->width, fb->height,
@@@ -7768,9 -7818,10 +7833,10 @@@ ironlake_get_initial_plane_config(struc
fb->pitches[0] = val & 0xffc0;
aligned_height = intel_fb_align_height(dev, fb->height,
- plane_config->tiling);
+ fb->pixel_format,
+ fb->modifier[0]);
- plane_config->size = PAGE_ALIGN(fb->pitches[0] * aligned_height);
+ plane_config->size = fb->pitches[0] * aligned_height;
DRM_DEBUG_KMS("pipe %c with fb: size=%dx%d@%d, offset=%x, pitch %d,
size 0x%x\n",
pipe_name(pipe), fb->width, fb->height,
@@@ -12197,9 -12188,10 +12203,7 @@@ intel_check_cursor_plane(struct drm_pla
return -ENOMEM;
}
- /* we only need to pin inside GTT if cursor is non-phy */
- mutex_lock(&dev->struct_mutex);
- if (!INTEL_INFO(dev)->cursor_needs_physical && obj->tiling_mode) {
- if (fb == crtc->cursor->fb)
- return 0;
-
+ if (fb->modifier[0] != DRM_FORMAT_MOD_NONE) {
DRM_DEBUG_KMS("cursor cannot be tiled\n");
ret = -EINVAL;
}
------ next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/b67d267e/attachment.sig>
[PATCH 1/8] clk: add helper function clk_is_match()
On Wed, Feb 25, 2015 at 09:27:57AM -0800, Mike Turquette wrote:
> Hi Shawn,
>
> Thanks for the patch. I wrote a similar one last night but did not
> finish fixing up the drivers (and thus did not post it). I prefer my
> implementation below, and I'm happy to merge your driver fixes with it.
Sure, no problem. My intention was to get rmk's HummingBoard back to
work ASAP :)
> From: Michael Turquette
> Date: Wed, 25 Feb 2015 09:11:01 -0800
> Subject: [PATCH] clk: introduce clk_is_match
>
> Some drivers compare struct clk pointers as a means of knowing
> if the two pointers reference the same clock hardware. This behavior is
> dubious (drivers must not dereference struct clk), but did not cause any
> regressions until the per-user struct clk patch was merged. Now the test
> for matching clk's will always fail with per-user struct clk's.
>
> clk_is_match is introduced to fix the regression and prevent drivers
> from comparing the pointers manually.
>
> Fixes: 035a61c314eb ("clk: Make clk API return per-user struct clk instances")
> Cc: Russell King
> Cc: Stephen Boyd
> Cc: Shawn Guo
Tested-by: Shawn Guo
> Cc: Tomeu Vizoso
> Signed-off-by: Michael Turquette
[Bug 89327] Loss of HDMI audio on auto screen off (energy saving)
https://bugs.freedesktop.org/show_bug.cgi?id=89327 --- Comment #8 from Dieter Nützel --- (In reply to Dieter Nützel from comment #7) > (In reply to Alex Deucher from comment #6) > > Can you bisect? > > So I have to go before your -rc1 merge? Alex, my reportet drm-next-4.1-wip error [drm:radeon_atom_pick_dig_encoder [radeon]] *ERROR* chosen encoder in use 4 is related to this. If I reenable audio with xrandr --output HDMI-0 --set audio on I get next line in dmesg. 2cond time do NOT work but xrandr --output HDMI-0 --set audio auto do?! Is this right? [4.722072] snd_hda_intel :01:00.1: Handle VGA-switcheroo audio client There is no other 'enable audio' in dmesg. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/0d8509c9/attachment.html>
[PATCH 7/8] ASoC: fsl_spdif: fix struct clk pointer comparing
On Wed, Feb 25, 2015 at 01:04:41PM -0800, Stephen Boyd wrote:
> > diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
> > index 75870c0ea2c9..91eb3aef7f02 100644
> > --- a/sound/soc/fsl/fsl_spdif.c
> > +++ b/sound/soc/fsl/fsl_spdif.c
> > @@ -1049,7 +1049,7 @@ static u32 fsl_spdif_txclk_caldiv(struct
> > fsl_spdif_priv *spdif_priv,
> > enum spdif_txrate index, bool round)
> > {
> > const u32 rate[] = { 32000, 44100, 48000, 96000, 192000 };
> > - bool is_sysclk = clk == spdif_priv->sysclk;
> > + bool is_sysclk = clk_is_match(clk, spdif_priv->sysclk);
> > u64 rate_ideal, rate_actual, sub;
> > u32 sysclk_dfmin, sysclk_dfmax;
> > u32 txclk_df, sysclk_df, arate;
> > @@ -1143,7 +1143,7 @@ static int fsl_spdif_probe_txclk(struct
> > fsl_spdif_priv *spdif_priv,
> > spdif_priv->txclk_src[index], rate[index]);
> > dev_dbg(&pdev->dev, "use txclk df %d for %dHz sample rate\n",
> > spdif_priv->txclk_df[index], rate[index]);
> > - if (spdif_priv->txclk[index] == spdif_priv->sysclk)
> > + if (clk_is_match(spdif_priv->txclk[index], spdif_priv->sysclk))
> > dev_dbg(&pdev->dev, "use sysclk df %d for %dHz sample rate\n",
> > spdif_priv->sysclk_df[index], rate[index]);
> > dev_dbg(&pdev->dev, "the best rate for %dHz sample rate is %dHz\n",
>
> Couldn't this be fixed like this?
It could. But this fix is less-intuitive and makes the code change
unnecessarily complex, considering we are introducing helper
clk_is_match() anyway.
Shawn
>
> 8<
>
> diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
> index af0429421fc8..1878dd62a247 100644
> --- a/sound/soc/fsl/fsl_spdif.c
> +++ b/sound/soc/fsl/fsl_spdif.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -46,6 +47,8 @@ static u8 srpc_dpll_locked[] = { 0x0, 0x1, 0x2, 0x3, 0x4,
> 0xa, 0xb };
>
> #define DEFAULT_RXCLK_SRC1
>
> +#define SYSCLK_NUM 5
> +
> /*
> * SPDIF control structure
> * Defines channel status, subcode and Q sub
> @@ -1051,10 +1054,10 @@ static const struct regmap_config
> fsl_spdif_regmap_config = {
>
> static u32 fsl_spdif_txclk_caldiv(struct fsl_spdif_priv *spdif_priv,
> struct clk *clk, u64 savesub,
> - enum spdif_txrate index, bool round)
> + enum spdif_txrate index, bool round,
> + bool is_sysclk)
> {
> const u32 rate[] = { 32000, 44100, 48000, 96000, 192000 };
> - bool is_sysclk = clk == spdif_priv->sysclk;
> u64 rate_ideal, rate_actual, sub;
> u32 sysclk_dfmin, sysclk_dfmax;
> u32 txclk_df, sysclk_df, arate;
> @@ -1131,7 +1134,8 @@ static int fsl_spdif_probe_txclk(struct fsl_spdif_priv
> *spdif_priv,
> continue;
>
> ret = fsl_spdif_txclk_caldiv(spdif_priv, clk, savesub, index,
> - i == STC_TXCLK_SPDIF_ROOT);
> + i == STC_TXCLK_SPDIF_ROOT,
> + i == SYSCLK_NUM);
> if (savesub == ret)
> continue;
>
> @@ -1210,7 +1214,8 @@ static int fsl_spdif_probe(struct platform_device *pdev)
> }
>
> /* Get system clock for rx clock rate calculation */
> - spdif_priv->sysclk = devm_clk_get(&pdev->dev, "rxtx5");
> + spdif_priv->sysclk = devm_clk_get(&pdev->dev,
> + "rxtx" __stringify(SYSCLK_NUM));
> if (IS_ERR(spdif_priv->sysclk)) {
> dev_err(&pdev->dev, "no sys clock (rxtx5) in devicetree\n");
> return PTR_ERR(spdif_priv->sysclk);
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
[PATCH 0/8] Fix struct clk pointer comparing
On Wed, Feb 25, 2015 at 12:42:45PM -0800, Stephen Boyd wrote: > On 02/25/15 09:55, Mike Turquette wrote: > > Quoting Russell King - ARM Linux (2015-02-25 07:03:49) > >> Case 1 applies in places like the Kirkwood I2S driver, and the iMX6 > >> ethernet code, and it's these cases which need to be fixed. > >> > >> Case 2 applies in the Armada DRM driver, and these cases need not be > >> "fixed". > >> > >> To put it a different way: case 1 is when you're testing to see whether > >> two clocks refer to the same clock. case 2 is when you're testing > >> whether the cached clk cookie is the same. > > It looks like patches 2, 7 and 8 are correct in this series. I'll apply > > them towards -rc2 if nobody objects. > > > > > > For patch 8 can't we use the alternative patch that I came up with > before? I have a patch for sound/soc/fsl/fsl_esai.c and > drivers/pwm/pwm-atmel-hlcdc.c which I can send shortly. This beats the idea of clk_is_match() helper. I prefer to fix this generic problem in a generic way, i.e. using clk_is_match(), which should be much easier and safer during -rc cycle. Shawn
[PATCH] drm/radeon: release digital encoder before asking for new one.
From: Dave Airlie
This stops a DRM_ERROR that says we already used the encoder.
Reported-by: Dieter Nützel
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/atombios_encoders.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index e8fe2b7..0f46f68 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -2465,6 +2465,8 @@ static void radeon_atom_encoder_prepare(struct
drm_encoder *encoder)
ENCODER_OBJECT_ID_NONE)) {
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
if (dig) {
+ if (dig->dig_encoder >= 0)
+ radeon_atom_release_dig_encoder(rdev,
dig->dig_encoder);
dig->dig_encoder =
radeon_atom_pick_dig_encoder(encoder, -1);
if (radeon_encoder->active_device &
ATOM_DEVICE_DFP_SUPPORT) {
if (rdev->family >= CHIP_R600)
--
2.1.0
[PATCH 7/8] ASoC: fsl_spdif: fix struct clk pointer comparing
On Thu, Feb 26, 2015 at 11:12:50AM +0900, Mark Brown wrote:
> On Wed, Feb 25, 2015 at 10:53:37PM +0800, Shawn Guo wrote:
> > Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> > instances"), clk API users can no longer check if two struct clk
> > pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
>
> Applied, thanks.
Mark,
Sorry that I did not make it clear in the cover-letter. But the first
patch introduces a helper function clk_is_match(), on which all the
other patches in the series depend. That said, the patch series should
probably be handled by Mike as a whole.
Shawn
drm-next-4.1-wip: NI/Turks *ERROR* chosen encoder in use 4
Am 25.02.2015 23:02, schrieb Dave Airlie: > On 26 February 2015 at 06:22, Alex Deucher > wrote: >> On Tue, Feb 24, 2015 at 11:20 PM, Dieter Nützel >> wrote: >>> Hello Alex, >>> >>> I get this in dmesg: >>> >>> [ 26.001926] [drm:radeon_atom_pick_dig_encoder [radeon]] *ERROR* >>> chosen >>> encoder in use 4 >>> >>> What do you need? >> >> The message is harmless I think. It's just debugging output from the >> DP MST patches. I think what's happening is that when you change the >> mode on an encoder that is already enabled, it see that the encoder is >> already in use (by itself). I think the fix would be to call >> radeon_atom_release_dig_encoder() in the encoder prepare callback, but >> I'm not sure if that will negatively affect MST or not. Dave? > > well we can drop the message down to debug_kms, I'll have a look > to see if we need to do a release there, its probably safe but I'd have > to > test it. > > Dave. Fixed in (new) drm-next-4.1-wip by commit: 2248a6a41473e4a77391a2163284fe0683eac165 Thanks Dave and Alex! -Dieter
[PATCH] drm/radeon: release digital encoder before asking for new one.
Am 26.02.2015 03:05, schrieb Alex Deucher:
> On Wed, Feb 25, 2015 at 8:32 PM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This stops a DRM_ERROR that says we already used the encoder.
>>
>> Reported-by: Dieter Nützel
>> Signed-off-by: Dave Airlie
>
> I've squashed this into the appropriate patch and pushed a new 4.1-wip
> tree.
>
> Alex
Up and running.
Thanks!
-â Dieter
>> ---
>> drivers/gpu/drm/radeon/atombios_encoders.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
>> b/drivers/gpu/drm/radeon/atombios_encoders.c
>> index e8fe2b7..0f46f68 100644
>> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
>> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
>> @@ -2465,6 +2465,8 @@ static void radeon_atom_encoder_prepare(struct
>> drm_encoder *encoder)
>> ENCODER_OBJECT_ID_NONE)) {
>> struct radeon_encoder_atom_dig *dig =
>> radeon_encoder->enc_priv;
>> if (dig) {
>> + if (dig->dig_encoder >= 0)
>> + radeon_atom_release_dig_encoder(rdev,
>> dig->dig_encoder);
>> dig->dig_encoder =
>> radeon_atom_pick_dig_encoder(encoder, -1);
>> if (radeon_encoder->active_device &
>> ATOM_DEVICE_DFP_SUPPORT) {
>> if (rdev->family >= CHIP_R600)
>> --
>> 2.1.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/15] ARM: shmobile: lager: Add DU HDMI output support
On Thu, Dec 11, 2014 at 01:42:11AM +0200, Laurent Pinchart wrote:
> Add DT nodes for the ADV7511 HDMI encoder and its HDMI output connector.
>
> Signed-off-by: Laurent Pinchart
Thanks, I have queued this up.
> ---
> arch/arm/boot/dts/r8a7790-lager.dts | 48
> +
> 1 file changed, 48 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
> b/arch/arm/boot/dts/r8a7790-lager.dts
> index 59365bccc945..749fe841aa09 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -222,6 +222,17 @@
> };
> };
> };
> +
> + hdmi-out {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con: endpoint {
> + remote-endpoint = <&adv7511_out>;
> + };
> + };
> + };
> };
>
> &du {
> @@ -235,6 +246,11 @@
> remote-endpoint = <&adv7123_in>;
> };
> };
> + port at 1 {
> + endpoint {
> + remote-endpoint = <&adv7511_in>;
> + };
> + };
> port at 2 {
> lvds_connector: endpoint {
> };
> @@ -504,6 +520,38 @@
> };
> };
> };
> +
> + hdmi at 39 {
> + compatible = "adi,adv7511w";
> + reg = <0x39>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
> +
> + adi,input-depth = <8>;
> + adi,input-colorspace = "rgb";
> + adi,input-clock = "1x";
> + adi,input-style = <1>;
> + adi,input-justification = "evenly";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + adv7511_in: endpoint {
> + remote-endpoint = <&du_out_lvds0>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <&hdmi_con>;
> + };
> + };
> + };
> + };
> };
>
> &iic3 {
> --
> 2.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[PATCH 8/8] ASoC: kirkwood: fix struct clk pointer comparing
On Wed, Feb 25, 2015 at 10:53:38PM +0800, Shawn Guo wrote:
> Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> instances"), clk API users can no longer check if two struct clk
> pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
Applied, thanks.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/130aa66d/attachment-0001.sig>
[PATCH 7/8] ASoC: fsl_spdif: fix struct clk pointer comparing
On Wed, Feb 25, 2015 at 10:53:37PM +0800, Shawn Guo wrote:
> Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> instances"), clk API users can no longer check if two struct clk
> pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
Applied, thanks.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/acd119b1/attachment-0001.sig>
[PATCH 7/8] ASoC: fsl_spdif: fix struct clk pointer comparing
On Thu, Feb 26, 2015 at 10:20:00AM +0800, Shawn Guo wrote: > Sorry that I did not make it clear in the cover-letter. But the first > patch introduces a helper function clk_is_match(), on which all the > other patches in the series depend. That said, the patch series should > probably be handled by Mike as a whole. Ugh, right. I've dropped those patches then. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/0cf9f199/attachment-0001.sig>
[PATCH 7/8] ASoC: fsl_spdif: fix struct clk pointer comparing
On Wed, Feb 25, 2015 at 10:53:37PM +0800, Shawn Guo wrote:
> Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> instances"), clk API users can no longer check if two struct clk
> pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
Acked-by: Mark Brown
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/f40b117a/attachment.sig>
[PATCH 8/8] ASoC: kirkwood: fix struct clk pointer comparing
On Wed, Feb 25, 2015 at 10:53:38PM +0800, Shawn Guo wrote:
> Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> instances"), clk API users can no longer check if two struct clk
> pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
Acked-by: Mark Brown
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/0555aca7/attachment.sig>
[PATCH 6/8] ASoC: fsl_esai: fix struct clk pointer comparing
On Wed, Feb 25, 2015 at 10:53:36PM +0800, Shawn Guo wrote:
> Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> instances"), clk API users can no longer check if two struct clk
> pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
Acked-by: Mark Brown
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/a789c434/attachment-0001.sig>
[Bug 89327] Loss of HDMI audio on auto screen off (energy saving)
https://bugs.freedesktop.org/show_bug.cgi?id=89327 --- Comment #9 from John --- Created attachment 113833 --> https://bugs.freedesktop.org/attachment.cgi?id=113833&action=edit john's dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/0cdfa5aa/attachment.html>
[Bug 89327] Loss of HDMI audio on auto screen off (energy saving)
https://bugs.freedesktop.org/show_bug.cgi?id=89327 --- Comment #10 from John --- Created attachment 113834 --> https://bugs.freedesktop.org/attachment.cgi?id=113834&action=edit john's xorg.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/20150226/1dff73dd/attachment.html>
[Bug 89327] Loss of HDMI audio on auto screen off (energy saving)
https://bugs.freedesktop.org/show_bug.cgi?id=89327 --- Comment #11 from John --- (In reply to Dieter Nützel from comment #2) > (In reply to John from comment #0) > > Since moving to 4.0-rc1 when my screen goes off (energy saving), I lose the > > hdmi audio, standard stuff. > > When I move the mouse I get the screen back but not the audio anymore. > > Switching it back on with xrandr works. > > > > Thanks > > Can you please attach the 'right' xrandr line, please? > I do not hear anything after screen goes off (energy saving) with > drm-next-4.1-wip on r600/NI/Turks, too. > > So it seems to be not only with radeonsi. > > -Dieter xrandr --output HDMI-0 --set audio on works for me -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/16a5350b/attachment.html>
[Bug 89327] Loss of HDMI audio on auto screen off (energy saving)
https://bugs.freedesktop.org/show_bug.cgi?id=89327 --- Comment #12 from Dieter Nützel --- Bisected 6f945693be7eea24b1a8e5ce252a96df98d55a5c is the first bad commit commit 6f945693be7eea24b1a8e5ce252a96df98d55a5c Author: Slava Grigorev Date: Wed Dec 10 14:52:43 2014 -0500 radeon/audio: applied audio_dpms() and audio_mode_set() calls Reviewed-by: Christian König Signed-off-by: Slava Grigorev Signed-off-by: Alex Deucher :04 04 33622643fd03f2afac723aa1356fe9c638a8fb3c fac1a0f988f61f513a75af0b0e554246d500 M drivers git bisect start # bad: [308de41ba3bde80d50833718a2e37e49be868f5a] drm/radeon: use NULL rather then 0 in audio detect git bisect bad 308de41ba3bde80d50833718a2e37e49be868f5a # good: [49ead33b9f0e0ba0b528951a05986486196848ef] drm/radeon: comment out some currently unused 7xx dpm code git bisect good 49ead33b9f0e0ba0b528951a05986486196848ef # good: [64424d6e45aeee311a4231def7e125bcc2de0855] radeon/audio: consolidate update_acr() functions (v2) git bisect good 64424d6e45aeee311a4231def7e125bcc2de0855 # good: [3be2e7d0e705621c1bb41eeabb63b122d50ecff3] radeon/audio: moved mute programming to a separate function git bisect good 3be2e7d0e705621c1bb41eeabb63b122d50ecff3 # bad: [6f945693be7eea24b1a8e5ce252a96df98d55a5c] radeon/audio: applied audio_dpms() and audio_mode_set() calls git bisect bad 6f945693be7eea24b1a8e5ce252a96df98d55a5c # good: [6e72376dcc663e4b8a00cdd08f61a8623f572ef1] radeon/audio: consolidate audio_mode_set() functions git bisect good 6e72376dcc663e4b8a00cdd08f61a8623f572ef1 # first bad commit: [6f945693be7eea24b1a8e5ce252a96df98d55a5c] radeon/audio: applied audio_dpms() and audio_mode_set() calls -- 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/20150226/e0b195de/attachment-0001.html>
[Bug 89327] Loss of HDMI audio on auto screen off (energy saving)
https://bugs.freedesktop.org/show_bug.cgi?id=89327 --- Comment #13 from Dieter Nützel --- But I can't revert commit 6f94569 on top of HEAD. During some restarts I got this in dmesg: [4.159787] [drm:btc_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed And my reported r600 - NI/Turks: flickering with 'geom-outlining-150' seems to be related!? It was first gone under drm-next-4.1-wip but arise with going bak to drm-next-3.20-wip (3.19-rc5). I had to power down my system to get it back after 'git bisect reset' and got the above messages during some power cycles. -- 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/20150226/2da78427/attachment.html>
r600 - NI/Turks: flickering with 'geom-outlining-150'
Am 25.02.2015 22:50, schrieb Dieter Nützel: > Am 25.02.2015 09:31, schrieb Michel Dänzer: >> On 25.02.2015 13:04, Dieter Nützel wrote: >>> Am 20.02.2015 17:29, schrieb Alex Deucher: On Fri, Feb 20, 2015 at 10:54 AM, Dieter Nützel wrote: > Hello Alex, > > I get _today_ flickering with Mesa-demo 'geom-outlining-150'. > It worked OK last night and I've reseted Mesa git back to 5c1aac1 > but NO > success. > Only thing is I've used LLVM git of today, too and for GOOD result > LLVM > from 18th. > Any hints? > Please narrow it down to what update caused the issue and then use git to bisect. Alex >>> >>> Couldn't find a GOOD version (Mesa/LLVM) for bisect start so far. >>> I've to search further. >> >> Note that the r600g driver doesn't use LLVM for graphics shader >> compilation, so you should only need to search in Mesa and maybe the >> kernel or libdrm. > > Thanks for the hint Michel. > > But, ughhh... > ...in the minute it WORKS without a hitch! > > I'm running a new LLVM compilation with 4 cores and thought try it. > > System spec: > Mesa 10.6.0-devel (git-cb25087) > libdrm-2.4.59 (minor distro update on 24th) > Linux 4.0.0-rc1-2.g1133f88-desktop+ (drm-next-4.1, 50c7535, 23 hours > ago) > > I'll freeze LLVM (do not install latest compile) and try to bisect > Mesa (?) 'cause kernel and libdrm did NOT changed compared to tests > last night. Michel, it seems to be radeon drm ((HDMI) audio_dpms) related. Have a look here: https://bugs.freedesktop.org/show_bug.cgi?id=89327 Greetings, Dieter
[Bug 89327] Loss of HDMI audio on auto screen off (energy saving)
https://bugs.freedesktop.org/show_bug.cgi?id=89327 --- Comment #14 from John --- (In reply to Dieter Nützel from comment #12) > Bisected > > 6f945693be7eea24b1a8e5ce252a96df98d55a5c is the first bad commit > commit 6f945693be7eea24b1a8e5ce252a96df98d55a5c > Author: Slava Grigorev > Date: Wed Dec 10 14:52:43 2014 -0500 > > radeon/audio: applied audio_dpms() and audio_mode_set() calls > > Reviewed-by: Christian König > Signed-off-by: Slava Grigorev > Signed-off-by: Alex Deucher > > :04 04 33622643fd03f2afac723aa1356fe9c638a8fb3c > fac1a0f988f61f513a75af0b0e554246d500 M drivers > > git bisect start > # bad: [308de41ba3bde80d50833718a2e37e49be868f5a] drm/radeon: use NULL > rather then 0 in audio detect > git bisect bad 308de41ba3bde80d50833718a2e37e49be868f5a > # good: [49ead33b9f0e0ba0b528951a05986486196848ef] drm/radeon: comment out > some currently unused 7xx dpm code > git bisect good 49ead33b9f0e0ba0b528951a05986486196848ef > # good: [64424d6e45aeee311a4231def7e125bcc2de0855] radeon/audio: consolidate > update_acr() functions (v2) > git bisect good 64424d6e45aeee311a4231def7e125bcc2de0855 > # good: [3be2e7d0e705621c1bb41eeabb63b122d50ecff3] radeon/audio: moved mute > programming to a separate function > git bisect good 3be2e7d0e705621c1bb41eeabb63b122d50ecff3 > # bad: [6f945693be7eea24b1a8e5ce252a96df98d55a5c] radeon/audio: applied > audio_dpms() and audio_mode_set() calls > git bisect bad 6f945693be7eea24b1a8e5ce252a96df98d55a5c > # good: [6e72376dcc663e4b8a00cdd08f61a8623f572ef1] radeon/audio: consolidate > audio_mode_set() functions > git bisect good 6e72376dcc663e4b8a00cdd08f61a8623f572ef1 > # first bad commit: [6f945693be7eea24b1a8e5ce252a96df98d55a5c] radeon/audio: > applied audio_dpms() and audio_mode_set() calls Based on the commit's name I'd say it looks like a good match. Thank you for doing the bisecting instead of me :) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/1cef4998/attachment.html>
[PATCH RESEND] drm: tda998x: Use drm_do_get_edid()
Hi Russell, On Friday 16 January 2015 17:47:34 Russell King - ARM Linux wrote: > On Fri, Jan 16, 2015 at 06:37:43PM +0200, Laurent Pinchart wrote: > > Replace the internal EDID read implementation by a call to the new EDID > > read core function. > > > > Signed-off-by: Laurent Pinchart > > > > Reviewed-by: Rob Clark > > Tested-by: Jean-Francois Moine > > Thanks, committed, and updated the summary line to: > > "drm/i2c: tda998x: use drm_do_get_edid()" > > to match the style used in the past. I can't see the patch in Dave's -next branch, has it been lost somewhere ? -- Regards, Laurent Pinchart
[PATCH] drm: exynos: clean up dma_addr_t use
On Wednesday 25 February 2015 16:36:46 Arnd Bergmann wrote:
> @@ -671,6 +671,7 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc,
> int zpos)
> struct fimd_win_data *win_data;
> int win = zpos;
> unsigned long val, alpha, size;
> + dma_addr_t end;
> unsigned int last_x;
> unsigned int last_y;
>
> @@ -705,16 +706,16 @@ static void fimd_win_commit(struct exynos_drm_crtc
> *crtc, int zpos)
> /* buffer end address */
> size = win_data->fb_width * win_data->ovl_height * (win_data->bpp >> 3);
> - val = (unsigned long)(win_data->dma_addr + size);
> + end = win_data->dma_addr + size;
> writel(val, ctx->regs + VIDWx_BUF_END(win, 0));
>
> - DRM_DEBUG_KMS("start addr = 0x%lx, end addr = 0x%lx, size = 0x%lx\n",
> - (unsigned long)win_data->dma_addr, val, size);
> + DRM_DEBUG_KMS("start addr = %pad, end addr = %pad, size = 0x%lx\n",
> + &win_data->dma_addr, end, size);
> DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
> win_data->ovl_width, win_data->ovl_height);
>
Unfortunately, I introduced a new bug here, please disregard this version
and use v2 of this patch instead.
Arnd
[PATCH 00/11] drm/rockchip: add support for lvds controller and external encoders
Hi, Am Samstag, 31. Januar 2015, 17:32:53 schrieb Heiko Stuebner: > This series adds support for the lvds encoder present on rk3288 soc and > allows external connectors to use the generic rgb pins. > > On the older socs (rk3188, rk3066, etc) these pins where accessible by > anyone, while on the rk3288 the lvds controller controls access to them. > > So while on the old socs an external encoder was explicitly connected > to one of the two lcd-controllers, on the rk3288 the lvds in between > can toggle which controller should be the source. > > To facilitate this the lvds encoder can use two modes. When a panel is > attached it acts as encoder and without panel it just registers a bridge > that can be used later. > > The bridge association to an encoder is done via a rockchip,rgb-bridge > property in the encoder node itself and handled in rockchip_drm_load > to not leak rockchip-specific handling into generic encoder drivers. > > > As example on how this can work, I've included a driver for simple > (dumb) vga encoders, like the adv7123 (and clones) as used on the > rk3288-firefly board. This same encoder is used on the Rayeager-px2 > board but there connected directly to the rgb pins of the rk3066 > which will hopefully also be supported in the future. > > I've named this currently vga-simply (inspired by panel-simple), because > so far I have found the adv7123 (and two clones) but I guess there will > be more dumb vga encoders around that only differ in minimal things. > > > Similarly, most of the rk3288-based TV-boxes use a rk1000 i2c tv encoder > connected in a similar way - and again directly connected on the > rk3188-radxarock. > > > Caveats: > - the i2c subdirectory is probably not the right one for my vga encoder > so if somebody could suggest where this should live, I'd be very happy > - I'm not sure if I'm abusing some drm-APIs in a wrong way :-) any comments or suggestions? Especially on the core drm integration? Am I abusing stuff or does this look somewhat sane? Thanks Heiko
eDP display control registers in Linux kernel
On Thu, 26 Feb 2015, Michael Leuchtenburg wrote: > Okay, here's the results: > : 12 0a 02 41 00 00 00 00 00 00 00 00 00 0b 00 > 0070: 01 00 > 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0100: 0a 02 00 09 09 00 00 00 01 00 00 > 0200: 01 00 77 00 01 01 55 00 > 0600: 01 > 0700: 02 > 0701: 88 40 00 00 > 0720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0732: 00 00 > > If I read that right, it looks like it is dynamic backlight capable - 0x702 > | (1 << 6). That's correct, your panel is dynamic backlight *capable*, but the dynamic backlight *enable* (bit 4 in 0x721) is not set. The power-on default value is also disabled, and the i915 driver does not touch it for sure. It is of course (I wish it wasn't "of course") possible the BIOS enables that in some circumstances; please try the dump again when you've observed the brightness swings for sure, and check for the DBC enable bit. Also, are you sure the swings are content adaptive, and not ambient light adaptive? Have you tried locating the ambient light sensor on the laptop (possibly somewhere in the bezel around the display or keyboard) and covering or ensuring constant lighting of it? BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[PATCH v2] drm: exynos: clean up dma_addr_t use
dma_addr_t may be 32 or 64 bits long on 32-bit CPUs, so we cannot
cast it to a pointer without getting a compiler warning:
drivers/gpu/drm/exynos/exynos_drm_buf.c: In function 'lowlevel_buffer_allocate':
drivers/gpu/drm/exynos/exynos_drm_buf.c:109:18: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
buf->dma_addr = (dma_addr_t)NULL;
^
The use of pointers is wrong here anyway, and so is the cast
to the same type, and printing the value as a 32-bit instance.
This patch tries for address all these issues in the exynos
drm driver, by printing the values as %pad and removing the
bogus type casts.
I've added '& 0x' masks in a few places I found where
a dma_addr_t is assigned to a 32-bit value, as a reminder that
this code will not work with 64-bit dma addresses. There should
not be any change in the generated code here.
Signed-off-by: Arnd Bergmann
---
v2: fix incorrect conversion in fimd_win_commit()
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 63f02e2380ae..0512157b065f 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -335,7 +335,7 @@ static void decon_win_mode_set(struct exynos_drm_crtc *crtc,
win_data->offset_x, win_data->offset_y);
DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
win_data->ovl_width, win_data->ovl_height);
- DRM_DEBUG_KMS("paddr = 0x%lx\n", (unsigned long)win_data->dma_addr);
+ DRM_DEBUG_KMS("paddr = %pad\n", &win_data->dma_addr);
DRM_DEBUG_KMS("fb_width = %d, crtc_width = %d\n",
plane->fb_width, plane->crtc_width);
}
@@ -490,7 +490,7 @@ static void decon_win_commit(struct exynos_drm_crtc *crtc,
int zpos)
decon_shadow_protect_win(ctx, win, true);
/* buffer start address */
- val = (unsigned long)win_data->dma_addr;
+ val = win_data->dma_addr & 0x;
writel(val, ctx->regs + VIDW_BUF_START(win));
/* buffer size */
@@ -501,8 +501,7 @@ static void decon_win_commit(struct exynos_drm_crtc *crtc,
int zpos)
writel(win_data->offset_x, ctx->regs + VIDW_OFFSET_X(win));
writel(win_data->offset_y, ctx->regs + VIDW_OFFSET_Y(win));
- DRM_DEBUG_KMS("start addr = 0x%lx\n",
- (unsigned long)win_data->dma_addr);
+ DRM_DEBUG_KMS("start addr = %pad\n", &win_data->dma_addr);
DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
win_data->ovl_width, win_data->ovl_height);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 24994ba10e28..935157e65236 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -97,16 +97,15 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
goto err_free_attrs;
}
- DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
- (unsigned long)buf->dma_addr,
- buf->size);
+ DRM_DEBUG_KMS("dma_addr(%pad), size(0x%lx)\n",
+ &buf->dma_addr, buf->size);
return ret;
err_free_attrs:
dma_free_attrs(dev->dev, buf->size, buf->pages,
- (dma_addr_t)buf->dma_addr, &buf->dma_attrs);
- buf->dma_addr = (dma_addr_t)NULL;
+ buf->dma_addr, &buf->dma_attrs);
+ buf->dma_addr = 0;
err_free:
if (!is_drm_iommu_supported(dev))
drm_free_large(buf->pages);
@@ -122,9 +121,8 @@ static void lowlevel_buffer_deallocate(struct drm_device
*dev,
return;
}
- DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
- (unsigned long)buf->dma_addr,
- buf->size);
+ DRM_DEBUG_KMS("dma_addr(%pad), size(0x%lx)\n",
+ &buf->dma_addr, buf->size);
sg_free_table(buf->sgt);
@@ -133,13 +131,13 @@ static void lowlevel_buffer_deallocate(struct drm_device
*dev,
if (!is_drm_iommu_supported(dev)) {
dma_free_attrs(dev->dev, buf->size, buf->cookie,
- (dma_addr_t)buf->dma_addr, &buf->dma_attrs);
+ buf->dma_addr, &buf->dma_attrs);
drm_free_large(buf->pages);
} else
dma_free_attrs(dev->dev, buf->size, buf->pages,
- (dma_addr_t)buf->dma_addr, &buf->dma_attrs);
+ buf->dma_addr, &buf->dma_attrs);
- buf->dma_addr = (dma_addr_t)NULL;
+ buf->dma_addr = 0;
}
struct exynos_drm_gem_buf *exynos_drm_init_buf(struct drm_device *dev,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index d346d1e6eda0..b259c1bf8752 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb
[PULL] drm-intel-fixes
Hi Dave - First batch of fixes for v4.0-rc, plenty of cc: stable material. BR, Jani. The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-02-26 for you to fetch changes up to 62e537f8d568347bbe4e00d7803a838750cdc618: drm/i915: Fix frontbuffer false positve. (2015-02-25 10:08:15 +0200) Chris Wilson (1): drm/i915: Check obj->vma_list under the struct_mutex Daniel Vetter (1): drm/i915: Align initial plane backing objects correctly Imre Deak (1): drm/i915: avoid processing spurious/shared interrupts in low-power states Jani Nikula (2): drm/i915/skl: handle all pixel formats in skylake_update_primary_plane() drm/i915: Dell Chromebook 11 has PWM backlight Nick Hoath (1): drm/i915: Fix a use after free, and unbalanced refcounting Rodrigo Vivi (2): drm/i915/bdw: PCI IDs ending in 0xb are ULT. drm/i915: Fix frontbuffer false positve. drivers/gpu/drm/i915/i915_drv.h| 15 ++- drivers/gpu/drm/i915/i915_gem.c| 3 +-- drivers/gpu/drm/i915/i915_gem_stolen.c | 6 ++ drivers/gpu/drm/i915/i915_gem_tiling.c | 7 --- drivers/gpu/drm/i915/i915_irq.c| 22 ++ drivers/gpu/drm/i915/intel_display.c | 33 - drivers/gpu/drm/i915/intel_lrc.c | 8 include/drm/i915_pciids.h | 4 ++-- 8 files changed, 73 insertions(+), 25 deletions(-) -- Jani Nikula, Intel Open Source Technology Center
[PATCH RESEND] drm: tda998x: Use drm_do_get_edid()
On Thu, Feb 26, 2015 at 09:52:02AM +0200, Laurent Pinchart wrote: > Hi Russell, > > On Friday 16 January 2015 17:47:34 Russell King - ARM Linux wrote: > > On Fri, Jan 16, 2015 at 06:37:43PM +0200, Laurent Pinchart wrote: > > > Replace the internal EDID read implementation by a call to the new EDID > > > read core function. > > > > > > Signed-off-by: Laurent Pinchart > > > > > > Reviewed-by: Rob Clark > > > Tested-by: Jean-Francois Moine > > > > Thanks, committed, and updated the summary line to: > > > > "drm/i2c: tda998x: use drm_do_get_edid()" > > > > to match the style used in the past. > > I can't see the patch in Dave's -next branch, has it been lost somewhere ? I thought I had sent a pull request before the last merge window, but it seems I didn't. That's the problem when you end up carrying too many patches... tracking what's been sent and to whom is a real pain. The only time I get to verify what's been sent is after it's appeared in mainline (so after a merge window). -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
[PATCH 00/38] Renesas R-Car DU atomic updates support
Hi Magnus, On Wednesday 25 February 2015 16:43:53 Magnus Damm wrote: > On Wed, Feb 25, 2015 at 1:54 PM, Laurent Pinchart wrote: > > Hello, > > > > This patch series implements atomic updates support for the rcar-du > > driver. > > > > The series starts with four core atomic helpers fixes/cleanups (two from > > Daniel that I have included here for completeness). It then follows with > > two fixes for the adv7511 driver and height fixes for the rcar-du driver. > > It finally gets to work by slowly reworking rcar-du until atomic updates > > are fully implemented and the transitional helpers gone. > > > > The patches are based on Dave's 'next' branch and available at > > > > git://linuxtv.org/pinchartl/fbdev.git drm/next/atomic > > > > The last patch contains a hardware plane allocator based solely on state > > objects, which could be useful as a base implementation should other > > drivers experience similar needs. > > Many thanks for your efforts on this! > > It looks to me like the adv7511 fixes would be useful as-is > independently of the atomic update changes. > > [PATCH 05/38] drm: adv7511: Fix DDC error interrupt handling > [PATCH 06/38] drm: adv7511: Fix nested sleep when reading EDID > > Is it possible to fast track just the fixes somehow? I believe that > several hardware platforms with adv7511 chips would benefit from these > fixes. Do you mean fast track them to v4.0 or v4.1 ? I certainly want to see them in v4.1 (hopefully with the rest of the series as well) and I can mark them as stable candidates. -- Regards, Laurent Pinchart
[PATCH 4/8] pwm: atmel-hlcdc: fix struct clk pointer comparing
Nicolas, Shawn,
On Thu, 26 Feb 2015 10:22:50 +0100
Nicolas Ferre wrote:
> Le 25/02/2015 15:53, Shawn Guo a écrit :
> > Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> > instances"), clk API users can no longer check if two struct clk
> > pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
> > simply comparing two pointers. That's because with the per-user clk
> > change, a brand new struct clk is created whenever clients try to look
> > up the clock by calling clk_get() or sister functions like clk_get_sys()
> > and of_clk_get(). This changes the original behavior where the struct
> > clk is only created for once when clock driver registers the clock to
> > CCF in the first place. The net change here is before commit
> > 035a61c314eb the struct clk pointer is unique for given hardware
> > clock, while after the commit the pointers returned by clk lookup calls
> > become different for the same hardware clock.
> >
> > That said, the struct clk pointer comparing in the code doesn't work any
> > more. Call helper function clk_is_match() instead to fix the problem.
> >
> > Signed-off-by: Shawn Guo
>
> I agree with the fix whichever name is chosen for the function in an
> future version of this series. So you can add my:
> Acked-by: Nicolas Ferre
>
> Maybe Boris can double check...
Looks good to me.
Thanks for fixing that.
Acked-by: Boris Brezillon
>
> > ---
> > drivers/pwm/pwm-atmel-hlcdc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
> > index 522f7075bb1a..36475949b829 100644
> > --- a/drivers/pwm/pwm-atmel-hlcdc.c
> > +++ b/drivers/pwm/pwm-atmel-hlcdc.c
> > @@ -97,7 +97,7 @@ static int atmel_hlcdc_pwm_config(struct pwm_chip *c,
> >
> > pwmcfg = ATMEL_HLCDC_PWMPS(pres);
> >
> > - if (new_clk != chip->cur_clk) {
> > + if (!clk_is_match(new_clk, chip->cur_clk)) {
> > u32 gencfg = 0;
> > int ret;
> >
> >
>
>
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[Bug 89156] r300g: GL_COMPRESSED_RED_RGTC1 / ATI1N support broken
https://bugs.freedesktop.org/show_bug.cgi?id=89156
--- Comment #4 from Stefan Dösinger ---
Created attachment 113841
--> https://bugs.freedesktop.org/attachment.cgi?id=113841&action=edit
Shader used to read the texture
Indeed changing the swizzle fixes the random output. I have attached the shader
we use to sample the texture. We don't have a swizzle on the texture2D
statement, but we do swizzle the output variable, and apparently the optimizer
merges that.
If I use the RGBA values returned by the texture sampling directly I get a
solid color as expected. However, the value is off quite a bit: Instead of 0x7f
I get 0x6c.
The texture data we use is this:
static const char ati1n_data[] =
{
/* A 4x4 texture with the color component at 50%. */
0x7f, 0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};
--
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/20150226/d75bfe7a/attachment-0001.html>
[Bug 89148] r300g: Kernel rejected CS in Wine d3d multisample test
https://bugs.freedesktop.org/show_bug.cgi?id=89148 --- Comment #11 from Stefan Dösinger --- Attachment 113802 fixes the invalid CS / crash and my test program now reads a color. However, sRGB color correction seems to be applied at some stage. Note that the test program is not using GL_ARB_framebuffer_sRGB (which isn't supported on r500 anyway), and that GL_TEXTURE_SRGB_DECODE_EXT is set to GL_SKIP_DECODE_EXT. It seems that the correction is applied during blitting. If I clear the 2D texture directly the expected result (0xff80) is returned. If I use the renderbuffer and blit I get 0xff37. (Wine expects that glBlitFramebuffer never applies sRGB correction when blitting from an sRGB texture, but this codepath is only used if GL_EXT_sRGB_decode is not supported. In this case we load two copies of the texture, one sRGB and one RGB, and use glBlitFramebuffer to blit between them if the application toggles sRGB on and off.) -- 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/20150226/b5457517/attachment.html>
[alsa-devel] [PATCH 1/8] clk: add helper function clk_is_match()
Am Donnerstag, den 26.02.2015, 09:02 + schrieb Ben Dooks: > On Wed, Feb 25, 2015 at 09:27:57AM -0800, Mike Turquette wrote: [...] > > From: Michael Turquette > > Date: Wed, 25 Feb 2015 09:11:01 -0800 > > Subject: [PATCH] clk: introduce clk_is_match > > > > Some drivers compare struct clk pointers as a means of knowing > > if the two pointers reference the same clock hardware. This behavior is > > dubious (drivers must not dereference struct clk), but did not cause any > > regressions until the per-user struct clk patch was merged. Now the test > > for matching clk's will always fail with per-user struct clk's. > > > > clk_is_match is introduced to fix the regression and prevent drivers > > from comparing the pointers manually. > > small observaton, clk_is_same() is linguistically nicer. How about clk_equal() ? regards Philipp
[PATCH 3/4] drm/dp: add DPCD definitions from eDP 1.2
On Wednesday 25 February 2015 06:16 PM, Jani Nikula wrote: > Mostly display control related DPCD addresses. > > Signed-off-by: Jani Nikula > --- > include/drm/drm_dp_helper.h | 32 > 1 file changed, 32 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 209c5b91b0e8..cc96024e8776 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -426,6 +426,38 @@ > > #define DP_EDP_DPCD_REV 0x700/* eDP 1.2 */ > > +#define DP_EDP_GENERAL_CAP_1 0x701 > + > +#define DP_EDP_BACKLIGHT_ADJUSTMENT_CAP 0x702 > + > +#define DP_EDP_GENERAL_CAP_2 0x703 > + > +#define DP_EDP_DISPLAY_CONTROL_REGISTER 0x720 > + > +#define DP_EDP_BACKLIGHT_MODE_SET_REGISTER 0x721 > + > +#define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722 > +#define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723 > + > +#define DP_EDP_PWMGEN_BIT_COUNT 0x724 > +#define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725 > +#define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726 > + > +#define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727 > + > +#define DP_EDP_BACKLIGHT_FREQ_SET 0x728 > + > +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB 0x72a > +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID 0x72b > +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_LSB 0x72c > + > +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_MSB 0x72d > +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_MID 0x72e > +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_LSB 0x72f > + > +#define DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET 0x732 > +#define DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET 0x733 > + > #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ > #define DP_SIDEBAND_MSG_UP_REP_BASE 0x1200 /* 1.2 MST */ > #define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ Checked against edp1.3 spec. Reviewed-by: Sonika Jindal
[PATCH 1/4] drm/dp: indentation and ordering cleanups
On Wednesday 25 February 2015 06:16 PM, Jani Nikula wrote: > Keep the DPCD macros ordered by address, and make indentation conform to > the rest of the file. > > commit e045d20bef41707dbba676e58624b54f9f39e172 > Author: Sonika Jindal > Date: Thu Feb 19 13:16:44 2015 +0530 > > drm: Adding edp1.4 specific dpcd macros > > Signed-off-by: Jani Nikula > > --- > > Daniel, this might be squashed into the above commit in the drm-misc > tree. > --- > include/drm/drm_dp_helper.h | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index d4803224028f..98fefe45d158 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -92,9 +92,6 @@ > # define DP_MSA_TIMING_PAR_IGNORED (1 << 6) /* eDP */ > # define DP_OUI_SUPPORT (1 << 7) > > -#define DP_SUPPORTED_LINK_RATES 0x010 /*eDP 1.4*/ > -#define DP_MAX_SUPPORTED_RATES 0x8 > - > #define DP_I2C_SPEED_CAP0x00c/* DPI */ > # define DP_I2C_SPEED_1K0x01 > # define DP_I2C_SPEED_5K0x02 > @@ -105,8 +102,12 @@ > > #define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */ > # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher > */ > + > #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > > +#define DP_SUPPORTED_LINK_RATES 0x010 /* eDP 1.4 */ > +# define DP_MAX_SUPPORTED_RATES 8 /* 16-bit > little-endian */ > + > /* Multiple stream transport */ > #define DP_FAUX_CAP 0x020 /* 1.2 */ > # define DP_FAUX_CAP_1 (1 << 0) > @@ -225,7 +226,7 @@ > # define DP_UP_REQ_EN (1 << 1) > # define DP_UPSTREAM_IS_SRC (1 << 2) > > -#define DP_LINK_RATE_SET 0x115 > +#define DP_LINK_RATE_SET 0x115 /* eDP 1.4 */ > > #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ > # define DP_PSR_ENABLE (1 << 0) > @@ -338,7 +339,7 @@ > # define DP_SET_POWER_D30x2 > # define DP_SET_POWER_MASK 0x3 > > -#define DP_EDP_DPCD_REV 0x700 > +#define DP_EDP_DPCD_REV 0x700/* eDP 1.2 */ > > #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ > #define DP_SIDEBAND_MSG_UP_REP_BASE 0x1200 /* 1.2 MST */ Reviewed-by: Sonika Jindal
[PATCH 2/4] drm/dp: add DPCD definitions from DP 1.2a
On Wednesday 25 February 2015 06:16 PM, Jani Nikula wrote: > Signed-off-by: Jani Nikula > --- > include/drm/drm_dp_helper.h | 95 > ++--- > 1 file changed, 90 insertions(+), 5 deletions(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 98fefe45d158..209c5b91b0e8 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -92,6 +92,15 @@ > # define DP_MSA_TIMING_PAR_IGNORED (1 << 6) /* eDP */ > # define DP_OUI_SUPPORT (1 << 7) > > +#define DP_RECEIVE_PORT_0_CAP_0 0x008 /* XXX 1.2? */ This is part of DPv1.1 as well, the 1.2 in comment stands for DP version? > +# define DP_LOCAL_EDID_PRESENT (1 << 1) > +# define DP_ASSOCIATED_TO_PRECEDING_PORT(1 << 2) > + > +#define DP_RECEIVE_PORT_0_BUFFER_SIZE0x009 > + > +#define DP_RECEIVE_PORT_1_CAP_0 0x00a > +#define DP_RECEIVE_PORT_1_BUFFER_SIZE 0x00b > + > #define DP_I2C_SPEED_CAP0x00c/* DPI */ > # define DP_I2C_SPEED_1K0x01 > # define DP_I2C_SPEED_5K0x02 > @@ -101,10 +110,16 @@ > # define DP_I2C_SPEED_1M0x20 > > #define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */ > +# define DP_ALTERNATE_SCRAMBLER_RESET_CAP (1 << 0) > +# define DP_FRAMING_CHANGE_CAP (1 << 1) > # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher > */ > > #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > > +#define DP_ADAPTER_CAP 0x00f /* 1.2 */ > +# define DP_FORCE_LOAD_SENSE_CAP (1 << 0) > +# define DP_ALTERNATE_I2C_PATTERN_CAP(1 << 1) > + > #define DP_SUPPORTED_LINK_RATES 0x010 /* eDP 1.4 */ > # define DP_MAX_SUPPORTED_RATES 8 /* 16-bit > little-endian */ > > @@ -115,6 +130,44 @@ > #define DP_MSTM_CAP 0x021 /* 1.2 */ > # define DP_MST_CAP (1 << 0) > > +#define DP_NUMBER_OF_AUDIO_ENDPOINTS 0x022 /* 1.2 */ > + > +/* AV_SYNC_DATA_BLOCK 1.2 */ > +#define DP_AV_GRANULARITY0x023 > +# define DP_AG_FACTOR_MASK (0xf << 0) > +# define DP_AG_FACTOR_3MS(0 << 0) > +# define DP_AG_FACTOR_2MS(1 << 0) > +# define DP_AG_FACTOR_1MS(2 << 0) > +# define DP_AG_FACTOR_500US (3 << 0) > +# define DP_AG_FACTOR_200US (4 << 0) > +# define DP_AG_FACTOR_100US (5 << 0) > +# define DP_AG_FACTOR_10US (6 << 0) > +# define DP_AG_FACTOR_1US(7 << 0) > +# define DP_VG_FACTOR_MASK (0xf << 4) > +# define DP_VG_FACTOR_3MS(0 << 4) > +# define DP_VG_FACTOR_2MS(1 << 4) > +# define DP_VG_FACTOR_1MS(2 << 4) > +# define DP_VG_FACTOR_500US (3 << 4) > +# define DP_VG_FACTOR_200US (4 << 4) > +# define DP_VG_FACTOR_100US (5 << 4) > + > +#define DP_AUD_DEC_LAT0 0x024 > +#define DP_AUD_DEC_LAT1 0x025 > + > +#define DP_AUD_PP_LAT0 0x026 > +#define DP_AUD_PP_LAT1 0x027 > + > +#define DP_VID_INTER_LAT 0x028 > + > +#define DP_VID_PROG_LAT 0x029 > + > +#define DP_REP_LAT 0x02a > + > +#define DP_AUD_DEL_INS0 0x02b > +#define DP_AUD_DEL_INS1 0x02c > +#define DP_AUD_DEL_INS2 0x02d > +/* End of AV_SYNC_DATA_BLOCK */ > + > #define DP_GUID 0x030 /* 1.2 */ > > #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ > @@ -173,11 +226,12 @@ > # define DP_TRAINING_PATTERN_3 3 /* 1.2 */ > # define DP_TRAINING_PATTERN_MASK 0x3 > > -# define DP_LINK_QUAL_PATTERN_DISABLE(0 << 2) > -# define DP_LINK_QUAL_PATTERN_D10_2 (1 << 2) > -# define DP_LINK_QUAL_PATTERN_ERROR_RATE(2 << 2) > -# define DP_LINK_QUAL_PATTERN_PRBS7 (3 << 2) > -# define DP_LINK_QUAL_PATTERN_MASK (3 << 2) > +/* DPCD 1.1 only. For DPCD >= 1.2 see per-lane DP_LINK_QUAL_LANEn_SET */ > +# define DP_LINK_QUAL_PATTERN_11_DISABLE(0 << 2) > +# define DP_LINK_QUAL_PATTERN_11_D10_2 (1 << 2) > +# define DP_LINK_QUAL_PATTERN_11_ERROR_RATE (2 << 2) > +# define DP_LINK_QUAL_PATTERN_11_PRBS7 (3 << 2) > +# define DP_LINK_QUAL_PATTERN_11_MASK(3 << 2) > > # define DP_RECOVERED_CLOCK_OUT_EN (1 << 4) > # define DP_LINK_SCRAMBLING_DISABLE (1 << 5) > @@ -220,14 +274,45 @@ > /* bitmask as for DP_I2C_SPEED_CAP */ > > #define DP_EDP_CONFIGURATION_SET0x10a /* XXX 1.2? */ > +# define DP_ALTERNATE_SCRAMBLE
[Bug 89148] r300g: Kernel rejected CS in Wine d3d multisample test
https://bugs.freedesktop.org/show_bug.cgi?id=89148 --- Comment #12 from Marek Olšák --- r300g doesn't do sRGB conversion for MSAA resolves. It always interprets the textures as linear and only averages the samples. -- 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/20150226/89743641/attachment.html>
[Bug 89156] r300g: GL_COMPRESSED_RED_RGTC1 / ATI1N support broken
https://bugs.freedesktop.org/show_bug.cgi?id=89156
--- Comment #5 from Marek Olšák ---
(In reply to Stefan Dösinger from comment #4)
> Created attachment 113841 [details]
> Shader used to read the texture
>
> Indeed changing the swizzle fixes the random output. I have attached the
> shader we use to sample the texture. We don't have a swizzle on the
> texture2D statement, but we do swizzle the output variable, and apparently
> the optimizer merges that.
So it's a compiler bug.
>
> If I use the RGBA values returned by the texture sampling directly I get a
> solid color as expected. However, the value is off quite a bit: Instead of
> 0x7f I get 0x6c.
>
> The texture data we use is this:
>
> static const char ati1n_data[] =
> {
> /* A 4x4 texture with the color component at 50%. */
> 0x7f, 0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> };
That's expected. ATI1N operates at lower precision. I'm afraid I can't change
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/20150226/398c8812/attachment-0001.html>
[Bug 89156] r300g: GL_COMPRESSED_RED_RGTC1 / ATI1N support broken
https://bugs.freedesktop.org/show_bug.cgi?id=89156
--- Comment #6 from Stefan Dösinger ---
(In reply to Marek Olšák from comment #5)
> So it's a compiler bug.
In which sense? Is there something in the spec that tells me I should expect
garbage when I use texture2D().? Or is this something the driver tells the
compiler and the compiler is supposed to generate a swizzle-free texture2D
statement?
> > static const char ati1n_data[] =
> > {
> > /* A 4x4 texture with the color component at 50%. */
> > 0x7f, 0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > };
>
> That's expected. ATI1N operates at lower precision. I'm afraid I can't
> change that.
Windows gives me a proper value (0x7f, which is pretty close to 0x80). Do you
have any idea how it does that?
I can try to find a scheme behind the imprecision if it helps you. There may be
something like an off by one error that the driver can account for.
--
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/20150226/04f6519d/attachment.html>
[Bug 89148] r300g: Kernel rejected CS in Wine d3d multisample test
https://bugs.freedesktop.org/show_bug.cgi?id=89148 --- Comment #13 from Stefan Dösinger --- The thing that seems to trigger the sRGB correction is the fact that the destination texture has an sRGB internal. If I change it to GL_RGBA8 I get the expected result. The format of the source RB doesn't seem to matter here. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/57954498/attachment.html>
[Intel-gfx] [PATCH 4/4] drm/dp: add DPCD definitions from eDP 1.4
On Wednesday 25 February 2015 06:16 PM, Jani Nikula wrote: > Signed-off-by: Jani Nikula > --- > include/drm/drm_dp_helper.h | 37 + > 1 file changed, 37 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index cc96024e8776..07d94faa9255 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -168,10 +168,18 @@ > #define DP_AUD_DEL_INS2 0x02d > /* End of AV_SYNC_DATA_BLOCK */ > > +#define DP_RECEIVER_ALPM_CAP 0x02e /* eDP 1.4 */ > +# define DP_ALPM_CAP (1 << 0) Yes, it is named ALPM_CAP in spec, but to me something like DP_ALPM_SUPPORTED makes more sense to me here. > + > +#define DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP 0x02f /* eDP 1.4 */ > +# define DP_AUX_FRAME_SYNC_CAP (1 << 0) Same comment as above. > + > #define DP_GUID 0x030 /* 1.2 */ > > #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ > # define DP_PSR_IS_SUPPORTED1 > +# define DP_PSR2_IS_SUPPORTED2 /* eDP 1.4 */ > + > #define DP_PSR_CAPS 0x071 /* XXX 1.2? */ > # define DP_PSR_NO_TRAIN_ON_EXIT1 > # define DP_PSR_SETUP_TIME_330 (0 << 1) > @@ -211,6 +219,7 @@ > > /* link configuration */ > #define DP_LINK_BW_SET 0x100 > +# define DP_LINK_RATE_TABLE 0x00/* eDP 1.4 */ > # define DP_LINK_BW_1_620x06 > # define DP_LINK_BW_2_7 0x0a > # define DP_LINK_BW_5_4 0x14/* 1.2 */ > @@ -309,15 +318,30 @@ > #define DP_AUDIO_DELAY2 0x114 > > #define DP_LINK_RATE_SET0x115 /* eDP 1.4 */ > +# define DP_LINK_RATE_SET_SHIFT 0 > +# define DP_LINK_RATE_SET_MASK (7 << 0) > + > +#define DP_RECEIVER_ALPM_CONFIG 0x116 /* eDP 1.4 */ > +# define DP_ALPM_ENABLE (1 << 0) > +# define DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE (1 << 1) > + > +#define DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF 0x117 /* eDP 1.4 */ > +# define DP_AUX_FRAME_SYNC_ENABLE(1 << 0) > +# define DP_IRQ_HPD_ENABLE (1 << 1) > > #define DP_UPSTREAM_DEVICE_DP_PWR_NEED 0x118 /* 1.2 */ > # define DP_PWR_NOT_NEEDED (1 << 0) > > +#define DP_AUX_FRAME_SYNC_VALUE 0x15c /* eDP 1.4 */ > +# define DP_AUX_FRAME_SYNC_VALID (1 << 0) > + > #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ > # define DP_PSR_ENABLE (1 << 0) > # define DP_PSR_MAIN_LINK_ACTIVE(1 << 1) > # define DP_PSR_CRC_VERIFICATION(1 << 2) > # define DP_PSR_FRAME_CAPTURE (1 << 3) > +# define DP_PSR_SELECTIVE_UPDATE (1 << 4) > +# define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS (1 << 5) > > #define DP_ADAPTER_CTRL 0x1a0 > # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) > @@ -425,6 +449,10 @@ > # define DP_SET_POWER_MASK 0x3 > > #define DP_EDP_DPCD_REV 0x700/* eDP 1.2 */ > +# define DP_EDP_11 0x00 > +# define DP_EDP_12 0x01 > +# define DP_EDP_13 0x02 > +# define DP_EDP_14 0x03 > > #define DP_EDP_GENERAL_CAP_10x701 > > @@ -432,6 +460,8 @@ > > #define DP_EDP_GENERAL_CAP_20x703 > > +#define DP_EDP_GENERAL_CAP_3 0x704/* eDP 1.4 */ > + > #define DP_EDP_DISPLAY_CONTROL_REGISTER 0x720 > > #define DP_EDP_BACKLIGHT_MODE_SET_REGISTER 0x721 > @@ -458,6 +488,9 @@ > #define DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET 0x732 > #define DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET 0x733 > > +#define DP_EDP_REGIONAL_BACKLIGHT_BASE 0x740/* eDP 1.4 */ > +#define DP_EDP_REGIONAL_BACKLIGHT_0 0x741/* eDP 1.4 */ > + > #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ > #define DP_SIDEBAND_MSG_UP_REP_BASE 0x1200 /* 1.2 MST */ > #define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ > @@ -476,6 +509,7 @@ > #define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */ > # define DP_PSR_LINK_CRC_ERROR (1 << 0) > # define DP_PSR_RFB_STORAGE_ERROR (1 << 1) > +# define DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR (1 << 2) /* eDP 1.4 */ > > #define DP_PSR_ESI 0x2007 /* XXX 1.2? */ > # define DP_PSR_CAPS_CHANGE (1 << 0) > @@ -489,6 +523,9 @@ > # define DP_PSR_SINK_INTERNAL_ERROR 7 > # define DP_PSR_SINK_STATE_MASK 0x07 > > +#define DP_RECEIVER_ALPM_STATUS 0x200b /* eDP 1.4 */ > +# define DP_ALPM_LOCK_TIMEOUT_ERROR_STATUS
[Intel-gfx] [PATCH 4/4] drm/dp: add DPCD definitions from eDP 1.4
On Thu, 26 Feb 2015, sonika wrote: > On Wednesday 25 February 2015 06:16 PM, Jani Nikula wrote: >> Signed-off-by: Jani Nikula >> --- >> include/drm/drm_dp_helper.h | 37 + >> 1 file changed, 37 insertions(+) >> >> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h >> index cc96024e8776..07d94faa9255 100644 >> --- a/include/drm/drm_dp_helper.h >> +++ b/include/drm/drm_dp_helper.h >> @@ -168,10 +168,18 @@ >> #define DP_AUD_DEL_INS20x02d >> /* End of AV_SYNC_DATA_BLOCK */ >> >> +#define DP_RECEIVER_ALPM_CAP0x02e /* eDP 1.4 */ >> +# define DP_ALPM_CAP(1 << 0) > Yes, it is named ALPM_CAP in spec, but to me something like > DP_ALPM_SUPPORTED makes more sense to me here. I would prefer to keep the same name as in the spec. In many places in the DPCD, _CAP refers to a capability, so I don't find it confusing. >> + >> +#define DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP 0x02f /* eDP 1.4 */ >> +# define DP_AUX_FRAME_SYNC_CAP (1 << 0) > Same comment as above. Likewise. :) >> + >> #define DP_GUID0x030 /* 1.2 */ >> >> #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ >> # define DP_PSR_IS_SUPPORTED1 >> +# define DP_PSR2_IS_SUPPORTED 2 /* eDP 1.4 */ >> + >> #define DP_PSR_CAPS 0x071 /* XXX 1.2? */ >> # define DP_PSR_NO_TRAIN_ON_EXIT1 >> # define DP_PSR_SETUP_TIME_330 (0 << 1) >> @@ -211,6 +219,7 @@ >> >> /* link configuration */ >> #defineDP_LINK_BW_SET 0x100 >> +# define DP_LINK_RATE_TABLE 0x00/* eDP 1.4 */ >> # define DP_LINK_BW_1_62 0x06 >> # define DP_LINK_BW_2_70x0a >> # define DP_LINK_BW_5_40x14/* 1.2 */ >> @@ -309,15 +318,30 @@ >> #define DP_AUDIO_DELAY20x114 >> >> #define DP_LINK_RATE_SET 0x115 /* eDP 1.4 */ >> +# define DP_LINK_RATE_SET_SHIFT 0 >> +# define DP_LINK_RATE_SET_MASK (7 << 0) >> + >> +#define DP_RECEIVER_ALPM_CONFIG 0x116 /* eDP 1.4 */ >> +# define DP_ALPM_ENABLE (1 << 0) >> +# define DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE (1 << 1) >> + >> +#define DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF 0x117 /* eDP 1.4 */ >> +# define DP_AUX_FRAME_SYNC_ENABLE (1 << 0) >> +# define DP_IRQ_HPD_ENABLE (1 << 1) >> >> #define DP_UPSTREAM_DEVICE_DP_PWR_NEED 0x118 /* 1.2 */ >> # define DP_PWR_NOT_NEEDED (1 << 0) >> >> +#define DP_AUX_FRAME_SYNC_VALUE 0x15c /* eDP 1.4 */ >> +# define DP_AUX_FRAME_SYNC_VALID(1 << 0) >> + >> #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ >> # define DP_PSR_ENABLE (1 << 0) >> # define DP_PSR_MAIN_LINK_ACTIVE (1 << 1) >> # define DP_PSR_CRC_VERIFICATION (1 << 2) >> # define DP_PSR_FRAME_CAPTURE (1 << 3) >> +# define DP_PSR_SELECTIVE_UPDATE(1 << 4) >> +# define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS (1 << 5) >> >> #define DP_ADAPTER_CTRL0x1a0 >> # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) >> @@ -425,6 +449,10 @@ >> # define DP_SET_POWER_MASK 0x3 >> >> #define DP_EDP_DPCD_REV0x700/* eDP 1.2 */ >> +# define DP_EDP_11 0x00 >> +# define DP_EDP_12 0x01 >> +# define DP_EDP_13 0x02 >> +# define DP_EDP_14 0x03 >> >> #define DP_EDP_GENERAL_CAP_1 0x701 >> >> @@ -432,6 +460,8 @@ >> >> #define DP_EDP_GENERAL_CAP_2 0x703 >> >> +#define DP_EDP_GENERAL_CAP_30x704/* eDP 1.4 */ >> + >> #define DP_EDP_DISPLAY_CONTROL_REGISTER 0x720 >> >> #define DP_EDP_BACKLIGHT_MODE_SET_REGISTER 0x721 >> @@ -458,6 +488,9 @@ >> #define DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET 0x732 >> #define DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET 0x733 >> >> +#define DP_EDP_REGIONAL_BACKLIGHT_BASE 0x740/* eDP 1.4 */ >> +#define DP_EDP_REGIONAL_BACKLIGHT_0 0x741/* eDP 1.4 */ >> + >> #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ >> #define DP_SIDEBAND_MSG_UP_REP_BASE0x1200 /* 1.2 MST */ >> #define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ >> @@ -476,6 +509,7 @@ >> #define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */ >> # define DP_PSR_LINK_CRC_ERROR (1 << 0) >> # define DP_PSR_RFB_STORAGE_ERROR (1 << 1) >> +# define DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR (1 << 2) /* eDP 1.4 */ >> >> #define DP_PSR_ESI 0x2007 /* XXX 1.2? */ >> # defin
[PATCH] drm/atomic-helper: Fix kerneldoc for prepare_planes
Copypaste-fail from cleanup_planes. Reported by Tvrtko. Cc: Tvrtko Ursulin Reviewed-by: Tvrtko Ursulin Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 28aa87510551..3ce57f46ad7f 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1096,9 +1096,9 @@ EXPORT_SYMBOL(drm_atomic_helper_commit); */ /** - * drm_atomic_helper_prepare_planes - prepare plane resources after commit + * drm_atomic_helper_prepare_planes - prepare plane resources before commit * @dev: DRM device - * @state: atomic state object with old state structures + * @state: atomic state object with new state structures * * This function prepares plane state, specifically framebuffers, for the new * configuration. If any failure is encountered this function will call -- 2.1.4
[PATCH] drm: atmel-hlcdc: remove clock polarity from crtc driver
On Wed, 25 Feb 2015 18:44:51 +0100 Nicolas Ferre wrote: > Remove this configuration bit in crtc driver as the rising edge clock is > widely > used. Applied to drm-atmel-hlcdc-fixes. Thanks, Boris > > Signed-off-by: Boris BREZILLON > Signed-off-by: Nicolas Ferre > --- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c > index 0409b907de5d..b3e3068c6ec0 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c > @@ -153,7 +153,7 @@ static int atmel_hlcdc_crtc_mode_set(struct drm_crtc *c, >(adj->crtc_hdisplay - 1) | >((adj->crtc_vdisplay - 1) << 16)); > > - cfg = ATMEL_HLCDC_CLKPOL; > + cfg = 0; > > prate = clk_get_rate(crtc->dc->hlcdc->sys_clk); > mode_rate = mode->crtc_clock * 1000; -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[Intel-gfx] [PATCH 3/4] drm/dp: add DPCD definitions from eDP 1.2
On Thu, Feb 26, 2015 at 03:21:13PM +0530, sonika wrote: > > On Wednesday 25 February 2015 06:16 PM, Jani Nikula wrote: > >Mostly display control related DPCD addresses. > > > >Signed-off-by: Jani Nikula > >--- > > include/drm/drm_dp_helper.h | 32 > > 1 file changed, 32 insertions(+) > > > >diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > >index 209c5b91b0e8..cc96024e8776 100644 > >--- a/include/drm/drm_dp_helper.h > >+++ b/include/drm/drm_dp_helper.h > >@@ -426,6 +426,38 @@ > > #define DP_EDP_DPCD_REV0x700/* eDP 1.2 */ > >+#define DP_EDP_GENERAL_CAP_10x701 > >+ > >+#define DP_EDP_BACKLIGHT_ADJUSTMENT_CAP 0x702 > >+ > >+#define DP_EDP_GENERAL_CAP_20x703 > >+ > >+#define DP_EDP_DISPLAY_CONTROL_REGISTER 0x720 > >+ > >+#define DP_EDP_BACKLIGHT_MODE_SET_REGISTER 0x721 > >+ > >+#define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722 > >+#define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723 > >+ > >+#define DP_EDP_PWMGEN_BIT_COUNT 0x724 > >+#define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725 > >+#define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726 > >+ > >+#define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727 > >+ > >+#define DP_EDP_BACKLIGHT_FREQ_SET 0x728 > >+ > >+#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB 0x72a > >+#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID 0x72b > >+#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_LSB 0x72c > >+ > >+#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_MSB 0x72d > >+#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_MID 0x72e > >+#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_LSB 0x72f > >+ > >+#define DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET 0x732 > >+#define DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET 0x733 > >+ > > #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ > > #define DP_SIDEBAND_MSG_UP_REP_BASE0x1200 /* 1.2 MST */ > > #define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ > Checked against edp1.3 spec. > > Reviewed-by: Sonika Jindal Merged this and patch 1 to drm-misc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 89156] r300g: GL_COMPRESSED_RED_RGTC1 / ATI1N support broken
https://bugs.freedesktop.org/show_bug.cgi?id=89156 --- Comment #7 from Marek Olšák --- A compiler bug is a compiler bug. Sorry, I don't know how to make that statement clearer. If you run the rgtc-teximage-01 piglit test, you'll see that it looks like the red channel only has 4 bits. -- 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/20150226/03c017ea/attachment.html>
[PATCH 1/3] drm/panel: Add display_timing support
Hi Philipp, On Mon, 23 Feb 2015 15:04:32 +0100 Philipp Zabel wrote: > Hi Thierry, > > do you have any further thoughts on this? > > Am Dienstag, den 03.02.2015, 14:30 +0100 schrieb Thierry Reding: > > On Thu, Dec 11, 2014 at 06:32:44PM +0100, Philipp Zabel wrote: > > > Many panel data sheets additionally to typical values list allowed ranges > > > for > > > timings such as hsync/vsync lengths, porches, and the pixel clock rate. > > > These > > > can be stored in a struct display_timing, to be used by an encoder > > > mode_fixup > > > callback to clamp user provided timing values or to validate workarounds > > > for > > > clock source limitations. > > > > > > This patch adds a new drm_panel_funcs callback that returns the panels' > > > available display_timing entries. Anthony recently noticed that the edt_etm0700g0dh6 panel he's connecting on his sama5 board defines typical timings that are not supported by Atmel's display controller. This patch could help us deal with such cases. Could you keep me (and Anthony) in Cc of your future versions ? Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[Bug 83226] Allow use of ColorRange and ColorSpace in xorg.conf.d files
https://bugs.freedesktop.org/show_bug.cgi?id=83226 Alex Deucher changed: What|Removed |Added CC||friedrich.timo at gmail.com --- Comment #19 from Alex Deucher --- *** Bug 87591 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/20150226/363ca5ad/attachment.html>
[Bug 83226] Allow use of ColorRange and ColorSpace in xorg.conf.d files
https://bugs.freedesktop.org/show_bug.cgi?id=83226 --- Comment #20 from Pitscho --- I've read a lot about tvrgb here, what is about YCbCr. My Tv for example produces a better picture with this space compared to limited RGB. -- 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/20150226/611ba41c/attachment.html>
[PATCH 1/2] drm: Complete moving rotation property to core
For both patches:
Reviewed-by: Matt Roper
On Thu, Feb 26, 2015 at 01:49:17PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Commit 1da30627fc511a57c9bd23a02c97f0576379f761 "drm: Add rotation value to
> plane state" moved the rotation property to DRM core but only did the set
> property part. This does the get property part as well.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Matt Roper
> Reviewed-by: Daniel Vetter
> Cc: dri-devel at lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_atomic.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 321e098..7ca54cb 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -450,6 +450,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> *val = state->src_w;
> } else if (property == config->prop_src_h) {
> *val = state->src_h;
> + } else if (property == config->rotation_property) {
> + *val = state->rotation;
> } else if (plane->funcs->atomic_get_property) {
> return plane->funcs->atomic_get_property(plane, state,
> property, val);
> } else {
> --
> 2.3.0
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
[Bug 83226] Allow use of ColorRange and ColorSpace in xorg.conf.d files
https://bugs.freedesktop.org/show_bug.cgi?id=83226 --- Comment #21 from Alex Deucher --- (In reply to Pitscho from comment #20) > I've read a lot about tvrgb here, what is about YCbCr. My Tv for example > produces a better picture with this space compared to limited RGB. YUV output is not supported yet. -- 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/20150226/7ef45084/attachment.html>
[Bug 93921] New: No Audio HDMI
https://bugzilla.kernel.org/show_bug.cgi?id=93921 Bug ID: 93921 Summary: No Audio HDMI Product: Drivers Version: 2.5 Kernel Version: 4.0-rc1 Hardware: i386 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: vincenzov72 at hotmail.com Regression: No I have a pc with a10-7800, with kernel 4.0-rc1, after a while it does not work hdmi audio. Kubuntu 14.10 64 bit. Sorry my english is bad. Whit old kernel not problem. dmesg |grep HDMI [3.320925] [drm] HDMI-A-1 [3.320939] [drm] HDMI-A-2 [ 10.515340] input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci:00/:00:01.1/sound/card0/input6 [ 10.515465] input: HD-Audio Generic HDMI/DP,pcm=7 as /devices/pci:00/:00:01.1/sound/card0/input7 [ 25.091471] sound hdaudioC0D0: HDMI ATI/AMD: no speaker allocation for ELD [ 25.092613] sound hdaudioC0D0: HDMI ATI/AMD: no speaker allocation for ELD [ 25.391257] sound hdaudioC0D0: HDMI ATI/AMD: no speaker allocation for ELD [ 25.691148] sound hdaudioC0D0: HDMI ATI/AMD: no speaker allocation for ELD [ 25.991059] sound hdaudioC0D0: HDMI ATI/AMD: no speaker allocation for ELD [ 26.290938] sound hdaudioC0D0: HDMI ATI/AMD: no speaker allocation for ELD [ 26.590844] sound hdaudioC0D0: HDMI ATI/AMD: no speaker allocation for ELD [ 26.890724] sound hdaudioC0D0: HDMI ATI/AMD: no speaker allocation for ELD [ 27.190621] sound hdaudioC0D0: HDMI ATI/AMD: no speaker allocation for ELD [ 27.490514] sound hdaudioC0D0: HDMI ATI/AMD: no speaker allocation for ELD uname -a Linux A10-7800 4.0.0-04rc1-generic #20150235 SMP Mon Feb 23 03:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 84648] Lag/Pause When VRAM->GTT or GTT->VRAM transfer occur
https://bugs.freedesktop.org/show_bug.cgi?id=84648 --- Comment #9 from commiethebeastie at gmail.com --- >Does >http://cgit.freedesktop.org/mesa/mesa/commit/?id=a338dc01866ce50bf7555ee8dc08491c7f63b585 > help? Possible yes. :) -- 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/20150226/3a3673c5/attachment.html>
[Bug 89196] Radeon GPU crashes at random times (GPU lockup)
https://bugs.freedesktop.org/show_bug.cgi?id=89196 --- Comment #6 from Maciej Gluszek --- UPDATE: I removed all additional tested kernel command lines that apply to Radeon besides radeon.dpm=1 for power management. I upgraded Ubuntu library and kernel to 3.16.0-31-generic. Also upgraded Mesa library to 10.3.2 OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV635 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.3.2 OpenGL shading language version string: 1.30 OpenGL context flags: (none) Lockups are still happening. I cannot specify which application is causing this. Lockups happen completly at random times. -- 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/20150226/6bdaa2ae/attachment.html>
[Intel-gfx] [PATCH 1/2] drm: Complete moving rotation property to core
On Thu, Feb 26, 2015 at 07:24:24AM -0800, Matt Roper wrote:
> For both patches:
>
> Reviewed-by: Matt Roper
Both merged to drm-misc, thanks.
-Daniel
>
> On Thu, Feb 26, 2015 at 01:49:17PM +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Commit 1da30627fc511a57c9bd23a02c97f0576379f761 "drm: Add rotation value to
> > plane state" moved the rotation property to DRM core but only did the set
> > property part. This does the get property part as well.
> >
> > Signed-off-by: Tvrtko Ursulin
> > Cc: Matt Roper
> > Reviewed-by: Daniel Vetter
> > Cc: dri-devel at lists.freedesktop.org
> > ---
> > drivers/gpu/drm/drm_atomic.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 321e098..7ca54cb 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -450,6 +450,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> > *val = state->src_w;
> > } else if (property == config->prop_src_h) {
> > *val = state->src_h;
> > + } else if (property == config->rotation_property) {
> > + *val = state->rotation;
> > } else if (plane->funcs->atomic_get_property) {
> > return plane->funcs->atomic_get_property(plane, state,
> > property, val);
> > } else {
> > --
> > 2.3.0
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[patch -next] drm/i915: fix a printk format
This printk leads to the following Smatch warning: drivers/gpu/drm/i915/i915_gem_gtt.c:336 alloc_pt_range() error: '%pa' expects argument of type 'phys_addr_t*', argument 5 has type 'struct i915_page_table_entry*' It looks like a simple typo to me where "%p" was intended instead of "%pa". Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index e05488e..48eff65 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -334,7 +334,7 @@ static int alloc_pt_range(struct i915_page_directory_entry *pd, uint16_t pde, si goto err_out; } WARN(pd->page_table[i], -"Leaking page directory entry %d (%pa)\n", +"Leaking page directory entry %d (%p)\n", i, pd->page_table[i]); pd->page_table[i] = pt; }
[Bug 89196] Radeon GPU crashes at random times (GPU lockup)
https://bugs.freedesktop.org/show_bug.cgi?id=89196 --- Comment #7 from Alex Deucher --- (In reply to Maciej Gluszek from comment #6) > UPDATE: > > I removed all additional tested kernel command lines that apply to Radeon > besides radeon.dpm=1 for power management. > Lockups are still happening. I cannot specify which application is causing > this. Lockups happen completly at random times. dpm is disabled by default on rv6xx due to stability issues. It's likely that may be the problem you are seeing. In that case, this bug is a duplicate of bug 66963. -- 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/20150226/ce53c948/attachment.html>
[PATCH 02/11] drm: add bindings for simple vga encoders
Hi Heiko,
Thank you for the patch.
On Saturday 31 January 2015 17:32:55 Heiko Stuebner wrote:
> Add the necessary devicetree binding document for simple vga encoders.
>
> Signed-off-by: Heiko Stuebner
> ---
> .../devicetree/bindings/drm/i2c/vga-simple.txt | 18 +++
> 1 file changed, 18 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/drm/i2c/vga-simple.txt
>
> diff --git a/Documentation/devicetree/bindings/drm/i2c/vga-simple.txt
> b/Documentation/devicetree/bindings/drm/i2c/vga-simple.txt new file mode
> 100644
> index 000..271df9a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/i2c/vga-simple.txt
> @@ -0,0 +1,18 @@
> +Device-Tree bindings for generic vga encoders
> +
> +Required properties;
> + - compatible: must be "adi,adv7123"
Bindings already exist for that device, they have been added in commit
8d0f1956f7c11202 ("video: Add ADV7123 DT bindings documentation").
> +Optional properties:
> + - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> + - enable-gpio: GPIO pin to enable or disable the encoder
> + - vaa-supply: regulator for the analog power supply
> +
> +Example:
> +
> + adv7123: vga-encoder {
> + compatible = "adi,adv7123";
> + ddc-i2c-bus = <&i2c4>;
> + vaa-supply = <&vcc_io>;
> + enable-gpio = <&gpio0 17 GPIO_ACTIVE_HIGH>;
> + };
--
Regards,
Laurent Pinchart
[PATCH 03/11] drm: add driver for simple vga encoders
Hi Heiko,
Thank you for the patch.
On Saturday 31 January 2015 17:32:56 Heiko Stuebner wrote:
> There exist simple vga encoders without any type of management interface
> and just maybe a simple gpio for turning it on or off. Examples for these
> are the Analog Devices ADV7123, Chipsea CS7123 or Micronas SDA7123.
>
> Add a generic encoder driver for those that can be used by drm drivers
> using the component framework.
The rcar-du driver already handles the adi,adv7123 compatible string used by
this driver. A generic driver is in my opinion a very good idea, but we can't
break the existing support. Porting the rcar-du driver to the component model
is needed.
> Signed-off-by: Heiko Stuebner
> ---
> drivers/gpu/drm/i2c/Kconfig | 6 +
> drivers/gpu/drm/i2c/Makefile | 2 +
> drivers/gpu/drm/i2c/vga-simple.c | 325
drivers/gpu/drm/i2c/ feels wrong for a platform device.
> 3 files changed, 333 insertions(+)
> create mode 100644 drivers/gpu/drm/i2c/vga-simple.c
>
> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> index 22c7ed6..319f2cb 100644
> --- a/drivers/gpu/drm/i2c/Kconfig
> +++ b/drivers/gpu/drm/i2c/Kconfig
> @@ -31,4 +31,10 @@ config DRM_I2C_NXP_TDA998X
> help
> Support for NXP Semiconductors TDA998X HDMI encoders.
>
> +config DRM_VGA_SIMPLE
> + tristate "Generic simple vga encoder"
> + help
> + Support for vga encoder chips without any special settings
> + and at most a power-control gpio.
> +
> endmenu
> diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
> index 2c72eb5..858961f 100644
> --- a/drivers/gpu/drm/i2c/Makefile
> +++ b/drivers/gpu/drm/i2c/Makefile
> @@ -10,3 +10,5 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
>
> tda998x-y := tda998x_drv.o
> obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
> +
> +obj-$(CONFIG_DRM_VGA_SIMPLE) += vga-simple.o
> diff --git a/drivers/gpu/drm/i2c/vga-simple.c
> b/drivers/gpu/drm/i2c/vga-simple.c new file mode 100644
> index 000..bb9d19c
> --- /dev/null
> +++ b/drivers/gpu/drm/i2c/vga-simple.c
> @@ -0,0 +1,325 @@
> +/*
> + * Simple vga encoder driver
> + *
> + * Copyright (C) 2014 Heiko Stuebner
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define connector_to_vga_simple(x) container_of(x, struct vga_simple,
> connector) +#define encoder_to_vga_simple(x) container_of(x, struct
> vga_simple, encoder) +
> +struct vga_simple {
> + struct drm_connector connector;
> + struct drm_encoder encoder;
> +
> + struct device *dev;
> + struct i2c_adapter *ddc;
> +
> + struct regulator *vaa_reg;
> + struct gpio_desc *enable_gpio;
> +
> + struct mutex enable_lock;
> + bool enabled;
> +};
> +
> +/*
> + * Connector functions
> + */
> +
> +enum drm_connector_status vga_simple_detect(struct drm_connector
> *connector, + bool force)
> +{
> + struct vga_simple *vga = connector_to_vga_simple(connector);
> +
> + if (!vga->ddc)
> + return connector_status_unknown;
> +
> + if (drm_probe_ddc(vga->ddc))
> + return connector_status_connected;
> +
> + return connector_status_disconnected;
> +}
> +
> +void vga_simple_connector_destroy(struct drm_connector *connector)
> +{
> + drm_connector_unregister(connector);
> + drm_connector_cleanup(connector);
> +}
> +
> +struct drm_connector_funcs vga_simple_connector_funcs = {
> + .dpms = drm_helper_connector_dpms,
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .detect = vga_simple_detect,
> + .destroy = vga_simple_connector_destroy,
> +};
> +
> +/*
> + * Connector helper functions
> + */
> +
> +static int vga_simple_connector_get_modes(struct drm_connector *connector)
> +{
> + struct vga_simple *vga = connector_to_vga_simple(connector);
> + struct edid *edid;
> + int ret = 0;
> +
> + if (!vga->ddc)
> + return 0;
> +
> + edid = drm_get_edid(connector, vga->ddc);
> + if (edid) {
> + drm_mode_connector_update_edid_property(connector, edid);
> + ret = drm_add_edid_modes(connector, edid);
> + kfree(edid);
> + }
> +
> + return ret;
> +}
> +
> +static int vga_simple_connector_mode_valid(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> +
[PATCH 1/3] drm/panel: Add display_timing support
Hi Boris, Am Donnerstag, den 26.02.2015, 14:51 +0100 schrieb Boris Brezillon: > Hi Philipp, > > On Mon, 23 Feb 2015 15:04:32 +0100 > Philipp Zabel wrote: > > > Hi Thierry, > > > > do you have any further thoughts on this? > > > > Am Dienstag, den 03.02.2015, 14:30 +0100 schrieb Thierry Reding: > > > On Thu, Dec 11, 2014 at 06:32:44PM +0100, Philipp Zabel wrote: > > > > Many panel data sheets additionally to typical values list allowed > > > > ranges for > > > > timings such as hsync/vsync lengths, porches, and the pixel clock rate. > > > > These > > > > can be stored in a struct display_timing, to be used by an encoder > > > > mode_fixup > > > > callback to clamp user provided timing values or to validate > > > > workarounds for > > > > clock source limitations. > > > > > > > > This patch adds a new drm_panel_funcs callback that returns the panels' > > > > available display_timing entries. > > Anthony recently noticed that the edt_etm0700g0dh6 panel he's > connecting on his sama5 board defines typical timings that are not > supported by Atmel's display controller. > This patch could help us deal with such cases. > Could you keep me (and Anthony) in Cc of your future versions ? Will do. regards Philipp
[Bug 89196] Radeon GPU crashes at random times (GPU lockup)
https://bugs.freedesktop.org/show_bug.cgi?id=89196 --- Comment #8 from Maciej Gluszek --- I see. I was running Ubuntu without dpm at first but GPU temperature was too high. When i disable dpm GPU temp is about 10-15 degress higher and the fan is louder than with dpm enabled. Is there any other way to turn on some power management for this card without using dpm? Thanks -- 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/20150226/77937336/attachment.html>
[PATCH 04/11] dt-bindings: Add documentation for rockchip lvds
Hi Heiko,
Thank you for the patch.
On Saturday 31 January 2015 17:32:57 Heiko Stuebner wrote:
> From: Mark Yao
>
> Add binding documentation for Rockchip SoC LVDS driver.
>
> Signed-off-by: Mark Yao
> Signed-off-by: Heiko Stuebner
> ---
> .../devicetree/bindings/video/rockchip-lvds.txt| 59 +++
> 1 file changed, 59 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/video/rockchip-lvds.txt
>
> diff --git a/Documentation/devicetree/bindings/video/rockchip-lvds.txt
> b/Documentation/devicetree/bindings/video/rockchip-lvds.txt new file mode
> 100644
> index 000..1616d7e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/rockchip-lvds.txt
> @@ -0,0 +1,59 @@
> +Rockchip RK3288 LVDS interface
> +
> +
> +Required properties:
> +- compatible: "rockchip,rk3288-lvds";
> +
> +- reg: physical base address of the controller and length
> + of memory mapped region.
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +- clock-names: must contain "pclk_lvds"
> +
> +- avdd1v0-supply: regulator phandle for 1.0V analog power
> +- avdd1v8-supply: regulator phandle for 1.8V analog power
> +- avdd3v3-supply: regulator phandle for 3.3V analog power
> +
> +- rockchip,grf: phandle to the general register files syscon
> +- rockchip,panel: phandle to a panel node as described by
> + Documentation/devicetree/bindings/panel/*
Doesn't this duplicate the information provided by the ports ?
> +- rockchip,data-mapping: should be "vesa" or "jeida",
> + This describes how the color bits are laid out in the
> + serialized LVDS signal.
> +- rockchip,data-width : should be <18> or <24>;
> +- rockchip,output: should be "rgb", "lvds" or "duallvds",
> + This describes the output face.
Isn't all this panel-dependent ? Could we query the information from the panel
at runtime instead ?
> +- ports: contain a port node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> + lvds: lvds at ff96c000 {
> + compatible = "rockchip,rk3288-lvds";
> + rockchip,grf = <&grf>;
> + reg = <0xff96c000 0x4000>;
> + clocks = <&cru PCLK_LVDS_PHY>;
> + clock-names = "pclk_lvds";
> + avdd1v0-supply = <&vdd10_lcd>;
> + avdd1v8-supply = <&vcc18_lcd>;
> + avdd3v3-supply = <&vcca_33>;
> + rockchip,panel = <&panel>;
> + rockchip,data-mapping = "jeida";
> + rockchip,data-width = <24>;
> + rockchip,output = "rgb";
> + ports {
> + lvds_in: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + lvds_in_vopb: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vopb_out_lvds>;
> + };
> + lvds_in_vopl: endpoint at 1 {
> + reg = <1>;
> + remote-endpoint = <&vopl_out_lvds>;
> + };
> + };
> + };
> + };
--
Regards,
Laurent Pinchart
[Bug 89196] Radeon GPU crashes at random times (GPU lockup)
https://bugs.freedesktop.org/show_bug.cgi?id=89196 --- Comment #9 from Alex Deucher --- (In reply to Maciej Gluszek from comment #8) > I see. I was running Ubuntu without dpm at first but GPU temperature was too > high. > > When i disable dpm GPU temp is about 10-15 degress higher and the fan is > louder than with dpm enabled. > > Is there any other way to turn on some power management for this card > without using dpm? Thanks You can manually select the performance levels via the old pm sysfs interface. See the "KMS Power Management Options" section on this page: http://xorg.freedesktop.org/wiki/RadeonFeature/ -- 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/20150226/049cb960/attachment.html>
[PATCH RESEND] drm: tda998x: Use drm_do_get_edid()
Hi Russell, On Thursday 26 February 2015 09:20:08 Russell King - ARM Linux wrote: > On Thu, Feb 26, 2015 at 09:52:02AM +0200, Laurent Pinchart wrote: > > On Friday 16 January 2015 17:47:34 Russell King - ARM Linux wrote: > >> On Fri, Jan 16, 2015 at 06:37:43PM +0200, Laurent Pinchart wrote: > >>> Replace the internal EDID read implementation by a call to the new > >>> EDID > >>> read core function. > >>> > >>> Signed-off-by: Laurent Pinchart > >>> > >>> Reviewed-by: Rob Clark > >>> Tested-by: Jean-Francois Moine > >> > >> Thanks, committed, and updated the summary line to: > >> > >> "drm/i2c: tda998x: use drm_do_get_edid()" > >> > >> to match the style used in the past. > > > > I can't see the patch in Dave's -next branch, has it been lost somewhere ? > > I thought I had sent a pull request before the last merge window, but > it seems I didn't. That's the problem when you end up carrying too many > patches... tracking what's been sent and to whom is a real pain. The > only time I get to verify what's been sent is after it's appeared in > mainline (so after a merge window). No worries. Looks like I'm part of a distributed patch tracker system then ;-) -- Regards, Laurent Pinchart
[PATCH] drm/i915: fix failure to power off after hibernate
On to, 2015-02-26 at 10:34 +0100, Bjørn Mork wrote: > Imre Deak writes: > > >> That patch fixes the problem, with only pci_set_power_state commented > >> out. Do you still want me to try with pci_disable_device() commented > >> out as well? > > > > No, but it would help if you could still try the two attached patch > > separately, without any of the previous workarounds. Based on the > > result, we'll follow up with a fix that adds for your specific platform > > either of the attached workarounds or simply avoids putting the device > > into D3 (corresponding to the patch you already tried). > > None of those patches made any difference. The laptop still hangs at > power-off. > > Not really surprising, is it? Previous testing shows that the hang > occurs at the pci_set_power_state(drm_dev->pdev, PCI_D3hot) call in the > poweroff_late hook. It is hard to see how replacing it by an attempt to > set D3cold, or adding any call after this point, could possibly change > anything. The system is stil hanging at the pci_set_power_state() call. Judging from the blinking LED, I assume that it's not pci_set_power_state() that hangs the machine, but the hang happens in BIOS code. > The generic pci-driver code will put the i915 device into PCI_D3hot for > you, won't it? Why do you need to duplicate that in the driver, > *knowing* that doing so breaks (at least some) systems? Letting the pci core put the device into D3 wouldn't get rid of the problem. It's putting the device into D3 in the first place what causes it. > I honestly don't think this "let's try some random code" is the proper > way to fix this bug (or any other bug for that matter). You need to > start understanding the code you write, and the first step is by > actually explaining the changes you make. We have a good understanding about the issue: the BIOS on your platform does something unexpected behind the back of the driver/kernel. In that sense the patches were not random, for instance the first one is based on an existing workaround for an issue that resembles quite a lot yours, see pci_pm_poweroff_noirq(). > I also believe that you completely miss the fact that this bug has > survived a full release cycle before you became aware of it, and the > implications this has wrt other affected systems/users. I assume you > understand that my system isn't one-of-a-kind, This means that there are > other affected users with identical/similar systems. Now, if none of > those users reported the bug to you (we all know why: Linux kernel > development is currently limited by the available testing resources, NOT > by the available developer resources), then how do you know that there > aren't a number of other systems affected as well? > > Let me answer that for you: You don't. > > Which is why you must explain the mechanism triggering the bug, proving > that it is a chipset/system specific issue. Because that's the only way > you will *know* that you have solved the problem not only for me, but for > all affected users. > > IMHO, the only safe and sane solution at the moment is the revert patch > I posted. It's a simple fix, reverting back to the *known* working > state before this regression was introduced. > > Then you can start over from there, trying to implement this properly. The current way is the proper one that we want for the generic case. The issue on your platform is the exception, so working around that is a sensible choice. Attached is the proposed fix for this issue. --Imre -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-i915-gm45-work-around-hang-during-hibernation.patch Type: text/x-patch Size: 3625 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150226/52357a6d/attachment-0001.bin>
[Intel-gfx] [patch -next] drm/i915: fix a printk format
On Thu, Feb 26, 2015 at 07:53:54PM +0300, Dan Carpenter wrote: > This printk leads to the following Smatch warning: > > drivers/gpu/drm/i915/i915_gem_gtt.c:336 alloc_pt_range() > error: '%pa' expects argument of type 'phys_addr_t*', > argument 5 has type 'struct i915_page_table_entry*' > > It looks like a simple typo to me where "%p" was intended instead of > "%pa". > > Signed-off-by: Dan Carpenter Queued for -next, thanks for the patch. -Daniel > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > b/drivers/gpu/drm/i915/i915_gem_gtt.c > index e05488e..48eff65 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -334,7 +334,7 @@ static int alloc_pt_range(struct > i915_page_directory_entry *pd, uint16_t pde, si > goto err_out; > } > WARN(pd->page_table[i], > - "Leaking page directory entry %d (%pa)\n", > + "Leaking page directory entry %d (%p)\n", >i, pd->page_table[i]); > pd->page_table[i] = pt; > } > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate
On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote: > On to, 2015-02-26 at 10:34 +0100, Bjørn Mork wrote: > > Imre Deak writes: > > > > >> That patch fixes the problem, with only pci_set_power_state commented > > >> out. Do you still want me to try with pci_disable_device() commented > > >> out as well? > > > > > > No, but it would help if you could still try the two attached patch > > > separately, without any of the previous workarounds. Based on the > > > result, we'll follow up with a fix that adds for your specific platform > > > either of the attached workarounds or simply avoids putting the device > > > into D3 (corresponding to the patch you already tried). > > > > None of those patches made any difference. The laptop still hangs at > > power-off. > > > > Not really surprising, is it? Previous testing shows that the hang > > occurs at the pci_set_power_state(drm_dev->pdev, PCI_D3hot) call in the > > poweroff_late hook. It is hard to see how replacing it by an attempt to > > set D3cold, or adding any call after this point, could possibly change > > anything. The system is stil hanging at the pci_set_power_state() call. > > Judging from the blinking LED, I assume that it's not > pci_set_power_state() that hangs the machine, but the hang happens in > BIOS code. > > > The generic pci-driver code will put the i915 device into PCI_D3hot for > > you, won't it? Why do you need to duplicate that in the driver, > > *knowing* that doing so breaks (at least some) systems? > > Letting the pci core put the device into D3 wouldn't get rid of the problem. > It's putting the device into D3 in the first place what causes it. > > > I honestly don't think this "let's try some random code" is the proper > > way to fix this bug (or any other bug for that matter). You need to > > start understanding the code you write, and the first step is by > > actually explaining the changes you make. > > We have a good understanding about the issue: the BIOS on your platform > does something unexpected behind the back of the driver/kernel. In that > sense the patches were not random, for instance the first one is based on > an existing workaround for an issue that resembles quite a lot yours, see > pci_pm_poweroff_noirq(). > > > I also believe that you completely miss the fact that this bug has > > survived a full release cycle before you became aware of it, and the > > implications this has wrt other affected systems/users. I assume you > > understand that my system isn't one-of-a-kind, This means that there are > > other affected users with identical/similar systems. Now, if none of > > those users reported the bug to you (we all know why: Linux kernel > > development is currently limited by the available testing resources, NOT > > by the available developer resources), then how do you know that there > > aren't a number of other systems affected as well? > > > > Let me answer that for you: You don't. > > > > Which is why you must explain the mechanism triggering the bug, proving > > that it is a chipset/system specific issue. Because that's the only way > > you will *know* that you have solved the problem not only for me, but for > > all affected users. > > > > IMHO, the only safe and sane solution at the moment is the revert patch > > I posted. It's a simple fix, reverting back to the *known* working > > state before this regression was introduced. > > > > Then you can start over from there, trying to implement this properly. > > The current way is the proper one that we want for the generic case. The issue > on your platform is the exception, so working around that is a sensible > choice. > > Attached is the proposed fix for this issue. > > --Imre > > From 5c23657bc168db12a1ba100ab65fabd305c89c8a Mon Sep 17 00:00:00 2001 > From: Imre Deak > Date: Thu, 26 Feb 2015 18:38:53 +0200 > Subject: [PATCH] drm/i915: gm45: work around hang during hibernation > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Bjørn reported that his machine hang during hibernation and eventually > bisected the problem to the following commit: > > commit da2bc1b9db3351addd293e5b82757efe1f77ed1d > Author: Imre Deak > Date: Thu Oct 23 19:23:26 2014 +0300 > > drm/i915: add poweroff_late handler > > The problem seems to be that after the kernel puts the device into D3 > the BIOS still tries to access it, or otherwise assumes that it's in D0. > This is clearly bogus, since ACPI mandates that devices are put into D3 > by the OSPM if they are not wake-up sources. In the future we want to > unify more of the driver's runtime and system suspend paths, for example > by skipping all the system suspend/hibernation hooks if the device is > runtime suspended already. Accordingly for all other platforms the goal > is still to properly power down the device during hibernation. > > Reference: > http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html > Reported-a
[PATCH] drm/i915: fix failure to power off after hibernate
On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote: > On to, 2015-02-26 at 10:34 +0100, Bjørn Mork wrote: > > Imre Deak writes: > > > > >> That patch fixes the problem, with only pci_set_power_state commented > > >> out. Do you still want me to try with pci_disable_device() commented > > >> out as well? > > > > > > No, but it would help if you could still try the two attached patch > > > separately, without any of the previous workarounds. Based on the > > > result, we'll follow up with a fix that adds for your specific platform > > > either of the attached workarounds or simply avoids putting the device > > > into D3 (corresponding to the patch you already tried). > > > > None of those patches made any difference. The laptop still hangs at > > power-off. > > > > Not really surprising, is it? Previous testing shows that the hang > > occurs at the pci_set_power_state(drm_dev->pdev, PCI_D3hot) call in the > > poweroff_late hook. It is hard to see how replacing it by an attempt to > > set D3cold, or adding any call after this point, could possibly change > > anything. The system is stil hanging at the pci_set_power_state() call. > > Judging from the blinking LED, I assume that it's not > pci_set_power_state() that hangs the machine, but the hang happens in > BIOS code. > > > The generic pci-driver code will put the i915 device into PCI_D3hot for > > you, won't it? Why do you need to duplicate that in the driver, > > *knowing* that doing so breaks (at least some) systems? > > Letting the pci core put the device into D3 wouldn't get rid of the problem. > It's putting the device into D3 in the first place what causes it. > > > I honestly don't think this "let's try some random code" is the proper > > way to fix this bug (or any other bug for that matter). You need to > > start understanding the code you write, and the first step is by > > actually explaining the changes you make. > > We have a good understanding about the issue: the BIOS on your platform > does something unexpected behind the back of the driver/kernel. In that > sense the patches were not random, for instance the first one is based on > an existing workaround for an issue that resembles quite a lot yours, see > pci_pm_poweroff_noirq(). > > > I also believe that you completely miss the fact that this bug has > > survived a full release cycle before you became aware of it, and the > > implications this has wrt other affected systems/users. I assume you > > understand that my system isn't one-of-a-kind, This means that there are > > other affected users with identical/similar systems. Now, if none of > > those users reported the bug to you (we all know why: Linux kernel > > development is currently limited by the available testing resources, NOT > > by the available developer resources), then how do you know that there > > aren't a number of other systems affected as well? > > > > Let me answer that for you: You don't. > > > > Which is why you must explain the mechanism triggering the bug, proving > > that it is a chipset/system specific issue. Because that's the only way > > you will *know* that you have solved the problem not only for me, but for > > all affected users. > > > > IMHO, the only safe and sane solution at the moment is the revert patch > > I posted. It's a simple fix, reverting back to the *known* working > > state before this regression was introduced. > > > > Then you can start over from there, trying to implement this properly. > > The current way is the proper one that we want for the generic case. The issue > on your platform is the exception, so working around that is a sensible > choice. > > Attached is the proposed fix for this issue. > > --Imre > > From 5c23657bc168db12a1ba100ab65fabd305c89c8a Mon Sep 17 00:00:00 2001 > From: Imre Deak > Date: Thu, 26 Feb 2015 18:38:53 +0200 > Subject: [PATCH] drm/i915: gm45: work around hang during hibernation > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Bjørn reported that his machine hang during hibernation and eventually > bisected the problem to the following commit: > > commit da2bc1b9db3351addd293e5b82757efe1f77ed1d > Author: Imre Deak > Date: Thu Oct 23 19:23:26 2014 +0300 > > drm/i915: add poweroff_late handler > > The problem seems to be that after the kernel puts the device into D3 > the BIOS still tries to access it, or otherwise assumes that it's in D0. > This is clearly bogus, since ACPI mandates that devices are put into D3 > by the OSPM if they are not wake-up sources. In the future we want to > unify more of the driver's runtime and system suspend paths, for example > by skipping all the system suspend/hibernation hooks if the device is > runtime suspended already. Accordingly for all other platforms the goal > is still to properly power down the device during hibernation. > > Reference: > http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html > Reported-a
[Bug 93921] No Audio HDMI
https://bugzilla.kernel.org/show_bug.cgi?id=93921 Dieter Nützel changed: What|Removed |Added CC||Dieter at nuetzel-hh.de --- Comment #1 from Dieter Nützel --- It is a regression: 3.19 to 4.0-rc1 Seems to be duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=89327 When you hit DRI/DRM/gfx bug please have a look first at bugs.freedesktop.org Try to reenable HDMI audio with: xrandr --output HDMI-0 --set audio on or xrandr --output HDMI-0 --set audio auto -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering
https://bugs.freedesktop.org/show_bug.cgi?id=73528 --- Comment #30 from MirceaKitsune --- Still waiting for news please. Like I said, the patch in comment 28 does not fix the issue, but the patch in comment 23 did. I'm hoping there is enough data to make a solution possible before the next release, if not I can still test other patches. -- 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/20150226/d375ec87/attachment.html>
[Bug 89196] Radeon GPU crashes at random times (GPU lockup)
https://bugs.freedesktop.org/show_bug.cgi?id=89196 --- Comment #10 from Maciej Gluszek --- Unfortunately it didn't take long again.. I removed dpm parameter from startup. There are no radeon related parameters active. Then i set performance level by hand to "med", after a while to "low". After about 2 hours it locked up again with the same error (GPU 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/20150226/40605180/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #31 from Gustavo Lopes --- I'm using 4.0-rc1 and the radeon module now works, but it hangs once or twice a day, something I did not experience with catalyst. It seems to be more frequent under load. -- 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/20150226/b1ad4967/attachment.html>
[PATCH] drm/i915: fix failure to power off after hibernate
Imre Deak writes: >> That patch fixes the problem, with only pci_set_power_state commented >> out. Do you still want me to try with pci_disable_device() commented >> out as well? > > No, but it would help if you could still try the two attached patch > separately, without any of the previous workarounds. Based on the > result, we'll follow up with a fix that adds for your specific platform > either of the attached workarounds or simply avoids putting the device > into D3 (corresponding to the patch you already tried). None of those patches made any difference. The laptop still hangs at power-off. Not really surprising, is it? Previous testing shows that the hang occurs at the pci_set_power_state(drm_dev->pdev, PCI_D3hot) call in the poweroff_late hook. It is hard to see how replacing it by an attempt to set D3cold, or adding any call after this point, could possibly change anything. The system is stil hanging at the pci_set_power_state() call. The generic pci-driver code will put the i915 device into PCI_D3hot for you, won't it? Why do you need to duplicate that in the driver, *knowing* that doing so breaks (at least some) systems? I honestly don't think this "let's try some random code" is the proper way to fix this bug (or any other bug for that matter). You need to start understanding the code you write, and the first step is by actually explaining the changes you make. I also believe that you completely miss the fact that this bug has survived a full release cycle before you became aware of it, and the implications this has wrt other affected systems/users. I assume you understand that my system isn't one-of-a-kind, This means that there are other affected users with identical/similar systems. Now, if none of those users reported the bug to you (we all know why: Linux kernel development is currently limited by the available testing resources, NOT by the available developer resources), then how do you know that there aren't a number of other systems affected as well? Let me answer that for you: You don't. Which is why you must explain the mechanism triggering the bug, proving that it is a chipset/system specific issue. Because that's the only way you will *know* that you have solved the problem not only for me, but for all affected users. IMHO, the only safe and sane solution at the moment is the revert patch I posted. It's a simple fix, reverting back to the *known* working state before this regression was introduced. Then you can start over from there, trying to implement this properly. Thanks, Bjørn
[PATCH v2 3/4] nouveau: make nouveau importing global buffers completely thread-safe, with tests
While I've closed off most races in a previous patch, a small race still existed
where importing then unreffing cound cause an invalid bo. Add a test for this
case.
Racing sequence fixed:
- thread 1 releases bo, refcount drops to zero, blocks on acquiring nvdev->lock.
- thread 2 increases refcount to 1.
- thread 2 decreases refcount to zero, blocks on acquiring nvdev->lock.
At this point the 2 threads will clean up the same bo.
Signed-off-by: Maarten Lankhorst
Reviewed-By: Emil Velikov
---
configure.ac | 1 +
nouveau/nouveau.c | 69 ++--
tests/Makefile.am | 4 ++
tests/nouveau/.gitignore | 1 +
tests/nouveau/Makefile.am | 16 +
tests/nouveau/threaded.c | 156 ++
6 files changed, 210 insertions(+), 37 deletions(-)
create mode 100644 tests/nouveau/.gitignore
create mode 100644 tests/nouveau/Makefile.am
create mode 100644 tests/nouveau/threaded.c
diff --git a/configure.ac b/configure.ac
index 8afee83..6dc5044 100644
--- a/configure.ac
+++ b/configure.ac
@@ -441,6 +441,7 @@ AC_CONFIG_FILES([
tests/vbltest/Makefile
tests/exynos/Makefile
tests/tegra/Makefile
+ tests/nouveau/Makefile
man/Makefile
libdrm.pc])
AC_OUTPUT
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index c6c153a..1c723b9 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@@ -351,29 +351,18 @@ nouveau_bo_del(struct nouveau_bo *bo)
pthread_mutex_lock(&nvdev->lock);
if (nvbo->name) {
- if (atomic_read(&nvbo->refcnt)) {
+ if (atomic_read(&nvbo->refcnt) == 0) {
+ DRMLISTDEL(&nvbo->head);
/*
-* bo has been revived by a race with
-* nouveau_bo_prime_handle_ref, or nouveau_bo_name_ref.
-*
-* In theory there's still a race possible with
-* nouveau_bo_wrap, but when using this function
-* the lifetime of the handle is probably already
-* handled in another way. If there are races
-* you're probably using nouveau_bo_wrap wrong.
+* This bo has to be closed with the lock held because
+* gem handles are not refcounted. If a shared bo is
+* closed and re-opened in another thread a race
+* against DRM_IOCTL_GEM_OPEN or drmPrimeFDToHandle
+* might cause the bo to be closed accidentally while
+* re-importing.
*/
- pthread_mutex_unlock(&nvdev->lock);
- return;
+ drmIoctl(bo->device->fd, DRM_IOCTL_GEM_CLOSE, &req);
}
- DRMLISTDEL(&nvbo->head);
- /*
-* This bo has to be closed with the lock held because gem
-* handles are not refcounted. If a shared bo is closed and
-* re-opened in another thread a race against
-* DRM_IOCTL_GEM_OPEN or drmPrimeFDToHandle might cause the
-* bo to be closed accidentally while re-importing.
-*/
- drmIoctl(bo->device->fd, DRM_IOCTL_GEM_CLOSE, &req);
pthread_mutex_unlock(&nvdev->lock);
} else {
DRMLISTDEL(&nvbo->head);
@@ -418,7 +407,7 @@ nouveau_bo_new(struct nouveau_device *dev, uint32_t flags,
uint32_t align,
static int
nouveau_bo_wrap_locked(struct nouveau_device *dev, uint32_t handle,
- struct nouveau_bo **pbo)
+ struct nouveau_bo **pbo, int name)
{
struct nouveau_device_priv *nvdev = nouveau_device(dev);
struct drm_nouveau_gem_info req = { .handle = handle };
@@ -427,8 +416,24 @@ nouveau_bo_wrap_locked(struct nouveau_device *dev,
uint32_t handle,
DRMLISTFOREACHENTRY(nvbo, &nvdev->bo_list, head) {
if (nvbo->base.handle == handle) {
- *pbo = NULL;
- nouveau_bo_ref(&nvbo->base, pbo);
+ if (atomic_inc_return(&nvbo->refcnt) == 1) {
+ /*
+* Uh oh, this bo is dead and someone else
+* will free it, but because refcnt is
+* now non-zero fortunately they won't
+* call the ioctl to close the bo.
+*
+* Remove this bo from the list so other
+* calls to nouveau_bo_wrap_locked will
+* see our replacement nvbo.
+*/
+ DRMLISTDEL(&nvbo->head);
+ if (!name)
+
[PATCH 09/21] drm/omap: handle mismatching color format and buffer width
omapdrm doesn't check if the width of the framebuffer and the color
format's bits-per-pixel match.
For example, using a display with a width of 1280, and a buffer
allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with
a 24 bits per pixel color format, leads to the following mismatch:
5120/3 = 1706.666... bytes. This causes bad colors and a tilt on the
screen.
Add a check into omapdrm to return an error if the user tries to use
such a combination.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 2975096abdf5..bf98580223d0 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct
drm_device *dev,
goto fail;
}
+ if (mode_cmd->width % format->planes[i].stride_bpp != 0) {
+ dev_err(dev->dev,
+ "buffer width (%d) is not a multiple of pixel
width (%d)\n",
+ mode_cmd->width, format->planes[i].stride_bpp);
+ ret = -EINVAL;
+ goto fail;
+ }
+
size = pitch * mode_cmd->height / format->planes[i].sub_y;
if (size > (omap_gem_mmap_size(bos[i]) - mode_cmd->offsets[i]))
{
--
2.3.0
[PATCH 11/21] drm/omap: fix plane's channel selection
omap_plane_pre_apply() sets the plane's output channel too late, only after the plane has already been otherwise configured and enabled. This causes problems, as at the configuration stage we need to make decisions based on the output channel. This may lead to bad plane settings or failing to setup the plane. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_plane.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c b/drivers/gpu/drm/omapdrm/omap_plane.c index bedd6f7af0f1..8e94694ba8a3 100644 --- a/drivers/gpu/drm/omapdrm/omap_plane.c +++ b/drivers/gpu/drm/omapdrm/omap_plane.c @@ -153,6 +153,8 @@ static void omap_plane_pre_apply(struct omap_drm_apply *apply) ilace = false; replication = false; + dispc_ovl_set_channel_out(omap_plane->id, channel); + /* and finally, update omapdss: */ ret = dispc_ovl_setup(omap_plane->id, info, replication, omap_crtc_timings(crtc), false); @@ -162,7 +164,6 @@ static void omap_plane_pre_apply(struct omap_drm_apply *apply) } dispc_ovl_enable(omap_plane->id, true); - dispc_ovl_set_channel_out(omap_plane->id, channel); } static void omap_plane_post_apply(struct omap_drm_apply *apply) -- 2.3.0
[PATCH 18/21] drm/omap: do not use BUG_ON(!spin_is_locked(x))
spin_is_locked(x) returns always 0 on uniprocessor, triggering BUG() in omapdrm. Change it to use assert_spin_locked() to fix the issue. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c b/drivers/gpu/drm/omapdrm/omap_irq.c index f035d2bceae7..3eb097efc488 100644 --- a/drivers/gpu/drm/omapdrm/omap_irq.c +++ b/drivers/gpu/drm/omapdrm/omap_irq.c @@ -34,7 +34,7 @@ static void omap_irq_update(struct drm_device *dev) struct omap_drm_irq *irq; uint32_t irqmask = priv->vblank_mask; - BUG_ON(!spin_is_locked(&list_lock)); + assert_spin_locked(&list_lock); list_for_each_entry(irq, &priv->irq_list, node) irqmask |= irq->irqmask; -- 2.3.0
[PATCH 14/21] drm/omap: stop connector polling during suspend
Hi Tomi,
On 02/26/2015 03:20 PM, Tomi Valkeinen wrote:
> When not using proper hotplug detection, DRM polls periodically the
> connectors to find out if a cable is connected. This polling can happen
> at any time, even very late in the suspend process.
>
> This causes a problem with omapdrm, when the poll happens during the
> suspend process after GPIOs have been disabled, leading to a crash in
> gpio_get().
>
> This patch fixes the issue by adding suspend and resume hooks to
> omapdrm, in which we disable and enable, respectively, the polling.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/omap_drv.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 0ebd1315fff8..d0b1aece8cc5 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -694,9 +694,28 @@ static int pdev_remove(struct platform_device *device)
> return 0;
> }
>
> +static int omap_drm_suspend(struct device *dev)
> +{
> + struct drm_device *drm_dev = dev_get_drvdata(dev);
> +
> + drm_kms_helper_poll_disable(drm_dev);
> +
> + return 0;
> +}
> +
> +static int omap_drm_resume(struct device *dev)
> +{
> + struct drm_device *drm_dev = dev_get_drvdata(dev);
> +
> + drm_kms_helper_poll_enable(drm_dev);
> +
> + return omap_gem_resume(dev);
> +}
> +
> #ifdef CONFIG_PM
> static const struct dev_pm_ops omapdrm_pm_ops = {
> - .resume = omap_gem_resume,
> + .suspend = omap_drm_suspend,
> + .resume = omap_drm_resume,
> };
> #endif
>
>
Could I ask you to update this patch as below, pls?
Regards,
-grygorii
===
drm/omap: add hibernation callbacks
Setting a dev_pm_ops suspend/resume pair but not a set of
hibernation functions means those pm functions will not be
called upon hibernation.
Fix this by using SET_SYSTEM_SLEEP_PM_OPS, which appropriately
assigns the suspend and hibernation handlers and move
omap_drm_suspend/omap_drm_resume under CONFIG_PM_SLEEP
to avoid build warnings.
Signed-off-by: Grygorii Strashko
---
drivers/gpu/drm/omapdrm/omap_drv.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 7cb1c8f..4a544e4 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -715,6 +715,7 @@ static int pdev_remove(struct platform_device *device)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
static int omap_drm_suspend(struct device *dev)
{
struct drm_device *drm_dev = dev_get_drvdata(dev);
@@ -732,21 +733,15 @@ static int omap_drm_resume(struct device *dev)
return omap_gem_resume(dev);
}
-
-#ifdef CONFIG_PM
-static const struct dev_pm_ops omapdrm_pm_ops = {
- .suspend = omap_drm_suspend,
- .resume = omap_drm_resume,
-};
#endif
+static SIMPLE_DEV_PM_OPS(omapdrm_pm_ops, omap_drm_suspend, omap_drm_resume);
+
static struct platform_driver pdev = {
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
-#ifdef CONFIG_PM
.pm = &omapdrm_pm_ops,
-#endif
},
.probe = pdev_probe,
.remove = pdev_remove,
-- 1.9.1
--
regards,
-grygorii
[PATCH RFC 3/6] drm/tilcdc: Add support for external compontised DRM encoder
Add support for an external compontised DRM encoder. The external
encoder can be connected to tilcdc trough device tree graph binding.
The binding document for tilcdc has been updated. The support has only
been tested with tda998x encoder, but other encoders should work too
with a little tweaking.
I got the idea and some lines of code from Jean-Francois Moine's
"drm/tilcdc: Change the interface with the tda998x driver"-patch.
Signed-off-by: Jyri Sarha
---
.../devicetree/bindings/drm/tilcdc/tilcdc.txt | 27 ++
drivers/gpu/drm/tilcdc/Makefile| 1 +
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 33 +++
drivers/gpu/drm/tilcdc/tilcdc_drv.c| 56 ---
drivers/gpu/drm/tilcdc/tilcdc_drv.h| 2 +
drivers/gpu/drm/tilcdc/tilcdc_external.c | 105 +
drivers/gpu/drm/tilcdc/tilcdc_external.h | 24 +
7 files changed, 235 insertions(+), 13 deletions(-)
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index fff10da..2136ee8 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -18,6 +18,12 @@ Optional properties:
- max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.
+Optional nodes:
+
+ - port/ports: to describe a connection to an external encoder. The
+ binding follows Documentation/devicetree/bindings/graph.txt and
+ suppors a single port with a single endpoint.
+
Example:
fb: fb at 4830e000 {
@@ -26,4 +32,25 @@ Example:
interrupt-parent = <&intc>;
interrupts = <36>;
ti,hwmods = "lcdc";
+
+ port {
+ lcdc_0: endpoint at 0 {
+ remote-endpoint = <&hdmi_0>;
+ };
+ };
+ };
+
+ tda19988: tda19988 {
+ compatible = "nxp,tda998x";
+ reg = <0x70>;
+
+ pinctrl-names = "default", "off";
+ pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+ pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+
+ port {
+ hdmi_0: endpoint at 0 {
+ remote-endpoint = <&lcdc_0>;
+ };
+ };
};
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 44485f9..e1f738b 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -7,6 +7,7 @@ tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
tilcdc_panel.o \
+ tilcdc_external.o \
tilcdc_drv.o
obj-$(CONFIG_DRM_TILCDC) += tilcdc.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c2d5980..7d07733 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -37,6 +37,9 @@ struct tilcdc_crtc {
/* for deferred fb unref's: */
struct drm_flip_work unref_work;
+
+ /* Only set if an external encoder is connected */
+ bool simulate_vesa_sync;
};
#define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
@@ -214,6 +217,28 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+ if (!tilcdc_crtc->simulate_vesa_sync)
+ return true;
+
+ /*
+* tilcdc does not generate VESA-compliant sync but aligns
+* VS on the second edge of HS instead of first edge.
+* We use adjusted_mode, to fixup sync by aligning both rising
+* edges and add HSKEW offset to fix the sync.
+*/
+ adjusted_mode->hskew = mode->hsync_end - mode->hsync_start;
+ adjusted_mode->flags |= DRM_MODE_FLAG_HSKEW;
+
+ if (mode->flags & DRM_MODE_FLAG_NHSYNC) {
+ adjusted_mode->flags |= DRM_MODE_FLAG_PHSYNC;
+ adjusted_mode->flags &= ~DRM_MODE_FLAG_NHSYNC;
+ } else {
+ adjusted_mode->flags |= DRM_MODE_FLAG_NHSYNC;
+ adjusted_mode->flags &= ~DRM_MODE_FLAG_PHSYNC;
+ }
+
return true;
}
@@ -534,6 +559,14 @@ void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
tilcdc_crtc->info = info;
}
+void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc *crtc,
+ bool simulate_vesa_sync)
+{
+ struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+ tilcdc_crtc->simulate_vesa_sync = simulate_vesa_sync;
+}
+
void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
{
struct tilcdc_crtc *til
[PATCH 4/8] pwm: atmel-hlcdc: fix struct clk pointer comparing
Le 25/02/2015 15:53, Shawn Guo a écrit :
> Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> instances"), clk API users can no longer check if two struct clk
> pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
> simply comparing two pointers. That's because with the per-user clk
> change, a brand new struct clk is created whenever clients try to look
> up the clock by calling clk_get() or sister functions like clk_get_sys()
> and of_clk_get(). This changes the original behavior where the struct
> clk is only created for once when clock driver registers the clock to
> CCF in the first place. The net change here is before commit
> 035a61c314eb the struct clk pointer is unique for given hardware
> clock, while after the commit the pointers returned by clk lookup calls
> become different for the same hardware clock.
>
> That said, the struct clk pointer comparing in the code doesn't work any
> more. Call helper function clk_is_match() instead to fix the problem.
>
> Signed-off-by: Shawn Guo
I agree with the fix whichever name is chosen for the function in an
future version of this series. So you can add my:
Acked-by: Nicolas Ferre
Maybe Boris can double check...
> ---
> drivers/pwm/pwm-atmel-hlcdc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
> index 522f7075bb1a..36475949b829 100644
> --- a/drivers/pwm/pwm-atmel-hlcdc.c
> +++ b/drivers/pwm/pwm-atmel-hlcdc.c
> @@ -97,7 +97,7 @@ static int atmel_hlcdc_pwm_config(struct pwm_chip *c,
>
> pwmcfg = ATMEL_HLCDC_PWMPS(pres);
>
> - if (new_clk != chip->cur_clk) {
> + if (!clk_is_match(new_clk, chip->cur_clk)) {
> u32 gencfg = 0;
> int ret;
>
>
--
Nicolas Ferre
[alsa-devel] [PATCH 1/8] clk: add helper function clk_is_match()
On Wed, Feb 25, 2015 at 09:27:57AM -0800, Mike Turquette wrote:
> Quoting Shawn Guo (2015-02-25 06:53:31)
> > Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> > instances"), clk API users can no longer check if two struct clk
> > pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
> > simply comparing two pointers. That's because with the per-user clk
> > change, a brand new struct clk is created whenever clients try to look
> > up the clock by calling clk_get() or sister functions like clk_get_sys()
> > and of_clk_get(). This changes the original behavior where the struct
> > clk is only created for once when clock driver registers the clock to
> > CCF in the first place. The net change here is before commit
> > 035a61c314eb the struct clk pointer is unique for given hardware
> > clock, while after the commit the pointers returned by clk lookup calls
> > become different for the same hardware clock.
> >
> > A number of client drivers detecting if two struct clk pointers point to
> > the same one hardware clock by comparing the pointers are broken now.
> > As a stop-gap solution, this patch adds a helper function clk_is_match()
> > to test if two struct clk pointers point to the same hardware clock, so
> > that these client drivers can use to fix the regression.
> >
> > Signed-off-by: Shawn Guo
>
> Hi Shawn,
>
> Thanks for the patch. I wrote a similar one last night but did not
> finish fixing up the drivers (and thus did not post it). I prefer my
> implementation below, and I'm happy to merge your driver fixes with it.
>
> Regards,
> Mike
>
>
>
> From: Michael Turquette
> Date: Wed, 25 Feb 2015 09:11:01 -0800
> Subject: [PATCH] clk: introduce clk_is_match
>
> Some drivers compare struct clk pointers as a means of knowing
> if the two pointers reference the same clock hardware. This behavior is
> dubious (drivers must not dereference struct clk), but did not cause any
> regressions until the per-user struct clk patch was merged. Now the test
> for matching clk's will always fail with per-user struct clk's.
>
> clk_is_match is introduced to fix the regression and prevent drivers
> from comparing the pointers manually.
small observaton, clk_is_same() is linguistically nicer.
--
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
[PATCH v2 2/4] Use __sync_add_and_fetch instead of __sync_fetch_and_add for atomic_dec_and_test
Signed-off-by: Maarten Lankhorst
---
xf86atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xf86atomic.h b/xf86atomic.h
index 17fb088..194554c 100644
--- a/xf86atomic.h
+++ b/xf86atomic.h
@@ -50,7 +50,7 @@ typedef struct {
# define atomic_set(x, val) ((x)->atomic = (val))
# define atomic_inc(x) ((void) __sync_fetch_and_add (&(x)->atomic, 1))
# define atomic_inc_return(x) (__sync_add_and_fetch (&(x)->atomic, 1))
-# define atomic_dec_and_test(x) (__sync_fetch_and_add (&(x)->atomic, -1) == 1)
+# define atomic_dec_and_test(x) (__sync_add_and_fetch (&(x)->atomic, -1) == 0)
# define atomic_add(x, v) ((void) __sync_add_and_fetch(&(x)->atomic, (v)))
# define atomic_dec(x, v) ((void) __sync_sub_and_fetch(&(x)->atomic, (v)))
# define atomic_cmpxchg(x, oldv, newv) __sync_val_compare_and_swap
(&(x)->atomic, oldv, newv)
--
2.3.0
[PATCH v2 4/4] nouveau: Do not add most bo's to the global bo list.
Only add wrapped bo's and bo's that have been exported through flink or dma-buf.
This avoids a lock in the common case, and decreases traversal needed for
importing
a dma-buf or flink.
Signed-off-by: Maarten Lankhorst
---
nouveau/nouveau.c | 46 ++
1 file changed, 22 insertions(+), 24 deletions(-)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index 1c723b9..2d95b74 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@@ -349,8 +349,8 @@ nouveau_bo_del(struct nouveau_bo *bo)
struct nouveau_bo_priv *nvbo = nouveau_bo(bo);
struct drm_gem_close req = { bo->handle };
- pthread_mutex_lock(&nvdev->lock);
- if (nvbo->name) {
+ if (nvbo->head.next) {
+ pthread_mutex_lock(&nvdev->lock);
if (atomic_read(&nvbo->refcnt) == 0) {
DRMLISTDEL(&nvbo->head);
/*
@@ -365,8 +365,6 @@ nouveau_bo_del(struct nouveau_bo *bo)
}
pthread_mutex_unlock(&nvdev->lock);
} else {
- DRMLISTDEL(&nvbo->head);
- pthread_mutex_unlock(&nvdev->lock);
drmIoctl(bo->device->fd, DRM_IOCTL_GEM_CLOSE, &req);
}
if (bo->map)
@@ -379,7 +377,6 @@ nouveau_bo_new(struct nouveau_device *dev, uint32_t flags,
uint32_t align,
uint64_t size, union nouveau_bo_config *config,
struct nouveau_bo **pbo)
{
- struct nouveau_device_priv *nvdev = nouveau_device(dev);
struct nouveau_bo_priv *nvbo = calloc(1, sizeof(*nvbo));
struct nouveau_bo *bo = &nvbo->base;
int ret;
@@ -397,10 +394,6 @@ nouveau_bo_new(struct nouveau_device *dev, uint32_t flags,
uint32_t align,
return ret;
}
- pthread_mutex_lock(&nvdev->lock);
- DRMLISTADD(&nvbo->head, &nvdev->bo_list);
- pthread_mutex_unlock(&nvdev->lock);
-
*pbo = bo;
return 0;
}
@@ -457,6 +450,18 @@ nouveau_bo_wrap_locked(struct nouveau_device *dev,
uint32_t handle,
return -ENOMEM;
}
+static void
+nouveau_bo_make_global(struct nouveau_bo_priv *nvbo)
+{
+ if (!nvbo->head.next) {
+ struct nouveau_device_priv *nvdev =
nouveau_device(nvbo->base.device);
+ pthread_mutex_lock(&nvdev->lock);
+ if (!nvbo->head.next)
+ DRMLISTADD(&nvbo->head, &nvdev->bo_list);
+ pthread_mutex_unlock(&nvdev->lock);
+ }
+}
+
drm_public int
nouveau_bo_wrap(struct nouveau_device *dev, uint32_t handle,
struct nouveau_bo **pbo)
@@ -494,13 +499,16 @@ nouveau_bo_name_get(struct nouveau_bo *bo, uint32_t *name)
struct nouveau_bo_priv *nvbo = nouveau_bo(bo);
*name = nvbo->name;
- if (!*name || *name == ~0U) {
+ if (!*name) {
int ret = drmIoctl(bo->device->fd, DRM_IOCTL_GEM_FLINK, &req);
+
if (ret) {
*name = 0;
return ret;
}
nvbo->name = *name = req.name;
+
+ nouveau_bo_make_global(nvbo);
}
return 0;
}
@@ -533,16 +541,6 @@ nouveau_bo_prime_handle_ref(struct nouveau_device *dev,
int prime_fd,
ret = drmPrimeFDToHandle(dev->fd, prime_fd, &handle);
if (ret == 0) {
ret = nouveau_bo_wrap_locked(dev, handle, bo, 0);
- if (!ret) {
- struct nouveau_bo_priv *nvbo = nouveau_bo(*bo);
- if (!nvbo->name) {
- /*
-* XXX: Force locked DRM_IOCTL_GEM_CLOSE
-* to rule out race conditions
-*/
- nvbo->name = ~0;
- }
- }
}
pthread_mutex_unlock(&nvdev->lock);
return ret;
@@ -557,8 +555,8 @@ nouveau_bo_set_prime(struct nouveau_bo *bo, int *prime_fd)
ret = drmPrimeHandleToFD(bo->device->fd, nvbo->base.handle,
DRM_CLOEXEC, prime_fd);
if (ret)
return ret;
- if (!nvbo->name)
- nvbo->name = ~0;
+
+ nouveau_bo_make_global(nvbo);
return 0;
}
@@ -578,8 +576,8 @@ nouveau_bo_wait(struct nouveau_bo *bo, uint32_t access,
if (push && push->channel)
nouveau_pushbuf_kick(push, push->channel);
- if (!nvbo->name && !(nvbo->access & NOUVEAU_BO_WR) &&
- !( access & NOUVEAU_BO_WR))
+ if (!nvbo->head.next && !(nvbo->access & NOUVEAU_BO_WR) &&
+ !(access & NOUVEAU_BO_WR))
return 0;
req.handle = bo->handle;
--
2.3.0
[alsa-devel] [PATCH 1/8] clk: add helper function clk_is_match()
On Thu, Feb 26, 2015 at 10:56:58AM +0100, Philipp Zabel wrote: > Am Donnerstag, den 26.02.2015, 09:02 + schrieb Ben Dooks: > > On Wed, Feb 25, 2015 at 09:27:57AM -0800, Mike Turquette wrote: > [...] > > > From: Michael Turquette > > > Date: Wed, 25 Feb 2015 09:11:01 -0800 > > > Subject: [PATCH] clk: introduce clk_is_match > > > > > > Some drivers compare struct clk pointers as a means of knowing > > > if the two pointers reference the same clock hardware. This behavior is > > > dubious (drivers must not dereference struct clk), but did not cause any > > > regressions until the per-user struct clk patch was merged. Now the test > > > for matching clk's will always fail with per-user struct clk's. > > > > > > clk_is_match is introduced to fix the regression and prevent drivers > > > from comparing the pointers manually. > > > > small observaton, clk_is_same() is linguistically nicer. > > How about clk_equal() ? That's good, the only issue that's not clear in any of these names is that does this mean "the same clock", a "clock of the same rate" or a "clock that is equivalent to in the rate and phase but not subject to the same gate". -- Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear.
[alsa-devel] [PATCH 1/8] clk: add helper function clk_is_match()
On Thu, 26 Feb 2015, Ben Dooks wrote: > > > small observaton, clk_is_same() is linguistically nicer. > > > > How about clk_equal() ? > > That's good, the only issue that's not clear in any of these names is > that does this mean "the same clock", a "clock of the same rate" or a > "clock that is equivalent to in the rate and phase but not subject to > the same gate". clk_identical() ? /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Swedenwww.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30
[PATCH 00/21] drm/omap: misc fixes/improvements
Various small(ish) fixes and improvements for omapdrm. Laurent, some of these may conflict with your work. I'm fine with dropping the conflicting ones from this series, as long as the issue has been fixed in your WIP branch. Or maybe some of these should be rebased on top of your work. Tomi Tomi Valkeinen (21): drm/omap: fix encoder-crtc mapping drm/omap: page_flip: return -EBUSY if flip pending drm/omap: clear omap_obj->paddr in omap_gem_put_paddr() drm/omap: add pin refcounting to omap_framebuffer drm/omap: add a comment why locking is missing drm/omap: check CRTC color format earlier drm/omap: fix operation without fbdev drm/omap: fix error handling in omap_framebuffer_create() drm/omap: handle mismatching color format and buffer width drm/omap: fix TILER on OMAP5 drm/omap: fix plane's channel selection drm/omap: tiler: fix race condition with engine->async drm/omap: remove dummy PM functions drm/omap: stop connector polling during suspend drm/omap: use DRM_ERROR_RATELIMITED() for error irqs drm/omap: fix race with error_irq drm/omap: only ignore DIGIT SYNC LOST for TV output drm/omap: do not use BUG_ON(!spin_is_locked(x)) drm/omap: fix race condition with dev->obj_list drm/omap: fix race conditon in DMM drm/omap: keep ref to old_fb drivers/gpu/drm/omapdrm/omap_crtc.c | 44 +++ drivers/gpu/drm/omapdrm/omap_dmm_priv.h | 8 - drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 54 +++- drivers/gpu/drm/omapdrm/omap_dmm_tiler.h | 1 + drivers/gpu/drm/omapdrm/omap_drv.c | 60 +--- drivers/gpu/drm/omapdrm/omap_drv.h | 3 ++ drivers/gpu/drm/omapdrm/omap_fb.c| 26 -- drivers/gpu/drm/omapdrm/omap_gem.c | 10 -- drivers/gpu/drm/omapdrm/omap_irq.c | 2 +- drivers/gpu/drm/omapdrm/omap_plane.c | 28 +-- 10 files changed, 176 insertions(+), 60 deletions(-) -- 2.3.0
[PATCH 02/21] drm/omap: page_flip: return -EBUSY if flip pending
The DRM documentation says:
"If a page flip is already pending, the page_flip operation must return
-EBUSY."
Currently omapdrm returns -EINVAL instead. Fix omapdrm by returning
-EBUSY.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index b0566a1ca28f..af4b230b5269 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -361,7 +361,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc *crtc,
if (omap_crtc->old_fb) {
spin_unlock_irqrestore(&dev->event_lock, flags);
dev_err(dev->dev, "already a pending flip\n");
- return -EINVAL;
+ return -EBUSY;
}
omap_crtc->event = event;
--
2.3.0
[PATCH 03/21] drm/omap: clear omap_obj->paddr in omap_gem_put_paddr()
Clear omap_obj's paddr when unmapping the memory, so that it's easier to catch bad use of the paddr. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_gem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c index aeb91ed653c9..9b250c93b046 100644 --- a/drivers/gpu/drm/omapdrm/omap_gem.c +++ b/drivers/gpu/drm/omapdrm/omap_gem.c @@ -828,6 +828,7 @@ int omap_gem_put_paddr(struct drm_gem_object *obj) dev_err(obj->dev->dev, "could not release unmap: %d\n", ret); } + omap_obj->paddr = 0; omap_obj->block = NULL; } } -- 2.3.0
[PATCH 04/21] drm/omap: add pin refcounting to omap_framebuffer
omap_framebuffer_pin() and omap_framebuffer_unpin() are currently
broken, as they cannot be called multiple times (i.e. pin, pin, unpin,
unpin), which is what happens in certain cases. This issue causes the
driver to possibly use 0 as an address for a displayed buffer, leading
to OCP error from DSS.
This patch fixes the issue by adding a simple pin_count, used to track
the number of pins.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fb.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 2a5cacdc344b..58f2af32ede8 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -86,6 +86,7 @@ struct plane {
struct omap_framebuffer {
struct drm_framebuffer base;
+ int pin_count;
const struct format *format;
struct plane planes[4];
};
@@ -261,6 +262,11 @@ int omap_framebuffer_pin(struct drm_framebuffer *fb)
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
int ret, i, n = drm_format_num_planes(fb->pixel_format);
+ if (omap_fb->pin_count > 0) {
+ omap_fb->pin_count++;
+ return 0;
+ }
+
for (i = 0; i < n; i++) {
struct plane *plane = &omap_fb->planes[i];
ret = omap_gem_get_paddr(plane->bo, &plane->paddr, true);
@@ -269,6 +275,8 @@ int omap_framebuffer_pin(struct drm_framebuffer *fb)
omap_gem_dma_sync(plane->bo, DMA_TO_DEVICE);
}
+ omap_fb->pin_count++;
+
return 0;
fail:
@@ -287,6 +295,11 @@ int omap_framebuffer_unpin(struct drm_framebuffer *fb)
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
int ret, i, n = drm_format_num_planes(fb->pixel_format);
+ omap_fb->pin_count--;
+
+ if (omap_fb->pin_count > 0)
+ return 0;
+
for (i = 0; i < n; i++) {
struct plane *plane = &omap_fb->planes[i];
ret = omap_gem_put_paddr(plane->bo);
--
2.3.0
[PATCH 06/21] drm/omap: check CRTC color format earlier
When setting a color format to a DRM plane, the DRM core checks whether
the format is supported by the HW. However, it seems that when setting
the color format of a CRTC (i.e. a root plane), there's no checking
done. This causes omapdrm to configure omapdss with the bad color
format, which omapdss then rejects.
While the above is ok, the error message is a bit confusing, and the
configuring of omapdss happens asynchronously from the ioctl that does
the color format change.
This patch adds a color format check to omap_plane_mode_set() which
causes the ioctl to return an error for invalid color format. This means
that the userspace will get to know of the wrong setting, instead of the
current behavior where the error is not seen by the userspace.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_plane.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 1f4f2b866379..bedd6f7af0f1 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -207,6 +207,24 @@ int omap_plane_mode_set(struct drm_plane *plane,
{
struct omap_plane *omap_plane = to_omap_plane(plane);
struct omap_drm_window *win = &omap_plane->win;
+ int i;
+
+ /*
+* Check whether this plane supports the fb pixel format.
+* I don't think this should really be needed, but it looks like the
+* drm core only checks the format for planes, not for the crtc. So
+* when setting the format for crtc, without this check we would
+* get an error later when trying to program the color format into the
+* HW.
+*/
+ for (i = 0; i < plane->format_count; i++)
+ if (fb->pixel_format == plane->format_types[i])
+ break;
+ if (i == plane->format_count) {
+ DBG("Invalid pixel format %s",
+ drm_get_format_name(fb->pixel_format));
+ return -EINVAL;
+ }
win->crtc_x = crtc_x;
win->crtc_y = crtc_y;
--
2.3.0
[PATCH 08/21] drm/omap: fix error handling in omap_framebuffer_create()
When an error happens in omap_framebuffer_create(),
omap_framebuffer_create() calls omap_framebuffer_destroy() if the fb
struct has been allocated. However, that crashes, as
omap_framebuffer_destroy(), which calls drm_framebuffer_cleanup(),
should only be called after drm_framebuffer_init()
Fix this by just calling kfree() for the allocated fb when an error
happens.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fb.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 58f2af32ede8..2975096abdf5 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -420,7 +420,7 @@ struct drm_framebuffer *omap_framebuffer_create(struct
drm_device *dev,
struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos)
{
- struct omap_framebuffer *omap_fb;
+ struct omap_framebuffer *omap_fb = NULL;
struct drm_framebuffer *fb = NULL;
const struct format *format = NULL;
int ret, i, n = drm_format_num_planes(mode_cmd->pixel_format);
@@ -491,8 +491,7 @@ struct drm_framebuffer *omap_framebuffer_init(struct
drm_device *dev,
return fb;
fail:
- if (fb)
- omap_framebuffer_destroy(fb);
+ kfree(omap_fb);
return ERR_PTR(ret);
}
--
2.3.0
[PATCH 10/21] drm/omap: fix TILER on OMAP5
On OMAP5 it is not possible to use TILER buffer with CPU when caching or
write-combining is used. Doing so leads to errors from the memory
manager.
However, on OMAP4, write-combining works fine.
This patch adds platform specific data for the TILER, and a function
tiler_get_cpu_cache_flags() which can be used to get the caching mode to
be used.
Note that without write-combining the use of the TILER buffer with CPU
is unusably slow. It's still good to have it operational for testing
purposes.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_dmm_priv.h | 6 +
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 39 ++--
drivers/gpu/drm/omapdrm/omap_dmm_tiler.h | 1 +
drivers/gpu/drm/omapdrm/omap_gem.c | 4 ++--
4 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
index 58bcd6ae0255..d96660573076 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
@@ -153,6 +153,10 @@ struct refill_engine {
struct list_head idle_node;
};
+struct dmm_platform_data {
+ uint32_t cpu_cache_flags;
+};
+
struct dmm {
struct device *dev;
void __iomem *base;
@@ -183,6 +187,8 @@ struct dmm {
/* allocation list and lock */
struct list_head alloc_head;
+
+ const struct dmm_platform_data *plat_data;
};
#endif
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 56c60552abba..ef3d14d9cfa1 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -39,6 +39,10 @@
static struct tcm *containers[TILFMT_NFORMATS];
static struct dmm *omap_dmm;
+#if defined(CONFIG_OF)
+static const struct of_device_id dmm_of_match[];
+#endif
+
/* global spinlock for protecting lists */
static DEFINE_SPINLOCK(list_lock);
@@ -529,6 +533,11 @@ size_t tiler_vsize(enum tiler_fmt fmt, uint16_t w,
uint16_t h)
return round_up(geom[fmt].cpp * w, PAGE_SIZE) * h;
}
+uint32_t tiler_get_cpu_cache_flags(void)
+{
+ return omap_dmm->plat_data->cpu_cache_flags;
+}
+
bool dmm_is_available(void)
{
return omap_dmm ? true : false;
@@ -592,6 +601,18 @@ static int omap_dmm_probe(struct platform_device *dev)
init_waitqueue_head(&omap_dmm->engine_queue);
+ if (dev->dev.of_node) {
+ const struct of_device_id *match;
+
+ match = of_match_node(dmm_of_match, dev->dev.of_node);
+ if (!match) {
+ dev_err(&dev->dev, "failed to find matching device
node\n");
+ return -ENODEV;
+ }
+
+ omap_dmm->plat_data = match->data;
+ }
+
/* lookup hwmod data - base address and irq */
mem = platform_get_resource(dev, IORESOURCE_MEM, 0);
if (!mem) {
@@ -972,9 +993,23 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
#endif
#if defined(CONFIG_OF)
+static const struct dmm_platform_data dmm_omap4_platform_data = {
+ .cpu_cache_flags = OMAP_BO_WC,
+};
+
+static const struct dmm_platform_data dmm_omap5_platform_data = {
+ .cpu_cache_flags = OMAP_BO_UNCACHED,
+};
+
static const struct of_device_id dmm_of_match[] = {
- { .compatible = "ti,omap4-dmm", },
- { .compatible = "ti,omap5-dmm", },
+ {
+ .compatible = "ti,omap4-dmm",
+ .data = &dmm_omap4_platform_data,
+ },
+ {
+ .compatible = "ti,omap5-dmm",
+ .data = &dmm_omap5_platform_data,
+ },
{},
};
#endif
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
index 4fdd61e54bd2..e83c78372db8 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h
@@ -106,6 +106,7 @@ uint32_t tiler_stride(enum tiler_fmt fmt, uint32_t orient);
size_t tiler_size(enum tiler_fmt fmt, uint16_t w, uint16_t h);
size_t tiler_vsize(enum tiler_fmt fmt, uint16_t w, uint16_t h);
void tiler_align(enum tiler_fmt fmt, uint16_t *w, uint16_t *h);
+uint32_t tiler_get_cpu_cache_flags(void);
bool dmm_is_available(void);
extern struct platform_driver omap_dmm_driver;
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 9b250c93b046..d37ee756a0b1 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1359,8 +1359,8 @@ struct drm_gem_object *omap_gem_new(struct drm_device
*dev,
/* currently don't allow cached buffers.. there is some caching
* stuff that needs to be handled better
*/
- flags &= ~(OMAP_BO_CACHED|OMAP_BO_UNCACHED);
- flags |= OMAP_BO_WC;
+ flags &= ~(OMAP_BO_CACHED|OMAP_BO_WC|OMAP_BO_UNCACHED);
+ flags |= tiler_get_cpu_cache_flags();
/* align dimensions t
[PATCH 12/21] drm/omap: tiler: fix race condition with engine->async
The tiler irq handler uses engine->async value, but the code that sets engine->async and enables the interrupt does not have a barrier. This may cause the irq handler to see the old value of engine->async, causing memory corruption. Reported-by: Harinarayan Bhatta Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c index ef3d14d9cfa1..c4563af55a82 100644 --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c @@ -273,6 +273,8 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait) /* mark whether it is async to denote list management in IRQ handler */ engine->async = wait ? false : true; + /* verify that the irq handler sees the 'async' value */ + smp_mb(); /* kick reload */ writel(engine->refill_pa, -- 2.3.0
[PATCH 14/21] drm/omap: stop connector polling during suspend
When not using proper hotplug detection, DRM polls periodically the
connectors to find out if a cable is connected. This polling can happen
at any time, even very late in the suspend process.
This causes a problem with omapdrm, when the poll happens during the
suspend process after GPIOs have been disabled, leading to a crash in
gpio_get().
This patch fixes the issue by adding suspend and resume hooks to
omapdrm, in which we disable and enable, respectively, the polling.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 0ebd1315fff8..d0b1aece8cc5 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -694,9 +694,28 @@ static int pdev_remove(struct platform_device *device)
return 0;
}
+static int omap_drm_suspend(struct device *dev)
+{
+ struct drm_device *drm_dev = dev_get_drvdata(dev);
+
+ drm_kms_helper_poll_disable(drm_dev);
+
+ return 0;
+}
+
+static int omap_drm_resume(struct device *dev)
+{
+ struct drm_device *drm_dev = dev_get_drvdata(dev);
+
+ drm_kms_helper_poll_enable(drm_dev);
+
+ return omap_gem_resume(dev);
+}
+
#ifdef CONFIG_PM
static const struct dev_pm_ops omapdrm_pm_ops = {
- .resume = omap_gem_resume,
+ .suspend = omap_drm_suspend,
+ .resume = omap_drm_resume,
};
#endif
--
2.3.0
[PATCH 15/21] drm/omap: use DRM_ERROR_RATELIMITED() for error irqs
omapdrm uses normal DRM_ERROR() print when the HW reports an error. As
we sometimes may get a flood of errors, let's rather use
DRM_ERROR_RATELIMITED().
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +-
drivers/gpu/drm/omapdrm/omap_plane.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index af4b230b5269..832fb9e38612 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -429,7 +429,7 @@ static void omap_crtc_error_irq(struct omap_drm_irq *irq,
uint32_t irqstatus)
struct omap_crtc *omap_crtc =
container_of(irq, struct omap_crtc, error_irq);
struct drm_crtc *crtc = &omap_crtc->base;
- DRM_ERROR("%s: errors: %08x\n", omap_crtc->name, irqstatus);
+ DRM_ERROR_RATELIMITED("%s: errors: %08x\n", omap_crtc->name, irqstatus);
/* avoid getting in a flood, unregister the irq until next vblank */
__omap_irq_unregister(crtc->dev, &omap_crtc->error_irq);
}
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 8e94694ba8a3..dc666f6b2bf8 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -386,7 +386,8 @@ static void omap_plane_error_irq(struct omap_drm_irq *irq,
uint32_t irqstatus)
{
struct omap_plane *omap_plane =
container_of(irq, struct omap_plane, error_irq);
- DRM_ERROR("%s: errors: %08x\n", omap_plane->name, irqstatus);
+ DRM_ERROR_RATELIMITED("%s: errors: %08x\n", omap_plane->name,
+ irqstatus);
}
static const char *plane_names[] = {
--
2.3.0
[PATCH 16/21] drm/omap: fix race with error_irq
omapdrm tries to avoid error floods by unregistering the error irq when
an error happens, and then registering the error irq again later.
However, the code is racy, as it sometimes tries to unregister the error
irq when it's already unregistered, leading to WARN().
Also, the code only registers the error irq again when something is done
on that particular output, i.e. if only TV is used to flip the buffers,
and LCD is showing a same buffer, an error on LCD will cause the LCD
error irq to be unregistered and never registered again.
To fix this, let's keep the error irqs always enabled and trust the
DRM_ERROR_RATELIMITED to limit the flood.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 832fb9e38612..2175b9b7c725 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -74,6 +74,8 @@ struct omap_crtc {
* XXX maybe fold into apply_work??
*/
struct work_struct page_flip_work;
+
+ bool ignore_digit_sync_lost;
};
uint32_t pipe2vbl(struct drm_crtc *crtc)
@@ -428,10 +430,14 @@ static void omap_crtc_error_irq(struct omap_drm_irq *irq,
uint32_t irqstatus)
{
struct omap_crtc *omap_crtc =
container_of(irq, struct omap_crtc, error_irq);
- struct drm_crtc *crtc = &omap_crtc->base;
+
+ if (omap_crtc->ignore_digit_sync_lost) {
+ irqstatus &= ~DISPC_IRQ_SYNC_LOST_DIGIT;
+ if (!irqstatus)
+ return;
+ }
+
DRM_ERROR_RATELIMITED("%s: errors: %08x\n", omap_crtc->name, irqstatus);
- /* avoid getting in a flood, unregister the irq until next vblank */
- __omap_irq_unregister(crtc->dev, &omap_crtc->error_irq);
}
static void omap_crtc_apply_irq(struct omap_drm_irq *irq, uint32_t irqstatus)
@@ -440,9 +446,6 @@ static void omap_crtc_apply_irq(struct omap_drm_irq *irq,
uint32_t irqstatus)
container_of(irq, struct omap_crtc, apply_irq);
struct drm_crtc *crtc = &omap_crtc->base;
- if (!omap_crtc->error_irq.registered)
- __omap_irq_register(crtc->dev, &omap_crtc->error_irq);
-
if (!dispc_mgr_go_busy(omap_crtc->channel)) {
struct omap_drm_private *priv =
crtc->dev->dev_private;
@@ -558,7 +561,7 @@ static void set_enabled(struct drm_crtc *crtc, bool enable)
* Digit output produces some sync lost interrupts during the first
* frame when enabling, so we need to ignore those.
*/
- omap_irq_unregister(crtc->dev, &omap_crtc->error_irq);
+ omap_crtc->ignore_digit_sync_lost = true;
framedone_irq = dispc_mgr_get_framedone_irq(channel);
vsync_irq = dispc_mgr_get_vsync_irq(channel);
@@ -589,7 +592,9 @@ static void set_enabled(struct drm_crtc *crtc, bool enable)
omap_crtc->name, enable ? "enable" : "disable");
}
- omap_irq_register(crtc->dev, &omap_crtc->error_irq);
+ omap_crtc->ignore_digit_sync_lost = false;
+ /* make sure the irq handler sees the value above */
+ mb();
}
static void omap_crtc_pre_apply(struct omap_drm_apply *apply)
--
2.3.0
[PATCH 19/21] drm/omap: fix race condition with dev->obj_list
omap_gem_objects are added to dev->obj_list in omap_gem_new, and removed
in omap_gem_free_object. Unfortunately there's no locking for
dev->obj_list, which eventually leads to a crash:
WARNING: CPU: 1 PID: 1123 at lib/list_debug.c:59 __list_del_entry+0xa4/0xe0()
list_del corruption. prev->next should be e9281344, but was ea722b84
Add a spinlock to protect dev->obj_list.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c | 1 +
drivers/gpu/drm/omapdrm/omap_drv.h | 3 +++
drivers/gpu/drm/omapdrm/omap_gem.c | 5 +
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index d0b1aece8cc5..2a85221e0604 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -479,6 +479,7 @@ static int dev_load(struct drm_device *dev, unsigned long
flags)
priv->wq = alloc_ordered_workqueue("omapdrm", 0);
+ spin_lock_init(&priv->list_lock);
INIT_LIST_HEAD(&priv->obj_list);
omap_gem_init(dev);
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 60e47b33c801..dac9f8ef3b15 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -105,6 +105,9 @@ struct omap_drm_private {
struct workqueue_struct *wq;
+ /* lock for obj_list below */
+ spinlock_t list_lock;
+
/* list of GEM objects: */
struct list_head obj_list;
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index d37ee756a0b1..e9718b99a8a9 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1273,13 +1273,16 @@ unlock:
void omap_gem_free_object(struct drm_gem_object *obj)
{
struct drm_device *dev = obj->dev;
+ struct omap_drm_private *priv = dev->dev_private;
struct omap_gem_object *omap_obj = to_omap_bo(obj);
evict(obj);
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
+ spin_lock(&priv->list_lock);
list_del(&omap_obj->mm_list);
+ spin_unlock(&priv->list_lock);
drm_gem_free_mmap_offset(obj);
@@ -1377,7 +1380,9 @@ struct drm_gem_object *omap_gem_new(struct drm_device
*dev,
if (!omap_obj)
goto fail;
+ spin_lock(&priv->list_lock);
list_add(&omap_obj->mm_list, &priv->obj_list);
+ spin_unlock(&priv->list_lock);
obj = &omap_obj->base;
--
2.3.0
