[git pull] drm fixes for 5.2-rc6
Hey Linus, Just catching up on the week since back from holidays, everything seems quite sane. Dave. core: - copy_to_user fix for really legacy codepaths. vmwgfx: - two dma fixes - one virt hw interaction fix i915: - modesetting fix - gvt fix panfrost: - BO unmapping fix imx: - image converter fixes drm-fixes-2019-06-21: drm vmwgfx, panfrost, i915, imx fixes The following changes since commit 9e0babf2c06c73cda2c0cd37a1653d823adb40ec: Linux 5.2-rc5 (2019-06-16 08:49:45 -1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-06-21 for you to fetch changes up to 5eab9cf87b6c261f4e2f6c7623171cc2f5ea1a9c: Merge tag 'imx-drm-fixes-2019-06-20' of git://git.pengutronix.de/git/pza/linux into drm-fixes (2019-06-21 11:44:24 +1000) drm vmwgfx, panfrost, i915, imx fixes Boris Brezillon (1): drm/panfrost: Make sure a BO is only unmapped when appropriate Dan Carpenter (1): drm: return -EFAULT if copy_to_user() fails Dave Airlie (4): Merge branch 'vmwgfx-fixes-5.2' of git://people.freedesktop.org/~thomash/linux into drm-fixes Merge tag 'drm-misc-fixes-2019-06-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2019-06-20' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'imx-drm-fixes-2019-06-20' of git://git.pengutronix.de/git/pza/linux into drm-fixes Jani Nikula (1): Merge tag 'gvt-fixes-2019-06-19' of https://github.com/intel/gvt-linux into drm-intel-fixes Qian Cai (1): drm/vmwgfx: fix a warning due to missing dma_parms Steve Longerbeam (3): gpu: ipu-v3: image-convert: Fix input bytesperline width/height align gpu: ipu-v3: image-convert: Fix input bytesperline for packed formats gpu: ipu-v3: image-convert: Fix image downsize coefficients Thomas Hellstrom (2): drm/vmwgfx: Use the backdoor port if the HB port is not available drm/vmwgfx: Honor the sg list segment size limitation Ville Syrjälä (1): drm/i915: Don't clobber M/N values during fastset check Weinan Li (1): drm/i915/gvt: ignore unexpected pvinfo write drivers/gpu/drm/drm_bufs.c | 5 +- drivers/gpu/drm/drm_ioc32.c| 5 +- drivers/gpu/drm/i915/gvt/handlers.c| 15 +-- drivers/gpu/drm/i915/intel_display.c | 38 ++-- drivers/gpu/drm/panfrost/panfrost_gem.c| 3 +- drivers/gpu/drm/panfrost/panfrost_gem.h| 1 + drivers/gpu/drm/panfrost/panfrost_mmu.c| 8 ++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 3 + drivers/gpu/drm/vmwgfx/vmwgfx_msg.c| 146 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 10 +- drivers/gpu/ipu-v3/ipu-image-convert.c | 40 +--- 11 files changed, 209 insertions(+), 65 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] mali-dp and komeda patches for drm-next
On Thu, 20 Jun 2019 at 20:35, Liviu Dudau wrote:
>
> Hi DRM maintainers,
>
> Picking up pace on the upstreaming of Komeda driver, with quite a lot
> of new features added this time. On top of that we have the small
> cleanups and improved usage of the debugfs functions. Please pull!
It looks like you rebased this at the last moment, please don't do
that, don't rebase just because you can.
The reason I noticed is because
dim: 344f00e4d7d6 ("drm/komeda: Make Komeda interrupts shareable"):
author Signed-off-by missing.
dim: 1885a6d946f5 ("drm/komeda: fix 32-bit
komeda_crtc_update_clock_ratio"): SHA1 in fixes line not found:
dim: a962091227ed ("drm/komeda: Add engine clock requirement check
for the downscaling")
dim: ERROR: issues in commits detected, aborting
so clearly rebasing the fixed commit broke stuff, you should probably
squash fixes if you are rebasing.
Please resend with above fixed, and refrain from misc rebases in future.
Dave.
>
> Best regards,
> Liviu
>
>
> The following changes since commit 52d2d44eee8091e740d0d275df1311fb8373c9a9:
>
> Merge v5.2-rc5 into drm-next (2019-06-19 12:07:29 +0200)
>
> are available in the Git repository at:
>
> git://linux-arm.org/linux-ld.git for-upstream/mali-dp
>
> for you to fetch changes up to 344f00e4d7d6538c1862505b25b662b47c9e0bb0:
>
> drm/komeda: Make Komeda interrupts shareable (2019-06-19 17:04:21 +0100)
>
>
> Arnd Bergmann (1):
> drm/komeda: fix 32-bit komeda_crtc_update_clock_ratio
>
> Ayan Halder (1):
> drm/komeda: Make Komeda interrupts shareable
>
> Greg Kroah-Hartman (2):
> komeda: no need to check return value of debugfs_create functions
> malidp: no need to check return value of debugfs_create functions
>
> Liviu Dudau (1):
> arm/komeda: Convert dp_wait_cond() to return an error code.
>
> Lowry Li (Arm Technology China) (10):
> drm/komeda: Creates plane alpha and blend mode properties
> drm/komeda: Clear enable bit in CU_INPUTx_CONTROL
> drm/komeda: Add rotation support on Komeda driver
> drm/komeda: Adds limitation check for AFBC wide block not support Rot90
> drm/komeda: Update HW up-sampling on D71
> drm/komeda: Enable color-encoding (YUV format) support
> drm/komeda: Adds SMMU support
> dt/bindings: drm/komeda: Adds SMMU support for D71 devicetree
> drm/komeda: Adds zorder support
> drm/komeda: Add slave pipeline support
>
> james qian wang (Arm Technology China) (21):
> drm/komeda: Add writeback support
> drm/komeda: Added AFBC support for komeda driver
> drm/komeda: Attach scaler to drm as private object
> drm/komeda: Add the initial scaler support for CORE
> drm/komeda: Implement D71 scaler support
> drm/komeda: Add writeback scaling support
> drm/komeda: Add engine clock requirement check for the downscaling
> drm/komeda: Add image enhancement support
> drm/komeda: Add komeda_fb_check_src_coords
> drm/komeda: Add format support for Y0L2, P010, YUV420_8/10BIT
> drm/komeda: Unify mclk/pclk/pipeline->aclk to one MCLK
> drm/komeda: Rename main engine clk name "mclk" to "aclk"
> dt/bindings: drm/komeda: Unify mclk/pclk/pipeline->aclk to one ACLK
> drm/komeda: Add component komeda_merger
> drm/komeda: Add split support for scaler
> drm/komeda: Add layer split support
> drm/komeda: Refine function to_d71_input_id
> drm/komeda: Accept null writeback configurations for writeback
> drm/komeda: Add new component komeda_splitter
> drm/komeda: Enable writeback split support
> drm/komeda: Correct printk format specifier for "size_t"
>
> .../devicetree/bindings/display/arm,komeda.txt | 23 +-
> drivers/gpu/drm/arm/display/include/malidp_io.h| 7 +
> drivers/gpu/drm/arm/display/include/malidp_utils.h | 5 +-
> drivers/gpu/drm/arm/display/komeda/Makefile| 2 +
> .../gpu/drm/arm/display/komeda/d71/d71_component.c | 582 +-
> drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 142 +++--
> drivers/gpu/drm/arm/display/komeda/d71/d71_dev.h | 2 +
> .../gpu/drm/arm/display/komeda/komeda_color_mgmt.c | 67 ++
> .../gpu/drm/arm/display/komeda/komeda_color_mgmt.h | 17 +
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 154 -
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c| 59 +-
> drivers/gpu/drm/arm/display/komeda/komeda_dev.h| 13 +-
> .../drm/arm/display/komeda/komeda_format_caps.c| 58 ++
> .../drm/arm/display/komeda/komeda_format_caps.h| 24 +-
> .../drm/arm/display/komeda/komeda_framebuffer.c| 175 +-
> .../drm/arm/display/komeda/komeda_framebuffer.h| 13 +-
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c| 130 +++-
> drivers/gpu/drm/arm/display/komeda/komeda_kms.h| 71 ++-
> .../gpu/drm/arm/display/komeda/komeda_pipeline.c | 66 +-
>
Re: [linux-sunxi] Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits
On Fri, Jun 21, 2019 at 2:51 AM Jagan Teki wrote: > > On Tue, Jun 18, 2019 at 8:15 PM Chen-Yu Tsai wrote: > > > > On Tue, Jun 18, 2019 at 8:11 PM Jagan Teki > > wrote: > > > > > > On Tue, Jun 18, 2019 at 5:13 PM Chen-Yu Tsai wrote: > > > > > > > > On Tue, Jun 18, 2019 at 6:51 PM Jagan Teki > > > > wrote: > > > > > > > > > > On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard > > > > > wrote: > > > > > > > > > > > > On Fri, Jun 14, 2019 at 12:03:13PM +0530, Jagan Teki wrote: > > > > > > > On Thu, Jun 13, 2019 at 6:56 PM Maxime Ripard > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Jun 05, 2019 at 01:17:11PM +0530, Jagan Teki wrote: > > > > > > > > > On Tue, Jun 4, 2019 at 3:30 PM Maxime Ripard > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Wed, May 29, 2019 at 11:44:56PM +0530, Jagan Teki wrote: > > > > > > > > > > > On Wed, May 29, 2019 at 8:24 PM Maxime Ripard > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:48:51PM +0530, Jagan Teki > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Fri, May 24, 2019 at 2:04 AM Maxime Ripard > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan > > > > > > > > > > > > > > Teki wrote: > > > > > > > > > > > > > > > According to "DRM kernel-internal display mode > > > > > > > > > > > > > > > structure" in > > > > > > > > > > > > > > > include/drm/drm_modes.h the current driver is > > > > > > > > > > > > > > > trying to include > > > > > > > > > > > > > > > sync timings along with front porch value while > > > > > > > > > > > > > > > checking and > > > > > > > > > > > > > > > computing drq set bits in non-burst mode. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > mode->hsync_end - mode->hdisplay => horizontal > > > > > > > > > > > > > > > front porch + sync > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With adding additional sync timings, the dsi > > > > > > > > > > > > > > > controller leads to > > > > > > > > > > > > > > > wrong drq set bits for "bananapi,s070wv20-ct16" > > > > > > > > > > > > > > > panel which indeed > > > > > > > > > > > > > > > trigger panel flip_done timed out as: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > WARNING: CPU: 0 PID: 31 at > > > > > > > > > > > > > > > drivers/gpu/drm/drm_atomic_helper.c:1429 > > > > > > > > > > > > > > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > > > > > > > > > > > > > > [CRTC:46:crtc-0] vblank wait timed out > > > > > > > > > > > > > > > Modules linked in: > > > > > > > > > > > > > > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > > > > > > > > > > > > > > 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 > > > > > > > > > > > > > > > Hardware name: Allwinner sun8i Family > > > > > > > > > > > > > > > Workqueue: events deferred_probe_work_func > > > > > > > > > > > > > > > [] (unwind_backtrace) from > > > > > > > > > > > > > > > [] (show_stack+0x10/0x14) > > > > > > > > > > > > > > > [] (show_stack) from [] > > > > > > > > > > > > > > > (dump_stack+0x84/0x98) > > > > > > > > > > > > > > > [] (dump_stack) from [] > > > > > > > > > > > > > > > (__warn+0xfc/0x114) > > > > > > > > > > > > > > > [] (__warn) from [] > > > > > > > > > > > > > > > (warn_slowpath_fmt+0x44/0x68) > > > > > > > > > > > > > > > [] (warn_slowpath_fmt) from > > > > > > > > > > > > > > > [] > > > > > > > > > > > > > > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > > > > > > > > > > > > > > [] > > > > > > > > > > > > > > > (drm_atomic_helper_wait_for_vblanks.part.1) from > > > > > > > > > > > > > > > [] > > > > > > > > > > > > > > > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > > > > > > > > > > > > > > [] (drm_atomic_helper_commit_tail_rpm) > > > > > > > > > > > > > > > from [] (commit_tail+0x40/0x6c) > > > > > > > > > > > > > > > [] (commit_tail) from [] > > > > > > > > > > > > > > > (drm_atomic_helper_commit+0xbc/0x128) > > > > > > > > > > > > > > > [] (drm_atomic_helper_commit) from > > > > > > > > > > > > > > > [] > > > > > > > > > > > > > > > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > > > > > > > > > > > > > > [] (restore_fbdev_mode_atomic) from > > > > > > > > > > > > > > > [] > > > > > > > > > > > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > > > > > > > > > > > > > > > [] > > > > > > > > > > > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked) from > > > > > > > > > > > > > > > [] (drm_fb_helper_set_par+0x30/0x54) > > > > > > > > > > > > > > > [] (drm_fb_helper_set_par) from > > > > > > > > > > > > > > > [] (fbcon_init+0x560/0x5ac) > > > > > > > > > > > > > > > [] (fbcon_init) from [] > > > > > > > > > > > > > > > (visual_init+0xbc/0x104) > > > > > > > > > > > > > > > [] (visual_init) from [] > > > > > > > > > > > > > > > (do_bind_con_driver+0x1b0/0x390) > > > > > > > > > > > > > > > [] (do_bind_con_driver)
Re: [PATCH] drm/komeda: Adds power management support
Hi Liviu,
On Thu, Jun 20, 2019 at 12:15:22AM +0800, Liviu Dudau wrote:
> Hi Lowry,
>
> On Mon, Jun 17, 2019 at 06:55:49AM +0100, Lowry Li (Arm Technology China)
> wrote:
> > Adds runtime and system power management support in KMS kernel driver.
> >
> > Depends on:
> > - https://patchwork.freedesktop.org/series/61650/
> > - https://patchwork.freedesktop.org/series/60083/
> >
> > Signed-off-by: Lowry Li (Arm Technology China)
> > ---
> > drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +
> > drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 30 +
> > drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 2 +
> > drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 54
> > ++--
> > 4 files changed, 85 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > index 66c5e0d..1b4ea8a 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > @@ -257,6 +257,7 @@ void komeda_crtc_handle_event(struct komeda_crtc
> > *kcrtc,
> > komeda_crtc_atomic_enable(struct drm_crtc *crtc,
> > struct drm_crtc_state *old)
> > {
> > + pm_runtime_get_sync(crtc->dev->dev);
> > komeda_crtc_prepare(to_kcrtc(crtc));
> > drm_crtc_vblank_on(crtc);
> > komeda_crtc_do_flush(crtc, old);
> > @@ -330,6 +331,7 @@ void komeda_crtc_handle_event(struct komeda_crtc
> > *kcrtc,
> >
> > drm_crtc_vblank_off(crtc);
> > komeda_crtc_unprepare(kcrtc);
> > + pm_runtime_put(crtc->dev->dev);
> > }
> >
> > static void
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > index 405c64d..edd0943 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > @@ -308,3 +308,33 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
> >
> > devm_kfree(dev, mdev);
> > }
> > +
> > +int komeda_dev_resume(struct komeda_dev *mdev)
> > +{
> > + int ret = 0;
> > +
> > + if (mdev->iommu && mdev->funcs->connect_iommu) {
> > + ret = mdev->funcs->connect_iommu(mdev);
> > + if (ret < 0) {
> > + DRM_ERROR("connect iommu failed.\n");
> > + return ret;
> > + }
> > + }
> > +
> > + return mdev->funcs->enable_irq(mdev);
> > +}
> > +
> > +int komeda_dev_suspend(struct komeda_dev *mdev)
> > +{
> > + int ret = 0;
> > +
> > + if (mdev->iommu && mdev->funcs->disconnect_iommu) {
> > + ret = mdev->funcs->disconnect_iommu(mdev);
> > + if (ret < 0) {
> > + DRM_ERROR("disconnect iommu failed.\n");
> > + return ret;
> > + }
> > + }
> > +
> > + return mdev->funcs->disable_irq(mdev);
> > +}
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> > b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> > index d1c86b6..096f9f7 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> > @@ -207,4 +207,6 @@ struct komeda_dev {
> >
> > struct komeda_dev *dev_to_mdev(struct device *dev);
> >
> > +int komeda_dev_resume(struct komeda_dev *mdev);
> > +int komeda_dev_suspend(struct komeda_dev *mdev);
> > #endif /*_KOMEDA_DEV_H_*/
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> > index cfa5068..aa4cef1 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include "komeda_dev.h"
> > #include "komeda_kms.h"
> > @@ -32,6 +33,9 @@ static void komeda_unbind(struct device *dev)
> > return;
> >
> > komeda_kms_detach(mdrv->kms);
> > +
> > + pm_runtime_disable(dev);
> > +
> > komeda_dev_destroy(mdrv->mdev);
> >
> > dev_set_drvdata(dev, NULL);
> > @@ -52,6 +56,9 @@ static int komeda_bind(struct device *dev)
> > err = PTR_ERR(mdrv->mdev);
> > goto free_mdrv;
> > }
> > + dev_set_drvdata(dev, mdrv);
> > +
> > + pm_runtime_enable(dev);
> >
> > mdrv->kms = komeda_kms_attach(mdrv->mdev);
> > if (IS_ERR(mdrv->kms)) {
> > @@ -59,11 +66,10 @@ static int komeda_bind(struct device *dev)
> > goto destroy_mdev;
> > }
> >
> > - dev_set_drvdata(dev, mdrv);
> > -
> > return 0;
> >
> > destroy_mdev:
> > + pm_runtime_disable(dev);
> > komeda_dev_destroy(mdrv->mdev);
> >
> > free_mdrv:
> > @@ -134,13 +140,55 @@ static int komeda_platform_remove(struct
> > platform_device *pdev)
> >
> > MODULE_DEVICE_TABLE(of, komeda_of_match);
> >
> > +static int komeda_rt_pm_suspend(struct device *dev)
> > +{
> > + dev_info(dev, "%s\n", __func__);
> > + return
Re: [PATCH 2/6] dt-bindings: display: msm: gmu: add optional ocmem property
On Wed, Jun 19, 2019 at 01:21:20PM -0700, Rob Clark wrote:
> On Wed, Jun 19, 2019 at 1:17 PM Rob Herring wrote:
> >
> > On Sun, Jun 16, 2019 at 7:29 AM Brian Masney wrote:
> > >
> > > Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> > > must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> > > optional ocmem property to the Adreno Graphics Management Unit bindings.
> > >
> > > Signed-off-by: Brian Masney
> > > ---
> > > Documentation/devicetree/bindings/display/msm/gmu.txt | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt
> > > b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > > index 90af5b0a56a9..c746b95e95d4 100644
> > > --- a/Documentation/devicetree/bindings/display/msm/gmu.txt
> > > +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > > @@ -31,6 +31,10 @@ Required properties:
> > > - iommus: phandle to the adreno iommu
> > > - operating-points-v2: phandle to the OPP operating points
> > >
> > > +Optional properties:
> > > +- ocmem: phandle to the On Chip Memory (OCMEM) that's present on some
> > > Snapdragon
> > > + SoCs. See
> > > Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml.
> >
> > We already have a couple of similar properties. Lets standardize on
> > 'sram' as that is what TI already uses.
> >
> > Also, is the whole OCMEM allocated to the GMU? If not you should have
> > child nodes to subdivide the memory.
> >
>
> iirc, downstream a large chunk of OCMEM is statically allocated for
> GPU.. the remainder is dynamically allocated for different use-cases.
> The upstream driver Brian is proposing only handles the static
> allocation case
It appears that the GPU expects to use a specific region of ocmem,
specifically starting at 0. The freedreno driver allocates 1MB of
ocmem on the Nexus 5 starting at ocmem address 0. As a test, I
changed the starting address to 0.5MB and kmscube shows only half the
cube, and four wide black bars across the screen:
https://www.flickr.com/photos/masneyb/48100534381/
> (and I don't think we have upstream support for the various audio and
> video use-cases that used dynamic OCMEM allocation downstream)
That's my understanding as well.
> Although maybe we should still have a child node to separate the
> statically and dynamically allocated parts? I'm not sure what would
> make the most sense..
Given that the GPU is expecting a fixed address in ocmem, perhaps it
makes sense to have the child node. How about this based on the
sram/sram.txt bindings?
ocmem: ocmem@fdd0 {
compatible = "qcom,msm8974-ocmem";
reg = <0xfdd0 0x2000>, <0xfec0 0x18>;
reg-names = "ctrl", "mem";
clocks = < RPM_SMD_OCMEMGX_CLK>, < OCMEMCX_OCMEMNOC_CLK>;
clock-names = "core", "iface";
gmu-sram@0 {
reg = <0x0 0x10>;
pool;
};
misc-sram@0 {
reg = <0x10 0x08>;
export;
};
};
I marked the misc pool as export since I've seen in the downstream ocmem
sources a reference to their closed libsensors that runs in userspace.
Looking at the sram bindings led me to the genalloc API
(Documentation/core-api/genalloc.rst). I wonder if this is the way that
this should be done?
Brian
Re: [PATCH 3/5] drm/panel: Add attach/detach callbacks
If we want to query the device tree outside of the panel code in
helper functions, we can do this with the struct as is. There's
already a device struct pointer in drm_panel, so I think we can pull
from that.
On Tue, Jun 11, 2019 at 5:25 PM dbasehore . wrote:
>
> On Tue, Jun 11, 2019 at 1:57 AM Daniel Vetter wrote:
> >
> > On Mon, Jun 10, 2019 at 09:03:48PM -0700, Derek Basehore wrote:
> > > This adds the attach/detach callbacks. These are for setting up
> > > internal state for the connector/panel pair that can't be done at
> > > probe (since the connector doesn't exist) and which don't need to be
> > > repeatedly done for every get/modes, prepare, or enable callback.
> > > Values such as the panel orientation, and display size can be filled
> > > in for the connector.
> > >
> > > Signed-off-by: Derek Basehore
> > > ---
> > > drivers/gpu/drm/drm_panel.c | 14 ++
> > > include/drm/drm_panel.h | 4
> > > 2 files changed, 18 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> > > index 3b689ce4a51a..72f67678d9d5 100644
> > > --- a/drivers/gpu/drm/drm_panel.c
> > > +++ b/drivers/gpu/drm/drm_panel.c
> > > @@ -104,12 +104,23 @@ EXPORT_SYMBOL(drm_panel_remove);
> > > */
> > > int drm_panel_attach(struct drm_panel *panel, struct drm_connector
> > > *connector)
> > > {
> > > + int ret;
> > > +
> > > if (panel->connector)
> > > return -EBUSY;
> > >
> > > panel->connector = connector;
> > > panel->drm = connector->dev;
> > >
> > > + if (panel->funcs->attach) {
> > > + ret = panel->funcs->attach(panel);
> > > + if (ret < 0) {
> > > + panel->connector = NULL;
> > > + panel->drm = NULL;
> > > + return ret;
> > > + }
> > > + }
> >
> > Why can't we just implement this in the drm helpers for everyone, by e.g.
> > storing a dt node in drm_panel? Feels a bit overkill to have these new
> > hooks here.
> >
> > Also, my understanding is that this dt stuff is supposed to be
> > standardized, so this should work.
>
> So do you want all of this information added to the drm_panel struct?
> If we do that, we don't necessarily even need the drm helper function.
> We could just copy the values over here in the drm_panel_attach
> function (and clear them in drm_panel_detach).
>
> > -Daniel
> >
> > > +
> > > return 0;
> > > }
> > > EXPORT_SYMBOL(drm_panel_attach);
> > > @@ -128,6 +139,9 @@ EXPORT_SYMBOL(drm_panel_attach);
> > > */
> > > int drm_panel_detach(struct drm_panel *panel)
> > > {
> > > + if (panel->funcs->detach)
> > > + panel->funcs->detach(panel);
> > > +
> > > panel->connector = NULL;
> > > panel->drm = NULL;
> > >
> > > diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> > > index 13631b2efbaa..e136e3a3c996 100644
> > > --- a/include/drm/drm_panel.h
> > > +++ b/include/drm/drm_panel.h
> > > @@ -37,6 +37,8 @@ struct display_timing;
> > > * struct drm_panel_funcs - perform operations on a given panel
> > > * @disable: disable panel (turn off back light, etc.)
> > > * @unprepare: turn off panel
> > > + * @detach: detach panel->connector (clear internal state, etc.)
> > > + * @attach: attach panel->connector (update internal state, etc.)
> > > * @prepare: turn on panel and perform set up
> > > * @enable: enable panel (turn on back light, etc.)
> > > * @get_modes: add modes to the connector that the panel is attached to
> > > and
> > > @@ -70,6 +72,8 @@ struct display_timing;
> > > struct drm_panel_funcs {
> > > int (*disable)(struct drm_panel *panel);
> > > int (*unprepare)(struct drm_panel *panel);
> > > + void (*detach)(struct drm_panel *panel);
> > > + int (*attach)(struct drm_panel *panel);
> > > int (*prepare)(struct drm_panel *panel);
> > > int (*enable)(struct drm_panel *panel);
> > > int (*get_modes)(struct drm_panel *panel);
> > > --
> > > 2.22.0.rc2.383.gf4fbbf30c2-goog
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
[PATCH] drm/amdgpu: Don't skip display settings in hwmgr_resume()
I'm not entirely sure why this is, but for some reason:
921935dc6404 ("drm/amd/powerplay: enforce display related settings only on
needed")
Breaks runtime PM resume on the Radeon PRO WX 3100 (Lexa) in one the
pre-production laptops I have. The issue manifests as the following
messages in dmesg:
[drm] UVD and UVD ENC initialized successfully.
amdgpu :3b:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring vce1
test failed (-110)
[drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block
failed -110
[drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_device_ip_resume failed
(-110).
And happens after about 6-10 runtime PM suspend/resume cycles (sometimes
sooner, if you're lucky!). Unfortunately I can't seem to pin down
precisely which part in psm_adjust_power_state_dynamic that is causing
the issue, but not skipping the display setting setup seems to fix it.
Hopefully if there is a better fix for this, this patch will spark
discussion around it.
Fixes: 921935dc6404 ("drm/amd/powerplay: enforce display related settings only
on needed")
Cc: Evan Quan
Cc: Alex Deucher
Cc: Huang Rui
Cc: Rex Zhu
Cc: Likun Gao
Cc: # v5.1+
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index 6cd6497c6fc2..0e1b2d930816 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -325,7 +325,7 @@ int hwmgr_resume(struct pp_hwmgr *hwmgr)
if (ret)
return ret;
- ret = psm_adjust_power_state_dynamic(hwmgr, true, NULL);
+ ret = psm_adjust_power_state_dynamic(hwmgr, false, NULL);
return ret;
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema
On Thu, Jun 20, 2019 at 8:52 AM Rob Herring wrote: > > On Thu, Jun 20, 2019 at 3:01 AM Thierry Reding > wrote: > > > > On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote: > > > Convert the common panel bindings to DT schema consolidating scattered > > > definitions to a single schema file. > > > > > > The 'simple-panel' binding just a collection of properties and not a > > > complete binding itself. All of the 'simple-panel' properties are > > > covered by the panel-common.txt binding with the exception of the > > > 'no-hpd' property, so add that to the schema. > > > > > > As there are lots of references to simple-panel.txt, just keep the file > > > with a reference to panel-common.yaml for now until all the bindings are > > > converted. > > > > > > Cc: Thierry Reding > > > Cc: Sam Ravnborg > > > Cc: Maxime Ripard > > > Cc: Laurent Pinchart > > > Cc: dri-devel@lists.freedesktop.org > > > Signed-off-by: Rob Herring > > > --- > > > Note there's still some references to panel-common.txt that I need to > > > update or just go ahead and convert to schema. > > > > > > .../bindings/display/panel/panel-common.txt | 101 - > > > .../bindings/display/panel/panel-common.yaml | 143 ++ > > > .../bindings/display/panel/panel.txt | 4 - > > > .../bindings/display/panel/simple-panel.txt | 29 +--- > > > 4 files changed, 144 insertions(+), 133 deletions(-) > > > delete mode 100644 > > > Documentation/devicetree/bindings/display/panel/panel-common.txt > > > create mode 100644 > > > Documentation/devicetree/bindings/display/panel/panel-common.yaml > > > > I know it was this way before, but perhaps remove the redundant panel- > > prefix while at it? > > Sure. On 2nd thought, I prefer it as-is. The reason being the schema including this file are more readable with: allOf: - $ref: panel-common.yaml# Compared to one of: $ref: common.yaml# $ref: /schemas/display/panel/common.yaml# I suppose we could automagically include a 'common.yaml' file if existing in the same directory. That's a bigger change though... Rob
Re: [PATCH 1/7] video: add HDMI state notifier support
Massively cutting this thread, since halfway through in my previous reply I realized that maybe hdmi_codec is a much better starting point. On Thu, Jun 20, 2019 at 09:23:23PM +0800, Cheng-yi Chiang wrote: > On Thu, Jun 20, 2019 at 5:25 PM Daniel Vetter wrote: > > Yeah fully agreeing that hdmi_audio_code is probably a better starting > > point. Problem is that becuase hdmi_codec is built on top of platform > > device it's quite a bit harder to extend with callbacks and things like > > that, without breaking the driver model. > > > > I need to think about this more, but if all we need to look at is > > hdmi_codec, then I think this becomes a lot easier. And we can ignore > > drm_audio_component.h completely. > > > It is surprising that you think this way. > Maybe the original patch before hdmi-notifier was introduced is the > better way to solve this issue, if we only need to look at hdmi_codec. > > The history of hdmi_codec driver is in this patch series: > > https://lore.kernel.org/patchwork/patch/539656/ Hm, this doesn't seem to be the hdmi_codec driver I meant, but another, new one. I was talking about SND_SOC_HDMI_CODEC. > There was a callback mechanism implemented between dw-hdmi and hdmi > codec driver. > It was later consolidated by Doug in this patch for better jack status > reporting: > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/303573/ Hm that still seems entirely separate hdmi-codec specific to dw-hdmi only ... > I am not sure why the original patch series did not get fully accepted > in the upstream. > It was quite long time ago. > > But if you think this might be the right way to do, then it is even > better for us because the patch series and Doug's patch had been quite > stable > on our RK3288 products for about four years with plenty of users, so > we have much higher confidence in them. > I can rebase and clean up them and post another patch for review. > > Please let me know what approach you feel is better. > Thanks again! Not sure we're talking about the same. What I had in mind is to add jack status to the hdmi-codec.c stuff, which is used by multiple soc drm display drivers already. Looking at git grep output, there seems to be already some support for dw-hdmi synopsys drm_bridge driver. I thought of extending that. Does that not work for you? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[RFC/RFT PATCH RESEND] i2c: replace i2c_new_secondary_device with an ERR_PTR variant
In the general move to have i2c_new_*_device functions which return
ERR_PTR instead of NULL, this patch converts i2c_new_secondary_device().
There are only few users, so this patch converts the I2C core and all
users in one go. The function gets renamed to i2c_new_ancillary_device()
so out-of-tree users will get a build failure to understand they need to
adapt their error checking code.
Signed-off-by: Wolfram Sang
---
Sorry for the resend. I missed to add quite some relevant ppl to cc.
This patch is RFC for now because:
* there is one FIXME blob which I can only remove after a missing
header update which I will try to get into v5.2-rc6
* I wanted to check if media-maintainers agree to let me apply
this via the I2C tree?
* maybe someone with ADV HW is willing to test this?
The patch is based on v5.2-rc5 and tested with a Renesas Lager board
(R-Car H2) and a tweaked DA9063 driver. I don't have any of these ADV
devices properly set up so the code is only build tested.
If this is acceptable, I likely will add a patch adding a devm_ variant
of this new function to the patch stack and convert the users, too.
I think this new i2c_new_ancillary_device() should replace
i2c_new_dummy() in quite some places later. But we will see...
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 18 +-
drivers/i2c/i2c-core-base.c | 10 +-
drivers/media/i2c/adv748x/adv748x-core.c | 6 +++---
drivers/media/i2c/adv7604.c | 12
include/linux/i2c.h | 2 +-
5 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index f6d2681f6927..9e13e466e72c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -981,10 +981,10 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
{
int ret;
- adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
+ adv->i2c_cec = i2c_new_ancillary_device(adv->i2c_main, "cec",
ADV7511_CEC_I2C_ADDR_DEFAULT);
- if (!adv->i2c_cec)
- return -EINVAL;
+ if (IS_ERR(adv->i2c_cec))
+ return PTR_ERR(adv->i2c_cec);
i2c_set_clientdata(adv->i2c_cec, adv);
adv->regmap_cec = devm_regmap_init_i2c(adv->i2c_cec,
@@ -1165,20 +1165,20 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
adv7511_packet_disable(adv7511, 0x);
- adv7511->i2c_edid = i2c_new_secondary_device(i2c, "edid",
+ adv7511->i2c_edid = i2c_new_ancillary_device(i2c, "edid",
ADV7511_EDID_I2C_ADDR_DEFAULT);
- if (!adv7511->i2c_edid) {
- ret = -EINVAL;
+ if (IS_ERR(adv7511->i2c_edid)) {
+ ret = PTR_ERR(adv7511->i2c_edid);
goto uninit_regulators;
}
regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
adv7511->i2c_edid->addr << 1);
- adv7511->i2c_packet = i2c_new_secondary_device(i2c, "packet",
+ adv7511->i2c_packet = i2c_new_ancillary_device(i2c, "packet",
ADV7511_PACKET_I2C_ADDR_DEFAULT);
- if (!adv7511->i2c_packet) {
- ret = -EINVAL;
+ if (IS_ERR(adv7511->i2c_packet)) {
+ ret = PTR_ERR(adv7511->i2c_packet);
goto err_i2c_unregister_edid;
}
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index e77bab2fb467..8b7855f3a199 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -965,7 +965,7 @@ struct i2c_client *devm_i2c_new_dummy_device(struct device
*dev,
EXPORT_SYMBOL_GPL(devm_i2c_new_dummy_device);
/**
- * i2c_new_secondary_device - Helper to get the instantiated secondary address
+ * i2c_new_ancillary_device - Helper to get the instantiated secondary address
* and create the associated device
* @client: Handle to the primary client
* @name: Handle to specify which secondary address to get
@@ -984,9 +984,9 @@ EXPORT_SYMBOL_GPL(devm_i2c_new_dummy_device);
* cell whose "reg-names" value matches the slave name.
*
* This returns the new i2c client, which should be saved for later use with
- * i2c_unregister_device(); or NULL to indicate an error.
+ * i2c_unregister_device(); or an ERR_PTR to describe the error.
*/
-struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
+struct i2c_client *i2c_new_ancillary_device(struct i2c_client *client,
const char *name,
u16 default_addr)
{
@@ -1001,9 +1001,9 @@ struct i2c_client *i2c_new_secondary_device(struct
i2c_client *client,
}
dev_dbg(>adapter->dev, "Address for %s : 0x%x\n", name, addr);
- return
Re: [PATCH 1/2] drm: Pretty print mode flags
Hi Ville.
On Thu, Jun 20, 2019 at 09:50:48PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Decode the mode flags when printing the modeline so that I
> no longer have to decode the hex number myself.
You are extending the current way to print mode flags,
but I would anyway like to point out a different approach.
When I need to print a fourcc code it is as simple as:
{
struct drm_format_name_buf fbuf;
printk("My format: %s\n", drm_get_format_name(format, );
}
This way to handle this feels more straightforward
than the current approach used for modes.
Maybe bikeshedding, as your mileage may vary.
A middle ground could be to introduce a struct for the buf so we know
the callers do it right.
Most of the code would be the same, but all call sites would need to be
updated.
What do you think?
Sam
>
> To do this neatly I made the caller provide a temporary
> on stack buffer where we can produce the results. I choce 64
> bytes as a reasonable size for this. The worst case I think
> is > 100 bytes but that kind of mode would be nonsense anyway
> so I figured correct decoding isn't as important in such
> cases.
>
> Cc: Russell King
> Cc: Neil Armstrong
> Cc: Rob Clark
> Cc: Tomi Valkeinen
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: Ilia Mirkin
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/armada/armada_crtc.c | 3 +-
> drivers/gpu/drm/drm_atomic.c | 3 +-
> drivers/gpu/drm/drm_modes.c | 116 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 3 +-
> drivers/gpu/drm/meson/meson_venc.c| 4 +-
> drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 3 +-
> .../gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c | 3 +-
> .../gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c | 3 +-
> .../gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 3 +-
> .../gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 4 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 3 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 3 +-
> drivers/gpu/drm/msm/dsi/dsi_manager.c | 3 +-
> drivers/gpu/drm/msm/edp/edp_bridge.c | 3 +-
> drivers/gpu/drm/omapdrm/omap_connector.c | 5 +-
> drivers/gpu/drm/omapdrm/omap_crtc.c | 3 +-
> drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 3 +-
> drivers/gpu/drm/sti/sti_crtc.c| 3 +-
> include/drm/drm_modes.h | 14 ++-
> 20 files changed, 165 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c
> b/drivers/gpu/drm/armada/armada_crtc.c
> index ba4a3fab7745..ce9335682bd2 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -262,6 +262,7 @@ static void armada_drm_crtc_mode_set_nofb(struct drm_crtc
> *crtc)
> unsigned long flags;
> unsigned i;
> bool interlaced = !!(adj->flags & DRM_MODE_FLAG_INTERLACE);
> + char buf[DRM_MODE_FLAGS_BUF_LEN];
>
> i = 0;
> rm = adj->crtc_hsync_start - adj->crtc_hdisplay;
> @@ -270,7 +271,7 @@ static void armada_drm_crtc_mode_set_nofb(struct drm_crtc
> *crtc)
> tm = adj->crtc_vtotal - adj->crtc_vsync_end;
>
> DRM_DEBUG_KMS("[CRTC:%d:%s] mode " DRM_MODE_FMT "\n",
> - crtc->base.id, crtc->name, DRM_MODE_ARG(adj));
> + crtc->base.id, crtc->name, DRM_MODE_ARG(adj, buf));
> DRM_DEBUG_KMS("lm %d rm %d tm %d bm %d\n", lm, rm, tm, bm);
>
> /* Now compute the divider for real */
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 419381abbdd1..81caf91fbd72 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -380,6 +380,7 @@ static void drm_atomic_crtc_print_state(struct
> drm_printer *p,
> const struct drm_crtc_state *state)
> {
> struct drm_crtc *crtc = state->crtc;
> + char buf[DRM_MODE_FLAGS_BUF_LEN];
>
> drm_printf(p, "crtc[%u]: %s\n", crtc->base.id, crtc->name);
> drm_printf(p, "\tenable=%d\n", state->enable);
> @@ -393,7 +394,7 @@ static void drm_atomic_crtc_print_state(struct
> drm_printer *p,
> drm_printf(p, "\tplane_mask=%x\n", state->plane_mask);
> drm_printf(p, "\tconnector_mask=%x\n", state->connector_mask);
> drm_printf(p, "\tencoder_mask=%x\n", state->encoder_mask);
> - drm_printf(p, "\tmode: " DRM_MODE_FMT "\n", DRM_MODE_ARG(>mode));
> + drm_printf(p, "\tmode: " DRM_MODE_FMT "\n", DRM_MODE_ARG(>mode,
> buf));
>
> if (crtc->funcs->atomic_print_state)
> crtc->funcs->atomic_print_state(p, state);
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 57e6408288c8..3d15c600295a 100644
> ---
Re: [PATCH] docs: fix some broken references due to txt->rst renames
On Tue, 18 Jun 2019 10:33:58 -0300 Mauro Carvalho Chehab wrote: > here are three left-overs from the recent file renames, > probably due to some other conflicting patch. > > Fix them. > > Signed-off-by: Mauro Carvalho Chehab > --- > > This patch is against today's next-20190617 branch. Not sure if it > will apply cleanly at -docs tree. If not, Please let me know for me to > split. Indeed it does not; one of the files being patched doesn't even exist in my world... jon
Re: [PATCH v11 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs
Hi, On Thu, Jun 20, 2019 at 02:18:53PM +0530, Kishon Vijay Abraham I wrote: > Hi, > > On 24/05/19 9:31 PM, Kishon Vijay Abraham I wrote: > > Hi, > > > > On 24/05/19 5:53 PM, Fabio Estevam wrote: > >> Hi Kishon, > >> > >> On Sun, May 12, 2019 at 7:49 AM Guido Günther wrote: > >>> > >>> This adds support for the Mixel DPHY as found on i.MX8 CPUs but since > >>> this is an IP core it will likely be found on others in the future. So > >>> instead of adding this to the nwl host driver make it a generic PHY > >>> driver. > >>> > >>> The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be > >>> added once the necessary system controller bits are in via > >>> mixel_dphy_devdata. > >>> > >>> Signed-off-by: Guido Günther > >>> Co-developed-by: Robert Chiras > >>> Signed-off-by: Robert Chiras > >>> Reviewed-by: Fabio Estevam > >>> Reviewed-by: Sam Ravnborg > >> > >> Would you have any comments on this series, please? > > > > I don't have any comments. I'll queue this once I start queuing patches for > > the > > next merge window. > > Can you fix the following checkpatch warning and repost? > WARNING: quoted string split across lines > #420: FILE: drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:280: > + dev_dbg(>dev, "hs_prepare: %u, clk_prepare: %u, " > + "hs_zero: %u, clk_zero: %u, " > > WARNING: quoted string split across lines > #421: FILE: drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:281: > + "hs_zero: %u, clk_zero: %u, " > + "hs_trail: %u, clk_trail: %u, " > > WARNING: quoted string split across lines > #422: FILE: drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:282: > + "hs_trail: %u, clk_trail: %u, " > + "rxhs_settle: %u\n", Fixed in v12. Thanks, -- Guido ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs
This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
this is an IP core it will likely be found on others in the future. So
instead of adding this to the nwl host driver make it a generic PHY
driver.
The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be
added once the necessary system controller bits are in via
mixel_dphy_devdata.
Signed-off-by: Guido Günther
Co-developed-by: Robert Chiras
Signed-off-by: Robert Chiras
Reviewed-by: Fabio Estevam
Reviewed-by: Sam Ravnborg
---
drivers/phy/freescale/Kconfig | 10 +
drivers/phy/freescale/Makefile| 1 +
.../phy/freescale/phy-fsl-imx8-mipi-dphy.c| 497 ++
3 files changed, 508 insertions(+)
create mode 100644 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index f435d6406943..320630ffe3cd 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -4,3 +4,13 @@ config PHY_FSL_IMX8MQ_USB
depends on OF && HAS_IOMEM
select GENERIC_PHY
default ARCH_MXC && ARM64
+
+config PHY_MIXEL_MIPI_DPHY
+ tristate "Mixel MIPI DSI PHY support"
+ depends on OF && HAS_IOMEM
+ select GENERIC_PHY
+ select GENERIC_PHY_MIPI_DPHY
+ select REGMAP_MMIO
+ help
+ Enable this to add support for the Mixel DSI PHY as found
+ on NXP's i.MX8 family of SOCs.
diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
index a459a44f6ecd..1d02e3869b45 100644
--- a/drivers/phy/freescale/Makefile
+++ b/drivers/phy/freescale/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o
+obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-fsl-imx8-mipi-dphy.o
diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
new file mode 100644
index ..9f2c1da14f5a
--- /dev/null
+++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
@@ -0,0 +1,497 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2017,2018 NXP
+ * Copyright 2019 Purism SPC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* DPHY registers */
+#define DPHY_PD_DPHY 0x00
+#define DPHY_M_PRG_HS_PREPARE 0x04
+#define DPHY_MC_PRG_HS_PREPARE 0x08
+#define DPHY_M_PRG_HS_ZERO 0x0c
+#define DPHY_MC_PRG_HS_ZERO0x10
+#define DPHY_M_PRG_HS_TRAIL0x14
+#define DPHY_MC_PRG_HS_TRAIL 0x18
+#define DPHY_PD_PLL0x1c
+#define DPHY_TST 0x20
+#define DPHY_CN0x24
+#define DPHY_CM0x28
+#define DPHY_CO0x2c
+#define DPHY_LOCK 0x30
+#define DPHY_LOCK_BYP 0x34
+#define DPHY_REG_BYPASS_PLL0x4C
+
+#define MBPS(x) ((x) * 100)
+
+#define DATA_RATE_MAX_SPEED MBPS(1500)
+#define DATA_RATE_MIN_SPEED MBPS(80)
+
+#define PLL_LOCK_SLEEP 10
+#define PLL_LOCK_TIMEOUT 1000
+
+#define CN_BUF 0xcb7a89c0
+#define CO_BUF 0x63
+#define CM(x) ( \
+ ((x) < 32) ? 0xe0 | ((x) - 16) : \
+ ((x) < 64) ? 0xc0 | ((x) - 32) : \
+ ((x) < 128) ? 0x80 | ((x) - 64) : \
+ ((x) - 128))
+#define CN(x) (((x) == 1) ? 0x1f : (((CN_BUF) >> ((x) - 1)) & 0x1f))
+#define CO(x) ((CO_BUF) >> (8 - (x)) & 0x03)
+
+/* PHY power on is active low */
+#define PWR_ON 0
+#define PWR_OFF1
+
+enum mixel_dphy_devtype {
+ MIXEL_IMX8MQ,
+};
+
+struct mixel_dphy_devdata {
+ u8 reg_tx_rcal;
+ u8 reg_auto_pd_en;
+ u8 reg_rxlprp;
+ u8 reg_rxcdrp;
+ u8 reg_rxhs_settle;
+};
+
+static const struct mixel_dphy_devdata mixel_dphy_devdata[] = {
+ [MIXEL_IMX8MQ] = {
+ .reg_tx_rcal = 0x38,
+ .reg_auto_pd_en = 0x3c,
+ .reg_rxlprp = 0x40,
+ .reg_rxcdrp = 0x44,
+ .reg_rxhs_settle = 0x48,
+ },
+};
+
+struct mixel_dphy_cfg {
+ /* DPHY PLL parameters */
+ u32 cm;
+ u32 cn;
+ u32 co;
+ /* DPHY register values */
+ u8 mc_prg_hs_prepare;
+ u8 m_prg_hs_prepare;
+ u8 mc_prg_hs_zero;
+ u8 m_prg_hs_zero;
+ u8 mc_prg_hs_trail;
+ u8 m_prg_hs_trail;
+ u8 rxhs_settle;
+};
+
+struct mixel_dphy_priv {
+ struct mixel_dphy_cfg cfg;
+ struct regmap *regmap;
+ struct clk *phy_ref_clk;
+ const struct mixel_dphy_devdata *devdata;
+};
+
+static const struct regmap_config mixel_dphy_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = DPHY_REG_BYPASS_PLL,
+ .name = "mipi-dphy",
+};
+
+static int phy_write(struct phy *phy, u32
[PATCH v12 1/2] dt-bindings: phy: Add documentation for mixel dphy
Add support for the MIXEL DPHY IP as found on NXP's i.MX8MQ SoCs.
Signed-off-by: Guido Günther
Reviewed-by: Sam Ravnborg
Reviewed-by: Rob Herring
Reviewed-by: Fabio Estevam
---
.../bindings/phy/mixel,mipi-dsi-phy.txt | 29 +++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
new file mode 100644
index ..9b23407233c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
@@ -0,0 +1,29 @@
+Mixel DSI PHY for i.MX8
+
+The Mixel MIPI-DSI PHY IP block is e.g. found on i.MX8 platforms (along the
+MIPI-DSI IP from Northwest Logic). It represents the physical layer for the
+electrical signals for DSI.
+
+Required properties:
+- compatible: Must be:
+ - "fsl,imx8mq-mipi-dphy"
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names: Must contain the following entries:
+ - "phy_ref": phandle and specifier referring to the DPHY ref clock
+- reg: the register range of the PHY controller
+- #phy-cells: number of cells in PHY, as defined in
+ Documentation/devicetree/bindings/phy/phy-bindings.txt
+ this must be <0>
+
+Optional properties:
+- power-domains: phandle to power domain
+
+Example:
+ dphy: dphy@30a0030 {
+ compatible = "fsl,imx8mq-mipi-dphy";
+ clocks = < IMX8MQ_CLK_DSI_PHY_REF>;
+ clock-names = "phy_ref";
+ reg = <0x30a00300 0x100>;
+ power-domains = <_mipi0>;
+ #phy-cells = <0>;
+};
--
2.20.1
[PATCH v12 0/2] Mixel MIPI DPHY support for NXPs i.MX8 SOCs
This adds initial support for the Mixel IP based mipi dphy as found on i.MX8
processors. It has support for the i.MX8MQ, support for other variants can be
added - once the platform specific parts are in - via the provided devdata.
The driver is somewhat based on what's found in NXPs BSP.
Public documentation on the DPHY's registers is currently thin in the i.MX8
reference manuals (even on the i.MX8QXP form 11/18) so most of the values were
taken from existing drivers. Newer NXP drivers have a bit more details so where
possible the timings are calculated and validated.
This was tested with the an initial version of a NWL MIPI DSI host
controller driver
https://lists.freedesktop.org/archives/dri-devel/2019-March/209685.html
and a forward ported DCSS driver on linux-next 20190617.
Robert Chiras (the author of the corresponding driver in NXPs vendor
tree) got this driver to work in his tree as well using mxsfb:
https://www.spinics.net/lists/arm-kernel/msg711950.html
Changes form v11
* as per review comments from Kishon Vijay Abraham I
* Use a single line debug message to not trip up check patch
Changes from v10
* Collect Reviewed-by: from Fabio Estevam
* Collect Reviewed-by: from Sam Ravnborg
* As per review comments from Sam Ravnborg
* Terminate all dev_{dbg,err} with '\n'
* Add more whitespace to CM/CN/CO macros
* Drop another non-ascii symbol in a debug message
Changes from v9
* As per review comments from Fabio Estevam
* Sort includes alphabetically
* Remove excessive new lines between functions
* Drop error message on devm_ioremap_resource, handled by
the core already.
* Don't default to it on i.MX8
* As per review comments from Sam Ravnborg
* Use clearer variablenames:
struct regmap *regs -> regmap
void __iomem *regs -> base
* Use u32 for all parameters of get_best_ratio()
* Don't use non-ascii symbols in debug message
* Change MODULE_LICENSE to GPL
* As per review comment from Andreas Färber
* Change co-authored-by: to co-developed-by:
* Collect Signed-off-by from Robert Chiras
Changes from v8
* Collect Reviewed-by from Rob Herring
* Fix {hs,clk}_prepare vs {hs,clk}_zero debug print out
Changes from v7
* As per review comments from Rob Herring
* Use fsl, as vendor prefix
* Drop changes to vendor-prefixes.txt due to that
* Shorten mixel_dphy to dphy in the example
* Fix an indentation error noticed by checkpatch that got introduced in v6
* Use lowercase letters in hex addresses in DT bindings example
Changes from v6
* Depend on HAS_IOMEM (fixes a build problem on UM spotted by kbuild)
Changes from v5
* Fix build problems on mips (spotted by the kbuild test robot) by using u32
consistently and long long for lp_t.
Changes from v4
* Build by default on ARCH_MXC && ARM64
Changes form v3
* Check correct variable after devm_ioremap_resource
* Add Robert Chiras as Co-authored-by since he's the author
of the driver in NXPs BSP.
Changes from v2
* As per review comments from Fabio Estevam
* KConfig: select REGMAP_MMIO
* Drop phy_read
* Don't make phy_write inline
* Remove duplicate debugging output
* Comment style and typo fixes
* Add #defines's for PLL lock timing values
* Return correct error value when PLL fails to lock
* Check error when enabling clock
* Use devm_ioremap_resource
* As per review comments from Robert Chiras
* Deassert PD_DPHY after PLL lock (as per mixel ref manual)
* Assert PD_{DPHY,PLL} before power on (as per mixel ref manual)manual
* Add exit phy_op to reset CN/CM/CO
Changes from v1
* As per review comments from Fabio Estevam
* Kconfig: tristate mixel dphy support.
* Drop unused 'ret' in mixel_dphy_ref_power_off.
* Match values of DPHY_RXL{PRP,DRP} to those of
https://source.codeaurora.org/external/imx/linux-imx/log/?h=imx_4.14.78_1.0.0_ga
The previous values were based on 4.9.
* Use resource size on devm_ioremap, we have that in dt already.
* Use regmap so it's simple to dump the registers.
* Use regmap_read_poll_timeout instead of open coded loop.
* Add undocumented rxhs_settle register
* As per review comments from Sam Ravnborg
* Move driver to d/phy/freescale/
* Move SPDX-License-Identifier to top of file.
* Drop '/* #define DEBUG 1 */'.
* Use GPL-2.0+ since the vendor driver uses that as well.
* Drop the mutex, register access is now protected by regmap.
* Fix various style / indentation issues.
* Check for register read, write and ioremap errors
* Improve phy timing calculations
* Use LP clock rate where sensible, check for errors
* Use ad hoc forumulas for timings involving hs clock
* Switch from dphy_ops to devdata. Other i.MX8 variants
differ in register layout too
* Add Mixel Inc to vendor-prefixes.txt
To: Kishon Vijay Abraham I ,Rob Herring
,Mark Rutland ,Shawn Guo
,Sascha Hauer ,Pengutronix Kernel
Team ,Fabio Estevam ,NXP Linux Team
,Thierry Reding ,"Andreas Färber"
,Martin Blumenstingl
,Heiko Stuebner ,Johan
Hovold ,Lucas Stach
Re: [PATCH 04/22] mm: don't clear ->mapping in hmm_devmem_free
On Thu 13-06-19 11:43:07, Christoph Hellwig wrote:
> ->mapping isn't even used by HMM users, and the field at the same offset
> in the zone_device part of the union is declared as pad. (Which btw is
> rather confusing, as DAX uses ->pgmap and ->mapping from two different
> sides of the union, but DAX doesn't use hmm_devmem_free).
>
> Signed-off-by: Christoph Hellwig
I cannot really judge here but setting mapping here without any comment
is quite confusing. So if this is safe to remove then it is certainly an
improvement.
> ---
> mm/hmm.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 0c62426d1257..e1dc98407e7b 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -1347,8 +1347,6 @@ static void hmm_devmem_free(struct page *page, void
> *data)
> {
> struct hmm_devmem *devmem = data;
>
> - page->mapping = NULL;
> -
> devmem->ops->free(devmem, page);
> }
>
> --
> 2.20.1
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/22] mm: remove hmm_devmem_add_resource
On Thu 13-06-19 11:43:06, Christoph Hellwig wrote:
> This function has never been used since it was first added to the kernel
> more than a year and a half ago, and if we ever grow a consumer of the
> MEMORY_DEVICE_PUBLIC infrastructure it can easily use devm_memremap_pages
> directly now that we've simplified the API for it.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Michal Hocko
> ---
> include/linux/hmm.h | 3 ---
> mm/hmm.c| 54 -
> 2 files changed, 57 deletions(-)
>
> diff --git a/include/linux/hmm.h b/include/linux/hmm.h
> index 4867b9da1b6c..5761a39221a6 100644
> --- a/include/linux/hmm.h
> +++ b/include/linux/hmm.h
> @@ -688,9 +688,6 @@ struct hmm_devmem {
> struct hmm_devmem *hmm_devmem_add(const struct hmm_devmem_ops *ops,
> struct device *device,
> unsigned long size);
> -struct hmm_devmem *hmm_devmem_add_resource(const struct hmm_devmem_ops *ops,
> -struct device *device,
> -struct resource *res);
>
> /*
> * hmm_devmem_page_set_drvdata - set per-page driver data field
> diff --git a/mm/hmm.c b/mm/hmm.c
> index ff2598eb7377..0c62426d1257 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -1445,58 +1445,4 @@ struct hmm_devmem *hmm_devmem_add(const struct
> hmm_devmem_ops *ops,
> return devmem;
> }
> EXPORT_SYMBOL_GPL(hmm_devmem_add);
> -
> -struct hmm_devmem *hmm_devmem_add_resource(const struct hmm_devmem_ops *ops,
> -struct device *device,
> -struct resource *res)
> -{
> - struct hmm_devmem *devmem;
> - void *result;
> - int ret;
> -
> - if (res->desc != IORES_DESC_DEVICE_PUBLIC_MEMORY)
> - return ERR_PTR(-EINVAL);
> -
> - dev_pagemap_get_ops();
> -
> - devmem = devm_kzalloc(device, sizeof(*devmem), GFP_KERNEL);
> - if (!devmem)
> - return ERR_PTR(-ENOMEM);
> -
> - init_completion(>completion);
> - devmem->pfn_first = -1UL;
> - devmem->pfn_last = -1UL;
> - devmem->resource = res;
> - devmem->device = device;
> - devmem->ops = ops;
> -
> - ret = percpu_ref_init(>ref, _devmem_ref_release,
> - 0, GFP_KERNEL);
> - if (ret)
> - return ERR_PTR(ret);
> -
> - ret = devm_add_action_or_reset(device, hmm_devmem_ref_exit,
> - >ref);
> - if (ret)
> - return ERR_PTR(ret);
> -
> - devmem->pfn_first = devmem->resource->start >> PAGE_SHIFT;
> - devmem->pfn_last = devmem->pfn_first +
> -(resource_size(devmem->resource) >> PAGE_SHIFT);
> - devmem->page_fault = hmm_devmem_fault;
> -
> - devmem->pagemap.type = MEMORY_DEVICE_PUBLIC;
> - devmem->pagemap.res = *devmem->resource;
> - devmem->pagemap.page_free = hmm_devmem_free;
> - devmem->pagemap.altmap_valid = false;
> - devmem->pagemap.ref = >ref;
> - devmem->pagemap.data = devmem;
> - devmem->pagemap.kill = hmm_devmem_ref_kill;
> -
> - result = devm_memremap_pages(devmem->device, >pagemap);
> - if (IS_ERR(result))
> - return result;
> - return devmem;
> -}
> -EXPORT_SYMBOL_GPL(hmm_devmem_add_resource);
> #endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
> --
> 2.20.1
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 18/22] mm: mark DEVICE_PUBLIC as broken
On Thu 13-06-19 11:43:21, Christoph Hellwig wrote: > The code hasn't been used since it was added to the tree, and doesn't > appear to actually be usable. Mark it as BROKEN until either a user > comes along or we finally give up on it. I would go even further and simply remove all the DEVICE_PUBLIC code. > Signed-off-by: Christoph Hellwig Anyway Acked-by: Michal Hocko > --- > mm/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/Kconfig b/mm/Kconfig > index 0d2ba7e1f43e..406fa45e9ecc 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -721,6 +721,7 @@ config DEVICE_PRIVATE > config DEVICE_PUBLIC > bool "Addressable device memory (like GPU memory)" > depends on ARCH_HAS_HMM > + depends on BROKEN > select HMM > select DEV_PAGEMAP_OPS > > -- > 2.20.1 -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/22] mm: export alloc_pages_vma
On Thu 13-06-19 11:43:08, Christoph Hellwig wrote: > noveau is currently using this through an odd hmm wrapper, and I plan > to switch it to the real thing later in this series. > > Signed-off-by: Christoph Hellwig > --- > mm/mempolicy.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/mempolicy.c b/mm/mempolicy.c > index 01600d80ae01..f9023b5fba37 100644 > --- a/mm/mempolicy.c > +++ b/mm/mempolicy.c > @@ -2098,6 +2098,7 @@ alloc_pages_vma(gfp_t gfp, int order, struct > vm_area_struct *vma, > out: > return page; > } > +EXPORT_SYMBOL_GPL(alloc_pages_vma); All allocator exported symbols are EXPORT_SYMBOL, what is a reason to have this one special? -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits
On Tue, Jun 18, 2019 at 8:15 PM Chen-Yu Tsai wrote: > > On Tue, Jun 18, 2019 at 8:11 PM Jagan Teki wrote: > > > > On Tue, Jun 18, 2019 at 5:13 PM Chen-Yu Tsai wrote: > > > > > > On Tue, Jun 18, 2019 at 6:51 PM Jagan Teki > > > wrote: > > > > > > > > On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard > > > > wrote: > > > > > > > > > > On Fri, Jun 14, 2019 at 12:03:13PM +0530, Jagan Teki wrote: > > > > > > On Thu, Jun 13, 2019 at 6:56 PM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Jun 05, 2019 at 01:17:11PM +0530, Jagan Teki wrote: > > > > > > > > On Tue, Jun 4, 2019 at 3:30 PM Maxime Ripard > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Wed, May 29, 2019 at 11:44:56PM +0530, Jagan Teki wrote: > > > > > > > > > > On Wed, May 29, 2019 at 8:24 PM Maxime Ripard > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:48:51PM +0530, Jagan Teki > > > > > > > > > > > wrote: > > > > > > > > > > > > On Fri, May 24, 2019 at 2:04 AM Maxime Ripard > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > According to "DRM kernel-internal display mode > > > > > > > > > > > > > > structure" in > > > > > > > > > > > > > > include/drm/drm_modes.h the current driver is > > > > > > > > > > > > > > trying to include > > > > > > > > > > > > > > sync timings along with front porch value while > > > > > > > > > > > > > > checking and > > > > > > > > > > > > > > computing drq set bits in non-burst mode. > > > > > > > > > > > > > > > > > > > > > > > > > > > > mode->hsync_end - mode->hdisplay => horizontal > > > > > > > > > > > > > > front porch + sync > > > > > > > > > > > > > > > > > > > > > > > > > > > > With adding additional sync timings, the dsi > > > > > > > > > > > > > > controller leads to > > > > > > > > > > > > > > wrong drq set bits for "bananapi,s070wv20-ct16" > > > > > > > > > > > > > > panel which indeed > > > > > > > > > > > > > > trigger panel flip_done timed out as: > > > > > > > > > > > > > > > > > > > > > > > > > > > > WARNING: CPU: 0 PID: 31 at > > > > > > > > > > > > > > drivers/gpu/drm/drm_atomic_helper.c:1429 > > > > > > > > > > > > > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > > > > > > > > > > > > > [CRTC:46:crtc-0] vblank wait timed out > > > > > > > > > > > > > > Modules linked in: > > > > > > > > > > > > > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > > > > > > > > > > > > > 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 > > > > > > > > > > > > > > Hardware name: Allwinner sun8i Family > > > > > > > > > > > > > > Workqueue: events deferred_probe_work_func > > > > > > > > > > > > > > [] (unwind_backtrace) from [] > > > > > > > > > > > > > > (show_stack+0x10/0x14) > > > > > > > > > > > > > > [] (show_stack) from [] > > > > > > > > > > > > > > (dump_stack+0x84/0x98) > > > > > > > > > > > > > > [] (dump_stack) from [] > > > > > > > > > > > > > > (__warn+0xfc/0x114) > > > > > > > > > > > > > > [] (__warn) from [] > > > > > > > > > > > > > > (warn_slowpath_fmt+0x44/0x68) > > > > > > > > > > > > > > [] (warn_slowpath_fmt) from [] > > > > > > > > > > > > > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > > > > > > > > > > > > > [] > > > > > > > > > > > > > > (drm_atomic_helper_wait_for_vblanks.part.1) from > > > > > > > > > > > > > > [] > > > > > > > > > > > > > > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > > > > > > > > > > > > > [] (drm_atomic_helper_commit_tail_rpm) > > > > > > > > > > > > > > from [] (commit_tail+0x40/0x6c) > > > > > > > > > > > > > > [] (commit_tail) from [] > > > > > > > > > > > > > > (drm_atomic_helper_commit+0xbc/0x128) > > > > > > > > > > > > > > [] (drm_atomic_helper_commit) from > > > > > > > > > > > > > > [] (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > > > > > > > > > > > > > [] (restore_fbdev_mode_atomic) from > > > > > > > > > > > > > > [] > > > > > > > > > > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > > > > > > > > > > > > > > [] > > > > > > > > > > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked) from > > > > > > > > > > > > > > [] (drm_fb_helper_set_par+0x30/0x54) > > > > > > > > > > > > > > [] (drm_fb_helper_set_par) from > > > > > > > > > > > > > > [] (fbcon_init+0x560/0x5ac) > > > > > > > > > > > > > > [] (fbcon_init) from [] > > > > > > > > > > > > > > (visual_init+0xbc/0x104) > > > > > > > > > > > > > > [] (visual_init) from [] > > > > > > > > > > > > > > (do_bind_con_driver+0x1b0/0x390) > > > > > > > > > > > > > > [] (do_bind_con_driver) from > > > > > > > > > > > > > > [] (do_take_over_console+0x13c/0x1c4) > > > > > > > > > > > > > > [] (do_take_over_console) from > > > > > > > > > > > > > > [] (do_fbcon_takeover+0x74/0xcc) > > > > > > > > > > > > > > [] (do_fbcon_takeover) from [] > > > > > > > > > > > > > >
[PATCH 1/2] drm: Pretty print mode flags
From: Ville Syrjälä
Decode the mode flags when printing the modeline so that I
no longer have to decode the hex number myself.
To do this neatly I made the caller provide a temporary
on stack buffer where we can produce the results. I choce 64
bytes as a reasonable size for this. The worst case I think
is > 100 bytes but that kind of mode would be nonsense anyway
so I figured correct decoding isn't as important in such
cases.
Cc: Russell King
Cc: Neil Armstrong
Cc: Rob Clark
Cc: Tomi Valkeinen
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Benjamin Gaignard
Cc: Vincent Abriou
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/armada/armada_crtc.c | 3 +-
drivers/gpu/drm/drm_atomic.c | 3 +-
drivers/gpu/drm/drm_modes.c | 116 +-
drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
drivers/gpu/drm/meson/meson_dw_hdmi.c | 3 +-
drivers/gpu/drm/meson/meson_venc.c| 4 +-
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 3 +-
.../gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c | 3 +-
.../gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c | 3 +-
.../gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 3 +-
.../gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 4 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 3 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 3 +-
drivers/gpu/drm/msm/dsi/dsi_manager.c | 3 +-
drivers/gpu/drm/msm/edp/edp_bridge.c | 3 +-
drivers/gpu/drm/omapdrm/omap_connector.c | 5 +-
drivers/gpu/drm/omapdrm/omap_crtc.c | 3 +-
drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 3 +-
drivers/gpu/drm/sti/sti_crtc.c| 3 +-
include/drm/drm_modes.h | 14 ++-
20 files changed, 165 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index ba4a3fab7745..ce9335682bd2 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -262,6 +262,7 @@ static void armada_drm_crtc_mode_set_nofb(struct drm_crtc
*crtc)
unsigned long flags;
unsigned i;
bool interlaced = !!(adj->flags & DRM_MODE_FLAG_INTERLACE);
+ char buf[DRM_MODE_FLAGS_BUF_LEN];
i = 0;
rm = adj->crtc_hsync_start - adj->crtc_hdisplay;
@@ -270,7 +271,7 @@ static void armada_drm_crtc_mode_set_nofb(struct drm_crtc
*crtc)
tm = adj->crtc_vtotal - adj->crtc_vsync_end;
DRM_DEBUG_KMS("[CRTC:%d:%s] mode " DRM_MODE_FMT "\n",
- crtc->base.id, crtc->name, DRM_MODE_ARG(adj));
+ crtc->base.id, crtc->name, DRM_MODE_ARG(adj, buf));
DRM_DEBUG_KMS("lm %d rm %d tm %d bm %d\n", lm, rm, tm, bm);
/* Now compute the divider for real */
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 419381abbdd1..81caf91fbd72 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -380,6 +380,7 @@ static void drm_atomic_crtc_print_state(struct drm_printer
*p,
const struct drm_crtc_state *state)
{
struct drm_crtc *crtc = state->crtc;
+ char buf[DRM_MODE_FLAGS_BUF_LEN];
drm_printf(p, "crtc[%u]: %s\n", crtc->base.id, crtc->name);
drm_printf(p, "\tenable=%d\n", state->enable);
@@ -393,7 +394,7 @@ static void drm_atomic_crtc_print_state(struct drm_printer
*p,
drm_printf(p, "\tplane_mask=%x\n", state->plane_mask);
drm_printf(p, "\tconnector_mask=%x\n", state->connector_mask);
drm_printf(p, "\tencoder_mask=%x\n", state->encoder_mask);
- drm_printf(p, "\tmode: " DRM_MODE_FMT "\n", DRM_MODE_ARG(>mode));
+ drm_printf(p, "\tmode: " DRM_MODE_FMT "\n", DRM_MODE_ARG(>mode,
buf));
if (crtc->funcs->atomic_print_state)
crtc->funcs->atomic_print_state(p, state);
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 57e6408288c8..3d15c600295a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -45,6 +45,118 @@
#include "drm_crtc_internal.h"
+static char *snprint_cont(char *buf, int *len,
+ const char *str, bool last)
+{
+ int r;
+
+ r = snprintf(buf, *len, "%s%s", str, last ? "" : ",");
+ if (r >= *len)
+ return buf;
+
+ *len -= r;
+ buf += r;
+
+ return buf;
+}
+
+#define MODE_STR(x) { .name = #x, .flag = DRM_MODE_FLAG_ ## x, }
+
+static const struct {
+ const char *name;
+ u32 flag;
+} mode_flags[] = {
+ MODE_STR(PHSYNC),
+ MODE_STR(NHSYNC),
+ MODE_STR(PVSYNC),
+ MODE_STR(NVSYNC),
+ MODE_STR(INTERLACE),
+ MODE_STR(CSYNC),
+ MODE_STR(PCSYNC),
+ MODE_STR(NCSYNC),
+ MODE_STR(DBLSCAN),
+ MODE_STR(HSKEW),
+ MODE_STR(DBLCLK),
+
[PATCH v2 2/2] drm: Dump mode picture aspect ratio
From: Ville Syrjälä
Currently the logs show nothing about the mode's aspect ratio.
Include that information in the normal mode dump.
v2: Don't print anything for NONE (Ilia)
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c| 3 ++-
include/drm/drm_modes.h | 6 --
include/linux/hdmi.h| 3 +++
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index b939bc28d886..bc593fe1c268 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1057,7 +1057,7 @@ static const char *hdmi_colorimetry_get_name(enum
hdmi_colorimetry colorimetry)
return "Invalid";
}
-static const char *
+const char *
hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect)
{
switch (picture_aspect) {
@@ -1076,6 +1076,7 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect
picture_aspect)
}
return "Invalid";
}
+EXPORT_SYMBOL(hdmi_picture_aspect_get_name);
static const char *
hdmi_active_aspect_get_name(enum hdmi_active_aspect active_aspect)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 3962dbf82100..0a724874fd84 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -436,7 +436,7 @@ struct drm_display_mode {
/**
* DRM_MODE_FMT - printf string for drm_display_mode
*/
-#define DRM_MODE_FMT"\"%s\": %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x %s"
+#define DRM_MODE_FMT"\"%s\": %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x %s %s"
/**
* DRM_MODE_ARG - printf arguments for drm_display_mode
@@ -448,7 +448,9 @@ struct drm_display_mode {
(m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
(m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
(m)->type, (m)->flags, \
- drm_get_mode_flags_name(b, sizeof(b), (m)->flags)
+ drm_get_mode_flags_name(b, sizeof(b), (m)->flags), \
+ (m)->picture_aspect_ratio ? \
+ hdmi_picture_aspect_get_name((m)->picture_aspect_ratio) : ""
#define obj_to_mode(x) container_of(x, struct drm_display_mode, base)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 9918a6c910c5..de7cbe385dba 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -434,4 +434,7 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
void hdmi_infoframe_log(const char *level, struct device *dev,
const union hdmi_infoframe *frame);
+const char *
+hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect);
+
#endif /* _DRM_HDMI_H */
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
On Fri, Jun 14, 2019 at 7:54 PM Maxime Ripard wrote: > > On Wed, Jun 05, 2019 at 01:03:16PM +0530, Jagan Teki wrote: > > On Wed, Jun 5, 2019 at 12:19 PM Maxime Ripard > > wrote: > > > > > > Hi, > > > > > > I've reordered the mail a bit to work on chunks > > > > > > On Fri, May 24, 2019 at 03:37:42PM +0530, Jagan Teki wrote: > > > > > I wish it was in your commit log in the first place, instead of having > > > > > to exchange multiple mails over this. > > > > > > > > > > However, I don't think that's quite true, and it might be a bug in > > > > > Allwinner's implementation (or rather something quite confusing). > > > > > > > > > > You're right that the lcd_rate and pll_rate seem to be generated from > > > > > the pixel clock, and it indeed looks like the ratio between the pixel > > > > > clock and the TCON dotclock is defined through the number of bits per > > > > > lanes. > > > > > > > > > > However, in this case, dsi_rate is actually the same than lcd_rate, > > > > > since pll_rate is going to be divided by dsi_div: > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L791 > > > > > > > > > > Since lcd_div is 1, it also means that in this case, dsi_rate == > > > > > dclk_rate. > > > > > > > > > > The DSI module clock however, is always set to 148.5 MHz. Indeed, if > > > > > we look at: > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L804 > > > > > > > > > > We can see that the rate in clk_info is used if it's different than > > > > > 0. This is filled by disp_al_lcd_get_clk_info, which, in the case of a > > > > > DSI panel, will hardcode it to 148.5 MHz: > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L164 > > > > > > > > Let me explain, something more. > > > > > > > > According to bsp there are clk_info.tcon_div which I will explain below. > > > > clk_info.dsi_div which is dynamic and it depends on bpp/lanes, so it > > > > is 6 for 24bpp and 4 lanes devices. > > > > > > > > PLL rate here depends on dsi_div (not tcon_div) > > > > > > > > Code here > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L784 > > > > > > > > is computing the actual set rate, which depends on dsi_rate. > > > > > > > > lcd_rate = dclk_rate * clk_info.dsi_div; > > > > dsi_rate = pll_rate / clk_info.dsi_div; > > > > > > > > Say if the dclk_rate 148MHz then the dsi_rate is 888MHz which set rate > > > > for above link you mentioned. > > > > > > > > Here are the evidence with some prints. > > > > > > > > https://gist.github.com/openedev/9bae2d87d2fcc06b999fe48c998b7043 > > > > https://gist.github.com/openedev/700de2e3701b2bf3ad1aa0f0fa862c9a > > > > > > Ok, so we agree up to this point, and the prints confirm that the > > > analysis above is the right one. > > > > > > > > So, the DSI clock is set to this here: > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L805 > > > > > > Your patch doesn't address that, so let's leave that one alone. > > > > Basically this is final pll set rate when sun4i_dotclock.c called the > > desired rate with ccu_nkm.c so it ended the final rate with parent as > > Line 8 of > > https://gist.github.com/openedev/700de2e3701b2bf3ad1aa0f0fa862c9a > > If that's important to the driver, it should be set explicitly then, > and not work by accident. > > > > > > The TCON *module* clock (the one in the clock controller) has been set > > > > > to lcd_rate (so the pixel clock times the number of bits per lane) > > > > > here: > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L800 > > > > > > > > > > And the PLL has been set to the same rate here: > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L794 > > > > > > > > > > Let's take a step back now: that function we were looking at, > > > > > lcd_clk_config, is called by lcd_clk_enable, which is in turn called > > > > > by disp_lcd_enable here: > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L1328 > > > > > > > > > > The next function being called is disp_al_lcd_cfg, and that function > > > > > will hardcode the TCON dotclock divider to 4, here: > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L240 > > > > > > > > tcon_div from BSP point-of-view of there are two variants > > > > 00) clk_info.tcon_div which is 4 and same is set the divider position > > > > in SUN4I_TCON0_DCLK_REG (like above link refer) > > > > 01) tcon_div which is 4 and used for edge timings computation > > > >
Re: [PATCH 2/3] drm/rockchip: Add optional support for CRTC gamma LUT
Hi,
On Tue, Jun 18, 2019 at 2:43 PM Ezequiel Garcia wrote:
>
> +static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
> + struct drm_crtc_state *old_state)
> +{
> + int idle, ret, i;
> +
> + spin_lock(>reg_lock);
> + VOP_REG_SET(vop, common, dsp_lut_en, 0);
> + vop_cfg_done(vop);
> + spin_unlock(>reg_lock);
> +
> + ret = readx_poll_timeout(vop_dsp_lut_is_enable, vop,
> + idle, !idle, 5, 30 * 1000);
> + if (ret)
Worth an error message?
> @@ -1205,6 +1294,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
>
> static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
> .mode_fixup = vop_crtc_mode_fixup,
> + .atomic_check = vop_crtc_atomic_check,
At first I was worried that there was a bug here since in the context
of dw_hdmi (an encoder) adding ".atomic_check" caused ".mode_fixup" to
stop getting called as per mode_fixup() in
"drivers/gpu/drm/drm_atomic_helper.c".
...but it seems like it's OK for CRTCs, so I think we're fine.
> @@ -1323,6 +1413,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
> .disable_vblank = vop_crtc_disable_vblank,
> .set_crc_source = vop_crtc_set_crc_source,
> .verify_crc_source = vop_crtc_verify_crc_source,
> + .gamma_set = drm_atomic_helper_legacy_gamma_set,
Are there any issues in adding this ".gamma_set" property even though
we may or may not actually have the ability to set the gamma
(depending on whether or not the LUT register range was provided in
the device tree)? I am a DRM noob but
drm_atomic_helper_legacy_gamma_set() is not a trivial little function
and now we'll be running it in some cases where we don't actually have
gamma.
I also notice that there's at least one bit of code that seems to
check if ".gamma_set" is NULL. ...and if it is, it'll return -ENOSYS
right away. Do we still properly return -ENOSYS on devices that don't
have the register range?
It seems like the absolute safest would be to have two copies of this
struct: one used for VOPs that have the range and one for VOPs that
don't.
...but possibly I'm just paranoid and as I've said I'm a clueless
noob. If someone says it's fine to always provide the .gamma_set
property that's fine too.
> static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
> @@ -1480,6 +1571,10 @@ static int vop_create_crtc(struct vop *vop)
> goto err_cleanup_planes;
>
> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> + if (vop_data->lut_size) {
> + drm_mode_crtc_set_gamma_size(crtc, vop_data->lut_size);
> + drm_crtc_enable_color_mgmt(crtc, 0, false,
> vop_data->lut_size);
Should we only do the above calls if we successfully mapped the resources?
> @@ -1776,6 +1871,17 @@ static int vop_bind(struct device *dev, struct device
> *master, void *data)
> if (IS_ERR(vop->regs))
> return PTR_ERR(vop->regs);
>
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lut");
As per comments in the bindings, shouldn't use the name "lut" but
should just pick resource #1.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/stm: drv: fix suspend/resume
Hi Yannick,
On Mon, 17 Jun 2019 at 08:18, Yannick Fertré wrote:
> @@ -155,15 +154,17 @@ static __maybe_unused int drv_resume(struct device *dev)
> struct ltdc_device *ldev = ddev->dev_private;
> int ret;
>
> + if (WARN_ON(!ldev->suspend_state))
> + return -ENOENT;
> +
> pm_runtime_force_resume(dev);
> ret = drm_atomic_helper_resume(ddev, ldev->suspend_state);
> - if (ret) {
> + if (ret)
Hmm the msm driver uses !ret here. Suspecting that you want the same,
although I haven't checked in detail.
HTH
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dt-bindings: display: rockchip: document VOP gamma LUT address
On Thu, 2019-06-20 at 09:43 -0700, Doug Anderson wrote: > Hi, > > On Tue, Jun 18, 2019 at 2:43 PM Ezequiel Garcia > wrote: > > Add the register specifier description for an > > optional gamma LUT address. > > > > Signed-off-by: Ezequiel Garcia > > --- > > .../bindings/display/rockchip/rockchip-vop.txt | 10 +- > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > diff --git > > a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt > > b/Documentation/devicetree/bindings/display/rockchip/rockchip- > > vop.txt > > index 4f58c5a2d195..97ad78cc7e03 100644 > > --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt > > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt > > @@ -20,6 +20,13 @@ Required properties: > > "rockchip,rk3228-vop"; > > "rockchip,rk3328-vop"; > > > > +- reg: Must contain one entry corresponding to the base address and length > > + of the register space. Can optionally contain a second entry > > + corresponding to the CRTC gamma LUT address. > > + > > +- reg-names: "base" for the base register space. If present, the CRTC > > + gamma LUT name should be "lut". > > As per Rob Herring, current suggestion is to avoid reg-names when > possible. The code should just look for the presence of a 2nd entry > and assume that if it's there that it's the lut range. Full context: > > > https://lore.kernel.org/lkml/CAL_Jsq+MMunmVWqeW9v2RyzsMKP+=kmzethnmg4jdhm7fy0...@mail.gmail.com/ > Oh, that's news to me. I was assuming having reg-names was preferred. Thanks for the feedback, I'll send a new version. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: correct order of crtc disable
On Thu, 2019-06-20 at 18:29 +0200, Daniel Vetter wrote:
> On Thu, Jun 20, 2019 at 3:30 PM Robert Beckett
> wrote:
> > On Thu, 2019-06-20 at 14:32 +0200, Daniel Vetter wrote:
> > > On Thu, Jun 20, 2019 at 12:12:13PM +0100, Robert Beckett wrote:
> > > > On Thu, 2019-06-20 at 10:50 +0200, Daniel Vetter wrote:
> > > > > On Wed, Jun 19, 2019 at 11:40 AM Philipp Zabel <
> > > > > p.za...@pengutronix.de> wrote:
> > > > > >
> > > > > > Hi Robert,
> > > > > >
> > > > > > thank you for the patch.
> > > > > >
> > > > > > On Tue, 2019-06-18 at 16:50 +0100, Robert Beckett wrote:
> > > > > > > Notify drm core before sending pending events during crtc
> > > > > > > disable.
> > > > > > > This fixes the first event after disable having an old
> > > > > > > stale
> > > > > > > timestamp
> > > > > > > by having drm_crtc_vblank_off update the timestamp to
> > > > > > > now.
> > > > > > >
> > > > > > > This was seen while debugging weston log message:
> > > > > > > Warning: computed repaint delay is insane: -8212 msec
> > > > > > >
> > > > > >
> > > > > > Would you say this
> > > > > > Fixes: a474478642d5 ("drm/imx: fix crtc vblank state
> > > > > > regression")
> > > > > > ?
> > > > > >
> > > > > > > Signed-off-by: Robert Beckett
> > > > > > > ---
> > > > > > > drivers/gpu/drm/imx/ipuv3-crtc.c | 6 +++---
> > > > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > > > > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > > > > index 9cc1d678674f..c436a28d50e4 100644
> > > > > > > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > > > > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > > > > @@ -91,14 +91,14 @@ static void
> > > > > > > ipu_crtc_atomic_disable(struct
> > > > > > > drm_crtc *crtc,
> > > > > > > ipu_dc_disable(ipu);
> > > > > > > ipu_prg_disable(ipu);
> > > > > > >
> > > > > > > + drm_crtc_vblank_off(crtc);
> > > > > > > +
> > > > > >
> > > > > > This is explained in the commit message and aligns with the
> > > > > > drm_crtc_state @event documentation.
> > > > >
> > > > > This part here looks fishy. The drm_vblank.c code is supposed
> > > > > to
> > > > > do
> > > > > the right thing, no matter where or when you ask it to
> > > > > generate
> > > > > an
> > > > > event. It definitely shouldn't generate a timestamp that's a
> > > > > few
> > > > > seconds too early. Bunch of options:
> > > > > - there's a bug in drm_vblank.c and it's mixing up something
> > > > > and
> > > > > generating a totally bogus value.
> > > > > - there's a lie in your imx vblank code, which trips the
> > > > > drm_vblank.c
> > > > > counter interpolation and results in a totally bogus value.
> > > > >
> > > > > drm_vblank.c assumes that if you do claim to have a hw
> > > > > counter
> > > > > and
> > > > > generate timestamps, that those are perfectly accurate. It
> > > > > only
> > > > > falls
> > > > > back to guestimating using the system timer if that's not
> > > > > present.
> > > > >
> > > > > Either way, this very much smells like papering over a bug if
> > > > > this
> > > > > change indeed fixes your wrong vblank timestamps.
> > > > >
> > > >
> > > > A quick explaination of where the dodgy timestamp came from:
> > > > 1. driver starts up
> > > > 2. fbcon comes along and restores fbdev, enabling vblank
> > > > 3. vblank_disable_fn fires via timer disabling vblank, keeping
> > > > vblank
> > > > seq number and time set at current value
> > > > (some time later)
> > > > 4. weston starts and does a modeset
> > > > 5. atomic commit disables crtc while it does the modeset
> > > > 6. ipu_crtc_atomic_disable sends vblank with old seq number and
> > > > time
> > > >
> > > > It turns out the actual fix for the old vblank is the next
> > > > change,
> > > > which stops it being sent at all during the crtc disable as it
> > > > is
> > > > is
> > > > still active, it would then go through drm_crtc_vblank_off,
> > > > reseting
> > > > the timestamp, and get delivered during the vblank enable as
> > > > part
> > > > of
> > > > the atomic commit.
> > >
> > > This shouldn't fix your vblank timestamp troubles either. It
> > > might
> > > mean
> > > that the timestamp is slightly too early (because you take it
> > > while
> > > shutting down the crtc, not while re-enabling), but not by
> > > seconds.
> > >
> > > Quick experiment: Disable vblank disabling with
> > > drm.vblankoffdelay =
> > > 0. If
> > > that also fixes the timestamps, then I'm pretty sure you have a
> > > driver bug
> > > somewhere and lie to the vblank core code about something.
> > > -Daniel
> > >
> >
> > Experiment done. The timestamp is fine, it is the timestamp of the
> > previous vblank update. But, this would fix it because the vblank
> > interrupt was never disabled.
> >
> > The original issue was that the event got sent after vblank was
> > disabled and before it got re-enabled during the modeset, so
> > nothing
> > had happened to update the timestamp and seq
Re: [PATCH 1/3] dt-bindings: display: rockchip: document VOP gamma LUT address
Hi, On Tue, Jun 18, 2019 at 2:43 PM Ezequiel Garcia wrote: > > Add the register specifier description for an > optional gamma LUT address. > > Signed-off-by: Ezequiel Garcia > --- > .../bindings/display/rockchip/rockchip-vop.txt | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt > b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt > index 4f58c5a2d195..97ad78cc7e03 100644 > --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt > @@ -20,6 +20,13 @@ Required properties: > "rockchip,rk3228-vop"; > "rockchip,rk3328-vop"; > > +- reg: Must contain one entry corresponding to the base address and length > + of the register space. Can optionally contain a second entry > + corresponding to the CRTC gamma LUT address. > + > +- reg-names: "base" for the base register space. If present, the CRTC > + gamma LUT name should be "lut". As per Rob Herring, current suggestion is to avoid reg-names when possible. The code should just look for the presence of a 2nd entry and assume that if it's there that it's the lut range. Full context: https://lore.kernel.org/lkml/CAL_Jsq+MMunmVWqeW9v2RyzsMKP+=kmzethnmg4jdhm7fy0...@mail.gmail.com/ -Doug
Re: [linux-sunxi] [PATCH v7 0/6] Add support for Orange Pi 3
Hi Jernej, On Thu, Jun 20, 2019 at 05:53:58PM +0200, Jernej Škrabec wrote: > Hi! > > Dne četrtek, 20. junij 2019 ob 15:47:42 CEST je megous via linux-sunxi > napisal(a): > > From: Ondrej Jirman > > > > This series implements support for Xunlong Orange Pi 3 board. > > > > - ethernet support (patches 1-3) > > Correct me if I'm wrong, but patches 1-2 aren't strictly necessary for > OrangePi 3, right? H6 DTSI already has emac node with dual compatible (H6 and > A64) and since OrangePi 3 uses gigabit ethernet, quirk introduced by patches > 1-2 are not needed. I've checked with u-boot and md.l 0x0330 (syscon_field) and the actual default value there on cold boot is 0x58000, just like on H3. H3_EPHY_SELECT is BIT(15) That means that those patches (1 and 2) are both doing the same thing, basicaly. H3_EPHY_SELECT bit needs to be cleared, and it is cleared either explicitly, or via default_syscon_value = 0x5. It's also cleared incidentally by using emac_variant_a64, because it has default_syscon_value set to 0. Meaning of those remaining set bits on H6[1] are the same as on H3. Bit 16 is SHUTDOWN (on 1) and bit 18 is CLK_SEL. At least SHUTDOWN bit should be kept high, as it keeps the EPHY shut down. Normally that would be ensured by the code, but only if soc_has_internal_phy is true, which it is not for emac_variant_a64. Thus the patch adds the emac_variant_h6 with a different default_syscon_value from A64. Dose the SHUTDOWN bit matter on H6? I don't know. I'm just trying to keep the default values of these bits unchanged. Maybe it would be nicer to have default_syscon_value be 0x58000 on H6, to avoid the boot warning. dwmac-sun8i 502.ethernet: Current syscon value is not the default 58000 (expect 5) The same warning is there with A64 compatible (with "expect 0"). [1] See page 238 in H6 manual. regards, o. > However, it is nice to have this 100 Mbit fix, because most STB DTS will need > it. > > Best regards, > Jernej > > > - HDMI support (patches 4-6) > > > > For some people, ethernet doesn't work after reboot (but works on cold > > boot), when the stmmac driver is built into the kernel. It works when > > the driver is built as a module. It's either some timing issue, or power > > supply issue or a combination of both. Module build induces a power > > cycling of the phy. > > > > I encourage people with this issue, to build the driver into the kernel, > > and try to alter the reset timings for the phy in DTS or > > startup-delay-us and report the findings. > > > > > > Please take a look. > > > > thank you and regards, > > Ondrej Jirman > > > > > > Changes in v7: > > - dropped stored reference to connector_pdev as suggested by Jernej > > - added forgotten dt-bindings reviewed-by tag > > > > Changes in v6: > > - added dt-bindings reviewed-by tag > > - fix wording in stmmac commit (as suggested by Sergei) > > > > Changes in v5: > > - dropped already applied patches (pinctrl patches, mmc1 pinconf patch) > > - rename GMAC-3V3 -> GMAC-3V to match the schematic (Jagan) > > - changed hdmi-connector's ddc-supply property to ddc-en-gpios > > (Rob Herring) > > > > Changes in v4: > > - fix checkpatch warnings/style issues > > - use enum in struct sunxi_desc_function for io_bias_cfg_variant > > - collected acked-by's > > - fix compile error in drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c:156 > > caused by missing conversion from has_io_bias_cfg struct member > > (I've kept the acked-by, because it's a trivial change, but feel free > > to object.) (reported by Martin A. on github) > > I did not have A80 pinctrl enabled for some reason, so I did not catch > > this sooner. > > - dropped brcm firmware patch (was already applied) > > - dropped the wifi dts patch (will re-send after H6 RTC gets merged, > > along with bluetooth support, in a separate series) > > > > Changes in v3: > > - dropped already applied patches > > - changed pinctrl I/O bias selection constants to enum and renamed > > - added /omit-if-no-ref/ to mmc1_pins > > - made mmc1_pins default pinconf for mmc1 in H6 dtsi > > - move ddc-supply to HDMI connector node, updated patch descriptions, > > changed dt-bindings docs > > > > Changes in v2: > > - added dt-bindings documentation for the board's compatible string > > (suggested by Clement) > > - addressed checkpatch warnings and code formatting issues (on Maxime's > > suggestions) > > - stmmac: dropped useless parenthesis, reworded description of the patch > > (suggested by Sergei) > > - drop useles dev_info() about the selected io bias voltage > > - docummented io voltage bias selection variant macros > > - wifi: marked WiFi DTS patch and realted mmc1_pins as "DO NOT MERGE", > > because wifi depends on H6 RTC support that's not merged yet (suggested > > by Clement) > > - added missing signed-of-bys > > - changed dr_mode to otg, and added a note about VBUS > > - improved wording of HDMI driver's DDC power supply patch > > > >
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On 2019/06/14, Koenig, Christian wrote: > Am 14.06.19 um 17:53 schrieb Emil Velikov: > > On 2019/06/14, Koenig, Christian wrote: > >> Am 14.06.19 um 14:09 schrieb Emil Velikov: > >>> On 2019/05/27, Emil Velikov wrote: > >>> [SNIP] > >>> Hi Christian, > >>> > >>> > >>> In the following, I would like to summarise and emphasize the need for > >>> DRM_AUTH removal. I would kindly ask you to spend a couple of minutes > >>> extra reading it. > >>> > >>> > >>> Today DRM drivers* do not make any distinction between primary and > >>> render node clients. > >> That is actually not 100% correct. We have a special case where a DRM > >> master is allowed to change the priority of render node clients. > >> > > Can you provide a link? I cannot find that code. > > See amdgpu_sched_ioctl(). > > >>> Thus for a render capable driver, any premise of > >>> separation, security or otherwise imposed via DRM_AUTH is a fallacy. > >> Yeah, that's what I agree on. I just don't think that removing DRM_AUTH > >> now is the right direction to take. > >> > > Could have been clearer - I'm talking about DRM_AUTH | DRM_RENDER_ALLOW > > ioctls. > > > > That aside, can you propose an alternative solution that addresses this > > and the second point just below? > > Give me a few days to work on this, it's already Friday 6pm here. > Hi Christian, Any progress? As mentioned earlier, I'm OK with writing the patches although I would love to hear your plan. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: correct order of crtc disable
On Thu, Jun 20, 2019 at 3:30 PM Robert Beckett
wrote:
> On Thu, 2019-06-20 at 14:32 +0200, Daniel Vetter wrote:
> > On Thu, Jun 20, 2019 at 12:12:13PM +0100, Robert Beckett wrote:
> > > On Thu, 2019-06-20 at 10:50 +0200, Daniel Vetter wrote:
> > > > On Wed, Jun 19, 2019 at 11:40 AM Philipp Zabel <
> > > > p.za...@pengutronix.de> wrote:
> > > > >
> > > > > Hi Robert,
> > > > >
> > > > > thank you for the patch.
> > > > >
> > > > > On Tue, 2019-06-18 at 16:50 +0100, Robert Beckett wrote:
> > > > > > Notify drm core before sending pending events during crtc
> > > > > > disable.
> > > > > > This fixes the first event after disable having an old stale
> > > > > > timestamp
> > > > > > by having drm_crtc_vblank_off update the timestamp to now.
> > > > > >
> > > > > > This was seen while debugging weston log message:
> > > > > > Warning: computed repaint delay is insane: -8212 msec
> > > > > >
> > > > >
> > > > > Would you say this
> > > > > Fixes: a474478642d5 ("drm/imx: fix crtc vblank state
> > > > > regression")
> > > > > ?
> > > > >
> > > > > > Signed-off-by: Robert Beckett
> > > > > > ---
> > > > > > drivers/gpu/drm/imx/ipuv3-crtc.c | 6 +++---
> > > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > > > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > > > index 9cc1d678674f..c436a28d50e4 100644
> > > > > > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > > > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > > > @@ -91,14 +91,14 @@ static void
> > > > > > ipu_crtc_atomic_disable(struct
> > > > > > drm_crtc *crtc,
> > > > > > ipu_dc_disable(ipu);
> > > > > > ipu_prg_disable(ipu);
> > > > > >
> > > > > > + drm_crtc_vblank_off(crtc);
> > > > > > +
> > > > >
> > > > > This is explained in the commit message and aligns with the
> > > > > drm_crtc_state @event documentation.
> > > >
> > > > This part here looks fishy. The drm_vblank.c code is supposed to
> > > > do
> > > > the right thing, no matter where or when you ask it to generate
> > > > an
> > > > event. It definitely shouldn't generate a timestamp that's a few
> > > > seconds too early. Bunch of options:
> > > > - there's a bug in drm_vblank.c and it's mixing up something and
> > > > generating a totally bogus value.
> > > > - there's a lie in your imx vblank code, which trips the
> > > > drm_vblank.c
> > > > counter interpolation and results in a totally bogus value.
> > > >
> > > > drm_vblank.c assumes that if you do claim to have a hw counter
> > > > and
> > > > generate timestamps, that those are perfectly accurate. It only
> > > > falls
> > > > back to guestimating using the system timer if that's not
> > > > present.
> > > >
> > > > Either way, this very much smells like papering over a bug if
> > > > this
> > > > change indeed fixes your wrong vblank timestamps.
> > > >
> > >
> > > A quick explaination of where the dodgy timestamp came from:
> > > 1. driver starts up
> > > 2. fbcon comes along and restores fbdev, enabling vblank
> > > 3. vblank_disable_fn fires via timer disabling vblank, keeping
> > > vblank
> > > seq number and time set at current value
> > > (some time later)
> > > 4. weston starts and does a modeset
> > > 5. atomic commit disables crtc while it does the modeset
> > > 6. ipu_crtc_atomic_disable sends vblank with old seq number and
> > > time
> > >
> > > It turns out the actual fix for the old vblank is the next change,
> > > which stops it being sent at all during the crtc disable as it is
> > > is
> > > still active, it would then go through drm_crtc_vblank_off,
> > > reseting
> > > the timestamp, and get delivered during the vblank enable as part
> > > of
> > > the atomic commit.
> >
> > This shouldn't fix your vblank timestamp troubles either. It might
> > mean
> > that the timestamp is slightly too early (because you take it while
> > shutting down the crtc, not while re-enabling), but not by seconds.
> >
> > Quick experiment: Disable vblank disabling with drm.vblankoffdelay =
> > 0. If
> > that also fixes the timestamps, then I'm pretty sure you have a
> > driver bug
> > somewhere and lie to the vblank core code about something.
> > -Daniel
> >
>
> Experiment done. The timestamp is fine, it is the timestamp of the
> previous vblank update. But, this would fix it because the vblank
> interrupt was never disabled.
>
> The original issue was that the event got sent after vblank was
> disabled and before it got re-enabled during the modeset, so nothing
> had happened to update the timestamp and seq number.
>
> What are you expecting to update the timestamp and seq number while the
> interrupt is disabled after vblank_disable_fn?
Hm maybe this indeed needs to be shuffled around a bit, since
currently it's indeed not not allowed to call
drm_crtc_send_vblank_event if:
- your driver has vblank support (i.e. dev->num_crtcs > 0)
- the vblank irq is off (i.e. no one called drm_crtc_vblank_get)
- from the vblank code's pov the pipe is still
Re: [linux-sunxi] [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Tue, Jun 18, 2019 at 4:24 PM Chen-Yu Tsai wrote:
>
> On Tue, Jun 18, 2019 at 6:34 PM Jagan Teki wrote:
> >
> > On Tue, Jun 18, 2019 at 1:23 PM Chen-Yu Tsai wrote:
> > >
> > > On Tue, Jun 18, 2019 at 3:45 PM Jagan Teki
> > > wrote:
> > > >
> > > > On Tue, Jun 18, 2019 at 12:49 PM Chen-Yu Tsai wrote:
> > > > >
> > > > > On Mon, Jun 17, 2019 at 6:30 PM Jagan Teki
> > > > > wrote:
> > > > > >
> > > > > > On Sun, Jun 16, 2019 at 11:01 AM Chen-Yu Tsai wrote:
> > > > > > >
> > > > > > > On Sat, Jun 15, 2019 at 12:44 AM Jagan Teki
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > TCON TOP have clock gates for TV0, TV1, dsi and right
> > > > > > > > now these are register during bind call.
> > > > > > > >
> > > > > > > > Of which, dsi clock gate would required during DPHY probe
> > > > > > > > but same can miss to get since tcon top is not bound at
> > > > > > > > that time.
> > > > > > > >
> > > > > > > > To solve, this circular dependency move the clock gate
> > > > > > > > registration from bind to probe so-that DPHY can get the
> > > > > > > > dsi gate clock on time.
> > > > > > > >
> > > > > > > > Signed-off-by: Jagan Teki
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 94
> > > > > > > > ++
> > > > > > > > 1 file changed, 49 insertions(+), 45 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > > index 465e9b0cdfee..a8978b3fe851 100644
> > > > > > > > --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > > @@ -124,7 +124,53 @@ static struct clk_hw
> > > > > > > > *sun8i_tcon_top_register_gate(struct device *dev,
> > > > > > > > static int sun8i_tcon_top_bind(struct device *dev, struct
> > > > > > > > device *master,
> > > > > > > >void *data)
> > > > > > > > {
> > > > > > > > - struct platform_device *pdev = to_platform_device(dev);
> > > > > > > > + struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
> > > > > > > > + int ret;
> > > > > > > > +
> > > > > > > > + ret = reset_control_deassert(tcon_top->rst);
> > > > > > > > + if (ret) {
> > > > > > > > + dev_err(dev, "Could not deassert ctrl reset
> > > > > > > > control\n");
> > > > > > > > + return ret;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + ret = clk_prepare_enable(tcon_top->bus);
> > > > > > > > + if (ret) {
> > > > > > > > + dev_err(dev, "Could not enable bus clock\n");
> > > > > > > > + goto err_assert_reset;
> > > > > > > > + }
> > > > > > >
> > > > > > > You have to de-assert the reset control and enable the clock
> > > > > > > before the
> > > > > > > clocks it provides are registered. Otherwise a consumer may come
> > > > > > > in and
> > > > > > > ask for the provided clock to be enabled, but since the TCON
> > > > > > > TOP's own
> > > > > > > reset and clock are still disabled, you can't actually access the
> > > > > > > registers
> > > > > > > that controls the provided clock.
> > > > > >
> > > > > > These rst and bus are common reset and bus clocks not tcon top
> > > > > > clocks
> > > > > > that are trying to register here. ie reason I have not moved it in
> > > > > > top.
> > > > >
> > > > > And you're sure that toggling bits in the TCON TOP block doesn't
> > > > > require
> > > > > the reset to be de-asserted and the bus clock enabled?
> > > > >
> > > > > Somehow I doubt that.
> > > > >
> > > > > Once the driver register the clocks it provides, they absolutely must
> > > > > work.
> > > > > They can't only work after the bind phase when the reset gets
> > > > > de-asserted
> > > > > and the bus clock enabled. Or you should provide proper error
> > > > > reporting
> > > > > in the clock ops. I doubt you want to go that way either.
> > > >
> > > > Why would they won't work after bind phase? unlike tcon top gates,
> > > > these reset, and bus are common like what we have in other DE block
> > > > so enable them in bind won't be an issue as per as I understand. let
> > > > me know if you want me to check in other directions.
> > >
> > > You misunderstood. When you moved the clock registering parts to the probe
> > > phase, but didn't move the clock enable and reset de-assert parts to go
> > > with,
> > > the clock ops will not work as expected between probe and bind time.
> >
> > If I understand correctly, I have moved tcon clock gates, not the bus
> > clock or the reset. Both have independent enablement phase, the bus
> > clock is enable in tcon top bind and the clock gate ("dsi") enable in
> > init call of phy_ops. is both bus clock and clock gates are same and
> > related that is what you are saying?
>
> I am saying that you may need the tcon top bus gates and resets properly
> configured to be able to read/write
Re: [PATCH] drm: Dump mode picture aspect ratio
On Thu, Jun 20, 2019 at 11:59:37AM -0400, Ilia Mirkin wrote:
> On Thu, Jun 20, 2019 at 11:46 AM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Currently the logs show nothing about the mode's aspect ratio.
> > Include that information in the normal mode dump.
> >
> > Cc: Ilia Mirkin
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/video/hdmi.c| 3 ++-
> > include/drm/drm_modes.h | 4 ++--
> > include/linux/hdmi.h| 3 +++
> > 3 files changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > index b939bc28d886..bc593fe1c268 100644
> > --- a/drivers/video/hdmi.c
> > +++ b/drivers/video/hdmi.c
> > @@ -1057,7 +1057,7 @@ static const char *hdmi_colorimetry_get_name(enum
> > hdmi_colorimetry colorimetry)
> > return "Invalid";
> > }
> >
> > -static const char *
> > +const char *
> > hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect)
> > {
> > switch (picture_aspect) {
> > @@ -1076,6 +1076,7 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect
> > picture_aspect)
> > }
> > return "Invalid";
> > }
> > +EXPORT_SYMBOL(hdmi_picture_aspect_get_name);
>
> So this will return "No Data" most of the time (since the DRM_CAP
> won't be enabled)? This will look awkward, esp since the person seeing
> this print will have no idea what "No Data" is referring to.
I suppose we could do
picture_aspet_ratio ? hdmi_picture_aspect_get_name(picture_aspet_ratio) : ""
>
> >
> > static const char *
> > hdmi_active_aspect_get_name(enum hdmi_active_aspect active_aspect)
> > diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> > index 083f16747369..2b1809c74fbe 100644
> > --- a/include/drm/drm_modes.h
> > +++ b/include/drm/drm_modes.h
> > @@ -431,7 +431,7 @@ struct drm_display_mode {
> > /**
> > * DRM_MODE_FMT - printf string for drm_display_mode
> > */
> > -#define DRM_MODE_FMT"\"%s\": %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
> > +#define DRM_MODE_FMT"\"%s\": %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x
> > %s"
> >
> > /**
> > * DRM_MODE_ARG - printf arguments for drm_display_mode
> > @@ -441,7 +441,7 @@ struct drm_display_mode {
> > (m)->name, (m)->vrefresh, (m)->clock, \
> > (m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
> > (m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
> > - (m)->type, (m)->flags
> > + (m)->type, (m)->flags,
> > hdmi_picture_aspect_get_name((m)->picture_aspect_ratio)
>
> Flags are printed as a literal integer value. Given that AR stuff is
> fairly esoteric, I might just print an integer here too.
I hate those thing. I can't even remember which is one the type
(absolutely useless) and which on is the flags. And I always end up
going through the headers to figure out which bit is what sync polarity.
So I'd rather like to decode those too, just been too lazy to do it.
> (Why was
> picture_aspect_ratio not stuffed into ->flags in the first place?)
It's also in there. I think the reason for having this odd duplication
was that we didn't have the flags initially, and just had the prop.
I've not looked how hard it would be to get rid of that.
>
> >
> > #define obj_to_mode(x) container_of(x, struct drm_display_mode, base)
> >
> > diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> > index 9918a6c910c5..de7cbe385dba 100644
> > --- a/include/linux/hdmi.h
> > +++ b/include/linux/hdmi.h
> > @@ -434,4 +434,7 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
> > void hdmi_infoframe_log(const char *level, struct device *dev,
> > const union hdmi_infoframe *frame);
> >
> > +const char *
> > +hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect);
> > +
> > #endif /* _DRM_HDMI_H */
> > --
> > 2.21.0
> >
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/rockchip: Add optional support for CRTC gamma LUT
On Wed, 2019-06-19 at 00:18 +0200, Heiko Stübner wrote:
> Am Mittwoch, 19. Juni 2019, 00:09:57 CEST schrieb Ezequiel Garcia:
> > On Tue, 2019-06-18 at 17:47 -0400, Ilia Mirkin wrote:
> > > On Tue, Jun 18, 2019 at 5:43 PM Ezequiel Garcia
> > > wrote:
> > > > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > > > This is currently enabled via a separate address resource,
> > > > which needs to be specified in the devicetree.
> > > >
> > > > The address resource is required because on some SoCs, such as
> > > > RK3288, the LUT address is after the MMU address, and the latter
> > > > is supported by a different driver. This prevents the DRM driver
> > > > from requesting an entire register space.
> > > >
> > > > The current implementation works for RGB 10-bit tables, as that
> > > > is what seems to work on RK3288.
> > > >
> > > > Signed-off-by: Ezequiel Garcia
> > > > ---
> > > > Changes from RFC:
> > > > * Request (an optional) address resource for the LUT.
> > > > * Drop support for RK3399, which doesn't seem to work
> > > > out of the box and needs more research.
> > > > * Support pass-thru setting when GAMMA_LUT is NULL.
> > > > * Add a check for the gamma size, as suggested by Ilia.
> > > > * Move gamma setting to atomic_commit_tail, as pointed
> > > > out by Jacopo/Laurent, is the correct way.
> > > > ---
> > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > > index 12ed5265a90b..5b6edbe2673f 100644
> > > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > > +static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
> > > > + struct drm_crtc_state *old_state)
> > > > +{
> > > > + int idle, ret, i;
> > > > +
> > > > + spin_lock(>reg_lock);
> > > > + VOP_REG_SET(vop, common, dsp_lut_en, 0);
> > > > + vop_cfg_done(vop);
> > > > + spin_unlock(>reg_lock);
> > > > +
> > > > + ret = readx_poll_timeout(vop_dsp_lut_is_enable, vop,
> > > > + idle, !idle, 5, 30 * 1000);
> > > > + if (ret)
> > > > + return;
> > > > +
> > > > + spin_lock(>reg_lock);
> > > > +
> > > > + if (crtc->state->gamma_lut) {
> > > > + if (!old_state->gamma_lut ||
> > > > (crtc->state->gamma_lut->base.id !=
> > > > +
> > > > old_state->gamma_lut->base.id))
> > > > + vop_crtc_write_gamma_lut(vop, crtc);
> > > > + } else {
> > > > + for (i = 0; i < crtc->gamma_size; i++) {
> > > > + u32 word;
> > > > +
> > > > + word = (i << 20) | (i << 10) | i;
> > > > + writel(word, vop->lut_regs + i * 4);
> > > > + }
> > >
> > > Note - I'm not in any way familiar with the hardware, so take with a
> > > grain of salt --
> > >
> > > Could you just leave dsp_lut_en turned off in this case?
> > >
> >
> > That was the first thing I tried :-)
> >
> > It seems dsp_lut_en is not to enable the CRTC gamma LUT stage,
> > but to enable writing the gamma LUT to the internal RAM.
>
> I guess that warants a code comment stating this, so we don't end
> up with well-meant cleanup patches in the future :-) .
>
Sure, makes sense.
Any other feedback aside from this?
Thanks,
Ezequiel
Re: [PATCH] drm: Dump mode picture aspect ratio
On Thu, Jun 20, 2019 at 11:46 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Currently the logs show nothing about the mode's aspect ratio.
> Include that information in the normal mode dump.
>
> Cc: Ilia Mirkin
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c| 3 ++-
> include/drm/drm_modes.h | 4 ++--
> include/linux/hdmi.h| 3 +++
> 3 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index b939bc28d886..bc593fe1c268 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -1057,7 +1057,7 @@ static const char *hdmi_colorimetry_get_name(enum
> hdmi_colorimetry colorimetry)
> return "Invalid";
> }
>
> -static const char *
> +const char *
> hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect)
> {
> switch (picture_aspect) {
> @@ -1076,6 +1076,7 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect
> picture_aspect)
> }
> return "Invalid";
> }
> +EXPORT_SYMBOL(hdmi_picture_aspect_get_name);
So this will return "No Data" most of the time (since the DRM_CAP
won't be enabled)? This will look awkward, esp since the person seeing
this print will have no idea what "No Data" is referring to.
>
> static const char *
> hdmi_active_aspect_get_name(enum hdmi_active_aspect active_aspect)
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 083f16747369..2b1809c74fbe 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -431,7 +431,7 @@ struct drm_display_mode {
> /**
> * DRM_MODE_FMT - printf string for drm_display_mode
> */
> -#define DRM_MODE_FMT"\"%s\": %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
> +#define DRM_MODE_FMT"\"%s\": %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x %s"
>
> /**
> * DRM_MODE_ARG - printf arguments for drm_display_mode
> @@ -441,7 +441,7 @@ struct drm_display_mode {
> (m)->name, (m)->vrefresh, (m)->clock, \
> (m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
> (m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
> - (m)->type, (m)->flags
> + (m)->type, (m)->flags,
> hdmi_picture_aspect_get_name((m)->picture_aspect_ratio)
Flags are printed as a literal integer value. Given that AR stuff is
fairly esoteric, I might just print an integer here too. (Why was
picture_aspect_ratio not stuffed into ->flags in the first place?)
>
> #define obj_to_mode(x) container_of(x, struct drm_display_mode, base)
>
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 9918a6c910c5..de7cbe385dba 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -434,4 +434,7 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
> void hdmi_infoframe_log(const char *level, struct device *dev,
> const union hdmi_infoframe *frame);
>
> +const char *
> +hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect);
> +
> #endif /* _DRM_HDMI_H */
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v7 0/6] Add support for Orange Pi 3
Hi! Dne četrtek, 20. junij 2019 ob 15:47:42 CEST je megous via linux-sunxi napisal(a): > From: Ondrej Jirman > > This series implements support for Xunlong Orange Pi 3 board. > > - ethernet support (patches 1-3) Correct me if I'm wrong, but patches 1-2 aren't strictly necessary for OrangePi 3, right? H6 DTSI already has emac node with dual compatible (H6 and A64) and since OrangePi 3 uses gigabit ethernet, quirk introduced by patches 1-2 are not needed. However, it is nice to have this 100 Mbit fix, because most STB DTS will need it. Best regards, Jernej > - HDMI support (patches 4-6) > > For some people, ethernet doesn't work after reboot (but works on cold > boot), when the stmmac driver is built into the kernel. It works when > the driver is built as a module. It's either some timing issue, or power > supply issue or a combination of both. Module build induces a power > cycling of the phy. > > I encourage people with this issue, to build the driver into the kernel, > and try to alter the reset timings for the phy in DTS or > startup-delay-us and report the findings. > > > Please take a look. > > thank you and regards, > Ondrej Jirman > > > Changes in v7: > - dropped stored reference to connector_pdev as suggested by Jernej > - added forgotten dt-bindings reviewed-by tag > > Changes in v6: > - added dt-bindings reviewed-by tag > - fix wording in stmmac commit (as suggested by Sergei) > > Changes in v5: > - dropped already applied patches (pinctrl patches, mmc1 pinconf patch) > - rename GMAC-3V3 -> GMAC-3V to match the schematic (Jagan) > - changed hdmi-connector's ddc-supply property to ddc-en-gpios > (Rob Herring) > > Changes in v4: > - fix checkpatch warnings/style issues > - use enum in struct sunxi_desc_function for io_bias_cfg_variant > - collected acked-by's > - fix compile error in drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c:156 > caused by missing conversion from has_io_bias_cfg struct member > (I've kept the acked-by, because it's a trivial change, but feel free > to object.) (reported by Martin A. on github) > I did not have A80 pinctrl enabled for some reason, so I did not catch > this sooner. > - dropped brcm firmware patch (was already applied) > - dropped the wifi dts patch (will re-send after H6 RTC gets merged, > along with bluetooth support, in a separate series) > > Changes in v3: > - dropped already applied patches > - changed pinctrl I/O bias selection constants to enum and renamed > - added /omit-if-no-ref/ to mmc1_pins > - made mmc1_pins default pinconf for mmc1 in H6 dtsi > - move ddc-supply to HDMI connector node, updated patch descriptions, > changed dt-bindings docs > > Changes in v2: > - added dt-bindings documentation for the board's compatible string > (suggested by Clement) > - addressed checkpatch warnings and code formatting issues (on Maxime's > suggestions) > - stmmac: dropped useless parenthesis, reworded description of the patch > (suggested by Sergei) > - drop useles dev_info() about the selected io bias voltage > - docummented io voltage bias selection variant macros > - wifi: marked WiFi DTS patch and realted mmc1_pins as "DO NOT MERGE", > because wifi depends on H6 RTC support that's not merged yet (suggested > by Clement) > - added missing signed-of-bys > - changed dr_mode to otg, and added a note about VBUS > - improved wording of HDMI driver's DDC power supply patch > > Icenowy Zheng (2): > net: stmmac: sun8i: add support for Allwinner H6 EMAC > net: stmmac: sun8i: force select external PHY when no internal one > > Ondrej Jirman (4): > arm64: dts: allwinner: orange-pi-3: Enable ethernet > dt-bindings: display: hdmi-connector: Support DDC bus enable > drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue > arm64: dts: allwinner: orange-pi-3: Enable HDMI output > > .../display/connector/hdmi-connector.txt | 1 + > .../dts/allwinner/sun50i-h6-orangepi-3.dts| 70 +++ > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 54 -- > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 + > .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 21 ++ > 5 files changed, 144 insertions(+), 4 deletions(-)
Re: [linux-sunxi] [PATCH v7 5/6] drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue
Dne četrtek, 20. junij 2019 ob 15:47:47 CEST je megous via linux-sunxi napisal(a): > From: Ondrej Jirman > > Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO > for the DDC bus to be usable. > > Add support for hdmi-connector node's optional ddc-en-gpios property to > support this use case. > > Signed-off-by: Ondrej Jirman Reviewed-by: Jernej Skrabec Best regards, Jernej
[PATCH] drm: Dump mode picture aspect ratio
From: Ville Syrjälä
Currently the logs show nothing about the mode's aspect ratio.
Include that information in the normal mode dump.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c| 3 ++-
include/drm/drm_modes.h | 4 ++--
include/linux/hdmi.h| 3 +++
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index b939bc28d886..bc593fe1c268 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1057,7 +1057,7 @@ static const char *hdmi_colorimetry_get_name(enum
hdmi_colorimetry colorimetry)
return "Invalid";
}
-static const char *
+const char *
hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect)
{
switch (picture_aspect) {
@@ -1076,6 +1076,7 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect
picture_aspect)
}
return "Invalid";
}
+EXPORT_SYMBOL(hdmi_picture_aspect_get_name);
static const char *
hdmi_active_aspect_get_name(enum hdmi_active_aspect active_aspect)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 083f16747369..2b1809c74fbe 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -431,7 +431,7 @@ struct drm_display_mode {
/**
* DRM_MODE_FMT - printf string for drm_display_mode
*/
-#define DRM_MODE_FMT"\"%s\": %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
+#define DRM_MODE_FMT"\"%s\": %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x %s"
/**
* DRM_MODE_ARG - printf arguments for drm_display_mode
@@ -441,7 +441,7 @@ struct drm_display_mode {
(m)->name, (m)->vrefresh, (m)->clock, \
(m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
(m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
- (m)->type, (m)->flags
+ (m)->type, (m)->flags,
hdmi_picture_aspect_get_name((m)->picture_aspect_ratio)
#define obj_to_mode(x) container_of(x, struct drm_display_mode, base)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 9918a6c910c5..de7cbe385dba 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -434,4 +434,7 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
void hdmi_infoframe_log(const char *level, struct device *dev,
const union hdmi_infoframe *frame);
+const char *
+hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect);
+
#endif /* _DRM_HDMI_H */
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Daniel, Dave,
Final pull request for drm-misc-next!
Biggest changes are the remove-fbcon-notifiers branch and modeline cmdline
parser rework,
and the addition of a new KMS driver for ingenic.
drm-misc-next-2019-06-20:
drm-misc-next for v5.3:
UAPI Changes:
- Give each dma-buf their own inode, add DMA_BUF_SET_NAME ioctl and a
show_fdinfo handler.
Cross-subsystem Changes:
- Pull in the topic/remove-fbcon-notifiers branch:
* remove fbdev notifier usage for fbcon, as prep work to clean up the fbcon
locking
* assorted locking checks in vt/console code
* assorted notifier and cleanups in fbdev and backlight code
Core Changes:
- Make drm_debugfs_create_files() never fail.
- add debug print to update_vblank_count.
- Add DP_DPCD_QUIRK_NO_SINK_COUNT quirk.
- Add todo item for drm_gem_objects.
- Unexport drm_gem_(un)pin/v(un)map.
- Document struct drm_cmdline_mode.
- Rewrite the command handler for mode names, and add support to specify
rotation, reflection and overscan. With a new selftest! :)
- Fixes to drm/client for improving rotation support, and fixing variable scope.
- Small fixes to self refresh helper.
Driver Changes:
- Add rockchip RK3328 support.
- Assorted driver fixes to rockchip, vc4, rcar-du, vkms.
- Expose panfrost performance counters through unstable ioctl's, hidden
behind a module parameter.
- Enumerate CRC sources list in vkms.
- Add a basic kms driver for the Ingenic JZ47xx SoC, which will be expanded
soon with more advanced features.
- Suspend/resume fix for stm.
The following changes since commit 52d2d44eee8091e740d0d275df1311fb8373c9a9:
Merge v5.2-rc5 into drm-next (2019-06-19 12:07:29 +0200)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-06-20
for you to fetch changes up to 836334fd747595331dcdc7709b447ad8134db693:
drm/todo: Update drm_gem_object_funcs todo even more (2019-06-20 17:11:53
+0200)
Boris Brezillon (4):
drm/panfrost: Move gpu_{write, read}() macros to panfrost_regs.h
drm/panfrost: Add a module parameter to expose unstable ioctls
drm/panfrost: Add an helper to check the GPU generation
drm/panfrost: Expose performance counters through unstable ioctls
Dan Carpenter (1):
drm: self_refresh: Fix a reversed condition in
drm_self_refresh_helper_cleanup()
Daniel Vetter (38):
dummycon: Sprinkle locking checks
fbdev: locking check for fb_set_suspend
vt: might_sleep() annotation for do_blank_screen
vt: More locking checks
fbdev/sa1100fb: Remove dead code
fbdev/cyber2000: Remove struct display
fbdev/aty128fb: Remove dead code
fbcon: s/struct display/struct fbcon_display/
fbcon: Remove fbcon_has_exited
fbcon: call fbcon_fb_(un)registered directly
fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify
fbdev/omap: sysfs files can't disappear before the device is gone
fbdev: sysfs files can't disappear before the device is gone
staging/olpc: lock_fb_info can't fail
fbdev/atyfb: lock_fb_info can't fail
fbdev: lock_fb_info cannot fail
fbcon: call fbcon_fb_bind directly
fbdev: make unregister/unlink functions not fail
fbdev: unify unlink_framebuffer paths
fbdev/sh_mob: Remove fb notifier callback
fbdev: directly call fbcon_suspended/resumed
fbcon: Call fbcon_mode_deleted/new_modelist directly
fbdev: Call fbcon_get_requirement directly
Revert "backlight/fbcon: Add FB_EVENT_CONBLANK"
fbmem: pull fbcon_fb_blanked out of fb_blank
fbdev: remove FBINFO_MISC_USEREVENT around fb_blank
fb: Flatten control flow in fb_set_var
fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls
vgaswitcheroo: call fbcon_remap_all directly
fbcon: Call con2fb_map functions directly
fbcon: Document what I learned about fbcon locking
staging/olpc_dcon: Add drm conversion to TODO
backlight: simplify lcd notifier
drm/todo: Improve drm_gem_object funcs todo
drm/gem: Unexport drm_gem_(un)pin/v(un)map
drm/vkms: Move format arrays to vkms_plane.c
fbcon: Export fbcon_update_vcs
drm/todo: Update drm_gem_object_funcs todo even more
Douglas Anderson (2):
drm/rockchip: Properly adjust to a true clock in adjusted_mode
drm/rockchip: Base adjustments of the mode based on prev adjustments
Greg Hackmann (3):
dma-buf: give each buffer a full-fledged inode
dma-buf: add DMA_BUF_SET_NAME ioctls
dma-buf: add show_fdinfo handler
Greg Kroah-Hartman (2):
drm: debugfs: make drm_debugfs_create_files() never fail
drm/vc4: no need to check return value of debugfs_create functions
Justin Swartz (1):
drm/rockchip: dw_hdmi: add basic rk3228 support
Maarten Lankhorst (3):
Merge remote-tracking branch 'drm/drm-next' into drm-misc-next
Merge remote-tracking branch 'drm/drm-next'
Re: drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
On Tue, Jun 18, 2019 at 04:37:16PM +0100, Jon Hunter wrote: > > On 18/06/2019 16:19, Greg Kroah-Hartman wrote: > > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote: > >> Greg is busy already, but maybe he won't do everything ... > >> > >> Cc: Greg Kroah-Hartman > >> Signed-off-by: Daniel Vetter > >> --- > >> Documentation/gpu/todo.rst | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > >> index 9717540ee28f..026e55c517e1 100644 > >> --- a/Documentation/gpu/todo.rst > >> +++ b/Documentation/gpu/todo.rst > >> @@ -375,6 +375,9 @@ There's a bunch of issues with it: > >>this (together with the drm_minor->drm_device move) would allow us to > >> remove > >>debugfs_init. > >> > >> +- Drop the return code and error checking from all debugfs functions. > >> Greg KH is > >> + working on this already. > > > > > > Part of this work was to try to delete drm_debugfs_remove_files(). > > > > There are only 4 files that currently still call this function: > > drivers/gpu/drm/tegra/dc.c > > drivers/gpu/drm/tegra/dsi.c > > drivers/gpu/drm/tegra/hdmi.c > > drivers/gpu/drm/tegra/sor.c > > > > For dc.c, the driver wants to add debugfs files to the struct drm_crtc > > debugfs directory. Which is fine, but it has to do some special memory > > allocation to get the debugfs callback to point not to the struct > > drm_minor pointer, but rather the drm_crtc structure. > > > > So, to remove this call, I need to remove this special memory allocation > > and to do that, I need to somehow be able to cast from drm_minor back to > > the drm_crtc structure being used in this driver. And I can't figure > > how they are related at all. > > > > Any pointers here (pun intended) would be appreciated. > > > > For the other 3 files, the situation is much the same, but I need to get > > from a 'struct drm_minor' pointer to a 'struct drm_connector' pointer. > > > > I could just "open code" a bunch of calls to debugfs_create_file() for > > these drivers, which would solve this issue, but in a more "non-drm" > > way. Is it worth to just do that instead of overthinking the whole > > thing and trying to squish it into the drm "model" of drm debugfs calls? > > > > Either way, who can test these changes? I can't even build the tegra > > driver without digging up an arm64 cross-compiler, and can't test it as > > I have no hardware at all. > > We can definitely compile and boot test these no problem. In fact > anything that lands in -next we will boot test. However, I can do some > quick sanity if you have something to test. > > Thierry may have more specific Tegra DRM tests. We don't have any automated tests for this yet, unfortunately. Let me work on something. In the meantime I can manually test any of the patches that Greg sends out. These should be fairly trivial to test. It's difficult to check for success/failure on something like the register dump or the CRC, but I think for now we don't really need much more than just validating that things don't crash when we read one of these debugfs files. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema
On Thu, Jun 20, 2019 at 12:55 AM Sam Ravnborg wrote: > > Hi Rob. > > Thanks for starting the conversion of panel bindings to yaml. > > On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote: > > Convert the common panel bindings to DT schema consolidating scattered > > definitions to a single schema file. > > > > The 'simple-panel' binding just a collection of properties and not a > > complete binding itself. All of the 'simple-panel' properties are > > covered by the panel-common.txt binding with the exception of the > > 'no-hpd' property, so add that to the schema. > > > > As there are lots of references to simple-panel.txt, just keep the file > > with a reference to panel-common.yaml for now until all the bindings are > > converted. > Good idea. > > > > > Cc: Thierry Reding > > Cc: Sam Ravnborg > > Cc: Maxime Ripard > > Cc: Laurent Pinchart > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Rob Herring > > --- > > Note there's still some references to panel-common.txt that I need to > > update or just go ahead and convert to schema. > Better let it point to the .yaml variant, so this patchset does not > depend on too much other bindings to be converted. There's only 8 files referencing panel-common.txt which was why I was debating just converting all of them. > Then we can start the conversion of the remaining panel bindings. > Any tooling that helps the conversions? I have a doc2yaml script that helps with some of the boilerplate. It's in my yaml-bindings-v2 branch[1]. > When this hits upstream I assume all future panel bindings shall be yaml > based - so we have a few pending contributions that need to do something. That would be ideal, but not strictly required. For pending things, no reason to make folks redo things. Requiring schema really depends on whomever is applying things to run at least 'make dt_binding_check' before accepting. > > For the actual conversion below: > Acked-by: Sam Ravnborg Thanks. Rob [1] https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/log/?h=yaml-bindings-v2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
On Tue, Jun 18, 2019 at 07:32:20PM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
> wrote:
> > On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > > > Greg is busy already, but maybe he won't do everything ...
> > > >
> > > > Cc: Greg Kroah-Hartman
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > > Documentation/gpu/todo.rst | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > > > index 9717540ee28f..026e55c517e1 100644
> > > > --- a/Documentation/gpu/todo.rst
> > > > +++ b/Documentation/gpu/todo.rst
> > > > @@ -375,6 +375,9 @@ There's a bunch of issues with it:
> > > >this (together with the drm_minor->drm_device move) would allow us
> > > > to remove
> > > >debugfs_init.
> > > >
> > > > +- Drop the return code and error checking from all debugfs functions.
> > > > Greg KH is
> > > > + working on this already.
> > >
> > >
> > > Part of this work was to try to delete drm_debugfs_remove_files().
> > >
> > > There are only 4 files that currently still call this function:
> > > drivers/gpu/drm/tegra/dc.c
> > > drivers/gpu/drm/tegra/dsi.c
> > > drivers/gpu/drm/tegra/hdmi.c
> > > drivers/gpu/drm/tegra/sor.c
> > >
> > > For dc.c, the driver wants to add debugfs files to the struct drm_crtc
> > > debugfs directory. Which is fine, but it has to do some special memory
> > > allocation to get the debugfs callback to point not to the struct
> > > drm_minor pointer, but rather the drm_crtc structure.
>
> There's already a todo to switch the drm_minor debugfs stuff over to
> drm_device. drm_minor is essentially different uapi flavours (/dev/
> minor nodes, hence the name) sitting on top of the same drm_device.
> Last time I checked all the debugfs files want the drm_device, not the
> minor. I think we even discussed to only register the debugfs files
> for the first minor, and create the other ones as symlinks to the
> first one. But haven't yet gotten around to typing that.
>
> drm_crtc/connector are parts of drm_device with modesetting support,
> so the drm_minor is even worse choice really.
For the connector drivers we already sit on top of the per-connector
debugfs directories. I think the only reason why we don't do that for
the display controller is because drm_crtc didn't have built-in debugfs
support like the connectors have. It looks like that's no longer true,
though it's been there for a while. I think it'd be good to just move
those over as well.
As for passing struct drm_minor, I think that's mostly unnecessary. As
far as I can tell, we only use drm_minor to get at drm_device, which in
turn we only use to check some features flags, and drm_minor itself is
only used to track the list of files that are being added so that they
can later be removed again. Given that we can just tear down everything
debugfs recursively, I don't think we need any of that.
>
> Not exactly sure why we went with this, but probably dates back to the
> *bsd compat layer and a lot of these files hanging out in procfs too
> (we've fixed those mistakes a few years ago, yay!).
>
> > > So, to remove this call, I need to remove this special memory allocation
> > > and to do that, I need to somehow be able to cast from drm_minor back to
> > > the drm_crtc structure being used in this driver. And I can't figure
> > > how they are related at all.
> > >
> > > Any pointers here (pun intended) would be appreciated.
> > >
> > > For the other 3 files, the situation is much the same, but I need to get
> > > from a 'struct drm_minor' pointer to a 'struct drm_connector' pointer.
>
> Ditch the drm_minor, there's no no way to get from that to something
> like drm_connector/crtc, since it's a n:m relationship.
Yeah. That too.
> > > I could just "open code" a bunch of calls to debugfs_create_file() for
> > > these drivers, which would solve this issue, but in a more "non-drm"
> > > way. Is it worth to just do that instead of overthinking the whole
> > > thing and trying to squish it into the drm "model" of drm debugfs calls?
> >
> > An example of "open coding" this is the patch below for the sor.c
> > driver.
>
> I think open-coding is the way to go here. One of the todos is to
> extend debugfs support for crtc/connectors, but looking at the
> open-coded version we really don't need a drm-flavoured midlayer here.
Exactly my thoughts. It'd be nice to have some sort of macro to help
bring the boilerplate down a bit.
Thierry
> > Totally untested, not even built, but you should get the idea here.
> >
> > thanks,
> >
> > greg k-h
> >
> > ---
> >
> > diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> > index 5be5a0817dfe..3216221c77c4 100644
> > --- a/drivers/gpu/drm/tegra/sor.c
> > +++ b/drivers/gpu/drm/tegra/sor.c
> > @@ -414,7 +414,8 @@ struct tegra_sor {
>
[Bug 110949] Continuious warnings from agd5f 5.3-wip branch
https://bugs.freedesktop.org/show_bug.cgi?id=110949 --- Comment #4 from Mike Lothian --- If there's anything you'd like me to test for you, please do shout -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 29/59] drm/sti: Drop drm_gem_prime_export/import
Le ven. 14 juin 2019 à 22:36, Daniel Vetter a écrit :
>
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
Thanks,
Reviewed-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/sti/sti_drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index d9f63c9f287b..faea4dcb21b1 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -152,8 +152,6 @@ static struct drm_driver sti_driver = {
>
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export = drm_gem_prime_export,
> - .gem_prime_import = drm_gem_prime_import,
> .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> .gem_prime_vmap = drm_gem_cma_prime_vmap,
> --
> 2.20.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/stm: drv: fix suspend/resume
Le mar. 18 juin 2019 à 11:57, Philippe CORNU a écrit :
>
> Hi Yannick,
>
> Thank you for your patch.
>
> Acked-by: Philippe Cornu
I have corrected Fixes sha1 (should be 12 digits)
Applied on drm-misc-next.
Benjamin
>
> Philippe :-)
>
> On 6/17/19 9:18 AM, Yannick Fertré wrote:
> > Without this fix, the system can not go in "suspend" mode
> > due to an error in drv_suspend function.
> >
> > Fixes: 35ab6cf ("drm/stm: support runtime power management")
> >
> > Signed-off-by: Yannick Fertré
> > ---
> > drivers/gpu/drm/stm/drv.c | 15 ---
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> > index 5659572..9dee4e4 100644
> > --- a/drivers/gpu/drm/stm/drv.c
> > +++ b/drivers/gpu/drm/stm/drv.c
> > @@ -136,8 +136,7 @@ static __maybe_unused int drv_suspend(struct device
> > *dev)
> > struct ltdc_device *ldev = ddev->dev_private;
> > struct drm_atomic_state *state;
> >
> > - if (WARN_ON(!ldev->suspend_state))
> > - return -ENOENT;
> > + WARN_ON(ldev->suspend_state);
> >
> > state = drm_atomic_helper_suspend(ddev);
> > if (IS_ERR(state))
> > @@ -155,15 +154,17 @@ static __maybe_unused int drv_resume(struct device
> > *dev)
> > struct ltdc_device *ldev = ddev->dev_private;
> > int ret;
> >
> > + if (WARN_ON(!ldev->suspend_state))
> > + return -ENOENT;
> > +
> > pm_runtime_force_resume(dev);
> > ret = drm_atomic_helper_resume(ddev, ldev->suspend_state);
> > - if (ret) {
> > + if (ret)
> > pm_runtime_force_suspend(dev);
> > - ldev->suspend_state = NULL;
> > - return ret;
> > - }
> >
> > - return 0;
> > + ldev->suspend_state = NULL;
> > +
> > + return ret;
> > }
> >
> > static __maybe_unused int drv_runtime_suspend(struct device *dev)
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote: > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote: > > Greg is busy already, but maybe he won't do everything ... > > > > Cc: Greg Kroah-Hartman > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/todo.rst | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > index 9717540ee28f..026e55c517e1 100644 > > --- a/Documentation/gpu/todo.rst > > +++ b/Documentation/gpu/todo.rst > > @@ -375,6 +375,9 @@ There's a bunch of issues with it: > >this (together with the drm_minor->drm_device move) would allow us to > > remove > >debugfs_init. > > > > +- Drop the return code and error checking from all debugfs functions. Greg > > KH is > > + working on this already. > > > Part of this work was to try to delete drm_debugfs_remove_files(). > > There are only 4 files that currently still call this function: > drivers/gpu/drm/tegra/dc.c > drivers/gpu/drm/tegra/dsi.c > drivers/gpu/drm/tegra/hdmi.c > drivers/gpu/drm/tegra/sor.c > > For dc.c, the driver wants to add debugfs files to the struct drm_crtc > debugfs directory. Which is fine, but it has to do some special memory > allocation to get the debugfs callback to point not to the struct > drm_minor pointer, but rather the drm_crtc structure. Actually the reason why the memory allocation is done is because there can be multiple instances of the display controller. In fact, there's always at least two (and up to four in later Tegra generations). The DRM debugfs infrastructure, however, doesn't automatically duplicate the data for each drm_debugfs_create_files() call and at the same time it does not allow you to specify driver-private data other than by embedding it in the drm_info_list structure. So rather than manually create the drm_info_list for each display controller instance, the code creates a template that is then duplicated and for which the driver- private is then set. That way multiple invocations end up with different data. This is because of the extra indirection that the DRM debugfs infrastructure introduces. It's in fact much easier to do this with just plain debugfs function calls. The only downside is the boilerplate required to make that happen. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema
On Thu, Jun 20, 2019 at 3:01 AM Thierry Reding wrote: > > On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote: > > Convert the common panel bindings to DT schema consolidating scattered > > definitions to a single schema file. > > > > The 'simple-panel' binding just a collection of properties and not a > > complete binding itself. All of the 'simple-panel' properties are > > covered by the panel-common.txt binding with the exception of the > > 'no-hpd' property, so add that to the schema. > > > > As there are lots of references to simple-panel.txt, just keep the file > > with a reference to panel-common.yaml for now until all the bindings are > > converted. > > > > Cc: Thierry Reding > > Cc: Sam Ravnborg > > Cc: Maxime Ripard > > Cc: Laurent Pinchart > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Rob Herring > > --- > > Note there's still some references to panel-common.txt that I need to > > update or just go ahead and convert to schema. > > > > .../bindings/display/panel/panel-common.txt | 101 - > > .../bindings/display/panel/panel-common.yaml | 143 ++ > > .../bindings/display/panel/panel.txt | 4 - > > .../bindings/display/panel/simple-panel.txt | 29 +--- > > 4 files changed, 144 insertions(+), 133 deletions(-) > > delete mode 100644 > > Documentation/devicetree/bindings/display/panel/panel-common.txt > > create mode 100644 > > Documentation/devicetree/bindings/display/panel/panel-common.yaml > > I know it was this way before, but perhaps remove the redundant panel- > prefix while at it? Sure. > > diff --git > > a/Documentation/devicetree/bindings/display/panel/panel-common.yaml > > b/Documentation/devicetree/bindings/display/panel/panel-common.yaml > > new file mode 100644 > > index ..6fe87254edad > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml > > @@ -0,0 +1,143 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/panel/panel-common.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Common Properties for Display Panels > > + > > +maintainers: > > + - Thierry Reding > > + - Laurent Pinchart > > + > > +description: | > > + This document defines device tree properties common to several classes of > > + display panels. It doesn't constitue a device tree binding specification > > by > > + itself but is meant to be referenced by device tree bindings. > > + > > + When referenced from panel device tree bindings the properties defined > > in this > > + document are defined as follows. The panel device tree bindings are > > + responsible for defining whether each property is required or optional. > > + > > + > > Are the two blank lines here on purpose? No. > The original document had two > blank lines here, but that was mostly for readability I would guess. The > YAML format doesn't really need additional formatting for readability, > so perhaps just remove the extra blank line? > > > +properties: > > + # Descriptive Properties > > + width-mm: > > +description: The width-mm and height-mm specify the width and height > > of the > > + physical area where images are displayed. These properties are > > expressed > > + in millimeters and rounded to the closest unit. > > + > > + height-mm: > > +description: The width-mm and height-mm specify the width and height > > of the > > + physical area where images are displayed. These properties are > > expressed > > + in millimeters and rounded to the closest unit. > > I suppose there's no way in YAML to share the description between both > the width-mm and height-mm properties? It's a little unfortunate that we > have to copy, but if there's no better way, guess we'll have to live > with it. I could make it a comment instead, but then we loose being able to parse it. I should probably just reword them to be separate: "Specifies the height of the physical area where images are displayed. The property is expressed in millimeters and rounded to the closest unit." Also, just realized I need to make these 2 dependencies on either other (i.e. not valid to only have one). > > + label: > > +description: | > > + The label property specifies a symbolic name for the panel as a > > + string suitable for use by humans. It typically contains a name > > inscribed > > + on the system (e.g. as an affixed label) or specified in the system's > > + documentation (e.g. in the user's manual). > > + > > + If no such name exists, and unless the property is mandatory > > according to > > + device tree bindings, it shall rather be omitted than constructed of > > + non-descriptive information. For instance an LCD panel in a system > > that > > + contains a single panel shall not be labelled "LCD" if that name is > > not > > + inscribed on the system or used in a
Re: drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
On Tue, Jun 18, 2019 at 11:46:56PM +0200, Daniel Vetter wrote: > On Tue, Jun 18, 2019 at 08:01:13PM +0200, Greg Kroah-Hartman wrote: > > On Tue, Jun 18, 2019 at 07:32:20PM +0200, Daniel Vetter wrote: > > > On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman > > > wrote: > > > > On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote: > > > > > I could just "open code" a bunch of calls to debugfs_create_file() for > > > > > these drivers, which would solve this issue, but in a more "non-drm" > > > > > way. Is it worth to just do that instead of overthinking the whole > > > > > thing and trying to squish it into the drm "model" of drm debugfs > > > > > calls? > > > > > > > > An example of "open coding" this is the patch below for the sor.c > > > > driver. > > > > > > I think open-coding is the way to go here. One of the todos is to > > > extend debugfs support for crtc/connectors, but looking at the > > > open-coded version we really don't need a drm-flavoured midlayer here. > > > > There already is debugfs support in the code for crtc/connectors, these > > files are "hanging" off of those locations already. I'll keep that, but > > indent it one more directory so that there's no namespace collisions. > > The todo was to have some drm wrappers here for the boilerplate, but after > looking at your version that's not a good idea. So not just making sure > crtcs/connectors have a debugfs directory made for them, but more. > > Wrt adding a new directory: debugfs isnt uapi, but there's usually a > massive pile of script relying on them, so it's not nice to shuffle paths > around. Plus the lifetimes match anyway (at least if you don't hotplug > connectors, which tegra doesn't do). So, I think you two already covered everything. From a Tegra perspective there's not really a need to care about the exact structure of debugfs because there are only a handful of scripts that use this and they are not exactly widely distributed. At the same time there's really no need to add another level of directories, since the connector really is the SOR, so an sor directory in the connector's directory is just redundant. Cleaning up and lifetime management aren't issues, really, so there are no good arguments for adding it, in my opinion. Historically, the sor.c driver is interesting because it used to be just plain debugfs calls. Only when I added a second debugfs file I decided to go with the built-in DRM infrastructure for this and then later went and converted the first file to it as well, for consistency. I do remember though that I was very unhappy about the fact that I had to do all this kmemdup()'ing just to make debugfs files per-instance (the DRM infrastructure doesn't allow that by default). In retrospect that was a poor decision and I should've just stuck with debugfs and perhaps just spin a couple of helpers around that instead. So I'm happy to see this effort. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 5/5 v3] drm/msm/mdp5: Use the interconnect API
On Tue, Jun 18, 2019 at 4:10 PM Rob Clark wrote: > > From: Georgi Djakov > > The interconnect API provides an interface for consumer drivers to > express their bandwidth needs in the SoC. This data is aggregated > and the on-chip interconnect hardware is configured to the most > appropriate power/performance profile. > > Use the API to configure the interconnects and request bandwidth > between DDR and the display hardware (MDP port(s) and rotator > downscaler). > > v2: update the path names to be consistent with dpu, handle the NULL > path case, updated commit msg from Georgi. > v3: split out icc setup into it's own function, and rework logic > slightly so no interconnect paths is not fatal. > > Signed-off-by: Georgi Djakov > Signed-off-by: Rob Clark Looks good to me. Reviewed-By: Jeffrey Hugo
Re: [PATCH] drm/self_refresh: Fix possible NULL deref in failure path
On Thu, Jun 20, 2019 at 01:28:55PM +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 02:19:47PM -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > If state allocation fails, we still try to give back the reference on
> > it. Also initialize ret in case the crtc is not enabled and we hit the
> > eject button.
> >
> > Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in
> > drivers")
> > Cc: Daniel Vetter
> > Cc: Jose Souza
> > Cc: Zain Wang
> > Cc: Tomasz Figa
> > Cc: Ville Syrjälä
> > Cc: Sam Ravnborg
> > Cc: Sean Paul
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: dri-devel@lists.freedesktop.org
> > Reported-by: Dan Carpenter
> > Signed-off-by: Sean Paul
>
> Reviewed-by: Daniel Vetter
>
Applied to -misc-next, thanks!
Sean
> > ---
> > drivers/gpu/drm/drm_self_refresh_helper.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c
> > b/drivers/gpu/drm/drm_self_refresh_helper.c
> > index e0d2ad1f070cb..4b9424a8f1f1c 100644
> > --- a/drivers/gpu/drm/drm_self_refresh_helper.c
> > +++ b/drivers/gpu/drm/drm_self_refresh_helper.c
> > @@ -69,14 +69,14 @@ static void drm_self_refresh_helper_entry_work(struct
> > work_struct *work)
> > struct drm_connector *conn;
> > struct drm_connector_state *conn_state;
> > struct drm_crtc_state *crtc_state;
> > - int i, ret;
> > + int i, ret = 0;
> >
> > drm_modeset_acquire_init(, 0);
> >
> > state = drm_atomic_state_alloc(dev);
> > if (!state) {
> > ret = -ENOMEM;
> > - goto out;
> > + goto out_drop_locks;
> > }
> >
> > retry:
> > @@ -116,6 +116,8 @@ static void drm_self_refresh_helper_entry_work(struct
> > work_struct *work)
> > }
> >
> > drm_atomic_state_put(state);
> > +
> > +out_drop_locks:
> > drm_modeset_drop_locks();
> > drm_modeset_acquire_fini();
> > }
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: gpio-backlight: Set power state instead of brightness at probe
Daniel,
On 20/06/2019 16.56, Daniel Thompson wrote:
> On 18/06/2019 13:58, Paul Kocialkowski wrote:
>> Hi,
>>
>> On Fri, 2019-05-17 at 17:05 +0200, Paul Kocialkowski wrote:
>>> On a trivial gpio-backlight setup with a panel using the backlight but
>>> no boot software to enable it beforehand, we fall in a case where the
>>> backlight is disabled (not just blanked) and thus remains disabled when
>>> the panel gets enabled.
>>>
>>> Setting gbl->def_value via the device-tree prop allows enabling the
>>> backlight in this situation, but it will be unblanked straight away,
>>> in compliance with the binding. This does not work well when there
>>> was no
>>> boot software to display something before, since we really need to
>>> unblank
>>> by the time the panel is enabled, not before.
>>>
>>> Resolve the situation by setting the brightness to 1 at probe and
>>> managing the power state accordingly, a bit like it's done in
>>> pwm-backlight.
>>
>> Any feedback on this? I was under the impression that it could be quite
>> controversial, as it implies that the backlight can no longer be
>> enabled without a bound panel (which IMO makes good sense but could be
>> a matter to debate).
>
> My apologies. This patch brought on such severe deja-vu I got rather
> confused. Then when I went digging I've also dropped the ball on the
> same feature previously.
>
> Peter Ujfalusi provided a similar patch to yours but with a slightly
> different implementation:
> https://lore.kernel.org/patchwork/patch/1002359/
>
> On the whole I think it is important to read the GPIO pin since
> otherwise we swap problems when there bootloader does setup the
> backlight for problems where it does not.
>
> The thing I don't get is why both patches try to avoid setting the
> backlight brightness from def_value. Simple displays, especially
> monochrome ones are perfectly readable with the backlight off... zero
> brightness is not a "bad" value.
Because we might have non monochrome displays where the display is not
readable when the backlight is off and for the sake of to be consistent?
Flickering backlight is not really a nice thing during boot.
> Not sure if Peter is still willing to rev his version of this code
> (given how badly we neglected him previously) or whether you want to try
> and combine both ideas.
Nothing special, things sometimes got overlooked.
I should have been nagging you about it ;)
I think the v2 patch from me should apply just fine and it has the gpio
read as well, if not, then I might not be able to resend as I'm out of
office for a while
- Péter
>
>
> Daniel.
>
>
>>
>> Cheers,
>>
>> Paul
>>
>>> Fixes: 8b770e3c9824 ("backlight: Add GPIO-based backlight driver")
>>> Signed-off-by: Paul Kocialkowski
>>> ---
>>> drivers/video/backlight/gpio_backlight.c | 19 ++-
>>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/video/backlight/gpio_backlight.c
>>> b/drivers/video/backlight/gpio_backlight.c
>>> index e470da95d806..c9cb97fa13d0 100644
>>> --- a/drivers/video/backlight/gpio_backlight.c
>>> +++ b/drivers/video/backlight/gpio_backlight.c
>>> @@ -57,6 +57,21 @@ static const struct backlight_ops
>>> gpio_backlight_ops = {
>>> .check_fb = gpio_backlight_check_fb,
>>> };
>>> +static int gpio_backlight_initial_power_state(struct
>>> gpio_backlight *gbl)
>>> +{
>>> + struct device_node *node = gbl->dev->of_node;
>>> +
>>> + /* If we absolutely want the backlight enabled at boot. */
>>> + if (gbl->def_value)
>>> + return FB_BLANK_UNBLANK;
>>> +
>>> + /* If there's no panel to unblank the backlight later. */
>>> + if (!node || !node->phandle)
>>> + return FB_BLANK_UNBLANK;
>>> +
>>> + return FB_BLANK_POWERDOWN;
>>> +}
>>> +
>>> static int gpio_backlight_probe_dt(struct platform_device *pdev,
>>> struct gpio_backlight *gbl)
>>> {
>>> @@ -142,7 +157,9 @@ static int gpio_backlight_probe(struct
>>> platform_device *pdev)
>>> return PTR_ERR(bl);
>>> }
>>> - bl->props.brightness = gbl->def_value;
>>> + bl->props.brightness = 1;
>>> + bl->props.power = gpio_backlight_initial_power_state(gbl);
>>> +
>>> backlight_update_status(bl);
>>> platform_set_drvdata(pdev, bl);
>
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/bridge: dw-hdmi: Add support for HDR metadata
Hi Andrzej, Gentle ping, could you review the dw-hdmi changes here ? Thanks, Neil On 26/05/2019 23:18, Jonas Karlman wrote: > Add support for HDR metadata using the hdr_output_metadata connector property, > configure Dynamic Range and Mastering InfoFrame accordingly. > > A drm_infoframe flag is added to dw_hdmi_plat_data that platform drivers > can use to signal when Dynamic Range and Mastering infoframes is supported. > This flag is needed because Amlogic GXBB and GXL report same DW-HDMI version, > and only GXL support DRM InfoFrame. > > The first patch add functionality to configure DRM InfoFrame based on the > hdr_output_metadata connector property. > > The remaining patches sets the drm_infoframe flag on some SoCs supporting > Dynamic Range and Mastering InfoFrame. > > Note that this was based on top of drm-misc-next and Neil Armstrong's > "drm/meson: Add support for HDMI2.0 YUV420 4k60" series at [1] > > [1] https://patchwork.freedesktop.org/series/58725/#rev2 > > Jonas Karlman (4): > drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support > drm/rockchip: Enable DRM InfoFrame support on RK3328 and RK3399 > drm/meson: Enable DRM InfoFrame support on GXL, GXM and G12A > drm/sun4i: Enable DRM InfoFrame support on H6 > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 109 > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 37 +++ > drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 + > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 + > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 + > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 + > include/drm/bridge/dw_hdmi.h| 1 + > 7 files changed, 157 insertions(+) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: dw-hdmi: Use automatic CTS generation mode when using non-AHB audio
Hi Andrzej,
Gentle ping, do you think this could go in drm-misc-next for 5.3 ?
Thanks,
Neil
On 12/06/2019 10:51, Neil Armstrong wrote:
> When using an I2S source using a different clock source (usually the I2S
> audio HW uses dedicated PLLs, different from the HDMI PHY PLL), fixed
> CTS values will cause some frequent audio drop-out and glitches as
> reported on Amlogic, Allwinner and Rockchip SoCs setups.
>
> Setting the CTS in automatic mode will let the HDMI controller generate
> automatically the CTS value to match the input audio clock.
>
> The DesignWare DW-HDMI User Guide explains:
> For Automatic CTS generation
> Write "0" on the bit field "CTS_manual", Register 0x3205: AUD_CTS3
>
> The DesignWare DW-HDMI Databook explains :
> If "CTS_manual" bit equals 0b this registers contains "audCTS[19:0]"
> generated by the Cycle time counter according to specified timing.
>
> Cc: Jernej Skrabec
> Cc: Maxime Ripard
> Cc: Jonas Karlman
> Cc: Heiko Stuebner
> Cc: Jerome Brunet
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 +++
> 1 file changed, 29 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index c68b6ed1bb35..6458c3a31d23 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -437,8 +437,14 @@ static void hdmi_set_cts_n(struct dw_hdmi *hdmi,
> unsigned int cts,
> /* nshift factor = 0 */
> hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
>
> - hdmi_writeb(hdmi, ((cts >> 16) & HDMI_AUD_CTS3_AUDCTS19_16_MASK) |
> - HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
> + /* Use automatic CTS generation mode when CTS is not set */
> + if (cts)
> + hdmi_writeb(hdmi, ((cts >> 16) &
> +HDMI_AUD_CTS3_AUDCTS19_16_MASK) |
> + HDMI_AUD_CTS3_CTS_MANUAL,
> + HDMI_AUD_CTS3);
> + else
> + hdmi_writeb(hdmi, 0, HDMI_AUD_CTS3);
> hdmi_writeb(hdmi, (cts >> 8) & 0xff, HDMI_AUD_CTS2);
> hdmi_writeb(hdmi, cts & 0xff, HDMI_AUD_CTS1);
>
> @@ -508,24 +514,32 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi
> *hdmi,
> {
> unsigned long ftdms = pixel_clk;
> unsigned int n, cts;
> + u8 config3;
> u64 tmp;
>
> n = hdmi_compute_n(sample_rate, pixel_clk);
>
> - /*
> - * Compute the CTS value from the N value. Note that CTS and N
> - * can be up to 20 bits in total, so we need 64-bit math. Also
> - * note that our TDMS clock is not fully accurate; it is accurate
> - * to kHz. This can introduce an unnecessary remainder in the
> - * calculation below, so we don't try to warn about that.
> - */
> - tmp = (u64)ftdms * n;
> - do_div(tmp, 128 * sample_rate);
> - cts = tmp;
> + config3 = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
>
> - dev_dbg(hdmi->dev, "%s: fs=%uHz ftdms=%lu.%03luMHz N=%d cts=%d\n",
> - __func__, sample_rate, ftdms / 100, (ftdms / 1000) % 1000,
> - n, cts);
> + /* Only compute CTS when using internal AHB audio */
> + if (config3 & HDMI_CONFIG3_AHBAUDDMA) {
> + /*
> + * Compute the CTS value from the N value. Note that CTS and N
> + * can be up to 20 bits in total, so we need 64-bit math. Also
> + * note that our TDMS clock is not fully accurate; it is
> + * accurate to kHz. This can introduce an unnecessary remainder
> + * in the calculation below, so we don't try to warn about that.
> + */
> + tmp = (u64)ftdms * n;
> + do_div(tmp, 128 * sample_rate);
> + cts = tmp;
> +
> + dev_dbg(hdmi->dev, "%s: fs=%uHz ftdms=%lu.%03luMHz N=%d
> cts=%d\n",
> + __func__, sample_rate,
> + ftdms / 100, (ftdms / 1000) % 1000,
> + n, cts);
> + } else
> + cts = 0;
>
> spin_lock_irq(>audio_lock);
> hdmi->audio_n = n;
>
[PATCH 4/5] drm/i915: Do not override mode's aspect ratio with the prop value NONE
From: Ville Syrjälä
HDMI_PICTURE_ASPECT_NONE means "Automatic" so when the user has that
selected we should keep whatever aspect ratio the mode already has.
Also no point in checking for connector->is_hdmi in the SDVO code
since we only attach the property to HDMI connectors.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 +++--
drivers/gpu/drm/i915/display/intel_sdvo.c | 6 +++---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 0ebec69bbbfc..6a4650b44ac6 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2394,8 +2394,9 @@ int intel_hdmi_compute_config(struct intel_encoder
*encoder,
return -EINVAL;
}
- /* Set user selected PAR to incoming mode's member */
- adjusted_mode->picture_aspect_ratio = conn_state->picture_aspect_ratio;
+ if (conn_state->picture_aspect_ratio)
+ adjusted_mode->picture_aspect_ratio =
+ conn_state->picture_aspect_ratio;
pipe_config->lane_count = 4;
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
b/drivers/gpu/drm/i915/display/intel_sdvo.c
index ceda03e5a3d4..5cb619613157 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -1321,9 +1321,9 @@ static int intel_sdvo_compute_config(struct intel_encoder
*encoder,
if (IS_TV(intel_sdvo_connector))
i9xx_adjust_sdvo_tv_clock(pipe_config);
- /* Set user selected PAR to incoming mode's member */
- if (intel_sdvo_connector->is_hdmi)
- adjusted_mode->picture_aspect_ratio =
conn_state->picture_aspect_ratio;
+ if (conn_state->picture_aspect_ratio)
+ adjusted_mode->picture_aspect_ratio =
+ conn_state->picture_aspect_ratio;
if (!intel_sdvo_compute_avi_infoframe(intel_sdvo,
pipe_config, conn_state)) {
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/i915: Drop redundant aspec ratio prop value initialization
From: Ville Syrjälä HDMI_PICTURE_ASPECT_NONE is zero and the connector state is kzalloc()'d so no need to initialize conn_state->picture_aspect_ratio with it. Cc: Ilia Mirkin Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_hdmi.c | 1 - drivers/gpu/drm/i915/display/intel_sdvo.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index 6a4650b44ac6..f95f3db5ecb8 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -2809,7 +2809,6 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *c intel_attach_colorspace_property(connector); drm_connector_attach_content_type_property(connector); - connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) drm_object_attach_property(>base, diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c b/drivers/gpu/drm/i915/display/intel_sdvo.c index 5cb619613157..c471fcce59f8 100644 --- a/drivers/gpu/drm/i915/display/intel_sdvo.c +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c @@ -2624,7 +2624,6 @@ intel_sdvo_add_hdmi_properties(struct intel_sdvo *intel_sdvo, intel_attach_broadcast_rgb_property(>base.base); } intel_attach_aspect_ratio_property(>base.base); - connector->base.base.state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; } static struct intel_sdvo_connector *intel_sdvo_connector_alloc(void) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm: WARN on illegal aspect ratio when converting a mode to umode
From: Ville Syrjälä WARN if the incoming drm_display_mode has an illegal aspect ratio when converting it to a user mode. This should never happen unless the driver made a mistake and put an invalid value into the aspect ratio. Cc: Ilia Mirkin Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_modes.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 847048dee048..be2ccd8eccfd 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1906,8 +1906,11 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out, case HDMI_PICTURE_ASPECT_256_135: out->flags |= DRM_MODE_FLAG_PIC_AR_256_135; break; - case HDMI_PICTURE_ASPECT_RESERVED: default: + WARN(1, "Invalid aspect ratio (0%x) on mode\n", +in->picture_aspect_ratio); + /* fall through */ + case HDMI_PICTURE_ASPECT_NONE: out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; break; } -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm: Do not accept garbage mode aspect ratio flags
From: Ville Syrjälä Don't let userspace feed us any old garbage in the mode aspect ratio flags. Cc: Ilia Mirkin Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_modes.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 53acc6756ee0..847048dee048 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1977,9 +1977,11 @@ int drm_mode_convert_umode(struct drm_device *dev, case DRM_MODE_FLAG_PIC_AR_256_135: out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_256_135; break; - default: + case DRM_MODE_FLAG_PIC_AR_NONE: out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; break; + default: + return -EINVAL; } out->status = drm_mode_validate_driver(dev, out); -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm: Do not use bitwise OR to set picure_aspect_ratio
From: Ville Syrjälä
enum hdmi_picture_aspect is not a bitmask, so don't use bitwise OR
to populate it.
Cc: Ilia Mirkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 57e6408288c8..53acc6756ee0 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1966,16 +1966,16 @@ int drm_mode_convert_umode(struct drm_device *dev,
switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
case DRM_MODE_FLAG_PIC_AR_4_3:
- out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+ out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3;
break;
case DRM_MODE_FLAG_PIC_AR_16_9:
- out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+ out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
break;
case DRM_MODE_FLAG_PIC_AR_64_27:
- out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+ out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27;
break;
case DRM_MODE_FLAG_PIC_AR_256_135:
- out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+ out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_256_135;
break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/imx: ipu-v3 image converter fixes
Hi Dave, Daniel, please consider merging these fixes for v5.2. regards Philipp The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008: Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) are available in the Git repository at: git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-fixes-2019-06-20 for you to fetch changes up to 912bbf7e9ca422099935dd69d3ff0fd62db24882: gpu: ipu-v3: image-convert: Fix image downsize coefficients (2019-06-14 14:06:16 +0200) drm/imx: ipu-v3 image converter fixes This series fixes input buffer alignment and downsizer configuration to adhere to IPU mem2mem CSC/scaler hardware restrictions in certain downscaling ratios. Steve Longerbeam (3): gpu: ipu-v3: image-convert: Fix input bytesperline width/height align gpu: ipu-v3: image-convert: Fix input bytesperline for packed formats gpu: ipu-v3: image-convert: Fix image downsize coefficients drivers/gpu/ipu-v3/ipu-image-convert.c | 40 +++--- 1 file changed, 27 insertions(+), 13 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm: Aspect ratio fixes
From: Ville Syrjälä Ilia pointed out some oddball crap in the i915 aspect ratio handling. While looking at that I noticed a bunch of fail in the core as well. This series aims to fix it all. Cc: Ilia Mirkin Ville Syrjälä (5): drm: Do not use bitwise OR to set picure_aspect_ratio drm: Do not accept garbage mode aspect ratio flags drm: WARN on illegal aspect ratio when converting a mode to umode drm/i915: Do not override mode's aspect ratio with the prop value NONE drm/i915: Drop redundant aspec ratio prop value initialization drivers/gpu/drm/drm_modes.c | 17 +++-- drivers/gpu/drm/i915/display/intel_hdmi.c | 5 ++--- drivers/gpu/drm/i915/display/intel_sdvo.c | 4 +--- 3 files changed, 14 insertions(+), 12 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] DRM: Add KMS driver for the Ingenic JZ47xx SoCs
Le mer. 19 juin 2019 à 14:26, Sam Ravnborg a écrit : Hi Paul. On Mon, Jun 03, 2019 at 05:23:31PM +0200, Paul Cercueil wrote: Add a KMS driver for the Ingenic JZ47xx family of SoCs. This driver is meant to replace the aging jz4740-fb driver. This driver does not make use of the simple pipe helper, for the reason that it will soon be updated to support more advanced features like multiple planes, IPU integration for colorspace conversion and up/down scaling, support for DSI displays, and TV-out and HDMI outputs. Signed-off-by: Paul Cercueil Tested-by: Artur Rojek --- Notes: v2: - Remove custom handling of panel. The panel is now discovered using the standard API. - Lots of small tweaks suggested by upstream v3: - Use devm_drm_dev_init() - Update compatible strings to -lcd instead of -drm - Add destroy() callbacks to plane and crtc - The ingenic,lcd-mode is now read from the bridge's DT node v4: Remove ingenic,lcd-mode property completely. The various modes are now deduced from the connector type, the pixel format or the bus flags. v5: - Fix framebuffer size incorrectly calculated for 24bpp framebuffers - Use 32bpp framebuffer instead of 16bpp, as it'll work with both 16-bit and 24-bit panel - Get rid of drm_format_plane_cpp() which has been dropped upstream - Avoid using drm_format_info->depth, which is deprecated. In the drm world we include the revision notes in the changelog. So I did this when I applied it to drm-misc-next. Fixed a few trivial checkpatch warnings about indent too. There was a few too-long-lines warnings that I ignored. Fixing them would have hurt readability. Thanks. I assume you will maintain this driver onwards from now. Please request drm-misc commit rights (see https://www.freedesktop.org/wiki/AccountRequests/) You will need a legacy SSH account. I requested an account here: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/162 And you should familiarize yourself with the maintainer-tools: https://drm.pages.freedesktop.org/maintainer-tools/index.html For my use I use "dim update-branches; dim apply; dim push So only a small subset i needed for simple use. Sam
Re: [PATCH v1] backlight: pwm_bl: convert to use SPDX identifier
On 19/06/2019 14:59, Andy Shevchenko wrote:
Reduce size of duplicated comments by switching to use SPDX identifier.
No functional change.
While here, correct MODULE_LICENSE() string to be aligned with license text.
Signed-off-by: Andy Shevchenko
Acked-by: Daniel Thompson
---
drivers/video/backlight/pwm_bl.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index fb45f866b923..1f7f8d5c0bf1 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -1,13 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
/*
- * linux/drivers/video/backlight/pwm_bl.c
- *
- * simple PWM based backlight control, board code has to setup
+ * Simple PWM based backlight control, board code has to setup
* 1) pin configuration so PWM waveforms can output
* 2) platform_data being correctly configured
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
*/
#include
@@ -708,5 +703,5 @@ static struct platform_driver pwm_backlight_driver = {
module_platform_driver(pwm_backlight_driver);
MODULE_DESCRIPTION("PWM based Backlight Driver");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:pwm-backlight");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] backlight: gpio_backlight: Enable ACPI enumeration
On 19/06/2019 16:21, Andy Shevchenko wrote:
ACPI allows to enumerate specific devices by using compatible strings.
Enable that enumeration for GPIO based backlight devices.
Signed-off-by: Andy Shevchenko
---
drivers/video/backlight/gpio_backlight.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index e470da95d806..05c12df62b27 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
struct gpio_backlight {
@@ -61,11 +62,10 @@ static int gpio_backlight_probe_dt(struct platform_device
*pdev,
struct gpio_backlight *gbl)
{
struct device *dev = >dev;
- struct device_node *np = dev->of_node;
enum gpiod_flags flags;
int ret;
- gbl->def_value = of_property_read_bool(np, "default-on");
+ gbl->def_value = device_property_read_bool(dev, "default-on");
flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
@@ -89,26 +89,19 @@ static int gpio_backlight_probe(struct platform_device
*pdev)
struct backlight_properties props;
struct backlight_device *bl;
struct gpio_backlight *gbl;
- struct device_node *np = pdev->dev.of_node;
int ret;
- if (!pdata && !np) {
- dev_err(>dev,
- "failed to find platform data or device tree node.\n");
- return -ENODEV;
- }
-
gbl = devm_kzalloc(>dev, sizeof(*gbl), GFP_KERNEL);
if (gbl == NULL)
return -ENOMEM;
gbl->dev = >dev;
- if (np) {
+ if (pdev->dev.fwnode) {
ret = gpio_backlight_probe_dt(pdev, gbl);
if (ret)
return ret;
- } else {
+ } else if (pdata) {
/*
* Legacy platform data GPIO retrieveal. Do not expand
* the use of this code path, currently only used by one
@@ -129,6 +122,10 @@ static int gpio_backlight_probe(struct platform_device
*pdev)
gbl->gpiod = gpio_to_desc(pdata->gpio);
if (!gbl->gpiod)
return -EINVAL;
+ } else {
+ dev_err(>dev,
+ "failed to find platform data or device tree node.\n");
Should the string also be updated?
If what is updated to acknoledge option to use ACPI then:
Acked-by: Daniel Thompson
+ return -ENODEV;
}
memset(, 0, sizeof(props));
@@ -149,19 +146,17 @@ static int gpio_backlight_probe(struct platform_device
*pdev)
return 0;
}
-#ifdef CONFIG_OF
static struct of_device_id gpio_backlight_of_match[] = {
{ .compatible = "gpio-backlight" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, gpio_backlight_of_match);
-#endif
static struct platform_driver gpio_backlight_driver = {
.driver = {
.name = "gpio-backlight",
- .of_match_table = of_match_ptr(gpio_backlight_of_match),
+ .of_match_table = gpio_backlight_of_match,
},
.probe = gpio_backlight_probe,
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Re: [PATCH] backlight: gpio-backlight: Set power state instead of brightness at probe
On 18/06/2019 13:58, Paul Kocialkowski wrote:
Hi,
On Fri, 2019-05-17 at 17:05 +0200, Paul Kocialkowski wrote:
On a trivial gpio-backlight setup with a panel using the backlight but
no boot software to enable it beforehand, we fall in a case where the
backlight is disabled (not just blanked) and thus remains disabled when
the panel gets enabled.
Setting gbl->def_value via the device-tree prop allows enabling the
backlight in this situation, but it will be unblanked straight away,
in compliance with the binding. This does not work well when there was no
boot software to display something before, since we really need to unblank
by the time the panel is enabled, not before.
Resolve the situation by setting the brightness to 1 at probe and
managing the power state accordingly, a bit like it's done in
pwm-backlight.
Any feedback on this? I was under the impression that it could be quite
controversial, as it implies that the backlight can no longer be
enabled without a bound panel (which IMO makes good sense but could be
a matter to debate).
My apologies. This patch brought on such severe deja-vu I got rather
confused. Then when I went digging I've also dropped the ball on the
same feature previously.
Peter Ujfalusi provided a similar patch to yours but with a slightly
different implementation:
https://lore.kernel.org/patchwork/patch/1002359/
On the whole I think it is important to read the GPIO pin since
otherwise we swap problems when there bootloader does setup the
backlight for problems where it does not.
The thing I don't get is why both patches try to avoid setting the
backlight brightness from def_value. Simple displays, especially
monochrome ones are perfectly readable with the backlight off... zero
brightness is not a "bad" value.
Not sure if Peter is still willing to rev his version of this code
(given how badly we neglected him previously) or whether you want to try
and combine both ideas.
Daniel.
Cheers,
Paul
Fixes: 8b770e3c9824 ("backlight: Add GPIO-based backlight driver")
Signed-off-by: Paul Kocialkowski
---
drivers/video/backlight/gpio_backlight.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index e470da95d806..c9cb97fa13d0 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -57,6 +57,21 @@ static const struct backlight_ops gpio_backlight_ops = {
.check_fb = gpio_backlight_check_fb,
};
+static int gpio_backlight_initial_power_state(struct gpio_backlight *gbl)
+{
+ struct device_node *node = gbl->dev->of_node;
+
+ /* If we absolutely want the backlight enabled at boot. */
+ if (gbl->def_value)
+ return FB_BLANK_UNBLANK;
+
+ /* If there's no panel to unblank the backlight later. */
+ if (!node || !node->phandle)
+ return FB_BLANK_UNBLANK;
+
+ return FB_BLANK_POWERDOWN;
+}
+
static int gpio_backlight_probe_dt(struct platform_device *pdev,
struct gpio_backlight *gbl)
{
@@ -142,7 +157,9 @@ static int gpio_backlight_probe(struct platform_device
*pdev)
return PTR_ERR(bl);
}
- bl->props.brightness = gbl->def_value;
+ bl->props.brightness = 1;
+ bl->props.power = gpio_backlight_initial_power_state(gbl);
+
backlight_update_status(bl);
platform_set_drvdata(pdev, bl);
[PATCH v7 4/6] dt-bindings: display: hdmi-connector: Support DDC bus enable
From: Ondrej Jirman Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable on-board voltage shifting logic for the DDC bus using a gpio to be able to access DDC bus. Use ddc-en-gpios property on the hdmi-connector to model this. Add binding documentation for optional ddc-en-gpios property. Signed-off-by: Ondrej Jirman Reviewed-by: Rob Herring --- .../devicetree/bindings/display/connector/hdmi-connector.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt index 508aee461e0d..aeb07c4bd703 100644 --- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt +++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt @@ -9,6 +9,7 @@ Optional properties: - label: a symbolic name for the connector - hpd-gpios: HPD GPIO number - ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing +- ddc-en-gpios: signal to enable DDC bus Required nodes: - Video port for HDMI input -- 2.22.0
[PATCH v7 3/6] arm64: dts: allwinner: orange-pi-3: Enable ethernet
From: Ondrej Jirman
Orange Pi 3 has two regulators that power the Realtek RTL8211E. According
to the phy datasheet, both regulators need to be enabled at the same time,
but we can only specify a single phy-supply in the DT.
This can be achieved by making one regulator depedning on the other via
vin-supply. While it's not a technically correct description of the
hardware, it achieves the purpose.
All values of RX/TX delay were tested exhaustively and a middle one of the
working values was chosen.
Signed-off-by: Ondrej Jirman
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts| 44 +++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 17d496990108..2c6807b74ff6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -15,6 +15,7 @@
aliases {
serial0 =
+ ethernet0 =
};
chosen {
@@ -44,6 +45,27 @@
regulator-max-microvolt = <500>;
regulator-always-on;
};
+
+ /*
+* The board uses 2.5V RGMII signalling. Power sequence to enable
+* the phy is to enable GMAC-2V5 and GMAC-3V (aldo2) power rails
+* at the same time and to wait 100ms.
+*/
+ reg_gmac_2v5: gmac-2v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "gmac-2v5";
+ regulator-min-microvolt = <250>;
+ regulator-max-microvolt = <250>;
+ startup-delay-us = <10>;
+ enable-active-high;
+ gpio = < 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
+
+ /* The real parent of gmac-2v5 is reg_vcc5v, but we need to
+* enable two regulators to power the phy. This is one way
+* to achieve that.
+*/
+ vin-supply = <_aldo2>; /* GMAC-3V */
+ };
};
{
@@ -58,6 +80,28 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <_rgmii_phy>;
+ phy-supply = <_gmac_2v5>;
+ allwinner,rx-delay-ps = <1500>;
+ allwinner,tx-delay-ps = <700>;
+ status = "okay";
+};
+
+ {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+
+ reset-gpios = < 3 14 GPIO_ACTIVE_LOW>; /* PD14 */
+ reset-assert-us = <15000>;
+ reset-deassert-us = <4>;
+ };
+};
+
{
vmmc-supply = <_cldo1>;
cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
--
2.22.0
[PATCH v7 2/6] net: stmmac: sun8i: force select external PHY when no internal one
From: Icenowy Zheng
The PHY selection bit also exists on SoCs without an internal PHY; if it's
set to 1 (internal PHY, default value) then the MAC will not make use of
any PHY on such SoCs.
This problem appears when adapting for H6, which has no real internal PHY
(the "internal PHY" on H6 is not on-die, but on a co-packaged AC200 chip,
connected via RMII interface at GPIO bank A).
Force the PHY selection bit to 0 when the SOC doesn't have an internal PHY,
to address the problem of a wrong default value.
Signed-off-by: Icenowy Zheng
Signed-off-by: Ondrej Jirman
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index c3e94104474f..6d5cba4075eb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -898,6 +898,11 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
* address. No need to mask it again.
*/
reg |= 1 << H3_EPHY_ADDR_SHIFT;
+ } else {
+ /* For SoCs without internal PHY the PHY selection bit should be
+* set to 0 (external PHY).
+*/
+ reg &= ~H3_EPHY_SELECT;
}
if (!of_property_read_u32(node, "allwinner,tx-delay-ps", )) {
--
2.22.0
[PATCH v7 0/6] Add support for Orange Pi 3
From: Ondrej Jirman This series implements support for Xunlong Orange Pi 3 board. - ethernet support (patches 1-3) - HDMI support (patches 4-6) For some people, ethernet doesn't work after reboot (but works on cold boot), when the stmmac driver is built into the kernel. It works when the driver is built as a module. It's either some timing issue, or power supply issue or a combination of both. Module build induces a power cycling of the phy. I encourage people with this issue, to build the driver into the kernel, and try to alter the reset timings for the phy in DTS or startup-delay-us and report the findings. Please take a look. thank you and regards, Ondrej Jirman Changes in v7: - dropped stored reference to connector_pdev as suggested by Jernej - added forgotten dt-bindings reviewed-by tag Changes in v6: - added dt-bindings reviewed-by tag - fix wording in stmmac commit (as suggested by Sergei) Changes in v5: - dropped already applied patches (pinctrl patches, mmc1 pinconf patch) - rename GMAC-3V3 -> GMAC-3V to match the schematic (Jagan) - changed hdmi-connector's ddc-supply property to ddc-en-gpios (Rob Herring) Changes in v4: - fix checkpatch warnings/style issues - use enum in struct sunxi_desc_function for io_bias_cfg_variant - collected acked-by's - fix compile error in drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c:156 caused by missing conversion from has_io_bias_cfg struct member (I've kept the acked-by, because it's a trivial change, but feel free to object.) (reported by Martin A. on github) I did not have A80 pinctrl enabled for some reason, so I did not catch this sooner. - dropped brcm firmware patch (was already applied) - dropped the wifi dts patch (will re-send after H6 RTC gets merged, along with bluetooth support, in a separate series) Changes in v3: - dropped already applied patches - changed pinctrl I/O bias selection constants to enum and renamed - added /omit-if-no-ref/ to mmc1_pins - made mmc1_pins default pinconf for mmc1 in H6 dtsi - move ddc-supply to HDMI connector node, updated patch descriptions, changed dt-bindings docs Changes in v2: - added dt-bindings documentation for the board's compatible string (suggested by Clement) - addressed checkpatch warnings and code formatting issues (on Maxime's suggestions) - stmmac: dropped useless parenthesis, reworded description of the patch (suggested by Sergei) - drop useles dev_info() about the selected io bias voltage - docummented io voltage bias selection variant macros - wifi: marked WiFi DTS patch and realted mmc1_pins as "DO NOT MERGE", because wifi depends on H6 RTC support that's not merged yet (suggested by Clement) - added missing signed-of-bys - changed dr_mode to otg, and added a note about VBUS - improved wording of HDMI driver's DDC power supply patch Icenowy Zheng (2): net: stmmac: sun8i: add support for Allwinner H6 EMAC net: stmmac: sun8i: force select external PHY when no internal one Ondrej Jirman (4): arm64: dts: allwinner: orange-pi-3: Enable ethernet dt-bindings: display: hdmi-connector: Support DDC bus enable drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue arm64: dts: allwinner: orange-pi-3: Enable HDMI output .../display/connector/hdmi-connector.txt | 1 + .../dts/allwinner/sun50i-h6-orangepi-3.dts| 70 +++ drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 54 -- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 + .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 21 ++ 5 files changed, 144 insertions(+), 4 deletions(-) -- 2.22.0
[PATCH v7 5/6] drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue
From: Ondrej Jirman
Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
for the DDC bus to be usable.
Add support for hdmi-connector node's optional ddc-en-gpios property to
support this use case.
Signed-off-by: Ondrej Jirman
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 54 +--
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 39d8509d96a0..6733bfc9c2d6 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -98,10 +98,34 @@ static u32 sun8i_dw_hdmi_find_possible_crtcs(struct
drm_device *drm,
return crtcs;
}
+static int sun8i_dw_hdmi_find_connector_pdev(struct device *dev,
+struct platform_device **pdev_out)
+{
+ struct platform_device *pdev;
+ struct device_node *remote;
+
+ remote = of_graph_get_remote_node(dev->of_node, 1, -1);
+ if (!remote)
+ return -ENODEV;
+
+ if (!of_device_is_compatible(remote, "hdmi-connector")) {
+ of_node_put(remote);
+ return -ENODEV;
+ }
+
+ pdev = of_find_device_by_node(remote);
+ of_node_put(remote);
+ if (!pdev)
+ return -ENODEV;
+
+ *pdev_out = pdev;
+ return 0;
+}
+
static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
void *data)
{
- struct platform_device *pdev = to_platform_device(dev);
+ struct platform_device *pdev = to_platform_device(dev), *connector_pdev;
struct dw_hdmi_plat_data *plat_data;
struct drm_device *drm = data;
struct device_node *phy_node;
@@ -151,16 +175,30 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
device *master,
return PTR_ERR(hdmi->regulator);
}
+ ret = sun8i_dw_hdmi_find_connector_pdev(dev, _pdev);
+ if (!ret) {
+ hdmi->ddc_en = gpiod_get_optional(_pdev->dev,
+ "ddc-en", GPIOD_OUT_HIGH);
+ platform_device_put(connector_pdev);
+
+ if (IS_ERR(hdmi->ddc_en)) {
+ dev_err(dev, "Couldn't get ddc-en gpio\n");
+ return PTR_ERR(hdmi->ddc_en);
+ }
+ }
+
ret = regulator_enable(hdmi->regulator);
if (ret) {
dev_err(dev, "Failed to enable regulator\n");
- return ret;
+ goto err_unref_ddc_en;
}
+ gpiod_set_value(hdmi->ddc_en, 1);
+
ret = reset_control_deassert(hdmi->rst_ctrl);
if (ret) {
dev_err(dev, "Could not deassert ctrl reset control\n");
- goto err_disable_regulator;
+ goto err_disable_ddc_en;
}
ret = clk_prepare_enable(hdmi->clk_tmds);
@@ -213,8 +251,12 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
device *master,
clk_disable_unprepare(hdmi->clk_tmds);
err_assert_ctrl_reset:
reset_control_assert(hdmi->rst_ctrl);
-err_disable_regulator:
+err_disable_ddc_en:
+ gpiod_set_value(hdmi->ddc_en, 0);
regulator_disable(hdmi->regulator);
+err_unref_ddc_en:
+ if (hdmi->ddc_en)
+ gpiod_put(hdmi->ddc_en);
return ret;
}
@@ -228,7 +270,11 @@ static void sun8i_dw_hdmi_unbind(struct device *dev,
struct device *master,
sun8i_hdmi_phy_remove(hdmi);
clk_disable_unprepare(hdmi->clk_tmds);
reset_control_assert(hdmi->rst_ctrl);
+ gpiod_set_value(hdmi->ddc_en, 0);
regulator_disable(hdmi->regulator);
+
+ if (hdmi->ddc_en)
+ gpiod_put(hdmi->ddc_en);
}
static const struct component_ops sun8i_dw_hdmi_ops = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 720c5aa8adc1..d707c9171824 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -190,6 +191,7 @@ struct sun8i_dw_hdmi {
struct regulator*regulator;
const struct sun8i_dw_hdmi_quirks *quirks;
struct reset_control*rst_ctrl;
+ struct gpio_desc*ddc_en;
};
static inline struct sun8i_dw_hdmi *
--
2.22.0
[PATCH v7 6/6] arm64: dts: allwinner: orange-pi-3: Enable HDMI output
From: Ondrej Jirman
Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
This is realized by the ddc-en-gpios property.
Signed-off-by: Ondrej Jirman
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts| 26 +++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 2c6807b74ff6..01bb1bafe284 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -22,6 +22,18 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -72,6 +84,10 @@
cpu-supply = <_dcdca>;
};
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
@@ -91,6 +107,16 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <_con_in>;
+ };
+};
+
{
ext_rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.22.0
[PATCH v7 1/6] net: stmmac: sun8i: add support for Allwinner H6 EMAC
From: Icenowy Zheng
The EMAC on Allwinner H6 is just like the one on A64. The "internal PHY" on
H6 is on a co-packaged AC200 chip, and it's not really internal (it's
connected via RMII at PA GPIO bank).
Add support for the Allwinner H6 EMAC in the dwmac-sun8i driver.
Signed-off-by: Icenowy Zheng
Signed-off-by: Ondrej Jirman
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c| 16
1 file changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index b15c6d5dbd38..c3e94104474f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -138,6 +138,20 @@ static const struct emac_variant emac_variant_a64 = {
.tx_delay_max = 7,
};
+static const struct emac_variant emac_variant_h6 = {
+ .default_syscon_value = 0x5,
+ .syscon_field = _syscon_reg_field,
+ /* The "Internal PHY" of H6 is not on the die. It's on the
+* co-packaged AC200 chip instead.
+*/
+ .soc_has_internal_phy = false,
+ .support_mii = true,
+ .support_rmii = true,
+ .support_rgmii = true,
+ .rx_delay_max = 31,
+ .tx_delay_max = 7,
+};
+
#define EMAC_BASIC_CTL0 0x00
#define EMAC_BASIC_CTL1 0x04
#define EMAC_INT_STA0x08
@@ -1216,6 +1230,8 @@ static const struct of_device_id sun8i_dwmac_match[] = {
.data = _variant_r40 },
{ .compatible = "allwinner,sun50i-a64-emac",
.data = _variant_a64 },
+ { .compatible = "allwinner,sun50i-h6-emac",
+ .data = _variant_h6 },
{ }
};
MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
--
2.22.0
RE: [v7 00/16] Add Plane Color Properties
>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Ville >Syrjälä >Sent: Wednesday, June 19, 2019 10:00 PM >To: Ezequiel Garcia >Cc: Syrjala, Ville ; intel-...@lists.freedesktop.org; >Emil >Velikov ; dri-devel >; >Andrzej Pietrasiewicz ; Shankar, Uma >; Sean Paul ; Ezequiel Garcia >; Boris Brezillon >; >Lankhorst, Maarten >Subject: Re: [v7 00/16] Add Plane Color Properties > >On Wed, Jun 19, 2019 at 12:33:33PM -0300, Ezequiel Garcia wrote: >> On Wed, 2019-06-19 at 18:03 +0300, Ville Syrjälä wrote: >> > On Wed, Jun 19, 2019 at 10:18:18AM -0300, Ezequiel Garcia wrote: >> > > On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote: >> > > > > -Original Message- >> > > > > From: dri-devel >> > > > > [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >> > > > > Ezequiel Garcia >> > > > > Sent: Friday, June 14, 2019 9:48 PM >> > > > > To: Shankar, Uma >> > > > > Cc: Emil Velikov ; >> > > > > intel-...@lists.freedesktop.org; Syrjala, Ville >> > > > > ; Lankhorst, Maarten >> > > > > ; dri-devel >> > > > > >> > > > > Subject: Re: [v7 00/16] Add Plane Color Properties >> > > > > >> > > > > On Thu, 28 Mar 2019 at 16:50, Uma Shankar >wrote: >> > > > > > This is how a typical display color hardware pipeline looks like: >> > > > > > +---+ >> > > > > > |RAM| >> > > > > > | +--++-++-+ | >> > > > > > | | FB 1 || FB 2 || FB N| | >> > > > > > | +--++-++-+ | >> > > > > > +---+ >> > > > > >| Plane Color Hardware Block | >> > > > > > ++ >> > > > > > | +---v-+ +---v---+ +---v--+ | >> > > > > > | | Plane A | | Plane B | | Plane N | | >> > > > > > | | DeGamma | | Degamma | | Degamma | | >> > > > > > | +---+-+ +---+---+ +---+--+ | >> > > > > > | | | || >> > > > > > | +---v-+ +---v---+ +---v--+ | >> > > > > > | |Plane A | | Plane B | | Plane N | | >> > > > > > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | >> > > > > > | +---+-+ ++--+ ++-+ | >> > > > > > | | | | | >> > > > > > | +---v-+ +v--+ +v-+ | >> > > > > > | | Plane A | | Plane B | | Plane N | | >> > > > > > | | Gamma | | Gamma | | Gamma| | >> > > > > > | +---+-+ ++--+ ++-+ | >> > > > > > | | | | | >> > > > > > ++ >> > > > > > +--v--v---v---| >> > > > > > > > || >> > > > > > > > Pipe Blender|| >> > > > > > +++ >> > > > > > >|| >> > > > > > >+---v--+ | >> > > > > > >| Pipe DeGamma| | >> > > > > > >| | | >> > > > > > >+---+--+ | >> > > > > > >|Pipe Color | >> > > > > > >+---v--+ Hardware| >> > > > > > >| Pipe CSC/CTM| | >> > > > > > >| | | >> > > > > > >+---+--+ | >> > > > > > >|| >> > > > > > >+---v--+ | >> > > > > > >| Pipe Gamma | | >> > > > > > >| | | >> > > > > > >+---+--+ | >> > > > > > >|| >> > > > > > +-+ >> > > > > > | >> > > > > > v >> > > > > >Pipe Output >> > > > > > >> > > > > > This patch series adds properties for plane color features. >> > > > > > It adds properties for degamma used to linearize data, CSC >> > > > > > used for gamut conversion, and gamma used to again >> > > > > > non-linearize data as per panel supported color space. These >> > > > > > can be utilize by user space to convert planes from one format to >> > > > > > another, >one color space to another etc. >> > > > > > >> > > > > > Usersapce can take smart blending decisions and utilize >> > > > > > these hardware supported plane color features to get >> > > > > > accurate color profile. The same can help in consistent >> > > > > > color quality from source to panel taking advantage of advanced >> > > > > > color >features in hardware. >> > > > > > >> > > > > > These patches just add the property interfaces and
[Bug 109887] vega56 undervolting/overclocking voltage issues
https://bugs.freedesktop.org/show_bug.cgi?id=109887 --- Comment #7 from hagar-dunor --- Met the same annoyance, and found a rather convoluted way to get around it. It would be better overclocking/undervolting work by setting pp_od_clk_voltage only. https://forum.level1techs.com/t/how-to-overclock-vega-on-linux/132771/65 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] backlight: Don't build support by default
On 12/06/2019 14:27, Marc Gonzalez wrote:
b20c5249aa6a ("backlight: Fix compile error if CONFIG_FB is unset")
added 'default m' for BACKLIGHT_CLASS_DEVICE and LCD_CLASS_DEVICE.
It took me some little while until I realized this patch is from 2005
which explains why I couldn't find it in the modern git repo!
Let's go back to not building support by default.
At first glance disabling this by default looks like it would cause some
existing defconfig files to disable useful drivers.
For backlight I think this isn't true (because both DRM and FB_BACKLIGHT
have a "select" on BACKLIGHT_CLASS_DEVICE).
However for LCD it is not nearly as clear cut. Commit message needs to
explain why this won't cause unacceptable problems for existinng
defconfig files.
Daniel.
Signed-off-by: Marc Gonzalez
---
drivers/video/backlight/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 8b081d61773e..40676be2e46a 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -10,7 +10,6 @@ menu "Backlight & LCD device support"
#
config LCD_CLASS_DEVICE
tristate "Lowlevel LCD controls"
- default m
help
This framework adds support for low-level control of LCD.
Some framebuffer devices connect to platform-specific LCD modules
@@ -143,7 +142,6 @@ endif # LCD_CLASS_DEVICE
#
config BACKLIGHT_CLASS_DEVICE
tristate "Lowlevel Backlight controls"
- default m
help
This framework adds support for low-level control of the LCD
backlight. This includes support for brightness and power.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/panel: Add support for Raydium RM67191 panel driver
This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
protocol).
Signed-off-by: Robert Chiras
Reviewed-by: Sam Ravnborg
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm67191.c | 690 ++
4 files changed, 706 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-raydium-rm67191.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a2f487..cd93030e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5089,6 +5089,12 @@ S: Maintained
F: drivers/gpu/drm/qxl/
F: include/uapi/drm/qxl_drm.h
+DRM DRIVER FOR RAYDIUM RM67191 PANELS
+M: Robert Chiras
+S: Maintained
+F: drivers/gpu/drm/panel/panel-raydium-rm67191.c
+F: Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
+
DRM DRIVER FOR RAGE 128 VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/r128/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d9d931a..8be1ac1 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -159,6 +159,15 @@ config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN
Pi 7" Touchscreen. To compile this driver as a module,
choose M here.
+config DRM_PANEL_RAYDIUM_RM67191
+ tristate "Raydium RM67191 FHD 1080x1920 DSI video mode panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Raydium RM67191 FHD
+ (1080x1920) DSI panel.
+
config DRM_PANEL_RAYDIUM_RM68200
tristate "Raydium RM68200 720x1280 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index fb0cb3a..1fc0f68 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) +=
panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
panel-raspberrypi-touchscreen.o
+obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_ROCKTECH_JH057N00900) += panel-rocktech-jh057n00900.o
obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm67191.c
b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
new file mode 100644
index 000..c4d7dfd
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
@@ -0,0 +1,690 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Raydium RM67191 MIPI-DSI panel driver
+ *
+ * Copyright 2019 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Panel specific color-format bits */
+#define COL_FMT_16BPP 0x55
+#define COL_FMT_18BPP 0x66
+#define COL_FMT_24BPP 0x77
+
+/* Write Manufacture Command Set Control */
+#define WRMAUCCTR 0xFE
+
+/* Manufacturer Command Set pages (CMD2) */
+struct cmd_set_entry {
+ u8 cmd;
+ u8 param;
+};
+
+/*
+ * There is no description in the Reference Manual about these commands.
+ * We received them from vendor, so just use them as is.
+ */
+static const struct cmd_set_entry manufacturer_cmd_set[] = {
+ {0xFE, 0x0B},
+ {0x28, 0x40},
+ {0x29, 0x4F},
+ {0xFE, 0x0E},
+ {0x4B, 0x00},
+ {0x4C, 0x0F},
+ {0x4D, 0x20},
+ {0x4E, 0x40},
+ {0x4F, 0x60},
+ {0x50, 0xA0},
+ {0x51, 0xC0},
+ {0x52, 0xE0},
+ {0x53, 0xFF},
+ {0xFE, 0x0D},
+ {0x18, 0x08},
+ {0x42, 0x00},
+ {0x08, 0x41},
+ {0x46, 0x02},
+ {0x72, 0x09},
+ {0xFE, 0x0A},
+ {0x24, 0x17},
+ {0x04, 0x07},
+ {0x1A, 0x0C},
+ {0x0F, 0x44},
+ {0xFE, 0x04},
+ {0x00, 0x0C},
+ {0x05, 0x08},
+ {0x06, 0x08},
+ {0x08, 0x08},
+ {0x09, 0x08},
+ {0x0A, 0xE6},
+ {0x0B, 0x8C},
+ {0x1A, 0x12},
+ {0x1E, 0xE0},
+ {0x29, 0x93},
+ {0x2A, 0x93},
+ {0x2F, 0x02},
+ {0x31, 0x02},
+ {0x33, 0x05},
+ {0x37, 0x2D},
+ {0x38, 0x2D},
+ {0x3A, 0x1E},
+ {0x3B, 0x1E},
+ {0x3D, 0x27},
+ {0x3F, 0x80},
+ {0x40, 0x40},
+ {0x41, 0xE0},
+ {0x4F, 0x2F},
+ {0x50, 0x1E},
+ {0xFE, 0x06},
+ {0x00, 0xCC},
+ {0x05, 0x05},
+ {0x07, 0xA2},
+ {0x08, 0xCC},
+ {0x0D, 0x03},
+ {0x0F, 0xA2},
+ {0x32, 0xCC},
+ {0x37, 0x05},
+ {0x39, 0x83},
+ {0x3A, 0xCC},
+ {0x41, 0x04},
+ {0x43, 0x83},
+ {0x44, 0xCC},
+ {0x49, 0x05},
[PATCH v3 0/2] Add DSI panel driver for Raydium RM67191
This patch-set contains the DRM panel driver and dt-bindings documentation for the DSI driven panel: Raydium RM67191. v3: - Added myself to MAINTAINERS for this driver (sam) - Removed display-timings property (fabio) - Fixed dt description (sam) - Re-arranged calls inside get_modes function (sam) - Changed ifdefs with _maybe_unused for suspend/resume functions (sam) - Collected Reviewed-by from Sam v2: - Fixed 'reset-gpio' to 'reset-gpios' property naming (fabio) - Changed the state of the reset gpio to active low and fixed how it is handled in driver (fabio) - Fixed copyright statement (daniel) - Reordered includes (sam) - Added defines for panel specific color formats (fabio) - Removed unnecessary tests in enable and unprepare (sam) - Removed the unnecessary backlight write in enable (sam) Robert Chiras (2): dt-bindings: display: panel: Add support for Raydium RM67191 panel drm/panel: Add support for Raydium RM67191 panel driver .../bindings/display/panel/raydium,rm67191.txt | 39 ++ MAINTAINERS| 6 + drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-raydium-rm67191.c | 690 + 5 files changed, 745 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt create mode 100644 drivers/gpu/drm/panel/panel-raydium-rm67191.c -- 2.7.4
Re: [PATCH] drm/imx: correct order of crtc disable
On Thu, 2019-06-20 at 14:32 +0200, Daniel Vetter wrote:
> On Thu, Jun 20, 2019 at 12:12:13PM +0100, Robert Beckett wrote:
> > On Thu, 2019-06-20 at 10:50 +0200, Daniel Vetter wrote:
> > > On Wed, Jun 19, 2019 at 11:40 AM Philipp Zabel <
> > > p.za...@pengutronix.de> wrote:
> > > >
> > > > Hi Robert,
> > > >
> > > > thank you for the patch.
> > > >
> > > > On Tue, 2019-06-18 at 16:50 +0100, Robert Beckett wrote:
> > > > > Notify drm core before sending pending events during crtc
> > > > > disable.
> > > > > This fixes the first event after disable having an old stale
> > > > > timestamp
> > > > > by having drm_crtc_vblank_off update the timestamp to now.
> > > > >
> > > > > This was seen while debugging weston log message:
> > > > > Warning: computed repaint delay is insane: -8212 msec
> > > > >
> > > >
> > > > Would you say this
> > > > Fixes: a474478642d5 ("drm/imx: fix crtc vblank state
> > > > regression")
> > > > ?
> > > >
> > > > > Signed-off-by: Robert Beckett
> > > > > ---
> > > > > drivers/gpu/drm/imx/ipuv3-crtc.c | 6 +++---
> > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > > index 9cc1d678674f..c436a28d50e4 100644
> > > > > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > > @@ -91,14 +91,14 @@ static void
> > > > > ipu_crtc_atomic_disable(struct
> > > > > drm_crtc *crtc,
> > > > > ipu_dc_disable(ipu);
> > > > > ipu_prg_disable(ipu);
> > > > >
> > > > > + drm_crtc_vblank_off(crtc);
> > > > > +
> > > >
> > > > This is explained in the commit message and aligns with the
> > > > drm_crtc_state @event documentation.
> > >
> > > This part here looks fishy. The drm_vblank.c code is supposed to
> > > do
> > > the right thing, no matter where or when you ask it to generate
> > > an
> > > event. It definitely shouldn't generate a timestamp that's a few
> > > seconds too early. Bunch of options:
> > > - there's a bug in drm_vblank.c and it's mixing up something and
> > > generating a totally bogus value.
> > > - there's a lie in your imx vblank code, which trips the
> > > drm_vblank.c
> > > counter interpolation and results in a totally bogus value.
> > >
> > > drm_vblank.c assumes that if you do claim to have a hw counter
> > > and
> > > generate timestamps, that those are perfectly accurate. It only
> > > falls
> > > back to guestimating using the system timer if that's not
> > > present.
> > >
> > > Either way, this very much smells like papering over a bug if
> > > this
> > > change indeed fixes your wrong vblank timestamps.
> > >
> >
> > A quick explaination of where the dodgy timestamp came from:
> > 1. driver starts up
> > 2. fbcon comes along and restores fbdev, enabling vblank
> > 3. vblank_disable_fn fires via timer disabling vblank, keeping
> > vblank
> > seq number and time set at current value
> > (some time later)
> > 4. weston starts and does a modeset
> > 5. atomic commit disables crtc while it does the modeset
> > 6. ipu_crtc_atomic_disable sends vblank with old seq number and
> > time
> >
> > It turns out the actual fix for the old vblank is the next change,
> > which stops it being sent at all during the crtc disable as it is
> > is
> > still active, it would then go through drm_crtc_vblank_off,
> > reseting
> > the timestamp, and get delivered during the vblank enable as part
> > of
> > the atomic commit.
>
> This shouldn't fix your vblank timestamp troubles either. It might
> mean
> that the timestamp is slightly too early (because you take it while
> shutting down the crtc, not while re-enabling), but not by seconds.
>
> Quick experiment: Disable vblank disabling with drm.vblankoffdelay =
> 0. If
> that also fixes the timestamps, then I'm pretty sure you have a
> driver bug
> somewhere and lie to the vblank core code about something.
> -Daniel
>
Experiment done. The timestamp is fine, it is the timestamp of the
previous vblank update. But, this would fix it because the vblank
interrupt was never disabled.
The original issue was that the event got sent after vblank was
disabled and before it got re-enabled during the modeset, so nothing
had happened to update the timestamp and seq number.
What are you expecting to update the timestamp and seq number while the
interrupt is disabled after vblank_disable_fn?
Im struggling to see what this experiment was meant to test/prove.
> >
> > So, in theory, we could just have the following change to fix the
> > specific issue of a stale timestamp.
> >
> > However, given the documentation for the event in
> > include/drm/drm_crtc.h:
> >
> > * - The event is for a CRTC which is being disabled
> > through
> > this
> > *atomic commit. In that case the event can be send out
> > any
> > time
> > *after the hardware has stopped scanning out the
> > current
> > *framebuffers. It should contain
[PATCH v3 1/2] dt-bindings: display: panel: Add support for Raydium RM67191 panel
Add dt-bindings documentation for Raydium RM67191 DSI panel.
Signed-off-by: Robert Chiras
Reviewed-by: Sam Ravnborg
---
.../bindings/display/panel/raydium,rm67191.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
new file mode 100644
index 000..52af272
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
@@ -0,0 +1,39 @@
+Raydium RM67171 OLED LCD panel with MIPI-DSI protocol
+
+Required properties:
+- compatible: "raydium,rm67191"
+- reg: virtual channel for MIPI-DSI protocol
+ must be <0>
+- dsi-lanes: number of DSI lanes to be used
+ must be <3> or <4>
+- port:input port node with endpoint definition as
+ defined in Documentation/devicetree/bindings/graph.txt;
+ the input port should be connected to a MIPI-DSI device
+ driver
+
+Optional properties:
+- reset-gpios: a GPIO spec for the RST_B GPIO pin
+- width-mm:see panel-common.txt
+- height-mm: see panel-common.txt
+- video-mode: 0 - burst-mode
+ 1 - non-burst with sync event
+ 2 - non-burst with sync pulse
+
+Example:
+
+ panel@0 {
+ compatible = "raydium,rm67191";
+ reg = <0>;
+ pinctrl-0 = <_mipi_dsi_0_1_en>;
+ pinctrl-names = "default";
+ reset-gpios = < 7 GPIO_ACTIVE_LOW>;
+ dsi-lanes = <4>;
+ width-mm = <68>;
+ height-mm = <121>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
--
2.7.4
Re: [PATCH 1/7] video: add HDMI state notifier support
On Thu, Jun 20, 2019 at 5:25 PM Daniel Vetter wrote: > > On Wed, Jun 19, 2019 at 07:48:11PM +0800, Cheng-yi Chiang wrote: > > On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter wrote: > > > > > > On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote: > > > > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter wrote: > > > > > > > > > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote: > > > > > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter > > > > > > wrote: > > > > > > > > > > > > > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote: > > > > > > > > On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote: > > > > > > > > > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote: > > > > > > > > > > > From: Hans Verkuil > > > > > > > > > > > > > > > > > > > > > > Add support for HDMI hotplug and EDID notifiers, which is > > > > > > > > > > > used to convey > > > > > > > > > > > information from HDMI drivers to their CEC and audio > > > > > > > > > > > counterparts. > > > > > > > > > > > > > > > > > > > > > > Based on an earlier version from Russell King: > > > > > > > > > > > > > > > > > > > > > > https://patchwork.kernel.org/patch/9277043/ > > > > > > > > > > > > > > > > > > > > > > The hdmi_notifier is a reference counted object > > > > > > > > > > > containing the HDMI state > > > > > > > > > > > of an HDMI device. > > > > > > > > > > > > > > > > > > > > > > When a new notifier is registered the current state will > > > > > > > > > > > be reported to > > > > > > > > > > > that notifier at registration time. > > > > > > > > > > > > > > > > > > > > > > Based on Hans Verkuil's patch: > > > > > > > > > > > > > > > > > > > > > > https://patchwork.kernel.org/patch/9472521/ > > > > > > > > > > > > > > > > > > > > Erm, you are aware that this patch morphed into a > > > > > > > > > > CEC-specific notifier > > > > > > > > > > found in drivers/media/cec/cec-notifier.c? > > > > > > > > > > > > > > > > > > > > I don't think it makes sense to have two notifier > > > > > > > > > > implementations in the kernel. > > > > > > > > > > The original intention was to have the notifier deal with > > > > > > > > > > both CEC and ASoC > > > > > > > > > > notifications, but there was not enough interest for the > > > > > > > > > > ASoC bits at the time > > > > > > > > > > and it was dropped. > > > > > > > > > > > > > > > > > > > > I am planning changes to the cec-notifier API, I hope to > > > > > > > > > > work on that this > > > > > > > > > > week. I'll CC you when I post those. Those might be a good > > > > > > > > > > starting point > > > > > > > > > > to convert the cec-notifier to an hdmi-notifier as was > > > > > > > > > > originally intended. > > > > > > > > > > > > > > > > > > > > I've added your colleague Dariusz Marcinkiewicz to the CC > > > > > > > > > > list since he's been > > > > > > > > > > working on some nice cec-notifier improvements as well. > > > > > > > > > > > > > > > > > > We also have some interfaces for drm/alsa interactions around > > > > > > > > > hdmi > > > > > > > > > already in drm/drm_audio_component.h, but it's not used by > > > > > > > > > anything > > > > > > > > > outside of i915. Imo we should extend that, not reinvent a > > > > > > > > > new wheel. > > > > > > > > > > > > > > > > > Hi Daniel, > > > > > > > > Thank you for the pointer. Looking at the ops, it seems that it > > > > > > > > is > > > > > > > > specific to HDA. > > > > > > > > I am not familiar with drm and HDA. I am not sure how > > > > > > > > applicable it > > > > > > > > would be to report jack status to ASoC. > > > > > > > > There is a use case in sound/soc/codecs/hdac_hdmi.c though so it > > > > > > > > should be possible. > > > > > > > > > > > > > > Currently hda is the only user, but the idea was to make it more > > > > > > > generic. > > > > > > > Jack status in alsa is what drm calls connector status btw. > > > > > > > > > > > > > > So if we can take that as a baseline and extend it (probably > > > > > > > needs some > > > > > > > registration boilerplate and helpers to look up the right > > > > > > > endpoint using > > > > > > > of/dt for soc systems, we use component.c in i915/hda for this), > > > > > > > that > > > > > > > would be great I think. > > > > > > > > > > > > > > > > Another note: notifiers considered evil, imo. Gets the job > > > > > > > > > done for one > > > > > > > > > case, as soon as you have multiple devices and need to make > > > > > > > > > sure you get > > > > > > > > > the update for the right one it all comes crashing down. > > > > > > > > > Please create an > > > > > > > > > api which registers for updates from a specific device only, > > > > > > > > > plus > > > > > > > > > something that has real callbacks (like the > > > > > > > > > drm_audio_component.h thing we > > > > > > > > > started already). > > > > > > > > > > > > > > > > To
Re: [PATCH] drm/todo: Update drm_gem_object_funcs todo even more
On Tue, Jun 18, 2019 at 07:25:08PM +0100, Eric Engestrom wrote:
> On Tuesday, 2019-06-18 16:02:41 +0200, Daniel Vetter wrote:
> > I rushed merging this a bit too much, and Noralf pointed out that
> > we're a lot better already and have made great progress.
> >
> > Let's try again.
> >
> > Fixes: 42dbbb4b54a3 ("drm/todo: Add new debugfs todo")
> > Cc: Greg Kroah-Hartman
> > Cc: Daniel Vetter
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Sean Paul
> > Cc: Thomas Zimmermann
> > Cc: Gerd Hoffmann
> > Cc: Rob Herring
> > Cc: Noralf Trønnes
> > Cc: Eric Anholt
> > Cc: Gerd Hoffmann
> > Signed-off-by: Daniel Vetter
> > ---
> > Documentation/gpu/todo.rst | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index 25878dd048fd..66c123737c3d 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -212,9 +212,11 @@ struct drm_gem_object_funcs
> > GEM objects can now have a function table instead of having the callbacks
> > on the
> > DRM driver struct. This is now the preferred way and drivers can be moved
> > over.
> >
> > -Unfortunately some of the recently added GEM helpers are going in the wrong
> > -direction by adding OPS macros that use the old, deprecated hooks. See
> > -DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and
> > DRM_GEM_VRAM_DRIVER_PRIME.
> > +DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS already support
> > this, but
> > +DRM_GEM_VRAM_DRIVER_PRIME does not yet and needs to be aligend with the
> > previous
>
> s/aligend/aligned/
Fixed while applying.
-Daniel
>
> > +two. We also need a 2nd version of the CMA define that doesn't require the
> > +vmapping to be present (different hook for prime importing). Plus this
> > needs to
> > +be rolled out to all drivers using their own implementations, too.
> >
> > Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
> > -
> > --
> > 2.20.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/prime: Update docs
Yes this is a bit a big patch, but since it's essentially a complete rewrite of all the prime docs I didn't see how to better split it up. Changes: - Consistently point to drm_gem_object_funcs as the preferred hooks, where applicable. - Document all the hooks in _driver that lacked kerneldoc. - Completely new overview section, which now also includes the cleaned up lifetime/reference counting subchapter. I also mentioned the weak references in there due to the lookup caches. - Completely rewritten helper intro section, highlight the import/export related functionality. - Polish for all the functions and more cross references. I also sprinkled a bunch of todos all over. Most important: 0 code changes in here. The cleanup motivated by reading and improving all this will follow later on. v2: Actually update the prime helper docs. Plus add a few FIXMEs that I won't address right away in subsequent cleanup patches. v3: - Split out the function moving. This patch is now exclusively documentation changes. - Typos and nits (Sam). v4: Polish suggestions from Noralf. Acked-by: Gerd Hoffmann Acked-by: Emil Velikov Acked-by: Noralf Trønnes Cc: Thomas Zimmermann Cc: Gerd Hoffmann Cc: Noralf Trønnes Cc: Sam Ravnborg Cc: Eric Anholt Cc: Emil Velikov Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-mm.rst | 40 +-- drivers/gpu/drm/drm_prime.c | 201 +-- include/drm/drm_drv.h| 104 +++--- include/drm/drm_gem.h| 18 ++-- 4 files changed, 229 insertions(+), 134 deletions(-) diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index c8ebd4f66a6a..b664f054c259 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -433,43 +433,11 @@ PRIME is the cross device buffer sharing framework in drm, originally created for the OPTIMUS range of multi-gpu platforms. To userspace PRIME buffers are dma-buf based file descriptors. -Overview and Driver Interface -- +Overview and Lifetime Rules +--- -Similar to GEM global names, PRIME file descriptors are also used to -share buffer objects across processes. They offer additional security: -as file descriptors must be explicitly sent over UNIX domain sockets to -be shared between applications, they can't be guessed like the globally -unique GEM names. - -Drivers that support the PRIME API must set the DRIVER_PRIME bit in the -struct :c:type:`struct drm_driver ` -driver_features field, and implement the prime_handle_to_fd and -prime_fd_to_handle operations. - -int (\*prime_handle_to_fd)(struct drm_device \*dev, struct drm_file -\*file_priv, uint32_t handle, uint32_t flags, int \*prime_fd); int -(\*prime_fd_to_handle)(struct drm_device \*dev, struct drm_file -\*file_priv, int prime_fd, uint32_t \*handle); Those two operations -convert a handle to a PRIME file descriptor and vice versa. Drivers must -use the kernel dma-buf buffer sharing framework to manage the PRIME file -descriptors. Similar to the mode setting API PRIME is agnostic to the -underlying buffer object manager, as long as handles are 32bit unsigned -integers. - -While non-GEM drivers must implement the operations themselves, GEM -drivers must use the :c:func:`drm_gem_prime_handle_to_fd()` and -:c:func:`drm_gem_prime_fd_to_handle()` helper functions. Those -helpers rely on the driver gem_prime_export and gem_prime_import -operations to create a dma-buf instance from a GEM object (dma-buf -exporter role) and to create a GEM object from a dma-buf instance -(dma-buf importer role). - -struct dma_buf \* (\*gem_prime_export)(struct drm_device \*dev, -struct drm_gem_object \*obj, int flags); struct drm_gem_object \* -(\*gem_prime_import)(struct drm_device \*dev, struct dma_buf -\*dma_buf); These two operations are mandatory for GEM drivers that -support PRIME. +.. kernel-doc:: drivers/gpu/drm/drm_prime.c + :doc: overview and lifetime rules PRIME Helper Functions -- diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 68b4de85370c..c269bc03c42a 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -38,47 +38,53 @@ #include "drm_internal.h" -/* - * DMA-BUF/GEM Object references and lifetime overview: - * - * On the export the dma_buf holds a reference to the exporting GEM - * object. It takes this reference in handle_to_fd_ioctl, when it - * first calls .prime_export and stores the exporting GEM object in - * the dma_buf priv. This reference needs to be released when the - * final reference to the _buf itself is dropped and its - * _buf_ops.release function is called. For GEM-based drivers, - * the dma_buf should be exported using drm_gem_dmabuf_export() and - * then released by drm_gem_dmabuf_release(). - * - * On the import the importing GEM object holds a reference to the - * dma_buf (which in turn holds a ref to the exporting GEM object). - * It takes
Re: [PATCH 2/2] drm/prime: Update docs
On Wed, Jun 19, 2019 at 02:43:20PM +0200, Noralf Trønnes wrote:
>
>
> Den 18.06.2019 11.20, skrev Daniel Vetter:
> > Yes this is a bit a big patch, but since it's essentially a complete
> > rewrite of all the prime docs I didn't see how to better split it up.
> >
> > Changes:
> > - Consistently point to drm_gem_object_funcs as the preferred hooks,
> > where applicable.
> >
> > - Document all the hooks in _driver that lacked kerneldoc.
> >
> > - Completely new overview section, which now also includes the cleaned
> > up lifetime/reference counting subchapter. I also mentioned the weak
> > references in there due to the lookup caches.
> >
> > - Completely rewritten helper intro section, highlight the
> > import/export related functionality.
> >
> > - Polish for all the functions and more cross references.
> >
> > I also sprinkled a bunch of todos all over.
> >
> > Most important: 0 code changes in here. The cleanup motivated by
> > reading and improving all this will follow later on.
> >
> > v2: Actually update the prime helper docs. Plus add a few FIXMEs that
> > I won't address right away in subsequent cleanup patches.
> >
> > v3:
> > - Split out the function moving. This patch is now exclusively
> > documentation changes.
> > - Typos and nits (Sam).
> >
> > Cc: Sam Ravnborg
> > Cc: Eric Anholt
> > Cc: Emil Velikov
> > Signed-off-by: Daniel Vetter
> > ---
> > Documentation/gpu/drm-mm.rst | 40 +--
> > drivers/gpu/drm/drm_prime.c | 197 +--
> > include/drm/drm_drv.h| 104 +++---
> > include/drm/drm_gem.h| 18 ++--
> > 4 files changed, 226 insertions(+), 133 deletions(-)
> >
>
>
>
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 68b4de85370c..2234206288fa 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -38,47 +38,53 @@
> >
> > #include "drm_internal.h"
> >
> > -/*
> > - * DMA-BUF/GEM Object references and lifetime overview:
> > - *
> > - * On the export the dma_buf holds a reference to the exporting GEM
> > - * object. It takes this reference in handle_to_fd_ioctl, when it
> > - * first calls .prime_export and stores the exporting GEM object in
> > - * the dma_buf priv. This reference needs to be released when the
> > - * final reference to the _buf itself is dropped and its
> > - * _buf_ops.release function is called. For GEM-based drivers,
> > - * the dma_buf should be exported using drm_gem_dmabuf_export() and
> > - * then released by drm_gem_dmabuf_release().
> > - *
> > - * On the import the importing GEM object holds a reference to the
> > - * dma_buf (which in turn holds a ref to the exporting GEM object).
> > - * It takes that reference in the fd_to_handle ioctl.
> > - * It calls dma_buf_get, creates an attachment to it and stores the
> > - * attachment in the GEM object. When this attachment is destroyed
> > - * when the imported object is destroyed, we remove the attachment
> > - * and drop the reference to the dma_buf.
> > - *
> > - * When all the references to the _buf are dropped, i.e. when
> > - * userspace has closed both handles to the imported GEM object (through
> > the
> > - * FD_TO_HANDLE IOCTL) and closed the file descriptor of the exported
> > - * (through the HANDLE_TO_FD IOCTL) dma_buf, and all kernel-internal
> > references
> > - * are also gone, then the dma_buf gets destroyed. This can also happen
> > as a
> > - * part of the clean up procedure in the drm_release() function if
> > userspace
> > - * fails to properly clean up. Note that both the kernel and userspace (by
> > - * keeeping the PRIME file descriptors open) can hold references onto a
> > - * _buf.
> > - *
> > - * Thus the chain of references always flows in one direction
> > - * (avoiding loops): importing_gem -> dmabuf -> exporting_gem
> > - *
> > - * Self-importing: if userspace is using PRIME as a replacement for flink
> > - * then it will get a fd->handle request for a GEM object that it created.
> > - * Drivers should detect this situation and return back the gem object
> > - * from the dma-buf private. Prime will do this automatically for drivers
> > that
> > - * use the drm_gem_prime_{import,export} helpers.
> > - *
> > - * GEM struct _buf_ops symbols are now exported. They can be resued by
> > - * drivers which implement GEM interface.
> > +/**
> > + * DOC: overview and lifetime rules
> > + *
> > + * Similar to GEM global names, PRIME file descriptors are also used to
> > share
> > + * buffer objects across processes. They offer additional security: as file
> > + * descriptors must be explicitly sent over UNIX domain sockets to be
> > shared
> > + * between applications, they can't be guessed like the globally unique GEM
> > + * names.
> > + *
> > + * Drivers that support the PRIME API must set the DRIVER_PRIME bit in the
> > + * _driver.driver_features field, and implement the
> > + * _driver.prime_handle_to_fd and
Re: [PATCH] drm/imx: correct order of crtc disable
On Thu, Jun 20, 2019 at 12:12:13PM +0100, Robert Beckett wrote:
> On Thu, 2019-06-20 at 10:50 +0200, Daniel Vetter wrote:
> > On Wed, Jun 19, 2019 at 11:40 AM Philipp Zabel <
> > p.za...@pengutronix.de> wrote:
> > >
> > > Hi Robert,
> > >
> > > thank you for the patch.
> > >
> > > On Tue, 2019-06-18 at 16:50 +0100, Robert Beckett wrote:
> > > > Notify drm core before sending pending events during crtc
> > > > disable.
> > > > This fixes the first event after disable having an old stale
> > > > timestamp
> > > > by having drm_crtc_vblank_off update the timestamp to now.
> > > >
> > > > This was seen while debugging weston log message:
> > > > Warning: computed repaint delay is insane: -8212 msec
> > > >
> > >
> > > Would you say this
> > > Fixes: a474478642d5 ("drm/imx: fix crtc vblank state regression")
> > > ?
> > >
> > > > Signed-off-by: Robert Beckett
> > > > ---
> > > > drivers/gpu/drm/imx/ipuv3-crtc.c | 6 +++---
> > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > index 9cc1d678674f..c436a28d50e4 100644
> > > > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > @@ -91,14 +91,14 @@ static void ipu_crtc_atomic_disable(struct
> > > > drm_crtc *crtc,
> > > > ipu_dc_disable(ipu);
> > > > ipu_prg_disable(ipu);
> > > >
> > > > + drm_crtc_vblank_off(crtc);
> > > > +
> > >
> > > This is explained in the commit message and aligns with the
> > > drm_crtc_state @event documentation.
> >
> > This part here looks fishy. The drm_vblank.c code is supposed to do
> > the right thing, no matter where or when you ask it to generate an
> > event. It definitely shouldn't generate a timestamp that's a few
> > seconds too early. Bunch of options:
> > - there's a bug in drm_vblank.c and it's mixing up something and
> > generating a totally bogus value.
> > - there's a lie in your imx vblank code, which trips the drm_vblank.c
> > counter interpolation and results in a totally bogus value.
> >
> > drm_vblank.c assumes that if you do claim to have a hw counter and
> > generate timestamps, that those are perfectly accurate. It only falls
> > back to guestimating using the system timer if that's not present.
> >
> > Either way, this very much smells like papering over a bug if this
> > change indeed fixes your wrong vblank timestamps.
> >
>
> A quick explaination of where the dodgy timestamp came from:
> 1. driver starts up
> 2. fbcon comes along and restores fbdev, enabling vblank
> 3. vblank_disable_fn fires via timer disabling vblank, keeping vblank
> seq number and time set at current value
> (some time later)
> 4. weston starts and does a modeset
> 5. atomic commit disables crtc while it does the modeset
> 6. ipu_crtc_atomic_disable sends vblank with old seq number and time
>
> It turns out the actual fix for the old vblank is the next change,
> which stops it being sent at all during the crtc disable as it is is
> still active, it would then go through drm_crtc_vblank_off, reseting
> the timestamp, and get delivered during the vblank enable as part of
> the atomic commit.
This shouldn't fix your vblank timestamp troubles either. It might mean
that the timestamp is slightly too early (because you take it while
shutting down the crtc, not while re-enabling), but not by seconds.
Quick experiment: Disable vblank disabling with drm.vblankoffdelay = 0. If
that also fixes the timestamps, then I'm pretty sure you have a driver bug
somewhere and lie to the vblank core code about something.
-Daniel
>
> So, in theory, we could just have the following change to fix the
> specific issue of a stale timestamp.
>
> However, given the documentation for the event in
> include/drm/drm_crtc.h:
>
> * - The event is for a CRTC which is being disabled through
> this
> *atomic commit. In that case the event can be send out any
> time
> *after the hardware has stopped scanning out the current
> *framebuffers. It should contain the timestamp and counter
> for the
> *last vblank before the display pipeline was shut off. The
> simplest
> *way to achieve that is calling
> drm_crtc_send_vblank_event()
> *somewhen after drm_crtc_vblank_off() has been called.
>
> This still seems like a sensible change for when the crtc is being
> disabled.
>
>
>
> > > > spin_lock_irq(>dev->event_lock);
> > > > - if (crtc->state->event)
> > > > {
> > > > + if (crtc->state->event && !crtc->state->active) {
> > >
> > > This is not mentioned though.
> > >
> > > If the pending event is not sent here, I assume it will be picked
> > > up by
> > > .atomic_flush and will then be sent after the first EOF interrupt
> > > after
> > > the modeset is complete. Can you explain this in the commit
> > > message?
> >
> > Yeah looks correct (you only want to generate the event here when
[Bug 110949] Continuious warnings from agd5f 5.3-wip branch
https://bugs.freedesktop.org/show_bug.cgi?id=110949 --- Comment #3 from Nicholas Kazlauskas --- Seems like there's still issues with dropping the check depending on the ASIC revision and probably userspace that's being used. I can revert this for now while investigating the issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel - drm-intel-fixes-2019-06-20: drm/i915 fixes for v5.2-rc6: - GVT: Fix reserved PVINFO register write (Weinan) - Avoid clobbering M/N values in fastset fuzzy checks (Ville) BR, Jani. The following changes since commit 9e0babf2c06c73cda2c0cd37a1653d823adb40ec: Linux 5.2-rc5 (2019-06-16 08:49:45 -1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-06-20 for you to fetch changes up to 475df5d0f3eb2d031e4505f84d8fba75baaf2e80: drm/i915: Don't clobber M/N values during fastset check (2019-06-19 15:57:09 +0300) drm/i915 fixes for v5.2-rc6: - GVT: Fix reserved PVINFO register write (Weinan) - Avoid clobbering M/N values in fastset fuzzy checks (Ville) Jani Nikula (1): Merge tag 'gvt-fixes-2019-06-19' of https://github.com/intel/gvt-linux into drm-intel-fixes Ville Syrjälä (1): drm/i915: Don't clobber M/N values during fastset check Weinan Li (1): drm/i915/gvt: ignore unexpected pvinfo write drivers/gpu/drm/i915/gvt/handlers.c | 15 -- drivers/gpu/drm/i915/intel_display.c | 38 +++- 2 files changed, 38 insertions(+), 15 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: correct order of crtc disable
Hi Robert, Daniel,
On Thu, 2019-06-20 at 12:12 +0100, Robert Beckett wrote:
> On Thu, 2019-06-20 at 10:50 +0200, Daniel Vetter wrote:
> > On Wed, Jun 19, 2019 at 11:40 AM Philipp Zabel <
> > p.za...@pengutronix.de> wrote:
> > >
> > > Hi Robert,
> > >
> > > thank you for the patch.
> > >
> > > On Tue, 2019-06-18 at 16:50 +0100, Robert Beckett wrote:
> > > > Notify drm core before sending pending events during crtc
> > > > disable.
> > > > This fixes the first event after disable having an old stale
> > > > timestamp
> > > > by having drm_crtc_vblank_off update the timestamp to now.
> > > >
> > > > This was seen while debugging weston log message:
> > > > Warning: computed repaint delay is insane: -8212 msec
> > > >
> > >
> > > Would you say this
> > > Fixes: a474478642d5 ("drm/imx: fix crtc vblank state regression")
> > > ?
> > >
> > > > Signed-off-by: Robert Beckett
> > > > ---
> > > > drivers/gpu/drm/imx/ipuv3-crtc.c | 6 +++---
> > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > index 9cc1d678674f..c436a28d50e4 100644
> > > > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > @@ -91,14 +91,14 @@ static void ipu_crtc_atomic_disable(struct
> > > > drm_crtc *crtc,
> > > > ipu_dc_disable(ipu);
> > > > ipu_prg_disable(ipu);
> > > >
> > > > + drm_crtc_vblank_off(crtc);
> > > > +
> > >
> > > This is explained in the commit message and aligns with the
> > > drm_crtc_state @event documentation.
> >
> > This part here looks fishy. The drm_vblank.c code is supposed to do
> > the right thing, no matter where or when you ask it to generate an
> > event. It definitely shouldn't generate a timestamp that's a few
> > seconds too early. Bunch of options:
> > - there's a bug in drm_vblank.c and it's mixing up something and
> > generating a totally bogus value.
> > - there's a lie in your imx vblank code, which trips the drm_vblank.c
> > counter interpolation and results in a totally bogus value.
> >
> > drm_vblank.c assumes that if you do claim to have a hw counter and
> > generate timestamps, that those are perfectly accurate. It only falls
> > back to guestimating using the system timer if that's not present.
> >
> > Either way, this very much smells like papering over a bug if this
> > change indeed fixes your wrong vblank timestamps.
Thank you for chiming in, I can confirm that just moving the
drm_crtc_vblank_off around does not change anything.
I'll drop this patch and wait for v3.
> A quick explaination of where the dodgy timestamp came from:
> 1. driver starts up
> 2. fbcon comes along and restores fbdev, enabling vblank
> 3. vblank_disable_fn fires via timer disabling vblank, keeping vblank
> seq number and time set at current value
> (some time later)
> 4. weston starts and does a modeset
> 5. atomic commit disables crtc while it does the modeset
> 6. ipu_crtc_atomic_disable sends vblank with old seq number and time
It would be great to have this in the commit message for context.
> It turns out the actual fix for the old vblank is the next change,
> which stops it being sent at all during the crtc disable as it is is
> still active, it would then go through drm_crtc_vblank_off, reseting
> the timestamp, and get delivered during the vblank enable as part of
> the atomic commit.
Which means this patch isn't "Fixes: a474478642d5" after all.
The offending code has been there since commit 5f2f911578fb ("drm/imx:
atomic phase 3 step 1: Use atomic configuration").
> So, in theory, we could just have the following change to fix the
> specific issue of a stale timestamp.
>
> However, given the documentation for the event in
> include/drm/drm_crtc.h:
>
> * - The event is for a CRTC which is being disabled through this
> *atomic commit. In that case the event can be send out any time
> *after the hardware has stopped scanning out the current
> *framebuffers. It should contain the timestamp and counter for
> the
> *last vblank before the display pipeline was shut off. The
> simplest
> *way to achieve that is calling drm_crtc_send_vblank_event()
> *somewhen after drm_crtc_vblank_off() has been called.
>
> This still seems like a sensible change for when the crtc is being
> disabled.
This is what had me confused as well. It doesn't really say, but it
seems to imply that drm_crtc_send_vblank_event must only be sent after
drm_crtc_vblank_off.
If this is not a hard requirement, maybe this could be mentioned here?
> > > > spin_lock_irq(>dev->event_lock);
> > > > - if (crtc->state->event)
> > > > {
> > > > + if (crtc->state->event && !crtc->state->active) {
> > >
> > > This is not mentioned though.
> > >
> > > If the pending event is not sent here, I assume it will be picked
> > > up by
> > > .atomic_flush and will then be
Re: [PATCH] drm/self_refresh: Fix possible NULL deref in failure path
On Wed, Jun 19, 2019 at 02:19:47PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> If state allocation fails, we still try to give back the reference on
> it. Also initialize ret in case the crtc is not enabled and we hit the
> eject button.
>
> Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in
> drivers")
> Cc: Daniel Vetter
> Cc: Jose Souza
> Cc: Zain Wang
> Cc: Tomasz Figa
> Cc: Ville Syrjälä
> Cc: Sam Ravnborg
> Cc: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> Reported-by: Dan Carpenter
> Signed-off-by: Sean Paul
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_self_refresh_helper.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c
> b/drivers/gpu/drm/drm_self_refresh_helper.c
> index e0d2ad1f070cb..4b9424a8f1f1c 100644
> --- a/drivers/gpu/drm/drm_self_refresh_helper.c
> +++ b/drivers/gpu/drm/drm_self_refresh_helper.c
> @@ -69,14 +69,14 @@ static void drm_self_refresh_helper_entry_work(struct
> work_struct *work)
> struct drm_connector *conn;
> struct drm_connector_state *conn_state;
> struct drm_crtc_state *crtc_state;
> - int i, ret;
> + int i, ret = 0;
>
> drm_modeset_acquire_init(, 0);
>
> state = drm_atomic_state_alloc(dev);
> if (!state) {
> ret = -ENOMEM;
> - goto out;
> + goto out_drop_locks;
> }
>
> retry:
> @@ -116,6 +116,8 @@ static void drm_self_refresh_helper_entry_work(struct
> work_struct *work)
> }
>
> drm_atomic_state_put(state);
> +
> +out_drop_locks:
> drm_modeset_drop_locks();
> drm_modeset_acquire_fini();
> }
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: correct order of crtc disable
On Thu, 2019-06-20 at 10:50 +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 11:40 AM Philipp Zabel <
> p.za...@pengutronix.de> wrote:
> >
> > Hi Robert,
> >
> > thank you for the patch.
> >
> > On Tue, 2019-06-18 at 16:50 +0100, Robert Beckett wrote:
> > > Notify drm core before sending pending events during crtc
> > > disable.
> > > This fixes the first event after disable having an old stale
> > > timestamp
> > > by having drm_crtc_vblank_off update the timestamp to now.
> > >
> > > This was seen while debugging weston log message:
> > > Warning: computed repaint delay is insane: -8212 msec
> > >
> >
> > Would you say this
> > Fixes: a474478642d5 ("drm/imx: fix crtc vblank state regression")
> > ?
> >
> > > Signed-off-by: Robert Beckett
> > > ---
> > > drivers/gpu/drm/imx/ipuv3-crtc.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > index 9cc1d678674f..c436a28d50e4 100644
> > > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > @@ -91,14 +91,14 @@ static void ipu_crtc_atomic_disable(struct
> > > drm_crtc *crtc,
> > > ipu_dc_disable(ipu);
> > > ipu_prg_disable(ipu);
> > >
> > > + drm_crtc_vblank_off(crtc);
> > > +
> >
> > This is explained in the commit message and aligns with the
> > drm_crtc_state @event documentation.
>
> This part here looks fishy. The drm_vblank.c code is supposed to do
> the right thing, no matter where or when you ask it to generate an
> event. It definitely shouldn't generate a timestamp that's a few
> seconds too early. Bunch of options:
> - there's a bug in drm_vblank.c and it's mixing up something and
> generating a totally bogus value.
> - there's a lie in your imx vblank code, which trips the drm_vblank.c
> counter interpolation and results in a totally bogus value.
>
> drm_vblank.c assumes that if you do claim to have a hw counter and
> generate timestamps, that those are perfectly accurate. It only falls
> back to guestimating using the system timer if that's not present.
>
> Either way, this very much smells like papering over a bug if this
> change indeed fixes your wrong vblank timestamps.
>
A quick explaination of where the dodgy timestamp came from:
1. driver starts up
2. fbcon comes along and restores fbdev, enabling vblank
3. vblank_disable_fn fires via timer disabling vblank, keeping vblank
seq number and time set at current value
(some time later)
4. weston starts and does a modeset
5. atomic commit disables crtc while it does the modeset
6. ipu_crtc_atomic_disable sends vblank with old seq number and time
It turns out the actual fix for the old vblank is the next change,
which stops it being sent at all during the crtc disable as it is is
still active, it would then go through drm_crtc_vblank_off, reseting
the timestamp, and get delivered during the vblank enable as part of
the atomic commit.
So, in theory, we could just have the following change to fix the
specific issue of a stale timestamp.
However, given the documentation for the event in
include/drm/drm_crtc.h:
* - The event is for a CRTC which is being disabled through
this
*atomic commit. In that case the event can be send out any
time
*after the hardware has stopped scanning out the current
*framebuffers. It should contain the timestamp and counter
for the
*last vblank before the display pipeline was shut off. The
simplest
*way to achieve that is calling
drm_crtc_send_vblank_event()
*somewhen after drm_crtc_vblank_off() has been called.
This still seems like a sensible change for when the crtc is being
disabled.
> > > spin_lock_irq(>dev->event_lock);
> > > - if (crtc->state->event)
> > > {
> > > + if (crtc->state->event && !crtc->state->active) {
> >
> > This is not mentioned though.
> >
> > If the pending event is not sent here, I assume it will be picked
> > up by
> > .atomic_flush and will then be sent after the first EOF interrupt
> > after
> > the modeset is complete. Can you explain this in the commit
> > message?
>
> Yeah looks correct (you only want to generate the event here when the
> crtc stays off), if it gets re-enabled the event should only be
> generated later on once that's all finished. But separate bugfix.
> -Daniel
>
It looks like this is actually the fix needed to avoid the bogus
timestamp.
I can split this patch up in to 2 commits if desired?
> >
> > With that,
> > Reviewed-by: Philipp Zabel
> >
> > > drm_crtc_send_vblank_event(crtc, crtc->state-
> > > >event);
> > > crtc->state->event = NULL;
> > > }
> > > spin_unlock_irq(>dev->event_lock);
> > > -
> > > - drm_crtc_vblank_off(crtc);
> > > }
> > >
> > > static void imx_drm_crtc_reset(struct drm_crtc *crtc)
> >
> > regards
> > Philipp
> >
Re: use exact allocation for dma coherent memory
On Wed, Jun 19, 2019 at 01:29:03PM -0300, Jason Gunthorpe wrote: > > Yes. This will blow up badly on many platforms, as sq->queue > > might be vmapped, ioremapped, come from a pool without page backing. > > Gah, this addr gets fed into io_remap_pfn_range/remap_pfn_range too.. > > Potnuri, you should fix this.. > > You probably need to use dma_mmap_from_dev_coherent() in the mmap ? The function to use is dma_mmap_coherent, dma_mmap_from_dev_coherent is just an internal helper. That beiŋ said the drivers/infiniband code has a lot of *remap_pfn_range, and a lot of them look like they might be for DMA memory.
[Bug 110635] briefly flashing corruption when playing various OGL games
https://bugs.freedesktop.org/show_bug.cgi?id=110635 --- Comment #9 from tempel.jul...@gmail.com --- *bump* Situation unchanged with recent llvm-git and mesa-git. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/7] Hexdump Enhancements
On Wed, 19 Jun 2019, Joe Perches wrote:
> On Thu, 2019-06-20 at 11:14 +1000, Alastair D'Silva wrote:
>> On Wed, 2019-06-19 at 17:35 -0700, Joe Perches wrote:
>> > On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
>> > > On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
>> > > > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
>> > > > > From: Alastair D'Silva
>> > > > >
>> > > > > Apologies for the large CC list, it's a heads up for those
>> > > > > responsible
>> > > > > for subsystems where a prototype change in generic code causes
>> > > > > a
>> > > > > change
>> > > > > in those subsystems.
>> > > > >
>> > > > > This series enhances hexdump.
>> > > >
>> > > > Still not a fan of these patches.
>> > >
>> > > I'm afraid there's not too much action I can take on that, I'm
>> > > happy to
>> > > address specific issues though.
>> > >
>> > > > > These improve the readability of the dumped data in certain
>> > > > > situations
>> > > > > (eg. wide terminals are available, many lines of empty bytes
>> > > > > exist,
>> > > > > etc).
>> >
>> > I think it's generally overkill for the desired uses.
>>
>> I understand where you're coming from, however, these patches make it a
>> lot easier to work with large chucks of binary data. I think it makes
>> more sense to have these patches upstream, even though committed code
>> may not necessarily have all the features enabled, as it means that
>> devs won't have to apply out-of-tree patches during development to make
>> larger dumps manageable.
>>
>> > > > Changing hexdump's last argument from bool to int is odd.
>> > > >
>> > >
>> > > Think of it as replacing a single boolean with many booleans.
>> >
>> > I understand it. It's odd.
>> >
>> > I would rather not have a mixture of true, false, and apparently
>> > random collections of bitfields like 0xd or 0b1011 or their
>> > equivalent or'd defines.
>> >
>>
>> Where's the mixture? What would you propose instead?
>
> create a hex_dump_to_buffer_ext with a new argument
> and a new static inline for the old hex_dump_to_buffer
> without modifying the argument list that calls
> hex_dump_to_buffer with whatever added argument content
> you need.
>
> Something like:
>
> static inline
> int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
> int groupsize, char *linebuf, size_t linebuflen,
> bool ascii)
> {
> return hex_dump_to_buffer_ext(buf, len, rowsize, groupsize,
> linebuf, linebuflen, ascii, 0);
> }
>
> and remove EXPORT_SYMBOL(hex_dump_to_buffer)
If you decide to do something like this, I'd actually suggest you drop
the bool ascii parameter from hex_dump_to_buffer() altogether, and
replace the callers that do require ascii with
hex_dump_to_buffer_ext(..., HEXDUMP_ASCII). Even if that also requires
touching all callers.
But no strong opinions, really.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #23 from tempel.jul...@gmail.com --- Any news on this? I'd really like to have this sorted out before I wholeheartedly recommended Navi for Linux gaming. I can imagine that Navi causes a ton of work, but still this issue is painful. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] mali-dp and komeda patches for drm-next
Hi DRM maintainers, Picking up pace on the upstreaming of Komeda driver, with quite a lot of new features added this time. On top of that we have the small cleanups and improved usage of the debugfs functions. Please pull! Best regards, Liviu The following changes since commit 52d2d44eee8091e740d0d275df1311fb8373c9a9: Merge v5.2-rc5 into drm-next (2019-06-19 12:07:29 +0200) are available in the Git repository at: git://linux-arm.org/linux-ld.git for-upstream/mali-dp for you to fetch changes up to 344f00e4d7d6538c1862505b25b662b47c9e0bb0: drm/komeda: Make Komeda interrupts shareable (2019-06-19 17:04:21 +0100) Arnd Bergmann (1): drm/komeda: fix 32-bit komeda_crtc_update_clock_ratio Ayan Halder (1): drm/komeda: Make Komeda interrupts shareable Greg Kroah-Hartman (2): komeda: no need to check return value of debugfs_create functions malidp: no need to check return value of debugfs_create functions Liviu Dudau (1): arm/komeda: Convert dp_wait_cond() to return an error code. Lowry Li (Arm Technology China) (10): drm/komeda: Creates plane alpha and blend mode properties drm/komeda: Clear enable bit in CU_INPUTx_CONTROL drm/komeda: Add rotation support on Komeda driver drm/komeda: Adds limitation check for AFBC wide block not support Rot90 drm/komeda: Update HW up-sampling on D71 drm/komeda: Enable color-encoding (YUV format) support drm/komeda: Adds SMMU support dt/bindings: drm/komeda: Adds SMMU support for D71 devicetree drm/komeda: Adds zorder support drm/komeda: Add slave pipeline support james qian wang (Arm Technology China) (21): drm/komeda: Add writeback support drm/komeda: Added AFBC support for komeda driver drm/komeda: Attach scaler to drm as private object drm/komeda: Add the initial scaler support for CORE drm/komeda: Implement D71 scaler support drm/komeda: Add writeback scaling support drm/komeda: Add engine clock requirement check for the downscaling drm/komeda: Add image enhancement support drm/komeda: Add komeda_fb_check_src_coords drm/komeda: Add format support for Y0L2, P010, YUV420_8/10BIT drm/komeda: Unify mclk/pclk/pipeline->aclk to one MCLK drm/komeda: Rename main engine clk name "mclk" to "aclk" dt/bindings: drm/komeda: Unify mclk/pclk/pipeline->aclk to one ACLK drm/komeda: Add component komeda_merger drm/komeda: Add split support for scaler drm/komeda: Add layer split support drm/komeda: Refine function to_d71_input_id drm/komeda: Accept null writeback configurations for writeback drm/komeda: Add new component komeda_splitter drm/komeda: Enable writeback split support drm/komeda: Correct printk format specifier for "size_t" .../devicetree/bindings/display/arm,komeda.txt | 23 +- drivers/gpu/drm/arm/display/include/malidp_io.h| 7 + drivers/gpu/drm/arm/display/include/malidp_utils.h | 5 +- drivers/gpu/drm/arm/display/komeda/Makefile| 2 + .../gpu/drm/arm/display/komeda/d71/d71_component.c | 582 +- drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 142 +++-- drivers/gpu/drm/arm/display/komeda/d71/d71_dev.h | 2 + .../gpu/drm/arm/display/komeda/komeda_color_mgmt.c | 67 ++ .../gpu/drm/arm/display/komeda/komeda_color_mgmt.h | 17 + drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 154 - drivers/gpu/drm/arm/display/komeda/komeda_dev.c| 59 +- drivers/gpu/drm/arm/display/komeda/komeda_dev.h| 13 +- .../drm/arm/display/komeda/komeda_format_caps.c| 58 ++ .../drm/arm/display/komeda/komeda_format_caps.h| 24 +- .../drm/arm/display/komeda/komeda_framebuffer.c| 175 +- .../drm/arm/display/komeda/komeda_framebuffer.h| 13 +- drivers/gpu/drm/arm/display/komeda/komeda_kms.c| 130 +++- drivers/gpu/drm/arm/display/komeda/komeda_kms.h| 71 ++- .../gpu/drm/arm/display/komeda/komeda_pipeline.c | 66 +- .../gpu/drm/arm/display/komeda/komeda_pipeline.h | 111 +++- .../drm/arm/display/komeda/komeda_pipeline_state.c | 679 - drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 191 +- .../drm/arm/display/komeda/komeda_private_obj.c| 154 + .../drm/arm/display/komeda/komeda_wb_connector.c | 199 ++ drivers/gpu/drm/arm/malidp_drv.c | 11 +- 25 files changed, 2728 insertions(+), 227 deletions(-) create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list
Re: [PATCH 1/7] video: add HDMI state notifier support
On Wed, Jun 19, 2019 at 07:48:11PM +0800, Cheng-yi Chiang wrote: > On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter wrote: > > > > On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote: > > > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter wrote: > > > > > > > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote: > > > > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter wrote: > > > > > > > > > > > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote: > > > > > > > On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter > > > > > > > wrote: > > > > > > > > > > > > > > > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote: > > > > > > > > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote: > > > > > > > > > > From: Hans Verkuil > > > > > > > > > > > > > > > > > > > > Add support for HDMI hotplug and EDID notifiers, which is > > > > > > > > > > used to convey > > > > > > > > > > information from HDMI drivers to their CEC and audio > > > > > > > > > > counterparts. > > > > > > > > > > > > > > > > > > > > Based on an earlier version from Russell King: > > > > > > > > > > > > > > > > > > > > https://patchwork.kernel.org/patch/9277043/ > > > > > > > > > > > > > > > > > > > > The hdmi_notifier is a reference counted object containing > > > > > > > > > > the HDMI state > > > > > > > > > > of an HDMI device. > > > > > > > > > > > > > > > > > > > > When a new notifier is registered the current state will be > > > > > > > > > > reported to > > > > > > > > > > that notifier at registration time. > > > > > > > > > > > > > > > > > > > > Based on Hans Verkuil's patch: > > > > > > > > > > > > > > > > > > > > https://patchwork.kernel.org/patch/9472521/ > > > > > > > > > > > > > > > > > > Erm, you are aware that this patch morphed into a > > > > > > > > > CEC-specific notifier > > > > > > > > > found in drivers/media/cec/cec-notifier.c? > > > > > > > > > > > > > > > > > > I don't think it makes sense to have two notifier > > > > > > > > > implementations in the kernel. > > > > > > > > > The original intention was to have the notifier deal with > > > > > > > > > both CEC and ASoC > > > > > > > > > notifications, but there was not enough interest for the ASoC > > > > > > > > > bits at the time > > > > > > > > > and it was dropped. > > > > > > > > > > > > > > > > > > I am planning changes to the cec-notifier API, I hope to work > > > > > > > > > on that this > > > > > > > > > week. I'll CC you when I post those. Those might be a good > > > > > > > > > starting point > > > > > > > > > to convert the cec-notifier to an hdmi-notifier as was > > > > > > > > > originally intended. > > > > > > > > > > > > > > > > > > I've added your colleague Dariusz Marcinkiewicz to the CC > > > > > > > > > list since he's been > > > > > > > > > working on some nice cec-notifier improvements as well. > > > > > > > > > > > > > > > > We also have some interfaces for drm/alsa interactions around > > > > > > > > hdmi > > > > > > > > already in drm/drm_audio_component.h, but it's not used by > > > > > > > > anything > > > > > > > > outside of i915. Imo we should extend that, not reinvent a new > > > > > > > > wheel. > > > > > > > > > > > > > > > Hi Daniel, > > > > > > > Thank you for the pointer. Looking at the ops, it seems that it is > > > > > > > specific to HDA. > > > > > > > I am not familiar with drm and HDA. I am not sure how applicable > > > > > > > it > > > > > > > would be to report jack status to ASoC. > > > > > > > There is a use case in sound/soc/codecs/hdac_hdmi.c though so it > > > > > > > should be possible. > > > > > > > > > > > > Currently hda is the only user, but the idea was to make it more > > > > > > generic. > > > > > > Jack status in alsa is what drm calls connector status btw. > > > > > > > > > > > > So if we can take that as a baseline and extend it (probably needs > > > > > > some > > > > > > registration boilerplate and helpers to look up the right endpoint > > > > > > using > > > > > > of/dt for soc systems, we use component.c in i915/hda for this), > > > > > > that > > > > > > would be great I think. > > > > > > > > > > > > > > Another note: notifiers considered evil, imo. Gets the job done > > > > > > > > for one > > > > > > > > case, as soon as you have multiple devices and need to make > > > > > > > > sure you get > > > > > > > > the update for the right one it all comes crashing down. Please > > > > > > > > create an > > > > > > > > api which registers for updates from a specific device only, > > > > > > > > plus > > > > > > > > something that has real callbacks (like the > > > > > > > > drm_audio_component.h thing we > > > > > > > > started already). > > > > > > > > > > > > > > To clarify a bit, this hdmi-notifier indeed supports updating > > > > > > > from a > > > > > > > specific device only. > > > > > > > hdmi_notifier_get takes a device and return the notifier. > > > > > > > > > > > > Hm I missed that, I thought it's global, so one of my usual notifier > > > > >
Re: [RFC PATCH 4/4] dt-bindings: display: Convert innolux,ee101ia-01 panel to DT schema
On Wed, Jun 19, 2019 at 03:51:56PM -0600, Rob Herring wrote: > Convert the innolux,ee101ia-01 LVDS panel binding to DT schema. > > Cc: Thierry Reding > Cc: Sam Ravnborg > Cc: Maxime Ripard > Cc: Laurent Pinchart > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Rob Herring > --- > .../display/panel/innolux,ee101ia-01d.txt | 7 --- > .../display/panel/innolux,ee101ia-01d.yaml| 21 +++ > 2 files changed, 21 insertions(+), 7 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > create mode 100644 > Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [RFC PATCH 3/4] dt-bindings: display: Convert panel-lvds to DT schema
On Wed, Jun 19, 2019 at 03:51:55PM -0600, Rob Herring wrote: > Convert the panel-lvds binding to use DT schema. The panel-lvds schema > inherits from the panel-common.yaml schema and specific LVDS panel > bindings should inherit from this schema. > > Cc: Thierry Reding > Cc: Sam Ravnborg > Cc: Maxime Ripard > Cc: Laurent Pinchart > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Rob Herring > --- > .../bindings/display/panel/panel-lvds.txt | 121 -- > .../bindings/display/panel/panel-lvds.yaml| 107 > 2 files changed, 107 insertions(+), 121 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/panel/panel-lvds.txt > create mode 100644 > Documentation/devicetree/bindings/display/panel/panel-lvds.yaml Similar to my comments on panel-common.yaml, perhaps make this just lvds.yaml? Otherwise: Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [RFC PATCH 2/4] dt-bindings: display: Convert ampire,am-480272h3tmqw-t01h panel to DT schema
On Wed, Jun 19, 2019 at 03:51:54PM -0600, Rob Herring wrote: > Convert the ampire,am-480272h3tmqw-t01h panel binding to DT schema. > > Cc: Thierry Reding > Cc: Sam Ravnborg > Cc: Maxime Ripard > Cc: Laurent Pinchart > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Rob Herring > --- > .../panel/ampire,am-480272h3tmqw-t01h.txt | 26 > .../panel/ampire,am-480272h3tmqw-t01h.yaml| 41 +++ > 2 files changed, 41 insertions(+), 26 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt > create mode 100644 > Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema
On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote: > Convert the common panel bindings to DT schema consolidating scattered > definitions to a single schema file. > > The 'simple-panel' binding just a collection of properties and not a > complete binding itself. All of the 'simple-panel' properties are > covered by the panel-common.txt binding with the exception of the > 'no-hpd' property, so add that to the schema. > > As there are lots of references to simple-panel.txt, just keep the file > with a reference to panel-common.yaml for now until all the bindings are > converted. > > Cc: Thierry Reding > Cc: Sam Ravnborg > Cc: Maxime Ripard > Cc: Laurent Pinchart > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Rob Herring > --- > Note there's still some references to panel-common.txt that I need to > update or just go ahead and convert to schema. > > .../bindings/display/panel/panel-common.txt | 101 - > .../bindings/display/panel/panel-common.yaml | 143 ++ > .../bindings/display/panel/panel.txt | 4 - > .../bindings/display/panel/simple-panel.txt | 29 +--- > 4 files changed, 144 insertions(+), 133 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/panel/panel-common.txt > create mode 100644 > Documentation/devicetree/bindings/display/panel/panel-common.yaml I know it was this way before, but perhaps remove the redundant panel- prefix while at it? > delete mode 100644 Documentation/devicetree/bindings/display/panel/panel.txt > > diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt > b/Documentation/devicetree/bindings/display/panel/panel-common.txt > deleted file mode 100644 > index 5d2519af4bb5.. > --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt > +++ /dev/null > @@ -1,101 +0,0 @@ > -Common Properties for Display Panel > -=== > - > -This document defines device tree properties common to several classes of > -display panels. It doesn't constitue a device tree binding specification by > -itself but is meant to be referenced by device tree bindings. > - > -When referenced from panel device tree bindings the properties defined in > this > -document are defined as follows. The panel device tree bindings are > -responsible for defining whether each property is required or optional. > - > - > -Descriptive Properties > --- > - > -- width-mm, > -- height-mm: The width-mm and height-mm specify the width and height of the > - physical area where images are displayed. These properties are expressed in > - millimeters and rounded to the closest unit. > - > -- label: The label property specifies a symbolic name for the panel as a > - string suitable for use by humans. It typically contains a name inscribed > on > - the system (e.g. as an affixed label) or specified in the system's > - documentation (e.g. in the user's manual). > - > - If no such name exists, and unless the property is mandatory according to > - device tree bindings, it shall rather be omitted than constructed of > - non-descriptive information. For instance an LCD panel in a system that > - contains a single panel shall not be labelled "LCD" if that name is not > - inscribed on the system or used in a descriptive fashion in system > - documentation. > - > - > -Display Timings > > - > -- panel-timing: Most display panels are restricted to a single resolution and > - require specific display timings. The panel-timing subnode expresses those > - timings as specified in the timing subnode section of the display timing > - bindings defined in > - Documentation/devicetree/bindings/display/panel/display-timing.txt. > - > - > -Connectivity > - > - > -- ports: Panels receive video data through one or multiple connections. While > - the nature of those connections is specific to the panel type, the > - connectivity is expressed in a standard fashion using ports as specified in > - the device graph bindings defined in > - Documentation/devicetree/bindings/graph.txt. > - > -- ddc-i2c-bus: Some panels expose EDID information through an I2C-compatible > - bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a > - phandle to the system I2C controller connected to that bus. > - > - > -Control I/Os > - > - > -Many display panels can be controlled through pins driven by GPIOs. The > nature > -and timing of those control signals are device-specific and left for panel > -device tree bindings to specify. The following GPIO specifiers can however be > -used for panels that implement compatible control signals. > - > -- enable-gpios: Specifier for a GPIO connected to the panel enable control > - signal. The enable signal is active high and enables operation of the > panel. > - This property can also be used for panels implementing an active low power > - down signal, which is
Re: [PATCH] drm/imx: correct order of crtc disable
On Wed, Jun 19, 2019 at 11:40 AM Philipp Zabel wrote:
>
> Hi Robert,
>
> thank you for the patch.
>
> On Tue, 2019-06-18 at 16:50 +0100, Robert Beckett wrote:
> > Notify drm core before sending pending events during crtc disable.
> > This fixes the first event after disable having an old stale timestamp
> > by having drm_crtc_vblank_off update the timestamp to now.
> >
> > This was seen while debugging weston log message:
> > Warning: computed repaint delay is insane: -8212 msec
> >
>
> Would you say this
> Fixes: a474478642d5 ("drm/imx: fix crtc vblank state regression")
> ?
>
> > Signed-off-by: Robert Beckett
> > ---
> > drivers/gpu/drm/imx/ipuv3-crtc.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > index 9cc1d678674f..c436a28d50e4 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > @@ -91,14 +91,14 @@ static void ipu_crtc_atomic_disable(struct drm_crtc
> > *crtc,
> > ipu_dc_disable(ipu);
> > ipu_prg_disable(ipu);
> >
> > + drm_crtc_vblank_off(crtc);
> > +
>
> This is explained in the commit message and aligns with the
> drm_crtc_state @event documentation.
This part here looks fishy. The drm_vblank.c code is supposed to do
the right thing, no matter where or when you ask it to generate an
event. It definitely shouldn't generate a timestamp that's a few
seconds too early. Bunch of options:
- there's a bug in drm_vblank.c and it's mixing up something and
generating a totally bogus value.
- there's a lie in your imx vblank code, which trips the drm_vblank.c
counter interpolation and results in a totally bogus value.
drm_vblank.c assumes that if you do claim to have a hw counter and
generate timestamps, that those are perfectly accurate. It only falls
back to guestimating using the system timer if that's not present.
Either way, this very much smells like papering over a bug if this
change indeed fixes your wrong vblank timestamps.
> > spin_lock_irq(>dev->event_lock);
> > - if (crtc->state->event) {
> > + if (crtc->state->event && !crtc->state->active) {
>
> This is not mentioned though.
>
> If the pending event is not sent here, I assume it will be picked up by
> .atomic_flush and will then be sent after the first EOF interrupt after
> the modeset is complete. Can you explain this in the commit message?
Yeah looks correct (you only want to generate the event here when the
crtc stays off), if it gets re-enabled the event should only be
generated later on once that's all finished. But separate bugfix.
-Daniel
>
> With that,
> Reviewed-by: Philipp Zabel
>
> > drm_crtc_send_vblank_event(crtc, crtc->state->event);
> > crtc->state->event = NULL;
> > }
> > spin_unlock_irq(>dev->event_lock);
> > -
> > - drm_crtc_vblank_off(crtc);
> > }
> >
> > static void imx_drm_crtc_reset(struct drm_crtc *crtc)
>
> regards
> Philipp
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
