[PULL] drm-amdkfd-next
> >> drm-amdkfd-next-2015-05-18: >> >> - Add the interrupts & events modules, including new IOCTLs to create and >> wait >> on events. The HSA RT open source stack is mainly using events to know >> when >> a dispatched work has been completed. In addition, this module is >> a pre-requisite for the next module I'm going to upstream - debugger >> support >> >> This module also handles H/W exceptions, such as memory exception >> received >> through the IOMMUv2 H/W and Bad Opcode exception receieved from the GPU. >> >> - Adding a new kernel module parameter to let the user decide whether he >> wants >> to receive a SIGTERM when a memory exception occurs inside the GPU >> kernel and >> the HSA application doesn't wait on an appropriate event, or if he just >> want >> to receive notification about this event in dmesg. The default is the >> latter. >> >> - Additional improvements for SDMA code >> >> - Update my email address in Maintainers file as I'm leaving AMD in two >> weeks. >> > Two things, a) pull request from ssh:// please fix scripts to generate git:// URLs, b) ioctls with bool in them make me worry, four packed bool's even more, 4 packed bools with a 64-bit straight after them put me over the not pulling this edge. I don't trust bools in ioctl defintions, please use explicitly sized types. Dave. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/1d0c056f/attachment.html>
[Bug 90481] Radeon R9 270X gpu lockup in game spec ops: the line.
https://bugs.freedesktop.org/show_bug.cgi?id=90481 Michel Dänzer changed: What|Removed |Added Component|DRM/Radeon |Drivers/Gallium/radeonsi Version|unspecified |10.5 Product|DRI |Mesa QA Contact||dri-devel at lists.freedesktop ||.org -- 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/20150519/1544a560/attachment-0001.html>
[Bug 90484] LLVM >=r237140 causes gpu lockups Spec Ops: The Line
https://bugs.freedesktop.org/show_bug.cgi?id=90484 --- Comment #6 from Michel Dänzer --- (In reply to Arek RuÅniak from comment #5) > r237139 is affected too, but need more time(about 100-120 sec)to trigger, > this is why i didn't see it before. Now i've tried r230876 and time to > trigger ~ 11 min. The hangs before r237140 might simply be random, and might have been there for a long time if not forever. See e.g. bug 90481. -- 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/20150519/87e179f5/attachment.html>
[PATCH] drm/exynos: dp: Lower level of EDID read success message
> Don't pollute the dmesg with EDID read success message as an error. > Printing as debug should be fine. > > Signed-off-by: Krzysztof Kozlowski Right, dev_err() is not right. Thank you for sending the patch. Acked-by: Jingoo Han Best regards, Jingoo Han > --- > drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c > b/drivers/gpu/drm/exynos/exynos_dp_core.c > index 441ef06b8894..30feb7d06624 100644 > --- a/drivers/gpu/drm/exynos/exynos_dp_core.c > +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c > @@ -195,7 +195,7 @@ static int exynos_dp_read_edid(struct exynos_dp_device > *dp) > } > } > > - dev_err(dp->dev, "EDID Read success!\n"); > + dev_dbg(dp->dev, "EDID Read success!\n"); > return 0; > } > > -- > 1.9.1
[Bug 90320] Lenovo ThinkPad E455 (Kaveri A10-7300): Blank built-in screen with radeon kms driver
https://bugs.freedesktop.org/show_bug.cgi?id=90320 --- Comment #12 from Samir IbradžiÄ --- (In reply to Alex Deucher from comment #11) > Created attachment 115885 [details] [review] > possible fix > > Does this patch help? Unfortunately no, same symptoms. -- 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/20150519/fd8d5605/attachment.html>
[PATCH] drm/radeon: take the mode_config mutex when dealing with hpds
On 19.05.2015 01:24, Alex Deucher wrote: > > @@ -96,10 +98,12 @@ static void radeon_dp_work_func(struct work_struct *work) > struct drm_connector *connector; > > /* this should take a mutex */ > + mutex_lock(&mode_config->mutex); This comment can be removed? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH] drm/radeon: take the mode_config mutex when dealing with hpds
On 19 May 2015 at 12:27, Michel Dänzer wrote: > On 19.05.2015 01:24, Alex Deucher wrote: >> >> @@ -96,10 +98,12 @@ static void radeon_dp_work_func(struct work_struct *work) >> struct drm_connector *connector; >> >> /* this should take a mutex */ >> + mutex_lock(&mode_config->mutex); > > This comment can be removed? I have vague memories of not doing this, because bad things happened. so keep an eye out for lockdep traces. Dave.
[PULL] drm-amdkfd-next
On May 19, 2015 3:16 AM, "Dave Airlie" wrote: > > >>> >>> drm-amdkfd-next-2015-05-18: >>> >>> - Add the interrupts & events modules, including new IOCTLs to create and wait >>> on events. The HSA RT open source stack is mainly using events to know when >>> a dispatched work has been completed. In addition, this module is >>> a pre-requisite for the next module I'm going to upstream - debugger support >>> >>> This module also handles H/W exceptions, such as memory exception received >>> through the IOMMUv2 H/W and Bad Opcode exception receieved from the GPU. >>> >>> - Adding a new kernel module parameter to let the user decide whether he wants >>> to receive a SIGTERM when a memory exception occurs inside the GPU kernel and >>> the HSA application doesn't wait on an appropriate event, or if he just want >>> to receive notification about this event in dmesg. The default is the latter. >>> >>> - Additional improvements for SDMA code >>> >>> - Update my email address in Maintainers file as I'm leaving AMD in two weeks. > > > Two things, > > a) pull request from ssh:// please fix scripts to generate git:// URLs, > > b) ioctls with bool in them make me worry, four packed bool's even more, > 4 packed bools with a 64-bit straight after them put me over the not pulling this edge. > > I don't trust bools in ioctl defintions, please use explicitly sized types. > > Dave. Thanks Dave, No problem, I'll fix and resend it today. Oded -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/69a311fc/attachment.html>
radeon: ring 0 stalled for more than 10480msec
May 18 21:38:55 arcadia kernel: [0.00] Linux version 4.0.0-1-amd64 (debian-kernel at lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11) May 18 21:38:55 arcadia kernel: [3.467818] [drm] radeon/VERDE_mc2.bin: 31500 bytes May 19 00:06:08 arcadia kernel: [ 6226.594929] radeon :01:00.0: ring 0 stalled for more than 10480msec May 19 00:06:08 arcadia kernel: [ 6226.594938] radeon :01:00.0: GPU lockup (current fence id 0x0003dc60 last fence id 0x0003dc7c on ring 0) May 19 00:06:09 arcadia kernel: [ 6227.126990] radeon :01:00.0: Saved 1185 dwords of commands on ring 0. May 19 00:06:09 arcadia kernel: [ 6227.127068] radeon :01:00.0: GPU softreset: 0x004D May 19 00:06:09 arcadia kernel: [ 6227.127072] radeon :01:00.0: GRBM_STATUS = 0xA25E7028 May 19 00:06:09 arcadia kernel: [ 6227.127076] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0F86 May 19 00:06:09 arcadia kernel: [ 6227.127080] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0006 May 19 00:06:09 arcadia kernel: [ 6227.127083] radeon :01:00.0: SRBM_STATUS = 0x200400C0 May 19 00:06:09 arcadia kernel: [ 6227.127141] radeon :01:00.0: SRBM_STATUS2 = 0x May 19 00:06:09 arcadia kernel: [ 6227.127144] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x May 19 00:06:09 arcadia kernel: [ 6227.127147] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x00010800 May 19 00:06:09 arcadia kernel: [ 6227.127150] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x00408006 May 19 00:06:09 arcadia kernel: [ 6227.127154] radeon :01:00.0: R_008680_CP_STAT = 0x84038647 May 19 00:06:09 arcadia kernel: [ 6227.127157] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44483146 May 19 00:06:09 arcadia kernel: [ 6227.127160] radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 May 19 00:06:09 arcadia kernel: [ 6227.127163] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x May 19 00:06:09 arcadia kernel: [ 6227.127167] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x May 19 00:06:09 arcadia kernel: [ 6227.637461] radeon :01:00.0: GRBM_SOFT_RESET=0xDDFF May 19 00:06:09 arcadia kernel: [ 6227.637520] radeon :01:00.0: SRBM_SOFT_RESET=0x00100100 May 19 00:06:09 arcadia kernel: [ 6227.638671] radeon :01:00.0: GRBM_STATUS = 0x80007028 May 19 00:06:09 arcadia kernel: [ 6227.638675] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0206 May 19 00:06:09 arcadia kernel: [ 6227.638679] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0006 May 19 00:06:09 arcadia kernel: [ 6227.638682] radeon :01:00.0: SRBM_STATUS = 0x200400C0 May 19 00:06:09 arcadia kernel: [ 6227.638740] radeon :01:00.0: SRBM_STATUS2 = 0x May 19 00:06:09 arcadia kernel: [ 6227.638744] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x May 19 00:06:09 arcadia kernel: [ 6227.638747] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x May 19 00:06:09 arcadia kernel: [ 6227.638750] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x May 19 00:06:09 arcadia kernel: [ 6227.638753] radeon :01:00.0: R_008680_CP_STAT = 0x May 19 00:06:09 arcadia kernel: [ 6227.638756] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 May 19 00:06:09 arcadia kernel: [ 6227.638759] radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 May 19 00:06:09 arcadia kernel: [ 6227.638890] radeon :01:00.0: GPU reset succeeded, trying to resume May 19 00:06:09 arcadia kernel: [ 6227.670575] [drm] probing gen 2 caps for device 1022:1425 = 733d03/e May 19 00:06:09 arcadia kernel: [ 6227.670580] [drm] PCIE gen 3 link speeds already enabled May 19 00:06:09 arcadia kernel: [ 6227.673508] [drm] PCIE GART of 1024M enabled (table at 0x00277000). May 19 00:06:09 arcadia kernel: [ 6227.673631] radeon :01:00.0: WB enabled May 19 00:06:09 arcadia kernel: [ 6227.673634] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x88040a4ffc00 May 19 00:06:09 arcadia kernel: [ 6227.673636] radeon :01:00.0: fence driver on ring 1 use gpu addr 0x8c04 and cpu addr 0x88040a4ffc04 May 19 00:06:09 arcadia kernel: [ 6227.673638] radeon :01:00.0: fence driver on ring 2 use gpu addr 0x8c08 and cpu addr 0x88040a4ffc08 May 19 00:06:09 arcadia kernel: [ 6227.673639] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c and cpu addr 0x88040a4ffc0c May 19 00:06:09 arcadia kernel: [ 6227.673641] radeon :01:00.0: fence driver on ring 4 use gpu addr 0x8c10 and cpu addr 0x88040a4ffc10 May 19 00:06:09 arcadia kernel: [ 6227.674040] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xc90005f35a18 May 19 00:06:09 arcadia kernel: [ 6227.841114] [drm] ring tes
[PATCH] drm/bridge: use flags argument of devm_gpiod_get to set direction
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Use this to simplify the driver. Furthermore this is one caller less
that stops us making the flags argument to gpiod_get*() mandatory.
Fixes: b2ea8772799d ("drm/bridge: Add I2C based driver for ps8622/ps8625
bridge")
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/bridge/ps8622.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
index e895aa7ea353..9534607cbd10 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -581,31 +581,21 @@ static int ps8622_probe(struct i2c_client *client,
ps8622->v12 = NULL;
}
- ps8622->gpio_slp = devm_gpiod_get(dev, "sleep");
+ ps8622->gpio_slp = devm_gpiod_get(dev, "sleep", GPIOD_OUT_HIGH);
if (IS_ERR(ps8622->gpio_slp)) {
ret = PTR_ERR(ps8622->gpio_slp);
dev_err(dev, "cannot get gpio_slp %d\n", ret);
return ret;
}
- ret = gpiod_direction_output(ps8622->gpio_slp, 1);
- if (ret) {
- dev_err(dev, "cannot configure gpio_slp\n");
- return ret;
- }
- ps8622->gpio_rst = devm_gpiod_get(dev, "reset");
- if (IS_ERR(ps8622->gpio_rst)) {
- ret = PTR_ERR(ps8622->gpio_rst);
- dev_err(dev, "cannot get gpio_rst %d\n", ret);
- return ret;
- }
/*
* Assert the reset pin high to avoid the bridge being
* initialized prematurely
*/
- ret = gpiod_direction_output(ps8622->gpio_rst, 1);
- if (ret) {
- dev_err(dev, "cannot configure gpio_rst\n");
+ ps8622->gpio_rst = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(ps8622->gpio_rst)) {
+ ret = PTR_ERR(ps8622->gpio_rst);
+ dev_err(dev, "cannot get gpio_rst %d\n", ret);
return ret;
}
--
2.1.4
[PATCH] drm/bridge: use flags argument of devm_gpiod_get to set direction
Hello, the subject is missing "ps8622" before the :. Should I resend for that? On Tue, May 19, 2015 at 09:03:49AM +0200, Uwe Kleine-König wrote: > drivers/gpu/drm/bridge/ps8622.c | 20 +--- > 1 file changed, 5 insertions(+), 15 deletions(-) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH] drm/bridge/ptn3460: use flags argument of devm_gpiod_get to set direction
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Use this to simplify the driver. Furthermore this is one caller less
that stops us making the flags argument to gpiod_get*() mandatory.
Fixes: af478d8823a7 ("drm/bridge: ptn3460: use gpiod interface")
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/bridge/ptn3460.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 9d2f053382e1..c70abbe166b6 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -330,32 +330,23 @@ static int ptn3460_probe(struct i2c_client *client,
ptn_bridge->client = client;
- ptn_bridge->gpio_pd_n = devm_gpiod_get(&client->dev, "powerdown");
+ ptn_bridge->gpio_pd_n = devm_gpiod_get(&client->dev, "powerdown",
+ GPIOD_OUT_HIGH);
if (IS_ERR(ptn_bridge->gpio_pd_n)) {
ret = PTR_ERR(ptn_bridge->gpio_pd_n);
dev_err(dev, "cannot get gpio_pd_n %d\n", ret);
return ret;
}
- ret = gpiod_direction_output(ptn_bridge->gpio_pd_n, 1);
- if (ret) {
- DRM_ERROR("cannot configure gpio_pd_n\n");
- return ret;
- }
-
- ptn_bridge->gpio_rst_n = devm_gpiod_get(&client->dev, "reset");
- if (IS_ERR(ptn_bridge->gpio_rst_n)) {
- ret = PTR_ERR(ptn_bridge->gpio_rst_n);
- DRM_ERROR("cannot get gpio_rst_n %d\n", ret);
- return ret;
- }
/*
* Request the reset pin low to avoid the bridge being
* initialized prematurely
*/
- ret = gpiod_direction_output(ptn_bridge->gpio_rst_n, 0);
- if (ret) {
- DRM_ERROR("cannot configure gpio_rst_n\n");
+ ptn_bridge->gpio_rst_n = devm_gpiod_get(&client->dev, "reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(ptn_bridge->gpio_rst_n)) {
+ ret = PTR_ERR(ptn_bridge->gpio_rst_n);
+ DRM_ERROR("cannot get gpio_rst_n %d\n", ret);
return ret;
}
--
2.1.4
[PATCH v2] drm/i915: fix screen flickering
On Thu, 14 May 2015, Matt Roper wrote:
> On Thu, May 14, 2015 at 09:16:39AM +0200, Thomas Gummerer wrote:
>> Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
>> always on for wm calculation (v4)") fixes a null pointer dereference.
>> Setting the primary and cursor panes to false in
>> ilk_compute_wm_parameters to false does however give the following
>> errors in the kernel log and causes the screen to flicker.
>>
>> [ 101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]]
>> *ERROR* uncleared fifo underrun on pipe A
>> [ 101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
>> *ERROR* CPU pipe A FIFO underrun
>>
>> Always setting the panes to enabled fixes this error.
>>
>> Helped-by: Matt Roper
>> Signed-off-by: Thomas Gummerer
>
> Seems like a reasonable short-term workaround and returns us to how the
> code used to behaves.
>
> Reviewed-by: Matt Roper
Pushed to drm-intel-fixes, thanks for the patch and review.
BR,
Jani.
>
>> ---
>>
>> > Sorry, I missed your patch when you first sent it. That type of fix
>> > looks like an okay workaround while we do a more in-depth rework of the
>> > watermark system. However I think your patch could cause a crash if we
>> > disable the primary plane via the universal plane interface; if we do
>> > that, p->pri.bytes_per_pixel is set to 0, but since we're now pretending
>> > the primary plane is always enabled, ilk_wm_fbc() can eventually get
>> > called and use that 0 in the denominator of a division operation.
>> >
>> > If you just squash the following change into your patch, I think it should
>> > be
>> > safe:
>> > [...]
>>
>> Thank you very much for the suggestion, here is an updated version of the
>> patch.
>>
>> drivers/gpu/drm/i915/intel_pm.c | 24 +++-
>> 1 file changed, 11 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index fa4ccb3..555b896 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -2045,22 +2045,20 @@ static void ilk_compute_wm_parameters(struct
>> drm_crtc *crtc,
>> p->pipe_htotal = intel_crtc->config->base.adjusted_mode.crtc_htotal;
>> p->pixel_rate = ilk_pipe_pixel_rate(dev, crtc);
>>
>> -if (crtc->primary->state->fb) {
>> -p->pri.enabled = true;
>> +if (crtc->primary->state->fb)
>> p->pri.bytes_per_pixel =
>> crtc->primary->state->fb->bits_per_pixel / 8;
>> -} else {
>> -p->pri.enabled = false;
>> -p->pri.bytes_per_pixel = 0;
>> -}
>> +else
>> +p->pri.bytes_per_pixel = 4;
>> +
>> +p->cur.bytes_per_pixel = 4;
>> +/*
>> + * TODO: for now, assume primary and cursor planes are always enabled.
>> + * Setting them to false makes the screen flicker.
>> + */
>> +p->pri.enabled = true;
>> +p->cur.enabled = true;
>>
>> -if (crtc->cursor->state->fb) {
>> -p->cur.enabled = true;
>> -p->cur.bytes_per_pixel = 4;
>> -} else {
>> -p->cur.enabled = false;
>> -p->cur.bytes_per_pixel = 0;
>> -}
>> p->pri.horiz_pixels = intel_crtc->config->pipe_src_w;
>> p->cur.horiz_pixels = intel_crtc->base.cursor->state->crtc_w;
>>
>> --
>> 2.4.0.184.g8e1974e
>>
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/msm: use devm_gpiod_get_optional for optional reset gpio
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Also there is a variant to find optional gpios that returns NULL if
there is no gpio instead of -ENOENT.
Make use of both features to simplify the driver.
This makes error checking more strict because errors like -ENOSYS ("no
gpio support compiled in") or -EPROBE_DEFER ("gpio not ready yet") are
handled correctly now.
Furthermore this is one caller less that stops us making the flags
argument to gpiod_get*() mandatory.
Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 956b22492c9a..b3d8f4694bf2 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1353,34 +1353,19 @@ static int dsi_host_init_panel_gpios(struct
msm_dsi_host *msm_host,
{
int ret;
- msm_host->disp_en_gpio = devm_gpiod_get(panel_device,
- "disp-enable");
+ msm_host->disp_en_gpio = devm_gpiod_get_optional(panel_device,
+"disp-enable",
+GPIOD_OUT_LOW);
if (IS_ERR(msm_host->disp_en_gpio)) {
DBG("cannot get disp-enable-gpios %ld",
PTR_ERR(msm_host->disp_en_gpio));
- msm_host->disp_en_gpio = NULL;
- }
- if (msm_host->disp_en_gpio) {
- ret = gpiod_direction_output(msm_host->disp_en_gpio, 0);
- if (ret) {
- pr_err("cannot set dir to disp-en-gpios %d\n", ret);
- return ret;
- }
+ return PTR_ERR(msm_host->disp_en_gpio);
}
- msm_host->te_gpio = devm_gpiod_get(panel_device, "disp-te");
+ msm_host->te_gpio = devm_gpiod_get(panel_device, "disp-te", GPIOD_IN);
if (IS_ERR(msm_host->te_gpio)) {
DBG("cannot get disp-te-gpios %ld", PTR_ERR(msm_host->te_gpio));
- msm_host->te_gpio = NULL;
- }
-
- if (msm_host->te_gpio) {
- ret = gpiod_direction_input(msm_host->te_gpio);
- if (ret) {
- pr_err("%s: cannot set dir to disp-te-gpios, %d\n",
- __func__, ret);
- return ret;
- }
+ return PTR_ERR(msm_host->te_gpio);
}
return 0;
--
2.1.4
[Bug 90484] LLVM >=r237140 causes gpu lockups Spec Ops: The Line
https://bugs.freedesktop.org/show_bug.cgi?id=90484 --- Comment #7 from Arek RuÅniak --- Yes I saw #90481 before filled this. It's doesn't look the same. I don't even touch gameplay. In my case all lockups is happening in game menu. When I able to start the game i can play over 40 min. But i am not hard player so hard to tell it is never happen. Maybe fortune is by my side. Yesterday i tried r228821 and it works over 50min without issues, so i think it is somewhere in 3.7 branch. If i don't screw up it shoud be between r228821 & r230067. Keep searching. PS. I have another issue with blinking fog in MetroLL (in game, in "waiting screen", and in intro) and it's the same: somewhere between r228821 & r230067, so i'll find the little bastard for sure (but it's probably another 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/20150519/18a14bec/attachment.html>
[PATCH] drm/radeon: take the mode_config mutex when dealing with hpds
On Mon, May 18, 2015 at 11:28:47PM -0400, Alex Deucher wrote: > On Mon, May 18, 2015 at 11:24 PM, Dave Airlie wrote: > > On 19 May 2015 at 12:27, Michel Dänzer wrote: > >> On 19.05.2015 01:24, Alex Deucher wrote: > >>> > >>> @@ -96,10 +98,12 @@ static void radeon_dp_work_func(struct work_struct > >>> *work) > >>> struct drm_connector *connector; > >>> > >>> /* this should take a mutex */ > >>> + mutex_lock(&mode_config->mutex); > >> > >> This comment can be removed? > > > > I have vague memories of not doing this, because bad things happened. > > > > so keep an eye out for lockdep traces. > > I tested the non-MST handling pretty extensively, but I admit I didn't > play with mst. Might be better to split this into two patches. Registering a new connector also needs the dev->mode_config.mutex. If you hold that while calling into mst hpd code you'll deadlock. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] Add device enumeration interface (v3)
From: frank
v3: switch to udev/sysfs for the enumeration
Signed-off-by: Frank Min
Reviewed-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Jammy Zhou
---
Makefile.am | 7 +++--
xf86drm.c | 103
xf86drm.h | 19 +++
3 files changed, 127 insertions(+), 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 13df80c..ffd334a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -95,12 +95,15 @@ SUBDIRS = \
libdrm_la_LTLIBRARIES = libdrm.la
libdrm_ladir = $(libdir)
libdrm_la_LDFLAGS = -version-number 2:4:0 -no-undefined
-libdrm_la_LIBADD = @CLOCK_LIB@
+libdrm_la_LIBADD = \
+ @CLOCK_LIB@ \
+ @LIBUDEV_LIBS@
libdrm_la_CPPFLAGS = -I$(top_srcdir)/include/drm
AM_CFLAGS = \
$(WARN_CFLAGS) \
- $(VALGRIND_CFLAGS)
+ $(VALGRIND_CFLAGS) \
+ $(LIBUDEV_CFLAGS)
libdrm_la_SOURCES = $(LIBDRM_FILES)
diff --git a/xf86drm.c b/xf86drm.c
index f7c45f8..d2704de 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -63,6 +63,7 @@
#include "xf86drm.h"
#include "libdrm_macros.h"
+#include "libudev.h"
#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
defined(__DragonFly__)
#define DRM_MAJOR 145
@@ -2817,3 +2818,105 @@ char *drmGetRenderDeviceNameFromFd(int fd)
{
return drmGetMinorNameForFD(fd, DRM_NODE_RENDER);
}
+
+/**
+* Enumerate the GPU devices on the system
+*
+* \param devs device array set to return the device information
+* (if NULL, the number of device is returned)
+* \param vendor the vendor ID for GPU devices to list
+* (optional, if not specified, all GPU devices are returned)
+*
+* \return the number of GPU devices
+*/
+int drmGetPciDevices(drmPciDevicePtr devSet, uint16_t vendorId)
+{
+ struct udev *udev = NULL;
+ struct udev_enumerate *udev_enumerate;
+ struct udev_list_entry *list_entry;
+ struct udev_device *device;
+ int drmDevCount = 0;
+ int vendor = 0;
+ int devid = 0;
+ int devclass = 0;
+ int subvendor = 0;
+ int subdevid = 0;
+ int revid = 0xff;
+ int domain = 0;
+ int bus = 0;
+ int dev = 0;
+ int func = 0;
+ char config[64] = {0};
+ char node[128] = {'\0'};
+ char slot[] = ":00:00.0";
+ char *info = NULL;
+ int minor = 0xff;
+ int fd = 0;
+ int ret = 0;
+
+ udev = udev_new();
+ if (udev == NULL) {
+ fprintf(stderr, "no context\n");
+ return -EINVAL;
+ }
+ udev_enumerate = udev_enumerate_new(udev);
+ if (udev_enumerate == NULL)
+ return -EINVAL;
+ udev_enumerate_add_match_subsystem(udev_enumerate, "drm");
+ udev_enumerate_add_match_property(udev_enumerate, "DEVTYPE",
"drm_minor");
+
+ udev_enumerate_scan_devices(udev_enumerate);
+
+ udev_list_entry_foreach(list_entry,
udev_enumerate_get_list_entry(udev_enumerate)) {
+ device =
udev_device_new_from_syspath(udev_enumerate_get_udev(udev_enumerate),
+
udev_list_entry_get_name(list_entry));
+ if (device != NULL) {
+ info = udev_device_get_property_value(device, "MINOR");
+ if (!strcmp(info, "0")) {
+ strcpy(node, udev_device_get_syspath(device));
+ info = strstr(node, "/drm");
+ strncpy(slot, info - strlen(slot), strlen(slot));
+ if (sscanf(slot, "%4x:%2x:%2x.%1x", &domain, &bus,
&dev, &func) != 4) {
+ domain = 0;
+ bus = 0;
+ dev = 0;
+ func = 0;
+ }
+ strcpy(node + strlen(node), "/device/config");
+
+ fd = open(node, O_RDONLY);
+ if (fd >= 0) {
+ ret = read(fd, config, 64);
+ if (ret == 64) {
+ vendor = config[0] + (config[1] << 8);
+ devid = config[2] + (config[3] << 8);
+ revid = config[8];
+ devclass = config[9] + (config[10] <<
8) + (config[11] << 16);
+ subdevid = config[44] + (config[45] <<
8);
+ }
+ close(fd);
+ }
+
+ if((vendorId == 0) || (vendorId == vendor)) {
+ if(devSet != NULL) {
+ devSet[drmDevCount].domain = domain;
+ devSet[drmDevCount].bus = bus;
+ devSet[drmDevCount].dev = dev;
+ devSet[drmDevCount].func = fu
[PATCH] drm/bridge: use flags argument of devm_gpiod_get to set direction
On Tue, May 19, 2015 at 09:09:24AM +0200, Uwe Kleine-König wrote: > Hello, > > the subject is missing "ps8622" before the :. Should I resend for that? No need to resend, I've fixed it up while applying. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/f53621bb/attachment.sig>
[PATCH] drm/bridge: use flags argument of devm_gpiod_get to set direction
On Tue, May 19, 2015 at 09:03:49AM +0200, Uwe Kleine-König wrote:
> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
> which appeared in v3.17-rc1, the gpiod_get* functions take an additional
> parameter that allows to specify direction and initial value for output.
>
> Use this to simplify the driver. Furthermore this is one caller less
> that stops us making the flags argument to gpiod_get*() mandatory.
>
> Fixes: b2ea8772799d ("drm/bridge: Add I2C based driver for ps8622/ps8625
> bridge")
There's no need for this. The patch refactors code, but it doesn't fix
anything. Including a "Fixes:" line will cause people to pick this up
for stable releases, which I don't think is warranted in this case.
I've applied the patch with the "Fixes:" line removed.
Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/5d4f030c/attachment.sig>
[PATCH] drm/bridge/ptn3460: use flags argument of devm_gpiod_get to set direction
On Tue, May 19, 2015 at 09:15:56AM +0200, Uwe Kleine-König wrote:
> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
> which appeared in v3.17-rc1, the gpiod_get* functions take an additional
> parameter that allows to specify direction and initial value for output.
>
> Use this to simplify the driver. Furthermore this is one caller less
> that stops us making the flags argument to gpiod_get*() mandatory.
>
> Fixes: af478d8823a7 ("drm/bridge: ptn3460: use gpiod interface")
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/gpu/drm/bridge/ptn3460.c | 23 +++
> 1 file changed, 7 insertions(+), 16 deletions(-)
Applied without the "Fixes:" line.
Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/dddba69a/attachment.sig>
[PATCH] drm/bridge: use flags argument of devm_gpiod_get to set direction
Hello,
On Tue, May 19, 2015 at 10:06:54AM +0200, Thierry Reding wrote:
> On Tue, May 19, 2015 at 09:03:49AM +0200, Uwe Kleine-König wrote:
> > Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
> > which appeared in v3.17-rc1, the gpiod_get* functions take an additional
> > parameter that allows to specify direction and initial value for output.
> >
> > Use this to simplify the driver. Furthermore this is one caller less
> > that stops us making the flags argument to gpiod_get*() mandatory.
> >
> > Fixes: b2ea8772799d ("drm/bridge: Add I2C based driver for ps8622/ps8625
> > bridge")
>
> There's no need for this. The patch refactors code, but it doesn't fix
> anything. Including a "Fixes:" line will cause people to pick this up
> for stable releases, which I don't think is warranted in this case.
>
> I've applied the patch with the "Fixes:" line removed.
I added the line because at some near point in time I want to make the
flags argument mandatory and then it's a bug to not pass it. Do the
stable guys really pick patches that have Fixes: but not Cc: stable?
But I don't feel strong here. If you pick the patch up, everything
should be fine.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH v3 1/2] drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula
Reviewed-by: Rob Clark
Signed-off-by: Archit Taneja
---
v3:
- Add headerdocs for the new functions
v2:
- Add EXPORT_SYMBOL for the new functions
- Fix logic issue in mode_fixup()
drivers/gpu/drm/drm_atomic_helper.c | 29 +++-
drivers/gpu/drm/drm_bridge.c| 144
drivers/gpu/drm/drm_crtc_helper.c | 54 +-
include/drm/drm_crtc.h | 14
4 files changed, 188 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 1d2ca52..d6c85c0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -281,14 +281,11 @@ mode_fixup(struct drm_atomic_state *state)
encoder = conn_state->best_encoder;
funcs = encoder->helper_private;
- if (encoder->bridge && encoder->bridge->funcs->mode_fixup) {
- ret = encoder->bridge->funcs->mode_fixup(
- encoder->bridge, &crtc_state->mode,
- &crtc_state->adjusted_mode);
- if (!ret) {
- DRM_DEBUG_ATOMIC("Bridge fixup failed\n");
- return -EINVAL;
- }
+ ret = drm_bridge_mode_fixup(encoder->bridge, &crtc_state->mode,
+ &crtc_state->adjusted_mode);
+ if (!ret) {
+ DRM_DEBUG_ATOMIC("Bridge fixup failed\n");
+ return -EINVAL;
}
if (funcs->atomic_check) {
@@ -578,8 +575,7 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
* Each encoder has at most one connector (since we always steal
* it away), so we won't call disable hooks twice.
*/
- if (encoder->bridge)
- encoder->bridge->funcs->disable(encoder->bridge);
+ drm_bridge_disable(encoder->bridge);
/* Right function depends upon target state. */
if (connector->state->crtc && funcs->prepare)
@@ -589,8 +585,7 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
else
funcs->dpms(encoder, DRM_MODE_DPMS_OFF);
- if (encoder->bridge)
- encoder->bridge->funcs->post_disable(encoder->bridge);
+ drm_bridge_post_disable(encoder->bridge);
}
for_each_crtc_in_
[PATCH v3 2/2] drm: bridge: Add missing headerdocs for older bridge functions
Add headerdocs for drm_bridge_add, drm_bridge_remove, drm_bridge_attach and
of_drm_find_bridge.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/drm_bridge.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index f70e617..ceb8121 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -31,6 +31,11 @@
static DEFINE_MUTEX(bridge_lock);
static LIST_HEAD(bridge_list);
+/**
+ * drm_bridge_add - add the given bridge to the global bridge list
+ *
+ * @bridge: bridge control structure
+ */
int drm_bridge_add(struct drm_bridge *bridge)
{
mutex_lock(&bridge_lock);
@@ -41,6 +46,11 @@ int drm_bridge_add(struct drm_bridge *bridge)
}
EXPORT_SYMBOL(drm_bridge_add);
+/**
+ * drm_bridge_remove - remove the given bridge from the global bridge list
+ *
+ * @bridge: bridge control structure
+ */
void drm_bridge_remove(struct drm_bridge *bridge)
{
mutex_lock(&bridge_lock);
@@ -49,6 +59,18 @@ void drm_bridge_remove(struct drm_bridge *bridge)
}
EXPORT_SYMBOL(drm_bridge_remove);
+/**
+ * drm_bridge_attach - associate given bridge to our DRM device
+ *
+ * @dev: DRM device
+ * @bridge: bridge control structure
+ *
+ * called by a kms driver to link one of our encoder/bridge to the given
+ * bridge.
+ *
+ * Note that setting up links between the bridge and our encoder/bridge
+ * objects needs to be handled by the kms driver itself
+ */
int drm_bridge_attach(struct drm_device *dev, struct drm_bridge *bridge)
{
if (!dev || !bridge)
@@ -211,6 +233,12 @@ void drm_bridge_enable(struct drm_bridge *bridge)
EXPORT_SYMBOL(drm_bridge_enable);
#ifdef CONFIG_OF
+/**
+ * of_drm_find_bridge - find the bridge corresponding to the device node in
+ * the global bridge list
+ *
+ * @np: device node
+ */
struct drm_bridge *of_drm_find_bridge(struct device_node *np)
{
struct drm_bridge *bridge;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[Bug 89713] [radeon]GPU lockup in World of Tanks with gallium nine
https://bugs.freedesktop.org/show_bug.cgi?id=89713 --- Comment #9 from Iaroslav Andrusyak --- Created attachment 115893 --> https://bugs.freedesktop.org/attachment.cgi?id=115893&action=edit GTT usage во вÑÐµÐ¼Ñ Ð¸Ð³ÑÑ Ð¸ÑполÑзование ÐТТ ÑаÑÑеÑ, но поÑом она наÑÐ¸Ð½Ð°ÐµÑ ÑменÑÑаÑÑÑÑ Ð¸ игÑа вÑлеÑÐ°ÐµÑ -- 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/20150519/7766b41d/attachment.html>
[Bug 89713] [radeon]GPU lockup in World of Tanks with gallium nine
https://bugs.freedesktop.org/show_bug.cgi?id=89713 --- Comment #10 from Iaroslav Andrusyak --- during the game use GTT growing, but then it starts to decrease and the game crashes -- 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/20150519/0c4de147/attachment.html>
[Bug 90515] memory use increase with vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=90515 Bug ID: 90515 Summary: memory use increase with vdpau Product: Mesa Version: 10.4 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: fabrice at bellet.info QA Contact: dri-devel at lists.freedesktop.org I noticed a constant increase of rss memory while playing a video using vdpau + radeonsi, caused by X events accumulating in read_packet (c=0x8275a0) at xcb_in.c:333, and never flushed, and corresponding to this backtrace : Breakpoint 6, read_packet (c=0x8275a0) at xcb_in.c:333 (gdb) bt #0 0x7fffec99b281 in read_packet (c=0x8275a0) at xcb_in.c:333 #1 0x7fffec99c742 in _xcb_in_read (c=0x8275a0) at xcb_in.c:936 #2 0x7fffec999ae4 in _xcb_conn_wait (c=0x8275a0, cond=0x7fffe1636960, vector=0x0, count=0x0) at xcb_conn.c:495 #3 0x7fffec99b78b in wait_for_reply (c=0x8275a0, request=207, e=0x0) at xcb_in.c:493 #4 0x7fffec99b8a4 in xcb_wait_for_reply (c=0x8275a0, request=207, e=0x0) at xcb_in.c:523 #5 0x7fffea7c5ac8 in xcb_dri2_swap_buffers_reply (c=0x8275a0, cookie=..., e=0x0) at dri2.c:893 #6 0x7fffe6a982f0 in vl_dri2_get_flush_reply (scrn=0x83cab0) at ../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:103 #7 0x7fffe6a984b4 in vl_dri2_destroy_drawable (scrn=0x83cab0) at ../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:146 #8 0x7fffe6a98524 in vl_dri2_set_drawable (scrn=0x83cab0, drawable=41943041) at ../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:162 #9 0x7fffe6a988ed in vl_screen_get_timestamp (vscreen=0x83cab0, drawable=41943041)at ../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:269 #10 0x7fffe6aa193d in vlVdpPresentationQueueGetTime (presentation_queue=11,current_time=0x7fffe1636b80) at presentation.c:189 #11 0x7fffe6aa1f04 in vlVdpPresentationQueueBlockUntilSurfaceIdle (presentation_queue=11, surface=13, first_presentation_time=0x7fffe1636b80) at presentation.c:335 #12 0x7fffe719fb51 in put_surface () at /usr/lib64/dri/radeonsi_drv_video.so #13 0x7fffe719fdcf in vdpau_PutSurface () at /usr/lib64/dri/radeonsi_drv_video.so #14 0x7fffed5ead37 in gst_vaapi_texture_glx_put_surface (flags=0, crop_rect=0x7fffe1636d20,surface=0x7fffdc08fd90, base_texture=0x7fffcc1385a0) at gstvaapitexture_glx.c:315 #15 0x7fffed5ead37 in gst_vaapi_texture_glx_put_surface (texture=0x7fffcc1385a0, surface=0x7fffdc08fd90, crop_rect=0x7fffe1636d20, flags=0) at gstvaapitexture_glx.c:378 #16 0x7fffedf6e1b1 in gst_vaapi_texture_put_surface (texture=0x7fffcc1385a0, surface=0x7fffdc08fd90, crop_rect=, flags=) at gstvaapitexture.c:332 #17 0x7fffe99118ec in _do_upload_with_meta (context=, upload=0x7fffdc029600 [GstGLUpload]) at gstglupload.c:357 #18 0x7fffe9913198 in _run_message_sync (message=0x7fffe1e37840) at gstglwindow.c:353 #19 0x7fffe9917a82 in _run_message (message=0x7fffd8001b60)at gstglwindow_x11.c:598 #20 0x773857fb in g_main_context_dispatch (context=0x7fffcc010980) at gmain.c:3111 #21 0x773857fb in g_main_context_dispatch (context=context at entry=0x7fffcc010980) at gmain.c:3710 #22 0x77385b98 in g_main_context_iterate (context=0x7fffcc010980, block=block at entry=1, dispatch=dispatch at entry=1, self=) at gmain.c:3781 #23 0x77385ec2 in g_main_loop_run (loop=0x7fffcc010b70)at gmain.c:3975 #24 0x7fffe9901cf7 in gst_gl_context_create_thread (context=0x7fffdc023260 [GstGLContextGLX]) at gstglcontext.c:959 #25 0x773ac3d5 in g_thread_proxy (data=0x7fffdc0234a0) at gthread.c:764 #26 0x76f2352a in start_thread (arg=0x7fffe1637700) at pthread_create.c:310 #27 0x76c5f22d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 The commands generating this case is : # ln -s vdpau_drv_video.so /usr/lib64/dri/radeonsi_drv_video.so $ export VDPAU_DRIVER=radeonsi $ wget http://samples.mplayerhq.hu/MPEG-4/NeroRecodeSample-MP4/NeroRecodeSample.mp4 $ gst-launch-1.0 filesrc location=NeroRecodeSample.mp4 ! qtdemux ! mpeg4videoparse ! vaapidecode ! videoconvert ! glimagesink The two malloc() occuring in libxcb in read_packet() are sufficient to make gst-launch-1.0 memory use grow out of control. It seems to occur because vl_dri2_set_drawable() is called alternatively with two different drawables, each call destroying the previous drawable. -- 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/20150519/8efbaf7f/attachment.html>
[Bug 89713] [radeon]GPU lockup in World of Tanks with gallium nine
https://bugs.freedesktop.org/show_bug.cgi?id=89713 Iaroslav Andrusyak changed: What|Removed |Added Attachment #115893|0 |1 is obsolete|| --- Comment #11 from Iaroslav Andrusyak --- Created attachment 115894 --> https://bugs.freedesktop.org/attachment.cgi?id=115894&action=edit GTT usage -- 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/20150519/65abb551/attachment-0001.html>
[Bug 87856] Driver load fails with no error on ppc64 host
https://bugs.freedesktop.org/show_bug.cgi?id=87856 --- Comment #8 from kristof --- (In reply to Alex Deucher from comment #7) > All it needs to contain is the following. > > Section "Device" > Identifier "Radeon" > Driver "radeon" > Option "NoAccel" "true" > EndSection Hi ALex, Following your advise, I've putted it in a xorg.conf Consequence : system disabled Gallium then returns on Software Rasterizer methode. It results that it improves perf, glxgears (without vblank=0 option set) run now 102 fps (60 before) Regards, Kristof -- 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/20150519/69bd7f8c/attachment.html>
gma500: initial medfield merge
Hello Kirill A. Shutemov,
The patch 026abc333205: "gma500: initial medfield merge" from Mar 8,
2012, leads to the following static checker warning:
drivers/gpu/drm/gma500/mdfld_intel_display.c:102
mdfldWaitForPipeEnable()
warn: masked condition '(temp & (1 << 30)) == 1' is always false.
drivers/gpu/drm/gma500/mdfld_intel_display.c
79 void mdfldWaitForPipeEnable(struct drm_device *dev, int pipe)
80 {
81 struct drm_psb_private *dev_priv = dev->dev_private;
82 const struct psb_offset *map = &dev_priv->regmap[pipe];
83 int count, temp;
84
85 switch (pipe) {
86 case 0:
87 case 1:
88 case 2:
89 break;
90 default:
91 DRM_ERROR("Illegal Pipe Number.\n");
92 return;
93 }
94
95 /* FIXME JLIU7_PO */
96 gma_wait_for_vblank(dev);
97 return;
98
99 /* Wait for for the pipe enable to take effect. */
100 for (count = 0; count < COUNT_MAX; count++) {
101 temp = REG_READ(map->conf);
102 if ((temp & PIPEACONF_PIPE_STATE) == 1)
^^
Never true. It meants we always loop until the timeout. I am tempted
to change it to:
if (temp & PIPEACONF_PIPE_STATE)
But removing delays is slightly risky unless you can test it on
hardware.
103 break;
104 }
105 }
regards,
dan carpenter
[PATCH v3 1/2] drm: bridge: Allow daisy chaining of bridges
On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote:
> Allow drm_bridge objects to link to each other in order to form an encoder
> chain. The requirement for creating a chain of bridges comes because the
> MSM drm driver uses up its encoder and bridge objects for blocks within
> the SoC itself. There isn't anything left to use if the SoC display output
> is connected to an external encoder IC. Having an additional bridge
> connected to the existing bridge helps here. In general, it is possible for
> platforms to have multiple devices between the encoder and the
> connector/panel that require some sort of configuration.
>
> We create drm bridge helper functions corresponding to each op in
> 'drm_bridge_funcs'. These helpers call the corresponding
> 'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
> used internally by drm_atomic_helper.c and drm_crtc_helper.c.
>
> The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
> the bridge closet to the encoder, and proceed until the last bridge in the
> chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
> helpers. The drm_bridge_disable/post_disable helpers disable the last
> bridge in the chain first, and proceed until the first bridge in the chain
> is disabled.
>
> drm_bridge_attach() remains the same. As before, the driver calling this
> function should make sure it has set the links correctly. The order in
> which the bridges are connected to each other determines the order in which
> the calls are made. One requirement is that every bridge in the chain
> should point the parent encoder object. This is required since bridge
> drivers expect a valid encoder pointer in drm_bridge. For example, consider
> a chain where an encoder's output is connected to bridge1, and bridge1's
> output is connected to bridge2:
>
> /* Like before, attach bridge to an encoder */
> bridge1->encoder = encoder;
> ret = drm_bridge_attach(dev, bridge1);
> ..
>
> /*
>* set the first bridge's 'next' bridge to bridge2, set its encoder
>* as bridge1's encoder
>*/
> bridge1->next = bridge2
> bridge2->encoder = bridge1->encoder;
> ret = drm_bridge_attach(dev, bridge2);
>
> ...
> ...
>
> This method of bridge chaining isn't intrusive and existing drivers that
> use drm_bridge will behave the same way as before. The bridge helpers also
> cleans up the atomic and crtc helper files a bit.
>
> Reviewed-by: Jani Nikula
> Reviewed-by: Rob Clark
> Signed-off-by: Archit Taneja
Two comments below about the nesting of callers. lgtm otherwise.
-Daniel
> ---
> v3:
> - Add headerdocs for the new functions
>
> v2:
> - Add EXPORT_SYMBOL for the new functions
> - Fix logic issue in mode_fixup()
>
> drivers/gpu/drm/drm_atomic_helper.c | 29 +++-
> drivers/gpu/drm/drm_bridge.c| 144
>
> drivers/gpu/drm/drm_crtc_helper.c | 54 +-
> include/drm/drm_crtc.h | 14
> 4 files changed, 188 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 1d2ca52..d6c85c0 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -281,14 +281,11 @@ mode_fixup(struct drm_atomic_state *state)
> encoder = conn_state->best_encoder;
> funcs = encoder->helper_private;
>
> - if (encoder->bridge && encoder->bridge->funcs->mode_fixup) {
> - ret = encoder->bridge->funcs->mode_fixup(
> - encoder->bridge, &crtc_state->mode,
> - &crtc_state->adjusted_mode);
> - if (!ret) {
> - DRM_DEBUG_ATOMIC("Bridge fixup failed\n");
> - return -EINVAL;
> - }
> + ret = drm_bridge_mode_fixup(encoder->bridge, &crtc_state->mode,
> + &crtc_state->adjusted_mode);
> + if (!ret) {
> + DRM_DEBUG_ATOMIC("Bridge fixup failed\n");
> + return -EINVAL;
> }
>
> if (funcs->atomic_check) {
> @@ -578,8 +575,7 @@ disable_outputs(struct drm_device *dev, struct
> drm_atomic_state *old_state)
>* Each encoder has at most one connector (since we always steal
>* it away), so we won't call disable hooks twice.
>*/
> - if (encoder->bridge)
> - encoder->bridge->funcs->disable(encoder->bridge);
> + drm_bridge_disable(encoder->bridge);
>
> /* Right function depends upon target state. */
> if (connector->state->crtc && funcs->prepare)
> @@ -589,8 +585,7 @@ disable_outputs(struct drm_device *dev, struct
> drm_atomic_state *old_state)
> els
[PATCH v3 2/2] drm: bridge: Add missing headerdocs for older bridge functions
On Tue, May 19, 2015 at 02:05:05PM +0530, Archit Taneja wrote:
> Add headerdocs for drm_bridge_add, drm_bridge_remove, drm_bridge_attach and
> of_drm_find_bridge.
>
> Signed-off-by: Archit Taneja
You also need to pull in the kerneldoc into the drm.tmpl DocBook template
to include into the drm docs. You can generate those with
$ make htmldocs -k
-k because right now 802 docs are broken :( Also it'd be awesome if you
could include a short DOC: section to describe the design&goal of
drm_bridge quickly and also include that into the DocBook.
> ---
> drivers/gpu/drm/drm_bridge.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index f70e617..ceb8121 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -31,6 +31,11 @@
> static DEFINE_MUTEX(bridge_lock);
> static LIST_HEAD(bridge_list);
>
> +/**
> + * drm_bridge_add - add the given bridge to the global bridge list
> + *
> + * @bridge: bridge control structure
For functions which return something it's good to add a Returns: section
describing the semantics of the return codes. Copypasting something
suitable from other kerneldoc is good for consistency ;-)
Cheers, Daniel
> + */
> int drm_bridge_add(struct drm_bridge *bridge)
> {
> mutex_lock(&bridge_lock);
> @@ -41,6 +46,11 @@ int drm_bridge_add(struct drm_bridge *bridge)
> }
> EXPORT_SYMBOL(drm_bridge_add);
>
> +/**
> + * drm_bridge_remove - remove the given bridge from the global bridge list
> + *
> + * @bridge: bridge control structure
> + */
> void drm_bridge_remove(struct drm_bridge *bridge)
> {
> mutex_lock(&bridge_lock);
> @@ -49,6 +59,18 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> }
> EXPORT_SYMBOL(drm_bridge_remove);
>
> +/**
> + * drm_bridge_attach - associate given bridge to our DRM device
> + *
> + * @dev: DRM device
> + * @bridge: bridge control structure
> + *
> + * called by a kms driver to link one of our encoder/bridge to the given
> + * bridge.
> + *
> + * Note that setting up links between the bridge and our encoder/bridge
> + * objects needs to be handled by the kms driver itself
> + */
> int drm_bridge_attach(struct drm_device *dev, struct drm_bridge *bridge)
> {
> if (!dev || !bridge)
> @@ -211,6 +233,12 @@ void drm_bridge_enable(struct drm_bridge *bridge)
> EXPORT_SYMBOL(drm_bridge_enable);
>
> #ifdef CONFIG_OF
> +/**
> + * of_drm_find_bridge - find the bridge corresponding to the device node in
> + * the global bridge list
> + *
> + * @np: device node
> + */
> struct drm_bridge *of_drm_find_bridge(struct device_node *np)
> {
> struct drm_bridge *bridge;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 1/2] drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register name
Hi Vladimir, Am Montag, den 18.05.2015, 15:32 +0300 schrieb Vladimir Zapolskiy: > I2CM_ADDRESS became a MESS, fix it, also change guarding define > to __DW_HDMI_H__ , since the driver is not IMX specific. > > Signed-off-by: Vladimir Zapolskiy Acked-by: Philipp Zabel regards Philipp
[PULL resend] drm-amdkfd-next
Hi Dave, Resending the pull request of amdkfd for 4.2 after fixing what you requested (bool -> uint32_t and using git:// instead of ssh://) drm-amdkfd-next-2015-05-19: - Add the interrupts & events modules, including new IOCTLs to create and wait on events. The HSA RT open source stack is mainly using events to know when a dispatched work has been completed. In addition, this module is a pre-requisite for the next module I'm going to upstream - debugger support This module also handles H/W exceptions, such as memory exception received through the IOMMUv2 H/W and Bad Opcode exception receieved from the GPU. - Adding a new kernel module parameter to let the user decide whether he wants to receive a SIGTERM when a memory exception occurs inside the GPU kernel and the HSA application doesn't wait on an appropriate event, or if he just want to receive notification about this event in dmesg. The default is the latter. - Additional improvements for SDMA code - Update my email address in Maintainers file. Thanks, Oded The following changes since commit d0093404f808e23a480dbb4e05c083f1cfeddfd9: Merge tag 'drm-intel-next-2015-05-08' of git://anongit.freedesktop.org/drm-intel into drm-next (2015-05-19 10:18:13 +1000) are available in the git repository at: git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-next-2015-05-19 for you to fetch changes up to 7591cd2cd59d77c52141d9c2c759c14f981c1a13: drm/amdkfd: change driver version to 0.7.2 (2015-05-19 13:02:30 +0300) Alexey Skidanov (2): drm/amdkfd: Add memory exception handling drm/amdkfd: Add bad opcode exception handling Andrew Lewycky (4): drm/amdkfd: Add interrupt handling module drm/amdkfd: add events IOCTL set definitions drm/amdkfd: Add the events module drm/amdkfd: Implement events IOCTLs Firo Yang (1): drm/amdkfd: Remove unessary void pointer cast Oded Gabbay (7): drm/amdkfd: reformat some debug prints drm/amdkfd: Use new struct for asic specific ops drm/amdkfd: make the sdma vm init to be asic specific MAINTAINERS: update amdkfd Oded's email address drm/radeon: Add init interrupt kfd->kgd interface drm/amdkfd: Add module parameter of send_sigterm drm/amdkfd: change driver version to 0.7.2 MAINTAINERS| 2 +- drivers/gpu/drm/amd/amdkfd/Makefile| 1 + drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c | 66 ++ drivers/gpu/drm/amd/amdkfd/cik_int.h | 41 + drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 87 +- drivers/gpu/drm/amd/amdkfd/kfd_device.c| 52 +- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 30 +- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 21 +- .../drm/amd/amdkfd/kfd_device_queue_manager_cik.c | 18 +- .../drm/amd/amdkfd/kfd_device_queue_manager_vi.c | 10 +- drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 15 +- drivers/gpu/drm/amd/amdkfd/kfd_events.c| 965 + drivers/gpu/drm/amd/amdkfd/kfd_events.h| 84 ++ drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 188 drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 5 +- drivers/gpu/drm/amd/amdkfd/kfd_module.c| 9 +- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 75 ++ drivers/gpu/drm/amd/amdkfd/kfd_process.c | 27 +- drivers/gpu/drm/amd/include/kgd_kfd_interface.h| 2 + drivers/gpu/drm/radeon/cik_reg.h | 2 + drivers/gpu/drm/radeon/cikd.h | 1 + drivers/gpu/drm/radeon/radeon_kfd.c| 21 +- include/uapi/linux/kfd_ioctl.h | 96 +- 23 files changed, 1778 insertions(+), 40 deletions(-) create mode 100644 drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c create mode 100644 drivers/gpu/drm/amd/amdkfd/cik_int.h create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_events.c create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_events.h create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
[PATCH 1/2] drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register name
Hi Vladimir, Am Montag, den 18.05.2015, 15:32 +0300 schrieb Vladimir Zapolskiy: > I2CM_ADDRESS became a MESS, fix it, also change guarding define > to __DW_HDMI_H__ , since the driver is not IMX specific. > > Signed-off-by: Vladimir Zapolskiy Acked-by: Philipp Zabel regards Philipp
[PATCH v2 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Hi Vladimir, Am Montag, den 18.05.2015, 15:32 +0300 schrieb Vladimir Zapolskiy: > The change adds support of internal HDMI I2C master controller, this > subdevice is used by default, if "ddc-i2c-bus" DT property is omitted. > > The main purpose of this functionality is to support reading EDID from > an HDMI monitor on boards, which don't have an I2C bus connected to > DDC pins. > > Signed-off-by: Vladimir Zapolskiy Tested-by: Philipp Zabel on imx6q-nitrogen6x with the DDC pads muxed to HDMI_TX. regards Philipp
[PATCH v6 06/11] cec: add HDMI CEC framework
Hi Sean,
I'm taking over this patch series from Kamil for the time being with his
permission (he's switching jobs and moving house so he can't spend any time
on this for a while).
On 05/13/15 13:10, Sean Young wrote:
> On Mon, May 04, 2015 at 07:32:59PM +0200, Kamil Debski wrote:
>> From: Hans Verkuil
>>
>> The added HDMI CEC framework provides a generic kernel interface for
>> HDMI CEC devices.
>>
>> Signed-off-by: Hans Verkuil
>
> -snip-
>
>> +int cec_create_adapter(struct cec_adapter *adap, const char *name, u32 caps)
>> +{
>> +int res = 0;
>> +
>> +adap->state = CEC_ADAP_STATE_DISABLED;
>> +adap->name = name;
>> +adap->phys_addr = 0x;
>> +adap->capabilities = caps;
>> +adap->version = CEC_VERSION_1_4;
>> +adap->sequence = 0;
>> +mutex_init(&adap->lock);
>> +adap->kthread = kthread_run(cec_thread_func, adap, name);
>> +init_waitqueue_head(&adap->kthread_waitq);
>> +init_waitqueue_head(&adap->waitq);
>> +if (IS_ERR(adap->kthread)) {
>> +pr_err("cec-%s: kernel_thread() failed\n", name);
>> +return PTR_ERR(adap->kthread);
>> +}
>> +if (caps) {
>> +res = cec_devnode_register(&adap->devnode, adap->owner);
>> +if (res)
>> +kthread_stop(adap->kthread);
>> +}
>> +adap->recv_notifier = cec_receive_notify;
>> +
>> +/* Prepare the RC input device */
>> +adap->rc = rc_allocate_device();
>> +if (!adap->rc) {
>> +pr_err("cec-%s: failed to allocate memory for rc_dev\n", name);
>> +cec_devnode_unregister(&adap->devnode);
>> +kthread_stop(adap->kthread);
>> +return -ENOMEM;
>> +}
>> +
>> +snprintf(adap->input_name, sizeof(adap->input_name), "RC for %s", name);
>> +snprintf(adap->input_phys, sizeof(adap->input_phys), "%s/input0", name);
>> +strncpy(adap->input_drv, name, sizeof(adap->input_drv));
>> +
>> +adap->rc->input_name = adap->input_name;
>> +adap->rc->input_phys = adap->input_phys;
>> +adap->rc->dev.parent = &adap->devnode.dev;
>> +adap->rc->driver_name = adap->input_drv;
>> +adap->rc->driver_type = RC_DRIVER_CEC;
>> +adap->rc->allowed_protocols = RC_BIT_CEC;
>> +adap->rc->priv = adap;
>> +adap->rc->map_name = RC_MAP_CEC;
>> +adap->rc->timeout = MS_TO_NS(100);
>> +
>
> rc->input_id is not populated. It would be nice if input_phys has some
> resemblance to a physical path (like the output of usb_make_path() if it
> is a usb device).
I've added a BUS_CEC type, the version field can probably get the CEC version
used, but the vendor/product IDs are difficult: there isn't a product ID in
the CEC protocol, but there is a 24-bit vendor ID. I'm wondering whether I
should just put the top 8 bits of the vendor ID in the vendor field and the
remaining 16 in the product field. That way the combination of the two will be
unique.
What do you think?
>> +res = rc_register_device(adap->rc);
>> +
>> +if (res) {
>> +pr_err("cec-%s: failed to prepare input device\n", name);
>> +cec_devnode_unregister(&adap->devnode);
>> +rc_free_device(adap->rc);
>> +kthread_stop(adap->kthread);
>> +}
>> +
>> +return res;
>> +}
>> +EXPORT_SYMBOL_GPL(cec_create_adapter);
>> +
>> +void cec_delete_adapter(struct cec_adapter *adap)
>> +{
>> +if (adap->kthread == NULL)
>> +return;
>> +kthread_stop(adap->kthread);
>> +if (adap->kthread_config)
>> +kthread_stop(adap->kthread_config);
>> +adap->state = CEC_ADAP_STATE_DISABLED;
>> +if (cec_devnode_is_registered(&adap->devnode))
>> +cec_devnode_unregister(&adap->devnode);
>
> I think you're missing a rc_unregister_device() here.
Yes indeed. Added.
Regards,
Hans
>
>> +}
>> +EXPORT_SYMBOL_GPL(cec_delete_adapter);
>
>
> Sean
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[PATCH v3 1/2] drm: bridge: Allow daisy chaining of bridges
Hi,
On 05/19/2015 03:04 PM, Daniel Vetter wrote:
> On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote:
>> Allow drm_bridge objects to link to each other in order to form an encoder
>> chain. The requirement for creating a chain of bridges comes because the
>> MSM drm driver uses up its encoder and bridge objects for blocks within
>> the SoC itself. There isn't anything left to use if the SoC display output
>> is connected to an external encoder IC. Having an additional bridge
>> connected to the existing bridge helps here. In general, it is possible for
>> platforms to have multiple devices between the encoder and the
>> connector/panel that require some sort of configuration.
>>
>> We create drm bridge helper functions corresponding to each op in
>> 'drm_bridge_funcs'. These helpers call the corresponding
>> 'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
>> used internally by drm_atomic_helper.c and drm_crtc_helper.c.
>>
>> The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
>> the bridge closet to the encoder, and proceed until the last bridge in the
>> chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
>> helpers. The drm_bridge_disable/post_disable helpers disable the last
>> bridge in the chain first, and proceed until the first bridge in the chain
>> is disabled.
>>
>> drm_bridge_attach() remains the same. As before, the driver calling this
>> function should make sure it has set the links correctly. The order in
>> which the bridges are connected to each other determines the order in which
>> the calls are made. One requirement is that every bridge in the chain
>> should point the parent encoder object. This is required since bridge
>> drivers expect a valid encoder pointer in drm_bridge. For example, consider
>> a chain where an encoder's output is connected to bridge1, and bridge1's
>> output is connected to bridge2:
>>
>> /* Like before, attach bridge to an encoder */
>> bridge1->encoder = encoder;
>> ret = drm_bridge_attach(dev, bridge1);
>> ..
>>
>> /*
>> * set the first bridge's 'next' bridge to bridge2, set its encoder
>> * as bridge1's encoder
>> */
>> bridge1->next = bridge2
>> bridge2->encoder = bridge1->encoder;
>> ret = drm_bridge_attach(dev, bridge2);
>>
>> ...
>> ...
>>
>> This method of bridge chaining isn't intrusive and existing drivers that
>> use drm_bridge will behave the same way as before. The bridge helpers also
>> cleans up the atomic and crtc helper files a bit.
>>
>> Reviewed-by: Jani Nikula
>> Reviewed-by: Rob Clark
>> Signed-off-by: Archit Taneja
>
> Two comments below about the nesting of callers. lgtm otherwise.
> -Daniel
>
>> ---
>> v3:
>> - Add headerdocs for the new functions
>>
>> v2:
>> - Add EXPORT_SYMBOL for the new functions
>> - Fix logic issue in mode_fixup()
>>
>> drivers/gpu/drm/drm_atomic_helper.c | 29 +++-
>> drivers/gpu/drm/drm_bridge.c| 144
>>
>> drivers/gpu/drm/drm_crtc_helper.c | 54 +-
>> include/drm/drm_crtc.h | 14
>> 4 files changed, 188 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 1d2ca52..d6c85c0 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -281,14 +281,11 @@ mode_fixup(struct drm_atomic_state *state)
>> encoder = conn_state->best_encoder;
>> funcs = encoder->helper_private;
>>
>> -if (encoder->bridge && encoder->bridge->funcs->mode_fixup) {
>> -ret = encoder->bridge->funcs->mode_fixup(
>> -encoder->bridge, &crtc_state->mode,
>> -&crtc_state->adjusted_mode);
>> -if (!ret) {
>> -DRM_DEBUG_ATOMIC("Bridge fixup failed\n");
>> -return -EINVAL;
>> -}
>> +ret = drm_bridge_mode_fixup(encoder->bridge, &crtc_state->mode,
>> +&crtc_state->adjusted_mode);
>> +if (!ret) {
>> +DRM_DEBUG_ATOMIC("Bridge fixup failed\n");
>> +return -EINVAL;
>> }
>>
>> if (funcs->atomic_check) {
>> @@ -578,8 +575,7 @@ disable_outputs(struct drm_device *dev, struct
>> drm_atomic_state *old_state)
>> * Each encoder has at most one connector (since we always steal
>> * it away), so we won't call disable hooks twice.
>> */
>> -if (encoder->bridge)
>> -encoder->bridge->funcs->disable(encoder->bridge);
>> +drm_bridge_disable(encoder->bridge);
>>
>> /* Right function depends upon target state. */
>> if (connector->state->crtc && funcs->prepare)
>> @@ -5
[PATCH v3 2/2] drm: bridge: Add missing headerdocs for older bridge functions
On 05/19/2015 03:07 PM, Daniel Vetter wrote: > On Tue, May 19, 2015 at 02:05:05PM +0530, Archit Taneja wrote: >> Add headerdocs for drm_bridge_add, drm_bridge_remove, drm_bridge_attach and >> of_drm_find_bridge. >> >> Signed-off-by: Archit Taneja > > You also need to pull in the kerneldoc into the drm.tmpl DocBook template > to include into the drm docs. You can generate those with > > $ make htmldocs -k > > -k because right now 802 docs are broken :( Also it'd be awesome if you > could include a short DOC: section to describe the design&goal of > drm_bridge quickly and also include that into the DocBook. > >> --- >> drivers/gpu/drm/drm_bridge.c | 28 >> 1 file changed, 28 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c >> index f70e617..ceb8121 100644 >> --- a/drivers/gpu/drm/drm_bridge.c >> +++ b/drivers/gpu/drm/drm_bridge.c >> @@ -31,6 +31,11 @@ >> static DEFINE_MUTEX(bridge_lock); >> static LIST_HEAD(bridge_list); >> >> +/** >> + * drm_bridge_add - add the given bridge to the global bridge list >> + * >> + * @bridge: bridge control structure > > For functions which return something it's good to add a Returns: section > describing the semantics of the return codes. Copypasting something > suitable from other kerneldoc is good for consistency ;-) I wasn't aware of the template stuff. I'll do the required. Thanks! Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Experiencing FIFO underruns on Intel Skylake platform
Hi, I'm testing the vanilla kernel on prototype boards for Intel Skylake. The graphics adapter on those boards identifies like this: 00:02.0 0300: 8086:1912 (rev 04) (prog-if 00 [VGA controller]) Subsystem: 1734:121c Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: [40] Vendor Specific Information: Len=0c Capabilities: [70] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE+ DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee00018 Data: Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [100 v1] #1b Capabilities: [200 v1] Address Translation Service (ATS) ATSCap: Invalidate Queue Depth: 00 ATSCtl: Enable-, Smallest Translation Unit: 00 Capabilities: [300 v1] #13 Kernel driver in use: i915 Kernel modules: i915 I'm running both Fedora 21 and OpenSUSE 13.2 on those boards at the moment, both with a self compiled Kernel 4.1-rc4 (latest git pull was today). Problem: Whenever power management kicks in and blanks the screen the systems behave very strange when trying to get the screen back. The screen is not fully restored then, but when I move the mouse (Gnome 3 or XFCE desktops) up and down the image rolls up and down like a curtain. I see no mouse cursor anymore and can't resume to normal operation. When this happens I see the following line in dmesg: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Hardware is still the first prototypes for Skylake, BIOS is beta too. But I wanted to give a note about that problem here, maybe someone has an idea what is missing. Regards Rainer -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Clients Dept. PDG WPS R&D SW OSE Fujitsu Technology Solutions Bürgermeister-Ullrich-Str. 100 86199 Augsburg Germany Telephone: +49-821-804-3321 Telefax: +49-821-804-2131 Mail: mailto:Rainer.Koenig at ts.fujitsu.com Internet ts.fujtsu.com Company Details ts.fujitsu.com/imprint.html
[PATCH] drm/ttm: dma: Don't crash on memory in the vmalloc range
On 05/16/2015 04:55 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, May 15, 2015 at 04:09:54PM +0900, Alexandre Courbot wrote:
>> dma_alloc_coherent() can return memory in the vmalloc range.
>> virt_to_page() cannot handle such addresses and crashes. This
>> patch detects such cases and obtains the struct page * using
>> vmalloc_to_page() instead.
>>
>> Signed-off-by: Alexandre Courbot
>> ---
>> This patch is a follow-up of the following discussion:
>>
>> https://www.marc.info/?l=dri-devel&m=141579595431254&w=3
>>
>> It works for me on both 32-bit and 64-bit Tegra, so I am not convinced
>> that Thierry's initial change from virt_to_page() to phys_to_page() is
>> still required - Thierry, can you confirm whether your patch is still
>> relevant after this one?
>>
>> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 9 ++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> index 01e1d27eb078..3077f1554099 100644
>> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> @@ -342,9 +342,12 @@ static struct dma_page *__ttm_dma_alloc_page(struct
>> dma_pool *pool)
>> d_page->vaddr = dma_alloc_coherent(pool->dev, pool->size,
>> &d_page->dma,
>> pool->gfp_flags);
>> -if (d_page->vaddr)
>> -d_page->p = virt_to_page(d_page->vaddr);
>> -else {
>> +if (d_page->vaddr) {
>> +if (is_vmalloc_addr(d_page->vaddr))
>> +d_page->p = vmalloc_to_page(d_page->vaddr);
>> +else
>> +d_page->p = virt_to_page(d_page->vaddr);
>> +} else {
>
>
> Looks OK to me.
Thanks guys. Could we translate these approvals into
Acked-bys/Reviewed-bys so Dave (?) can merge this patch?
Experiencing FIFO underruns on Intel Skylake platform
+intel-gfx On Tue, 19 May 2015, Rainer Koenig wrote: > Hi, > > I'm testing the vanilla kernel on prototype boards for Intel Skylake. > The graphics adapter on those boards identifies like this: > > 00:02.0 0300: 8086:1912 (rev 04) (prog-if 00 [VGA controller]) > Subsystem: 1734:121c > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-Latency: 0 > Interrupt: pin A routed to IRQ 123 > Region 0: Memory at d000 (64-bit, non-prefetchable) [size=16M] > Region 2: Memory at c000 (64-bit, prefetchable) [size=256M] > Region 4: I/O ports at f000 [size=64] > Expansion ROM at [disabled] > Capabilities: [40] Vendor Specific Information: Len=0c > Capabilities: [70] Express (v2) Root Complex Integrated Endpoint, MSI 00 > DevCap: MaxPayload 128 bytes, PhantFunc 0 > ExtTag- RBE+ > DevCtl: Report errors: Correctable- Non-Fatal- Fatal- > Unsupported- > RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- > MaxPayload 128 bytes, MaxReadReq 128 bytes > DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- > TransPend- > DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, > OBFF > Not Supported > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, > OBFF > Disabled > Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit- > Address: fee00018 Data: > Capabilities: [d0] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [100 v1] #1b > Capabilities: [200 v1] Address Translation Service (ATS) > ATSCap: Invalidate Queue Depth: 00 > ATSCtl: Enable-, Smallest Translation Unit: 00 > Capabilities: [300 v1] #13 > Kernel driver in use: i915 > Kernel modules: i915 > > > I'm running both Fedora 21 and OpenSUSE 13.2 on those boards at the > moment, both with a self compiled Kernel 4.1-rc4 (latest git pull was > today). > > Problem: Whenever power management kicks in and blanks the screen the > systems behave very strange when trying to get the screen back. The > screen is not fully restored then, but when I move the mouse (Gnome 3 or > XFCE desktops) up and down the image rolls up and down like a curtain. I > see no mouse cursor anymore and can't resume to normal operation. > > When this happens I see the following line in dmesg: > > [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO > underrun > > Hardware is still the first prototypes for Skylake, BIOS is beta too. > But I wanted to give a note about that problem here, maybe someone has > an idea what is missing. For brand new platforms you should be running drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel. Double check that you have either i915.preliminary_hw_support=1 module parameter set or CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=y config option set. BR, Jani. > > Regards > Rainer > -- > Dipl.-Inf. (FH) Rainer Koenig > Project Manager Linux Clients > Dept. PDG WPS R&D SW OSE > > Fujitsu Technology Solutions > Bürgermeister-Ullrich-Str. 100 > 86199 Augsburg > Germany > > Telephone: +49-821-804-3321 > Telefax: +49-821-804-2131 > Mail: mailto:Rainer.Koenig at ts.fujitsu.com > > Internet ts.fujtsu.com > Company Details ts.fujitsu.com/imprint.html > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center
[PATCH] drm: drop drm_property_unreference_blob_locked()
drm_property_unreference_blob_locked() is static and unused,
drop it.
Signed-off-by: Sergey Senozhatsky
---
drivers/gpu/drm/drm_crtc.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4059f06..6e60f71 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4313,25 +4313,6 @@ void drm_property_unreference_blob(struct
drm_property_blob *blob)
EXPORT_SYMBOL(drm_property_unreference_blob);
/**
- * drm_property_unreference_blob_locked - Unreference a blob property with
blob_lock held
- *
- * Drop a reference on a blob property. May free the object. This must be
- * called with blob_lock held.
- *
- * @param dev Device the blob was created on
- * @param blob Pointer to blob property
- */
-static void drm_property_unreference_blob_locked(struct drm_property_blob
*blob)
-{
- if (!blob)
- return;
-
- DRM_DEBUG("%p: blob ID: %d (%d)\n", blob, blob->base.id,
atomic_read(&blob->refcount.refcount));
-
- kref_put(&blob->refcount, drm_property_free_blob);
-}
-
-/**
* drm_property_reference_blob - Take a reference on an existing property
*
* Take a new reference on an existing blob property.
--
2.4.1.168.g1ea28e1
Experiencing FIFO underruns on Intel Skylake platform
Am 19.05.2015 um 13:41 schrieb Jani Nikula: > > For brand new platforms you should be running drm-intel-nightly branch > from http://cgit.freedesktop.org/drm-intel. Thanks, will try out next. > Double check that you have either i915.preliminary_hw_support=1 module > parameter set or CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=y config option > set. ACK. That option is set (otherwise the audio-driver wouldn't work. :-) Regards, Rainer -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Clients Dept. PDG WPS R&D SW OSE Fujitsu Technology Solutions Bürgermeister-Ullrich-Str. 100 86199 Augsburg Germany Telephone: +49-821-804-3321 Telefax: +49-821-804-2131 Mail: mailto:Rainer.Koenig at ts.fujitsu.com Internet ts.fujtsu.com Company Details ts.fujitsu.com/imprint.html
[PATCH] drm/nouveau/platform: add IOMMU dependency
The recently added iommu code in the nouveau driver fails to build
when the IOMMU support is disabled:
drivers/gpu/drm/nouveau/nouveau_platform.c: In function
'nouveau_platform_probe_iommu':
drivers/gpu/drm/nouveau/nouveau_platform.c:113:41: error: 'const struct
iommu_ops' has no mem
To avoid the build error, this now adds an explicit dependency on the
IOMMU implementation.
Signed-off-by: Arnd Bergmann
Fixes: 58fd9375c2c5 ("drm/nouveau/platform: probe IOMMU if present")
diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index 5ab13e7939db..18dfa4af60ea 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -28,6 +28,7 @@ config DRM_NOUVEAU
config NOUVEAU_PLATFORM_DRIVER
bool "Nouveau (NVIDIA) SoC GPUs"
depends on DRM_NOUVEAU && ARCH_TEGRA
+ depends on IOMMU
default y
help
Support for Nouveau platform driver, used for SoC GPUs as found
[PATCH] drm/nouveau/platform: add IOMMU dependency
On Tue, May 19, 2015 at 02:53:26PM +0200, Arnd Bergmann wrote:
> The recently added iommu code in the nouveau driver fails to build
> when the IOMMU support is disabled:
>
> drivers/gpu/drm/nouveau/nouveau_platform.c: In function
> 'nouveau_platform_probe_iommu':
> drivers/gpu/drm/nouveau/nouveau_platform.c:113:41: error: 'const struct
> iommu_ops' has no mem
>
> To avoid the build error, this now adds an explicit dependency on the
> IOMMU implementation.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 58fd9375c2c5 ("drm/nouveau/platform: probe IOMMU if present")
Acked-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/b896fe1c/attachment.sig>
drm/exynos: Add atomic modesetting support
Hello,
On 2015-05-18 23:02, Gustavo Padovan wrote:
> 2015-05-18 Daniel Stone :
>
>> Hi,
>>
>> On Monday, May 18, 2015, Gustavo Padovan wrote:
>>
>> > Hi Tobias,
>> >
>> > 2015-05-15 Tobias Jakobi >:
>> > > I did another run with drm.debug=0xff and also tried to figure out where
>> > the
>> > > div-by-zero comes from.
>> > >
>> > > The only division I see is in fimd_calc_clkdiv() (which is called by
>> > > fimd_commit()). So it looks like 'ideal_clk' is zero when calling
>> > > DIV_ROUND_UP().
>> > >
>> > > 'htotal' and 'vtotal' can't be zero, since this is checked early in
>> > > fimd_commit(). So 'vrefresh' has to be zero. Maybe this helps?
>> >
>> > What is is the output when you run with this patch:
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > index 12ab80c..f5d215d 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > @@ -310,6 +310,8 @@ static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
>> > unsigned long ideal_clk = mode->htotal * mode->vtotal *
>> > mode->vrefresh;
>> > u32 clkdiv;
>> >
>> > + DRM_DEBUG_KMS("vrefresh %d\n", mode->vrefresh);
>> > +
>> > if (ctx->i80_if) {
>> > /*
>> > * The frame done interrupt should be occurred prior to the
>> > @@ -328,6 +330,7 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc
>> > *crtc,
>> > const struct drm_display_mode *mode,
>> > struct drm_display_mode *adjusted_mode)
>> > {
>> > + DRM_DEBUG_KMS("vrefresh %d\n", adjusted_mode->vrefresh);
>> > if (adjusted_mode->vrefresh == 0)
>> > adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
>> >
>>
>> vrefresh can legitimately be zero, which makes this
>> FIMD_DEFAULT_FRAMERATE
>> assignment problematic rather than harmless.
>>
>> If it's zero, you can find a vrefresh value with drm_mode_vrefresh,
>> which
>> will calculate it for you.
>
> So better try this. Ideally fimd_mode_fixup should go away too, I'll do
> a proper
> patch once we know this works.
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 12ab80c..363353b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -307,9 +307,17 @@ static void fimd_iommu_detach_devices(struct
> fimd_context *ctx)
> static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
> const struct drm_display_mode *mode)
> {
> - unsigned long ideal_clk = mode->htotal * mode->vtotal *
> mode->vrefresh;
> + unsigned long ideal_clk;
> + int vrefresh;
> u32 clkdiv;
>
> + if (mode->vrefresh == 0)
> + vrefresh = drm_mode_vrefresh(mode);
> + else
> + vrefresh = mode->vrefresh;
> +
> + ideal_clk = mode->htotal * mode->vtotal * vrefresh;
> +
> if (ctx->i80_if) {
> /*
> * The frame done interrupt should be occurred prior to
> the
I've applied this and the debug output patch, but I still get a
div-by-zero.
With best wishes,
Tobias
kernel output:
[ 135.978266] [drm:drm_stub_open]
[ 135.978290] [drm:drm_open_helper] pid = 2650, minor = 0
[ 135.978308] [drm:ipp_subdrv_open] done priv[0xed983210]
[ 135.978324] [drm:drm_setup]
[ 135.978368] [drm:drm_ioctl] pid=2650, dev=0xe200, auth=1,
DRM_IOCTL_VERSION
[ 135.978387] [drm:drm_ioctl] pid=2650, dev=0xe200, auth=1,
DRM_IOCTL_VERSION
[ 135.978425] [drm:drm_release] open_count = 1
[ 135.978445] [drm:drm_release] pid = 2650, device = 0xe200, open_count
= 1
[ 135.978466] [drm:drm_lastclose]
[ 135.978506] [drm:drm_atomic_state_alloc] Allocate atomic state
ed3a4a40
[ 135.978524] [drm:drm_atomic_get_crtc_state] Added [CRTC:21] ee20d400
state to ed3a4a40
[ 135.978540] [drm:drm_atomic_get_plane_state] Added [PLANE:17]
ed3a4f80 state to ed3a4a40
[ 135.978552] [drm:drm_atomic_set_crtc_for_plane] Link plane state
ed3a4f80 to [NOCRTC]
[ 135.978563] [drm:drm_atomic_set_fb_for_plane] Set [NOFB] for plane
state ed3a4f80
[ 135.978577] [drm:drm_atomic_add_affected_connectors] Adding all
current connectors for [CRTC:21] to ed3a4a40
[ 135.978590] [drm:drm_atomic_check_only] checking ed3a4a40
[ 135.978607] [drm:drm_atomic_commit] commiting ed3a4a40
[ 135.978623] [drm:drm_atomic_state_clear] Clearing atomic state
ed3a4a40
[ 135.978639] [drm:drm_atomic_state_free] Freeing atomic state ed3a4a40
[ 135.978660] [drm:drm_atomic_state_alloc] Allocate atomic state
ed3a4a40
[ 135.978676] [drm:drm_atomic_get_crtc_state] Added [CRTC:29] ee20d800
state to ed3a4a40
[ 135.978690] [drm:drm_atomic_get_plane_state] Added [PLANE:24]
ed3a4ac0 state to ed3a4a40
[ 135.978702] [drm:drm_atomic_set_crtc_for_plane] Link plane state
ed3a4ac0 to [CRTC:29]
[ 135.978714] [drm:drm_framebuffer_reference] ee112240: FB ID: 40 (1)
[ 135.978725] [drm:drm
[PATCH] drm/amdkfd: fix topology bug with capability attr.
From: Alexey Skidanov This patch fixes a bug where the number of watch points was shown before it was actually calculated Signed-off-by: Alexey Skidanov Cc: stable at vger.kernel.org Signed-off-by: Oded Gabbay --- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c index e469c4b..c25728b 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c @@ -684,8 +684,6 @@ static ssize_t node_show(struct kobject *kobj, struct attribute *attr, dev->node_props.cpu_core_id_base); sysfs_show_32bit_prop(buffer, "simd_id_base", dev->node_props.simd_id_base); - sysfs_show_32bit_prop(buffer, "capability", - dev->node_props.capability); sysfs_show_32bit_prop(buffer, "max_waves_per_simd", dev->node_props.max_waves_per_simd); sysfs_show_32bit_prop(buffer, "lds_size_in_kb", @@ -736,6 +734,8 @@ static ssize_t node_show(struct kobject *kobj, struct attribute *attr, dev->gpu->kfd2kgd->get_fw_version( dev->gpu->kgd, KGD_ENGINE_MEC1)); + sysfs_show_32bit_prop(buffer, "capability", + dev->node_props.capability); } return sysfs_show_32bit_prop(buffer, "max_engine_clk_ccompute", -- 1.9.1
drm/exynos: Add atomic modesetting support
Hi Tobias,
On 19 May 2015 at 14:53, Tobias Jakobi wrote:
> On 2015-05-18 23:02, Gustavo Padovan wrote:
>> So better try this. Ideally fimd_mode_fixup should go away too, I'll do a
>> proper
>> patch once we know this works.
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 12ab80c..363353b 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -307,9 +307,17 @@ static void fimd_iommu_detach_devices(struct
>> fimd_context *ctx)
>> static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
>> const struct drm_display_mode *mode)
>> {
>> - unsigned long ideal_clk = mode->htotal * mode->vtotal *
>> mode->vrefresh;
>> + unsigned long ideal_clk;
>> + int vrefresh;
>> u32 clkdiv;
>>
>> + if (mode->vrefresh == 0)
>> + vrefresh = drm_mode_vrefresh(mode);
>> + else
>> + vrefresh = mode->vrefresh;
>> +
>> + ideal_clk = mode->htotal * mode->vtotal * vrefresh;
>> +
>> if (ctx->i80_if) {
>> /*
>> * The frame done interrupt should be occurred prior to
>> the
>
> I've applied this and the debug output patch, but I still get a div-by-zero.
Can you please add a drm_mode_debug_printmodeline(mode) and give the
output there?
Cheers,
Daniel
[PULL] topic/drm-misc
Hi Dave, Scattering of random drm core patches. Bunch of atomic prep work too, but the final bits for blob properties, atomic modesets and lifting the experimental tag on the atomic ioctl are still blocked on Daniel Stone finalizing and testing the weston support for it. I hope that we can get it all ready for 4.2 though. Cheers, Daniel The following changes since commit c0fe07aa50befe2e6e6525181e2080377a1c1494: drm/qxl: rewrite framebuffer support (2015-05-07 13:09:25 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-05-19 for you to fetch changes up to 036ef5733ba433760a3512bb5f7a155946e2df05: drm/atomic: Allow drivers to subclass drm_atomic_state, v3 (2015-05-18 16:39:41 +0200) Daniel Stone (5): drm/atomic: Don't open-code CRTC state destroy drm: Don't leak path blob property when updating drm: Introduce helper for replacing blob properties drm: Introduce blob_lock drm: Add reference counting to blob properties Daniel Vetter (2): drm/atomic-helpers: Update vblank timestamping constants drm/atomic-helpers: Export drm_atomic_helper_update_legacy_modeset_state Gustavo Padovan (1): drm/atomic: remove duplicated assignment of old_plane_state Jani Nikula (4): drm/sysfs: add a helper for extracting connector type from kobject drm/sysfs: make optional attribute groups per connector type drm/sysfs: split DVI-I and TV-out attributes drm/sysfs: remove unnecessary connector type checks Jon Hunter (1): drm/dp: Fix comment in DP helper Maarten Lankhorst (4): drm/i915: get rid of -Iinclude/drm drm/core: get rid of -Iinclude/drm drm/atomic: add drm_atomic_get_existing_*_state helpers drm/atomic: Allow drivers to subclass drm_atomic_state, v3 Tomasz Figa (1): drm/prime: Allow internal imports without import_sg_table Ville Syrjälä (4): drm/edid: Fix up DMT modes drm/edid: Add the DMT ID in the comments drm/edid: Add DMT modes with ID > 0x50 drm/edid: Add CEA modes before inferred modes drivers/gpu/drm/Makefile| 2 - drivers/gpu/drm/drm_atomic.c| 134 + drivers/gpu/drm/drm_atomic_helper.c | 29 ++- drivers/gpu/drm/drm_crtc.c | 325 ++-- drivers/gpu/drm/drm_crtc_helper.c | 7 +- drivers/gpu/drm/drm_edid.c | 206 +++- drivers/gpu/drm/drm_flip_work.c | 4 +- drivers/gpu/drm/drm_prime.c | 6 +- drivers/gpu/drm/drm_sysfs.c | 160 ++-- drivers/gpu/drm/i915/Makefile | 2 - drivers/gpu/drm/i915/i915_gem_userptr.c | 4 +- include/drm/drm_atomic.h| 55 ++ include/drm/drm_atomic_helper.h | 4 + include/drm/drm_crtc.h | 26 ++- include/drm/drm_dp_helper.h | 6 +- 15 files changed, 696 insertions(+), 274 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[GIT PULL] exynos-drm-fixes
Hi Dave, This pull request contains mainly some regression fixups and code cleanups. Summary: - Use generic function to get buffer count instead of specific one. In case of Exynos DRM, There was a special case which decides pixel format of a given buffer according to planer types, which is NV12M and NV12. However, NV12M doesn't exist in drm fourcc so it removes exynos_drm_format_num_buffers() specific to Exynos DRM and use a generic function, drm_format_num_planes() instead. - Allow mixer driver to support NV21 format for Video processor. This format was already supported but we just missed DRM_FORMAT_NV21 case so this patch considers the case so that Mixer driver can handle it correctly. - Add regression fix and some code cleanups. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 64d237e66d562348f04a9c04a45455c1f3201ced: Merge branch 'msm-fixes-4.1' of git://people.freedesktop.org/~robclark/linux into drm-fixes (2015-05-19 10:17:34 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git exynos-drm-fixes for you to fetch changes up to b0f155ada4c819f06aa32b4c906e7e76350c7ec1: drm/exynos: dp: Lower level of EDID read success message (2015-05-19 22:50:55 +0900) Krzysztof Kozlowski (5): drm/exynos: mixer: Constify platform_device_id drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD drm/exynos: Constify exynos_drm_crtc_ops drm/exynos: Consolidate return statements in fimd_bind() drm/exynos: dp: Lower level of EDID read success message Tobias Jakobi (8): drm/exynos: fb: use drm_format_num_planes to get buffer count drm/exynos: plane: honor buffer offset for dma_addr drm/exynos: mixer: remove buffer count handling in vp_video_buffer() drm/exynos: mixer: also allow NV21 for the video processor drm/exynos: mixer: cleanup pixelformat handling drm/exynos: mixer: don't dump registers under spinlock drm/exynos: 'win' is always unsigned drm/exynos: cleanup exynos_drm_plane drivers/gpu/drm/exynos/exynos7_drm_decon.c |4 +- drivers/gpu/drm/exynos/exynos_dp_core.c| 13 +++-- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 10 ++-- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 10 ++-- drivers/gpu/drm/exynos/exynos_drm_drv.h| 20 +++- drivers/gpu/drm/exynos/exynos_drm_fb.c | 39 +-- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 53 ++-- drivers/gpu/drm/exynos/exynos_drm_fimd.h | 15 -- drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 +- drivers/gpu/drm/exynos/exynos_mixer.c | 72 +++- 11 files changed, 92 insertions(+), 148 deletions(-) delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd.h
[PATCH] drm/imx: parallel-display: fix drm_panel support
The parallel-display driver used an undocumented, non-standard property
"fsl,panel" to optionally associate with a drm_panel device. This patch
fixes the driver to use the same OF graph bindings as the LDB driver
instead:
parallel-display {
compatible = "fsl,imx-parallel-display";
...
port at 1 {
reg = <1>;
parallel_out: endpoint {
remote_endpoint = <&panel_in>;
};
};
};
panel {
...
port {
panel_in: endpoint {
remote-endpoint = <¶llel_out>;
};
};
};
Signed-off-by: Philipp Zabel
---
.../devicetree/bindings/drm/imx/fsl-imx-drm.txt| 26 --
drivers/gpu/drm/imx/parallel-display.c | 21 -
2 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/imx/fsl-imx-drm.txt
b/Documentation/devicetree/bindings/drm/imx/fsl-imx-drm.txt
index f349703..29c0467 100644
--- a/Documentation/devicetree/bindings/drm/imx/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/drm/imx/fsl-imx-drm.txt
@@ -65,8 +65,10 @@ Optional properties:
- edid: verbatim EDID data block describing attached display.
- ddc: phandle describing the i2c bus handling the display data
channel
-- port: A port node with endpoint definitions as defined in
+- port@[0-1]: Port nodes with endpoint definitions as defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
+ Port 0 is the input port connected to the IPU display interface,
+ port 1 is the output port connected to a panel.
example:
@@ -75,9 +77,29 @@ display at di0 {
edid = [edid-data];
interface-pix-fmt = "rgb24";
- port {
+ port at 0 {
+ reg = <0>;
+
display_in: endpoint {
remote-endpoint = <&ipu_di0_disp0>;
};
};
+
+ port at 1 {
+ reg = <1>;
+
+ display_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+};
+
+panel {
+ ...
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
};
diff --git a/drivers/gpu/drm/imx/parallel-display.c
b/drivers/gpu/drm/imx/parallel-display.c
index 78db5d4..c663099 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "imx-drm.h"
@@ -216,7 +217,7 @@ static int imx_pd_bind(struct device *dev, struct device
*master, void *data)
{
struct drm_device *drm = data;
struct device_node *np = dev->of_node;
- struct device_node *panel_node;
+ struct device_node *port;
const u8 *edidp;
struct imx_parallel_display *imxpd;
int ret;
@@ -245,11 +246,19 @@ static int imx_pd_bind(struct device *dev, struct device
*master, void *data)
imxpd->interface_pix_fmt = V4L2_PIX_FMT_BGR24;
}
- panel_node = of_parse_phandle(np, "fsl,panel", 0);
- if (panel_node) {
- imxpd->panel = of_drm_find_panel(panel_node);
- if (!imxpd->panel)
- return -EPROBE_DEFER;
+ /* port at 1 is the output port */
+ port = of_graph_get_port_by_id(np, 1);
+ if (port) {
+ struct device_node *endpoint, *remote;
+
+ endpoint = of_get_child_by_name(port, "endpoint");
+ if (endpoint) {
+ remote = of_graph_get_remote_port_parent(endpoint);
+ if (remote)
+ imxpd->panel = of_drm_find_panel(remote);
+ if (!imxpd->panel)
+ return -EPROBE_DEFER;
+ }
}
imxpd->dev = dev;
--
2.1.4
[PATCH v2 0/3] drm_of_encoder_active_endpoint helpers
Hi, this patch factors out the mostly identical imx_drm_encoder_get_mux_id and rockchip_drm_encoder_get_mux_id functions into a common helper to parse the active endpoint and two inline functions to return its id or port id. All prerequisites are now upstream. I'd like to get an Acked-by from the Rockchip developers and then to queue this series through imx-drm. Changes since v1: - Added missing struct drm_encoder declaration to drm_of.h - Rebased onto v4.1-rc2 regards Philipp Philipp Zabel (3): drm: add drm_of_encoder_active_endpoint helpers drm/imx: remove imx_drm_encoder_get_mux_id drm/rockchip: remove rockchip_drm_encoder_get_mux_id drivers/gpu/drm/drm_of.c| 34 + drivers/gpu/drm/imx/dw_hdmi-imx.c | 2 +- drivers/gpu/drm/imx/imx-drm-core.c | 30 - drivers/gpu/drm/imx/imx-drm.h | 2 -- drivers/gpu/drm/imx/imx-ldb.c | 4 ++-- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 30 - drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 -- include/drm/drm_of.h| 33 9 files changed, 71 insertions(+), 68 deletions(-) -- 2.1.4
[PATCH v2 3/3] drm/rockchip: remove rockchip_drm_encoder_get_mux_id
It is replaced by drm_of_encoder_active_endpoint_id.
Suggested-by: Daniel Kurtz
Reviewed-by: Daniel Kurtz
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 30 -
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 --
3 files changed, 1 insertion(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 80d6fc8..042eb95 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -201,7 +201,7 @@ static void dw_hdmi_rockchip_encoder_commit(struct
drm_encoder *encoder)
u32 val;
int mux;
- mux = rockchip_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
+ mux = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
if (mux)
val = HDMI_SEL_VOP_LIT | (HDMI_SEL_VOP_LIT << 16);
else
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 3962176..bc2bb3b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -378,36 +378,6 @@ static const struct dev_pm_ops rockchip_drm_pm_ops = {
rockchip_drm_sys_resume)
};
-/*
- * @node: device tree node containing encoder input ports
- * @encoder: drm_encoder
- */
-int rockchip_drm_encoder_get_mux_id(struct device_node *node,
- struct drm_encoder *encoder)
-{
- struct device_node *ep;
- struct drm_crtc *crtc = encoder->crtc;
- struct of_endpoint endpoint;
- struct device_node *port;
- int ret;
-
- if (!node || !crtc)
- return -EINVAL;
-
- for_each_endpoint_of_node(node, ep) {
- port = of_graph_get_remote_port(ep);
- of_node_put(port);
- if (port == crtc->port) {
- ret = of_graph_parse_endpoint(ep, &endpoint);
- of_node_put(ep);
- return ret ?: endpoint.id;
- }
- }
-
- return -EINVAL;
-}
-EXPORT_SYMBOL_GPL(rockchip_drm_encoder_get_mux_id);
-
static int compare_of(struct device *dev, void *data)
{
struct device_node *np = data;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index dc4e5f0..20d6ac1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -56,8 +56,6 @@ int rockchip_register_crtc_funcs(struct drm_device *dev,
const struct rockchip_crtc_funcs *crtc_funcs,
int pipe);
void rockchip_unregister_crtc_funcs(struct drm_device *dev, int pipe);
-int rockchip_drm_encoder_get_mux_id(struct device_node *node,
- struct drm_encoder *encoder);
int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
int out_mode);
int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
--
2.1.4
[PATCH v2 1/3] drm: add drm_of_encoder_active_endpoint helpers
This patch adds a helper to parse the encoder endpoint connected to the
encoder's crtc and two helpers to return its id and port id.
This can be used to determine input mux setting from endpoint or port ids.
Suggested-by: Daniel Kurtz
Reviewed-by: Daniel Kurtz
Signed-off-by: Philipp Zabel
---
Changes since v1:
- Added missing struct drm_encoder declaration to drm_of.h
---
drivers/gpu/drm/drm_of.c | 34 ++
include/drm/drm_of.h | 33 +
2 files changed, 67 insertions(+)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index aaa1307..a526301 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -61,3 +61,37 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
return possible_crtcs;
}
EXPORT_SYMBOL(drm_of_find_possible_crtcs);
+
+/*
+ * drm_of_encoder_active_endpoint - return the active encoder endpoint
+ * @node: device tree node containing encoder input ports
+ * @encoder: drm_encoder
+ *
+ * Given an encoder device node and a drm_encoder with a connected crtc,
+ * parse the encoder endpoint connecting to the crtc port.
+ */
+int drm_of_encoder_active_endpoint(struct device_node *node,
+ struct drm_encoder *encoder,
+ struct of_endpoint *endpoint)
+{
+ struct device_node *ep;
+ struct drm_crtc *crtc = encoder->crtc;
+ struct device_node *port;
+ int ret;
+
+ if (!node || !crtc)
+ return -EINVAL;
+
+ for_each_endpoint_of_node(node, ep) {
+ port = of_graph_get_remote_port(ep);
+ of_node_put(port);
+ if (port == crtc->port) {
+ ret = of_graph_parse_endpoint(ep, endpoint);
+ of_node_put(ep);
+ return ret;
+ }
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 2441f71..efd3b44 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -1,18 +1,51 @@
#ifndef __DRM_OF_H__
#define __DRM_OF_H__
+#include
+
struct drm_device;
+struct drm_encoder;
struct device_node;
#ifdef CONFIG_OF
extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
struct device_node *port);
+extern int drm_of_encoder_active_endpoint(struct device_node *node,
+ struct drm_encoder *encoder,
+ struct of_endpoint *endpoint);
#else
static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
struct device_node *port)
{
return 0;
}
+
+static inline int drm_of_encoder_active_endpoint(struct device_node *node,
+struct drm_encoder *encoder,
+struct of_endpoint *endpoint)
+{
+ return -EINVAL;
+}
#endif
+static inline int drm_of_encoder_active_endpoint_id(struct device_node *node,
+ struct drm_encoder *encoder)
+{
+ struct of_endpoint endpoint;
+ int ret = drm_of_encoder_active_endpoint(node, encoder,
+&endpoint);
+
+ return ret ?: endpoint.id;
+}
+
+static inline int drm_of_encoder_active_port_id(struct device_node *node,
+ struct drm_encoder *encoder)
+{
+ struct of_endpoint endpoint;
+ int ret = drm_of_encoder_active_endpoint(node, encoder,
+&endpoint);
+
+ return ret ?: endpoint.port;
+}
+
#endif /* __DRM_OF_H__ */
--
2.1.4
[PATCH v2 2/3] drm/imx: remove imx_drm_encoder_get_mux_id
It is replaced by drm_of_encoder_active_port_id.
Suggested-by: Daniel Kurtz
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 2 +-
drivers/gpu/drm/imx/imx-drm-core.c | 30 --
drivers/gpu/drm/imx/imx-drm.h | 2 --
drivers/gpu/drm/imx/imx-ldb.c | 4 ++--
4 files changed, 3 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index a3ecf10..aefa63b 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -114,7 +114,7 @@ static void dw_hdmi_imx_encoder_mode_set(struct drm_encoder
*encoder,
static void dw_hdmi_imx_encoder_commit(struct drm_encoder *encoder)
{
struct imx_hdmi *hdmi = container_of(encoder, struct imx_hdmi, encoder);
- int mux = imx_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
+ int mux = drm_of_encoder_active_port_id(hdmi->dev->of_node, encoder);
regmap_update_bits(hdmi->regmap, IOMUXC_GPR3,
IMX6Q_GPR3_HDMI_MUX_CTL_MASK,
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 74f505b..8f85585 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -431,36 +431,6 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
}
EXPORT_SYMBOL_GPL(imx_drm_encoder_parse_of);
-/*
- * @node: device tree node containing encoder input ports
- * @encoder: drm_encoder
- */
-int imx_drm_encoder_get_mux_id(struct device_node *node,
- struct drm_encoder *encoder)
-{
- struct imx_drm_crtc *imx_crtc = imx_drm_find_crtc(encoder->crtc);
- struct device_node *ep;
- struct of_endpoint endpoint;
- struct device_node *port;
- int ret;
-
- if (!node || !imx_crtc)
- return -EINVAL;
-
- for_each_endpoint_of_node(node, ep) {
- port = of_graph_get_remote_port(ep);
- of_node_put(port);
- if (port == imx_crtc->crtc->port) {
- ret = of_graph_parse_endpoint(ep, &endpoint);
- of_node_put(ep);
- return ret ? ret : endpoint.port;
- }
- }
-
- return -EINVAL;
-}
-EXPORT_SYMBOL_GPL(imx_drm_encoder_get_mux_id);
-
static const struct drm_ioctl_desc imx_drm_ioctls[] = {
/* none so far */
};
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index 28e776d..10ed4e1 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -45,8 +45,6 @@ int imx_drm_set_bus_format_pins(struct drm_encoder *encoder,
int imx_drm_set_bus_format(struct drm_encoder *encoder,
u32 bus_format);
-int imx_drm_encoder_get_mux_id(struct device_node *node,
- struct drm_encoder *encoder);
int imx_drm_encoder_parse_of(struct drm_device *drm,
struct drm_encoder *encoder, struct device_node *np);
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index abacc8f..6988f23 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -215,7 +215,7 @@ static void imx_ldb_encoder_commit(struct drm_encoder
*encoder)
struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
struct imx_ldb *ldb = imx_ldb_ch->ldb;
int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
- int mux = imx_drm_encoder_get_mux_id(imx_ldb_ch->child, encoder);
+ int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
drm_panel_prepare(imx_ldb_ch->panel);
@@ -265,7 +265,7 @@ static void imx_ldb_encoder_mode_set(struct drm_encoder
*encoder,
int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
unsigned long serial_clk;
unsigned long di_clk = mode->clock * 1000;
- int mux = imx_drm_encoder_get_mux_id(imx_ldb_ch->child, encoder);
+ int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
if (mode->clock > 17) {
dev_warn(ldb->dev,
--
2.1.4
[PATCH 2/3] drm/atomic: add drm_atomic_add_affected_planes
This is a convenience function to add all planes for a crtc,
similar to add_affected_connectors. This will be used in
drm_atomic_helper_check_modeset, but drivers can call it too
when they need to recalculate all state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 32
include/drm/drm_atomic.h | 4
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index cd1b16b25716..c48b7db438b8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -956,6 +956,38 @@ drm_atomic_add_affected_connectors(struct drm_atomic_state
*state,
EXPORT_SYMBOL(drm_atomic_add_affected_connectors);
/**
+ * drm_atomic_add_affected_planes - add planes for crtc
+ * @state: atomic state
+ * @crtc: DRM crtc
+ *
+ * This function walks the current configuration and adds all planes
+ * currently used by @crtc to the atomic configuration @state.
+ *
+ * Returns:
+ * 0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK
+ * then the w/w mutex code has detected a deadlock and the entire atomic
+ * sequence must be restarted. All other errors are fatal.
+ */
+int
+drm_atomic_add_affected_planes(struct drm_atomic_state *state,
+ struct drm_crtc *crtc)
+{
+ struct drm_plane *plane;
+
+ WARN_ON(!drm_atomic_get_existing_crtc_state(state, crtc));
+
+ drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) {
+ struct drm_plane_state *plane_state =
+ drm_atomic_get_plane_state(state, plane);
+
+ if (IS_ERR(plane_state))
+ return PTR_ERR(plane_state);
+ }
+ return 0;
+}
+EXPORT_SYMBOL(drm_atomic_add_affected_planes);
+
+/**
* drm_atomic_connectors_for_crtc - count number of connected outputs
* @state: atomic state
* @crtc: DRM crtc
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index f0d3a7387d99..e89db0c377ba 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -120,6 +120,10 @@ drm_atomic_set_crtc_for_connector(struct
drm_connector_state *conn_state,
int __must_check
drm_atomic_add_affected_connectors(struct drm_atomic_state *state,
struct drm_crtc *crtc);
+int __must_check
+drm_atomic_add_affected_planes(struct drm_atomic_state *state,
+ struct drm_crtc *crtc);
+
int
drm_atomic_connectors_for_crtc(struct drm_atomic_state *state,
struct drm_crtc *crtc);
--
2.1.0
[PATCH 3/3] drm/atomic: add all affected planes in drm_atomic_helper_check_modeset
Drivers may need to recalculate plane state when a modeset occurs, not reliably adding them might cause hard to debug bugs. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 2da8a16bb39e..4f5a427e9405 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -429,6 +429,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev, if (ret != 0) return ret; + ret = drm_atomic_add_affected_planes(state, crtc); + if (ret != 0) + return ret; + num_connectors = drm_atomic_connectors_for_crtc(state, crtc); -- 2.1.0
[PATCH 1/3] drm/atomic: add commit_planes_on_crtc helper
drm_atomic_helper_commit_planes calls all atomic_begin's first,
then updates all planes, finally calling atomic_flush.
Some drivers may want to things like disabling irq's
from their atomic_begin, in which case a second call to atomic_begin
will splat. By using commit_planes_on_crtc on each crtc in the
atomic state they'll evade that issue.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 53 +
include/drm/drm_atomic_helper.h | 1 +
2 files changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index b82ef6262469..2da8a16bb39e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1181,6 +1181,59 @@ void drm_atomic_helper_commit_planes(struct drm_device
*dev,
EXPORT_SYMBOL(drm_atomic_helper_commit_planes);
/**
+ * drm_atomic_helper_commit_planes_on_crtc - commit plane state for a crtc
+ * @old_crtc_state: atomic state object with the old crtc state
+ *
+ * This function commits the new plane state using the plane and atomic helper
+ * functions for planes on the specific crtc. It assumes that the atomic state
+ * has already been pushed into the relevant object state pointers, since this
+ * step can no longer fail.
+ *
+ * This function can only be used when planes are not allowed to move between
+ * different crtc's.
+ */
+void
+drm_atomic_helper_commit_planes_on_crtc(struct drm_crtc_state *old_crtc_state)
+{
+ const struct drm_crtc_helper_funcs *crtc_funcs;
+ struct drm_crtc *crtc = old_crtc_state->crtc;
+ struct drm_atomic_state *old_state = old_crtc_state->state;
+ struct drm_plane *plane;
+ unsigned plane_mask;
+
+ plane_mask = old_crtc_state->plane_mask;
+ plane_mask |= crtc->state->plane_mask;
+
+ crtc_funcs = crtc->helper_private;
+ if (crtc_funcs && crtc_funcs->atomic_begin)
+ crtc_funcs->atomic_begin(crtc);
+
+ drm_for_each_plane_mask(plane, crtc->dev, plane_mask) {
+ struct drm_plane_state *old_plane_state =
+ drm_atomic_get_existing_plane_state(old_state, plane);
+ const struct drm_plane_helper_funcs *plane_funcs;
+
+ plane_funcs = plane->helper_private;
+
+ if (!old_plane_state || !plane_funcs)
+ continue;
+
+ WARN_ON(plane->state->crtc && plane->state->crtc != crtc);
+
+ if (drm_atomic_plane_disabling(plane, old_plane_state) &&
+ plane_funcs->atomic_disable)
+ plane_funcs->atomic_disable(plane, old_plane_state);
+ else if (plane->state->crtc ||
+drm_atomic_plane_disabling(plane, old_plane_state))
+ plane_funcs->atomic_update(plane, old_plane_state);
+ }
+
+ if (crtc_funcs->atomic_flush)
+ crtc_funcs->atomic_flush(crtc);
+}
+EXPORT_SYMBOL(drm_atomic_helper_commit_planes_on_crtc);
+
+/**
* drm_atomic_helper_cleanup_planes - cleanup plane resources after commit
* @dev: DRM device
* @old_state: atomic state object with old state structures
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 6ee0ee5b6143..cc1fee8a12d0 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -58,6 +58,7 @@ void drm_atomic_helper_commit_planes(struct drm_device *dev,
struct drm_atomic_state *state);
void drm_atomic_helper_cleanup_planes(struct drm_device *dev,
struct drm_atomic_state *old_state);
+void drm_atomic_helper_commit_planes_on_crtc(struct drm_crtc_state
*old_crtc_state);
void drm_atomic_helper_swap_state(struct drm_device *dev,
struct drm_atomic_state *state);
--
2.1.0
drm/exynos: Add atomic modesetting support
Hey Daniel,
On 2015-05-19 16:06, Daniel Stone wrote:
> Hi Tobias,
>
> On 19 May 2015 at 14:53, Tobias Jakobi
> wrote:
>> On 2015-05-18 23:02, Gustavo Padovan wrote:
>>> So better try this. Ideally fimd_mode_fixup should go away too, I'll
>>> do a
>>> proper
>>> patch once we know this works.
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 12ab80c..363353b 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -307,9 +307,17 @@ static void fimd_iommu_detach_devices(struct
>>> fimd_context *ctx)
>>> static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
>>> const struct drm_display_mode *mode)
>>> {
>>> - unsigned long ideal_clk = mode->htotal * mode->vtotal *
>>> mode->vrefresh;
>>> + unsigned long ideal_clk;
>>> + int vrefresh;
>>> u32 clkdiv;
>>>
>>> + if (mode->vrefresh == 0)
>>> + vrefresh = drm_mode_vrefresh(mode);
>>> + else
>>> + vrefresh = mode->vrefresh;
>>> +
>>> + ideal_clk = mode->htotal * mode->vtotal * vrefresh;
>>> +
>>> if (ctx->i80_if) {
>>> /*
>>> * The frame done interrupt should be occurred prior
>>> to
>>> the
>>
>> I've applied this and the debug output patch, but I still get a
>> div-by-zero.
>
> Can you please add a drm_mode_debug_printmodeline(mode) and give the
> output there?
I've also added printk for ideal_clk, here's the output.
kernel output:
[ 81.204682] [drm:fimd_calc_clkdiv] vrefresh 0
[ 81.204700] [drm:drm_mode_debug_printmodeline] Modeline 0:"1366x768"
0 500 1366 1414 1446 1526 768 771 776 790 0x48 0x5
[ 81.204710] [drm:fimd_calc_clkdiv] ideal_clk 0
So vrefresh remains zero after all.
With best wishes,
Tobias
>
> Cheers,
> Daniel
[RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU
On Fri, May 15, 2015 at 02:07:29AM +0100, Robert Bragg wrote: > On Fri, May 8, 2015 at 5:24 PM, Peter Zijlstra > wrote: > > On Thu, May 07, 2015 at 03:15:43PM +0100, Robert Bragg wrote: > > > >> I've changed the uapi for configuring the i915_oa specific attributes > >> when calling perf_event_open(2) whereby instead of cramming lots of > >> bitfields into the perf_event_attr config members, I'm now > >> daisy-chaining a drm_i915_oa_event_attr_t structure off of a single > >> config member that's extensible and validated in the same way as the > >> perf_event_attr struct. I've found this much nicer to work with while > >> being neatly extensible too. > > > > This worries me a bit.. is there more background for this? > > Would it maybe be helpful to see the before and after? I had kept this > uapi change in a separate patch for a while locally but in the end > decided to squash it before sending out my updated series. > > Although I did find it a bit awkward with the bitfields, I was mainly > concerned about the extensibility of packing logically separate > attributes into the config members and had heard similar concerns from > a few others who had been experimenting with my patches too. > > A few simple attributes I can think of a.t.m that we might want to add > in the future are: > - control of the OABUFFER size > - a way to ask the kernel to collect reports at the beginning and end > of batch buffers, in addition to periodic reports > - alternative ways to uniquely identify a context to support tools > profiling a single context not necessarily owned by the current > process > > It could also be interesting to expose some counter configuration > through these attributes too. E.g. on Broadwell+ we have 14 'Flexible > EU' counters included in the OA unit reports, each with a 16bit > configuration. > > In a more extreme case it might also be useful to allow userspace to > specify a complete counter config, which (depending on the > configuration) could be over 100 32bit values to select the counter > signals + configure the corresponding combining logic. > > Since this pmu is in a device driver it also seemed reasonably > appropriate to de-couple it slightly from the core perf_event_attr > structure by allowing driver extensible attributes. > > I wonder if it might be less worrisome if the i915_oa_copy_attr() code > were instead a re-usable utility perhaps maintained in events/core.c, > so if other pmu drivers were to follow suite there would be less risk > of a mistake being made here? So I had a peek at: https://01.org/sites/default/files/documentation/observability_performance_counters_haswell.pdf In an attempt to inform myself of how the hardware worked. But the document is rather sparse (and does not include broadwell). So from what I can gather there's two ways to observe the counters, through MMIO or trough the ring-buffer, which in turn seems triggered by a MI_REPORT_PERF_COUNT command. [ Now the document talks about shortcomings of this scheme, where the MI_REPORT_PERF_COUNT command can only be placed every other command, but a single command can contain so much computation that this is not fine grained enough -- leading to the suggestion of a timer/cycle based reporting, but that is not actually mentioned afaict ] Now the MI_REPORT_PERF_COUNT can select a vector (Counter Select) of which events it will write out. This covers the regular 'A' counters. Is this correct? Then there are the 'B' counters, which appear to be programmable through the CEC MMIO registers. These B events can also be part of the MI_REPORT_PERF_COUNT vector. Right? So for me the 'natural' way to represent this in perf would be through event groups. Create a perf event for every single event -- yes this is 53 events. Use the MMIO reads for the regular read() interface, and use a hrtimer placing MI_REPORT_PERF_COUNT commands, with a counter select mask covering the all events in the current group, for sampling. Then obtain the vector values using PERF_SAMPLE_READ and PERF_FORMAT_READ -- and use the read txn support to consume the ring-buffer vectors instead of the MMIO registers. You can use the perf_event_attr::config to select the counter (A0-A44, B0-B7) and use perf_event_attr::config1 (low and high dword) for the corresponding CEC registers. This does not require random per driver ABI extentions for perf_event_attr, nor your custom output format. Am I missing something obvious here?
[PATCH] drm/msm: use devm_gpiod_get_optional for optional reset gpio
On Tue, May 19, 2015 at 9:40 AM, Uwe Kleine-König
wrote:
> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
> which appeared in v3.17-rc1, the gpiod_get* functions take an additional
> parameter that allows to specify direction and initial value for output.
>
> Also there is a variant to find optional gpios that returns NULL if
> there is no gpio instead of -ENOENT.
>
> Make use of both features to simplify the driver.
>
> This makes error checking more strict because errors like -ENOSYS ("no
> gpio support compiled in") or -EPROBE_DEFER ("gpio not ready yet") are
> handled correctly now.
>
> Furthermore this is one caller less that stops us making the flags
> argument to gpiod_get*() mandatory.
>
> Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
I'd recommend dropping this Fixes:
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
[PATCH v3 1/2] drm: bridge: Allow daisy chaining of bridges
On Tue, May 19, 2015 at 04:37:44PM +0530, Archit Taneja wrote:
> On 05/19/2015 03:04 PM, Daniel Vetter wrote:
> >On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote:
> >>+void drm_bridge_post_disable(struct drm_bridge *bridge)
> >>+{
> >>+ if (!bridge)
> >>+ return;
> >>+
> >>+ drm_bridge_post_disable(bridge->next);
> >>+
> >>+ bridge->funcs->post_disable(bridge);
> >
> >For symmetry I'd call the post_disable hook for the next brigde _after_
> >this one. Otherwise we break abstraction. E.g. with 1 bridge we'd have
> >
> >bridgeA_disable();
> >encoder_disable();
> >bridgeA_post_disable();
> >
> >But if on some other part bridge A is connected to bridge B (i.e. we
> >replace the encoder with a combo of other_encoder+bridgeA) with your code
> >the post_disable is suddenly interleaved with the preceeding stages in the
> >pipeline:
> >
> >
> >bridgeA_disable();
> >bridgeB_disable();
> >other_encoder_disable();
> >bridgeA_post_disable();
> >bridgeB_post_disable();
> >
> >Which means from the pov of bridgeA there's a difference between whether
> >it's connected to "encoder" or "other_encoder+bridgeB". But if we reorder
> >the post_disable sequence like I suggest we'll get:
> >
> >bridgeA_disable();
> >bridgeB_disable();
> >other_encoder_disable();
> >bridgeB_post_disable();
> >bridgeA_post_disable();
> >
> >Which means that "encoder" and "other_encoder+bridgeB" look the same for
> >bridgeA. To avoid confusion the two pipelines in hw are:
> >
> >encoder ---> bridgeA
> >
> >other_encoder ---> bridgeB ---> bridgeA
>
> I agree with this, thanks for the explanation. Although, I'm not sure about
> the pre_enable part below.
>
>
>
> >>+void drm_bridge_pre_enable(struct drm_bridge *bridge)
> >>+{
> >>+ if (!bridge)
> >>+ return;
> >>+
> >>+ bridge->funcs->pre_enable(bridge);
> >>+
> >>+ drm_bridge_pre_enable(bridge->next);
> >
> >Same as with post_disable, pre_enable for bridge->next should be called
> >_before_ the pre_enable for this bridge.
>
>
> The order of nesting suggested by you gives the sequence:
>
> bridgeA_pre_enable();
> bridgeB_pre_enable();
> other_encoder_enable();
> bridgeB_enable();
> bridgeA_enable();
>
> This won't work if the bridge A relies on bridge B to be enabled first. This
> happens in the encoder path I'm working on:
>
> msm mdp5 encoder -> dsi bridge -> adv7511 dsi to hdmi bridge chip
>
>
> The adv chip relies on dsi's clock for it to function. If dsi's pre_enable()
> isn't called first, then adv's pre_enable would fail.
If you need the clock, then imo that's code which should be in the enable
hook, and not in the pre-enable hook. At least thus far the rules have
roughly been:
- pre_enable: anything that needs to be done _before_ clock+timings are
enabled by the source for this bridge.
- enable: anything that needs clock+timings to be on from the source for
this bridge.
Similar for the disable side:
- disable still has clocks+timing on.
- post_disable should be called after clocks are off.
In i915 we once had a callback in between clock enabling and timing
enabling, but we've removed that again after some restructuring. Maybe we
need such a hook bridges? But that also means we need to split up
encoder/crtc callbacks, and that will get nasty real fast.
> We could modify the call order in drm_bridge_enable() instead to achieve:
>
> bridgeB_pre_enable();
> bridgeA_pre_enable();
> other_encoder_enable();
> bridgeA_enable();
> bridgeB_enable();
>
> This fixes the sequence for pre_enable() calls, but assumes that the
> configurations in the enable() don't need to follow a specific sequence to
> ensure proper behavior.
>
> pre_enable() should ideally represent things to be done before we enable the
> next encoder in the chain. So the sequence right above seems to be better.
Nah, that's even more backwards imo. From bridgeA's pov it really should
make no difference at all whether the input is directly from an encoder or
whether it's "other_encoder+bridgeB". If we leak this detail down the
bridge chain, then the abstraction is leaky and bridge drivers will be
impossible to be reused.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 6/7] drm: add RGB formats with separate alpha plane
Some hardware can read the alpha components separately and then
conditionally fetch color components only for non-zero alpha values.
This patch adds fourcc definitions for two-plane RGB formats with an
8-bit alpha channel on a second plane.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/drm_crtc.c| 35 +++
include/uapi/drm/drm_fourcc.h | 14 ++
2 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3007b44..2ac0d7c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3245,6 +3245,14 @@ static int format_check(const struct drm_mode_fb_cmd2 *r)
case DRM_FORMAT_YVU422:
case DRM_FORMAT_YUV444:
case DRM_FORMAT_YVU444:
+ case DRM_FORMAT_XRGB_A8:
+ case DRM_FORMAT_XBGR_A8:
+ case DRM_FORMAT_RGBX_A8:
+ case DRM_FORMAT_BGRX_A8:
+ case DRM_FORMAT_RGB888_A8:
+ case DRM_FORMAT_BGR888_A8:
+ case DRM_FORMAT_RGB565_A8:
+ case DRM_FORMAT_BGR565_A8:
return 0;
default:
DRM_DEBUG_KMS("invalid pixel format %s\n",
@@ -5198,11 +5206,15 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int
*depth,
break;
case DRM_FORMAT_RGB565:
case DRM_FORMAT_BGR565:
+ case DRM_FORMAT_RGB565_A8:
+ case DRM_FORMAT_BGR565_A8:
*depth = 16;
*bpp = 16;
break;
case DRM_FORMAT_RGB888:
case DRM_FORMAT_BGR888:
+ case DRM_FORMAT_RGB888_A8:
+ case DRM_FORMAT_BGR888_A8:
*depth = 24;
*bpp = 24;
break;
@@ -5210,6 +5222,10 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int
*depth,
case DRM_FORMAT_XBGR:
case DRM_FORMAT_RGBX:
case DRM_FORMAT_BGRX:
+ case DRM_FORMAT_XRGB_A8:
+ case DRM_FORMAT_XBGR_A8:
+ case DRM_FORMAT_RGBX_A8:
+ case DRM_FORMAT_BGRX_A8:
*depth = 24;
*bpp = 32;
break;
@@ -5268,6 +5284,14 @@ int drm_format_num_planes(uint32_t format)
case DRM_FORMAT_NV61:
case DRM_FORMAT_NV24:
case DRM_FORMAT_NV42:
+ case DRM_FORMAT_RGB565_A8:
+ case DRM_FORMAT_BGR565_A8:
+ case DRM_FORMAT_RGB888_A8:
+ case DRM_FORMAT_BGR888_A8:
+ case DRM_FORMAT_XRGB_A8:
+ case DRM_FORMAT_XBGR_A8:
+ case DRM_FORMAT_RGBX_A8:
+ case DRM_FORMAT_BGRX_A8:
return 2;
default:
return 1;
@@ -5315,6 +5339,17 @@ int drm_format_plane_cpp(uint32_t format, int plane)
case DRM_FORMAT_YUV444:
case DRM_FORMAT_YVU444:
return 1;
+ case DRM_FORMAT_RGB565_A8:
+ case DRM_FORMAT_BGR565_A8:
+ return plane ? 1 : 2;
+ case DRM_FORMAT_RGB888_A8:
+ case DRM_FORMAT_BGR888_A8:
+ return plane ? 1 : 3;
+ case DRM_FORMAT_XRGB_A8:
+ case DRM_FORMAT_XBGR_A8:
+ case DRM_FORMAT_RGBX_A8:
+ case DRM_FORMAT_BGRX_A8:
+ return plane ? 1 : 4;
default:
drm_fb_get_bpp_depth(format, &depth, &bpp);
return bpp >> 3;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0773582..48d6ec8 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -96,6 +96,20 @@
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
/*
+ * 2 plane RGB + A
+ * index 0 = RGB plane
+ * index 1 = A plane
+ */
+#define DRM_FORMAT_XRGB_A8 fourcc_code('X', 'R', 'A', '8')
+#define DRM_FORMAT_XBGR_A8 fourcc_code('X', 'B', 'A', '8')
+#define DRM_FORMAT_RGBX_A8 fourcc_code('R', 'X', 'A', '8')
+#define DRM_FORMAT_BGRX_A8 fourcc_code('B', 'X', 'A', '8')
+#define DRM_FORMAT_RGB888_A8 fourcc_code('R', '8', 'A', '8')
+#define DRM_FORMAT_BGR888_A8 fourcc_code('B', '8', 'A', '8')
+#define DRM_FORMAT_RGB565_A8 fourcc_code('R', '5', 'A', '8')
+#define DRM_FORMAT_BGR565_A8 fourcc_code('B', '5', 'A', '8')
+
+/*
* 2 plane YCbCr
* index 0 = Y plane, [7:0] Y
* index 1 = Cr:Cb plane, [15:0] Cr:Cb little endian
--
2.1.4
[PATCH 1/7] gpu: ipu-v3: Add support for 15-bit RGB with 1-bit alpha formats
This patch adds support for ARGB1555, ABGR1555, RGBA5551, and BGRA5551
in-memory formats.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 4
drivers/gpu/ipu-v3/ipu-cpmem.c | 44 +
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 67bab5c..e21a358 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -57,6 +57,10 @@ EXPORT_SYMBOL_GPL(ipu_srm_dp_sync_update);
enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 drm_fourcc)
{
switch (drm_fourcc) {
+ case DRM_FORMAT_ARGB1555:
+ case DRM_FORMAT_ABGR1555:
+ case DRM_FORMAT_RGBA5551:
+ case DRM_FORMAT_BGRA5551:
case DRM_FORMAT_RGB565:
case DRM_FORMAT_BGR565:
case DRM_FORMAT_RGB888:
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index 3bf05bc..d26b8be 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -500,6 +500,38 @@ static const struct ipu_rgb def_bgr_16 = {
.bits_per_pixel = 16,
};
+static const struct ipu_rgb def_argb_16 = {
+ .red= { .offset = 10, .length = 5, },
+ .green = { .offset = 5, .length = 5, },
+ .blue = { .offset = 0, .length = 5, },
+ .transp = { .offset = 15, .length = 1, },
+ .bits_per_pixel = 16,
+};
+
+static const struct ipu_rgb def_abgr_16 = {
+ .red= { .offset = 0, .length = 5, },
+ .green = { .offset = 5, .length = 5, },
+ .blue = { .offset = 10, .length = 5, },
+ .transp = { .offset = 15, .length = 1, },
+ .bits_per_pixel = 16,
+};
+
+static const struct ipu_rgb def_rgba_16 = {
+ .red= { .offset = 11, .length = 5, },
+ .green = { .offset = 6, .length = 5, },
+ .blue = { .offset = 1, .length = 5, },
+ .transp = { .offset = 0, .length = 1, },
+ .bits_per_pixel = 16,
+};
+
+static const struct ipu_rgb def_bgra_16 = {
+ .red= { .offset = 1, .length = 5, },
+ .green = { .offset = 6, .length = 5, },
+ .blue = { .offset = 11, .length = 5, },
+ .transp = { .offset = 0, .length = 1, },
+ .bits_per_pixel = 16,
+};
+
#define Y_OFFSET(pix, x, y)((x) + pix->width * (y))
#define U_OFFSET(pix, x, y)((pix->width * pix->height) + \
(pix->width * (y) / 4) + (x) / 2)
@@ -581,6 +613,18 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32
drm_fourcc)
case DRM_FORMAT_BGR565:
ipu_cpmem_set_format_rgb(ch, &def_bgr_16);
break;
+ case DRM_FORMAT_ARGB1555:
+ ipu_cpmem_set_format_rgb(ch, &def_argb_16);
+ break;
+ case DRM_FORMAT_ABGR1555:
+ ipu_cpmem_set_format_rgb(ch, &def_abgr_16);
+ break;
+ case DRM_FORMAT_RGBA5551:
+ ipu_cpmem_set_format_rgb(ch, &def_rgba_16);
+ break;
+ case DRM_FORMAT_BGRA5551:
+ ipu_cpmem_set_format_rgb(ch, &def_bgra_16);
+ break;
default:
return -EINVAL;
}
--
2.1.4
[PATCH 5/7] drm/imx: ipuv3-plane: enable support for RGBX8888 and RGBA8888 pixel formats
This patch allows to use the RGBX and RGBA 8:8:8:8 formats.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index d13dbb6..d030990 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -33,6 +33,10 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ABGR,
DRM_FORMAT_XBGR,
+ DRM_FORMAT_RGBA,
+ DRM_FORMAT_RGBX,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_BGRA,
DRM_FORMAT_YUYV,
DRM_FORMAT_YVYU,
DRM_FORMAT_YUV420,
@@ -185,6 +189,8 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
case DRM_FORMAT_BGRA5551:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
+ case DRM_FORMAT_RGBA:
+ case DRM_FORMAT_BGRA:
ipu_dp_set_global_alpha(ipu_plane->dp, false, 0, false);
break;
default:
--
2.1.4
[PATCH 0/7] imx-drm: additional alpha transparency formats
Hi, this series adds support for more alpha transpancy formats such as RGBA 8:8:8:8, ARGB 1:5:5:5, and the more esoteric formats with 8-bit alpha on a separate plane. For the latter, new 2-plane RGB formats are added: DRM_FORMAT_XRGB_A8 DRM_FORMAT_XBGR_A8 DRM_FORMAT_RGBX_A8 DRM_FORMAT_BGRX_A8 DRM_FORMAT_RGB888_A8 DRM_FORMAT_BGR888_A8 DRM_FORMAT_RGB565_A8 DRM_FORMAT_BGR565_A8 They contain RGB data in the first plane and 8-bit alpha values in the second plane. If supported by the hardware, memory bandwidth usage can be reduced in case of frame buffers with large, completely transparent regions by selectively skipping read accesses in the color channel. regards Philipp Philipp Zabel (7): gpu: ipu-v3: Add support for 15-bit RGB with 1-bit alpha formats drm/imx: Add support for 15-bit RGB with 1-bit alpha formats gpu: ipu-v3: add support for RGBX and RGBA pixel formats gpu: ipu-v3: add support for separate alpha channels drm/imx: ipuv3-plane: enable support for RGBX and RGBA pixel formats drm: add RGB formats with separate alpha plane drm/imx: ipuv3-plane: add support for separate alpha planes drivers/gpu/drm/drm_crtc.c| 35 ++ drivers/gpu/drm/imx/ipuv3-plane.c | 86 drivers/gpu/drm/imx/ipuv3-plane.h | 2 + drivers/gpu/ipu-v3/ipu-common.c | 10 +++ drivers/gpu/ipu-v3/ipu-cpmem.c| 133 -- include/uapi/drm/drm_fourcc.h | 14 include/video/imx-ipu-v3.h| 22 +++ 7 files changed, 298 insertions(+), 4 deletions(-) -- 2.1.4
[PATCH 3/7] gpu: ipu-v3: add support for RGBX8888 and RGBA8888 pixel formats
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-cpmem.c | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index d26b8be..0e6b868 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -452,7 +452,7 @@ void ipu_cpmem_set_yuv_planar(struct ipuv3_channel *ch,
}
EXPORT_SYMBOL_GPL(ipu_cpmem_set_yuv_planar);
-static const struct ipu_rgb def_rgb_32 = {
+static const struct ipu_rgb def_xrgb_32 = {
.red= { .offset = 16, .length = 8, },
.green = { .offset = 8, .length = 8, },
.blue = { .offset = 0, .length = 8, },
@@ -460,7 +460,7 @@ static const struct ipu_rgb def_rgb_32 = {
.bits_per_pixel = 32,
};
-static const struct ipu_rgb def_bgr_32 = {
+static const struct ipu_rgb def_xbgr_32 = {
.red= { .offset = 0, .length = 8, },
.green = { .offset = 8, .length = 8, },
.blue = { .offset = 16, .length = 8, },
@@ -468,6 +468,22 @@ static const struct ipu_rgb def_bgr_32 = {
.bits_per_pixel = 32,
};
+static const struct ipu_rgb def_rgbx_32 = {
+ .red= { .offset = 24, .length = 8, },
+ .green = { .offset = 16, .length = 8, },
+ .blue = { .offset = 8, .length = 8, },
+ .transp = { .offset = 0, .length = 8, },
+ .bits_per_pixel = 32,
+};
+
+static const struct ipu_rgb def_bgrx_32 = {
+ .red= { .offset = 8, .length = 8, },
+ .green = { .offset = 16, .length = 8, },
+ .blue = { .offset = 24, .length = 8, },
+ .transp = { .offset = 0, .length = 8, },
+ .bits_per_pixel = 32,
+};
+
static const struct ipu_rgb def_rgb_24 = {
.red= { .offset = 16, .length = 8, },
.green = { .offset = 8, .length = 8, },
@@ -595,11 +611,19 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32
drm_fourcc)
break;
case DRM_FORMAT_ABGR:
case DRM_FORMAT_XBGR:
- ipu_cpmem_set_format_rgb(ch, &def_bgr_32);
+ ipu_cpmem_set_format_rgb(ch, &def_xbgr_32);
break;
case DRM_FORMAT_ARGB:
case DRM_FORMAT_XRGB:
- ipu_cpmem_set_format_rgb(ch, &def_rgb_32);
+ ipu_cpmem_set_format_rgb(ch, &def_xrgb_32);
+ break;
+ case DRM_FORMAT_RGBA:
+ case DRM_FORMAT_RGBX:
+ ipu_cpmem_set_format_rgb(ch, &def_rgbx_32);
+ break;
+ case DRM_FORMAT_BGRA:
+ case DRM_FORMAT_BGRX:
+ ipu_cpmem_set_format_rgb(ch, &def_bgrx_32);
break;
case DRM_FORMAT_BGR888:
ipu_cpmem_set_format_rgb(ch, &def_bgr_24);
--
2.1.4
[PATCH 4/7] gpu: ipu-v3: add support for separate alpha channels
The IPUv3 can read 8-bit alpha values from a separate IDMAC channel driven
by the Alpha Transparency Controller (ATC) for the graphics IDMAC channels.
This allows to reduce memory bandwidth via a conditional read mechanism or
to support planar YUV formats with alpha transparency.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 6 +
drivers/gpu/ipu-v3/ipu-cpmem.c | 57 +
include/video/imx-ipu-v3.h | 22
3 files changed, 85 insertions(+)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index e21a358..72994b0 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -73,6 +73,12 @@ enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32
drm_fourcc)
case DRM_FORMAT_ABGR:
case DRM_FORMAT_RGBA:
case DRM_FORMAT_BGRA:
+ case DRM_FORMAT_RGB565_A8:
+ case DRM_FORMAT_BGR565_A8:
+ case DRM_FORMAT_RGB888_A8:
+ case DRM_FORMAT_BGR888_A8:
+ case DRM_FORMAT_RGBX_A8:
+ case DRM_FORMAT_BGRX_A8:
return IPUV3_COLORSPACE_RGB;
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index 0e6b868..75b5412 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -564,6 +564,43 @@ static const struct ipu_rgb def_bgra_16 = {
#define UV2_OFFSET(pix, x, y) ((pix->width * pix->height) + \
(pix->width * y) + (x))
+#define NUM_ALPHA_CHANNELS 7
+
+/* See Table 37-12. Alpha channels mapping. */
+static int ipu_channel_albm(int ch_num)
+{
+ switch (ch_num) {
+ case IPUV3_CHANNEL_G_MEM_IC_PRP_VF: return 0;
+ case IPUV3_CHANNEL_G_MEM_IC_PP: return 1;
+ case IPUV3_CHANNEL_MEM_FG_SYNC: return 2;
+ case IPUV3_CHANNEL_MEM_FG_ASYNC:return 3;
+ case IPUV3_CHANNEL_MEM_BG_SYNC: return 4;
+ case IPUV3_CHANNEL_MEM_BG_ASYNC:return 5;
+ case IPUV3_CHANNEL_MEM_VDI_PLANE1_COMB: return 6;
+ default:
+ return -EINVAL;
+ }
+}
+
+static void ipu_cpmem_set_separate_alpha(struct ipuv3_channel *ch)
+{
+ struct ipu_soc *ipu = ch->ipu;
+ int albm;
+ u32 val;
+
+ albm = ipu_channel_albm(ch->num);
+ if (albm < 0)
+ return;
+
+ ipu_ch_param_write_field(ch, IPU_FIELD_ALU, 1);
+ ipu_ch_param_write_field(ch, IPU_FIELD_ALBM, albm);
+ ipu_ch_param_write_field(ch, IPU_FIELD_CRE, 1);
+
+ val = ipu_idmac_read(ipu, IDMAC_SEP_ALPHA);
+ val |= BIT(ch->num);
+ ipu_idmac_write(ipu, val, IDMAC_SEP_ALPHA);
+}
+
int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 drm_fourcc)
{
switch (drm_fourcc) {
@@ -619,22 +656,28 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32
drm_fourcc)
break;
case DRM_FORMAT_RGBA:
case DRM_FORMAT_RGBX:
+ case DRM_FORMAT_RGBX_A8:
ipu_cpmem_set_format_rgb(ch, &def_rgbx_32);
break;
case DRM_FORMAT_BGRA:
case DRM_FORMAT_BGRX:
+ case DRM_FORMAT_BGRX_A8:
ipu_cpmem_set_format_rgb(ch, &def_bgrx_32);
break;
case DRM_FORMAT_BGR888:
+ case DRM_FORMAT_BGR888_A8:
ipu_cpmem_set_format_rgb(ch, &def_bgr_24);
break;
case DRM_FORMAT_RGB888:
+ case DRM_FORMAT_RGB888_A8:
ipu_cpmem_set_format_rgb(ch, &def_rgb_24);
break;
case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_RGB565_A8:
ipu_cpmem_set_format_rgb(ch, &def_rgb_16);
break;
case DRM_FORMAT_BGR565:
+ case DRM_FORMAT_BGR565_A8:
ipu_cpmem_set_format_rgb(ch, &def_bgr_16);
break;
case DRM_FORMAT_ARGB1555:
@@ -653,6 +696,20 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32
drm_fourcc)
return -EINVAL;
}
+ switch (drm_fourcc) {
+ case DRM_FORMAT_RGB565_A8:
+ case DRM_FORMAT_BGR565_A8:
+ case DRM_FORMAT_RGB888_A8:
+ case DRM_FORMAT_BGR888_A8:
+ case DRM_FORMAT_RGBX_A8:
+ case DRM_FORMAT_BGRX_A8:
+ ipu_ch_param_write_field(ch, IPU_FIELD_WID3, 7);
+ ipu_cpmem_set_separate_alpha(ch);
+ break;
+ default:
+ break;
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(ipu_cpmem_set_fmt);
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 85dedca..9f5d220 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -118,6 +118,28 @@ enum ipu_channel_irq {
#define IPUV3_CHANNEL_ROT_PP_MEM 50
#define IPUV3_CHANNEL_MEM_BG_SYNC_ALPHA51
+static inline int ipu_channel_alpha_channel(int ch_num)
+{
+ switch (
[PATCH 2/7] drm/imx: Add support for 15-bit RGB with 1-bit alpha formats
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 878a643..d13dbb6 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -23,8 +23,12 @@
#define to_ipu_plane(x)container_of(x, struct ipu_plane, base)
static const uint32_t ipu_plane_formats[] = {
+ DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_ABGR1555,
DRM_FORMAT_XBGR1555,
+ DRM_FORMAT_RGBA5551,
+ DRM_FORMAT_BGRA5551,
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB,
DRM_FORMAT_ABGR,
@@ -175,6 +179,10 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
ipu_dp_set_window_pos(ipu_plane->dp, crtc_x, crtc_y);
/* Enable local alpha on partial plane */
switch (fb->pixel_format) {
+ case DRM_FORMAT_ARGB1555:
+ case DRM_FORMAT_ABGR1555:
+ case DRM_FORMAT_RGBA5551:
+ case DRM_FORMAT_BGRA5551:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
ipu_dp_set_global_alpha(ipu_plane->dp, false, 0, false);
--
2.1.4
[PATCH 7/7] drm/imx: ipuv3-plane: add support for separate alpha planes
The IPUv3 can read 8-bit alpha values from a separate plane buffer using a
companion IDMAC channel driven by the Alpha Transparency Controller (ATC)
for the graphics channels. The conditional read mechanism allows to reduce
memory bandwidth by skipping reads of color data for completely transparent
bursts.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 72 +++
drivers/gpu/drm/imx/ipuv3-plane.h | 2 ++
2 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index d030990..ca10d55 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -41,6 +41,12 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_YUV420,
DRM_FORMAT_YVU420,
+ DRM_FORMAT_RGB565_A8,
+ DRM_FORMAT_BGR565_A8,
+ DRM_FORMAT_RGB888_A8,
+ DRM_FORMAT_BGR888_A8,
+ DRM_FORMAT_RGBX_A8,
+ DRM_FORMAT_BGRX_A8,
};
int ipu_plane_irq(struct ipu_plane *ipu_plane)
@@ -71,6 +77,7 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct
drm_framebuffer *fb,
int x, int y)
{
struct drm_gem_cma_object *cma_obj;
+ unsigned long alpha_eba = 0;
unsigned long eba;
int active;
@@ -86,13 +93,36 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct
drm_framebuffer *fb,
eba = cma_obj->paddr + fb->offsets[0] +
fb->pitches[0] * y + (fb->bits_per_pixel >> 3) * x;
+ switch (fb->pixel_format) {
+ case DRM_FORMAT_RGB565_A8:
+ case DRM_FORMAT_BGR565_A8:
+ case DRM_FORMAT_RGB888_A8:
+ case DRM_FORMAT_BGR888_A8:
+ case DRM_FORMAT_RGBX_A8:
+ case DRM_FORMAT_BGRX_A8:
+ alpha_eba = cma_obj->paddr + fb->offsets[1] +
+ fb->pitches[1] * y + x;
+ break;
+ }
+
if (ipu_plane->enabled) {
active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba);
ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active);
+ if (alpha_eba) {
+ active = ipu_idmac_get_current_buffer(
+ ipu_plane->alpha_ch);
+ ipu_cpmem_set_buffer(ipu_plane->alpha_ch, !active,
+alpha_eba);
+ ipu_idmac_select_buffer(ipu_plane->alpha_ch, !active);
+ }
} else {
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 0, eba);
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 1, eba);
+ if (alpha_eba) {
+ ipu_cpmem_set_buffer(ipu_plane->alpha_ch, 0, alpha_eba);
+ ipu_cpmem_set_buffer(ipu_plane->alpha_ch, 1, alpha_eba);
+ }
}
/* cache offsets for subsequent pageflips */
@@ -163,6 +193,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
return ipu_plane_set_base(ipu_plane, fb, src_x, src_y);
}
+ ipu_plane->separate_alpha = false;
switch (ipu_plane->dp_flow) {
case IPU_DP_FLOW_SYNC_BG:
ret = ipu_dp_setup_channel(ipu_plane->dp,
@@ -183,6 +214,16 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
ipu_dp_set_window_pos(ipu_plane->dp, crtc_x, crtc_y);
/* Enable local alpha on partial plane */
switch (fb->pixel_format) {
+ case DRM_FORMAT_RGB565_A8:
+ case DRM_FORMAT_BGR565_A8:
+ case DRM_FORMAT_RGB888_A8:
+ case DRM_FORMAT_BGR888_A8:
+ case DRM_FORMAT_RGBX_A8:
+ case DRM_FORMAT_BGRX_A8:
+ if (!ipu_plane->alpha_ch)
+ return -EINVAL;
+ ipu_plane->separate_alpha = true;
+ /* fallthrough */
case DRM_FORMAT_ARGB1555:
case DRM_FORMAT_ABGR1555:
case DRM_FORMAT_RGBA5551:
@@ -224,6 +265,18 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
ipu_idmac_set_double_buffer(ipu_plane->ipu_ch, 1);
ipu_cpmem_set_stride(ipu_plane->ipu_ch, fb->pitches[0]);
+ if (ipu_plane->separate_alpha) {
+ ipu_cpmem_set_burstsize(ipu_plane->ipu_ch, 16);
+
+ ipu_cpmem_zero(ipu_plane->alpha_ch);
+ ipu_cpmem_set_resolution(ipu_plane->alpha_ch, src_w, src_h);
+ ipu_cpmem_set_format_passthrough(ipu_plane->alpha_ch, 8);
+ ipu_cpmem_set_high_priority(ipu_plane->alpha_ch);
+ ipu_idmac_set_double_buffer(ipu_plane->alpha_ch, 1);
+ ipu_cpmem_set_stride(ipu_plane->alpha_ch, fb->pitches[1]);
+ ipu_cp
[PATCH] drm/radeon: take the mode_config mutex when dealing with hpds (v2)
Since we are messing with state in the worker.
v2: drop the changes in the mst worker
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 7162c93..f682e53 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -79,10 +79,12 @@ static void radeon_hotplug_work_func(struct work_struct
*work)
struct drm_mode_config *mode_config = &dev->mode_config;
struct drm_connector *connector;
+ mutex_lock(&mode_config->mutex);
if (mode_config->num_connector) {
list_for_each_entry(connector, &mode_config->connector_list,
head)
radeon_connector_hotplug(connector);
}
+ mutex_unlock(&mode_config->mutex);
/* Just fire off a uevent and let userspace tell us what to do */
drm_helper_hpd_irq_event(dev);
}
--
1.8.3.1
[PATCH] drm/radeon: properly select encoder in radeon_audio_detect (v2)
Need to handle DVI where we way end up with an analog encoder
in some cases.
v2: rework checks. always set use_digital for DVI-D, HDMI-A
Reported-by: Julian Margetson
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_audio.c | 20 +++-
drivers/gpu/drm/radeon/radeon_connectors.c | 6 --
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_audio.c
b/drivers/gpu/drm/radeon/radeon_audio.c
index dcb7796..ace2b4b 100644
--- a/drivers/gpu/drm/radeon/radeon_audio.c
+++ b/drivers/gpu/drm/radeon/radeon_audio.c
@@ -453,22 +453,24 @@ void radeon_audio_enable(struct radeon_device *rdev,
void radeon_audio_detect(struct drm_connector *connector,
enum drm_connector_status status)
{
- struct radeon_device *rdev;
- struct radeon_encoder *radeon_encoder;
+ struct drm_device *dev = connector->dev;
+ struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder_atom_dig *dig;
+ const struct drm_connector_helper_funcs *connector_funcs =
+ connector->helper_private;
+ struct drm_encoder *encoder = connector_funcs->best_encoder(connector);
+ struct radeon_encoder *radeon_encoder;
- if (!connector || !connector->encoder)
+ if (!radeon_audio_chipset_supported(rdev))
return;
- if (!radeon_encoder_is_digital(connector->encoder))
+ if (!encoder)
return;
- rdev = connector->encoder->dev->dev_private;
-
- if (!radeon_audio_chipset_supported(rdev))
+ if (!radeon_encoder_is_digital(encoder))
return;
- radeon_encoder = to_radeon_encoder(connector->encoder);
+ radeon_encoder = to_radeon_encoder(encoder);
dig = radeon_encoder->enc_priv;
if (!dig->afmt)
@@ -484,7 +486,7 @@ void radeon_audio_detect(struct drm_connector *connector,
else
radeon_encoder->audio = rdev->audio.hdmi_funcs;
- dig->afmt->pin = radeon_audio_get_pin(connector->encoder);
+ dig->afmt->pin = radeon_audio_get_pin(encoder);
if (drm_detect_monitor_audio(radeon_connector_edid(connector)))
{
radeon_audio_enable(rdev, dig->afmt->pin, 0xf);
} else {
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index d17d251..8052759 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1303,8 +1303,10 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
/* DVI-D and HDMI-A are digital only */
if ((connector->connector_type == DRM_MODE_CONNECTOR_DVID) ||
- (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA))
+ (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA)) {
+ radeon_connector->use_digital = true;
goto out;
+ }
/* if we aren't forcing don't do destructive polling */
if (!force) {
@@ -1379,7 +1381,7 @@ out:
/* updated in get modes as well since we need to know if it's analog or
digital */
radeon_connector_update_scratch_regs(connector, ret);
- if (radeon_audio != 0) {
+ if ((radeon_audio != 0) && (radeon_connector->use_digital)) {
radeon_connector_get_edid(connector);
radeon_audio_detect(connector, ret);
}
--
1.8.3.1
[PATCH 6/7] drm: add RGB formats with separate alpha plane
On Tue, May 19, 2015 at 06:06:00PM +0200, Philipp Zabel wrote:
> Some hardware can read the alpha components separately and then
> conditionally fetch color components only for non-zero alpha values.
> This patch adds fourcc definitions for two-plane RGB formats with an
> 8-bit alpha channel on a second plane.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/drm/drm_crtc.c| 35 +++
> include/uapi/drm/drm_fourcc.h | 14 ++
> 2 files changed, 49 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 3007b44..2ac0d7c 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3245,6 +3245,14 @@ static int format_check(const struct drm_mode_fb_cmd2
> *r)
> case DRM_FORMAT_YVU422:
> case DRM_FORMAT_YUV444:
> case DRM_FORMAT_YVU444:
> + case DRM_FORMAT_XRGB_A8:
> + case DRM_FORMAT_XBGR_A8:
> + case DRM_FORMAT_RGBX_A8:
> + case DRM_FORMAT_BGRX_A8:
> + case DRM_FORMAT_RGB888_A8:
> + case DRM_FORMAT_BGR888_A8:
> + case DRM_FORMAT_RGB565_A8:
> + case DRM_FORMAT_BGR565_A8:
> return 0;
> default:
> DRM_DEBUG_KMS("invalid pixel format %s\n",
> @@ -5198,11 +5206,15 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned
> int *depth,
> break;
> case DRM_FORMAT_RGB565:
> case DRM_FORMAT_BGR565:
> + case DRM_FORMAT_RGB565_A8:
> + case DRM_FORMAT_BGR565_A8:
> *depth = 16;
> *bpp = 16;
> break;
> case DRM_FORMAT_RGB888:
> case DRM_FORMAT_BGR888:
> + case DRM_FORMAT_RGB888_A8:
> + case DRM_FORMAT_BGR888_A8:
> *depth = 24;
> *bpp = 24;
> break;
> @@ -5210,6 +5222,10 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned
> int *depth,
> case DRM_FORMAT_XBGR:
> case DRM_FORMAT_RGBX:
> case DRM_FORMAT_BGRX:
> + case DRM_FORMAT_XRGB_A8:
> + case DRM_FORMAT_XBGR_A8:
> + case DRM_FORMAT_RGBX_A8:
> + case DRM_FORMAT_BGRX_A8:
> *depth = 24;
> *bpp = 32;
> break;
Please drop the above two hunks, these functions are only for backwards
compat with drivers from the addfb1 days. Modern drivers should only use
the format tags directly. Extending the plane_cpp function like you do
below is enough.
Maybe we should add a WARN_ON(num_planes(format) != 0) to the top of this
and a comment that this is for legacy stuff only.
lgtm otherwise.
-Daniel
> @@ -5268,6 +5284,14 @@ int drm_format_num_planes(uint32_t format)
> case DRM_FORMAT_NV61:
> case DRM_FORMAT_NV24:
> case DRM_FORMAT_NV42:
> + case DRM_FORMAT_RGB565_A8:
> + case DRM_FORMAT_BGR565_A8:
> + case DRM_FORMAT_RGB888_A8:
> + case DRM_FORMAT_BGR888_A8:
> + case DRM_FORMAT_XRGB_A8:
> + case DRM_FORMAT_XBGR_A8:
> + case DRM_FORMAT_RGBX_A8:
> + case DRM_FORMAT_BGRX_A8:
> return 2;
> default:
> return 1;
> @@ -5315,6 +5339,17 @@ int drm_format_plane_cpp(uint32_t format, int plane)
> case DRM_FORMAT_YUV444:
> case DRM_FORMAT_YVU444:
> return 1;
> + case DRM_FORMAT_RGB565_A8:
> + case DRM_FORMAT_BGR565_A8:
> + return plane ? 1 : 2;
> + case DRM_FORMAT_RGB888_A8:
> + case DRM_FORMAT_BGR888_A8:
> + return plane ? 1 : 3;
> + case DRM_FORMAT_XRGB_A8:
> + case DRM_FORMAT_XBGR_A8:
> + case DRM_FORMAT_RGBX_A8:
> + case DRM_FORMAT_BGRX_A8:
> + return plane ? 1 : 4;
> default:
> drm_fb_get_bpp_depth(format, &depth, &bpp);
> return bpp >> 3;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 0773582..48d6ec8 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -96,6 +96,20 @@
> #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
>
> /*
> + * 2 plane RGB + A
> + * index 0 = RGB plane
> + * index 1 = A plane
> + */
> +#define DRM_FORMAT_XRGB_A8 fourcc_code('X', 'R', 'A', '8')
> +#define DRM_FORMAT_XBGR_A8 fourcc_code('X', 'B', 'A', '8')
> +#define DRM_FORMAT_RGBX_A8 fourcc_code('R', 'X', 'A', '8')
> +#define DRM_FORMAT_BGRX_A8 fourcc_code('B', 'X', 'A', '8')
> +#define DRM_FORMAT_RGB888_A8 fourcc_code('R', '8', 'A', '8')
> +#define DRM_FORMAT_BGR888_A8 fourcc_code('B', '8', 'A', '8')
> +#define DRM_FORMAT_RGB565_A8 fourcc_code('R', '5', 'A', '8')
> +#define DRM_FORMAT_BGR565_A8 fourcc_code('B', '5', 'A', '8')
> +
> +/*
> * 2 plane YCbCr
> * index 0 = Y plane, [7:0] Y
> * index 1 = Cr:Cb plane, [15:0] Cr:Cb little endian
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.
[PATCH 7/7] drm/imx: ipuv3-plane: add support for separate alpha planes
On Tue, May 19, 2015 at 06:06:01PM +0200, Philipp Zabel wrote:
> The IPUv3 can read 8-bit alpha values from a separate plane buffer using a
> companion IDMAC channel driven by the Alpha Transparency Controller (ATC)
> for the graphics channels. The conditional read mechanism allows to reduce
> memory bandwidth by skipping reads of color data for completely transparent
> bursts.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/drm/imx/ipuv3-plane.c | 72
> +++
> drivers/gpu/drm/imx/ipuv3-plane.h | 2 ++
> 2 files changed, 74 insertions(+)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index d030990..ca10d55 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -41,6 +41,12 @@ static const uint32_t ipu_plane_formats[] = {
> DRM_FORMAT_YVYU,
> DRM_FORMAT_YUV420,
> DRM_FORMAT_YVU420,
> + DRM_FORMAT_RGB565_A8,
> + DRM_FORMAT_BGR565_A8,
> + DRM_FORMAT_RGB888_A8,
> + DRM_FORMAT_BGR888_A8,
> + DRM_FORMAT_RGBX_A8,
> + DRM_FORMAT_BGRX_A8,
> };
>
> int ipu_plane_irq(struct ipu_plane *ipu_plane)
> @@ -71,6 +77,7 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct
> drm_framebuffer *fb,
> int x, int y)
> {
> struct drm_gem_cma_object *cma_obj;
> + unsigned long alpha_eba = 0;
> unsigned long eba;
> int active;
>
> @@ -86,13 +93,36 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane,
> struct drm_framebuffer *fb,
> eba = cma_obj->paddr + fb->offsets[0] +
> fb->pitches[0] * y + (fb->bits_per_pixel >> 3) * x;
>
> + switch (fb->pixel_format) {
> + case DRM_FORMAT_RGB565_A8:
> + case DRM_FORMAT_BGR565_A8:
> + case DRM_FORMAT_RGB888_A8:
> + case DRM_FORMAT_BGR888_A8:
> + case DRM_FORMAT_RGBX_A8:
> + case DRM_FORMAT_BGRX_A8:
> + alpha_eba = cma_obj->paddr + fb->offsets[1] +
> + fb->pitches[1] * y + x;
You need to look at the 2nd cma_obj here, i.e. drm_fb_cma_get_gem_obj(fb, 1);
Yes, userspace is allowed to hand in non-matching. And given that you
you just reuse the cma helpers and don't reject framebuffers with
non-matching cma objects your current planar yuv support is also already
broken. Would be good if you could also patch modetest a bit to exercise
this ...
-Daniel
> + break;
> + }
> +
> if (ipu_plane->enabled) {
> active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
> ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba);
> ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active);
> + if (alpha_eba) {
> + active = ipu_idmac_get_current_buffer(
> + ipu_plane->alpha_ch);
> + ipu_cpmem_set_buffer(ipu_plane->alpha_ch, !active,
> + alpha_eba);
> + ipu_idmac_select_buffer(ipu_plane->alpha_ch, !active);
> + }
> } else {
> ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 0, eba);
> ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 1, eba);
> + if (alpha_eba) {
> + ipu_cpmem_set_buffer(ipu_plane->alpha_ch, 0, alpha_eba);
> + ipu_cpmem_set_buffer(ipu_plane->alpha_ch, 1, alpha_eba);
> + }
> }
>
> /* cache offsets for subsequent pageflips */
> @@ -163,6 +193,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane,
> struct drm_crtc *crtc,
> return ipu_plane_set_base(ipu_plane, fb, src_x, src_y);
> }
>
> + ipu_plane->separate_alpha = false;
> switch (ipu_plane->dp_flow) {
> case IPU_DP_FLOW_SYNC_BG:
> ret = ipu_dp_setup_channel(ipu_plane->dp,
> @@ -183,6 +214,16 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane,
> struct drm_crtc *crtc,
> ipu_dp_set_window_pos(ipu_plane->dp, crtc_x, crtc_y);
> /* Enable local alpha on partial plane */
> switch (fb->pixel_format) {
> + case DRM_FORMAT_RGB565_A8:
> + case DRM_FORMAT_BGR565_A8:
> + case DRM_FORMAT_RGB888_A8:
> + case DRM_FORMAT_BGR888_A8:
> + case DRM_FORMAT_RGBX_A8:
> + case DRM_FORMAT_BGRX_A8:
> + if (!ipu_plane->alpha_ch)
> + return -EINVAL;
> + ipu_plane->separate_alpha = true;
> + /* fallthrough */
> case DRM_FORMAT_ARGB1555:
> case DRM_FORMAT_ABGR1555:
> case DRM_FORMAT_RGBA5551:
> @@ -224,6 +265,18 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane,
> struct drm_crtc *crtc,
> ipu_idmac_set_double_buffer(ipu_plane->ipu_ch, 1);
> ipu_cpmem_set_stride(ipu_plane->ipu_ch, fb->pitches[0]);
>
> + if (ipu
[Intel-gfx] [PATCH 1/3] drm/atomic: add commit_planes_on_crtc helper
On Tue, May 19, 2015 at 04:41:01PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_commit_planes calls all atomic_begin's first,
> then updates all planes, finally calling atomic_flush.
>
> Some drivers may want to things like disabling irq's
> from their atomic_begin, in which case a second call to atomic_begin
> will splat. By using commit_planes_on_crtc on each crtc in the
> atomic state they'll evade that issue.
>
> Signed-off-by: Maarten Lankhorst
All three patches merged to topic/drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 53
> +
> include/drm/drm_atomic_helper.h | 1 +
> 2 files changed, 54 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index b82ef6262469..2da8a16bb39e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1181,6 +1181,59 @@ void drm_atomic_helper_commit_planes(struct drm_device
> *dev,
> EXPORT_SYMBOL(drm_atomic_helper_commit_planes);
>
> /**
> + * drm_atomic_helper_commit_planes_on_crtc - commit plane state for a crtc
> + * @old_crtc_state: atomic state object with the old crtc state
> + *
> + * This function commits the new plane state using the plane and atomic
> helper
> + * functions for planes on the specific crtc. It assumes that the atomic
> state
> + * has already been pushed into the relevant object state pointers, since
> this
> + * step can no longer fail.
> + *
> + * This function can only be used when planes are not allowed to move between
> + * different crtc's.
> + */
> +void
> +drm_atomic_helper_commit_planes_on_crtc(struct drm_crtc_state
> *old_crtc_state)
> +{
> + const struct drm_crtc_helper_funcs *crtc_funcs;
> + struct drm_crtc *crtc = old_crtc_state->crtc;
> + struct drm_atomic_state *old_state = old_crtc_state->state;
> + struct drm_plane *plane;
> + unsigned plane_mask;
> +
> + plane_mask = old_crtc_state->plane_mask;
> + plane_mask |= crtc->state->plane_mask;
> +
> + crtc_funcs = crtc->helper_private;
> + if (crtc_funcs && crtc_funcs->atomic_begin)
> + crtc_funcs->atomic_begin(crtc);
> +
> + drm_for_each_plane_mask(plane, crtc->dev, plane_mask) {
> + struct drm_plane_state *old_plane_state =
> + drm_atomic_get_existing_plane_state(old_state, plane);
> + const struct drm_plane_helper_funcs *plane_funcs;
> +
> + plane_funcs = plane->helper_private;
> +
> + if (!old_plane_state || !plane_funcs)
> + continue;
> +
> + WARN_ON(plane->state->crtc && plane->state->crtc != crtc);
> +
> + if (drm_atomic_plane_disabling(plane, old_plane_state) &&
> + plane_funcs->atomic_disable)
> + plane_funcs->atomic_disable(plane, old_plane_state);
> + else if (plane->state->crtc ||
> + drm_atomic_plane_disabling(plane, old_plane_state))
> + plane_funcs->atomic_update(plane, old_plane_state);
> + }
> +
> + if (crtc_funcs->atomic_flush)
> + crtc_funcs->atomic_flush(crtc);
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_commit_planes_on_crtc);
> +
> +/**
> * drm_atomic_helper_cleanup_planes - cleanup plane resources after commit
> * @dev: DRM device
> * @old_state: atomic state object with old state structures
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index 6ee0ee5b6143..cc1fee8a12d0 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -58,6 +58,7 @@ void drm_atomic_helper_commit_planes(struct drm_device *dev,
>struct drm_atomic_state *state);
> void drm_atomic_helper_cleanup_planes(struct drm_device *dev,
> struct drm_atomic_state *old_state);
> +void drm_atomic_helper_commit_planes_on_crtc(struct drm_crtc_state
> *old_crtc_state);
>
> void drm_atomic_helper_swap_state(struct drm_device *dev,
> struct drm_atomic_state *state);
> --
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drm/exynos: Add atomic modesetting support
OK,
so Daniel helped me track down this issue. It came from an incorrect
'clock-frequency' entry in my DTS. The freq was 50. Daniel
recommended 7060 which works 'fine' (and according to modetest
produces a 59Hz mode). I say 'fine' because I can't confirm that FIMD is
actually working. I just see that with that change I no longer get any
div-by-zeros in the kernel.
So fimd_calc_clkdiv needs some sanitizing for 'ideal_clk' at least.
What still bothers me though is the fact that FIMD actually gets
enabled. I'm just calling 'modetest -M exynos', so it's just doing
probing. Why does that trigger dpms?
With best wishes,
Tobias
On 2015-05-19 16:06, Daniel Stone wrote:
> Hi Tobias,
>
> On 19 May 2015 at 14:53, Tobias Jakobi
> wrote:
>> On 2015-05-18 23:02, Gustavo Padovan wrote:
>>> So better try this. Ideally fimd_mode_fixup should go away too, I'll
>>> do a
>>> proper
>>> patch once we know this works.
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 12ab80c..363353b 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -307,9 +307,17 @@ static void fimd_iommu_detach_devices(struct
>>> fimd_context *ctx)
>>> static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
>>> const struct drm_display_mode *mode)
>>> {
>>> - unsigned long ideal_clk = mode->htotal * mode->vtotal *
>>> mode->vrefresh;
>>> + unsigned long ideal_clk;
>>> + int vrefresh;
>>> u32 clkdiv;
>>>
>>> + if (mode->vrefresh == 0)
>>> + vrefresh = drm_mode_vrefresh(mode);
>>> + else
>>> + vrefresh = mode->vrefresh;
>>> +
>>> + ideal_clk = mode->htotal * mode->vtotal * vrefresh;
>>> +
>>> if (ctx->i80_if) {
>>> /*
>>> * The frame done interrupt should be occurred prior
>>> to
>>> the
>>
>> I've applied this and the debug output patch, but I still get a
>> div-by-zero.
>
> Can you please add a drm_mode_debug_printmodeline(mode) and give the
> output there?
>
> Cheers,
> Daniel
drm/exynos: Add atomic modesetting support
Hi Tobias, 2015-05-19 Tobias Jakobi : > OK, > > so Daniel helped me track down this issue. It came from an incorrect > 'clock-frequency' entry in my DTS. The freq was 50. Daniel recommended > 7060 which works 'fine' (and according to modetest produces a 59Hz > mode). I say 'fine' because I can't confirm that FIMD is actually working. I > just see that with that change I no longer get any div-by-zeros in the > kernel. That is good to hear! So maybe we are now ready to have the atomic modesetting patches merged in. I'll send a new version with the last fix to avoid crashes with null CRTC. > > So fimd_calc_clkdiv needs some sanitizing for 'ideal_clk' at least. > > What still bothers me though is the fact that FIMD actually gets enabled. > I'm just calling 'modetest -M exynos', so it's just doing probing. Why does > that trigger dpms? That comes from restore_fbdev_mode() when modetest closes the file descriptor, but I'm not sure why a update happens at this time. Gustavo
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #108 from N.Leiten --- (In reply to Alex Deucher from comment #102) > Created attachment 115802 [details] [review] > retry dpcd fetch > > Does this patch help? It didn't work for me, trying some other changes for now. -- 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/20150519/4e95d716/attachment-0001.html>
drm/exynos: Add atomic modesetting support
Hi, On 19 May 2015 at 19:43, Gustavo Padovan wrote: > 2015-05-19 Tobias Jakobi : >> so Daniel helped me track down this issue. It came from an incorrect >> 'clock-frequency' entry in my DTS. The freq was 50. Daniel recommended >> 7060 which works 'fine' (and according to modetest produces a 59Hz >> mode). I say 'fine' because I can't confirm that FIMD is actually working. I >> just see that with that change I no longer get any div-by-zeros in the >> kernel. > > That is good to hear! So maybe we are now ready to have the atomic > modesetting patches merged in. I'll send a new version with the last > fix to avoid crashes with null CRTC. Indeed. Though as he says below: >> So fimd_calc_clkdiv needs some sanitizing for 'ideal_clk' at least. It would be nice to: a) reject any mode with an impossible clock in mode_valid (filter connector modes) + mode_fixup (explicit request) b) WARN_ON and return during FIMD commit if clk_div ends up being zero >> What still bothers me though is the fact that FIMD actually gets enabled. >> I'm just calling 'modetest -M exynos', so it's just doing probing. Why does >> that trigger dpms? > > That comes from restore_fbdev_mode() when modetest closes the file > descriptor, but I'm not sure why a update happens at this time. It comes from lastclose: when the last client exits, DRM tries to restore the mode that fbcon was using. Quite why it didn't fail before this point (i.e. when doing it initially), I'm not quite sure, but oh well. Cheers, Daniel
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #109 from Alex Deucher --- (In reply to N.Leiten from comment #108) > (In reply to Alex Deucher from comment #102) > > Created attachment 115802 [details] [review] [review] > > retry dpcd fetch > > > > Does this patch help? > > It didn't work for me, trying some other changes for now. Please attach your dmesg output with attachment 115782 and attachment 115778 applied. -- 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/20150519/75a91ff4/attachment.html>
[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x
https://bugs.freedesktop.org/show_bug.cgi?id=90523 Bug ID: 90523 Summary: Easily reproducible GPU lockup (verde) with any mesa 10.5.x Product: Mesa Version: 10.5 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: acab at digitalfuture.it QA Contact: dri-devel at lists.freedesktop.org A few seconds into certain games the GPU locks up and X crashes. The same happens (albeit not as quickly) under other circumstances like playing a video in a browser. Last known good configuration is mesa 10.4.6. Known bad configurations: 10.5.1, 10.5.2, 10.5.4, 10.5.5. Are there any steps to follow to help diagnose the issue? -- 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/20150519/19246e8c/attachment.html>
[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x
https://bugs.freedesktop.org/show_bug.cgi?id=90523 acab at digitalfuture.it changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/b4ffac45/attachment.html>
[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x
https://bugs.freedesktop.org/show_bug.cgi?id=90523 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. -- 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/20150519/37896446/attachment.html>
[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x
https://bugs.freedesktop.org/show_bug.cgi?id=90523 --- Comment #2 from acab at digitalfuture.it --- I am sorry, but while trying to get a crash I've realized it's not mesa. The culprit appears to be llvm. In short: llvm 3.5.2 + mesa 10.5.5 -> ok llvm 3.6.0 + mesa 10.5.5 -> lockup I'm going to attach the logs anyway. Feel free to close this bug if it doesn't belong in 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/20150519/c36d5bd5/attachment.html>
[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x
https://bugs.freedesktop.org/show_bug.cgi?id=90523 --- Comment #3 from acab at digitalfuture.it --- Created attachment 115900 --> https://bugs.freedesktop.org/attachment.cgi?id=115900&action=edit 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/20150519/f5abc6be/attachment.html>
[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x
https://bugs.freedesktop.org/show_bug.cgi?id=90523 --- Comment #4 from acab at digitalfuture.it --- Created attachment 115901 --> https://bugs.freedesktop.org/attachment.cgi?id=115901&action=edit 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/20150519/c81e9a2c/attachment-0001.html>
[PATCH] drm: remove unused function 'drm_property_unreference_blob_locked'
This function was added recently but never used, and causes
a compile warning:
drivers/gpu/drm/drm_crtc.c:4324:13: warning:
'drm_property_unreference_blob_locked' defined but not used [-Wunused-function]
Removing that function avoids the warning. It can simply be put
back in case it is needed in the future.
Signed-off-by: Arnd Bergmann
Fixes: 6bcacf51d05 ("drm: Add reference counting to blob properties")
---
The broken patch is currently in
git://anongit.freedesktop.org/drm-intel#topic/drm-misc
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4059f065c854..6e60f71bbf46 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4313,25 +4313,6 @@ void drm_property_unreference_blob(struct
drm_property_blob *blob)
EXPORT_SYMBOL(drm_property_unreference_blob);
/**
- * drm_property_unreference_blob_locked - Unreference a blob property with
blob_lock held
- *
- * Drop a reference on a blob property. May free the object. This must be
- * called with blob_lock held.
- *
- * @param dev Device the blob was created on
- * @param blob Pointer to blob property
- */
-static void drm_property_unreference_blob_locked(struct drm_property_blob
*blob)
-{
- if (!blob)
- return;
-
- DRM_DEBUG("%p: blob ID: %d (%d)\n", blob, blob->base.id,
atomic_read(&blob->refcount.refcount));
-
- kref_put(&blob->refcount, drm_property_free_blob);
-}
-
-/**
* drm_property_reference_blob - Take a reference on an existing property
*
* Take a new reference on an existing blob property.
[PATCH] Do not loop on ERESTARTSYS using interruptible waits
This problem happens using KMS surfaces and QXL driver.
To easy reproduce use KDE Plasma (which use surfaces a lot) and assure
you are using KMS surfaces (QXL driver on Fedora/RedHat has a patch to
stop using them). Open some complex application like LibreOffice and
after a while your machine get stuck using 100% CPU on Xorg.
The problem occurs as creating new surfaces not interruptible wait
are used however instead of returning ERESTARTSYS back to userspace
you try to loop but wait routines always keep returning ERESTARTSYS
once the signal is marked.
On out of memory conditions TTM module try to move objects to system
memory and QXL assure surface is updated before the move.
The fix handle differently this case using no interruptible wait so
wait functions will wait instead of returning ERESTARTSYS.
Note the when the loop occurs driver will send a lot of update requests
causing more CPU usage on Qemu side too.
Signed-off-by: Frediano Ziglio
---
qxl/qxl_cmd.c | 12 +++-
qxl/qxl_drv.h | 2 +-
qxl/qxl_ioctl.c | 2 +-
3 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drivers/gpu/drm/qxl/qxl_cmd.c b/qxl/qxl_cmd.c
index 9782364..bd5404e 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -317,14 +317,11 @@ static void wait_for_io_cmd(struct qxl_device *qdev,
uint8_t val, long port)
{
int ret;
-restart:
ret = wait_for_io_cmd_user(qdev, val, port, false);
- if (ret == -ERESTARTSYS)
- goto restart;
}
int qxl_io_update_area(struct qxl_device *qdev, struct qxl_bo *surf,
- const struct qxl_rect *area)
+ const struct qxl_rect *area, bool intr)
{
int surface_id;
uint32_t surface_width, surface_height;
@@ -350,7 +347,7 @@ int qxl_io_update_area(struct qxl_device *qdev, struct
qxl_bo *surf,
mutex_lock(&qdev->update_area_mutex);
qdev->ram_header->update_area = *area;
qdev->ram_header->update_surface = surface_id;
- ret = wait_for_io_cmd_user(qdev, 0, QXL_IO_UPDATE_AREA_ASYNC, true);
+ ret = wait_for_io_cmd_user(qdev, 0, QXL_IO_UPDATE_AREA_ASYNC, intr);
mutex_unlock(&qdev->update_area_mutex);
return ret;
}
@@ -588,10 +585,7 @@ int qxl_update_surface(struct qxl_device *qdev, struct
qxl_bo *surf)
rect.right = surf->surf.width;
rect.top = 0;
rect.bottom = surf->surf.height;
-retry:
- ret = qxl_io_update_area(qdev, surf, &rect);
- if (ret == -ERESTARTSYS)
- goto retry;
+ ret = qxl_io_update_area(qdev, surf, &rect, false);
return ret;
}
diff --git a/drivers/gpu/drm/drivers/gpu/drm/qxl/qxl_drv.h b/qxl/qxl_drv.h
index 7c6cafe..6745c44 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -462,7 +462,7 @@ void qxl_io_memslot_add(struct qxl_device *qdev, uint8_t
id);
void qxl_io_notify_oom(struct qxl_device *qdev);
int qxl_io_update_area(struct qxl_device *qdev, struct qxl_bo *surf,
- const struct qxl_rect *area);
+ const struct qxl_rect *area, bool intr);
void qxl_io_reset(struct qxl_device *qdev);
void qxl_io_monitors_config(struct qxl_device *qdev);
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/qxl/qxl_ioctl.c
index b110883..afd7297 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -348,7 +348,7 @@ static int qxl_update_area_ioctl(struct drm_device *dev,
void *data,
goto out2;
if (!qobj->surface_id)
DRM_ERROR("got update area for surface with no id %d\n",
update_area->handle);
- ret = qxl_io_update_area(qdev, qobj, &area);
+ ret = qxl_io_update_area(qdev, qobj, &area, true);
out2:
qxl_bo_unreserve(qobj);
--
2.1.0
[PATCH 1/2] drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register name
Hi Vladimir,
Thanks for you patch.
On 2015å¹´05æ18æ¥ 20:32, Vladimir Zapolskiy wrote:
> I2CM_ADDRESS became a MESS, fix it, also change guarding define
> to __DW_HDMI_H__ , since the driver is not IMX specific.
>
> Signed-off-by: Vladimir Zapolskiy
Acked-by: Andy Yan
> ---
> drivers/gpu/drm/bridge/dw_hdmi.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.h
> b/drivers/gpu/drm/bridge/dw_hdmi.h
> index 175dbc8..ee7f7ed 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.h
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.h
> @@ -7,8 +7,8 @@
>* (at your option) any later version.
>*/
>
> -#ifndef __IMX_HDMI_H__
> -#define __IMX_HDMI_H__
> +#ifndef __DW_HDMI_H__
> +#define __DW_HDMI_H__
>
> /* Identification Registers */
> #define HDMI_DESIGN_ID 0x
> @@ -525,7 +525,7 @@
>
> /* I2C Master Registers (E-DDC) */
> #define HDMI_I2CM_SLAVE 0x7E00
> -#define HDMI_I2CMESS0x7E01
> +#define HDMI_I2CM_ADDRESS 0x7E01
> #define HDMI_I2CM_DATAO 0x7E02
> #define HDMI_I2CM_DATAI 0x7E03
> #define HDMI_I2CM_OPERATION 0x7E04
> @@ -1031,4 +1031,4 @@ enum {
> HDMI_A_VIDPOLCFG_HSYNCPOL_ACTIVE_LOW = 0x0,
> };
>
> -#endif /* __IMX_HDMI_H__ */
> +#endif /* __DW_HDMI_H__ */
[PATCH v2 1/2] clk: change clk_ops' ->round_rate() prototype
On 05/16, Mikko Perttunen wrote: > On 05/15/2015 06:40 PM, Boris Brezillon wrote: > >Hi Stephen, > > > >Adding Mikko in the loop (after all, he was the one complaining about > >this signed long limitation in the first place, and I forgot to add > >him in the Cc list :-/). > > I think I got it through linux-tegra anyway, but thanks :) > > > > >Mikko, are you okay with the approach proposed by Stephen (adding a > >new method) ? > > Yes, sounds good to me. If a driver uses the existing methods with > too large frequencies, the issue is pretty discoverable anyway. I > think "adjust_rate" sounds a bit too much like it sets the clock's > rate, though; perhaps "adjust_rate_request" or something like that? > Well I'm also OK with changing the determine_rate API one more time, but we'll have to be careful. Invariably someone will push a new clock driver through some non-clk tree path and we'll get build breakage. They shouldn't be doing that, so either we do the change now and push it to -next and see what breaks, or we do this after -rc1 comes out and make sure everyone has lots of warning. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[EDT][PATCh 1/1]mdfld_dsi_pkg_sender.c : Fix Possible NULL Pointer dereference
EP-AA9D1F29B02341529D96C06444D8471D
Hi,
There is NULL pointer check for sender after dereferencing sender in
__read_panel_data as below:-
struct drm_device *dev = sender->dev;
...
if (!sender || !data || !len)
And from codeflow
mdfld_dsi_get_panel_status --> mdfld_dsi_read_mcs --> __read_panel_data
In mdfld_dsi_get_panel_status & mdfld_dsi_read_mcs there is already a same
check.
---Cut
if (!sender || !data || !len) {
DRM_ERROR("Invalid parameters\n");
return -EINVAL;
}
return __read_panel_data(sender, MIPI_DSI_DCS_READ, &cmd, 1,
data, len, hs);
Cut---
So either we can remove this check from __read_panel_data ,
or if we want to have defensive code then below change should be included.
Subject: [PATCH 1/1] mdfld_dsi_pkg_sender.c : Initialize dev struct after NULL
check of sender
Signed-off-by: Maninder Singh
Reviewed-By: Vaneet Narang
---
drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
index 6b43ae3..6f2b2c9 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
@@ -520,7 +520,7 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender
*sender, u8 data_type,
u8 *data, u16 len, u32 *data_out, u16 len_out, bool hs)
{
unsigned long flags;
- struct drm_device *dev = sender->dev;
+ struct drm_device *dev;
int i;
u32 gen_data_reg;
int retry = MDFLD_DSI_READ_MAX_COUNT;
@@ -530,6 +530,8 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender
*sender, u8 data_type,
return -EINVAL;
}
+ dev = sender->dev;
+
/**
* do reading.
* 0) send out generic read request
--
1.7.1
Thanks
Maninder
[PATCH 00/12] treewide: Use DECLARE_BITMAP
Use the standard method to declare a bitmap array. Joe Perches (12): ARM: mach-imx: iomux-imx31: Use DECLARE_BITMAP dmaengine: rcar-dmac: Use DECLARE_BITMAP drm/amdkfd: Use DECLARE_BITMAP drm/radeon: Use DECLARE_BITMAP IB/ehca: Use DECLARE_BITMAP bcache: Use DECLARE_BITMAP spider_net: Use DECLARE_BITMAP s390/sclp: Use DECLARE_BITMAP [SCSI] qla4xxx: Use DECLARE_BITMAP scsi: Use DECLARE_BITMAP logfs: Use DECLARE_BITMAP sunrpc: Use DECLARE_BITMAP arch/arm/mach-imx/iomux-imx31.c | 2 +- drivers/dma/sh/rcar-dmac.c| 2 +- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 5 ++--- drivers/gpu/drm/radeon/radeon.h | 2 +- drivers/infiniband/hw/ehca/ipz_pt_fn.h| 2 +- drivers/md/bcache/journal.c | 2 +- drivers/net/ethernet/toshiba/spider_net.c | 3 +-- drivers/s390/char/sclp_cmd.c | 2 +- drivers/scsi/qla4xxx/ql4_def.h| 2 +- drivers/scsi/sr.c | 2 +- fs/logfs/logfs.h | 2 +- net/sunrpc/auth_gss/svcauth_gss.c | 2 +- 12 files changed, 13 insertions(+), 15 deletions(-) -- 2.1.2
[PATCH 04/12] drm/radeon: Use DECLARE_BITMAP
Use the generic mechanism to declare a bitmap instead of unsigned long.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/radeon/radeon.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 46eb0fa..d556733 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -719,7 +719,7 @@ struct radeon_doorbell {
resource_size_t size;
u32 __iomem *ptr;
u32 num_doorbells; /* Number of doorbells actually
reserved for radeon. */
- unsigned long used[DIV_ROUND_UP(RADEON_MAX_DOORBELLS,
BITS_PER_LONG)];
+ DECLARE_BITMAP(used, RADEON_MAX_DOORBELLS);
};
int radeon_doorbell_get(struct radeon_device *rdev, u32 *page);
--
2.1.2
[PATCH 03/12] drm/amdkfd: Use DECLARE_BITMAP
Use the generic mechanism to declare a bitmap instead of unsigned long.
It seems that "struct kfd_process.allocated_queue_bitmap" is unused.
Maybe it could be deleted instead.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index f21fcce..aba3e5d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -150,8 +150,7 @@ struct kfd_dev {
const struct kfd2kgd_calls *kfd2kgd;
struct mutex doorbell_mutex;
- unsigned long doorbell_available_index[DIV_ROUND_UP(
- KFD_MAX_NUM_OF_QUEUES_PER_PROCESS, BITS_PER_LONG)];
+ DECLARE_BITMAP(doorbell_available_index,
KFD_MAX_NUM_OF_QUEUES_PER_PROCESS);
void *gtt_mem;
uint64_t gtt_start_gpu_addr;
@@ -473,7 +472,7 @@ struct kfd_process {
/* Size is queue_array_size, up to MAX_PROCESS_QUEUES. */
struct kfd_queue **queues;
- unsigned long
allocated_queue_bitmap[DIV_ROUND_UP(KFD_MAX_NUM_OF_QUEUES_PER_PROCESS,
BITS_PER_LONG)];
+ DECLARE_BITMAP(allocated_queue_bitmap,
KFD_MAX_NUM_OF_QUEUES_PER_PROCESS);
/*Is the user space process 32 bit?*/
bool is_32bit_user_mode;
--
2.1.2
