Re: [RFC] treewide: cleanup unreachable breaks
On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > From: Tom Rix > > This is a upcoming change to clean up a new warning treewide. > I am wondering if the change could be one mega patch (see below) or > normal patch per file about 100 patches or somewhere half way by collecting > early acks. Please break it up into one-patch-per-subsystem, like normal, and get it merged that way. Sending us a patch, without even a diffstat to review, isn't going to get you very far... thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] treewide: cleanup unreachable breaks
On Sat, Oct 17, 2020 at 9:10 AM wrote:
>
> From: Tom Rix
>
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early acks.
>
> clang has a number of useful, new warnings see
> https://clang.llvm.org/docs/DiagnosticsReference.html
>
> This change cleans up -Wunreachable-code-break
> https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
> for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.
>
> The method of fixing was to look for warnings where the preceding statement
> was a simple statement and by inspection made the subsequent break unneeded.
> In order of frequency these look like
>
> return and break
>
> switch (c->x86_vendor) {
> case X86_VENDOR_INTEL:
> intel_p5_mcheck_init(c);
> return 1;
> - break;
>
> goto and break
>
> default:
> operation = 0; /* make gcc happy */
> goto fail_response;
> - break;
>
> break and break
> case COLOR_SPACE_SRGB:
> /* by pass */
> REG_SET(OUTPUT_CSC_CONTROL, 0,
> OUTPUT_CSC_GRPH_MODE, 0);
> break;
> - break;
>
> The exception to the simple statement, is a switch case with a block
> and the end of block is a return
>
> struct obj_buffer *buff = r->ptr;
> return scnprintf(str, PRIV_STR_SIZE,
> "size=%u\naddr=0x%X\n", buff->size,
> buff->addr);
> }
> - break;
>
> Not considered obvious and excluded, breaks after
> multi level switches
> complicated if-else if-else blocks
> panic() or similar calls
>
> And there is an odd addition of a 'fallthrough' in drivers/tty/nozomi.c
[..]
> diff --git a/drivers/nvdimm/claim.c b/drivers/nvdimm/claim.c
> index 5a7c80053c62..2f250874b1a4 100644
> --- a/drivers/nvdimm/claim.c
> +++ b/drivers/nvdimm/claim.c
> @@ -200,11 +200,10 @@ ssize_t nd_namespace_store(struct device *dev,
> }
> break;
> default:
> len = -EBUSY;
> goto out_attach;
> - break;
> }
Acked-by: Dan Williams
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] mm: mmap: fix fput in error path v2
On Mon, Oct 12, 2020 at 10:52:02AM +0200, Christian König wrote: > Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..." > adds a workaround for a bug in mmap_region. > > As the comment states ->mmap() callback can change > vma->vm_file and so we might call fput() on the wrong file. > > Revert the workaround and proper fix this in mmap_region. > > v2: drop the extra if in dma_buf_mmap as well > > Signed-off-by: Christian König > Reviewed-by: Jason Gunthorpe > --- > drivers/dma-buf/dma-buf.c | 20 +++- > mm/mmap.c | 2 +- > 2 files changed, 4 insertions(+), 18 deletions(-) Reviewed-by: Jason Gunthorpe Probably should Fixes that other patch Andrew pointed at Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/msm/dsi_pll_10nm: restore VCO rate during restore_state
PHY disable/enable resets PLL registers to default values. Thus in
addition to restoring several registers we also need to restore VCO rate
settings.
Signed-off-by: Dmitry Baryshkov
Fixes: c6659785dfb3 ("drm/msm/dsi/pll: call vco set rate explicitly")
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index 6ac04fc303f5..e4e9bf04b736 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -559,6 +559,7 @@ static int dsi_pll_10nm_restore_state(struct msm_dsi_pll
*pll)
struct pll_10nm_cached_state *cached = _10nm->cached_state;
void __iomem *phy_base = pll_10nm->phy_cmn_mmio;
u32 val;
+ int ret;
val = pll_read(pll_10nm->mmio + REG_DSI_10nm_PHY_PLL_PLL_OUTDIV_RATE);
val &= ~0x3;
@@ -573,6 +574,13 @@ static int dsi_pll_10nm_restore_state(struct msm_dsi_pll
*pll)
val |= cached->pll_mux;
pll_write(phy_base + REG_DSI_10nm_PHY_CMN_CLK_CFG1, val);
+ ret = dsi_pll_10nm_vco_set_rate(>clk_hw,
pll_10nm->vco_current_rate, pll_10nm->vco_ref_clk_rate);
+ if (ret) {
+ DRM_DEV_ERROR(_10nm->pdev->dev,
+ "restore vco rate failed. ret=%d\n", ret);
+ return ret;
+ }
+
DBG("DSI PLL%d", pll_10nm->id);
return 0;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/sun4i: frontend: Fix the scaler phase on A33
The A33 has a different phase parameter in the Allwinner BSP on the
channel1 than the one currently applied. Fix this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index d32b12cbbb60..ff4187eab519 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -694,7 +694,7 @@ static const struct sun4i_frontend_data sun4i_a10_frontend
= {
};
static const struct sun4i_frontend_data sun8i_a33_frontend = {
- .ch_phase = { 0x400, 0x400 },
+ .ch_phase = { 0x400, 0xfc400 },
.has_coef_access_ctrl = true,
};
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
On 10/16/20 6:25 PM, Sam Ravnborg wrote: > Hi Marek. Hello Sam, > On Sat, Oct 03, 2020 at 01:08:23AM +0200, Marek Vasut wrote: >> The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to >> select input pixel data sampling edge. Add DT property "pixelclk-active", >> same as the one used by display timings, and configure bus flags based on >> this DT property. > > Why is it that this information cannot come from the panel driver? Because the sampling edge of the panel can be different (is there even such an edge for LVDS panel?). What we care about specifying here is the edge on which the FIN3385 samples the data on the Parallel bus, and that is a property of the FIN3385, because that is configured via a dedicated pin on the FIN3385. > The property tell when data are sampled and the FIN3385 Parallel-to-LVDS > is the one that transmit the data - not then one that samples the data. > Correct? Not correct I'm afraid, see above. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/5] RDMA/uverbs: Add uverbs command for dma-buf based MR registration
On Thu, Oct 15, 2020 at 03:02:55PM -0700, Jianxin Xiong wrote:
> Implement a new uverbs ioctl method for memory registration with file
> descriptor as an extra parameter.
>
> Signed-off-by: Jianxin Xiong
> Reviewed-by: Sean Hefty
> Acked-by: Michael J. Ruhl
> Acked-by: Christian Koenig
> Acked-by: Daniel Vetter
> drivers/infiniband/core/uverbs_std_types_mr.c | 112
> ++
> include/uapi/rdma/ib_user_ioctl_cmds.h| 14
> 2 files changed, 126 insertions(+)
>
> diff --git a/drivers/infiniband/core/uverbs_std_types_mr.c
> b/drivers/infiniband/core/uverbs_std_types_mr.c
> index 9b22bb5..e54459f 100644
> +++ b/drivers/infiniband/core/uverbs_std_types_mr.c
> @@ -1,5 +1,6 @@
> /*
> * Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
> + * Copyright (c) 2020, Intel Corporation. All rights reserved.
> *
> * This software is available to you under a choice of one of two
> * licenses. You may choose to be licensed under the terms of the GNU
> @@ -178,6 +179,85 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_MR)(
> return IS_UVERBS_COPY_ERR(ret) ? ret : 0;
> }
>
> +static int UVERBS_HANDLER(UVERBS_METHOD_REG_DMABUF_MR)(
> + struct uverbs_attr_bundle *attrs)
> +{
> + struct ib_uobject *uobj =
> + uverbs_attr_get_uobject(attrs,
> UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
> + struct ib_pd *pd =
> + uverbs_attr_get_obj(attrs, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE);
> + struct ib_device *ib_dev = pd->device;
> +
> + u64 start, length, virt_addr;
> + u32 fd, access_flags;
> + struct ib_mr *mr;
> + int ret;
> +
> + if (!ib_dev->ops.reg_user_mr_dmabuf)
> + return -EOPNOTSUPP;
> +
> + ret = uverbs_copy_from(, attrs,
> +UVERBS_ATTR_REG_DMABUF_MR_ADDR);
This should be called OFFSET uniformly here and in all the call chain
below. Not start and not addr.
> + if (ret)
> + return ret;
> +
> + ret = uverbs_copy_from(, attrs,
> +UVERBS_ATTR_REG_DMABUF_MR_LENGTH);
> + if (ret)
> + return ret;
> +
> + ret = uverbs_copy_from(_addr, attrs,
> +UVERBS_ATTR_REG_DMABUF_MR_HCA_VA);
I've been trying to call this IOVA
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/5] RDMA/umem: Support importing dma-buf as user memory region
On Sat, Oct 17, 2020 at 12:57:21AM +, Xiong, Jianxin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, October 16, 2020 5:28 PM
> > To: Xiong, Jianxin
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug
> > Ledford ; Leon Romanovsky
> > ; Sumit Semwal ; Christian Koenig
> > ; Vetter, Daniel
> >
> > Subject: Re: [PATCH v5 1/5] RDMA/umem: Support importing dma-buf as user
> > memory region
> >
> > On Thu, Oct 15, 2020 at 03:02:45PM -0700, Jianxin Xiong wrote:
> > > +struct ib_umem *ib_umem_dmabuf_get(struct ib_device *device,
> > > +unsigned long addr, size_t size,
> > > +int dmabuf_fd, int access,
> > > +const struct ib_umem_dmabuf_ops *ops) {
> > > + struct dma_buf *dmabuf;
> > > + struct ib_umem_dmabuf *umem_dmabuf;
> > > + struct ib_umem *umem;
> > > + unsigned long end;
> > > + long ret;
> > > +
> > > + if (check_add_overflow(addr, (unsigned long)size, ))
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + if (unlikely(PAGE_ALIGN(end) < PAGE_SIZE))
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + if (unlikely(!ops || !ops->invalidate || !ops->update))
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + umem_dmabuf = kzalloc(sizeof(*umem_dmabuf), GFP_KERNEL);
> > > + if (!umem_dmabuf)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + umem_dmabuf->ops = ops;
> > > + INIT_WORK(_dmabuf->work, ib_umem_dmabuf_work);
> > > +
> > > + umem = _dmabuf->umem;
> > > + umem->ibdev = device;
> > > + umem->length = size;
> > > + umem->address = addr;
> >
> > addr here is offset within the dma buf, but this code does nothing with it.
> >
> The current code assumes 0 offset, and 'addr' is the nominal starting address
> of the
> buffer. If this is to be changed to offset, then yes, some more handling is
> needed
> as you mentioned below.
There is no such thing as 'nominal starting address'
If the user is to provide any argument it can only be offset and length.
> > Also, dma_buf_map_attachment() does not do the correct dma mapping
> > for RDMA, eg it does not use ib_dma_map(). This is not a problem
> > for mlx5 but it is troublesome to put in the core code.
>
> ib_dma_map() uses dma_map_single(), GPU drivers use dma_map_resource() for
> dma_buf_map_attachment(). They belong to the same family, but take different
> address type (kernel address vs MMIO physical address). Could you elaborate
> what
> the problem could be for non-mlx5 HCAs?
They use the virtual dma ops which we intend to remove
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v3] drm/msm: Fix race condition in msm driver with async layer updates
When there are back to back commits with async cursor update,
there is a case where second commit can program the DPU hw
blocks while first didn't complete flushing config to HW.
Synchronize the compositions such that second commit waits
until first commit flushes the composition.
This change also introduces per crtc commit lock, such that
commits on different crtcs are not blocked by each other.
Changes in v2:
- Use an array of mutexes in kms to handle commit
lock per crtc. (Rob Clark)
Changes in v3:
- Add wrapper functions to handle lock and unlock of
commit_lock for each crtc. (Rob Clark)
Signed-off-by: Krishna Manikandan
---
drivers/gpu/drm/msm/msm_atomic.c | 37 -
drivers/gpu/drm/msm/msm_kms.h| 6 --
2 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 561bfa4..575e9af 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -55,16 +55,32 @@ static void vblank_put(struct msm_kms *kms, unsigned
crtc_mask)
}
}
+static void lock_crtcs(struct msm_kms *kms, unsigned int crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask)
+ mutex_lock(>commit_lock[drm_crtc_index(crtc)]);
+}
+
+static void unlock_crtcs(struct msm_kms *kms, unsigned int crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask)
+ mutex_unlock(>commit_lock[drm_crtc_index(crtc)]);
+}
+
static void msm_atomic_async_commit(struct msm_kms *kms, int crtc_idx)
{
unsigned crtc_mask = BIT(crtc_idx);
trace_msm_atomic_async_commit_start(crtc_mask);
- mutex_lock(>commit_lock);
+ lock_crtcs(kms, crtc_mask);
if (!(kms->pending_crtc_mask & crtc_mask)) {
- mutex_unlock(>commit_lock);
+ unlock_crtcs(kms, crtc_mask);
goto out;
}
@@ -79,7 +95,6 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
*/
trace_msm_atomic_flush_commit(crtc_mask);
kms->funcs->flush_commit(kms, crtc_mask);
- mutex_unlock(>commit_lock);
/*
* Wait for flush to complete:
@@ -90,9 +105,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
vblank_put(kms, crtc_mask);
- mutex_lock(>commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
- mutex_unlock(>commit_lock);
+ unlock_crtcs(kms, crtc_mask);
kms->funcs->disable_commit(kms);
out:
@@ -189,12 +203,11 @@ void msm_atomic_commit_tail(struct drm_atomic_state
*state)
* Ensure any previous (potentially async) commit has
* completed:
*/
+ lock_crtcs(kms, crtc_mask);
trace_msm_atomic_wait_flush_start(crtc_mask);
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
- mutex_lock(>commit_lock);
-
/*
* Now that there is no in-progress flush, prepare the
* current update:
@@ -232,8 +245,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
}
kms->funcs->disable_commit(kms);
- mutex_unlock(>commit_lock);
-
+ unlock_crtcs(kms, crtc_mask);
/*
* At this point, from drm core's perspective, we
* are done with the atomic update, so we can just
@@ -260,8 +272,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
*/
trace_msm_atomic_flush_commit(crtc_mask);
kms->funcs->flush_commit(kms, crtc_mask);
- mutex_unlock(>commit_lock);
-
+ unlock_crtcs(kms, crtc_mask);
/*
* Wait for flush to complete:
*/
@@ -271,9 +282,9 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
vblank_put(kms, crtc_mask);
- mutex_lock(>commit_lock);
+ lock_crtcs(kms, crtc_mask);
kms->funcs->complete_commit(kms, crtc_mask);
- mutex_unlock(>commit_lock);
+ unlock_crtcs(kms, crtc_mask);
kms->funcs->disable_commit(kms);
drm_atomic_helper_commit_hw_done(state);
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 1cbef6b..2049847 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -155,7 +155,7 @@ struct msm_kms {
* For async commit, where ->flush_commit() and later happens
* from the crtc's pending_timer close to end of the frame:
*/
- struct mutex commit_lock;
+ struct mutex commit_lock[MAX_CRTCS];
unsigned pending_crtc_mask;
struct msm_pending_timer pending_timers[MAX_CRTCS];
};
@@ -165,7 +165,9 @@ static inline void msm_kms_init(struct msm_kms *kms,
{
unsigned i;
- mutex_init(>commit_lock);
+ for
[PATCH 1/3] drm/sun4i: frontend: Rework a bit the phase data
The scaler filter phase setup in the allwinner kernel has two different
cases for setting up the scaler filter, the first one using different phase
parameters for the two channels, and the second one reusing the first
channel parameters on the second channel.
The allwinner kernel has a third option where the horizontal phase of the
second channel will be set to a different value than the vertical one (and
seems like it's the same value than one used on the first channel).
However, that code path seems to never be taken, so we can ignore it for
now, and it's essentially what we're doing so far as well.
Since we will have always the same values across each components of the
filter setup for a given channel, we can simplify a bit our frontend
structure by only storing the phase value we want to apply to a given
channel.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 34 ++
drivers/gpu/drm/sun4i/sun4i_frontend.h | 6 +
2 files changed, 9 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index ec2a032e07b9..7462801b1fa8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -443,17 +443,17 @@ int sun4i_frontend_update_formats(struct sun4i_frontend
*frontend,
* related to the scaler FIR filter phase parameters.
*/
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG,
-frontend->data->ch_phase[0].horzphase);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG,
-frontend->data->ch_phase[1].horzphase);
+frontend->data->ch_phase[1]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG,
-frontend->data->ch_phase[0].vertphase[0]);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG,
-frontend->data->ch_phase[1].vertphase[0]);
+frontend->data->ch_phase[1]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG,
-frontend->data->ch_phase[0].vertphase[1]);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG,
-frontend->data->ch_phase[1].vertphase[1]);
+frontend->data->ch_phase[1]);
/*
* Checking the input format is sufficient since we currently only
@@ -687,30 +687,12 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
};
static const struct sun4i_frontend_data sun4i_a10_frontend = {
- .ch_phase = {
- {
- .horzphase = 0,
- .vertphase = { 0, 0 },
- },
- {
- .horzphase = 0xfc000,
- .vertphase = { 0xfc000, 0xfc000 },
- },
- },
+ .ch_phase = { 0x000, 0xfc000 },
.has_coef_rdy = true,
};
static const struct sun4i_frontend_data sun8i_a33_frontend = {
- .ch_phase = {
- {
- .horzphase = 0x400,
- .vertphase = { 0x400, 0x400 },
- },
- {
- .horzphase = 0x400,
- .vertphase = { 0x400, 0x400 },
- },
- },
+ .ch_phase = { 0x400, 0x400 },
.has_coef_access_ctrl = true,
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h
b/drivers/gpu/drm/sun4i/sun4i_frontend.h
index 0c382c1ddb0f..2e7b76e50c2b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h
@@ -115,11 +115,7 @@ struct reset_control;
struct sun4i_frontend_data {
boolhas_coef_access_ctrl;
boolhas_coef_rdy;
-
- struct {
- u32 horzphase;
- u32 vertphase[2];
- } ch_phase[2];
+ u32 ch_phase[2];
};
struct sun4i_frontend {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] mm: introduce vma_set_file function v4
On Mon, Oct 12, 2020 at 10:52:03AM +0200, Christian König wrote: > Add the new vma_set_file() function to allow changing > vma->vm_file with the necessary refcount dance. > > v2: add more users of this. > v3: add missing EXPORT_SYMBOL, rebase on mmap cleanup, > add comments why we drop the reference on two occasions. > v4: make it clear that changing an anonymous vma is illegal. > > Signed-off-by: Christian König > Reviewed-by: Daniel Vetter (v2) > --- > drivers/dma-buf/dma-buf.c | 3 +-- > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +--- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 +-- > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 5 +++-- > drivers/gpu/drm/msm/msm_gem.c | 4 +--- > drivers/gpu/drm/omapdrm/omap_gem.c | 3 +-- > drivers/gpu/drm/vgem/vgem_drv.c| 3 +-- > drivers/staging/android/ashmem.c | 6 +++--- > include/linux/mm.h | 2 ++ > mm/mmap.c | 12 > 10 files changed, 26 insertions(+), 19 deletions(-) Reviewed-by: Jason Gunthorpe Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/5] RDMA/umem: Support importing dma-buf as user memory region
On Thu, Oct 15, 2020 at 03:02:45PM -0700, Jianxin Xiong wrote:
> +static void ib_umem_dmabuf_invalidate_cb(struct dma_buf_attachment *attach)
> +{
> + struct ib_umem_dmabuf *umem_dmabuf = attach->importer_priv;
> +
> + dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv);
> +
> + ib_umem_dmabuf_unmap_pages(_dmabuf->umem, true);
> + queue_work(ib_wq, _dmabuf->work);
Do we really want to queue remapping or should it wait until there is
a page fault?
What do GPUs do?
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm/hisilicon v3 1/2] drm/hisilicon: Use the same style of variable type in hibmc_drm_de
Consistently Use the same style of variable type in hibmc_drm_de.c.
Signed-off-by: Tian Tao
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 59 +-
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 8478a84..a1eabad 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -23,15 +23,15 @@
#include "hibmc_drm_regs.h"
struct hibmc_display_panel_pll {
- unsigned long M;
- unsigned long N;
- unsigned long OD;
- unsigned long POD;
+ u64 M;
+ u64 N;
+ u64 OD;
+ u64 POD;
};
struct hibmc_dislay_pll_config {
- unsigned long hdisplay;
- unsigned long vdisplay;
+ u64 hdisplay;
+ u64 vdisplay;
u32 pll1_config_value;
u32 pll2_config_value;
};
@@ -102,7 +102,7 @@ static void hibmc_plane_atomic_update(struct drm_plane
*plane,
struct drm_plane_state *state = plane->state;
u32 reg;
s64 gpu_addr = 0;
- unsigned int line_l;
+ u32 line_l;
struct hibmc_drm_private *priv = to_hibmc_drm_private(plane->dev);
struct drm_gem_vram_object *gbo;
@@ -155,10 +155,10 @@ static const struct drm_plane_helper_funcs
hibmc_plane_helper_funcs = {
.atomic_update = hibmc_plane_atomic_update,
};
-static void hibmc_crtc_dpms(struct drm_crtc *crtc, int dpms)
+static void hibmc_crtc_dpms(struct drm_crtc *crtc, u32 dpms)
{
struct hibmc_drm_private *priv = to_hibmc_drm_private(crtc->dev);
- unsigned int reg;
+ u32 reg;
reg = readl(priv->mmio + HIBMC_CRT_DISP_CTL);
reg &= ~HIBMC_CRT_DISP_CTL_DPMS_MASK;
@@ -172,7 +172,7 @@ static void hibmc_crtc_dpms(struct drm_crtc *crtc, int dpms)
static void hibmc_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- unsigned int reg;
+ u32 reg;
struct hibmc_drm_private *priv = to_hibmc_drm_private(crtc->dev);
hibmc_set_power_mode(priv, HIBMC_PW_MODE_CTL_MODE_MODE0);
@@ -191,7 +191,7 @@ static void hibmc_crtc_atomic_enable(struct drm_crtc *crtc,
static void hibmc_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- unsigned int reg;
+ u32 reg;
struct hibmc_drm_private *priv = to_hibmc_drm_private(crtc->dev);
hibmc_crtc_dpms(crtc, HIBMC_CRT_DPMS_OFF);
@@ -212,7 +212,7 @@ static enum drm_mode_status
hibmc_crtc_mode_valid(struct drm_crtc *crtc,
const struct drm_display_mode *mode)
{
- int i = 0;
+ size_t i = 0;
int vrefresh = drm_mode_vrefresh(mode);
if (vrefresh < 59 || vrefresh > 61)
@@ -227,9 +227,9 @@ hibmc_crtc_mode_valid(struct drm_crtc *crtc,
return MODE_BAD;
}
-static unsigned int format_pll_reg(void)
+static u32 format_pll_reg(void)
{
- unsigned int pllreg = 0;
+ u32 pllreg = 0;
struct hibmc_display_panel_pll pll = {0};
/*
@@ -249,7 +249,7 @@ static unsigned int format_pll_reg(void)
return pllreg;
}
-static void set_vclock_hisilicon(struct drm_device *dev, unsigned long pll)
+static void set_vclock_hisilicon(struct drm_device *dev, u64 pll)
{
u32 val;
struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
@@ -279,11 +279,10 @@ static void set_vclock_hisilicon(struct drm_device *dev,
unsigned long pll)
writel(val, priv->mmio + CRT_PLL1_HS);
}
-static void get_pll_config(unsigned long x, unsigned long y,
- u32 *pll1, u32 *pll2)
+static void get_pll_config(u64 x, u64 y, u32 *pll1, u32 *pll2)
{
- int i;
- int count = ARRAY_SIZE(hibmc_pll_table);
+ size_t i;
+ size_t count = ARRAY_SIZE(hibmc_pll_table);
for (i = 0; i < count; i++) {
if (hibmc_pll_table[i].hdisplay == x &&
@@ -306,11 +305,11 @@ static void get_pll_config(unsigned long x, unsigned long
y,
* FPGA only supports 7 predefined pixel clocks, and clock select is
* in bit 4:0 of new register 0x802a8.
*/
-static unsigned int display_ctrl_adjust(struct drm_device *dev,
- struct drm_display_mode *mode,
- unsigned int ctrl)
+static u32 display_ctrl_adjust(struct drm_device *dev,
+ struct drm_display_mode *mode,
+ u32 ctrl)
{
- unsigned long x, y;
+ u64 x, y;
u32 pll1; /* bit[31:0] of PLL */
u32 pll2; /* bit[63:32] of PLL */
struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
@@ -358,12 +357,12 @@ static unsigned int display_ctrl_adjust(struct drm_device
*dev,
static void hibmc_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
- unsigned int val;
[PATCH drm/hisilicon v3 0/2] Use the same style of variable type
patch #1 and #2 Use the same style of variable type in hisilicon drm driver and both are clean up, no actual functional changes. Changes since v1: -Change part of unsigned int to size_t. Changes since v2: -Modify the type of fb_base and fb_size to resource_size_t. Tian Tao (2): drm/hisilicon: Use the same style of variable type in hibmc_drm_de drm/hisilicon: Use the same style of variable type in hibmc_drm_drv drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 59 - drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 +++--- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 8 ++-- 3 files changed, 39 insertions(+), 41 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Cocci] [RFC] treewide: cleanup unreachable breaks
On Sat, 17 Oct 2020, Joe Perches wrote: > On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote: > > From: Tom Rix > > > > This is a upcoming change to clean up a new warning treewide. > > I am wondering if the change could be one mega patch (see below) or > > normal patch per file about 100 patches or somewhere half way by collecting > > early acks. > > > > clang has a number of useful, new warnings see > > https://clang.llvm.org/docs/DiagnosticsReference.html > > > > This change cleans up -Wunreachable-code-break > > https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break > > for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64. > > Early acks/individual patches by subsystem would be good. > Better still would be an automated cocci script. Coccinelle is not especially good at this, because it is based on control flow, and a return or goto diverts the control flow away from the break. A hack to solve the problem is to put an if around the return or goto, but that gives the break a meaningless file name and line number. I collected the following list, but it only has 439 results, so fewer than clang. But maybe there are some files that are not considered by clang in the x86 allyesconfig configuration. Probably checkpatch is the best solution here, since it is not configuration sensitive and doesn't care about control flow. julia drivers/scsi/mvumi.c: function mvumi_cfg_hw_reg line 114 drivers/watchdog/geodewdt.c: function geodewdt_ioctl line 18 drivers/media/usb/b2c2/flexcop-usb.c: function flexcop_usb_init line 21 drivers/media/usb/b2c2/flexcop-usb.c: function flexcop_usb_memory_req line 20 drivers/tty/nozomi.c: function write_mem32 line 17 drivers/tty/nozomi.c: function write_mem32 line 25 drivers/tty/nozomi.c: function read_mem32 line 17 drivers/tty/nozomi.c: function read_mem32 line 21 sound/soc/codecs/wl1273.c: function wl1273_startup line 27 drivers/iio/adc/meson_saradc.c: function meson_sar_adc_iio_info_read_raw line 12 drivers/iio/adc/meson_saradc.c: function meson_sar_adc_iio_info_read_raw line 19 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c: function map_transmitter_id_to_phy_instance line 6 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c: function map_transmitter_id_to_phy_instance line 9 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c: function map_transmitter_id_to_phy_instance line 12 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c: function map_transmitter_id_to_phy_instance line 15 drivers/media/tuners/mt2063.c: function mt2063_init line 81 drivers/nfc/st21nfca/core.c: function st21nfca_hci_im_transceive line 46 arch/sh/boards/mach-landisk/gio.c: function gio_ioctl line 53 drivers/gpu/drm/mgag200/mgag200_mode.c: function mgag200_crtc_set_plls line 11 drivers/gpu/drm/mgag200/mgag200_mode.c: function mgag200_crtc_set_plls line 15 drivers/gpu/drm/mgag200/mgag200_mode.c: function mgag200_crtc_set_plls line 18 drivers/gpu/drm/mgag200/mgag200_mode.c: function mgag200_crtc_set_plls line 22 drivers/gpu/drm/mgag200/mgag200_mode.c: function mgag200_crtc_set_plls line 25 drivers/media/dvb-frontends/cx24117.c: function cx24117_attach line 16 drivers/block/xen-blkback/blkback.c: function dispatch_rw_block_io line 48 drivers/platform/x86/sony-laptop.c: function __sony_nc_gfx_switch_status_get line 16 drivers/platform/x86/sony-laptop.c: function __sony_nc_gfx_switch_status_get line 22 drivers/platform/x86/sony-laptop.c: function __sony_nc_gfx_switch_status_get line 31 drivers/char/mwave/mwavedd.c: function mwave_ioctl line 288 drivers/scsi/be2iscsi/be_mgmt.c: function beiscsi_adap_family_disp line 15 drivers/scsi/be2iscsi/be_mgmt.c: function beiscsi_adap_family_disp line 19 drivers/scsi/be2iscsi/be_mgmt.c: function beiscsi_adap_family_disp line 22 drivers/scsi/be2iscsi/be_mgmt.c: function beiscsi_adap_family_disp line 27 drivers/iio/imu/bmi160/bmi160_core.c: function bmi160_write_raw line 11 drivers/block/z2ram.c: function z2_open line 138 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c: function _rtl8723e_set_media_status line 38 samples/hidraw/hid-example.c: function bus_str line 6 samples/hidraw/hid-example.c: function bus_str line 9 samples/hidraw/hid-example.c: function bus_str line 12 samples/hidraw/hid-example.c: function bus_str line 15 samples/hidraw/hid-example.c: function bus_str line 18 drivers/scsi/ipr.c: function ipr_pci_error_detected line 10 drivers/gpio/gpio-bd70528.c: function bd70528_gpio_set_config line 11 drivers/gpio/gpio-bd70528.c: function bd70528_gpio_set_config line 17 drivers/gpio/gpio-bd70528.c: function bd70528_gpio_set_config line 21 drivers/pinctrl/pinctrl-rockchip.c: function rockchip_pinconf_get line 71 drivers/pinctrl/pinctrl-rockchip.c: function rockchip_pinconf_set line 74 drivers/gpu/drm/amd/display/include/signal_types.h: function dc_is_dvi_signal line 6 security/keys/trusted-keys/trusted_tpm1.c: function datablob_parse line 63 arch/x86/math-emu/fpu_trig.c: function
[PATCH 2/3] drm/sun4i: frontend: Reuse the ch0 phase for RGB formats
When using the scaler on the A10-like frontend with single-planar formats, the current code will setup the channel 0 filter (used for the R or Y component) with a different phase parameter than the channel 1 filter (used for the G/B or U/V components). This creates a bleed out that keeps repeating on of the last line of the RGB plane across the rest of the display. The Allwinner BSP either applies the same phase parameter over both channels or use a separate one, the condition being whether the input format is YUV420 or not. Since YUV420 is both subsampled and multi-planar, and since YUYV is subsampled but single-planar, we can rule out the subsampling and assume that the condition is actually whether the format is single or multi-planar. And it looks like applying the same phase parameter over both channels for single-planar formats fixes our issue, while we keep the multi-planar formats working properly. Reported-by: Taras Galchenko Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c index 7462801b1fa8..d32b12cbbb60 100644 --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c @@ -407,6 +407,7 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, struct drm_framebuffer *fb = state->fb; const struct drm_format_info *format = fb->format; uint64_t modifier = fb->modifier; + unsigned ch1_phase_idx; u32 out_fmt_val; u32 in_fmt_val, in_mod_val, in_ps_val; unsigned int i; @@ -442,18 +443,19 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, * I have no idea what this does exactly, but it seems to be * related to the scaler FIR filter phase parameters. */ + ch1_phase_idx = (format->num_planes > 1) ? 1 : 0; regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG, -frontend->data->ch_phase[1]); +frontend->data->ch_phase[ch1_phase_idx]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG, -frontend->data->ch_phase[1]); +frontend->data->ch_phase[ch1_phase_idx]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG, -frontend->data->ch_phase[1]); +frontend->data->ch_phase[ch1_phase_idx]); /* * Checking the input format is sufficient since we currently only -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v1] drm/msm: Fix race condition in msm driver with async layer updates
On 2020-10-14 20:55, Rob Clark wrote:
On Wed, Oct 14, 2020 at 5:58 AM Krishna Manikandan
wrote:
When there are back to back commits with async cursor update,
there is a case where second commit can program the DPU hw
blocks while first didn't complete flushing config to HW.
Synchronize the compositions such that second commit waits
until first commit flushes the composition.
This change also introduces per crtc commit lock, such that
commits on different crtcs are not blocked by each other.
Signed-off-by: Krishna Manikandan
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 26
drivers/gpu/drm/msm/msm_atomic.c | 35
++--
drivers/gpu/drm/msm/msm_kms.h| 5 +
5 files changed, 57 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index c2729f7..9024719 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1383,6 +1383,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device
*dev, struct drm_plane *plane,
/* initialize event handling */
spin_lock_init(_crtc->event_lock);
+ mutex_init(_crtc->commit_lock);
DPU_DEBUG("%s: successfully initialized crtc\n",
dpu_crtc->name);
return crtc;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index cec3474..1eeb73d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -169,6 +169,7 @@ struct dpu_crtc {
/* for handling internal event thread */
spinlock_t event_lock;
+ struct mutex commit_lock;
struct dpu_core_perf_params cur_perf;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index c0a4d4e..f99ae7a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -445,6 +445,30 @@ static void dpu_kms_wait_flush(struct msm_kms
*kms, unsigned crtc_mask)
dpu_kms_wait_for_commit_done(kms, crtc);
}
+static void dpu_kms_commit_lock(struct msm_kms *kms, unsigned int
crtc_mask)
+{
+ struct dpu_kms *dpu_kms = to_dpu_kms(kms);
+ struct drm_crtc *crtc;
+ struct dpu_crtc *dpu_crtc;
+
+ for_each_crtc_mask(dpu_kms->dev, crtc, crtc_mask) {
+ dpu_crtc = to_dpu_crtc(crtc);
+ mutex_lock(_crtc->commit_lock);
+ }
+}
+
+static void dpu_kms_commit_unlock(struct msm_kms *kms, unsigned int
crtc_mask)
+{
+ struct dpu_kms *dpu_kms = to_dpu_kms(kms);
+ struct drm_crtc *crtc;
+ struct dpu_crtc *dpu_crtc;
+
+ for_each_crtc_mask(dpu_kms->dev, crtc, crtc_mask) {
+ dpu_crtc = to_dpu_crtc(crtc);
+ mutex_unlock(_crtc->commit_lock);
+ }
+}
+
static int _dpu_kms_initialize_dsi(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
@@ -738,6 +762,8 @@ static const struct msm_kms_funcs kms_funcs = {
#ifdef CONFIG_DEBUG_FS
.debugfs_init= dpu_kms_debugfs_init,
#endif
+ .commit_lock = dpu_kms_commit_lock,
+ .commit_unlock = dpu_kms_commit_unlock,
};
static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c
b/drivers/gpu/drm/msm/msm_atomic.c
index 561bfa4..d33253f 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -55,16 +55,32 @@ static void vblank_put(struct msm_kms *kms,
unsigned crtc_mask)
}
}
+static void msm_commit_lock(struct msm_kms *kms, unsigned int
crtc_mask)
+{
+ if (kms->funcs->commit_lock)
+ kms->funcs->commit_lock(kms, crtc_mask);
+ else
+ mutex_lock(>commit_lock);
+}
+
+static void msm_commit_unlock(struct msm_kms *kms, unsigned int
crtc_mask)
+{
+ if (kms->funcs->commit_unlock)
+ kms->funcs->commit_unlock(kms, crtc_mask);
+ else
+ mutex_unlock(>commit_lock);
+}
Hi, I think the per-crtc commit-lock, and the updated
locking/unlocking points are the right thing to do, but I don't think
we need to touch dpu for this. Just change kms->commit_lock to an
array of mutexes, and drop the vfunc indirection. All the same
locking logic applies to mdp4/mdp5 as well (ie. don't touch the hw
until it has flushed)
BR,
-R
Thanks for the comments Rob. I have addressed them in v2 patch.
Regards,
Krishna
+
static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
{
unsigned crtc_mask = BIT(crtc_idx);
trace_msm_atomic_async_commit_start(crtc_mask);
- mutex_lock(>commit_lock);
+ msm_commit_lock(kms, crtc_mask);
if (!(kms->pending_crtc_mask &
[PATCH drm/hisilicon v2 2/2] drm/hisilicon: Use the same style of variable type in hibmc_drm_drv
Consistently Use the same style of variable type in hibmc_drm_drv.c and
hibmc_drm_drv.h.
Signed-off-by: Tian Tao
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 ++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 8
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 5632bce..0c1b40d 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -121,12 +121,11 @@ static void hibmc_kms_fini(struct hibmc_drm_private *priv)
/*
* It can operate in one of three modes: 0, 1 or Sleep.
*/
-void hibmc_set_power_mode(struct hibmc_drm_private *priv,
- unsigned int power_mode)
+void hibmc_set_power_mode(struct hibmc_drm_private *priv, u32 power_mode)
{
- unsigned int control_value = 0;
+ u32 control_value = 0;
void __iomem *mmio = priv->mmio;
- unsigned int input = 1;
+ u32 input = 1;
if (power_mode > HIBMC_PW_MODE_CTL_MODE_SLEEP)
return;
@@ -144,8 +143,8 @@ void hibmc_set_power_mode(struct hibmc_drm_private *priv,
void hibmc_set_current_gate(struct hibmc_drm_private *priv, unsigned int gate)
{
- unsigned int gate_reg;
- unsigned int mode;
+ u32 gate_reg;
+ u32 mode;
void __iomem *mmio = priv->mmio;
/* Get current power mode. */
@@ -170,7 +169,7 @@ void hibmc_set_current_gate(struct hibmc_drm_private *priv,
unsigned int gate)
static void hibmc_hw_config(struct hibmc_drm_private *priv)
{
- unsigned int reg;
+ u32 reg;
/* On hardware reset, power mode 0 is default. */
hibmc_set_power_mode(priv, HIBMC_PW_MODE_CTL_MODE_MODE0);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 6a63502..5c4030d 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -33,8 +33,8 @@ struct hibmc_drm_private {
/* hw */
void __iomem *mmio;
void __iomem *fb_map;
- unsigned long fb_base;
- unsigned long fb_size;
+ u64 fb_base;
+ u64 fb_size;
/* drm */
struct drm_device *dev;
@@ -56,9 +56,9 @@ static inline struct hibmc_drm_private
*to_hibmc_drm_private(struct drm_device *
}
void hibmc_set_power_mode(struct hibmc_drm_private *priv,
- unsigned int power_mode);
+ u32 power_mode);
void hibmc_set_current_gate(struct hibmc_drm_private *priv,
- unsigned int gate);
+ u32 gate);
int hibmc_de_init(struct hibmc_drm_private *priv);
int hibmc_vdac_init(struct hibmc_drm_private *priv);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3] drm/bridge: lvds-codec: Add support for regulator
Hi Sam,
> Subject: Re: [PATCH v3] drm/bridge: lvds-codec: Add support for regulator
>
> Hi Biju, Laurent
>
> On Tue, Sep 22, 2020 at 01:55:26PM +0300, Laurent Pinchart wrote:
> > From: Biju Das
> >
> > Add the support for enabling optional regulator that may be used as
> > VCC source.
> >
> > Signed-off-by: Biju Das
> > Reviewed-by: Laurent Pinchart
> > [Replaced 'error' variable with 'ret'] [Renamed regulator from 'vcc'
> > to 'power']
> > Signed-off-by: Laurent Pinchart
> >
>
> Applied to drm-misc-next.
> Biju, could you make a follow-up patch that introduces dev_err_probe()
> where appropriate? I did not fix up the code but this was a good candidate.
Ok, sure will do.
Thanks,
Biju
>
> Sam
>
> > ---
> > Changes since v2:
> >
> > - Use the correct regulator name
> > ---
> > drivers/gpu/drm/bridge/lvds-codec.c | 29
> > +
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > b/drivers/gpu/drm/bridge/lvds-codec.c
> > index f19d9f7a5db2..f52ccffc1bd1 100644
> > --- a/drivers/gpu/drm/bridge/lvds-codec.c
> > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > @@ -10,13 +10,16 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> >
> > struct lvds_codec {
> > + struct device *dev;
> > struct drm_bridge bridge;
> > struct drm_bridge *panel_bridge;
> > + struct regulator *vcc;
> > struct gpio_desc *powerdown_gpio;
> > u32 connector_type;
> > };
> > @@ -38,6 +41,14 @@ static int lvds_codec_attach(struct drm_bridge
> > *bridge, static void lvds_codec_enable(struct drm_bridge *bridge) {
> > struct lvds_codec *lvds_codec = to_lvds_codec(bridge);
> > + int ret;
> > +
> > + ret = regulator_enable(lvds_codec->vcc);
> > + if (ret) {
> > + dev_err(lvds_codec->dev,
> > + "Failed to enable regulator \"vcc\": %d\n", ret);
> > + return;
> > + }
> >
> > if (lvds_codec->powerdown_gpio)
> > gpiod_set_value_cansleep(lvds_codec->powerdown_gpio,
> 0); @@ -46,9
> > +57,15 @@ static void lvds_codec_enable(struct drm_bridge *bridge)
> > static void lvds_codec_disable(struct drm_bridge *bridge) {
> > struct lvds_codec *lvds_codec = to_lvds_codec(bridge);
> > + int ret;
> >
> > if (lvds_codec->powerdown_gpio)
> > gpiod_set_value_cansleep(lvds_codec->powerdown_gpio,
> 1);
> > +
> > + ret = regulator_disable(lvds_codec->vcc);
> > + if (ret)
> > + dev_err(lvds_codec->dev,
> > + "Failed to disable regulator \"vcc\": %d\n", ret);
> > }
> >
> > static const struct drm_bridge_funcs funcs = { @@ -63,12 +80,24 @@
> > static int lvds_codec_probe(struct platform_device *pdev)
> > struct device_node *panel_node;
> > struct drm_panel *panel;
> > struct lvds_codec *lvds_codec;
> > + int ret;
> >
> > lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
> > if (!lvds_codec)
> > return -ENOMEM;
> >
> > + lvds_codec->dev = >dev;
> > lvds_codec->connector_type =
> > (uintptr_t)of_device_get_match_data(dev);
> > +
> > + lvds_codec->vcc = devm_regulator_get(lvds_codec->dev, "power");
> > + if (IS_ERR(lvds_codec->vcc)) {
> > + ret = PTR_ERR(lvds_codec->vcc);
> > + if (ret != -EPROBE_DEFER)
> > + dev_err(lvds_codec->dev,
> > + "Unable to get \"vcc\" supply: %d\n", ret);
> > + return ret;
> > + }
> > +
> > lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev,
> "powerdown",
> >
> GPIOD_OUT_HIGH);
> > if (IS_ERR(lvds_codec->powerdown_gpio))
> > --
> > Regards,
> >
> > Laurent Pinchart
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm/hisilicon v2 0/2] Use the same style of variable type
patch #1 and #2 Use the same style of variable type in hisilicon drm driver and both are clean up, no actual functional changes. Changes since v1: -Change part of unsigned int to size_t. Tian Tao (2): drm/hisilicon: Use the same style of variable type in hibmc_drm_de drm/hisilicon: Use the same style of variable type in hibmc_drm_drv drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 59 - drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 +++--- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 8 ++-- 3 files changed, 39 insertions(+), 41 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/4] Add a RPMSG driver for the APU in the mt8183
On Wed, Oct 14, 2020 at 04:55:34PM -0600, Mathieu Poirier wrote:
> Hi Alexandre,
>
> On Wed, Sep 30, 2020 at 01:53:47PM +0200, Alexandre Bailon wrote:
> > This adds a driver to communicate with the APU available
> > in the mt8183. The driver is generic and could be used for other APU.
> > It mostly provides a userspace interface to send messages and
> > and share big buffers with the APU.
> >
> > Signed-off-by: Alexandre Bailon
> > ---
> > drivers/rpmsg/Kconfig | 9 +
> > drivers/rpmsg/Makefile | 1 +
> > drivers/rpmsg/apu_rpmsg.c | 606 +
> > drivers/rpmsg/apu_rpmsg.h | 52 +++
> > include/uapi/linux/apu_rpmsg.h | 36 ++
> > 5 files changed, 704 insertions(+)
> > create mode 100644 drivers/rpmsg/apu_rpmsg.c
> > create mode 100644 drivers/rpmsg/apu_rpmsg.h
> > create mode 100644 include/uapi/linux/apu_rpmsg.h
> >
> > diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> > index f96716893c2a..3437c6fc8647 100644
> > --- a/drivers/rpmsg/Kconfig
> > +++ b/drivers/rpmsg/Kconfig
> > @@ -64,4 +64,13 @@ config RPMSG_VIRTIO
> > select RPMSG
> > select VIRTIO
> >
> > +config RPMSG_APU
> > + tristate "APU RPMSG driver"
> > + help
> > + This provides a RPMSG driver that provides some facilities to
> > + communicate with an accelerated processing unit (APU).
> > + This creates one or more char files that could be used by userspace
> > + to send a message to an APU. In addition, this also take care of
> > + sharing the memory buffer with the APU.
> > +
> > endmenu
> > diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
> > index ffe932ef6050..93e0f3de99c9 100644
> > --- a/drivers/rpmsg/Makefile
> > +++ b/drivers/rpmsg/Makefile
> > @@ -8,3 +8,4 @@ obj-$(CONFIG_RPMSG_QCOM_GLINK_RPM) += qcom_glink_rpm.o
> > obj-$(CONFIG_RPMSG_QCOM_GLINK_SMEM) += qcom_glink_smem.o
> > obj-$(CONFIG_RPMSG_QCOM_SMD) += qcom_smd.o
> > obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
> > +obj-$(CONFIG_RPMSG_APU)+= apu_rpmsg.o
> > diff --git a/drivers/rpmsg/apu_rpmsg.c b/drivers/rpmsg/apu_rpmsg.c
> > new file mode 100644
> > index ..5131b8b8e1f2
> > --- /dev/null
> > +++ b/drivers/rpmsg/apu_rpmsg.c
> > @@ -0,0 +1,606 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +//
> > +// Copyright 2020 BayLibre SAS
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "rpmsg_internal.h"
> > +
> > +#include
> > +
> > +#include "apu_rpmsg.h"
> > +
> > +/* Maximum of APU devices supported */
> > +#define APU_DEV_MAX 2
> > +
> > +#define dev_to_apu(dev) container_of(dev, struct rpmsg_apu, dev)
> > +#define cdev_to_apu(i_cdev) container_of(i_cdev, struct rpmsg_apu, cdev)
> > +
> > +struct rpmsg_apu {
> > + struct rpmsg_device *rpdev;
> > + struct cdev cdev;
> > + struct device dev;
> > +
> > + struct rproc *rproc;
> > + struct iommu_domain *domain;
> > + struct iova_domain *iovad;
> > + int iova_limit_pfn;
> > +};
> > +
> > +struct rpmsg_request {
> > + struct completion completion;
> > + struct list_head node;
> > + void *req;
> > +};
> > +
> > +struct apu_buffer {
> > + int fd;
> > + struct dma_buf *dma_buf;
> > + struct dma_buf_attachment *attachment;
> > + struct sg_table *sg_table;
> > + u32 iova;
> > +};
> > +
> > +/*
> > + * Shared IOVA domain.
> > + * The MT8183 has two VP6 core but they are sharing the IOVA.
> > + * They could be used alone, or together. In order to avoid conflict,
> > + * create an IOVA domain that could be shared by those two core.
> > + * @iovad: The IOVA domain to share between the APU cores
> > + * @refcount: Allow to automatically release the IOVA domain once all the
> > APU
> > + *cores has been stopped
> > + */
> > +struct apu_iova_domain {
> > + struct iova_domain iovad;
> > + struct kref refcount;
> > +};
> > +
> > +static dev_t rpmsg_major;
> > +static DEFINE_IDA(rpmsg_ctrl_ida);
> > +static DEFINE_IDA(rpmsg_minor_ida);
> > +static DEFINE_IDA(req_ida);
> > +static LIST_HEAD(requests);
> > +static struct apu_iova_domain *apu_iovad;
> > +
> > +static int apu_rpmsg_callback(struct rpmsg_device *dev, void *data, int
> > count,
> > + void *priv, u32 addr)
> > +{
> > + struct rpmsg_request *rpmsg_req;
> > + struct apu_dev_request *hdr = data;
> > +
> > + list_for_each_entry(rpmsg_req, , node) {
> > + struct apu_dev_request *tmp_hdr = rpmsg_req->req;
> > +
> > + if (hdr->id == tmp_hdr->id) {
> > + memcpy(rpmsg_req->req, data, count);
> > + complete(_req->completion);
> > +
> > + return 0;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int apu_device_memory_map(struct rpmsg_apu *apu,
> > +struct apu_buffer *buffer)
> > +{
> > + struct
[v2] drm/msm: Fix race condition in msm driver with async layer updates
When there are back to back commits with async cursor update,
there is a case where second commit can program the DPU hw
blocks while first didn't complete flushing config to HW.
Synchronize the compositions such that second commit waits
until first commit flushes the composition.
This change also introduces per crtc commit lock, such that
commits on different crtcs are not blocked by each other.
Changes in v2:
- Use an array of mutexes in kms to handle commit
lock per crtc. (Rob Clark)
Signed-off-by: Krishna Manikandan
---
drivers/gpu/drm/msm/msm_atomic.c | 32 +++-
drivers/gpu/drm/msm/msm_kms.h| 6 --
2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 561bfa4..f9bd472 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -61,10 +61,10 @@ static void msm_atomic_async_commit(struct msm_kms *kms,
int crtc_idx)
trace_msm_atomic_async_commit_start(crtc_mask);
- mutex_lock(>commit_lock);
+ mutex_lock(>commit_lock[crtc_idx]);
if (!(kms->pending_crtc_mask & crtc_mask)) {
- mutex_unlock(>commit_lock);
+ mutex_unlock(>commit_lock[crtc_idx]);
goto out;
}
@@ -79,7 +79,6 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
*/
trace_msm_atomic_flush_commit(crtc_mask);
kms->funcs->flush_commit(kms, crtc_mask);
- mutex_unlock(>commit_lock);
/*
* Wait for flush to complete:
@@ -90,9 +89,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
vblank_put(kms, crtc_mask);
- mutex_lock(>commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
- mutex_unlock(>commit_lock);
+ mutex_unlock(>commit_lock[crtc_idx]);
kms->funcs->disable_commit(kms);
out:
@@ -171,6 +169,16 @@ static unsigned get_crtc_mask(struct drm_atomic_state
*state)
return mask;
}
+static int get_crtc_id(struct msm_kms *kms, unsigned int crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask)
+ return drm_crtc_index(crtc);
+
+ return 0;
+}
+
void msm_atomic_commit_tail(struct drm_atomic_state *state)
{
struct drm_device *dev = state->dev;
@@ -180,6 +188,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
unsigned crtc_mask = get_crtc_mask(state);
bool async = kms->funcs->vsync_time &&
can_do_async(state, _crtc);
+ int crtc_idx = get_crtc_id(kms, crtc_mask);
trace_msm_atomic_commit_tail_start(async, crtc_mask);
@@ -189,12 +198,11 @@ void msm_atomic_commit_tail(struct drm_atomic_state
*state)
* Ensure any previous (potentially async) commit has
* completed:
*/
+ mutex_lock(>commit_lock[crtc_idx]);
trace_msm_atomic_wait_flush_start(crtc_mask);
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
- mutex_lock(>commit_lock);
-
/*
* Now that there is no in-progress flush, prepare the
* current update:
@@ -232,8 +240,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
}
kms->funcs->disable_commit(kms);
- mutex_unlock(>commit_lock);
-
+ mutex_unlock(>commit_lock[crtc_idx]);
/*
* At this point, from drm core's perspective, we
* are done with the atomic update, so we can just
@@ -260,8 +267,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
*/
trace_msm_atomic_flush_commit(crtc_mask);
kms->funcs->flush_commit(kms, crtc_mask);
- mutex_unlock(>commit_lock);
-
+ mutex_unlock(>commit_lock[crtc_idx]);
/*
* Wait for flush to complete:
*/
@@ -271,9 +277,9 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
vblank_put(kms, crtc_mask);
- mutex_lock(>commit_lock);
+ mutex_lock(>commit_lock[crtc_idx]);
kms->funcs->complete_commit(kms, crtc_mask);
- mutex_unlock(>commit_lock);
+ mutex_unlock(>commit_lock[crtc_idx]);
kms->funcs->disable_commit(kms);
drm_atomic_helper_commit_hw_done(state);
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 1cbef6b..2049847 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -155,7 +155,7 @@ struct msm_kms {
* For async commit, where ->flush_commit() and later happens
* from the crtc's pending_timer close to end of the frame:
*/
- struct mutex commit_lock;
+ struct mutex commit_lock[MAX_CRTCS];
unsigned pending_crtc_mask;
struct msm_pending_timer pending_timers[MAX_CRTCS];
};
@@
Re: [PATCH v5 4/5] RDMA/mlx5: Support dma-buf based userspace memory region
On Fri, Oct 16, 2020 at 06:40:01AM +, Xiong, Jianxin wrote:
> > > + if (!mr)
> > > + return -EINVAL;
> > > +
> > > + return mlx5_ib_update_xlt(mr, 0, mr->npages, PAGE_SHIFT, flags); }
> > > +
> > > +static struct ib_umem_dmabuf_ops mlx5_ib_umem_dmabuf_ops = {
> > > + .init = mlx5_ib_umem_dmabuf_xlt_init,
> > > + .update = mlx5_ib_umem_dmabuf_xlt_update,
> > > + .invalidate = mlx5_ib_umem_dmabuf_xlt_invalidate,
> > > +};
> >
> > I'm not really convinced these should be ops, this is usually a bad design
> > pattern.
> >
> > Why do I need so much code to extract the sgl from the dma_buf? I would
> > prefer the dma_buf layer simplify this, not by adding a wrapper
> > around it in the IB core code...
> >
>
> We just need a way to call a device specific function to update the NIC's
> translation
> table. I considered three ways: (1) ops registered with ib_umem_get_dmabuf;
> (2) a single function pointer registered with ib_umem_get_dmabuf; (3) a
> method
> in 'struct ib_device'. Option (1) was chosen here with no strong reason. We
> could
> consolidate the three functions of the ops into one, but then we will need to
> define commands or flags for different update operations.
I'd rather the driver directly provide the dma_buf ops.. Inserting
layers that do nothing be call other layers is usually a bad idea. I
didn't look carefully yet at how that would be arranged.
> > > + ncont = npages;
> > > + order = ilog2(roundup_pow_of_two(ncont));
> >
> > We still need to deal with contiguity here, this ncont/npages is just
> > obfuscation.
>
> Since the pages can move, we can't take advantage of contiguity here. This
> handling
> is similar to the ODP case. The variables 'ncont' and 'page_shift' here are
> not necessary.
> They are kept just for the sake of signifying the semantics of the following
> functions that
> use them.
Well, in this case we can manage it, and the performance boost is high
enough we need to. The work on mlx5 to do it is a bit inovlved though.
> > > + err = ib_umem_dmabuf_init_mapping(umem, mr);
> > > + if (err) {
> > > + dereg_mr(dev, mr);
> > > + return ERR_PTR(err);
> > > + }
> >
> > Did you test the page fault path at all? Looks like some xarray code is
> > missing here, and this is also missing the related complex teardown
> > logic.
> >
> > Does this mean you didn't test the pagefault_dmabuf_mr() at all?
>
> Thanks for the hint. I was unable to get the test runs reaching the
> pagefault_dmabuf_mr() function. Now I have found the reason. Along
> the path of all the page fault handlers, the array "odp_mkeys" is checked
> against the mr key. Since the dmabuf mr keys are not in the list the
> handler is never called.
>
> On the other hand, it seems that pagefault_dmabuf_mr() is not needed at all.
> The pagefault is gracefully handled by retrying until the work thread finished
> programming the NIC.
This is a bug of some kind, pagefaults that can't find a mkey in the
xarray should cause completion with error.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/5] RDMA/umem: Support importing dma-buf as user memory region
On Thu, Oct 15, 2020 at 03:02:45PM -0700, Jianxin Xiong wrote:
> +struct ib_umem *ib_umem_dmabuf_get(struct ib_device *device,
> +unsigned long addr, size_t size,
> +int dmabuf_fd, int access,
> +const struct ib_umem_dmabuf_ops *ops)
> +{
> + struct dma_buf *dmabuf;
> + struct ib_umem_dmabuf *umem_dmabuf;
> + struct ib_umem *umem;
> + unsigned long end;
> + long ret;
> +
> + if (check_add_overflow(addr, (unsigned long)size, ))
> + return ERR_PTR(-EINVAL);
> +
> + if (unlikely(PAGE_ALIGN(end) < PAGE_SIZE))
> + return ERR_PTR(-EINVAL);
> +
> + if (unlikely(!ops || !ops->invalidate || !ops->update))
> + return ERR_PTR(-EINVAL);
> +
> + umem_dmabuf = kzalloc(sizeof(*umem_dmabuf), GFP_KERNEL);
> + if (!umem_dmabuf)
> + return ERR_PTR(-ENOMEM);
> +
> + umem_dmabuf->ops = ops;
> + INIT_WORK(_dmabuf->work, ib_umem_dmabuf_work);
> +
> + umem = _dmabuf->umem;
> + umem->ibdev = device;
> + umem->length = size;
> + umem->address = addr;
addr here is offset within the dma buf, but this code does nothing
with it.
dma_buf_map_attachment gives a complete SGL for the entire DMA buf,
but offset/length select a subset.
You need to edit the sgls to make them properly span the sub-range and
follow the peculiar rules for how SGLs in ib_umem's have to be
constructed.
Who validates that the total dma length of the SGL is exactly equal to
length? That is really important too.
Also, dma_buf_map_attachment() does not do the correct dma mapping for
RDMA, eg it does not use ib_dma_map(). This is not a problem for mlx5
but it is troublesome to put in the core code.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/5] RDMA/mlx5: Support dma-buf based userspace memory region
On Thu, Oct 15, 2020 at 03:02:58PM -0700, Jianxin Xiong wrote:
> Implement the new driver method 'reg_user_mr_dmabuf'. Utilize the core
> functions to import dma-buf based memory region and update the mappings.
>
> Add code to handle dma-buf related page fault.
>
> Signed-off-by: Jianxin Xiong
> Reviewed-by: Sean Hefty
> Acked-by: Michael J. Ruhl
> Acked-by: Christian Koenig
> Acked-by: Daniel Vetter
> drivers/infiniband/hw/mlx5/main.c| 2 +
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 5 ++
> drivers/infiniband/hw/mlx5/mr.c | 119
> +++
> drivers/infiniband/hw/mlx5/odp.c | 42 +
> 4 files changed, 168 insertions(+)
>
> diff --git a/drivers/infiniband/hw/mlx5/main.c
> b/drivers/infiniband/hw/mlx5/main.c
> index 89e04ca..ec4ad2f 100644
> +++ b/drivers/infiniband/hw/mlx5/main.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
> /*
> * Copyright (c) 2013-2020, Mellanox Technologies inc. All rights reserved.
> + * Copyright (c) 2020, Intel Corporation. All rights reserved.
> */
>
> #include
> @@ -4060,6 +4061,7 @@ static int mlx5_ib_enable_driver(struct ib_device *dev)
> .query_srq = mlx5_ib_query_srq,
> .query_ucontext = mlx5_ib_query_ucontext,
> .reg_user_mr = mlx5_ib_reg_user_mr,
> + .reg_user_mr_dmabuf = mlx5_ib_reg_user_mr_dmabuf,
> .req_notify_cq = mlx5_ib_arm_cq,
> .rereg_user_mr = mlx5_ib_rereg_user_mr,
> .resize_cq = mlx5_ib_resize_cq,
> diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h
> b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> index b1f2b34..65fcc18 100644
> +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> @@ -1,6 +1,7 @@
> /* SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB */
> /*
> * Copyright (c) 2013-2020, Mellanox Technologies inc. All rights reserved.
> + * Copyright (c) 2020, Intel Corporation. All rights reserved.
> */
>
> #ifndef MLX5_IB_H
> @@ -1174,6 +1175,10 @@ int mlx5_ib_create_cq(struct ib_cq *ibcq, const struct
> ib_cq_init_attr *attr,
> struct ib_mr *mlx5_ib_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
> u64 virt_addr, int access_flags,
> struct ib_udata *udata);
> +struct ib_mr *mlx5_ib_reg_user_mr_dmabuf(struct ib_pd *pd, u64 start,
> + u64 length, u64 virt_addr,
> + int dmabuf_fd, int access_flags,
> + struct ib_udata *udata);
> int mlx5_ib_advise_mr(struct ib_pd *pd,
> enum ib_uverbs_advise_mr_advice advice,
> u32 flags,
> diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
> index b261797..24750f1 100644
> +++ b/drivers/infiniband/hw/mlx5/mr.c
> @@ -1,5 +1,6 @@
> /*
> * Copyright (c) 2013-2015, Mellanox Technologies. All rights reserved.
> + * Copyright (c) 2020, Intel Corporation. All rights reserved.
> *
> * This software is available to you under a choice of one of two
> * licenses. You may choose to be licensed under the terms of the GNU
> @@ -1462,6 +1463,124 @@ struct ib_mr *mlx5_ib_reg_user_mr(struct ib_pd *pd,
> u64 start, u64 length,
> return ERR_PTR(err);
> }
>
> +static int mlx5_ib_umem_dmabuf_xlt_init(struct ib_umem *umem, void *context)
> +{
> + struct mlx5_ib_mr *mr = context;
> + int flags = MLX5_IB_UPD_XLT_ENABLE;
> +
> + if (!mr)
> + return -EINVAL;
> +
> + return mlx5_ib_update_xlt(mr, 0, mr->npages, PAGE_SHIFT, flags);
> +}
> +static int mlx5_ib_umem_dmabuf_xlt_update(struct ib_umem *umem, void
> *context)
> +{
> + struct mlx5_ib_mr *mr = context;
> + int flags = MLX5_IB_UPD_XLT_ATOMIC;
Why are these atomic? Why the strange coding style of declaring a
variable?
> + if (!mr)
> + return -EINVAL;
Why can this happen? Will dma_buf call move_notify prior to
dma_buf_map_attachment? There are locking problems if that happens.
> + return mlx5_ib_update_xlt(mr, 0, mr->npages, PAGE_SHIFT, flags);
> +}
> +
> +static int mlx5_ib_umem_dmabuf_xlt_invalidate(struct ib_umem *umem, void
> *context)
> +{
> + struct mlx5_ib_mr *mr = context;
> + int flags = MLX5_IB_UPD_XLT_ZAP | MLX5_IB_UPD_XLT_ATOMIC;
> +
> + if (!mr)
> + return -EINVAL;
> +
> + return mlx5_ib_update_xlt(mr, 0, mr->npages, PAGE_SHIFT, flags);
> +}
> +
> +static struct ib_umem_dmabuf_ops mlx5_ib_umem_dmabuf_ops = {
> + .init = mlx5_ib_umem_dmabuf_xlt_init,
> + .update = mlx5_ib_umem_dmabuf_xlt_update,
> + .invalidate = mlx5_ib_umem_dmabuf_xlt_invalidate,
> +};
I'm not really convinced these should be ops, this is usually a bad
design pattern.
Why do I need so much code to extract the sgl from the dma_buf? I
would prefer the dma_buf layer simplify this, not by adding a wrapper
around it in the IB core code...
> +struct ib_mr *mlx5_ib_reg_user_mr_dmabuf(struct ib_pd *pd, u64 start,
> +
[PATCH drm/hisilicon v2 1/2] drm/hisilicon: Use the same style of variable type in hibmc_drm_de
Consistently Use the same style of variable type in hibmc_drm_de.c.
Signed-off-by: Tian Tao
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 59 +-
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 8478a84..a1eabad 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -23,15 +23,15 @@
#include "hibmc_drm_regs.h"
struct hibmc_display_panel_pll {
- unsigned long M;
- unsigned long N;
- unsigned long OD;
- unsigned long POD;
+ u64 M;
+ u64 N;
+ u64 OD;
+ u64 POD;
};
struct hibmc_dislay_pll_config {
- unsigned long hdisplay;
- unsigned long vdisplay;
+ u64 hdisplay;
+ u64 vdisplay;
u32 pll1_config_value;
u32 pll2_config_value;
};
@@ -102,7 +102,7 @@ static void hibmc_plane_atomic_update(struct drm_plane
*plane,
struct drm_plane_state *state = plane->state;
u32 reg;
s64 gpu_addr = 0;
- unsigned int line_l;
+ u32 line_l;
struct hibmc_drm_private *priv = to_hibmc_drm_private(plane->dev);
struct drm_gem_vram_object *gbo;
@@ -155,10 +155,10 @@ static const struct drm_plane_helper_funcs
hibmc_plane_helper_funcs = {
.atomic_update = hibmc_plane_atomic_update,
};
-static void hibmc_crtc_dpms(struct drm_crtc *crtc, int dpms)
+static void hibmc_crtc_dpms(struct drm_crtc *crtc, u32 dpms)
{
struct hibmc_drm_private *priv = to_hibmc_drm_private(crtc->dev);
- unsigned int reg;
+ u32 reg;
reg = readl(priv->mmio + HIBMC_CRT_DISP_CTL);
reg &= ~HIBMC_CRT_DISP_CTL_DPMS_MASK;
@@ -172,7 +172,7 @@ static void hibmc_crtc_dpms(struct drm_crtc *crtc, int dpms)
static void hibmc_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- unsigned int reg;
+ u32 reg;
struct hibmc_drm_private *priv = to_hibmc_drm_private(crtc->dev);
hibmc_set_power_mode(priv, HIBMC_PW_MODE_CTL_MODE_MODE0);
@@ -191,7 +191,7 @@ static void hibmc_crtc_atomic_enable(struct drm_crtc *crtc,
static void hibmc_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- unsigned int reg;
+ u32 reg;
struct hibmc_drm_private *priv = to_hibmc_drm_private(crtc->dev);
hibmc_crtc_dpms(crtc, HIBMC_CRT_DPMS_OFF);
@@ -212,7 +212,7 @@ static enum drm_mode_status
hibmc_crtc_mode_valid(struct drm_crtc *crtc,
const struct drm_display_mode *mode)
{
- int i = 0;
+ size_t i = 0;
int vrefresh = drm_mode_vrefresh(mode);
if (vrefresh < 59 || vrefresh > 61)
@@ -227,9 +227,9 @@ hibmc_crtc_mode_valid(struct drm_crtc *crtc,
return MODE_BAD;
}
-static unsigned int format_pll_reg(void)
+static u32 format_pll_reg(void)
{
- unsigned int pllreg = 0;
+ u32 pllreg = 0;
struct hibmc_display_panel_pll pll = {0};
/*
@@ -249,7 +249,7 @@ static unsigned int format_pll_reg(void)
return pllreg;
}
-static void set_vclock_hisilicon(struct drm_device *dev, unsigned long pll)
+static void set_vclock_hisilicon(struct drm_device *dev, u64 pll)
{
u32 val;
struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
@@ -279,11 +279,10 @@ static void set_vclock_hisilicon(struct drm_device *dev,
unsigned long pll)
writel(val, priv->mmio + CRT_PLL1_HS);
}
-static void get_pll_config(unsigned long x, unsigned long y,
- u32 *pll1, u32 *pll2)
+static void get_pll_config(u64 x, u64 y, u32 *pll1, u32 *pll2)
{
- int i;
- int count = ARRAY_SIZE(hibmc_pll_table);
+ size_t i;
+ size_t count = ARRAY_SIZE(hibmc_pll_table);
for (i = 0; i < count; i++) {
if (hibmc_pll_table[i].hdisplay == x &&
@@ -306,11 +305,11 @@ static void get_pll_config(unsigned long x, unsigned long
y,
* FPGA only supports 7 predefined pixel clocks, and clock select is
* in bit 4:0 of new register 0x802a8.
*/
-static unsigned int display_ctrl_adjust(struct drm_device *dev,
- struct drm_display_mode *mode,
- unsigned int ctrl)
+static u32 display_ctrl_adjust(struct drm_device *dev,
+ struct drm_display_mode *mode,
+ u32 ctrl)
{
- unsigned long x, y;
+ u64 x, y;
u32 pll1; /* bit[31:0] of PLL */
u32 pll2; /* bit[63:32] of PLL */
struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
@@ -358,12 +357,12 @@ static unsigned int display_ctrl_adjust(struct drm_device
*dev,
static void hibmc_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
- unsigned int val;
[PATCH drm/hisilicon v3 2/2] drm/hisilicon: Use the same style of variable type in hibmc_drm_drv
Consistently Use the same style of variable type in hibmc_drm_drv.c and
hibmc_drm_drv.h.
Signed-off-by: Tian Tao
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 ++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 8
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 5632bce..0c1b40d 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -121,12 +121,11 @@ static void hibmc_kms_fini(struct hibmc_drm_private *priv)
/*
* It can operate in one of three modes: 0, 1 or Sleep.
*/
-void hibmc_set_power_mode(struct hibmc_drm_private *priv,
- unsigned int power_mode)
+void hibmc_set_power_mode(struct hibmc_drm_private *priv, u32 power_mode)
{
- unsigned int control_value = 0;
+ u32 control_value = 0;
void __iomem *mmio = priv->mmio;
- unsigned int input = 1;
+ u32 input = 1;
if (power_mode > HIBMC_PW_MODE_CTL_MODE_SLEEP)
return;
@@ -144,8 +143,8 @@ void hibmc_set_power_mode(struct hibmc_drm_private *priv,
void hibmc_set_current_gate(struct hibmc_drm_private *priv, unsigned int gate)
{
- unsigned int gate_reg;
- unsigned int mode;
+ u32 gate_reg;
+ u32 mode;
void __iomem *mmio = priv->mmio;
/* Get current power mode. */
@@ -170,7 +169,7 @@ void hibmc_set_current_gate(struct hibmc_drm_private *priv,
unsigned int gate)
static void hibmc_hw_config(struct hibmc_drm_private *priv)
{
- unsigned int reg;
+ u32 reg;
/* On hardware reset, power mode 0 is default. */
hibmc_set_power_mode(priv, HIBMC_PW_MODE_CTL_MODE_MODE0);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 6a63502..f310a83 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -33,8 +33,8 @@ struct hibmc_drm_private {
/* hw */
void __iomem *mmio;
void __iomem *fb_map;
- unsigned long fb_base;
- unsigned long fb_size;
+ resource_size_t fb_base;
+ resource_size_t fb_size;
/* drm */
struct drm_device *dev;
@@ -56,9 +56,9 @@ static inline struct hibmc_drm_private
*to_hibmc_drm_private(struct drm_device *
}
void hibmc_set_power_mode(struct hibmc_drm_private *priv,
- unsigned int power_mode);
+ u32 power_mode);
void hibmc_set_current_gate(struct hibmc_drm_private *priv,
- unsigned int gate);
+ u32 gate);
int hibmc_de_init(struct hibmc_drm_private *priv);
int hibmc_vdac_init(struct hibmc_drm_private *priv);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/msm/dsi_pll_7nm: restore VCO rate during restore_state
PHY disable/enable resets PLL registers to default values. Thus in
addition to restoring several registers we also need to restore VCO rate
settings.
Signed-off-by: Dmitry Baryshkov
Fixes: 1ef7c99d145c ("drm/msm/dsi: add support for 7nm DSI PHY/PLL")
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c
index de0dfb815125..93bf142e4a4e 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c
@@ -585,6 +585,7 @@ static int dsi_pll_7nm_restore_state(struct msm_dsi_pll
*pll)
struct pll_7nm_cached_state *cached = _7nm->cached_state;
void __iomem *phy_base = pll_7nm->phy_cmn_mmio;
u32 val;
+ int ret;
val = pll_read(pll_7nm->mmio + REG_DSI_7nm_PHY_PLL_PLL_OUTDIV_RATE);
val &= ~0x3;
@@ -599,6 +600,13 @@ static int dsi_pll_7nm_restore_state(struct msm_dsi_pll
*pll)
val |= cached->pll_mux;
pll_write(phy_base + REG_DSI_7nm_PHY_CMN_CLK_CFG1, val);
+ ret = dsi_pll_7nm_vco_set_rate(>clk_hw, pll_7nm->vco_current_rate,
pll_7nm->vco_ref_clk_rate);
+ if (ret) {
+ DRM_DEV_ERROR(_7nm->pdev->dev,
+ "restore vco rate failed. ret=%d\n", ret);
+ return ret;
+ }
+
DBG("DSI PLL%d", pll_7nm->id);
return 0;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Force state->modeset=true when distrust_bios_wm==true"
Dear Ville Syrjälä, Thank you for responding so quickly. I was occupied with work and life for the past two weeks, sorry about the wait, but have now managed to find some time to continue pursuing this issue again. On Thu, 2020-10-01 at 18:23 +0300, Ville Syrjälä wrote: > Argh. If only I had managed to land the full dbuf rework and nuke > this mess before it came back to bite us... Yeah... I know the feeling. > This is definitely going to break something else, so not great. I did expect that. The automated tests failing was a pretty good indicator. You put that code in to take care of something. All I did was just tear it down because it happens to work better for me... blunt but functional for my purposes. Seems to need some finesse or a condition to not cause my problem? Yet still function for the reason you put it in there for. I am more than willing to play guinea pig and test patches on my end to improve it with you. > Can you file an upstream bug at > https://gitlab.freedesktop.org/drm/intel/issues/new > and attach dmesgs from booting both good and bad kernels with > drm.debug=0x1e passed to the kernel cmdline? Bump log_buf_len= > if necessary to capture the full log. I have done so today. It's at: https://gitlab.freedesktop.org/drm/intel/-/issues/2579 -- Stefan Joosten AT Computing BV Sharing and growing together Tel +31 24 352 72 82 Arnhemsestraatweg 33 i...@atcomputing.nl 6881 ND Velp www.atcomputing.nl signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/msm/dsi_phy_10nm: implement PHY disabling
Implement phy_disable() callback to disable DSI PHY lanes and blocks
when phy is not used.
Signed-off-by: Dmitry Baryshkov
Fixes: ff73ff194060 ("drm/msm/dsi: Populate the 10nm PHY funcs")
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 47403d4f2d28..d1b92d4dc197 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -192,6 +192,28 @@ static int dsi_10nm_phy_enable(struct msm_dsi_phy *phy,
int src_pll_id,
static void dsi_10nm_phy_disable(struct msm_dsi_phy *phy)
{
+ void __iomem *base = phy->base;
+ u32 data;
+
+ DBG("");
+
+ if (dsi_phy_hw_v3_0_is_pll_on(phy))
+ pr_warn("Turning OFF PHY while PLL is on\n");
+
+ dsi_phy_hw_v3_0_config_lpcdrx(phy, false);
+ data = dsi_phy_read(base + REG_DSI_10nm_PHY_CMN_CTRL_0);
+
+ /* disable all lanes */
+ data &= ~0x1F;
+ dsi_phy_write(base + REG_DSI_10nm_PHY_CMN_CTRL_0, data);
+ dsi_phy_write(base + REG_DSI_10nm_PHY_CMN_LANE_CTRL0, 0);
+
+ /* Turn off all PHY blocks */
+ dsi_phy_write(base + REG_DSI_10nm_PHY_CMN_CTRL_0, 0x00);
+ /* make sure phy is turned off */
+ wmb();
+
+ DBG("DSI%d PHY disabled", phy->id);
}
static int dsi_10nm_phy_init(struct msm_dsi_phy *phy)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/msm/dsi_phy_7nm: implement PHY disabling
Implement phy_disable() callback to disable DSI PHY lanes and blocks
when phy is not used.
Signed-off-by: Dmitry Baryshkov
Fixes: 1ef7c99d145c ("drm/msm/dsi: add support for 7nm DSI PHY/PLL")
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
index 255b5f5ab2ce..79c034ae075d 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
@@ -200,7 +200,28 @@ static int dsi_7nm_phy_enable(struct msm_dsi_phy *phy, int
src_pll_id,
static void dsi_7nm_phy_disable(struct msm_dsi_phy *phy)
{
- /* TODO */
+ void __iomem *base = phy->base;
+ u32 data;
+
+ DBG("");
+
+ if (dsi_phy_hw_v4_0_is_pll_on(phy))
+ pr_warn("Turning OFF PHY while PLL is on\n");
+
+ dsi_phy_hw_v4_0_config_lpcdrx(phy, false);
+ data = dsi_phy_read(base + REG_DSI_7nm_PHY_CMN_CTRL_0);
+
+ /* disable all lanes */
+ data &= ~0x1F;
+ dsi_phy_write(base + REG_DSI_7nm_PHY_CMN_CTRL_0, data);
+ dsi_phy_write(base + REG_DSI_7nm_PHY_CMN_LANE_CTRL0, 0);
+
+ /* Turn off all PHY blocks */
+ dsi_phy_write(base + REG_DSI_7nm_PHY_CMN_CTRL_0, 0x00);
+ /* make sure phy is turned off */
+ wmb();
+
+ DBG("DSI%d PHY disabled", phy->id);
}
static int dsi_7nm_phy_init(struct msm_dsi_phy *phy)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Cocci] [RFC] treewide: cleanup unreachable breaks
On Sat, 2020-10-17 at 20:21 +0200, Julia Lawall wrote: > On Sat, 17 Oct 2020, Joe Perches wrote: > > On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote: > > > From: Tom Rix > > > > > > This is a upcoming change to clean up a new warning treewide. > > > I am wondering if the change could be one mega patch (see below) or > > > normal patch per file about 100 patches or somewhere half way by > > > collecting > > > early acks. > > > > > > clang has a number of useful, new warnings see > > > https://clang.llvm.org/docs/DiagnosticsReference.html > > > > > > This change cleans up -Wunreachable-code-break > > > https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break > > > for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64. > > > > Early acks/individual patches by subsystem would be good. > > Better still would be an automated cocci script. > > Coccinelle is not especially good at this, because it is based on control > flow, and a return or goto diverts the control flow away from the break. > A hack to solve the problem is to put an if around the return or goto, but > that gives the break a meaningless file name and line number. I collected > the following list, but it only has 439 results, so fewer than clang. But > maybe there are some files that are not considered by clang in the x86 > allyesconfig configuration. > > Probably checkpatch is the best solution here, since it is not > configuration sensitive and doesn't care about control flow. Likely the clang compiler is the best option here. It might be useful to add -Wunreachable-code-break to W=1 or just always enable it if it isn't already enabled. diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn index 95e4cdb94fe9..3819787579d5 100644 --- a/scripts/Makefile.extrawarn +++ b/scripts/Makefile.extrawarn @@ -32,6 +32,7 @@ KBUILD_CFLAGS += $(call cc-option, -Wunused-but-set-variable) KBUILD_CFLAGS += $(call cc-option, -Wunused-const-variable) KBUILD_CFLAGS += $(call cc-option, -Wpacked-not-aligned) KBUILD_CFLAGS += $(call cc-option, -Wstringop-truncation) +KBUILD_CFLAGS += $(call cc-option, -Wunreachable-code-break) # The following turn off the warnings enabled by -Wextra KBUILD_CFLAGS += -Wno-missing-field-initializers KBUILD_CFLAGS += -Wno-sign-compare (and thank you Tom for pushing this forward) checkpatch can't find instances like: case FOO: if (foo) return 1; else return 2; break; As it doesn't track flow and relies on the number of tabs to be the same for any goto/return and break; checkpatch will warn on: case FOO: ... goto bar; break; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] treewide: cleanup unreachable breaks
On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote: > From: Tom Rix > > This is a upcoming change to clean up a new warning treewide. > I am wondering if the change could be one mega patch (see below) or > normal patch per file about 100 patches or somewhere half way by collecting > early acks. > > clang has a number of useful, new warnings see > https://clang.llvm.org/docs/DiagnosticsReference.html > > This change cleans up -Wunreachable-code-break > https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break > for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64. Early acks/individual patches by subsystem would be good. Better still would be an automated cocci script. The existing checkpatch test for UNNECESSARY_BREAK has a few too many false positives. >From a script run on next on July 28th: arch/arm/mach-s3c24xx/mach-rx1950.c:266: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/arm/nwfpe/fpa11_cprt.c:38: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/arm/nwfpe/fpa11_cprt.c:41: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/include/asm/mach-au1x00/au1000.h:684: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/include/asm/mach-au1x00/au1000.h:687: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/include/asm/mach-au1x00/au1000.h:690: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/include/asm/mach-au1x00/au1000.h:693: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/include/asm/mach-au1x00/au1000.h:697: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/include/asm/mach-au1x00/au1000.h:700: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:276: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:279: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:282: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:287: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:290: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/rb532/setup.c:76: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/mips/rb532/setup.c:79: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/powerpc/include/asm/kvm_book3s_64.h:231: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/powerpc/include/asm/kvm_book3s_64.h:234: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/powerpc/include/asm/kvm_book3s_64.h:237: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/powerpc/include/asm/kvm_book3s_64.h:240: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/powerpc/net/bpf_jit_comp.c:455: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/powerpc/platforms/cell/spufs/switch.c:2047: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/powerpc/platforms/cell/spufs/switch.c:2077: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/sh/boards/mach-landisk/gio.c:111: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/x86/kernel/cpu/mce/core.c:1734: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/x86/kernel/cpu/mce/core.c:1738: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return arch/x86/kernel/cpu/microcode/amd.c:218: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return drivers/acpi/utils.c:107: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return drivers/acpi/utils.c:132: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return drivers/acpi/utils.c:147: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return drivers/acpi/utils.c:158: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return drivers/ata/libata-scsi.c:3973: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return drivers/base/power/main.c:366: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return drivers/block/xen-blkback/blkback.c:1272: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return drivers/char/ipmi/ipmi_devintf.c:493: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return drivers/char/lp.c:625: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return drivers/char/mwave/mwavedd.c:406: WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return
[RFC] treewide: cleanup unreachable breaks
From: Tom Rix
This is a upcoming change to clean up a new warning treewide.
I am wondering if the change could be one mega patch (see below) or
normal patch per file about 100 patches or somewhere half way by collecting
early acks.
clang has a number of useful, new warnings see
https://clang.llvm.org/docs/DiagnosticsReference.html
This change cleans up -Wunreachable-code-break
https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.
The method of fixing was to look for warnings where the preceding statement
was a simple statement and by inspection made the subsequent break unneeded.
In order of frequency these look like
return and break
switch (c->x86_vendor) {
case X86_VENDOR_INTEL:
intel_p5_mcheck_init(c);
return 1;
- break;
goto and break
default:
operation = 0; /* make gcc happy */
goto fail_response;
- break;
break and break
case COLOR_SPACE_SRGB:
/* by pass */
REG_SET(OUTPUT_CSC_CONTROL, 0,
OUTPUT_CSC_GRPH_MODE, 0);
break;
- break;
The exception to the simple statement, is a switch case with a block
and the end of block is a return
struct obj_buffer *buff = r->ptr;
return scnprintf(str, PRIV_STR_SIZE,
"size=%u\naddr=0x%X\n", buff->size,
buff->addr);
}
- break;
Not considered obvious and excluded, breaks after
multi level switches
complicated if-else if-else blocks
panic() or similar calls
And there is an odd addition of a 'fallthrough' in drivers/tty/nozomi.c
Tom
---
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 1c08cb9eb9f6..16ce86aed8e2 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -1809,15 +1809,13 @@ static int __mcheck_cpu_ancient_init(struct cpuinfo_x86
*c)
switch (c->x86_vendor) {
case X86_VENDOR_INTEL:
intel_p5_mcheck_init(c);
return 1;
- break;
case X86_VENDOR_CENTAUR:
winchip_mcheck_init(c);
return 1;
- break;
default:
return 0;
}
return 0;
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index 3f6b137ef4e6..3d4a48336084 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -213,11 +213,10 @@ static unsigned int __verify_patch_size(u8 family, u32
sh_psize, size_t buf_size
max_size = F14H_MPB_MAX_SIZE;
break;
default:
WARN(1, "%s: WTF family: 0x%x\n", __func__, family);
return 0;
- break;
}
if (sh_psize > min_t(u32, buf_size, max_size))
return 0;
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index 838b719ec7ce..d5411a166685 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -102,11 +102,10 @@ acpi_extract_package(union acpi_object *package,
printk(KERN_WARNING PREFIX "Invalid package
element"
" [%d]: got number, expecting"
" [%c]\n",
i, format_string[i]);
return AE_BAD_DATA;
- break;
}
break;
case ACPI_TYPE_STRING:
case ACPI_TYPE_BUFFER:
@@ -127,11 +126,10 @@ acpi_extract_package(union acpi_object *package,
printk(KERN_WARNING PREFIX "Invalid package
element"
" [%d] got string/buffer,"
" expecting [%c]\n",
i, format_string[i]);
return AE_BAD_DATA;
- break;
}
break;
case ACPI_TYPE_LOCAL_REFERENCE:
switch (format_string[i]) {
case 'R':
@@ -142,22 +140,20 @@ acpi_extract_package(union acpi_object *package,
printk(KERN_WARNING PREFIX "Invalid package
element"
" [%d] got reference,"
" expecting [%c]\n",
i, format_string[i]);
return AE_BAD_DATA;
-
Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly
On Sat, Oct 17, 2020 at 10:39 AM Melissa Wen wrote: > > On 10/16, Daniel Vetter wrote: > > On Fri, Oct 16, 2020 at 7:02 PM Melissa Wen wrote: > > > > > > On 10/16, Daniel Vetter wrote: > > > > On Fri, Oct 16, 2020 at 12:38 PM Simon Ser wrote: > > > > > > > > > > > The only thing we support is xrgb. > > > > > > > > > > > > Signed-off-by: Daniel Vetter > > > > > > Cc: Rodrigo Siqueira > > > > > > Cc: Melissa Wen > > > > > > Cc: Haneen Mohammed > > > > > > Cc: Daniel Vetter > > > > > > --- > > > > > > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c > > > > > > b/drivers/gpu/drm/vkms/vkms_drv.c > > > > > > index 726801ab44d4..eb4007443706 100644 > > > > > > --- a/drivers/gpu/drm/vkms/vkms_drv.c > > > > > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > > > > > > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device > > > > > > *vkmsdev) > > > > > > dev->mode_config.max_height = YRES_MAX; > > > > > > dev->mode_config.cursor_width = 512; > > > > > > dev->mode_config.cursor_height = 512; > > > > > > - dev->mode_config.preferred_depth = 24; > > > > > > + dev->mode_config.preferred_depth = 32; > > > > > > > > > > Are you sure xrgb's depth is 32 and not 24? Looking at drmdb [1], > > > > > *all* > > > > > drivers set it to 24. > > > > > > > > Uh there's a problem I think. Depth should indeed stay at 24, the > > > > problem is that fb helpers directly take that to be the bpp parameter, > > > > which is a different thing. And if you look at how most drivers set up > > > > that, they pick 32. > > > > > > > > I guess I need to revert this here, and unconfuse the fb helpers about > > > > depth vs bpp. > > > > > > Hi guys, > > > > > > Perhaps it deserves to be pointed out: the documentation says > > > "preferred_depth: preferred RBG(sic) pixel depth, used by fb helpers", > > > and looking to fb helpers, preferred_depth is only used by > > > generic_setup, as bits by pixel (if I didn't miss something there). > > > > > > In fact, the alpha channel is not used for final display (perhaps in the > > > future); however, I saw another driver with a change similar to this > > > here and, possibly like me, following the same misunderstanding. > > > > Yeah the problem is that preferred_depth is depth, and that means 24 > > bit for XRGB. But bpp as used by fb helpers would be 32 bit for > > XRGB. > > > > I think the real fix here is to switch this entire mess over to using > > drm_fourcc codes directly, at least for atomic drivers. Which nowadays > > are most. Interim I'm not sure whether we should revert my patch (it > > breaks fbdev) or switch preferred_depth to 0, which means we get the > > default every, and that means both fbdev helpers and userspace will > > pick XRGB. > > hmm... but why not keep preferred_depth = 24 and pass 32 as the > preferred_bpp parameter of fbdev_generic_setup? The goal is to get rid of this parameter in fbdev_generic_setup. It should be able to figure this out automatically, like any kms client in userspace. What does work is setting preferred_bpp = 0. Userspace will pick the default (which is generally 24 depth, 32bpp), and fbcon do the same. And then I guess a nice patch series to clean up this mess. -Daniel > > -Daniel > > > > > Melissa > > > > > > > > Maybe best would be to just switch over to preferred drm_fourcc format > > > > code, or maybe just pick this up from the first format the primary > > > > plane supports. > > > > > > > > This is all getting slightly tricky and a lot more work :-/ > > > > -Daniel > > > > -- > > > > Daniel Vetter > > > > Software Engineer, Intel Corporation > > > > http://blog.ffwll.ch > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- 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] vgacon: fix a UAF in do_update_region()
Hi Yang. Can you please resend and include Greg in the recipient list. Greg is maintainer of the console subsystem these days. Sam On Mon, Jul 13, 2020 at 11:04:45AM +, Yang Yingliang wrote: > I got a UAF report in do_update_region() when I doing fuzz test. > > [ 51.161905] BUG: KASAN: use-after-free in do_update_region+0x579/0x600 > [ 51.161918] Read of size 2 at addr 88800010 by task test/295 > > [ 51.161957] CPU: 2 PID: 295 Comm: test Not tainted 5.7.0+ #975 > [ 51.161969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 > [ 51.161976] Call Trace: > [ 51.162001] dump_stack+0xc6/0x11e > [ 51.162019] ? do_update_region+0x579/0x600 > [ 51.162047] print_address_description.constprop.6+0x1a/0x220 > [ 51.162083] ? vprintk_func+0x66/0xed > [ 51.162100] ? do_update_region+0x579/0x600 > [ 51.162112] ? do_update_region+0x579/0x600 > [ 51.162128] kasan_report.cold.9+0x37/0x7c > [ 51.162151] ? do_update_region+0x579/0x600 > [ 51.162173] do_update_region+0x579/0x600 > [ 51.162207] ? con_get_trans_old+0x230/0x230 > [ 51.162229] ? retint_kernel+0x10/0x10 > [ 51.162278] csi_J+0x557/0xa00 > [ 51.162307] do_con_trol+0x49af/0x5cc0 > [ 51.162330] ? lock_downgrade+0x720/0x720 > [ 51.162347] ? reset_palette+0x1b0/0x1b0 > [ 51.162369] ? lockdep_hardirqs_on_prepare+0x379/0x540 > [ 51.162393] ? notifier_call_chain+0x11b/0x160 > [ 51.162438] do_con_write.part.24+0xb0a/0x1a30 > [ 51.162501] ? do_con_trol+0x5cc0/0x5cc0 > [ 51.162522] ? console_unlock+0x7b8/0xb00 > [ 51.162555] ? __mutex_unlock_slowpath+0xd4/0x670 > [ 51.162574] ? this_tty+0xe0/0xe0 > [ 51.162589] ? console_unlock+0x559/0xb00 > [ 51.162605] ? wait_for_completion+0x260/0x260 > [ 51.162638] con_write+0x31/0xb0 > [ 51.162658] n_tty_write+0x4fa/0xd40 > [ 51.162710] ? n_tty_read+0x1800/0x1800 > [ 51.162730] ? prepare_to_wait_exclusive+0x270/0x270 > [ 51.162754] ? __might_fault+0x175/0x1b0 > [ 51.162783] tty_write+0x42b/0x8d0 > [ 51.162795] ? n_tty_read+0x1800/0x1800 > [ 51.162825] ? tty_lookup_driver+0x450/0x450 > [ 51.162848] __vfs_write+0x7c/0x100 > [ 51.162875] vfs_write+0x1c9/0x510 > [ 51.162901] ksys_write+0xff/0x200 > [ 51.162918] ? __ia32_sys_read+0xb0/0xb0 > [ 51.162940] ? do_syscall_64+0x1a/0x520 > [ 51.162957] ? lockdep_hardirqs_on_prepare+0x379/0x540 > [ 51.162984] do_syscall_64+0xa1/0x520 > [ 51.163008] entry_SYSCALL_64_after_hwframe+0x49/0xb3 > > After vgacon_set_origin() is called in set_origin(), the vc_origin is > set to vga_vram_base, the vc_pos should between vga_vram_base and > vga_vram_end. But we still use vc_screenbuf_size, if the vga_vram_size > is smaller than vc_screenbuf_size, vc_pos may be out of bound, using it > will cause a use-after-free(or out-of-bounds). Fix this by calling > vc_resize() if vga_vram_size is smaller than vc_screenbuf_size. > > Signed-off-by: Yang Yingliang > --- > drivers/video/console/vgacon.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c > index b51ffb9a208d..2eabb86bb0dd 100644 > --- a/drivers/video/console/vgacon.c > +++ b/drivers/video/console/vgacon.c > @@ -1341,6 +1341,9 @@ static int vgacon_set_origin(struct vc_data *c) > if (vga_is_gfx || /* We don't play origin tricks in graphic modes > */ > (console_blanked && !vga_palette_blanked)) /* Nor we write to > blanked screens */ > return 0; > + > + if (c->vc_screenbuf_size > vga_vram_size) > + vc_resize(c, screen_info.orig_video_cols, > screen_info.orig_video_lines); > c->vc_origin = c->vc_visible_origin = vga_vram_base; > vga_set_mem_top(c); > vga_rolled_over = 0; > -- > 2.25.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 0/3] drm/panel: mantix panel reset fixes
Hi Guido. On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote: > Hi Sam, > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote: > > Hi Guido. > > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote: > [..snip..] > > > > > > Changes from v1: > > > - As per review comments by Fabio Estevam > > > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/ > > >- Fix typo in commit messages > > > - As per review comments by Rob Herring > > >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/ > > >- Don't use an array of reset lines > > > > > > Guido Günther (3): > > > drm/panel: mantix: Don't dereference NULL mode > > > drm/panel: mantix: Fix panel reset > > > dt-binding: display: Require two resets on mantix panel > > > > All applied to drm-misc-next and pushed out. > > And then I remembered you had commit right - sigh. > > Thanks! Is there any special care needed to get that into 5.10? The > driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45. As the patches was applied to drm-misc-next the easiet path would be to cherry-pick them and apply to drm-misc-fixes. dim has cherry-pick support - try to use it rahter than doing it by hand. When you apply to drm-misc-fixes include a Fixes: tag so the tooling will pick the patches automagically. In hindsight the patches should have carried a Fixes: tag from a start and should have been applied to drm-misc-fixes from a start too. I have done something like above once or twice but anyway reach out if you have questions. Or ask at #dri-devel. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi Sam, On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote: > Hi Guido. > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote: [..snip..] > > > > Changes from v1: > > - As per review comments by Fabio Estevam > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/ > >- Fix typo in commit messages > > - As per review comments by Rob Herring > >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/ > >- Don't use an array of reset lines > > > > Guido Günther (3): > > drm/panel: mantix: Don't dereference NULL mode > > drm/panel: mantix: Fix panel reset > > dt-binding: display: Require two resets on mantix panel > > All applied to drm-misc-next and pushed out. > And then I remembered you had commit right - sigh. Thanks! Is there any special care needed to get that into 5.10? The driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45. Cheers, -- Guido > > Sam > > > > > .../display/panel/mantix,mlaf057we51-x.yaml | 4 +++ > > .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 25 +-- > > 2 files changed, 21 insertions(+), 8 deletions(-) > > > > -- > > 2.28.0 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly
On 10/16, Daniel Vetter wrote: > On Fri, Oct 16, 2020 at 7:02 PM Melissa Wen wrote: > > > > On 10/16, Daniel Vetter wrote: > > > On Fri, Oct 16, 2020 at 12:38 PM Simon Ser wrote: > > > > > > > > > The only thing we support is xrgb. > > > > > > > > > > Signed-off-by: Daniel Vetter > > > > > Cc: Rodrigo Siqueira > > > > > Cc: Melissa Wen > > > > > Cc: Haneen Mohammed > > > > > Cc: Daniel Vetter > > > > > --- > > > > > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c > > > > > b/drivers/gpu/drm/vkms/vkms_drv.c > > > > > index 726801ab44d4..eb4007443706 100644 > > > > > --- a/drivers/gpu/drm/vkms/vkms_drv.c > > > > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > > > > > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device > > > > > *vkmsdev) > > > > > dev->mode_config.max_height = YRES_MAX; > > > > > dev->mode_config.cursor_width = 512; > > > > > dev->mode_config.cursor_height = 512; > > > > > - dev->mode_config.preferred_depth = 24; > > > > > + dev->mode_config.preferred_depth = 32; > > > > > > > > Are you sure xrgb's depth is 32 and not 24? Looking at drmdb [1], > > > > *all* > > > > drivers set it to 24. > > > > > > Uh there's a problem I think. Depth should indeed stay at 24, the > > > problem is that fb helpers directly take that to be the bpp parameter, > > > which is a different thing. And if you look at how most drivers set up > > > that, they pick 32. > > > > > > I guess I need to revert this here, and unconfuse the fb helpers about > > > depth vs bpp. > > > > Hi guys, > > > > Perhaps it deserves to be pointed out: the documentation says > > "preferred_depth: preferred RBG(sic) pixel depth, used by fb helpers", > > and looking to fb helpers, preferred_depth is only used by > > generic_setup, as bits by pixel (if I didn't miss something there). > > > > In fact, the alpha channel is not used for final display (perhaps in the > > future); however, I saw another driver with a change similar to this > > here and, possibly like me, following the same misunderstanding. > > Yeah the problem is that preferred_depth is depth, and that means 24 > bit for XRGB. But bpp as used by fb helpers would be 32 bit for > XRGB. > > I think the real fix here is to switch this entire mess over to using > drm_fourcc codes directly, at least for atomic drivers. Which nowadays > are most. Interim I'm not sure whether we should revert my patch (it > breaks fbdev) or switch preferred_depth to 0, which means we get the > default every, and that means both fbdev helpers and userspace will > pick XRGB. hmm... but why not keep preferred_depth = 24 and pass 32 as the preferred_bpp parameter of fbdev_generic_setup? > -Daniel > > > Melissa > > > > > > Maybe best would be to just switch over to preferred drm_fourcc format > > > code, or maybe just pick this up from the first format the primary > > > plane supports. > > > > > > This is all getting slightly tricky and a lot more work :-/ > > > -Daniel > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/via: reduce no need mutex_lock area
Hi Bernard. On Fri, Aug 14, 2020 at 01:30:19AM -0700, Bernard Zhao wrote: > In function via_mem_alloc`s error branch, DRM_ERROR is protected > in the mutex_lock(>struct_mutex) area. > >From the code, we see that DRM_ERROR is just an error log print > without any struct element, there is no need to protect this. > > Signed-off-by: Bernard Zhao Thanks, applied to drm-misc-next. The patch will show up in -next in a few weeks. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: simple: Add support for Innolux LS075AT011
Hi Lubomir.
Sorry for the late feedback!
On Wed, Aug 19, 2020 at 12:12:06PM +0200, Lubomir Rintel wrote:
> This adds support for the Innolux LS075AT011 7.5" 1200x900 panel. There's
> no public data sheet for the panel -- the values have been taken from Open
> Firmware and the documentation for the display controller that drives
> the panel and tested on the OLPC laptop.
>
> Signed-off-by: Lubomir Rintel
> ---
> drivers/gpu/drm/panel/panel-simple.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index cb6550d37e858..dfc69457ed2d4 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2121,6 +2121,30 @@ static const struct panel_desc innolux_g121x1_l03 = {
> },
> };
>
> +static const struct display_timing innolux_ls075at011_timing = {
> + .pixelclock = { 5600, 5700, 5800 },
> + .hactive = { 1200, 1200, 1200 },
> + .hfront_porch = { 26, 26, 26 },
> + .hback_porch = { 24, 24, 24 },
> + .hsync_len = { 6, 6, 6 },
> + .vactive = { 900, 900, 900 },
> + .vfront_porch = { 4, 4, 4 },
> + .vback_porch = { 5, 5, 5 },
> + .vsync_len = { 3, 3, 3 },
> + .flags = DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_HSYNC_LOW,
> +};
> +
> +static const struct panel_desc innolux_ls075at011 = {
> + .timings = _ls075at011_timing,
> + .num_timings = 1,
> + .bpc = 8,
> + .size = {
> + .width = 152,
> + .height = 115,
> + },
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
> +};
For LVDS panels following info is mandatory:
.bus_flags
.bus_format
You have .bpc - so this part is OK.
See the checks in panel_simple_probe() - thay are not allowed to trigger
for any new panels.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/tc358775: Fixes bus formats read
Hi Vinay On Tue, Sep 08, 2020 at 08:57:07PM +0300, Laurent Pinchart wrote: > Hi Vinay, > > On Tue, Sep 08, 2020 at 11:22:48PM +0530, Vinay Simha B N wrote: > > laurent, > > > > Please review or give some feedback. > > I'm sorry, I have very little time these days :-( Maybe Neil can provide > feedback ? I have lost the original patch - if this is still pending could you then please resend. Thanks, Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/mcde: Fix handling of platform_get_irq() error
Hi Krzysztof
On Thu, Aug 27, 2020 at 09:11:06AM +0200, Krzysztof Kozlowski wrote:
> platform_get_irq() returns -ERRNO on error. In such case comparison
> to 0 would pass the check.
>
> Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
> Signed-off-by: Krzysztof Kozlowski
Thanks, applied this and the tve200 patch to drm-misc-next.
They will appear in -next in a few weeks time.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/bridge: add it6505 driver
Hi Allen On Fri, Sep 04, 2020 at 10:10:23AM +0800, allen wrote: > This adds support for the iTE IT6505. > This device can convert DPI signal to DP output. > > From: Allen Chen > Signed-off-by: Jitao Shi > Signed-off-by: Pi-Hsun Shih > Signed-off-by: Yilun Lin > Signed-off-by: Hermes Wu > Signed-off-by: Allen Chen > Reported-by: kernel test robot Sorry for being so late with the feedback - have been offline for a while. One high-level comment - the bridge does not respect the flags arguments in the it6505_bridge_attach function. And will unconditionally create the connector. The correct approach is that the display driver creates the connector, and pass a flag to the bridge driver to tell it not to create the connector. Could we please update the relevant display drivers to create the connector and then drop it from the bridge driver. So we avoid adding backward compatible code to a new bridge driver. What display driver will this bridge be used with? Sam > --- > drivers/gpu/drm/bridge/Kconfig |7 + > drivers/gpu/drm/bridge/Makefile |1 + > drivers/gpu/drm/bridge/ite-it6505.c | 3338 +++ > 3 files changed, 3346 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 3e11af4e9f63e..f21dce3fabeb9 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -61,6 +61,13 @@ config DRM_LONTIUM_LT9611 > HDMI signals > Please say Y if you have such hardware. > > +config DRM_ITE_IT6505 > + tristate "ITE IT6505 DisplayPort bridge" > + depends on OF > + select DRM_KMS_HELPER > + help > + ITE IT6505 DisplayPort bridge chip driver. > + > config DRM_LVDS_CODEC > tristate "Transparent LVDS encoders and decoders support" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index c589a6a7cbe1d..8a118fd901ad7 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o > obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o > +obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o > obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += > megachips-stdp-ge-b850v3-fw.o > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > diff --git a/drivers/gpu/drm/bridge/ite-it6505.c > b/drivers/gpu/drm/bridge/ite-it6505.c > new file mode 100644 > index 0..0ed19673431ee > --- /dev/null > +++ b/drivers/gpu/drm/bridge/ite-it6505.c > @@ -0,0 +1,3338 @@ > +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +/* > + * Copyright (c) 2020, The Linux Foundation. All rights reserved. > + */ > +#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 > +#include > +#include > + > +#include > + > +#define REG_IC_VER 0x04 > + > +#define REG_RESET_CTRL 0x05 > +#define VIDEO_RESET BIT(0) > +#define AUDIO_RESET BIT(1) > +#define ALL_LOGIC_RESET BIT(2) > +#define AUX_RESET BIT(3) > +#define HDCP_RESET BIT(4) > + > +#define INT_STATUS_01 0x06 > +#define INT_MASK_01 0x09 > +#define INT_HPD_CHANGE BIT(0) > +#define INT_RECEIVE_HPD_IRQ BIT(1) > +#define INT_SCDT_CHANGE BIT(2) > +#define INT_HDCP_FAIL BIT(3) > +#define INT_HDCP_DONE BIT(4) > + > +#define INT_STATUS_02 0x07 > +#define INT_MASK_02 0x0A > +#define INT_AUX_CMD_FAIL BIT(0) > +#define INT_HDCP_KSV_CHECK BIT(1) > +#define INT_AUDIO_FIFO_ERROR BIT(2) > + > +#define INT_STATUS_03 0x08 > +#define INT_MASK_03 0x0B > +#define INT_LINK_TRAIN_FAIL BIT(4) > +#define INT_VID_FIFO_ERROR BIT(5) > +#define INT_IO_LATCH_FIFO_OVERFLOW BIT(7) > + > +#define REG_SYSTEM_STS 0x0D > +#define INT_STS BIT(0) > +#define HPD_STS BIT(1) > +#define VIDEO_STB BIT(2) > + > +#define REG_LINK_TRAIN_STS 0x0E > +#define LINK_STATE_CR BIT(2) > +#define LINK_STATE_EQ BIT(3) > +#define LINK_STATE_NORP BIT(4) > + > +#define REG_BANK_SEL 0x0F > +#define REG_CLK_CTRL0 0x10 > +#define M_PCLK_DELAY 0x03 > + > +#define REG_AUX_OPT 0x11 > +#define AUX_AUTO_RST BIT(0) > +#define AUX_FIX_FREQ BIT(3) > + > +#define REG_DATA_CTRL0 0x12 > +#define VIDEO_LATCH_EDGE BIT(4) > +#define ENABLE_PCLK_COUNTER BIT(7) > + > +#define REG_PCLK_COUNTER_VALUE 0x13 > + > +#define REG_501_FIFO_CTRL 0x15 > +#define RST_501_FIFO BIT(1) > + > +#define REG_TRAIN_CTRL0 0x16 > +#define FORCE_LBR BIT(0) > +#define LANE_COUNT_MASK 0x06 > +#define LANE_SWAP BIT(3) > +#define SPREAD_AMP_5 BIT(4) > +#define FORCE_CR_DONE BIT(5) > +#define
Re: [PATCH 1/3] dt-bindings: vendor-prefixes: Add Yes Optoelectronics
Hi Jagan. On Fri, Sep 04, 2020 at 11:38:19PM +0530, Jagan Teki wrote: > Add vendor dt-bindings for Yes Optoelectronics Co.,Ltd. > > Signed-off-by: Jagan Teki I have applied the full series to drm-misc-next. Sorry for the delay. Sam > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index 9aeab66be85f..15a6a8e7260d 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -1167,6 +1167,8 @@ patternProperties: > description: Shenzhen Xunlong Software CO.,Limited >"^xylon,.*": > description: Xylon > + "^yes-optoelectronics,.*": > +description: Yes Optoelectronics Co.,Ltd. >"^yna,.*": > description: YSH & ATIL >"^yones-toptech,.*": > -- > 2.25.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 v3 0/2] Add LT9611UXC DSI to HDMI bridge support
Hi Dmitry On Wed, Sep 09, 2020 at 12:28:21PM +0300, Dmitry Baryshkov wrote: > Hi, > > This series adds support for Lontium LT9611UXC bridge chip which takes > MIPI DSI as input and provides HDMI signal as output. > > The chip can be found in Qualcomm RB5 platform [1], [2]. > > [1] https://www.qualcomm.com/products/qualcomm-robotics-rb5-platform > [2] https://www.thundercomm.com/app_en/product/1590131656070623 > > Changes since v2: > - Squashed connector support into main patch > - Added comment on modes table > - Dropped display timings support, covered by EDID > - Dropped sleep mode support > - Dropped hpd_status reading from ISR handler > - Added "sentinel" comments to empty table entries > > Changes since v1: > - Fix whitespaces/indentation > - Support working without DRM_BRIDGE_ATTACH_NO_CONNECTOR Sorry for taking so long time to get back to you. Which display driver will this be used together with? The preference is that the display driver adds support for creating the connector so we can drop this from the bridge as this is not how things should be done these days. All the rest looked good. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: fsl-diu-fb: remove unneeded variable 'res'
On Thu, Sep 10, 2020 at 10:05:58PM +0800, Jason Yan wrote:
> Eliminate the following coccicheck warning:
>
> drivers/video/fbdev/fsl-diu-fb.c:1428:5-8: Unneeded variable: "res".
> Return "0" on line 1450
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Hi Jason,
applied to drm-misc-next too.
Sam
> ---
> drivers/video/fbdev/fsl-diu-fb.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/fsl-diu-fb.c
> b/drivers/video/fbdev/fsl-diu-fb.c
> index a547c21c7e92..e332017c6af6 100644
> --- a/drivers/video/fbdev/fsl-diu-fb.c
> +++ b/drivers/video/fbdev/fsl-diu-fb.c
> @@ -1425,7 +1425,6 @@ static int fsl_diu_open(struct fb_info *info, int user)
> static int fsl_diu_release(struct fb_info *info, int user)
> {
> struct mfb_info *mfbi = info->par;
> - int res = 0;
>
> spin_lock(_lock);
> mfbi->count--;
> @@ -1447,7 +1446,7 @@ static int fsl_diu_release(struct fb_info *info, int
> user)
> }
>
> spin_unlock(_lock);
> - return res;
> + return 0;
> }
>
> static const struct fb_ops fsl_diu_ops = {
> --
> 2.25.4
>
> ___
> 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] video: fbdev: sis: remove unneeded semicolon
On Thu, Sep 10, 2020 at 10:05:36PM +0800, Jason Yan wrote: > Eliminate the following coccicheck warning: > > drivers/video/fbdev/sis/sis_accel.h:143:72-73: Unneeded semicolon > drivers/video/fbdev/sis/sis_accel.h:144:72-73: Unneeded semicolon > drivers/video/fbdev/sis/sis_accel.h:145:72-73: Unneeded semicolon > drivers/video/fbdev/sis/sis_accel.h:273:75-76: Unneeded semicolon > drivers/video/fbdev/sis/sis_accel.h:274:75-76: Unneeded semicolon > drivers/video/fbdev/sis/sis_accel.h:275:73-74: Unneeded semicolon > drivers/video/fbdev/sis/sis_accel.h:276:75-76: Unneeded semicolon > > Reported-by: Hulk Robot > Signed-off-by: Jason Yan Applied to drm-misc-next. checkpatch was not happy with the patch - but I ignored these warnings as this is an old code base. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] omapfb: connector-dvi: simplify the return expression of dvic_connect()
Hi Liu.
On Tue, Sep 15, 2020 at 11:26:27AM +0800, Liu Shixin wrote:
> Simplify the return expression.
>
> Signed-off-by: Liu Shixin
Thanks, also applied.
If you have other drm/fbdev patches pending then I have missed them.
So please resend if this is the case.
Sam
> ---
> drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
> b/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
> index b4a1aefff766..2fa436475b40 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
> @@ -51,16 +51,11 @@ static int dvic_connect(struct omap_dss_device *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> struct omap_dss_device *in = ddata->in;
> - int r;
>
> if (omapdss_device_is_connected(dssdev))
> return 0;
>
> - r = in->ops.dvi->connect(in, dssdev);
> - if (r)
> - return r;
> -
> - return 0;
> + return in->ops.dvi->connect(in, dssdev);
> }
>
> static void dvic_disconnect(struct omap_dss_device *dssdev)
> --
> 2.25.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 -next] drm/panel: simplify the return expression of rb070d30_panel_enable()
Hi Liu
On Tue, Sep 15, 2020 at 11:26:23AM +0800, Liu Shixin wrote:
> Simplify the return expression.
>
> Signed-off-by: Liu Shixin
Thanks, applied to drm-misc-next.
The patch will appear in drm-misc-next in a few weeks.
Sam
> ---
> drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> index 535c8d1cca21..a3782830ae3c 100644
> --- a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> +++ b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> @@ -75,13 +75,8 @@ static int rb070d30_panel_unprepare(struct drm_panel
> *panel)
> static int rb070d30_panel_enable(struct drm_panel *panel)
> {
> struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
> - int ret;
>
> - ret = mipi_dsi_dcs_exit_sleep_mode(ctx->dsi);
> - if (ret)
> - return ret;
> -
> - return 0;
> + return mipi_dsi_dcs_exit_sleep_mode(ctx->dsi);
> }
>
> static int rb070d30_panel_disable(struct drm_panel *panel)
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: analogix_dp: make analogix_dp_start_aux_transaction() static
Hi Jason.
Thanks, also applied to drm-misc-next.
If you had other drm/fbdev related patches pending then I have missed
them so please resend.
Sam
On Sat, Sep 12, 2020 at 11:38:43AM +0800, Jason Yan wrote:
> This eliminates the following sparse warning:
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c:527:5: warning: symbol
> 'analogix_dp_start_aux_transaction' was not declared. Should it be
> static?
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
> ---
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 914c569ab8c1..fafb4b492ea0 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -524,7 +524,7 @@ void analogix_dp_enable_sw_function(struct
> analogix_dp_device *dp)
> writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
> }
>
> -int analogix_dp_start_aux_transaction(struct analogix_dp_device *dp)
> +static int analogix_dp_start_aux_transaction(struct analogix_dp_device *dp)
> {
> int reg;
> int retval = 0;
> --
> 2.25.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: adv7511: make adv7511_hdmi_hw_params() static
Hi Jason,
Thanks, applied to drm-misc-next.
As for the other patch this will appear in -next in a few weeks.
Sam
On Sat, Sep 12, 2020 at 11:38:26AM +0800, Jason Yan wrote:
> This eliminates the following sparse warning:
>
> drivers/gpu/drm/bridge/adv7511/adv7511_audio.c:58:5: warning: symbol
> 'adv7511_hdmi_hw_params' was not declared. Should it be static?
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> index f101dd2819b5..45838bd08d37 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> @@ -55,9 +55,9 @@ static int adv7511_update_cts_n(struct adv7511 *adv7511)
> return 0;
> }
>
> -int adv7511_hdmi_hw_params(struct device *dev, void *data,
> -struct hdmi_codec_daifmt *fmt,
> -struct hdmi_codec_params *hparms)
> +static int adv7511_hdmi_hw_params(struct device *dev, void *data,
> + struct hdmi_codec_daifmt *fmt,
> + struct hdmi_codec_params *hparms)
> {
> struct adv7511 *adv7511 = dev_get_drvdata(dev);
> unsigned int audio_source, i2s_format = 0;
> --
> 2.25.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: st7703: Make jh057n00900_panel_desc static
Hi Jason,
On Sat, Sep 12, 2020 at 11:38:09AM +0800, Jason Yan wrote:
> This eliminates the following sparse warning:
>
> drivers/gpu/drm/panel/panel-sitronix-st7703.c:156:26: warning: symbol
> 'jh057n00900_panel_desc' was not declared. Should it be static?
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Thanks, applied to drm-misc-next with Guidos suggestions.
The patch will appear in -next in a few weeks.
Sam
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index c22e7c49e077..7c07a8fc8506 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -153,7 +153,7 @@ static const struct drm_display_mode jh057n00900_mode = {
> .height_mm = 130,
> };
>
> -struct st7703_panel_desc jh057n00900_panel_desc = {
> +static struct st7703_panel_desc jh057n00900_panel_desc = {
> .mode = _mode,
> .lanes = 4,
> .mode_flags = MIPI_DSI_MODE_VIDEO |
> --
> 2.25.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/4] drm: panel: add support for TDO tl070wsh30 panel
Hi Neil. On Tue, Sep 29, 2020 at 11:25:17AM +0200, Neil Armstrong wrote: > Hi Sam, > > Is there anything more to change ? Sorry for taking so long to get back to you on this. All patches looks good and are: Reviewed-by: Sam Ravnborg I assume you will apply the patches. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
