Re: [PATCH] dt-bindings: display: rockchip: add document for rk3066 hdmi

[Johan Jonker]

Thanks for your advice.

On 2/25/19 5:59 PM, Rob Herring wrote:> On Fri, Feb 01, 2019 at
01:32:35PM +0100, Johan Jonker wrote:
>> This patch adds a binding that describes the HDMI controller for
>> rk3066.
>
> This is not using the DW block like other Rockchip SoCs (IIRC)?

As outsider it's a little bit difficult to comment on that.
Maybe an insider can give a better answer.
The rk3066 is there early model.
Reusing blocks like in the later improved models wasn't in the fashion
yet I think.
Also comparing the rk3066-hdmi driver to the inno driver gives too many
differences in registers, sound support and irqs.
If it was similar they would have combined it in there own kernel.
Given the age there won't come any other support for it.
This is what we have...

>
>>
>> Signed-off-by: Johan Jonker 
>> ---
>>  .../display/rockchip/rk3066_hdmi-rockchip.txt  | 60
++
>
> Using the compatible string plus '.txt' is the preferred naming.

Will change that in V2.
rk3066-hdmi  -> rk3066-hdmi-rockchip.txt

How about the other documents?
rk3036-inno-hdmi -> inno_hdmi-rockchip.txt
rk3288-dw-hdmi   -> dw_hdmi-rockchip.txt
rk3288-dp-> analogix_dp-rockchip.txt
etc.

>
>>  1 file changed, 60 insertions(+)
>>  create mode 100644
Documentation/devicetree/bindings/display/rockchip/rk3066_hdmi-rockchip.txt
>>
>> diff --git
a/Documentation/devicetree/bindings/display/rockchip/rk3066_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/rk3066_hdmi-rockchip.txt
>> new file mode 100644
>> index 0..6a8f3754f
>> --- /dev/null
>> +++
b/Documentation/devicetree/bindings/display/rockchip/rk3066_hdmi-rockchip.txt
>> @@ -0,0 +1,60 @@
>> +Rockchip specific extensions for rk3066 HDMI
>> +
>> +
>> +Required properties:
>> +- compatible:
>> +"rockchip,rk3066-hdmi";
>> +- reg:
>> +Physical base address and length of the controller's registers.
>> +- clocks, clock-names:
>> +Phandle to HDMI controller clock, name should be "hclk".
>> +- interrupts:
>> +HDMI interrupt number.
>> +- power-domains:
>> +Phandle to the RK3066_PD_VIO power domain.
>> +- rockchip,grf:
>> +This soc uses GRF regs to switch the HDMI TX input between vop0 and
vop1.
>> +- ports:

Should "ports" be replaced by: "hdmi_in: port"?
What is preferred?

There are two different methods in use:
-1
hdmi_in: port {

-2
ports {
hdmi_in: port {

>> +Contains one port node with two endpoints, numbered 0 and 1,
>> +connected respectively to vop0 and vop1.
>
> You should have an output port to an hdmi-connector node (or bridge) as
> well.

Which hdmi-connector node?
Could you explane with an example?
The Rockchip hdmi nodes I'm aware off only use the port nodes as a way
to switch the hdmi input between the vop's.
The vop nodes can have multiple outputs.

>
>> +- pinctrl-0, pinctrl-name:
>> +Switch the iomux for the HPD/I2C pins to HDMI function.
>> +
>> +Example:
>> +hdmi: hdmi@10116000 {
>> +compatible = "rockchip,rk3066-hdmi";
>> +reg = <0x10116000 0x2000>;
>> +interrupts = ;
>> +clocks = <&cru HCLK_HDMI>;
>> +clock-names = "hclk";
>> +power-domains = <&power RK3066_PD_VIO>;
>> +rockchip,grf = <&grf>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&hdmii2c_xfer>, <&hdmi_hpd>;
>> +status = "disabled";
>
> Don't show status in examples.

Will change that in V2.

>
>> +
>> +hdmi_in: port {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +hdmi_in_vop0: endpoint@0 {
>> +reg = <0>;
>> +remote-endpoint = <&vop0_out_hdmi>;
>> +};
>> +hdmi_in_vop1: endpoint@1 {
>> +reg = <1>;
>> +remote-endpoint = <&vop1_out_hdmi>;
>> +};
>> +};
>> +};
>> +
>> +&pinctrl {
>> +hdmi {
>> +hdmi_hpd: hdmi-hpd {
>> +rockchip,pins = <0 RK_PA0 1 &pcfg_pull_default>;
>> +};
>> +hdmii2c_xfer: hdmii2c-xfer {
>> +rockchip,pins = <0 RK_PA1 1 &pcfg_pull_none>,
>> +<0 RK_PA2 1 &pcfg_pull_none>;
>> +};
>> +};
>> +};
>> --
>> 2.11.0
>>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/7] drm: atmel-hlcdc: avoid initializing cfg with zero

[Claudiu.Beznea]

From: Claudiu Beznea 

Remove cfg initialization with zero and read state with
drm_crtc_state_to_atmel_hlcdc_crtc_state() so that cfg to be initialized
with state's output_mode.

Signed-off-by: Claudiu Beznea 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 17a7a18f6a07..7b0c6683a690 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -138,7 +138,8 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
 
regmap_update_bits(regmap, ATMEL_HLCDC_CFG(0), mask, cfg);
 
-   cfg = 0;
+   state = drm_crtc_state_to_atmel_hlcdc_crtc_state(c->state);
+   cfg = state->output_mode << 8;
 
if (adj->flags & DRM_MODE_FLAG_NVSYNC)
cfg |= ATMEL_HLCDC_VSPOL;
@@ -146,9 +147,6 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
if (adj->flags & DRM_MODE_FLAG_NHSYNC)
cfg |= ATMEL_HLCDC_HSPOL;
 
-   state = drm_crtc_state_to_atmel_hlcdc_crtc_state(c->state);
-   cfg |= state->output_mode << 8;
-
regmap_update_bits(regmap, ATMEL_HLCDC_CFG(5),
   ATMEL_HLCDC_HSPOL | ATMEL_HLCDC_VSPOL |
   ATMEL_HLCDC_VSPDLYS | ATMEL_HLCDC_VSPDLYE |
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] drm: atmel-hlcdc: add config option for clock selection

[Claudiu.Beznea]

From: Claudiu Beznea 

SAM9x60 LCD Controller has no option to select clock source as previous
controllers have. To be able to use the same driver even for this LCD
controller add a config option to know if controller supports this.

Signed-off-by: Claudiu Beznea 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 12 +++-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   |  2 ++
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 8070a558d7b1..17a7a18f6a07 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -78,7 +78,8 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc *c)
unsigned long mode_rate;
struct videomode vm;
unsigned long prate;
-   unsigned int cfg;
+   unsigned int mask = ATMEL_HLCDC_CLKDIV_MASK | ATMEL_HLCDC_CLKPOL;
+   unsigned int cfg = 0;
int div;
 
vm.vfront_porch = adj->crtc_vsync_start - adj->crtc_vdisplay;
@@ -101,7 +102,10 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
 (adj->crtc_hdisplay - 1) |
 ((adj->crtc_vdisplay - 1) << 16));
 
-   cfg = ATMEL_HLCDC_CLKSEL;
+   if (!crtc->dc->desc->fixed_clksrc) {
+   cfg = ATMEL_HLCDC_CLKSEL;
+   mask |= ATMEL_HLCDC_CLKSEL;
+   }
 
prate = 2 * clk_get_rate(crtc->dc->hlcdc->sys_clk);
mode_rate = adj->crtc_clock * 1000;
@@ -132,9 +136,7 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
 
cfg |= ATMEL_HLCDC_CLKDIV(div);
 
-   regmap_update_bits(regmap, ATMEL_HLCDC_CFG(0),
-  ATMEL_HLCDC_CLKSEL | ATMEL_HLCDC_CLKDIV_MASK |
-  ATMEL_HLCDC_CLKPOL, cfg);
+   regmap_update_bits(regmap, ATMEL_HLCDC_CFG(0), mask, cfg);
 
cfg = 0;
 
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 70bd540d644e..0155efb9c443 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -328,6 +328,7 @@ atmel_hlcdc_layer_to_plane(struct atmel_hlcdc_layer *layer)
  * @max_hpw: maximum horizontal back/front porch width
  * @conflicting_output_formats: true if RGBXXX output formats conflict with
  * each other.
+ * @fixed_clksrc: true if clock source is fixed
  * @layers: a layer description table describing available layers
  * @nlayers: layer description table size
  */
@@ -340,6 +341,7 @@ struct atmel_hlcdc_dc_desc {
int max_vpw;
int max_hpw;
bool conflicting_output_formats;
+   bool fixed_clksrc;
const struct atmel_hlcdc_layer_desc *layers;
int nlayers;
 };
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] pwm: atmel-hlcdc: add compatible for SAM9X60 HLCDC's PWM

[Claudiu.Beznea]

From: Claudiu Beznea 

Add compatible string for SAM9X60 HLCDC's PWM.

Signed-off-by: Claudiu Beznea 
---
 drivers/pwm/pwm-atmel-hlcdc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
index 54c6633d9b5d..331ca0233d9e 100644
--- a/drivers/pwm/pwm-atmel-hlcdc.c
+++ b/drivers/pwm/pwm-atmel-hlcdc.c
@@ -246,6 +246,9 @@ static const struct of_device_id atmel_hlcdc_dt_ids[] = {
.compatible = "atmel,sama5d4-hlcdc",
.data = &atmel_hlcdc_pwm_sama5d3_errata,
},
+   {
+   .compatible = "microchip,sam9x60-hlcdc",
+   },
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, atmel_hlcdc_dt_ids);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1] drm/tegra: plane: Remove format-modifier checking

[Dmitry Osipenko]

24.02.2019 18:34, Dmitry Osipenko пишет:
> Tiling modifier can't be applied to YV12 video overlay because all tiling
> modifiers are filtered out for multi-plane formats. AFAIK, all modifiers
> should work with all of formats, hence the checking is incorrect and
> simply not needed.
> 
> Fixes: e90124cb46bdb ("drm/tegra: plane: Support format modifiers")
> Signed-off-by: Dmitry Osipenko 
> ---

For the reference.. this patch needs a stable tag, I did the same mistake in 
[0]. Thierry, please let me know if you're okay with the change and if you 
could add the tag while applying the patch, thanks.

[0] https://lkml.org/lkml/2019/2/26/277
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/7] drm: atmel-hlcdc: add sam9x60 LCD controller

[Claudiu.Beznea]

From: Sandeep Sheriker Mallikarjun 

Add the LCD controller for SAM9X60.

Signed-off-by: Sandeep Sheriker Mallikarjun 

[claudiu.bez...@microchip.com: add fixed_clksrc option to
 atmel_hlcdc_dc_sam9x60]
Signed-off-by: Claudiu Beznea 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 101 +++
 1 file changed, 101 insertions(+)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 8bf51f853721..fb2e7646daeb 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -364,6 +364,103 @@ static const struct atmel_hlcdc_dc_desc 
atmel_hlcdc_dc_sama5d4 = {
.nlayers = ARRAY_SIZE(atmel_hlcdc_sama5d4_layers),
.layers = atmel_hlcdc_sama5d4_layers,
 };
+
+static const struct atmel_hlcdc_layer_desc atmel_hlcdc_sam9x60_layers[] = {
+   {
+   .name = "base",
+   .formats = &atmel_hlcdc_plane_rgb_formats,
+   .regs_offset = 0x60,
+   .id = 0,
+   .type = ATMEL_HLCDC_BASE_LAYER,
+   .cfgs_offset = 0x2c,
+   .layout = {
+   .xstride = { 2 },
+   .default_color = 3,
+   .general_config = 4,
+   .disc_pos = 5,
+   .disc_size = 6,
+   },
+   .clut_offset = 0x600,
+   },
+   {
+   .name = "overlay1",
+   .formats = &atmel_hlcdc_plane_rgb_formats,
+   .regs_offset = 0x160,
+   .id = 1,
+   .type = ATMEL_HLCDC_OVERLAY_LAYER,
+   .cfgs_offset = 0x2c,
+   .layout = {
+   .pos = 2,
+   .size = 3,
+   .xstride = { 4 },
+   .pstride = { 5 },
+   .default_color = 6,
+   .chroma_key = 7,
+   .chroma_key_mask = 8,
+   .general_config = 9,
+   },
+   .clut_offset = 0xa00,
+   },
+   {
+   .name = "overlay2",
+   .formats = &atmel_hlcdc_plane_rgb_formats,
+   .regs_offset = 0x260,
+   .id = 2,
+   .type = ATMEL_HLCDC_OVERLAY_LAYER,
+   .cfgs_offset = 0x2c,
+   .layout = {
+   .pos = 2,
+   .size = 3,
+   .xstride = { 4 },
+   .pstride = { 5 },
+   .default_color = 6,
+   .chroma_key = 7,
+   .chroma_key_mask = 8,
+   .general_config = 9,
+   },
+   .clut_offset = 0xe00,
+   },
+   {
+   .name = "high-end-overlay",
+   .formats = &atmel_hlcdc_plane_rgb_and_yuv_formats,
+   .regs_offset = 0x360,
+   .id = 3,
+   .type = ATMEL_HLCDC_OVERLAY_LAYER,
+   .cfgs_offset = 0x4c,
+   .layout = {
+   .pos = 2,
+   .size = 3,
+   .memsize = 4,
+   .xstride = { 5, 7 },
+   .pstride = { 6, 8 },
+   .default_color = 9,
+   .chroma_key = 10,
+   .chroma_key_mask = 11,
+   .general_config = 12,
+   .scaler_config = 13,
+   .phicoeffs = {
+   .x = 17,
+   .y = 33,
+   },
+   .csc = 14,
+   },
+   .clut_offset = 0x1200,
+   },
+};
+
+static const struct atmel_hlcdc_dc_desc atmel_hlcdc_dc_sam9x60 = {
+   .min_width = 0,
+   .min_height = 0,
+   .max_width = 2048,
+   .max_height = 2048,
+   .max_spw = 0xff,
+   .max_vpw = 0xff,
+   .max_hpw = 0x3ff,
+   .fixed_clksrc = true,
+   .nlayers = ARRAY_SIZE(atmel_hlcdc_sam9x60_layers),
+   .layers = atmel_hlcdc_sam9x60_layers,
+};
+
 static const struct of_device_id atmel_hlcdc_of_match[] = {
{
.compatible = "atmel,at91sam9n12-hlcdc",
@@ -385,6 +482,10 @@ static const struct of_device_id atmel_hlcdc_of_match[] = {
.compatible = "atmel,sama5d4-hlcdc",
.data = &atmel_hlcdc_dc_sama5d4,
},
+   {
+   .compatible = "microchip,sam9x60-hlcdc",
+   .data = &atmel_hlcdc_dc_sam9x60,
+   },
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, atmel_hlcdc_of_match);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: fix use-after-free when drm_gem_handle_create() fails

[Dmitry Vyukov]

On Thu, Feb 28, 2019 at 12:12 AM Rodrigo Siqueira
 wrote:
>
> On 02/26, Eric Biggers wrote:
> > From: Eric Biggers 
> >
> > If drm_gem_handle_create() fails in vkms_gem_create(), then the
> > vkms_gem_object is freed twice: once when the reference is dropped by
> > drm_gem_object_put_unlocked(), and again by the extra calls to
> > drm_gem_object_release() and kfree().
> >
> > Fix it by skipping the second release and free.
> >
> > This bug was originally found in the vgem driver by syzkaller using
> > fault injection, but I noticed it's also present in the vkms driver.
> >
> > Fixes: 559e50fd34d1 ("drm/vkms: Add dumb operations")
> > Cc: Rodrigo Siqueira 
> > Cc: Haneen Mohammed 
> > Cc: Daniel Vetter 
> > Cc: Chris Wilson 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Eric Biggers 
> > ---
> >  drivers/gpu/drm/vkms/vkms_gem.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_gem.c 
> > b/drivers/gpu/drm/vkms/vkms_gem.c
> > index 138b0bb325cf9..69048e73377dc 100644
> > --- a/drivers/gpu/drm/vkms/vkms_gem.c
> > +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> > @@ -111,11 +111,8 @@ struct drm_gem_object *vkms_gem_create(struct 
> > drm_device *dev,
> >
> >   ret = drm_gem_handle_create(file, &obj->gem, handle);
> >   drm_gem_object_put_unlocked(&obj->gem);
> > - if (ret) {
> > - drm_gem_object_release(&obj->gem);
> > - kfree(obj);
> > + if (ret)
> >   return ERR_PTR(ret);
> > - }
> >
> >   return &obj->gem;
> >  }
> > --
> > 2.21.0.rc2.261.ga7da99ff1b-goog
> >
>
> Hi,
>
> Thanks for your patch! :)
>
> The patch looks good for me. I also tested it under the IGT tests on my
> local VM and everything was fine.

Hi Rodrigo,

What are IGT tests? How can I run them?

>
> Reviewed-by: Rodrigo Siqueira 
>
> --
> Rodrigo Siqueira
> https://siqueira.tech
> Graduate Student
> Department of Computer Science
> University of São Paulo
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/syzkaller-bugs/20190227231202.tycdbcqtk5ylwp4k%40smtp.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/7] add LCD support for SAM9X60

[Claudiu.Beznea]

From: Claudiu Beznea 

Hi,

These patches adds support for SAM9X60's LCD controller.

First patches add option to specify if controller clock source is fixed.
Second patch avoid a variable initialization in 
atmel_hlcdc_crtc_mode_set_nofb().
The 3rd one adds specific bindings for SAM9X60 LCD controller.
The 4th and 5th add compatibles in the driver.
The 6th patch enables sys_clk in probe since SAM9X60 needs this.
Specific support was added also in suspend/resume hooks.
The work in the 6th patch was done based on support added in 1st patch.
The 7th patch adds SAM9X60's LCD configuration and enabled it. 

I kept a big series including PWM, MFD, LCD changes due to shared DT
bindings. If you prefer, I'm available to send them separately. Please let
me know.

Thank you,
Claudiu Beznea

Claudiu Beznea (5):
  drm: atmel-hlcdc: add config option for clock selection
  drm: atmel-hlcdc: avoid initializing cfg with zero
  dt-bindings: mfd: add bindings for SAM9X60 HLCD controller
  mfd: atmel-hlcdc: add compatible for SAM9X60 HLCD controller
  pwm: atmel-hlcdc: add compatible for SAM9X60 HLCDC's PWM

Sandeep Sheriker Mallikarjun (2):
  drm: atmel-hlcdc: enable sys_clk during initalization.
  drm: atmel-hlcdc: add sam9x60 LCD controller

 .../devicetree/bindings/mfd/atmel-hlcdc.txt|   1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |  17 ++-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 120 -
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   |   2 +
 drivers/mfd/atmel-hlcdc.c  |   1 +
 drivers/pwm/pwm-atmel-hlcdc.c  |   3 +
 6 files changed, 134 insertions(+), 10 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/7] mfd: atmel-hlcdc: add compatible for SAM9X60 HLCD controller

[Claudiu.Beznea]

From: Claudiu Beznea 

Add compatible for SAM9X60 HLCD controller.

Signed-off-by: Claudiu Beznea 
---
 drivers/mfd/atmel-hlcdc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/atmel-hlcdc.c b/drivers/mfd/atmel-hlcdc.c
index e82543bcfdc8..35a9e16f9902 100644
--- a/drivers/mfd/atmel-hlcdc.c
+++ b/drivers/mfd/atmel-hlcdc.c
@@ -141,6 +141,7 @@ static const struct of_device_id atmel_hlcdc_match[] = {
{ .compatible = "atmel,sama5d2-hlcdc" },
{ .compatible = "atmel,sama5d3-hlcdc" },
{ .compatible = "atmel,sama5d4-hlcdc" },
+   { .compatible = "microchip,sam9x60-hlcdc" },
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, atmel_hlcdc_match);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/7] drm: atmel-hlcdc: enable sys_clk during initalization.

[Claudiu.Beznea]

From: Sandeep Sheriker Mallikarjun 

For SAM9X60 SoC, sys_clk is through lcd_gclk clock source and this
needs to be enabled before enabling lcd_clk.

Signed-off-by: Sandeep Sheriker Mallikarjun 

[claudiu.bez...@microchip.com: add fixed_clksrc checks]
Signed-off-by: Claudiu Beznea 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 0be13eceedba..8bf51f853721 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -625,10 +625,18 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
dc->hlcdc = dev_get_drvdata(dev->dev->parent);
dev->dev_private = dc;
 
+   if (dc->desc->fixed_clksrc) {
+   ret = clk_prepare_enable(dc->hlcdc->sys_clk);
+   if (ret) {
+   dev_err(dev->dev, "failed to enable sys_clk\n");
+   goto err_destroy_wq;
+   }
+   }
+
ret = clk_prepare_enable(dc->hlcdc->periph_clk);
if (ret) {
dev_err(dev->dev, "failed to enable periph_clk\n");
-   goto err_destroy_wq;
+   goto err_sys_clk_disable;
}
 
pm_runtime_enable(dev->dev);
@@ -664,6 +672,9 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
 err_periph_clk_disable:
pm_runtime_disable(dev->dev);
clk_disable_unprepare(dc->hlcdc->periph_clk);
+err_sys_clk_disable:
+   if (dc->desc->fixed_clksrc)
+   clk_disable_unprepare(dc->hlcdc->sys_clk);
 
 err_destroy_wq:
destroy_workqueue(dc->wq);
@@ -688,6 +699,8 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
 
pm_runtime_disable(dev->dev);
clk_disable_unprepare(dc->hlcdc->periph_clk);
+   if (dc->desc->fixed_clksrc)
+   clk_disable_unprepare(dc->hlcdc->sys_clk);
destroy_workqueue(dc->wq);
 }
 
@@ -805,6 +818,8 @@ static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
regmap_read(regmap, ATMEL_HLCDC_IMR, &dc->suspend.imr);
regmap_write(regmap, ATMEL_HLCDC_IDR, dc->suspend.imr);
clk_disable_unprepare(dc->hlcdc->periph_clk);
+   if (dc->desc->fixed_clksrc)
+   clk_disable_unprepare(dc->hlcdc->sys_clk);
 
return 0;
 }
@@ -814,6 +829,8 @@ static int atmel_hlcdc_dc_drm_resume(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct atmel_hlcdc_dc *dc = drm_dev->dev_private;
 
+   if (dc->desc->fixed_clksrc)
+   clk_prepare_enable(dc->hlcdc->sys_clk);
clk_prepare_enable(dc->hlcdc->periph_clk);
regmap_write(dc->hlcdc->regmap, ATMEL_HLCDC_IER, dc->suspend.imr);
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/7] dt-bindings: mfd: add bindings for SAM9X60 HLCD controller

[Claudiu.Beznea]

From: Claudiu Beznea 

Add new compatible string for the HLCD controller on SAM9X60 SoC.

Signed-off-by: Claudiu Beznea 
---
 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt 
b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
index 3f643ef121ff..5f8880cc757e 100644
--- a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
+++ b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
@@ -7,6 +7,7 @@ Required properties:
"atmel,sama5d2-hlcdc"
"atmel,sama5d3-hlcdc"
"atmel,sama5d4-hlcdc"
+   "microchip,sam9x60-hlcdc"
  - reg: base address and size of the HLCDC device registers.
  - clock-names: the name of the 3 clocks requested by the HLCDC device.
Should contain "periph_clk", "sys_clk" and "slow_clk".
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH libdrm 2/2] tests/amdgpu: add memcpy dispatch test

[Zhang, Hawking]

Reviewed-by: Hawking Zhang 

Regards,
Hawking
-Original Message-
From: amd-gfx  On Behalf Of Cui, Flora
Sent: 2019年2月28日 13:44
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Cui, Flora 
Subject: [PATCH libdrm 2/2] tests/amdgpu: add memcpy dispatch test

add memcpy dispatch test for gfx9

Change-Id: If433434c5378f3b318209d4e28c19d7ce9cff1a2
Signed-off-by: Flora Cui 
Tested-by: Rui Teng 
---
 tests/amdgpu/basic_tests.c | 129 +
 1 file changed, 129 insertions(+)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c index 
d4b0faf..9d2cc95 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -305,6 +305,11 @@ static const uint32_t 
bufferclear_cs_shader_registers_gfx9[][2] = {
 
 static const uint32_t bufferclear_cs_shader_registers_num_gfx9 = 5;
 
+static const uint32_t buffercopy_cs_shader_gfx9[] = {
+0xD1FD, 0x04010C08, 0xE00C2000, 0x8100,
+0xBF8C0F70, 0xE01C2000, 0x80010100, 0xBF81 };
+
 int amdgpu_bo_alloc_and_map_raw(amdgpu_device_handle dev, unsigned size,
unsigned alignment, unsigned heap, uint64_t alloc_flags,
uint64_t mapping_flags, amdgpu_bo_handle *bo, void 
**cpu, @@ -2084,6 +2089,128 @@ static void amdgpu_memset_dispatch_test(uint32_t 
ip_type)
 
r = amdgpu_bo_unmap_and_free(bo_shader, va_shader, mc_address_shader, 
bo_shader_size);
CU_ASSERT_EQUAL(r, 0);
+
+   r = amdgpu_cs_ctx_free(context_handle);
+   CU_ASSERT_EQUAL(r, 0);
+}
+
+static void amdgpu_memcpy_dispatch_test(uint32_t ip_type) {
+   amdgpu_context_handle context_handle;
+   amdgpu_bo_handle bo_src, bo_dst, bo_shader, resources[3];
+   volatile unsigned char *ptr_dst;
+   void *ptr_shader;
+   void *ptr_src;
+   uint64_t mc_address_src, mc_address_dst, mc_address_shader;
+   amdgpu_va_handle va_src, va_dst, va_shader;
+   int i, j, r;
+   uint32_t *ptr;
+   int bo_dst_size = 16384;
+   int bo_shader_size = 4096;
+   struct amdgpu_cs_request ibs_request = {0};
+   struct amdgpu_cs_ib_info ib_info= {0};
+   uint32_t version, ring_id;
+   struct drm_amdgpu_info_hw_ip info;
+
+   r = amdgpu_query_hw_ip_info(device_handle, ip_type, 0, &info);
+   CU_ASSERT_EQUAL(r, 0);
+
+   version = info.hw_ip_version_major;
+   if (version != 9) {
+   printf("\tSkip...memcpy dispatch test is only supported with 
gfx9\n");
+   return;
+   }
+
+   ptr = calloc(256, sizeof(*ptr));
+   CU_ASSERT_NOT_EQUAL(ptr, NULL);
+
+   r = amdgpu_cs_ctx_create(device_handle, &context_handle);
+   CU_ASSERT_EQUAL(r, 0);
+
+   r = amdgpu_bo_alloc_and_map(device_handle, bo_shader_size, 4096,
+   AMDGPU_GEM_DOMAIN_VRAM, 0,
+   &bo_shader, &ptr_shader,
+   &mc_address_shader, &va_shader);
+   CU_ASSERT_EQUAL(r, 0);
+
+   memcpy(ptr_shader, buffercopy_cs_shader_gfx9, 
+sizeof(buffercopy_cs_shader_gfx9));
+
+   for (ring_id = 0; (1 << ring_id) & info.available_rings; ring_id++) {
+   r = amdgpu_bo_alloc_and_map(device_handle, bo_dst_size, 4096,
+   AMDGPU_GEM_DOMAIN_VRAM, 0,
+   &bo_src, &ptr_src,
+   &mc_address_src, &va_src);
+   CU_ASSERT_EQUAL(r, 0);
+
+   r = amdgpu_bo_alloc_and_map(device_handle, bo_dst_size, 4096,
+   AMDGPU_GEM_DOMAIN_VRAM, 0,
+   &bo_dst, &ptr_dst,
+   &mc_address_dst, &va_dst);
+   CU_ASSERT_EQUAL(r, 0);
+
+   memset(ptr_src, 0x55, bo_dst_size);
+
+   i = 0;
+   i += amdgpu_dispatch_init(ip_type, version, ptr + i);
+
+   /*  Issue commands to set cu mask used in current dispatch */
+   i += amdgpu_dispatch_write_cumask(ip_type, version, ptr + i);
+
+   /* Writes shader state to HW */
+   i += amdgpu_dispatch_write2hw(ip_type, version, ptr + i, 
+mc_address_shader);
+
+   /* Write constant data */
+   /* Writes the texture resource constants data to the SGPRs */
+   ptr[i++] = PACKET3_COMPUTE(PKT3_SET_SH_REG, 4);
+   ptr[i++] = 0x240;
+   ptr[i++] = mc_address_src;
+   ptr[i++] = (mc_address_src > 32) | 0x10;
+   ptr[i++] = 0x400;
+   ptr[i++] = 0x74fac;
+   /* Writes the UAV constant data to the SGPRs. */
+   ptr[i++] = PACKET3_COMPUTE(PKT3_SET_SH_REG, 4);
+   ptr[i++] = 0x244;
+   ptr[i++] = mc_address_dst;
+   ptr[i++] = (mc_address_dst > 32) | 0x10;
+ 

Re: AFBC versions modifiers

[Neil Armstrong]

Hi,

On 27/02/2019 16:41, Ayan Halder wrote:
> Hi Neil,
> 
> AFBC 1.0 does not support (ignoring common prefix AFBC_FORMAT_MOD_) 
> BLOCK_SIZE_32x8, BLOCK_SIZE_64x4, BLOCK_SIZE_32x8_64x4
> CBR, TILED, SC, DB and BCH  modifiers.
> 
> AFBC 1.2 does not support BLOCK_SIZE_64x4, BLOCK_SIZE_32x8_64x4, DB and BCH 
> modifiers.

It's useful

> 
> Beyond that it's very hard to say. The AFBC version numbers refer to versions 
> of the specification, but aren't very useful for describing the actual 
> bitstream format.
> To determine which modifiers _are_ supported, you will really need to get 
> technical documentation from the SoC vendor

OK

Thanks,
Neil

> 
> Regards,
> Ayan Kumar Halder
> 
> --
> *From:* Neil Armstrong 
> *Sent:* Tuesday, February 26, 2019 2:15 PM
> *To:* Ayan Halder; Liviu Dudau
> *Cc:* DRI Development
> *Subject:* AFBC versions modifiers
>  
> Hi Ayan,
> 
> Could you help distinguish which are the AFBC modifiers for each version of 
> AFBC ?
> 
> The Amlogic SoCs embeds an AFBC 1.0 compatible decoder, then the newer SoCs 
> embeds an AFBC 1.2 decoder,
> I assume the modifiers before the patch "drm/fourcc: Add modifier 
> defininitions for AFBC 1.3" are
> valid for AFBC 1.2, but what is the subset for 1.0 and 1.1 ?
> 
> Thanks,
> Neil
> 
> -- 
> Neil Armstrong
> Embedded Linux Software Engineer
> BayLibre - At the Heart of Embedded Linux
> www.baylibre.com 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/bochs: Drop best_encoder

[Gerd Hoffmann]

On Thu, Feb 21, 2019 at 04:58:57PM +0100, Daniel Vetter wrote:
> This is the default for atomic drivers.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Gerd Hoffmann 
> Cc: virtualizat...@lists.linux-foundation.org
> ---
>  drivers/gpu/drm/bochs/bochs_kms.c | 11 ---
>  1 file changed, 11 deletions(-)

Pushed to drm-misc-next.

thanks,
  Gerd

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109749] FreeSync stutters if framerate is less than refresh rate and vsync/flipping is on

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109749

--- Comment #3 from Michel Dänzer  ---
(In reply to bmilreu from comment #2)
> Fix was pushed to 5.0, should we mark this as resolved for now?

You're the reporter, if you consider it resolved, please mark it as such.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v4 08/17] kunit: test: add support for test abort

[Brendan Higgins]

On Tue, Feb 26, 2019 at 12:35 PM Stephen Boyd  wrote:
>
> Quoting Brendan Higgins (2019-02-14 13:37:20)
> > Add support for aborting/bailing out of test cases. Needed for
> > implementing assertions.
>
> Can you add some more text here with the motivating reasons for
> implementing assertions and bailing out of test cases?

Sure. Yeah, this comes before the commit that adds assertions, so I
should probably put a better explanation here.
>
> For example, I wonder why unit tests can't just return with a failure

Well, you could. You can just do the check as you would without KUnit,
except call KUNIT_FAIL(...) before you return. For example, instead
of:

KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);

you could do:

if (IS_ERR_OR_NULL(ptr)) {
KUNIT_FAIL(test, "ptr is an errno or null: %ld", ptr);
return;
}

> when they need to abort and then the test runner would detect that error
> via the return value from the 'run test' function. That would be a more
> direct approach, but also more verbose than a single KUNIT_ASSERT()
> line. It would be more kernel idiomatic too because the control flow

Yeah, I was intentionally going against that idiom. I think that idiom
makes test logic more complicated than it needs to be, especially if
the assertion failure happens in a helper function; then you have to
pass that error all the way back up. It is important that test code
should be as simple as possible to the point of being immediately
obviously correct at first glance because there are no tests for
tests.

The idea with assertions is that you use them to state all the
preconditions for your test. Logically speaking, these are the
premises of the test case, so if a premise isn't true, there is no
point in continuing the test case because there are no conclusions
that can be drawn without the premises. Whereas, the expectation is
the thing you are trying to prove. It is not used universally in
x-unit style test frameworks, but I really like it as a convention.
You could still express the idea of a premise using the above idiom,
but I think KUNIT_ASSERT_* states the intended idea perfectly.

> isn't hidden inside a macro and it isn't intimately connected with
> kthreads and completions.

Yeah, I wasn't a fan of that myself, but it was broadly available. My
previous version (still the architecture specific version for UML, not
in this patchset though) relies on UML_LONGJMP, but is obviously only
works on UML. A number of people wanted support for other
architectures. Rob and Luis specifically wanted me to provide a
version of abort that would work on any architecture, even if it only
had reduced functionality; I thought this fit the bill okay.

>
> >
> > Signed-off-by: Brendan Higgins 
> [...]
> > diff --git a/kunit/test-test.c b/kunit/test-test.c
> > new file mode 100644
> > index 0..a936c041f1c8f
>
> Could this whole file be another patch? It seems to be a test for the
> try catch mechanism.

Sure.

>
> > diff --git a/kunit/test.c b/kunit/test.c
> > index d18c50d5ed671..6e5244642ab07 100644
> > --- a/kunit/test.c
> > +++ b/kunit/test.c
> [...]
> > +
> > +static void kunit_generic_throw(struct kunit_try_catch *try_catch)
> > +{
> > +   try_catch->context.try_result = -EFAULT;
> > +   complete_and_exit(try_catch->context.try_completion, -EFAULT);
> > +}
> > +
> > +static int kunit_generic_run_threadfn_adapter(void *data)
> > +{
> > +   struct kunit_try_catch *try_catch = data;
> >
> > +   try_catch->try(&try_catch->context);
> > +
> > +   complete_and_exit(try_catch->context.try_completion, 0);
>
> The exit code doesn't matter, right? If so, it might be clearer to just
> return 0 from this function because kthreads exit themselves as far as I
> recall.

You mean complete and then return?

>
> > +}
> > +
> > +static void kunit_generic_run_try_catch(struct kunit_try_catch *try_catch)
> > +{
> > +   struct task_struct *task_struct;
> > +   struct kunit *test = try_catch->context.test;
> > +   int exit_code, wake_result;
> > +   DECLARE_COMPLETION(test_case_completion);
>
> DECLARE_COMPLETION_ONSTACK()?

Whoops, yeah, that one.

>
> > +
> > +   try_catch->context.try_completion = &test_case_completion;
> > +   try_catch->context.try_result = 0;
> > +   task_struct = kthread_create(kunit_generic_run_threadfn_adapter,
> > +try_catch,
> > +"kunit_try_catch_thread");
> > +   if (IS_ERR_OR_NULL(task_struct)) {
>
> It looks like NULL is never returned from kthread_create(), so don't
> check for it here.

Bad habit, sorry.

>
> > +   try_catch->catch(&try_catch->context);
> > +   return;
> > +   }
> > +
> > +   wake_result = wake_up_process(task_struct);
> > +   if (wake_result != 0 && wake_result != 1) {
>
> These are the only two possible return values of wake_up_process(), so
> why not just use kthread_run() and check for an error o

[Bug 109649] [bisected][raven] gfx ring timeout when running clover apps

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109649

Jan Vesely  changed:

   What|Removed |Added

Summary|[raven] gfx ring timeout|[bisected][raven] gfx ring
   |when running clover apps|timeout when running clover
   ||apps
 CC||christian.koe...@amd.com

--- Comment #1 from Jan Vesely  ---
Bisection shows that the first bad commit is:
commit 09b6f25b55d9c66af7302e1f09ad90aa5b1dfbcb (HEAD, refs/bisect/bad)
Author: Christian König 
Date:   Wed Aug 15 14:04:47 2018 +0200

drm/amdgpu: fix VM size reporting on Raven

Raven doesn't have an VCE block and so also no buggy VCE firmware.

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
Reviewed-by: Huang Rui 
Acked-by: Chunming Zhou 
Signed-off-by: Alex Deucher 

I guess there is other buggy firmware/limitation?

# cat /sys/kernel/debug/dri/0/amdgpu_firmware_info 
VCE feature version: 0, firmware version: 0x
UVD feature version: 0, firmware version: 0x
MC feature version: 0, firmware version: 0x
ME feature version: 40, firmware version: 0x0099
PFP feature version: 40, firmware version: 0x00ae
CE feature version: 40, firmware version: 0x004d
RLC feature version: 1, firmware version: 0xd237
RLC SRLC feature version: 1, firmware version: 0x0001
RLC SRLG feature version: 1, firmware version: 0x0001
RLC SRLS feature version: 1, firmware version: 0x0001
MEC feature version: 40, firmware version: 0x018b
MEC2 feature version: 40, firmware version: 0x018b
SOS feature version: 0, firmware version: 0x
ASD feature version: 0, firmware version: 0x0017ba78
SMC feature version: 0, firmware version: 0x1e49
SDMA0 feature version: 41, firmware version: 0x00a9
VCN feature version: 0, firmware version: 0x01004912
VBIOS version: 113-RAVEN-106

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/bochs: Drop best_encoder

[Daniel Vetter]

On Thu, Feb 28, 2019 at 09:55:22AM +0100, Gerd Hoffmann wrote:
> On Thu, Feb 21, 2019 at 04:58:57PM +0100, Daniel Vetter wrote:
> > This is the default for atomic drivers.
> > 
> > Signed-off-by: Daniel Vetter 
> > Cc: Gerd Hoffmann 
> > Cc: virtualizat...@lists.linux-foundation.org
> > ---
> >  drivers/gpu/drm/bochs/bochs_kms.c | 11 ---
> >  1 file changed, 11 deletions(-)
> 
> Pushed to drm-misc-next.

Thanks. r-b on the first patch too so I can pull that in?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109649] [bisected][raven] gfx ring timeout when running clover apps

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109649

--- Comment #2 from Jan Vesely  ---
I've confirmed that reverting the change on top of 4.20.13 fixes the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: big conflict in drm-tip (amdgpu)

[Daniel Vetter]

On Thu, Feb 28, 2019 at 5:30 AM Dave Airlie  wrote:
>
> I merged some fixes into drm-fixes, pushed it out, then saw tip
> breaking, but I'm needed elsewhere, so if anyone can fix tip up or
> tell me why I got a super messy commit, I'll owe you.

Chris already patched it up it seems, I guess someone should
double-check it's reasonable. For the future might be good if amd
trees push into drm-tip and/or linux-next beforehand, for early
warning and testing of the merge resolution. Ideally both I'd say.
It's the biggest driver we have after all :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: big conflict in drm-tip (amdgpu)

[Chris Wilson]

Quoting Daniel Vetter (2019-02-28 09:49:51)
> On Thu, Feb 28, 2019 at 5:30 AM Dave Airlie  wrote:
> >
> > I merged some fixes into drm-fixes, pushed it out, then saw tip
> > breaking, but I'm needed elsewhere, so if anyone can fix tip up or
> > tell me why I got a super messy commit, I'll owe you.
> 
> Chris already patched it up it seems, I guess someone should
> double-check it's reasonable. For the future might be good if amd
> trees push into drm-tip and/or linux-next beforehand, for early
> warning and testing of the merge resolution. Ideally both I'd say.
> It's the biggest driver we have after all :-)

I took a conservative approach, and just verified that the code still
compiled. I expect the vrr fakery was reverted in the process, but also
expect that new code will be flowing from amdgpu in their next update
anyway.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/2] drm: move i915_kick_out_vgacon to vgaarb

[Daniel Vetter]

On Mon, Feb 25, 2019 at 09:34:09AM +0100, Gerd Hoffmann wrote:
> On Fri, Feb 22, 2019 at 06:20:11PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 22, 2019 at 12:03 PM Gerd Hoffmann  wrote:
> > >
> > >   Hi,
> > >
> > > > > -   /*
> > > > > -* WARNING: Apparently we must kick fbdev drivers before vgacon,
> > > > > -* otherwise the vga fbdev driver falls over.
> > > > > -*/
> > > > > ret = i915_kick_out_firmware_fb(dev_priv);
> > > >
> > > > This needs to be replaced with a call to
> > > > drm_fb_helper_remove_conflicting_pci_framebuffers, because the above
> > > > wrapper hasn't been converted yet. Otherwise you end up removing the
> > > > vgacon unbind from i915.
> > >
> > > Ah, little but important difference I didn't notice on the first look.
> > > That wrapper calls the non-pci version.  But seems it isn't that easy
> > > to switch over because the framebuffer is in stolen memory instead of a
> > > pci bar ...
> > 
> > stolen memory is where the fb physically resides. the pci bar is how
> > you access it (as long as you take all the pci bars). From a quick
> > look i915 and pci version of remove_conflicting_fb matched.
> 
> Well, it is
> 
>   ap->ranges[0].base = ggtt->gmadr.start;
>   ap->ranges[0].size = ggtt->mappable_end;
> 
> vs.
> 
>   ap->ranges[0].base = pci_resource_start(pdev, res_id);
>   ap->ranges[0].size = pci_resource_len(pdev, res_id);
> 
> So not obvious that they are the same.  At least to me, maybe it is a
> different story for someone knowing the i915 driver better.

It's one of the pci bars, so amounts to the same. But yeah not obvious if
you don't know that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915/fence: Do not use TIMER_IRQSAFE

[Chris Wilson]

Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38)
> On 2019-02-12 17:28:57 [+0100], To linux-ker...@vger.kernel.org wrote:
> > The timer is initialized with TIMER_IRQSAFE flag. It does look like the
> > timer callback requires this flag at all. Its sole purpose is to ensure
> > synchronisation in the workqueue code.
> > 
> > Remove TIMER_IRQSAFE flag because it is not required.
> 
> ping

We call del_timer_sync from irq context, which mandates using
TIMER_IRQSAFE. Failure to do so results in lots of explosions across CI
-- every machine managed to hit the warning.

It may not be the best of api, but it's the only one available for the
driver to use...
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 1/1] uio: Add dma-buf import ioctls

[Daniel Vetter]

On Wed, Feb 27, 2019 at 04:36:06PM -0800, Hyun Kwon wrote:
> Hi Daniel,
> 
> On Wed, 2019-02-27 at 06:13:45 -0800, Daniel Vetter wrote:
> > On Tue, Feb 26, 2019 at 11:20 PM Hyun Kwon  wrote:
> > >
> > > Hi Daniel,
> > >
> > > Thanks for the comment.
> > >
> > > On Tue, 2019-02-26 at 04:06:13 -0800, Daniel Vetter wrote:
> > > > On Tue, Feb 26, 2019 at 12:53 PM Greg Kroah-Hartman
> > > >  wrote:
> > > > >
> > > > > On Sat, Feb 23, 2019 at 12:28:17PM -0800, Hyun Kwon wrote:
> > > > > > Add the dmabuf map / unmap interfaces. This allows the user driver
> > > > > > to be able to import the external dmabuf and use it from user space.
> > > > > >
> > > > > > Signed-off-by: Hyun Kwon 
> > > > > > ---
> > > > > >  drivers/uio/Makefile |   2 +-
> > > > > >  drivers/uio/uio.c|  43 +
> > > > > >  drivers/uio/uio_dmabuf.c | 210 
> > > > > > +++
> > > > > >  drivers/uio/uio_dmabuf.h |  26 ++
> > > > > >  include/uapi/linux/uio/uio.h |  33 +++
> > > > > >  5 files changed, 313 insertions(+), 1 deletion(-)
> > > > > >  create mode 100644 drivers/uio/uio_dmabuf.c
> > > > > >  create mode 100644 drivers/uio/uio_dmabuf.h
> > > > > >  create mode 100644 include/uapi/linux/uio/uio.h
> > > > > >
> > > > > > diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> > > > > > index c285dd2..5da16c7 100644
> > > > > > --- a/drivers/uio/Makefile
> > > > > > +++ b/drivers/uio/Makefile
> > > > > > @@ -1,5 +1,5 @@
> > > > > >  # SPDX-License-Identifier: GPL-2.0
> > > > > > -obj-$(CONFIG_UIO)+= uio.o
> > > > > > +obj-$(CONFIG_UIO)+= uio.o uio_dmabuf.o
> > > > > >  obj-$(CONFIG_UIO_CIF)+= uio_cif.o
> > > > > >  obj-$(CONFIG_UIO_PDRV_GENIRQ)+= uio_pdrv_genirq.o
> > > > > >  obj-$(CONFIG_UIO_DMEM_GENIRQ)+= uio_dmem_genirq.o
> > > > > > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> > > > > > index 1313422..6841f98 100644
> > > > > > --- a/drivers/uio/uio.c
> > > > > > +++ b/drivers/uio/uio.c
> > > > > > @@ -24,6 +24,12 @@
> > > > > >  #include 
> > > > > >  #include 
> > > > > >  #include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +
> > > > > > +#include 
> > > > > > +
> > > > > > +#include "uio_dmabuf.h"
> > > > > >
> > > > > >  #define UIO_MAX_DEVICES  (1U << MINORBITS)
> > > > > >
> > > > > > @@ -454,6 +460,8 @@ static irqreturn_t uio_interrupt(int irq, void 
> > > > > > *dev_id)
> > > > > >  struct uio_listener {
> > > > > >   struct uio_device *dev;
> > > > > >   s32 event_count;
> > > > > > + struct list_head dbufs;
> > > > > > + struct mutex dbufs_lock; /* protect @dbufs */
> > > > > >  };
> > > > > >
> > > > > >  static int uio_open(struct inode *inode, struct file *filep)
> > > > > > @@ -500,6 +508,9 @@ static int uio_open(struct inode *inode, struct 
> > > > > > file *filep)
> > > > > >   if (ret)
> > > > > >   goto err_infoopen;
> > > > > >
> > > > > > + INIT_LIST_HEAD(&listener->dbufs);
> > > > > > + mutex_init(&listener->dbufs_lock);
> > > > > > +
> > > > > >   return 0;
> > > > > >
> > > > > >  err_infoopen:
> > > > > > @@ -529,6 +540,10 @@ static int uio_release(struct inode *inode, 
> > > > > > struct file *filep)
> > > > > >   struct uio_listener *listener = filep->private_data;
> > > > > >   struct uio_device *idev = listener->dev;
> > > > > >
> > > > > > + ret = uio_dmabuf_cleanup(idev, &listener->dbufs, 
> > > > > > &listener->dbufs_lock);
> > > > > > + if (ret)
> > > > > > + dev_err(&idev->dev, "failed to clean up the dma 
> > > > > > bufs\n");
> > > > > > +
> > > > > >   mutex_lock(&idev->info_lock);
> > > > > >   if (idev->info && idev->info->release)
> > > > > >   ret = idev->info->release(idev->info, inode);
> > > > > > @@ -652,6 +667,33 @@ static ssize_t uio_write(struct file *filep, 
> > > > > > const char __user *buf,
> > > > > >   return retval ? retval : sizeof(s32);
> > > > > >  }
> > > > > >
> > > > > > +static long uio_ioctl(struct file *filep, unsigned int cmd, 
> > > > > > unsigned long arg)
> > > > >
> > > > > We have resisted adding a uio ioctl for a long time, can't you do this
> > > > > through sysfs somehow?
> > > > >
> > > > > A meta-comment about your ioctl structure:
> > > > >
> > > > > > +#define UIO_DMABUF_DIR_BIDIR 1
> > > > > > +#define UIO_DMABUF_DIR_TO_DEV2
> > > > > > +#define UIO_DMABUF_DIR_FROM_DEV  3
> > > > > > +#define UIO_DMABUF_DIR_NONE  4
> > > > >
> > > > > enumerated type?
> > > > >
> > > > > > +
> > > > > > +struct uio_dmabuf_args {
> > > > > > + __s32   dbuf_fd;
> > > > > > + __u64   dma_addr;
> > > > > > + __u64   size;
> > > > > > + __u32   dir;
> > > > >
> > > > > Why the odd alignment?  Are you sure this is the best packing for 
> > > > > such a
> > > > > structure?
> > > > >
> > > > > Why is dbuf_fd __s32?  dir can be __u8, right?
> > > > >
> > > > > I don't know that dma layer very well, it would be go

Re: [PATCH] drm/vkms: Solve bug on kms_crc_cursor tests

[Daniel Vetter]

On Mon, Feb 25, 2019 at 11:26:06AM -0300, Shayenne Moura wrote:
> vkms_crc_work_handle needs the value of the actual frame to
> schedule the workqueue that calls periodically the vblank
> handler and the destroy state functions. However, the frame
> value returned from vkms_vblank_simulate is updated and
> diminished in vblank_get_timestamp because it is not in a
> vblank interrupt, and return an inaccurate value.
> 
> Solve this getting the actual vblank frame directly from the
> vblank->count inside the `struct drm_crtc`, instead of using
> the `drm_accurate_vblank_count` function.
> 
> Signed-off-by: Shayenne Moura 

Sorry for the delay, I'm a bit swamped right now :-/

Debug work you're doing here is really impressive! But I have no idea
what's going on. It doesn't look like it's just papering over a bug (like
the in_vblank_irq check we've discussed on irc), but I also have no idea
why it works.

I'll pull in Ville, he understands this better than me.
-Daniel

> ---
>  drivers/gpu/drm/vkms/vkms_crc.c  | 4 +++-
>  drivers/gpu/drm/vkms/vkms_crtc.c | 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index d7b409a3c0f8..09a8b00ef1f1 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -161,6 +161,8 @@ void vkms_crc_work_handle(struct work_struct *work)
>   struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
>   struct vkms_device *vdev = container_of(out, struct vkms_device,
>   output);
> + unsigned int pipe = drm_crtc_index(crtc);
> + struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe];
>   struct vkms_crc_data *primary_crc = NULL;
>   struct vkms_crc_data *cursor_crc = NULL;
>   struct drm_plane *plane;
> @@ -196,7 +198,7 @@ void vkms_crc_work_handle(struct work_struct *work)
>   if (primary_crc)
>   crc32 = _vkms_get_crc(primary_crc, cursor_crc);
>  
> - frame_end = drm_crtc_accurate_vblank_count(crtc);
> + frame_end = vblank->count;
>  
>   /* queue_work can fail to schedule crc_work; add crc for
>* missing frames
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 8a9aeb0a9ea8..9bf3268e2e92 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -10,6 +10,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
> hrtimer *timer)
> vblank_hrtimer);
>   struct drm_crtc *crtc = &output->crtc;
>   struct vkms_crtc_state *state = to_vkms_crtc_state(crtc->state);
> + unsigned int pipe = drm_crtc_index(crtc);
> + struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe];
>   u64 ret_overrun;
>   bool ret;
>  
> @@ -20,7 +22,7 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
> hrtimer *timer)
>   DRM_ERROR("vkms failure on handling vblank");
>  
>   if (state && output->crc_enabled) {
> - u64 frame = drm_crtc_accurate_vblank_count(crtc);
> + u64 frame = vblank->count;
>  
>   /* update frame_start only if a queued vkms_crc_work_handle()
>* has read the data
> -- 
> 2.17.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: Solve bug on kms_crc_cursor tests

[Daniel Vetter]

On Thu, Feb 28, 2019 at 11:11:07AM +0100, Daniel Vetter wrote:
> On Mon, Feb 25, 2019 at 11:26:06AM -0300, Shayenne Moura wrote:
> > vkms_crc_work_handle needs the value of the actual frame to
> > schedule the workqueue that calls periodically the vblank
> > handler and the destroy state functions. However, the frame
> > value returned from vkms_vblank_simulate is updated and
> > diminished in vblank_get_timestamp because it is not in a
> > vblank interrupt, and return an inaccurate value.
> > 
> > Solve this getting the actual vblank frame directly from the
> > vblank->count inside the `struct drm_crtc`, instead of using
> > the `drm_accurate_vblank_count` function.
> > 
> > Signed-off-by: Shayenne Moura 
> 
> Sorry for the delay, I'm a bit swamped right now :-/
> 
> Debug work you're doing here is really impressive! But I have no idea
> what's going on. It doesn't look like it's just papering over a bug (like
> the in_vblank_irq check we've discussed on irc), but I also have no idea
> why it works.
> 
> I'll pull in Ville, he understands this better than me.

Works better if I actually add Ville ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: AFBC versions modifiers

[Daniel Vetter]

On Wed, Feb 27, 2019 at 03:41:35PM +, Ayan Halder wrote:
> Hi Neil,
> 
> AFBC 1.0 does not support (ignoring common prefix AFBC_FORMAT_MOD_) 
> BLOCK_SIZE_32x8, BLOCK_SIZE_64x4, BLOCK_SIZE_32x8_64x4
> CBR, TILED, SC, DB and BCH  modifiers.
> 
> AFBC 1.2 does not support BLOCK_SIZE_64x4, BLOCK_SIZE_32x8_64x4, DB and BCH 
> modifiers.

Would be great to add that to kernel comments in drm_fourcc.h ...
-Daniel

> 
> Beyond that it's very hard to say. The AFBC version numbers refer to versions 
> of the specification, but aren't very useful for describing the actual 
> bitstream format.
> To determine which modifiers _are_ supported, you will really need to get 
> technical documentation from the SoC vendor
> 
> Regards,
> Ayan Kumar Halder
> 
> 
> From: Neil Armstrong 
> Sent: Tuesday, February 26, 2019 2:15 PM
> To: Ayan Halder; Liviu Dudau
> Cc: DRI Development
> Subject: AFBC versions modifiers
> 
> Hi Ayan,
> 
> Could you help distinguish which are the AFBC modifiers for each version of 
> AFBC ?
> 
> The Amlogic SoCs embeds an AFBC 1.0 compatible decoder, then the newer SoCs 
> embeds an AFBC 1.2 decoder,
> I assume the modifiers before the patch "drm/fourcc: Add modifier 
> defininitions for AFBC 1.3" are
> valid for AFBC 1.2, but what is the subset for 1.0 and 1.1 ?
> 
> Thanks,
> Neil
> 
> --
> Neil Armstrong
> Embedded Linux Software Engineer
> BayLibre - At the Heart of Embedded Linux
> www.baylibre.com

> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915/fence: Do not use TIMER_IRQSAFE

[Chris Wilson]

Quoting Thomas Gleixner (2019-02-28 10:09:26)
> On Thu, 28 Feb 2019, Chris Wilson wrote:
> 
> > Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38)
> > > On 2019-02-12 17:28:57 [+0100], To linux-ker...@vger.kernel.org wrote:
> > > > The timer is initialized with TIMER_IRQSAFE flag. It does look like the
> > > > timer callback requires this flag at all. Its sole purpose is to ensure
> > > > synchronisation in the workqueue code.
> > > > 
> > > > Remove TIMER_IRQSAFE flag because it is not required.
> > > 
> > > ping
> > 
> > We call del_timer_sync from irq context, which mandates using
> > TIMER_IRQSAFE. Failure to do so results in lots of explosions across CI
> > -- every machine managed to hit the warning.
> > 
> > It may not be the best of api, but it's the only one available for the
> > driver to use...
> 
> The comment in the header files says clearly:
> 
>  * Note: The irq disabled callback execution is a special case for
>  * workqueue locking issues. It's not meant for executing random crap
>  * with interrupts disabled. Abuse is monitored!  
>  
> 
> So what's so special in drm that you need to call del_timer_sync() from
> interrupt context?

There's no protection against fence signaling from inside interrupt
context, and a lot of pressure to do so.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

--- Comment #8 from Michel Dänzer  ---
(In reply to Marek Olšák from comment #7)
> An even better solution would be to have a virtual thread affinity that only
> the application can see and change, which should be silently masked by
> administrative policies not visible to the application.

Mesa doesn't really need explicit thread affinity at all. All it wants is that
certain sets of threads run on the same CPU module; it doesn't care which
particular CPU module that is. What's really needed is an API to express this
affinity between threads, instead of to specific CPU cores.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 41/50] drm/bridge: ti-tfp410: Report input bus config through bridge timings

[Tomi Valkeinen]

Hi Laurent,

On 11/02/2019 11:46, Laurent Pinchart wrote:

> + /* Get the sampling edge from the endpoint. */
> + of_property_read_u32(ep, "pclk-sample", &pclk_sample);
> + of_node_put(ep);
> +
> + timings->input_bus_flags = DRM_BUS_FLAG_DE_HIGH;
> +
> + switch (pclk_sample) {
> + case 0:
> + timings->input_bus_flags |= DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE
> +  |  DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE;
> + break;
> + case 1:
> + timings->input_bus_flags |= DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE
> +  |  DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE;
> + break;
> + default:
> + return -EINVAL;
> + }

The default for pclk_sample is just the opposite of what omapdrm's
tfp410 used to do. The dts doc file also says that pclk-sample is
required, but the driver works fine without it, defaulting to 0.

This means that none of the omap dts files with tfp410 work correctly,
instead they silently use the wrong settings which may work but easily
also won't...

As the bus flags are added in this patch for the first time, maybe we
can assume that no one is using them, and the default could be made to
be the same as was on omapdrm's tfp410?

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 41/50] drm/bridge: ti-tfp410: Report input bus config through bridge timings

[Tomi Valkeinen]

On 28/02/2019 12:27, Tomi Valkeinen wrote:
> Hi Laurent,
> 
> On 11/02/2019 11:46, Laurent Pinchart wrote:
> 
>> +/* Get the sampling edge from the endpoint. */
>> +of_property_read_u32(ep, "pclk-sample", &pclk_sample);
>> +of_node_put(ep);
>> +
>> +timings->input_bus_flags = DRM_BUS_FLAG_DE_HIGH;
>> +
>> +switch (pclk_sample) {
>> +case 0:
>> +timings->input_bus_flags |= DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE
>> + |  DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE;
>> +break;
>> +case 1:
>> +timings->input_bus_flags |= DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE
>> + |  DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE;
>> +break;
>> +default:
>> +return -EINVAL;
>> +}
> 
> The default for pclk_sample is just the opposite of what omapdrm's
> tfp410 used to do. The dts doc file also says that pclk-sample is
> required, but the driver works fine without it, defaulting to 0.
> 
> This means that none of the omap dts files with tfp410 work correctly,
> instead they silently use the wrong settings which may work but easily
> also won't...
> 
> As the bus flags are added in this patch for the first time, maybe we
> can assume that no one is using them, and the default could be made to
> be the same as was on omapdrm's tfp410?

Aaaand never mind. In omapdrm's driver we were using
DRM_BUS_FLAG_SYNC_DRIVE_* variant, here we have SAMPLE variant. So it's
fine =).

Sorry for the noise.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[tiL4.19-AD PATCH 2/2] drm/tilcdc: Remove obsolete crtc_mode_valid() hack

[Jyri Sarha]

Earlier there were no mode_valid() helper for crtc and tilcdc had a
hack to over come this limitation. But now the mode_valid() helper is
there (has been since v4.13), so it is about time to get rid of that
hack.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 28 +++-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.h  |  2 -
 drivers/gpu/drm/tilcdc/tilcdc_external.c | 88 +++-
 drivers/gpu/drm/tilcdc/tilcdc_external.h |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_panel.c|  9 ---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c   |  9 ---
 7 files changed, 19 insertions(+), 119 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index a8ae064f52bb..f9600f2ad660 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -659,9 +659,6 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
 static int tilcdc_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
 {
-   struct drm_display_mode *mode = &state->mode;
-   int ret;
-
/* If we are not active we don't care */
if (!state->active)
return 0;
@@ -673,12 +670,6 @@ static int tilcdc_crtc_atomic_check(struct drm_crtc *crtc,
return -EINVAL;
}
 
-   ret = tilcdc_crtc_mode_valid(crtc, mode);
-   if (ret) {
-   dev_dbg(crtc->dev->dev, "Mode \"%s\" not valid", mode->name);
-   return -EINVAL;
-   }
-
return 0;
 }
 
@@ -730,13 +721,6 @@ static const struct drm_crtc_funcs tilcdc_crtc_funcs = {
.disable_vblank = tilcdc_crtc_disable_vblank,
 };
 
-static const struct drm_crtc_helper_funcs tilcdc_crtc_helper_funcs = {
-   .mode_fixup = tilcdc_crtc_mode_fixup,
-   .atomic_check   = tilcdc_crtc_atomic_check,
-   .atomic_enable  = tilcdc_crtc_atomic_enable,
-   .atomic_disable = tilcdc_crtc_atomic_disable,
-};
-
 int tilcdc_crtc_max_width(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
@@ -751,7 +735,9 @@ int tilcdc_crtc_max_width(struct drm_crtc *crtc)
return max_width;
 }
 
-int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct drm_display_mode 
*mode)
+static enum drm_mode_status
+tilcdc_crtc_mode_valid(struct drm_crtc *crtc,
+  const struct drm_display_mode *mode)
 {
struct tilcdc_drm_private *priv = crtc->dev->dev_private;
unsigned int bandwidth;
@@ -839,6 +825,14 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
return MODE_OK;
 }
 
+static const struct drm_crtc_helper_funcs tilcdc_crtc_helper_funcs = {
+   .mode_valid = tilcdc_crtc_mode_valid,
+   .mode_fixup = tilcdc_crtc_mode_fixup,
+   .atomic_check   = tilcdc_crtc_atomic_check,
+   .atomic_enable  = tilcdc_crtc_atomic_enable,
+   .atomic_disable = tilcdc_crtc_atomic_disable,
+};
+
 void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
const struct tilcdc_panel_info *info)
 {
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 3dac08b24140..36fd05b145a4 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -192,7 +192,6 @@ static void tilcdc_fini(struct drm_device *dev)
drm_kms_helper_poll_fini(dev);
drm_irq_uninstall(dev);
drm_mode_config_cleanup(dev);
-   tilcdc_remove_external_device(dev);
 
 #ifdef CONFIG_CPU_FREQ
if (priv->freq_transition.notifier_call)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 62cea5ff5558..3298f39d320e 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -86,7 +86,6 @@ struct tilcdc_drm_private {
 
struct drm_encoder *external_encoder;
struct drm_connector *external_connector;
-   const struct drm_connector_helper_funcs *connector_funcs;
 
bool is_registered;
bool is_componentized;
@@ -168,7 +167,6 @@ void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
const struct tilcdc_panel_info *info);
 void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc *crtc,
bool simulate_vesa_sync);
-int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct drm_display_mode 
*mode);
 int tilcdc_crtc_max_width(struct drm_crtc *crtc);
 void tilcdc_crtc_shutdown(struct drm_crtc *crtc);
 int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c 
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index b4eaf9bc87f8..54adf05f44e6 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -40,64 +40,6 @@ static const struct tilcdc_panel_info panel_info_def

[tiL4.19-AD PATCH 0/2] drm/tilcdc: a cleanup and a fix

[Jyri Sarha]

Jyri Sarha (2):
  drm/tilcdc: Check drm_fb_cma_get_gem_obj() return value
  drm/tilcdc: Remove obsolete crtc_mode_valid() hack

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 30 
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.h  |  2 -
 drivers/gpu/drm/tilcdc/tilcdc_external.c | 88 +++-
 drivers/gpu/drm/tilcdc/tilcdc_external.h |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_panel.c|  9 ---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c   |  9 ---
 7 files changed, 21 insertions(+), 119 deletions(-)

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[tiL4.19-AD PATCH 1/2] drm/tilcdc: Check drm_fb_cma_get_gem_obj() return value

[Jyri Sarha]

drm_fb_cma_get_gem_obj() may return NULL. The return value needs to be
checked before dereferencing the returned pointer.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 1067e702c22c..a8ae064f52bb 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -75,6 +75,8 @@ static void set_scanout(struct drm_crtc *crtc, struct 
drm_framebuffer *fb)
u64 dma_base_and_ceiling;
 
gem = drm_fb_cma_get_gem_obj(fb, 0);
+   if (WARN_ON(!gem))
+   return;
 
start = gem->paddr + fb->offsets[0] +
crtc->y * fb->pitches[0] +
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers

[Hans de Goede]

Hi,

On 28-02-19 10:15, Heikki Krogerus wrote:

On Wed, Feb 27, 2019 at 04:45:32PM +0100, Hans de Goede wrote:

Hi,

On 27-02-19 12:16, Jani Nikula wrote:

On Wed, 27 Feb 2019, Heikki Krogerus  wrote:

One thing that this series does not consider is the DP lane count
problem. The GPU drivers (i915 in this case) does not know is four,
two or one DP lanes in use.


Also, orientation.


The orientation should simply be correct with Type-C over DP. The mux /
orientation-switch used will take care of (physically) swapping the
lanes if the connector is inserted upside-down.


I guess that is not a critical issue since there is a workaround (I
think) where the driver basically does trial and error, but ideally we
should be able to tell i915 also the pin assignment that was
negotiated with the partner device so it knows the DP lane count.


Yeah, if the information is there, we'd like to know.


So far machines actually using a setup where the kernel does the
USB-PD / Type-C negotiation rather then this being handled in firmware
in say the Alpine Ridge controller, are very rare.

AFAIK in the Alpine Ridge controller case, there is no communication
with the i915 driver, the only thing the Alpine Ridge controller does
which the everything done in the kernel approach does not, is that
it actually has a pin connected to the HDP pin of the displayport in
question.  But that just lets the i915 driver know about hotplug-events,
not how many lanes are used.

Currently I'm aware of only 2 x86 models which actually need the
hotplug event propagation from the Type-C subsystem to the i915 driver.
Do we really want to come up with a much more complex solution to
optimize for this corner case, while the much more common case
(Alpine Ridge controller) does not provide this info to the i915 driver?


The HPD signal is often handled with a GPIO on Intel Platforms. Either
the PD controller or EC controller, after receiving the Attention
message, triggers the GPIO. On some systems though that GPIO method
could not be used, so instead a side channel communication is used:
the GFX device (so i915 driver) receives a specific custom interrupt.

Unfortunately it now appears that there may be products coming where
using the GPIO is not going to be possible, and also side channel
communication is going to be out of the question. I've started an
internal discussion inside Intel about the possibility to extend the
UCSI specification to be able to support that kind of products.

Alpine Ridge uses TI's Power Delivery controllers. The platforms that
have Alpine Ridge TBT controller(s) often expose the USB Type-C
connectors on them to the OS via UCSI, however, it appears the Alpine
Ridge actually allows direct access to the PD controllers from the OS.
That would mean we can supply the same information to the GPU drivers
that we will deliver on CHT also on every platform that uses Alpine
Ridge.


Ok.


To give some idea of the complexity, first of all we need some
mechanism to let the kernel know which drm_connector is connected
to which Type-C port. For the 2 models I know if which need this, this
info is not available and we would need to hardcode it in the kernel
based on e.g. DMI matching.


I've been thinking about this... Do we actually need to link the
correct drm_connector to the Type-C connector? Perhaps we can make
this work by just linking the GFX device to the Type-C connector.


What use is it to the kms driver if it gets an event there is a DP
hotplug with x lanes and orientation foo, if we are not telling it
on which DP port it is ? kms devices already have multiple DP ports
and more then one could be hooked-up to type-c connectors.


Then once we have this link, we need to start thinking about probe
ordering. Likely we need the typec framework to find the drm_connector,
since the typec-partner device is only created when there actually is
a DP capable "dongle" connected, making doing it the other way around
tricky. Then the typec-partner device needs to get a reference or some
such to make sure the drm_connector does not fgo away during the lifetime
of the typec-partner device.


No! We must not link the partner device with anything other than the
Type-C connector. We link the USB Type-C connector to the DisplayPort,
and we link the USB Type-C connector to the partner. The Type-C
connector is the proxy here.


Maybe, but even then we still need one side of the link to have a
reference on the other, having a proxy in between does not change
anything.


I would really like to avoid this, so if we want to send more info to
the i915 driver, I suggest we create some event struct for this which
gets passed to the notifier, this could include a string to
describe the DP connector which the Type-C connector is connected to
when the mux is set to DP mode, e.g. "i915/DP-1" should be unique
or probably better, use the PCI device name, so: ":00:02.0/DP-1"

Then we still have a loose coupling avoiding lifetime issues, while
the receiving 

Re: [PATCH] xen, fbfront: mark expected switch fall-through

[Oleksandr Andrushchenko]

+Xen-devel list

On 2/27/19 10:53 PM, Gustavo A. R. Silva wrote:

In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.

This patch fixes the following warning:

drivers/video/fbdev/xen-fbfront.c: In function ‘xenfb_backend_changed’:
drivers/video/fbdev/xen-fbfront.c:678:6: warning: this statement may fall 
through [-Wimplicit-fallthrough=]
if (dev->state == XenbusStateClosed)
   ^
drivers/video/fbdev/xen-fbfront.c:681:2: note: here
   case XenbusStateClosing:
   ^~~~

Warning level 3 was used: -Wimplicit-fallthrough=3

Notice that, in this particular case, the code comment is modified
in accordance with what GCC is expecting to find.

This patch is part of the ongoing efforts to enable
-Wimplicit-fallthrough.

Signed-off-by: Gustavo A. R. Silva 
---
  drivers/video/fbdev/xen-fbfront.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/xen-fbfront.c 
b/drivers/video/fbdev/xen-fbfront.c
index 6a4bbc9e1fb0..a3d6b6db221b 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -677,7 +677,7 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
case XenbusStateClosed:
if (dev->state == XenbusStateClosed)
break;
-   /* Missed the backend's CLOSING state -- fallthrough */
+   /* fall through - Missed the backend's CLOSING state. */
case XenbusStateClosing:
xenbus_frontend_closed(dev);
break;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] topic/mei-hdcp for char-misc-next

[Greg KH]

On Tue, Feb 26, 2019 at 10:17:10PM +0100, Daniel Vetter wrote:
> Hi Greg&Arnd
> 
> topic/mei-hdcp-2019-02-26:
> mei-hdcp driver
> 
> mei driver for the me hdcp client, for use by drm/i915.
> 
> Including the following prep work:
> - whitelist hdcp client in mei bus
> - merge to include char-misc-next because of another mei bus prep patch to
>   export a helper macro to drivers
> - drm/i915 side of the mei_hdcp/i915 component interface (already pulled
>   into drm-intel for 5.2 as a topic branch)
> - component prep work (including one patch touching i915&snd-hda), already
>   pulled by you into drivers-base-next for 5.1
> 
> mei-hdcp patches all reviewed and acked by Tomas Winkler. All other bits
> and pieces acked by relevant subsystem people. Took a bit longer than
> planned, but so does the 5.0 release. Up to you whether you still want to
> pull for 5.1 merge window or delay for 5.2, either totally fine for us.
> The drm/i915 of this will only land in 5.2 completely.
> 
> Cheers, Daniel
> 
> Note: diffstat below generated against Linus' tree. Which is wrong, but
> since this both contains drivers-base-next, char-misc-next and stuff
> queued for drm-i915 (but which isn't in linux-next yet because that's
> aimed for 5.2) it's a bit a mess. Given that shrugged and just went with
> this. I can regenerate some other diffstat if you want something else,
> just didn't know what's really the right thing here.

That diffstat and shortlog was crazy :(

Here's the right diffstat:

 Documentation/driver-api/component.rst   |  17 ++
 Documentation/driver-api/device_link.rst |   3 +
 Documentation/driver-api/index.rst   |   1 +
 drivers/base/component.c | 206 -
 drivers/gpu/drm/i915/intel_audio.c   |   4 +-
 drivers/gpu/drm/i915/intel_display.h |  16 +-
 drivers/misc/mei/Kconfig |  10 +
 drivers/misc/mei/Makefile|   2 +
 drivers/misc/mei/bus-fixup.c |  16 ++
 drivers/misc/mei/hdcp/Makefile   |   7 +
 drivers/misc/mei/hdcp/mei_hdcp.c | 849 
+++
 drivers/misc/mei/hdcp/mei_hdcp.h | 377 
 include/drm/drm_audio_component.h|   1 +
 include/drm/drm_hdcp.h   |  18 ++
 include/drm/i915_component.h |   5 +
 include/drm/i915_drm.h   |  15 ++
 include/drm/i915_mei_hdcp_interface.h| 149 +
 include/linux/component.h|  76 +++
 include/sound/hda_component.h|   5 +-
 sound/hda/hdac_component.c   |   4 +-
 sound/hda/hdac_i915.c|   6 +-
 21 files changed, 1754 insertions(+), 33 deletions(-)
 create mode 100644 Documentation/driver-api/component.rst
 create mode 100644 drivers/misc/mei/hdcp/Makefile
 create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c
 create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h
 create mode 100644 include/drm/i915_mei_hdcp_interface.h

Anyway, I've pulled this into my char-misc-testing tree to let 0-day run with
it, and if all is good, will move it to my -next branch for inclusion in
5.1-rc1.

thanks,

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

Timo Aaltonen  changed:

   What|Removed |Added

 Blocks||109535
 CC||tjaal...@ubuntu.com


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=109535
[Bug 109535] [Tracker] Mesa 19.0 release tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/hibmc: Drop best_encoder

[Noralf Trønnes]

Den 21.02.2019 16.58, skrev Daniel Vetter:
> This is the default for atomic drivers.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Daniel Vetter 
> Cc: Sam Ravnborg 
> Cc: Neil Armstrong 
> Cc: Luc Van Oostenryck 
> Cc: Rodrigo Vivi 
> ---

Acked-by: Noralf Trønnes 

>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> index d2cf7317930a..8c2f9b9cafb3 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> @@ -33,17 +33,10 @@ static enum drm_mode_status 
> hibmc_connector_mode_valid(struct drm_connector *con
>   return MODE_OK;
>  }
>  
> -static struct drm_encoder *
> -hibmc_connector_best_encoder(struct drm_connector *connector)
> -{
> - return drm_encoder_find(connector->dev, NULL, 
> connector->encoder_ids[0]);
> -}
> -
>  static const struct drm_connector_helper_funcs
>   hibmc_connector_helper_funcs = {
>   .get_modes = hibmc_connector_get_modes,
>   .mode_valid = hibmc_connector_mode_valid,
> - .best_encoder = hibmc_connector_best_encoder,
>  };
>  
>  static const struct drm_connector_funcs hibmc_connector_funcs = {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/2] drm: move i915_kick_out_vgacon to vgaarb

[Gerd Hoffmann]

> > > stolen memory is where the fb physically resides. the pci bar is how
> > > you access it (as long as you take all the pci bars). From a quick
> > > look i915 and pci version of remove_conflicting_fb matched.
> > 
> > Well, it is
> > 
> > ap->ranges[0].base = ggtt->gmadr.start;
> > ap->ranges[0].size = ggtt->mappable_end;
> > 
> > vs.
> > 
> > ap->ranges[0].base = pci_resource_start(pdev, res_id);
> > ap->ranges[0].size = pci_resource_len(pdev, res_id);
> > 
> > So not obvious that they are the same.  At least to me, maybe it is a
> > different story for someone knowing the i915 driver better.
> 
> It's one of the pci bars, so amounts to the same. But yeah not obvious if
> you don't know that.

On my system (kaby lake) it happens to be pci bar 2, is that true for
all igd devices?

cheers,
  Gerd

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Slightly quieten bad EDID messages

[Chris Wilson]

Bad EDID are a fact of life when dealing with random monitors. We only
spam the logs when debugging is enabled, but we only need to raise
notice and not set off the warning bells.

Signed-off-by: Chris Wilson 
Cc: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_edid.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 990b1909f9d7..98903cb7064d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1535,9 +1535,8 @@ static void connector_bad_edid(struct drm_connector 
*connector,
if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
return;
 
-   dev_warn(connector->dev->dev,
-"%s: EDID is invalid:\n",
-connector->name);
+   dev_notice(connector->dev->dev,
+  "%s: EDID is invalid:\n", connector->name);
for (i = 0; i < num_blocks; i++) {
u8 *block = edid + i * EDID_LENGTH;
char prefix[20];
@@ -1549,7 +1548,7 @@ static void connector_bad_edid(struct drm_connector 
*connector,
else
sprintf(prefix, "\t[%02x] GOOD ", i);
 
-   print_hex_dump(KERN_WARNING,
+   print_hex_dump(KERN_NOTICE,
   prefix, DUMP_PREFIX_NONE, 16, 1,
   block, EDID_LENGTH, false);
}
@@ -4695,8 +4694,8 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
}
if (!drm_edid_is_valid(edid)) {
clear_eld(connector);
-   dev_warn(connector->dev->dev, "%s: EDID invalid.\n",
-connector->name);
+   dev_notice(connector->dev->dev,
+  "%s: EDID invalid.\n", connector->name);
return 0;
}
 
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PULL] topic/mei-hdcp for char-misc-next

[Daniel Vetter]

On Thu, Feb 28, 2019 at 1:00 PM Greg KH  wrote:
>
> On Tue, Feb 26, 2019 at 10:17:10PM +0100, Daniel Vetter wrote:
> > Hi Greg&Arnd
> >
> > topic/mei-hdcp-2019-02-26:
> > mei-hdcp driver
> >
> > mei driver for the me hdcp client, for use by drm/i915.
> >
> > Including the following prep work:
> > - whitelist hdcp client in mei bus
> > - merge to include char-misc-next because of another mei bus prep patch to
> >   export a helper macro to drivers
> > - drm/i915 side of the mei_hdcp/i915 component interface (already pulled
> >   into drm-intel for 5.2 as a topic branch)
> > - component prep work (including one patch touching i915&snd-hda), already
> >   pulled by you into drivers-base-next for 5.1
> >
> > mei-hdcp patches all reviewed and acked by Tomas Winkler. All other bits
> > and pieces acked by relevant subsystem people. Took a bit longer than
> > planned, but so does the 5.0 release. Up to you whether you still want to
> > pull for 5.1 merge window or delay for 5.2, either totally fine for us.
> > The drm/i915 of this will only land in 5.2 completely.
> >
> > Cheers, Daniel
> >
> > Note: diffstat below generated against Linus' tree. Which is wrong, but
> > since this both contains drivers-base-next, char-misc-next and stuff
> > queued for drm-i915 (but which isn't in linux-next yet because that's
> > aimed for 5.2) it's a bit a mess. Given that shrugged and just went with
> > this. I can regenerate some other diffstat if you want something else,
> > just didn't know what's really the right thing here.
>
> That diffstat and shortlog was crazy :(
>
> Here's the right diffstat:

Yup, that one looks reasonable. I guess for the next contrived topic
branch I need to figure out how to generate diffstat against the other
subsytem tree and put that in our scripting. Usually for topic
branches just generating the diffstat against Linus' tree dtrt. But
not in this case.

>  Documentation/driver-api/component.rst   |  17 ++
>  Documentation/driver-api/device_link.rst |   3 +
>  Documentation/driver-api/index.rst   |   1 +
>  drivers/base/component.c | 206 -
>  drivers/gpu/drm/i915/intel_audio.c   |   4 +-
>  drivers/gpu/drm/i915/intel_display.h |  16 +-
>  drivers/misc/mei/Kconfig |  10 +
>  drivers/misc/mei/Makefile|   2 +
>  drivers/misc/mei/bus-fixup.c |  16 ++
>  drivers/misc/mei/hdcp/Makefile   |   7 +
>  drivers/misc/mei/hdcp/mei_hdcp.c | 849 
> +++
>  drivers/misc/mei/hdcp/mei_hdcp.h | 377 
> 
>  include/drm/drm_audio_component.h|   1 +
>  include/drm/drm_hdcp.h   |  18 ++
>  include/drm/i915_component.h |   5 +
>  include/drm/i915_drm.h   |  15 ++
>  include/drm/i915_mei_hdcp_interface.h| 149 +
>  include/linux/component.h|  76 +++
>  include/sound/hda_component.h|   5 +-
>  sound/hda/hdac_component.c   |   4 +-
>  sound/hda/hdac_i915.c|   6 +-
>  21 files changed, 1754 insertions(+), 33 deletions(-)
>  create mode 100644 Documentation/driver-api/component.rst
>  create mode 100644 drivers/misc/mei/hdcp/Makefile
>  create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c
>  create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h
>  create mode 100644 include/drm/i915_mei_hdcp_interface.h
>
> Anyway, I've pulled this into my char-misc-testing tree to let 0-day run with
> it, and if all is good, will move it to my -next branch for inclusion in
> 5.1-rc1.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v4 08/17] kunit: test: add support for test abort

[Dan Carpenter]

On Thu, Feb 28, 2019 at 01:03:24AM -0800, Brendan Higgins wrote:
> you could do:
> 
> if (IS_ERR_OR_NULL(ptr)) {
> KUNIT_FAIL(test, "ptr is an errno or null: %ld", ptr);
> return;
> }

It's best to not mix error pointers and NULL but when we do mix them,
it means that NULL is a special kind of success.  Like we try to load
a feature and we get back:

valid pointer <-- success
null  <-- feature is disabled.  not an error.
error pointer <-- feature is broken.  fail.

regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/hibmc: Drop best_encoder

[Gerd Hoffmann]

On Thu, Feb 21, 2019 at 04:58:56PM +0100, Daniel Vetter wrote:
> This is the default for atomic drivers.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Daniel Vetter 
> Cc: Sam Ravnborg 
> Cc: Neil Armstrong 
> Cc: Luc Van Oostenryck 
> Cc: Rodrigo Vivi 

Acked-by: Gerd Hoffmann 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: Solve bug on kms_crc_cursor tests

[Ville Syrjälä]

On Thu, Feb 28, 2019 at 11:11:07AM +0100, Daniel Vetter wrote:
> On Mon, Feb 25, 2019 at 11:26:06AM -0300, Shayenne Moura wrote:
> > vkms_crc_work_handle needs the value of the actual frame to
> > schedule the workqueue that calls periodically the vblank
> > handler and the destroy state functions. However, the frame
> > value returned from vkms_vblank_simulate is updated and
> > diminished in vblank_get_timestamp because it is not in a
> > vblank interrupt, and return an inaccurate value.
> > 
> > Solve this getting the actual vblank frame directly from the
> > vblank->count inside the `struct drm_crtc`, instead of using
> > the `drm_accurate_vblank_count` function.
> > 
> > Signed-off-by: Shayenne Moura 
> 
> Sorry for the delay, I'm a bit swamped right now :-/
> 
> Debug work you're doing here is really impressive! But I have no idea
> what's going on. It doesn't look like it's just papering over a bug (like
> the in_vblank_irq check we've discussed on irc), but I also have no idea
> why it works.
> 
> I'll pull in Ville, he understands this better than me.

It's not entirely clear what we're trying to fix. From what I can see
the crc work seems to be in no way synchronized with page flips, so
I'm not sure how all this is really supposed to work.

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/vkms/vkms_crc.c  | 4 +++-
> >  drivers/gpu/drm/vkms/vkms_crtc.c | 4 +++-
> >  2 files changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_crc.c 
> > b/drivers/gpu/drm/vkms/vkms_crc.c
> > index d7b409a3c0f8..09a8b00ef1f1 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> > @@ -161,6 +161,8 @@ void vkms_crc_work_handle(struct work_struct *work)
> > struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> > struct vkms_device *vdev = container_of(out, struct vkms_device,
> > output);
> > +   unsigned int pipe = drm_crtc_index(crtc);
> > +   struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe];
> > struct vkms_crc_data *primary_crc = NULL;
> > struct vkms_crc_data *cursor_crc = NULL;
> > struct drm_plane *plane;
> > @@ -196,7 +198,7 @@ void vkms_crc_work_handle(struct work_struct *work)
> > if (primary_crc)
> > crc32 = _vkms_get_crc(primary_crc, cursor_crc);
> >  
> > -   frame_end = drm_crtc_accurate_vblank_count(crtc);
> > +   frame_end = vblank->count;
> >  
> > /* queue_work can fail to schedule crc_work; add crc for
> >  * missing frames
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index 8a9aeb0a9ea8..9bf3268e2e92 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -10,6 +10,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
> > hrtimer *timer)
> >   vblank_hrtimer);
> > struct drm_crtc *crtc = &output->crtc;
> > struct vkms_crtc_state *state = to_vkms_crtc_state(crtc->state);
> > +   unsigned int pipe = drm_crtc_index(crtc);
> > +   struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe];
> > u64 ret_overrun;
> > bool ret;
> >  
> > @@ -20,7 +22,7 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
> > hrtimer *timer)
> > DRM_ERROR("vkms failure on handling vblank");
> >  
> > if (state && output->crc_enabled) {
> > -   u64 frame = drm_crtc_accurate_vblank_count(crtc);
> > +   u64 frame = vblank->count;
> >  
> > /* update frame_start only if a queued vkms_crc_work_handle()
> >  * has read the data
> > -- 
> > 2.17.1
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv11 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite

[Daniel Vetter]

On Mon, Feb 11, 2019 at 10:11:10AM +0800, Hean-Loong, Ong wrote:
> From: Ong, Hean Loong 
> 
> Signed-off-by: Ong, Hean Loong 

Per-patch changelog is missing here, would be good to include that to help
reviewers. I've done a very quick scroll through, looks like a nice&clean
driver.

Acked-by: Daniel Vetter 

I think all we need is ack from the dt side. Rob Herring has commit rights
to drm-misc, so he can push your driver once he's reviewed the dt side.

Cheers, Daniel

> ---
>  drivers/gpu/drm/ivip/Kconfig  |   14 +++
>  drivers/gpu/drm/ivip/Makefile |7 ++
>  drivers/gpu/drm/ivip/intel_vip_conn.c |   91 
>  drivers/gpu/drm/ivip/intel_vip_core.c |  189 
> +
>  drivers/gpu/drm/ivip/intel_vip_drv.h  |   73 +
>  drivers/gpu/drm/ivip/intel_vip_of.c   |  181 +++
>  6 files changed, 555 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/gpu/drm/ivip/Kconfig
>  create mode 100644 drivers/gpu/drm/ivip/Makefile
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
> 
> diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
> new file mode 100644
> index 000..1d08b90
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/Kconfig
> @@ -0,0 +1,14 @@
> +config DRM_IVIP
> +tristate "Intel FGPA Video and Image Processing"
> +depends on DRM && OF
> +select DRM_GEM_CMA_HELPER
> +select DRM_KMS_HELPER
> +select DRM_KMS_FB_HELPER
> +select DRM_KMS_CMA_HELPER
> +help
> +   Choose this option if you have an Intel FPGA Arria 10 system
> +   and above with an Intel Display Port IP. This does not support
> +   legacy Intel FPGA Cyclone V display port. Currently only 
> single
> +   frame buffer is supported. Note that ACPI and X_86 
> architecture
> +   is not supported for Arria10. If M is selected the module 
> will be
> +   called ivip.
> diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
> new file mode 100644
> index 000..3fd2e75
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Makefile for the drm device driver.  This driver provides support for the
> +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> +
> +obj-$(CONFIG_DRM_IVIP) += ivip.o
> +ivip-objs := intel_vip_of.o intel_vip_core.o \
> + intel_vip_conn.o
> diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c 
> b/drivers/gpu/drm/ivip/intel_vip_conn.c
> new file mode 100644
> index 000..93ce0b3
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
> @@ -0,0 +1,91 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Intel Corporation.
> + *
> + * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
> + * Frame Buffer II driver
> + *
> + * This driver supports the Intel VIP Frame Reader component.
> + * More info on the hardware can be found in the Intel Video
> + * and Image Processing Suite User Guide at this address
> + * http://www.altera.com/literature/ug/ug_vip.pdf.
> + *
> + * Authors:
> + * Walter Goossens 
> + * Thomas Chou 
> + * Chris Rauer 
> + * Ong, Hean-Loong 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static enum drm_connector_status
> +intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
> +{
> + return connector_status_connected;
> +}
> +
> +static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
> +{
> + drm_connector_unregister(connector);
> + drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = {
> + .detect = intelvipfb_drm_connector_detect,
> + .reset = drm_atomic_helper_connector_reset,
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> + .destroy = intelvipfb_drm_connector_destroy,
> +};
> +
> +static int intelvipfb_drm_connector_get_modes(struct drm_connector 
> *connector)
> +{
> + struct drm_device *drm = connector->dev;
> + int count;
> +
> + count = drm_add_modes_noedid(connector, drm->mode_config.max_width,
> + drm->mode_config.max_height);
> + drm_set_preferred_mode(connector, drm->mode_config.max_width,
> + drm->mode_config.max_height);
> + return count;
> +}
> +
> +static const struct drm_connector_helper_funcs
> +intelvipfb_drm_connector_helper_funcs = {
> + .get_modes = intelvipfb_drm_connector_get_modes,
> +};
> +
> +struct drm_connector *
> +intelvipfb_conn_setup(st

Re: [Intel-gfx] [PATCH] drm: Slightly quieten bad EDID messages

[Daniel Vetter]

On Thu, Feb 28, 2019 at 01:42:33PM +, Chris Wilson wrote:
> Bad EDID are a fact of life when dealing with random monitors. We only
> spam the logs when debugging is enabled, but we only need to raise
> notice and not set off the warning bells.
> 
> Signed-off-by: Chris Wilson 
> Cc: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_edid.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 990b1909f9d7..98903cb7064d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1535,9 +1535,8 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>   if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
>   return;
>  
> - dev_warn(connector->dev->dev,
> -  "%s: EDID is invalid:\n",
> -  connector->name);
> + dev_notice(connector->dev->dev,
> +"%s: EDID is invalid:\n", connector->name);
>   for (i = 0; i < num_blocks; i++) {
>   u8 *block = edid + i * EDID_LENGTH;
>   char prefix[20];
> @@ -1549,7 +1548,7 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>   else
>   sprintf(prefix, "\t[%02x] GOOD ", i);
>  
> - print_hex_dump(KERN_WARNING,
> + print_hex_dump(KERN_NOTICE,
>  prefix, DUMP_PREFIX_NONE, 16, 1,
>  block, EDID_LENGTH, false);
>   }

These two definitely make sense.

> @@ -4695,8 +4694,8 @@ int drm_add_edid_modes(struct drm_connector *connector, 
> struct edid *edid)
>   }
>   if (!drm_edid_is_valid(edid)) {
>   clear_eld(connector);
> - dev_warn(connector->dev->dev, "%s: EDID invalid.\n",
> -  connector->name);
> + dev_notice(connector->dev->dev,
> +"%s: EDID invalid.\n", connector->name);

Not entirely sure about this one, if we totally break the i2c reading, but
load detect still works (likely, since different paths at least for i915),
then we won't catch that. We'll just silently fall back to the default
modes (and maybe some wtf test failures).

I'd keep this one here.
-Daniel

>   return 0;
>   }
>  
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/hibmc: Drop best_encoder

[Daniel Vetter]

On Thu, Feb 28, 2019 at 02:16:03PM +0100, Noralf Trønnes wrote:
> 
> 
> Den 21.02.2019 16.58, skrev Daniel Vetter:
> > This is the default for atomic drivers.
> > 
> > Signed-off-by: Daniel Vetter 
> > Cc: Daniel Vetter 
> > Cc: Sam Ravnborg 
> > Cc: Neil Armstrong 
> > Cc: Luc Van Oostenryck 
> > Cc: Rodrigo Vivi 
> > ---
> 
> Acked-by: Noralf Trønnes 
Thanks for taking a look, merged to drm-misc-next.
-Daniel
> 
> >  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 7 ---
> >  1 file changed, 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c 
> > b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> > index d2cf7317930a..8c2f9b9cafb3 100644
> > --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> > @@ -33,17 +33,10 @@ static enum drm_mode_status 
> > hibmc_connector_mode_valid(struct drm_connector *con
> > return MODE_OK;
> >  }
> >  
> > -static struct drm_encoder *
> > -hibmc_connector_best_encoder(struct drm_connector *connector)
> > -{
> > -   return drm_encoder_find(connector->dev, NULL, 
> > connector->encoder_ids[0]);
> > -}
> > -
> >  static const struct drm_connector_helper_funcs
> > hibmc_connector_helper_funcs = {
> > .get_modes = hibmc_connector_get_modes,
> > .mode_valid = hibmc_connector_mode_valid,
> > -   .best_encoder = hibmc_connector_best_encoder,
> >  };
> >  
> >  static const struct drm_connector_funcs hibmc_connector_funcs = {
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109749] FreeSync stutters if framerate is less than refresh rate and vsync/flipping is on

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109749

--- Comment #4 from Nicholas Kazlauskas  ---
It technically isn't in amd-staging-drm-next directly yet, but it is in the
fixes branch. It'll make its way to staging and 5.1 eventually.

Like Michel said, feel free to mark as resolved when you feel that it is.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/7] drm/lease: Check for lessor outside of locks

[Daniel Vetter]

The lessor is invariant over a lifetime of a lease, we don't have to
grab any locks for that. Speeds up the common case of not being a lease.

Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_lease.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index cce5d9dd52ff..694ff363a90b 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -111,7 +111,7 @@ static bool _drm_has_leased(struct drm_master *master, int 
id)
  */
 bool _drm_lease_held(struct drm_file *file_priv, int id)
 {
-   if (file_priv == NULL || file_priv->master == NULL)
+   if (!file_priv || !file_priv->master)
return true;
 
return _drm_lease_held_master(file_priv->master, id);
@@ -133,7 +133,7 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
struct drm_master *master;
bool ret;
 
-   if (file_priv == NULL || file_priv->master == NULL)
+   if (!file_priv || !file_priv->master || !file_priv->master->lessor)
return true;
 
master = file_priv->master;
@@ -159,7 +159,7 @@ uint32_t drm_lease_filter_crtcs(struct drm_file *file_priv, 
uint32_t crtcs_in)
int count_in, count_out;
uint32_t crtcs_out = 0;
 
-   if (file_priv == NULL || file_priv->master == NULL)
+   if (!file_priv || !file_priv->master || !file_priv->master->lessor)
return crtcs_in;
 
master = file_priv->master;
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/7] drm/lease: Drop recursive leads checks

[Daniel Vetter]

We disallow subleasing, so no point checking whether the master holds
all the leases - it will.

Spotted while typing exhaustive igt coverage for all these corner
cases.

Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_lease.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 1176d814cf7f..cce5d9dd52ff 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -220,8 +220,6 @@ static struct drm_master *drm_lease_create(struct 
drm_master *lessor, struct idr
error = 0;
if (!idr_find(&dev->mode_config.object_idr, object))
error = -ENOENT;
-   else if (!_drm_lease_held_master(lessor, object))
-   error = -EACCES;
else if (_drm_has_leased(lessor, object))
error = -EBUSY;
 
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] drm/lease: Make sure implicit planes are leased

[Daniel Vetter]

If userspace doesn't enable universal planes, then we automatically
add the primary and cursor planes. But for universal userspace there's
no such check (and maybe we only want to give the lessee one plane,
maybe not even the primary one), hence we need to check for the
implied plane.

v2: don't forget setcrtc ioctl.

v3: Still allow disabling of the crtc in SETCRTC.

Cc: sta...@vger.kernel.org
Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c  | 4 
 drivers/gpu/drm/drm_plane.c | 8 
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7dabbaf033a1..790ba5941954 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -559,6 +559,10 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
 
plane = crtc->primary;
 
+   /* allow disabling with the primary plane leased */
+   if (crtc_req->mode_valid && !drm_lease_held(file_priv, plane->base.id))
+   return -EACCES;
+
mutex_lock(&crtc->dev->mode_config.mutex);
DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx,
   DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 4cfb56893b7f..d6ad60ab0d38 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -960,6 +960,11 @@ static int drm_mode_cursor_common(struct drm_device *dev,
if (ret)
goto out;
 
+   if (!drm_lease_held(file_priv, crtc->cursor->base.id)) {
+   ret = -EACCES;
+   goto out;
+   }
+
ret = drm_mode_cursor_universal(crtc, req, file_priv, &ctx);
goto out;
}
@@ -1062,6 +1067,9 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
 
plane = crtc->primary;
 
+   if (!drm_lease_held(file_priv, plane->base.id))
+   return -EACCES;
+
if (crtc->funcs->page_flip_target) {
u32 current_vblank;
int r;
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/7] some cleanups and uapi clarification for leases

[Daniel Vetter]

Hi all,

Nothing too major, only things I did find in all my igt test extending for
drm lease is some corner cases around implicit planes and atomic target
crtcs. Review and comments very much appreciated.

Cheers, Daniel

Test-with: 20190228141918.26043-1-daniel.vet...@ffwll.ch

Daniel Vetter (7):
  drm/leases: Drop object_id validation for negative ids
  drm/lease: Drop recursive leads checks
  drm/leases: Don't init to 0 in drm_master_create
  drm/lease: Check for lessor outside of locks
  drm/lease: Make sure implicit planes are leased
  drm/atomic: Wire file_priv through for property changes
  drm/atomic: -EACCESS for lease-denied crtc lookup

 drivers/gpu/drm/drm_atomic_uapi.c   | 36 +++-
 drivers/gpu/drm/drm_auth.c  |  2 --
 drivers/gpu/drm/drm_crtc.c  |  4 
 drivers/gpu/drm/drm_crtc_internal.h |  1 +
 drivers/gpu/drm/drm_lease.c | 13 +++--
 drivers/gpu/drm/drm_mode_object.c   |  5 +++--
 drivers/gpu/drm/drm_plane.c |  8 
 7 files changed, 42 insertions(+), 27 deletions(-)

-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] drm/leases: Drop object_id validation for negative ids

[Daniel Vetter]

Not exactly sure what's the aim here, but the canonical nil object has
id == 0, we don't use negative object ids for anything. Plus all
object_id are valided by the object_idr, there's nothing we need to do
on top of that ENOENT check a bit further down.

Spotted while typing exhaustive igt coverage for all these
corner-cases.

Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_lease.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 603b0bd9c5ce..1176d814cf7f 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -403,11 +403,6 @@ static int fill_object_idr(struct drm_device *dev,
/* step one - get references to all the mode objects
   and check for validity. */
for (o = 0; o < object_count; o++) {
-   if ((int) object_ids[o] < 0) {
-   ret = -EINVAL;
-   goto out_free_objects;
-   }
-
objects[o] = drm_mode_object_find(dev, lessor_priv,
  object_ids[o],
  DRM_MODE_OBJECT_ANY);
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/7] drm/atomic: Wire file_priv through for property changes

[Daniel Vetter]

We need this to make sure lessees can only connect their
plane/connectors to crtc objects they own. And note that this is
irrespective of whether the lessor is atomic or not, lessor cannot
prevent lessees from enabling atomic.

Cc: sta...@vger.kernel.org
Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_uapi.c   | 32 +++-
 drivers/gpu/drm/drm_crtc_internal.h |  1 +
 drivers/gpu/drm/drm_mode_object.c   |  5 +++--
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 4eb81f10bc54..f0dbfeb00926 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -512,8 +512,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
 }
 
 static int drm_atomic_plane_set_property(struct drm_plane *plane,
-   struct drm_plane_state *state, struct drm_property *property,
-   uint64_t val)
+   struct drm_plane_state *state, struct drm_file *file_priv,
+   struct drm_property *property, uint64_t val)
 {
struct drm_device *dev = plane->dev;
struct drm_mode_config *config = &dev->mode_config;
@@ -521,7 +521,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
int ret;
 
if (property == config->prop_fb_id) {
-   struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
+   struct drm_framebuffer *fb;
+   fb = drm_framebuffer_lookup(dev, file_priv, val);
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
drm_framebuffer_put(fb);
@@ -537,7 +538,7 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
return -EINVAL;
 
} else if (property == config->prop_crtc_id) {
-   struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
+   struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
return drm_atomic_set_crtc_for_plane(state, crtc);
} else if (property == config->prop_crtc_x) {
state->crtc_x = U642I64(val);
@@ -681,14 +682,14 @@ static int drm_atomic_set_writeback_fb_for_connector(
 }
 
 static int drm_atomic_connector_set_property(struct drm_connector *connector,
-   struct drm_connector_state *state, struct drm_property 
*property,
-   uint64_t val)
+   struct drm_connector_state *state, struct drm_file *file_priv,
+   struct drm_property *property, uint64_t val)
 {
struct drm_device *dev = connector->dev;
struct drm_mode_config *config = &dev->mode_config;
 
if (property == config->prop_crtc_id) {
-   struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
+   struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
return drm_atomic_set_crtc_for_connector(state, crtc);
} else if (property == config->dpms_property) {
/* setting DPMS property requires special handling, which
@@ -749,8 +750,10 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
-   struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
-   int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
+   struct drm_framebuffer *fb;
+   int ret;
+   fb = drm_framebuffer_lookup(dev, file_priv, val);
+   ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
if (fb)
drm_framebuffer_put(fb);
return ret;
@@ -947,6 +950,7 @@ int drm_atomic_connector_commit_dpms(struct 
drm_atomic_state *state,
 }
 
 int drm_atomic_set_property(struct drm_atomic_state *state,
+   struct drm_file *file_priv,
struct drm_mode_object *obj,
struct drm_property *prop,
uint64_t prop_value)
@@ -969,7 +973,8 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
}
 
ret = drm_atomic_connector_set_property(connector,
-   connector_state, prop, prop_value);
+   connector_state, file_priv,
+   prop, prop_value);
break;
}
case DRM_MODE_OBJECT_CRTC: {
@@ -997,7 +1002,8 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
}
 
ret = drm_atomic_plane_set_property(plane,
-   plane_state, prop, prop_value);
+   plane_state, file_priv,
+   prop, prop_value);
  

[PATCH 3/7] drm/leases: Don't init to 0 in drm_master_create

[Daniel Vetter]

We kzalloc.

Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_auth.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 1669c42c40ed..bcf0a5a1018f 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -109,8 +109,6 @@ struct drm_master *drm_master_create(struct drm_device *dev)
master->dev = dev;
 
/* initialize the tree of output resource lessees */
-   master->lessor = NULL;
-   master->lessee_id = 0;
INIT_LIST_HEAD(&master->lessees);
INIT_LIST_HEAD(&master->lessee_list);
idr_init(&master->leases);
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/7] drm/atomic: -EACCESS for lease-denied crtc lookup

[Daniel Vetter]

With the previous patch drm_crtc_find will return NULL when the crtc
isn't in our lease, which will then disable the plane/connector. No
longer an issue since the lessor can't escape their lease terms
anymore, but not quite great semantics yet either.

Catch this and return -EACCES, so that at least evil test cases have a
better chance of making sure the kernel works correctly.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index f0dbfeb00926..6687215cc188 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -539,6 +539,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
 
} else if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
+   if (val && !crtc)
+   return -EACCES;
return drm_atomic_set_crtc_for_plane(state, crtc);
} else if (property == config->prop_crtc_x) {
state->crtc_x = U642I64(val);
@@ -690,6 +692,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 
if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
+   if (val && !crtc)
+   return -EACCES;
return drm_atomic_set_crtc_for_connector(state, crtc);
} else if (property == config->dpms_property) {
/* setting DPMS property requires special handling, which
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.20 37/81] drm/amdgpu: Transfer fences to dmabuf importer

[Sasha Levin]

From: Chris Wilson 

[ Upstream commit 6e11ea9de9576a644045ffdc2067c09bc2012eda ]

amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As such, on exporting a dmabuf, we must either flush all
outstanding fences (for we do not know which are writes and should have
been exclusive) or alternatively create a new exclusive fence that is
the composite of all the existing shared fences, and so will only be
signaled when all earlier fences are signaled (ensuring that we can not
be signaled before the completion of any earlier write).

v2: reservation_object is already locked by amdgpu_bo_reserve()
v3: Replace looping with get_fences_rcu and special case the promotion
of a single shared fence directly to an exclusive fence, bypassing the
fence array.
v4: Drop the fence array ref after assigning to reservation_object

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Testcase: igt/amd_prime/amd-to-i915
References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported 
bo's. (v5)")
Signed-off-by: Chris Wilson 
Cc: Alex Deucher 
Cc: "Christian König" 
Reviewed-by: "Christian König" 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 59 ---
 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index e45e929aaab5b..90a5970af4b7f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -38,6 +38,7 @@
 #include "amdgpu_gem.h"
 #include 
 #include 
+#include 
 
 static const struct dma_buf_ops amdgpu_dmabuf_ops;
 
@@ -189,6 +190,48 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
 }
 
+static int
+__reservation_object_make_exclusive(struct reservation_object *obj)
+{
+   struct dma_fence **fences;
+   unsigned int count;
+   int r;
+
+   if (!reservation_object_get_list(obj)) /* no shared fences to convert */
+   return 0;
+
+   r = reservation_object_get_fences_rcu(obj, NULL, &count, &fences);
+   if (r)
+   return r;
+
+   if (count == 0) {
+   /* Now that was unexpected. */
+   } else if (count == 1) {
+   reservation_object_add_excl_fence(obj, fences[0]);
+   dma_fence_put(fences[0]);
+   kfree(fences);
+   } else {
+   struct dma_fence_array *array;
+
+   array = dma_fence_array_create(count, fences,
+  dma_fence_context_alloc(1), 0,
+  false);
+   if (!array)
+   goto err_fences_put;
+
+   reservation_object_add_excl_fence(obj, &array->base);
+   dma_fence_put(&array->base);
+   }
+
+   return 0;
+
+err_fences_put:
+   while (count--)
+   dma_fence_put(fences[count]);
+   kfree(fences);
+   return -ENOMEM;
+}
+
 /**
  * amdgpu_gem_map_attach - &dma_buf_ops.attach implementation
  * @dma_buf: Shared DMA buffer
@@ -220,16 +263,16 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
 
if (attach->dev->driver != adev->dev->driver) {
/*
-* Wait for all shared fences to complete before we switch to 
future
-* use of exclusive fence on this prime shared bo.
+* We only create shared fences for internal use, but importers
+* of the dmabuf rely on exclusive fences for implicitly
+* tracking write hazards. As any of the current fences may
+* correspond to a write, we need to convert all existing
+* fences on the reservation object into a single exclusive
+* fence.
 */
-   r = reservation_object_wait_timeout_rcu(bo->tbo.resv,
-   true, false,
-   MAX_SCHEDULE_TIMEOUT);
-   if (unlikely(r < 0)) {
-   DRM_DEBUG_PRIME("Fence wait failed: %li\n", r);
+   r = __reservation_object_make_exclusive(bo->tbo.resv);
+   if (r)
goto error_unreserve;
-   }
}
 
/* pin buffer into GTT */
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.20 33/81] drm/radeon: check if device is root before getting pci speed caps

[Sasha Levin]

From: Alex Deucher 

[ Upstream commit afeff4c16edaa6275b903f82b0561406259aa3a3 ]

Check if the device is root rather before attempting to see what
speeds the pcie port supports.  Fixes a crash with pci passthrough
in a VM.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109366
Reviewed-by: Evan Quan 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 5 +++--
 drivers/gpu/drm/radeon/si_dpm.c | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index d587779a80b4d..a97294ac96d59 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -5676,7 +5676,7 @@ int ci_dpm_init(struct radeon_device *rdev)
u16 data_offset, size;
u8 frev, crev;
struct ci_power_info *pi;
-   enum pci_bus_speed speed_cap;
+   enum pci_bus_speed speed_cap = PCI_SPEED_UNKNOWN;
struct pci_dev *root = rdev->pdev->bus->self;
int ret;
 
@@ -5685,7 +5685,8 @@ int ci_dpm_init(struct radeon_device *rdev)
return -ENOMEM;
rdev->pm.dpm.priv = pi;
 
-   speed_cap = pcie_get_speed_cap(root);
+   if (!pci_is_root_bus(rdev->pdev->bus))
+   speed_cap = pcie_get_speed_cap(root);
if (speed_cap == PCI_SPEED_UNKNOWN) {
pi->sys_pcie_mask = 0;
} else {
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 8fb60b3af0158..0a785ef0ab660 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -6899,7 +6899,7 @@ int si_dpm_init(struct radeon_device *rdev)
struct ni_power_info *ni_pi;
struct si_power_info *si_pi;
struct atom_clock_dividers dividers;
-   enum pci_bus_speed speed_cap;
+   enum pci_bus_speed speed_cap = PCI_SPEED_UNKNOWN;
struct pci_dev *root = rdev->pdev->bus->self;
int ret;
 
@@ -6911,7 +6911,8 @@ int si_dpm_init(struct radeon_device *rdev)
eg_pi = &ni_pi->eg;
pi = &eg_pi->rv7xx;
 
-   speed_cap = pcie_get_speed_cap(root);
+   if (!pci_is_root_bus(rdev->pdev->bus))
+   speed_cap = pcie_get_speed_cap(root);
if (speed_cap == PCI_SPEED_UNKNOWN) {
si_pi->sys_pcie_mask = 0;
} else {
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.20 50/81] drm/amdgpu: Implement doorbell self-ring for NBIO 7.4

[Sasha Levin]

From: Jay Cornwall 

[ Upstream commit 12292519d919ecde92e7e7c8acbcdb9f0c7c6013 ]

Fixes doorbell reflection on Vega20.

Change-Id: I0495139d160a9032dff5977289b1eec11c16f781
Signed-off-by: Jay Cornwall 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c 
b/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c
index f8cee95d61cc1..7d5cbadbe1cbc 100644
--- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c
+++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c
@@ -92,7 +92,20 @@ static void nbio_v7_4_enable_doorbell_aperture(struct 
amdgpu_device *adev,
 static void nbio_v7_4_enable_doorbell_selfring_aperture(struct amdgpu_device 
*adev,
bool enable)
 {
+   u32 tmp = 0;
 
+   if (enable) {
+   tmp = REG_SET_FIELD(tmp, DOORBELL_SELFRING_GPA_APER_CNTL, 
DOORBELL_SELFRING_GPA_APER_EN, 1) |
+ REG_SET_FIELD(tmp, DOORBELL_SELFRING_GPA_APER_CNTL, 
DOORBELL_SELFRING_GPA_APER_MODE, 1) |
+ REG_SET_FIELD(tmp, DOORBELL_SELFRING_GPA_APER_CNTL, 
DOORBELL_SELFRING_GPA_APER_SIZE, 0);
+
+   WREG32_SOC15(NBIO, 0, mmDOORBELL_SELFRING_GPA_APER_BASE_LOW,
+lower_32_bits(adev->doorbell.base));
+   WREG32_SOC15(NBIO, 0, mmDOORBELL_SELFRING_GPA_APER_BASE_HIGH,
+upper_32_bits(adev->doorbell.base));
+   }
+
+   WREG32_SOC15(NBIO, 0, mmDOORBELL_SELFRING_GPA_APER_CNTL, tmp);
 }
 
 static void nbio_v7_4_ih_doorbell_range(struct amdgpu_device *adev,
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.20 32/81] drm/amdgpu: Add missing power attribute to APU check

[Sasha Levin]

From: Alex Deucher 

[ Upstream commit dc14eb12f6bb3e779c5461429c1889a339c67aab ]

Add missing power_average to visible check for power
attributes for APUs.  Was missed before.

Reviewed-by: Evan Quan 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 59cc678de8c15..bbac15fd8caac 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1671,7 +1671,8 @@ static umode_t hwmon_attributes_visible(struct kobject 
*kobj,
effective_mode &= ~S_IWUSR;
 
if ((adev->flags & AMD_IS_APU) &&
-   (attr == &sensor_dev_attr_power1_cap_max.dev_attr.attr ||
+   (attr == &sensor_dev_attr_power1_average.dev_attr.attr ||
+attr == &sensor_dev_attr_power1_cap_max.dev_attr.attr ||
 attr == &sensor_dev_attr_power1_cap_min.dev_attr.attr||
 attr == &sensor_dev_attr_power1_cap.dev_attr.attr))
return 0;
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.20 52/81] drm/sun4i: tcon: Prepare and enable TCON channel 0 clock at init

[Sasha Levin]

From: Paul Kocialkowski 

[ Upstream commit b14e945bda8ae227d1bf2b1837c0c4a61721cd1a ]

When initializing clocks, a reference to the TCON channel 0 clock is
obtained. However, the clock is never prepared and enabled later.
Switching from simplefb to DRM actually disables the clock (that was
usually configured by U-Boot) because of that.

On the V3s, this results in a hang when writing to some mixer registers
when switching over to DRM from simplefb.

Fix this by preparing and enabling the clock when initializing other
clocks. Waiting for sun4i_tcon_channel_enable to enable the clock is
apparently too late and results in the same mixer register access hang.

Signed-off-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190131132550.26355-1-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index f949287d926cd..4e0562aa2cc90 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -760,6 +760,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
return PTR_ERR(tcon->sclk0);
}
}
+   clk_prepare_enable(tcon->sclk0);
 
if (tcon->quirks->has_channel_1) {
tcon->sclk1 = devm_clk_get(dev, "tcon-ch1");
@@ -774,6 +775,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
 
 static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
 {
+   clk_disable_unprepare(tcon->sclk0);
clk_disable_unprepare(tcon->clk);
 }
 
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.20 51/81] drm/amdgpu: fix the incorrect external id for raven series

[Sasha Levin]

From: Huang Rui 

[ Upstream commit 7e4545d372b560df10fa47281ef0783a479ce435 ]

This patch fixes the incorrect external id that kernel reports to user mode
driver. Raven2's rev_id is starts from 0x8, so its external id (0x81) should
start from rev_id + 0x79 (0x81 - 0x8). And Raven's rev_id should be 0x21 while
rev_id == 1.

Reported-by: Crystal Jin 
Signed-off-by: Huang Rui 
Reviewed-by: Hawking Zhang 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/soc15.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c 
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index 4cc0dcb1a1875..825d1cae85abd 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -705,11 +705,13 @@ static int soc15_common_early_init(void *handle)
break;
case CHIP_RAVEN:
if (adev->rev_id >= 0x8)
-   adev->external_rev_id = adev->rev_id + 0x81;
+   adev->external_rev_id = adev->rev_id + 0x79;
else if (adev->pdev->device == 0x15d8)
adev->external_rev_id = adev->rev_id + 0x41;
+   else if (adev->rev_id == 1)
+   adev->external_rev_id = adev->rev_id + 0x20;
else
-   adev->external_rev_id = 0x1;
+   adev->external_rev_id = adev->rev_id + 0x01;
 
if (adev->rev_id >= 0x8) {
adev->cg_flags = AMD_CG_SUPPORT_GFX_MGCG |
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.20 72/81] drm/omap: dsi: Fix crash in DSI debug dumps

[Sasha Levin]

From: Tomi Valkeinen 

[ Upstream commit 4df04ac9b37f278c48bb696289aff8f81226af4b ]

Reading any of the DSI debugfs files results in a crash, as wrong
pointer is passed to the dump functions, and the dump functions use a
wrong pointer. This patch fixes DSI debug dumps.

Fixes: f3ed97f9ae7d ("drm/omap: dsi: Simplify debugfs implementation")
Signed-off-by: Tomi Valkeinen 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Tomi Valkeinen 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190111035120.20668-3-laurent.pinch...@ideasonboard.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/omapdrm/dss/dsi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 00a9c2ab9e6c8..277f9dd2ec8ca 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -1406,7 +1406,7 @@ static void dsi_pll_disable(struct dss_pll *pll)
 
 static int dsi_dump_dsi_clocks(struct seq_file *s, void *p)
 {
-   struct dsi_data *dsi = p;
+   struct dsi_data *dsi = s->private;
struct dss_pll_clock_info *cinfo = &dsi->pll.cinfo;
enum dss_clk_source dispc_clk_src, dsi_clk_src;
int dsi_module = dsi->module_id;
@@ -1467,7 +1467,7 @@ static int dsi_dump_dsi_clocks(struct seq_file *s, void 
*p)
 #ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
 static int dsi_dump_dsi_irqs(struct seq_file *s, void *p)
 {
-   struct dsi_data *dsi = p;
+   struct dsi_data *dsi = s->private;
unsigned long flags;
struct dsi_irq_stats stats;
 
@@ -1558,7 +1558,7 @@ static int dsi_dump_dsi_irqs(struct seq_file *s, void *p)
 
 static int dsi_dump_dsi_regs(struct seq_file *s, void *p)
 {
-   struct dsi_data *dsi = p;
+   struct dsi_data *dsi = s->private;
 
if (dsi_runtime_get(dsi))
return 0;
@@ -5083,15 +5083,15 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
 
snprintf(name, sizeof(name), "dsi%u_regs", dsi->module_id + 1);
dsi->debugfs.regs = dss_debugfs_create_file(dss, name,
-   dsi_dump_dsi_regs, &dsi);
+   dsi_dump_dsi_regs, dsi);
 #ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
snprintf(name, sizeof(name), "dsi%u_irqs", dsi->module_id + 1);
dsi->debugfs.irqs = dss_debugfs_create_file(dss, name,
-   dsi_dump_dsi_irqs, &dsi);
+   dsi_dump_dsi_irqs, dsi);
 #endif
snprintf(name, sizeof(name), "dsi%u_clks", dsi->module_id + 1);
dsi->debugfs.clks = dss_debugfs_create_file(dss, name,
-   dsi_dump_dsi_clocks, &dsi);
+   dsi_dump_dsi_clocks, dsi);
 
return 0;
 }
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.20 73/81] drm/omap: dsi: Fix OF platform depopulate

[Sasha Levin]

From: Tomi Valkeinen 

[ Upstream commit 0940c52742de0d2f70ba687bfd5fe8aa38c5f27d ]

Commit edb715dffdee ("drm/omap: dss: dsi: Move initialization code from
bind to probe") moved the of_platform_populate() call from dsi_bind() to
dsi_probe(), but failed to move the corresponding
of_platform_depopulate() from dsi_unbind() to dsi_remove(). This results
in OF child devices being potentially removed multiple times. Fix it by
placing the of_platform_depopulate() call where it belongs.

Fixes: edb715dffdee ("drm/omap: dss: dsi: Move initialization code from bind to 
probe")
Signed-off-by: Laurent Pinchart 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Tomi Valkeinen 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190111035120.20668-4-laurent.pinch...@ideasonboard.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/omapdrm/dss/dsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 277f9dd2ec8ca..b5685018d8302 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -5104,8 +5104,6 @@ static void dsi_unbind(struct device *dev, struct device 
*master, void *data)
dss_debugfs_remove_file(dsi->debugfs.irqs);
dss_debugfs_remove_file(dsi->debugfs.regs);
 
-   of_platform_depopulate(dev);
-
WARN_ON(dsi->scp_clk_refcount > 0);
 
dss_pll_unregister(&dsi->pll);
@@ -5457,6 +5455,8 @@ static int dsi_remove(struct platform_device *pdev)
 
dsi_uninit_output(dsi);
 
+   of_platform_depopulate(&pdev->dev);
+
pm_runtime_disable(&pdev->dev);
 
if (dsi->vdds_dsi_reg != NULL && dsi->vdds_dsi_enabled) {
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.20 71/81] drm/amdgpu: use spin_lock_irqsave to protect vm_manager.pasid_idr

[Sasha Levin]

From: Philip Yang 

[ Upstream commit 0a5f49cbf9d6ad3721c16f8a6d823363ea7a160f ]

amdgpu_vm_get_task_info is called from interrupt handler and sched timeout
workqueue, we should use irq version spin_lock to avoid deadlock.

Signed-off-by: Philip Yang 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 62df4bd0a0fc2..16c83155ef5ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -3405,14 +3405,15 @@ void amdgpu_vm_get_task_info(struct amdgpu_device 
*adev, unsigned int pasid,
 struct amdgpu_task_info *task_info)
 {
struct amdgpu_vm *vm;
+   unsigned long flags;
 
-   spin_lock(&adev->vm_manager.pasid_lock);
+   spin_lock_irqsave(&adev->vm_manager.pasid_lock, flags);
 
vm = idr_find(&adev->vm_manager.pasid_idr, pasid);
if (vm)
*task_info = vm->task_info;
 
-   spin_unlock(&adev->vm_manager.pasid_lock);
+   spin_unlock_irqrestore(&adev->vm_manager.pasid_lock, flags);
 }
 
 /**
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.20 74/81] drm/omap: dsi: Hack-fix DSI bus flags

[Sasha Levin]

From: Tomi Valkeinen 

[ Upstream commit 6297388e1eddd2f1345cea5892156223995bcf2d ]

Since commit b4935e3a3cfa ("drm/omap: Store bus flags in the
omap_dss_device structure") video mode flags are managed by the omapdss
(and later omapdrm) core based on bus flags stored in omap_dss_device.
This works fine for all devices whose video modes are set by the omapdss
and omapdrm core, but breaks DSI operation as the DSI still uses legacy
code paths and sets the DISPC timings manually.

To fix the problem properly we should move the DSI encoder to the new
encoder model. This will however require a considerable amount of work.
Restore DSI operation by adding back video mode flags handling in the
DSI encoder driver as a hack in the meantime.

Fixes: b4935e3a3cfa ("drm/omap: Store bus flags in the omap_dss_device 
structure")
Signed-off-by: Laurent Pinchart 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Tomi Valkeinen 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190111035120.20668-5-laurent.pinch...@ideasonboard.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/omapdrm/dss/dsi.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index b5685018d8302..64fb788b66474 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -4751,6 +4751,17 @@ static int dsi_set_config(struct omap_dss_device *dssdev,
dsi->vm.flags |= DISPLAY_FLAGS_HSYNC_HIGH;
dsi->vm.flags &= ~DISPLAY_FLAGS_VSYNC_LOW;
dsi->vm.flags |= DISPLAY_FLAGS_VSYNC_HIGH;
+   /*
+* HACK: These flags should be handled through the omap_dss_device bus
+* flags, but this will only be possible when the DSI encoder will be
+* converted to the omapdrm-managed encoder model.
+*/
+   dsi->vm.flags &= ~DISPLAY_FLAGS_PIXDATA_NEGEDGE;
+   dsi->vm.flags |= DISPLAY_FLAGS_PIXDATA_POSEDGE;
+   dsi->vm.flags &= ~DISPLAY_FLAGS_DE_LOW;
+   dsi->vm.flags |= DISPLAY_FLAGS_DE_HIGH;
+   dsi->vm.flags &= ~DISPLAY_FLAGS_SYNC_POSEDGE;
+   dsi->vm.flags |= DISPLAY_FLAGS_SYNC_NEGEDGE;
 
dss_mgr_set_timings(&dsi->output, &dsi->vm);
 
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.19 25/64] drm/radeon: check if device is root before getting pci speed caps

[Sasha Levin]

From: Alex Deucher 

[ Upstream commit afeff4c16edaa6275b903f82b0561406259aa3a3 ]

Check if the device is root rather before attempting to see what
speeds the pcie port supports.  Fixes a crash with pci passthrough
in a VM.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109366
Reviewed-by: Evan Quan 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 5 +++--
 drivers/gpu/drm/radeon/si_dpm.c | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index d587779a80b4d..a97294ac96d59 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -5676,7 +5676,7 @@ int ci_dpm_init(struct radeon_device *rdev)
u16 data_offset, size;
u8 frev, crev;
struct ci_power_info *pi;
-   enum pci_bus_speed speed_cap;
+   enum pci_bus_speed speed_cap = PCI_SPEED_UNKNOWN;
struct pci_dev *root = rdev->pdev->bus->self;
int ret;
 
@@ -5685,7 +5685,8 @@ int ci_dpm_init(struct radeon_device *rdev)
return -ENOMEM;
rdev->pm.dpm.priv = pi;
 
-   speed_cap = pcie_get_speed_cap(root);
+   if (!pci_is_root_bus(rdev->pdev->bus))
+   speed_cap = pcie_get_speed_cap(root);
if (speed_cap == PCI_SPEED_UNKNOWN) {
pi->sys_pcie_mask = 0;
} else {
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 8fb60b3af0158..0a785ef0ab660 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -6899,7 +6899,7 @@ int si_dpm_init(struct radeon_device *rdev)
struct ni_power_info *ni_pi;
struct si_power_info *si_pi;
struct atom_clock_dividers dividers;
-   enum pci_bus_speed speed_cap;
+   enum pci_bus_speed speed_cap = PCI_SPEED_UNKNOWN;
struct pci_dev *root = rdev->pdev->bus->self;
int ret;
 
@@ -6911,7 +6911,8 @@ int si_dpm_init(struct radeon_device *rdev)
eg_pi = &ni_pi->eg;
pi = &eg_pi->rv7xx;
 
-   speed_cap = pcie_get_speed_cap(root);
+   if (!pci_is_root_bus(rdev->pdev->bus))
+   speed_cap = pcie_get_speed_cap(root);
if (speed_cap == PCI_SPEED_UNKNOWN) {
si_pi->sys_pcie_mask = 0;
} else {
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.19 24/64] drm/amdgpu: Add missing power attribute to APU check

[Sasha Levin]

From: Alex Deucher 

[ Upstream commit dc14eb12f6bb3e779c5461429c1889a339c67aab ]

Add missing power_average to visible check for power
attributes for APUs.  Was missed before.

Reviewed-by: Evan Quan 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 7b4e657a95c70..c3df75a9f65d9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1443,7 +1443,8 @@ static umode_t hwmon_attributes_visible(struct kobject 
*kobj,
effective_mode &= ~S_IWUSR;
 
if ((adev->flags & AMD_IS_APU) &&
-   (attr == &sensor_dev_attr_power1_cap_max.dev_attr.attr ||
+   (attr == &sensor_dev_attr_power1_average.dev_attr.attr ||
+attr == &sensor_dev_attr_power1_cap_max.dev_attr.attr ||
 attr == &sensor_dev_attr_power1_cap_min.dev_attr.attr||
 attr == &sensor_dev_attr_power1_cap.dev_attr.attr))
return 0;
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.19 39/64] drm/sun4i: tcon: Prepare and enable TCON channel 0 clock at init

[Sasha Levin]

From: Paul Kocialkowski 

[ Upstream commit b14e945bda8ae227d1bf2b1837c0c4a61721cd1a ]

When initializing clocks, a reference to the TCON channel 0 clock is
obtained. However, the clock is never prepared and enabled later.
Switching from simplefb to DRM actually disables the clock (that was
usually configured by U-Boot) because of that.

On the V3s, this results in a hang when writing to some mixer registers
when switching over to DRM from simplefb.

Fix this by preparing and enabling the clock when initializing other
clocks. Waiting for sun4i_tcon_channel_enable to enable the clock is
apparently too late and results in the same mixer register access hang.

Signed-off-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190131132550.26355-1-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 3fb084f802e29..8c31c9ab06f8b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -672,6 +672,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
return PTR_ERR(tcon->sclk0);
}
}
+   clk_prepare_enable(tcon->sclk0);
 
if (tcon->quirks->has_channel_1) {
tcon->sclk1 = devm_clk_get(dev, "tcon-ch1");
@@ -686,6 +687,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
 
 static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
 {
+   clk_disable_unprepare(tcon->sclk0);
clk_disable_unprepare(tcon->clk);
 }
 
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.19 28/64] drm/amdgpu: Transfer fences to dmabuf importer

[Sasha Levin]

From: Chris Wilson 

[ Upstream commit 6e11ea9de9576a644045ffdc2067c09bc2012eda ]

amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As such, on exporting a dmabuf, we must either flush all
outstanding fences (for we do not know which are writes and should have
been exclusive) or alternatively create a new exclusive fence that is
the composite of all the existing shared fences, and so will only be
signaled when all earlier fences are signaled (ensuring that we can not
be signaled before the completion of any earlier write).

v2: reservation_object is already locked by amdgpu_bo_reserve()
v3: Replace looping with get_fences_rcu and special case the promotion
of a single shared fence directly to an exclusive fence, bypassing the
fence array.
v4: Drop the fence array ref after assigning to reservation_object

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Testcase: igt/amd_prime/amd-to-i915
References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported 
bo's. (v5)")
Signed-off-by: Chris Wilson 
Cc: Alex Deucher 
Cc: "Christian König" 
Reviewed-by: "Christian König" 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 59 ---
 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 1c5d97f4b4dde..8dcf6227ab990 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -37,6 +37,7 @@
 #include "amdgpu_display.h"
 #include 
 #include 
+#include 
 
 static const struct dma_buf_ops amdgpu_dmabuf_ops;
 
@@ -188,6 +189,48 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
 }
 
+static int
+__reservation_object_make_exclusive(struct reservation_object *obj)
+{
+   struct dma_fence **fences;
+   unsigned int count;
+   int r;
+
+   if (!reservation_object_get_list(obj)) /* no shared fences to convert */
+   return 0;
+
+   r = reservation_object_get_fences_rcu(obj, NULL, &count, &fences);
+   if (r)
+   return r;
+
+   if (count == 0) {
+   /* Now that was unexpected. */
+   } else if (count == 1) {
+   reservation_object_add_excl_fence(obj, fences[0]);
+   dma_fence_put(fences[0]);
+   kfree(fences);
+   } else {
+   struct dma_fence_array *array;
+
+   array = dma_fence_array_create(count, fences,
+  dma_fence_context_alloc(1), 0,
+  false);
+   if (!array)
+   goto err_fences_put;
+
+   reservation_object_add_excl_fence(obj, &array->base);
+   dma_fence_put(&array->base);
+   }
+
+   return 0;
+
+err_fences_put:
+   while (count--)
+   dma_fence_put(fences[count]);
+   kfree(fences);
+   return -ENOMEM;
+}
+
 /**
  * amdgpu_gem_map_attach - &dma_buf_ops.attach implementation
  * @dma_buf: shared DMA buffer
@@ -219,16 +262,16 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
 
if (attach->dev->driver != adev->dev->driver) {
/*
-* Wait for all shared fences to complete before we switch to 
future
-* use of exclusive fence on this prime shared bo.
+* We only create shared fences for internal use, but importers
+* of the dmabuf rely on exclusive fences for implicitly
+* tracking write hazards. As any of the current fences may
+* correspond to a write, we need to convert all existing
+* fences on the reservation object into a single exclusive
+* fence.
 */
-   r = reservation_object_wait_timeout_rcu(bo->tbo.resv,
-   true, false,
-   MAX_SCHEDULE_TIMEOUT);
-   if (unlikely(r < 0)) {
-   DRM_DEBUG_PRIME("Fence wait failed: %li\n", r);
+   r = __reservation_object_make_exclusive(bo->tbo.resv);
+   if (r)
goto error_unreserve;
-   }
}
 
/* pin buffer into GTT */
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.19 57/64] drm/amdgpu: use spin_lock_irqsave to protect vm_manager.pasid_idr

[Sasha Levin]

From: Philip Yang 

[ Upstream commit 0a5f49cbf9d6ad3721c16f8a6d823363ea7a160f ]

amdgpu_vm_get_task_info is called from interrupt handler and sched timeout
workqueue, we should use irq version spin_lock to avoid deadlock.

Signed-off-by: Philip Yang 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 6a84526e20e09..49fe5084c53dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -3011,14 +3011,15 @@ void amdgpu_vm_get_task_info(struct amdgpu_device 
*adev, unsigned int pasid,
 struct amdgpu_task_info *task_info)
 {
struct amdgpu_vm *vm;
+   unsigned long flags;
 
-   spin_lock(&adev->vm_manager.pasid_lock);
+   spin_lock_irqsave(&adev->vm_manager.pasid_lock, flags);
 
vm = idr_find(&adev->vm_manager.pasid_idr, pasid);
if (vm)
*task_info = vm->task_info;
 
-   spin_unlock(&adev->vm_manager.pasid_lock);
+   spin_unlock_irqrestore(&adev->vm_manager.pasid_lock, flags);
 }
 
 /**
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.14 20/36] drm/sun4i: tcon: Prepare and enable TCON channel 0 clock at init

[Sasha Levin]

From: Paul Kocialkowski 

[ Upstream commit b14e945bda8ae227d1bf2b1837c0c4a61721cd1a ]

When initializing clocks, a reference to the TCON channel 0 clock is
obtained. However, the clock is never prepared and enabled later.
Switching from simplefb to DRM actually disables the clock (that was
usually configured by U-Boot) because of that.

On the V3s, this results in a hang when writing to some mixer registers
when switching over to DRM from simplefb.

Fix this by preparing and enabling the clock when initializing other
clocks. Waiting for sun4i_tcon_channel_enable to enable the clock is
apparently too late and results in the same mixer register access hang.

Signed-off-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190131132550.26355-1-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 7b909d814d38c..095bd6b4ae80d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -371,6 +371,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
dev_err(dev, "Couldn't get the TCON channel 0 clock\n");
return PTR_ERR(tcon->sclk0);
}
+   clk_prepare_enable(tcon->sclk0);
 
if (tcon->quirks->has_channel_1) {
tcon->sclk1 = devm_clk_get(dev, "tcon-ch1");
@@ -385,6 +386,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
 
 static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
 {
+   clk_disable_unprepare(tcon->sclk0);
clk_disable_unprepare(tcon->clk);
 }
 
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 4.9 06/19] drm/sun4i: tcon: Prepare and enable TCON channel 0 clock at init

[Sasha Levin]

From: Paul Kocialkowski 

[ Upstream commit b14e945bda8ae227d1bf2b1837c0c4a61721cd1a ]

When initializing clocks, a reference to the TCON channel 0 clock is
obtained. However, the clock is never prepared and enabled later.
Switching from simplefb to DRM actually disables the clock (that was
usually configured by U-Boot) because of that.

On the V3s, this results in a hang when writing to some mixer registers
when switching over to DRM from simplefb.

Fix this by preparing and enabling the clock when initializing other
clocks. Waiting for sun4i_tcon_channel_enable to enable the clock is
apparently too late and results in the same mixer register access hang.

Signed-off-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190131132550.26355-1-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index f2975a1525bee..2796fea70a427 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -327,6 +327,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
dev_err(dev, "Couldn't get the TCON channel 0 clock\n");
return PTR_ERR(tcon->sclk0);
}
+   clk_prepare_enable(tcon->sclk0);
 
if (tcon->quirks->has_channel_1) {
tcon->sclk1 = devm_clk_get(dev, "tcon-ch1");
@@ -341,6 +342,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
 
 static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
 {
+   clk_disable_unprepare(tcon->sclk0);
clk_disable_unprepare(tcon->clk);
 }
 
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework

[Andrew F. Davis]

On 2/27/19 3:55 PM, John Stultz wrote:
> On Wed, Feb 27, 2019 at 8:38 AM Andrew F. Davis  wrote:
>>
>> On 2/26/19 5:40 PM, John Stultz wrote:
>>> On Tue, Feb 26, 2019 at 11:21 AM John Stultz  wrote:
>>> I've updated the patches here:
>>> kernel: 
>>> https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
>>> userland: 
>>> https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
>>>
>>>
 I also realized some of Benajmin's error path improvements are going
 to be hard to fix w/ my current code, specifically having the allocate
 op do the allocation of the dma_heap_buffer (since we don't have a
 free op, if something fails creating the dmabuf fd in the core, we
 don't have a hook to release the dma_heap_buffer and heap private
 data).
>>>
>>
>> We can always add back the free op, the alternative is to have the heap
>> export the fd.
>>
>> I'm not sure either is needed though, when we
>> dma_buf_put(buffer->dmabuf) on the error path it should trigger the
>> release op, and that can cleanup the allocations in the heap.
> 
> Good point, but I worry that's a bit subtle.
> 
> Also doing the stuff with the helpers where we have to register a free
> callback is kind of ugly, and I personally like the symmetry of having
> free hooks if we have allocation hooks (even if the dmabuf release
> hook initiates the free call).
> 

I do like the symmetry of a free op, just not sure how or what should be
done in it that couldn't be taken care of in the dmabuf.release op..

>>> I also realized doing my development and testing against my
>>> hikey960-mainline-WIP branch, I accidentally folded in an ion hack I
>>> was using to reduce cache operations, so I'll need to undo that in the
>>> heap-helpers.c.  But at least we have a rough validation point for the
>>> design.
>>>
>>
>> Great! The details of the heap-helpers can always get fixed up at a
>> later point, validation of the core working is really good to hear.
>>
> 
> Let me know if you have any further feedback or changes to integrate.
> I've got to get back to some other work, but will try to take a
> cleanup pass in the next few days.
> 

I've got no other feedback right now. I'm guessing we will try a first
non-RFC sometime in the next couple weeks for the sake of getting Greg's
eyes on this, can see where it goes from there.

Thanks,
Andrew

> thanks
> -john
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/edid: If no preferred mode is found assume the first mode is preferred

[Adam Jackson]

On Wed, 2019-02-27 at 23:03 +0200, Ville Syrjälä wrote:

> So instead of putting this logic into the EDID parser I guess we
> could just put it into the i915 fixed mode code. But then I suppose
> we should also fix EDID_QUIRK_FIRST_DETAILED_PREFERRED (assuming it
> exists for a good reason).

I don't think it has any good reason to exist, tbh. The commit adding
it to xserver was for the Philips 107P5, which - being a CRT - would be
entirely expected to not have the preferred bit set. We should probably
have handled that instead by letting the "target a DPI near 96" logic
handle things.

- ajax

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109649] [bisected][raven] gfx ring timeout when running clover apps

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109649

--- Comment #3 from Jan Vesely  ---
The bug is still present in 5.0.0-rc8.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109692] deadlock occurs during GPU reset

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109692

--- Comment #17 from mikhail.v.gavri...@gmail.com ---
(In reply to Michel Dänzer from comment #16)
> The "suspicious RCU usage" looks related to the igb ethernet driver, not
> amdgpu. Quite likely it's already fixed in later 5.0-rc releases.

Thank Michel, I knew, but I forgot about it.
This can be fixed by revert commit 59361316afcb08569af21e1af83e89c7051c055a,
but kernel in this branch even after it still much buggy than from Linus tree.
For example when I launch Assassin Creed Odyssey errors begin out related to
file system after then the computer hangs.

[44188.533349] [ cut here ]
[44188.533840] kernel BUG at fs/inode.c:515!
[44188.533906] invalid opcode:  [#1] SMP NOPTI
[44188.533909] CPU: 2 PID: 114 Comm: kswapd0 Tainted: G C   
5.0.0-rc1-drm-next-kernel-3+ #3
[44188.533910] Hardware name: System manufacturer System Product Name/ROG STRIX
X470-I GAMING, BIOS 1103 11/16/2018
[44188.533915] RIP: 0010:clear_inode+0x7c/0x90
[44188.533917] Code: 2b a8 40 75 29 48 8b 83 e8 01 00 00 48 8d 93 e8 01 00 00
48 39 c2 75 18 48 c7 83 e0 00 00 00 60 00 00 00 5b 5d c3 0f 0b 0f 0b <0f> 0b 0f
0b 0f 0b 0f 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f
[44188.533918] RSP: 0018:b577c3effae8 EFLAGS: 00010216
[44188.533920] RAX: ff4d207cff51227d RBX: 8e4f4f12f208 RCX:
0007
[44188.533922] RDX: 8e4f4f12f5c8 RSI: 8e561c5ec020 RDI:
8e561c5eb2c0
[44188.533923] RBP: 8e4f4f12f440 R08: 283071cf739b R09:

[44188.533924] R10:  R11:  R12:
9b042f00
[44188.533925] R13: 8e4f4f120780 R14: 8e4f4f120810 R15:
8e4f4f12f208
[44188.533927] FS:  () GS:8e563ce0()
knlGS:
[44188.533928] CS:  0010 DS:  ES:  CR0: 80050033
[44188.533929] CR2: 7fcc2acc75d0 CR3: 0005437e CR4:
003406e0
[44188.533930] Call Trace:
[44188.533935]  proc_evict_inode+0x1d/0x50
[44188.533937]  evict+0xd0/0x1a0
[44188.533940]  __dentry_kill+0xdf/0x190
[44188.533942]  shrink_dentry_list+0x11c/0x330
[44188.533944]  prune_dcache_sb+0x53/0x80
[44188.533947]  super_cache_scan+0xf7/0x1b0
[44188.533951]  do_shrink_slab+0x18a/0x3d0
[44188.533954]  shrink_slab+0x170/0x2c0
[44188.533957]  shrink_node+0x177/0x460
[44188.533960]  balance_pgdat+0x2d5/0x560
[44188.533965]  kswapd+0x25b/0x540
[44188.533968]  ? finish_wait+0x90/0x90
[44188.533972]  kthread+0x108/0x140
[44188.533973]  ? balance_pgdat+0x560/0x560
[44188.533975]  ? kthread_park+0x90/0x90
[44188.533978]  ret_from_fork+0x27/0x50
[44188.533981] Modules linked in: snd_seq_dummy uinput fuse rfcomm xt_CHECKSUM
ipt_MASQUERADE tun bridge stp llc devlink nf_conntrack_netbios_ns
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack ebtable_nat ip6table_nat nf_nat_ipv6 ip6table_mangle ip6table_raw
ip6table_security iptable_nat nf_nat_ipv4 nf_nat iptable_mangle iptable_raw
iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set
nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables cmac bnep sunrpc
vfat fat arc4 r8822be(C) edac_mce_amd mac80211 kvm_amd kvm uvcvideo irqbypass
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_hda_codec_realtek
videobuf2_common snd_hda_codec_generic ledtrig_audio videodev
snd_hda_codec_hdmi snd_usb_audio joydev snd_hda_intel cfg80211 snd_hda_codec
media snd_usbmidi_lib btusb snd_hda_core snd_rawmidi btrtl snd_seq btbcm
btintel crct10dif_pclmul snd_hwdep bluetooth snd_seq_device crc32_pclmul
eeepc_wmi asus_wmi snd_pcm sparse_keymap video
[44188.534011]  wmi_bmof ghash_clmulni_intel snd_timer snd ccp ecdh_generic
sp5100_tco soundcore rfkill i2c_piix4 k10temp pcspkr pcc_cpufreq gpio_amdpt
gpio_generic acpi_cpufreq binfmt_misc hid_sony amdgpu ff_memless
hid_logitech_hidpp chash amd_iommu_v2 gpu_sched ttm drm_kms_helper drm
crc32c_intel igb nvme dca i2c_algo_bit hid_logitech_dj nvme_core wmi
pinctrl_amd
[44188.534028] ---[ end trace 85933fec4c138d6a ]---

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109692] deadlock occurs during GPU reset

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109692

--- Comment #18 from mikhail.v.gavri...@gmail.com ---
Created attachment 143497
  --> https://bugs.freedesktop.org/attachment.cgi?id=143497&action=edit
"amd-staging-drm-next" + commits  3741540, 222b5f0 and 5936131 is reverted

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers

[Hans de Goede]

Hi Heikki,

On 28-02-19 15:47, Heikki Krogerus wrote:

Hi Hans,

On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote:

Hi,

On 28-02-19 10:15, Heikki Krogerus wrote:





I've been thinking about this... Do we actually need to link the
correct drm_connector to the Type-C connector? Perhaps we can make
this work by just linking the GFX device to the Type-C connector.


What use is it to the kms driver if it gets an event there is a DP
hotplug with x lanes and orientation foo, if we are not telling it
on which DP port it is ? kms devices already have multiple DP ports
and more then one could be hooked-up to type-c connectors.


I was looking at this series. You walk trough every DP port in the
system when the DP alt mode driver broadcasts the event, but maybe
that's different. Never mind.


Right, my "simple / naive" solution simply tells the kms driver to
check all DP ports for connection state changes, similar to how
running "xrandr" under Xorg causes the kms driver to re-check the
connection status of all ports. Actually running xrandr under Xorg
after plugging in the cable, is how I did my initial DP over Type-C
testing on the GPD win.

But once we start passing extra-info, I believe the kms driver needs
to know to which connector that info belongs.




Well, I don't think we can deny the GPU driver (in this case) the
information that we have and that is relevant to it, just because it
seems difficult to deliver that information to the right location.


Right, but this does not require a tight-coupling. My original
proposal can do this if we pass a data struct with an identifier
for the DP port for which the event is to the notifier. I suggest using
a string for identifier, something like: ":00:02.0/DP-1" this
event struct could then also contain all the info we want to pass.


I do agree that we should not tie the objects (device entries)
representing these components in kernel together, but I assume that we
agree now that the connection between the two - the USB Type-C
connector and the DisplayPort - must be described somewhere, either in
firmware or build-in? So I guess we are talking implementation details
here, right?


Right.


If that is the case...

That string identifier you proposed would basically provide the
details about the connection, so if we know those details, we might as
well use "normal" ways to describe the connection and just extract
them in runtime in the function that our DP alt mode driver calls. I
think the connection has to be defined in i915 on CHT in any case.


Interesting, I think the connection should be described in the fwnode
for the fusb302 device for the CHT/GPD win case. Specifically I think
this fits well as a property of the dp altmode.


The DP alt mode driver should definitely not need to pass anything
else to the notifier other than handle to itself (actually, handle
straight to the port device would be better) as an identifier. The
notifier function needs to be the one that determines the actual
connection using that handle. Even if the target DP is described using
a string like you propose, then that string has to come from
somewhere, most likely from a device property. The notifier function
can just as well extract it, we don't need to pass it separately.

Here's my suggestion for function prototype:

int drm_typec_dp_notification(struct device *typec_port_dev,
   struct typec_displayport_data *data);


How about instead of the port_dev we pass in the altmode object and
we have a method to get the fwnode for the altmode? Then the
drm_typec_dp_notification() function can get info from that fwnode
to implement the connection finding you describe below:


So that function finds the connection between typec_port_dev and the
correct DP in runtime, possibly by letting i915 (or what ever GPU
driver) to do that. Once the function is done, it decrements any ref
counts that it incremented before returning.

That struct typec_displayport_data has all the information we have -
the current pin assignment from the Configure VDO, HPD IRQ from the
last Status Update, etc. - so it needs to be passed as payload to the
notifier.


Ack.

So I believe that this discussion ties into the discussion from the:
"[PATCH 0/2] platform/x86: intel_cht_int33fe: Start using software nodes"

Mail thread. As discussed there I agree that adding a usb_connector
child fwnode to the fwnode for the fusb302 to describe things like
sink- and source-pdos is a good idea.

Our last few mails were discussing describing supported alt-modes on
the connector by adding altmode child-nodes to the usb_connector node.

I think it is best to continue that discussion here, as the 2 discussions
tie into one another.

So my last proposal in that thread was adding the following to:

Documentation/devicetree/bindings/connector/usb-connector.txt:

"""
Optionally an "usb-c-connector" can have child nodes, describing
supported alt-modes.

Required properties for usb-c-connector

[PATCH 2/7] drm/lease: Drop recursive leads checks

[Daniel Vetter]

We disallow subleasing, so no point checking whether the master holds
all the leases - it will.

Spotted while typing exhaustive igt coverage for all these corner
cases.

Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_lease.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 1176d814cf7f..cce5d9dd52ff 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -220,8 +220,6 @@ static struct drm_master *drm_lease_create(struct 
drm_master *lessor, struct idr
error = 0;
if (!idr_find(&dev->mode_config.object_idr, object))
error = -ENOENT;
-   else if (!_drm_lease_held_master(lessor, object))
-   error = -EACCES;
else if (_drm_has_leased(lessor, object))
error = -EBUSY;
 
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] drm/leases: Drop object_id validation for negative ids

[Daniel Vetter]

Not exactly sure what's the aim here, but the canonical nil object has
id == 0, we don't use negative object ids for anything. Plus all
object_id are valided by the object_idr, there's nothing we need to do
on top of that ENOENT check a bit further down.

Spotted while typing exhaustive igt coverage for all these
corner-cases.

Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_lease.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 603b0bd9c5ce..1176d814cf7f 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -403,11 +403,6 @@ static int fill_object_idr(struct drm_device *dev,
/* step one - get references to all the mode objects
   and check for validity. */
for (o = 0; o < object_count; o++) {
-   if ((int) object_ids[o] < 0) {
-   ret = -EINVAL;
-   goto out_free_objects;
-   }
-
objects[o] = drm_mode_object_find(dev, lessor_priv,
  object_ids[o],
  DRM_MODE_OBJECT_ANY);
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/7] some cleanups and uapi clarification for leases

[Daniel Vetter]

[resend with the right mailing lists]

Hi all,

Nothing too major, only things I did find in all my igt test extending for
drm lease is some corner cases around implicit planes and atomic target
crtcs. Review and comments very much appreciated.

Cheers, Daniel

Test-with: 20190228141918.26043-1-daniel.vet...@ffwll.ch

Daniel Vetter (7):
  drm/leases: Drop object_id validation for negative ids
  drm/lease: Drop recursive leads checks
  drm/leases: Don't init to 0 in drm_master_create
  drm/lease: Check for lessor outside of locks
  drm/lease: Make sure implicit planes are leased
  drm/atomic: Wire file_priv through for property changes
  drm/atomic: -EACCESS for lease-denied crtc lookup

 drivers/gpu/drm/drm_atomic_uapi.c   | 36 +++-
 drivers/gpu/drm/drm_auth.c  |  2 --
 drivers/gpu/drm/drm_crtc.c  |  4 
 drivers/gpu/drm/drm_crtc_internal.h |  1 +
 drivers/gpu/drm/drm_lease.c | 13 +++--
 drivers/gpu/drm/drm_mode_object.c   |  5 +++--
 drivers/gpu/drm/drm_plane.c |  8 
 7 files changed, 42 insertions(+), 27 deletions(-)

-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] drm/lease: Make sure implicit planes are leased

[Daniel Vetter]

If userspace doesn't enable universal planes, then we automatically
add the primary and cursor planes. But for universal userspace there's
no such check (and maybe we only want to give the lessee one plane,
maybe not even the primary one), hence we need to check for the
implied plane.

v2: don't forget setcrtc ioctl.

v3: Still allow disabling of the crtc in SETCRTC.

Cc: sta...@vger.kernel.org
Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c  | 4 
 drivers/gpu/drm/drm_plane.c | 8 
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7dabbaf033a1..790ba5941954 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -559,6 +559,10 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
 
plane = crtc->primary;
 
+   /* allow disabling with the primary plane leased */
+   if (crtc_req->mode_valid && !drm_lease_held(file_priv, plane->base.id))
+   return -EACCES;
+
mutex_lock(&crtc->dev->mode_config.mutex);
DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx,
   DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 4cfb56893b7f..d6ad60ab0d38 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -960,6 +960,11 @@ static int drm_mode_cursor_common(struct drm_device *dev,
if (ret)
goto out;
 
+   if (!drm_lease_held(file_priv, crtc->cursor->base.id)) {
+   ret = -EACCES;
+   goto out;
+   }
+
ret = drm_mode_cursor_universal(crtc, req, file_priv, &ctx);
goto out;
}
@@ -1062,6 +1067,9 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
 
plane = crtc->primary;
 
+   if (!drm_lease_held(file_priv, plane->base.id))
+   return -EACCES;
+
if (crtc->funcs->page_flip_target) {
u32 current_vblank;
int r;
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/7] drm/leases: Don't init to 0 in drm_master_create

[Daniel Vetter]

We kzalloc.

Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_auth.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 1669c42c40ed..bcf0a5a1018f 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -109,8 +109,6 @@ struct drm_master *drm_master_create(struct drm_device *dev)
master->dev = dev;
 
/* initialize the tree of output resource lessees */
-   master->lessor = NULL;
-   master->lessee_id = 0;
INIT_LIST_HEAD(&master->lessees);
INIT_LIST_HEAD(&master->lessee_list);
idr_init(&master->leases);
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/7] drm/atomic: Wire file_priv through for property changes

[Daniel Vetter]

We need this to make sure lessees can only connect their
plane/connectors to crtc objects they own. And note that this is
irrespective of whether the lessor is atomic or not, lessor cannot
prevent lessees from enabling atomic.

Cc: sta...@vger.kernel.org
Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_uapi.c   | 32 +++-
 drivers/gpu/drm/drm_crtc_internal.h |  1 +
 drivers/gpu/drm/drm_mode_object.c   |  5 +++--
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 4eb81f10bc54..f0dbfeb00926 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -512,8 +512,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
 }
 
 static int drm_atomic_plane_set_property(struct drm_plane *plane,
-   struct drm_plane_state *state, struct drm_property *property,
-   uint64_t val)
+   struct drm_plane_state *state, struct drm_file *file_priv,
+   struct drm_property *property, uint64_t val)
 {
struct drm_device *dev = plane->dev;
struct drm_mode_config *config = &dev->mode_config;
@@ -521,7 +521,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
int ret;
 
if (property == config->prop_fb_id) {
-   struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
+   struct drm_framebuffer *fb;
+   fb = drm_framebuffer_lookup(dev, file_priv, val);
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
drm_framebuffer_put(fb);
@@ -537,7 +538,7 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
return -EINVAL;
 
} else if (property == config->prop_crtc_id) {
-   struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
+   struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
return drm_atomic_set_crtc_for_plane(state, crtc);
} else if (property == config->prop_crtc_x) {
state->crtc_x = U642I64(val);
@@ -681,14 +682,14 @@ static int drm_atomic_set_writeback_fb_for_connector(
 }
 
 static int drm_atomic_connector_set_property(struct drm_connector *connector,
-   struct drm_connector_state *state, struct drm_property 
*property,
-   uint64_t val)
+   struct drm_connector_state *state, struct drm_file *file_priv,
+   struct drm_property *property, uint64_t val)
 {
struct drm_device *dev = connector->dev;
struct drm_mode_config *config = &dev->mode_config;
 
if (property == config->prop_crtc_id) {
-   struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
+   struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
return drm_atomic_set_crtc_for_connector(state, crtc);
} else if (property == config->dpms_property) {
/* setting DPMS property requires special handling, which
@@ -749,8 +750,10 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
-   struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
-   int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
+   struct drm_framebuffer *fb;
+   int ret;
+   fb = drm_framebuffer_lookup(dev, file_priv, val);
+   ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
if (fb)
drm_framebuffer_put(fb);
return ret;
@@ -947,6 +950,7 @@ int drm_atomic_connector_commit_dpms(struct 
drm_atomic_state *state,
 }
 
 int drm_atomic_set_property(struct drm_atomic_state *state,
+   struct drm_file *file_priv,
struct drm_mode_object *obj,
struct drm_property *prop,
uint64_t prop_value)
@@ -969,7 +973,8 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
}
 
ret = drm_atomic_connector_set_property(connector,
-   connector_state, prop, prop_value);
+   connector_state, file_priv,
+   prop, prop_value);
break;
}
case DRM_MODE_OBJECT_CRTC: {
@@ -997,7 +1002,8 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
}
 
ret = drm_atomic_plane_set_property(plane,
-   plane_state, prop, prop_value);
+   plane_state, file_priv,
+   prop, prop_value);
  

[PATCH 4/7] drm/lease: Check for lessor outside of locks

[Daniel Vetter]

The lessor is invariant over a lifetime of a lease, we don't have to
grab any locks for that. Speeds up the common case of not being a lease.

Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_lease.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index cce5d9dd52ff..694ff363a90b 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -111,7 +111,7 @@ static bool _drm_has_leased(struct drm_master *master, int 
id)
  */
 bool _drm_lease_held(struct drm_file *file_priv, int id)
 {
-   if (file_priv == NULL || file_priv->master == NULL)
+   if (!file_priv || !file_priv->master)
return true;
 
return _drm_lease_held_master(file_priv->master, id);
@@ -133,7 +133,7 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
struct drm_master *master;
bool ret;
 
-   if (file_priv == NULL || file_priv->master == NULL)
+   if (!file_priv || !file_priv->master || !file_priv->master->lessor)
return true;
 
master = file_priv->master;
@@ -159,7 +159,7 @@ uint32_t drm_lease_filter_crtcs(struct drm_file *file_priv, 
uint32_t crtcs_in)
int count_in, count_out;
uint32_t crtcs_out = 0;
 
-   if (file_priv == NULL || file_priv->master == NULL)
+   if (!file_priv || !file_priv->master || !file_priv->master->lessor)
return crtcs_in;
 
master = file_priv->master;
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/7] drm/atomic: -EACCESS for lease-denied crtc lookup

[Daniel Vetter]

With the previous patch drm_crtc_find will return NULL when the crtc
isn't in our lease, which will then disable the plane/connector. No
longer an issue since the lessor can't escape their lease terms
anymore, but not quite great semantics yet either.

Catch this and return -EACCES, so that at least evil test cases have a
better chance of making sure the kernel works correctly.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index f0dbfeb00926..6687215cc188 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -539,6 +539,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
 
} else if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
+   if (val && !crtc)
+   return -EACCES;
return drm_atomic_set_crtc_for_plane(state, crtc);
} else if (property == config->prop_crtc_x) {
state->crtc_x = U642I64(val);
@@ -690,6 +692,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 
if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
+   if (val && !crtc)
+   return -EACCES;
return drm_atomic_set_crtc_for_connector(state, crtc);
} else if (property == config->dpms_property) {
/* setting DPMS property requires special handling, which
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: big conflict in drm-tip (amdgpu)

[Alex Deucher]

On Thu, Feb 28, 2019 at 4:54 AM Chris Wilson  wrote:
>
> Quoting Daniel Vetter (2019-02-28 09:49:51)
> > On Thu, Feb 28, 2019 at 5:30 AM Dave Airlie  wrote:
> > >
> > > I merged some fixes into drm-fixes, pushed it out, then saw tip
> > > breaking, but I'm needed elsewhere, so if anyone can fix tip up or
> > > tell me why I got a super messy commit, I'll owe you.
> >
> > Chris already patched it up it seems, I guess someone should
> > double-check it's reasonable. For the future might be good if amd
> > trees push into drm-tip and/or linux-next beforehand, for early
> > warning and testing of the merge resolution. Ideally both I'd say.
> > It's the biggest driver we have after all :-)
>
> I took a conservative approach, and just verified that the code still
> compiled. I expect the vrr fakery was reverted in the process, but also
> expect that new code will be flowing from amdgpu in their next update
> anyway.

Can you point me to the conflict?  I'll take a look.  Sorry for the
noise.  The VRR fix for 5.0 was a backport since the code changed
slightly between 5.0 and 5.1.  We have the same fix against 5.1 as
well if that is what the problem was.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel

[Jagan Teki]

Hi Thierry,

On Tue, Feb 19, 2019 at 1:57 AM Sam Ravnborg  wrote:
>
> Hi Thierry
>
> > Pleas let me know if you any further comments on this?
> No further comments from my side, and I consider it
> ready to apply.

Would you please pick this?

Jagan.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: big conflict in drm-tip (amdgpu)

[Chris Wilson]

Quoting Alex Deucher (2019-02-28 17:25:41)
> On Thu, Feb 28, 2019 at 4:54 AM Chris Wilson  wrote:
> >
> > Quoting Daniel Vetter (2019-02-28 09:49:51)
> > > On Thu, Feb 28, 2019 at 5:30 AM Dave Airlie  wrote:
> > > >
> > > > I merged some fixes into drm-fixes, pushed it out, then saw tip
> > > > breaking, but I'm needed elsewhere, so if anyone can fix tip up or
> > > > tell me why I got a super messy commit, I'll owe you.
> > >
> > > Chris already patched it up it seems, I guess someone should
> > > double-check it's reasonable. For the future might be good if amd
> > > trees push into drm-tip and/or linux-next beforehand, for early
> > > warning and testing of the merge resolution. Ideally both I'd say.
> > > It's the biggest driver we have after all :-)
> >
> > I took a conservative approach, and just verified that the code still
> > compiled. I expect the vrr fakery was reverted in the process, but also
> > expect that new code will be flowing from amdgpu in their next update
> > anyway.
> 
> Can you point me to the conflict?  I'll take a look.  Sorry for the
> noise.  The VRR fix for 5.0 was a backport since the code changed
> slightly between 5.0 and 5.1.  We have the same fix against 5.1 as
> well if that is what the problem was.

https://cgit.freedesktop.org/drm/drm-tip/commit/?h=rerere-cache&id=660b640f5938ce08c95d75bd7a20182a92e1467f
see amdgpu_dm_commit_planes()

Presentation in rerere-cache is very weird, there's probably a better
way to review the merge choice&resolution
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v4 08/17] kunit: test: add support for test abort

[Stephen Boyd]

Quoting Brendan Higgins (2019-02-28 01:03:24)
> On Tue, Feb 26, 2019 at 12:35 PM Stephen Boyd  wrote:
> >
> > when they need to abort and then the test runner would detect that error
> > via the return value from the 'run test' function. That would be a more
> > direct approach, but also more verbose than a single KUNIT_ASSERT()
> > line. It would be more kernel idiomatic too because the control flow
> 
> Yeah, I was intentionally going against that idiom. I think that idiom
> makes test logic more complicated than it needs to be, especially if
> the assertion failure happens in a helper function; then you have to
> pass that error all the way back up. It is important that test code
> should be as simple as possible to the point of being immediately
> obviously correct at first glance because there are no tests for
> tests.
> 
> The idea with assertions is that you use them to state all the
> preconditions for your test. Logically speaking, these are the
> premises of the test case, so if a premise isn't true, there is no
> point in continuing the test case because there are no conclusions
> that can be drawn without the premises. Whereas, the expectation is
> the thing you are trying to prove. It is not used universally in
> x-unit style test frameworks, but I really like it as a convention.
> You could still express the idea of a premise using the above idiom,
> but I think KUNIT_ASSERT_* states the intended idea perfectly.

Fair enough. It would be great if these sorts of things were described
in the commit text.

Is the assumption that things like held locks and refcounted elements
won't exist when one of these assertions is made? It sounds like some of
the cleanup logic could be fairly complicated if a helper function
changes some state and then an assert fails and we have to unwind all
the state from a corrupt location. A similar problem exists for a test
timeout too. How do we get back to a sane state if the test locks up for
a long time? Just don't try?

> 
> > isn't hidden inside a macro and it isn't intimately connected with
> > kthreads and completions.
> 
> Yeah, I wasn't a fan of that myself, but it was broadly available. My
> previous version (still the architecture specific version for UML, not
> in this patchset though) relies on UML_LONGJMP, but is obviously only
> works on UML. A number of people wanted support for other
> architectures. Rob and Luis specifically wanted me to provide a
> version of abort that would work on any architecture, even if it only
> had reduced functionality; I thought this fit the bill okay.

Ok.

> 
> >
> > >
> > > diff --git a/kunit/test.c b/kunit/test.c
> > > index d18c50d5ed671..6e5244642ab07 100644
> > > --- a/kunit/test.c
> > > +++ b/kunit/test.c
> > [...]
> > > +
> > > +static void kunit_generic_throw(struct kunit_try_catch *try_catch)
> > > +{
> > > +   try_catch->context.try_result = -EFAULT;
> > > +   complete_and_exit(try_catch->context.try_completion, -EFAULT);
> > > +}
> > > +
> > > +static int kunit_generic_run_threadfn_adapter(void *data)
> > > +{
> > > +   struct kunit_try_catch *try_catch = data;
> > >
> > > +   try_catch->try(&try_catch->context);
> > > +
> > > +   complete_and_exit(try_catch->context.try_completion, 0);
> >
> > The exit code doesn't matter, right? If so, it might be clearer to just
> > return 0 from this function because kthreads exit themselves as far as I
> > recall.
> 
> You mean complete and then return?

Yes. I was confused for a minute because I thought the exit code was
checked, but it isn't. Instead, the try_catch->context.try_result is
where the test result goes, so calling exit explicitly doesn't seem to
be important here, but it is important in the throw case.

> 
> >
> > > +   else if (exit_code)
> > > +   kunit_err(test, "Unknown error: %d", exit_code);
> > > +}
> > > +
> > > +void kunit_generic_try_catch_init(struct kunit_try_catch *try_catch)
> > > +{
> > > +   try_catch->run = kunit_generic_run_try_catch;
> >
> > Is the idea that 'run' would be anything besides
> > 'kunit_generic_run_try_catch'? If it isn't going to be different, then
> 
> Yeah, it can be overridden with an architecture specific version.
> 
> > maybe it's simpler to just have a function like
> > kunit_generic_run_try_catch() that is called by the unit tests instead
> > of having to write 'try_catch->run(try_catch)' and indirect for the
> > basic case. Maybe I've missed the point entirely though and this is all
> > scaffolding for more complicated exception handling later on.
> 
> Yeah, the idea is that different architectures can override exception
> handling with their own implementation. This is just the generic one.
> For example, UML has one that doesn't depend on kthreads or
> completions; the UML version also allows recovery from some segfault
> conditions.

Ok, got it. It may still be nice to have a wrapper or macro for that
try_catch->run(try_catch) statement so we don't have to know that a
try_ca

Re: [PATCH 0/7] add LCD support for SAM9X60

[Sam Ravnborg]

Hi Claudiu

On Wed, Feb 27, 2019 at 04:24:11PM +, claudiu.bez...@microchip.com wrote:
> From: Claudiu Beznea 
> 
> Hi,
> 
> These patches adds support for SAM9X60's LCD controller.
Can you elaborate a little more which chips that are relevant.
To be able to look into the right data-sheet, while reviewing.
Link to data-sheet would be nice too.

Thanks in advance,
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] dt-bindings: gpu: add bindings for the ARM Mali Bifrost GPU

[Rob Herring]

On Tue, Feb 12, 2019 at 05:38:38PM +0100, Neil Armstrong wrote:
> Add the bindings for the Bifrost family of ARM Mali GPUs.
> 
> The Bifrost GPU architecture is similar to the Midgard family,
> but with a different Shader Core & Execution Engine structures.
> 
> Bindings are based on the Midgard family bindings, but the inner
> architectural changes makes it a separate family needing separate
> bindings.
> 
> The Bifrost GPUs are present in a number of recent SoCs, like the
> Amlogic G12A Family, and many other vendors.
> The Amlogic vendor specific compatible is added to handle the
> specific IP integration differences and dependencies.
> 
> Signed-off-by: Neil Armstrong 
> ---
> Changes since v1:
> - adding missing G31 and G52
> - fixed example
> 
>  .../bindings/gpu/arm,mali-bifrost.txt | 96 +++
>  1 file changed, 96 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt 
> b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
> new file mode 100644
> index ..04a1d63ee578
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
> @@ -0,0 +1,96 @@
> +ARM Mali Bifrost GPU
> +
> +
> +Required properties:
> +
> +- compatible :
> +  * Must contain one of the following:
> ++ "arm,mali-g31"
> ++ "arm,mali-g51"
> ++ "arm,mali-g52"
> ++ "arm,mali-g71"
> ++ "arm,mali-g72"
> ++ "arm,mali-g76"

Given that these flavors are all fully disoverable, we could probably 
just have 1 compatible here. It's not often that I suggest this. :)

We allowed this with vivante as all the version and feature information 
is discoverable.

> +  * which must be preceded by one of the following vendor specifics:
> ++ "amlogic,meson-g12a-mali"

We should keep these for any integration differences though.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/5] drm: Add PSR helpers

[Sean Paul]

From: Sean Paul 

Hey all,
Here's a set to add some helpers for drivers looking to implement PSR.
I've converted rockchip as a proof of concept, and will likely do the
work for msm dsi sometime in the coming months.

PTAL,

Sean


Sean Paul (5):
  drm: Add helpers to kick off PSR enable/disable
  drm/rockchip: Check for fast link training before enabling psr
  drm/rockchip: Use the helpers for PSR
  drm/rockchip: Don't fully disable vop on PSR
  drm/rockchip: Use drm_atomic_helper_commit_tail_rpm

 Documentation/gpu/drm-kms-helpers.rst |   9 +
 drivers/gpu/drm/Makefile  |   2 +-
 .../drm/bridge/analogix/analogix_dp_core.c| 206 +++
 .../drm/bridge/analogix/analogix_dp_core.h|   1 -
 drivers/gpu/drm/drm_atomic_helper.c   |  34 ++
 drivers/gpu/drm/drm_atomic_uapi.c |   5 +
 drivers/gpu/drm/drm_fb_helper.c   |   9 +
 drivers/gpu/drm/drm_framebuffer.c |  18 +
 drivers/gpu/drm/drm_psr_helper.c  | 343 ++
 drivers/gpu/drm/rockchip/Makefile |   3 +-
 .../gpu/drm/rockchip/analogix_dp-rockchip.c   |  70 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  12 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  37 +-
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c   | 290 ---
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h   |  30 --
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |  59 ++-
 include/drm/bridge/analogix_dp.h  |   4 +-
 include/drm/drm_connector.h   |  22 ++
 include/drm/drm_crtc.h|  11 +
 include/drm/drm_mode_config.h |   6 +
 include/drm/drm_psr_helper.h  |  24 ++
 21 files changed, 699 insertions(+), 496 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_psr_helper.c
 delete mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
 delete mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h
 create mode 100644 include/drm/drm_psr_helper.h

-- 
Sean Paul, Software Engineer, Google / Chromium OS

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/5] drm: Add helpers to kick off PSR enable/disable

[Sean Paul]

From: Sean Paul 

This patch adds a new drm helper library to help drivers implement
PSR. Drivers choosing to use it will register connectors with
PSR-capable displays connected and will receive callbacks when it's time
to enter or exit PSR.

In its current form, it has a timer which will trigger after a
driver-specified amount of inactivity. When the timer triggers, the
helpers will save the current atomic state and issue a new state which
has the PSR-enabled pipes turned off. On the next update, the drm core
will poke the PSR helpers to restore the saved state to the driver before
servicing said update.

From the driver's perspective, this works like a regular disable/enable
cycle. The driver need only check the 'psr_transition' state in
connector_state and keep the panel turned on when in .disable(), while
everything else will cycle off as normal. If drivers want more control,
they can use the psr_transition state to enter a low-power state to
minimize PSR exit time.

While this carries the PSR moniker, it is not specific to the
DisplayPort technology. This can be used for power savings with other
types of self refresh, such as MIPI command mode.

Cc: Zain Wang 
Cc: Tomasz Figa 
Signed-off-by: Sean Paul 
---
 Documentation/gpu/drm-kms-helpers.rst |   9 +
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_atomic_helper.c   |  34 +++
 drivers/gpu/drm/drm_atomic_uapi.c |   5 +
 drivers/gpu/drm/drm_fb_helper.c   |   9 +
 drivers/gpu/drm/drm_framebuffer.c |  18 ++
 drivers/gpu/drm/drm_psr_helper.c  | 343 ++
 include/drm/drm_connector.h   |  22 ++
 include/drm/drm_crtc.h|  11 +
 include/drm/drm_mode_config.h |   6 +
 include/drm/drm_psr_helper.h  |  24 ++
 11 files changed, 482 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_psr_helper.c
 create mode 100644 include/drm/drm_psr_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 17ca7f8bf3d3..d218a113bd52 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -107,6 +107,15 @@ fbdev Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c
:export:
 
+Panel Self Refresh Helper Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_psr_helper.c
+   :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_psr_helper.c
+   :export:
+
 Framebuffer CMA Helper Functions Reference
 ==
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 1ac55c65eac0..bff80fb946c7 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -19,7 +19,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
-   drm_atomic_uapi.o
+   drm_atomic_uapi.o drm_psr_helper.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c53ecbd9abdd..f5284d55f170 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2746,6 +2747,10 @@ int drm_atomic_helper_update_plane(struct drm_plane 
*plane,
struct drm_plane_state *plane_state;
int ret = 0;
 
+   ret = drm_psr_helper_flush(plane->dev, ctx);
+   if (ret)
+   return ret;
+
state = drm_atomic_state_alloc(plane->dev);
if (!state)
return -ENOMEM;
@@ -2797,6 +2802,10 @@ int drm_atomic_helper_disable_plane(struct drm_plane 
*plane,
struct drm_plane_state *plane_state;
int ret = 0;
 
+   ret = drm_psr_helper_flush(plane->dev, ctx);
+   if (ret)
+   return ret;
+
state = drm_atomic_state_alloc(plane->dev);
if (!state)
return -ENOMEM;
@@ -2934,11 +2943,16 @@ int drm_atomic_helper_set_config(struct drm_mode_set 
*set,
struct drm_crtc *crtc = set->crtc;
int ret = 0;
 
+   ret = drm_psr_helper_flush(crtc->dev, ctx);
+   if (ret)
+   return ret;
+
state = drm_atomic_state_alloc(crtc->dev);
if (!state)
return -ENOMEM;
 
state->acquire_ctx = ctx;
+
ret = __drm_atomic_helper_set_config(set, state);
if (ret != 0)
goto fail;
@@ -3139,6 +3153,10 @@ void drm_atomic_helper_shutdown(struct drm_device *dev)
 
DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
 
+   ret = drm_psr_helper_flush(dev, &ctx);
+   if (ret)
+   DRM_ERROR("PSR flush during shutdown failed with %i\n", ret);
+
ret =

[PATCH 2/5] drm/rockchip: Check for fast link training before enabling psr

[Sean Paul]

From: Sean Paul 

Once we start shutting off the link during PSR, we're going to want fast
training to work. If the display doesn't support fast training, don't
enable psr.

Cc: Zain Wang 
Cc: Tomasz Figa 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 225f5e5dd69b..af34554a5a02 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1040,16 +1040,17 @@ static int analogix_dp_commit(struct analogix_dp_device 
*dp)
if (ret)
return ret;
 
+   /* Check whether panel supports fast training */
+   ret = analogix_dp_fast_link_train_detection(dp);
+   if (ret)
+   dp->psr_enable = false;
+
if (dp->psr_enable) {
ret = analogix_dp_enable_sink_psr(dp);
if (ret)
return ret;
}
 
-   /* Check whether panel supports fast training */
-   ret =  analogix_dp_fast_link_train_detection(dp);
-   if (ret)
-   dp->psr_enable = false;
 
return ret;
 }
-- 
Sean Paul, Software Engineer, Google / Chromium OS

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/5] drm/rockchip: Use the helpers for PSR

[Sean Paul]

From: Sean Paul 

Instead of rolling our own implementation for tracking when PSR should
be [in]active, use the PSR helpers to do the heavy lifting.

Cc: Zain Wang 
Cc: Tomasz Figa 
Signed-off-by: Sean Paul 
---
 .../drm/bridge/analogix/analogix_dp_core.c| 205 -
 .../drm/bridge/analogix/analogix_dp_core.h|   1 -
 drivers/gpu/drm/rockchip/Makefile |   3 +-
 .../gpu/drm/rockchip/analogix_dp-rockchip.c   |  70 ++---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  12 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  16 -
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c   | 290 --
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h   |  30 --
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |  21 +-
 include/drm/bridge/analogix_dp.h  |   4 +-
 10 files changed, 177 insertions(+), 475 deletions(-)
 delete mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
 delete mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index af34554a5a02..de98cb3570be 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -106,63 +107,19 @@ static int analogix_dp_detect_hpd(struct 
analogix_dp_device *dp)
return 0;
 }
 
-int analogix_dp_psr_enabled(struct analogix_dp_device *dp)
+bool analogix_dp_in_psr_transition(struct analogix_dp_device *dp)
 {
+   struct drm_mode_config *config = &dp->drm_dev->mode_config;
 
-   return dp->psr_enable;
-}
-EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
+   /* This should only be called from the encoder enable/disable */
+   if (WARN_ON(!drm_modeset_is_locked(&config->connection_mutex)))
+   return false;
 
-int analogix_dp_enable_psr(struct analogix_dp_device *dp)
-{
-   struct edp_vsc_psr psr_vsc;
-
-   if (!dp->psr_enable)
-   return 0;
-
-   /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
-   memset(&psr_vsc, 0, sizeof(psr_vsc));
-   psr_vsc.sdp_header.HB0 = 0;
-   psr_vsc.sdp_header.HB1 = 0x7;
-   psr_vsc.sdp_header.HB2 = 0x2;
-   psr_vsc.sdp_header.HB3 = 0x8;
-
-   psr_vsc.DB0 = 0;
-   psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
-
-   return analogix_dp_send_psr_spd(dp, &psr_vsc, true);
+   return dp->connector.state->psr_transition;
 }
-EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
+EXPORT_SYMBOL_GPL(analogix_dp_in_psr_transition);
 
-int analogix_dp_disable_psr(struct analogix_dp_device *dp)
-{
-   struct edp_vsc_psr psr_vsc;
-   int ret;
-
-   if (!dp->psr_enable)
-   return 0;
-
-   /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
-   memset(&psr_vsc, 0, sizeof(psr_vsc));
-   psr_vsc.sdp_header.HB0 = 0;
-   psr_vsc.sdp_header.HB1 = 0x7;
-   psr_vsc.sdp_header.HB2 = 0x2;
-   psr_vsc.sdp_header.HB3 = 0x8;
-
-   psr_vsc.DB0 = 0;
-   psr_vsc.DB1 = 0;
-
-   ret = drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
-   if (ret != 1) {
-   dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
-   return ret;
-   }
-
-   return analogix_dp_send_psr_spd(dp, &psr_vsc, false);
-}
-EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
-
-static int analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
+static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
 {
unsigned char psr_version;
int ret;
@@ -170,14 +127,11 @@ static int analogix_dp_detect_sink_psr(struct 
analogix_dp_device *dp)
ret = drm_dp_dpcd_readb(&dp->aux, DP_PSR_SUPPORT, &psr_version);
if (ret != 1) {
dev_err(dp->dev, "failed to get PSR version, disable it\n");
-   return ret;
+   return false;
}
 
dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
-
-   dp->psr_enable = (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
-
-   return 0;
+   return psr_version & DP_PSR_IS_SUPPORTED;
 }
 
 static int analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
@@ -200,7 +154,7 @@ static int analogix_dp_enable_sink_psr(struct 
analogix_dp_device *dp)
}
 
/* Main-Link transmitter remains active during PSR active states */
-   psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
+   psr_en = DP_PSR_CRC_VERIFICATION;
ret = drm_dp_dpcd_writeb(&dp->aux, DP_PSR_EN_CFG, psr_en);
if (ret != 1) {
dev_err(dp->dev, "failed to set panel psr\n");
@@ -208,8 +162,7 @@ static int analogix_dp_enable_sink_psr(struct 
analogix_dp_device *dp)
}
 
/* Enable psr function */
-   psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
-DP_PSR_CRC_VERIFICATION;
+   psr_en = DP_PSR_ENABLE | DP_PSR_CR

[PATCH 5/5] drm/rockchip: Use drm_atomic_helper_commit_tail_rpm

[Sean Paul]

From: Sean Paul 

Now that we use the drm psr helpers, we no longer need to hand-roll our
atomic_commit_tail implementation. So use the helper

Cc: Zain Wang 
Cc: Tomasz Figa 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 21 +
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 7e121875e3c9..75198df2b022 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -115,27 +115,8 @@ rockchip_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return ERR_PTR(ret);
 }
 
-static void
-rockchip_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
-{
-   struct drm_device *dev = old_state->dev;
-
-   drm_atomic_helper_commit_modeset_disables(dev, old_state);
-
-   drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
-   drm_atomic_helper_commit_planes(dev, old_state,
-   DRM_PLANE_COMMIT_ACTIVE_ONLY);
-
-   drm_atomic_helper_commit_hw_done(old_state);
-
-   drm_atomic_helper_wait_for_vblanks(dev, old_state);
-
-   drm_atomic_helper_cleanup_planes(dev, old_state);
-}
-
 static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers 
= {
-   .atomic_commit_tail = rockchip_atomic_helper_commit_tail_rpm,
+   .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
 };
 
 static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
-- 
Sean Paul, Software Engineer, Google / Chromium OS

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] drm/rockchip: Don't fully disable vop on PSR

[Sean Paul]

From: Sean Paul 

Instead of fully disabling and re-enabling the vop on PSR transitions,
only disable the active windows. This will speed up PSR exits
substantially and is still a power-savings win.

This patch integrates portions of Zain's patch from here:
https://patchwork.kernel.org/patch/9615063/

Cc: Zain Wang 
Cc: Tomasz Figa 
Cc: Kristian H. Kristensen 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 38 +
 1 file changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 66c99d57e62a..025cfb55ffe2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -131,6 +131,7 @@ struct vop {
bool is_enabled;
 
struct completion dsp_hold_completion;
+   unsigned int win_enabled;
 
/* protected by dev->event_lock */
struct drm_pending_vblank_event *event;
@@ -591,6 +592,7 @@ static int vop_enable(struct drm_crtc *crtc, struct 
drm_crtc_state *old_state)
const struct vop_win_data *win = vop_win->data;
 
VOP_WIN_SET(vop, win, enable, 0);
+   vop->win_enabled &= ~BIT(i);
}
}
spin_unlock(&vop->reg_lock);
@@ -621,6 +623,25 @@ static int vop_enable(struct drm_crtc *crtc, struct 
drm_crtc_state *old_state)
return ret;
 }
 
+static void rockchip_drm_set_win_enabled(struct drm_crtc *crtc, bool enabled)
+{
+struct vop *vop = to_vop(crtc);
+int i;
+
+spin_lock(&vop->reg_lock);
+
+for (i = 0; i < vop->data->win_size; i++) {
+struct vop_win *vop_win = &vop->win[i];
+const struct vop_win_data *win = vop_win->data;
+
+VOP_WIN_SET(vop, win, enable,
+enabled && (vop->win_enabled & BIT(i)));
+}
+vop_cfg_done(vop);
+
+spin_unlock(&vop->reg_lock);
+}
+
 static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
 {
@@ -628,9 +649,15 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
 
WARN_ON(vop->event);
 
+   if (crtc->state->psr_transition)
+   rockchip_drm_set_win_enabled(crtc, false);
+
mutex_lock(&vop->vop_lock);
drm_crtc_vblank_off(crtc);
 
+   if (crtc->state->psr_transition)
+   goto out;
+
/*
 * Vop standby will take effect at end of current frame,
 * if dsp hold valid irq happen, it means standby complete.
@@ -661,6 +688,8 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
clk_disable(vop->dclk);
vop_core_clks_disable(vop);
pm_runtime_put(vop->dev);
+
+out:
mutex_unlock(&vop->vop_lock);
 
if (crtc->state->event && !crtc->state->active) {
@@ -741,6 +770,7 @@ static void vop_plane_atomic_disable(struct drm_plane 
*plane,
spin_lock(&vop->reg_lock);
 
VOP_WIN_SET(vop, win, enable, 0);
+   vop->win_enabled &= ~BIT(VOP_WIN_TO_INDEX(vop_win));
 
spin_unlock(&vop->reg_lock);
 }
@@ -879,6 +909,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
}
 
VOP_WIN_SET(vop, win, enable, 1);
+   vop->win_enabled |= BIT(win_index);
spin_unlock(&vop->reg_lock);
 }
 
@@ -1034,6 +1065,12 @@ static void vop_crtc_atomic_enable(struct drm_crtc *crtc,
uint32_t pin_pol, val;
int ret;
 
+   if (old_state->psr_transition) {
+   drm_crtc_vblank_on(crtc);
+   rockchip_drm_set_win_enabled(crtc, true);
+   return;
+   }
+
mutex_lock(&vop->vop_lock);
 
WARN_ON(vop->event);
@@ -1627,6 +1664,7 @@ static int vop_initial(struct vop *vop)
VOP_WIN_SET(vop, win, channel, (channel + 1) << 4 | channel);
VOP_WIN_SET(vop, win, enable, 0);
VOP_WIN_SET(vop, win, gate, 1);
+   vop->win_enabled &= ~BIT(i);
}
 
vop_cfg_done(vop);
-- 
Sean Paul, Software Engineer, Google / Chromium OS

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel