date:20150622

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

--- Comment #1 from Orion Poplawski  ---
Still present with kernel-4.0.5-200.fc21.x86_64:

[drm:radeon_get_legacy_connector_info_from_bios [radeon]] *ERROR* Unknown
connector type: 8

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/000f3968/attachment.html>

[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'

2015-06-22 Thread Krzysztof Kozlowski

2015-06-22 20:42 GMT+09:00 Inki Dae :
> + Krzysztof
>
> On 2015ë 06ì 22ì¼ 18:10, Inki Dae wrote:
>> On 2015ë 06ì 12ì¼ 21:59, Hyungwon Hwang wrote:
>>> The clock which was named as 'pll_clk' is actually not the clock source
>>> of PLL in MIPI DSI. This patch fixes this disagreement.
>>
>> Mr. Kukjin and Krzysztof, can you give me Acked-by or Singed-off-by? I'd
>> like to merge this patch to mainline through drm-next.

Thanks for forwarding me other necessary patch. All that burden could
be easily avoided by sending everything to samsung-soc anyway.

The patch itself looks good:
Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

>>
>> Thanks,
>> Inki Dae
>>
>>>
>>> Signed-off-by: Hyungwon Hwang 
>>> ---
>>> Changes before:
>>> - Refer https://patchwork.kernel.org/patch/6191811
>>> Changes for v6:
>>> - None
>>>
>>>  arch/arm/boot/dts/exynos4.dtsi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
>>> index e20cdc2..1538d7a 100644
>>> --- a/arch/arm/boot/dts/exynos4.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4.dtsi
>>> @@ -167,7 +167,7 @@
>>>  phys = <_phy 1>;
>>>  phy-names = "dsim";
>>>  clocks = < CLK_DSIM0>, < CLK_SCLK_MIPI0>;
>>> -clock-names = "bus_clk", "pll_clk";
>>> +clock-names = "bus_clk", "sclk_mipi";
>>>  status = "disabled";
>>>  #address-cells = <1>;
>>>  #size-cells = <0>;
>>> --
>>> 1.9.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>

[PATCH v6 08/15] drm/exynos: dsi: rename pll_clk to sclk_clk

+ Samsung SoC mailing list.

On 2015ë 06ì 12ì¼ 21:59, Hyungwon Hwang wrote:
> This patch renames pll_clk to sclk_clk. The clock referenced by pll_clk
> is actually not the pll input clock for dsi. The pll input clock comes
> from the board's oscillator directly. But for the backward
> compatibility, the old clock name "pll_clk" is also OK.
> 
> Signed-off-by: Hyungwon Hwang 
> ---
> Changes before:
> - Refer https://patchwork.kernel.org/patch/6191721
> Changes for v6:
> - Merged 2 patches
>drm/exynos: dsi: add the backward compatibility for the renamed clock
>drm/exynos: dsi: rename pll_clk to sclk_clk
> 
>  .../devicetree/bindings/video/exynos_dsim.txt  |  7 +++--
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c| 36 
> ++
>  2 files changed, 20 insertions(+), 23 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
> b/Documentation/devicetree/bindings/video/exynos_dsim.txt
> index 802aa7e..44659dd 100644
> --- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
> @@ -10,13 +10,14 @@ Required properties:
>- interrupts: should contain DSI interrupt
>- clocks: list of clock specifiers, must contain an entry for each required
>  entry in clock-names
> -  - clock-names: should include "bus_clk"and "pll_clk" entries
> +  - clock-names: should include "bus_clk"and "sclk_mipi" entries
> +  the use of "pll_clk" is deprecated
>- phys: list of phy specifiers, must contain an entry for each required
>  entry in phy-names
>- phy-names: should include "dsim" entry
>- vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V)
>- vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
> -  - samsung,pll-clock-frequency: specifies frequency of the "pll_clk" clock
> +  - samsung,pll-clock-frequency: specifies frequency of the oscillator clock
>- #address-cells, #size-cells: should be set respectively to <1> and <0>
>  according to DSI host bindings (see MIPI DSI bindings [1])
> 
> @@ -48,7 +49,7 @@ Example:
>   reg = <0x11C8 0x1>;
>   interrupts = <0 79 0>;
>   clocks = < 286>, < 143>;
> - clock-names = "bus_clk", "pll_clk";
> + clock-names = "bus_clk", "sclk_mipi";
>   phys = <_phy 1>;
>   phy-names = "dsim";
>   vddcore-supply = <_reg>;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index c1999ad..a3bfac2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -235,6 +235,8 @@
>  #define DSI_XFER_TIMEOUT_MS  100
>  #define DSI_RX_FIFO_EMPTY0x3082
> 
> +#define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
> +
>  enum exynos_dsi_transfer_type {
>   EXYNOS_DSI_TX,
>   EXYNOS_DSI_RX,
> @@ -279,7 +281,7 @@ struct exynos_dsi {
> 
>   void __iomem *reg_base;
>   struct phy *phy;
> - struct clk *pll_clk;
> + struct clk *sclk_clk;
>   struct clk *bus_clk;
>   struct regulator_bulk_data supplies[2];
>   int irq;
> @@ -433,16 +435,7 @@ static unsigned long exynos_dsi_set_pll(struct 
> exynos_dsi *dsi,
>   u16 m;
>   u32 reg;
> 
> - clk_set_rate(dsi->pll_clk, dsi->pll_clk_rate);
> -
> - fin = clk_get_rate(dsi->pll_clk);
> - if (!fin) {
> - dev_err(dsi->dev, "failed to get PLL clock frequency\n");
> - return 0;
> - }
> -
> - dev_dbg(dsi->dev, "PLL input frequency: %lu\n", fin);
> -
> + fin = dsi->pll_clk_rate;
>   fout = exynos_dsi_pll_find_pms(dsi, fin, freq, , , );
>   if (!fout) {
>   dev_err(dsi->dev,
> @@ -1313,10 +1306,10 @@ static int exynos_dsi_poweron(struct exynos_dsi *dsi)
>   goto err_bus_clk;
>   }
> 
> - ret = clk_prepare_enable(dsi->pll_clk);
> + ret = clk_prepare_enable(dsi->sclk_clk);
>   if (ret < 0) {
>   dev_err(dsi->dev, "cannot enable pll clock %d\n", ret);
> - goto err_pll_clk;
> + goto err_sclk_clk;
>   }
> 
>   ret = phy_power_on(dsi->phy);
> @@ -1328,8 +1321,8 @@ static int exynos_dsi_poweron(struct exynos_dsi *dsi)
>   return 0;
> 
>  err_phy:
> - clk_disable_unprepare(dsi->pll_clk);
> -err_pll_clk:
> + clk_disable_unprepare(dsi->sclk_clk);
> +err_sclk_clk:
>   clk_disable_unprepare(dsi->bus_clk);
>  err_bus_clk:
>   regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
> @@ -1355,7 +1348,7 @@ static void exynos_dsi_poweroff(struct exynos_dsi *dsi)
> 
>   phy_power_off(dsi->phy);
> 
> - clk_disable_unprepare(dsi->pll_clk);
> + clk_disable_unprepare(dsi->sclk_clk);
>   clk_disable_unprepare(dsi->bus_clk);
> 
>   ret = regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
> @@ -1722,10 +1715,13 @@ static int exynos_dsi_probe(struct

[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'

2015-06-22 Thread Krzysztof Kozlowski

2015-06-22 21:10 GMT+09:00 Inki Dae :
> On 2015ë 06ì 22ì¼ 20:59, Krzysztof Kozlowski wrote:
>> 2015-06-22 20:42 GMT+09:00 Inki Dae :
>>> + Krzysztof
>>>
>>> On 2015ë 06ì 22ì¼ 18:10, Inki Dae wrote:
>>>> On 2015ë 06ì 12ì¼ 21:59, Hyungwon Hwang wrote:
>>>>> The clock which was named as 'pll_clk' is actually not the clock source
>>>>> of PLL in MIPI DSI. This patch fixes this disagreement.
>>>>
>>>> Mr. Kukjin and Krzysztof, can you give me Acked-by or Singed-off-by? I'd
>>>> like to merge this patch to mainline through drm-next.
>>
>> Dear Hyungwon Hwang,
>>
>> Please always CC samsung-soc mailing list on such patches. I won't
>> receive it on my personal email if you don't CC the list. The
>> get_maintainers.pl gives necessary addresses.
>>
>> Comment below,
>>
>>>>
>>>> Thanks,
>>>> Inki Dae
>>>>
>>>>>
>>>>> Signed-off-by: Hyungwon Hwang 
>>>>> ---
>>>>> Changes before:
>>>>> - Refer https://patchwork.kernel.org/patch/6191811
>>>>> Changes for v6:
>>>>> - None
>>>>>
>>>>>  arch/arm/boot/dts/exynos4.dtsi | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos4.dtsi 
>>>>> b/arch/arm/boot/dts/exynos4.dtsi
>>>>> index e20cdc2..1538d7a 100644
>>>>> --- a/arch/arm/boot/dts/exynos4.dtsi
>>>>> +++ b/arch/arm/boot/dts/exynos4.dtsi
>>>>> @@ -167,7 +167,7 @@
>>>>>  phys = <_phy 1>;
>>>>>  phy-names = "dsim";
>>>>>  clocks = < CLK_DSIM0>, < CLK_SCLK_MIPI0>;
>>>>> -clock-names = "bus_clk", "pll_clk";
>>>>> +clock-names = "bus_clk", "sclk_mipi";
>>
>> It seems wrong. The driver fetches reference from a name of "pll_clk",
>> not "sclk_mipi". Also bindings documentation mentions pll_clk and
>> bus_clk only.
>
> Krzysztof,
>
> There is your missing point. The driver is already considered for
> pll_clk also. See the below codes,
>
> #define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
> ...
>
> for (i = 0; i < dsi->driver_data->num_clks; i++) {
> dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
> if (IS_ERR(dsi->clks[i])) {
> if (strcmp(clk_names[i], "sclk_mipi") == 0) {
> strcpy(clk_names[i], OLD_SCLK_MIPI_CLK_NAME);
> i--;
> continue;
> }
>
> dev_info(dev, "failed to get the clock: %s\n",
> clk_names[i]);
> return PTR_ERR(dsi->clks[i]);
> }
> }
>
> Above codes make the driver to try to get the pll_clk - defined as
> OLD_SCLK_MIPI_CLK_NAME macro - again if getting sclk_mipi clock failed
> so there is no problem even though a little bit ugly.
>
> As you know, we should guarantee the backward compatibility so this
> codes check two clock names.

I am looking at next-20150622 and file
drivers/gpu/drm/exynos/exynos_drm_dsi.c. There is no such code there.
There is only pll_clk. No sclk_mipi.

Maybe it was changed by other patch... but I haven't received it. Also
I cannot find such patch on linux-kernel, linux-arm-kernel and
linux-samsung-soc. I cannot ack something that I cannot see :) .

If you sent whole patchset to my office address, then I will look at
it tomorrow. From home I can only look at LKML patches.

Best regards,
Krzysztof

[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'

On 2015ë 06ì 22ì¼ 20:59, Krzysztof Kozlowski wrote:
> 2015-06-22 20:42 GMT+09:00 Inki Dae :
>> + Krzysztof
>>
>> On 2015ë 06ì 22ì¼ 18:10, Inki Dae wrote:
>>> On 2015ë 06ì 12ì¼ 21:59, Hyungwon Hwang wrote:
 The clock which was named as 'pll_clk' is actually not the clock source
 of PLL in MIPI DSI. This patch fixes this disagreement.
>>>
>>> Mr. Kukjin and Krzysztof, can you give me Acked-by or Singed-off-by? I'd
>>> like to merge this patch to mainline through drm-next.
> 
> Dear Hyungwon Hwang,
> 
> Please always CC samsung-soc mailing list on such patches. I won't
> receive it on my personal email if you don't CC the list. The
> get_maintainers.pl gives necessary addresses.
> 
> Comment below,
> 
>>>
>>> Thanks,
>>> Inki Dae
>>>

 Signed-off-by: Hyungwon Hwang 
 ---
 Changes before:
 - Refer https://patchwork.kernel.org/patch/6191811
 Changes for v6:
 - None

  arch/arm/boot/dts/exynos4.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/arm/boot/dts/exynos4.dtsi 
 b/arch/arm/boot/dts/exynos4.dtsi
 index e20cdc2..1538d7a 100644
 --- a/arch/arm/boot/dts/exynos4.dtsi
 +++ b/arch/arm/boot/dts/exynos4.dtsi
 @@ -167,7 +167,7 @@
  phys = <_phy 1>;
  phy-names = "dsim";
  clocks = < CLK_DSIM0>, < CLK_SCLK_MIPI0>;
 -clock-names = "bus_clk", "pll_clk";
 +clock-names = "bus_clk", "sclk_mipi";
> 
> It seems wrong. The driver fetches reference from a name of "pll_clk",
> not "sclk_mipi". Also bindings documentation mentions pll_clk and
> bus_clk only.

Krzysztof,

There is your missing point. The driver is already considered for
pll_clk also. See the below codes,

#define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
...

for (i = 0; i < dsi->driver_data->num_clks; i++) {
dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
if (IS_ERR(dsi->clks[i])) {
if (strcmp(clk_names[i], "sclk_mipi") == 0) {
strcpy(clk_names[i], OLD_SCLK_MIPI_CLK_NAME);
i--;
continue;
}

dev_info(dev, "failed to get the clock: %s\n",
clk_names[i]);
return PTR_ERR(dsi->clks[i]);
}
}

Above codes make the driver to try to get the pll_clk - defined as
OLD_SCLK_MIPI_CLK_NAME macro - again if getting sclk_mipi clock failed
so there is no problem even though a little bit ugly.

As you know, we should guarantee the backward compatibility so this
codes check two clock names.

Thanks,
Inki Dae

> 
> Best regards,
> Krzysztof
> 
> 
  status = "disabled";
  #address-cells = <1>;
  #size-cells = <0>;
 --
 1.9.1

 --
 To unsubscribe from this list: send the line "unsubscribe devicetree" in
 the body of a message to majordomo at vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
>

[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'

2015-06-22 Thread Krzysztof Kozlowski

2015-06-22 20:42 GMT+09:00 Inki Dae :
> + Krzysztof
>
> On 2015ë 06ì 22ì¼ 18:10, Inki Dae wrote:
>> On 2015ë 06ì 12ì¼ 21:59, Hyungwon Hwang wrote:
>>> The clock which was named as 'pll_clk' is actually not the clock source
>>> of PLL in MIPI DSI. This patch fixes this disagreement.
>>
>> Mr. Kukjin and Krzysztof, can you give me Acked-by or Singed-off-by? I'd
>> like to merge this patch to mainline through drm-next.

Dear Hyungwon Hwang,

Please always CC samsung-soc mailing list on such patches. I won't
receive it on my personal email if you don't CC the list. The
get_maintainers.pl gives necessary addresses.

Comment below,

>>
>> Thanks,
>> Inki Dae
>>
>>>
>>> Signed-off-by: Hyungwon Hwang 
>>> ---
>>> Changes before:
>>> - Refer https://patchwork.kernel.org/patch/6191811
>>> Changes for v6:
>>> - None
>>>
>>>  arch/arm/boot/dts/exynos4.dtsi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
>>> index e20cdc2..1538d7a 100644
>>> --- a/arch/arm/boot/dts/exynos4.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4.dtsi
>>> @@ -167,7 +167,7 @@
>>>  phys = <_phy 1>;
>>>  phy-names = "dsim";
>>>  clocks = < CLK_DSIM0>, < CLK_SCLK_MIPI0>;
>>> -clock-names = "bus_clk", "pll_clk";
>>> +clock-names = "bus_clk", "sclk_mipi";

It seems wrong. The driver fetches reference from a name of "pll_clk",
not "sclk_mipi". Also bindings documentation mentions pll_clk and
bus_clk only.

Best regards,
Krzysztof


>>>  status = "disabled";
>>>  #address-cells = <1>;
>>>  #size-cells = <0>;
>>> --
>>> 1.9.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>

[PATCH v7 05/15] drm/exynos: add Exynos5433 decon driver

On 2015ë 06ì 22ì¼ 20:41, Varka Bhadram wrote:
> Hi,
> 
> On 06/22/2015 04:46 PM, Inki Dae wrote:
> 
>> From: Joonyoung Shim 
>>
>> DECON(Display and Enhancement Controller) is new IP replacing FIMD in
>> Exynos5433. This patch adds Exynos5433 decon driver.
>>
>> Changelog v7:
>> - Rebased on top of exynos-drm-next.
>> - Added runtime pm support.
>>
>> Signed-off-by: Joonyoung Shim 
>> Signed-off-by: Hyungwon Hwang 
>> Signed-off-by: Inki Dae 
>> ---
>>   
> 
> (...)
> 
>> +static int exynos5433_decon_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = >dev;
>> +struct decon_context *ctx;
>> +struct resource *res;
>> +int ret;
>> +int i;
>> +
>> +ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>> +if (!ctx)
>> +return -ENOMEM;
>> +
>> +ctx->default_win = 0;
>> +ctx->suspended = true;
>> +ctx->dev = dev;
>> +if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
>> +ctx->i80_if = true;
>> +
>> +for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
>> +struct clk *clk;
>> +
>> +clk = devm_clk_get(ctx->dev, decon_clks_name[i]);
>> +if (IS_ERR(clk))
>> +return PTR_ERR(clk);
>> +
>> +ctx->clks[i] = clk;
>> +}
>> +
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +if (!res) {
>> +dev_err(dev, "cannot find IO resource\n");
>> +return -ENXIO;
>> +}
>> +
> 
> You people promised me to remove this check  :-)

Right but isn't it better to check an error explicitly? Anyway trivial one.

> 
> http://lists.freedesktop.org/archives/dri-devel/2015-April/081077.html
> 
>> +ctx->addr = devm_ioremap_resource(dev, res);
>> +if (IS_ERR(ctx->addr)) {
>> +dev_err(dev, "ioremap failed\n");
>> +return PTR_ERR(ctx->addr);
>> +}
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
>> +ctx->i80_if ? "lcd_sys" : "vsync");
>> +if (!res) {
>> +dev_err(dev, "cannot find IRQ resource\n");
>> +return -ENXIO;
>> +}
>> +
>> +ret = devm_request_irq(dev, res->start, ctx->i80_if ?
>> +decon_lcd_sys_irq_handler : decon_vsync_irq_handler, 0,
>> +"drm_decon", ctx);
>> +if (ret < 0) {
>> +dev_err(dev, "lcd_sys irq request failed\n");
>> +return ret;
>> +}
>> +
>> +platform_set_drvdata(pdev, ctx);
> 
> You are setting the driver data as ctx..
> 
> But no where you are using it...?
> 
> Am i missing anything ?

See decon_bind and decon_unbind functions. :)

Thanks,
Inki Dae

>

[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'

+ Krzysztof

On 2015ë 06ì 22ì¼ 18:10, Inki Dae wrote:
> On 2015ë 06ì 12ì¼ 21:59, Hyungwon Hwang wrote:
>> The clock which was named as 'pll_clk' is actually not the clock source
>> of PLL in MIPI DSI. This patch fixes this disagreement.
> 
> Mr. Kukjin and Krzysztof, can you give me Acked-by or Singed-off-by? I'd
> like to merge this patch to mainline through drm-next.
> 
> Thanks,
> Inki Dae
> 
>>
>> Signed-off-by: Hyungwon Hwang 
>> ---
>> Changes before:
>> - Refer https://patchwork.kernel.org/patch/6191811
>> Changes for v6:
>> - None
>>
>>  arch/arm/boot/dts/exynos4.dtsi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
>> index e20cdc2..1538d7a 100644
>> --- a/arch/arm/boot/dts/exynos4.dtsi
>> +++ b/arch/arm/boot/dts/exynos4.dtsi
>> @@ -167,7 +167,7 @@
>>  phys = <_phy 1>;
>>  phy-names = "dsim";
>>  clocks = < CLK_DSIM0>, < CLK_SCLK_MIPI0>;
>> -clock-names = "bus_clk", "pll_clk";
>> +clock-names = "bus_clk", "sclk_mipi";
>>  status = "disabled";
>>  #address-cells = <1>;
>>  #size-cells = <0>;
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

[PATCH 3/3] drm/msm: mdp4 lvds: get panel node via of graph parsing

We currently get the output connected to LVDS by looking for a phandle
called 'qcom,lvds-panel' under the mdp DT node.

Use the more standard of_graph approach to create an lvds output port,
and retrieve the panel node from the port's endpoint data.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 32 +++-
 drivers/gpu/drm/msm/msm_drv.h   |  1 +
 2 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 531e4ac..cf72eda 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -241,22 +241,36 @@ int mdp4_enable(struct mdp4_kms *mdp4_kms)
 }

 #ifdef CONFIG_OF
-static struct drm_panel *detect_panel(struct drm_device *dev, const char *name)
+static struct drm_panel *detect_panel(struct drm_device *dev)
 {
-   struct device_node *n;
+   struct device_node *endpoint, *panel_node;
+   struct device_node *np = dev->dev->of_node;
struct drm_panel *panel = NULL;

-   n = of_parse_phandle(dev->dev->of_node, name, 0);
-   if (n) {
-   panel = of_drm_find_panel(n);
-   if (!panel)
-   panel = ERR_PTR(-EPROBE_DEFER);
+   endpoint = of_graph_get_next_endpoint(np, NULL);
+   if (IS_ERR(endpoint)) {
+   dev_err(dev->dev, "no valid endpoint\n");
+   return ERR_CAST(endpoint);
}

+   of_node_put(endpoint);
+
+   panel_node = of_graph_get_remote_port_parent(endpoint);
+   if (IS_ERR(panel_node)) {
+   dev_err(dev->dev, "no valid panel node\n");
+   return ERR_CAST(panel_node);
+   }
+
+   of_node_put(panel_node);
+
+   panel = of_drm_find_panel(panel_node);
+   if (IS_ERR(panel))
+   panel = ERR_PTR(-EPROBE_DEFER);
+
return panel;
 }
 #else
-static struct drm_panel *detect_panel(struct drm_device *dev, const char *name)
+static struct drm_panel *detect_panel(struct drm_device *dev)
 {
// ??? maybe use a module param to specify which panel is attached?
 }
@@ -294,7 +308,7 @@ static int modeset_init(struct mdp4_kms *mdp4_kms)
 * Setup the LCDC/LVDS path: RGB2 -> DMA_P -> LCDC -> LVDS:
 */

-   panel = detect_panel(dev, "qcom,lvds-panel");
+   panel = detect_panel(dev);
if (IS_ERR(panel)) {
ret = PTR_ERR(panel);
dev_err(dev->dev, "failed to detect LVDS panel: %d\n", ret);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index e7c5ea1..0cbeb1d 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #ifndef CONFIG_OF
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 2/3] drm/msm: dsi host: Use device graph parsing to parse connected panel

The dsi host looks for the connected panel node by parsing for a child
named 'panel'. This hierarchy isn't very flexible. The connected
panel is forced to be a child to the dsi host, and hence, a mipi dsi
device. This isn't suitable for dsi devices that don't use mipi dsi
as their control bus.

Follow the of_graph approach of creating ports and endpoints to
represent the connections between the dsi host and the panel connected
to it. In our case, the dsi host will only have one output port, linked
to the panel's input port.

Update DT binding documentation with device graph usage info.

Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/drm/msm/dsi.txt | 15 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c| 64 +--
 2 files changed, 63 insertions(+), 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/msm/dsi.txt 
b/Documentation/devicetree/bindings/drm/msm/dsi.txt
index 6ccd860..c88ec3c 100644
--- a/Documentation/devicetree/bindings/drm/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/drm/msm/dsi.txt
@@ -25,6 +25,9 @@ Required properties:
 - vddio-supply: phandle to vdd-io regulator device node
 - vdda-supply: phandle to vdda regulator device node
 - qcom,dsi-phy: phandle to DSI PHY device node
+- port: DSI controller output port. This contains one endpoint subnode, with 
its
+  remote-endpoint set to the phandle of the connected panel's endpoint.
+  See Documentation/devicetree/bindings/graph.txt for device graph info.

 Optional properties:
 - panel at 0: Node of panel connected to this DSI controller.
@@ -101,6 +104,18 @@ Example:

power-supply = <...>;
backlight = <...>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   port {
+   dsi0_out: endpoint {
+   remote-endpoint = <_in>;
+   };
};
};

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 1751659..ab0b23b 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1379,7 +1380,7 @@ static int dsi_host_attach(struct mipi_dsi_host *host,
msm_host->format = dsi->format;
msm_host->mode_flags = dsi->mode_flags;

-   msm_host->panel_node = dsi->dev.of_node;
+   WARN_ON(dsi->dev.of_node != msm_host->panel_node);

/* Some gpios defined in panel DT need to be controlled by host */
ret = dsi_host_init_panel_gpios(msm_host, >dev);
@@ -1429,6 +1430,46 @@ static struct mipi_dsi_host_ops dsi_host_ops = {
.transfer = dsi_host_transfer,
 };

+static int msm_dsi_host_parse_dt(struct msm_dsi_host *msm_host)
+{
+   struct device *dev = _host->pdev->dev;
+   struct device_node *np = dev->of_node;
+   struct device_node *endpoint, *panel_node;
+   int ret;
+
+   ret = of_property_read_u32(np, "qcom,dsi-host-index", _host->id);
+   if (ret) {
+   dev_err(dev, "%s: host index not specified, ret=%d\n",
+   __func__, ret);
+   return ret;
+   }
+
+   /*
+* get the first endpoint node. in our case, dsi has one output port
+* to which the panel is connected.
+*/
+   endpoint = of_graph_get_next_endpoint(np, NULL);
+   if (IS_ERR(endpoint)) {
+   dev_err(dev, "%s: no valid endpoint\n", __func__);
+   return PTR_ERR(endpoint);
+   }
+
+   of_node_put(endpoint);
+
+   /* get panel node from the output port's endpoint data */
+   panel_node = of_graph_get_remote_port_parent(endpoint);
+   if (IS_ERR(panel_node)) {
+   dev_err(dev, "%s: no valid device\n", __func__);
+   return PTR_ERR(panel_node);
+   }
+
+   of_node_put(panel_node);
+
+   msm_host->panel_node = panel_node;
+
+   return 0;
+}
+
 int msm_dsi_host_init(struct msm_dsi *msm_dsi)
 {
struct msm_dsi_host *msm_host = NULL;
@@ -1443,15 +1484,13 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
goto fail;
}

-   ret = of_property_read_u32(pdev->dev.of_node,
-   "qcom,dsi-host-index", _host->id);
+   msm_host->pdev = pdev;
+
+   ret = msm_dsi_host_parse_dt(msm_host);
if (ret) {
-   dev_err(>dev,
-   "%s: host index not specified, ret=%d\n",
-   __func__, ret);
+   pr_err("%s: failed to parse dt\n", __func__);
goto fail;
}
-   msm_host->pdev = pdev;

ret = dsi_clk_init(msm_host);
if (ret) {
@@ -1559,7 +1598,6 @@ int

[PATCH 1/3] drm/msm: dsi host: add missing of_node_put()

Decrement device node refcount if of_get_child_by_name is successfully
called.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index de04009..1751659 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1582,6 +1582,8 @@ int msm_dsi_host_register(struct mipi_dsi_host *host, 
bool check_defer)
node = of_get_child_by_name(msm_host->pdev->dev.of_node,
"panel");
if (node) {
+   of_node_put(node);
+
if (!of_drm_find_panel(node))
return -EPROBE_DEFER;
}
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 0/3] drm/msm: Use device graph to parse connected panels

drm/msm currently relies on phandles/child nodes to get data about
connected panels to LVDS and DSI. This method has known limitations.

Use device graphs in DT to represent the connections between the encoder
outputs and the panels. Use of_graph helpers in the driver to get the
panel device node.

The usage of device graphs should also simplify management in dual dsi
mode. I haven't tried this out yet, though.

Archit Taneja (3):
  drm/msm: dsi host: add missing of_node_put()
  drm/msm: dsi host: Use device graph parsing to parse connected panel
  drm/msm: mdp4 lvds: get panel node via of graph parsing

 Documentation/devicetree/bindings/drm/msm/dsi.txt | 15 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c| 62 ++-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   | 32 
 drivers/gpu/drm/msm/msm_drv.h |  1 +
 4 files changed, 87 insertions(+), 23 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH v7 05/15] drm/exynos: add Exynos5433 decon driver

From: Joonyoung Shim 

DECON(Display and Enhancement Controller) is new IP replacing FIMD in
Exynos5433. This patch adds Exynos5433 decon driver.

Changelog v7:
- Rebased on top of exynos-drm-next.
- Added runtime pm support.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Inki Dae 
---
 .../devicetree/bindings/video/exynos5433-decon.txt |   65 ++
 drivers/gpu/drm/exynos/Kconfig |6 +
 drivers/gpu/drm/exynos/Makefile|1 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  |  660 
 drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
 include/video/exynos5433_decon.h   |  165 +
 6 files changed, 898 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/exynos5433-decon.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos5433_drm_decon.c
 create mode 100644 include/video/exynos5433_decon.h

diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
new file mode 100644
index 000..377afbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
@@ -0,0 +1,65 @@
+Device-Tree bindings for Samsung Exynos SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be "samsung,exynos5433-decon";
+- reg: physical base address and length of the DECON registers set.
+- interrupts: should contain a list of all DECON IP block interrupts in the
+ order: VSYNC, LCD_SYSTEM. The interrupt specifier format
+ depends on the interrupt controller used.
+- interrupt-names: should contain the interrupt names: "vsync", "lcd_sys"
+  in the same order as they were listed in the interrupts
+  property.
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+- clock-names: list of clock names sorted in the same order as the clocks
+  property. Must contain "aclk_decon", "aclk_smmu_decon0x",
+  "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk",
+  "sclk_decon_eclk"
+- ports: contains a port which is connected to mic node. address-cells and
+size-cells must 1 and 0, respectively.
+- port: contains an endpoint node which is connected to the endpoint in the mic
+   node. The reg value muset be 0.
+- i80-if-timings: specify whether the panel which is connected to decon uses
+ i80 lcd interface or mipi video interface. This node contains
+ no timing information as that of fimd does. Because there is
+ no register in decon to specify i80 interface timing value,
+ it is not needed, but make it remain to use same kind of node
+ in fimd and exynos7 decon.
+
+Example:
+SoC specific DT entry:
+decon: decon at 1380 {
+   compatible = "samsung,exynos5433-decon";
+   reg = <0x1380 0x2104>;
+   clocks = <_disp CLK_ACLK_DECON>, <_disp CLK_ACLK_SMMU_DECON0X>,
+   <_disp CLK_ACLK_XIU_DECON0X>,
+   <_disp CLK_PCLK_SMMU_DECON0X>,
+   <_disp CLK_SCLK_DECON_VCLK>,
+   <_disp CLK_SCLK_DECON_ECLK>;
+   clock-names = "aclk_decon", "aclk_smmu_decon0x", "aclk_xiu_decon0x",
+   "pclk_smmu_decon0x", "sclk_decon_vclk", "sclk_decon_eclk";
+   interrupt-names = "vsync", "lcd_sys";
+   interrupts = <0 202 0>, <0 203 0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   decon_to_mic: endpoint {
+   remote-endpoint = <_to_decon>;
+   };
+   };
+   };
+};
+
+Board specific DT entry:
+ {
+   i80-if-timings {
+   };
+};
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index ddb7c8a..51a4eb5 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,6 +24,12 @@ config DRM_EXYNOS_FIMD
help
  Choose this option if you want to use Exynos FIMD for DRM.

+config DRM_EXYNOS5433_DECON
+   bool "Exynos5433 DRM DECON"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos5433 DECON for DRM.
+
 config DRM_EXYNOS7_DECON
bool "Exynos7 DRM DECON"
depends on DRM_EXYNOS && !FB_S3C
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index cc90679..fbd084d 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -10,6 +10,7 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \

[Bug 91014] Piglit regression: spec/!OpenGL 1.2/texture-packed-formats

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

--- Comment #4 from Mark Janes  ---
I was able to reproduce this bug using the old versions of piglit and mesa

  piglit:  1f39e07d44f7d78557d69c505168afb8eab913c6
  mesa:c2a0600

After updating piglit to the latest revision, the test passes.

Based on this information, I think it is safe to conclude that this
bug does not indicate a regression in mesa.  Instead, it is caused by
using an obsolete version of piglit.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/6c395675/attachment.html>

[Bug 91016] Piglit regression: shaders/glsl-floating-constant-120

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

--- Comment #4 from Mark Janes  ---
I was able to reproduce this bug using the old versions of piglit and mesa

  piglit:  1f39e07d44f7d78557d69c505168afb8eab913c6
  mesa:c2a0600

After updating piglit to the latest revision, the test passes.  This
seems to be the correct behavior, based on Ian's comment.

Based on this information, I think it is safe to conclude that this
bug does not indicate a regression in mesa.  Instead, it is caused by
using a fixed version of mesa, but failing to pull in the
corresponding piglit fix.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/0cc9a6f6/attachment.html>

[Bug 91015] Piglit regression: spec/ARB_occlusion_query2/api

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

--- Comment #5 from Mark Janes  ---
I was able to reproduce this bug using the old versions of piglit and mesa

  piglit:  1f39e07d44f7d78557d69c505168afb8eab913c6
  mesa:c2a0600

After updating piglit to the latest revision, the test skips.  This
seems to be the correct behavior, since g33 does not support occlusion
query.

Based on this information, it seems safe to conclude that this bug is
the result of running an obsolete/buggy version of piglit, and does
not indicate a regression in mesa.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/c54da9c7/attachment.html>

[PATCH 00/21] On-demand device registration

2015-06-22 Thread Rob Herring

On Mon, Jun 22, 2015 at 10:23 AM, Tomeu Vizoso
 wrote:
> On 28 May 2015 at 06:33, Rob Herring  wrote:
>> On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
>>  wrote:
>>> Hello,
>>>
>>> I have a problem with the panel on my Tegra Chromebook taking longer than
>>> expected to be ready during boot (StÃ©phane Marchesin reported what is
>>> basically the same issue in [0]), and have looked into ordered probing as a
>>> better way of solving this than moving nodes around in the DT or playing 
>>> with
>>> initcall levels.
>>>
>>> While reading the thread [1] that Alexander Holler started with his series 
>>> to
>>> make probing order deterministic, it occurred to me that it should be 
>>> possible
>>> to achieve the same by registering devices as they are referenced by other
>>> devices.
>>
>> I like the concept and novel approach.
>>
>>> This basically reuses the information that is already implicit in the 
>>> probe()
>>> implementations, saving us from refactoring existing drivers or adding
>>> information to DTBs.
>>>
>>> Something I'm not completely happy with is that I have had to move the call 
>>> to
>>> of_platform_populate after all platform drivers have been registered.
>>> Otherwise I don't see how I could register drivers on demand as we don't 
>>> have
>>> yet each driver's compatible strings.
>>
>> Yeah, this is the opposite of what we'd really like.
>
> Can you elaborate on the reasons why we would like to have devices
> registered before built-in drivers finish registering, even if we
> don't probe them yet?

My main thought was for modules we will almost always have devices
appearing first. More generally, we can have devices and drivers
coming or going at any point in time and should not put restrictions
on ordering.

Also, I think all the probe ordering and dependency tracking should be
done within the driver core (i.e. dependencies are a list of struct
devices). At some level it has to become firmware specific, but we
want to minimize that part. I could be convinced otherwise and you
have put more thought into this problem than I have.

>> Ideally, we would
>> have a solution that works for modules too. However, we're no worse
>> off. We pretty much build-in dependencies to avoid module ordering
>> problems.
>
> Nod, I haven't looked yet at requesting modules on-demand, but I guess
> it should be doable. Modules that have dependencies described in the
> firmware should get them probed automatically already though.
>
>> Perhaps we need to make the probing on-demand rather than simply on
>> device<->driver match occurring.
>
> I'm afraid that too much old code depends on that. For example, Rafael
> pointed out to the PNP subsystem, which registers a driver that will
> probe devices with the EISA ID PNP0c02 to reserve memory regions for
> devices that will be probed later.
>
> http://lxr.free-electrons.com/source/drivers/pnp/system.c
>
> My understanding is that probing of PNP0c02 devices must happen before
> the actual devices that depend on those regions are probed, so if we
> decoupled the probing from the driver/device registration, we would be
> breaking that assumption.

That shouldn't matter as PNP matching is PNP specific. We already have
different ways of matching with device/driver name or of_match_table
for example. Changing how and when OF matching occurs would not affect
PNP matching. We do matching on device and driver add currently. For
the "when" part, we would need to add what I'll call async matching or
deferred matching which in addition to matching on the of_match_table
also matches on the dependency list having probed. Your last series
essentially does this, but the difference is yours is not OF specific
and I think it needs to be. I mean it is OF specific only in the
aspect that matching already is. From a driver and subsystem
standpoint, it should not be OF specific much like deferred probe is
not OF specific, but in reality only occurs (currently) on OF probed
drivers.

>>> For machs that don't move of_platform_populate() to a later point, these
>>> patches shouldn't cause any problems but it's not guaranteed that we'll 
>>> avoid
>>> all the deferred probes as some drivers may not be registered yet.
>>
>> Ideally, of_platform_populate is not explicitly called by each
>> platform. So I think we need to make this work for the default case.
>
> The problem is that some platforms will need fixing because some
> initcalls assume that some devices will have been registered already,
> or even probed. I think removing those assumptions shouldn't be
> problematic because I haven't had much trouble with this on the four
> platforms I have tested with, but I cannot test every board that is
> supported upstream.
>
> I can ask though the KernelCI folks to boot my branch in all their
> boards and make sure that those work when of_platform_populate is
> called in late_initcall.

I'd imagine Kevin would be happy to. That is still a subset of h/w, so
we'd need a way to disable any

[Bug 91061] [4.1-rc8][radeonsi] GPU lockup from chrome - radeon_ttm_bo_destroy

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

Shawn Starr  changed:

   What|Removed |Added

Version|XOrg git|DRI git

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/19ad8781/attachment.html>

[Bug 91061] [4.1-rc8][radeonsi] GPU lockup from chrome - radeon_ttm_bo_destroy

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

--- Comment #1 from Shawn Starr  ---
GPU Info: Radeon BONAIRE (Saturn XT) FirePro M6100

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/21b5a859/attachment.html>

[Bug 91061] [4.1-rc8][radeonsi] GPU lockup from chrome - radeon_ttm_bo_destroy

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

Bug ID: 91061
   Summary: [4.1-rc8][radeonsi] GPU lockup from chrome -
radeon_ttm_bo_destroy
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: shawn.starr at rogers.com

Created attachment 116660
  --> https://bugs.freedesktop.org/attachment.cgi?id=116660=edit
Kernel stack dump

Somehow triggered GPU lockup with Chrome

Attachment contains crash stack from kernel

DDX: xorg-x11-drv-ati-7.5.0-3.fc22.x86_64
Kernel: 4.1.0-0.rc8.git0.2.fc23.x86_64
Mesa: mesa-dri-drivers-10.7.0-0.devel.60.20150606.fc22.x86_64 (git master
build, from specified date)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/ec677d11/attachment.html>

[Bug 91016] Piglit regression: shaders/glsl-floating-constant-120

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

--- Comment #3 from Chad Versace  ---
Brian Wilson said:
> It fails in the following Mesa commit:
>   c2a0600 i965: Don't set NirOptions for stages that will use the vec4 
> backend [May 2015-ish]

Incorrect. The actual Mesa tree that Brian's team is validating is commit
c1a0600 plus many patches. I've the pushed the full tree, patches included, to 

  git://github.com/chadversary/mesa refs/tags/chadv/cros-gerrit-262788-patched

Also, the Piglit being tested is the following commit plus a few incosequential
patches.

  commit 4069bec62a8a99c44573395ea1597694760f
  Author: Marek OlÅ¡Ã¡k 
  AuthorDate: Thu Apr 30 14:11:26 2015 +0200
  Commit: Marek OlÅ¡Ã¡k 
  CommitDate: Thu Apr 30 22:41:02 2015 +0200
  Subject: framework: use the correct executable for GLES parser tests

Building that Piglit against recent Mesa, however, produces an error at
linktime. The fix requires backporting Piglit commit
845ba0e4dfb9372307f5d3032abdd0860e76731b.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/2215211a/attachment.html>

[Bug 91015] Piglit regression: spec/ARB_occlusion_query2/api

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

--- Comment #4 from Chad Versace  ---
Brian Wilson said:
> It fails in the following Mesa commit:
>   c2a0600 i965: Don't set NirOptions for stages that will use the vec4 
> backend [May 2015-ish]

Incorrect. The actual Mesa tree that Brian's team is validating is commit
c1a0600 plus many patches. I've the pushed the full tree, patches included, to 

  git://github.com/chadversary/mesa refs/tags/chadv/cros-gerrit-262788-patched

Also, the Piglit being tested is the following commit plus a few incosequential
patches.

  commit 4069bec62a8a99c44573395ea1597694760f
  Author: Marek OlÅ¡Ã¡k 
  AuthorDate: Thu Apr 30 14:11:26 2015 +0200
  Commit: Marek OlÅ¡Ã¡k 
  CommitDate: Thu Apr 30 22:41:02 2015 +0200
  Subject: framework: use the correct executable for GLES parser tests

Building that Piglit against recent Mesa, however, produces an error at
linktime. The fix requires backporting Piglit commit
845ba0e4dfb9372307f5d3032abdd0860e76731b.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/3ba0f71a/attachment.html>

[Bug 91014] Piglit regression: spec/!OpenGL 1.2/texture-packed-formats

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

--- Comment #3 from Chad Versace  ---
Brian Wilson said:
> It fails in the following Mesa commit:
> c2a0600 i965: Don't set NirOptions for stages that will use the vec4
backend [May 2015-ish]

Incorrect. The actual Mesa tree that Brian's team is validating is commit
c1a0600 plus many patches. I've the pushed the full tree, patches included, to 

  git://github.com/chadversary/mesa refs/tags/chadv/cros-gerrit-262788-patched

Also, the Piglit being tested is the following commit plus a few incosequential
patches.

  commit 4069bec62a8a99c44573395ea1597694760f
  Author: Marek OlÅ¡Ã¡k 
  AuthorDate: Thu Apr 30 14:11:26 2015 +0200
  Commit: Marek OlÅ¡Ã¡k 
  CommitDate: Thu Apr 30 22:41:02 2015 +0200
  Subject: framework: use the correct executable for GLES parser tests

Building that Piglit against recent Mesa, however, produces an error at
linktime. The fix requires backporting Piglit commit
845ba0e4dfb9372307f5d3032abdd0860e76731b.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/1fdde9af/attachment-0001.html>

[PULL] drm-intel-next-fixes

On 22 June 2015 at 18:12, Jani Nikula  wrote:
> On Mon, 22 Jun 2015, Ander Conselvan De Oliveira  
> wrote:
>> There is
>>
>> commit bd4b4827acdc00bf9e71f939d160102021d10d4f
>> Author: Ander Conselvan de Oliveira
>> 
>> Date:   Fri May 29 14:28:09 2015 +0300
>>
>> drm/i915: Silence compiler warning
>>
>> in -nightly to fix that same issue. I didn't realize this was also
>> needed in -next-fixes.
>
> Dave, sorry, I didn't see the warning, gcc 4.9.2 here.
>
> Do you want another pull request with Ander's fix on top?

Yes please.

Dave.

[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'

On 2015ë 06ì 12ì¼ 21:59, Hyungwon Hwang wrote:
> The clock which was named as 'pll_clk' is actually not the clock source
> of PLL in MIPI DSI. This patch fixes this disagreement.

Mr. Kukjin and Krzysztof, can you give me Acked-by or Singed-off-by? I'd
like to merge this patch to mainline through drm-next.

Thanks,
Inki Dae

> 
> Signed-off-by: Hyungwon Hwang 
> ---
> Changes before:
> - Refer https://patchwork.kernel.org/patch/6191811
> Changes for v6:
> - None
> 
>  arch/arm/boot/dts/exynos4.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index e20cdc2..1538d7a 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -167,7 +167,7 @@
>   phys = <_phy 1>;
>   phy-names = "dsim";
>   clocks = < CLK_DSIM0>, < CLK_SCLK_MIPI0>;
> - clock-names = "bus_clk", "pll_clk";
> + clock-names = "bus_clk", "sclk_mipi";
>   status = "disabled";
>   #address-cells = <1>;
>   #size-cells = <0>;
> --
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[PATCH libdrm 2/2] xf86drmMode: include config.h before anything else

Signed-off-by: Emil Velikov 
---
 xf86drmMode.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index 30ef6f2..71bd62f 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -37,14 +37,15 @@
  * TODO the types we are after are defined in diffrent headers on diffrent
  * platforms find which headers to include to get uint32_t
  */
-#include 
-#include 
-#include 

 #ifdef HAVE_CONFIG_H
 #include "config.h"
 #endif

+#include 
+#include 
+#include 
+
 #include "xf86drmMode.h"
 #include "xf86drm.h"
 #include 
-- 
2.1.3

[PATCH libdrm 1/2] xf86drmMode: remove unused valgrind(VG) macros

Signed-off-by: Emil Velikov 
---
 xf86drmMode.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index 1333da4..30ef6f2 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -53,14 +53,6 @@
 #include 
 #include 

-#ifdef HAVE_VALGRIND
-#include 
-#include 
-#define VG(x) x
-#else
-#define VG(x)
-#endif
-
 #define memclear(s) memset(, 0, sizeof(s))

 #define U642VOID(x) ((void *)(unsigned long)(x))
-- 
2.1.3

[Bug 91015] Piglit regression: spec/ARB_occlusion_query2/api

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

--- Comment #3 from Ian Romanick  ---
The following two piglit commits are probably necessary:

commit 49e326474d5ed487d04ff6bef1efae376e4a2492
Author: Eduardo Lima Mitev 
Date:   Mon Feb 16 11:10:30 2015 +0100

arb_occlusion_query2: Checks that query obj passed to glBeginQuery matches
target

From the OpenGL 3.3 spec, section "2.14. ASYNCHRONOUS QUERIES", page 94:

"[...] if id is the name of an existing query object whose type does
not
 match target, [...] the error INVALID_OPERATION is generated."

Similar wording exists in the OpenGL ES 3.0.0 spec, section "2.13.
ASYNCHRONOUS QUERIES", page 82.

This patch adds a check for this situation.

Reviewed-by: Ian Romanick 

commit 0eff6819639d8c84c98f8fa0bd0b254a69aead60
Author: Eduardo Lima Mitev 
Date:   Sat Feb 14 13:29:52 2015 +0100

arb_occlusion_query2: expect an error when target mismatch in
glBeginQuery()

From the OpenGL 3.3 spec, section "2.14. ASYNCHRONOUS QUERIES", page 94:

"[...] if id is the name of an existing query object whose type does
not
 match target, [...] the error INVALID_OPERATION is generated."

Similar wording exists in the OpenGL ES 3.0.0 spec, section "2.13.
ASYNCHRONOUS QUERIES", page 82.

Hence, trying to call BeginQuery on a query object which has already
been bound to a different target should return GL_INVALID_OPERATION.

Reviewed-by: Ian Romanick 

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/49851dec/attachment.html>

[PATCH] drm/dp/mst: make sure mst_primary mstb is valid in work function

From: Daniel Vetter 

This validates the mst_primary under the lock, and then calls
into the check and send function. This makes the code a lot
easier to understand the locking rules in.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index a9c437e..8a3bfcd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1204,7 +1204,7 @@ static void drm_dp_check_and_send_link_address(struct 
drm_dp_mst_topology_mgr *m
   struct drm_dp_mst_branch *mstb)
 {
struct drm_dp_mst_port *port;
-
+   struct drm_dp_mst_branch *mstb_child;
if (!mstb->link_address_sent) {
drm_dp_send_link_address(mgr, mstb);
mstb->link_address_sent = true;
@@ -1219,17 +1219,31 @@ static void drm_dp_check_and_send_link_address(struct 
drm_dp_mst_topology_mgr *m
if (!port->available_pbn)
drm_dp_send_enum_path_resources(mgr, mstb, port);

-   if (port->mstb)
-   drm_dp_check_and_send_link_address(mgr, port->mstb);
+   if (port->mstb) {
+   mstb_child = drm_dp_get_validated_mstb_ref(mgr, 
port->mstb);
+   if (mstb_child) {
+   drm_dp_check_and_send_link_address(mgr, 
mstb_child);
+   drm_dp_put_mst_branch_device(mstb_child);
+   }
+   }
}
 }

 static void drm_dp_mst_link_probe_work(struct work_struct *work)
 {
struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct 
drm_dp_mst_topology_mgr, work);
+   struct drm_dp_mst_branch *mstb;

-   drm_dp_check_and_send_link_address(mgr, mgr->mst_primary);
-
+   mutex_lock(>lock);
+   mstb = mgr->mst_primary;
+   if (mstb) {
+   kref_get(>kref);
+   }
+   mutex_unlock(>lock);
+   if (mstb) {
+   drm_dp_check_and_send_link_address(mgr, mstb);
+   drm_dp_put_mst_branch_device(mstb);
+   }
 }

 static bool drm_dp_validate_guid(struct drm_dp_mst_topology_mgr *mgr,
-- 
2.4.1

[PATCH v7 05/15] drm/exynos: add Exynos5433 decon driver

On 06/22/2015 05:27 PM, Inki Dae wrote:

> On 2015ë 06ì 22ì¼ 20:41, Varka Bhadram wrote:
>
(..)

> +platform_set_drvdata(pdev, ctx);
>> You are setting the driver data as ctx..
>>
>> But no where you are using it...?
>>
>> Am i missing anything ?
> See decon_bind and decon_unbind functions. :)

Cleared. Thanks


-- 
Best regards,
Varka Bhadram.

[PATCH v2 libdrm 2/2] Add blob property create/destroy ioctl wrappers

2015-06-22 Thread Daniel Stone

v2: Use memclear to zero out structure.

Signed-off-by: Daniel Stone 
---
 include/drm/drm.h  |  2 ++
 include/drm/drm_mode.h | 21 +
 xf86drmMode.c  | 34 ++
 xf86drmMode.h  |  5 +
 4 files changed, 62 insertions(+)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 0b1d2ef..15d4454 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -766,6 +766,8 @@ struct drm_prime_handle {
 #define DRM_IOCTL_MODE_OBJ_SETPROPERTY DRM_IOWR(0xBA, struct 
drm_mode_obj_set_property)
 #define DRM_IOCTL_MODE_CURSOR2 DRM_IOWR(0xBB, struct drm_mode_cursor2)
 #define DRM_IOCTL_MODE_ATOMIC  DRM_IOWR(0xBC, struct drm_mode_atomic)
+#define DRM_IOCTL_MODE_CREATEPROPBLOB  DRM_IOWR(0xBD, struct 
drm_mode_create_blob)
+#define DRM_IOCTL_MODE_DESTROYPROPBLOB DRM_IOWR(0xBE, struct 
drm_mode_destroy_blob)

 /**
  * Device specific ioctls should only be in their respective headers
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 66f856f..69c1ac3 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -523,4 +523,25 @@ struct drm_mode_atomic {
__u64 user_data;
 };

+/**
+ * Create a new 'blob' data property, copying length bytes from data pointer,
+ * and returning new blob ID.
+ */
+struct drm_mode_create_blob {
+   /** Pointer to data to copy. */
+   __u64 data;
+   /** Length of data to copy. */
+   __u32 length;
+   /** Return: new property ID. */
+   __u32 blob_id;
+};
+
+/**
+ * Destroy a user-created blob property.
+ */
+struct drm_mode_destroy_blob {
+   __u32 blob_id;
+};
+
+
 #endif
diff --git a/xf86drmMode.c b/xf86drmMode.c
index a75eca3..73c8695 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -1387,3 +1387,37 @@ out:

return ret;
 }
+
+int
+drmModeCreatePropertyBlob(int fd, const void *data, size_t length, uint32_t 
*id)
+{
+   struct drm_mode_create_blob create;
+   int ret;
+
+   if (length >= 0x)
+   return -ERANGE;
+
+   memclear(create);
+
+   create.length = length;
+   create.data = (uintptr_t) data;
+   create.blob_id = 0;
+   *id = 0;
+
+   ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_CREATEPROPBLOB, );
+   if (ret != 0)
+   return ret;
+
+   *id = create.blob_id;
+   return 0;
+}
+
+int
+drmModeDestroyPropertyBlob(int fd, uint32_t id)
+{
+   struct drm_mode_destroy_blob destroy;
+
+   memclear(destroy);
+   destroy.blob_id = id;
+   return DRM_IOCTL(fd, DRM_IOCTL_MODE_DESTROYPROPBLOB, );
+}
diff --git a/xf86drmMode.h b/xf86drmMode.h
index 317ea23..1c10023 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -503,6 +503,11 @@ extern int drmModeAtomicCommit(int fd,
   uint32_t flags,
   void *user_data);

+extern int drmModeCreatePropertyBlob(int fd, const void *data, size_t size,
+uint32_t *id);
+extern int drmModeDestroyPropertyBlob(int fd, uint32_t id);
+
+
 #if defined(__cplusplus) || defined(c_plusplus)
 }
 #endif
-- 
2.4.3

[PATCH v2 libdrm 1/2] Support atomic modesetting ioctl

2015-06-22 Thread Daniel Stone

From: Ville SyrjÃ¤lÃ¤ 

Add support for the atomic modesetting ioctl through a property-set API.

v1: Squashed intermediate patches from Ville, Rob and myself. Updated
for current kernel interface (no blobs).
v2: Rewrite user-facing API to provide transactional/cursor interface.
Use memclear to zero out ioctl.

Signed-off-by: Ville SyrjÃ¤lÃ¤ 
Signed-off-by: Rob Clark 
Signed-off-by: Daniel Stone 
---
 include/drm/drm.h  |   9 ++
 include/drm/drm_mode.h |  16 
 xf86drmMode.c  | 240 +
 xf86drmMode.h  |  19 
 4 files changed, 284 insertions(+)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 229a29f..0b1d2ef 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -635,6 +635,13 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2

+/**
+ * DRM_CLIENT_CAP_ATOMIC
+ *
+ * If set to 1, the DRM core will allow atomic modesetting requests.
+ */
+#define DRM_CLIENT_CAP_ATOMIC  3
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
@@ -758,6 +765,7 @@ struct drm_prime_handle {
 #define DRM_IOCTL_MODE_OBJ_GETPROPERTIES   DRM_IOWR(0xB9, struct 
drm_mode_obj_get_properties)
 #define DRM_IOCTL_MODE_OBJ_SETPROPERTY DRM_IOWR(0xBA, struct 
drm_mode_obj_set_property)
 #define DRM_IOCTL_MODE_CURSOR2 DRM_IOWR(0xBB, struct drm_mode_cursor2)
+#define DRM_IOCTL_MODE_ATOMIC  DRM_IOWR(0xBC, struct drm_mode_atomic)

 /**
  * Device specific ioctls should only be in their respective headers
@@ -806,6 +814,7 @@ struct drm_event_vblank {
 #define DRM_CAP_PRIME 0x5
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
 #define DRM_CAP_ASYNC_PAGE_FLIP 0x7
+#define DRM_CAP_ATOMIC 0xa

 #define DRM_PRIME_CAP_IMPORT 0x1
 #define DRM_PRIME_CAP_EXPORT 0x2
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index a2ab88a..66f856f 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -507,4 +507,20 @@ struct drm_mode_destroy_dumb {
__u32 handle;
 };

+/* page-flip flags are valid, plus: */
+#define DRM_MODE_ATOMIC_TEST_ONLY  0x0100
+#define DRM_MODE_ATOMIC_NONBLOCK   0x0200
+#define DRM_MODE_ATOMIC_ALLOW_MODESET  0x0400
+
+struct drm_mode_atomic {
+   __u32 flags;
+   __u32 count_objs;
+   __u64 objs_ptr;
+   __u64 count_props_ptr;
+   __u64 props_ptr;
+   __u64 prop_values_ptr;
+   __u64 reserved;
+   __u64 user_data;
+};
+
 #endif
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 1333da4..a75eca3 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -37,9 +37,12 @@
  * TODO the types we are after are defined in diffrent headers on diffrent
  * platforms find which headers to include to get uint32_t
  */
+#include 
 #include 
+#include 
 #include 
 #include 
+#include 

 #ifdef HAVE_CONFIG_H
 #include "config.h"
@@ -1147,3 +1150,240 @@ int drmModeObjectSetProperty(int fd, uint32_t 
object_id, uint32_t object_type,

return DRM_IOCTL(fd, DRM_IOCTL_MODE_OBJ_SETPROPERTY, );
 }
+
+typedef struct _drmModeAtomicReqItem drmModeAtomicReqItem, 
*drmModeAtomicReqItemPtr;
+
+struct _drmModeAtomicReqItem {
+   uint32_t object_id;
+   uint32_t property_id;
+   uint64_t value;
+};
+
+struct _drmModeAtomicReq {
+   uint32_t cursor;
+   uint32_t size_items;
+   drmModeAtomicReqItemPtr items;
+};
+
+drmModeAtomicReqPtr drmModeAtomicAlloc(void)
+{
+   drmModeAtomicReqPtr req;
+
+   req = drmMalloc(sizeof *req);
+   if (!req)
+   return NULL;
+
+   req->items = NULL;
+   req->cursor = 0;
+   req->size_items = 0;
+
+   return req;
+}
+
+drmModeAtomicReqPtr drmModeAtomicDuplicate(drmModeAtomicReqPtr old)
+{
+   drmModeAtomicReqPtr new;
+
+   new = drmMalloc(sizeof *new);
+   if (!new)
+   return NULL;
+
+   new->cursor = old->cursor;
+   new->size_items = old->size_items;
+
+   if (old->size_items) {
+   new->items = drmMalloc(old->size_items * sizeof(*new->items));
+   if (!new->items) {
+   free(new);
+   return NULL;
+   }
+   memcpy(new->items, old->items,
+  old->size_items * sizeof(*new->items));
+   } else {
+   new->items = NULL;
+   }
+
+   return new;
+}
+
+int drmModeAtomicMerge(drmModeAtomicReqPtr base, drmModeAtomicReqPtr augment)
+{
+   if (!augment || augment->cursor == 0)
+   return 0;
+
+   if (base->cursor + augment->cursor >= base->size_items) {
+   drmModeAtomicReqItemPtr new;
+   int saved_size = base->size_items;
+
+   base->size_items = base->cursor + augment->cursor;
+   new = realloc(base->items,
+ base->size_items * sizeof(*base->items));
+   if (!new) {
+   base->size_items = saved_size;
+

[PATCH 00/21] On-demand device registration

2015-06-22 Thread Tomeu Vizoso

On 28 May 2015 at 06:33, Rob Herring  wrote:
> On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
>  wrote:
>> Hello,
>>
>> I have a problem with the panel on my Tegra Chromebook taking longer than
>> expected to be ready during boot (StÃ©phane Marchesin reported what is
>> basically the same issue in [0]), and have looked into ordered probing as a
>> better way of solving this than moving nodes around in the DT or playing with
>> initcall levels.
>>
>> While reading the thread [1] that Alexander Holler started with his series to
>> make probing order deterministic, it occurred to me that it should be 
>> possible
>> to achieve the same by registering devices as they are referenced by other
>> devices.
>
> I like the concept and novel approach.
>
>> This basically reuses the information that is already implicit in the probe()
>> implementations, saving us from refactoring existing drivers or adding
>> information to DTBs.
>>
>> Something I'm not completely happy with is that I have had to move the call 
>> to
>> of_platform_populate after all platform drivers have been registered.
>> Otherwise I don't see how I could register drivers on demand as we don't have
>> yet each driver's compatible strings.
>
> Yeah, this is the opposite of what we'd really like.

Can you elaborate on the reasons why we would like to have devices
registered before built-in drivers finish registering, even if we
don't probe them yet?

> Ideally, we would
> have a solution that works for modules too. However, we're no worse
> off. We pretty much build-in dependencies to avoid module ordering
> problems.

Nod, I haven't looked yet at requesting modules on-demand, but I guess
it should be doable. Modules that have dependencies described in the
firmware should get them probed automatically already though.

> Perhaps we need to make the probing on-demand rather than simply on
> device<->driver match occurring.

I'm afraid that too much old code depends on that. For example, Rafael
pointed out to the PNP subsystem, which registers a driver that will
probe devices with the EISA ID PNP0c02 to reserve memory regions for
devices that will be probed later.

http://lxr.free-electrons.com/source/drivers/pnp/system.c

My understanding is that probing of PNP0c02 devices must happen before
the actual devices that depend on those regions are probed, so if we
decoupled the probing from the driver/device registration, we would be
breaking that assumption.

>> For machs that don't move of_platform_populate() to a later point, these
>> patches shouldn't cause any problems but it's not guaranteed that we'll avoid
>> all the deferred probes as some drivers may not be registered yet.
>
> Ideally, of_platform_populate is not explicitly called by each
> platform. So I think we need to make this work for the default case.

The problem is that some platforms will need fixing because some
initcalls assume that some devices will have been registered already,
or even probed. I think removing those assumptions shouldn't be
problematic because I haven't had much trouble with this on the four
platforms I have tested with, but I cannot test every board that is
supported upstream.

I can ask though the KernelCI folks to boot my branch in all their
boards and make sure that those work when of_platform_populate is
called in late_initcall.

http://kernelci.org/boot/all/job/next/kernel/next-20150619/

>> I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
>> patches were enough to eliminate all the deferred probes.
>>
>> With this series I get the kernel to output to the panel in 0.5s, instead of 
>> 2.8s.
>
> That's certainly compelling.

Have to say that those numbers are with the serial console enabled
(without, it's 0.5s vs 1.5s), but on machines that take longer to boot
we should see bigger gains because we won't be sending devices to the
end of the queue when their probe is deferred.

Regards,

Tomeu

> Rob
>
>>
>> Regards,
>>
>> Tomeu
>>
>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
>>
>> [1] https://lkml.org/lkml/2014/5/12/452
>>
>> Tomeu Vizoso (21):
>>   regulator: core: Reduce critical area in _regulator_get
>>   ARM: tegra: Add gpio-ranges property
>>   ARM: tegra: Register drivers before devices
>>   ARM: EXYNOS: Register drivers before devices
>>   ARM i.MX6q: Register drivers before devices
>>   of/platform: Add of_platform_device_ensure()
>>   of/platform: Ensure device registration on lookup
>>   gpio: Probe GPIO drivers on demand
>>   gpio: Probe pinctrl devices on demand
>>   regulator: core: Probe regulators on demand
>>   drm: Probe panels on demand
>>   drm/tegra: Probe dpaux devices on demand
>>   i2c: core: Probe i2c master devices on demand
>>   pwm: Probe PWM chip devices on demand
>>   backlight: Probe backlight devices on demand
>>   usb: phy: Probe phy devices on demand
>>   clk: Probe clk providers on demand
>>   pinctrl: Probe pinctrl devices on demand
>>   phy: core: Probe phy providers

[Bug 91016] Piglit regression: shaders/glsl-floating-constant-120

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

--- Comment #2 from Brian Wilson  ---
This is the version of Piglit that is being used:
http://cgit.freedesktop.org/piglit/commit/?id=1f39e07d44f7d78557d69c505168afb8eab913c6

Here is the failing test output:
06/13 08:50:32.209 DEBUG|base_utils:0239| [stdout] + Running test
[shaders/glsl-floating-constant-120] of expected runtime 0.0 sec:
[bin/shader_runner tests/shaders/glsl-floating-constant-120.shader_test -auto]
06/13 08:50:32.310 DEBUG|base_utils:0239| [stderr] Failed to compile
FS: 0:5(14): error: syntax error, unexpected NEW_IDENTIFIER, expecting ',' or
';'
06/13 08:50:32.312 DEBUG|base_utils:0239| [stderr] 
06/13 08:50:32.314 DEBUG|base_utils:0239| [stdout] PIGLIT: {"result":
"fail" }
06/13 08:50:32.315 DEBUG|base_utils:0239| [stdout] + fail ::
shaders/glsl-floating-constant-120

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/7985d897/attachment.html>

[Bug 91015] Piglit regression: spec/ARB_occlusion_query2/api

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

--- Comment #2 from Brian Wilson  ---
Version of Piglit being used:
http://cgit.freedesktop.org/piglit/commit/?id=1f39e07d44f7d78557d69c505168afb8eab913c6

Here's the failure output from the test:
06/13 08:38:48.586 DEBUG|base_utils:0239| [stdout] + Running test
[spec/ARB_occlusion_query2/api] of expected runtime 0.0 sec:
[bin/arb_occlusion_query2-api -fbo -auto]
06/13 08:38:48.691 DEBUG|base_utils:0239| [stderr]
GL_CURRENT_QUERY(GL_SAMPLES_PASSED) returned 0 while GL_SAMPLES_PASSED active
06/13 08:38:48.692 DEBUG|base_utils:0239| [stdout] Unexpected GL error:
GL_INVALID_OPERATION 0x502
06/13 08:38:48.694 DEBUG|base_utils:0239| [stdout] (Error at
../../../../../../piglit-2014.07.23/tests/spec/arb_occlusion_query2/api.c:119)
06/13 08:38:48.696 DEBUG|base_utils:0239| [stdout] Unexpected GL error:
GL_INVALID_OPERATION 0x502
06/13 08:38:48.698 DEBUG|base_utils:0239| [stdout] (Error at
../../../../../../piglit-2014.07.23/tests/spec/arb_occlusion_query2/api.c:128)
06/13 08:38:48.699 DEBUG|base_utils:0239| [stdout] Unexpected GL error:
GL_INVALID_OPERATION 0x502
06/13 08:38:48.703 DEBUG|base_utils:0239| [stdout] (Error at
../../../../../../piglit-2014.07.23/tests/spec/arb_occlusion_query2/api.c:63)
06/13 08:38:48.704 DEBUG|base_utils:0239| [stdout] Unexpected GL error:
GL_NO_ERROR 0x0
06/13 08:38:48.707 DEBUG|base_utils:0239| [stdout] (Error at
../../../../../../piglit-2014.07.23/tests/spec/arb_occlusion_query2/api.c:66)
06/13 08:38:48.708 DEBUG|base_utils:0239| [stdout] Expected GL error:
GL_INVALID_OPERATION 0x502
06/13 08:38:48.709 DEBUG|base_utils:0239| [stdout] PIGLIT: {"result":
"fail" }
06/13 08:38:48.711 DEBUG|base_utils:0239| [stdout] + fail ::
spec/ARB_occlusion_query2/api

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/1146269d/attachment.html>

[PATCH] drm/dp: look up the mstb passed into work function

>> It doesn't actually matter if mgr->mst_primary gets messed up here I
>> don't think,
>> as long as we validate it. So the value is going to be either a)
>> correct, b) NULL,
>> c) garbage between a and b assuming its not atomic, the validate function
>> locks the mgr, and checks primary, at this point primary will either be a or 
>> b
>> as we hold the lock, and if primary from outside the function is a, b or c 
>> won't
>> matter as the validation will either pass or fail depending on the
>> state under the
>> lock.
>
> Hm, I was afraid of some derefencing of the passed-in mstb pointer, but
> indeed we seem to be covered. Still I think pulling the mgr->lock out and
> instead using drm_dp_mst_get_validated_mstb_ref_locked in
> drm_dp_check_and_send_link_address would result in less head-scratching
> next time we read this code ;-)

That's why the follow up patch adds a comment. Also that starts down the road
of locks protecting code not data, the lock is only needed for the lookup
not the whole function. The problem being the function iterates, so then
we end up holding the lock for a lot longer than is required IMO.

Dave.

[PATCH v2 0/9] drm/exynos: cleanups and small fixes for libdrm

On 12 June 2015 at 18:15, Tobias Jakobi  
wrote:
> Hello,
>
> I've split off the Exynos specific bits, so this is just some cleanups and 
> small fixes. Everything can be reviewed without knowledge about the Exynos 
> platform. My hope is that I can get at least some of the patches from my last 
> series upstream.
>
> With best wishes,
> Tobias
>
> Changes in v2:
> - Made it clear that the error handling is currently 'unsatisfactory', but 
> that this is going to be adressed in a later patch.
> - Point out that removed code also wasn't used anywhere in the past (by 
> inspection of git history).
>
Big thanks for the update. It will make things clear a week/month down
the road - when we've forgotten pretty much everything in the area :-)
Considering how trivial these are and the silence from the
Samsung/Exynos folk, I'll be pushing these later on today.

If some of the dead code ends up required, we can always bring it back.

Cheers,
Emil

[Bug 91014] Piglit regression: spec/!OpenGL 1.2/texture-packed-formats

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

--- Comment #2 from Brian Wilson  ---
Version of Piglit being used:
http://cgit.freedesktop.org/piglit/commit/?id=1f39e07d44f7d78557d69c505168afb8eab913c6

Here's the error:
06/13 08:36:34.256 DEBUG|base_utils:0239| [stdout] + Running test
[spec/!OpenGL 1.2/texture-packed-formats] of expected runtime 0.0 sec:
[bin/texture-packed-formats -au
to]
06/13 08:36:34.847 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGBA
06/13 08:36:34.850 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGBA2
06/13 08:36:34.852 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGBA4
06/13 08:36:34.856 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB5_A1
06/13 08:36:34.866 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGBA8
06/13 08:36:34.867 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGBA12
06/13 08:36:34.868 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGBA16
06/13 08:36:34.869 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB10_A2
06/13 08:36:34.871 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB
06/13 08:36:34.872 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_R3_G3_B2
06/13 08:36:34.873 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB4
06/13 08:36:34.875 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB5
06/13 08:36:34.877 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB8
06/13 08:36:34.878 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB10
06/13 08:36:34.879 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB12
06/13 08:36:34.880 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB16
06/13 08:36:34.881 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGBA
06/13 08:36:34.883 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGBA2
06/13 08:36:34.884 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGBA4
06/13 08:36:34.888 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB5_A1
06/13 08:36:34.890 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGBA8
06/13 08:36:34.891 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGBA12
06/13 08:36:34.892 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGBA16
06/13 08:36:34.893 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB10_A2
06/13 08:36:34.895 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB
06/13 08:36:34.896 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_R3_G3_B2
06/13 08:36:34.897 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB4
06/13 08:36:34.898 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB5
06/13 08:36:34.900 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB8
06/13 08:36:34.904 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB10
06/13 08:36:34.905 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB12
06/13 08:36:34.906 DEBUG|base_utils:0239| [stdout] Unexpected GL Error
for GL_RGB16
06/13 08:36:34.908 DEBUG|base_utils:0239| [stdout] PIGLIT: {"result":
"fail" }
06/13 08:36:34.909 DEBUG|base_utils:0239| [stdout] + fail ::
spec/!OpenGL 1.2/texture-packed-formats

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/4be9465b/attachment-0001.html>

[PATCH v7 05/15] drm/exynos: add Exynos5433 decon driver

Hi,

On 06/22/2015 04:46 PM, Inki Dae wrote:

> From: Joonyoung Shim 
>
> DECON(Display and Enhancement Controller) is new IP replacing FIMD in
> Exynos5433. This patch adds Exynos5433 decon driver.
>
> Changelog v7:
> - Rebased on top of exynos-drm-next.
> - Added runtime pm support.
>
> Signed-off-by: Joonyoung Shim 
> Signed-off-by: Hyungwon Hwang 
> Signed-off-by: Inki Dae 
> ---
>   

(...)

> +static int exynos5433_decon_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct decon_context *ctx;
> + struct resource *res;
> + int ret;
> + int i;
> +
> + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + ctx->default_win = 0;
> + ctx->suspended = true;
> + ctx->dev = dev;
> + if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
> + ctx->i80_if = true;
> +
> + for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
> + struct clk *clk;
> +
> + clk = devm_clk_get(ctx->dev, decon_clks_name[i]);
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + ctx->clks[i] = clk;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(dev, "cannot find IO resource\n");
> + return -ENXIO;
> + }
> +

You people promised me to remove this check  :-)

http://lists.freedesktop.org/archives/dri-devel/2015-April/081077.html

> + ctx->addr = devm_ioremap_resource(dev, res);
> + if (IS_ERR(ctx->addr)) {
> + dev_err(dev, "ioremap failed\n");
> + return PTR_ERR(ctx->addr);
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
> + ctx->i80_if ? "lcd_sys" : "vsync");
> + if (!res) {
> + dev_err(dev, "cannot find IRQ resource\n");
> + return -ENXIO;
> + }
> +
> + ret = devm_request_irq(dev, res->start, ctx->i80_if ?
> + decon_lcd_sys_irq_handler : decon_vsync_irq_handler, 0,
> + "drm_decon", ctx);
> + if (ret < 0) {
> + dev_err(dev, "lcd_sys irq request failed\n");
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, ctx);

You are setting the driver data as ctx..

But no where you are using it...?

Am i missing anything ?

-- 
Best regards,
Varka Bhadram.

[PATCH libdrm] configure: Add flag to disable valgrind support.

On 22 June 2015 at 16:56, Matt Turner  wrote:
> ---
>  configure.ac | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 78a0010..dd6c0ab 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -403,7 +403,15 @@ else
>  fi
>  AM_CONDITIONAL([HAVE_MANPAGES_STYLESHEET], [test 
> "x$HAVE_MANPAGES_STYLESHEET" = "xyes"])
>
> -PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
> [have_valgrind=no])
> +AC_ARG_ENABLE(valgrind,
> +  AS_HELP_STRING([--disable-valgrind],
> + [Disable valgrind support]),
> + [use_valgrind=$enableval], [use_valgrind=yes])
> +
> +if test "x$use_valgrind" = "xyes"; then
> +   PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
> [have_valgrind=no])
> +fi
> +
Any objections if we move this to "auto" rather than enabled by
default (like we do with cairo) ? If you're ok I'll amend the patch
before pushing.

-Emil

[Bug 91016] Piglit regression: shaders/glsl-floating-constant-120

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

Ian Romanick  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Ian Romanick  ---
Does your piglit have the following commit?  Mesa was updated to follow the
spec, and the test was previously incorrect.

commit 63aef6af996d5ca37e9dee78e0392106848e2735
Author: Neil Roberts 
Date:   Wed Nov 26 18:35:32 2014 +

Don't test floats with the form â1fâ

There is nothing in the GLSL spec which says you can have a float
literal without an exponent or a decimal point even if you add the âfâ
suffix. This patch replaces that literal with some other variations
that should be accepted according to the spec.

Reviewed-by: Matt Turner 

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/077c2efd/attachment.html>

[Bug 91015] Piglit regression: spec/ARB_occlusion_query2/api

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

--- Comment #1 from Ian Romanick  ---
Note that this hardware does not support occlusion queries, so
ARB_occlusion_query2 should not even be enabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/0fb7c967/attachment.html>

[PATCH 1/3] drm/msm: dsi host: add missing of_node_put()

2015-06-22 Thread Srinivas Kandagatla



On 22/06/15 15:54, Archit Taneja wrote:
> Decrement device node refcount if of_get_child_by_name is successfully
> called.
>
> Signed-off-by: Archit Taneja 
> ---
>   drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index de04009..1751659 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -1582,6 +1582,8 @@ int msm_dsi_host_register(struct mipi_dsi_host *host, 
> bool check_defer)
>   node = of_get_child_by_name(msm_host->pdev->dev.of_node,
>   "panel");
>   if (node) {
> + of_node_put(node);
> +

Atleast from the current state of code, It looks like the driver is 
going to refer to the node of_node_put?, So I think this is not the 
right place to have of_node_put.



  > if (!of_drm_find_panel(node))
>   return -EPROBE_DEFER;
>   }
>

[v2 5/7] pwm: crc: Add Crystalcove (CRC) PWM driver

Hi Shobhit Kumar,

On 06/22/2015 04:24 PM, Shobhit Kumar wrote:

> The Crystalcove PMIC provides three PWM signals and this driver exports
> one of them on the BYT platform which is used to control backlight for
> DSI panel. This is platform device implementation of the drivers/mfd
> cell device for CRC PMIC.
>
> v2: Use the existing config callback with duty_ns and period_ns(Thierry)
>
> v3: Correct the subject line (Lee jones)
>
> v4: Address comment by Thierry & Paul
>  - Commit message update and fixes for few syntax errors
>  - Add PWM_CRC in Kconfig and Makefile sorted alphabetically
>  - Use the PWM_BASE_CLK as 600 for better code readability
>  - Remove the redundant rule of three while calculating pwm level
>  - Use the platform_device in pwm_chip
>  - Use builin_platform_driver
>
> CC: Samuel Ortiz 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: Thierry Reding 
> Cc: Paul Bolle 
> Cc: Paul Gortmaker 
> Signed-off-by: Shobhit Kumar 

(...)

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PWM0_CLK_DIV 0x4B
> +#define  PWM_OUTPUT_ENABLE   (1 << 7)

Can't be BIT() macro ?

> +#define  PWM_DIV_CLK_0   0x00 /* DIVIDECLK = BASECLK */
> +#define  PWM_DIV_CLK_100 0x63 /* DIVIDECLK = BASECLK/100 */
> +#define  PWM_DIV_CLK_128 0x7F /* DIVIDECLK = BASECLK/128 */
> +
> +#define PWM0_DUTY_CYCLE  0x4E
> +#define BACKLIGHT_EN 0x51

(...)

> +static int crystalcove_pwm_probe(struct platform_device *pdev)
> +{
> + struct crystalcove_pwm *pwm;
> + int retval;
> + struct device *dev = pdev->dev.parent;
> + struct intel_soc_pmic *pmic = dev_get_drvdata(dev);
> +
> + pwm = devm_kzalloc(>dev, sizeof(*pwm), GFP_KERNEL);
> + if (!pwm)
> + return -ENOMEM;
> +
> + pwm->chip.dev = >dev;
> + pwm->chip.ops = _pwm_ops;
> + pwm->chip.base = -1;
> + pwm->chip.npwm = 1;
> +
> + /* get the PMIC regmap */
> + pwm->regmap = pmic->regmap;
> +
> + retval = pwmchip_add(>chip);
> + if (retval < 0)
> + return retval;
> +
> + platform_set_drvdata(pdev, pwm);
> +

If you can change this oder we can simply do something like this:

platform_set_drvdata(pdev, pwm);

return pwmchip_add(>chip);

> + return 0;
> +}
> +
> +static int crystalcove_pwm_remove(struct platform_device *pdev)
> +{
> + struct crystalcove_pwm *pwm = platform_get_drvdata(pdev);
> + int retval;
> +
> + retval = pwmchip_remove(>chip);
> + if (retval < 0)
> + return retval;
> +
> + dev_dbg(>dev, "crc-pwm driver removed\n");

This debug message may not be required  :-)

you can directly do:

return pwmchip_remove(>chip);

> +
> + return 0;
> +}
> +
> +static struct platform_driver crystalcove_pwm_driver = {
> + .probe = crystalcove_pwm_probe,
> + .remove = crystalcove_pwm_remove,
> + .driver = {
> + .name = "crystal_cove_pwm",
> + },
> +};
> +
> +builtin_platform_driver(crystalcove_pwm_driver);


-- 
Best regards,
Varka Bhadram.

[Intel-gfx] [PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off

On Mon, 22 Jun 2015, Josh Boyer  wrote:
> On Mon, Jun 22, 2015 at 9:27 AM, Jani Nikula
>  wrote:
>> On Mon, 22 Jun 2015, Josh Boyer  wrote:
>>> On Mon, Jun 22, 2015 at 8:02 AM, Daniel Vetter  
>>> wrote:
 We should never nest these since in theory kms drivers should know
 when a pipe is on/off and call the corresponding enable/disable
 functions for the vblank helper code only once. But for historical
 reasons (the shared-with-ums version of this code in modeset_pre/post
 needed to be able to cope with silly userspace that lost track of
 things) we still have this bit of "robustness" around.

 Enforce this with a WARN_ON, preparing to eventually rip out this
 special handling.
>>>
>>> This doesn't really provide any context in the WARN_ON itself.  It
>>> will just result in a splat that looks like a kernel oops, and end
>>> users and distribution maintainers will be left scratching their
>>> heads.
>>>
>>> Could this be done with a printk warning instead, or could you at
>>> least provide a pr_warn statement to help people understand why their
>>> machine has an oops splat?
>>
>> FWIW i915_drv.h has
>>
>> #define WARN_ON(x) WARN((x), "WARN_ON(" #x ")")
>>
>> which makes it a little better...
>
> Only a little though, and only in i915.  This is in the generic DRM
> code, isn't it?

You're absolutely right, sorry. Agreed with your complaint.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/i915: enable BIOS hang workaround for Lenovo T60 too

2015-06-22 Thread Imre Deak

On pe, 2015-06-19 at 18:36 +0200, Paul Bolle wrote:
> On Fri, 2015-06-19 at 17:44 +0200, Daniel Vetter wrote:
> > I wonder whether we shouldn't do this unconditionally for gen4 and earlier
> > for Lenovo ... Anyway this needs Cc: stable at vger.kernel.org and is for
> > Jani to pick up.
> > 
> > Thanks for figuring out what's been broken here.
> > -Daniel
> > 
> > >   pci_set_power_state(drm_dev->pdev, PCI_D3hot);
> > >  
> > >   return 0;
> 
> Just two days ago we discussed this bug too, see
> https://lkml.org/lkml/2015/6/17/327 . That message contains a link to a
> patch I cobbled together for yet another ThinkPad hitting this, but with
> PCI_SUBVENDOR_ID_IBM involved.

To summarize, since we extended the range of platforms to apply the
workaround in
commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb
Author: Imre Deak 
Date:   Mon Mar 2 13:04:41 2015 +0200

drm/i915: gen4: work around hang during hibernation

we had the following reports I know of with the same issue:
- Acer Aspire 1830T by Ilya (Gen5) [1]
- Fujitsu FSC S7110 by Dirk (Gen4.5) [2]
- ThinkPad X60 by Pavel (Gen4.5) [3]
- ThinkPad T60 by Mikko (Gen4.5) [4]
- ThinkPad X41 by Paul (Gen3) [5]

Based on this I would give up on a vendor specific blacklist and apply
the workaround for anything < GEN6.

About completely reverting the original
commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
Author: Imre Deak 
Date:   Thu Oct 23 19:23:26 2014 +0300

drm/i915: add poweroff_late handler

I still believe that the normal thing to do is to power off the device
during S4. This is the default action taken by the kernel's PCI core for
every device. S4 is not a state where it'd be guaranteed that all
devices are powered off, there may be wake-up devices that are still
powered for example, so powering off any devices explicitly that are not
wake-up sources makes sense to me. I think we need a point where we stop
applying this workaround and GEN6 seems like a good point for that,
since I haven't seen any report past GEN5.

--Imre

[1] https://bugzilla.kernel.org/show_bug.cgi?id=94241#c8
[2] https://bugzilla.kernel.org/show_bug.cgi?id=95061
[3] https://lkml.org/lkml/2015/6/17/404
[4] http://lists.freedesktop.org/archives/intel-gfx/2015-June/069305.html
[5] https://lkml.org/lkml/2015/3/18/133

[v2 4/7] mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM

Hi Shobhit Kumar,

On 06/22/2015 04:24 PM, Shobhit Kumar wrote:

> On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
> entry for the same to be used by the consumer (Intel GFX)
>
> v2: Remove the lookup table on driver unload (Thierry)
>
> v3: Correct the subject line (Lee jones)

This part should only describe what this is about..

Don't put this patch change history over here.
Include this change history after
...
Signed-off-by: Author 
---

> CC: Samuel Ortiz 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: Thierry Reding 
> Acked-by: Lee Jones 
> Signed-off-by: Shobhit Kumar 
> ---

Here you add this change history so that after applying this
will not be the part of your commit description.

This comment is applicable for all of your patches.

-- 
Best regards,
Varka Bhadram.

[Intel-gfx] [PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off

On Mon, 22 Jun 2015, Josh Boyer  wrote:
> On Mon, Jun 22, 2015 at 8:02 AM, Daniel Vetter  
> wrote:
>> We should never nest these since in theory kms drivers should know
>> when a pipe is on/off and call the corresponding enable/disable
>> functions for the vblank helper code only once. But for historical
>> reasons (the shared-with-ums version of this code in modeset_pre/post
>> needed to be able to cope with silly userspace that lost track of
>> things) we still have this bit of "robustness" around.
>>
>> Enforce this with a WARN_ON, preparing to eventually rip out this
>> special handling.
>
> This doesn't really provide any context in the WARN_ON itself.  It
> will just result in a splat that looks like a kernel oops, and end
> users and distribution maintainers will be left scratching their
> heads.
>
> Could this be done with a printk warning instead, or could you at
> least provide a pr_warn statement to help people understand why their
> machine has an oops splat?

FWIW i915_drv.h has

#define WARN_ON(x) WARN((x), "WARN_ON(" #x ")")

which makes it a little better...

BR,
Jani.


>
> josh
>
>> Cc: Yogesh Mohan Marimuthu 
>> Cc: Gaurav K Singh 
>> Cc: Michel DÃ¤nzer 
>> Cc: Ville SyrjÃ¤lÃ¤ 
>> Signed-off-by: Daniel Vetter 
>> ---
>>  drivers/gpu/drm/drm_irq.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> index f9cc68fbd2a3..3819465abe22 100644
>> --- a/drivers/gpu/drm/drm_irq.c
>> +++ b/drivers/gpu/drm/drm_irq.c
>> @@ -1219,6 +1219,8 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
>> vblank_disable_and_save(dev, crtc);
>> wake_up(>queue);
>>
>> +   WARN_ON(vblank->inmodeset);
>> +
>> /*
>>  * Prevent subsequent drm_vblank_get() from re-enabling
>>  * the vblank interrupt by bumping the refcount.
>> @@ -1318,6 +1320,8 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
>> return;
>>
>> spin_lock_irqsave(>vbl_lock, irqflags);
>> +   WARN_ON(!vblank->inmodeset);
>> +
>> /* Drop our private "prevent drm_vblank_get" refcount */
>> if (vblank->inmodeset) {
>> atomic_dec(>refcount);
>> --
>> 2.1.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center

[v2 7/7] drm/i915: Backlight control using CRC PMIC based PWM driver

Use the CRC PWM device in intel_panel.c and add new MIPI backlight
specififc callbacks

v2: Modify to use pwm_config callback
v3: Addressed Jani's comments
- Renamed all function as pwm_* instead of vlv_*
- Call intel_panel_actually_set_backlight in enable function
- Return -ENODEV in case pwm_get fails
- in case pwm_config error return error cdoe from pwm_config
- Cleanup pwm in intel_panel_destroy_backlight

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Signed-off-by: Shobhit Kumar 
---
 drivers/gpu/drm/i915/intel_drv.h   |  4 ++
 drivers/gpu/drm/i915/intel_dsi.c   |  6 +++
 drivers/gpu/drm/i915/intel_panel.c | 95 --
 3 files changed, 100 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2afb31a..561c17f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -182,6 +182,10 @@ struct intel_panel {
bool enabled;
bool combination_mode;  /* gen 2/4 only */
bool active_low_pwm;
+
+   /* PWM chip */
+   struct pwm_device *pwm;
+
struct backlight_device *device;
} backlight;

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index c4db74a..be8722c 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -402,6 +402,8 @@ static void intel_dsi_enable(struct intel_encoder *encoder)

intel_dsi_port_enable(encoder);
}
+
+   intel_panel_enable_backlight(intel_dsi->attached_connector);
 }

 static void intel_dsi_pre_enable(struct intel_encoder *encoder)
@@ -466,6 +468,8 @@ static void intel_dsi_pre_disable(struct intel_encoder 
*encoder)

DRM_DEBUG_KMS("\n");

+   intel_panel_disable_backlight(intel_dsi->attached_connector);
+
if (is_vid_mode(intel_dsi)) {
/* Send Shutdown command to the panel in LP mode */
for_each_dsi_port(port, intel_dsi->ports)
@@ -1132,6 +1136,8 @@ void intel_dsi_init(struct drm_device *dev)
}

intel_panel_init(_connector->panel, fixed_mode, NULL);
+   intel_panel_setup_backlight(connector,
+   (intel_encoder->crtc_mask = (1 << PIPE_A)) ? PIPE_A : PIPE_B);

return;

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 7d83527..2aa30db 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -32,8 +32,12 @@

 #include 
 #include 
+#include 
 #include "intel_drv.h"

+#define CRC_PMIC_PWM_PERIOD_NS 21333
+#define CRC_PMIC_PWM_STEPS 255
+
 void
 intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
   struct drm_display_mode *adjusted_mode)
@@ -544,6 +548,15 @@ static u32 bxt_get_backlight(struct intel_connector 
*connector)
return I915_READ(BXT_BLC_PWM_DUTY1);
 }

+static u32 pwm_get_backlight(struct intel_connector *connector)
+{
+   struct intel_panel *panel = >panel;
+   int duty_ns;
+
+   duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
+   return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
+}
+
 static u32 intel_panel_get_backlight(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
@@ -632,6 +645,14 @@ static void bxt_set_backlight(struct intel_connector 
*connector, u32 level)
I915_WRITE(BXT_BLC_PWM_DUTY1, level);
 }

+static void pwm_set_backlight(struct intel_connector *connector, u32 level)
+{
+   struct intel_panel *panel = >panel;
+   int duty_ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+
+   pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
+}
+
 static void
 intel_panel_actually_set_backlight(struct intel_connector *connector, u32 
level)
 {
@@ -769,6 +790,16 @@ static void bxt_disable_backlight(struct intel_connector 
*connector)
I915_WRITE(BXT_BLC_PWM_CTL1, tmp & ~BXT_BLC_PWM_ENABLE);
 }

+static void pwm_disable_backlight(struct intel_connector *connector)
+{
+   struct intel_panel *panel = >panel;
+
+   /* Disable the backlight */
+   pwm_config(panel->backlight.pwm, 0, CRC_PMIC_PWM_PERIOD_NS);
+   usleep_range(2000, 3000);
+   pwm_disable(panel->backlight.pwm);
+}
+
 void intel_panel_disable_backlight(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
@@ -1002,6 +1033,14 @@ static void bxt_enable_backlight(struct intel_connector 
*connector)
I915_WRITE(BXT_BLC_PWM_CTL1, pwm_ctl | BXT_BLC_PWM_ENABLE);
 }

+static void pwm_enable_backlight(struct intel_connector *connector)
+{
+   struct intel_panel *panel = >panel;
+
+   pwm_enable(panel->backlight.pwm);
+   intel_panel_actually_set_backlight(connector, panel->backlight.level);
+}
+
 void intel_panel_enable_backlight(struct intel_connector *connector)

[v2 6/7] drm/i915: Use the CRC gpio for panel enable/disable

The CRC (Crystal Cove) PMIC, controls the panel enable and disable
signals for BYT for dsi panels. This is indicated in the VBT fields. Use
that to initialize and use GPIO based control for these signals.

v2: Use the newer gpiod interface(Alexandre)
v3: Remove the redundant checks and unused code (Ville)
v4: Moved PWM vs SoC backlight #defines to intel_bios.h (Jani)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Acked-by: Linus Walleij 
Reviewed-by: Jani Nikula 
Signed-off-by: Shobhit Kumar 
---
 drivers/gpu/drm/i915/intel_bios.h |  7 +++
 drivers/gpu/drm/i915/intel_dsi.c  | 32 ++--
 drivers/gpu/drm/i915/intel_dsi.h  |  3 +++
 3 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.h 
b/drivers/gpu/drm/i915/intel_bios.h
index af0b476..f7ad6a5 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -778,6 +778,13 @@ int intel_parse_bios(struct drm_device *dev);
 #define MIPI_DSI_UNDEFINED_PANEL_ID0
 #define MIPI_DSI_GENERIC_PANEL_ID  1

+/*
+ * PMIC vs SoC Backlight support specified in pwm_blc
+ * field in mipi_config block below.
+*/
+#define PPS_BLC_PMIC   0
+#define PPS_BLC_SOC1
+
 struct mipi_config {
u16 panel_id;

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b5a5558..c4db74a 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "i915_drv.h"
 #include "intel_drv.h"
 #include "intel_dsi.h"
@@ -415,6 +416,12 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)

DRM_DEBUG_KMS("\n");

+   /* Panel Enable over CRC PMIC */
+   if (intel_dsi->gpio_panel)
+   gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
+
+   msleep(intel_dsi->panel_on_delay);
+
/* Disable DPOunit clock gating, can stall pipe
 * and we need DPLL REFA always enabled */
tmp = I915_READ(DPLL(pipe));
@@ -432,8 +439,6 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)
/* put device in ready state */
intel_dsi_device_ready(encoder);

-   msleep(intel_dsi->panel_on_delay);
-
drm_panel_prepare(intel_dsi->panel);

for_each_dsi_port(port, intel_dsi->ports)
@@ -576,6 +581,10 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder)

msleep(intel_dsi->panel_off_delay);
msleep(intel_dsi->panel_pwr_cycle_delay);
+
+   /* Panel Disable over CRC PMIC */
+   if (intel_dsi->gpio_panel)
+   gpiod_set_value_cansleep(intel_dsi->gpio_panel, 0);
 }

 static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
@@ -955,6 +964,11 @@ static void intel_dsi_encoder_destroy(struct drm_encoder 
*encoder)
/* XXX: Logically this call belongs in the panel driver. */
drm_panel_remove(intel_dsi->panel);
}
+
+   /* dispose of the gpios */
+   if (intel_dsi->gpio_panel)
+   gpiod_put(intel_dsi->gpio_panel);
+
intel_encoder_destroy(encoder);
 }

@@ -1071,6 +1085,20 @@ void intel_dsi_init(struct drm_device *dev)
goto err;
}

+   /*
+* In case of BYT with CRC PMIC, we need to use GPIO for
+* Panel control.
+*/
+   if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {
+   intel_dsi->gpio_panel =
+   gpiod_get(dev->dev, "panel", GPIOD_OUT_HIGH);
+
+   if (IS_ERR(intel_dsi->gpio_panel)) {
+   DRM_ERROR("Failed to own gpio for panel control\n");
+   intel_dsi->gpio_panel = NULL;
+   }
+   }
+
intel_encoder->type = INTEL_OUTPUT_DSI;
intel_encoder->cloneable = 0;
drm_connector_init(dev, connector, _dsi_connector_funcs,
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 2784ac4..42a6859 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -42,6 +42,9 @@ struct intel_dsi {
struct drm_panel *panel;
struct intel_dsi_host *dsi_hosts[I915_MAX_PORTS];

+   /* GPIO Desc for CRC based Panel control */
+   struct gpio_desc *gpio_panel;
+
struct intel_connector *attached_connector;

/* bit mask of ports being driven */
-- 
1.9.1

[v2 5/7] pwm: crc: Add Crystalcove (CRC) PWM driver

The Crystalcove PMIC provides three PWM signals and this driver exports
one of them on the BYT platform which is used to control backlight for
DSI panel. This is platform device implementation of the drivers/mfd
cell device for CRC PMIC.

v2: Use the existing config callback with duty_ns and period_ns(Thierry)

v3: Correct the subject line (Lee jones)

v4: Address comment by Thierry & Paul
- Commit message update and fixes for few syntax errors
- Add PWM_CRC in Kconfig and Makefile sorted alphabetically
- Use the PWM_BASE_CLK as 600 for better code readability
- Remove the redundant rule of three while calculating pwm level
- Use the platform_device in pwm_chip
- Use builin_platform_driver

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Cc: Paul Bolle 
Cc: Paul Gortmaker 
Signed-off-by: Shobhit Kumar 
---
 drivers/pwm/Kconfig   |   7 +++
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-crc.c | 155 ++
 3 files changed, 163 insertions(+)
 create mode 100644 drivers/pwm/pwm-crc.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index b1541f4..948d9ab 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -111,6 +111,13 @@ config PWM_CLPS711X
  To compile this driver as a module, choose M here: the module
  will be called pwm-clps711x.

+config PWM_CRC
+   bool "Intel Crystalcove (CRC) PWM support"
+   depends on X86 && INTEL_SOC_PMIC
+   help
+ Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
+ control.
+
 config PWM_EP93XX
tristate "Cirrus Logic EP93xx PWM support"
depends on ARCH_EP93XX
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index ec50eb5..d186f35 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PWM_BCM_KONA)  += pwm-bcm-kona.o
 obj-$(CONFIG_PWM_BCM2835)  += pwm-bcm2835.o
 obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
 obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
+obj-$(CONFIG_PWM_CRC)  += pwm-crc.o
 obj-$(CONFIG_PWM_EP93XX)   += pwm-ep93xx.o
 obj-$(CONFIG_PWM_FSL_FTM)  += pwm-fsl-ftm.o
 obj-$(CONFIG_PWM_IMG)  += pwm-img.o
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
new file mode 100644
index 000..dcd9782
--- /dev/null
+++ b/drivers/pwm/pwm-crc.c
@@ -0,0 +1,155 @@
+/*
+ * Copyright (C) 2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Author: Shobhit Kumar 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define PWM0_CLK_DIV   0x4B
+#define  PWM_OUTPUT_ENABLE (1 << 7)
+#define  PWM_DIV_CLK_0 0x00 /* DIVIDECLK = BASECLK */
+#define  PWM_DIV_CLK_100   0x63 /* DIVIDECLK = BASECLK/100 */
+#define  PWM_DIV_CLK_128   0x7F /* DIVIDECLK = BASECLK/128 */
+
+#define PWM0_DUTY_CYCLE0x4E
+#define BACKLIGHT_EN   0x51
+
+#define PWM_MAX_LEVEL  0xFF
+
+#define PWM_BASE_CLK   600  /* 6 MHz */
+#define PWM_MAX_PERIOD_NS  21333/* 46.875KHz */
+
+/**
+ * struct crystalcove_pwm - Crystal Cove PWM controller
+ * @chip: the abstract pwm_chip structure.
+ * @regmap: the regmap from the parent device.
+ */
+struct crystalcove_pwm {
+   struct pwm_chip chip;
+   struct regmap *regmap;
+};
+
+static inline struct crystalcove_pwm *to_crc_pwm(struct pwm_chip *pc)
+{
+   return container_of(pc, struct crystalcove_pwm, chip);
+}
+
+static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
+{
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+
+   regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
+
+   return 0;
+}
+
+static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
+{
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+
+   regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
+}
+
+static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+   struct device *dev = crc_pwm->chip.dev;
+   int level;
+
+   if (period_ns > PWM_MAX_PERIOD_NS) {
+   dev_err(dev, "un-supported period_ns\n");
+   return -EINVAL;
+   }
+
+   if (pwm->period != period_ns) {
+   int clk_div;
+
+   /* changing the clk divisor, need to disable fisrt */
+   crc_pwm_disable(c, pwm);
+   clk_div = PWM_BASE_CLK * period_ns / NSEC_PER_SEC;
+
+

[v2 4/7] mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM

On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
entry for the same to be used by the consumer (Intel GFX)

v2: Remove the lookup table on driver unload (Thierry)

v3: Correct the subject line (Lee jones)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Acked-by: Lee Jones 
Signed-off-by: Shobhit Kumar 
---
 drivers/mfd/intel_soc_pmic_core.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/mfd/intel_soc_pmic_core.c 
b/drivers/mfd/intel_soc_pmic_core.c
index f3d918e..a00ddd9 100644
--- a/drivers/mfd/intel_soc_pmic_core.c
+++ b/drivers/mfd/intel_soc_pmic_core.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_soc_pmic_core.h"

 /* Lookup table for the Panel Enable/Disable line as GPIO signals */
@@ -37,6 +38,11 @@ static struct gpiod_lookup_table panel_gpio_table = {
},
 };

+/* PWM consumed by the Intel GFX */
+static struct pwm_lookup crc_pwm_lookup[] = {
+   PWM_LOOKUP("crystal_cove_pwm", 0, ":00:02.0", "pwm_backlight", 0, 
PWM_POLARITY_NORMAL),
+};
+
 static int intel_soc_pmic_find_gpio_irq(struct device *dev)
 {
struct gpio_desc *desc;
@@ -99,6 +105,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
/* Add lookup table binding for Panel Control to the GPIO Chip */
gpiod_add_lookup_table(_gpio_table);

+   /* Add lookup table for crc-pwm */
+   pwm_add_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
+
ret = mfd_add_devices(dev, -1, config->cell_dev,
  config->n_cell_devs, NULL, 0,
  regmap_irq_get_domain(pmic->irq_chip_data));
@@ -121,6 +130,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client *i2c)
/* Remove lookup table for Panel Control from the GPIO Chip */
gpiod_remove_lookup_table(_gpio_table);

+   /* remove crc-pwm lookup table */
+   pwm_remove_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
+
mfd_remove_devices(>dev);

return 0;
-- 
1.9.1

[v2 3/7] mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC

Needed for PWM control suuported by the PMIC

v2: Correct the subject line (Lee jones)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Acked-by: Lee Jones 
Signed-off-by: Shobhit Kumar 
---
 drivers/mfd/intel_soc_pmic_crc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
index 7436075..4a74948 100644
--- a/drivers/mfd/intel_soc_pmic_crc.c
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -109,6 +109,9 @@ static struct mfd_cell crystal_cove_dev[] = {
{
.name = "crystal_cove_pmic",
},
+   {
+   .name = "crystal_cove_pwm",
+   },
 };

 static const struct regmap_config crystal_cove_regmap_config = {
-- 
1.9.1

[v2 2/7] mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO signal

On some Intel SoC platforms, the panel enable/disable signals are
controlled by CRC PMIC. Add those control as a new GPIO in a lookup
table for gpio-crystalcove chip during CRC driver load

v2: Make the lookup table static (Thierry)
Remove the lookup table during driver remove (Thierry)

v3: Correct the subject line (Lee jones)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Acked-by: Lee Jones 
Acked-by: Linus Walleij 
Signed-off-by: Shobhit Kumar 
---
 drivers/mfd/intel_soc_pmic_core.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mfd/intel_soc_pmic_core.c 
b/drivers/mfd/intel_soc_pmic_core.c
index 7b50b6b..f3d918e 100644
--- a/drivers/mfd/intel_soc_pmic_core.c
+++ b/drivers/mfd/intel_soc_pmic_core.c
@@ -24,8 +24,19 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_soc_pmic_core.h"

+/* Lookup table for the Panel Enable/Disable line as GPIO signals */
+static struct gpiod_lookup_table panel_gpio_table = {
+   /* Intel GFX is consumer */
+   .dev_id = ":00:02.0",
+   .table = {
+   /* Panel EN/DISABLE */
+   GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH),
+   },
+};
+
 static int intel_soc_pmic_find_gpio_irq(struct device *dev)
 {
struct gpio_desc *desc;
@@ -85,6 +96,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
if (ret)
dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret);

+   /* Add lookup table binding for Panel Control to the GPIO Chip */
+   gpiod_add_lookup_table(_gpio_table);
+
ret = mfd_add_devices(dev, -1, config->cell_dev,
  config->n_cell_devs, NULL, 0,
  regmap_irq_get_domain(pmic->irq_chip_data));
@@ -104,6 +118,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client *i2c)

regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);

+   /* Remove lookup table for Panel Control from the GPIO Chip */
+   gpiod_remove_lookup_table(_gpio_table);
+
mfd_remove_devices(>dev);

return 0;
-- 
1.9.1

[v2 1/7] gpiolib: Add support for removing registered consumer lookup table

In case we unload and load a driver module again that is registering a
lookup table, without this it will result in multiple entries. Provide
an option to remove the lookup table on driver unload

v2: Ccing maintainers
v3: Correct the subject line (Lee jones)

Cc: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Reviewed-by: Alexandre Courbot 
Reviewed-by: Linus Walleij 
Signed-off-by: Shobhit Kumar 
---
 drivers/gpio/gpiolib.c   | 13 +
 include/linux/gpio/machine.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 957ede5..9d3ea4e 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1675,6 +1675,19 @@ void gpiod_add_lookup_table(struct gpiod_lookup_table 
*table)
mutex_unlock(_lookup_lock);
 }

+/**
+ * gpiod_remove_lookup_table() - unregister GPIO device consumers
+ * @table: table of consumers to unregister
+ */
+void gpiod_remove_lookup_table(struct gpiod_lookup_table *table)
+{
+   mutex_lock(_lookup_lock);
+
+   list_del(>list);
+
+   mutex_unlock(_lookup_lock);
+}
+
 static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
  unsigned int idx,
  enum gpio_lookup_flags *flags)
diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
index e270614..c0d712d 100644
--- a/include/linux/gpio/machine.h
+++ b/include/linux/gpio/machine.h
@@ -57,5 +57,6 @@ struct gpiod_lookup_table {
 }

 void gpiod_add_lookup_table(struct gpiod_lookup_table *table);
+void gpiod_remove_lookup_table(struct gpiod_lookup_table *table);

 #endif /* __LINUX_GPIO_MACHINE_H */
-- 
1.9.1

[v2 0/7] Crystalcove (CRC) PMIC based panel and pwm control

Hi All,
On some of the BYT devices, for DSI panels, the panel enable/disable signals
and backlight control are done using the Crystalcove PMIC. This series provides
support for the same and has been reviewed earlier on -
https://lkml.org/lkml/2015/4/29/301

This series addresses the review comments with one patch from last set already 
merged as -
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=efb0de55b6a2ec15fc424e660601f22ae2fa487a

Basically following are implemented -

1. GPIO control for panel enable/disable with GFX device as consumer
2. New PWM chip driver added for CRC PMIC based backlight control
3. i915 is modified to use the CRC gpio chip and the CRC PWM chip to do
   backlight control. This is now added in the generic panel backlight
   control infrastructure

All these patches have been tested on AsusT100 and working fine using
/sys/class/backlight/intel_backlight interface.

Patches were also verified on android-x86 tree for AsusT100.

Regards
Shobhit

Shobhit Kumar (7):
  gpiolib: Add support for removing registered consumer lookup table
  mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO
signal
  mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC
  mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM
  pwm: crc: Add Crystalcove (CRC) PWM driver
  drm/i915: Use the CRC gpio for panel enable/disable
  drm/i915: Backlight control using CRC PMIC based PWM driver

 drivers/gpio/gpiolib.c |  13 
 drivers/gpu/drm/i915/intel_bios.h  |   7 ++
 drivers/gpu/drm/i915/intel_drv.h   |   4 +
 drivers/gpu/drm/i915/intel_dsi.c   |  38 -
 drivers/gpu/drm/i915/intel_dsi.h   |   3 +
 drivers/gpu/drm/i915/intel_panel.c |  95 +--
 drivers/mfd/intel_soc_pmic_core.c  |  29 +++
 drivers/mfd/intel_soc_pmic_crc.c   |   3 +
 drivers/pwm/Kconfig|   7 ++
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-crc.c  | 155 +
 include/linux/gpio/machine.h   |   1 +
 12 files changed, 349 insertions(+), 7 deletions(-)
 create mode 100644 drivers/pwm/pwm-crc.c

-- 
1.9.1

[Intel-gfx] [v2 4/7] mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM

On Mon, Jun 22, 2015 at 04:33:22PM +0530, Varka Bhadram wrote:
> Hi Shobhit Kumar,
> 
> On 06/22/2015 04:24 PM, Shobhit Kumar wrote:
> 
> >On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
> >entry for the same to be used by the consumer (Intel GFX)
> >
> >v2: Remove the lookup table on driver unload (Thierry)
> >
> >v3: Correct the subject line (Lee jones)
> 
> This part should only describe what this is about..
> 
> Don't put this patch change history over here.
> Include this change history after
> ...
> Signed-off-by: Author 
> ---
> 
> >CC: Samuel Ortiz 
> >Cc: Linus Walleij 
> >Cc: Alexandre Courbot 
> >Cc: Thierry Reding 
> >Acked-by: Lee Jones 
> >Signed-off-by: Shobhit Kumar 
> >---
> 
> Here you add this change history so that after applying this
> will not be the part of your commit description.
> 
> This comment is applicable for all of your patches.

It's honestly a per-maintainer thing and hard to tell who wants what ...
Personally I do want to include the patch changelog in the commit message.
-Daniel
> 
> 
> -- 
> Best regards,
> Varka Bhadram.
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/msm/mdp5: release SMB(shared memory blocks) in various cases


On 06/19/2015 11:33 PM, Wentao Xu wrote:
> Release all blocks after the pipe is disabled, even when vsync
> didn't happen in some error cases. Allow requesting SMB multiple
> times before configuring to hardware, by releasing blocks not
> programmed to hardware yet for shrinking case.

Tested-by: Archit Taneja 

>
> Signed-off-by: Wentao Xu 
> ---
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 13 +
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  2 +
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 33 +---
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c   | 87 
> ++-
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.h   |  1 +
>   5 files changed, 104 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> index 97226a1..db49ee8 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> @@ -78,7 +78,20 @@ static void mdp5_prepare_commit(struct msm_kms *kms, 
> struct drm_atomic_state *st
>
>   static void mdp5_complete_commit(struct msm_kms *kms, struct 
> drm_atomic_state *state)
>   {
> + int i;
>   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
> + int nplanes = mdp5_kms->dev->mode_config.num_total_plane;
> +
> + for (i = 0; i < nplanes; i++) {
> + struct drm_plane *plane = state->planes[i];
> + struct drm_plane_state *plane_state = state->plane_states[i];
> +
> + if (!plane)
> + continue;
> +
> + mdp5_plane_complete_commit(plane, plane_state);
> + }
> +
>   mdp5_disable(mdp5_kms);
>   }
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> index 2c0de17..42f270b 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> @@ -227,6 +227,8 @@ void mdp5_plane_install_properties(struct drm_plane 
> *plane,
>   struct drm_mode_object *obj);
>   uint32_t mdp5_plane_get_flush(struct drm_plane *plane);
>   void mdp5_plane_complete_flip(struct drm_plane *plane);
> +void mdp5_plane_complete_commit(struct drm_plane *plane,
> + struct drm_plane_state *state);
>   enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane);
>   struct drm_plane *mdp5_plane_init(struct drm_device *dev,
>   enum mdp5_pipe pipe, bool private_plane, uint32_t reg_offset);
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> index 18a3d20..05b2634 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> @@ -31,8 +31,6 @@ struct mdp5_plane {
>
>   uint32_t nformats;
>   uint32_t formats[32];
> -
> - bool enabled;
>   };
>   #define to_mdp5_plane(x) container_of(x, struct mdp5_plane, base)
>
> @@ -56,22 +54,6 @@ static bool plane_enabled(struct drm_plane_state *state)
>   return state->fb && state->crtc;
>   }
>
> -static int mdp5_plane_disable(struct drm_plane *plane)
> -{
> - struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
> - struct mdp5_kms *mdp5_kms = get_kms(plane);
> - enum mdp5_pipe pipe = mdp5_plane->pipe;
> -
> - DBG("%s: disable", mdp5_plane->name);
> -
> - if (mdp5_kms) {
> - /* Release the memory we requested earlier from the SMP: */
> - mdp5_smp_release(mdp5_kms->smp, pipe);
> - }
> -
> - return 0;
> -}
> -
>   static void mdp5_plane_destroy(struct drm_plane *plane)
>   {
>   struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
> @@ -224,7 +206,6 @@ static void mdp5_plane_atomic_update(struct drm_plane 
> *plane,
>
>   if (!plane_enabled(state)) {
>   to_mdp5_plane_state(state)->pending = true;
> - mdp5_plane_disable(plane);
>   } else if (to_mdp5_plane_state(state)->mode_changed) {
>   int ret;
>   to_mdp5_plane_state(state)->pending = true;
> @@ -602,6 +583,20 @@ uint32_t mdp5_plane_get_flush(struct drm_plane *plane)
>   return mdp5_plane->flush_mask;
>   }
>
> +/* called after vsync in thread context */
> +void mdp5_plane_complete_commit(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct mdp5_kms *mdp5_kms = get_kms(plane);
> + struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
> + enum mdp5_pipe pipe = mdp5_plane->pipe;
> +
> + if (!plane_enabled(plane->state)) {
> + DBG("%s: free SMP", mdp5_plane->name);
> + mdp5_smp_release(mdp5_kms->smp, pipe);
> + }
> +}
> +
>   /* initialize plane */
>   struct drm_plane *mdp5_plane_init(struct drm_device *dev,
>   enum mdp5_pipe pipe, bool private_plane, uint32_t reg_offset)
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
> index 16702ae..64a27d8 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
> +++

Linux 4.1 WARNING in drm_ioctl.c

2015-06-22 Thread Fabio Coatti

Hi All,

just compiled 4.1 and just got this warning, twice, in my dmesg:


[lun giu 22 11:43:18 2015] [ cut here ]
[lun giu 22 11:43:18 2015] WARNING: CPU: 1 PID: 2184 at 
drivers/gpu/drm/drm_ioctl.c:144 drm_setversion+0xe1/0x179()
[lun giu 22 11:43:18 2015] No drm_driver.set_busid() implementation provided 
by 0x81ec3980. Use drm_dev_set_unique() to set the unique name 
explicitly.
[lun giu 22 11:43:18 2015] Modules linked in:
[lun giu 22 11:43:18 2015]  bnep algif_skcipher cdc_wdm cdc_acm uvcvideo 
videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev btusb 
btbcm btintel bluetooth hp_wmi sparse_keymap intel_rapl iosf_mbi 
x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi coretemp kvm_intel 
kvm snd_hda_codec_generic crct10dif_pclmul crc32_pclmul snd_hda_intel iwldvm 
snd_hda_controller snd_hda_codec snd_hwdep psmouse snd_hda_core iwlwifi 
snd_pcm snd_timer snd soundcore wmi hp_accel(+) hp_wireless lis3lv02d 
sch_fq_codel dm_zero dm_persistent_data dm_service_time dm_round_robin 
dm_queue_length dm_multipath dm_delay virtio_pci virtio_blk virtio_balloon 
virtio_ring virtio fuse overlay linear raid0 dm_raid dm_snapshot dm_bufio 
dm_mirror dm_region_hash dm_log ohci_pci ohci_hcd uhci_hcd
[lun giu 22 11:43:18 2015] CPU: 1 PID: 2184 Comm: X Tainted: GW   
4.1.0 #1
[lun giu 22 11:43:18 2015] Hardware name: Hewlett-Packard HP EliteBook Folio 
9470m/18DF, BIOS 68IBD Ver. F.40 02/01/2013
[lun giu 22 11:43:18 2015]   0009 818d8bfd 
8800b226fd38
[lun giu 22 11:43:18 2015]  810c5426 880235437240 8152870c 
8800b2f16000
[lun giu 22 11:43:18 2015]  880234ffc000 8800b226fdf0 8800b2c8f300 
c0106407
[lun giu 22 11:43:18 2015] Call Trace:
[lun giu 22 11:43:18 2015]  [] ? dump_stack+0x47/0x67
[lun giu 22 11:43:18 2015]  [] ? 
warn_slowpath_common+0x9d/0xb5
[lun giu 22 11:43:18 2015]  [] ? drm_setversion+0xe1/0x179
[lun giu 22 11:43:18 2015]  [] ? warn_slowpath_fmt+0x4a/0x4f
[lun giu 22 11:43:18 2015]  [] ? drm_setversion+0xe1/0x179
[lun giu 22 11:43:18 2015]  [] ? drm_ioctl+0x376/0x3dd
[lun giu 22 11:43:18 2015]  [] ? drm_version+0x8d/0x8d
[lun giu 22 11:43:18 2015]  [] ? do_filp_open+0x30/0x74
[lun giu 22 11:43:18 2015]  [] ? do_vfs_ioctl+0x379/0x431
[lun giu 22 11:43:18 2015]  [] ? __fd_install+0x20/0x52
[lun giu 22 11:43:18 2015]  [] ? do_sys_open+0x1c0/0x1d2
[lun giu 22 11:43:18 2015]  [] ? SyS_ioctl+0x3e/0x5a
[lun giu 22 11:43:18 2015]  [] ? 
system_call_fastpath+0x16/0x6e
[lun giu 22 11:43:18 2015] ---[ end trace 46364eedd82ef148 ]---

It does not seems to affect normal behaviour, but maybe the report could be 
interesting for maintainers.

Sorry if this has already been reported; if more information is needed just 
let me know (please CC: me as I'm not subscribed to lists.)

Many thanks.

-- 
Fabio

[Intel-gfx] [PATCH 2/5] drm/i915/irq: abstract irq storm hotplug disabling

On Thu, Jun 18, 2015 at 01:06:14PM +0300, Jani Nikula wrote:
> Continue abstracting hotplug storm related functions to clarify the
> code. This time, abstract hotplug irq storm related hotplug
> disabling. While at it, clean up the loop iterating over connectors for
> readability.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 77 
> ++---
>  1 file changed, 50 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index d64d6895a2e5..bf4c15d0ea2b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -879,7 +879,7 @@ static void i915_digport_work_func(struct work_struct 
> *work)
>  /*
>   * Handle hotplug events outside the interrupt handler proper.
>   */
> -#define I915_REENABLE_HOTPLUG_DELAY (2*60*1000)
> +static void intel_hpd_irq_storm_disable(struct drm_i915_private *dev_priv);
>  
>  static void i915_hotplug_work_func(struct work_struct *work)
>  {
> @@ -890,7 +890,6 @@ static void i915_hotplug_work_func(struct work_struct 
> *work)
>   struct intel_connector *intel_connector;
>   struct intel_encoder *intel_encoder;
>   struct drm_connector *connector;
> - bool hpd_disabled = false;
>   bool changed = false;
>   u32 hpd_event_bits;
>  
> @@ -901,31 +900,9 @@ static void i915_hotplug_work_func(struct work_struct 
> *work)
>  
>   hpd_event_bits = dev_priv->hotplug.event_bits;
>   dev_priv->hotplug.event_bits = 0;
> - list_for_each_entry(connector, _config->connector_list, head) {

Random comment: We have piles of connector_list walking in probe codde,
and DP MST adds/removes them without much thought really users of these.
Dave? Do we need a connector_list spinlock?

Just grabbing one of the modeset locks won't cut it I think since it'll
serialize way too much.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/2] drm/dp/mst: take lock around looking up the branch device on hpd irq

From: Dave Airlie 

If we are doing an MST transaction and we've gotten HPD and we
lookup the device from the incoming msg, we should take the mgr
lock around it, so that mst_primary and mstb->ports are valid.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 3c7e5cd..15a6d8e 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1175,6 +1175,8 @@ static struct drm_dp_mst_branch 
*drm_dp_get_mst_branch_device(struct drm_dp_mst_
struct drm_dp_mst_port *port;
int i;
/* find the port by iterating down */
+
+   mutex_lock(>lock);
mstb = mgr->mst_primary;

for (i = 0; i < lct - 1; i++) {
@@ -1194,6 +1196,7 @@ static struct drm_dp_mst_branch 
*drm_dp_get_mst_branch_device(struct drm_dp_mst_
}
}
kref_get(>kref);
+   mutex_unlock(>lock);
return mstb;
 }

-- 
2.4.1

[PATCH 1/2] drm/dp: look up the mstb passed into work function (v2)

From: Dave Airlie 

We should validate the passed in mstb under the lock
this should stop us getting an invalid mstb here.

(first attempt with cancelling work has lockdep issues).
Bugzilla: https://bugs.archlinux.org/task/45369

v2: update bugzilla, add some notes on why passing mst_primary
is okay.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index fb65f5d..3c7e5cd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1198,9 +1198,14 @@ static struct drm_dp_mst_branch 
*drm_dp_get_mst_branch_device(struct drm_dp_mst_
 }

 static void drm_dp_check_and_send_link_address(struct drm_dp_mst_topology_mgr 
*mgr,
-  struct drm_dp_mst_branch *mstb)
+  struct drm_dp_mst_branch 
*mstb_in)
 {
struct drm_dp_mst_port *port;
+   struct drm_dp_mst_branch *mstb;
+
+   mstb = drm_dp_get_validated_mstb_ref(mgr, mstb_in);
+   if (!mstb)
+   return;

if (!mstb->link_address_sent) {
drm_dp_send_link_address(mgr, mstb);
@@ -1219,12 +1224,20 @@ static void drm_dp_check_and_send_link_address(struct 
drm_dp_mst_topology_mgr *m
if (port->mstb)
drm_dp_check_and_send_link_address(mgr, port->mstb);
}
+   drm_dp_put_mst_branch_device(mstb);
 }

 static void drm_dp_mst_link_probe_work(struct work_struct *work)
 {
struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct 
drm_dp_mst_topology_mgr, work);
-
+   /*
+* Note this passes mgr->mst_primary without validation
+* it could be a) valid, b) NULL, c) some value between
+* since we haven't taken the lock,
+* however the validation sequence in check and send
+* will take the lock, and if the value isn't valid
+* it will fail appropriately.
+*/
drm_dp_check_and_send_link_address(mgr, mgr->mst_primary);

 }
-- 
2.4.1

[PATCH] drm/dp: look up the mstb passed into work function

On 20 June 2015 at 01:42, Daniel Vetter  wrote:
> On Fri, Jun 19, 2015 at 10:53:10AM +1000, Dave Airlie wrote:
>> From: Dave Airlie 
>>
>> We should validate the passed in mstb under the lock
>> this should stop us getting an invalid mstb here.
>>
>> (first attempt with cancelling work has lockdep issues).
>
> Yeah cancel_work_sync is nasty that way ;-)
>
> Btw random bikeshed, but mgr->work would look nice as mgr->probe_work.
>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89366
> Bugzilla: https://bugs.archlinux.org/task/45369
>
> seems the more accurate one, the fdo one is a mess.

yes probably.

> I am a bit concerned about the lifetime rules of the mgr->mst_primary
> pointer. port->mstb is controlled by the lifetime of the port and that by
> the parent mst branch, so I think we're covered dereferencing that one.
>
> But mgr->mst_primary seems to be protected only by mgr->lock, and you're
> not holding that in the probe work. I did review
> drm_dp_mst_topology_mgr_set_mst and that does seem to clean up
> ->mst_primary correctly but might be helped with a comment. But we do need
> the locking I think.

That won't work as we take the lock to do the lookups later,

It doesn't actually matter if mgr->mst_primary gets messed up here I
don't think,
as long as we validate it. So the value is going to be either a)
correct, b) NULL,
c) garbage between a and b assuming its not atomic, the validate function
locks the mgr, and checks primary, at this point primary will either be a or b
as we hold the lock, and if primary from outside the function is a, b or c won't
matter as the validation will either pass or fail depending on the
state under the
lock.

Though in reviewing that I did find another bug with primary which
I'll send another fix for.

Dave.

[PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off

We should never nest these since in theory kms drivers should know
when a pipe is on/off and call the corresponding enable/disable
functions for the vblank helper code only once. But for historical
reasons (the shared-with-ums version of this code in modeset_pre/post
needed to be able to cope with silly userspace that lost track of
things) we still have this bit of "robustness" around.

Enforce this with a WARN_ON, preparing to eventually rip out this
special handling.

Cc: Yogesh Mohan Marimuthu 
Cc: Gaurav K Singh 
Cc: Michel DÃ¤nzer 
Cc: Ville SyrjÃ¤lÃ¤ 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index f9cc68fbd2a3..3819465abe22 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1219,6 +1219,8 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
vblank_disable_and_save(dev, crtc);
wake_up(>queue);

+   WARN_ON(vblank->inmodeset);
+
/*
 * Prevent subsequent drm_vblank_get() from re-enabling
 * the vblank interrupt by bumping the refcount.
@@ -1318,6 +1320,8 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
return;

spin_lock_irqsave(>vbl_lock, irqflags);
+   WARN_ON(!vblank->inmodeset);
+
/* Drop our private "prevent drm_vblank_get" refcount */
if (vblank->inmodeset) {
atomic_dec(>refcount);
-- 
2.1.4

[Bug 91045] problems with 10.6.x and glamor

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

--- Comment #3 from gabriele balducci  ---
(In reply to Michel DÃ¤nzer from comment #2)
> > (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
> > (II) Module glamoregl: vendor="X.Org Foundation"
> > compiled for 1.17.0, module version = 0.6.0
> 
> You're using the old standalone glamor. Please try current glamor from the
> xserver tree (if you build xserver yourself, make sure --enable-glamor is
> passed to its configure script).

thanks a lot: everything is working nicely again (10.6.0+glamor)
apologies for the noise

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/7067d03a/attachment-0001.html>

[PATCH] configure.ac: bump version to 2.4.62

2015-06-22 Thread Alexandre Courbot

Increase version number so Mesa can check against it before using the
new NOUVEAU_GEM_DOMAIN_COHERENT flag.

Signed-off-by: Alexandre Courbot 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 78a0010..e48fb7e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@

 AC_PREREQ([2.63])
 AC_INIT([libdrm],
-[2.4.61],
+[2.4.62],
 [https://bugs.freedesktop.org/enter_bug.cgi?product=DRI],
 [libdrm])

-- 
2.4.4

[PULL] topic/drm-misc

Hi Dave,

One more drm-misc pull for 4.2. The important one is the fix from Laurent
for Daniel Stone's mode_blob work.

Cheers, Daniel


The following changes since commit b9a1077a4e8f6961df8fd393fad2265249f015c5:

  Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into 
drm-next (2015-06-12 10:17:55 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-06-22

for you to fetch changes up to c30f55a7b1336cdfeac74c7931ebff40a32e72b7:

  drm/atomic: Don't set crtc_state->enable manually (2015-06-22 13:45:33 +0200)


Chris Wilson (1):
  drm: Avoid the double clflush on the last cache line in 
drm_clflush_virt_range()

Daniel Thompson (1):
  drm: prime: Document gem_prime_mmap

Daniel Vetter (1):
  drm/atomic: Extract needs_modeset function

Laurent Pinchart (1):
  drm/atomic: Don't set crtc_state->enable manually

Magnus Damm (1):
  drm/cma: Fix 64-bit size_t build warnings

Sonika Jindal (1):
  Documentation/drm: Update rotation property

 Documentation/DocBook/drm.tmpl   | 41 
 drivers/gpu/drm/drm_atomic.c |  3 +--
 drivers/gpu/drm/drm_atomic_helper.c  | 26 +++
 drivers/gpu/drm/drm_cache.c  |  5 +++--
 drivers/gpu/drm/drm_gem_cma_helper.c |  4 ++--
 drivers/gpu/drm/drm_prime.c  |  4 +++-
 include/drm/drm_atomic.h |  6 ++
 7 files changed, 45 insertions(+), 44 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2] drm/atomic: Don't set crtc_state->enable manually

On Mon, Jun 22, 2015 at 01:37:46PM +0300, Laurent Pinchart wrote:
> The enable field needs to be kept in sync with the mode_blob field. Call
> drm_atomic_set_mode_prop_for_crtc() instead of setting enable to false
> in order to dereference the mode blob correctly.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> Changes since v1:
> 
> - Check the return value of drm_atomic_set_mode_prop_for_crtc()
> - Drop the num_connectors local variable

Random process bikeshed: I'm one of the kernel maintainers who prefers to
keep the per-patch changelog (since often submitters fail to reflect all
the discussion properly in the commit message itself).

Fixed that and applied your patch to drm-misc, thanks.
-Daniel

> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 536ae4da4665..ec3d65a497ac 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1561,10 +1561,14 @@ static int update_output_state(struct 
> drm_atomic_state *state,
>   if (crtc == set->crtc)
>   continue;
>  
> - crtc_state->enable =
> - drm_atomic_connectors_for_crtc(state, crtc);
> - if (!crtc_state->enable)
> + if (!drm_atomic_connectors_for_crtc(state, crtc)) {
> + ret = drm_atomic_set_mode_prop_for_crtc(crtc_state,
> + NULL);
> + if (ret < 0)
> + return ret;
> +
>   crtc_state->active = false;
> + }
>   }
>  
>   return 0;
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Color management in DRM framework

2015-06-22 Thread Sharma, Shashank

Hi Rob, Alex, Ben, All :)

I am Shashank Sharma, from Linux display team Intel, Bangalore.
We are planning to add a color management extension in the existing I915
driver, for Intel HWs.
Plan was to provide a color correction and enhancement interface for any Linux
based userspace, based on various HW capabilities.

We are now thinking that if we can generalize this implementation, in such a
way that other drivers can also utilize this, this idea can act as an extension
to the DRM framework itself.
Based on that thought, We have prepared a design for the same, and a rough
implementation based on this design.

Would you all be kind enough to have a look at this design, and give us some
feedback, so that we can implement this in a way best suitable to most of the
drivers ?
We have gone through few rounds of design discussions internally (design
contributors, reviewers in CC), and we all are moreover agree on the design
(few comments still in progress).

The highlights of the design:

1. The color correction capabilities of a HW are being registered as a
DRM property of a CRTC / Plane (depending on a HW)

2. Properties will be of blob type.

3. New data structures will be added in DRM layer, to encoder and decode
color correction and enhancement data.

4. The color correction DRM properties would look like :

a. Palette correction / programming based color properties (like gamma
correction). This can support various coefficients counts and correction
values, based on the underneath HW.

b. Color transformation matrix based color correction (CSC, wide and
narrow gamut mapping)

c. Plane level corrections like gamma correction, hue, saturation,
contrast and brightness.

d. One blob type property to showcase the color correction capabilities to
the userspace, superset of all other color correction properties.

5. The driver's init function can create the superset color property, and
show its color capabilities to the userspace.

6. Userspace can query the current color correction Or apply a new color
correction using a set/get property interface.

Please find the detailed design, in this shared google document:
https://docs.google.com/document/d/1jyfNSAStKHEpmIUZd_1Gd68cPuyiyr8wmJXThSDb_2w/
Please feel free to add more people in the design discussion, once we have some
basic agreement on the design, we will share the patches in dri-devel level.

Regards
Shashank

-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150622/e70b07d8/attachment.html>

[PATCH v2] drm/atomic: Don't set crtc_state->enable manually

2015-06-22 Thread Laurent Pinchart

The enable field needs to be kept in sync with the mode_blob field. Call
drm_atomic_set_mode_prop_for_crtc() instead of setting enable to false
in order to dereference the mode blob correctly.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_atomic_helper.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Changes since v1:

- Check the return value of drm_atomic_set_mode_prop_for_crtc()
- Drop the num_connectors local variable

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 536ae4da4665..ec3d65a497ac 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1561,10 +1561,14 @@ static int update_output_state(struct drm_atomic_state 
*state,
if (crtc == set->crtc)
continue;

-   crtc_state->enable =
-   drm_atomic_connectors_for_crtc(state, crtc);
-   if (!crtc_state->enable)
+   if (!drm_atomic_connectors_for_crtc(state, crtc)) {
+   ret = drm_atomic_set_mode_prop_for_crtc(crtc_state,
+   NULL);
+   if (ret < 0)
+   return ret;
+
crtc_state->active = false;
+   }
}

return 0;
-- 
Regards,

Laurent Pinchart

[PULL] drm-intel-next-fixes


Hi Dave, new pull for drm-next/v4.2 with the compiler warnings fixed.

BR,
Jani.

The following changes since commit bf546f8158e2df2656494a475e6235634121c87c:

  drm/i915/skl: Fix DMC API version in firmware file name (2015-06-05 12:08:01 
+0300)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2015-06-22

for you to fetch changes up to 9044a81d1be632251b7ee97ce9a0bf2a97989be6:

  drm/i915: Silence compiler warning (2015-06-22 11:56:17 +0300)


Ander Conselvan de Oliveira (4):
  drm/i915: Don't check modeset state in the hw state force restore path
  drm/i915: Don't update staged config during force restore modesets
  drm/i915: Don't set enabled value of all CRTCs when restoring the mode
  drm/i915: Silence compiler warning

Francisco Jerez (3):
  drm/i915: Fix command parser to validate multiple register access with 
the same command.
  drm/i915: Extend the parser to check register writes against a mask/value 
pair.
  drm/i915: Add SCRATCH1 and ROW_CHICKEN3 to the register whitelist.

Ville SyrjÃ¤lÃ¤ (1):
  drm/i915: Don't skip request retirement if the active list is empty

 drivers/gpu/drm/i915/i915_cmd_parser.c  | 197 +---
 drivers/gpu/drm/i915/i915_drv.h |   5 +
 drivers/gpu/drm/i915/i915_gem.c |   3 -
 drivers/gpu/drm/i915/intel_display.c|  96 
 drivers/gpu/drm/i915/intel_ringbuffer.h |   5 +-
 5 files changed, 185 insertions(+), 121 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver

On Sat, Jun 20, 2015 at 11:34 PM, Paul Gortmaker
 wrote:
> [Re: [Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver] 
> On 20/06/2015 (Sat 13:23) Paul Bolle wrote:
>
>> [Added Paul Gortmaker.]
>>
>> Hi Shobhit,
>>
>> On Fri, 2015-06-19 at 12:16 +0530, Shobhit Kumar wrote:
>> > So what is the exact big problem with this ?
>>
>> The main problem I have is that it's hard to read a submitter's mind.
>> And, I think, in cases like this we need to know if the submitter just
>> made some silly mistake or that the mismatch (between Kconfig type and
>> code) was intentional. So each time such a mismatch is spotted the
>> submitter ought to be asked about it.
>>
>> (I'd guess that one or two new drivers are submitted _each_ day. And
>> these mismatches are quite common. I'd say I receive answers like:
>> - "Oops, yes bool should have been tristate"; or
>> - "Oops, forgot to clean up after noticing tristate didn't work"; or
>> - "I just copy-and-pasted a similar driver, the module stuff isn't
>>   actually needed"
>> at least once a week. Not sure, I don't keep track of this stuff.)
>>
>> Furthermore, it appears that Paul Gortmaker is on a mission to, badly
>> summarized, untangle the module and init code. See for instance
>> https://lkml.org/lkml/2015/5/28/809 and
>> https://lkml.org/lkml/2015/5/31/205 .
>>
>> Now, I don't know whether (other) Paul is bothered by these MODULE_*
>> macros. But Paul did submit a series that adds
>
> Yes, I agree that it would be nice to not see these mismatches,
> regardless of whether we can get away with it or not.
>
>> builtin_platform_driver(), see https://lkml.org/lkml/2015/5/10/131 .
>> That new macro ensures built-in only code doesn't have to use
>> module_platform_driver(), which your patch also uses. So perhaps Paul
>> can explain some of the non-obvious issues caused by built-in only code
>> using module specific constructs.
>
> In  https://lkml.org/lkml/2015/5/10/125 I'd written:
>
>   There are several downsides to this:
>   1) The code can appear modular to a reader of the code, and they
>  won't know if the code really is modular without checking the
>  Makefile and Kconfig to see if compilation is governed by a
>  bool or tristate.
>   2) Coders of drivers may be tempted to code up an __exit function
>  that is never used, just in order to satisfy the required three
>  args of the modular registration function.
>   3) Non-modular code ends up including the  which increases
>  CPP overhead that they don't need.
>   4) It hinders us from performing better separation of the module
>  init code and the generic init code.
>

Okay. Get the idea and the need in terms of clear separation. Its just
that there are quite a few built-in drivers using module
initialization that I assumed its okay.

> The nature of linux means that thousands of developers are reading the
> code every day -- so I think that there is a genuine value in having the
> code convey a clear message on how it was designed to be used.  Only
> using module related headers/macros for genuinely modular code helps us
> (albeit in a small way) towards achieving that.
>
> Looking at this thread, I see that one of the reasons given for this
> code's ambiguous module vs. built-in identity was the observation of a
> similar identity crisis of the related INTEL_SOC_PMIC code. Does that
> not back up the point above about the value in having the code speak for
> itself?  So IMHO we probably should clarify the PMIC code vs. adding
> another example that looks just like it.
>

Okay agree. I think there are quite of them lurking in the sources
which would need correction. For this PWM driver I will take care as
suggested.

Regards
Shobhit

> Paul.
> --
>
>>
>> > I can anyway shove out these macros to end the discussion.
>>
>> I'd rather convince you than annoy you into doing as I suggested.
>>
>> > BTW whether you  buy the argument or not, please do treat yourself
>> > with ice cream for being able to make such a comment.
>>
>> Will do.
>>
>> Thanks,
>>
>>
>> Paul Bolle
>>

[PATCH v5 4/6] drm: bridge/dw_hdmi-i2s-audio: add audio driver

2015-06-22 Thread Paul Bolle

Something I didn't notice in v4, sorry.

On Sat, 2015-06-20 at 00:28 +0800, Yakir Yang wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c

> +#define DRIVER_NAME "dw-hdmi-i2s-audio"

> +MODULE_ALIAS(PLATFORM_MODULE_PREFIX DRIVER_NAME);

0) Side note: this is the first time that PLATFORM_MODULE_PREFIX is used
inside MODULE_ALIAS(). But none of the 1000+ other "platform:" aliases
do that. And neither does 5/6 of this series! That suggests, I think,
that this shouldn't be done.

You could consider adding something like
#define MODULE_ALIAS_PLATFORM(NAME) MODULE_ALIAS(PLATFORM_MODULE_PREFIX 
NAME)

But then, I think, all the current 1000+ platform: aliases should be
converted to that macro. Would that be worth it?

1) Now on to my remark: this alias seems to be only useful if there also
is a struct platform_device with a "dw-hdmi-i2s-audio" name. Because
that platform_device would, badly summarized, fire of a
"MODALIAS=platform:dw-hdmi-i2s-audio" uevent when created. Which, in its
turn, would trigger userspace to load this module, correct?

But I think there's no platform_device with a "dw-hdmi-i2s-audio" name.
So I wonder whether this MODULE_ALIAS() is actually needed. What breaks
if you leave it out?

(Likewise for 5/6, but there the platform_device should have a
"rockchip-hdmi-audio" name.)

Thanks,

Paul Bolle

[PATCH] drm/msm: change to uninterruptible wait in atomic commit

2015-06-22 Thread Wentao Xu

The atomic commit cannot easily undo and return an error once the
state is swapped. Change to uninterruptible wait, and ignore the
timeout error.

Signed-off-by: Wentao Xu 
---
 drivers/gpu/drm/msm/msm_atomic.c |  8 ++--
 drivers/gpu/drm/msm/msm_drv.c| 13 +
 drivers/gpu/drm/msm/msm_drv.h|  4 ++--
 drivers/gpu/drm/msm/msm_gem.c|  2 +-
 4 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 8763918..4386352 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -257,12 +257,8 @@ int msm_atomic_commit(struct drm_device *dev,

timeout = ktime_add(ktime_get(), ms_to_ktime(1000));

-   ret = msm_wait_fence_interruptable(dev, c->fence, );
-   if (ret) {
-   WARN_ON(ret);  // TODO unswap state back?  or??
-   commit_destroy(c);
-   return ret;
-   }
+   /* uninterruptible wait */
+   msm_wait_fence(dev, c->fence, , false);

complete_commit(c);

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 29af5ba..c445522 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -637,8 +637,8 @@ static void msm_debugfs_cleanup(struct drm_minor *minor)
  * Fences:
  */

-int msm_wait_fence_interruptable(struct drm_device *dev, uint32_t fence,
-   ktime_t *timeout)
+int msm_wait_fence(struct drm_device *dev, uint32_t fence,
+   ktime_t *timeout , bool interruptible)
 {
struct msm_drm_private *priv = dev->dev_private;
int ret;
@@ -667,7 +667,12 @@ int msm_wait_fence_interruptable(struct drm_device *dev, 
uint32_t fence,
remaining_jiffies = timespec_to_jiffies();
}

-   ret = wait_event_interruptible_timeout(priv->fence_event,
+   if (interruptible)
+   ret = 
wait_event_interruptible_timeout(priv->fence_event,
+   fence_completed(dev, fence),
+   remaining_jiffies);
+   else
+   ret = wait_event_timeout(priv->fence_event,
fence_completed(dev, fence),
remaining_jiffies);

@@ -850,7 +855,7 @@ static int msm_ioctl_wait_fence(struct drm_device *dev, 
void *data,
return -EINVAL;
}

-   return msm_wait_fence_interruptable(dev, args->fence, );
+   return msm_wait_fence(dev, args->fence, , true);
 }

 static const struct drm_ioctl_desc msm_ioctls[] = {
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index e7c5ea1..4ff0ec9 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -164,8 +164,8 @@ int msm_atomic_commit(struct drm_device *dev,

 int msm_register_mmu(struct drm_device *dev, struct msm_mmu *mmu);

-int msm_wait_fence_interruptable(struct drm_device *dev, uint32_t fence,
-   ktime_t *timeout);
+int msm_wait_fence(struct drm_device *dev, uint32_t fence,
+   ktime_t *timeout, bool interruptible);
 int msm_queue_fence_cb(struct drm_device *dev,
struct msm_fence_cb *cb, uint32_t fence);
 void msm_update_fence(struct drm_device *dev, uint32_t fence);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 9b62201..e73d465 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -460,7 +460,7 @@ int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t 
op, ktime_t *timeout)
if (op & MSM_PREP_NOSYNC)
timeout = NULL;

-   ret = msm_wait_fence_interruptable(dev, fence, timeout);
+   ret = msm_wait_fence(dev, fence, timeout, true);
}

/* TODO cache maintenance */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PULL] drm-intel-next-fixes

On Mon, 22 Jun 2015, Ander Conselvan De Oliveira  
wrote:
> There is
>
> commit bd4b4827acdc00bf9e71f939d160102021d10d4f
> Author: Ander Conselvan de Oliveira
> 
> Date:   Fri May 29 14:28:09 2015 +0300
>
> drm/i915: Silence compiler warning
>
> in -nightly to fix that same issue. I didn't realize this was also
> needed in -next-fixes.

Dave, sorry, I didn't see the warning, gcc 4.9.2 here.

Do you want another pull request with Ander's fix on top?

BR,
Jani.


>
>
> Ander
>
> On Fri, 2015-06-19 at 17:24 +0200, Daniel Vetter wrote:
>> On Fri, Jun 19, 2015 at 01:48:13PM +1000, Dave Airlie wrote:
>> > On 18 June 2015 at 16:04, Jani Nikula  wrote:
>> > >
>> > > Hi Dave, i915 fixes for drm-next/v4.2.
>> > >
>> > > BR,
>> > > Jani.
>> > 
>> > And my gcc says:
>> > 
>> > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:
>> > In function â__intel_set_modeâ:
>> > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11850:14:
>> > warning: âcrtc_stateâ may be used uninitialized in this function
>> > [-Wmaybe-uninitialized]
>> >   return state->mode_changed || state->active_changed;
>> >   ^
>> > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11860:25:
>> > note: âcrtc_stateâ was declared here
>> >   struct drm_crtc_state *crtc_state;
>> >  ^
>> > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11874:6:
>> > warning: âcrtcâ may be used uninitialized in this function
>> > [-Wmaybe-uninitialized]
>> >if (crtc != intel_encoder->base.crtc)
>> >   ^
>> > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11859:19:
>> > note: âcrtcâ was declared here
>> >   struct drm_crtc *crtc;
>> >^
>> > 
>> > No idea if this is true, but I don't think I've seen it before now.
>> > 
>> > gcc 5.1.1 on fedora 22
>> 
>> Yeah this is new with Ander's patches. gcc Doesn't know that we have at
>> least 1 crtc and hence crtc are guaranteed to be initiliazed. I
>> think you should be able to shut it up with
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index e047105837c9..5ade250dc6d7 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -11856,8 +11856,8 @@ intel_modeset_update_state(struct drm_atomic_state 
>> *state)
>>  struct drm_device *dev = state->dev;
>>  struct drm_i915_private *dev_priv = dev->dev_private;
>>  struct intel_encoder *intel_encoder;
>> -struct drm_crtc *crtc;
>> -struct drm_crtc_state *crtc_state;
>> +struct drm_crtc *crtc = NULL;
>> +struct drm_crtc_state *crtc_state = NULL;
>>  struct drm_connector *connector;
>>  int i;
>>  
>> But the entire Finland team is out of office (celebrating solstice), so
>> might be better to wait for Monday for them to confirm. Otherwise just
>> apply this fixup with my ack if you want to send out the merge window pull
>> asap.
>> 
>> Cheers, Daniel
>
>

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v5 4/6] drm: bridge/dw_hdmi-i2s-audio: add audio driver

2015-06-22 Thread Russell King - ARM Linux

On Mon, Jun 22, 2015 at 12:06:04PM +0200, Paul Bolle wrote:
> But I think there's no platform_device with a "dw-hdmi-i2s-audio" name.
> So I wonder whether this MODULE_ALIAS() is actually needed. What breaks
> if you leave it out?

+   } else if (hdmi_readb(hdmi, HDMI_CONFIG0_ID) & HDMI_CONFIG0_I2S) {
+   pdevinfo.name = "dw-hdmi-ahb-audio";

This should be "dw-hdmi-i2s-audio" to avoid picking up on my AHB audio
driver.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PULL] drm-intel-next-fixes

2015-06-22 Thread Ander Conselvan De Oliveira

There is

commit bd4b4827acdc00bf9e71f939d160102021d10d4f
Author: Ander Conselvan de Oliveira

Date:   Fri May 29 14:28:09 2015 +0300

drm/i915: Silence compiler warning

in -nightly to fix that same issue. I didn't realize this was also
needed in -next-fixes.


Ander

On Fri, 2015-06-19 at 17:24 +0200, Daniel Vetter wrote:
> On Fri, Jun 19, 2015 at 01:48:13PM +1000, Dave Airlie wrote:
> > On 18 June 2015 at 16:04, Jani Nikula  wrote:
> > >
> > > Hi Dave, i915 fixes for drm-next/v4.2.
> > >
> > > BR,
> > > Jani.
> > 
> > And my gcc says:
> > 
> > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:
> > In function â__intel_set_modeâ:
> > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11850:14:
> > warning: âcrtc_stateâ may be used uninitialized in this function
> > [-Wmaybe-uninitialized]
> >   return state->mode_changed || state->active_changed;
> >   ^
> > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11860:25:
> > note: âcrtc_stateâ was declared here
> >   struct drm_crtc_state *crtc_state;
> >  ^
> > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11874:6:
> > warning: âcrtcâ may be used uninitialized in this function
> > [-Wmaybe-uninitialized]
> >if (crtc != intel_encoder->base.crtc)
> >   ^
> > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11859:19:
> > note: âcrtcâ was declared here
> >   struct drm_crtc *crtc;
> >^
> > 
> > No idea if this is true, but I don't think I've seen it before now.
> > 
> > gcc 5.1.1 on fedora 22
> 
> Yeah this is new with Ander's patches. gcc Doesn't know that we have at
> least 1 crtc and hence crtc are guaranteed to be initiliazed. I
> think you should be able to shut it up with
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e047105837c9..5ade250dc6d7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11856,8 +11856,8 @@ intel_modeset_update_state(struct drm_atomic_state 
> *state)
>   struct drm_device *dev = state->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_encoder *intel_encoder;
> - struct drm_crtc *crtc;
> - struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc = NULL;
> + struct drm_crtc_state *crtc_state = NULL;
>   struct drm_connector *connector;
>   int i;
>  
> But the entire Finland team is out of office (celebrating solstice), so
> might be better to wait for Monday for them to confirm. Otherwise just
> apply this fixup with my ack if you want to send out the merge window pull
> asap.
> 
> Cheers, Daniel

[PATCH libdrm] configure: Add flag to disable valgrind support.

2015-06-22 Thread Matt Turner

On Mon, Jun 22, 2015 at 10:07 AM, Emil Velikov  
wrote:
> On 22 June 2015 at 16:56, Matt Turner  wrote:
>> ---
>>  configure.ac | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 78a0010..dd6c0ab 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -403,7 +403,15 @@ else
>>  fi
>>  AM_CONDITIONAL([HAVE_MANPAGES_STYLESHEET], [test 
>> "x$HAVE_MANPAGES_STYLESHEET" = "xyes"])
>>
>> -PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
>> [have_valgrind=no])
>> +AC_ARG_ENABLE(valgrind,
>> +  AS_HELP_STRING([--disable-valgrind],
>> + [Disable valgrind support]),
>> + [use_valgrind=$enableval], [use_valgrind=yes])
>> +
>> +if test "x$use_valgrind" = "xyes"; then
>> +   PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
>> [have_valgrind=no])
>> +fi
>> +
> Any objections if we move this to "auto" rather than enabled by
> default (like we do with cairo) ? If you're ok I'll amend the patch
> before pushing.
>
> -Emil

Fine by me!

Thanks Emil.

[PATCH libdrm] configure: Add flag to disable valgrind support.

2015-06-22 Thread Matt Turner

---
 configure.ac | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 78a0010..dd6c0ab 100644
--- a/configure.ac
+++ b/configure.ac
@@ -403,7 +403,15 @@ else
 fi
 AM_CONDITIONAL([HAVE_MANPAGES_STYLESHEET], [test "x$HAVE_MANPAGES_STYLESHEET" 
= "xyes"])

-PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
[have_valgrind=no])
+AC_ARG_ENABLE(valgrind,
+  AS_HELP_STRING([--disable-valgrind],
+ [Disable valgrind support]),
+ [use_valgrind=$enableval], [use_valgrind=yes])
+
+if test "x$use_valgrind" = "xyes"; then
+   PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
[have_valgrind=no])
+fi
+
 if test "x$have_valgrind" = "xyes"; then
AC_DEFINE([HAVE_VALGRIND], 1, [Use valgrind intrinsics to suppress 
false warnings])
 fi
-- 
2.3.6

[PATCH] drm/dp/mst: make sure mst_primary mstb is valid in work function

On Mon, Jun 22, 2015 at 05:31:59PM +1000, Dave Airlie wrote:
> From: Daniel Vetter 
> 
> This validates the mst_primary under the lock, and then calls
> into the check and send function. This makes the code a lot
> easier to understand the locking rules in.
> 
> Signed-off-by: Dave Airlie 

Signed-off-by: Daniel Vetter 
Reviewed-by: Daniel Vetter 

Pick what you like ;-)

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 24 +++-
>  1 file changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index a9c437e..8a3bfcd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1204,7 +1204,7 @@ static void drm_dp_check_and_send_link_address(struct 
> drm_dp_mst_topology_mgr *m
>  struct drm_dp_mst_branch *mstb)
>  {
>   struct drm_dp_mst_port *port;
> -
> + struct drm_dp_mst_branch *mstb_child;
>   if (!mstb->link_address_sent) {
>   drm_dp_send_link_address(mgr, mstb);
>   mstb->link_address_sent = true;
> @@ -1219,17 +1219,31 @@ static void drm_dp_check_and_send_link_address(struct 
> drm_dp_mst_topology_mgr *m
>   if (!port->available_pbn)
>   drm_dp_send_enum_path_resources(mgr, mstb, port);
>  
> - if (port->mstb)
> - drm_dp_check_and_send_link_address(mgr, port->mstb);
> + if (port->mstb) {
> + mstb_child = drm_dp_get_validated_mstb_ref(mgr, 
> port->mstb);
> + if (mstb_child) {
> + drm_dp_check_and_send_link_address(mgr, 
> mstb_child);
> + drm_dp_put_mst_branch_device(mstb_child);
> + }
> + }
>   }
>  }
>  
>  static void drm_dp_mst_link_probe_work(struct work_struct *work)
>  {
>   struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct 
> drm_dp_mst_topology_mgr, work);
> + struct drm_dp_mst_branch *mstb;
>  
> - drm_dp_check_and_send_link_address(mgr, mgr->mst_primary);
> -
> + mutex_lock(>lock);
> + mstb = mgr->mst_primary;
> + if (mstb) {
> + kref_get(>kref);
> + }
> + mutex_unlock(>lock);
> + if (mstb) {
> + drm_dp_check_and_send_link_address(mgr, mstb);
> + drm_dp_put_mst_branch_device(mstb);
> + }
>  }
>  
>  static bool drm_dp_validate_guid(struct drm_dp_mst_topology_mgr *mgr,
> -- 
> 2.4.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off

2015-06-22 Thread Josh Boyer

On Mon, Jun 22, 2015 at 9:27 AM, Jani Nikula
 wrote:
> On Mon, 22 Jun 2015, Josh Boyer  wrote:
>> On Mon, Jun 22, 2015 at 8:02 AM, Daniel Vetter  
>> wrote:
>>> We should never nest these since in theory kms drivers should know
>>> when a pipe is on/off and call the corresponding enable/disable
>>> functions for the vblank helper code only once. But for historical
>>> reasons (the shared-with-ums version of this code in modeset_pre/post
>>> needed to be able to cope with silly userspace that lost track of
>>> things) we still have this bit of "robustness" around.
>>>
>>> Enforce this with a WARN_ON, preparing to eventually rip out this
>>> special handling.
>>
>> This doesn't really provide any context in the WARN_ON itself.  It
>> will just result in a splat that looks like a kernel oops, and end
>> users and distribution maintainers will be left scratching their
>> heads.
>>
>> Could this be done with a printk warning instead, or could you at
>> least provide a pr_warn statement to help people understand why their
>> machine has an oops splat?
>
> FWIW i915_drv.h has
>
> #define WARN_ON(x) WARN((x), "WARN_ON(" #x ")")
>
> which makes it a little better...

Only a little though, and only in i915.  This is in the generic DRM
code, isn't it?  I mean, a DRM developer is certainly helped by that.
But an end user seeing this won't know it is because of nested calls.
A simple:

dev_warn("Driver has nested vblank calls.  This works but should be
fixed soon.")

or something similar would at least help people understand what is
happening and that their machine isn't actually broken yet.

josh

>>> Cc: Yogesh Mohan Marimuthu 
>>> Cc: Gaurav K Singh 
>>> Cc: Michel DÃ¤nzer 
>>> Cc: Ville SyrjÃ¤lÃ¤ 
>>> Signed-off-by: Daniel Vetter 
>>> ---
>>>  drivers/gpu/drm/drm_irq.c | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>>> index f9cc68fbd2a3..3819465abe22 100644
>>> --- a/drivers/gpu/drm/drm_irq.c
>>> +++ b/drivers/gpu/drm/drm_irq.c
>>> @@ -1219,6 +1219,8 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
>>> vblank_disable_and_save(dev, crtc);
>>> wake_up(>queue);
>>>
>>> +   WARN_ON(vblank->inmodeset);
>>> +
>>> /*
>>>  * Prevent subsequent drm_vblank_get() from re-enabling
>>>  * the vblank interrupt by bumping the refcount.
>>> @@ -1318,6 +1320,8 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
>>> return;
>>>
>>> spin_lock_irqsave(>vbl_lock, irqflags);
>>> +   WARN_ON(!vblank->inmodeset);
>>> +
>>> /* Drop our private "prevent drm_vblank_get" refcount */
>>> if (vblank->inmodeset) {
>>> atomic_dec(>refcount);
>>> --
>>> 2.1.4
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center

[PATCH 1/2] drm/dp: look up the mstb passed into work function (v2)

On Mon, Jun 22, 2015 at 02:40:43PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> We should validate the passed in mstb under the lock
> this should stop us getting an invalid mstb here.
> 
> (first attempt with cancelling work has lockdep issues).
> Bugzilla: https://bugs.archlinux.org/task/45369
> 
> v2: update bugzilla, add some notes on why passing mst_primary
> is okay.
> 
> Signed-off-by: Dave Airlie 

On 2nd look I realized that pulling out mgr->lock and using the _locked
variant won't work cleanly since the _put might also take the mgr->lock. I
guess we could fix that too by also pulling the ref grab/drop for its
argument out of check_and_send like this:

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 132581ca4ad8..08c131536b2b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1189,6 +1189,7 @@ static void drm_dp_check_and_send_link_address(struct 
drm_dp_mst_topology_mgr *m
   struct drm_dp_mst_branch *mstb)
 {
struct drm_dp_mst_port *port;
+   struct drm_dp_mst_branch *mstb_child;

if (!mstb->link_address_sent) {
drm_dp_send_link_address(mgr, mstb);
@@ -1204,17 +1205,31 @@ static void drm_dp_check_and_send_link_address(struct 
drm_dp_mst_topology_mgr *m
if (!port->available_pbn)
drm_dp_send_enum_path_resources(mgr, mstb, port);

-   if (port->mstb)
-   drm_dp_check_and_send_link_address(mgr, port->mstb);
+   if (port->mstb) {
+   mstb_child = drm_dp_get_validated_mstb_ref(mgr,
+  port->mstb);
+   if (mstb_child) {
+   drm_dp_check_and_send_link_address(mgr,
+  mstb_child);
+   drm_dp_put_mst_branch_device(mstb_child);
+   }
+   }
}
 }

 static void drm_dp_mst_link_probe_work(struct work_struct *work)
 {
struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct 
drm_dp_mst_topology_mgr, work);
+   struct drm_dp_mst_branch *mstb;

-   drm_dp_check_and_send_link_address(mgr, mgr->mst_primary);
+   mutex_lock(>lock);
+   kref_get(>mst_primary->kref);
+   mstb = mgr->mst_primary;
+   mutex_unlock(>lock);

+   drm_dp_check_and_send_link_address(mgr, mstb);
+
+   drm_dp_put_mst_branch_device(mstb);
 }

 static bool drm_dp_validate_guid(struct drm_dp_mst_topology_mgr *mgr,

Upside is that we don't need a comment, and imo non-tricky code is better
code. Or am I still missing something?
-Daniel

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index fb65f5d..3c7e5cd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1198,9 +1198,14 @@ static struct drm_dp_mst_branch 
> *drm_dp_get_mst_branch_device(struct drm_dp_mst_
>  }
>  
>  static void drm_dp_check_and_send_link_address(struct 
> drm_dp_mst_topology_mgr *mgr,
> -struct drm_dp_mst_branch *mstb)
> +struct drm_dp_mst_branch 
> *mstb_in)
>  {
>   struct drm_dp_mst_port *port;
> + struct drm_dp_mst_branch *mstb;
> +
> + mstb = drm_dp_get_validated_mstb_ref(mgr, mstb_in);
> + if (!mstb)
> + return;
>  
>   if (!mstb->link_address_sent) {
>   drm_dp_send_link_address(mgr, mstb);
> @@ -1219,12 +1224,20 @@ static void drm_dp_check_and_send_link_address(struct 
> drm_dp_mst_topology_mgr *m
>   if (port->mstb)
>   drm_dp_check_and_send_link_address(mgr, port->mstb);
>   }
> + drm_dp_put_mst_branch_device(mstb);
>  }
>  
>  static void drm_dp_mst_link_probe_work(struct work_struct *work)
>  {
>   struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct 
> drm_dp_mst_topology_mgr, work);
> -
> + /*
> +  * Note this passes mgr->mst_primary without validation
> +  * it could be a) valid, b) NULL, c) some value between
> +  * since we haven't taken the lock,
> +  * however the validation sequence in check and send
> +  * will take the lock, and if the value isn't valid
> +  * it will fail appropriately.
> +  */
>   drm_dp_check_and_send_link_address(mgr, mgr->mst_primary);
>  
>  }
> -- 
> 2.4.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off

2015-06-22 Thread Josh Boyer

On Mon, Jun 22, 2015 at 8:02 AM, Daniel Vetter  
wrote:
> We should never nest these since in theory kms drivers should know
> when a pipe is on/off and call the corresponding enable/disable
> functions for the vblank helper code only once. But for historical
> reasons (the shared-with-ums version of this code in modeset_pre/post
> needed to be able to cope with silly userspace that lost track of
> things) we still have this bit of "robustness" around.
>
> Enforce this with a WARN_ON, preparing to eventually rip out this
> special handling.

This doesn't really provide any context in the WARN_ON itself.  It
will just result in a splat that looks like a kernel oops, and end
users and distribution maintainers will be left scratching their
heads.

Could this be done with a printk warning instead, or could you at
least provide a pr_warn statement to help people understand why their
machine has an oops splat?

josh

> Cc: Yogesh Mohan Marimuthu 
> Cc: Gaurav K Singh 
> Cc: Michel DÃ¤nzer 
> Cc: Ville SyrjÃ¤lÃ¤ 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index f9cc68fbd2a3..3819465abe22 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1219,6 +1219,8 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
> vblank_disable_and_save(dev, crtc);
> wake_up(>queue);
>
> +   WARN_ON(vblank->inmodeset);
> +
> /*
>  * Prevent subsequent drm_vblank_get() from re-enabling
>  * the vblank interrupt by bumping the refcount.
> @@ -1318,6 +1320,8 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
> return;
>
> spin_lock_irqsave(>vbl_lock, irqflags);
> +   WARN_ON(!vblank->inmodeset);
> +
> /* Drop our private "prevent drm_vblank_get" refcount */
> if (vblank->inmodeset) {
> atomic_dec(>refcount);
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/2] drm/dp/mst: take lock around looking up the branch device on hpd irq

On Mon, Jun 22, 2015 at 02:40:44PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> If we are doing an MST transaction and we've gotten HPD and we
> lookup the device from the incoming msg, we should take the mgr
> lock around it, so that mst_primary and mstb->ports are valid.
> 
> Signed-off-by: Dave Airlie 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 3c7e5cd..15a6d8e 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1175,6 +1175,8 @@ static struct drm_dp_mst_branch 
> *drm_dp_get_mst_branch_device(struct drm_dp_mst_
>   struct drm_dp_mst_port *port;
>   int i;
>   /* find the port by iterating down */
> +
> + mutex_lock(>lock);
>   mstb = mgr->mst_primary;
>  
>   for (i = 0; i < lct - 1; i++) {
> @@ -1194,6 +1196,7 @@ static struct drm_dp_mst_branch 
> *drm_dp_get_mst_branch_device(struct drm_dp_mst_
>   }
>   }
>   kref_get(>kref);
> + mutex_unlock(>lock);
>   return mstb;
>  }
>  
> -- 
> 2.4.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/dp: look up the mstb passed into work function

On Mon, Jun 22, 2015 at 02:28:33PM +1000, Dave Airlie wrote:
> On 20 June 2015 at 01:42, Daniel Vetter  wrote:
> > On Fri, Jun 19, 2015 at 10:53:10AM +1000, Dave Airlie wrote:
> >> From: Dave Airlie 
> >>
> >> We should validate the passed in mstb under the lock
> >> this should stop us getting an invalid mstb here.
> >>
> >> (first attempt with cancelling work has lockdep issues).
> >
> > Yeah cancel_work_sync is nasty that way ;-)
> >
> > Btw random bikeshed, but mgr->work would look nice as mgr->probe_work.
> >
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89366
> > Bugzilla: https://bugs.archlinux.org/task/45369
> >
> > seems the more accurate one, the fdo one is a mess.
> 
> yes probably.
> 
> > I am a bit concerned about the lifetime rules of the mgr->mst_primary
> > pointer. port->mstb is controlled by the lifetime of the port and that by
> > the parent mst branch, so I think we're covered dereferencing that one.
> >
> > But mgr->mst_primary seems to be protected only by mgr->lock, and you're
> > not holding that in the probe work. I did review
> > drm_dp_mst_topology_mgr_set_mst and that does seem to clean up
> > ->mst_primary correctly but might be helped with a comment. But we do need
> > the locking I think.
> 
> That won't work as we take the lock to do the lookups later,
> 
> It doesn't actually matter if mgr->mst_primary gets messed up here I
> don't think,
> as long as we validate it. So the value is going to be either a)
> correct, b) NULL,
> c) garbage between a and b assuming its not atomic, the validate function
> locks the mgr, and checks primary, at this point primary will either be a or b
> as we hold the lock, and if primary from outside the function is a, b or c 
> won't
> matter as the validation will either pass or fail depending on the
> state under the
> lock.

Hm, I was afraid of some derefencing of the passed-in mstb pointer, but
indeed we seem to be covered. Still I think pulling the mgr->lock out and
instead using drm_dp_mst_get_validated_mstb_ref_locked in
drm_dp_check_and_send_link_address would result in less head-scratching
next time we read this code ;-)
-Daniel

> 
> Though in reviewing that I did find another bug with primary which
> I'll send another fix for.
> 
> Dave.

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 91045] problems with 10.6.x and glamor