Re: [PATCH 19/60] drm/panel: Add driver for the LG Philips LB035Q02 panel
Hi Laurent.
>
> > > + unsigned int i;
> >
> > index to arrays are default "int" IIRC.
> > Not that it matters but noticed it.
>
> Are they ? I've always advocated for unsigned indexes to use unsigned
> int.
I did not dig up anything authorative - but found this:
https://stackoverflow.com/questions/8111357/type-of-array-index-in-c
There is some confusion betwwen the type of array and the type of the
index.
But the part that looks to answer the questions say that index can be
negative, so the integral type is default int.
Again, nothing to worry about, as code wokrs and unsigen int is used for
index in many places.
> > > +MODULE_LICENSE("GPL");
> >
> > This should be "GPL v2" if I read
> > https://www.kernel.org/doc/html/latest/process/license-rules.html
> > correct. See "MODULE_LICENSE" table.
>
> According to that table, "GPL v2" is defined as "Same as “GPL”. It
> exists for historic reasons.". My understanding is that "GPL v2" exists
> for historical reasons and should not be used in new code.
Re-reading the link you are right. module license is to be specified as
"GPL" and then one has to visit the file.
So ignore that comment in following reviews.
Seems simple to remember, will keep in mind for future reviews.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109246] HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=109246 --- Comment #22 from valentin...@gmail.com --- This is happening to me as well. RX570 w/ Acer H236HL Dual head, both inputs HDMI I didn't have this issue with the same monitors and an nvidia card, so it seems specific to the amdgpu driver. The monitors seem to lose signal (which is normal), then perform an auto input cycle which then wakes the monitors back up. The backlight will come on and display the mouse cursor on a black screen. I experience this with both Xorg and Wayland. Unfortunately I can't disable auto input on my monitors, as the previous workaround suggests. Just disabling DDC/CI didn't help. Adding amdgpu.dc=0 to linux cmdline resolves the issue for me, but I'm concerned that may preclude my system from gaining newer features. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [EXT] Re: [v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE
> -Original Message- > From: Philipp Zabel > Sent: 2019年7月5日 18:32 > To: Wen He ; linux-ker...@vger.kernel.org; > dri-devel@lists.freedesktop.org > Cc: Leo Li > Subject: [EXT] Re: [v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE > > Caution: EXT Email > > Hi Wen, > > On Wed, 2019-05-08 at 10:56 +, Wen He wrote: > > The new LS1028A DP driver code causes a link failure when DRM_IMX > > built-in, but platform is ARCH_LAYERSCAPE: > > > > drivers/gpu/drm/imx/ipuv3-crtc.c:51: undefined reference to > `ipu_prg_enable' > > drivers/gpu/drm/imx/ipuv3-crtc.c:52: undefined reference to > `ipu_dc_enable' > > drivers/gpu/drm/imx/ipuv3-crtc.c:53: undefined reference to > `ipu_dc_enable_channel' > > drivers/gpu/drm/imx/ipuv3-crtc.c:54: undefined reference to `ipu_di_enable' > > drivers/gpu/drm/imx/ipuv3-crtc.o: In function `ipu_crtc_mode_set_nofb > > > > Adding a Kconfig dependency allow to build if ARCH_LAYERSCAPE is enable. > > > > Signed-off-by: Wen He > > --- > > drivers/gpu/ipu-v3/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig > > index fe6f8c5b4445..51ea88c440df 100644 > > --- a/drivers/gpu/ipu-v3/Kconfig > > +++ b/drivers/gpu/ipu-v3/Kconfig > > @@ -1,6 +1,6 @@ > > config IMX_IPUV3_CORE > > tristate "IPUv3 core support" > > - depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM || > COMPILE_TEST > > + depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM || > > + COMPILE_TEST || ARCH_LAYERSCAPE > > depends on DRM || !DRM # if DRM=m, this can't be 'y' > > select BITREVERSE > > select GENERIC_ALLOCATOR if DRM > > -- > > 2.17.1 > > Thank you for the patch, but this does not seem right. > ipuv3-crtc.c is part of DRM_IMX, which already depends on IMX_IPUV3_CORE. > How did you manage to make it try to compile imxdrm? > Thanks for the review, Philipp, NXP LS1028A platform use same Display IP with IMX8, so they have use same display transmit controller drivers, config 'DRM_IMX' is used to support drm common drivers on the NXP I.MX and LS1028A, display transmit controller is coming to plan upstream. Actually, we have done compile of the imxdrm on LS1028A BSP release. > Since LS1028A does not have the IPUv3, keeping this under COMPILE_TEST > should be correct. Although LS1028A does not have the IPVv3, but DRM_IMX depends on it, LS1028A display Transmit controller drivers also depends on DRM_IMX, so we need add this dependency to solve the compile issue. Best Regards, Wen > > regards > Philipp
Re: [PATCH v3 5/5] dt-bindings: drm/panel: simple: add sharp,lq070y3dg3b panel
On Fri, 7 Jun 2019 13:11:11 +0200, "H. Nikolaus Schaller" wrote: > Signed-off-by: H. Nikolaus Schaller > --- > .../bindings/display/panel/sharp,lq070y3dg3b.txt | 12 > 1 file changed, 12 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/sharp,lq070y3dg3b.txt > Reviewed-by: Rob Herring
Re: [PATCH v3 4/5] dt-bindings: drm/panel: simple: add ortustech,com37h3m99dtc panel
On Fri, 7 Jun 2019 13:11:10 +0200, "H. Nikolaus Schaller" wrote: > Signed-off-by: H. Nikolaus Schaller > --- > .../display/panel/ortustech,com37h3m99dtc.txt| 12 > 1 file changed, 12 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/ortustech,com37h3m99dtc.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/5] dt-bindings: drm/panel: simple: add ortustech,com37h3m05dtc panel
On Fri, 7 Jun 2019 13:11:09 +0200, "H. Nikolaus Schaller" wrote: > Signed-off-by: H. Nikolaus Schaller > --- > .../display/panel/ortustech,com37h3m05dtc.txt| 12 > 1 file changed, 12 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/ortustech,com37h3m05dtc.txt > Reviewed-by: Rob Herring
Re: [PATCH v3, 04/27] dt-bindings: mediatek: add dither description for mt8183 display
On Wed, 5 Jun 2019 19:42:43 +0800, wrote: > From: Yongqiang Niu > > Update device tree binding documention for the display subsystem for > Mediatek MT8183 SOCs > > Signed-off-by: Yongqiang Niu > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3, 03/27] dt-bindings: mediatek: add ccorr description for mt8183 display
On Wed, 5 Jun 2019 19:42:42 +0800, wrote: > From: Yongqiang Niu > > Update device tree binding documention for the display subsystem for > Mediatek MT8183 SOCs > > Signed-off-by: Yongqiang Niu > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3, 02/27] dt-bindings: mediatek: add ovl_2l description for mt8183 display
On Wed, Jun 05, 2019 at 07:42:41PM +0800, yongqiang@mediatek.com wrote: > From: Yongqiang Niu > > Update device tree binding documention for the display subsystem for > Mediatek MT8183 SOCs > > Signed-off-by: Yongqiang Niu > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > index 70770fe..2418c56 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > @@ -28,6 +28,7 @@ > Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt. > Required properties (all function blocks): > - compatible: "mediatek,-disp-", one of > "mediatek,-disp-ovl" - overlay (4 layers, blending, > csc) > + "mediatek,-disp-ovl-2l" - overlay (2 layers, blending, > csc) Does a single chip have a mixture of this block doing 2 and 4 layers? If not, the part implies 2 vs. 4 layers. Rob
Re: [PATCH 17/60] dt-bindings: Add legacy 'toppoly' vendor prefix
On Mon, Jul 8, 2019 at 7:00 PM Laurent Pinchart wrote: > > Hi Rob, > > On Mon, Jul 08, 2019 at 01:00:35PM -0600, Rob Herring wrote: > > On Sun, Jul 7, 2019 at 12:25 PM Laurent Pinchart wrote: > > > > > > The 'toppoly' vendor prefix is in use and refers to TPO, whose DT vendor > > > prefix is already defined as 'tpo'. Add 'toppoly' as an alternative and > > > document it as legacy. > > > > > > Signed-off-by: Laurent Pinchart > > > --- > > > 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 2514463f2c63..d78527eb8254 100644 > > > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > > > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > > > @@ -867,6 +867,8 @@ patternProperties: > > > description: Tecon Microprocessor Technologies, LLC. > > >"^topeet,.*": > > > description: Topeet > > > + "^toppoly,.*": > > > +description: TPO (legacy prefix, see 'tpo') > > > > Add 'deprecated: true' also. That's a new property in json-schema > > draft8. It's not used for anything yet other than documentation. > > Thank you for the pointer. > > By the way this series conflicts with your patches that move all panel > bindings to yaml. I'll rebase it on top if yours gets merged first. I committed the series today, but I don't see what conflicts though. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 17/60] dt-bindings: Add legacy 'toppoly' vendor prefix
Hi Rob, On Mon, Jul 08, 2019 at 01:00:35PM -0600, Rob Herring wrote: > On Sun, Jul 7, 2019 at 12:25 PM Laurent Pinchart wrote: > > > > The 'toppoly' vendor prefix is in use and refers to TPO, whose DT vendor > > prefix is already defined as 'tpo'. Add 'toppoly' as an alternative and > > document it as legacy. > > > > Signed-off-by: Laurent Pinchart > > --- > > 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 2514463f2c63..d78527eb8254 100644 > > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > > @@ -867,6 +867,8 @@ patternProperties: > > description: Tecon Microprocessor Technologies, LLC. > >"^topeet,.*": > > description: Topeet > > + "^toppoly,.*": > > +description: TPO (legacy prefix, see 'tpo') > > Add 'deprecated: true' also. That's a new property in json-schema > draft8. It's not used for anything yet other than documentation. Thank you for the pointer. By the way this series conflicts with your patches that move all panel bindings to yaml. I'll rebase it on top if yours gets merged first. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Mon, Jul 1, 2019 at 2:58 AM Maxime Ripard wrote: > > Hi! > > On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote: > > On 12.06.2019 17:20, Maxime Ripard wrote: > > >> I am not sure if I understand whole discussion here, but I also do not > > >> understand whole edp-connector thing. > > > The context is this one: > > > https://patchwork.freedesktop.org/patch/257352/?series=51182=1 > > > https://patchwork.freedesktop.org/patch/283012/?series=56163=1 > > > https://patchwork.freedesktop.org/patch/286468/?series=56776=2 > > > > > > TL;DR: This bridge is being used on ARM laptops that can come with > > > different eDP panels. Some of these panels require a regulator to be > > > enabled for the panel to work, and this is obviously something that > > > should be in the DT. > > > > > > However, we can't really describe the panel itself, since the vendor > > > uses several of them and just relies on the eDP bus to do its job at > > > retrieving the EDIDs. A generic panel isn't really working either > > > since that would mean having a generic behaviour for all the panels > > > connected to that bus, which isn't there either. > > > > > > The connector allows to expose this nicely. > > > > As VESA presentation says[1] eDP is based on DP but is much more > > flexible, it is up to integrator (!!!) how the connection, power > > up/down, initialization sequence should be performed. Trying to cover > > every such case in edp-connector seems to me similar to panel-simple > > attempt failure. Moreover there is no such thing as physical standard > > eDP connector. Till now I though DT connector should describe physical > > connector on the device, now I am lost, are there some DT bindings > > guidelines about definition of a connector? > > This might be semantics but I guess we're in some kind of grey area? > > Like, for eDP, if it's soldered I guess we could say that there's no > connector. But what happens if for some other board, that signal is > routed through a ribbon? > > You could argue that there's no physical connector in both cases, or > that there's one in both, or one for the ribbon and no connector for > the one soldered in. > > > Maybe instead of edp-connector one would introduce integrator's specific > > connector, for example with compatible "olimex,teres-edp-connector" > > which should follow edp abstract connector rules? This will be at least > > consistent with below presentation[1] - eDP requirements depends on > > integrator. Then if olimex has standard way of dealing with panels > > present in olimex/teres platforms the driver would then create > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > > Anyway it still looks fishy for me :), maybe because I am not > > familiarized with details of these platforms. > > That makes sense yes Actually, it makes no sense at all. Current implementation for anx6345 driver works fine as is with any panel specified assuming panel delays are long enough for connected panel. It just doesn't use panel timings from the driver. Creating a platform driver for connector itself looks redundant since it can't be reused, it doesn't describe actual hardware and it's just defeats purpose of DT by introducing board-specific code. There's another issue: if we introduce edp-connector we'll have to specify power up delays somewhere (in dts? or in platform driver?), so edp-connector doesn't really solve the issue of multiple panels with same motherboard. I'd say DT overlays should be preferred solution here, not another connector binding. > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
Re: linux-next: manual merge of the akpm-current tree with the drm tree
Hi all,
On Mon, 24 Jun 2019 21:06:59 +1000 Stephen Rothwell
wrote:
>
> On Mon, 24 Jun 2019 20:49:08 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> >
> > mm/memory.c
> >
> > between commit:
> >
> > 29875a52915e ("mm: Add an apply_to_pfn_range interface")
> >
> > from the drm tree and commit:
> >
> > e972cea08fb3 ("mm/pgtable: drop pgtable_t variable from pte_fn_t
> > functions")
> >
> > from the akpm-current tree.
> >
> > I fixed it up (see below my signature, then added the following merge
> > resolution patch as well) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> > From: Stephen Rothwell
> > Date: Mon, 24 Jun 2019 20:40:46 +1000
> > Subject: [PATCH] merge fixup for "mm: Add an apply_to_pfn_range interface"
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > include/linux/mm.h| 2 +-
> > mm/as_dirty_helpers.c | 8 ++--
> > 2 files changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 87d53de3dee4..4404e18443ef 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -2673,7 +2673,7 @@ extern int apply_to_page_range(struct mm_struct *mm,
> > unsigned long address,
> >unsigned long size, pte_fn_t fn, void *data);
> >
> > struct pfn_range_apply;
> > -typedef int (*pter_fn_t)(pte_t *pte, pgtable_t token, unsigned long addr,
> > +typedef int (*pter_fn_t)(pte_t *pte, unsigned long addr,
> > struct pfn_range_apply *closure);
> > struct pfn_range_apply {
> > struct mm_struct *mm;
> > diff --git a/mm/as_dirty_helpers.c b/mm/as_dirty_helpers.c
> > index f600e31534fb..7c863626c2a4 100644
> > --- a/mm/as_dirty_helpers.c
> > +++ b/mm/as_dirty_helpers.c
> > @@ -26,7 +26,6 @@ struct apply_as {
> > /**
> > * apply_pt_wrprotect - Leaf pte callback to write-protect a pte
> > * @pte: Pointer to the pte
> > - * @token: Page table token, see apply_to_pfn_range()
> > * @addr: The virtual page address
> > * @closure: Pointer to a struct pfn_range_apply embedded in a
> > * struct apply_as
> > @@ -36,8 +35,7 @@ struct apply_as {
> > *
> > * Return: Always zero.
> > */
> > -static int apply_pt_wrprotect(pte_t *pte, pgtable_t token,
> > - unsigned long addr,
> > +static int apply_pt_wrprotect(pte_t *pte, unsigned long addr,
> > struct pfn_range_apply *closure)
> > {
> > struct apply_as *aas = container_of(closure, typeof(*aas), base);
> > @@ -78,7 +76,6 @@ struct apply_as_clean {
> > /**
> > * apply_pt_clean - Leaf pte callback to clean a pte
> > * @pte: Pointer to the pte
> > - * @token: Page table token, see apply_to_pfn_range()
> > * @addr: The virtual page address
> > * @closure: Pointer to a struct pfn_range_apply embedded in a
> > * struct apply_as_clean
> > @@ -91,8 +88,7 @@ struct apply_as_clean {
> > *
> > * Return: Always zero.
> > */
> > -static int apply_pt_clean(pte_t *pte, pgtable_t token,
> > - unsigned long addr,
> > +static int apply_pt_clean(pte_t *pte, unsigned long addr,
> > struct pfn_range_apply *closure)
> > {
> > struct apply_as *aas = container_of(closure, typeof(*aas), base);
> > --
> > 2.20.1
> >
> > --
> > Cheers,
> > Stephen Rothwell
> >
> > diff --cc mm/memory.c
> > index 462aa47f8878,f8a75528658a..e7e37fcbd687
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@@ -2037,12 -2036,11 +2035,11 @@@ static int apply_to_pte_range(struct pf
> > {
> > pte_t *pte;
> > int err;
> > - pgtable_t token;
> > spinlock_t *uninitialized_var(ptl);
> >
> > - pte = (mm == _mm) ?
> > + pte = (closure->mm == _mm) ?
> > pte_alloc_kernel(pmd, addr) :
> > - pte_alloc_map_lock(mm, pmd, addr, );
> > + pte_alloc_map_lock(closure->mm, pmd, addr, );
> > if (!pte)
> > return -ENOMEM;
> >
> > @@@ -2050,10 -2048,8 +2047,8 @@@
> >
> > arch_enter_lazy_mmu_mode();
> >
> > - token = pmd_pgtable(*pmd);
> > -
> > do {
> > - err = closure->ptefn(pte++, token, addr, closure);
> > - err = fn(pte++, addr, data);
> > ++ err = closure->ptefn(pte++, addr, closure);
> > if (err)
> > break;
> > } while (addr += PAGE_SIZE, addr != end);
>
> I also needed this:
>
> From: Stephen Rothwell
> Date: Mon, 24 Jun 2019 21:04:14 +1000
> Subject: [PATCH] another fixup for "mm: Add an apply_to_pfn_range interface"
>
> Signed-off-by: Stephen Rothwell
> ---
> mm/memory.c | 5 ++---
> 1 file changed, 2 insertions(+), 3
Re: linux-next: manual merge of the drm-intel tree with the pci tree
Hi all,
On Mon, 24 Jun 2019 13:53:52 +1000 Stephen Rothwell
wrote:
>
> On Mon, 17 Jun 2019 13:20:27 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the drm-intel tree got a conflict in:
> >
> > drivers/gpu/drm/i915/i915_drv.h
> >
> > between commit:
> >
> > 151f4e2bdc7a ("docs: power: convert docs to ReST and rename to *.rst")
> >
> > from the pci tree and commit:
> >
> > 1bf676cc2dba ("drm/i915: move and rename i915_runtime_pm")
> >
> > from the drm-intel tree.
> >
> > I fixed it up (I just removed the struct definition from this files as
> > the latter did - its comment will need to be fixed up in its new file)
> > and can carry the fix as necessary. This is now fixed as far as linux-next
> > is concerned, but any non trivial conflicts should be mentioned to your
> > upstream maintainer when your tree is submitted for merging. You may
> > also want to consider cooperating with the maintainer of the conflicting
> > tree to minimise any particularly complex conflicts.
>
> This is now a conflict between the drm and pci trees.
I am still getting this conflict (the commit ids may have changed).
Just a reminder in case you think Linus may need to know.
--
Cheers,
Stephen Rothwell
pgppZJU2grPto.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm tree with the jc_docs tree
Hi all,
On Mon, 24 Jun 2019 13:41:47 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> Documentation/fb/modedb.rst
>
> between commit:
>
> ab42b818954c ("docs: fb: convert docs to ReST and rename to *.rst")
>
> from the jc_docs tree and commit:
>
> 1bf4e09227c3 ("drm/modes: Allow to specify rotation and reflection on the
> commandline")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc Documentation/fb/modedb.rst
> index 3c2397293977,1dd5a52f9390..
> --- a/Documentation/fb/modedb.rst
> +++ b/Documentation/fb/modedb.rst
> @@@ -45,18 -45,29 +45,32 @@@ signals (e.g. HDMI and DVI-I). For othe
> is specified the output is disabled.
>
> You can additionally specify which output the options matches to.
> -To force the VGA output to be enabled and drive a specific mode say:
> +To force the VGA output to be enabled and drive a specific mode say::
> +
> video=VGA-1:1280x1024@60me
>
> -Specifying the option multiple times for different ports is possible, e.g.:
> +Specifying the option multiple times for different ports is possible, e.g.::
> +
> video=LVDS-1:d video=HDMI-1:D
>
> + Options can also be passed after the mode, using commas as separator.
> +
> +Sample usage: 720x480,rotate=180 - 720x480 mode, rotated by 180
> degrees
> +
> + Valid options are:
> +
> + - margin_top, margin_bottom, margin_left, margin_right (integer):
> + Number of pixels in the margins, typically to deal with overscan on TVs
> + - reflect_x (boolean): Perform an axial symmetry on the X axis
> + - reflect_y (boolean): Perform an axial symmetry on the Y axis
> + - rotate (integer): Rotate the initial framebuffer by x
> + degrees. Valid values are 0, 90, 180 and 270.
> +
> +
> -* oOo * oOo * oOo * oOo * oOo * oOo * oOo *
>
> +-
>
> What is the VESA(TM) Coordinated Video Timings (CVT)?
> +=
>
> From the VESA(TM) Website:
>
I am still getting this conflict (the commit ids may have changed).
Just a reminder in case you think Linus may need to know.
--
Cheers,
Stephen Rothwell
pgpZgs2kOOa8o.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 18/18] MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section
> On Mon, Jul 8, 2019 at 4:16 PM Brendan Higgins > wrote: >> >> CC'ing Iurii Zaikin >> >> On Fri, Jul 5, 2019 at 1:48 PM Luis Chamberlain wrote: >> > >> > On Wed, Jul 03, 2019 at 05:36:15PM -0700, Brendan Higgins wrote: >> > > Add entry for the new proc sysctl KUnit test to the PROC SYSCTL section. >> > > >> > > Signed-off-by: Brendan Higgins >> > > Reviewed-by: Greg Kroah-Hartman >> > > Reviewed-by: Logan Gunthorpe >> > > Acked-by: Luis Chamberlain >> > >> > Come to think of it, I'd welcome Iurii to be added as a maintainer, >> > with the hope Iurii would be up to review only the kunit changes. Of >> > course if Iurii would be up to also help review future proc changes, >> > even better. 3 pair of eyeballs is better than 2 pairs. >> >> What do you think, Iurii? I'm in.
Re: linux-next: manual merge of the drm tree with the kbuild tree
Hi all,
On Wed, 19 Jun 2019 14:19:49 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/Makefile.header-test
>
> between commit:
>
> e846f0dc57f4 ("kbuild: add support for ensuring headers are self-contained")
>
> from the kbuild tree and commits:
>
> 112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
> d91e657876a9 ("drm/i915: Introduce struct intel_wakeref")
> aab30b85c97a ("drm/i915: ensure more headers remain self-contained")
> b375d0ef2589 ("drm/i915: extract intel_vdsc.h from intel_drv.h and
> i915_drv.h")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/i915/Makefile.header-test
> index 639b596a06a9,3a9663002d4a..
> --- a/drivers/gpu/drm/i915/Makefile.header-test
> +++ b/drivers/gpu/drm/i915/Makefile.header-test
> @@@ -2,18 -2,28 +2,28 @@@
> # Copyright © 2019 Intel Corporation
>
> # Test the headers are compilable as standalone units
> -header_test := \
> +header-test-$(CONFIG_DRM_I915_WERROR) := \
> i915_active_types.h \
> + i915_debugfs.h \
> + i915_drv.h \
> i915_gem_context_types.h \
> + i915_gem_pm.h \
> + i915_irq.h \
> + i915_params.h \
> i915_priolist_types.h \
> + i915_reg.h \
> i915_scheduler_types.h \
> i915_timeline_types.h \
> + i915_utils.h \
> + intel_acpi.h \
> + intel_atomic.h \
> intel_atomic_plane.h \
> intel_audio.h \
> + intel_bios.h \
> intel_cdclk.h \
> intel_color.h \
> + intel_combo_phy.h \
> intel_connector.h \
> - intel_context_types.h \
> intel_crt.h \
> intel_csr.h \
> intel_ddi.h \
> @@@ -31,7 -54,22 +54,12 @@@
> intel_pipe_crc.h \
> intel_pm.h \
> intel_psr.h \
> + intel_quirks.h \
> + intel_runtime_pm.h \
> intel_sdvo.h \
> + intel_sideband.h \
> intel_sprite.h \
> intel_tv.h \
> - intel_workarounds_types.h
> + intel_uncore.h \
> + intel_vdsc.h \
> + intel_wakeref.h
> -
> -quiet_cmd_header_test = HDRTEST $@
> - cmd_header_test = echo "\#include \"$( $@
> -
> -header_test_%.c: %.h
> -$(call cmd,header_test)
> -
> -i915-$(CONFIG_DRM_I915_WERROR) += $(foreach h,$(header_test),$(patsubst
> %.h,header_test_%.o,$(h)))
> -
> -clean-files += $(foreach h,$(header_test),$(patsubst
> %.h,header_test_%.c,$(h)))
I am still getting this conflict (the commit ids may have changed).
Just a reminder in case you think Linus may need to know.
--
Cheers,
Stephen Rothwell
pgpMBmCvnuQRy.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 18/18] MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section
CC'ing Iurii Zaikin On Fri, Jul 5, 2019 at 1:48 PM Luis Chamberlain wrote: > > On Wed, Jul 03, 2019 at 05:36:15PM -0700, Brendan Higgins wrote: > > Add entry for the new proc sysctl KUnit test to the PROC SYSCTL section. > > > > Signed-off-by: Brendan Higgins > > Reviewed-by: Greg Kroah-Hartman > > Reviewed-by: Logan Gunthorpe > > Acked-by: Luis Chamberlain > > Come to think of it, I'd welcome Iurii to be added as a maintainer, > with the hope Iurii would be up to review only the kunit changes. Of > course if Iurii would be up to also help review future proc changes, > even better. 3 pair of eyeballs is better than 2 pairs. What do you think, Iurii?
[PATCH v4, 02/33] dt-bindings: mediatek: add ovl_2l description for mt8183 display
From: Yongqiang Niu Update device tree binding documention for the display subsystem for Mediatek MT8183 SOCs Signed-off-by: Yongqiang Niu --- .../bindings/display/mediatek/mediatek,disp.txt| 27 +++--- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index 464b92f..8c4700f 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -27,19 +27,20 @@ Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt. Required properties (all function blocks): - compatible: "mediatek,-disp-", one of - "mediatek,-disp-ovl" - overlay (4 layers, blending, csc) - "mediatek,-disp-rdma" - read DMA / line buffer - "mediatek,-disp-wdma" - write DMA - "mediatek,-disp-color" - color processor - "mediatek,-disp-aal" - adaptive ambient light controller - "mediatek,-disp-gamma" - gamma correction - "mediatek,-disp-merge" - merge streams from two RDMA sources - "mediatek,-disp-split" - split stream to two encoders - "mediatek,-disp-ufoe" - data compression engine - "mediatek,-dsi"- DSI controller, see mediatek,dsi.txt - "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt - "mediatek,-disp-mutex" - display mutex - "mediatek,-disp-od"- overdrive + "mediatek,-disp-ovl" - overlay (4 layers, blending, csc) + "mediatek,-disp-ovl-2l" - overlay (2 layers, blending, csc) + "mediatek,-disp-rdma" - read DMA / line buffer + "mediatek,-disp-wdma" - write DMA + "mediatek,-disp-color"- color processor + "mediatek,-disp-aal" - adaptive ambient light controller + "mediatek,-disp-gamma"- gamma correction + "mediatek,-disp-merge"- merge streams from two RDMA sources + "mediatek,-disp-split"- split stream to two encoders + "mediatek,-disp-ufoe" - data compression engine + "mediatek,-dsi" - DSI controller, see mediatek,dsi.txt + "mediatek,-dpi" - DPI controller, see mediatek,dpi.txt + "mediatek,-disp-mutex"- display mutex + "mediatek,-disp-od" - overdrive the supported chips are mt2701, mt2712 and mt8173. - reg: Physical base address and length of the function block register space - interrupts: The interrupt signal from the function block (required, except for -- 1.8.1.1.dirty
[PATCH v4, 06/33] dt-bindings: mediatek: add mutex description for mt8183 display
From: Yongqiang Niu This patch add mutex description for mt8183 display Signed-off-by: Yongqiang Niu --- Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index bb9274a..4a22d49 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -53,6 +53,7 @@ Required properties (all function blocks): For most function blocks this is just a single clock input. Only the DSI and DPI controller nodes have multiple clock inputs. These are documented in mediatek,dsi.txt and mediatek,dpi.txt, respectively. + for MT8183 mutex, this hardware is always free run, has no clocks control Required properties (DMA function blocks): - compatible: Should be one of -- 1.8.1.1.dirty
[PATCH v4, 04/33] dt-bindings: mediatek: add dither description for mt8183 display
From: Yongqiang Niu Update device tree binding documention for the display subsystem for Mediatek MT8183 SOCs Signed-off-by: Yongqiang Niu --- Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index cf5fb08..afd3c90 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -33,6 +33,7 @@ Required properties (all function blocks): "mediatek,-disp-wdma" - write DMA "mediatek,-disp-ccorr"- color correction "mediatek,-disp-color"- color processor + "mediatek,-disp-dither" - dither "mediatek,-disp-aal" - adaptive ambient light controller "mediatek,-disp-gamma"- gamma correction "mediatek,-disp-merge"- merge streams from two RDMA sources -- 1.8.1.1.dirty
[PATCH v4, 07/33] arm64: dts: add display nodes for mt8183
From: Yongqiang Niu
This patch add display nodes for mt8183
Signed-off-by: Yongqiang Niu
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 109 +++
1 file changed, 109 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index d13ade7..4991c64 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -17,6 +17,14 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ ovl0 =
+ ovl_2l0 = _2l0;
+ ovl_2l1 = _2l1;
+ rdma0 =
+ rdma1 =
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -327,6 +335,107 @@
#clock-cells = <1>;
};
+ display_components: dispsys@1400 {
+ compatible = "mediatek,mt8183-display";
+ reg = <0 0x1400 0 0x1000>;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ };
+
+ ovl0: ovl@14008000 {
+ compatible = "mediatek,mt8183-disp-ovl";
+ reg = <0 0x14008000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_OVL0>;
+ mediatek,larb = <>;
+ };
+
+ ovl_2l0: ovl@14009000 {
+ compatible = "mediatek,mt8183-disp-ovl-2l";
+ reg = <0 0x14009000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_OVL0_2L>;
+ mediatek,larb = <>;
+ };
+
+ ovl_2l1: ovl@1400a000 {
+ compatible = "mediatek,mt8183-disp-ovl-2l";
+ reg = <0 0x1400a000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_OVL1_2L>;
+ mediatek,larb = <>;
+ };
+
+ rdma0: rdma@1400b000 {
+ compatible = "mediatek,mt8183-disp-rdma";
+ reg = <0 0x1400b000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_RDMA0>;
+ mediatek,larb = <>;
+ };
+
+ rdma1: rdma@1400c000 {
+ compatible = "mediatek,mt8183-disp-rdma1";
+ reg = <0 0x1400c000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_RDMA1>;
+ mediatek,larb = <>;
+ };
+
+ color0: color@1400e000 {
+ compatible = "mediatek,mt8183-disp-color",
+"mediatek,mt8173-disp-color";
+ reg = <0 0x1400e000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_COLOR0>;
+ };
+
+ ccorr0: ccorr@1400f000 {
+ compatible = "mediatek,mt8183-disp-ccorr";
+ reg = <0 0x1400f000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_CCORR0>;
+ };
+
+ aal0: aal@1401 {
+ compatible = "mediatek,mt8183-disp-aal",
+"mediatek,mt8173-disp-aal";
+ reg = <0 0x1401 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_AAL0>;
+ };
+
+ gamma0: gamma@14011000 {
+ compatible = "mediatek,mt8183-disp-gamma",
+"mediatek,mt8173-disp-gamma";
+ reg = <0 0x14011000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_GAMMA0>;
+ };
+
+ dither0: dither@14012000 {
+ compatible = "mediatek,mt8183-disp-dither";
+ reg = <0 0x14012000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ clocks = < CLK_MM_DISP_DITHER0>;
+
[PATCH v4, 10/33] drm/mediatek: add mutex sof into ddp private data
From: Yongqiang Niu
mutex sof will be ddp private data
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 43 +++---
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8bde2cf..ab396ee 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -149,8 +149,19 @@ struct mtk_disp_mutex {
bool claimed;
};
+enum mtk_ddp_mutex_sof_id {
+ DDP_MUTEX_SOF_SINGLE_MODE,
+ DDP_MUTEX_SOF_DSI0,
+ DDP_MUTEX_SOF_DSI1,
+ DDP_MUTEX_SOF_DPI0,
+ DDP_MUTEX_SOF_DPI1,
+ DDP_MUTEX_SOF_DSI2,
+ DDP_MUTEX_SOF_DSI3,
+};
+
struct mtk_ddp_data {
const unsigned int *mutex_mod;
+ const unsigned int *mutex_sof;
const unsigned int mutex_mod_reg;
};
@@ -209,18 +220,31 @@ struct mtk_ddp {
[DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
};
+static const unsigned int mt2712_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
+ [DDP_MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
+ [DDP_MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
+ [DDP_MUTEX_SOF_DSI1] = MUTEX_SOF_DSI1,
+ [DDP_MUTEX_SOF_DPI0] = MUTEX_SOF_DPI0,
+ [DDP_MUTEX_SOF_DPI1] = MUTEX_SOF_DPI1,
+ [DDP_MUTEX_SOF_DSI2] = MUTEX_SOF_DSI2,
+ [DDP_MUTEX_SOF_DSI3] = MUTEX_SOF_DSI3,
+};
+
static const struct mtk_ddp_data mt2701_ddp_driver_data = {
.mutex_mod = mt2701_mutex_mod,
+ .mutex_sof = mt2712_mutex_sof,
.mutex_mod_reg = MT2701_DISP_MUTEX0_MOD0,
};
static const struct mtk_ddp_data mt2712_ddp_driver_data = {
.mutex_mod = mt2712_mutex_mod,
+ .mutex_sof = mt2712_mutex_sof,
.mutex_mod_reg = MT2701_DISP_MUTEX0_MOD0,
};
static const struct mtk_ddp_data mt8173_ddp_driver_data = {
.mutex_mod = mt8173_mutex_mod,
+ .mutex_sof = mt2712_mutex_sof,
.mutex_mod_reg = MT2701_DISP_MUTEX0_MOD0,
};
@@ -462,28 +486,29 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
mutex[mutex->id]);
unsigned int reg;
+ unsigned int sof_id;
unsigned int offset;
WARN_ON(>mutex[mutex->id] != mutex);
switch (id) {
case DDP_COMPONENT_DSI0:
- reg = MUTEX_SOF_DSI0;
+ sof_id = DDP_MUTEX_SOF_DSI0;
break;
case DDP_COMPONENT_DSI1:
- reg = MUTEX_SOF_DSI0;
+ sof_id = DDP_MUTEX_SOF_DSI0;
break;
case DDP_COMPONENT_DSI2:
- reg = MUTEX_SOF_DSI2;
+ sof_id = DDP_MUTEX_SOF_DSI2;
break;
case DDP_COMPONENT_DSI3:
- reg = MUTEX_SOF_DSI3;
+ sof_id = DDP_MUTEX_SOF_DSI3;
break;
case DDP_COMPONENT_DPI0:
- reg = MUTEX_SOF_DPI0;
+ sof_id = DDP_MUTEX_SOF_DPI0;
break;
case DDP_COMPONENT_DPI1:
- reg = MUTEX_SOF_DPI1;
+ sof_id = DDP_MUTEX_SOF_DPI1;
break;
default:
if (ddp->data->mutex_mod[id] < 32) {
@@ -501,7 +526,8 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
return;
}
- writel_relaxed(reg, ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
+ writel_relaxed(ddp->data->mutex_sof[sof_id],
+ ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
}
void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
@@ -522,7 +548,8 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
*mutex,
case DDP_COMPONENT_DPI0:
case DDP_COMPONENT_DPI1:
writel_relaxed(MUTEX_SOF_SINGLE_MODE,
- ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
+ ddp->regs +
+ DISP_REG_MUTEX_SOF(mutex->id));
break;
default:
if (ddp->data->mutex_mod[id] < 32) {
--
1.8.1.1.dirty
[PATCH v4, 17/33] drm/mediatek: add component OVL_2L1
From: Yongqiang Niu
This patch add component OVL_2L1
Signed-off-by: Yongqiang Niu
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index bcbf673..1aa4224 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -268,6 +268,7 @@ struct mtk_ddp_comp_match {
[DDP_COMPONENT_OVL0]= { MTK_DISP_OVL, 0, NULL },
[DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L,0, NULL },
+ [DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L,1, NULL },
[DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
[DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
[DDP_COMPONENT_PWM2]= { MTK_DISP_PWM, 2, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 8f586d0..8ac9f62 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -60,6 +60,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_OD1,
DDP_COMPONENT_OVL0,
DDP_COMPONENT_OVL_2L0,
+ DDP_COMPONENT_OVL_2L1,
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
DDP_COMPONENT_PWM1,
--
1.8.1.1.dirty
[PATCH v4, 20/33] drm/medaitek: add layer_nr for ovl private data
From: Yongqiang Niu
This patch add layer_nr for ovl private data
ovl_2l almost same with with ovl hardware, except the
layer number for ovl_2l is 2 and ovl is 4.
this patch is a preparation for ovl-2l and
ovl share the same driver.
Signed-off-by: Yongqiang Niu
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index afb313c..a0ab760 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -60,6 +60,7 @@
struct mtk_disp_ovl_data {
unsigned int addr;
unsigned int gmc_bits;
+ unsigned int layer_nr;
bool fmt_rgb565_is_0;
};
@@ -137,7 +138,9 @@ static void mtk_ovl_config(struct mtk_ddp_comp *comp,
unsigned int w,
static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp *comp)
{
- return 4;
+ struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
+
+ return ovl->data->layer_nr;
}
static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx)
@@ -342,12 +345,14 @@ static int mtk_disp_ovl_remove(struct platform_device
*pdev)
static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
.addr = DISP_REG_OVL_ADDR_MT2701,
.gmc_bits = 8,
+ .layer_nr = 4,
.fmt_rgb565_is_0 = false,
};
static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
.addr = DISP_REG_OVL_ADDR_MT8173,
.gmc_bits = 8,
+ .layer_nr = 4,
.fmt_rgb565_is_0 = true,
};
--
1.8.1.1.dirty
[PATCH v4, 29/33] drm/mediatek: add connection from OVL_2L0 to RDMA0
From: Yongqiang Niu
this patch add add connection from OVL_2L0 to RDMA0
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index fbea47f..0a63dd0 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -41,6 +41,12 @@
#define DISP_REG_CONFIG_DSI_SEL0x050
#define DISP_REG_CONFIG_DPI_SEL0x064
+#define MT8183_DISP_OVL0_2L_MOUT_EN0xf04
+#define MT8183_DISP_PATH0_SEL_IN 0xf24
+
+#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
+#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
+
#define MT2701_DISP_MUTEX0_MOD00x2c
#define MT2701_DISP_MUTEX0_SOF00x30
@@ -315,6 +321,10 @@ static unsigned int mtk_ddp_mout_en(const struct
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_OVL_2L0) {
*addr = data->ovl0_mout_en;
value = OVL0_MOUT_EN_OVL0_2L;
+ } else if (cur == DDP_COMPONENT_OVL_2L0 &&
+ next == DDP_COMPONENT_RDMA0) {
+ *addr = MT8183_DISP_OVL0_2L_MOUT_EN;
+ value = OVL0_2L_MOUT_EN_DISP_PATH0;
} else {
value = 0;
}
@@ -374,6 +384,10 @@ static unsigned int mtk_ddp_sel_in(const struct
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
*addr = DISP_REG_CONFIG_DSI_SEL;
value = DSI_SEL_IN_BLS;
+ } else if (cur == DDP_COMPONENT_OVL_2L0 &&
+ next == DDP_COMPONENT_RDMA0) {
+ *addr = MT8183_DISP_PATH0_SEL_IN;
+ value = DISP_PATH0_SEL_IN_OVL0_2L;
} else {
value = 0;
}
--
1.8.1.1.dirty
[PATCH v4, 18/33] drm/mediatek: add component DITHER
From: Yongqiang Niu
This patch add component DITHER
Signed-off-by: Yongqiang Niu
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 32 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 1aa4224..bc92a1b 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -47,6 +47,12 @@
#define CCORR_RELAY_MODE BIT(0)
#define DISP_CCORR_SIZE0x0030
+#define DISP_DITHER_EN 0x
+#define DITHER_EN BIT(0)
+#define DISP_DITHER_CFG0x0020
+#define DITHER_RELAY_MODE BIT(0)
+#define DISP_DITHER_SIZE 0x0030
+
#define DISP_GAMMA_EN 0x
#define DISP_GAMMA_CFG 0x0020
#define DISP_GAMMA_SIZE0x0030
@@ -155,6 +161,24 @@ static void mtk_ccorr_stop(struct mtk_ddp_comp *comp)
writel_relaxed(0x0, comp->regs + DISP_CCORR_EN);
}
+static void mtk_dither_config(struct mtk_ddp_comp *comp, unsigned int w,
+ unsigned int h, unsigned int vrefresh,
+ unsigned int bpc)
+{
+ writel(h << 16 | w, comp->regs + DISP_DITHER_SIZE);
+ writel(DITHER_RELAY_MODE, comp->regs + DISP_DITHER_CFG);
+}
+
+static void mtk_dither_start(struct mtk_ddp_comp *comp)
+{
+ writel(DITHER_EN, comp->regs + DISP_DITHER_EN);
+}
+
+static void mtk_dither_stop(struct mtk_ddp_comp *comp)
+{
+ writel_relaxed(0x0, comp->regs + DISP_DITHER_EN);
+}
+
static void mtk_gamma_config(struct mtk_ddp_comp *comp, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc)
@@ -209,6 +233,12 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
.stop = mtk_ccorr_stop,
};
+static const struct mtk_ddp_comp_funcs ddp_dither = {
+ .config = mtk_dither_config,
+ .start = mtk_dither_start,
+ .stop = mtk_dither_stop,
+};
+
static const struct mtk_ddp_comp_funcs ddp_gamma = {
.gamma_set = mtk_gamma_set,
.config = mtk_gamma_config,
@@ -234,6 +264,7 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
[MTK_DISP_CCORR] = "ccorr",
[MTK_DISP_AAL] = "aal",
[MTK_DISP_GAMMA] = "gamma",
+ [MTK_DISP_DITHER] = "dither",
[MTK_DISP_UFOE] = "ufoe",
[MTK_DSI] = "dsi",
[MTK_DPI] = "dpi",
@@ -256,6 +287,7 @@ struct mtk_ddp_comp_match {
[DDP_COMPONENT_CCORR] = { MTK_DISP_CCORR, 0, _ccorr },
[DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, NULL },
[DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, NULL },
+ [DDP_COMPONENT_DITHER] = { MTK_DISP_DITHER,0, _dither },
[DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
[DDP_COMPONENT_DPI1]= { MTK_DPI,1, NULL },
[DDP_COMPONENT_DSI0]= { MTK_DSI,0, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 8ac9f62..a0ea8c9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -30,6 +30,7 @@ enum mtk_ddp_comp_type {
MTK_DISP_WDMA,
MTK_DISP_COLOR,
MTK_DISP_CCORR,
+ MTK_DISP_DITHER,
MTK_DISP_AAL,
MTK_DISP_GAMMA,
MTK_DISP_UFOE,
@@ -49,6 +50,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_CCORR,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_COLOR1,
+ DDP_COMPONENT_DITHER,
DDP_COMPONENT_DPI0,
DDP_COMPONENT_DPI1,
DDP_COMPONENT_DSI0,
--
1.8.1.1.dirty
[PATCH v4, 23/33] drm/mediatek: add ovl0/ovl_2l0 usecase
From: Yongqiang Niu
This patch add ovl0/ovl_2l0 usecase
in ovl->ovl_2l0 direct link usecase:
1. the crtc support layer number will 4+2
2. ovl_2l0 background color input select ovl0 when crtc init
and disable it when crtc finish
3. config ovl_2l0 layer, if crtc config layer number is
bigger than ovl0 support layers(max is 4)
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 38 +++--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 5eac376..9ee9ce2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -282,6 +282,15 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];
+ enum mtk_ddp_comp_id prev;
+
+ if (i > 0)
+ prev = mtk_crtc->ddp_comp[i - 1]->id;
+ else
+ prev = DDP_COMPONENT_ID_MAX;
+
+ if (prev == DDP_COMPONENT_OVL0)
+ mtk_ddp_comp_bgclr_in_on(comp);
mtk_ddp_comp_config(comp, width, height, vrefresh, bpc);
mtk_ddp_comp_start(comp);
@@ -291,9 +300,18 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
for (i = 0; i < mtk_crtc->layer_nr; i++) {
struct drm_plane *plane = _crtc->planes[i];
struct mtk_plane_state *plane_state;
+ struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
+ unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
+ unsigned int local_layer;
plane_state = to_mtk_plane_state(plane->state);
- mtk_ddp_comp_layer_config(mtk_crtc->ddp_comp[0], i,
+
+ if (i >= comp_layer_nr) {
+ comp = mtk_crtc->ddp_comp[1];
+ local_layer = i - comp_layer_nr;
+ } else
+ local_layer = i;
+ mtk_ddp_comp_layer_config(comp , local_layer,
plane_state);
}
@@ -319,6 +337,7 @@ 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_comp_bgclr_in_off(mtk_crtc->ddp_comp[i]);
mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
mtk_crtc->mmsys_reg_data,
mtk_crtc->ddp_comp[i]->id,
@@ -339,6 +358,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
unsigned int i;
+ unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
+ unsigned int local_layer;
/*
* TODO: instead of updating the registers here, we should prepare
@@ -361,7 +382,14 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
plane_state = to_mtk_plane_state(plane->state);
if (plane_state->pending.config) {
- mtk_ddp_comp_layer_config(comp, i, plane_state);
+ if (i >= comp_layer_nr) {
+ comp = mtk_crtc->ddp_comp[1];
+ local_layer = i - comp_layer_nr;
+ } else
+ local_layer = i;
+
+ mtk_ddp_comp_layer_config(comp, local_layer,
+ plane_state);
plane_state->pending.config = false;
}
}
@@ -592,6 +620,12 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
}
mtk_crtc->layer_nr = mtk_ddp_comp_layer_nr(mtk_crtc->ddp_comp[0]);
+ if (mtk_crtc->ddp_comp_nr > 1) {
+ struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[1];
+
+ if (comp->funcs->bgclr_in_on)
+ mtk_crtc->layer_nr += mtk_ddp_comp_layer_nr(comp);
+ }
mtk_crtc->planes = devm_kcalloc(dev, mtk_crtc->layer_nr,
sizeof(struct drm_plane),
GFP_KERNEL);
--
1.8.1.1.dirty
[PATCH v4, 15/33] drm/mediatek: add ddp component CCORR
From: Yongqiang Niu
This patch add ddp component CCORR
Signed-off-by: Yongqiang Niu
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 32 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index ede15c9..b357b24 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -41,6 +41,12 @@
#define DISP_AAL_EN0x
#define DISP_AAL_SIZE 0x0030
+#define DISP_CCORR_EN 0x
+#define CCORR_EN BIT(0)
+#define DISP_CCORR_CFG 0x0020
+#define CCORR_RELAY_MODE BIT(0)
+#define DISP_CCORR_SIZE0x0030
+
#define DISP_GAMMA_EN 0x
#define DISP_GAMMA_CFG 0x0020
#define DISP_GAMMA_SIZE0x0030
@@ -131,6 +137,24 @@ static void mtk_aal_stop(struct mtk_ddp_comp *comp)
writel_relaxed(0x0, comp->regs + DISP_AAL_EN);
}
+static void mtk_ccorr_config(struct mtk_ddp_comp *comp, unsigned int w,
+unsigned int h, unsigned int vrefresh,
+unsigned int bpc)
+{
+ writel(h << 16 | w, comp->regs + DISP_CCORR_SIZE);
+ writel(CCORR_RELAY_MODE, comp->regs + DISP_CCORR_CFG);
+}
+
+static void mtk_ccorr_start(struct mtk_ddp_comp *comp)
+{
+ writel(CCORR_EN, comp->regs + DISP_CCORR_EN);
+}
+
+static void mtk_ccorr_stop(struct mtk_ddp_comp *comp)
+{
+ writel_relaxed(0x0, comp->regs + DISP_CCORR_EN);
+}
+
static void mtk_gamma_config(struct mtk_ddp_comp *comp, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc)
@@ -179,6 +203,12 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
.stop = mtk_aal_stop,
};
+static const struct mtk_ddp_comp_funcs ddp_ccorr = {
+ .config = mtk_ccorr_config,
+ .start = mtk_ccorr_start,
+ .stop = mtk_ccorr_stop,
+};
+
static const struct mtk_ddp_comp_funcs ddp_gamma = {
.gamma_set = mtk_gamma_set,
.config = mtk_gamma_config,
@@ -200,6 +230,7 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
[MTK_DISP_RDMA] = "rdma",
[MTK_DISP_WDMA] = "wdma",
[MTK_DISP_COLOR] = "color",
+ [MTK_DISP_CCORR] = "ccorr",
[MTK_DISP_AAL] = "aal",
[MTK_DISP_GAMMA] = "gamma",
[MTK_DISP_UFOE] = "ufoe",
@@ -221,6 +252,7 @@ struct mtk_ddp_comp_match {
[DDP_COMPONENT_AAL0]= { MTK_DISP_AAL, 0, _aal },
[DDP_COMPONENT_AAL1]= { MTK_DISP_AAL, 1, _aal },
[DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
+ [DDP_COMPONENT_CCORR] = { MTK_DISP_CCORR, 0, _ccorr },
[DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, NULL },
[DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, NULL },
[DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index b8dc17e..bd5fcc9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -28,6 +28,7 @@ enum mtk_ddp_comp_type {
MTK_DISP_RDMA,
MTK_DISP_WDMA,
MTK_DISP_COLOR,
+ MTK_DISP_CCORR,
MTK_DISP_AAL,
MTK_DISP_GAMMA,
MTK_DISP_UFOE,
@@ -44,6 +45,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_AAL0,
DDP_COMPONENT_AAL1,
DDP_COMPONENT_BLS,
+ DDP_COMPONENT_CCORR,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_COLOR1,
DDP_COMPONENT_DPI0,
--
1.8.1.1.dirty
[PATCH v4, 16/33] drm/mediatek: add commponent OVL_2L0
From: Yongqiang Niu
This patch add commponent OVL_2L0
Signed-off-by: Yongqiang Niu
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index b357b24..bcbf673 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -227,6 +227,7 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
[MTK_DISP_OVL] = "ovl",
+ [MTK_DISP_OVL_2L] = "ovl_2l",
[MTK_DISP_RDMA] = "rdma",
[MTK_DISP_WDMA] = "wdma",
[MTK_DISP_COLOR] = "color",
@@ -266,6 +267,7 @@ struct mtk_ddp_comp_match {
[DDP_COMPONENT_OD1] = { MTK_DISP_OD,1, _od },
[DDP_COMPONENT_OVL0]= { MTK_DISP_OVL, 0, NULL },
[DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, NULL },
+ [DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L,0, NULL },
[DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
[DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
[DDP_COMPONENT_PWM2]= { MTK_DISP_PWM, 2, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index bd5fcc9..8f586d0 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -25,6 +25,7 @@
enum mtk_ddp_comp_type {
MTK_DISP_OVL,
+ MTK_DISP_OVL_2L,
MTK_DISP_RDMA,
MTK_DISP_WDMA,
MTK_DISP_COLOR,
@@ -58,6 +59,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_OD0,
DDP_COMPONENT_OD1,
DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_OVL_2L0,
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
DDP_COMPONENT_PWM1,
--
1.8.1.1.dirty
[PATCH v4, 11/33] drm/mediatek: add mutex sof register offset into ddp private data
From: Yongqiang Niu
mutex sof register offset will be private data of ddp
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index ab396ee..d015c1a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -42,12 +42,13 @@
#define DISP_REG_CONFIG_DPI_SEL0x064
#define MT2701_DISP_MUTEX0_MOD00x2c
+#define MT2701_DISP_MUTEX0_SOF00x30
#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
#define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
#define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
#define DISP_REG_MUTEX_MOD(mutex_mod_reg, n) (mutex_mod_reg + 0x20 * (n))
-#define DISP_REG_MUTEX_SOF(n) (0x30 + 0x20 * (n))
+#define DISP_REG_MUTEX_SOF(mutex_sof_reg, n) (mutex_sof_reg + 0x20 * (n))
#define DISP_REG_MUTEX_MOD2(n) (0x34 + 0x20 * (n))
#define INT_MUTEX BIT(1)
@@ -163,6 +164,7 @@ struct mtk_ddp_data {
const unsigned int *mutex_mod;
const unsigned int *mutex_sof;
const unsigned int mutex_mod_reg;
+ const unsigned int mutex_sof_reg;
};
struct mtk_ddp {
@@ -234,18 +236,21 @@ struct mtk_ddp {
.mutex_mod = mt2701_mutex_mod,
.mutex_sof = mt2712_mutex_sof,
.mutex_mod_reg = MT2701_DISP_MUTEX0_MOD0,
+ .mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
};
static const struct mtk_ddp_data mt2712_ddp_driver_data = {
.mutex_mod = mt2712_mutex_mod,
.mutex_sof = mt2712_mutex_sof,
.mutex_mod_reg = MT2701_DISP_MUTEX0_MOD0,
+ .mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
};
static const struct mtk_ddp_data mt8173_ddp_driver_data = {
.mutex_mod = mt8173_mutex_mod,
.mutex_sof = mt2712_mutex_sof,
.mutex_mod_reg = MT2701_DISP_MUTEX0_MOD0,
+ .mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
};
static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
@@ -527,7 +532,8 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
}
writel_relaxed(ddp->data->mutex_sof[sof_id],
- ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
+ ddp->regs +
+ DISP_REG_MUTEX_SOF(ddp->data->mutex_sof_reg, mutex->id));
}
void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
@@ -549,7 +555,8 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
*mutex,
case DDP_COMPONENT_DPI1:
writel_relaxed(MUTEX_SOF_SINGLE_MODE,
ddp->regs +
- DISP_REG_MUTEX_SOF(mutex->id));
+ DISP_REG_MUTEX_SOF(ddp->data->mutex_sof_reg,
+ mutex->id));
break;
default:
if (ddp->data->mutex_mod[id] < 32) {
--
1.8.1.1.dirty
[PATCH v4, 09/33] drm/mediatek: add mutex mod register offset into ddp private data
From: Yongqiang Niu
mutex mod register offset will be private data of ddp.
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 412b82f..8bde2cf 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -41,12 +41,14 @@
#define DISP_REG_CONFIG_DSI_SEL0x050
#define DISP_REG_CONFIG_DPI_SEL0x064
-#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
-#define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
-#define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
-#define DISP_REG_MUTEX_MOD(n) (0x2c + 0x20 * (n))
-#define DISP_REG_MUTEX_SOF(n) (0x30 + 0x20 * (n))
-#define DISP_REG_MUTEX_MOD2(n) (0x34 + 0x20 * (n))
+#define MT2701_DISP_MUTEX0_MOD00x2c
+
+#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
+#define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
+#define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
+#define DISP_REG_MUTEX_MOD(mutex_mod_reg, n) (mutex_mod_reg + 0x20 * (n))
+#define DISP_REG_MUTEX_SOF(n) (0x30 + 0x20 * (n))
+#define DISP_REG_MUTEX_MOD2(n) (0x34 + 0x20 * (n))
#define INT_MUTEX BIT(1)
@@ -149,6 +151,7 @@ struct mtk_disp_mutex {
struct mtk_ddp_data {
const unsigned int *mutex_mod;
+ const unsigned int mutex_mod_reg;
};
struct mtk_ddp {
@@ -208,14 +211,17 @@ struct mtk_ddp {
static const struct mtk_ddp_data mt2701_ddp_driver_data = {
.mutex_mod = mt2701_mutex_mod,
+ .mutex_mod_reg = MT2701_DISP_MUTEX0_MOD0,
};
static const struct mtk_ddp_data mt2712_ddp_driver_data = {
.mutex_mod = mt2712_mutex_mod,
+ .mutex_mod_reg = MT2701_DISP_MUTEX0_MOD0,
};
static const struct mtk_ddp_data mt8173_ddp_driver_data = {
.mutex_mod = mt8173_mutex_mod,
+ .mutex_mod_reg = MT2701_DISP_MUTEX0_MOD0,
};
static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
@@ -481,7 +487,8 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
break;
default:
if (ddp->data->mutex_mod[id] < 32) {
- offset = DISP_REG_MUTEX_MOD(mutex->id);
+ offset = DISP_REG_MUTEX_MOD(ddp->data->mutex_mod_reg,
+ mutex->id);
reg = readl_relaxed(ddp->regs + offset);
reg |= 1 << ddp->data->mutex_mod[id];
writel_relaxed(reg, ddp->regs + offset);
@@ -519,7 +526,8 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
*mutex,
break;
default:
if (ddp->data->mutex_mod[id] < 32) {
- offset = DISP_REG_MUTEX_MOD(mutex->id);
+ offset = DISP_REG_MUTEX_MOD(ddp->data->mutex_mod_reg,
+ mutex->id);
reg = readl_relaxed(ddp->regs + offset);
reg &= ~(1 << ddp->data->mutex_mod[id]);
writel_relaxed(reg, ddp->regs + offset);
--
1.8.1.1.dirty
[PATCH v4, 03/33] dt-bindings: mediatek: add ccorr description for mt8183 display
From: Yongqiang Niu Update device tree binding documention for the display subsystem for Mediatek MT8183 SOCs Signed-off-by: Yongqiang Niu --- Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index 8c4700f..cf5fb08 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -31,6 +31,7 @@ Required properties (all function blocks): "mediatek,-disp-ovl-2l" - overlay (2 layers, blending, csc) "mediatek,-disp-rdma" - read DMA / line buffer "mediatek,-disp-wdma" - write DMA + "mediatek,-disp-ccorr"- color correction "mediatek,-disp-color"- color processor "mediatek,-disp-aal" - adaptive ambient light controller "mediatek,-disp-gamma"- gamma correction -- 1.8.1.1.dirty
[PATCH v4, 33/33] drm/mediatek: add support for mediatek SOC MT8183
From: Yongqiang Niu
This patch add support for mediatek SOC MT8183
1.ovl_2l share driver with ovl
2.rdma1 share drive with rdma0, but fifo size is different
3.add mt8183 mutex private data, and mmsys private data
4.add mt8183 main and external path module for crtc create
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 +
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 12 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 69
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 ++
5 files changed, 147 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 7e99827..cd2b928 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -381,11 +381,29 @@ static int mtk_disp_ovl_remove(struct platform_device
*pdev)
.fmt_rgb565_is_0 = true,
};
+static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 10,
+ .layer_nr = 4,
+ .fmt_rgb565_is_0 = true,
+};
+
+static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 10,
+ .layer_nr = 2,
+ .fmt_rgb565_is_0 = true,
+};
+
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-ovl",
.data = _ovl_driver_data},
{ .compatible = "mediatek,mt8173-disp-ovl",
.data = _ovl_driver_data},
+ { .compatible = "mediatek,mt8183-disp-ovl",
+ .data = _ovl_driver_data},
+ { .compatible = "mediatek,mt8183-disp-ovl-2l",
+ .data = _ovl_2l_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index b0a5cff..5d62588 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -336,11 +336,23 @@ static int mtk_disp_rdma_remove(struct platform_device
*pdev)
.fifo_size = SZ_8K,
};
+static const struct mtk_disp_rdma_data mt8183_rdma_driver_data = {
+ .fifo_size = 5 * SZ_1K,
+};
+
+static const struct mtk_disp_rdma_data mt8183_rdma1_driver_data = {
+ .fifo_size = SZ_2K,
+};
+
static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-rdma",
.data = _rdma_driver_data},
{ .compatible = "mediatek,mt8173-disp-rdma",
.data = _rdma_driver_data},
+ { .compatible = "mediatek,mt8183-disp-rdma",
+ .data = _rdma_driver_data},
+ { .compatible = "mediatek,mt8183-disp-rdma1",
+ .data = _rdma1_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index c4d8ecb..b5bb794 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -41,19 +41,31 @@
#define DISP_REG_CONFIG_DSI_SEL0x050
#define DISP_REG_CONFIG_DPI_SEL0x064
+#define MT8183_DISP_OVL0_MOUT_EN 0xf00
#define MT8183_DISP_OVL0_2L_MOUT_EN0xf04
#define MT8183_DISP_OVL1_2L_MOUT_EN0xf08
#define MT8183_DISP_DITHER0_MOUT_EN0xf0c
#define MT8183_DISP_PATH0_SEL_IN 0xf24
+#define MT8183_DISP_DSI0_SEL_IN0xf2c
+#define MT8183_DISP_DPI0_SEL_IN0xf30
+#define MT8183_DISP_RDMA0_SOUT_SEL_IN 0xf50
+#define MT8183_DISP_RDMA1_SOUT_SEL_IN 0xf54
#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
#define DITHER0_MOUT_IN_DSI0 BIT(0)
#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
#define DSI0_SEL_IN_RDMA0 0x1
+#define MT8183_DSI0_SEL_IN_RDMA1 0x3
+#define MT8183_DPI0_SEL_IN_RDMA0 0x1
+#define MT8183_DPI0_SEL_IN_RDMA1 0x2
+#define MT8183_RDMA0_SOUT_COLOR0 0x1
+#define MT8183_RDMA1_SOUT_DSI0 0x1
#define MT2701_DISP_MUTEX0_MOD00x2c
#define MT2701_DISP_MUTEX0_SOF00x30
+#define MT8183_DISP_MUTEX0_MOD00x30
+#define MT8183_DISP_MUTEX0_SOF00x2c
#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
#define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
@@ -64,6 +76,18 @@
#define INT_MUTEX BIT(1)
+#define MT8183_MUTEX_MOD_DISP_RDMA00
+#define MT8183_MUTEX_MOD_DISP_RDMA11
+#define
[PATCH v4, 27/33] drm/mediatek: add connection from RDMA0 to COLOR0
From: Yongqiang Niu
This patch add connection from RDMA0 to COLOR0
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index fe4a458..c87bc4c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -439,6 +439,9 @@ static unsigned int mtk_ddp_sout_sel(const struct
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
*addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
value = RDMA2_SOUT_DSI3;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_COLOR0) {
+ *addr = data->rdma0_sout_sel_in;
+ value = data->rdma0_sout_color0;
} else {
value = 0;
}
--
1.8.1.1.dirty
[PATCH v4, 24/33] drm/mediatek: distinguish ovl and ovl_2l by layer_nr
From: Yongqiang Niu
distinguish ovl and ovl_2l by layer_nr when get comp
id
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8ca4965..7e99827 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -326,7 +326,12 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
if (irq < 0)
return irq;
- comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DISP_OVL);
+ priv->data = of_device_get_match_data(dev);
+
+ comp_id = mtk_ddp_comp_get_id(dev->of_node,
+ priv->data->layer_nr == 4 ?
+ MTK_DISP_OVL :
+ MTK_DISP_OVL_2L);
if (comp_id < 0) {
dev_err(dev, "Failed to identify by alias: %d\n", comp_id);
return comp_id;
@@ -339,8 +344,6 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
return ret;
}
- priv->data = of_device_get_match_data(dev);
-
platform_set_drvdata(pdev, priv);
ret = devm_request_irq(dev, irq, mtk_disp_ovl_irq_handler,
--
1.8.1.1.dirty
[PATCH v4, 22/33] drm/mediatek: add background color input select function for ovl/ovl_2l
From: Yongqiang Niu
This patch add background color input select function for ovl/ovl_2l
ovl include 4 DRAM layer and 1 background color layer
ovl_2l include 4 DRAM layer and 1 background color layer
DRAM layer frame buffer data from render hardware, GPU for example.
backgournd color layer is embed in ovl/ovl_2l, we can only set
it color, but not support DRAM frame buffer.
for ovl0->ovl0_2l direct link usecase,
we need set ovl0_2l background color intput select from ovl0
if render send DRAM buffer layer number <=4, all these layer read
by ovl.
layer0 is at the bottom of all layers.
layer3 is at the top of all layers.
if render send DRAM buffer layer numbfer >=4 && <=6
ovl0 read layer0~3
ovl0_2l read layer4~5
layer5 is at the top ot all these layers.
the decision of how to setting ovl0/ovl0_2l read these layer data
is controlled in mtk crtc, which will be another patch
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index a0ab760..8ca4965 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -27,6 +27,8 @@
#define DISP_REG_OVL_EN0x000c
#define DISP_REG_OVL_RST 0x0014
#define DISP_REG_OVL_ROI_SIZE 0x0020
+#define DISP_REG_OVL_DATAPATH_CON 0x0024
+#define OVL_BGCLR_SEL_IN BIT(2)
#define DISP_REG_OVL_ROI_BGCLR 0x0028
#define DISP_REG_OVL_SRC_CON 0x002c
#define DISP_REG_OVL_CON(n)(0x0030 + 0x20 * (n))
@@ -245,6 +247,24 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp
*comp, unsigned int idx,
mtk_ovl_layer_on(comp, idx);
}
+static void mtk_ovl_bgclr_in_on(struct mtk_ddp_comp *comp)
+{
+ unsigned int reg;
+
+ reg = readl(comp->regs + DISP_REG_OVL_DATAPATH_CON);
+ reg = reg | OVL_BGCLR_SEL_IN;
+ writel(reg, comp->regs + DISP_REG_OVL_DATAPATH_CON);
+}
+
+static void mtk_ovl_bgclr_in_off(struct mtk_ddp_comp *comp)
+{
+ unsigned int reg;
+
+ reg = readl(comp->regs + DISP_REG_OVL_DATAPATH_CON);
+ reg = reg & ~OVL_BGCLR_SEL_IN;
+ writel(reg, comp->regs + DISP_REG_OVL_DATAPATH_CON);
+}
+
static const struct mtk_ddp_comp_funcs mtk_disp_ovl_funcs = {
.config = mtk_ovl_config,
.start = mtk_ovl_start,
@@ -255,6 +275,8 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp,
unsigned int idx,
.layer_on = mtk_ovl_layer_on,
.layer_off = mtk_ovl_layer_off,
.layer_config = mtk_ovl_layer_config,
+ .bgclr_in_on = mtk_ovl_bgclr_in_on,
+ .bgclr_in_off = mtk_ovl_bgclr_in_off,
};
static int mtk_disp_ovl_bind(struct device *dev, struct device *master,
--
1.8.1.1.dirty
[PATCH v4, 21/33] drm/mediatek: add function to background color input select for ovl/ovl_2l direct link
From: Yongqiang Niu
This patch add function to background color input select for ovl/ovl_2l direct
link
for ovl/ovl_2l direct link usecase, we need set background color
input select for these hardware.
this is preparation patch for ovl/ovl_2l usecase
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index a0ea8c9..ec6f329a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -92,6 +92,8 @@ struct mtk_ddp_comp_funcs {
struct mtk_plane_state *state);
void (*gamma_set)(struct mtk_ddp_comp *comp,
struct drm_crtc_state *state);
+ void (*bgclr_in_on)(struct mtk_ddp_comp *comp);
+ void (*bgclr_in_off)(struct mtk_ddp_comp *comp);
};
struct mtk_ddp_comp {
@@ -172,6 +174,18 @@ static inline void mtk_ddp_gamma_set(struct mtk_ddp_comp
*comp,
comp->funcs->gamma_set(comp, state);
}
+static inline void mtk_ddp_comp_bgclr_in_on(struct mtk_ddp_comp *comp)
+{
+ if (comp->funcs && comp->funcs->bgclr_in_on)
+ comp->funcs->bgclr_in_on(comp);
+}
+
+static inline void mtk_ddp_comp_bgclr_in_off(struct mtk_ddp_comp *comp)
+{
+ if (comp->funcs && comp->funcs->bgclr_in_off)
+ comp->funcs->bgclr_in_off(comp);
+}
+
int mtk_ddp_comp_get_id(struct device_node *node,
enum mtk_ddp_comp_type comp_type);
int mtk_ddp_comp_init(struct device *dev, struct device_node *comp_node,
--
1.8.1.1.dirty
[PATCH v4, 28/33] drm/mediatek: add connection from RDMA1 to DSI0
From: Yongqiang Niu
This patch add connection from RDMA1 to DSI0
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index c87bc4c..fbea47f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -442,6 +442,9 @@ static unsigned int mtk_ddp_sout_sel(const struct
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_COLOR0) {
*addr = data->rdma0_sout_sel_in;
value = data->rdma0_sout_color0;
+ } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
+ *addr = data->rdma1_sout_sel_in;
+ value = data->rdma1_sout_dsi0;
} else {
value = 0;
}
--
1.8.1.1.dirty
[PATCH v4, 31/33] drm/mediatek: add connection from DITHER0 to DSI0
From: Yongqiang Niu
This patch add connection from DITHER0 to DSI0
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 4d75cef..c4c8531 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -43,10 +43,12 @@
#define MT8183_DISP_OVL0_2L_MOUT_EN0xf04
#define MT8183_DISP_OVL1_2L_MOUT_EN0xf08
+#define MT8183_DISP_DITHER0_MOUT_EN0xf0c
#define MT8183_DISP_PATH0_SEL_IN 0xf24
#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
+#define DITHER0_MOUT_IN_DSI0 BIT(0)
#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
#define MT2701_DISP_MUTEX0_MOD00x2c
@@ -331,6 +333,9 @@ static unsigned int mtk_ddp_mout_en(const struct
mtk_mmsys_reg_data *data,
next == DDP_COMPONENT_RDMA1) {
*addr = MT8183_DISP_OVL1_2L_MOUT_EN;
value = OVL1_2L_MOUT_EN_RDMA1;
+ } else if (cur == DDP_COMPONENT_DITHER && next == DDP_COMPONENT_DSI0) {
+ *addr = MT8183_DISP_DITHER0_MOUT_EN;
+ value = DITHER0_MOUT_IN_DSI0;
} else {
value = 0;
}
--
1.8.1.1.dirty
[PATCH v4, 19/33] drm/mediatek: add gmc_bits for ovl private data
From: Yongqiang Niu
This patch add gmc_bits for ovl private data
GMC register was set RDMA ultra and pre-ultra threshold.
10bit GMC register define is different with other SOC, gmc_thrshd_l not
used.
Signed-off-by: Yongqiang Niu
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 28d1911..afb313c 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -39,7 +39,9 @@
#define DISP_REG_OVL_ADDR_MT8173 0x0f40
#define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->addr + 0x20 * (n))
-#defineOVL_RDMA_MEM_GMC0x40402020
+#define GMC_THRESHOLD_BITS 16
+#define GMC_THRESHOLD_HIGH ((1 << GMC_THRESHOLD_BITS) / 4)
+#define GMC_THRESHOLD_LOW ((1 << GMC_THRESHOLD_BITS) / 8)
#define OVL_CON_BYTE_SWAP BIT(24)
#define OVL_CON_MTX_YUV_TO_RGB (6 << 16)
@@ -57,6 +59,7 @@
struct mtk_disp_ovl_data {
unsigned int addr;
+ unsigned int gmc_bits;
bool fmt_rgb565_is_0;
};
@@ -140,9 +143,23 @@ static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp
*comp)
static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx)
{
unsigned int reg;
+ unsigned int gmc_thrshd_l;
+ unsigned int gmc_thrshd_h;
+ unsigned int gmc_value;
+ struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
writel(0x1, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
- writel(OVL_RDMA_MEM_GMC, comp->regs + DISP_REG_OVL_RDMA_GMC(idx));
+
+ gmc_thrshd_l = GMC_THRESHOLD_LOW >>
+ (GMC_THRESHOLD_BITS - ovl->data->gmc_bits);
+ gmc_thrshd_h = GMC_THRESHOLD_HIGH >>
+ (GMC_THRESHOLD_BITS - ovl->data->gmc_bits);
+ if (ovl->data->gmc_bits == 10)
+ gmc_value = gmc_thrshd_h | gmc_thrshd_h << 16;
+ else
+ gmc_value = gmc_thrshd_l | gmc_thrshd_l << 8 |
+ gmc_thrshd_h << 16 | gmc_thrshd_h << 24;
+ writel(gmc_value, comp->regs + DISP_REG_OVL_RDMA_GMC(idx));
reg = readl(comp->regs + DISP_REG_OVL_SRC_CON);
reg = reg | BIT(idx);
@@ -324,11 +341,13 @@ static int mtk_disp_ovl_remove(struct platform_device
*pdev)
static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
.addr = DISP_REG_OVL_ADDR_MT2701,
+ .gmc_bits = 8,
.fmt_rgb565_is_0 = false,
};
static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
.addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 8,
.fmt_rgb565_is_0 = true,
};
--
1.8.1.1.dirty
[PATCH v4, 32/33] drm/mediatek: add connection from RDMA0 to DSI0
From: Yongqiang Niu
This patch add connection from RDMA0 to DSI0
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index c4c8531..c4d8ecb 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -50,6 +50,7 @@
#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
#define DITHER0_MOUT_IN_DSI0 BIT(0)
#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
+#define DSI0_SEL_IN_RDMA0 0x1
#define MT2701_DISP_MUTEX0_MOD00x2c
#define MT2701_DISP_MUTEX0_SOF00x30
@@ -399,6 +400,9 @@ static unsigned int mtk_ddp_sel_in(const struct
mtk_mmsys_reg_data *data,
next == DDP_COMPONENT_RDMA0) {
*addr = MT8183_DISP_PATH0_SEL_IN;
value = DISP_PATH0_SEL_IN_OVL0_2L;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI0) {
+ *addr = data->dsi0_sel_in;
+ value = DSI0_SEL_IN_RDMA0;
} else {
value = 0;
}
--
1.8.1.1.dirty
[PATCH v4, 30/33] drm/mediatek: add connection from OVL_2L1 to RDMA1
From: Yongqiang Niu
This patch add connection from OVL_2L1 to RDMA1
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 0a63dd0..4d75cef 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -42,9 +42,11 @@
#define DISP_REG_CONFIG_DPI_SEL0x064
#define MT8183_DISP_OVL0_2L_MOUT_EN0xf04
+#define MT8183_DISP_OVL1_2L_MOUT_EN0xf08
#define MT8183_DISP_PATH0_SEL_IN 0xf24
#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
+#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
#define MT2701_DISP_MUTEX0_MOD00x2c
@@ -325,6 +327,10 @@ static unsigned int mtk_ddp_mout_en(const struct
mtk_mmsys_reg_data *data,
next == DDP_COMPONENT_RDMA0) {
*addr = MT8183_DISP_OVL0_2L_MOUT_EN;
value = OVL0_2L_MOUT_EN_DISP_PATH0;
+ } else if (cur == DDP_COMPONENT_OVL_2L1 &&
+ next == DDP_COMPONENT_RDMA1) {
+ *addr = MT8183_DISP_OVL1_2L_MOUT_EN;
+ value = OVL1_2L_MOUT_EN_RDMA1;
} else {
value = 0;
}
--
1.8.1.1.dirty
[PATCH v4, 01/33] dt-bindings: mediatek: add binding for mt8183 display
From: Yongqiang Niu
Update device tree binding documention for the display subsystem for
Mediatek MT8183 SOCs
Signed-off-by: Yongqiang Niu
---
.../bindings/display/mediatek/mediatek,display.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt
new file mode 100644
index 000..951d2a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt
@@ -0,0 +1,21 @@
+Mediatek Display Device
+
+
+The Mediatek Display Device provides power control to the system.
+
+Required Properties:
+
+- compatible: Should be one of:
+ - "mediatek,mt8183-display"
+
+The Display Device power name are defined in
+include\dt-bindings\power\mt*-power.h
+
+
+Example:
+
+display_components: dispsys@1400 {
+ compatible = "mediatek,mt8183-display";
+ reg = <0 0x1400 0 0x1000>;
+ power-domains = < MT8183_POWER_DOMAIN_DISP>;
+};
\ No newline at end of file
--
1.8.1.1.dirty
[PATCH v4, 08/33] drm/mediatek: add mutex mod into ddp private data
From: Yongqiang Niu
except mutex mod, mutex mod reg,mutex sof reg,
and mutex sof id will be ddp private data
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 41 +-
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 579ce28..412b82f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -147,12 +147,16 @@ struct mtk_disp_mutex {
bool claimed;
};
+struct mtk_ddp_data {
+ const unsigned int *mutex_mod;
+};
+
struct mtk_ddp {
struct device *dev;
struct clk *clk;
void __iomem*regs;
struct mtk_disp_mutex mutex[10];
- const unsigned int *mutex_mod;
+ const struct mtk_ddp_data *data;
};
static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
@@ -202,6 +206,18 @@ struct mtk_ddp {
[DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
};
+static const struct mtk_ddp_data mt2701_ddp_driver_data = {
+ .mutex_mod = mt2701_mutex_mod,
+};
+
+static const struct mtk_ddp_data mt2712_ddp_driver_data = {
+ .mutex_mod = mt2712_mutex_mod,
+};
+
+static const struct mtk_ddp_data mt8173_ddp_driver_data = {
+ .mutex_mod = mt8173_mutex_mod,
+};
+
static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next,
unsigned int *addr)
@@ -464,15 +480,15 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
reg = MUTEX_SOF_DPI1;
break;
default:
- if (ddp->mutex_mod[id] < 32) {
+ if (ddp->data->mutex_mod[id] < 32) {
offset = DISP_REG_MUTEX_MOD(mutex->id);
reg = readl_relaxed(ddp->regs + offset);
- reg |= 1 << ddp->mutex_mod[id];
+ reg |= 1 << ddp->data->mutex_mod[id];
writel_relaxed(reg, ddp->regs + offset);
} else {
offset = DISP_REG_MUTEX_MOD2(mutex->id);
reg = readl_relaxed(ddp->regs + offset);
- reg |= 1 << (ddp->mutex_mod[id] - 32);
+ reg |= 1 << (ddp->data->mutex_mod[id] - 32);
writel_relaxed(reg, ddp->regs + offset);
}
return;
@@ -502,15 +518,15 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
*mutex,
ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
break;
default:
- if (ddp->mutex_mod[id] < 32) {
+ if (ddp->data->mutex_mod[id] < 32) {
offset = DISP_REG_MUTEX_MOD(mutex->id);
reg = readl_relaxed(ddp->regs + offset);
- reg &= ~(1 << ddp->mutex_mod[id]);
+ reg &= ~(1 << ddp->data->mutex_mod[id]);
writel_relaxed(reg, ddp->regs + offset);
} else {
offset = DISP_REG_MUTEX_MOD2(mutex->id);
reg = readl_relaxed(ddp->regs + offset);
- reg &= ~(1 << (ddp->mutex_mod[id] - 32));
+ reg &= ~(1 << (ddp->data->mutex_mod[id] - 32));
writel_relaxed(reg, ddp->regs + offset);
}
break;
@@ -585,7 +601,7 @@ static int mtk_ddp_probe(struct platform_device *pdev)
return PTR_ERR(ddp->regs);
}
- ddp->mutex_mod = of_device_get_match_data(dev);
+ ddp->data = of_device_get_match_data(dev);
platform_set_drvdata(pdev, ddp);
@@ -598,9 +614,12 @@ static int mtk_ddp_remove(struct platform_device *pdev)
}
static const struct of_device_id ddp_driver_dt_match[] = {
- { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
- { .compatible = "mediatek,mt2712-disp-mutex", .data = mt2712_mutex_mod},
- { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
+ { .compatible = "mediatek,mt2701-disp-mutex",
+ .data = _ddp_driver_data},
+ { .compatible = "mediatek,mt2712-disp-mutex",
+ .data = _ddp_driver_data},
+ { .compatible = "mediatek,mt8173-disp-mutex",
+ .data = _ddp_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, ddp_driver_dt_match);
--
1.8.1.1.dirty
[PATCH v4, 05/33] dt-bindings: mediatek: add RDMA1 description for mt8183 display
From: Yongqiang Niu This patch add RDMA1 description for mt8183 display Signed-off-by: Yongqiang Niu --- Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index afd3c90..bb9274a 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -30,6 +30,7 @@ Required properties (all function blocks): "mediatek,-disp-ovl" - overlay (4 layers, blending, csc) "mediatek,-disp-ovl-2l" - overlay (2 layers, blending, csc) "mediatek,-disp-rdma" - read DMA / line buffer + "mediatek,-disp-rdma1"- function is same with RDMA, fifo size is different "mediatek,-disp-wdma" - write DMA "mediatek,-disp-ccorr"- color correction "mediatek,-disp-color"- color processor -- 1.8.1.1.dirty
[PATCH v4, 12/33] drm/mediatek: split DISP_REG_CONFIG_DSI_SEL setting into another use case
From: Yongqiang Niu
Here is two modifition in this patch:
1.bls->dpi0 and rdma1->dsi are differen usecase,
Split DISP_REG_CONFIG_DSI_SEL setting into anther usecase
2.remove DISP_REG_CONFIG_DPI_SEL setting, DPI_SEL_IN_BLS is 0 and
this is same with hardware defautl setting,
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index d015c1a..47b3e35 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -400,10 +400,9 @@ static void mtk_ddp_sout_sel(void __iomem *config_regs,
} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
config_regs + DISP_REG_CONFIG_OUT_SEL);
+ } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
writel_relaxed(DSI_SEL_IN_RDMA,
config_regs + DISP_REG_CONFIG_DSI_SEL);
- writel_relaxed(DPI_SEL_IN_BLS,
- config_regs + DISP_REG_CONFIG_DPI_SEL);
}
}
--
1.8.1.1.dirty
[PATCH v4, 00/33] add drm support for MT8183
From: Yongqiang Niu This series are based on 5.2-rc1 and provid 27 patch to support mediatek SOC MT8183 Change since v3 - fix reviewed issue in v3 - fix type error in v3 - fix conflict with iommu patch Yongqiang Niu (33): dt-bindings: mediatek: add binding for mt8183 display dt-bindings: mediatek: add ovl_2l description for mt8183 display dt-bindings: mediatek: add ccorr description for mt8183 display dt-bindings: mediatek: add dither description for mt8183 display dt-bindings: mediatek: add RDMA1 description for mt8183 display dt-bindings: mediatek: add mutex description for mt8183 display arm64: dts: add display nodes for mt8183 drm/mediatek: add mutex mod into ddp private data drm/mediatek: add mutex mod register offset into ddp private data drm/mediatek: add mutex sof into ddp private data drm/mediatek: add mutex sof register offset into ddp private data drm/mediatek: split DISP_REG_CONFIG_DSI_SEL setting into another use case drm/mediatek: add mmsys private data for ddp path config drm/mediatek: move rdma sout from mtk_ddp_mout_en into mtk_ddp_sout_sel drm/mediatek: add ddp component CCORR drm/mediatek: add commponent OVL_2L0 drm/mediatek: add component OVL_2L1 drm/mediatek: add component DITHER drm/mediatek: add gmc_bits for ovl private data drm/medaitek: add layer_nr for ovl private data drm/mediatek: add function to background color input select for ovl/ovl_2l direct link drm/mediatek: add background color input select function for ovl/ovl_2l drm/mediatek: add ovl0/ovl_2l0 usecase drm/mediatek: distinguish ovl and ovl_2l by layer_nr drm/mediatek: add clock property check before get it drm/mediatek: add connection from OVL0 to OVL_2L0 drm/mediatek: add connection from RDMA0 to COLOR0 drm/mediatek: add connection from RDMA1 to DSI0 drm/mediatek: add connection from OVL_2L0 to RDMA0 drm/mediatek: add connection from OVL_2L1 to RDMA1 drm/mediatek: add connection from DITHER0 to DSI0 drm/mediatek: add connection from RDMA0 to DSI0 drm/mediatek: add support for mediatek SOC MT8183 .../bindings/display/mediatek/mediatek,disp.txt| 31 +- .../bindings/display/mediatek/mediatek,display.txt | 21 ++ arch/arm64/boot/dts/mediatek/mt8183.dtsi | 109 ++ drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 79 +++- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 12 + drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 42 ++- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 410 - drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 6 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 67 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 21 ++ drivers/gpu/drm/mediatek/mtk_drm_drv.c | 50 +++ drivers/gpu/drm/mediatek/mtk_drm_drv.h | 3 + 12 files changed, 730 insertions(+), 121 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt -- 1.8.1.1.dirty
Re: [PATCH v6 01/18] kunit: test: add KUnit test runner core
On Mon, Jul 8, 2019 at 11:08 AM Brendan Higgins wrote: > > On Fri, Jul 5, 2019 at 1:15 PM Luis Chamberlain wrote: > > > > On Wed, Jul 03, 2019 at 05:35:58PM -0700, Brendan Higgins wrote: > > > Add core facilities for defining unit tests; this provides a common way > > > to define test cases, functions that execute code which is under test > > > and determine whether the code under test behaves as expected; this also > > > provides a way to group together related test cases in test suites (here > > > we call them test_modules). > > > > > > Just define test cases and how to execute them for now; setting > > > expectations on code will be defined later. > > > > > > Signed-off-by: Brendan Higgins > > > Reviewed-by: Greg Kroah-Hartman > > > Reviewed-by: Logan Gunthorpe > > > > Reviewed-by: Luis Chamberlain > > > > But a nitpick below, I think that can be fixed later with a follow up > > patch. > > > > > +/** > > > + * struct kunit - represents a running instance of a test. > > > + * @priv: for user to store arbitrary data. Commonly used to pass data > > > created > > > + * in the init function (see kunit_suite). > > > + * > > > + * Used to store information about the current context under which the > > > test is > > > + * running. Most of this data is private and should only be accessed > > > indirectly > > > + * via public functions; the one exception is @priv which can be used by > > > the > > > + * test writer to store arbitrary data. > > > + * > > > + * A brief note on locking: > > > + * > > > + * First off, we need to lock because in certain cases a user may want > > > to use an > > > + * expectation in a thread other than the thread that the test case is > > > running > > > + * in. > > > > This as a prefix to the struct without a lock seems odd. It would be > > clearer I think if you'd explain here what locking mechanism we decided > > to use and why it suffices today. > > Whoops, sorry this should have been in the next patch. Will fix. Err..no, this shouldn't be here at all. Sorry about that. I just need to rewrite the comment. > > > +/** > > > + * suite_test() - used to register a kunit_suite with KUnit. > > > > You mean kunit_test_suite()? > > Yep, sorry about that. Will fix. > > > > + * @suite: a statically allocated kunit_suite. > > > + * > > > + * Registers @suite with the test framework. See kunit_suite for > > > more > > > + * information. > > > + * > > > + * NOTE: Currently KUnit tests are all run as late_initcalls; this means > > > that > > > + * they cannot test anything where tests must run at a different init > > > phase. One > > > + * significant restriction resulting from this is that KUnit cannot > > > reliably > > > + * test anything that is initialize in the late_init phase. > > initialize prior to the late init phase. > > > > > > That is, this is useless to test things running early. > > Yeah, I can add that phrasing in. > > > > + * > > > + * TODO(brendanhigg...@google.com): Don't run all KUnit tests as > > > late_initcalls. > > > + * I have some future work planned to dispatch all KUnit tests from the > > > same > > > + * place, and at the very least to do so after everything else is > > > definitely > > > + * initialized. > > > > TODOs are odd to be adding to documentation, this is just not common > > place practice. The NOTE should suffice for you. > > Because it is a kernel doc? Would you usually make a separate > non-kernel doc comment for a TODO? I guess that makes sense. > > Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/amdgpu/mes10.1: Fix header guard
On Thu, Jul 4, 2019 at 7:52 AM Nathan Chancellor
wrote:
>
> clang warns:
>
> In file included from drivers/gpu/drm/amd/amdgpu/nv.c:53:
> drivers/gpu/drm/amd/amdgpu/../amdgpu/mes_v10_1.h:24:9: warning:
> '__MES_V10_1_H__' is used as a header guard here, followed by #define of
> a different macro [-Wheader-guard]
> #ifndef __MES_V10_1_H__
> ^~~
> drivers/gpu/drm/amd/amdgpu/../amdgpu/mes_v10_1.h:25:9: note:
> '__MES_v10_1_H__' is defined here; did you mean '__MES_V10_1_H__'?
> #define __MES_v10_1_H__
> ^~~
> __MES_V10_1_H__
> 1 warning generated.
>
> Capitalize the V.
>
> Fixes: 886f82aa7a1d ("drm/amdgpu/mes10.1: add ip block mes10.1 (v2)")
> Link: https://github.com/ClangBuiltLinux/linux/issues/582
> Signed-off-by: Nathan Chancellor
I ran into the same one now, and saw your version before sending an
identical patch.
Acked-by: Arnd Bergmann
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu/drm_memory: fix a few warnings
On Mon, 8 Jul 2019, Qian Cai wrote: > On Mon, 2019-07-08 at 15:21 -0400, Ilia Mirkin wrote: > > > -/** > > > +// SPDX-License-Identifier: MIT > > > +/* > > > * \file drm_memory.c > > > * Memory management wrappers for DRM > > > * > > > @@ -12,25 +13,6 @@ > > > * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. > > > * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. > > > * All Rights Reserved. > > > - * > > > - * 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 (including the > > > next > > > - * paragraph) 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 > > > - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES > > > OR > > > > This talks about VA Linux Systems and/or its suppliers, while the MIT > > licence talks about authors or copyright holders. That's looks lika a valid substitution and does not change the meaning of the license, AFAICT. Richard might have a differnt opinion though. > > Are such transformations OK to just do? Nope. > From, > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Document > ation/process/license-rules.rst > > "The Linux kernel requires the precise SPDX identifier in all source files." That's correct. > That is the closest license I can think of. Well, it's pretty much plain MIT, but you might have noticed: * The above copyright notice and this permission notice (including the next * paragraph) shall be included in all copies or substantial portions of the * Software. So in this case, you need to talk to the copyright holder if he agrees to remove the boiler plate language. Adding the MIT SPDX identifier without touching the boiler plate is fine. Thanks, tglx
Re: [PATCH 21/60] drm/panel: Add driver for the Sharp LS037V7DW01 panel
Hi Laurent.
> > +
> > +MODULE_DEVICE_TABLE(of, ls037v7dw01_of_match);
> > +
> > +static struct platform_driver ls037v7dw01_driver = {
> > + .probe = ls037v7dw01_probe,
> > + .remove = __exit_p(ls037v7dw01_remove),
I hope _exit_p() is not needed.
No other panel drivers use it as far as I could see.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/60] drm/panel: Add driver for the Sharp LS037V7DW01 panel
Hi Laurent.
Third panel driver in line for review.
Review comments that are duplicates from the first two will have only a
brief remark - if any.
On Sun, Jul 07, 2019 at 09:18:58PM +0300, Laurent Pinchart wrote:
> This panel is used on the SDP3430.
Add a little more context and put it in Kconfig help.
Maybe this is the TI board, and maybe it is something else.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/panel/Kconfig | 7 +
> drivers/gpu/drm/panel/Makefile| 1 +
> .../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 231 ++
> 3 files changed, 239 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index da613c04b835..04fd152efe4c 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -271,6 +271,13 @@ config DRM_PANEL_SHARP_LS043T1LE01
> Say Y here if you want to enable support for Sharp LS043T1LE01 qHD
> (540x960) DSI panel as found on the Qualcomm APQ8074 Dragonboard
>
> +config DRM_PANEL_SHARP_LS037V7DW01
> + tristate "Sharp LS037V7DW01 VGA LCD panel"
> + depends on GPIOLIB && OF && REGULATOR
> + help
> + Say Y here if you want to enable support for Sharp LS037V7DW01 VGA
> + (480x640) LCD panel.
> +
Alphabetical order, so it comes before DRM_PANEL_SHARP_LS043T1LE01
> config DRM_PANEL_SITRONIX_ST7701
> tristate "Sitronix ST7701 panel driver"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index e81ed1535024..12dcd76eb87c 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63M0) +=
> panel-samsung-s6e63m0.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
> obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> +obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
And here it is right.
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> @@ -0,0 +1,231 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Sharp LS037V7DW01 LCD Panel Driver
> + *
> + * Copyright (C) 2019 Texas Instruments Incorporated
> + *
> + * Based on the omapdrm-specific panel-sharp-ls037v7dw01 driver
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated
> + * Author: Tomi Valkeinen
Add your copyright?
> +struct ls037v7dw01_device {
> + struct drm_panel panel;
> + struct platform_device *pdev;
> +
> + struct regulator *vcc;
The property is named envdd - should they use the same name?
> + struct gpio_desc *resb_gpio;/* low = reset active min 20 us */
> + struct gpio_desc *ini_gpio; /* high = power on */
> + struct gpio_desc *mo_gpio; /* low = 480x640, high = 240x320 */
> + struct gpio_desc *lr_gpio; /* high = conventional horizontal
> scanning */
> + struct gpio_desc *ud_gpio; /* high = conventional vertical
> scanning */
> +};
device versus panel, but bikeshedding, so feel free to ignore.
> +
> +static int ls037v7dw01_disable(struct drm_panel *panel)
> +{
> + struct ls037v7dw01_device *lcd = to_ls037v7dw01_device(panel);
> +
> + gpiod_set_value_cansleep(lcd->ini_gpio, 0);
> + gpiod_set_value_cansleep(lcd->resb_gpio, 0);
> +
> + /* Wait at least 5 vsyncs after disabling the LCD. */
> + msleep(100);
> +
> + return 0;
> +}
> +
> +static int ls037v7dw01_unprepare(struct drm_panel *panel)
> +{
> + struct ls037v7dw01_device *lcd = to_ls037v7dw01_device(panel);
> +
> + if (lcd->vcc)
> + regulator_disable(lcd->vcc);
Why is the if (lcd-vcc) needed?
If I read the probe code correct then we either get a regulator or we
error out.
Same goes for all other checks of lcd->vcc
> +static const struct drm_display_mode ls037v7dw01_mode = {
> + .clock = 19200,
> + .hdisplay = 480,
> + .hsync_start = 480 + 1,
> + .hsync_end = 480 + 1 + 2,
> + .htotal = 480 + 1 + 2 + 28,
> + .vdisplay = 640,
> + .vsync_start = 640 + 1,
> + .vsync_end = 640 + 1 + 1,
> + .vtotal = 640 + 1 + 1 + 1,
> + .vrefresh = 58,
> + .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> +};
> +
> +static int ls037v7dw01_get_modes(struct drm_panel *panel)
> +{
> + struct drm_connector *connector = panel->connector;
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(panel->drm, _mode);
> + if (!mode)
> + return -ENOMEM;
> +
> + drm_mode_set_name(mode);
> + drm_mode_probed_add(connector, mode);
> +
> + connector->display_info.width_mm = 56;
> + connector->display_info.height_mm = 75;
> +
Re: [PATCH v2] gpu/drm_memory: fix a few warnings
On Mon, 2019-07-08 at 15:21 -0400, Ilia Mirkin wrote: > On Mon, Jul 8, 2019 at 2:06 PM Qian Cai wrote: > > > > The opening comment mark "/**" is reserved for kernel-doc comments, so > > it will generate a warning with "make W=1". > > > > drivers/gpu/drm/drm_memory.c:2: warning: Cannot understand * \file > > drm_memory.c > > > > Also, silence a checkpatch warning by adding a license identfiter where > > it indicates the MIT license further down in the source file. > > > > WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 > > > > It becomes redundant to add both an SPDX identifier and have a > > description of the license in the comment block at the top, so remove > > the later. > > > > Signed-off-by: Qian Cai > > --- > > > > v2: remove the redundant description of the license. > > > > drivers/gpu/drm/drm_memory.c | 22 ++ > > 1 file changed, 2 insertions(+), 20 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c > > index 132fef8ff1b6..86a11fc8e954 100644 > > --- a/drivers/gpu/drm/drm_memory.c > > +++ b/drivers/gpu/drm/drm_memory.c > > @@ -1,4 +1,5 @@ > > -/** > > +// SPDX-License-Identifier: MIT > > +/* > > * \file drm_memory.c > > * Memory management wrappers for DRM > > * > > @@ -12,25 +13,6 @@ > > * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. > > * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. > > * All Rights Reserved. > > - * > > - * 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 (including the > > next > > - * paragraph) 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 > > - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES > > OR > > This talks about VA Linux Systems and/or its suppliers, while the MIT > licence talks about authors or copyright holders. > > Are such transformations OK to just do? From, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Document ation/process/license-rules.rst "The Linux kernel requires the precise SPDX identifier in all source files." That is the closest license I can think of. Anyway, I have added a few people who may know better of the licensing. > > -ilia > > > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > > - * OTHER DEALINGS IN THE SOFTWARE. > > */ > > > > #include > > -- > > 1.8.3.1 > >
Re: [PATCH 20/60] drm/panel: Add driver for the NEC NL8048HL11 panel
Hi Laurent. > > Use __maybe_unused, and loose the #ifdef > And why does this panel need suspend/resume? > The panel is supposed to be turned off in disable() Sorry - the panel is supposed to be turned off in unprepare. disable() is mainly for backlight and such. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu/drm_memory: fix a few warnings
On Mon, Jul 8, 2019 at 2:06 PM Qian Cai wrote: > > The opening comment mark "/**" is reserved for kernel-doc comments, so > it will generate a warning with "make W=1". > > drivers/gpu/drm/drm_memory.c:2: warning: Cannot understand * \file > drm_memory.c > > Also, silence a checkpatch warning by adding a license identfiter where > it indicates the MIT license further down in the source file. > > WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 > > It becomes redundant to add both an SPDX identifier and have a > description of the license in the comment block at the top, so remove > the later. > > Signed-off-by: Qian Cai > --- > > v2: remove the redundant description of the license. > > drivers/gpu/drm/drm_memory.c | 22 ++ > 1 file changed, 2 insertions(+), 20 deletions(-) > > diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c > index 132fef8ff1b6..86a11fc8e954 100644 > --- a/drivers/gpu/drm/drm_memory.c > +++ b/drivers/gpu/drm/drm_memory.c > @@ -1,4 +1,5 @@ > -/** > +// SPDX-License-Identifier: MIT > +/* > * \file drm_memory.c > * Memory management wrappers for DRM > * > @@ -12,25 +13,6 @@ > * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. > * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. > * All Rights Reserved. > - * > - * 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 (including the next > - * paragraph) 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 > - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR This talks about VA Linux Systems and/or its suppliers, while the MIT licence talks about authors or copyright holders. Are such transformations OK to just do? -ilia > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > - * OTHER DEALINGS IN THE SOFTWARE. > */ > > #include > -- > 1.8.3.1 >
[Bug 111082] Severe stutter in CS:GO surf servers, despite ~300fps
https://bugs.freedesktop.org/show_bug.cgi?id=111082 --- Comment #7 from Sylvain BERTRAND --- > My CPU load is also super low and never above 50 % on a single > core. This is the issue: looks like cpu capping in the 3d engine. But, since csgo 3d engine is direct3d designed, this is why vulkan. linux csgo devs are the ones who can profile properly their game and figure out the culprit. (could be linux networking related too). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 111082] Severe stutter in CS:GO surf servers, despite ~300fps
> My CPU load is also super low and never above 50 % on a single > core. This is the issue: looks like cpu capping in the 3d engine. But, since csgo 3d engine is direct3d designed, this is why vulkan. linux csgo devs are the ones who can profile properly their game and figure out the culprit. (could be linux networking related too). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 20/60] drm/panel: Add driver for the NEC NL8048HL11 panel
Hi Laurent.
Thanks for keeping me busy :-)
On Sun, Jul 07, 2019 at 09:18:57PM +0300, Laurent Pinchart wrote:
> This panel is used on the Zoom2/3/3630 SDP boards.
This information may be good to have in the Kconfig help entry too.
Maybe tell in the changelog where this code originates from.
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
> @@ -0,0 +1,249 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * NEC NL8048HL11 Panel Driver
> + *
> + * Copyright (C) 2019 Texas Instruments Incorporated
> + *
> + * Based on the omapdrm-specific panel-nec-nl8048hl11 driver
> + *
> + * Copyright (C) 2010 Texas Instruments Incorporated
> + * Author: Erik Gilling
> + */
No added copyright from you?
(Apply to all panel drivers)
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
Good to see panel drivers that are NOT using drmP.h :-)
> +
> +struct nl8048_device {
> + struct drm_panel panel;
> +
> + struct spi_device *spi;
> + struct gpio_desc *reset_gpio;
> +};
Naming bikeshedding. This is a nl8048_panel, not a device.
> +
> +static const struct drm_display_mode nl8048_mode = {
> + /* NEC PIX Clock Ratings MIN:21.8MHz TYP:23.8MHz MAX:25.7MHz */
> + .clock = 23800,
> + .hdisplay = 800,
> + .hsync_start = 800 + 6,
> + .hsync_end = 800 + 6 + 1,
> + .htotal = 800 + 6 + 1 + 4,
> + .vdisplay = 480,
> + .vsync_start = 480 + 3,
> + .vsync_end = 480 + 3 + 1,
> + .vtotal = 480 + 3 + 1 + 4,
> + .vrefresh = 60,
> + .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> +};
Same comment as for previous patch on height/width.
> +
> +static int nl8048_get_modes(struct drm_panel *panel)
> +{
> + struct drm_connector *connector = panel->connector;
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(panel->drm, _mode);
> + if (!mode)
> + return -ENOMEM;
> +
> + drm_mode_set_name(mode);
> + drm_mode_probed_add(connector, mode);
> +
> + connector->display_info.width_mm = 89;
> + connector->display_info.height_mm = 53;
> + connector->display_info.bus_flags = DRM_BUS_FLAG_DE_HIGH
> + | DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE
> + | DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE;
> +
> + return 1;
> +}
This should be moved to drm_panle_helper.c (which we do not have yet.
But the function is used in some many drivers it makes sense.
On my TODO list.
I have yet to find a good way to specify the bus_flags though.
> +#ifdef CONFIG_PM_SLEEP
Use __maybe_unused, and loose the #ifdef
And why does this panel need suspend/resume?
The panel is supposed to be turned off in disable()
To simple solution would be to move the write to "2" to
the enable and disable functions.
And then this driver is alinged with the rest.
> +static int nl8048_suspend(struct device *dev)
> +{
> + struct nl8048_device *lcd = dev_get_drvdata(dev);
> +
> + nl8048_write(lcd, 2, 0x01);
> + msleep(40);
This sleep puzzle me. What is the puspose?
And the write is to a display that is already reset??
> +
> + return 0;
> +}
> +
> +static int nl8048_resume(struct device *dev)
> +{
> + struct nl8048_device *lcd = dev_get_drvdata(dev);
> +
> + /* Reinitialize the panel. */
> + spi_setup(lcd->spi);
> + nl8048_write(lcd, 2, 0x00);
> + nl8048_init(lcd);
> +
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(nl8048_pm_ops, nl8048_suspend, nl8048_resume);
> +#endif
> +
> +static int nl8048_probe(struct spi_device *spi)
> +{
> + struct nl8048_device *lcd;
> + int ret;
> +
> + lcd = devm_kzalloc(>dev, sizeof(*lcd), GFP_KERNEL);
> + if (lcd == NULL)
> + return -ENOMEM;
> +
> + spi_set_drvdata(spi, lcd);
> + lcd->spi = spi;
> +
> + lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(lcd->reset_gpio)) {
> + dev_err(>dev, "failed to parse reset gpio\n");
> + return PTR_ERR(lcd->reset_gpio);
> + }
> +
> + spi->mode = SPI_MODE_0;
> + spi->bits_per_word = 32;
> +
> + ret = spi_setup(spi);
> + if (ret < 0) {
> + dev_err(>dev, "failed to setup SPI: %d\n", ret);
> + return ret;
> + }
> +
> + ret = nl8048_init(lcd);
> + if (ret < 0)
> + return ret;
> +
> + drm_panel_init(>panel);
> + lcd->panel.dev = >spi->dev;
> + lcd->panel.funcs = _funcs;
> +
> + return drm_panel_add(>panel);
> +}
> +
> +static int nl8048_remove(struct spi_device *spi)
> +{
> + struct nl8048_device *lcd = spi_get_drvdata(spi);
> +
> + drm_panel_remove(>panel);
> + nl8048_disable(>panel);
Use drm_panel_disable() - same comment as other panel driver.
> +
> + return 0;
> +}
> +
> +static const struct of_device_id nl8048_of_match[] = {
> + { .compatible =
Re: [PATCH 17/60] dt-bindings: Add legacy 'toppoly' vendor prefix
On Sun, Jul 7, 2019 at 12:25 PM Laurent Pinchart wrote: > > The 'toppoly' vendor prefix is in use and refers to TPO, whose DT vendor > prefix is already defined as 'tpo'. Add 'toppoly' as an alternative and > document it as legacy. > > Signed-off-by: Laurent Pinchart > --- > 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 2514463f2c63..d78527eb8254 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -867,6 +867,8 @@ patternProperties: > description: Tecon Microprocessor Technologies, LLC. >"^topeet,.*": > description: Topeet > + "^toppoly,.*": > +description: TPO (legacy prefix, see 'tpo') Add 'deprecated: true' also. That's a new property in json-schema draft8. It's not used for anything yet other than documentation. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 19/60] drm/panel: Add driver for the LG Philips LB035Q02 panel
Hi Laurent.
Good to move omapdrm to a more standard way to do things.
> new file mode 100644
> index ..d8a8c3a3a8c5
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-lg-lb035q02.c
> @@ -0,0 +1,235 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * LG.Philips LB035Q02 LCD Panel Driver
Looks like a typo. As far as I know LG and Philips are not the same.
But I can see this is used in several places, so I need to check up on
actual status here and driver is likely OK.
Google... this is fine. Some joint venture in 2001.
> + * Based on the omapdrm-specific panel-lg-lb035q02 driver
Will we have two drivers with the same name, or are this above already
disabled from the build?
> + unsigned int i;
index to arrays are default "int" IIRC.
Not that it matters but noticed it.
> + int ret;
> +
> + for (i = 0; i < ARRAY_SIZE(init_data); ++i) {
> + ret = lb035q02_write(lcd, init_data[i].index,
> + init_data[i].value);
> + if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static const struct drm_display_mode lb035q02_mode = {
> + .clock = 6500,
> + .hdisplay = 320,
> + .hsync_start = 320 + 20,
> + .hsync_end = 320 + 20 + 2,
> + .htotal = 320 + 20 + 2 + 68,
> + .vdisplay = 240,
> + .vsync_start = 240 + 4,
> + .vsync_end = 240 + 4 + 2,
> + .vtotal = 240 + 4 + 2 + 18,
> + .vrefresh = 60,
> + .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> +};
We already specify all the timing details.
Consider to use display_mode to specify the width/height too.
So the panel specificatiosn are hardcoded only in one place.
> +
> +static int lb035q02_get_modes(struct drm_panel *panel)
> +{
> + struct drm_connector *connector = panel->connector;
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(panel->drm, _mode);
> + if (!mode)
> + return -ENOMEM;
> +
> + drm_mode_set_name(mode);
> + drm_mode_probed_add(connector, mode);
> +
> + connector->display_info.width_mm = 70;
> + connector->display_info.height_mm = 53;
So we avoid hardcoding height/width here, but do it with the timing
above.
> + /*
> + * FIXME: According to the datasheet pixel data is sampled on the
> + * rising edge of the clock, but the code running on the Gumstix Overo
> + * Palo35 indicates sampling on the negative edge. This should be
> + * tested on a real device.
> + */
> + connector->display_info.bus_flags = DRM_BUS_FLAG_DE_HIGH
> + | DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE
> + | DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE;
> +
> + return 1;
> +}
> +
> +static const struct drm_panel_funcs lb035q02_funcs = {
> + .disable = lb035q02_disable,
> + .enable = lb035q02_enable,
> + .get_modes = lb035q02_get_modes,
> +};
> +
> +static int lb035q02_probe(struct spi_device *spi)
> +{
> + struct lb035q02_device *lcd;
> + int ret;
> +
> + lcd = devm_kzalloc(>dev, sizeof(*lcd), GFP_KERNEL);
> + if (lcd == NULL)
> + return -ENOMEM;
> +
> + spi_set_drvdata(spi, lcd);
> + lcd->spi = spi;
> +
> + lcd->enable_gpio = devm_gpiod_get(>dev, "enable", GPIOD_OUT_LOW);
> + if (IS_ERR(lcd->enable_gpio)) {
> + dev_err(>dev, "failed to parse enable gpio\n");
> + return PTR_ERR(lcd->enable_gpio);
> + }
> +
> + ret = lb035q02_init(lcd);
> + if (ret < 0)
> + return ret;
> +
> + drm_panel_init(>panel);
> + lcd->panel.dev = >spi->dev;
> + lcd->panel.funcs = _funcs;
> +
> + return drm_panel_add(>panel);
> +}
> +
> +static int lb035q02_remove(struct spi_device *spi)
> +{
> + struct lb035q02_device *lcd = spi_get_drvdata(spi);
> +
> + drm_panel_remove(>panel);
> + lb035q02_disable(>panel);
Use drm_panel_disable() so the driver will benefit when we move more
functionality to the drm_panel_disable() function.
> +
> + return 0;
> +}
> +
> +static const struct of_device_id lb035q02_of_match[] = {
> + { .compatible = "lgphilips,lb035q02", },
> + {},
Some drivers use { /* sentinel */ }, to document this is on purpose the
last entry.
> +};
> +
> +MODULE_DEVICE_TABLE(of, lb035q02_of_match);
> +
> +static struct spi_driver lb035q02_driver = {
> + .probe = lb035q02_probe,
> + .remove = lb035q02_remove,
> + .driver = {
> + .name = "panel-lg-lb035q02",
> + .of_match_table = lb035q02_of_match,
> + },
> +};
> +
> +module_spi_driver(lb035q02_driver);
> +
> +MODULE_ALIAS("spi:lgphilips,lb035q02");
> +MODULE_AUTHOR("Tomi Valkeinen ");
> +MODULE_DESCRIPTION("LG.Philips LB035Q02 LCD Panel driver");
> +MODULE_LICENSE("GPL");
This should be "GPL v2" if I read
Re: use exact allocation for dma coherent memory
On Tue, Jul 02, 2019 at 11:48:44AM +0200, Arend Van Spriel wrote: > You made me look ;-) Actually not touching my drivers so I'm off the hook. > However, I was wondering if drivers could know so I decided to look into > the DMA-API.txt documentation which currently states: > > """ > The flag parameter (dma_alloc_coherent() only) allows the caller to > specify the ``GFP_`` flags (see kmalloc()) for the allocation (the > implementation may choose to ignore flags that affect the location of > the returned memory, like GFP_DMA). > """ > > I do expect you are going to change that description as well now that you > are going to issue a warning on __GFP_COMP. Maybe include that in patch > 15/16 where you introduce that warning. Yes, that description needs an updated, even without this series. I'll make sure it is more clear.
Re: [PATCH] drm/amd/display: avoid 64-bit division
Acked-by: Slava Abramov
Tested-by: Slava Abramov
From: amd-gfx on behalf of Arnd
Bergmann
Sent: Monday, July 8, 2019 9:52:08 AM
To: Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander; Koenig, Christian;
Zhou, David(ChunMing); David Airlie; Daniel Vetter
Cc: Liu, Charlene; Park, Chris; Arnd Bergmann; Cheng, Tony; Francis, David;
linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Cornij, Nikola;
Laktyushkin, Dmytro; dri-devel@lists.freedesktop.org; Lei, Jun; Lakha,
Bhawanpreet; Koo, Anthony
Subject: [PATCH] drm/amd/display: avoid 64-bit division
On 32-bit architectures, dividing a 64-bit integer in the kernel
leads to a link error:
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Change the two recently introduced instances to a multiply+shift
operation that is also much cheaper on 32-bit architectures.
We can do that here, since both of them are really 32-bit numbers
that change a few percent.
Fixes: bedbbe6af4be ("drm/amd/display: Move link functions from dc to dc_link")
Fixes: f18bc4e53ad6 ("drm/amd/display: update calculated bounding box logic for
NV")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index c17db5c144aa..8dbf759eba45 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3072,8 +3072,8 @@ uint32_t dc_link_bandwidth_kbps(
* but the difference is minimal and is in a safe direction,
* which all works well around potential ambiguity of DP 1.4a
spec.
*/
- long long fec_link_bw_kbps = link_bw_kbps * 970LL;
- link_bw_kbps = (uint32_t)(fec_link_bw_kbps / 1000LL);
+ link_bw_kbps = mul_u64_u32_shr(BIT_ULL(32) * 970LL / 1000,
+ link_bw_kbps, 32);
}
#endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index b35327bafbc5..70ac8a95d2db 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -2657,7 +2657,7 @@ static void update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_
calculated_states[i].dram_speed_mts = uclk_states[i] * 16 /
1000;
// FCLK:UCLK ratio is 1.08
- min_fclk_required_by_uclk = ((unsigned long
long)uclk_states[i]) * 1080 / 100;
+ min_fclk_required_by_uclk = mul_u64_u32_shr(BIT_ULL(32) * 1080
/ 100, uclk_states[i], 32);
calculated_states[i].fabricclk_mhz =
(min_fclk_required_by_uclk < min_dcfclk) ?
min_dcfclk : min_fclk_required_by_uclk;
--
2.20.0
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 6/6] drm/hdcp: reference for srm file format
In the kernel documentation, HDCP specifications links are shared as a reference for SRM table format. Signed-off-by: Ramalingam C --- drivers/gpu/drm/drm_hdcp.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c index 77433ee3d652..803bf8283b83 100644 --- a/drivers/gpu/drm/drm_hdcp.c +++ b/drivers/gpu/drm/drm_hdcp.c @@ -271,6 +271,13 @@ static void drm_hdcp_request_srm(struct drm_device *drm_dev) * * SRM should be presented in the name of "display_hdcp_srm.bin". * + * Format of the SRM table that userspace needs to write into the binary file + * is defined at + * 1. Renewability chapter on 55th page of HDCP 1.4 specification + * https://www.digital-cp.com/sites/default/files/specifications/HDCP%20Specification%20Rev1_4_Secure.pdf + * 2. Renewability chapter on 63rd page of HDCP 2.2 specification + * https://www.digital-cp.com/sites/default/files/specifications/HDCP%20on%20HDMI%20Specification%20Rev2_2_Final1.pdf + * * Returns: * TRUE on any of the KSV is revoked, else FALSE. */ -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 3/6] drm: uevent for connector status change
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR= and PROPERTY=
Need ACK from this uevent from userspace consumer.
v2:
Minor fixes at KDoc comments [Daniel]
v3:
Check the property is really attached with connector [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_sysfs.c | 35 +++
include/drm/drm_sysfs.h | 5 -
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index ad10810bc972..d13a77057045 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -26,6 +26,7 @@
#include
#include "drm_internal.h"
+#include "drm_crtc_internal.h"
#define to_drm_minor(d) dev_get_drvdata(d)
#define to_drm_connector(d) dev_get_drvdata(d)
@@ -325,6 +326,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
* Send a uevent for the DRM device specified by @dev. Currently we only
* set HOTPLUG=1 in the uevent environment, but this could be expanded to
* deal with other types of events.
+ *
+ * Any new uapi should be using the drm_sysfs_connector_status_event()
+ * for uevents on connector status change.
*/
void drm_sysfs_hotplug_event(struct drm_device *dev)
{
@@ -337,6 +341,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_sysfs_hotplug_event);
+/**
+ * drm_sysfs_connector_status_event - generate a DRM uevent for connector
+ * property status change
+ * @connector: connector on which property status changed
+ * @property: connector property whoes status changed.
+ *
+ * Send a uevent for the DRM device specified by @dev. Currently we
+ * set HOTPLUG=1 and connector id along with the attached property id
+ * related to the status change.
+ */
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property)
+{
+ struct drm_device *dev = connector->dev;
+ char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
+ char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
+
+ WARN_ON(!drm_mode_obj_find_prop_id(>base,
+ property->base.id));
+
+ snprintf(conn_id, ARRAY_SIZE(conn_id),
+"CONNECTOR=%u", connector->base.id);
+ snprintf(prop_id, ARRAY_SIZE(prop_id),
+"PROPERTY=%u", property->base.id);
+
+ DRM_DEBUG("generating connector status event\n");
+
+ kobject_uevent_env(>primary->kdev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_connector_status_event);
+
static void drm_sysfs_release(struct device *dev)
{
kfree(dev);
diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
index 4f311e836cdc..d454ef617b2c 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -4,10 +4,13 @@
struct drm_device;
struct device;
+struct drm_connector;
+struct drm_property;
int drm_class_device_register(struct device *dev);
void drm_class_device_unregister(struct device *dev);
void drm_sysfs_hotplug_event(struct drm_device *dev);
-
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property);
#endif
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 5/6] drm/i915: update the hdcp state with uevent
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.
Hence whenever kernel changes the property state, userspace will be
updated with a uevent.
Need a ACK for uevent generating uAPI from userspace.
v2:
state update is moved into drm function [daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 4580af57bddb..e56969ebdd25 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -865,7 +865,6 @@ static void intel_hdcp_prop_work(struct work_struct *work)
prop_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
struct drm_device *dev = connector->base.dev;
- struct drm_connector_state *state;
drm_modeset_lock(>mode_config.connection_mutex, NULL);
mutex_lock(>mutex);
@@ -875,10 +874,9 @@ static void intel_hdcp_prop_work(struct work_struct *work)
* those to UNDESIRED is handled by core. If value == UNDESIRED,
* we're running just after hdcp has been disabled, so just exit
*/
- if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- state = connector->base.state;
- state->content_protection = hdcp->value;
- }
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ drm_hdcp_update_content_protection(>base,
+ hdcp->value);
mutex_unlock(>mutex);
drm_modeset_unlock(>mode_config.connection_mutex);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 4/6] drm/hdcp: update content protection property with uevent
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.
Need ACK for the uevent from userspace consumer.
v2:
Update only when state is different from old one.
v3:
KDoc is added [Daniel]
v4:
KDoc is extended bit more [pekka]
v5:
Uevent usage is documented at kdoc of "Content Protection" also
[pekka]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_connector.c | 17 +
drivers/gpu/drm/drm_hdcp.c | 34 +
include/drm/drm_hdcp.h | 2 ++
3 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 732f6645643d..6de906ef10b3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -947,10 +947,19 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
* - If the state is DESIRED, kernel should attempt to re-authenticate the
* link whenever possible. This includes across disable/enable, dpms,
* hotplug, downstream device changes, link status failures, etc..
- * - Userspace is responsible for polling the property to determine when
- * the value transitions from ENABLED to DESIRED. This signifies the link
- * is no longer protected and userspace should take appropriate action
- * (whatever that might be).
+ * - Kernel sends uevent with the connector id and property id through
+ * @drm_hdcp_update_content_protection, upon below kernel triggered
+ * scenarios:
+ * DESIRED -> ENABLED (authentication success)
+ * ENABLED -> DESIRED (termination of authentication)
+ * - Please note no uevents for userspace triggered property state changes,
+ * which can't fail such as
+ * DESIRED/ENABLED -> UNDESIRED
+ * UNDESIRED -> DESIRED
+ * - Userspace is responsible for polling the property or listen to uevents
+ * to determine when the value transitions from ENABLED to DESIRED.
+ * This signifies the link is no longer protected and userspace should
+ * take appropriate action (whatever that might be).
*
* HDCP Content Type:
* This Enum property is used by the userspace to declare the content type
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index ce235fd1c844..77433ee3d652 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -374,6 +374,10 @@ DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
*
* The content protection will be set to
_connector_state.content_protection
*
+ * When kernel triggered content protection state change like DESIRED->ENABLED
+ * and ENABLED->DESIRED, will use drm_hdcp_update_content_protection() to
update
+ * the content protection state of a connector.
+ *
* Returns:
* Zero on success, negative errno on failure.
*/
@@ -414,3 +418,33 @@ int drm_connector_attach_content_protection_property(
return 0;
}
EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
+
+/**
+ * drm_hdcp_update_content_protection - Updates the content protection state
+ * of a connector
+ *
+ * @connector: drm_connector on which content protection state needs an update
+ * @val: New state of the content protection property
+ *
+ * This function can be used by display drivers, to update the kernel triggered
+ * content protection state changes of a drm_connector such as DESIRED->ENABLED
+ * and ENABLED->DESIRED. No uevent for DESIRED->UNDESIRED or
ENABLED->UNDESIRED,
+ * as userspace is triggering such state change and kernel performs it without
+ * fail.This function update the new state of the property into the connector's
+ * state and generate an uevent to notify the userspace.
+ */
+void drm_hdcp_update_content_protection(struct drm_connector *connector,
+ u64 val)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_connector_state *state = connector->state;
+
+ WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
+ if (state->content_protection == val)
+ return;
+
+ state->content_protection = val;
+ drm_sysfs_connector_status_event(connector,
+dev->mode_config.content_protection_property);
+}
+EXPORT_SYMBOL(drm_hdcp_update_content_protection);
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 2970abdfaf12..dd864ac9ce85 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -292,4 +292,6 @@ bool drm_hdcp_check_ksvs_revoked(struct drm_device *dev,
u8 *ksvs, u32 ksv_count);
int drm_connector_attach_content_protection_property(
struct drm_connector *connector, bool hdcp_content_type);
+void drm_hdcp_update_content_protection(struct drm_connector *connector,
+
[PATCH v9 2/6] drm/i915: Attach content type property
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
Need ACK for content type property from userspace consumer.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
[Maarten]
v3:
s/content_protection_type/hdcp_content_type [Pekka]
v4:
hdcp disable incase of type change is moved into commit [daniel].
v5:
Simplified the Type change procedure. [Daniel]
v6:
Type change with UNDESIRED state is ignored.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/display/intel_ddi.c | 39
drivers/gpu/drm/i915/display/intel_hdcp.c | 43 +++
drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +-
3 files changed, 62 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a4172595c8d8..862907393a6d 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3514,7 +3514,8 @@ static void intel_enable_ddi(struct intel_encoder
*encoder,
/* Enable hdcp if it's desired */
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector));
+ intel_hdcp_enable(to_intel_connector(conn_state->connector),
+ (u8)conn_state->hdcp_content_type);
}
static void intel_disable_ddi_dp(struct intel_encoder *encoder,
@@ -3583,15 +3584,41 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ bool content_protection_type_changed =
+ (conn_state->hdcp_content_type != hdcp->content_type &&
+conn_state->content_protection !=
+DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
+
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+ /*
+* During the HDCP encryption session if Type change is requested,
+* disable the HDCP and reenable it with new TYPE value.
+*/
if (conn_state->content_protection ==
- DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector));
- else if (conn_state->content_protection ==
-DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
- intel_hdcp_disable(to_intel_connector(conn_state->connector));
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
+ content_protection_type_changed)
+ intel_hdcp_disable(connector);
+
+ /*
+* Mark the hdcp state as DESIRED after the hdcp disable of type
+* change procedure.
+*/
+ if (content_protection_type_changed) {
+ mutex_lock(>mutex);
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ mutex_unlock(>mutex);
+ }
+
+ if (conn_state->content_protection ==
+ DRM_MODE_CONTENT_PROTECTION_DESIRED ||
+ content_protection_type_changed)
+ intel_hdcp_enable(connector, (u8)conn_state->hdcp_content_type);
}
static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 2a4d10952b74..4580af57bddb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1748,14 +1748,15 @@ static const struct component_ops
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
};
-static inline int initialize_hdcp_port_data(struct intel_connector *connector)
+static inline int initialize_hdcp_port_data(struct intel_connector *connector,
+ const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
data->port = connector->encoder->port;
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
- data->protocol = (u8)hdcp->shim->protocol;
+ data->protocol = (u8)shim->protocol;
data->k = 1;
if (!data->streams)
@@ -1805,12 +1806,13 @@ void intel_hdcp_component_init(struct drm_i915_private
*dev_priv)
}
}
-static void intel_hdcp2_init(struct intel_connector *connector)
+static void intel_hdcp2_init(struct intel_connector
[PATCH v9 1/6] drm: Add Content protection type property
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.
So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.
Need ACK for this new conenctor property from userspace consumer.
v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
v5:
kernel doc nits addressed [Daniel]
Rebased as part of patch reordering.
v6:
Kernel docs are modified [pekka]
v7:
More details in Kernel docs. [pekka]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_connector.c | 39 +++
drivers/gpu/drm/drm_hdcp.c| 36 -
drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++-
include/drm/drm_connector.h | 7
include/drm/drm_hdcp.h| 2 +-
include/drm/drm_mode_config.h | 6
include/uapi/drm/drm_mode.h | 4 +++
8 files changed, 99 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index abe38bdf85ae..19ae119f1a5d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -747,6 +747,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == config->hdcp_content_type_property) {
+ state->hdcp_content_type = val;
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
@@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
state->hdr_output_metadata->base.id : 0;
} else if (property == config->content_protection_property) {
*val = state->content_protection;
+ } else if (property == config->hdcp_content_type_property) {
+ *val = state->hdcp_content_type;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 068d4b05f1be..732f6645643d 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -952,6 +952,45 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
* is no longer protected and userspace should take appropriate action
* (whatever that might be).
*
+ * HDCP Content Type:
+ * This Enum property is used by the userspace to declare the content type
+ * of the display stream, to kernel. Here display stream stands for any
+ * display content that userspace intended to render with HDCP encryption.
+ *
+ * Content Type of a stream is decided by the owner of the stream, as
+ * "HDCP Type0" or "HDCP Type1".
+ *
+ * The value of the property can be one the below:
+ * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
+ * - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1
+ *
+ * When kernel starts the HDCP authentication upon the "DESIRED" state of
+ * the "Content Protection", it refers the "HDCP Content Type" property
+ * state. And perform the HDCP authentication with the display sink for
+ * the content type mentioned by "HDCP Content Type".
+ *
+ * Stream classified as HDCP Type0 can be transmitted on a link which is
+ * encrypted with HDCP 1.4 or higher versions of HDCP(i.e HDCP2.2
+ * and more).
+ *
+ * Streams classified as HDCP Type1 can be transmitted on a link which is
+ * encrypted only with HDCP 2.2. In future, HDCP versions >2.2 also might
+ * support Type1 based on their spec.
+ *
+ * HDCP2.2 authentication protocol itself takes the "Content Type" as a
+ * parameter, which is a input for the DP HDCP2.2 encryption algo.
+ *
+ * Note that the HDCP Content Type property is introduced at HDCP 2.2, and
+ * defaults to type 0. It is only exposed by drivers supporting HDCP 2.2.
+ * Based on how next versions of HDCP specs are defined content Type could
+ * be used for higher versions too.
+ *
+ * If content type is changed
[PATCH v9 0/6] HDCP2.2 Phase II
Adding the uAPI support for the HDCP content type is the main focus here. Along with that uevent is implemented for the "Content Protection" state change that got triggered by kernel. v9: KDoc improvements [pekka] Ramalingam C (6): drm: Add Content protection type property drm/i915: Attach content type property drm: uevent for connector status change drm/hdcp: update content protection property with uevent drm/i915: update the hdcp state with uevent drm/hdcp: reference for srm file format drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ drivers/gpu/drm/drm_connector.c | 56 +++-- drivers/gpu/drm/drm_hdcp.c| 77 ++- drivers/gpu/drm/drm_sysfs.c | 35 +++ drivers/gpu/drm/i915/display/intel_ddi.c | 39 ++-- drivers/gpu/drm/i915/display/intel_hdcp.c | 53 ++-- drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +- include/drm/drm_connector.h | 7 +++ include/drm/drm_hdcp.h| 4 +- include/drm/drm_mode_config.h | 6 ++ include/drm/drm_sysfs.h | 5 +- include/uapi/drm/drm_mode.h | 4 ++ 12 files changed, 258 insertions(+), 34 deletions(-) -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/a6xx: add missing MODULE_FIRMWARE()
On Wed 03 Jul 07:00 PDT 2019, Rob Clark wrote:
> From: Rob Clark
>
> For platforms that require the "zap shader" to take the GPU out of
> secure mode at boot, we also need the zap fw to end up in the initrd.
>
> Signed-off-by: Rob Clark
My upcoming pull request for this merge window includes the support for
the mdt_loader to read unsplit firmware files. So how about running the
firmware through [1] (pil-squasher a630_zap.mbn a630_zap.mdt) and
pointing the driver to use the single .mbn file instead?
If not, you have my:
Reviewed-by: Bjorn Andersson
[1] https://github.com/andersson/pil-squasher
Regards,
Bjorn
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index d9ac8c4cd866..aa64514afd5c 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -174,6 +174,10 @@ MODULE_FIRMWARE("qcom/a530_zap.b01");
> MODULE_FIRMWARE("qcom/a530_zap.b02");
> MODULE_FIRMWARE("qcom/a630_sqe.fw");
> MODULE_FIRMWARE("qcom/a630_gmu.bin");
> +MODULE_FIRMWARE("qcom/a630_zap.mdt");
> +MODULE_FIRMWARE("qcom/a630_zap.b00");
> +MODULE_FIRMWARE("qcom/a630_zap.b01");
> +MODULE_FIRMWARE("qcom/a630_zap.b02");
>
> static inline bool _rev_match(uint8_t entry, uint8_t id)
> {
> --
> 2.20.1
>
Re: [PATCH v6 01/18] kunit: test: add KUnit test runner core
On Fri, Jul 5, 2019 at 1:20 PM Luis Chamberlain wrote:
>
> On Wed, Jul 03, 2019 at 05:35:58PM -0700, Brendan Higgins wrote:
> > +struct kunit {
> > + void *priv;
> > +
> > + /* private: internal use only. */
> > + const char *name; /* Read only after initialization! */
> > + bool success; /* Read only after test_case finishes! */
> > +};
>
> No lock attribute above.
>
> > +void kunit_init_test(struct kunit *test, const char *name)
> > +{
> > + spin_lock_init(>lock);
> > + test->name = name;
> > + test->success = true;
> > +}
>
> And yet here you initialize a spin lock... This won't compile. Seems
> you forgot to remove this line. So I guess a re-spin is better.
Oh crap, sorry about that. You can't compile these patches until the
kbuild patch. I will fix this and make sure I didn't make any similar
mistakes on these early patches.
Thanks!
Re: [PATCH v6 01/18] kunit: test: add KUnit test runner core
On Fri, Jul 5, 2019 at 1:15 PM Luis Chamberlain wrote: > > On Wed, Jul 03, 2019 at 05:35:58PM -0700, Brendan Higgins wrote: > > Add core facilities for defining unit tests; this provides a common way > > to define test cases, functions that execute code which is under test > > and determine whether the code under test behaves as expected; this also > > provides a way to group together related test cases in test suites (here > > we call them test_modules). > > > > Just define test cases and how to execute them for now; setting > > expectations on code will be defined later. > > > > Signed-off-by: Brendan Higgins > > Reviewed-by: Greg Kroah-Hartman > > Reviewed-by: Logan Gunthorpe > > Reviewed-by: Luis Chamberlain > > But a nitpick below, I think that can be fixed later with a follow up > patch. > > > +/** > > + * struct kunit - represents a running instance of a test. > > + * @priv: for user to store arbitrary data. Commonly used to pass data > > created > > + * in the init function (see kunit_suite). > > + * > > + * Used to store information about the current context under which the > > test is > > + * running. Most of this data is private and should only be accessed > > indirectly > > + * via public functions; the one exception is @priv which can be used by > > the > > + * test writer to store arbitrary data. > > + * > > + * A brief note on locking: > > + * > > + * First off, we need to lock because in certain cases a user may want to > > use an > > + * expectation in a thread other than the thread that the test case is > > running > > + * in. > > This as a prefix to the struct without a lock seems odd. It would be > clearer I think if you'd explain here what locking mechanism we decided > to use and why it suffices today. Whoops, sorry this should have been in the next patch. Will fix. > > +/** > > + * suite_test() - used to register a kunit_suite with KUnit. > > You mean kunit_test_suite()? Yep, sorry about that. Will fix. > > + * @suite: a statically allocated kunit_suite. > > + * > > + * Registers @suite with the test framework. See kunit_suite for > > more > > + * information. > > + * > > + * NOTE: Currently KUnit tests are all run as late_initcalls; this means > > that > > + * they cannot test anything where tests must run at a different init > > phase. One > > + * significant restriction resulting from this is that KUnit cannot > > reliably > > + * test anything that is initialize in the late_init phase. > initialize prior to the late init phase. > > > That is, this is useless to test things running early. Yeah, I can add that phrasing in. > > + * > > + * TODO(brendanhigg...@google.com): Don't run all KUnit tests as > > late_initcalls. > > + * I have some future work planned to dispatch all KUnit tests from the > > same > > + * place, and at the very least to do so after everything else is > > definitely > > + * initialized. > > TODOs are odd to be adding to documentation, this is just not common > place practice. The NOTE should suffice for you. Because it is a kernel doc? Would you usually make a separate non-kernel doc comment for a TODO? I guess that makes sense. Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] gpu/drm_memory: fix a few warnings
The opening comment mark "/**" is reserved for kernel-doc comments, so it will generate a warning with "make W=1". drivers/gpu/drm/drm_memory.c:2: warning: Cannot understand * \file drm_memory.c Also, silence a checkpatch warning by adding a license identfiter where it indicates the MIT license further down in the source file. WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 It becomes redundant to add both an SPDX identifier and have a description of the license in the comment block at the top, so remove the later. Signed-off-by: Qian Cai --- v2: remove the redundant description of the license. drivers/gpu/drm/drm_memory.c | 22 ++ 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c index 132fef8ff1b6..86a11fc8e954 100644 --- a/drivers/gpu/drm/drm_memory.c +++ b/drivers/gpu/drm/drm_memory.c @@ -1,4 +1,5 @@ -/** +// SPDX-License-Identifier: MIT +/* * \file drm_memory.c * Memory management wrappers for DRM * @@ -12,25 +13,6 @@ * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. * All Rights Reserved. - * - * 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 (including the next - * paragraph) 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 - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR - * OTHER DEALINGS IN THE SOFTWARE. */ #include -- 1.8.3.1
Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing
On Mon, Jul 01, 2019 at 09:39:06AM -0700, Doug Anderson wrote:
> Hi,
>
> On Sun, Jun 30, 2019 at 1:55 PM Sam Ravnborg wrote:
> >
> > Hi Douglas.
> >
> > > > +
> > > > + /* Only add timings if override was not there or failed to validate
> > > > */
> > > > + if (num == 0 && panel->desc->num_timings)
> > > > + num = panel_simple_get_timings_modes(panel);
> > > > +
> > > > + /*
> > > > +* Only add fixed modes if timings/override added no mode.
> > >
> > > This part I fail to understand.
> > > If we have a panel where we in panel-simple have specified the timings,
> > > and done so using display_timing so with proper {min, typ, max} then it
> > > should be perfectly legal to specify a more precise variant in the DT
> > > file.
> > > Or what did I miss here?
> >
> > Got it now.
> > If display_mode is used for timings this is what you call "fixed mode".
> > Hmm, if I got confused someone else may also be confused by this naming.
>
> The name "fixed mode" comes from the old code, though I guess in the
> old code it used to refer to a mode that came from either the
> display_timing or the display_mode.
>
> How about if I call it "panel_simple_get_from_fixed_display_mode"?
> ...or if you have another suggestion feel free to chime in.
What we really want to distingush here is the use of display_mode
and display_timings (if I got the names right).
That display_mode specify a fixed timing and display_timing specify
a valid range is something in the semantics of the two types.
So naming that refer to display_mode versus display_timing will make the
code simpler to understand. and then a nice comment that when
display_mode
is used one looses the possibility to use override_mode.
That would be fine to have in the struct in the driver.
> NOTE: Since this feedback is minor and this patch has been outstanding
> for a while (and is blocking other work), I am assuming that the best
> path forward is for Heiko to land this patch with Thierry's Ack and
> I'll send a follow-up. Please yell if you disagree.
Let's give the patches a spin more as we have passed the possibility for
the current merge window.
I am on vacation at the moment and thus slow in responses, but will be back
at the home office next week and will be more responsive again.
Sam - who is enjoying the alps in Austria
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing
Hi Dough.
On Mon, Jul 01, 2019 at 09:39:24AM -0700, Doug Anderson wrote:
> Hi,
>
> On Sun, Jun 30, 2019 at 1:22 PM Sam Ravnborg wrote:
> >
> > > @@ -91,6 +92,8 @@ struct panel_simple {
> > > struct i2c_adapter *ddc;
> > >
> > > struct gpio_desc *enable_gpio;
> > > +
> > > + struct drm_display_mode override_mode;
> > I fail to see where this poiter is assigned.
>
> In panel_simple_parse_override_mode(). Specifically:
>
> drm_display_mode_from_videomode(, >override_mode);
The above code-snippet is only called in the panel has specified display
timings using display_timings - it is not called when display_mode is
used.
So override_mode is only assigned in some cases and not all cases.
This needs to be fixed so we do not reference override_mode unless
it is set.
>
>
> > @@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct
> > panel_simple *panel)
> > > num++;
> > > }
> > >
> > > + return num;
> > > +}
> > > +
> > > +static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
> > > +{
> > > + struct drm_connector *connector = panel->base.connector;
> > > + struct drm_device *drm = panel->base.drm;
> > > + struct drm_display_mode *mode;
> > > + bool has_override = panel->override_mode.type;
> > This looks suspicious.
> > panel->override_mode.type is an unsigned int that may have a number of
> > bits set.
> > So the above code implicitly convert a .type != 0 to a true.
> > This can be expressed in a much more reader friendly way.
>
> You would suggest that I add a boolean field to a structure to
> indicate whether an override mode is present?
A simple bool has_override = panel->override_mode.type != 0;
would do the trick here.
Then there is no hidden conversion from int to a bool.
But as override_mode can be NULL something more needs to be done.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111082] Severe stutter in CS:GO surf servers, despite ~300fps
https://bugs.freedesktop.org/show_bug.cgi?id=111082 --- Comment #6 from nuc...@hotmail.com --- Hm, well as I said my fps are constantly very high, so it looks like a frame pacing issue. My CPU load is also super low and never above 50 % on a single core. Of course this might be an issue with the Linux implementation of CS:GO, but I think it would be worth figuring out where exactly the culprit is. It can only be those two things: CS:GO or the graphics driver.. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111087] SteamOS boots to black screen
https://bugs.freedesktop.org/show_bug.cgi?id=111087 --- Comment #12 from Michel Dänzer --- Sounds like Xorg keeps crashing, please attach the Xorg.0.log.old file. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 111082] Severe stutter in CS:GO surf servers, despite ~300fps
I did report my CSGO performance pb to valve devs: https://github.com/ValveSoftware/csgo-osx-linux/issues/ I have no idea if my CPU bound performance pb is in the driver (which is very likely since it's opengl), or the 3D engine. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111082] Severe stutter in CS:GO surf servers, despite ~300fps
https://bugs.freedesktop.org/show_bug.cgi?id=111082 --- Comment #5 from Sylvain BERTRAND --- I did report my CSGO performance pb to valve devs: https://github.com/ValveSoftware/csgo-osx-linux/issues/ I have no idea if my CPU bound performance pb is in the driver (which is very likely since it's opengl), or the 3D engine. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/panel: simple: Add support for Sharp LD-D5116Z01B panel
The Sharp LD-D5116Z01B is a 12.3" eDP panel with a 1920X1280 resolution.
Signed-off-by: Jeffrey Hugo
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5a93c4edf1e4..a8808b13c370 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2354,6 +2354,32 @@ static const struct panel_desc samsung_ltn140at29_301 = {
},
};
+static const struct drm_display_mode sharp_ld_d5116z01b_mode = {
+ .clock = 168480,
+ .hdisplay = 1920,
+ .hsync_start = 1920 + 48,
+ .hsync_end = 1920 + 48 + 32,
+ .htotal = 1920 + 48 + 32 + 80,
+ .vdisplay = 1280,
+ .vsync_start = 1280 + 3,
+ .vsync_end = 1280 + 3 + 10,
+ .vtotal = 1280 + 3 + 10 + 57,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc sharp_ld_d5116z01b = {
+ .modes = _ld_d5116z01b_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 260,
+ .height = 120,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DATA_MSB_TO_LSB,
+};
+
static const struct drm_display_mode sharp_lq035q7db03_mode = {
.clock = 5500,
.hdisplay = 240,
@@ -3002,6 +3028,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "samsung,ltn140at29-301",
.data = _ltn140at29_301,
+ }, {
+ .compatible = "sharp,ld-d5116z01b",
+ .data = _ld_d5116z01b,
}, {
.compatible = "sharp,lq035q7db03",
.data = _lq035q7db03,
--
2.17.1
[PATCH v2 0/2] Add Sharp panel option for Lenovo Miix 630
The Lenovo Miix 630 laptop can be found with one of two panels - a BOE or Sharp option. This likely provides options during manufacturing. These panels connect via eDP, however they sit behind a DSI to eDP bridge on the laptop, so they can easily be handled by the existing simple panel code. This series adds support for the Sharp option. v2: -removed no-hpd from dt example -added .bus_format and .bus_flags fields based on reviews -added .flags after Bjorn pointed me to something I missed -added Sam's reviewed-by tags Jeffrey Hugo (2): dt-bindings: panel: Add Sharp LD-D5116Z01B drm/panel: simple: Add support for Sharp LD-D5116Z01B panel .../display/panel/sharp,ld-d5116z01b.txt | 26 + drivers/gpu/drm/panel/panel-simple.c | 29 +++ 2 files changed, 55 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.txt -- 2.17.1
[PATCH v2 1/2] dt-bindings: panel: Add Sharp LD-D5116Z01B
The Sharp LD-D5116Z01B is a 12.3" eDP panel with a 1920X1280 resolution.
Signed-off-by: Jeffrey Hugo
Reviewed-by: Sam Ravnborg
---
.../display/panel/sharp,ld-d5116z01b.txt | 26 +++
1 file changed, 26 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.txt
b/Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.txt
new file mode 100644
index ..fd9cf39bde77
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.txt
@@ -0,0 +1,26 @@
+Sharp LD-D5116Z01B 12.3" WUXGA+ eDP panel
+
+Required properties:
+- compatible: should be "sharp,ld-d5116z01b"
+- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
+
+This binding is compatible with the simple-panel binding.
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [1]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel: panel {
+ compatible = "sharp,ld-d5116z01b";
+ power-supply = <_3v3>;
+
+ port {
+ panel_ep: endpoint {
+ remote-endpoint = <_out_ep>;
+ };
+ };
+ };
--
2.17.1
[Bug 111082] Severe stutter in CS:GO surf servers, despite ~300fps
https://bugs.freedesktop.org/show_bug.cgi?id=111082 --- Comment #4 from nuc...@hotmail.com --- So maybe we should figure out if it is graphics driver related or a bug in the CS:GO engine? Why has this bug report been set to "RESOLVED FIX"? I understand claiming that this might not be a graphics driver bug, but it might pretty well be one. On which basis are reports closed here, on speculations? In the end I want to help the Linux ecosystem and make games work, because now even though my own CSGO surf server is on Linux, I have to switch to Windows 10 to test it which is utterly ridiculus. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 12/14] drm/i915: s/crtc_mask/pipe_mask/
From: Ville Syrjälä
Rename the encoder->crtc_mask to encoder->pipe_mask to better
reflect what it actually contains.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
drivers/gpu/drm/i915/display/intel_crt.c | 4 ++--
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
drivers/gpu/drm/i915/display/intel_dvo.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c| 6 +++---
drivers/gpu/drm/i915/display/intel_lvds.c| 4 ++--
drivers/gpu/drm/i915/display/intel_sdvo.c| 2 +-
drivers/gpu/drm/i915/display/intel_tv.c | 2 +-
drivers/gpu/drm/i915/display/vlv_dsi.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 5 +++--
13 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index b8673debf932..0641bc1a36fb 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1549,7 +1549,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
encoder->get_hw_state = gen11_dsi_get_hw_state;
encoder->type = INTEL_OUTPUT_DSI;
encoder->cloneable = 0;
- encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C);
+ encoder->pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C);
encoder->power_domain = POWER_DOMAIN_PORT_DSI;
encoder->get_power_domains = gen11_dsi_get_power_domains;
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
b/drivers/gpu/drm/i915/display/intel_crt.c
index 68457e8e07aa..c9055e1ea988 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -997,9 +997,9 @@ void intel_crt_init(struct drm_i915_private *dev_priv)
crt->base.type = INTEL_OUTPUT_ANALOG;
crt->base.cloneable = (1 << INTEL_OUTPUT_DVO) | (1 <<
INTEL_OUTPUT_HDMI);
if (IS_I830(dev_priv))
- crt->base.crtc_mask = BIT(PIPE_A);
+ crt->base.pipe_mask = BIT(PIPE_A);
else
- crt->base.crtc_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C);
+ crt->base.pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C);
if (IS_GEN(dev_priv, 2))
connector->interlace_allowed = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 30e48609db1d..9ab6b40e4b61 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4250,7 +4250,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
intel_encoder->port = port;
intel_encoder->cloneable = 0;
for_each_pipe(dev_priv, pipe)
- intel_encoder->crtc_mask |= BIT(pipe);
+ intel_encoder->pipe_mask |= BIT(pipe);
if (INTEL_GEN(dev_priv) >= 11)
intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 93fdd1cbd343..70ec20444255 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15218,7 +15218,7 @@ static u32 intel_encoder_possible_crtcs(struct
intel_encoder *encoder)
u32 possible_crtcs = 0;
for_each_intel_crtc(dev, crtc) {
- if (encoder->crtc_mask & BIT(crtc->pipe))
+ if (encoder->pipe_mask & BIT(crtc->pipe))
possible_crtcs |= drm_crtc_mask(>base);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6baa537e9849..ef183a90e929 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7283,11 +7283,11 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder->power_domain = intel_port_to_power_domain(port);
if (IS_CHERRYVIEW(dev_priv)) {
if (port == PORT_D)
- intel_encoder->crtc_mask = BIT(PIPE_C);
+ intel_encoder->pipe_mask = BIT(PIPE_C);
else
- intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B);
+ intel_encoder->pipe_mask = BIT(PIPE_A) | BIT(PIPE_B);
} else {
- intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B) |
BIT(PIPE_C);
+ intel_encoder->pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) |
BIT(PIPE_C);
}
intel_encoder->cloneable = 0;
intel_encoder->port = port;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index d08e4a47816a..f79842c7be67 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -602,7
Re: [PATCH v8 6/6] drm/hdcp: reference for srm file format
On 2019-07-08 at 13:16:23 +0300, Pekka Paalanen wrote: > On Fri, 5 Jul 2019 06:16:42 +0530 > Ramalingam C wrote: > > > In the kernel documentation, HDCP specifications links are shared as a > > reference for SRM table format. > > > > Signed-off-by: Ramalingam C > > --- > > drivers/gpu/drm/drm_hdcp.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c > > index 77433ee3d652..803bf8283b83 100644 > > --- a/drivers/gpu/drm/drm_hdcp.c > > +++ b/drivers/gpu/drm/drm_hdcp.c > > @@ -271,6 +271,13 @@ static void drm_hdcp_request_srm(struct drm_device > > *drm_dev) > > * > > * SRM should be presented in the name of "display_hdcp_srm.bin". > > * > > + * Format of the SRM table that userspace needs to write into the binary > > file > > + * is defined at > > + * 1. Renewability chapter on 55th page of HDCP 1.4 specification > > + * > > https://www.digital-cp.com/sites/default/files/specifications/HDCP%20Specification%20Rev1_4_Secure.pdf > > + * 2. Renewability chapter on 63rd page of HDCP 2.2 specification > > + * > > https://www.digital-cp.com/sites/default/files/specifications/HDCP%20on%20HDMI%20Specification%20Rev2_2_Final1.pdf > > + * > > * Returns: > > * TRUE on any of the KSV is revoked, else FALSE. > > */ > > Hi, > > this look good, publicly accessible spec links even. I'm happy with > this, but I repeat that the Weston work[1] does not directly prove this > UAPI (perhaps not necessary either?). Thanks for helping to improve this part. -Ram > > > [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 > > Thanks, > pq ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 14/14] drm: Validate encoder->possible_crtcs
From: Ville Syrjälä
WARN if the encoder possible_crtcs is effectively empty or contains
bits for non-existing crtcs.
TODO: Or should we perhapst just filter out any bit for a
non-exisiting crtc?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_encoder.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 3ece97a9d029..07191e2db64c 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -106,6 +106,23 @@ static void validate_possible_clones(struct drm_encoder
*encoder)
encoder->possible_clones, encoder_mask);
}
+static void validate_possible_crtcs(struct drm_encoder *encoder)
+{
+ struct drm_device *dev = encoder->dev;
+ struct drm_crtc *crtc;
+ u32 crtc_mask = 0;
+
+ drm_for_each_crtc(crtc, dev)
+ crtc_mask |= drm_crtc_mask(crtc);
+
+ WARN((encoder->possible_crtcs & crtc_mask) == 0 ||
+(encoder->possible_crtcs & ~crtc_mask) != 0,
+"Bogus possible_crtcs: "
+"[ENCODER:%d:%s] possible_crtcs=0x%x (full crtc mask=0x%x)\n",
+encoder->base.id, encoder->name,
+encoder->possible_crtcs, crtc_mask);
+}
+
int drm_encoder_register_all(struct drm_device *dev)
{
struct drm_encoder *encoder;
@@ -114,6 +131,7 @@ int drm_encoder_register_all(struct drm_device *dev)
fixup_possible_clones(dev);
drm_for_each_encoder(encoder, dev) {
+ validate_possible_crtcs(encoder);
validate_possible_clones(encoder);
if (encoder->funcs->late_register)
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 11/14] drm/i915: Simplfy LVDS crtc_mask setup
From: Ville Syrjälä We don't need to special case PCH vs. gen4 when setting up the LVDS crtc_mask. Just claim pipes A|B|C work and intel_encoder_crtcs() drop out any crtc that doesn't exist. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_lvds.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c b/drivers/gpu/drm/i915/display/intel_lvds.c index 765091a9835c..e79dcc891b80 100644 --- a/drivers/gpu/drm/i915/display/intel_lvds.c +++ b/drivers/gpu/drm/i915/display/intel_lvds.c @@ -901,10 +901,8 @@ void intel_lvds_init(struct drm_i915_private *dev_priv) intel_encoder->power_domain = POWER_DOMAIN_PORT_OTHER; intel_encoder->port = PORT_NONE; intel_encoder->cloneable = 0; - if (HAS_PCH_SPLIT(dev_priv)) + if (INTEL_GEN(dev_priv) >= 4) intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C); - else if (IS_GEN(dev_priv, 4)) - intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B); else intel_encoder->crtc_mask = BIT(PIPE_B); -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 13/14] drm: Validate encoder->possible_clones
From: Ville Syrjälä
Many drivers are populating encoder->possible_clones wrong. Let's
persuade them to get it right by adding some loud WARNs.
We'll cross check the bits between any two encoders. So either
both encoders can clone with the other, or neither can.
We'll also complain about effectively empty possible_clones, and
possible_clones containing bits for encoders that don't exist.
TODO: Or should we just silently filter out any bits for non-existing
encoders?
v2: encoder->possible_clones now includes the encoder itelf
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_encoder.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index e87e6fecc1fb..3ece97a9d029 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -78,6 +78,34 @@ static void fixup_possible_clones(struct drm_device *dev)
encoder->possible_clones |= drm_encoder_mask(encoder);
}
+static void validate_possible_clones(struct drm_encoder *encoder)
+{
+ struct drm_device *dev = encoder->dev;
+ struct drm_encoder *other;
+ u32 encoder_mask = 0;
+
+ drm_for_each_encoder(other, dev) {
+ encoder_mask |= drm_encoder_mask(other);
+
+ WARN(!(encoder->possible_clones & drm_encoder_mask(other)) !=
+!(other->possible_clones & drm_encoder_mask(encoder)),
+"possible_clones mismatch: "
+"[ENCODER:%d:%s] mask=0x%x possible_clones=0x%x vs. "
+"[ENCODER:%d:%s] mask=0x%x possible_clones=0x%x\n",
+encoder->base.id, encoder->name,
+drm_encoder_mask(encoder), encoder->possible_clones,
+other->base.id, other->name,
+drm_encoder_mask(other), other->possible_clones);
+ }
+
+ WARN((encoder->possible_clones & drm_encoder_mask(encoder)) == 0 ||
+(encoder->possible_clones & ~encoder_mask) != 0,
+"Bogus possible_clones: "
+"[ENCODER:%d:%s] possible_clones=0x%x (full encoder mask=0x%x)\n",
+encoder->base.id, encoder->name,
+encoder->possible_clones, encoder_mask);
+}
+
int drm_encoder_register_all(struct drm_device *dev)
{
struct drm_encoder *encoder;
@@ -86,6 +114,8 @@ int drm_encoder_register_all(struct drm_device *dev)
fixup_possible_clones(dev);
drm_for_each_encoder(encoder, dev) {
+ validate_possible_clones(encoder);
+
if (encoder->funcs->late_register)
ret = encoder->funcs->late_register(encoder);
if (ret)
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/14] drm/i915: Clean up encoder->crtc_mask setup
From: Ville Syrjälä
Use BIT(pipe) for better legibility when populating the crtc_mask
for encoders.
Also remove the redundant possible_crtcs setup for the TV encoder.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crt.c | 4 ++--
drivers/gpu/drm/i915/display/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/display/intel_dvo.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +++---
drivers/gpu/drm/i915/display/intel_lvds.c | 6 +++---
drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
drivers/gpu/drm/i915/display/intel_tv.c | 3 +--
7 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
b/drivers/gpu/drm/i915/display/intel_crt.c
index 3fcf2f84bcce..68457e8e07aa 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -997,9 +997,9 @@ void intel_crt_init(struct drm_i915_private *dev_priv)
crt->base.type = INTEL_OUTPUT_ANALOG;
crt->base.cloneable = (1 << INTEL_OUTPUT_DVO) | (1 <<
INTEL_OUTPUT_HDMI);
if (IS_I830(dev_priv))
- crt->base.crtc_mask = (1 << 0);
+ crt->base.crtc_mask = BIT(PIPE_A);
else
- crt->base.crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
+ crt->base.crtc_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C);
if (IS_GEN(dev_priv, 2))
connector->interlace_allowed = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0bdb7ecc5a81..6baa537e9849 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7283,11 +7283,11 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder->power_domain = intel_port_to_power_domain(port);
if (IS_CHERRYVIEW(dev_priv)) {
if (port == PORT_D)
- intel_encoder->crtc_mask = 1 << 2;
+ intel_encoder->crtc_mask = BIT(PIPE_C);
else
- intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
+ intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B);
} else {
- intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
+ intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B) |
BIT(PIPE_C);
}
intel_encoder->cloneable = 0;
intel_encoder->port = port;
diff --git a/drivers/gpu/drm/i915/display/intel_dvo.c
b/drivers/gpu/drm/i915/display/intel_dvo.c
index 22666d28f4aa..df491f59401b 100644
--- a/drivers/gpu/drm/i915/display/intel_dvo.c
+++ b/drivers/gpu/drm/i915/display/intel_dvo.c
@@ -505,7 +505,7 @@ void intel_dvo_init(struct drm_i915_private *dev_priv)
intel_encoder->type = INTEL_OUTPUT_DVO;
intel_encoder->power_domain = POWER_DOMAIN_PORT_OTHER;
intel_encoder->port = port;
- intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
+ intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B);
switch (dvo->type) {
case INTEL_DVO_CHIP_TMDS:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 0ebec69bbbfc..3a73577ef259 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3202,11 +3202,11 @@ void intel_hdmi_init(struct drm_i915_private *dev_priv,
intel_encoder->port = port;
if (IS_CHERRYVIEW(dev_priv)) {
if (port == PORT_D)
- intel_encoder->crtc_mask = 1 << 2;
+ intel_encoder->crtc_mask = BIT(PIPE_C);
else
- intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
+ intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B);
} else {
- intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
+ intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B) |
BIT(PIPE_C);
}
intel_encoder->cloneable = 1 << INTEL_OUTPUT_ANALOG;
/*
diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c
b/drivers/gpu/drm/i915/display/intel_lvds.c
index efefed62a7f8..765091a9835c 100644
--- a/drivers/gpu/drm/i915/display/intel_lvds.c
+++ b/drivers/gpu/drm/i915/display/intel_lvds.c
@@ -902,11 +902,11 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
intel_encoder->port = PORT_NONE;
intel_encoder->cloneable = 0;
if (HAS_PCH_SPLIT(dev_priv))
- intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
+ intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B) |
BIT(PIPE_C);
else if (IS_GEN(dev_priv, 4))
- intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
+ intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B);
else
- intel_encoder->crtc_mask = (1 << 1);
+
[PATCH v2 06/14] drm/imx: Remove the bogus possible_clones setup
From: Ville Syrjälä It's not at all clear what cloning options this driver supports. So let's just clear possible_clones instead of setting it to some bogus value. Cc: Philipp Zabel Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/imx/imx-drm-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c index bdefaa1635eb..bd650b0c27b2 100644 --- a/drivers/gpu/drm/imx/imx-drm-core.c +++ b/drivers/gpu/drm/imx/imx-drm-core.c @@ -136,7 +136,7 @@ int imx_drm_encoder_parse_of(struct drm_device *drm, encoder->possible_crtcs = crtc_mask; /* FIXME: this is the mask of outputs which can clone this output. */ - encoder->possible_clones = ~0; + encoder->possible_clones = 0; return 0; } -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/14] drm/exynos: Use drm_encoder_mask()
From: Ville Syrjälä Replace the hand rolled encoder bitmask thing with drm_encoder_mask() Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index cc53dcad25e4..140ef553e156 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -264,7 +264,7 @@ static int exynos_drm_bind(struct device *dev) struct drm_encoder *encoder; struct drm_device *drm; unsigned int clone_mask; - int cnt, ret; + int ret; drm = drm_dev_alloc(_drm_driver, dev); if (IS_ERR(drm)) @@ -287,10 +287,9 @@ static int exynos_drm_bind(struct device *dev) exynos_drm_mode_config_init(drm); /* setup possible_clones. */ - cnt = 0; clone_mask = 0; list_for_each_entry(encoder, >mode_config.encoder_list, head) - clone_mask |= (1 << (cnt++)); + clone_mask |= drm_encoder_mask(encoder); list_for_each_entry(encoder, >mode_config.encoder_list, head) encoder->possible_clones = clone_mask; -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/14] drm/i915: Populate possible_crtcs correctly
From: Ville Syrjälä
Don't advertize non-exisiting crtcs in the encoder possible_crtcs
bitmask.
Reviewed-by: Dhinakaran Pandiyan
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 503c20a3a49c..93fdd1cbd343 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15211,6 +15211,20 @@ static u32 intel_encoder_possible_clones(struct
intel_encoder *encoder)
return possible_clones;
}
+static u32 intel_encoder_possible_crtcs(struct intel_encoder *encoder)
+{
+ struct drm_device *dev = encoder->base.dev;
+ struct intel_crtc *crtc;
+ u32 possible_crtcs = 0;
+
+ for_each_intel_crtc(dev, crtc) {
+ if (encoder->crtc_mask & BIT(crtc->pipe))
+ possible_crtcs |= drm_crtc_mask(>base);
+ }
+
+ return possible_crtcs;
+}
+
static bool ilk_has_edp_a(struct drm_i915_private *dev_priv)
{
if (!IS_MOBILE(dev_priv))
@@ -15500,7 +15514,8 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
intel_psr_init(dev_priv);
for_each_intel_encoder(_priv->drm, encoder) {
- encoder->base.possible_crtcs = encoder->crtc_mask;
+ encoder->base.possible_crtcs =
+ intel_encoder_possible_crtcs(encoder);
encoder->base.possible_clones =
intel_encoder_possible_clones(encoder);
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/14] drm/i915: Fix DP-MST crtc_mask
From: Ville Syrjälä Each fake MST encoder is tied to a specific pipe. Fix the encoder's crtc_mask to reflect that fact. Reviewed-by: Dhinakaran Pandiyan Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c index 60652ebbdf61..d08e4a47816a 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c @@ -602,7 +602,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port *intel_dig_port, enum intel_encoder->type = INTEL_OUTPUT_DP_MST; intel_encoder->power_domain = intel_dig_port->base.power_domain; intel_encoder->port = intel_dig_port->base.port; - intel_encoder->crtc_mask = 0x7; + intel_encoder->crtc_mask = BIT(pipe); intel_encoder->cloneable = 0; intel_encoder->compute_config = intel_dp_mst_compute_config; -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/14] drm/i915: Polish possible_clones setup
From: Ville Syrjälä
Replace the hand rolled stuff with drm_encoder_mask() when populating
possible_clones, and rename the function to
intel_encoder_possible_clones() to make it clear what it's used for.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f09eda75711a..503c20a3a49c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15197,21 +15197,18 @@ int intel_get_pipe_from_crtc_id_ioctl(struct
drm_device *dev, void *data,
return 0;
}
-static int intel_encoder_clones(struct intel_encoder *encoder)
+static u32 intel_encoder_possible_clones(struct intel_encoder *encoder)
{
struct drm_device *dev = encoder->base.dev;
struct intel_encoder *source_encoder;
- int index_mask = 0;
- int entry = 0;
+ u32 possible_clones = 0;
for_each_intel_encoder(dev, source_encoder) {
if (encoders_cloneable(encoder, source_encoder))
- index_mask |= (1 << entry);
-
- entry++;
+ possible_clones |=
drm_encoder_mask(_encoder->base);
}
- return index_mask;
+ return possible_clones;
}
static bool ilk_has_edp_a(struct drm_i915_private *dev_priv)
@@ -15505,7 +15502,7 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
for_each_intel_encoder(_priv->drm, encoder) {
encoder->base.possible_crtcs = encoder->crtc_mask;
encoder->base.possible_clones =
- intel_encoder_clones(encoder);
+ intel_encoder_possible_clones(encoder);
}
intel_init_pch_refclk(dev_priv);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/14] drm/sti: Try to fix up the tvout possible clones
From: Ville Syrjälä The current possible_clones setup doesn't look sensible. I'm assuming the 0 and 1 are supposed to refer to the indexes of the hdmi and hda encoders? So it kinda looks like we want hda+hdmi cloning, but then dvo also claims to be cloneable with hdmi, but hdmi won't recipricate. Benjamin tells me all encoders should be cloneable with each other, so let's fix up the masks to indicate that. Cc: Benjamin Gaignard Cc: Vincent Abriou Acked-by: Benjamin Gaignard Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/sti/sti_tvout.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c index 42f4c264a783..aba79c172512 100644 --- a/drivers/gpu/drm/sti/sti_tvout.c +++ b/drivers/gpu/drm/sti/sti_tvout.c @@ -672,7 +672,6 @@ sti_tvout_create_dvo_encoder(struct drm_device *dev, drm_encoder = >encoder; drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; - drm_encoder->possible_clones = 1 << 0; drm_encoder_init(dev, drm_encoder, _tvout_encoder_funcs, DRM_MODE_ENCODER_LVDS, @@ -725,7 +724,6 @@ static struct drm_encoder *sti_tvout_create_hda_encoder(struct drm_device *dev, drm_encoder = >encoder; drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; - drm_encoder->possible_clones = 1 << 0; drm_encoder_init(dev, drm_encoder, _tvout_encoder_funcs, DRM_MODE_ENCODER_DAC, NULL); @@ -774,7 +772,6 @@ static struct drm_encoder *sti_tvout_create_hdmi_encoder(struct drm_device *dev, drm_encoder = >encoder; drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; - drm_encoder->possible_clones = 1 << 1; drm_encoder_init(dev, drm_encoder, _tvout_encoder_funcs, DRM_MODE_ENCODER_TMDS, NULL); @@ -790,6 +787,13 @@ static void sti_tvout_create_encoders(struct drm_device *dev, tvout->hdmi = sti_tvout_create_hdmi_encoder(dev, tvout); tvout->hda = sti_tvout_create_hda_encoder(dev, tvout); tvout->dvo = sti_tvout_create_dvo_encoder(dev, tvout); + + tvout->hdmi->possible_clones = drm_encoder_mask(tvout->hdmi) | + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); + tvout->hda->possible_clones = drm_encoder_mask(tvout->hdmi) | + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); + tvout->dvo->possible_clones = drm_encoder_mask(tvout->hdmi) | + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); } static void sti_tvout_destroy_encoders(struct sti_tvout *tvout) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/14] drm/sti: Remove pointless casts
From: Ville Syrjälä There's no point in the cast for accessing the base class. Just take the address of the struct instead. Cc: Benjamin Gaignard Cc: Vincent Abriou Acked-by: Benjamin Gaignard Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/sti/sti_tvout.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c index e1b3c8cb7287..42f4c264a783 100644 --- a/drivers/gpu/drm/sti/sti_tvout.c +++ b/drivers/gpu/drm/sti/sti_tvout.c @@ -669,7 +669,7 @@ sti_tvout_create_dvo_encoder(struct drm_device *dev, encoder->tvout = tvout; - drm_encoder = (struct drm_encoder *)encoder; + drm_encoder = >encoder; drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; drm_encoder->possible_clones = 1 << 0; @@ -722,7 +722,7 @@ static struct drm_encoder *sti_tvout_create_hda_encoder(struct drm_device *dev, encoder->tvout = tvout; - drm_encoder = (struct drm_encoder *) encoder; + drm_encoder = >encoder; drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; drm_encoder->possible_clones = 1 << 0; @@ -771,7 +771,7 @@ static struct drm_encoder *sti_tvout_create_hdmi_encoder(struct drm_device *dev, encoder->tvout = tvout; - drm_encoder = (struct drm_encoder *) encoder; + drm_encoder = >encoder; drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; drm_encoder->possible_clones = 1 << 1; -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/14] drm/gma500: Sanitize possible_clones
From: Ville Syrjälä
I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
i915 at least doesn't do those. Truthfully there could be some very
specific circumstances where some of them would do doable, but
genereally it's too much pain to deal with so we've chose not to
bother. Let's use the same approach for gma500.
Also the LVDS+LVDS and DSI+DSI cases probably don't really exist as
there is one of each at most.
This does mean we'll now leave possible_clones at 0 for these encoder
types whereas previosuly we included the encoder itself in the bitmask.
But that's fine as the core now treaks 0 as a special case and adds
the encoder itself into the final bitmask reported to userspace.
Cc: Patrik Jakobsson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/gma500/framebuffer.c | 16
drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 4 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 218f3bb15276..580a701fd91c 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -584,31 +584,31 @@ static void psb_setup_outputs(struct drm_device *dev)
break;
case INTEL_OUTPUT_SDVO:
crtc_mask = dev_priv->ops->sdvo_mask;
- clone_mask = (1 << INTEL_OUTPUT_SDVO);
+ clone_mask = 0;
break;
case INTEL_OUTPUT_LVDS:
- crtc_mask = dev_priv->ops->lvds_mask;
- clone_mask = (1 << INTEL_OUTPUT_LVDS);
+ crtc_mask = dev_priv->ops->lvds_mask;
+ clone_mask = 0;
break;
case INTEL_OUTPUT_MIPI:
crtc_mask = (1 << 0);
- clone_mask = (1 << INTEL_OUTPUT_MIPI);
+ clone_mask = 0;
break;
case INTEL_OUTPUT_MIPI2:
crtc_mask = (1 << 2);
- clone_mask = (1 << INTEL_OUTPUT_MIPI2);
+ clone_mask = 0;
break;
case INTEL_OUTPUT_HDMI:
- crtc_mask = dev_priv->ops->hdmi_mask;
+ crtc_mask = dev_priv->ops->hdmi_mask;
clone_mask = (1 << INTEL_OUTPUT_HDMI);
break;
case INTEL_OUTPUT_DISPLAYPORT:
crtc_mask = (1 << 0) | (1 << 1);
- clone_mask = (1 << INTEL_OUTPUT_DISPLAYPORT);
+ clone_mask = 0;
break;
case INTEL_OUTPUT_EDP:
crtc_mask = (1 << 1);
- clone_mask = (1 << INTEL_OUTPUT_EDP);
+ clone_mask = 0;
}
encoder->possible_crtcs = crtc_mask;
encoder->possible_clones =
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
b/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
index d4c65f268922..187817e0c004 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
@@ -1006,10 +1006,10 @@ struct mdfld_dsi_encoder *mdfld_dsi_dpi_init(struct
drm_device *dev,
/*set possible crtcs and clones*/
if (dsi_connector->pipe) {
encoder->possible_crtcs = (1 << 2);
- encoder->possible_clones = (1 << 1);
+ encoder->possible_clones = 0;
} else {
encoder->possible_crtcs = (1 << 0);
- encoder->possible_clones = (1 << 0);
+ encoder->possible_clones = 0;
}
dsi_connector->base.encoder = _output->base.base;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/14] drm: Try to fix encoder possible_clones/crtc
From: Ville Syrjälä Resurrecting my possible_clones/crtcs cleanup from ~1 year ago. Some prep work from the previous posting did get merged in the meantime. I have a feeling the WARNs from the new validation code may end up triggering on some drivers, but I don't imagine this stuff would get fixed without inflicting a bit of pain. Ville Syrjälä (14): drm: Include the encoder itself in possible_clones drm/gma500: Sanitize possible_clones drm/sti: Remove pointless casts drm/sti: Try to fix up the tvout possible clones drm/exynos: Use drm_encoder_mask() drm/imx: Remove the bogus possible_clones setup drm/i915: Polish possible_clones setup drm/i915: Populate possible_crtcs correctly drm/i915: Fix DP-MST crtc_mask drm/i915: Clean up encoder->crtc_mask setup drm/i915: Simplfy LVDS crtc_mask setup drm/i915: s/crtc_mask/pipe_mask/ drm: Validate encoder->possible_clones drm: Validate encoder->possible_crtcs drivers/gpu/drm/drm_encoder.c| 63 drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 +- drivers/gpu/drm/gma500/framebuffer.c | 16 ++--- drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 4 +- drivers/gpu/drm/i915/display/icl_dsi.c | 2 +- drivers/gpu/drm/i915/display/intel_crt.c | 4 +- drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- drivers/gpu/drm/i915/display/intel_display.c | 28 ++--- drivers/gpu/drm/i915/display/intel_dp.c | 6 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- drivers/gpu/drm/i915/display/intel_dvo.c | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c| 6 +- drivers/gpu/drm/i915/display/intel_lvds.c| 8 +-- drivers/gpu/drm/i915/display/intel_sdvo.c| 2 +- drivers/gpu/drm/i915/display/intel_tv.c | 3 +- drivers/gpu/drm/i915/display/vlv_dsi.c | 6 +- drivers/gpu/drm/i915/intel_drv.h | 5 +- drivers/gpu/drm/imx/imx-drm-core.c | 2 +- drivers/gpu/drm/sti/sti_tvout.c | 16 +++-- 19 files changed, 129 insertions(+), 53 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/14] drm: Include the encoder itself in possible_clones
From: Ville Syrjälä
The docs say possible_clones should always include the encoder itself.
Since most drivers don't want to deal with the complexities of cloning
let's allow them to set possible_clones=0 and instead we'll fix that
up in the core.
We can't put this special case into drm_encoder_init() because drivers
will have to fill up possible_clones after adding all the relevant
encoders. Otherwise they wouldn't know the proper encoder indexes to
use. So we'll just do it just before registering the encoders.
TODO: Should we add the bit even if possible_clones was otherwise
populated by the driver?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_encoder.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 7fb47b7b8b44..e87e6fecc1fb 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -65,11 +65,26 @@ static const struct drm_prop_enum_list
drm_encoder_enum_list[] = {
{ DRM_MODE_ENCODER_DPI, "DPI" },
};
+/*
+ * For some reason we want the encoder itself included in
+ * possible_clones. Make life easy for drivers by allowing them
+ * to leave possible_clones unset if no cloning is possible.
+ */
+static void fixup_possible_clones(struct drm_device *dev)
+{
+ struct drm_encoder *encoder;
+
+ drm_for_each_encoder(encoder, dev)
+ encoder->possible_clones |= drm_encoder_mask(encoder);
+}
+
int drm_encoder_register_all(struct drm_device *dev)
{
struct drm_encoder *encoder;
int ret = 0;
+ fixup_possible_clones(dev);
+
drm_for_each_encoder(encoder, dev) {
if (encoder->funcs->late_register)
ret = encoder->funcs->late_register(encoder);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
