Re: [PATCH v7 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS

[Sandy Huang]

Hi heiko,

在 2017/8/29 18:29, Heiko Stuebner 写道:

Am Dienstag, 29. August 2017, 18:17:11 CEST schrieb Mark yao:

On 2017年08月23日 14:26, Sandy Huang wrote:

This patch add Document for Rockchip Soc RK3288 LVDS,
This based on the patches from Mark yao and Heiko Stuebner.

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---

Looks good for me:

Reviewed-by: Mark Yao 


Signed-off ordering is wrong though ... you add a Signed-off below
all others and you could also drop the one from me, as I don't
think I did provide to much value between Mark's and Sandy's variant
of the patches :-)


Heiko



I will change the Singed off order as bellow at next version.

Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
Signed-off-by: Sandy Huang 


Changes according to Rob Herring's review.

   .../bindings/display/rockchip/rockchip-lvds.txt| 99 
++
   1 file changed, 99 insertions(+)
   create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
new file mode 100644
index 000..da6939e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
@@ -0,0 +1,99 @@
+Rockchip RK3288 LVDS interface
+
+
+Required properties:
+- compatible: matching the soc type, one of
+   - "rockchip,rk3288-lvds";
+
+- reg: physical base address of the controller and length
+   of memory mapped region.
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+- clock-names: must contain "pclk_lvds"
+
+- avdd1v0-supply: regulator phandle for 1.0V analog power
+- avdd1v8-supply: regulator phandle for 1.8V analog power
+- avdd3v3-supply: regulator phandle for 3.3V analog power
+
+- rockchip,grf: phandle to the general register files syscon
+- rockchip,output: "rgb", "lvds" or "duallvds", This describes the output 
interface
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this controller.
+
+Required nodes:
+
+The lvds has two video ports as described by
+   Documentation/devicetree/bindings/media/video-interfaces.txt
+Their connections are modeled using the OF graph bindings specified in
+   Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
+- video port 1 for either a panel or subsequent encoder
+
+the lvds panel described by
+   Documentation/devicetree/bindings/display/panel/simple-panel.txt
+
+Panel required properties:
+- ports for remote LVDS output
+
+Panel optional properties:
+- data-mapping: should be "vesa-24","jeida-24" or "jeida-18".
+This describes decribed by:
+   Documentation/devicetree/bindings/display/panel/panel-lvds.txt
+
+Example:
+
+lvds_panel: lvds-panel {
+   compatible = "auo,b101ean01";
+   enable-gpios = <&gpio7 21 GPIO_ACTIVE_HIGH>;
+   data-mapping = "jeida-24";
+
+   ports {
+   panel_in_lvds: endpoint {
+   remote-endpoint = <&lvds_out_panel>;
+   };
+   };
+};
+
+For Rockchip RK3288:
+
+   lvds: lvds@ff96c000 {
+   compatible = "rockchip,rk3288-lvds";
+   rockchip,grf = <&grf>;
+   reg = <0xff96c000 0x4000>;
+   clocks = <&cru PCLK_LVDS_PHY>;
+   clock-names = "pclk_lvds";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <&lcdc_ctl>;
+   avdd1v0-supply = <&vdd10_lcd>;
+   avdd1v8-supply = <&vcc18_lcd>;
+   avdd3v3-supply = <&vcca_33>;
+   rockchip,output = "rgb";
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   lvds_in: port@0 {
+   reg = <0>;
+
+   lvds_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&vopb_out_lvds>;
+   };
+   lvds_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&vopl_out_lvds>;
+   };
+   };
+
+   lvds_out: port@1 {
+   reg = <1>;
+
+   lvds_out_panel: endpoint {
+   remote-endpoint = <&panel_in_lvds>;
+   };
+   };
+   };
+   };








___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

Hi Eric,

On Thu, 31 Aug 2017 10:03:23 -0700
Eric Anholt  wrote:

> Boris Brezillon  writes:
> 
> > Add a driver for Cadence DPI -> DSI bridge.
> >
> > This driver only support a subset of Cadence DSI bridge capabilities.
> >
> > Here is a non-exhaustive list of missing features:
> >  * burst mode
> >  * dynamic configuration of the DPHY based on the
> >  * support for additional input interfaces (SDI input)
> >
> > Signed-off-by: Boris Brezillon 
> > ---
> > Changes in v3:
> > - replace magic values by real timing calculation. The DPHY PLL clock
> >   is still hardcoded since we don't have a working DPHY block yet, and
> >   this is the piece of HW we need to dynamically configure the PLL
> >   rate based on the display refresh rate and the resolution.
> > - parse DSI devices represented with the OF-graph. This is needed to
> >   support DSI devices controlled through an external bus like I2C or
> >   SPI.
> > - use the DRM panel-bridge infrastructure to simplify the DRM panel
> >   logic  
> 
> Just a few comments from me.  With the few straightforward nitpicks
> fixed, it gets my:
> 
> Acked-by: Eric Anholt 
> 
> > +static enum drm_mode_status
> > +cdns_dsi_bridge_mode_valid(struct drm_bridge *bridge,
> > +  const struct drm_display_mode *mode)
> > +{
> > +   struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
> > +   struct cdns_dsi *dsi = input_to_dsi(input);
> > +   struct cdns_dsi_output *output = &dsi->output;
> > +   int bpp;
> > +
> > +   /*
> > +* VFP_DSI should be less than VFP_DPI and VFP_DSI should be at
> > +* least 1.
> > +*/
> > +   if (mode->vtotal - mode->vsync_end < 2)
> > +   return MODE_V_ILLEGAL;
> > +
> > +   /* VSA_DSI = VSA_DPI and must be at least 2. */
> > +   if (mode->vsync_end - mode->vsync_start < 2)
> > +   return MODE_V_ILLEGAL;
> > +
> > +   /* HACT must be a 32-bits aligned. */  
> 
> s/a /
> 
> > +   bpp = mipi_dsi_pixel_format_to_bpp(output->dev->format);
> > +   if ((mode->hdisplay * bpp) % 32)
> > +   return MODE_H_ILLEGAL;
> > +
> > +   return MODE_OK;
> > +}  
> 
> 
> > +static void cdns_dsi_bridge_enable(struct drm_bridge *bridge)
> > +{
> > +   struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
> > +   struct cdns_dsi *dsi = input_to_dsi(input);
> > +   struct cdns_dsi_output *output = &dsi->output;
> > +   u32 hsize0, hsa, hline, tmp, reg_wakeup, div;
> > +   unsigned long dphy_pll_period, tx_byte_period;
> > +   struct drm_display_mode *mode;
> > +   int bpp, nlanes;
> > +
> > +   mode = &bridge->encoder->crtc->state->adjusted_mode;
> > +   bpp = mipi_dsi_pixel_format_to_bpp(output->dev->format);
> > +   nlanes = output->dev->lanes;
> > +
> > +   if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> > +   tmp = mode->crtc_htotal - mode->crtc_hsync_end;
> > +   else
> > +   tmp = mode->crtc_htotal - mode->crtc_hsync_start;
> > +   tmp = (tmp * bpp) / 8;
> > +   tmp = tmp < DSI_HBP_FRAME_OVERHEAD ? 0 : tmp - DSI_HBP_FRAME_OVERHEAD;
> > +   hsize0 = HBP_LEN(tmp);
> > +
> > +   tmp = mode->crtc_hsync_start - mode->crtc_hdisplay;
> > +   tmp = (tmp * bpp) / 8;  
> 
> How is this scaling supposed to work when you have RGB666_PACKED (bpp =
> 18)?  It seems like there would be bad rounding issues.

That's a good question. The spec does not say anything about rounding,
but I guess rounding up is safer. Richard, any opinion on that?

> 
> > +   tmp = tmp < DSI_HFP_FRAME_OVERHEAD ? 0 : tmp - DSI_HFP_FRAME_OVERHEAD;
> > +   hsize0 |= HFP_LEN(tmp);
> > +
> > +   if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> > +   tmp = mode->crtc_hsync_end - mode->crtc_hsync_start;
> > +   else
> > +   tmp = 0;
> > +   tmp = (tmp * 8) / bpp;  
> 
> This scaling is suspiciously different from the others around it.  Did
> you mean this?

It's a mistake, I'll fix that.

> 
> > +   tmp = tmp < DSI_HSA_FRAME_OVERHEAD ? 0 : tmp - DSI_HSA_FRAME_OVERHEAD;
> > +   hsa = tmp;
> > +   hsize0 |= HSA_LEN(tmp);
> > +
> > +   writel(hsize0, dsi->regs + VID_HSIZE1);
> > +   writel((mode->crtc_hdisplay * bpp) / 8, dsi->regs + VID_HSIZE2);
> > +
> > +   writel(VBP_LEN(mode->crtc_vtotal - mode->crtc_vsync_end - 1) |
> > +  VFP_LEN(mode->crtc_vsync_start - mode->crtc_vdisplay) |
> > +  VSA_LEN(mode->crtc_vsync_end - mode->crtc_vsync_start),
> > +  dsi->regs + VID_VSIZE1);
> > +   writel(mode->crtc_vdisplay, dsi->regs + VID_VSIZE2);
> > +
> > +   hline = (mode->crtc_htotal * bpp) / 8;
> > +   tmp = hline - DSI_HSA_FRAME_OVERHEAD;
> > +   if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> > +   tmp -= hsa + DSI_HSA_FRAME_OVERHEAD;
> > +
> > +   writel(BLK_LINE_PULSE_PKT_LEN(tmp), dsi->regs + VID_BLKSIZE2);
> > +   if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> > +   writel(MAX_LINE_LIMIT(tmp - DSI_NULL_FRAME_OVERHEAD),
> > +  dsi->regs + VID_VCA_SETTING2);
> > +
> > +   tmp = hline -
> >

[radeon-alex:amd-staging-drm-next 463/840] powerpc64-linux-gnu-gcc: error: unrecognized command line option '-msse'; did you mean '-mspe'?

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   990b8d69489cc8ba7e119af536808e5ca41d3864
commit: 1167fd8e59a79a52602701e3c30298d4da750388 [463/840] drm/amdgpu/display: 
Enable DCN in DC
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1167fd8e59a79a52602701e3c30298d4da750388
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

Note: the radeon-alex/amd-staging-drm-next HEAD 
990b8d69489cc8ba7e119af536808e5ca41d3864 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> powerpc64-linux-gnu-gcc: error: unrecognized command line option '-msse'; 
>> did you mean '-mspe'?
>> powerpc64-linux-gnu-gcc: error: unrecognized command line option 
>> '-mpreferred-stack-boundary=4'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/3] drm/exynos/gsc: Support the rotate hardware limits of gsc

[Hoegeun Kwon]

Hello all,

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  ARM: dts: exynos: Add the hardware rotation limits for gsc
  arm64: dts: exynos: Add the hardware rotation limits for gsc
  drm/exynos/gsc: Add rotation hardware limits of gscaler

 arch/arm/boot/dts/exynos5250.dtsi  |  8 
 arch/arm/boot/dts/exynos5420.dtsi  |  4 ++
 arch/arm64/boot/dts/exynos/exynos5433.dtsi |  6 +++
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 63 +++---
 include/uapi/drm/exynos_drm.h  |  2 +
 5 files changed, 60 insertions(+), 23 deletions(-)

-- 
1.9.1

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

[PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

[Hoegeun Kwon]

The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 +
 include/uapi/drm/exynos_drm.h   |  2 ++
 2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = &property->config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct device *dev,
if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
if (swap) {
if ((pos->h < pp->scale_min.hsize) ||
-   (sz->vsize > pp->scale_max.hsize) ||
+   (pos->h > pp->scale_max.hsize) ||
(pos->w < pp->scale_min.vsize) ||
-   (sz->hsize > pp->scale_max.vsize)) {
+   (pos->w > pp->scale_max.vsize)) {
DRM_ERROR("out of scale size.\n");
goto err_property;
}
 

[PATCH 1/3] ARM: dts: exynos: Add the hardware rotation limits for gsc

[Hoegeun Kwon]

The gscaler has maximum size of input or output rotation. Add the
hardware limits property for the gscaler rotation in the exynos5250
and exynos5420 dts.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..d9434e0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -643,6 +643,8 @@
power-domains = <&pd_gsc>;
clocks = <&clock CLK_GSCL0>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <&sysmmu_gsc0>;
};
 
@@ -653,6 +655,8 @@
power-domains = <&pd_gsc>;
clocks = <&clock CLK_GSCL1>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <&sysmmu_gsc1>;
};
 
@@ -663,6 +667,8 @@
power-domains = <&pd_gsc>;
clocks = <&clock CLK_GSCL2>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <&sysmmu_gsc2>;
};
 
@@ -673,6 +679,8 @@
power-domains = <&pd_gsc>;
clocks = <&clock CLK_GSCL3>;
clock-names = "gscl";
+   rot-max-hsize = <2048>;
+   rot-max-vsize = <2048>;
iommu = <&sysmmu_gsc3>;
};
 
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..0fd6be9 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -664,6 +664,8 @@
clocks = <&clock CLK_GSCL0>;
clock-names = "gscl";
power-domains = <&gsc_pd>;
+   rot-max-hsize = <2016>;
+   rot-max-vsize = <2016>;
iommus = <&sysmmu_gscl0>;
};
 
@@ -674,6 +676,8 @@
clocks = <&clock CLK_GSCL1>;
clock-names = "gscl";
power-domains = <&gsc_pd>;
+   rot-max-hsize = <2016>;
+   rot-max-vsize = <2016>;
iommus = <&sysmmu_gscl1>;
};
 
-- 
1.9.1

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

[PATCH 2/3] arm64: dts: exynos: Add the hardware rotation limits for gsc

[Hoegeun Kwon]

The gscaler has maximum size of input or output rotation. Add the
hardware limits property for the gscaler rotation in the exynos5433
dts.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 7fe994b..57c9997 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -891,6 +891,8 @@
 <&cmu_gscl CLK_ACLK_GSCL0>,
 <&cmu_gscl CLK_ACLK_XIU_GSCLX>,
 <&cmu_gscl CLK_ACLK_GSCLBEND_333>;
+   rot-max-hsize = <2047>;
+   rot-max-vsize = <2047>;
iommus = <&sysmmu_gscl0>;
};
 
@@ -904,6 +906,8 @@
 <&cmu_gscl CLK_ACLK_GSCL1>,
 <&cmu_gscl CLK_ACLK_XIU_GSCLX>,
 <&cmu_gscl CLK_ACLK_GSCLBEND_333>;
+   rot-max-hsize = <2047>;
+   rot-max-vsize = <2047>;
iommus = <&sysmmu_gscl1>;
};
 
@@ -917,6 +921,8 @@
 <&cmu_gscl CLK_ACLK_GSCL2>,
 <&cmu_gscl CLK_ACLK_XIU_GSCLX>,
 <&cmu_gscl CLK_ACLK_GSCLBEND_333>;
+   rot-max-hsize = <2047>;
+   rot-max-vsize = <2047>;
iommus = <&sysmmu_gscl2>;
};
 
-- 
1.9.1

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

[radeon-alex:amd-staging-drm-next 463/840] cc1: error: unrecognized command line option '-mhard-float'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   990b8d69489cc8ba7e119af536808e5ca41d3864
commit: 1167fd8e59a79a52602701e3c30298d4da750388 [463/840] drm/amdgpu/display: 
Enable DCN in DC
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1167fd8e59a79a52602701e3c30298d4da750388
# save the attached .config to linux build tree
make.cross ARCH=tile 

Note: the radeon-alex/amd-staging-drm-next HEAD 
990b8d69489cc8ba7e119af536808e5ca41d3864 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> cc1: error: unrecognized command line option '-mhard-float'
>> cc1: error: unrecognized command line option '-msse'
>> cc1: error: unrecognized command line option '-mpreferred-stack-boundary=4'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102498] [DC] Monitors blink every 10sec and layout resets after returning from powersave or sleep

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com
Summary|Monitors blink every 10sec  |[DC] Monitors blink every
   |and layout resets after |10sec and layout resets
   |returning from powersave or |after returning from
   |sleep   |powersave or sleep

--- Comment #1 from Michel Dänzer  ---
You mentioned on bug 102300 that this is a recent linux-amd-staging regression.
Please mention the last known good and first known bad version.

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

[radeon-alex:amd-staging-drm-next 153/840] drivers/gpu/drm/amd/amdgpu/../display/include/dpcd_defs.h:29:27: fatal error: drm_dp_helper.h: No such file or directory

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   990b8d69489cc8ba7e119af536808e5ca41d3864
commit: a5c3e065aefce54e10552725481f795980625a66 [153/840] drm/amd/display: 
port to using drm dpcd defines
config: s390-allyesconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a5c3e065aefce54e10552725481f795980625a66
# save the attached .config to linux build tree
make.cross ARCH=s390 

Note: the radeon-alex/amd-staging-drm-next HEAD 
990b8d69489cc8ba7e119af536808e5ca41d3864 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:42:0:
>> drivers/gpu/drm/amd/amdgpu/../display/include/dpcd_defs.h:29:27: fatal 
>> error: drm_dp_helper.h: No such file or directory
#include "drm_dp_helper.h"
  ^
   compilation terminated.

vim +29 drivers/gpu/drm/amd/amdgpu/../display/include/dpcd_defs.h

28  
  > 29  #include "drm_dp_helper.h"
30  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102432] [regression] Steam fails to start with libdrm 2.4.83

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer  ---
(In reply to Jan Vesely from comment #2)
> The parsing mechanism is flimsy and adding an entry to
> /usr/share/libdrm/amdgpu.ids crashes libdrm

Can you share more details about how adding en entry to
/usr/share/libdrm/amdgpu.ids causes a crash?

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

Re: [PATCH 1/2] vfs: add flags parameter to ->mmap() in 'struct file_operations'

[Dan Williams]

On Thu, Aug 31, 2017 at 3:02 AM, Christoph Hellwig  wrote:
>> -static int ecryptfs_mmap(struct file *file, struct vm_area_struct *vma)
>> +static int ecryptfs_mmap(struct file *file, struct vm_area_struct *vma,
>> +  unsigned long map_flags)
>>  {
>>   struct file *lower_file = ecryptfs_file_to_lower(file);
>>   /*
>> @@ -179,7 +180,7 @@ static int ecryptfs_mmap(struct file *file, struct 
>> vm_area_struct *vma)
>>*/
>>   if (!lower_file->f_op->mmap)
>>   return -ENODEV;
>> - return generic_file_mmap(file, vma);
>> + return generic_file_mmap(file, vma, 0);
>
> Shouldn't ecryptfs pass on the flags?  Same for coda_file_mmap and
> shm_mmap.

Yes, I'll get those fixed up.

>
>> -static inline int call_mmap(struct file *file, struct vm_area_struct *vma)
>> +static inline int call_mmap(struct file *file, struct vm_area_struct *vma,
>> + unsigned long flags)
>>  {
>> - return file->f_op->mmap(file, vma);
>> + return file->f_op->mmap(file, vma, flags);
>>  }
>
> It would be great to kill this pointless wrapper while we're at it.

Will do.

Thanks for taking a look!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board

[Krzysztof Kozlowski]

On Thu, Aug 31, 2017 at 02:27:14PM +0200, Maciej Purski wrote:
> Add HDMI and Sil9234 MHL converter to Trats2 board.
> Following in SoC devices have been enabled:
> - HDMI (HDMI signal encoder),
> - Mixer (video buffer scanout device),
> - I2C_5 bus (used for HDMI DDC)
> - I2C_8 bus (used for HDMI_PHY control).
> 
> Based on previous work by:
> Tomasz Stanislawski 
> 
> Signed-off-by: Maciej Purski 
> ---
> Changes in v2:
> - fix commit message
> - add regulators nodes to model actual physical connections
> ---
>  arch/arm/boot/dts/exynos4412-trats2.dts | 111 
> 
>  1 file changed, 111 insertions(+)

I think all of my previous comments were missed...

Best regards,
Krzysztof

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

[PATCH] virtgpu: remove redundant task_comm copying

[Michał Mirosław]

Remove redundant task name copying because:

1. task->comm is already NUL-terminated
2. virtio_gpu_context_create() trims passed dbgname anyway

Signed-off-by: Michał Mirosław 
---
 drivers/gpu/drm/virtio/virtgpu_kms.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c 
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 1e1c90b30d4a..6f5c4a8c0ba8 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -272,20 +272,18 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct 
drm_file *file)
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_fpriv *vfpriv;
uint32_t id;
-   char dbgname[64], tmpname[TASK_COMM_LEN];
+   char dbgname[TASK_COMM_LEN];
 
/* can't create contexts without 3d renderer */
if (!vgdev->has_virgl_3d)
return 0;
 
-   get_task_comm(tmpname, current);
-   snprintf(dbgname, sizeof(dbgname), "%s", tmpname);
-   dbgname[63] = 0;
/* allocate a virt GPU context for this opener */
vfpriv = kzalloc(sizeof(*vfpriv), GFP_KERNEL);
if (!vfpriv)
return -ENOMEM;
 
+   get_task_comm(dbgname, current);
virtio_gpu_context_create(vgdev, strlen(dbgname), dbgname, &id);
 
vfpriv->ctx_id = id;
-- 
2.11.0

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

[radeon-alex:amd-staging-drm-next 89/840] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:38:22: fatal error: drm_edid.h: No such file or directory

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   990b8d69489cc8ba7e119af536808e5ca41d3864
commit: 68f6159d99d839908b2b75900209b55ef6bb97b3 [89/840] drm/amd/dc: Add dc 
display driver (v2)
config: s390-allyesconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 68f6159d99d839908b2b75900209b55ef6bb97b3
# save the attached .config to linux build tree
make.cross ARCH=s390 

Note: the radeon-alex/amd-staging-drm-next HEAD 
990b8d69489cc8ba7e119af536808e5ca41d3864 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:38:22: 
>> fatal error: drm_edid.h: No such file or directory
#include "drm_edid.h"
 ^
   compilation terminated.

vim +38 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c

37  
  > 38  #include "drm_edid.h"
39  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102500] [polaris10][amd-staging-4.12] GPU fault detected, somethimes lockup

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher  ---
can you bisect?

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

[PATCH] drm/tve200: Replace custom connector with panel bridge

[Linus Walleij]

This replaces the custom connector in the TVE200 with the
panel bridge helper. As long as we're just using panels
and no other bridges, this works just fine.

Signed-off-by: Linus Walleij 
---
 drivers/gpu/drm/tve200/Kconfig|   3 +-
 drivers/gpu/drm/tve200/Makefile   |   3 +-
 drivers/gpu/drm/tve200/tve200_connector.c | 125 --
 drivers/gpu/drm/tve200/tve200_display.c   |  15 ++--
 drivers/gpu/drm/tve200/tve200_drm.h   |  14 ++--
 drivers/gpu/drm/tve200/tve200_drv.c   |  66 +++-
 6 files changed, 63 insertions(+), 163 deletions(-)
 delete mode 100644 drivers/gpu/drm/tve200/tve200_connector.c

diff --git a/drivers/gpu/drm/tve200/Kconfig b/drivers/gpu/drm/tve200/Kconfig
index 21d9841ddb88..c5f03bf4570c 100644
--- a/drivers/gpu/drm/tve200/Kconfig
+++ b/drivers/gpu/drm/tve200/Kconfig
@@ -4,7 +4,8 @@ config DRM_TVE200
depends on CMA
depends on ARM || COMPILE_TEST
depends on OF
-   select DRM_PANEL
+   select DRM_BRIDGE
+   select DRM_PANEL_BRIDGE
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
diff --git a/drivers/gpu/drm/tve200/Makefile b/drivers/gpu/drm/tve200/Makefile
index a9dba54f7ee5..6b7a6a1dcbf8 100644
--- a/drivers/gpu/drm/tve200/Makefile
+++ b/drivers/gpu/drm/tve200/Makefile
@@ -1,5 +1,4 @@
-tve200_drm-y +=tve200_connector.o \
-   tve200_display.o \
+tve200_drm-y +=tve200_display.o \
tve200_drv.o
 
 obj-$(CONFIG_DRM_TVE200) += tve200_drm.o
diff --git a/drivers/gpu/drm/tve200/tve200_connector.c 
b/drivers/gpu/drm/tve200/tve200_connector.c
deleted file mode 100644
index 5e6c20b57d6d..
--- a/drivers/gpu/drm/tve200/tve200_connector.c
+++ /dev/null
@@ -1,125 +0,0 @@
-/*
- * Copyright (C) 2017 Linus Walleij 
- * Parts of this file were based on sources as follows:
- *
- * Copyright (C) 2006-2008 Intel Corporation
- * Copyright (C) 2007 Amos Lee 
- * Copyright (C) 2007 Dave Airlie 
- * Copyright (C) 2011 Texas Instruments
- * Copyright (C) 2017 Eric Anholt
- *
- * This program is free software and is provided to you under the terms of the
- * GNU General Public License version 2 as published by the Free Software
- * Foundation, and any use by you of this program is subject to the terms of
- * such GNU licence.
- */
-
-/**
- * tve200_drm_connector.c
- * Implementation of the connector functions for the Faraday TV Encoder
- */
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "tve200_drm.h"
-
-static void tve200_connector_destroy(struct drm_connector *connector)
-{
-   struct tve200_drm_connector *tve200con =
-   to_tve200_connector(connector);
-
-   if (tve200con->panel)
-   drm_panel_detach(tve200con->panel);
-
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
-
-static enum drm_connector_status tve200_connector_detect(struct drm_connector
-   *connector, bool force)
-{
-   struct tve200_drm_connector *tve200con =
-   to_tve200_connector(connector);
-
-   return (tve200con->panel ?
-   connector_status_connected :
-   connector_status_disconnected);
-}
-
-static int tve200_connector_helper_get_modes(struct drm_connector *connector)
-{
-   struct tve200_drm_connector *tve200con =
-   to_tve200_connector(connector);
-
-   if (!tve200con->panel)
-   return 0;
-
-   return drm_panel_get_modes(tve200con->panel);
-}
-
-static const struct drm_connector_funcs connector_funcs = {
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .destroy = tve200_connector_destroy,
-   .detect = tve200_connector_detect,
-   .reset = drm_atomic_helper_connector_reset,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-static const struct drm_connector_helper_funcs connector_helper_funcs = {
-   .get_modes = tve200_connector_helper_get_modes,
-};
-
-/*
- * Walks the OF graph to find the panel node and then asks DRM to look
- * up the panel.
- */
-static struct drm_panel *tve200_get_panel(struct device *dev)
-{
-   struct device_node *endpoint, *panel_node;
-   struct device_node *np = dev->of_node;
-   struct drm_panel *panel;
-
-   endpoint = of_graph_get_next_endpoint(np, NULL);
-   if (!endpoint) {
-   dev_err(dev, "no endpoint to fetch panel\n");
-   return NULL;
-   }
-
-   /* Don't proceed if we have an endpoint but no panel_node tied to it */
-   panel_node = of_graph_get_remote_port_parent(endpoint);
-   of_node_put(endpoint);
-   if (!panel_node) {
-   dev_err(dev, "no valid panel node\n");
-   return NULL;
-   }
-
-   panel = of_drm_f

[PATCH 00/13] mmu_notifier kill invalidate_page callback v2

[jglisse]

From: Jérôme Glisse 

(Sorry for so many list cross-posting and big cc)

Changes since v1:
  - remove more dead code in kvm (no testing impact)
  - more accurate end address computation (patch 2)
in page_mkclean_one and try_to_unmap_one
  - added tested-by/reviewed-by gotten so far

Tested as both host and guest kernel with KVM nothing is burning yet.

Previous cover letter:


Please help testing !

The invalidate_page callback suffered from 2 pitfalls. First it used to
happen after page table lock was release and thus a new page might have
been setup for the virtual address before the call to invalidate_page().

This is in a weird way fixed by c7ab0d2fdc840266b39db94538f74207ec2afbf6
which moved the callback under the page table lock. Which also broke
several existing user of the mmu_notifier API that assumed they could
sleep inside this callback.

The second pitfall was invalidate_page being the only callback not taking
a range of address in respect to invalidation but was giving an address
and a page. Lot of the callback implementer assumed this could never be
THP and thus failed to invalidate the appropriate range for THP pages.

By killing this callback we unify the mmu_notifier callback API to always
take a virtual address range as input.

There is now 2 clear API (I am not mentioning the youngess API which is
seldomly used):
  - invalidate_range_start()/end() callback (which allow you to sleep)
  - invalidate_range() where you can not sleep but happen right after
page table update under page table lock


Note that a lot of existing user feels broken in respect to range_start/
range_end. Many user only have range_start() callback but there is nothing
preventing them to undo what was invalidated in their range_start() callback
after it returns but before any CPU page table update take place.

The code pattern use in kvm or umem odp is an example on how to properly
avoid such race. In a nutshell use some kind of sequence number and active
range invalidation counter to block anything that might undo what the
range_start() callback did.

If you do not care about keeping fully in sync with CPU page table (ie
you can live with CPU page table pointing to new different page for a
given virtual address) then you can take a reference on the pages inside
the range_start callback and drop it in range_end or when your driver
is done with those pages.

Last alternative is to use invalidate_range() if you can do invalidation
without sleeping as invalidate_range() callback happens under the CPU
page table spinlock right after the page table is updated.


Note this is barely tested. I intend to do more testing of next few days
but i do not have access to all hardware that make use of the mmu_notifier
API.


First 2 patches convert existing call of mmu_notifier_invalidate_page()
to mmu_notifier_invalidate_range() and bracket those call with call to
mmu_notifier_invalidate_range_start()/end().

The next 10 patches remove existing invalidate_page() callback as it can
no longer happen.

Finaly the last page remove it completely so it can RIP.

Jérôme Glisse (13):
  dax: update to new mmu_notifier semantic
  mm/rmap: update to new mmu_notifier semantic
  powerpc/powernv: update to new mmu_notifier semantic
  drm/amdgpu: update to new mmu_notifier semantic
  IB/umem: update to new mmu_notifier semantic
  IB/hfi1: update to new mmu_notifier semantic
  iommu/amd: update to new mmu_notifier semantic
  iommu/intel: update to new mmu_notifier semantic
  misc/mic/scif: update to new mmu_notifier semantic
  sgi-gru: update to new mmu_notifier semantic
  xen/gntdev: update to new mmu_notifier semantic
  KVM: update to new mmu_notifier semantic
  mm/mmu_notifier: kill invalidate_page

Cc: Kirill A. Shutemov 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Andrea Arcangeli 
Cc: Joerg Roedel 
Cc: Dan Williams 
Cc: Sudeep Dutt 
Cc: Ashutosh Dixit 
Cc: Dimitri Sivanich 
Cc: Jack Steiner 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 

Cc: linuxppc-...@lists.ozlabs.org
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: io...@lists.linux-foundation.org
Cc: xen-de...@lists.xenproject.org
Cc: k...@vger.kernel.org

Jérôme Glisse (13):
  dax: update to new mmu_notifier semantic
  mm/rmap: update to new mmu_notifier semantic v2
  powerpc/powernv: update to new mmu_notifier semantic
  drm/amdgpu: update to new mmu_notifier semantic
  IB/umem: update to new mmu_notifier semantic
  IB/hfi1: update to new mmu_notifier semantic
  iommu/amd: update to new mmu_notifier semantic
  iommu/intel: update to new mmu_notifier semantic
  misc/mic/scif: update to new mmu_notifier semantic
  sgi-gru: update to new mmu_notifier semantic
  xen/gntdev: update to new mmu_notifier semantic
  KVM: update to new mmu_notifier semantic v2
  mm/mmu_notifier: kill invalidate_page

 arch/arm/include/asm/kvm_host.h  |  6 -
 arch/arm64/include/asm/kvm_host.h|  6 -
 arch/mips/include/asm/kvm_host.h  

[Bug 102500] [polaris10][amd-staging-4.12] GPU fault detected, somethimes lockup

[bugzilla-daemon]

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

Bug ID: 102500
   Summary: [polaris10][amd-staging-4.12] GPU fault detected,
somethimes lockup
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: arek.r...@gmail.com

Created attachment 133914
  --> https://bugs.freedesktop.org/attachment.cgi?id=133914&action=edit
dmesg - start gnome 3 session only

Hi, 
Afer today kernel update witcher 3 hangs. After restart (only Gnome3 session is
running) in kernel log i see lot of:
...
amdgpu :01:00.0: GPU fault detected: 146 0x0d023d14
amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x001061A0
amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0903D014
amdgpu :01:00.0: VM fault (0x14, vmid 4) at page 1073568, write from 'SDM1'
(0x53444d31) (61)
...
downgrade kernel resolve this issue. 

I use binary kernel from unofficial arch's repo:
linux-amd-staging 4.12.0.680862.7be0a528b097 - the bad one 
linux-amd-staging-4.12.0.680853.eeb9985d7228 - works great

these kernels are built from alex's git tree, branch amd-staging-4.12

OpenGL renderer string: AMD Radeon (TM) RX 470 Graphics (POLARIS10 / DRM 3.18.0
/ 4.13.0-rc7-mainline, LLVM 6.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.0-devel
(git-2d93b462b4)

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

[Bug 102498] Monitors blink every 10sec and layout resets after returning from powersave or sleep

[bugzilla-daemon]

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

Bug ID: 102498
   Summary: Monitors blink every 10sec and layout resets after
returning from powersave or sleep
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: f...@mt2015.com

Created attachment 133913
  --> https://bugs.freedesktop.org/attachment.cgi?id=133913&action=edit
dmesg

One or both monitors (ASUS much more often) continously blink once in 5-10
seconds. This happens only in linux and not in grub or windows. Second problem
is that monitor layout resets to mirrored from extended desktop when monitor
returns from powersaving to show lockscreen and I need to rerun xrandr. There
are some errors in dmesg, so it is attached. Log is from right after returning
from being AFK and giving lockscreen password. This bug is continuation to my
previous problem in Bug #102300.  

** System Info **

Ryzen 1700
ASUS Prime B350+
Radeon R9 285

Dell U2414H DVI-D-0 (HDMI -> DVI-D cable)
ASUS VE247  DVI-D-1 (DVI-I cable)

Graphics:  Card: Advanced Micro Devices [AMD/ATI] Tonga PRO [Radeon R9 285/380]
   Display Server: x11 (X.Org 1.19.3) driver: amdgpu
   Resolution: 1920x1080@60.00hz, 1920x1080@60.00hz
   OpenGL: renderer: Gallium 0.4 on AMD TONGA (DRM 3.19.0 /
4.12.0-1-amd-staging, LLVM 4.0.1)
   version: 4.5 Mesa 17.1.7

Linux zaplo-pc 4.12.0-1-amd-staging #1 SMP PREEMPT Sun Aug 27 18:23:36 UTC 2017
x86_64 GNU/Linux

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

[Bug 102497] Fatal error during GPU init when using an aarch64 board

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher  ---
(In reply to Bernhard Rosenkraenzer from comment #0)

> 
> I presume the problem is caused by the (lack of) BIOS on aarch64 boards not
> initializing the GPU the same way an x86 box does.
> 

No, the driver is able to init the card regardless of whether the vbios has
been posted or not.

> This is on kernel 4.4.52 (latest kernel supported by the board; could try
> pulling DRI patches from newer kernels if there's any hope of changes being
> there already), libdrm 2.4.82

Here's the problem:

> [Wed Jul 12 14:01:10 2017] [drm] Detected VRAM RAM=512M, BAR=0M

There is no PCI BAR for frame buffer access. I'm guessing your pcie bridge does
not have a large enough aperture for the frame buffer BAR.  It's generally
256MB.

The driver can't work without access to vram.

Please attach your full dmesg output.

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

[Bug 102497] Fatal error during GPU init when using an aarch64 board

[bugzilla-daemon]

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

Bug ID: 102497
   Summary: Fatal error during GPU init when using an aarch64
board
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: b...@lindev.ch

Putting a Radeon graphics card into the PCI slot of an Aarch64 board (the
particular one I tried is the Solidrun MACCHIATObin) results in:

[Wed Jul 12 14:01:10 2017] [drm] Initialized drm 1.1.0 20060810
[Wed Jul 12 14:01:10 2017] [drm] radeon kernel modesetting enabled.
[Wed Jul 12 14:01:10 2017] [drm] initializing kernel modesetting (RV620
0x1002:0x95C5 0x174B:0xE400).
[Wed Jul 12 14:01:10 2017] [drm] register mmio base: 0xF612
[Wed Jul 12 14:01:10 2017] [drm] register mmio size: 65536
[Wed Jul 12 14:01:10 2017] ATOM BIOS: 
[Wed Jul 12 14:01:10 2017] [drm] GPU not posted. posting now...
[Wed Jul 12 14:01:10 2017] radeon :01:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[Wed Jul 12 14:01:10 2017] radeon :01:00.0: GTT: 512M 0x2000 -
0x3FFF
[Wed Jul 12 14:01:10 2017] [drm] Detected VRAM RAM=512M, BAR=0M
[Wed Jul 12 14:01:10 2017] [drm] RAM width 64bits DDR
[Wed Jul 12 14:01:10 2017] [TTM] Zone  kernel: Available graphics memory:
1889730 kiB
[Wed Jul 12 14:01:10 2017] [TTM] Initializing pool allocator
[Wed Jul 12 14:01:10 2017] [TTM] Initializing DMA pool allocator
[Wed Jul 12 14:01:10 2017] radeon :01:00.0: Fatal error during GPU init
[Wed Jul 12 14:01:10 2017] [drm] radeon: finishing device.
[Wed Jul 12 14:01:10 2017] [TTM] Trying to take down uninitialized memory
manager type 1
[Wed Jul 12 14:01:10 2017] [TTM] Finalizing pool allocator
[Wed Jul 12 14:01:10 2017] [TTM] Finalizing DMA pool allocator
[Wed Jul 12 14:01:10 2017] [TTM] Zone  kernel: Used memory at exit: 0 kiB
[Wed Jul 12 14:01:10 2017] [drm] radeon: ttm finalized
[Wed Jul 12 14:01:10 2017] radeon: probe of :01:00.0 failed with error -12

I've tried 3 different radeon cards:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620
LE [Radeon HD 3450]

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV710/M92 [Mobility Radeon HD 4530/4570/545v]

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV530LE [Radeon X1600/X1650 PRO]

All behave the exact same.

I presume the problem is caused by the (lack of) BIOS on aarch64 boards not
initializing the GPU the same way an x86 box does.

This is on kernel 4.4.52 (latest kernel supported by the board; could try
pulling DRI patches from newer kernels if there's any hope of changes being
there already), libdrm 2.4.82

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

Re: [PATCH 6/6] drm/tinydrm: Support device unplug

[Noralf Trønnes]

Den 31.08.2017 14.59, skrev Laurent Pinchart:

Hi Daniel and Noralf,

On Wednesday, 30 August 2017 20:18:49 EEST Daniel Vetter wrote:

On Wed, Aug 30, 2017 at 6:31 PM, Noralf Trønnes  wrote:

Den 28.08.2017 23.56, skrev Daniel Vetter:

On Mon, Aug 28, 2017 at 07:17:48PM +0200, Noralf Trønnes wrote:

Support device unplugging to make tinydrm suitable for USB devices.

Cc: David Lechner 
Signed-off-by: Noralf Trønnes 
---

drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 69 ++---
drivers/gpu/drm/tinydrm/mi0283qt.c  |  4 ++
drivers/gpu/drm/tinydrm/mipi-dbi.c  |  5 ++-
drivers/gpu/drm/tinydrm/repaper.c   |  9 +++-
drivers/gpu/drm/tinydrm/st7586.c|  9 +++-
include/drm/tinydrm/tinydrm.h   |  5 +++
6 files changed, 87 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index f11f4cd..3ccbcc5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -32,6 +32,29 @@
   * The driver allocates &tinydrm_device, initializes it using
   * devm_tinydrm_init(), sets up the pipeline using
tinydrm_display_pipe_init()
   * and registers the DRM device using devm_tinydrm_register().
+ *
+ * Device unplug
+ * -
+ *
+ * tinydrm supports device unplugging when there's still open DRM or
fbdev file
+ * handles.
+ *
+ * There are 2 ways for driver-device unbinding to happen:
+ *
+ * - The driver module is unloaded causing the driver to be
unregistered.
+ *   This can't happen as long as there's open file handles because a
reference
+ *   is taken on the module.

Aside: you can do that, but then it works like a hw unplug, through the
unbind property in sysfs.

The module is still pinned isn't it?

Yup, but only the code is pinned, not any of the datastructures like
drm_device.


I can add sysfs unbind as a third way of triggering unbind:
  * - The sysfs driver _unbind_ file can be used to unbind the driver form
the
  *   device. This can happen any time.
  *

Sounds good to me.


+ *
+ * - The device is removed (USB, Device Tree overlay).
+ *   This can happen at any time.
+ *
+ * The driver needs to protect device resources from access after the
device is
+ * gone. This is done checking drm_dev_is_unplugged(), typically in
+ * &drm_framebuffer_funcs.dirty, &drm_simple_display_pipe_funcs.enable
and
+ * \.disable. Resources that doesn't face userspace and is only used

s/doesn't/don't/
s/and is/and are/


with the
+ * device can be setup using devm\_ functions, but &tinydrm_device must
be
+ * allocated using plain kzalloc() since it's lifetime can exceed that
of the

s/it's/its/


+ * device. tinydrm_release() will free the structure.

So here's a bit a dragon: There's no prevention of is_unplugged racing
against a drm_dev_unplug(). There's been various attempts to fixing this,
but they're all somewhat ugly.

Either way, that's a bug in the drm core :-)


*/

 /**

@@ -138,6 +161,29 @@ static const struct drm_mode_config_funcs
tinydrm_mode_config_funcs = {
 .atomic_commit = drm_atomic_helper_commit,
   };
+/**
+ * tinydrm_release - DRM driver release helper
+ * @drm: DRM device
+ *
+ * This function cleans up and finalizes &drm_device and frees
&tinydrm_device.
+ *
+ * Drivers must use this as their &drm_driver->release callback.
+ */
+void tinydrm_release(struct drm_device *drm)
+{
+   struct tinydrm_device *tdev = drm_to_tinydrm(drm);
+
+   DRM_DEBUG_DRIVER("\n");
+
+   drm_mode_config_cleanup(drm);
+   drm_dev_fini(drm);
+
+   mutex_destroy(&tdev->dirty_lock);
+   kfree(tdev->fbdev_cma);
+   kfree(tdev);
+}
+EXPORT_SYMBOL(tinydrm_release);
+
   static int tinydrm_init(struct device *parent, struct tinydrm_device
*tdev,
 const struct drm_framebuffer_funcs *fb_funcs,
 struct drm_driver *driver)
@@ -160,8 +206,6 @@ static int tinydrm_init(struct device *parent,
struct tinydrm_device *tdev,
   static void tinydrm_fini(struct tinydrm_device *tdev)
   {
-   drm_mode_config_cleanup(&tdev->drm);
-   mutex_destroy(&tdev->dirty_lock);
 drm_dev_unref(&tdev->drm);
   }
@@ -178,8 +222,8 @@ static void devm_tinydrm_release(void *data)
   * @driver: DRM driver
   *
   * This function initializes @tdev, the underlying DRM device and it's

While at it, s/it's/its/


- * mode_config. Resources will be automatically freed on driver detach
(devres)
- * using drm_mode_config_cleanup() and drm_dev_unref().
+ * mode_config. drm_dev_unref() is called on driver detach (devres) and
when
+ * all refs are dropped, tinydrm_release() is called.
   *
   * Returns:
   * Zero on success, negative error code on failure.
@@ -226,14 +270,17 @@ static int tinydrm_register(struct tinydrm_device
*tdev)

   static void tinydrm_unregister(struct tinydrm_device *tdev)
   {
-   struct drm_fbdev_cma *fbdev_cma = tdev->fbdev_cma;
-
 drm_atomic_hel

Re: [PATCH v2 09/10] dt-bindings: exynos5433-decon: remove i80-if-timings property

[Rob Herring]

On Thu, Aug 24, 2017 at 03:33:58PM +0200, Andrzej Hajda wrote:
> Since i80/command mode is determined in runtime by propagating info
> from panel this property can be removed.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  .../devicetree/bindings/display/exynos/exynos5433-decon.txt  | 12 
> 
>  1 file changed, 12 deletions(-)

Acked-by: Rob Herring 

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

[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

[bugzilla-daemon]

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

--- Comment #42 from MirceaKitsune  ---
Further more, I suspect I now know what the culprit component is. It's very
likely that the problem lies within Mesa itself, and was introduced in the
switch between 13.0 and 17.0.

This was confirmed by the bug report I linked previously, which I strongly
believe is related to the issue I'm experiencing here: Another person there was
able to verify that their crash happens with Mesa 17 but not 13. Looking at the
dates, I realize that I started experiencing this problem precisely when
openSUSE Tumbleweed upgraded from Mesa 13.0 to 17.0: Mesa 17 landed in early
March 2017, it was a few days later that the issues began, which I then
reported the following week (08 March 2017). See my comment in the other bug
for more info on this:

https://bugs.freedesktop.org/show_bug.cgi?id=101325#c22

I also seem to confirm that the issue only affects RadeonSI cards but not R600:
My laptop has a Mobility Radeon HD 5470 card (R600) whereas my desktop has a
Radeon R7 370 card (RadeonSI). I've been away for two weeks and have been using
my laptop exclusively during this time, which has the exact same OS and
configuration as my desktop. I was able to preform every task I do on my
desktop from my laptop, including the triggers I described above... I have
never experienced this freeze with the laptop.

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

[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

[bugzilla-daemon]

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

--- Comment #41 from MirceaKitsune  ---
I have important new information. After yet more weeks of testing, I seem to
have found both of the common triggers for this issue. The crash happens a few
hours after either of the following actions is preformed:

1 - Desktop effects are toggled at runtime. Pressing Alt + Shift + F12 twice to
turn compositing off then back on will mine the system with this crash.

2 - I insert my USB stick or external drive into an USB port, mount it and
access it in Dolphin, then unmount and remove it. A few hours after I've
inserted / removed my drive, the freeze occurs. I suspect this has to do with
the device notifier popping up in the system tray, asking what action to
preform on the device or telling me the device is safe to unplug.

I'm not sure if the themes I'm using might have any relevancy. Considering this
is a graphics problem, I figured I'd share this info as well so others can test
them if they wish. I'm using the Plasma / KWin theme Freeze with the default
Breeze icons / cursor / widget style:

https://www.opendesktop.org/p/998653/
https://www.opendesktop.org/p/1002663/

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

Re: [PATCH 7/7] drm/pl111: Add handling of Versatile platforms

[Eric Anholt]

Linus Walleij  writes:

> The ARM reference designs in the Versatile family: Integrator,
> Versatile and RealView can make use of the new DRM driver as well.
> We just need to create a bit of platform-specific code for them
> that we isolate to its own file.
>
> Signed-off-by: Linus Walleij 
> ---
>  drivers/gpu/drm/pl111/Makefile  |   1 +
>  drivers/gpu/drm/pl111/pl111_display.c   |   7 -
>  drivers/gpu/drm/pl111/pl111_drv.c   |   5 +
>  drivers/gpu/drm/pl111/pl111_versatile.c | 270 
> 
>  drivers/gpu/drm/pl111/pl111_versatile.h |   9 ++
>  5 files changed, 285 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/gpu/drm/pl111/pl111_versatile.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_versatile.h
>
> diff --git a/drivers/gpu/drm/pl111/Makefile b/drivers/gpu/drm/pl111/Makefile
> index c5f8f9684848..fce1453a93e1 100644
> --- a/drivers/gpu/drm/pl111/Makefile
> +++ b/drivers/gpu/drm/pl111/Makefile
> @@ -1,4 +1,5 @@
>  pl111_drm-y +=   pl111_display.o \
> + pl111_versatile.o \
>   pl111_drv.o
>  
>  pl111_drm-$(CONFIG_DEBUG_FS) += pl111_debugfs.o
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
> b/drivers/gpu/drm/pl111/pl111_display.c
> index 37f409867934..f7b043f4fed6 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -454,13 +454,6 @@ int pl111_display_init(struct drm_device *drm)
>   }
>   of_node_put(endpoint);
>  
> - if (tft_r0b0g0[0] != 0 ||
> - tft_r0b0g0[1] != 8 ||
> - tft_r0b0g0[2] != 16) {
> - dev_err(dev, "arm,pl11x,tft-r0g0b0-pads != [0,8,16] not yet 
> supported\n");
> - return -EINVAL;
> - }

I had a note in the DOC section of pl111_drv.c about needing to filter
available formats based on this property.  Could you update that with
some explanation of the new state of things?  (Do we actually need to
filter the formats?)

I haven't verified that we get the same pin routing setup as the fbdev
driver did for these platforms, but even if they don't match yet this
seems like an excellent start and we can make sure we sort them out as
we add panel drivers.

I've verified that my Cygnus board continues working with your series.


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

Re: [PATCH 4/7] drm/pl111: Enable PL110 variant

[Eric Anholt]

Linus Walleij  writes:

> We detect and enable the use of the PL110 variant, an earlier
> incarnation of PL111. The only real difference is that the
> control and interrupt enable registers have swapped place.
> The Versatile AB and Versatile PB have a variant inbetween
> PL110 and PL111, it is PL110 but they have already swapped the
> two registers so those two need a bit of special handling.
>
> Signed-off-by: Linus Walleij 

With the other Eric's little const fixes,

Reviewed-by: Eric Anholt 


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

[PATCH] drm: nouveau: replace magic constant for TASK_COMM_LEN

[Michał Mirosław]

Client's name is task_comm + pid: use constant for clarity and prepare
for changed TASK_COMM_LEN.

Signed-off-by: Michał Mirosław 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 15a13d09d431..28396d0b0864 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -830,7 +830,7 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file 
*fpriv)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_cli *cli;
-   char name[32], tmpname[TASK_COMM_LEN];
+   char name[TASK_COMM_LEN + 16], tmpname[TASK_COMM_LEN];
int ret;
 
/* need to bring up power immediately if opening device */
-- 
2.11.0

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

Re: DRM Format Modifiers in v4l2

[Nicolas Dufresne]

Le jeudi 31 août 2017 à 17:28 +0300, Laurent Pinchart a écrit :
> > e.g. if I have two devices which support MODIFIER_FOO, I could attempt
> > to share a buffer between them which uses MODIFIER_FOO without
> > necessarily knowing exactly what it is/does.
> 
> Userspace could certainly set modifiers blindly, but the point of modifiers 
> is 
> to generate side effects benefitial to the use case at hand (for instance by 
> optimizing the memory access pattern). To use them meaningfully userspace 
> would need to have at least an idea of the side effects they generate.

Generic userspace will basically pick some random combination. To allow
generically picking the optimal configuration we could indeed rely on
the application knowledge, but we could also enhance the spec so that
the order in the enumeration becomes meaningful.

regards,
Nicolas

signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/7] drm/pl111: Add all registers to debugfs

[Eric Anholt]

Linus Walleij  writes:

> This adds all the main control registers to the debugfs
> register file. This was helpful for my debugging so it will
> likely help others as well.

This and the previous patch are:

Reviewed-by: Eric Anholt 


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

Re: [PATCH 3/7] drm/pl111: Replace custom connector with panel bridge

[Eric Anholt]

Linus Walleij  writes:

> This replaces the custom connector in the PL111 with the
> panel bridge helper.
>
> This works nicely for all standard panels, but since there
> are several PL11x-based systems that will need to use the dumb
> VGA connector bridge we use drm_of_find_panel_or_bridge()
> and make some headroom for dealing with bridges that are
> not panels as well, and drop a TODO in the code.
>
> Signed-off-by: Linus Walleij 

> diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
> b/drivers/gpu/drm/pl111/pl111_display.c
> index c6ca4f1bbd49..ef86ef60aed1 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -93,7 +93,7 @@ static void pl111_display_enable(struct 
> drm_simple_display_pipe *pipe,
>   struct pl111_drm_dev_private *priv = drm->dev_private;
>   const struct drm_display_mode *mode = &cstate->mode;
>   struct drm_framebuffer *fb = plane->state->fb;
> - struct drm_connector *connector = &priv->connector.connector;
> + struct drm_connector *connector = priv->connector;
>   u32 cntl;
>   u32 ppl, hsw, hfp, hbp;
>   u32 lpp, vsw, vfp, vbp;
> @@ -155,7 +155,7 @@ static void pl111_display_enable(struct 
> drm_simple_display_pipe *pipe,
>  
>   writel(0, priv->regs + CLCD_TIM3);
>  
> - drm_panel_prepare(priv->connector.panel);
> + drm_panel_prepare(priv->panel);

If we're moving to panel-bridge, then we should drop our manual panel
prepare/enable/disable calls -- the panel-bridge will have already
panel_prepare()d before our encoder's enable, and will panel_enable()
after we finish.


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

Re: [PATCH 4/6] drm/tinydrm: Embed drm_device in tinydrm_device

[Noralf Trønnes]

Den 31.08.2017 12.18, skrev Laurent Pinchart:

Hi Noralf,

Thank you for the patch.

On Monday, 28 August 2017 20:17:46 EEST Noralf Trønnes wrote:

Might as well embed drm_device since tinydrm_device (embeds pipe struct
and fbdev pointer) needs to stick around after driver-device unbind to
handle open fd's after device removal.

Cc: David Lechner 
Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 44  -
  drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c |  2 +-
  drivers/gpu/drm/tinydrm/mi0283qt.c  |  8 +++---
  drivers/gpu/drm/tinydrm/mipi-dbi.c  | 12 
  drivers/gpu/drm/tinydrm/repaper.c   | 10 +++
  drivers/gpu/drm/tinydrm/st7586.c| 16 +--
  include/drm/tinydrm/tinydrm.h   |  9 +-
  7 files changed, 50 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c index 551709e..f11f4cd 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c

[snip]


@@ -142,23 +142,16 @@ static int tinydrm_init(struct device *parent, struct
tinydrm_device *tdev, const struct drm_framebuffer_funcs *fb_funcs,
struct drm_driver *driver)
  {
-   struct drm_device *drm;
+   struct drm_device *drm = &tdev->drm;
+   int ret;

mutex_init(&tdev->dirty_lock);
tdev->fb_funcs = fb_funcs;

-   /*
-* We don't embed drm_device, because that prevent us from using
-* devm_kzalloc() to allocate tinydrm_device in the driver since
-* drm_dev_unref() frees the structure. The devm_ functions provide
-* for easy error handling.

Don't you then need a custom drm_driver.release handler to free the parent
structure ?


I rely on the fact that drm_device is the first member in the driver
structure and thus it will be freed in drm_dev_release(). A later patch
adds a drm_driver.release function though.

Noralf.


-*/
-   drm = drm_dev_alloc(driver, parent);
-   if (IS_ERR(drm))
-   return PTR_ERR(drm);
-
-   tdev->drm = drm;
-   drm->dev_private = tdev;
+   ret = drm_dev_init(drm, driver, parent);
+   if (ret)
+   return ret;
+
drm_mode_config_init(drm);
drm->mode_config.funcs = &tinydrm_mode_config_funcs;


[snip]


diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c index 7e5bb7d..77d40c9 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c

[snip]


@@ -169,7 +169,7 @@ static int mi0283qt_probe(struct spi_device *spi)
u32 rotation = 0;
int ret;

-   mipi = devm_kzalloc(dev, sizeof(*mipi), GFP_KERNEL);
+   mipi = kzalloc(sizeof(*mipi), GFP_KERNEL);

Where's the related kfree() ?


if (!mipi)
return -ENOMEM;

[snip]


diff --git a/drivers/gpu/drm/tinydrm/repaper.c
b/drivers/gpu/drm/tinydrm/repaper.c index 30dc97b..b8fc8eb 100644
--- a/drivers/gpu/drm/tinydrm/repaper.c
+++ b/drivers/gpu/drm/tinydrm/repaper.c

[snip]


@@ -949,7 +949,7 @@ static int repaper_probe(struct spi_device *spi)
}
}

-   epd = devm_kzalloc(dev, sizeof(*epd), GFP_KERNEL);
+   epd = kzalloc(sizeof(*epd), GFP_KERNEL);

Ditto.


if (!epd)
return -ENOMEM;

[snip]


diff --git a/drivers/gpu/drm/tinydrm/st7586.c
b/drivers/gpu/drm/tinydrm/st7586.c index b439956..bc2b905 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c

[snip]


@@ -349,7 +349,7 @@ static int st7586_probe(struct spi_device *spi)
u32 rotation = 0;
int ret;

-   mipi = devm_kzalloc(dev, sizeof(*mipi), GFP_KERNEL);
+   mipi = kzalloc(sizeof(*mipi), GFP_KERNEL);

Ang here again.


if (!mipi)
return -ENOMEM;

[snip]



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

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

[Eric Anholt]

Boris Brezillon  writes:

> Add a driver for Cadence DPI -> DSI bridge.
>
> This driver only support a subset of Cadence DSI bridge capabilities.
>
> Here is a non-exhaustive list of missing features:
>  * burst mode
>  * dynamic configuration of the DPHY based on the
>  * support for additional input interfaces (SDI input)
>
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v3:
> - replace magic values by real timing calculation. The DPHY PLL clock
>   is still hardcoded since we don't have a working DPHY block yet, and
>   this is the piece of HW we need to dynamically configure the PLL
>   rate based on the display refresh rate and the resolution.
> - parse DSI devices represented with the OF-graph. This is needed to
>   support DSI devices controlled through an external bus like I2C or
>   SPI.
> - use the DRM panel-bridge infrastructure to simplify the DRM panel
>   logic

Just a few comments from me.  With the few straightforward nitpicks
fixed, it gets my:

Acked-by: Eric Anholt 

> +static enum drm_mode_status
> +cdns_dsi_bridge_mode_valid(struct drm_bridge *bridge,
> +const struct drm_display_mode *mode)
> +{
> + struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
> + struct cdns_dsi *dsi = input_to_dsi(input);
> + struct cdns_dsi_output *output = &dsi->output;
> + int bpp;
> +
> + /*
> +  * VFP_DSI should be less than VFP_DPI and VFP_DSI should be at
> +  * least 1.
> +  */
> + if (mode->vtotal - mode->vsync_end < 2)
> + return MODE_V_ILLEGAL;
> +
> + /* VSA_DSI = VSA_DPI and must be at least 2. */
> + if (mode->vsync_end - mode->vsync_start < 2)
> + return MODE_V_ILLEGAL;
> +
> + /* HACT must be a 32-bits aligned. */

s/a /

> + bpp = mipi_dsi_pixel_format_to_bpp(output->dev->format);
> + if ((mode->hdisplay * bpp) % 32)
> + return MODE_H_ILLEGAL;
> +
> + return MODE_OK;
> +}


> +static void cdns_dsi_bridge_enable(struct drm_bridge *bridge)
> +{
> + struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
> + struct cdns_dsi *dsi = input_to_dsi(input);
> + struct cdns_dsi_output *output = &dsi->output;
> + u32 hsize0, hsa, hline, tmp, reg_wakeup, div;
> + unsigned long dphy_pll_period, tx_byte_period;
> + struct drm_display_mode *mode;
> + int bpp, nlanes;
> +
> + mode = &bridge->encoder->crtc->state->adjusted_mode;
> + bpp = mipi_dsi_pixel_format_to_bpp(output->dev->format);
> + nlanes = output->dev->lanes;
> +
> + if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + tmp = mode->crtc_htotal - mode->crtc_hsync_end;
> + else
> + tmp = mode->crtc_htotal - mode->crtc_hsync_start;
> + tmp = (tmp * bpp) / 8;
> + tmp = tmp < DSI_HBP_FRAME_OVERHEAD ? 0 : tmp - DSI_HBP_FRAME_OVERHEAD;
> + hsize0 = HBP_LEN(tmp);
> +
> + tmp = mode->crtc_hsync_start - mode->crtc_hdisplay;
> + tmp = (tmp * bpp) / 8;

How is this scaling supposed to work when you have RGB666_PACKED (bpp =
18)?  It seems like there would be bad rounding issues.

> + tmp = tmp < DSI_HFP_FRAME_OVERHEAD ? 0 : tmp - DSI_HFP_FRAME_OVERHEAD;
> + hsize0 |= HFP_LEN(tmp);
> +
> + if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + tmp = mode->crtc_hsync_end - mode->crtc_hsync_start;
> + else
> + tmp = 0;
> + tmp = (tmp * 8) / bpp;

This scaling is suspiciously different from the others around it.  Did
you mean this?

> + tmp = tmp < DSI_HSA_FRAME_OVERHEAD ? 0 : tmp - DSI_HSA_FRAME_OVERHEAD;
> + hsa = tmp;
> + hsize0 |= HSA_LEN(tmp);
> +
> + writel(hsize0, dsi->regs + VID_HSIZE1);
> + writel((mode->crtc_hdisplay * bpp) / 8, dsi->regs + VID_HSIZE2);
> +
> + writel(VBP_LEN(mode->crtc_vtotal - mode->crtc_vsync_end - 1) |
> +VFP_LEN(mode->crtc_vsync_start - mode->crtc_vdisplay) |
> +VSA_LEN(mode->crtc_vsync_end - mode->crtc_vsync_start),
> +dsi->regs + VID_VSIZE1);
> + writel(mode->crtc_vdisplay, dsi->regs + VID_VSIZE2);
> +
> + hline = (mode->crtc_htotal * bpp) / 8;
> + tmp = hline - DSI_HSA_FRAME_OVERHEAD;
> + if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + tmp -= hsa + DSI_HSA_FRAME_OVERHEAD;
> +
> + writel(BLK_LINE_PULSE_PKT_LEN(tmp), dsi->regs + VID_BLKSIZE2);
> + if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + writel(MAX_LINE_LIMIT(tmp - DSI_NULL_FRAME_OVERHEAD),
> +dsi->regs + VID_VCA_SETTING2);
> +
> + tmp = hline -
> +   (DSI_HSS_VSS_VSE_FRAME_OVERHEAD + DSI_BLANKING_FRAME_OVERHEAD);
> + writel(BLK_LINE_EVENT_PKT_LEN(tmp), dsi->regs + VID_BLKSIZE1);
> + if (!(output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> + writel(MAX_LINE_LIMIT(tmp - DSI_NULL_FRAME_OVERHEAD),
> +dsi->regs + VID_VCA_SETTING2);
> +
> + tmp = DIV_ROU

[Bug 102432] [regression] Steam fails to start with libdrm 2.4.83

[bugzilla-daemon]

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

--- Comment #2 from Jan Vesely  ---
(In reply to Gregor Münch from comment #1)
> Forget everything, solution:
> 
> Ok, the problem is that nobody updated lib32-libdrm in arch. Its still at
> 2.4.81 so way to old. I installed now the git versions of both packages
> witch brings them effectively to 2.4.83 r0 and the problem went away.
> 
> In the meantime, I even tried to bisect:
> 
> 0167e6836e91947418fec36c3b4b396760d0f345 is the first bad commit
> commit 0167e6836e91947418fec36c3b4b396760d0f345
> Author: Jan Vesely 
> Date:   Fri Jul 28 01:46:45 2017 -0400
> 
> amdgpu: Add FX-9800P Bristol Ridge iGPU id
> 
> Signed-off-by: Jan Vesely 
> Reviewed-by: Michel Dänzer 
> 
> :04 04 8b07e8bdce21260ecccb07f424348b838a787472
> 2c65bba8b27ddf5329fa9f1e3501f33225ca909a Mdata
> 
> confirmed by reverting, though its pointless.

the list of ids needs to be sinced across 32/64 bit versions.
The parsing mechanism is flimsy and adding an entry to
/usr/share/libdrm/amdgpu.ids crashes libdrm

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

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

[bugzilla-daemon]

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

Eike  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #76 from Eike  ---
This is fixed (as suggested by iono in comment #55 ) as of kernel v4.12-rc7.
Change:
https://github.com/torvalds/linux/commit/52b482b0f4fd6d5267faf29fe91398e203f3c230

I am currently using Arch with kernel 4.12.8-2, which contains the fix and
everything is fixed for me.

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

Re: [PATCH V3 00/23] drm/etnaviv: support performance counters

[Christian Gmeiner]

2017-08-25 11:06 GMT+02:00 Christian Gmeiner :
> In a perfect world we would be able to read GPU registers of interest
> via the command stream with a 'read-register' command/package. For perf
> counters it is a must to read them synchronized with the GPU to put the
> values in relation to a draw command. As Vivante GPUs do not provide this
> functionality we need to emulate it in software.
>
>
> We need to support three different kind of perf register types:
>
> 1) normal register
>   This is the easierst case where we can simply read the register and we
>   are done.
>
> 2) debug register
>   We need to configure the mux register and then read the debug register 
> value.
>
> 3) pipeline register
>   We need to 'iterate' over all pixel pipes and sum up the values. The 
> 'iteration'
>   is done by select the pipe of interest via 
> HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE.
>   There is also need to configure the mux register.
>
>
> Allowing the userspace to do it all by its own feels quite error prone and not
> future-proof. Thats why the kernel exports all performance domains and their
> signals to the userspace via two new ioctls. So the kernel knows all 
> performance
> counters and how to sample them.
>
> At the moment all performacne domains and signals get exported to all gpu 
> pipe types,
> but that can be changed in follow-up patches.
>
> struct drm_etnaviv_gem_submit was extended to include so-called performance 
> monitor
> requests (pmrs). A request defines what domain and signal should be sampled 
> (pre/post
> draw cmdbuffer) and where to store the result.
>
> The whole series can be found here:
> https://github.com/austriancoder/linux/tree/perfmon-v3
>
> The used libdrm and mesa branches to test this feature can be found here:
> https://github.com/austriancoder/libdrm/commits/perfmon-v2
> https://github.com/austriancoder/mesa/commits/perfmon-v2
>
> Changes v1 -> v2:
>  - reworked events
>  - reworked uapi
>  - reworked enumeration of domains and signals
>  - process sync point with a work item to keep irq as fast as possible
>  - prevent GPU hang when reading pixel pipeline perf values
>  - all SH perf counters are accessed via perf_reg_read(..)
>
> Changes v2 -> v3:
>  - reworked alloc_event(..)
>  - fixed pmr flag validation
>
> Happy reviewing!
>
> Christian Gmeiner (23):
>   drm/etnaviv: use bitmap to keep track of events
>   drm/etnaviv: make it possible to allocate multiple events
>   drm/etnaviv: add infrastructure to query perf counter
>   drm/etnaviv: add uapi for perfmon feature
>   drm/etnaviv: add internal representation of perfmon_request
>   drm/etnaviv: extend etnaviv_gpu_cmdbuf_new(..) with nr_pmrs
>   drm/etnaviv: add performance monitor request validation
>   drm/etnaviv: copy pmrs from userspace
>   drm/etnaviv: add performance monitor request processing
>   drm/etnaviv: add 'sync point' support
>   drm/etnaviv: clear alloced event
>   drm/etnaviv: use 'sync points' for performance monitor requests
>   drm/etnaviv: add HI perf domain
>   drm/etnaviv: add PE perf domain
>   drm/etnaviv: add SH perf domain
>   drm/etnaviv: add PA perf domain
>   drm/etnaviv: add SE perf domain
>   drm/etnaviv: add RA perf domain
>   drm/etnaviv: add TX perf domain
>   drm/etnaviv: add MC perf domain
>   drm/etnaviv: need to disable clock gating when doing profiling
>   drm/etnaviv: enable debug registers on demand
>   drm/etnaviv: submit supports performance monitor requests
>
>  drivers/gpu/drm/etnaviv/Makefile |   3 +-
>  drivers/gpu/drm/etnaviv/etnaviv_buffer.c |  36 +++
>  drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c |  15 +-
>  drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h |   6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c|  39 ++-
>  drivers/gpu/drm/etnaviv/etnaviv_drv.h|   1 +
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  69 -
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 216 ++---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  13 +-
>  drivers/gpu/drm/etnaviv/etnaviv_perfmon.c| 447 
> +++
>  drivers/gpu/drm/etnaviv/etnaviv_perfmon.h|  48 +++
>  include/uapi/drm/etnaviv_drm.h   |  42 ++-
>  12 files changed, 878 insertions(+), 57 deletions(-)
>  create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
>  create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
>
> --

It looks like I have screwed up patches 03 and 04 - used v1 ones
instead of v2 :/
I will send out a tested v4 series on Tuesday next week as I am
currently in Sweden
and my device @home did not survived a reboot.

Sorry if I wasted somebody's time.
--
Christian Gmeiner, MSc

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

[PATCH v3 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings

[Boris Brezillon]

Document the bindings used for the Cadence DSI bridge.

Signed-off-by: Boris Brezillon 
---
Changes in v3:
- Fix clock names in the example
- Document how to represent DSI devices that are controller through
  an external bus like I2C or SPI

Changes in v2:
- None
---
 .../bindings/display/bridge/cdns,dsi.txt   | 109 +
 1 file changed, 109 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt 
b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
new file mode 100644
index ..c70008bd8c0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
@@ -0,0 +1,109 @@
+Cadence DSI bridge
+==
+
+The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
+
+Required properties:
+- compatible: should be set to "cdns,dsi-1.3.1".
+- reg: physical base address and length of the controller's registers.
+- interrupts: interrupt line connected to the DSI bridge.
+- clocks: DSI bridge clocks.
+- clock-names: must contain "pclk" and "sysclk".
+- phys: phandle link to the MIPI D-PHY controller.
+- phy-names: must contain "dphy".
+- #address-cells: must be set to 1.
+- #size-cells: must be set to 0.
+
+Required subnodes:
+- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
+  2 ports are available:
+  * port 0: this port is only needed if some of your DSI devices are
+   controlled through  an external bus like I2C or SPI. Can have at
+   most 4 endpoints. The endpoint number is directly encoding the
+   DSI virtual channel used by this device.
+  * port 1: represents the DPI input.
+  Other ports will be added later to support the new kind of inputs.
+
+- one subnode per DSI device connected on the DSI bus. Each DSI device should
+  contain a reg property encoding its virtual channel.
+
+Example:
+
+   dsi0: dsi@fd0c {
+   compatible = "cdns,dsi-1.3.1";
+   reg = <0x0 0xfd0c 0x0 0x1000>;
+   clocks = <&pclk>, <&sysclk>;
+   clock-names = "pclk", "sysclk";
+   interrupts = <1>;
+   phys = <&dphy1>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+   dsi0_dpi_input: endpoint {
+   remote-endpoint = <&xxx_dpi_output>;
+   };
+   };
+   };
+
+   panel: dsi-dev@0 {
+   compatible = "";
+   reg = <0>;
+   };
+   };
+
+or
+
+   dsi0: dsi@fd0c {
+   compatible = "cdns,dsi";
+   reg = <0x0 0xfd0c 0x0 0x1000>;
+   clocks = <&pclk>, <&sysclk>;
+   clock-names = "pclk", "sysclk";
+   interrupts = <1>;
+   phys = <&dphy1>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dsi0_output: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&dsi_panel_input>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dsi0_dpi_input: endpoint {
+   remote-endpoint = <&xxx_dpi_output>;
+   };
+   };
+   };
+   };
+
+   i2c@xxx {
+   panel: panel@59 {
+   compatible = "";
+   reg = <0x59>;
+
+   port {
+   dsi_panel_input: endpoint {
+   remote-endpoint = <&dsi0_output>;
+   };
+   };
+   };
+   };
-- 
2.11.0

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

[PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

Add a driver for Cadence DPI -> DSI bridge.

This driver only support a subset of Cadence DSI bridge capabilities.

Here is a non-exhaustive list of missing features:
 * burst mode
 * dynamic configuration of the DPHY based on the
 * support for additional input interfaces (SDI input)

Signed-off-by: Boris Brezillon 
---
Changes in v3:
- replace magic values by real timing calculation. The DPHY PLL clock
  is still hardcoded since we don't have a working DPHY block yet, and
  this is the piece of HW we need to dynamically configure the PLL
  rate based on the display refresh rate and the resolution.
- parse DSI devices represented with the OF-graph. This is needed to
  support DSI devices controlled through an external bus like I2C or
  SPI.
- use the DRM panel-bridge infrastructure to simplify the DRM panel
  logic

Changes in v2:
- rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes
- return the correct error when devm_clk_get(sysclk) fails
- add missing depends on OF and select DRM_PANEL in the Kconfig entry
---
 drivers/gpu/drm/bridge/Kconfig|9 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/cdns-dsi.c | 1090 +
 3 files changed, 1100 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index adf9ae0e0b7c..88c324b12e16 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -25,6 +25,15 @@ config DRM_ANALOGIX_ANX78XX
  the HDMI output of an application processor to MyDP
  or DisplayPort.
 
+config DRM_CDNS_DSI
+   tristate "Cadence DPI/DSI bridge"
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   depends on OF
+   help
+ Support Cadence DPI to DSI bridge.
+
 config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index defcf1e7ca1c..77b65e8ecf59 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
+obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
new file mode 100644
index ..f5dc26c90b20
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -0,0 +1,1090 @@
+/*
+ * Copyright: 2017 Cadence Design Systems, Inc.
+ *
+ * Author: Boris Brezillon 
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IP_CONF0x0
+#define SP_HS_FIFO_DEPTH(x)(((x) & GENMASK(30, 26)) >> 26)
+#define SP_LP_FIFO_DEPTH(x)(((x) & GENMASK(25, 21)) >> 21)
+#define VRS_FIFO_DEPTH(x)  (((x) & GENMASK(20, 16)) >> 16)
+#define DIRCMD_FIFO_DEPTH(x)   (((x) & GENMASK(15, 13)) >> 13)
+#define SDI_IFACE_32   BIT(12)
+#define INTERNAL_DATAPATH_32   (0 << 10)
+#define INTERNAL_DATAPATH_16   (1 << 10)
+#define INTERNAL_DATAPATH_8(3 << 10)
+#define INTERNAL_DATAPATH_SIZE ((x) & GENMASK(11, 10))
+#define INTERNAL_DATAPATH_32   (0 << 10)
+#define INTERNAL_DATAPATH_16   (1 << 10)
+#define INTERNAL_DATAPATH_8(3 << 10)
+#define NUM_IFACE(x)   x) & GENMASK(9, 8)) >> 8) + 1)
+#define MAX_LANE_NB(x) (((x) & GENMASK(7, 6)) >> 6)
+#define RX_FIFO_DEPTH(x)   ((x) & GENMASK(5, 0))
+
+#define MCTL_MAIN_DATA_CTL 0x4
+#define TE_MIPI_POLLING_EN BIT(25)
+#define TE_HW_POLLING_EN   BIT(24)
+#define DISP_EOT_GEN   BIT(18)
+#define HOST_EOT_GEN   BIT(17)
+#define DISP_GEN_CHECKSUM  BIT(16)
+#define DISP_GEN_ECC   BIT(15)
+#define BTA_EN BIT(14)
+#define READ_ENBIT(13)
+#define REG_TE_EN  BIT(12)
+#define IF_TE_EN(x)BIT(8 + (x))
+#define T

Re: DRM Format Modifiers in v4l2

[Brian Starkey]

Hi Laurent,

On Thu, Aug 31, 2017 at 05:51:33PM +0300, Laurent Pinchart wrote:

Hi Brian,

On Wednesday, 30 August 2017 13:32:01 EEST Brian Starkey wrote:

On Wed, Aug 30, 2017 at 11:53:58AM +0200, Hans Verkuil wrote:
> On 30/08/17 11:36, Brian Starkey wrote:
>> On Wed, Aug 30, 2017 at 10:10:01AM +0200, Hans Verkuil wrote:
>>> On 30/08/17 09:50, Daniel Vetter wrote:
 On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
> The fact is, adding special formats for each combination is
> unmanageable - we're talking dozens in the case of our hardware.

 Hm right, we can just remap the special combos to the drm-fourcc +
 modifier style. Bonus point if v4l does that in the core so not
 everyone has to reinvent that wheel :-)
>>>
>>> Probably not something we'll do: there are I believe only two drivers
>>> that are affected (exynos & mediatek), so they can do that in their
>>> driver.
>>>
>>> Question: how many modifiers will typically apply to a format? I ask
>>> because I realized that V4L2 could use VIDIOC_ENUMFMT to make the link
>>> between a fourcc and modifiers:
>>>
>>> https://hverkuil.home.xs4all.nl/spec/uapi/v4l/vidioc-enum-fmt.html
>>>
>>> The __u32 reserved[4] array can be used to provide a bitmask to modifier
>>> indices (for the integer menu control). It's similar to what drm does,
>>> except instead of modifiers mapping to fourccs it is the other way
>>> around.
>>>
>>> This would avoid having to change the modifiers control whenever a new
>>> format is set and it makes it easy to enumerate all combinations.
>>>
>>> But this only works if the total number of modifiers used by a single
>>> driver is expected to remain small (let's say no more than 64).
>>
>> In our current (yet to be submitted) description, we've got around a
>> dozen modifiers for any one format to describe our compression
>> variants. We have a lot of on/off toggles which leads to combinatorial
>> expansion, so it can grow pretty quickly (though I am trying to limit
>> the valid combinations as much as possible).
>>
>> How about if the mask fills up then VIDIOC_ENUM_FMT can return another
>> fmtdsc with the same FourCC and different modifier bitmask, where the
>> second one's modifier bitmask is for the next "N" modifiers?
>
> I was thinking along similar lines, but it could cause some problems with
> the ABI since applications currently assume that no fourcc will appear
> twice when enumerating formats. Admittedly, we never explicitly said in
> the spec that that can't happen, but it is kind of expected.
>
> There are ways around that, but if possible I'd like to avoid that.
>
> In theory there are up to 128 bits available but I can't help thinking
> that if you create more than, say, 64 modifiers for a HW platform you
> have a big mess anyway.
>
> If I am wrong, then I need to know because then I can prepare for it
> (or whoever is going to actually implement this...)

You're probably right, but I can't speak for everyone. From the
current state of drm_fourcc.h it looks like 64 would be plenty (there
aren't anywhere near 64 modifiers even defined right now). Adding in
the Arm compression formats will expand it a lot, but still not to 64
(yet).


Do all those modifiers make sense on the V4L2 side ? I expect that some
modifiers will mostly be used for buffers shared between the GPU and the
display engine, while others will be used by codecs. The sets will likely
overlap, but might not be identical.



All of the ones from drm_fourcc.h - I expect not. In the case of Arm's
framebuffer compression though, it's used in all our media IPs;
Display, GPU and Video, and ideally on all data exchanged between
them. For the most part the modifiers describing it could apply to
all three.

There's also the question of what you're calling a codec - mem2mem
rotation blocks/scalers/etc. exposed via V4L2 would likely want the
same set as any display device which consumes their output (which I
think puts them firmly in the shared between the XXX and display
engine camp).

Cheers,
-Brian


> If the number of modifiers is expected to be limited then making 64 bits
> available would be good enough, at least for now.
>
> BTW, is a modifier always optional? I.e. for all fourccs, is the
> unmodified format always available? Or are there fourccs that require the
> use of a modifier?

We do actually have one or two formats which are only supported with a
modifier (on our HW).


--
Regards,

Laurent Pinchart


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

Re: [RFC PATCH 1/5] drm/i915: Always wait for flip_done

[Maarten Lankhorst]

Op 30-08-17 om 15:40 schreef Daniel Vetter:
> On Wed, Aug 30, 2017 at 02:54:28PM +0200, Maarten Lankhorst wrote:
>> Op 30-08-17 om 14:43 schreef Daniel Vetter:
>>> On Wed, Aug 30, 2017 at 02:17:48PM +0200, Maarten Lankhorst wrote:
 The next commit removes the wait for flip_done in in
 drm_atomic_helper_commit_cleanup_done, but we need it for the tests
 to pass. Instead of using complicated vblank tracking which ends
 up being ignored anyway, call the correct atomic helper. :)

 RFC because I'm not completely sure what we want to do with the vblank 
 waiting,
 I think for now this patch is the right way to go until we decide because 
 it
 preserves the status quo when drm_crtc_commit was introduced.

 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/i915/i915_drv.h  |  3 +-
  drivers/gpu/drm/i915/intel_display.c | 83 
 +++-
  2 files changed, 8 insertions(+), 78 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h 
 b/drivers/gpu/drm/i915/i915_drv.h
 index cbbafbfb0a55..de19621864a9 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -707,8 +707,7 @@ struct drm_i915_display_funcs {
struct drm_atomic_state *old_state);
void (*crtc_disable)(struct intel_crtc_state *old_crtc_state,
 struct drm_atomic_state *old_state);
 -  void (*update_crtcs)(struct drm_atomic_state *state,
 -   unsigned int *crtc_vblank_mask);
 +  void (*update_crtcs)(struct drm_atomic_state *state);
void (*audio_codec_enable)(struct drm_connector *connector,
   struct intel_encoder *encoder,
   const struct drm_display_mode 
 *adjusted_mode);
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 52c73b4dabaa..3f3cb96aa11e 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -12114,73 +12114,10 @@ u32 intel_crtc_get_vblank_counter(struct 
 intel_crtc *crtc)
return dev->driver->get_vblank_counter(dev, crtc->pipe);
  }
  
 -static void intel_atomic_wait_for_vblanks(struct drm_device *dev,
 -struct drm_i915_private *dev_priv,
 -unsigned crtc_mask)
 -{
 -  unsigned last_vblank_count[I915_MAX_PIPES];
 -  enum pipe pipe;
 -  int ret;
 -
 -  if (!crtc_mask)
 -  return;
 -
 -  for_each_pipe(dev_priv, pipe) {
 -  struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv,
 -pipe);
 -
 -  if (!((1 << pipe) & crtc_mask))
 -  continue;
 -
 -  ret = drm_crtc_vblank_get(&crtc->base);
 -  if (WARN_ON(ret != 0)) {
 -  crtc_mask &= ~(1 << pipe);
 -  continue;
 -  }
 -
 -  last_vblank_count[pipe] = drm_crtc_vblank_count(&crtc->base);
 -  }
 -
 -  for_each_pipe(dev_priv, pipe) {
 -  struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv,
 -pipe);
 -  long lret;
 -
 -  if (!((1 << pipe) & crtc_mask))
 -  continue;
 -
 -  lret = wait_event_timeout(dev->vblank[pipe].queue,
 -  last_vblank_count[pipe] !=
 -  drm_crtc_vblank_count(&crtc->base),
 -  msecs_to_jiffies(50));
 -
 -  WARN(!lret, "pipe %c vblank wait timed out\n", pipe_name(pipe));
 -
 -  drm_crtc_vblank_put(&crtc->base);
 -  }
 -}
 -
 -static bool needs_vblank_wait(struct intel_crtc_state *crtc_state)
 -{
 -  /* fb updated, need to unpin old fb */
 -  if (crtc_state->fb_changed)
 -  return true;
 -
 -  /* wm changes, need vblank before final wm's */
 -  if (crtc_state->update_wm_post)
 -  return true;
 -
 -  if (crtc_state->wm.need_postvbl_update)
 -  return true;
 -
 -  return false;
 -}
 -
  static void intel_update_crtc(struct drm_crtc *crtc,
  struct drm_atomic_state *state,
  struct drm_crtc_state *old_crtc_state,
 -struct drm_crtc_state *new_crtc_state,
 -unsigned int *crtc_vblank_mask)
 +struct drm_crtc_state *new_crtc_state)
  {
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
 @@ -12203,13 +12140,9 @@ static vo

[PATCH] staging: vboxvideo: Use CONFIG_DRM_KMS_FB_HELPER to check for fbdefio availability

[Hans de Goede]

Checking for CONFIG_FB_DEFERRED_IO is not the right thing to do since
the fbdev code may be built as a module while vboxvideo is builtin.

This can only happen when DRM_KMS_FB_HELPER is not set:
a) DRM_VBOXVIDEO selects DRM_KMS_HELPER
b) DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
c) DRM_KMS_FB_HELPER selects FB_DEFERRED_IO

So when DRM_KMS_FB_HELPER is set and vboxvideo is builtin then
FB_DEFERRED_IO must be builtin too.

This commit moves the #ifdefs around fbdefio code over to
CONFIG_DRM_KMS_FB_HELPER, as other drm drivers already do, fixing:

drivers/staging/vboxvideo/vbox_fb.o: In function `vbox_fbdev_fini':
vbox_fb.c:(.text+0x36): undefined reference to `fb_deferred_io_cleanup'

Signed-off-by: Hans de Goede 
---
 drivers/staging/vboxvideo/vbox_fb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_fb.c 
b/drivers/staging/vboxvideo/vbox_fb.c
index a85797b45ecf..8aed248db6e2 100644
--- a/drivers/staging/vboxvideo/vbox_fb.c
+++ b/drivers/staging/vboxvideo/vbox_fb.c
@@ -45,7 +45,7 @@
 #include "vbox_drv.h"
 #include "vboxvideo.h"
 
-#ifdef CONFIG_FB_DEFERRED_IO
+#ifdef CONFIG_DRM_KMS_FB_HELPER
 static struct fb_deferred_io vbox_defio = {
.delay = HZ / 30,
.deferred_io = drm_fb_helper_deferred_io,
@@ -173,7 +173,7 @@ static int vboxfb_create(struct drm_fb_helper *helper,
info->screen_base = bo->kmap.virtual;
info->screen_size = size;
 
-#ifdef CONFIG_FB_DEFERRED_IO
+#ifdef CONFIG_DRM_KMS_FB_HELPER
info->fbdefio = &vbox_defio;
fb_deferred_io_init(info);
 #endif
@@ -195,7 +195,7 @@ void vbox_fbdev_fini(struct drm_device *dev)
struct vbox_fbdev *fbdev = vbox->fbdev;
struct vbox_framebuffer *afb = &fbdev->afb;
 
-#ifdef CONFIG_FB_DEFERRED_IO
+#ifdef CONFIG_DRM_KMS_FB_HELPER
if (fbdev->helper.fbdev && fbdev->helper.fbdev->fbdefio)
fb_deferred_io_cleanup(fbdev->helper.fbdev);
 #endif
-- 
2.13.4

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

Re: [PATCH] drm: omapdrm: hdmi: Use PTR_ERR_OR_ZERO

[Laurent Pinchart]

Hi Himanshu,

Thank you for the patch.

On Tuesday, 29 August 2017 17:00:12 EEST Himanshu Jha wrote:
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
> 
> Signed-off-by: Himanshu Jha 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c  | 5 +
>  drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 5 +
>  drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 5 +
>  drivers/gpu/drm/omapdrm/dss/hdmi_phy.c   | 5 +
>  4 files changed, 4 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c index f169348..3bf81e1 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> @@ -676,10 +676,7 @@ static int hdmi_audio_register(struct device *dev)
>   dev, "omap-hdmi-audio", PLATFORM_DEVID_AUTO,
>   &pdata, sizeof(pdata));
> 
> - if (IS_ERR(hdmi.audio_pdev))
> - return PTR_ERR(hdmi.audio_pdev);
> -
> - return 0;
> + return PTR_ERR_OR_ZERO(hdmi.audio_pdev);
>  }
> 
>  /* HDMI HW IP initialisation */
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c index 365cf07..aafd723 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
> @@ -922,8 +922,5 @@ int hdmi4_core_init(struct platform_device *pdev, struct
> hdmi_core_data *core)
> 
>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core");
>   core->base = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(core->base))
> - return PTR_ERR(core->base);
> -
> - return 0;
> + return PTR_ERR_OR_ZERO(core->base);
>  }
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c index ab179ec..45c7b0f 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
> @@ -911,8 +911,5 @@ int hdmi5_core_init(struct platform_device *pdev, struct
> hdmi_core_data *core)
> 
>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core");
>   core->base = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(core->base))
> - return PTR_ERR(core->base);
> -
> - return 0;
> + return PTR_ERR_OR_ZERO(core->base);
>  }
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c index a156292..12a85cb 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
> @@ -194,8 +194,5 @@ int hdmi_phy_init(struct platform_device *pdev, struct
> hdmi_phy_data *phy,
> 
>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy");
>   phy->base = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(phy->base))
> - return PTR_ERR(phy->base);
> -
> - return 0;
> + return PTR_ERR_OR_ZERO(phy->base);
>  }


-- 
Regards,

Laurent Pinchart

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

Re: DRM Format Modifiers in v4l2

[Laurent Pinchart]

Hi Brian,

On Wednesday, 30 August 2017 13:32:01 EEST Brian Starkey wrote:
> On Wed, Aug 30, 2017 at 11:53:58AM +0200, Hans Verkuil wrote:
> > On 30/08/17 11:36, Brian Starkey wrote:
> >> On Wed, Aug 30, 2017 at 10:10:01AM +0200, Hans Verkuil wrote:
> >>> On 30/08/17 09:50, Daniel Vetter wrote:
>  On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
> > The fact is, adding special formats for each combination is
> > unmanageable - we're talking dozens in the case of our hardware.
>  
>  Hm right, we can just remap the special combos to the drm-fourcc +
>  modifier style. Bonus point if v4l does that in the core so not
>  everyone has to reinvent that wheel :-)
> >>> 
> >>> Probably not something we'll do: there are I believe only two drivers
> >>> that are affected (exynos & mediatek), so they can do that in their
> >>> driver.
> >>> 
> >>> Question: how many modifiers will typically apply to a format? I ask
> >>> because I realized that V4L2 could use VIDIOC_ENUMFMT to make the link
> >>> between a fourcc and modifiers:
> >>> 
> >>> https://hverkuil.home.xs4all.nl/spec/uapi/v4l/vidioc-enum-fmt.html
> >>> 
> >>> The __u32 reserved[4] array can be used to provide a bitmask to modifier
> >>> indices (for the integer menu control). It's similar to what drm does,
> >>> except instead of modifiers mapping to fourccs it is the other way
> >>> around.
> >>> 
> >>> This would avoid having to change the modifiers control whenever a new
> >>> format is set and it makes it easy to enumerate all combinations.
> >>> 
> >>> But this only works if the total number of modifiers used by a single
> >>> driver is expected to remain small (let's say no more than 64).
> >> 
> >> In our current (yet to be submitted) description, we've got around a
> >> dozen modifiers for any one format to describe our compression
> >> variants. We have a lot of on/off toggles which leads to combinatorial
> >> expansion, so it can grow pretty quickly (though I am trying to limit
> >> the valid combinations as much as possible).
> >> 
> >> How about if the mask fills up then VIDIOC_ENUM_FMT can return another
> >> fmtdsc with the same FourCC and different modifier bitmask, where the
> >> second one's modifier bitmask is for the next "N" modifiers?
> >
> > I was thinking along similar lines, but it could cause some problems with
> > the ABI since applications currently assume that no fourcc will appear
> > twice when enumerating formats. Admittedly, we never explicitly said in
> > the spec that that can't happen, but it is kind of expected.
> >
> > There are ways around that, but if possible I'd like to avoid that.
> >
> > In theory there are up to 128 bits available but I can't help thinking
> > that if you create more than, say, 64 modifiers for a HW platform you
> > have a big mess anyway.
> >
> > If I am wrong, then I need to know because then I can prepare for it
> > (or whoever is going to actually implement this...)
> 
> You're probably right, but I can't speak for everyone. From the
> current state of drm_fourcc.h it looks like 64 would be plenty (there
> aren't anywhere near 64 modifiers even defined right now). Adding in
> the Arm compression formats will expand it a lot, but still not to 64
> (yet).

Do all those modifiers make sense on the V4L2 side ? I expect that some 
modifiers will mostly be used for buffers shared between the GPU and the 
display engine, while others will be used by codecs. The sets will likely 
overlap, but might not be identical.

> > If the number of modifiers is expected to be limited then making 64 bits
> > available would be good enough, at least for now.
> >
> > BTW, is a modifier always optional? I.e. for all fourccs, is the
> > unmodified format always available? Or are there fourccs that require the
> > use of a modifier?
> 
> We do actually have one or two formats which are only supported with a
> modifier (on our HW).

-- 
Regards,

Laurent Pinchart

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

Re: DRM Format Modifiers in v4l2

[Laurent Pinchart]

Hi Brian,

On Tuesday, 29 August 2017 12:19:43 EEST Brian Starkey wrote:
> On Fri, Aug 25, 2017 at 10:14:03AM +0200, Hans Verkuil wrote:
> >On 24/08/17 14:26, Brian Starkey wrote:
> >> On Thu, Aug 24, 2017 at 01:37:35PM +0200, Hans Verkuil wrote:
> >>> On 08/24/17 13:14, Brian Starkey wrote:
>  On Mon, Aug 21, 2017 at 06:36:29PM +0200, Hans Verkuil wrote:
> > On 08/21/2017 06:01 PM, Daniel Vetter wrote:
> >> On Mon, Aug 21, 2017 at 5:52 PM, Brian Starkey wrote:
> >>> Hi all,
> >>> 
> >>> I couldn't find this topic talked about elsewhere, but apologies if
> >>> it's a duplicate - I'll be glad to be steered in the direction of a
> >>> thread.
> >>> 
> >>> We'd like to support DRM format modifiers in v4l2 in order to share
> >>> the description of different (mostly proprietary) buffer formats
> >>> between e.g. a v4l2 device and a DRM device.
> >>> 
> >>> DRM format modifiers are defined in include/uapi/drm/drm_fourcc.h
> >>> and are a vendor-namespaced 64-bit value used to describe various
> >>> vendor-specific buffer layouts. They are combined with a (DRM)
> >>> FourCC code to give a complete description of the data contained in
> >>> a buffer.
> >>> 
> >>> The same modifier definition is used in the Khronos EGL extension
> >>> EGL_EXT_image_dma_buf_import_modifiers, and is supported in the
> >>> Wayland linux-dmabuf protocol.
> >>> 
> >>> 
> >>> This buffer information could of course be described in the
> >>> vendor-specific part of V4L2_PIX_FMT_*, but this would duplicate the
> >>> information already defined in drm_fourcc.h. Additionally, there
> >>> would be quite a format explosion where a device supports a dozen or
> >>> more formats, all of which can use one or more different
> >>> layouts/compression schemes.
> >>> 
> >>> So, I'm wondering if anyone has views on how/whether this could be
> >>> incorporated?
> >>> 
> >>> I spoke briefly about this to Laurent at LPC last year, and he
> >>> suggested v4l2_control as one approach.
> >>> 
> >>> I also wondered if could be added in v4l2_pix_format_mplane - looks
> >>> like there's 8 bytes left before it exceeds the 200 bytes, or could
> >>> go in the reserved portion of v4l2_plane_pix_format.
> >>> 
> >>> Thanks for any thoughts,
> >> 
> >> One problem is that the modifers sometimes reference the DRM fourcc
> >> codes. v4l has a different (and incompatible set) of fourcc codes,
> >> whereas all the protocols and specs (you can add DRI3.1 for Xorg to
> >> that list btw) use both drm fourcc and drm modifiers.
> >> 
> >> This might or might not make this proposal unworkable, but it's
> >> something I'd at least review carefully.
> >> 
> >> Otherwise I think it'd be great if we could have one namespace for
> >> all modifiers, that's pretty much why we have them. Please also note
> >> that for drm_fourcc.h we don't require an in-kernel user for a new
> >> modifier since a bunch of them might need to be allocated just for
> >> userspace-to-userspace buffer sharing (e.g. in EGL/vk). One example
> >> for this would be compressed surfaces with fast-clearing, which is
> >> planned for i915 (but current hw can't scan it out). And we really
> >> want to have one namespace for everything.
> > 
> > Who sets these modifiers? Kernel or userspace? Or can it be set by
> > both? I assume any userspace code that sets/reads this is code
> > specific for that hardware?
>  
>  I think normally the modifier would be set by userspace. However it
>  might not necessarily be device-specific code. In DRM the intention is
>  for userspace to query the set of modifiers which are supported, and
>  then use them without necessarily knowing exactly what they mean
>  (insofar as that is possible).
>  
>  e.g. if I have two devices which support MODIFIER_FOO, I could attempt
>  to share a buffer between them which uses MODIFIER_FOO without
>  necessarily knowing exactly what it is/does.
>  
> > I think Laurent's suggestion of using a 64 bit V4L2 control for this
> > makes the most sense.
> > 
> > Especially if you can assume that whoever sets this knows the
> > hardware.
> > 
> > I think this only makes sense if you pass buffers from one HW device
> > to another.
> > 
> > Because you cannot expect generic video capture code to be able to
> > interpret all the zillion different combinations of modifiers.
>  
>  I don't quite follow this last bit. The control could report the set
>  of supported modifiers.
> >>> 
> >>> What I mean was: an application can use the modifier to give buffers
> >>> from one device to another without needing to understand it.
> >>> 
> >>> But a generic video capture application that processes the video itself
> >>> can

Re: DRM Format Modifiers in v4l2

[Laurent Pinchart]

Hi Brian,

On Thursday, 24 August 2017 14:14:31 EEST Brian Starkey wrote:
> On Mon, Aug 21, 2017 at 06:36:29PM +0200, Hans Verkuil wrote:
> > On 08/21/2017 06:01 PM, Daniel Vetter wrote:
> >> On Mon, Aug 21, 2017 at 5:52 PM, Brian Starkey wrote:
> >>> Hi all,
> >>> 
> >>> I couldn't find this topic talked about elsewhere, but apologies if
> >>> it's a duplicate - I'll be glad to be steered in the direction of a
> >>> thread.
> >>> 
> >>> We'd like to support DRM format modifiers in v4l2 in order to share
> >>> the description of different (mostly proprietary) buffer formats
> >>> between e.g. a v4l2 device and a DRM device.
> >>> 
> >>> DRM format modifiers are defined in include/uapi/drm/drm_fourcc.h and
> >>> are a vendor-namespaced 64-bit value used to describe various
> >>> vendor-specific buffer layouts. They are combined with a (DRM) FourCC
> >>> code to give a complete description of the data contained in a buffer.
> >>> 
> >>> The same modifier definition is used in the Khronos EGL extension
> >>> EGL_EXT_image_dma_buf_import_modifiers, and is supported in the
> >>> Wayland linux-dmabuf protocol.
> >>> 
> >>> 
> >>> This buffer information could of course be described in the
> >>> vendor-specific part of V4L2_PIX_FMT_*, but this would duplicate the
> >>> information already defined in drm_fourcc.h. Additionally, there
> >>> would be quite a format explosion where a device supports a dozen or
> >>> more formats, all of which can use one or more different
> >>> layouts/compression schemes.
> >>> 
> >>> So, I'm wondering if anyone has views on how/whether this could be
> >>> incorporated?
> >>> 
> >>> I spoke briefly about this to Laurent at LPC last year, and he
> >>> suggested v4l2_control as one approach.
> >>> 
> >>> I also wondered if could be added in v4l2_pix_format_mplane - looks
> >>> like there's 8 bytes left before it exceeds the 200 bytes, or could go
> >>> in the reserved portion of v4l2_plane_pix_format.

We're considering reworking the format ioctls at some point. We don't 
necessarily need to wait until then to implement support for modifiers, but we 
will have an opportunity to integrate them with formats at that point.

> >>> Thanks for any thoughts,
> >> 
> >> One problem is that the modifers sometimes reference the DRM fourcc
> >> codes. v4l has a different (and incompatible set) of fourcc codes,
> >> whereas all the protocols and specs (you can add DRI3.1 for Xorg to
> >> that list btw) use both drm fourcc and drm modifiers.
> >> 
> >> This might or might not make this proposal unworkable, but it's
> >> something I'd at least review carefully.
> >> 
> >> Otherwise I think it'd be great if we could have one namespace for all
> >> modifiers, that's pretty much why we have them. Please also note that
> >> for drm_fourcc.h we don't require an in-kernel user for a new modifier
> >> since a bunch of them might need to be allocated just for
> >> userspace-to-userspace buffer sharing (e.g. in EGL/vk). One example
> >> for this would be compressed surfaces with fast-clearing, which is
> >> planned for i915 (but current hw can't scan it out). And we really
> >> want to have one namespace for everything.
> >
> > Who sets these modifiers? Kernel or userspace? Or can it be set by both?
> > I assume any userspace code that sets/reads this is code specific for that
> > hardware?
> 
> I think normally the modifier would be set by userspace. However it
> might not necessarily be device-specific code. In DRM the intention is
> for userspace to query the set of modifiers which are supported, and
> then use them without necessarily knowing exactly what they mean
> (insofar as that is possible).
> 
> e.g. if I have two devices which support MODIFIER_FOO, I could attempt
> to share a buffer between them which uses MODIFIER_FOO without
> necessarily knowing exactly what it is/does.

Userspace could certainly set modifiers blindly, but the point of modifiers is 
to generate side effects benefitial to the use case at hand (for instance by 
optimizing the memory access pattern). To use them meaningfully userspace 
would need to have at least an idea of the side effects they generate.

> > I think Laurent's suggestion of using a 64 bit V4L2 control for this makes
> > the most sense.
> >
> > Especially if you can assume that whoever sets this knows the hardware.
> >
> > I think this only makes sense if you pass buffers from one HW device to
> > another.
> >
> > Because you cannot expect generic video capture code to be able to
> > interpret all the zillion different combinations of modifiers.
> 
> I don't quite follow this last bit. The control could report the set
> of supported modifiers.
> 
> However, in DRM the API lets you get the supported formats for each
> modifier as-well-as the modifier list itself. I'm not sure how exactly
> to provide that in a control.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCHv4 4/5] cec-gpio: add HDMI CEC GPIO driver

[Hans Verkuil]

On 31/08/17 16:10, Linus Walleij wrote:
> On Thu, Aug 31, 2017 at 1:01 PM, Hans Verkuil  wrote:
> 
>> From: Hans Verkuil 
>>
>> Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework.
>>
>> While I have heard of SoCs that use the GPIO pin for CEC (apparently an
>> early RockChip SoC used that), the main use-case of this driver is to
>> function as a debugging tool.
>>
>> By connecting the CEC line to a GPIO pin on a Raspberry Pi 3 for example
>> it turns it into a CEC debugger and protocol analyzer.
>>
>> With 'cec-ctl --monitor-pin' the CEC traffic can be analyzed.
>>
>> But of course it can also be used with any hardware project where the
>> HDMI CEC line is hooked up to a pull-up gpio line.
>>
>> In addition this has (optional) support for tracing HPD changes if the
>> HPD is connected to a GPIO.
>>
>> Signed-off-by: Hans Verkuil 
> 
> This looks nice!
> Reviewed-by: Linus Walleij 

Thank you for the gpio crash course! :-)

Hans

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

Re: [PATCHv4 4/5] cec-gpio: add HDMI CEC GPIO driver

[Linus Walleij]

On Thu, Aug 31, 2017 at 1:01 PM, Hans Verkuil  wrote:

> From: Hans Verkuil 
>
> Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework.
>
> While I have heard of SoCs that use the GPIO pin for CEC (apparently an
> early RockChip SoC used that), the main use-case of this driver is to
> function as a debugging tool.
>
> By connecting the CEC line to a GPIO pin on a Raspberry Pi 3 for example
> it turns it into a CEC debugger and protocol analyzer.
>
> With 'cec-ctl --monitor-pin' the CEC traffic can be analyzed.
>
> But of course it can also be used with any hardware project where the
> HDMI CEC line is hooked up to a pull-up gpio line.
>
> In addition this has (optional) support for tracing HPD changes if the
> HPD is connected to a GPIO.
>
> Signed-off-by: Hans Verkuil 

This looks nice!
Reviewed-by: Linus Walleij 

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

Re: [PATCHv4 3/5] dt-bindings: document the CEC GPIO bindings

[Linus Walleij]

On Thu, Aug 31, 2017 at 1:01 PM, Hans Verkuil  wrote:

> From: Hans Verkuil 
>
> Document the bindings for the cec-gpio module for hardware where the
> CEC line and optionally the HPD line are connected to GPIO lines.
>
> Signed-off-by: Hans Verkuil 

Reviewed-by: Linus Walleij 

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

Re: [PATCH v2 1/2] drm/bridge: add Silicon Image SiI9234 driver

[Laurent Pinchart]

Hi Maciej,

Thank you for the patch.

On Thursday, 31 August 2017 15:27:13 EEST Maciej Purski wrote:
> SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
> It is controlled via I2C bus. Its interaction with other
> devices in video pipeline is performed mainly on HW level.
> The only interaction it does on device driver level is
> filtering-out unsupported video modes, it exposes drm_bridge
> interface to perform this operation.
> 
> This patch is based on the code refactored by Tomasz Stanislawski
> , which was initially developed by:
> Adam Hampson 
> Erik Gilling 
> Shankar Bandal 
> Dharam Kumar 
> 
> Signed-off-by: Maciej Purski 
> ---
> Changes in v2:
> - use bulk_requlators instead of single one
> - substitute some of the magic values with macros
> - improve coding style
> - improved error handling in sii9234_probe()
> ---
>  .../devicetree/bindings/display/bridge/sii9234.txt |  34 +
>  drivers/gpu/drm/bridge/Kconfig |   8 +
>  drivers/gpu/drm/bridge/Makefile|   1 +
>  drivers/gpu/drm/bridge/sii9234.c   | 993 ++
>  4 files changed, 1036 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/bridge/sii9234.txt create mode
> 100644 drivers/gpu/drm/bridge/sii9234.c
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt
> b/Documentation/devicetree/bindings/display/bridge/sii9234.txt new file
> mode 100644
> index 000..3ce7413
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
> @@ -0,0 +1,34 @@
> +Silicon Image SiI9234 HDMI/MHL bridge bindings
> +
> +Required properties:
> + - compatible : "sil,sii9234".
> + - reg : I2C address for TPI interface, use 0x39
> + - avcc33-supply : MHL/USB Switch Supply Voltage (3.3V)
> + - iovcc18-supply : I/O Supply Voltage (1.8V)
> + - avcc12-supply : TMDS Analog Supply Voltage (1.2V)
> + - cvcc12-supply : Digital Core Supply Voltage (1.2V)
> + - interrupts, interrupt-parent: interrupt specifier of INT pin
> + - reset-gpios: gpio specifier of RESET pin (active low)
> + - video interfaces: Device node can contain video interface port
> + node for HDMI encoder according to [1].
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt

Doesn't this chip have two ports, one input connected to the SoC and one 
output connected to an HDMI connector ? If so there should be two ports in DT 
too.

> +Example:
> + sii9234@39 {
> + compatible = "sil,sii9234";
> + reg = <0x39>;
> + avcc33-supply = <&vcc33mhl>;
> + iovcc18-supply = <&vcc18mhl>;
> + avcc12-supply = <&vsil12>;
> + cvcc12-supply = <&vsil12>;
> + reset-gpios = <&gpf3 4 GPIO_ACTIVE_LOW>;
> + interrupt-parent = <&gpf3>;
> + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
> +
> + port {
> + mhl_to_hdmi: endpoint {
> + remote-endpoint = <&hdmi_to_mhl>;

It would be useful to include the remote DT nodes in the example too.

> + };
> + };
> + };

-- 
Regards,

Laurent Pinchart

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

[Bug 92248] [KBL/SKL/BYT/BXT/GLK] igt/kms_plane_scaling fail

[bugzilla-daemon]

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

--- Comment #36 from Hector Velazquez 
 ---
Created attachment 133902
  --> https://bugs.freedesktop.org/attachment.cgi?id=133902&action=edit
Dmesg.log (GLK)

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

[Bug 92248] [KBL/SKL/BYT/BXT/GLK] igt/kms_plane_scaling fail

[bugzilla-daemon]

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

--- Comment #35 from Hector Velazquez 
 ---
Created attachment 133901
  --> https://bugs.freedesktop.org/attachment.cgi?id=133901&action=edit
Output(GLK)

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

[Bug 92248] [KBL/SKL/BYT/BXT/GLK] igt/kms_plane_scaling fail

[bugzilla-daemon]

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

Hector Velazquez  changed:

   What|Removed |Added

Summary|[KBL/SKL/BYT/BXT]   |[KBL/SKL/BYT/BXT/GLK]
   |igt/kms_plane_scaling fail  |igt/kms_plane_scaling fail

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

[Bug 92248] [KBL/SKL/BYT/BXT] igt/kms_plane_scaling fail

[bugzilla-daemon]

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

--- Comment #34 from Hector Velazquez 
 ---
The following tests Fail on GLK with this configuration

Test List:

igt@kms_plane_scaling


==
Output
==

(kms_plane_scaling:3256) igt-kms-DEBUG: display: A.2: plane_set_position(0,0)
(kms_plane_scaling:3256) igt-kms-DEBUG: display: A.2: plane_set_size
(1920x1080)
(kms_plane_scaling:3256) igt-kms-DEBUG: display: commit {
(kms_plane_scaling:3256) igt-kms-DEBUG: display: SetPlane A.2, fb 78, src =
(0, 0) 1920x1080 dst = (0, 0) 1920x1080
(kms_plane_scaling:3256) igt-kms-DEBUG: display: }
(kms_plane_scaling:3256) igt-kms-DEBUG: display: A.2: fb_set_position(100,100)
(kms_plane_scaling:3256) igt-kms-DEBUG: display: A.2: fb_set_size(500x500)
(kms_plane_scaling:3256) igt-kms-DEBUG: display: A.2: plane_set_position(10,10)
(kms_plane_scaling:3256) igt-kms-DEBUG: display: A.2: plane_set_size
(1900x1060)
(kms_plane_scaling:3256) igt-kms-DEBUG: display: commit {
(kms_plane_scaling:3256) igt-kms-DEBUG: display: SetPlane A.2, fb 78, src =
(100, 100) 500x500 dst = (10, 10) 1900x1060
(kms_plane_scaling:3256) igt-kms-DEBUG: display: }
(kms_plane_scaling:3256) igt-kms-DEBUG: display: A.2: fb_set_position(0,0)
(kms_plane_scaling:3256) igt-kms-DEBUG: display: A.2: fb_set_size(1920x1080)
(kms_plane_scaling:3256) igt-kms-DEBUG: display: A.2: plane_set_position(10,10)
(kms_plane_scaling:3256) igt-kms-DEBUG: display: A.2: plane_set_size (500x281)
(kms_plane_scaling:3256) igt-kms-DEBUG: display: commit {
(kms_plane_scaling:3256) igt-kms-DEBUG: display: SetPlane A.2, fb 78, src =
(0, 0) 1920x1080 dst = (10, 10) 500x281
(kms_plane_scaling:3256) igt-kms-CRITICAL: Test assertion failure function
igt_drm_plane_commit, file igt_kms.c:2244:
(kms_plane_scaling:3256) igt-kms-CRITICAL: Failed assertion: ret == 0
(kms_plane_scaling:3256) igt-kms-CRITICAL: Last errno: 22, Invalid argument
(kms_plane_scaling:3256) igt-kms-CRITICAL: error: -22 != 0
(kms_plane_scaling:3256) igt-core-INFO: Stack trace:
(kms_plane_scaling:3256) igt-core-INFO:   #0 [__igt_fail_assert+0x101]
(kms_plane_scaling:3256) igt-core-INFO:   #1 [do_display_commit+0xa9c]
(kms_plane_scaling:3256) igt-core-INFO:   #2 [+0xa9c]
  END  
Stack trace:
  #0 [__igt_fail_assert+0x101]
  #1 [do_display_commit+0xa9c]
  #2 [+0xa9c]
(kms_plane_scaling:3256) igt-core-DEBUG: Exiting with status code 99



This is my configuration:

==
Graphic stack
==

Component: drm
tag: libdrm-2.4.81-51-gf19dbb7
commit: f19dbb79fe54994ecd505ac67ad15d19f591933a

Component: cairo
tag: 1.15.6-25-g12b875a
commit: 12b875aef374636d1693a631524dd3b622277415

Component: intel-gpu-tools
tag: intel-gpu-tools-1.19-206-g60f6a12
commit: 60f6a12195395934f179d5ecc080353190d19a6c

Component: piglit
tag: piglit-v1
commit: 739bcd89179ea9aa752f2f5c9eb405fb9dd396b0

==
 Software
==
kernel version  : 4.13.0-rc6-drm-tip-ww35-commit-00b77f6+
hostname: GLK-2-GLKRVP1DDR405
architecture: x86_64
os version  : Ubuntu 16.10
os codename : yakkety
kernel driver   : i915
bios revision   : 60.34
bios release date   : 08/09/2017
ksc : 1.41
hardware acceleration   : disabled
swap partition  : enabled on (/dev/sda3)

==
Graphic drivers
==
grep: /opt/X11R7/var/log/Xorg.0.log: No such file or directory
libdrm  : 2.4.83
cairo   : 1.15.7
intel-gpu-tools (tag)   : intel-gpu-tools-1.19-206-g60f6a12
intel-gpu-tools (commit): 60f6a12

==
 Hardware
==
platform   : Geminilake
motherboard model  : Geminilake
motherboard id : GLKRVP1DDR4(05)
form factor: Hand Held
manufacturer   : IntelCorp.
cpu family : Other
cpu family id  : 6
cpu information: Genuine Intel(R) CPU @ 1.10GHz
gpu card   : Intel Corporation Device 3185 (rev 03) (prog-if 00
[VGA controller])
memory ram : 3.7 GB
max memory ram : 16 GB
cpu thread : 2
cpu core   : 2
cpu model  : 122
cpu stepping   : 1
socket : Other
hard drive : 74GiB (80GB)
current cd clock frequency : 79200 kHz
maximum cd clock frequency : 316800 kHz
displays connected : eDP-1 DP-1 HDMI-A-2

==
 Firmware
==
dmc fw loaded : no
guc fw loaded 

Re: [PATCH 6/6] drm/tinydrm: Support device unplug

[Laurent Pinchart]

Hi Daniel and Noralf,

On Wednesday, 30 August 2017 20:18:49 EEST Daniel Vetter wrote:
> On Wed, Aug 30, 2017 at 6:31 PM, Noralf Trønnes  wrote:
> > Den 28.08.2017 23.56, skrev Daniel Vetter:
> >> On Mon, Aug 28, 2017 at 07:17:48PM +0200, Noralf Trønnes wrote:
> >>> Support device unplugging to make tinydrm suitable for USB devices.
> >>> 
> >>> Cc: David Lechner 
> >>> Signed-off-by: Noralf Trønnes 
> >>> ---
> >>> 
> >>> drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 69 ++---
> >>> drivers/gpu/drm/tinydrm/mi0283qt.c  |  4 ++
> >>> drivers/gpu/drm/tinydrm/mipi-dbi.c  |  5 ++-
> >>> drivers/gpu/drm/tinydrm/repaper.c   |  9 +++-
> >>> drivers/gpu/drm/tinydrm/st7586.c|  9 +++-
> >>> include/drm/tinydrm/tinydrm.h   |  5 +++
> >>> 6 files changed, 87 insertions(+), 14 deletions(-)
> >>> 
> >>> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> >>> b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> >>> index f11f4cd..3ccbcc5 100644
> >>> --- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> >>> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> >>> @@ -32,6 +32,29 @@
> >>>   * The driver allocates &tinydrm_device, initializes it using
> >>>   * devm_tinydrm_init(), sets up the pipeline using
> >>> tinydrm_display_pipe_init()
> >>>   * and registers the DRM device using devm_tinydrm_register().
> >>> + *
> >>> + * Device unplug
> >>> + * -
> >>> + *
> >>> + * tinydrm supports device unplugging when there's still open DRM or
> >>> fbdev file
> >>> + * handles.
> >>> + *
> >>> + * There are 2 ways for driver-device unbinding to happen:
> >>> + *
> >>> + * - The driver module is unloaded causing the driver to be
> >>> unregistered.
> >>> + *   This can't happen as long as there's open file handles because a
> >>> reference
> >>> + *   is taken on the module.
> >> 
> >> Aside: you can do that, but then it works like a hw unplug, through the
> >> unbind property in sysfs.
> > 
> > The module is still pinned isn't it?
> 
> Yup, but only the code is pinned, not any of the datastructures like
> drm_device.
>
> > I can add sysfs unbind as a third way of triggering unbind:
> >  * - The sysfs driver _unbind_ file can be used to unbind the driver form
> > the
> >  *   device. This can happen any time.
> >  *

Sounds good to me.

> >>> + *
> >>> + * - The device is removed (USB, Device Tree overlay).
> >>> + *   This can happen at any time.
> >>> + *
> >>> + * The driver needs to protect device resources from access after the
> >>> device is
> >>> + * gone. This is done checking drm_dev_is_unplugged(), typically in
> >>> + * &drm_framebuffer_funcs.dirty, &drm_simple_display_pipe_funcs.enable
> >>> and
> >>> + * \.disable. Resources that doesn't face userspace and is only used

s/doesn't/don't/
s/and is/and are/

> >>> with the
> >>> + * device can be setup using devm\_ functions, but &tinydrm_device must
> >>> be
> >>> + * allocated using plain kzalloc() since it's lifetime can exceed that
> >>> of the

s/it's/its/

> >>> + * device. tinydrm_release() will free the structure.
> >> 
> >> So here's a bit a dragon: There's no prevention of is_unplugged racing
> >> against a drm_dev_unplug(). There's been various attempts to fixing this,
> >> but they're all somewhat ugly.
> >> 
> >> Either way, that's a bug in the drm core :-)
> >> 
> >>>*/
> >>>
> >>> /**
> >>> @@ -138,6 +161,29 @@ static const struct drm_mode_config_funcs
> >>> tinydrm_mode_config_funcs = {
> >>> .atomic_commit = drm_atomic_helper_commit,
> >>>   };
> >>> +/**
> >>> + * tinydrm_release - DRM driver release helper
> >>> + * @drm: DRM device
> >>> + *
> >>> + * This function cleans up and finalizes &drm_device and frees
> >>> &tinydrm_device.
> >>> + *
> >>> + * Drivers must use this as their &drm_driver->release callback.
> >>> + */
> >>> +void tinydrm_release(struct drm_device *drm)
> >>> +{
> >>> +   struct tinydrm_device *tdev = drm_to_tinydrm(drm);
> >>> +
> >>> +   DRM_DEBUG_DRIVER("\n");
> >>> +
> >>> +   drm_mode_config_cleanup(drm);
> >>> +   drm_dev_fini(drm);
> >>> +
> >>> +   mutex_destroy(&tdev->dirty_lock);
> >>> +   kfree(tdev->fbdev_cma);
> >>> +   kfree(tdev);
> >>> +}
> >>> +EXPORT_SYMBOL(tinydrm_release);
> >>> +
> >>>   static int tinydrm_init(struct device *parent, struct tinydrm_device
> >>> *tdev,
> >>> const struct drm_framebuffer_funcs *fb_funcs,
> >>> struct drm_driver *driver)
> >>> @@ -160,8 +206,6 @@ static int tinydrm_init(struct device *parent,
> >>> struct tinydrm_device *tdev,
> >>>   static void tinydrm_fini(struct tinydrm_device *tdev)
> >>>   {
> >>> -   drm_mode_config_cleanup(&tdev->drm);
> >>> -   mutex_destroy(&tdev->dirty_lock);
> >>> drm_dev_unref(&tdev->drm);
> >>>   }
> >>> @@ -178,8 +222,8 @@ static void devm_tinydrm_release(void *data)
> >>>   * @driver: DRM driver
> >>>   *
> >>>   * This function initializes @tdev, the underly

[PATCH v2 2/2] ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board

[Maciej Purski]

Add HDMI and Sil9234 MHL converter to Trats2 board.
Following in SoC devices have been enabled:
- HDMI (HDMI signal encoder),
- Mixer (video buffer scanout device),
- I2C_5 bus (used for HDMI DDC)
- I2C_8 bus (used for HDMI_PHY control).

Based on previous work by:
Tomasz Stanislawski 

Signed-off-by: Maciej Purski 
---
Changes in v2:
- fix commit message
- add regulators nodes to model actual physical connections
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 111 
 1 file changed, 111 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 35e9b94..0180753 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -97,6 +97,34 @@
gpio = <&gpj0 5 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+   vsil12: voltage-regulator-6 {
+   compatible = "regulator-fixed";
+   regulator-name = "VSIL_1.2V";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   vin-supply = <&buck7_reg>;
+   };
+
+   vcc33mhl: voltage-regulator-7 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_3.3_MHL";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vcc18mhl: voltage-regulator-8 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_1.8_MHL";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
};
 
gpio-keys {
@@ -229,6 +257,36 @@
};
};
 
+   i2c-mhl {
+   compatible = "i2c-gpio";
+   gpios = <&gpf0 4 GPIO_ACTIVE_HIGH &gpf0 6 GPIO_ACTIVE_HIGH>;
+   i2c-gpio,delay-us = <100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pinctrl-0 = <&i2c_mhl_bus>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   sii9234: sii9234@39 {
+   compatible = "sil,sii9234";
+   avcc33-supply = <&vcc33mhl>;
+   iovcc18-supply = <&vcc18mhl>;
+   avcc12-supply = <&vsil12>;
+   cvcc12-supply = <&vsil12>;
+   reset-gpios = <&gpf3 4 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <&gpf3>;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+   reg = <0x39>;
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <&hdmi_to_mhl>;
+   };
+   };
+   };
+   };
+
camera: camera {
pinctrl-0 = <&cam_port_a_clk_active &cam_port_b_clk_active>;
pinctrl-names = "default";
@@ -522,6 +580,29 @@
status = "okay";
 };
 
+&hdmi {
+   hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&hdmi_hpd>;
+   vdd-supply = <&ldo3_reg>;
+   vdd_osc-supply = <&ldo4_reg>;
+   vdd_pll-supply = <&ldo3_reg>;
+   ddc = <&i2c_5>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+   hdmi_to_mhl: endpoint {
+   remote-endpoint = <&mhl_to_hdmi>;
+   };
+   };
+   };
+};
+
 &hsotg {
vusb_d-supply = <&ldo15_reg>;
vusb_a-supply = <&ldo12_reg>;
@@ -600,6 +681,11 @@
};
 };
 
+
+&i2c_5 {
+   status = "okay";
+};
+
 &i2c_7 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
@@ -894,12 +980,20 @@
};
 };
 
+&i2c_8 {
+   status = "okay";
+};
+
 &i2s0 {
pinctrl-0 = <&i2s0_bus>;
pinctrl-names = "default";
status = "okay";
 };
 
+&mixer {
+   status = "okay";
+};
+
 &mshc_0 {
num-slots = <1>;
broken-cd;
@@ -926,6 +1020,18 @@
pinctrl-names = "default";
pinctrl-0 = <&sleep0>;
 
+   mhl_int: mhl-int {
+   samsung,pins = "gpf3-5";
+   samsung,pin-pud = <0>;
+   };
+
+   i2c_mhl_bus: i2c-mhl-bus {
+

[PATCH v2 0/2] add Silicon Image SiI9234 driver

[Maciej Purski]

Hi everyone,

These patches are a continuation of work by Tomasz Stanislawski on sii9324 
driver, which was described
in th following letter:
https://lists.freedesktop.org/archives/dri-devel/2014-April/057481.html

The main differences from the previous code are:
* driver moved to /gpu/drm/bridge/ and integrated with drm/bridge subsystem
* added filtering-out unsupported display modes
* changed gpio interface to up-to-date
* changed interrupt handling
* improve code style
* add hdmi and sii9324 to exynos4412-trats2 device tree

All comments are welcome.

Regards,
Maciej Purski

Changes in v2:
- regulators used in driver now model all physical regulators
  used by the device
- substitute some of the magic values with macros
- improve coding style
- improve error handling in sii9234_probe()
- fix commit message

Maciej Purski (2):
  drm/bridge: add Silicon Image SiI9234 driver
  ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board

 .../devicetree/bindings/display/bridge/sii9234.txt |  34 +
 arch/arm/boot/dts/exynos4412-trats2.dts| 111 +++
 drivers/gpu/drm/bridge/Kconfig |   8 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/sii9234.c   | 993 +
 5 files changed, 1147 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/sii9234.txt
 create mode 100644 drivers/gpu/drm/bridge/sii9234.c

-- 
2.7.4

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

[PATCH v2 1/2] drm/bridge: add Silicon Image SiI9234 driver

[Maciej Purski]

SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interface to perform this operation.

This patch is based on the code refactored by Tomasz Stanislawski
, which was initially developed by:
Adam Hampson 
Erik Gilling 
Shankar Bandal 
Dharam Kumar 

Signed-off-by: Maciej Purski 
---
Changes in v2:
- use bulk_requlators instead of single one
- substitute some of the magic values with macros
- improve coding style
- improved error handling in sii9234_probe()
---
 .../devicetree/bindings/display/bridge/sii9234.txt |  34 +
 drivers/gpu/drm/bridge/Kconfig |   8 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/sii9234.c   | 993 +
 4 files changed, 1036 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/sii9234.txt
 create mode 100644 drivers/gpu/drm/bridge/sii9234.c

diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt 
b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
new file mode 100644
index 000..3ce7413
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
@@ -0,0 +1,34 @@
+Silicon Image SiI9234 HDMI/MHL bridge bindings
+
+Required properties:
+   - compatible : "sil,sii9234".
+   - reg : I2C address for TPI interface, use 0x39
+   - avcc33-supply : MHL/USB Switch Supply Voltage (3.3V)
+   - iovcc18-supply : I/O Supply Voltage (1.8V)
+   - avcc12-supply : TMDS Analog Supply Voltage (1.2V)
+   - cvcc12-supply : Digital Core Supply Voltage (1.2V)
+   - interrupts, interrupt-parent: interrupt specifier of INT pin
+   - reset-gpios: gpio specifier of RESET pin (active low)
+   - video interfaces: Device node can contain video interface port
+   node for HDMI encoder according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   sii9234@39 {
+   compatible = "sil,sii9234";
+   reg = <0x39>;
+   avcc33-supply = <&vcc33mhl>;
+   iovcc18-supply = <&vcc18mhl>;
+   avcc12-supply = <&vsil12>;
+   cvcc12-supply = <&vsil12>;
+   reset-gpios = <&gpf3 4 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <&gpf3>;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <&hdmi_to_mhl>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index adf9ae0..9dba16fd 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -84,6 +84,14 @@ config DRM_SII902X
---help---
  Silicon Image sii902x bridge chip driver.
 
+config DRM_SII9234
+   tristate "Silicon Image SII9234 HDMI/MHL bridge"
+   depends on OF
+   ---help---
+ Say Y here if you want support for the MHL interface.
+ It is an I2C driver, that detects connection of MHL bridge
+ and starts encapsulation of HDMI signal.
+
 config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index defcf1e..e3d5eb0 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
+obj-$(CONFIG_DRM_SII9234) += sii9234.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
new file mode 100644
index 000..b70d69a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sii9234.c
@@ -0,0 +1,993 @@
+/*
+ * Copyright (C) 2017 Samsung Electronics
+ *
+ * Authors:
+ *Tomasz Stanislawski 
+ *Maciej Purski 
+ *
+ * Based on sii9234 driver created by:
+ *Adam Hampson 
+ *Erik Gilling 
+ *Shankar Bandal 
+ *Dharam Kumar 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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

Re: [PATCH 3/6 v3] ASoC: AMD: disabling memory gating in stoney platform

[Mark Brown]

On Fri, Aug 18, 2017 at 02:10:27PM -0400, Alex Deucher wrote:
> From: Vijendar Mukunda 
> 
> For Stoney platform, Memory gating is disabled.i.e SRAM Banks
> won't be turned off. By Default, SRAM Bank state set to ON.
> Added condition checks to skip SRAM Bank state set logic for
> Stoney platform.

Acked-by: Mark Brown 


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

Re: [PATCH 4/6 v2] ASoC: AMD: DMA driver changes for Stoney Platform

[Mark Brown]

On Fri, Aug 18, 2017 at 02:10:28PM -0400, Alex Deucher wrote:
> From: Vijendar Mukunda 
> 
> Added DMA driver changes for Stoney platform.
> Below are the key differences between Stoney and CZ

Acked-by: Mark Brown 


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

Re: [PATCH 6/6 v3] ASoC: AMD: Add machine driver for cz rt5650

[Mark Brown]

On Fri, Aug 18, 2017 at 02:10:30PM -0400, Alex Deucher wrote:

> +++ b/sound/soc/amd/Kconfig
> @@ -2,3 +2,10 @@ config SND_SOC_AMD_ACP
>   tristate "AMD Audio Coprocessor support"
>   help
>This option enables ACP DMA support on AMD platform.
> +config SND_SOC_AMD_CZ_RT5645_MACH
> + tristate "AMD CZ support for RT5645"

Missing blank line between the stanzas.

> + select SND_SOC_RT5645
> + select SND_SOC_AMD_ACP
> + depends on I2C_DESIGNWARE_PLATFORM

No system dependencies of any kind?  Looking at this I'd expect at least
CONFIG_ACPI || COMPILE_TEST.  It's also unclear to me how the DesignWare
device is going to be instantiated here or if that should be a direct
depenency at all here.

> + ret = snd_soc_register_card(card);

devm_snd_soc_register_card() and then you don't need the remove
function.

> +static const struct acpi_device_id cz_audio_acpi_match[] = {
> + { "AMDI1002", 0 },
> + {},
> +};
> +

Missing MODULE_DEVICE_TABLE().


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

Re: [PATCH v2 6/9] drm/exynos: introduce BYTE_PITCH capability

[Tobias Jakobi]

Hello Marek,

first of all thanks for checking this!


Marek Szyprowski wrote:
> Hi Tobias,
> 
> On 2017-08-22 16:19, Tobias Jakobi wrote:
>> In some of subdrivers we compute something like 'pitch / cpp' at some
>> point, silently assuming that the pitch (which is in bytes) is
>> divisible by the buffer's cpp. This must not be true, in particular
>> it depends on the underlying hardware.
>>
>> If userspace should request such a setup, we should communicate this.
>>
>> Introduce a new cap which indicates that the hardware supports a
>> pitch with 'byte-granularity'. If the cap is not set, assume that
>> we need a pitch aligned to cpp.
>>
>> We set this cap in a later patch for the drivers/planes which
>> support it.
>>
>> Signed-off-by: Tobias Jakobi 
> 
> I briefly checked the patch and it looks fine, but I really wonder whether
> drivers should support such strange formats, when pitches are not multiple
> of pixel size in bytes. I cannot find any sane use case for such formats.
Apparantly the hw can do it, so why not support it? A potential use case I see
would be an application that uses a single buffer with multiple pixelformats.

Let buffer-size = width * height * sizeof(uint16_t), with width odd. Then the
buffer pitch is not divisible by 4. In case the hw supports it, we can still use
e.g. XRGB with this setup.


> Maybe it would make sense to add a check for it in DRM core? I also didn't
> notice a check for that in any other drivers, but some of them also
> compute 'pitch / cpp' values.
I thought about some check in DRM core, but I didn't see a clean way to add it,
since the behaviour very much depends on the hw.  Well, except if you just want
to enforce 'pitch % cpp == 0' everywhere. Not sure how the rest of the DRM folks
thinks about it.

With best wishes,
Tobias



>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
>>   drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 ++
>>   2 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 43afab4bebc3..ec32632485d2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -92,6 +92,7 @@ struct exynos_drm_plane {
>>   #define EXYNOS_DRM_PLANE_CAP_SCALE(1 << 1)
>>   #define EXYNOS_DRM_PLANE_CAP_ZPOS(1 << 2)
>>   #define EXYNOS_DRM_PLANE_CAP_TILE(1 << 3)
>> +#define EXYNOS_DRM_PLANE_CAP_BYTE_PITCH(1 << 4)
>> /*
>>* Exynos DRM plane configuration structure.
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> index 133af72f5c90..17e47b8f0d6a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> @@ -185,6 +185,16 @@ exynos_drm_plane_check_format(const struct
>> exynos_drm_plane_config *config,
>>   {
>>   struct drm_framebuffer *fb = state->base.fb;
>>   +/*
>> + * Some blocks only allow to specify a buffer pitch in terms
>> + * of pixels. In these cases, we need to ensure that the pitch
>> + * provided by userspace is divisible by the cpp.
>> + */
>> +if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_BYTE_PITCH)) {
>> +if (fb->pitches[0] % fb->format->cpp[0])
>> +return -ENOTSUPP;
>> +}
>> +
>>   switch (fb->modifier) {
>>   case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
>>   if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_TILE))
> 
> Best regards

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

Re: [PATCH 5/6 v3] ASoC: AMD: Audio buffer related changes for Stoney

[Mark Brown]

On Fri, Aug 18, 2017 at 02:10:29PM -0400, Alex Deucher wrote:

> +#define ST_PLAYBACK_MAX_PERIOD_SIZE 8192
> +#define ST_CAPTURE_MAX_PERIOD_SIZE  8192
> +#define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * 
> PLAYBACK_MAX_NUM_PERIODS)

These defines will go wrong if the capture size is changed independently
of the playback size.  Either just use a single define for both or have
separate defines for the maximum buffer as well as for the period.

> +#define ST_MIN_BUFFER ST_MAX_BUFFER
>  static const struct snd_pcm_hardware acp_pcm_hardware_playback = {

Missing blank line between the defines and here.

> + if (adata->asic_type == CHIP_STONEY)
> + return snd_pcm_lib_preallocate_pages_for_all(rtd->pcm,

As I've said previously it's better to write these variant checks as
switch statements, that way if more variants appear (or special handling
is discovered for existing chips) the code can be modified more cleanly.


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

[PATCHv4 5/5] MAINTAINERS: add cec-gpio entry

[Hans Verkuil]

From: Hans Verkuil 

Add an entry for the CEC GPIO driver.

Signed-off-by: Hans Verkuil 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index eb930ebecfcb..5ef0d34ef502 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3205,6 +3205,15 @@ F:   include/uapi/linux/cec.h
 F: include/uapi/linux/cec-funcs.h
 F: Documentation/devicetree/bindings/media/cec.txt
 
+CEC GPIO DRIVER
+M: Hans Verkuil 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Supported
+F: drivers/media/platform/cec-gpio/
+F: Documentation/devicetree/bindings/media/cec-gpio.txt
+
 CELL BROADBAND ENGINE ARCHITECTURE
 M: Arnd Bergmann 
 L: linuxppc-...@lists.ozlabs.org
-- 
2.14.1

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

[PATCHv4 0/5] cec-gpio: add HDMI CEC GPIO-based driver

[Hans Verkuil]

From: Hans Verkuil 

This driver adds support for CEC implementations that use a pull-up
GPIO line. While SoCs exist that do this, the primary use-case is to
turn a single-board computer into a cheap CEC debugger.

Together with 'cec-ctl --monitor-pin' you can do low-level CEC bus
monitoring and do protocol analysis. And error injection is also
planned for the future.

Here is an example using the Raspberry Pi 3:

https://hverkuil.home.xs4all.nl/rpi3-cec.jpg

While this example is for the Rpi, this driver will work for any
SoC with a pull-up GPIO line.

In addition the cec-gpio driver can optionally monitor the HPD line.
The state of the HPD line influences the CEC behavior so it is very
useful to be able to monitor both.

And some HDMI sinks are known to quickly toggle the HPD when e.g.
switching between inputs. So it is useful to be able to see an event
when the HPD changes value.

The first two patches add support for the new HPD events. The last
three patches are for the cec-gpio driver itself.

Regards,

Hans

Changes since v3:

- cec-gpio.txt: refer to lines instead of pins and use OPEN_DRAIN
  in the example.
- Kconfig: add select GPIOLIB
- cec-gpio.c: switch to gpiod.
- cec-core.c: initialize the devnode mutex/list in allocate_adapter.
  Doing this in register_adapter is too late if the HPD is high.

Changes since v2:

- Add support for HPD events.
- Switch from pin BCM4 to pin BCM7 in the bindings example

Changes since v1:

- Updated the bindings doc to not refer to the driver, instead
  refer to the hardware.


Hans Verkuil (5):
  cec: add CEC_EVENT_PIN_HPD_LOW/HIGH events
  cec-ioc-dqevent.rst: document new CEC_EVENT_PIN_HPD_LOW/HIGH events
  dt-bindings: document the CEC GPIO bindings
  cec-gpio: add HDMI CEC GPIO driver
  MAINTAINERS: add cec-gpio entry

 .../devicetree/bindings/media/cec-gpio.txt |  22 ++
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst   |  18 ++
 MAINTAINERS|   9 +
 drivers/media/cec/cec-adap.c   |  18 +-
 drivers/media/cec/cec-api.c|  18 +-
 drivers/media/cec/cec-core.c   |   8 +-
 drivers/media/platform/Kconfig |  10 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cec-gpio/Makefile   |   1 +
 drivers/media/platform/cec-gpio/cec-gpio.c | 236 +
 include/media/cec-pin.h|   4 +
 include/media/cec.h|  12 +-
 include/uapi/linux/cec.h   |   2 +
 13 files changed, 350 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt
 create mode 100644 drivers/media/platform/cec-gpio/Makefile
 create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c

-- 
2.14.1

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

[PATCHv4 2/5] cec-ioc-dqevent.rst: document new CEC_EVENT_PIN_HPD_LOW/HIGH events

[Hans Verkuil]

From: Hans Verkuil 

Document these new CEC events.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst 
b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
index db615e3405c0..32b47763f5a6 100644
--- a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
@@ -160,6 +160,24 @@ it is guaranteed that the state did change in between the 
two events.
   - Generated if the CEC pin goes from a low voltage to a high voltage.
 Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
capability set.
+* .. _`CEC-EVENT-PIN-HPD-LOW`:
+
+  - ``CEC_EVENT_PIN_HPD_LOW``
+  - 5
+  - Generated if the HPD pin goes from a high voltage to a low voltage.
+Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
+   capability set. When open() is called, the HPD pin can be read and
+   the HPD is low, then an initial event will be generated for that
+   filehandle.
+* .. _`CEC-EVENT-PIN-HPD-HIGH`:
+
+  - ``CEC_EVENT_PIN_HPD_HIGH``
+  - 6
+  - Generated if the HPD pin goes from a low voltage to a high voltage.
+Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
+   capability set. When open() is called, the HPD pin can be read and
+   the HPD is high, then an initial event will be generated for that
+   filehandle.
 
 
 .. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.9cm}|
-- 
2.14.1

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

[PATCHv4 1/5] cec: add CEC_EVENT_PIN_HPD_LOW/HIGH events

[Hans Verkuil]

From: Hans Verkuil 

Add support for two new low-level events: PIN_HPD_LOW and PIN_HPD_HIGH.

This is specifically meant for use with the upcoming cec-gpio driver
and makes it possible to trace when the HPD pin changes. Some HDMI
sinks do strange things with the HPD and this makes it easy to debug
this.

Note that this also moves the initialization of a devnode mutex and
list to the allocate_adapter function: if the HPD is high, then as
soon as the HPD interrupt is created an interrupt occurs and
cec_queue_pin_hpd_event() is called which requires that the devnode
mutex and list are initialized.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-adap.c | 18 +-
 drivers/media/cec/cec-api.c  | 18 ++
 drivers/media/cec/cec-core.c |  8 
 include/media/cec-pin.h  |  4 
 include/media/cec.h  | 12 +++-
 include/uapi/linux/cec.h |  2 ++
 6 files changed, 52 insertions(+), 10 deletions(-)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index dd769e40416f..eb904a71609a 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -86,7 +86,7 @@ void cec_queue_event_fh(struct cec_fh *fh,
const struct cec_event *new_ev, u64 ts)
 {
static const u8 max_events[CEC_NUM_EVENTS] = {
-   1, 1, 64, 64,
+   1, 1, 64, 64, 8, 8,
};
struct cec_event_entry *entry;
unsigned int ev_idx = new_ev->event - 1;
@@ -170,6 +170,22 @@ void cec_queue_pin_cec_event(struct cec_adapter *adap, 
bool is_high, ktime_t ts)
 }
 EXPORT_SYMBOL_GPL(cec_queue_pin_cec_event);
 
+/* Notify userspace that the HPD pin changed state at the given time. */
+void cec_queue_pin_hpd_event(struct cec_adapter *adap, bool is_high, ktime_t 
ts)
+{
+   struct cec_event ev = {
+   .event = is_high ? CEC_EVENT_PIN_HPD_HIGH :
+  CEC_EVENT_PIN_HPD_LOW,
+   };
+   struct cec_fh *fh;
+
+   mutex_lock(&adap->devnode.lock);
+   list_for_each_entry(fh, &adap->devnode.fhs, list)
+   cec_queue_event_fh(fh, &ev, ktime_to_ns(ts));
+   mutex_unlock(&adap->devnode.lock);
+}
+EXPORT_SYMBOL_GPL(cec_queue_pin_hpd_event);
+
 /*
  * Queue a new message for this filehandle.
  *
diff --git a/drivers/media/cec/cec-api.c b/drivers/media/cec/cec-api.c
index a079f7fe018c..465bb3ec21f6 100644
--- a/drivers/media/cec/cec-api.c
+++ b/drivers/media/cec/cec-api.c
@@ -529,7 +529,7 @@ static int cec_open(struct inode *inode, struct file *filp)
 * Initial events that are automatically sent when the cec device is
 * opened.
 */
-   struct cec_event ev_state = {
+   struct cec_event ev = {
.event = CEC_EVENT_STATE_CHANGE,
.flags = CEC_EVENT_FL_INITIAL_STATE,
};
@@ -569,9 +569,19 @@ static int cec_open(struct inode *inode, struct file *filp)
filp->private_data = fh;
 
/* Queue up initial state events */
-   ev_state.state_change.phys_addr = adap->phys_addr;
-   ev_state.state_change.log_addr_mask = adap->log_addrs.log_addr_mask;
-   cec_queue_event_fh(fh, &ev_state, 0);
+   ev.state_change.phys_addr = adap->phys_addr;
+   ev.state_change.log_addr_mask = adap->log_addrs.log_addr_mask;
+   cec_queue_event_fh(fh, &ev, 0);
+#ifdef CONFIG_CEC_PIN
+   if (adap->pin && adap->pin->ops->read_hpd) {
+   err = adap->pin->ops->read_hpd(adap);
+   if (err >= 0) {
+   ev.event = err ? CEC_EVENT_PIN_HPD_HIGH :
+CEC_EVENT_PIN_HPD_LOW;
+   cec_queue_event_fh(fh, &ev, 0);
+   }
+   }
+#endif
 
list_add(&fh->list, &devnode->fhs);
mutex_unlock(&devnode->lock);
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index 648136e552d5..e3a1fb6d6690 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -112,10 +112,6 @@ static int __must_check cec_devnode_register(struct 
cec_devnode *devnode,
int minor;
int ret;
 
-   /* Initialization */
-   INIT_LIST_HEAD(&devnode->fhs);
-   mutex_init(&devnode->lock);
-
/* Part 1: Find a free minor number */
mutex_lock(&cec_devnode_lock);
minor = find_next_zero_bit(cec_devnode_nums, CEC_NUM_DEVICES, 0);
@@ -242,6 +238,10 @@ struct cec_adapter *cec_allocate_adapter(const struct 
cec_adap_ops *ops,
INIT_LIST_HEAD(&adap->wait_queue);
init_waitqueue_head(&adap->kthread_waitq);
 
+   /* adap->devnode initialization */
+   INIT_LIST_HEAD(&adap->devnode.fhs);
+   mutex_init(&adap->devnode.lock);
+
adap->kthread = kthread_run(cec_thread_func, adap, "cec-%s", name);
if (IS_ERR(adap->kthread)) {
pr_err("cec-%s: kernel_thread() failed\n", name);
diff --git a/include/media/cec-pin.h b/include/media/cec-pin.h
index f09cc9579d53..e

[PATCHv4 3/5] dt-bindings: document the CEC GPIO bindings

[Hans Verkuil]

From: Hans Verkuil 

Document the bindings for the cec-gpio module for hardware where the
CEC line and optionally the HPD line are connected to GPIO lines.

Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/cec-gpio.txt | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt

diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt 
b/Documentation/devicetree/bindings/media/cec-gpio.txt
new file mode 100644
index ..db20a7452dbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
@@ -0,0 +1,22 @@
+* HDMI CEC GPIO driver
+
+The HDMI CEC GPIO module supports CEC implementations where the CEC line
+is hooked up to a pull-up GPIO line and - optionally - the HPD line is
+hooked up to another GPIO line.
+
+Required properties:
+  - compatible: value must be "cec-gpio"
+  - cec-gpio: gpio that the CEC line is connected to
+
+Optional property:
+  - hpd-gpio: gpio that the HPD line is connected to
+
+Example for the Raspberry Pi 3 where the CEC line is connected to
+pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
+connected to pin 11 aka BCM17:
+
+cec-gpio@7 {
+   compatible = "cec-gpio";
+   cec-gpio = <&gpio 7 GPIO_OPEN_DRAIN>;
+   hpd-gpio = <&gpio 17 GPIO_ACTIVE_HIGH>;
+};
-- 
2.14.1

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

[PATCHv4 4/5] cec-gpio: add HDMI CEC GPIO driver

[Hans Verkuil]

From: Hans Verkuil 

Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework.

While I have heard of SoCs that use the GPIO pin for CEC (apparently an
early RockChip SoC used that), the main use-case of this driver is to
function as a debugging tool.

By connecting the CEC line to a GPIO pin on a Raspberry Pi 3 for example
it turns it into a CEC debugger and protocol analyzer.

With 'cec-ctl --monitor-pin' the CEC traffic can be analyzed.

But of course it can also be used with any hardware project where the
HDMI CEC line is hooked up to a pull-up gpio line.

In addition this has (optional) support for tracing HPD changes if the
HPD is connected to a GPIO.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/Kconfig |  10 ++
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cec-gpio/Makefile   |   1 +
 drivers/media/platform/cec-gpio/cec-gpio.c | 236 +
 4 files changed, 249 insertions(+)
 create mode 100644 drivers/media/platform/cec-gpio/Makefile
 create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49b8674..e4c89a16a3e7 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -553,6 +553,16 @@ config VIDEO_MESON_AO_CEC
  This is a driver for Amlogic Meson SoCs AO CEC interface. It uses the
  generic CEC framework interface.
  CEC bus is present in the HDMI connector and enables communication
+
+config CEC_GPIO
+   tristate "Generic GPIO-based CEC driver"
+   depends on PREEMPT
+   select CEC_CORE
+   select CEC_PIN
+   select GPIOLIB
+   ---help---
+ This is a generic GPIO-based CEC driver.
+ The CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
 config VIDEO_SAMSUNG_S5P_CEC
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c1ef946bf032..9bf48f118537 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_VIDEO_CODA)  += coda/
 
 obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
 
+obj-$(CONFIG_CEC_GPIO) += cec-gpio/
+
 obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
 
 obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
diff --git a/drivers/media/platform/cec-gpio/Makefile 
b/drivers/media/platform/cec-gpio/Makefile
new file mode 100644
index ..e82b258afa55
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CEC_GPIO) += cec-gpio.o
diff --git a/drivers/media/platform/cec-gpio/cec-gpio.c 
b/drivers/media/platform/cec-gpio/cec-gpio.c
new file mode 100644
index ..eb982bce99fc
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/cec-gpio.c
@@ -0,0 +1,236 @@
+/*
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct cec_gpio {
+   struct cec_adapter  *adap;
+   struct device   *dev;
+
+   struct gpio_desc*cec_gpio;
+   int cec_irq;
+   boolcec_is_low;
+   boolcec_have_irq;
+
+   struct gpio_desc*hpd_gpio;
+   int hpd_irq;
+   boolhpd_is_high;
+   ktime_t hpd_ts;
+};
+
+static bool cec_gpio_read(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (cec->cec_is_low)
+   return false;
+   return gpiod_get_value(cec->cec_gpio);
+}
+
+static void cec_gpio_high(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (!cec->cec_is_low)
+   return;
+   cec->cec_is_low = false;
+   gpiod_set_value(cec->cec_gpio, 1);
+}
+
+static void cec_gpio_low(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (cec->cec_is_low)
+   return;
+   if (WARN_ON_ONCE(cec->cec_have_irq))
+   free_irq(cec->cec_irq, cec);
+   

Re: [PATCHv3 3/5] dt-bindings: document the CEC GPIO bindings

[Hans Verkuil]

On 31/08/17 11:20, Linus Walleij wrote:
> On Wed, Aug 30, 2017 at 6:10 PM, Hans Verkuil  wrote:
> 
>> From: Hans Verkuil 
>>
>> Document the bindings for the cec-gpio module for hardware where the
>> CEC pin and optionally the HPD pin are connected to GPIO pins.
>>
>> Signed-off-by: Hans Verkuil 
> 
> I usually refer to GPIO "lines" rather than "pins" for clarity.
> It's because some systems also have pin control, and then it becomes
> a bit muddy what is a pin.

I'll change the terminology.

>> +* HDMI CEC GPIO driver
>> +
>> +The HDMI CEC GPIO module supports CEC implementations where the CEC pin
>> +is hooked up to a pull-up GPIO pin and - optionally - the HPD pin is
>> +hooked up to a pull-down GPIO pin.
>> +
>> +Required properties:
>> +  - compatible: value must be "cec-gpio"
>> +  - cec-gpio: gpio that the CEC line is connected to
>> +
>> +Optional property:
>> +  - hpd-gpio: gpio that the HPD line is connected to
>> +
>> +Example for the Raspberry Pi 3 where the CEC line is connected to
>> +pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
>> +connected to pin 11 aka BCM17:
>> +
>> +cec-gpio@7 {
>> +   compatible = "cec-gpio";
>> +   cec-gpio = <&gpio 7 GPIO_ACTIVE_HIGH>;
>> +   hpd-gpio = <&gpio 17 GPIO_ACTIVE_HIGH>;
>> +};
> 
> So what I understood from the driver is that the cec-gpio is maybe actually
> an open drain output line, so in that case it should be stated in the docs and
> cec-gpio  = <&gpio 7 GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN>
> or GPIO_LINE_OPEN_DRAIN if it is not also single-ended.

Yes, I agree, it's open drain. I'm not sure whether or not it is single-ended.
I'm not sure what the difference is, and I have no electronics background.

Looking at fwnode_get_named_gpiod() it seems that it has to be single-ended
for GPIO_OPEN_DRAIN to be set, so I am going with that. It works, so it is
probably right :-)

Regards,

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

Re: [PATCH 0/6 v3] Add ASoC support for AMD Stoney APUs

[Mark Brown]

On Wed, Aug 30, 2017 at 09:40:07PM +, Deucher, Alexander wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> I sent one patch in the v2 patch set that had already gone upstream
> because I didn't know that it had landed in Linus' tree yet.  I had
> thought it had just landed in the audio tree.  I apologize for that.
> On the v3 cover page, I mentioned that v3 was a resend of the patches
> that had not been applied to any tree yet; I did not resend any
> patches that were already applied.  I believe all the previous
> comments were addressed.  Now that we've clarified that, are there an
> outstanding objections to these patches?  The patches touch both drm
> and audio.  My preference would be to take them through the drm tree,
> but I'm happy to have them go through the audio tree if you prefer.

I haven't really looked at them yet because I was waiting for the DRM
side of it to get sorted out (previous experience has been that DRM
changes that need review can take a while to figure out).  To be a bit
clearer about what I said in the mail you're replying to you should just
apply the initial DRM bits and send a pull request, this is a standard
way of handling cross tree stuff and means that worst case there's fewer
dependencies after the merge window.


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

Re: [PATCH v2 6/9] drm/exynos: introduce BYTE_PITCH capability

[Marek Szyprowski]

Hi Tobias,

On 2017-08-22 16:19, Tobias Jakobi wrote:

In some of subdrivers we compute something like 'pitch / cpp' at some
point, silently assuming that the pitch (which is in bytes) is
divisible by the buffer's cpp. This must not be true, in particular
it depends on the underlying hardware.

If userspace should request such a setup, we should communicate this.

Introduce a new cap which indicates that the hardware supports a
pitch with 'byte-granularity'. If the cap is not set, assume that
we need a pitch aligned to cpp.

We set this cap in a later patch for the drivers/planes which
support it.

Signed-off-by: Tobias Jakobi 


I briefly checked the patch and it looks fine, but I really wonder whether
drivers should support such strange formats, when pitches are not multiple
of pixel size in bytes. I cannot find any sane use case for such formats.

Maybe it would make sense to add a check for it in DRM core? I also didn't
notice a check for that in any other drivers, but some of them also
compute 'pitch / cpp' values.


---
  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
  drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 ++
  2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 43afab4bebc3..ec32632485d2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -92,6 +92,7 @@ struct exynos_drm_plane {
  #define EXYNOS_DRM_PLANE_CAP_SCALE(1 << 1)
  #define EXYNOS_DRM_PLANE_CAP_ZPOS (1 << 2)
  #define EXYNOS_DRM_PLANE_CAP_TILE (1 << 3)
+#define EXYNOS_DRM_PLANE_CAP_BYTE_PITCH(1 << 4)
  
  /*

   * Exynos DRM plane configuration structure.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 133af72f5c90..17e47b8f0d6a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -185,6 +185,16 @@ exynos_drm_plane_check_format(const struct 
exynos_drm_plane_config *config,
  {
struct drm_framebuffer *fb = state->base.fb;
  
+	/*

+* Some blocks only allow to specify a buffer pitch in terms
+* of pixels. In these cases, we need to ensure that the pitch
+* provided by userspace is divisible by the cpp.
+*/
+   if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_BYTE_PITCH)) {
+   if (fb->pitches[0] % fb->format->cpp[0])
+   return -ENOTSUPP;
+   }
+
switch (fb->modifier) {
case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_TILE))


Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

Re: [PATCH 4/7] drm/pl111: Enable PL110 variant

[Eric Engestrom]

On Wednesday, 2017-08-30 20:07:08 +0200, Linus Walleij wrote:
> We detect and enable the use of the PL110 variant, an earlier
> incarnation of PL111. The only real difference is that the
> control and interrupt enable registers have swapped place.
> The Versatile AB and Versatile PB have a variant inbetween
> PL110 and PL111, it is PL110 but they have already swapped the
> two registers so those two need a bit of special handling.
> 
> Signed-off-by: Linus Walleij 
> ---
>  drivers/gpu/drm/pl111/pl111_display.c | 27 +++
>  drivers/gpu/drm/pl111/pl111_drm.h | 17 +++
>  drivers/gpu/drm/pl111/pl111_drv.c | 84 
> ++-
>  3 files changed, 105 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
> b/drivers/gpu/drm/pl111/pl111_display.c
> index ef86ef60aed1..6447f36c243a 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -201,7 +201,7 @@ static void pl111_display_enable(struct 
> drm_simple_display_pipe *pipe,
>   break;
>   }
>  
> - writel(cntl, priv->regs + CLCD_PL111_CNTL);
> + writel(cntl, priv->regs + priv->ctrl);
>  
>   drm_panel_enable(priv->panel);
>  
> @@ -219,7 +219,7 @@ void pl111_display_disable(struct drm_simple_display_pipe 
> *pipe)
>   drm_panel_disable(priv->panel);
>  
>   /* Disable and Power Down */
> - writel(0, priv->regs + CLCD_PL111_CNTL);
> + writel(0, priv->regs + priv->ctrl);
>  
>   drm_panel_unprepare(priv->panel);
>  
> @@ -259,7 +259,7 @@ int pl111_enable_vblank(struct drm_device *drm, unsigned 
> int crtc)
>  {
>   struct pl111_drm_dev_private *priv = drm->dev_private;
>  
> - writel(CLCD_IRQ_NEXTBASE_UPDATE, priv->regs + CLCD_PL111_IENB);
> + writel(CLCD_IRQ_NEXTBASE_UPDATE, priv->regs + priv->ienb);
>  
>   return 0;
>  }
> @@ -268,7 +268,7 @@ void pl111_disable_vblank(struct drm_device *drm, 
> unsigned int crtc)
>  {
>   struct pl111_drm_dev_private *priv = drm->dev_private;
>  
> - writel(0, priv->regs + CLCD_PL111_IENB);
> + writel(0, priv->regs + priv->ienb);
>  }
>  
>  static int pl111_display_prepare_fb(struct drm_simple_display_pipe *pipe,
> @@ -412,22 +412,6 @@ int pl111_display_init(struct drm_device *drm)
>   struct device_node *endpoint;
>   u32 tft_r0b0g0[3];
>   int ret;
> - static const u32 formats[] = {
> - DRM_FORMAT_ABGR,
> - DRM_FORMAT_XBGR,
> - DRM_FORMAT_ARGB,
> - DRM_FORMAT_XRGB,
> - DRM_FORMAT_BGR565,
> - DRM_FORMAT_RGB565,
> - DRM_FORMAT_ABGR1555,
> - DRM_FORMAT_XBGR1555,
> - DRM_FORMAT_ARGB1555,
> - DRM_FORMAT_XRGB1555,
> - DRM_FORMAT_ABGR,
> - DRM_FORMAT_XBGR,
> - DRM_FORMAT_ARGB,
> - DRM_FORMAT_XRGB,
> - };
>  
>   endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
>   if (!endpoint)
> @@ -456,7 +440,8 @@ int pl111_display_init(struct drm_device *drm)
>  
>   ret = drm_simple_display_pipe_init(drm, &priv->pipe,
>  &pl111_display_funcs,
> -formats, ARRAY_SIZE(formats),
> +priv->variant->formats,
> +priv->variant->nformats,
>  priv->connector);
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/pl111/pl111_drm.h 
> b/drivers/gpu/drm/pl111/pl111_drm.h
> index 8804af0f8997..b316a8a0fbc0 100644
> --- a/drivers/gpu/drm/pl111/pl111_drm.h
> +++ b/drivers/gpu/drm/pl111/pl111_drm.h
> @@ -31,6 +31,20 @@
>  
>  struct drm_minor;
>  
> +/**
> + * struct pl111_variant_data - encodes IP differences
> + * @name: the name of this variant
> + * @is_pl110: this is the early PL110 variant
> + * @formats: array of supported pixel formats on this variant
> + * @nformats: the length of the array of supported pixel formats
> + */
> +struct pl111_variant_data {
> + const char *name;
> + bool is_pl110;
> + const u32 *formats;
> + unsigned int nformats;
> +};
> +
>  struct pl111_drm_dev_private {
>   struct drm_device *drm;
>  
> @@ -42,6 +56,8 @@ struct pl111_drm_dev_private {
>   struct drm_fbdev_cma *fbdev;
>  
>   void *regs;
> + u32 ienb;
> + u32 ctrl;
>   /* The pixel clock (a reference to our clock divider off of CLCDCLK). */
>   struct clk *clk;
>   /* pl111's internal clock divider. */
> @@ -50,6 +66,7 @@ struct pl111_drm_dev_private {
>* subsystem and pl111_display_enable().
>*/
>   spinlock_t tim2_lock;
> + struct pl111_variant_data *variant;
>  };
>  
>  int pl111_display_init(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
> b/drivers/gpu/drm/pl111/pl111_drv.c
> index e66cbf202e17..f6863c0fb809 100

Re: [PATCH 4/6] drm/tinydrm: Embed drm_device in tinydrm_device

[Laurent Pinchart]

Hi Noralf,

Thank you for the patch.

On Monday, 28 August 2017 20:17:46 EEST Noralf Trønnes wrote:
> Might as well embed drm_device since tinydrm_device (embeds pipe struct
> and fbdev pointer) needs to stick around after driver-device unbind to
> handle open fd's after device removal.
> 
> Cc: David Lechner 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 44  -
>  drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c |  2 +-
>  drivers/gpu/drm/tinydrm/mi0283qt.c  |  8 +++---
>  drivers/gpu/drm/tinydrm/mipi-dbi.c  | 12 
>  drivers/gpu/drm/tinydrm/repaper.c   | 10 +++
>  drivers/gpu/drm/tinydrm/st7586.c| 16 +--
>  include/drm/tinydrm/tinydrm.h   |  9 +-
>  7 files changed, 50 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c index 551709e..f11f4cd 100644
> --- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c

[snip]

> @@ -142,23 +142,16 @@ static int tinydrm_init(struct device *parent, struct
> tinydrm_device *tdev, const struct drm_framebuffer_funcs *fb_funcs,
>   struct drm_driver *driver)
>  {
> - struct drm_device *drm;
> + struct drm_device *drm = &tdev->drm;
> + int ret;
> 
>   mutex_init(&tdev->dirty_lock);
>   tdev->fb_funcs = fb_funcs;
> 
> - /*
> -  * We don't embed drm_device, because that prevent us from using
> -  * devm_kzalloc() to allocate tinydrm_device in the driver since
> -  * drm_dev_unref() frees the structure. The devm_ functions provide
> -  * for easy error handling.

Don't you then need a custom drm_driver.release handler to free the parent 
structure ?

> -  */
> - drm = drm_dev_alloc(driver, parent);
> - if (IS_ERR(drm))
> - return PTR_ERR(drm);
> -
> - tdev->drm = drm;
> - drm->dev_private = tdev;
> + ret = drm_dev_init(drm, driver, parent);
> + if (ret)
> + return ret;
> +
>   drm_mode_config_init(drm);
>   drm->mode_config.funcs = &tinydrm_mode_config_funcs;
> 

[snip]

> diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
> b/drivers/gpu/drm/tinydrm/mi0283qt.c index 7e5bb7d..77d40c9 100644
> --- a/drivers/gpu/drm/tinydrm/mi0283qt.c
> +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c

[snip]

> @@ -169,7 +169,7 @@ static int mi0283qt_probe(struct spi_device *spi)
>   u32 rotation = 0;
>   int ret;
> 
> - mipi = devm_kzalloc(dev, sizeof(*mipi), GFP_KERNEL);
> + mipi = kzalloc(sizeof(*mipi), GFP_KERNEL);

Where's the related kfree() ?

>   if (!mipi)
>   return -ENOMEM;

[snip]

> diff --git a/drivers/gpu/drm/tinydrm/repaper.c
> b/drivers/gpu/drm/tinydrm/repaper.c index 30dc97b..b8fc8eb 100644
> --- a/drivers/gpu/drm/tinydrm/repaper.c
> +++ b/drivers/gpu/drm/tinydrm/repaper.c

[snip]

> @@ -949,7 +949,7 @@ static int repaper_probe(struct spi_device *spi)
>   }
>   }
> 
> - epd = devm_kzalloc(dev, sizeof(*epd), GFP_KERNEL);
> + epd = kzalloc(sizeof(*epd), GFP_KERNEL);

Ditto.

>   if (!epd)
>   return -ENOMEM;

[snip]

> diff --git a/drivers/gpu/drm/tinydrm/st7586.c
> b/drivers/gpu/drm/tinydrm/st7586.c index b439956..bc2b905 100644
> --- a/drivers/gpu/drm/tinydrm/st7586.c
> +++ b/drivers/gpu/drm/tinydrm/st7586.c

[snip]

> @@ -349,7 +349,7 @@ static int st7586_probe(struct spi_device *spi)
>   u32 rotation = 0;
>   int ret;
> 
> - mipi = devm_kzalloc(dev, sizeof(*mipi), GFP_KERNEL);
> + mipi = kzalloc(sizeof(*mipi), GFP_KERNEL);

Ang here again.

>   if (!mipi)
>   return -ENOMEM;

[snip]

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/2] vfs: add flags parameter to ->mmap() in 'struct file_operations'

[Christoph Hellwig]

> -static int ecryptfs_mmap(struct file *file, struct vm_area_struct *vma)
> +static int ecryptfs_mmap(struct file *file, struct vm_area_struct *vma,
> +  unsigned long map_flags)
>  {
>   struct file *lower_file = ecryptfs_file_to_lower(file);
>   /*
> @@ -179,7 +180,7 @@ static int ecryptfs_mmap(struct file *file, struct 
> vm_area_struct *vma)
>*/
>   if (!lower_file->f_op->mmap)
>   return -ENODEV;
> - return generic_file_mmap(file, vma);
> + return generic_file_mmap(file, vma, 0);

Shouldn't ecryptfs pass on the flags?  Same for coda_file_mmap and
shm_mmap.

> -static inline int call_mmap(struct file *file, struct vm_area_struct *vma)
> +static inline int call_mmap(struct file *file, struct vm_area_struct *vma,
> + unsigned long flags)
>  {
> - return file->f_op->mmap(file, vma);
> + return file->f_op->mmap(file, vma, flags);
>  }

It would be great to kill this pointless wrapper while we're at it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dt-bindings: display: renesas: dw-hdmi: Drop bogus node name suffix

[Simon Horman]

On Wed, Aug 30, 2017 at 01:05:43PM +0300, Laurent Pinchart wrote:
> Hi Geert,
> 
> Thank you for the patch.
> 
> On Wednesday, 30 August 2017 12:53:01 EEST Geert Uytterhoeven wrote:
> > Node names should not use numerical suffixes if the nodes can be
> > distinguished by unit-address.
> > 
> > Signed-off-by: Geert Uytterhoeven 
> 
> Acked-by: Laurent Pinchart 

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

[RFC PATCH] drm/nouveau/therm: initial implementation of new gp1xx temperature sensor

[Rhys Kidd]

Signed-off-by: Rhys Kidd 
---
 .../gpu/drm/nouveau/include/nvkm/subdev/therm.h|  1 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |  6 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild   |  1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c   |  3 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c  | 57 ++
 5 files changed, 67 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h 
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
index b268b96faece..adf14731ea15 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
@@ -96,4 +96,5 @@ int g84_therm_new(struct nvkm_device *, int, struct 
nvkm_therm **);
 int gt215_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 int gf119_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 int gm107_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
+int gp100_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
 #endif
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 7bdc7a5ae723..a6221b0996bf 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -2166,6 +2166,7 @@ nv130_chipset = {
.ltc = gp100_ltc_new,
.mc = gp100_mc_new,
.mmu = gf100_mmu_new,
+   .therm = gp100_therm_new,
.secboot = gm200_secboot_new,
.pci = gp100_pci_new,
.pmu = gp100_pmu_new,
@@ -2200,6 +2201,7 @@ nv132_chipset = {
.ltc = gp100_ltc_new,
.mc = gp100_mc_new,
.mmu = gf100_mmu_new,
+   .therm = gp100_therm_new,
.secboot = gp102_secboot_new,
.pci = gp100_pci_new,
.pmu = gp102_pmu_new,
@@ -2234,6 +2236,7 @@ nv134_chipset = {
.ltc = gp100_ltc_new,
.mc = gp100_mc_new,
.mmu = gf100_mmu_new,
+   .therm = gp100_therm_new,
.secboot = gp102_secboot_new,
.pci = gp100_pci_new,
.pmu = gp102_pmu_new,
@@ -2268,6 +2271,7 @@ nv136_chipset = {
.ltc = gp100_ltc_new,
.mc = gp100_mc_new,
.mmu = gf100_mmu_new,
+   .therm = gp100_therm_new,
.secboot = gp102_secboot_new,
.pci = gp100_pci_new,
.pmu = gp102_pmu_new,
@@ -2302,6 +2306,7 @@ nv137_chipset = {
.ltc = gp100_ltc_new,
.mc = gp100_mc_new,
.mmu = gf100_mmu_new,
+   .therm = gp100_therm_new,
.secboot = gp102_secboot_new,
.pci = gp100_pci_new,
.pmu = gp102_pmu_new,
@@ -2332,6 +2337,7 @@ nv13b_chipset = {
.ltc = gp100_ltc_new,
.mc = gp10b_mc_new,
.mmu = gf100_mmu_new,
+   .therm = gp100_therm_new,
.secboot = gp10b_secboot_new,
.pmu = gm20b_pmu_new,
.timer = gk20a_timer_new,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild 
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild
index 135758ba3e28..3ef1b396a946 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild
@@ -11,3 +11,4 @@ nvkm-y += nvkm/subdev/therm/g84.o
 nvkm-y += nvkm/subdev/therm/gt215.o
 nvkm-y += nvkm/subdev/therm/gf119.o
 nvkm-y += nvkm/subdev/therm/gm107.o
+nvkm-y += nvkm/subdev/therm/gp100.o
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
index 952a7cb0a59a..f27fc6d0d4c6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
@@ -341,7 +341,8 @@ nvkm_therm_init(struct nvkm_subdev *subdev)
 {
struct nvkm_therm *therm = nvkm_therm(subdev);
 
-   therm->func->init(therm);
+   if (therm->func->init)
+   therm->func->init(therm);
 
if (therm->suspend >= 0) {
/* restore the pwm value only when on manual or auto mode */
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
new file mode 100644
index ..b83d4af8c8bb
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
@@ -0,0 +1,57 @@
+/*
+ * Copyright 2017 Rhys Kidd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS

Re: [Nouveau] [RFC PATCH] drm/nouveau/therm: initial implementation of new gp1xx temperature sensor

[Karol Herbst]

On Thu, Aug 31, 2017 at 4:55 AM, Rhys Kidd  wrote:
> Signed-off-by: Rhys Kidd 
> ---
>  .../gpu/drm/nouveau/include/nvkm/subdev/therm.h|  1 +
>  drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |  6 +++
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild   |  1 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c   |  3 +-
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c  | 57 
> ++
>  5 files changed, 67 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
>
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h 
> b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> index b268b96faece..adf14731ea15 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> @@ -96,4 +96,5 @@ int g84_therm_new(struct nvkm_device *, int, struct 
> nvkm_therm **);
>  int gt215_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int gf119_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int gm107_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
> +int gp100_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  #endif
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> index 7bdc7a5ae723..a6221b0996bf 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> @@ -2166,6 +2166,7 @@ nv130_chipset = {
> .ltc = gp100_ltc_new,
> .mc = gp100_mc_new,
> .mmu = gf100_mmu_new,
> +   .therm = gp100_therm_new,
> .secboot = gm200_secboot_new,
> .pci = gp100_pci_new,
> .pmu = gp100_pmu_new,
> @@ -2200,6 +2201,7 @@ nv132_chipset = {
> .ltc = gp100_ltc_new,
> .mc = gp100_mc_new,
> .mmu = gf100_mmu_new,
> +   .therm = gp100_therm_new,
> .secboot = gp102_secboot_new,
> .pci = gp100_pci_new,
> .pmu = gp102_pmu_new,
> @@ -2234,6 +2236,7 @@ nv134_chipset = {
> .ltc = gp100_ltc_new,
> .mc = gp100_mc_new,
> .mmu = gf100_mmu_new,
> +   .therm = gp100_therm_new,
> .secboot = gp102_secboot_new,
> .pci = gp100_pci_new,
> .pmu = gp102_pmu_new,
> @@ -2268,6 +2271,7 @@ nv136_chipset = {
> .ltc = gp100_ltc_new,
> .mc = gp100_mc_new,
> .mmu = gf100_mmu_new,
> +   .therm = gp100_therm_new,
> .secboot = gp102_secboot_new,
> .pci = gp100_pci_new,
> .pmu = gp102_pmu_new,
> @@ -2302,6 +2306,7 @@ nv137_chipset = {
> .ltc = gp100_ltc_new,
> .mc = gp100_mc_new,
> .mmu = gf100_mmu_new,
> +   .therm = gp100_therm_new,
> .secboot = gp102_secboot_new,
> .pci = gp100_pci_new,
> .pmu = gp102_pmu_new,
> @@ -2332,6 +2337,7 @@ nv13b_chipset = {
> .ltc = gp100_ltc_new,
> .mc = gp10b_mc_new,
> .mmu = gf100_mmu_new,
> +   .therm = gp100_therm_new,
> .secboot = gp10b_secboot_new,
> .pmu = gm20b_pmu_new,
> .timer = gk20a_timer_new,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild
> index 135758ba3e28..3ef1b396a946 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild
> @@ -11,3 +11,4 @@ nvkm-y += nvkm/subdev/therm/g84.o
>  nvkm-y += nvkm/subdev/therm/gt215.o
>  nvkm-y += nvkm/subdev/therm/gf119.o
>  nvkm-y += nvkm/subdev/therm/gm107.o
> +nvkm-y += nvkm/subdev/therm/gp100.o
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> index 952a7cb0a59a..f27fc6d0d4c6 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> @@ -341,7 +341,8 @@ nvkm_therm_init(struct nvkm_subdev *subdev)
>  {
> struct nvkm_therm *therm = nvkm_therm(subdev);
>
> -   therm->func->init(therm);
> +   if (therm->func->init)
> +   therm->func->init(therm);
>
> if (therm->suspend >= 0) {
> /* restore the pwm value only when on manual or auto mode */
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
> new file mode 100644
> index ..b83d4af8c8bb
> --- /dev/null
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
> @@ -0,0 +1,57 @@
> +/*
> + * Copyright 2017 Rhys Kidd
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Softwa

Re: [PATCH 1/6] drm/fb-helper: Avoid NULL ptr dereference in fb_set_suspend()

[Laurent Pinchart]

Hello,

On Tuesday, 29 August 2017 00:34:57 EEST Daniel Vetter wrote:
> On Mon, Aug 28, 2017 at 07:17:43PM +0200, Noralf Trønnes wrote:
> > drm_fb_helper_resume_worker() uses fb_helper->fbdev to call
> > fb_set_suspend() which dereferences the pointer.
> > Move sync-canceling of the resume worker in drm_fb_helper_fini() before
> > setting fb_helper->fbdev to NULL.
> > 
> > Signed-off-by: Noralf Trønnes 
> > ---
> > 
> >  drivers/gpu/drm/drm_fb_helper.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c index 1b8f013..2e33467 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -910,6 +910,8 @@ void drm_fb_helper_fini(struct drm_fb_helper
> > *fb_helper)> 
> > if (!drm_fbdev_emulation || !fb_helper)
> > 
> > return;
> > 
> > +   cancel_work_sync(&fb_helper->resume_work);
> > +
> > 
> > info = fb_helper->fbdev;
> > if (info) {
> > 
> > if (info->cmap.len)
> > 
> > @@ -918,7 +920,6 @@ void drm_fb_helper_fini(struct drm_fb_helper
> > *fb_helper)> 
> > }
> > fb_helper->fbdev = NULL;
> > 
> > -   cancel_work_sync(&fb_helper->resume_work);
> > 
> > cancel_work_sync(&fb_helper->dirty_work);
> 
> Hm, I would have moved both up, just for safety. Either way:
> 
> Reviewed-by: Daniel Vetter 

I was going to mention the same, let's move both. With this changed,

Reviewed-by: Laurent Pinchart 

> > mutex_lock(&kernel_fb_helper_lock);


-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm/tve200: Pass NULL format_modifier to drm_simple_display_pipe_init

[Linus Walleij]

On Wed, Aug 30, 2017 at 9:22 AM, Daniel Vetter  wrote:
> On Mon, Aug 28, 2017 at 10:40:34AM +0200, Daniel Vetter wrote:
>> On Fri, Aug 25, 2017 at 01:16:12PM -0700, Rodrigo Vivi wrote:
>> > This Fixes build on branches where we already have format-modifier.
>> >
>> > Reference: 
>> > https://lists.freedesktop.org/archives/dri-devel/2017-August/151044.html
>> > Fixes: e6fc3b68558e ("drm: Plumb modifiers through plane init")
>>
>> tve200 was merged after this patch, the correct Fixes line would be:
>>
>> Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200")
>>
>> Linus, can you pls make sure that tve200 is enabled int the
>> drm-rerere/*arm*defconfig files, to avoid this in the future? They're the
>> recommended set to compile-test drm-misc (yes we should somehow bot-ify
>> this, but oh well).

Oh I was not aware of that, sorry.

> Neither Rodrigo (as the author of the patch) or Linus (as the driver
> maintainer) took action here already, and since it's an obvious compile
> fail it's annoying, so I merged it.

Thanks.

> But really this entire commit rights thing means committer take care of
> this stuff, not maintainers.
>
> Linus, I also added tve200 to the defconfigs now.

Thanks, I was just about to ask how to do it.

I will look in drm-rerere folder and try to figure out how this works so
I can get it right in the future.

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

Re: [PATCHv3 3/5] dt-bindings: document the CEC GPIO bindings

[Linus Walleij]

On Wed, Aug 30, 2017 at 6:10 PM, Hans Verkuil  wrote:

> From: Hans Verkuil 
>
> Document the bindings for the cec-gpio module for hardware where the
> CEC pin and optionally the HPD pin are connected to GPIO pins.
>
> Signed-off-by: Hans Verkuil 

I usually refer to GPIO "lines" rather than "pins" for clarity.
It's because some systems also have pin control, and then it becomes
a bit muddy what is a pin.

> +* HDMI CEC GPIO driver
> +
> +The HDMI CEC GPIO module supports CEC implementations where the CEC pin
> +is hooked up to a pull-up GPIO pin and - optionally - the HPD pin is
> +hooked up to a pull-down GPIO pin.
> +
> +Required properties:
> +  - compatible: value must be "cec-gpio"
> +  - cec-gpio: gpio that the CEC line is connected to
> +
> +Optional property:
> +  - hpd-gpio: gpio that the HPD line is connected to
> +
> +Example for the Raspberry Pi 3 where the CEC line is connected to
> +pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
> +connected to pin 11 aka BCM17:
> +
> +cec-gpio@7 {
> +   compatible = "cec-gpio";
> +   cec-gpio = <&gpio 7 GPIO_ACTIVE_HIGH>;
> +   hpd-gpio = <&gpio 17 GPIO_ACTIVE_HIGH>;
> +};

So what I understood from the driver is that the cec-gpio is maybe actually
an open drain output line, so in that case it should be stated in the docs and
cec-gpio  = <&gpio 7 GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN>
or GPIO_LINE_OPEN_DRAIN if it is not also single-ended.


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

[Bug 102491] OpenCL app gets CL_OUT_OF_HOST_MEMORY on Cape Verde 7770

[bugzilla-daemon]

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

--- Comment #4 from ka.n...@mail.ru ---
Created attachment 133900
  --> https://bugs.freedesktop.org/attachment.cgi?id=133900&action=edit
lspci -k output

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

[Bug 102491] OpenCL app gets CL_OUT_OF_HOST_MEMORY on Cape Verde 7770

[bugzilla-daemon]

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

--- Comment #3 from ka.n...@mail.ru ---
Created attachment 133899
  --> https://bugs.freedesktop.org/attachment.cgi?id=133899&action=edit
darktable-cltest output

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

[Bug 102491] OpenCL app gets CL_OUT_OF_HOST_MEMORY on Cape Verde 7770

[bugzilla-daemon]

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

--- Comment #2 from ka.n...@mail.ru ---
Created attachment 133898
  --> https://bugs.freedesktop.org/attachment.cgi?id=133898&action=edit
Clinfo output

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

[Bug 102491] OpenCL app gets CL_OUT_OF_HOST_MEMORY on Cape Verde 7770

[bugzilla-daemon]

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

--- Comment #1 from ka.n...@mail.ru ---
Created attachment 133897
  --> https://bugs.freedesktop.org/attachment.cgi?id=133897&action=edit
Dmesg output

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

[Bug 102491] OpenCL app gets CL_OUT_OF_HOST_MEMORY on Cape Verde 7770

[bugzilla-daemon]

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

Bug ID: 102491
   Summary: OpenCL app gets CL_OUT_OF_HOST_MEMORY on Cape Verde
7770
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu-pro
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ka.n...@mail.ru

Created attachment 133896
  --> https://bugs.freedesktop.org/attachment.cgi?id=133896&action=edit
Kernel config

Trying to couple mainline amdgpu driver with opencl from amdgpu-pro (installed
via Gentoo dev-libs/amdgpu-pro-opencl package) to make darktable use opencl
again.  Clinfo and apps see the opencl but when trying to create a command
queue driver returns CL_OUT_OF_HOST_MEMORY. The same behavior is reported on
Ubuntu 16.04.3 as seen here https://redmine.darktable.org/issues/11702

kernel 4.12.0-pf7 
xorg-server-1.19.3
libdrm-2.4.82
xorg-1.19.3
x11-drivers/xf86-video-amdgpu-1.3.0
dev-libs/amdgpu-pro-opencl-17.30.465504

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

Re: [PATCHv3 4/5] cec-gpio: add HDMI CEC GPIO driver

[Linus Walleij]

On Wed, Aug 30, 2017 at 6:10 PM, Hans Verkuil  wrote:

> From: Hans Verkuil 
>
> Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework.
>
> While I have heard of SoCs that use the GPIO pin for CEC (apparently an
> early RockChip SoC used that), the main use-case of this driver is to
> function as a debugging tool.
>
> By connecting the CEC line to a GPIO pin on a Raspberry Pi 3 for example
> it turns it into a CEC debugger and protocol analyzer.
>
> With 'cec-ctl --monitor-pin' the CEC traffic can be analyzed.
>
> But of course it can also be used with any hardware project where the
> HDMI CEC pin is hooked up to a pull-up gpio pin.
>
> In addition this has (optional) support for tracing HPD changes if the
> HPD is connected to a GPIO.
>
> Signed-off-by: Hans Verkuil 

Pretty cool stuff!

> +config CEC_GPIO
> +   tristate "Generic GPIO-based CEC driver"
> +   depends on PREEMPT

depends on GPIOLIB

or

select GPIOLIB

your pick.

> +#include 

This should not be needed in new code.

> +#include 

This should be enough.

> +#include 

Your should not need this either.

> +struct cec_gpio {
> +   struct cec_adapter  *adap;
> +   struct device   *dev;
> +   int gpio;
> +   int hpd_gpio;

Think this should be:

struct gpio_desc *gpio;
struct gpio_desc *hpd_gpio;

> +   int irq;
> +   int hpd_irq;
> +   boolhpd_is_high;
> +   ktime_t hpd_ts;
> +   boolis_low;
> +   boolhave_irq;
> +};
> +
> +static bool cec_gpio_read(struct cec_adapter *adap)
> +{
> +   struct cec_gpio *cec = cec_get_drvdata(adap);
> +
> +   if (cec->is_low)
> +   return false;
> +   return gpio_get_value(cec->gpio);

Use descriptor accessors

gpiod_get_value()

> +static void cec_gpio_high(struct cec_adapter *adap)
> +{
> +   struct cec_gpio *cec = cec_get_drvdata(adap);
> +
> +   if (!cec->is_low)
> +   return;
> +   cec->is_low = false;
> +   gpio_direction_input(cec->gpio);

Are you setting the GPIO high by setting it as input?
That sounds like you should be requesting it as
open drain in the DTS file, see
Documentation/gpio/driver.txt
for details about open drain, and use
GPIO_LINE_OPEN_DRAIN
from 

> +static void cec_gpio_low(struct cec_adapter *adap)
> +{
> +   struct cec_gpio *cec = cec_get_drvdata(adap);
> +
> +   if (cec->is_low)
> +   return;
> +   if (WARN_ON_ONCE(cec->have_irq))
> +   free_irq(cec->irq, cec);
> +   cec->have_irq = false;
> +   cec->is_low = true;
> +   gpio_direction_output(cec->gpio, 0);

Yeah this looks like you're doing open drain.
gpiod_direction_output() etc.

> +static int cec_gpio_read_hpd(struct cec_adapter *adap)
> +{
> +   struct cec_gpio *cec = cec_get_drvdata(adap);
> +
> +   if (cec->hpd_gpio < 0)
> +   return -ENOTTY;
> +   return gpio_get_value(cec->hpd_gpio);

gpiod_get_value()


> +static int cec_gpio_probe(struct platform_device *pdev)
> +{
> +   struct device *dev = &pdev->dev;
> +   enum of_gpio_flags hpd_gpio_flags;
> +   struct cec_gpio *cec;
> +   int ret;
> +
> +   cec = devm_kzalloc(dev, sizeof(*cec), GFP_KERNEL);
> +   if (!cec)
> +   return -ENOMEM;
> +
> +   cec->gpio = of_get_named_gpio_flags(dev->of_node,
> +   "cec-gpio", 0, &hpd_gpio_flags);
> +   if (cec->gpio < 0)
> +   return cec->gpio;
> +
> +   cec->hpd_gpio = of_get_named_gpio_flags(dev->of_node,
> +   "hpd-gpio", 0, &hpd_gpio_flags);

This is a proper device so don't use all this trouble.

cec->gpio = gpiod_get(dev, "cec-gpio", GPIOD_IN);

or similar (grep for examples!)

Same for hdp_gpio.

> +   cec->irq = gpio_to_irq(cec->gpio);

gpiod_to_irq()

> +   gpio_direction_input(cec->gpio);

This is not needed with the above IN flag.

But as said above, maybe you are looking for an open drain
output actually.

> +   if (cec->hpd_gpio >= 0) {
> +   cec->hpd_irq = gpio_to_irq(cec->hpd_gpio);
> +   gpio_direction_input(cec->hpd_gpio);

Already done if you pass the right flag. This should be IN for sure.

Use gpiod_to_irq().

Please include me on subsequent posts, I want to try to use
descriptors as much as possible for new drivers.

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

Re: [PATCH] drm/gma500: Remove null check before kfree

[Daniel Vetter]

On Wed, Aug 30, 2017 at 06:55:56PM +0530, Himanshu Jha wrote:
> kfree on NULL pointer is a no-op and therefore checking is redundant.
> 
> Signed-off-by: Himanshu Jha 

Applied to drm-misc-next, thanks.
-Daniel

> ---
>  drivers/gpu/drm/gma500/cdv_intel_dp.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c 
> b/drivers/gpu/drm/gma500/cdv_intel_dp.c
> index c52f9ad..a4bb89b 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
> @@ -1901,10 +1901,8 @@ cdv_intel_dp_destroy(struct drm_connector *connector)
>  
>   if (is_edp(gma_encoder)) {
>   /*  cdv_intel_panel_destroy_backlight(connector->dev); */
> - if (intel_dp->panel_fixed_mode) {
> - kfree(intel_dp->panel_fixed_mode);
> - intel_dp->panel_fixed_mode = NULL;
> - }
> + kfree(intel_dp->panel_fixed_mode);
> + intel_dp->panel_fixed_mode = NULL;
>   }
>   i2c_del_adapter(&intel_dp->adapter);
>   drm_connector_unregister(connector);
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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