Re: [PATCH v3, 06/27] drm/mediatek: add mutex mod into ddp private data
Hi, Yongqiang:
On Wed, 2019-06-05 at 19:42 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> except mutex mod, mutex mod reg,mutex sof reg,
> and mutex sof id will be ddp private data
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 53
> +++---
> 1 file changed, 36 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 579ce28..ae94d44 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -41,12 +41,12 @@
> #define DISP_REG_CONFIG_DSI_SEL 0x050
> #define DISP_REG_CONFIG_DPI_SEL 0x064
>
> -#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> -#define DISP_REG_MUTEX(n)(0x24 + 0x20 * (n))
> -#define DISP_REG_MUTEX_RST(n)(0x28 + 0x20 * (n))
> -#define DISP_REG_MUTEX_MOD(n)(0x2c + 0x20 * (n))
> -#define DISP_REG_MUTEX_SOF(n)(0x30 + 0x20 * (n))
> -#define DISP_REG_MUTEX_MOD2(n) (0x34 + 0x20 * (n))
> +#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> +#define DISP_REG_MUTEX(n)(0x24 + 0x20 * (n))
> +#define DISP_REG_MUTEX_RST(n)(0x28 + 0x20 * (n))
> +#define DISP_REG_MUTEX_MOD(n)(0x2c + 0x20 * (n))
> +#define DISP_REG_MUTEX_SOF(n)(0x30 + 0x20 * (n))
> +#define DISP_REG_MUTEX_MOD2(n) (0x34 + 0x20 * (n))
You add 'tab' because of "add mutex mod register offset into ddp private
data" not "add mutex mod into ddp private data", so move this to the
related patch.
Regards,
CK
>
> #define INT_MUTEXBIT(1)
>
> @@ -147,12 +147,16 @@ struct mtk_disp_mutex {
> bool claimed;
> };
>
> +struct mtk_ddp_data {
> + const unsigned int *mutex_mod;
> +};
> +
> struct mtk_ddp {
> struct device *dev;
> struct clk *clk;
> void __iomem*regs;
> struct mtk_disp_mutex mutex[10];
> - const unsigned int *mutex_mod;
> + const struct mtk_ddp_data *data;
> };
>
> static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> @@ -202,6 +206,18 @@ struct mtk_ddp {
> [DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
> };
>
> +static const struct mtk_ddp_data mt2701_ddp_driver_data = {
> + .mutex_mod = mt2701_mutex_mod,
> +};
> +
> +static const struct mtk_ddp_data mt2712_ddp_driver_data = {
> + .mutex_mod = mt2712_mutex_mod,
> +};
> +
> +static const struct mtk_ddp_data mt8173_ddp_driver_data = {
> + .mutex_mod = mt8173_mutex_mod,
> +};
> +
> static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next,
> unsigned int *addr)
> @@ -464,15 +480,15 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex
> *mutex,
> reg = MUTEX_SOF_DPI1;
> break;
> default:
> - if (ddp->mutex_mod[id] < 32) {
> + if (ddp->data->mutex_mod[id] < 32) {
> offset = DISP_REG_MUTEX_MOD(mutex->id);
> reg = readl_relaxed(ddp->regs + offset);
> - reg |= 1 << ddp->mutex_mod[id];
> + reg |= 1 << ddp->data->mutex_mod[id];
> writel_relaxed(reg, ddp->regs + offset);
> } else {
> offset = DISP_REG_MUTEX_MOD2(mutex->id);
> reg = readl_relaxed(ddp->regs + offset);
> - reg |= 1 << (ddp->mutex_mod[id] - 32);
> + reg |= 1 << (ddp->data->mutex_mod[id] - 32);
> writel_relaxed(reg, ddp->regs + offset);
> }
> return;
> @@ -502,15 +518,15 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
> *mutex,
> ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
> break;
> default:
> - if (ddp->mutex_mod[id] < 32) {
> + if (ddp->data->mutex_mod[id] < 32) {
> offset = DISP_REG_MUTEX_MOD(mutex->id);
> reg = readl_relaxed(ddp->regs + offset);
> - reg &= ~(1 << ddp->mutex_mod[id]);
> + reg &= ~(1 << ddp->data->mutex_mod[id]);
> writel_relaxed(reg, ddp->regs + offset);
> } else {
> offset = DISP_REG_MUTEX_MOD2(mutex->id);
> reg = readl_relaxed(ddp->regs + offset);
> - reg &= ~(1 << (ddp->mutex_mod[id] - 32));
> + reg &= ~(1 << (ddp->data->mutex_mod[id] - 32));
> writel_relaxed(reg, ddp->regs + offset);
> }
> break;
> @@ -585,7 +601,7 @@ static int
Re: [pull] amdgpu, ttm drm-next-5.3
On Thu, Jun 6, 2019 at 7:25 AM Daniel Vetter wrote:
>
> On Thu, Jun 6, 2019 at 5:05 AM Alex Deucher wrote:
> >
> > On Wed, Jun 5, 2019 at 10:34 PM Dave Airlie wrote:
> > >
> > > On Thu, 6 Jun 2019 at 05:12, Alex Deucher wrote:
> > > >
> > > > Hi Dave, Daniel,
> > > >
> > > > More new stuff for 5.3:
> > > >
> > > > amdgpu:
> > > > - Revert timeline support until KHR is ready
> > > > - Various driver reload fixes
> > > > - Refactor clock handling in DC
> > > > - Aux fixes for DC
> > > > - Bandwidth calculation updates for DC
> > > > - Fix documentation due to file rename
> > > > - RAS fix
> > > > - Fix race in late_init
> > > >
> > > > ttm:
> > > > - Allow for better forward progress when there is heavy memory
> > > > contention
> > >
> > > dim: 137a7da92557 ("Revert "drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to
> > > amdgpu""): mandatory review missing.
> > > dim: cf25b6444376 ("gpu: amdgpu: fix broken amdgpu_dma_buf.c
> > > references"): SHA1 in fixes line not found:
> > > dim: 988076cd8c5c ("drm/amdgpu: rename amdgpu_prime.[ch] into
> > > amdgpu_dma_buf.[ch]")
> > >
> > > The first I'm not worried about, but the fixes line should be fixed
> > > before I can pull this.
> > > 2fbd6f94accdbb223acccada68940b50b0c668d9 is the upstream commit in my
> > > tree.
> >
> > Weird. dim didn't complain when I ran it. I guess the old commit
> > happened to be in my repo. I'll fix it up.
>
> I should check also that it's an ancestor commit, not just that it's
s/I/It/, meanwhile dim makes sure this is the case. Typing mails
before coffee :-)
https://gitlab.freedesktop.org/drm/maintainer-tools/blob/master/dim#L831
Is the check.
-Daniel
> in the repo (but that's a few conditions later on, for Dave it
> obviously failed earlier). Since it's a branch not a tag I can't pull
> the old version anymore and take a look and figure out what might be
> the reason, but this should have worked.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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
Re: [pull] amdgpu, ttm drm-next-5.3
On Thu, Jun 6, 2019 at 5:05 AM Alex Deucher wrote:
>
> On Wed, Jun 5, 2019 at 10:34 PM Dave Airlie wrote:
> >
> > On Thu, 6 Jun 2019 at 05:12, Alex Deucher wrote:
> > >
> > > Hi Dave, Daniel,
> > >
> > > More new stuff for 5.3:
> > >
> > > amdgpu:
> > > - Revert timeline support until KHR is ready
> > > - Various driver reload fixes
> > > - Refactor clock handling in DC
> > > - Aux fixes for DC
> > > - Bandwidth calculation updates for DC
> > > - Fix documentation due to file rename
> > > - RAS fix
> > > - Fix race in late_init
> > >
> > > ttm:
> > > - Allow for better forward progress when there is heavy memory contention
> >
> > dim: 137a7da92557 ("Revert "drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to
> > amdgpu""): mandatory review missing.
> > dim: cf25b6444376 ("gpu: amdgpu: fix broken amdgpu_dma_buf.c
> > references"): SHA1 in fixes line not found:
> > dim: 988076cd8c5c ("drm/amdgpu: rename amdgpu_prime.[ch] into
> > amdgpu_dma_buf.[ch]")
> >
> > The first I'm not worried about, but the fixes line should be fixed
> > before I can pull this.
> > 2fbd6f94accdbb223acccada68940b50b0c668d9 is the upstream commit in my tree.
>
> Weird. dim didn't complain when I ran it. I guess the old commit
> happened to be in my repo. I'll fix it up.
I should check also that it's an ancestor commit, not just that it's
in the repo (but that's a few conditions later on, for Dave it
obviously failed earlier). Since it's a branch not a tag I can't pull
the old version anymore and take a look and figure out what might be
the reason, but this should have worked.
-Daniel
--
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
Re: [PATCH v3, 01/27] dt-bindings: mediatek: add binding for mt8183 display
Hi, Yongqiang:
On Wed, 2019-06-05 at 19:42 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> Update device tree binding documention for the display subsystem for
> Mediatek MT8183 SOCs
>
> Signed-off-by: Yongqiang Niu
> ---
> .../bindings/display/mediatek/mediatek,disp.txt| 34
> +-
> 1 file changed, 20 insertions(+), 14 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index 8469de5..70770fe 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -27,20 +27,20 @@
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt.
>
> Required properties (all function blocks):
> - compatible: "mediatek,-disp-", one of
> - "mediatek,-disp-ovl" - overlay (4 layers, blending, csc)
> - "mediatek,-disp-rdma" - read DMA / line buffer
> - "mediatek,-disp-wdma" - write DMA
> - "mediatek,-disp-color" - color processor
> - "mediatek,-disp-aal" - adaptive ambient light controller
> - "mediatek,-disp-gamma" - gamma correction
> - "mediatek,-disp-merge" - merge streams from two RDMA sources
> - "mediatek,-disp-split" - split stream to two encoders
> - "mediatek,-disp-ufoe" - data compression engine
> - "mediatek,-dsi"- DSI controller, see mediatek,dsi.txt
> - "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt
> - "mediatek,-disp-mutex" - display mutex
> - "mediatek,-disp-od"- overdrive
> - the supported chips are mt2701, mt2712 and mt8173.
> + "mediatek,-disp-ovl" - overlay (4 layers, blending,
> csc)
> + "mediatek,-disp-rdma" - read DMA / line buffer
> + "mediatek,-disp-wdma" - write DMA
> + "mediatek,-disp-color"- color processor
> + "mediatek,-disp-aal" - adaptive ambient light
> controller
> + "mediatek,-disp-gamma"- gamma correction
> + "mediatek,-disp-merge"- merge streams from two RDMA
> sources
> + "mediatek,-disp-split"- split stream to two encoders
> + "mediatek,-disp-ufoe" - data compression engine
> + "mediatek,-dsi" - DSI controller, see
> mediatek,dsi.txt
> + "mediatek,-dpi" - DPI controller, see
> mediatek,dpi.txt
> + "mediatek,-disp-mutex"- display mutex
> + "mediatek,-disp-od" - overdrive
I think you add 'tab' because of "add ovl_2l description for mt8183
display" not "add binding for mt8183 display", so move the 'tab' to the
related patch.
> + the supported chips are mt2701, mt2712, mt8173 and mt8183.
> - reg: Physical base address and length of the function block register space
> - interrupts: The interrupt signal from the function block (required, except
> for
>merge and split function blocks).
> @@ -71,6 +71,12 @@ mmsys: clock-controller@1400 {
> #clock-cells = <1>;
> };
>
> +display_components: dispsys@1400 {
> + compatible = "mediatek,mt8183-display";
Where do you define "mediatek,mt8183-display"?
Regards,
CK
> + reg = <0 0x1400 0 0x1000>;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> +};
> +
> ovl0: ovl@1400c000 {
> compatible = "mediatek,mt8173-disp-ovl";
> reg = <0 0x1400c000 0 0x1000>;
[pull v2] amdgpu, ttm drm-next-5.3
Hi Dave, Daniel, More new stuff for 5.3: amdgpu: - Revert timeline support until KHR is ready - Various driver reload fixes - Refactor clock handling in DC - Aux fixes for DC - Bandwidth calculation updates for DC - Fix documentation due to file rename - RAS fix - Fix race in late_init ttm: - Allow for better forward progress when there is heavy memory contention v2: fix sha1 in fixes line. The following changes since commit 91c1ead6aee22d4595f50ba66070b94a4a8f84a9: Merge branch 'drm-next-5.3' of git://people.freedesktop.org/~agd5f/linux into drm-next (2019-05-31 10:04:39 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-5.3 for you to fetch changes up to 72a14e9b23d0a5a68f8504a2ecaf26788a11a14d: Revert "drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to amdgpu" (2019-06-05 22:18:09 -0500) Alex Deucher (3): drm/amdgpu: fix a race in GPU reset with IB test (v2) drm/amdgpu/display: Drop some new CONFIG_DRM_AMD_DC_DCN1_01 guards Revert "drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to amdgpu" Anthony Koo (2): drm/amd/display: do not power on eDP power rail early drm/amd/display: fix issues with bad AUX reply on some displays Aric Cyr (2): drm/amd/display: 3.2.32 drm/amd/display: program manual trigger only for bottom most pipe Chris Park (1): drm/amd/display: Move link functions from dc to dc_link Christian König (7): drm/ttm: Make LRU removal optional v2 drm/ttm: return immediately in case of a signal drm/ttm: remove manual placement preference drm/ttm: cleanup ttm_bo_mem_space drm/ttm: immediately move BOs to the new LRU v3 drm/ttm: fix busy memory to fail other user v10 drm/ttm: fix ttm_bo_unreserve Chunming Zhou (1): drm/amd/display: use ttm_eu_reserve_buffers instead of amdgpu_bo_reserve v2 Daniel He (1): drm/amd/display: Modified AUX_DPHY_RX_CONTROL0 Emily Deng (3): drm/amdgpu:Fix the unpin warning about csb buffer drm/amdgpu/sriov: Correct some register program method drm/amdgpu/display: Fix reload driver error Eric Bernstein (1): drm/amd/display: Refactor DIO stream encoder Eric Yang (5): drm/amd/display: make clk mgr soc specific drm/amd/display: Move CLK_BASE_INNER macro drm/amd/display: move clk_mgr files to right place drm/amd/display: Fix type of pp_smu_wm_set_range struct drm/amd/display: Refactor clk_mgr functions Eryk Brol (3): drm/amd/display: Disable audio stream only if it's currently enabled drm/amd/display: Ensure DRR triggers in BP drm/amd/display: Increase Backlight Gain Step Size Gary Kattan (1): drm/amd/display: Implement CM dealpha and bias interfaces Hugo Hu (1): drm/amd/display: Don't use ROM for output TF if GAMMA_CS_TFM_1D Ilya Bakoulin (1): drm/amd/display: Add writeback_config to VBA vars Jun Lei (1): drm/amd/display: Add min_dcfclk_mhz field to bb overrides Krunoslav Kovac (2): drm/amd/display: Add GSL source select registers drm/amd/display: CS_TFM_1D only applied post EOTF Mauro Carvalho Chehab (1): gpu: amdgpu: fix broken amdgpu_dma_buf.c references Nicholas Kazlauskas (1): drm/amd/display: Reset planes for color management changes Oak Zeng (1): drm/amdkfd: Return proper error code for gws alloc API Paul Hsieh (1): drm/amd/display: disable PSR/ABM before destroy DMCU struct Su Sung Chung (2): drm/amd/display: fix calculation of total_data_read_bandwidth drm/amd/display: fix crash on setmode when mode is close to bw limit Wenjing Liu (1): drm/amd/display: assign new stream id in dc_copy_stream xinhui pan (2): drm/amdgpu: ras injection use gpu address drm/amdgpu: cancel late_init_work before gpu reset Documentation/gpu/amdgpu.rst |4 +- drivers/gpu/drm/amd/amdgpu/amdgpu.h|2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 11 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c|2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 116 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 16 + drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 14 +- drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c |8 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c |6 +- .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c |2 +- drivers/gpu/drm/amd/display/Makefile |1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 66 +- drivers/gpu/drm/amd/display/dc/Makefile|2 +-
Re: [pull] amdgpu, ttm drm-next-5.3
On Wed, Jun 5, 2019 at 10:34 PM Dave Airlie wrote:
>
> On Thu, 6 Jun 2019 at 05:12, Alex Deucher wrote:
> >
> > Hi Dave, Daniel,
> >
> > More new stuff for 5.3:
> >
> > amdgpu:
> > - Revert timeline support until KHR is ready
> > - Various driver reload fixes
> > - Refactor clock handling in DC
> > - Aux fixes for DC
> > - Bandwidth calculation updates for DC
> > - Fix documentation due to file rename
> > - RAS fix
> > - Fix race in late_init
> >
> > ttm:
> > - Allow for better forward progress when there is heavy memory contention
>
> dim: 137a7da92557 ("Revert "drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to
> amdgpu""): mandatory review missing.
> dim: cf25b6444376 ("gpu: amdgpu: fix broken amdgpu_dma_buf.c
> references"): SHA1 in fixes line not found:
> dim: 988076cd8c5c ("drm/amdgpu: rename amdgpu_prime.[ch] into
> amdgpu_dma_buf.[ch]")
>
> The first I'm not worried about, but the fixes line should be fixed
> before I can pull this.
> 2fbd6f94accdbb223acccada68940b50b0c668d9 is the upstream commit in my tree.
Weird. dim didn't complain when I ran it. I guess the old commit
happened to be in my repo. I'll fix it up.
Alex
>
> Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #42 from Andrew Randrianasulu --- (In reply to Rui Salvaterra from comment #41) > Hi, guys > > I haven't tried Marek's solution yet. It's the first time I build Mesa from > scratch and I've never used Meson before, so I'm studying along the way. I > applied the patch, configured with no DRI drivers and only the r300g driver, > compiled and installed to the default location > (/usr/local/lib/x86_64-linux-gnu, it seems). Unfortunately, glxinfo can't > find the libraries when I point the environment variables to them, so I must > have done something stupid. Will dig deeper. > (I know this isn't a developer support thread, I just wanted you to know I > haven't given up or stopped!) meson actually accepts prefix , so I use it like this (from BUILD dir inside mesa tree): meson ../ --prefix=/usr/X11R7 rest_of_options (obviously, for x86-64 prefix will be diffeent, I just wanted to say I have non-standard X prefix and install mesa into it just fine) full line in my case looks like: meson ../ --prefix=/usr/X11R7 --strip --buildtype debugoptimized -Degl=true -Ddri-drivers=r100,r200,i965,nouveau -Dplatforms=drm,x11 -Dgallium-drivers=i915,r600,radeonsi,swrast,virgl,nouveau,r300 -Dvulkan-drivers=amd,intel -Dgallium-nine=true -Dgallium-opencl=icd -Dgallium-va=true -Dgallium-xvmc=true -Dgallium-xa=false You probably want to add --reconfigure if you re-run meson after some git pull from same BUILD directory. -- 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: [pull] amdgpu, ttm drm-next-5.3
On Thu, 6 Jun 2019 at 05:12, Alex Deucher wrote:
>
> Hi Dave, Daniel,
>
> More new stuff for 5.3:
>
> amdgpu:
> - Revert timeline support until KHR is ready
> - Various driver reload fixes
> - Refactor clock handling in DC
> - Aux fixes for DC
> - Bandwidth calculation updates for DC
> - Fix documentation due to file rename
> - RAS fix
> - Fix race in late_init
>
> ttm:
> - Allow for better forward progress when there is heavy memory contention
dim: 137a7da92557 ("Revert "drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to
amdgpu""): mandatory review missing.
dim: cf25b6444376 ("gpu: amdgpu: fix broken amdgpu_dma_buf.c
references"): SHA1 in fixes line not found:
dim: 988076cd8c5c ("drm/amdgpu: rename amdgpu_prime.[ch] into
amdgpu_dma_buf.[ch]")
The first I'm not worried about, but the fixes line should be fixed
before I can pull this.
2fbd6f94accdbb223acccada68940b50b0c668d9 is the upstream commit in my tree.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] v5.2 fixes for Arm drivers
Hi Liviu,
dim: c43de636a469 ("drm/komeda: Potential error pointer dereference"):
committer Signed-off-by missing.
dim: c43de636a469 ("drm/komeda: Potential error pointer dereference"):
SHA1 in fixes line not found:
dim: 7d31b9e7a550 ("drm/komeda: Add komeda_plane/plane_helper_funcs")
These are real, please fix and resubmit.
Dave.
On Wed, 5 Jun 2019 at 00:42, Liviu Dudau wrote:
>
> Hello DRM maintainers,
>
> I have collected an assorted set of patches for Arm DRM drivers that I
> maintain
> in my tree, so it's time to flush them out. Please pull!
>
> Best regards,
> Liviu
>
>
> The following changes since commit 2a3e0b716296a504d9e65fea7acb379c86fe4283:
>
> Merge tag 'imx-drm-fixes-2019-05-29' of
> git://git.pengutronix.de/git/pza/linux into drm-fixes (2019-05-31 09:15:25
> +1000)
>
> are available in the Git repository at:
>
> git://linux-arm.org/linux-ld.git malidp-fixes
>
> for you to fetch changes up to c43de636a469a42c7b040c8d48eda6d5c3977b9c:
>
> drm/komeda: Potential error pointer dereference (2019-06-04 15:19:40 +0100)
>
>
> Dan Carpenter (1):
> drm/komeda: Potential error pointer dereference
>
> Lowry Li (Arm Technology China) (1):
> drm/komeda: fixing of DMA mapping sg segment warning
>
> Robin Murphy (2):
> drm/arm/hdlcd: Actually validate CRTC modes
> drm/arm/hdlcd: Allow a bit of clock tolerance
>
> Wen He (1):
> drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 times
>
> YueHaibing (1):
> drm/komeda: remove set but not used variable 'kcrtc'
>
> james qian wang (Arm Technology China) (1):
> drm/komeda: Constify the usage of komeda_component/pipeline/dev_funcs
>
> drivers/gpu/drm/arm/display/komeda/d71/d71_component.c | 8
> drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 4 ++--
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +-
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c| 6 +-
> drivers/gpu/drm/arm/display/komeda/komeda_dev.h| 8 +---
> drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c | 4 ++--
> drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h | 10 +-
> drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 4 +---
> drivers/gpu/drm/arm/hdlcd_crtc.c | 14 +++---
> drivers/gpu/drm/arm/malidp_drv.c | 13 -
> 10 files changed, 44 insertions(+), 29 deletions(-)
> --
>
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---
> ¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 17/18] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec()
On Fri, May 17, 2019 at 11:22 AM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-05-14 15:17:10)
> > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> > new file mode 100644
> > index 0..fe0f2bae66085
> > --- /dev/null
> > +++ b/kernel/sysctl-test.c
> > @@ -0,0 +1,293 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * KUnit test of proc sysctl.
> > + */
> > +
> > +#include
> > +#include
>
> Is this include used?
Deleted.
>
> > +#include
> > +#include
>
> Is this include used?
Deleted.
>
> > +
> > +
> > +static void sysctl_test_dointvec_happy_single_negative(struct kunit *test)
> > +{
> > + struct ctl_table table = {
> > + .procname = "foo",
> > + .data = _data.int_0001,
> > + .maxlen = sizeof(int),
> > + .mode = 0644,
> > + .proc_handler = proc_dointvec,
> > + .extra1 = _zero,
> > + .extra2 = _one_hundred,
> > + };
> > + char input[] = "-9";
> > + size_t len = sizeof(input) - 1;
> > + loff_t pos = 0;
> > +
> > + table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > + KUNIT_EXPECT_EQ(test, 0, proc_dointvec(, 1, input, ,
> > ));
> > + KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > + KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos);
> > + KUNIT_EXPECT_EQ(test, -9, *(int *)table.data);
>
> Is the casting necessary? Or can the macro do a type coercion of the
> second parameter based on the first type?
Data field is defined as void* so I believe casting is necessary to
dereference it as a pointer to an array of ints. I don't think the
macro should do any type coercion that == operator wouldn't do.
I did change the cast to make it more clear that it's a pointer to an
array of ints being dereferenced.
>
> > +}
> > +
> > +static void sysctl_test_dointvec_single_less_int_min(struct kunit *test)
> > +{
> > + struct ctl_table table = {
> > + .procname = "foo",
> > + .data = _data.int_0001,
> > + .maxlen = sizeof(int),
> > + .mode = 0644,
> > + .proc_handler = proc_dointvec,
> > + .extra1 = _zero,
> > + .extra2 = _one_hundred,
> > + };
> > + char input[32];
> > + size_t len = sizeof(input) - 1;
> > + loff_t pos = 0;
> > + unsigned long abs_of_less_than_min = (unsigned long)INT_MAX
> > +- (INT_MAX + INT_MIN) + 1;
> > +
> > + KUNIT_EXPECT_LT(test,
> > + snprintf(input, sizeof(input), "-%lu",
> > +abs_of_less_than_min),
> > + sizeof(input));
> > +
> > + table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > + KUNIT_EXPECT_EQ(test, -EINVAL,
> > + proc_dointvec(, 1, input, , ));
> > + KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > + KUNIT_EXPECT_EQ(test, 0, *(int *)table.data);
> > +}
> > +
> > +static void sysctl_test_dointvec_single_greater_int_max(struct kunit *test)
> > +{
> > + struct ctl_table table = {
> > + .procname = "foo",
> > + .data = _data.int_0001,
> > + .maxlen = sizeof(int),
> > + .mode = 0644,
> > + .proc_handler = proc_dointvec,
> > + .extra1 = _zero,
> > + .extra2 = _one_hundred,
> > + };
> > + char input[32];
> > + size_t len = sizeof(input) - 1;
> > + loff_t pos = 0;
> > + unsigned long greater_than_max = (unsigned long)INT_MAX + 1;
> > +
> > + KUNIT_EXPECT_GT(test, greater_than_max, INT_MAX);
> > + KUNIT_EXPECT_LT(test, snprintf(input, sizeof(input), "%lu",
> > + greater_than_max),
> > + sizeof(input));
> > + table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > + KUNIT_EXPECT_EQ(test, -EINVAL,
> > + proc_dointvec(, 1, input, , ));
> > + KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > + KUNIT_EXPECT_EQ(test, 0, *(int *)table.data);
> > +}
> > +
> > +static int sysctl_test_init(struct kunit *test)
> > +{
> > + return 0;
> > +}
> > +
> > +/*
> > + * This is run once after each test case, see the comment on
> > example_test_module
> > + * for more information.
> > + */
> > +static void sysctl_test_exit(struct kunit *test)
> > +{
> > +}
> Can the above two be omitted? If they can be empty sometimes it would be
> nice to avoid the extra symbols and code by letting them be assigned to
> NULL in the kunit_module.
Deleted.
>
> > +
> > +/*
> > + * Here we make a list of all the test cases we want to add to the test
> > module
> > + * below.
> > + */
> > +static struct kunit_case
[Bug 110845] [DC-only][regression] cannot select full refresh rate on 5.2rc - 144Hz 2560x1440
https://bugs.freedesktop.org/show_bug.cgi?id=110845 --- Comment #4 from Matt Coffin --- I just tested this now on my setup with this patch on top of amd-staging-drm-next, and all looks good! Thank you kindly. Too bad this one was easy enough that I didn't get to do any learning. Now, on to the power management issues I see under load :). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/virtio: Add memory barriers for capset cache.
From: David Riley
After data is copied to the cache entry, atomic_set is used indicate
that the data is the entry is valid without appropriate memory barriers.
Similarly the read side was missing the same memory barries.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +++
drivers/gpu/drm/virtio/virtgpu_vq.c| 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 88c1ed57a3c5..502f5f7c2298 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -542,6 +542,9 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
if (!ret)
return -EBUSY;
+ /* is_valid check must proceed before copy of the cache entry. */
+ virt_rmb();
+
ptr = cache_ent->caps_cache;
if (copy_to_user((void __user *)(unsigned long)args->addr, ptr, size))
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index dd5ead2541c2..b974eba4fe7d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -583,6 +583,8 @@ static void virtio_gpu_cmd_capset_cb(struct
virtio_gpu_device *vgdev,
cache_ent->id == le32_to_cpu(cmd->capset_id)) {
memcpy(cache_ent->caps_cache, resp->capset_data,
cache_ent->size);
+ /* Copy must occur before is_valid is signalled. */
+ virt_wmb();
atomic_set(_ent->is_valid, 1);
break;
}
--
2.22.0.rc1.311.g5d7573a151-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/virtio: Fix cache entry creation race.
From: David Riley
virtio_gpu_cmd_get_capset would check for the existence of an entry
under lock. If it was not found, it would unlock and call
virtio_gpu_cmd_get_capset to create a new entry. The new entry would
be added it to the list without checking if it was added by another
task during the period where the lock was not held resulting in
duplicate entries.
Compounding this issue, virtio_gpu_cmd_capset_cb would stop iterating
after find the first matching entry. Multiple callbacks would modify
the first entry, but any subsequent entries and their associated waiters
would eventually timeout since they don't become valid, also wasting
memory along the way.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index da71568adb9a..dd5ead2541c2 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -684,8 +684,11 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device
*vgdev,
struct virtio_gpu_vbuffer *vbuf;
int max_size;
struct virtio_gpu_drv_cap_cache *cache_ent;
+ struct virtio_gpu_drv_cap_cache *search_ent;
void *resp_buf;
+ *cache_p = NULL;
+
if (idx >= vgdev->num_capsets)
return -EINVAL;
@@ -716,9 +719,26 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device
*vgdev,
atomic_set(_ent->is_valid, 0);
cache_ent->size = max_size;
spin_lock(>display_info_lock);
- list_add_tail(_ent->head, >cap_cache);
+ /* Search while under lock in case it was added by another task. */
+ list_for_each_entry(search_ent, >cap_cache, head) {
+ if (search_ent->id == vgdev->capsets[idx].id &&
+ search_ent->version == version) {
+ *cache_p = search_ent;
+ break;
+ }
+ }
+ if (!*cache_p)
+ list_add_tail(_ent->head, >cap_cache);
spin_unlock(>display_info_lock);
+ if (*cache_p) {
+ /* Entry was found, so free everything that was just created. */
+ kfree(resp_buf);
+ kfree(cache_ent->caps_cache);
+ kfree(cache_ent);
+ return 0;
+ }
+
cmd_p = virtio_gpu_alloc_cmd_resp
(vgdev, _gpu_cmd_capset_cb, , sizeof(*cmd_p),
sizeof(struct virtio_gpu_resp_capset) + max_size,
--
2.22.0.rc1.311.g5d7573a151-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/virtio: Wake up all waiters when capset response comes in.
From: David Riley If multiple callers occur simultaneously, wake them all up. Signed-off-by: David Riley --- drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index e62fe24b1a2e..da71568adb9a 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -588,7 +588,7 @@ static void virtio_gpu_cmd_capset_cb(struct virtio_gpu_device *vgdev, } } spin_unlock(>display_info_lock); - wake_up(>resp_wq); + wake_up_all(>resp_wq); } static int virtio_get_edid_block(void *data, u8 *buf, -- 2.22.0.rc1.311.g5d7573a151-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/virtio: Ensure cached capset entries are valid before copying.
From: David Riley
virtio_gpu_get_caps_ioctl could return success with invalid data if a
second caller to the function occurred after the entry was created in
virtio_gpu_cmd_get_capset but prior to the virtio_gpu_cmd_capset_cb
callback being called. This could leak contents of memory as well
since the caps_cache allocation is done without zeroing.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 949a264985fc..88c1ed57a3c5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -526,7 +526,6 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
list_for_each_entry(cache_ent, >cap_cache, head) {
if (cache_ent->id == args->cap_set_id &&
cache_ent->version == args->cap_set_ver) {
- ptr = cache_ent->caps_cache;
spin_unlock(>display_info_lock);
goto copy_exit;
}
@@ -537,6 +536,7 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
virtio_gpu_cmd_get_capset(vgdev, found_valid, args->cap_set_ver,
_ent);
+copy_exit:
ret = wait_event_timeout(vgdev->resp_wq,
atomic_read(_ent->is_valid), 5 * HZ);
if (!ret)
@@ -544,7 +544,6 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
ptr = cache_ent->caps_cache;
-copy_exit:
if (copy_to_user((void __user *)(unsigned long)args->addr, ptr, size))
return -EFAULT;
--
2.22.0.rc1.311.g5d7573a151-goog
Re: [PATCH v5 2/3] media: uapi: Add MEDIA_BUS_FMT_RGB888_3X8 media bus format
Em Thu, 6 Jun 2019 00:22:46 +0200 Paul Cercueil escreveu: > This patch adds MEDIA_BUS_FMT_RGB888_3X8, used for the GiantPlus > GPM940B0 24-bit TFT panel, where the RGB components are transferred > sequentially on a 8-bit bus. > > Signed-off-by: Paul Cercueil Looks ok to me. Feel free to apply via DRM tree. Acked-by: Mauro Carvalho Chehab > --- > > Notes: > v2: New patch > > v3: No change > > v4: Add only MEDIA_BUS_FMT_RGB888_3X8, as we don't have to care about > endianness > > v5: Also update Documentation/media/uapi/v4l/subdev-formats.rst > > .../media/uapi/v4l/subdev-formats.rst | 107 ++ > include/uapi/linux/media-bus-format.h | 3 +- > 2 files changed, 109 insertions(+), 1 deletion(-) > > diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst > b/Documentation/media/uapi/v4l/subdev-formats.rst > index ab1a48a5ae80..f4f8de31ac63 100644 > --- a/Documentation/media/uapi/v4l/subdev-formats.rst > +++ b/Documentation/media/uapi/v4l/subdev-formats.rst > @@ -1305,6 +1305,113 @@ The following tables list existing packed RGB formats. >- g\ :sub:`6` >- g\ :sub:`5` >- g\ :sub:`4` > +* .. _MEDIA-BUS-FMT-RGB888-3X8: > + > + - MEDIA_BUS_FMT_RGB888_3X8 > + - 0x101c > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - r\ :sub:`7` > + - r\ :sub:`6` > + - r\ :sub:`5` > + - r\ :sub:`4` > + - r\ :sub:`3` > + - r\ :sub:`2` > + - r\ :sub:`1` > + - r\ :sub:`0` > +* - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - g\ :sub:`7` > + - g\ :sub:`6` > + - g\ :sub:`5` > + - g\ :sub:`4` > + - g\ :sub:`3` > + - g\ :sub:`2` > + - g\ :sub:`1` > + - g\ :sub:`0` > +* - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - > + - b\ :sub:`7` > + - b\ :sub:`6` > + - b\ :sub:`5` > + - b\ :sub:`4` > + - b\ :sub:`3` > + - b\ :sub:`2` > + - b\ :sub:`1` > + - b\ :sub:`0` > * .. _MEDIA-BUS-FMT-ARGB888-1X32: > >- MEDIA_BUS_FMT_ARGB888_1X32 > diff --git a/include/uapi/linux/media-bus-format.h > b/include/uapi/linux/media-bus-format.h > index 2a6b253cfb05..16c1fa2d89a4 100644 > --- a/include/uapi/linux/media-bus-format.h > +++ b/include/uapi/linux/media-bus-format.h > @@ -34,7 +34,7 @@ > > #define MEDIA_BUS_FMT_FIXED 0x0001 > > -/* RGB - next is 0x101c */ > +/* RGB - next is 0x101d */ > #define MEDIA_BUS_FMT_RGB444_1X120x1016 > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001 > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002 > @@ -55,6 +55,7 @@ > #define MEDIA_BUS_FMT_RGB888_1X240x100a > #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b > #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c > +#define MEDIA_BUS_FMT_RGB888_3X8 0x101c > #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG 0x1011 > #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012 > #define MEDIA_BUS_FMT_ARGB_1X32 0x100d Thanks, Mauro
[Bug 203471] Tearing on Raven Ridge and RX560X PRIME setup even with Vsync enabled
https://bugzilla.kernel.org/show_bug.cgi?id=203471 --- Comment #10 from Haxk20 (haxk...@gmail.com) --- (In reply to Michel Dänzer from comment #8) > The tearing occurs because amdgpu doesn't support scatter/gather scanout > with Raven yet, so page flipping cannot be used. > > For the time being, you can get rid of the tearing by enabling TearFree: > > xrandr --output eDP --set TearFree on > > See the amdgpu (4) manpage for more information about TearFree. Also i forgot to ask. Isnt there an time estimate when can we expect scatter scanout support for Raven ? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #41 from Rui Salvaterra --- Hi, guys I haven't tried Marek's solution yet. It's the first time I build Mesa from scratch and I've never used Meson before, so I'm studying along the way. I applied the patch, configured with no DRI drivers and only the r300g driver, compiled and installed to the default location (/usr/local/lib/x86_64-linux-gnu, it seems). Unfortunately, glxinfo can't find the libraries when I point the environment variables to them, so I must have done something stupid. Will dig deeper. (I know this isn't a developer support thread, I just wanted you to know I haven't given up or stopped!) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/3] drm/panel: simple: Add GiantPlus GPM940B0 panel support
The GiantPlus GPM940B0 is a simple 3.0" 320x240 24-bit TFT panel.
Signed-off-by: Paul Cercueil
Tested-by: Artur Rojek
---
Notes:
v2: Change bus format to MEDIA_BUS_FMT_RGB888_3X8_BE
v3: No change
v4: Change bus format to MEDIA_BUS_FMT_RGB888_3X8
v5: No change
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5a93c4edf1e4..eec9a9efcc73 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1335,6 +1335,31 @@ static const struct panel_desc giantplus_gpg482739qs5 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct display_timing giantplus_gpm940b0_timing = {
+ .pixelclock = { 1350, 2700, 2750 },
+ .hactive = { 320, 320, 320 },
+ .hfront_porch = { 14, 686, 718 },
+ .hback_porch = { 50, 70, 255 },
+ .hsync_len = { 1, 1, 1 },
+ .vactive = { 240, 240, 240 },
+ .vfront_porch = { 1, 1, 179 },
+ .vback_porch = { 1, 21, 31 },
+ .vsync_len = { 1, 1, 6 },
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_desc giantplus_gpm940b0 = {
+ .timings = _gpm940b0_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 60,
+ .height = 45,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_3X8,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
+};
+
static const struct display_timing hannstar_hsd070pww1_timing = {
.pixelclock = { 6430, 7110, 8200 },
.hactive = { 1280, 1280, 1280 },
@@ -2882,6 +2907,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "giantplus,gpg482739qs5",
.data = _gpg482739qs5
+ }, {
+ .compatible = "giantplus,gpm940b0",
+ .data = _gpm940b0,
}, {
.compatible = "hannstar,hsd070pww1",
.data = _hsd070pww1,
--
2.21.0.593.g511ec345e18
[PATCH v5 2/3] media: uapi: Add MEDIA_BUS_FMT_RGB888_3X8 media bus format
This patch adds MEDIA_BUS_FMT_RGB888_3X8, used for the GiantPlus GPM940B0 24-bit TFT panel, where the RGB components are transferred sequentially on a 8-bit bus. Signed-off-by: Paul Cercueil --- Notes: v2: New patch v3: No change v4: Add only MEDIA_BUS_FMT_RGB888_3X8, as we don't have to care about endianness v5: Also update Documentation/media/uapi/v4l/subdev-formats.rst .../media/uapi/v4l/subdev-formats.rst | 107 ++ include/uapi/linux/media-bus-format.h | 3 +- 2 files changed, 109 insertions(+), 1 deletion(-) diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst b/Documentation/media/uapi/v4l/subdev-formats.rst index ab1a48a5ae80..f4f8de31ac63 100644 --- a/Documentation/media/uapi/v4l/subdev-formats.rst +++ b/Documentation/media/uapi/v4l/subdev-formats.rst @@ -1305,6 +1305,113 @@ The following tables list existing packed RGB formats. - g\ :sub:`6` - g\ :sub:`5` - g\ :sub:`4` +* .. _MEDIA-BUS-FMT-RGB888-3X8: + + - MEDIA_BUS_FMT_RGB888_3X8 + - 0x101c + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` +* - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` +* - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - b\ :sub:`7` + - b\ :sub:`6` + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` * .. _MEDIA-BUS-FMT-ARGB888-1X32: - MEDIA_BUS_FMT_ARGB888_1X32 diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index 2a6b253cfb05..16c1fa2d89a4 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -34,7 +34,7 @@ #define MEDIA_BUS_FMT_FIXED0x0001 -/* RGB - next is 0x101c */ +/* RGB - next is 0x101d */ #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 @@ -55,6 +55,7 @@ #define MEDIA_BUS_FMT_RGB888_1X24 0x100a #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c +#define MEDIA_BUS_FMT_RGB888_3X8 0x101c #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG0x1011 #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012 #define MEDIA_BUS_FMT_ARGB_1X320x100d -- 2.21.0.593.g511ec345e18
[PATCH v5 1/3] dt-bindings: display: Add GiantPlus GPM940B0 panel documentation
The GPM940B0 is a 3.0" 320x240 24-bit TFT LCD panel. Signed-off-by: Paul Cercueil Reviewed-by: Rob Herring --- Notes: v2: New patch v3: Add Rob's ack v4-v5: No change .../bindings/display/panel/giantplus,gpm940b0.txt| 12 1 file changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt diff --git a/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt b/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt new file mode 100644 index ..3dab52f92c26 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt @@ -0,0 +1,12 @@ +GiantPlus 3.0" (320x240 pixels) 24-bit TFT LCD panel + +Required properties: +- compatible: should be "giantplus,gpm940b0" +- power-supply: as specified in the base binding + +Optional properties: +- backlight: as specified in the base binding +- enable-gpios: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.21.0.593.g511ec345e18
Re: [PATCH v4 2/3] media: uapi: Add RGB bus format for the GiantPlus GPM940B0 panel
Le mer. 5 juin 2019 à 16:26, Mauro Carvalho Chehab a écrit : Em Mon, 3 Jun 2019 17:35:10 +0200 Paul Cercueil escreveu: The GiantPlus GPM940B0 is a 24-bit TFT panel where the RGB components are transferred sequentially on a 8-bit bus. Signed-off-by: Paul Cercueil --- Notes: v2: New patch v3: No change v4: Add only MEDIA_BUS_FMT_RGB888_3X8, as we don't have to care about endianness Same comment as on version 3: You should also patch the documentation text at: Documentation/media/uapi/v4l/subdev-formats.rst In order to describe the new format that will be included. Ouch. Sorry. Will do. -Paul include/uapi/linux/media-bus-format.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index 2a6b253cfb05..16c1fa2d89a4 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -34,7 +34,7 @@ #define MEDIA_BUS_FMT_FIXED 0x0001 -/* RGB - next is 0x101c */ +/* RGB - next is 0x101d */ #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 @@ -55,6 +55,7 @@ #define MEDIA_BUS_FMT_RGB888_1X24 0x100a #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c +#define MEDIA_BUS_FMT_RGB888_3X8 0x101c #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG 0x1011 #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012 #define MEDIA_BUS_FMT_ARGB_1X32 0x100d Thanks, Mauro
Re: [PATCH 1/2] drm/panel: Add Ilitek ILI9341 parallel RGB panel driver
Hi Josef.
Thanks for the patch. A little late review follows.
Just a few thing, but please fix and resend.
Sam
> +++ b/MAINTAINERS
> @@ -4800,6 +4800,12 @@ S: Maintained
> F: drivers/gpu/drm/tinydrm/ili9225.c
> F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
>
> +DRM DRIVER FOR ILITEK ILI9341 PANELS
> +M: Josef Lusticky
> +S: Maintained
> +F: drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> +F: Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> +
> DRM DRIVER FOR HX8357D PANELS
> M: Eric Anholt
> T: git git://anongit.freedesktop.org/drm/drm-misc
I recall entries in MAINTAINERS are supposed to be ordred alphabitically
after their title. So this needs to be fixed (H comes before I)
>
> +config DRM_PANEL_ILITEK_IL9341
> + tristate "Ilitek ILI9341 240x320 panels"
> + depends on OF && SPI
> + help
> + Say Y here if you want to enable support for Ilitek IL9341
> + QVGA (240x320) RGB panel.
The panel uses backlight - should it depens on BACKLIGHT?
> +
> config DRM_PANEL_ILITEK_ILI9881C
> tristate "Ilitek ILI9881C-based panels"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index e7ab71968bbf..1df564018bc4 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
> obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
> obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
> obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
> +obj-$(CONFIG_DRM_PANEL_ILITEK_IL9341) += panel-ilitek-ili9341.o
> obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
> obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
> obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> new file mode 100644
> index ..51ed03140f8d
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> @@ -0,0 +1,320 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Ilitek ILI9341 drm_panel driver
> + * 240RGBx320 dots resolution TFT LCD display
> + *
> + * This driver support the following panel configurations:
> + * - 18-bit parallel RGB interface
> + * - 8-bit SPI with Data/Command GPIO
> + *
> + * Copyright (C) 2019 Josef Lusticky
> + *
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
Please include files in following blocks:
#include
#include
#include
This matches what other panel drivers do today.
(It was only recently made the same for all drivers)
> +
> +/* ILI9341 extended register set */
> +#define ILI9341_IFMODE 0xB0 // clock polarity
> +#define ILI9341_IFCTL 0xF6 // interface conrol
> +#define ILI9341_PGAMCTRL 0xE0 // positive gamma control
> +#define ILI9341_NGAMCTRL 0xE1 // negative gamma control
> +
> +#define ILI9341_MADCTL_MV BIT(5)
> +#define ILI9341_MADCTL_MX BIT(6)
> +#define ILI9341_MADCTL_MY BIT(7)
> +
> +/**
> + * struct ili9341_config - the display specific configuration
> + * @width_mm: physical panel width [mm]
> + * @height_mm: physical panel height [mm]
> + */
> +struct ili9341_config {
> + u32 width_mm;
> + u32 height_mm;
> +};
> +
> +struct ili9341 {
> + const struct ili9341_config *conf;
> + struct drm_panel panel;
> + struct spi_device *spi;
> + struct backlight_device *backlight;
> + struct gpio_desc *dc_gpio;
> + struct gpio_desc *reset_gpio;
> +};
No power-supply?
It is not in the binding, so likely not. But just wondering.
> +
> +static inline struct ili9341 *panel_to_ili9341(struct drm_panel *panel)
> +{
> + return container_of(panel, struct ili9341, panel);
> +}
> +
> +static int ili9341_spi_write_command(struct ili9341 *ili, u8 cmd)
> +{
> + struct spi_transfer xfer = {
> + .tx_buf = ,
> + .bits_per_word = 8,
> + .len = 1
> + };
> + struct spi_message msg;
> + spi_message_init();
> + spi_message_add_tail(, );
> +
> + gpiod_set_value(ili->dc_gpio, 0);
> +
> + return spi_sync(ili->spi, );
> +}
> +
> +static int ili9341_spi_write_data(struct ili9341 *ili, u8 *data, size_t size)
> +{
> + struct spi_transfer xfer = {
> + .tx_buf = data,
> + .bits_per_word = 8,
> + .len = size
> + };
> +
> + struct spi_message msg;
> + spi_message_init();
> + spi_message_add_tail(, );
> +
> + gpiod_set_value(ili->dc_gpio, 1);
> +
> + return spi_sync(ili->spi, );
> +}
> +
> +#define ili9341_spi_write(ili, cmd, data...) \
> +({ \
> + u8 d[] = { data }; \
> + ili9341_spi_write_command(ili, cmd); \
> + if (ARRAY_SIZE(d) > 0) \
> + ili9341_spi_write_data(ili,
Re: [PATCH 2/2] dt-bindings: panel: Add Ilitek ILI9341 panel documentation
Hi Josef.
Please follow guidelines in
Documentation/devicetree/bindings/submitting...
You will among other learn to send this patch to the right mailing list.
And please add a short summary in the changelog body.
The changelog body shall not require the reader to rtead subject to know
what the patch contains.
In next revisions, sent to the right list etc. you can add my:
Reviewed-by: Sam Ravnborg
On Tue, Feb 19, 2019 at 02:21:01PM +0100, Josef Lusticky wrote:
> ---
> .../bindings/display/panel/ilitek,ili9341.txt | 33 +++
> 1 file changed, 33 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> new file mode 100644
> index ..4e0e483bc12e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> @@ -0,0 +1,33 @@
> +Ilitek ILI9341 TFT panel driver with SPI control bus
> +
> +This is a driver for 240x320 TFT panels with parallel RGB color input.
> +
> +Required properties:
> + - compatible: "displaytech,dt024ctft", "ilitek,ili9341"
> + - backlight: phandle of the backlight device attached to the panel
> +
> +Optional properties:
> + - dc-gpios: a GPIO spec for the Data/Command pin, see gpio/gpio.txt
> + - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt
> +
> +The panel must obey the rules for a SPI slave device as specified in
> +spi/spi-bus.txt
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in
> +media/video-interfaces.txt. This node should describe panel's video bus.
> +
> +Example:
> +
> +panel@0 {
> + compatible = "displaytech,dt024ctft", "ilitek,ili9341";
> + reg = <0>;
> + backlight = <>;
> + dc-gpios = < 4 9 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +};
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #40 from Richard Thier --- Okay... I cannot easily test more heavy games because some of them crash with the 17.x last good one (maybe because missing external S3TC or whatever, or just something similar). Will try to bisect the minor issue too however still, just to see what that is. -- 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-misc-fixes
Hi Da.*, Our slow release cycle continues, only 2 contributors since last time! The set from Helen avoids blocking in async commits and Lucas ensures the sg list is unmapped with the udmabuf. drm-misc-fixes-2019-06-05: - Allow fb changes in async commits (fixes igt failures) (Helen) - Actually unmap the scatterlist when unmapping udmabuf (Lucas) Cc: Lucas Stach Cc: Helen Koike Cheers, Sean The following changes since commit 2a3e0b716296a504d9e65fea7acb379c86fe4283: Merge tag 'imx-drm-fixes-2019-05-29' of git://git.pengutronix.de/git/pza/linux into drm-fixes (2019-05-31 09:15:25 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-06-05 for you to fetch changes up to 283f1e383e91d96fe652fad549537ae15cf31d60: udmabuf: actually unmap the scatterlist (2019-06-05 10:41:17 +0200) - Allow fb changes in async commits (fixes igt failures) (Helen) - Actually unmap the scatterlist when unmapping udmabuf (Lucas) Cc: Lucas Stach Cc: Helen Koike Helen Koike (5): drm/rockchip: fix fb references in async update drm/amd: fix fb references in async update drm/msm: fix fb references in async update drm/vc4: fix fb references in async update drm: don't block fb changes for async plane updates Lucas Stach (1): udmabuf: actually unmap the scatterlist drivers/dma-buf/udmabuf.c | 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +- drivers/gpu/drm/drm_atomic_helper.c | 22 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 4 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 51 --- drivers/gpu/drm/vc4/vc4_plane.c | 2 +- include/drm/drm_modeset_helper_vtables.h | 8 7 files changed, 53 insertions(+), 38 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #39 from Richard Thier --- First I went on to strace a bit and measure directly... 10 sec glxgears - lastfast 17.x: - 2105 ioctl calls - 6 DRM_IOCTL_RADEON_GEM_CREATE - 7 DRM_IOCTL_GEM_CLOSE 10 sec glxgears - patched 19.x: - 2916 ioctl calls - 712 DRM_IOCTL_RADEON_GEM_CREATE - 713 DRM_IOCTL_GEM_CLOSE In comparison this is the unpatched 19.x originally (10 sec): -> 12466 (any) ioctl calls -> 3111 DRM_IOCTL_RADEON_GEM_CREATE -> 3112 DRM_IOCTL_GEM_CLOSE Surely it is already an order of magnitude better now, but maybe still not as best as it should be. As I told you, when bisecting there was a point I saw this happening and it was hinting there are two issues - but one is much smaller. glxgears however runs roughly the same FPS now. Maybe things start to slow down if I run out of CPU power as glxgears don't run out now - neither tuxracer, but will try heavy things like mount: warband... it was working well before.. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110844] AMDGPU Resets and blackscreens couple minutes into any game regardless of wine/proton/native - sound keeps playing
https://bugs.freedesktop.org/show_bug.cgi?id=110844 --- Comment #5 from nathaniel.h...@protonmail.com --- (In reply to Alex Deucher from comment #4) > You said it started happening for week or two ago. What component(s) did > you update at that time? tbh I dont really know what it could have been. Im on arch and i just did a pacman -Syu. Im thinking its probably mesa or the kernel. The problem is that my gpu apparently resets while trying to play a game. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #38 from Richard Thier --- Hello everyone! While hopefully someone is testing Marek's solution as I went to test if the "minor problem" between 04ea03d99d8 and 19.x is causing a slowdown or not. Despite most of the heavy slowdown went away now, I am still unsure if the more ioctl calls in later versions (let's call it ioctl spamming) can cause a slowdown in cases or not so I plan to compare performance of more heavy games between a patched 19.x and the last working 17.x just to see how it is and maybe start bisecting from 04ea03d99d8 if there is still a slowdown. It just bugs me as a bad feeling so I want to be sure with heavier games than extreme tux racer... -- 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 1/5] dt-bindings: drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc bus
On Thu, May 02, 2019 at 03:53:32PM -0700, Douglas Anderson wrote:
> In certain situations it was seen that we could wedge up the DDC bus
> on the HDMI adapter on rk3288. The only way to unwedge was to mux one
> of the pins over to GPIO output-driven-low temporarily and then
> quickly mux back. Full details can be found in the patch
> ("drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc bus").
>
> Since unwedge requires remuxing the pins, we first need to add to the
> bindings so that we can specify what state the pins should be in for
> unwedging.
Pushed to drm-misc-next along with patch 2. I'll let Heiko land the dts patches.
Thanks!
Sean
>
> Signed-off-by: Douglas Anderson
> ---
>
> .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> index 39143424a474..8346bac81f1c 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> +++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> @@ -38,6 +38,13 @@ Optional properties
> - phys: from general PHY binding: the phandle for the PHY device.
> - phy-names: Should be "hdmi" if phys references an external phy.
>
> +Optional pinctrl entry:
> +- If you have both a "unwedge" and "default" pinctrl entry, dw_hdmi
> + will switch to the unwedge pinctrl state for 10ms if it ever gets an
> + i2c timeout. It's intended that this unwedge pinctrl entry will
> + cause the SDA line to be driven low to work around a hardware
> + errata.
> +
> Example:
>
> hdmi: hdmi@ff98 {
> --
> 2.21.0.1020.gf2820cf01a-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS
[PATCH] drm/crc-debugfs: User irqsafe spinlock in drm_crtc_add_crc_entry
We can be called from any context, we need to be prepared.
Noticed this while hacking on vkms, which calls this function from a
normal worker. Which really upsets lockdep.
Cc: Rodrigo Siqueira
Cc: Tomeu Vizoso
Cc: Emil Velikov
Cc: Benjamin Gaignard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_debugfs_crc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index 585169f0dcc5..7f35b5ba1924 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -396,8 +396,9 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool
has_frame,
struct drm_crtc_crc *crc = >crc;
struct drm_crtc_crc_entry *entry;
int head, tail;
+ unsigned long flags;
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, flags);
/* Caller may not have noticed yet that userspace has stopped reading */
if (!crc->entries) {
@@ -428,7 +429,7 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool
has_frame,
head = (head + 1) & (DRM_CRC_ENTRIES_NR - 1);
crc->head = head;
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, flags);
wake_up_interruptible(>wq);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, ttm drm-next-5.3
Hi Dave, Daniel, More new stuff for 5.3: amdgpu: - Revert timeline support until KHR is ready - Various driver reload fixes - Refactor clock handling in DC - Aux fixes for DC - Bandwidth calculation updates for DC - Fix documentation due to file rename - RAS fix - Fix race in late_init ttm: - Allow for better forward progress when there is heavy memory contention The following changes since commit 91c1ead6aee22d4595f50ba66070b94a4a8f84a9: Merge branch 'drm-next-5.3' of git://people.freedesktop.org/~agd5f/linux into drm-next (2019-05-31 10:04:39 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-5.3 for you to fetch changes up to 137a7da9255763f259351edc1a6f8d0e30ff66db: Revert "drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to amdgpu" (2019-06-05 09:54:27 -0500) Alex Deucher (3): drm/amdgpu: fix a race in GPU reset with IB test (v2) drm/amdgpu/display: Drop some new CONFIG_DRM_AMD_DC_DCN1_01 guards Revert "drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to amdgpu" Anthony Koo (2): drm/amd/display: do not power on eDP power rail early drm/amd/display: fix issues with bad AUX reply on some displays Aric Cyr (2): drm/amd/display: 3.2.32 drm/amd/display: program manual trigger only for bottom most pipe Chris Park (1): drm/amd/display: Move link functions from dc to dc_link Christian König (7): drm/ttm: Make LRU removal optional v2 drm/ttm: return immediately in case of a signal drm/ttm: remove manual placement preference drm/ttm: cleanup ttm_bo_mem_space drm/ttm: immediately move BOs to the new LRU v3 drm/ttm: fix busy memory to fail other user v10 drm/ttm: fix ttm_bo_unreserve Chunming Zhou (1): drm/amd/display: use ttm_eu_reserve_buffers instead of amdgpu_bo_reserve v2 Daniel He (1): drm/amd/display: Modified AUX_DPHY_RX_CONTROL0 Emily Deng (3): drm/amdgpu:Fix the unpin warning about csb buffer drm/amdgpu/sriov: Correct some register program method drm/amdgpu/display: Fix reload driver error Eric Bernstein (1): drm/amd/display: Refactor DIO stream encoder Eric Yang (5): drm/amd/display: make clk mgr soc specific drm/amd/display: Move CLK_BASE_INNER macro drm/amd/display: move clk_mgr files to right place drm/amd/display: Fix type of pp_smu_wm_set_range struct drm/amd/display: Refactor clk_mgr functions Eryk Brol (3): drm/amd/display: Disable audio stream only if it's currently enabled drm/amd/display: Ensure DRR triggers in BP drm/amd/display: Increase Backlight Gain Step Size Gary Kattan (1): drm/amd/display: Implement CM dealpha and bias interfaces Hugo Hu (1): drm/amd/display: Don't use ROM for output TF if GAMMA_CS_TFM_1D Ilya Bakoulin (1): drm/amd/display: Add writeback_config to VBA vars Jun Lei (1): drm/amd/display: Add min_dcfclk_mhz field to bb overrides Krunoslav Kovac (2): drm/amd/display: Add GSL source select registers drm/amd/display: CS_TFM_1D only applied post EOTF Mauro Carvalho Chehab (1): gpu: amdgpu: fix broken amdgpu_dma_buf.c references Nicholas Kazlauskas (1): drm/amd/display: Reset planes for color management changes Oak Zeng (1): drm/amdkfd: Return proper error code for gws alloc API Paul Hsieh (1): drm/amd/display: disable PSR/ABM before destroy DMCU struct Su Sung Chung (2): drm/amd/display: fix calculation of total_data_read_bandwidth drm/amd/display: fix crash on setmode when mode is close to bw limit Wenjing Liu (1): drm/amd/display: assign new stream id in dc_copy_stream xinhui pan (2): drm/amdgpu: ras injection use gpu address drm/amdgpu: cancel late_init_work before gpu reset Documentation/gpu/amdgpu.rst |4 +- drivers/gpu/drm/amd/amdgpu/amdgpu.h|2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 11 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c|2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 116 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 16 + drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 14 +- drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c |8 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c |6 +- .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c |2 +- drivers/gpu/drm/amd/display/Makefile |1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 66 +- drivers/gpu/drm/amd/display/dc/Makefile|2 +- .../gpu/drm/amd/display/dc/calcs/dcn_calc_auto.h |1 +
Re: [PATCH] drm: actually remove the newline for CRC source name.
Hi Dingchen. Thanks for the quick follow-up. On Wed, Jun 05, 2019 at 02:35:56PM -0400, Dingchen Zhang wrote: > 'n-1' is the index to replace the newline character of CRC source name. subject is much better now. It would be fine if the body of the changelog conveyed the same message. The body explains what the patch does, it is better to focus on why the patch does what is do. So maybe a short explanation that userspace may transfer a newine, and that this terminating newline is replaced by a '\0' to avoid followup isses. > > Cc: Leo Li > Cc: Harry Wentland Please add a space after the name, before the '<'. This is also suggested by checkpatch.pl. > Signed-off-by: Dingchen Zhang > --- > drivers/gpu/drm/drm_debugfs_crc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c > b/drivers/gpu/drm/drm_debugfs_crc.c > index 585169f0dcc5..e20adef9d623 100644 > --- a/drivers/gpu/drm/drm_debugfs_crc.c > +++ b/drivers/gpu/drm/drm_debugfs_crc.c > @@ -131,8 +131,8 @@ static ssize_t crc_control_write(struct file *file, const > char __user *ubuf, > if (IS_ERR(source)) > return PTR_ERR(source); > > - if (source[len] == '\n') > - source[len] = '\0'; > + if (source[len-1] == '\n') > + source[len-1] = '\0'; You did not add spaces around operators as requested. Whith the above things fixed: Reviewed-by: Sam Ravnborg > > ret = crtc->funcs->verify_crc_source(crtc, source, _cnt); > if (ret) > -- > 2.17.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/panfrost: make devfreq optional again
On Wed, 2019-06-05 at 17:02 +0200, Neil Armstrong wrote:
> Devfreq runtime usage was made mandatory, thus making panfrost fail to probe
> on Amlogic S912 SoCs missing the "operating-points-v2" property.
> Make it optional again, leaving PM_DEVFREQ selected by default.
>
> Fixes: f3617b449d ("drm/panfrost: Select devfreq")
> Signed-off-by: Neil Armstrong
Reviewed-by: Ezequiel Garcia
Thanks for the fix,
Eze
> ---
> Changes since v1:
> - fixed else/if logic in panfrost_devfreq_init
>
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 29fcffdf2d57..db798532b0b6 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -140,7 +140,9 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
> return 0;
>
> ret = dev_pm_opp_of_add_table(>pdev->dev);
> - if (ret)
> + if (ret == -ENODEV) /* Optional, continue without devfreq */
> + return 0;
> + else if (ret)
> return ret;
>
> panfrost_devfreq_reset(pfdev);
> @@ -170,6 +172,9 @@ void panfrost_devfreq_resume(struct panfrost_device
> *pfdev)
> {
> int i;
>
> + if (!pfdev->devfreq.devfreq)
> + return;
> +
> panfrost_devfreq_reset(pfdev);
> for (i = 0; i < NUM_JOB_SLOTS; i++)
> pfdev->devfreq.slot[i].busy = false;
> @@ -179,6 +184,9 @@ void panfrost_devfreq_resume(struct panfrost_device
> *pfdev)
>
> void panfrost_devfreq_suspend(struct panfrost_device *pfdev)
> {
> + if (!pfdev->devfreq.devfreq)
> + return;
> +
> devfreq_suspend_device(pfdev->devfreq.devfreq);
> }
>
> @@ -188,6 +196,9 @@ static void panfrost_devfreq_update_utilization(struct
> panfrost_device *pfdev, i
> ktime_t now;
> ktime_t last;
>
> + if (!pfdev->devfreq.devfreq)
> + return;
> +
> now = ktime_get();
> last = pfdev->devfreq.slot[slot].time_last_update;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panfrost: Require the simple_ondemand governor
Panfrost depends on the simple_ondemand governor, and therefore
it's a required configuration. Select it.
Fixes: f3617b449d ("drm/panfrost: Select devfreq")
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/panfrost/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/Kconfig b/drivers/gpu/drm/panfrost/Kconfig
index 81963e964b0f..86cdc0ce79e6 100644
--- a/drivers/gpu/drm/panfrost/Kconfig
+++ b/drivers/gpu/drm/panfrost/Kconfig
@@ -10,6 +10,7 @@ config DRM_PANFROST
select IOMMU_IO_PGTABLE_LPAE
select DRM_GEM_SHMEM_HELPER
select PM_DEVFREQ
+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
help
DRM driver for ARM Mali Midgard (T6xx, T7xx, T8xx) and
Bifrost (G3x, G5x, G7x) GPUs.
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] drm/r128: drop use of drmP.h
On Wed, Jun 05, 2019 at 06:47:44PM +0200, Daniel Vetter wrote: > On Wed, Jun 05, 2019 at 04:13:21PM +0200, Sam Ravnborg wrote: > > Drop use of the deprecated drmP.h header file. > > Replace it with relevant include files. > > Sort include files in files touched. > > > > Signed-off-by: Sam Ravnborg > > Cc: David Airlie > > Cc: Daniel Vetter > > On both patches: > > Reviewed-by: Daniel Vetter Thanks, pushed to drm-misc-next. Still a long way to go: $ cd drivers/gpu/drm $ git grep drmP | wc -l 492 So who is it that today uses drmP - list the 15 largest users: (There are likely smarter ways to count it, but this works for me) $ git grep drmP | cut -d '/' -f 1 | uniq -c | sort -n | tail -n 15 8 arm 8 via 8 xen 9 udl 10 virtio 11 meson 12 mediatek 13 vmwgfx 15 rockchip 16 sti 18 sun4i 24 exynos 27 nouveau 103 radeon 110 amd nouveau is already done, pending merge from their tree. sti and exynos awaits review feedback. So this is another 67 uses gone. When insanity hits me again I will try to focus on the unmaintained parts. Assuming someone else care about the maintained parts and will follow the example. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: actually remove the newline for CRC source name.
'n-1' is the index to replace the newline character of CRC source name. Cc: Leo Li Cc: Harry Wentland Signed-off-by: Dingchen Zhang --- drivers/gpu/drm/drm_debugfs_crc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c index 585169f0dcc5..e20adef9d623 100644 --- a/drivers/gpu/drm/drm_debugfs_crc.c +++ b/drivers/gpu/drm/drm_debugfs_crc.c @@ -131,8 +131,8 @@ static ssize_t crc_control_write(struct file *file, const char __user *ubuf, if (IS_ERR(source)) return PTR_ERR(source); - if (source[len] == '\n') - source[len] = '\0'; + if (source[len-1] == '\n') + source[len-1] = '\0'; ret = crtc->funcs->verify_crc_source(crtc, source, _cnt); if (ret) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/i915/dsi: Move vlv/icl_dphy_param_init call out of intel_dsi_vbt_init (v2)
On Wed, Jun 05, 2019 at 08:17:34PM +0200, Hans de Goede wrote:
> The vlv/icl_dphy_param_init calls do various calculations to set dphy
> parameters based on the pclk.
>
> Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
> vlv_dsi_init a chance to tweak the pclk before these calculations are done.
>
> Changes in v2:
> -Also moves the icl and vlv specific dphy_param_init functions from the
> generic intel_dsi_vbt.c file into the icl_ and vlv_dsi.c specific files.
>
> Note icl_dphy_param_init() and vlv_dphy_param_init() are only moved,
> otherwise they are completely unchanged.
>
> Signed-off-by: Hans de Goede
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 108 ++
> drivers/gpu/drm/i915/intel_dsi.h | 1 +
> drivers/gpu/drm/i915/intel_dsi_vbt.c | 282 +--
> drivers/gpu/drm/i915/vlv_dsi.c | 170
> 4 files changed, 280 insertions(+), 281 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index 9d962ea1e635..511c76e788ef 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1363,6 +1363,113 @@ static const struct mipi_dsi_host_ops
> gen11_dsi_host_ops = {
> .transfer = gen11_dsi_host_transfer,
> };
>
> +#define ICL_PREPARE_CNT_MAX 0x7
> +#define ICL_CLK_ZERO_CNT_MAX 0xf
> +#define ICL_TRAIL_CNT_MAX0x7
> +#define ICL_TCLK_PRE_CNT_MAX 0x3
> +#define ICL_TCLK_POST_CNT_MAX0x7
> +#define ICL_HS_ZERO_CNT_MAX 0xf
> +#define ICL_EXIT_ZERO_CNT_MAX0x7
> +
> +static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
> +{
> + struct drm_device *dev = intel_dsi->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
> + u32 tlpx_ns;
> + u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
> + u32 ths_prepare_ns, tclk_trail_ns;
> + u32 hs_zero_cnt;
> + u32 tclk_pre_cnt, tclk_post_cnt;
> +
> + tlpx_ns = intel_dsi_tlpx_ns(intel_dsi);
> +
> + tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail);
> + ths_prepare_ns = max(mipi_config->ths_prepare,
> + mipi_config->tclk_prepare);
> +
> + /*
> + * prepare cnt in escape clocks
> + * this field represents a hexadecimal value with a precision
> + * of 1.2 – i.e. the most significant bit is the integer
> + * and the least significant 2 bits are fraction bits.
> + * so, the field can represent a range of 0.25 to 1.75
> + */
> + prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * 4, tlpx_ns);
> + if (prepare_cnt > ICL_PREPARE_CNT_MAX) {
> + DRM_DEBUG_KMS("prepare_cnt out of range (%d)\n", prepare_cnt);
> + prepare_cnt = ICL_PREPARE_CNT_MAX;
> + }
> +
> + /* clk zero count in escape clocks */
> + clk_zero_cnt = DIV_ROUND_UP(mipi_config->tclk_prepare_clkzero -
> + ths_prepare_ns, tlpx_ns);
> + if (clk_zero_cnt > ICL_CLK_ZERO_CNT_MAX) {
> + DRM_DEBUG_KMS("clk_zero_cnt out of range (%d)\n", clk_zero_cnt);
> + clk_zero_cnt = ICL_CLK_ZERO_CNT_MAX;
> + }
> +
> + /* trail cnt in escape clocks*/
> + trail_cnt = DIV_ROUND_UP(tclk_trail_ns, tlpx_ns);
> + if (trail_cnt > ICL_TRAIL_CNT_MAX) {
> + DRM_DEBUG_KMS("trail_cnt out of range (%d)\n", trail_cnt);
> + trail_cnt = ICL_TRAIL_CNT_MAX;
> + }
> +
> + /* tclk pre count in escape clocks */
> + tclk_pre_cnt = DIV_ROUND_UP(mipi_config->tclk_pre, tlpx_ns);
> + if (tclk_pre_cnt > ICL_TCLK_PRE_CNT_MAX) {
> + DRM_DEBUG_KMS("tclk_pre_cnt out of range (%d)\n", tclk_pre_cnt);
> + tclk_pre_cnt = ICL_TCLK_PRE_CNT_MAX;
> + }
> +
> + /* tclk post count in escape clocks */
> + tclk_post_cnt = DIV_ROUND_UP(mipi_config->tclk_post, tlpx_ns);
> + if (tclk_post_cnt > ICL_TCLK_POST_CNT_MAX) {
> + DRM_DEBUG_KMS("tclk_post_cnt out of range (%d)\n",
> tclk_post_cnt);
> + tclk_post_cnt = ICL_TCLK_POST_CNT_MAX;
> + }
> +
> + /* hs zero cnt in escape clocks */
> + hs_zero_cnt = DIV_ROUND_UP(mipi_config->ths_prepare_hszero -
> +ths_prepare_ns, tlpx_ns);
> + if (hs_zero_cnt > ICL_HS_ZERO_CNT_MAX) {
> + DRM_DEBUG_KMS("hs_zero_cnt out of range (%d)\n", hs_zero_cnt);
> + hs_zero_cnt = ICL_HS_ZERO_CNT_MAX;
> + }
> +
> + /* hs exit zero cnt in escape clocks */
> + exit_zero_cnt = DIV_ROUND_UP(mipi_config->ths_exit, tlpx_ns);
> + if (exit_zero_cnt > ICL_EXIT_ZERO_CNT_MAX) {
> + DRM_DEBUG_KMS("exit_zero_cnt out of range (%d)\n",
> exit_zero_cnt);
> + exit_zero_cnt = ICL_EXIT_ZERO_CNT_MAX;
> + }
> +
> + /* clock lane dphy timings */
> + intel_dsi->dphy_reg = (CLK_PREPARE_OVERRIDE |
> +
Re: [PATCH v1 2/2] drm/savage: drop use of drmP.h
On Wed, Jun 05, 2019 at 06:44:53PM +0200, Daniel Vetter wrote: > On Wed, Jun 05, 2019 at 04:03:14PM +0200, Sam Ravnborg wrote: > > Drop use of the deprecated drmP.h header file. > > Replace it with the necessary includes of other headers. > > > > Signed-off-by: Sam Ravnborg > > Cc: David Airlie > > Cc: Daniel Vetter > > Assuming it all compiles still, on the series: > > Reviewed-by: Daniel Vetter Thanks, pushed to drm-misc-next now. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: not to read outside the boundary for CRC source name.
Thanks for the reply, Sam. On 2019-06-05 1:50 p.m., Sam Ravnborg wrote: > Hi Dingchen. > > Thanks for the patch! > > On Wed, Jun 05, 2019 at 01:06:38PM -0400, Dingchen Zhang wrote: >> 'n-1' is the index to access the last character of CRC source name. >> >> Cc:Leo Li , Harry Wentland > Please add only one person (mail address) per Cc: line > > I dunno if this is a hard rule, but this is what we always do. > >> Signed-off-by: Dingchen Zhang >> --- >> drivers/gpu/drm/drm_debugfs_crc.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c >> b/drivers/gpu/drm/drm_debugfs_crc.c >> index 585169f0dcc5..e20adef9d623 100644 >> --- a/drivers/gpu/drm/drm_debugfs_crc.c >> +++ b/drivers/gpu/drm/drm_debugfs_crc.c >> @@ -131,8 +131,8 @@ static ssize_t crc_control_write(struct file *file, >> const char __user *ubuf, >> if (IS_ERR(source)) >> return PTR_ERR(source); >> >> -if (source[len] == '\n') >> -source[len] = '\0'; >> +if (source[len-1] == '\n') >> +source[len-1] = '\0'; > In the kernel code we add spaces around operators. > So the above should be: source[len - 1] > > Details aside. > memdup_user_nul() which is called gurantee that the buffer is null > terminated. The buffer allocated is len + 1 and the last byte in the > buffer is set to '\0' in memdup_user_nul(). > > So the right fix is to kill the two lines since they have no effect. > Could you please verify my analysis, and if you agree submit a new > patch. > > Thanks, > Sam You are right the buffer is null terminated at 'len+1'th. However, the patch is to actually remove the new line character. For example, if you type 'echo "abcd" > /sys/kernel/debugfs/dri/0/crtc-x/crc/control' in debugfs, the 'len' here is 5, where the 5th is the new line. I will submit a new patch with a clear title and modify the format. Thanks, Dingchen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/1] drm/sis: drop drmP.h use
On Wed, Jun 05, 2019 at 06:43:10PM +0200, Daniel Vetter wrote:
> On Wed, Jun 05, 2019 at 03:55:39PM +0200, Sam Ravnborg wrote:
> > Drop use of the deprecated drmP.h header.
> > Repalced with relevant header files and sorted header files in all files
> > touched.
> >
> > Replaced DRM_{READ,WRITE} to avoid the drm_os_linux header.
> >
> > Build tested with allyesconfig, allmodconfig on various architectures.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: David Airlie
> > Cc: Daniel Vetter
>
> Reviewed-by: Daniel Vetter
Thanks, pushed to drm-misc-next
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-5.2
Hi Dave, Daniel, Fixes for 5.2: - A fix to make VCE resume more reliable - Updates for new raven variants The following changes since commit 2a3e0b716296a504d9e65fea7acb379c86fe4283: Merge tag 'imx-drm-fixes-2019-05-29' of git://git.pengutronix.de/git/pza/linux into drm-fixes (2019-05-31 09:15:25 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-5.2 for you to fetch changes up to 1929059893022a3bbed43934c7313e66aad7346b: drm/amd/amdgpu: add RLC firmware to support raven1 refresh (2019-06-05 11:14:15 -0500) Chengming Gui (1): drm/amd/powerplay: add set_power_profile_mode for raven1_refresh Louis Li (1): drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2) Prike Liang (1): drm/amd/amdgpu: add RLC firmware to support raven1 refresh drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 12 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 15 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 4 ++- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 12 - drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c | 1 + drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 31 --- drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 + 8 files changed, 63 insertions(+), 14 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/i915/dsi: Move vlv/icl_dphy_param_init call out of intel_dsi_vbt_init (v2)
The vlv/icl_dphy_param_init calls do various calculations to set dphy
parameters based on the pclk.
Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
vlv_dsi_init a chance to tweak the pclk before these calculations are done.
Changes in v2:
-Also moves the icl and vlv specific dphy_param_init functions from the
generic intel_dsi_vbt.c file into the icl_ and vlv_dsi.c specific files.
Note icl_dphy_param_init() and vlv_dphy_param_init() are only moved,
otherwise they are completely unchanged.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/icl_dsi.c | 108 ++
drivers/gpu/drm/i915/intel_dsi.h | 1 +
drivers/gpu/drm/i915/intel_dsi_vbt.c | 282 +--
drivers/gpu/drm/i915/vlv_dsi.c | 170
4 files changed, 280 insertions(+), 281 deletions(-)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 9d962ea1e635..511c76e788ef 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1363,6 +1363,113 @@ static const struct mipi_dsi_host_ops
gen11_dsi_host_ops = {
.transfer = gen11_dsi_host_transfer,
};
+#define ICL_PREPARE_CNT_MAX0x7
+#define ICL_CLK_ZERO_CNT_MAX 0xf
+#define ICL_TRAIL_CNT_MAX 0x7
+#define ICL_TCLK_PRE_CNT_MAX 0x3
+#define ICL_TCLK_POST_CNT_MAX 0x7
+#define ICL_HS_ZERO_CNT_MAX0xf
+#define ICL_EXIT_ZERO_CNT_MAX 0x7
+
+static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
+{
+ struct drm_device *dev = intel_dsi->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
+ u32 tlpx_ns;
+ u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
+ u32 ths_prepare_ns, tclk_trail_ns;
+ u32 hs_zero_cnt;
+ u32 tclk_pre_cnt, tclk_post_cnt;
+
+ tlpx_ns = intel_dsi_tlpx_ns(intel_dsi);
+
+ tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail);
+ ths_prepare_ns = max(mipi_config->ths_prepare,
+mipi_config->tclk_prepare);
+
+ /*
+* prepare cnt in escape clocks
+* this field represents a hexadecimal value with a precision
+* of 1.2 – i.e. the most significant bit is the integer
+* and the least significant 2 bits are fraction bits.
+* so, the field can represent a range of 0.25 to 1.75
+*/
+ prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * 4, tlpx_ns);
+ if (prepare_cnt > ICL_PREPARE_CNT_MAX) {
+ DRM_DEBUG_KMS("prepare_cnt out of range (%d)\n", prepare_cnt);
+ prepare_cnt = ICL_PREPARE_CNT_MAX;
+ }
+
+ /* clk zero count in escape clocks */
+ clk_zero_cnt = DIV_ROUND_UP(mipi_config->tclk_prepare_clkzero -
+ ths_prepare_ns, tlpx_ns);
+ if (clk_zero_cnt > ICL_CLK_ZERO_CNT_MAX) {
+ DRM_DEBUG_KMS("clk_zero_cnt out of range (%d)\n", clk_zero_cnt);
+ clk_zero_cnt = ICL_CLK_ZERO_CNT_MAX;
+ }
+
+ /* trail cnt in escape clocks*/
+ trail_cnt = DIV_ROUND_UP(tclk_trail_ns, tlpx_ns);
+ if (trail_cnt > ICL_TRAIL_CNT_MAX) {
+ DRM_DEBUG_KMS("trail_cnt out of range (%d)\n", trail_cnt);
+ trail_cnt = ICL_TRAIL_CNT_MAX;
+ }
+
+ /* tclk pre count in escape clocks */
+ tclk_pre_cnt = DIV_ROUND_UP(mipi_config->tclk_pre, tlpx_ns);
+ if (tclk_pre_cnt > ICL_TCLK_PRE_CNT_MAX) {
+ DRM_DEBUG_KMS("tclk_pre_cnt out of range (%d)\n", tclk_pre_cnt);
+ tclk_pre_cnt = ICL_TCLK_PRE_CNT_MAX;
+ }
+
+ /* tclk post count in escape clocks */
+ tclk_post_cnt = DIV_ROUND_UP(mipi_config->tclk_post, tlpx_ns);
+ if (tclk_post_cnt > ICL_TCLK_POST_CNT_MAX) {
+ DRM_DEBUG_KMS("tclk_post_cnt out of range (%d)\n",
tclk_post_cnt);
+ tclk_post_cnt = ICL_TCLK_POST_CNT_MAX;
+ }
+
+ /* hs zero cnt in escape clocks */
+ hs_zero_cnt = DIV_ROUND_UP(mipi_config->ths_prepare_hszero -
+ ths_prepare_ns, tlpx_ns);
+ if (hs_zero_cnt > ICL_HS_ZERO_CNT_MAX) {
+ DRM_DEBUG_KMS("hs_zero_cnt out of range (%d)\n", hs_zero_cnt);
+ hs_zero_cnt = ICL_HS_ZERO_CNT_MAX;
+ }
+
+ /* hs exit zero cnt in escape clocks */
+ exit_zero_cnt = DIV_ROUND_UP(mipi_config->ths_exit, tlpx_ns);
+ if (exit_zero_cnt > ICL_EXIT_ZERO_CNT_MAX) {
+ DRM_DEBUG_KMS("exit_zero_cnt out of range (%d)\n",
exit_zero_cnt);
+ exit_zero_cnt = ICL_EXIT_ZERO_CNT_MAX;
+ }
+
+ /* clock lane dphy timings */
+ intel_dsi->dphy_reg = (CLK_PREPARE_OVERRIDE |
+ CLK_PREPARE(prepare_cnt) |
+ CLK_ZERO_OVERRIDE |
+ CLK_ZERO(clk_zero_cnt) |
+ CLK_PRE_OVERRIDE |
+
[PATCH 1/3] drm/i915/dsi: Move logging of DSI VBT parameters to a helper function
This is a preparation patch for moving the calling of *_dphy_param_init()
out of intel_dsi_vbt_init.
Reviewed-by: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 77 +++-
1 file changed, 42 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 4b8e48db1843..3a187ffabfbd 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -532,6 +532,44 @@ void intel_dsi_msleep(struct intel_dsi *intel_dsi, int
msec)
msleep(msec);
}
+static void intel_dsi_log_params(struct intel_dsi *intel_dsi)
+{
+ DRM_DEBUG_KMS("Pclk %d\n", intel_dsi->pclk);
+ DRM_DEBUG_KMS("Pixel overlap %d\n", intel_dsi->pixel_overlap);
+ DRM_DEBUG_KMS("Lane count %d\n", intel_dsi->lane_count);
+ DRM_DEBUG_KMS("DPHY param reg 0x%x\n", intel_dsi->dphy_reg);
+ DRM_DEBUG_KMS("Video mode format %s\n",
+ intel_dsi->video_mode_format ==
VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE ?
+ "non-burst with sync pulse" :
+ intel_dsi->video_mode_format ==
VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS ?
+ "non-burst with sync events" :
+ intel_dsi->video_mode_format == VIDEO_MODE_BURST ?
+ "burst" : "");
+ DRM_DEBUG_KMS("Burst mode ratio %d\n", intel_dsi->burst_mode_ratio);
+ DRM_DEBUG_KMS("Reset timer %d\n", intel_dsi->rst_timer_val);
+ DRM_DEBUG_KMS("Eot %s\n", enableddisabled(intel_dsi->eotp_pkt));
+ DRM_DEBUG_KMS("Clockstop %s\n",
enableddisabled(!intel_dsi->clock_stop));
+ DRM_DEBUG_KMS("Mode %s\n", intel_dsi->operation_mode ? "command" :
"video");
+ if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK)
+ DRM_DEBUG_KMS("Dual link: DSI_DUAL_LINK_FRONT_BACK\n");
+ else if (intel_dsi->dual_link == DSI_DUAL_LINK_PIXEL_ALT)
+ DRM_DEBUG_KMS("Dual link: DSI_DUAL_LINK_PIXEL_ALT\n");
+ else
+ DRM_DEBUG_KMS("Dual link: NONE\n");
+ DRM_DEBUG_KMS("Pixel Format %d\n", intel_dsi->pixel_format);
+ DRM_DEBUG_KMS("TLPX %d\n", intel_dsi->escape_clk_div);
+ DRM_DEBUG_KMS("LP RX Timeout 0x%x\n", intel_dsi->lp_rx_timeout);
+ DRM_DEBUG_KMS("Turnaround Timeout 0x%x\n", intel_dsi->turn_arnd_val);
+ DRM_DEBUG_KMS("Init Count 0x%x\n", intel_dsi->init_count);
+ DRM_DEBUG_KMS("HS to LP Count 0x%x\n", intel_dsi->hs_to_lp_count);
+ DRM_DEBUG_KMS("LP Byte Clock %d\n", intel_dsi->lp_byte_clk);
+ DRM_DEBUG_KMS("DBI BW Timer 0x%x\n", intel_dsi->bw_timer);
+ DRM_DEBUG_KMS("LP to HS Clock Count 0x%x\n",
intel_dsi->clk_lp_to_hs_count);
+ DRM_DEBUG_KMS("HS to LP Clock Count 0x%x\n",
intel_dsi->clk_hs_to_lp_count);
+ DRM_DEBUG_KMS("BTA %s\n",
+ enableddisabled(!(intel_dsi->video_frmt_cfg_bits &
DISABLE_VIDEO_BTA)));
+}
+
#define ICL_PREPARE_CNT_MAX0x7
#define ICL_CLK_ZERO_CNT_MAX 0xf
#define ICL_TRAIL_CNT_MAX 0x7
@@ -635,6 +673,8 @@ static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
HS_TRAIL(trail_cnt) |
HS_EXIT_OVERRIDE |
HS_EXIT(exit_zero_cnt));
+
+ intel_dsi_log_params(intel_dsi);
}
static void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
@@ -794,6 +834,8 @@ static void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
DIV_ROUND_UP(2 * tlpx_ui + trail_cnt * 2 + 8,
8);
intel_dsi->clk_hs_to_lp_count += extra_byte_count;
+
+ intel_dsi_log_params(intel_dsi);
}
bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id)
@@ -888,41 +930,6 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
else
vlv_dphy_param_init(intel_dsi);
- DRM_DEBUG_KMS("Pclk %d\n", intel_dsi->pclk);
- DRM_DEBUG_KMS("Pixel overlap %d\n", intel_dsi->pixel_overlap);
- DRM_DEBUG_KMS("Lane count %d\n", intel_dsi->lane_count);
- DRM_DEBUG_KMS("DPHY param reg 0x%x\n", intel_dsi->dphy_reg);
- DRM_DEBUG_KMS("Video mode format %s\n",
- intel_dsi->video_mode_format ==
VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE ?
- "non-burst with sync pulse" :
- intel_dsi->video_mode_format ==
VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS ?
- "non-burst with sync events" :
- intel_dsi->video_mode_format == VIDEO_MODE_BURST ?
- "burst" : "");
- DRM_DEBUG_KMS("Burst mode ratio %d\n", intel_dsi->burst_mode_ratio);
- DRM_DEBUG_KMS("Reset timer %d\n", intel_dsi->rst_timer_val);
- DRM_DEBUG_KMS("Eot %s\n", enableddisabled(intel_dsi->eotp_pkt));
- DRM_DEBUG_KMS("Clockstop %s\n",
enableddisabled(!intel_dsi->clock_stop));
-
[PATCH 3/3] drm/i915/dsi: Read back pclk set by GOP and use that as pclk (v3)
The GOP sometimes initializes the pclk at a (slightly) different frequency
then the pclk which we've calculated.
This commit makes the DSI code read-back the pclk set by the GOP and
if that is within a reasonable margin of the calculated pclk, uses
that instead.
This fixes the first modeset being a full modeset instead of a
fast modeset on systems where the GOP pclk is different.
Changes in v2:
-Use intel_encoder_current_mode() to get the pclk setup by the GOP
Changes in v3:
-Back to the readback approach, skipping the dsi_pll.ctrl / .dev checks
in intel_pipe_config_compare() when adjust is set leads to:
[drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.ctrl (...)
[drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.div (...)
-Do the readback and pclk overriding from vlv_dsi_init(), rather then from
intel_dsi_vbt_init() as the vbt code should not be touching the hw
Reviewed-by: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/vlv_dsi.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index 59500c838b9d..6d96891984a5 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1865,7 +1865,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
struct drm_encoder *encoder;
struct intel_connector *intel_connector;
struct drm_connector *connector;
- struct drm_display_mode *fixed_mode;
+ struct drm_display_mode *current_mode, *fixed_mode;
enum port port;
DRM_DEBUG_KMS("\n");
@@ -1909,6 +1909,9 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
intel_connector->get_hw_state = intel_connector_get_hw_state;
intel_encoder->port = port;
+ intel_encoder->type = INTEL_OUTPUT_DSI;
+ intel_encoder->power_domain = POWER_DOMAIN_PORT_DSI;
+ intel_encoder->cloneable = 0;
/*
* On BYT/CHV, pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI
@@ -1946,6 +1949,20 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
+ /* Use clock read-back from current hw-state for fastboot */
+ current_mode = intel_encoder_current_mode(intel_encoder);
+ if (current_mode) {
+ DRM_DEBUG_KMS("Calculated pclk %d GOP %d\n",
+ intel_dsi->pclk, current_mode->clock);
+ if (intel_fuzzy_clock_check(intel_dsi->pclk,
+ current_mode->clock)) {
+ DRM_DEBUG_KMS("Using GOP pclk\n");
+ intel_dsi->pclk = current_mode->clock;
+ }
+
+ kfree(current_mode);
+ }
+
vlv_dphy_param_init(intel_dsi);
/*
@@ -1963,9 +1980,6 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
}
}
- intel_encoder->type = INTEL_OUTPUT_DSI;
- intel_encoder->power_domain = POWER_DOMAIN_PORT_DSI;
- intel_encoder->cloneable = 0;
drm_connector_init(dev, connector, _dsi_connector_funcs,
DRM_MODE_CONNECTOR_DSI);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/i915/dsi: Move vlv/icl_dphy_param_init call out of intel_dsi_vbt_init
Hi,
On 04-06-19 19:35, Ville Syrjälä wrote:
On Fri, May 24, 2019 at 06:30:19PM +0200, Hans de Goede wrote:
The vlv/icl_dphy_param_init calls do various calculations to set dphy
parameters based on the pclk.
Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
vlv_dsi_init a chance to tweak the pclk before these calculations are done.
This also removes the single "if (IS_ICELAKE(dev_priv))" check from
intel_dsi_vbt_init making it fully platform agnostic.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/icl_dsi.c | 1 +
drivers/gpu/drm/i915/intel_dsi.h | 2 ++
drivers/gpu/drm/i915/intel_dsi_vbt.c | 9 ++---
drivers/gpu/drm/i915/vlv_dsi.c | 2 ++
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 9d962ea1e635..0f43ef07efec 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1455,6 +1455,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
+ icl_dphy_param_init(intel_dsi);
I think we should move the entire function into this file.
I was thinking the same thing when I was writing the patch, but I was
not 100% sure. I'm glad that you think the same, I will post a
new version with this fixed (both of them).
Regards,
Hans
return;
err:
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 705a609050c0..a58d3d988d9f 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -192,5 +192,7 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id);
void intel_dsi_vbt_exec_sequence(struct intel_dsi *intel_dsi,
enum mipi_seq seq_id);
void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec);
+void icl_dphy_param_init(struct intel_dsi *intel_dsi);
+void vlv_dphy_param_init(struct intel_dsi *intel_dsi);
#endif /* _INTEL_DSI_H */
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 3448e8d51057..022bf59418df 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -578,7 +578,7 @@ static void intel_dsi_log_params(struct intel_dsi
*intel_dsi)
#define ICL_HS_ZERO_CNT_MAX 0xf
#define ICL_EXIT_ZERO_CNT_MAX 0x7
-static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
+void icl_dphy_param_init(struct intel_dsi *intel_dsi)
{
struct drm_device *dev = intel_dsi->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -677,7 +677,7 @@ static void icl_dphy_param_init(struct intel_dsi *intel_dsi)
intel_dsi_log_params(intel_dsi);
}
-static void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
+void vlv_dphy_param_init(struct intel_dsi *intel_dsi)
{
struct drm_device *dev = intel_dsi->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -914,11 +914,6 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
intel_dsi->burst_mode_ratio = burst_mode_ratio;
- if (INTEL_GEN(dev_priv) >= 11)
- icl_dphy_param_init(intel_dsi);
- else
- vlv_dphy_param_init(intel_dsi);
-
/* delays in VBT are in unit of 100us, so need to convert
* here in ms
* Delay (100us) * 100 /1000 = Delay / 10 (ms) */
diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index fce8b58f7f93..3329ccf3b346 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1782,6 +1782,8 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
+ vlv_dphy_param_init(intel_dsi);
ditto
+
/*
* In case of BYT with CRC PMIC, we need to use GPIO for
* Panel control.
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110845] [DC-only][regression] cannot select full refresh rate on 5.2rc - 144Hz 2560x1440
https://bugs.freedesktop.org/show_bug.cgi?id=110845 --- Comment #3 from Matt Coffin --- Thanks. I will test tonight with the patch applied when I have access to an AMD card. -- 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] drm/ttm: fix ttm_bo_unreserve
Am 05.06.19 um 16:33 schrieb Kuehling, Felix:
> On 2019-06-05 9:56, Michel Dänzer wrote:
>> On 2019-06-05 1:24 p.m., Christian König wrote:
>>> Am 04.06.19 um 21:03 schrieb Zeng, Oak:
From: amd-gfx On Behalf Of
Kuehling, Felix
On 2019-06-04 11:23, Christian König wrote:
> [snip]
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -767,14 +767,12 @@ static inline int
ttm_bo_reserve_slowpath(struct ttm_buffer_object *bo,
*/
static inline void ttm_bo_unreserve(struct ttm_buffer_object *bo)
{
- if (!(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
- spin_lock(>bdev->glob->lru_lock);
- if (list_empty(>lru))
- ttm_bo_add_to_lru(bo);
- else
- ttm_bo_move_to_lru_tail(bo, NULL);
- spin_unlock(>bdev->glob->lru_lock);
- }
+ spin_lock(>bdev->glob->lru_lock);
+ if (list_empty(>lru))
+ ttm_bo_add_to_lru(bo);
+ else
+ ttm_bo_move_to_lru_tail(bo, NULL);
Going just by the function names, this seems to do the exact opposite
of what the change description says.
[Oak] +1, when I read the description, I also get lost...So please do
add a more accurate description.
>>> I'm puzzled why you are confused. We now keep the BOs on the LRU while
>>> they are reserved, so on unreserve we now need to explicitly remove them
>>> from the LRU when they are pinned.
>> I don't know about Felix and Oak, but for me "remove from the LRU" is
>> confusing, as I don't see that in the code, only adding to the LRU or
>> moving to its tail.
> Exactly. The names of the functions being called imply that something
> gets added or moved on the LRU list. You have to go look at the
> implementation of those functions to find out that they do something
> else for pinned BOs (that have TTM_PL_FLAG_NO_EVICT set in their
> placement flags).
>
> Fixing the function names would probably be overkill:
> ttm_bo_add_lru_unless_pinned and
> ttm_bo_move_to_lru_tail_or_remove_if_pinned. But maybe a comment in
> ttm_bo_unreserve would help.
Ah! Yes of course, I thought you mean the ttm_bo_unreserve function name.
Going to add a comment when we start to rename the functions.
Christian.
>
> Regards,
> Felix
>
>
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: Use devm_platform_ioremap_resource()
Use devm_platform_ioremap_resource() to simplify the code a bit.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 72d01e873160..a4ff1ee41bfa 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1711,7 +1711,6 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
{
struct device *dev = >dev;
struct etnaviv_gpu *gpu;
- struct resource *res;
int err;
gpu = devm_kzalloc(dev, sizeof(*gpu), GFP_KERNEL);
@@ -1723,8 +1722,7 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
mutex_init(>fence_lock);
/* Map registers: */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- gpu->mmio = devm_ioremap_resource(>dev, res);
+ gpu->mmio = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(gpu->mmio))
return PTR_ERR(gpu->mmio);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: Set crc->opened = false before setting crc source to NULL.
Hi Dingchen I do not know this code, so please await feedback from others on the patch itself. On Wed, Jun 05, 2019 at 01:06:39PM -0400, Dingchen Zhang wrote: > to terminate the while-loop in drm_dp_aux_crc_work when drm_dp_start/stop_crc > are called in the hook to set crc source. > > Cc:Leo Li , Harry , Nick > Only one pair of name/email per line. And try to use the full name as reported by scripts/get_maintainer.pl Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110844] AMDGPU Resets and blackscreens couple minutes into any game regardless of wine/proton/native - sound keeps playing
https://bugs.freedesktop.org/show_bug.cgi?id=110844 --- Comment #4 from Alex Deucher --- You said it started happening for week or two ago. What component(s) did you update at that time? -- 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 1/2] drm: not to read outside the boundary for CRC source name.
Hi Dingchen. Thanks for the patch! On Wed, Jun 05, 2019 at 01:06:38PM -0400, Dingchen Zhang wrote: > 'n-1' is the index to access the last character of CRC source name. > > Cc:Leo Li , Harry Wentland Please add only one person (mail address) per Cc: line I dunno if this is a hard rule, but this is what we always do. > Signed-off-by: Dingchen Zhang > --- > drivers/gpu/drm/drm_debugfs_crc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c > b/drivers/gpu/drm/drm_debugfs_crc.c > index 585169f0dcc5..e20adef9d623 100644 > --- a/drivers/gpu/drm/drm_debugfs_crc.c > +++ b/drivers/gpu/drm/drm_debugfs_crc.c > @@ -131,8 +131,8 @@ static ssize_t crc_control_write(struct file *file, const > char __user *ubuf, > if (IS_ERR(source)) > return PTR_ERR(source); > > - if (source[len] == '\n') > - source[len] = '\0'; > + if (source[len-1] == '\n') > + source[len-1] = '\0'; In the kernel code we add spaces around operators. So the above should be: source[len - 1] Details aside. memdup_user_nul() which is called gurantee that the buffer is null terminated. The buffer allocated is len + 1 and the last byte in the buffer is set to '\0' in memdup_user_nul(). So the right fix is to kill the two lines since they have no effect. Could you please verify my analysis, and if you agree submit a new patch. Thanks, Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110777] Kernel 5.1-5.2 MCLK stuck at 167MHz Vega 10 (56)
https://bugs.freedesktop.org/show_bug.cgi?id=110777 --- Comment #5 from Anton Herzfeld --- The following patch fixes the issue with boosting again: https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd/powerplay/hwmgr?h=amd-staging-drm-next=7d59c41b5150d0641203f91cfcaa0f9af5999cce however it also seems to expose the issue in mclk not going down again once it has boosted. just to clarify the issue occurs when using manual OD on mclk since kernel 5.1. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110844] AMDGPU Resets and blackscreens couple minutes into any game regardless of wine/proton/native - sound keeps playing
https://bugs.freedesktop.org/show_bug.cgi?id=110844 --- Comment #3 from nathaniel.h...@protonmail.com --- If you have any idea as to how i should narrow down the issue, im willing to try. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: Set crc->opened = false before setting crc source to NULL.
to terminate the while-loop in drm_dp_aux_crc_work when drm_dp_start/stop_crc
are called in the hook to set crc source.
Cc:Leo Li , Harry , Nick
Signed-off-by: Dingchen Zhang
---
drivers/gpu/drm/drm_debugfs_crc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index e20adef9d623..0e8bcc130383 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -249,6 +249,13 @@ static int crtc_crc_release(struct inode *inode, struct
file *filep)
struct drm_crtc *crtc = filep->f_inode->i_private;
struct drm_crtc_crc *crc = >crc;
+ /* terminate the infinite while loop if 'drm_dp_aux_crc_work' running */
+ if (crc->opened) {
+ spin_lock_irq(>lock);
+ crc->opened = false;
+ spin_unlock_irq(>lock);
+ }
+
crtc->funcs->set_crc_source(crtc, NULL);
spin_lock_irq(>lock);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: not to read outside the boundary for CRC source name.
'n-1' is the index to access the last character of CRC source name. Cc:Leo Li , Harry Wentland Signed-off-by: Dingchen Zhang --- drivers/gpu/drm/drm_debugfs_crc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c index 585169f0dcc5..e20adef9d623 100644 --- a/drivers/gpu/drm/drm_debugfs_crc.c +++ b/drivers/gpu/drm/drm_debugfs_crc.c @@ -131,8 +131,8 @@ static ssize_t crc_control_write(struct file *file, const char __user *ubuf, if (IS_ERR(source)) return PTR_ERR(source); - if (source[len] == '\n') - source[len] = '\0'; + if (source[len-1] == '\n') + source[len-1] = '\0'; ret = crtc->funcs->verify_crc_source(crtc, source, _cnt); if (ret) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110844] AMDGPU Resets and blackscreens couple minutes into any game regardless of wine/proton/native - sound keeps playing
https://bugs.freedesktop.org/show_bug.cgi?id=110844 --- Comment #2 from nathaniel.h...@protonmail.com --- (In reply to Alex Deucher from comment #1) > Can you narrow down what component (mesa, kernel, ddx) caused the issue and > bisect? I will try but I have no idea how to narrow down the issue. I could share a xorg log and maybe another journalctl. -- 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 2/2] drm/r128: drop use of drmP.h
On Wed, Jun 05, 2019 at 04:13:21PM +0200, Sam Ravnborg wrote:
> Drop use of the deprecated drmP.h header file.
> Replace it with relevant include files.
> Sort include files in files touched.
>
> Signed-off-by: Sam Ravnborg
> Cc: David Airlie
> Cc: Daniel Vetter
On both patches:
Reviewed-by: Daniel Vetter
Again r128 is unmaintained, I think you can just go ahead and push.
-Daniel
> ---
> drivers/gpu/drm/r128/r128_cce.c | 12 ++--
> drivers/gpu/drm/r128/r128_drv.c | 9 ++---
> drivers/gpu/drm/r128/r128_drv.h | 6 ++
> drivers/gpu/drm/r128/r128_state.c | 9 -
> 4 files changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/r128/r128_cce.c b/drivers/gpu/drm/r128/r128_cce.c
> index 6f426bb06934..138af32480d4 100644
> --- a/drivers/gpu/drm/r128/r128_cce.c
> +++ b/drivers/gpu/drm/r128/r128_cce.c
> @@ -29,13 +29,21 @@
> *Gareth Hughes
> */
>
> +#include
> +#include
> #include
> +#include
> #include
> #include
> -#include
> +#include
>
> -#include
> +#include
> +#include
> +#include
> +#include
> +#include
> #include
> +
> #include "r128_drv.h"
>
> #define R128_FIFO_DEBUG 0
> diff --git a/drivers/gpu/drm/r128/r128_drv.c b/drivers/gpu/drm/r128/r128_drv.c
> index 4b1a505ab353..fd74f744604f 100644
> --- a/drivers/gpu/drm/r128/r128_drv.c
> +++ b/drivers/gpu/drm/r128/r128_drv.c
> @@ -31,11 +31,14 @@
>
> #include
>
> -#include
> +#include
> +#include
> +#include
> +#include
> +#include
> #include
> -#include "r128_drv.h"
>
> -#include
> +#include "r128_drv.h"
>
> static struct pci_device_id pciidlist[] = {
> r128_PCI_IDS
> diff --git a/drivers/gpu/drm/r128/r128_drv.h b/drivers/gpu/drm/r128/r128_drv.h
> index 115bb286dd2a..ba8c30ed91d1 100644
> --- a/drivers/gpu/drm/r128/r128_drv.h
> +++ b/drivers/gpu/drm/r128/r128_drv.h
> @@ -35,8 +35,14 @@
> #ifndef __R128_DRV_H__
> #define __R128_DRV_H__
>
> +#include
> +#include
> +#include
> +
> #include
> +#include
> #include
> +#include
>
> /* General customization:
> */
> diff --git a/drivers/gpu/drm/r128/r128_state.c
> b/drivers/gpu/drm/r128/r128_state.c
> index 2535ea8d2d9b..9d74c9d914cb 100644
> --- a/drivers/gpu/drm/r128/r128_state.c
> +++ b/drivers/gpu/drm/r128/r128_state.c
> @@ -28,8 +28,15 @@
> *Gareth Hughes
> */
>
> -#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> #include
> +
> #include "r128_drv.h"
>
> /*
> --
> 2.20.1
>
--
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 v1 2/2] drm/savage: drop use of drmP.h
On Wed, Jun 05, 2019 at 04:03:14PM +0200, Sam Ravnborg wrote:
> Drop use of the deprecated drmP.h header file.
> Replace it with the necessary includes of other headers.
>
> Signed-off-by: Sam Ravnborg
> Cc: David Airlie
> Cc: Daniel Vetter
Assuming it all compiles still, on the series:
Reviewed-by: Daniel Vetter
Since sis/savage are unmaintained I think you can just go ahead and push
those.
-Daniel
> ---
> drivers/gpu/drm/savage/savage_bci.c | 8 +++-
> drivers/gpu/drm/savage/savage_drv.c | 9 +
> drivers/gpu/drm/savage/savage_drv.h | 4
> drivers/gpu/drm/savage/savage_state.c | 9 -
> 4 files changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/savage/savage_bci.c
> b/drivers/gpu/drm/savage/savage_bci.c
> index aa00cf117433..6889d6534eba 100644
> --- a/drivers/gpu/drm/savage/savage_bci.c
> +++ b/drivers/gpu/drm/savage/savage_bci.c
> @@ -24,9 +24,15 @@
> */
>
> #include
> +#include
> +#include
> +#include
>
> -#include
> +#include
> +#include
> +#include
> #include
> +
> #include "savage_drv.h"
>
> /* Need a long timeout for shadow status updates can take a while
> diff --git a/drivers/gpu/drm/savage/savage_drv.c
> b/drivers/gpu/drm/savage/savage_drv.c
> index 2bddeb8bf457..2966fcfd9548 100644
> --- a/drivers/gpu/drm/savage/savage_drv.c
> +++ b/drivers/gpu/drm/savage/savage_drv.c
> @@ -25,12 +25,13 @@
>
> #include
>
> -#include
> -#include
> -#include "savage_drv.h"
> -
> +#include
> +#include
> +#include
> #include
>
> +#include "savage_drv.h"
> +
> static struct pci_device_id pciidlist[] = {
> savage_PCI_IDS
> };
> diff --git a/drivers/gpu/drm/savage/savage_drv.h
> b/drivers/gpu/drm/savage/savage_drv.h
> index 38aab625f12e..b0081bb64776 100644
> --- a/drivers/gpu/drm/savage/savage_drv.h
> +++ b/drivers/gpu/drm/savage/savage_drv.h
> @@ -26,7 +26,11 @@
> #ifndef __SAVAGE_DRV_H__
> #define __SAVAGE_DRV_H__
>
> +#include
> +
> +#include
> #include
> +#include
>
> #define DRIVER_AUTHOR"Felix Kuehling"
>
> diff --git a/drivers/gpu/drm/savage/savage_state.c
> b/drivers/gpu/drm/savage/savage_state.c
> index ebb8b7d32b33..a2ac25c11c90 100644
> --- a/drivers/gpu/drm/savage/savage_state.c
> +++ b/drivers/gpu/drm/savage/savage_state.c
> @@ -22,8 +22,15 @@
> * CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
> * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> */
> -#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> #include
> +
> #include "savage_drv.h"
>
> void savage_emit_clip_rect_s3d(drm_savage_private_t * dev_priv,
> --
> 2.20.1
>
--
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 v1 1/1] drm/sis: drop drmP.h use
On Wed, Jun 05, 2019 at 03:55:39PM +0200, Sam Ravnborg wrote:
> Drop use of the deprecated drmP.h header.
> Repalced with relevant header files and sorted header files in all files
> touched.
>
> Replaced DRM_{READ,WRITE} to avoid the drm_os_linux header.
>
> Build tested with allyesconfig, allmodconfig on various architectures.
>
> Signed-off-by: Sam Ravnborg
> Cc: David Airlie
> Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/sis/sis_drv.c | 8 +---
> drivers/gpu/drm/sis/sis_drv.h | 10 --
> drivers/gpu/drm/sis/sis_mm.c | 7 +--
> 3 files changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/sis/sis_drv.c
> index e04a92658cd7..ee3801201ecc 100644
> --- a/drivers/gpu/drm/sis/sis_drv.c
> +++ b/drivers/gpu/drm/sis/sis_drv.c
> @@ -27,11 +27,13 @@
>
> #include
>
> -#include
> +#include
> +#include
> +#include
> +#include
> #include
> -#include "sis_drv.h"
>
> -#include
> +#include "sis_drv.h"
>
> static struct pci_device_id pciidlist[] = {
> sisdrv_PCI_IDS
> diff --git a/drivers/gpu/drm/sis/sis_drv.h b/drivers/gpu/drm/sis/sis_drv.h
> index 328f8a750976..81339443b3b1 100644
> --- a/drivers/gpu/drm/sis/sis_drv.h
> +++ b/drivers/gpu/drm/sis/sis_drv.h
> @@ -28,7 +28,9 @@
> #ifndef _SIS_DRV_H_
> #define _SIS_DRV_H_
>
> +#include
> #include
> +#include
>
> /* General customization:
> */
> @@ -46,12 +48,8 @@ enum sis_family {
> SIS_CHIP_315 = 1,
> };
>
> -#include
> -
> -
> -#define SIS_BASE (dev_priv->mmio)
> -#define SIS_READ(reg) DRM_READ32(SIS_BASE, reg)
> -#define SIS_WRITE(reg, val) DRM_WRITE32(SIS_BASE, reg, val)
> +#define SIS_READ(reg) readl(((void __iomem *)dev_priv->mmio->handle)
> + (reg))
> +#define SIS_WRITE(reg, val) writel(val, ((void __iomem
> *)dev_priv->mmio->handle) + (reg))
>
> typedef struct drm_sis_private {
> drm_local_map_t *mmio;
> diff --git a/drivers/gpu/drm/sis/sis_mm.c b/drivers/gpu/drm/sis/sis_mm.c
> index 1622db24cd39..e51d4289a3d0 100644
> --- a/drivers/gpu/drm/sis/sis_mm.c
> +++ b/drivers/gpu/drm/sis/sis_mm.c
> @@ -31,11 +31,14 @@
> *Thomas Hellström
> */
>
> -#include
> +#include
> +
> +#include
> +#include
> #include
> +
> #include "sis_drv.h"
>
> -#include
>
> #define VIDEO_TYPE 0
> #define AGP_TYPE 1
> --
> 2.20.1
>
--
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
[Bug 110845] [DC-only][regression] cannot select full refresh rate on 5.2rc - 144Hz 2560x1440
https://bugs.freedesktop.org/show_bug.cgi?id=110845 --- Comment #2 from Nicholas Kazlauskas --- This patch should fix it: https://patchwork.freedesktop.org/patch/308794/ -- 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 2/2] drm/i915/dsi: Use a fuzzy check for burst mode clock check
Hi,
Thank you for the reviews.
On 04-06-19 19:29, Ville Syrjälä wrote:
On Fri, May 24, 2019 at 07:40:28PM +0200, Hans de Goede wrote:
Prior to this commit we fail to init the DSI panel on the GPD MicroPC:
https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/
The problem is intel_dsi_vbt_init() failing with the following error:
*ERROR* Burst mode freq is less than computed
The pclk in the VBT panel modeline is 7, together with 24 bpp and
4 lines this results in a bitrate value of 7 * 24 / 4 = 42.
But the target_burst_mode_freq in the VBT is 418000.
This commit works around this problem by adding an intel_fuzzy_clock_check
when target_burst_mode_freq < bitrate and setting target_burst_mode_freq to
bitrate when that checks succeeds, fixing the panel not working.
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 022bf59418df..a2a9b9d0eeaa 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -895,6 +895,17 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
if (mipi_config->target_burst_mode_freq) {
u32 bitrate = intel_dsi_bitrate(intel_dsi);
+ /*
+* Sometimes the VBT contains a slightly lower clock,
+* then the bitrate we have calculated, in this case
+* just replace it with the calculated bitrate.
+*/
+ if (mipi_config->target_burst_mode_freq < bitrate &&
+ intel_fuzzy_clock_check(
+ mipi_config->target_burst_mode_freq,
+ bitrate))
+ mipi_config->target_burst_mode_freq = bitrate;
Maybe should squash these patches together to make the stable
backport less painful?
Good idea, done.
Anyways, seems OK to me.
Reviewed-by: Ville Syrjälä
And pushed with your Reviewed-by.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110844] AMDGPU Resets and blackscreens couple minutes into any game regardless of wine/proton/native - sound keeps playing
https://bugs.freedesktop.org/show_bug.cgi?id=110844 --- Comment #1 from Alex Deucher --- Can you narrow down what component (mesa, kernel, ddx) caused the issue and bisect? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #37 from Rui Salvaterra --- (In reply to Marek Olšák from comment #36) > I think if you just implement the disk cache callback, it'll automatically > enable the shader cache for the GLSL compiler. Hi, Marek Yeah, that was my reasoning. Will try. :) -- 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] drm: Ignore drm_gem_vram_mm_funcs in generated documentation
On Wed, Jun 05, 2019 at 11:59:04AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.06.19 um 11:03 schrieb Gerd Hoffmann:
> > On Tue, Jun 04, 2019 at 01:13:30PM +0200, Thomas Zimmermann wrote:
> >> The documentation tools interpret drm_gem_vram_mm_funcs as function and
> >> there appears to be no way of inline-documenting constants.
> >
> >> -/**
> >> +/*
> >> * drm_gem_vram_mm_funcs - Functions for drm_vram_mm
> >
> > "struct drm_gem_vram_mm_funcs" ?
> >
> > (see include/drm/drm_gem.h where struct drm_gem_object_funcs is
> > documented that way).
>
> The documented source line is
>
> const struct drm_vram_mm_funcs drm_gem_vram_mm_funcs = {
>
> and I tried to document the purpose of the constant 'drm_gem_vram_mm_funcs'.
Ah. Missed that detail.
> Documenting global constants is not described in the kernel guide and I
> could not find a source-code example either. Function and struct style
> with '-' didn't work; member-field style with '@' neither. The only way
> seems to be adding it to an .rst file in Documentation. But then it's
> not part of the API documentation, but somewhere in the text.
Ok, patch is fine then.
Acked-by: Gerd Hoffmann
(can you commit & push yourself meanwhile?)
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110845] [DC-only][regression] cannot select full refresh rate on 5.2rc - 144Hz 2560x1440
https://bugs.freedesktop.org/show_bug.cgi?id=110845 --- Comment #1 from Nicholas Kazlauskas --- My guess is that this is probably related to the: https://patchwork.freedesktop.org/patch/306397/ patch. It might not be defaulting to 8bpc as the maximum, limiting you to 120Hz at 1440p. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110845] [DC-only][regression] cannot select full refresh rate on 5.2rc - 144Hz 2560x1440
https://bugs.freedesktop.org/show_bug.cgi?id=110845 Bug ID: 110845 Summary: [DC-only][regression] cannot select full refresh rate on 5.2rc - 144Hz 2560x1440 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mcoffi...@gmail.com Somewhere between 5.1 and amd-staging-drm-next for 5.2-rc1, I stopped being able to set my Acer XV272U 144Hz 1440p display in its 144Hz setting at 2560x1440 resolution. 1920x1080@144Hz still works. This only happens under the display core driver. Setting amdgpu.dc=0 fixes it, but that is not needed on the 5.1 kernel. I will bisect tonight when I get home and have access to my AMD card. Card: XFX RX 590 Kernel: current AMD-staging-drm-next HEAD. The issue occurs both in Xfce4, and in sway (wayland), so I’m assuming that the desktop environment has little to do with the issue. Sorry for bad formatting on mobile, I wanted to get this in and filed with the 5.2 release coming up. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110844] AMDGPU Resets and blackscreens couple minutes into any game regardless of wine/proton/native - sound keeps playing
https://bugs.freedesktop.org/show_bug.cgi?id=110844 Bug ID: 110844 Summary: AMDGPU Resets and blackscreens couple minutes into any game regardless of wine/proton/native - sound keeps playing Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: nathaniel.h...@protonmail.com Created attachment 144461 --> https://bugs.freedesktop.org/attachment.cgi?id=144461=edit the relevant dmesg bit. When i start a game on arch linux with kernel 5.1.7 with the AMDGPU driver it loads up fine but after a couple minutes my monitor blackscreens. The audio of the game keeps playing but i cant close it nor does any other input work either. This issue has existed for about a week or two now. When playing games on windows I have no issues. Attached is the log of dmesg/journalctl -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/13] drivers: Introduce variants for bus_find_device()
Similar to the class_find_device_by_*() introduce the variants
for bus_find_device() to automatically search for device by
generic device properties.
Here is the list of new helpers :
bus_find_device_by_of_node
bus_find_device_by_fwnode
bus_find_device_by_devt
bus_find_next_device
While at it convert the bus_find_device_by_name to static inline
reusing the generic helper to match the name.
Cc: Alexander Shishkin
Cc: Andrew Lunn
Cc: Daniel Vetter
Cc: David Airlie
Cc: "David S. Miller"
Cc: devicet...@vger.kernel.org
Cc: Doug Ledford
Cc: dri-devel@lists.freedesktop.org
Cc: Florian Fainelli
Cc: Frank Rowand
Cc: Greg Kroah-Hartman
Cc: Heiko Stuebner
Cc: Jason Gunthorpe
Cc: Liam Girdwood
Cc: linux-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Mark Brown
Cc: Mathieu Poirier
Cc: Maxime Ripard
Cc: Oliver Neukum
Cc: "Rafael J. Wysocki"
Cc: Rob Herring
Cc: Sebastian Andrzej Siewior
Cc: Srinivas Kandagatla
Cc: Takashi Iwai
Cc: Wolfram Sang
Signed-off-by: Suzuki K Poulose
---
drivers/base/bus.c | 24 ---
include/linux/device.h | 64 +++---
2 files changed, 61 insertions(+), 27 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index df3cac7..a1d1e82 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -342,30 +342,6 @@ struct device *bus_find_device(struct bus_type *bus,
}
EXPORT_SYMBOL_GPL(bus_find_device);
-static int match_name(struct device *dev, const void *data)
-{
- const char *name = data;
-
- return sysfs_streq(name, dev_name(dev));
-}
-
-/**
- * bus_find_device_by_name - device iterator for locating a particular device
of a specific name
- * @bus: bus type
- * @start: Device to begin with
- * @name: name of the device to match
- *
- * This is similar to the bus_find_device() function above, but it handles
- * searching by a name automatically, no need to write another strcmp matching
- * function.
- */
-struct device *bus_find_device_by_name(struct bus_type *bus,
- struct device *start, const char *name)
-{
- return bus_find_device(bus, start, (void *)name, match_name);
-}
-EXPORT_SYMBOL_GPL(bus_find_device_by_name);
-
/**
* subsys_find_device_by_id - find a device with a specific enumeration number
* @subsys: subsystem
diff --git a/include/linux/device.h b/include/linux/device.h
index 4396edc..10de79d 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -175,9 +175,67 @@ int bus_for_each_dev(struct bus_type *bus, struct device
*start, void *data,
struct device *bus_find_device(struct bus_type *bus, struct device *start,
const void *data,
int (*match)(struct device *dev, const void
*data));
-struct device *bus_find_device_by_name(struct bus_type *bus,
- struct device *start,
- const char *name);
+/**
+ * bus_find_device_by_name - device iterator for locating a particular device
+ * of a specific name.
+ * @bus: bus type
+ * @start: Device to begin with
+ * @name: name of the device to match
+ */
+static inline struct device *bus_find_device_by_name(struct bus_type *bus,
+struct device *start,
+const char *name)
+{
+ return bus_find_device(bus, start, name, device_match_name);
+}
+
+/**
+ * bus_find_device_by_of_node : device iterator for locating a particular
device
+ * matching the of_node.
+ * @bus: bus type
+ * @np: of_node of the device to match.
+ */
+static inline struct device *
+bus_find_device_by_of_node(struct bus_type *bus, const struct device_node *np)
+{
+ return bus_find_device(bus, NULL, np, device_match_of_node);
+}
+
+/**
+ * bus_find_device_by_fwnode : device iterator for locating a particular device
+ * matching the fwnode.
+ * @bus: bus type
+ * @fwnode: fwnode of the device to match.
+ */
+static inline struct device *
+bus_find_device_by_fwnode(struct bus_type *bus, const struct fwnode_handle
*fwnode)
+{
+ return bus_find_device(bus, NULL, fwnode, device_match_fwnode);
+}
+
+/**
+ * bus_find_device_by_devt : device iterator for locating a particular device
+ * matching the device type.
+ * @bus: bus type
+ * @start: device to start the search from
+ * @devt: device type of the device to match.
+ */
+static inline struct device *
+bus_find_device_by_devt(struct bus_type *bus, struct device *start, dev_t devt)
+{
+ return bus_find_device(bus, start, , device_match_devt);
+}
+
+/**
+ * bus_find_next_device - Find the next device after a given device in a
+ * given bus.
+ */
+static inline struct device *
+bus_find_next_device(struct bus_type *bus,struct device *cur)
+{
+ return bus_find_device(bus,
[PATCH 04/13] drivers: Add generic helper to match by of_node
Add a helper to match device by the of_node. This will be later used
to provide generic lookup functions by of_node.
Cc: Alan Tull
Cc: Andrew Lunn
Cc: Daniel Vetter
Cc: David Airlie
Cc: "David S. Miller"
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Florian Fainelli
Cc: Frank Rowand
Cc: Greg Kroah-Hartman
Cc: Heiner Kallweit
Cc: Jiri Slaby
Cc: Jonathan Hunter
Cc: Lee Jones
Cc: Liam Girdwood
Cc: linux-f...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Mark Brown
Cc: Mathieu Poirier
Cc: Maxime Ripard
Cc: Moritz Fischer
Cc: Peter Rosin
Cc: Rob Herring
Cc: Srinivas Kandagatla
Cc: Thierry Reding
Cc: Thor Thayer
Cc: Wolfram Sang
Cc: "Rafael J. Wysocki"
Cc: Greg Kroah-Hartman
Cc: Ulf Hansson
Cc: Joe Perches
Signed-off-by: Suzuki K Poulose
---
drivers/base/core.c| 6 ++
include/linux/device.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index fd7511e..9211908 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3328,3 +3328,9 @@ void device_set_of_node_from_dev(struct device *dev,
const struct device *dev2)
dev->of_node_reused = true;
}
EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
+
+int device_match_of_node(struct device *dev, const void *np)
+{
+ return dev->of_node == np;
+}
+EXPORT_SYMBOL_GPL(device_match_of_node);
diff --git a/include/linux/device.h b/include/linux/device.h
index 4d7c881..7093085 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -163,6 +163,8 @@ void subsys_dev_iter_init(struct subsys_dev_iter *iter,
struct device *subsys_dev_iter_next(struct subsys_dev_iter *iter);
void subsys_dev_iter_exit(struct subsys_dev_iter *iter);
+int device_match_of_node(struct device *dev, const void *np);
+
int bus_for_each_dev(struct bus_type *bus, struct device *start, void *data,
int (*fn)(struct device *dev, void *data));
struct device *bus_find_device(struct bus_type *bus, struct device *start,
--
2.7.4
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #36 from Marek Olšák --- I think if you just implement the disk cache callback, it'll automatically enable the shader cache for the GLSL compiler. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/panfrost: make devfreq optional again
Devfreq runtime usage was made mandatory, thus making panfrost fail to probe
on Amlogic S912 SoCs missing the "operating-points-v2" property.
Make it optional again, leaving PM_DEVFREQ selected by default.
Fixes: f3617b449d ("drm/panfrost: Select devfreq")
Signed-off-by: Neil Armstrong
---
Changes since v1:
- fixed else/if logic in panfrost_devfreq_init
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 29fcffdf2d57..db798532b0b6 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -140,7 +140,9 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
return 0;
ret = dev_pm_opp_of_add_table(>pdev->dev);
- if (ret)
+ if (ret == -ENODEV) /* Optional, continue without devfreq */
+ return 0;
+ else if (ret)
return ret;
panfrost_devfreq_reset(pfdev);
@@ -170,6 +172,9 @@ void panfrost_devfreq_resume(struct panfrost_device *pfdev)
{
int i;
+ if (!pfdev->devfreq.devfreq)
+ return;
+
panfrost_devfreq_reset(pfdev);
for (i = 0; i < NUM_JOB_SLOTS; i++)
pfdev->devfreq.slot[i].busy = false;
@@ -179,6 +184,9 @@ void panfrost_devfreq_resume(struct panfrost_device *pfdev)
void panfrost_devfreq_suspend(struct panfrost_device *pfdev)
{
+ if (!pfdev->devfreq.devfreq)
+ return;
+
devfreq_suspend_device(pfdev->devfreq.devfreq);
}
@@ -188,6 +196,9 @@ static void panfrost_devfreq_update_utilization(struct
panfrost_device *pfdev, i
ktime_t now;
ktime_t last;
+ if (!pfdev->devfreq.devfreq)
+ return;
+
now = ktime_get();
last = pfdev->devfreq.slot[slot].time_last_update;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/1] drm/exynos: drop drmP.h usage
Drop use of the deprecated drmP.h file. Replace with forwards / externals as appropriate. While touching the list of include files divide them up in blocks and sort them. Signed-off-by: Sam Ravnborg Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: David Airlie Cc: Daniel Vetter Cc: Kukjin Kim Cc: Krzysztof Kozlowski Cc: Jingoo Han --- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++- drivers/gpu/drm/exynos/exynos7_drm_decon.c| 8 ++-- drivers/gpu/drm/exynos/exynos_dp.c| 13 +++--- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dma.c | 6 ++- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 ++-- drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 +++--- drivers/gpu/drm/exynos/exynos_drm_drv.h | 8 +++- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 21 +- drivers/gpu/drm/exynos/exynos_drm_fb.c| 6 +-- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 7 ++-- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 15 +++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 8 ++-- drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 ++-- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 13 +++--- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 3 +- drivers/gpu/drm/exynos/exynos_drm_mic.c | 22 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 10 ++--- drivers/gpu/drm/exynos/exynos_drm_scaler.c| 12 +++--- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 9 ++-- drivers/gpu/drm/exynos/exynos_hdmi.c | 41 +-- drivers/gpu/drm/exynos/exynos_mixer.c | 31 +++--- 24 files changed, 151 insertions(+), 136 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c index 73b318a7ef49..40423e237b82 100644 --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c @@ -10,7 +10,6 @@ * published by the Free Software Foundationr */ -#include #include #include #include @@ -18,11 +17,15 @@ #include #include #include +#include #include #include -#include "exynos_drm_drv.h" +#include +#include + #include "exynos_drm_crtc.h" +#include "exynos_drm_drv.h" #include "exynos_drm_fb.h" #include "exynos_drm_plane.h" #include "regs-decon5433.h" diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c index 0217ee9a118d..98c2debdd053 100644 --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c @@ -11,8 +11,6 @@ * option) any later version. * */ -#include -#include #include #include @@ -26,10 +24,14 @@ #include #include +#include +#include +#include + #include "exynos_drm_crtc.h" -#include "exynos_drm_plane.h" #include "exynos_drm_drv.h" #include "exynos_drm_fb.h" +#include "exynos_drm_plane.h" #include "regs-decon7.h" /* diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c index b0288cf85701..882275e475c9 100644 --- a/drivers/gpu/drm/exynos/exynos_dp.c +++ b/drivers/gpu/drm/exynos/exynos_dp.c @@ -10,25 +10,24 @@ * option) any later version. */ -#include -#include -#include #include -#include #include +#include +#include +#include +#include #include #include #include #include -#include +#include #include #include #include #include +#include #include - -#include #include #include "exynos_drm_crtc.h" diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 96ee83a798c4..201fdc75ec18 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -12,11 +12,11 @@ * option) any later version. */ -#include #include #include #include #include +#include #include "exynos_drm_crtc.h" #include "exynos_drm_drv.h" diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c b/drivers/gpu/drm/exynos/exynos_drm_dma.c index bef8bc3c8e00..9ebc02768847 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dma.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c @@ -4,11 +4,13 @@ // Author: Inki Dae // Author: Andrzej Hajda -#include -#include #include #include #include +#include + +#include +#include #include "exynos_drm_drv.h" diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c index 6ea92173db9f..87289db12868 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c @@ -10,14 +10,14 @@ * published by the Free Software Foundation. */ -#include +#include +#include + #include #include +#include #include -#include -#include - #include #include diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
[PATCH v1 0/1] drm/exynos: drop use of drmP.h
Drop the use of the deprecated drmP.h header file. Build tested using allyesconfig, allmodconfig for various architectures. Sam Sam Ravnborg (1): drm/exynos: drop drmP.h usage drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++-- drivers/gpu/drm/exynos/exynos7_drm_decon.c| 8 -- drivers/gpu/drm/exynos/exynos_dp.c| 13 - drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dma.c | 6 ++-- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 +++--- drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 drivers/gpu/drm/exynos/exynos_drm_drv.h | 8 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 21 +++--- drivers/gpu/drm/exynos/exynos_drm_fb.c| 6 ++-- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 7 +++-- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 15 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 + drivers/gpu/drm/exynos/exynos_drm_g2d.c | 8 +++--- drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 +++-- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 13 + drivers/gpu/drm/exynos/exynos_drm_ipp.c | 3 +- drivers/gpu/drm/exynos/exynos_drm_mic.c | 22 +++--- drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +-- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 10 +++ drivers/gpu/drm/exynos/exynos_drm_scaler.c| 12 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 9 +++--- drivers/gpu/drm/exynos/exynos_hdmi.c | 41 +-- drivers/gpu/drm/exynos/exynos_mixer.c | 31 ++-- 24 files changed, 151 insertions(+), 136 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/ttm: fix ttm_bo_unreserve
Regards,
Oak
-Original Message-
From: Christian König
Sent: Wednesday, June 5, 2019 7:25 AM
To: Zeng, Oak ; Kuehling, Felix ;
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: fix ttm_bo_unreserve
Am 04.06.19 um 21:03 schrieb Zeng, Oak:
>
> Regards,
> Oak
>
> -Original Message-
> From: amd-gfx On Behalf Of
> Kuehling, Felix
> Sent: Tuesday, June 4, 2019 2:47 PM
> To: Christian König ;
> dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/ttm: fix ttm_bo_unreserve
>
> On 2019-06-04 11:23, Christian König wrote:
>
>> Since we now keep BOs on the LRU we need to make sure that they are
>> removed when they are pinned.
>>
>> Signed-off-by: Christian König
>> ---
>>include/drm/ttm/ttm_bo_driver.h | 14 ++
>>1 file changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/drm/ttm/ttm_bo_driver.h
>> b/include/drm/ttm/ttm_bo_driver.h index 9f54cf9c60df..c9b8ba492f24
>> 100644
>> --- a/include/drm/ttm/ttm_bo_driver.h
>> +++ b/include/drm/ttm/ttm_bo_driver.h
>> @@ -767,14 +767,12 @@ static inline int ttm_bo_reserve_slowpath(struct
>> ttm_buffer_object *bo,
>> */
>>static inline void ttm_bo_unreserve(struct ttm_buffer_object *bo)
>>{
>> -if (!(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
>> -spin_lock(>bdev->glob->lru_lock);
>> -if (list_empty(>lru))
>> -ttm_bo_add_to_lru(bo);
>> -else
>> -ttm_bo_move_to_lru_tail(bo, NULL);
>> -spin_unlock(>bdev->glob->lru_lock);
>> -}
>> +spin_lock(>bdev->glob->lru_lock);
>> +if (list_empty(>lru))
>> +ttm_bo_add_to_lru(bo);
>> +else
>> +ttm_bo_move_to_lru_tail(bo, NULL);
> Going just by the function names, this seems to do the exact opposite of what
> the change description says.
>
> [Oak] +1, when I read the description, I also get lost...So please do add a
> more accurate description.
I'm puzzled why you are confused. We now keep the BOs on the LRU while they are
reserved, so on unreserve we now need to explicitly remove them from the LRU
when they are pinned.
[Oak] When I read the description, I though you meant to remove bo from LRU on
a pin action, but from codes, it is done on unreserve. In other words, it is
better to say "if it is pinned" than "when it is pinned". Sorry being
pickyAlso from codes before your change, there was a condition
"!(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)". Is this condition to check
whether bo is no pinned? How do you check whether bo is pinned in the new
codes? To me condition " list_empty(>lru)" only means this bo is currently
not on LRU list, I am not sure whether this also means it is not pinned. Also,
can ttm_bo_move_to_lru_tail be replaced with ttm_bo_del_from_lru - from your
description, this is more like a function to remove it from LRU. Sorry too many
questions. I really don't know the context here...
>
> Anway, this patch is Reviewed-by: Felix Kuehling
>
> BTW, this fix is needed for KFD. It fixes our eviction test that was broken
> by your previous patch series. This test specifically triggers interactions
> between KFD and graphics under memory pressure. It's something we rarely see
> in real world compute application testing without a targeted test. But when
> it breaks it leads to some painful intermittent failures that are hard to
> regress and debug.
>
> Do you have any targeted tests to trigger evictions when you work on TTM
> internals?
Cat amdgpu_evict_gtt in debugfs is a good test for this.
Christian.
>
> Regards,
> Felix
>
>
>> +spin_unlock(>bdev->glob->lru_lock);
>> reservation_object_unlock(bo->resv);
>>}
>>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix ttm_bo_unreserve
On 2019-06-05 9:56, Michel Dänzer wrote:
> On 2019-06-05 1:24 p.m., Christian König wrote:
>> Am 04.06.19 um 21:03 schrieb Zeng, Oak:
>>> From: amd-gfx On Behalf Of
>>> Kuehling, Felix
>>> On 2019-06-04 11:23, Christian König wrote:
[snip]
>>> --- a/include/drm/ttm/ttm_bo_driver.h
>>> +++ b/include/drm/ttm/ttm_bo_driver.h
>>> @@ -767,14 +767,12 @@ static inline int
>>> ttm_bo_reserve_slowpath(struct ttm_buffer_object *bo,
>>> */
>>> static inline void ttm_bo_unreserve(struct ttm_buffer_object *bo)
>>> {
>>> - if (!(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
>>> - spin_lock(>bdev->glob->lru_lock);
>>> - if (list_empty(>lru))
>>> - ttm_bo_add_to_lru(bo);
>>> - else
>>> - ttm_bo_move_to_lru_tail(bo, NULL);
>>> - spin_unlock(>bdev->glob->lru_lock);
>>> - }
>>> + spin_lock(>bdev->glob->lru_lock);
>>> + if (list_empty(>lru))
>>> + ttm_bo_add_to_lru(bo);
>>> + else
>>> + ttm_bo_move_to_lru_tail(bo, NULL);
>>> Going just by the function names, this seems to do the exact opposite
>>> of what the change description says.
>>>
>>> [Oak] +1, when I read the description, I also get lost...So please do
>>> add a more accurate description.
>> I'm puzzled why you are confused. We now keep the BOs on the LRU while
>> they are reserved, so on unreserve we now need to explicitly remove them
>> from the LRU when they are pinned.
> I don't know about Felix and Oak, but for me "remove from the LRU" is
> confusing, as I don't see that in the code, only adding to the LRU or
> moving to its tail.
Exactly. The names of the functions being called imply that something
gets added or moved on the LRU list. You have to go look at the
implementation of those functions to find out that they do something
else for pinned BOs (that have TTM_PL_FLAG_NO_EVICT set in their
placement flags).
Fixing the function names would probably be overkill:
ttm_bo_add_lru_unless_pinned and
ttm_bo_move_to_lru_tail_or_remove_if_pinned. But maybe a comment in
ttm_bo_unreserve would help.
Regards,
Felix
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/3] media: uapi: Add RGB bus format for the GiantPlus GPM940B0 panel
Em Mon, 3 Jun 2019 17:35:10 +0200 Paul Cercueil escreveu: > The GiantPlus GPM940B0 is a 24-bit TFT panel where the RGB components > are transferred sequentially on a 8-bit bus. > > Signed-off-by: Paul Cercueil > --- > > Notes: > v2: New patch > > v3: No change > > v4: Add only MEDIA_BUS_FMT_RGB888_3X8, as we don't have to care about > endianness Same comment as on version 3: You should also patch the documentation text at: Documentation/media/uapi/v4l/subdev-formats.rst In order to describe the new format that will be included. > > include/uapi/linux/media-bus-format.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/media-bus-format.h > b/include/uapi/linux/media-bus-format.h > index 2a6b253cfb05..16c1fa2d89a4 100644 > --- a/include/uapi/linux/media-bus-format.h > +++ b/include/uapi/linux/media-bus-format.h > @@ -34,7 +34,7 @@ > > #define MEDIA_BUS_FMT_FIXED 0x0001 > > -/* RGB - next is 0x101c */ > +/* RGB - next is 0x101d */ > #define MEDIA_BUS_FMT_RGB444_1X120x1016 > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001 > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002 > @@ -55,6 +55,7 @@ > #define MEDIA_BUS_FMT_RGB888_1X240x100a > #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b > #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c > +#define MEDIA_BUS_FMT_RGB888_3X8 0x101c > #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG 0x1011 > #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012 > #define MEDIA_BUS_FMT_ARGB_1X32 0x100d Thanks, Mauro
Re: [Freedreno] [PATCH] of/device: add blacklist for iommu dma_ops
On Wed, Jun 5, 2019 at 6:18 AM Marek Szyprowski wrote: > > Hi Rob, > > On 2019-06-05 14:57, Rob Clark wrote: > > On Tue, Jun 4, 2019 at 11:58 PM Tomasz Figa wrote: > >> But first of all, I remember Marek already submitted some patches long > >> ago that extended struct driver with some flag that means that the > >> driver doesn't want the IOMMU to be attached before probe. Why > >> wouldn't that work? Sounds like a perfect opt-out solution. > > Actually, yeah.. we should do that. That is the simplest solution. > > Tomasz has very good memory. It took me a while to find that old patches: > > https://patchwork.kernel.org/patch/4677251/ > https://patchwork.kernel.org/patch/4677941/ > https://patchwork.kernel.org/patch/4677401/ > > It looks that my idea was a bit ahead of its time ;) > if I re-spin this, was their a reason not to just use bitfields, ie: -bool suppress_bind_attrs;/* disables bind/unbind via sysfs */ +bool suppress_bind_attrs : 1;/* disables bind/unbind via sysfs */ +bool has_own_iommu_manager : 1; /* driver explictly manages IOMMU */ That seems like it would have been a bit less churn and a bit nicer looking (IMO at least) BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/2] drm/r128: drop use of drmP.h
Drop use of the deprecated drmP.h header file.
Replace it with relevant include files.
Sort include files in files touched.
Signed-off-by: Sam Ravnborg
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/r128/r128_cce.c | 12 ++--
drivers/gpu/drm/r128/r128_drv.c | 9 ++---
drivers/gpu/drm/r128/r128_drv.h | 6 ++
drivers/gpu/drm/r128/r128_state.c | 9 -
4 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/r128/r128_cce.c b/drivers/gpu/drm/r128/r128_cce.c
index 6f426bb06934..138af32480d4 100644
--- a/drivers/gpu/drm/r128/r128_cce.c
+++ b/drivers/gpu/drm/r128/r128_cce.c
@@ -29,13 +29,21 @@
*Gareth Hughes
*/
+#include
+#include
#include
+#include
#include
#include
-#include
+#include
-#include
+#include
+#include
+#include
+#include
+#include
#include
+
#include "r128_drv.h"
#define R128_FIFO_DEBUG0
diff --git a/drivers/gpu/drm/r128/r128_drv.c b/drivers/gpu/drm/r128/r128_drv.c
index 4b1a505ab353..fd74f744604f 100644
--- a/drivers/gpu/drm/r128/r128_drv.c
+++ b/drivers/gpu/drm/r128/r128_drv.c
@@ -31,11 +31,14 @@
#include
-#include
+#include
+#include
+#include
+#include
+#include
#include
-#include "r128_drv.h"
-#include
+#include "r128_drv.h"
static struct pci_device_id pciidlist[] = {
r128_PCI_IDS
diff --git a/drivers/gpu/drm/r128/r128_drv.h b/drivers/gpu/drm/r128/r128_drv.h
index 115bb286dd2a..ba8c30ed91d1 100644
--- a/drivers/gpu/drm/r128/r128_drv.h
+++ b/drivers/gpu/drm/r128/r128_drv.h
@@ -35,8 +35,14 @@
#ifndef __R128_DRV_H__
#define __R128_DRV_H__
+#include
+#include
+#include
+
#include
+#include
#include
+#include
/* General customization:
*/
diff --git a/drivers/gpu/drm/r128/r128_state.c
b/drivers/gpu/drm/r128/r128_state.c
index 2535ea8d2d9b..9d74c9d914cb 100644
--- a/drivers/gpu/drm/r128/r128_state.c
+++ b/drivers/gpu/drm/r128/r128_state.c
@@ -28,8 +28,15 @@
*Gareth Hughes
*/
-#include
+#include
+#include
+#include
+
+#include
+#include
+#include
#include
+
#include "r128_drv.h"
/*
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/2] drm/r128: drop drm_os_linux dependencies
Drop use of drm_os_linux macros.
Simple 1:1 replacements of
- DRM_UDELAY
- DRM_CURRENTPID
- DRM_READ
- DRM_WRITE
With this change we do not need to introduce the deprecated
drm_os_linux.h header when we drop use of drmP.h.
Signed-off-by: Sam Ravnborg
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/r128/r128_cce.c | 16
drivers/gpu/drm/r128/r128_drv.h | 10 +-
drivers/gpu/drm/r128/r128_state.c | 16
3 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/r128/r128_cce.c b/drivers/gpu/drm/r128/r128_cce.c
index b91af1bf531b..6f426bb06934 100644
--- a/drivers/gpu/drm/r128/r128_cce.c
+++ b/drivers/gpu/drm/r128/r128_cce.c
@@ -85,7 +85,7 @@ static int r128_do_pixcache_flush(drm_r128_private_t
*dev_priv)
for (i = 0; i < dev_priv->usec_timeout; i++) {
if (!(R128_READ(R128_PC_NGUI_CTLSTAT) & R128_PC_BUSY))
return 0;
- DRM_UDELAY(1);
+ udelay(1);
}
#if R128_FIFO_DEBUG
@@ -102,7 +102,7 @@ static int r128_do_wait_for_fifo(drm_r128_private_t
*dev_priv, int entries)
int slots = R128_READ(R128_GUI_STAT) & R128_GUI_FIFOCNT_MASK;
if (slots >= entries)
return 0;
- DRM_UDELAY(1);
+ udelay(1);
}
#if R128_FIFO_DEBUG
@@ -124,7 +124,7 @@ static int r128_do_wait_for_idle(drm_r128_private_t
*dev_priv)
r128_do_pixcache_flush(dev_priv);
return 0;
}
- DRM_UDELAY(1);
+ udelay(1);
}
#if R128_FIFO_DEBUG
@@ -211,7 +211,7 @@ int r128_do_cce_idle(drm_r128_private_t *dev_priv)
return r128_do_pixcache_flush(dev_priv);
}
}
- DRM_UDELAY(1);
+ udelay(1);
}
#if R128_FIFO_DEBUG
@@ -838,7 +838,7 @@ static struct drm_buf *r128_freelist_get(struct drm_device
* dev)
return buf;
}
}
- DRM_UDELAY(1);
+ udelay(1);
}
DRM_DEBUG("returning NULL!\n");
@@ -870,7 +870,7 @@ int r128_wait_ring(drm_r128_private_t *dev_priv, int n)
r128_update_ring_snapshot(dev_priv);
if (ring->space >= n)
return 0;
- DRM_UDELAY(1);
+ udelay(1);
}
/* FIXME: This is being ignored... */
@@ -916,7 +916,7 @@ int r128_cce_buffers(struct drm_device *dev, void *data,
struct drm_file *file_p
*/
if (d->send_count != 0) {
DRM_ERROR("Process %d trying to send %d buffers via drmDMA\n",
- DRM_CURRENTPID, d->send_count);
+ task_pid_nr(current), d->send_count);
return -EINVAL;
}
@@ -924,7 +924,7 @@ int r128_cce_buffers(struct drm_device *dev, void *data,
struct drm_file *file_p
*/
if (d->request_count < 0 || d->request_count > dma->buf_count) {
DRM_ERROR("Process %d trying to get %d buffers (of %d max)\n",
- DRM_CURRENTPID, d->request_count, dma->buf_count);
+ task_pid_nr(current), d->request_count,
dma->buf_count);
return -EINVAL;
}
diff --git a/drivers/gpu/drm/r128/r128_drv.h b/drivers/gpu/drm/r128/r128_drv.h
index 2de40d276116..115bb286dd2a 100644
--- a/drivers/gpu/drm/r128/r128_drv.h
+++ b/drivers/gpu/drm/r128/r128_drv.h
@@ -397,10 +397,10 @@ extern long r128_compat_ioctl(struct file *filp, unsigned
int cmd,
#define R128_PCIGART_TABLE_SIZE 32768
-#define R128_READ(reg) DRM_READ32(dev_priv->mmio, (reg))
-#define R128_WRITE(reg, val) DRM_WRITE32(dev_priv->mmio, (reg), (val))
-#define R128_READ8(reg)DRM_READ8(dev_priv->mmio, (reg))
-#define R128_WRITE8(reg, val) DRM_WRITE8(dev_priv->mmio, (reg), (val))
+#define R128_READ(reg) readl(((void __iomem *)dev_priv->mmio->handle)
+ (reg))
+#define R128_WRITE(reg, val) writel(val, ((void __iomem
*)dev_priv->mmio->handle) + (reg))
+#define R128_READ8(reg)readb(((void __iomem
*)dev_priv->mmio->handle) + (reg))
+#define R128_WRITE8(reg, val) writeb(val, ((void __iomem
*)dev_priv->mmio->handle) + (reg))
#define R128_WRITE_PLL(addr, val) \
do { \
@@ -445,7 +445,7 @@ do {
\
r128_update_ring_snapshot(dev_priv);\
if (ring->space >= ring->high_mark) \
goto __ring_space_done; \
- DRM_UDELAY(1); \
+ udelay(1);
[PATCH v1 0/2] drm/r128: drop use of drmP.h
Drop use of the deprecated header file drmP.h in the r128 driver. Also drop dependencies to drm_os_linux.h Sam Sam Ravnborg (2): drm/r128: drop drm_os_linux dependencies drm/r128: drop use of drmP.h drivers/gpu/drm/r128/r128_cce.c | 28 ++-- drivers/gpu/drm/r128/r128_drv.c | 9 ++--- drivers/gpu/drm/r128/r128_drv.h | 16 +++- drivers/gpu/drm/r128/r128_state.c | 25 - 4 files changed, 51 insertions(+), 27 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/meson: fix G12A primary plane disabling
The G12A Primary plane was disabled by writing in the OSD1 configuration
registers, but this caused the plane blender to stall instead of continuing
blended only the overlay plane.
Fix this by disabling the OSD1 plane in the blender registers, and also
enabling it back using the same register.
Fixes: 490f50c109d1 ("drm/meson: Add G12A support for OSD1 Plane")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 2 ++
drivers/gpu/drm/meson/meson_plane.c | 4 ++--
drivers/gpu/drm/meson/meson_viu.c | 3 +--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index 50a9a96720b9..aa8ea107524e 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -252,6 +252,8 @@ static void meson_g12a_crtc_enable_osd1(struct meson_drm
*priv)
writel_relaxed(priv->viu.osb_blend1_size,
priv->io_base +
_REG(VIU_OSD_BLEND_BLEND1_SIZE));
+ writel_bits_relaxed(3 << 8, 3 << 8,
+ priv->io_base + _REG(OSD1_BLEND_SRC_CTRL));
}
static void meson_crtc_enable_vd1(struct meson_drm *priv)
diff --git a/drivers/gpu/drm/meson/meson_plane.c
b/drivers/gpu/drm/meson/meson_plane.c
index b788280895c6..d90427b93a51 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -318,8 +318,8 @@ static void meson_plane_atomic_disable(struct drm_plane
*plane,
/* Disable OSD1 */
if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
- writel_bits_relaxed(BIT(0) | BIT(21), 0,
- priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
+ writel_bits_relaxed(3 << 8, 0,
+ priv->io_base + _REG(OSD1_BLEND_SRC_CTRL));
else
writel_bits_relaxed(VPP_OSD1_POSTBLEND, 0,
priv->io_base + _REG(VPP_MISC));
diff --git a/drivers/gpu/drm/meson/meson_viu.c
b/drivers/gpu/drm/meson/meson_viu.c
index 462c7cb3e1bd..4b2b3024d371 100644
--- a/drivers/gpu/drm/meson/meson_viu.c
+++ b/drivers/gpu/drm/meson/meson_viu.c
@@ -405,8 +405,7 @@ void meson_viu_init(struct meson_drm *priv)
0 << 16 |
1,
priv->io_base + _REG(VIU_OSD_BLEND_CTRL));
- writel_relaxed(3 << 8 |
- 1 << 20,
+ writel_relaxed(1 << 20,
priv->io_base + _REG(OSD1_BLEND_SRC_CTRL));
writel_relaxed(1 << 20,
priv->io_base + _REG(OSD2_BLEND_SRC_CTRL));
--
2.21.0
[PATCH 1/2] drm/meson: fix primary plane disabling
The primary plane disable logic is flawed, when the primary plane is
disabled, it is re-enabled in the vsync irq when another plane is updated.
Handle the plane disabling correctly by handling the primary plane
enable flag in the primary plane update & disable callbacks.
Fixes: 490f50c109d1 ("drm/meson: Add G12A support for OSD1 Plane")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 4
drivers/gpu/drm/meson/meson_plane.c | 4 +++-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index 685715144156..50a9a96720b9 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -107,8 +107,6 @@ static void meson_g12a_crtc_atomic_enable(struct drm_crtc
*crtc,
priv->io_base + _REG(VPP_OUT_H_V_SIZE));
drm_crtc_vblank_on(crtc);
-
- priv->viu.osd1_enabled = true;
}
static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
@@ -137,8 +135,6 @@ static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
priv->io_base + _REG(VPP_MISC));
drm_crtc_vblank_on(crtc);
-
- priv->viu.osd1_enabled = true;
}
static void meson_g12a_crtc_atomic_disable(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/meson/meson_plane.c
b/drivers/gpu/drm/meson/meson_plane.c
index 22490047932e..b788280895c6 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -305,6 +305,8 @@ static void meson_plane_atomic_update(struct drm_plane
*plane,
meson_plane->enabled = true;
}
+ priv->viu.osd1_enabled = true;
+
spin_unlock_irqrestore(>drm->event_lock, flags);
}
@@ -323,7 +325,7 @@ static void meson_plane_atomic_disable(struct drm_plane
*plane,
priv->io_base + _REG(VPP_MISC));
meson_plane->enabled = false;
-
+ priv->viu.osd1_enabled = false;
}
static const struct drm_plane_helper_funcs meson_plane_helper_funcs = {
--
2.21.0
[PATCH 0/2] drm/meson: fix primary plane disabling
The primary plane disabling logic is broken on all supported Amlogic SoCs, and the G12A primary plane disable register write is wrong. This patchset solves thse issues, and has been tested with the Baylibre ffmpeg-drm tool and modetest. Neil Armstrong (2): drm/meson: fix primary plane disabling drm/meson: fix G12A primary plane disabling drivers/gpu/drm/meson/meson_crtc.c | 6 ++ drivers/gpu/drm/meson/meson_plane.c | 8 +--- drivers/gpu/drm/meson/meson_viu.c | 3 +-- 3 files changed, 8 insertions(+), 9 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: dpms mode change with wayland on iMX.6
On Mon, May 27, 2019 at 10:53 AM Pintu Agarwal wrote: > One more point: > Although it is having Kernel 3.10, but the DRM modules were upgraded > to Kernel 4.9.xx from mainline. > So, latest DRM changes are already applied. Please don't do this: just use a recent mainline kernel instead of mixing 3.10 kernel + DRM part from 4.9. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/2] drm/savage: drop use of drmP.h
Drop use of the deprecated drmP.h header file.
Replace it with the necessary includes of other headers.
Signed-off-by: Sam Ravnborg
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/savage/savage_bci.c | 8 +++-
drivers/gpu/drm/savage/savage_drv.c | 9 +
drivers/gpu/drm/savage/savage_drv.h | 4
drivers/gpu/drm/savage/savage_state.c | 9 -
4 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/savage/savage_bci.c
b/drivers/gpu/drm/savage/savage_bci.c
index aa00cf117433..6889d6534eba 100644
--- a/drivers/gpu/drm/savage/savage_bci.c
+++ b/drivers/gpu/drm/savage/savage_bci.c
@@ -24,9 +24,15 @@
*/
#include
+#include
+#include
+#include
-#include
+#include
+#include
+#include
#include
+
#include "savage_drv.h"
/* Need a long timeout for shadow status updates can take a while
diff --git a/drivers/gpu/drm/savage/savage_drv.c
b/drivers/gpu/drm/savage/savage_drv.c
index 2bddeb8bf457..2966fcfd9548 100644
--- a/drivers/gpu/drm/savage/savage_drv.c
+++ b/drivers/gpu/drm/savage/savage_drv.c
@@ -25,12 +25,13 @@
#include
-#include
-#include
-#include "savage_drv.h"
-
+#include
+#include
+#include
#include
+#include "savage_drv.h"
+
static struct pci_device_id pciidlist[] = {
savage_PCI_IDS
};
diff --git a/drivers/gpu/drm/savage/savage_drv.h
b/drivers/gpu/drm/savage/savage_drv.h
index 38aab625f12e..b0081bb64776 100644
--- a/drivers/gpu/drm/savage/savage_drv.h
+++ b/drivers/gpu/drm/savage/savage_drv.h
@@ -26,7 +26,11 @@
#ifndef __SAVAGE_DRV_H__
#define __SAVAGE_DRV_H__
+#include
+
+#include
#include
+#include
#define DRIVER_AUTHOR "Felix Kuehling"
diff --git a/drivers/gpu/drm/savage/savage_state.c
b/drivers/gpu/drm/savage/savage_state.c
index ebb8b7d32b33..a2ac25c11c90 100644
--- a/drivers/gpu/drm/savage/savage_state.c
+++ b/drivers/gpu/drm/savage/savage_state.c
@@ -22,8 +22,15 @@
* CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
* WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
-#include
+
+#include
+#include
+
+#include
+#include
+#include
#include
+
#include "savage_drv.h"
void savage_emit_clip_rect_s3d(drm_savage_private_t * dev_priv,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/2] drm/savage: drop use of drm_os_linux
Drop use of macros from the deprecated drm_os_linux header.
Simple 1:1 replacements of
- DRM_UDELAY
- DRM_CURRENTPID
- DRM_READ
- DRM_WRITE
With this change we do not need to introduce the deprecated
drm_os_linux.h header when we drop use of drmP.h.
Signed-off-by: Sam Ravnborg
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/savage/savage_bci.c | 17 ++---
drivers/gpu/drm/savage/savage_drv.h | 6 --
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/savage/savage_bci.c
b/drivers/gpu/drm/savage/savage_bci.c
index 35dc74883f83..aa00cf117433 100644
--- a/drivers/gpu/drm/savage/savage_bci.c
+++ b/drivers/gpu/drm/savage/savage_bci.c
@@ -22,6 +22,9 @@
* CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
* WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
+
+#include
+
#include
#include
#include "savage_drv.h"
@@ -53,7 +56,7 @@ savage_bci_wait_fifo_shadow(drm_savage_private_t * dev_priv,
unsigned int n)
status = dev_priv->status_ptr[0];
if ((status & mask) < threshold)
return 0;
- DRM_UDELAY(1);
+ udelay(1);
}
#if SAVAGE_BCI_DEBUG
@@ -74,7 +77,7 @@ savage_bci_wait_fifo_s3d(drm_savage_private_t * dev_priv,
unsigned int n)
status = SAVAGE_READ(SAVAGE_STATUS_WORD0);
if ((status & SAVAGE_FIFO_USED_MASK_S3D) <= maxUsed)
return 0;
- DRM_UDELAY(1);
+ udelay(1);
}
#if SAVAGE_BCI_DEBUG
@@ -95,7 +98,7 @@ savage_bci_wait_fifo_s4(drm_savage_private_t * dev_priv,
unsigned int n)
status = SAVAGE_READ(SAVAGE_ALT_STATUS_WORD0);
if ((status & SAVAGE_FIFO_USED_MASK_S4) <= maxUsed)
return 0;
- DRM_UDELAY(1);
+ udelay(1);
}
#if SAVAGE_BCI_DEBUG
@@ -128,7 +131,7 @@ savage_bci_wait_event_shadow(drm_savage_private_t *
dev_priv, uint16_t e)
if status & 0x) - e) & 0x) <= 0x7fff ||
(status & 0x) == 0)
return 0;
- DRM_UDELAY(1);
+ udelay(1);
}
#if SAVAGE_BCI_DEBUG
@@ -150,7 +153,7 @@ savage_bci_wait_event_reg(drm_savage_private_t * dev_priv,
uint16_t e)
if status & 0x) - e) & 0x) <= 0x7fff ||
(status & 0x) == 0)
return 0;
- DRM_UDELAY(1);
+ udelay(1);
}
#if SAVAGE_BCI_DEBUG
@@ -1014,7 +1017,7 @@ int savage_bci_buffers(struct drm_device *dev, void
*data, struct drm_file *file
*/
if (d->send_count != 0) {
DRM_ERROR("Process %d trying to send %d buffers via drmDMA\n",
- DRM_CURRENTPID, d->send_count);
+ task_pid_nr(current), d->send_count);
return -EINVAL;
}
@@ -1022,7 +1025,7 @@ int savage_bci_buffers(struct drm_device *dev, void
*data, struct drm_file *file
*/
if (d->request_count < 0 || d->request_count > dma->buf_count) {
DRM_ERROR("Process %d trying to get %d buffers (of %d max)\n",
- DRM_CURRENTPID, d->request_count, dma->buf_count);
+ task_pid_nr(current), d->request_count,
dma->buf_count);
return -EINVAL;
}
diff --git a/drivers/gpu/drm/savage/savage_drv.h
b/drivers/gpu/drm/savage/savage_drv.h
index 44a1009b6ecb..38aab625f12e 100644
--- a/drivers/gpu/drm/savage/savage_drv.h
+++ b/drivers/gpu/drm/savage/savage_drv.h
@@ -484,8 +484,10 @@ extern void savage_emit_clip_rect_s4(drm_savage_private_t
* dev_priv,
/*
* access to MMIO
*/
-#define SAVAGE_READ(reg) DRM_READ32( dev_priv->mmio, (reg) )
-#define SAVAGE_WRITE(reg) DRM_WRITE32( dev_priv->mmio, (reg) )
+#define SAVAGE_READ(reg) \
+ readl(((void __iomem *)dev_priv->mmio->handle) + (reg))
+#define SAVAGE_WRITE(reg) \
+ writel(val, ((void __iomem *)dev_priv->mmio->handle) + (reg))
/*
* access to the burst command interface (BCI)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/2] drm/savage: drop use of drmP.h
Drop use of the deprecated drmP.h header file. And likewise drop use of macros from drm_os_linux.h Sam Sam Ravnborg (2): drm/savage: drop use of drm_os_linux drm/savage: drop use of drmP.h drivers/gpu/drm/savage/savage_bci.c | 25 + drivers/gpu/drm/savage/savage_drv.c | 9 + drivers/gpu/drm/savage/savage_drv.h | 10 -- drivers/gpu/drm/savage/savage_state.c | 9 - 4 files changed, 38 insertions(+), 15 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: dpms mode change with wayland on iMX.6
On Mon, 27 May 2019 12:41:43 +0530 Pintu Agarwal wrote: > Dear All, > > I have a iMX.6 (arm 32) board with Linux Kernel 3.10 and debian > platform running. > The board is connected to one LCD screen and one HDMI monitor. > It have DRM + Wayland setup for display. > Also, I noticed that it have two dri interface: > /dev/dri/card0 > /dev/dri/card1 > > I am not very familiar with Linux Graphics/Display subsystem, so I am > looking for some help here. > > My requirement is that I have turn off HDMI display screen using a > command line utility or test program. > I learn that for X-server we can use xset : xset dpms force off (and > it works on my ubuntu desktop with 16.04). > > However this command does not exists on my board. > So, my question is: > Is there any equivalent DPMS commands for Wayland/Wetson? Hi, there is not. A proper solution is to teach the display server (e.g. Weston) toggle DPMS according to the conditions you need. If DPMS must be controlled from outside of the display server, you have to invent the necessary protocol extension (Wayland, D-Bus, something else...) yourself. > Then, when I try to run it using below command: > # ./proptest.out 29 connector 2 3 > > The program just returns successfully without any errors, but nothing > happens. The display does not turns off. > I saw that in my kernel 3.10 the ioctl(DRM_IOCTL_MODE_SETPROPERTY) is > already supported under DRM. > > So, I am wondering what is the right way to verify DPMS mode property > on wayland ? You can probably read the property via DRM, but on DRM KMS there is no way to set it unless you are the DRM master. The idea is that the currently active display server is in control, and there is no way to bypass it as long as it is active (is "DRM master"). Wayland is not a display server. Wayland is just an interface to some display servers, and by design Wayland does not expose hardware knobs like DPMS directly, unless you make your own Wayland extension for it. Thanks, pq pgp4L82y4u_wH.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix ttm_bo_unreserve
On 2019-06-05 1:24 p.m., Christian König wrote:
> Am 04.06.19 um 21:03 schrieb Zeng, Oak:
>> From: amd-gfx On Behalf Of
>> Kuehling, Felix
>> On 2019-06-04 11:23, Christian König wrote:
>>
>>> Since we now keep BOs on the LRU we need to make sure that they are
>>> removed when they are pinned.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> include/drm/ttm/ttm_bo_driver.h | 14 ++
>>> 1 file changed, 6 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/include/drm/ttm/ttm_bo_driver.h
>>> b/include/drm/ttm/ttm_bo_driver.h index 9f54cf9c60df..c9b8ba492f24
>>> 100644
>>> --- a/include/drm/ttm/ttm_bo_driver.h
>>> +++ b/include/drm/ttm/ttm_bo_driver.h
>>> @@ -767,14 +767,12 @@ static inline int
>>> ttm_bo_reserve_slowpath(struct ttm_buffer_object *bo,
>>> */
>>> static inline void ttm_bo_unreserve(struct ttm_buffer_object *bo)
>>> {
>>> - if (!(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
>>> - spin_lock(>bdev->glob->lru_lock);
>>> - if (list_empty(>lru))
>>> - ttm_bo_add_to_lru(bo);
>>> - else
>>> - ttm_bo_move_to_lru_tail(bo, NULL);
>>> - spin_unlock(>bdev->glob->lru_lock);
>>> - }
>>> + spin_lock(>bdev->glob->lru_lock);
>>> + if (list_empty(>lru))
>>> + ttm_bo_add_to_lru(bo);
>>> + else
>>> + ttm_bo_move_to_lru_tail(bo, NULL);
>> Going just by the function names, this seems to do the exact opposite
>> of what the change description says.
>>
>> [Oak] +1, when I read the description, I also get lost...So please do
>> add a more accurate description.
>
> I'm puzzled why you are confused. We now keep the BOs on the LRU while
> they are reserved, so on unreserve we now need to explicitly remove them
> from the LRU when they are pinned.
I don't know about Felix and Oak, but for me "remove from the LRU" is
confusing, as I don't see that in the code, only adding to the LRU or
moving to its tail.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/1] drm/sis: drop use of drmP.h
Drop use of the deprecated drmP.h file Sam Ravnborg (1): drm/sis: drop drmP.h use drivers/gpu/drm/sis/sis_drv.c | 8 +--- drivers/gpu/drm/sis/sis_drv.h | 10 -- drivers/gpu/drm/sis/sis_mm.c | 7 +-- 3 files changed, 14 insertions(+), 11 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/1] drm/sis: drop drmP.h use
Drop use of the deprecated drmP.h header.
Repalced with relevant header files and sorted header files in all files
touched.
Replaced DRM_{READ,WRITE} to avoid the drm_os_linux header.
Build tested with allyesconfig, allmodconfig on various architectures.
Signed-off-by: Sam Ravnborg
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/sis/sis_drv.c | 8 +---
drivers/gpu/drm/sis/sis_drv.h | 10 --
drivers/gpu/drm/sis/sis_mm.c | 7 +--
3 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/sis/sis_drv.c
index e04a92658cd7..ee3801201ecc 100644
--- a/drivers/gpu/drm/sis/sis_drv.c
+++ b/drivers/gpu/drm/sis/sis_drv.c
@@ -27,11 +27,13 @@
#include
-#include
+#include
+#include
+#include
+#include
#include
-#include "sis_drv.h"
-#include
+#include "sis_drv.h"
static struct pci_device_id pciidlist[] = {
sisdrv_PCI_IDS
diff --git a/drivers/gpu/drm/sis/sis_drv.h b/drivers/gpu/drm/sis/sis_drv.h
index 328f8a750976..81339443b3b1 100644
--- a/drivers/gpu/drm/sis/sis_drv.h
+++ b/drivers/gpu/drm/sis/sis_drv.h
@@ -28,7 +28,9 @@
#ifndef _SIS_DRV_H_
#define _SIS_DRV_H_
+#include
#include
+#include
/* General customization:
*/
@@ -46,12 +48,8 @@ enum sis_family {
SIS_CHIP_315 = 1,
};
-#include
-
-
-#define SIS_BASE (dev_priv->mmio)
-#define SIS_READ(reg) DRM_READ32(SIS_BASE, reg)
-#define SIS_WRITE(reg, val) DRM_WRITE32(SIS_BASE, reg, val)
+#define SIS_READ(reg) readl(((void __iomem *)dev_priv->mmio->handle) +
(reg))
+#define SIS_WRITE(reg, val) writel(val, ((void __iomem
*)dev_priv->mmio->handle) + (reg))
typedef struct drm_sis_private {
drm_local_map_t *mmio;
diff --git a/drivers/gpu/drm/sis/sis_mm.c b/drivers/gpu/drm/sis/sis_mm.c
index 1622db24cd39..e51d4289a3d0 100644
--- a/drivers/gpu/drm/sis/sis_mm.c
+++ b/drivers/gpu/drm/sis/sis_mm.c
@@ -31,11 +31,14 @@
*Thomas Hellström
*/
-#include
+#include
+
+#include
+#include
#include
+
#include "sis_drv.h"
-#include
#define VIDEO_TYPE 0
#define AGP_TYPE 1
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/1] sti: drop drmP.h
Drop use of drmP.h in the sti driver. Sam Sam Ravnborg (1): drm/sti: drop use of drmP.h drivers/gpu/drm/sti/sti_awg_utils.c| 2 ++ drivers/gpu/drm/sti/sti_awg_utils.h| 2 +- drivers/gpu/drm/sti/sti_compositor.c | 5 - drivers/gpu/drm/sti/sti_crtc.c | 4 +++- drivers/gpu/drm/sti/sti_crtc.h | 6 -- drivers/gpu/drm/sti/sti_cursor.c | 2 ++ drivers/gpu/drm/sti/sti_cursor.h | 3 +++ drivers/gpu/drm/sti/sti_drv.c | 11 ++- drivers/gpu/drm/sti/sti_drv.h | 5 +++-- drivers/gpu/drm/sti/sti_dvo.c | 3 ++- drivers/gpu/drm/sti/sti_gdp.c | 4 drivers/gpu/drm/sti/sti_gdp.h | 5 + drivers/gpu/drm/sti/sti_hda.c | 6 +- drivers/gpu/drm/sti/sti_hdmi.c | 5 - drivers/gpu/drm/sti/sti_hdmi.h | 4 +++- drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 2 ++ drivers/gpu/drm/sti/sti_hqvdp.c| 8 +++- drivers/gpu/drm/sti/sti_mixer.c| 4 drivers/gpu/drm/sti/sti_mixer.h| 7 ++- drivers/gpu/drm/sti/sti_plane.c| 4 +++- drivers/gpu/drm/sti/sti_plane.h| 1 - drivers/gpu/drm/sti/sti_tvout.c| 6 +- drivers/gpu/drm/sti/sti_vid.c | 4 +++- drivers/gpu/drm/sti/sti_vtg.c | 4 +++- drivers/gpu/drm/sti/sti_vtg.h | 1 + 25 files changed, 85 insertions(+), 23 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH] of/device: add blacklist for iommu dma_ops
Hi Rob, On 2019-06-05 14:57, Rob Clark wrote: > On Tue, Jun 4, 2019 at 11:58 PM Tomasz Figa wrote: >> But first of all, I remember Marek already submitted some patches long >> ago that extended struct driver with some flag that means that the >> driver doesn't want the IOMMU to be attached before probe. Why >> wouldn't that work? Sounds like a perfect opt-out solution. > Actually, yeah.. we should do that. That is the simplest solution. Tomasz has very good memory. It took me a while to find that old patches: https://patchwork.kernel.org/patch/4677251/ https://patchwork.kernel.org/patch/4677941/ https://patchwork.kernel.org/patch/4677401/ It looks that my idea was a bit ahead of its time ;) Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH] gpu: host1x: Do not output error message for deferred probe
On Wed, Jun 05, 2019 at 03:40:28PM +0300, Dmitry Osipenko wrote:
> 05.06.2019 15:32, Thierry Reding пишет:
> > On Wed, Jun 05, 2019 at 02:25:43PM +0300, Dmitry Osipenko wrote:
> >> 05.06.2019 11:28, Thierry Reding пишет:
> >>> On Tue, Jun 04, 2019 at 07:07:42PM +0300, Dmitry Osipenko wrote:
> 04.06.2019 18:31, Thierry Reding пишет:
> > From: Thierry Reding
> >
> > When deferring probe, avoid logging a confusing error message. While at
> > it, make the error message more informational.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > drivers/gpu/host1x/dev.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
> > index c55e2d634887..5a3f797240d4 100644
> > --- a/drivers/gpu/host1x/dev.c
> > +++ b/drivers/gpu/host1x/dev.c
> > @@ -247,8 +247,11 @@ static int host1x_probe(struct platform_device
> > *pdev)
> >
> > host->clk = devm_clk_get(>dev, NULL);
> > if (IS_ERR(host->clk)) {
> > - dev_err(>dev, "failed to get clock\n");
> > err = PTR_ERR(host->clk);
> > +
> > + if (err != -EPROBE_DEFER)
> > + dev_err(>dev, "failed to get clock:
> > %d\n", err);
> > +
> > return err;
> > }
>
> The clock driver should be available at the time of host1x's probing on
> all Tegra's because it is one of essential core drivers that become
> available early during boot.
> >>>
> >>> That's the currently baked-in assumption. However, there can be any
> >>> number of reasons for why the clocks may not show up as early as
> >>> expected, as evidenced in the case of Tegra186.
> >>>
> I guess you're making this change for T186, is it because the BPMP
> driver's probe getting deferred? If yes, won't it be possible to fix the
> defer of the clock driver instead of making such changes in the affected
> drivers?
> >>>
> >>> The reason why this is now happening on Tegra186 is because the BPMP is
> >>> bound to an IOMMU to avoid getting faults from the new no-bypass policy
> >>> that the ARM SMMU driver is implementing as of v5.2-rc1.
> >>>
> >>> As a result of binding to an IOMMU, the first probe of the BPMP driver
> >>> will get deferred, so any driver trying to request a clock after that
> >>> and before BPMP gets probed successfully the next time, any clk_get()
> >>> calls will fail with -EPROBE_DEFER.
> >>>
> >>> This is a bit unfortunate, but like I said, these kinds of things can
> >>> happen, and probe deferral was designed specifically to deal with that
> >>> kind of situation so that we wouldn't have to rely on all of these
> >>> built-in assumptions that occasionally break.
> >>>
> >>> The driver also already handles deferred probe properly. The only thing
> >>> that this patch really changes is to no longer consider -EPROBE_DEFER an
> >>> error. It's in fact a pretty common situation in many drivers and should
> >>> not warrant a kernel log message.
> >>
> >> You're trying to mask symptoms instead of curing the decease and it looks
> >> like the decease could be cured.
> >
> > There's nothing here to cure. -EPROBE_DEFER was designed specifically to
> > avoid having to play these kinds of games with initcall levels.
> >
> > What this patch tries to do is just to avoid printing an error message
> > for something that is not an error. -EPROBE_DEFER is totally expected to
> > happen, it's normal, it's not something that we should bother users with
> > because things end up sorting themselves out in the end.
> >
> >> Won't something like this work for you?
> >
> > I'm sure we could find a number of ways to fix this. But there's no need
> > to fix this because it's not broken. What is broken is that we output an
> > error message when this happens and make an elephant out of a fly.
>
> Sure, this is absolutely not critical and deferred probe is doing its job.
> But don't you agree that it's better to fix the root of the annoyance once
> and for all?
From my point of view deferred probe is the once and for all fix. Back
before we had deferred probe, doing these kinds of initcall reordering
tricks was fairly common and while such a change may fix one setup, it
often ended up breaking others.
Sorry, this is a lesson that we already learned a couple of years ago,
no need to rehash it.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/bridge: dw-hdmi: allow ycbcr420 modes for >= 0x200a
On 22/05/2019 08:07, Andrzej Hajda wrote:
> On 20.05.2019 15:37, Neil Armstrong wrote:
>> Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
>> for these modes in the connector if the platform supports them.
>> We limit these modes to DW-HDMI IP version >= 0x200a which
>> are designed to support HDMI2.0 display modes.
>>
>> Signed-off-by: Neil Armstrong
>> Tested-by: Heiko Stuebner
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 ++
>> include/drm/bridge/dw_hdmi.h | 1 +
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index ab7968c8f6a2..b50c49caf7ae 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2629,6 +2629,12 @@ __dw_hdmi_probe(struct platform_device *pdev,
>> if (hdmi->phy.ops->setup_hpd)
>> hdmi->phy.ops->setup_hpd(hdmi, hdmi->phy.data);
>>
>> +if (hdmi->version >= 0x200a)
>> +hdmi->connector.ycbcr_420_allowed =
>> +hdmi->plat_data->ycbcr_420_allowed;
>> +else
>> +hdmi->connector.ycbcr_420_allowed = false;
>> +
>
>
> I suspect else clause can be dropped.
You are right, thanks for the review.
Do you have comments on the patches 2, 3 & 4 of serie ?
Thanks,
Neil
>
> Beside this:
>
> Reviewed-by: Andrzej Hajda
>
> --
> Regards
> Andrzej
>
>
>> memset(, 0, sizeof(pdevinfo));
>> pdevinfo.parent = dev;
>> pdevinfo.id = PLATFORM_DEVID_AUTO;
>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>> index 66e70770cce5..0f0e82638fbe 100644
>> --- a/include/drm/bridge/dw_hdmi.h
>> +++ b/include/drm/bridge/dw_hdmi.h
>> @@ -130,6 +130,7 @@ struct dw_hdmi_plat_data {
>> const struct drm_display_mode *mode);
>> unsigned long input_bus_format;
>> unsigned long input_bus_encoding;
>> +bool ycbcr_420_allowed;
>>
>> /* Vendor PHY support */
>> const struct dw_hdmi_phy_ops *phy_ops;
>
>
Re: [Freedreno] [PATCH] of/device: add blacklist for iommu dma_ops
On Tue, Jun 4, 2019 at 11:58 PM Tomasz Figa wrote: > > But first of all, I remember Marek already submitted some patches long > ago that extended struct driver with some flag that means that the > driver doesn't want the IOMMU to be attached before probe. Why > wouldn't that work? Sounds like a perfect opt-out solution. Actually, yeah.. we should do that. That is the simplest solution. BR, -R
Re: [PATCH 1/4] drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support
On 26/05/2019 23:19, Jonas Karlman wrote:
> Add support for configuring Dynamic Range and Mastering InfoFrame from
> the hdr_output_metadata connector property.
>
> This patch adds a drm_infoframe flag to dw_hdmi_plat_data that platform
> drivers
> 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.
>
> These changes were based on work done by Zheng Yang
> to support DRM InfoFrame on the Rockchip 4.4 BSP kernel at [1] and [2]
>
> [1] https://github.com/rockchip-linux/kernel/tree/develop-4.4
> [2]
> https://github.com/rockchip-linux/kernel/commit/d1943fde81ff41d7cca87f4a42f03992e90bddd5
>
> Cc: Zheng Yang
> Signed-off-by: Jonas Karlman
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 109 ++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 37
> include/drm/bridge/dw_hdmi.h | 1 +
> 3 files changed, 147 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 284ce59be8f8..801bbbd732fd 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -24,6 +24,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1592,6 +1593,78 @@ static void
> hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
> HDMI_FC_DATAUTO0_VSD_MASK);
> }
>
> +#define HDR_LSB(n) ((n) & 0xff)
> +#define HDR_MSB(n) (((n) & 0xff00) >> 8)
> +
> +static void hdmi_config_drm_infoframe(struct dw_hdmi *hdmi)
> +{
> + const struct drm_connector_state *conn_state = hdmi->connector.state;
> + struct hdmi_drm_infoframe frame;
> + int ret;
> +
> + if (hdmi->version < 0x200a || !hdmi->plat_data->drm_infoframe)
> + return;
> +
> + hdmi_modb(hdmi, HDMI_FC_PACKET_TX_EN_DRM_DISABLE,
> + HDMI_FC_PACKET_TX_EN_DRM_MASK, HDMI_FC_PACKET_TX_EN);
> +
> + ret = drm_hdmi_infoframe_set_hdr_metadata(, conn_state);
> + if (ret < 0)
> + return;
> +
> + ret = hdmi_drm_infoframe_check();
> + if (WARN_ON(ret))
> + return;
> +
> + hdmi_writeb(hdmi, frame.version, HDMI_FC_DRM_HB0);
> + hdmi_writeb(hdmi, frame.length, HDMI_FC_DRM_HB1);
> + hdmi_writeb(hdmi, frame.eotf, HDMI_FC_DRM_PB0);
> + hdmi_writeb(hdmi, frame.metadata_type, HDMI_FC_DRM_PB1);
> + hdmi_writeb(hdmi, HDR_LSB(frame.display_primaries[0].x),
> + HDMI_FC_DRM_PB2);
> + hdmi_writeb(hdmi, HDR_MSB(frame.display_primaries[0].x),
> + HDMI_FC_DRM_PB3);
> + hdmi_writeb(hdmi, HDR_LSB(frame.display_primaries[0].y),
> + HDMI_FC_DRM_PB4);
> + hdmi_writeb(hdmi, HDR_MSB(frame.display_primaries[0].y),
> + HDMI_FC_DRM_PB5);
> + hdmi_writeb(hdmi, HDR_LSB(frame.display_primaries[1].x),
> + HDMI_FC_DRM_PB6);
> + hdmi_writeb(hdmi, HDR_MSB(frame.display_primaries[1].x),
> + HDMI_FC_DRM_PB7);
> + hdmi_writeb(hdmi, HDR_LSB(frame.display_primaries[1].y),
> + HDMI_FC_DRM_PB8);
> + hdmi_writeb(hdmi, HDR_MSB(frame.display_primaries[1].y),
> + HDMI_FC_DRM_PB9);
> + hdmi_writeb(hdmi, HDR_LSB(frame.display_primaries[2].x),
> + HDMI_FC_DRM_PB10);
> + hdmi_writeb(hdmi, HDR_MSB(frame.display_primaries[2].x),
> + HDMI_FC_DRM_PB11);
> + hdmi_writeb(hdmi, HDR_LSB(frame.display_primaries[2].y),
> + HDMI_FC_DRM_PB12);
> + hdmi_writeb(hdmi, HDR_MSB(frame.display_primaries[2].y),
> + HDMI_FC_DRM_PB13);
> + hdmi_writeb(hdmi, HDR_LSB(frame.white_point.x), HDMI_FC_DRM_PB14);
> + hdmi_writeb(hdmi, HDR_MSB(frame.white_point.x), HDMI_FC_DRM_PB15);
> + hdmi_writeb(hdmi, HDR_LSB(frame.white_point.y), HDMI_FC_DRM_PB16);
> + hdmi_writeb(hdmi, HDR_MSB(frame.white_point.y), HDMI_FC_DRM_PB17);
> + hdmi_writeb(hdmi, HDR_LSB(frame.max_display_mastering_luminance),
> + HDMI_FC_DRM_PB18);
> + hdmi_writeb(hdmi, HDR_MSB(frame.max_display_mastering_luminance),
> + HDMI_FC_DRM_PB19);
> + hdmi_writeb(hdmi, HDR_LSB(frame.min_display_mastering_luminance),
> + HDMI_FC_DRM_PB20);
> + hdmi_writeb(hdmi, HDR_MSB(frame.min_display_mastering_luminance),
> + HDMI_FC_DRM_PB21);
> + hdmi_writeb(hdmi, HDR_LSB(frame.max_cll), HDMI_FC_DRM_PB22);
> + hdmi_writeb(hdmi, HDR_MSB(frame.max_cll), HDMI_FC_DRM_PB23);
> + hdmi_writeb(hdmi, HDR_LSB(frame.max_fall), HDMI_FC_DRM_PB24);
> + hdmi_writeb(hdmi, HDR_MSB(frame.max_fall), HDMI_FC_DRM_PB25);
> + hdmi_writeb(hdmi, 1, HDMI_FC_DRM_UP);
> + hdmi_modb(hdmi, HDMI_FC_PACKET_TX_EN_DRM_ENABLE,
> + HDMI_FC_PACKET_TX_EN_DRM_MASK, HDMI_FC_PACKET_TX_EN);
> +}
> +
> static void hdmi_av_composer(struct
Re: [PATCH 3/4] drm/meson: Enable DRM InfoFrame support on GXL, GXM and G12A
On 26/05/2019 23:20, Jonas Karlman wrote: > This patch enables Dynamic Range and Mastering InfoFrame on GXL, GXM and G12A. > > Cc: Neil Armstrong > Signed-off-by: Jonas Karlman > --- > drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c > b/drivers/gpu/drm/meson/meson_dw_hdmi.c > index df3f9ddd2234..f7761e698c03 100644 > --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c > +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c > @@ -966,6 +966,11 @@ static int meson_dw_hdmi_bind(struct device *dev, struct > device *master, > dw_plat_data->input_bus_format = MEDIA_BUS_FMT_YUV8_1X24; > dw_plat_data->input_bus_encoding = V4L2_YCBCR_ENC_709; > > + if (dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxl-dw-hdmi") || > + dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxm-dw-hdmi") || > + dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-g12a-dw-hdmi")) > + dw_plat_data->drm_infoframe = true; > + > platform_set_drvdata(pdev, meson_dw_hdmi); > > meson_dw_hdmi->hdmi = dw_hdmi_bind(pdev, encoder, > Reviewed-by: Neil Armstrong ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/meson: fix G12A HDMI PLL settings for 4K60 1000/1001 variations
The Amlogic G12A HDMI PLL needs some specific settings to lock with
different fractional values for the 5,4GHz mode.
Handle the 1000/1001 variation fractional case here to avoid having
the PLL in an non lockable state.
Fixes: 202b9808f8ed ("drm/meson: Add G12A Video Clock setup")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_vclk.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_vclk.c
b/drivers/gpu/drm/meson/meson_vclk.c
index 44250eff8a3f..83fc2fc82001 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -553,8 +553,17 @@ void meson_hdmi_pll_set_params(struct meson_drm *priv,
unsigned int m,
/* G12A HDMI PLL Needs specific parameters for 5.4GHz */
if (m >= 0xf7) {
- regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL4, 0xea68dc00);
- regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL5, 0x65771290);
+ if (frac < 0x1) {
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL4,
+ 0x6a685c00);
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL5,
+ 0x11551293);
+ } else {
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL4,
+ 0xea68dc00);
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL5,
+ 0x65771290);
+ }
regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL6, 0x39272000);
regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL7, 0x5554);
} else {
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
