Re: [PATCH 17/18] drm/arcpgu: Convert to devm_platform_ioremap_resource()
Hi Yangtao, > Use devm_platform_ioremap_resource() to simplify code. > > Signed-off-by: Yangtao Li Thanks for the improvement. Acked-by: Alexey Brodkin > --- > drivers/gpu/drm/tiny/arcpgu.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c > index e5b10e41554a..3a5e66d909a4 100644 > --- a/drivers/gpu/drm/tiny/arcpgu.c > +++ b/drivers/gpu/drm/tiny/arcpgu.c > @@ -251,7 +251,6 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu) > struct device_node *encoder_node = NULL, *endpoint_node = NULL; > struct drm_connector *connector = NULL; > struct drm_device *drm = >drm; > - struct resource *res; > int ret; > > arcpgu->clk = devm_clk_get(drm->dev, "pxlclk"); > @@ -268,8 +267,7 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu) > drm->mode_config.max_height = 1080; > drm->mode_config.funcs = _drm_modecfg_funcs; > > - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > - arcpgu->regs = devm_ioremap_resource(>dev, res); > + arcpgu->regs = devm_platform_ioremap_resource(pdev, 0); > if (IS_ERR(arcpgu->regs)) > return PTR_ERR(arcpgu->regs); > > -- > 2.39.0
Re: [PATCH v2 3/7] drm/arc: use new debugfs device-centered functions
Hi Maíra, > Replace the use of drm_debugfs_create_files() with the new > drm_debugfs_add_file() function, which centers the debugfs files > management on the drm_device instead of drm_minor. Moreover, remove the > debugfs_init hook and add the debugfs files directly on arcpgu_probe(), > before drm_dev_register(). > > Reviewed-by: Daniel Vetter > Signed-off-by: Maíra Canal > --- > drivers/gpu/drm/tiny/arcpgu.c | 24 +--- > 1 file changed, 5 insertions(+), 19 deletions(-) Thanks for taking care of ARC PGU driver and Acked-by: Alexey Brodkin
Re: [PATCH] drm/arc: disambiguate Synopsys ARC in Kconfig labels
Hi Adam, > There's Intel Arc now which is what most folks will be looking for. > > Signed-off-by: Adam Borowski > --- > drivers/gpu/drm/tiny/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig > index 565957264875..51b60c1a2bea 100644 > --- a/drivers/gpu/drm/tiny/Kconfig > +++ b/drivers/gpu/drm/tiny/Kconfig > @@ -1,12 +1,12 @@ > # SPDX-License-Identifier: GPL-2.0-only > > config DRM_ARCPGU > - tristate "ARC PGU" > + tristate "Synopsys ARC PGU" > depends on DRM && OF > select DRM_GEM_DMA_HELPER > select DRM_KMS_HELPER > help > - Choose this option if you have an ARC PGU controller. > + Choose this option if you have a Synopsys ARC PGU controller. > >If M is selected the module will be called arcpgu. Acked-by: Alexey Brodkin
RE: [PATCH 53/59] drm/arc: Move to drm/tiny
Hi Daniel, > > Looking at this patch series, feels a bit like hand-rolling of bridge > > code, badly. We should get away from that. > > > > Once you have that I think the end result is tiny enough that it can > > stay, bridges intergrate quite well into simple display pipe drivers. > > > > > BTW should I pull that series in my tree and send you a pull-request > > > or that kind of change needs to go through another tree? > > > > > > Also I'd like to test the change we discuss here to make sure stuff > > > still works. Once we do that I'll send an update. Any hint on > > > when that change needs to be acked/nacked? > > > > Simplest is if this can all land through drm-misc, is arc not > > maintained in there? And there's plenty of time for testing, I'm just > > slowly crawling through the tree to get everything polished and > > cleaned up in this area. > > Any updates on testing this pile here? First patch landed now, and I've > started to push driver patches. So would be good to get this sorted out > too. Sorry we're in the middle of 2 long weekends so missed this one. I guess we'll be able to test it in a week or two from now. Is that OK? -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 53/59] drm/arc: Move to drm/tiny
Hi Daniel,
> -Original Message-
> From: Sam Ravnborg
> Sent: Wednesday, April 15, 2020 12:45 PM
> To: Daniel Vetter
> Cc: Intel Graphics Development ; Alexey
> Brodkin
> ; DRI Development ;
> Daniel Vetter
>
> Subject: Re: [PATCH 53/59] drm/arc: Move to drm/tiny
>
> Hi Daniel.
> On Wed, Apr 15, 2020 at 09:40:28AM +0200, Daniel Vetter wrote:
> > Because it is.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Alexey Brodkin
> > ---
> > MAINTAINERS | 2 +-
> > drivers/gpu/drm/Kconfig | 2 --
> > drivers/gpu/drm/Makefile| 1 -
> > drivers/gpu/drm/arc/Kconfig | 10 --
> > drivers/gpu/drm/arc/Makefile| 3 ---
> > drivers/gpu/drm/tiny/Kconfig| 10 ++
> > drivers/gpu/drm/tiny/Makefile | 1 +
> > drivers/gpu/drm/{arc/arcpgu_drv.c => tiny/arcpgu.c} | 0
> > 8 files changed, 12 insertions(+), 17 deletions(-)
> > delete mode 100644 drivers/gpu/drm/arc/Kconfig
> > delete mode 100644 drivers/gpu/drm/arc/Makefile
> > rename drivers/gpu/drm/{arc/arcpgu_drv.c => tiny/arcpgu.c} (100%)
>
> We have "DRM: ARC: add HDMI 2.0 TX encoder support" which
> adds another platform driver to drm/arc/
> This speaks against the move to tiny IMO
Indeed that's an interesting question, see v3 series here:
https://lists.freedesktop.org/archives/dri-devel/2020-April/262352.html
BTW should I pull that series in my tree and send you a pull-request
or that kind of change needs to go through another tree?
Also I'd like to test the change we discuss here to make sure stuff
still works. Once we do that I'll send an update. Any hint on
when that change needs to be acked/nacked?
-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 05/17] drm/arc: make arcgpu_debugfs_init() return 0.
Hi Wambui, > -Original Message- > From: Wambui Karuga > Sent: Tuesday, March 10, 2020 8:31 PM > To: airl...@linux.ie; dan...@ffwll.ch; Alexey Brodkin > Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; > gre...@linuxfoundation.org > Subject: [PATCH v2 05/17] drm/arc: make arcgpu_debugfs_init() return 0. > > Since commit 987d65d01356 (drm: debugfs: make > drm_debugfs_create_files() never fail), drm_debugfs_create_files() never > fails and should return void. Therefore, remove its use as the > return value of arcpgu_debugfs_init() and have the latter function return > 0 directly. > > v2: convert the function to return 0 instead of void to avoid breaking > the build and ensure that this individual patch compiles properly. > > References: > https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html > Signed-off-by: Wambui Karuga Thanks for the patch! Acked-by: Alexey Brodkin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] DRM: ARC: PGU: interlaced mode not supported
Hi Greg, > -Original Message- > From: Greg KH > Sent: Wednesday, March 11, 2020 8:22 PM > To: Eugeniy Paltsev > Cc: dri-devel@lists.freedesktop.org; Alexey Brodkin ; > linux-snps- > a...@lists.infradead.org; linux-ker...@vger.kernel.org; David Airlie > ; Daniel Vetter > ; sta...@vger.kernel.org > Subject: Re: [PATCH] DRM: ARC: PGU: interlaced mode not supported > > On Wed, Mar 11, 2020 at 04:13:10PM +0300, Eugeniy Paltsev wrote: > > Filter out interlaced modes as they are not supported by ARC PGU > > hardware. > > > > Signed-off-by: Eugeniy Paltsev > > --- > > drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c > > b/drivers/gpu/drm/arc/arcpgu_crtc.c > > index 8ae1e1f97a73..c854066d4c75 100644 > > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c > > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c > > @@ -67,6 +67,9 @@ static enum drm_mode_status > > arc_pgu_crtc_mode_valid(struct drm_crtc *crtc, > > long rate, clk_rate = mode->clock * 1000; > > long diff = clk_rate / 200; /* +-0.5% allowed by HDMI spec */ > > > > + if (mode->flags & DRM_MODE_FLAG_INTERLACE) > > + return MODE_NO_INTERLACE; > > + > > rate = clk_round_rate(arcpgu->clk, clk_rate); > > if ((max(rate, clk_rate) - min(rate, clk_rate) < diff) && (rate > 0)) > > return MODE_OK; > > -- > > 2.21.1 > > > > > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read: > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.kernel.org_doc_html_latest_process_stable-2Dkernel- > 2Drules.html=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=oXPD1Sz > FBs-0-4u24Ah1rK1Y65Fma8tJZix0Jih-yqY=WTVW1dC7E2oD0muPxtNd9KAHzwIZwEU9jGuCHWx1iQk= > for how to do this properly. > > Thanks for the comment. I'll add "Cc: sta...@vger.kernel.org" tag to the patch on committing it to my maintainer tree so one the patch makes its way up to the Linus' tree you'll get notified as usual. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/arc: Filter out interlaced mode
Hi David, Daniel! The following changes since commit e3c3b6e66da1caeb39a504b03ddcdd3693e45254: Merge tag 'exynos-drm-fixes-for-v5.6-rc5-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes (2020-03-12 11:02:52 +1000) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2020.03.12 for you to fetch changes up to 1e8928584e8f29c31c8db1a50b5bdb1769047434: DRM: ARC: PGU: interlaced mode not supported (2020-03-12 07:59:06 +0300) There's just one tiny fix this time around with explicit filtering of interlaced modes as they are not supported by ARC PGU hardware. Eugeniy Paltsev (1): DRM: ARC: PGU: interlaced mode not supported drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +++ 1 file changed, 3 insertions(+) Note this is based on the current drm/drm-fixes contents. Thanks, Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 06/21] drm/arc: make arcpgu_debugfs_init return void
Hi Wambui, > -Original Message- > From: Wambui Karuga > Sent: Thursday, February 27, 2020 7:02 PM > To: dan...@ffwll.ch; airl...@linux.ie; Alexey Brodkin > Cc: linux-ker...@vger.kernel.org; gre...@linuxfoundation.org; > dri-devel@lists.freedesktop.org > Subject: [PATCH 06/21] drm/arc: make arcpgu_debugfs_init return void > > Since commit 987d65d01356 (drm: debugfs: make > drm_debugfs_create_files() never fail), drm_debugfs_create_files never > fails and should return void. Therefore, remove its use as the > return value of arcpgu_debugfs_init and have the latter function also > return void. > > Signed-off-by: Wambui Karuga Thanks for this clean-up and Acked-by: Alexey Brodkin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 5/9] arc: Constify ioreadX() iomem argument (as in generic implementation)
Hi Krzysztof, > The ioreadX() helpers have inconsistent interface. On some architectures > void *__iomem address argument is a pointer to const, on some not. > > Implementations of ioreadX() do not modify the memory under the > address so they can be converted to a "const" version for const-safety > and consistency among architectures. Thanks for this clean-up. Looks good to me, so ... Acked-by: Alexey Brodkin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL REBASED] drm/arc: Yet another set of minor fixes
Hi David, Daniel! The following changes since commit d1eef1c619749b2a57e514a3fa67d9a516ffa919: Linux 5.5-rc2 (2019-12-15 15:16:08 -0800) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.12.16 for you to fetch changes up to 0ff916e2ef6fb742e4906aac26c470314b59bae8: DRM: ARC: PGU: add ARGB format to supported format list (2019-12-16 13:53:05 +0300) Clean-up and fixes for FourCC handling in ARC PGU. Eugeniy Paltsev (4): DRM: ARC: PGU: fix framebuffer format switching DRM: ARC: PGU: cleanup supported format list code DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 DRM: ARC: PGU: add ARGB format to supported format list drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++-- drivers/gpu/drm/arc/arcpgu_regs.h | 2 +- 2 files changed, 19 insertions(+), 19 deletions(-) Note this is based on the current drm/drm-next contents. Thanks, Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [GIT PULL] drm/arc: Yet another set of minor fixes
Hi Daniel, [snip] > > Thanks for the pointers > > > > > Or respin this one, but these small pulls have a habit of occasionally > > > getting lost :-/ > > > > Well I'd better re-spin this, see below. > > > > The following changes since commit acc61b8929365e63a3e8c8c8913177795aa45594: > > > > Merge tag 'drm-next-5.5-2019-11-22' of > > git://people.freedesktop.org/~agd5f/linux into drm-next > (2019-11-26 08:40:23 +1000) > > > > are available in the Git repository at: > > > > g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27 > > > > for you to fetch changes up to 9c2acc26c899aa12ad009dff10a5573ef769a7fd: > > > > DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 > > 16:43:39 +0300) > > > > > > Clean-up and fixes for FourCC handling in ARC PGU. > > > > > > Eugeniy Paltsev (4): > > DRM: ARC: PGU: fix framebuffer format switching > > DRM: ARC: PGU: cleanup supported format list code > > DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 > > DRM: ARC: PGU: add ARGB format to supported format list > > > > drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++-- > > drivers/gpu/drm/arc/arcpgu_regs.h | 2 +- > > 2 files changed, 19 insertions(+), 19 deletions(-) Not sure if you noticed re-spin of my pull-request in the previous message. Do you want me to send it in a separate email? -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [GIT PULL] drm/arc: Yet another set of minor fixes
Hi Daniel, > -Original Message- > From: Daniel Vetter > Sent: Friday, December 13, 2019 1:22 PM > To: Alexey Brodkin > Cc: Daniel Vetter ; David Airlie ; arcml > a...@lists.infradead.org>; Eugeniy Paltsev ; > dri-devel@lists.freedesktop.org > Subject: Re: [GIT PULL] drm/arc: Yet another set of minor fixes > [snip] > > Not sure if you noticed re-spin of my pull-request in the previous message. > > Do you want me to send it in a separate email? > > Yeah I guess this got lost again. So should I re-send it in another email or you will pick it up from existing thread? If I'm going to re-send it do I need to re-base it on today's drm/drm-next? -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/arc: Yet another set of minor fixes
Hi David, Daniel! The following changes since commit 8082731830a0b95f7f7a63b78de67de446013c80: drm/vram: remove unused declaration (2019-11-27 07:51:49 +0100) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27 for you to fetch changes up to b2c68fb15a4c2e27f80353d3067dce30882a0972: DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 10:38:24 +0300) Clean-up and fixes for FourCC handling in ARC PGU. Eugeniy Paltsev (4): DRM: ARC: PGU: fix framebuffer format switching DRM: ARC: PGU: cleanup supported format list code DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 DRM: ARC: PGU: add ARGB format to supported format list drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++-- drivers/gpu/drm/arc/arcpgu_regs.h | 2 +- 2 files changed, 19 insertions(+), 19 deletions(-) Thanks, Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [GIT PULL] drm/arc: Yet another set of minor fixes
Hi Daniel, > -Original Message- > From: Daniel Vetter > Sent: Wednesday, November 27, 2019 1:07 PM > To: Alexey Brodkin > Cc: Daniel Vetter ; David Airlie ; arcml > a...@lists.infradead.org>; Eugeniy Paltsev ; > dri-devel@lists.freedesktop.org > Subject: Re: [GIT PULL] drm/arc: Yet another set of minor fixes > > On Wed, Nov 27, 2019 at 07:48:04AM +, Alexey Brodkin wrote: > > Hi David, Daniel! > > > > The following changes since commit 8082731830a0b95f7f7a63b78de67de446013c80: > > > > drm/vram: remove unused declaration (2019-11-27 07:51:49 +0100) > > > > are available in the Git repository at: > > > > g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27 > > > > for you to fetch changes up to b2c68fb15a4c2e27f80353d3067dce30882a0972: > > > > DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 > > 10:38:24 +0300) > > > > > > Clean-up and fixes for FourCC handling in ARC PGU. > > > > > > Eugeniy Paltsev (4): > > DRM: ARC: PGU: fix framebuffer format switching > > DRM: ARC: PGU: cleanup supported format list code > > DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 > > DRM: ARC: PGU: add ARGB format to supported format list > > Uh, this seems to be based on some random snapshot of drm-misc-next, so > contains a _lot_ more than just these 4 patches (compared to drm-next). Indeed it's based off of today's "drm-misc-next". That's because I still get lost when I have to deal with DRM trees which we have a plenty. I guess there should be a clean explanation of which repo and branch should be used for which purpose, right? May I have a reference to it then? > If you want to move arcpgu to drm-misc (which would make tons of sense imo) Could you please elaborate a bit on this? Given we have a couple a patches if at all for each kernel release I'd prefer to escape a need to use yet another repo, tools etc as this doesn't simplify anything but instead makes simple things much more complex (if done rarely). > then: > - create a MAINTAINER patch to add drm-misc as the git repo for it > - request your account for drm-misc, see > https://www.freedesktop.org/wiki/AccountRequests/ > - and set up the scripts > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html Thanks for the pointers > Or respin this one, but these small pulls have a habit of occasionally > getting lost :-/ Well I'd better re-spin this, see below. The following changes since commit acc61b8929365e63a3e8c8c8913177795aa45594: Merge tag 'drm-next-5.5-2019-11-22' of git://people.freedesktop.org/~agd5f/linux into drm-next (2019-11-26 08:40:23 +1000) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27 for you to fetch changes up to 9c2acc26c899aa12ad009dff10a5573ef769a7fd: DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 16:43:39 +0300) Clean-up and fixes for FourCC handling in ARC PGU. Eugeniy Paltsev (4): DRM: ARC: PGU: fix framebuffer format switching DRM: ARC: PGU: cleanup supported format list code DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 DRM: ARC: PGU: add ARGB format to supported format list drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++-- drivers/gpu/drm/arc/arcpgu_regs.h | 2 +- 2 files changed, 19 insertions(+), 19 deletions(-) -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [GIT PULL] drm/arc: Minor improvements
Hi all, As Jose suggested I'm adding "drm-misc" maintainers as that tree might be a better fit for ARC PGU patches. -Alexey > -Original Message- > From: linux-snps-arc On Behalf > Of Alexey Brodkin > Sent: Wednesday, November 27, 2019 10:25 AM > To: Daniel Vetter ; David Airlie > Cc: arcml ; Eugeniy Paltsev > ; dri- > de...@lists.freedesktop.org > Subject: RE: [GIT PULL] drm/arc: Minor improvements > > Hi Daniel, David! > > Any chance for this one to be processed sometime soon? > It's been quite some time since July when I initially sent > this pull-request. > > -Alexey > > > -Original Message- > > From: linux-snps-arc On Behalf > > Of Alexey Brodkin > > Sent: Wednesday, November 13, 2019 2:30 PM > > To: Daniel Vetter ; David Airlie > > Cc: arcml ; Eugeniy Paltsev > > ; dri- > > de...@lists.freedesktop.org > > Subject: RE: [GIT PULL] drm/arc: Minor improvements > > > > Hi Daniel, David, > > > > > -Original Message- > > > From: linux-snps-arc On > > > Behalf Of Alexey Brodkin > > > Sent: Thursday, July 18, 2019 12:09 AM > > > To: Daniel Vetter ; David Airlie > > > Cc: arcml ; > > > dri-devel@lists.freedesktop.org > > > Subject: [GIT PULL] drm/arc: Minor improvements > > > > > > Hi Dave, Daniel, > > > > > > The following changes since commit > > > 7aaddd96d5febcf5b24357a326b3038d49a20532: > > > > > > drm/modes: Don't apply cmdline's rotation if it wasn't specified > > > (2019-07-16 10:34:38 +0200) > > > > > > are available in the Git repository at: > > > > > > g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18 > > > > > > for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9: > > > > > > drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300) > > > > > > > > > This is a pretty simple improvement that allows to find encoder > > > as the one and only (ARC PGU doesn't support more than one) endpoint > > > instead of using non-standard "encoder-slave" property. > > > > > > > > > Eugeniy Paltsev (1): > > > drm/arcpgu: rework encoder search > > > > > > drivers/gpu/drm/arc/arcpgu_drv.c | 16 +--- > > > 1 file changed, 13 insertions(+), 3 deletions(-) > > > > Any chance for this one to get pulled into your tree(s) sometime soon? > > > > -Alexey > > > > ___ > > linux-snps-arc mailing list > > linux-snps-...@lists.infradead.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux- > 2Dsnps- > > > 2Darc=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=f3bFSjs3gZI9vC > > LJW5sa6Kxu43yXUsCXhaUNhtEymmk=eFO6mnw8IJyfrQZYrMEbJ-bryplfw9LvcYBSCEyj5XA= > > ___ > linux-snps-arc mailing list > linux-snps-...@lists.infradead.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps- > 2Darc=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=c8DhCL8_- > 0iY2tS35o8kpDyvbHZ_Cu762s4qtn2hDVg=sGFaDT7yPIbVcjW49E_rjb6ND82Nrq0kplYjbztlh3A= ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [GIT PULL] drm/arc: Minor improvements
Hi Daniel, David! Any chance for this one to be processed sometime soon? It's been quite some time since July when I initially sent this pull-request. -Alexey > -Original Message- > From: linux-snps-arc On Behalf > Of Alexey Brodkin > Sent: Wednesday, November 13, 2019 2:30 PM > To: Daniel Vetter ; David Airlie > Cc: arcml ; Eugeniy Paltsev > ; dri- > de...@lists.freedesktop.org > Subject: RE: [GIT PULL] drm/arc: Minor improvements > > Hi Daniel, David, > > > -Original Message- > > From: linux-snps-arc On Behalf > > Of Alexey Brodkin > > Sent: Thursday, July 18, 2019 12:09 AM > > To: Daniel Vetter ; David Airlie > > Cc: arcml ; > > dri-devel@lists.freedesktop.org > > Subject: [GIT PULL] drm/arc: Minor improvements > > > > Hi Dave, Daniel, > > > > The following changes since commit 7aaddd96d5febcf5b24357a326b3038d49a20532: > > > > drm/modes: Don't apply cmdline's rotation if it wasn't specified > > (2019-07-16 10:34:38 +0200) > > > > are available in the Git repository at: > > > > g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18 > > > > for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9: > > > > drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300) > > > > > > This is a pretty simple improvement that allows to find encoder > > as the one and only (ARC PGU doesn't support more than one) endpoint > > instead of using non-standard "encoder-slave" property. > > > > > > Eugeniy Paltsev (1): > > drm/arcpgu: rework encoder search > > > > drivers/gpu/drm/arc/arcpgu_drv.c | 16 +--- > > 1 file changed, 13 insertions(+), 3 deletions(-) > > Any chance for this one to get pulled into your tree(s) sometime soon? > > -Alexey > > ___ > linux-snps-arc mailing list > linux-snps-...@lists.infradead.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps- > 2Darc=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=f3bFSjs3gZI9vC > LJW5sa6Kxu43yXUsCXhaUNhtEymmk=eFO6mnw8IJyfrQZYrMEbJ-bryplfw9LvcYBSCEyj5XA= ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [GIT PULL] drm/arc: Minor improvements
Hi Daniel, David, > -Original Message- > From: linux-snps-arc On Behalf > Of Alexey Brodkin > Sent: Thursday, July 18, 2019 12:09 AM > To: Daniel Vetter ; David Airlie > Cc: arcml ; > dri-devel@lists.freedesktop.org > Subject: [GIT PULL] drm/arc: Minor improvements > > Hi Dave, Daniel, > > The following changes since commit 7aaddd96d5febcf5b24357a326b3038d49a20532: > > drm/modes: Don't apply cmdline's rotation if it wasn't specified > (2019-07-16 10:34:38 +0200) > > are available in the Git repository at: > > g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18 > > for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9: > > drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300) > > > This is a pretty simple improvement that allows to find encoder > as the one and only (ARC PGU doesn't support more than one) endpoint > instead of using non-standard "encoder-slave" property. > > > Eugeniy Paltsev (1): > drm/arcpgu: rework encoder search > > drivers/gpu/drm/arc/arcpgu_drv.c | 16 +--- > 1 file changed, 13 insertions(+), 3 deletions(-) Any chance for this one to get pulled into your tree(s) sometime soon? -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/arc: Minor improvements
Hi Dave, Daniel, The following changes since commit 7aaddd96d5febcf5b24357a326b3038d49a20532: drm/modes: Don't apply cmdline's rotation if it wasn't specified (2019-07-16 10:34:38 +0200) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18 for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9: drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300) This is a pretty simple improvement that allows to find encoder as the one and only (ARC PGU doesn't support more than one) endpoint instead of using non-standard "encoder-slave" property. Eugeniy Paltsev (1): drm/arcpgu: rework encoder search drivers/gpu/drm/arc/arcpgu_drv.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) Regards, Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4 5/8] drm/arcpgu: prepare for drmP.h removal from drm_modeset_helper.h
Hi Sam, > -Original Message- > From: Sam Ravnborg [mailto:sam.ravnb...@gmail.com] On Behalf Of Sam Ravnborg > Sent: Saturday, January 12, 2019 10:33 PM > To: Alex Deucher ; Alexey Brodkin > ; Andrzej > Hajda ; Benjamin Gaignard > ; Chen Feng > ; Christian Konig ; Daniel > Vetter > ; David Airlie ; David Zhou > ; Eric Anholt > ; Gerd Hoffmann ; Kieran Bingham > ; Laurent Pinchart > ; > Laurent Pinchart ; Maarten Lankhorst > ; Maxime Ripard > ; Philippe Cornu > ; Rob Clark ; Rongrong Zou > ; Sean > Paul ; Tomi Valkeinen ; Vincent Abriou > ; Xinliang Liu ; Xinwei > Kong > ; Yannick Fertre ; > linux-ker...@vger.kernel.org; > dri-devel@lists.freedesktop.org > Cc: Sam Ravnborg > Subject: [PATCH v4 5/8] drm/arcpgu: prepare for drmP.h removal from > drm_modeset_helper.h > > The use of drmP.h is discouraged and removal of it from > drm_modeset_helper.h caused arcgpu to fail to build. > > This patch introduce the necessary fixes to prepare for the > drmP.h removal from drm_modeset_helper.h. > List of include files sorted alphabetically. > > Build tested on arm x86 and arm allmodconfig. > > Signed-off-by: Sam Ravnborg > Cc: Alexey Brodkin > Cc: David Airlie > Cc: Daniel Vetter Thanks for your patch! Build tested for ARC AXS103 board. Acked-by: Alexey Brodkin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm: replace "drm_dev_unref" function with "drm_dev_put"
Hi Fernando, On Thu, 2018-11-15 at 23:16 +0100, Fernando Ramos wrote: > This patch unifies the naming of DRM functions for reference counting as > requested on Documentation/gpu/todo.rst > > Signed-off-by: Fernando Ramos > --- > drivers/gpu/drm/arc/arcpgu_drv.c | 4 ++-- For ARCPGU Acked-by: Alexey Brodkin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/20] drm/arc: Use drm_fbdev_generic_setup()
Hi Noralf, On Mon, 2018-10-01 at 14:05 +0200, Noralf Trønnes wrote: > > Den 01.10.2018 09.56, skrev Alexey Brodkin: > > Hi Noralf, > > > > On Fri, 2018-09-28 at 12:42 +0200, Noralf Trønnes wrote: > > > Den 28.09.2018 09.34, skrev Alexey Brodkin: > > > > Hi Noralf, > > > > > > > > On Sat, 2018-09-08 at 15:46 +0200, Noralf Trønnes wrote: > > > > > The CMA helper is already using the drm_fb_helper_generic_probe part > > > > > of > > > > > the generic fbdev emulation. This patch makes full use of the generic > > > > > fbdev emulation by using its drm_client callbacks. This means that > > > > > drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose > > > > > are > > > > > now handled by the emulation code. Additionally fbdev unregister > > > > > happens > > > > > automatically on drm_dev_unregister(). > > > > > > > > > > The drm_fbdev_generic_setup() call is put after drm_dev_register() in > > > > > the > > > > > driver. This is done to highlight the fact that fbdev emulation is an > > > > > internal client that makes use of the driver, it is not part of the > > > > > driver as such. If fbdev setup fails, an error is printed, but the > > > > > driver > > > > > succeeds probing. > > > > > > > > > > Cc: Alexey Brodkin > > > > > Signed-off-by: Noralf Trønnes > > > > > > > > Thanks for doing that! > > > > Quite some code removed from the driver and still FBDEV emulation works > > > > :) > > > > > > Yeah we're down to one line of code in the driver to get fbdev emulation > > > which is quite nice a think :D > > > > Exactly! > > > > And just to not lose this nice improvement - do I need to pull this through > > my tree or entire series will be merged in main DRM tree? > > I apply the patches to drm-misc-next when I get acks. > Unless the maintainer wants to take it himself. > So, yes I'll apply this one :-) Cool! thanks for doing that! -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/20] drm/arc: Use drm_fbdev_generic_setup()
Hi Noralf, On Fri, 2018-09-28 at 12:42 +0200, Noralf Trønnes wrote: > Den 28.09.2018 09.34, skrev Alexey Brodkin: > > Hi Noralf, > > > > On Sat, 2018-09-08 at 15:46 +0200, Noralf Trønnes wrote: > > > The CMA helper is already using the drm_fb_helper_generic_probe part of > > > the generic fbdev emulation. This patch makes full use of the generic > > > fbdev emulation by using its drm_client callbacks. This means that > > > drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are > > > now handled by the emulation code. Additionally fbdev unregister happens > > > automatically on drm_dev_unregister(). > > > > > > The drm_fbdev_generic_setup() call is put after drm_dev_register() in the > > > driver. This is done to highlight the fact that fbdev emulation is an > > > internal client that makes use of the driver, it is not part of the > > > driver as such. If fbdev setup fails, an error is printed, but the driver > > > succeeds probing. > > > > > > Cc: Alexey Brodkin > > > Signed-off-by: Noralf Trønnes > > > > Thanks for doing that! > > Quite some code removed from the driver and still FBDEV emulation works :) > > Yeah we're down to one line of code in the driver to get fbdev emulation > which is quite nice a think :D Exactly! And just to not lose this nice improvement - do I need to pull this through my tree or entire series will be merged in main DRM tree? -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/20] drm/arc: Use drm_fbdev_generic_setup()
Hi Noralf, On Sat, 2018-09-08 at 15:46 +0200, Noralf Trønnes wrote: > The CMA helper is already using the drm_fb_helper_generic_probe part of > the generic fbdev emulation. This patch makes full use of the generic > fbdev emulation by using its drm_client callbacks. This means that > drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are > now handled by the emulation code. Additionally fbdev unregister happens > automatically on drm_dev_unregister(). > > The drm_fbdev_generic_setup() call is put after drm_dev_register() in the > driver. This is done to highlight the fact that fbdev emulation is an > internal client that makes use of the driver, it is not part of the > driver as such. If fbdev setup fails, an error is printed, but the driver > succeeds probing. > > Cc: Alexey Brodkin > Signed-off-by: Noralf Trønnes Thanks for doing that! Quite some code removed from the driver and still FBDEV emulation works :) Acked-by: Alexey Brodkin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH] drm/arc: Replace drm_dev_unref with drm_dev_put
Hi Thomas, On Wed, 2018-09-26 at 13:33 +0200, Thomas Zimmermann wrote: > This patch unifies the naming of DRM functions for reference counting > of struct drm_device. The resulting code is more aligned with the rest > of the Linux kernel interfaces. Thanks for your clean-up efforts! I'll pick it up to my tree. Acked-by: Alexey Brodkin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/22] drm/arc: Use drm_fb_cma_fbdev_init/fini()
Hi Noralf, On Wed, 2017-11-15 at 15:19 +0100, Noralf Trønnes wrote: > Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on > the fact that drm_device holds a pointer to the drm_fb_helper structure. > This means that the driver doesn't have to keep track of that. > Also use the drm_fb_helper functions directly. > Remove unused function prototype arcpgu_fbdev_cma_init(). > > Cc: Alexey Brodkin > Signed-off-by: Noralf Trønnes Similarly to drm/fsl-dcu driver this one never made it upstream. I was under impression that entire series will be either accepted or not but looks like fixes for separate drivers were pulled via separate trees. Anyways I like this patch for ARC PGU and may confirm it works perfectly fine on top of 4.18.10 so should I pull this into my tree and send a pull-request to David or maybe all not yet accepted patches from the series may go through the same tree? -Alexey And essentially... Acked-by: Alexey Brodkin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/20] drm/arc: Use drm_fbdev_generic_setup()
Hi Noralf, On Sat, 2018-09-08 at 15:46 +0200, Noralf Trønnes wrote: > The CMA helper is already using the drm_fb_helper_generic_probe part of > the generic fbdev emulation. This patch makes full use of the generic > fbdev emulation by using its drm_client callbacks. This means that > drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are > now handled by the emulation code. Additionally fbdev unregister happens > automatically on drm_dev_unregister(). > > The drm_fbdev_generic_setup() call is put after drm_dev_register() in the > driver. This is done to highlight the fact that fbdev emulation is an > internal client that makes use of the driver, it is not part of the > driver as such. If fbdev setup fails, an error is printed, but the driver > succeeds probing. > > Cc: Alexey Brodkin > Signed-off-by: Noralf Trønnes > --- Thanks for making these improvements! I'm wondering what is a base for these changes so that I may try it on my board? Preferably I'd like to get a link to the tag in your git tree with all the prerequisites in place. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/21] udl-kms: avoid prefetch
Hi Mikulas, On Wed, 2018-06-06 at 11:46 -0400, Mikulas Patocka wrote: > > On Wed, 6 Jun 2018, Alexey Brodkin wrote: > > > Hi Mikulas, > > > > On Tue, 2018-06-05 at 11:30 -0400, Mikulas Patocka wrote: > > > > > > On Tue, 5 Jun 2018, Alexey Brodkin wrote: > > > > > > > Hi Mikulas, > > > > > > > > On Sun, 2018-06-03 at 16:41 +0200, Mikulas Patocka wrote: > > > > > Modern processors can detect linear memory accesses and prefetch data > > > > > automatically, so there's no need to use prefetch. > > > > > > > > Not each and every CPU that's capable of running Linux has prefetch > > > > functionality :) > > > > > > > > Still read-on... > > > > > > > > > Signed-off-by: Mikulas Patocka > > > > > > > > > > --- > > > > > drivers/gpu/drm/udl/udl_transfer.c |7 --- > > > > > 1 file changed, 7 deletions(-) > > > > > > > > > > Index: linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c > > > > > === > > > > > --- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_transfer.c > > > > > 2018-05-31 14:48:12.0 +0200 > > > > > +++ linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31 > > > > > 14:48:12.0 +0200 > > > > > @@ -13,7 +13,6 @@ > > > > > #include > > > > > #include > > > > > #include > > > > > -#include > > > > > #include > > > > > > > > > > #include > > > > > @@ -51,9 +50,6 @@ static int udl_trim_hline(const u8 *bbac > > > > > int start = width; > > > > > int end = width; > > > > > > > > > > - prefetch((void *) front); > > > > > - prefetch((void *) back); > > > > > > > > AFAIK prefetcher fetches new data according to a known history... i.e. > > > > based on previously > > > > used pattern we'll trying to get the next batch of data. > > > > > > > > But the code above is in the very beginning of the data processing > > > > routine where > > > > prefetcher doesn't yet have any history to know what and where to > > > > prefetch. > > > > > > > > So I'd say this particular usage is good. > > > > At least those prefetches shouldn't hurt because typically it > > > > would be just 1 instruction if those exist or nothing if CPU/compiler > > > > doesn't > > > > support it. > > > > > > See this post > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_444336_=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl > > > 656e > > > ViXO7breS55ytWkhpk5R81I=a5RaqJtvajFkM1hL7bOKD5jV7cpFfTvG2Y1cYCdBPd0=w0W8wFtAgENp8TE6RzdPGhdKRasJc_otIn08V0EkgrY= > > > where they measured that > > > prefetch hurts performance. Prefetch shouldn't be used unless you have a > > > proof that it improves performance. > > > > > > The problem is that the prefetch instruction causes stalls in the > > > pipeline > > > when it encounters TLB miss and the automatic prefetcher doesn't. > > > > Wow, thanks for the link. > > I didn't know about that subtle issue with prefetch instructions on ARM and > > x86. > > > > So OK in case of UDL these prefetches anyways make not not much sense I > > guess and there's > > something worse still, see what I've got from WandBoard Quad running > > kmscube [1] application > > with help of perf utility: > > --->8- > > # Overhead Command Shared ObjectSymbol > > # ... ... > > > > # > > 92.93% kmscube [kernel.kallsyms][k] udl_render_hline > > 2.51% kmscube [kernel.kallsyms][k] __divsi3 > > 0.33% kmscube [kernel.kallsyms][k] > > _raw_spin_unlock_irqrestore > > 0.22% kmscube [kernel.kallsyms][k] lock_acquire > > 0.19% kmscube [kernel.kallsyms][k] _raw_spin_unlock_irq > > 0.17% kmscube [kernel.kallsyms][k] udl_handle_damage > > 0.12% kmscube [kernel.kallsyms][k] v7_dma_clean_range > > 0.11% kmscube [kernel.kallsyms]
Re: [PATCH 08/21] udl-kms: avoid prefetch
Hi Mikulas, On Tue, 2018-06-05 at 11:30 -0400, Mikulas Patocka wrote: > > On Tue, 5 Jun 2018, Alexey Brodkin wrote: > > > Hi Mikulas, > > > > On Sun, 2018-06-03 at 16:41 +0200, Mikulas Patocka wrote: > > > Modern processors can detect linear memory accesses and prefetch data > > > automatically, so there's no need to use prefetch. > > > > Not each and every CPU that's capable of running Linux has prefetch > > functionality :) > > > > Still read-on... > > > > > Signed-off-by: Mikulas Patocka > > > > > > --- > > > drivers/gpu/drm/udl/udl_transfer.c |7 --- > > > 1 file changed, 7 deletions(-) > > > > > > Index: linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c > > > === > > > --- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31 > > > 14:48:12.0 +0200 > > > +++ linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31 > > > 14:48:12.0 +0200 > > > @@ -13,7 +13,6 @@ > > > #include > > > #include > > > #include > > > -#include > > > #include > > > > > > #include > > > @@ -51,9 +50,6 @@ static int udl_trim_hline(const u8 *bbac > > > int start = width; > > > int end = width; > > > > > > - prefetch((void *) front); > > > - prefetch((void *) back); > > > > AFAIK prefetcher fetches new data according to a known history... i.e. > > based on previously > > used pattern we'll trying to get the next batch of data. > > > > But the code above is in the very beginning of the data processing routine > > where > > prefetcher doesn't yet have any history to know what and where to prefetch. > > > > So I'd say this particular usage is good. > > At least those prefetches shouldn't hurt because typically it > > would be just 1 instruction if those exist or nothing if CPU/compiler > > doesn't > > support it. > > See this post > https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_444336_=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656e > ViXO7breS55ytWkhpk5R81I=a5RaqJtvajFkM1hL7bOKD5jV7cpFfTvG2Y1cYCdBPd0=w0W8wFtAgENp8TE6RzdPGhdKRasJc_otIn08V0EkgrY= > where they measured that > prefetch hurts performance. Prefetch shouldn't be used unless you have a > proof that it improves performance. > > The problem is that the prefetch instruction causes stalls in the pipeline > when it encounters TLB miss and the automatic prefetcher doesn't. Wow, thanks for the link. I didn't know about that subtle issue with prefetch instructions on ARM and x86. So OK in case of UDL these prefetches anyways make not not much sense I guess and there's something worse still, see what I've got from WandBoard Quad running kmscube [1] application with help of perf utility: --->8- # Overhead Command Shared ObjectSymbol # ... ... # 92.93% kmscube [kernel.kallsyms][k] udl_render_hline 2.51% kmscube [kernel.kallsyms][k] __divsi3 0.33% kmscube [kernel.kallsyms][k] _raw_spin_unlock_irqrestore 0.22% kmscube [kernel.kallsyms][k] lock_acquire 0.19% kmscube [kernel.kallsyms][k] _raw_spin_unlock_irq 0.17% kmscube [kernel.kallsyms][k] udl_handle_damage 0.12% kmscube [kernel.kallsyms][k] v7_dma_clean_range 0.11% kmscube [kernel.kallsyms][k] l2c210_clean_range 0.06% kmscube [kernel.kallsyms][k] __memzero --->8- That said it's not even USB 2.0 which is a bottle-neck but computations in the udl_render_hline(). [1] https://cgit.freedesktop.org/mesa/kmscube/ -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/21] udl-kms: avoid prefetch
Hi Mikulas,
On Sun, 2018-06-03 at 16:41 +0200, Mikulas Patocka wrote:
> Modern processors can detect linear memory accesses and prefetch data
> automatically, so there's no need to use prefetch.
Not each and every CPU that's capable of running Linux has prefetch
functionality :)
Still read-on...
> Signed-off-by: Mikulas Patocka
>
> ---
> drivers/gpu/drm/udl/udl_transfer.c |7 ---
> 1 file changed, 7 deletions(-)
>
> Index: linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c
> ===
> --- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31
> 14:48:12.0 +0200
> +++ linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c 2018-05-31
> 14:48:12.0 +0200
> @@ -13,7 +13,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #include
> @@ -51,9 +50,6 @@ static int udl_trim_hline(const u8 *bbac
> int start = width;
> int end = width;
>
> - prefetch((void *) front);
> - prefetch((void *) back);
AFAIK prefetcher fetches new data according to a known history... i.e. based on
previously
used pattern we'll trying to get the next batch of data.
But the code above is in the very beginning of the data processing routine where
prefetcher doesn't yet have any history to know what and where to prefetch.
So I'd say this particular usage is good.
At least those prefetches shouldn't hurt because typically it
would be just 1 instruction if those exist or nothing if CPU/compiler doesn't
support it.
> for (j = 0; j < width; j++) {
> if (back[j] != front[j]) {
> start = j;
> @@ -140,8 +136,6 @@ static void udl_compress_hline16(
> const u8 *cmd_pixel_start, *cmd_pixel_end = NULL;
> uint16_t pixel_val16;
>
> - prefetchw((void *) cmd); /* pull in one cache line at least */
> -
Pretty much the same is here. Obviously on the first iteration prefetcher dosn't
know where to get "cmd". On the next iterations it might be better but given
amount
of operation happens further in the cycle (and in inner cycles) I won't be
completely
sure that each and every prefetcher will still keep track of "cmd".
> *cmd++ = 0xaf;
> *cmd++ = 0x6b;
> *cmd++ = (uint8_t) ((dev_addr >> 16) & 0xFF);
> @@ -158,7 +152,6 @@ static void udl_compress_hline16(
> (unsigned long)(pixel_end - pixel) >>
> log_bpp,
> (unsigned long)(cmd_buffer_end - 1 -
> cmd) / 2) << log_bpp);
>
> - prefetch_range((void *) pixel, cmd_pixel_end - pixel);
Again I'm not sure what we gain removing that code in comparison of possible
performance degradation on simpler CPUs.
And essentially all the same is applicable to UDLFB patch.
-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/21] USB DisplayLink patches
Hi Mikulas, On Sun, 2018-06-03 at 16:40 +0200, Mikulas Patocka wrote: > Hi > > Here I'm sending bug fixes and performance improvements for the USB > DisplayLink framebuffer and modesetting drivers for this merge window. For such a long series it would be very nice to post a link to your git tree so people may play with your changes easily. Could you please prepare one? -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Print unadorned pointers
On Wed, 2018-04-18 at 11:29 +0200, Maarten Lankhorst wrote:
> Op 18-04-18 om 11:24 schreef Alexey Brodkin:
> > After commit ad67b74 ("printk: hash addresses printed with %p")
> > pointers are being hashed when printed. However, this makes
> > debug output completely useless. Switch to %px in order to see the
> > unadorned kernel pointers.
> >
> > This was done with the following one-liner:
> > find drivers/gpu/drm -type f -name "*.c" -exec sed -r -i
> > '/DRM_DEBUG|KERN_DEBUG|pr_debug/ s/%p\b/%px/g' {} +
>
> So first we plug a kernel information leak hole, then we introduce it again?
> Seems like a terrible idea..
Well security concerns are good but what about us poor kernel developers?
Those debug prints are supposed to help us to deal with stuff we develop or fix.
Frankly I was quite surprised when first saw what was "unique hashed ID" instead
of real pointer value. And what's worse there's no way to get previous behavior
back.
So now we have to manually patch sources here and there to get meaningful data,
right?
I wouldn't bother sending this patch if there was Kconfig option reverting %p
behavior
but that was never implemented.
-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Print unadorned pointers
After commit ad67b74 ("printk: hash addresses printed with %p")
pointers are being hashed when printed. However, this makes
debug output completely useless. Switch to %px in order to see the
unadorned kernel pointers.
This was done with the following one-liner:
find drivers/gpu/drm -type f -name "*.c" -exec sed -r -i
'/DRM_DEBUG|KERN_DEBUG|pr_debug/ s/%p\b/%px/g' {} +
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Borislav Petkov <b...@suse.de>
Cc: Tobin C. Harding <m...@tobin.cc>
Cc: Alex Deucher <alexander.deuc...@amd.com>
Cc: Andrey Grodzovsky <andrey.grodzov...@amd.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Benjamin Gaignard <benjamin.gaign...@linaro.org>
Cc: Chen-Yu Tsai <w...@csie.org>
Cc: Christian Gmeiner <christian.gmei...@gmail.com>
Cc: "Christian König" <christian.koe...@amd.com>
Cc: Cihangir Akturk <cakt...@gmail.com>
Cc: CK Hu <ck...@mediatek.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Dave Airlie <airl...@redhat.com>
Cc: David Airlie <airl...@linux.ie>
Cc: "David (ChunMing) Zhou" <david1.z...@amd.com>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Gustavo Padovan <gust...@padovan.org>
Cc: Harry Wentland <harry.wentl...@amd.com>
Cc: "Heiko Stübner" <he...@sntech.de>
Cc: Ingo Molnar <mi...@kernel.org>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: "Jerry (Fangzhi) Zuo" <jerry@amd.com>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Cc: Krzysztof Kozlowski <k...@kernel.org>
Cc: "Leo (Sunpeng) Li" <sunpeng...@amd.com>
Cc: Lucas Stach <l.st...@pengutronix.de>
Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Cc: Matthias Brugger <matthias@gmail.com>
Cc: Maxime Ripard <maxime.rip...@bootlin.com>
Cc: "Michel Dänzer" <michel.daen...@amd.com>
Cc: Oded Gabbay <oded.gab...@gmail.com>
Cc: Philipp Zabel <p.za...@pengutronix.de>
Cc: Rob Clark <robdcl...@gmail.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: Roger He <hongbo...@amd.com>
Cc: Roman Li <roman...@amd.com>
Cc: Russell King <li...@armlinux.org.uk>
Cc: Samuel Li <samuel...@amd.com>
Cc: Sandy Huang <h...@rock-chips.com>
Cc: Sean Paul <seanp...@chromium.org>
Cc: Shirish S <shiris...@amd.com>
Cc: Sinclair Yeh <s...@vmware.com>
Cc: Thomas Hellstrom <thellst...@vmware.com>
Cc: Tom Lendacky <thomas.lenda...@amd.com>
Cc: Tony Cheng <tony.ch...@amd.com>
Cc: Vincent Abriou <vincent.abr...@st.com>
Cc: VMware Graphics <linux-graphics-maintai...@vmware.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: etna...@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 14 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 4 +-
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 +-
drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c| 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 10 ++---
drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 4 +-
drivers/gpu/drm/amd/amdkfd/kfd_events.c| 4 +-
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 4 +-
drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 18 -
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 2 +-
drivers/gpu/drm/armada/armada_gem.c| 12 +++---
drivers/gpu/drm/drm_atomic.c | 44 +++---
drivers/gpu/drm/drm_bufs.c | 8 ++--
drivers/gpu/drm/drm_dp_mst_topology.c | 4 +-
drivers/gpu/drm/drm_lease.c| 6 +--
drivers/gpu/drm/drm_lock.c | 2 +-
drivers/gpu/drm/drm_scatter.c | 4 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 +--
drivers/gpu/drm/i810/i810_dma.c| 2 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_guc_ct.c| 4 +-
drivers/gpu/drm/i915/intel_guc_submission.c| 2 +-
drivers/gpu/drm/i915/intel_uc_fw.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +-
drivers/gpu/drm/mga/mga_warp.c | 2 +-
drivers/gpu/drm/msm/msm_drv.c | 4 +-
drivers/gpu/dr
Re: DRM_UDL and GPU under Xserver
Hi Daniel, On Mon, 2018-04-09 at 11:17 +0200, Daniel Vetter wrote: > On Mon, Apr 09, 2018 at 08:55:36AM +0000, Alexey Brodkin wrote: > > Hi Daniel, > > > > On Mon, 2018-04-09 at 10:31 +0200, Daniel Vetter wrote: > > > On Thu, Apr 05, 2018 at 06:39:41PM +, Alexey Brodkin wrote: > > > > Hi Daniel, all, > > > > [snip] > > > > > > Ok it was quite some time ago so I forgot about that completely. > > > > I really made one trivial change in xf86-video-armada: > > > > >8-- > > > > --- a/src/armada_module.c > > > > +++ b/src/armada_module.c > > > > @@ -26,7 +26,7 @@ > > > > #define ARMADA_NAME"armada" > > > > #define ARMADA_DRIVER_NAME "armada" > > > > > > > > -#define DRM_MODULE_NAMES "armada-drm", "imx-drm" > > > > +#define DRM_MODULE_NAMES "armada-drm", "imx-drm", "udl" > > > > #define DRM_DEFAULT_BUS_ID NULL > > > > >8-- > > > > > > > > Otherwise Xserver fails on start which is expected given "imx-drm" is > > > > intentionally removed. > > > > Here I meant I explicitly disabled DRM_IMX in the kernel configuraion > > so that it is not used in run-time. > > > > > You need to keep imx-drm around. And then light up the udl display using > > > prime. Afaiui it should all just work (but with maybe a few disconnected > > > outputs from imx-drm around that you don't need, but that's not a > > > problem). > > > > And given my comment above I don't really see any difference between > > DRM_IMX and DRM_UDL (except their HW implmentation which I guess should > > not bother upper layers) so why do wee need to treat them differently? > > > > Most probably I'm missing something but my thought was if we have > > 2 equally well supported KMS devices we may easily swap them and still > > have resulting setup functional. > > armada is not a generic drm driver, but can only be used for armada-drm > and imx-drm. You can't just use it with any drm device, for that you need > a generic driver like -modesetting. But "armada" is the name of xf86 "driver" only which then uses true DRM_ETNAVIV kernel driver. That's why I'm a bit confused. And from what I see DRM_ETNAVIV happily works with either DRM_xxx frame-buffer device be it DRM_IMX or DRM_UDL. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM_UDL and GPU under Xserver
Hi Daniel, On Mon, 2018-04-09 at 10:31 +0200, Daniel Vetter wrote: > On Thu, Apr 05, 2018 at 06:39:41PM +0000, Alexey Brodkin wrote: > > Hi Daniel, all, [snip] > > Ok it was quite some time ago so I forgot about that completely. > > I really made one trivial change in xf86-video-armada: > > >8-- > > --- a/src/armada_module.c > > +++ b/src/armada_module.c > > @@ -26,7 +26,7 @@ > > #define ARMADA_NAME"armada" > > #define ARMADA_DRIVER_NAME "armada" > > > > -#define DRM_MODULE_NAMES "armada-drm", "imx-drm" > > +#define DRM_MODULE_NAMES "armada-drm", "imx-drm", "udl" > > #define DRM_DEFAULT_BUS_ID NULL > > >8-- > > > > Otherwise Xserver fails on start which is expected given "imx-drm" is > > intentionally removed. Here I meant I explicitly disabled DRM_IMX in the kernel configuraion so that it is not used in run-time. > You need to keep imx-drm around. And then light up the udl display using > prime. Afaiui it should all just work (but with maybe a few disconnected > outputs from imx-drm around that you don't need, but that's not a > problem). And given my comment above I don't really see any difference between DRM_IMX and DRM_UDL (except their HW implmentation which I guess should not bother upper layers) so why do wee need to treat them differently? Most probably I'm missing something but my thought was if we have 2 equally well supported KMS devices we may easily swap them and still have resulting setup functional. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/arc: Stop consulting plane->fb
Hi Ville, On Thu, 2018-04-05 at 22:50 +0300, Ville Syrjala wrote: > From: Ville Syrjälä <ville.syrj...@linux.intel.com> > > We want to stop using plane->fb with atomic driver, so stop looking at > it. > > I have no idea what this code is trying to achieve. There is no > corresponding check in the enable path. Also since > arc_pgu_set_pxl_fmt() will anyway oops if there is no fb I'm going > to assuming that I can just remove the check entirely. There seems > to be a general shortage of .atomic_check() in this driver... > > Cc: Alexey Brodkin <abrod...@synopsys.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com> Acked-by: Alexey Brodkin <abrod...@synopys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM_UDL and GPU under Xserver
Hi Daniel, Lucas, On Thu, 2018-04-05 at 12:59 +0200, Daniel Vetter wrote: > On Thu, Apr 5, 2018 at 12:29 PM, Lucas Stach <l.st...@pengutronix.de> wrote: > > Am Donnerstag, den 05.04.2018, 11:32 +0200 schrieb Daniel Vetter: > > > On Thu, Apr 5, 2018 at 9:16 AM, Alexey Brodkin > > > <alexey.brod...@synopsys.com> wrote: > > > > Hi Daniel, > > > > > > > > On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote: > > > > > On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin > > > > > <alexey.brod...@synopsys.com> wrote: > > > > > > Hello, > > > > > > > > > > > > We're trying to use DisplayLink USB2-to-HDMI adapter to render > > > > > > GPU-accelerated graphics. > > > > > > Hardware setup is as simple as a devboard + DisplayLink > > > > > > adapter. > > > > > > Devboards we use for this experiment are: > > > > > > * Wandboard Quad (based on IMX6 SoC with Vivante GPU) or > > > > > > * HSDK (based on Synopsys ARC HS38 SoC with Vivante GPU as > > > > > > well) > > > > > > > > > > > > I'm sure any other board with DRM supported GPU will work, > > > > > > those we just used > > > > > > as the very recent Linux kernels could be easily run on them > > > > > > both. > > > > > > > > > > > > Basically the problem is UDL needs to be explicitly notified > > > > > > about new data > > > > > > to be rendered on the screen compared to typical bit-streamers > > > > > > that infinitely > > > > > > scan a dedicated buffer in memory. > > > > > > > > > > > > In case of UDL there're just 2 ways for this notification: > > > > > > 1) DRM_IOCTL_MODE_PAGE_FLIP that calls drm_crtc_funcs- > > > > > > > page_flip() > > > > > > > > > > > > 2) DRM_IOCTL_MODE_DIRTYFB that calls drm_framebuffer_funcs- > > > > > > > dirty() > > > > > > > > > > > > But neither of IOCTLs happen when we run Xserver with xf86- > > > > > > video-armada driver > > > > > > (see https://urldefense.proofpoint.com/v2/url?u=http-3A__git.ar > > > > > > m.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh- > > > > > > 3Dunstable-2Ddevel=DwIBaQ&; > > > > > > c=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkh > > > > > > pk5R81I=oEAlP64L9vkuUs_k3kGwwwlN1WJbDMJbCo0uDhwKwwk=3ZHj- > > > > > > 6JXZBLSTWg_4KMnL0VNi7z8c0RxHzj2U5ywVIw=). > > > > > > > > > > > > Is it something missing in Xserver or in UDL driver? > > > > > > > > > > Use the -modesetting driverr for UDL, that one works correctly. > > > > > > > > If you're talking about "modesetting" driver of Xserver [1] then > > > > indeed > > > > picture is displayed on the screen. But there I guess won't be any > > > > 3D acceleration. > > > > > > > > At least that's what was suggested to me earlier here [2] by Lucas: > > > > >8--- > > > > For 3D acceleration to work under X you need the etnaviv specific > > > > DDX > > > > driver, which can be found here: > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.arm.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-3Dunsta=DwIBaQ=DPL6_X_6Jk > > > > XFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=FleDFAQb2lBcZk5DMld7qpeSrB5Srsb4XPQecA5BPvU=YUzMQWe3lpC_pjGqRjb4MvRYh16ZBbealqf > > > > rywlqjKE= > > > > ble-devel > > > > > > You definitely want to use -modesetting for UDL. And I thought with > > > glamour and the corresponding mesa work you should also get > > > accelaration. Insisting that you must use a driver-specific ddx is > > > broken, the world doesn't work like that anymore. > > > > On etnaviv the world definitely still works like this. The etnaviv DDX > > uses the dedicated 2D hardware of the Vivante GPUs, which is much > > faster and efficient than going through Glamor. > > Especially since almost all X accel operations are done on linear > > buffers, while the 3D GPU can only ever do tiled on both sampler and > > render, where some multi-p
Re: DRM_UDL and GPU under Xserver
Hi Daniel, all, On Thu, 2018-04-05 at 15:44 +0200, Daniel Vetter wrote: > On Thu, Apr 05, 2018 at 11:10:03AM +0000, Alexey Brodkin wrote: > > Hi Daniel, Lucas, > > > > On Thu, 2018-04-05 at 12:59 +0200, Daniel Vetter wrote: > > > On Thu, Apr 5, 2018 at 12:29 PM, Lucas Stach <l.st...@pengutronix.de> > > > wrote: > > > > Am Donnerstag, den 05.04.2018, 11:32 +0200 schrieb Daniel Vetter: > > > > > On Thu, Apr 5, 2018 at 9:16 AM, Alexey Brodkin > > > > > <alexey.brod...@synopsys.com> wrote: > > > > > > Hi Daniel, > > > > > > > > > > > > On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote: > > > > > > > On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin > > > > > > > <alexey.brod...@synopsys.com> wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > We're trying to use DisplayLink USB2-to-HDMI adapter to render > > > > > > > > GPU-accelerated graphics. > > > > > > > > Hardware setup is as simple as a devboard + DisplayLink > > > > > > > > adapter. > > > > > > > > Devboards we use for this experiment are: > > > > > > > > * Wandboard Quad (based on IMX6 SoC with Vivante GPU) or > > > > > > > > * HSDK (based on Synopsys ARC HS38 SoC with Vivante GPU as > > > > > > > > well) > > > > > > > > > > > > > > > > I'm sure any other board with DRM supported GPU will work, > > > > > > > > those we just used > > > > > > > > as the very recent Linux kernels could be easily run on them > > > > > > > > both. > > > > > > > > > > > > > > > > Basically the problem is UDL needs to be explicitly notified > > > > > > > > about new data > > > > > > > > to be rendered on the screen compared to typical bit-streamers > > > > > > > > that infinitely > > > > > > > > scan a dedicated buffer in memory. > > > > > > > > > > > > > > > > In case of UDL there're just 2 ways for this notification: > > > > > > > > 1) DRM_IOCTL_MODE_PAGE_FLIP that calls drm_crtc_funcs- > > > > > > > > > page_flip() > > > > > > > > > > > > > > > > 2) DRM_IOCTL_MODE_DIRTYFB that calls drm_framebuffer_funcs- > > > > > > > > > dirty() > > > > > > > > > > > > > > > > But neither of IOCTLs happen when we run Xserver with xf86- > > > > > > > > video-armada driver > > > > > > > > (see https://urldefense.proofpoint.com/v2/url?u=http-3A__git.ar > > > > > > > > m.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh- > > > > > > > > 3Dunstable-2Ddevel=DwIBaQ&; > > > > > > > > c=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkh > > > > > > > > pk5R81I=oEAlP64L9vkuUs_k3kGwwwlN1WJbDMJbCo0uDhwKwwk=3ZHj- > > > > > > > > 6JXZBLSTWg_4KMnL0VNi7z8c0RxHzj2U5ywVIw=). > > > > > > > > > > > > > > > > Is it something missing in Xserver or in UDL driver? > > > > > > > > > > > > > > Use the -modesetting driverr for UDL, that one works correctly. > > > > > > > > > > > > If you're talking about "modesetting" driver of Xserver [1] then > > > > > > indeed > > > > > > picture is displayed on the screen. But there I guess won't be any > > > > > > 3D acceleration. > > > > > > > > > > > > At least that's what was suggested to me earlier here [2] by Lucas: > > > > > > >8--- > > > > > > For 3D acceleration to work under X you need the etnaviv specific > > > > > > DDX > > > > > > driver, which can be found here: > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.arm.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-3Dunsta=DwIBaQ=DPL6_X > > > > > > _6Jk > > > > > > XFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=FleDFAQb2lBcZk5DMld7qpeSrB
Re: DRM_UDL and GPU under Xserver
Hi Daniel, On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote: > On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin > <alexey.brod...@synopsys.com> wrote: > > Hello, > > > > We're trying to use DisplayLink USB2-to-HDMI adapter to render > > GPU-accelerated graphics. > > Hardware setup is as simple as a devboard + DisplayLink adapter. > > Devboards we use for this experiment are: > > * Wandboard Quad (based on IMX6 SoC with Vivante GPU) or > > * HSDK (based on Synopsys ARC HS38 SoC with Vivante GPU as well) > > > > I'm sure any other board with DRM supported GPU will work, those we just > > used > > as the very recent Linux kernels could be easily run on them both. > > > > Basically the problem is UDL needs to be explicitly notified about new data > > to be rendered on the screen compared to typical bit-streamers that > > infinitely > > scan a dedicated buffer in memory. > > > > In case of UDL there're just 2 ways for this notification: > > 1) DRM_IOCTL_MODE_PAGE_FLIP that calls drm_crtc_funcs->page_flip() > > 2) DRM_IOCTL_MODE_DIRTYFB that calls drm_framebuffer_funcs->dirty() > > > > But neither of IOCTLs happen when we run Xserver with xf86-video-armada > > driver > > (see > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.arm.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-3Dunstable-2Ddevel=DwIBaQ; > > c=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=oEAlP64L9vkuUs_k3kGwwwlN1WJbDMJbCo0uDhwKwwk=3ZHj- > > 6JXZBLSTWg_4KMnL0VNi7z8c0RxHzj2U5ywVIw=). > > > > Is it something missing in Xserver or in UDL driver? > > Use the -modesetting driverr for UDL, that one works correctly. If you're talking about "modesetting" driver of Xserver [1] then indeed picture is displayed on the screen. But there I guess won't be any 3D acceleration. At least that's what was suggested to me earlier here [2] by Lucas: >8--- For 3D acceleration to work under X you need the etnaviv specific DDX driver, which can be found here: http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/log/?h=unstable-devel >8--- [1] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/drivers/modesetting [2] http://lists.infradead.org/pipermail/linux-snps-arc/2017-November/003031.html -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
DRM_UDL and GPU under Xserver
Hello, We're trying to use DisplayLink USB2-to-HDMI adapter to render GPU-accelerated graphics. Hardware setup is as simple as a devboard + DisplayLink adapter. Devboards we use for this experiment are: * Wandboard Quad (based on IMX6 SoC with Vivante GPU) or * HSDK (based on Synopsys ARC HS38 SoC with Vivante GPU as well) I'm sure any other board with DRM supported GPU will work, those we just used as the very recent Linux kernels could be easily run on them both. Basically the problem is UDL needs to be explicitly notified about new data to be rendered on the screen compared to typical bit-streamers that infinitely scan a dedicated buffer in memory. In case of UDL there're just 2 ways for this notification: 1) DRM_IOCTL_MODE_PAGE_FLIP that calls drm_crtc_funcs->page_flip() 2) DRM_IOCTL_MODE_DIRTYFB that calls drm_framebuffer_funcs->dirty() But neither of IOCTLs happen when we run Xserver with xf86-video-armada driver (see http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/log/?h=unstable-devel). Is it something missing in Xserver or in UDL driver? Regards, Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/arcpgu: remove drm_encoder_slave
Hi Daniel, On Tue, 2018-01-30 at 10:15 +0100, Daniel Vetter wrote: > On Wed, Jan 17, 2018 at 03:17:55PM +0100, Daniel Vetter wrote: > > drm_encoder_slave is the old way to write bridge drivers, for i2c > > bridges only. It's deprecated, and definitely should not be used in > > new drivers. This has absolutely nothing to do with the new bridge > > driver infrastructure implemented by drm_bridge. > > > > What's even strange is that arcpgu doesn't even use any of this, it > > really only wants a plain normal drm_encoder. Nuke all the surplus > > real estate. > > > > v2: Actually git add after compile testing ... > > > > v3: Clarify commit message and stop including drm_encoder_slave.h. > > > > Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > > Cc: Alexey Brodkin <abrod...@synopsys.com> > > Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > > I assumed this is ok and applied it to drm-misc-next. > -Daniel Not sure but I still cannot see anything arcpgu-related here https://cgit.freedesktop.org/drm-misc/log/ Am I looking at the wrong place? -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/arcpgu: remove drm_encoder_slave
Hi Daniel, On Tue, 2018-01-30 at 18:07 +0100, Daniel Vetter wrote: > On Tue, Jan 30, 2018 at 5:44 PM, Alexey Brodkin > <alexey.brod...@synopsys.com> wrote: > > Hi Daniel, > > > > On Tue, 2018-01-30 at 10:15 +0100, Daniel Vetter wrote: > > > On Wed, Jan 17, 2018 at 03:17:55PM +0100, Daniel Vetter wrote: > > > > drm_encoder_slave is the old way to write bridge drivers, for i2c > > > > bridges only. It's deprecated, and definitely should not be used in > > > > new drivers. This has absolutely nothing to do with the new bridge > > > > driver infrastructure implemented by drm_bridge. > > > > > > > > What's even strange is that arcpgu doesn't even use any of this, it > > > > really only wants a plain normal drm_encoder. Nuke all the surplus > > > > real estate. > > > > > > > > v2: Actually git add after compile testing ... > > > > > > > > v3: Clarify commit message and stop including drm_encoder_slave.h. > > > > > > > > Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > > > > Cc: Alexey Brodkin <abrod...@synopsys.com> > > > > Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > > > > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > > > > > > I assumed this is ok and applied it to drm-misc-next. > > > -Daniel > > > > Not sure but I still cannot see anything arcpgu-related here > > https://urldefense.proofpoint.com/v2/url?u=https-3A__cgit.freedesktop.org_drm-2Dmisc_log_=DwIBaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656e > > ViXO7breS55ytWkhpk5R81I=ZsFKo3w8gSf8Ul8_sl5RG8BACV1SwqgPV3wf6m4YtVM=f9P3-3L_o6CCd_1IQjGPNtAPAOtlO8rj2D2X8T5v_xw= > > > > Am I looking at the wrong place? > > Build test script got stuck, pushed for real now. Thanks! Gave it a try and it works perfectly fine. If it still makes any sense... Acked-by: Alexey Brodkin <abrod...@synopsys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/12] Cargo cult cleanup in atomic drivers
Hi Laurent, On Wed, 2018-01-17 at 23:55 +0200, Laurent Pinchart wrote: > Hello, > > This patch series removes a few cargo-cult constructs from a set of atomic > drivers. > > Patches 01/12 and 02/12 remove the unneeded .mode_set() and .mode_set_base() > CRTC handlers from the arc and atmel-hlcdc drivers. > > Patches 03/12 to 12/12 then remove the use of drm_plane_helper_disable() from > the plane .destroy() handlers of atomic drivers, replacing them with the use > of drm_atomic_helper_shutdown() at removal time. Interleaved there are patches > 04/12 and 06/12 that remove unnecessary cleanups in error paths, and patch > 09/12 that adds missing cleanup. > > All this has been compile-tested only. I'd like to test it on ARC boards and so wondering if there's a git tree with these patches so I'm not missing any prerequisites or maybe you may specify what should be used as a base for the series? -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/arcpgu: remove drm_encoder_slave
Hi Daniel, On Wed, 2018-01-17 at 14:43 +0100, Daniel Vetter wrote: > drm_encoder_slave is the old way to write bridge drivers, for i2c > bridges only. It's deprecated, and definitely should not be used in > new drivers. > > What's even strange is that arcpgu doesn't even use any of this, it > really only wants a plain normal drm_encoder. Nuke all the surplus > real estate. As of today we use either use adv7511 encoder or dw-hdmi. And I guess proposed change is OK for both bridge versions, rigth? -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: UDL's fbdev doesn't work for user-space apps
Hi Noralf, On Tue, 2017-12-12 at 22:58 +0100, Noralf Trønnes wrote: > Den 04.12.2017 12.32, skrev Alexey Brodkin: > > Hello, > > > > I'm trying to use DisplayLink USB2.0-to-HDMI adapter as the one and only > > video output and I want to get Xserver working on top of that. > > > > I'm not very familiar with all the parts of Linux GPU/video stack > > (especially its user-space counterpart) so my assumptions might be wrong > > in that case please correct me. > > > > My first [probably incorrect] assumption is Xserver requires fbdev > > (/dev/fbX) > > and it cannot use DRI video card natively. Is that correct? > > > > So to get /ded/fb0 with UDL I just enabled CONFIG_DRM_UDL & > > CONFIG_DRM_FBDEV_EMULATION. > > That gave me boot console on HDMI screen and I was full of expectations. > > But when I tried to use /dev/fb0 from whatever user-space app nothing got > > displayed on the screen... as well as no error messages appeared. > > > > After eyeballing at UDL code (especially in comparison with QXC which uses > > deferredio > > as well) I noticed that in UDL fb_deferred_io_init() is called from > > udl_fb_open(), > > i.e. .fb_open call-back (in other words every time user-space app opens > > /dev/fb0) > > while in QXC this is done only once and much earlier in qxlfb_create(), > > which is > > called with .fb_probe call-back. So moved fb_deferred_io_init() in UDL > > driver from > > udl_fb_open() to udlfb_create() which is also called from .fb_probe. > > > > With that change I finally got video output via fbdev from user-space app, > > but only on the first run. The next attempt to run inevitably ends with > > kernel crash showing the following stack-trace (having half of the new > > screen > > rendered on display): > > >8- > > Stack Trace: > >udl_handle_damage+0x48/0x210 > >udl_crtc_mode_set+0x6ee/0x754 > >drm_crtc_helper_set_mode+0x25e/0x438 > >drm_crtc_helper_set_config+0x6d6/0x814 > >__drm_mode_set_config_internal+0x48/0xc8 > >drm_mode_setcrtc+0x320/0x478 > >drm_ioctl+0x22c/0x3e4 > >SyS_ioctl+0xa4/0x8cc > >EV_Trap+0x108/0x10c > > random: crng init done > > >8- > > > > I'm wondering if UDL driver (its DRM flavor) was ever tested for > > fbdev in user-space? If so and it really works for somebody > > maybe I'm doing something terribly wrong - in that case any comments > > are very welcome. > > udl uses shmem buffers which doesn't work with fbdev deferred io. > They fight over page->lru and page->mapping. See this commit: > drm/udl: disable fb_defio by default > 677d23b70bf949f75746c80cbae92c233c6b5e2a Well that's interesting indeed, but IMHO that's not the most important problem with UDL as of now since DRI-aware apps and Xserver stuff work fine with /dev/dri/cardX. What bothers me is some problem [probably] with export of its DMA buffers, so Vivante GPU does render stuff but it is not displayed on the screen... in absense of error messages I'd conclude that the GPU just renders to some virtuall addresses which are not mapped to UDL's "frame-buffers". And it's not about improper handling of caches - I tried with data caches disabled but still to no avail :( -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: UDL's fbdev doesn't work for user-space apps
Hi Pavel, On Sat, 2017-12-09 at 18:20 +0100, Pavel Machek wrote: > On Mon 2017-12-04 11:50:40, Jose Abreu wrote: > > > > Hi Alexey, > > > > On 04-12-2017 11:32, Alexey Brodkin wrote: > > > > > > My first [probably incorrect] assumption is Xserver requires fbdev > > > (/dev/fbX) > > > and it cannot use DRI video card natively. Is that correct? > > > > > > > > > > Xserver can use DRI directly, you need to enable modesetting > > driver in Xorg config or use the designated driver for your card > > (if there is any). > > Still, dev/fb1 should work. Agree, but it doesn't :) Even on completely different architectures (ARC and ARM). > Can be tested using dd, even :-) Most probably so but not in case of UDL as of today :( I mean as long as it does't work dd etc make no sense. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
Hi Jose, On Tue, 2017-12-05 at 10:39 +, Jose Abreu wrote: > Hi Alexey, > > On 04-12-2017 17:29, Alexey Brodkin wrote: > > > > > > Indeed, in case of kmscube etnaviv is a renderer while UDL > > outputs the picture on the screen. > > Thats nice :) > > Ok, from your logs I was not able to see anything wrong. X server > does not error exit and Prime seems to be working in DRM ... > > Lets try one more thing: Enable all debug in DRM (drm.debug=0x3f) > and try to correlate the log with the actions. i.e. > > [boot] > [log] > [x start] > [log] > [xclock start] > [log] > [glmark2-es2 start] > [log] I think I have something like that. Below are extracts which show at least one difference I was able to find. And that difference is presence of "[drm:udl_drm_gem_mmap] flags = 0x1" in case of Xserver only. kmscube: -->8--- [drm:drm_crtc_helper_set_config] encoder changed, full mode switch [drm:drm_crtc_helper_set_config] crtc changed, full mode switch [drm:drm_crtc_helper_set_config] [CONNECTOR:30:DVI-I-1] to [CRTC:28:crtc-0] [drm:drm_crtc_helper_set_config] attempting to set mode from userspace [drm:drm_mode_debug_printmodeline] Modeline 44:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 [drm:drm_crtc_helper_set_mode] [CRTC:28:crtc-0] [drm:drm_crtc_helper_set_mode] [ENCODER:29:TMDS-29] set [MODE:44:1920x1080] [drm] write mode info 153 [drm:drm_crtc_helper_set_config] Setting connector DPMS state to on [drm:drm_crtc_helper_set_config][CONNECTOR:30:DVI-I-1] set DPMS on [drm:udl_attach_dma_buf] [DEV:soc:gpu-subsystem] size:8355840 [drm:udl_map_dma_buf] [DEV:soc:gpu-subsystem] size:8355840 dir=0 etnaviv-gpu f009.gpu: virt 7104 phys 0x free 0x1ec0 stream link to 0x00a8 @ 0x2000 71042000 -->8--- X: -->8--- [drm:udl_drm_gem_mmap] flags = 0x1 [drm:drm_mode_addfb] [FB:43] [drm:drm_mode_setcrtc] [CRTC:28:crtc-0] [drm:drm_mode_setcrtc] [CONNECTOR:30:DVI-I-1] [drm:drm_crtc_helper_set_config] [drm:drm_crtc_helper_set_config] [CRTC:28:crtc-0] [FB:43] #connectors=1 (x y) (0 0) [drm:drm_crtc_helper_set_config] crtc has no fb, full mode set [drm:drm_crtc_helper_set_config] connector dpms not on, full mode switch [drm:drm_crtc_helper_set_config] encoder changed, full mode switch [drm:drm_crtc_helper_set_config] crtc changed, full mode switch [drm:drm_crtc_helper_set_config] [CONNECTOR:30:DVI-I-1] to [CRTC:28:crtc-0] [drm:drm_crtc_helper_set_config] attempting to set mode from userspace [drm:drm_mode_debug_printmodeline] Modeline 44:"" 0 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x0 0x5 [drm:drm_crtc_helper_set_mode] [CRTC:28:crtc-0] [drm:drm_crtc_helper_set_mode] [ENCODER:29:TMDS-29] set [MODE:44:] [drm] write mode info 153 [drm:drm_crtc_helper_set_config] Setting connector DPMS state to on [drm:drm_crtc_helper_set_config][CONNECTOR:30:DVI-I-1] set DPMS on [drm] write mode info 153 [drm:udl_attach_dma_buf] [DEV:soc:gpu-subsystem] size:8298496 [drm:udl_map_dma_buf] [DEV:soc:gpu-subsystem] size:8298496 dir=0 etnaviv-gpu f009.gpu: virt 7104 phys 0x free 0x1ec0 stream link to 0x01e8 @ 0x2000 71042000 -->8--- > If that does not give any more info then maybe someone with > better understanding of etnaviv, UDL and X can help From my note above about udl_drm_gem_mmap() being only used in case of Xserver I barely may conclude anything. Given my lack of knowledge of DRM guts especially when it comes to complicated cases with DMA buffer exports/imports I cannot say immediately if that's just improper implementation of udl_drm_gem_mmap() or not. Even though I do see some differences between implementation of file_operations->mmap() callback in UDL and say exynos_drm_gem_mmap() or qxl_mmap() it's not clear why this and that implementation was done. > (maybe cc X devel list also ...) Well at this point I think its purely a UDL driver problem because if we swap UDL to imx-drm on Wandboard everything works perfectly fine! -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: etnaviv: PHYS_OFFSET usage
Hi Lucas,
On Wed, 2017-11-15 at 18:56 +0100, Lucas Stach wrote:
> Am Mittwoch, den 15.11.2017, 17:36 + schrieb Alexey Brodkin:
[snip]
> I'm not keen on having a private memory region for the GPU. Normally we
> just use the shared system CMA memory region (and we will point the
> linear memory window there on MC2.0 GPUs), which has the added benefit
> that we can map the contiguous framebuffers allocated by another device
> through the linear window, which is a crucial performance optimization
> for the MMUv1 GPUs.
>
> The only time where we really need to know the start of RAM is on MC1.0
> GPUs which have a hardware bug in the TS unit, so we try to avoid
> moving the linear window at all to work around that. In that case the
> PHYS_OFFSET check is really there to avoid the situation where the
> linear window would not allow any RAM to be reached at all. Then we
> need to move the window, but disable any TS functionality, impacting
> performance a lot.
Thanks a lot fro explanation!
> As MC1.0 GPUs are hopefully on the way out with new designs using MC2.0
> this shouldn't be much of a problem going forward. Maybe we can even
> simply solve this issue by just dropping the check if PHYS_OFFSET isn't
> defined.
I guess something like that should work then:
>8
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index fc9a6a83dfc7..5ad191a605e2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -678,6 +678,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
goto fail;
}
+#ifdef PHYS_OFFSET
/*
* Set the GPU linear window to be at the end of the DMA window, where
* the CMA area is likely to reside. This ensures that we are able to
@@ -699,6 +700,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
gpu->memory_base = PHYS_OFFSET;
gpu->identity.features &= ~chipFeatures_FAST_CLEAR;
}
+#endif
ret = etnaviv_hw_reset(gpu);
if (ret) {
>8
> At least I hope VeriSilicon didn't sell you a MC1.0 part at
> this time...
Given "chipMinorFeatures0_MC20" bit is set for us I would think that we
indeed have MC2.0 in our chip.
-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
Hi Jose, On Tue, 2017-12-05 at 12:26 +, Jose Abreu wrote: > On 05-12-2017 11:53, Alexey Brodkin wrote: > > > > > > From my note above about udl_drm_gem_mmap() being only used in case of > > Xserver > > I barely may conclude anything. Given my lack of knowledge of DRM guts > > especially > > when it comes to complicated cases with DMA buffer exports/imports I cannot > > say > > immediately if that's just improper implementation of > > udl_drm_gem_mmap() or not. > > Even though I do see some differences between implementation of > > file_operations->mmap() > > callback in UDL and > > say exynos_drm_gem_mmap() or qxl_mmap() it's not clear > > why this and that implementation was done. > > Oh, I've seen this before. This is the same thing that arcpgu > used to do in the mmap callback! Please comment out the call to > update_vm_cache_attr() in the mmap callback and check if it works. Actually I did it as the first thing when I spotted it in udl_drm_gem_mmap(). But that made no difference at all :( -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
Hi Jose, On Mon, 2017-12-04 at 17:24 +, Jose Abreu wrote: > On 04-12-2017 16:00, Alexey Brodkin wrote: > > > > [30.763] (II) armada(0): etnaviv: Xv: using YUY2 format intermediate > > YUV target > > > > I'm wondering if this means that target format for UDL is YUV ... > > But anyway, I revisited your first email and noticed that you > said kmscube runs fine. Is this using etnaviv as renderer? Indeed, in case of kmscube etnaviv is a renderer while UDL outputs the picture on the screen. > And > you also said X is claiming the screen but nothing appears ... > which X client are you using to test this? Well it might be seen from my full log. I just start X with "X&" command and then execute things like "xclock". So not sure who is a client in that case. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
Hi Jose, On Mon, 2017-12-04 at 14:02 +, Jose Abreu wrote: > On 04-12-2017 13:16, Alexey Brodkin wrote: > > > > Option "kmsdev" "/dev/dri/card1" > > Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and > if you don't specify the busID it will fallback for the first > card that matches "armada-drm" or "imx-drm" or "udl". > > > > > But if I swap "imx-drm" to "udl" I don't see anything on my screen > > (connected via UDL) even though Xserver seems to really start claiming the > > screen > > (so I see it becomes black, effectively overriding whatever was there > > before) and > > glmark benchmark prints results. > > > > > > Xorg.log can help confirm if everything is ok. That's xorg.conf: --->8-- # cat /etc/X11/xorg.conf Section "Device" Identifier "Driver0" Screen 0 Driver "armada" # Support hotplugging displays? Option "Hotplug" "TRUE" # Support hardware cursor if available? Option "HWCursor" "TRUE" # Use GPU acceleration? Option "UseGPU""TRUE" # Provide Xv interfaces? Option "XvAccel" "TRUE" # Prefer overlay for Xv (TRUE for armada-drm, FALSE for imx-drm) Option "XvPreferOverlay" "TRUE" # Which accelerator module to load (automatically found if commented out) Option "AccelModule" "etnadrm_gpu" Option "AccelModule" "etnaviv_gpu" # Support DRI2 interfaces? Option "DRI" "TRUE" EndSection --->8-- Full log you may find below. -Alexey Linux version 4.14.2-8-g95be6f762b7f-dirty (abrodkin@abrodkin-7440l) (gcc version 7.1.1 20170710 (ARCv2 ISA Linux uClibc toolchain 2017.09-rc1)) #68 SMP PREEMPT Mon Dec 4 16:12:46 MSK 2017 Memory @ 8000 [1024M] OF: fdt: Machine model: snps,hsdk earlycon: uart8250 at MMIO32 0xf0005000 (options '115200n8') bootconsole [uart8250] enabled archs-intc : 2 priority levels (default 1) FIRQ (not used) IDENTITY: ARCVER [0x52] ARCNUM [0x0] CHIPID [ 0x0] processor [0] : ARC HS38 R2.1 (ARCv2 ISA) Timers : Timer0 Timer1 RTC [UP 64-bit] GFRC [SMP 64-bit] ISA Extn: atomic ll64 unalign (not used) : mpy[opt 9] div_rem norm barrel-shift swap minmax swape BPU : full match, cache:2048, Predict Table:16384 MMU [v4]: 8k PAGE, 2M Super Page (not used) JTLB 1024 (256x4), uDTLB 8, uITLB 4, PAE40 (not used) I-Cache : 64K, 4way/set, 64B Line, VIPT aliasing D-Cache : 64K, 2way/set, 64B Line, PIPT SLC : 512K, 128B Line Peripherals : 0xf000, IO-Coherency (disabled) Vector Table: 0x9000 FPU : SP DP DEBUG : ActionPoint smaRT RTT OS ABI [v4] : 64-bit data any register aligned Extn [SMP] : ARConnect (v2): 4 cores with IPI IDU DEBUG GFRC Enable CONFIG_ARC_HAS_ACCL_REGS for working apps On node 0 totalpages: 131072 free_area_init_node: node 0, pgdat 91cf1080, node_mem_map bfb8 Normal zone: 576 pages used for memmap Normal zone: 0 pages reserved Normal zone: 131072 pages, LIFO batch:15 random: fast init done percpu: Embedded 7 pages/cpu @bfb1c000 s25088 r8192 d24064 u57344 pcpu-alloc: s25088 r8192 d24064 u57344 alloc=7*8192 pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 Built 1 zonelists, mobility grouping on. Total pages: 130496 Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1 drm.debug=0x1e PID hash table entries: 4096 (order: 1, 16384 bytes) Dentry cache hash table entries: 131072 (order: 6, 524288 bytes) Inode-cache hash table entries: 65536 (order: 5, 262144 bytes) Memory: 749864K/1048576K available (5319K kernel code, 270K rwdata, 1048K rodata, 23040K init, 293K bss, 298712K reserved, 0K cma-reserved) Preemptible hierarchical RCU implementation. Tasks RCU enabled. NR_IRQS: 512 MCIP: IDU supports 64 common irqs clocksource: ARConnect GFRC: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns Console: colour dummy device 80x25 Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 2048 (order: 0, 8192 bytes) Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes) Hierarchical SRCU implementation. smp: Bringing up secondary CPUs ... Idle Task [1] bf04da80 Trying to bring up CPU1 ... archs-intc : 2 priority levels (default 1) FIRQ
UDL's fbdev doesn't work for user-space apps
Hello, I'm trying to use DisplayLink USB2.0-to-HDMI adapter as the one and only video output and I want to get Xserver working on top of that. I'm not very familiar with all the parts of Linux GPU/video stack (especially its user-space counterpart) so my assumptions might be wrong in that case please correct me. My first [probably incorrect] assumption is Xserver requires fbdev (/dev/fbX) and it cannot use DRI video card natively. Is that correct? So to get /ded/fb0 with UDL I just enabled CONFIG_DRM_UDL & CONFIG_DRM_FBDEV_EMULATION. That gave me boot console on HDMI screen and I was full of expectations. But when I tried to use /dev/fb0 from whatever user-space app nothing got displayed on the screen... as well as no error messages appeared. After eyeballing at UDL code (especially in comparison with QXC which uses deferredio as well) I noticed that in UDL fb_deferred_io_init() is called from udl_fb_open(), i.e. .fb_open call-back (in other words every time user-space app opens /dev/fb0) while in QXC this is done only once and much earlier in qxlfb_create(), which is called with .fb_probe call-back. So moved fb_deferred_io_init() in UDL driver from udl_fb_open() to udlfb_create() which is also called from .fb_probe. With that change I finally got video output via fbdev from user-space app, but only on the first run. The next attempt to run inevitably ends with kernel crash showing the following stack-trace (having half of the new screen rendered on display): >8- Stack Trace: udl_handle_damage+0x48/0x210 udl_crtc_mode_set+0x6ee/0x754 drm_crtc_helper_set_mode+0x25e/0x438 drm_crtc_helper_set_config+0x6d6/0x814 __drm_mode_set_config_internal+0x48/0xc8 drm_mode_setcrtc+0x320/0x478 drm_ioctl+0x22c/0x3e4 SyS_ioctl+0xa4/0x8cc EV_Trap+0x108/0x10c random: crng init done >8- I'm wondering if UDL driver (its DRM flavor) was ever tested for fbdev in user-space? If so and it really works for somebody maybe I'm doing something terribly wrong - in that case any comments are very welcome. One interesting note: it seems like pure DRI stuff works like a charm. I may run kmscube perfectly fine without any changes whatsoever and do it many times in a row. Thanks in advance, Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
Hi Jose,
On Mon, 2017-12-04 at 11:50 +, Jose Abreu wrote:
> Hi Alexey,
>
> On 04-12-2017 11:32, Alexey Brodkin wrote:
> >
> > My first [probably incorrect] assumption is Xserver requires fbdev
> > (/dev/fbX)
> > and it cannot use DRI video card natively. Is that correct?
> >
> >
>
> Xserver can use DRI directly, you need to enable modesetting
> driver in Xorg config or use the designated driver for your card
> (if there is any).
Ok that makes sense. I didn't think about generic modesetting driver for
Xserver.
And that indeed works. This is my xorg.conf:
--->8--
# cat /etc/X11/xorg.conf
Section "Device"
Identifier "Driver0"
Screen 0
Driver "modesetting"
Option "kmsdev" "/dev/dri/card1"
EndSection
--->8--
I do see xclock is rendered fine.
Now I guess is getting closer to what I really need :)
In the end I wanted to get 3D rendered by Vivante GPU
to be displayed on UDL. My assumption was very simple - if IMX-DRM+Etnaviv
work fine it should be straight-forward to swap IMX-DRM bitstreamer with UDL
and we're golden.
That might be more a question to Lucas now.
I use xorg.conf as found here:
http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/tree/conf/xorg-sample.conf?h=unstable-devel
That's what it has:
--->8--
Section "Device"
Identifier "Driver0"
Screen 0
Driver "armada"
# Support hotplugging displays?
# Option "Hotplug" "TRUE"
# Support hardware cursor if available?
# Option "HWCursor" "TRUE"
# Use GPU acceleration?
# Option "UseGPU""TRUE"
# Provide Xv interfaces?
# Option "XvAccel" "TRUE"
# Prefer overlay for Xv (TRUE for armada-drm, FALSE for imx-drm)
# Option "XvPreferOverlay" "TRUE"
# Which accelerator module to load (automatically found if commented out)
# Option "AccelModule" "etnadrm_gpu"
# Option "AccelModule" "etnaviv_gpu"
# Support DRI2 interfaces?
# Option "DRI" "TRUE"
EndSection
--->8--
Indeed I uncommented all the lines and then it allows to see
for example glmark2-es2 working on Wandboard (that's exactly where
"imx-drm + etnaviv" combo is used).
But if I swap "imx-drm" to "udl" I don't see anything on my screen
(connected via UDL) even though Xserver seems to really start claiming the
screen
(so I see it becomes black, effectively overriding whatever was there before)
and
glmark benchmark prints results.
Maybe I'm missing some additional glue for UDL in "xf86-video-armada" except
the simple one:
--->8--
--- a/src/armada_module.c
+++ b/src/armada_module.c
@@ -26,7 +26,7 @@
#define ARMADA_NAME"armada"
#define ARMADA_DRIVER_NAME "armada"
-#define DRM_MODULE_NAMES "armada-drm", "imx-drm"
+#define DRM_MODULE_NAMES "armada-drm", "imx-drm", "udl"
#define DRM_DEFAULT_BUS_ID NULL
static const char *drm_module_names[] = { DRM_MODULE_NAMES };
@@ -43,6 +43,11 @@ static SymTabRec ipu_chipsets[] = {
{ -1, NULL }
};
+static SymTabRec udl_chipsets[] = {
+ { 0, "UDL" },
+ { -1, NULL }
+};
+
static const OptionInfoRec * const options[] = {
armada_drm_options,
common_drm_options,
@@ -115,6 +120,8 @@ static void armada_identify(int flags)
armada_chipsets);
xf86PrintChipsets(ARMADA_NAME, "Support for Freescale IPU",
ipu_chipsets);
+ xf86PrintChipsets(ARMADA_NAME, "Support DisplayLink USB2.0",
+ udl_chipsets);
}
--->8--
-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
Hi Jose, On Mon, 2017-12-04 at 15:55 +, Jose Abreu wrote: > On 04-12-2017 14:53, Alexey Brodkin wrote: > > > > Full log you may find below. > > Sorry but I meant /var/log/Xorg.0.log file. Ooops... sorry... here is it. -Alexey # cat /var/log/Xorg.0.log [30.345] X.Org X Server 1.19.5 Release Date: 2017-10-12 [30.345] X Protocol Version 11, Revision 0 [30.345] Build Operating System: Linux 3.10.0-514.el7.x86_64 x86_64 [30.346] Current Operating System: Linux axs103 4.14.2-8-g95be6f762b7f-dirty #68 SMP PREEMPT Mon Dec 4 16:12:46 MSK 2017 arc [30.346] Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1 drm.debug=0x1e [30.346] Build Date: 01 December 2017 12:21:28PM [30.346] [30.346] Current version of pixman: 0.34.0 [30.346]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [30.346] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [30.346] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan 1 00:00:30 1970 [30.346] (==) Using config file: "/etc/X11/xorg.conf" [30.346] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [30.347] (==) No Layout section. Using the first Screen section. [30.347] (==) No screen section available. Using defaults. [30.347] (**) |-->Screen "Default Screen Section" (0) [30.347] (**) | |-->Monitor "" [30.348] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [30.348] (**) | |-->Device "Driver0" [30.348] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [30.349] (==) Not automatically adding devices [30.349] (==) Not automatically enabling devices [30.349] (==) Not automatically adding GPU devices [30.349] (==) Max clients allowed: 256, resource mask: 0x1f [30.349] (WW) The directory "/usr/share/fonts/X11//TTF/" does not exist. [30.349]Entry deleted from font path. [30.349] (WW) The directory "/usr/share/fonts/X11//OTF/" does not exist. [30.349]Entry deleted from font path. [30.349] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/X11//100dpi/". [30.349]Entry deleted from font path. [30.349](Run 'mkfontdir' on "/usr/share/fonts/X11//100dpi/"). [30.349] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/X11//75dpi/". [30.349]Entry deleted from font path. [30.350](Run 'mkfontdir' on "/usr/share/fonts/X11//75dpi/"). [30.350] (==) FontPath set to: /usr/share/fonts/X11//misc/, /usr/share/fonts/X11//Type1/ [30.350] (==) ModulePath set to "/usr/lib/xorg/modules" [30.350] (==) |-->Input Device "" [30.350] (==) |-->Input Device "" [30.350] (==) No Layout section. Using the default mouse configuration. [30.350] (==) No Layout section. Using the default keyboard configuration. [30.350] (II) Loader magic: 0x178528 [30.350] (II) Module ABI versions: [30.350]X.Org ANSI C Emulation: 0.4 [30.350]X.Org Video Driver: 23.0 [30.350]X.Org XInput driver : 24.1 [30.350]X.Org Server Extension : 10.0 [30.350] (II) LoadModule: "armada" [30.351] (II) Loading /usr/lib/xorg/modules/drivers/armada_drv.so [30.352] (II) Module armada: vendor="X.Org Foundation" [30.352]compiled for 1.19.5, module version = 0.0.0 [30.352]Module class: X.Org Video Driver [30.352]ABI class: X.Org Video Driver, version 23.0 [30.352] (II) LoadModule: "mouse" [30.352] (II) Loading /usr/lib/xorg/modules/input/mouse_drv.so [30.353] (II) Module mouse: vendor="X.Org Foundation" [30.353]compiled for 1.19.5, module version = 1.9.2 [30.353]Module class: X.Org XInput Driver [30.353]ABI class: X.Org XInput driver, version 24.1 [30.353] (II) LoadModule: "kbd" [30.353] (II) Loading /usr/lib/xorg/modules/input/kbd_drv.so [30.353] (II) Module kbd: vendor="X.Org Foundation" [30.353]compiled for 1.19.5, module version = 1.9.0 [30.354]Module class: X.Org XInput Driver [30.354]ABI class: X.Org XInput driver, version 24.1 [30.354] (II) armada: Support for Marvell LCD Controller: 88AP510 [30.354] (II) armada: Support for Freescale IPU: i.MX6 [30.354] (II) armada: Support DisplayLink USB2.0: UDL [30.354] (--) using VT number 2 [30.354] (WW) Falling back to old probe method for
Re: glxgears on Etnaviv: couldn't get an RGB, Double-buffered visual
Hi Lucas, On Fri, 2017-11-24 at 17:11 +0100, Lucas Stach wrote: > Hi Alexey, > > Am Freitag, den 24.11.2017, 16:02 + schrieb Alexey Brodkin: > > > > Hello, > > > > Being in the middle of bring-up of the new board with Vivante GPU (HSDK > > namely, > > see > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_arch_arc_plat-2Dhsdk=Dw > > IDaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=ZXa-564Jm43PXsqGXCf2US2DY7C0qIlCw6c56pL- > > bLY=ZJSI1u6GgsRHNIcONVFfIKvn1AWaB38GmtCN1dGB3w0=) > > I was looking at simple 3D test apps to see how Etnaviv works on the > > hardware. > > > > So far I was able to get kmscube working perfectly fine and the next item I > > took > > was glxgears (for some reason I was under impression that's de facto "Hello > > world" app > > in the GPU world). But apparently even with Xserver up and running glxgears > > doesn't work. > > > > Moreover I tried the same thing on Wandboard Quad but to no avail as well. > > That's what I saw: > > ->8- > > # glxgears > > Error: couldn't get an RGB, Double-buffered visual > > > > # glxinfo > > name of display: :0 > > Error: couldn't find RGB GLX visual or fbconfig > > ->8- > > > > Googling didn't help here unfortunately so maybe some pointers could be > > suggested here... like what do I do wrong and if glxgears is supposed to > > work on top of DRM GPU at all? > > > > Thanks a lot in advance! > > For 3D acceleration to work under X you need the etnaviv specific DDX > driver, which can be found here: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.arm.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-3Dunstable-2Ddevel=DwIDaQ=DPL6_ > X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=ZXa-564Jm43PXsqGXCf2US2DY7C0qIlCw6c56pL- > bLY=ZzK2fxA6_XlN6pGnf2Tpo6qKzzQh76ocWZ6IDR-WPtc= Thanks for the pointer, still a couple of questions below... > Don't let you get confused by the name, the armada driver implements > support for both armada drm and imx-drm and the etnaviv DDX. This > provides 2D acceleration on the Vivante 2D cores, as well a the DRI2/3 > bit necessary to get a 3D context on X. From Wandboard's .dts I see that 2D core is a separate node with separate set of registers mapped at a different location in memory, right? Do you know if that's possible if the same one memory-mapped register set controls both 3D and 2D engine? If we happen to not have 2D core if that's a no go for us for anything? Like no compositing whatsoever etc? In the meantime I'll try to figure out if we have 2D core or not. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: glxgears on Etnaviv: couldn't get an RGB, Double-buffered visual
Hi Lucas, On Fri, 2017-11-24 at 17:38 +0100, Lucas Stach wrote: > Am Freitag, den 24.11.2017, 16:25 + schrieb Alexey Brodkin: > > > > Hi Lucas, > > > > On Fri, 2017-11-24 at 17:11 +0100, Lucas Stach wrote: > > > > > > Hi Alexey, > > > > > > Am Freitag, den 24.11.2017, 16:02 + schrieb Alexey Brodkin: > > > > > > > > > > > > Hello, > > > > > > > > Being in the middle of bring-up of the new board with Vivante GPU (HSDK > > > > namely, > > > > see > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_arch_arc_plat-2Dhsdk; > > > > d=Dw > > > > IDaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=ZXa-564Jm43PXsqGXCf2US2DY7C0qIlCw6c56pL- > > > > bLY=ZJSI1u6GgsRHNIcONVFfIKvn1AWaB38GmtCN1dGB3w0=) > > > > I was looking at simple 3D test apps to see how Etnaviv works on the > > > > hardware. > > > > > > > > So far I was able to get kmscube working perfectly fine and the next > > > > item I took > > > > was glxgears (for some reason I was under impression that's de facto > > > > "Hello world" app > > > > in the GPU world). But apparently even with Xserver up and running > > > > glxgears doesn't work. > > > > > > > > Moreover I tried the same thing on Wandboard Quad but to no avail as > > > > well. > > > > That's what I saw: > > > > ->8- > > > > # glxgears > > > > Error: couldn't get an RGB, Double-buffered visual > > > > > > > > # glxinfo > > > > name of display: :0 > > > > Error: couldn't find RGB GLX visual or fbconfig > > > > ->8- > > > > > > > > Googling didn't help here unfortunately so maybe some pointers could be > > > > suggested here... like what do I do wrong and if glxgears is supposed to > > > > work on top of DRM GPU at all? > > > > > > > > Thanks a lot in advance! > > > > > > For 3D acceleration to work under X you need the etnaviv specific DDX > > > driver, which can be found here: > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.arm.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-3Dunstable-2Ddevel=DwIDaQ=D > > > PL6_ > > > X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=ZXa-564Jm43PXsqGXCf2US2DY7C0qIlCw6c56pL- > > > bLY=ZzK2fxA6_XlN6pGnf2Tpo6qKzzQh76ocWZ6IDR-WPtc= > > > > Thanks for the pointer, still a couple of questions below... > > > > > > > > Don't let you get confused by the name, the armada driver implements > > > support for both armada drm and imx-drm and the etnaviv DDX. This > > > provides 2D acceleration on the Vivante 2D cores, as well a the DRI2/3 > > > bit necessary to get a 3D context on X. > > > > From Wandboard's .dts I see that 2D core is a separate node with separate > > set of registers mapped at a different location in memory, right? > > > > Do you know if that's possible if the same one memory-mapped register set > > controls both 3D and 2D engine? > > Yes, a "core" in Vivante speak is a GPU with one DMA frontend. A single > frontend can feed both 3D and 2D acceleration engines behind it. On > i.MX6 the 2D and 3D engine are on separate cores, but Marvell Dove has > a combined 2D/3D core. Hm, that sounds encouraging. The next question would be if Marvel Dove is supported in Etnaviv DDX? I guess it's called Armada so the answer if yes, right? > > If we happen to not have 2D core if that's a no go for us for anything? > > I don't know if the DDX works properly without 2D acceleration. Weston > on the other hand only relies on the 3D accel core for doing > compositing, so even if you don't have a 2D engine you will be able to > launch a modern Linux graphics stack. That's really cool! I'm much more interested in Weston ATM, which is actually another separate question :) I tried to find some details on how to run Weston on Wandboard but seems like I was looking at wrong Google again... do you know any good manuals for doing that? > > The etnaviv DDX could also emulate 2D accel over the 3D core by using > the X.Org glamor module, but no one has bothered to implement this yet. Ok we'll see if above case (combined cores) is applicable to us and then we'll see what to
Re: glxgears on Etnaviv: couldn't get an RGB, Double-buffered visual
Hi Lucas, On Fri, 2017-11-24 at 18:11 +0100, Lucas Stach wrote: > Am Freitag, den 24.11.2017, 16:49 + schrieb Alexey Brodkin: > [...] > > > > > > > > Yes, a "core" in Vivante speak is a GPU with one DMA frontend. A > > > single > > > frontend can feed both 3D and 2D acceleration engines behind it. On > > > i.MX6 the 2D and 3D engine are on separate cores, but Marvell Dove > > > has > > > a combined 2D/3D core. > > > > Hm, that sounds encouraging. The next question would be if Marvel > > Dove is > > supported in Etnaviv DDX? I guess it's called Armada so the answer if > > yes, right? > > Yes, the Dove was the original platform for the Armada X.Org driver. > Combined 2D/3D cores are supported just fine by etnaviv. Sweet! Maybe another question then. To get kmscube working on our board which uses essentially different bit-streamer device "udl" as opposed to "imx-drm" I had just to say: -->8-- export MESA_LOADER_DRIVER_OVERRIDE=imx-drm -->8-- and then all the magic has happened. Will it be a) required b) enough for Vivante X.org driver? > > > > If we happen to not have 2D core if that's a no go for us for > > > > anything? > > > > > > I don't know if the DDX works properly without 2D acceleration. > > > Weston > > > on the other hand only relies on the 3D accel core for doing > > > compositing, so even if you don't have a 2D engine you will be able > > > to > > > launch a modern Linux graphics stack. > > > > That's really cool! I'm much more interested in Weston ATM, which is > > actually another separate question :) > > I tried to find some details on how to run Weston on Wandboard > > but seems like I was looking at wrong Google again... do you > > know any good manuals for doing that? > > There really is no magic to it. Or better there is, but it's all hidden > in the Mesa implementation. > > You need at least Mesa 17.2 and Weston 3.0 for etnaviv to work > properly. Other than that just set XDG_RUNTIME_DIR to something > sensible and launch Weston with "weston --tty=63", done. Cool, will try that! > > > The etnaviv DDX could also emulate 2D accel over the 3D core by > > > using > > > the X.Org glamor module, but no one has bothered to implement this > > > yet. > > > > Ok we'll see if above case (combined cores) is applicable to us and > > then > > we'll see what to do. > > > > > > > > > > > > > In the meantime I'll try to figure out if we have 2D core or not. > > > > > > You can find out what your GPU provides by looking at the feature > > > bits. > > > chipFeatures_PIPE_2D, chipFeatures_PIPE_3D and chipFeatures_PIPE_VG > > > is > > > what you are looking out for. > > > > Does that info helps to decipher these bits? > > Unfortunately we forgot to expose the major feature bits register in > debugfs. It's gpu->identity.features in the kernel driver, the > interesting bits in there are chipFeatures_PIPE_3D and > chipFeatures_PIPE_2D. Noted! Are you going to add that yourself sometime soon or shall I do it? -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
glxgears on Etnaviv: couldn't get an RGB, Double-buffered visual
Hello, Being in the middle of bring-up of the new board with Vivante GPU (HSDK namely, see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arc/plat-hsdk) I was looking at simple 3D test apps to see how Etnaviv works on the hardware. So far I was able to get kmscube working perfectly fine and the next item I took was glxgears (for some reason I was under impression that's de facto "Hello world" app in the GPU world). But apparently even with Xserver up and running glxgears doesn't work. Moreover I tried the same thing on Wandboard Quad but to no avail as well. That's what I saw: ->8- # glxgears Error: couldn't get an RGB, Double-buffered visual # glxinfo name of display: :0 Error: couldn't find RGB GLX visual or fbconfig ->8- Googling didn't help here unfortunately so maybe some pointers could be suggested here... like what do I do wrong and if glxgears is supposed to work on top of DRM GPU at all? Thanks a lot in advance! -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/22] drm/arc: Use drm_fb_cma_fbdev_init/fini()
Hi Noralf, On Wed, 2017-11-15 at 15:19 +0100, Noralf Trønnes wrote: > Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on > the fact that drm_device holds a pointer to the drm_fb_helper structure. > This means that the driver doesn't have to keep track of that. > Also use the drm_fb_helper functions directly. > Remove unused function prototype arcpgu_fbdev_cma_init(). > > Cc: Alexey Brodkin <abrod...@synopsys.com> > Signed-off-by: Noralf Trønnes <nor...@tronnes.org> Acked-by: Alexey Brodkin <abrod...@synopsys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/22] drm/cma-helper: Remove drm_fbdev_cma* functions
Hi Noralf, On Tue, 2017-11-21 at 00:52 +0100, Noralf Trønnes wrote: > Den 17.11.2017 10.10, skrev Alexey Brodkin: > > > > Hi Noralf, > > > > On Thu, 2017-11-16 at 21:11 +0100, Noralf Trønnes wrote: > > > > > > Den 16.11.2017 09.14, skrev Shawn Guo: > > > > > > > > On Wed, Nov 15, 2017 at 03:19:39PM +0100, Noralf Trønnes wrote: > > > > > > > > > > This patchset adds drm_fb_cma_fbdev_init/fini() functions that > > > > > replaces > > > > > drm_fbdev_cma_init/fini(). The reason for doing so is to get rid of > > > > > struct drm_fbdev_cma and it's wrapper functions. The final piece will > > > > > happen when tinydrm moves away from the cma helper and we can remove > > > > > the > > > > > struct. > > > > > > > > > > Note: > > > > > Patches 19-22 depends on patchset: > > > > > [v3] drm: Add simple modeset suspend/resume helpers > > > > Is there a git branch somewhere we can test? > > > > > > > Here you go: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notro_linux_tree_drm-5Ffb-5Fcma-5Ffbdev-5Finit=DwIDaQ=DPL6_X_6J > > > kXFx > > > 7AXWqB0tg=OtZvQ4lNHIbjtyysXrNW8RbX6WFkigcev-xByzJ_fLk=McbBjcx46wmGkpM3GHmk9URB1xbd6ywS- > > > Z5tpdWwDX8=BewulagwMNQa5xW19olMnlzV5DI5cZ_7eDSPyUpzMV8= > > Thanks for that this really helps to test your patches. > > And looks like something is broken for ARC PGU + ADV7511 with your tree: > > -->8 > > adv7511: probe of 1-0039 failed with error -2 > > Maybe the problem is with the cec support added after 4.14: > > drm: adv7511/33: add HDMI CEC support > https://urldefense.proofpoint.com/v2/url?u=https-3A__cgit.freedesktop.org_drm_drm-2Dmisc_commit_drivers_gpu_drm_bridge_adv7511-3Fid-3D3b1b975003e4a3 > da4b93ab032487a3ae4afca7b5=DwIDaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=H7HSEHrOweYdtYmtV7QQ7l6ndVPGq1aUigPo3Wq > DlNg=67zDRPjQ2iyMOhroP6wat67ESWhYnGPAhKgbmgHwxQ0= > > Apparently there's a problem with it: > > [PATCHv2] drm: adv7511/33: Fix adv7511_cec_init() failure handling > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_dri-2Ddevel_2017-2DNovember_158024.html=DwIDaQ=DPL6_X_6JkXFx > 7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=H7HSEHrOweYdtYmtV7QQ7l6ndVPGq1aUigPo3WqDlNg=ecprlgbDaK04JzdFl4w5JR7J- > HoHaHCMwB0BfgRxufY= Thanks a lot for the pointer! Indeed this patch fixes a problem: >8 arcpgu e0017000.pgu: arc_pgu ID: 0x41440304 arcpgu e0017000.pgu: assigned reserved memory node frame_buffer@9e00 Console: switching to colour frame buffer device 160x45 arcpgu e0017000.pgu: fb0: frame buffer device [drm] Initialized arcpgu 1.0.0 20160219 for e0017000.pgu on minor 0 >8 So I'll reply with my ack for ARC PGU patch then as it works perfectly fine for me. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/22] drm/cma-helper: Remove drm_fbdev_cma* functions
Hi Noralf, On Thu, 2017-11-16 at 21:11 +0100, Noralf Trønnes wrote: > Den 16.11.2017 09.14, skrev Shawn Guo: > > > > On Wed, Nov 15, 2017 at 03:19:39PM +0100, Noralf Trønnes wrote: > > > > > > This patchset adds drm_fb_cma_fbdev_init/fini() functions that replaces > > > drm_fbdev_cma_init/fini(). The reason for doing so is to get rid of > > > struct drm_fbdev_cma and it's wrapper functions. The final piece will > > > happen when tinydrm moves away from the cma helper and we can remove the > > > struct. > > > > > > Note: > > > Patches 19-22 depends on patchset: > > > [v3] drm: Add simple modeset suspend/resume helpers > > Is there a git branch somewhere we can test? > > > > Here you go: > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notro_linux_tree_drm-5Ffb-5Fcma-5Ffbdev-5Finit=DwIDaQ=DPL6_X_6JkXFx > 7AXWqB0tg=OtZvQ4lNHIbjtyysXrNW8RbX6WFkigcev-xByzJ_fLk=McbBjcx46wmGkpM3GHmk9URB1xbd6ywS- > Z5tpdWwDX8=BewulagwMNQa5xW19olMnlzV5DI5cZ_7eDSPyUpzMV8= Thanks for that this really helps to test your patches. And looks like something is broken for ARC PGU + ADV7511 with your tree: -->8 adv7511: probe of 1-0039 failed with error -2 arcpgu e0017000.pgu: arc_pgu ID: 0x41440304 arcpgu e0017000.pgu: assigned reserved memory node frame_buffe r@9e00 [drm] Cannot find any crtc or sizes [drm] Cannot find any crtc or sizes [drm] Initialized arcpgu 1.0.0 20160219 for e0017000.pgu on minor 0 -->8 That's what I see on vanilla 4.14 kernel: -->8 arcpgu e0017000.pgu: arc_pgu ID: 0x41440304 arcpgu e0017000.pgu: assigned reserved memory node frame_buffer@9e00 Console: switching to colour frame buffer device 160x45 arcpgu e0017000.pgu: fb0: frame buffer device [drm] Initialized arcpgu 1.0.0 20160219 for e0017000.pgu on minor 0 -->8 Any thoughts? -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: etnaviv: PHYS_OFFSET usage
Hi Lucas,
On Wed, 2017-11-15 at 17:44 +0100, Lucas Stach wrote:
> Hi Alexey,
>
> Am Mittwoch, den 15.11.2017, 16:24 + schrieb Alexey Brodkin:
> >
> > Hi Lucas,
> >
> > As we discussed on ELCE last month in Prague we have Vivante GPU
> > built-in our new ARC HSDK development board.
> >
> > And even though [thanks to your suggestions] I got Etnaviv driver
> > working perfectly fine on our board I faced one quite a tricky
> > situation [which I dirty worked-around for now].
> >
> > Etnaviv driver uses some PHYS_OFFSET define which is not very
> > usual across all architectures and platforms supported by Linux kernel.
> >
> > In fact for ARC we don't have PHYS_OFFSET defined [yet].
> > And I'm wondering how to get this resolved.
> >
> > Essentially we have 2 options:
> > 1. Define PHYS_OFFSET for ARC (and later for other arches once needed)
> > 2. Replace PHYS_OFFSET with something else in etnaviv sources.
> >
> > Even though (1) seems to be the simplest solution is doesn't look very nice
> > because it seems to be quite ARM-specific but not something really generic
> > and portable.
> >
> > As for (2) frankly I din't quite understand why do we really care about
> > DDR start offset in the GPU driver. If some more light could be shed on this
> > topic probably we'll figure out what would be more elegant solution.
>
> Basically the GPU has a linear address window which is 2GB in size and
> all GPU command buffers must be mapped through this window. The window
> has a base offset, so we can move it to point to different locations in
> the physical address space of the system.
Wow, what a design decision :)
> Etnaviv uses the PHYS_OFFSET to find out where in the physical address
> space the RAM starts. If the start of RAM is above the 2GB mark we
> _must_ use the linear window in order to make the command buffers
> available to the GPU.
Well that looks not super safe and versatile solution to me.
What if used RAM is much more than 2Gb? I guess in that case it's
possible to to set PHYS_OFFSET to say 0 and then kernel might allocate
command buffer above 2Gb which will make that buffer not visible for
GPU I guess.
> I'm not aware of any other kernel API that would allow us to find the
> start of RAM. If there is I would be happy to replace the PHYS_OFFSET
> stuff. If you don't like to copy the PHYS_OFFSET stuff to ARC, you
> would need to introduce some new API, which allows us to retrieve this
> information.
I'd say we may use so-called "reserved memory" here as a nice an elegant
solution.
In device tree we describe this memory area like this:
-->8---
gpu_3d: gpu@9 {
compatible = "vivante,gc";
reg = <0x9 0x4000>;
interrupts = <28>;
memory-region = <_memory>;
};
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
gpu_memory: gpu_memory@be00 {
compatible = "shared-dma-pool";
reg = <0xbe00 0x200>;
no-map;
};
};
-->8---
And then in the driver code we just need to do 2 things:
1) Start using this memory for allocations in the driver
with help of of_reserved_mem_device_init()
2) Get the region start. Not sure what's the best way to do it
but I guess we'll be able to get "reg" property of the "gpu_memory"
node in the worst case. And then use that base instead of PHYS_OFFSET.
If of any interest I'll be willing to send you an RFC shortly so you
may see real implementation in details.
-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
etnaviv: PHYS_OFFSET usage
Hi Lucas, As we discussed on ELCE last month in Prague we have Vivante GPU built-in our new ARC HSDK development board. And even though [thanks to your suggestions] I got Etnaviv driver working perfectly fine on our board I faced one quite a tricky situation [which I dirty worked-around for now]. Etnaviv driver uses some PHYS_OFFSET define which is not very usual across all architectures and platforms supported by Linux kernel. In fact for ARC we don't have PHYS_OFFSET defined [yet]. And I'm wondering how to get this resolved. Essentially we have 2 options: 1. Define PHYS_OFFSET for ARC (and later for other arches once needed) 2. Replace PHYS_OFFSET with something else in etnaviv sources. Even though (1) seems to be the simplest solution is doesn't look very nice because it seems to be quite ARM-specific but not something really generic and portable. As for (2) frankly I din't quite understand why do we really care about DDR start offset in the GPU driver. If some more light could be shed on this topic probably we'll figure out what would be more elegant solution. Regards, Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 08/12] drm/arc: Use drm_gem_cma_print_info()
Hi Noralf, On Tue, 2017-11-07 at 20:13 +0100, Noralf Trønnes wrote: > There is a new core debugfs file that prints fb/gem info: > /dri//framebuffer > > Use drm_gem_cma_print_info() to provide info to that output instead > of using drm_fb_cma_debugfs_show(). > > Cc: Alexey Brodkin <abrod...@synopsys.com> > Signed-off-by: Noralf Trønnes <nor...@tronnes.org> > Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> I think I acked the previous version but anyways, Acked-by: Alexey Brodkin <abrod...@synopsys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 07/11] drm/arc: Use drm_gem_cma_print_info()
Hi Noralf, On Mon, 2017-10-30 at 17:29 +0100, Noralf Trønnes wrote: > There is a new core debugfs file that prints fb/gem info: > /dri//framebuffer > > Use drm_gem_cma_print_info() to provide info to that output instead > of using drm_fb_cma_debugfs_show(). > > Cc: Alexey Brodkin <abrod...@synopsys.com> > Signed-off-by: Noralf Trønnes <nor...@tronnes.org> > --- Thanks for doing this! We used to have just: ->8-- # cat fb fb: 1280x720@RG16 0: offset=0 pitch=2560, obj: 0 ( 1) 8000 0xbe00 7010 1843200 ->8-- And now we get more: a) information printed b) readable form of this info ->8-- # cat framebuffer framebuffer[33]: refcount=3 format=RG16 little-endian (0x36314752) modifier=0x0 size=1280x720 layers: size[0]=1280x720 pitch[0]=2560 offset[0]=0 obj[0]: name=0 refcount=1 start=8000 size=1843200 imported=no paddr=0xbe00 vaddr=7010 ----->8-- Acked-by: Alexey Brodkin <abrod...@synopsys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 04/22] drm/arc: Use drm_gem_fb_create()
Hi Noralf, > -Original Message- > From: Noralf Trønnes [mailto:nor...@tronnes.org] > Sent: Sunday, August 13, 2017 4:32 PM > To: dri-devel@lists.freedesktop.org > Cc: daniel.vet...@ffwll.ch; alexey.brod...@synopsys.com; > alison.w...@freescale.com; benjamin.gaign...@linaro.org; > boris.brezil...@free-electrons.com; brian.star...@arm.com; > puck.c...@hisilicon.com; e...@anholt.net; jsa...@ti.com; > laurent.pinch...@ideasonboard.com; liviu.du...@arm.com; ma...@denx.de; > maxime.rip...@free-electrons.com; > narmstr...@baylibre.com; philippe.co...@st.com; p.za...@pengutronix.de; > zourongr...@gmail.com; shawn...@kernel.org; > ste...@agner.ch; tomi.valkei...@ti.com; vincent.abr...@st.com; > z.liuxinli...@hisilicon.com; kong.kongxin...@hisilicon.com; > yannick.fer...@st.com; Noralf Trønnes <nor...@tronnes.org> > Subject: [PATCH v3 04/22] drm/arc: Use drm_gem_fb_create() > > drm_fb_cma_create() is just a wrapper around drm_gem_fb_create() now, > so use the function directly. Acked-by: Alexey Brodkin <abrod...@synopsys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] Please pull ARCPGU changes
Hi Dave, Could you please pull a couple of minor fixes and improvements for ARCPGU. These changes are based on today's drm-next branch. The following changes since commit dd24df657075fdf1e850612ea50634816f3c3581: Merge branch 'drm-next-4.14' of git://people.freedesktop.org/~agd5f/linux into drm-next (2017-08-02 12:43:12 +1000) are available in the git repository at: https://github.com/foss-for-synopsys-dwc-arc-processors/linux topic-arcpgu-updates for you to fetch changes up to 22d0be2a557e53a22feb484e8fce255fe09e6ad5: drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback (2017-08-03 00:11:02 +0300) ---- Alexey Brodkin (2): drm/arcpgu: Opt in debugfs arcpgu: Simplify driver name Jose Abreu (3): drm: arcpgu: Fix mmap() callback drm: arcpgu: Fix module unload drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback drivers/gpu/drm/arc/arcpgu_crtc.c | 7 --- drivers/gpu/drm/arc/arcpgu_drv.c | 57 - 2 files changed, 36 insertions(+), 28 deletions(-) Regards, Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Please pull ARCPGU changes
Hi Alex, On Wed, 2017-08-02 at 14:24 -0400, Alex Deucher wrote: > On Wed, Aug 2, 2017 at 6:16 AM, Alexey Brodkin > <alexey.brod...@synopsys.com> wrote: > > > > Hi Daniel, > > > > On Wed, 2017-08-02 at 11:41 +0200, Daniel Vetter wrote: > > > > > > On Mon, Jul 31, 2017 at 11:11:06AM +, Alexey Brodkin wrote: > > > > > > > > > > > > Hi Dave, > > > > > > > > Could you please pull a couple of minor fixes for ARCPGU. > > > > These changes are based on today's drm-misc/drm-misc-next. > > > > > > You can't send Dave a pull based on a random snapshot of drm-misc-next. If > > > you want to maintain your driver on top of drm-misc, then become part of > > > the group (arcgpu would fit imo). Otherwise you need to base your pulls on > > > top of Dave's tree. > > > > I don't have any specific requirement for "drm-misc-next" to b used as a > > base. > > That said Dave trees are OK for me. Still could you please point me to > > his "for-curr" and "for-next" (or equivalent) trees? > > next: > https://urldefense.proofpoint.com/v2/url?u=https-3A__cgit.freedesktop.org_-7Eairlied_linux_log_-3Fh-3Ddrm-2Dnext=DwIBaQ=DPL6_X_6JkXFx7AXWqB0tg > =lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=pbG-5bjYHB5-5W7BvTn5O7AaB-7boN5rb88XcxgLT5s=WrBr72Zx251yCmFMiv7mH7uKt5omhSWk8vlr0GDvG60= > > > fixes: > https://urldefense.proofpoint.com/v2/url?u=https-3A__cgit.freedesktop.org_-7Eairlied_linux_log_-3Fh-3Ddrm-2Dfixes=DwIBaQ=DPL6_X_6JkXFx7AXWqB0tg; > r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=pbG-5bjYHB5-5W7BvTn5O7AaB-7boN5rb88XcxgLT5s=iRx0mpfiNcQURDcMGyXfb9arq0OQsCnMddGvXDVk7Zg= > I added this repo as a remote and sent new pull-request based on drm-next. Thanks a lot for your help. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Please pull ARCPGU changes
Hi Daniel, On Wed, 2017-08-02 at 11:41 +0200, Daniel Vetter wrote: > On Mon, Jul 31, 2017 at 11:11:06AM +0000, Alexey Brodkin wrote: > > > > Hi Dave, > > > > Could you please pull a couple of minor fixes for ARCPGU. > > These changes are based on today's drm-misc/drm-misc-next. > > You can't send Dave a pull based on a random snapshot of drm-misc-next. If > you want to maintain your driver on top of drm-misc, then become part of > the group (arcgpu would fit imo). Otherwise you need to base your pulls on > top of Dave's tree. I don't have any specific requirement for "drm-misc-next" to b used as a base. That said Dave trees are OK for me. Still could you please point me to his "for-curr" and "for-next" (or equivalent) trees? > Also, your pull is missing the [PULL] tag in the > subject. Sorry for that, will fix it in the next request. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Please pull ARCPGU changes
Hi Dave, Could you please pull a couple of minor fixes for ARCPGU. These changes are based on today's drm-misc/drm-misc-next. The following changes since commit 9dd2aca46a13cc7177625f0dc3aaf5b7ebc6fe74: drm/rockchip: vop: rk3328: fix overlay abnormal (2017-07-31 08:44:18 +0800) are available in the git repository at: https://github.com/foss-for-synopsys-dwc-arc-processors/linux topic-arcpgu-updates for you to fetch changes up to a8709950755748e9975d63faa624f2ba4b39f9d6: drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback (2017-07-31 14:05:21 +0300) ---- Alexey Brodkin (2): drm/arcpgu: Opt in debugfs arcpgu: Simplify driver name Jose Abreu (3): drm: arcpgu: Fix mmap() callback drm: arcpgu: Fix module unload drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback drivers/gpu/drm/arc/arcpgu_crtc.c | 7 --- drivers/gpu/drm/arc/arcpgu_drv.c | 57 - 2 files changed, 36 insertions(+), 28 deletions(-) Regards, Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 03/41] drm/arc: Use .dumb_map_offset and .dumb_destroy defaults
Hi Noralf, > -Original Message- > From: Noralf Trønnes [mailto:nor...@tronnes.org] > Sent: Sunday, July 23, 2017 10:16 PM > To: dri-devel@lists.freedesktop.org > Cc: alexander.deuc...@amd.com; alexey.brod...@synopsys.com; > alison.w...@freescale.com; benjamin.gaign...@linaro.org; > bske...@redhat.com; boris.brezil...@free-electrons.com; > brian.star...@arm.com; puck.c...@hisilicon.com; > christian.koe...@amd.com; ck...@mediatek.com; daniel.vet...@intel.com; > airl...@redhat.com; e...@anholt.net; > kra...@redhat.com; jani.nik...@linux.intel.com; jy0922.s...@samsung.com; > jsa...@ti.com; kyungmin.p...@samsung.com; > laurent.pinch...@ideasonboard.com; liviu.du...@arm.com; ma...@denx.de; > mark@rock-chips.com; maxime.ripard@free- > electrons.com; narmstr...@baylibre.com; patrik.r.jakobs...@gmail.com; > philippe.co...@st.com; p.za...@pengutronix.de; > robdcl...@gmail.com; zourongr...@gmail.com; li...@armlinux.org.uk; > sw0312@samsung.com; shawn...@kernel.org; > ste...@agner.ch; thierry.red...@gmail.com; tomi.valkei...@ti.com; > vincent.abr...@st.com; z.liuxinli...@hisilicon.com; > kong.kongxin...@hisilicon.com; yannick.fer...@st.com; Noralf Trønnes > <nor...@tronnes.org> > Subject: [PATCH 03/41] drm/arc: Use .dumb_map_offset and .dumb_destroy > defaults > > This driver can use the drm_driver.dumb_destroy and > drm_driver.dumb_map_offset defaults, so no need to set them. > > Cc: Alexey Brodkin <abrod...@synopsys.com> > Signed-off-by: Noralf Trønnes <nor...@tronnes.org> > --- Acked-by: Alexey Brodkin <abrod...@synopsys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback
Hi Jose, On Tue, 2017-06-27 at 15:36 +0100, Jose Abreu wrote: > Currently we expect that clock driver produces the exact same value > as we are requiring. There can, and will, be some deviation however > so we need to take into account that instead of rejecting the mode. > > According to HDMI spec we have a max of +-0.5% for the pixel clock > frequency variation. Lets take that into an advantage and use it > to calculate how much deviation we can support. > > This patch was based on today's drm-misc-next. > > Signed-off-by: Jose Abreu <joab...@synopsys.com> > Cc: Carlos Palminha <palmi...@synopsys.com> > Cc: Alexey Brodkin <abrod...@synopsys.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Cc: Dave Airlie <airl...@linux.ie> Finally our problem with EDID-less monitor is fixed with that patch. Thus, Acked-by: Alexey Brodkin <abrod...@synopsys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] drm: arcpgu: Remove CRTC .prepare() helper operation
Hi Laurent,
On Wed, 2017-06-28 at 00:16 +0300, Laurent Pinchart wrote:
> The CRTC helper .prepare() operation is legacy code, the atomic helpers
> prefer the .disable() operation. As the arcpgu driver implements the
> .disable() and .prepare() operations identicallly, .prepare() can be
> removed.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> ---
> drivers/gpu/drm/arc/arcpgu_crtc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
> b/drivers/gpu/drm/arc/arcpgu_crtc.c
> index 51745608e09d..1f306781c9d5 100644
> --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> @@ -163,7 +163,6 @@ static const struct drm_crtc_helper_funcs
> arc_pgu_crtc_helper_funcs = {
> .mode_set_nofb = arc_pgu_crtc_mode_set_nofb,
> .enable = arc_pgu_crtc_enable,
> .disable= arc_pgu_crtc_disable,
> - .prepare= arc_pgu_crtc_disable,
> .atomic_begin = arc_pgu_crtc_atomic_begin,
> };
Acked-by: Alexey Brodkin <abrod...@synopsys.com>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm: Convert atomic drivers from CRTC .disable() to .atomic_disable()
Hi Laurent, On Wed, 2017-06-28 at 00:16 +0300, Laurent Pinchart wrote: > The CRTC .disable() helper operation is deprecated for atomic drivers, > the new .atomic_disable() helper operation being preferred. Convert all > atomic drivers to .atomic_disable() to avoid cargo-cult use of > .disable() in new drivers. > > Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com> > --- > drivers/gpu/drm/arc/arcpgu_crtc.c | 5 +++-- For arcpgu: Acked-by: Alexey Brodkin <abrod...@synopsys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/8] drm: Add old state pointer to CRTC .enable() helper function
Hi Laurent, On Wed, 2017-06-28 at 00:16 +0300, Laurent Pinchart wrote: > The old state is useful for drivers that need to perform operations at > enable time that depend on the transition between the old and new > states. > > While at it, rename the operation to .atomic_enable() to be consistent > with .atomic_disable(), as the .enable() operation is used by atomic > helpers only. > > Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com> > --- > drivers/gpu/drm/arc/arcpgu_crtc.c | 5 ++-- For arcpgu: Acked-by: Alexey Brodkin <abrod...@synopsys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm: arcpgu: Remove CRTC .commit() helper operation
Hi Laurent,
On Wed, 2017-06-28 at 00:16 +0300, Laurent Pinchart wrote:
> The CRTC helper .commit() operation is legacy code, the atomic helpers
> prefer the .enable() operation. As the arcpgu driver implements the
> .enable() operation, .commit() is never used and can be removed.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> ---
> drivers/gpu/drm/arc/arcpgu_crtc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
> b/drivers/gpu/drm/arc/arcpgu_crtc.c
> index 611af74a31c0..51745608e09d 100644
> --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> @@ -164,7 +164,6 @@ static const struct drm_crtc_helper_funcs
> arc_pgu_crtc_helper_funcs = {
> .enable = arc_pgu_crtc_enable,
> .disable= arc_pgu_crtc_disable,
> .prepare= arc_pgu_crtc_disable,
> - .commit = arc_pgu_crtc_enable,
> .atomic_begin = arc_pgu_crtc_atomic_begin,
> };
Acked-by: Alexey Brodkin <abrod...@synopsys.com>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/37] drm/arcgpu: Drop drm_vblank_cleanup
Hi Daniel, On Wed, 2017-05-24 at 16:51 +0200, Daniel Vetter wrote: > CRTC don't seem to get shut down in a controlled fashion, but no one > bothers to stop interrupts either so this races no matter what. Might > as well remove it. A call to drm_atomic_helper_shutdown would be > pretty sweet somewhere (and maybe getting rid of the load/unload > callbacks while at it). > > Cc: Alexey Brodkin <abrod...@synopsys.com> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > --- > drivers/gpu/drm/arc/arcpgu_drv.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c > b/drivers/gpu/drm/arc/arcpgu_drv.c > index 1926b200e4cb..3e43a5d4fb09 100644 > --- a/drivers/gpu/drm/arc/arcpgu_drv.c > +++ b/drivers/gpu/drm/arc/arcpgu_drv.c > @@ -155,7 +155,6 @@ static int arcpgu_unload(struct drm_device *drm) > arcpgu->fbdev = NULL; > } > drm_kms_helper_poll_fini(drm); > - drm_vblank_cleanup(drm); > drm_mode_config_cleanup(drm); > > return 0; Reviewed-by: Alexey Brodkin <abrod...@synopsys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/10] drm: arc: Use crtc->mode_valid() callback
Hi Jose, The only nitpicking note from my side is patch name. Probably full driver name as "arcpgu" might give a bit more context especially if later something else from ARC appears in "drm" folder. But IMHO that doesn't worth another respin. On Fri, 2017-05-19 at 01:52 +0100, Jose Abreu wrote: > Now that we have a callback to check if crtc supports a given mode > we can use it in arcpgu so that we restrict the number of probbed > modes to the ones we can actually display. > > This is specially useful because arcpgu crtc is responsible to set > a clock value in the commit() stage but unfortunatelly this clock > does not support all the needed ranges. > > Also, remove the atomic_check() callback as mode_valid() callback > will be called before. > > Signed-off-by: Jose Abreu <joab...@synopsys.com> > Cc: Carlos Palminha <palmi...@synopsys.com> > Cc: Alexey Brodkin <abrod...@synopsys.com> Reviewed-by: Alexey Brodkin <abrod...@synopsys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] arcpgu: Simplify driver name
This very minor change is still useful because it aligns
ARC PGU driver name with other DRM drivers and makes usage of
that driver name a bit easier.
For example in libdrm's test app we'll use "arcpgu" instead of
a bit more ugly "drm-arcpgu".
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
---
drivers/gpu/drm/arc/arcpgu_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 0b6eaa49a1db..c33cdbae7588 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -166,7 +166,7 @@ static struct drm_driver arcpgu_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
DRIVER_ATOMIC,
.lastclose = arcpgu_lastclose,
- .name = "drm-arcpgu",
+ .name = "arcpgu",
.desc = "ARC PGU Controller",
.date = "20160219",
.major = 1,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/arcpgu: Get rid of "encoder-slave" property
Hi Liviu, Rob,
On Fri, 2017-03-03 at 18:21 +, liviu.du...@arm.com wrote:
> On Fri, Mar 03, 2017 at 05:48:19PM +0000, Alexey Brodkin wrote:
> >
> > Hi Liviu,
> >
> > On Fri, 2017-03-03 at 16:28 +, Liviu Dudau wrote:
> > >
> > > On Fri, Mar 03, 2017 at 06:19:24PM +0300, Alexey Brodkin wrote:
> > > >
> > > >
> > > > - /* find the encoder node and initialize it */
> > > > - encoder_node = of_parse_phandle(drm->dev->of_node,
> > > > "encoder-slave", 0);
> > > > - if (encoder_node) {
> > > > - ret = arcpgu_drm_hdmi_init(drm, encoder_node);
> > > > - of_node_put(encoder_node);
> > > > + /* There is only one output port inside each device, find it */
> > > > + port = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
> > > > +
> > > > + if (port) {
> > > > + if (of_device_is_available(port))
> > > > + encoder = of_graph_get_remote_port_parent(port);
> > > > + of_node_put(port);
> > > > + }
> > >
> > > You must've been looking at some old version. Current version in -next
> > > uses
> > > of_graph_get_remote_node() to replace all those lines you have added (see
> > > Rob
> > > Herring's series to introduce of_graph_get_remote_node() function)
> >
> > Hm, I'm not on Linus' master tree [1] and so I thought I was quite up to
> > date :)
> > Still I made a check of linux-next and don't see any changes in
> > "drivers/gpu/drm/arm" compared to Linus' tree.
> >
> > [1]
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_cgit_linux_kernel_git_torvalds_linux.git_commit_drivers_gpu_drm_arm-3Fid-3D
> > e4563f6ba71792c77aeccb2092cc23149b44e642=DwIDaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=SI66ngnnXy33ncb8m5H4La2
> > T1SzSEiiP7hc_XsRahEc=uaswjVXcjYDrUosOkO_UpTMqJMWTT-LLPrg5JE6-t-8=
> > [2]
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_cgit_linux_kernel_git_next_linux-2Dnext.git_commit_drivers_gpu_drm_arm-3Fid
> > -3De4563f6ba71792c77aeccb2092cc23149b44e642=DwIDaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=SI66ngnnXy33ncb8m5H4
> > La2T1SzSEiiP7hc_XsRahEc=hl9Y6s3K9LwLL1M2WnL3ODax_V-ZRh8k1iTiyctIqU4=
> >
> > Could you please clarify which exact tree did you mean?
>
> Sorry, I thought the series got pulled by one of the DRM trees, but it looks
> like
> I was wrong. I was carrying a private copy in my internal tree, waiting for
> the
> moment when it got pulled into drm-next or drm-misc-next.
>
> Rob, do you have an update on your series introducing
> of_graph_get_remote_node() ?
For some reason I cannot find any relevant commits in linux-next tree even
today.
Could you please point me to either any random git tree with mentioned above
change or
maybe just mailing list where this patch was sent?
I'd like to implement the same fix in ARCPGU and call it a day finally.
-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/arcpgu: Get rid of "encoder-slave" property
We used to use "encoder-slave" property in PGU's
Device Tree node to refer to the encoder, but since there's
a way to find it with some code smarts we get rid of
obviously extra complication in PGU node.
Again inspired by ARM's HDLCD code.
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Liviu Dudau <liviu.du...@arm.com>
Cc: Daniel Vetter <dan...@ffwll.ch>
Cc: David Airlie <airl...@linux.ie>
Cc: Rob Herring <robh...@kernel.org>
---
arch/arc/boot/dts/axs10x_mb.dtsi | 1 -
drivers/gpu/drm/arc/arcpgu_drv.c | 23 +--
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 41cfb29b62c1..2fe030186b9d 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -287,7 +287,6 @@
pgu@17000 {
compatible = "snps,arcpgu";
reg = <0x17000 0x400>;
- encoder-slave = <>;
clocks = <>;
clock-names = "pxlclk";
memory-region = <_buffer>;
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 5c82f52fba80..b1b2286bda95 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include "arcpgu.h"
@@ -83,7 +84,7 @@ static int arcpgu_load(struct drm_device *drm)
{
struct platform_device *pdev = to_platform_device(drm->dev);
struct arcpgu_drm_private *arcpgu;
- struct device_node *encoder_node;
+ struct device_node *encoder, *port;
struct resource *res;
int ret;
@@ -118,14 +119,24 @@ static int arcpgu_load(struct drm_device *drm)
if (arc_pgu_setup_crtc(drm) < 0)
return -ENODEV;
- /* find the encoder node and initialize it */
- encoder_node = of_parse_phandle(drm->dev->of_node, "encoder-slave", 0);
- if (encoder_node) {
- ret = arcpgu_drm_hdmi_init(drm, encoder_node);
- of_node_put(encoder_node);
+ /* There is only one output port inside each device, find it */
+ port = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
+
+ if (port) {
+ if (of_device_is_available(port))
+ encoder = of_graph_get_remote_port_parent(port);
+ of_node_put(port);
+ }
+
+ if (encoder && of_device_is_available(encoder)) {
+ dev_info(drm->dev, "Found encoder node %s, proceeding with
it\n",
+encoder->name);
+ ret = arcpgu_drm_hdmi_init(drm, encoder);
+ of_node_put(encoder);
if (ret < 0)
return ret;
} else {
+ dev_info(drm->dev, "No encoder node, assume simulation\n");
ret = arcpgu_drm_sim_init(drm, NULL);
if (ret < 0)
return ret;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/arcpgu: Get rid of "encoder-slave" property
Hi Liviu,
On Fri, 2017-03-03 at 16:28 +, Liviu Dudau wrote:
> On Fri, Mar 03, 2017 at 06:19:24PM +0300, Alexey Brodkin wrote:
> >
> > - /* find the encoder node and initialize it */
> > - encoder_node = of_parse_phandle(drm->dev->of_node, "encoder-slave", 0);
> > - if (encoder_node) {
> > - ret = arcpgu_drm_hdmi_init(drm, encoder_node);
> > - of_node_put(encoder_node);
> > + /* There is only one output port inside each device, find it */
> > + port = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
> > +
> > + if (port) {
> > + if (of_device_is_available(port))
> > + encoder = of_graph_get_remote_port_parent(port);
> > + of_node_put(port);
> > + }
>
> You must've been looking at some old version. Current version in -next uses
> of_graph_get_remote_node() to replace all those lines you have added (see Rob
> Herring's series to introduce of_graph_get_remote_node() function)
Hm, I'm not on Linus' master tree [1] and so I thought I was quite up to date :)
Still I made a check of linux-next and don't see any changes in
"drivers/gpu/drm/arm" compared to Linus' tree.
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/arm?id=e4563f6ba71792c77aeccb2092cc23149b44e642
[2]
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/arm?id=e4563f6ba71792c77aeccb2092cc23149b44e642
Could you please clarify which exact tree did you mean?
Anyways I just tried to rebase my patch on top of linux-next tree and now
video output is broken for me - I only see some garbage on top of the screen
so I'll need to investigate it first before moving forward with stuff you
proposed :)
-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check
Hi Daniel,
On Thu, 2017-03-02 at 20:54 +0100, Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 08:27:54PM +0300, Alexey Brodkin wrote:
> >
> > Since we cannot always generate exactly requested pixel clock
> > there's not much sense in checking requested_clock == clk_round_rate().
> > In that case for quite some modes we'll be getting -EINVAL and no video
> > output at all.
> >
> > But given there's some tolerance to real pixel clock in TVs/monitors
> > we may still give it a try with the clock as close to requested one as
> > PLL on the board may generate. So we just do a fixup to what current
> > board may provide.
> >
> > Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
> > Cc: David Airlie <airl...@linux.ie>
> > Cc: Jose Abreu <joab...@synopsys.com>
> > ---
> > drivers/gpu/drm/arc/arcpgu_crtc.c | 16 +++-
> > 1 file changed, 7 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > index ad9a95916f1f..3f2823c1efc3 100644
> > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > @@ -129,18 +129,16 @@ static void arc_pgu_crtc_disable(struct drm_crtc
> > *crtc)
> > ~ARCPGU_CTRL_ENABLE_MASK);
> > }
> >
> > -static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
> > - struct drm_crtc_state *state)
> > +static bool arc_pgu_crtc_mode_fixup(struct drm_crtc *crtc,
> > + const struct drm_display_mode *mode,
> > + struct drm_display_mode *adjusted_mode)
>
> This isn't required at all, see drm_crtc_state.adjusted_mode. Just update
> that and you're good - .mode_fixup is the backwards compatibility function
> for old kms drivers, atomic_check is strictly more powerful.
So if I understood you correct here what I really need is just to get rid of
existing check,
right? I.e. the following is to be in v2 respin:
--->8---
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a95916f1f..86f1555914e8 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -129,20 +129,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
~ARCPGU_CTRL_ENABLE_MASK);
}
-static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
-struct drm_crtc_state *state)
-{
- struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
- struct drm_display_mode *mode = >adjusted_mode;
- long rate, clk_rate = mode->clock * 1000;
-
- rate = clk_round_rate(arcpgu->clk, clk_rate);
- if (rate != clk_rate)
- return -EINVAL;
-
- return 0;
-}
-
static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
@@ -165,7 +151,6 @@ static const struct drm_crtc_helper_funcs
arc_pgu_crtc_helper_funcs = {
.disable= arc_pgu_crtc_disable,
.prepare= arc_pgu_crtc_disable,
.commit = arc_pgu_crtc_enable,
- .atomic_check = arc_pgu_crtc_atomic_check,
.atomic_begin = arc_pgu_crtc_atomic_begin,
};
--->8---
> Please also make sure the documentation properly explains this, and if
> not, please submit a patch to improve it.
You mean explains what? That .mode_fixup is not meant to be used in
new code?
-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check
Hi Jose,
On Fri, 2017-03-03 at 18:05 +, Jose Abreu wrote:
> Hi Alexey,
>
>
> On 03-03-2017 13:27, Alexey Brodkin wrote:
> >
> >
> > So if I understood you correct here what I really need is just to get rid
> > of existing check,
> > right? I.e. the following is to be in v2 respin:
> > --->8---
> > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > index ad9a95916f1f..86f1555914e8 100644
> > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > @@ -129,20 +129,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
> > ~ARCPGU_CTRL_ENABLE_MASK);
> > }
> >
> > -static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
> > -struct drm_crtc_state *state)
> > -{
> > - struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> > - struct drm_display_mode *mode = >adjusted_mode;
> > - long rate, clk_rate = mode->clock * 1000;
> > -
> > - rate = clk_round_rate(arcpgu->clk, clk_rate);
> > - if (rate != clk_rate)
> > - return -EINVAL;
> > -
> > - return 0;
> > -}
> > -
> > static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
> > struct drm_crtc_state *state)
> > {
> > @@ -165,7 +151,6 @@ static const struct drm_crtc_helper_funcs
> > arc_pgu_crtc_helper_funcs = {
> > .disable= arc_pgu_crtc_disable,
> > .prepare= arc_pgu_crtc_disable,
> > .commit = arc_pgu_crtc_enable,
> > - .atomic_check = arc_pgu_crtc_atomic_check,
> > .atomic_begin = arc_pgu_crtc_atomic_begin,
> > };
> > --->8---
>
> I don't think you can remove the check entirely as this will make
> any mode be accepted, right?
Correct. Otherwise we'll get some modes and devices that
don't work.
Remember our saga with 74.25 vs 74.40 MHz?
With our PLLs on AXS and HSDK boards we may generate 74.25 MHz clock
which satisfy some monitors especially those who pass correct EDID to the host.
But what if EDID is either corrupted or doesn't exist (that's my case with
some industrial monitor as well as with old DVI monitor)?
In that case Linux kernel attempts to calculate all the values including pixel
clock
but then instead of 74.25 we'll get 74.40 and equipment that used to work is no
longer useful.
So strictly speaking existing check makes perfect sense. But it reduces
compatibility with not very good monitors.
Probably better solution to the problem is just to throw away [my] faulty HW and
buy equipment that conforms to standards (not really sure if EDID is a hard
requirement for DVI/HDMI displays or this is just an option).
BTW I'm wondering if there're any guidelines on what could be pixel clock
deviation from the requested one?
-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/arcpgu: Opt in debugfs
This change adopts debugfs usage for outputting useful data.
As of today we print:
* Mode and real HW clock values
* Standard FB info
Code is heavily borrowed from ARM's HDLCD thus adding Liviu in Cc.
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Liviu Dudau <liviu.du...@arm.com>
Cc: Daniel Vetter <dan...@ffwll.ch>
Cc: David Airlie <airl...@linux.ie>
Cc: Jose Abreu <joab...@synopsys.com>
---
drivers/gpu/drm/arc/arcpgu_drv.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 8d8344ed655e..5c82f52fba80 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -161,6 +161,32 @@ static int arcpgu_unload(struct drm_device *drm)
return 0;
}
+#ifdef CONFIG_DEBUG_FS
+static int arcpgu_show_pxlclock(struct seq_file *m, void *arg)
+{
+ struct drm_info_node *node = (struct drm_info_node *)m->private;
+ struct drm_device *drm = node->minor->dev;
+ struct arcpgu_drm_private *arcpgu = drm->dev_private;
+ unsigned long clkrate = clk_get_rate(arcpgu->clk);
+ unsigned long mode_clock = arcpgu->crtc.mode.crtc_clock * 1000;
+
+ seq_printf(m, "hw : %lu\n", clkrate);
+ seq_printf(m, "mode: %lu\n", mode_clock);
+ return 0;
+}
+
+static struct drm_info_list arcpgu_debugfs_list[] = {
+ { "clocks", arcpgu_show_pxlclock, 0 },
+ { "fb", drm_fb_cma_debugfs_show, 0 },
+};
+
+static int arcpgu_debugfs_init(struct drm_minor *minor)
+{
+ return drm_debugfs_create_files(arcpgu_debugfs_list,
+ ARRAY_SIZE(arcpgu_debugfs_list), minor->debugfs_root, minor);
+}
+#endif
+
static struct drm_driver arcpgu_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
DRIVER_ATOMIC,
@@ -187,6 +213,9 @@ static struct drm_driver arcpgu_drm_driver = {
.gem_prime_vmap = drm_gem_cma_prime_vmap,
.gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
+#ifdef CONFIG_DEBUG_FS
+ .debugfs_init = arcpgu_debugfs_init,
+#endif
};
static int arcpgu_probe(struct platform_device *pdev)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check
Since we cannot always generate exactly requested pixel clock
there's not much sense in checking requested_clock == clk_round_rate().
In that case for quite some modes we'll be getting -EINVAL and no video
output at all.
But given there's some tolerance to real pixel clock in TVs/monitors
we may still give it a try with the clock as close to requested one as
PLL on the board may generate. So we just do a fixup to what current
board may provide.
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: David Airlie <airl...@linux.ie>
Cc: Jose Abreu <joab...@synopsys.com>
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a95916f1f..3f2823c1efc3 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -129,18 +129,16 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
~ARCPGU_CTRL_ENABLE_MASK);
}
-static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
-struct drm_crtc_state *state)
+static bool arc_pgu_crtc_mode_fixup(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
{
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
- struct drm_display_mode *mode = >adjusted_mode;
- long rate, clk_rate = mode->clock * 1000;
- rate = clk_round_rate(arcpgu->clk, clk_rate);
- if (rate != clk_rate)
- return -EINVAL;
+ adjusted_mode->clock =
+ clk_round_rate(arcpgu->clk, mode->clock * 1000) / 1000;
- return 0;
+ return true;
}
static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
@@ -165,8 +163,8 @@ static const struct drm_crtc_helper_funcs
arc_pgu_crtc_helper_funcs = {
.disable= arc_pgu_crtc_disable,
.prepare= arc_pgu_crtc_disable,
.commit = arc_pgu_crtc_enable,
- .atomic_check = arc_pgu_crtc_atomic_check,
.atomic_begin = arc_pgu_crtc_atomic_begin,
+ .mode_fixup = arc_pgu_crtc_mode_fixup,
};
static void arc_pgu_plane_atomic_update(struct drm_plane *plane,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/23] drm: remove drm_vblank_no_hw_counter assignment from driver code
Hi Shawn, On Tue, 2017-02-07 at 17:16 +0800, Shawn Guo wrote: > From: Shawn Guo <shawn@linaro.org> > > Core code already makes drm_driver.get_vblank_counter hook optional by > letting drm_vblank_no_hw_counter be the default implementation for the > function hook. So the drm_vblank_no_hw_counter assignment in the driver > code becomes redundant and can be removed now. > > Signed-off-by: Shawn Guo <shawn@linaro.org> > Cc: Alexey Brodkin <abrod...@synopsys.com> For ARC PGU part Acked-by: Alexey Brodkin <abrod...@synopsys.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Make the connector .detect() callback optional
Hi Laurent, On Tue, 2016-11-29 at 22:56 +0200, Laurent Pinchart wrote: > Many drivers (21 to be exact) create connectors that are always > connected (for instance to an LVDS or DSI panel). Instead of forcing > them to implement a dummy .detect() handler, make the callback optional > and consider the connector as always connected in that case. > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com> > --- >  drivers/gpu/drm/amd/amdgpu/dce_virtual.c         |  7 --- >  drivers/gpu/drm/arc/arcpgu_sim.c                 |  7 > --- For ARC PGU Acked-by: Alexey Brodkin -Alexey
[PATCH 08/37] drm/arcpgu: Add local 'fb' variables
Hi Ville,
On Fri, 2016-11-18 at 21:52 +0200, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add a local 'fb' variable to a few places to get rid of the
> 'crtc->primary->fb' stuff. Looks neater and helps me with my ppor
> coccinelle skills later.
>
> Cc: Alexey Brodkin
> Signed-off-by: Ville Syrjälä
> ---
> Â drivers/gpu/drm/arc/arcpgu_crtc.c | 3 ++-
> Â 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
> b/drivers/gpu/drm/arc/arcpgu_crtc.c
> index 7130b044b004..5c26c5f126a3 100644
> --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> @@ -35,7 +35,8 @@ static struct simplefb_format supported_formats[] = {
> Â static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
> Â {
> Â struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> - uint32_t pixel_format = crtc->primary->state->fb->pixel_format;
> + const struct drm_framebuffer *fb = crtc->primary->state->fb;
> + uint32_t pixel_format = fb->pixel_format;
> Â struct simplefb_format *format = NULL;
> Â int i;
Acked-by: Alexey Brodkin
[PATCH 08/37] drm/arcpgu: Add local 'fb' variables
Hi Ville,
On Fri, 2016-11-18 at 21:52 +0200, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add a local 'fb' variable to a few places to get rid of the
> 'crtc->primary->fb' stuff. Looks neater and helps me with my ppor
> coccinelle skills later.
>
> Cc: Alexey Brodkin
> Signed-off-by: Ville Syrjälä
> ---
> Â drivers/gpu/drm/arc/arcpgu_crtc.c | 3 ++-
> Â 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
> b/drivers/gpu/drm/arc/arcpgu_crtc.c
> index 7130b044b004..5c26c5f126a3 100644
> --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> @@ -35,7 +35,8 @@ static struct simplefb_format supported_formats[] = {
> Â static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
> Â {
> Â struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> - uint32_t pixel_format = crtc->primary->state->fb->pixel_format;
> + const struct drm_framebuffer *fb = crtc->primary->state->fb;
> + uint32_t pixel_format = fb->pixel_format;
> Â struct simplefb_format *format = NULL;
> Â int i;
Acked-by: Alexey Brodkin
[PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge
Hi Daniel, David,
On Wed, 2016-11-02 at 12:23 +, Alexey Brodkin wrote:
> Hi Daniel, David,
>
> On Mon, 2016-10-24 at 18:33 +0000, Alexey Brodkin wrote:
> >
> > Hi Daniel,
> >
> > >
> > >
> > > -Original Message-
> > > From: linux-snps-arc [mailto:linux-snps-arc-bounces at
> > > lists.infradead.org] On Behalf Of Alexey Brodkin
> > > Sent: 19 окÑÑбÑÑ 2016 г. 12:33
> > > To: dri-devel at lists.freedesktop.org; architt at codeaurora.org;
> > > Eugeniy.Paltsev at synopsys.com
> > > Cc: linux-snps-arc at lists.infradead.org; linux-kernel at vger.kernel.org
> > > Subject: Re: [PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM
> > > bridge
> > >
> > > Hi Archit, all,
> > >
> > > On Wed, 2016-10-19 at 14:43 +0530, Archit Taneja wrote:
> > > >
> > > >
> > > >
> > > > On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote:
> > > > >
> > > > >
> > > > >
> > > > > ARC PGU driver starts crashing on initialization after
> > > > > 'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
> > > > > This happenes because in "arcpgu_drm_hdmi_init" function we get
> > > > > pointer
> > > > > of "drm_i2c_encoder_driver" structure, which doesn't exist after
> > > > > adv7511 hdmi encoder interface changed from slave encoder to drm
> > > > > bridge.
> > > > > So, when we call "encoder_init" function from this structure driver
> > > > > crashes.
> > >
> > > [snip]
> > >
> > > >
> > > >
> > > > Looks good now.
> > > >
> > > > Reviewed-by: Archit Taneja
> > >
> > > And IMHO it would be really good to get this one back-ported to 4.8
> > > because it really fixes kernel crash if ARC PGU driver is used.
> > >
> > > It might be a bit of a problem because patch itself a little-bit larger
> > > than formal requirement for stable backports but let's see if it gets
> > > accepted.
> >
> > Could you please pick this one up?
> > I may alternatively send a pull-request to David but not sure if 1 patch
> > worth it.
> >
> > Also if that's not really too late it would be good to get this one in 4.9
> > since the patch
> > In question fixes a real driver crash on its instantiation.
> > Actually driver crash happens since 4.8 but I failed to notice it earlier
> > and given amount
> > of changes I think there's barely a chance for it it to be accepted in
> > stable branches...
> > which in its turn makes at least 4.9 very desirable.
>
> Any chance this one gets accepted anytime soon?
Please treat this as another polite reminder to apply this patch.
If you prefer I may send a pull-request otherwise.
Regards,
Alexey
[PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge
Hi Daniel, David,
On Mon, 2016-10-24 at 18:33 +, Alexey Brodkin wrote:
> Hi Daniel,
>
> >
> > -Original Message-
> > From: linux-snps-arc [mailto:linux-snps-arc-bounces at lists.infradead.org]
> > On Behalf Of Alexey Brodkin
> > Sent: 19 окÑÑбÑÑ 2016 г. 12:33
> > To: dri-devel at lists.freedesktop.org; architt at codeaurora.org;
> > Eugeniy.Paltsev at synopsys.com
> > Cc: linux-snps-arc at lists.infradead.org; linux-kernel at vger.kernel.org
> > Subject: Re: [PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge
> >
> > Hi Archit, all,
> >
> > On Wed, 2016-10-19 at 14:43 +0530, Archit Taneja wrote:
> > >
> > >
> > > On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote:
> > > >
> > > >
> > > > ARC PGU driver starts crashing on initialization after
> > > > 'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
> > > > This happenes because in "arcpgu_drm_hdmi_init" function we get pointer
> > > > of "drm_i2c_encoder_driver" structure, which doesn't exist after
> > > > adv7511 hdmi encoder interface changed from slave encoder to drm bridge.
> > > > So, when we call "encoder_init" function from this structure driver
> > > > crashes.
> >
> > [snip]
> >
> > >
> > > Looks good now.
> > >
> > > Reviewed-by: Archit Taneja
> >
> > And IMHO it would be really good to get this one back-ported to 4.8
> > because it really fixes kernel crash if ARC PGU driver is used.
> >
> > It might be a bit of a problem because patch itself a little-bit larger
> > than formal requirement for stable backports but let's see if it gets
> > accepted.
>
> Could you please pick this one up?
> I may alternatively send a pull-request to David but not sure if 1 patch
> worth it.
>
> Also if that's not really too late it would be good to get this one in 4.9
> since the patch
> In question fixes a real driver crash on its instantiation.
> Actually driver crash happens since 4.8 but I failed to notice it earlier and
> given amount
> of changes I think there's barely a chance for it it to be accepted in stable
> branches...
> which in its turn makes at least 4.9 very desirable.
Any chance this one gets accepted anytime soon?
Regards,
Alexey
[PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge
Hi Daniel,
> -Original Message-
> From: linux-snps-arc [mailto:linux-snps-arc-bounces at lists.infradead.org]
> On Behalf Of Alexey Brodkin
> Sent: 19 окÑÑбÑÑ 2016 г. 12:33
> To: dri-devel at lists.freedesktop.org; architt at codeaurora.org;
> Eugeniy.Paltsev at synopsys.com
> Cc: linux-snps-arc at lists.infradead.org; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge
>
> Hi Archit, all,
>
> On Wed, 2016-10-19 at 14:43 +0530, Archit Taneja wrote:
> >
> > On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote:
> > >
> > > ARC PGU driver starts crashing on initialization after
> > > 'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
> > > This happenes because in "arcpgu_drm_hdmi_init" function we get pointer
> > > of "drm_i2c_encoder_driver" structure, which doesn't exist after
> > > adv7511 hdmi encoder interface changed from slave encoder to drm bridge.
> > > So, when we call "encoder_init" function from this structure driver
> > > crashes.
>
> [snip]
>
> > Looks good now.
> >
> > Reviewed-by: Archit Taneja
>
> And IMHO it would be really good to get this one back-ported to 4.8
> because it really fixes kernel crash if ARC PGU driver is used.
>
> It might be a bit of a problem because patch itself a little-bit larger
> than formal requirement for stable backports but let's see if it gets
> accepted.
Could you please pick this one up?
I may alternatively send a pull-request to David but not sure if 1 patch worth
it.
Also if that's not really too late it would be good to get this one in 4.9
since the patch
In question fixes a real driver crash on its instantiation.
Actually driver crash happens since 4.8 but I failed to notice it earlier and
given amount
of changes I think there's barely a chance for it it to be accepted in stable
branches...
which in its turn makes at least 4.9 very desirable.
-Alexey
[PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge
Hi Archit, all,
On Wed, 2016-10-19 at 14:43 +0530, Archit Taneja wrote:
>
> On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote:
> >
> > ARC PGU driver starts crashing on initialization after
> > 'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
> > This happenes because in "arcpgu_drm_hdmi_init" function we get pointer
> > of "drm_i2c_encoder_driver" structure, which doesn't exist after
> > adv7511 hdmi encoder interface changed from slave encoder to drm bridge.
> > So, when we call "encoder_init" function from this structure driver
> > crashes.
[snip]
> Looks good now.
>
> Reviewed-by: Archit Taneja
And IMHO it would be really good to get this one back-ported to 4.8
because it really fixes kernel crash if ARC PGU driver is used.
It might be a bit of a problem because patch itself a little-bit larger
than formal requirement for stable backports but let's see if it gets accepted.
-Alexey
[PATCH] drm/arcpgu: Delete an unnecessary check before drm_fbdev_cma_hotplug_event()
Hi Markus, On Fri, 2016-07-15 at 22:00 +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 15 Jul 2016 21:52:40 +0200 > > The drm_fbdev_cma_hotplug_event() function tests whether its argument > is NULL and then returns immediately. > Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Good catch! Acked-by: Alexey Brodkin
[PATCH -next] drm/arc: Remove redundant dev_err call in arcpgu_load()
Hi Wei Yongjun, On Tue, 2016-07-19 at 12:01 +, Wei Yongjun wrote: > From: Wei Yongjun > > There is a error message within devm_ioremap_resource > already, so remove the dev_err call to avoid redundant > error message. > > Signed-off-by: Wei Yongjun Acked-by: Alexey Brodkin
[PATCH -next] drm/arc: Fix some sparse warnings
Hi Wei Yongjun, On Tue, 2016-07-19 at 12:04 +, Wei Yongjun wrote: > From: Wei Yongjun > > Fixes the following sparse warnings: > > drivers/gpu/drm/arc/arcpgu_drv.c:52:5: warning: >  symbol 'arcpgu_gem_mmap' was not declared. Should it be static? > drivers/gpu/drm/arc/arcpgu_drv.c:134:48: warning: >  Using plain integer as NULL pointer > drivers/gpu/drm/arc/arcpgu_drv.c:155:5: warning: >  symbol 'arcpgu_unload' was not declared. Should it be static? > > Signed-off-by: Wei Yongjun Acked-by: Alexey Brodkin
of_reserved_mem_device_init_by_idx() returns -EINVAL if "memory-region" is missing
Hi Marek,
On Fri, 2016-06-17 at 07:28 +0200, Marek Szyprowski wrote:
> Hi Alexey
>
>
> On 2016-06-16 18:47, Alexey Brodkin wrote:
> >
> > Hi Marek,
> >
> > We used to use of_reserved_mem_device_init() in such a context in GPU
> > drivers:
> > >8---
> > /* Get the optional framebuffer memory resource */
> > ret = of_reserved_mem_device_init(drm->dev);
> > if (ret && ret != -ENODEV)
> > return ret;
> > >8---
> >
> > The point is we may have a dedicated reserved memory area or may not have
> > (depends on a particular .dts).
> > Our expectation is if reserved memory area is missing then
> > of_reserved_mem_device_init()
> > just returns -ENODEV and it used to work like this.
> >
> > Now with your commit 59ce4039727e "of: reserved_mem: add support for using
> > more than one region for given device"
> > behavior is different. of_reserved_mem_device_init_by_idx() has this:
> > >8---
> > target = of_parse_phandle(np, "memory-region", idx);
> > if (!target)
> > return -EINVAL;
> > >8---
> >
> > So I'm wondering which part should be fixed:
> > Â 1) of_reserved_mem itself or
> > Â 2) users of of_reserved_mem_device_init()
> >
> > Any thoughts?
>
> This was my fault. The fix is already queued to linux-next, see commit
> 9f5a802b1d51dc80a27d828a5f7dcc8ec4a72f03 ("[media] of: reserved_mem: restore
> old behavior when no region is defined"),
> http://www.spinics.net/lists/linux-media/msg100972.html
>
Indeed with mentioned fix GPU driver now works again!
Sorry for the noise and thank you for fixing it that fast.
Regards,
Alexey
of_reserved_mem_device_init_by_idx() returns -EINVAL if "memory-region" is missing
Hi Marek, We used to use of_reserved_mem_device_init() in such a context in GPU drivers: >8--- /* Get the optional framebuffer memory resource */ ret = of_reserved_mem_device_init(drm->dev); if (ret && ret != -ENODEV) return ret; >8--- The point is we may have a dedicated reserved memory area or may not have (depends on a particular .dts). Our expectation is if reserved memory area is missing then of_reserved_mem_device_init() just returns -ENODEV and it used to work like this. Now with your commit 59ce4039727e "of: reserved_mem: add support for using more than one region for given device" behavior is different. of_reserved_mem_device_init_by_idx() has this: >8--- target = of_parse_phandle(np, "memory-region", idx); if (!target) return -EINVAL; >8--- So I'm wondering which part should be fixed:  1) of_reserved_mem itself or  2) users of of_reserved_mem_device_init() Any thoughts? Regards, Alexey
[GIT PULL] drm/arcpgu: Make ARC PGU usable on sim platforms
Hi Dave, Please pull this mini-series that allows ARC PGU to be used on simulation platforms like nSIM OSCI (AKA Linux Virtual Platform) or ARC VDK. The series was published for review here https://lists.freedesktop.org/archives/dri-devel/2016-June/110647.html It is based on today's "drm-next" branch. Best regards, Alexey The following changes since commit 3c85f20a289d044f303f473ee6ab7502303fc3b0:  Merge tag 'omapdrm-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next (2016-06-09 12:20:11 +1000) are available in the git repository at:  https://github.com/foss-for-synopsys-dwc-arc-processors/linux.git topic-arcpgu-sim for you to fetch changes up to 830c6578481e3b8649261062dfc5b0ac3c9374f8:  ARC: [nsimosci] Enable ARC PGU on nSIM OSCI virtual platforms (2016-06-13 17:45:18 +0200) -------- Alexey Brodkin (2):       ARCv2: [vdk] Enable ARC PGU on HS38 VDK       ARC: [nsimosci] Enable ARC PGU on nSIM OSCI virtual platforms Ruud Derwig (1):       drm/arcpgu: Make ARC PGU usable on simulation platforms  arch/arc/boot/dts/nsimosci.dts             |  14 +++---  arch/arc/boot/dts/nsimosci_hs.dts          |  14 +++---  arch/arc/boot/dts/nsimosci_hs_idu.dts      |  14 +++---  arch/arc/boot/dts/vdk_axs10x_mb.dtsi       |  13 +  arch/arc/boot/dts/vdk_hs38_smp.dts         |   2 +-  arch/arc/configs/nsimosci_defconfig        |   3 ++-  arch/arc/configs/nsimosci_hs_defconfig     |   3 ++-  arch/arc/configs/nsimosci_hs_smp_defconfig |   3 ++-  arch/arc/configs/vdk_hs38_smp_defconfig    |   7 ++-  drivers/gpu/drm/arc/Makefile               |   2 +-  drivers/gpu/drm/arc/arcpgu.h               |   1 +  drivers/gpu/drm/arc/arcpgu_drv.c           |  15 ---  drivers/gpu/drm/arc/arcpgu_sim.c           | 128  13 files changed, 189 insertions(+), 30 deletions(-)  create mode 100644 drivers/gpu/drm/arc/arcpgu_sim.c
