Re: [PATCH v6 3/3] drm: bridge: cdns-mhdp: add j721e wrapper
Hi Laurent,
On 11/03/2020 22:52, Laurent Pinchart wrote:
+void cdns_mhdp_j721e_enable(struct cdns_mhdp_device *mhdp)
+{
+ /*
+* Eneble VIF_0 and select DPI2 as its input. DSS0 DPI0 is connected
+* to eDP DPI2. This is the only supported SST configuration on
+* J721E.
Without hardware documentation I can't really comment on this, but I'd
like to make sure it doesn't imply that the MHDP has more than one input
and one output.
You can download the TRM for j721e here:
http://www.ti.com/lit/pdf/spruil1
MHDP has one DP output, but 4 inputs to support MST and split/dual panel modes. None of those are
supported by the drivers, but perhaps some thought should be paid to figure out if adding these
features affect the DT bindings.
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 v6 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge
Hi Laurent, On 12/03/2020 00:20, Laurent Pinchart wrote: + ret = load_firmware(mhdp); + if (ret) + goto phy_exit; + + drm_bridge_add(&mhdp->bridge); What if someone starts using the bridge before the firmware is operational ? It seems that you should delay bridge registration until the firmware is loaded. It may make it possible to remove bridge_attached and solve the problem you mention in mhdp_fw_cb(). Handling the fw has been a bit of a pain... This is what we came up with to support all the combinations (built-in/module, fw-userspace-helper/direct load, single-output/multiple-outputs). The idea is that when the driver is loaded and probed (with or without fw), the DP is "ready". If we don't have fw yet, everything looks fine, but the connector stays in disconnected state. When we get the fw, connector will get connected (only if there's a cable connected, of course). If we register the bridge only when we have fw, two things can happen: - If we get the fw only rather late (in case userspace fw helper), a userspace app (e.g. weston) could already have been started, and failed due to there being no DRM card. - If we have two displays from the same display controller, say, DP and HDMI, the HDMI will only be available when the DP is available. If the DP fw, for some reason, cannot be loaded, we never get HDMI. 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: [Nouveau] [PATCH v3 1/4] nouveau/hmm: fix vma range check for migration
I've taken all 4 patches in my tree. Thanks Ralph, Ben. On Wed, 4 Mar 2020 at 10:14, Ralph Campbell wrote: > > find_vma_intersection(mm, start, end) only guarantees that end is greater > than or equal to vma->vm_start but doesn't guarantee that start is > greater than or equal to vma->vm_start. The calculation for the > intersecting range in nouveau_svmm_bind() isn't accounting for this and > can call migrate_vma_setup() with a starting address less than > vma->vm_start. This results in migrate_vma_setup() returning -EINVAL for > the range instead of nouveau skipping that part of the range and migrating > the rest. > > Signed-off-by: Ralph Campbell > --- > drivers/gpu/drm/nouveau/nouveau_svm.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c > b/drivers/gpu/drm/nouveau/nouveau_svm.c > index df9bf1fd1bc0..169320409286 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_svm.c > +++ b/drivers/gpu/drm/nouveau/nouveau_svm.c > @@ -179,6 +179,7 @@ nouveau_svmm_bind(struct drm_device *dev, void *data, > if (!vma) > break; > > + addr = max(addr, vma->vm_start); > next = min(vma->vm_end, end); > /* This is a best effort so we ignore errors */ > nouveau_dmem_migrate_vma(cli->drm, vma, addr, next); > -- > 2.20.1 > > ___ > Nouveau mailing list > nouv...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v2 8/9] media: fsl-viu: Constify ioreadX() iomem argument (as in generic implementation)
On 2/19/20 6:50 PM, Krzysztof Kozlowski wrote: > The ioreadX() helpers have inconsistent interface. On some architectures > void *__iomem address argument is a pointer to const, on some not. > > Implementations of ioreadX() do not modify the memory under the address > so they can be converted to a "const" version for const-safety and > consistency among architectures. > > Signed-off-by: Krzysztof Kozlowski Acked-by: Hans Verkuil Regards, Hans > --- > drivers/media/platform/fsl-viu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/platform/fsl-viu.c > b/drivers/media/platform/fsl-viu.c > index 81a8faedbba6..991d9dc82749 100644 > --- a/drivers/media/platform/fsl-viu.c > +++ b/drivers/media/platform/fsl-viu.c > @@ -34,7 +34,7 @@ > /* Allow building this driver with COMPILE_TEST */ > #if !defined(CONFIG_PPC) && !defined(CONFIG_MICROBLAZE) > #define out_be32(v, a) iowrite32be(a, (void __iomem *)v) > -#define in_be32(a) ioread32be((void __iomem *)a) > +#define in_be32(a) ioread32be((const void __iomem *)a) > #endif > > #define BUFFER_TIMEOUT msecs_to_jiffies(500) /* 0.5 seconds */ > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hmm 0/8] Various error case bug fixes for hmm_range_fault()
From: Jason Gunthorpe The hmm_range_fault() flow is fairly complicated. The scheme allows the caller to specify if it needs a usable result for each page, or if it only needs the current page table status filled in. This mixture of behavior is useful for a caller that wants to build a 'prefetch around fault' algorithm. Although we have no in-tree users of this capability, I am working on having RDMA ODP work in this manner, and removing these bugs from hmm_range_fault() is a necessary step. The basic principles are: - If the caller did not ask for a VA to be valid then hmm_range_fault() should not fail because of that VA - If 0 is returned from hmm_range_fault() then the entire pfns array contains valid data - HMM_PFN_ERROR is set if faulting fails, or if asking for faulting would fail - A 0 return from hmm_range_fault() does not have HMM_PFN_ERROR in any VA's the caller asked to be valid This series does not get there completely, I have a followup series closing some more complex cases. I tested this series using Ralph's hmm tester he posted a while back, other testing would be appreciated. Jason Gunthorpe (8): mm/hmm: add missing unmaps of the ptep during hmm_vma_handle_pte() mm/hmm: don't free the cached pgmap while scanning mm/hmm: do not call hmm_vma_walk_hole() while holding a spinlock mm/hmm: add missing pfns set to hmm_vma_walk_pmd() mm/hmm: add missing call to hmm_range_need_fault() before returning EFAULT mm/hmm: reorganize how !pte_present is handled in hmm_vma_handle_pte() mm/hmm: return -EFAULT when setting HMM_PFN_ERROR on requested valid pages mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL handling mm/hmm.c | 166 ++- 1 file changed, 79 insertions(+), 87 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 3/5] clk / soc: mediatek: Move mt8173 MMSYS to platform driver
From: Matthias Brugger
There is no strong reason for this to use CLK_OF_DECLARE instead of
being a platform driver. Plus, MMSYS provides clocks but also a shared
register space for the mediatek-drm and the mediatek-mdp
driver. So move the MMSYS clocks to a new platform driver and also
create a new MMSYS platform driver in drivers/soc/mediatek that
instantiates the clock driver.
Signed-off-by: Matthias Brugger
Signed-off-by: Enric Balletbo i Serra
---
Changes in v11:
- Leave the clocks part in drivers/clk (clk-mt8173-mm)
- Instantiate the clock driver from the mtk-mmsys driver.
- Add default config option to not break anything.
- Removed the Reviewed-by CK tag as changed the organization.
Changes in v10:
- Renamed to be generic mtk-mmsys
- Add driver data support to be able to support diferent SoCs
Changes in v9:
- Move mmsys to drivers/soc/mediatek (CK)
Changes in v8:
- Be a builtin_platform_driver like other mediatek mmsys drivers.
Changes in v7:
- Free clk_data->clks as well
- Get rid of private data structure
drivers/clk/mediatek/Kconfig | 7 ++
drivers/clk/mediatek/Makefile| 1 +
drivers/clk/mediatek/clk-mt8173-mm.c | 146 +++
drivers/clk/mediatek/clk-mt8173.c| 104 ---
drivers/soc/mediatek/Kconfig | 8 ++
drivers/soc/mediatek/Makefile| 1 +
drivers/soc/mediatek/mtk-mmsys.c | 50 +
7 files changed, 213 insertions(+), 104 deletions(-)
create mode 100644 drivers/clk/mediatek/clk-mt8173-mm.c
create mode 100644 drivers/soc/mediatek/mtk-mmsys.c
diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index ea3c70d1307e..9e28db8125cd 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -274,6 +274,13 @@ config COMMON_CLK_MT8173
---help---
This driver supports MediaTek MT8173 clocks.
+config COMMON_CLK_MT8173_MMSYS
+ bool "Clock driver for MediaTek MT8173 mmsys"
+ depends on COMMON_CLK_MT8173
+ default COMMON_CLK_MT8173
+ help
+ This driver supports MediaTek MT8173 mmsys clocks.
+
config COMMON_CLK_MT8183
bool "Clock driver for MediaTek MT8183"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 8cdb76a5cd71..bb0536942075 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_COMMON_CLK_MT7629_ETHSYS) += clk-mt7629-eth.o
obj-$(CONFIG_COMMON_CLK_MT7629_HIFSYS) += clk-mt7629-hif.o
obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
+obj-$(CONFIG_COMMON_CLK_MT8173_MMSYS) += clk-mt8173-mm.o
obj-$(CONFIG_COMMON_CLK_MT8183) += clk-mt8183.o
obj-$(CONFIG_COMMON_CLK_MT8183_AUDIOSYS) += clk-mt8183-audio.o
obj-$(CONFIG_COMMON_CLK_MT8183_CAMSYS) += clk-mt8183-cam.o
diff --git a/drivers/clk/mediatek/clk-mt8173-mm.c
b/drivers/clk/mediatek/clk-mt8173-mm.c
new file mode 100644
index ..36fa20be77b6
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt8173-mm.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: James Liao
+ */
+
+#include
+#include
+#include
+
+#include "clk-gate.h"
+#include "clk-mtk.h"
+
+#include
+
+static const struct mtk_gate_regs mm0_cg_regs = {
+ .set_ofs = 0x0104,
+ .clr_ofs = 0x0108,
+ .sta_ofs = 0x0100,
+};
+
+static const struct mtk_gate_regs mm1_cg_regs = {
+ .set_ofs = 0x0114,
+ .clr_ofs = 0x0118,
+ .sta_ofs = 0x0110,
+};
+
+#define GATE_MM0(_id, _name, _parent, _shift) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_name = _parent, \
+ .regs = &mm0_cg_regs, \
+ .shift = _shift,\
+ .ops = &mtk_clk_gate_ops_setclr,\
+ }
+
+#define GATE_MM1(_id, _name, _parent, _shift) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_name = _parent, \
+ .regs = &mm1_cg_regs, \
+ .shift = _shift,\
+ .ops = &mtk_clk_gate_ops_setclr,\
+ }
+
+static const struct mtk_gate mt8173_mm_clks[] = {
+ /* MM0 */
+ GATE_MM0(CLK_MM_SMI_COMMON, "mm_smi_common", "mm_sel", 0),
+ GATE_MM0(CLK_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 1),
+ GATE_MM0(CLK_MM_CAM_MDP, "mm_cam_mdp", "mm_sel", 2),
+ GATE_MM0(CLK_MM_MDP_RDMA0, "mm_mdp_rdma0", "mm_sel", 3),
+ GATE_MM0(CLK_MM_MDP_RDMA1, "mm_mdp_rdma1", "mm_sel", 4),
+ GATE_MM0(CLK_MM_MDP_RSZ0,
RE: [PATCH v3 2/2] arm64: dts: renesas: Add HiHope RZ/G2M board with idk-1110wr display
Hi Geert,
Thank you for the review.
> -Original Message-
> From: Geert Uytterhoeven
> Sent: 11 March 2020 10:08
> To: Prabhakar Mahadev Lad
> Cc: Thierry Reding ; Sam Ravnborg
> ; David Airlie ; Daniel Vetter
> ; Rob Herring ; Mark Rutland
> ; Magnus Damm ;
> DRI Development ; open list:OPEN
> FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; Linux Kernel Mailing List ker...@vger.kernel.org>; Linux-Renesas s...@vger.kernel.org>
> Subject: Re: [PATCH v3 2/2] arm64: dts: renesas: Add HiHope RZ/G2M board
> with idk-1110wr display
>
> Hi Lad,
>
> On Tue, Mar 10, 2020 at 9:42 PM Lad Prabhakar lad...@bp.renesas.com> wrote:
> > From: Fabrizio Castro
> >
> > The HiHope RZ/G2M is advertised as compatible with panel idk-1110wr
> > from Advantech, however the panel isn't sold alongside the board.
> > A new dts, adding everything that's required to get the panel to work
> > the HiHope RZ/G2M, is the most convenient way to support the HiHope
> > RZ/G2M when it's connected to the idk-1110wr.
> >
> > Signed-off-by: Fabrizio Castro
> > Acked-by: Laurent Pinchart
> > Signed-off-by: Lad Prabhakar lad...@bp.renesas.com>
>
> Thanks for picking up this patch!
>
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-
> 1110wr.
> > +++ dts
> > @@ -0,0 +1,86 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Device Tree Source for the HiHope RZ/G2M sub board connected to an
> > + * Advantech IDK-1110WR 10.1" LVDS panel
> > + *
> > + * Copyright (C) 2020 Renesas Electronics Corp.
> > + */
> > +
> > +#include "r8a774a1-hihope-rzg2m-ex.dts"
> > +
> > +/ {
> > + backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&pwm0 0 5>;
> > +
> > + brightness-levels = <0 2 8 16 32 64 128 255>;
> > + default-brightness-level = <6>;
> > + };
> > +
> > + panel-lvds {
> > + compatible = "advantech,idk-1110wr", "panel-lvds";
> > +
> > + width-mm = <223>;
> > + height-mm = <125>;
> > +
> > + data-mapping = "jeida-24";
> > +
> > + panel-timing {
> > + /* 1024x600 @60Hz */
> > + clock-frequency = <5120>;
> > + hactive = <1024>;
> > + vactive = <600>;
> > + hsync-len = <240>;
> > + hfront-porch = <40>;
> > + hback-porch = <40>;
> > + vfront-porch = <15>;
> > + vback-porch = <10>;
> > + vsync-len = <10>;
> > + };
> > +
> > + port {
> > + panel_in: endpoint {
> > + remote-endpoint = <&lvds0_out>;
> > + };
> > + };
> > + };
>
> I believe the plan was to include the existing rzg2-advantech-idk-1110wr-
> panel.dtsi instead, to provide the panel-lvds node...
>
Ahha missed it, I'll quickly respin the series fixing it.
> > +};
> > +
> > +&gpio1 {
> > + /*
> > +* When GP1_20 is LOW LVDS0 is connected to the LVDS connector
> > +* When GP1_20 is HIGH LVDS0 is connected to the LT8918L
> > +*/
> > + lvds-connector-en-gpio {
> > + gpio-hog;
> > + gpios = <20 GPIO_ACTIVE_HIGH>;
> > + output-low;
> > + line-name = "lvds-connector-en-gpio";
> > + };
> > +};
> > +
> > +&lvds0 {
> > + status = "okay";
> > +
> > + ports {
> > + port@1 {
> > + lvds0_out: endpoint {
> > + remote-endpoint = <&panel_in>;
> > + };
> > + };
> > + };
> > +};
>
> ... and the lvds_connector endpoint configuration.
>
Agreed.
Cheers,
--Prabhakar
> The rest looks good to me.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-
> m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch,
Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472
Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB
3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg.
no.: DE 14978647
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] dt-bindings: vendor-prefixes: Add Xingbangda
Shenzhen Xingbangda Display Technology Co., Ltd is a company which produces LCD modules. It supplies the LCD panels of the PinePhone series (the developers' kit and the final phone). Add the vendor prefix of it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b8e9ef79cab9..038a2180d34b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1102,6 +1102,8 @@ patternProperties: description: Xiaomi Technology Co., Ltd. "^xillybus,.*": description: Xillybus Ltd. + "^xingbangda,.*": +description: Shenzhen Xingbangda Display Technology Co., Ltd "^xinpeng,.*": description: Shenzhen Xinpeng Technology Co., Ltd "^xlnx,.*": -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 2/3] arch: mips: brcm: Add 7425 flash-edu support
On Wed, 2020-01-22 at 21:33:12 UTC, Kamal Dasu wrote: > Nand controller v5.0 and v6.0 have nand edu blocks that enable > dma nand flash transfers. This allows for faster read and write > access. > > Signed-off-by: Kamal Dasu > Acked-by: Paul Burton > Reviewed-by: Florian Fainelli Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks. Miquel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] display/drm/bridge: tc358775 DSI/LVDS driver
dsi2lvds tc358775 bridge driver added Tested in apq8016, ifc6309 board and panel auo,b101xtn01 Signed-off-by: Vinay Simha BN --- v1: Initial version v2: * Andrzej Hajda review comments incorporated SPDX identifier development debug removed alphabetic order headers u32 instead of unit32_t magic numbers to macros for CLRSI and mux registers ignored return value * Laurent Pinchart review comments incorporated mdelay to usleep_range bus_formats added --- drivers/gpu/drm/bridge/Kconfig| 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/tc358775.c | 688 ++ 3 files changed, 699 insertions(+) create mode 100644 drivers/gpu/drm/bridge/tc358775.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 8397bf7..d5528fa 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -133,6 +133,16 @@ config DRM_TOSHIBA_TC358767 ---help--- Toshiba TC358767 eDP bridge chip driver. +config DRM_TOSHIBA_TC358775 +tristate "Toshiba TC358775 LVDS bridge" +depends on OF +select DRM_KMS_HELPER +select REGMAP_I2C +select DRM_PANEL + select DRM_MIPI_DSI +---help--- + Toshiba TC358775 LVDS bridge chip driver. + config DRM_TI_TFP410 tristate "TI TFP410 DVI/HDMI bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 1eb5376..9b2c512 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o +obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o diff --git a/drivers/gpu/drm/bridge/tc358775.c b/drivers/gpu/drm/bridge/tc358775.c new file mode 100644 index 000..28b828e --- /dev/null +++ b/drivers/gpu/drm/bridge/tc358775.c @@ -0,0 +1,688 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * tc358775 DSI to LVDS bridge driver + * + * Copyright (C) 2020 InforceComputing + * Author: Vinay Simha BN + * + */ +#define DEBUG +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) << (end)) +#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end)) + +/* Registers */ + +/* DSI D-PHY Layer Registers */ +#define D0W_DPHYCONTTX 0x0004 /* Data Lane 0 DPHY Tx Control */ +#define CLW_DPHYCONTRX 0x0020 /* Clock Lane DPHY Rx Control */ +#define D0W_DPHYCONTRX 0x0024 /* Data Lane 0 DPHY Rx Control */ +#define D1W_DPHYCONTRX 0x0028 /* Data Lane 1 DPHY Rx Control */ +#define D2W_DPHYCONTRX 0x002C /* Data Lane 2 DPHY Rx Control */ +#define D3W_DPHYCONTRX 0x0030 /* Data Lane 3 DPHY Rx Control */ +#define COM_DPHYCONTRX 0x0038 /* DPHY Rx Common Control */ +#define CLW_CNTRL 0x0040 /* Clock Lane Control */ +#define D0W_CNTRL 0x0044 /* Data Lane 0 Control */ +#define D1W_CNTRL 0x0048 /* Data Lane 1 Control */ +#define D2W_CNTRL 0x004C /* Data Lane 2 Control */ +#define D3W_CNTRL 0x0050 /* Data Lane 3 Control */ +#define DFTMODE_CNTRL 0x0054 /* DFT Mode Control */ + +/* DSI PPI Layer Registers */ +#define PPI_STARTPPI0x0104 /* START control bit of PPI-TX function. */ +#define PPI_BUSYPPI 0x0108 +#define PPI_LINEINITCNT 0x0110 /* Line Initialization Wait Counter */ +#define PPI_LPTXTIMECNT 0x0114 +#define PPI_LANEENABLE 0x0134 /* Enables each lane at the PPI layer. */ +#define PPI_TX_RX_TA0x013C /* DSI Bus Turn Around timing parameters */ + +/* Analog timer function enable */ +#define PPI_CLS_ATMR0x0140 /* Delay for Clock Lane in LPRX */ +#define PPI_D0S_ATMR0x0144 /* Delay for Data Lane 0 in LPRX */ +#define PPI_D1S_ATMR0x0148 /* Delay for Data Lane 1 in LPRX */ +#define PPI_D2S_ATMR0x014C /* Delay for Data Lane 2 in LPRX */ +#define PPI_D3S_ATMR0x0150 /* Delay for Data Lane 3 in LPRX */ + +#define PPI_D0S_CLRSIPOCOUNT0x0164 /* For lane 0 */ +#define PPI_D1S_CLRSIPOCOUNT0x0168 /* For lane 1 */ +#define PPI_D2S_CLRSIPOCOUNT0x016C /* For lane 2 */ +#define PPI_D3S_CLRSIPOCOUNT0x0170 /* For lane 3 */ + +#define CLS_PRE 0x0180 /* Digital Counter inside of PHY IO */ +#define D0S_PRE 0x0184 /* Digital Counter inside of PHY IO */ +#define D1S_PRE 0x0188 /* Digital Counter inside of PHY IO */ +#define D2S_PRE 0x018C /* Digital Counter inside of PHY IO */ +#define D3S_PRE 0x0190 /* Digital Counter inside of PHY IO */ +#define CLS_PREP0x01A0 /*
[PATCH v4 2/2] arm64: dts: renesas: Add HiHope RZ/G2M board with idk-1110wr display
From: Fabrizio Castro
The HiHope RZ/G2M is advertised as compatible with panel idk-1110wr
from Advantech, however the panel isn't sold alongside the board.
A new dts, adding everything that's required to get the panel to
work with HiHope RZ/G2M, is the most convenient way to support the
HiHope RZ/G2M when it's connected to the idk-1110wr.
Signed-off-by: Fabrizio Castro
Signed-off-by: Lad Prabhakar
---
arch/arm64/boot/dts/renesas/Makefile | 1 +
.../r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts| 52 ++
2 files changed, 53 insertions(+)
create mode 100644
arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
diff --git a/arch/arm64/boot/dts/renesas/Makefile
b/arch/arm64/boot/dts/renesas/Makefile
index 2153842..82dd245 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m.dtb
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex.dtb
+dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex-idk-1110wr.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n-ex.dtb
dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb \
diff --git
a/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
b/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
new file mode 100644
index 000..2ab5edd
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the HiHope RZ/G2M sub board connected to an
+ * Advantech IDK-1110WR 10.1" LVDS panel
+ *
+ * Copyright (C) 2020 Renesas Electronics Corp.
+ */
+
+#include "r8a774a1-hihope-rzg2m-ex.dts"
+#include "rzg2-advantech-idk-1110wr-panel.dtsi"
+
+/ {
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm0 0 5>;
+
+ brightness-levels = <0 2 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ };
+
+};
+
+&gpio1 {
+ /*
+* When GP1_20 is LOW LVDS0 is connected to the LVDS connector
+* When GP1_20 is HIGH LVDS0 is connected to the LT8918L
+*/
+ lvds-connector-en-gpio {
+ gpio-hog;
+ gpios = <20 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "lvds-connector-en-gpio";
+ };
+};
+
+&lvds0 {
+ status = "okay";
+};
+
+&pfc {
+ pwm0_pins: pwm0 {
+ groups = "pwm0";
+ function = "pwm0";
+ };
+};
+
+&pwm0 {
+ pinctrl-0 = <&pwm0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 4/5] soc / drm: mediatek: Move routing control to mmsys device
Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path().
Those functions will allow DRM driver and others to control the data
path routing.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Matthias Brugger
Reviewed-by: CK Hu
Acked-by: CK Hu
---
Changes in v12: None
Changes in v10:
- Select CONFIG_MTK_MMSYS (CK)
- Pass device pointer of mmsys device instead of config regs (CK)
Changes in v9:
- Introduced a new patch to move routing control into mmsys driver.
- Removed the patch to use regmap as is not needed anymore.
Changes in v8: None
Changes in v7: None
drivers/gpu/drm/mediatek/Kconfig| 1 +
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 256 --
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 -
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 14 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/soc/mediatek/mtk-mmsys.c| 279
include/linux/soc/mediatek/mtk-mmsys.h | 20 ++
8 files changed, 316 insertions(+), 282 deletions(-)
create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index fa5ffc4fe823..c420f5a3d33b 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -11,6 +11,7 @@ config DRM_MEDIATEK
select DRM_MIPI_DSI
select DRM_PANEL
select MEMORY
+ select MTK_MMSYS
select MTK_SMI
select VIDEOMODE_HELPERS
help
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 0e05683d7b53..579a5a5d4472 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,7 +29,7 @@
* @enabled: records whether crtc_enable succeeded
* @planes: array of 4 drm_plane structures, one for each overlay plane
* @pending_planes: whether any plane has pending changes to be applied
- * @config_regs: memory mapped mmsys configuration register space
+ * @mmsys_dev: pointer to the mmsys device for configuration registers
* @mutex: handle to one of the ten disp_mutex streams
* @ddp_comp_nr: number of components in ddp_comp
* @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc
@@ -50,7 +51,7 @@ struct mtk_drm_crtc {
u32 cmdq_event;
#endif
- void __iomem*config_regs;
+ struct device *mmsys_dev;
struct mtk_disp_mutex *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
@@ -296,9 +297,9 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
}
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
- mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
-mtk_crtc->ddp_comp[i]->id,
-mtk_crtc->ddp_comp[i + 1]->id);
+ mtk_mmsys_ddp_connect(mtk_crtc->mmsys_dev,
+ mtk_crtc->ddp_comp[i]->id,
+ mtk_crtc->ddp_comp[i + 1]->id);
mtk_disp_mutex_add_comp(mtk_crtc->mutex,
mtk_crtc->ddp_comp[i]->id);
}
@@ -355,9 +356,9 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
*mtk_crtc)
mtk_crtc->ddp_comp[i]->id);
mtk_disp_mutex_disable(mtk_crtc->mutex);
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
- mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
- mtk_crtc->ddp_comp[i]->id,
- mtk_crtc->ddp_comp[i + 1]->id);
+ mtk_mmsys_ddp_disconnect(mtk_crtc->mmsys_dev,
+mtk_crtc->ddp_comp[i]->id,
+mtk_crtc->ddp_comp[i + 1]->id);
mtk_disp_mutex_remove_comp(mtk_crtc->mutex,
mtk_crtc->ddp_comp[i]->id);
}
@@ -761,7 +762,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
if (!mtk_crtc)
return -ENOMEM;
- mtk_crtc->config_regs = priv->config_regs;
+ mtk_crtc->mmsys_dev = priv->mmsys_dev;
mtk_crtc->ddp_comp_nr = path_len;
mtk_crtc->ddp_comp = devm_kmalloc_array(dev, mtk_crtc->ddp_comp_nr,
sizeof(*mtk_crtc->ddp_comp),
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index b885f60f474c..014c1bbe1df2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@
Re: [PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported
On Wed, Mar 11, 2020 at 03:33:01PM +0100, Christian König wrote: > Am 11.03.20 um 15:04 schrieb Jason Gunthorpe: > > On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote: > > > Check if we can do peer2peer on the PCIe bus. > > > > > > Signed-off-by: Christian König > > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > > > index aef12ee2f1e3..bbf67800c8a6 100644 > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > > > @@ -38,6 +38,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > /** > > >* amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation > > > @@ -179,6 +180,9 @@ static int amdgpu_dma_buf_attach(struct dma_buf > > > *dmabuf, > > > struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); > > > int r; > > > + if (pci_p2pdma_distance_many(adev->pdev, &attach->dev, 1, true) < 0) > > > + attach->peer2peer = false; > > > + > > Are there other related patches than this series? > > > > p2p dma mapping needs to be done in common code, in p2pdma.c - ie this > > open coding is missing the bus_offset stuff, at least. > > Yeah, I'm aware of this. But I couldn't find a better way for now. Well, it isn't optional :) > > I really do not want to see drivers open code this stuff. > > > > We already have a p2pdma API for handling the struct page case, so I > > suggest adding some new p2pdma API to handle this for non-struct page > > cases. > > > > ie some thing like: > > > > int 'p2pdma map bar'( > > struct pci_device *source, > > unsigned int source_bar_number, > > struct pci_device *dest, > > physaddr&len *array_of_offsets & length pairs into source bar, > > struct scatterlist *output_sgl) > > Well that's exactly what I have to avoid since I don't have the array of > offsets around and want to avoid constructing it. Maybe it doesn't need an array of offsets - just a single offset and callers can iterate the API? > Similar problem for dma_map_resource(). My example does this on demand, but > essentially we also have use cases where this is done only once. I'm not sure if this is portable. Does any IOMMU HW need to know P2P is happening to setup successfully? We currently support such a narrow scope of HW for P2P.. > Ideally we would have some function to create an sgl based on some arbitrary > collection of offsets and length inside a BAR. Isn't that what I just proposed above ? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-binding: Add DSI/LVDS tc358775 bridge bindings
Add yaml documentation for DSI/LVDS tc358775 bridge
Signed-off-by: Vinay Simha BN
---
v1:
Initial version
---
.../bindings/display/bridge/toshiba-tc358775.yaml | 174 +
1 file changed, 174 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml
b/Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml
new file mode 100644
index 000..e9a9544
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml
@@ -0,0 +1,174 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/toshiba-tc358775.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+
+title: Toshiba TC358775 DSI to LVDS bridge bindings
+
+maintainers:
+ - Vinay Simha BN
+
+description: |
+ This binding supports DSI to LVDS bridge TC358775
+
+properties:
+ compatible:
+ const: toshiba,tc358775
+
+ reg:
+ maxItems: 1
+ description: i2c address of the bridge, 0x0f
+
+ tc, dsi-lanes: 1
+ maxItems: 1
+ description: Number of DSI data lanes connected to the DSI host. It should
+ be one of 1, 2, 3 or 4.
+
+ tc, dual-link: 1
+ maxItems: 1
+ description: To configure the LVDS transmitter either as single-link or
dual-link.
+
+ vdd-supply:
+ maxItems: 1
+ description: 1.2V LVDS Power Supply
+
+ vddio-supply:
+ maxItems: 1
+ description: 1.8V IO Power Supply
+
+ stby-gpios:
+ maxItems: 1
+ description: Standby pin, Low active
+
+ reset-gpios:
+ maxItems: 1
+ description: Hardware reset, Low active
+
+ ports:
+ type: object
+
+properties:
+ port@0:
+type: object
+description: |
+ DSI Input. The remote endpoint phandle should be a
+ reference to a valid mipi_dsi_host device node.
+ port@1:
+type: object
+description: |
+ Video port for LVDS output (panel or connector).
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - dsi-lanes
+ - vdd-supply
+ - vddio-supply
+ - stby-gpios
+ - reset-gpios
+ - ports
+
+examples:
+ - |
+ i2c@78b8000 {
+ /* On High speed expansion */
+ label = "HS-I2C2";
+ status = "okay";
+
+ tc_bridge: bridge@f {
+ status = "okay";
+
+ compatible = "toshiba,tc358775";
+ reg = <0x0f>;
+
+ tc,dsi-lanes = <4>;
+ tc,dual-link = <0>;
+
+ vdd-supply = <&pm8916_l2>;
+ vddio-supply = <&pm8916_l6>;
+
+ stby-gpio = <&msmgpio 99 GPIO_ACTIVE_LOW>;
+ reset-gpio = <&msmgpio 72 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ d2l_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ d2l_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ };
+ };
+
+ panel: auo,b101xtn01 {
+ status = "okay";
+ compatible = "auo,b101xtn01", "panel-lvds";
+ power-supply = <&pm8916_l14>;
+
+ width-mm = <223>;
+ height-mm = <125>;
+
+ data-mapping = "jeida-24";
+
+ panel-timing {
+ /* 1366x768 @60Hz */
+ clock-frequency = <7200>;
+ hactive = <1366>;
+ vactive = <768>;
+ hsync-len = <70>;
+ hfront-porch = <20>;
+ hback-porch = <0>;
+ vsync-len = <42>;
+ vfront-porch = <14>;
+ vback-porch = <0>;
+ };
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&d2l_out>;
+ };
+ };
+ };
+
+ mdss@1a0 {
+ status = "okay";
+
+ mdp@1a01000 {
+ status = "okay";
+ };
+
+ dsi@1a98000 {
+ status = "okay";
+ ..
+ ports {
+ port@1 {
+ dsi0_out: endpoint {
+ remote-endpoint = <&d2l_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+ };
+
+ dsi-phy@1a98300 {
+ status = "okay";
+
[PATCH v2 2/4] dt-bindings: display: bridge: add it66121 bindings
Add the ITE bridge HDMI it66121 bindings.
Signed-off-by: Phong LE
---
.../bindings/display/bridge/ite,it66121.yaml | 98 +++
1 file changed, 98 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
new file mode 100644
index ..1717e880d130
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ite,it66121.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ITE it66121 HDMI bridge Device Tree Bindings
+
+maintainers:
+ - Phong LE
+ - Neil Armstrong
+
+description: |
+ The IT66121 is a high-performance and low-power single channel HDMI
+ transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward compatible
+ to DVI 1.0 specifications.
+
+properties:
+ compatible:
+const: ite,it66121
+
+ reg:
+maxItems: 1
+description: base I2C address of the device
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active low reset
+
+ vrf12-supply:
+maxItems: 1
+description: Regulator for 1.2V analog core power.
+
+ vcn33-supply:
+maxItems: 1
+description: Regulator for 3.3V digital core power.
+
+ vcn18-supply:
+maxItems: 1
+description: Regulator for 1.8V IO core power.
+
+ interrupts:
+maxItems: 1
+
+ pclk-dual-edge:
+maxItems: 1
+description: enable pclk dual edge mode.
+
+ port:
+type: object
+
+properties:
+ endpoint:
+type: object
+description: |
+ Input endpoints of the bridge.
+
+required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vrf12-supply
+ - vcn33-supply
+ - vcn18-supply
+ - interrupts
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+i2c6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ it66121hdmitx: it66121hdmitx@4c {
+compatible = "ite,it66121";
+pinctrl-names = "default";
+pinctrl-0 = <&ite_pins_default>;
+vcn33-supply = <&mt6358_vcn33_wifi_reg>;
+vcn18-supply = <&mt6358_vcn18_reg>;
+vrf12-supply = <&mt6358_vrf12_reg>;
+reset-gpios = <&pio 160 1 /* GPIO_ACTIVE_LOW */>;
+interrupt-parent = <&pio>;
+interrupts = <4 8 /* IRQ_TYPE_LEVEL_LOW */>;
+reg = <0x4c>;
+pclk-dual-edge;
+
+port {
+ it66121_in: endpoint {
+remote-endpoint = <&display_out>;
+ };
+};
+ };
+};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
How to wait for DRM_MODE_CONNECTED status?
Dear All, What is the most effective/optimal/recommended way to wait for DRM_MODE_CONNECTED status? This is to make sure when disply manager (uses drm apis) starts and if it do not get the DRM_MODE_CONNECTED status as some dependent driver is still loading and setting up (e.g. serializer driver) in that case what is the best way to wait for it? Should I poll the state repeatedly in a loop? Will this value be automatically get updated? Should I close() the DRM device and re-open() it again? Is there any interrupt/callback we can register for to receive updated for this connector state? Thank you. Best Regards, Vikash ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel.
Add its device tree binding.
Signed-off-by: Icenowy Zheng
---
.../display/panel/xingbangda,xbd599.yaml | 50 +++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
new file mode 100644
index ..62816b34de31
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/xingbangda,xbd599.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xingbangda XBD599 5.99in MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: xingbangda,xbd599
+ reg: true
+ backlight: true
+ reset-gpios: true
+ vcc-supply:
+ description: regulator that supplies the VCC voltage
+ iovcc-supply:
+ description: regulator that supplies the IOVCC voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - vcc-supply
+ - iovcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+&dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "xingbangda,xbd599";
+reg = <0>;
+backlight = <&backlight>;
+iovcc-supply = <®_dldo2>;
+vcc-supply = <®_ldo_io0>;
+};
+};
+
+...
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 0/5] arm/arm64: mediatek: Fix mt8173 mmsys device probing
Hi CK, On 11/3/20 14:01, CK Hu wrote: > Hi, Enric: > > I'm confused this is v11 or v12. > For v12, you've lost some 'Acked-by' and 'Reviewed-by' tag. > Right, sorry about that, I messed my workflow after a patman upgrade that didn't work. I'll collect the acks and reviews and send a v12 later today, so it's clear which patches to apply. Thanks, Enric > Regards, > CK > > On Wed, 2020-03-11 at 12:56 +0100, Enric Balletbo i Serra wrote: >> Dear all, >> >> These patches are intended to solve an old standing issue on some >> Mediatek devices (mt8173, mt2701 and mt2712 are affected by this issue). >> >> Up to now both drivers, clock and drm are probed with the same device tree >> compatible. But only the first driver gets probed, which in effect breaks >> graphics on those devices. >> >> The MMSYS (Multimedia subsystem) in Mediatek SoCs has some registers to >> control clock gates (which is used in the clk driver) and some registers >> to set the routing and enable the differnet blocks of the display >> and MDP (Media Data Path) subsystem. On this series the clk driver is >> not a pure clock controller but a system controller that can provide >> access to the shared registers between the different drivers that need >> it (mediatek-drm and mediatek-mdp). Hence the MMSYS clk driver was moved >> to drivers/soc/mediatek and is the entry point (parent) which will trigger >> the probe of the corresponding mediatek-drm driver. >> >> **IMPORTANT** This series only fixes the issue on mt8173 to make it >> simple and as is the only platform I can test. Similar changes should be >> applied for mt2701 and mt2712 to have display working. >> >> These patches apply on top of linux-next. >> >> For reference, here are the links to the old discussions: >> * v10: >> https://patchwork.kernel.org/project/linux-mediatek/list/?series=248505 >> * v9: https://patchwork.kernel.org/project/linux-clk/list/?series=247591 >> * v8: https://patchwork.kernel.org/project/linux-mediatek/list/?series=244891 >> * v7: https://patchwork.kernel.org/project/linux-mediatek/list/?series=241217 >> * v6: https://patchwork.kernel.org/project/linux-mediatek/list/?series=213219 >> * v5: https://patchwork.kernel.org/project/linux-mediatek/list/?series=44063 >> * v4: >> * https://patchwork.kernel.org/patch/10530871/ >> * https://patchwork.kernel.org/patch/10530883/ >> * https://patchwork.kernel.org/patch/10530885/ >> * https://patchwork.kernel.org/patch/10530911/ >> * https://patchwork.kernel.org/patch/10530913/ >> * v3: >> * https://patchwork.kernel.org/patch/10367857/ >> * https://patchwork.kernel.org/patch/10367861/ >> * https://patchwork.kernel.org/patch/10367877/ >> * https://patchwork.kernel.org/patch/10367875/ >> * https://patchwork.kernel.org/patch/10367885/ >> * https://patchwork.kernel.org/patch/10367883/ >> * https://patchwork.kernel.org/patch/10367889/ >> * https://patchwork.kernel.org/patch/10367907/ >> * https://patchwork.kernel.org/patch/10367909/ >> * https://patchwork.kernel.org/patch/10367905/ >> * v2: No relevant discussion, see v3 >> * v1: >> * https://patchwork.kernel.org/patch/10016497/ >> * https://patchwork.kernel.org/patch/10016499/ >> * https://patchwork.kernel.org/patch/10016505/ >> * https://patchwork.kernel.org/patch/10016507/ >> >> Best regards, >> Enric >> >> Changes in v11: >> - Leave the clocks part in drivers/clk (clk-mt8173-mm) >> - Instantiate the clock driver from the mtk-mmsys driver. >> - Add default config option to not break anything. >> - Removed the Reviewed-by CK tag as changed the organization. >> >> Changes in v10: >> - Update the binding documentation for the mmsys system controller. >> - Renamed to be generic mtk-mmsys >> - Add driver data support to be able to support diferent SoCs >> - Select CONFIG_MTK_MMSYS (CK) >> - Pass device pointer of mmsys device instead of config regs (CK) >> - Match driver data to get display routing. >> >> Changes in v9: >> - Move mmsys to drivers/soc/mediatek (CK) >> - Introduced a new patch to move routing control into mmsys driver. >> - Removed the patch to use regmap as is not needed anymore. >> - Do not move the display routing from the drm driver (CK) >> >> Changes in v8: >> - Be a builtin_platform_driver like other mediatek mmsys drivers. >> - New patch introduced in this series. >> >> Changes in v7: >> - Free clk_data->clks as well >> - Get rid of private data structure >> >> Enric Balletbo i Serra (3): >> dt-bindings: mediatek: Update mmsys binding to reflect it is a system >> controller >> soc / drm: mediatek: Move routing control to mmsys device >> soc / drm: mediatek: Fix mediatek-drm device probing >> >> Matthias Brugger (2): >> drm/mediatek: Omit warning on probe defers >> clk / soc: mediatek: Move mt8173 MMSYS to platform driver >> >> .../bindings/arm/mediatek/mediatek,mmsys.txt | 7 +- >> drivers/clk/mediatek/Kconfig | 7 + >> drivers/clk/mediatek/Makefile | 1 + >> dr
Re: [PATCH -next 013/491] INGENIC JZ47xx SoCs: Use fallthrough;
Ulf Hansson wrote on Wed, 11 Mar 2020 15:20:59 +0100: > On Wed, 11 Mar 2020 at 08:40, Miquel Raynal wrote: > > > > Hi Joe, > > > > Joe Perches wrote on Tue, 10 Mar 2020 21:51:27 -0700: > > > > > Convert the various uses of fallthrough comments to fallthrough; > > > > > > Done via script > > > Link: > > > https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/ > > > > > > Signed-off-by: Joe Perches > > > --- > > > drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +- > > > drivers/mmc/host/jz4740_mmc.c | 6 ++ > > > drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c | 2 +- > > > drivers/mtd/nand/raw/ingenic/jz4725b_bch.c | 4 ++-- > > > drivers/mtd/nand/raw/ingenic/jz4780_bch.c | 4 ++-- > > > sound/soc/codecs/jz4770.c | 2 +- > > > 6 files changed, 9 insertions(+), 11 deletions(-) > > > > I like very much the new way to advertise for fallthrough statements, > > but I am not willing to take any patch converting a single driver > > anymore. I had too many from Gustavo when these comments had to be > > inserted. I would really prefer a MTD-wide or a NAND-wide or at least a > > raw-NAND-wide single patch (anything inside drivers/mtd/nand/raw/). > > > > Hope you'll understand! > > I fully agree (for mmc). One patch please. > > Another option is to make a big fat tree wide patch and ask Linus if > he want to pick up immediately after an rc1. That should cause less > disturbance for everyone, no? Absolutely. Miquèl ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/amdgpu: add support for exporting VRAM using DMA-buf v2
On Wed, Mar 11, 2020 at 02:51:57PM +0100, Christian König wrote:
> +/**
> + * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
> + *
> + * @adev: amdgpu device pointer
> + * @mem: TTM memory object
> + * @dev: the other device
> + * @dir: dma direction
> + * @sgt: resulting sg table
> + *
> + * Allocate and fill a sg table from a VRAM allocation.
> + */
> +int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
> + struct ttm_mem_reg *mem,
> + struct device *dev,
> + enum dma_data_direction dir,
> + struct sg_table **sgt)
single ** pointer with an int return is odd, use ERR_PTR?
> +{
> + struct drm_mm_node *node;
> + struct scatterlist *sg;
> + int num_entries = 0;
> + unsigned int pages;
> + int i, r;
> +
> + *sgt = kmalloc(sizeof(*sg), GFP_KERNEL);
> + if (!*sgt)
> + return -ENOMEM;
> +
> + for (pages = mem->num_pages, node = mem->mm_node;
> + pages; pages -= node->size, ++node)
> + ++num_entries;
> +
> + r = sg_alloc_table(*sgt, num_entries, GFP_KERNEL);
> + if (r)
> + goto error_free;
> +
> + for_each_sg((*sgt)->sgl, sg, num_entries, i)
> + sg->length = 0;
> +
> + node = mem->mm_node;
> + for_each_sg((*sgt)->sgl, sg, num_entries, i) {
> + phys_addr_t phys = (node->start << PAGE_SHIFT) +
> + adev->gmc.aper_base;
> + size_t size = node->size << PAGE_SHIFT;
> + dma_addr_t addr;
> +
> + ++node;
> + addr = dma_map_resource(dev, phys, size, dir,
> + DMA_ATTR_SKIP_CPU_SYNC);
> + r = dma_mapping_error(dev, addr);
> + if (r)
> + goto error_unmap;
> +
> + sg_set_dma_addr(sg, addr, size, 0);
Is it possible that phys will need to have contiguous pages joined
here, or has 'node' already ensured contiguous pages?
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] dt-bindings: display: convert rockchip vop bindings to yaml
Current dts files with 'vop' nodes are manually verified.
In order to automate this process rockchip-vop.txt
has to be converted to yaml.
Signed-off-by: Johan Jonker
---
Changes v2:
No new properties
---
.../bindings/display/rockchip/rockchip-vop.txt | 74
.../bindings/display/rockchip/rockchip-vop.yaml| 126 +
2 files changed, 126 insertions(+), 74 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
deleted file mode 100644
index 8b3a5f514..0
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-device-tree bindings for rockchip soc display controller (vop)
-
-VOP (Visual Output Processor) is the Display Controller for the Rockchip
-series of SoCs which transfers the image data from a video memory
-buffer to an external LCD interface.
-
-Required properties:
-- compatible: value should be one of the following
- "rockchip,rk3036-vop";
- "rockchip,rk3126-vop";
- "rockchip,px30-vop-lit";
- "rockchip,px30-vop-big";
- "rockchip,rk3066-vop";
- "rockchip,rk3188-vop";
- "rockchip,rk3288-vop";
- "rockchip,rk3368-vop";
- "rockchip,rk3366-vop";
- "rockchip,rk3399-vop-big";
- "rockchip,rk3399-vop-lit";
- "rockchip,rk3228-vop";
- "rockchip,rk3328-vop";
-
-- reg: Must contain one entry corresponding to the base address and length
- of the register space. Can optionally contain a second entry
- corresponding to the CRTC gamma LUT address.
-
-- interrupts: should contain a list of all VOP IP block interrupts in the
-order: VSYNC, LCD_SYSTEM. The interrupt specifier
-format depends on the interrupt controller used.
-
-- clocks: must include clock specifiers corresponding to entries in the
- clock-names property.
-
-- clock-names: Must contain
- aclk_vop: for ddr buffer transfer.
- hclk_vop: for ahb bus to R/W the phy regs.
- dclk_vop: pixel clock.
-
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - axi
- - ahb
- - dclk
-
-- iommus: required a iommu node
-
-- port: A port node with endpoint definitions as defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Example:
-SoC specific DT entry:
- vopb: vopb@ff93 {
- compatible = "rockchip,rk3288-vop";
- reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
- interrupts = ;
- clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
- clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
- resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru
SRST_LCDC1_DCLK>;
- reset-names = "axi", "ahb", "dclk";
- iommus = <&vopb_mmu>;
- vopb_out: port {
- #address-cells = <1>;
- #size-cells = <0>;
- vopb_out_edp: endpoint@0 {
- reg = <0>;
- remote-endpoint=<&edp_in_vopb>;
- };
- vopb_out_hdmi: endpoint@1 {
- reg = <1>;
- remote-endpoint=<&hdmi_in_vopb>;
- };
- };
- };
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
new file mode 100644
index 0..cb88849f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip soc display controller (VOP)
+
+description:
+ VOP (Visual Output Processor) is the Display Controller for the Rockchip
+ series of SoCs which transfers the image data from a video memory
+ buffer to an external LCD interface.
+
+maintainers:
+ - Sandy Huang
+ - Heiko Stuebner
+
+properties:
+ compatible:
+oneOf:
+ - const: rockchip,px30-vop-big
+ - const: rockchip,px30-vop-lit
+ - const: rockchip,rk3036-vop
+ - const: rockchip,rk3066-vop
+ - const: rockchip,rk3126-vop
+ - const: rockchip,rk3188-vop
+ - const: rockchip,rk3228-vop
+ - const: rockchip,rk3288
[PATCH v2 1/4] dt-bindings: add ITE vendor
Add ITE Tech Inc. prefix "ite" in vendor-prefixes. More information on: http://www.ite.com.tw/ Signed-off-by: Phong LE --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index a2da166df1bc..c2fb444e1900 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -475,6 +475,8 @@ patternProperties: description: Intersil "^issi,.*": description: Integrated Silicon Solutions Inc. + "^ite,.*": +description: ITE Tech Inc. "^itead,.*": description: ITEAD Intelligent Systems Co.Ltd "^iwave,.*": -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mxsfb: fix Kconfig menu presentation
From: Randy Dunlap
Make DRM_MXS depend on DRM. This causes the MXS FB menu to be
presented in the DRM menu where it should be instead of in the
Graphics support menu.
Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller")
Signed-off-by: Randy Dunlap
Cc: Marek Vasut
Cc: Lucas Stach
Cc: Fabio Estevam
Cc: Shawn Guo
Cc: Stefan Agner
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/mxsfb/Kconfig |1 +
1 file changed, 1 insertion(+)
--- linux-next-a.orig/drivers/gpu/drm/mxsfb/Kconfig
+++ linux-next-b/drivers/gpu/drm/mxsfb/Kconfig
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config DRM_MXS
bool
+ depends on DRM
help
Choose this option to select drivers for MXS FB devices
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 1/5] drm/mediatek: Omit warning on probe defers
From: Matthias Brugger
It can happen that the mmsys clock drivers aren't probed before the
platform driver gets invoked. The platform driver used to print a warning
that the driver failed to get the clocks. Omit this error on
the defered probe path.
Signed-off-by: Matthias Brugger
Reviewed-by: CK Hu
Signed-off-by: Enric Balletbo i Serra
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 -
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 -
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 -
drivers/gpu/drm/mediatek/mtk_dpi.c| 12 +---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 3 ++-
drivers/gpu/drm/mediatek/mtk_dsi.c| 8 ++--
drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 +++-
7 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 6fb0d6983a4a..3ae9c810845b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -119,7 +119,10 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_color_funcs);
if (ret) {
- dev_err(dev, "Failed to initialize component: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 891d80c73e04..28651bc579bc 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -386,7 +386,10 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_ovl_funcs);
if (ret) {
- dev_err(dev, "Failed to initialize component: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 0cb848d64206..e04319fedf46 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -294,7 +294,10 @@ static int mtk_disp_rdma_probe(struct platform_device
*pdev)
ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_rdma_funcs);
if (ret) {
- dev_err(dev, "Failed to initialize component: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 01fa8b8d763d..1b219edef541 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -701,21 +701,27 @@ static int mtk_dpi_probe(struct platform_device *pdev)
dpi->engine_clk = devm_clk_get(dev, "engine");
if (IS_ERR(dpi->engine_clk)) {
ret = PTR_ERR(dpi->engine_clk);
- dev_err(dev, "Failed to get engine clock: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get engine clock: %d\n", ret);
+
return ret;
}
dpi->pixel_clk = devm_clk_get(dev, "pixel");
if (IS_ERR(dpi->pixel_clk)) {
ret = PTR_ERR(dpi->pixel_clk);
- dev_err(dev, "Failed to get pixel clock: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get pixel clock: %d\n", ret);
+
return ret;
}
dpi->tvd_clk = devm_clk_get(dev, "pll");
if (IS_ERR(dpi->tvd_clk)) {
ret = PTR_ERR(dpi->tvd_clk);
- dev_err(dev, "Failed to get tvdpll clock: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get tvdpll clock: %d\n", ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 13035c906035..b885f60f474c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -628,7 +628,8 @@ static int mtk_ddp_probe(struct platform_device *pdev)
if (!ddp->data->no_clk) {
ddp->clk = devm_clk_get(dev, NULL);
if (IS_ERR(ddp->clk)) {
- dev_err(dev, "Failed to get clock\n");
+
Re: [PATCH 10/21] drm/tegra: remove checks for debugfs functions return value
Hey Thierry, On Wed, 11 Mar 2020, Thierry Reding wrote: On Thu, Feb 27, 2020 at 03:02:21PM +0300, Wambui Karuga wrote: Since 987d65d01356 (drm: debugfs: make drm_debugfs_create_files() never fail) there is no need to check the return value of drm_debugfs_create_files(). Therefore, remove the return checks and error handling of the drm_debugfs_create_files() function from various debugfs init functions in drm/tegra and have them return 0 directly. This change also includes removing the use of drm_debugfs_create_files as a return value in tegra_debugfs_init() and have the function declared as void. Signed-off-by: Wambui Karuga --- drivers/gpu/drm/tegra/dc.c | 11 +-- drivers/gpu/drm/tegra/drm.c | 8 drivers/gpu/drm/tegra/dsi.c | 11 +-- drivers/gpu/drm/tegra/hdmi.c | 11 +-- drivers/gpu/drm/tegra/sor.c | 11 +-- 5 files changed, 8 insertions(+), 44 deletions(-) Applied, thanks. There's a newer version[1] of this patch series as this specific patch depends on other work in drm. Thanks, wambui karuga. [1] https://lists.freedesktop.org/archives/dri-devel/2020-March/258793.html Thierry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 3/5] clk / soc: mediatek: Move mt8173 MMSYS to platform driver
On 11/3/20 17:53, Enric Balletbo i Serra wrote:
> From: Matthias Brugger
>
> There is no strong reason for this to use CLK_OF_DECLARE instead of
> being a platform driver. Plus, MMSYS provides clocks but also a shared
> register space for the mediatek-drm and the mediatek-mdp
> driver. So move the MMSYS clocks to a new platform driver and also
> create a new MMSYS platform driver in drivers/soc/mediatek that
> instantiates the clock driver.
>
> Signed-off-by: Matthias Brugger
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: CK Hu
> ---
>
> Changes in v12:
> - Leave the clocks part in drivers/clk (clk-mt8173-mm)
> - Instantiate the clock driver from the mtk-mmsys driver.
> - Add default config option to not break anything.
> - Removed the Reviewed-by CK tag as changed the organization.
>
> Changes in v10:
> - Renamed to be generic mtk-mmsys
> - Add driver data support to be able to support diferent SoCs
>
> Changes in v9:
> - Move mmsys to drivers/soc/mediatek (CK)
>
> Changes in v8:
> - Be a builtin_platform_driver like other mediatek mmsys drivers.
>
> Changes in v7:
> - Free clk_data->clks as well
> - Get rid of private data structure
>
> drivers/clk/mediatek/Kconfig | 7 ++
> drivers/clk/mediatek/Makefile| 1 +
> drivers/clk/mediatek/clk-mt8173-mm.c | 146 +++
> drivers/clk/mediatek/clk-mt8173.c| 104 ---
Quoting Matthias to continue the discussion here:
"I'm not sure we really need that. We can just convert the mmsys clock bits in
clk-mt8173.c to a platform driver with no need put them in a seperate file.
If you think a seperate file is worth doing, I think the approach is to put the
driver in a seperate file first and in a following patch change it to a platform
driver."
"Anyway its Stephen to make the decision. If he thinks things are fine like
this, I'm happy to take the patch through my tree"
> drivers/soc/mediatek/Kconfig | 8 ++
> drivers/soc/mediatek/Makefile| 1 +
> drivers/soc/mediatek/mtk-mmsys.c | 50 +
> 7 files changed, 213 insertions(+), 104 deletions(-)
> create mode 100644 drivers/clk/mediatek/clk-mt8173-mm.c
> create mode 100644 drivers/soc/mediatek/mtk-mmsys.c
>
> diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> index ea3c70d1307e..9e28db8125cd 100644
> --- a/drivers/clk/mediatek/Kconfig
> +++ b/drivers/clk/mediatek/Kconfig
> @@ -274,6 +274,13 @@ config COMMON_CLK_MT8173
> ---help---
> This driver supports MediaTek MT8173 clocks.
>
> +config COMMON_CLK_MT8173_MMSYS
> + bool "Clock driver for MediaTek MT8173 mmsys"
> + depends on COMMON_CLK_MT8173
> + default COMMON_CLK_MT8173
> + help
> + This driver supports MediaTek MT8173 mmsys clocks.
> +
> config COMMON_CLK_MT8183
> bool "Clock driver for MediaTek MT8183"
> depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index 8cdb76a5cd71..bb0536942075 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_COMMON_CLK_MT7629_ETHSYS) += clk-mt7629-eth.o
> obj-$(CONFIG_COMMON_CLK_MT7629_HIFSYS) += clk-mt7629-hif.o
> obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
> obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
> +obj-$(CONFIG_COMMON_CLK_MT8173_MMSYS) += clk-mt8173-mm.o
> obj-$(CONFIG_COMMON_CLK_MT8183) += clk-mt8183.o
> obj-$(CONFIG_COMMON_CLK_MT8183_AUDIOSYS) += clk-mt8183-audio.o
> obj-$(CONFIG_COMMON_CLK_MT8183_CAMSYS) += clk-mt8183-cam.o
> diff --git a/drivers/clk/mediatek/clk-mt8173-mm.c
> b/drivers/clk/mediatek/clk-mt8173-mm.c
> new file mode 100644
> index ..36fa20be77b6
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt8173-mm.c
> @@ -0,0 +1,146 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2014 MediaTek Inc.
> + * Author: James Liao
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "clk-gate.h"
> +#include "clk-mtk.h"
> +
> +#include
> +
> +static const struct mtk_gate_regs mm0_cg_regs = {
> + .set_ofs = 0x0104,
> + .clr_ofs = 0x0108,
> + .sta_ofs = 0x0100,
> +};
> +
> +static const struct mtk_gate_regs mm1_cg_regs = {
> + .set_ofs = 0x0114,
> + .clr_ofs = 0x0118,
> + .sta_ofs = 0x0110,
> +};
> +
> +#define GATE_MM0(_id, _name, _parent, _shift) { \
> + .id = _id, \
> + .name = _name, \
> + .parent_name = _parent, \
> + .regs = &mm0_cg_regs, \
> + .shift = _shift,\
> + .ops = &mtk_clk_gate_ops_setclr,\
> + }
> +
> +#define GATE_MM1(_id, _name, _parent, _shift) { \
> + .id = _id, \
Re: [RFC v2 6/8] MIPS: DTS: jz4780: account for Synopsys HDMI driver and LCD controller
Hi Nikolaus,
Le mer., mars 11, 2020 at 13:43, H. Nikolaus Schaller
a écrit :
Hi Paul,
Am 02.03.2020 um 20:27 schrieb Paul Cercueil :
Hi Nikolaus,
Le ven., févr. 28, 2020 at 19:19, H. Nikolaus Schaller
a écrit :
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed
for JZ4780
HDMI support. This requires a new driver, plus device tree and
configuration
modifications.
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/jz4780.dtsi | 32
++
1 file changed, 32 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index f928329b034b..391d4e1efd35 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -433,4 +433,36 @@
status = "disabled";
};
+
+ hdmi: hdmi@1018 {
+ compatible = "ingenic,jz4780-dw-hdmi";
+ reg = <0x1018 0x8000>;
+ reg-io-width = <4>;
+
+ clocks = <&cgu JZ4780_CLK_HDMI>, <&cgu JZ4780_CLK_AHB0>;
+ clock-names = "isfr" , "iahb";
+
+ assigned-clocks = <&cgu JZ4780_CLK_HDMI>;
+ assigned-clock-rates = <2700>;
I *think* this should go to the board file.
+
+ interrupt-parent = <&intc>;
+ interrupts = <3>;
+
+ /* ddc-i2c-bus = <&i2c4>; */
+
+ status = "disabled";
+ };
+
+ lcd: lcd@1305 {
The node name should be 'lcd-controller'.
+ compatible = "ingenic,jz4740-lcd";
The JZ4780's LCD controller is much newer than the JZ4740 one, so
even if it works with the "ingenic,jz4740-lcd" compatible string,
you want it as a fallback.
So this should be: compatible = "ingenic,jz4780-lcd",
"ingenic,jz4740-lcd".
That means the YAML should be updated too.
I have started to look into jz4780 HDMI setup again.
Well, there is no driver compatible to "ingenic,jz4780-lcd" so far
and it is questionalbe if we need a different one.
I think we should rather make the driver also compatible
than adding a fallback to ingenic,jz4740-lcdto the DTS.
The reason why this is better even if both LCDC are almost
compatible is that the jz4780 allows for much bigger displays
and therefore should have its own jz_soc_info with 4k x 2k
as maximum.
Sure, feel free to extend the driver.
Next I tried to find out if the LCDC are really compatible.
Well the jz4780 has two lcdc instances but they are separated
by the reg addr. Next, there are unique features (like picture in
picture with alpha blending) but those are probably disabled
if not programmed from reset state. This may become a reason
to separate or augment the driver for the jz4780 but at the
moment we can ignore that.
Two LCDC instances -> two lcd-controller@... nodes. It's that simple.
The other features you listed are outside the LCDC, so outside the
scope of this driver.
There are also subtly different bit definitions and register
widths (e.g. 24 bit in addition to 16/18 bit modes or more bits
for the sync position) but it looks as if the ingenic_drm
driver already handles this.
Then I tried to read back the registers. Strangely they
are all 0x. So there is no programming of the
lcd-controller in our DT setup with HDMI at all!
How did you read them?
Do it from the regmap: should be "cat
/sys/kernel/debug/regmap/1305.lcd-controller/registers" (not sure
about the path)
I also checked that ingenic_drm_probe() is called and
returns successfully 0. It also reports that a /dev/fb
has been created:
[7.908830] ingenic-drm 1305.lcd-controller: fb0:
ingenic-drmdrmf frame buffer device
But for example ingenic_drm_encoder_atomic_mode_set() is
never called which should write some registers of the LCDC.
I only did see some calls to ingenic_drm_encoder_atomic_check().
This of course explains why we have no HDMI signals despite
proper HPD and a /dev/fb0. Because the LCDC is not being
programmed.
It won't be called until the HDMI driver says that the cable is
plugged, and there's a client application (e.g. fbdev emulation)
running. So the problem is most likely within the HDMI driver.
Cheers,
-Paul
Any ideas / hints how to check or improve?
BR and thanks,
Nikolaus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/amdgpu: add support for exporting VRAM using DMA-buf v2
On Wed, Mar 11, 2020 at 02:51:57PM +0100, Christian König wrote:
> +/**
> + * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
> + *
> + * @adev: amdgpu device pointer
> + * @sgt: sg table to free
Wrong kdoc in many ways
> + * Free a previously allocate sg table.
> + */
> +void amdgpu_vram_mgr_free_sgt(struct amdgpu_device *adev,
> + struct device *dev,
> + enum dma_data_direction dir,
> + struct sg_table *sgt)
> +{
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported
On Wed, Mar 11, 2020 at 03:43:03PM +0100, Christian König wrote: > > > > int 'p2pdma map bar'( > > > > struct pci_device *source, > > > > unsigned int source_bar_number, > > > > struct pci_device *dest, > > > > physaddr&len *array_of_offsets & length pairs into source bar, > > > > struct scatterlist *output_sgl) > > > Well that's exactly what I have to avoid since I don't have the array of > > > offsets around and want to avoid constructing it. > > Maybe it doesn't need an array of offsets - just a single offset and > > callers can iterate the API? > > Yes, that would of course work as well. > > But I was assuming that p2pdma_map_bar() needs some state between those > calls. It might be able to run faster if some state is held. We've had APIs before where the caller can provide a cache for expensive state for APIs. Maybe that would be an appropriate pattern here? IIRC the distance calculation is the expensive bit, that would be easy enough to cache. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 3/5] clk / soc: mediatek: Move mt8173 MMSYS to platform driver
On 11/03/2020 12:56, Enric Balletbo i Serra wrote: > From: Matthias Brugger > > There is no strong reason for this to use CLK_OF_DECLARE instead of > being a platform driver. Plus, MMSYS provides clocks but also a shared > register space for the mediatek-drm and the mediatek-mdp > driver. So move the MMSYS clocks to a new platform driver and also > create a new MMSYS platform driver in drivers/soc/mediatek that > instantiates the clock driver. > > Signed-off-by: Matthias Brugger > Signed-off-by: Enric Balletbo i Serra > --- > > Changes in v11: > - Leave the clocks part in drivers/clk (clk-mt8173-mm) > - Instantiate the clock driver from the mtk-mmsys driver. > - Add default config option to not break anything. > - Removed the Reviewed-by CK tag as changed the organization. > > Changes in v10: > - Renamed to be generic mtk-mmsys > - Add driver data support to be able to support diferent SoCs > > Changes in v9: > - Move mmsys to drivers/soc/mediatek (CK) > > Changes in v8: > - Be a builtin_platform_driver like other mediatek mmsys drivers. > > Changes in v7: > - Free clk_data->clks as well > - Get rid of private data structure > > drivers/clk/mediatek/Kconfig | 7 ++ > drivers/clk/mediatek/Makefile| 1 + > drivers/clk/mediatek/clk-mt8173-mm.c | 146 +++ > drivers/clk/mediatek/clk-mt8173.c| 104 --- I'm not sure we really need that. We can just convert the mmsys clock bits in clk-mt8173.c to a platform driver with no need put them in a seperate file. If you think a seperate file is worth doing, I think the approach is to put the driver in a seperate file first and in a following patch change it to a platform driver. Anyway its Stephen to make the decision. If he thinks things are fine like this, I'm happy to take the patch through my tree. > drivers/soc/mediatek/Kconfig | 8 ++ > drivers/soc/mediatek/Makefile| 1 + > drivers/soc/mediatek/mtk-mmsys.c | 50 + > 7 files changed, 213 insertions(+), 104 deletions(-) > create mode 100644 drivers/clk/mediatek/clk-mt8173-mm.c > create mode 100644 drivers/soc/mediatek/mtk-mmsys.c > > diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig > index 2114b563478c..e84513318725 100644 > --- a/drivers/soc/mediatek/Kconfig > +++ b/drivers/soc/mediatek/Kconfig > @@ -44,4 +44,12 @@ config MTK_SCPSYS > Say yes here to add support for the MediaTek SCPSYS power domain > driver. > > +config MTK_MMSYS > + bool "MediaTek MMSYS Support" > + depends on COMMON_CLK_MT8173_MMSYS > + default COMMON_CLK_MT8173_MMSYS If we don't create a new file, we would need to depend on COMMON_CLK_MT8173 or maybe not even that. I suppose the system does not get anywhere without the clock driver. Regards, Matthias ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm: panel: add Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
Xingbangda, which is used on PinePhone final assembled phones.
Add support for it.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-xingbangda-xbd599.c | 367 ++
3 files changed, 377 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index da3b84602cdd..d648f40469c7 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -413,6 +413,15 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+config DRM_PANEL_XINGBANGDA_XBD599
+ tristate "Xingbangda XBD599 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Xingbangda XBD599
+ MIPI DSI Video Mode panel.
+
config DRM_PANEL_XINPENG_XPP055C272
tristate "Xinpeng XPP055C272 panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index af1e2a3cc5fc..d9645f079e59 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,4 +44,5 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_XINGBANGDA_XBD599) += panel-xingbangda-xbd599.o
obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
new file mode 100644
index ..68a5d8bb7f26
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
@@ -0,0 +1,367 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xingbangda XBD599 MIPI-DSI panel driver
+ *
+ * Copyright (C) 2019 Icenowy Zheng
+ *
+ * Based on panel-rocktech-jh057n00900.c, which is:
+ * Copyright (C) Purism SPC 2019
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "panel-xingbangda-xbd599"
+
+/* Manufacturer specific Commands send via DSI */
+#define ST7703_CMD_ALL_PIXEL_OFF 0x22
+#define ST7703_CMD_ALL_PIXEL_ON 0x23
+#define ST7703_CMD_SETDISP 0xB2
+#define ST7703_CMD_SETRGBIF 0xB3
+#define ST7703_CMD_SETCYC 0xB4
+#define ST7703_CMD_SETBGP 0xB5
+#define ST7703_CMD_SETVCOM 0xB6
+#define ST7703_CMD_SETOTP 0xB7
+#define ST7703_CMD_SETPOWER_EXT 0xB8
+#define ST7703_CMD_SETEXTC 0xB9
+#define ST7703_CMD_SETMIPI 0xBA
+#define ST7703_CMD_SETVDC 0xBC
+#define ST7703_CMD_SETSCR 0xC0
+#define ST7703_CMD_SETPOWER 0xC1
+#define ST7703_CMD_UNK_C6 0xC6
+#define ST7703_CMD_SETPANEL 0xCC
+#define ST7703_CMD_SETGAMMA 0xE0
+#define ST7703_CMD_SETEQ0xE3
+#define ST7703_CMD_SETGIP1 0xE9
+#define ST7703_CMD_SETGIP2 0xEA
+
+static const char * const regulator_names[] = {
+ "iovcc",
+ "vcc",
+};
+
+struct xbd599 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+ bool prepared;
+};
+
+static inline struct xbd599 *panel_to_xbd599(struct drm_panel *panel)
+{
+ return container_of(panel, struct xbd599, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int xbd599_init_sequence(struct xbd599 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+ int ret;
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
+ 0xF1, 0x12, 0x83);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
+ 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
+ 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4F, 0x11,
+ 0x00, 0x00, 0x37);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT,
+
[PATCH v2 0/4] Add it66121 driver
The IT66121 is a high-performance and low-power single channel HDMI transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward compatible to DVI 1.0 specifications. It supports pixel rates from 25MHz to 165MHz. This series contains document bindings, add vendor prefix, Kconfig to enable or not. For now, the driver handles only RGB without color conversion. Audio, CEC and HDCP are not implemented yet. Phong LE (4): dt-bindings: add ITE vendor dt-bindings: display: bridge: add it66121 bindings drm: bridge: add it66121 driver MAINTAINERS: add it66121 HDMI bridge driver entry .../bindings/display/bridge/ite,it66121.yaml | 98 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 8 + drivers/gpu/drm/bridge/Kconfig| 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ite-it66121.c | 997 ++ 6 files changed, 1114 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] dma-buf: add support for virtio exported objects
This change adds a new dma-buf operation that allows dma-bufs to be used
by virtio drivers to share exported objects. The new operation allows
the importing driver to query the exporting driver for the UUID which
identifies the underlying exported object.
Signed-off-by: David Stevens
---
drivers/dma-buf/dma-buf.c | 12
include/linux/dma-buf.h | 18 ++
2 files changed, 30 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d4097856c86b..fa5210ba6aaa 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1158,6 +1158,18 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
}
EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid)
+{
+ if (WARN_ON(!dmabuf) || !uuid)
+ return -EINVAL;
+
+ if (!dmabuf->ops->get_uuid)
+ return -ENODEV;
+
+ return dmabuf->ops->get_uuid(dmabuf, uuid);
+}
+EXPORT_SYMBOL_GPL(dma_buf_get_uuid);
+
#ifdef CONFIG_DEBUG_FS
static int dma_buf_debug_show(struct seq_file *s, void *unused)
{
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index abf5459a5b9d..00758523597d 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -251,6 +251,21 @@ struct dma_buf_ops {
void *(*vmap)(struct dma_buf *);
void (*vunmap)(struct dma_buf *, void *vaddr);
+
+ /**
+* @get_uuid
+*
+* This is called by dma_buf_get_uuid to get the UUID which identifies
+* the buffer to virtio devices.
+*
+* This callback is optional.
+*
+* Returns:
+*
+* 0 on success or a negative error code on failure. On success uuid
+* will be populated with the buffer's UUID.
+*/
+ int (*get_uuid)(struct dma_buf *dmabuf, uuid_t *uuid);
};
/**
@@ -444,4 +459,7 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
unsigned long);
void *dma_buf_vmap(struct dma_buf *);
void dma_buf_vunmap(struct dma_buf *, void *vaddr);
+
+int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid);
+
#endif /* __DMA_BUF_H__ */
--
2.25.1.481.gfbce0eb801-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 3/5] clk / soc: mediatek: Move mt8173 MMSYS to platform driver
From: Matthias Brugger
There is no strong reason for this to use CLK_OF_DECLARE instead of
being a platform driver. Plus, MMSYS provides clocks but also a shared
register space for the mediatek-drm and the mediatek-mdp
driver. So move the MMSYS clocks to a new platform driver and also
create a new MMSYS platform driver in drivers/soc/mediatek that
instantiates the clock driver.
Signed-off-by: Matthias Brugger
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: CK Hu
---
Changes in v12:
- Leave the clocks part in drivers/clk (clk-mt8173-mm)
- Instantiate the clock driver from the mtk-mmsys driver.
- Add default config option to not break anything.
- Removed the Reviewed-by CK tag as changed the organization.
Changes in v10:
- Renamed to be generic mtk-mmsys
- Add driver data support to be able to support diferent SoCs
Changes in v9:
- Move mmsys to drivers/soc/mediatek (CK)
Changes in v8:
- Be a builtin_platform_driver like other mediatek mmsys drivers.
Changes in v7:
- Free clk_data->clks as well
- Get rid of private data structure
drivers/clk/mediatek/Kconfig | 7 ++
drivers/clk/mediatek/Makefile| 1 +
drivers/clk/mediatek/clk-mt8173-mm.c | 146 +++
drivers/clk/mediatek/clk-mt8173.c| 104 ---
drivers/soc/mediatek/Kconfig | 8 ++
drivers/soc/mediatek/Makefile| 1 +
drivers/soc/mediatek/mtk-mmsys.c | 50 +
7 files changed, 213 insertions(+), 104 deletions(-)
create mode 100644 drivers/clk/mediatek/clk-mt8173-mm.c
create mode 100644 drivers/soc/mediatek/mtk-mmsys.c
diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index ea3c70d1307e..9e28db8125cd 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -274,6 +274,13 @@ config COMMON_CLK_MT8173
---help---
This driver supports MediaTek MT8173 clocks.
+config COMMON_CLK_MT8173_MMSYS
+ bool "Clock driver for MediaTek MT8173 mmsys"
+ depends on COMMON_CLK_MT8173
+ default COMMON_CLK_MT8173
+ help
+ This driver supports MediaTek MT8173 mmsys clocks.
+
config COMMON_CLK_MT8183
bool "Clock driver for MediaTek MT8183"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 8cdb76a5cd71..bb0536942075 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_COMMON_CLK_MT7629_ETHSYS) += clk-mt7629-eth.o
obj-$(CONFIG_COMMON_CLK_MT7629_HIFSYS) += clk-mt7629-hif.o
obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
+obj-$(CONFIG_COMMON_CLK_MT8173_MMSYS) += clk-mt8173-mm.o
obj-$(CONFIG_COMMON_CLK_MT8183) += clk-mt8183.o
obj-$(CONFIG_COMMON_CLK_MT8183_AUDIOSYS) += clk-mt8183-audio.o
obj-$(CONFIG_COMMON_CLK_MT8183_CAMSYS) += clk-mt8183-cam.o
diff --git a/drivers/clk/mediatek/clk-mt8173-mm.c
b/drivers/clk/mediatek/clk-mt8173-mm.c
new file mode 100644
index ..36fa20be77b6
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt8173-mm.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: James Liao
+ */
+
+#include
+#include
+#include
+
+#include "clk-gate.h"
+#include "clk-mtk.h"
+
+#include
+
+static const struct mtk_gate_regs mm0_cg_regs = {
+ .set_ofs = 0x0104,
+ .clr_ofs = 0x0108,
+ .sta_ofs = 0x0100,
+};
+
+static const struct mtk_gate_regs mm1_cg_regs = {
+ .set_ofs = 0x0114,
+ .clr_ofs = 0x0118,
+ .sta_ofs = 0x0110,
+};
+
+#define GATE_MM0(_id, _name, _parent, _shift) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_name = _parent, \
+ .regs = &mm0_cg_regs, \
+ .shift = _shift,\
+ .ops = &mtk_clk_gate_ops_setclr,\
+ }
+
+#define GATE_MM1(_id, _name, _parent, _shift) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_name = _parent, \
+ .regs = &mm1_cg_regs, \
+ .shift = _shift,\
+ .ops = &mtk_clk_gate_ops_setclr,\
+ }
+
+static const struct mtk_gate mt8173_mm_clks[] = {
+ /* MM0 */
+ GATE_MM0(CLK_MM_SMI_COMMON, "mm_smi_common", "mm_sel", 0),
+ GATE_MM0(CLK_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 1),
+ GATE_MM0(CLK_MM_CAM_MDP, "mm_cam_mdp", "mm_sel", 2),
+ GATE_MM0(CLK_MM_MDP_RDMA0, "mm_mdp_rdma0", "mm_sel", 3),
+ GATE_MM0(CLK_MM_MDP_RDMA1, "mm_mdp_rdma1", "mm_sel", 4),
+ GATE_M
Re: [PATCH V4 1/3] dt: bindings: brcmnand: Add support for flash-edu
On Wed, 2020-01-22 at 21:33:11 UTC, Kamal Dasu wrote: > Adding support for EBI DMA unit (EDU). > > Signed-off-by: Kamal Dasu > Reviewed-by: Rob Herring Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks. Miquel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hmm 2/8] mm/hmm: don't free the cached pgmap while scanning
From: Jason Gunthorpe
The pgmap is held in the hmm_vma_walk variable in hope of speeding up
future get_dev_pagemap() calls by hitting the same pointer. The algorithm
doesn't actually care about how long the pgmap is held for.
Move the put of the cached pgmap to after the walk is completed and delete
all the other now redundant puts.
This solves a possible leak of the reference in hmm_vma_walk_pmd() if a
hmm_vma_handle_pte() fails while looping.
Fixes: 992de9a8b751 ("mm/hmm: allow to mirror vma of a file on a DAX backed
filesystem")
Signed-off-by: Jason Gunthorpe
---
mm/hmm.c | 31 +--
1 file changed, 9 insertions(+), 22 deletions(-)
We talked about just deleting this stuff, but I think it makes alot sense for
hmm_range_fault() to trigger fault on devmap pages that are not compatible
with the caller - so lets just fix the leak on error path for now.
diff --git a/mm/hmm.c b/mm/hmm.c
index 35f85424176d14..9e8f68eb83287a 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -239,10 +239,6 @@ static int hmm_vma_handle_pmd(struct mm_walk *walk,
unsigned long addr,
}
pfns[i] = hmm_device_entry_from_pfn(range, pfn) | cpu_flags;
}
- if (hmm_vma_walk->pgmap) {
- put_dev_pagemap(hmm_vma_walk->pgmap);
- hmm_vma_walk->pgmap = NULL;
- }
hmm_vma_walk->last = end;
return 0;
}
@@ -360,10 +356,6 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
unsigned long addr,
return 0;
fault:
- if (hmm_vma_walk->pgmap) {
- put_dev_pagemap(hmm_vma_walk->pgmap);
- hmm_vma_walk->pgmap = NULL;
- }
pte_unmap(ptep);
/* Fault any virtual address we were asked to fault */
return hmm_vma_walk_hole_(addr, end, fault, write_fault, walk);
@@ -446,16 +438,6 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
return r;
}
}
- if (hmm_vma_walk->pgmap) {
- /*
-* We do put_dev_pagemap() here and not in hmm_vma_handle_pte()
-* so that we can leverage get_dev_pagemap() optimization which
-* will not re-take a reference on a pgmap if we already have
-* one.
-*/
- put_dev_pagemap(hmm_vma_walk->pgmap);
- hmm_vma_walk->pgmap = NULL;
- }
pte_unmap(ptep - 1);
hmm_vma_walk->last = addr;
@@ -529,10 +511,6 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long
start, unsigned long end,
pfns[i] = hmm_device_entry_from_pfn(range, pfn) |
cpu_flags;
}
- if (hmm_vma_walk->pgmap) {
- put_dev_pagemap(hmm_vma_walk->pgmap);
- hmm_vma_walk->pgmap = NULL;
- }
hmm_vma_walk->last = end;
goto out_unlock;
}
@@ -694,6 +672,15 @@ long hmm_range_fault(struct hmm_range *range, unsigned int
flags)
return -EBUSY;
ret = walk_page_range(mm, hmm_vma_walk.last, range->end,
&hmm_walk_ops, &hmm_vma_walk);
+ /*
+* A pgmap is kept cached in the hmm_vma_walk to avoid expensive
+* searching in the probably common case that the pgmap is the
+* same for the entire requested range.
+*/
+ if (hmm_vma_walk.pgmap) {
+ put_dev_pagemap(hmm_vma_walk.pgmap);
+ hmm_vma_walk.pgmap = NULL;
+ }
} while (ret == -EBUSY);
if (ret)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/2] Add LVDS panel support to HiHope RZ/G2M
Dear All, The HiHope RZ/G2M is advertised as supporting panel idk-1110wr from Advantech, but the panel doesn't come with the board, it has to purchased separatey, therefore this series adds panel support to a new DT. v3->v4 * Included rzg2-advantech-idk-1110wr-panel.dtsi in r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts file instead of re-inventing the wheel. * Dropped the Ack from Laurent for patch 2/2 due to above changes v2->v3 * Included Reviewed-by from Rob and Laurent * Switched to dual license * Added myself as the maintainer * Updated copyright year * Rebased the patches v1->v2 * fixed a space according to Geert's feedback. Thanks, Prabhakar Fabrizio Castro (2): dt-bindings: display: Add idk-1110wr binding arm64: dts: renesas: Add HiHope RZ/G2M board with idk-1110wr display .../display/panel/advantech,idk-1110wr.yaml| 69 ++ arch/arm64/boot/dts/renesas/Makefile | 1 + .../r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts| 52 3 files changed, 122 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml create mode 100644 arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/panel: Add Starry KR070PE2T
On 2020-03-10 19:54, Sam Ravnborg wrote:
A few things to improve.
The binding should be a separate patch.
subject - shall start with dt-bindings:
Shall be sent to deveicetree mailing list.
Hi Sam,
Thank you very much for your review.
I did consider this. The reason I combined the patches, is that the
binding depends on the display so I thought they were related in some
way. Didn't know the correct procedure to handle this. I will split them
apart in v2.
---
.../display/panel/starry,kr070pe2t.txt| 7 +
drivers/gpu/drm/panel/panel-simple.c | 26
+++
2 files changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
b/Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
new file mode 100644
index 0..699ad5eb2
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/starry,kr070pe2t.txt
@@ -0,0 +1,7 @@
+Starry 7" (800x480 pixels) LCD panel
+
+Required properties:
+- compatible: should be "starry,kr070pe2t"
+
+This binding is compatible with the simple-panel binding, which is
specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index e14c14ac6..027a2612b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2842,6 +2842,29 @@ static const struct panel_desc
shelly_sca07010_bfn_lnn = {
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct drm_display_mode starry_kr070pe2t_mode = {
+ .clock = 33000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 209,
+ .hsync_end = 800 + 209 + 1,
+ .htotal = 800 + 209 + 1 + 45,
+ .vdisplay = 480,
+ .vsync_start = 480 + 22,
+ .vsync_end = 480 + 22 + 1,
+ .vtotal = 480 + 22 + 1 + 22,
+ .vrefresh = 60,
+};
Please adjust so:
vrefresh * htotal * vtotal == clock.
I cannot say what needs to be adjusted.
But we are moving away from specifying vrefresh and want the
data to be OK.
Just like Ville Syrjälä, I ran the numbers and vrefresh indeed
calculates to 59.58.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/arc: Filter out interlaced mode
Hi David, Daniel! The following changes since commit e3c3b6e66da1caeb39a504b03ddcdd3693e45254: Merge tag 'exynos-drm-fixes-for-v5.6-rc5-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes (2020-03-12 11:02:52 +1000) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2020.03.12 for you to fetch changes up to 1e8928584e8f29c31c8db1a50b5bdb1769047434: DRM: ARC: PGU: interlaced mode not supported (2020-03-12 07:59:06 +0300) There's just one tiny fix this time around with explicit filtering of interlaced modes as they are not supported by ARC PGU hardware. Eugeniy Paltsev (1): DRM: ARC: PGU: interlaced mode not supported drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +++ 1 file changed, 3 insertions(+) Note this is based on the current drm/drm-fixes contents. Thanks, Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: amd/acp: fix broken menu structure
From: Randy Dunlap
Fix the Kconfig dependencies so that the menu is presented
correctly by adding a dependency on DRM_AMDGPU to the "menu"
Kconfig statement. This makes a continuous dependency on
DRM_AMDGPU in the DRM AMD menus and eliminates a broken menu
structure.
Fixes: a8fe58cec351 ("drm/amd: add ACP driver support")
Signed-off-by: Randy Dunlap
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: Maruthi Bayyavarapu
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/acp/Kconfig |1 +
1 file changed, 1 insertion(+)
--- linux-next.orig/drivers/gpu/drm/amd/acp/Kconfig
+++ linux-next/drivers/gpu/drm/amd/acp/Kconfig
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: MIT
menu "ACP (Audio CoProcessor) Configuration"
+ depends on DRM_AMDGPU
config DRM_AMD_ACP
bool "Enable AMD Audio CoProcessor IP support"
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hmm 6/8] mm/hmm: reorganize how !pte_present is handled in hmm_vma_handle_pte()
From: Jason Gunthorpe
The intention with this code is to determine if the caller required the
pages to be valid, and if so, then take some action to make them valid.
The action varies depending on the page type.
In all cases, if the caller doesn't ask for the page, then
hmm_range_fault() should not return an error.
Revise the implementation to be clearer, and fix some bugs:
- hmm_pte_need_fault() must always be called before testing fault or
write_fault otherwise the defaults of false apply and the if()'s don't
work. This was missed on the is_migration_entry() branch
- -EFAULT should not be returned unless hmm_pte_need_fault() indicates
fault is required - ie snapshotting should not fail.
- For !pte_present() the cpu_flags are always 0, except in the special
case of is_device_private_entry(), calling pte_to_hmm_pfn_flags() is
confusing.
Reorganize the flow so that it always follows the pattern of calling
hmm_pte_need_fault() and then checking fault || write_fault.
Fixes: 2aee09d8c116 ("mm/hmm: change hmm_vma_fault() to allow write fault on
page basis")
Signed-off-by: Jason Gunthorpe
---
mm/hmm.c | 35 +++
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index e10cd0adba7b37..bf676cfef3e8ee 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -282,15 +282,6 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
unsigned long addr,
if (!pte_present(pte)) {
swp_entry_t entry = pte_to_swp_entry(pte);
- if (!non_swap_entry(entry)) {
- cpu_flags = pte_to_hmm_pfn_flags(range, pte);
- hmm_pte_need_fault(hmm_vma_walk, orig_pfn, cpu_flags,
- &fault, &write_fault);
- if (fault || write_fault)
- goto fault;
- return 0;
- }
-
/*
* This is a special swap entry, ignore migration, use
* device and report anything else as error.
@@ -310,26 +301,30 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
unsigned long addr,
return 0;
}
- if (is_migration_entry(entry)) {
- if (fault || write_fault) {
- pte_unmap(ptep);
- hmm_vma_walk->last = addr;
- migration_entry_wait(walk->mm, pmdp, addr);
- return -EBUSY;
- }
+ hmm_pte_need_fault(hmm_vma_walk, orig_pfn, 0, &fault,
+ &write_fault);
+ if (!fault && !write_fault)
return 0;
+
+ if (!non_swap_entry(entry))
+ goto fault;
+
+ if (is_migration_entry(entry)) {
+ pte_unmap(ptep);
+ hmm_vma_walk->last = addr;
+ migration_entry_wait(walk->mm, pmdp, addr);
+ return -EBUSY;
}
/* Report error for everything else */
pte_unmap(ptep);
*pfn = range->values[HMM_PFN_ERROR];
return -EFAULT;
- } else {
- cpu_flags = pte_to_hmm_pfn_flags(range, pte);
- hmm_pte_need_fault(hmm_vma_walk, orig_pfn, cpu_flags,
- &fault, &write_fault);
}
+ cpu_flags = pte_to_hmm_pfn_flags(range, pte);
+ hmm_pte_need_fault(hmm_vma_walk, orig_pfn, cpu_flags, &fault,
+ &write_fault);
if (fault || write_fault)
goto fault;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 5/5] soc / drm: mediatek: Fix mediatek-drm device probing
In the actual implementation the same compatible string
"mediatek,-mmsys" is used to bind the clock drivers
(drivers/soc/mediatek) as well as to the gpu driver
(drivers/gpu/drm/mediatek/mtk_drm_drv.c). This ends with the problem
that the only probed driver is the clock driver and there is no display
at all.
In any case having the same compatible string for two drivers is not
correct and should be fixed. To fix this, and maintain backward
compatibility, we can consider that the mmsys driver is the top-level
entry point for the multimedia subsystem, so is not a pure clock
controller but a system controller, and the drm driver is instantiated
by that MMSYS driver.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: CK Hu
---
Changes in v11: None
Changes in v10:
- Match driver data to get display routing.
Changes in v9:
- Do not move the display routing from the drm driver (CK)
Changes in v8:
- New patch introduced in this series.
Changes in v7: None
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 31 --
drivers/soc/mediatek/mtk-mmsys.c | 6 +
2 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 208f9c5256ef..bb26e346750a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -422,9 +422,21 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ }
};
+static const struct of_device_id mtk_drm_of_ids[] = {
+ { .compatible = "mediatek,mt2701-mmsys",
+ .data = &mt2701_mmsys_driver_data},
+ { .compatible = "mediatek,mt2712-mmsys",
+ .data = &mt2712_mmsys_driver_data},
+ { .compatible = "mediatek,mt8173-mmsys",
+ .data = &mt8173_mmsys_driver_data},
+ { }
+};
+
static int mtk_drm_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
+ struct device_node *phandle = dev->parent->of_node;
+ const struct of_device_id *of_id;
struct mtk_drm_private *private;
struct device_node *node;
struct component_match *match = NULL;
@@ -442,8 +454,14 @@ static int mtk_drm_probe(struct platform_device *pdev)
return -ENODEV;
}
+ of_id = of_match_node(mtk_drm_of_ids, phandle);
+ if (!of_id)
+ return -ENODEV;
+
+ private->data = of_id->data;
+
/* Iterate over sibling DISP function blocks */
- for_each_child_of_node(dev->of_node->parent, node) {
+ for_each_child_of_node(phandle->parent, node) {
const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
@@ -575,22 +593,11 @@ static int mtk_drm_sys_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
mtk_drm_sys_resume);
-static const struct of_device_id mtk_drm_of_ids[] = {
- { .compatible = "mediatek,mt2701-mmsys",
- .data = &mt2701_mmsys_driver_data},
- { .compatible = "mediatek,mt2712-mmsys",
- .data = &mt2712_mmsys_driver_data},
- { .compatible = "mediatek,mt8173-mmsys",
- .data = &mt8173_mmsys_driver_data},
- { }
-};
-
static struct platform_driver mtk_drm_platform_driver = {
.probe = mtk_drm_probe,
.remove = mtk_drm_remove,
.driver = {
.name = "mediatek-drm",
- .of_match_table = mtk_drm_of_ids,
.pm = &mtk_drm_pm_ops,
},
};
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 4b286b525cd3..32a92ec447c5 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -285,6 +285,7 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
const struct mtk_mmsys_driver_data *data;
struct device *dev = &pdev->dev;
struct platform_device *clks;
+ struct platform_device *drm;
void __iomem *config_regs;
struct resource *mem;
int ret;
@@ -307,6 +308,11 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
if (IS_ERR(clks))
return PTR_ERR(clks);
+ drm = platform_device_register_data(&pdev->dev, "mediatek-drm",
+ PLATFORM_DEVID_AUTO, NULL, 0);
+ if (IS_ERR(drm))
+ return PTR_ERR(drm);
+
return 0;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hmm 5/8] mm/hmm: add missing call to hmm_range_need_fault() before returning EFAULT
From: Jason Gunthorpe
All return paths that do EFAULT must call hmm_range_need_fault() to
determine if the user requires this page to be valid.
If the page cannot be made valid if the user later requires it, due to vma
flags in this case, then the return should be HMM_PFN_ERROR.
Fixes: a3e0d41c2b1f ("mm/hmm: improve driver API to work and wait over a range")
Signed-off-by: Jason Gunthorpe
---
mm/hmm.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 5f5ccf13dd1e85..e10cd0adba7b37 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -582,18 +582,15 @@ static int hmm_vma_walk_test(unsigned long start,
unsigned long end,
struct vm_area_struct *vma = walk->vma;
/*
-* Skip vma ranges that don't have struct page backing them or
-* map I/O devices directly.
-*/
- if (vma->vm_flags & (VM_IO | VM_PFNMAP | VM_MIXEDMAP))
- return -EFAULT;
-
- /*
+* Skip vma ranges that don't have struct page backing them or map I/O
+* devices directly.
+*
* If the vma does not allow read access, then assume that it does not
-* allow write access either. HMM does not support architectures
-* that allow write without read.
+* allow write access either. HMM does not support architectures that
+* allow write without read.
*/
- if (!(vma->vm_flags & VM_READ)) {
+ if ((vma->vm_flags & (VM_IO | VM_PFNMAP | VM_MIXEDMAP)) ||
+ !(vma->vm_flags & VM_READ)) {
bool fault, write_fault;
/*
@@ -607,7 +604,7 @@ static int hmm_vma_walk_test(unsigned long start, unsigned
long end,
if (fault || write_fault)
return -EFAULT;
- hmm_pfns_fill(start, end, range, HMM_PFN_NONE);
+ hmm_pfns_fill(start, end, range, HMM_PFN_ERROR);
hmm_vma_walk->last = end;
/* Skip this vma and continue processing the next vma. */
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 0/5] arm/arm64: mediatek: Fix mt8173 mmsys device probing
Dear all, These patches are intended to solve an old standing issue on some Mediatek devices (mt8173, mt2701 and mt2712 are affected by this issue). Up to now both drivers, clock and drm are probed with the same device tree compatible. But only the first driver gets probed, which in effect breaks graphics on those devices. The MMSYS (Multimedia subsystem) in Mediatek SoCs has some registers to control clock gates (which is used in the clk driver) and some registers to set the routing and enable the differnet blocks of the display and MDP (Media Data Path) subsystem. On this series the clk driver is not a pure clock controller but a system controller that can provide access to the shared registers between the different drivers that need it (mediatek-drm and mediatek-mdp). Hence the MMSYS clk driver was moved to drivers/soc/mediatek and is the entry point (parent) which will trigger the probe of the corresponding mediatek-drm driver. **IMPORTANT** This series only fixes the issue on mt8173 to make it simple and as is the only platform I can test. Similar changes should be applied for mt2701 and mt2712 to have display working. These patches apply on top of linux-next. For reference, here are the links to the old discussions: * v10: https://patchwork.kernel.org/project/linux-mediatek/list/?series=248505 * v9: https://patchwork.kernel.org/project/linux-clk/list/?series=247591 * v8: https://patchwork.kernel.org/project/linux-mediatek/list/?series=244891 * v7: https://patchwork.kernel.org/project/linux-mediatek/list/?series=241217 * v6: https://patchwork.kernel.org/project/linux-mediatek/list/?series=213219 * v5: https://patchwork.kernel.org/project/linux-mediatek/list/?series=44063 * v4: * https://patchwork.kernel.org/patch/10530871/ * https://patchwork.kernel.org/patch/10530883/ * https://patchwork.kernel.org/patch/10530885/ * https://patchwork.kernel.org/patch/10530911/ * https://patchwork.kernel.org/patch/10530913/ * v3: * https://patchwork.kernel.org/patch/10367857/ * https://patchwork.kernel.org/patch/10367861/ * https://patchwork.kernel.org/patch/10367877/ * https://patchwork.kernel.org/patch/10367875/ * https://patchwork.kernel.org/patch/10367885/ * https://patchwork.kernel.org/patch/10367883/ * https://patchwork.kernel.org/patch/10367889/ * https://patchwork.kernel.org/patch/10367907/ * https://patchwork.kernel.org/patch/10367909/ * https://patchwork.kernel.org/patch/10367905/ * v2: No relevant discussion, see v3 * v1: * https://patchwork.kernel.org/patch/10016497/ * https://patchwork.kernel.org/patch/10016499/ * https://patchwork.kernel.org/patch/10016505/ * https://patchwork.kernel.org/patch/10016507/ Best regards, Enric Changes in v11: - Leave the clocks part in drivers/clk (clk-mt8173-mm) - Instantiate the clock driver from the mtk-mmsys driver. - Add default config option to not break anything. - Removed the Reviewed-by CK tag as changed the organization. Changes in v10: - Update the binding documentation for the mmsys system controller. - Renamed to be generic mtk-mmsys - Add driver data support to be able to support diferent SoCs - Select CONFIG_MTK_MMSYS (CK) - Pass device pointer of mmsys device instead of config regs (CK) - Match driver data to get display routing. Changes in v9: - Move mmsys to drivers/soc/mediatek (CK) - Introduced a new patch to move routing control into mmsys driver. - Removed the patch to use regmap as is not needed anymore. - Do not move the display routing from the drm driver (CK) Changes in v8: - Be a builtin_platform_driver like other mediatek mmsys drivers. - New patch introduced in this series. Changes in v7: - Free clk_data->clks as well - Get rid of private data structure Enric Balletbo i Serra (3): dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller soc / drm: mediatek: Move routing control to mmsys device soc / drm: mediatek: Fix mediatek-drm device probing Matthias Brugger (2): drm/mediatek: Omit warning on probe defers clk / soc: mediatek: Move mt8173 MMSYS to platform driver .../bindings/arm/mediatek/mediatek,mmsys.txt | 7 +- drivers/clk/mediatek/Kconfig | 7 + drivers/clk/mediatek/Makefile | 1 + drivers/clk/mediatek/clk-mt8173-mm.c | 146 drivers/clk/mediatek/clk-mt8173.c | 104 -- drivers/gpu/drm/mediatek/Kconfig | 1 + drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 +- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 +- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 +- drivers/gpu/drm/mediatek/mtk_dpi.c| 12 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 259 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.h| 7 - drivers/gpu/drm/mediatek/mtk_drm_drv.c| 45 +-- drivers/gpu/drm/mediatek/mtk_drm_drv.h| 2 +- drivers/gpu/drm/mediatek/mtk_dsi.c|
RE: [PATCH] DRM: ARC: PGU: interlaced mode not supported
Hi Greg, > -Original Message- > From: Greg KH > Sent: Wednesday, March 11, 2020 8:22 PM > To: Eugeniy Paltsev > Cc: dri-devel@lists.freedesktop.org; Alexey Brodkin ; > linux-snps- > a...@lists.infradead.org; linux-ker...@vger.kernel.org; David Airlie > ; Daniel Vetter > ; sta...@vger.kernel.org > Subject: Re: [PATCH] DRM: ARC: PGU: interlaced mode not supported > > On Wed, Mar 11, 2020 at 04:13:10PM +0300, Eugeniy Paltsev wrote: > > Filter out interlaced modes as they are not supported by ARC PGU > > hardware. > > > > Signed-off-by: Eugeniy Paltsev > > --- > > drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c > > b/drivers/gpu/drm/arc/arcpgu_crtc.c > > index 8ae1e1f97a73..c854066d4c75 100644 > > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c > > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c > > @@ -67,6 +67,9 @@ static enum drm_mode_status > > arc_pgu_crtc_mode_valid(struct drm_crtc *crtc, > > long rate, clk_rate = mode->clock * 1000; > > long diff = clk_rate / 200; /* +-0.5% allowed by HDMI spec */ > > > > + if (mode->flags & DRM_MODE_FLAG_INTERLACE) > > + return MODE_NO_INTERLACE; > > + > > rate = clk_round_rate(arcpgu->clk, clk_rate); > > if ((max(rate, clk_rate) - min(rate, clk_rate) < diff) && (rate > 0)) > > return MODE_OK; > > -- > > 2.21.1 > > > > > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read: > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.kernel.org_doc_html_latest_process_stable-2Dkernel- > 2Drules.html&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=oXPD1Sz > FBs-0-4u24Ah1rK1Y65Fma8tJZix0Jih-yqY&s=WTVW1dC7E2oD0muPxtNd9KAHzwIZwEU9jGuCHWx1iQk&e= > for how to do this properly. > > Thanks for the comment. I'll add "Cc: sta...@vger.kernel.org" tag to the patch on committing it to my maintainer tree so one the patch makes its way up to the Linus' tree you'll get notified as usual. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] dt-bindings: display: convert rockchip vop bindings to yaml
Current dts files with 'vop' nodes are manually verified.
In order to automate this process rockchip-vop.txt
has to be converted to yaml.
Signed-off-by: Johan Jonker
---
Changes v3:
Change description
Changes v2:
No new properties
---
.../bindings/display/rockchip/rockchip-vop.txt | 74
.../bindings/display/rockchip/rockchip-vop.yaml| 126 +
2 files changed, 126 insertions(+), 74 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
deleted file mode 100644
index 8b3a5f514..0
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-device-tree bindings for rockchip soc display controller (vop)
-
-VOP (Visual Output Processor) is the Display Controller for the Rockchip
-series of SoCs which transfers the image data from a video memory
-buffer to an external LCD interface.
-
-Required properties:
-- compatible: value should be one of the following
- "rockchip,rk3036-vop";
- "rockchip,rk3126-vop";
- "rockchip,px30-vop-lit";
- "rockchip,px30-vop-big";
- "rockchip,rk3066-vop";
- "rockchip,rk3188-vop";
- "rockchip,rk3288-vop";
- "rockchip,rk3368-vop";
- "rockchip,rk3366-vop";
- "rockchip,rk3399-vop-big";
- "rockchip,rk3399-vop-lit";
- "rockchip,rk3228-vop";
- "rockchip,rk3328-vop";
-
-- reg: Must contain one entry corresponding to the base address and length
- of the register space. Can optionally contain a second entry
- corresponding to the CRTC gamma LUT address.
-
-- interrupts: should contain a list of all VOP IP block interrupts in the
-order: VSYNC, LCD_SYSTEM. The interrupt specifier
-format depends on the interrupt controller used.
-
-- clocks: must include clock specifiers corresponding to entries in the
- clock-names property.
-
-- clock-names: Must contain
- aclk_vop: for ddr buffer transfer.
- hclk_vop: for ahb bus to R/W the phy regs.
- dclk_vop: pixel clock.
-
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - axi
- - ahb
- - dclk
-
-- iommus: required a iommu node
-
-- port: A port node with endpoint definitions as defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Example:
-SoC specific DT entry:
- vopb: vopb@ff93 {
- compatible = "rockchip,rk3288-vop";
- reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
- interrupts = ;
- clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
- clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
- resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru
SRST_LCDC1_DCLK>;
- reset-names = "axi", "ahb", "dclk";
- iommus = <&vopb_mmu>;
- vopb_out: port {
- #address-cells = <1>;
- #size-cells = <0>;
- vopb_out_edp: endpoint@0 {
- reg = <0>;
- remote-endpoint=<&edp_in_vopb>;
- };
- vopb_out_hdmi: endpoint@1 {
- reg = <1>;
- remote-endpoint=<&hdmi_in_vopb>;
- };
- };
- };
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
new file mode 100644
index 0..be363e2e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip SoC display controller (VOP)
+
+description:
+ VOP (Video Out Processor) is the display controller for the Rockchip
+ series of SoCs which transfers the image data from a video memory
+ buffer to an external LCD interface.
+
+maintainers:
+ - Sandy Huang
+ - Heiko Stuebner
+
+properties:
+ compatible:
+oneOf:
+ - const: rockchip,px30-vop-big
+ - const: rockchip,px30-vop-lit
+ - const: rockchip,rk3036-vop
+ - const: rockchip,rk3066-vop
+ - const: rockchip,rk3126-vop
+ - const: rockchip,rk3188-vop
+ - const: rockchip,rk3228-vop
+
Re: [PATCH v2 4/4] MAINTAINERS: add it66121 HDMI bridge driver entry
On Wed, Mar 11, 2020 at 01:51:35PM +0100, Phong LE wrote: > Add Neil Armstrong and myself as maintainers Run parse-maintainers.pl to fix issues. > Signed-off-by: Phong LE > --- > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 37c2963226d4..3d722d723686 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8977,6 +8977,14 @@ T: git git://linuxtv.org/anttip/media_tree.git > S: Maintained > F: drivers/media/tuners/it913x* > > +ITE IT66121 HDMI BRIDGE DRIVER > +M: Phong LE > +M: Neil Armstrong > +S: Maintained > +F: drivers/gpu/drm/bridge/ite-it66121.c > +T: git git://anongit.freedesktop.org/drm/drm-misc > +F: Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml > + > IVTV VIDEO4LINUX DRIVER > M: Andy Walls > L: linux-me...@vger.kernel.org > -- > 2.17.1 > -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation
The max() function call in horizontal timing calculation shouldn't pad a length already subtracted with overhead to overhead, instead it should only prevent the set timing to underflow. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 059939789730..5f2313c40328 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -555,7 +555,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HSA_PACKET_OVERHEAD10 hsa = max((unsigned int)HSA_PACKET_OVERHEAD, - (mode->hsync_end - mode->hsync_start) * Bpp - HSA_PACKET_OVERHEAD); + (mode->hsync_end - mode->hsync_start) * Bpp) - HSA_PACKET_OVERHEAD; /* * The backporch is set using a blanking packet (4 @@ -564,7 +564,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBP_PACKET_OVERHEAD6 hbp = max((unsigned int)HBP_PACKET_OVERHEAD, - (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD); + (mode->htotal - mode->hsync_end) * Bpp) - HBP_PACKET_OVERHEAD; /* * The frontporch is set using a sync event (4 bytes) @@ -574,7 +574,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HFP_PACKET_OVERHEAD16 hfp = max((unsigned int)HFP_PACKET_OVERHEAD, - (mode->hsync_start - mode->hdisplay) * Bpp - HFP_PACKET_OVERHEAD); + (mode->hsync_start - mode->hdisplay) * Bpp) - HFP_PACKET_OVERHEAD; /* * The blanking is set using a sync event (4 bytes) @@ -583,8 +583,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBLK_PACKET_OVERHEAD 10 hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, - (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp - - HBLK_PACKET_OVERHEAD); + (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp) - + HBLK_PACKET_OVERHEAD; /* * And I'm not entirely sure what vblk is about. The driver in -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dt-bindings: display: convert rockchip vop bindings to yaml
Hi johan,
在 2020/3/11 21:05, Johan Jonker 写道:
Current dts files with 'vop' nodes are manually verified.
In order to automate this process rockchip-vop.txt
has to be converted to yaml.
Signed-off-by: Johan Jonker
---
Changes v2:
No new properties
---
.../bindings/display/rockchip/rockchip-vop.txt | 74
.../bindings/display/rockchip/rockchip-vop.yaml| 126 +
2 files changed, 126 insertions(+), 74 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
deleted file mode 100644
index 8b3a5f514..0
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-device-tree bindings for rockchip soc display controller (vop)
-
-VOP (Visual Output Processor) is the Display Controller for the Rockchip
Can you change (Visual Out Processor) to (Video Out Processor) by the
way, we have change this at the latest TRM document. thanks.
-series of SoCs which transfers the image data from a video memory
-buffer to an external LCD interface.
-
-Required properties:
-- compatible: value should be one of the following
- "rockchip,rk3036-vop";
- "rockchip,rk3126-vop";
- "rockchip,px30-vop-lit";
- "rockchip,px30-vop-big";
- "rockchip,rk3066-vop";
- "rockchip,rk3188-vop";
- "rockchip,rk3288-vop";
- "rockchip,rk3368-vop";
- "rockchip,rk3366-vop";
- "rockchip,rk3399-vop-big";
- "rockchip,rk3399-vop-lit";
- "rockchip,rk3228-vop";
- "rockchip,rk3328-vop";
-
-- reg: Must contain one entry corresponding to the base address and length
- of the register space. Can optionally contain a second entry
- corresponding to the CRTC gamma LUT address.
-
-- interrupts: should contain a list of all VOP IP block interrupts in the
-order: VSYNC, LCD_SYSTEM. The interrupt specifier
-format depends on the interrupt controller used.
-
-- clocks: must include clock specifiers corresponding to entries in the
- clock-names property.
-
-- clock-names: Must contain
- aclk_vop: for ddr buffer transfer.
- hclk_vop: for ahb bus to R/W the phy regs.
- dclk_vop: pixel clock.
-
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - axi
- - ahb
- - dclk
-
-- iommus: required a iommu node
-
-- port: A port node with endpoint definitions as defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Example:
-SoC specific DT entry:
- vopb: vopb@ff93 {
- compatible = "rockchip,rk3288-vop";
- reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
- interrupts = ;
- clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
- clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
- resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru
SRST_LCDC1_DCLK>;
- reset-names = "axi", "ahb", "dclk";
- iommus = <&vopb_mmu>;
- vopb_out: port {
- #address-cells = <1>;
- #size-cells = <0>;
- vopb_out_edp: endpoint@0 {
- reg = <0>;
- remote-endpoint=<&edp_in_vopb>;
- };
- vopb_out_hdmi: endpoint@1 {
- reg = <1>;
- remote-endpoint=<&hdmi_in_vopb>;
- };
- };
- };
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
new file mode 100644
index 0..cb88849f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip soc display controller (VOP)
+
+description:
+ VOP (Visual Output Processor) is the Display Controller for the Rockchip
+ series of SoCs which transfers the image data from a video memory
+ buffer to an external LCD interface.
+
+maintainers:
+ - Sandy Huang
+ - Heiko Stuebner
+
+properties:
+ compatible:
+oneOf:
+ - const: rockchip,px30-vop-big
+ - const: rockchip,px30-vop-lit
+ - const: roc
[PATCH 0/5] Add support for PinePhone LCD panel
This patchset adds support for the LCD panel of PinePhone. The first 3 patches are for the panel itself, and the last 2 patches are for enabling it on PinePhone. PATCH 4 is the fix of a bug in sun6i_mipi_dsi which will gets triggered on XBD599. Icenowy Zheng (5): dt-bindings: vendor-prefixes: Add Xingbangda dt-bindings: panel: add binding for Xingbangda XBD599 panel drm: panel: add Xingbangda XBD599 panel drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone .../display/panel/xingbangda,xbd599.yaml | 50 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-xingbangda-xbd599.c | 367 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 10 +- 7 files changed, 471 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/4] drm/prime: add support for virtio exported objects
This change exposes dma-buf's get_uuid callback to PRIME drivers.
Signed-off-by: David Stevens
---
drivers/gpu/drm/drm_prime.c | 23 +++
include/drm/drm_drv.h | 10 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 86d9b0e45c8c..50fed8497d3c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -779,6 +779,28 @@ int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct
vm_area_struct *vma)
}
EXPORT_SYMBOL(drm_gem_dmabuf_mmap);
+/**
+ * drm_gem_dmabuf_get_uuid - dma_buf get_uuid implementation for GEM
+ * @dma_buf: buffer to query
+ * @uuid: uuid outparam
+ *
+ * Queries the buffer's virtio UUID. This can be used as the
+ * &dma_buf_ops.get_uuid callback. Calls into &drm_driver.gem_prime_get_uuid.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_gem_dmabuf_get_uuid(struct dma_buf *dma_buf, uuid_t *uuid)
+{
+ struct drm_gem_object *obj = dma_buf->priv;
+ struct drm_device *dev = obj->dev;
+
+ if (!dev->driver->gem_prime_get_uuid)
+ return -ENODEV;
+
+ return dev->driver->gem_prime_get_uuid(obj, uuid);
+}
+EXPORT_SYMBOL(drm_gem_dmabuf_get_uuid);
+
static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = {
.cache_sgt_mapping = true,
.attach = drm_gem_map_attach,
@@ -789,6 +811,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
.mmap = drm_gem_dmabuf_mmap,
.vmap = drm_gem_dmabuf_vmap,
.vunmap = drm_gem_dmabuf_vunmap,
+ .get_uuid = drm_gem_dmabuf_get_uuid,
};
/**
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 77685ed7aa65..61e3ff341844 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -29,6 +29,7 @@
#include
#include
+#include
#include
@@ -639,6 +640,15 @@ struct drm_driver {
int (*gem_prime_mmap)(struct drm_gem_object *obj,
struct vm_area_struct *vma);
+ /**
+* @gem_prime_get_uuid
+*
+* get_uuid hook for GEM drivers. Retrieves the virtio uuid of the
+* given GEM buffer.
+*/
+ int (*gem_prime_get_uuid)(struct drm_gem_object *obj,
+ uuid_t *uuid);
+
/**
* @dumb_create:
*
--
2.25.1.481.gfbce0eb801-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 6/8] MIPS: DTS: jz4780: account for Synopsys HDMI driver and LCD controller
Hi Paul, > Am 11.03.2020 um 14:20 schrieb Paul Cercueil : > > Hi Nikolaus, > > > Le mer., mars 11, 2020 at 13:43, H. Nikolaus Schaller a > écrit : >> Hi Paul, >>> The JZ4780's LCD controller is much newer than the JZ4740 one, so even if >>> it works with the "ingenic,jz4740-lcd" compatible string, you want it as a >>> fallback. >>> So this should be: compatible = "ingenic,jz4780-lcd", "ingenic,jz4740-lcd". >>> That means the YAML should be updated too. >> I have started to look into jz4780 HDMI setup again. >> Well, there is no driver compatible to "ingenic,jz4780-lcd" so far >> and it is questionalbe if we need a different one. >> I think we should rather make the driver also compatible >> than adding a fallback to ingenic,jz4740-lcdto the DTS. >> The reason why this is better even if both LCDC are almost >> compatible is that the jz4780 allows for much bigger displays >> and therefore should have its own jz_soc_info with 4k x 2k >> as maximum. > > Sure, feel free to extend the driver. > >> Next I tried to find out if the LCDC are really compatible. >> Well the jz4780 has two lcdc instances but they are separated >> by the reg addr. Next, there are unique features (like picture in >> picture with alpha blending) but those are probably disabled >> if not programmed from reset state. This may become a reason >> to separate or augment the driver for the jz4780 but at the >> moment we can ignore that. > > Two LCDC instances -> two lcd-controller@... nodes. It's that simple. Indeed :) > > The other features you listed are outside the LCDC, so outside the scope of > this driver. Well, in the description they are mixed but I think we do not have to care about now. > >> There are also subtly different bit definitions and register >> widths (e.g. 24 bit in addition to 16/18 bit modes or more bits >> for the sync position) but it looks as if the ingenic_drm >> driver already handles this. >> Then I tried to read back the registers. Strangely they >> are all 0x. So there is no programming of the >> lcd-controller in our DT setup with HDMI at all! > > How did you read them? I used devmem2 (may be an omap tool I have recompiled for MIPS - it uses /dev/mem). > Do it from the regmap: should be "cat > /sys/kernel/debug/regmap/1305.lcd-controller/registers" (not sure about > the path) Well seems to give the same result: root@letux:~# cat /sys/kernel/debug/regmap/1305.lcd-controller/registers 00: 04: 08: 0c: 10: 14: 18: 1c: 20: 24: 28: 2c: 30: 34: 38: 3c: 40: 44: 48: 4c: 50: 54: 58: 5c: root@letux:~# > >> I also checked that ingenic_drm_probe() is called and >> returns successfully 0. It also reports that a /dev/fb >> has been created: >> [7.908830] ingenic-drm 1305.lcd-controller: fb0: ingenic-drmdrmf >> frame buffer device >> But for example ingenic_drm_encoder_atomic_mode_set() is >> never called which should write some registers of the LCDC. >> I only did see some calls to ingenic_drm_encoder_atomic_check(). >> This of course explains why we have no HDMI signals despite >> proper HPD and a /dev/fb0. Because the LCDC is not being >> programmed. > > It won't be called until the HDMI driver says that the cable is plugged, and > there's a client application (e.g. fbdev emulation) running. So the problem > is most likely within the HDMI driver. Ok! The HDMI subsystem says (with some printk inserted) on cable unplug/replug: root@letux:~# [ 3894.370706] dw_hdmi_update_power [ 3894.373984] dw_hdmi_update_power: hdmi->force=0 [ 3894.378759] dw_hdmi_update_power: hdmi->disabled=0 [ 3894.383756] dw_hdmi_update_power: hdmi->bridge_is_on=1 [ 3894.388947] dw_hdmi_update_power: hdmi->rxsense=1 [ 3894.393831] dw_hdmi_update_power: force=2 [ 3894.397895] dw_hdmi_update_power: hdmi->bridge_is_on=1 [ 3894.403200] dw_hdmi_phy_update_hpd [ 3894.406784] dw_hdmi_update_power [ 3894.410054] dw_hdmi_update_power: hdmi->force=0 [ 3894.414766] dw_hdmi_update_power: hdmi->disabled=0 [ 3894.419611] dw_hdmi_update_power: hdmi->bridge_is_on=1 [ 3894.424928] dw_hdmi_update_power: hdmi->rxsense=1 [ 3894.429699] dw_hdmi_update_power: force=2 [ 3894.433876] dw_hdmi_update_power: hdmi->bridge_is_on=1 [ 3894.439068] dw_hdmi_phy_update_hpd [ 3894.452316] dw_hdmi_update_power [ 3894.455596] dw_hdmi_update_power: hdmi->force=0 [ 3894.460150] dw_hdmi_update_power: hdmi->disabled=0 [ 3894.464967] dw_hdmi_update_power: hdmi->bridge_is_on=1 [ 3894.470131] dw_hdmi_update_power: hdmi->rxsense=1 [ 3894.475051] dw_hdmi_update_power: force=2 [ 3894.479111] dw_hdmi_update_power: hdmi->bridge_is_on=1 [ 3894.484423] dw_hdmi_phy_update_hpd [ 3894.488007] dw_hdmi_update_power [ 3894.491278] dw_hdmi_update_power: hdmi->force=0 [ 3894.495982] dw_hdmi_update_power: hdmi->disabled=0 [ 3894.500823] dw_hdmi_
[PATCH hmm 4/8] mm/hmm: add missing pfns set to hmm_vma_walk_pmd()
From: Jason Gunthorpe
All success exit paths from the walker functions must set the pfns array.
A migration entry with no required fault is a HMM_PFN_NONE return, just
like the pte case.
Fixes: d08faca018c4 ("mm/hmm: properly handle migration pmd")
Signed-off-by: Jason Gunthorpe
---
mm/hmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 32dcbfd3908315..5f5ccf13dd1e85 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -394,7 +394,7 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
pmd_migration_entry_wait(walk->mm, pmdp);
return -EBUSY;
}
- return 0;
+ return hmm_pfns_fill(start, end, range, HMM_PFN_NONE);
} else if (!pmd_present(pmd))
return hmm_pfns_fill(start, end, range, HMM_PFN_ERROR);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 05/17] drm/arc: make arcgpu_debugfs_init() return 0.
Hi Wambui, > -Original Message- > From: Wambui Karuga > Sent: Tuesday, March 10, 2020 8:31 PM > To: airl...@linux.ie; dan...@ffwll.ch; Alexey Brodkin > Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; > gre...@linuxfoundation.org > Subject: [PATCH v2 05/17] drm/arc: make arcgpu_debugfs_init() return 0. > > Since commit 987d65d01356 (drm: debugfs: make > drm_debugfs_create_files() never fail), drm_debugfs_create_files() never > fails and should return void. Therefore, remove its use as the > return value of arcpgu_debugfs_init() and have the latter function return > 0 directly. > > v2: convert the function to return 0 instead of void to avoid breaking > the build and ensure that this individual patch compiles properly. > > References: > https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html > Signed-off-by: Wambui Karuga Thanks for the patch! Acked-by: Alexey Brodkin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 5/5] soc / drm: mediatek: Fix mediatek-drm device probing
In the actual implementation the same compatible string
"mediatek,-mmsys" is used to bind the clock drivers
(drivers/soc/mediatek) as well as to the gpu driver
(drivers/gpu/drm/mediatek/mtk_drm_drv.c). This ends with the problem
that the only probed driver is the clock driver and there is no display
at all.
In any case having the same compatible string for two drivers is not
correct and should be fixed. To fix this, and maintain backward
compatibility, we can consider that the mmsys driver is the top-level
entry point for the multimedia subsystem, so is not a pure clock
controller but a system controller, and the drm driver is instantiated
by that MMSYS driver.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: CK Hu
Acked-by: CK Hu
---
Changes in v12: None
Changes in v10:
- Match driver data to get display routing.
Changes in v9:
- Do not move the display routing from the drm driver (CK)
Changes in v8:
- New patch introduced in this series.
Changes in v7: None
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 31 --
drivers/soc/mediatek/mtk-mmsys.c | 6 +
2 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 208f9c5256ef..bb26e346750a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -422,9 +422,21 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ }
};
+static const struct of_device_id mtk_drm_of_ids[] = {
+ { .compatible = "mediatek,mt2701-mmsys",
+ .data = &mt2701_mmsys_driver_data},
+ { .compatible = "mediatek,mt2712-mmsys",
+ .data = &mt2712_mmsys_driver_data},
+ { .compatible = "mediatek,mt8173-mmsys",
+ .data = &mt8173_mmsys_driver_data},
+ { }
+};
+
static int mtk_drm_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
+ struct device_node *phandle = dev->parent->of_node;
+ const struct of_device_id *of_id;
struct mtk_drm_private *private;
struct device_node *node;
struct component_match *match = NULL;
@@ -442,8 +454,14 @@ static int mtk_drm_probe(struct platform_device *pdev)
return -ENODEV;
}
+ of_id = of_match_node(mtk_drm_of_ids, phandle);
+ if (!of_id)
+ return -ENODEV;
+
+ private->data = of_id->data;
+
/* Iterate over sibling DISP function blocks */
- for_each_child_of_node(dev->of_node->parent, node) {
+ for_each_child_of_node(phandle->parent, node) {
const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
@@ -575,22 +593,11 @@ static int mtk_drm_sys_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
mtk_drm_sys_resume);
-static const struct of_device_id mtk_drm_of_ids[] = {
- { .compatible = "mediatek,mt2701-mmsys",
- .data = &mt2701_mmsys_driver_data},
- { .compatible = "mediatek,mt2712-mmsys",
- .data = &mt2712_mmsys_driver_data},
- { .compatible = "mediatek,mt8173-mmsys",
- .data = &mt8173_mmsys_driver_data},
- { }
-};
-
static struct platform_driver mtk_drm_platform_driver = {
.probe = mtk_drm_probe,
.remove = mtk_drm_remove,
.driver = {
.name = "mediatek-drm",
- .of_match_table = mtk_drm_of_ids,
.pm = &mtk_drm_pm_ops,
},
};
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 4b286b525cd3..32a92ec447c5 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -285,6 +285,7 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
const struct mtk_mmsys_driver_data *data;
struct device *dev = &pdev->dev;
struct platform_device *clks;
+ struct platform_device *drm;
void __iomem *config_regs;
struct resource *mem;
int ret;
@@ -307,6 +308,11 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
if (IS_ERR(clks))
return PTR_ERR(clks);
+ drm = platform_device_register_data(&pdev->dev, "mediatek-drm",
+ PLATFORM_DEVID_AUTO, NULL, 0);
+ if (IS_ERR(drm))
+ return PTR_ERR(drm);
+
return 0;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/4] drm/virtio: Support virtgpu exported resources
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++
drivers/gpu/drm/virtio/virtgpu_drv.h | 18 +
drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++
drivers/gpu/drm/virtio/virtgpu_prime.c | 41 +--
drivers/gpu/drm/virtio/virtgpu_vq.c| 55 ++
5 files changed, 118 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index ab4bed78e656..776e6667042e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -165,6 +165,7 @@ static unsigned int features[] = {
VIRTIO_GPU_F_VIRGL,
#endif
VIRTIO_GPU_F_EDID,
+ VIRTIO_GPU_F_RESOURCE_UUID,
};
static struct virtio_driver virtio_gpu_driver = {
.feature_table = features,
@@ -202,7 +203,9 @@ static struct drm_driver driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_mmap = drm_gem_prime_mmap,
+ .gem_prime_export = virtgpu_gem_prime_export,
.gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
+ .gem_prime_get_uuid = virtgpu_gem_prime_get_uuid,
.gem_create_object = virtio_gpu_create_object,
.fops = &virtio_gpu_driver_fops,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index af9403e1cf78..fab65f0f5a4d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -49,6 +49,10 @@
#define DRIVER_MINOR 1
#define DRIVER_PATCHLEVEL 0
+#define UUID_INITIALIZING 0
+#define UUID_INITIALIZED 1
+#define UUID_INITIALIZATION_FAILED 2
+
struct virtio_gpu_object_params {
uint32_t format;
uint32_t width;
@@ -75,6 +79,9 @@ struct virtio_gpu_object {
bool dumb;
bool created;
+
+ int uuid_state;
+ uuid_t uuid;
};
#define gem_to_virtio_gpu_obj(gobj) \
container_of((gobj), struct virtio_gpu_object, base.base)
@@ -196,6 +203,7 @@ struct virtio_gpu_device {
bool has_virgl_3d;
bool has_edid;
bool has_indirect;
+ bool has_resource_assign_uuid;
struct work_struct config_changed_work;
@@ -206,6 +214,8 @@ struct virtio_gpu_device {
struct virtio_gpu_drv_capset *capsets;
uint32_t num_capsets;
struct list_head cap_cache;
+
+ spinlock_t resource_export_lock;
};
struct virtio_gpu_fpriv {
@@ -338,6 +348,10 @@ void virtio_gpu_dequeue_fence_func(struct work_struct
*work);
void virtio_gpu_disable_notify(struct virtio_gpu_device *vgdev);
void virtio_gpu_enable_notify(struct virtio_gpu_device *vgdev);
+int
+virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object_array *objs);
+
/* virtio_gpu_display.c */
void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev);
void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev);
@@ -366,6 +380,10 @@ int virtio_gpu_object_create(struct virtio_gpu_device
*vgdev,
struct virtio_gpu_object **bo_ptr,
struct virtio_gpu_fence *fence);
/* virtgpu_prime.c */
+struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj,
+int flags);
+int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj,
+ uuid_t *uuid);
struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
struct drm_device *dev, struct dma_buf_attachment *attach,
struct sg_table *sgt);
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 4009c2f97d08..5a2aeb6d2f35 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -134,6 +134,7 @@ int virtio_gpu_init(struct drm_device *dev)
vgdev->dev = dev->dev;
spin_lock_init(&vgdev->display_info_lock);
+ spin_lock_init(&vgdev->resource_export_lock);
ida_init(&vgdev->ctx_id_ida);
ida_init(&vgdev->resource_ida);
init_waitqueue_head(&vgdev->resp_wq);
@@ -162,6 +163,9 @@ int virtio_gpu_init(struct drm_device *dev)
if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) {
vgdev->has_indirect = true;
}
+ if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) {
+ vgdev->has_resource_assign_uuid = true;
+ }
DRM_INFO("features: %cvirgl %cedid\n",
vgdev->has_virgl_3d ? '+' : '-',
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 050d24c39a8f..7c6357f59877 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prim
[PATCH hmm 3/8] mm/hmm: do not call hmm_vma_walk_hole() while holding a spinlock
From: Jason Gunthorpe
This eventually calls into handle_mm_fault() which is a sleeping function.
Release the lock first.
hmm_vma_walk_hole() does not touch the contents of the PUD, so it does not
need the lock.
Fixes: 3afc423632a1 ("mm: pagewalk: add p4d_entry() and pgd_entry()")
Cc: Steven Price
Signed-off-by: Jason Gunthorpe
---
mm/hmm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 9e8f68eb83287a..32dcbfd3908315 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -473,8 +473,8 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long
start, unsigned long end,
pud = READ_ONCE(*pudp);
if (pud_none(pud)) {
- ret = hmm_vma_walk_hole(start, end, -1, walk);
- goto out_unlock;
+ spin_unlock(ptl);
+ return hmm_vma_walk_hole(start, end, -1, walk);
}
if (pud_huge(pud) && pud_devmap(pud)) {
@@ -483,8 +483,8 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long
start, unsigned long end,
bool fault, write_fault;
if (!pud_present(pud)) {
- ret = hmm_vma_walk_hole(start, end, -1, walk);
- goto out_unlock;
+ spin_unlock(ptl);
+ return hmm_vma_walk_hole(start, end, -1, walk);
}
i = (addr - range->start) >> PAGE_SHIFT;
@@ -495,9 +495,9 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long
start, unsigned long end,
hmm_range_need_fault(hmm_vma_walk, pfns, npages,
cpu_flags, &fault, &write_fault);
if (fault || write_fault) {
- ret = hmm_vma_walk_hole_(addr, end, fault,
-write_fault, walk);
- goto out_unlock;
+ spin_unlock(ptl);
+ return hmm_vma_walk_hole_(addr, end, fault, write_fault,
+ walk);
}
pfn = pud_pfn(pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/2] dt-bindings: display: add visionox rm69299 panel variant
Add bindings for visionox rm69299 panel.
Signed-off-by: Harigovindan P
---
Changes in v2:
- Removed unwanted properties from description.
- Creating source files without execute permissions(Rob Herring).
Changes in v3:
- Changing txt file into yaml
Changes in v4:
- Updating license identifier.
- Moving yaml file inside panel directory.
- Removing pinctrl entries.
- Adding documentation for reset-gpios.
Changes in v5:
- No changes. Updated 2/2 Patch.
Changes in v6:
- Removing patternProperties.
- Added " |" after description.
- Setting port and reset-gpios to true.
- Removing @ae94000 for dsi node.
.../display/panel/visionox,rm69299.yaml | 77 +++
1 file changed, 77 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
new file mode 100644
index ..18854cc7d99e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/visionox,rm69299.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Visionox model RM69299 Panels Device Tree Bindings.
+
+maintainers:
+ - Harigovindan P
+
+description: |
+ This binding is for display panels using a Visionox RM692999 panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: visionox,rm69299-1080p-display
+
+ reg:
+maxItems: 1
+
+ vdda-supply:
+description: |
+ Phandle of the regulator that provides the vdda supply voltage.
+
+ vdd3p3-supply:
+description: |
+ Phandle of the regulator that provides the vdd3p3 supply voltage.
+
+ ports:
+type: object
+description: |
+ A node containing DSI input & output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ Documentation/devicetree/bindings/graph.txt
+ properties:
+port: true
+
+ reset-gpios: true
+
+required:
+ - compatible
+ - reg
+ - vdda-supply
+ - vdd3p3-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+- |
+dsi {
+panel@0 {
+compatible = "visionox,rm69299-1080p-display";
+
+vdda-supply = <&src_pp1800_l8c>;
+vdd3p3-supply = <&src_pp2800_l18a>;
+
+reset-gpios = <&pm6150l_gpio 3 0>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+panel0_in: endpoint {
+remote-endpoint = <&dsi0_out>;
+};
+};
+};
+};
+};
+...
+
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/linux/virtio_gpu.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
index 0c85914d9369..9721d58b4d58 100644
--- a/include/uapi/linux/virtio_gpu.h
+++ b/include/uapi/linux/virtio_gpu.h
@@ -50,6 +50,10 @@
* VIRTIO_GPU_CMD_GET_EDID
*/
#define VIRTIO_GPU_F_EDID1
+/*
+ * VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID
+ */
+#define VIRTIO_GPU_F_RESOURCE_UUID 2
enum virtio_gpu_ctrl_type {
VIRTIO_GPU_UNDEFINED = 0,
@@ -66,6 +70,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_CMD_GET_CAPSET_INFO,
VIRTIO_GPU_CMD_GET_CAPSET,
VIRTIO_GPU_CMD_GET_EDID,
+ VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID,
/* 3d commands */
VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
@@ -87,6 +92,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_RESP_OK_CAPSET_INFO,
VIRTIO_GPU_RESP_OK_CAPSET,
VIRTIO_GPU_RESP_OK_EDID,
+ VIRTIO_GPU_RESP_OK_RESOURCE_UUID,
/* error responses */
VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
@@ -340,4 +346,17 @@ enum virtio_gpu_formats {
VIRTIO_GPU_FORMAT_R8G8B8X8_UNORM = 134,
};
+/* VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID */
+struct virtio_gpu_resource_assign_uuid {
+ struct virtio_gpu_ctrl_hdr hdr;
+ __le32 resource_id;
+ __le32 padding;
+};
+
+/* VIRTIO_GPU_RESP_OK_RESOURCE_UUID */
+struct virtio_gpu_resp_resource_uuid {
+ struct virtio_gpu_ctrl_hdr hdr;
+ __u8 uuid[16];
+};
+
#endif
--
2.25.1.481.gfbce0eb801-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 2/5] dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller
The mmsys system controller is not only a pure clock controller, so
update the binding documentation to reflect that apart from providing
clocks, it also provides routing and miscellaneous control registers.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Matthias Brugger
Reviewed-by: CK Hu
---
Changes in v11: None
Changes in v10:
- Update the binding documentation for the mmsys system controller.
Changes in v9: None
Changes in v8: None
Changes in v7: None
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.txt| 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
index 301eefbe1618..8d6a9d98e7a6 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -1,7 +1,8 @@
Mediatek mmsys controller
-The Mediatek mmsys controller provides various clocks to the system.
+The Mediatek mmsys system controller provides clock control, routing control,
+and miscellaneous control in mmsys partition.
Required Properties:
@@ -15,13 +16,13 @@ Required Properties:
- "mediatek,mt8183-mmsys", "syscon"
- #clock-cells: Must be 1
-The mmsys controller uses the common clk binding from
+For the clock control, the mmsys controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
Example:
-mmsys: clock-controller@1400 {
+mmsys: syscon@1400 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
#clock-cells = <1>;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 5/5] soc / drm: mediatek: Fix mediatek-drm device probing
On 11/03/2020 12:56, Enric Balletbo i Serra wrote: > In the actual implementation the same compatible string > "mediatek,-mmsys" is used to bind the clock drivers > (drivers/soc/mediatek) as well as to the gpu driver > (drivers/gpu/drm/mediatek/mtk_drm_drv.c). This ends with the problem > that the only probed driver is the clock driver and there is no display > at all. > > In any case having the same compatible string for two drivers is not > correct and should be fixed. To fix this, and maintain backward > compatibility, we can consider that the mmsys driver is the top-level > entry point for the multimedia subsystem, so is not a pure clock > controller but a system controller, and the drm driver is instantiated > by that MMSYS driver. > > Signed-off-by: Enric Balletbo i Serra > Reviewed-by: CK Hu Same here. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 6/8] MIPS: DTS: jz4780: account for Synopsys HDMI driver and LCD controller
Hi Paul,
> Am 02.03.2020 um 20:27 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
>
> Le ven., févr. 28, 2020 at 19:19, H. Nikolaus Schaller a
> écrit :
>> From: Paul Boddie
>> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
>> HDMI support. This requires a new driver, plus device tree and configuration
>> modifications.
>> Signed-off-by: Paul Boddie
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> arch/mips/boot/dts/ingenic/jz4780.dtsi | 32 ++
>> 1 file changed, 32 insertions(+)
>> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
>> b/arch/mips/boot/dts/ingenic/jz4780.dtsi
>> index f928329b034b..391d4e1efd35 100644
>> --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
>> +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
>> @@ -433,4 +433,36 @@
>> status = "disabled";
>> };
>> +
>> +hdmi: hdmi@1018 {
>> +compatible = "ingenic,jz4780-dw-hdmi";
>> +reg = <0x1018 0x8000>;
>> +reg-io-width = <4>;
>> +
>> +clocks = <&cgu JZ4780_CLK_HDMI>, <&cgu JZ4780_CLK_AHB0>;
>> +clock-names = "isfr" , "iahb";
>> +
>> +assigned-clocks = <&cgu JZ4780_CLK_HDMI>;
>> +assigned-clock-rates = <2700>;
>
> I *think* this should go to the board file.
>
>> +
>> +interrupt-parent = <&intc>;
>> +interrupts = <3>;
>> +
>> +/* ddc-i2c-bus = <&i2c4>; */
>> +
>> +status = "disabled";
>> +};
>> +
>> +lcd: lcd@1305 {
>
> The node name should be 'lcd-controller'.
>
>> +compatible = "ingenic,jz4740-lcd";
>
> The JZ4780's LCD controller is much newer than the JZ4740 one, so even if it
> works with the "ingenic,jz4740-lcd" compatible string, you want it as a
> fallback.
> So this should be: compatible = "ingenic,jz4780-lcd", "ingenic,jz4740-lcd".
>
> That means the YAML should be updated too.
I have started to look into jz4780 HDMI setup again.
Well, there is no driver compatible to "ingenic,jz4780-lcd" so far
and it is questionalbe if we need a different one.
I think we should rather make the driver also compatible
than adding a fallback to ingenic,jz4740-lcdto the DTS.
The reason why this is better even if both LCDC are almost
compatible is that the jz4780 allows for much bigger displays
and therefore should have its own jz_soc_info with 4k x 2k
as maximum.
Next I tried to find out if the LCDC are really compatible.
Well the jz4780 has two lcdc instances but they are separated
by the reg addr. Next, there are unique features (like picture in
picture with alpha blending) but those are probably disabled
if not programmed from reset state. This may become a reason
to separate or augment the driver for the jz4780 but at the
moment we can ignore that.
There are also subtly different bit definitions and register
widths (e.g. 24 bit in addition to 16/18 bit modes or more bits
for the sync position) but it looks as if the ingenic_drm
driver already handles this.
Then I tried to read back the registers. Strangely they
are all 0x. So there is no programming of the
lcd-controller in our DT setup with HDMI at all!
I also checked that ingenic_drm_probe() is called and
returns successfully 0. It also reports that a /dev/fb
has been created:
[7.908830] ingenic-drm 1305.lcd-controller: fb0: ingenic-drmdrmf frame
buffer device
But for example ingenic_drm_encoder_atomic_mode_set() is
never called which should write some registers of the LCDC.
I only did see some calls to ingenic_drm_encoder_atomic_check().
This of course explains why we have no HDMI signals despite
proper HPD and a /dev/fb0. Because the LCDC is not being
programmed.
Any ideas / hints how to check or improve?
BR and thanks,
Nikolaus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
(I know I'm going to be spammed by so many mailing list ...) Le mercredi 11 mars 2020 à 14:21 -0500, Jason Ekstrand a écrit : > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand wrote: > > All, > > > > Sorry for casting such a broad net with this one. I'm sure most people > > who reply will get at least one mailing list rejection. However, this > > is an issue that affects a LOT of components and that's why it's > > thorny to begin with. Please pardon the length of this e-mail as > > well; I promise there's a concrete point/proposal at the end. > > > > > > Explicit synchronization is the future of graphics and media. At > > least, that seems to be the consensus among all the graphics people > > I've talked to. I had a chat with one of the lead Android graphics > > engineers recently who told me that doing explicit sync from the start > > was one of the best engineering decisions Android ever made. It's > > also the direction being taken by more modern APIs such as Vulkan. > > > > > > ## What are implicit and explicit synchronization? > > > > For those that aren't familiar with this space, GPUs, media encoders, > > etc. are massively parallel and synchronization of some form is > > required to ensure that everything happens in the right order and > > avoid data races. Implicit synchronization is when bits of work (3D, > > compute, video encode, etc.) are implicitly based on the absolute > > CPU-time order in which API calls occur. Explicit synchronization is > > when the client (whatever that means in any given context) provides > > the dependency graph explicitly via some sort of synchronization > > primitives. If you're still confused, consider the following > > examples: > > > > With OpenGL and EGL, almost everything is implicit sync. Say you have > > two OpenGL contexts sharing an image where one writes to it and the > > other textures from it. The way the OpenGL spec works, the client has > > to make the API calls to render to the image before (in CPU time) it > > makes the API calls which texture from the image. As long as it does > > this (and maybe inserts a glFlush?), the driver will ensure that the > > rendering completes before the texturing happens and you get correct > > contents. > > > > Implicit synchronization can also happen across processes. Wayland, > > for instance, is currently built on implicit sync where the client > > does their rendering and then does a hand-off (via wl_surface::commit) > > to tell the compositor it's done at which point the compositor can now > > texture from the surface. The hand-off ensures that the client's > > OpenGL API calls happen before the server's OpenGL API calls. > > > > A good example of explicit synchronization is the Vulkan API. There, > > a client (or multiple clients) can simultaneously build command > > buffers in different threads where one of those command buffers > > renders to an image and the other textures from it and then submit > > both of them at the same time with instructions to the driver for > > which order to execute them in. The execution order is described via > > the VkSemaphore primitive. With the new VK_KHR_timeline_semaphore > > extension, you can even submit the work which does the texturing > > BEFORE the work which does the rendering and the driver will sort it > > out. > > > > The #1 problem with implicit synchronization (which explicit solves) > > is that it leads to a lot of over-synchronization both in client space > > and in driver/device space. The client has to synchronize a lot more > > because it has to ensure that the API calls happen in a particular > > order. The driver/device have to synchronize a lot more because they > > never know what is going to end up being a synchronization point as an > > API call on another thread/process may occur at any time. As we move > > to more and more multi-threaded programming this synchronization (on > > the client-side especially) becomes more and more painful. > > > > > > ## Current status in Linux > > > > Implicit synchronization in Linux works via a the kernel's internal > > dma_buf and dma_fence data structures. A dma_fence is a tiny object > > which represents the "done" status for some bit of work. Typically, > > dma_fences are created as a by-product of someone submitting some bit > > of work (say, 3D rendering) to the kernel. The dma_buf object has a > > set of dma_fences on it representing shared (read) and exclusive > > (write) access to the object. When work is submitted which, for > > instance renders to the dma_buf, it's queued waiting on all the fences > > on the dma_buf and and a dma_fence is created representing the end of > > said rendering work and it's installed as the dma_buf's exclusive > > fence. This way, the kernel can manage all its internal queues (3D > > rendering, display, video encode, etc.) and know which things to > > submit in what order. > > > > For the last few years, we've had sync_file in the kernel and
Re: [PATCH V4 3/3] mtd: rawnand: brcmnand: Add support for flash-edu for dma transfers
On Wed, 2020-01-22 at 21:33:13 UTC, Kamal Dasu wrote: > Legacy mips soc platforms that have controller v5.0 and 6.0 use > flash-edu block for dma transfers. This change adds support for > nand dma transfers using the EDU block. > > Signed-off-by: Kamal Dasu Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks. Miquel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 1/5] drm/mediatek: Omit warning on probe defers
From: Matthias Brugger
It can happen that the mmsys clock drivers aren't probed before the
platform driver gets invoked. The platform driver used to print a warning
that the driver failed to get the clocks. Omit this error on
the defered probe path.
Signed-off-by: Matthias Brugger
Reviewed-by: CK Hu
Signed-off-by: Enric Balletbo i Serra
---
Changes in v12: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 -
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 -
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 -
drivers/gpu/drm/mediatek/mtk_dpi.c| 12 +---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 3 ++-
drivers/gpu/drm/mediatek/mtk_dsi.c| 8 ++--
drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 +++-
7 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 6fb0d6983a4a..3ae9c810845b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -119,7 +119,10 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_color_funcs);
if (ret) {
- dev_err(dev, "Failed to initialize component: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 891d80c73e04..28651bc579bc 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -386,7 +386,10 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_ovl_funcs);
if (ret) {
- dev_err(dev, "Failed to initialize component: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 0cb848d64206..e04319fedf46 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -294,7 +294,10 @@ static int mtk_disp_rdma_probe(struct platform_device
*pdev)
ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_rdma_funcs);
if (ret) {
- dev_err(dev, "Failed to initialize component: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 01fa8b8d763d..1b219edef541 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -701,21 +701,27 @@ static int mtk_dpi_probe(struct platform_device *pdev)
dpi->engine_clk = devm_clk_get(dev, "engine");
if (IS_ERR(dpi->engine_clk)) {
ret = PTR_ERR(dpi->engine_clk);
- dev_err(dev, "Failed to get engine clock: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get engine clock: %d\n", ret);
+
return ret;
}
dpi->pixel_clk = devm_clk_get(dev, "pixel");
if (IS_ERR(dpi->pixel_clk)) {
ret = PTR_ERR(dpi->pixel_clk);
- dev_err(dev, "Failed to get pixel clock: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get pixel clock: %d\n", ret);
+
return ret;
}
dpi->tvd_clk = devm_clk_get(dev, "pll");
if (IS_ERR(dpi->tvd_clk)) {
ret = PTR_ERR(dpi->tvd_clk);
- dev_err(dev, "Failed to get tvdpll clock: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get tvdpll clock: %d\n", ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 13035c906035..b885f60f474c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -628,7 +628,8 @@ static int mtk_ddp_probe(struct platform_device *pdev)
if (!ddp->data->no_clk) {
ddp->clk = devm_clk_get(dev, NULL);
if (IS_ERR(ddp->clk)) {
- dev_err(dev, "Failed to get clock\n");
+
[PATCH v4 1/2] dt-bindings: display: Add idk-1110wr binding
From: Fabrizio Castro
Add binding for the idk-1110wr LVDS panel from Advantech.
Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htm
Signed-off-by: Fabrizio Castro
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
Signed-off-by: Lad Prabhakar
---
.../display/panel/advantech,idk-1110wr.yaml| 69 ++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
new file mode 100644
index 000..93878c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/advantech,idk-1110wr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advantech IDK-1110WR 10.1" WSVGA LVDS Display Panel
+
+maintainers:
+ - Lad Prabhakar
+ - Thierry Reding
+
+allOf:
+ - $ref: lvds.yaml#
+
+properties:
+ compatible:
+items:
+ - const: advantech,idk-1110wr
+ - {} # panel-lvds, but not listed here to avoid false select
+
+ data-mapping:
+const: jeida-24
+
+ width-mm:
+const: 223
+
+ height-mm:
+const: 125
+
+ panel-timing: true
+ port: true
+
+additionalProperties: false
+
+required:
+ - compatible
+
+examples:
+ - |+
+panel {
+ compatible = "advantech,idk-1110wr", "panel-lvds";
+
+ width-mm = <223>;
+ height-mm = <125>;
+
+ data-mapping = "jeida-24";
+
+ panel-timing {
+/* 1024x600 @60Hz */
+clock-frequency = <5120>;
+hactive = <1024>;
+vactive = <600>;
+hsync-len = <240>;
+hfront-porch = <40>;
+hback-porch = <40>;
+vsync-len = <10>;
+vfront-porch = <15>;
+vback-porch = <10>;
+ };
+
+ port {
+panel_in: endpoint {
+ remote-endpoint = <&lvds_encoder>;
+};
+ };
+};
+
+...
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/2] drm/panel: add support for rm69299 visionox panel driver
Add support for Visionox panel driver.
Signed-off-by: Harigovindan P
---
Changes in v2:
- Dropping redundant space in Kconfig(Sam Ravnborg).
- Changing structure for include files(Sam Ravnborg).
- Removing backlight related code and functions(Sam Ravnborg).
- Removing repeated printing of error message(Sam Ravnborg).
- Adding drm_connector as an argument for get_modes function.
Changes in v3:
- Adding arguments for drm_panel_init to support against mainline.
Changes in v4:
- Removing error messages from regulator_set_load.
- Removing dev struct entry.
- Removing checks.
- Dropping empty comment lines.
Changes in v5:
- Removing unused struct member variables.
- Removing blank lines.
- Fixed indentation.
- Invoking dsi_detach and panel_remove while early exiting from probe.
Changes in v6:
- Changed "35597" to "rm69299" for power_on function.
- Removing rm69299_config since it supports single type of panel for
now.
- Fixed alignment.
- Using goto statements when regulator_set_load fails.
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-visionox-rm69299.c| 295 ++
3 files changed, 304 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-visionox-rm69299.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ae44ac2ec106..7b696f304a99 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -389,6 +389,14 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+config DRM_PANEL_VISIONOX_RM69299
+ tristate "Visionox RM69299"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ help
+ Say Y here if you want to enable support for Visionox
+ RM69299 DSI Video Mode panel.
+
config DRM_PANEL_XINPENG_XPP055C272
tristate "Xinpeng XPP055C272 panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7c4d3c581fd4..9f11d067a6b2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -41,4 +41,5 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_VISIONOX_RM69299) += panel-visionox-rm69299.o
obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c
b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
new file mode 100644
index ..b226723a7543
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
@@ -0,0 +1,295 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+struct visionox_rm69299 {
+ struct drm_panel panel;
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc *reset_gpio;
+ struct mipi_dsi_device *dsi;
+ bool prepared;
+ bool enabled;
+};
+
+static inline struct visionox_rm69299 *panel_to_ctx(struct drm_panel *panel)
+{
+ return container_of(panel, struct visionox_rm69299, panel);
+}
+
+static int visionox_rm69299_power_on(struct visionox_rm69299 *ctx)
+{
+ int ret;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+ if (ret < 0)
+ return ret;
+
+ /*
+* Reset sequence of visionox panel requires the panel to be
+* out of reset for 10ms, followed by being held in reset
+* for 10ms and then out again
+*/
+ gpiod_set_value(ctx->reset_gpio, 1);
+ usleep_range(1, 2);
+ gpiod_set_value(ctx->reset_gpio, 0);
+ usleep_range(1, 2);
+ gpiod_set_value(ctx->reset_gpio, 1);
+ usleep_range(1, 2);
+
+ return 0;
+}
+
+static int visionox_rm69299_power_off(struct visionox_rm69299 *ctx)
+{
+ gpiod_set_value(ctx->reset_gpio, 0);
+
+ return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+}
+
+static int visionox_rm69299_unprepare(struct drm_panel *panel)
+{
+ struct visionox_rm69299 *ctx = panel_to_ctx(panel);
+ int ret;
+
+ ctx->dsi->mode_flags = 0;
+
+ ret = mipi_dsi_dcs_write(ctx->dsi, MIPI_DCS_SET_DISPLAY_OFF, NULL, 0);
+ if (ret < 0)
+ DRM_DEV_ERROR(ctx->panel.dev,
+ "set_display_off cmd failed ret = %d\n", ret);
+
+ /* 120ms delay required here as per DCS spec */
+ msleep(120);
+
Re: [PATCH v11 4/5] soc / drm: mediatek: Move routing control to mmsys device
On 11/03/2020 14:07, CK Hu wrote: > Hi, Enric: > > On Wed, 2020-03-11 at 12:56 +0100, Enric Balletbo i Serra wrote: >> Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to >> replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path(). >> Those functions will allow DRM driver and others to control the data >> path routing. >> > > Reviewed-by: CK Hu > If I remember correctly you are OK me taking the patch through the SoC tree, right? In this case I'd need a Acked-by tag. Not a big deal, just trying to remeber the tag policy in the linux kernel :) Regards, Matthias >> Signed-off-by: Enric Balletbo i Serra >> Reviewed-by: Matthias Brugger >> --- >> >> Changes in v11: None >> Changes in v10: >> - Select CONFIG_MTK_MMSYS (CK) >> - Pass device pointer of mmsys device instead of config regs (CK) >> >> Changes in v9: >> - Introduced a new patch to move routing control into mmsys driver. >> - Removed the patch to use regmap as is not needed anymore. >> >> Changes in v8: None >> Changes in v7: None >> >> drivers/gpu/drm/mediatek/Kconfig| 1 + >> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +- >> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 256 -- >> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 - >> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 14 +- >> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +- >> drivers/soc/mediatek/mtk-mmsys.c| 279 >> include/linux/soc/mediatek/mtk-mmsys.h | 20 ++ >> 8 files changed, 316 insertions(+), 282 deletions(-) >> create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/2] Add support for rm69299 Visionox panel driver and add devicetree bindings for visionox panel
Adding support for visionox rm69299 panel driver and adding bindings for the same panel. Harigovindan P (2): dt-bindings: display: add visionox rm69299 panel variant drm/panel: add support for rm69299 visionox panel driver .../display/panel/visionox,rm69299.yaml | 77 + drivers/gpu/drm/panel/Kconfig | 8 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-visionox-rm69299.c| 295 ++ 4 files changed, 381 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml create mode 100644 drivers/gpu/drm/panel/panel-visionox-rm69299.c -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hmm 7/8] mm/hmm: return -EFAULT when setting HMM_PFN_ERROR on requested valid pages
From: Jason Gunthorpe
hmm_range_fault() should never return 0 if the caller requested a valid
page, but the pfns output for that page would be HMM_PFN_ERROR.
hmm_pte_need_fault() must always be called before setting HMM_PFN_ERROR to
detect if the page is in faulting mode or not.
Fix two cases in hmm_vma_walk_pmd() and reorganize some of the duplicated
code.
Fixes: d08faca018c4 ("mm/hmm: properly handle migration pmd")
Fixes: da4c3c735ea4 ("mm/hmm/mirror: helper to snapshot CPU page table")
Signed-off-by: Jason Gunthorpe
---
mm/hmm.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index bf676cfef3e8ee..f61fddf2ef6505 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -363,8 +363,10 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
{
struct hmm_vma_walk *hmm_vma_walk = walk->private;
struct hmm_range *range = hmm_vma_walk->range;
- uint64_t *pfns = range->pfns;
- unsigned long addr = start, i;
+ uint64_t *pfns = &range->pfns[(start - range->start) >> PAGE_SHIFT];
+ unsigned long npages = (end - start) >> PAGE_SHIFT;
+ unsigned long addr = start;
+ bool fault, write_fault;
pte_t *ptep;
pmd_t pmd;
@@ -374,14 +376,6 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
return hmm_vma_walk_hole(start, end, -1, walk);
if (thp_migration_supported() && is_pmd_migration_entry(pmd)) {
- bool fault, write_fault;
- unsigned long npages;
- uint64_t *pfns;
-
- i = (addr - range->start) >> PAGE_SHIFT;
- npages = (end - addr) >> PAGE_SHIFT;
- pfns = &range->pfns[i];
-
hmm_range_need_fault(hmm_vma_walk, pfns, npages,
0, &fault, &write_fault);
if (fault || write_fault) {
@@ -390,8 +384,15 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
return -EBUSY;
}
return hmm_pfns_fill(start, end, range, HMM_PFN_NONE);
- } else if (!pmd_present(pmd))
+ }
+
+ if (!pmd_present(pmd)) {
+ hmm_range_need_fault(hmm_vma_walk, pfns, npages, 0, &fault,
+&write_fault);
+ if (fault || write_fault)
+ return -EFAULT;
return hmm_pfns_fill(start, end, range, HMM_PFN_ERROR);
+ }
if (pmd_devmap(pmd) || pmd_trans_huge(pmd)) {
/*
@@ -408,8 +409,7 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
if (!pmd_devmap(pmd) && !pmd_trans_huge(pmd))
goto again;
- i = (addr - range->start) >> PAGE_SHIFT;
- return hmm_vma_handle_pmd(walk, addr, end, &pfns[i], pmd);
+ return hmm_vma_handle_pmd(walk, addr, end, pfns, pmd);
}
/*
@@ -418,15 +418,19 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
* entry pointing to pte directory or it is a bad pmd that will not
* recover.
*/
- if (pmd_bad(pmd))
+ if (pmd_bad(pmd)) {
+ hmm_range_need_fault(hmm_vma_walk, pfns, npages, 0, &fault,
+&write_fault);
+ if (fault || write_fault)
+ return -EFAULT;
return hmm_pfns_fill(start, end, range, HMM_PFN_ERROR);
+ }
ptep = pte_offset_map(pmdp, addr);
- i = (addr - range->start) >> PAGE_SHIFT;
- for (; addr < end; addr += PAGE_SIZE, ptep++, i++) {
+ for (; addr < end; addr += PAGE_SIZE, ptep++, pfns++) {
int r;
- r = hmm_vma_handle_pte(walk, addr, end, pmdp, ptep, &pfns[i]);
+ r = hmm_vma_handle_pte(walk, addr, end, pmdp, ptep, pfns);
if (r) {
/* hmm_vma_handle_pte() did pte_unmap() */
hmm_vma_walk->last = addr;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 2/2] ARM: dts: sun4i: Add support for Topwise A721 tablet
On 2020-03-10 15:02, Ondřej Jirman wrote:
Hello Pascal,
On Tue, Mar 10, 2020 at 11:27:24AM +0100, Pascal Roeleven wrote:
The Topwise A721/LY-F1 tablet is a tablet sold around 2012 under
different brands. The mainboard mentions A721 clearly, so this tablet
is best known under this name.
Signed-off-by: Pascal Roeleven
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/sun4i-a10-topwise-a721.dts | 302
+++
2 files changed, 304 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 78f144e33..6e6141e00 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1040,7 +1040,8 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-olinuxino-lime.dtb \
sun4i-a10-pcduino.dtb \
sun4i-a10-pcduino2.dtb \
- sun4i-a10-pov-protab2-ips9.dtb
+ sun4i-a10-pov-protab2-ips9.dtb \
+ sun4i-a10-topwise-a721.dtb
dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-auxtek-t003.dtb \
sun5i-a10s-auxtek-t004.dtb \
diff --git a/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
b/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
new file mode 100644
index 0..ff43c9c12
--- /dev/null
+++ b/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
@@ -0,0 +1,302 @@
+/*
+ * Copyright 2020 Pascal Roeleven
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the
Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
You should use SPDX license identifier instead of boilerplate license
text.
+/dts-v1/;
+#include "sun4i-a10.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+#include
+#include
+
+/ {
+ model = "Topwise A721";
+ compatible = "topwise,a721", "allwinner,sun4i-a10";
topwise is not in vendor-prefixes.yaml
+ aliases {
+ serial0 = &uart0;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 10 PWM_POLARITY_INVERTED>;
+ power-supply = <®_vbat>;
+ enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+ brightness-levels = <0 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <8>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ panel: panel {
+ compatible = "starry,kr070pe2t";
+ backlight = <&backlight>;
+ power-supply = <®_lcd_power>;
+
+ port {
+ panel_input: endpoint {
+ remote-endpoint = <&tcon0_out_panel>;
+ };
+ };
+ };
+
+ reg_lcd_power: reg-lcd-power {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_power_pin>;
+ regulator-name = "reg-lcd-power";
+ gpio = <&pio 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */
+ enable-active-high;
+ };
+
+ reg_vbat: reg-vbat {
+ compatible
[PATCH 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
display.
Add its device nodes.
Signed-off-by: Icenowy Zheng
---
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index cefda145c3c9..96d9150423e0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -16,6 +16,15 @@ aliases {
serial0 = &uart0;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&r_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42 46 51
56 62 68 75 83 91 100>;
+ default-brightness-level = <15>;
+ enable-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+ power-supply = <®_ldo_io0>;
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -84,6 +93,30 @@ &dai {
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dldo1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "xingbangda,xbd599";
+ reg = <0>;
+ reset-gpios = <&pio 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
+ iovcc-supply = <®_dldo2>;
+ vcc-supply = <®_ldo_io0>;
+ backlight = <&backlight>;
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -188,6 +221,10 @@ &r_pio {
*/
};
+&r_pwm {
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hmm 8/8] mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL handling
From: Jason Gunthorpe
Currently if a special PTE is encountered hmm_range_fault() immediately
returns EFAULT and sets the HMM_PFN_SPECIAL error output (which nothing
uses).
EFAULT should only be returned after testing with hmm_pte_need_fault().
Also pte_devmap() and pte_special() are exclusive, and there is no need to
check IS_ENABLED, pte_special() is stubbed out to return false on
unsupported architectures.
Fixes: 992de9a8b751 ("mm/hmm: allow to mirror vma of a file on a DAX backed
filesystem")
Signed-off-by: Jason Gunthorpe
---
mm/hmm.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index f61fddf2ef6505..ca33d086bdc190 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -335,16 +335,21 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
unsigned long addr,
pte_unmap(ptep);
return -EBUSY;
}
- } else if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL) && pte_special(pte))
{
- if (!is_zero_pfn(pte_pfn(pte))) {
+ }
+
+ /*
+* Since each architecture defines a struct page for the zero page, just
+* fall through and treat it like a normal page.
+*/
+ if (pte_special(pte) && !is_zero_pfn(pte_pfn(pte))) {
+ hmm_pte_need_fault(hmm_vma_walk, orig_pfn, 0, &fault,
+ &write_fault);
+ if (fault || write_fault) {
pte_unmap(ptep);
- *pfn = range->values[HMM_PFN_SPECIAL];
return -EFAULT;
}
- /*
-* Since each architecture defines a struct page for the zero
-* page, just fall through and treat it like a normal page.
-*/
+ *pfn = range->values[HMM_PFN_SPECIAL];
+ return 0;
}
*pfn = hmm_device_entry_from_pfn(range, pte_pfn(pte)) | cpu_flags;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/msm/dpu: Remove some set but not used variables
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c: In function _dpu_debugfs_show_regset32:
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:142:26: warning: variable priv set but
not used [-Wunused-but-set-variable]
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c: In function dpu_kms_prepare_commit:
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:271:21: warning: variable dev set but
not used [-Wunused-but-set-variable]
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c: In function _dpu_kms_hw_destroy:
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:555:21: warning: variable dev set but
not used [-Wunused-but-set-variable]
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c: In function dpu_kms_hw_init:
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:763:26: warning: variable priv set but
not used [-Wunused-but-set-variable]
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c: In function dpu_runtime_suspend:
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:1021:21: warning: variable ddev set but
not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot
Signed-off-by: tongtiangen
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index cb08fafb1dc1..089d1cde39da 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -138,16 +138,12 @@ static int _dpu_debugfs_show_regset32(struct seq_file *s,
void *data)
{
struct dpu_debugfs_regset32 *regset = s->private;
struct dpu_kms *dpu_kms = regset->dpu_kms;
- struct drm_device *dev;
- struct msm_drm_private *priv;
void __iomem *base;
uint32_t i, addr;
if (!dpu_kms->mmio)
return 0;
- dev = dpu_kms->dev;
- priv = dev->dev_private;
base = dpu_kms->mmio + regset->offset;
/* insert padding spaces, if needed */
@@ -267,8 +263,6 @@ static ktime_t dpu_kms_vsync_time(struct msm_kms *kms,
struct drm_crtc *crtc)
static void dpu_kms_prepare_commit(struct msm_kms *kms,
struct drm_atomic_state *state)
{
- struct dpu_kms *dpu_kms;
- struct drm_device *dev;
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
struct drm_encoder *encoder;
@@ -276,8 +270,6 @@ static void dpu_kms_prepare_commit(struct msm_kms *kms,
if (!kms)
return;
- dpu_kms = to_dpu_kms(kms);
- dev = dpu_kms->dev;
/* Call prepare_commit for all affected encoders */
for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
@@ -552,11 +544,8 @@ static long dpu_kms_round_pixclk(struct msm_kms *kms,
unsigned long rate,
static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
{
- struct drm_device *dev;
int i;
- dev = dpu_kms->dev;
-
if (dpu_kms->hw_intr)
dpu_hw_intr_destroy(dpu_kms->hw_intr);
dpu_kms->hw_intr = NULL;
@@ -760,7 +749,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
{
struct dpu_kms *dpu_kms;
struct drm_device *dev;
- struct msm_drm_private *priv;
int i, rc = -EINVAL;
if (!kms) {
@@ -770,7 +758,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
dpu_kms = to_dpu_kms(kms);
dev = dpu_kms->dev;
- priv = dev->dev_private;
atomic_set(&dpu_kms->bandwidth_ref, 0);
@@ -1018,10 +1005,8 @@ static int __maybe_unused dpu_runtime_suspend(struct
device *dev)
int rc = -1;
struct platform_device *pdev = to_platform_device(dev);
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
- struct drm_device *ddev;
struct dss_module_power *mp = &dpu_kms->mp;
- ddev = dpu_kms->dev;
rc = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
if (rc)
DPU_ERROR("clock disable failed rc:%d\n", rc);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH libdrm] modetest: call drmModeCrtcSetGamma() only if add_property_optional returns true
Hi Ilia Mirkin,
Thanks for the review.
By old-fashioned way you mean to say using drmModeCrtcSetGamma()? If yes then,
it shows error as "failed to set gamma: Function no implemented" if any
platform specific drm has no gamma property implemented.
Current code shows error while running modetest for Xilinx drm as it doesn't
supports gamma property and ideally it should not show error as gamma is
optional property, so it doesn't serve the purpose of optional property.
Please correct me if I am missing anything.
Thanks
Rohit
> -Original Message-
> From: Ilia Mirkin [mailto:imir...@alum.mit.edu]
> Sent: Tuesday, March 3, 2020 7:08 PM
> To: Devarsh Thakkar
> Cc: Rohit Visavalia ; dri-devel@lists.freedesktop.org;
> emil.veli...@collabora.com; Ville Syrjälä ;
> Hyun
> Kwon ; Ranganathan Sk ; Dhaval
> Rajeshbhai Shah ; Varunkumar Allagadapa
>
> Subject: Re: [PATCH libdrm] modetest: call drmModeCrtcSetGamma() only if
> add_property_optional returns true
>
> EXTERNAL EMAIL
>
> Pretty sure the current code is right. If the GAMMA_LUT property can't be set,
> it tries to set gamma the old-fashioned way.
>
> On Tue, Mar 3, 2020 at 8:12 AM Devarsh Thakkar
> wrote:
> >
> > Hi Rohit,
> >
> > This makes sense to me as gamma was implemented as optional property.
> > Reviewed-By: "Devarsh Thakkar "
> >
> > @emil.veli...@collabora.com, @imir...@alum.mit.edu, @Ville Syrjälä,
> Could you please ack and help merge this patch if it also look good to you ?
> >
> > Regards,
> > Devarsh
> >
> > > -Original Message-
> > > From: Rohit Visavalia
> > > Sent: 27 February 2020 00:40
> > > To: Rohit Visavalia ;
> > > dri-devel@lists.freedesktop.org; imir...@alum.mit.edu;
> > > emil.veli...@collabora.com
> > > Cc: Hyun Kwon ; Ranganathan Sk ;
> > > Dhaval Rajeshbhai Shah ; Varunkumar Allagadapa
> > > ; Devarsh Thakkar
> > > Subject: RE: [PATCH libdrm] modetest: call drmModeCrtcSetGamma()
> > > only if add_property_optional returns true
> > >
> > > Gentle reminder.
> > >
> > > + Ilia Mirkin, +Emil Velikov.
> > >
> > > Thanks & Regards,
> > > Rohit
> > >
> > > > -Original Message-
> > > > From: Rohit Visavalia [mailto:rohit.visava...@xilinx.com]
> > > > Sent: Tuesday, February 25, 2020 3:08 PM
> > > > To: dri-devel@lists.freedesktop.org
> > > > Cc: Hyun Kwon ; Ranganathan Sk ;
> > > > Dhaval Rajeshbhai Shah ; Varunkumar Allagadapa
> > > > ; Devarsh Thakkar ;
> > > > Rohit Visavalia
> > > > Subject: [PATCH libdrm] modetest: call drmModeCrtcSetGamma() only
> > > > if add_property_optional returns true
> > > >
> > > > gamma is a optional property then also it prints error message, so
> > > > set gamma only if add_property_optional() returns true.
> > > >
> > > > Signed-off-by: Rohit Visavalia
> > > > ---
> > > > tests/modetest/modetest.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> > > > index b907ab3..379b9ea 100644
> > > > --- a/tests/modetest/modetest.c
> > > > +++ b/tests/modetest/modetest.c
> > > > @@ -1138,7 +1138,7 @@ static void set_gamma(struct device *dev,
> > > > unsigned crtc_id, unsigned fourcc)
> > > >
> > > > add_property_optional(dev, crtc_id, "DEGAMMA_LUT", 0);
> > > > add_property_optional(dev, crtc_id, "CTM", 0);
> > > > - if (!add_property_optional(dev, crtc_id, "GAMMA_LUT", blob_id)) {
> > > > + if (add_property_optional(dev, crtc_id, "GAMMA_LUT", blob_id))
> > > > + {
> > > > uint16_t r[256], g[256], b[256];
> > > >
> > > > for (i = 0; i < 256; i++) {
> > > > --
> > > > 2.7.4
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 0/5] arm/arm64: mediatek: Fix mt8173 mmsys device probing
Dear all, These patches are intended to solve an old standing issue on some Mediatek devices (mt8173, mt2701 and mt2712 are affected by this issue). Up to now both drivers, clock and drm are probed with the same device tree compatible. But only the first driver gets probed, which in effect breaks graphics on those devices. The MMSYS (Multimedia subsystem) in Mediatek SoCs has some registers to control clock gates (which is used in the clk driver) and some registers to set the routing and enable the differnet blocks of the display and MDP (Media Data Path) subsystem. On this series the clk driver is not a pure clock controller but a system controller that can provide access to the shared registers between the different drivers that need it (mediatek-drm and mediatek-mdp). Hence the MMSYS clk driver was moved to drivers/soc/mediatek and is the entry point (parent) which will trigger the probe of the corresponding mediatek-drm driver. **IMPORTANT** This series only fixes the issue on mt8173 to make it simple and as is the only platform I can test. Similar changes should be applied for mt2701 and mt2712 to have display working. These patches apply on top of linux-next. For reference, here are the links to the old discussions: * v11: https://patchwork.kernel.org/project/linux-mediatek/list/?series=249871 * v10: https://patchwork.kernel.org/project/linux-mediatek/list/?series=248505 * v9: https://patchwork.kernel.org/project/linux-clk/list/?series=247591 * v8: https://patchwork.kernel.org/project/linux-mediatek/list/?series=244891 * v7: https://patchwork.kernel.org/project/linux-mediatek/list/?series=241217 * v6: https://patchwork.kernel.org/project/linux-mediatek/list/?series=213219 * v5: https://patchwork.kernel.org/project/linux-mediatek/list/?series=44063 * v4: * https://patchwork.kernel.org/patch/10530871/ * https://patchwork.kernel.org/patch/10530883/ * https://patchwork.kernel.org/patch/10530885/ * https://patchwork.kernel.org/patch/10530911/ * https://patchwork.kernel.org/patch/10530913/ * v3: * https://patchwork.kernel.org/patch/10367857/ * https://patchwork.kernel.org/patch/10367861/ * https://patchwork.kernel.org/patch/10367877/ * https://patchwork.kernel.org/patch/10367875/ * https://patchwork.kernel.org/patch/10367885/ * https://patchwork.kernel.org/patch/10367883/ * https://patchwork.kernel.org/patch/10367889/ * https://patchwork.kernel.org/patch/10367907/ * https://patchwork.kernel.org/patch/10367909/ * https://patchwork.kernel.org/patch/10367905/ * v2: No relevant discussion, see v3 * v1: * https://patchwork.kernel.org/patch/10016497/ * https://patchwork.kernel.org/patch/10016499/ * https://patchwork.kernel.org/patch/10016505/ * https://patchwork.kernel.org/patch/10016507/ Best regards, Enric Changes in v12: - Leave the clocks part in drivers/clk (clk-mt8173-mm) - Instantiate the clock driver from the mtk-mmsys driver. - Add default config option to not break anything. - Removed the Reviewed-by CK tag as changed the organization. Changes in v10: - Update the binding documentation for the mmsys system controller. - Renamed to be generic mtk-mmsys - Add driver data support to be able to support diferent SoCs - Select CONFIG_MTK_MMSYS (CK) - Pass device pointer of mmsys device instead of config regs (CK) - Match driver data to get display routing. Changes in v9: - Move mmsys to drivers/soc/mediatek (CK) - Introduced a new patch to move routing control into mmsys driver. - Removed the patch to use regmap as is not needed anymore. - Do not move the display routing from the drm driver (CK) Changes in v8: - Be a builtin_platform_driver like other mediatek mmsys drivers. - New patch introduced in this series. Changes in v7: - Free clk_data->clks as well - Get rid of private data structure Enric Balletbo i Serra (3): dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller soc / drm: mediatek: Move routing control to mmsys device soc / drm: mediatek: Fix mediatek-drm device probing Matthias Brugger (2): drm/mediatek: Omit warning on probe defers clk / soc: mediatek: Move mt8173 MMSYS to platform driver .../bindings/arm/mediatek/mediatek,mmsys.txt | 7 +- drivers/clk/mediatek/Kconfig | 7 + drivers/clk/mediatek/Makefile | 1 + drivers/clk/mediatek/clk-mt8173-mm.c | 146 drivers/clk/mediatek/clk-mt8173.c | 104 -- drivers/gpu/drm/mediatek/Kconfig | 1 + drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 +- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 +- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 +- drivers/gpu/drm/mediatek/mtk_dpi.c| 12 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 259 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.h| 7 - drivers/gpu/drm/mediatek/mtk_drm_drv.c| 45 +-- drivers/gpu/drm/mediatek
[PATCH v3 0/4] Support virtio cross-device resources
This patchset implements the current proposal for virtio cross-device resource sharing [1], with minor changes based on recent comments. It is expected that this will be used to import virtio resources into the virtio-video driver currently under discussion [2]. This patchset adds a new hook to dma-buf, for querying the dma-buf's underlying virtio UUID. This hook is then plumbed through DRM PRIME buffers, and finally implemented in virtgpu. [1] https://markmail.org/thread/jsaoqy7phrqdcpqu [2] https://markmail.org/thread/p5d3k566srtdtute v2 -> v3 changes: - Remove ifdefs. - Simplify virtgpu_gem_prime_export as it can only be called once. - Use virtio_gpu_vbuffer's objs field instead of abusing data_buf. David Stevens (4): dma-buf: add support for virtio exported objects drm/prime: add support for virtio exported objects virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature drm/virtio: Support virtgpu exported resources drivers/dma-buf/dma-buf.c | 12 ++ drivers/gpu/drm/drm_prime.c| 23 +++ drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++ drivers/gpu/drm/virtio/virtgpu_drv.h | 18 + drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ drivers/gpu/drm/virtio/virtgpu_prime.c | 41 +-- drivers/gpu/drm/virtio/virtgpu_vq.c| 55 ++ include/drm/drm_drv.h | 10 + include/linux/dma-buf.h| 18 + include/uapi/linux/virtio_gpu.h| 19 + 10 files changed, 200 insertions(+), 3 deletions(-) -- 2.25.1.481.gfbce0eb801-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] display/bridge: dsi2lvds tc358775 driver
Laurent Pinchart, if we want to set to jeida-18 data mapping, do we need to set DATA3 with "Logic 0" LVI_L0 ? Please see reply inline. On Fri, Mar 6, 2020 at 7:02 PM Laurent Pinchart wrote: > > Hi Vinay, > > Thank you for the patch. > > On Fri, Mar 06, 2020 at 06:06:36PM +0530, Vinay Simha B N wrote: > > hi andrzej, > > > > I had a doubt In the tc358764 driver,VP_CTRL, VP_CTRL_VSDELAY(15) is > > hardcoded to 15, but this has to be dynamic based on the resolution of > > panel used? > > > > Please see the reply inline. > > > > On Tue, Mar 3, 2020 at 8:39 PM Andrzej Hajda wrote: > > > On 27.02.2020 15:03, Vinay Simha BN wrote: > > > > dsi2lvds tc358775 bridge driver added > > > > Tested in apq8016, ifc6309 board and panel > > > > auo,b101xtn01 > > > > > > Just FYI, there exists already TC358764/5 driver for similar hw, but > > > controlled via DSI bus. > > > > There is not much difference between these two chips, but still the > > dsi read access for 775 does not works. > > TC358764/5 - 800Mbps per lane, 3.2Gbps > > TC358775 - 1Gbps per lane, 4Gbps. > > > > tc358775 chip details - > > https://download.t-firefly.com/product/RK3399/Docs/Chip%20Specifications/TC358774XBG_75XBG_V1%204nm.pdf > > I am able to configure the tc358775 chip by i2c, but from dsi it fails > > i tried accessing the tc358775 chip by dsi using apq8016-qcom , but it > > fails to read the chip id itself. > > > > Please suggest if you any inputs for this issue. > > > > https://github.com/vinaysimhabn/kernel-msm/commits/5.6.0-rc3-dsi2lvds-dsi > > > > [4.582405] tc358764 1a98000.dsi.0: read: 1408, addr: 0 > > [4.582426] tc358764 1a98000.dsi.0: ID: 0x0 > > [4.582451] tc358764 1a98000.dsi.0: error initializing bridge (-22) > > > > [4.796220] dsi_cmds2buf_tx: cmd dma tx failed, type=0x24, data0=0x80, > > len=4 > > [4.796244] [drm:msm_dsi_host_cmd_rx] data = 0x0 and ntohl(data) = 0x0 > > [4.796266] [drm:msm_dsi_host_cmd_rx] data = 0x0 and ntohl(data) = 0x0 > > [4.796288] [drm:msm_dsi_host_cmd_rx] data = 0x0 and ntohl(data) = 0x0 > > [4.796310] [drm:msm_dsi_host_cmd_rx] data = 0x0 and ntohl(data) = 0x0 > > [4.796319] msm_dsi_host_cmd_rx:Invalid response cmd > > > > > > Signed-off-by: Vinay Simha BN > > > > --- > > > > .../bindings/display/bridge/toshiba,tc358775.txt | 106 > > > > > > Bindings should be in separate patch and in yaml format. > > > > > > > drivers/gpu/drm/bridge/Kconfig | 10 + > > > > drivers/gpu/drm/bridge/Makefile| 1 + > > > > drivers/gpu/drm/bridge/tc358775.c | 687 > > > > + > > > > 4 files changed, 804 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.txt > > > > create mode 100644 drivers/gpu/drm/bridge/tc358775.c > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.txt > > > > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.txt > > > > new file mode 100644 > > > > index 000..c4c364d > > > > --- /dev/null > > > > +++ > > > > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.txt > > > > @@ -0,0 +1,106 @@ > > > > +Toshiba TC358775 DSI to LVDS bridge bindings > > > > + > > > > +Required properties: > > > > + - compatible: "toshiba,tc358775" > > > > + - reg: i2c address of the bridge, 0x0f > > > > + - tc, dsi-lanes: Number of DSI data lanes connected to the DSI host. > > > > It should > > > > + be one of 1, 2, 3 or 4. > > > > + - tc, dual-link : To configure the LVDS transmitter either > > > > + as single-link or dual-link. > > > > + - tc, data-format: To configure the data formats > > > > + 0 for VESA standard, 1 for JEIDA standard > > > > > > IMO, three properties above should be received from downstream device in > > > runtime, not hardcoded into DT, however I am not sure if frameworks > > > support it. > > I assume Andrzej meant upstream device for the tc,dsi-lanes property. > This should be exposed through the data-lanes property as described in > media/video-interface.txt. data-lanes mainly used for the interfaces of the hardware. example : dsi, csi In general panels/bridges either it will be hardcoded by setting in the panel driver like this dsi->lanes = 4; bridge -> dsi2hdmi display/bridge/adi,adv7511.txt it wil be set by adi,dsi-lanes > > The tc,dual-link property should be replaced by exposing two port nodes, > one for each link, and connecting them appropriately. See > display/bridge/thine,thc63lvd1024.txt for an example of DT bindings on > the LVDS receiver side, and drivers/gpu/drm/rcar-du/rcar_lvds.c for an > example implementation on the LVDS transmitter side. Can we add two port nodes though it can give only 1 output? when higher resolution panel used dual_link is enabled in LVCFG > > The tc,data-format property should be replaced by the data-mapping > property on the downstream LVDS device (see display/panel/lvds.yaml
[PATCH v11 4/5] soc / drm: mediatek: Move routing control to mmsys device
Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path().
Those functions will allow DRM driver and others to control the data
path routing.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Matthias Brugger
---
Changes in v11: None
Changes in v10:
- Select CONFIG_MTK_MMSYS (CK)
- Pass device pointer of mmsys device instead of config regs (CK)
Changes in v9:
- Introduced a new patch to move routing control into mmsys driver.
- Removed the patch to use regmap as is not needed anymore.
Changes in v8: None
Changes in v7: None
drivers/gpu/drm/mediatek/Kconfig| 1 +
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 256 --
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 -
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 14 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/soc/mediatek/mtk-mmsys.c| 279
include/linux/soc/mediatek/mtk-mmsys.h | 20 ++
8 files changed, 316 insertions(+), 282 deletions(-)
create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index fa5ffc4fe823..c420f5a3d33b 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -11,6 +11,7 @@ config DRM_MEDIATEK
select DRM_MIPI_DSI
select DRM_PANEL
select MEMORY
+ select MTK_MMSYS
select MTK_SMI
select VIDEOMODE_HELPERS
help
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 0e05683d7b53..579a5a5d4472 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,7 +29,7 @@
* @enabled: records whether crtc_enable succeeded
* @planes: array of 4 drm_plane structures, one for each overlay plane
* @pending_planes: whether any plane has pending changes to be applied
- * @config_regs: memory mapped mmsys configuration register space
+ * @mmsys_dev: pointer to the mmsys device for configuration registers
* @mutex: handle to one of the ten disp_mutex streams
* @ddp_comp_nr: number of components in ddp_comp
* @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc
@@ -50,7 +51,7 @@ struct mtk_drm_crtc {
u32 cmdq_event;
#endif
- void __iomem*config_regs;
+ struct device *mmsys_dev;
struct mtk_disp_mutex *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
@@ -296,9 +297,9 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
}
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
- mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
-mtk_crtc->ddp_comp[i]->id,
-mtk_crtc->ddp_comp[i + 1]->id);
+ mtk_mmsys_ddp_connect(mtk_crtc->mmsys_dev,
+ mtk_crtc->ddp_comp[i]->id,
+ mtk_crtc->ddp_comp[i + 1]->id);
mtk_disp_mutex_add_comp(mtk_crtc->mutex,
mtk_crtc->ddp_comp[i]->id);
}
@@ -355,9 +356,9 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
*mtk_crtc)
mtk_crtc->ddp_comp[i]->id);
mtk_disp_mutex_disable(mtk_crtc->mutex);
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
- mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
- mtk_crtc->ddp_comp[i]->id,
- mtk_crtc->ddp_comp[i + 1]->id);
+ mtk_mmsys_ddp_disconnect(mtk_crtc->mmsys_dev,
+mtk_crtc->ddp_comp[i]->id,
+mtk_crtc->ddp_comp[i + 1]->id);
mtk_disp_mutex_remove_comp(mtk_crtc->mutex,
mtk_crtc->ddp_comp[i]->id);
}
@@ -761,7 +762,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
if (!mtk_crtc)
return -ENOMEM;
- mtk_crtc->config_regs = priv->config_regs;
+ mtk_crtc->mmsys_dev = priv->mmsys_dev;
mtk_crtc->ddp_comp_nr = path_len;
mtk_crtc->ddp_comp = devm_kmalloc_array(dev, mtk_crtc->ddp_comp_nr,
sizeof(*mtk_crtc->ddp_comp),
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index b885f60f474c..014c1bbe1df2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -13,26 +13,6 @@
#include "mtk_drm_d
[PATCH v12 2/5] dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller
The mmsys system controller is not only a pure clock controller, so
update the binding documentation to reflect that apart from providing
clocks, it also provides routing and miscellaneous control registers.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Matthias Brugger
Reviewed-by: CK Hu
---
Changes in v12: None
Changes in v10:
- Update the binding documentation for the mmsys system controller.
Changes in v9: None
Changes in v8: None
Changes in v7: None
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.txt| 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
index 301eefbe1618..8d6a9d98e7a6 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -1,7 +1,8 @@
Mediatek mmsys controller
-The Mediatek mmsys controller provides various clocks to the system.
+The Mediatek mmsys system controller provides clock control, routing control,
+and miscellaneous control in mmsys partition.
Required Properties:
@@ -15,13 +16,13 @@ Required Properties:
- "mediatek,mt8183-mmsys", "syscon"
- #clock-cells: Must be 1
-The mmsys controller uses the common clk binding from
+For the clock control, the mmsys controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
Example:
-mmsys: clock-controller@1400 {
+mmsys: syscon@1400 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
#clock-cells = <1>;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] MAINTAINERS: add it66121 HDMI bridge driver entry
Add Neil Armstrong and myself as maintainers Signed-off-by: Phong LE --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 37c2963226d4..3d722d723686 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8977,6 +8977,14 @@ T: git git://linuxtv.org/anttip/media_tree.git S: Maintained F: drivers/media/tuners/it913x* +ITE IT66121 HDMI BRIDGE DRIVER +M: Phong LE +M: Neil Armstrong +S: Maintained +F: drivers/gpu/drm/bridge/ite-it66121.c +T: git git://anongit.freedesktop.org/drm/drm-misc +F: Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml + IVTV VIDEO4LINUX DRIVER M: Andy Walls L: linux-me...@vger.kernel.org -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm: bridge: add it66121 driver
This commit is a simple driver for bridge HMDI it66121. The input format is RBG and there is no color conversion. Audio, HDCP and CEC are not supported yet. Signed-off-by: Phong LE --- drivers/gpu/drm/bridge/Kconfig | 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ite-it66121.c | 997 +++ 3 files changed, 1006 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index aaed2347ace9..ae57b83f47c8 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -38,6 +38,14 @@ config DRM_DISPLAY_CONNECTOR on ARM-based platforms. Saying Y here when this driver is not needed will not cause any issue. +config DRM_ITE_IT66121 + tristate "ITE IT66121 HDMI bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + help + Support for ITE IT66121 HDMI bridge. + config DRM_LVDS_CODEC tristate "Transparent LVDS encoders and decoders support" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 6fb062b5b0f0..9fe80e820f64 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o +obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += megachips-stdp-ge-b850v3-fw.o obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c new file mode 100644 index ..7e1a90319a6a --- /dev/null +++ b/drivers/gpu/drm/bridge/ite-it66121.c @@ -0,0 +1,997 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2020 BayLibre, SAS + * Author: Phong LE + * Copyright (C) 2018-2019, Artem Mygaiev + * Copyright (C) 2017, Fresco Logic, Incorporated. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#define IT66121_MASTER_SEL_REG 0x10 +#define IT66121_MASTER_SEL_HOSTBIT(0) + +#define IT66121_AFE_DRV_REG0x61 +#define IT66121_AFE_DRV_RSTBIT(4) +#define IT66121_AFE_DRV_PWDBIT(5) + +#define IT66121_INPUT_MODE_REG 0x70 +#define IT66121_INPUT_MODE_RGB (0 << 6) +#define IT66121_INPUT_MODE_YUV422 BIT(6) +#define IT66121_INPUT_MODE_YUV444 (2 << 6) +#define IT66121_INPUT_MODE_CCIR656 BIT(4) +#define IT66121_INPUT_MODE_SYNCEMB BIT(3) +#define IT66121_INPUT_MODE_DDR BIT(2) + +#define IT66121_INPUT_CSC_REG 0x72 +#define IT66121_INPUT_CSC_ENDITHER BIT(7) +#define IT66121_INPUT_CSC_ENUDFILTER BIT(6) +#define IT66121_INPUT_CSC_DNFREE_GOBIT(5) +#define IT66121_INPUT_CSC_RGB_TO_YUV 0x02 +#define IT66121_INPUT_CSC_YUV_TO_RGB 0x03 +#define IT66121_INPUT_CSC_NO_CONV 0x00 + +#define IT66121_AFE_XP_REG 0x62 +#define IT66121_AFE_XP_GAINBIT BIT(7) +#define IT66121_AFE_XP_PWDPLL BIT(6) +#define IT66121_AFE_XP_ENI BIT(5) +#define IT66121_AFE_XP_ENO BIT(4) +#define IT66121_AFE_XP_RESETB BIT(3) +#define IT66121_AFE_XP_PWDIBIT(2) + +#define IT66121_AFE_IP_REG 0x64 +#define IT66121_AFE_IP_GAINBIT BIT(7) +#define IT66121_AFE_IP_PWDPLL BIT(6) +#define IT66121_AFE_IP_CKSEL_05(0 << 4) +#define IT66121_AFE_IP_CKSEL_1 BIT(4) +#define IT66121_AFE_IP_CKSEL_2 (2 << 4) +#define IT66121_AFE_IP_CKSEL_2OR4 (3 << 4) +#define IT66121_AFE_IP_ER0 BIT(3) +#define IT66121_AFE_IP_RESETB BIT(2) +#define IT66121_AFE_IP_ENC BIT(1) +#define IT66121_AFE_IP_EC1 BIT(0) + +#define IT66121_AFE_XP_EC1_REG 0x68 +#define IT66121_AFE_XP_EC1_LOWCLK BIT(4) + +#define IT66121_SW_RST_REG 0x04 +#define IT66121_SW_RST_REF BIT(5) +#define IT66121_SW_RST_AREFBIT(4) +#define IT66121_SW_RST_VID BIT(3) +#define IT66121_SW_RST_AUD BIT(2) +#define IT66121_SW_RST_HDCPBIT(0) + +#define IT66121_DDC_COMMAND_REG0x15 +#define IT66121_DDC_COMMAND_BURST_READ 0x0 +#define IT66121_DDC_COMMAND_EDID_READ 0x3 +#define IT66121_D
Re: [PATCH -next 013/491] INGENIC JZ47xx SoCs: Use fallthrough;
On Wed, 11 Mar 2020 at 08:40, Miquel Raynal wrote: > > Hi Joe, > > Joe Perches wrote on Tue, 10 Mar 2020 21:51:27 -0700: > > > Convert the various uses of fallthrough comments to fallthrough; > > > > Done via script > > Link: > > https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/ > > > > Signed-off-by: Joe Perches > > --- > > drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +- > > drivers/mmc/host/jz4740_mmc.c | 6 ++ > > drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c | 2 +- > > drivers/mtd/nand/raw/ingenic/jz4725b_bch.c | 4 ++-- > > drivers/mtd/nand/raw/ingenic/jz4780_bch.c | 4 ++-- > > sound/soc/codecs/jz4770.c | 2 +- > > 6 files changed, 9 insertions(+), 11 deletions(-) > > I like very much the new way to advertise for fallthrough statements, > but I am not willing to take any patch converting a single driver > anymore. I had too many from Gustavo when these comments had to be > inserted. I would really prefer a MTD-wide or a NAND-wide or at least a > raw-NAND-wide single patch (anything inside drivers/mtd/nand/raw/). > > Hope you'll understand! I fully agree (for mmc). One patch please. Another option is to make a big fat tree wide patch and ask Linus if he want to pick up immediately after an rc1. That should cause less disturbance for everyone, no? Kind regards Uffe ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] Add support for PinePhone LCD panel
This patchset adds support for the LCD panel of PinePhone. The first 3 patches are for the panel itself, and the last 2 patches are for enabling it on PinePhone. PATCH 4 is the fix of a bug in sun6i_mipi_dsi which will gets triggered on XBD599. Icenowy Zheng (5): dt-bindings: vendor-prefixes: Add Xingbangda dt-bindings: panel: add binding for Xingbangda XBD599 panel drm: panel: add Xingbangda XBD599 panel drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone .../display/panel/xingbangda,xbd599.yaml | 50 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-xingbangda-xbd599.c | 367 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 10 +- 7 files changed, 471 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hmm 1/8] mm/hmm: add missing unmaps of the ptep during hmm_vma_handle_pte()
From: Jason Gunthorpe
Many of the direct returns of error skipped doing the pte_unmap(). All non
zero exit paths must unmap the pte.
The pte_unmap() is split unnaturally like this because some of the error
exit paths trigger a sleep and must release the lock before sleeping.
Fixes: 992de9a8b751 ("mm/hmm: allow to mirror vma of a file on a DAX backed
filesystem")
Fixes: 53f5c3f489ec ("mm/hmm: factor out pte and pmd handling to simplify
hmm_vma_walk_pmd()")
Signed-off-by: Jason Gunthorpe
---
mm/hmm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 72e5a6d9a41756..35f85424176d14 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -325,6 +325,7 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
unsigned long addr,
}
/* Report error for everything else */
+ pte_unmap(ptep);
*pfn = range->values[HMM_PFN_ERROR];
return -EFAULT;
} else {
@@ -339,10 +340,13 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
unsigned long addr,
if (pte_devmap(pte)) {
hmm_vma_walk->pgmap = get_dev_pagemap(pte_pfn(pte),
hmm_vma_walk->pgmap);
- if (unlikely(!hmm_vma_walk->pgmap))
+ if (unlikely(!hmm_vma_walk->pgmap)) {
+ pte_unmap(ptep);
return -EBUSY;
+ }
} else if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL) && pte_special(pte))
{
if (!is_zero_pfn(pte_pfn(pte))) {
+ pte_unmap(ptep);
*pfn = range->values[HMM_PFN_SPECIAL];
return -EFAULT;
}
@@ -437,7 +441,7 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
r = hmm_vma_handle_pte(walk, addr, end, pmdp, ptep, &pfns[i]);
if (r) {
- /* hmm_vma_handle_pte() did unmap pte directory */
+ /* hmm_vma_handle_pte() did pte_unmap() */
hmm_vma_walk->last = addr;
return r;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported
On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote: > Check if we can do peer2peer on the PCIe bus. > > Signed-off-by: Christian König > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > index aef12ee2f1e3..bbf67800c8a6 100644 > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c > @@ -38,6 +38,7 @@ > #include > #include > #include > +#include > > /** > * amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation > @@ -179,6 +180,9 @@ static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf, > struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); > int r; > > + if (pci_p2pdma_distance_many(adev->pdev, &attach->dev, 1, true) < 0) > + attach->peer2peer = false; > + Are there other related patches than this series? p2p dma mapping needs to be done in common code, in p2pdma.c - ie this open coding is missing the bus_offset stuff, at least. I really do not want to see drivers open code this stuff. We already have a p2pdma API for handling the struct page case, so I suggest adding some new p2pdma API to handle this for non-struct page cases. ie some thing like: int 'p2pdma map bar'( struct pci_device *source, unsigned int source_bar_number, struct pci_device *dest, physaddr&len *array_of_offsets & length pairs into source bar, struct scatterlist *output_sgl) Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm: bridge: add it66121 driver
On Wed, Mar 11, 2020 at 01:51:34PM +0100, Phong LE wrote:
> This commit is a simple driver for bridge HMDI it66121.
> The input format is RBG and there is no color conversion.
> Audio, HDCP and CEC are not supported yet.
I guess you should have been told in your company how to use get_maintainer.pl
to avoid spamming people.
Hint:
scripts/get_maintainer.pl --git --git-min-percent=67 ...
...
> + * Copyright (C) 2020 BayLibre, SAS
> + * Author: Phong LE
> + * Copyright (C) 2018-2019, Artem Mygaiev
> + * Copyright (C) 2017, Fresco Logic, Incorporated.
This too compact to read, perhaps squeeze blank line after your (c) note
followed by description how the rest (c) appear in the file.
> + *
Redundant line.
> + */
...
> +#include
This can be replaced with property.h, see comments against ->probe().
> +#include
> +#include
I didn't find evidence of use of any of those.
...
> +#define IT66121_MASTER_SEL_REG 0x10
> +#define IT66121_AFE_DRV_REG 0x61
> +#define IT66121_INPUT_MODE_REG 0x70
> +#define IT66121_INPUT_CSC_REG0x72
> +#define IT66121_AFE_XP_REG 0x62
> +#define IT66121_AFE_IP_REG 0x64
> +#define IT66121_AFE_XP_EC1_REG 0x68
> +#define IT66121_SW_RST_REG 0x04
> +#define IT66121_DDC_COMMAND_REG 0x15
> +#define IT66121_HDCP_REG 0x20
> +#define IT66121_INT_STATUS1_REG 0x06
> +#define IT66121_DDC_HEADER_REG 0x11
> +#define IT66121_DDC_OFFSET_REG 0x12
> +#define IT66121_DDC_BYTE_REG 0x13
> +#define IT66121_DDC_SEGMENT_REG 0x14
> +#define IT66121_DDC_RD_FIFO_REG 0x17
> +#define IT66121_CLK_BANK_REG 0x0F
> +#define IT66121_INT_REG 0x05
> +#define IT66121_INT_MASK1_REG0x09
> +#define IT66121_INT_CLR1_REG 0x0C
> +#define IT66121_AV_MUTE_REG 0xC1
> +#define IT66121_PKT_GEN_CTRL_REG 0xC6
> +#define IT66121_AVIINFO_DB1_REG 0x158
> +#define IT66121_AVIINFO_DB2_REG 0x159
> +#define IT66121_AVIINFO_DB3_REG 0x15A
> +#define IT66121_AVIINFO_DB4_REG 0x15B
> +#define IT66121_AVIINFO_DB5_REG 0x15C
> +#define IT66121_AVIINFO_CSUM_REG 0x15D
> +#define IT66121_AVIINFO_DB6_REG 0x15E
> +#define IT66121_AVIINFO_DB7_REG 0x15F
> +#define IT66121_AVIINFO_DB8_REG 0x160
> +#define IT66121_AVIINFO_DB9_REG 0x161
> +#define IT66121_AVIINFO_DB10_REG 0x162
> +#define IT66121_AVIINFO_DB11_REG 0x163
> +#define IT66121_AVIINFO_DB12_REG 0x164
> +#define IT66121_AVIINFO_DB13_REG 0x165
> +
> +#define IT66121_AVI_INFO_PKT_REG 0xCD
> +#define IT66121_HDMI_MODE_REG0xC0
> +#define IT66121_SYS_STATUS_REG 0x0E
> +#define IT66121_DDC_STATUS_REG 0x16
It's better to
a) keep register sorted by value (easy to be oriented);
b) have them in fixed width, e.g. 0x0CD.
...
> +#define IT66121_DEVICE_MASK 0x0F
GENMASK() ?
> +#define IT66121_EDID_SLEEP 2
> +#define IT66121_EDID_TIMEOUT 20
Care to add units?
> +#define IT66121_AFE_CLK_HIGH 8
Also, what is the unit of this?
...
> + return regmap_write(ctx->regmap, IT66121_MASTER_SEL_REG,
> + IT66121_MASTER_SEL_HOST);
Indentation?
Same for other similar places.
...
> +static int it66121_configure_afe(struct it66121_ctx *ctx,
> + const struct drm_display_mode *mode)
...like this.
...
> + if (val & (IT66121_DDC_STATUS_NOACK | IT66121_DDC_STATUS_WAIT_BUS |
> + IT66121_DDC_STATUS_ARBI_LOSE))
> + return -EAGAIN;
Perhaps better to
u32 busy = IT66121_DDC_STATUS_NOACK | IT66121_DDC_STATUS_WAIT_BUS |
IT66121_DDC_STATUS_ARBI_LOSE;
if (val & busy)
return -EAGAIN;
?
> +
> + return 0;
> +}
...
> +static int it66121_abort_ddc_ops(struct it66121_ctx *ctx)
> +{
> + int ret;
> + unsigned int swreset, cpdesire;
> +
> + ret = regmap_read(ctx->regmap, IT66121_SW_RST_REG, &swreset);
> + if (ret)
> + return ret;
> +
> + ret = regmap_read(ctx->regmap, IT66121_HDCP_REG, &cpdesire);
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(ctx->regmap, IT66121_HDCP_REG,
> +cpdesire & (~IT66121_HDCP_CPDESIRED & 0xFF));
> + if (ret)
> + return ret;
regmap_update_bits() ?
> +
> + ret = regmap_write(ctx->regmap, IT6612
[PATCH v8 4/5] drm/i915: Add helper code for ACPI privacy screen
Add helper functions that can allow i915 to detect and control
an integrated privacy screen via ACPI methods. These shall be used
in the next patch.
Signed-off-by: Rajat Jain
---
v8: Initial version. formed by refactoring the previous patch 4.
print the connector name in the debug messages.
drivers/gpu/drm/i915/Makefile | 3 +-
.../drm/i915/display/intel_privacy_screen.c | 184 ++
.../drm/i915/display/intel_privacy_screen.h | 27 +++
3 files changed, 213 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.c
create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9f887a86e555d..da42389107f9c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -209,7 +209,8 @@ i915-y += \
display/intel_vga.o
i915-$(CONFIG_ACPI) += \
display/intel_acpi.o \
- display/intel_opregion.o
+ display/intel_opregion.o \
+ display/intel_privacy_screen.o
i915-$(CONFIG_DRM_FBDEV_EMULATION) += \
display/intel_fbdev.o
diff --git a/drivers/gpu/drm/i915/display/intel_privacy_screen.c
b/drivers/gpu/drm/i915/display/intel_privacy_screen.c
new file mode 100644
index 0..66039103c821b
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_privacy_screen.c
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Intel ACPI privacy screen code
+ *
+ * Copyright © 2020 Google Inc.
+ *
+ * This code can help detect and control an integrated EPS (electronic
+ * privacy screen) via ACPI functions. It expects an ACPI node for the
+ * drm connector device with the following elements:
+ *
+ * UUID should be "c7033113-8720-4ceb-9090-9d52b3e52d73"
+ *
+ * _ADR = ACPI address per Spec (also see intel_acpi_device_id_update())
+ * https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
+ * Pages 1119 - 1123.
+ *
+ * _DSM method that will perform the following functions according to
+ * Local1 argument passed to it:
+ * - Local1 = 0 (EPS capabilities): Report EPS presence and capabilities.
+ * - Local1 = 1 (EPS State) : _DSM returns 1 if EPS is enabled, 0 otherwise.
+ * - Local1 = 2 (EPS Enable) : _DSM enables EPS
+ * - Local1 = 3 (EPS Disable): _DSM disables EPS
+ *
+ * Here is a sample ACPI node:
+ *
+ * Scope (\_SB.PCI0.GFX0) // Intel graphics device (PCI device)
+ * {
+ * Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices
+ * {
+ * Return (Package (0x01)
+ * {
+ * 0x80010400
+ * })
+ * }
+ *
+ * Device (LCD)
+ * {
+ * Name (_ADR, 0x80010400) // _ADR: Address
+ * Name (_STA, 0x0F) // _STA: Status
+ *
+ * Method (EPSP, 0, NotSerialized) // EPS Present
+ * {
+ * Return (0x01)
+ * }
+ *
+ * Method (EPSS, 0, NotSerialized) // EPS State
+ * {
+ * Local0 = \_SB.PCI0.GRXS (0xCD)
+ * Return (Local0)
+ * }
+ *
+ * Method (EPSE, 0, NotSerialized) // EPS Enable
+ * {
+ * \_SB.PCI0.STXS (0xCD)
+ * }
+ *
+ * Method (EPSD, 0, NotSerialized) // EPS Disable
+ * {
+ * \_SB.PCI0.CTXS (0xCD)
+ * }
+ *
+ * Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
+ * {
+ * ToBuffer (Arg0, Local0)
+ * If ((Local0 == ToUUID
("c7033113-8720-4ceb-9090-9d52b3e52d73")))
+ * {
+ * ToInteger (Arg2, Local1)
+ * If ((Local1 == Zero))
+ * {
+ * Local2 = EPSP ()
+ * If ((Local2 == One))
+ * {
+ * Return (Buffer (One)
+ * {
+ * 0x0F
+ * })
+ * }
+ * }
+ *
+ * If ((Local1 == One))
+ * {
+ * Return (EPSS ())
+ * }
+ *
+ * If ((Local1 == 0x02))
+ * {
+ * EPSE ()
+ * }
+ *
+ * If ((Local1 == 0x03))
+ * {
+ * EPSD ()
+ * }
+ *
+ * Return (Buffer (One)
+ * {
+ * 0x00
+ * })
+ * }
+ *
+ * Return (Buffer (One)
+ * {
+ * 0x00
+ * })
+ * }
+ * }
+ * }
+ */
+
+#include
+
+#include "intel_privacy_screen.h"
+
+#define CONN_NAME(conn)\
+ (conn->base.kdev ? dev_name(conn->base.kdev) : "NONAME")
+
+#define CONNECTOR_DSM_REVID 1
+
+#define CONNECTOR_DSM_FN_PRIVACY_ENABLE2
+#def
Re: [PATCH v7 4/4] drm/i915: Add support for integrated privacy screen
Hi Jani,
On Mon, Mar 9, 2020 at 5:18 PM Rajat Jain wrote:
>
> Hi Jani,
>
> I have 1 question / need 1 help about this patch:
Kind ignore, I found the answer, and posted my new patchset here:
https://patchwork.freedesktop.org/series/74607/
I got a "failed to apply" email from the patchwork. Can you please let
me know on which branch is it trying to apply it? I have currently
rebased my patchset to drm-intel-next-queued.
Thanks & Best Regards,
Rajat
>
> On Mon, Mar 9, 2020 at 5:06 PM Rajat Jain wrote:
> >
> > Add support for an ACPI based integrated privacy screen that is
> > available on some systems.
> >
> > Signed-off-by: Rajat Jain
> > ---
> > v7: * Move the privacy-screen property back into drm core.
> > * Do the actual HW EPS toggling at commit time.
> > * Provide a sample ACPI node for reference in comments.
> > v6: Always initialize prop in intel_attach_privacy_screen_property()
> > v5: fix a cosmetic checkpatch warning
> > v4: Fix a typo in intel_privacy_screen.h
> > v3: * Change license to GPL-2.0 OR MIT
> > * Move privacy screen enum from UAPI to intel_display_types.h
> > * Rename parameter name and some other minor changes.
> > v2: Formed by splitting the original patch into multiple patches.
> > - All code has been moved into i915 now.
> > - Privacy screen is a i915 property
> > - Have a local state variable to store the prvacy screen. Don't read
> > it from hardware.
> >
> > drivers/gpu/drm/i915/Makefile | 3 +-
> > drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
> > drivers/gpu/drm/i915/display/intel_dp.c | 30 ++-
> > .../drm/i915/display/intel_privacy_screen.c | 175 ++
> > .../drm/i915/display/intel_privacy_screen.h | 27 +++
> > 5 files changed, 234 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.c
> > create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.h
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 9f887a86e555d..da42389107f9c 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -209,7 +209,8 @@ i915-y += \
> > display/intel_vga.o
> > i915-$(CONFIG_ACPI) += \
> > display/intel_acpi.o \
> > - display/intel_opregion.o
> > + display/intel_opregion.o \
> > + display/intel_privacy_screen.o
> > i915-$(CONFIG_DRM_FBDEV_EMULATION) += \
> > display/intel_fbdev.o
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > index d043057d2fa03..fc6264b4a7f73 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > @@ -150,6 +150,7 @@ int intel_digital_connector_atomic_check(struct
> > drm_connector *conn,
> > new_conn_state->base.picture_aspect_ratio !=
> > old_conn_state->base.picture_aspect_ratio ||
> > new_conn_state->base.content_type !=
> > old_conn_state->base.content_type ||
> > new_conn_state->base.scaling_mode !=
> > old_conn_state->base.scaling_mode ||
> > + new_conn_state->base.privacy_screen_status !=
> > old_conn_state->base.privacy_screen_status ||
> > !blob_equal(new_conn_state->base.hdr_output_metadata,
> > old_conn_state->base.hdr_output_metadata))
> > crtc_state->mode_changed = true;
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 41c623b029464..a39b0c420b50a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -62,6 +62,7 @@
> > #include "intel_lspcon.h"
> > #include "intel_lvds.h"
> > #include "intel_panel.h"
> > +#include "intel_privacy_screen.h"
> > #include "intel_psr.h"
> > #include "intel_sideband.h"
> > #include "intel_tc.h"
> > @@ -5886,6 +5887,12 @@ intel_dp_connector_register(struct drm_connector
> > *connector)
> > dev_priv->acpi_scan_done = true;
> > }
> >
> > + /* Check for integrated Privacy screen support */
> > + if (intel_privacy_screen_present(to_intel_connector(connector)))
> > + drm_connector_attach_privacy_screen_property(connector);
> > + else
> > + drm_connector_destroy_privacy_screen_property(connector);
> > +
> > DRM_DEBUG_KMS("registering %s bus for %s\n",
> > intel_dp->aux.name, connector->kdev->kobj.name);
> >
> > @@ -6881,9 +6888,30 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> > struct drm_connector *connect
> > drm_connector_attach_scaling_mode_property(connector,
> > allowed_scalers);
> >
> > connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
> > +
> > + drm_connector_create_privacy_screen_property(connector);
> > }
> > }
> >
> > +
Re: [PATCH v2 3/4] drm: bridge: add it66121 driver
On Thu, Mar 12, 2020 at 2:56 AM Laurent Pinchart wrote: > On Wed, Mar 11, 2020 at 03:55:35PM +0200, Andy Shevchenko wrote: > > On Wed, Mar 11, 2020 at 01:51:34PM +0100, Phong LE wrote: > > > This commit is a simple driver for bridge HMDI it66121. > > > The input format is RBG and there is no color conversion. > > > Audio, HDCP and CEC are not supported yet. > > > > I guess you should have been told in your company how to use > > get_maintainer.pl > > to avoid spamming people. > > > > Hint: > > scripts/get_maintainer.pl --git --git-min-percent=67 ... > I didn't even know about those options... Doesn't one usually look at the help of the tool they are using? How does one know what it does by default? > I don't think we can't expect > contributors to know about this if it's not even documented in > Documentation/process/. This is indeed not good and there is room for improvement. > And even in that case, if this is what every > contribution should use by default, then those options should become the > default for the get_maintainer.pl script. I don't think so. There is a common sense rule in play. By default get_maintainer.pl shows the roles of the people, so, when one puts the name at least they may read what the role of the recipient in question. If I see too many people in the list (let's say 4+), I definitely will start looking for the explanation why. -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 3/8] mm/hmm: do not call hmm_vma_walk_hole() while holding a spinlock
On 11/03/2020 18:35, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This eventually calls into handle_mm_fault() which is a sleeping function.
Release the lock first.
hmm_vma_walk_hole() does not touch the contents of the PUD, so it does not
need the lock.
Fixes: 3afc423632a1 ("mm: pagewalk: add p4d_entry() and pgd_entry()")
Cc: Steven Price
Signed-off-by: Jason Gunthorpe
Sorry about that, thanks for fixing.
Reviewed-by: Steven Price
---
mm/hmm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 9e8f68eb83287a..32dcbfd3908315 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -473,8 +473,8 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long
start, unsigned long end,
pud = READ_ONCE(*pudp);
if (pud_none(pud)) {
- ret = hmm_vma_walk_hole(start, end, -1, walk);
- goto out_unlock;
+ spin_unlock(ptl);
+ return hmm_vma_walk_hole(start, end, -1, walk);
}
if (pud_huge(pud) && pud_devmap(pud)) {
@@ -483,8 +483,8 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long
start, unsigned long end,
bool fault, write_fault;
if (!pud_present(pud)) {
- ret = hmm_vma_walk_hole(start, end, -1, walk);
- goto out_unlock;
+ spin_unlock(ptl);
+ return hmm_vma_walk_hole(start, end, -1, walk);
}
i = (addr - range->start) >> PAGE_SHIFT;
@@ -495,9 +495,9 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long
start, unsigned long end,
hmm_range_need_fault(hmm_vma_walk, pfns, npages,
cpu_flags, &fault, &write_fault);
if (fault || write_fault) {
- ret = hmm_vma_walk_hole_(addr, end, fault,
-write_fault, walk);
- goto out_unlock;
+ spin_unlock(ptl);
+ return hmm_vma_walk_hole_(addr, end, fault, write_fault,
+ walk);
}
pfn = pud_pfn(pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC][PATCH 3/5] drm/i915: Enable scaling filter for plane and pipe
> -Original Message-
> From: Ville Syrjälä
> Sent: 10 March 2020 21:36
> To: Laxminarayan Bharadiya, Pankaj
>
> Cc: jani.nik...@linux.intel.com; dan...@ffwll.ch; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; airl...@linux.ie;
> maarten.lankho...@linux.intel.com; tzimmerm...@suse.de;
> mrip...@kernel.org; mihail.atanas...@arm.com; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> Chris Wilson ; Souza, Jose
> ; Juha-Pekka Heikkila
> ; linux-ker...@vger.kernel.org; Nautiyal,
> Ankit K
> Subject: Re: [RFC][PATCH 3/5] drm/i915: Enable scaling filter for plane and
> pipe
>
> On Tue, Feb 25, 2020 at 12:35:43PM +0530, Pankaj Bharadiya wrote:
> > Attach scaling filter property for crtc and plane and program the
> > scaler control register for the selected filter type.
> >
> > This is preparatory patch to enable Nearest-neighbor integer scaling.
> >
> > Signed-off-by: Pankaj Bharadiya
> >
> > Signed-off-by: Ankit Nautiyal
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 17 +++--
> > drivers/gpu/drm/i915/display/intel_sprite.c | 12 +++-
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > 3 files changed, 27 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 3031e64ee518..b5903ef3c5a0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -6242,6 +6242,8 @@ static void skl_pfit_enable(const struct
> intel_crtc_state *crtc_state)
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > enum pipe pipe = crtc->pipe;
> > + const struct drm_crtc_state *state = &crtc_state->uapi;
> > + u32 scaling_filter = PS_FILTER_MEDIUM;
> > const struct intel_crtc_scaler_state *scaler_state =
> > &crtc_state->scaler_state;
> >
> > @@ -6258,6 +6260,11 @@ static void skl_pfit_enable(const struct
> intel_crtc_state *crtc_state)
> > pfit_w = (crtc_state->pch_pfit.size >> 16) & 0x;
> > pfit_h = crtc_state->pch_pfit.size & 0x;
> >
> > + if (state->scaling_filter ==
> > + DRM_SCALING_FILTER_NEAREST_NEIGHBOR) {
> > + scaling_filter = PS_FILTER_PROGRAMMED;
> > + }
>
> Just make that a function that can be used all over.
> skl_scaler_filter(scaling_filter) or something.
>
> > +
> > hscale = (crtc_state->pipe_src_w << 16) / pfit_w;
> > vscale = (crtc_state->pipe_src_h << 16) / pfit_h;
> >
> > @@ -6268,8 +6275,10 @@ static void skl_pfit_enable(const struct
> > intel_crtc_state *crtc_state)
> >
> > spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> >
> > - intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id),
> PS_SCALER_EN |
> > - PS_FILTER_MEDIUM | scaler_state-
> >scalers[id].mode);
> > + intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id),
> > + PS_SCALER_EN |
> > + scaling_filter |
> > + scaler_state->scalers[id].mode);
> > intel_de_write_fw(dev_priv, SKL_PS_VPHASE(pipe, id),
> > PS_Y_PHASE(0) |
> PS_UV_RGB_PHASE(uv_rgb_vphase));
> > intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id), @@
> -16695,6
> > +16704,10 @@ static int intel_crtc_init(struct drm_i915_private *dev_priv,
> enum pipe pipe)
> > dev_priv->plane_to_crtc_mapping[i9xx_plane] = crtc;
> > }
> >
> > +
> > + if (INTEL_GEN(dev_priv) >= 11)
>
> gen >= 10 actually. Even glk seems to have it but bspec says not to use it on
> glk. Supposedly not validated.
>
> ilk/snb/ivb pfits also has programmable coefficients actually. So IMO we
> should enable this on those as well.
OK. I need to explore bspec more for these platforms.
To begin with I would like to stick to gen >=10.
>
> The bigger problem will be how is userspace supposed to use this if it's a
> crtc
> property? Those will not get automagically exposed via xrandr.
>
> > + drm_crtc_enable_scaling_filter(&crtc->base);
> > +
> > intel_color_init(crtc);
> >
> > drm_WARN_ON(&dev_priv->drm, drm_crtc_index(&crtc->base) !=
> > crtc->pipe); diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > index 7abeefe8dce5..fd7b31a21723 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > @@ -414,6 +414,12 @@ skl_program_scaler(struct intel_plane *plane,
> > u16 y_hphase, uv_rgb_hphase;
> > u16 y_vphase, uv_rgb_vphase;
> > int hscale, vscale;
> > + const struct drm_plane_state *state = &plane_state->uapi;
> > + u32 scaling_filter = PS_FILTER_MEDIUM;
> > +
> > + if (state->scaling_filter ==
> DRM_SCALING_FILTER_NEAREST_
Re: [RFC PATCH 0/8] *** Per context fencing ***
Hi, > Can virtqueues be added dynamically? No. > Or can we have > fixed but enough (e.g., 64) virtqueues? Well, I wouldn't bet that any specific number is enough. When gtk starts rendering using vulkan by default the number of contexts of a standard gnome desktop will be pretty high I guess ... We can have a host-configurable number of virtqueues. Typically the guest can figure the number of available queues from config space. One common usage pattern (seen in block/net devices) is to have the number of virtqueues equal the number of vcpus, so each vcpu has dedicated virtqueue. For virtio-gpu it is probably more useful to bind contexts to virtqueues. As long as we have enough virtqueues each context can have its own. Once we run out of virtqueues we have to start sharing. On the host side it probably makes sense to have one process per virtqueue. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/8] *** Per context fencing ***
Hi, > I will start with... how many timelines do we want to expose per > context? In my mind, it goes like > > V1: 1 timeline per virtqueue (there is one timeline for ctrlq right now) > V2: 1 timeline per context (VK and GL on different timelines) > V3: N timelines per context (each VkQueue in a VK context gets a timeline?) > V4: N+M timelines per context (each CPU thread also gets a timeline?!?!) > > I certainly don't know if V4 is a good idea or not... I'd expect apps use one VkQueue per thread, so v3 makes sense but v4 not so much I think ... cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC][PATCH 5/5] drm/i915/display: Add Nearest-neighbor based integer scaling support
> -Original Message-
> From: Ville Syrjälä
> Sent: 10 March 2020 21:47
> To: Laxminarayan Bharadiya, Pankaj
>
> Cc: jani.nik...@linux.intel.com; dan...@ffwll.ch; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; airl...@linux.ie;
> maarten.lankho...@linux.intel.com; tzimmerm...@suse.de;
> mrip...@kernel.org; mihail.atanas...@arm.com; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> Chris Wilson ; Souza, Jose
> ; De Marchi, Lucas ;
> Roper, Matthew D ; Deak, Imre
> ; Shankar, Uma ; linux-
> ker...@vger.kernel.org; Nautiyal, Ankit K
> Subject: Re: [RFC][PATCH 5/5] drm/i915/display: Add Nearest-neighbor
> based integer scaling support
>
> On Tue, Feb 25, 2020 at 12:35:45PM +0530, Pankaj Bharadiya wrote:
> > Integer scaling (IS) is a nearest-neighbor upscaling technique that
> > simply scales up the existing pixels by an integer (i.e., whole
> > number) multiplier.Nearest-neighbor (NN) interpolation works by
> > filling in the missing color values in the upscaled image with that of
> > the coordinate-mapped nearest source pixel value.
> >
> > Both IS and NN preserve the clarity of the original image. Integer
> > scaling is particularly useful for pixel art games that rely on sharp,
> > blocky images to deliver their distinctive look.
> >
> > Program the scaler filter coefficients to enable the NN filter if
> > scaling filter property is set to DRM_SCALING_FILTER_NEAREST_NEIGHBOR
> > and enable integer scaling.
> >
> > Bspec: 49247
> >
> > Signed-off-by: Pankaj Bharadiya
> >
> > Signed-off-by: Ankit Nautiyal
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 83
> > +++- drivers/gpu/drm/i915/display/intel_display.h |
> > 2 + drivers/gpu/drm/i915/display/intel_sprite.c | 20 +++--
> > 3 files changed, 97 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index b5903ef3c5a0..6d5f59203258 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -6237,6 +6237,73 @@ void skl_scaler_disable(const struct
> intel_crtc_state *old_crtc_state)
> > skl_detach_scaler(crtc, i);
> > }
> >
> > +/**
> > + * Theory behind setting nearest-neighbor integer scaling:
> > + *
> > + * 17 phase of 7 taps requires 119 coefficients in 60 dwords per set.
> > + * The letter represents the filter tap (D is the center tap) and
> > +the number
> > + * represents the coefficient set for a phase (0-16).
> > + *
> > + * ++++
> > + * |Index value | Data value coeffient 1 | Data value coeffient 2 |
> > + * ++++
> > + * | 00h | B0| A0|
> > + * ++++
> > + * | 01h | D0| C0|
> > + * ++++
> > + * | 02h | F0| E0|
> > + * ++++
> > + * | 03h | A1| G0|
> > + * ++++
> > + * | 04h | C1| B1|
> > + * ++++
> > + * | ... | ... | ... |
> > + * ++++
> > + * | 38h | B16 | A16 |
> > + * ++++
> > + * | 39h | D16 | C16 |
> > + * ++++
> > + * | 3Ah | F16 | C16 |
> > + * ++++
> > + * | 3Bh |Reserved| G16 |
> > + * ++++
> > + *
> > + * To enable nearest-neighbor scaling: program scaler coefficents
> > +with
> > + * the center tap (Dxx) values set to 1 and all other values set to
> > +0 as per
> > + * SCALER_COEFFICIENT_FORMAT
> > + *
> > + */
> > +void skl_setup_nearest_neighbor_filter(struct drm_i915_private
> *dev_priv,
> > + enum pipe pipe, int scaler_id)
>
> skl_scaler_...
>
> > +{
> > +
> > + int coeff = 0;
> > + int phase = 0;
> > + int tap;
> > + int val = 0;
>
> Needlessly wide scope for most of these.
>
> > +
> > + /*enable the index auto i
Re: [PATCH v2] drm/bridge: analogix_dp: Split bind() into probe() and real bind()
On 10.03.2020 11:34, Marek Szyprowski wrote: > Analogix_dp driver acquires all its resources in the ->bind() callback, > what is a bit against the component driver based approach, where the > driver initialization is split into a probe(), where all resources are > gathered, and a bind(), where all objects are created and a compound > driver is initialized. > > Extract all the resource related operations to analogix_dp_probe() and > analogix_dp_remove(), then call them before/after registration of the > device components from the main Exynos DP and Rockchip DP drivers. Also > move the plat_data initialization to the probe() to make it available for > the analogix_dp_probe() function. > > This fixes the multiple calls to the bind() of the DRM compound driver > when the DP PHY driver is not yet loaded/probed: > > [drm] Exynos DRM: using 1440.fimd device for DMA mapping operations > exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops > [exynosdrm]) > exynos-drm exynos-drm: bound 1445.mixer (ops mixer_component_ops > [exynosdrm]) > exynos-dp 145b.dp-controller: no DP phy configured > exynos-drm exynos-drm: failed to bind 145b.dp-controller (ops > exynos_dp_ops [exynosdrm]): -517 > exynos-drm exynos-drm: master bind failed: -517 > ... > [drm] Exynos DRM: using 1440.fimd device for DMA mapping operations > exynos-drm exynos-drm: bound 1440.fimd (ops hdmi_enable [exynosdrm]) > exynos-drm exynos-drm: bound 1445.mixer (ops hdmi_enable [exynosdrm]) > exynos-drm exynos-drm: bound 145b.dp-controller (ops hdmi_enable > [exynosdrm]) > exynos-drm exynos-drm: bound 1453.hdmi (ops hdmi_enable [exynosdrm]) > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > Console: switching to colour frame buffer device 170x48 > exynos-drm exynos-drm: fb0: exynosdrmfb frame buffer device > [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1 > ... > > Signed-off-by: Marek Szyprowski Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/8] *** Per context fencing ***
On Wed, Mar 11, 2020 at 04:36:16PM -0700, Gurchetan Singh wrote: > On Wed, Mar 11, 2020 at 3:36 AM Gerd Hoffmann wrote: > > > Hi, > > > > > I should've been more clear -- this is an internal cleanup/preparation > > and > > > the per-context changes are invisible to host userspace. > > > > Ok, it wasn't clear that you don't flip the switch yet. In general the > > commit messages could be a bit more verbose ... > > > > I'm wondering though why we need the new fence_id in the first place. > > Isn't it enough to have per-context (instead of global) last_seq? > > > > Heh, that was to leave open the possibility of multiple timelines per > context. Roughly speaking, > > V2 -- multiple processes > V3 -- multiple processes and multiple threads (due to VK multi-threaded > command buffers) > > I think we all agree on V2. It seems we still have to discuss V3 > (multi-queue, thread pools, a fence context associated with each thread) a > bit more before we start landing pieces. While thinking about the whole thing a bit more ... Do we need virtio_gpu_ctrl_hdr->fence_id at all? At virtio level it is pretty simple: The host completes the SUBMIT_3D virtio command when it finished rendering, period. On the guest side we don't need the fence_id. The completion callback gets passed the virtio_gpu_vbuffer, so it can figure which command did actually complete without looking at virtio_gpu_ctrl_hdr->fence_id. On the host side we depend on the fence_id right now, but only because that is the way the virgl_renderer_callbacks->write_fence interface is designed. We have to change that anyway for per-context (or whatever) fences, so it should not be a problem to drop the fence_id dependency too and just pass around an opaque pointer instead. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 3/3] drm/tegra: dc: Silence RGB output deferred-probe error
On Mon, Mar 09, 2020 at 01:38:09AM +0300, Dmitry Osipenko wrote:
> Driver fails to probe with -EPROBE_DEFER if display output isn't ready
> yet. This produces a bit noisy error message in KMSG during kernel's boot
> up on Tegra20 and Tegra30 because RGB output tends to be probed earlier
> than a corresponding voltage regulator driver.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/dc.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 56d933e81797..d7f2c4654b6b 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -2571,7 +2571,11 @@ static int tegra_dc_probe(struct platform_device *pdev)
>
> err = tegra_dc_rgb_probe(dc);
> if (err < 0 && err != -ENODEV) {
> - dev_err(&pdev->dev, "failed to probe RGB output: %d\n", err);
> + if (err == -EPROBE_DEFER)
> + dev_dbg(&pdev->dev, "RGB output probe deferred\n");
> + else
> + dev_err(&pdev->dev, "failed to probe RGB output: %d\n",
> + err);
> return err;
> }
I'd prefer if we had just a single message and only differentiate on the
kernel message level, something more along these lines:
if (err < 0 && err != -ENODEV) {
const char *level = KERN_ERR;
if (err == -EPROBE_DEFER)
level = KERN_DEBUG;
dev_printk(level, dc->dev, "failed to probe RGB output: %d\n",
err);
return err;
}
Do you mind if I squash that into your patch?
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/1] dt-bindings: display: fix panel warnings
On Sun, Mar 8, 2020 at 12:50 PM Sam Ravnborg wrote: > Fix following type af warnings in the panel bindings: > > Warning (unit_address_vs_reg): /example-0/dsi/panel: node has a reg or ranges > property, but no unit name > Warning (unit_address_vs_reg): /example-0/dsi@ff45: node has a unit name, > but no reg property > > Removing the "@xxx" from the node name fixed first warning. > Adding a missing reg property fixed the second warning > > Signed-off-by: Sam Ravnborg > Cc: Thierry Reding > Cc: Linus Walleij > Cc: Rob Herring > Cc: Heiko Stuebner > Cc: Maxime Ripard > Cc: Benjamin Gaignard > Cc: Laurent Pinchart Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/2] Add LVDS panel support to HiHope RZ/G2M
Hi Lad,
On Wed, Mar 11, 2020 at 9:03 PM Lad Prabhakar
wrote:
> The HiHope RZ/G2M is advertised as supporting panel idk-1110wr from
> Advantech, but the panel doesn't come with the board, it has to purchased
> separatey, therefore this series adds panel support to a new DT.
>
> v3->v4
> * Included rzg2-advantech-idk-1110wr-panel.dtsi in
>r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts file instead of re-inventing
>the wheel.
> * Dropped the Ack from Laurent for patch 2/2 due to above changes
>
> v2->v3
> * Included Reviewed-by from Rob and Laurent
> * Switched to dual license
> * Added myself as the maintainer
> * Updated copyright year
> * Rebased the patches
>
> v1->v2
> * fixed a space according to Geert's feedback.
>
> Thanks,
> Prabhakar
>
> Fabrizio Castro (2):
> dt-bindings: display: Add idk-1110wr binding
> arm64: dts: renesas: Add HiHope RZ/G2M board with idk-1110wr display
>
> .../display/panel/advantech,idk-1110wr.yaml| 69
> ++
> arch/arm64/boot/dts/renesas/Makefile | 1 +
> .../r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts| 52
> 3 files changed, 122 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
> create mode 100644
> arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts
Thanks for the update!
I've queued the second patch in renesas-devel for v5.7.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
