Re: [RFC 4/6] drm/bridge/sii8620: fix extcon dependency

[Andrzej Hajda]

On 08.04.2020 22:27, Arnd Bergmann wrote:
> Using 'imply' does not work here, it still cause the same build
> failure:
>
> arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function 
> `sii8620_remove':
> sil-sii8620.c:(.text+0x1b8): undefined reference to 
> `extcon_unregister_notifier'
> arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function 
> `sii8620_probe':
> sil-sii8620.c:(.text+0x27e8): undefined reference to 
> `extcon_find_edev_by_node'
> arm-linux-gnueabi-ld: sil-sii8620.c:(.text+0x2870): undefined reference to 
> `extcon_register_notifier'
> arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function 
> `sii8620_extcon_work':
> sil-sii8620.c:(.text+0x2908): undefined reference to `extcon_get_state'
>
> I tried the usual 'depends on EXTCON || !EXTCON' logic, but that caused
> a circular Kconfig dependency. Using IS_REACHABLE() is ugly but works.

'depends on EXTCON || !EXTCON' seems to be proper solution, maybe would be 
better to try to solve circular dependencies issue.

Regards
Andrzej


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

Re: [PATCH 2/2] drm/i915: remove gvt/Makefile

[Zhenyu Wang]

On 2020.04.10 00:58:16 +0300, Jani Nikula wrote:
> On Fri, 10 Apr 2020, Masahiro Yamada  wrote:
> > Including subdirectory Makefile from the driver main Makefile does not
> > buy us much because this is not real isolation.
> 
> The isolation it does buy us is that gvt/ subdirectory is developed and
> maintained on a separate mailing list and separate git repo. I think at
> some point there were plans to make it an actual module too.
> 
> So while you could quip about Conway's law here, I think it might be
> better to keep this as it is.
> 
> Zhenyu, Zhi, what do you think?

Yeah, I have the same feeling, maybe we can add some comment in gvt Makefile
to state that point.

Thanks

> >
> > Having a single Makefile at the top of the module is clearer, and
> > it is what this driver almost does.
> >
> > Move all gvt objects to the i915 main Makefile.
> >
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> >  drivers/gpu/drm/i915/Makefile | 28 
> >  drivers/gpu/drm/i915/gvt/Makefile |  8 
> >  2 files changed, 24 insertions(+), 12 deletions(-)
> >  delete mode 100644 drivers/gpu/drm/i915/gvt/Makefile
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 6cd1f6253814..74e965882a98 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -275,10 +275,30 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
> >  # virtual gpu code
> >  i915-y += i915_vgpu.o
> >  
> > -ifeq ($(CONFIG_DRM_I915_GVT),y)
> > -i915-y += intel_gvt.o
> > -include $(src)/gvt/Makefile
> > -endif
> > +i915-$(CONFIG_DRM_I915_GVT) += \
> > +   intel_gvt.o \
> > +   gvt/gvt.o \
> > +   gvt/aperture_gm.o \
> > +   gvt/handlers.o \
> > +   gvt/vgpu.o \
> > +   gvt/trace_points.o \
> > +   gvt/firmware.o \
> > +   gvt/interrupt.o \
> > +   gvt/gtt.o \
> > +   gvt/cfg_space.o \
> > +   gvt/opregion.o \
> > +   gvt/mmio.o \
> > +   gvt/display.o \
> > +   gvt/edid.o \
> > +   gvt/execlist.o \
> > +   gvt/scheduler.o \
> > +   gvt/sched_policy.o \
> > +   gvt/mmio_context.o \
> > +   gvt/cmd_parser.o \
> > +   gvt/debugfs.o \
> > +   gvt/fb_decoder.o \
> > +   gvt/dmabuf.o \
> > +   gvt/page_track.o
> >  
> >  obj-$(CONFIG_DRM_I915) += i915.o
> >  obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
> > diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
> > b/drivers/gpu/drm/i915/gvt/Makefile
> > deleted file mode 100644
> > index 4d70f4689479..
> > --- a/drivers/gpu/drm/i915/gvt/Makefile
> > +++ /dev/null
> > @@ -1,8 +0,0 @@
> > -# SPDX-License-Identifier: GPL-2.0
> > -GVT_DIR := gvt
> > -GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o 
> > firmware.o \
> > -   interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
> > -   execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o 
> > debugfs.o \
> > -   fb_decoder.o dmabuf.o page_track.o
> > -
> > -i915-y += $(addprefix $(GVT_DIR)/, 
> > $(GVT_SOURCE))
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

[PATCH v5 0/4] Config mipi tx current and impedance

[Jitao Shi]

Changes since v4:
 - add Reviewed-by:
 - move the get the calibration data code to probe.

Changes since v3:
 - refine drive-strength-microamp as from 3000 to 6000.

Changes since v2:
 - fix the title of commit message.
 - rename mipitx-current-drive to drive-strength-microamp

Changes since v1:
 - fix coding style.
 - change mtk_mipi_tx_config_calibration_data() to void

Jitao Shi (4):
  dt-bindings: display: mediatek: add property to control mipi tx drive
current
  dt-bindings: display: mediatek: get mipitx calibration data from nvmem
  drm/mediatek: add the mipitx driving control
  drm/mediatek: config mipitx impedance with calibration data

 .../display/mediatek/mediatek,dsi.txt | 10 
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 54 +++
 drivers/gpu/drm/mediatek/mtk_mipi_tx.h|  4 ++
 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 28 ++
 4 files changed, 96 insertions(+)

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

[PATCH v5 4/4] drm/mediatek: config mipitx impedance with calibration data

[Jitao Shi]

Read calibration data from nvmem, and config mipitx impedance with
calibration data to make sure their impedance are 100ohm.

Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 40 +++
 drivers/gpu/drm/mediatek/mtk_mipi_tx.h|  3 ++
 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 21 ++
 3 files changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c 
b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
index e301af64809e..5e91fc2c1318 100644
--- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
+++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
@@ -88,6 +88,44 @@ static const struct phy_ops mtk_mipi_tx_ops = {
.owner = THIS_MODULE,
 };
 
+static void mtk_mipi_tx_get_calibration_datal(struct mtk_mipi_tx *mipi_tx)
+{
+   struct nvmem_cell *cell;
+   size_t len;
+   u32 *buf;
+
+   memset(mipi_tx->rt_code, 0, sizeof(mipi_tx->rt_code));
+   cell = nvmem_cell_get(mipi_tx->dev, "calibration-data");
+   if (IS_ERR(cell)) {
+   dev_info(mipi_tx->dev, "can't get nvmem_cell_get, ignore it\n");
+   } else {
+   buf = (u32 *)nvmem_cell_read(cell, &len);
+   nvmem_cell_put(cell);
+
+   if (IS_ERR(buf)) {
+   dev_info(mipi_tx->dev, "can't get data, ignore it\n");
+   } else {
+   if (len < 3 * sizeof(u32)) {
+   dev_info(mipi_tx->dev, "invalid calibration 
data\n");
+   kfree(buf);
+   return;
+   }
+
+   mipi_tx->rt_code[0] = ((buf[0] >> 6 & 0x1f) << 5) |
+  (buf[0] >> 11 & 0x1f);
+   mipi_tx->rt_code[1] = ((buf[1] >> 27 & 0x1f) << 5) |
+  (buf[0] >> 1 & 0x1f);
+   mipi_tx->rt_code[2] = ((buf[1] >> 17 & 0x1f) << 5) |
+  (buf[1] >> 22 & 0x1f);
+   mipi_tx->rt_code[3] = ((buf[1] >> 7 & 0x1f) << 5) |
+  (buf[1] >> 12 & 0x1f);
+   mipi_tx->rt_code[4] = ((buf[2] >> 27 & 0x1f) << 5) |
+  (buf[1] >> 2 & 0x1f);
+   kfree(buf);
+   }
+   }
+}
+
 static int mtk_mipi_tx_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
@@ -174,6 +212,8 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
 
mipi_tx->dev = dev;
 
+   mtk_mipi_tx_get_calibration_datal(mipi_tx);
+
return of_clk_add_provider(dev->of_node, of_clk_src_simple_get,
   mipi_tx->pll);
 }
diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h 
b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
index eea44327fe9f..c76f07c3fdeb 100644
--- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
+++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
@@ -12,9 +12,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 struct mtk_mipitx_data {
const u32 mppll_preserve;
@@ -28,6 +30,7 @@ struct mtk_mipi_tx {
void __iomem *regs;
u32 data_rate;
u32 mipitx_drive;
+   u32 rt_code[5];
const struct mtk_mipitx_data *driver_data;
struct clk_hw pll_hw;
struct clk *pll;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c 
b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
index e4cc967750cb..9f3e55aeebb2 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
@@ -28,6 +28,7 @@
 #define MIPITX_PLL_CON40x003c
 #define RG_DSI_PLL_IBIAS   (3 << 10)
 
+#define MIPITX_D2P_RTCODE  0x0100
 #define MIPITX_D2_SW_CTL_EN0x0144
 #define MIPITX_D0_SW_CTL_EN0x0244
 #define MIPITX_CK_CKMODE_EN0x0328
@@ -108,6 +109,24 @@ static const struct clk_ops mtk_mipi_tx_pll_ops = {
.recalc_rate = mtk_mipi_tx_pll_recalc_rate,
 };
 
+static void mtk_mipi_tx_config_calibration_data(struct mtk_mipi_tx *mipi_tx)
+{
+   int i, j;
+
+   for (i = 0; i < 5; i++) {
+   if ((mipi_tx->rt_code[i] & 0x1f) == 0)
+   mipi_tx->rt_code[i] |= 0x10;
+
+   if ((mipi_tx->rt_code[i] >> 5 & 0x1f) == 0)
+   mipi_tx->rt_code[i] |= 0x10 << 5;
+
+   for (j = 0; j < 10; j++)
+   mtk_mipi_tx_update_bits(mipi_tx,
+   MIPITX_D2P_RTCODE * (i + 1) + j * 4,
+   1, mipi_tx->rt_code[i] >> j & 1);
+   }
+}
+
 static void mtk_mipi_tx_power_on_signal(struct phy *phy)
 {
struct mtk_mipi_tx *mipi_tx = phy_get_drvdata(phy);
@@ -130,6 +149,8 @@ static void mtk_mipi_tx_power_on_signal(struct phy *phy)
RG_DSI_HSTX_LDO_REF_SEL,
(mipi_

[PATCH v5 1/4] dt-bindings: display: mediatek: add property to control mipi tx drive current

[Jitao Shi]

Add a property to control mipi tx drive current:
"drive-strength-microamp"

Reviewed-by: Chun-Kuang Hu 
Signed-off-by: Jitao Shi 
---
 .../devicetree/bindings/display/mediatek/mediatek,dsi.txt| 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
index a19a6cc375ed..d78b6d6d8fab 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
@@ -33,6 +33,10 @@ Required properties:
 - #clock-cells: must be <0>;
 - #phy-cells: must be <0>.
 
+Optional properties:
+- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And
+  the step is 200.
+
 Example:
 
 mipi_tx0: mipi-dphy@10215000 {
@@ -42,6 +46,7 @@ mipi_tx0: mipi-dphy@10215000 {
clock-output-names = "mipi_tx0_pll";
#clock-cells = <0>;
#phy-cells = <0>;
+   drive-strength-microamp = <4600>;
 };
 
 dsi0: dsi@1401b000 {
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 2/4] dt-bindings: display: mediatek: get mipitx calibration data from nvmem

[Jitao Shi]

Add properties to get get mipitx calibration data.

Reviewed-by: Chun-Kuang Hu 
Reviewed-by: Rob Herring 
Signed-off-by: Jitao Shi 
---
 .../devicetree/bindings/display/mediatek/mediatek,dsi.txt| 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
index d78b6d6d8fab..8e4729de8c85 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
@@ -36,6 +36,9 @@ Required properties:
 Optional properties:
 - drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And
   the step is 200.
+- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
+   unspecified default values shall be used.
+- nvmem-cell-names: Should be "calibration-data"
 
 Example:
 
@@ -47,6 +50,8 @@ mipi_tx0: mipi-dphy@10215000 {
#clock-cells = <0>;
#phy-cells = <0>;
drive-strength-microamp = <4600>;
+   nvmem-cells= <&mipi_tx_calibration>;
+   nvmem-cell-names = "calibration-data";
 };
 
 dsi0: dsi@1401b000 {
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 3/4] drm/mediatek: add the mipitx driving control

[Jitao Shi]

Add a property in device tree to control the driving by different
board.

Reviewed-by: Chun-Kuang Hu 
Reviewed-by: Matthias Brugger 
Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 14 ++
 drivers/gpu/drm/mediatek/mtk_mipi_tx.h|  1 +
 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c |  7 +++
 3 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c 
b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
index e4d34484ecc8..e301af64809e 100644
--- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
+++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
@@ -125,6 +125,20 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
return ret;
}
 
+   ret = of_property_read_u32(dev->of_node, "drive-strength-microamp",
+  &mipi_tx->mipitx_drive);
+   /* If can't get the "mipi_tx->mipitx_drive", set it default 0x8 */
+   if (ret < 0)
+   mipi_tx->mipitx_drive = 4600;
+
+   /* check the mipitx_drive valid */
+   if (mipi_tx->mipitx_drive > 6000 || mipi_tx->mipitx_drive < 3000) {
+   dev_warn(dev, "drive-strength-microamp is invalid %d, not in 
3000 ~ 6000\n",
+mipi_tx->mipitx_drive);
+   mipi_tx->mipitx_drive = clamp_val(mipi_tx->mipitx_drive, 3000,
+ 6000);
+   }
+
ref_clk_name = __clk_get_name(ref_clk);
 
ret = of_property_read_string(dev->of_node, "clock-output-names",
diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h 
b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
index 413f35d86219..eea44327fe9f 100644
--- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
+++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
@@ -27,6 +27,7 @@ struct mtk_mipi_tx {
struct device *dev;
void __iomem *regs;
u32 data_rate;
+   u32 mipitx_drive;
const struct mtk_mipitx_data *driver_data;
struct clk_hw pll_hw;
struct clk *pll;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c 
b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
index 91f08a351fd0..e4cc967750cb 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
@@ -17,6 +17,9 @@
 #define RG_DSI_BG_CORE_EN  BIT(7)
 #define RG_DSI_PAD_TIEL_SELBIT(8)
 
+#define MIPITX_VOLTAGE_SEL 0x0010
+#define RG_DSI_HSTX_LDO_REF_SEL(0xf << 6)
+
 #define MIPITX_PLL_PWR 0x0028
 #define MIPITX_PLL_CON00x002c
 #define MIPITX_PLL_CON10x0030
@@ -123,6 +126,10 @@ static void mtk_mipi_tx_power_on_signal(struct phy *phy)
mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_D3_SW_CTL_EN, DSI_SW_CTL_EN);
mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_CK_SW_CTL_EN, DSI_SW_CTL_EN);
 
+   mtk_mipi_tx_update_bits(mipi_tx, MIPITX_VOLTAGE_SEL,
+   RG_DSI_HSTX_LDO_REF_SEL,
+   (mipi_tx->mipitx_drive - 3000) / 200 << 6);
+
mtk_mipi_tx_set_bits(mipi_tx, MIPITX_CK_CKMODE_EN, DSI_CK_CKMODE_EN);
 }
 
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

[Sergey Senozhatsky]

On (20/04/09 10:08), Minchan Kim wrote:
> > > Even though I don't know how many usecase we have using zsmalloc as
> > > module(I heard only once by dumb reason), it could affect existing
> > > users. Thus, please include concrete explanation in the patch to
> > > justify when the complain occurs.
> > 
> > The justification is 'we can unexport functions that have no sane reason
> > of being exported in the first place'.
> > 
> > The Changelog pretty much says that.
> 
> Okay, I hope there is no affected user since this patch.
> If there are someone, they need to provide sane reason why they want
> to have zsmalloc as module.

I'm one of those who use zsmalloc as a module - mainly because I use zram
as a compressing general purpose block device, not as a swap device.
I create zram0, mkfs, mount, checkout and compile code, once done -
umount, rmmod. This reduces the number of writes to SSD. Some people use
tmpfs, but zram device(-s) can be much larger in size. That's a niche use
case and I'm not against the patch.

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

Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete worker

[Chunming Zhou]

We can have both of yours, I think.

Even switch to use spin_trylock, I think we are ok to have 
cond_resched() Xinhui added in this patch. That can give more chance to 
urgent task to use cpu.



-David

在 2020/4/9 22:59, Christian König 写道:

Why we break out the loops when there are pending bos to be released?


We do this anyway if we can't acquire the necessary locks. Freeing 
already deleted BOs is just a very lazy background work.



So it did not break anything with this patch I think.


Oh, the patch will certainly work. I'm just not sure if it's the ideal 
behavior.



https://elixir.bootlin.com/linux/latest/source/mm/slab.c#L4026

This is another example of the usage of  cond_sched.


Yes, and that is also a good example of what I mean here:

	if  (!mutex_trylock 
(&slab_mutex 
))

/* Give up. Setup the next iteration. */
goto  out;


If the function can't acquire the lock immediately it gives up and 
waits for the next iteration.


I think it would be better if we do this in TTM as well if we spend to 
much time cleaning up old BOs.


On the other hand you are right that cond_resched() has the advantage 
that we could spend more time on cleaning up old BOs if there is 
nothing else for the CPU TODO.


Regards,
Christian.

Am 09.04.20 um 16:24 schrieb Pan, Xinhui:

https://elixir.bootlin.com/linux/latest/source/mm/slab.c#L4026

This is another example of the usage of  cond_sched.

*From:* Pan, Xinhui 
*Sent:* Thursday, April 9, 2020 10:11:08 PM
*To:* Lucas Stach ; 
amd-...@lists.freedesktop.org ; 
Koenig, Christian 

*Cc:* dri-devel@lists.freedesktop.org 
*Subject:* Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed 
delete worker
I think it doesn't matter if workitem schedule out. Even we did not 
schedule out, the workqueue itself will schedule out later.

So it did not break anything with this patch I think.

*From:* Pan, Xinhui 
*Sent:* Thursday, April 9, 2020 10:07:09 PM
*To:* Lucas Stach ; 
amd-...@lists.freedesktop.org ; 
Koenig, Christian 

*Cc:* dri-devel@lists.freedesktop.org 
*Subject:* Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed 
delete worker

Why we break out the loops when there are pending bos to be released?

And I just checked the process_one_work. Right after the work item 
callback is called,  the workqueue itself will call cond_resched. So 
I think


*From:* Koenig, Christian 
*Sent:* Thursday, April 9, 2020 9:38:24 PM
*To:* Lucas Stach ; Pan, Xinhui 
; amd-...@lists.freedesktop.org 


*Cc:* dri-devel@lists.freedesktop.org 
*Subject:* Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed 
delete worker

Am 09.04.20 um 15:25 schrieb Lucas Stach:
> Am Donnerstag, den 09.04.2020, 14:35 +0200 schrieb Christian König:
>> Am 09.04.20 um 03:31 schrieb xinhui pan:
>>> The delayed delete list is per device which might be very huge. 
And in

>>> a heavy workload test, the list might always not be empty. That will
>>> trigger any RCU stall warnings or softlockups in non-preemptible 
kernels

>>> Lets do schedule out if possible in that case.
>> Mhm, I'm not sure if that is actually allowed. This is called from a
>> work item and those are not really supposed to be scheduled away.
> Huh? Workitems can schedule out just fine, otherwise they would be
> horribly broken when it comes to sleeping locks.

Let me refine the sentence: Work items are not really supposed to be
scheduled purposely. E.g. you shouldn't call schedule() or
cond_resched() like in the case here.

Getting scheduled away because we wait for a lock is of course perfectly
fine.

>   The workqueue code
> even has measures to keep the workqueues at the expected concurrency
> level by starting other workitems when one of them goes to sleep.

Yeah, and exactly that's what I would say we should avoid here :)

In other words work items can be scheduled away, but they should not if
not really necessary (e.g. waiting for a lock).

Otherwise as you said new threads for work item processing are started
up and I don't think we want that.

Just returning from the work item and waiting for the next cycle is most
likely 

Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete worker

[Pan, Xinhui]

> 2020年4月9日 22:59，Koenig, Christian  写道：
> 
>> Why we break out the loops when there are pending bos to be released?
> 
> We do this anyway if we can't acquire the necessary locks. Freeing already 
> deleted BOs is just a very lazy background work.

That is true. eviction will reclaim the BO resource too.

> 
>> So it did not break anything with this patch I think.
> 
> Oh, the patch will certainly work. I'm just not sure if it's the ideal 
> behavior.
> 
>> https://elixir.bootlin.com/linux/latest/source/mm/slab.c#L4026
>> 
>> This is another example of the usage of  cond_sched.
> 
> Yes, and that is also a good example of what I mean here:
> 
>>  if (!mutex_trylock(&slab_mutex))
>> 
>>  
>> /* Give up. Setup the next iteration. */
>> 
>>  
>> goto out;
> 
> If the function can't acquire the lock immediately it gives up and waits for 
> the next iteration.
> 
> I think it would be better if we do this in TTM as well if we spend to much 
> time cleaning up old BOs.

fair enough.

> 
> On the other hand you are right that cond_resched() has the advantage that we 
> could spend more time on cleaning up old BOs if there is nothing else for the 
> CPU TODO.
> 
> Regards,
> Christian.
> 
> Am 09.04.20 um 16:24 schrieb Pan, Xinhui:
>> https://elixir.bootlin.com/linux/latest/source/mm/slab.c#L4026
>> 
>> This is another example of the usage of  cond_sched.
>> From: Pan, Xinhui 
>> Sent: Thursday, April 9, 2020 10:11:08 PM
>> To: Lucas Stach ; amd-...@lists.freedesktop.org 
>> ; Koenig, Christian 
>> Cc: dri-devel@lists.freedesktop.org 
>> Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete 
>> worker
>>  
>> I think it doesn't matter if workitem schedule out. Even we did not schedule 
>> out, the workqueue itself will schedule out later.
>> So it did not break anything with this patch I think.
>> From: Pan, Xinhui 
>> Sent: Thursday, April 9, 2020 10:07:09 PM
>> To: Lucas Stach ; amd-...@lists.freedesktop.org 
>> ; Koenig, Christian 
>> Cc: dri-devel@lists.freedesktop.org 
>> Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete 
>> worker
>>  
>> Why we break out the loops when there are pending bos to be released?
>> 
>> And I just checked the process_one_work. Right after the work item callback 
>> is called,  the workqueue itself will call cond_resched. So I think
>> From: Koenig, Christian 
>> Sent: Thursday, April 9, 2020 9:38:24 PM
>> To: Lucas Stach ; Pan, Xinhui ; 
>> amd-...@lists.freedesktop.org 
>> Cc: dri-devel@lists.freedesktop.org 
>> Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete 
>> worker
>>  
>> Am 09.04.20 um 15:25 schrieb Lucas Stach:
>> > Am Donnerstag, den 09.04.2020, 14:35 +0200 schrieb Christian König:
>> >> Am 09.04.20 um 03:31 schrieb xinhui pan:
>> >>> The delayed delete list is per device which might be very huge. And in
>> >>> a heavy workload test, the list might always not be empty. That will
>> >>> trigger any RCU stall warnings or softlockups in non-preemptible kernels
>> >>> Lets do schedule out if possible in that case.
>> >> Mhm, I'm not sure if that is actually allowed. This is called from a
>> >> work item and those are not really supposed to be scheduled away.
>> > Huh? Workitems can schedule out just fine, otherwise they would be
>> > horribly broken when it comes to sleeping locks.
>> 
>> Let me refine the sentence: Work items are not really supposed to be 
>> scheduled purposely. E.g. you shouldn't call schedule() or 
>> cond_resched() like in the case here.
>> 
>> Getting scheduled away because we wait for a lock is of course perfectly 
>> fine.
>> 
>> >   The workqueue code
>> > even has measures to keep the workqueues at the expected concurrency
>> > level by starting other workitems when one of them goes to sleep.
>> 
>> Yeah, and exactly that's what I would say we should avoid here :)
>> 
>> In other words work items can be scheduled away, but they should not if 
>> not really necessary (e.g. waiting for a lock).
>> 
>> Otherwise as you said new threads for work item processing are started 
>> up and I don't think we want that.
>> 
>> Just returning from the work item and waiting for the next cycle is most 
>> likely the better option.
>> 
>> Regards,
>> Christian.
>> 
>> >
>> > Regards,
>> > Lucas
>> >
>> >> Maybe rather change the while into while (!list_empty(&bdev->ddestroy)
>> >> && !should_reschedule(0)).
>> >>
>> >> Christian.
>> >>
>> >>> Signed-off-by: xinhui pan 
>> >>> ---
>> >>>drivers/gpu/drm/ttm/ttm_bo.c | 1 +
>> >>>1 file changed, 1 insertion(+)
>> >>>
>> >>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> >>> index 9e07c3f75156..b8d853cab33b 100644
>> >>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> >>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> >>> @@ -541,6 +541,7 @@ static bool ttm_bo_delayed_delete(struct 
>> >>> ttm_bo_device *bdev, bool remove_all)
>> >>>  }
>> >>>
>> >>>  ttm_bo_put(bo);
>> >>

[PATCH v6 4/5] drm/msm: Refactor address space initialization

[Jordan Crouse]

Refactor how address space initialization works. Instead of having the
address space function create the MMU object (and thus require separate but
equal functions for gpummu and iommu) use a single function and pass the
MMU struct in. Make the generic code cleaner by using target specific
functions to create the address space so a2xx can do its own thing in its
own space.  For all the other targets use a generic helper to initialize
IOMMU but leave the door open for newer targets to use customization
if they need it.

Reviewed-by: Rob Clark 
Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a2xx_gpu.c| 16 
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 23 ---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h  |  8 
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 10 ++---
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 14 ---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c |  4 --
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 11 -
 drivers/gpu/drm/msm/msm_drv.h|  8 +---
 drivers/gpu/drm/msm/msm_gem_vma.c| 51 +++-
 drivers/gpu/drm/msm/msm_gpu.c| 40 +--
 drivers/gpu/drm/msm/msm_gpu.h|  4 +-
 drivers/gpu/drm/msm/msm_iommu.c  |  3 ++
 16 files changed, 82 insertions(+), 114 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index 1f83bc18d500..60f6472a3e58 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -401,6 +401,21 @@ static struct msm_gpu_state *a2xx_gpu_state_get(struct 
msm_gpu *gpu)
return state;
 }
 
+static struct msm_gem_address_space *
+a2xx_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev)
+{
+   struct msm_mmu *mmu = msm_gpummu_new(&pdev->dev, gpu);
+   struct msm_gem_address_space *aspace;
+
+   aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
+   SZ_16M + 0xfff * SZ_64K);
+
+   if (IS_ERR(aspace) && !IS_ERR(mmu))
+   mmu->funcs->destroy(mmu);
+
+   return aspace;
+}
+
 /* Register offset defines for A2XX - copy of A3XX */
 static const unsigned int a2xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_AXXX_CP_RB_BASE),
@@ -429,6 +444,7 @@ static const struct adreno_gpu_funcs funcs = {
 #endif
.gpu_state_get = a2xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
+   .create_address_space = a2xx_create_address_space,
},
 };
 
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index b67f88872726..0a5ea9f56cb8 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -441,6 +441,7 @@ static const struct adreno_gpu_funcs funcs = {
 #endif
.gpu_state_get = a3xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
+   .create_address_space = adreno_iommu_create_address_space,
},
 };
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 253d8d85daad..b626afb0627d 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -532,6 +532,7 @@ static const struct adreno_gpu_funcs funcs = {
 #endif
.gpu_state_get = a4xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
+   .create_address_space = adreno_iommu_create_address_space,
},
.get_timestamp = a4xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 724024a2243a..e81b1deaf535 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1439,6 +1439,7 @@ static const struct adreno_gpu_funcs funcs = {
.gpu_busy = a5xx_gpu_busy,
.gpu_state_get = a5xx_gpu_state_get,
.gpu_state_put = a5xx_gpu_state_put,
+   .create_address_space = adreno_iommu_create_address_space,
},
.get_timestamp = a5xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 68af24150de5..02ade43d6335 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -847,6 +847,7 @@ static const struct adreno_gpu_funcs funcs = {
.gpu_state_get = a6xx_gpu_state_get,
.gpu_state_put = a6xx_gpu_state_put,
 #endif
+   .create_address_space = adreno_iommu_create_address_space,
},
.get_timestamp = a6xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adren

[PATCH v6 0/5] iommu/arm-smmu: Split pagetable support for arm-smmu-v2

[Jordan Crouse]

This is another iteration for the split pagetable support based on the
suggestions from Robin and Will [1].

Background: In order to support per-context pagetables the GPU needs to enable
split tables so that we can store global buffers in the TTBR1 space leaving the
GPU free to program the TTBR0 register with the address of a context specific
pagetable.

If the DOMAIN_ATTR_SPLIT_TABLES attribute is set on the domain before attaching,
the context bank assigned to the domain will be programmed to allow translations
in the TTBR1 space. Translations in the TTBR0 region will be disallowed because,
as Robin pointe out, having a un-programmed TTBR0 register is dangerous.

The driver can determine if TTBR1 was successfully programmed by querying
DOMAIN_ATTR_SPLIT_TABLES after attaching. The domain geometry will also be
updated to reflect the virtual address space for the TTBR1 range.

Upcoming changes will allow auxiliary domains to be attached to the device which
will enable and program TTBR0.

This patchset is based on top of linux-next-20200409

Change log:

v6: Cleanups for the arm-smmu TTBR1 patch from Will Deacon
v4: Only program TTBR1 when split pagetables are requested. TTBR0 will be
enabled later when an auxiliary domain is attached
v3: Remove the implementation specific and make split pagetable support
part of the generic configuration

[1] https://lists.linuxfoundation.org/pipermail/iommu/2020-January/041373.html


Jordan Crouse (5):
  iommu: Add DOMAIN_ATTR_SPLIT_TABLES
  iommu/arm-smmu: Add support for TTBR1
  drm/msm: Attach the IOMMU device during initialization
  drm/msm: Refactor address space initialization
  drm/msm/a6xx: Support split pagetables

 drivers/gpu/drm/msm/adreno/a2xx_gpu.c| 16 
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c| 51 
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 23 ---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h  |  8 
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 18 +++--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 18 -
 drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c |  4 --
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 18 -
 drivers/gpu/drm/msm/msm_drv.h|  8 +---
 drivers/gpu/drm/msm/msm_gem_vma.c| 36 +++--
 drivers/gpu/drm/msm/msm_gpu.c| 49 +--
 drivers/gpu/drm/msm/msm_gpu.h|  4 +-
 drivers/gpu/drm/msm/msm_gpummu.c |  6 ---
 drivers/gpu/drm/msm/msm_iommu.c  | 18 +
 drivers/gpu/drm/msm/msm_mmu.h|  1 -
 drivers/iommu/arm-smmu.c | 48 ++
 drivers/iommu/arm-smmu.h | 24 ---
 include/linux/iommu.h|  2 +
 21 files changed, 200 insertions(+), 155 deletions(-)

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

[PATCH v6 5/5] drm/msm/a6xx: Support split pagetables

[Jordan Crouse]

Attempt to enable split pagetables if the arm-smmu driver supports it.
This will move the default address space from the default region to
the address range assigned to TTBR1. The behavior should be transparent
to the driver for now but it gets the default buffers out of the way
when we want to start swapping TTBR0 for context-specific pagetables.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 52 ++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 02ade43d6335..b27daa77723c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -825,6 +825,56 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
return (unsigned long)busy_time;
 }
 
+static struct msm_gem_address_space *
+a6xx_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev)
+{
+   struct iommu_domain *iommu = iommu_domain_alloc(&platform_bus_type);
+   struct msm_gem_address_space *aspace;
+   struct msm_mmu *mmu;
+   u64 start, size;
+   u32 val = 1;
+   int ret;
+
+   if (!iommu)
+   return ERR_PTR(-ENOMEM);
+
+   /*
+* Try to request split pagetables - the request has to be made before
+* the domian is attached
+*/
+   iommu_domain_set_attr(iommu, DOMAIN_ATTR_SPLIT_TABLES, &val);
+
+   mmu = msm_iommu_new(&pdev->dev, iommu);
+   if (IS_ERR(mmu)) {
+   iommu_domain_free(iommu);
+   return ERR_CAST(mmu);
+   }
+
+   /*
+* After the domain is attached, see if the split tables were actually
+* successful.
+*/
+   ret = iommu_domain_get_attr(iommu, DOMAIN_ATTR_SPLIT_TABLES, &val);
+   if (!ret && val) {
+   /*
+* The aperture start will be at the beginning of the TTBR1
+* space so use that as a base
+*/
+   start = iommu->geometry.aperture_start;
+   size = 0x;
+   } else {
+   /* Otherwise use the legacy 32 bit region */
+   start = SZ_16M;
+   size = 0x - SZ_16M;
+   }
+
+   aspace = msm_gem_address_space_create(mmu, "gpu", start, size);
+   if (IS_ERR(aspace))
+   iommu_domain_free(iommu);
+
+   return aspace;
+}
+
 static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -847,7 +897,7 @@ static const struct adreno_gpu_funcs funcs = {
.gpu_state_get = a6xx_gpu_state_get,
.gpu_state_put = a6xx_gpu_state_put,
 #endif
-   .create_address_space = adreno_iommu_create_address_space,
+   .create_address_space = a6xx_create_address_space,
},
.get_timestamp = a6xx_get_timestamp,
 };
-- 
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 3/5] drm/msm: Attach the IOMMU device during initialization

[Jordan Crouse]

Everywhere an IOMMU object is created by msm_gpu_create_address_space
the IOMMU device is attached immediately after. Instead of carrying around
the infrastructure to do the attach from the device specific code do it
directly in the msm_iommu_init() function. This gets it out of the way for
more aggressive cleanups that follow.

Reviewed-by: Rob Clark 
Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  8 
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c |  4 
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  7 ---
 drivers/gpu/drm/msm/msm_gem_vma.c| 23 +++
 drivers/gpu/drm/msm/msm_gpu.c| 11 +--
 drivers/gpu/drm/msm/msm_gpummu.c |  6 --
 drivers/gpu/drm/msm/msm_iommu.c  | 15 +++
 drivers/gpu/drm/msm/msm_mmu.h|  1 -
 8 files changed, 27 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ce19f1d39367..6629a142574e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -772,7 +772,6 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
 {
struct iommu_domain *domain;
struct msm_gem_address_space *aspace;
-   int ret;
 
domain = iommu_domain_alloc(&platform_bus_type);
if (!domain)
@@ -788,13 +787,6 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
return PTR_ERR(aspace);
}
 
-   ret = aspace->mmu->funcs->attach(aspace->mmu);
-   if (ret) {
-   DPU_ERROR("failed to attach iommu %d\n", ret);
-   msm_gem_address_space_put(aspace);
-   return ret;
-   }
-
dpu_kms->base.aspace = aspace;
return 0;
 }
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index dda05436f716..9dba37c6344f 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -518,10 +518,6 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
}
 
kms->aspace = aspace;
-
-   ret = aspace->mmu->funcs->attach(aspace->mmu);
-   if (ret)
-   goto fail;
} else {
DRM_DEV_INFO(dev->dev, "no iommu, fallback to phys "
"contig buffers for scanout\n");
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 47b989834af1..1e9ba99fd9eb 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -644,13 +644,6 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
}
 
kms->aspace = aspace;
-
-   ret = aspace->mmu->funcs->attach(aspace->mmu);
-   if (ret) {
-   DRM_DEV_ERROR(&pdev->dev, "failed to attach iommu: 
%d\n",
-   ret);
-   goto fail;
-   }
} else {
DRM_DEV_INFO(&pdev->dev,
 "no iommu, fallback to phys contig buffers for 
scanout\n");
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c 
b/drivers/gpu/drm/msm/msm_gem_vma.c
index 1af5354bcd46..91d993a16850 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -131,8 +131,8 @@ msm_gem_address_space_create(struct device *dev, struct 
iommu_domain *domain,
const char *name)
 {
struct msm_gem_address_space *aspace;
-   u64 size = domain->geometry.aperture_end -
-   domain->geometry.aperture_start;
+   u64 start = domain->geometry.aperture_start;
+   u64 size = domain->geometry.aperture_end - start;
 
aspace = kzalloc(sizeof(*aspace), GFP_KERNEL);
if (!aspace)
@@ -141,9 +141,18 @@ msm_gem_address_space_create(struct device *dev, struct 
iommu_domain *domain,
spin_lock_init(&aspace->lock);
aspace->name = name;
aspace->mmu = msm_iommu_new(dev, domain);
+   if (IS_ERR(aspace->mmu)) {
+   int ret = PTR_ERR(aspace->mmu);
 
-   drm_mm_init(&aspace->mm, (domain->geometry.aperture_start >> 
PAGE_SHIFT),
-   size >> PAGE_SHIFT);
+   kfree(aspace);
+   return ERR_PTR(ret);
+   }
+
+   /*
+* Attaching the IOMMU device changes the aperture values so use the
+* cached values instead
+*/
+   drm_mm_init(&aspace->mm, start >> PAGE_SHIFT, size >> PAGE_SHIFT);
 
kref_init(&aspace->kref);
 
@@ -164,6 +173,12 @@ msm_gem_address_space_create_a2xx(struct device *dev, 
struct msm_gpu *gpu,
spin_lock_init(&aspace->lock);
aspace->name = name;
aspace->mmu = msm_gpummu_new(dev, gpu);
+   if (IS_ERR(aspace->mmu)) {
+   int ret = PTR_ERR(aspace->mmu);
+
+   kfree(aspace);
+   return ERR_P

Re: [PATCH v2 1/4] dt-bindings: display: Add IPK DSI subsystem bindings

[Rob Herring]

On Mon,  6 Apr 2020 15:24:11 +0200, Angelo Ribeiro wrote:
> Add dt-bindings for Synopsys DesignWare MIPI DSI Host and VPG (Video
> Pattern Generator) support in the IPK display subsystem.
> 
> The Synopsys DesignWare IPK display video pipeline is composed by a DSI
> controller (snps,dw-ipk-dsi) and a VPG (snps,dw-ipk-vpg) as DPI
> stimulus. Typically is used the Raspberry Pi
> (raspberrypi,7inch-touchscreen-panel) as DSI panel that requires a
> I2C controller (snps,designware-i2c).
> 
> Reported-by: Rob Herring 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Gustavo Pimentel 
> Cc: Joao Pinto 
> Signed-off-by: Angelo Ribeiro 
> ---
>  .../bindings/display/snps,dw-ipk-dsi.yaml  | 162 
> +
>  .../bindings/display/snps,dw-ipk-vpg.yaml  |  75 ++
>  2 files changed, 237 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/snps,dw-ipk-vpg.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.example.dts:60.17-30: 
Warning (reg_format): /example-0/i2c@0x01000/lcd@45:reg: property has invalid 
length (4 bytes) (#address-cells == 2, #size-cells == 1)
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.example.dt.yaml: 
Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.example.dts:49.21-68.11:
 Warning (i2c_bus_bridge): /example-0/i2c@0x01000: incorrect #address-cells for 
I2C bus
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.example.dts:49.21-68.11:
 Warning (i2c_bus_bridge): /example-0/i2c@0x01000: incorrect #size-cells for 
I2C bus
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.example.dt.yaml: 
Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.example.dt.yaml: 
Warning (i2c_bus_reg): Failed prerequisite 'i2c_bus_bridge'
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.example.dt.yaml: 
Warning (spi_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.example.dts:58.20-67.15:
 Warning (avoid_default_addr_size): /example-0/i2c@0x01000/lcd@45: Relying on 
default #address-cells value
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.example.dts:58.20-67.15:
 Warning (avoid_default_addr_size): /example-0/i2c@0x01000/lcd@45: Relying on 
default #size-cells value
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/snps,dw-ipk-vpg.example.dt.yaml:
 example-0: 'dw-dsi-vpg@0x03000' does not match any of the regexes: 
'.*-names$', '.*-supply$', '^#.*-cells$', '^#[a-zA-Z0-9,+\\-._]{0,63}$', 
'^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}$', 
'^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+(,[0-9a-fA-F]+)*$', '^__.*__$', 
'pinctrl-[0-9]+'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/snps,dw-ipk-vpg.example.dt.yaml:
 dw-dsi-vpg@0x03000: '#address-cells', '#size-cells' do not match any of the 
regexes: 'pinctrl-[0-9]+'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.example.dt.yaml:
 example-0: 'dw-ipk-dsi@0x02000', 'i2c@0x01000' do not match any of the 
regexes: '.*-names$', '.*-supply$', '^#.*-cells$', 
'^#[a-zA-Z0-9,+\\-._]{0,63}$', '^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}$', 
'^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+(,[0-9a-fA-F]+)*$', '^__.*__$', 
'pinctrl-[0-9]+'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.example.dt.yaml:
 dw-ipk-dsi@0x02000: clock-names: ['pclk', 'ref'] is too short
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.example.dt.yaml:
 dw-ipk-dsi@0x02000: 'reset' is a required property

See https://patchwork.ozlabs.org/patch/1266879

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc

[Benjamin Herrenschmidt]

On Thu, 2020-04-09 at 11:41 +0200, Daniel Vetter wrote:
> Now if these boxes didn't ever have agp then I think we can get away
> with deleting this, since we've already deleted the legacy radeon
> driver. And that one used vmalloc for everything. The new kms one does
> use the dma-api if the gpu isn't connected through agp

Definitely no AGP there.

Cheers
Ben.


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

Re: [PATCH 2/2] drm/i915: remove gvt/Makefile

[Jani Nikula]

On Fri, 10 Apr 2020, Masahiro Yamada  wrote:
> Including subdirectory Makefile from the driver main Makefile does not
> buy us much because this is not real isolation.

The isolation it does buy us is that gvt/ subdirectory is developed and
maintained on a separate mailing list and separate git repo. I think at
some point there were plans to make it an actual module too.

So while you could quip about Conway's law here, I think it might be
better to keep this as it is.

Zhenyu, Zhi, what do you think?


BR,
Jani.


>
> Having a single Makefile at the top of the module is clearer, and
> it is what this driver almost does.
>
> Move all gvt objects to the i915 main Makefile.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/gpu/drm/i915/Makefile | 28 
>  drivers/gpu/drm/i915/gvt/Makefile |  8 
>  2 files changed, 24 insertions(+), 12 deletions(-)
>  delete mode 100644 drivers/gpu/drm/i915/gvt/Makefile
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 6cd1f6253814..74e965882a98 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -275,10 +275,30 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
>  # virtual gpu code
>  i915-y += i915_vgpu.o
>  
> -ifeq ($(CONFIG_DRM_I915_GVT),y)
> -i915-y += intel_gvt.o
> -include $(src)/gvt/Makefile
> -endif
> +i915-$(CONFIG_DRM_I915_GVT) += \
> + intel_gvt.o \
> + gvt/gvt.o \
> + gvt/aperture_gm.o \
> + gvt/handlers.o \
> + gvt/vgpu.o \
> + gvt/trace_points.o \
> + gvt/firmware.o \
> + gvt/interrupt.o \
> + gvt/gtt.o \
> + gvt/cfg_space.o \
> + gvt/opregion.o \
> + gvt/mmio.o \
> + gvt/display.o \
> + gvt/edid.o \
> + gvt/execlist.o \
> + gvt/scheduler.o \
> + gvt/sched_policy.o \
> + gvt/mmio_context.o \
> + gvt/cmd_parser.o \
> + gvt/debugfs.o \
> + gvt/fb_decoder.o \
> + gvt/dmabuf.o \
> + gvt/page_track.o
>  
>  obj-$(CONFIG_DRM_I915) += i915.o
>  obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
> b/drivers/gpu/drm/i915/gvt/Makefile
> deleted file mode 100644
> index 4d70f4689479..
> --- a/drivers/gpu/drm/i915/gvt/Makefile
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0
> -GVT_DIR := gvt
> -GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o 
> firmware.o \
> - interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
> - execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o 
> debugfs.o \
> - fb_decoder.o dmabuf.o page_track.o
> -
> -i915-y   += $(addprefix $(GVT_DIR)/, 
> $(GVT_SOURCE))

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 207183] New: radeon.dpm=1 with second monitor runs hot

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=207183

Bug ID: 207183
   Summary: radeon.dpm=1 with second monitor runs hot
   Product: Drivers
   Version: 2.5
Kernel Version: 5.3.18
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: ehu...@gmail.com
Regression: No

Created attachment 288315
  --> https://bugzilla.kernel.org/attachment.cgi?id=288315&action=edit
dmesg | grep -iE "drm|radeon"

for a long time, I've been searching for the reason why my card was running
fans high on Linux. (It started after a kernel update; don't know which one --
years ago) While at the time, I ran Windows on the same laptop every now and
then, it would work correctly.

My card reports `lspci | grep VGA`:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus
XT [Radeon HD 8870M / R9 M270X/M370X]


Without radeon.dpm or with radeon.dpm=1, the card runs hot: within minutes fans
will run at 3300+ RPM keeping the card barely below 66 degC. Note that
`radeontop` reports an `Graphics pipe` of 0.00% most of the time.

After discovery of the setting radeon.dpm yesterday, after a few failed trials
to set the setting to '1', I set `radeon.dpm=0`. After letting the PC cool down
(turned off) and starting again, the PC ran 10 minutes without fans and is
running at 53 degC with fans running at 2100 RPM.

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

[git pull] drm fixes for 5.7-rc1 (part two)

[Dave Airlie]

Hey Linus,

As previously mentioned more fixes did turn up in the latter part of the week.

The drm_local_map build regression fix is here, along with temporary
disabling of the hugepage work due to some amdgpu related crashes.

Otherwise it's just a bunch of i915, and amdgpu fixes.

Have a good Easter!
Dave.

drm-next-2020-04-10:
drm fixes for 5.7-rc1 (part two)

legacy:
- fix drm_local_map.offset type

ttm:
- temporarily disable hugepages to debug amdgpu problems.

prime:
- fix sg extraction

amdgpu:
- Various Renoir fixes
- Fix gfx clockgating sequence on gfx10
- RAS fixes
- Avoid MST property creation after registration
- Various cursor/viewport fixes
- Fix a confusing log message about optional firmwares

i915:
- Flush all the reloc_gpu batch (Chris)
- Ignore readonly failures when updating relocs (Chris)
- Fill all the unused space in the GGTT (Chris)
- Return the right vswing table (Jose)
- Don't enable DDI IO power on a TypeC port in TBT mode for ICL+ (Imre)

analogix_dp:
- probe fix

virtio:
- oob fix in object create
The following changes since commit 12ab316ced2c5f32ced0e6300a054db644b5444a:

  Merge tag 'amd-drm-next-5.7-2020-04-01' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2020-04-08
09:34:27 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-04-10

for you to fetch changes up to 74bd4f0c921cc9cf5f99ba4129dafe35496de6f3:

  Merge tag 'amd-drm-fixes-5.7-2020-04-08' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2020-04-10
06:42:53 +1000)


drm fixes for 5.7-rc1 (part two)

legacy:
- fix drm_local_map.offset type

ttm:
- temporarily disable hugepages to debug amdgpu problems.

prime:
- fix sg extraction

amdgpu:
- Various Renoir fixes
- Fix gfx clockgating sequence on gfx10
- RAS fixes
- Avoid MST property creation after registration
- Various cursor/viewport fixes
- Fix a confusing log message about optional firmwares

i915:
- Flush all the reloc_gpu batch (Chris)
- Ignore readonly failures when updating relocs (Chris)
- Fill all the unused space in the GGTT (Chris)
- Return the right vswing table (Jose)
- Don't enable DDI IO power on a TypeC port in TBT mode for ICL+ (Imre)

analogix_dp:
- probe fix

virtio:
- oob fix in object create


Aaron Liu (1):
  drm/amdgpu: unify fw_write_wait for new gfx9 asics

Aaron Ma (1):
  drm/amdgpu: Fix oops when pp_funcs is unset in ACPI event

Alex Deucher (2):
  drm/amdgpu/psp: dont warn on missing optional TA's
  drm/amdgpu/display: fix warning when compiling without debugfs

Chengming Gui (1):
  drm/amd/amdgpu: Correct gfx10's CG sequence

Chris Wilson (4):
  drm/i915/gt: Fill all the unused space in the GGTT
  drm/i915/gem: Ignore readonly failures when updating relocs
  drm/i915/gem: Flush all the reloc_gpu batch
  drm/legacy: Fix type for drm_local_map.offset

Dave Airlie (3):
  Merge tag 'drm-misc-next-fixes-2020-04-09' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next
  Merge tag 'drm-intel-next-fixes-2020-04-08' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next
  Merge tag 'amd-drm-fixes-5.7-2020-04-08' of
git://people.freedesktop.org/~agd5f/linux into drm-next

Eric Yang (1):
  drm/amd/display: change default pipe_split policy for DCN1

Evan Quan (1):
  drm/amd/powerplay: error out on forcing clock setting not supported

Imre Deak (1):
  drm/i915/icl+: Don't enable DDI IO power on a TypeC port in TBT mode

Isabel Zhang (1):
  drm/amd/display: Update stream adjust in dc_stream_adjust_vmin_vmax

Jerry (Fangzhi) Zuo (1):
  drm/amd/display: Avoid create MST prop after registration

Jiri Slaby (1):
  drm/virtio: fix OOB in virtio_gpu_object_create

John Clements (2):
  drm/amdgpu: resolve mGPU RAS query instability
  drm/amdgpu: update RAS related dmesg print

Joshua Aberback (1):
  drm/amd/display: Acknowledge wm_optimized_required

José Roberto de Souza (1):
  drm/i915/dp: Return the right vswing tables

Likun Gao (1):
  drm/amdgpu: change SH MEM alignment mode for gfx10

Marek Szyprowski (2):
  drm/prime: fix extracting of the DMA addresses from a scatterlist
  drm/bridge: analogix_dp: Split bind() into probe() and real bind()

Maxime Ripard (1):
  Merge drm/drm-next into drm-misc-next-fixes

Michael Strauss (1):
  drm/amd/display: Check for null fclk voltage when parsing clock table

Nicholas Kazlauskas (5):
  drm/amd/display: Translate cursor position by source rect
  drm/amd/display: Fix incorrect cursor pos on scaled primary plane
  drm/amd/display: Program viewport when source pos changes for DCN20 hw seq
  drm/amd/display: Calculate scaling ratios on every medium/full update
  drm/amd/display: Make cursor source translation adjustment optional

Prike Liang (2):
  drm/amd/powerplay: i

Re: [PATCH v2 15/17] drm/gma500: Stop using mode->private_flags

[Sam Ravnborg]

Hi Ville.

> > > > > index 264d7ad004b4..9e88a37f55e9 100644
> > > > > --- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> > > > > +++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> > > > > @@ -132,6 +132,8 @@ struct psb_intel_sdvo {
> > > > >   /* DDC bus used by this SDVO encoder */
> > > > >   uint8_t ddc_bus;
> > > > >  
> > > > > + u8 pixel_multiplier;
> > > > > +
> > > > 
> > > > There is really no good reason to use an u8 here.
> > > 
> > > Wastes less space.
> > 
> > When there is a good reason - use the size limited variants.
> > But in this use case there is no reason to space optimize it.
> 
> IMO when it's stuffed into a structure there's no reason not to
> optimize it. At some point it all starts to add up.
> 
> At least i915 suffers a lot from bloated structures (dev_priv
> and atomic state structs being the prime examples) where we
> could probably shave dozens if not hundreds of bytes if
> everything just used the smallest type possible. In fact
> this series does shave dozens of bytes from the crtc state
> alone.

There is a difference between a structure used many times -
And a structure used once or only a few times.
If everyone started to optimize the types used, then we
would end up with code that is hard to maintain.

The point here is that we have a structure allocated maybe
once and a field assinged from a int - which using integer promotion
is then stuffed into an u8. If we one day start to be clever and
use values above 255 we need to find all the places where a
u8 was used to optimize size of some random struct.

If this was a struct instantiated many times and used all over
the story was another - but thats not the case here.
Here the principle of least suprises hold - do not change the type.

I try to explain the rationale behind the argument to use int.
Feel free to disagree.

> 
> > 
> > When in the slightly pedantic mode, using u8 is not consistent.
> > ddc_bus defined above usese uint8_t.
> 
> u8 & co. are preferred in kernel code. Checkpatch even complains when
> you use the stdint types. The uint8_t here is some old leftovers.

Mixing coding practice makes code less readable, no matter
the output of checkpatch.
The right fix would be to update gma500 to migrate away from the
stdint types. But that would be a sepearte patch for another day.

My orginal feedback on the patch has not changed.
Feel free to move forward with the patch without my r-b.

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

Re: [PATCH] drm/ttm: Temporarily disable the huge_fault() callback

[Dave Airlie]

On Fri, 10 Apr 2020 at 02:51, Thomas Hellström (VMware)
 wrote:
>
> Dave, Christian,
>
> Could any of you pick this up (I'm currently on vacation) to have a
> chance of getting it in before -rc1?

I'll pull this in directly to fixes today.

Dave.

> Thanks,
> Thomas
>
>
> On 4/9/20 6:49 PM, Thomas Hellström (VMware) wrote:
> > From: "Thomas Hellstrom (VMware)" 
> >
> > With amdgpu and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y, there are
> > errors like:
> > BUG: non-zero pgtables_bytes on freeing mm
> > and:
> > BUG: Bad rss-counter state
> > with TTM transparent huge-pages.
> > Until we've figured out what other TTM drivers do differently compared to
> > vmwgfx, disable the huge_fault() callback, eliminating transhuge
> > page-table entries.
> >
> > Cc: Christian König 
> > Signed-off-by: Thomas Hellstrom (VMware) 
> > Reported-by: Alex Xu (Hello71) 
> > Tested-by: Alex Xu (Hello71) 
> > Acked-by: Christian König 
> > ---
> >   drivers/gpu/drm/ttm/ttm_bo_vm.c | 63 -
> >   1 file changed, 63 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c 
> > b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > index 6ee3b96f0d13..0ad30b112982 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > @@ -442,66 +442,6 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
> >   }
> >   EXPORT_SYMBOL(ttm_bo_vm_fault);
> >
> > -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > -/**
> > - * ttm_pgprot_is_wrprotecting - Is a page protection value 
> > write-protecting?
> > - * @prot: The page protection value
> > - *
> > - * Return: true if @prot is write-protecting. false otherwise.
> > - */
> > -static bool ttm_pgprot_is_wrprotecting(pgprot_t prot)
> > -{
> > - /*
> > -  * This is meant to say "pgprot_wrprotect(prot) == prot" in a generic
> > -  * way. Unfortunately there is no generic pgprot_wrprotect.
> > -  */
> > - return pte_val(pte_wrprotect(__pte(pgprot_val(prot ==
> > - pgprot_val(prot);
> > -}
> > -
> > -static vm_fault_t ttm_bo_vm_huge_fault(struct vm_fault *vmf,
> > -enum page_entry_size pe_size)
> > -{
> > - struct vm_area_struct *vma = vmf->vma;
> > - pgprot_t prot;
> > - struct ttm_buffer_object *bo = vma->vm_private_data;
> > - vm_fault_t ret;
> > - pgoff_t fault_page_size = 0;
> > - bool write = vmf->flags & FAULT_FLAG_WRITE;
> > -
> > - switch (pe_size) {
> > - case PE_SIZE_PMD:
> > - fault_page_size = HPAGE_PMD_SIZE >> PAGE_SHIFT;
> > - break;
> > -#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> > - case PE_SIZE_PUD:
> > - fault_page_size = HPAGE_PUD_SIZE >> PAGE_SHIFT;
> > - break;
> > -#endif
> > - default:
> > - WARN_ON_ONCE(1);
> > - return VM_FAULT_FALLBACK;
> > - }
> > -
> > - /* Fallback on write dirty-tracking or COW */
> > - if (write && ttm_pgprot_is_wrprotecting(vma->vm_page_prot))
> > - return VM_FAULT_FALLBACK;
> > -
> > - ret = ttm_bo_vm_reserve(bo, vmf);
> > - if (ret)
> > - return ret;
> > -
> > - prot = vm_get_page_prot(vma->vm_flags);
> > - ret = ttm_bo_vm_fault_reserved(vmf, prot, 1, fault_page_size);
> > - if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
> > - return ret;
> > -
> > - dma_resv_unlock(bo->base.resv);
> > -
> > - return ret;
> > -}
> > -#endif
> > -
> >   void ttm_bo_vm_open(struct vm_area_struct *vma)
> >   {
> >   struct ttm_buffer_object *bo = vma->vm_private_data;
> > @@ -604,9 +544,6 @@ static const struct vm_operations_struct ttm_bo_vm_ops 
> > = {
> >   .open = ttm_bo_vm_open,
> >   .close = ttm_bo_vm_close,
> >   .access = ttm_bo_vm_access,
> > -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > - .huge_fault = ttm_bo_vm_huge_fault,
> > -#endif
> >   };
> >
> >   static struct ttm_buffer_object *ttm_bo_vm_lookup(struct ttm_bo_device 
> > *bdev,
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 15/17] drm/gma500: Stop using mode->private_flags

[Ville Syrjälä]

On Thu, Apr 09, 2020 at 10:49:52PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 07, 2020 at 09:35:37PM +0200, Sam Ravnborg wrote:
> > On Tue, Apr 07, 2020 at 10:08:00PM +0300, Ville Syrjälä wrote:
> > > On Tue, Apr 07, 2020 at 08:56:53PM +0200, Sam Ravnborg wrote:
> > > > Hi Ville.
> > > > 
> > > > On Fri, Apr 03, 2020 at 11:40:06PM +0300, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä 
> > > > > 
> > > > > gma500 only uses mode->private_flags to convey the sdvo pixel
> > > > > multiplier from the encoder .mode_fixup() hook to the encoder
> > > > > .mode_set() hook. Those always seems get called as a pair so
> > > > > let's just stuff the pixel multiplier into the encoder itself
> > > > > as there are no state objects we could use in this non-atomic
> > > > > driver.
> > > > > 
> > > > > Paves the way for nuking mode->private_flag.
> > > > Nice little clean-up. One comment below.
> > > > 
> > > > Sam
> > > > > 
> > > > > Cc: Patrik Jakobsson 
> > > > > CC: Sam Ravnborg 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: Emil Velikov 
> > > > > Signed-off-by: Ville Syrjälä 
> > > > > ---
> > > > >  drivers/gpu/drm/gma500/psb_intel_drv.h  | 19 ---
> > > > >  drivers/gpu/drm/gma500/psb_intel_sdvo.c | 11 ++-
> > > > >  2 files changed, 6 insertions(+), 24 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h 
> > > > > b/drivers/gpu/drm/gma500/psb_intel_drv.h
> > > > > index fb601983cef0..3dd5718c3e31 100644
> > > > > --- a/drivers/gpu/drm/gma500/psb_intel_drv.h
> > > > > +++ b/drivers/gpu/drm/gma500/psb_intel_drv.h
> > > > > @@ -56,25 +56,6 @@
> > > > >  #define INTEL_OUTPUT_DISPLAYPORT 9
> > > > >  #define INTEL_OUTPUT_EDP 10
> > > > >  
> > > > > -#define INTEL_MODE_PIXEL_MULTIPLIER_SHIFT (0x0)
> > > > > -#define INTEL_MODE_PIXEL_MULTIPLIER_MASK (0xf << 
> > > > > INTEL_MODE_PIXEL_MULTIPLIER_SHIFT)
> > > > > -
> > > > > -static inline void
> > > > > -psb_intel_mode_set_pixel_multiplier(struct drm_display_mode *mode,
> > > > > - int multiplier)
> > > > > -{
> > > > > - mode->clock *= multiplier;
> > > > > - mode->private_flags |= multiplier;
> > > > > -}
> > > > > -
> > > > > -static inline int
> > > > > -psb_intel_mode_get_pixel_multiplier(const struct drm_display_mode 
> > > > > *mode)
> > > > > -{
> > > > > - return (mode->private_flags & INTEL_MODE_PIXEL_MULTIPLIER_MASK)
> > > > > ->> INTEL_MODE_PIXEL_MULTIPLIER_SHIFT;
> > > > > -}
> > > > > -
> > > > > -
> > > > >  /*
> > > > >   * Hold information useally put on the device driver privates here,
> > > > >   * since it needs to be shared across multiple of devices drivers 
> > > > > privates.
> > > > > diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c 
> > > > > b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> > > > > index 264d7ad004b4..9e88a37f55e9 100644
> > > > > --- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> > > > > +++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> > > > > @@ -132,6 +132,8 @@ struct psb_intel_sdvo {
> > > > >   /* DDC bus used by this SDVO encoder */
> > > > >   uint8_t ddc_bus;
> > > > >  
> > > > > + u8 pixel_multiplier;
> > > > > +
> > > > 
> > > > There is really no good reason to use an u8 here.
> > > 
> > > Wastes less space.
> > 
> > When there is a good reason - use the size limited variants.
> > But in this use case there is no reason to space optimize it.
> 
> IMO when it's stuffed into a structure there's no reason not to
> optimize it. At some point it all starts to add up.
> 
> At least i915 suffers a lot from bloated structures (dev_priv
> and atomic state structs being the prime examples) where we
> could probably shave dozens if not hundreds of bytes if
> everything just used the smallest type possible. In fact
> this series does shave dozens of bytes from the crtc state
> alone.

Make that hundreds of bytes actually. I think we have three or more
copies of drm_display_mode embedded in there and this series shrinks
each one by 80 bytes (iirc).

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

Re: [PATCH v2 15/17] drm/gma500: Stop using mode->private_flags

[Ville Syrjälä]

On Tue, Apr 07, 2020 at 09:35:37PM +0200, Sam Ravnborg wrote:
> On Tue, Apr 07, 2020 at 10:08:00PM +0300, Ville Syrjälä wrote:
> > On Tue, Apr 07, 2020 at 08:56:53PM +0200, Sam Ravnborg wrote:
> > > Hi Ville.
> > > 
> > > On Fri, Apr 03, 2020 at 11:40:06PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > gma500 only uses mode->private_flags to convey the sdvo pixel
> > > > multiplier from the encoder .mode_fixup() hook to the encoder
> > > > .mode_set() hook. Those always seems get called as a pair so
> > > > let's just stuff the pixel multiplier into the encoder itself
> > > > as there are no state objects we could use in this non-atomic
> > > > driver.
> > > > 
> > > > Paves the way for nuking mode->private_flag.
> > > Nice little clean-up. One comment below.
> > > 
> > >   Sam
> > > > 
> > > > Cc: Patrik Jakobsson 
> > > > CC: Sam Ravnborg 
> > > > Cc: Daniel Vetter 
> > > > Cc: Emil Velikov 
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/gma500/psb_intel_drv.h  | 19 ---
> > > >  drivers/gpu/drm/gma500/psb_intel_sdvo.c | 11 ++-
> > > >  2 files changed, 6 insertions(+), 24 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h 
> > > > b/drivers/gpu/drm/gma500/psb_intel_drv.h
> > > > index fb601983cef0..3dd5718c3e31 100644
> > > > --- a/drivers/gpu/drm/gma500/psb_intel_drv.h
> > > > +++ b/drivers/gpu/drm/gma500/psb_intel_drv.h
> > > > @@ -56,25 +56,6 @@
> > > >  #define INTEL_OUTPUT_DISPLAYPORT 9
> > > >  #define INTEL_OUTPUT_EDP 10
> > > >  
> > > > -#define INTEL_MODE_PIXEL_MULTIPLIER_SHIFT (0x0)
> > > > -#define INTEL_MODE_PIXEL_MULTIPLIER_MASK (0xf << 
> > > > INTEL_MODE_PIXEL_MULTIPLIER_SHIFT)
> > > > -
> > > > -static inline void
> > > > -psb_intel_mode_set_pixel_multiplier(struct drm_display_mode *mode,
> > > > -   int multiplier)
> > > > -{
> > > > -   mode->clock *= multiplier;
> > > > -   mode->private_flags |= multiplier;
> > > > -}
> > > > -
> > > > -static inline int
> > > > -psb_intel_mode_get_pixel_multiplier(const struct drm_display_mode 
> > > > *mode)
> > > > -{
> > > > -   return (mode->private_flags & INTEL_MODE_PIXEL_MULTIPLIER_MASK)
> > > > -  >> INTEL_MODE_PIXEL_MULTIPLIER_SHIFT;
> > > > -}
> > > > -
> > > > -
> > > >  /*
> > > >   * Hold information useally put on the device driver privates here,
> > > >   * since it needs to be shared across multiple of devices drivers 
> > > > privates.
> > > > diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c 
> > > > b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> > > > index 264d7ad004b4..9e88a37f55e9 100644
> > > > --- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> > > > +++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> > > > @@ -132,6 +132,8 @@ struct psb_intel_sdvo {
> > > > /* DDC bus used by this SDVO encoder */
> > > > uint8_t ddc_bus;
> > > >  
> > > > +   u8 pixel_multiplier;
> > > > +
> > > 
> > > There is really no good reason to use an u8 here.
> > 
> > Wastes less space.
> 
> When there is a good reason - use the size limited variants.
> But in this use case there is no reason to space optimize it.

IMO when it's stuffed into a structure there's no reason not to
optimize it. At some point it all starts to add up.

At least i915 suffers a lot from bloated structures (dev_priv
and atomic state structs being the prime examples) where we
could probably shave dozens if not hundreds of bytes if
everything just used the smallest type possible. In fact
this series does shave dozens of bytes from the crtc state
alone.

> 
> When in the slightly pedantic mode, using u8 is not consistent.
> ddc_bus defined above usese uint8_t.

u8 & co. are preferred in kernel code. Checkpatch even complains when
you use the stdint types. The uint8_t here is some old leftovers.

> 
>   Sam
> > 
> > > psb_intel_sdvo_get_pixel_multiplier() return an int, so use an int here
> > > too.
> > > 
> > > With this fixed:
> > > Reviewed-by: Sam Ravnborg 
> > > 
> > > > /* Input timings for adjusted_mode */
> > > > struct psb_intel_sdvo_dtd input_dtd;
> > > >  
> > > > @@ -958,7 +960,6 @@ static bool psb_intel_sdvo_mode_fixup(struct 
> > > > drm_encoder *encoder,
> > > >   struct drm_display_mode 
> > > > *adjusted_mode)
> > > >  {
> > > > struct psb_intel_sdvo *psb_intel_sdvo = 
> > > > to_psb_intel_sdvo(encoder);
> > > > -   int multiplier;
> > > >  
> > > > /* We need to construct preferred input timings based on our
> > > >  * output timings.  To do that, we have to set the output
> > > > @@ -985,8 +986,9 @@ static bool psb_intel_sdvo_mode_fixup(struct 
> > > > drm_encoder *encoder,
> > > > /* Make the CRTC code factor in the SDVO pixel multiplier.  The
> > > >  * SDVO device will factor out the multiplier during mode_set.
> > > >  */
> > > > -   multiplier = psb_intel_sdvo_get_pixel_multipli

Re: [PATCH] drm/i915: remove redundant assignment to variable err

[Chris Wilson]

Quoting Colin King (2020-04-09 14:31:07)
> From: Colin Ian King 
> 
> The variable err is being initialized with a value that is never read
> and it is being updated later with a new value.  The initialization is
> redundant and can be removed.
> 
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King 

Could be useful... No, let's not look at that function again.
Reviewed-by: Chris Wilson 
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] dt-bindings: display: ltk500hd1829: Remove the reg property

[Sam Ravnborg]

Hi Rob.

On Thu, Apr 09, 2020 at 10:04:13AM -0600, Rob Herring wrote:
> On Sat, Mar 28, 2020 at 2:30 PM Sam Ravnborg  wrote:
> >
> > On Sat, Mar 28, 2020 at 03:36:40PM -0300, Fabio Estevam wrote:
> > > Commit 52120e8c7ae3 ("dt-bindings: display: fix panel warnings") removed
> > > the dsi unit name, but missed to remove the 'reg' property, which causes
> > > the following 'make dt_binding_check' warning:
> > >
> > > Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.example.dts:17.5-29.11:
> > >  Warning (unit_address_vs_reg): /example-0/dsi: node has a reg or ranges 
> > > property, but no unit name
> > >
> > > Fix it by removing the unneeded 'reg' property.
> > >
> > > Fixes: 52120e8c7ae3 ("dt-bindings: display: fix panel warnings")
> > > Signed-off-by: Fabio Estevam 
> >
> > Thanks, applied to drm-misc-next.
> 
> This should go in fixes for 5.7 as well as the one for xinpeng,xpp055c272.
Will take care later this week or start next week.
Ping me if you continue to see panel releated warnings in late -rc1.

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

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

[Minchan Kim]

On Thu, Apr 09, 2020 at 06:50:30PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 09, 2020 at 09:08:26AM -0700, Minchan Kim wrote:
> > On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote:
> > > This allows to unexport map_vm_area and unmap_kernel_range, which are
> > > rather deep internal and should not be available to modules.
> > 
> > Even though I don't know how many usecase we have using zsmalloc as
> > module(I heard only once by dumb reason), it could affect existing
> > users. Thus, please include concrete explanation in the patch to
> > justify when the complain occurs.
> 
> The justification is 'we can unexport functions that have no sane reason
> of being exported in the first place'.
> 
> The Changelog pretty much says that.

Okay, I hope there is no affected user since this patch.
If there are someone, they need to provide sane reason why they want
to have zsmalloc as module.

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

Re: [PATCH] drm/ttm: Temporarily disable the huge_fault() callback

[VMware]

Dave, Christian,

Could any of you pick this up (I'm currently on vacation) to have a 
chance of getting it in before -rc1?

Thanks,
Thomas


On 4/9/20 6:49 PM, Thomas Hellström (VMware) wrote:

From: "Thomas Hellstrom (VMware)" 

With amdgpu and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y, there are
errors like:
BUG: non-zero pgtables_bytes on freeing mm
and:
BUG: Bad rss-counter state
with TTM transparent huge-pages.
Until we've figured out what other TTM drivers do differently compared to
vmwgfx, disable the huge_fault() callback, eliminating transhuge
page-table entries.

Cc: Christian König 
Signed-off-by: Thomas Hellstrom (VMware) 
Reported-by: Alex Xu (Hello71) 
Tested-by: Alex Xu (Hello71) 
Acked-by: Christian König 
---
  drivers/gpu/drm/ttm/ttm_bo_vm.c | 63 -
  1 file changed, 63 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 6ee3b96f0d13..0ad30b112982 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -442,66 +442,6 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
  }
  EXPORT_SYMBOL(ttm_bo_vm_fault);
  
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE

-/**
- * ttm_pgprot_is_wrprotecting - Is a page protection value write-protecting?
- * @prot: The page protection value
- *
- * Return: true if @prot is write-protecting. false otherwise.
- */
-static bool ttm_pgprot_is_wrprotecting(pgprot_t prot)
-{
-   /*
-* This is meant to say "pgprot_wrprotect(prot) == prot" in a generic
-* way. Unfortunately there is no generic pgprot_wrprotect.
-*/
-   return pte_val(pte_wrprotect(__pte(pgprot_val(prot ==
-   pgprot_val(prot);
-}
-
-static vm_fault_t ttm_bo_vm_huge_fault(struct vm_fault *vmf,
-  enum page_entry_size pe_size)
-{
-   struct vm_area_struct *vma = vmf->vma;
-   pgprot_t prot;
-   struct ttm_buffer_object *bo = vma->vm_private_data;
-   vm_fault_t ret;
-   pgoff_t fault_page_size = 0;
-   bool write = vmf->flags & FAULT_FLAG_WRITE;
-
-   switch (pe_size) {
-   case PE_SIZE_PMD:
-   fault_page_size = HPAGE_PMD_SIZE >> PAGE_SHIFT;
-   break;
-#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
-   case PE_SIZE_PUD:
-   fault_page_size = HPAGE_PUD_SIZE >> PAGE_SHIFT;
-   break;
-#endif
-   default:
-   WARN_ON_ONCE(1);
-   return VM_FAULT_FALLBACK;
-   }
-
-   /* Fallback on write dirty-tracking or COW */
-   if (write && ttm_pgprot_is_wrprotecting(vma->vm_page_prot))
-   return VM_FAULT_FALLBACK;
-
-   ret = ttm_bo_vm_reserve(bo, vmf);
-   if (ret)
-   return ret;
-
-   prot = vm_get_page_prot(vma->vm_flags);
-   ret = ttm_bo_vm_fault_reserved(vmf, prot, 1, fault_page_size);
-   if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
-   return ret;
-
-   dma_resv_unlock(bo->base.resv);
-
-   return ret;
-}
-#endif
-
  void ttm_bo_vm_open(struct vm_area_struct *vma)
  {
struct ttm_buffer_object *bo = vma->vm_private_data;
@@ -604,9 +544,6 @@ static const struct vm_operations_struct ttm_bo_vm_ops = {
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
.access = ttm_bo_vm_access,
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   .huge_fault = ttm_bo_vm_huge_fault,
-#endif
  };
  
  static struct ttm_buffer_object *ttm_bo_vm_lookup(struct ttm_bo_device *bdev,



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

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

[Peter Zijlstra]

On Thu, Apr 09, 2020 at 09:08:26AM -0700, Minchan Kim wrote:
> On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote:
> > This allows to unexport map_vm_area and unmap_kernel_range, which are
> > rather deep internal and should not be available to modules.
> 
> Even though I don't know how many usecase we have using zsmalloc as
> module(I heard only once by dumb reason), it could affect existing
> users. Thus, please include concrete explanation in the patch to
> justify when the complain occurs.

The justification is 'we can unexport functions that have no sane reason
of being exported in the first place'.

The Changelog pretty much says that.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/ttm: Temporarily disable the huge_fault() callback

[VMware]

From: "Thomas Hellstrom (VMware)" 

With amdgpu and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y, there are
errors like:
BUG: non-zero pgtables_bytes on freeing mm
and:
BUG: Bad rss-counter state
with TTM transparent huge-pages.
Until we've figured out what other TTM drivers do differently compared to
vmwgfx, disable the huge_fault() callback, eliminating transhuge
page-table entries.

Cc: Christian König 
Signed-off-by: Thomas Hellstrom (VMware) 
Reported-by: Alex Xu (Hello71) 
Tested-by: Alex Xu (Hello71) 
Acked-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c | 63 -
 1 file changed, 63 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 6ee3b96f0d13..0ad30b112982 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -442,66 +442,6 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
 }
 EXPORT_SYMBOL(ttm_bo_vm_fault);
 
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-/**
- * ttm_pgprot_is_wrprotecting - Is a page protection value write-protecting?
- * @prot: The page protection value
- *
- * Return: true if @prot is write-protecting. false otherwise.
- */
-static bool ttm_pgprot_is_wrprotecting(pgprot_t prot)
-{
-   /*
-* This is meant to say "pgprot_wrprotect(prot) == prot" in a generic
-* way. Unfortunately there is no generic pgprot_wrprotect.
-*/
-   return pte_val(pte_wrprotect(__pte(pgprot_val(prot ==
-   pgprot_val(prot);
-}
-
-static vm_fault_t ttm_bo_vm_huge_fault(struct vm_fault *vmf,
-  enum page_entry_size pe_size)
-{
-   struct vm_area_struct *vma = vmf->vma;
-   pgprot_t prot;
-   struct ttm_buffer_object *bo = vma->vm_private_data;
-   vm_fault_t ret;
-   pgoff_t fault_page_size = 0;
-   bool write = vmf->flags & FAULT_FLAG_WRITE;
-
-   switch (pe_size) {
-   case PE_SIZE_PMD:
-   fault_page_size = HPAGE_PMD_SIZE >> PAGE_SHIFT;
-   break;
-#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
-   case PE_SIZE_PUD:
-   fault_page_size = HPAGE_PUD_SIZE >> PAGE_SHIFT;
-   break;
-#endif
-   default:
-   WARN_ON_ONCE(1);
-   return VM_FAULT_FALLBACK;
-   }
-
-   /* Fallback on write dirty-tracking or COW */
-   if (write && ttm_pgprot_is_wrprotecting(vma->vm_page_prot))
-   return VM_FAULT_FALLBACK;
-
-   ret = ttm_bo_vm_reserve(bo, vmf);
-   if (ret)
-   return ret;
-
-   prot = vm_get_page_prot(vma->vm_flags);
-   ret = ttm_bo_vm_fault_reserved(vmf, prot, 1, fault_page_size);
-   if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
-   return ret;
-
-   dma_resv_unlock(bo->base.resv);
-
-   return ret;
-}
-#endif
-
 void ttm_bo_vm_open(struct vm_area_struct *vma)
 {
struct ttm_buffer_object *bo = vma->vm_private_data;
@@ -604,9 +544,6 @@ static const struct vm_operations_struct ttm_bo_vm_ops = {
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
.access = ttm_bo_vm_access,
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   .huge_fault = ttm_bo_vm_huge_fault,
-#endif
 };
 
 static struct ttm_buffer_object *ttm_bo_vm_lookup(struct ttm_bo_device *bdev,
-- 
2.21.1

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

Re: [PATCH v2 01/36] dt-bindings: display: allow port and ports in panel-lvds

[Rob Herring]

On Wed, Apr 8, 2020 at 1:51 PM Sam Ravnborg  wrote:
>
> Both port and ports names may be used.
> port - for a single port
> ports - if there is more than one port in sub-nodes
>
> Fixes the following warning:
> advantech,idk-2121wr.example.dt.yaml: panel-lvds: 'port' is a required 
> property
>
> advantech,idk-2121wr.yaml needs several ports, so uses a ports node.
>
> Signed-off-by: Sam Ravnborg 
> Cc: Fabrizio Castro 
> Cc: Lad Prabhakar 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  Documentation/devicetree/bindings/display/panel/lvds.yaml | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)


>
> diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
> b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> index d0083301acbe..f9132d50821c 100644
> --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> @@ -102,6 +102,12 @@ required:
>- width-mm
>- height-mm
>- panel-timing
> -  - port
> +
> +if:
> +  required:
> +- port
> +else:
> +  required:
> +- ports

Humm, I guess 'then' is not required. That's a bit weird IMO.

I usually do a 'oneOf' for these cases.

Either way, please apply this to drm-misc-fixes (or
drm-misc-next-fixes depending on the state of the tree). Or I can take
it. I'd like to get all the warnings cleared up by rc2.

Reviewed-by: Rob Herring 

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

Re: [PATCH v2] drm: mediatek: fix device passed to cmdq

[Chun-Kuang Hu]

Hi, Hsin-Yi:

Hsin-Yi Wang  於 2020年4月9日 週四 下午2:02寫道：
>
> drm device is now probed from mmsys. We need to use mmsys device to get gce
> nodes. Fix following errors:
>
> [0.740068] mediatek-drm mediatek-drm.1.auto: error -2 can't parse 
> gce-client-reg property (0)
> [0.748721] mediatek-drm mediatek-drm.1.auto: error -2 can't parse 
> gce-client-reg property (0)
> ...
> [2.659645] mediatek-drm mediatek-drm.1.auto: failed to request channel
> [2.666270] mediatek-drm mediatek-drm.1.auto: failed to request channel

Reviewed-by: Chun-Kuang Hu 

>
> Fixes: 1d367541aded ("soc / drm: mediatek: Fix mediatek-drm device probing")
> Signed-off-by: Hsin-Yi Wang 
> Reviewed-by: Enric Balletbo i Serra 
> Tested-by: Enric Balletbo i Serra 
> ---
> The patch is based on
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git
> branch v5.6-next/soc
>
> Change log:
> v1->v2:
> align with 60fa8c13ab1a ("drm/mediatek: Move gce event property to mutex 
> device node")
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 ++-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 615a54e60fe2..7247c6f87f4a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -822,7 +822,8 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
>
>  #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> mtk_crtc->cmdq_client =
> -   cmdq_mbox_create(dev, drm_crtc_index(&mtk_crtc->base),
> +   cmdq_mbox_create(mtk_crtc->mmsys_dev,
> +drm_crtc_index(&mtk_crtc->base),
>  2000);
> if (IS_ERR(mtk_crtc->cmdq_client)) {
> dev_dbg(dev, "mtk_crtc %d failed to create mailbox client, 
> writing register by CPU now\n",
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index e2bb0d19ef99..28418e5b83ee 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -517,7 +517,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
> goto err_node;
> }
>
> -   ret = mtk_ddp_comp_init(dev, node, comp, comp_id, 
> NULL);
> +   ret = mtk_ddp_comp_init(dev->parent, node, comp, 
> comp_id, NULL);
> if (ret) {
> of_node_put(node);
> goto err_node;
> --
> 2.26.0.292.g33ef6b2f38-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

[Minchan Kim]

On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote:
> This allows to unexport map_vm_area and unmap_kernel_range, which are
> rather deep internal and should not be available to modules.

Even though I don't know how many usecase we have using zsmalloc as
module(I heard only once by dumb reason), it could affect existing
users. Thus, please include concrete explanation in the patch to
justify when the complain occurs.

> 
> Signed-off-by: Christoph Hellwig 
> ---
>  mm/Kconfig   | 2 +-
>  mm/vmalloc.c | 2 --
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 36949a9425b8..614cc786b519 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -702,7 +702,7 @@ config ZSMALLOC
>  
>  config ZSMALLOC_PGTABLE_MAPPING
>   bool "Use page table mapping to access object in zsmalloc"
> - depends on ZSMALLOC
> + depends on ZSMALLOC=y
>   help
> By default, zsmalloc uses a copy-based object mapping method to
> access allocations that span two pages. However, if a particular
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 3375f9508ef6..9183fc0d365a 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2046,7 +2046,6 @@ void unmap_kernel_range(unsigned long addr, unsigned 
> long size)
>   vunmap_page_range(addr, end);
>   flush_tlb_kernel_range(addr, end);
>  }
> -EXPORT_SYMBOL_GPL(unmap_kernel_range);
>  
>  int map_vm_area(struct vm_struct *area, pgprot_t prot, struct page **pages)
>  {
> @@ -2058,7 +2057,6 @@ int map_vm_area(struct vm_struct *area, pgprot_t prot, 
> struct page **pages)
>  
>   return err > 0 ? 0 : err;
>  }
> -EXPORT_SYMBOL_GPL(map_vm_area);
>  
>  static inline void setup_vmalloc_vm_locked(struct vm_struct *vm,
>   struct vmap_area *va, unsigned long flags, const void *caller)
> -- 
> 2.25.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] dt-bindings: display: ltk500hd1829: Remove the reg property

[Rob Herring]

On Sat, Mar 28, 2020 at 2:30 PM Sam Ravnborg  wrote:
>
> On Sat, Mar 28, 2020 at 03:36:40PM -0300, Fabio Estevam wrote:
> > Commit 52120e8c7ae3 ("dt-bindings: display: fix panel warnings") removed
> > the dsi unit name, but missed to remove the 'reg' property, which causes
> > the following 'make dt_binding_check' warning:
> >
> > Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.example.dts:17.5-29.11:
> >  Warning (unit_address_vs_reg): /example-0/dsi: node has a reg or ranges 
> > property, but no unit name
> >
> > Fix it by removing the unneeded 'reg' property.
> >
> > Fixes: 52120e8c7ae3 ("dt-bindings: display: fix panel warnings")
> > Signed-off-by: Fabio Estevam 
>
> Thanks, applied to drm-misc-next.

This should go in fixes for 5.7 as well as the one for xinpeng,xpp055c272.

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

Re: [PATCH 09/28] mm: rename CONFIG_PGTABLE_MAPPING to CONFIG_ZSMALLOC_PGTABLE_MAPPING

[Minchan Kim]

On Wed, Apr 08, 2020 at 01:59:07PM +0200, Christoph Hellwig wrote:
> Rename the Kconfig variable to clarify the scope.
> 
> Signed-off-by: Christoph Hellwig 
Acked-by: Minchan Kim 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/28] x86/hyperv: use vmalloc_exec for the hypercall page

[Wei Liu]

On Wed, Apr 08, 2020 at 01:58:59PM +0200, Christoph Hellwig wrote:
> Use the designated helper for allocating executable kernel memory, and
> remove the now unused PAGE_KERNEL_RX define.
> 
> Signed-off-by: Christoph Hellwig 

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

[Bug 207171] [regression][bisected] Ryzen PRO 2400G, firefox screen corruption in X

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=207171

--- Comment #2 from Florian Ziegler (florian.zieg...@posteo.de) ---
> Does this patch fix it?
Yes, the patch fixes the issue. Thank you.

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

[PATCH 1/2] drm/i915: remove unneeded ccflags-y from gvt/Makefile

[Masahiro Yamada]

When CONFIG_DRM_I915_GVT=y, the same include path is added twice.

drivers/gpu/drm/i915/Makefile specifies:

  subdir-ccflags-y += -I$(srctree)/$(src)

drivers/gpu/drm/i915/gvt/Makefile adds the second '-I $(srctree)/$(src)',
which is redundant.

The include path '-I $(srctree)/$(src)/$(GVT_DIR)/' is added to allow
include/trace/define_trace.h to find the gvt/trace.h

By setting the correct relative path to TRACE_INCLUDE_PATH, this -I
is also unneeded.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpu/drm/i915/gvt/Makefile | 1 -
 drivers/gpu/drm/i915/gvt/trace.h  | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
index ea8324abc784..4d70f4689479 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -5,5 +5,4 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
trace_points.o firmware.o \
execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o 
debugfs.o \
fb_decoder.o dmabuf.o page_track.o
 
-ccflags-y  += -I $(srctree)/$(src) -I 
$(srctree)/$(src)/$(GVT_DIR)/
 i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/trace.h b/drivers/gpu/drm/i915/gvt/trace.h
index 6d787750d279..d63b7eef6179 100644
--- a/drivers/gpu/drm/i915/gvt/trace.h
+++ b/drivers/gpu/drm/i915/gvt/trace.h
@@ -377,7 +377,7 @@ TRACE_EVENT(render_mmio,
 
 /* This part must be out of protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/i915/gvt
 #undef TRACE_INCLUDE_FILE
 #define TRACE_INCLUDE_FILE trace
 #include 
-- 
2.17.1

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

[PATCH 2/2] drm/i915: remove gvt/Makefile

[Masahiro Yamada]

Including subdirectory Makefile from the driver main Makefile does not
buy us much because this is not real isolation.

Having a single Makefile at the top of the module is clearer, and
it is what this driver almost does.

Move all gvt objects to the i915 main Makefile.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpu/drm/i915/Makefile | 28 
 drivers/gpu/drm/i915/gvt/Makefile |  8 
 2 files changed, 24 insertions(+), 12 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/gvt/Makefile

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6cd1f6253814..74e965882a98 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -275,10 +275,30 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
 # virtual gpu code
 i915-y += i915_vgpu.o
 
-ifeq ($(CONFIG_DRM_I915_GVT),y)
-i915-y += intel_gvt.o
-include $(src)/gvt/Makefile
-endif
+i915-$(CONFIG_DRM_I915_GVT) += \
+   intel_gvt.o \
+   gvt/gvt.o \
+   gvt/aperture_gm.o \
+   gvt/handlers.o \
+   gvt/vgpu.o \
+   gvt/trace_points.o \
+   gvt/firmware.o \
+   gvt/interrupt.o \
+   gvt/gtt.o \
+   gvt/cfg_space.o \
+   gvt/opregion.o \
+   gvt/mmio.o \
+   gvt/display.o \
+   gvt/edid.o \
+   gvt/execlist.o \
+   gvt/scheduler.o \
+   gvt/sched_policy.o \
+   gvt/mmio_context.o \
+   gvt/cmd_parser.o \
+   gvt/debugfs.o \
+   gvt/fb_decoder.o \
+   gvt/dmabuf.o \
+   gvt/page_track.o
 
 obj-$(CONFIG_DRM_I915) += i915.o
 obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
deleted file mode 100644
index 4d70f4689479..
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ /dev/null
@@ -1,8 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-GVT_DIR := gvt
-GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
-   interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
-   execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o 
debugfs.o \
-   fb_decoder.o dmabuf.o page_track.o
-
-i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
-- 
2.17.1

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

Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete worker

[Christian König]

Why we break out the loops when there are pending bos to be released?


We do this anyway if we can't acquire the necessary locks. Freeing 
already deleted BOs is just a very lazy background work.



So it did not break anything with this patch I think.


Oh, the patch will certainly work. I'm just not sure if it's the ideal 
behavior.



https://elixir.bootlin.com/linux/latest/source/mm/slab.c#L4026

This is another example of the usage of  cond_sched.


Yes, and that is also a good example of what I mean here:

	if  (!mutex_trylock 
(&slab_mutex 
))

/* Give up. Setup the next iteration. */
goto  out;


If the function can't acquire the lock immediately it gives up and waits 
for the next iteration.


I think it would be better if we do this in TTM as well if we spend to 
much time cleaning up old BOs.


On the other hand you are right that cond_resched() has the advantage 
that we could spend more time on cleaning up old BOs if there is nothing 
else for the CPU TODO.


Regards,
Christian.

Am 09.04.20 um 16:24 schrieb Pan, Xinhui:

https://elixir.bootlin.com/linux/latest/source/mm/slab.c#L4026

This is another example of the usage of  cond_sched.

*From:* Pan, Xinhui 
*Sent:* Thursday, April 9, 2020 10:11:08 PM
*To:* Lucas Stach ; 
amd-...@lists.freedesktop.org ; Koenig, 
Christian 

*Cc:* dri-devel@lists.freedesktop.org 
*Subject:* Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed 
delete worker
I think it doesn't matter if workitem schedule out. Even we did not 
schedule out, the workqueue itself will schedule out later.

So it did not break anything with this patch I think.

*From:* Pan, Xinhui 
*Sent:* Thursday, April 9, 2020 10:07:09 PM
*To:* Lucas Stach ; 
amd-...@lists.freedesktop.org ; Koenig, 
Christian 

*Cc:* dri-devel@lists.freedesktop.org 
*Subject:* Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed 
delete worker

Why we break out the loops when there are pending bos to be released?

And I just checked the process_one_work. Right after the work item 
callback is called,  the workqueue itself will call cond_resched. So I 
think


*From:* Koenig, Christian 
*Sent:* Thursday, April 9, 2020 9:38:24 PM
*To:* Lucas Stach ; Pan, Xinhui 
; amd-...@lists.freedesktop.org 


*Cc:* dri-devel@lists.freedesktop.org 
*Subject:* Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed 
delete worker

Am 09.04.20 um 15:25 schrieb Lucas Stach:
> Am Donnerstag, den 09.04.2020, 14:35 +0200 schrieb Christian König:
>> Am 09.04.20 um 03:31 schrieb xinhui pan:
>>> The delayed delete list is per device which might be very huge. And in
>>> a heavy workload test, the list might always not be empty. That will
>>> trigger any RCU stall warnings or softlockups in non-preemptible 
kernels

>>> Lets do schedule out if possible in that case.
>> Mhm, I'm not sure if that is actually allowed. This is called from a
>> work item and those are not really supposed to be scheduled away.
> Huh? Workitems can schedule out just fine, otherwise they would be
> horribly broken when it comes to sleeping locks.

Let me refine the sentence: Work items are not really supposed to be
scheduled purposely. E.g. you shouldn't call schedule() or
cond_resched() like in the case here.

Getting scheduled away because we wait for a lock is of course perfectly
fine.

>   The workqueue code
> even has measures to keep the workqueues at the expected concurrency
> level by starting other workitems when one of them goes to sleep.

Yeah, and exactly that's what I would say we should avoid here :)

In other words work items can be scheduled away, but they should not if
not really necessary (e.g. waiting for a lock).

Otherwise as you said new threads for work item processing are started
up and I don't think we want that.

Just returning from the work item and waiting for the next cycle is most
likely the better option.

Regards,
Christian.

>
> Regards,
> Lucas
>
>> Maybe rather change the while into while (!list_empty(&bdev->ddestroy)
>> && !should_reschedule(0)).
>>
>> Christian.
>>
>>> Signed-off-by: xinhui pan 
>>> ---
>>>    drivers/gpu/drm/ttm/ttm_bo.c | 1 +
>>>    1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
b/drivers/gpu/drm/ttm/ttm_bo.c

>>> index 9e07c3f75156..b8d853cab33b 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -541,6 +541,7 @@ static bool ttm_bo_delayed_delete(struct 
ttm_bo_device *bdev, bool remove_all)

>>>  }
>>>
>>>  ttm_bo_put(bo);
>>> +   cond_resched();
>>> spin_lock(&glob->lru_lock);
>>>  }
>>>  list_splice_tail(&removed, &b

Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc

[Daniel Vetter]

On Thu, Apr 9, 2020 at 4:19 PM Alex Deucher  wrote:
>
> On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter  wrote:
> >
> > On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
> >  wrote:
> > >
> > > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > > > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > > > If this code was broken for non-coherent caches a crude powerpc hack
> > > > > isn't going to help anyone else.  Remove the hack as it is the last
> > > > > user of __vmalloc passing a page protection flag other than 
> > > > > PAGE_KERNEL.
> > > >
> > > > Well Ben added this to make stuff work on ppc, ofc the home grown dma
> > > > layer in drm from back then isn't going to work in other places. I guess
> > > > should have at least an ack from him, in case anyone still cares about
> > > > this on ppc. Adding Ben to cc.
> > >
> > > This was due to some drivers (radeon ?) trying to use vmalloc pages for
> > > coherent DMA, which means on those 4xx powerpc's need to be non-cached.
> > >
> > > There were machines using that (440 based iirc), though I honestly
> > > can't tell if anybody still uses any of it.
> >
> > agp subsystem still seems to happily do that (vmalloc memory for
> > device access), never having been ported to dma apis (or well
> > converted to iommu drivers, which they kinda are really). So I think
> > this all still works exactly as back then, even with the kms radeon
> > drivers. Question really is whether we have users left, and I have no
> > clue about that either.
> >
> > Now if these boxes didn't ever have agp then I think we can get away
> > with deleting this, since we've already deleted the legacy radeon
> > driver. And that one used vmalloc for everything. The new kms one does
> > use the dma-api if the gpu isn't connected through agp.
>
> All radeons have a built in remapping table to handle non-AGP systems.
> On the earlier radeons it wasn't quite as performant as AGP, but it
> was always more reliable because AGP is AGP.  Maybe it's time to let
> AGP go?

I'd be very much in favour of that, if we can just use the integrated
gart and drop agp fast writes wobbliness on the floor. I think the
only other modern driver using agp would be nouveau at that point.
-Daniel

>
> Alex
>
> > -Daniel
> >
> > > Cheers,
> > > Ben.
> > >
> > > > -Daniel
> > > >
> > > > >
> > > > > Signed-off-by: Christoph Hellwig 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_scatter.c | 11 +--
> > > > >  1 file changed, 1 insertion(+), 10 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_scatter.c 
> > > > > b/drivers/gpu/drm/drm_scatter.c
> > > > > index ca520028b2cb..f4e6184d1877 100644
> > > > > --- a/drivers/gpu/drm/drm_scatter.c
> > > > > +++ b/drivers/gpu/drm/drm_scatter.c
> > > > > @@ -43,15 +43,6 @@
> > > > >
> > > > >  #define DEBUG_SCATTER 0
> > > > >
> > > > > -static inline void *drm_vmalloc_dma(unsigned long size)
> > > > > -{
> > > > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > > > > -   return __vmalloc(size, GFP_KERNEL, 
> > > > > pgprot_noncached_wc(PAGE_KERNEL));
> > > > > -#else
> > > > > -   return vmalloc_32(size);
> > > > > -#endif
> > > > > -}
> > > > > -
> > > > >  static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > > > >  {
> > > > > struct page *page;
> > > > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, 
> > > > > void *data,
> > > > > return -ENOMEM;
> > > > > }
> > > > >
> > > > > -   entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > > > > +   entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > > > > if (!entry->virtual) {
> > > > > kfree(entry->busaddr);
> > > > > kfree(entry->pagelist);
> > > > > --
> > > > > 2.25.1
> > > > >
> > > >
> > > >
> > >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: [PATCH v1 2/3] drm/panel: update backlight handling for samsung-s6e63j0x03

[Sam Ravnborg]

Hi Emil.

Thanks for your feedback!

On Thu, Apr 09, 2020 at 03:13:28PM +0100, Emil Velikov wrote:
> On Thu, 9 Apr 2020 at 12:53, Sam Ravnborg  wrote:
> >
> > The samsung-s6e63j0x03 had a local way to handle backlight.
> >
> > Update the driver to use a devm_ based register function
> > and utilize drm_panel backlight support. The changes results
> > in a simpler driver with the same functionality.
> >
> > Signed-off-by: Sam Ravnborg 
> > Cc: Joonas Kylmälä 
> > Cc: Andrzej Hajda 
> > Cc: Thierry Reding 
> > Cc: Inki Dae 
> > Cc: Hyungwon Hwang 
> > Cc: Hoegeun Kwon 
> > ---
> >  .../gpu/drm/panel/panel-samsung-s6e63j0x03.c  | 55 ++-
> >  1 file changed, 29 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c 
> > b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
> > index a3570e0a90a8..2c035f87e3f0 100644
> > --- a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
> > +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
> > @@ -36,7 +36,6 @@
> >  struct s6e63j0x03 {
> > struct device *dev;
> > struct drm_panel panel;
> > -   struct backlight_device *bl_dev;
> >
> > struct regulator_bulk_data supplies[2];
> > struct gpio_desc *reset_gpio;
> > @@ -184,7 +183,7 @@ static unsigned int 
> > s6e63j0x03_get_brightness_index(unsigned int brightness)
> >  static int s6e63j0x03_update_gamma(struct s6e63j0x03 *ctx,
> > unsigned int brightness)
> >  {
> > -   struct backlight_device *bl_dev = ctx->bl_dev;
> > +   struct backlight_device *bl_dev = ctx->panel.backlight;
> > unsigned int index = s6e63j0x03_get_brightness_index(brightness);
> > int ret;
> >
> > @@ -217,6 +216,30 @@ static const struct backlight_ops s6e63j0x03_bl_ops = {
> > .update_status = s6e63j0x03_set_brightness,
> >  };
> >
> > +static int s6e63j0x03_backlight_register(struct s6e63j0x03 *ctx)
> > +{
> > +   struct backlight_properties props = {
> Pretty sure we can (should really) make the props const.
Thanks, will fix either in v2 or when I apply.

> 
> Quick grep through drm, shows that there're other offenders, so might
> as well do that in separate series.
> Seems like other panels could follow suite, with later series of course.
> 
> Back on topic, it's not immediately obvious why the FB_BLANK_*
> handling is safe to remove. Please add small mention in the commit log
> mentioning why.

Maybe because it is not so?
Lets take a closer look.
backlight_enable() and backlight_disable() are called from
drm_panel - because drm_panel->backlight is assigned.


drm_panel_prepare:
OLD:ctx->bl_dev->props.power = FB_BLANK_NORMAL;
NEW:

drm_panel_enable:
OLD:ctx->bl_dev->props.power = FB_BLANK_UNBLANK;
NEW:backlight_enable() => 
bd->props.power = FB_BLANK_UNBLANK;
bd->props.fb_blank = FB_BLANK_UNBLANK;
bd->props.state &= ~BL_CORE_FBBLANK;

drm_panel_disable:
OLD:ctx->bl_dev->props.power = FB_BLANK_NORMAL;
NEW:backlight_disable() =>
bd->props.power = FB_BLANK_POWERDOWN;
bd->props.fb_blank = FB_BLANK_POWERDOWN;
bd->props.state |= BL_CORE_FBBLANK;


drm_panel_unprepare:
OLD:ctx->bl_dev->props.power = FB_BLANK_POWERDOWN;
NEW:

So old and new code are not exactly the same.

But with my (limited) backlight understanding this should
work as expected - and it works for many other drivers.
So if this does not work, then we should look at the backlight
handling and not do workarounds in the driver.

I will summarize the above in the individual changelogs.

Sam


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

Re: [PATCH 3/3] drm: pl111: Move VExpress setup into versatile init

[Sam Ravnborg]

Hi Rob.

On Wed, Apr 08, 2020 at 07:39:47PM -0600, Rob Herring wrote:
> Since the VExpress setup in pl111_vexpress.c is now just a single
> function call, let's move it into pl111_versatile.c and we can further
> simplify pl111_versatile_init() by moving the other pieces for VExpress
> into pl111_vexpress_clcd_init().
> 
> Cc: Eric Anholt 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring 
Patch looks good - nits below, but anyway:

Acked-by: Sam Ravnborg 


> ---
>  drivers/gpu/drm/pl111/Makefile  |   1 -
>  drivers/gpu/drm/pl111/pl111_versatile.c | 122 
>  drivers/gpu/drm/pl111/pl111_vexpress.c  |  96 ---
>  drivers/gpu/drm/pl111/pl111_vexpress.h  |  22 -
>  4 files changed, 102 insertions(+), 139 deletions(-)
>  delete mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.c
>  delete mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.h
> 
> diff --git a/drivers/gpu/drm/pl111/Makefile b/drivers/gpu/drm/pl111/Makefile
> index 0c70f0e91d21..67d430d433e0 100644
> --- a/drivers/gpu/drm/pl111/Makefile
> +++ b/drivers/gpu/drm/pl111/Makefile
> @@ -3,7 +3,6 @@ pl111_drm-y +=pl111_display.o \
>   pl111_versatile.o \
>   pl111_drv.o
>  
> -pl111_drm-$(CONFIG_ARCH_VEXPRESS) += pl111_vexpress.o
>  pl111_drm-$(CONFIG_ARCH_NOMADIK) += pl111_nomadik.o
>  pl111_drm-$(CONFIG_DEBUG_FS) += pl111_debugfs.o
>  
> diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c 
> b/drivers/gpu/drm/pl111/pl111_versatile.c
> index 8c2551088f26..1b55f977e945 100644
> --- a/drivers/gpu/drm/pl111/pl111_versatile.c
> +++ b/drivers/gpu/drm/pl111/pl111_versatile.c
> @@ -11,7 +11,6 @@
>  #include 
>  
>  #include "pl111_versatile.h"
> -#include "pl111_vexpress.h"
>  #include "pl111_drm.h"
>  
>  static struct regmap *versatile_syscon_map;
> @@ -309,13 +308,110 @@ static const struct pl111_variant_data pl111_vexpress 
> = {
>   .broken_clockdivider = true,
>  };
>  
> +#define VEXPRESS_FPGAMUX_MOTHERBOARD 0x00
> +#define VEXPRESS_FPGAMUX_DAUGHTERBOARD_1 0x01
> +#define VEXPRESS_FPGAMUX_DAUGHTERBOARD_2 0x02
> +
> +static int pl111_vexpress_clcd_init(struct device *dev, struct device_node 
> *np,
> + struct pl111_drm_dev_private *priv)
> +{
> + struct platform_device *pdev;
> + struct device_node *root;
> + struct device_node *child;
> + struct device_node *ct_clcd = NULL;
> + struct regmap *map;
> + bool has_coretile_clcd = false;
> + bool has_coretile_hdlcd = false;
> + bool mux_motherboard = true;
> + u32 val;
> + int ret;
> +
> + if (!IS_ENABLED(CONFIG_VEXPRESS_CONFIG))
> + return -ENODEV;
Thats was a simple way to get out of this.
Maybe a WARN() was in place, because should we ever hit this?

> +
> + /*
> +  * Check if we have a CLCD or HDLCD on the core tile by checking if a
> +  * CLCD or HDLCD is available in the root of the device tree.
> +  */
> + root = of_find_node_by_path("/");
> + if (!root)
> + return -EINVAL;
> +
> + for_each_available_child_of_node(root, child) {
> + if (of_device_is_compatible(child, "arm,pl111")) {
> + has_coretile_clcd = true;
> + ct_clcd = child;
> + break;
> + }
> + if (of_device_is_compatible(child, "arm,hdlcd")) {
> + has_coretile_hdlcd = true;
> + of_node_put(child);
> + break;
> + }
> + }
> +
> + of_node_put(root);
> +
> + /*
> +  * If there is a coretile HDLCD and it has a driver,
> +  * do not mux the CLCD on the motherboard to the DVI.
> +  */
> + if (has_coretile_hdlcd && IS_ENABLED(CONFIG_DRM_HDLCD))
> + mux_motherboard = false;
> +
> + /*
> +  * On the Vexpress CA9 we let the CLCD on the coretile
> +  * take precedence, so also in this case do not mux the
> +  * motherboard to the DVI.
> +  */
> + if (has_coretile_clcd)
> + mux_motherboard = false;
> +
> + if (mux_motherboard) {
> + dev_info(dev, "DVI muxed to motherboard CLCD\n");
> + val = VEXPRESS_FPGAMUX_MOTHERBOARD;
> + } else if (ct_clcd == dev->of_node) {
> + dev_info(dev,
> +  "DVI muxed to daughterboard 1 (core tile) CLCD\n");
> + val = VEXPRESS_FPGAMUX_DAUGHTERBOARD_1;
> + } else {
> + dev_info(dev, "core tile graphics present\n");
> + dev_info(dev, "this device will be deactivated\n");
> + return -ENODEV;
> + }
> +
> + /* Call into deep Vexpress configuration API */
> + pdev = of_find_device_by_node(np);
> + if (!pdev) {
> + dev_err(dev, "can't find the sysreg device, deferring\n");
> + return -EPROBE_DEFER;
> + }
> +
> + map = devm_regmap_init_vexpress_config(&pdev->dev);
> + if (IS_ERR(map)) {
> 

Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete worker

[Pan, Xinhui]

https://elixir.bootlin.com/linux/latest/source/mm/slab.c#L4026

This is another example of the usage of  cond_sched.

From: Pan, Xinhui 
Sent: Thursday, April 9, 2020 10:11:08 PM
To: Lucas Stach ; amd-...@lists.freedesktop.org 
; Koenig, Christian 
Cc: dri-devel@lists.freedesktop.org 
Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete 
worker

I think it doesn't matter if workitem schedule out. Even we did not schedule 
out, the workqueue itself will schedule out later.
So it did not break anything with this patch I think.

From: Pan, Xinhui 
Sent: Thursday, April 9, 2020 10:07:09 PM
To: Lucas Stach ; amd-...@lists.freedesktop.org 
; Koenig, Christian 
Cc: dri-devel@lists.freedesktop.org 
Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete 
worker

Why we break out the loops when there are pending bos to be released?

And I just checked the process_one_work. Right after the work item callback is 
called,  the workqueue itself will call cond_resched. So I think

From: Koenig, Christian 
Sent: Thursday, April 9, 2020 9:38:24 PM
To: Lucas Stach ; Pan, Xinhui ; 
amd-...@lists.freedesktop.org 
Cc: dri-devel@lists.freedesktop.org 
Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete 
worker

Am 09.04.20 um 15:25 schrieb Lucas Stach:
> Am Donnerstag, den 09.04.2020, 14:35 +0200 schrieb Christian König:
>> Am 09.04.20 um 03:31 schrieb xinhui pan:
>>> The delayed delete list is per device which might be very huge. And in
>>> a heavy workload test, the list might always not be empty. That will
>>> trigger any RCU stall warnings or softlockups in non-preemptible kernels
>>> Lets do schedule out if possible in that case.
>> Mhm, I'm not sure if that is actually allowed. This is called from a
>> work item and those are not really supposed to be scheduled away.
> Huh? Workitems can schedule out just fine, otherwise they would be
> horribly broken when it comes to sleeping locks.

Let me refine the sentence: Work items are not really supposed to be
scheduled purposely. E.g. you shouldn't call schedule() or
cond_resched() like in the case here.

Getting scheduled away because we wait for a lock is of course perfectly
fine.

>   The workqueue code
> even has measures to keep the workqueues at the expected concurrency
> level by starting other workitems when one of them goes to sleep.

Yeah, and exactly that's what I would say we should avoid here :)

In other words work items can be scheduled away, but they should not if
not really necessary (e.g. waiting for a lock).

Otherwise as you said new threads for work item processing are started
up and I don't think we want that.

Just returning from the work item and waiting for the next cycle is most
likely the better option.

Regards,
Christian.

>
> Regards,
> Lucas
>
>> Maybe rather change the while into while (!list_empty(&bdev->ddestroy)
>> && !should_reschedule(0)).
>>
>> Christian.
>>
>>> Signed-off-by: xinhui pan 
>>> ---
>>>drivers/gpu/drm/ttm/ttm_bo.c | 1 +
>>>1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>>> index 9e07c3f75156..b8d853cab33b 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -541,6 +541,7 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device 
>>> *bdev, bool remove_all)
>>>  }
>>>
>>>  ttm_bo_put(bo);
>>> +   cond_resched();
>>>  spin_lock(&glob->lru_lock);
>>>  }
>>>  list_splice_tail(&removed, &bdev->ddestroy);
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C0a47486676a74702f05408d7dc89839c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220355504145868&sdata=wbRkYBPI6mYuZjKBtQN3AGLDOwqJlWY3XUtwwSiUQHg%3D&reserved=0

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

Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc

[Alex Deucher]

On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter  wrote:
>
> On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
>  wrote:
> >
> > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > > If this code was broken for non-coherent caches a crude powerpc hack
> > > > isn't going to help anyone else.  Remove the hack as it is the last
> > > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
> > >
> > > Well Ben added this to make stuff work on ppc, ofc the home grown dma
> > > layer in drm from back then isn't going to work in other places. I guess
> > > should have at least an ack from him, in case anyone still cares about
> > > this on ppc. Adding Ben to cc.
> >
> > This was due to some drivers (radeon ?) trying to use vmalloc pages for
> > coherent DMA, which means on those 4xx powerpc's need to be non-cached.
> >
> > There were machines using that (440 based iirc), though I honestly
> > can't tell if anybody still uses any of it.
>
> agp subsystem still seems to happily do that (vmalloc memory for
> device access), never having been ported to dma apis (or well
> converted to iommu drivers, which they kinda are really). So I think
> this all still works exactly as back then, even with the kms radeon
> drivers. Question really is whether we have users left, and I have no
> clue about that either.
>
> Now if these boxes didn't ever have agp then I think we can get away
> with deleting this, since we've already deleted the legacy radeon
> driver. And that one used vmalloc for everything. The new kms one does
> use the dma-api if the gpu isn't connected through agp.

All radeons have a built in remapping table to handle non-AGP systems.
On the earlier radeons it wasn't quite as performant as AGP, but it
was always more reliable because AGP is AGP.  Maybe it's time to let
AGP go?

Alex

> -Daniel
>
> > Cheers,
> > Ben.
> >
> > > -Daniel
> > >
> > > >
> > > > Signed-off-by: Christoph Hellwig 
> > > > ---
> > > >  drivers/gpu/drm/drm_scatter.c | 11 +--
> > > >  1 file changed, 1 insertion(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_scatter.c 
> > > > b/drivers/gpu/drm/drm_scatter.c
> > > > index ca520028b2cb..f4e6184d1877 100644
> > > > --- a/drivers/gpu/drm/drm_scatter.c
> > > > +++ b/drivers/gpu/drm/drm_scatter.c
> > > > @@ -43,15 +43,6 @@
> > > >
> > > >  #define DEBUG_SCATTER 0
> > > >
> > > > -static inline void *drm_vmalloc_dma(unsigned long size)
> > > > -{
> > > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > > > -   return __vmalloc(size, GFP_KERNEL, 
> > > > pgprot_noncached_wc(PAGE_KERNEL));
> > > > -#else
> > > > -   return vmalloc_32(size);
> > > > -#endif
> > > > -}
> > > > -
> > > >  static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > > >  {
> > > > struct page *page;
> > > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, 
> > > > void *data,
> > > > return -ENOMEM;
> > > > }
> > > >
> > > > -   entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > > > +   entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > > > if (!entry->virtual) {
> > > > kfree(entry->busaddr);
> > > > kfree(entry->pagelist);
> > > > --
> > > > 2.25.1
> > > >
> > >
> > >
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm: pl111: Simplify vexpress init

[Sam Ravnborg]

Hi Rob.

On Wed, Apr 08, 2020 at 07:39:46PM -0600, Rob Herring wrote:
> The init VExpress variants currently instantiates a 'muxfpga' driver for
> the sole purpose of getting a regmap for it. There's no reason to
> instantiate a driver and doing so just complicates things. The muxfpga
> driver also isn't unregistered properly on module unload. Let's
> just simplify all this this by just calling
> devm_regmap_init_vexpress_config() directly.
> 
> Cc: Eric Anholt 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring 

Procastinating, so I took a look at this.
Nice simplification - on nit below.
Acked-by: Sam Ravnborg 
> ---
>  drivers/gpu/drm/pl111/pl111_versatile.c | 21 +++--
>  drivers/gpu/drm/pl111/pl111_vexpress.c  | 42 -
>  drivers/gpu/drm/pl111/pl111_vexpress.h  |  7 -
>  3 files changed, 4 insertions(+), 66 deletions(-)
> 
> diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c 
> b/drivers/gpu/drm/pl111/pl111_versatile.c
> index 09aeaffb7660..8c2551088f26 100644
> --- a/drivers/gpu/drm/pl111/pl111_versatile.c
> +++ b/drivers/gpu/drm/pl111/pl111_versatile.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "pl111_versatile.h"
>  #include "pl111_vexpress.h"
> @@ -325,17 +326,8 @@ int pl111_versatile_init(struct device *dev, struct 
> pl111_drm_dev_private *priv)
>   versatile_clcd_type = (enum versatile_clcd)clcd_id->data;
>  
>   /* Versatile Express special handling */
> - if (versatile_clcd_type == VEXPRESS_CLCD_V2M) {
> + if (IS_ENABLED(CONFIG_VEXPRESS_CONFIG) && versatile_clcd_type == 
> VEXPRESS_CLCD_V2M) {
>   struct platform_device *pdev;
> -
> - /* Registers a driver for the muxfpga */
> - ret = vexpress_muxfpga_init();
> - if (ret) {
> - dev_err(dev, "unable to initialize muxfpga driver\n");
> - of_node_put(np);
> - return ret;
> - }
> -
>   /* Call into deep Vexpress configuration API */
>   pdev = of_find_device_by_node(np);
>   if (!pdev) {
> @@ -343,13 +335,8 @@ int pl111_versatile_init(struct device *dev, struct 
> pl111_drm_dev_private *priv)
>   of_node_put(np);
>   return -EPROBE_DEFER;
>   }
> - map = dev_get_drvdata(&pdev->dev);
> - if (!map) {
> - dev_err(dev, "sysreg has not yet probed\n");
> - platform_device_put(pdev);
> - of_node_put(np);
> - return -EPROBE_DEFER;
> - }
> + map = devm_regmap_init_vexpress_config(&pdev->dev);
> + platform_device_put(pdev);
>   } else {
>   map = syscon_node_to_regmap(np);
>   }

On the following line there is:
if (IS_ERR(map)) {
dev_err(dev, "no Versatile syscon regmap\n");
return PTR_ERR(map);
}

The error message no longer tell if this was
devm_regmap_init_vexpress_config() or syscon_node_to_regmap() that
caused the error.

Sam

> diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.c 
> b/drivers/gpu/drm/pl111/pl111_vexpress.c
> index 350570fe06b5..37ed3f1da820 100644
> --- a/drivers/gpu/drm/pl111/pl111_vexpress.c
> +++ b/drivers/gpu/drm/pl111/pl111_vexpress.c
> @@ -94,45 +94,3 @@ int pl111_vexpress_clcd_init(struct device *dev,
>  
>   return 0;
>  }
> -
> -/*
> - * This sets up the regmap pointer that will then be retrieved by
> - * the detection code in pl111_versatile.c and passed in to the
> - * pl111_vexpress_clcd_init() function above.
> - */
> -static int vexpress_muxfpga_probe(struct platform_device *pdev)
> -{
> - struct device *dev = &pdev->dev;
> - struct regmap *map;
> -
> - map = devm_regmap_init_vexpress_config(&pdev->dev);
> - if (IS_ERR(map))
> - return PTR_ERR(map);
> - dev_set_drvdata(dev, map);
> -
> - return 0;
> -}
> -
> -static const struct of_device_id vexpress_muxfpga_match[] = {
> - { .compatible = "arm,vexpress-muxfpga", },
> - {}
> -};
> -
> -static struct platform_driver vexpress_muxfpga_driver = {
> - .driver = {
> - .name = "vexpress-muxfpga",
> - .of_match_table = of_match_ptr(vexpress_muxfpga_match),
> - },
> - .probe = vexpress_muxfpga_probe,
> -};
> -
> -int vexpress_muxfpga_init(void)
> -{
> - int ret;
> -
> - ret = platform_driver_register(&vexpress_muxfpga_driver);
> - /* -EBUSY just means this driver is already registered */
> - if (ret == -EBUSY)
> - ret = 0;
> - return ret;
> -}
> diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.h 
> b/drivers/gpu/drm/pl111/pl111_vexpress.h
> index 5d3681bb4c00..bb54864ca91e 100644
> --- a/drivers/gpu/drm/pl111/pl111_vexpress.h
> +++ b/drivers/gpu/drm/pl111/pl111_vexpress.h
> @@ -10,8 +10,6 @@ int pl111_vexpress_clcd_init(struct device *dev,

Re: [PATCH v1 2/3] drm/panel: update backlight handling for samsung-s6e63j0x03

[Emil Velikov]

On Thu, 9 Apr 2020 at 12:53, Sam Ravnborg  wrote:
>
> The samsung-s6e63j0x03 had a local way to handle backlight.
>
> Update the driver to use a devm_ based register function
> and utilize drm_panel backlight support. The changes results
> in a simpler driver with the same functionality.
>
> Signed-off-by: Sam Ravnborg 
> Cc: Joonas Kylmälä 
> Cc: Andrzej Hajda 
> Cc: Thierry Reding 
> Cc: Inki Dae 
> Cc: Hyungwon Hwang 
> Cc: Hoegeun Kwon 
> ---
>  .../gpu/drm/panel/panel-samsung-s6e63j0x03.c  | 55 ++-
>  1 file changed, 29 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c 
> b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
> index a3570e0a90a8..2c035f87e3f0 100644
> --- a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
> @@ -36,7 +36,6 @@
>  struct s6e63j0x03 {
> struct device *dev;
> struct drm_panel panel;
> -   struct backlight_device *bl_dev;
>
> struct regulator_bulk_data supplies[2];
> struct gpio_desc *reset_gpio;
> @@ -184,7 +183,7 @@ static unsigned int 
> s6e63j0x03_get_brightness_index(unsigned int brightness)
>  static int s6e63j0x03_update_gamma(struct s6e63j0x03 *ctx,
> unsigned int brightness)
>  {
> -   struct backlight_device *bl_dev = ctx->bl_dev;
> +   struct backlight_device *bl_dev = ctx->panel.backlight;
> unsigned int index = s6e63j0x03_get_brightness_index(brightness);
> int ret;
>
> @@ -217,6 +216,30 @@ static const struct backlight_ops s6e63j0x03_bl_ops = {
> .update_status = s6e63j0x03_set_brightness,
>  };
>
> +static int s6e63j0x03_backlight_register(struct s6e63j0x03 *ctx)
> +{
> +   struct backlight_properties props = {
Pretty sure we can (should really) make the props const.

Quick grep through drm, shows that there're other offenders, so might
as well do that in separate series.
Seems like other panels could follow suite, with later series of course.

Back on topic, it's not immediately obvious why the FB_BLANK_*
handling is safe to remove. Please add small mention in the commit log
mentioning why.

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

Re: [PATCH 1/3] drm: pl111: Fix module autoloading

[Sam Ravnborg]

Hi Rob.

On Wed, Apr 08, 2020 at 07:39:45PM -0600, Rob Herring wrote:
> Add a missing MODULE_DEVICE_TABLE entry to fix module autoloading.
> 
> Cc: Eric Anholt 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring 

Change looks straightforward.
Acked-by: Sam Ravnborg 

> ---
>  drivers/gpu/drm/pl111/pl111_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
> b/drivers/gpu/drm/pl111/pl111_drv.c
> index aa8aa8d9e405..7f405b1374c2 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -444,6 +444,7 @@ static const struct amba_id pl111_id_table[] = {
>   },
>   {0, 0},
>  };
> +MODULE_DEVICE_TABLE(amba, pl111_id_table);
>  
>  static struct amba_driver pl111_amba_driver __maybe_unused = {
>   .drv = {
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete worker

[Pan, Xinhui]

I think it doesn't matter if workitem schedule out. Even we did not schedule 
out, the workqueue itself will schedule out later.
So it did not break anything with this patch I think.

From: Pan, Xinhui 
Sent: Thursday, April 9, 2020 10:07:09 PM
To: Lucas Stach ; amd-...@lists.freedesktop.org 
; Koenig, Christian 
Cc: dri-devel@lists.freedesktop.org 
Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete 
worker

Why we break out the loops when there are pending bos to be released?

And I just checked the process_one_work. Right after the work item callback is 
called,  the workqueue itself will call cond_resched. So I think

From: Koenig, Christian 
Sent: Thursday, April 9, 2020 9:38:24 PM
To: Lucas Stach ; Pan, Xinhui ; 
amd-...@lists.freedesktop.org 
Cc: dri-devel@lists.freedesktop.org 
Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete 
worker

Am 09.04.20 um 15:25 schrieb Lucas Stach:
> Am Donnerstag, den 09.04.2020, 14:35 +0200 schrieb Christian König:
>> Am 09.04.20 um 03:31 schrieb xinhui pan:
>>> The delayed delete list is per device which might be very huge. And in
>>> a heavy workload test, the list might always not be empty. That will
>>> trigger any RCU stall warnings or softlockups in non-preemptible kernels
>>> Lets do schedule out if possible in that case.
>> Mhm, I'm not sure if that is actually allowed. This is called from a
>> work item and those are not really supposed to be scheduled away.
> Huh? Workitems can schedule out just fine, otherwise they would be
> horribly broken when it comes to sleeping locks.

Let me refine the sentence: Work items are not really supposed to be
scheduled purposely. E.g. you shouldn't call schedule() or
cond_resched() like in the case here.

Getting scheduled away because we wait for a lock is of course perfectly
fine.

>   The workqueue code
> even has measures to keep the workqueues at the expected concurrency
> level by starting other workitems when one of them goes to sleep.

Yeah, and exactly that's what I would say we should avoid here :)

In other words work items can be scheduled away, but they should not if
not really necessary (e.g. waiting for a lock).

Otherwise as you said new threads for work item processing are started
up and I don't think we want that.

Just returning from the work item and waiting for the next cycle is most
likely the better option.

Regards,
Christian.

>
> Regards,
> Lucas
>
>> Maybe rather change the while into while (!list_empty(&bdev->ddestroy)
>> && !should_reschedule(0)).
>>
>> Christian.
>>
>>> Signed-off-by: xinhui pan 
>>> ---
>>>drivers/gpu/drm/ttm/ttm_bo.c | 1 +
>>>1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>>> index 9e07c3f75156..b8d853cab33b 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -541,6 +541,7 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device 
>>> *bdev, bool remove_all)
>>>  }
>>>
>>>  ttm_bo_put(bo);
>>> +   cond_resched();
>>>  spin_lock(&glob->lru_lock);
>>>  }
>>>  list_splice_tail(&removed, &bdev->ddestroy);
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C0a47486676a74702f05408d7dc89839c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220355504145868&sdata=wbRkYBPI6mYuZjKBtQN3AGLDOwqJlWY3XUtwwSiUQHg%3D&reserved=0

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

Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete worker

[Pan, Xinhui]

[AMD Official Use Only - Internal Distribution Only]

Why we break out the loops when there are pending bos to be released?

And I just checked the process_one_work. Right after the work item callback is 
called,  the workqueue itself will call cond_resched. So I think

From: Koenig, Christian 
Sent: Thursday, April 9, 2020 9:38:24 PM
To: Lucas Stach ; Pan, Xinhui ; 
amd-...@lists.freedesktop.org 
Cc: dri-devel@lists.freedesktop.org 
Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete 
worker

Am 09.04.20 um 15:25 schrieb Lucas Stach:
> Am Donnerstag, den 09.04.2020, 14:35 +0200 schrieb Christian König:
>> Am 09.04.20 um 03:31 schrieb xinhui pan:
>>> The delayed delete list is per device which might be very huge. And in
>>> a heavy workload test, the list might always not be empty. That will
>>> trigger any RCU stall warnings or softlockups in non-preemptible kernels
>>> Lets do schedule out if possible in that case.
>> Mhm, I'm not sure if that is actually allowed. This is called from a
>> work item and those are not really supposed to be scheduled away.
> Huh? Workitems can schedule out just fine, otherwise they would be
> horribly broken when it comes to sleeping locks.

Let me refine the sentence: Work items are not really supposed to be
scheduled purposely. E.g. you shouldn't call schedule() or
cond_resched() like in the case here.

Getting scheduled away because we wait for a lock is of course perfectly
fine.

>   The workqueue code
> even has measures to keep the workqueues at the expected concurrency
> level by starting other workitems when one of them goes to sleep.

Yeah, and exactly that's what I would say we should avoid here :)

In other words work items can be scheduled away, but they should not if
not really necessary (e.g. waiting for a lock).

Otherwise as you said new threads for work item processing are started
up and I don't think we want that.

Just returning from the work item and waiting for the next cycle is most
likely the better option.

Regards,
Christian.

>
> Regards,
> Lucas
>
>> Maybe rather change the while into while (!list_empty(&bdev->ddestroy)
>> && !should_reschedule(0)).
>>
>> Christian.
>>
>>> Signed-off-by: xinhui pan 
>>> ---
>>>drivers/gpu/drm/ttm/ttm_bo.c | 1 +
>>>1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>>> index 9e07c3f75156..b8d853cab33b 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -541,6 +541,7 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device 
>>> *bdev, bool remove_all)
>>>  }
>>>
>>>  ttm_bo_put(bo);
>>> +   cond_resched();
>>>  spin_lock(&glob->lru_lock);
>>>  }
>>>  list_splice_tail(&removed, &bdev->ddestroy);
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C0a47486676a74702f05408d7dc89839c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220355504145868&sdata=wbRkYBPI6mYuZjKBtQN3AGLDOwqJlWY3XUtwwSiUQHg%3D&reserved=0

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

Re: [PATCH v11 0/2] drm: bridge: Add NWL MIPI DSI host controller support

[Sam Ravnborg]

Hi Guido.

On Thu, Apr 09, 2020 at 12:42:00PM +0200, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
> SoCs.
> 
> It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
> i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
> I only have imx8mq boards to test I omitted the platform data for other SoCs.
> 
> The code is based on NXPs BSP so I added Robert Chiras as Co-authored-by.
> 
> The most notable changes over the BSP driver are
>  - Calculate HS mode timing from phy_configure_opts_mipi_dphy
>  - Perform all clock setup via DT
>  - Merge nwl-imx and nwl drivers
>  - Add B0 silion revision quirk
>  - become a bridge driver to hook into mxsfb / dcss
>imx-display-subsystem so it makes sense to make it drive a bridge for dsi 
> as
>well).
>  - Use panel_bridge to attach the panel
>  - Use multiplex framework instead of accessing syscon directly
> 
> This has been tested on a Librem 5 devkit using mxsfb with Robert's patches[1]
> and the mainline rocktech-jh057n00900 DSI panel driver on next-20200317 and on
> the Librem5 with the a Mantix MLAF057WE51-X DSI panel driver (not yet 
> mainline)
> The DCSS (submitted for mainline inclusion now too) can also act as input
> source.

Thanks for your persistence with this driver.
I got ack from Laurent on IRC to apply it (not for the driver as he had
no time to review it).
So applied to drm-misc-next now.

I look forward for the update to support DRM_BRIDGE_ATTACH_NO_CONNECTOR
in this driver and the corresponding display driver.

Sam
> 
> Changes from v10:
> - Per review comments by Sam Ravnborg
>   
> https://lore.kernel.org/linux-arm-kernel/20200408175252.gb24...@ravnborg.org/
>   - Drop unused headers
>   - Fix 'check-patch --strict' findings
>   - Print error when DRM_BRIDGE_ATTACH_NO_CONNECTOR is passed
> - Per review comment by Laurent Pinchart
>   
> https://lore.kernel.org/linux-arm-kernel/20200408173258.ga24...@ravnborg.org/
>   - There's only one endpoint allowed at a time, add a restriction for that.
> - Add Reviewed-by from Fabio Estevam
>   
> https://lore.kernel.org/linux-arm-kernel/CAOMZO5Dhy7ahcR-S=QG=pumxxa8hnqowpg0tdfyeu_levdh...@mail.gmail.com/
>   
> https://lore.kernel.org/linux-arm-kernel/caomzo5du-zp7wxm2eh8wafock_kwomgh57ayjrbb0pzhuaa...@mail.gmail.com/
> - Move to next-20200408
> 
> Changes from v9:
> - Per review comments by Sam Ravnborg
>   https://lore.kernel.org/dri-devel/20200318214639.ga...@ravnborg.org/
>   - Drop header-test-y since kernel lost support
>   - Handle drm_bridge_attach's new flags argument
>   - Add Acked-by: to binding patch, thanks!
> - Move to next-20200319
> 
> Changes from v8:
> - Per review comments by Robert Chiras
>   https://lore.kernel.org/dri-devel/1575366594.6423.61.ca...@nxp.com/
>   - don't mix DSI host and bridge initialization
>   - only select output source once
>   - defer probe when panel is not ready to fix usage as a module
>   - use correct reset sequence as described by Robert
> (and provided by NWL)
>   - use mode->clock instead of mode->crtc_clock
> - Add tested by from Martin Kepplinger, thanks!
> - Drop platform specific data (as suggested previously by Laurent Pinchart and
>   Andrzej Hajda) since imx8q* needs another set of abstractions with the new
>   reset sequence and that's easier to do when adding imx8q* support rather 
> then
>   adding wrong abstraction now.
> - Update bindings to use proper clock and irq names to make the example match
>   reality more closely.
> - Use `fallthrough;` instead of /* Fall through */ in switch statements
> - Move to next-20200226
> 
> Changes from v7:
> - Drop reset quirk. It's not needed with mxsfb and sometimes triggers a 
> shifted display.
> 
> Changes from v6:
> - Per review comments by Andrzej Hajda
>   
> https://lore.kernel.org/linux-arm-kernel/c86b7ca2-7799-eafd-c380-e4b551520...@samsung.com/
>   - Drop spare empty line
>   - handle nwl_dsi_write errors
>   - better handle read errors
>   - unwind in case of error in nwl_dsi_enable
>   - use bridge_to_dsi() instead of accessing driver_private
>   - don't log on -EPROBEDEFER when fething the reset controller
>   - use endpoint number to determine input
> - Spotted by kbuild test robot 
>   
> https://lore.kernel.org/linux-arm-kernel/201909230644.qfskbnf9%25...@intel.com/
>   Use signed return type for nwl_dsi_get_dpi_pixel_format
> - Drop connector type from drm_panel_bridge_add
> - Don't forget to set an error value on dsi reads
> 
> Changes from v5:
> - Per review comments by Andrzej Hajda
>   https://lists.freedesktop.org/archives/dri-devel/2019-September/235281.html
>   - Fix include file ordering
>   - Add a comment to nwl_dsi_platform_data that will allow to add support
> at least for the i.MX8QM
>   - Merge driver into a single file plus the register defs in a separate 
> header
> - Make more functions and structs static
> 
> Changes from v4:
> - Collect Reviewed-

[Bug 207171] [regression][bisected] Ryzen PRO 2400G, firefox screen corruption in X

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=207171

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 288299
  --> https://bugzilla.kernel.org/attachment.cgi?id=288299&action=edit
possible fix

Does this patch fix it?

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

Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete worker

[Christian König]

Am 09.04.20 um 15:25 schrieb Lucas Stach:

Am Donnerstag, den 09.04.2020, 14:35 +0200 schrieb Christian König:

Am 09.04.20 um 03:31 schrieb xinhui pan:

The delayed delete list is per device which might be very huge. And in
a heavy workload test, the list might always not be empty. That will
trigger any RCU stall warnings or softlockups in non-preemptible kernels
Lets do schedule out if possible in that case.

Mhm, I'm not sure if that is actually allowed. This is called from a
work item and those are not really supposed to be scheduled away.

Huh? Workitems can schedule out just fine, otherwise they would be
horribly broken when it comes to sleeping locks.


Let me refine the sentence: Work items are not really supposed to be 
scheduled purposely. E.g. you shouldn't call schedule() or 
cond_resched() like in the case here.


Getting scheduled away because we wait for a lock is of course perfectly 
fine.



  The workqueue code
even has measures to keep the workqueues at the expected concurrency
level by starting other workitems when one of them goes to sleep.


Yeah, and exactly that's what I would say we should avoid here :)

In other words work items can be scheduled away, but they should not if 
not really necessary (e.g. waiting for a lock).


Otherwise as you said new threads for work item processing are started 
up and I don't think we want that.


Just returning from the work item and waiting for the next cycle is most 
likely the better option.


Regards,
Christian.



Regards,
Lucas


Maybe rather change the while into while (!list_empty(&bdev->ddestroy)
&& !should_reschedule(0)).

Christian.


Signed-off-by: xinhui pan 
---
   drivers/gpu/drm/ttm/ttm_bo.c | 1 +
   1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9e07c3f75156..b8d853cab33b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -541,6 +541,7 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
}
   
   		ttm_bo_put(bo);

+   cond_resched();
spin_lock(&glob->lru_lock);
}
list_splice_tail(&removed, &bdev->ddestroy);

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C0a47486676a74702f05408d7dc89839c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220355504145868&sdata=wbRkYBPI6mYuZjKBtQN3AGLDOwqJlWY3XUtwwSiUQHg%3D&reserved=0


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

[Bug 207171] [regression][bisected] Ryzen PRO 2400G, firefox screen corruption in X

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=207171

Florian Ziegler (florian.zieg...@posteo.de) changed:

   What|Removed |Added

 Regression|No  |Yes

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

[Bug 207171] New: [regression][bisected] Ryzen PRO 2400G, firefox screen corruption in X

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=207171

Bug ID: 207171
   Summary: [regression][bisected] Ryzen PRO 2400G, firefox screen
corruption in X
   Product: Drivers
   Version: 2.5
Kernel Version: 5.6.3
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: florian.zieg...@posteo.de
Regression: No

Created attachment 288297
  --> https://bugzilla.kernel.org/attachment.cgi?id=288297&action=edit
dmesg

Hello,

I have a Ryzen PRO 2400G (HP EliteDesk 705 G4)

with kernel 5.6 I am experiencing screen corruption in firefox under X.
Symptoms are:
- black and white horizontal lines over the whole width of the firefox window
- displaced/duplicated renderings all over the screen
- black bars over the width of a moving object (sroll-over effect)

Only the firefox window is affected.
But when I move the window while there are corruptions, the whole screen is
affected for 1(?) frame.
Windows decorations are not affected.

Symptoms vary form website to website, playing video or sites that heavily
rerender when scrolling or clicking buttons seems to trigger or increase the
symptoms.

The symptoms do not appear with weston and firefox.
The symptoms do not appear with chromium under X

Output of git bisect:

# first bad commit: [7af2a5771e0918cdadb1614c1f81dd67a58e00aa] drm/amdgpu:
attempt to enable gfxoff on more raven1 boards (v2)

If you need pictures or further information, I can provide them.

The bug looks similar to this one:
https://bugzilla.kernel.org/show_bug.cgi?id=207005
But the reporter claimed that it never worked.
My bug report is about a regression.

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

[PATCH] drm/i915: remove redundant assignment to variable err

[Colin King]

From: Colin Ian King 

The variable err is being initialized with a value that is never read
and it is being updated later with a new value.  The initialization is
redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c
index 2b6db6f799de..faa5b6d91795 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c
@@ -14,7 +14,7 @@ static int igt_gem_object(void *arg)
 {
struct drm_i915_private *i915 = arg;
struct drm_i915_gem_object *obj;
-   int err = -ENOMEM;
+   int err;
 
/* Basic test to ensure we can create an object */
 
-- 
2.25.1

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

Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete worker

[Lucas Stach]

Am Donnerstag, den 09.04.2020, 14:35 +0200 schrieb Christian König:
> Am 09.04.20 um 03:31 schrieb xinhui pan:
> > The delayed delete list is per device which might be very huge. And in
> > a heavy workload test, the list might always not be empty. That will
> > trigger any RCU stall warnings or softlockups in non-preemptible kernels
> > Lets do schedule out if possible in that case.
> 
> Mhm, I'm not sure if that is actually allowed. This is called from a 
> work item and those are not really supposed to be scheduled away.

Huh? Workitems can schedule out just fine, otherwise they would be
horribly broken when it comes to sleeping locks. The workqueue code
even has measures to keep the workqueues at the expected concurrency
level by starting other workitems when one of them goes to sleep.

Regards,
Lucas

> Maybe rather change the while into while (!list_empty(&bdev->ddestroy) 
> && !should_reschedule(0)).
> 
> Christian.
> 
> > Signed-off-by: xinhui pan 
> > ---
> >   drivers/gpu/drm/ttm/ttm_bo.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index 9e07c3f75156..b8d853cab33b 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -541,6 +541,7 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device 
> > *bdev, bool remove_all)
> > }
> >   
> > ttm_bo_put(bo);
> > +   cond_resched();
> > spin_lock(&glob->lru_lock);
> > }
> > list_splice_tail(&removed, &bdev->ddestroy);
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete worker

[Christian König]

Am 09.04.20 um 03:31 schrieb xinhui pan:

The delayed delete list is per device which might be very huge. And in
a heavy workload test, the list might always not be empty. That will
trigger any RCU stall warnings or softlockups in non-preemptible kernels
Lets do schedule out if possible in that case.


Mhm, I'm not sure if that is actually allowed. This is called from a 
work item and those are not really supposed to be scheduled away.


Maybe rather change the while into while (!list_empty(&bdev->ddestroy) 
&& !should_reschedule(0)).


Christian.



Signed-off-by: xinhui pan 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9e07c3f75156..b8d853cab33b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -541,6 +541,7 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
}
  
  		ttm_bo_put(bo);

+   cond_resched();
spin_lock(&glob->lru_lock);
}
list_splice_tail(&removed, &bdev->ddestroy);


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

Re: [RFC v3 1/8] dt-bindings: display: convert ingenic, lcd.txt to ingenic, lcd.yaml

[Sam Ravnborg]

Hi Nikolaus.

> >> +
> >> +examples:
> >> +  - |
> >> +#include 
> >> +
> >> +panel {
> >> +  compatible = "sharp,ls020b1dd01d";
> >> +
> >> +  backlight = <&backlight>;
> >> +  power-supply = <&vcc>;
> >> +
> >> +  port {
> >> +panel_input: endpoint {
> >> +  remote-endpoint = <&panel_output>;
> >> +  };
> >> +};
> >> +  };
> > The panel part is not needed - better to drop it.
> 
> Well, it is needed to fulfill the remote-endpoint below.

Examples may have phandle that are not defined.
So the example will work fine without it.
See other similar examples.

> 
> > 
> > 
> >> +
> >> +lcd: lcd-controller@1305 {
> >> +  compatible = "ingenic,jz4725b-lcd";
> >> +  reg = <0x1305 0x1000>;
> >> +
> >> +  interrupt-parent = <&intc>;
> >> +  interrupts = <31>;
> >> +
> >> +  clocks = <&cgu JZ4725B_CLK_LCD>;
> >> +  clock-names = "lcd", "lcd_pclk";
> >> +
> >> +  port {
> >> +panel_output: endpoint {
> >> +  remote-endpoint = <&panel_input>;
> >> +  };
> >> +};
> >> +  };
> > We know this example will not pass the check, as there is only
> > one clock specified.
> > I suggest to drop this example.
> > If it later turns out that jz4725b only have one clock,
> 
> Paul already reported that it only wants to see one clock.
> 
> > then the binding
> > needs to be updated.
> 
> Yes, I have that on my to-do list to update the binding to reflect
> this minItems/maxItems thing but I am not yet sure about how
> to handle the clock-names in that case. I.e. make "lcd" optional
> and enforce "lcd_pclk" only.
Look forward to next version.

> 
> > But the best guess is that the example is wrong.
> > 
> > The example below for jz4780-lcd cover all relevant parts - so
> > just keep it as the only example.
> > 
> >> +
> >> +  - |
> >> +#include 
> >> +
> >> +lcdc0: lcdc0@1305 {
> > Name this lcdc
> > And drop "lcdc0@1305" as this is not relevant for this example.
> > 
> > Remember - the examples exist to explain the binding. They are
> > just examples.
> > 
> >> +compatible = "ingenic,jz4780-lcd";
> >> +reg = <0x1305 0x1800>;
> >> +
> >> +clocks = <&cgu JZ4780_CLK_TVE>, <&cgu JZ4780_CLK_LCD0PIXCLK>;
> >> +clock-names = "lcd", "lcd_pclk";
> >> +
> >> +interrupt-parent = <&intc>;
> >> +interrupts = <31>;
> >> +
> >> +jz4780_lcd_out: port {
> >> +#address-cells = <1>;
> >> +#size-cells = <0>;
> >> +
> >> +jz4780_out_hdmi: endpoint@0 {
> >> +reg = <0>;
> >> +remote-endpoint = <&hdmi_in_lcd>;
> >> +};
> >> +};
> >> +};
> >> +
> > 
> > And drop this as it does not add anything extra.
> 
> Well, it demonstrates how to add a second lcdc which is disabled.
The purpose of the example is to show an example of the
binding specified in this file.
Adding a second disabled lcdc is a general thing, and not
something we want in all the individual examples.

Also the actual content, for example register values can be
random as they are not part of the binding.
This is not a documentation of the HW but a binding example.

Sam

> 
> Showing that it is possible to do so is IMHO the most important
> part of the example because it is not at all obvious.
> 
> I have also added both SoC to show how differently they can
> and should be.
> 
> >> +lcdc1: lcdc1@130a {
> >> +compatible = "ingenic,jz4780-lcd";
> >> +reg = <0x130a 0x1800>;
> >> +
> >> +clocks = <&cgu JZ4780_CLK_TVE>, <&cgu JZ4780_CLK_LCD1PIXCLK>;
> >> +clock-names = "lcd", "lcd_pclk";
> >> +
> >> +interrupt-parent = <&intc>;
> >> +interrupts = <31>;
> >> +
> >> +status = "disabled";
> >> +};
> > 
> > Sam
> 
> BR and thanks,
> Nikolaus
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: Remove reference to the mem_glob member

[Christian König]

Am 09.04.20 um 00:14 schrieb Maya Rashish:

It was removed in:

Author: Christian König 
Date:   Wed Sep 25 11:38:50 2019 +0200

 drm/ttm: remove pointers to globals

Signed-off-by: Maya Rashish 


Reviewed-by: Christian König 

I assuming you don't have commit right, so I'm going to push this to 
drm-misc-next as well.



---
  include/drm/ttm/ttm_bo_driver.h | 1 -
  1 file changed, 1 deletion(-)

diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index c9e0fd09f4b2..54a527aa79cc 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -390,7 +390,6 @@ struct ttm_bo_driver {
  /**
   * struct ttm_bo_global - Buffer object driver global data.
   *
- * @mem_glob: Pointer to a struct ttm_mem_global object for accounting.
   * @dummy_read_page: Pointer to a dummy page used for mapping requests
   * of unpopulated pages.
   * @shrink: A shrink callback object used for buffer object swap.


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

[PATCH v1 3/3] drm/panel: update backlight handling for samsung-s6e63m0

[Sam Ravnborg]

The samsung-s6e63m0 had a local way to handle backlight.

Update the driver to use a devm_ based register function
and utilize drm_panel backlight support. The changes results
in a simpler driver with the same functionality.

Signed-off-by: Sam Ravnborg 
Cc: Paweł Chmiel 
Cc: Joonas Kylmälä 
Cc: Andrzej Hajda 
Cc: Thierry Reding 
Cc: Sam Ravnborg 
---
 drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 20 ---
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
index a5f76eb4fa25..089bf4cff840 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
@@ -89,7 +89,6 @@ static u8 const 
s6e63m0_gamma_22[NUM_GAMMA_LEVELS][GAMMA_TABLE_COUNT] = {
 struct s6e63m0 {
struct device *dev;
struct drm_panel panel;
-   struct backlight_device *bl_dev;
 
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpio;
@@ -293,8 +292,6 @@ static int s6e63m0_disable(struct drm_panel *panel)
if (!ctx->enabled)
return 0;
 
-   backlight_disable(ctx->bl_dev);
-
s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_ENTER_SLEEP_MODE);
msleep(200);
 
@@ -355,8 +352,6 @@ static int s6e63m0_enable(struct drm_panel *panel)
 
s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_ON);
 
-   backlight_enable(ctx->bl_dev);
-
ctx->enabled = true;
 
return 0;
@@ -394,7 +389,6 @@ static const struct drm_panel_funcs s6e63m0_drm_funcs = {
 static int s6e63m0_set_brightness(struct backlight_device *bd)
 {
struct s6e63m0 *ctx = bl_get_data(bd);
-
int brightness = bd->props.brightness;
 
/* disable and set new gamma */
@@ -416,19 +410,21 @@ static int s6e63m0_backlight_register(struct s6e63m0 *ctx)
struct backlight_properties props = {
.type   = BACKLIGHT_RAW,
.brightness = MAX_BRIGHTNESS,
-   .max_brightness = MAX_BRIGHTNESS
+   .max_brightness = MAX_BRIGHTNESS,
};
+   struct backlight_device *backlight;
struct device *dev = ctx->dev;
int ret = 0;
 
-   ctx->bl_dev = devm_backlight_device_register(dev, "panel", dev, ctx,
-&s6e63m0_backlight_ops,
-&props);
-   if (IS_ERR(ctx->bl_dev)) {
-   ret = PTR_ERR(ctx->bl_dev);
+   backlight = devm_backlight_device_register(dev, "panel", dev, ctx,
+  &s6e63m0_backlight_ops,
+  &props);
+   if (IS_ERR(backlight)) {
+   ret = PTR_ERR(backlight);
DRM_DEV_ERROR(dev, "error registering backlight device (%d)\n",
  ret);
}
+   ctx->panel.backlight = backlight;
 
return ret;
 }
-- 
2.20.1

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

[PATCH v1 2/3] drm/panel: update backlight handling for samsung-s6e63j0x03

[Sam Ravnborg]

The samsung-s6e63j0x03 had a local way to handle backlight.

Update the driver to use a devm_ based register function
and utilize drm_panel backlight support. The changes results
in a simpler driver with the same functionality.

Signed-off-by: Sam Ravnborg 
Cc: Joonas Kylmälä 
Cc: Andrzej Hajda 
Cc: Thierry Reding 
Cc: Inki Dae 
Cc: Hyungwon Hwang 
Cc: Hoegeun Kwon 
---
 .../gpu/drm/panel/panel-samsung-s6e63j0x03.c  | 55 ++-
 1 file changed, 29 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
index a3570e0a90a8..2c035f87e3f0 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -36,7 +36,6 @@
 struct s6e63j0x03 {
struct device *dev;
struct drm_panel panel;
-   struct backlight_device *bl_dev;
 
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpio;
@@ -184,7 +183,7 @@ static unsigned int 
s6e63j0x03_get_brightness_index(unsigned int brightness)
 static int s6e63j0x03_update_gamma(struct s6e63j0x03 *ctx,
unsigned int brightness)
 {
-   struct backlight_device *bl_dev = ctx->bl_dev;
+   struct backlight_device *bl_dev = ctx->panel.backlight;
unsigned int index = s6e63j0x03_get_brightness_index(brightness);
int ret;
 
@@ -217,6 +216,30 @@ static const struct backlight_ops s6e63j0x03_bl_ops = {
.update_status = s6e63j0x03_set_brightness,
 };
 
+static int s6e63j0x03_backlight_register(struct s6e63j0x03 *ctx)
+{
+   struct backlight_properties props = {
+   .type   = BACKLIGHT_RAW,
+   .brightness = DEFAULT_BRIGHTNESS,
+   .max_brightness = MAX_BRIGHTNESS,
+   };
+   struct backlight_device *backlight;
+   struct device *dev = ctx->dev;
+   int ret = 0;
+
+   backlight = devm_backlight_device_register(dev, "panel", dev, ctx,
+  &s6e63j0x03_bl_ops,
+  &props);
+   if (IS_ERR(backlight)) {
+   ret = PTR_ERR(backlight);
+   DRM_DEV_ERROR(dev, "error registering backlight device (%d)\n",
+ ret);
+   }
+   ctx->panel.backlight = backlight;
+
+   return ret;
+}
+
 static int s6e63j0x03_disable(struct drm_panel *panel)
 {
struct s6e63j0x03 *ctx = panel_to_s6e63j0x03(panel);
@@ -227,8 +250,6 @@ static int s6e63j0x03_disable(struct drm_panel *panel)
if (ret < 0)
return ret;
 
-   ctx->bl_dev->props.power = FB_BLANK_NORMAL;
-
ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
if (ret < 0)
return ret;
@@ -247,8 +268,6 @@ static int s6e63j0x03_unprepare(struct drm_panel *panel)
if (ret < 0)
return ret;
 
-   ctx->bl_dev->props.power = FB_BLANK_POWERDOWN;
-
return 0;
 }
 
@@ -334,8 +353,6 @@ static int s6e63j0x03_prepare(struct drm_panel *panel)
if (ret < 0)
goto err;
 
-   ctx->bl_dev->props.power = FB_BLANK_NORMAL;
-
return 0;
 
 err:
@@ -395,8 +412,6 @@ static int s6e63j0x03_enable(struct drm_panel *panel)
if (ret < 0)
return ret;
 
-   ctx->bl_dev->props.power = FB_BLANK_UNBLANK;
-
return 0;
 }
 
@@ -469,20 +484,13 @@ static int s6e63j0x03_probe(struct mipi_dsi_device *dsi)
drm_panel_init(&ctx->panel, dev, &s6e63j0x03_funcs,
   DRM_MODE_CONNECTOR_DSI);
 
-   ctx->bl_dev = backlight_device_register("s6e63j0x03", dev, ctx,
-   &s6e63j0x03_bl_ops, NULL);
-   if (IS_ERR(ctx->bl_dev)) {
-   dev_err(dev, "failed to register backlight device\n");
-   return PTR_ERR(ctx->bl_dev);
-   }
-
-   ctx->bl_dev->props.max_brightness = MAX_BRIGHTNESS;
-   ctx->bl_dev->props.brightness = DEFAULT_BRIGHTNESS;
-   ctx->bl_dev->props.power = FB_BLANK_POWERDOWN;
+   ret = s6e63j0x03_backlight_register(ctx);
+   if (ret)
+   return ret;
 
ret = drm_panel_add(&ctx->panel);
if (ret < 0)
-   goto unregister_backlight;
+   return ret;
 
ret = mipi_dsi_attach(dsi);
if (ret < 0)
@@ -493,9 +501,6 @@ static int s6e63j0x03_probe(struct mipi_dsi_device *dsi)
 remove_panel:
drm_panel_remove(&ctx->panel);
 
-unregister_backlight:
-   backlight_device_unregister(ctx->bl_dev);
-
return ret;
 }
 
@@ -506,8 +511,6 @@ static int s6e63j0x03_remove(struct mipi_dsi_device *dsi)
mipi_dsi_detach(dsi);
drm_panel_remove(&ctx->panel);
 
-   backlight_device_unregister(ctx->bl_dev);
-
return 0;
 }
 
-- 
2.20.1

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

[PATCH v1 0/3] drm/panel: update backlight support for samsung panels

[Sam Ravnborg]

Update the backlight handling in three samsung panels.
  - Use devm_ functions to automate cleanup
  - Utilize backlight support in drm_panel
  - Introduce a register backlight helper in all panels
Using the same pattern in all panels makes it simpler
to read the code.

With this change the backlight handling in these panels
is now much more like what we see in other panels.

Testing or any other feedback appreciated!

Sam


Sam Ravnborg (3):
  drm/panel: update backlight handling for samsung-s6e3ha2
  drm/panel: update backlight handling for samsung-s6e63j0x03
  drm/panel: update backlight handling for samsung-s6e63m0

 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c| 55 +---
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 55 +---
 drivers/gpu/drm/panel/panel-samsung-s6e63m0.c| 20 -
 3 files changed, 68 insertions(+), 62 deletions(-)


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

[PATCH v1 1/3] drm/panel: update backlight handling for samsung-s6e3ha2

[Sam Ravnborg]

The samsung-s6e3ha2 had a local way to handle backlight.

Update the driver to use a devm_ based register function
and utilize drm_panel backlight support. The changes results
in a simpler driver with the same functionality.

Signed-off-by: Sam Ravnborg 
Cc: Joonas Kylmälä 
Cc: Andrzej Hajda 
Cc: Thierry Reding 
Cc: Inki Dae 
Cc: Hyungwon Hwang 
Cc: Hoegeun Kwon 
---
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 55 +++
 1 file changed, 31 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 36ebd5a4ac7b..08862146aec3 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -233,7 +233,6 @@ struct s6e3ha2_panel_desc {
 struct s6e3ha2 {
struct device *dev;
struct drm_panel panel;
-   struct backlight_device *bl_dev;
 
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpio;
@@ -415,7 +414,7 @@ static int s6e3ha2_get_brightness(struct backlight_device 
*bl_dev)
 
 static int s6e3ha2_set_vint(struct s6e3ha2 *ctx)
 {
-   struct backlight_device *bl_dev = ctx->bl_dev;
+   struct backlight_device *bl_dev = ctx->panel.backlight;
unsigned int brightness = bl_dev->props.brightness;
unsigned char data[] = { 0xf4, 0x8b,
vint_table[brightness * (S6E3HA2_VINT_STATUS_MAX - 1) /
@@ -432,7 +431,7 @@ static unsigned int s6e3ha2_get_brightness_index(unsigned 
int brightness)
 
 static int s6e3ha2_update_gamma(struct s6e3ha2 *ctx, unsigned int brightness)
 {
-   struct backlight_device *bl_dev = ctx->bl_dev;
+   struct backlight_device *bl_dev = ctx->panel.backlight;
unsigned int index = s6e3ha2_get_brightness_index(brightness);
u8 data[S6E3HA2_GAMMA_CMD_CNT + 1] = { 0xca, };
int ret;
@@ -476,6 +475,30 @@ static const struct backlight_ops s6e3ha2_bl_ops = {
.update_status = s6e3ha2_set_brightness,
 };
 
+static int s6e3ha2_backlight_register(struct s6e3ha2 *ctx)
+{
+   struct backlight_properties props = {
+   .type   = BACKLIGHT_RAW,
+   .brightness = S6E3HA2_DEFAULT_BRIGHTNESS,
+   .max_brightness = S6E3HA2_MAX_BRIGHTNESS,
+   };
+   struct backlight_device *backlight;
+   struct device *dev = ctx->dev;
+   int ret = 0;
+
+   backlight = devm_backlight_device_register(dev, "panel", dev, ctx,
+  &s6e3ha2_bl_ops,
+  &props);
+   if (IS_ERR(backlight)) {
+   ret = PTR_ERR(backlight);
+   DRM_DEV_ERROR(dev, "error registering backlight device (%d)\n",
+ ret);
+   }
+   ctx->panel.backlight = backlight;
+
+   return ret;
+}
+
 static int s6e3ha2_panel_init(struct s6e3ha2 *ctx)
 {
struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
@@ -509,7 +532,6 @@ static int s6e3ha2_disable(struct drm_panel *panel)
s6e3ha2_call_write_func(ret, mipi_dsi_dcs_set_display_off(dsi));
 
msleep(40);
-   ctx->bl_dev->props.power = FB_BLANK_NORMAL;
 
return 0;
 }
@@ -555,8 +577,6 @@ static int s6e3ha2_prepare(struct drm_panel *panel)
if (ret < 0)
goto err;
 
-   ctx->bl_dev->props.power = FB_BLANK_NORMAL;
-
return 0;
 
 err:
@@ -588,7 +608,6 @@ static int s6e3ha2_enable(struct drm_panel *panel)
s6e3ha2_call_write_func(ret, s6e3ha2_te_start_setting(ctx));
 
/* brightness setting */
-   s6e3ha2_call_write_func(ret, s6e3ha2_set_brightness(ctx->bl_dev));
s6e3ha2_call_write_func(ret, s6e3ha2_aor_control(ctx));
s6e3ha2_call_write_func(ret, s6e3ha2_caps_elvss_set(ctx));
s6e3ha2_call_write_func(ret, s6e3ha2_gamma_update(ctx));
@@ -602,7 +621,6 @@ static int s6e3ha2_enable(struct drm_panel *panel)
s6e3ha2_call_write_func(ret, s6e3ha2_test_key_off_f0(ctx));
 
s6e3ha2_call_write_func(ret, mipi_dsi_dcs_set_display_on(dsi));
-   ctx->bl_dev->props.power = FB_BLANK_UNBLANK;
 
return 0;
 }
@@ -721,23 +739,16 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
return PTR_ERR(ctx->enable_gpio);
}
 
-   ctx->bl_dev = backlight_device_register("s6e3ha2", dev, ctx,
-   &s6e3ha2_bl_ops, NULL);
-   if (IS_ERR(ctx->bl_dev)) {
-   dev_err(dev, "failed to register backlight device\n");
-   return PTR_ERR(ctx->bl_dev);
-   }
-
-   ctx->bl_dev->props.max_brightness = S6E3HA2_MAX_BRIGHTNESS;
-   ctx->bl_dev->props.brightness = S6E3HA2_DEFAULT_BRIGHTNESS;
-   ctx->bl_dev->props.power = FB_BLANK_POWERDOWN;
-
drm_panel_init(&ctx->panel, dev, &s6e3ha2_drm_funcs,
   DRM_MODE_CONNECTOR_DSI);
 
+   ret = s6e3ha2_backlight_register(ctx);
+   if (ret)
+

Re: [PATCH v10 2/2] drm/bridge: Add NWL MIPI DSI host controller support

[Sam Ravnborg]

Hi Guido.

> > > +
> > > +/* i.MX8 NWL quirks */
> > > +/* i.MX8MQ errata E11418 */
> > > +#define E11418_HS_MODE_QUIRK BIT(0)
> > > +
> > > +#define NWL_DSI_MIPI_FIFO_TIMEOUT msecs_to_jiffies(500)
> > Should the defines be moved to the header file?
> 
> I've used this rules: register layout (that is chip properties)
> go to the header file while defines specific to this very driver
> go into the .c file. Hope that makes sense.

Makes good sense, thanks for the explanation.

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

[PATCH 2/3] dma-buf: Report signaled links inside dma-fence-chain

[Chris Wilson]

Whenever we walk along the dma-fence-chain, we prune signaled links to
keep the chain nice and tidy. This leads to situations where we can
prune a link and report the earlier fence as the target seqno --
violating our own consistency checks that the seqno is not more advanced
than the last element in a dma-fence-chain.

Report a NULL fence and success if the seqno has already been signaled.

Signed-off-by: Chris Wilson 
Tested-by: Venkata Sandeep Dhanalakota 
Reviewed-by: Venkata Sandeep Dhanalakota 
---
 drivers/dma-buf/dma-fence-chain.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c
index 3d123502ff12..c435bbba851c 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -99,6 +99,12 @@ int dma_fence_chain_find_seqno(struct dma_fence **pfence, 
uint64_t seqno)
return -EINVAL;
 
dma_fence_chain_for_each(*pfence, &chain->base) {
+   if ((*pfence)->seqno < seqno) { /* already signaled */
+   dma_fence_put(*pfence);
+   *pfence = NULL;
+   break;
+   }
+
if ((*pfence)->context != chain->base.context ||
to_dma_fence_chain(*pfence)->prev_seqno < seqno)
break;
@@ -222,6 +228,7 @@ EXPORT_SYMBOL(dma_fence_chain_ops);
  * @chain: the chain node to initialize
  * @prev: the previous fence
  * @fence: the current fence
+ * @seqno: the sequence number (syncpt) of the fence within the chain
  *
  * Initialize a new chain node and either start a new chain or add the node to
  * the existing chain of the previous fence.
-- 
2.20.1

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

[PATCH 3/3] dma-buf: Exercise dma-fence-chain under selftests

[Chris Wilson]

A few very simple testcases to exercise the dma-fence-chain API.

Signed-off-by: Chris Wilson 
Reviewed-by: Venkata Sandeep Dhanalakota 
---
 drivers/dma-buf/Makefile |   3 +-
 drivers/dma-buf/selftests.h  |   1 +
 drivers/dma-buf/st-dma-fence-chain.c | 713 +++
 3 files changed, 716 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma-buf/st-dma-fence-chain.c

diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 9c190026bfab..995e05f609ff 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_UDMABUF)   += udmabuf.o
 
 dmabuf_selftests-y := \
selftest.o \
-   st-dma-fence.o
+   st-dma-fence.o \
+   st-dma-fence-chain.o
 
 obj-$(CONFIG_DMABUF_SELFTESTS) += dmabuf_selftests.o
diff --git a/drivers/dma-buf/selftests.h b/drivers/dma-buf/selftests.h
index 5320386f02e5..55918ef9adab 100644
--- a/drivers/dma-buf/selftests.h
+++ b/drivers/dma-buf/selftests.h
@@ -11,3 +11,4 @@
  */
 selftest(sanitycheck, __sanitycheck__) /* keep first (igt selfcheck) */
 selftest(dma_fence, dma_fence)
+selftest(dma_fence_chain, dma_fence_chain)
diff --git a/drivers/dma-buf/st-dma-fence-chain.c 
b/drivers/dma-buf/st-dma-fence-chain.c
new file mode 100644
index ..bd08ba67b03b
--- /dev/null
+++ b/drivers/dma-buf/st-dma-fence-chain.c
@@ -0,0 +1,713 @@
+// SPDX-License-Identifier: MIT
+
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "selftest.h"
+
+static struct kmem_cache *slab_fences;
+
+static inline struct mock_fence {
+   struct dma_fence base;
+   spinlock_t lock;
+} *to_mock_fence(struct dma_fence *f) {
+   return container_of(f, struct mock_fence, base);
+}
+
+static const char *mock_name(struct dma_fence *f)
+{
+   return "mock";
+}
+
+static void mock_fence_release(struct dma_fence *f)
+{
+   kmem_cache_free(slab_fences, to_mock_fence(f));
+}
+
+static const struct dma_fence_ops mock_ops = {
+   .get_driver_name = mock_name,
+   .get_timeline_name = mock_name,
+   .release = mock_fence_release,
+};
+
+static struct dma_fence *mock_fence(void)
+{
+   struct mock_fence *f;
+
+   f = kmem_cache_alloc(slab_fences, GFP_KERNEL);
+   if (!f)
+   return NULL;
+
+   spin_lock_init(&f->lock);
+   dma_fence_init(&f->base, &mock_ops, &f->lock, 0, 0);
+
+   return &f->base;
+}
+
+static inline struct mock_chain {
+   struct dma_fence_chain base;
+} *to_mock_chain(struct dma_fence *f) {
+   return container_of(f, struct mock_chain, base.base);
+}
+
+static struct dma_fence *mock_chain(struct dma_fence *prev,
+   struct dma_fence *fence,
+   u64 seqno)
+{
+   struct mock_chain *f;
+
+   f = kmalloc(sizeof(*f), GFP_KERNEL);
+   if (!f)
+   return NULL;
+
+   dma_fence_chain_init(&f->base,
+dma_fence_get(prev),
+dma_fence_get(fence),
+seqno);
+
+   return &f->base.base;
+}
+
+static int sanitycheck(void *arg)
+{
+   struct dma_fence *f, *chain;
+   int err = 0;
+
+   f = mock_fence();
+   if (!f)
+   return -ENOMEM;
+
+   chain = mock_chain(NULL, f, 1);
+   if (!chain)
+   err = -ENOMEM;
+
+   dma_fence_signal(f);
+   dma_fence_put(f);
+
+   dma_fence_put(chain);
+
+   return err;
+}
+
+struct fence_chains {
+   unsigned int chain_length;
+   struct dma_fence **fences;
+   struct dma_fence **chains;
+
+   struct dma_fence *tail;
+};
+
+static uint64_t seqno_inc(unsigned int i)
+{
+   return i + 1;
+}
+
+static int fence_chains_init(struct fence_chains *fc, unsigned int count,
+uint64_t (*seqno_fn)(unsigned int))
+{
+   unsigned int i;
+   int err = 0;
+
+   fc->chains = kvmalloc_array(count, sizeof(*fc->chains),
+   GFP_KERNEL | __GFP_ZERO);
+   if (!fc->chains)
+   return -ENOMEM;
+
+   fc->fences = kvmalloc_array(count, sizeof(*fc->fences),
+   GFP_KERNEL | __GFP_ZERO);
+   if (!fc->fences) {
+   err = -ENOMEM;
+   goto err_chains;
+   }
+
+   fc->tail = NULL;
+   for (i = 0; i < count; i++) {
+   fc->fences[i] = mock_fence();
+   if (!fc->fences[i]) {
+   err = -ENOMEM;
+   goto unwind;
+   }
+
+   fc->chains[i] = mock_chain(fc->tail,
+  fc->fences[i],
+  seqno_fn(i));
+   if (!fc->chains[i]) {
+   err = -ENOMEM;
+   goto unwind;
+   }
+
+

[PATCH 1/3] dma-buf: Prettify typecasts for dma-fence-chain

[Chris Wilson]

Inside dma-fence-chain, we use a cmpxchg on an RCU-protected pointer. To
avoid the sparse warning for using the RCU pointer directly, we have to
cast away the __rcu annotation. However, we don't need to use void*
everywhere and can stick to the dma_fence*.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/dma-buf/dma-fence-chain.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c
index 44a741677d25..3d123502ff12 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -62,7 +62,8 @@ struct dma_fence *dma_fence_chain_walk(struct dma_fence 
*fence)
replacement = NULL;
}
 
-   tmp = cmpxchg((void **)&chain->prev, (void *)prev, (void 
*)replacement);
+   tmp = cmpxchg((struct dma_fence __force **)&chain->prev,
+ prev, replacement);
if (tmp == prev)
dma_fence_put(tmp);
else
-- 
2.20.1

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

Re: [PATCH v10 2/2] drm/bridge: Add NWL MIPI DSI host controller support

[Guido Günther]

Hi Sam,
Thanks for having a look! Comments below:

On Wed, Apr 08, 2020 at 07:52:52PM +0200, Sam Ravnborg wrote:
> Hi Guido.
> 
> On Fri, Mar 20, 2020 at 07:49:10PM +0100, Guido Günther wrote:
> > This adds initial support for the NWL MIPI DSI Host controller found on
> > i.MX8 SoCs.
> > 
> > It adds support for the i.MX8MQ but the same IP can be found on
> > e.g. the i.MX8QXP.
> > 
> > It has been tested on the Librem 5 devkit using mxsfb.
> > 
> > Signed-off-by: Guido Günther 
> > Co-developed-by: Robert Chiras 
> > Signed-off-by: Robert Chiras 
> > Tested-by: Robert Chiras 
> > Tested-by: Martin Kepplinger 
> 
> I took an extra look at the driver (procastinating).
> checkpatch (--strict):
> -:511: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
> #511: FILE: drivers/gpu/drm/bridge/nwl-dsi.c:442:
> + DRM_DEV_ERROR(
> 
> -:671: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
> "msg->rx_buf"
> #671: FILE: drivers/gpu/drm/bridge/nwl-dsi.c:602:
> + msg->rx_len > 0 && msg->rx_buf != NULL)
> 
> -:868: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
> #868: FILE: drivers/gpu/drm/bridge/nwl-dsi.c:799:
> + ret = phy_mipi_dphy_get_default_config(
> 
> -:1021: WARNING:RETURN_VOID: void function return statements are not 
> generally useful
> #1021: FILE: drivers/gpu/drm/bridge/nwl-dsi.c:952:
> + return;
> +}
> 
> -:1067: CHECK:LINE_SPACING: Please don't use multiple blank lines
> #1067: FILE: drivers/gpu/drm/bridge/nwl-dsi.c:998:
> +
> +

All fixed.

> 
> A few more details below.
> 
>   Sam
> 
> 
> > ---
> >  drivers/gpu/drm/bridge/Kconfig   |   16 +
> >  drivers/gpu/drm/bridge/Makefile  |1 +
> >  drivers/gpu/drm/bridge/nwl-dsi.c | 1218 ++
> >  drivers/gpu/drm/bridge/nwl-dsi.h |  144 
> >  4 files changed, 1379 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi.c
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi.h
> > 
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index aaed2347ace9..6ec945f837b8 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -58,6 +58,22 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> >   to DP++. This is used with the i.MX6 imx-ldb
> >   driver. You are likely to say N here.
> >  
> > +config DRM_NWL_MIPI_DSI
> > +   tristate "Northwest Logic MIPI DSI Host controller"
> > +   depends on DRM
> > +   depends on COMMON_CLK
> > +   depends on OF && HAS_IOMEM
> > +   select DRM_KMS_HELPER
> > +   select DRM_MIPI_DSI
> > +   select DRM_PANEL_BRIDGE
> > +   select GENERIC_PHY_MIPI_DPHY
> > +   select MFD_SYSCON
> > +   select MULTIPLEXER
> > +   select REGMAP_MMIO
> > +   help
> > + This enables the Northwest Logic MIPI DSI Host controller as
> > + for example found on NXP's i.MX8 Processors.
> > +
> >  config DRM_NXP_PTN3460
> > tristate "NXP PTN3460 DP/LVDS bridge"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile 
> > b/drivers/gpu/drm/bridge/Makefile
> > index 6fb062b5b0f0..b04ac2dfa22c 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -18,6 +18,7 @@ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> >  obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> >  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> >  obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
> > +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
> >  
> >  obj-y += analogix/
> >  obj-y += synopsys/
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c 
> > b/drivers/gpu/drm/bridge/nwl-dsi.c
> > new file mode 100644
> > index ..12d1c5548e2d
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> > @@ -0,0 +1,1218 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * i.MX8 NWL MIPI DSI host driver
> > + *
> > + * Copyright (C) 2017 NXP
> > + * Copyright (C) 2020 Purism SPC
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> Header file is not used - drop
> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> > +#include 
> Header file is not used - drop
> > +
> > +#include 
> 
> > +#include 
> Header file not used

All dropped. Thanks!

> 
> > +
> > +#include "nwl-dsi.h"
> > +
> > +#define DRV_NAME "nwl-dsi"
> > +
> > +/* i.MX8 NWL quirks */
> > +/* i.MX8MQ errata E11418 */
> > +#define E11418_HS_MODE_QUIRK   BIT(0)
> > +
> > +#define NWL_DSI_MIPI_FIFO_TIMEOUT msecs_to_jiffies(500)
> Should the defines be moved to the header file?

I've used this rules: register layout (that is chip properties)
go to the header file while defines specific to this very driver
go into the .c file. Hope that makes sense.

> > +
> > +enum transfer_direction {
> > +   DSI_PACKET_SEND,
> > +   DSI_PACKET_RECEIVE,
> > +};
> > +
> > 

Re: [PATCH v10 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller

[Guido Günther]

Hi,
On Wed, Apr 08, 2020 at 07:32:58PM +0200, Sam Ravnborg wrote:
> Hi Guido.
> 
> We discussed this binding briefly on IRC:
> 
> 19:28  port 0 is defined as
> 19:28  +  Input port node to receive pixel data from the
> 19:28  +  display controller. Exactly one endpoint must be
> 19:28  +  specified.
> 19:28  then there's two endpoints,

There's only a single one allowed due to

  
https://lore.kernel.org/linux-arm-kernel/c86b7ca2-7799-eafd-c380-e4b551520...@samsung.com/

Back when doing that i couldn't figure out a way how to specify this but
I've figured it out now.
Cheers,
 -- Guido

> 
> 
> On Fri, Mar 20, 2020 at 07:49:09PM +0100, Guido Günther wrote:
> > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
> > 
> > Signed-off-by: Guido Günther 
> > Tested-by: Robert Chiras 
> > Reviewed-by: Rob Herring 
> > Acked-by: Sam Ravnborg 
> > ---
> >  .../bindings/display/bridge/nwl-dsi.yaml  | 216 ++
> >  1 file changed, 216 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml 
> > b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> > new file mode 100644
> > index ..ec1e7e12719d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> > @@ -0,0 +1,216 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Northwest Logic MIPI-DSI controller on i.MX SoCs
> > +
> > +maintainers:
> > +  - Guido Gúnther 
> > +  - Robert Chiras 
> > +
> > +description: |
> > +  NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi 
> > bridge for
> > +  the SOCs NWL MIPI-DSI host controller.
> > +
> > +properties:
> > +  compatible:
> > +const: fsl,imx8mq-nwl-dsi
> > +
> > +  reg:
> > +maxItems: 1
> > +
> > +  interrupts:
> > +maxItems: 1
> > +
> > +  '#address-cells':
> > +const: 1
> > +
> > +  '#size-cells':
> > +const: 0
> > +
> > +  clocks:
> > +items:
> > +  - description: DSI core clock
> > +  - description: RX_ESC clock (used in escape mode)
> > +  - description: TX_ESC clock (used in escape mode)
> > +  - description: PHY_REF clock
> > +  - description: LCDIF clock
> > +
> > +  clock-names:
> > +items:
> > +  - const: core
> > +  - const: rx_esc
> > +  - const: tx_esc
> > +  - const: phy_ref
> > +  - const: lcdif
> > +
> > +  mux-controls:
> > +description:
> > +  mux controller node to use for operating the input mux
> > +
> > +  phys:
> > +maxItems: 1
> > +description:
> > +  A phandle to the phy module representing the DPHY
> > +
> > +  phy-names:
> > +items:
> > +  - const: dphy
> > +
> > +  power-domains:
> > +maxItems: 1
> > +
> > +  resets:
> > +items:
> > +  - description: dsi byte reset line
> > +  - description: dsi dpi reset line
> > +  - description: dsi esc reset line
> > +  - description: dsi pclk reset line
> > +
> > +  reset-names:
> > +items:
> > +  - const: byte
> > +  - const: dpi
> > +  - const: esc
> > +  - const: pclk
> > +
> > +  ports:
> > +type: object
> > +description:
> > +  A node containing DSI input & output port nodes with endpoint
> > +  definitions as documented in
> > +  Documentation/devicetree/bindings/graph.txt.
> > +properties:
> > +  port@0:
> > +type: object
> > +description:
> > +  Input port node to receive pixel data from the
> > +  display controller. Exactly one endpoint must be
> > +  specified.
> > +properties:
> > +  '#address-cells':
> > +const: 1
> > +
> > +  '#size-cells':
> > +const: 0
> > +
> > +  endpoint@0:
> > +description: sub-node describing the input from LCDIF
> > +type: object
> > +
> > +  endpoint@1:
> > +description: sub-node describing the input from DCSS
> > +type: object
> > +
> > +  reg:
> > +const: 0
> > +
> > +required:
> > +  - '#address-cells'
> > +  - '#size-cells'
> > +  - reg
> > +additionalProperties: false
> > +
> > +  port@1:
> > +type: object
> > +description:
> > +  DSI output port node to the panel or the next bridge
> > +  in the chain
> > +
> > +  '#address-cells':
> > +const: 1
> > +
> > +  '#size-cells':
> > +const: 0
> > +
> > +required:
> > +  - '#address-cells'
> > +  - '#size-cells'
> > +  - port@0
> > +  - port@1
> > +
> > +additionalProperties: false
> 
> For the casual reader the above confuses.
> Assuming the binding is correct, 

[PATCH v11 2/2] drm/bridge: Add NWL MIPI DSI host controller support

[Guido Günther]

This adds initial support for the NWL MIPI DSI Host controller found on
i.MX8 SoCs.

It adds support for the i.MX8MQ but the same IP can be found on
e.g. the i.MX8QXP.

It has been tested on the Librem 5 devkit using mxsfb.

Signed-off-by: Guido Günther 
Co-developed-by: Robert Chiras 
Signed-off-by: Robert Chiras 
Tested-by: Robert Chiras 
Tested-by: Martin Kepplinger 
Reviewed-by: Fabio Estevam 
---
 drivers/gpu/drm/bridge/Kconfig   |   16 +
 drivers/gpu/drm/bridge/Makefile  |1 +
 drivers/gpu/drm/bridge/nwl-dsi.c | 1213 ++
 drivers/gpu/drm/bridge/nwl-dsi.h |  144 
 4 files changed, 1374 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/nwl-dsi.c
 create mode 100644 drivers/gpu/drm/bridge/nwl-dsi.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index aaed2347ace9..6ec945f837b8 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -58,6 +58,22 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW
  to DP++. This is used with the i.MX6 imx-ldb
  driver. You are likely to say N here.
 
+config DRM_NWL_MIPI_DSI
+   tristate "Northwest Logic MIPI DSI Host controller"
+   depends on DRM
+   depends on COMMON_CLK
+   depends on OF && HAS_IOMEM
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL_BRIDGE
+   select GENERIC_PHY_MIPI_DPHY
+   select MFD_SYSCON
+   select MULTIPLEXER
+   select REGMAP_MMIO
+   help
+ This enables the Northwest Logic MIPI DSI Host controller as
+ for example found on NXP's i.MX8 Processors.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 6fb062b5b0f0..b04ac2dfa22c 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
 obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
 obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
+obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
 
 obj-y += analogix/
 obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
new file mode 100644
index ..b14d725bf609
--- /dev/null
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -0,0 +1,1213 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX8 NWL MIPI DSI host driver
+ *
+ * Copyright (C) 2017 NXP
+ * Copyright (C) 2020 Purism SPC
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "nwl-dsi.h"
+
+#define DRV_NAME "nwl-dsi"
+
+/* i.MX8 NWL quirks */
+/* i.MX8MQ errata E11418 */
+#define E11418_HS_MODE_QUIRK   BIT(0)
+
+#define NWL_DSI_MIPI_FIFO_TIMEOUT msecs_to_jiffies(500)
+
+enum transfer_direction {
+   DSI_PACKET_SEND,
+   DSI_PACKET_RECEIVE,
+};
+
+#define NWL_DSI_ENDPOINT_LCDIF 0
+#define NWL_DSI_ENDPOINT_DCSS 1
+
+struct nwl_dsi_plat_clk_config {
+   const char *id;
+   struct clk *clk;
+   bool present;
+};
+
+struct nwl_dsi_transfer {
+   const struct mipi_dsi_msg *msg;
+   struct mipi_dsi_packet packet;
+   struct completion completed;
+
+   int status; /* status of transmission */
+   enum transfer_direction direction;
+   bool need_bta;
+   u8 cmd;
+   u16 rx_word_count;
+   size_t tx_len; /* in bytes */
+   size_t rx_len; /* in bytes */
+};
+
+struct nwl_dsi {
+   struct drm_bridge bridge;
+   struct mipi_dsi_host dsi_host;
+   struct drm_bridge *panel_bridge;
+   struct device *dev;
+   struct phy *phy;
+   union phy_configure_opts phy_cfg;
+   unsigned int quirks;
+
+   struct regmap *regmap;
+   int irq;
+   /*
+* The DSI host controller needs this reset sequence according to NWL:
+* 1. Deassert pclk reset to get access to DSI regs
+* 2. Configure DSI Host and DPHY and enable DPHY
+* 3. Deassert ESC and BYTE resets to allow host TX operations)
+* 4. Send DSI cmds to configure peripheral (handled by panel drv)
+* 5. Deassert DPI reset so DPI receives pixels and starts sending
+*DSI data
+*
+* TODO: Since panel_bridges do their DSI setup in enable we
+* currently have 4. and 5. swapped.
+*/
+   struct reset_control *rst_byte;
+   struct reset_control *rst_esc;
+   struct reset_control *rst_dpi;
+   struct reset_control *rst_pclk;
+   struct mux_control *mux;
+
+   /* DSI clocks */
+   struct clk *phy_ref_clk;
+   struct clk *rx_esc_clk;
+   struct clk *tx_esc_clk;
+   struct clk *core_clk;
+   /*
+* hardware bug: the i.MX8MQ needs this clock on during reset
+* even when not us

[PATCH v11 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller

[Guido Günther]

The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.

Signed-off-by: Guido Günther 
Tested-by: Robert Chiras 
Reviewed-by: Rob Herring 
Acked-by: Sam Ravnborg 
Reviewed-by: Fabio Estevam 
---
 .../bindings/display/bridge/nwl-dsi.yaml  | 226 ++
 1 file changed, 226 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml 
b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
new file mode 100644
index ..8aff2d68fc33
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
@@ -0,0 +1,226 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Northwest Logic MIPI-DSI controller on i.MX SoCs
+
+maintainers:
+  - Guido Gúnther 
+  - Robert Chiras 
+
+description: |
+  NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi bridge 
for
+  the SOCs NWL MIPI-DSI host controller.
+
+properties:
+  compatible:
+const: fsl,imx8mq-nwl-dsi
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  '#address-cells':
+const: 1
+
+  '#size-cells':
+const: 0
+
+  clocks:
+items:
+  - description: DSI core clock
+  - description: RX_ESC clock (used in escape mode)
+  - description: TX_ESC clock (used in escape mode)
+  - description: PHY_REF clock
+  - description: LCDIF clock
+
+  clock-names:
+items:
+  - const: core
+  - const: rx_esc
+  - const: tx_esc
+  - const: phy_ref
+  - const: lcdif
+
+  mux-controls:
+description:
+  mux controller node to use for operating the input mux
+
+  phys:
+maxItems: 1
+description:
+  A phandle to the phy module representing the DPHY
+
+  phy-names:
+items:
+  - const: dphy
+
+  power-domains:
+maxItems: 1
+
+  resets:
+items:
+  - description: dsi byte reset line
+  - description: dsi dpi reset line
+  - description: dsi esc reset line
+  - description: dsi pclk reset line
+
+  reset-names:
+items:
+  - const: byte
+  - const: dpi
+  - const: esc
+  - const: pclk
+
+  ports:
+type: object
+description:
+  A node containing DSI input & output port nodes with endpoint
+  definitions as documented in
+  Documentation/devicetree/bindings/graph.txt.
+properties:
+  port@0:
+type: object
+description:
+  Input port node to receive pixel data from the
+  display controller. Exactly one endpoint must be
+  specified.
+properties:
+  '#address-cells':
+const: 1
+
+  '#size-cells':
+const: 0
+
+  endpoint@0:
+description: sub-node describing the input from LCDIF
+type: object
+
+  endpoint@1:
+description: sub-node describing the input from DCSS
+type: object
+
+  reg:
+const: 0
+
+required:
+  - '#address-cells'
+  - '#size-cells'
+  - reg
+
+oneOf:
+  - required:
+  - endpoint@0
+  - required:
+  - endpoint@1
+
+additionalProperties: false
+
+  port@1:
+type: object
+description:
+  DSI output port node to the panel or the next bridge
+  in the chain
+
+  '#address-cells':
+const: 1
+
+  '#size-cells':
+const: 0
+
+required:
+  - '#address-cells'
+  - '#size-cells'
+  - port@0
+  - port@1
+
+additionalProperties: false
+
+patternProperties:
+  "^panel@[0-9]+$":
+type: object
+
+required:
+  - '#address-cells'
+  - '#size-cells'
+  - clock-names
+  - clocks
+  - compatible
+  - interrupts
+  - mux-controls
+  - phy-names
+  - phys
+  - ports
+  - reg
+  - reset-names
+  - resets
+
+additionalProperties: false
+
+examples:
+ - |
+
+   #include 
+   #include 
+   #include 
+
+   mipi_dsi: mipi_dsi@30a0 {
+  #address-cells = <1>;
+  #size-cells = <0>;
+  compatible = "fsl,imx8mq-nwl-dsi";
+  reg = <0x30A0 0x300>;
+  clocks = <&clk IMX8MQ_CLK_DSI_CORE>,
+   <&clk IMX8MQ_CLK_DSI_AHB>,
+   <&clk IMX8MQ_CLK_DSI_IPG_DIV>,
+   <&clk IMX8MQ_CLK_DSI_PHY_REF>,
+   <&clk IMX8MQ_CLK_LCDIF_PIXEL>;
+  clock-names = "core", "rx_esc", "tx_esc", "phy_ref", "lcdif";
+  interrupts = ;
+  mux-controls = <&mux 0>;
+  power-domains = <&pgc_mipi>;
+  resets = <&src IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N>,
+   <&src IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N>,
+   <&src IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N>,
+ 

[PATCH v11 0/2] drm: bridge: Add NWL MIPI DSI host controller support

[Guido Günther]

This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
SoCs.

It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
I only have imx8mq boards to test I omitted the platform data for other SoCs.

The code is based on NXPs BSP so I added Robert Chiras as Co-authored-by.

The most notable changes over the BSP driver are
 - Calculate HS mode timing from phy_configure_opts_mipi_dphy
 - Perform all clock setup via DT
 - Merge nwl-imx and nwl drivers
 - Add B0 silion revision quirk
 - become a bridge driver to hook into mxsfb / dcss
   imx-display-subsystem so it makes sense to make it drive a bridge for dsi as
   well).
 - Use panel_bridge to attach the panel
 - Use multiplex framework instead of accessing syscon directly

This has been tested on a Librem 5 devkit using mxsfb with Robert's patches[1]
and the mainline rocktech-jh057n00900 DSI panel driver on next-20200317 and on
the Librem5 with the a Mantix MLAF057WE51-X DSI panel driver (not yet mainline)
The DCSS (submitted for mainline inclusion now too) can also act as input
source.

Changes from v10:
- Per review comments by Sam Ravnborg
  https://lore.kernel.org/linux-arm-kernel/20200408175252.gb24...@ravnborg.org/
  - Drop unused headers
  - Fix 'check-patch --strict' findings
  - Print error when DRM_BRIDGE_ATTACH_NO_CONNECTOR is passed
- Per review comment by Laurent Pinchart
  https://lore.kernel.org/linux-arm-kernel/20200408173258.ga24...@ravnborg.org/
  - There's only one endpoint allowed at a time, add a restriction for that.
- Add Reviewed-by from Fabio Estevam
  
https://lore.kernel.org/linux-arm-kernel/CAOMZO5Dhy7ahcR-S=QG=pumxxa8hnqowpg0tdfyeu_levdh...@mail.gmail.com/
  
https://lore.kernel.org/linux-arm-kernel/caomzo5du-zp7wxm2eh8wafock_kwomgh57ayjrbb0pzhuaa...@mail.gmail.com/
- Move to next-20200408

Changes from v9:
- Per review comments by Sam Ravnborg
  https://lore.kernel.org/dri-devel/20200318214639.ga...@ravnborg.org/
  - Drop header-test-y since kernel lost support
  - Handle drm_bridge_attach's new flags argument
  - Add Acked-by: to binding patch, thanks!
- Move to next-20200319

Changes from v8:
- Per review comments by Robert Chiras
  https://lore.kernel.org/dri-devel/1575366594.6423.61.ca...@nxp.com/
  - don't mix DSI host and bridge initialization
  - only select output source once
  - defer probe when panel is not ready to fix usage as a module
  - use correct reset sequence as described by Robert
(and provided by NWL)
  - use mode->clock instead of mode->crtc_clock
- Add tested by from Martin Kepplinger, thanks!
- Drop platform specific data (as suggested previously by Laurent Pinchart and
  Andrzej Hajda) since imx8q* needs another set of abstractions with the new
  reset sequence and that's easier to do when adding imx8q* support rather then
  adding wrong abstraction now.
- Update bindings to use proper clock and irq names to make the example match
  reality more closely.
- Use `fallthrough;` instead of /* Fall through */ in switch statements
- Move to next-20200226

Changes from v7:
- Drop reset quirk. It's not needed with mxsfb and sometimes triggers a shifted 
display.

Changes from v6:
- Per review comments by Andrzej Hajda
  
https://lore.kernel.org/linux-arm-kernel/c86b7ca2-7799-eafd-c380-e4b551520...@samsung.com/
  - Drop spare empty line
  - handle nwl_dsi_write errors
  - better handle read errors
  - unwind in case of error in nwl_dsi_enable
  - use bridge_to_dsi() instead of accessing driver_private
  - don't log on -EPROBEDEFER when fething the reset controller
  - use endpoint number to determine input
- Spotted by kbuild test robot 
  
https://lore.kernel.org/linux-arm-kernel/201909230644.qfskbnf9%25...@intel.com/
  Use signed return type for nwl_dsi_get_dpi_pixel_format
- Drop connector type from drm_panel_bridge_add
- Don't forget to set an error value on dsi reads

Changes from v5:
- Per review comments by Andrzej Hajda
  https://lists.freedesktop.org/archives/dri-devel/2019-September/235281.html
  - Fix include file ordering
  - Add a comment to nwl_dsi_platform_data that will allow to add support
at least for the i.MX8QM
  - Merge driver into a single file plus the register defs in a separate header
- Make more functions and structs static

Changes from v4:
- Collect Reviewed-by: from Rob Herring, thanks!
  https://lists.freedesktop.org/archives/dri-devel/2019-September/233979.html
- Spotted by kbuild test robot 
  https://lists.freedesktop.org/archives/dri-devel/2019-September/233860.html
  https://lists.freedesktop.org/archives/dri-devel/2019-September/233863.html
  - fix format string for size_t
  - Use DIV64_U64_ROUND_UP to fix build on 32 bit architectures
We can't use simple shift sind d and n are similar in size and
we need full precision
- Fix debug cfg_t_post debug print out
- Avoid PSEC_PER_SEC
- Move timeout / overflow handling out of nwl_dsi_finish_transm

Re: [PATCH v1] staging: fbtft: fb_st7789v: Initialize the Display

[Dan Carpenter]

On Thu, Apr 09, 2020 at 11:25:32AM +0200, Oliver Graute wrote:
> From: Oliver Graute 
> 
> Set Gamma Values and Register Values for the HSD20_IPS
> 
> Signed-off-by: Oliver Graute 
> ---
>  drivers/staging/fbtft/fb_st7789v.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/fbtft/fb_st7789v.c 
> b/drivers/staging/fbtft/fb_st7789v.c
> index 84c5af2dc9a0..b0aa96b703a8 100644
> --- a/drivers/staging/fbtft/fb_st7789v.c
> +++ b/drivers/staging/fbtft/fb_st7789v.c
> @@ -17,8 +17,8 @@
>  #define DRVNAME "fb_st7789v"
>  
>  #define DEFAULT_GAMMA \
> - "70 2C 2E 15 10 09 48 33 53 0B 19 18 20 25\n" \
> - "70 2C 2E 15 10 09 48 33 53 0B 19 18 20 25"
> + "D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \
> + "D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33"

How do you know this won't break someone else's setup?

>  
>  /**
>   * enum st7789v_command - ST7789V display controller commands
> @@ -83,13 +83,13 @@ static int init_display(struct fbtft_par *par)
>   /* set pixel format to RGB-565 */
>   write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, MIPI_DCS_PIXEL_FMT_16BIT);
>  
> - write_reg(par, PORCTRL, 0x08, 0x08, 0x00, 0x22, 0x22);
> + write_reg(par, PORCTRL, 0x05, 0x05, 0x00, 0x33, 0x33);

Without knowing anything at all about this driver, it feels like this
should be:

if (new_hardware)
write_reg(par, PORCTRL, 0x05, 0x05, 0x00, 0x33, 0x33);
else
write_reg(par, PORCTRL, 0x08, 0x08, 0x00, 0x22, 0x22);

Same comment for the rest of the patch.

regards,
dan carpenter

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

Re: [PATCH v9 0/5] drm/tidss: New driver for TI Keystone platform Display SubSystem

[Tomi Valkeinen]

On 07/04/2020 19:44, Sam Ravnborg wrote:

On Tue, Apr 07, 2020 at 04:18:20PM +0300, Tomi Valkeinen wrote:

Hi Jyri,

On 27/01/2020 18:00, Jyri Sarha wrote:

This is intended to be the last patch series. I'll apply these trough
drm-misc-next tomorrow.


Were these ever merged?


See 32a1795f57eecc3974901760400618571c9d357f
("drm/tidss: New driver for TI Keystone platform Display SubSystem")
Ah, sorry, I replied to a wrong thread. I was looking for the patch that adds the DT data to the soc 
dts file... Somehow I thought it's in this series.


 Tomi

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

Re: [PATCH v1] staging: fbtft: fb_st7789v: enabled inversion

[Dan Carpenter]

On Thu, Apr 09, 2020 at 11:24:05AM +0200, Oliver Graute wrote:
> From: Oliver Graute 
> 
> Enable inversion mode

What the heck is an inversion mode and why would you want it?

regards,
dasn carpenter

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

Re: [PATCH v1] staging: fbtft: fb_st7789v: enabled inversion

[Dan Carpenter]

On Thu, Apr 09, 2020 at 11:24:05AM +0200, Oliver Graute wrote:
> From: Oliver Graute 
> 
> Enable inversion mode
> 
> Signed-off-by: Oliver Graute 
> ---
>  drivers/staging/fbtft/fb_st7789v.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/staging/fbtft/fb_st7789v.c 
> b/drivers/staging/fbtft/fb_st7789v.c
> index 3c3f387936e8..84c5af2dc9a0 100644
> --- a/drivers/staging/fbtft/fb_st7789v.c
> +++ b/drivers/staging/fbtft/fb_st7789v.c
> @@ -120,6 +120,10 @@ static int init_display(struct fbtft_par *par)
>   write_reg(par, PWCTRL1, 0xA4, 0xA1);
>  
>   write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
> +
> + /* enable inversion mode */
> + write_reg(par, 0x21);

Use the define and delete the comment.

write_reg(par, MIPI_DCS_ENTER_INVERT_MODE);

regards,
dan carpenter

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

Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc

[Daniel Vetter]

On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
 wrote:
>
> On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > If this code was broken for non-coherent caches a crude powerpc hack
> > > isn't going to help anyone else.  Remove the hack as it is the last
> > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
> >
> > Well Ben added this to make stuff work on ppc, ofc the home grown dma
> > layer in drm from back then isn't going to work in other places. I guess
> > should have at least an ack from him, in case anyone still cares about
> > this on ppc. Adding Ben to cc.
>
> This was due to some drivers (radeon ?) trying to use vmalloc pages for
> coherent DMA, which means on those 4xx powerpc's need to be non-cached.
>
> There were machines using that (440 based iirc), though I honestly
> can't tell if anybody still uses any of it.

agp subsystem still seems to happily do that (vmalloc memory for
device access), never having been ported to dma apis (or well
converted to iommu drivers, which they kinda are really). So I think
this all still works exactly as back then, even with the kms radeon
drivers. Question really is whether we have users left, and I have no
clue about that either.

Now if these boxes didn't ever have agp then I think we can get away
with deleting this, since we've already deleted the legacy radeon
driver. And that one used vmalloc for everything. The new kms one does
use the dma-api if the gpu isn't connected through agp.
-Daniel

> Cheers,
> Ben.
>
> > -Daniel
> >
> > >
> > > Signed-off-by: Christoph Hellwig 
> > > ---
> > >  drivers/gpu/drm/drm_scatter.c | 11 +--
> > >  1 file changed, 1 insertion(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
> > > index ca520028b2cb..f4e6184d1877 100644
> > > --- a/drivers/gpu/drm/drm_scatter.c
> > > +++ b/drivers/gpu/drm/drm_scatter.c
> > > @@ -43,15 +43,6 @@
> > >
> > >  #define DEBUG_SCATTER 0
> > >
> > > -static inline void *drm_vmalloc_dma(unsigned long size)
> > > -{
> > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > > -   return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
> > > -#else
> > > -   return vmalloc_32(size);
> > > -#endif
> > > -}
> > > -
> > >  static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > >  {
> > > struct page *page;
> > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void 
> > > *data,
> > > return -ENOMEM;
> > > }
> > >
> > > -   entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > > +   entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > > if (!entry->virtual) {
> > > kfree(entry->busaddr);
> > > kfree(entry->pagelist);
> > > --
> > > 2.25.1
> > >
> >
> >
>


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

Re: [PATCH 0/2] drm: bridge: simple-bridge: Enable usage with DRM bridge connector helper

[Sergei Shtylyov]

Hello!

On 09.04.2020 3:36, Laurent Pinchart wrote:


This small patch series enables usage of the simple-bridge driver with
the DRM bridge connector helper (drm_bridge_connector.c). Patch 1/2
starts by simplifying the driver by delegating DDC handling to the next
bridge in the chain, and patch 2/2 makes the connector creation
optional.

I will continue converting existing bridge drivers to this new model,
starting with the adv7511, rcar-lvds and dw-hdmi bridges. Anyone willing
to give a


   What? :-)


and converting additional bridge drivers is more than welcome
:-)

Laurent Pinchart (2):
   drm: bridge: simple-bridge: Delegate operations to next bridge
   drm: bridge: simple-bridge: Make connector creation optional

  drivers/gpu/drm/bridge/simple-bridge.c | 107 +
  1 file changed, 36 insertions(+), 71 deletions(-)


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

Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc

[Benjamin Herrenschmidt]

On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > If this code was broken for non-coherent caches a crude powerpc hack
> > isn't going to help anyone else.  Remove the hack as it is the last
> > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
> 
> Well Ben added this to make stuff work on ppc, ofc the home grown dma
> layer in drm from back then isn't going to work in other places. I guess
> should have at least an ack from him, in case anyone still cares about
> this on ppc. Adding Ben to cc.

This was due to some drivers (radeon ?) trying to use vmalloc pages for
coherent DMA, which means on those 4xx powerpc's need to be non-cached.

There were machines using that (440 based iirc), though I honestly
can't tell if anybody still uses any of it.

Cheers,
Ben.

> -Daniel
> 
> > 
> > Signed-off-by: Christoph Hellwig 
> > ---
> >  drivers/gpu/drm/drm_scatter.c | 11 +--
> >  1 file changed, 1 insertion(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
> > index ca520028b2cb..f4e6184d1877 100644
> > --- a/drivers/gpu/drm/drm_scatter.c
> > +++ b/drivers/gpu/drm/drm_scatter.c
> > @@ -43,15 +43,6 @@
> >  
> >  #define DEBUG_SCATTER 0
> >  
> > -static inline void *drm_vmalloc_dma(unsigned long size)
> > -{
> > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > -   return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
> > -#else
> > -   return vmalloc_32(size);
> > -#endif
> > -}
> > -
> >  static void drm_sg_cleanup(struct drm_sg_mem * entry)
> >  {
> > struct page *page;
> > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void 
> > *data,
> > return -ENOMEM;
> > }
> >  
> > -   entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > +   entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > if (!entry->virtual) {
> > kfree(entry->busaddr);
> > kfree(entry->pagelist);
> > -- 
> > 2.25.1
> > 
> 
> 

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

Re: [RFC 0/6] Regressions for "imply" behavior change

[Jani Nikula]

On Wed, 08 Apr 2020, Jason Gunthorpe  wrote:
> On Wed, Apr 08, 2020 at 10:49:48PM +0200, Arnd Bergmann wrote:
>> On Wed, Apr 8, 2020 at 10:38 PM Nicolas Pitre  wrote:
>> > On Wed, 8 Apr 2020, Arnd Bergmann wrote:
>> > > I have created workarounds for the Kconfig files, which now stop using
>> > > imply and do something else in each case. I don't know whether there was
>> > > a bug in the kconfig changes that has led to allowing configurations that
>> > > were not meant to be legal even with the new semantics, or if the Kconfig
>> > > files have simply become incorrect now and the tool works as expected.
>> >
>> > In most cases it is the code that has to be fixed. It typically does:
>> >
>> > if (IS_ENABLED(CONFIG_FOO))
>> > foo_init();
>> >
>> > Where it should rather do:
>> >
>> > if (IS_REACHABLE(CONFIG_FOO))
>> > foo_init();
>> >
>> > A couple of such patches have been produced and queued in their
>> > respective trees already.
>> 
>> I try to use IS_REACHABLE() only as a last resort, as it tends to
>> confuse users when a subsystem is built as a module and already
>> loaded but something relying on that subsystem does not use it.
>> 
>> In the six patches I made, I had to use IS_REACHABLE() once,
>> for the others I tended to use a Kconfig dependency like
>> 
>> 'depends on FOO || FOO=n'
>
> It is unfortunate kconfig doesn't have a language feature for this
> idiom, as the above is confounding without a lot of kconfig knowledge
>
>> I did come up with the IS_REACHABLE() macro originally, but that
>> doesn't mean I think it's a good idea to use it liberally ;-)
>
> It would be nice to have some uniform policy here
>
> I also don't like the IS_REACHABLE solution, it makes this more
> complicated, not less..

Just chiming "me too" here.

IS_REACHABLE() is not a solution, it's a hack to hide a dependency link
problem under the carpet, in a way that is difficult for the user to
debug and figure out.

The user thinks they've enabled a feature, but it doesn't get used
anyway, because a builtin depends on something that is a module and
therefore not reachable. Can someone please give me an example where
that kind of behaviour is desirable?

AFAICT IS_REACHABLE() is becoming more and more common in the kernel,
but arguably it's just making more undesirable configurations
possible. Configurations that should simply be blocked by using suitable
dependencies on the Kconfig level.

For example, you have two graphics drivers, one builtin and another
module. Then you have backlight as a module. Using IS_REACHABLE(),
backlight would work in one driver, but not the other. I'm sure there is
the oddball person who finds this desirable, but the overwhelming
majority would just make the deps such that either you make all of them
modules, or also require backlight to be builtin.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 17/28] mm: remove the prot argument from vm_map_ram

[Gao Xiang]

On Wed, Apr 08, 2020 at 01:59:15PM +0200, Christoph Hellwig wrote:
> This is always GFP_KERNEL - for long term mappings with other properties
> vmap should be used.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c   | 2 +-
>  drivers/media/common/videobuf2/videobuf2-dma-sg.c  | 3 +--
>  drivers/media/common/videobuf2/videobuf2-vmalloc.c | 3 +--
>  fs/erofs/decompressor.c| 2 +-

For EROFS part,

Acked-by: Gao Xiang 

Thanks,
Gao Xiang

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

Re: [PATCH 03/35] docs: fix broken references to text files

[Marc Zyngier]

On Wed,  8 Apr 2020 17:45:55 +0200
Mauro Carvalho Chehab  wrote:

> Several references got broken due to txt to ReST conversion.
> 
> Several of them can be automatically fixed with:
> 
>   scripts/documentation-file-ref-check --fix
> 
> Reviewed-by: Mathieu Poirier  # 
> hwtracing/coresight/Kconfig
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/virt/kvm/arm/pvtime.rst|  2 +-
>  virt/kvm/arm/vgic/vgic-mmio-v3.c |  2 +-
>  virt/kvm/arm/vgic/vgic.h |  4 ++--

Acked-by: Marc Zyngier  # kvm/arm64

M.
-- 
Jazz is not dead. It just smells funny...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

[Randy Dunlap]

On 4/8/20 8:36 AM, Christoph Hellwig wrote:
> On Wed, Apr 08, 2020 at 08:15:19AM -0700, Matthew Wilcox wrote:
>  config ZSMALLOC_PGTABLE_MAPPING
>   bool "Use page table mapping to access object in zsmalloc"
> - depends on ZSMALLOC
> + depends on ZSMALLOC=y

 It's a bool so this shouldn't matter... not needed.
>>>
>>> My mm/Kconfig has:
>>>
>>> config ZSMALLOC
>>> tristate "Memory allocator for compressed pages"
>>> depends on MMU
>>>
>>> which I think means it can be modular, no?
>>
>> Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch
>> is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become
>> 'n' instead of 'y'.
> 
> In Linus' tree you can select PGTABLE_MAPPING=y with ZSMALLOC=m,
> and that fits my understanding of the kbuild language.  With this
> patch I can't anymore.
> 

Makes sense. thanks.

-- 
~Randy

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

[PATCH v2] drm: mediatek: fix device passed to cmdq

[Hsin-Yi Wang]

drm device is now probed from mmsys. We need to use mmsys device to get gce
nodes. Fix following errors:

[0.740068] mediatek-drm mediatek-drm.1.auto: error -2 can't parse 
gce-client-reg property (0)
[0.748721] mediatek-drm mediatek-drm.1.auto: error -2 can't parse 
gce-client-reg property (0)
...
[2.659645] mediatek-drm mediatek-drm.1.auto: failed to request channel
[2.666270] mediatek-drm mediatek-drm.1.auto: failed to request channel

Fixes: 1d367541aded ("soc / drm: mediatek: Fix mediatek-drm device probing")
Signed-off-by: Hsin-Yi Wang 
Reviewed-by: Enric Balletbo i Serra 
Tested-by: Enric Balletbo i Serra 
---
The patch is based on
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git
branch v5.6-next/soc

Change log:
v1->v2:
align with 60fa8c13ab1a ("drm/mediatek: Move gce event property to mutex device 
node")
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 ++-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 615a54e60fe2..7247c6f87f4a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -822,7 +822,8 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
 
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
mtk_crtc->cmdq_client =
-   cmdq_mbox_create(dev, drm_crtc_index(&mtk_crtc->base),
+   cmdq_mbox_create(mtk_crtc->mmsys_dev,
+drm_crtc_index(&mtk_crtc->base),
 2000);
if (IS_ERR(mtk_crtc->cmdq_client)) {
dev_dbg(dev, "mtk_crtc %d failed to create mailbox client, 
writing register by CPU now\n",
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index e2bb0d19ef99..28418e5b83ee 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -517,7 +517,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
goto err_node;
}
 
-   ret = mtk_ddp_comp_init(dev, node, comp, comp_id, NULL);
+   ret = mtk_ddp_comp_init(dev->parent, node, comp, 
comp_id, NULL);
if (ret) {
of_node_put(node);
goto err_node;
-- 
2.26.0.292.g33ef6b2f38-goog

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

Re: [RFC 0/6] Regressions for "imply" behavior change

[Saeed Mahameed]

On Wed, 2020-04-08 at 16:38 -0400, Nicolas Pitre wrote:
> On Wed, 8 Apr 2020, Arnd Bergmann wrote:
> 
> > Hi everyone,
> > 
> > I've just restarted doing randconfig builds on top of mainline
> > Linux and
> > found a couple of regressions with missing dependency from the
> > recent
> > change in the "imply" keyword in Kconfig, presumably these two
> > patches:
> > 
> > 3a9dd3ecb207 kconfig: make 'imply' obey the direct dependency
> > def2fbffe62c kconfig: allow symbols implied by y to become m
> > 
> > I have created workarounds for the Kconfig files, which now stop
> > using
> > imply and do something else in each case. I don't know whether
> > there was
> > a bug in the kconfig changes that has led to allowing
> > configurations that
> > were not meant to be legal even with the new semantics, or if the
> > Kconfig
> > files have simply become incorrect now and the tool works as
> > expected.
> 
> In most cases it is the code that has to be fixed. It typically does:
> 
>   if (IS_ENABLED(CONFIG_FOO))
>   foo_init();
> 
> Where it should rather do:
> 
>   if (IS_REACHABLE(CONFIG_FOO))
>   foo_init();
> 
> A couple of such patches have been produced and queued in their 
> respective trees already.
> 
> 

Yes i have a patch in mlx5-net branch converting IS_ENABLED to
IS_REACHABLE in mlx5, i will post it today.

Thanks,
Saeed.

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

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Christophe Leroy]

Le 08/04/2020 à 01:32, Benjamin Herrenschmidt a écrit :

On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:

Benjamin Herrenschmidt  writes:

On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:

I have no attachment to 40x, and I'd certainly be happy to have
less
code in the tree, we struggle to keep even the modern platforms
well
maintained.

At the same time I don't want to render anyone's hardware
obsolete
unnecessarily. But if there's really no one using 40x then we
should
remove it, it could well be broken already.

So I guess post a series to do the removal and we'll see if
anyone
speaks up.


We shouldn't remove 40x completely. Just remove the Xilinx 405
stuff.


Congratulations on becoming the 40x maintainer!


Didn't I give you my last 40x system ? :-) IBM still put 40x cores
inside POWER chips no ?



According to Wikipedia (https://en.wikipedia.org/wiki/PowerPC_400), 405 
cores are used in modern equipments (how modern ?), however 403 has 
never reached the market.


Can we start removing 403 stuff ? That's not a lot, but still.

Does anybody knows anything about this ERRATUM 77 stuff ? Is that still 
an issue with all 405 cores or has this been fixed long time ago and can 
be removed ?


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

Re: [PATCH/RFC 4/6] dt-bindings: display: rockchip: dw-hdmi: Convert binding to YAML

[Maxime Ripard]

On Wed, Apr 08, 2020 at 02:45:52PM +0300, Laurent Pinchart wrote:
> Hi Maxime,
>
> On Tue, Apr 07, 2020 at 09:12:51AM +0200, Maxime Ripard wrote:
> > On Mon, Apr 06, 2020 at 08:50:28PM +0300, Laurent Pinchart wrote:
> > > On Mon, Apr 06, 2020 at 07:09:15PM +0200, Maxime Ripard wrote:
> > > > On Mon, Apr 06, 2020 at 02:19:27PM +0300, Laurent Pinchart wrote:
> > > > > On Mon, Apr 06, 2020 at 10:00:32AM +0200, Maxime Ripard wrote:
> > > > > > On Mon, Apr 06, 2020 at 02:39:33AM +0300, Laurent Pinchart wrote:
> > > > > > > Convert the Rockchip HDMI TX text binding to YAML.
> > > > > > >
> > > > > > > Signed-off-by: Laurent Pinchart 
> > > > > > > 
> > > > > > > ---
> > > > > > >  .../display/rockchip/dw_hdmi-rockchip.txt |  74 
> > > > > > >  .../display/rockchip/rockchip,dw-hdmi.yaml| 178 
> > > > > > > ++
> > > > > > >  2 files changed, 178 insertions(+), 74 deletions(-)
> > > > > > >  delete mode 100644 
> > > > > > > Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > > > > > >  create mode 100644 
> > > > > > > Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> > > > > > >
> > > > > > > diff --git 
> > > > > > > a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > > > > > >  
> > > > > > > b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > > > > > > deleted file mode 100644
> > > > > > > index 3d32ce137e7f..
> > > > > > > --- 
> > > > > > > a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > > > > > > +++ /dev/null
> > > > > > > @@ -1,74 +0,0 @@
> > > > > > > -Rockchip DWC HDMI TX Encoder
> > > > > > > -
> > > > > > > -
> > > > > > > -The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX 
> > > > > > > controller IP
> > > > > > > -with a companion PHY IP.
> > > > > > > -
> > > > > > > -These DT bindings follow the Synopsys DWC HDMI TX bindings 
> > > > > > > defined in
> > > > > > > -Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt 
> > > > > > > with the
> > > > > > > -following device-specific properties.
> > > > > > > -
> > > > > > > -
> > > > > > > -Required properties:
> > > > > > > -
> > > > > > > -- compatible: should be one of the following:
> > > > > > > - "rockchip,rk3228-dw-hdmi"
> > > > > > > - "rockchip,rk3288-dw-hdmi"
> > > > > > > - "rockchip,rk3328-dw-hdmi"
> > > > > > > - "rockchip,rk3399-dw-hdmi"
> > > > > > > -- reg: See dw_hdmi.txt.
> > > > > > > -- reg-io-width: See dw_hdmi.txt. Shall be 4.
> > > > > > > -- interrupts: HDMI interrupt number
> > > > > > > -- clocks: See dw_hdmi.txt.
> > > > > > > -- clock-names: Shall contain "iahb" and "isfr" as defined in 
> > > > > > > dw_hdmi.txt.
> > > > > > > -- ports: See dw_hdmi.txt. The DWC HDMI shall have a single port 
> > > > > > > numbered 0
> > > > > > > -  corresponding to the video input of the controller. The port 
> > > > > > > shall have two
> > > > > > > -  endpoints, numbered 0 and 1, connected respectively to the 
> > > > > > > vopb and vopl.
> > > > > > > -- rockchip,grf: Shall reference the GRF to mux vopl/vopb.
> > > > > > > -
> > > > > > > -Optional properties
> > > > > > > -
> > > > > > > -- ddc-i2c-bus: The HDMI DDC bus can be connected to either a 
> > > > > > > system I2C master
> > > > > > > -  or the functionally-reduced I2C master contained in the DWC 
> > > > > > > HDMI. When
> > > > > > > -  connected to a system I2C master this property contains a 
> > > > > > > phandle to that
> > > > > > > -  I2C master controller.
> > > > > > > -- clock-names: See dw_hdmi.txt. The "cec" clock is optional.
> > > > > > > -- clock-names: May contain "cec" as defined in dw_hdmi.txt.
> > > > > > > -- clock-names: May contain "grf", power for grf io.
> > > > > > > -- clock-names: May contain "vpll", external clock for some hdmi 
> > > > > > > phy.
> > > > > > > -- phys: from general PHY binding: the phandle for the PHY device.
> > > > > > > -- phy-names: Should be "hdmi" if phys references an external phy.
> > > > > > > -
> > > > > > > -Optional pinctrl entry:
> > > > > > > -- If you have both a "unwedge" and "default" pinctrl entry, 
> > > > > > > dw_hdmi
> > > > > > > -  will switch to the unwedge pinctrl state for 10ms if it ever 
> > > > > > > gets an
> > > > > > > -  i2c timeout.  It's intended that this unwedge pinctrl entry 
> > > > > > > will
> > > > > > > -  cause the SDA line to be driven low to work around a hardware
> > > > > > > -  errata.
> > > > > > > -
> > > > > > > -Example:
> > > > > > > -
> > > > > > > -hdmi: hdmi@ff98 {
> > > > > > > - compatible = "rockchip,rk3288-dw-hdmi";
> > > > > > > - reg = <0xff98 0x2>;
> > > > > > > - reg-io-width = <4>;
> > > > > > > - ddc-i2c-bus = <&i2c5>;
> > > > > > > - rockchip,grf = <&grf>;
> > > > > > > - interrupts = ;
> > > > > > > - clocks = <&cru  PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
> > > > > > > - clock-names = "iahb", "isf

Re: [PATCH 1/2] drm/panel: NT39016: Add support for multiple modes

[Paul Cercueil]

Hi Sam,


Le mer. 8 avril 2020 à 12:04, Sam Ravnborg  a écrit 
:

Hi Paul.

On Wed, Apr 08, 2020 at 11:58:29AM +0200, Paul Cercueil wrote:
 Add support for multiple drm_display_mode entries. This will allow 
to

 add a 50 Hz mode later.

 Signed-off-by: Paul Cercueil 

Patch looks good.

Could we please use lower case in the $subject?


You mean 's/Add/add/' or the panel name as well?

-Paul


Acked-by: Sam Ravnborg 

I asume you will apply yourself.

Sam


 ---
  drivers/gpu/drm/panel/panel-novatek-nt39016.c | 33 
+--

  1 file changed, 23 insertions(+), 10 deletions(-)

 diff --git a/drivers/gpu/drm/panel/panel-novatek-nt39016.c 
b/drivers/gpu/drm/panel/panel-novatek-nt39016.c

 index a470810f7dbe..f1286cf6528b 100644
 --- a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
 +++ b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
 @@ -49,7 +49,8 @@ enum nt39016_regs {
  #define NT39016_SYSTEM_STANDBYBIT(1)

  struct nt39016_panel_info {
 -  struct drm_display_mode display_mode;
 +  const struct drm_display_mode *display_modes;
 +  unsigned int num_modes;
u16 width_mm, height_mm;
u32 bus_format, bus_flags;
  };
 @@ -212,15 +213,22 @@ static int nt39016_get_modes(struct drm_panel 
*drm_panel,

struct nt39016 *panel = to_nt39016(drm_panel);
const struct nt39016_panel_info *panel_info = panel->panel_info;
struct drm_display_mode *mode;
 +  unsigned int i;

 -	mode = drm_mode_duplicate(connector->dev, 
&panel_info->display_mode);

 -  if (!mode)
 -  return -ENOMEM;
 +  for (i = 0; i < panel_info->num_modes; i++) {
 +  mode = drm_mode_duplicate(connector->dev,
 +&panel_info->display_modes[i]);
 +  if (!mode)
 +  return -ENOMEM;
 +
 +  drm_mode_set_name(mode);

 -  drm_mode_set_name(mode);
 +  mode->type = DRM_MODE_TYPE_DRIVER;
 +  if (panel_info->num_modes == 1)
 +  mode->type |= DRM_MODE_TYPE_PREFERRED;

 -  mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
 -  drm_mode_probed_add(connector, mode);
 +  drm_mode_probed_add(connector, mode);
 +  }

connector->display_info.bpc = 8;
connector->display_info.width_mm = panel_info->width_mm;
 @@ -230,7 +238,7 @@ static int nt39016_get_modes(struct drm_panel 
*drm_panel,

 &panel_info->bus_format, 1);
connector->display_info.bus_flags = panel_info->bus_flags;

 -  return 1;
 +  return panel_info->num_modes;
  }

  static const struct drm_panel_funcs nt39016_funcs = {
 @@ -316,8 +324,8 @@ static int nt39016_remove(struct spi_device 
*spi)

return 0;
  }

 -static const struct nt39016_panel_info kd035g6_info = {
 -  .display_mode = {
 +static const struct drm_display_mode kd035g6_display_modes[] = {
 +  {
.clock = 6000,
.hdisplay = 320,
.hsync_start = 320 + 10,
 @@ -330,6 +338,11 @@ static const struct nt39016_panel_info 
kd035g6_info = {

.vrefresh = 60,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
},
 +};
 +
 +static const struct nt39016_panel_info kd035g6_info = {
 +  .display_modes = kd035g6_display_modes,
 +  .num_modes = ARRAY_SIZE(kd035g6_display_modes),
.width_mm = 71,
.height_mm = 53,
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 --
 2.25.1



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

Re: [RFC 0/6] Regressions for "imply" behavior change

[Jason Gunthorpe]

On Wed, Apr 08, 2020 at 10:49:48PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 8, 2020 at 10:38 PM Nicolas Pitre  wrote:
> > On Wed, 8 Apr 2020, Arnd Bergmann wrote:
> > > I have created workarounds for the Kconfig files, which now stop using
> > > imply and do something else in each case. I don't know whether there was
> > > a bug in the kconfig changes that has led to allowing configurations that
> > > were not meant to be legal even with the new semantics, or if the Kconfig
> > > files have simply become incorrect now and the tool works as expected.
> >
> > In most cases it is the code that has to be fixed. It typically does:
> >
> > if (IS_ENABLED(CONFIG_FOO))
> > foo_init();
> >
> > Where it should rather do:
> >
> > if (IS_REACHABLE(CONFIG_FOO))
> > foo_init();
> >
> > A couple of such patches have been produced and queued in their
> > respective trees already.
> 
> I try to use IS_REACHABLE() only as a last resort, as it tends to
> confuse users when a subsystem is built as a module and already
> loaded but something relying on that subsystem does not use it.
> 
> In the six patches I made, I had to use IS_REACHABLE() once,
> for the others I tended to use a Kconfig dependency like
> 
> 'depends on FOO || FOO=n'

It is unfortunate kconfig doesn't have a language feature for this
idiom, as the above is confounding without a lot of kconfig knowledge

> I did come up with the IS_REACHABLE() macro originally, but that
> doesn't mean I think it's a good idea to use it liberally ;-)

It would be nice to have some uniform policy here

I also don't like the IS_REACHABLE solution, it makes this more
complicated, not less..

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

[PATCH 1/7] drm/bridge: ps8640: Get the EDID from eDP control

[Enric Balletbo i Serra]

The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
.get_edid callback and set the flag to indicate the core to use it.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/bridge/parade-ps8640.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index d3a53442d449..956b76e0a44d 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
return ret;
 }
 
+static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
+  struct drm_connector *connector)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+   return drm_get_edid(connector,
+   ps_bridge->page[PAGE0_DP_CNTL]->adapter);
+}
+
 static const struct drm_bridge_funcs ps8640_bridge_funcs = {
.attach = ps8640_bridge_attach,
+   .get_edid = ps8640_bridge_get_edid,
.post_disable = ps8640_post_disable,
.pre_enable = ps8640_pre_enable,
 };
@@ -296,6 +306,8 @@ static int ps8640_probe(struct i2c_client *client)
 
ps_bridge->bridge.funcs = &ps8640_bridge_funcs;
ps_bridge->bridge.of_node = dev->of_node;
+   ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
+   ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
 
ps_bridge->page[PAGE0_DP_CNTL] = client;
 
-- 
2.25.1

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

[PATCH 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

[Enric Balletbo i Serra]

Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index f9706f306275..a36c86e174f4 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -184,6 +185,7 @@ struct mtk_dsi {
struct drm_bridge bridge;
struct drm_bridge *panel_bridge;
struct drm_bridge *next_bridge;
+   struct drm_connector *connector;
struct phy *phy;
 
void __iomem *regs;
@@ -983,10 +985,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, 
struct mtk_dsi *dsi)
 */
dsi->encoder.possible_crtcs = 1;
 
-   ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
+   ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
+   DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret)
goto err_cleanup_encoder;
 
+   dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
+   if (IS_ERR(dsi->connector)) {
+   DRM_ERROR("Unable to create bridge connector\n");
+   ret = PTR_ERR(dsi->connector);
+   goto err_cleanup_encoder;
+   }
+   drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
+
return 0;
 
 err_cleanup_encoder:
@@ -1145,6 +1156,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
 
dsi->bridge.funcs = &mtk_dsi_bridge_funcs;
dsi->bridge.of_node = dev->of_node;
+   dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
 
drm_bridge_add(&dsi->bridge);
 
-- 
2.25.1

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

[PATCH 5/7] drm/mediatek: mtk_dsi: Use simple encoder

[Enric Balletbo i Serra]

The mtk_dsi driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 3400d6686c85..48361c1e9f34 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mtk_drm_ddp_comp.h"
 
@@ -788,15 +789,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
dsi->enabled = false;
 }
 
-static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
-{
-   drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
-   .destroy = mtk_dsi_encoder_destroy,
-};
-
 static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
*dsi);
 static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
 
@@ -1126,8 +1118,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, 
struct mtk_dsi *dsi)
 {
int ret;
 
-   ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
-  DRM_MODE_ENCODER_DSI, NULL);
+   ret = drm_simple_encoder_init(drm, &dsi->encoder,
+ DRM_MODE_ENCODER_DSI);
if (ret) {
DRM_ERROR("Failed to encoder init to drm\n");
return ret;
-- 
2.25.1

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

[PATCH v12 01/11] drm/i915: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.duty_cycle's
datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
to handle a 64-bit dividend.

Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Chris Wilson 
Cc: "Ville Syrjälä" 
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org

Signed-off-by: Guru Das Srinagesh 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 7b3ec6eb..b45eabf 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1877,7 +1877,7 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
 
panel->backlight.min = 0; /* 0% */
panel->backlight.max = 100; /* 100% */
-   panel->backlight.level = DIV_ROUND_UP(
+   panel->backlight.level = DIV_ROUND_UP_ULL(
 pwm_get_duty_cycle(panel->backlight.pwm) * 100,
 CRC_PMIC_PWM_PERIOD_NS);
panel->backlight.enabled = panel->backlight.level != 0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

drm/mcde: Checking for a failed platform_get_irq() call in mcde_probe()

[Markus Elfring]

Hello,

I have taken another look at the implementation of the function “mcde_probe”.
A software analysis approach points the following source code out for
further development considerations.
https://elixir.bootlin.com/linux/v5.6.2/source/drivers/gpu/drm/mcde/mcde_drv.c#L401
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/mcde/mcde_drv.c?id=f5e94d10e4c468357019e5c28d48499f677b284f#n402

irq = platform_get_irq(pdev, 0);
if (!irq) {
ret = -EINVAL;
goto clk_disable;
}


The software documentation is providing the following information
for the used programming interface.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/platform.c?id=f5e94d10e4c468357019e5c28d48499f677b284f#n221
https://elixir.bootlin.com/linux/v5.6.2/source/drivers/base/platform.c#L202

“…
 * Return: IRQ number on success, negative error number on failure.
…”

Would you like to reconsider the shown condition check?

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

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

[Randy Dunlap]

On 4/8/20 8:15 AM, Matthew Wilcox wrote:
> On Wed, Apr 08, 2020 at 05:12:03PM +0200, Peter Zijlstra wrote:
>> On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote:
>>> Hi,
>>>
>>> On 4/8/20 4:59 AM, Christoph Hellwig wrote:
 diff --git a/mm/Kconfig b/mm/Kconfig
 index 36949a9425b8..614cc786b519 100644
 --- a/mm/Kconfig
 +++ b/mm/Kconfig
 @@ -702,7 +702,7 @@ config ZSMALLOC
  
  config ZSMALLOC_PGTABLE_MAPPING
bool "Use page table mapping to access object in zsmalloc"
 -  depends on ZSMALLOC
 +  depends on ZSMALLOC=y
>>>
>>> It's a bool so this shouldn't matter... not needed.
>>
>> My mm/Kconfig has:
>>
>> config ZSMALLOC
>>  tristate "Memory allocator for compressed pages"
>>  depends on MMU
>>
>> which I think means it can be modular, no?

ack. I misread it.

> Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch
> is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become
> 'n' instead of 'y'.

sigh, I wish that I had meant that. :)

thanks.

-- 
~Randy

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

Re: [PATCH 18/28] mm: enforce that vmap can't map pages executable

[Mark Rutland]

On Wed, Apr 08, 2020 at 01:59:16PM +0200, Christoph Hellwig wrote:
> To help enforcing the W^X protection don't allow remapping existing
> pages as executable.
> 
> Based on patch from Peter Zijlstra .
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/x86/include/asm/pgtable_types.h | 6 ++
>  include/asm-generic/pgtable.h| 4 
>  mm/vmalloc.c | 2 +-
>  3 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/pgtable_types.h 
> b/arch/x86/include/asm/pgtable_types.h
> index 947867f112ea..2e7c442cc618 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -282,6 +282,12 @@ typedef struct pgprot { pgprotval_t pgprot; } pgprot_t;
>  
>  typedef struct { pgdval_t pgd; } pgd_t;
>  
> +static inline pgprot_t pgprot_nx(pgprot_t prot)
> +{
> + return __pgprot(pgprot_val(prot) | _PAGE_NX);
> +}
> +#define pgprot_nx pgprot_nx
> +
>  #ifdef CONFIG_X86_PAE

I reckon for arm64 we can do similar in our :

#define pgprot_nx(pgprot_t prot) \
__pgprot_modify(prot, 0, PTE_PXN)

... matching the style of our existing pgprot_*() modifier helpers.

Mark.

>  
>  /*
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 329b8c8ca703..8c5f9c29698b 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -491,6 +491,10 @@ static inline int arch_unmap_one(struct mm_struct *mm,
>  #define flush_tlb_fix_spurious_fault(vma, address) flush_tlb_page(vma, 
> address)
>  #endif
>  
> +#ifndef pgprot_nx
> +#define pgprot_nx(prot)  (prot)
> +#endif
> +
>  #ifndef pgprot_noncached
>  #define pgprot_noncached(prot)   (prot)
>  #endif
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 7356b3f07bd8..334c75251ddb 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2390,7 +2390,7 @@ void *vmap(struct page **pages, unsigned int count,
>   if (!area)
>   return NULL;
>  
> - if (map_kernel_range((unsigned long)area->addr, size, prot,
> + if (map_kernel_range((unsigned long)area->addr, size, pgprot_nx(prot),
>   pages) < 0) {
>   vunmap(area->addr);
>   return NULL;
> -- 
> 2.25.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

[Matthew Wilcox]

On Wed, Apr 08, 2020 at 05:12:03PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote:
> > Hi,
> > 
> > On 4/8/20 4:59 AM, Christoph Hellwig wrote:
> > > diff --git a/mm/Kconfig b/mm/Kconfig
> > > index 36949a9425b8..614cc786b519 100644
> > > --- a/mm/Kconfig
> > > +++ b/mm/Kconfig
> > > @@ -702,7 +702,7 @@ config ZSMALLOC
> > >  
> > >  config ZSMALLOC_PGTABLE_MAPPING
> > >   bool "Use page table mapping to access object in zsmalloc"
> > > - depends on ZSMALLOC
> > > + depends on ZSMALLOC=y
> > 
> > It's a bool so this shouldn't matter... not needed.
> 
> My mm/Kconfig has:
> 
> config ZSMALLOC
>   tristate "Memory allocator for compressed pages"
>   depends on MMU
> 
> which I think means it can be modular, no?

Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch
is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become
'n' instead of 'y'.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/panel: NT39016: Add support for multiple modes

[Paul Cercueil]

Add support for multiple drm_display_mode entries. This will allow to
add a 50 Hz mode later.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/panel/panel-novatek-nt39016.c | 33 +--
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-novatek-nt39016.c 
b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
index a470810f7dbe..f1286cf6528b 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
@@ -49,7 +49,8 @@ enum nt39016_regs {
 #define NT39016_SYSTEM_STANDBY BIT(1)
 
 struct nt39016_panel_info {
-   struct drm_display_mode display_mode;
+   const struct drm_display_mode *display_modes;
+   unsigned int num_modes;
u16 width_mm, height_mm;
u32 bus_format, bus_flags;
 };
@@ -212,15 +213,22 @@ static int nt39016_get_modes(struct drm_panel *drm_panel,
struct nt39016 *panel = to_nt39016(drm_panel);
const struct nt39016_panel_info *panel_info = panel->panel_info;
struct drm_display_mode *mode;
+   unsigned int i;
 
-   mode = drm_mode_duplicate(connector->dev, &panel_info->display_mode);
-   if (!mode)
-   return -ENOMEM;
+   for (i = 0; i < panel_info->num_modes; i++) {
+   mode = drm_mode_duplicate(connector->dev,
+ &panel_info->display_modes[i]);
+   if (!mode)
+   return -ENOMEM;
+
+   drm_mode_set_name(mode);
 
-   drm_mode_set_name(mode);
+   mode->type = DRM_MODE_TYPE_DRIVER;
+   if (panel_info->num_modes == 1)
+   mode->type |= DRM_MODE_TYPE_PREFERRED;
 
-   mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
-   drm_mode_probed_add(connector, mode);
+   drm_mode_probed_add(connector, mode);
+   }
 
connector->display_info.bpc = 8;
connector->display_info.width_mm = panel_info->width_mm;
@@ -230,7 +238,7 @@ static int nt39016_get_modes(struct drm_panel *drm_panel,
 &panel_info->bus_format, 1);
connector->display_info.bus_flags = panel_info->bus_flags;
 
-   return 1;
+   return panel_info->num_modes;
 }
 
 static const struct drm_panel_funcs nt39016_funcs = {
@@ -316,8 +324,8 @@ static int nt39016_remove(struct spi_device *spi)
return 0;
 }
 
-static const struct nt39016_panel_info kd035g6_info = {
-   .display_mode = {
+static const struct drm_display_mode kd035g6_display_modes[] = {
+   {
.clock = 6000,
.hdisplay = 320,
.hsync_start = 320 + 10,
@@ -330,6 +338,11 @@ static const struct nt39016_panel_info kd035g6_info = {
.vrefresh = 60,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
},
+};
+
+static const struct nt39016_panel_info kd035g6_info = {
+   .display_modes = kd035g6_display_modes,
+   .num_modes = ARRAY_SIZE(kd035g6_display_modes),
.width_mm = 71,
.height_mm = 53,
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
-- 
2.25.1

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

Re: [RFC 0/6] Regressions for "imply" behavior change

[Nicolas Pitre]

On Wed, 8 Apr 2020, Arnd Bergmann wrote:

> On Wed, Apr 8, 2020 at 10:38 PM Nicolas Pitre  wrote:
> > On Wed, 8 Apr 2020, Arnd Bergmann wrote:
> > > I have created workarounds for the Kconfig files, which now stop using
> > > imply and do something else in each case. I don't know whether there was
> > > a bug in the kconfig changes that has led to allowing configurations that
> > > were not meant to be legal even with the new semantics, or if the Kconfig
> > > files have simply become incorrect now and the tool works as expected.
> >
> > In most cases it is the code that has to be fixed. It typically does:
> >
> > if (IS_ENABLED(CONFIG_FOO))
> > foo_init();
> >
> > Where it should rather do:
> >
> > if (IS_REACHABLE(CONFIG_FOO))
> > foo_init();
> >
> > A couple of such patches have been produced and queued in their
> > respective trees already.
> 
> I try to use IS_REACHABLE() only as a last resort, as it tends to
> confuse users when a subsystem is built as a module and already
> loaded but something relying on that subsystem does not use it.

Then this is a usage policy issue, not a code correctness issue.

The correctness issue is fixed with IS_REACHABLE(). If you want to 
enforce a usage policy then this goes in Kconfig.

But you still can do both.


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

[PATCH v2 3/3] drm/amd/amdgpu: remove hardcoded module name in prints

[Aurabindo Pillai]

Let format prefixes take care of printing the module name
through pr_fmt and dev_fmt definitions.

Signed-off-by: Aurabindo Pillai 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c  | 2 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c| 2 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c| 2 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c| 2 +-
 6 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index fa8ac9d19..4afd4ef54 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -325,13 +325,13 @@ static int vm_validate_pt_pd_bos(struct amdgpu_vm *vm)
ret = amdgpu_vm_validate_pt_bos(adev, vm, amdgpu_amdkfd_validate,
¶m);
if (ret) {
-   pr_err("amdgpu: failed to validate PT BOs\n");
+   pr_err("failed to validate PT BOs\n");
return ret;
}
 
ret = amdgpu_amdkfd_validate(¶m, pd);
if (ret) {
-   pr_err("amdgpu: failed to validate PD\n");
+   pr_err("failed to validate PD\n");
return ret;
}
 
@@ -340,7 +340,7 @@ static int vm_validate_pt_pd_bos(struct amdgpu_vm *vm)
if (vm->use_cpu_for_update) {
ret = amdgpu_bo_kmap(pd, NULL);
if (ret) {
-   pr_err("amdgpu: failed to kmap PD, ret=%d\n", ret);
+   pr_err("failed to kmap PD, ret=%d\n", ret);
return ret;
}
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b8975857d..0a8c4a266 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1092,7 +1092,7 @@ static void amdgpu_switcheroo_set_state(struct pci_dev 
*pdev, enum vga_switchero
return;
 
if (state == VGA_SWITCHEROO_ON) {
-   pr_info("amdgpu: switched on\n");
+   pr_info("switched on\n");
/* don't suspend or resume card normally */
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
 
@@ -1106,7 +1106,7 @@ static void amdgpu_switcheroo_set_state(struct pci_dev 
*pdev, enum vga_switchero
dev->switch_power_state = DRM_SWITCH_POWER_ON;
drm_kms_helper_poll_enable(dev);
} else {
-   pr_info("amdgpu: switched off\n");
+   pr_info("switched off\n");
drm_kms_helper_poll_disable(dev);
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
amdgpu_device_suspend(dev, true);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index 5ed4227f3..0cc4c67f9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -260,7 +260,7 @@ int amdgpu_irq_init(struct amdgpu_device *adev)
nvec = pci_alloc_irq_vectors(adev->pdev, 1, 1, flags);
if (nvec > 0) {
adev->irq.msi_enabled = true;
-   dev_dbg(adev->dev, "amdgpu: using MSI/MSI-X.\n");
+   dev_dbg(adev->dev, "using MSI/MSI-X.\n");
}
}
 
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
index b20503935..c1a530dbe 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
@@ -858,7 +858,7 @@ static int gmc_v6_0_sw_init(void *handle)
 
r = dma_set_mask_and_coherent(adev->dev, DMA_BIT_MASK(44));
if (r) {
-   dev_warn(adev->dev, "amdgpu: No suitable DMA available.\n");
+   dev_warn(adev->dev, "No suitable DMA available.\n");
return r;
}
adev->need_swiotlb = drm_need_swiotlb(44);
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index 9da9596a3..e8529e244 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -1019,7 +1019,7 @@ static int gmc_v7_0_sw_init(void *handle)
 
r = dma_set_mask_and_coherent(adev->dev, DMA_BIT_MASK(40));
if (r) {
-   pr_warn("amdgpu: No suitable DMA available\n");
+   pr_warn("No suitable DMA available\n");
return r;
}
adev->need_swiotlb = drm_need_swiotlb(40);
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 27d83204f..0aa5b8280 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -1144,7 +1144,7 @@ static int gmc_v8_0_sw_init(void *handle)
 
r = dma_set_mask_and_coh