Re: [PATCH v7 1/2] dt-bindings: display: panel: Add bindings for Novatek nt36672a
Hi Sam,
On Thu, 15 Oct 2020 at 00:14, Sam Ravnborg wrote:
>
> Hi Sumit.
> On Wed, Sep 02, 2020 at 12:14:06PM +0530, Sumit Semwal wrote:
> > Novatek nt36672a is a display driver IC that can drive DSI panel. It
> > is also present in the Tianma video mode panel, which is a FHD+ panel
> > with a resolution of 1080x2246 and 6.18 inches size. It is found in
> > some of the Poco F1 phones.
> >
> > This patch adds the display driver for the IC, with support added for
> > this tianma fhd video mode panel.
> >
> > Signed-off-by: Sumit Semwal
> > Reviewed-by: Rob Herring
> Reviewed-by: Sam Ravnborg
> I assume you will apply the patch yourself.
Thanks, I will.
>
> Sam
Best,
Sumit.
> >
> > ---
> > v2: remove ports node, making port@0 directly under panel@0 node.
> > v3: updated to replace port@0 to just 'port'.
> > v5: renamed to novatek,nt36672a, since the binding is for the IC and not
> > the panel.
> > v6: v5 review comments incorporated.
> > - added enum for the compatible part, since it can be extended in
> > future.
> > - few cosmetic updates.
> > ---
> > .../display/panel/novatek,nt36672a.yaml | 87 +++
> > 1 file changed, 87 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> > b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> > new file mode 100644
> > index ..d2170de6b723
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> > @@ -0,0 +1,87 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Novatek NT36672A based DSI display Panels
> > +
> > +maintainers:
> > + - Sumit Semwal
> > +
> > +description: |
> > + The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi
> > + panels.
> > + Right now, support is added only for a Tianma FHD+ LCD display panel
> > with a
> > + resolution of 1080x2246. It is a video mode DSI panel.
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +items:
> > + - enum:
> > + - tianma,fhd-video
> > + - const: novatek,nt36672a
> > +description: This indicates the panel manufacturer of the panel that is
> > + in turn using the NT36672A panel driver. This compatible string
> > + determines how the NT36672A panel driver is configured for the
> > indicated
> > + panel. The novatek,nt36672a compatible shall always be provided as a
> > fallback.
> > +
> > + reset-gpios:
> > +description: phandle of gpio for reset line - This should be 8mA, gpio
> > + can be configured using mux, pinctrl, pinctrl-names (active high)
> > +
> > + vddio-supply:
> > +description: phandle of the regulator that provides the supply voltage
> > + Power IC supply
> > +
> > + vddpos-supply:
> > +description: phandle of the positive boost supply regulator
> > +
> > + vddneg-supply:
> > +description: phandle of the negative boost supply regulator
> > +
> > + reg: true
> > + port: true
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - vddi0-supply
> > + - vddpos-supply
> > + - vddneg-supply
> > + - reset-gpios
> > + - port
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |+
> > +#include
> > +
> > +dsi0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +panel@0 {
> > +compatible = "tianma,fhd-video", "novatek,nt36672a";
> > +reg = <0>;
> > +vddi0-supply = <_l14a_1p88>;
> > +vddpos-supply = <>;
> > +vddneg-supply = <>;
> > +
> > +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> > +
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +port {
> > +tianma_nt36672a_in_0: endpoint {
> > +remote-endpoint = <_out>;
> > +};
> > +};
> > +};
> > +};
> > +
> > +...
> > --
> > 2.28.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next pull for 5.10-rc1
On Thu, 15 Oct 2020 at 11:33, Dave Airlie wrote: > > Hi Linus, > > This is the main drm pull request for 5.10. > > Not a major amount of change, the i915 trees got split into display > and gt trees to better facilitate higher level review, and there's a > major refactoring of i915 GEM locking to use more core kernel concepts > (like ww-mutexes). msm gets per-process pagetables, older AMD SI cards > get DC support, nouveau got a bump in displayport support with common > code extraction from i915. > > There are a bunch of conflicts but none of them seemed overly scary, > and sfr has provided resolutions for them all. I've put a tree up with > my merge results, so you can tell me I did it wrong here: > https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next-5.10-merged Apparently I lied, and I only built my merged tree on x86 https://lore.kernel.org/dri-devel/20201015134357.0a4e6...@canb.auug.org.au/T/#t Please apply the patch from this thread once you merge my tree. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the iommu tree
Hi all,
On Tue, 13 Oct 2020 18:31:07 +1100 Stephen Rothwell
wrote:
>
> On Mon, 21 Sep 2020 14:09:01 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the iommu tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > drivers/gpu/drm/msm/msm_iommu.c: In function 'msm_iommu_pagetable_unmap':
> > drivers/gpu/drm/msm/msm_iommu.c:46:2: error: implicit declaration of
> > function 'iommu_flush_tlb_all'; did you mean 'iommu_flush_iotlb_all'?
> > [-Werror=implicit-function-declaration]
> >46 | iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
> > | ^~~
> > | iommu_flush_iotlb_all
> >
> > Caused by commit
> >
> > aae4c8e27bd7 ("iommu: Rename iommu_tlb_* functions to iommu_iotlb_*")
> >
> > interacting with commit
> >
> > b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
> >
> > from the drm-msm tree.
> >
> > I have applied the following merge fix patch. Someone will need to tell
> > Linus about this fix up when the trees get merged.
> >
> > From: Stephen Rothwell
> > Date: Mon, 21 Sep 2020 14:04:14 +1000
> > Subject: [PATCH] merge fix upt for iommu_flush_iotlb_all() rename
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/gpu/drm/msm/msm_iommu.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_iommu.c
> > b/drivers/gpu/drm/msm/msm_iommu.c
> > index 3a83ffdb3b90..22ac7c692a81 100644
> > --- a/drivers/gpu/drm/msm/msm_iommu.c
> > +++ b/drivers/gpu/drm/msm/msm_iommu.c
> > @@ -43,7 +43,7 @@ static int msm_iommu_pagetable_unmap(struct msm_mmu *mmu,
> > u64 iova,
> > size -= 4096;
> > }
> >
> > - iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
> > + iommu_flush_iotlb_all(to_msm_iommu(pagetable->parent)->domain);
> >
> > return (unmapped == size) ? 0 : -EINVAL;
> > }
> > @@ -199,7 +199,7 @@ struct msm_mmu *msm_iommu_pagetable_create(struct
> > msm_mmu *parent)
> >
> > /*
> > * TODO we would like each set of page tables to have a unique ASID
> > -* to optimize TLB invalidation. But iommu_flush_tlb_all() will
> > +* to optimize TLB invalidation. But iommu_flush_iotlb_all() will
> > * end up flushing the ASID used for TTBR1 pagetables, which is not
> > * what we want. So for now just use the same ASID as TTBR1.
> > */
> > --
> > 2.28.0
>
> This merge fix up is now needed when the iommu tree and the drm tree are
> merged.
This merge fix up is now needed when the drm tree is merged with Linus' tree.
--
Cheers,
Stephen Rothwell
pgp6aXZMIIDc0.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: add missing newline at eof
On Wed, Oct 14, 2020 at 5:18 PM wrote: > > From: Tom Rix > > Representative checkpatch.pl warning > > WARNING: adding a line without newline at end of file > 30: FILE: drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.h:30: > +#endif > > Signed-off-by: Tom Rix Applied. Thanks! Alex > --- > drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_1_sh_mask.h | 2 +- > drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_1_sh_mask.h > b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_1_sh_mask.h > index f26246a600c6..4089cfa081f5 100644 > --- a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_1_sh_mask.h > +++ b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_1_sh_mask.h > @@ -745,4 +745,4 @@ > #define RLC_EDC_CNT2__RLC_SPM_SE7_SCRATCH_RAM_SEC_COUNT_MASK > 0x3000L > #define RLC_EDC_CNT2__RLC_SPM_SE7_SCRATCH_RAM_DED_COUNT_MASK > 0xC000L > > -#endif > \ No newline at end of file > +#endif > diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.h > b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.h > index 29929b360db8..d8696e2274c4 100644 > --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.h > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.h > @@ -27,4 +27,4 @@ > > extern void vangogh_set_ppt_funcs(struct smu_context *smu); > > -#endif > \ No newline at end of file > +#endif > -- > 2.18.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/5] RDMA/umem: Support importing dma-buf as user memory region
Hi Jianxin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on rdma/for-next] [also build test WARNING on tegra-drm/drm/tegra/for-next v5.9 next-20201013] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Jianxin-Xiong/RDMA-Add-dma-buf-support/20201015-000352 base: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git for-next config: powerpc-randconfig-r006-20201014 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project e7fe3c6dfede8d5781bd000741c3dea7088307a4) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu # https://github.com/0day-ci/linux/commit/2990dd070526adeeccee2db6d465b8e1ca33a967 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Jianxin-Xiong/RDMA-Add-dma-buf-support/20201015-000352 git checkout 2990dd070526adeeccee2db6d465b8e1ca33a967 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:43:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insb, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :36:1: note: expanded from here __do_insb ^ arch/powerpc/include/asm/io.h:541:56: note: expanded from macro '__do_insb' #define __do_insb(p, b, n) readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/infiniband/core/umem_dmabuf.c:6: In file included from include/linux/dma-buf.h:18: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :41:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/infiniband/core/umem_dmabuf.c:6: In file included from include/linux/dma-buf.h:18: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :46:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/infiniband/core/umem_dmabuf.c:6: In file included from include/linux/dma-buf.h:18: In file included from include/linux/scatterlist.h:9: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c), ^~ arch/powerpc/i
[PATCH] drm/amdgpu: add missing newline at eof
From: Tom Rix Representative checkpatch.pl warning WARNING: adding a line without newline at end of file 30: FILE: drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.h:30: +#endif Signed-off-by: Tom Rix --- drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_1_sh_mask.h | 2 +- drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_1_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_1_sh_mask.h index f26246a600c6..4089cfa081f5 100644 --- a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_1_sh_mask.h +++ b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_1_sh_mask.h @@ -745,4 +745,4 @@ #define RLC_EDC_CNT2__RLC_SPM_SE7_SCRATCH_RAM_SEC_COUNT_MASK 0x3000L #define RLC_EDC_CNT2__RLC_SPM_SE7_SCRATCH_RAM_DED_COUNT_MASK 0xC000L -#endif \ No newline at end of file +#endif diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.h b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.h index 29929b360db8..d8696e2274c4 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.h +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.h @@ -27,4 +27,4 @@ extern void vangogh_set_ppt_funcs(struct smu_context *smu); -#endif \ No newline at end of file +#endif -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209457] AMDGPU resume fail with RX 580 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209457 --- Comment #9 from Robert M. Muncrief (rmuncr...@humanavance.com) --- The same type of problem also occurred when I had my old R9-390 and GT 710 GPUs, FX-6300 CPU, and Gigabyte GA-990FXA-UD5 motherboard. However if I put the GT 710 in the primary PCIE slot the resume problem never occurred. I can't be certain it was the exact same problem though, because there were a lot of AMDGPU resume problems and I just assumed it was because the hardware I had was so old. And since my R9 390 AMDGPU support was considered experimental I figured I had to live with the issue. So I really hoped it would go away when I got my two new RX 580 GPUs, R7 3700X CPU, and X570 motherboard, but unfortunately the resume problem still occurs. And I gave away my GT 710 so I can't check to see if it still alleviates the issue. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209457] AMDGPU resume fail with RX 580 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209457 --- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) --- [ 3399.070651] pcieport :03:02.0: can't change power state from D3hot to D0 (config space inaccessible) [ 3399.073473] amdgpu :05:00.0: can't change power state from D3hot to D0 (config space inaccessible) [ 3399.136581] snd_hda_intel :05:00.1: can't change power state from D3hot to D0 (config space inaccessible) Seems like the card never gets powered back up by the platform on resume. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209457] AMDGPU resume fail with RX 580 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209457 --- Comment #7 from Robert M. Muncrief (rmuncr...@humanavance.com) --- This bug still persists with kernel 5.9.0. I didn't attach new logs because the bug output is identical to the 5.8 kernel series. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, amdkfd drm-fixes-5.10
Hi Dave, Daniel,
Fixes for 5.10.
The following changes since commit 9c27bc97aff8bbe62b5b29ebf528291dd85d9c86:
drm/amdgpu: Fix invalid number of character '{' in amdgpu_acpi_init
(2020-10-09 15:16:10 -0400)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.10-2020-10-14
for you to fetch changes up to 8f4729e880647c419de0bbe3ff21d7efb4e65676:
drm/amdkfd: Use kvfree in destroy_crat_image (2020-10-14 15:29:28 -0400)
amd-drm-fixes-5.10-2020-10-14:
amdgpu:
- eDP fix
- BACO fix
- Kernel documentation fixes
- SMU7 mclk fix
- VCN1 hw bug workaround
amdkfd:
- kvfree vs kfree fix
Alex Deucher (1):
drm/amdgpu/swsmu: init the baco mutex in early_init
Evan Quan (1):
drm/amd/pm: increase mclk switch threshold to 200 us
Kent Russell (1):
drm/amdkfd: Use kvfree in destroy_crat_image
Mauro Carvalho Chehab (2):
drm/amd/display: kernel-doc: document force_timing_sync
docs: amdgpu: fix a warning when building the documentation
Rodrigo Siqueira (1):
drm/amd/display: Fix module load hangs when connected to an eDP
Veerabadhran G (1):
drm/amdgpu: vcn and jpeg ring synchronization
Documentation/gpu/amdgpu.rst | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h| 1 +
drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c | 24 +--
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 28 ++
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.h | 3 ++-
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 ++
drivers/gpu/drm/amd/display/dc/core/dc.c | 10
.../gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c| 2 +-
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 7 +++---
11 files changed, 65 insertions(+), 20 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] drm: panel: Add novatek nt36672a panel driver
Hi Sumit. On Wed, Sep 02, 2020 at 12:14:07PM +0530, Sumit Semwal wrote: > Novatek NT36672a is a generic DSI IC that drives command and video mode > panels. Add the driver for it. > > Right now adding support for some Poco F1 phones that have an LCD panel > from Tianma connected with this IC, with a resolution of 1080x2246 that > operates in DSI video mode. > > During testing, Benni Steini helped us fix > the reset sequence timing (from 10ms to 20ms), to get the bootanimation > to work on Android. > > With current AOSP, we need to increase it to 200ms - this seems to be a > safe high value to avoid a white screen occasionally. > > Signed-off-by: Sumit Semwal > Cc: Benni Steini Reviewed-by: Sam Ravnborg I assume you will apply the patch yourself to drm-misc-next. Sam > > --- > v2: increase reset sequence timing to a safe 200ms > v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate > vrefresh on demand. Update for it. > v5: Fixed review comments from Sam: > - rebased on top of drm-misc-next >remove return of drm_panel_add() >remove drm_panel_detach() > - renamed the panel driver file to reflect that this is a novatek >nt36672a display driver and not only for tianma panels. >Adjusted some internal names also to reflect the same. > - corrected changelog to add info about the generic Novatek DSI IC > - corrected compatible string accordingly > - removed pinctrl > - used drm_panel* API for prepare/unprepare/disable/remove > v6: Fixed few review comments on v5 from Sam: > - add dev_err_probe() support > - move DRM_* error printing to dev_err() > - removed a few unnecessary bits > v7: Fixed review comments on v6 from Bjorn: > - Reworked the send_mipi_commands functionality > - removed regulator disable_loads; moved active_load setting to probe > time > - made function names and struct less generic > - updated the reset_gpio working to active_low > - update MAINTAINERS for file name changes > --- > MAINTAINERS | 7 + > drivers/gpu/drm/panel/Kconfig | 10 + > drivers/gpu/drm/panel/Makefile| 1 + > .../gpu/drm/panel/panel-novatek-nt36672a.c| 711 ++ > 4 files changed, 729 insertions(+) > create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 01fb9ee6b951..c6fb966c0959 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5517,6 +5517,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > F: Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml > F: drivers/gpu/drm/panel/panel-novatek-nt35510.c > > +DRM DRIVER FOR NOVATEK NT36672A PANELS > +M: Sumit Semwal > +S: Maintained > +T: git git://anongit.freedesktop.org/drm/drm-misc > +F: Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml > +F: drivers/gpu/drm/panel/panel-novatek-nt36672a.c > + > DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS > M: Ben Skeggs > L: dri-devel@lists.freedesktop.org > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index 8d97d07c5871..51e6cb6c7826 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -208,6 +208,16 @@ config DRM_PANEL_NOVATEK_NT35510 > around the Novatek NT35510 display controller, such as some > Hydis panels. > > +config DRM_PANEL_NOVATEK_NT36672A > + tristate "Novatek NT36672A DSI panel" > + depends on OF > + depends on DRM_MIPI_DSI > + depends on BACKLIGHT_CLASS_DEVICE > + help > + Say Y here if you want to enable support for the panels built > + around the Novatek NT36672A display controller, such as some > + Tianma panels used in a few Xiaomi Poco F1 mobile phones. > + > config DRM_PANEL_NOVATEK_NT39016 > tristate "Novatek NT39016 RGB/SPI panel" > depends on OF && SPI > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > index 15a4e7752951..4a36eb45f670 100644 > --- a/drivers/gpu/drm/panel/Makefile > +++ b/drivers/gpu/drm/panel/Makefile > @@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o > obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o > obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o > +obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o > obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o > obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o > diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > new file mode 100644 > index ..533cd3934b8b > ---
Re: [PATCH v7 1/2] dt-bindings: display: panel: Add bindings for Novatek nt36672a
Hi Sumit.
On Wed, Sep 02, 2020 at 12:14:06PM +0530, Sumit Semwal wrote:
> Novatek nt36672a is a display driver IC that can drive DSI panel. It
> is also present in the Tianma video mode panel, which is a FHD+ panel
> with a resolution of 1080x2246 and 6.18 inches size. It is found in
> some of the Poco F1 phones.
>
> This patch adds the display driver for the IC, with support added for
> this tianma fhd video mode panel.
>
> Signed-off-by: Sumit Semwal
> Reviewed-by: Rob Herring
Reviewed-by: Sam Ravnborg
I assume you will apply the patch yourself.
Sam
>
> ---
> v2: remove ports node, making port@0 directly under panel@0 node.
> v3: updated to replace port@0 to just 'port'.
> v5: renamed to novatek,nt36672a, since the binding is for the IC and not
> the panel.
> v6: v5 review comments incorporated.
> - added enum for the compatible part, since it can be extended in
> future.
> - few cosmetic updates.
> ---
> .../display/panel/novatek,nt36672a.yaml | 87 +++
> 1 file changed, 87 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> new file mode 100644
> index ..d2170de6b723
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> @@ -0,0 +1,87 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Novatek NT36672A based DSI display Panels
> +
> +maintainers:
> + - Sumit Semwal
> +
> +description: |
> + The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi
> + panels.
> + Right now, support is added only for a Tianma FHD+ LCD display panel with a
> + resolution of 1080x2246. It is a video mode DSI panel.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - tianma,fhd-video
> + - const: novatek,nt36672a
> +description: This indicates the panel manufacturer of the panel that is
> + in turn using the NT36672A panel driver. This compatible string
> + determines how the NT36672A panel driver is configured for the
> indicated
> + panel. The novatek,nt36672a compatible shall always be provided as a
> fallback.
> +
> + reset-gpios:
> +description: phandle of gpio for reset line - This should be 8mA, gpio
> + can be configured using mux, pinctrl, pinctrl-names (active high)
> +
> + vddio-supply:
> +description: phandle of the regulator that provides the supply voltage
> + Power IC supply
> +
> + vddpos-supply:
> +description: phandle of the positive boost supply regulator
> +
> + vddneg-supply:
> +description: phandle of the negative boost supply regulator
> +
> + reg: true
> + port: true
> +
> +required:
> + - compatible
> + - reg
> + - vddi0-supply
> + - vddpos-supply
> + - vddneg-supply
> + - reset-gpios
> + - port
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |+
> +#include
> +
> +dsi0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel@0 {
> +compatible = "tianma,fhd-video", "novatek,nt36672a";
> +reg = <0>;
> +vddi0-supply = <_l14a_1p88>;
> +vddpos-supply = <>;
> +vddneg-supply = <>;
> +
> +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> +
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port {
> +tianma_nt36672a_in_0: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +};
> +
> +...
> --
> 2.28.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/5] RDMA/uverbs: Add uverbs command for dma-buf based MR registration
Implement a new uverbs ioctl method for memory registration with file
descriptor as an extra parameter.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
---
drivers/infiniband/core/uverbs_std_types_mr.c | 112 ++
include/uapi/rdma/ib_user_ioctl_cmds.h| 14
2 files changed, 126 insertions(+)
diff --git a/drivers/infiniband/core/uverbs_std_types_mr.c
b/drivers/infiniband/core/uverbs_std_types_mr.c
index 9b22bb5..e54459f 100644
--- a/drivers/infiniband/core/uverbs_std_types_mr.c
+++ b/drivers/infiniband/core/uverbs_std_types_mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -178,6 +179,85 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_MR)(
return IS_UVERBS_COPY_ERR(ret) ? ret : 0;
}
+static int UVERBS_HANDLER(UVERBS_METHOD_REG_DMABUF_MR)(
+ struct uverbs_attr_bundle *attrs)
+{
+ struct ib_uobject *uobj =
+ uverbs_attr_get_uobject(attrs,
UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
+ struct ib_pd *pd =
+ uverbs_attr_get_obj(attrs, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE);
+ struct ib_device *ib_dev = pd->device;
+
+ u64 start, length, virt_addr;
+ u32 fd, access_flags;
+ struct ib_mr *mr;
+ int ret;
+
+ if (!ib_dev->ops.reg_user_mr_dmabuf)
+ return -EOPNOTSUPP;
+
+ ret = uverbs_copy_from(, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_ADDR);
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_from(, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_LENGTH);
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_from(_addr, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_HCA_VA);
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_from(, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_FD);
+ if (ret)
+ return ret;
+
+ ret = uverbs_get_flags32(_flags, attrs,
+UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
+IB_ACCESS_SUPPORTED);
+ if (ret)
+ return ret;
+
+ ret = ib_check_mr_access(access_flags);
+ if (ret)
+ return ret;
+
+ mr = pd->device->ops.reg_user_mr_dmabuf(pd, start, length, virt_addr,
+ fd, access_flags,
+ >driver_udata);
+ if (IS_ERR(mr))
+ return PTR_ERR(mr);
+
+ mr->device = pd->device;
+ mr->pd = pd;
+ mr->type= IB_MR_TYPE_USER;
+ mr->uobject = uobj;
+ atomic_inc(>usecnt);
+
+ uobj->object = mr;
+
+ ret = uverbs_copy_to(attrs, UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY,
+>lkey, sizeof(mr->lkey));
+ if (ret)
+ goto err_dereg;
+
+ ret = uverbs_copy_to(attrs, UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY,
+>rkey, sizeof(mr->rkey));
+ if (ret)
+ goto err_dereg;
+
+ return 0;
+
+err_dereg:
+ ib_dereg_mr_user(mr, uverbs_get_cleared_udata(attrs));
+
+ return ret;
+}
+
DECLARE_UVERBS_NAMED_METHOD(
UVERBS_METHOD_ADVISE_MR,
UVERBS_ATTR_IDR(UVERBS_ATTR_ADVISE_MR_PD_HANDLE,
@@ -243,6 +323,37 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_MR)(
UVERBS_ATTR_TYPE(u32),
UA_MANDATORY));
+DECLARE_UVERBS_NAMED_METHOD(
+ UVERBS_METHOD_REG_DMABUF_MR,
+ UVERBS_ATTR_IDR(UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ UVERBS_OBJECT_MR,
+ UVERBS_ACCESS_NEW,
+ UA_MANDATORY),
+ UVERBS_ATTR_IDR(UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE,
+ UVERBS_OBJECT_PD,
+ UVERBS_ACCESS_READ,
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_ADDR,
+ UVERBS_ATTR_TYPE(u64),
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_LENGTH,
+ UVERBS_ATTR_TYPE(u64),
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_HCA_VA,
+ UVERBS_ATTR_TYPE(u64),
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_FD,
+ UVERBS_ATTR_TYPE(u32),
+ UA_MANDATORY),
+ UVERBS_ATTR_FLAGS_IN(UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
+enum ib_access_flags),
+
[PATCH v4 2/5] RDMA/core: Add device method for registering dma-buf base memory region
Dma-buf based memory region requires one extra parameter and is processed
quite differently. Adding a separate method allows clean separation from
regular memory regions.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
---
drivers/infiniband/core/device.c | 1 +
include/rdma/ib_verbs.h | 6 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index feaec8d..d6cd0ac 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -2653,6 +2653,7 @@ void ib_set_device_ops(struct ib_device *dev, const
struct ib_device_ops *ops)
SET_DEVICE_OP(dev_ops, read_counters);
SET_DEVICE_OP(dev_ops, reg_dm_mr);
SET_DEVICE_OP(dev_ops, reg_user_mr);
+ SET_DEVICE_OP(dev_ops, reg_user_mr_dmabuf);
SET_DEVICE_OP(dev_ops, req_ncomp_notif);
SET_DEVICE_OP(dev_ops, req_notify_cq);
SET_DEVICE_OP(dev_ops, rereg_user_mr);
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 9bf6c31..48bab74 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -2,7 +2,7 @@
/*
* Copyright (c) 2004 Mellanox Technologies Ltd. All rights reserved.
* Copyright (c) 2004 Infinicon Corporation. All rights reserved.
- * Copyright (c) 2004 Intel Corporation. All rights reserved.
+ * Copyright (c) 2004, 2020 Intel Corporation. All rights reserved.
* Copyright (c) 2004 Topspin Corporation. All rights reserved.
* Copyright (c) 2004 Voltaire Corporation. All rights reserved.
* Copyright (c) 2005 Sun Microsystems, Inc. All rights reserved.
@@ -2429,6 +2429,10 @@ struct ib_device_ops {
struct ib_mr *(*reg_user_mr)(struct ib_pd *pd, u64 start, u64 length,
u64 virt_addr, int mr_access_flags,
struct ib_udata *udata);
+ struct ib_mr *(*reg_user_mr_dmabuf)(struct ib_pd *pd, u64 start,
+u64 length, u64 virt_addr, int dmabuf_fd,
+int mr_access_flags,
+struct ib_udata *udata);
int (*rereg_user_mr)(struct ib_mr *mr, int flags, u64 start, u64 length,
u64 virt_addr, int mr_access_flags,
struct ib_pd *pd, struct ib_udata *udata);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] RDMA/umem: Support importing dma-buf as user memory region
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a property associated with the
buffer allocation. When the buffer is registered as a memory region,
the file descriptor is passed to the RDMA driver along with other
parameters.
Implement the common code for importing dma-buf object and mapping
dma-buf pages.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
---
drivers/infiniband/core/Makefile | 2 +-
drivers/infiniband/core/umem.c| 4 +
drivers/infiniband/core/umem_dmabuf.c | 200 ++
drivers/infiniband/core/umem_dmabuf.h | 11 ++
include/rdma/ib_umem.h| 32 +-
5 files changed, 247 insertions(+), 2 deletions(-)
create mode 100644 drivers/infiniband/core/umem_dmabuf.c
create mode 100644 drivers/infiniband/core/umem_dmabuf.h
diff --git a/drivers/infiniband/core/Makefile b/drivers/infiniband/core/Makefile
index ccf2670..8ab4eea 100644
--- a/drivers/infiniband/core/Makefile
+++ b/drivers/infiniband/core/Makefile
@@ -40,5 +40,5 @@ ib_uverbs-y :=uverbs_main.o
uverbs_cmd.o uverbs_marshall.o \
uverbs_std_types_srq.o \
uverbs_std_types_wq.o \
uverbs_std_types_qp.o
-ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
+ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o umem_dmabuf.o
ib_uverbs-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index e9fecbd..8c608a5 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -2,6 +2,7 @@
* Copyright (c) 2005 Topspin Communications. All rights reserved.
* Copyright (c) 2005 Cisco Systems. All rights reserved.
* Copyright (c) 2005 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -43,6 +44,7 @@
#include
#include "uverbs.h"
+#include "umem_dmabuf.h"
static void __ib_umem_release(struct ib_device *dev, struct ib_umem *umem, int
dirty)
{
@@ -269,6 +271,8 @@ void ib_umem_release(struct ib_umem *umem)
{
if (!umem)
return;
+ if (umem->is_dmabuf)
+ return ib_umem_dmabuf_release(umem);
if (umem->is_odp)
return ib_umem_odp_release(to_ib_umem_odp(umem));
diff --git a/drivers/infiniband/core/umem_dmabuf.c
b/drivers/infiniband/core/umem_dmabuf.c
new file mode 100644
index 000..4f2303e
--- /dev/null
+++ b/drivers/infiniband/core/umem_dmabuf.c
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+/*
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+
+#include "uverbs.h"
+
+struct ib_umem_dmabuf {
+ struct ib_umem umem;
+ struct dma_buf_attachment *attach;
+ struct sg_table *sgt;
+ const struct ib_umem_dmabuf_ops *ops;
+ void *device_context;
+ struct work_struct work;
+};
+
+static inline struct ib_umem_dmabuf *to_ib_umem_dmabuf(struct ib_umem *umem)
+{
+ return container_of(umem, struct ib_umem_dmabuf, umem);
+}
+
+int ib_umem_dmabuf_map_pages(struct ib_umem *umem, bool first)
+{
+ struct ib_umem_dmabuf *umem_dmabuf = to_ib_umem_dmabuf(umem);
+ struct sg_table *sgt;
+ struct dma_fence *fence;
+ int err;
+
+ dma_resv_lock(umem_dmabuf->attach->dmabuf->resv, NULL);
+
+ sgt = dma_buf_map_attachment(umem_dmabuf->attach,
+DMA_BIDIRECTIONAL);
+
+ if (IS_ERR(sgt)) {
+ dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
+ return PTR_ERR(sgt);
+ }
+
+ umem_dmabuf->umem.sg_head = *sgt;
+ umem_dmabuf->umem.nmap = sgt->nents;
+ umem_dmabuf->sgt = sgt;
+
+ fence = dma_resv_get_excl(umem_dmabuf->attach->dmabuf->resv);
+ if (fence)
+ dma_fence_wait(fence, false);
+
+ if (first)
+ err = umem_dmabuf->ops->init(umem,
+umem_dmabuf->device_context);
+ else
+ err = umem_dmabuf->ops->update(umem,
+ umem_dmabuf->device_context);
+
+ dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
+ return err;
+}
+
+int ib_umem_dmabuf_init_mapping(struct ib_umem *umem, void *device_context)
+{
+ struct ib_umem_dmabuf *umem_dmabuf = to_ib_umem_dmabuf(umem);
+
+ umem_dmabuf->device_context = device_context;
+ return ib_umem_dmabuf_map_pages(umem, true);
+}
[PATCH v4 5/5] dma-buf: Clarify that dma-buf sg lists are page aligned
The dma-buf API have been used under the assumption that the sg lists
returned from dma_buf_map_attachment() are fully page aligned. Lots of
stuff can break otherwise all over the place. Clarify this in the
documentation and add a check when DMA API debug is enabled.
Signed-off-by: Jianxin Xiong
---
drivers/dma-buf/dma-buf.c | 21 +
include/linux/dma-buf.h | 3 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 844967f..7309c83 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -851,6 +851,9 @@ void dma_buf_unpin(struct dma_buf_attachment *attach)
* Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
* on error. May return -EINTR if it is interrupted by a signal.
*
+ * On success, the DMA addresses and lengths in the returned scatterlist are
+ * PAGE_SIZE aligned.
+ *
* A mapping must be unmapped by using dma_buf_unmap_attachment(). Note that
* the underlying backing storage is pinned for as long as a mapping exists,
* therefore users/importers should not hold onto a mapping for undue amounts
of
@@ -904,6 +907,24 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
attach->dir = direction;
}
+#ifdef CONFIG_DMA_API_DEBUG
+ {
+ struct scatterlist *sg;
+ u64 addr;
+ int len;
+ int i;
+
+ for_each_sgtable_dma_sg(sg_table, sg, i) {
+ addr = sg_dma_address(sg);
+ len = sg_dma_len(sg);
+ if (!PAGE_ALIGNED(addr) || !PAGE_ALIGNED(len)) {
+ pr_debug("%s: addr %llx or len %x is not page
aligned!\n",
+__func__, addr, len);
+ }
+ }
+ }
+#endif /* CONFIG_DMA_API_DEBUG */
+
return sg_table;
}
EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index a2ca294e..4a5fa70 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -145,7 +145,8 @@ struct dma_buf_ops {
*
* A _table scatter list of or the backing storage of the DMA buffer,
* already mapped into the device address space of the attached
-* with the provided _buf_attachment.
+* with the provided _buf_attachment. The addresses and lengths in
+* the scatter list are PAGE_SIZE aligned.
*
* On failure, returns a negative error value wrapped into a pointer.
* May also return -EINTR when a signal was received while being
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/5] RDMA/mlx5: Support dma-buf based userspace memory region
Implement the new driver method 'reg_user_mr_dmabuf'. Utilize the core
functions to import dma-buf based memory region and update the mappings.
Add code to handle dma-buf related page fault.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
---
drivers/infiniband/hw/mlx5/main.c| 2 +
drivers/infiniband/hw/mlx5/mlx5_ib.h | 5 ++
drivers/infiniband/hw/mlx5/mr.c | 119 +++
drivers/infiniband/hw/mlx5/odp.c | 42 +
4 files changed, 168 insertions(+)
diff --git a/drivers/infiniband/hw/mlx5/main.c
b/drivers/infiniband/hw/mlx5/main.c
index 89e04ca..ec4ad2f 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
/*
* Copyright (c) 2013-2020, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*/
#include
@@ -4060,6 +4061,7 @@ static int mlx5_ib_enable_driver(struct ib_device *dev)
.query_srq = mlx5_ib_query_srq,
.query_ucontext = mlx5_ib_query_ucontext,
.reg_user_mr = mlx5_ib_reg_user_mr,
+ .reg_user_mr_dmabuf = mlx5_ib_reg_user_mr_dmabuf,
.req_notify_cq = mlx5_ib_arm_cq,
.rereg_user_mr = mlx5_ib_rereg_user_mr,
.resize_cq = mlx5_ib_resize_cq,
diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h
b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index b1f2b34..65fcc18 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB */
/*
* Copyright (c) 2013-2020, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*/
#ifndef MLX5_IB_H
@@ -1174,6 +1175,10 @@ int mlx5_ib_create_cq(struct ib_cq *ibcq, const struct
ib_cq_init_attr *attr,
struct ib_mr *mlx5_ib_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
u64 virt_addr, int access_flags,
struct ib_udata *udata);
+struct ib_mr *mlx5_ib_reg_user_mr_dmabuf(struct ib_pd *pd, u64 start,
+u64 length, u64 virt_addr,
+int dmabuf_fd, int access_flags,
+struct ib_udata *udata);
int mlx5_ib_advise_mr(struct ib_pd *pd,
enum ib_uverbs_advise_mr_advice advice,
u32 flags,
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index b261797..24750f1 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2013-2015, Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -1462,6 +1463,124 @@ struct ib_mr *mlx5_ib_reg_user_mr(struct ib_pd *pd, u64
start, u64 length,
return ERR_PTR(err);
}
+static int mlx5_ib_umem_dmabuf_xlt_init(struct ib_umem *umem, void *context)
+{
+ struct mlx5_ib_mr *mr = context;
+ int flags = MLX5_IB_UPD_XLT_ENABLE;
+
+ if (!mr)
+ return -EINVAL;
+
+ return mlx5_ib_update_xlt(mr, 0, mr->npages, PAGE_SHIFT, flags);
+}
+
+static int mlx5_ib_umem_dmabuf_xlt_update(struct ib_umem *umem, void *context)
+{
+ struct mlx5_ib_mr *mr = context;
+ int flags = MLX5_IB_UPD_XLT_ATOMIC;
+
+ if (!mr)
+ return -EINVAL;
+
+ return mlx5_ib_update_xlt(mr, 0, mr->npages, PAGE_SHIFT, flags);
+}
+
+static int mlx5_ib_umem_dmabuf_xlt_invalidate(struct ib_umem *umem, void
*context)
+{
+ struct mlx5_ib_mr *mr = context;
+ int flags = MLX5_IB_UPD_XLT_ZAP | MLX5_IB_UPD_XLT_ATOMIC;
+
+ if (!mr)
+ return -EINVAL;
+
+ return mlx5_ib_update_xlt(mr, 0, mr->npages, PAGE_SHIFT, flags);
+}
+
+static struct ib_umem_dmabuf_ops mlx5_ib_umem_dmabuf_ops = {
+ .init = mlx5_ib_umem_dmabuf_xlt_init,
+ .update = mlx5_ib_umem_dmabuf_xlt_update,
+ .invalidate = mlx5_ib_umem_dmabuf_xlt_invalidate,
+};
+
+struct ib_mr *mlx5_ib_reg_user_mr_dmabuf(struct ib_pd *pd, u64 start,
+u64 length, u64 virt_addr,
+int dmabuf_fd, int access_flags,
+struct ib_udata *udata)
+{
+ struct mlx5_ib_dev *dev = to_mdev(pd->device);
+ struct mlx5_ib_mr *mr = NULL;
+ struct ib_umem *umem;
+ int page_shift;
+ int npages;
+ int ncont;
+ int order;
+ int err;
+
+ if (!IS_ENABLED(CONFIG_INFINIBAND_USER_MEM))
+ return ERR_PTR(-EOPNOTSUPP);
+
+ mlx5_ib_dbg(dev,
+ "start 0x%llx,
[PATCH v4 0/5] RDMA: Add dma-buf support
This is the fourth version of the patch set. Changelog: v4: * Add a new ib_device method reg_user_mr_dmabuf() instead of expanding the existing method reg_user_mr() * Use a separate code flow for dma-buf instead of adding special cases to the ODP memory region code path * In invalidation callback, new mapping is updated as whole using work queue instead of being updated in page granularity in the page fault handler * Use dma_resv_get_excl() and dma_fence_wait() to ensure the content of the pages have been moved to the new location before the new mapping is programmed into the NIC * Add code to the ODP page fault handler to check the mapping status * The new access flag added in v3 is removed. * The checking for on-demand paging support in the new uverbs command is removed because it is implied by implementing the new ib_device method * Clarify that dma-buf sg lists are page aligned v3: https://www.spinics.net/lists/linux-rdma/msg96330.html * Use dma_buf_dynamic_attach() instead of dma_buf_attach() * Use on-demand paging mechanism to avoid pinning the GPU memory * Instead of adding a new parameter to the device method for memory registration, pass all the attributes including the file descriptor as a structure * Define a new access flag for dma-buf based memory region * Check for on-demand paging support in the new uverbs command v2: https://www.spinics.net/lists/linux-rdma/msg93643.html * The Kconfig option is removed. There is no dependence issue since dma-buf driver is always enabled. * The declaration of new data structure and functions is reorganized to minimize the visibility of the changes. * The new uverbs command now goes through ioctl() instead of write(). * The rereg functionality is removed. * Instead of adding new device method for dma-buf specific registration, existing method is extended to accept an extra parameter. * The correct function is now used for address range checking. v1: https://www.spinics.net/lists/linux-rdma/msg90720.html * The initial patch set * Implement core functions for importing and mapping dma-buf * Use dma-buf static attach interface * Add two ib_device methods reg_user_mr_fd() and rereg_user_mr_fd() * Add two uverbs commands via the write() interface * Add Kconfig option * Add dma-buf support to mlx5 device When enabled, an RDMA capable NIC can perform peer-to-peer transactions over PCIe to access the local memory located on another device. This can often lead to better performance than using a system memory buffer for RDMA and copying data between the buffer and device memory. Current kernel RDMA stack uses get_user_pages() to pin the physical pages backing the user buffer and uses dma_map_sg_attrs() to get the dma addresses for memory access. This usually doesn't work for peer device memory due to the lack of associated page structures. Several mechanisms exist today to facilitate device memory access. ZONE_DEVICE is a new zone for device memory in the memory management subsystem. It allows pages from device memory being described with specialized page structures, but what can be done with these page structures may be different from system memory. ZONE_DEVICE is further specialized into multiple memory types, such as one type for PCI p2pmem/p2pdma and one type for HMM. PCI p2pmem/p2pdma uses ZONE_DEVICE to represent device memory residing in a PCI BAR and provides a set of calls to publish, discover, allocate, and map such memory for peer-to-peer transactions. One feature of the API is that the buffer is allocated by the side that does the DMA transfer. This works well with the storage usage case, but is awkward with GPU-NIC communication, where typically the buffer is allocated by the GPU driver rather than the NIC driver. Heterogeneous Memory Management (HMM) utilizes mmu_interval_notifier and ZONE_DEVICE to support shared virtual address space and page migration between system memory and device memory. HMM doesn't support pinning device memory because pages located on device must be able to migrate to system memory when accessed by CPU. Peer-to-peer access is currently not supported by HMM. Dma-buf is a standard mechanism for sharing buffers among different device drivers. The buffer to be shared is exported by the owning driver and imported by the driver that wants to use it. The exporter provides a set of ops that the importer can call to pin and map the buffer. In addition, a file descriptor can be associated with a dma- buf object as the handle that can be passed to user space. This patch series adds dma-buf importer role to the RDMA driver in attempt to support RDMA using device memory such as GPU VRAM. Dma-buf is chosen for a few reasons: first, the API is relatively simple and allows a lot of flexibility in implementing the buffer manipulation ops. Second, it doesn't require page structure. Third, dma-buf is already supported in many GPU drivers. However, we are aware that existing GPU drivers don't allow pinning
Re: [v1] drm/msm: Fix race condition in msm driver with async layer updates
On Wed, Oct 14, 2020 at 5:58 AM Krishna Manikandan
wrote:
>
> When there are back to back commits with async cursor update,
> there is a case where second commit can program the DPU hw
> blocks while first didn't complete flushing config to HW.
>
> Synchronize the compositions such that second commit waits
> until first commit flushes the composition.
>
> This change also introduces per crtc commit lock, such that
> commits on different crtcs are not blocked by each other.
>
> Signed-off-by: Krishna Manikandan
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 26
> drivers/gpu/drm/msm/msm_atomic.c | 35
> ++--
> drivers/gpu/drm/msm/msm_kms.h| 5 +
> 5 files changed, 57 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index c2729f7..9024719 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -1383,6 +1383,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
> struct drm_plane *plane,
>
> /* initialize event handling */
> spin_lock_init(_crtc->event_lock);
> + mutex_init(_crtc->commit_lock);
>
> DPU_DEBUG("%s: successfully initialized crtc\n", dpu_crtc->name);
> return crtc;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> index cec3474..1eeb73d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> @@ -169,6 +169,7 @@ struct dpu_crtc {
>
> /* for handling internal event thread */
> spinlock_t event_lock;
> + struct mutex commit_lock;
>
> struct dpu_core_perf_params cur_perf;
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index c0a4d4e..f99ae7a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -445,6 +445,30 @@ static void dpu_kms_wait_flush(struct msm_kms *kms,
> unsigned crtc_mask)
> dpu_kms_wait_for_commit_done(kms, crtc);
> }
>
> +static void dpu_kms_commit_lock(struct msm_kms *kms, unsigned int crtc_mask)
> +{
> + struct dpu_kms *dpu_kms = to_dpu_kms(kms);
> + struct drm_crtc *crtc;
> + struct dpu_crtc *dpu_crtc;
> +
> + for_each_crtc_mask(dpu_kms->dev, crtc, crtc_mask) {
> + dpu_crtc = to_dpu_crtc(crtc);
> + mutex_lock(_crtc->commit_lock);
> + }
> +}
> +
> +static void dpu_kms_commit_unlock(struct msm_kms *kms, unsigned int
> crtc_mask)
> +{
> + struct dpu_kms *dpu_kms = to_dpu_kms(kms);
> + struct drm_crtc *crtc;
> + struct dpu_crtc *dpu_crtc;
> +
> + for_each_crtc_mask(dpu_kms->dev, crtc, crtc_mask) {
> + dpu_crtc = to_dpu_crtc(crtc);
> + mutex_unlock(_crtc->commit_lock);
> + }
> +}
> +
> static int _dpu_kms_initialize_dsi(struct drm_device *dev,
> struct msm_drm_private *priv,
> struct dpu_kms *dpu_kms)
> @@ -738,6 +762,8 @@ static const struct msm_kms_funcs kms_funcs = {
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init= dpu_kms_debugfs_init,
> #endif
> + .commit_lock = dpu_kms_commit_lock,
> + .commit_unlock = dpu_kms_commit_unlock,
> };
>
> static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
> diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> b/drivers/gpu/drm/msm/msm_atomic.c
> index 561bfa4..d33253f 100644
> --- a/drivers/gpu/drm/msm/msm_atomic.c
> +++ b/drivers/gpu/drm/msm/msm_atomic.c
> @@ -55,16 +55,32 @@ static void vblank_put(struct msm_kms *kms, unsigned
> crtc_mask)
> }
> }
>
> +static void msm_commit_lock(struct msm_kms *kms, unsigned int crtc_mask)
> +{
> + if (kms->funcs->commit_lock)
> + kms->funcs->commit_lock(kms, crtc_mask);
> + else
> + mutex_lock(>commit_lock);
> +}
> +
> +static void msm_commit_unlock(struct msm_kms *kms, unsigned int crtc_mask)
> +{
> + if (kms->funcs->commit_unlock)
> + kms->funcs->commit_unlock(kms, crtc_mask);
> + else
> + mutex_unlock(>commit_lock);
> +}
Hi, I think the per-crtc commit-lock, and the updated
locking/unlocking points are the right thing to do, but I don't think
we need to touch dpu for this. Just change kms->commit_lock to an
array of mutexes, and drop the vfunc indirection. All the same
locking logic applies to mdp4/mdp5 as well (ie. don't touch the hw
until it has flushed)
BR,
-R
> +
> static void msm_atomic_async_commit(struct msm_kms *kms, int crtc_idx)
> {
> unsigned crtc_mask = BIT(crtc_idx);
>
> trace_msm_atomic_async_commit_start(crtc_mask);
>
> -
[PATCH] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
JSL has update in vswing table for eDP.
BSpec: 21257
Cc: Souza Jose
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/display/intel_ddi.c | 87 +++-
1 file changed, 85 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index bb0b9930958f..7ab694c6d8df 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
ehl_combo_phy_ddi_translations_dp[] = {
{ 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
};
+static const struct cnl_ddi_buf_trans jsl_combo_phy_ddi_translations_edp_hbr[]
= {
+ /* NT mV Trans mV db*/
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
+ { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
+ { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
+ { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
+ { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
+ { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
+ { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+};
+
+static const struct cnl_ddi_buf_trans
jsl_combo_phy_ddi_translations_edp_hbr2[] = {
+ /* NT mV Trans mV db*/
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
+ { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
+ { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
+ { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+};
+
struct icl_mg_phy_ddi_buf_trans {
u32 cri_txdeemph_override_11_6;
u32 cri_txdeemph_override_5_0;
@@ -1162,6 +1190,57 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
return ehl_get_combo_buf_trans_dp(encoder, crtc_state,
n_entries);
}
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
+ return icl_combo_phy_ddi_translations_hdmi;
+}
+
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans_dp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
+ return icl_combo_phy_ddi_translations_dp_hbr2;
+}
+
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans_edp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ int *n_entries)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ if (dev_priv->vbt.edp.low_vswing) {
+ if (crtc_state->port_clock > 27) {
+ *n_entries =
ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
+ return jsl_combo_phy_ddi_translations_edp_hbr2;
+ } else {
+ *n_entries =
ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr);
+ return jsl_combo_phy_ddi_translations_edp_hbr;
+ }
+ }
+
+ return jsl_get_combo_buf_trans_dp(encoder, crtc_state, n_entries);
+}
+
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ int *n_entries)
+{
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+ return jsl_get_combo_buf_trans_hdmi(encoder, crtc_state,
n_entries);
+ else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP))
+ return jsl_get_combo_buf_trans_edp(encoder, crtc_state,
n_entries);
+ else
+ return jsl_get_combo_buf_trans_dp(encoder, crtc_state,
n_entries);
+}
+
static const struct cnl_ddi_buf_trans *
tgl_get_combo_buf_trans_hdmi(struct
Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Add gpu cooling support
On 10/9/2020 10:27 PM, Matthias Kaehlcke wrote:
On Fri, Oct 09, 2020 at 08:05:10AM -0700, Doug Anderson wrote:
Hi,
On Thu, Oct 8, 2020 at 10:10 AM Akhil P Oommen wrote:
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index d46b383..40d6a28 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2,7 +2,7 @@
/*
* SC7180 SoC device tree source
*
- * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-20, The Linux Foundation. All rights reserved.
*/
#include
@@ -1885,6 +1885,7 @@
iommus = <_smmu 0>;
operating-points-v2 = <_opp_table>;
qcom,gmu = <>;
+ #cooling-cells = <2>;
Presumably we should add this to the devicetree bindings, too?
Yes, thanks for catching this. Will update in the next patch.
interconnects = <_noc MASTER_GFX3D _virt
SLAVE_EBI1>;
interconnect-names = "gfx-mem";
@@ -3825,16 +3826,16 @@
};
gpuss0-thermal {
- polling-delay-passive = <0>;
+ polling-delay-passive = <100>;
Why did you make this change? I'm pretty sure that we _don't_ want
this since we're using interrupts for the thermal sensor. See commit
22337b91022d ("arm64: dts: qcom: sc7180: Changed polling mode in
Thermal-zones node").
I was going to ask the same, this shouldn't be needed.
polling-delay = <0>;
thermal-sensors = < 13>;
trips {
gpuss0_alert0: trip-point0 {
- temperature = <9>;
+ temperature = <95000>;
hysteresis = <2000>;
- type = "hot";
+ type = "passive";
Matthias probably knows better, but I wonder if we should be making
two passive trip levels like we do with CPU. IIRC this is important
if someone wants to be able to use this with IPA.
Yes, please introduce a second trip point and make both of them
'passive'.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Adding Manaf here.
-Akhil.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/mediatek: mtk_hdmi: add MT8167 support for HDMI
Hi, Fabien:
Fabien Parent 於 2020年10月14日 週三 上午2:19寫道：
>
> Add support for HDMI on MT8167. HDMI on MT8167 is similar to
> MT8173/MT2701 execpt for the two registers: SYS_CFG1C and SYS_CFG20
I think you should drop this series. According to Mediatek HDMI
binding document [1], the second parameter of mediatek,syscon-hdmi is
the register offset. I think you could set register offset to 0x800
for mt8167.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt?h=v5.9
Regards,
Chun-Kuang.
>
> Signed-off-by: Fabien Parent
> ---
>
> Changelog:
> v2: fix name of pdata structure
>
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +++
> drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 57370c036497..484ea9cd654a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1835,9 +1835,16 @@ static struct mtk_hdmi_data mt8173_hdmi_driver_data = {
> .sys_cfg20 = HDMI_SYS_CFG20,
> };
>
> +static struct mtk_hdmi_data mt8167_hdmi_driver_data = {
> + .sys_cfg1c = MT8167_HDMI_SYS_CFG1C,
> + .sys_cfg20 = MT8167_HDMI_SYS_CFG20,
> +};
> +
> static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
> { .compatible = "mediatek,mt8173-hdmi",
> .data = _hdmi_driver_data },
> + { .compatible = "mediatek,mt8167-hdmi",
> + .data = _hdmi_driver_data },
> {}
> };
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> index 2050ba45b23a..a0f9c367d7aa 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> @@ -195,6 +195,7 @@
> #define GEN_RGB(0 << 7)
>
> #define HDMI_SYS_CFG1C 0x000
> +#define MT8167_HDMI_SYS_CFG1C 0x800
> #define HDMI_ONBIT(0)
> #define HDMI_RST BIT(1)
> #define ANLG_ONBIT(2)
> @@ -211,6 +212,7 @@
> #define HTPLG_PIN_SEL_OFF BIT(30)
> #define AES_EFUSE_ENABLE BIT(31)
> #define HDMI_SYS_CFG20 0x004
> +#define MT8167_HDMI_SYS_CFG20 0x804
> #define DEEP_COLOR_MODE_MASK (3 << 1)
> #define COLOR_8BIT_MODE(0 << 1)
> #define COLOR_10BIT_MODE (1 << 1)
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH drm/hisilicon 2/2] drm/hisilicon: Use the same style of variable type in hibmc_drm_drv
Hi
On Wed, 30 Sep 2020 15:13:08 +0800 Tian Tao wrote:
> Consistently Use the same style of variable type in hibmc_drm_de.c and
> hibmc_drm_de.h.
>
> Signed-off-by: Tian Tao
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 ++---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 8
> 2 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c index 5632bce..0c1b40d
> 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -121,12 +121,11 @@ static void hibmc_kms_fini(struct hibmc_drm_private
> *priv) /*
> * It can operate in one of three modes: 0, 1 or Sleep.
> */
> -void hibmc_set_power_mode(struct hibmc_drm_private *priv,
> - unsigned int power_mode)
> +void hibmc_set_power_mode(struct hibmc_drm_private *priv, u32 power_mode)
> {
> - unsigned int control_value = 0;
> + u32 control_value = 0;
> void __iomem *mmio = priv->mmio;
> - unsigned int input = 1;
> + u32 input = 1;
>
> if (power_mode > HIBMC_PW_MODE_CTL_MODE_SLEEP)
> return;
> @@ -144,8 +143,8 @@ void hibmc_set_power_mode(struct hibmc_drm_private
> *priv,
> void hibmc_set_current_gate(struct hibmc_drm_private *priv, unsigned int
> gate) {
> - unsigned int gate_reg;
> - unsigned int mode;
> + u32 gate_reg;
> + u32 mode;
> void __iomem *mmio = priv->mmio;
>
> /* Get current power mode. */
> @@ -170,7 +169,7 @@ void hibmc_set_current_gate(struct hibmc_drm_private
> *priv, unsigned int gate)
> static void hibmc_hw_config(struct hibmc_drm_private *priv)
> {
> - unsigned int reg;
> + u32 reg;
>
> /* On hardware reset, power mode 0 is default. */
> hibmc_set_power_mode(priv, HIBMC_PW_MODE_CTL_MODE_MODE0);
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h index 6a63502..5c4030d
> 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> @@ -33,8 +33,8 @@ struct hibmc_drm_private {
> /* hw */
> void __iomem *mmio;
> void __iomem *fb_map;
> - unsigned long fb_base;
> - unsigned long fb_size;
> + u64 fb_base;
> + u64 fb_size;
resource_size_t would be the correct type here.
With my comments addressed:
Acked-by: Thomas Zimmermann
Best regards
Thomas
>
> /* drm */
> struct drm_device *dev;
> @@ -56,9 +56,9 @@ static inline struct hibmc_drm_private
> *to_hibmc_drm_private(struct drm_device * }
>
> void hibmc_set_power_mode(struct hibmc_drm_private *priv,
> - unsigned int power_mode);
> + u32 power_mode);
> void hibmc_set_current_gate(struct hibmc_drm_private *priv,
> - unsigned int gate);
> + u32 gate);
>
> int hibmc_de_init(struct hibmc_drm_private *priv);
> int hibmc_vdac_init(struct hibmc_drm_private *priv);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH drm/hisilicon 1/2] drm/hisilicon: Use the same style of variable type in hibmc_drm_de
Hi,
reviews take a while as I'm very busy ATM.
On Wed, 30 Sep 2020 15:13:07 +0800 Tian Tao wrote:
> Consistently Use the same style of variable type in hibmc_drm_de.c.
>
> Signed-off-by: Tian Tao
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 59
> +- 1 file changed, 29 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c index a3a9e0a..c54f93d
> 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> @@ -23,15 +23,15 @@
> #include "hibmc_drm_regs.h"
>
> struct hibmc_display_panel_pll {
> - unsigned long M;
> - unsigned long N;
> - unsigned long OD;
> - unsigned long POD;
> + u64 M;
> + u64 N;
> + u64 OD;
> + u64 POD;
> };
>
> struct hibmc_dislay_pll_config {
> - unsigned long hdisplay;
> - unsigned long vdisplay;
> + u64 hdisplay;
> + u64 vdisplay;
> u32 pll1_config_value;
> u32 pll2_config_value;
> };
> @@ -102,7 +102,7 @@ static void hibmc_plane_atomic_update(struct drm_plane
> *plane, struct drm_plane_state*state = plane->state;
> u32 reg;
> s64 gpu_addr = 0;
> - unsigned int line_l;
> + u32 line_l;
> struct hibmc_drm_private *priv = to_hibmc_drm_private(plane->dev);
> struct drm_gem_vram_object *gbo;
>
> @@ -155,10 +155,10 @@ static const struct drm_plane_helper_funcs
> hibmc_plane_helper_funcs = { .atomic_update = hibmc_plane_atomic_update,
> };
>
> -static void hibmc_crtc_dpms(struct drm_crtc *crtc, int dpms)
> +static void hibmc_crtc_dpms(struct drm_crtc *crtc, u32 dpms)
> {
> struct hibmc_drm_private *priv = to_hibmc_drm_private(crtc->dev);
> - unsigned int reg;
> + u32 reg;
>
> reg = readl(priv->mmio + HIBMC_CRT_DISP_CTL);
> reg &= ~HIBMC_CRT_DISP_CTL_DPMS_MASK;
> @@ -172,7 +172,7 @@ static void hibmc_crtc_dpms(struct drm_crtc *crtc, int
> dpms) static void hibmc_crtc_atomic_enable(struct drm_crtc *crtc,
>struct drm_crtc_state *old_state)
> {
> - unsigned int reg;
> + u32 reg;
> struct hibmc_drm_private *priv = to_hibmc_drm_private(crtc->dev);
>
> hibmc_set_power_mode(priv, HIBMC_PW_MODE_CTL_MODE_MODE0);
> @@ -191,7 +191,7 @@ static void hibmc_crtc_atomic_enable(struct drm_crtc
> *crtc, static void hibmc_crtc_atomic_disable(struct drm_crtc *crtc,
> struct drm_crtc_state *old_state)
> {
> - unsigned int reg;
> + u32 reg;
> struct hibmc_drm_private *priv = to_hibmc_drm_private(crtc->dev);
>
> hibmc_crtc_dpms(crtc, HIBMC_CRT_DPMS_OFF);
> @@ -212,7 +212,7 @@ static enum drm_mode_status
> hibmc_crtc_mode_valid(struct drm_crtc *crtc,
> const struct drm_display_mode *mode)
> {
> - int i = 0;
> + u32 i = 0;
This is a counter against ARRAY_SIZE. i should be of type 'size_t'.
> int vrefresh = drm_mode_vrefresh(mode);
>
> if (vrefresh < 59 || vrefresh > 61)
> @@ -227,9 +227,9 @@ hibmc_crtc_mode_valid(struct drm_crtc *crtc,
> return MODE_BAD;
> }
>
> -static unsigned int format_pll_reg(void)
> +static u32 format_pll_reg(void)
> {
> - unsigned int pllreg = 0;
> + u32 pllreg = 0;
> struct hibmc_display_panel_pll pll = {0};
>
> /*
> @@ -249,7 +249,7 @@ static unsigned int format_pll_reg(void)
> return pllreg;
> }
>
> -static void set_vclock_hisilicon(struct drm_device *dev, unsigned long pll)
> +static void set_vclock_hisilicon(struct drm_device *dev, u64 pll)
> {
> u32 val;
> struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
> @@ -279,11 +279,10 @@ static void set_vclock_hisilicon(struct drm_device
> *dev, unsigned long pll) writel(val, priv->mmio + CRT_PLL1_HS);
> }
>
> -static void get_pll_config(unsigned long x, unsigned long y,
> -u32 *pll1, u32 *pll2)
> +static void get_pll_config(u64 x, u64 y, u32 *pll1, u32 *pll2)
> {
> - int i;
> - int count = ARRAY_SIZE(hibmc_pll_table);
> + u32 i;
> + u32 count = ARRAY_SIZE(hibmc_pll_table);
These variables should also be size_t.
>
> for (i = 0; i < count; i++) {
> if (hibmc_pll_table[i].hdisplay == x &&
> @@ -306,11 +305,11 @@ static void get_pll_config(unsigned long x, unsigned
> long y,
> * FPGA only supports 7 predefined pixel clocks, and clock select is
> * in bit 4:0 of new register 0x802a8.
> */
> -static unsigned int display_ctrl_adjust(struct drm_device *dev,
> - struct drm_display_mode *mode,
> - unsigned int ctrl)
> +static u32 display_ctrl_adjust(struct drm_device *dev,
> +struct drm_display_mode *mode,
> +u32 ctrl)
> {
> - unsigned long x, y;
> + u64 x, y;
> u32 pll1; /* bit[31:0] of
Re: [PATCH v2 1/3] backlight: pwm_bl: Fix interpolation
On Tue, Oct 13, 2020 at 01:01:01AM -0700, Alexandru Stan wrote:
> Whenever num-interpolated-steps was larger than the distance
> between 2 consecutive brightness levels the table would get really
> discontinuous. The slope of the interpolation would stick with
> integers only and if it was 0 the whole line segment would get skipped.
>
> Example settings:
> brightness-levels = <0 1 2 4 8 16 32 64 128 256>;
> num-interpolated-steps = <16>;
>
> The distances between 1 2 4 and 8 would be 1, and only starting with 16
> it would start to interpolate properly.
Both comments a perilously close to nitpicking but enough that I wanted
to reply...
I'd suggest that the current behaviour as having two properties.
1. It was designed to generate strictly increasing tables (no repeated
values).
2. It's implementation contains quantization errors when calculating the
step size. This results in both the discards of some interpolated
steps you mentioned (it is possible to insert extra steps between 4
and 8 whilst retaining a strictly increasing table). It also
results in a potentially large undershoot when multiplying a step
size (64 interpolated steps and a gap of 127 is likely to get a visual
jump as we hop through 63 physical steps in one go).
#1 can is a policy that can be changed. #2 is a bug that could be fixed.
To be clear I don't object to generating a monotonically increasing
table but I'd prefer the policy change to be explicitly described in
the description.
> Let's change it so there's always interpolation happening, even if
> there's no enough points available (read: values in the table would
> appear more than once). This should match the expected behavior much
> more closely.
>
> Signed-off-by: Alexandru Stan
> ---
>
> drivers/video/backlight/pwm_bl.c | 70 ++--
> 1 file changed, 31 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index dfc760830eb9..3e77f6b73fd9 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -230,8 +230,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
> struct platform_pwm_backlight_data *data)
> {
> struct device_node *node = dev->of_node;
> - unsigned int num_levels = 0;
> - unsigned int levels_count;
> + unsigned int num_levels;
> unsigned int num_steps = 0;
> struct property *prop;
> unsigned int *table;
> @@ -260,12 +259,11 @@ static int pwm_backlight_parse_dt(struct device *dev,
> if (!prop)
> return 0;
>
> - data->max_brightness = length / sizeof(u32);
> + num_levels = length / sizeof(u32);
>
> /* read brightness levels from DT property */
> - if (data->max_brightness > 0) {
> - size_t size = sizeof(*data->levels) * data->max_brightness;
> - unsigned int i, j, n = 0;
> + if (num_levels > 0) {
> + size_t size = sizeof(*data->levels) * num_levels;
>
> data->levels = devm_kzalloc(dev, size, GFP_KERNEL);
> if (!data->levels)
> @@ -273,7 +271,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
>
> ret = of_property_read_u32_array(node, "brightness-levels",
>data->levels,
> - data->max_brightness);
> + num_levels);
> if (ret < 0)
> return ret;
>
> @@ -298,7 +296,13 @@ static int pwm_backlight_parse_dt(struct device *dev,
>* between two points.
>*/
> if (num_steps) {
> - if (data->max_brightness < 2) {
> + unsigned int num_input_levels = num_levels;
> + unsigned int i;
> + u32 x1, x2, x, dx;
> + u32 y1, y2;
> + s64 dy;
> +
> + if (num_input_levels < 2) {
> dev_err(dev, "can't interpolate\n");
> return -EINVAL;
> }
> @@ -308,14 +312,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
>* taking in consideration the number of interpolated
>* steps between two levels.
>*/
> - for (i = 0; i < data->max_brightness - 1; i++) {
> - if ((data->levels[i + 1] - data->levels[i]) /
> -num_steps)
> - num_levels += num_steps;
> - else
> - num_levels++;
> - }
> - num_levels++;
> + num_levels = (num_input_levels - 1) * num_steps + 1;
>
Re: drm/ast something ate high-res modes (5.3->5.6 regression)
On Thu, 17 Sep 2020, Thomas Zimmermann wrote: > Hi > > Am 17.09.20 um 13:17 schrieb Ilpo Järvinen: > > Hi, > > > > Yes, I can build custom kernels and test but I won't have time for that > > before the end of September so I'll do it only then. > > No problem, that's still fine. > > Best regards > Thomas > > > > > And thanks a lot :-). > > The high-res mode works, however, I wasn't expecting it to be this slow though as I can see the slowish sweeps to redraw the screen or large parts of it. Maybe you meant all along this slow (I was expecting something like memcpy slow and this looks definitely much slower)? While a large redrawing operation is going on, mouse cursor stops moving normally until it is over and it then jumps to catch up. When the mouse is over something that doesn't require large redraw, it seems to work quite normally. -- i.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208981] trace with B550I AORUS PRO AX and AMD Ryzen 5 PRO 4650G
https://bugzilla.kernel.org/show_bug.cgi?id=208981 Anton Repko (an...@a-repko.sk) changed: What|Removed |Added CC||an...@a-repko.sk --- Comment #8 from Anton Repko (an...@a-repko.sk) --- The same happened with the following setup: - Kernel 5.8.14 and 5.9 with mostly Gentoo kernel config - AMD Ryzen 7 PRO 4750G CPU+iGPU - ASRock A520M-ITX/ac mainboard + ECC UDIMM memory The trace mentioned above disappeared when I updated BIOS (v. 1.20 from 2020/9/18, it contains AGESA 1.0.8.0). However, I'm still not able to run ROCm OpenCL (tried various versions, including 3.7 and 3.8), system either hangs, or (if the program is killed early) dmesg shows Evicting PASID 0x8001 queues BTW, clinfo causes GPU resets, and leaves 99% GPU utilization, while dmesg shows something like qcm fence wait loop timeout expired The cp might be in an unrecoverable state due to an unsuccessful queues preemption amdgpu: Failed to evict process queues amdgpu: Failed to quiesce KFD amdgpu :07:00.0: amdgpu: GPU reset begin! [drm] free PSP TMP buffer amdgpu :07:00.0: amdgpu: GPU reset succeeded, trying to resume ...(and similarly for kernel 5.9.0) It is probably an off-topic, but it seems to be related to amdgpu driver, and I don't know how to move forward (and somebody reported that ROCk 3.7 driver works well with APU Renoir). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209673] divide_error in amdgpu freezes screen
https://bugzilla.kernel.org/show_bug.cgi?id=209673 --- Comment #1 from cornelius.riemenschnei...@googlemail.com --- Xorg.0.log.old (the log that should contain the output of the crashed X server) is unfortunately empty. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209673] New: divide_error in amdgpu freezes screen
https://bugzilla.kernel.org/show_bug.cgi?id=209673 Bug ID: 209673 Summary: divide_error in amdgpu freezes screen Product: Drivers Version: 2.5 Kernel Version: 5.8.14-arch1-1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: cornelius.riemenschnei...@googlemail.com Regression: No Created attachment 292959 --> https://bugzilla.kernel.org/attachment.cgi?id=292959=edit dmesg.txt Today, my freeze froze spontaneously while browsing the web with firefox. I am using a Lenovo T14s with AMD Rzyen 4750U (internal GPU) with amdgpu, one external screen connected to a USB-C docking station. The system had an uptime of ~3 hours. I attached the dmesg output from the time of the crash, let me know if you need more information to debug this issue. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/virtio: Use UUID API for importing the UUID
On Tue, Oct 13, 2020 at 04:27:14PM +0300, Andy Shevchenko wrote: > There is import_uuid() function which imports u8 array to the uuid_t. > Use it instead of open coding variant. > > This allows to hide the uuid_t internals. > > Reviewed-by: David Stevens > Signed-off-by: Andy Shevchenko Pushed to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH V2] drm/i915/jsl: Split EHL/JSL platform info and PCI ids
Op 13-10-2020 om 23:08 schreef Matt Roper:
> On Wed, Oct 14, 2020 at 12:59:48AM +0530, Tejas Upadhyay wrote:
>> Recently we came across requirement to identify EHL and JSL
>> platform to program them differently. Thus Split the basic
>> platform definition, macros, and PCI IDs to differentiate
>> between EHL and JSL platforms. Also, IS_ELKHARTLAKE is replaced
>> with IS_JSL_EHL everywhere.
>>
>> Changes since V1 :
>> - Rebased to avoid merge conflicts
>> - Added missed check for jasperlake in intel_uc_fw.c
>>
>> Cc : Matt Roper
>> Cc : Ville Syrjälä
>> Signed-off-by: Tejas Upadhyay
> Reviewed-by: Matt Roper
>
>> ---
>> drivers/gpu/drm/i915/display/icl_dsi.c | 4 ++--
>> drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
>> drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 +++---
>> drivers/gpu/drm/i915/display/intel_ddi.c | 12 ++--
>> drivers/gpu/drm/i915/display/intel_display.c | 8
>> drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
>> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16
>> drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
>> drivers/gpu/drm/i915/gt/intel_workarounds.c| 4 ++--
>> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
>> drivers/gpu/drm/i915/i915_drv.h| 7 ---
>> drivers/gpu/drm/i915/i915_pci.c| 9 +
>> drivers/gpu/drm/i915/intel_device_info.c | 1 +
>> drivers/gpu/drm/i915/intel_device_info.h | 1 +
>> drivers/gpu/drm/i915/intel_pch.c | 6 +++---
>> include/drm/i915_pciids.h | 9 ++---
>> 16 files changed, 54 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
>> b/drivers/gpu/drm/i915/display/icl_dsi.c
>> index 4400e83f783f..096652921453 100644
>> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
>> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
>> @@ -455,7 +455,7 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
>> intel_encoder *encoder)
>> intel_de_write(dev_priv, ICL_PORT_TX_DW2_GRP(phy), tmp);
>>
>> /* For EHL, TGL, set latency optimization for PCS_DW1 lanes */
>> -if (IS_ELKHARTLAKE(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
>> +if (IS_JSL_EHL(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
>> tmp = intel_de_read(dev_priv,
>> ICL_PORT_PCS_DW1_AUX(phy));
>> tmp &= ~LATENCY_OPTIM_MASK;
>> @@ -612,7 +612,7 @@ gen11_dsi_setup_dphy_timings(struct intel_encoder
>> *encoder,
>> }
>> }
>>
>> -if (IS_ELKHARTLAKE(dev_priv)) {
>> +if (IS_JSL_EHL(dev_priv)) {
>> for_each_dsi_phy(phy, intel_dsi->phys) {
>> tmp = intel_de_read(dev_priv, ICL_DPHY_CHKN(phy));
>> tmp |= ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP;
>> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
>> b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> index 7dbf153279fb..7b46330fa69c 100644
>> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
>> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> @@ -2588,7 +2588,7 @@ static int intel_compute_max_dotclk(struct
>> drm_i915_private *dev_priv)
>> */
>> void intel_update_max_cdclk(struct drm_i915_private *dev_priv)
>> {
>> -if (IS_ELKHARTLAKE(dev_priv)) {
>> +if (IS_JSL_EHL(dev_priv)) {
>> if (dev_priv->cdclk.hw.ref == 24000)
>> dev_priv->max_cdclk_freq = 552000;
>> else
>> @@ -2829,7 +2829,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
>> *dev_priv)
>> dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
>> dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
>> dev_priv->cdclk.table = icl_cdclk_table;
>> -} else if (IS_ELKHARTLAKE(dev_priv)) {
>> +} else if (IS_JSL_EHL(dev_priv)) {
>> dev_priv->display.set_cdclk = bxt_set_cdclk;
>> dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
>> dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
>> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
>> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
>> index 932265f1ac90..d5ad61e4083e 100644
>> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
>> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
>> @@ -188,7 +188,7 @@ static bool has_phy_misc(struct drm_i915_private *i915,
>> enum phy phy)
>> * PHY-B and may not even have instances of the register for the
>> * other combo PHY's.
>> */
>> -if (IS_ELKHARTLAKE(i915) ||
>> +if (IS_JSL_EHL(i915) ||
>> IS_ROCKETLAKE(i915) ||
>> IS_DG1(i915))
>> return phy < PHY_C;
>> @@ -283,7 +283,7 @@ static bool icl_combo_phy_verify_state(struct
>> drm_i915_private *dev_priv,
>> ret &= check_phy_reg(dev_priv, phy,
Re: drm/ast something ate high-res modes (5.3->5.6 regression)
Hi On Wed, 14 Oct 2020 09:58:37 +0300 (EEST) "Ilpo Järvinen" wrote: > On Thu, 17 Sep 2020, Thomas Zimmermann wrote: > > > Hi > > > > Am 17.09.20 um 13:17 schrieb Ilpo Järvinen: > > > Hi, > > > > > > Yes, I can build custom kernels and test but I won't have time for that > > > before the end of September so I'll do it only then. > > > > No problem, that's still fine. > > > > Best regards > > Thomas > > > > > > > > And thanks a lot :-). > > > > > The high-res mode works, however, I wasn't expecting it to be this slow > though as I can see the slowish sweeps to redraw the screen or large parts > of it. Maybe you meant all along this slow (I was expecting something like > memcpy slow and this looks definitely much slower)? First of all, thanks for testing. I didn't expect it to be that slow either. > > While a large redrawing operation is going on, mouse cursor stops moving > normally until it is over and it then jumps to catch up. When the mouse is > over something that doesn't require large redraw, it seems to work quite > normally. > That sounds bad. The cursor is drawn by hardware, so I'd expect it to move smoothly across the screen. Maybe the position update is blocked from the framebuffer's memcpy within the kernel code. I was hoping the performance would be acceptable, but this sounds like a dealbreaker to me. I can look a bit closer if there are issues/bugs in the code that make it run slow. Not holding my breath for it though... Best regards Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/8] dt-bindings: phy: convert phy-mtk-ufs.txt to YAML schema
Convert phy-mtk-ufs.txt to YAML schema mediatek,ufs-phy.yaml
Signed-off-by: Chunfeng Yun
---
v2: fix binding check warning of reg in example
---
.../bindings/phy/mediatek,ufs-phy.yaml| 64 +++
.../devicetree/bindings/phy/phy-mtk-ufs.txt | 38 ---
2 files changed, 64 insertions(+), 38 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
diff --git a/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
b/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
new file mode 100644
index ..3a9be82e7f13
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,ufs-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Universal Flash Storage (UFS) M-PHY binding
+
+maintainers:
+ - Stanley Chu
+ - Chunfeng Yun
+
+description: |
+ UFS M-PHY nodes are defined to describe on-chip UFS M-PHY hardware macro.
+ Each UFS M-PHY node should have its own node.
+ To bind UFS M-PHY with UFS host controller, the controller node should
+ contain a phandle reference to UFS M-PHY node.
+
+properties:
+ $nodename:
+pattern: "^ufs-phy@[0-9a-f]+$"
+
+ compatible:
+const: mediatek,mt8183-ufsphy
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Unipro core control clock.
+ - description: M-PHY core control clock.
+
+ clock-names:
+items:
+ - const: unipro
+ - const: mp
+
+ "#phy-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+ufsphy: ufs-phy@11fa {
+compatible = "mediatek,mt8183-ufsphy";
+reg = <0x11fa 0xc000>;
+clocks = < CLK_INFRA_UNIPRO_SCK>,
+ < CLK_INFRA_UFS_MP_SAP_BCLK>;
+clock-names = "unipro", "mp";
+#phy-cells = <0>;
+};
+
+...
diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
b/Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
deleted file mode 100644
index 5789029a1d42..
--- a/Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-MediaTek Universal Flash Storage (UFS) M-PHY binding
-
-
-UFS M-PHY nodes are defined to describe on-chip UFS M-PHY hardware macro.
-Each UFS M-PHY node should have its own node.
-
-To bind UFS M-PHY with UFS host controller, the controller node should
-contain a phandle reference to UFS M-PHY node.
-
-Required properties for UFS M-PHY nodes:
-- compatible : Compatible list, contains the following controller:
- "mediatek,mt8183-ufsphy" for ufs phy
- persent on MT81xx chipsets.
-- reg: Address and length of the UFS M-PHY register set.
-- #phy-cells : This property shall be set to 0.
-- clocks : List of phandle and clock specifier pairs.
-- clock-names: List of clock input name strings sorted in the same
- order as the clocks property. Following clocks are
- mandatory.
- "unipro": Unipro core control clock.
- "mp": M-PHY core control clock.
-
-Example:
-
- ufsphy: phy@11fa {
- compatible = "mediatek,mt8183-ufsphy";
- reg = <0 0x11fa 0 0xc000>;
- #phy-cells = <0>;
-
- clocks = <_ao INFRACFG_AO_UNIPRO_SCK_CG>,
-<_ao INFRACFG_AO_UFS_MP_SAP_BCLK_CG>;
- clock-names = "unipro", "mp";
- };
-
- ufshci@1127 {
- ...
- phys = <>;
- };
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 8/8] MAINTAINERS: update MediaTek PHY/USB entry
Due to the phy/usb bindings are converted into YAML schema and also renamed, update entries. Meanwhile add drivers/usb/host/mtk-xhci* files. Signed-off-by: Chunfeng Yun --- v2: new patch --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index deaafb617361..d68725d87e44 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2105,7 +2105,7 @@ M:Chunfeng Yun L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) L: linux-media...@lists.infradead.org (moderated for non-subscribers) S: Maintained -F: Documentation/devicetree/bindings/phy/phy-mtk-* +F: Documentation/devicetree/bindings/phy/mediatek,* F: drivers/phy/mediatek/ ARM/Microchip (AT91) SoC support @@ -11028,6 +11028,8 @@ L: linux-...@vger.kernel.org (moderated for non-subscribers) L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) L: linux-media...@lists.infradead.org (moderated for non-subscribers) S: Maintained +F: Documentation/devicetree/bindings/usb/mediatek,* +F: drivers/usb/host/xhci-mtk* F: drivers/usb/mtu3/ MEGACHIPS STDP-GE-B850V3-FW LVDS/DP++ BRIDGES -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/8] dt-bindings: usb: convert mediatek, mtk-xhci.txt to YAML schema
Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml
Signed-off-by: Chunfeng Yun
---
v2: new patch
---
.../bindings/usb/mediatek,mtk-xhci.txt| 121
.../bindings/usb/mediatek,mtk-xhci.yaml | 180 ++
2 files changed, 180 insertions(+), 121 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
deleted file mode 100644
index 42d8814f903a..
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
+++ /dev/null
@@ -1,121 +0,0 @@
-MT8173 xHCI
-
-The device node for Mediatek SOC USB3.0 host controller
-
-There are two scenarios: the first one only supports xHCI driver;
-the second one supports dual-role mode, and the host is based on xHCI
-driver. Take account of backward compatibility, we divide bindings
-into two parts.
-
-1st: only supports xHCI driver
-
-
-Required properties:
- - compatible : should be "mediatek,-xhci", "mediatek,mtk-xhci",
- soc-model is the name of SoC, such as mt8173, mt2712 etc, when using
- "mediatek,mtk-xhci" compatible string, you need SoC specific ones in
- addition, one of:
- - "mediatek,mt8173-xhci"
- - reg : specifies physical base address and size of the registers
- - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
- - interrupts : interrupt used by the controller
- - power-domains : a phandle to USB power domain node to control USB's
- mtcmos
- - vusb33-supply : regulator of USB avdd3.3v
-
- - clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
- - clock-names : must contain
- "sys_ck": controller clock used by normal mode,
- the following ones are optional:
- "ref_ck": reference clock used by low power mode etc,
- "mcu_ck": mcu_bus clock for register access,
- "dma_ck": dma_bus clock for data transfer by DMA,
- "xhci_ck": controller clock
-
- - phys : see usb-hcd.yaml in the current directory
-
-Optional properties:
- - wakeup-source : enable USB remote wakeup;
- - mediatek,syscon-wakeup : phandle to syscon used to access the register
- of the USB wakeup glue layer between xHCI and SPM; it depends on
- "wakeup-source", and has two arguments:
- - the first one : register base address of the glue layer in syscon;
- - the second one : hardware version of the glue layer
- - 1 : used by mt8173 etc
- - 2 : used by mt2712 etc
- - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
- bit1 for u3port1, ... etc;
- - vbus-supply : reference to the VBUS regulator;
- - usb3-lpm-capable : supports USB3.0 LPM
- - pinctrl-names : a pinctrl state named "default" must be defined
- - pinctrl-0 : pin control group
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
- - imod-interval-ns: default interrupt moderation interval is 5000ns
-
-additionally the properties from usb-hcd.yaml (in the current directory) are
-supported.
-
-Example:
-usb30: usb@1127 {
- compatible = "mediatek,mt8173-xhci";
- reg = <0 0x1127 0 0x1000>,
- <0 0x11280700 0 0x0100>;
- reg-names = "mac", "ippc";
- interrupts = ;
- power-domains = < MT8173_POWER_DOMAIN_USB>;
- clocks = < CLK_TOP_USB30_SEL>, <>,
-< CLK_PERI_USB0>,
-< CLK_PERI_USB1>;
- clock-names = "sys_ck", "ref_ck";
- phys = <_port0 PHY_TYPE_USB3>,
- <_port1 PHY_TYPE_USB2>;
- vusb33-supply = <_vusb_reg>;
- vbus-supply = <_p1_vbus>;
- usb3-lpm-capable;
- mediatek,syscon-wakeup = < 0x400 1>;
- wakeup-source;
- imod-interval-ns = <1>;
-};
-
-2nd: dual-role mode with xHCI driver
-
-
-In the case, xhci is added as subnode to mtu3. An example and the DT binding
-details of mtu3 can be found in:
-Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
-
-Required properties:
- - compatible : should be "mediatek,-xhci", "mediatek,mtk-xhci",
- soc-model is the name of SoC, such as mt8173, mt2712 etc, when using
- "mediatek,mtk-xhci" compatible string, you need SoC specific ones in
- addition, one of:
- - "mediatek,mt8173-xhci"
- - reg : specifies physical base address and size of the registers
- - reg-names: should be "mac" for xHCI MAC
- - interrupts : interrupt used by the host controller
- - power-domains : a phandle to USB power domain node to control USB's
- mtcmos
- - vusb33-supply : regulator of USB avdd3.3v
-
- - clocks : a list of phandle + clock-specifier pairs, one for each
- entry
[PATCH v2] drm/nouveau/kms: Fix NULL pointer dereference in nouveau_connector_detect_depth
This oops manifests itself on the following hardware: 01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce G 103M] (rev a1) Oct 09 14:17:46 lp-sasha kernel: BUG: kernel NULL pointer dereference, address: Oct 09 14:17:46 lp-sasha kernel: #PF: supervisor read access in kernel mode Oct 09 14:17:46 lp-sasha kernel: #PF: error_code(0x) - not-present page Oct 09 14:17:46 lp-sasha kernel: PGD 0 P4D 0 Oct 09 14:17:46 lp-sasha kernel: Oops: [#1] SMP PTI Oct 09 14:17:46 lp-sasha kernel: CPU: 1 PID: 191 Comm: systemd-udevd Not tainted 5.9.0-rc8-next-20201009 #38 Oct 09 14:17:46 lp-sasha kernel: Hardware name: Hewlett-Packard Compaq Presario CQ61 Notebook PC/306A, BIOS F.03 03/23/2009 Oct 09 14:17:46 lp-sasha kernel: RIP: 0010:nouveau_connector_detect_depth+0x71/0xc0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: Code: 0a 00 00 48 8b 49 48 c7 87 b8 00 00 00 06 00 00 00 80 b9 4d 0a 00 00 00 75 1e 83 fa 41 75 05 48 85 c0 75 29 8b 81 10 0d 00 00 <39> 06 7c 25 f6 81 14 0d 00 00 02 75 b7 c3 80 b9 0c 0d 00 00 00 75 Oct 09 14:17:46 lp-sasha kernel: RSP: 0018:c928f8c0 EFLAGS: 00010297 Oct 09 14:17:46 lp-sasha kernel: RAX: 00014c08 RBX: 8880369d4000 RCX: 8880369d3000 Oct 09 14:17:46 lp-sasha kernel: RDX: 0040 RSI: RDI: 8880369d4000 Oct 09 14:17:46 lp-sasha kernel: RBP: 88800601cc00 R08: 8880051da298 R09: 8226201a Oct 09 14:17:46 lp-sasha kernel: R10: 88800469aa80 R11: 888004c84ff8 R12: Oct 09 14:17:46 lp-sasha kernel: R13: 8880051da000 R14: 2000 R15: 0003 Oct 09 14:17:46 lp-sasha kernel: FS: 7fd0192b3440() GS:8880bc90() knlGS: Oct 09 14:17:46 lp-sasha kernel: CS: 0010 DS: ES: CR0: 80050033 Oct 09 14:17:46 lp-sasha kernel: CR2: CR3: 04976000 CR4: 06e0 Oct 09 14:17:46 lp-sasha kernel: Call Trace: Oct 09 14:17:46 lp-sasha kernel: nouveau_connector_get_modes+0x1e6/0x240 [nouveau] Oct 09 14:17:46 lp-sasha kernel: ? kfree+0xb9/0x240 Oct 09 14:17:46 lp-sasha kernel: ? drm_connector_list_iter_next+0x7c/0xa0 Oct 09 14:17:46 lp-sasha kernel: drm_helper_probe_single_connector_modes+0x1ba/0x7c0 Oct 09 14:17:46 lp-sasha kernel: drm_client_modeset_probe+0x27e/0x1360 Oct 09 14:17:46 lp-sasha kernel: ? nvif_object_sclass_put+0xc/0x20 [nouveau] Oct 09 14:17:46 lp-sasha kernel: ? nouveau_cli_init+0x3cc/0x440 [nouveau] Oct 09 14:17:46 lp-sasha kernel: ? ktime_get_mono_fast_ns+0x49/0xa0 Oct 09 14:17:46 lp-sasha kernel: ? nouveau_drm_open+0x4e/0x180 [nouveau] Oct 09 14:17:46 lp-sasha kernel: __drm_fb_helper_initial_config_and_unlock+0x3f/0x4a0 Oct 09 14:17:46 lp-sasha kernel: ? drm_file_alloc+0x18f/0x260 Oct 09 14:17:46 lp-sasha kernel: ? mutex_lock+0x9/0x40 Oct 09 14:17:46 lp-sasha kernel: ? drm_client_init+0x110/0x160 Oct 09 14:17:46 lp-sasha kernel: nouveau_fbcon_init+0x14d/0x1c0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: nouveau_drm_device_init+0x1c0/0x880 [nouveau] Oct 09 14:17:46 lp-sasha kernel: nouveau_drm_probe+0x11a/0x1e0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: pci_device_probe+0xcd/0x140 Oct 09 14:17:46 lp-sasha kernel: really_probe+0xd8/0x400 Oct 09 14:17:46 lp-sasha kernel: driver_probe_device+0x4a/0xa0 Oct 09 14:17:46 lp-sasha kernel: device_driver_attach+0x9c/0xc0 Oct 09 14:17:46 lp-sasha kernel: __driver_attach+0x6f/0x100 Oct 09 14:17:46 lp-sasha kernel: ? device_driver_attach+0xc0/0xc0 Oct 09 14:17:46 lp-sasha kernel: bus_for_each_dev+0x75/0xc0 Oct 09 14:17:46 lp-sasha kernel: bus_add_driver+0x106/0x1c0 Oct 09 14:17:46 lp-sasha kernel: driver_register+0x86/0xe0 Oct 09 14:17:46 lp-sasha kernel: ? 0xa044e000 Oct 09 14:17:46 lp-sasha kernel: do_one_initcall+0x48/0x1e0 Oct 09 14:17:46 lp-sasha kernel: ? _cond_resched+0x11/0x60 Oct 09 14:17:46 lp-sasha kernel: ? kmem_cache_alloc_trace+0x19c/0x1e0 Oct 09 14:17:46 lp-sasha kernel: do_init_module+0x57/0x220 Oct 09 14:17:46 lp-sasha kernel: __do_sys_finit_module+0xa0/0xe0 Oct 09 14:17:46 lp-sasha kernel: do_syscall_64+0x33/0x40 Oct 09 14:17:46 lp-sasha kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Oct 09 14:17:46 lp-sasha kernel: RIP: 0033:0x7fd01a060d5d Oct 09 14:17:46 lp-sasha kernel: Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 70 0c 00 f7 d8 64 89 01 48 Oct 09 14:17:46 lp-sasha kernel: RSP: 002b:7ffc8ad38a98 EFLAGS: 0246 ORIG_RAX: 0139 Oct 09 14:17:46 lp-sasha kernel: RAX: ffda RBX: 563f6e7fd530 RCX: 7fd01a060d5d Oct 09 14:17:46 lp-sasha kernel: RDX: RSI: 7fd01a19f95d RDI: 000f Oct 09 14:17:46 lp-sasha kernel: RBP: 0002 R08: R09: 0007 Oct 09 14:17:46 lp-sasha kernel: R10: 000f R11: 0246 R12:
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> On Fri, Oct 9, 2020 at 12:52 PM wrote:
> >
> > From: Ira Weiny
> >
> > The kmap() calls in this FS are localized to a single thread. To avoid
> > the over head of global PKRS updates use the new kmap_thread() call.
> >
> > Cc: Nicolas Pitre
> > Signed-off-by: Ira Weiny
> > ---
> > fs/cramfs/inode.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> > index 912308600d39..003c014a42ed 100644
> > --- a/fs/cramfs/inode.c
> > +++ b/fs/cramfs/inode.c
> > @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block *sb,
> > unsigned int offset,
> > struct page *page = pages[i];
> >
> > if (page) {
> > - memcpy(data, kmap(page), PAGE_SIZE);
> > - kunmap(page);
> > + memcpy(data, kmap_thread(page), PAGE_SIZE);
> > + kunmap_thread(page);
>
> Why does this need a sleepable kmap? This looks like a textbook
> kmap_atomic() use case.
There's a lot of code of this form. Could we perhaps have:
static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned int
size)
{
char *vto = kmap_atomic(to);
memcpy(vto, vfrom, size);
kunmap_atomic(vto);
}
in linux/highmem.h ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/mediatek: mtk_hdmi: add MT8167 support for HDMI
On Tue, Oct 13, 2020 at 7:28 PM Fabien Parent wrote:
>
> Add support for HDMI on MT8167. HDMI on MT8167 is similar to
> MT8173/MT2701 execpt for the two registers: SYS_CFG1C and SYS_CFG20
>
> Signed-off-by: Fabien Parent
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +++
> drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index c70f195c21be..7762be5cb446 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1835,9 +1835,16 @@ static struct mtk_hdmi_data mt8173_hdmi_driver_data = {
> .sys_cfg20 = HDMI_SYS_CFG20,
> };
>
> +static struct mtk_hdmi_conf mt8167_hdmi_driver_data = {
Sent the wrong patch. Sending v2 soon.
> + .sys_cfg1c = MT8167_HDMI_SYS_CFG1C,
> + .sys_cfg20 = MT8167_HDMI_SYS_CFG20,
> +};
> +
> static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
> { .compatible = "mediatek,mt8173-hdmi",
> .data = _hdmi_driver_data },
> + { .compatible = "mediatek,mt8167-hdmi",
> + .data = _hdmi_driver_data },
> {}
> };
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> index 2050ba45b23a..a0f9c367d7aa 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> @@ -195,6 +195,7 @@
> #define GEN_RGB(0 << 7)
>
> #define HDMI_SYS_CFG1C 0x000
> +#define MT8167_HDMI_SYS_CFG1C 0x800
> #define HDMI_ONBIT(0)
> #define HDMI_RST BIT(1)
> #define ANLG_ONBIT(2)
> @@ -211,6 +212,7 @@
> #define HTPLG_PIN_SEL_OFF BIT(30)
> #define AES_EFUSE_ENABLE BIT(31)
> #define HDMI_SYS_CFG20 0x004
> +#define MT8167_HDMI_SYS_CFG20 0x804
> #define DEEP_COLOR_MODE_MASK (3 << 1)
> #define COLOR_8BIT_MODE(0 << 1)
> #define COLOR_10BIT_MODE (1 << 1)
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/8] dt-bindings: usb: convert mediatek, musb.txt to YAML schema
Convert mediatek,musb.txt to YAML schema mediatek,musb.yaml
Cc: Min Guo
Signed-off-by: Chunfeng Yun
---
v2: new patch
---
.../devicetree/bindings/usb/mediatek,musb.txt | 57 -
.../bindings/usb/mediatek,musb.yaml | 113 ++
2 files changed, 113 insertions(+), 57 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt
create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.yaml
diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.txt
b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
deleted file mode 100644
index 5eedb0296562..
--- a/Documentation/devicetree/bindings/usb/mediatek,musb.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-MediaTek musb DRD/OTG controller
-
-Required properties:
- - compatible : should be one of:
- "mediatek,mt2701-musb"
- ...
- followed by "mediatek,mtk-musb"
- - reg : specifies physical base address and size of
- the registers
- - interrupts : interrupt used by musb controller
- - interrupt-names : must be "mc"
- - phys: PHY specifier for the OTG phy
- - dr_mode : should be one of "host", "peripheral" or "otg",
- refer to usb/generic.txt
- - clocks : a list of phandle + clock-specifier pairs, one for
- each entry in clock-names
- - clock-names : must contain "main", "mcu", "univpll"
- for clocks of controller
-
-Optional properties:
- - power-domains : a phandle to USB power domain node to control USB's
- MTCMOS
-
-Required child nodes:
- usb connector node as defined in bindings/connector/usb-connector.yaml
-Optional properties:
- - id-gpios: input GPIO for USB ID pin.
- - vbus-gpios : input GPIO for USB VBUS pin.
- - vbus-supply : reference to the VBUS regulator, needed when supports
- dual-role mode
- - usb-role-switch : use USB Role Switch to support dual-role switch, see
- usb/generic.txt.
-
-Example:
-
-usb2: usb@1120 {
- compatible = "mediatek,mt2701-musb",
-"mediatek,mtk-musb";
- reg = <0 0x1120 0 0x1000>;
- interrupts = ;
- interrupt-names = "mc";
- phys = < PHY_TYPE_USB2>;
- dr_mode = "otg";
- clocks = < CLK_PERI_USB0>,
-< CLK_PERI_USB0_MCU>,
-< CLK_PERI_USB_SLV>;
- clock-names = "main","mcu","univpll";
- power-domains = < MT2701_POWER_DOMAIN_IFR_MSC>;
- usb-role-switch;
- connector{
- compatible = "gpio-usb-b-connector", "usb-b-connector";
- type = "micro";
- id-gpios = < 44 GPIO_ACTIVE_HIGH>;
- vbus-supply = <_vbus>;
- };
-};
diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml
b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml
new file mode 100644
index ..f2b3dcb3d52c
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/mediatek,musb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MUSB DRD/OTG Controller Device Tree Bindings
+
+maintainers:
+ - Min Guo
+
+properties:
+ $nodename:
+pattern: '^usb@[0-9a-f]+$'
+
+ compatible:
+items:
+ - enum:
+ - mediatek,mt2701-musb
+ - const: mediatek,mtk-musb
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ interrupt-names:
+items:
+ - const: mc
+
+ clocks:
+items:
+ - description: The main/core clock
+ - description: The system bus clock
+ - description: The 48Mhz clock
+
+ clock-names:
+items:
+ - const: main
+ - const: mcu
+ - const: univpll
+
+ phys:
+maxItems: 1
+
+ usb-role-switch:
+$ref: /schemas/types.yaml#/definitions/flag
+description: Support role switch. See usb/generic.txt
+type: boolean
+
+ dr_mode:
+enum:
+ - host
+ - otg
+ - peripheral
+
+ power-domains:
+description: A phandle to USB power domain node to control USB's MTCMOS
+maxItems: 1
+
+ connector:
+$ref: /connector/usb-connector.yaml#
+description: Connector for dual role switch
+type: object
+
+dependencies:
+ usb-role-switch: [ 'connector' ]
+ connector: [ 'usb-role-switch' ]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - phys
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+#include
+
+usb2: usb@1120 {
+compatible = "mediatek,mt2701-musb", "mediatek,mtk-musb";
+reg = <0x1120
[PATCH v4] drm/msm/dp: return correct connection status after suspend
During suspend, dp host controller and hpd block are disabled due to
both ahb and aux clock are disabled. Therefore hpd plug/unplug interrupts
will not be generated. At dp_pm_resume(), reinitialize both dp host
controller and hpd block so that hpd plug/unplug interrupts will be
generated and handled by driver so that hpd connection state is updated
correctly. This patch will fix link training flaky issues.
Changes in v2:
-- use container_of to cast correct dp_display_private pointer
at both dp_pm_suspend() and dp_pm_resume().
Changes in v3:
-- replace hpd_state atomic_t with u32
Changes in v4
-- call dp_display_host_deinit() at dp_pm_suspend()
-- call dp_display_host_init() at msm_dp_display_enable()
-- fix phy->init_count unbalance which causes link training failed
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 13 +++
drivers/gpu/drm/msm/dp/dp_catalog.h | 1 +
drivers/gpu/drm/msm/dp/dp_ctrl.c| 5 +
drivers/gpu/drm/msm/dp/dp_display.c | 144 +++-
drivers/gpu/drm/msm/dp/dp_reg.h | 2 +
5 files changed, 97 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index b15b4ce4ba35..4963bfe6a472 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -572,6 +572,19 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog
*dp_catalog)
dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, DP_DP_HPD_CTRL_HPD_EN);
}
+u32 dp_catalog_hpd_get_state_status(struct dp_catalog *dp_catalog)
+{
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+ u32 status;
+
+ status = dp_read_aux(catalog, REG_DP_DP_HPD_INT_STATUS);
+ status >>= DP_DP_HPD_STATE_STATUS_BITS_SHIFT;
+ status &= DP_DP_HPD_STATE_STATUS_BITS_MASK;
+
+ return status;
+}
+
u32 dp_catalog_hpd_get_intr_status(struct dp_catalog *dp_catalog)
{
struct dp_catalog_private *catalog = container_of(dp_catalog,
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 4b7666f1fe6f..6d257dbebf29 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -97,6 +97,7 @@ void dp_catalog_ctrl_enable_irq(struct dp_catalog
*dp_catalog, bool enable);
void dp_catalog_hpd_config_intr(struct dp_catalog *dp_catalog,
u32 intr_mask, bool en);
void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog);
+u32 dp_catalog_hpd_get_state_status(struct dp_catalog *dp_catalog);
u32 dp_catalog_hpd_get_intr_status(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_phy_reset(struct dp_catalog *dp_catalog);
int dp_catalog_ctrl_update_vx_px(struct dp_catalog *dp_catalog, u8 v_level,
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 2e3e1917351f..6bdaec778c4c 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1400,6 +1400,8 @@ int dp_ctrl_host_init(struct dp_ctrl *dp_ctrl, bool flip)
void dp_ctrl_host_deinit(struct dp_ctrl *dp_ctrl)
{
struct dp_ctrl_private *ctrl;
+ struct dp_io *dp_io;
+ struct phy *phy;
if (!dp_ctrl) {
DRM_ERROR("Invalid input data\n");
@@ -1407,8 +1409,11 @@ void dp_ctrl_host_deinit(struct dp_ctrl *dp_ctrl)
}
ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
+ dp_io = >parser->io;
+ phy = dp_io->phy;
dp_catalog_ctrl_enable_irq(ctrl->catalog, false);
+ phy_exit(phy);
DRM_DEBUG_DP("Host deinitialized successfully\n");
}
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index e175aa3fd3a9..d9164ff6515d 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -108,14 +108,12 @@ struct dp_display_private {
/* event related only access by event thread */
struct mutex event_mutex;
wait_queue_head_t event_q;
- atomic_t hpd_state;
+ u32 hpd_state;
u32 event_pndx;
u32 event_gndx;
struct dp_event event_list[DP_EVENT_Q_MAX];
spinlock_t event_lock;
- struct completion resume_comp;
-
struct dp_audio *audio;
};
@@ -366,6 +364,20 @@ static void dp_display_host_init(struct dp_display_private
*dp)
dp->core_initialized = true;
}
+static void dp_display_host_deinit(struct dp_display_private *dp)
+{
+ if (!dp->core_initialized) {
+ DRM_DEBUG_DP("DP core not initialized\n");
+ return;
+ }
+
+ dp_ctrl_host_deinit(dp->ctrl);
+ dp_aux_deinit(dp->aux);
+ dp_power_deinit(dp->power);
+
+ dp->core_initialized = false;
+}
+
static int dp_display_usbpd_configure_cb(struct device *dev)
{
int rc = 0;
@@ -490,7 +502,7 @@ static int dp_hpd_plug_handle(struct dp_display_private
Re: [PATCH v2] drm/of: Consider the state in which the ep is disabled
Hi Maintainers,
Does this patch ready to merge?
On 2020/7/7 下午7:25, Sandy Huang wrote:
don't mask possible_crtcs if remote-point is disabled.
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/drm_of.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index fdb05fbf72a0..565f05f5f11b 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -66,6 +66,9 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
uint32_t possible_crtcs = 0;
for_each_endpoint_of_node(port, ep) {
+ if (!of_device_is_available(ep))
+ continue;
+
remote_port = of_graph_get_remote_port(ep);
if (!remote_port) {
of_node_put(ep);
Looks good to me.
Reviewed-by: Kever Yang
Thanks,
- Kever
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
Hi Stephen,
Le lun. 12 oct. 2020 à 15:24, Stephen Rothwell
a écrit :
Hi all,
On Thu, 8 Oct 2020 15:42:02 +1100 Stephen Rothwell
wrote:
On Thu, 8 Oct 2020 14:09:03 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
In file included from include/linux/clk.h:13,
from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:10:
drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function
'ingenic_drm_update_palette':
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct
ingenic_drm' has no member named 'dma_hwdescs'; did you mean
'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
| ^~~
include/linux/kernel.h:47:33: note: in definition of macro
'ARRAY_SIZE'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
| ^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct
ingenic_drm' has no member named 'dma_hwdescs'; did you mean
'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
| ^~~
include/linux/kernel.h:47:48: note: in definition of macro
'ARRAY_SIZE'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|^~~
In file included from include/linux/bits.h:22,
from include/linux/bitops.h:5,
from drivers/gpu/drm/ingenic/ingenic-drm.h:10,
from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:7:
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct
ingenic_drm' has no member named 'dma_hwdescs'; did you mean
'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
| ^~~
include/linux/build_bug.h:16:62: note: in definition of macro
'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct {
int:(-!!(e)); })))
|
^
include/linux/compiler.h:224:46: note: in expansion of macro
'__same_type'
224 | #define __must_be_array(a)
BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
| ^~~
include/linux/kernel.h:47:59: note: in expansion of macro
'__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in
expansion of macro 'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct
ingenic_drm' has no member named 'dma_hwdescs'; did you mean
'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
| ^~~
include/linux/build_bug.h:16:62: note: in definition of macro
'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct {
int:(-!!(e)); })))
|
^
include/linux/compiler.h:224:46: note: in expansion of macro
'__same_type'
224 | #define __must_be_array(a)
BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
| ^~~
include/linux/kernel.h:47:59: note: in expansion of macro
'__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in
expansion of macro 'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
| ^~
include/linux/build_bug.h:16:51: error: bit-field ''
width not an integer constant
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct {
int:(-!!(e)); })))
| ^
include/linux/compiler.h:224:28: note: in expansion of macro
'BUILD_BUG_ON_ZERO'
224 | #define __must_be_array(a)
BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
|^
include/linux/kernel.h:47:59: note: in expansion of macro
'__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in
expansion of macro 'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
Re: [PATCH v3] drm/msm/dp: fixes wrong connection state caused by failure of link train
Quoting Kuogee Hsieh (2020-10-13 16:35:44) > Connection state is not set correctly happen when either failure of link > train due to cable unplugged in the middle of aux channel reading or > cable plugged in while in suspended state. This patch fixes these problems. > This patch also replace ST_SUSPEND_PENDING with ST_DISPLAY_OFF. > > Changes in V2: > -- Add more information to commit message. > > Changes in V3: > -- change base > > Signed-off-by: Kuogee Hsieh > --- Any Fixes tag? Tested-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] PWM backlight interpolation adjustments
I was trying to adjust the brightness-levels for the trogdor boards: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2291209 Like on a lot of panels, trogdor's low end needs to be cropped, and now that we have the interpolation stuff I wanted to make use of it and bake in even the curve that's customary to have on chromebooks. I found the current behavior of the pwm_bl driver a little unintuitive and non-linear. See patch 1 for a suggested fix for this. A few veyron dts files were relying on this (perhaps weird) behavior. Those devices also want a minimum brightness like trogdor, so changed them to use the new way. Finally, given that trogdor's dts is part of linux-next now, add the brightness-levels to it, since that's the original reason I was looking at this. Changes in v2: - Fixed type promotion in the driver - Removed "backlight: pwm_bl: Artificially add 0% during interpolation", userspace works just fine without it because it already knows how to use bl_power for turning off the display. - Added brightness-levels to trogdor as well, now the dts is upstream. Alexandru Stan (3): backlight: pwm_bl: Fix interpolation ARM: dts: rockchip: veyron: Remove 0 point from brightness-levels arm64: dts: qcom: trogdor: Add brightness-levels arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2 +- arch/arm/boot/dts/rk3288-veyron-minnie.dts | 2 +- arch/arm/boot/dts/rk3288-veyron-tiger.dts| 2 +- arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 9 +++ drivers/video/backlight/pwm_bl.c | 70 +--- 5 files changed, 43 insertions(+), 42 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Add myself as a maintainer for vc4
On Fri, Oct 09, 2020 at 09:54:28AM -0700, Eric Anholt wrote: > Reviewed-by: Eric Anholt Thanks! I applied it to drm-misc-next > I'd be fine with retiring from being maintainer, too. I'm definitely > not active. Ultimately that's up to you, but I guess it would be nice to still stick around since you obviously have much more experience with the hardware and the driver :) Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/7] dt-bindings: display: mxsfb: Add a bus-width endpoint property
On 10/13/20 4:06 AM, Laurent Pinchart wrote: > Hi Marek, > > On Sat, Oct 10, 2020 at 10:47:05AM +0200, Marek Vasut wrote: >> On 10/10/20 1:58 AM, Laurent Pinchart wrote: >>> Hi Marek, >> >> Hi, >> >>> On Wed, Oct 07, 2020 at 10:40:26AM +0200, Marek Vasut wrote: On 10/7/20 3:24 AM, Laurent Pinchart wrote: [...] > + bus-width: > +enum: [16, 18, 24] > +description: | > + The output bus width. This value overrides the > configuration > + derived from the connected device (encoder or panel). It > should > + only be specified when PCB routing of the data signals > require a > + different bus width on the LCDIF and the connected device. > For > + instance, when a 18-bit RGB panel has its R[5:0], G[5:0] > and > + B[5:0] signals connected to LCD_DATA[7:2], LCD_DATA[15:10] > and > + LCD_DATA[23:18] instead of LCD_DATA[5:0], LCD_DATA[11:6] > and > + LCD_DATA[17:12], bus-width should be set to 24. The iMX6 IPUv3 uses interface-pix-fmt which is a bit more flexible, but I'm not sure whether it's the right way to go about this, see: Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt >>> >>> I think specifying the bus with is better. It's a standard property, but >>> more than that, a given bus width can carry different formats. For >>> instance, a 24-bus could carry RGB666 data (with dithering for the >>> LSBs). >> >> I think that's exactly what the interface-pix-fmt was trying to solve >> for the IPUv3, there you could have e.g. both RGB666 and LVDS666 , which >> were different. > > My point is that the driver should support multiple formats that can be > carried over a given bus width, with the actual format to be used > queried from the sink (usually a panel) instead of being hardcoded in > DT. So, should the IPUv3 be fixed as well then ? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/mediatek: mtk_hdmi: move 2 registers address into of_data
On MT8167, the two registers SYS_CFG1C and SYS_CFG20 don't have the
same address as on MT8173. Add OF data in order to store the address
of these two registers.
Signed-off-by: Fabien Parent
---
Changelog:
v2: no changes
drivers/gpu/drm/mediatek/mtk_hdmi.c | 45 ++---
1 file changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index a97725680d4e..57370c036497 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -36,6 +36,11 @@
#define NCTS_BYTES 7
+struct mtk_hdmi_data {
+ uint32_t sys_cfg1c;
+ uint32_t sys_cfg20;
+};
+
enum mtk_hdmi_clk_id {
MTK_HDMI_CLK_HDMI_PIXEL,
MTK_HDMI_CLK_HDMI_PLL,
@@ -146,6 +151,7 @@ struct hdmi_audio_param {
};
struct mtk_hdmi {
+ const struct mtk_hdmi_data *data;
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
struct drm_connector conn;
@@ -244,21 +250,24 @@ static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi
*hdmi, bool enable)
*/
if (hdmi_phy->conf && hdmi_phy->conf->tz_disabled)
regmap_update_bits(hdmi->sys_regmap,
- hdmi->sys_offset + HDMI_SYS_CFG20,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
0x80008005, enable ? 0x8005 : 0x8000);
else
arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904,
0x8000, 0, 0, 0, 0, 0, );
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
HDMI_ON | ANLG_ON, enable ? (HDMI_ON | ANLG_ON) : 0);
}
static void mtk_hdmi_hw_1p4_version_enable(struct mtk_hdmi *hdmi, bool enable)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI2P0_EN, enable ? 0 : HDMI2P0_EN);
}
@@ -274,12 +283,15 @@ static void mtk_hdmi_hw_aud_unmute(struct mtk_hdmi *hdmi)
static void mtk_hdmi_hw_reset(struct mtk_hdmi *hdmi)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
HDMI_RST, HDMI_RST);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
HDMI_RST, 0);
mtk_hdmi_clear_bits(hdmi, GRL_CFG3, CFG3_CONTROL_PACKET_DELAY);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
ANLG_ON, ANLG_ON);
}
@@ -362,16 +374,19 @@ static void mtk_hdmi_hw_send_aud_packet(struct mtk_hdmi
*hdmi, bool enable)
static void mtk_hdmi_hw_config_sys(struct mtk_hdmi *hdmi)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI_OUT_FIFO_EN | MHL_MODE_ON, 0);
usleep_range(2000, 4000);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI_OUT_FIFO_EN | MHL_MODE_ON, HDMI_OUT_FIFO_EN);
}
static void mtk_hdmi_hw_set_deep_color_mode(struct mtk_hdmi *hdmi)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
DEEP_COLOR_MODE_MASK | DEEP_COLOR_EN,
COLOR_8BIT_MODE);
}
@@ -1733,6 +1748,7 @@ static int mtk_drm_hdmi_probe(struct platform_device
*pdev)
return -ENOMEM;
hdmi->dev = dev;
+ hdmi->data = of_device_get_match_data(dev);
ret = mtk_hdmi_dt_parse_pdata(hdmi, pdev);
if (ret)
@@ -1813,8 +1829,15 @@ static int mtk_hdmi_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mtk_hdmi_pm_ops,
mtk_hdmi_suspend, mtk_hdmi_resume);
+
[PATCH] drm/mediatek: Optimize functions which do not need to return
Function mtk_hdmi_aud_set_input always return 0, no need to
keep the return value. Functions mtk_hdmi_aud_enable_packet &
mtk_hdmi_aud_on_off_hw_ncts are the same, these two functions
just call next functions. Maybe it`s a bit better to just call
the inner function.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index a97725680d4e..f1d987df0550 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -870,19 +870,8 @@ static void mtk_hdmi_video_set_display_mode(struct
mtk_hdmi *hdmi,
mtk_hdmi_hw_msic_setting(hdmi, mode);
}
-static int mtk_hdmi_aud_enable_packet(struct mtk_hdmi *hdmi, bool enable)
-{
- mtk_hdmi_hw_send_aud_packet(hdmi, enable);
- return 0;
-}
-static int mtk_hdmi_aud_on_off_hw_ncts(struct mtk_hdmi *hdmi, bool on)
-{
- mtk_hdmi_hw_ncts_enable(hdmi, on);
- return 0;
-}
-
-static int mtk_hdmi_aud_set_input(struct mtk_hdmi *hdmi)
+static void mtk_hdmi_aud_set_input(struct mtk_hdmi *hdmi)
{
enum hdmi_aud_channel_type chan_type;
u8 chan_count;
@@ -912,8 +901,6 @@ static int mtk_hdmi_aud_set_input(struct mtk_hdmi *hdmi)
chan_count = mtk_hdmi_aud_get_chnl_count(chan_type);
mtk_hdmi_hw_aud_set_i2s_chan_num(hdmi, chan_type, chan_count);
mtk_hdmi_hw_aud_set_input_type(hdmi, hdmi->aud_param.aud_input_type);
-
- return 0;
}
static int mtk_hdmi_aud_set_src(struct mtk_hdmi *hdmi,
@@ -921,7 +908,7 @@ static int mtk_hdmi_aud_set_src(struct mtk_hdmi *hdmi,
{
unsigned int sample_rate = hdmi->aud_param.codec_params.sample_rate;
- mtk_hdmi_aud_on_off_hw_ncts(hdmi, false);
+ mtk_hdmi_hw_ncts_enable(hdmi, false);
mtk_hdmi_hw_aud_src_disable(hdmi);
mtk_hdmi_clear_bits(hdmi, GRL_CFG2, CFG2_ACLK_INV);
@@ -959,7 +946,7 @@ static int mtk_hdmi_aud_output_config(struct mtk_hdmi *hdmi,
struct drm_display_mode *display_mode)
{
mtk_hdmi_hw_aud_mute(hdmi);
- mtk_hdmi_aud_enable_packet(hdmi, false);
+ mtk_hdmi_hw_send_aud_packet(hdmi, false);
mtk_hdmi_aud_set_input(hdmi);
mtk_hdmi_aud_set_src(hdmi, display_mode);
@@ -968,8 +955,8 @@ static int mtk_hdmi_aud_output_config(struct mtk_hdmi *hdmi,
usleep_range(50, 100);
- mtk_hdmi_aud_on_off_hw_ncts(hdmi, true);
- mtk_hdmi_aud_enable_packet(hdmi, true);
+ mtk_hdmi_hw_ncts_enable(hdmi, true);
+ mtk_hdmi_hw_send_aud_packet(hdmi, true);
mtk_hdmi_hw_aud_unmute(hdmi);
return 0;
}
@@ -1097,13 +1084,13 @@ static int mtk_hdmi_output_init(struct mtk_hdmi *hdmi)
static void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
{
- mtk_hdmi_aud_enable_packet(hdmi, true);
+ mtk_hdmi_hw_send_aud_packet(hdmi, true);
hdmi->audio_enable = true;
}
static void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
{
- mtk_hdmi_aud_enable_packet(hdmi, false);
+ mtk_hdmi_hw_send_aud_packet(hdmi, false);
hdmi->audio_enable = false;
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] backlight: pwm_bl: Fix interpolation
Whenever num-interpolated-steps was larger than the distance
between 2 consecutive brightness levels the table would get really
discontinuous. The slope of the interpolation would stick with
integers only and if it was 0 the whole line segment would get skipped.
Example settings:
brightness-levels = <0 1 2 4 8 16 32 64 128 256>;
num-interpolated-steps = <16>;
The distances between 1 2 4 and 8 would be 1, and only starting with 16
it would start to interpolate properly.
Let's change it so there's always interpolation happening, even if
there's no enough points available (read: values in the table would
appear more than once). This should match the expected behavior much
more closely.
Signed-off-by: Alexandru Stan
---
drivers/video/backlight/pwm_bl.c | 70 ++--
1 file changed, 31 insertions(+), 39 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index dfc760830eb9..3e77f6b73fd9 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -230,8 +230,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
struct platform_pwm_backlight_data *data)
{
struct device_node *node = dev->of_node;
- unsigned int num_levels = 0;
- unsigned int levels_count;
+ unsigned int num_levels;
unsigned int num_steps = 0;
struct property *prop;
unsigned int *table;
@@ -260,12 +259,11 @@ static int pwm_backlight_parse_dt(struct device *dev,
if (!prop)
return 0;
- data->max_brightness = length / sizeof(u32);
+ num_levels = length / sizeof(u32);
/* read brightness levels from DT property */
- if (data->max_brightness > 0) {
- size_t size = sizeof(*data->levels) * data->max_brightness;
- unsigned int i, j, n = 0;
+ if (num_levels > 0) {
+ size_t size = sizeof(*data->levels) * num_levels;
data->levels = devm_kzalloc(dev, size, GFP_KERNEL);
if (!data->levels)
@@ -273,7 +271,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
ret = of_property_read_u32_array(node, "brightness-levels",
data->levels,
-data->max_brightness);
+num_levels);
if (ret < 0)
return ret;
@@ -298,7 +296,13 @@ static int pwm_backlight_parse_dt(struct device *dev,
* between two points.
*/
if (num_steps) {
- if (data->max_brightness < 2) {
+ unsigned int num_input_levels = num_levels;
+ unsigned int i;
+ u32 x1, x2, x, dx;
+ u32 y1, y2;
+ s64 dy;
+
+ if (num_input_levels < 2) {
dev_err(dev, "can't interpolate\n");
return -EINVAL;
}
@@ -308,14 +312,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
* taking in consideration the number of interpolated
* steps between two levels.
*/
- for (i = 0; i < data->max_brightness - 1; i++) {
- if ((data->levels[i + 1] - data->levels[i]) /
- num_steps)
- num_levels += num_steps;
- else
- num_levels++;
- }
- num_levels++;
+ num_levels = (num_input_levels - 1) * num_steps + 1;
dev_dbg(dev, "new number of brightness levels: %d\n",
num_levels);
@@ -327,24 +324,25 @@ static int pwm_backlight_parse_dt(struct device *dev,
table = devm_kzalloc(dev, size, GFP_KERNEL);
if (!table)
return -ENOMEM;
-
- /* Fill the interpolated table. */
- levels_count = 0;
- for (i = 0; i < data->max_brightness - 1; i++) {
- value = data->levels[i];
- n = (data->levels[i + 1] - value) / num_steps;
- if (n > 0) {
- for (j = 0; j < num_steps; j++) {
- table[levels_count] = value;
- value += n;
- levels_count++;
- }
- } else {
-
[PATCH v2 1/8] dt-bindings: phy: convert phy-mtk-xsphy.txt to YAML schema
Convert phy-mtk-xsphy.txt to YAML schema mediatek,xsphy.yaml Signed-off-by: Chunfeng Yun --- v2: modify description and compatible definition suggested by Rob --- .../bindings/phy/mediatek,xsphy.yaml | 200 ++ .../devicetree/bindings/phy/phy-mtk-xsphy.txt | 109 -- 2 files changed, 200 insertions(+), 109 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt diff --git a/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml new file mode 100644 index ..86511f19277a --- /dev/null +++ b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml @@ -0,0 +1,200 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/mediatek,xsphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek XS-PHY Controller Device Tree Bindings + +maintainers: + - Chunfeng Yun + +description: | + The XS-PHY controller supports physical layer functionality for USB3.1 + GEN2 controller on MediaTek SoCs. + + Banks layout of xsphy + -- + portoffsetbank + u2 port00xMISC + 0x0100FMREG + 0x0300U2PHY_COM + u2 port10x1000MISC + 0x1100FMREG + 0x1300U2PHY_COM + u2 port20x2000MISC + ... + u31 common 0x3000DIG_GLB + 0x3100PHYA_GLB + u31 port0 0x3400DIG_LN_TOP + 0x3500DIG_LN_TX0 + 0x3600DIG_LN_RX0 + 0x3700DIG_LN_DAIF + 0x3800PHYA_LN + u31 port1 0x3a00DIG_LN_TOP + 0x3b00DIG_LN_TX0 + 0x3c00DIG_LN_RX0 + 0x3d00DIG_LN_DAIF + 0x3e00PHYA_LN + ... + DIG_GLB & PHYA_GLB are shared by U31 ports. + +properties: + $nodename: +pattern: "^xs-phy@[0-9a-f]+$" + + compatible: +items: + - enum: + - mediatek,mt3611-xsphy + - mediatek,mt3612-xsphy + - const: mediatek,xsphy + + reg: +description: | + Register shared by multiple U3 ports, exclude port's private register, + if only U2 ports provided, shouldn't use the property. +maxItems: 1 + + "#address-cells": + enum: [1, 2] + + "#size-cells": + enum: [1, 2] + + ranges: true + + mediatek,src-ref-clk-mhz: +description: + Frequency of reference clock for slew rate calibrate +$ref: /schemas/types.yaml#/definitions/uint32 +default: 26 + + mediatek,src-coef: +description: + Coefficient for slew rate calibrate, depends on SoC process +$ref: /schemas/types.yaml#/definitions/uint32 +default: 17 + +# Required child node: +patternProperties: + "^usb-phy@[0-9a-f]+$": +type: object +description: | + A sub-node is required for each port the controller provides. + Address range information including the usual 'reg' property + is used inside these nodes to describe the controller's topology. + +properties: + reg: +maxItems: 1 + + clocks: +items: + - description: Reference clock, (HS is 48Mhz, SS/P is 24~27Mhz) + + clock-names: +items: + - const: ref + + "#phy-cells": +const: 1 +description: | + The cells contain the following arguments. + + - description: The PHY type + enum: +- PHY_TYPE_USB2 +- PHY_TYPE_USB3 + + #The following optional vendor properties are only for debug or HQA test + mediatek,eye-src: +description: + The value of slew rate calibrate (U2 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 7 + + mediatek,eye-vrt: +description: + The selection of VRT reference voltage (U2 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 7 + + mediatek,eye-term: +description: + The selection of HS_TX TERM reference voltage (U2 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 7 + + mediatek,efuse-intr: +description: + The selection of Internal Resistor (U2/U3 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 63 + + mediatek,efuse-tx-imp: +description: + The selection of TX Impedance (U3 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 31 + + mediatek,efuse-rx-imp: +description: + The selection of RX Impedance (U3 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 31
[PATCH v2 2/2] drm/mediatek: mtk_hdmi: add MT8167 support for HDMI
Add support for HDMI on MT8167. HDMI on MT8167 is similar to
MT8173/MT2701 execpt for the two registers: SYS_CFG1C and SYS_CFG20
Signed-off-by: Fabien Parent
---
Changelog:
v2: fix name of pdata structure
drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +++
drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 57370c036497..484ea9cd654a 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1835,9 +1835,16 @@ static struct mtk_hdmi_data mt8173_hdmi_driver_data = {
.sys_cfg20 = HDMI_SYS_CFG20,
};
+static struct mtk_hdmi_data mt8167_hdmi_driver_data = {
+ .sys_cfg1c = MT8167_HDMI_SYS_CFG1C,
+ .sys_cfg20 = MT8167_HDMI_SYS_CFG20,
+};
+
static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
{ .compatible = "mediatek,mt8173-hdmi",
.data = _hdmi_driver_data },
+ { .compatible = "mediatek,mt8167-hdmi",
+ .data = _hdmi_driver_data },
{}
};
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
index 2050ba45b23a..a0f9c367d7aa 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
@@ -195,6 +195,7 @@
#define GEN_RGB(0 << 7)
#define HDMI_SYS_CFG1C 0x000
+#define MT8167_HDMI_SYS_CFG1C 0x800
#define HDMI_ONBIT(0)
#define HDMI_RST BIT(1)
#define ANLG_ONBIT(2)
@@ -211,6 +212,7 @@
#define HTPLG_PIN_SEL_OFF BIT(30)
#define AES_EFUSE_ENABLE BIT(31)
#define HDMI_SYS_CFG20 0x004
+#define MT8167_HDMI_SYS_CFG20 0x804
#define DEEP_COLOR_MODE_MASK (3 << 1)
#define COLOR_8BIT_MODE(0 << 1)
#define COLOR_10BIT_MODE (1 << 1)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/8] dt-bindings: phy: convert HDMI PHY binding to YAML schema
Convert HDMI PHY binding to YAML schema mediatek,ufs-phy.yaml
Signed-off-by: Chunfeng Yun
---
v2: fix binding check warning of reg in example
---
.../display/mediatek/mediatek,hdmi.txt| 17 +---
.../bindings/phy/mediatek,hdmi-phy.yaml | 90 +++
2 files changed, 91 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
index 7b124242b0c5..edac18951a75 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
@@ -50,22 +50,7 @@ Required properties:
HDMI PHY
-
-The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
-output and drives the HDMI pads.
-
-Required properties:
-- compatible: "mediatek,-hdmi-phy"
-- reg: Physical base address and length of the module's registers
-- clocks: PLL reference clock
-- clock-names: must contain "pll_ref"
-- clock-output-names: must be "hdmitx_dig_cts" on mt8173
-- #phy-cells: must be <0>
-- #clock-cells: must be <0>
-
-Optional properties:
-- mediatek,ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
-- mediatek,ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
+See phy/mediatek,hdmi-phy.yaml
Example:
diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
new file mode 100644
index ..77df50204606
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,hdmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek High Definition Multimedia Interface (HDMI) PHY binding
+
+maintainers:
+ - CK Hu
+ - Chunfeng Yun
+
+description: |
+ The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
+ output and drives the HDMI pads.
+
+properties:
+ $nodename:
+pattern: "^hdmi-phy@[0-9a-f]+$"
+
+ compatible:
+enum:
+ - mediatek,mt2701-hdmi-phy
+ - mediatek,mt8173-hdmi-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: PLL reference clock
+
+ clock-names:
+items:
+ - const: pll_ref
+
+ clock-output-names:
+items:
+ - const: hdmitx_dig_cts
+
+ "#phy-cells":
+const: 0
+
+ "#clock-cells":
+const: 0
+
+ mediatek,ibias:
+description:
+ TX DRV bias current for < 1.65Gbps
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 0
+maximum: 63
+default: 0xa
+
+ mediatek,ibias_up:
+description:
+ TX DRV bias current for >= 1.65Gbps
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 0
+maximum: 63
+default: 0x1c
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - clock-output-names
+ - "#phy-cells"
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+hdmi_phy: hdmi-phy@10209100 {
+compatible = "mediatek,mt8173-hdmi-phy";
+reg = <0x10209100 0x24>;
+clocks = < CLK_APMIXED_HDMI_REF>;
+clock-names = "pll_ref";
+clock-output-names = "hdmitx_dig_cts";
+mediatek,ibias = <0xa>;
+mediatek,ibias_up = <0x1c>;
+#clock-cells = <0>;
+#phy-cells = <0>;
+};
+
+...
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Nouveau DRM failure on 5120x1440 screen with 5.8/5.9 kernel
On Tue, 13 Oct 2020, Byron Stanoszek wrote: I'm having a problem with both the 5.8 and 5.9 kernels using the nouveau DRM driver. I have a laptop with a VGA card (specs below) connected to a 5120x1440 screen. At boot time, the card correctly detects the screen, tries to allocate fbdev fb0, then the video hangs completely for 15-30 seconds until it goes blank. This message eventually displays after a while: Workqueue: nvkm-disp nv50_disp_super RIP: 0010:nv50_disp_super_2_2+0x1b0/0x470 Code: 69 00 00 48 69 c0 d3 4d 62 10 48 c1 e8 26 49 89 c5 0f b7 43 40 44 89 e9 8d 44 02 f9 0f b7 53 46 29 d0 31 d2 48 98 49 0f af c4 <48> f7 f1 48 89 c6 0f b7 43 4e 0f b7 53 4c 83 e8 19 29 d0 31 d2 48 RSP: 0018:c95e3e08 EFLAGS: 00010206 RAX: RBX: 88841b08ed20 RCX: RDX: RSI: c90003614200 RDI: 820c1140 RBP: 88841b202060 R08: R09: 61ce R10: 0018 R11: 0018 R12: R13: R14: 88841b96b800 R15: 88841b975000 FS: () GS:88841dc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f922e61e000 CR3: 0240a004 CR4: 001706b0 Call Trace: ? nvkm_dp_disable+0x5d/0x70 ? nv50_disp_super+0x137/0x220 ? process_one_work+0x19c/0x2c0 ? worker_thread+0x48/0x350 ? process_one_work+0x2c0/0x2c0 ? kthread+0x129/0x150 ? __kthread_create_worker+0x100/0x100 ? ret_from_fork+0x22/0x30 ---[ end trace dbb0d14fd1ddb445 ]--- nouveau :01:00.0: DRM: core notifier timeout Thanks, -Byron ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Nouveau DRM failure on 5120x1440 screen with 5.8/5.9 kernel
I'm having a problem with both the 5.8 and 5.9 kernels using the nouveau DRM driver. I have a laptop with a VGA card (specs below) connected to a 5120x1440 screen. At boot time, the card correctly detects the screen, tries to allocate fbdev fb0, then the video hangs completely for 15-30 seconds until it goes blank. This used to work in Linux 5.7 and earlier, although it allocated a 3840x1080 fb instead of a 5120x1440. I've attached the full dmesg. I tried commands like video=DP-2:3840x1080 but it doesn't help. Linux 5.8 boots without hanging if the laptop is not connected to the 5120x1440 screen. PCI specs: 01:00.0 0300: 10de:0dfc (rev a1) 01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [NVS 5200M] (rev a1) xrandr available resolutions reported (from Linux 5.7 using Xorg): Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384 LVDS-1 unknown connection (normal left inverted right x axis y axis) 1600x900 59.99 + 40.00 5120x1440 60.00 1360x1020 73.97 1152x864 59.97 1024x768 59.95 800x600 59.96 640x480 59.94 DP-1 disconnected (normal left inverted right x axis y axis) DP-2 connected primary 5120x1440+0+0 (normal left inverted right x axis y axis) 1200mm x 340mm panning 5120x1440+0+0 3840x1080 59.97 + 5120x1440 29.98* 2560x1080 60.0059.9459.98 1920x1080 60.0060.0050.0059.94 1920x1080i60.0050.0059.94 1600x1200 60.00 1280x1024 75.0260.02 1280x800 59.81 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0360.00 800x600 75.0060.32 720x576 50.00 720x480 60.0059.94 640x480 75.0060.0059.94 720x400 70.08 HDMI-1 disconnected (normal left inverted right x axis y axis) VGA-1 disconnected (normal left inverted right x axis y axis) I'm currently using 5120x1440@30. 60 Hz isn't available. But look below: xrandr resolutions from Linux 5.9 (even though screen is still blank): Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384 LVDS-1 unknown connection (normal left inverted right x axis y axis) 1600x900 59.99 + 40.00 5120x1440 60.00 1360x1020 73.97 1152x864 59.97 1024x768 59.95 800x600 59.96 640x480 59.94 DP-1 disconnected (normal left inverted right x axis y axis) DP-2 connected primary 5120x1440+0+0 (normal left inverted right x axis y axis) 1200mm x 340mm panning 5120x1440+0+0 5120x1440 59.98 + 29.98* 3840x1080 59.97 + 2560x1080 60.0059.9459.98 1920x1080 60.0060.0050.0059.94 1920x1080i60.0050.0059.94 1600x1200 60.00 1280x1024 75.0260.02 1280x800 59.81 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0360.00 800x600 75.0060.32 720x576 50.00 720x480 60.0059.94 640x480 75.0060.0059.94 720x400 70.08 HDMI-1 disconnected (normal left inverted right x axis y axis) VGA-1 disconnected (normal left inverted right x axis y axis) Let me know if you need additional debug information/etc. Thanks, -Byron microcode: microcode updated early to revision 0x21, date = 2019-02-13 Linux version 5.9.0 (r...@iss.comtime.lan) (gcc (Gentoo 10.2.0-r2 p3) 10.2.0, GNU ld (Gentoo 2.35.1 p1) 2.35.1) #2 SMP PREEMPT Tue Oct 13 14:54:36 EDT 2020 Command line: auto BOOT_IMAGE=cti ro root=801 cti KERNEL supported cpus: Intel GenuineIntel x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009e7ff] usable BIOS-e820: [mem 0x0009e800-0x0009] reserved BIOS-e820: [mem 0x000e-0x000f] reserved BIOS-e820: [mem 0x0010-0xc9f09fff] usable BIOS-e820: [mem 0xc9f0a000-0xc9ff] reserved BIOS-e820: [mem 0xca00-0xca752fff] usable BIOS-e820: [mem 0xca753000-0xca7f] reserved BIOS-e820: [mem 0xca80-0xcafb1fff] usable BIOS-e820: [mem 0xcafb2000-0xcaff] ACPI data BIOS-e820: [mem 0xcb00-0xcc6fbfff] usable BIOS-e820: [mem 0xcc6fc000-0xcc7f] ACPI NVS BIOS-e820: [mem 0xcc80-0xcdda0fff] usable BIOS-e820: [mem 0xcdda1000-0xce7a4fff] reserved BIOS-e820: [mem 0xce7a5000-0xce7e7fff] ACPI NVS BIOS-e820: [mem 0xce7e8000-0xcf2b2fff] usable BIOS-e820: [mem 0xcf2b3000-0xcf7e] reserved BIOS-e820: [mem
[PATCH 2/2] drm/mediatek: mtk_hdmi: add MT8167 support for HDMI
Add support for HDMI on MT8167. HDMI on MT8167 is similar to
MT8173/MT2701 execpt for the two registers: SYS_CFG1C and SYS_CFG20
Signed-off-by: Fabien Parent
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +++
drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index c70f195c21be..7762be5cb446 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1835,9 +1835,16 @@ static struct mtk_hdmi_data mt8173_hdmi_driver_data = {
.sys_cfg20 = HDMI_SYS_CFG20,
};
+static struct mtk_hdmi_conf mt8167_hdmi_driver_data = {
+ .sys_cfg1c = MT8167_HDMI_SYS_CFG1C,
+ .sys_cfg20 = MT8167_HDMI_SYS_CFG20,
+};
+
static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
{ .compatible = "mediatek,mt8173-hdmi",
.data = _hdmi_driver_data },
+ { .compatible = "mediatek,mt8167-hdmi",
+ .data = _hdmi_driver_data },
{}
};
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
index 2050ba45b23a..a0f9c367d7aa 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
@@ -195,6 +195,7 @@
#define GEN_RGB(0 << 7)
#define HDMI_SYS_CFG1C 0x000
+#define MT8167_HDMI_SYS_CFG1C 0x800
#define HDMI_ONBIT(0)
#define HDMI_RST BIT(1)
#define ANLG_ONBIT(2)
@@ -211,6 +212,7 @@
#define HTPLG_PIN_SEL_OFF BIT(30)
#define AES_EFUSE_ENABLE BIT(31)
#define HDMI_SYS_CFG20 0x004
+#define MT8167_HDMI_SYS_CFG20 0x804
#define DEEP_COLOR_MODE_MASK (3 << 1)
#define COLOR_8BIT_MODE(0 << 1)
#define COLOR_10BIT_MODE (1 << 1)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
You mean, like
static void memcpy_from_page(char *to, struct page *page, size_t offset, size_t
len)
{
char *from = kmap_atomic(page);
memcpy(to, from + offset, len);
kunmap_atomic(from);
}
static void memcpy_to_page(struct page *page, size_t offset, const char *from,
size_t len)
{
char *to = kmap_atomic(page);
memcpy(to + offset, from, len);
kunmap_atomic(to);
}
static void memzero_page(struct page *page, size_t offset, size_t len)
{
char *addr = kmap_atomic(page);
memset(addr + offset, 0, len);
kunmap_atomic(addr);
}
in lib/iov_iter.c? FWIW, I don't like that "highpage" in the name and
highmem.h as location - these make perfect sense regardless of highmem;
they are normal memory operations with page + offset used instead of
a pointer...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/msm/dp: fixes wrong connection state caused by failure of link train
Connection state is not set correctly happen when either failure of link
train due to cable unplugged in the middle of aux channel reading or
cable plugged in while in suspended state. This patch fixes these problems.
This patch also replace ST_SUSPEND_PENDING with ST_DISPLAY_OFF.
Changes in V2:
-- Add more information to commit message.
Changes in V3:
-- change base
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 40 ++---
drivers/gpu/drm/msm/dp/dp_panel.c | 5
2 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index d9164ff6515d..c0665a0a4c78 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -45,7 +45,7 @@ enum {
ST_CONNECT_PENDING,
ST_CONNECTED,
ST_DISCONNECT_PENDING,
- ST_SUSPEND_PENDING,
+ ST_DISPLAY_OFF,
ST_SUSPENDED,
};
@@ -503,7 +503,7 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
mutex_lock(>event_mutex);
state = dp->hpd_state;
- if (state == ST_SUSPEND_PENDING) {
+ if (state == ST_DISPLAY_OFF || state == ST_SUSPENDED) {
mutex_unlock(>event_mutex);
return 0;
}
@@ -525,14 +525,14 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
hpd->hpd_high = 1;
ret = dp_display_usbpd_configure_cb(>pdev->dev);
- if (ret) { /* failed */
+ if (ret) { /* link train failed */
hpd->hpd_high = 0;
dp->hpd_state = ST_DISCONNECTED;
+ } else {
+ /* start sentinel checking in case of missing uevent */
+ dp_add_event(dp, EV_CONNECT_PENDING_TIMEOUT, 0, tout);
}
- /* start sanity checking */
- dp_add_event(dp, EV_CONNECT_PENDING_TIMEOUT, 0, tout);
-
mutex_unlock(>event_mutex);
/* uevent will complete connection part */
@@ -577,11 +577,6 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
mutex_lock(>event_mutex);
state = dp->hpd_state;
- if (state == ST_SUSPEND_PENDING) {
- mutex_unlock(>event_mutex);
- return 0;
- }
-
if (state == ST_DISCONNECT_PENDING || state == ST_DISCONNECTED) {
mutex_unlock(>event_mutex);
return 0;
@@ -608,7 +603,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
*/
dp_display_usbpd_disconnect_cb(>pdev->dev);
- /* start sanity checking */
+ /* start sentinel checking in case of missing uevent */
dp_add_event(dp, EV_DISCONNECT_PENDING_TIMEOUT, 0, DP_TIMEOUT_5_SECOND);
/* signal the disconnect event early to ensure proper teardown */
@@ -648,7 +643,7 @@ static int dp_irq_hpd_handle(struct dp_display_private *dp,
u32 data)
/* irq_hpd can happen at either connected or disconnected state */
state = dp->hpd_state;
- if (state == ST_SUSPEND_PENDING) {
+ if (state == ST_DISPLAY_OFF) {
mutex_unlock(>event_mutex);
return 0;
}
@@ -1073,7 +1068,7 @@ static irqreturn_t dp_display_irq_handler(int irq, void
*dev_id)
}
if (hpd_isr_status & DP_DP_IRQ_HPD_INT_MASK) {
- /* delete connect pending event first */
+ /* stop sentinel connect pending checking */
dp_del_event(dp, EV_CONNECT_PENDING_TIMEOUT);
dp_add_event(dp, EV_IRQ_HPD_INT, 0, 0);
}
@@ -1204,13 +1199,10 @@ static int dp_pm_resume(struct device *dev)
status = dp_catalog_hpd_get_state_status(dp->catalog);
- if (status) {
+ if (status)
dp->dp_display.is_connected = true;
- } else {
+ else
dp->dp_display.is_connected = false;
- /* make sure next resume host_init be called */
- dp->core_initialized = false;
- }
mutex_unlock(>event_mutex);
@@ -1232,6 +1224,9 @@ static int dp_pm_suspend(struct device *dev)
dp->hpd_state = ST_SUSPENDED;
+ /* host_init will be called at pm_resume */
+ dp->core_initialized = false;
+
mutex_unlock(>event_mutex);
return 0;
@@ -1361,6 +1356,7 @@ int msm_dp_display_enable(struct msm_dp *dp, struct
drm_encoder *encoder)
mutex_lock(_display->event_mutex);
+ /* stop sentinel checking */
dp_del_event(dp_display, EV_CONNECT_PENDING_TIMEOUT);
rc = dp_display_set_mode(dp, _display->dp_mode);
@@ -1391,7 +1387,8 @@ int msm_dp_display_enable(struct msm_dp *dp, struct
drm_encoder *encoder)
dp_display_unprepare(dp);
}
- if (state == ST_SUSPEND_PENDING)
+ /* manual kick off plug event to train link */
+ if (state
[PATCH v2 7/8] dt-bindings: usb: convert mediatek, mtu3.txt to YAML schema
Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml
Signed-off-by: Chunfeng Yun
---
v2: new patch
---
.../devicetree/bindings/usb/mediatek,mtu3.txt | 108 -
.../bindings/usb/mediatek,mtu3.yaml | 227 ++
2 files changed, 227 insertions(+), 108 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
deleted file mode 100644
index a82ca438aec1..
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
+++ /dev/null
@@ -1,108 +0,0 @@
-The device node for Mediatek USB3.0 DRD controller
-
-Required properties:
- - compatible : should be "mediatek,-mtu3", "mediatek,mtu3",
- soc-model is the name of SoC, such as mt8173, mt2712 etc,
- when using "mediatek,mtu3" compatible string, you need SoC specific
- ones in addition, one of:
- - "mediatek,mt8173-mtu3"
- - reg : specifies physical base address and size of the registers
- - reg-names: should be "mac" for device IP and "ippc" for IP port control
- - interrupts : interrupt used by the device IP
- - power-domains : a phandle to USB power domain node to control USB's
- mtcmos
- - vusb33-supply : regulator of USB avdd3.3v
- - clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
- - clock-names : must contain "sys_ck" for clock of controller,
- the following clocks are optional:
- "ref_ck", "mcu_ck" and "dma_ck";
- - phys : see usb-hcd.yaml in the current directory
- - dr_mode : should be one of "host", "peripheral" or "otg",
- refer to usb/generic.txt
-
-Optional properties:
- - #address-cells, #size-cells : should be '2' if the device has sub-nodes
- with 'reg' property
- - ranges : allows valid 1:1 translation between child's address space and
- parent's address space
- - extcon : external connector for vbus and idpin changes detection, needed
- when supports dual-role mode.
- it's considered valid for compatibility reasons, not allowed for
- new bindings, and use "usb-role-switch" property instead.
- - vbus-supply : reference to the VBUS regulator, needed when supports
- dual-role mode.
- it's considered valid for compatibility reasons, not allowed for
- new bindings, and put into a usb-connector node.
- see connector/usb-connector.yaml.
- - pinctrl-names : a pinctrl state named "default" is optional, and need be
- defined if auto drd switch is enabled, that means the property dr_mode
- is set as "otg", and meanwhile the property "mediatek,enable-manual-drd"
- is not set.
- - pinctrl-0 : pin control group
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
- - maximum-speed : valid arguments are "super-speed", "high-speed" and
- "full-speed"; refer to usb/generic.txt
- - usb-role-switch : use USB Role Switch to support dual-role switch, but
- not extcon; see usb/generic.txt.
- - enable-manual-drd : supports manual dual-role switch via debugfs; usually
- used when receptacle is TYPE-A and also wants to support dual-role
- mode.
- - wakeup-source: enable USB remote wakeup of host mode.
- - mediatek,syscon-wakeup : phandle to syscon used to access the register
- of the USB wakeup glue layer between SSUSB and SPM; it depends on
- "wakeup-source", and has two arguments:
- - the first one : register base address of the glue layer in syscon;
- - the second one : hardware version of the glue layer
- - 1 : used by mt8173 etc
- - 2 : used by mt2712 etc
- - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
- bit1 for u3port1, ... etc;
-
-additionally the properties from usb-hcd.yaml (in the current directory) are
-supported.
-
-Sub-nodes:
-The xhci should be added as subnode to mtu3 as shown in the following example
-if host mode is enabled. The DT binding details of xhci can be found in:
-Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
-
-The port would be added as subnode if use "usb-role-switch" property.
- see graph.txt
-
-Example:
-ssusb: usb@11271000 {
- compatible = "mediatek,mt8173-mtu3";
- reg = <0 0x11271000 0 0x3000>,
- <0 0x11280700 0 0x0100>;
- reg-names = "mac", "ippc";
- interrupts = ;
- phys = <_port0 PHY_TYPE_USB3>,
- <_port1 PHY_TYPE_USB2>;
- power-domains = < MT8173_POWER_DOMAIN_USB>;
- clocks = < CLK_TOP_USB30_SEL>, <>,
-< CLK_PERI_USB0>,
-< CLK_PERI_USB1>;
- clock-names = "sys_ck", "ref_ck";
- vusb33-supply = <_vusb_reg>;
- vbus-supply = <_p0_vbus>;
- extcon = <_usb>;
- dr_mode = "otg";
- wakeup-source;
-
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Fri, 9 Oct 2020, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
Acked-by: Nicolas Pitre
> fs/cramfs/inode.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 912308600d39..003c014a42ed 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block *sb,
> unsigned int offset,
> struct page *page = pages[i];
>
> if (page) {
> - memcpy(data, kmap(page), PAGE_SIZE);
> - kunmap(page);
> + memcpy(data, kmap_thread(page), PAGE_SIZE);
> + kunmap_thread(page);
> put_page(page);
> } else
> memset(data, 0, PAGE_SIZE);
> @@ -826,7 +826,7 @@ static int cramfs_readpage(struct file *file, struct page
> *page)
>
> maxblock = (inode->i_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> bytes_filled = 0;
> - pgdata = kmap(page);
> + pgdata = kmap_thread(page);
>
> if (page->index < maxblock) {
> struct super_block *sb = inode->i_sb;
> @@ -914,13 +914,13 @@ static int cramfs_readpage(struct file *file, struct
> page *page)
>
> memset(pgdata + bytes_filled, 0, PAGE_SIZE - bytes_filled);
> flush_dcache_page(page);
> - kunmap(page);
> + kunmap_thread(page);
> SetPageUptodate(page);
> unlock_page(page);
> return 0;
>
> err:
> - kunmap(page);
> + kunmap_thread(page);
> ClearPageUptodate(page);
> SetPageError(page);
> unlock_page(page);
> --
> 2.28.0.rc0.12.gb6a658bd00c9
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/mediatek: mtk_hdmi: move 2 registers address into of_data
On MT8167, the two registers SYS_CFG1C and SYS_CFG20 don't have the
same address as on MT8173. Add OF data in order to store the address
of these two registers.
Signed-off-by: Fabien Parent
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 45 ++---
1 file changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index a97725680d4e..c70f195c21be 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -36,6 +36,11 @@
#define NCTS_BYTES 7
+struct mtk_hdmi_data {
+ uint32_t sys_cfg1c;
+ uint32_t sys_cfg20;
+};
+
enum mtk_hdmi_clk_id {
MTK_HDMI_CLK_HDMI_PIXEL,
MTK_HDMI_CLK_HDMI_PLL,
@@ -146,6 +151,7 @@ struct hdmi_audio_param {
};
struct mtk_hdmi {
+ const struct mtk_hdmi_data *data;
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
struct drm_connector conn;
@@ -244,21 +250,24 @@ static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi
*hdmi, bool enable)
*/
if (hdmi_phy->conf && hdmi_phy->conf->tz_disabled)
regmap_update_bits(hdmi->sys_regmap,
- hdmi->sys_offset + HDMI_SYS_CFG20,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
0x80008005, enable ? 0x8005 : 0x8000);
else
arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904,
0x8000, 0, 0, 0, 0, 0, );
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
HDMI_ON | ANLG_ON, enable ? (HDMI_ON | ANLG_ON) : 0);
}
static void mtk_hdmi_hw_1p4_version_enable(struct mtk_hdmi *hdmi, bool enable)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI2P0_EN, enable ? 0 : HDMI2P0_EN);
}
@@ -274,12 +283,15 @@ static void mtk_hdmi_hw_aud_unmute(struct mtk_hdmi *hdmi)
static void mtk_hdmi_hw_reset(struct mtk_hdmi *hdmi)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
HDMI_RST, HDMI_RST);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
HDMI_RST, 0);
mtk_hdmi_clear_bits(hdmi, GRL_CFG3, CFG3_CONTROL_PACKET_DELAY);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
ANLG_ON, ANLG_ON);
}
@@ -362,16 +374,19 @@ static void mtk_hdmi_hw_send_aud_packet(struct mtk_hdmi
*hdmi, bool enable)
static void mtk_hdmi_hw_config_sys(struct mtk_hdmi *hdmi)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI_OUT_FIFO_EN | MHL_MODE_ON, 0);
usleep_range(2000, 4000);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI_OUT_FIFO_EN | MHL_MODE_ON, HDMI_OUT_FIFO_EN);
}
static void mtk_hdmi_hw_set_deep_color_mode(struct mtk_hdmi *hdmi)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
DEEP_COLOR_MODE_MASK | DEEP_COLOR_EN,
COLOR_8BIT_MODE);
}
@@ -1733,6 +1748,7 @@ static int mtk_drm_hdmi_probe(struct platform_device
*pdev)
return -ENOMEM;
hdmi->dev = dev;
+ hdmi->conf = of_device_get_match_data(dev);
ret = mtk_hdmi_dt_parse_pdata(hdmi, pdev);
if (ret)
@@ -1813,8 +1829,15 @@ static int mtk_hdmi_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mtk_hdmi_pm_ops,
mtk_hdmi_suspend, mtk_hdmi_resume);
+
+static struct mtk_hdmi_data
[PATCH v2] drm/virtio: Use UUID API for importing the UUID
There is import_uuid() function which imports u8 array to the uuid_t.
Use it instead of open coding variant.
This allows to hide the uuid_t internals.
Reviewed-by: David Stevens
Signed-off-by: Andy Shevchenko
---
v2: rebased on top of drm-misc-next (Gerd), added Rb tag (David)
drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 6434b9fb38a6..c1824f536936 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -1141,7 +1141,7 @@ static void virtio_gpu_cmd_resource_uuid_cb(struct
virtio_gpu_device *vgdev,
if (resp_type == VIRTIO_GPU_RESP_OK_RESOURCE_UUID &&
obj->uuid_state == STATE_INITIALIZING) {
- memcpy(>uuid.b, resp->uuid, sizeof(obj->uuid.b));
+ import_uuid(>uuid, resp->uuid);
obj->uuid_state = STATE_OK;
} else {
obj->uuid_state = STATE_ERR;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/msm/dp: return correct connection status after suspend
Quoting Kuogee Hsieh (2020-10-13 16:35:22) > During suspend, dp host controller and hpd block are disabled due to > both ahb and aux clock are disabled. Therefore hpd plug/unplug interrupts > will not be generated. At dp_pm_resume(), reinitialize both dp host > controller and hpd block so that hpd plug/unplug interrupts will be > generated and handled by driver so that hpd connection state is updated > correctly. This patch will fix link training flaky issues. > > Changes in v2: > -- use container_of to cast correct dp_display_private pointer >at both dp_pm_suspend() and dp_pm_resume(). > > Changes in v3: > -- replace hpd_state atomic_t with u32 > > Changes in v4 > -- call dp_display_host_deinit() at dp_pm_suspend() > -- call dp_display_host_init() at msm_dp_display_enable() > -- fix phy->init_count unbalance which causes link training failed > > Signed-off-by: Kuogee Hsieh > --- Can we add some sort of Fixes tag? Maybe the beginning of this DP driver support? Tested-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/8] dt-bindings: phy: convert phy-mtk-tphy.txt to YAML schema
Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml Signed-off-by: Chunfeng Yun --- v2: modify description and compatible --- .../bindings/phy/mediatek,tphy.yaml | 263 ++ .../devicetree/bindings/phy/phy-mtk-tphy.txt | 162 --- 2 files changed, 263 insertions(+), 162 deletions(-) create mode 100755 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml new file mode 100755 index ..56ad8be69095 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -0,0 +1,263 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/mediatek,tphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek T-PHY Controller Device Tree Bindings + +maintainers: + - Chunfeng Yun + +description: | + The T-PHY controller supports physical layer functionality for a number of + controllers on MediaTek SoCs, includes USB2.0, USB3.0, PCIe and SATA. + + Layout differences of banks between T-PHY V1 (mt8173/mt2701) and + T-PHY V2 (mt2712) when works on USB mode: + --- + Version 1: + portoffsetbank + shared 0xSPLLC + 0x0100FMREG + u2 port00x0800U2PHY_COM + u3 port00x0900U3PHYD + 0x0a00U3PHYD_BANK2 + 0x0b00U3PHYA + 0x0c00U3PHYA_DA + u2 port10x1000U2PHY_COM + u3 port10x1100U3PHYD + 0x1200U3PHYD_BANK2 + 0x1300U3PHYA + 0x1400U3PHYA_DA + u2 port20x1800U2PHY_COM + ... + + Version 2: + portoffsetbank + u2 port00xMISC + 0x0100FMREG + 0x0300U2PHY_COM + u3 port00x0700SPLLC + 0x0800CHIP + 0x0900U3PHYD + 0x0a00U3PHYD_BANK2 + 0x0b00U3PHYA + 0x0c00U3PHYA_DA + u2 port10x1000MISC + 0x1100FMREG + 0x1300U2PHY_COM + u3 port10x1700SPLLC + 0x1800CHIP + 0x1900U3PHYD + 0x1a00U3PHYD_BANK2 + 0x1b00U3PHYA + 0x1c00U3PHYA_DA + u2 port20x2000MISC + ... + + SPLLC shared by u3 ports and FMREG shared by u2 ports on V1 are put back + into each port; a new bank MISC for u2 ports and CHIP for u3 ports are + added on V2. + +properties: + $nodename: + pattern: "^t-phy@[0-9a-f]+$" + + compatible: +oneOf: + - items: + - enum: + - mediatek,mt2701-tphy + - mediatek,mt7623-tphy + - mediatek,mt7622-tphy + - mediatek,mt8516-tphy + - const: mediatek,generic-tphy-v1 + - items: + - enum: + - mediatek,mt2712-tphy + - mediatek,mt7629-tphy + - mediatek,mt8183-tphy + - const: mediatek,generic-tphy-v2 + - const: mediatek,mt2701-u3phy +deprecated: true + - const: mediatek,mt2712-u3phy +deprecated: true + - const: mediatek,mt8173-u3phy + + reg: +description: | + Register shared by multiple ports, exclude port's private register. + It is needed for T-PHY V1, such as mt2701 and mt8173, but not for + T-PHY V2, such as mt2712. +maxItems: 1 + + "#address-cells": + enum: [1, 2] + + "#size-cells": + enum: [1, 2] + + # Used with non-empty value if optional 'reg' is not provided. + # The format of the value is an arbitrary number of triplets of + # (child-bus-address, parent-bus-address, length). + ranges: true + + mediatek,src-ref-clk-mhz: +description: + Frequency of reference clock for slew rate calibrate +$ref: /schemas/types.yaml#/definitions/uint32 +default: 26 + + mediatek,src-coef: +description: + Coefficient for slew rate calibrate, depends on SoC process +$ref: /schemas/types.yaml#/definitions/uint32 +default: 28 + +# Required child node: +patternProperties: + "^usb-phy@[0-9a-f]+$": +type: object +description: | + A sub-node is required for each port the controller provides. + Address range information including the usual 'reg' property + is used inside these nodes to describe the controller's topology. + +properties: + reg: +maxItems: 1 + + clocks: +minItems: 1 +maxItems: 2 +items: + - description: Reference clock, (HS is 48Mhz, SS/P is 24~27Mhz) + - description: Reference clock of analog phy +description: | + Uses both clocks if the clock of analog and digital phys are +
