Re: [PATCH v5 08/15] mm: Add unsafe_follow_pfn
On Mon, Nov 2, 2020 at 4:52 PM Jason Gunthorpe wrote: > > On Mon, Nov 02, 2020 at 02:23:58PM +0100, Daniel Vetter wrote: > > On Mon, Nov 2, 2020 at 2:01 PM Jason Gunthorpe wrote: > > > > > > On Mon, Nov 02, 2020 at 01:56:10PM +0100, Daniel Vetter wrote: > > > > On Mon, Nov 2, 2020 at 8:29 AM Christoph Hellwig > > > > wrote: > > > > > > > > > > On Fri, Oct 30, 2020 at 11:08:08AM +0100, Daniel Vetter wrote: > > > > > > Also mark up follow_pfn as EXPORT_SYMBOL_GPL. The only safe way to > > > > > > use > > > > > > that by drivers/modules is together with an mmu_notifier, and that's > > > > > > all _GPL stuff. > > > > > > > > > > I also think it also needs to be renamed to explicitly break any > > > > > existing > > > > > users out of tree or int the submission queue. > > > > > > > > Ok I looked at the mmu notifier locking again and noticed that > > > > mm->subscriptions has its own spinlock. Since there usually shouldn't > > > > be a huge pile of these I think it's feasible to check for the mmu > > > > notifier in follow_pfn. And that would stuff this gap for good. I'll > > > > throw that on top as a final patch and see what people think. > > > > > > Probably the simplest is to just check mm_has_notifiers() when in > > > lockdep or something very simple like that > > > > lockdep feels wrong, was locking more at CONFIG_DEBUG_VM. And since > > generally you only have 1 mmu notifier (especially for kvm) I think we > > can also pay the 2nd cacheline miss and actually check the right mmu > > notifier is registered. > > Need to hold the lock to check that and there are two ways to register > notifiers these days, so it feels to expensive to me. Uh I mixed stuff up all along, struct mmu_notifier *subcription that all the mmu notifier users use has the ->mm pointer we want right there. That's good enough I think. Now I'm kinda lost in kvm code trying to wire it through, but it's looking ok-ish thus far :-) -Daniel > CH's 'export symbol only for kvm' really does seem the most robust way > to handle this though. > > Jason -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amd/pm: remove unused variable
Hi Zou,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20201102]
url:
https://github.com/0day-ci/linux/commits/Zou-Wei/drm-amd-pm-remove-unused-variable/20201102-195853
base:b49976d8ef6448e86a7fda6a86f64867942b442d
config: x86_64-randconfig-a004-20201102 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
cc91554ebb66e8c9a4b8c67ca2f1343eaac10cf6)
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 x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/4a14c85aff468b2d26c02415991b440b0b56fc75
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Zou-Wei/drm-amd-pm-remove-unused-variable/20201102-195853
git checkout 4a14c85aff468b2d26c02415991b440b0b56fc75
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:402:3: error: use
>> of undeclared identifier 'ret'
ret = vangogh_get_smu_metrics_data(smu,
^
1 error generated.
vim +/ret +402 drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c
271ab489f755245 Xiaojian Du 2020-10-26 392
271ab489f755245 Xiaojian Du 2020-10-26 393 static int
vangogh_get_current_activity_percent(struct smu_context *smu,
271ab489f755245 Xiaojian Du 2020-10-26 394
enum amd_pp_sensors sensor,
271ab489f755245 Xiaojian Du 2020-10-26 395
uint32_t *value)
271ab489f755245 Xiaojian Du 2020-10-26 396 {
271ab489f755245 Xiaojian Du 2020-10-26 397 if (!value)
271ab489f755245 Xiaojian Du 2020-10-26 398 return -EINVAL;
271ab489f755245 Xiaojian Du 2020-10-26 399
271ab489f755245 Xiaojian Du 2020-10-26 400 switch (sensor) {
271ab489f755245 Xiaojian Du 2020-10-26 401 case AMDGPU_PP_SENSOR_GPU_LOAD:
271ab489f755245 Xiaojian Du 2020-10-26 @402 ret =
vangogh_get_smu_metrics_data(smu,
271ab489f755245 Xiaojian Du 2020-10-26 403
METRICS_AVERAGE_GFXACTIVITY,
271ab489f755245 Xiaojian Du 2020-10-26 404
value);
271ab489f755245 Xiaojian Du 2020-10-26 405 break;
271ab489f755245 Xiaojian Du 2020-10-26 406 default:
271ab489f755245 Xiaojian Du 2020-10-26 407 dev_err(smu->adev->dev,
"Invalid sensor for retrieving clock activity\n");
271ab489f755245 Xiaojian Du 2020-10-26 408 return -EINVAL;
271ab489f755245 Xiaojian Du 2020-10-26 409 }
271ab489f755245 Xiaojian Du 2020-10-26 410
271ab489f755245 Xiaojian Du 2020-10-26 411 return 0;
271ab489f755245 Xiaojian Du 2020-10-26 412 }
271ab489f755245 Xiaojian Du 2020-10-26 413
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/6] dt-bindings: display: Add support for Intel KeemBay Display
Hi Neil. > > --- > > .../bindings/display/intel,keembay-display.yaml| 75 > > ++ > > 1 file changed, 75 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/intel,keembay-display.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml > > b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml > > new file mode 100644 > > index 000..8a8effe > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml > > @@ -0,0 +1,75 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/intel,keembay-display.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Devicetree bindings for Intel Keem Bay display controller > > + > > +maintainers: > > + - Anitha Chrisanthus > > + - Edmond J Dea > > + > > +properties: > > + compatible: > > +const: intel,keembay-display > > + > > + reg: > > +items: > > + - description: LCD registers range > > + - description: Msscam registers range > > + > >>> > >>> Indeed the split is much better, but as you replied on > >>> http://lore.kernel.org/r/by5pr11mb41827de07436dd0454e24e6e8c...@by5pr11mb4182.namprd11.prod.outlook.com > >>> the msscam seems to be shared with the camera subsystem block, if this is > >>> the case it should be handled. > >>> > >>> If it's a shared register block, it could be defined as a "syscon" used > >>> by both subsystems. > >> > >> I think I got it now. > >> > >> msscam is used to enable clocks both for the display driver and the > >> mipi-dsi part. > > > > If just clocks, then the msscam should be a clock provider possibly. > > If not, then the below looks right. I am feeling a little clueless here - sorry. Can you help with any example that does this? Everything I looked up in bindings/clock/ had a "#clock-cells" which is not relevant for msscam - or so I think at least. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM
On Fri, Oct 30, 2020 at 3:38 PM Daniel Vetter wrote:
>
> On Fri, Oct 30, 2020 at 3:11 PM Tomasz Figa wrote:
> >
> > On Fri, Oct 30, 2020 at 11:08 AM Daniel Vetter
> > wrote:
> > >
> > > This is used by media/videbuf2 for persistent dma mappings, not just
> > > for a single dma operation and then freed again, so needs
> > > FOLL_LONGTERM.
> > >
> > > Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
> > > locking issues. Rework the code to pull the pup path out from the
> > > mmap_sem critical section as suggested by Jason.
> > >
> > > By relying entirely on the vma checks in pin_user_pages and follow_pfn
> > > (for vm_flags and vma_is_fsdax) we can also streamline the code a lot.
> > >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Jason Gunthorpe
> > > Cc: Pawel Osciak
> > > Cc: Marek Szyprowski
> > > Cc: Kyungmin Park
> > > Cc: Tomasz Figa
> > > Cc: Mauro Carvalho Chehab
> > > Cc: Andrew Morton
> > > Cc: John Hubbard
> > > Cc: Jérôme Glisse
> > > Cc: Jan Kara
> > > Cc: Dan Williams
> > > Cc: linux...@kvack.org
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: linux-samsung-...@vger.kernel.org
> > > Cc: linux-me...@vger.kernel.org
> > > Signed-off-by: Daniel Vetter
> > > --
> > > v2: Streamline the code and further simplify the loop checks (Jason)
> > >
> > > v5: Review from Tomasz:
> > > - fix page counting for the follow_pfn case by resetting ret
> > > - drop gup_flags paramater, now unused
> > > ---
> > > .../media/common/videobuf2/videobuf2-memops.c | 3 +-
> > > include/linux/mm.h| 2 +-
> > > mm/frame_vector.c | 53 ++-
> > > 3 files changed, 19 insertions(+), 39 deletions(-)
> > >
> >
> > Thanks, looks good to me now.
> >
> > Acked-by: Tomasz Figa
> >
> > From reading the code, this is quite unlikely to introduce any
> > behavior changes, but just to be safe, did you have a chance to test
> > this with some V4L2 driver?
>
> Nah, unfortunately not.
I believe we don't have any setup that could exercise the IO/PFNMAP
user pointers, but it should be possible to exercise the basic userptr
path by enabling the virtual (fake) video driver, vivid or
CONFIG_VIDEO_VIVID, in your kernel and then using yavta [1] with
--userptr and --capture= (and possibly some more
options) to grab a couple of frames from the test pattern generator.
Does it sound like something that you could give a try? Feel free to
ping me on IRC (tfiga on #v4l or #dri-devel) if you need any help.
[1] https://git.ideasonboard.org/yavta.git
Best regards,
Tomasz
> -Daniel
>
> >
> > Best regards,
> > Tomasz
> >
> > > diff --git a/drivers/media/common/videobuf2/videobuf2-memops.c
> > > b/drivers/media/common/videobuf2/videobuf2-memops.c
> > > index 6e9e05153f4e..9dd6c27162f4 100644
> > > --- a/drivers/media/common/videobuf2/videobuf2-memops.c
> > > +++ b/drivers/media/common/videobuf2/videobuf2-memops.c
> > > @@ -40,7 +40,6 @@ struct frame_vector *vb2_create_framevec(unsigned long
> > > start,
> > > unsigned long first, last;
> > > unsigned long nr;
> > > struct frame_vector *vec;
> > > - unsigned int flags = FOLL_FORCE | FOLL_WRITE;
> > >
> > > first = start >> PAGE_SHIFT;
> > > last = (start + length - 1) >> PAGE_SHIFT;
> > > @@ -48,7 +47,7 @@ struct frame_vector *vb2_create_framevec(unsigned long
> > > start,
> > > vec = frame_vector_create(nr);
> > > if (!vec)
> > > return ERR_PTR(-ENOMEM);
> > > - ret = get_vaddr_frames(start & PAGE_MASK, nr, flags, vec);
> > > + ret = get_vaddr_frames(start & PAGE_MASK, nr, vec);
> > > if (ret < 0)
> > > goto out_destroy;
> > > /* We accept only complete set of PFNs */
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index ef360fe70aaf..d6b8e30dce2e 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -1765,7 +1765,7 @@ struct frame_vector {
> > > struct frame_vector *frame_vector_create(unsigned int nr_frames);
> > > void frame_vector_destroy(struct frame_vector *vec);
> > > int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
> > > -unsigned int gup_flags, struct frame_vector *vec);
> > > +struct frame_vector *vec);
> > > void put_vaddr_frames(struct frame_vector *vec);
> > > int frame_vector_to_pages(struct frame_vector *vec);
> > > void frame_vector_to_pfns(struct frame_vector *vec);
> > > diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> > > index 10f82d5643b6..f8c34b895c76 100644
> > > --- a/mm/frame_vector.c
> > > +++ b/mm/frame_vector.c
> > > @@ -32,13 +32,12 @@
> > > * This function takes care of grabbing mmap_lock as necessary.
> > > */
> > > int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
> > > -unsigned int gup_flags, struct frame_vector *vec)
> > > +struct frame_vector *vec)
> > > {
> > >
[kbuild] Re: [PATCH] drm/irq: Add irq as false detection
Hi Tian,
url:
https://github.com/0day-ci/linux/commits/Tian-Tao/drm-irq-Add-irq-as-false-detection/20201102-192137
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
3cea11cd5e3b00d91caf0b4730194039b45c5891
config: x86_64-randconfig-m001-20201102 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
New smatch warnings:
drivers/gpu/drm/drm_irq.c:175 drm_irq_uninstall() warn: variable dereferenced
before check 'dev' (see line 175)
Old smatch warnings:
drivers/gpu/drm/drm_irq.c:149 drm_irq_install() warn: 'irq' not released on
lines: 133.
vim +/dev +175 drivers/gpu/drm/drm_irq.c
84b1fd103dbbe01 drivers/char/drm/drm_irq.c Dave Airlie2007-07-11 169 int
drm_irq_uninstall(struct drm_device *dev)
^1da177e4c3f415 drivers/char/drm/drm_irq.c Linus Torvalds 2005-04-16 170 {
dc1336ff4fe08ae drivers/gpu/drm/drm_irq.c Jesse Barnes 2009-01-06 171
unsigned long irqflags;
4423843cde65232 drivers/gpu/drm/drm_irq.c Ville Syrjälä 2013-10-04 172
bool irq_enabled;
4423843cde65232 drivers/gpu/drm/drm_irq.c Ville Syrjälä 2013-10-04 173
int i;
^1da177e4c3f415 drivers/char/drm/drm_irq.c Linus Torvalds 2005-04-16 174
fa889e8baa5377b drivers/gpu/drm/drm_irq.c Tian Tao 2020-11-02 @175
if (!dev->irq_enabled || !dev)
^^
This is checking "dev" after dereferencing it. Can "dev" even be NULL?
fa889e8baa5377b drivers/gpu/drm/drm_irq.c Tian Tao 2020-11-02 176
return 0;
fa889e8baa5377b drivers/gpu/drm/drm_irq.c Tian Tao 2020-11-02 177
^1da177e4c3f415 drivers/char/drm/drm_irq.c Linus Torvalds 2005-04-16 178
irq_enabled = dev->irq_enabled;
4423843cde65232 drivers/gpu/drm/drm_irq.c Ville Syrjälä 2013-10-04 179
dev->irq_enabled = false;
^1da177e4c3f415 drivers/char/drm/drm_irq.c Linus Torvalds 2005-04-16 180
dc1336ff4fe08ae drivers/gpu/drm/drm_irq.c Jesse Barnes 2009-01-06 181
/*
3bff93d64cf59f0 drivers/gpu/drm/drm_irq.c Daniel Vetter 2015-02-22 182
* Wake up any waiters so they don't hang. This is just to paper over
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
kbuild mailing list -- kbu...@lists.01.org
To unsubscribe send an email to kbuild-le...@lists.01.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd: fix typoes
Applied. Thanks!
Alex
On Mon, Nov 2, 2020 at 8:43 AM Bernard Zhao wrote:
>
> Fix typoes.
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> index 2c6db379afae..e994d233aa21 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> @@ -1980,7 +1980,7 @@ static void calculate_bandwidth(
> else {
> data->latency_for_non_mcifwr_clients = bw_int_to_fixed(0);
> }
> - /*dmif mc urgent latency suppported in high sclk and yclk*/
> + /*dmif mc urgent latency supported in high sclk and yclk*/
> data->dmifmc_urgent_latency_supported_in_high_sclk_and_yclk =
> bw_div((bw_sub(data->min_read_buffer_size_in_time,
> data->dmif_burst_time[high][s_high])), data->total_dmifmc_urgent_trips);
> /*dram speed/p-state change margin*/
> /*in the multi-display case the nb p-state change watermark cannot
> exceed the average lb size plus the dmif size or the cursor dcp buffer size*/
> --
> 2.29.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: [PATCH][next] drm/amdgpu: fix spelling mistake: "Successed" -> "Succeeded"
Applied. Thanks! Alex On Mon, Nov 2, 2020 at 9:17 AM Colin King wrote: > > From: Colin Ian King > > There is a spelling mistake in a deb_dbg message. Fix it. > > Signed-off-by: Colin Ian King > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c > index 28a5c0d21b71..c99c2180785f 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c > @@ -296,7 +296,7 @@ static void amdgpu_vram_mgr_do_reserve(struct > ttm_resource_manager *man) > if (drm_mm_reserve_node(mm, &rsv->mm_node)) > continue; > > - dev_dbg(adev->dev, "Reservation 0x%llx - %lld, Successed\n", > + dev_dbg(adev->dev, "Reservation 0x%llx - %lld, Succeeded\n", > rsv->mm_node.start, rsv->mm_node.size); > > vis_usage = amdgpu_vram_mgr_vis_size(adev, &rsv->mm_node); > -- > 2.27.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: [PATCH][next] drm/amdgpu: fix spelling mistake: "Successed" -> "Succeeded"
[AMD Public Use] -Original Message- From: amd-gfx On Behalf Of Colin King Sent: Monday, November 2, 2020 7:47 PM To: Deucher, Alexander ; Koenig, Christian ; David Airlie ; Daniel Vetter ; Dave Airlie ; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org Subject: [PATCH][next] drm/amdgpu: fix spelling mistake: "Successed" -> "Succeeded" From: Colin Ian King There is a spelling mistake in a deb_dbg message. Fix it. Spell mistake in "deb_dbg" of commit message. With that fix (to dev_dbg): Reviewed-by: Madhav Chauhan Regards, Madhav Signed-off-by: Colin Ian King --- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c index 28a5c0d21b71..c99c2180785f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c @@ -296,7 +296,7 @@ static void amdgpu_vram_mgr_do_reserve(struct ttm_resource_manager *man) if (drm_mm_reserve_node(mm, &rsv->mm_node)) continue; - dev_dbg(adev->dev, "Reservation 0x%llx - %lld, Successed\n", + dev_dbg(adev->dev, "Reservation 0x%llx - %lld, Succeeded\n", rsv->mm_node.start, rsv->mm_node.size); vis_usage = amdgpu_vram_mgr_vis_size(adev, &rsv->mm_node); -- 2.27.0 ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Cmadhav.chauhan%40amd.com%7C563b9e348bf946c1894c08d87f3a6739%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637399236116555988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BiITYub2Q5HKNJXDwLRkrv%2FSpVmWt59oNVW2CmCgf3M%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amd/pm: remove unused variable
On Mon, Nov 2, 2020 at 8:44 AM Zou Wei wrote:
>
> Fix variable set but not used compilation warning:
>
> ./vangogh_ppt.c:397:6: warning: variable ‘ret’ set but not used
> [-Wunused-but-set-variable]
> int ret = 0;
> ^~~
>
Maybe you have an older version of the code? It's currently used.
Alex
> Reported-by: Hulk Robot
> Signed-off-by: Zou Wei
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> index 6e26025..355ade5 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> @@ -394,8 +394,6 @@ static int vangogh_get_current_activity_percent(struct
> smu_context *smu,
>enum amd_pp_sensors sensor,
>uint32_t *value)
> {
> - int ret = 0;
> -
> if (!value)
> return -EINVAL;
>
> --
> 2.6.2
>
> ___
> 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
[Bug 210005] Kernel stacktrace, Xorg freezes
https://bugzilla.kernel.org/show_bug.cgi?id=210005 --- Comment #1 from amara...@dshort.biz --- Found the same bug report on launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1901563 It seems there is a issue with Xorg and the i915 driver. -- 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 6/6] drm/amdgpu: improve code indentation and alignment
Applied the series. Thanks!
Alex
On Mon, Nov 2, 2020 at 12:44 PM Deepak R Varma wrote:
>
> General code indentation and alignment changes such as replace spaces
> by tabs or align function arguments as per the coding style
> guidelines. The patch covers various .c files for this driver.
> Issue reported by checkpatch script.
>
> Signed-off-by: Deepak R Varma
> ---
> drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/df_v1_7.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c | 8
> drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/si.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/si_ih.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/soc15.c | 2 +-
> 9 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index 4cfc786699c7..696e97ab77eb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -71,8 +71,8 @@ static int amdgpu_atom_execute_table_locked(struct
> atom_context *ctx, int index,
> int amdgpu_atom_execute_table(struct atom_context *ctx, int index, uint32_t
> * params);
>
> static uint32_t atom_arg_mask[8] =
> -{ 0x, 0x, 0x00, 0x, 0xFF, 0xFF00, 0xFF,
> -0xFF00 };
> + { 0x, 0x, 0x00, 0x, 0xFF, 0xFF00, 0xFF,
> + 0xFF00 };
> static int atom_arg_shift[8] = { 0, 0, 8, 16, 0, 8, 16, 24 };
>
> static int atom_dst_to_src[8][4] = {
> diff --git a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
> b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
> index 20f108818b2b..52f05d2f5ed9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
> +++ b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
> @@ -195,7 +195,7 @@ static void cik_sdma_ring_set_wptr(struct amdgpu_ring
> *ring)
> struct amdgpu_device *adev = ring->adev;
>
> WREG32(mmSDMA0_GFX_RB_WPTR + sdma_offsets[ring->me],
> - (lower_32_bits(ring->wptr) << 2) & 0x3fffc);
> + (lower_32_bits(ring->wptr) << 2) & 0x3fffc);
> }
>
> static void cik_sdma_ring_insert_nop(struct amdgpu_ring *ring, uint32_t
> count)
> diff --git a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c
> b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c
> index d6aca1c08068..2d01ac0d4c11 100644
> --- a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c
> +++ b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c
> @@ -41,7 +41,7 @@ static void df_v1_7_sw_fini(struct amdgpu_device *adev)
> }
>
> static void df_v1_7_enable_broadcast_mode(struct amdgpu_device *adev,
> - bool enable)
> + bool enable)
> {
> u32 tmp;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
> index dbc8b76b9b78..6b04729d8fec 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
> @@ -145,7 +145,7 @@ static const struct amdgpu_irq_src_funcs
> gmc_v10_0_ecc_funcs = {
> .process = amdgpu_umc_process_ecc_irq,
> };
>
> - static void gmc_v10_0_set_irq_funcs(struct amdgpu_device *adev)
> +static void gmc_v10_0_set_irq_funcs(struct amdgpu_device *adev)
> {
> adev->gmc.vm_fault.num_types = 1;
> adev->gmc.vm_fault.funcs = &gmc_v10_0_irq_funcs;
> diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c
> b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c
> index 94caf5204c8b..7b1a18cbafc4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c
> @@ -32,19 +32,19 @@
> #include "vcn/vcn_2_0_0_sh_mask.h"
> #include "ivsrcid/vcn/irqsrcs_vcn_2_0.h"
>
> -#define mmUVD_JRBC_EXTERNAL_REG_INTERNAL_OFFSET
> 0x1bfff
> +#define mmUVD_JRBC_EXTERNAL_REG_INTERNAL_OFFSET
> 0x1bfff
> #define mmUVD_JPEG_GPCOM_CMD_INTERNAL_OFFSET 0x4029
> #define mmUVD_JPEG_GPCOM_DATA0_INTERNAL_OFFSET 0x402a
> #define mmUVD_JPEG_GPCOM_DATA1_INTERNAL_OFFSET 0x402b
> #define mmUVD_LMI_JRBC_RB_MEM_WR_64BIT_BAR_LOW_INTERNAL_OFFSET 0x40ea
> -#define mmUVD_LMI_JRBC_RB_MEM_WR_64BIT_BAR_HIGH_INTERNAL_OFFSET0x40eb
> +#define mmUVD_LMI_JRBC_RB_MEM_WR_64BIT_BAR_HIGH_INTERNAL_OFFSET
> 0x40eb
> #define mmUVD_LMI_JRBC_IB_VMID_INTERNAL_OFFSET 0x40cf
> #define mmUVD_LMI_JPEG_VMID_INTERNAL_OFFSET0x40d1
> -#define mmUVD_LMI_JRBC_IB_64BIT_BAR_LOW_INTERNAL_OFFSET0x40e8
> +#define mmUVD_LMI_JRBC_IB_64BIT_BAR_LOW_INTERNAL_OFFSET
> 0x40e8
> #define mmUVD_LMI_JRBC_IB_64BIT_BAR_HIGH_INTERNAL_OFFSET 0x40e9
> #define mmUVD_JRBC_IB_SIZE_INTERNAL_OFFSET 0x4082
> #define mmUVD_LMI_JRBC_RB_MEM_RD_64BIT
Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma wrote:
>
> Initializing global variable to 0 or NULL is not necessary and should
> be avoided. Issue reported by checkpatch script as:
> ERROR: do not initialise globals to 0 (or NULL).
I agree that this is technically correct, but a lot of people don't
seem to know that so we get a lot of comments about this code for the
variables that are not explicitly set. Seems less confusing to
initialize them even if it not necessary. I don't have a particularly
strong opinion on it however.
Alex
>
> Signed-off-by: Deepak R Varma
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 46 -
> drivers/gpu/drm/amd/amdgpu/atom.c | 4 +--
> 2 files changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 8ab6126ff70c..6de94c46bc91 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -94,16 +94,16 @@
> #define KMS_DRIVER_MINOR 40
> #define KMS_DRIVER_PATCHLEVEL 0
>
> -int amdgpu_vram_limit = 0;
> -int amdgpu_vis_vram_limit = 0;
> +int amdgpu_vram_limit;
> +int amdgpu_vis_vram_limit;
> int amdgpu_gart_size = -1; /* auto */
> int amdgpu_gtt_size = -1; /* auto */
> int amdgpu_moverate = -1; /* auto */
> -int amdgpu_benchmarking = 0;
> -int amdgpu_testing = 0;
> +int amdgpu_benchmarking;
> +int amdgpu_testing;
> int amdgpu_audio = -1;
> -int amdgpu_disp_priority = 0;
> -int amdgpu_hw_i2c = 0;
> +int amdgpu_disp_priority;
> +int amdgpu_hw_i2c;
> int amdgpu_pcie_gen2 = -1;
> int amdgpu_msi = -1;
> char amdgpu_lockup_timeout[AMDGPU_MAX_TIMEOUT_PARAM_LENGTH];
> @@ -113,43 +113,43 @@ int amdgpu_aspm = -1;
> int amdgpu_runtime_pm = -1;
> uint amdgpu_ip_block_mask = 0x;
> int amdgpu_bapm = -1;
> -int amdgpu_deep_color = 0;
> +int amdgpu_deep_color;
> int amdgpu_vm_size = -1;
> int amdgpu_vm_fragment_size = -1;
> int amdgpu_vm_block_size = -1;
> -int amdgpu_vm_fault_stop = 0;
> -int amdgpu_vm_debug = 0;
> +int amdgpu_vm_fault_stop;
> +int amdgpu_vm_debug;
> int amdgpu_vm_update_mode = -1;
> -int amdgpu_exp_hw_support = 0;
> +int amdgpu_exp_hw_support;
> int amdgpu_dc = -1;
> int amdgpu_sched_jobs = 32;
> int amdgpu_sched_hw_submission = 2;
> -uint amdgpu_pcie_gen_cap = 0;
> -uint amdgpu_pcie_lane_cap = 0;
> +uint amdgpu_pcie_gen_cap;
> +uint amdgpu_pcie_lane_cap;
> uint amdgpu_cg_mask = 0x;
> uint amdgpu_pg_mask = 0x;
> uint amdgpu_sdma_phase_quantum = 32;
> -char *amdgpu_disable_cu = NULL;
> -char *amdgpu_virtual_display = NULL;
> +char *amdgpu_disable_cu;
> +char *amdgpu_virtual_display;
> /* OverDrive(bit 14) disabled by default*/
> uint amdgpu_pp_feature_mask = 0xbfff;
> -uint amdgpu_force_long_training = 0;
> -int amdgpu_job_hang_limit = 0;
> +uint amdgpu_force_long_training;
> +int amdgpu_job_hang_limit;
> int amdgpu_lbpw = -1;
> int amdgpu_compute_multipipe = -1;
> int amdgpu_gpu_recovery = -1; /* auto */
> -int amdgpu_emu_mode = 0;
> -uint amdgpu_smu_memory_pool_size = 0;
> +int amdgpu_emu_mode;
> +uint amdgpu_smu_memory_pool_size;
> /* FBC (bit 0) disabled by default*/
> -uint amdgpu_dc_feature_mask = 0;
> -uint amdgpu_dc_debug_mask = 0;
> +uint amdgpu_dc_feature_mask;
> +uint amdgpu_dc_debug_mask;
> int amdgpu_async_gfx_ring = 1;
> -int amdgpu_mcbp = 0;
> +int amdgpu_mcbp;
> int amdgpu_discovery = -1;
> -int amdgpu_mes = 0;
> +int amdgpu_mes;
> int amdgpu_noretry = -1;
> int amdgpu_force_asic_type = -1;
> -int amdgpu_tmz = 0;
> +int amdgpu_tmz;
> int amdgpu_reset_method = -1; /* auto */
> int amdgpu_num_kcq = -1;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index 696e97ab77eb..46c00ee580b1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -66,7 +66,7 @@ typedef struct {
> bool abort;
> } atom_exec_context;
>
> -int amdgpu_atom_debug = 0;
> +int amdgpu_atom_debug;
> static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int
> index, uint32_t * params);
> int amdgpu_atom_execute_table(struct atom_context *ctx, int index, uint32_t
> * params);
>
> @@ -88,7 +88,7 @@ static int atom_dst_to_src[8][4] = {
> };
> static int atom_def_dst[8] = { 0, 0, 1, 2, 0, 1, 2, 3 };
>
> -static int debug_depth = 0;
> +static int debug_depth;
> #ifdef ATOM_DEBUG
> static void debug_print_spaces(int n)
> {
> --
> 2.25.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/ttm: replace context flags with bools
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20201102]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.10-rc2]
[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/Christian-K-nig/drm-ttm-rework-no_retry-handling/20201102-205950
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a004-20201102 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
cc91554ebb66e8c9a4b8c67ca2f1343eaac10cf6)
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 x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/1010fe871b783d6385714dbfde4e57ed966b6749
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christian-K-nig/drm-ttm-rework-no_retry-handling/20201102-205950
git checkout 1010fe871b783d6385714dbfde4e57ed966b6749
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:408:4: error: field designator
>> 'flags' does not refer to any field in type 'struct ttm_operation_ctx'
.flags = 0
^
1 error generated.
--
>> drivers/gpu/drm/ttm/ttm_bo_vm.c:318:5: error: field designator
>> 'fource_alloc' does not refer to any field in type 'struct
>> ttm_operation_ctx'; did you mean 'force_alloc'?
.fource_alloc = true
^~~~
force_alloc
include/drm/ttm/ttm_bo_api.h:212:7: note: 'force_alloc' declared here
bool force_alloc;
^
1 error generated.
--
>> drivers/gpu/drm/ttm/ttm_resource.c:92:4: error: field designator
>> 'fource_alloc' does not refer to any field in type 'struct
>> ttm_operation_ctx'; did you mean 'force_alloc'?
.fource_alloc = true
^~~~
force_alloc
include/drm/ttm/ttm_bo_api.h:212:7: note: 'force_alloc' declared here
bool force_alloc;
^
1 error generated.
vim +408 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
d38ceaf99ed015f Alex Deucher 2015-04-20 399
14fd833efa3f136 Chunming Zhou 2016-08-04 400 static int
amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
14fd833efa3f136 Chunming Zhou 2016-08-04 401
struct amdgpu_bo *bo)
d38ceaf99ed015f Alex Deucher 2015-04-20 402 {
a7d64de659946e8 Christian König 2016-09-15 403 struct amdgpu_device
*adev = amdgpu_ttm_adev(bo->tbo.bdev);
9251859a9adb8e5 Roger He 2017-12-08 404 struct
ttm_operation_ctx ctx = {
9251859a9adb8e5 Roger He 2017-12-08 405 .interruptible
= true,
9251859a9adb8e5 Roger He 2017-12-08 406 .no_wait_gpu =
false,
5a5011a72489545 Gerd Hoffmann 2019-08-05 407 .resv =
bo->tbo.base.resv,
d330fca11500beb Roger He 2018-02-06 @408 .flags = 0
9251859a9adb8e5 Roger He 2017-12-08 409 };
36409d122cb84fa Christian König 2015-12-21 410 uint32_t domain;
14fd833efa3f136 Chunming Zhou 2016-08-04 411 int r;
2f568dbd6b944c2 Christian König 2016-02-23 412
4671078eb8e390b Christian König 2020-09-21 413 if (bo->tbo.pin_count)
14fd833efa3f136 Chunming Zhou 2016-08-04 414 return 0;
36409d122cb84fa Christian König 2015-12-21 415
95844d20ae024b5 Marek Olšák 2016-08-17 416 /* Don't move this
buffer if we have depleted our allowance
95844d20ae024b5 Marek Olšák 2016-08-17 417* to move it. Don't
move anything if the threshold is zero.
d38ceaf99ed015f Alex Deucher 2015-04-20 418*/
4993ba02635f69e Christian König 2019-05-06 419 if (p->bytes_moved <
p->bytes_moved_threshold &&
4993ba02635f69e Christian König 2019-05-06 420
(!bo->tbo.base.dma_buf ||
4993ba02635f69e Christian König 2019-05-06 421
list_empty(&bo->tbo.base.dma
Re: [PATCH 6/6] drm/amdgpu: use "*" adjacent to data name
Applied the series. Thanks!
Alex
On Mon, Nov 2, 2020 at 2:41 PM Deepak R Varma wrote:
>
> When declaring pointer data, the "*" symbol should be used adjacent to
> the data name as per the coding standards. This resolves following
> issues reported by checkpatch script:
> ERROR: "foo * bar" should be "foo *bar"
> ERROR: "foo * bar" should be "foo *bar"
> ERROR: "foo*bar" should be "foo *bar"
> ERROR: "(foo*)" should be "(foo *)"
>
> Signed-off-by: Deepak R Varma
> ---
> drivers/gpu/drm/amd/amdgpu/atom.c | 16
> drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/mes_v10_1.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c| 2 +-
> 5 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index 46c00ee580b1..515890f4f5a0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -67,8 +67,8 @@ typedef struct {
> } atom_exec_context;
>
> int amdgpu_atom_debug;
> -static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int
> index, uint32_t * params);
> -int amdgpu_atom_execute_table(struct atom_context *ctx, int index, uint32_t
> * params);
> +static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int
> index, uint32_t *params);
> +int amdgpu_atom_execute_table(struct atom_context *ctx, int index, uint32_t
> *params);
>
> static uint32_t atom_arg_mask[8] =
> { 0x, 0x, 0x00, 0x, 0xFF, 0xFF00, 0xFF,
> @@ -1201,7 +1201,7 @@ static struct {
> atom_op_div32, ATOM_ARG_WS},
> };
>
> -static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int
> index, uint32_t * params)
> +static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int
> index, uint32_t *params)
> {
> int base = CU16(ctx->cmd_table + 4 + 2 * index);
> int len, ws, ps, ptr;
> @@ -1262,7 +1262,7 @@ static int amdgpu_atom_execute_table_locked(struct
> atom_context *ctx, int index,
> return ret;
> }
>
> -int amdgpu_atom_execute_table(struct atom_context *ctx, int index, uint32_t
> * params)
> +int amdgpu_atom_execute_table(struct atom_context *ctx, int index, uint32_t
> *params)
> {
> int r;
>
> @@ -1388,8 +1388,8 @@ void amdgpu_atom_destroy(struct atom_context *ctx)
> }
>
> bool amdgpu_atom_parse_data_header(struct atom_context *ctx, int index,
> - uint16_t * size, uint8_t * frev, uint8_t * crev,
> - uint16_t * data_start)
> + uint16_t *size, uint8_t *frev, uint8_t *crev,
> + uint16_t *data_start)
> {
> int offset = index * 2 + 4;
> int idx = CU16(ctx->data_table + offset);
> @@ -1408,8 +1408,8 @@ bool amdgpu_atom_parse_data_header(struct atom_context
> *ctx, int index,
> return true;
> }
>
> -bool amdgpu_atom_parse_cmd_header(struct atom_context *ctx, int index,
> uint8_t * frev,
> - uint8_t * crev)
> +bool amdgpu_atom_parse_cmd_header(struct atom_context *ctx, int index,
> uint8_t *frev,
> + uint8_t *crev)
> {
> int offset = index * 2 + 4;
> int idx = CU16(ctx->cmd_table + offset);
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
> b/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
> index 09a538465ffd..af0335535f82 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_i2c.c
> @@ -159,7 +159,7 @@ u32 amdgpu_atombios_i2c_func(struct i2c_adapter *adap)
> return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
> }
>
> -void amdgpu_atombios_i2c_channel_trans(struct amdgpu_device* adev, u8
> slave_addr, u8 line_number, u8 offset, u8 data)
> +void amdgpu_atombios_i2c_channel_trans(struct amdgpu_device *adev, u8
> slave_addr, u8 line_number, u8 offset, u8 data)
> {
> PROCESS_I2C_CHANNEL_TRANSACTION_PS_ALLOCATION args;
> int index = GetIndexIntoMasterTable(COMMAND,
> ProcessI2cChannelTransaction);
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 48f98c750956..e96ab5325af5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -5167,7 +5167,7 @@ static void gfx_v9_0_ring_set_wptr_gfx(struct
> amdgpu_ring *ring)
>
> if (ring->use_doorbell) {
> /* XXX check if swapping is necessary on BE */
> - atomic64_set((atomic64_t*)&adev->wb.wb[ring->wptr_offs],
> ring->wptr);
> + atomic64_set((atomic64_t *)&adev->wb.wb[ring->wptr_offs],
> ring->wptr);
> WDOORBELL64(ring->doorbell_index, ring->wptr);
> } else {
> WREG32_SOC15(GC, 0, mmCP_RB0_WPTR, lower_32_bits(ring->wptr));
> @@ -5353,7
Re: [PATCH] drm/nouveu: fix swiotlb include
Am 02.11.20 um 11:32 schrieb Daniel Vetter: On Fri, Oct 30, 2020 at 12:13 PM Christian König wrote: The check for swiotlb has moved to nouveu_ttm.c, but we forgot to move the include as well. Signed-off-by: Christian König So this now broke drm-misc-next compilation on arm, which isn't great. Please make sure you compile test stuff before pushing. Well, I did compile tested it on x86_64 before pushing and all looked well. Since the proper fix is maybe stuck in the usual "drm abuses swiotlb internals" bikeshed, maybe best if we push a fix to including limits.h in nouveau and call it done? Also adding Maxime, who's trying to get the backmerge through right now. Yeah, that is probably the best approach. I didn't realized that the include of limit.h needs to move as well. Regards, Christian. -Daniel --- drivers/gpu/drm/nouveau/nouveau_bo.c | 1 - drivers/gpu/drm/nouveau/nouveau_ttm.c | 3 +++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 746c06ed195b..8133377d865d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -28,7 +28,6 @@ */ #include -#include #include "nouveau_drv.h" #include "nouveau_chan.h" diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index d696d882c9eb..2bf36229dd57 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c @@ -22,6 +22,9 @@ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE * USE OR OTHER DEALINGS IN THE SOFTWARE. */ + +#include + #include "nouveau_drv.h" #include "nouveau_gem.h" #include "nouveau_mem.h" -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd: fix typoes
Am 02.11.20 um 13:57 schrieb Bernard Zhao:
Fix typoes.
Signed-off-by: Bernard Zhao
Acked-by: Christian König
---
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
index 2c6db379afae..e994d233aa21 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
+++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
@@ -1980,7 +1980,7 @@ static void calculate_bandwidth(
else {
data->latency_for_non_mcifwr_clients = bw_int_to_fixed(0);
}
- /*dmif mc urgent latency suppported in high sclk and yclk*/
+ /*dmif mc urgent latency supported in high sclk and yclk*/
data->dmifmc_urgent_latency_supported_in_high_sclk_and_yclk =
bw_div((bw_sub(data->min_read_buffer_size_in_time,
data->dmif_burst_time[high][s_high])), data->total_dmifmc_urgent_trips);
/*dram speed/p-state change margin*/
/*in the multi-display case the nb p-state change watermark cannot
exceed the average lb size plus the dmif size or the cursor dcp buffer size*/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
Am 02.11.20 um 20:43 schrieb Alex Deucher:
On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma wrote:
Initializing global variable to 0 or NULL is not necessary and should
be avoided. Issue reported by checkpatch script as:
ERROR: do not initialise globals to 0 (or NULL).
I agree that this is technically correct, but a lot of people don't
seem to know that so we get a lot of comments about this code for the
variables that are not explicitly set. Seems less confusing to
initialize them even if it not necessary. I don't have a particularly
strong opinion on it however.
Agree with Alex.
Especially for the module parameters we should have a explicit init
value for documentation purposes, even when it is 0.
Christian.
Alex
Signed-off-by: Deepak R Varma
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 46 -
drivers/gpu/drm/amd/amdgpu/atom.c | 4 +--
2 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8ab6126ff70c..6de94c46bc91 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -94,16 +94,16 @@
#define KMS_DRIVER_MINOR 40
#define KMS_DRIVER_PATCHLEVEL 0
-int amdgpu_vram_limit = 0;
-int amdgpu_vis_vram_limit = 0;
+int amdgpu_vram_limit;
+int amdgpu_vis_vram_limit;
int amdgpu_gart_size = -1; /* auto */
int amdgpu_gtt_size = -1; /* auto */
int amdgpu_moverate = -1; /* auto */
-int amdgpu_benchmarking = 0;
-int amdgpu_testing = 0;
+int amdgpu_benchmarking;
+int amdgpu_testing;
int amdgpu_audio = -1;
-int amdgpu_disp_priority = 0;
-int amdgpu_hw_i2c = 0;
+int amdgpu_disp_priority;
+int amdgpu_hw_i2c;
int amdgpu_pcie_gen2 = -1;
int amdgpu_msi = -1;
char amdgpu_lockup_timeout[AMDGPU_MAX_TIMEOUT_PARAM_LENGTH];
@@ -113,43 +113,43 @@ int amdgpu_aspm = -1;
int amdgpu_runtime_pm = -1;
uint amdgpu_ip_block_mask = 0x;
int amdgpu_bapm = -1;
-int amdgpu_deep_color = 0;
+int amdgpu_deep_color;
int amdgpu_vm_size = -1;
int amdgpu_vm_fragment_size = -1;
int amdgpu_vm_block_size = -1;
-int amdgpu_vm_fault_stop = 0;
-int amdgpu_vm_debug = 0;
+int amdgpu_vm_fault_stop;
+int amdgpu_vm_debug;
int amdgpu_vm_update_mode = -1;
-int amdgpu_exp_hw_support = 0;
+int amdgpu_exp_hw_support;
int amdgpu_dc = -1;
int amdgpu_sched_jobs = 32;
int amdgpu_sched_hw_submission = 2;
-uint amdgpu_pcie_gen_cap = 0;
-uint amdgpu_pcie_lane_cap = 0;
+uint amdgpu_pcie_gen_cap;
+uint amdgpu_pcie_lane_cap;
uint amdgpu_cg_mask = 0x;
uint amdgpu_pg_mask = 0x;
uint amdgpu_sdma_phase_quantum = 32;
-char *amdgpu_disable_cu = NULL;
-char *amdgpu_virtual_display = NULL;
+char *amdgpu_disable_cu;
+char *amdgpu_virtual_display;
/* OverDrive(bit 14) disabled by default*/
uint amdgpu_pp_feature_mask = 0xbfff;
-uint amdgpu_force_long_training = 0;
-int amdgpu_job_hang_limit = 0;
+uint amdgpu_force_long_training;
+int amdgpu_job_hang_limit;
int amdgpu_lbpw = -1;
int amdgpu_compute_multipipe = -1;
int amdgpu_gpu_recovery = -1; /* auto */
-int amdgpu_emu_mode = 0;
-uint amdgpu_smu_memory_pool_size = 0;
+int amdgpu_emu_mode;
+uint amdgpu_smu_memory_pool_size;
/* FBC (bit 0) disabled by default*/
-uint amdgpu_dc_feature_mask = 0;
-uint amdgpu_dc_debug_mask = 0;
+uint amdgpu_dc_feature_mask;
+uint amdgpu_dc_debug_mask;
int amdgpu_async_gfx_ring = 1;
-int amdgpu_mcbp = 0;
+int amdgpu_mcbp;
int amdgpu_discovery = -1;
-int amdgpu_mes = 0;
+int amdgpu_mes;
int amdgpu_noretry = -1;
int amdgpu_force_asic_type = -1;
-int amdgpu_tmz = 0;
+int amdgpu_tmz;
int amdgpu_reset_method = -1; /* auto */
int amdgpu_num_kcq = -1;
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index 696e97ab77eb..46c00ee580b1 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -66,7 +66,7 @@ typedef struct {
bool abort;
} atom_exec_context;
-int amdgpu_atom_debug = 0;
+int amdgpu_atom_debug;
static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int
index, uint32_t * params);
int amdgpu_atom_execute_table(struct atom_context *ctx, int index, uint32_t *
params);
@@ -88,7 +88,7 @@ static int atom_dst_to_src[8][4] = {
};
static int atom_def_dst[8] = { 0, 0, 1, 2, 0, 1, 2, 3 };
-static int debug_depth = 0;
+static int debug_depth;
#ifdef ATOM_DEBUG
static void debug_print_spaces(int n)
{
--
2.25.1
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
On Mon, Nov 02, 2020 at 02:43:45PM -0500, Alex Deucher wrote: > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma wrote: > > > > Initializing global variable to 0 or NULL is not necessary and should > > be avoided. Issue reported by checkpatch script as: > > ERROR: do not initialise globals to 0 (or NULL). > > I agree that this is technically correct, but a lot of people don't > seem to know that so we get a lot of comments about this code for the > variables that are not explicitly set. Seems less confusing to > initialize them even if it not necessary. I don't have a particularly > strong opinion on it however. The kernel coding style is to do it this way. You even save space and time by doing it as well :) thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] dt-bindings: usb-connector: Add reference to graph schema
Now that we have a graph schema, reference it from the usb-connector schema. Signed-off-by: Rob Herring --- v3: new patch .../devicetree/bindings/connector/usb-connector.yaml | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 728f82db073d..64f2e1246ddb 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -125,11 +125,13 @@ properties: power dual role. ports: -description: OF graph bindings (specified in bindings/graph.txt) that model - any data bus to the connector unless the bus is between parent node and - the connector. Since a single connector can have multiple data buses every - bus has an assigned OF graph port number as described below. +$ref: /schemas/graph.yaml#/properties/ports type: object +description: OF graph bindings modeling any data bus to the connector + unless the bus is between parent node and the connector. Since a single + connector can have multiple data buses every bus has an assigned OF graph + port number as described below. + properties: port@0: type: object -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
From: Sameer Pujar
Convert device tree bindings of graph to YAML format. Currently graph.txt
doc is referenced in multiple files and all of these need to use schema
references. For now graph.txt is updated to refer to graph.yaml.
For users of the graph binding, they should reference to the graph
schema from either 'ports' or 'port' property:
properties:
ports:
type: object
$ref: graph.yaml#/properties/ports
properties:
port@0:
description: What data this port has
...
Or:
properties:
port:
description: What data this port has
type: object
$ref: graph.yaml#/properties/port
Signed-off-by: Sameer Pujar
Acked-by: Philipp Zabel
Signed-off-by: Rob Herring
---
v3:
- Move port 'reg' to port@* and make required
- Make remote-endpoint required
- Add 'additionalProperties: true' now required
- Fix yamllint warnings
Documentation/devicetree/bindings/graph.txt | 129 +---
Documentation/devicetree/bindings/graph.yaml | 199 +++
2 files changed, 200 insertions(+), 128 deletions(-)
create mode 100644 Documentation/devicetree/bindings/graph.yaml
diff --git a/Documentation/devicetree/bindings/graph.txt
b/Documentation/devicetree/bindings/graph.txt
index 0415e2c53ba0..b7818d61cef7 100644
--- a/Documentation/devicetree/bindings/graph.txt
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -1,128 +1 @@
-Common bindings for device graphs
-
-General concept
-
-The hierarchical organisation of the device tree is well suited to describe
-control flow to devices, but there can be more complex connections between
-devices that work together to form a logical compound device, following an
-arbitrarily complex graph.
-There already is a simple directed graph between devices tree nodes using
-phandle properties pointing to other nodes to describe connections that
-can not be inferred from device tree parent-child relationships. The device
-tree graph bindings described herein abstract more complex devices that can
-have multiple specifiable ports, each of which can be linked to one or more
-ports of other devices.
-
-These common bindings do not contain any information about the direction or
-type of the connections, they just map their existence. Specific properties
-may be described by specialized bindings depending on the type of connection.
-
-To see how this binding applies to video pipelines, for example, see
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-Here the ports describe data interfaces, and the links between them are
-the connecting data buses. A single port with multiple connections can
-correspond to multiple devices being connected to the same physical bus.
-
-Organisation of ports and endpoints
-
-Ports are described by child 'port' nodes contained in the device node.
-Each port node contains an 'endpoint' subnode for each remote device port
-connected to this port. If a single port is connected to more than one
-remote device, an 'endpoint' child node must be provided for each link.
-If more than one port is present in a device node or there is more than one
-endpoint at a port, or a port node needs to be associated with a selected
-hardware interface, a common scheme using '#address-cells', '#size-cells'
-and 'reg' properties is used to number the nodes.
-
-device {
-...
-#address-cells = <1>;
-#size-cells = <0>;
-
-port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>;
-
-endpoint@0 {
- reg = <0>;
- ...
- };
-endpoint@1 {
- reg = <1>;
- ...
- };
-};
-
-port@1 {
- reg = <1>;
-
- endpoint { ... };
- };
-};
-
-All 'port' nodes can be grouped under an optional 'ports' node, which
-allows to specify #address-cells, #size-cells properties for the 'port'
-nodes independently from any other child device nodes a device might
-have.
-
-device {
-...
-ports {
-#address-cells = <1>;
-#size-cells = <0>;
-
-port@0 {
-...
-endpoint@0 { ... };
-endpoint@1 { ... };
-};
-
-port@1 { ... };
-};
-};
-
-Links between endpoints
-
-Each endpoint should contain a 'remote-endpoint' phandle property that points
-to the corresponding endpoint in the port of the remote device. In turn, the
-remote endpoint should contain a 'remote-endpoint' property. If it has one, it
-must not point to anything other than the local endpoint. Two endpoints with
-their 'remote-endpoint' phandles pointing at each other form a link between the
-containing ports.
-
-device-1 {
-port {
-device_1_output:
[PATCH v3 3/3] dt-bindings: panel: common: Add reference to graph schema
Now that we have a graph schema, reference it from the common panel schema. Cc: Thierry Reding Cc: Sam Ravnborg Cc: Laurent Pinchart Signed-off-by: Rob Herring --- v3: new patch .../devicetree/bindings/display/panel/panel-common.yaml| 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml index cd6dc5461721..a3a72c574213 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml @@ -68,16 +68,15 @@ properties: # Connectivity port: -type: object +$ref: /schemas/graph.yaml#/properties/port ports: -type: object +$ref: /schemas/graph.yaml#/properties/ports description: Panels receive video data through one or multiple connections. While the nature of those connections is specific to the panel type, the connectivity is expressed in a standard fashion using ports as specified - in the device graph bindings defined in - Documentation/devicetree/bindings/graph.txt. + in the device graph bindings. ddc-i2c-bus: $ref: /schemas/types.yaml#/definitions/phandle -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/3] dt-bindings: Convert graph bindings to json-schema
Sameer, I wanted to experiment with what the interface for graph users looks like, so I've tweaked your patch a bit and converted 2 users. This series converts the DT graph binding to a schema. Users of the graph binding should reference the schema from 'ports' or 'port' node. Users will still need to define what each port node is and any additional properties that appear in port or endpoint nodes. I'm still considering whether to apply graph.yaml to the dtschema repo instead. Then I can sync adding it with a meta-schema update to check for a reference. Rob Rob Herring (2): dt-bindings: usb-connector: Add reference to graph schema dt-bindings: panel: common: Add reference to graph schema Sameer Pujar (1): dt-bindings: Convert graph bindings to json-schema .../bindings/connector/usb-connector.yaml | 10 +- .../bindings/display/panel/panel-common.yaml | 7 +- Documentation/devicetree/bindings/graph.txt | 129 +--- Documentation/devicetree/bindings/graph.yaml | 199 ++ 4 files changed, 209 insertions(+), 136 deletions(-) create mode 100644 Documentation/devicetree/bindings/graph.yaml -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: drv: Remove unused variable
On Mon, Nov 02, 2020 at 05:29:08PM +0100, Maxime Ripard wrote:
> The commit dcda7c28bff2 ("drm/vc4: kms: Add functions to create the state
> objects") removed the last users of the vc4 variable, but didn't remove
> that variable resulting in a warning.
>
> Fixes: dcda7c28bff2 ("drm/vc4: kms: Add functions to create the state
> objects")
> Reported-by: Daniel Vetter
> Signed-off-by: Maxime Ripard
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vc4/vc4_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 08c1cc225045..2cd97a39c286 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -307,7 +307,6 @@ static int vc4_drm_bind(struct device *dev)
> static void vc4_drm_unbind(struct device *dev)
> {
> struct drm_device *drm = dev_get_drvdata(dev);
> - struct vc4_dev *vc4 = to_vc4_dev(drm);
>
> drm_dev_unregister(drm);
>
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [bug report] dma-buf: Clarify that dma-buf sg lists are page aligned
Hi Dan,
Thanks for reporting the bug. I see what was missing. Am I supposed to submit a
patch to
replace the original patch or just to fix this bug?
Jianxin
> -Original Message-
> From: Dan Carpenter
> Sent: Monday, November 02, 2020 12:15 AM
> To: Xiong, Jianxin
> Cc: dri-devel@lists.freedesktop.org
> Subject: [bug report] dma-buf: Clarify that dma-buf sg lists are page aligned
>
> Hello Jianxin Xiong,
>
> The patch ac80cd17a615: "dma-buf: Clarify that dma-buf sg lists are page
> aligned" from Oct 14, 2020, leads to the following static checker
> warning:
>
> drivers/dma-buf/dma-buf.c:917 dma_buf_map_attachment()
> error: 'sg_table' dereferencing possible ERR_PTR()
>
> drivers/dma-buf/dma-buf.c
>897 sg_table = attach->dmabuf->ops->map_dma_buf(attach,
> direction);
>898 if (!sg_table)
>899 sg_table = ERR_PTR(-ENOMEM);
>900
>901 if (IS_ERR(sg_table) && dma_buf_is_dynamic(attach->dmabuf) &&
>902 !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
>903 dma_buf_unpin(attach);
>904
>905 if (!IS_ERR(sg_table) &&
> attach->dmabuf->ops->cache_sgt_mapping) {
> ^
>
>906 attach->sgt = sg_table;
>907 attach->dir = direction;
>908 }
>909
>910 #ifdef CONFIG_DMA_API_DEBUG
>911 {
>912 struct scatterlist *sg;
>913 u64 addr;
>914 int len;
>915 int i;
>916
>917 for_each_sgtable_dma_sg(sg_table, sg, i) {
> ^ Not checked here.
>
>918 addr = sg_dma_address(sg);
>919 len = sg_dma_len(sg);
>920 if (!PAGE_ALIGNED(addr) ||
> !PAGE_ALIGNED(len)) {
>921 pr_debug("%s: addr %llx or len %x is
> not page aligned!\n",
>922 __func__, addr, len);
>923 }
>924 }
>925 }
>926 #endif /* CONFIG_DMA_API_DEBUG */
>
> regards,
> dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/bridge: ti-sn65dsi86: Read EDID blob over DDC
Hi Stephen,
On Mon, Nov 02, 2020 at 09:38:12AM -0800, Stephen Boyd wrote:
> Quoting Doug Anderson (2020-11-02 08:06:14)
> > On Sun, Nov 1, 2020 at 11:21 AM Laurent Pinchart wrote:
> > > On Thu, Oct 29, 2020 at 06:17:37PM -0700, Stephen Boyd wrote:
> > > > @@ -265,6 +267,23 @@ connector_to_ti_sn_bridge(struct drm_connector
> > > > *connector)
> > > > static int ti_sn_bridge_connector_get_modes(struct drm_connector
> > > > *connector)
> > > > {
> > > > struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
> > > > + struct edid *edid = pdata->edid;
> > > > + int num, ret;
> > > > +
> > > > + if (!edid) {
> > > > + pm_runtime_get_sync(pdata->dev);
> > > > + edid = pdata->edid = drm_get_edid(connector,
> > > > &pdata->aux.ddc);
> > > > + pm_runtime_put(pdata->dev);
> > > > + }
> > >
> > > Do we need to cache the EDID ? It seems like something that should be
> > > done by the DRM core (well, caching modes in that case), not by
> > > individual bridge drivers.
> >
> > I can take the blame for the fact that it does caching, since I
> > requested it in early reviews. In general boot speed is pretty
> > important to me and each read of the EDID take 20 ms. There are
> > definitely several calls to get the EDID during a normal bootup.
> > Stephen did a little more digging into exactly what was causing all
> > these calls and can chime in,
>
> In ChromeOS we get modes a couple times and then whenever we connect or
> disconnect a DP cable for external display we also get modes. It seems
> that we also run modetest at boot but I'm not sure why we do that. I
> think it is to gather diagnostic data for all the EDIDs on the device at
> boot so we know what all is connected.
>
> > but in general until we can eliminate
> > the extra calls it seems like it'd be nice to keep the caching? This
> > bridge chip is intended for use for eDP for internal panels, so there
> > should be no downside to caching. If we can later optimize the DRM
> > core, we can fix this and a pre-existing driver that does the same
> > type of caching (analogix-anx6345.c) at the same time?
>
> I'd like to add the caching somewhere in the core (maybe the bridge
> connector code?) but I don't know what the logic should be. Is it eDP
> and if not hpd notify then cache all the time and if it is eDP and hpd
> notify then cache once hpd notify says detected and drop cache when no
> longer detected?
>
> if (eDP) {
> if (!hpd)
> cache();
> else if (hpd_detected()) {
> cache();
> else if (!hpd_detected()) {
> drop_cache();
> }
> }
>
> I thought that EDID could change and HPD can be pulsed to notify that it
> should be read again.
I think we should expose a flag tells the panel is fixed instead of
making it a special case of eDP, as other panel types could benefit from
the same mechanism. Otherwise, yes, I think it's really about caching
the EDID the first time we read it, and then reusing it. The question is
who should convert EDID to modes. At the moment bridge drivers do so,
and we're migrating to drm_bridge_connector for most cases. That would
be a candidate location to cache EDID. The DRM core would be another
one, but in that case we may need to also cache the modes.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] dma-buf: Clarify that dma-buf sg lists are page aligned
On Mon, Nov 2, 2020 at 10:33 PM Xiong, Jianxin wrote:
>
> Hi Dan,
>
> Thanks for reporting the bug. I see what was missing. Am I supposed to submit
> a patch to
> replace the original patch or just to fix this bug?
drm-misc-next doesn't rebase (except in emergencies), so please follow
up with a fixup patch that references the one already merged with
Fixes: line and everything else.
Thanks, Daniel
>
> Jianxin
>
> > -Original Message-
> > From: Dan Carpenter
> > Sent: Monday, November 02, 2020 12:15 AM
> > To: Xiong, Jianxin
> > Cc: dri-devel@lists.freedesktop.org
> > Subject: [bug report] dma-buf: Clarify that dma-buf sg lists are page
> > aligned
> >
> > Hello Jianxin Xiong,
> >
> > The patch ac80cd17a615: "dma-buf: Clarify that dma-buf sg lists are page
> > aligned" from Oct 14, 2020, leads to the following static checker
> > warning:
> >
> > drivers/dma-buf/dma-buf.c:917 dma_buf_map_attachment()
> > error: 'sg_table' dereferencing possible ERR_PTR()
> >
> > drivers/dma-buf/dma-buf.c
> >897 sg_table = attach->dmabuf->ops->map_dma_buf(attach,
> > direction);
> >898 if (!sg_table)
> >899 sg_table = ERR_PTR(-ENOMEM);
> >900
> >901 if (IS_ERR(sg_table) && dma_buf_is_dynamic(attach->dmabuf)
> > &&
> >902 !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
> >903 dma_buf_unpin(attach);
> >904
> >905 if (!IS_ERR(sg_table) &&
> > attach->dmabuf->ops->cache_sgt_mapping) {
> > ^
> >
> >906 attach->sgt = sg_table;
> >907 attach->dir = direction;
> >908 }
> >909
> >910 #ifdef CONFIG_DMA_API_DEBUG
> >911 {
> >912 struct scatterlist *sg;
> >913 u64 addr;
> >914 int len;
> >915 int i;
> >916
> >917 for_each_sgtable_dma_sg(sg_table, sg, i) {
> > ^ Not checked here.
> >
> >918 addr = sg_dma_address(sg);
> >919 len = sg_dma_len(sg);
> >920 if (!PAGE_ALIGNED(addr) ||
> > !PAGE_ALIGNED(len)) {
> >921 pr_debug("%s: addr %llx or len %x
> > is not page aligned!\n",
> >922 __func__, addr, len);
> >923 }
> >924 }
> >925 }
> >926 #endif /* CONFIG_DMA_API_DEBUG */
> >
> > regards,
> > dan carpenter
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/bridge: tpd12s015: Fix irq registering in tpd12s015_probe
Hi Yue,
Thank you for the patch.
On Mon, Nov 02, 2020 at 10:30:24PM +0800, YueHaibing wrote:
> gpiod_to_irq() return negative value in case of error,
> the existing code doesn't handle negative error codes.
> If the HPD gpio supports IRQs (gpiod_to_irq returns a
> valid number), we use the IRQ. If it doesn't (gpiod_to_irq
> returns an error), it gets polled via detect().
>
> Fixes: cff5e6f7e83f ("drm/bridge: Add driver for the TI TPD12S015 HDMI level
> shifter")
> Signed-off-by: YueHaibing
Reviewed-by: Laurent Pinchart
> ---
> v2: Add checking for >= 0 and update commit message
> ---
> drivers/gpu/drm/bridge/ti-tpd12s015.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tpd12s015.c
> b/drivers/gpu/drm/bridge/ti-tpd12s015.c
> index 514cbf0eac75..e0e015243a60 100644
> --- a/drivers/gpu/drm/bridge/ti-tpd12s015.c
> +++ b/drivers/gpu/drm/bridge/ti-tpd12s015.c
> @@ -160,7 +160,7 @@ static int tpd12s015_probe(struct platform_device *pdev)
>
> /* Register the IRQ if the HPD GPIO is IRQ-capable. */
> tpd->hpd_irq = gpiod_to_irq(tpd->hpd_gpio);
> - if (tpd->hpd_irq) {
> + if (tpd->hpd_irq >= 0) {
> ret = devm_request_threaded_irq(&pdev->dev, tpd->hpd_irq, NULL,
> tpd12s015_hpd_isr,
> IRQF_TRIGGER_RISING |
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH] drm/msm/dp: do not notify audio subsystem if sink doesn't support audio
Hi Stephen
Thanks for the review.
On 2020-11-02 13:19, Stephen Boyd wrote:
Quoting Abhinav Kumar (2020-10-29 13:55:09)
For sinks that do not support audio, there is no need to notify
audio subsystem of the connection event.
This will make sure that audio routes only to the primary display
when connected to such sinks.
Does this need a Fixes tag? Or it's just an optimization patch?
This is an unhandled corner case ( VGA dongle ) for DP audio and will
make
sure we do not switch audio output from primary to external when
connected to
a sink which does not support audio.
I thought of adding a fixes tag pointing to
https://patchwork.freedesktop.org/patch/390236/.
But at the same time, thought this can go in as a standlone patch as
well.
If you think its required, I will add the fixes tag pointing to the base
audio patch.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_display.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 4a5735564be2..d970980b0ca5 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -555,8 +555,16 @@ static int dp_connect_pending_timeout(struct
dp_display_private *dp, u32 data)
static void dp_display_handle_plugged_change(struct msm_dp
*dp_display,
bool plugged)
{
- if (dp_display->plugged_cb && dp_display->codec_dev)
- dp_display->plugged_cb(dp_display->codec_dev,
plugged);
+ struct dp_display_private *dp;
+
+ dp = container_of(g_dp_display,
What is g_dp_display? I guess this doesn't compile?
g_dp_display is the global dp_display pointer in the dp_display.c file.
It does compile.
+ struct dp_display_private, dp_display);
+
+ if (dp_display->plugged_cb && dp_display->codec_dev) {
+ /* notify audio subsystem only if sink supports audio
*/
+ if (dp->audio_supported)
Can we combine this into the above if statement?
+ dp_display->plugged_cb(dp_display->codec_dev,
plugged);
Then this isn't as nested.
Ok, will do ...
+ }
}
static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32
data)
___
Freedreno mailing list
freedr...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH] drm/msm/dp: do not notify audio subsystem if sink doesn't support audio
Hi Stephen
On 2020-11-02 15:06, Stephen Boyd wrote:
Quoting abhin...@codeaurora.org (2020-11-02 14:43:33)
Hi Stephen
Thanks for the review.
On 2020-11-02 13:19, Stephen Boyd wrote:
> Quoting Abhinav Kumar (2020-10-29 13:55:09)
>> For sinks that do not support audio, there is no need to notify
>> audio subsystem of the connection event.
>>
>> This will make sure that audio routes only to the primary display
>> when connected to such sinks.
>>
>
> Does this need a Fixes tag? Or it's just an optimization patch?
This is an unhandled corner case ( VGA dongle ) for DP audio and will
make
sure we do not switch audio output from primary to external when
connected to
a sink which does not support audio.
I thought of adding a fixes tag pointing to
https://patchwork.freedesktop.org/patch/390236/.
But at the same time, thought this can go in as a standlone patch as
well.
If you think its required, I will add the fixes tag pointing to the
base
audio patch.
Yeah Fixes is nice so we know what is fixed.
Ok sure, will include it.
>
>> Signed-off-by: Abhinav Kumar
>> ---
>> drivers/gpu/drm/msm/dp/dp_display.c | 12 ++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
>> b/drivers/gpu/drm/msm/dp/dp_display.c
>> index 4a5735564be2..d970980b0ca5 100644
>> --- a/drivers/gpu/drm/msm/dp/dp_display.c
>> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
>> @@ -555,8 +555,16 @@ static int dp_connect_pending_timeout(struct
>> dp_display_private *dp, u32 data)
>> static void dp_display_handle_plugged_change(struct msm_dp
>> *dp_display,
>> bool plugged)
>> {
>> - if (dp_display->plugged_cb && dp_display->codec_dev)
>> - dp_display->plugged_cb(dp_display->codec_dev,
>> plugged);
>> + struct dp_display_private *dp;
>> +
>> + dp = container_of(g_dp_display,
>
> What is g_dp_display? I guess this doesn't compile?
g_dp_display is the global dp_display pointer in the dp_display.c
file.
It does compile.
Oh gross. Can we not use it if dp_display points to it?
Ok sure, will get it from dp_display
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dp: promote irq_hpd handle to handle link trainign correctly
On Mon, Nov 2, 2020 at 11:29 AM Stephen Boyd wrote:
>
> Subject has a typo in "training".
>
> Quoting Kuogee Hsieh (2020-10-30 16:23:24)
> > Some dongles, such as Apple, required link training done at irq_hpd
>
> s/required/require/
>
> > request instead of plugin request. This patch promote irq_hpd hanlder
>
> s/hanlder/handler/
>
> > to handle link training and setup hpd_state correctly.
> >
> > Signed-off-by: Kuogee Hsieh
> > ---
>
> Any Fixes tag?
>
> > drivers/gpu/drm/msm/dp/dp_display.c | 20 ++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> > b/drivers/gpu/drm/msm/dp/dp_display.c
> > index 13b66266cd69..55627530957c 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_display.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> > @@ -483,10 +485,24 @@ static int dp_display_usbpd_attention_cb(struct
> > device *dev)
> > return -ENODEV;
> > }
> >
> > + hpd = dp->usbpd;
> > +
> > /* check for any test request issued by sink */
> > rc = dp_link_process_request(dp->link);
> > - if (!rc)
> > - dp_display_handle_irq_hpd(dp);
> > + if (!rc) {
> > + sink_request = dp->link->sink_request;
> > + if (sink_request & DS_PORT_STATUS_CHANGED) {
> > + dp->hpd_state = ST_CONNECT_PENDING;
> > + hpd->hpd_high = 1;
> > + }
> > +
> > + rc = dp_display_handle_irq_hpd(dp);
> > +
> > + if (rc && sink_request & DS_PORT_STATUS_CHANGED) {
>
> Can you add parenthesis around this?
>
> if (rc && (sink_request & DS_PORT_STATUS_CHANGED)) {
>
>
> I honestly don't know what's going on in this patch. It talks about
> making link training happen during irq hpd handler but this is the
> attention handler and we're checking port status changed? This is
> related? The code is really not clear.
>
> > + hpd->hpd_high = 0;
> > + dp->hpd_state = ST_DISCONNECTED;
> > + }
> > + }
> >
> > return rc;
> > }
> >
> > base-commit: 0e162b10644605428cd2596c12f8ed410cf9d2d9
>
> What commit is this?
Note that I skipped over a few dp related patches yesterday while
starting to pull things into msm-next-staging.
Kuogee, when you send the next version can you make sure it is based
against v5.10-rc or msm-next-staging?
BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Why is atomic_disable callback's plane->state->crtc sometimes null?
Hi, First, I will like to thank those who gave me hints on how to proceed with getting rid of an unwanted double allocation of visible portion of the frame buffer. https://lists.freedesktop.org/archives/dri-devel/2020-October/283452.html I may repost the question later to the mailing list based on the feedback I received. After a few more days of trying, I finally got my prototype OpenChrome DRM atomic modesetting code barely working for both primary and cursor planes (cursor plane was not working previously). I finally figured out what was causing the freeze, and in fact, I am writing this e-mail from the very computer that has the experimental code running. The code itself is still quite unstable that standby resume is not working and VT (Virtual Terminal) is broken, but X Server is working fine just with a few minor weird artifact lines on the right and bottom edges of the screen. Anyway, the question I have here (and I am assuming that Daniel Vetter will give me an explanation) is that I noticed that for cursor plane's atomic_disable callback, plane->state->crtc is null or sometimes null. Why is this? Assuming that plane->state->crtc will not be null was one the reason why the code was not working, so I will like to know the reason. Regards, Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build warning after merge of the drm-misc-fixes tree
Hi all,
After merging the drm-misc-fixes tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/gpu/drm/vc4/vc4_drv.c: In function 'vc4_drm_unbind':
drivers/gpu/drm/vc4/vc4_drv.c:322:18: warning: unused variable 'vc4'
[-Wunused-variable]
322 | struct vc4_dev *vc4 = to_vc4_dev(drm);
| ^~~
Introduced by commit
dcda7c28bff2 ("drm/vc4: kms: Add functions to create the state objects")
--
Cheers,
Stephen Rothwell
pgprcjFbNdBAB.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/11] Decouple Mediatek DRM sub driver
mtk ccorr is controlled by DRM and MDP [1]. In order to share mtk_ccorr driver for DRM and MDP, decouple Mediatek DRM sub driver which include mtk_ccorr, so MDP could use this decoupled mtk_ccorr. [1] https://patchwork.kernel.org/patch/11140751/ CK Hu (9): drm/mediatek: Move clk info from struct mtk_ddp_comp to sub driver private data drm/mediatek: Move regs info from struct mtk_ddp_comp to sub driver private data drm/mediatek: Remove irq in struct mtk_ddp_comp drm/mediatek: Use struct cmdq_client_reg to gather cmdq variable drm/mediatek: Move cmdq_reg info from struct mtk_ddp_comp to sub driver private data drm/mediatek: Change sub driver interface from mtk_ddp_comp to device drm/mediatek: Register vblank callback function drm/mediatek: DRM driver directly refer to sub driver's function drm/mediatek: Move mtk_ddp_comp_init() from sub driver to DRM driver Chun-Kuang Hu (2): drm/mediatek: Get CMDQ client register for all ddp component drm/mediatek: Use correct device pointer to get CMDQ client register drivers/gpu/drm/mediatek/mtk_disp_color.c | 86 ++--- drivers/gpu/drm/mediatek/mtk_disp_drv.h | 69 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 215 ++- drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 169 + drivers/gpu/drm/mediatek/mtk_dpi.c | 44 +-- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 75 ++-- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 - drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 389 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 100 ++--- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 30 +- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +- drivers/gpu/drm/mediatek/mtk_dsi.c | 47 +-- 12 files changed, 658 insertions(+), 569 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_drv.h -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/11] drm/mediatek: Use correct device pointer to get CMDQ client register
Some ddp component use mmsys device pointer to get CMDQ client
register, this would get mmsys' CMDQ client register, so use
each ddp component's device pointer to get.
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_disp_color.c | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 2 +-
drivers/gpu/drm/mediatek/mtk_dpi.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 14 +++---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 5 ++---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 2 +-
8 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 3ae9c810845b..461d96cb5cfa 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -116,7 +116,7 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
return comp_id;
}
- ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
+ ret = mtk_ddp_comp_init(dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_color_funcs);
if (ret) {
if (ret != -EPROBE_DEFER)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 28651bc579bc..f89a2b3e56f4 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -383,7 +383,7 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
return comp_id;
}
- ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
+ ret = mtk_ddp_comp_init(dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_ovl_funcs);
if (ret) {
if (ret != -EPROBE_DEFER)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index e04319fedf46..7a5dad4a2597 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -291,7 +291,7 @@ static int mtk_disp_rdma_probe(struct platform_device *pdev)
return comp_id;
}
- ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
+ ret = mtk_ddp_comp_init(dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_rdma_funcs);
if (ret) {
if (ret != -EPROBE_DEFER)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index cf11c4850b40..6852b76fa583 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -784,7 +784,7 @@ static int mtk_dpi_probe(struct platform_device *pdev)
return comp_id;
}
- ret = mtk_ddp_comp_init(dev, dev->of_node, &dpi->ddp_comp, comp_id,
+ ret = mtk_ddp_comp_init(dev->of_node, &dpi->ddp_comp, comp_id,
&mtk_dpi_funcs);
if (ret) {
dev_err(dev, "Failed to initialize component: %d\n", ret);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index c17c0e4c030f..93a10550a147 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -465,10 +465,11 @@ unsigned int mtk_drm_find_possible_crtc_by_comp(struct
drm_device *drm,
return ret;
}
-int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
- struct mtk_ddp_comp *comp, enum mtk_ddp_comp_id comp_id,
- const struct mtk_ddp_comp_funcs *funcs)
+int mtk_ddp_comp_init(struct device_node *node, struct mtk_ddp_comp *comp,
+ enum mtk_ddp_comp_id comp_id, const struct
mtk_ddp_comp_funcs *funcs)
{
+ struct platform_device *comp_pdev;
+ struct device *dev;
enum mtk_ddp_comp_type type;
struct device_node *larb_node;
struct platform_device *larb_pdev;
@@ -506,6 +507,13 @@ int mtk_ddp_comp_init(struct device *dev, struct
device_node *node,
if (IS_ERR(comp->clk))
return PTR_ERR(comp->clk);
+ comp_pdev = of_find_device_by_node(node);
+ if (!comp_pdev) {
+ DRM_INFO("Waiting for device %s\n", node->full_name);
+ return -EPROBE_DEFER;
+ }
+ dev = &comp_pdev->dev;
+
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
if (of_address_to_resource(node, 0, &res) != 0) {
dev_err(dev, "Missing reg in %s node\n", node->full_name);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 1d9e00b69462..3bd6012d0746 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -204,9 +204,8 @@ int mtk_ddp_comp_get_id(struct device_node *node,
[PATCH 01/11] drm/mediatek: Get CMDQ client register for all ddp component
Only OVL, RDMA,and WDMA get CMDQ client register information,
but all ddp component should work with CMDQ, so get this
information for all ddp component.
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 28 ++---
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 8eba44be3a8a..c17c0e4c030f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -506,6 +506,20 @@ int mtk_ddp_comp_init(struct device *dev, struct
device_node *node,
if (IS_ERR(comp->clk))
return PTR_ERR(comp->clk);
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+ if (of_address_to_resource(node, 0, &res) != 0) {
+ dev_err(dev, "Missing reg in %s node\n", node->full_name);
+ return -EINVAL;
+ }
+ comp->regs_pa = res.start;
+
+ ret = cmdq_dev_get_client_reg(dev, &cmdq_reg, 0);
+ if (ret)
+ dev_dbg(dev, "get mediatek,gce-client-reg fail!\n");
+ else
+ comp->subsys = cmdq_reg.subsys;
+#endif
+
/* Only DMA capable components need the LARB property */
comp->larb_dev = NULL;
if (type != MTK_DISP_OVL &&
@@ -531,20 +545,6 @@ int mtk_ddp_comp_init(struct device *dev, struct
device_node *node,
comp->larb_dev = &larb_pdev->dev;
-#if IS_REACHABLE(CONFIG_MTK_CMDQ)
- if (of_address_to_resource(node, 0, &res) != 0) {
- dev_err(dev, "Missing reg in %s node\n", node->full_name);
- put_device(&larb_pdev->dev);
- return -EINVAL;
- }
- comp->regs_pa = res.start;
-
- ret = cmdq_dev_get_client_reg(dev, &cmdq_reg, 0);
- if (ret)
- dev_dbg(dev, "get mediatek,gce-client-reg fail!\n");
- else
- comp->subsys = cmdq_reg.subsys;
-#endif
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/11] drm/mediatek: DRM driver directly refer to sub driver's function
From: CK Hu
Some ddp component exist in both display path and other path, so
sub driver should not directly call DRM driver's function. Let
DRM driver directly refer to sub driver's function so that sub
driver need not register these function to DRM driver.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_disp_color.c | 23 +++---
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 69 ++
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 68 +++---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 46 +---
drivers/gpu/drm/mediatek/mtk_dpi.c | 13 ++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 80 -
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 13 ++--
9 files changed, 193 insertions(+), 124 deletions(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_drv.h
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index cc11d857ba60..99a680164226 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -11,6 +11,7 @@
#include
#include
+#include "mtk_disp_drv.h"
#include "mtk_drm_crtc.h"
#include "mtk_drm_ddp_comp.h"
@@ -42,23 +43,23 @@ struct mtk_disp_color {
const struct mtk_disp_color_data*data;
};
-static int mtk_color_clk_enable(struct device *dev)
+int mtk_color_clk_enable(struct device *dev)
{
struct mtk_disp_color *color = dev_get_drvdata(dev);
return clk_prepare_enable(color->clk);
}
-static void mtk_color_clk_disable(struct device *dev)
+void mtk_color_clk_disable(struct device *dev)
{
struct mtk_disp_color *color = dev_get_drvdata(dev);
clk_disable_unprepare(color->clk);
}
-static void mtk_color_config(struct device *dev, unsigned int w,
-unsigned int h, unsigned int vrefresh,
-unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
+void mtk_color_config(struct device *dev, unsigned int w,
+ unsigned int h, unsigned int vrefresh,
+ unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
{
struct mtk_disp_color *color = dev_get_drvdata(dev);
@@ -66,7 +67,7 @@ static void mtk_color_config(struct device *dev, unsigned int
w,
mtk_ddp_write(cmdq_pkt, h, &color->cmdq_reg, color->regs,
DISP_COLOR_HEIGHT(color));
}
-static void mtk_color_start(struct device *dev)
+void mtk_color_start(struct device *dev)
{
struct mtk_disp_color *color = dev_get_drvdata(dev);
@@ -75,13 +76,6 @@ static void mtk_color_start(struct device *dev)
writel(0x1, color->regs + DISP_COLOR_START(color));
}
-static const struct mtk_ddp_comp_funcs mtk_disp_color_funcs = {
- .clk_enable = mtk_color_clk_enable,
- .clk_disable = mtk_color_clk_disable,
- .config = mtk_color_config,
- .start = mtk_color_start,
-};
-
static int mtk_disp_color_bind(struct device *dev, struct device *master,
void *data)
{
@@ -149,8 +143,7 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
return comp_id;
}
- ret = mtk_ddp_comp_init(dev->of_node, &priv->ddp_comp, comp_id,
- &mtk_disp_color_funcs);
+ ret = mtk_ddp_comp_init(dev->of_node, &priv->ddp_comp, comp_id);
if (ret) {
if (ret != -EPROBE_DEFER)
dev_err(dev, "Failed to initialize component: %d\n",
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
new file mode 100644
index ..46d199b7b4a2
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ */
+
+#ifndef _MTK_DISP_DRV_H_
+#define _MTK_DISP_DRV_H_
+
+#include
+#include "mtk_drm_plane.h"
+
+void mtk_color_bypass_shadow(struct device *dev);
+int mtk_color_clk_enable(struct device *dev);
+void mtk_color_clk_disable(struct device *dev);
+void mtk_color_config(struct device *dev, unsigned int w,
+ unsigned int h, unsigned int vrefresh,
+ unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
+void mtk_color_start(struct device *dev);
+
+void mtk_dpi_start(struct device *dev);
+void mtk_dpi_stop(struct device *dev);
+
+void mtk_dsi_ddp_start(struct device *dev);
+void mtk_dsi_ddp_stop(struct device *dev);
+
+void mtk_ovl_bgclr_in_on(struct device *dev);
+void mtk_ovl_bgclr_in_off(struct device *dev);
+void mtk_ovl_bypass_shadow(struct device *dev);
+int mtk_ovl_clk_enable(struct device *dev);
+void mtk_ovl_clk_disable(struct device *dev);
+void mtk_ovl_config(struct device *dev, unsigned int w,
+ unsigned int h, unsigned int vrefresh,
+ unsigned int bpc, struct
[PATCH 05/11] drm/mediatek: Remove irq in struct mtk_ddp_comp
From: CK Hu
irq in struct mtk_ddp_comp is useless, so remove it.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 2a3ba50d5397..27daff9458d6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -559,11 +558,9 @@ int mtk_ddp_comp_init(struct device_node *node, struct
mtk_ddp_comp *comp,
comp_id == DDP_COMPONENT_DSI2 ||
comp_id == DDP_COMPONENT_DSI3 ||
comp_id == DDP_COMPONENT_PWM0) {
- comp->irq = 0;
return 0;
}
- comp->irq = of_irq_get(node, 0);
comp_pdev = of_find_device_by_node(node);
if (!comp_pdev) {
DRM_INFO("Waiting for device %s\n", node->full_name);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] drm/mediatek: Move clk info from struct mtk_ddp_comp to sub driver private data
From: CK Hu
Some ddp component exist in both display path and other path, so data
belonged to sub driver should be moved into sub driver private data so it
could be used for multiple path. clk info is one of sub driver data, so
move it.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_disp_color.c | 23 +++
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 23 +++
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 23 +++
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 6 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 70 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 18 +-
6 files changed, 147 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 461d96cb5cfa..52af5e0ee7e3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -36,6 +36,7 @@ struct mtk_disp_color_data {
struct mtk_disp_color {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
+ struct clk *clk;
const struct mtk_disp_color_data*data;
};
@@ -44,6 +45,20 @@ static inline struct mtk_disp_color *comp_to_color(struct
mtk_ddp_comp *comp)
return container_of(comp, struct mtk_disp_color, ddp_comp);
}
+static int mtk_color_clk_enable(struct device *dev)
+{
+ struct mtk_disp_color *color = dev_get_drvdata(dev);
+
+ return clk_prepare_enable(color->clk);
+}
+
+static void mtk_color_clk_disable(struct device *dev)
+{
+ struct mtk_disp_color *color = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(color->clk);
+}
+
static void mtk_color_config(struct mtk_ddp_comp *comp, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
@@ -64,6 +79,8 @@ static void mtk_color_start(struct mtk_ddp_comp *comp)
}
static const struct mtk_ddp_comp_funcs mtk_disp_color_funcs = {
+ .clk_enable = mtk_color_clk_enable,
+ .clk_disable = mtk_color_clk_disable,
.config = mtk_color_config,
.start = mtk_color_start,
};
@@ -110,6 +127,12 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
if (!priv)
return -ENOMEM;
+ priv->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(priv->clk)) {
+ dev_err(dev, "failed to get color clk\n");
+ return PTR_ERR(priv->clk);
+ }
+
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DISP_COLOR);
if (comp_id < 0) {
dev_err(dev, "Failed to identify by alias: %d\n", comp_id);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index f89a2b3e56f4..8104824c5db6 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -71,6 +71,7 @@ struct mtk_disp_ovl_data {
struct mtk_disp_ovl {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
+ struct clk *clk;
const struct mtk_disp_ovl_data *data;
};
@@ -113,6 +114,20 @@ static void mtk_ovl_disable_vblank(struct mtk_ddp_comp
*comp)
writel_relaxed(0x0, comp->regs + DISP_REG_OVL_INTEN);
}
+static int mtk_ovl_clk_enable(struct device *dev)
+{
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+
+ return clk_prepare_enable(ovl->clk);
+}
+
+static void mtk_ovl_clk_disable(struct device *dev)
+{
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(ovl->clk);
+}
+
static void mtk_ovl_start(struct mtk_ddp_comp *comp)
{
writel_relaxed(0x1, comp->regs + DISP_REG_OVL_EN);
@@ -312,6 +327,8 @@ static void mtk_ovl_bgclr_in_off(struct mtk_ddp_comp *comp)
}
static const struct mtk_ddp_comp_funcs mtk_disp_ovl_funcs = {
+ .clk_enable = mtk_ovl_clk_enable,
+ .clk_disable = mtk_ovl_clk_disable,
.config = mtk_ovl_config,
.start = mtk_ovl_start,
.stop = mtk_ovl_stop,
@@ -372,6 +389,12 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
if (irq < 0)
return irq;
+ priv->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(priv->clk)) {
+ dev_err(dev, "failed to get ovl clk\n");
+ return PTR_ERR(priv->clk);
+ }
+
priv->data = of_device_get_match_data(dev);
comp_id = mtk_ddp_comp_get_id(dev->of_node,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 7a5dad4a2597..86c3f96f3ed8 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -62,6 +62,7 @@ struct mtk_disp_rdma_data {
struct mtk_disp_rdma {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc
[PATCH 06/11] drm/mediatek: Use struct cmdq_client_reg to gather cmdq variable
From: CK Hu
struct cmdq_client_reg include subsys and offset, so use it to replace
these two variable.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 24 ++---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 4 ++--
2 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 27daff9458d6..bf166b032fca 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -96,8 +96,8 @@ void mtk_ddp_write(struct cmdq_pkt *cmdq_pkt, unsigned int
value,
{
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
if (cmdq_pkt)
- cmdq_pkt_write(cmdq_pkt, comp->subsys,
- comp->regs_pa + offset, value);
+ cmdq_pkt_write(cmdq_pkt, comp->cmdq_reg.subsys,
+ comp->cmdq_reg.offset + offset, value);
else
#endif
writel(value, regs + offset);
@@ -109,8 +109,8 @@ void mtk_ddp_write_relaxed(struct cmdq_pkt *cmdq_pkt,
unsigned int value,
{
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
if (cmdq_pkt)
- cmdq_pkt_write(cmdq_pkt, comp->subsys,
- comp->regs_pa + offset, value);
+ cmdq_pkt_write(cmdq_pkt, comp->cmdq_reg.subsys,
+ comp->cmdq_reg.offset + offset, value);
else
#endif
writel_relaxed(value, regs + offset);
@@ -122,8 +122,8 @@ void mtk_ddp_write_mask(struct cmdq_pkt *cmdq_pkt, unsigned
int value,
{
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
if (cmdq_pkt) {
- cmdq_pkt_write_mask(cmdq_pkt, comp->subsys,
- comp->regs_pa + offset, value, mask);
+ cmdq_pkt_write_mask(cmdq_pkt, comp->cmdq_reg.subsys,
+ comp->cmdq_reg.offset + offset, value,
mask);
} else {
#endif
u32 tmp = readl(regs + offset);
@@ -537,8 +537,6 @@ int mtk_ddp_comp_init(struct device_node *node, struct
mtk_ddp_comp *comp,
struct platform_device *larb_pdev;
struct mtk_ddp_comp_dev *priv;
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
- struct resource res;
- struct cmdq_client_reg cmdq_reg;
int ret;
#endif
@@ -569,17 +567,9 @@ int mtk_ddp_comp_init(struct device_node *node, struct
mtk_ddp_comp *comp,
comp->dev = &comp_pdev->dev;
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
- if (of_address_to_resource(node, 0, &res) != 0) {
- dev_err(comp->dev, "Missing reg in %s node\n", node->full_name);
- return -EINVAL;
- }
- comp->regs_pa = res.start;
-
- ret = cmdq_dev_get_client_reg(comp->dev, &cmdq_reg, 0);
+ ret = cmdq_dev_get_client_reg(comp->dev, &comp->cmdq_reg, 0);
if (ret)
dev_dbg(comp->dev, "get mediatek,gce-client-reg fail!\n");
- else
- comp->subsys = cmdq_reg.subsys;
#endif
if (comp_id == DDP_COMPONENT_COLOR0 ||
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index e18299573d2b..621b07ef807e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -7,6 +7,7 @@
#define MTK_DRM_DDP_COMP_H
#include
+#include
struct device;
struct device_node;
@@ -102,8 +103,7 @@ struct mtk_ddp_comp {
struct device *larb_dev;
enum mtk_ddp_comp_id id;
const struct mtk_ddp_comp_funcs *funcs;
- resource_size_t regs_pa;
- u8 subsys;
+ struct cmdq_client_reg cmdq_reg;
};
static inline int mtk_ddp_comp_clk_enable(struct mtk_ddp_comp *comp)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/11] drm/mediatek: Move regs info from struct mtk_ddp_comp to sub driver private data
From: CK Hu
Some ddp component exist in both display path and other path, so data
belonged to sub driver should be moved into sub driver private data so it
could be used for multiple path. regs info is one of sub driver data, so
move it.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_disp_color.c | 17 ++-
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 67 +++
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 42 ---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 121 +---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 11 +-
5 files changed, 165 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 52af5e0ee7e3..8b61573a5f72 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -37,6 +37,7 @@ struct mtk_disp_color {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
struct clk *clk;
+ void __iomem*regs;
const struct mtk_disp_color_data*data;
};
@@ -65,8 +66,8 @@ static void mtk_color_config(struct mtk_ddp_comp *comp,
unsigned int w,
{
struct mtk_disp_color *color = comp_to_color(comp);
- mtk_ddp_write(cmdq_pkt, w, comp, DISP_COLOR_WIDTH(color));
- mtk_ddp_write(cmdq_pkt, h, comp, DISP_COLOR_HEIGHT(color));
+ mtk_ddp_write(cmdq_pkt, w, comp, color->regs, DISP_COLOR_WIDTH(color));
+ mtk_ddp_write(cmdq_pkt, h, comp, color->regs, DISP_COLOR_HEIGHT(color));
}
static void mtk_color_start(struct mtk_ddp_comp *comp)
@@ -74,8 +75,8 @@ static void mtk_color_start(struct mtk_ddp_comp *comp)
struct mtk_disp_color *color = comp_to_color(comp);
writel(COLOR_BYPASS_ALL | COLOR_SEQ_SEL,
- comp->regs + DISP_COLOR_CFG_MAIN);
- writel(0x1, comp->regs + DISP_COLOR_START(color));
+ color->regs + DISP_COLOR_CFG_MAIN);
+ writel(0x1, color->regs + DISP_COLOR_START(color));
}
static const struct mtk_ddp_comp_funcs mtk_disp_color_funcs = {
@@ -120,6 +121,7 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
{
struct device *dev = &pdev->dev;
struct mtk_disp_color *priv;
+ struct resource *res;
int comp_id;
int ret;
@@ -133,6 +135,13 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
return PTR_ERR(priv->clk);
}
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(priv->regs)) {
+ dev_err(dev, "failed to ioremap color\n");
+ return PTR_ERR(priv->regs);
+ }
+
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DISP_COLOR);
if (comp_id < 0) {
dev_err(dev, "Failed to identify by alias: %d\n", comp_id);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8104824c5db6..63164679f04d 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -72,6 +72,7 @@ struct mtk_disp_ovl {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
struct clk *clk;
+ void __iomem*regs;
const struct mtk_disp_ovl_data *data;
};
@@ -86,7 +87,7 @@ static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void
*dev_id)
struct mtk_ddp_comp *ovl = &priv->ddp_comp;
/* Clear frame completion interrupt */
- writel(0x0, ovl->regs + DISP_REG_OVL_INTSTA);
+ writel(0x0, priv->regs + DISP_REG_OVL_INTSTA);
if (!priv->crtc)
return IRQ_NONE;
@@ -102,8 +103,8 @@ static void mtk_ovl_enable_vblank(struct mtk_ddp_comp *comp,
struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
ovl->crtc = crtc;
- writel(0x0, comp->regs + DISP_REG_OVL_INTSTA);
- writel_relaxed(OVL_FME_CPL_INT, comp->regs + DISP_REG_OVL_INTEN);
+ writel(0x0, ovl->regs + DISP_REG_OVL_INTSTA);
+ writel_relaxed(OVL_FME_CPL_INT, ovl->regs + DISP_REG_OVL_INTEN);
}
static void mtk_ovl_disable_vblank(struct mtk_ddp_comp *comp)
@@ -111,7 +112,7 @@ static void mtk_ovl_disable_vblank(struct mtk_ddp_comp
*comp)
struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
ovl->crtc = NULL;
- writel_relaxed(0x0, comp->regs + DISP_REG_OVL_INTEN);
+ writel_relaxed(0x0, ovl->regs + DISP_REG_OVL_INTEN);
}
static int mtk_ovl_clk_enable(struct device *dev)
@@ -130,25 +131,31 @@ static void mtk_ovl_clk_disable(struct device *dev)
static void mtk_ovl_start(struct mtk_ddp_comp *comp)
{
- writel_relaxed(0x1, comp->regs + DISP_REG_OVL_EN);
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(comp->dev);
+
+ writel_relaxed(0x1, ovl-
[PATCH 09/11] drm/mediatek: Register vblank callback function
From: CK Hu
Some ddp component exist in both display path and other path, so
sub driver should not directly call crtc function. crtc register
callback function to sub driver to prevent sub driver directly
call crtc function.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 16 +++--
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 17 +++---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 67 +++--
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 -
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 9 ++-
5 files changed, 60 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index ab56054b0934..e07611edf5f0 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -75,30 +75,33 @@ struct mtk_disp_ovl {
void __iomem*regs;
struct cmdq_client_reg cmdq_reg;
const struct mtk_disp_ovl_data *data;
+ void(*vblank_cb)(void *data);
+ void*vblank_cb_data;
};
static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
{
struct mtk_disp_ovl *priv = dev_id;
- struct mtk_ddp_comp *ovl = &priv->ddp_comp;
/* Clear frame completion interrupt */
writel(0x0, priv->regs + DISP_REG_OVL_INTSTA);
- if (!priv->crtc)
+ if (!priv->vblank_cb)
return IRQ_NONE;
- mtk_crtc_ddp_irq(priv->crtc, ovl);
+ priv->vblank_cb(priv->vblank_cb_data);
return IRQ_HANDLED;
}
static void mtk_ovl_enable_vblank(struct device *dev,
- struct drm_crtc *crtc)
+ void (*vblank_cb)(void *),
+ void *vblank_cb_data)
{
struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
- ovl->crtc = crtc;
+ ovl->vblank_cb = vblank_cb;
+ ovl->vblank_cb_data = vblank_cb_data;
writel(0x0, ovl->regs + DISP_REG_OVL_INTSTA);
writel_relaxed(OVL_FME_CPL_INT, ovl->regs + DISP_REG_OVL_INTEN);
}
@@ -107,7 +110,8 @@ static void mtk_ovl_disable_vblank(struct device *dev)
{
struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
- ovl->crtc = NULL;
+ ovl->vblank_cb = NULL;
+ ovl->vblank_cb_data = NULL;
writel_relaxed(0x0, ovl->regs + DISP_REG_OVL_INTEN);
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 1976769ae4e3..edffe25f14b4 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -61,25 +61,25 @@ struct mtk_disp_rdma_data {
*/
struct mtk_disp_rdma {
struct mtk_ddp_comp ddp_comp;
- struct drm_crtc *crtc;
struct clk *clk;
void __iomem*regs;
struct cmdq_client_reg cmdq_reg;
const struct mtk_disp_rdma_data *data;
+ void(*vblank_cb)(void *data);
+ void*vblank_cb_data;
};
static irqreturn_t mtk_disp_rdma_irq_handler(int irq, void *dev_id)
{
struct mtk_disp_rdma *priv = dev_id;
- struct mtk_ddp_comp *rdma = &priv->ddp_comp;
/* Clear frame completion interrupt */
writel(0x0, priv->regs + DISP_REG_RDMA_INT_STATUS);
- if (!priv->crtc)
+ if (!priv->vblank_cb)
return IRQ_NONE;
- mtk_crtc_ddp_irq(priv->crtc, rdma);
+ priv->vblank_cb(priv->vblank_cb_data);
return IRQ_HANDLED;
}
@@ -95,11 +95,13 @@ static void rdma_update_bits(struct device *dev, unsigned
int reg,
}
static void mtk_rdma_enable_vblank(struct device *dev,
- struct drm_crtc *crtc)
+ void (*vblank_cb)(void *),
+ void *vblank_cb_data)
{
struct mtk_disp_rdma *rdma = dev_get_drvdata(dev);
- rdma->crtc = crtc;
+ rdma->vblank_cb = vblank_cb;
+ rdma->vblank_cb_data = vblank_cb_data;
rdma_update_bits(dev, DISP_REG_RDMA_INT_ENABLE, RDMA_FRAME_END_INT,
RDMA_FRAME_END_INT);
}
@@ -108,7 +110,8 @@ static void mtk_rdma_disable_vblank(struct device *dev)
{
struct mtk_disp_rdma *rdma = dev_get_drvdata(dev);
- rdma->crtc = NULL;
+ rdma->vblank_cb = NULL;
+ rdma->vblank_cb_data = NULL;
rdma_update_bits(dev, DISP_REG_RDMA_INT_ENABLE, RDMA_FRAME_END_INT, 0);
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index f1dd5943ba0c..01c35786be49 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -166,24 +166,6 @@ static void mtk_drm_crtc_mode_set_nofb(struct drm_crtc
*crtc)
state->pending_config = true
[PATCH 08/11] drm/mediatek: Change sub driver interface from mtk_ddp_comp to device
From: CK Hu
Some ddp component exist in both display path and other path, so
sub driver interface should get rid of display info. Using device
instead of mtk_ddp_comp make interface general.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_disp_color.c | 13 +--
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 57 +--
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 39
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 100 ++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 54 +--
drivers/gpu/drm/mediatek/mtk_dsi.c | 8 +-
7 files changed, 129 insertions(+), 150 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 950b7b92e2c3..cc11d857ba60 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -42,11 +42,6 @@ struct mtk_disp_color {
const struct mtk_disp_color_data*data;
};
-static inline struct mtk_disp_color *comp_to_color(struct mtk_ddp_comp *comp)
-{
- return container_of(comp, struct mtk_disp_color, ddp_comp);
-}
-
static int mtk_color_clk_enable(struct device *dev)
{
struct mtk_disp_color *color = dev_get_drvdata(dev);
@@ -61,19 +56,19 @@ static void mtk_color_clk_disable(struct device *dev)
clk_disable_unprepare(color->clk);
}
-static void mtk_color_config(struct mtk_ddp_comp *comp, unsigned int w,
+static void mtk_color_config(struct device *dev, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
{
- struct mtk_disp_color *color = comp_to_color(comp);
+ struct mtk_disp_color *color = dev_get_drvdata(dev);
mtk_ddp_write(cmdq_pkt, w, &color->cmdq_reg, color->regs,
DISP_COLOR_WIDTH(color));
mtk_ddp_write(cmdq_pkt, h, &color->cmdq_reg, color->regs,
DISP_COLOR_HEIGHT(color));
}
-static void mtk_color_start(struct mtk_ddp_comp *comp)
+static void mtk_color_start(struct device *dev)
{
- struct mtk_disp_color *color = comp_to_color(comp);
+ struct mtk_disp_color *color = dev_get_drvdata(dev);
writel(COLOR_BYPASS_ALL | COLOR_SEQ_SEL,
color->regs + DISP_COLOR_CFG_MAIN);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index d484d08e91e7..ab56054b0934 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -77,11 +77,6 @@ struct mtk_disp_ovl {
const struct mtk_disp_ovl_data *data;
};
-static inline struct mtk_disp_ovl *comp_to_ovl(struct mtk_ddp_comp *comp)
-{
- return container_of(comp, struct mtk_disp_ovl, ddp_comp);
-}
-
static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
{
struct mtk_disp_ovl *priv = dev_id;
@@ -98,19 +93,19 @@ static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-static void mtk_ovl_enable_vblank(struct mtk_ddp_comp *comp,
+static void mtk_ovl_enable_vblank(struct device *dev,
struct drm_crtc *crtc)
{
- struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
ovl->crtc = crtc;
writel(0x0, ovl->regs + DISP_REG_OVL_INTSTA);
writel_relaxed(OVL_FME_CPL_INT, ovl->regs + DISP_REG_OVL_INTEN);
}
-static void mtk_ovl_disable_vblank(struct mtk_ddp_comp *comp)
+static void mtk_ovl_disable_vblank(struct device *dev)
{
- struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
ovl->crtc = NULL;
writel_relaxed(0x0, ovl->regs + DISP_REG_OVL_INTEN);
@@ -130,25 +125,25 @@ static void mtk_ovl_clk_disable(struct device *dev)
clk_disable_unprepare(ovl->clk);
}
-static void mtk_ovl_start(struct mtk_ddp_comp *comp)
+static void mtk_ovl_start(struct device *dev)
{
- struct mtk_disp_ovl *ovl = dev_get_drvdata(comp->dev);
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
writel_relaxed(0x1, ovl->regs + DISP_REG_OVL_EN);
}
-static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
+static void mtk_ovl_stop(struct device *dev)
{
- struct mtk_disp_ovl *ovl = dev_get_drvdata(comp->dev);
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
writel_relaxed(0x0, ovl->regs + DISP_REG_OVL_EN);
}
-static void mtk_ovl_config(struct mtk_ddp_comp *comp, unsigned int w,
+static void mtk_ovl_config(struct device *dev, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
{
- struct mtk_disp_ovl *ovl = dev_get_drvdata(comp->dev);
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
if (w != 0 && h != 0)
[PATCH 07/11] drm/mediatek: Move cmdq_reg info from struct mtk_ddp_comp to sub driver private data
From: CK Hu
Some ddp component exist in both display path and other path, so data
belonged to sub driver should be moved into sub driver private data so it
could be used for multiple path. cmdq_reg info is one of sub driver data,
so move it.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_disp_color.c | 10 ++-
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 34 ++-
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 30 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 67 +++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 7 +--
5 files changed, 84 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 8b61573a5f72..950b7b92e2c3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -38,6 +38,7 @@ struct mtk_disp_color {
struct drm_crtc *crtc;
struct clk *clk;
void __iomem*regs;
+ struct cmdq_client_reg cmdq_reg;
const struct mtk_disp_color_data*data;
};
@@ -66,8 +67,8 @@ static void mtk_color_config(struct mtk_ddp_comp *comp,
unsigned int w,
{
struct mtk_disp_color *color = comp_to_color(comp);
- mtk_ddp_write(cmdq_pkt, w, comp, color->regs, DISP_COLOR_WIDTH(color));
- mtk_ddp_write(cmdq_pkt, h, comp, color->regs, DISP_COLOR_HEIGHT(color));
+ mtk_ddp_write(cmdq_pkt, w, &color->cmdq_reg, color->regs,
DISP_COLOR_WIDTH(color));
+ mtk_ddp_write(cmdq_pkt, h, &color->cmdq_reg, color->regs,
DISP_COLOR_HEIGHT(color));
}
static void mtk_color_start(struct mtk_ddp_comp *comp)
@@ -141,6 +142,11 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
dev_err(dev, "failed to ioremap color\n");
return PTR_ERR(priv->regs);
}
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+ ret = cmdq_dev_get_client_reg(dev, &priv->cmdq_reg, 0);
+ if (ret)
+ dev_dbg(dev, "get mediatek,gce-client-reg fail!\n");
+#endif
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DISP_COLOR);
if (comp_id < 0) {
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 63164679f04d..d484d08e91e7 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -73,6 +73,7 @@ struct mtk_disp_ovl {
struct drm_crtc *crtc;
struct clk *clk;
void __iomem*regs;
+ struct cmdq_client_reg cmdq_reg;
const struct mtk_disp_ovl_data *data;
};
@@ -150,12 +151,12 @@ static void mtk_ovl_config(struct mtk_ddp_comp *comp,
unsigned int w,
struct mtk_disp_ovl *ovl = dev_get_drvdata(comp->dev);
if (w != 0 && h != 0)
- mtk_ddp_write_relaxed(cmdq_pkt, h << 16 | w, comp, ovl->regs,
+ mtk_ddp_write_relaxed(cmdq_pkt, h << 16 | w, &ovl->cmdq_reg,
ovl->regs,
DISP_REG_OVL_ROI_SIZE);
- mtk_ddp_write_relaxed(cmdq_pkt, 0x0, comp, ovl->regs,
DISP_REG_OVL_ROI_BGCLR);
+ mtk_ddp_write_relaxed(cmdq_pkt, 0x0, &ovl->cmdq_reg, ovl->regs,
DISP_REG_OVL_ROI_BGCLR);
- mtk_ddp_write(cmdq_pkt, 0x1, comp, ovl->regs, DISP_REG_OVL_RST);
- mtk_ddp_write(cmdq_pkt, 0x0, comp, ovl->regs, DISP_REG_OVL_RST);
+ mtk_ddp_write(cmdq_pkt, 0x1, &ovl->cmdq_reg, ovl->regs,
DISP_REG_OVL_RST);
+ mtk_ddp_write(cmdq_pkt, 0x0, &ovl->cmdq_reg, ovl->regs,
DISP_REG_OVL_RST);
}
static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp *comp)
@@ -207,7 +208,7 @@ static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp,
unsigned int idx,
unsigned int gmc_value;
struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
- mtk_ddp_write(cmdq_pkt, 0x1, comp, ovl->regs,
+ mtk_ddp_write(cmdq_pkt, 0x1, &ovl->cmdq_reg, ovl->regs,
DISP_REG_OVL_RDMA_CTRL(idx));
gmc_thrshd_l = GMC_THRESHOLD_LOW >>
(GMC_THRESHOLD_BITS - ovl->data->gmc_bits);
@@ -219,8 +220,8 @@ static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp,
unsigned int idx,
gmc_value = gmc_thrshd_l | gmc_thrshd_l << 8 |
gmc_thrshd_h << 16 | gmc_thrshd_h << 24;
mtk_ddp_write(cmdq_pkt, gmc_value,
- comp, ovl->regs, DISP_REG_OVL_RDMA_GMC(idx));
- mtk_ddp_write_mask(cmdq_pkt, BIT(idx), comp, ovl->regs,
+ &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_RDMA_GMC(idx));
+ mtk_ddp_write_mask(cmdq_pkt, BIT(idx), &ovl->cmdq_reg, ovl->regs,
DISP_REG_OVL_SRC_CON, BIT(idx));
}
@@ -229,9 +230,9 @@ static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp,
unsigned int idx,
{
struct mtk_disp_ovl *ovl = dev_get_drvda
[PATCH 11/11] drm/mediatek: Move mtk_ddp_comp_init() from sub driver to DRM driver
From: CK Hu
Some ddp component exist in both display path and other path, so
sub driver should not directly call DRM driver's function. Moving
mtk_ddp_comp_init() from sub driver to DRM driver to achieve this.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_disp_color.c | 32 -
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 36 ---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 32 -
drivers/gpu/drm/mediatek/mtk_dpi.c | 29 ++--
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 38 ++---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 4 +--
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 29 +---
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 32 +
10 files changed, 25 insertions(+), 211 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 99a680164226..2217965041d8 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -35,7 +35,6 @@ struct mtk_disp_color_data {
* @crtc - associated crtc to report irq events to
*/
struct mtk_disp_color {
- struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
struct clk *clk;
void __iomem*regs;
@@ -79,27 +78,12 @@ void mtk_color_start(struct device *dev)
static int mtk_disp_color_bind(struct device *dev, struct device *master,
void *data)
{
- struct mtk_disp_color *priv = dev_get_drvdata(dev);
- struct drm_device *drm_dev = data;
- int ret;
-
- ret = mtk_ddp_comp_register(drm_dev, &priv->ddp_comp);
- if (ret < 0) {
- dev_err(dev, "Failed to register component %pOF: %d\n",
- dev->of_node, ret);
- return ret;
- }
-
return 0;
}
static void mtk_disp_color_unbind(struct device *dev, struct device *master,
void *data)
{
- struct mtk_disp_color *priv = dev_get_drvdata(dev);
- struct drm_device *drm_dev = data;
-
- mtk_ddp_comp_unregister(drm_dev, &priv->ddp_comp);
}
static const struct component_ops mtk_disp_color_component_ops = {
@@ -112,7 +96,6 @@ static int mtk_disp_color_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct mtk_disp_color *priv;
struct resource *res;
- int comp_id;
int ret;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -137,21 +120,6 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
dev_dbg(dev, "get mediatek,gce-client-reg fail!\n");
#endif
- comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DISP_COLOR);
- if (comp_id < 0) {
- dev_err(dev, "Failed to identify by alias: %d\n", comp_id);
- return comp_id;
- }
-
- ret = mtk_ddp_comp_init(dev->of_node, &priv->ddp_comp, comp_id);
- if (ret) {
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "Failed to initialize component: %d\n",
- ret);
-
- return ret;
- }
-
priv->data = of_device_get_match_data(dev);
platform_set_drvdata(pdev, priv);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index d1ec5e19d1ff..fd5262ae7c0f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -70,7 +70,6 @@ struct mtk_disp_ovl_data {
* @crtc - associated crtc to report vblank events to
*/
struct mtk_disp_ovl {
- struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
struct clk *clk;
void __iomem*regs;
@@ -341,27 +340,12 @@ void mtk_ovl_bgclr_in_off(struct device *dev)
static int mtk_disp_ovl_bind(struct device *dev, struct device *master,
void *data)
{
- struct mtk_disp_ovl *priv = dev_get_drvdata(dev);
- struct drm_device *drm_dev = data;
- int ret;
-
- ret = mtk_ddp_comp_register(drm_dev, &priv->ddp_comp);
- if (ret < 0) {
- dev_err(dev, "Failed to register component %pOF: %d\n",
- dev->of_node, ret);
- return ret;
- }
-
return 0;
}
static void mtk_disp_ovl_unbind(struct device *dev, struct device *master,
void *data)
{
- struct mtk_disp_ovl *priv = dev_get_drvdata(dev);
- struct drm_device *drm_dev = data;
-
- mtk_ddp_comp_unregister(drm_dev, &priv->ddp_comp);
}
static const struct component_ops mtk_disp_ovl_compo
[PATCH AUTOSEL 5.9 33/35] drm/nouveau/nouveau: fix the start/end range for migration
From: Ralph Campbell
[ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ]
The user level OpenCL code shouldn't have to align start and end
addresses to a page boundary. That is better handled in the nouveau
driver. The npages field is also redundant since it can be computed
from the start and end addresses.
Signed-off-by: Ralph Campbell
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 2df1c04605594..4f69e4c3dafde 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -105,11 +105,11 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
struct nouveau_cli *cli = nouveau_cli(file_priv);
struct drm_nouveau_svm_bind *args = data;
unsigned target, cmd, priority;
- unsigned long addr, end, size;
+ unsigned long addr, end;
struct mm_struct *mm;
args->va_start &= PAGE_MASK;
- args->va_end &= PAGE_MASK;
+ args->va_end = ALIGN(args->va_end, PAGE_SIZE);
/* Sanity check arguments */
if (args->reserved0 || args->reserved1)
@@ -118,8 +118,6 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
return -EINVAL;
if (args->va_start >= args->va_end)
return -EINVAL;
- if (!args->npages)
- return -EINVAL;
cmd = args->header >> NOUVEAU_SVM_BIND_COMMAND_SHIFT;
cmd &= NOUVEAU_SVM_BIND_COMMAND_MASK;
@@ -151,12 +149,6 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
if (args->stride)
return -EINVAL;
- size = ((unsigned long)args->npages) << PAGE_SHIFT;
- if ((args->va_start + size) <= args->va_start)
- return -EINVAL;
- if ((args->va_start + size) > args->va_end)
- return -EINVAL;
-
/*
* Ok we are ask to do something sane, for now we only support migrate
* commands but we will add things like memory policy (what to do on
@@ -171,7 +163,7 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
return -EINVAL;
}
- for (addr = args->va_start, end = args->va_start + size; addr < end;) {
+ for (addr = args->va_start, end = args->va_end; addr < end;) {
struct vm_area_struct *vma;
unsigned long next;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 30/35] drm/vc4: drv: Add error handding for bind
From: Hoegeun Kwon [ Upstream commit 9ce0af3e9573fb84c4c807183d13ea2a68271e4b ] There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by: Hoegeun Kwon Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.k...@samsung.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/vc4/vc4_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 38343d2fb4fb4..f6995e7f6eb6e 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -310,6 +310,7 @@ static int vc4_drm_bind(struct device *dev) component_unbind_all(dev, drm); gem_destroy: vc4_gem_destroy(drm); + drm_mode_config_cleanup(drm); vc4_bo_cache_destroy(drm); dev_put: drm_dev_put(drm); -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 13/35] drm/sun4i: frontend: Reuse the ch0 phase for RGB formats
From: Maxime Ripard [ Upstream commit 2db9ef9d9e6ea89a9feb5338f58d1f8f83875577 ] When using the scaler on the A10-like frontend with single-planar formats, the current code will setup the channel 0 filter (used for the R or Y component) with a different phase parameter than the channel 1 filter (used for the G/B or U/V components). This creates a bleed out that keeps repeating on of the last line of the RGB plane across the rest of the display. The Allwinner BSP either applies the same phase parameter over both channels or use a separate one, the condition being whether the input format is YUV420 or not. Since YUV420 is both subsampled and multi-planar, and since YUYV is subsampled but single-planar, we can rule out the subsampling and assume that the condition is actually whether the format is single or multi-planar. And it looks like applying the same phase parameter over both channels for single-planar formats fixes our issue, while we keep the multi-planar formats working properly. Reported-by: Taras Galchenko Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-2-max...@cerno.tech Signed-off-by: Sasha Levin --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c index 7462801b1fa8e..c4959d9e16391 100644 --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c @@ -407,6 +407,7 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, struct drm_framebuffer *fb = state->fb; const struct drm_format_info *format = fb->format; uint64_t modifier = fb->modifier; + unsigned int ch1_phase_idx; u32 out_fmt_val; u32 in_fmt_val, in_mod_val, in_ps_val; unsigned int i; @@ -442,18 +443,19 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, * I have no idea what this does exactly, but it seems to be * related to the scaler FIR filter phase parameters. */ + ch1_phase_idx = (format->num_planes > 1) ? 1 : 0; regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG, -frontend->data->ch_phase[1]); +frontend->data->ch_phase[ch1_phase_idx]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG, -frontend->data->ch_phase[1]); +frontend->data->ch_phase[ch1_phase_idx]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG, -frontend->data->ch_phase[1]); +frontend->data->ch_phase[ch1_phase_idx]); /* * Checking the input format is sufficient since we currently only -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 12/35] drm/sun4i: frontend: Rework a bit the phase data
From: Maxime Ripard
[ Upstream commit 84c971b356379c621df595bd00c3114579dfa59f ]
The scaler filter phase setup in the allwinner kernel has two different
cases for setting up the scaler filter, the first one using different phase
parameters for the two channels, and the second one reusing the first
channel parameters on the second channel.
The allwinner kernel has a third option where the horizontal phase of the
second channel will be set to a different value than the vertical one (and
seems like it's the same value than one used on the first channel).
However, that code path seems to never be taken, so we can ignore it for
now, and it's essentially what we're doing so far as well.
Since we will have always the same values across each components of the
filter setup for a given channel, we can simplify a bit our frontend
structure by only storing the phase value we want to apply to a given
channel.
Signed-off-by: Maxime Ripard
Acked-by: Jernej Skrabec
Link:
https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-1-max...@cerno.tech
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 34 ++
drivers/gpu/drm/sun4i/sun4i_frontend.h | 6 +
2 files changed, 9 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index ec2a032e07b97..7462801b1fa8e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -443,17 +443,17 @@ int sun4i_frontend_update_formats(struct sun4i_frontend
*frontend,
* related to the scaler FIR filter phase parameters.
*/
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG,
-frontend->data->ch_phase[0].horzphase);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG,
-frontend->data->ch_phase[1].horzphase);
+frontend->data->ch_phase[1]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG,
-frontend->data->ch_phase[0].vertphase[0]);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG,
-frontend->data->ch_phase[1].vertphase[0]);
+frontend->data->ch_phase[1]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG,
-frontend->data->ch_phase[0].vertphase[1]);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG,
-frontend->data->ch_phase[1].vertphase[1]);
+frontend->data->ch_phase[1]);
/*
* Checking the input format is sufficient since we currently only
@@ -687,30 +687,12 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
};
static const struct sun4i_frontend_data sun4i_a10_frontend = {
- .ch_phase = {
- {
- .horzphase = 0,
- .vertphase = { 0, 0 },
- },
- {
- .horzphase = 0xfc000,
- .vertphase = { 0xfc000, 0xfc000 },
- },
- },
+ .ch_phase = { 0x000, 0xfc000 },
.has_coef_rdy = true,
};
static const struct sun4i_frontend_data sun8i_a33_frontend = {
- .ch_phase = {
- {
- .horzphase = 0x400,
- .vertphase = { 0x400, 0x400 },
- },
- {
- .horzphase = 0x400,
- .vertphase = { 0x400, 0x400 },
- },
- },
+ .ch_phase = { 0x400, 0x400 },
.has_coef_access_ctrl = true,
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h
b/drivers/gpu/drm/sun4i/sun4i_frontend.h
index 0c382c1ddb0fe..2e7b76e50c2ba 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h
@@ -115,11 +115,7 @@ struct reset_control;
struct sun4i_frontend_data {
boolhas_coef_access_ctrl;
boolhas_coef_rdy;
-
- struct {
- u32 horzphase;
- u32 vertphase[2];
- } ch_phase[2];
+ u32 ch_phase[2];
};
struct sun4i_frontend {
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 07/29] hyperv_fb: Update screen_info after removing old framebuffer
From: Kairui Song
[ Upstream commit 3cb73bc3fa2a3cb80b88aa63b48409939e0d996b ]
On gen2 HyperV VM, hyperv_fb will remove the old framebuffer, and the
new allocated framebuffer address could be at a differnt location,
and it might be no longer a VGA framebuffer.
Update screen_info so that after kexec the kernel won't try to reuse
the old invalid/stale framebuffer address as VGA, corrupting memory.
[ mingo: Tidied up the changelog. ]
Signed-off-by: Kairui Song
Signed-off-by: Ingo Molnar
Cc: Dexuan Cui
Cc: Jake Oshins
Cc: Wei Hu
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Link: https://lore.kernel.org/r/20201014092429.1415040-3-kas...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/hyperv_fb.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index e4c3c8b65da44..4235ea7a6c40c 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1114,8 +1114,15 @@ static int hvfb_getmem(struct hv_device *hdev, struct
fb_info *info)
getmem_done:
remove_conflicting_framebuffers(info->apertures,
KBUILD_MODNAME, false);
- if (!gen2vm)
+
+ if (gen2vm) {
+ /* framebuffer is reallocated, clear screen_info to avoid
misuse from kexec */
+ screen_info.lfb_size = 0;
+ screen_info.lfb_base = 0;
+ screen_info.orig_video_isVGA = 0;
+ } else {
pci_dev_put(pdev);
+ }
kfree(info->apertures);
return 0;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 21/35] drm/amdgpu: disable DCN and VCN for navi10 blockchain SKU(v3)
From: "Tianci.Yin"
[ Upstream commit a305e7dc5fa86ff9cf6cd2da30215a92d43c9285 ]
The blockchain SKU has no display and video support, remove them.
Reviewed-by: Alex Deucher
Signed-off-by: Tianci.Yin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/nv.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index ca11253e787ca..8254f42146890 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -488,6 +488,14 @@ void nv_set_virt_ops(struct amdgpu_device *adev)
adev->virt.ops = &xgpu_nv_virt_ops;
}
+static bool nv_is_blockchain_sku(struct pci_dev *pdev)
+{
+ if (pdev->device == 0x731E &&
+ (pdev->revision == 0xC6 || pdev->revision == 0xC7))
+ return true;
+ return false;
+}
+
int nv_set_ip_blocks(struct amdgpu_device *adev)
{
int r;
@@ -516,7 +524,8 @@ int nv_set_ip_blocks(struct amdgpu_device *adev)
if (adev->enable_virtual_display || amdgpu_sriov_vf(adev))
amdgpu_device_ip_block_add(adev, &dce_virtual_ip_block);
#if defined(CONFIG_DRM_AMD_DC)
- else if (amdgpu_device_has_dc_support(adev))
+ else if (amdgpu_device_has_dc_support(adev) &&
+!nv_is_blockchain_sku(adev->pdev))
amdgpu_device_ip_block_add(adev, &dm_ip_block);
#endif
amdgpu_device_ip_block_add(adev, &gfx_v10_0_ip_block);
@@ -524,7 +533,8 @@ int nv_set_ip_blocks(struct amdgpu_device *adev)
if (adev->firmware.load_type == AMDGPU_FW_LOAD_DIRECT &&
!amdgpu_sriov_vf(adev))
amdgpu_device_ip_block_add(adev, &smu_v11_0_ip_block);
- amdgpu_device_ip_block_add(adev, &vcn_v2_0_ip_block);
+ if (!nv_is_blockchain_sku(adev->pdev))
+ amdgpu_device_ip_block_add(adev, &vcn_v2_0_ip_block);
amdgpu_device_ip_block_add(adev, &jpeg_v2_0_ip_block);
if (adev->enable_mes)
amdgpu_device_ip_block_add(adev, &mes_v10_1_ip_block);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 34/35] drm/nouveau/gem: fix "refcount_t: underflow; use-after-free"
From: Karol Herbst
[ Upstream commit 925681454d7b557d404b5d28ef4469fac1b2e105 ]
we can't use nouveau_bo_ref here as no ttm object was allocated and
nouveau_bo_ref mainly deals with that. Simply deallocate the object.
Signed-off-by: Karol Herbst
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 81f111ad3f4fd..124d3dcc5c590 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -198,7 +198,8 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int
align, uint32_t domain,
* to the caller, instead of a normal nouveau_bo ttm reference. */
ret = drm_gem_object_init(drm->dev, &nvbo->bo.base, size);
if (ret) {
- nouveau_bo_ref(NULL, &nvbo);
+ drm_gem_object_release(&nvbo->bo.base);
+ kfree(nvbo);
return ret;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 11/29] drm/sun4i: frontend: Rework a bit the phase data
From: Maxime Ripard
[ Upstream commit 84c971b356379c621df595bd00c3114579dfa59f ]
The scaler filter phase setup in the allwinner kernel has two different
cases for setting up the scaler filter, the first one using different phase
parameters for the two channels, and the second one reusing the first
channel parameters on the second channel.
The allwinner kernel has a third option where the horizontal phase of the
second channel will be set to a different value than the vertical one (and
seems like it's the same value than one used on the first channel).
However, that code path seems to never be taken, so we can ignore it for
now, and it's essentially what we're doing so far as well.
Since we will have always the same values across each components of the
filter setup for a given channel, we can simplify a bit our frontend
structure by only storing the phase value we want to apply to a given
channel.
Signed-off-by: Maxime Ripard
Acked-by: Jernej Skrabec
Link:
https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-1-max...@cerno.tech
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 34 ++
drivers/gpu/drm/sun4i/sun4i_frontend.h | 6 +
2 files changed, 9 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index ec2a032e07b97..7462801b1fa8e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -443,17 +443,17 @@ int sun4i_frontend_update_formats(struct sun4i_frontend
*frontend,
* related to the scaler FIR filter phase parameters.
*/
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG,
-frontend->data->ch_phase[0].horzphase);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG,
-frontend->data->ch_phase[1].horzphase);
+frontend->data->ch_phase[1]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG,
-frontend->data->ch_phase[0].vertphase[0]);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG,
-frontend->data->ch_phase[1].vertphase[0]);
+frontend->data->ch_phase[1]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG,
-frontend->data->ch_phase[0].vertphase[1]);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG,
-frontend->data->ch_phase[1].vertphase[1]);
+frontend->data->ch_phase[1]);
/*
* Checking the input format is sufficient since we currently only
@@ -687,30 +687,12 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
};
static const struct sun4i_frontend_data sun4i_a10_frontend = {
- .ch_phase = {
- {
- .horzphase = 0,
- .vertphase = { 0, 0 },
- },
- {
- .horzphase = 0xfc000,
- .vertphase = { 0xfc000, 0xfc000 },
- },
- },
+ .ch_phase = { 0x000, 0xfc000 },
.has_coef_rdy = true,
};
static const struct sun4i_frontend_data sun8i_a33_frontend = {
- .ch_phase = {
- {
- .horzphase = 0x400,
- .vertphase = { 0x400, 0x400 },
- },
- {
- .horzphase = 0x400,
- .vertphase = { 0x400, 0x400 },
- },
- },
+ .ch_phase = { 0x400, 0x400 },
.has_coef_access_ctrl = true,
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h
b/drivers/gpu/drm/sun4i/sun4i_frontend.h
index 0c382c1ddb0fe..2e7b76e50c2ba 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h
@@ -115,11 +115,7 @@ struct reset_control;
struct sun4i_frontend_data {
boolhas_coef_access_ctrl;
boolhas_coef_rdy;
-
- struct {
- u32 horzphase;
- u32 vertphase[2];
- } ch_phase[2];
+ u32 ch_phase[2];
};
struct sun4i_frontend {
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 25/35] drm/amd/display: adding ddc_gpio_vga_reg_list to ddc reg def'ns
From: Martin Leung
[ Upstream commit a1d2afc5dde29a943d32bf92eb0408c9f19541fc ]
why:
oem-related ddc read/write fails without these regs
how:
copy from hw_factory_dcn20.c
Signed-off-by: Martin Leung
Acked-by: Aurabindo Pillai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c
b/drivers/gpu/drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c
index 7e7fb65721073..9d3665f88c523 100644
--- a/drivers/gpu/drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c
+++ b/drivers/gpu/drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c
@@ -117,6 +117,12 @@ static const struct ddc_registers ddc_data_regs_dcn[] = {
ddc_data_regs_dcn2(4),
ddc_data_regs_dcn2(5),
ddc_data_regs_dcn2(6),
+ {
+ DDC_GPIO_VGA_REG_LIST(DATA),
+ .ddc_setup = 0,
+ .phy_aux_cntl = 0,
+ .dc_gpio_aux_ctrl_5 = 0
+ }
};
static const struct ddc_registers ddc_clk_regs_dcn[] = {
@@ -126,6 +132,12 @@ static const struct ddc_registers ddc_clk_regs_dcn[] = {
ddc_clk_regs_dcn2(4),
ddc_clk_regs_dcn2(5),
ddc_clk_regs_dcn2(6),
+ {
+ DDC_GPIO_VGA_REG_LIST(CLK),
+ .ddc_setup = 0,
+ .phy_aux_cntl = 0,
+ .dc_gpio_aux_ctrl_5 = 0
+ }
};
static const struct ddc_sh_mask ddc_shift[] = {
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 15/35] drm/v3d: Fix double free in v3d_submit_cl_ioctl()
From: Dan Carpenter
[ Upstream commit 897dbea6b716c0f2c5bcd4ba1eb4d809caba290c ]
Originally this error path used to leak "bin" but then we accidentally
applied two separate commits to fix it and ended up with a double free.
Signed-off-by: Dan Carpenter
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20201026094905.GA1634423@mwanda
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/v3d/v3d_gem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 915f8bfdb58ca..182c586525eb8 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -568,7 +568,6 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
ret = v3d_job_init(v3d, file_priv, &bin->base,
v3d_job_free, args->in_sync_bcl);
if (ret) {
- kfree(bin);
v3d_job_put(&render->base);
kfree(bin);
return ret;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 13/29] drm/sun4i: frontend: Fix the scaler phase on A33
From: Maxime Ripard
[ Upstream commit e3190b5e9462067714d267c40d8c8c1d0463dda3 ]
The A33 has a different phase parameter in the Allwinner BSP on the
channel1 than the one currently applied. Fix this.
Signed-off-by: Maxime Ripard
Acked-by: Jernej Skrabec
Link:
https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-3-max...@cerno.tech
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index c4959d9e16391..7186ba73d8e14 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -694,7 +694,7 @@ static const struct sun4i_frontend_data sun4i_a10_frontend
= {
};
static const struct sun4i_frontend_data sun8i_a33_frontend = {
- .ch_phase = { 0x400, 0x400 },
+ .ch_phase = { 0x400, 0xfc400 },
.has_coef_access_ctrl = true,
};
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 22/35] drm/amdgpu: add DID for navi10 blockchain SKU
From: "Tianci.Yin"
[ Upstream commit 8942881144a7365143f196f5eafed24783a424a3 ]
Reviewed-by: Alex Deucher
Reviewed-by: Guchun Chen
Signed-off-by: Tianci.Yin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 321032d3a51a2..06a5b6ae1c43e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1033,6 +1033,7 @@ static const struct pci_device_id pciidlist[] = {
{0x1002, 0x7319, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
{0x1002, 0x731A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
{0x1002, 0x731B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
+ {0x1002, 0x731E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
{0x1002, 0x731F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
/* Navi14 */
{0x1002, 0x7340, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI14},
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 14/35] drm/sun4i: frontend: Fix the scaler phase on A33
From: Maxime Ripard
[ Upstream commit e3190b5e9462067714d267c40d8c8c1d0463dda3 ]
The A33 has a different phase parameter in the Allwinner BSP on the
channel1 than the one currently applied. Fix this.
Signed-off-by: Maxime Ripard
Acked-by: Jernej Skrabec
Link:
https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-3-max...@cerno.tech
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index c4959d9e16391..7186ba73d8e14 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -694,7 +694,7 @@ static const struct sun4i_frontend_data sun4i_a10_frontend
= {
};
static const struct sun4i_frontend_data sun8i_a33_frontend = {
- .ch_phase = { 0x400, 0x400 },
+ .ch_phase = { 0x400, 0xfc400 },
.has_coef_access_ctrl = true,
};
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 07/35] hyperv_fb: Update screen_info after removing old framebuffer
From: Kairui Song
[ Upstream commit 3cb73bc3fa2a3cb80b88aa63b48409939e0d996b ]
On gen2 HyperV VM, hyperv_fb will remove the old framebuffer, and the
new allocated framebuffer address could be at a differnt location,
and it might be no longer a VGA framebuffer.
Update screen_info so that after kexec the kernel won't try to reuse
the old invalid/stale framebuffer address as VGA, corrupting memory.
[ mingo: Tidied up the changelog. ]
Signed-off-by: Kairui Song
Signed-off-by: Ingo Molnar
Cc: Dexuan Cui
Cc: Jake Oshins
Cc: Wei Hu
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Link: https://lore.kernel.org/r/20201014092429.1415040-3-kas...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/hyperv_fb.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 02411d89cb462..e36fb1a0ecdbd 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1114,8 +1114,15 @@ static int hvfb_getmem(struct hv_device *hdev, struct
fb_info *info)
getmem_done:
remove_conflicting_framebuffers(info->apertures,
KBUILD_MODNAME, false);
- if (!gen2vm)
+
+ if (gen2vm) {
+ /* framebuffer is reallocated, clear screen_info to avoid
misuse from kexec */
+ screen_info.lfb_size = 0;
+ screen_info.lfb_base = 0;
+ screen_info.orig_video_isVGA = 0;
+ } else {
pci_dev_put(pdev);
+ }
kfree(info->apertures);
return 0;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 23/35] drm/amd/display: Fixed panic during seamless boot.
From: David Galiffi
[ Upstream commit 866e09f0110c6e86071954033e3067975946592a ]
[why]
get_pixel_clk_frequency_100hz is undefined in clock_source_funcs.
[how]
set function pointer: ".get_pixel_clk_frequency_100hz =
get_pixel_clk_frequency_100hz"
Signed-off-by: David Galiffi
Reviewed-by: Bhawanpreet Lakha
Acked-by: Aurabindo Pillai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
index 9cc65dc1970f8..49ae5ff12da63 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
@@ -1149,7 +1149,8 @@ static uint32_t dcn3_get_pix_clk_dividers(
static const struct clock_source_funcs dcn3_clk_src_funcs = {
.cs_power_down = dce110_clock_source_power_down,
.program_pix_clk = dcn3_program_pix_clk,
- .get_pix_clk_dividers = dcn3_get_pix_clk_dividers
+ .get_pix_clk_dividers = dcn3_get_pix_clk_dividers,
+ .get_pixel_clk_frequency_100hz = get_pixel_clk_frequency_100hz
};
#endif
/*/
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 28/29] drm/nouveau/gem: fix "refcount_t: underflow; use-after-free"
From: Karol Herbst
[ Upstream commit 925681454d7b557d404b5d28ef4469fac1b2e105 ]
we can't use nouveau_bo_ref here as no ttm object was allocated and
nouveau_bo_ref mainly deals with that. Simply deallocate the object.
Signed-off-by: Karol Herbst
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index c5ee5b7364a09..ee5fec1ad9a46 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -197,7 +197,8 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int
align, uint32_t domain,
* to the caller, instead of a normal nouveau_bo ttm reference. */
ret = drm_gem_object_init(drm->dev, &nvbo->bo.base, size);
if (ret) {
- nouveau_bo_ref(NULL, &nvbo);
+ drm_gem_object_release(&nvbo->bo.base);
+ kfree(nvbo);
return ret;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 09/24] drm/sun4i: frontend: Reuse the ch0 phase for RGB formats
From: Maxime Ripard [ Upstream commit 2db9ef9d9e6ea89a9feb5338f58d1f8f83875577 ] When using the scaler on the A10-like frontend with single-planar formats, the current code will setup the channel 0 filter (used for the R or Y component) with a different phase parameter than the channel 1 filter (used for the G/B or U/V components). This creates a bleed out that keeps repeating on of the last line of the RGB plane across the rest of the display. The Allwinner BSP either applies the same phase parameter over both channels or use a separate one, the condition being whether the input format is YUV420 or not. Since YUV420 is both subsampled and multi-planar, and since YUYV is subsampled but single-planar, we can rule out the subsampling and assume that the condition is actually whether the format is single or multi-planar. And it looks like applying the same phase parameter over both channels for single-planar formats fixes our issue, while we keep the multi-planar formats working properly. Reported-by: Taras Galchenko Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-2-max...@cerno.tech Signed-off-by: Sasha Levin --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c index 7462801b1fa8e..c4959d9e16391 100644 --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c @@ -407,6 +407,7 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, struct drm_framebuffer *fb = state->fb; const struct drm_format_info *format = fb->format; uint64_t modifier = fb->modifier; + unsigned int ch1_phase_idx; u32 out_fmt_val; u32 in_fmt_val, in_mod_val, in_ps_val; unsigned int i; @@ -442,18 +443,19 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, * I have no idea what this does exactly, but it seems to be * related to the scaler FIR filter phase parameters. */ + ch1_phase_idx = (format->num_planes > 1) ? 1 : 0; regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG, -frontend->data->ch_phase[1]); +frontend->data->ch_phase[ch1_phase_idx]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG, -frontend->data->ch_phase[1]); +frontend->data->ch_phase[ch1_phase_idx]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG, -frontend->data->ch_phase[1]); +frontend->data->ch_phase[ch1_phase_idx]); /* * Checking the input format is sufficient since we currently only -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 23/24] drm/nouveau/gem: fix "refcount_t: underflow; use-after-free"
From: Karol Herbst
[ Upstream commit 925681454d7b557d404b5d28ef4469fac1b2e105 ]
we can't use nouveau_bo_ref here as no ttm object was allocated and
nouveau_bo_ref mainly deals with that. Simply deallocate the object.
Signed-off-by: Karol Herbst
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 7d39d4949ee77..2dd9fcab464b1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -197,7 +197,8 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int
align, uint32_t domain,
* to the caller, instead of a normal nouveau_bo ttm reference. */
ret = drm_gem_object_init(drm->dev, &nvbo->bo.base, size);
if (ret) {
- nouveau_bo_ref(NULL, &nvbo);
+ drm_gem_object_release(&nvbo->bo.base);
+ kfree(nvbo);
return ret;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 24/29] drm/vc4: drv: Add error handding for bind
From: Hoegeun Kwon [ Upstream commit 9ce0af3e9573fb84c4c807183d13ea2a68271e4b ] There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by: Hoegeun Kwon Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.k...@samsung.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/vc4/vc4_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 76f93b6627660..1dac8e28c7346 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -306,6 +306,7 @@ static int vc4_drm_bind(struct device *dev) component_unbind_all(dev, drm); gem_destroy: vc4_gem_destroy(drm); + drm_mode_config_cleanup(drm); vc4_bo_cache_destroy(drm); dev_put: drm_dev_put(drm); -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 27/29] drm/nouveau/nouveau: fix the start/end range for migration
From: Ralph Campbell
[ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ]
The user level OpenCL code shouldn't have to align start and end
addresses to a page boundary. That is better handled in the nouveau
driver. The npages field is also redundant since it can be computed
from the start and end addresses.
Signed-off-by: Ralph Campbell
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 6586d9d398740..11b7cc3625cf8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -116,11 +116,11 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
struct nouveau_cli *cli = nouveau_cli(file_priv);
struct drm_nouveau_svm_bind *args = data;
unsigned target, cmd, priority;
- unsigned long addr, end, size;
+ unsigned long addr, end;
struct mm_struct *mm;
args->va_start &= PAGE_MASK;
- args->va_end &= PAGE_MASK;
+ args->va_end = ALIGN(args->va_end, PAGE_SIZE);
/* Sanity check arguments */
if (args->reserved0 || args->reserved1)
@@ -129,8 +129,6 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
return -EINVAL;
if (args->va_start >= args->va_end)
return -EINVAL;
- if (!args->npages)
- return -EINVAL;
cmd = args->header >> NOUVEAU_SVM_BIND_COMMAND_SHIFT;
cmd &= NOUVEAU_SVM_BIND_COMMAND_MASK;
@@ -162,12 +160,6 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
if (args->stride)
return -EINVAL;
- size = ((unsigned long)args->npages) << PAGE_SHIFT;
- if ((args->va_start + size) <= args->va_start)
- return -EINVAL;
- if ((args->va_start + size) > args->va_end)
- return -EINVAL;
-
/*
* Ok we are ask to do something sane, for now we only support migrate
* commands but we will add things like memory policy (what to do on
@@ -182,7 +174,7 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
return -EINVAL;
}
- for (addr = args->va_start, end = args->va_start + size; addr < end;) {
+ for (addr = args->va_start, end = args->va_end; addr < end;) {
struct vm_area_struct *vma;
unsigned long next;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 08/24] drm/sun4i: frontend: Rework a bit the phase data
From: Maxime Ripard
[ Upstream commit 84c971b356379c621df595bd00c3114579dfa59f ]
The scaler filter phase setup in the allwinner kernel has two different
cases for setting up the scaler filter, the first one using different phase
parameters for the two channels, and the second one reusing the first
channel parameters on the second channel.
The allwinner kernel has a third option where the horizontal phase of the
second channel will be set to a different value than the vertical one (and
seems like it's the same value than one used on the first channel).
However, that code path seems to never be taken, so we can ignore it for
now, and it's essentially what we're doing so far as well.
Since we will have always the same values across each components of the
filter setup for a given channel, we can simplify a bit our frontend
structure by only storing the phase value we want to apply to a given
channel.
Signed-off-by: Maxime Ripard
Acked-by: Jernej Skrabec
Link:
https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-1-max...@cerno.tech
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 34 ++
drivers/gpu/drm/sun4i/sun4i_frontend.h | 6 +
2 files changed, 9 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index ec2a032e07b97..7462801b1fa8e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -443,17 +443,17 @@ int sun4i_frontend_update_formats(struct sun4i_frontend
*frontend,
* related to the scaler FIR filter phase parameters.
*/
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG,
-frontend->data->ch_phase[0].horzphase);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG,
-frontend->data->ch_phase[1].horzphase);
+frontend->data->ch_phase[1]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG,
-frontend->data->ch_phase[0].vertphase[0]);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG,
-frontend->data->ch_phase[1].vertphase[0]);
+frontend->data->ch_phase[1]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG,
-frontend->data->ch_phase[0].vertphase[1]);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG,
-frontend->data->ch_phase[1].vertphase[1]);
+frontend->data->ch_phase[1]);
/*
* Checking the input format is sufficient since we currently only
@@ -687,30 +687,12 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
};
static const struct sun4i_frontend_data sun4i_a10_frontend = {
- .ch_phase = {
- {
- .horzphase = 0,
- .vertphase = { 0, 0 },
- },
- {
- .horzphase = 0xfc000,
- .vertphase = { 0xfc000, 0xfc000 },
- },
- },
+ .ch_phase = { 0x000, 0xfc000 },
.has_coef_rdy = true,
};
static const struct sun4i_frontend_data sun8i_a33_frontend = {
- .ch_phase = {
- {
- .horzphase = 0x400,
- .vertphase = { 0x400, 0x400 },
- },
- {
- .horzphase = 0x400,
- .vertphase = { 0x400, 0x400 },
- },
- },
+ .ch_phase = { 0x400, 0x400 },
.has_coef_access_ctrl = true,
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h
b/drivers/gpu/drm/sun4i/sun4i_frontend.h
index 0c382c1ddb0fe..2e7b76e50c2ba 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h
@@ -115,11 +115,7 @@ struct reset_control;
struct sun4i_frontend_data {
boolhas_coef_access_ctrl;
boolhas_coef_rdy;
-
- struct {
- u32 horzphase;
- u32 vertphase[2];
- } ch_phase[2];
+ u32 ch_phase[2];
};
struct sun4i_frontend {
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 12/29] drm/sun4i: frontend: Reuse the ch0 phase for RGB formats
From: Maxime Ripard [ Upstream commit 2db9ef9d9e6ea89a9feb5338f58d1f8f83875577 ] When using the scaler on the A10-like frontend with single-planar formats, the current code will setup the channel 0 filter (used for the R or Y component) with a different phase parameter than the channel 1 filter (used for the G/B or U/V components). This creates a bleed out that keeps repeating on of the last line of the RGB plane across the rest of the display. The Allwinner BSP either applies the same phase parameter over both channels or use a separate one, the condition being whether the input format is YUV420 or not. Since YUV420 is both subsampled and multi-planar, and since YUYV is subsampled but single-planar, we can rule out the subsampling and assume that the condition is actually whether the format is single or multi-planar. And it looks like applying the same phase parameter over both channels for single-planar formats fixes our issue, while we keep the multi-planar formats working properly. Reported-by: Taras Galchenko Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-2-max...@cerno.tech Signed-off-by: Sasha Levin --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c index 7462801b1fa8e..c4959d9e16391 100644 --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c @@ -407,6 +407,7 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, struct drm_framebuffer *fb = state->fb; const struct drm_format_info *format = fb->format; uint64_t modifier = fb->modifier; + unsigned int ch1_phase_idx; u32 out_fmt_val; u32 in_fmt_val, in_mod_val, in_ps_val; unsigned int i; @@ -442,18 +443,19 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, * I have no idea what this does exactly, but it seems to be * related to the scaler FIR filter phase parameters. */ + ch1_phase_idx = (format->num_planes > 1) ? 1 : 0; regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG, -frontend->data->ch_phase[1]); +frontend->data->ch_phase[ch1_phase_idx]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG, -frontend->data->ch_phase[1]); +frontend->data->ch_phase[ch1_phase_idx]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG, -frontend->data->ch_phase[1]); +frontend->data->ch_phase[ch1_phase_idx]); /* * Checking the input format is sufficient since we currently only -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 22/24] drm/nouveau/nouveau: fix the start/end range for migration
From: Ralph Campbell
[ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ]
The user level OpenCL code shouldn't have to align start and end
addresses to a page boundary. That is better handled in the nouveau
driver. The npages field is also redundant since it can be computed
from the start and end addresses.
Signed-off-by: Ralph Campbell
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 824654742a604..0be4668c780bf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -112,11 +112,11 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
struct nouveau_cli *cli = nouveau_cli(file_priv);
struct drm_nouveau_svm_bind *args = data;
unsigned target, cmd, priority;
- unsigned long addr, end, size;
+ unsigned long addr, end;
struct mm_struct *mm;
args->va_start &= PAGE_MASK;
- args->va_end &= PAGE_MASK;
+ args->va_end = ALIGN(args->va_end, PAGE_SIZE);
/* Sanity check arguments */
if (args->reserved0 || args->reserved1)
@@ -125,8 +125,6 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
return -EINVAL;
if (args->va_start >= args->va_end)
return -EINVAL;
- if (!args->npages)
- return -EINVAL;
cmd = args->header >> NOUVEAU_SVM_BIND_COMMAND_SHIFT;
cmd &= NOUVEAU_SVM_BIND_COMMAND_MASK;
@@ -158,12 +156,6 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
if (args->stride)
return -EINVAL;
- size = ((unsigned long)args->npages) << PAGE_SHIFT;
- if ((args->va_start + size) <= args->va_start)
- return -EINVAL;
- if ((args->va_start + size) > args->va_end)
- return -EINVAL;
-
/*
* Ok we are ask to do something sane, for now we only support migrate
* commands but we will add things like memory policy (what to do on
@@ -178,7 +170,7 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
return -EINVAL;
}
- for (addr = args->va_start, end = args->va_start + size; addr < end;) {
+ for (addr = args->va_start, end = args->va_end; addr < end;) {
struct vm_area_struct *vma;
unsigned long next;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 14/24] drm/amdgpu: add DID for navi10 blockchain SKU
From: "Tianci.Yin"
[ Upstream commit 8942881144a7365143f196f5eafed24783a424a3 ]
Reviewed-by: Alex Deucher
Reviewed-by: Guchun Chen
Signed-off-by: Tianci.Yin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index fa2c0f29ad4de..e8e1720104160 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1011,6 +1011,7 @@ static const struct pci_device_id pciidlist[] = {
{0x1002, 0x7319, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
{0x1002, 0x731A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
{0x1002, 0x731B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
+ {0x1002, 0x731E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
{0x1002, 0x731F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
/* Navi14 */
{0x1002, 0x7340, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI14},
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 10/24] drm/sun4i: frontend: Fix the scaler phase on A33
From: Maxime Ripard
[ Upstream commit e3190b5e9462067714d267c40d8c8c1d0463dda3 ]
The A33 has a different phase parameter in the Allwinner BSP on the
channel1 than the one currently applied. Fix this.
Signed-off-by: Maxime Ripard
Acked-by: Jernej Skrabec
Link:
https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-3-max...@cerno.tech
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index c4959d9e16391..7186ba73d8e14 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -694,7 +694,7 @@ static const struct sun4i_frontend_data sun4i_a10_frontend
= {
};
static const struct sun4i_frontend_data sun8i_a33_frontend = {
- .ch_phase = { 0x400, 0x400 },
+ .ch_phase = { 0x400, 0xfc400 },
.has_coef_access_ctrl = true,
};
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 19/29] drm/amdgpu: add DID for navi10 blockchain SKU
From: "Tianci.Yin"
[ Upstream commit 8942881144a7365143f196f5eafed24783a424a3 ]
Reviewed-by: Alex Deucher
Reviewed-by: Guchun Chen
Signed-off-by: Tianci.Yin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index d73924e35a57e..92844ba2c9c4e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1016,6 +1016,7 @@ static const struct pci_device_id pciidlist[] = {
{0x1002, 0x7319, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
{0x1002, 0x731A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
{0x1002, 0x731B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
+ {0x1002, 0x731E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
{0x1002, 0x731F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10},
/* Navi14 */
{0x1002, 0x7340, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI14},
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 19/24] drm/vc4: drv: Add error handding for bind
From: Hoegeun Kwon [ Upstream commit 9ce0af3e9573fb84c4c807183d13ea2a68271e4b ] There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by: Hoegeun Kwon Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.k...@samsung.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/vc4/vc4_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 5e6fb6c2307f0..0d78ba017a29b 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -309,6 +309,7 @@ static int vc4_drm_bind(struct device *dev) component_unbind_all(dev, drm); gem_destroy: vc4_gem_destroy(drm); + drm_mode_config_cleanup(drm); vc4_bo_cache_destroy(drm); dev_put: drm_dev_put(drm); -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 14/29] drm/v3d: Fix double free in v3d_submit_cl_ioctl()
From: Dan Carpenter
[ Upstream commit 897dbea6b716c0f2c5bcd4ba1eb4d809caba290c ]
Originally this error path used to leak "bin" but then we accidentally
applied two separate commits to fix it and ended up with a double free.
Signed-off-by: Dan Carpenter
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20201026094905.GA1634423@mwanda
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/v3d/v3d_gem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 09a7639cf161f..0e0f1cc3e283a 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -568,7 +568,6 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
ret = v3d_job_init(v3d, file_priv, &bin->base,
v3d_job_free, args->in_sync_bcl);
if (ret) {
- kfree(bin);
v3d_job_put(&render->base);
kfree(bin);
return ret;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 10/11] drm/vc4: drv: Add error handding for bind
From: Hoegeun Kwon [ Upstream commit 9ce0af3e9573fb84c4c807183d13ea2a68271e4b ] There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by: Hoegeun Kwon Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.k...@samsung.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/vc4/vc4_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 04270a14fcaaf..868dd1ef3b693 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -312,6 +312,7 @@ static int vc4_drm_bind(struct device *dev) component_unbind_all(dev, drm); gem_destroy: vc4_gem_destroy(drm); + drm_mode_config_cleanup(drm); vc4_bo_cache_destroy(drm); dev_put: drm_dev_put(drm); -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 09/10] drm/vc4: drv: Add error handding for bind
From: Hoegeun Kwon [ Upstream commit 9ce0af3e9573fb84c4c807183d13ea2a68271e4b ] There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by: Hoegeun Kwon Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.k...@samsung.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/vc4/vc4_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 1c96edcb302be..028dc2819a368 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -283,6 +283,7 @@ static int vc4_drm_bind(struct device *dev) component_unbind_all(dev, drm); gem_destroy: vc4_gem_destroy(drm); + drm_mode_config_cleanup(drm); vc4_bo_cache_destroy(drm); dev_unref: drm_dev_unref(drm); -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/6] dt-bindings: display: Add support for Intel KeemBay Display
On Mon, Nov 2, 2020 at 10:38 AM Neil Armstrong wrote:
>
> On 02/11/2020 16:16, Rob Herring wrote:
> > On Fri, Oct 30, 2020 at 4:15 PM Sam Ravnborg wrote:
> >>
> >> Hi Neil.
> >>
> >> On Fri, Oct 30, 2020 at 09:31:36AM +0100, Neil Armstrong wrote:
> >>> Hi,
> >>>
> >>> On 29/10/2020 23:20, Sam Ravnborg wrote:
> Hi Anitha.
>
> On Thu, Oct 29, 2020 at 02:27:52PM -0700, Anitha Chrisanthus wrote:
> > This patch adds bindings for Intel KeemBay Display
> >
> > v2: review changes from Rob Herring
> > v3: review changes from Sam Ravnborg (removed mipi dsi entries, and
> > encoder entry, connect port to dsi)
> > MSSCAM is part of the display submodule and its used to reset LCD
> > and MIPI DSI clocks, so its best to be on this device tree.
> >
> > Signed-off-by: Anitha Chrisanthus
> > Cc: Sam Ravnborg
> > Cc: Thomas Zimmermann
> > Cc: Daniel Vetter
>
> Looks good - and the split betwwen the display and the mipi<->dsi parts
> matches the understanding of the HW I have developed.
>
> Reviewed-by: Sam Ravnborg
>
> > ---
> > .../bindings/display/intel,keembay-display.yaml| 75
> > ++
> > 1 file changed, 75 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> > b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> > new file mode 100644
> > index 000..8a8effe
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> > @@ -0,0 +1,75 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/intel,keembay-display.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Devicetree bindings for Intel Keem Bay display controller
> > +
> > +maintainers:
> > + - Anitha Chrisanthus
> > + - Edmond J Dea
> > +
> > +properties:
> > + compatible:
> > +const: intel,keembay-display
> > +
> > + reg:
> > +items:
> > + - description: LCD registers range
> > + - description: Msscam registers range
> > +
> >>>
> >>> Indeed the split is much better, but as you replied on
> >>> http://lore.kernel.org/r/by5pr11mb41827de07436dd0454e24e6e8c...@by5pr11mb4182.namprd11.prod.outlook.com
> >>> the msscam seems to be shared with the camera subsystem block, if this is
> >>> the case it should be handled.
> >>>
> >>> If it's a shared register block, it could be defined as a "syscon" used
> >>> by both subsystems.
> >>
> >> I think I got it now.
> >>
> >> msscam is used to enable clocks both for the display driver and the
> >> mipi-dsi part.
> >
> > If just clocks, then the msscam should be a clock provider possibly.
> > If not, then the below looks right.
>
> I agree
>
> >
> >>
> >> So it should be pulled in to a dedicated node - for example like this:
> >>
> >> mssscam: msscam@2091 {
> >> compatible = "intel,keembay-msscam", "syscon";
> >> reg = <0x2091, 0x30>;
> >> reg-io-width = <4>;
> >> };
> >>
> >> And ofc we need a binding file for that.
> >>
> >>
> >> And then we could have code like this in the display driver:
> >> regmap *msscam =
> >> syscon_regmap_lookup_by_compatible("intel,keembay-msscam");
> >> if (IS_ERR(msscam))
> >> tell-and goto-out;
>
> It's better to use a phandle in the display node, instead of looking for
> compatible nodes.
No, you don't need it in DT unless there's more than one instance or
other parameters needed like register offsets/masks. The above is
actually faster too walking a list rather than a phandle look up
(though the phandle cache now may make it faster).
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/6] dt-bindings: display: Add support for Intel KeemBay Display
On Mon, Nov 2, 2020 at 12:04 PM Sam Ravnborg wrote: > > Hi Neil. > > > > --- > > > .../bindings/display/intel,keembay-display.yaml| 75 > > > ++ > > > 1 file changed, 75 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/display/intel,keembay-display.yaml > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml > > > > > > b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml > > > new file mode 100644 > > > index 000..8a8effe > > > --- /dev/null > > > +++ > > > b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml > > > @@ -0,0 +1,75 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: > > > http://devicetree.org/schemas/display/intel,keembay-display.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Devicetree bindings for Intel Keem Bay display controller > > > + > > > +maintainers: > > > + - Anitha Chrisanthus > > > + - Edmond J Dea > > > + > > > +properties: > > > + compatible: > > > +const: intel,keembay-display > > > + > > > + reg: > > > +items: > > > + - description: LCD registers range > > > + - description: Msscam registers range > > > + > > >>> > > >>> Indeed the split is much better, but as you replied on > > >>> http://lore.kernel.org/r/by5pr11mb41827de07436dd0454e24e6e8c...@by5pr11mb4182.namprd11.prod.outlook.com > > >>> the msscam seems to be shared with the camera subsystem block, if this > > >>> is the case it should be handled. > > >>> > > >>> If it's a shared register block, it could be defined as a "syscon" used > > >>> by both subsystems. > > >> > > >> I think I got it now. > > >> > > >> msscam is used to enable clocks both for the display driver and the > > >> mipi-dsi part. > > > > > > If just clocks, then the msscam should be a clock provider possibly. > > > If not, then the below looks right. > > I am feeling a little clueless here - sorry. > > Can you help with any example that does this? I'm pretty sure there's some DSI PHYs where they are also a clock provider. > Everything I looked up in bindings/clock/ had a "#clock-cells" which is > not relevant for msscam - or so I think at least. That is precisely what needs to be added to msscam and then there would be another 'clocks' entry here. But it really depends if the register accesses here map to the controls the clock API provides. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 49/52] PM / devfreq: tegra20: Convert to EMC_STAT driver, support interconnect and device-tree
On 11/3/20 5:08 AM, Dmitry Osipenko wrote: > 01.11.2020 17:12, Dmitry Osipenko пишет: > ... >> We will probably move the Tegra20 EMC_STAT devfreq driver into the >> memory driver and remove the older IMC_STAT driver in v7, like it was >> suggested by Thierry Reding. This will be a much less invasive code change. >> >>> Also, if you want to get more responsiveness, you could use delayed timer >>> instead of deferrable timer by editing the devfreq_dev_profile structure. >> >> Thanks, I'll try the deferrable timer. > > I took a brief look at the delayed timer and I think the deferrable > timer should be more a preferred option because this devfreq drive is > more an assistance for the optimal bandwidth selection and it will be > more preferred to keep system idling whenever possible. > > My primary concern is the initial performance lag in a case of > multimedia applications. But this will be resolved by hooking up > performance voting to all drivers, once we will get around to it. OK. You can choice the type of timer on both probe and via sysfs file on the runtime. -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-misc tree with the amdgpu tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
between commit:
e8a982355f96 ("drm/amd/display: Add tracepoint for amdgpu_dm")
from the amdgpu tree and commit:
29b77ad7b9ca ("drm/atomic: Pass the full state to CRTC atomic_check")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 28dcaae06993,86fd4420f128..
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@@ -6003,19 -5514,19 +6003,21 @@@ static void dm_update_crtc_active_plane
}
static int dm_crtc_helper_atomic_check(struct drm_crtc *crtc,
- struct drm_crtc_state *state)
+ struct drm_atomic_state *state)
{
+ struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
+ crtc);
struct amdgpu_device *adev = drm_to_adev(crtc->dev);
struct dc *dc = adev->dm.dc;
- struct dm_crtc_state *dm_crtc_state = to_dm_crtc_state(state);
+ struct dm_crtc_state *dm_crtc_state = to_dm_crtc_state(crtc_state);
int ret = -EINVAL;
- trace_amdgpu_dm_crtc_atomic_check(state);
++ trace_amdgpu_dm_crtc_atomic_check(crtc_state);
+
- dm_update_crtc_active_planes(crtc, state);
+ dm_update_crtc_active_planes(crtc, crtc_state);
if (unlikely(!dm_crtc_state->stream &&
-modeset_required(state, NULL, dm_crtc_state->stream))) {
+modeset_required(crtc_state, NULL,
dm_crtc_state->stream))) {
WARN_ON(1);
return ret;
}
pgpRygMka49LX.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: Fix static checker warning
Here is the warning message:
drivers/dma-buf/dma-buf.c:917 dma_buf_map_attachment()
error: 'sg_table' dereferencing possible ERR_PTR()
Fix by adding error checking before dereferencing the pointer.
Fixes: ac80cd17a615 ("dma-buf: Clarify that dma-buf sg lists are page aligned")
Reported-by: Dan Carpenter
Signed-off-by: Jianxin Xiong
---
drivers/dma-buf/dma-buf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 556f62e..0eb80c1 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -908,7 +908,7 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
}
#ifdef CONFIG_DMA_API_DEBUG
- {
+ if (!IS_ERR(sg_table)) {
struct scatterlist *sg;
u64 addr;
int len;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/8] slab: provide and use krealloc_array()
On Mon, 2020-11-02 at 16:20 +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Andy brought to my attention the fact that users allocating an array of > equally sized elements should check if the size multiplication doesn't > overflow. This is why we have helpers like kmalloc_array(). > > However we don't have krealloc_array() equivalent and there are many > users who do their own multiplication when calling krealloc() for arrays. > > This series provides krealloc_array() and uses it in a couple places. My concern about this is a possible assumption that __GFP_ZERO will work, and as far as I know, it will not. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] drm/bridge: ti-sn65dsi86: Support EDID reading
Hi, Thanks Doug for adding me On 02-11-20, 08:37, Doug Anderson wrote: > > On Thu, Oct 29, 2020 at 06:17:34PM -0700, Stephen Boyd wrote: > > Any chance we can convince you to prepare this bridge driver for use in > > a chained bridge setup where the connector is created by the display > > driver and uses drm_bridge_funcs? > > > > First step wuld be to introduce the use of a panel_bridge. > > Then add get_edid to drm_bridge_funcs and maybe more helpers. > > > > Then natural final step would be to move connector creation to the > > display driver - see how other uses drm_bridge_connector_init() to do so > > - it is relatively simple. > > > > Should be doable - and reach out if you need some help. Yes it is and doable and you find this at [1], would need a rebase though. > At some point I think Vinod tried to prepare a patch for this and I > tried it, but it didn't just work. I spent an hour or so poking at it > and I couldn't quite figure out why and I couldn't find enough other > examples to compare against to see what was wrong... That was a few > months ago, though. Maybe things are in a better shape now? It worked fine for me on Rb3 and db410c where we had HDMI connector. I don't have a panel device to test and Bjorn tried to help out with a bit of testing. This didn't work on the laptop, that is why I haven't posted it yet. This has conversion of msm driver and bridge drivers lt9611, adv7511 and ti-sn65dsi86. [1]: https://git.linaro.org/people/vinod.koul/kernel.git/log/?h=wip/msm_bridges_no_conn Thanks -- ~Vinod ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [resource] 22b17dc667: Kernel panic - not syncing: Fatal exception
On 11/2/20 10:06 PM, lkp wrote:
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: 22b17dc667d36418ccabb9c668c4b489185fb40a ("[PATCH v5 13/15] resource: Move
devmem revoke code to resource framework")
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/follow_pfn-and-other-iomap-races/20201030-181112
base: git://linuxtv.org/media_tree.git master
in testcase: fsmark
version: fsmark-x86_64-3.3-1_20201007
with following parameters:
iterations: 1x
nr_threads: 1t
disk: 1BRD_48G
fs: f2fs
fs2: nfsv4
filesize: 4M
test_size: 40G
sync_method: NoSync
cpufreq_governor: performance
ucode: 0x5002f01
test-description: The fsmark is a file system benchmark to test synchronous
write workloads, for example, mail servers workload.
test-url: https://sourceforge.net/projects/fsmark/
on test machine: 192 threads Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz with
192G memory
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
Yep, this is the same crash that I saw. And the .config also has
# CONFIG_IO_STRICT_DEVMEM is not set
so it all makes sense.
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
[ 28.644165] systemd[1]: RTC configured in localtime, applying delta of 0
minutes to system time.
[ 28.699473] #PF: supervisor read access in kernel mode
[ 28.704611] #PF: error_code(0x) - not-present page
[ 28.709749] PGD 0 P4D 0
[ 28.712291] Oops: [#1] SMP NOPTI
[ 28.715956] CPU: 0 PID: 1 Comm: systemd Not tainted
5.10.0-rc1-00015-g22b17dc667d3 #1
[ 28.723793] RIP: 0010:do_dentry_open+0x1c9/0x360
[ 28.728410] Code: 84 82 01 00 00 81 ca 00 00 04 00 89 53 44 48 8b 83 f0 00 00 00
81 63 40 3f fc ff ff 48 8d bb 98 00 00 00 c7 43 34 00 00 00 00 <48> 8b 00 48 8b
70 30 e8 2b cb f4 ff f6 43 41 40 74 5a 48 8b 83 f0
[ 28.747157] RSP: 0018:c906fcc8 EFLAGS: 00010206
[ 28.752380] RAX: RBX: 8881502ad400 RCX:
[ 28.759506] RDX: 000a201d RSI: 8284d260 RDI: 8881502ad498
[ 28.766639] RBP: 88a485a06490 R08: R09: 8284d260
[ 28.773769] R10: c906fcc8 R11: 756c6176006d656d R12:
[ 28.780895] R13: 8133ddc0 R14: 8881502ad410 R15: 8881502ad400
[ 28.788028] FS: 7ff54afa1940() GS:888c4f60()
knlGS:
[ 28.796113] CS: 0010 DS: ES: CR0: 80050033
[ 28.801858] CR2: CR3: 000100120003 CR4: 007706f0
[ 28.808983] DR0: DR1: DR2:
[ 28.816114] DR3: DR6: fffe0ff0 DR7: 0400
[ 28.823239] PKRU: 5554
[ 28.825952] Call Trace:
[ 28.828412] path_openat+0xaa8/0x10a0
[ 28.832073] do_filp_open+0x91/0x100
[ 28.835653] ? acpi_os_wait_semaphore+0x48/0x80
[ 28.840186] ? __check_object_size+0x136/0x160
[ 28.844631] do_sys_openat2+0x20d/0x2e0
[ 28.848470] do_sys_open+0x44/0x80
[ 28.851878] do_syscall_64+0x33/0x40
[ 28.855457] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 28.860509] RIP: 0033:0x7ff54c1521ae
[ 28.864086] Code: 25 00 00 41 00 3d 00 00 41 00 74 48 48 8d 05 59 65 0d 00 8b 00
85 c0 75 69 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff
ff 0f 87 a6 00 00 00 48 8b 4c 24 28 64 48 33 0c 25
[ 28.882833] RSP: 002b:7ffd1c9586d0 EFLAGS: 0246 ORIG_RAX:
0101
[ 28.890399] RAX: ffda RBX: 7ffd1c9587d0 RCX: 7ff54c1521ae
[ 28.897531] RDX: 0008 RSI: 7ff54bfa0e5a RDI: ff9c
[ 28.904662] RBP: 7ffd1c9587d8 R08: 021f R09: 55f837cf4290
[ 28.911796] R10: R11: 0246 R12: 56dd9000
[ 28.918927] R13: R14: 7ffd1c9587d0 R15: 0002
[ 28.926060] Modules linked in: ip_tables
[ 28.929986] CR2:
mDebian GNU/Linu
[ 28.933416] ---[ end trace 94e4f9aa3df66098 ]---
[ 28.939355] RIP: 0010:do_dentry_open+0x1c9/0x360
[ 28.943975] Code: 84 82 01 00 00 81 ca 00 00 04 00 89 53 44 48 8b 83 f0 00 00 00
81 63 40 3f fc ff ff 48 8d bb 98 00 00 00 c7 43 34 00 00 00 00 <48> 8b 00 48 8b
70 30 e8 2b cb f4 ff f6 43 41 40 74 5a 48 8b 83 f0
[ 28.962721] RSP: 0018:c906fcc8 EFLAGS: 00010206
[ 28.967948] RAX: RBX: 8881502ad400 RCX:
[ 28.975079] RDX: 000a201d RSI: 8284d260 RDI: 8881502ad498
[ 28.982211] RBP: 88a485a06490 R08: R09: 8284d260
[ 28.989337] R10: c906fcc8 R11: 756c6176006d656d R12:
[ 28.996467] R13: 8133ddc0 R14: 8881502ad410 R15: 8881502ad400
[ 29.003592] FS: 7ff54afa1940() GS:888c4f60()
knlGS:
[ 29.011668] CS: 0010 DS: ES: CR0: 00
Re: [bug report] dma-buf: Clarify that dma-buf sg lists are page aligned
On Mon, Nov 02, 2020 at 09:33:08PM +, Xiong, Jianxin wrote:
> Hi Dan,
>
> Thanks for reporting the bug. I see what was missing. Am I supposed to submit
> a patch to
> replace the original patch or just to fix this bug?
>
Once the patch has been applied, then it's too late to replace it. Just
send a patch to fix it.
regards,
dan carpenter
> Jianxin
>
> > -Original Message-
> > From: Dan Carpenter
> > Sent: Monday, November 02, 2020 12:15 AM
> > To: Xiong, Jianxin
> > Cc: dri-devel@lists.freedesktop.org
> > Subject: [bug report] dma-buf: Clarify that dma-buf sg lists are page
> > aligned
> >
> > Hello Jianxin Xiong,
> >
> > The patch ac80cd17a615: "dma-buf: Clarify that dma-buf sg lists are page
> > aligned" from Oct 14, 2020, leads to the following static checker
> > warning:
> >
> > drivers/dma-buf/dma-buf.c:917 dma_buf_map_attachment()
> > error: 'sg_table' dereferencing possible ERR_PTR()
> >
> > drivers/dma-buf/dma-buf.c
> >897 sg_table = attach->dmabuf->ops->map_dma_buf(attach,
> > direction);
> >898 if (!sg_table)
> >899 sg_table = ERR_PTR(-ENOMEM);
> >900
> >901 if (IS_ERR(sg_table) && dma_buf_is_dynamic(attach->dmabuf)
> > &&
> >902 !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
> >903 dma_buf_unpin(attach);
> >904
> >905 if (!IS_ERR(sg_table) &&
> > attach->dmabuf->ops->cache_sgt_mapping) {
> > ^
> >
> >906 attach->sgt = sg_table;
> >907 attach->dir = direction;
> >908 }
> >909
> >910 #ifdef CONFIG_DMA_API_DEBUG
> >911 {
> >912 struct scatterlist *sg;
> >913 u64 addr;
> >914 int len;
> >915 int i;
> >916
> >917 for_each_sgtable_dma_sg(sg_table, sg, i) {
> > ^ Not checked here.
> >
> >918 addr = sg_dma_address(sg);
> >919 len = sg_dma_len(sg);
> >920 if (!PAGE_ALIGNED(addr) ||
> > !PAGE_ALIGNED(len)) {
> >921 pr_debug("%s: addr %llx or len %x
> > is not page aligned!\n",
> >922 __func__, addr, len);
> >923 }
> >924 }
> >925 }
> >926 #endif /* CONFIG_DMA_API_DEBUG */
> >
> > regards,
> > dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote: > Am 02.11.20 um 20:43 schrieb Alex Deucher: > > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma wrote: > > > Initializing global variable to 0 or NULL is not necessary and should > > > be avoided. Issue reported by checkpatch script as: > > > ERROR: do not initialise globals to 0 (or NULL). > > I agree that this is technically correct, but a lot of people don't > > seem to know that so we get a lot of comments about this code for the > > variables that are not explicitly set. Seems less confusing to > > initialize them even if it not necessary. I don't have a particularly > > strong opinion on it however. > > Agree with Alex. > > Especially for the module parameters we should have a explicit init value > for documentation purposes, even when it is 0. Why is this one tiny driver somehow special compared to the entire rest of the kernel? (hint, it isn't...) Please follow the normal coding style rules, there's no reason to ignore them unless you like to constantly reject patches like this that get sent to you. thnaks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/6] Exynos: Simple QoS for exynos-bus using interconnect
Hi Sylwester,
When I tested this patchset on Odroid-U3,
After setting 0 bps by interconnect[1][2],
the frequency of devfreq devs sustain the high frequency
according to the pm qos request.
So, I try to find the cause of this situation.
In result, it seems that interconnect exynos driver
updates the pm qos request to devfreq device
during the kernel booting. Do you know why the exynos
interconnect driver request the pm qos during probe
without the mixer request?
PS. The passive governor has a bug related to PM_QOS interface.
So, I posted the patch[4].
[1] interconnect_graph
root@localhost:~# cat /sys/kernel/debug/interconnect/interconnect_graph
digraph {
rankdir = LR
node [shape = record]
subgraph cluster_1 {
label = "soc:bus_dmc"
"2:bus_dmc" [label="2:bus_dmc
|avg_bw=0kBps
|peak_bw=0kBps"]
}
subgraph cluster_2 {
label = "soc:bus_leftbus"
"3:bus_leftbus" [label="3:bus_leftbus
|avg_bw=0kBps
|peak_bw=0kBps"]
}
subgraph cluster_3 {
label = "soc:bus_display"
"4:bus_display" [label="4:bus_display
|avg_bw=0kBps
|peak_bw=0kBps"]
}
"3:bus_leftbus" -> "2:bus_dmc"
"4:bus_display" -> "3:bus_leftbus"
[2] interconnect_summary
root@localhost:~# cat /sys/kernel/debug/interconnect/interconnect_summary
node tag avg peak
bus_dmc 00
12c1.mixer 000
bus_leftbus 00
12c1.mixer 000
bus_display 00
12c1.mixer 000
[3] devfreq_summary
root@localhost:~# cat /sys/kernel/debug/devfreq/devfreq_summary
devparent_dev governor
timer polling_ms cur_freq_Hz min_freq_Hz max_freq_Hz
-- -- ---
-- --
soc:bus_dmcnull simple_ondemand
deferrable 50444
soc:bus_acpsoc:bus_dmcpassive
null026700126700
soc:bus_c2csoc:bus_dmcpassive
null0414
soc:bus_leftbusnull simple_ondemand
deferrable 50222
soc:bus_rightbus soc:bus_leftbuspassive
null0212
soc:bus_displaysoc:bus_leftbuspassive
null0222
soc:bus_fsys soc:bus_leftbuspassive
null013400113400
soc:bus_peri soc:bus_leftbuspassive
null01 50001
soc:bus_mfcsoc:bus_leftbuspassive
null0212
[4] PM / devfreq: passive: Update frequency when start governor
https://patchwork.kernel.org/project/linux-pm/patch/20201103070646.18687-1-cw00.c...@samsung.com/
On 10/30/20 9:51 PM, Sylwester Nawrocki wrote:
>
> This patchset adds interconnect API support for the Exynos SoC "samsung,
> exynos-bus" compatible devices, which already have their corresponding
> exynos-bus driver in the devfreq subsystem. Complementing the devfreq
> driver with an interconnect functionality allows to ensure the QoS
> requirements of devices accessing the system memory (e.g. video processing
> devices) are fulfilled and aallows to avoid issues like the one discussed
> in thread [1].
>
> This patch series adds implementation of the interconnect provider per each
> "samsung,exynos-bus" compatible DT node, with one interconnect node per
> provider. The interconnect code which was previously added as a part of
> the devfreq driver has been converted to a separate platform driver.
> In the devfreq a corresponding virtual child platform device is registered.
> Integration of devfreq and interconnect frameworks is achieved through
> the PM QoS API.
>
> A sample interconnect consumer for exynos-mixer is added in patches 5/6,
> 6/6, it is currently added only for exynos4412 and allows to
Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
Am 03.11.20 um 07:53 schrieb Greg KH: On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote: Am 02.11.20 um 20:43 schrieb Alex Deucher: On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma wrote: Initializing global variable to 0 or NULL is not necessary and should be avoided. Issue reported by checkpatch script as: ERROR: do not initialise globals to 0 (or NULL). I agree that this is technically correct, but a lot of people don't seem to know that so we get a lot of comments about this code for the variables that are not explicitly set. Seems less confusing to initialize them even if it not necessary. I don't have a particularly strong opinion on it however. Agree with Alex. Especially for the module parameters we should have a explicit init value for documentation purposes, even when it is 0. Why is this one tiny driver somehow special compared to the entire rest of the kernel? (hint, it isn't...) And it certainly shouldn't :) Please follow the normal coding style rules, there's no reason to ignore them unless you like to constantly reject patches like this that get sent to you. Yeah, that's a rather good point. Not a particular strong opinion on this either, but when something global is set to 0 people usually do this to emphases that it is important that it is zero. Regards, Christian. thnaks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
On Mon, Nov 02, 2020 at 09:48:25PM +0100, Christian König wrote: > Am 03.11.20 um 07:53 schrieb Greg KH: > > On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote: > > > Am 02.11.20 um 20:43 schrieb Alex Deucher: > > > > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma > > > > wrote: > > > > > Initializing global variable to 0 or NULL is not necessary and should > > > > > be avoided. Issue reported by checkpatch script as: > > > > > ERROR: do not initialise globals to 0 (or NULL). > > > > I agree that this is technically correct, but a lot of people don't > > > > seem to know that so we get a lot of comments about this code for the > > > > variables that are not explicitly set. Seems less confusing to > > > > initialize them even if it not necessary. I don't have a particularly > > > > strong opinion on it however. > > > Agree with Alex. > > > > > > Especially for the module parameters we should have a explicit init value > > > for documentation purposes, even when it is 0. > > Why is this one tiny driver somehow special compared to the entire rest > > of the kernel? (hint, it isn't...) > > And it certainly shouldn't :) > > > Please follow the normal coding style rules, there's no reason to ignore > > them unless you like to constantly reject patches like this that get > > sent to you. > > Yeah, that's a rather good point. > > Not a particular strong opinion on this either, but when something global is > set to 0 people usually do this to emphases that it is important that it is > zero. Again, no, that's not what we have been doing in the kernel for the past 20+ years. If you do not set it to anything, we all know it is important for it to be set to 0. Otherwise we would explicitly set it to something else. And if we don't care, then that too doesn't matter so we let it be 0 by not initializing it, it doesn't matter. I think this very change is what started the whole "kernel janitor" movement all those years ago, because it was easily proven that this simple change saved both time and memory. This shouldn't even be an argument we are having anymore... thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Add the new api to install irq
Hi
Thanks, the code looks good already. There just are a few nits below.
Am 03.11.20 um 03:10 schrieb Tian Tao:
> Add new api devm_drm_irq_install() to register interrupts,
> no need to call drm_irq_uninstall() when the drm module is removed.
>
> v2:
> fixed the wrong parameter.
>
> Signed-off-by: Tian Tao
> ---
> drivers/gpu/drm/drm_drv.c | 23 +++
> include/drm/drm_drv.h | 3 ++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index cd162d4..0fe5243 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
The implementation should rather go to drm_irq.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -678,6 +679,28 @@ static int devm_drm_dev_init(struct device *parent,
> return ret;
> }
>
> +static void devm_drm_dev_irq_uninstall(void *data)
> +{
> + drm_irq_uninstall(data);
> +}
> +
> +int devm_drm_irq_install(struct device *parent,
> + struct drm_device *dev, int irq)
> +{
> + int ret;
> +
> + ret = drm_irq_install(dev, irq);
> + if (ret)
> + return ret;
> +
> + ret = devm_add_action(parent, devm_drm_dev_irq_uninstall, dev);
> + if (ret)
> + devm_drm_dev_irq_uninstall(dev);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(devm_drm_irq_install);
> +
> void *__devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver,
> size_t size, size_t offset)
> {
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 0230762..fec1776 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
And the declaration should go to drm_irq.h
We generally don't merge unused code, so you should convert at least one
KMS driver, say hibmc, to use the new interface.
Best regards
Thomas
> @@ -513,7 +513,8 @@ struct drm_driver {
>
> void *__devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver,
> size_t size, size_t offset);
> -
> +int devm_drm_irq_install(struct device *parent, struct drm_device *dev,
> + int irq);
> /**
> * devm_drm_dev_alloc - Resource managed allocation of a &drm_device instance
> * @parent: Parent device object
>
--
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
OpenPGP_0x680DC11D530B7A23.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Fix static checker warning
Am 03.11.20 um 04:51 schrieb Jianxin Xiong:
Here is the warning message:
drivers/dma-buf/dma-buf.c:917 dma_buf_map_attachment()
error: 'sg_table' dereferencing possible ERR_PTR()
Fix by adding error checking before dereferencing the pointer.
Fixes: ac80cd17a615 ("dma-buf: Clarify that dma-buf sg lists are page aligned")
Reported-by: Dan Carpenter
Signed-off-by: Jianxin Xiong
Reviewed-by: Christian König
Do you have commit access to drm-misc-next or should I push it?
---
drivers/dma-buf/dma-buf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 556f62e..0eb80c1 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -908,7 +908,7 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
}
#ifdef CONFIG_DMA_API_DEBUG
- {
+ if (!IS_ERR(sg_table)) {
struct scatterlist *sg;
u64 addr;
int len;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build warning after merge of the drm-misc tree
Hi Stephen,
On Mon, 2 Nov 2020 12:46:37 +1100
Stephen Rothwell wrote:
> Hi all,
>
> After merging the imx-drm tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> drivers/gpu/drm/panfrost/panfrost_job.c: In function 'panfrost_job_close':
> drivers/gpu/drm/panfrost/panfrost_job.c:617:28: warning: unused variable 'js'
> [-Wunused-variable]
> 617 | struct panfrost_job_slot *js = pfdev->js;
> |^~
>
> Introduced by commit
>
> a17d609e3e21 ("drm/panfrost: Don't corrupt the queue mutex on open/close")
>
Thanks for this report. I posted a patch [1] to fix that yesterday, and
I plan to apply it soon.
Regards,
Boris
[1]https://patchwork.kernel.org/project/dri-devel/patch/20201101173817.831769-1-boris.brezil...@collabora.com/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/drm: delete same check in if condition
In function drm_bridge_connector_get_modes_edid, drm_edid_is_valid
will check weather (!edid), no need to check again in the if
branch.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/drm_bridge_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bridge_connector.c
b/drivers/gpu/drm/drm_bridge_connector.c
index a58cbde59c34..791379816837 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -241,7 +241,7 @@ static int drm_bridge_connector_get_modes_edid(struct
drm_connector *connector,
goto no_edid;
edid = bridge->funcs->get_edid(bridge, connector);
- if (!edid || !drm_edid_is_valid(edid)) {
+ if (!drm_edid_is_valid(edid)) {
kfree(edid);
goto no_edid;
}
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/i915: Introduce quirk QUIRK_RENDERCLEAR_REDUCED
From: Randy Wright
Introduce quirk QUIRK_RENDERCLEAR_REDUCED, which will be used
to force a limited batch buffer size for clearing
residual contexts in gen7_renderclear.c.
Signed-off-by: Randy Wright
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4f7f6518945..e8873462eb2c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -525,6 +525,7 @@ struct i915_psr {
#define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
#define QUIRK_INCREASE_T12_DELAY (1<<6)
#define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
+#define QUIRK_RENDERCLEAR_REDUCED (1<<8)
struct intel_fbdev;
struct intel_fbc_work;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm: bridge: add support for lontium LT9611UXC bridge
Add support for Lontium LT9611UXC HDMI bridge. Lontium LT9611UXC is a
DSI to HDMI bridge which supports two DSI ports and I2S port as an input
and HDMI port as output. Despite name being similar to LT9611, these
devices are different enough to warrant separate driver.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/Kconfig | 13 +
drivers/gpu/drm/bridge/Makefile|1 +
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 1002
3 files changed, 1016 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611uxc.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index ef91646441b1..e4110d6ca7b3 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -61,6 +61,19 @@ config DRM_LONTIUM_LT9611
HDMI signals
Please say Y if you have such hardware.
+config DRM_LONTIUM_LT9611UXC
+ tristate "Lontium LT9611UXC DSI/HDMI bridge"
+ select SND_SOC_HDMI_CODEC if SND_SOC
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT9611UXC DSI to HDMI bridge
+ chip driver that converts dual DSI and I2S to
+ HDMI signals
+ Please say Y if you have such hardware.
+
config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2b3aff104e46..86e7acc76f8d 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
+obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
new file mode 100644
index ..0c98d27f84ac
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -0,0 +1,1002 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-2020. Linaro Limited.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define EDID_BLOCK_SIZE128
+#define EDID_NUM_BLOCKS2
+
+struct lt9611uxc {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct regmap *regmap;
+ /* Protects all accesses to registers by stopping the on-chip MCU */
+ struct mutex ocm_lock;
+
+ struct wait_queue_head wq;
+
+ struct device_node *dsi0_node;
+ struct device_node *dsi1_node;
+ struct mipi_dsi_device *dsi0;
+ struct mipi_dsi_device *dsi1;
+ struct platform_device *audio_pdev;
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *enable_gpio;
+
+ struct regulator_bulk_data supplies[2];
+
+ struct i2c_client *client;
+
+ bool hpd_supported;
+ bool edid_read;
+ uint8_t fw_version;
+};
+
+#define LT9611_PAGE_CONTROL0xff
+
+static const struct regmap_range_cfg lt9611uxc_ranges[] = {
+ {
+ .name = "register_range",
+ .range_min = 0,
+ .range_max = 0xd0ff,
+ .selector_reg = LT9611_PAGE_CONTROL,
+ .selector_mask = 0xff,
+ .selector_shift = 0,
+ .window_start = 0,
+ .window_len = 0x100,
+ },
+};
+
+static const struct regmap_config lt9611uxc_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x,
+ .ranges = lt9611uxc_ranges,
+ .num_ranges = ARRAY_SIZE(lt9611uxc_ranges),
+};
+
+struct lt9611uxc_mode {
+ u16 hdisplay;
+ u16 vdisplay;
+ u8 vrefresh;
+};
+
+/*
+ * This chip supports only a fixed set of modes.
+ * Enumerate them here to check whether the mode is supported.
+ */
+static struct lt9611uxc_mode lt9611uxc_modes[] = {
+ { 1920, 1080, 60 },
+ { 1920, 1080, 30 },
+ { 1920, 1080, 25 },
+ { 1366, 768, 60 },
+ { 1360, 768, 60 },
+ { 1280, 1024, 60 },
+ { 1280, 800, 60 },
+ { 1280, 720, 60 },
+ { 1280, 720, 50 },
+ { 1280, 720, 30 },
+ { 1152, 864, 60 },
+ { 1024, 768, 60 },
+ { 800, 600, 60 },
+ { 720, 576, 50 },
+ { 720, 480, 60 },
+ { 640, 480, 60 },
+};
+
+static struct lt9611uxc *bridge_to_lt9611uxc(struct drm_bridge *bridge)
+{
+ return conta
[PATCH] gpu/drm: make crtc check before new_connector circle
In function prepare_signaling, crtc check (c==0) is not related
with the next new_connector circle, maybe we can put the crtc
check just after the crtc circle and before new_connector circle.
This change is to make the code to run a bit first.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/drm_atomic_uapi.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 25c269bc4681..566110996474 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1182,6 +1182,12 @@ static int prepare_signaling(struct drm_device *dev,
c++;
}
+ /*
+* Having this flag means user mode pends on event which will never
+* reach due to lack of at least one CRTC for signaling
+*/
+ if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
+ return -EINVAL;
for_each_new_connector_in_state(state, conn, conn_state, i) {
struct drm_writeback_connector *wb_conn;
@@ -1220,13 +1226,6 @@ static int prepare_signaling(struct drm_device *dev,
conn_state->writeback_job->out_fence = fence;
}
- /*
-* Having this flag means user mode pends on event which will never
-* reach due to lack of at least one CRTC for signaling
-*/
- if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
- return -EINVAL;
-
return 0;
}
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd: move DRM_ERROR log out of the mutex protect area
In function amdgpu_register_gpu_instance, there is no need to
protect DRM_ERROR in mutex mgpu_info.mutex.
This change is to make the code to run a bit fast.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index efda38349a03..cc61b0a5b8d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -104,8 +104,8 @@ void amdgpu_register_gpu_instance(struct amdgpu_device
*adev)
mutex_lock(&mgpu_info.mutex);
if (mgpu_info.num_gpu >= MAX_GPU_INSTANCE) {
- DRM_ERROR("Cannot register more gpu instance\n");
mutex_unlock(&mgpu_info.mutex);
+ DRM_ERROR("Cannot register more gpu instance\n");
return;
}
--
2.29.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] dt-bindings: display: bridge: Add documentation for LT9611UXC
Lontium LT9611UXC is a DSI to HDMI bridge which supports 2 DSI ports and I2S port as input and one HDMI port as output. The LT9611UXC chip is handled by a separate driver, but the bindings used are fully compatible with the LT9611 chip, so let's reuse the lt9611.yaml schema. Signed-off-by: Dmitry Baryshkov Acked-by: Vinod Koul Acked-by: Sam Ravnborg Acked-by: Rob Herring Reviewed-by: Bjorn Andersson --- .../devicetree/bindings/display/bridge/lontium,lt9611.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml index d60208359234..7a1c89b995e2 100644 --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml @@ -4,18 +4,19 @@ $id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Lontium LT9611 2 Port MIPI to HDMI Bridge +title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge maintainers: - Vinod Koul description: | - The LT9611 is a bridge device which converts DSI to HDMI + The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI properties: compatible: enum: - lontium,lt9611 + - lontium,lt9611uxc reg: maxItems: 1 -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] drm/i915/display: Add function quirk_renderclear_reduced
From: Randy Wright
Added function quirk_renderclear_reduced to set QUIRK_RENDERCLEAR_REDUCED
for designated platforms. Applying QUIRK_RENDERCLEAR_REDUCED for
the HP Pavilion Mini 300-020 prevents a GPU hang.
Signed-off-by: Randy Wright
---
drivers/gpu/drm/i915/display/intel_quirks.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
b/drivers/gpu/drm/i915/display/intel_quirks.c
index 46beb155d835..630b984ba49c 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
drm_i915_private *i915)
drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
}
+/*
+ * Force use of smaller batch size in gen7_renderclear.c
+ * Needed on (at least) HP Pavilion Mini 300-020 to avoid GPU hang.
+ */
+static void quirk_renderclear_reduced(struct drm_i915_private *i915)
+{
+ i915->quirks |= QUIRK_RENDERCLEAR_REDUCED;
+ drm_info(&i915->drm, "Applying Renderclear Reduced quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -141,6 +151,9 @@ static struct intel_quirk intel_quirks[] = {
/* HP Chromebook 14 (Celeron 2955U) */
{ 0x0a06, 0x103c, 0x21ed, quirk_backlight_present },
+ /* HP Mini 300-020 */
+ { 0x0a06, 0x103c, 0x2b38, quirk_renderclear_reduced },
+
/* Dell Chromebook 11 */
{ 0x0a06, 0x1028, 0x0a35, quirk_backlight_present },
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/2] Add LT9611UXC DSI to HDMI bridge support
Hi, This series adds support for Lontium LT9611UXC bridge chip which takes MIPI DSI as input and provides HDMI signal as output. The chip can be found in Qualcomm RB5 platform [1], [2]. [1] https://www.qualcomm.com/products/qualcomm-robotics-rb5-platform [2] https://www.thundercomm.com/app_en/product/1590131656070623 Changes since v3: - Support for firmware upgrades - Simplified modes table to include only used fields (w, h, refresh) - Added more entries to display modes table, as more modes are supported by the firmware - Wait for EDID to be available from the hardware before reading it - Do not store EDID in the interim buffer, lowering the size of per-device struct Changes since v2: - Squashed connector support into main patch - Added comment on modes table - Dropped display timings support, covered by EDID - Dropped sleep mode support - Dropped hpd_status reading from ISR handler - Added "sentinel" comments to empty table entries Changes since v1: - Fix whitespaces/indentation - Support working without DRM_BRIDGE_ATTACH_NO_CONNECTOR ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/i915/gt: Force reduced batch size if new QUIRK_RENDERCLEAR_REDUCED is set.
From: Randy Wright
In function batch_get_defaults, the smaller batch size
will be selected if QUIRK_RENDERCLEAR_REDUCED is set.
Signed-off-by: Randy Wright
---
drivers/gpu/drm/i915/gt/gen7_renderclear.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
index d93d85cd3027..e5265cdf696b 100644
--- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -49,7 +49,7 @@ struct batch_vals {
static void
batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv)
{
- if (IS_HASWELL(i915)) {
+ if (IS_HASWELL(i915) && !(i915->quirks & QUIRK_RENDERCLEAR_REDUCED)) {
bv->max_primitives = 280;
bv->max_urb_entries = MAX_URB_ENTRIES;
bv->surface_height = 16 * 16;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] phy: mediatek: Move mtk_mipi_dsi_phy driver into drivers/phy/mediatek folder
On Mon, 2020-11-02 at 07:08 +0800, Chun-Kuang Hu wrote:
> + Vinod:
>
> Hi, Chunfeng:
>
> Chunfeng Yun 於 2020年10月30日 週五 下午2:24寫道：
> >
> > On Thu, 2020-10-29 at 23:27 +0800, Chun-Kuang Hu wrote:
> > > mtk_mipi_dsi_phy is currently placed inside mediatek drm driver, but it's
> > > more suitable to place a phy driver into phy driver folder, so move
> > > mtk_mipi_dsi_phy driver into phy driver folder.
> > >
> > > Signed-off-by: Chun-Kuang Hu
> > > ---
> > > drivers/gpu/drm/mediatek/Kconfig | 7 ---
> > > drivers/gpu/drm/mediatek/Makefile | 6 --
> > > drivers/phy/mediatek/Kconfig | 7 +++
> > > drivers/phy/mediatek/Makefile | 5 +
> > > .../mediatek/phy-mtk-mipi-dsi-mt8173.c}| 2 +-
> > > .../mediatek/phy-mtk-mipi-dsi-mt8183.c}| 2 +-
> > > .../mtk_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi.c} | 2 +-
> > > .../mtk_mipi_tx.h => phy/mediatek/phy-mtk-mipi-dsi.h} | 0
> > > 8 files changed, 15 insertions(+), 16 deletions(-)
> > > rename drivers/{gpu/drm/mediatek/mtk_mt8173_mipi_tx.c =>
> > > phy/mediatek/phy-mtk-mipi-dsi-mt8173.c} (99%)
> > > rename drivers/{gpu/drm/mediatek/mtk_mt8183_mipi_tx.c =>
> > > phy/mediatek/phy-mtk-mipi-dsi-mt8183.c} (99%)
> > > rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.c =>
> > > phy/mediatek/phy-mtk-mipi-dsi.c} (99%)
> > > rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.h =>
> > > phy/mediatek/phy-mtk-mipi-dsi.h} (100%)
> >
> > Reviewed-by: Chunfeng Yun
>
> I would like to apply the whole series into my tree, would you please
> give an acked-by tag on this patch, so I could apply this patch into
> my tree.
Acked-by: Chunfeng Yun
>
> Regards,
> Chun-Kuang.
>
> >
> > Please add phy maintaniner "Vinod Koul "
> >
> > Thanks
> >
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/Kconfig
> > > b/drivers/gpu/drm/mediatek/Kconfig
> > > index 24c4890a6e65..2976d21e9a34 100644
> > > --- a/drivers/gpu/drm/mediatek/Kconfig
> > > +++ b/drivers/gpu/drm/mediatek/Kconfig
> > > @@ -28,10 +28,3 @@ config DRM_MEDIATEK_HDMI
> > > select PHY_MTK_HDMI
> > > help
> > > DRM/KMS HDMI driver for Mediatek SoCs
> > > -
> > > -config PHY_MTK_MIPI_DSI
> > > - tristate "Mediatek MIPI-DSI-PHY Driver"
> > > - depends on ARCH_MEDIATEK && OF
> > > - select GENERIC_PHY
> > > - help
> > > - Support MIPI DSI PHY for Mediatek SoCs.
> > > diff --git a/drivers/gpu/drm/mediatek/Makefile
> > > b/drivers/gpu/drm/mediatek/Makefile
> > > index baa188000543..a892edec5563 100644
> > > --- a/drivers/gpu/drm/mediatek/Makefile
> > > +++ b/drivers/gpu/drm/mediatek/Makefile
> > > @@ -19,9 +19,3 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
> > > mtk_hdmi_ddc.o
> > >
> > > obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> > > -
> > > -phy-mtk-mipi-dsi-drv-objs := mtk_mipi_tx.o \
> > > - mtk_mt8173_mipi_tx.o \
> > > - mtk_mt8183_mipi_tx.o
> > > -
> > > -obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o
> > > diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> > > index 50c5e9306e19..574b8e6398d2 100644
> > > --- a/drivers/phy/mediatek/Kconfig
> > > +++ b/drivers/phy/mediatek/Kconfig
> > > @@ -42,3 +42,10 @@ config PHY_MTK_HDMI
> > > select GENERIC_PHY
> > > help
> > > Support HDMI PHY for Mediatek SoCs.
> > > +
> > > +config PHY_MTK_MIPI_DSI
> > > + tristate "MediaTek MIPI-DSI Driver"
> > > + depends on ARCH_MEDIATEK && OF
> > > + select GENERIC_PHY
> > > + help
> > > + Support MIPI DSI for Mediatek SoCs.
> > > diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> > > index 6325e38709ed..ace660fbed3a 100644
> > > --- a/drivers/phy/mediatek/Makefile
> > > +++ b/drivers/phy/mediatek/Makefile
> > > @@ -11,3 +11,8 @@ phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
> > > phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> > > phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt8173.o
> > > obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> > > +
> > > +phy-mtk-mipi-dsi-drv-y := phy-mtk-mipi-dsi.o
> > > +phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8173.o
> > > +phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8183.o
> > > +obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
> > > b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> > > similarity index 99%
> > > rename from drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
> > > rename to drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> > > index f18db14d8b63..7a847954594f 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
> > > +++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> > > @@ -4,7 +4,7 @@
>
