Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
在 2019/10/11 下午2:44, james qian wang (Arm Technology China) 写道:
On Fri, Oct 11, 2019 at 11:35:53AM +0800, sandy.huang wrote:
Hi james.qian.wang,
Thank for you remind, fou some unknow reason, i miss the the mail from
you:(, i get this message from https://patchwork.kernel.org/patch/11161937/
sorry about that.
About the format block describe, I also found some unreasonable, this
format need 2 line aligned, so the block_h need to sed as 2, and the
char_per_block need set as w * h * 10 for y plane, and w * h * 2 * 10 for uv
plane, so the following describe maybe more correct, thanks.
{ .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
Hi Sandy:
I think for such NV12 YUV-422 (hsub = 2, vsub = 2) 2x2 subsampled format
the block size can be:
the Y plane: 2x2;
The UV plane: 1x2; (H direction sample 1 Cb and 1Cr, V direction 2 lines got 2)
Then:
.char_per_block = {5, 5, 0} block_w = {2, 1, 0}. block_h = {2, 2, 0};
Thanks
James
Hi James,
If the block_w is 2 pixel, one line size at block is 2*10 bit %8 != 0,
although we use block to describe this format, but actually the data is
still stored one line by one line, still need 4 pixel aligned. so i
think here need use 4pixel*2line for per block,
Thanks,
sandy.huang.
.hsub = 2, .vsub = 2, .is_yuv = true},
{ .format = DRM_FORMAT_NV21_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
{ .format = DRM_FORMAT_NV16_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_NV61_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_NV24_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 1, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_NV42_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 1, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_P016, .depth = 0, .num_planes =
2,
.char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes
= 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
.block_h = { 4, 4, 0 },
Hi Sandy:
Their is a problem here for char_per_block size of plane[0]:
Since: 5 * 8 != 4 * 4 * 10;
Seems you mis-set the block_w/h, per your block size the block is 2x2, and
it should be:
.char_per_block = { 5, 10, 0 }, .block_w = { 2, 2, 0 }, .block_h = { 2,
2, 0 },
Best Regards:
James
在 2019/10/8 下午7:49, sandy.huang 写道:
在 2019/10/8 下午7:33, Ville Syrjälä 写道:
On Tue, Oct 08, 2019 at 10:40:20AM +0800, sandy.huang wrote:
Hi ville syrjala,
在 2019/9/30 下午6:48, Ville Syrjälä 写道:
On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
These new format is supported by some rockchip socs:
DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/drm_fourcc.c | 18 ++
include/uapi/drm/drm_fourcc.h | 14 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c
b/drivers/gpu/drm/drm_fourcc.c
index c630064..ccd78a3 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -261,6 +261,24 @@ const struct drm_format_info
*__drm_format_info(u32 format)
{ .format = DRM_FORMAT_P016, .depth =
0, .num_planes = 2,
.char_per_block = { 2, 4, 0 }, .block_w = {
1, 0, 0 }, .block_h = { 1, 0, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV12_10, .depth =
0, .num_planes = 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = {
4, 4, 0 }, .block_h = { 4, 4, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV21_10, .depth =
0, .num_planes = 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = {
4, 4, 0 }, .block_h = { 4, 4, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV16_10, .depth =
0, .num_planes = 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = {
4, 4, 0 }, .block_h = { 4, 4, 0 },
+ .hsub = 2,
Re: [PATCH v2 0/2] Add initial support for slimport anx7625
On 11.10.2019 04:20, Xin Ji wrote: > Hi all, > > The following series add initial support for the Slimport ANX7625 > transmitter, a > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > device. > > This is the initial version, any mistakes, please let me know, I will fix it > in > the next series. > > Thanks, > Xin Next time please increment patchset version number - this is third iteration of v2. Regards Andrzej > > > Xin Ji (2): > dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding > drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver > > .../bindings/display/bridge/anx7625.yaml | 96 + > drivers/gpu/drm/bridge/Makefile|2 +- > drivers/gpu/drm/bridge/analogix/Kconfig|6 + > drivers/gpu/drm/bridge/analogix/Makefile |1 + > drivers/gpu/drm/bridge/analogix/anx7625.c | 2153 > > drivers/gpu/drm/bridge/analogix/anx7625.h | 406 > 6 files changed, 2663 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/anx7625.yaml > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h >
Re: [PATCH v2 4/4] drm/komeda: Adds gamma and color-transform support for DOU-IPS
在 2019/10/11 下午1:43, james qian wang (Arm Technology China) 写道:
From: "Lowry Li (Arm Technology China)"
Adds gamma and color-transform support for DOU-IPS.
Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
If color management changed, set gamma and color-transform accordingly.
Signed-off-by: Lowry Li (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 24 +++
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
.../drm/arm/display/komeda/komeda_pipeline.h | 3 +++
.../display/komeda/komeda_pipeline_state.c| 6 +
4 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index c3d29c0b051b..e7e5a8e4430e 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -942,15 +942,39 @@ static int d71_merger_init(struct d71_dev *d71,
static void d71_improc_update(struct komeda_component *c,
struct komeda_component_state *state)
{
+ struct drm_crtc_state *crtc_st = state->crtc->state;
struct komeda_improc_state *st = to_improc_st(state);
+ struct d71_pipeline *pipe = to_d71_pipeline(c->pipeline);
u32 __iomem *reg = c->reg;
u32 index;
+ u32 mask = 0, ctrl = 0;
for_each_changed_input(state, index)
malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
to_d71_input_id(state, index));
malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
+
+ if (crtc_st->color_mgmt_changed) {
+ mask |= IPS_CTRL_FT | IPS_CTRL_RGB;
+
+ if (crtc_st->gamma_lut) {
+ malidp_write_group(pipe->dou_ft_coeff_addr, FT_COEFF0,
+ KOMEDA_N_GAMMA_COEFFS,
+ st->fgamma_coeffs);
+ ctrl |= IPS_CTRL_FT; /* enable gamma */
+ }
+
+ if (crtc_st->ctm) {
+ malidp_write_group(reg, IPS_RGB_RGB_COEFF0,
+ KOMEDA_N_CTM_COEFFS,
+ st->ctm_coeffs);
+ ctrl |= IPS_CTRL_RGB; /* enable gamut */
+ }
+ }
+
+ if (mask)
+ malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
}
There is no need or no method to disable/bypass the gamma and gamut?
static void d71_improc_dump(struct komeda_component *c, struct seq_file *sf)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 9beeda04818b..406b9d0ca058 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -590,6 +590,8 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
crtc->port = kcrtc->master->of_output_port;
+ drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
+
return err;
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index b322f52ba8f2..c5ab8096c85d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -11,6 +11,7 @@
#include
#include
#include "malidp_utils.h"
+#include "komeda_color_mgmt.h"
#define KOMEDA_MAX_PIPELINES 2
#define KOMEDA_PIPELINE_MAX_LAYERS4
@@ -324,6 +325,8 @@ struct komeda_improc {
struct komeda_improc_state {
struct komeda_component_state base;
u16 hsize, vsize;
+ u32 fgamma_coeffs[KOMEDA_N_GAMMA_COEFFS];
+ u32 ctm_coeffs[KOMEDA_N_CTM_COEFFS];
};
/* display timing controller */
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index 0ba9c6aa3708..4a40b37eb1a6 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -756,6 +756,12 @@ komeda_improc_validate(struct komeda_improc *improc,
st->hsize = dflow->in_w;
st->vsize = dflow->in_h;
+ if (kcrtc_st->base.color_mgmt_changed) {
+ drm_lut_to_fgamma_coeffs(kcrtc_st->base.gamma_lut,
+st->fgamma_coeffs);
+ drm_ctm_to_coeffs(kcrtc_st->base.ctm, st->ctm_coeffs);
+ }
+
komeda_component_add_input(>base, >input, 0);
komeda_component_set_output(>input, >base, 0);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
On Fri, Oct 11, 2019 at 11:35:53AM +0800, sandy.huang wrote:
> Hi james.qian.wang,
>
> Thank for you remind, fou some unknow reason, i miss the the mail from
> you:(, i get this message from https://patchwork.kernel.org/patch/11161937/
>
> sorry about that.
>
> About the format block describe, I also found some unreasonable, this
> format need 2 line aligned, so the block_h need to sed as 2, and the
> char_per_block need set as w * h * 10 for y plane, and w * h * 2 * 10 for uv
> plane, so the following describe maybe more correct, thanks.
>
> { .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes = 2,
> .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
> = { 2, 2, 0 },
> .hsub = 2, .vsub = 2, .is_yuv = true},
Hi Sandy:
I think for such NV12 YUV-422 (hsub = 2, vsub = 2) 2x2 subsampled format
the block size can be:
the Y plane: 2x2;
The UV plane: 1x2; (H direction sample 1 Cb and 1Cr, V direction 2 lines got 2)
Then:
.char_per_block = {5, 5, 0} block_w = {2, 1, 0}. block_h = {2, 2, 0};
Thanks
James
> .hsub = 2, .vsub = 2, .is_yuv = true},
> { .format = DRM_FORMAT_NV21_10, .depth = 0, .num_planes = 2,
> .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
> = { 2, 2, 0 },
> .hsub = 2, .vsub = 2, .is_yuv = true},
> { .format = DRM_FORMAT_NV16_10, .depth = 0, .num_planes = 2,
> .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
> = { 2, 2, 0 },
> .hsub = 2, .vsub = 1, .is_yuv = true},
> { .format = DRM_FORMAT_NV61_10, .depth = 0, .num_planes = 2,
> .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
> = { 2, 2, 0 },
> .hsub = 2, .vsub = 1, .is_yuv = true},
> { .format = DRM_FORMAT_NV24_10, .depth = 0, .num_planes = 2,
> .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
> = { 2, 2, 0 },
> .hsub = 1, .vsub = 1, .is_yuv = true},
> { .format = DRM_FORMAT_NV42_10, .depth = 0, .num_planes = 2,
> .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
> = { 2, 2, 0 },
> .hsub = 1, .vsub = 1, .is_yuv = true},
>
>
> > > { .format = DRM_FORMAT_P016, .depth = 0, .num_planes =
> 2,
> > > .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
> .block_h = { 1, 0, 0 },
> > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > + { .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes
> = 2,
> > > + .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
> .block_h = { 4, 4, 0 },
>
> > Hi Sandy:
> > Their is a problem here for char_per_block size of plane[0]:
> > Since: 5 * 8 != 4 * 4 * 10;
> > Seems you mis-set the block_w/h, per your block size the block is 2x2, and
> it should be:
> > .char_per_block = { 5, 10, 0 }, .block_w = { 2, 2, 0 }, .block_h = { 2,
> 2, 0 },
>
> > Best Regards:
> > James
>
>
>
>
>
>
> 在 2019/10/8 下午7:49, sandy.huang 写道:
> >
> > 在 2019/10/8 下午7:33, Ville Syrjälä 写道:
> > > On Tue, Oct 08, 2019 at 10:40:20AM +0800, sandy.huang wrote:
> > > > Hi ville syrjala,
> > > >
> > > > 在 2019/9/30 下午6:48, Ville Syrjälä 写道:
> > > > > On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
> > > > > > These new format is supported by some rockchip socs:
> > > > > >
> > > > > > DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
> > > > > > DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
> > > > > > DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
> > > > > >
> > > > > > Signed-off-by: Sandy Huang
> > > > > > ---
> > > > > > drivers/gpu/drm/drm_fourcc.c | 18 ++
> > > > > > include/uapi/drm/drm_fourcc.h | 14 ++
> > > > > > 2 files changed, 32 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_fourcc.c
> > > > > > b/drivers/gpu/drm/drm_fourcc.c
> > > > > > index c630064..ccd78a3 100644
> > > > > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > > > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > > > > @@ -261,6 +261,24 @@ const struct drm_format_info
> > > > > > *__drm_format_info(u32 format)
> > > > > > { .format = DRM_FORMAT_P016, .depth =
> > > > > > 0, .num_planes = 2,
> > > > > > .char_per_block = { 2, 4, 0 }, .block_w = {
> > > > > > 1, 0, 0 }, .block_h = { 1, 0, 0 },
> > > > > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > > > > + { .format = DRM_FORMAT_NV12_10, .depth =
> > > > > > 0, .num_planes = 2,
> > > > > > + .char_per_block = { 5, 10, 0 }, .block_w = {
> > > > > > 4, 4, 0 }, .block_h = { 4, 4, 0 },
> > > > > > + .hsub = 2, .vsub = 2, .is_yuv = true},
> > > > > > + { .format = DRM_FORMAT_NV21_10, .depth =
> > > > > > 0, .num_planes = 2,
> > > > > > + .char_per_block = { 5, 10, 0 }, .block_w = {
> > > > > > 4, 4, 0 }, .block_h = { 4, 4, 0 },
> > > > > > + .hsub = 2, .vsub = 2, .is_yuv =
[PATCH] drm/i915: Don't disable interrupts independently of the lock
The locks (active.lock and rq->lock) need to be taken with disabled interrupts. This is done in i915_request_retire() by disabling the interrupts independently of the locks itself. While local_irq_disable()+spin_lock() equals spin_lock_irq() on vanilla it does not on PREEMPT_RT. Also, it is not obvious if there is a special reason to why the interrupts are disabled independently of the lock. Enable/disable interrupts as part of the locking instruction. Signed-off-by: Sebastian Andrzej Siewior --- drivers/gpu/drm/i915/i915_request.c |8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -251,15 +251,13 @@ static bool i915_request_retire(struct i active->retire(active, rq); } - local_irq_disable(); - /* * We only loosely track inflight requests across preemption, * and so we may find ourselves attempting to retire a _completed_ * request that we have removed from the HW and put back on a run * queue. */ - spin_lock(>engine->active.lock); + spin_lock_irq(>engine->active.lock); list_del(>sched.link); spin_unlock(>engine->active.lock); @@ -278,9 +276,7 @@ static bool i915_request_retire(struct i __notify_execute_cb(rq); } GEM_BUG_ON(!list_empty(>execute_cb)); - spin_unlock(>lock); - - local_irq_enable(); + spin_unlock_irq(>lock); remove_from_client(rq); list_del(>link); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/scheduler: make unexported items static
On 09/10/2019 13:14, Ben Dooks wrote:
The drm_sched_fence_ops_{scheduled,finished} are not exported
from the file so make them static to avoid the following
warnings from sparse:
drivers/gpu/drm/scheduler/sched_fence.c:131:28: warning: symbol
'drm_sched_fence_ops_scheduled' was not declared. Should it be static?
drivers/gpu/drm/scheduler/sched_fence.c:137:28: warning: symbol
'drm_sched_fence_ops_finished' was not declared. Should it be static?
Signed-off-by: Ben Dooks
If it is useful I can get these into a public git repo and send
a pull request.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI to DisplayPort 1.3 4K.
You can add support to your board with binding.
Example:
anx7625_bridge: encoder@58 {
compatible = "analogix,anx7625";
reg = <0x58>;
status = "okay";
panel-flags = <1>;
enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
anx_1_in: endpoint {
remote-endpoint = <_dsi>;
};
};
port@3 {
reg = <3>;
anx_1_out: endpoint {
remote-endpoint = <_in>;
};
};
};
Signed-off-by: Xin Ji
---
.../bindings/display/bridge/anx7625.yaml | 96 ++
1 file changed, 96 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/anx7625.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
new file mode 100644
index 000..fc84683
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analogix Semiconductor, Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+
+maintainers:
+ - Xin Ji
+
+description: |
+ The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+ designed for portable devices.
+
+properties:
+ "#address-cells": true
+ "#size-cells": true
+
+ compatible:
+items:
+ - const: analogix,anx7625
+
+ reg:
+maxItems: 1
+
+ panel-flags:
+description: indicate the panel is internal or external
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ enable-gpios:
+description: used for power on chip control, POWER_EN pin D2.
+maxItems: 1
+
+ reset-gpios:
+description: used for reset chip control, RESET_N pin B7.
+maxItems: 1
+
+ port@0:
+type: object
+description:
+ A port node pointing to MIPI DSI host port node.
+
+ port@1:
+type: object
+description:
+ A port node pointing to MIPI DPI host port node.
+
+ port@2:
+type: object
+description:
+ A port node pointing to external connector port node.
+
+ port@3:
+type: object
+description:
+ A port node pointing to eDP port node.
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - compatible
+ - reg
+ - port@0
+ - port@3
+
+example:
+ - |
+anx7625_bridge: encoder@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+status = "okay";
+panel-flags = <1>;
+enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
+reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+ anx_1_in: endpoint {
+remote-endpoint = <_dsi>;
+ };
+};
+
+port@3 {
+ reg = <3>;
+ anx_1_out: endpoint {
+remote-endpoint = <_in>;
+ };
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/msm/dsi: Remove set but not used variable 'lpx'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c: In function msm_dsi_dphy_timing_calc_v2:
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c:156:17: warning: variable lpx set but not
used [-Wunused-but-set-variable]
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c: In function msm_dsi_dphy_timing_calc_v3:
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c:273:17: warning: variable lpx set but not
used [-Wunused-but-set-variable]
'lpx' in msm_dsi_dphy_timing_calc_v2 is not used since commit a4df68fa232e
("drm/msm/dsi: Add new method to calculate 14nm PHY timings")
'lpx' in msm_dsi_dphy_timing_calc_v3 is not used since commit f1fa7ff44056
("drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 3522863..aa22c3a 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -145,7 +145,7 @@ int msm_dsi_dphy_timing_calc_v2(struct msm_dsi_dphy_timing
*timing,
{
const unsigned long bit_rate = clk_req->bitclk_rate;
const unsigned long esc_rate = clk_req->escclk_rate;
- s32 ui, ui_x8, lpx;
+ s32 ui, ui_x8;
s32 tmax, tmin;
s32 pcnt0 = 50;
s32 pcnt1 = 50;
@@ -175,7 +175,6 @@ int msm_dsi_dphy_timing_calc_v2(struct msm_dsi_dphy_timing
*timing,
ui = mult_frac(NSEC_PER_MSEC, coeff, bit_rate / 1000);
ui_x8 = ui << 3;
- lpx = mult_frac(NSEC_PER_MSEC, coeff, esc_rate / 1000);
temp = S_DIV_ROUND_UP(38 * coeff - val_ckln * ui, ui_x8);
tmin = max_t(s32, temp, 0);
@@ -262,7 +261,7 @@ int msm_dsi_dphy_timing_calc_v3(struct msm_dsi_dphy_timing
*timing,
{
const unsigned long bit_rate = clk_req->bitclk_rate;
const unsigned long esc_rate = clk_req->escclk_rate;
- s32 ui, ui_x8, lpx;
+ s32 ui, ui_x8;
s32 tmax, tmin;
s32 pcnt0 = 50;
s32 pcnt1 = 50;
@@ -284,7 +283,6 @@ int msm_dsi_dphy_timing_calc_v3(struct msm_dsi_dphy_timing
*timing,
ui = mult_frac(NSEC_PER_MSEC, coeff, bit_rate / 1000);
ui_x8 = ui << 3;
- lpx = mult_frac(NSEC_PER_MSEC, coeff, esc_rate / 1000);
temp = S_DIV_ROUND_UP(38 * coeff, ui_x8);
tmin = max_t(s32, temp, 0);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/msm: Remove four set but not used variables
zhengbin (4): drm/msm/mdp5: Remove set but not used variable 'fmt' drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in blend_setup drm/msm/dsi: Remove set but not used variable 'lpx' drm/msm/dsi: Remove set but not used variable 'lp' drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 3 --- drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 2 -- drivers/gpu/drm/msm/dsi/dsi_host.c| 3 +-- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 6 ++ 4 files changed, 3 insertions(+), 11 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in blend_setup
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c: In function blend_setup:
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c:225:28: warning: variable hw_cfg set
but not used [-Wunused-but-set-variable]
It is not used since commit 14be3200cd5f ("drm/msm: rename mdp->disp")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index eb0b4b7..05cc04f 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -214,7 +214,6 @@ static void blend_setup(struct drm_crtc *crtc)
struct mdp5_pipeline *pipeline = _cstate->pipeline;
struct mdp5_kms *mdp5_kms = get_kms(crtc);
struct drm_plane *plane;
- const struct mdp5_cfg_hw *hw_cfg;
struct mdp5_plane_state *pstate, *pstates[STAGE_MAX + 1] = {NULL};
const struct mdp_format *format;
struct mdp5_hw_mixer *mixer = pipeline->mixer;
@@ -232,8 +231,6 @@ static void blend_setup(struct drm_crtc *crtc)
u32 val;
#define blender(stage) ((stage) - STAGE0)
- hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
-
spin_lock_irqsave(_crtc->lm_lock, flags);
/* ctl could be released already when we are shutting down: */
--
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/mdp5: Remove set but not used variable 'fmt'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c: In function mdp5_smp_calculate:
drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c:134:6: warning: variable fmt set but
not used [-Wunused-but-set-variable]
It is not used since commit 24c478ead0bf ("drm/fourcc:
Pass the format_info pointer to drm_format_plane_cpp")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
index b31cfb5..d7fa2c4 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
@@ -121,7 +121,6 @@ uint32_t mdp5_smp_calculate(struct mdp5_smp *smp,
struct mdp5_kms *mdp5_kms = get_kms(smp);
int rev = mdp5_cfg_get_hw_rev(mdp5_kms->cfg);
int i, hsub, nplanes, nlines;
- u32 fmt = format->base.pixel_format;
uint32_t blkcfg = 0;
nplanes = info->num_planes;
@@ -135,7 +134,6 @@ uint32_t mdp5_smp_calculate(struct mdp5_smp *smp,
* them together, writes to SMP using a single client.
*/
if ((rev > 0) && (format->chroma_sample > CHROMA_FULL)) {
- fmt = DRM_FORMAT_NV24;
nplanes = 2;
/* if decimation is enabled, HW decimates less on the
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[amdgpu] ASSERT()'s in write_i2c*retimer_setting() functions
Hello, I've built recently a new box with a Ryzen3 2200G APU. Each time I plug in an HDMI cable ( to a TV or Monitor ), or boot with HDMI connected a lot ASSERT()'s from write_i2c*retimer_setting() functions are triggered. I see the same on a Laptop with a Ryzen7 3750H with hybrid GPU configuration. Besides the noise in dmesg and the delay on boot, everything is working fine. I cannot find anything wrong or broken. Since the write errors seem to not be fatal, I think a friendly message would help more instead of flooding the dmesg with dumps while everything is working properly. Why is ASSERT() used there? I have a dmesg from the Ryzen3 box with drm.debug and a snipped from the Laptop ( not near me right now ) uploaded there: https://crazy.dev.frugalware.org/amdgpu/ Please let me know if you need more information, If needed I can upload a dmesg from the Laptop with drm.debug too. Best Regards, Gabriel C ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Kernel crash on 4.19.77-1-lts (Arch Linux / ThinkPad T470p)
Hi there, I wasn't sure which mailing list to use so I BCC'd intel-...@lists.freedesktop.org and dri-devel@lists.freedesktop.org I'm using a Lenovo Thinkpad T470p and running the 4.19.77-1-lts kernel on Arch Linux. Recently, I've started getting freezes each day. Audio can still be heard, but video output stops. I was able to retrieve a call trace from journald. I've attached the output of "sudo lspci -vvv" as well as the message from journald (null pointer dereference). Please let me know if there's anything more I can do to try to track this issue down. Thanks, John kernel_deref Description: Binary data lspci_output Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/msm/dsi: Remove set but not used variable 'lp'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/msm/dsi/dsi_host.c: In function dsi_cmd_dma_rx:
drivers/gpu/drm/msm/dsi/dsi_host.c:1302:7: warning: variable lp set but not
used [-Wunused-but-set-variable]
It is not used since commit a689554ba6ed ("drm/msm:
Initial add DSI connector support")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 663ff9f..4851188 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1291,14 +1291,13 @@ static int dsi_cmd_dma_tx(struct msm_dsi_host
*msm_host, int len)
static int dsi_cmd_dma_rx(struct msm_dsi_host *msm_host,
u8 *buf, int rx_byte, int pkt_size)
{
- u32 *lp, *temp, data;
+ u32 *temp, data;
int i, j = 0, cnt;
u32 read_cnt;
u8 reg[16];
int repeated_bytes = 0;
int buf_offset = buf - msm_host->rx_buf;
- lp = (u32 *)buf;
temp = (u32 *)reg;
cnt = (rx_byte + 3) >> 2;
if (cnt > 4)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Don't disable interrupts independently of the lock
On 2019-10-10 19:11:27 [+0100], Chris Wilson wrote: > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -251,15 +251,13 @@ static bool i915_request_retire(struct i > > active->retire(active, rq); > > } > > > > - local_irq_disable(); > > - > > /* > > * We only loosely track inflight requests across preemption, > > * and so we may find ourselves attempting to retire a _completed_ > > * request that we have removed from the HW and put back on a run > > * queue. > > */ > > - spin_lock(>engine->active.lock); > > + spin_lock_irq(>engine->active.lock); > > list_del(>sched.link); > > spin_unlock(>engine->active.lock); > > > > @@ -278,9 +276,7 @@ static bool i915_request_retire(struct i > > __notify_execute_cb(rq); > > } > > GEM_BUG_ON(!list_empty(>execute_cb)); > > - spin_unlock(>lock); > > - > > - local_irq_enable(); > > + spin_unlock_irq(>lock); > > Nothing screams about the imbalance? irq off from one lock to the other? There is no imbalance, is there? Interrupts are disabled as part of acquiring the first lock and enabled again as part of releasing the second lock. It may not look beautiful. I'm just not sure if this | spin_lock_irq(>engine->active.lock); | list_del(>sched.link); | spin_unlock_irq(>engine->active.lock); | | spin_lock_irq(>lock); | i915_request_mark_complete(rq); … | spin_unlock_irq(>lock); has been avoided because an interrupt here could change something or if this is just an optimisation. > -Chris Sebastian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 7/7] drm/omap: hdmi4: fix use of uninitialized var
* Tomi Valkeinen [191010 06:48]: > On 08/10/2019 17:21, Tony Lindgren wrote: > > * Tomi Valkeinen [191008 14:17]: > > > On 08/10/2019 17:13, Tony Lindgren wrote: > > > > * Tomi Valkeinen [190930 10:38]: > > > > > If use_mclk is false, mclk_mode is written to a register without > > > > > initialization. This doesn't cause any ill effects as the written > > > > > value > > > > > is not used when use_mclk is false. > > > > > > > > > > To fix this, write use_mclk only when use_mclk is true. > > > > > > > > Hey nice catch. Based on a quick test looks like this fixes an > > > > issue where power consumption stays higher after using HDMI. > > > > > > > > Would be nice to have merged in the v5.4-rc series: > > > > > > > > Tested-by: Tony Lindgren > > > > > > Really? Ok, well, then it was a good random find =). > > > > Yeah so it seems :) Earlier I thought there's still some > > clkctrl setting wrong after using HDMI, but did not see > > anything diffing the clkctrl registers before and after > > and gave up. > > > > > I did already push this to drm-misc-next, as I thought it does not have > > > any > > > real effect. I'll check if it's ok to push to drm-misc-fixes too, with Cc > > > stable. > > > > OK great thanks. > > Pushing this to fixes too would cause conflicts, so we shouldn't push > without good reason. How much power saving you see? Sure no rush with this one. I should also test again that it really fixes the issue I'm seeing. Hmm so what register does this clock actually change? I'm seeing an increase of few tens of extra mW, which means at least one day of standby time less for me :) It does not happen always, maybe half of the time. > I think this can still be sent to stable later, after it has been merged to > mainline. Yes sure. Thanks, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/4] drm/komeda: Adds gamma and color-transform support for DOU-IPS
On Fri, Oct 11, 2019 at 02:21:39PM +0800, sandy.huang wrote:
>
> 在 2019/10/11 下午1:43, james qian wang (Arm Technology China) 写道:
> > From: "Lowry Li (Arm Technology China)"
> >
> > Adds gamma and color-transform support for DOU-IPS.
> > Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
> > If color management changed, set gamma and color-transform accordingly.
> >
> > Signed-off-by: Lowry Li (Arm Technology China)
> > ---
> > .../arm/display/komeda/d71/d71_component.c| 24 +++
> > .../gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
> > .../drm/arm/display/komeda/komeda_pipeline.h | 3 +++
> > .../display/komeda/komeda_pipeline_state.c| 6 +
> > 4 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > index c3d29c0b051b..e7e5a8e4430e 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > @@ -942,15 +942,39 @@ static int d71_merger_init(struct d71_dev *d71,
> > static void d71_improc_update(struct komeda_component *c,
> > struct komeda_component_state *state)
> > {
> > + struct drm_crtc_state *crtc_st = state->crtc->state;
> > struct komeda_improc_state *st = to_improc_st(state);
> > + struct d71_pipeline *pipe = to_d71_pipeline(c->pipeline);
> > u32 __iomem *reg = c->reg;
> > u32 index;
> > + u32 mask = 0, ctrl = 0;
> > for_each_changed_input(state, index)
> > malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
> >to_d71_input_id(state, index));
> > malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
> > +
> > + if (crtc_st->color_mgmt_changed) {
> > + mask |= IPS_CTRL_FT | IPS_CTRL_RGB;
NOTE: only when color_mgmt_changed we mark the mask
> > +
> > + if (crtc_st->gamma_lut) {
> > + malidp_write_group(pipe->dou_ft_coeff_addr, FT_COEFF0,
> > + KOMEDA_N_GAMMA_COEFFS,
> > + st->fgamma_coeffs);
> > + ctrl |= IPS_CTRL_FT; /* enable gamma */
Here we enable the gamma, if the change include gamma_lut updating,
and if gammu_lut is NULL, the En-Gamma bit is 0, and gamma will be
disabled
> > + }
> > +
> > + if (crtc_st->ctm) {
> > + malidp_write_group(reg, IPS_RGB_RGB_COEFF0,
> > + KOMEDA_N_CTM_COEFFS,
> > + st->ctm_coeffs);
> > + ctrl |= IPS_CTRL_RGB; /* enable gamut */
> > + }
> > + }
> > +
> > + if (mask)
> > + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
We do have the support to disable gamma/gamut.
the ctrl is for en/dis gamma/gamut, the mask is for indicating which ctrl
bits need to be updated.
See my comments in the code.
Thanks
james
> > }
> There is no need or no method to disable/bypass the gamma and gamut?
> > static void d71_improc_dump(struct komeda_component *c, struct seq_file
> > *sf)
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > index 9beeda04818b..406b9d0ca058 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > @@ -590,6 +590,8 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> > crtc->port = kcrtc->master->of_output_port;
> > + drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
> > +
> > return err;
> > }
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > index b322f52ba8f2..c5ab8096c85d 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include "malidp_utils.h"
> > +#include "komeda_color_mgmt.h"
> > #define KOMEDA_MAX_PIPELINES 2
> > #define KOMEDA_PIPELINE_MAX_LAYERS4
> > @@ -324,6 +325,8 @@ struct komeda_improc {
> > struct komeda_improc_state {
> > struct komeda_component_state base;
> > u16 hsize, vsize;
> > + u32 fgamma_coeffs[KOMEDA_N_GAMMA_COEFFS];
> > + u32 ctm_coeffs[KOMEDA_N_CTM_COEFFS];
> > };
> > /* display timing controller */
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > index 0ba9c6aa3708..4a40b37eb1a6 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > @@ -756,6 +756,12 @@ komeda_improc_validate(struct komeda_improc *improc,
> > st->hsize = dflow->in_w;
> >
Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
On Fri, Oct 11, 2019 at 03:07:22PM +0800, sandy.huang wrote:
>
> 在 2019/10/11 下午2:44, james qian wang (Arm Technology China) 写道:
> > On Fri, Oct 11, 2019 at 11:35:53AM +0800, sandy.huang wrote:
> > > Hi james.qian.wang,
> > >
> > > Thank for you remind, fou some unknow reason, i miss the the mail
> > > from
> > > you:(, i get this message from
> > > https://patchwork.kernel.org/patch/11161937/
> > >
> > > sorry about that.
> > >
> > > About the format block describe, I also found some unreasonable,
> > > this
> > > format need 2 line aligned, so the block_h need to sed as 2, and the
> > > char_per_block need set as w * h * 10 for y plane, and w * h * 2 * 10 for
> > > uv
> > > plane, so the following describe maybe more correct, thanks.
> > >
> > > { .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes =
> > > 2,
> > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > .block_h
> > > = { 2, 2, 0 },
> > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > Hi Sandy:
> > I think for such NV12 YUV-422 (hsub = 2, vsub = 2) 2x2 subsampled format
> > the block size can be:
> >
> > the Y plane: 2x2;
> > The UV plane: 1x2; (H direction sample 1 Cb and 1Cr, V direction 2 lines
> > got 2)
> >
> > Then:
> >
> > .char_per_block = {5, 5, 0} block_w = {2, 1, 0}. block_h = {2, 2, 0};
> >
> > Thanks
> > James
>
> Hi James,
>
> If the block_w is 2 pixel, one line size at block is 2*10 bit %8 != 0,
Hi Sandy:
you got a mistake here, the bpp of UV plane is 20, 10bit Cb + 10 bit Cr.
> although we use block to describe this format, but actually the data is
> still stored one line by one line, still need 4 pixel aligned. so i think
> here need use 4pixel*2line for per block
I think this is your hardware specific requirement.
Thanks
James
>
> Thanks,
>
> sandy.huang.
>
> >
> > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > { .format = DRM_FORMAT_NV21_10, .depth = 0, .num_planes =
> > > 2,
> > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > .block_h
> > > = { 2, 2, 0 },
> > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > { .format = DRM_FORMAT_NV16_10, .depth = 0, .num_planes =
> > > 2,
> > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > .block_h
> > > = { 2, 2, 0 },
> > > .hsub = 2, .vsub = 1, .is_yuv = true},
> > > { .format = DRM_FORMAT_NV61_10, .depth = 0, .num_planes =
> > > 2,
> > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > .block_h
> > > = { 2, 2, 0 },
> > > .hsub = 2, .vsub = 1, .is_yuv = true},
> > > { .format = DRM_FORMAT_NV24_10, .depth = 0, .num_planes =
> > > 2,
> > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > .block_h
> > > = { 2, 2, 0 },
> > > .hsub = 1, .vsub = 1, .is_yuv = true},
> > > { .format = DRM_FORMAT_NV42_10, .depth = 0, .num_planes =
> > > 2,
> > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > .block_h
> > > = { 2, 2, 0 },
> > > .hsub = 1, .vsub = 1, .is_yuv = true},
> > >
> > >
> > > > > { .format = DRM_FORMAT_P016, .depth = 0,
> > > > > .num_planes =
> > > 2,
> > > > > .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
> > > .block_h = { 1, 0, 0 },
> > > > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > > > + { .format = DRM_FORMAT_NV12_10, .depth = 0,
> > > > > .num_planes
> > > = 2,
> > > > > + .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
> > > .block_h = { 4, 4, 0 },
> > >
> > > > Hi Sandy:
> > > > Their is a problem here for char_per_block size of plane[0]:
> > > > Since: 5 * 8 != 4 * 4 * 10;
> > > > Seems you mis-set the block_w/h, per your block size the block is 2x2,
> > > > and
> > > it should be:
> > > > .char_per_block = { 5, 10, 0 }, .block_w = { 2, 2, 0 }, .block_h = {
> > > > 2,
> > > 2, 0 },
> > >
> > > > Best Regards:
> > > > James
> > >
> > >
> > >
> > >
> > >
> > > 在 2019/10/8 下午7:49, sandy.huang 写道:
> > > > 在 2019/10/8 下午7:33, Ville Syrjälä 写道:
> > > > > On Tue, Oct 08, 2019 at 10:40:20AM +0800, sandy.huang wrote:
> > > > > > Hi ville syrjala,
> > > > > >
> > > > > > 在 2019/9/30 下午6:48, Ville Syrjälä 写道:
> > > > > > > On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
> > > > > > > > These new format is supported by some rockchip socs:
> > > > > > > >
> > > > > > > > DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
> > > > > > > > DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
> > > > > > > > DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
> > > > > > > >
> > > > > > > > Signed-off-by: Sandy Huang
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/drm_fourcc.c | 18 ++
> > > > > > > > include/uapi/drm/drm_fourcc.h | 14 ++
> > > > > > > > 2 files changed, 32 insertions(+)
> > > > > > > >
Re: [PATCH v2] drm: bridge: adv7511: Enable SPDIF DAI
On 07.10.2019 12:06, Bogdan Togorean wrote:
> ADV7511 support I2S or SPDIF as audio input interfaces. This commit
> enable support for SPDIF.
>
> Signed-off-by: Bogdan Togorean
Reviewed-by: Andrzej Hajda
Let's wait few days with queuing, with hope somebody will test it.
--
Regards
Andrzej
> ---
>
> Changes in v2:
> - add forgotten break statement
>
> drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> index a428185be2c1..1e9b128d229b 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> @@ -119,6 +119,9 @@ int adv7511_hdmi_hw_params(struct device *dev, void *data,
> audio_source = ADV7511_AUDIO_SOURCE_I2S;
> i2s_format = ADV7511_I2S_FORMAT_LEFT_J;
> break;
> + case HDMI_SPDIF:
> + audio_source = ADV7511_AUDIO_SOURCE_SPDIF;
> + break;
> default:
> return -EINVAL;
> }
> @@ -175,11 +178,21 @@ static int audio_startup(struct device *dev, void *data)
> /* use Audio infoframe updated info */
> regmap_update_bits(adv7511->regmap, ADV7511_REG_GC(1),
> BIT(5), 0);
> + /* enable SPDIF receiver */
> + if (adv7511->audio_source == ADV7511_AUDIO_SOURCE_SPDIF)
> + regmap_update_bits(adv7511->regmap, ADV7511_REG_AUDIO_CONFIG,
> +BIT(7), BIT(7));
> +
> return 0;
> }
>
> static void audio_shutdown(struct device *dev, void *data)
> {
> + struct adv7511 *adv7511 = dev_get_drvdata(dev);
> +
> + if (adv7511->audio_source == ADV7511_AUDIO_SOURCE_SPDIF)
> + regmap_update_bits(adv7511->regmap, ADV7511_REG_AUDIO_CONFIG,
> +BIT(7), 0);
> }
>
> static int adv7511_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
> @@ -213,6 +226,7 @@ static const struct hdmi_codec_pdata codec_data = {
> .ops = _codec_ops,
> .max_i2s_channels = 2,
> .i2s = 1,
> + .spdif = 1,
> };
>
> int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511)
Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
在 2019/10/11 下午3:22, james qian wang (Arm Technology China) 写道:
On Fri, Oct 11, 2019 at 03:07:22PM +0800, sandy.huang wrote:
在 2019/10/11 下午2:44, james qian wang (Arm Technology China) 写道:
On Fri, Oct 11, 2019 at 11:35:53AM +0800, sandy.huang wrote:
Hi james.qian.wang,
Thank for you remind, fou some unknow reason, i miss the the mail from
you:(, i get this message from https://patchwork.kernel.org/patch/11161937/
sorry about that.
About the format block describe, I also found some unreasonable, this
format need 2 line aligned, so the block_h need to sed as 2, and the
char_per_block need set as w * h * 10 for y plane, and w * h * 2 * 10 for uv
plane, so the following describe maybe more correct, thanks.
{ .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
Hi Sandy:
I think for such NV12 YUV-422 (hsub = 2, vsub = 2) 2x2 subsampled format
the block size can be:
the Y plane: 2x2;
The UV plane: 1x2; (H direction sample 1 Cb and 1Cr, V direction 2 lines got 2)
Then:
.char_per_block = {5, 5, 0} block_w = {2, 1, 0}. block_h = {2, 2, 0};
Thanks
James
Hi James,
If the block_w is 2 pixel, one line size at block is 2*10 bit %8 != 0,
Hi Sandy:
you got a mistake here, the bpp of UV plane is 20, 10bit Cb + 10 bit Cr.
here is for y plane.
although we use block to describe this format, but actually the data is
still stored one line by one line, still need 4 pixel aligned. so i think
here need use 4pixel*2line for per block
I think this is your hardware specific requirement.
Thanks
James
yes, this is a new format first used at rockchip platform.
Thanks,
sandy.huang
Thanks,
sandy.huang.
.hsub = 2, .vsub = 2, .is_yuv = true},
{ .format = DRM_FORMAT_NV21_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
{ .format = DRM_FORMAT_NV16_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_NV61_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_NV24_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 1, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_NV42_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 1, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_P016, .depth = 0, .num_planes =
2,
.char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes
= 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
.block_h = { 4, 4, 0 },
Hi Sandy:
Their is a problem here for char_per_block size of plane[0]:
Since: 5 * 8 != 4 * 4 * 10;
Seems you mis-set the block_w/h, per your block size the block is 2x2, and
it should be:
.char_per_block = { 5, 10, 0 }, .block_w = { 2, 2, 0 }, .block_h = { 2,
2, 0 },
Best Regards:
James
在 2019/10/8 下午7:49, sandy.huang 写道:
在 2019/10/8 下午7:33, Ville Syrjälä 写道:
On Tue, Oct 08, 2019 at 10:40:20AM +0800, sandy.huang wrote:
Hi ville syrjala,
在 2019/9/30 下午6:48, Ville Syrjälä 写道:
On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
These new format is supported by some rockchip socs:
DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/drm_fourcc.c | 18 ++
include/uapi/drm/drm_fourcc.h | 14 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c
b/drivers/gpu/drm/drm_fourcc.c
index c630064..ccd78a3 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -261,6 +261,24 @@ const struct drm_format_info
*__drm_format_info(u32 format)
{ .format = DRM_FORMAT_P016, .depth =
0, .num_planes = 2,
.char_per_block = { 2, 4, 0 }, .block_w = {
1, 0, 0 }, .block_h = { 1, 0, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV12_10, .depth =
0, .num_planes = 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = {
4, 4, 0 }, .block_h = { 4, 4, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
+
Re: [pull] ttm drm-fixes-5.4
On Fri, Oct 11, 2019 at 6:24 AM Dave Airlie wrote: > > On Fri, 11 Oct 2019 at 14:20, Dave Airlie wrote: > > > > On Thu, 10 Oct 2019 at 21:58, Koenig, Christian > > wrote: > > > > > > Am 09.10.19 um 09:47 schrieb Arkadiusz Hiler: > > > > On Tue, Oct 08, 2019 at 09:13:41AM -0400, Alex Deucher wrote: > > > >> On Tue, Oct 8, 2019 at 4:04 AM Koenig, Christian > > > >> wrote: > > > >>> My git version should be relative new, but I'm usually using > > > >>> thunderbird > > > >>> to send pull requests not git itself since I want to edit the message > > > >>> before sending. > > > >>> > > > >>> How would I do this in a way patchwork likes it with git? > > > >> FWIW, I usually generate the email first and then use git-send-email > > > >> to actually send it. > > > >> > > > >> Alex > > > > Hey, > > > > > > > > FDO patchwork maintainer here. > > > > > > > > I have tried few things quickly with no luck. There is something fishy > > > > about FDO deployment of patchwork - you email works just fine on my > > > > development instance. > > > > > > > > I have created issue for this: > > > > https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/issues/28 > > > > > > > > Sorry for the inconvenience. > > > > > > Maybe it's the non-Latin letter in my last name? Anyway we need to get > > > the TTM fixes upstream for 5.4. > > > > > > Dave/Daniel any objections that I push those directly to drm-misc-fixes? > > > > Don't bother, I can manually process it, just takes a bit more effort. > > Actually it has a problem, you need to Signed-off-by any commits you touch. > > The first patch should to be correect have your Sob after Thomas > review as you touched it last, > the second patch needs your Sob somewhere in it. So yeah maybe -misc because that makes sure this is all correct :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Hi, On Fri, 11 Oct 2019 at 08:46, Daniel Vetter wrote: > On Thu, Oct 10, 2019 at 7:32 PM Ayan Halder wrote: > > On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote: > > > Sorry I don't understand, you ask me to limit AFBC to ABGR ? > > > > Apologies for the confusion, as per the link, the formats which are > > suggested with AFBC_FORMAT_MOD_YTR are the BGR/ABGR formats (as > > listed in the 'AFBC formats' table) > > > > Thus, any other permutation of the components might make it incompatible > > with some other AFBC producers/consumers. > > Uh, that's not how this is supposed to be used. Drivers are meant to > expose _everything_ they support (bonus if you roughly sort it in > preference order). Userspace then computes the intersection of > modifiers/formats supported by all devices it needs to share a buffer > with. Allowing that was the entire point of modifiers, if we > artificially limit to the common denominator we're back "only linear > works everywhere". Correct. A lot of userspace will select for format first, then find a modifier which can be used with that format. If userspace has specific knowledge of AFBC and decides that it prefers to use AFBC so will seek out an alpha format - and make sure everyone fills the channel solid - then that's fine. But that's putting the cart before the horse. Not exposing XRGB on the primary plane will break a lot of userspace, so in this case AFBC would just never really be used. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 8/8] drm/omap: add OMAP_BO flags to affect buffer allocation
Hi Jean-Jacques,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.4-rc2 next-20191010]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Jean-Jacques-Hiblot/drm-omap-OMAP_BO-flags/20191011-134859
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_new':
>> drivers/gpu/drm/omapdrm/omap_gem.c:1310:3: error: implicit declaration of
>> function 'dma_free_writecombine'; did you mean 'pgprot_writecombine'?
>> [-Werror=implicit-function-declaration]
dma_free_writecombine(dev->dev, size,
^
pgprot_writecombine
cc1: some warnings being treated as errors
vim +1310 drivers/gpu/drm/omapdrm/omap_gem.c
1179
1180 /**
1181 * omap_gem_new() - Create a new GEM buffer
1182 * @dev: The DRM device
1183 * @gsize: The requested size for the GEM buffer. If the buffer is tiled
1184 * (2D buffer), the size is a pair of values: height and width
1185 * expressed in pixels. If the buffers is not tiled, it is
expressed
1186 * in bytes.
1187 * @flags: Flags give additionnal information about the allocation:
1188 * OMAP_BO_TILED_x: use the TILER (2D buffers). The TILER
container
1189 * unit can be 8, 16 or 32 bits. Cache is always disabled
for
1190 * tiled buffers.
1191 * OMAP_BO_SCANOUT: Scannout buffer, consummable by the DSS
1192 * OMAP_BO_CACHED: Buffer CPU caching mode: cached
1193 * OMAP_BO_WC: Buffer CPU caching mode: write-combined
1194 * OMAP_BO_UNCACHED: Buffer CPU caching mode: uncached
1195 * OMAP_BO_MEM_CONTIG: The driver will use dma_alloc to get the
memory.
1196 * This can be used to avoid DMM if the userspace knows it
needs
1197 * more than 128M of memory at the same time.
1198 * OMAP_BO_MEM_DMM: The driver will use DMM to get the memory.
There's
1199 * not much use for this flag at the moment, as on
platforms with
1200 * DMM it is used by default, but it's here for
completeness.
1201 * OMAP_BO_MEM_PIN: The driver will pin the memory at alloc
time, and
1202 * keep it pinned. This can be used to 1) get an error at
alloc
1203 * time if DMM space is full, and 2) get rid of the
constant
1204 * pin/unpin operations which may have some effect on
performance.
1205 *
1206 * Return: The GEM buffer or NULL if the allocation failed
1207 */
1208 struct drm_gem_object *omap_gem_new(struct drm_device *dev,
1209 union omap_gem_size gsize, u32 flags)
1210 {
1211 struct omap_drm_private *priv = dev->dev_private;
1212 struct omap_gem_object *omap_obj;
1213 struct drm_gem_object *obj;
1214 struct address_space *mapping;
1215 size_t size;
1216 int ret;
1217
1218 if (!omap_gem_validate_flags(dev, flags))
1219 return NULL;
1220
1221 /* Validate the flags and compute the memory and cache flags. */
1222 if (flags & OMAP_BO_TILED_MASK) {
1223 /*
1224 * Tiled buffers are always shmem paged backed. When
they are
1225 * scanned out, they are remapped into DMM/TILER.
1226 */
1227 flags |= OMAP_BO_MEM_SHMEM;
1228
1229 /*
1230 * Currently don't allow cached buffers. There is some
caching
1231 * stuff that needs to be handled better.
1232 */
1233 flags &= ~(OMAP_BO_CACHED|OMAP_BO_WC|OMAP_BO_UNCACHED);
1234 flags |= tiler_get_cpu_cache_flags();
1235 } else if ((flags & OMAP_BO_MEM_CONTIG) ||
1236 ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm)) {
1237 /*
1238 * If we don't have DMM, we must allocate scanout
buffers
1239 * from contiguous DMA memory.
1240 */
1241 flags |
[PATCH V3 1/7] mdev: class id support
Mdev bus only supports vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
the first driver could be virtio-mdev. This means we need to add
device class id support in bus match method to pair the mdev device
and mdev driver correctly.
So this patch adds id_table to mdev_driver and class_id for mdev
device with the match method for mdev bus.
Signed-off-by: Jason Wang
---
Documentation/driver-api/vfio-mediated-device.rst | 7 ++-
drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
drivers/s390/cio/vfio_ccw_ops.c | 1 +
drivers/s390/crypto/vfio_ap_ops.c | 1 +
drivers/vfio/mdev/mdev_core.c | 11 +++
drivers/vfio/mdev/mdev_driver.c | 14 ++
drivers/vfio/mdev/mdev_private.h | 1 +
drivers/vfio/mdev/vfio_mdev.c | 6 ++
include/linux/mdev.h | 8
include/linux/mod_devicetable.h | 8
samples/vfio-mdev/mbochs.c| 1 +
samples/vfio-mdev/mdpy.c | 1 +
samples/vfio-mdev/mtty.c | 1 +
13 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/Documentation/driver-api/vfio-mediated-device.rst
b/Documentation/driver-api/vfio-mediated-device.rst
index 25eb7d5b834b..2035e48da7b2 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -102,12 +102,14 @@ structure to represent a mediated device's driver::
* @probe: called when new device created
* @remove: called when device removed
* @driver: device driver structure
+ * @id_table: the ids serviced by this driver
*/
struct mdev_driver {
const char *name;
int (*probe) (struct device *dev);
void (*remove) (struct device *dev);
struct device_driverdriver;
+const struct mdev_class_id *id_table;
};
A mediated bus driver for mdev should use this structure in the function calls
@@ -165,12 +167,15 @@ register itself with the mdev core driver::
extern int mdev_register_device(struct device *dev,
const struct mdev_parent_ops *ops);
+It is also required to specify the class_id through::
+
+ extern int mdev_set_class(struct device *dev, u16 id);
+
However, the mdev_parent_ops structure is not required in the function call
that a driver should use to unregister itself with the mdev core driver::
extern void mdev_unregister_device(struct device *dev);
-
Mediated Device Management Interface Through sysfs
==
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 343d79c1cb7e..17e9d4634c84 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -678,6 +678,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
dev_name(mdev_dev(mdev)));
ret = 0;
+ mdev_set_class(mdev, MDEV_ID_VFIO);
out:
return ret;
}
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index f0d71ab77c50..b5d223882c6c 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -129,6 +129,7 @@ static int vfio_ccw_mdev_create(struct kobject *kobj,
struct mdev_device *mdev)
private->sch->schid.ssid,
private->sch->schid.sch_no);
+ mdev_set_class(mdev, MDEV_ID_VFIO);
return 0;
}
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 5c0f53c6dde7..47df1c593c35 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -343,6 +343,7 @@ static int vfio_ap_mdev_create(struct kobject *kobj, struct
mdev_device *mdev)
list_add(_mdev->node, _dev->mdev_list);
mutex_unlock(_dev->lock);
+ mdev_set_class(mdev, MDEV_ID_VFIO);
return 0;
}
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index b558d4cfd082..724e9b9841d8 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -45,6 +45,12 @@ void mdev_set_drvdata(struct mdev_device *mdev, void *data)
}
EXPORT_SYMBOL(mdev_set_drvdata);
+void mdev_set_class(struct mdev_device *mdev, u16 id)
+{
+ mdev->class_id = id;
+}
+EXPORT_SYMBOL(mdev_set_class);
+
struct device *mdev_dev(struct mdev_device *mdev)
{
return >dev;
@@ -135,6 +141,7 @@ static int mdev_device_remove_cb(struct device *dev, void
*data)
* mdev_register_device : Register a device
* @dev: device structure representing parent device.
* @ops: Parent device operation structure to be registered.
+ * @id: class id.
*
* Add device to list
[PATCH V3 0/7] mdev based hardware virtio offloading support
Hi all: There are hardware that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver to talk with mdev device implementation. Though the series only contains kernel driver support, the goal is to make the transport generic enough to support userspace drivers. This means vhost-mdev[1] could be built on top as well by resuing the transport. A sample driver is also implemented which simulate a virito-net loopback ethernet device on top of vringh + workqueue. This could be used as a reference implementation for real hardware driver. Consider mdev framework only support VFIO device and driver right now, this series also extend it to support other types. This is done through introducing class id to the device and pairing it with id_talbe claimed by the driver. On top, this seris also decouple device specific parents ops out of the common ones. Pktgen test was done with virito-net + mvnet loop back device. Please review. [1] https://lkml.org/lkml/2019/9/26/15 Changes from V2: - fail when class_id is not specified - drop the vringh patch - match the doc to the code - tweak the commit log - move device_ops from parent to mdev device - remove the unused MDEV_ID_VHOST Changes from V1: - move virtio_mdev.c to drivers/virtio - store class_id in mdev_device instead of mdev_parent - store device_ops in mdev_device instead of mdev_parent - reorder the patch, vringh fix comes first - really silent compiling warnings - really switch to use u16 for class_id - uevent and modpost support for mdev class_id - vraious tweaks per comments from Parav Changes from RFC-V2: - silent compile warnings on some specific configuration - use u16 instead u8 for class id - reseve MDEV_ID_VHOST for future vhost-mdev work - introduce "virtio" type for mvnet and make "vhost" type for future work - add entries in MAINTAINER - tweak and typos fixes in commit log Changes from RFC-V1: - rename device id to class id - add docs for class id and device specific ops (device_ops) - split device_ops into seperate headers - drop the mdev_set_dma_ops() - use device_ops to implement the transport API, then it's not a part of UAPI any more - use GFP_ATOMIC in mvnet sample device and other tweaks - set_vring_base/get_vring_base support for mvnet device Jason Wang (7): mdev: class id support mdev: bus uevent support modpost: add support for mdev class id mdev: introduce device specific ops mdev: introduce virtio device and its device ops virtio: introduce a mdev based transport docs: sample driver to demonstrate how to implement virtio-mdev framework .../driver-api/vfio-mediated-device.rst | 25 +- MAINTAINERS | 2 + drivers/gpu/drm/i915/gvt/kvmgt.c | 17 +- drivers/s390/cio/vfio_ccw_ops.c | 17 +- drivers/s390/crypto/vfio_ap_ops.c | 13 +- drivers/vfio/mdev/mdev_core.c | 18 + drivers/vfio/mdev/mdev_driver.c | 22 + drivers/vfio/mdev/mdev_private.h | 2 + drivers/vfio/mdev/vfio_mdev.c | 45 +- drivers/virtio/Kconfig| 7 + drivers/virtio/Makefile | 1 + drivers/virtio/virtio_mdev.c | 416 +++ include/linux/mdev.h | 49 +- include/linux/mod_devicetable.h | 8 + include/linux/vfio_mdev.h | 52 ++ include/linux/virtio_mdev.h | 148 samples/Kconfig | 7 + samples/vfio-mdev/Makefile| 1 + samples/vfio-mdev/mbochs.c| 19 +- samples/vfio-mdev/mdpy.c | 20 +- samples/vfio-mdev/mtty.c | 17 +- samples/vfio-mdev/mvnet.c | 691 ++ scripts/mod/devicetable-offsets.c | 3 + scripts/mod/file2alias.c | 10 + 24 files changed, 1523 insertions(+), 87 deletions(-) create mode 100644 drivers/virtio/virtio_mdev.c create mode 100644 include/linux/vfio_mdev.h create mode 100644 include/linux/virtio_mdev.h create mode 100644 samples/vfio-mdev/mvnet.c -- 2.19.1
[PATCH V3 6/7] virtio: introduce a mdev based transport
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the device with
mdev based config ops. This means it is a software transport between
mdev driver and mdev device. The transport was implemented through
device specific opswhich is a part of mdev_parent_ops now.
Signed-off-by: Jason Wang
---
drivers/virtio/Kconfig | 7 +
drivers/virtio/Makefile | 1 +
drivers/virtio/virtio_mdev.c | 416 +++
3 files changed, 424 insertions(+)
create mode 100644 drivers/virtio/virtio_mdev.c
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 078615cf2afc..8d18722ab572 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -43,6 +43,13 @@ config VIRTIO_PCI_LEGACY
If unsure, say Y.
+config VIRTIO_MDEV_DEVICE
+ tristate "VIRTIO driver for Mediated devices"
+ depends on VFIO_MDEV && VIRTIO
+ default n
+ help
+ VIRTIO based driver for Mediated devices.
+
config VIRTIO_PMEM
tristate "Support for virtio pmem driver"
depends on VIRTIO
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 3a2b5c5dcf46..ebc7fa15ae82 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
+obj-$(CONFIG_VIRTIO_MDEV_DEVICE) += virtio_mdev.o
diff --git a/drivers/virtio/virtio_mdev.c b/drivers/virtio/virtio_mdev.c
new file mode 100644
index ..8516f3f0f658
--- /dev/null
+++ b/drivers/virtio/virtio_mdev.c
@@ -0,0 +1,416 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * VIRTIO based driver for Mediated device
+ *
+ * Copyright (c) 2019, Red Hat. All rights reserved.
+ * Author: Jason Wang
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR "Red Hat Corporation"
+#define DRIVER_DESC "VIRTIO based driver for Mediated device"
+
+#define to_virtio_mdev_device(dev) \
+ container_of(dev, struct virtio_mdev_device, vdev)
+
+struct virtio_mdev_device {
+ struct virtio_device vdev;
+ struct mdev_device *mdev;
+ unsigned long version;
+
+ struct virtqueue **vqs;
+ /* The lock to protect virtqueue list */
+ spinlock_t lock;
+ struct list_head virtqueues;
+};
+
+struct virtio_mdev_vq_info {
+ /* the actual virtqueue */
+ struct virtqueue *vq;
+
+ /* the list node for the virtqueues list */
+ struct list_head node;
+};
+
+static struct mdev_device *vm_get_mdev(struct virtio_device *vdev)
+{
+ struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
+ struct mdev_device *mdev = vm_dev->mdev;
+
+ return mdev;
+}
+
+static void virtio_mdev_get(struct virtio_device *vdev, unsigned offset,
+ void *buf, unsigned len)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ ops->get_config(mdev, offset, buf, len);
+}
+
+static void virtio_mdev_set(struct virtio_device *vdev, unsigned offset,
+ const void *buf, unsigned len)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ ops->set_config(mdev, offset, buf, len);
+}
+
+static u32 virtio_mdev_generation(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->get_generation(mdev);
+}
+
+static u8 virtio_mdev_get_status(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->get_status(mdev);
+}
+
+static void virtio_mdev_set_status(struct virtio_device *vdev, u8 status)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->set_status(mdev, status);
+}
+
+static void virtio_mdev_reset(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->set_status(mdev, 0);
+}
+
+static bool virtio_mdev_notify(struct virtqueue *vq)
+{
+ struct mdev_device *mdev = vm_get_mdev(vq->vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
Re: [PATCH v2 1/4] drm: Add a new helper drm_color_ctm_s31_32_to_qm_n()
Hi James,
On Friday, 11 October 2019 06:45:27 BST james qian wang (Arm Technology China)
wrote:
> Add a new helper function drm_color_ctm_s31_32_to_qm_n() for driver to
> convert S31.32 sign-magnitude to Qm.n 2's complement that supported by
> hardware.
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 23 +++
> include/drm/drm_color_mgmt.h | 2 ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 4ce5c6d8de99..3d533d0b45af 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -132,6 +132,29 @@ uint32_t drm_color_lut_extract(uint32_t user_input,
> uint32_t bit_precision)
> }
> EXPORT_SYMBOL(drm_color_lut_extract);
>
> +/**
> + * drm_color_ctm_s31_32_to_qm_n
> + *
> + * @user_input: input value
> + * @m: number of integer bits
> + * @n: number of fractinal bits
> + *
> + * Convert and clamp S31.32 sign-magnitude to Qm.n 2's complement.
> + */
> +uint64_t drm_color_ctm_s31_32_to_qm_n(uint64_t user_input,
> + uint32_t m, uint32_t n)
> +{
> + u64 mag = (user_input & ~BIT_ULL(63)) >> (32 - n);
This doesn't account for n > 32, which is perfectly possible (e.g. Q1.63).
> + bool negative = !!(user_input & BIT_ULL(63));
> + s64 val;
> +
> + /* the range of signed 2s complement is [-2^n+m, 2^n+m - 1] */
> + val = clamp_val(mag, 0, negative ? BIT(n + m) : BIT(n + m) - 1);
This also doesn't account for n + m == 64.
> +
> + return negative ? 0ll - val : val;
> +}
> +EXPORT_SYMBOL(drm_color_ctm_s31_32_to_qm_n);
> +
> /**
> * drm_crtc_enable_color_mgmt - enable color management properties
> * @crtc: DRM CRTC
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index d1c662d92ab7..60fea5501886 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -30,6 +30,8 @@ struct drm_crtc;
> struct drm_plane;
>
> uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
> +uint64_t drm_color_ctm_s31_32_to_qm_n(uint64_t user_input,
> + uint32_t m, uint32_t n);
>
> void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> uint degamma_lut_size,
> --
> 2.20.1
>
--
Mihail
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/komeda: Add drm_lut_to_fgamma_coeffs()
On Friday, 11 October 2019 06:45:35 BST james qian wang (Arm Technology China)
wrote:
> This function is used to convert drm 3dlut to komeda HW required 1d curve
> coeffs values.
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
> .../arm/display/komeda/komeda_color_mgmt.c| 52 +++
> .../arm/display/komeda/komeda_color_mgmt.h| 9 +++-
> 2 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> index 9d14a92dbb17..c180ce70c26c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> @@ -65,3 +65,55 @@ const s32 *komeda_select_yuv2rgb_coeffs(u32
> color_encoding, u32 color_range)
>
> return coeffs;
> }
> +
> +struct gamma_curve_sector {
> + u32 boundary_start;
> + u32 num_of_segments;
> + u32 segment_width;
> +};
> +
> +struct gamma_curve_segment {
> + u32 start;
> + u32 end;
> +};
> +
> +static struct gamma_curve_sector sector_tbl[] = {
[bikeshed] I'd name this fgamma_sector_tbl (didn't the previous version
of this patch stack have an gamma_curve_sector for igamma?).
> + { 0,4, 4 },
> + { 16, 4, 4 },
> + { 32, 4, 8 },
> + { 64, 4, 16 },
> + { 128, 4, 32 },
> + { 256, 4, 64 },
> + { 512, 16, 32 },
> + { 1024, 24, 128 },
> +};
> +
> +static void
> +drm_lut_to_coeffs(struct drm_property_blob *lut_blob, u32 *coeffs,
> + struct gamma_curve_sector *sector_tbl, u32 num_sectors)
> +{
> + struct drm_color_lut *lut;
> + u32 i, j, in, num = 0;
> +
> + if (!lut_blob)
> + return;
> +
> + lut = lut_blob->data;
> +
> + for (i = 0; i < num_sectors; i++) {
> + for (j = 0; j < sector_tbl[i].num_of_segments; j++) {
> + in = sector_tbl[i].boundary_start +
> + j * sector_tbl[i].segment_width;
> +
> + coeffs[num++] = drm_color_lut_extract(lut[in].red,
> + KOMEDA_COLOR_PRECISION);
> + }
> + }
> +
> + coeffs[num] = BIT(KOMEDA_COLOR_PRECISION);
> +}
> +
> +void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32
> *coeffs)
> +{
> + drm_lut_to_coeffs(lut_blob, coeffs, sector_tbl, ARRAY_SIZE(sector_tbl));
> +}
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> index a2df218f58e7..08ab69281648 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> @@ -11,7 +11,14 @@
> #include
>
> #define KOMEDA_N_YUV2RGB_COEFFS 12
> +#define KOMEDA_N_RGB2YUV_COEFFS 12
> +#define KOMEDA_COLOR_PRECISION 12
> +#define KOMEDA_N_GAMMA_COEFFS65
> +#define KOMEDA_COLOR_LUT_SIZEBIT(KOMEDA_COLOR_PRECISION)
> +#define KOMEDA_N_CTM_COEFFS 9
[nit] The alignment with the group above seems a bit off.
> +
> +void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32
> *coeffs);
>
> const s32 *komeda_select_yuv2rgb_coeffs(u32 color_encoding, u32 color_range);
>
> -#endif
> +#endif /*_KOMEDA_COLOR_MGMT_H_*/
>
Reviewed-by: Mihail Atanassov
--
Mihail
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
On Fri, Oct 11, 2019 at 03:32:17PM +0800, sandy.huang wrote:
>
> 在 2019/10/11 下午3:22, james qian wang (Arm Technology China) 写道:
> > On Fri, Oct 11, 2019 at 03:07:22PM +0800, sandy.huang wrote:
> > > 在 2019/10/11 下午2:44, james qian wang (Arm Technology China) 写道:
> > > > On Fri, Oct 11, 2019 at 11:35:53AM +0800, sandy.huang wrote:
> > > > > Hi james.qian.wang,
> > > > >
> > > > > Thank for you remind, fou some unknow reason, i miss the the
> > > > > mail from
> > > > > you:(, i get this message from
> > > > > https://patchwork.kernel.org/patch/11161937/
> > > > >
> > > > > sorry about that.
> > > > >
> > > > > About the format block describe, I also found some
> > > > > unreasonable, this
> > > > > format need 2 line aligned, so the block_h need to sed as 2, and the
> > > > > char_per_block need set as w * h * 10 for y plane, and w * h * 2 * 10
> > > > > for uv
> > > > > plane, so the following describe maybe more correct, thanks.
> > > > >
> > > > > { .format = DRM_FORMAT_NV12_10, .depth = 0,
> > > > > .num_planes = 2,
> > > > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > > > .block_h
> > > > > = { 2, 2, 0 },
> > > > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > > Hi Sandy:
> > > > I think for such NV12 YUV-422 (hsub = 2, vsub = 2) 2x2 subsampled format
> > > > the block size can be:
> > > >
> > > > the Y plane: 2x2;
> > > > The UV plane: 1x2; (H direction sample 1 Cb and 1Cr, V direction 2
> > > > lines got 2)
> > > >
> > > > Then:
> > > >
> > > > .char_per_block = {5, 5, 0} block_w = {2, 1, 0}. block_h = {2, 2, 0};
> > > >
> > > > Thanks
> > > > James
> > > Hi James,
> > >
> > > If the block_w is 2 pixel, one line size at block is 2*10 bit %8 != 0,
> > Hi Sandy:
> > you got a mistake here, the bpp of UV plane is 20, 10bit Cb + 10 bit Cr.
> here is for y plane.
Sorry, Are we talking about the block size calcaltion here ?
block_size = block_w * block_h * plane_bpp
for you Y plane a 2x2 block is: 2 x 2 * 10 bpp = 40bits
And the block info is for computing the minimum pitch, and don't
consider the specific hardware alignment here.
see: drm_format_info_min_pitch()
If you hardware need alignment, you need to put that consideration into your
specific driver.
James.
> > > although we use block to describe this format, but actually the data is
> > > still stored one line by one line, still need 4 pixel aligned. so i think
> > > here need use 4pixel*2line for per block
> > I think this is your hardware specific requirement.
> >
> > Thanks
> > James
>
> yes, this is a new format first used at rockchip platform.
>
>
> Thanks,
>
> sandy.huang
>
> > > Thanks,
> > >
> > > sandy.huang.
> > >
> > > > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > > > { .format = DRM_FORMAT_NV21_10, .depth = 0,
> > > > > .num_planes = 2,
> > > > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > > > .block_h
> > > > > = { 2, 2, 0 },
> > > > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > > > { .format = DRM_FORMAT_NV16_10, .depth = 0,
> > > > > .num_planes = 2,
> > > > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > > > .block_h
> > > > > = { 2, 2, 0 },
> > > > > .hsub = 2, .vsub = 1, .is_yuv = true},
> > > > > { .format = DRM_FORMAT_NV61_10, .depth = 0,
> > > > > .num_planes = 2,
> > > > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > > > .block_h
> > > > > = { 2, 2, 0 },
> > > > > .hsub = 2, .vsub = 1, .is_yuv = true},
> > > > > { .format = DRM_FORMAT_NV24_10, .depth = 0,
> > > > > .num_planes = 2,
> > > > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > > > .block_h
> > > > > = { 2, 2, 0 },
> > > > > .hsub = 1, .vsub = 1, .is_yuv = true},
> > > > > { .format = DRM_FORMAT_NV42_10, .depth = 0,
> > > > > .num_planes = 2,
> > > > > .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 },
> > > > > .block_h
> > > > > = { 2, 2, 0 },
> > > > > .hsub = 1, .vsub = 1, .is_yuv = true},
> > > > >
> > > > >
> > > > > > > { .format = DRM_FORMAT_P016, .depth = 0,
> > > > > > > .num_planes =
> > > > > 2,
> > > > > > > .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0
> > > > > > > },
> > > > > .block_h = { 1, 0, 0 },
> > > > > > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > > > > > + { .format = DRM_FORMAT_NV12_10, .depth = 0,
> > > > > > > .num_planes
> > > > > = 2,
> > > > > > > + .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
> > > > > .block_h = { 4, 4, 0 },
> > > > >
> > > > > > Hi Sandy:
> > > > > > Their is a problem here for char_per_block size of plane[0]:
> > > > > > Since: 5 * 8 != 4 * 4 * 10;
> > > > > > Seems you mis-set the block_w/h, per your block size
Re: [PATCH v2 3/4] drm/komeda: Add drm_ctm_to_coeffs()
On Friday, 11 October 2019 06:45:42 BST james qian wang (Arm Technology China)
wrote:
> This function is for converting drm_color_ctm matrix to komeda hardware
> required required Q2.12 2's complement CSC matrix.
>
> v2:
> Move the fixpoint conversion function s31_32_to_q2_12() to drm core
> as a shared helper.
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
> .../gpu/drm/arm/display/komeda/komeda_color_mgmt.c | 14 ++
> .../gpu/drm/arm/display/komeda/komeda_color_mgmt.h | 1 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> index c180ce70c26c..ad668accbdf4 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> @@ -117,3 +117,17 @@ void drm_lut_to_fgamma_coeffs(struct drm_property_blob
> *lut_blob, u32 *coeffs)
> {
> drm_lut_to_coeffs(lut_blob, coeffs, sector_tbl, ARRAY_SIZE(sector_tbl));
> }
> +
> +void drm_ctm_to_coeffs(struct drm_property_blob *ctm_blob, u32 *coeffs)
[nit] Could do with an extra const or two on the drm_property_blob,
otherwise...
> +{
> + struct drm_color_ctm *ctm;
> + u32 i;
> +
> + if (!ctm_blob)
> + return;
> +
> + ctm = ctm_blob->data;
> +
> + for (i = 0; i < KOMEDA_N_CTM_COEFFS; i++)
> + coeffs[i] = drm_color_ctm_s31_32_to_qm_n(ctm->matrix[i], 2, 12);
> +}
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> index 08ab69281648..2f4668466112 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.h
> @@ -18,6 +18,7 @@
> #define KOMEDA_N_CTM_COEFFS 9
>
> void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32
> *coeffs);
> +void drm_ctm_to_coeffs(struct drm_property_blob *ctm_blob, u32 *coeffs);
>
> const s32 *komeda_select_yuv2rgb_coeffs(u32 color_encoding, u32 color_range);
>
>
...
Reviewed-by: Mihail Atanassov
--
Mihail
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Hi Neil,
On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> Hi Ayan,
>
> On 10/10/2019 15:26, Ayan Halder wrote:
> > On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
> >> This adds all the OSD configuration plumbing to support the AFBC decoders
> >> path to display of the OSD1 plane.
> >>
> >> The Amlogic GXM and G12A AFBC decoders are integrated very differently.
> >>
> >> The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
> >> because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
> >>
> >> On the other side, the Amlogic G12A AFBC decoder seems to be an external
> >> IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
> >> feeding the OSD1 VIU pixel input.
> >> This uses a weird "0x100" internal HW physical address on both
> >> sides to transfer the pixels.
> >>
> >> For Amlogic GXM, the supported pixel formats are the same as the normal
> >> linear OSD1 mode.
> >>
> >> On the other side, Amlogic added support for all AFBC v1.2 formats for
> >> the G12A AFBC integration.
> >>
> >> For simplicity, we stick to the already supported formats for now.
> >>
> >> Signed-off-by: Neil Armstrong
> >> ---
> >> drivers/gpu/drm/meson/meson_crtc.c | 2 +
> >> drivers/gpu/drm/meson/meson_drv.h | 4 +
> >> drivers/gpu/drm/meson/meson_plane.c | 215
> >> 3 files changed, 190 insertions(+), 31 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/meson/meson_crtc.c
> >> b/drivers/gpu/drm/meson/meson_crtc.c
> >> index 57ae1c13d1e6..d478fa232951 100644
> >> --- a/drivers/gpu/drm/meson/meson_crtc.c
> >> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> >> @@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
> >>if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
> >>writel_relaxed(priv->viu.osd1_ctrl_stat,
> >>priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
> >> + writel_relaxed(priv->viu.osd1_ctrl_stat2,
> >> + priv->io_base + _REG(VIU_OSD1_CTRL_STAT2));
> >>writel_relaxed(priv->viu.osd1_blk0_cfg[0],
> >>priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W0));
> >>writel_relaxed(priv->viu.osd1_blk0_cfg[1],
> >> diff --git a/drivers/gpu/drm/meson/meson_drv.h
> >> b/drivers/gpu/drm/meson/meson_drv.h
> >> index 60f13c6f34e5..de25349be8aa 100644
> >> --- a/drivers/gpu/drm/meson/meson_drv.h
> >> +++ b/drivers/gpu/drm/meson/meson_drv.h
> >> @@ -53,8 +53,12 @@ struct meson_drm {
> >>bool osd1_enabled;
> >>bool osd1_interlace;
> >>bool osd1_commit;
> >> + bool osd1_afbcd;
> >>uint32_t osd1_ctrl_stat;
> >> + uint32_t osd1_ctrl_stat2;
> >>uint32_t osd1_blk0_cfg[5];
> >> + uint32_t osd1_blk1_cfg4;
> >> + uint32_t osd1_blk2_cfg4;
> >>uint32_t osd1_addr;
> >>uint32_t osd1_stride;
> >>uint32_t osd1_height;
> >> diff --git a/drivers/gpu/drm/meson/meson_plane.c
> >> b/drivers/gpu/drm/meson/meson_plane.c
> >> index 5e798c276037..412941aa8402 100644
> >> --- a/drivers/gpu/drm/meson/meson_plane.c
> >> +++ b/drivers/gpu/drm/meson/meson_plane.c
> >> @@ -23,6 +23,7 @@
> >> #include "meson_plane.h"
> >> #include "meson_registers.h"
> >> #include "meson_viu.h"
> >> +#include "meson_osd_afbcd.h"
> >>
> >> /* OSD_SCI_WH_M1 */
> >> #define SCI_WH_M1_W(w)FIELD_PREP(GENMASK(28, 16), w)
> >> @@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane
> >> *plane,
> >> false, true);
> >> }
> >>
> >> +#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> >> \
> >> + AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |\
> >> + AFBC_FORMAT_MOD_YTR |\
> >> + AFBC_FORMAT_MOD_SPARSE | \
> >> + AFBC_FORMAT_MOD_SPLIT)
> >> +
> >> /* Takes a fixed 16.16 number and converts it to integer. */
> >> static inline int64_t fixed16_to_int(int64_t value)
> >> {
> >>return value >> 16;
> >> }
> >>
> >> +static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv)
> >> +{
> >> + u32 line_stride = 0;
> >> +
> >> + switch (priv->afbcd.format) {
> >> + case DRM_FORMAT_RGB565:
> >> + line_stride = ((priv->viu.osd1_width << 4) + 127) >> 7;
> >> + break;
> >> + case DRM_FORMAT_RGB888:
> >> + case DRM_FORMAT_XRGB:
> >> + case DRM_FORMAT_ARGB:
> >> + case DRM_FORMAT_XBGR:
> >> + case DRM_FORMAT_ABGR:
> > Please have a look at
> > https://www.kernel.org/doc/html/latest/gpu/afbc.html for our
> > recommendation. We suggest that *X* formats are avoided.
> >
> > Also, for interoperability and maximum compression efficiency (with
> > AFBC_FORMAT_MOD_YTR), we suggest the following order :-
> >
> > Component 0: R
>
Re: [PATCH v2 4/4] drm/komeda: Adds gamma and color-transform support for DOU-IPS
Hi James, Lowry,
On Friday, 11 October 2019 06:45:50 BST james qian wang (Arm Technology China)
wrote:
> From: "Lowry Li (Arm Technology China)"
>
> Adds gamma and color-transform support for DOU-IPS.
> Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
> If color management changed, set gamma and color-transform accordingly.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
> .../arm/display/komeda/d71/d71_component.c| 24 +++
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
> .../drm/arm/display/komeda/komeda_pipeline.h | 3 +++
> .../display/komeda/komeda_pipeline_state.c| 6 +
> 4 files changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> index c3d29c0b051b..e7e5a8e4430e 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -942,15 +942,39 @@ static int d71_merger_init(struct d71_dev *d71,
> static void d71_improc_update(struct komeda_component *c,
> struct komeda_component_state *state)
> {
> + struct drm_crtc_state *crtc_st = state->crtc->state;
I'm not sure it's a good idea to introduce a dependency on drm state
so far down in the HW funcs, is there a good reason for the direct prod?
> struct komeda_improc_state *st = to_improc_st(state);
> + struct d71_pipeline *pipe = to_d71_pipeline(c->pipeline);
> u32 __iomem *reg = c->reg;
> u32 index;
> + u32 mask = 0, ctrl = 0;
>
> for_each_changed_input(state, index)
> malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
> to_d71_input_id(state, index));
>
> malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
> +
> + if (crtc_st->color_mgmt_changed) {
> + mask |= IPS_CTRL_FT | IPS_CTRL_RGB;
> +
> + if (crtc_st->gamma_lut) {
> + malidp_write_group(pipe->dou_ft_coeff_addr, FT_COEFF0,
> +KOMEDA_N_GAMMA_COEFFS,
> +st->fgamma_coeffs);
> + ctrl |= IPS_CTRL_FT; /* enable gamma */
> + }
> +
> + if (crtc_st->ctm) {
> + malidp_write_group(reg, IPS_RGB_RGB_COEFF0,
> +KOMEDA_N_CTM_COEFFS,
> +st->ctm_coeffs);
> + ctrl |= IPS_CTRL_RGB; /* enable gamut */
> + }
> + }
> +
> + if (mask)
> + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
> }
>
> static void d71_improc_dump(struct komeda_component *c, struct seq_file *sf)
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 9beeda04818b..406b9d0ca058 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -590,6 +590,8 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>
> crtc->port = kcrtc->master->of_output_port;
>
> + drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
> +
> return err;
> }
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> index b322f52ba8f2..c5ab8096c85d 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> @@ -11,6 +11,7 @@
> #include
> #include
> #include "malidp_utils.h"
> +#include "komeda_color_mgmt.h"
>
> #define KOMEDA_MAX_PIPELINES 2
> #define KOMEDA_PIPELINE_MAX_LAYERS 4
> @@ -324,6 +325,8 @@ struct komeda_improc {
> struct komeda_improc_state {
> struct komeda_component_state base;
> u16 hsize, vsize;
> + u32 fgamma_coeffs[KOMEDA_N_GAMMA_COEFFS];
> + u32 ctm_coeffs[KOMEDA_N_CTM_COEFFS];
> };
>
> /* display timing controller */
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> index 0ba9c6aa3708..4a40b37eb1a6 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> @@ -756,6 +756,12 @@ komeda_improc_validate(struct komeda_improc *improc,
> st->hsize = dflow->in_w;
> st->vsize = dflow->in_h;
>
> + if (kcrtc_st->base.color_mgmt_changed) {
> + drm_lut_to_fgamma_coeffs(kcrtc_st->base.gamma_lut,
> + st->fgamma_coeffs);
> + drm_ctm_to_coeffs(kcrtc_st->base.ctm, st->ctm_coeffs);
> + }
> +
> komeda_component_add_input(>base, >input, 0);
> komeda_component_set_output(>input, >base, 0);
>
>
--
Mihail
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
On Thu, Oct 10, 2019 at 7:32 PM Ayan Halder wrote:
>
> On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> > Hi Ayan,
> >
> > On 10/10/2019 15:26, Ayan Halder wrote:
> > > On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
> > >> This adds all the OSD configuration plumbing to support the AFBC decoders
> > >> path to display of the OSD1 plane.
> > >>
> > >> The Amlogic GXM and G12A AFBC decoders are integrated very differently.
> > >>
> > >> The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
> > >> because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
> > >>
> > >> On the other side, the Amlogic G12A AFBC decoder seems to be an external
> > >> IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
> > >> feeding the OSD1 VIU pixel input.
> > >> This uses a weird "0x100" internal HW physical address on both
> > >> sides to transfer the pixels.
> > >>
> > >> For Amlogic GXM, the supported pixel formats are the same as the normal
> > >> linear OSD1 mode.
> > >>
> > >> On the other side, Amlogic added support for all AFBC v1.2 formats for
> > >> the G12A AFBC integration.
> > >>
> > >> For simplicity, we stick to the already supported formats for now.
> > >>
> > >> Signed-off-by: Neil Armstrong
> > >> ---
> > >> drivers/gpu/drm/meson/meson_crtc.c | 2 +
> > >> drivers/gpu/drm/meson/meson_drv.h | 4 +
> > >> drivers/gpu/drm/meson/meson_plane.c | 215
> > >> 3 files changed, 190 insertions(+), 31 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/meson/meson_crtc.c
> > >> b/drivers/gpu/drm/meson/meson_crtc.c
> > >> index 57ae1c13d1e6..d478fa232951 100644
> > >> --- a/drivers/gpu/drm/meson/meson_crtc.c
> > >> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> > >> @@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
> > >>if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
> > >>writel_relaxed(priv->viu.osd1_ctrl_stat,
> > >>priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
> > >> + writel_relaxed(priv->viu.osd1_ctrl_stat2,
> > >> + priv->io_base + _REG(VIU_OSD1_CTRL_STAT2));
> > >>writel_relaxed(priv->viu.osd1_blk0_cfg[0],
> > >>priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W0));
> > >>writel_relaxed(priv->viu.osd1_blk0_cfg[1],
> > >> diff --git a/drivers/gpu/drm/meson/meson_drv.h
> > >> b/drivers/gpu/drm/meson/meson_drv.h
> > >> index 60f13c6f34e5..de25349be8aa 100644
> > >> --- a/drivers/gpu/drm/meson/meson_drv.h
> > >> +++ b/drivers/gpu/drm/meson/meson_drv.h
> > >> @@ -53,8 +53,12 @@ struct meson_drm {
> > >>bool osd1_enabled;
> > >>bool osd1_interlace;
> > >>bool osd1_commit;
> > >> + bool osd1_afbcd;
> > >>uint32_t osd1_ctrl_stat;
> > >> + uint32_t osd1_ctrl_stat2;
> > >>uint32_t osd1_blk0_cfg[5];
> > >> + uint32_t osd1_blk1_cfg4;
> > >> + uint32_t osd1_blk2_cfg4;
> > >>uint32_t osd1_addr;
> > >>uint32_t osd1_stride;
> > >>uint32_t osd1_height;
> > >> diff --git a/drivers/gpu/drm/meson/meson_plane.c
> > >> b/drivers/gpu/drm/meson/meson_plane.c
> > >> index 5e798c276037..412941aa8402 100644
> > >> --- a/drivers/gpu/drm/meson/meson_plane.c
> > >> +++ b/drivers/gpu/drm/meson/meson_plane.c
> > >> @@ -23,6 +23,7 @@
> > >> #include "meson_plane.h"
> > >> #include "meson_registers.h"
> > >> #include "meson_viu.h"
> > >> +#include "meson_osd_afbcd.h"
> > >>
> > >> /* OSD_SCI_WH_M1 */
> > >> #define SCI_WH_M1_W(w)FIELD_PREP(GENMASK(28, 16), w)
> > >> @@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane
> > >> *plane,
> > >> false, true);
> > >> }
> > >>
> > >> +#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> > >> \
> > >> + AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |\
> > >> + AFBC_FORMAT_MOD_YTR |\
> > >> + AFBC_FORMAT_MOD_SPARSE | \
> > >> + AFBC_FORMAT_MOD_SPLIT)
> > >> +
> > >> /* Takes a fixed 16.16 number and converts it to integer. */
> > >> static inline int64_t fixed16_to_int(int64_t value)
> > >> {
> > >>return value >> 16;
> > >> }
> > >>
> > >> +static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv)
> > >> +{
> > >> + u32 line_stride = 0;
> > >> +
> > >> + switch (priv->afbcd.format) {
> > >> + case DRM_FORMAT_RGB565:
> > >> + line_stride = ((priv->viu.osd1_width << 4) + 127) >> 7;
> > >> + break;
> > >> + case DRM_FORMAT_RGB888:
> > >> + case DRM_FORMAT_XRGB:
> > >> + case DRM_FORMAT_ARGB:
> > >> + case DRM_FORMAT_XBGR:
> > >> + case DRM_FORMAT_ABGR:
> > > Please have a look at
> > >
Re: [PATCH v2 0/2] Add initial support for slimport anx7625
Hi Andrzej, OK, I'll increment patchset version number next time. Thanks, Xin On Fri, Oct 11, 2019 at 08:12:53AM +0200, Andrzej Hajda wrote: > On 11.10.2019 04:20, Xin Ji wrote: > > Hi all, > > > > The following series add initial support for the Slimport ANX7625 > > transmitter, a > > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > > device. > > > > This is the initial version, any mistakes, please let me know, I will fix > > it in > > the next series. > > > > Thanks, > > Xin > > > Next time please increment patchset version number - this is third > iteration of v2. > > > Regards > > Andrzej > > > > > > > > Xin Ji (2): > > dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding > > drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver > > > > .../bindings/display/bridge/anx7625.yaml | 96 + > > drivers/gpu/drm/bridge/Makefile|2 +- > > drivers/gpu/drm/bridge/analogix/Kconfig|6 + > > drivers/gpu/drm/bridge/analogix/Makefile |1 + > > drivers/gpu/drm/bridge/analogix/anx7625.c | 2153 > > > > drivers/gpu/drm/bridge/analogix/anx7625.h | 406 > > 6 files changed, 2663 insertions(+), 1 deletion(-) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/anx7625.yaml > > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c > > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h > >
[PATCH V3 2/7] mdev: bus uevent support
This patch adds bus uevent support for mdev bus in order to allow
cooperation with userspace.
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/mdev_driver.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/vfio/mdev/mdev_driver.c b/drivers/vfio/mdev/mdev_driver.c
index b7c40ce86ee3..319d886ffaf7 100644
--- a/drivers/vfio/mdev/mdev_driver.c
+++ b/drivers/vfio/mdev/mdev_driver.c
@@ -82,9 +82,17 @@ static int mdev_match(struct device *dev, struct
device_driver *drv)
return 0;
}
+static int mdev_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+ struct mdev_device *mdev = to_mdev_device(dev);
+
+ return add_uevent_var(env, "MODALIAS=mdev:c%02X", mdev->class_id);
+}
+
struct bus_type mdev_bus_type = {
.name = "mdev",
.match = mdev_match,
+ .uevent = mdev_uevent,
.probe = mdev_probe,
.remove = mdev_remove,
};
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3 3/7] modpost: add support for mdev class id
Add support to parse mdev class id table.
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/vfio_mdev.c | 2 ++
scripts/mod/devicetable-offsets.c | 3 +++
scripts/mod/file2alias.c | 10 ++
3 files changed, 15 insertions(+)
diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
index fd2a4d9a3f26..891cf83a2d9a 100644
--- a/drivers/vfio/mdev/vfio_mdev.c
+++ b/drivers/vfio/mdev/vfio_mdev.c
@@ -125,6 +125,8 @@ static struct mdev_class_id id_table[] = {
{ 0 },
};
+MODULE_DEVICE_TABLE(mdev, id_table);
+
static struct mdev_driver vfio_mdev_driver = {
.name = "vfio_mdev",
.probe = vfio_mdev_probe,
diff --git a/scripts/mod/devicetable-offsets.c
b/scripts/mod/devicetable-offsets.c
index 054405b90ba4..6cbb1062488a 100644
--- a/scripts/mod/devicetable-offsets.c
+++ b/scripts/mod/devicetable-offsets.c
@@ -231,5 +231,8 @@ int main(void)
DEVID(wmi_device_id);
DEVID_FIELD(wmi_device_id, guid_string);
+ DEVID(mdev_class_id);
+ DEVID_FIELD(mdev_class_id, id);
+
return 0;
}
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index c91eba751804..d365dfe7c718 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1335,6 +1335,15 @@ static int do_wmi_entry(const char *filename, void
*symval, char *alias)
return 1;
}
+/* looks like: "mdev:cN" */
+static int do_mdev_entry(const char *filename, void *symval, char *alias)
+{
+ DEF_FIELD(symval, mdev_class_id, id);
+
+ sprintf(alias, "mdev:c%02X", id);
+ return 1;
+}
+
/* Does namelen bytes of name exactly match the symbol? */
static bool sym_is(const char *name, unsigned namelen, const char *symbol)
{
@@ -1407,6 +1416,7 @@ static const struct devtable devtable[] = {
{"typec", SIZE_typec_device_id, do_typec_entry},
{"tee", SIZE_tee_client_device_id, do_tee_entry},
{"wmi", SIZE_wmi_device_id, do_wmi_entry},
+ {"mdev", SIZE_mdev_class_id, do_mdev_entry},
};
/* Create MODULE_ALIAS() statements.
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3 5/7] mdev: introduce virtio device and its device ops
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Signed-off-by: Jason Wang
---
include/linux/mdev.h| 1 +
include/linux/virtio_mdev.h | 148
2 files changed, 149 insertions(+)
create mode 100644 include/linux/virtio_mdev.h
diff --git a/include/linux/mdev.h b/include/linux/mdev.h
index f491308674e5..298581e7ad45 100644
--- a/include/linux/mdev.h
+++ b/include/linux/mdev.h
@@ -124,6 +124,7 @@ struct mdev_device *mdev_from_dev(struct device *dev);
enum {
MDEV_ID_VFIO = 1,
+ MDEV_ID_VIRTIO = 2,
/* New entries must be added here */
};
diff --git a/include/linux/virtio_mdev.h b/include/linux/virtio_mdev.h
new file mode 100644
index ..b39c62534acc
--- /dev/null
+++ b/include/linux/virtio_mdev.h
@@ -0,0 +1,148 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Virtio mediated device driver
+ *
+ * Copyright 2019, Red Hat Corp.
+ * Author: Jason Wang
+ */
+#ifndef _LINUX_VIRTIO_MDEV_H
+#define _LINUX_VIRTIO_MDEV_H
+
+#include
+#include
+#include
+
+#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
+#define VIRTIO_MDEV_F_VERSION_1 0x1
+
+struct virtio_mdev_callback {
+ irqreturn_t (*callback)(void *data);
+ void *private;
+};
+
+/**
+ * struct vfio_mdev_device_ops - Structure to be registered for each
+ * mdev device to register the device to virtio-mdev module.
+ *
+ * @set_vq_address:Set the address of virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @desc_area: address of desc area
+ * @driver_area: address of driver area
+ * @device_area: address of device area
+ * Returns integer: success (0) or error (< 0)
+ * @set_vq_num:Set the size of virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @num: the size of virtqueue
+ * @kick_vq: Kick the virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @set_vq_cb: Set the interrut calback function for
+ * a virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @cb: virtio-mdev interrupt callback structure
+ * @set_vq_ready: Set ready status for a virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @ready: ready (true) not ready(false)
+ * @get_vq_ready: Get ready status for a virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * Returns boolean: ready (true) or not (false)
+ * @set_vq_state: Set the state for a virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @state: virtqueue state (last_avail_idx)
+ * Returns integer: success (0) or error (< 0)
+ * @get_vq_state: Get the state for a virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * Returns virtqueue state (last_avail_idx)
+ * @get_vq_align: Get the virtqueue align requirement
+ * for the device
+ * @mdev: mediated device
+ * Returns virtqueue algin requirement
+ * @get_features: Get virtio features supported by the device
+ * @mdev: mediated device
+ * Returns the virtio features support by the
+ * device
+ * @get_features: Set virtio features supported by the driver
+ * @mdev: mediated device
+ * @features: feature support by the driver
+ * Returns integer: success (0) or error (< 0)
+ * @set_config_cb: Set the config interrupt callback
+ * @mdev: mediated device
+ * @cb: virtio-mdev interrupt callback structure
+ * @get_vq_num_max:Get the max size of virtqueue
+ * @mdev: mediated device
+ * Returns u16: max size of virtqueue
+ * @get_device_id: Get virtio device id
+ * @mdev: mediated device
+ * Returns u32: virtio device id
+ * @get_vendor_id:
[PATCH V3 4/7] mdev: introduce device specific ops
Currently, except for the create and remove, the rest of
mdev_parent_ops is designed for vfio-mdev driver only and may not help
for kernel mdev driver. With the help of class id, this patch
introduces device specific callbacks inside mdev_device
structure. This allows different set of callback to be used by
vfio-mdev and virtio-mdev.
Signed-off-by: Jason Wang
---
.../driver-api/vfio-mediated-device.rst | 22 +---
MAINTAINERS | 1 +
drivers/gpu/drm/i915/gvt/kvmgt.c | 18 ---
drivers/s390/cio/vfio_ccw_ops.c | 18 ---
drivers/s390/crypto/vfio_ap_ops.c | 14 +++--
drivers/vfio/mdev/mdev_core.c | 9 +++-
drivers/vfio/mdev/mdev_private.h | 1 +
drivers/vfio/mdev/vfio_mdev.c | 37 ++---
include/linux/mdev.h | 42 +++
include/linux/vfio_mdev.h | 52 +++
samples/vfio-mdev/mbochs.c| 20 ---
samples/vfio-mdev/mdpy.c | 21 +---
samples/vfio-mdev/mtty.c | 18 ---
13 files changed, 177 insertions(+), 96 deletions(-)
create mode 100644 include/linux/vfio_mdev.h
diff --git a/Documentation/driver-api/vfio-mediated-device.rst
b/Documentation/driver-api/vfio-mediated-device.rst
index 2035e48da7b2..553574ebba73 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -152,11 +152,20 @@ callbacks per mdev parent device, per mdev type, or any
other categorization.
Vendor drivers are expected to be fully asynchronous in this respect or
provide their own internal resource protection.)
-The callbacks in the mdev_parent_ops structure are as follows:
+In order to support multiple types of device/driver, device needs to
+provide both class_id and device_ops through:
-* open: open callback of mediated device
-* close: close callback of mediated device
-* ioctl: ioctl callback of mediated device
+void mdev_set_class(struct mdev_device *mdev, u16 id, const void *ops);
+
+The class_id is used to be paired with ids in id_table in mdev_driver
+structure for probing the correct driver. The device_ops is device
+specific callbacks which can be get through mdev_get_dev_ops()
+function by mdev bus driver. For vfio-mdev device, its device specific
+ops are as follows:
+
+* open: open callback of vfio mediated device
+* close: close callback of vfio mediated device
+* ioctl: ioctl callback of vfio mediated device
* read : read emulation callback
* write: write emulation callback
* mmap: mmap emulation callback
@@ -167,9 +176,10 @@ register itself with the mdev core driver::
extern int mdev_register_device(struct device *dev,
const struct mdev_parent_ops *ops);
-It is also required to specify the class_id through::
+It is also required to specify the class_id and device specific ops through::
- extern int mdev_set_class(struct device *dev, u16 id);
+ extern int mdev_set_class(struct device *dev, u16 id,
+ const void *ops);
However, the mdev_parent_ops structure is not required in the function call
that a driver should use to unregister itself with the mdev core driver::
diff --git a/MAINTAINERS b/MAINTAINERS
index 8824f61cd2c0..3d196a023b5e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17127,6 +17127,7 @@ S: Maintained
F: Documentation/driver-api/vfio-mediated-device.rst
F: drivers/vfio/mdev/
F: include/linux/mdev.h
+F: include/linux/vfio_mdev.h
F: samples/vfio-mdev/
VFIO PLATFORM DRIVER
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 17e9d4634c84..7e2b720074fd 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -643,6 +644,8 @@ static void kvmgt_put_vfio_device(void *vgpu)
vfio_device_put(((struct intel_vgpu *)vgpu)->vdev.vfio_device);
}
+static const struct vfio_mdev_device_ops intel_vfio_vgpu_dev_ops;
+
static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
{
struct intel_vgpu *vgpu = NULL;
@@ -678,7 +681,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
dev_name(mdev_dev(mdev)));
ret = 0;
- mdev_set_class(mdev, MDEV_ID_VFIO);
+ mdev_set_class(mdev, MDEV_ID_VFIO, _vfio_vgpu_dev_ops);
out:
return ret;
}
@@ -1599,20 +1602,21 @@ static const struct attribute_group
*intel_vgpu_groups[] = {
NULL,
};
-static struct mdev_parent_ops intel_vgpu_ops = {
- .mdev_attr_groups = intel_vgpu_groups,
- .create = intel_vgpu_create,
- .remove = intel_vgpu_remove,
-
+static const struct vfio_mdev_device_ops
[PATCH V3 7/7] docs: sample driver to demonstrate how to implement virtio-mdev framework
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to make sure HVA is used
directly as the IOVA. This should be sufficient for kernel virtio
driver to work.
Only 'virtio' type is supported right now. I plan to add 'vhost' type
on top which requires some virtual IOMMU implemented in this sample
driver.
Signed-off-by: Jason Wang
---
MAINTAINERS| 1 +
samples/Kconfig| 7 +
samples/vfio-mdev/Makefile | 1 +
samples/vfio-mdev/mvnet.c | 691 +
4 files changed, 700 insertions(+)
create mode 100644 samples/vfio-mdev/mvnet.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 3d196a023b5e..cb51351cd5c9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17254,6 +17254,7 @@ F: include/linux/virtio*.h
F: include/uapi/linux/virtio_*.h
F: drivers/crypto/virtio/
F: mm/balloon_compaction.c
+F: samples/vfio-mdev/mvnet.c
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin"
diff --git a/samples/Kconfig b/samples/Kconfig
index c8dacb4dda80..a1a1ca2c00b7 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -131,6 +131,13 @@ config SAMPLE_VFIO_MDEV_MDPY
mediated device. It is a simple framebuffer and supports
the region display interface (VFIO_GFX_PLANE_TYPE_REGION).
+config SAMPLE_VIRTIO_MDEV_NET
+tristate "Build virtio mdev net example mediated device sample code --
loadable modules only"
+ depends on VIRTIO_MDEV_DEVICE && VHOST_RING && m
+ help
+ Build a networking sample device for use as a virtio
+ mediated device.
+
config SAMPLE_VFIO_MDEV_MDPY_FB
tristate "Build VFIO mdpy example guest fbdev driver -- loadable module
only"
depends on FB && m
diff --git a/samples/vfio-mdev/Makefile b/samples/vfio-mdev/Makefile
index 10d179c4fdeb..f34af90ed0a0 100644
--- a/samples/vfio-mdev/Makefile
+++ b/samples/vfio-mdev/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_SAMPLE_VFIO_MDEV_MTTY) += mtty.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY) += mdpy.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY_FB) += mdpy-fb.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MBOCHS) += mbochs.o
+obj-$(CONFIG_SAMPLE_VIRTIO_MDEV_NET) += mvnet.o
diff --git a/samples/vfio-mdev/mvnet.c b/samples/vfio-mdev/mvnet.c
new file mode 100644
index ..b218e7075611
--- /dev/null
+++ b/samples/vfio-mdev/mvnet.c
@@ -0,0 +1,691 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Mediated virtual virtio-net device driver.
+ *
+ * Copyright (c) 2019, Red Hat Inc. All rights reserved.
+ * Author: Jason Wang
+ *
+ * Sample driver that creates mdev device that simulates ethernet loopback
+ * device.
+ *
+ * Usage:
+ *
+ * # modprobe virtio_mdev
+ * # modprobe mvnet
+ * # cd /sys/devices/virtual/mvnet/mvnet/mdev_supported_types/mvnet-virtio
+ * # echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > ./create
+ * # cd devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
+ * # ls -d virtio0
+ * virtio0
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define VERSION_STRING "0.1"
+#define DRIVER_AUTHOR "Red Hat Corporation"
+
+#define MVNET_CLASS_NAME "mvnet"
+#define MVNET_NAME "mvnet"
+
+/*
+ * Global Structures
+ */
+
+static struct mvnet_dev {
+ struct class*vd_class;
+ struct idr vd_idr;
+ struct device dev;
+} mvnet_dev;
+
+struct mvnet_virtqueue {
+ struct vringh vring;
+ struct vringh_kiov iov;
+ unsigned short head;
+ bool ready;
+ u64 desc_addr;
+ u64 device_addr;
+ u64 driver_addr;
+ u32 num;
+ void *private;
+ irqreturn_t (*cb)(void *data);
+};
+
+#define MVNET_QUEUE_ALIGN PAGE_SIZE
+#define MVNET_QUEUE_MAX 256
+#define MVNET_DEVICE_ID 0x1
+#define MVNET_VENDOR_ID 0
+
+u64 mvnet_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
+(1ULL << VIRTIO_F_VERSION_1) |
+(1ULL << VIRTIO_F_IOMMU_PLATFORM);
+
+/* State of each mdev device */
+struct mvnet_state {
+ struct mvnet_virtqueue vqs[2];
+ struct work_struct work;
+ spinlock_t lock;
+ struct mdev_device *mdev;
+ struct virtio_net_config config;
+ void *buffer;
+ u32 status;
+ u32 generation;
+ u64 features;
+ struct list_head next;
+};
+
+static struct mutex mdev_list_lock;
+static struct list_head mdev_devices_list;
+
+static void mvnet_queue_ready(struct mvnet_state *mvnet, unsigned int idx)
+{
+ struct mvnet_virtqueue *vq = >vqs[idx];
+ int ret;
+
+ ret = vringh_init_kern(>vring, mvnet_features, MVNET_QUEUE_MAX,
+ false, (struct vring_desc *)vq->desc_addr,
+ (struct vring_avail *)vq->driver_addr,
+
[Bug 110361] [CI][DRMTIP] igt@kms_chamelium@hdmi-cmp-planes-random - fail - Failed assertion: false, Conversion not implemented
https://bugs.freedesktop.org/show_bug.cgi?id=110361 --- Comment #6 from CI Bug Log --- The CI Bug Log issue associated to this bug has been archived. New failures matching the above filters will not be associated to this bug anymore. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Hi Brian,
On 11/10/2019 10:41, Brian Starkey wrote:
> Hi Neil,
>
> On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
>> Hi Ayan,
>>
>> On 10/10/2019 15:26, Ayan Halder wrote:
>>> On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
This adds all the OSD configuration plumbing to support the AFBC decoders
path to display of the OSD1 plane.
The Amlogic GXM and G12A AFBC decoders are integrated very differently.
The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
On the other side, the Amlogic G12A AFBC decoder seems to be an external
IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
feeding the OSD1 VIU pixel input.
This uses a weird "0x100" internal HW physical address on both
sides to transfer the pixels.
For Amlogic GXM, the supported pixel formats are the same as the normal
linear OSD1 mode.
On the other side, Amlogic added support for all AFBC v1.2 formats for
the G12A AFBC integration.
For simplicity, we stick to the already supported formats for now.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 2 +
drivers/gpu/drm/meson/meson_drv.h | 4 +
drivers/gpu/drm/meson/meson_plane.c | 215
3 files changed, 190 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index 57ae1c13d1e6..d478fa232951 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
writel_relaxed(priv->viu.osd1_ctrl_stat,
priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
+ writel_relaxed(priv->viu.osd1_ctrl_stat2,
+ priv->io_base + _REG(VIU_OSD1_CTRL_STAT2));
writel_relaxed(priv->viu.osd1_blk0_cfg[0],
priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W0));
writel_relaxed(priv->viu.osd1_blk0_cfg[1],
diff --git a/drivers/gpu/drm/meson/meson_drv.h
b/drivers/gpu/drm/meson/meson_drv.h
index 60f13c6f34e5..de25349be8aa 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -53,8 +53,12 @@ struct meson_drm {
bool osd1_enabled;
bool osd1_interlace;
bool osd1_commit;
+ bool osd1_afbcd;
uint32_t osd1_ctrl_stat;
+ uint32_t osd1_ctrl_stat2;
uint32_t osd1_blk0_cfg[5];
+ uint32_t osd1_blk1_cfg4;
+ uint32_t osd1_blk2_cfg4;
uint32_t osd1_addr;
uint32_t osd1_stride;
uint32_t osd1_height;
diff --git a/drivers/gpu/drm/meson/meson_plane.c
b/drivers/gpu/drm/meson/meson_plane.c
index 5e798c276037..412941aa8402 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -23,6 +23,7 @@
#include "meson_plane.h"
#include "meson_registers.h"
#include "meson_viu.h"
+#include "meson_osd_afbcd.h"
/* OSD_SCI_WH_M1 */
#define SCI_WH_M1_W(w)FIELD_PREP(GENMASK(28, 16), w)
@@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane
*plane,
false, true);
}
+#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
\
+ AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |\
+ AFBC_FORMAT_MOD_YTR |\
+ AFBC_FORMAT_MOD_SPARSE | \
+ AFBC_FORMAT_MOD_SPLIT)
+
/* Takes a fixed 16.16 number and converts it to integer. */
static inline int64_t fixed16_to_int(int64_t value)
{
return value >> 16;
}
+static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv)
+{
+ u32 line_stride = 0;
+
+ switch (priv->afbcd.format) {
+ case DRM_FORMAT_RGB565:
+ line_stride = ((priv->viu.osd1_width << 4) + 127) >> 7;
+ break;
+ case DRM_FORMAT_RGB888:
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_ABGR:
>>> Please have a look at
>>> https://www.kernel.org/doc/html/latest/gpu/afbc.html for our
>>> recommendation. We suggest that *X* formats are avoided.
>>>
>>> Also, for interoperability and maximum compression efficiency (with
>>> AFBC_FORMAT_MOD_YTR), we
[Bug 107877] deepin-desktop: xdg-email: no method available for opening 'mailto:'
https://bugs.freedesktop.org/show_bug.cgi?id=107877 andrerushell changed: What|Removed |Added URL|https://www.monktech.us/Gma |https://www.monktech.us/ |il-Help-Phone-number.html | --- Comment #34 from andrerushell --- If you are one of those who are confronting with any sort of technical or non technical issues during the course of composing a mail on Gmail, you should take Gmail Help by using our toll free helpline number. Here, you will get the best in class solution to your problems at an affordable cost. https://www.monktech.us/Gmail-Help-Phone-number.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107877] deepin-desktop: xdg-email: no method available for opening 'mailto:'
https://bugs.freedesktop.org/show_bug.cgi?id=107877 andrerushell changed: What|Removed |Added URL||https://www.monktech.us/Gma ||il-Help-Phone-number.html --- Comment #33 from andrerushell --- If you are one of those who are confronting with any sort of technical or non technical issues during the course of composing a mail on Gmail, you should take Gmail Help by using our toll free helpline number. Here, you will get the best in class solution to your problems at an affordable cost. https://www.monktech.us/Gmail-Help-Phone-number.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1
Hi,
On 10-10-2019 18:59, Daniel Vetter wrote:
On Thu, Oct 10, 2019 at 6:28 PM Hans de Goede wrote:
Bail from the pci_driver probe function instead of from the drm_driver
load function.
This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events to
userspace.
Specifically this avoids triggering the (userspace) bug fixed by this
plymouth merge-request:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59
Note that despite that being a userspace bug, not sending unnecessary
udev events is a good idea in general.
I think even better would be getting rid of the load/unload callbacks,
this issue here isn't the only problem with them.
Reviewed-by: Daniel Vetter
Thanks,
I guess also cc: stable material?
Yes.
amdgpu maintainers, can you please add a Cc: stable while merging?
Let me know if you want a new version with this added.
Regards,
Hans
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 35 +
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 35 -
2 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6f8aaf655a9f..2a00a36106b2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1048,6 +1048,41 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
return -ENODEV;
}
+#ifdef CONFIG_DRM_AMDGPU_SI
+ if (!amdgpu_si_support) {
+ switch (flags & AMD_ASIC_MASK) {
+ case CHIP_TAHITI:
+ case CHIP_PITCAIRN:
+ case CHIP_VERDE:
+ case CHIP_OLAND:
+ case CHIP_HAINAN:
+ dev_info(>dev,
+"SI support provided by radeon.\n");
+ dev_info(>dev,
+"Use radeon.si_support=0 amdgpu.si_support=1 to
override.\n"
+ );
+ return -ENODEV;
+ }
+ }
+#endif
+#ifdef CONFIG_DRM_AMDGPU_CIK
+ if (!amdgpu_cik_support) {
+ switch (flags & AMD_ASIC_MASK) {
+ case CHIP_KAVERI:
+ case CHIP_BONAIRE:
+ case CHIP_HAWAII:
+ case CHIP_KABINI:
+ case CHIP_MULLINS:
+ dev_info(>dev,
+"CIK support provided by radeon.\n");
+ dev_info(>dev,
+"Use radeon.cik_support=0 amdgpu.cik_support=1 to
override.\n"
+ );
+ return -ENODEV;
+ }
+ }
+#endif
+
/* Get rid of things like offb */
ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0,
"amdgpudrmfb");
if (ret)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index f2c097983f48..d55f5baa83d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -144,41 +144,6 @@ int amdgpu_driver_load_kms(struct drm_device *dev,
unsigned long flags)
struct amdgpu_device *adev;
int r, acpi_status;
-#ifdef CONFIG_DRM_AMDGPU_SI
- if (!amdgpu_si_support) {
- switch (flags & AMD_ASIC_MASK) {
- case CHIP_TAHITI:
- case CHIP_PITCAIRN:
- case CHIP_VERDE:
- case CHIP_OLAND:
- case CHIP_HAINAN:
- dev_info(dev->dev,
-"SI support provided by radeon.\n");
- dev_info(dev->dev,
-"Use radeon.si_support=0 amdgpu.si_support=1 to
override.\n"
- );
- return -ENODEV;
- }
- }
-#endif
-#ifdef CONFIG_DRM_AMDGPU_CIK
- if (!amdgpu_cik_support) {
- switch (flags & AMD_ASIC_MASK) {
- case CHIP_KAVERI:
- case CHIP_BONAIRE:
- case CHIP_HAWAII:
- case CHIP_KABINI:
- case CHIP_MULLINS:
- dev_info(dev->dev,
-"CIK support provided by radeon.\n");
- dev_info(dev->dev,
-"Use radeon.cik_support=0 amdgpu.cik_support=1 to
override.\n"
- );
- return -ENODEV;
- }
- }
-#endif
-
adev = kzalloc(sizeof(struct amdgpu_device), GFP_KERNEL);
if (adev == NULL) {
return -ENOMEM;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #84 from Shmerl --- Testing this patch now, using Firefox with nodma. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/amdgpu/dm/mst: Report possible_crtcs incorrectly, for now
a little late but: i915 does have this hack (or rather-possible_crtcs with MST in i915 has been broken for a while and got fixed, but had to get reverted because of this issue), it's where this originally came from. On Wed, 2019-10-09 at 17:01 +0200, Daniel Vetter wrote: > On Fri, Sep 27, 2019 at 11:27:41AM -0400, Sean Paul wrote: > > On Thu, Sep 26, 2019 at 06:51:07PM -0400, Lyude Paul wrote: > > > This commit is seperate from the previous one to make it easier to > > > revert in the future. Basically, there's multiple userspace applications > > > that interpret possible_crtcs very wrong: > > > > > > https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277 > > > https://gitlab.gnome.org/GNOME/mutter/issues/759 > > > > > > While work is ongoing to fix these issues in userspace, we need to > > > report ->possible_crtcs incorrectly for now in order to avoid > > > introducing a regression in in userspace. Once these issues get fixed, > > > this commit should be reverted. > > > > > > Signed-off-by: Lyude Paul > > > Cc: Ville Syrjälä > > > --- > > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++ > > > 1 file changed, 11 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > > index b404f1ae6df7..fe8ac801d7a5 100644 > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > > @@ -4807,6 +4807,17 @@ static int amdgpu_dm_crtc_init(struct > > > amdgpu_display_manager *dm, > > > if (!acrtc->mst_encoder) > > > goto fail; > > > > > > + /* > > > + * FIXME: This is a hack to workaround the following issues: > > > + * > > > + * https://gitlab.gnome.org/GNOME/mutter/issues/759 > > > + * https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277 > > > + * > > > + * One these issues are closed, this should be removed > > > > Even when these issues are closed, we'll still be introducing a regression > > if we > > revert this change. Time for actually_possible_crtcs? :) > > > > You also might want to briefly explain the u/s bug in case the links go > > sour. > > > > > + */ > > > + acrtc->mst_encoder->base.possible_crtcs = > > > + amdgpu_dm_get_encoder_crtc_mask(dm->adev); > > > > Why don't we put this hack in amdgpu_dm_dp_create_fake_mst_encoder()? > > If we don't have the same hack for i915 mst I think we shouldn't merge > this ... broken userspace is broken. > -Daniel -- Cheers, Lyude Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #86 from Shmerl --- Looks stable so far, no hangs. I'll continue using it, and will post if it occurs again. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111980] Rebbot and shutdown doesn't work on specific hardware
https://bugs.freedesktop.org/show_bug.cgi?id=111980 --- Comment #2 from lei.p...@gmail.com --- (In reply to Tim Cuthbertson from comment #1) > My system does this, too, since kernel 5.3.5-arch1-1-ARCH on Arch Linux. Can you test it without this commit? Same for me 5.3.5-arch1-1-ARCH introduced the bug. I've used git revert 894c414129a8d9ef1b2de443015e4dde6085f64f to exclude that commit in stable branch (after bisecting) for 5.4-rc2 and it worked fine without it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #22 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 285473 --> https://bugzilla.kernel.org/attachment.cgi?id=285473=edit possible fix uvd6 Nice work. I think the attached patch should fix it. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241
a...@tutanota.com changed:
What|Removed |Added
Attachment #285349|0 |1
is obsolete||
--- Comment #20 from a...@tutanota.com ---
Created attachment 285469
--> https://bugzilla.kernel.org/attachment.cgi?id=285469=edit
Patch to fix the resume failures
(In reply to Alex Deucher from comment #17)
> I'm not sure I understand why the patch helps. You are just changing the
> order of two memory allocations. The order shouldn't matter.
My hypothesis is that the order here is not the root cause of the problem, but
rather affects the likelihood of that manifesting itself.
This is based on the fact that I have seen a resume failure typical for this
bug on linux 5.0 once, but I'm unable to reproduce it with that version.
As commit 533aed278afe apparently makes the failures much more likely to
happen, it provides an opportunity to debug this further by backporting it to
older linux versions.
Doing that for versions down to linux 4.15 exposes the resume failures, but not
on linux 4.14.
A bisection between these two, while backporting 533aed278afe on every step,
lead to commit 2a91f272e34c, which failed to boot and thus had to be skipped,
and:
commit e0128efb08b3d628d767ec8578e77cdd7ecc8f81
Author: James Zhu
Date: Fri Sep 29 16:42:27 2017 -0400
drm/amdgpu: add uvd enc ib test
Generate create/destroy messages to test UVD encode indirect buffer
function.
And enable UVD encode IB test during device initialization.
Signed-off-by: James Zhu
Reviewed-and-Tested-by: Leo Liu
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
This looks like a likely root cause. Indeed, adding 'return 0;' at the
beginning of uvd_v6_0_enc_ring_test_ib makes the problem unreproducible, even
on the latest linux 5.4-rc2.
Comparing with amdgpu_uvd_get_{create,destroy}_msg shows that these use 0 as
dummy GPU pointer, while uvd_v6_0_enc_get_{create,destroy}_msg use a real GPU
memory address.
Changing them to also use 0 as dummy pointer, as is done in the attached patch,
actually fixes the resume failures.
Maybe a similar change should also be made for UVD 7.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #21 from a...@tutanota.com --- Created attachment 285471 --> https://bugzilla.kernel.org/attachment.cgi?id=285471=edit Patch to prevent kernel NULL pointer dereferences By the way, some of the kernel NULL pointer dereferences, that can happen after a resume failure, also happen always on shutdown: RIP: 0010:build_audio_output.isra.0+0x97/0x110 [amdgpu] RIP: 0010:enable_link_dp+0x186/0x300 [amdgpu] Attached patch prevents them. Note that these oopses are difficult to notice on shutdown, because they only leave traces in /sys/fs/pstore, not on the disk, as they happen after unmounting. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #85 from Shmerl --- (In reply to Shmerl from comment #84) > Testing this patch now, using Firefox with nodma. without* nodma. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/msm/dsi: Implement reset correctly
On Fri, Oct 11, 2019 at 06:39:39AM -0700, Jeffrey Hugo wrote:
> On msm8998, vblank timeouts are observed because the DSI controller is not
> reset properly, which ends up stalling the MDP. This is because the reset
> logic is not correct per the hardware documentation.
>
> The documentation states that after asserting reset, software should wait
> some time (no indication of how long), or poll the status register until it
> returns 0 before deasserting reset.
>
> wmb() is insufficient for this purpose since it just ensures ordering, not
> timing between writes. Since asserting and deasserting reset occurs on the
> same register, ordering is already guaranteed by the architecture, making
> the wmb extraneous.
>
> Since we would define a timeout for polling the status register to avoid a
> possible infinite loop, lets just use a static delay of 20 ms, since 16.666
> ms is the time available to process one frame at 60 fps.
>
> Fixes: a689554ba6ed (drm/msm: Initial add DSI connector support)
> Signed-off-by: Jeffrey Hugo
Pushed to drm-misc-fixes for 5.4
Thanks!
Sean
> Reviewed-by: Sean Paul
> ---
>
> v2:
> -make a DEFINE for the delay
>
> drivers/gpu/drm/msm/dsi/dsi_host.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 663ff9f4fac9..9a81705301c6 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -26,6 +26,8 @@
> #include "dsi_cfg.h"
> #include "msm_kms.h"
>
> +#define RESET_DELAY 20
> +
> static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
> {
> u32 ver;
> @@ -986,7 +988,7 @@ static void dsi_sw_reset(struct msm_dsi_host *msm_host)
> wmb(); /* clocks need to be enabled before reset */
>
> dsi_write(msm_host, REG_DSI_RESET, 1);
> - wmb(); /* make sure reset happen */
> + msleep(RESET_DELAY); /* make sure reset happen */
> dsi_write(msm_host, REG_DSI_RESET, 0);
> }
>
> @@ -1396,7 +1398,7 @@ static void dsi_sw_reset_restore(struct msm_dsi_host
> *msm_host)
>
> /* dsi controller can only be reset while clocks are running */
> dsi_write(msm_host, REG_DSI_RESET, 1);
> - wmb(); /* make sure reset happen */
> + msleep(RESET_DELAY);/* make sure reset happen */
> dsi_write(msm_host, REG_DSI_RESET, 0);
> wmb(); /* controller out of reset */
> dsi_write(msm_host, REG_DSI_CTRL, data0);
> --
> 2.17.1
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #23 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 285475 --> https://bugzilla.kernel.org/attachment.cgi?id=285475=edit possible fix uvd7 Same fix for uvd7. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111980] Rebbot and shutdown doesn't work on specific hardware
https://bugs.freedesktop.org/show_bug.cgi?id=111980 --- Comment #1 from Tim Cuthbertson --- My system does this, too, since kernel 5.3.5-arch1-1-ARCH on Arch Linux. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 Matthias Heinz (m...@familie-heinz.name) changed: What|Removed |Added CC||m...@familie-heinz.name --- Comment #12 from Matthias Heinz (m...@familie-heinz.name) --- Hi, I think I have the same bug and opened https://bugzilla.kernel.org/show_bug.cgi?id=204683. At first it looked a bit different, because in newer kernels the error message has changed. But as you can see I did some testing and this seems to go way back. Sadly I couldn't test a 4.18 kernel. Can somebody mark my report as duplicate? Because I think it is. And Would some more debug info help? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/atmel-hlcdc: Use swap() where appropriate
On Thu, Oct 10, 2019 at 03:24:28PM +0200, Boris Brezillon wrote:
> On Thu, 10 Oct 2019 16:11:59 +0300
> Ville Syrjala wrote:
>
> > From: Ville Syrjälä
> >
> > @swap@
> > identifier TEMP;
> > expression A,B;
> > @@
> > - TEMP = A;
> > - A = B;
> > - B = TEMP;
> > + swap(A, B);
> >
> > @@
> > type T;
> > identifier swap.TEMP;
> > @@
> > (
> > - T TEMP;
> > |
> > - T TEMP = {...};
> > )
> > ... when != TEMP
> >
> > Cc: Sam Ravnborg
> > Cc: Boris Brezillon
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Boris Brezillon
Ta. Pushed to drm-misc-next.
>
> > ---
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 5 +
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > index 89f5a756fa37..034f202dfe8f 100644
> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > @@ -601,7 +601,6 @@ static int atmel_hlcdc_plane_atomic_check(struct
> > drm_plane *p,
> > struct drm_framebuffer *fb = state->base.fb;
> > const struct drm_display_mode *mode;
> > struct drm_crtc_state *crtc_state;
> > - unsigned int tmp;
> > int ret;
> > int i;
> >
> > @@ -694,9 +693,7 @@ static int atmel_hlcdc_plane_atomic_check(struct
> > drm_plane *p,
> > * Swap width and size in case of 90 or 270 degrees rotation
> > */
> > if (drm_rotation_90_or_270(state->base.rotation)) {
> > - tmp = state->src_w;
> > - state->src_w = state->src_h;
> > - state->src_h = tmp;
> > + swap(state->src_w, state->src_h);
> > }
> >
> > if (!desc->layout.size &&
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111691] inconsistent cursor movement speed when using AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #17 from Jaap Buurman --- (In reply to takios+fdbugs from comment #16) > I ran into the same issue but after installing linux kernel 5.4rc2 it was > fixed. That's good to hear! Does anyone know whether the fix will be backported to the 5.3 kernel? It's gonna take a while before 5.4 becomes mainline. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/meson: fix max mode_config height/width
On 2019-10-09 03:47, Daniel Vetter wrote:
On Tue, Sep 24, 2019 at 10:28:48AM -0700, Jeykumar Sankaran wrote:
Reviving this thread from the context of the below conversion:
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332881
@baylibre.com/T/#u
On 2018-10-05 01:19, Neil Armstrong wrote:
> On 05/10/2018 09:58, Daniel Vetter wrote:
> > On Fri, Oct 5, 2018 at 9:39 AM Neil Armstrong
> > wrote:
> > >
>
> [...]
>
> > > OK, won't this be enough ?
> > > --- a/include/drm/drm_mode_config.h
> > > +++ b/include/drm/drm_mode_config.h
> > > @@ -333,6 +333,8 @@ struct drm_mode_config_funcs {
> > > * @min_height: minimum fb pixel height on this device
> > > * @max_width: maximum fb pixel width on this device
> > > * @max_height: maximum fb pixel height on this device
> > > + * @max_fb_width: maximum fb buffer width if differs from
max_width
> > > + * @max_fb_height: maximum fb buffer height if differs from
> > > max_height
> > > * @funcs: core driver provided mode setting functions
> > > * @fb_base: base address of the framebuffer
> > > * @poll_enabled: track polling support for this device
> > > @@ -508,6 +510,7 @@ struct drm_mode_config {
> > >
> > > int min_width, min_height;
> > > int max_width, max_height;
> > > + int max_fb_width, max_fb_height;
> > > const struct drm_mode_config_funcs *funcs;
> > > resource_size_t fb_base;
> > >
> > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > @@ -283,14 +283,20 @@ drm_internal_framebuffer_create(struct
> > > drm_device *dev,
> > > return ERR_PTR(-EINVAL);
> > > }
> > >
> > > - if ((config->min_width > r->width) || (r->width >
> > > config->max_width)) {
> > > + if ((config->min_width > r->width) ||
> > > + (!config->max_fb_width && r->width >
> > > config->max_width) ||
> > > + (config->max_fb_width && r->width >
> > > config->max_fb_width)) {
> > > DRM_DEBUG_KMS("bad framebuffer width %d, should
> > > be >= %d && <= %d\n",
> > > - r->width, config->min_width,
> > > config->max_width);
> > > + r->width, config->min_width,
> > > config->max_fb_width ?
> > > + config->max_fb_width :
config->max_width);
> > > return ERR_PTR(-EINVAL);
> > > }
> > > - if ((config->min_height > r->height) || (r->height >
> > > config->max_height)) {
> > > + if ((config->min_height > r->height) ||
> > > + (!config->max_fb_height && r->height >
> > > config->max_height) ||
> > > + (config->max_fb_height && r->height >
> > > config->max_fb_height)) {
> > > DRM_DEBUG_KMS("bad framebuffer height %d, should
> > > be >= %d && <= %d\n",
> > > - r->height, config->min_height,
> > > config->max_height);
> > > + r->height, config->min_height,
> > > config->max_fb_height ?
> > > + config->max_fb_height :
> > > config->max_height);
> > > return ERR_PTR(-EINVAL);
> > > }
> > >
> > > and in the driver :
> > >
> > > + drm->mode_config.max_width = 4096;
> > > + drm->mode_config.max_height = 3840;
> > > + drm->mode_config.max_fb_width = 16384;
> > > + drm->mode_config.max_fb_height = 8192;
> > >
> > > With this I leave the mode filtering intact.
> >
> > Not enough. See
> >
https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#c.drm_connec
tor_helper_funcs
> > and scroll down to mode_valid. You need to filter modes both in the
> > detect paths, and the atomic_check paths.
> >
> > Detect is explicitly filtered out, but atomic_check was only
> > implicitly filtered, through the max fb size checks. Ok, you could
> > light up a mode that's bigger than max fb, but in practice, no
> > userspace ever did that.
Daniel, MSM and few other vendor hardware have upscale blocks where
the
driver can expose fb sizes smaller than
the mode resolution and use h/w upscaling to fill the screen. This
would
optimize the fetch bandwidth.
But with your code we're missing crucial
> > validation now, and userspace could fall over that. What I think we
> > need is to add mode filter against mode_config.max_width/height in
> > drm_atomic_helper_check_modeset(). Probably best to stuff that into
> > the mode_valid() function.
>
Agreed! Since the above patch from Niel is taking care of cases where
max/min fb values
are not set, by checking against the original max/min values, can we
separate out this
core change from the driver level mode_valid changes? If Niel couldn't
find
the time, I can
repost the above change.
Sure, I think Neil wouldn't mind if you take this over and get it ready
for merging. Just need to make sure we're not leaving any validation
gaps
in core/helper code.
-Daniel
I guess you are a bit late for the party!
I did post the patch on the forum. The
Re: [PATCH 7/7] drm/dp-mst: fix warning on unused var
+dri, +Daniel
On Thu, Oct 10, 2019 at 06:09:07PM -0700, Lucas De Marchi wrote:
Fixes: 83fa9842afe7 ("drm/dp-mst: Drop connection_mutex check")
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 9364e4f42975..95e63309 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4184,8 +4184,6 @@ EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct
drm_atomic_state *state,
struct
drm_dp_mst_topology_mgr *mgr)
{
- struct drm_device *dev = mgr->dev;
-
return to_dp_mst_topology_state(drm_atomic_get_private_obj_state(state,
>base));
}
EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dt-bindings: power: Convert Generic Power Domain bindings to json-schema
On Wed, Oct 02, 2019 at 06:06:30PM +0200, Krzysztof Kozlowski wrote:
> Convert Generic Power Domain bindings to DT schema format using
> json-schema. The consumer bindings are split to separate file.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1. Select all nodes for consumers,
> 2. Remove from consumers duplicated properties with dt-schema,
> 3. Fix power domain pattern,
> 4. Remove unneeded types.
> ---
> .../devicetree/bindings/arm/arm,scmi.txt | 2 +-
> .../devicetree/bindings/arm/arm,scpi.txt | 2 +-
> .../bindings/arm/freescale/fsl,scu.txt| 2 +-
> .../bindings/clock/clk-exynos-audss.txt | 2 +-
> .../bindings/clock/exynos5433-clock.txt | 4 +-
> .../bindings/clock/renesas,cpg-mssr.txt | 2 +-
> .../clock/renesas,r8a7778-cpg-clocks.txt | 2 +-
> .../clock/renesas,r8a7779-cpg-clocks.txt | 2 +-
> .../clock/renesas,rcar-gen2-cpg-clocks.txt| 2 +-
> .../bindings/clock/renesas,rz-cpg-clocks.txt | 2 +-
> .../bindings/clock/ti/davinci/psc.txt | 2 +-
> .../bindings/display/etnaviv/etnaviv-drm.txt | 2 +-
> .../devicetree/bindings/display/msm/dpu.txt | 2 +-
> .../devicetree/bindings/display/msm/mdp5.txt | 2 +-
> .../devicetree/bindings/dsp/fsl,dsp.yaml | 2 +-
> .../firmware/nvidia,tegra186-bpmp.txt | 2 +-
> .../bindings/media/imx7-mipi-csi2.txt | 3 +-
> .../bindings/media/mediatek-jpeg-decoder.txt | 3 +-
> .../bindings/media/mediatek-mdp.txt | 3 +-
> .../bindings/opp/qcom-nvmem-cpufreq.txt | 2 +-
> .../devicetree/bindings/pci/pci-keystone.txt | 2 +-
> .../bindings/phy/ti,phy-am654-serdes.txt | 2 +-
> .../bindings/power/amlogic,meson-gx-pwrc.txt | 2 +-
> .../devicetree/bindings/power/fsl,imx-gpc.txt | 2 +-
> .../bindings/power/fsl,imx-gpcv2.txt | 2 +-
> .../power/power-domain-consumers.yaml | 105 +
> .../bindings/power/power-domain.yaml | 134
> .../bindings/power/power_domain.txt | 205 --
> .../devicetree/bindings/power/qcom,rpmpd.txt | 2 +-
> .../bindings/power/renesas,rcar-sysc.txt | 2 +-
> .../bindings/power/renesas,sysc-rmobile.txt | 2 +-
> .../bindings/power/xlnx,zynqmp-genpd.txt | 2 +-
> .../bindings/soc/bcm/brcm,bcm2835-pm.txt | 2 +-
> .../bindings/soc/mediatek/scpsys.txt | 2 +-
> .../bindings/soc/ti/sci-pm-domain.txt | 2 +-
> .../bindings/usb/nvidia,tegra124-xusb.txt | 4 +-
> MAINTAINERS | 2 +-
> 37 files changed, 278 insertions(+), 241 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/power/power-domain-consumers.yaml
> create mode 100644 Documentation/devicetree/bindings/power/power-domain.yaml
> delete mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
> diff --git
> a/Documentation/devicetree/bindings/power/power-domain-consumers.yaml
> b/Documentation/devicetree/bindings/power/power-domain-consumers.yaml
> new file mode 100644
> index ..f65078e1260e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/power-domain-consumers.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/power-domain-consumers.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PM domain consumers
> +
> +maintainers:
> + - Rafael J. Wysocki
> + - Kevin Hilman
> + - Ulf Hansson
> +
> +description: |+
> + See power-domain.yaml
> +
> +select: true
> +
> +allOf:
> + - $ref: /schemas/power-domain/power-domain-consumer.yaml
I don't like this split. We should move the contents of this file to the
above file.
I checked the authorship of the relevant lines and they are all except
for a small number of lines from Linaro authors (Viresh and Ulf). I have
permission from Linaro to dual license Linaro authored bindings, so it's
not a problem to move this. I can do that and you can just drop this file.
> +
> +properties:
> + required-opps:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> + This contains phandle to an OPP node in another device's OPP table.
> + It may contain an array of phandles, where each phandle points to an
> OPP
> + of a different device. It should not contain multiple phandles to the
> OPP
> + nodes in the same OPP table. This specifies the minimum required OPP
> + of the device(s), whose OPP's phandle is present in this property,
> + for the functioning of the current device at the current OPP (where
> this
> + property is present).
> +
> +examples:
> + - |
> +leaky-device@1235 {
> + compatible = "foo,i-leak-current";
> + reg = <0x1235 0x1000>;
> + power-domains = < 0>;
> + power-domain-names = "io";
> +};
> +
> +leaky-device@12351000 {
> +
[Bug 111980] Rebbot and shutdown doesn't work on specific hardware
https://bugs.freedesktop.org/show_bug.cgi?id=111980 Bug ID: 111980 Summary: Rebbot and shutdown doesn't work on specific hardware Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: not set Priority: not set Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: lei.p...@gmail.com When system shutdown/reboot is initiated, everything works as it should, journal doesn't show any error and it reaches target reboot (for example), display shuts down properly, but PC stays powered on (requiring hard reset) indefinitely. This happened after kernel upgrade, after bisectiing, commit that was to blame was bellow, after removing just that specific commit, it would work as expected: 894c414129a8d9ef1b2de443015e4dde6085f64f is the first bad commit commit 894c414129a8d9ef1b2de443015e4dde6085f64f Author: KyleMahlkuch Date: Wed Jul 31 17:10:14 2019 -0500 drm/radeon: Fix EEH during kexec [ Upstream commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6 ] During kexec some adapters hit an EEH since they are not properly shut down in the radeon_pci_shutdown() function. Adding radeon_suspend_kms() fixes this issue. Signed-off-by: KyleMahlkuch Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin drivers/gpu/drm/radeon/radeon_drv.c | 8 1 file changed, 8 insertions(+) Issue is described here, seems like others have similar issue that might be connected with this as well: https://bbs.archlinux.org/viewtopic.php?id=249787 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource
Hello, Daniel. On Wed, Oct 09, 2019 at 06:06:52PM +0200, Daniel Vetter wrote: > That's not the point I was making. For cpu cgroups there's a very well > defined connection between the cpu bitmasks/numbers in cgroups and the cpu > bitmasks you use in various system calls (they match). And that stuff > works across vendors. Please note that there are a lot of limitations even to cpuset. Affinity is easy to implement and seems attractive in terms of absolute isolation but it's inherently cumbersome and limited in granularity and can lead to surprising failure modes where contention on one cpu can't be resolved by the load balancer and leads to system wide slowdowns / stalls caused by the dependency chain anchored at the affinity limited tasks. Maybe this is a less of a problem for gpu workloads but in general the more constraints are put on scheduling, the more likely is the system to develop twisted dependency chains while other parts of the system are sitting idle. How does scheduling currently work when there are competing gpu workloads? There gotta be some fairness provision whether that's unit allocation based or time slicing, right? If that's the case, it might be best to implement proportional control on top of that. Work-conserving mechanisms are the most versatile, easiest to use and least likely to cause regressions. Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111691] inconsistent cursor movement speed when using AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #16 from takios+fdb...@takios.de --- I ran into the same issue but after installing linux kernel 5.4rc2 it was fixed. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/ioctl: Add a ioctl to label GEM objects
Hi Am 11.10.19 um 19:09 schrieb Daniel Stone: Hi Rohan, On Fri, 11 Oct 2019 at 15:30, Rohan Garg wrote: DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it easier to debug issues in userspace applications. I'm not sure if this was pointed out already, but dumb buffers != GEM buffers. GEM buffers _can_ be dumb, but might not be. Could you please rename to GEM_SET_LABEL? This change to build upon dumb buffers was suggested by me, as dumb buffers is the closes thing there is to a buffer management interface. Drivers with 'smart buffers' would have to add their own ioctl interfaces. What I really miss here is a userspace application that uses this functionality. It would be much easier to discuss if there was an actual example. Best regards Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.4-rc3
The pull request you sent on Fri, 11 Oct 2019 14:36:03 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-10-11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9892f9f6cf83e8ecaacc5ec7847cf5ba033119d2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 0/3] drm/amd/display/dc/dce: remove some not used variables
Thanks for the patches. I think for all of them we should just drop the REG_READ calls completely. They look like leftovers from when we had a different register update scheme that would read the register, then update or get the field value. Now we just use the REG_ macros that will combine the read with the GET or UPDATE operations. Harry On 2019-10-09 2:25 a.m., zhengbin wrote: > zhengbin (3): > drm/amd/display: Remove set but not used variables > 'bl_pwm_cntl','pwm_period_cntl' > drm/amd/display: Remove set but not used variable 'value0' > drm/amd/display: Remove set but not used variables 'regval','speakers' > > drivers/gpu/drm/amd/display/dc/dce/dce_abm.c| 8 > drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c | 3 +-- > drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c | 5 + > 3 files changed, 6 insertions(+), 10 deletions(-) > > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 7/7] drm/omap: hdmi4: fix use of uninitialized var
* Tomi Valkeinen [191011 10:25]: > On 10/10/2019 16:24, Tony Lindgren wrote: > > > Hmm so what register does this clock actually change? > > > > I'm seeing an increase of few tens of extra mW, which means at > > least one day of standby time less for me :) It does not happen > > always, maybe half of the time. > > I have no idea why this would affect power consumption. As far as I can > understand, the bits written here are a clk divider MCLK. I don't see why > that would affect. Yeah you're right, and I just got lucky initially. I have seen the power consumption stay higher already with the patch applied. The clocks seem just fine. > Maybe Jyri or Peter has an idea, I have never looked at the HDMI audio side. I'll try dumping out the hdmi registers before and after when I get a chance. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel crash on 4.19.77-1-lts (Arch Linux / ThinkPad T470p)
> Just use Cc. We want all replies to go to the list(s) as well. Sorry, I wasn't sure and wanted to err on the side of not spamming the wrong people. > Oct 10 12:53:30 scorpion kernel: RIP: 0010:dma_fence_signal_locked+0x30/0xe0 > > Looks like it could be > https://bugs.freedesktop.org/show_bug.cgi?id=111381 > > in which case you just need to upgrade to 4.19.78 and it should be > fixed. Thanks a bunch, not sure how I missed there was a new LTS kernel out. I have upgraded and will report back if I continue to see the issue. Thanks for the quick support, John On Fri, Oct 11, 2019 at 6:12 AM Ville Syrjälä wrote: > On Thu, Oct 10, 2019 at 01:15:09PM -0400, John Maguire wrote: > > Hi there, > > > > I wasn't sure which mailing list to use so I BCC'd > > intel-...@lists.freedesktop.org and dri-devel@lists.freedesktop.org > > Just use Cc. We want all replies to go to the list(s) as well. > > > > > I'm using a Lenovo Thinkpad T470p and running the 4.19.77-1-lts kernel on > > Arch Linux. Recently, I've started getting freezes each day. Audio can > > still be heard, but video output stops. I was able to retrieve a call > trace > > from journald. > > > > I've attached the output of "sudo lspci -vvv" as well as the message from > > journald (null pointer dereference). > > Oct 10 12:53:30 scorpion kernel: RIP: > 0010:dma_fence_signal_locked+0x30/0xe0 > > > Looks like it could be > https://bugs.freedesktop.org/show_bug.cgi?id=111381 > > in which case you just need to upgrade to 4.19.78 and it should be > fixed. > > -- > Ville Syrjälä > Intel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] drm/ioctl: Add a ioctl to label GEM objects
DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it
easier to debug issues in userspace applications.
Changes in v2:
- Hoist the IOCTL up into the drm_driver framework
Changes in v3:
- Introduce a drm_gem_set_label for drivers to use internally
in order to label a GEM object
- Hoist string copying up into the IOCTL
- Fix documentation
- Move actual gem labeling into drm_gem_adopt_label
Changes in v4:
- Refactor IOCTL call to only perform string duplication and move
all gem lookup logic into GEM specific call
Signed-off-by: Rohan Garg
---
drivers/gpu/drm/drm_gem.c | 70 ++
drivers/gpu/drm/drm_internal.h | 8
drivers/gpu/drm/drm_ioctl.c| 1 +
include/drm/drm_drv.h | 16
include/drm/drm_gem.h | 7
include/uapi/drm/drm.h | 20 ++
6 files changed, 122 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 6854f5867d51..0fa4609b2817 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -941,6 +941,71 @@ drm_gem_release(struct drm_device *dev, struct drm_file
*file_private)
idr_destroy(_private->object_idr);
}
+int drm_dumb_set_label_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ char *label;
+ struct drm_dumb_set_label_object *args = data;
+ int ret = 0;
+
+ if (!args->len || !args->name)
+ return -EINVAL;
+
+ if (!dev->driver->label)
+ return -EOPNOTSUPP;
+
+ label = strndup_user(u64_to_user_ptr(args->name), args->len);
+
+ if (IS_ERR(label)) {
+ ret = PTR_ERR(label);
+ goto err;
+ }
+
+ ret = dev->driver->label(dev, file_priv, args->handle, label);
+
+err:
+ kfree(label);
+ return ret;
+}
+
+int drm_gem_set_label(struct drm_device *dev,
+ struct drm_file *file_priv,
+ uint32_t handle,
+ const char *label)
+{
+ struct drm_gem_object *gem_obj;
+ int ret = 0;
+
+ gem_obj = drm_gem_object_lookup(file_priv, handle);
+ if (!gem_obj) {
+ DRM_DEBUG("Failed to look up GEM BO %d\n", handle);
+ ret = -ENOENT;
+ goto err;
+ }
+ drm_gem_adopt_label(gem_obj, label);
+
+err:
+ drm_gem_object_put_unlocked(gem_obj);
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_set_label);
+
+void drm_gem_adopt_label(struct drm_gem_object *gem_obj, const char *label)
+{
+ char *adopted_label = NULL;
+
+ if (label)
+ adopted_label = kstrdup(label, GFP_KERNEL);
+
+ if (gem_obj->label) {
+ kfree(gem_obj->label);
+ gem_obj->label = NULL;
+ }
+
+ gem_obj->label = adopted_label;
+}
+EXPORT_SYMBOL(drm_gem_adopt_label);
+
/**
* drm_gem_object_release - release GEM buffer object resources
* @obj: GEM buffer object
@@ -958,6 +1023,11 @@ drm_gem_object_release(struct drm_gem_object *obj)
dma_resv_fini(>_resv);
drm_gem_free_mmap_offset(obj);
+
+ if (obj->label) {
+ kfree(obj->label);
+ obj->label = NULL;
+ }
}
EXPORT_SYMBOL(drm_gem_object_release);
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 51a2055c8f18..cbc3f7b7fb9b 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -137,6 +137,14 @@ int drm_gem_pin(struct drm_gem_object *obj);
void drm_gem_unpin(struct drm_gem_object *obj);
void *drm_gem_vmap(struct drm_gem_object *obj);
void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
+int drm_dumb_set_label_ioctl(struct drm_device *dev,
+ void *data,
+ struct drm_file *file_priv);
+int drm_gem_set_label(struct drm_device *dev,
+ struct drm_file *file_priv,
+ uint32_t handle,
+ const char *label);
+void drm_gem_adopt_label(struct drm_gem_object *gem_obj, const char *label);
/* drm_debugfs.c drm_debugfs_crc.c */
#if defined(CONFIG_DEBUG_FS)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index fcd728d7cf72..f34e1571d70f 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -714,6 +714,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessees_ioctl,
DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl,
DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_REVOKE_LEASE, drm_mode_revoke_lease_ioctl,
DRM_MASTER),
+ DRM_IOCTL_DEF(DRM_IOCTL_DUMB_SET_LABEL, drm_dumb_set_label_ioctl,
DRM_RENDER_ALLOW),
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index cf13470810a5..501a3924354a 100644
Re: [PATCH v4] drm/ioctl: Add a ioctl to label GEM objects
Hi Rohan, On Fri, 11 Oct 2019 at 15:30, Rohan Garg wrote: > DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it > easier to debug issues in userspace applications. I'm not sure if this was pointed out already, but dumb buffers != GEM buffers. GEM buffers _can_ be dumb, but might not be. Could you please rename to GEM_SET_LABEL? Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
On Fri, Oct 11, 2019 at 12:56 PM Brian Starkey wrote: > > Hi, > > On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote: > > Hi Brian, > > > > On 11/10/2019 10:41, Brian Starkey wrote: > > > Are you sure the GPU supports other orders? I think any Arm driver > > > will only be producing DRM_FORMATs with "BGR" order e.g. ABGR888> > > > I'm not convinced the GPU HW actually supports any other order, but > > > it's all rather confusing with texture swizzling. What I can tell you > > > for sure is that it _does_ support BGR order (in DRM naming > > > convention). > > > > Well, since the Bifrost Mali blobs are closed-source and delivered > > by licensees, it's hard to define what is supported from a closed > > GPU HW, closed SW implementation to a closed pixel format implementation. > > > > I hear you. IMO the only way to make any of this clear is to publish > reference data and tests which make sure implementations match each > other. It's something I'm trying to make happen. *cough* igt test with crc/writeback validation *cough* And you don't even need anything that actually compresses. All you need is the minimal enough AFBC knowledge to set up the metadata that everything is uncompressed. We're doing that for our intel compression formats already, and it works great in making sure that we have end-to-end agreement on all the bits and ordering and everything. Ofc it doesn't validate the decoder, but that's not really igts job. Should be possible to convince ARM to release that (as open source, in igt), since it would be fairly valuable for the entire ecosystem here ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] dt-bindings: display: imx: add bindings for DCSS
:u?wc??m5?^?㞾?}4-??z{b???r?+?׀u???ا#????ek
?W?J^?(???h}??-??z{b???r?Z+?jW.?\?oۊwb?
?v+)l?b? &??,?&??ξW???!jx w?ǫ?*'??+y?^??^?M:???r鞞֭???u??q?ky?ۊwb?
?v+)l?b? &??,?&????? uޮ?G???h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204683] amdgpu: ring sdma0 timeout
https://bugzilla.kernel.org/show_bug.cgi?id=204683 --- Comment #12 from Matthias Heinz (m...@familie-heinz.name) --- My last update, because I have no way to go forward from here on. This bug seems to go way back longer than I initially thought. I'm currently at "drm-fixes-2018-08-31" in linux-drm and it's already in there, so it's probably pretty old. I can't use any older kernel, because I need steam to run the games to test this. But steam wont work with anything older than 4.19. BUT I found a game that almost instantly triggers this bug on startup: Insurgency. Just start it and if that doesn't trigger it immediately, quit the game and start it again. It can take two to three times, joining a match helps, too, but it takes less than 5 minutes for each test. So, please go ahead and fix this already, it's annoying. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v7 0/3] CRTC background color
On Wed, Oct 09, 2019 at 02:27:41PM -0700, Matt Roper wrote: > On Wed, Oct 09, 2019 at 05:01:20PM -0400, Daniele Castagna wrote: > > On Wed, Oct 9, 2019 at 1:34 PM Matt Roper wrote: > > > > > > The previous version of this series was posted in February here: > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-February/208068.html > > > > > > Right before we merged this in February Maarten noticed that we should > > > be setting up the initial property state in a CRTC reset function (which > > > didn't exist yet) instead of when the property was attached. Maarten > > > landed the CRTC reset functionality a week or two later, but I was busy > > > with travel and other work at the time, so revisiting and rebasing this > > > background color series fell through the cracks and I'm just getting > > > back to it now. > > > > > > Userspace consumer is chromeos; these are the links the ChromeOS folks > > > gave me back in February: > > > https://chromium-review.googlesource.com/c/chromium/src/+/1278858 > > > > > > https://chromium-review.googlesource.com/c/chromiumos/platform/drm-tests/+/1241436 > > > > Please note that the current state of the background color on Chrome > > OS side is that while the property plumbing landed, the property is > > currently not used by the compositor and no one is working on making > > that happen. > > Hmm, in that case it sounds like we probably don't actually have enough > userspace support yet to justify merging the kernel changes at this > time. I'm not too familiar with Chrome OS' userspace stack; is the rest > of the work to actually make use of ozone stuff in the links above a > heavy lift? Is it something someone is likely to work on that once > they're freed up from other tasks or is there just not enough benefit to > justify the effort of utilizing it at the compositor level right now? > AFAIK, there are no plans for the Chrome team to spend time utilising this feature. If you look at the bug [1], there's no correspondance with CrOS and there is no clear usecase for the feature. The patches are basically just copy/paste of how other properties are surfaced and that's it. A few months later, we get more stub implementations [2]/[3] again with no feedback from the Chrome team on the bugs [4]/[5]. On the first review, Daniele asked if the submitter was going to finish the background work before adding more properties. The answer is that CRTC BG isn't seen on Chrome, so it's not useful on the platform. We should not have landed the crtc-bg stub in the first place, it's just dead code and it's clear from the comments in [2] that it's going to stay that way. So I think the best course of action is to revert this change from Chrome until we have a usecase for the feature which is blessed by the Chrome team and it is implemented fully. Going forward, we're going to keep a closer eye on the HW enablement in Chrome so as to avoid adding dead code to Chrome and to avoid skirting the spirit of the "opensource userspace" rule by just implementing getters/setters. Sean ps: As for the stubs referenced in [2] and [3], that's more of a Chrome matter. There are already other existing userspace implementations for these 2 features, so Chrome is not being used as an upstreaming vehicle for the kernel patches. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=894259 [2] https://polymer2-chromium-review.googlesource.com/c/chromium/src/+/1504300 [3] https://polymer2-chromium-review.googlesource.com/c/chromium/src/+/1572247 [4] https://bugs.chromium.org/p/chromium/issues/detail?id=940683 [5] https://bugs.chromium.org/p/chromium/issues/detail?id=938536 > > Matt > > > The kernel patches have not landed on the ChromeOS kernel either. > > > > > > > > > > > > > IGT is still the same as posted in February: > > > https://lists.freedesktop.org/archives/igt-dev/2019-February/009637.html > > > > > > Cc: Maarten Lankhorst > > > > > > Matt Roper (3): > > > drm: Add CRTC background color property > > > drm/i915/gen9+: Add support for pipe background color > > > drm/i915: Add background color hardware readout and state check > > > > > > drivers/gpu/drm/drm_atomic_state_helper.c| 4 +- > > > drivers/gpu/drm/drm_atomic_uapi.c| 4 ++ > > > drivers/gpu/drm/drm_blend.c | 35 +-- > > > drivers/gpu/drm/drm_mode_config.c| 6 +++ > > > drivers/gpu/drm/i915/display/intel_color.c | 11 +++-- > > > drivers/gpu/drm/i915/display/intel_display.c | 45 > > > drivers/gpu/drm/i915/i915_debugfs.c | 9 > > > include/drm/drm_blend.h | 1 + > > > include/drm/drm_crtc.h | 12 ++ > > > include/drm/drm_mode_config.h| 5 +++ > > > include/uapi/drm/drm_mode.h | 28 > > > 11 files changed, 153 insertions(+), 7 deletions(-) > > > > > > -- > > > 2.21.0 > > > > > >
Re: [PATCH v4] drm/ioctl: Add a ioctl to label GEM objects
Hello Rohan,
On Fri, 11 Oct 2019 16:30:09 +0200
Rohan Garg wrote:
> DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it
> easier to debug issues in userspace applications.
>
> Changes in v2:
> - Hoist the IOCTL up into the drm_driver framework
>
> Changes in v3:
> - Introduce a drm_gem_set_label for drivers to use internally
> in order to label a GEM object
> - Hoist string copying up into the IOCTL
> - Fix documentation
> - Move actual gem labeling into drm_gem_adopt_label
>
> Changes in v4:
> - Refactor IOCTL call to only perform string duplication and move
> all gem lookup logic into GEM specific call
>
> Signed-off-by: Rohan Garg
> ---
> drivers/gpu/drm/drm_gem.c | 70 ++
> drivers/gpu/drm/drm_internal.h | 8
> drivers/gpu/drm/drm_ioctl.c| 1 +
> include/drm/drm_drv.h | 16
> include/drm/drm_gem.h | 7
> include/uapi/drm/drm.h | 20 ++
> 6 files changed, 122 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 6854f5867d51..0fa4609b2817 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -941,6 +941,71 @@ drm_gem_release(struct drm_device *dev, struct drm_file
> *file_private)
> idr_destroy(_private->object_idr);
> }
>
> +int drm_dumb_set_label_ioctl(struct drm_device *dev,
Why dumb? Not sure what a smart set_label_ioctl() function would
do differently :-).
Oh, and if this function can be used to label TTM BOs it should be moved
somewhere else (drm_ioctl.c ?).
> + void *data, struct drm_file *file_priv)
Indentation is broken here.
> +{
> + char *label;
> + struct drm_dumb_set_label_object *args = data;
> + int ret = 0;
> +
> + if (!args->len || !args->name)
Hm, I thought args->len == 0 was a valid case and meant "free the
existing label". Has it changed. The case that's not allowed is
args->len && !args->name.
> + return -EINVAL;
> +
> + if (!dev->driver->label)
> + return -EOPNOTSUPP;
> +
> + label = strndup_user(u64_to_user_ptr(args->name), args->len);
> +
Remove this blank line.
> + if (IS_ERR(label)) {
> + ret = PTR_ERR(label);
> + goto err;
> + }
> +
> + ret = dev->driver->label(dev, file_priv, args->handle, label);
> +
> +err:
I would s/err/out/ as this is not an error-only path.
> + kfree(label);
> + return ret;
> +}
> +
> +int drm_gem_set_label(struct drm_device *dev,
> +struct drm_file *file_priv,
> +uint32_t handle,
> +const char *label)
> +{
> + struct drm_gem_object *gem_obj;
> + int ret = 0;
> +
> + gem_obj = drm_gem_object_lookup(file_priv, handle);
> + if (!gem_obj) {
> + DRM_DEBUG("Failed to look up GEM BO %d\n", handle);
> + ret = -ENOENT;
> + goto err;
> + }
> + drm_gem_adopt_label(gem_obj, label);
> +
> +err:
Ditto: s/err/out/
> + drm_gem_object_put_unlocked(gem_obj);
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_gem_set_label);
> +
> +void drm_gem_adopt_label(struct drm_gem_object *gem_obj, const char *label)
> +{
> + char *adopted_label = NULL;
> +
> + if (label)
> + adopted_label = kstrdup(label, GFP_KERNEL);
Add
WARN_ON(adopted_label);
> +
> + if (gem_obj->label) {
> + kfree(gem_obj->label);
> + gem_obj->label = NULL;
This assignment is useless since gem_obj->label is assigned below.
> + }
> +
> + gem_obj->label = adopted_label;
> +}
> +EXPORT_SYMBOL(drm_gem_adopt_label);
> +
> /**
> * drm_gem_object_release - release GEM buffer object resources
> * @obj: GEM buffer object
> @@ -958,6 +1023,11 @@ drm_gem_object_release(struct drm_gem_object *obj)
>
> dma_resv_fini(>_resv);
> drm_gem_free_mmap_offset(obj);
> +
> + if (obj->label) {
> + kfree(obj->label);
> + obj->label = NULL;
> + }
You can call kfree(obj->label) directly (kfree() checks for NULL vals),
and no need to reset obj->label (obj should be free when the function
returns).
> }
> EXPORT_SYMBOL(drm_gem_object_release);
>
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index 51a2055c8f18..cbc3f7b7fb9b 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -137,6 +137,14 @@ int drm_gem_pin(struct drm_gem_object *obj);
> void drm_gem_unpin(struct drm_gem_object *obj);
> void *drm_gem_vmap(struct drm_gem_object *obj);
> void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
> +int drm_dumb_set_label_ioctl(struct drm_device *dev,
> + void *data,
> + struct drm_file *file_priv);
> +int drm_gem_set_label(struct drm_device *dev,
> + struct drm_file *file_priv,
> +
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #87 from Marko Popovic --- All of the hangs are still present for me, so this patch changed nothing. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111983] quan ly
https://bugs.freedesktop.org/show_bug.cgi?id=111983 Bug ID: 111983 Summary: quan ly Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: General Assignee: dri-devel@lists.freedesktop.org Reporter: mongkhan...@gmail.com quan ly -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111983] quan ly
https://bugs.freedesktop.org/show_bug.cgi?id=111983 Andre Klapper changed: What|Removed |Added Component|General |Two Status|NEW |RESOLVED Group||spam Resolution|--- |INVALID Product|DRI |Spam Version|XOrg git|unspecified --- Comment #1 from Andre Klapper --- Go away and test somewhere else. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 7/8] dt-bindings: display: panel: add AUO auo,b101uan08.3 panel documentation
Add dcumentation for auo,b101uan08.3, which is mipi dsi video panel
and resolution is 1200x1920.
Signed-off-by: Jitao Shi
---
.../display/panel/auo,b101uan08.3.yaml| 67 +++
1 file changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml
b/Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml
new file mode 100644
index ..c0939f8c7274
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/auo,b101uan08.3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AUO B101UAN08.3 DSI Display Panel
+
+maintainers:
+ - Thierry Reding
+ - Sam Ravnborg
+ - Rob Herring
+
+properties:
+ compatible:
+const: auo,b101uan08.3
+
+ reg:
+description: the virtual channel number of a DSI peripheral
+
+ enable-gpios:
+description: a GPIO spec for the enable pin
+
+ pp1800-supply:
+description: core voltage supply
+
+ avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+ avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+ backlight:
+description: phandle of the backlight device attached to the panel
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+ - |
+ {
+panel@0 {
+compatible = "auo,b101uan08.3";
+reg = <0>;
+enable-gpios = < 45 0>;
+avdd-supply = <_lcd>;
+avee-supply = <_lcd>;
+pp1800-supply = <_lcd>;
+backlight = <_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.21.0
[PATCH v7 8/8] drm/panel: support for auo,b101uan08.3 wuxga dsi video mode panel
Auo,auo,b101uan08.3's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So auo,b101uan08.3 and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.
Signed-off-by: Jitao Shi
---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 78 +++
1 file changed, 78 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 7b47619675f5..e2496a334ab6 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -382,6 +382,53 @@ static const struct panel_init_cmd
auo_kd101n80_45na_init_cmd[] = {
{},
};
+static const struct panel_init_cmd auo_b101uan08_3_init_cmd[] = {
+ _INIT_DELAY_CMD(24),
+ _INIT_DCS_CMD(0xB0, 0x01),
+ _INIT_DCS_CMD(0xC0, 0x48),
+ _INIT_DCS_CMD(0xC1, 0x48),
+ _INIT_DCS_CMD(0xC2, 0x47),
+ _INIT_DCS_CMD(0xC3, 0x47),
+ _INIT_DCS_CMD(0xC4, 0x46),
+ _INIT_DCS_CMD(0xC5, 0x46),
+ _INIT_DCS_CMD(0xC6, 0x45),
+ _INIT_DCS_CMD(0xC7, 0x45),
+ _INIT_DCS_CMD(0xC8, 0x64),
+ _INIT_DCS_CMD(0xC9, 0x64),
+ _INIT_DCS_CMD(0xCA, 0x4F),
+ _INIT_DCS_CMD(0xCB, 0x4F),
+ _INIT_DCS_CMD(0xCC, 0x40),
+ _INIT_DCS_CMD(0xCD, 0x40),
+ _INIT_DCS_CMD(0xCE, 0x66),
+ _INIT_DCS_CMD(0xCF, 0x66),
+ _INIT_DCS_CMD(0xD0, 0x4F),
+ _INIT_DCS_CMD(0xD1, 0x4F),
+ _INIT_DCS_CMD(0xD2, 0x41),
+ _INIT_DCS_CMD(0xD3, 0x41),
+ _INIT_DCS_CMD(0xD4, 0x48),
+ _INIT_DCS_CMD(0xD5, 0x48),
+ _INIT_DCS_CMD(0xD6, 0x47),
+ _INIT_DCS_CMD(0xD7, 0x47),
+ _INIT_DCS_CMD(0xD8, 0x46),
+ _INIT_DCS_CMD(0xD9, 0x46),
+ _INIT_DCS_CMD(0xDA, 0x45),
+ _INIT_DCS_CMD(0xDB, 0x45),
+ _INIT_DCS_CMD(0xDC, 0x64),
+ _INIT_DCS_CMD(0xDD, 0x64),
+ _INIT_DCS_CMD(0xDE, 0x4F),
+ _INIT_DCS_CMD(0xDF, 0x4F),
+ _INIT_DCS_CMD(0xE0, 0x40),
+ _INIT_DCS_CMD(0xE1, 0x40),
+ _INIT_DCS_CMD(0xE2, 0x66),
+ _INIT_DCS_CMD(0xE3, 0x66),
+ _INIT_DCS_CMD(0xE4, 0x4F),
+ _INIT_DCS_CMD(0xE5, 0x4F),
+ _INIT_DCS_CMD(0xE6, 0x41),
+ _INIT_DCS_CMD(0xE7, 0x41),
+ _INIT_DELAY_CMD(150),
+ {},
+};
+
static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
{
return container_of(panel, struct boe_panel, base);
@@ -652,6 +699,34 @@ static const struct panel_desc boe_tv101wum_n53_desc = {
.init_cmds = boe_init_cmd,
};
+static const struct drm_display_mode auo_b101uan08_3_default_mode = {
+ .clock = 159667,
+ .hdisplay = 1200,
+ .hsync_start = 1200 + 60,
+ .hsync_end = 1200 + 60 + 4,
+ .htotal = 1200 + 60 + 4 + 80,
+ .vdisplay = 1920,
+ .vsync_start = 1920 + 34,
+ .vsync_end = 1920 + 34 + 2,
+ .vtotal = 1920 + 34 + 2 + 24,
+ .vrefresh = 60,
+ .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct panel_desc auo_b101uan08_3_desc = {
+ .modes = _b101uan08_3_default_mode,
+ .bpc = 8,
+ .size = {
+ .width_mm = 135,
+ .height_mm = 216,
+ },
+ .lanes = 4,
+ .format = MIPI_DSI_FMT_RGB888,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+ .init_cmds = auo_b101uan08_3_init_cmd,
+};
+
static int boe_panel_get_modes(struct drm_panel *panel)
{
struct boe_panel *boe = to_boe_panel(panel);
@@ -782,6 +857,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "boe,tv101wum-n53",
.data = _tv101wum_n53_desc
},
+ { .compatible = "auo,b101uan08.3",
+ .data = _b101uan08_3_desc
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, boe_of_match);
--
2.21.0
[PATCH v7 0/8] add driver for "boe, tv101wum-nl6", "boe, tv101wum-n53", "auo, kd101n80-45na" and "auo, b101uan08.3" panels
Changes since v6: - fix boe_panel_init err uninit. - adjust the delay of backlight on. Changes since v5: - covert the documents to yaml - fine tune boe, tv101wum-n53 panel video timine Changes since v4: - add auo,b101uan08.3 panel for this driver. - add boe,tv101wum-n53 panel for this driver. Changes since v3: - remove check enable_gpio. - fine tune the auo,kd101n80-45na panel's power on timing. Changes since v2: - correct the panel size - remove blank line in Kconfig - move auo,kd101n80-45na panel driver in this series. Changes since v1: - update typo nl6 -> n16. - update new panel config and makefile are added in alphabetically order. - add the panel mode and panel info in driver data. - merge auo,kd101n80-45a and boe,tv101wum-nl6 in one driver Jitao Shi (8): dt-bindings: display: panel: Add BOE tv101wum-n16 panel bindings drm/panel: support for BOE tv101wum-nl6 wuxga dsi video mode panel dt-bindings: display: panel: add auo kd101n80-45na panel bindings drm/panel: support for auo,kd101n80-45na wuxga dsi video mode panel dt-bindings: display: panel: add boe tv101wum-n53 panel documentation drm/panel: support for boe,tv101wum-n53 wuxga dsi video mode panel dt-bindings: display: panel: add AUO auo,b101uan08.3 panel documentation drm/panel: support for auo,b101uan08.3 wuxga dsi video mode panel .../display/panel/auo,b101uan08.3.yaml| 67 ++ .../display/panel/auo,kd101n80-45na.yaml | 67 ++ .../display/panel/boe,tv101wum-n53.yaml | 67 ++ .../display/panel/boe,tv101wum-nl6.yaml | 67 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 880 ++ 7 files changed, 1158 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml create mode 100644 Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml create mode 100644 Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml create mode 100644 Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/8] drm/panel: support for BOE tv101wum-nl6 wuxga dsi video mode panel
Add driver for BOE tv101wum-nl6 panel is a 10.1" 1200x1920 panel.
Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 713 ++
3 files changed, 723 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d9d931aa6e26..afcadb3585fb 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,15 @@ config DRM_PANEL_ARM_VERSATILE
reference designs. The panel is detected using special registers
in the Versatile family syscon registers.
+config DRM_PANEL_BOE_TV101WUM_NL6
+ tristate "BOE TV101WUM 1200x1920 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
+ DSI Video Mode panel
+
config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index fb0cb3aaa9e6..bd26b6ac039e 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
+obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
new file mode 100644
index ..af68236ea0e8
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -0,0 +1,713 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Jitao Shi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+struct panel_desc {
+ const struct drm_display_mode *modes;
+ unsigned int bpc;
+
+ /**
+* @width_mm: width of the panel's active display area
+* @height_mm: height of the panel's active display area
+*/
+ struct {
+ unsigned int width_mm;
+ unsigned int height_mm;
+ } size;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ const struct panel_init_cmd *init_cmds;
+ unsigned int lanes;
+};
+
+struct boe_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *dsi;
+
+ const struct panel_desc *desc;
+
+ struct backlight_device *backlight;
+ struct regulator *pp1800;
+ struct regulator *avee;
+ struct regulator *avdd;
+ struct gpio_desc *enable_gpio;
+
+ bool prepared;
+ bool enabled;
+
+ const struct drm_display_mode *mode;
+};
+
+enum dsi_cmd_type {
+ INIT_DCS_CMD,
+ DELAY_CMD,
+};
+
+struct panel_init_cmd {
+ enum dsi_cmd_type type;
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_DCS_CMD(...) { \
+ .type = INIT_DCS_CMD, \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+#define _INIT_DELAY_CMD(...) { \
+ .type = DELAY_CMD,\
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const struct panel_init_cmd boe_init_cmd[] = {
+ _INIT_DELAY_CMD(24),
+ _INIT_DCS_CMD(0xB0, 0x05),
+ _INIT_DCS_CMD(0xB1, 0xE5),
+ _INIT_DCS_CMD(0xB3, 0x52),
+ _INIT_DCS_CMD(0xB0, 0x00),
+ _INIT_DCS_CMD(0xB3, 0x88),
+ _INIT_DCS_CMD(0xB0, 0x04),
+ _INIT_DCS_CMD(0xB8, 0x00),
+ _INIT_DCS_CMD(0xB0, 0x00),
+ _INIT_DCS_CMD(0xB6, 0x03),
+ _INIT_DCS_CMD(0xBA, 0x8B),
+ _INIT_DCS_CMD(0xBF, 0x1A),
+ _INIT_DCS_CMD(0xC0, 0x0F),
+ _INIT_DCS_CMD(0xC2, 0x0C),
+ _INIT_DCS_CMD(0xC3, 0x02),
+ _INIT_DCS_CMD(0xC4, 0x0C),
+ _INIT_DCS_CMD(0xC5, 0x02),
+ _INIT_DCS_CMD(0xB0, 0x01),
+ _INIT_DCS_CMD(0xE0, 0x26),
+ _INIT_DCS_CMD(0xE1, 0x26),
+ _INIT_DCS_CMD(0xDC, 0x00),
+ _INIT_DCS_CMD(0xDD, 0x00),
+ _INIT_DCS_CMD(0xCC, 0x26),
+ _INIT_DCS_CMD(0xCD, 0x26),
+ _INIT_DCS_CMD(0xC8, 0x00),
+ _INIT_DCS_CMD(0xC9, 0x00),
+ _INIT_DCS_CMD(0xD2, 0x03),
+ _INIT_DCS_CMD(0xD3, 0x03),
+ _INIT_DCS_CMD(0xE6, 0x04),
+ _INIT_DCS_CMD(0xE7, 0x04),
+ _INIT_DCS_CMD(0xC4, 0x09),
+ _INIT_DCS_CMD(0xC5, 0x09),
+ _INIT_DCS_CMD(0xD8, 0x0A),
+ _INIT_DCS_CMD(0xD9, 0x0A),
+ _INIT_DCS_CMD(0xC2, 0x0B),
+ _INIT_DCS_CMD(0xC3, 0x0B),
+ _INIT_DCS_CMD(0xD6, 0x0C),
+ _INIT_DCS_CMD(0xD7,
[PATCH v7 6/8] drm/panel: support for boe,tv101wum-n53 wuxga dsi video mode panel
Boe,tv101wum-n53's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So boe,tv101wum-n53 and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.
Signed-off-by: Jitao Shi
---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index e6457f87bc61..7b47619675f5 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -624,6 +624,34 @@ static const struct panel_desc auo_kd101n80_45na_desc = {
.discharge_on_disable = true,
};
+static const struct drm_display_mode boe_tv101wum_n53_default_mode = {
+ .clock = 159833,
+ .hdisplay = 1200,
+ .hsync_start = 1200 + 114,
+ .hsync_end = 1200 + 114 + 10,
+ .htotal = 1200 + 114 + 10 + 40,
+ .vdisplay = 1920,
+ .vsync_start = 1920 + 19,
+ .vsync_end = 1920 + 19 + 4,
+ .vtotal = 1920 + 19 + 4 + 10,
+ .vrefresh = 60,
+ .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct panel_desc boe_tv101wum_n53_desc = {
+ .modes = _tv101wum_n53_default_mode,
+ .bpc = 8,
+ .size = {
+ .width_mm = 135,
+ .height_mm = 216,
+ },
+ .lanes = 4,
+ .format = MIPI_DSI_FMT_RGB888,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+ .init_cmds = boe_init_cmd,
+};
+
static int boe_panel_get_modes(struct drm_panel *panel)
{
struct boe_panel *boe = to_boe_panel(panel);
@@ -751,6 +779,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "auo,kd101n80-45na",
.data = _kd101n80_45na_desc
},
+ { .compatible = "boe,tv101wum-n53",
+ .data = _tv101wum_n53_desc
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, boe_of_match);
--
2.21.0
[PATCH v7 4/8] drm/panel: support for auo, kd101n80-45na wuxga dsi video mode panel
Auo,kd101n80-45na's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So auo,kd101n80-45na and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/panel/Kconfig | 6 +-
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 86 ---
2 files changed, 75 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index afcadb3585fb..0e887c978796 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -19,13 +19,13 @@ config DRM_PANEL_ARM_VERSATILE
in the Versatile family syscon registers.
config DRM_PANEL_BOE_TV101WUM_NL6
- tristate "BOE TV101WUM 1200x1920 panel"
+ tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
help
- Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
- DSI Video Mode panel
+ Say Y here if you want to support for BOE TV101WUM and AUO KD101N80
+ 45NA WUXGA PANEL DSI Video Mode panel
config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index af68236ea0e8..e6457f87bc61 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -35,6 +35,7 @@ struct panel_desc {
enum mipi_dsi_pixel_format format;
const struct panel_init_cmd *init_cmds;
unsigned int lanes;
+ bool discharge_on_disable;
};
struct boe_panel {
@@ -372,6 +373,15 @@ static const struct panel_init_cmd boe_init_cmd[] = {
{},
};
+static const struct panel_init_cmd auo_kd101n80_45na_init_cmd[] = {
+ _INIT_DELAY_CMD(24),
+ _INIT_DCS_CMD(0x11),
+ _INIT_DELAY_CMD(120),
+ _INIT_DCS_CMD(0x29),
+ _INIT_DELAY_CMD(120),
+ {},
+};
+
static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
{
return container_of(panel, struct boe_panel, base);
@@ -452,20 +462,30 @@ static int boe_panel_unprepare(struct drm_panel *panel)
if (!boe->prepared)
return 0;
- ret = boe_panel_off(boe);
- if (ret < 0) {
- dev_err(panel->dev, "failed to set panel off: %d\n", ret);
- return ret;
+ if (boe->desc->discharge_on_disable) {
+ msleep(150);
+ regulator_disable(boe->avee);
+ regulator_disable(boe->avdd);
+ usleep_range(5000, 7000);
+ gpiod_set_value(boe->enable_gpio, 0);
+ usleep_range(5000, 7000);
+ regulator_disable(boe->pp1800);
+ } else {
+ ret = boe_panel_off(boe);
+ if (ret < 0) {
+ dev_err(panel->dev, "failed to set panel off: %d\n",
+ ret);
+ return ret;
+ }
+ msleep(150);
+ gpiod_set_value(boe->enable_gpio, 0);
+ usleep_range(500, 1000);
+ regulator_disable(boe->avee);
+ regulator_disable(boe->avdd);
+ usleep_range(5000, 7000);
+ regulator_disable(boe->pp1800);
}
- msleep(150);
- gpiod_set_value(boe->enable_gpio, 0);
- usleep_range(500, 1000);
- regulator_disable(boe->avee);
- regulator_disable(boe->avdd);
- usleep_range(5000, 7000);
- regulator_disable(boe->pp1800);
-
boe->prepared = false;
return 0;
@@ -495,10 +515,14 @@ static int boe_panel_prepare(struct drm_panel *panel)
if (ret < 0)
goto poweroffavdd;
- msleep(100);
+ usleep_range(5000, 1);
gpiod_set_value(boe->enable_gpio, 1);
- usleep_range(1, 12000);
+ usleep_range(1000, 2000);
+ gpiod_set_value(boe->enable_gpio, 0);
+ usleep_range(1000, 2000);
+ gpiod_set_value(boe->enable_gpio, 1);
+ usleep_range(6000, 1);
ret = boe_panel_init(boe);
if (ret < 0) {
@@ -530,6 +554,8 @@ static int boe_panel_enable(struct drm_panel *panel)
if (boe->enabled)
return 0;
+ msleep(130);
+
ret = backlight_enable(boe->backlight);
if (ret) {
dev_err(panel->dev, "Failed to enable backlight %d\n",
@@ -567,6 +593,35 @@ static const struct panel_desc boe_tv101wum_nl6_desc = {
.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
MIPI_DSI_MODE_LPM,
.init_cmds = boe_init_cmd,
+ .discharge_on_disable = false,
+};
+
+static const struct drm_display_mode auo_kd101n80_45na_default_mode = {
+ .clock = 157000,
+ .hdisplay = 1200,
+ .hsync_start = 1200 + 80,
+ .hsync_end = 1200 +
[PATCH v7 5/8] dt-bindings: display: panel: add boe tv101wum-n53 panel documentation
Add dcumentation for boe,tv101wum-n53, which is mipi dsi video panel
and resolution is 1200x1920.
Signed-off-by: Jitao Shi
---
.../display/panel/boe,tv101wum-n53.yaml | 67 +++
1 file changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml
new file mode 100644
index ..ceeba8d95486
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-n53.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TV101WUM-N53 DSI Display Panel
+
+maintainers:
+ - Thierry Reding
+ - Sam Ravnborg
+ - Rob Herring
+
+properties:
+ compatible:
+const: boe,tv101wum-n53
+
+ reg:
+description: the virtual channel number of a DSI peripheral
+
+ enable-gpios:
+description: a GPIO spec for the enable pin
+
+ pp1800-supply:
+description: core voltage supply
+
+ avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+ avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+ backlight:
+description: phandle of the backlight device attached to the panel
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+ - |
+ {
+panel@0 {
+compatible = "boe,tv101wum-n53";
+reg = <0>;
+enable-gpios = < 45 0>;
+avdd-supply = <_lcd>;
+avee-supply = <_lcd>;
+pp1800-supply = <_lcd>;
+backlight = <_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 3/8] dt-bindings: display: panel: add auo kd101n80-45na panel bindings
Add documentation for auo kd101n80-45na panel.
Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
---
.../display/panel/auo,kd101n80-45na.yaml | 67 +++
1 file changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml
b/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml
new file mode 100644
index ..46ba7e8a3896
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/auo,kd101n80-45na.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AUO KD101N80-45NA DSI Display Panel
+
+maintainers:
+ - Thierry Reding
+ - Sam Ravnborg
+ - Rob Herring
+
+properties:
+ compatible:
+const: auo,kd101n80-45na
+
+ reg:
+description: the virtual channel number of a DSI peripheral
+
+ enable-gpios:
+description: a GPIO spec for the enable pin
+
+ pp1800-supply:
+description: core voltage supply
+
+ avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+ avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+ backlight:
+description: phandle of the backlight device attached to the panel
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+ - |
+ {
+panel@0 {
+compatible = "auo,kd101n80-45na";
+reg = <0>;
+enable-gpios = < 45 0>;
+avdd-supply = <_lcd>;
+avee-supply = <_lcd>;
+pp1800-supply = <_lcd>;
+backlight = <_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/8] dt-bindings: display: panel: Add BOE tv101wum-n16 panel bindings
Add documentation for boe tv101wum-n16 panel.
Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
---
.../display/panel/boe,tv101wum-nl6.yaml | 67 +++
1 file changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
new file mode 100644
index ..25447682f826
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TV101WUM-Nl6 DSI Display Panel
+
+maintainers:
+ - Thierry Reding
+ - Sam Ravnborg
+ - Rob Herring
+
+properties:
+ compatible:
+const: boe,tv101wum-nl6
+
+ reg:
+description: the virtual channel number of a DSI peripheral
+
+ enable-gpios:
+description: a GPIO spec for the enable pin
+
+ pp1800-supply:
+description: core voltage supply
+
+ avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+ avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+ backlight:
+description: phandle of the backlight device attached to the panel
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+ - |
+ {
+panel@0 {
+compatible = "boe,tv101wum-nl6";
+reg = <0>;
+enable-gpios = < 45 0>;
+avdd-supply = <_lcd>;
+avee-supply = <_lcd>;
+pp1800-supply = <_lcd>;
+backlight = <_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.21.0
Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Hi,
On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote:
> Hi Brian,
>
> On 11/10/2019 10:41, Brian Starkey wrote:
> > Hi Neil,
> >
> > On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> >> Hi Ayan,
> >>
> >> On 10/10/2019 15:26, Ayan Halder wrote:
> >>> On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
> This adds all the OSD configuration plumbing to support the AFBC decoders
> path to display of the OSD1 plane.
>
> The Amlogic GXM and G12A AFBC decoders are integrated very differently.
>
> The Amlogic GXM has a direct output path to the OSD1 VIU pixel input,
> because the GXM AFBC decoder seem to be a custom IP developed by Amlogic.
>
> On the other side, the Amlogic G12A AFBC decoder seems to be an external
> IP that emit pixels on an AXI master hooked to a "Mali Unpack" block
> feeding the OSD1 VIU pixel input.
> This uses a weird "0x100" internal HW physical address on both
> sides to transfer the pixels.
>
> For Amlogic GXM, the supported pixel formats are the same as the normal
> linear OSD1 mode.
>
> On the other side, Amlogic added support for all AFBC v1.2 formats for
> the G12A AFBC integration.
>
> For simplicity, we stick to the already supported formats for now.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_crtc.c | 2 +
> drivers/gpu/drm/meson/meson_drv.h | 4 +
> drivers/gpu/drm/meson/meson_plane.c | 215
> 3 files changed, 190 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_crtc.c
> b/drivers/gpu/drm/meson/meson_crtc.c
> index 57ae1c13d1e6..d478fa232951 100644
> --- a/drivers/gpu/drm/meson/meson_crtc.c
> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> @@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv)
> if (priv->viu.osd1_enabled && priv->viu.osd1_commit) {
> writel_relaxed(priv->viu.osd1_ctrl_stat,
> priv->io_base +
> _REG(VIU_OSD1_CTRL_STAT));
> +writel_relaxed(priv->viu.osd1_ctrl_stat2,
> +priv->io_base +
> _REG(VIU_OSD1_CTRL_STAT2));
> writel_relaxed(priv->viu.osd1_blk0_cfg[0],
> priv->io_base +
> _REG(VIU_OSD1_BLK0_CFG_W0));
> writel_relaxed(priv->viu.osd1_blk0_cfg[1],
> diff --git a/drivers/gpu/drm/meson/meson_drv.h
> b/drivers/gpu/drm/meson/meson_drv.h
> index 60f13c6f34e5..de25349be8aa 100644
> --- a/drivers/gpu/drm/meson/meson_drv.h
> +++ b/drivers/gpu/drm/meson/meson_drv.h
> @@ -53,8 +53,12 @@ struct meson_drm {
> bool osd1_enabled;
> bool osd1_interlace;
> bool osd1_commit;
> +bool osd1_afbcd;
> uint32_t osd1_ctrl_stat;
> +uint32_t osd1_ctrl_stat2;
> uint32_t osd1_blk0_cfg[5];
> +uint32_t osd1_blk1_cfg4;
> +uint32_t osd1_blk2_cfg4;
> uint32_t osd1_addr;
> uint32_t osd1_stride;
> uint32_t osd1_height;
> diff --git a/drivers/gpu/drm/meson/meson_plane.c
> b/drivers/gpu/drm/meson/meson_plane.c
> index 5e798c276037..412941aa8402 100644
> --- a/drivers/gpu/drm/meson/meson_plane.c
> +++ b/drivers/gpu/drm/meson/meson_plane.c
> @@ -23,6 +23,7 @@
> #include "meson_plane.h"
> #include "meson_registers.h"
> #include "meson_viu.h"
> +#include "meson_osd_afbcd.h"
>
> /* OSD_SCI_WH_M1 */
> #define SCI_WH_M1_W(w) FIELD_PREP(GENMASK(28, 16), w)
> @@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane
> *plane,
> false, true);
> }
>
> +#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> \
> + AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |
> \
> + AFBC_FORMAT_MOD_YTR |
> \
> + AFBC_FORMAT_MOD_SPARSE |
> \
> + AFBC_FORMAT_MOD_SPLIT)
> +
> /* Takes a fixed 16.16 number and converts it to integer. */
> static inline int64_t fixed16_to_int(int64_t value)
> {
> return value >> 16;
> }
>
> +static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv)
> +{
> +u32 line_stride = 0;
> +
> +switch (priv->afbcd.format) {
> +case DRM_FORMAT_RGB565:
> +
[Bug 111691] inconsistent cursor movement speed when using AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #15 from Jaap Buurman --- I am running into the same issue. Arch Kernel: 5.3.5 llvm: 9.0.0 Mesa: 19.2.0 xf86-video-amdgpu: 19.0.1 Linux-firmware: 20190923 Let me know if I can supply any additional information. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/21] drm/exynos: Fix potential unbalanced calls to pm_runtime_put
Hi Inki,
On Mon, 26 Aug 2019 17:26:32 +0200
Boris Brezillon wrote:
> The encoder->enable() can't report errors and is expected to always
> succeed. If we call pm_runtime_put() in the exynos_dsi_enable() error
> path (as currently done) we'll have unbalanced get/put calls when
> encoder->disable() is called.
>
> The situation is not ideal since drm_panel_{prepare,enable}() can
> theoretically return an error (even if in practice I don't think any
> panel driver does that). Putting a WARN_ON() is the best we can do,
> unfortunately. Note that -ENOSYS is actually a valid case, it just
> means the panel driver does not implement the hook.
>
> Signed-off-by: Boris Brezillon
Did you have a chance to look at this patch 4 and 5 of this series? I'd
really like to get those 2 patches merged.
Thanks,
Boris
> ---
> Changes in v2:
> * New patch
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 8e655ae1fb0c..c555cecfe1f5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1387,8 +1387,7 @@ static void exynos_dsi_enable(struct drm_encoder
> *encoder)
>
> if (dsi->panel) {
> ret = drm_panel_prepare(dsi->panel);
> - if (ret < 0)
> - goto err_put_sync;
> + WARN_ON(ret && ret != -ENOSYS);
> } else {
> drm_bridge_pre_enable(dsi->out_bridge);
> }
> @@ -1398,22 +1397,13 @@ static void exynos_dsi_enable(struct drm_encoder
> *encoder)
>
> if (dsi->panel) {
> ret = drm_panel_enable(dsi->panel);
> - if (ret < 0)
> - goto err_display_disable;
> + WARN_ON(ret && ret != -ENOSYS);
> } else {
> drm_bridge_enable(dsi->out_bridge);
> }
>
> dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
> return;
> -
> -err_display_disable:
> - exynos_dsi_set_display_enable(dsi, false);
> - drm_panel_unprepare(dsi->panel);
> -
> -err_put_sync:
> - dsi->state &= ~DSIM_STATE_ENABLED;
> - pm_runtime_put(dsi->dev);
> }
>
> static void exynos_dsi_disable(struct drm_encoder *encoder)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/msm/dsi: Implement reset correctly
On msm8998, vblank timeouts are observed because the DSI controller is not
reset properly, which ends up stalling the MDP. This is because the reset
logic is not correct per the hardware documentation.
The documentation states that after asserting reset, software should wait
some time (no indication of how long), or poll the status register until it
returns 0 before deasserting reset.
wmb() is insufficient for this purpose since it just ensures ordering, not
timing between writes. Since asserting and deasserting reset occurs on the
same register, ordering is already guaranteed by the architecture, making
the wmb extraneous.
Since we would define a timeout for polling the status register to avoid a
possible infinite loop, lets just use a static delay of 20 ms, since 16.666
ms is the time available to process one frame at 60 fps.
Fixes: a689554ba6ed (drm/msm: Initial add DSI connector support)
Signed-off-by: Jeffrey Hugo
Reviewed-by: Sean Paul
---
v2:
-make a DEFINE for the delay
drivers/gpu/drm/msm/dsi/dsi_host.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 663ff9f4fac9..9a81705301c6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -26,6 +26,8 @@
#include "dsi_cfg.h"
#include "msm_kms.h"
+#define RESET_DELAY 20
+
static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
{
u32 ver;
@@ -986,7 +988,7 @@ static void dsi_sw_reset(struct msm_dsi_host *msm_host)
wmb(); /* clocks need to be enabled before reset */
dsi_write(msm_host, REG_DSI_RESET, 1);
- wmb(); /* make sure reset happen */
+ msleep(RESET_DELAY); /* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
}
@@ -1396,7 +1398,7 @@ static void dsi_sw_reset_restore(struct msm_dsi_host
*msm_host)
/* dsi controller can only be reset while clocks are running */
dsi_write(msm_host, REG_DSI_RESET, 1);
- wmb(); /* make sure reset happen */
+ msleep(RESET_DELAY);/* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
wmb(); /* controller out of reset */
dsi_write(msm_host, REG_DSI_CTRL, data0);
--
2.17.1
Re: [PATCH v2 4/4] drm/komeda: Adds gamma and color-transform support for DOU-IPS
Hi Mihail,
On Fri, Oct 11, 2019 at 08:54:03AM +, Mihail Atanassov wrote:
> Hi James, Lowry,
>
> On Friday, 11 October 2019 06:45:50 BST james qian wang (Arm Technology
> China) wrote:
> > From: "Lowry Li (Arm Technology China)"
> >
> > Adds gamma and color-transform support for DOU-IPS.
> > Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
> > If color management changed, set gamma and color-transform accordingly.
> >
> > Signed-off-by: Lowry Li (Arm Technology China)
> > ---
> > .../arm/display/komeda/d71/d71_component.c| 24 +++
> > .../gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
> > .../drm/arm/display/komeda/komeda_pipeline.h | 3 +++
> > .../display/komeda/komeda_pipeline_state.c| 6 +
> > 4 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > index c3d29c0b051b..e7e5a8e4430e 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > @@ -942,15 +942,39 @@ static int d71_merger_init(struct d71_dev *d71,
> > static void d71_improc_update(struct komeda_component *c,
> > struct komeda_component_state *state)
> > {
> > + struct drm_crtc_state *crtc_st = state->crtc->state;
> I'm not sure it's a good idea to introduce a dependency on drm state
> so far down in the HW funcs, is there a good reason for the direct prod?
We dicussed about this before. To decide using this way is to avoid of
duplicated state between DRM and Komeda.
Regards,
Lowry
> > struct komeda_improc_state *st = to_improc_st(state);
> > + struct d71_pipeline *pipe = to_d71_pipeline(c->pipeline);
> > u32 __iomem *reg = c->reg;
> > u32 index;
> > + u32 mask = 0, ctrl = 0;
> >
> > for_each_changed_input(state, index)
> > malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
> >to_d71_input_id(state, index));
> >
> > malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
> > +
> > + if (crtc_st->color_mgmt_changed) {
> > + mask |= IPS_CTRL_FT | IPS_CTRL_RGB;
> > +
> > + if (crtc_st->gamma_lut) {
> > + malidp_write_group(pipe->dou_ft_coeff_addr, FT_COEFF0,
> > + KOMEDA_N_GAMMA_COEFFS,
> > + st->fgamma_coeffs);
> > + ctrl |= IPS_CTRL_FT; /* enable gamma */
> > + }
> > +
> > + if (crtc_st->ctm) {
> > + malidp_write_group(reg, IPS_RGB_RGB_COEFF0,
> > + KOMEDA_N_CTM_COEFFS,
> > + st->ctm_coeffs);
> > + ctrl |= IPS_CTRL_RGB; /* enable gamut */
> > + }
> > + }
> > +
> > + if (mask)
> > + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
> > }
> >
> > static void d71_improc_dump(struct komeda_component *c, struct seq_file
> > *sf)
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > index 9beeda04818b..406b9d0ca058 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > @@ -590,6 +590,8 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> >
> > crtc->port = kcrtc->master->of_output_port;
> >
> > + drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
> > +
> > return err;
> > }
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > index b322f52ba8f2..c5ab8096c85d 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include "malidp_utils.h"
> > +#include "komeda_color_mgmt.h"
> >
> > #define KOMEDA_MAX_PIPELINES 2
> > #define KOMEDA_PIPELINE_MAX_LAYERS 4
> > @@ -324,6 +325,8 @@ struct komeda_improc {
> > struct komeda_improc_state {
> > struct komeda_component_state base;
> > u16 hsize, vsize;
> > + u32 fgamma_coeffs[KOMEDA_N_GAMMA_COEFFS];
> > + u32 ctm_coeffs[KOMEDA_N_CTM_COEFFS];
> > };
> >
> > /* display timing controller */
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > index 0ba9c6aa3708..4a40b37eb1a6 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > @@ -756,6 +756,12 @@ komeda_improc_validate(struct komeda_improc *improc,
> > st->hsize = dflow->in_w;
> > st->vsize = dflow->in_h;
> >
> > + if (kcrtc_st->base.color_mgmt_changed) {
> > +
Re: Kernel crash on 4.19.77-1-lts (Arch Linux / ThinkPad T470p)
On Thu, Oct 10, 2019 at 01:15:09PM -0400, John Maguire wrote: > Hi there, > > I wasn't sure which mailing list to use so I BCC'd > intel-...@lists.freedesktop.org and dri-devel@lists.freedesktop.org Just use Cc. We want all replies to go to the list(s) as well. > > I'm using a Lenovo Thinkpad T470p and running the 4.19.77-1-lts kernel on > Arch Linux. Recently, I've started getting freezes each day. Audio can > still be heard, but video output stops. I was able to retrieve a call trace > from journald. > > I've attached the output of "sudo lspci -vvv" as well as the message from > journald (null pointer dereference). Oct 10 12:53:30 scorpion kernel: RIP: 0010:dma_fence_signal_locked+0x30/0xe0 Looks like it could be https://bugs.freedesktop.org/show_bug.cgi?id=111381 in which case you just need to upgrade to 4.19.78 and it should be fixed. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #11 from Marko Popovic --- (In reply to takios+fdbugs from comment #10) > (In reply to Marko Popovic from comment #9) > > https://cgit.freedesktop.org/mesa/mesa/commit/ > > ?id=a2a68d551c1c2a4f13761ffa8f3f6f13fee7a384 > > > > This might actually fix the ring_gfx type hangs or even sdma ones at least > > for Vulkan API? Not exactly sure but will also be testing the latest MESA > > builds from Oibaf's PPA in following days and report back on the issue :) > > Sadly, I'm still getting the ring_gfx hangs after a few minutes of playing > Trackmania 2. Oh yes I forgot to add a reply here. It didn't solve any of the hangs for me either. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
Hi, james, ville syrjala, david,
在 2019/10/11 下午4:32, james qian wang (Arm Technology China) 写道:
On Fri, Oct 11, 2019 at 03:32:17PM +0800, sandy.huang wrote:
在 2019/10/11 下午3:22, james qian wang (Arm Technology China) 写道:
On Fri, Oct 11, 2019 at 03:07:22PM +0800, sandy.huang wrote:
在 2019/10/11 下午2:44, james qian wang (Arm Technology China) 写道:
On Fri, Oct 11, 2019 at 11:35:53AM +0800, sandy.huang wrote:
Hi james.qian.wang,
Thank for you remind, fou some unknow reason, i miss the the mail from
you:(, i get this message from https://patchwork.kernel.org/patch/11161937/
sorry about that.
About the format block describe, I also found some unreasonable, this
format need 2 line aligned, so the block_h need to sed as 2, and the
char_per_block need set as w * h * 10 for y plane, and w * h * 2 * 10 for uv
plane, so the following describe maybe more correct, thanks.
{ .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
Hi Sandy:
I think for such NV12 YUV-422 (hsub = 2, vsub = 2) 2x2 subsampled format
the block size can be:
the Y plane: 2x2;
The UV plane: 1x2; (H direction sample 1 Cb and 1Cr, V direction 2 lines got 2)
Then:
.char_per_block = {5, 5, 0} block_w = {2, 1, 0}. block_h = {2, 2, 0};
Thanks
James
Hi James,
If the block_w is 2 pixel, one line size at block is 2*10 bit %8 != 0,
Hi Sandy:
you got a mistake here, the bpp of UV plane is 20, 10bit Cb + 10 bit Cr.
here is for y plane.
Sorry, Are we talking about the block size calcaltion here ?
block_size = block_w * block_h * plane_bpp
for you Y plane a 2x2 block is: 2 x 2 * 10 bpp = 40bits
And the block info is for computing the minimum pitch, and don't
consider the specific hardware alignment here.
see: drm_format_info_min_pitch()
If you hardware need alignment, you need to put that consideration into your
specific driver.
James.
Hi david and ville syrjala,
Do you have any Suggestions?
James think Y plane 2x2 block size is enough to describe this
format, but i prefer to use 4x2 block size, this can include the
alignment message.
just like the malidp_de_plane_check()@malidp_plane.c have the following
code, here use the block size to check alignment.
block_w = drm_format_info_block_width(fb->format, 0);
block_h = drm_format_info_block_height(fb->format, 0);
if (fb->width % block_w || fb->height % block_h) {
DRM_DEBUG_KMS("Buffer width/height needs to be a multiple of
tile sizes");
return -EINVAL;
}
if ((state->src_x >> 16) % block_w || (state->src_y >> 16) % block_h) {
DRM_DEBUG_KMS("Plane src_x/src_y needs to be a multiple of tile
sizes");
return -EINVAL;
}
can you give me some suggestions?
thanks,
sandy.huang
although we use block to describe this format, but actually the data is
still stored one line by one line, still need 4 pixel aligned. so i think
here need use 4pixel*2line for per block
I think this is your hardware specific requirement.
Thanks
James
yes, this is a new format first used at rockchip platform.
Thanks,
sandy.huang
Thanks,
sandy.huang.
.hsub = 2, .vsub = 2, .is_yuv = true},
{ .format = DRM_FORMAT_NV21_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
{ .format = DRM_FORMAT_NV16_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_NV61_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 2, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_NV24_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 1, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_NV42_10, .depth = 0, .num_planes = 2,
.char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
= { 2, 2, 0 },
.hsub = 1, .vsub = 1, .is_yuv = true},
{ .format = DRM_FORMAT_P016, .depth = 0, .num_planes =
2,
.char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
.block_h = { 1, 0, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes
= 2,
+ .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 },
.block_h = { 4, 4, 0 },
Hi Sandy:
Their is a problem here for char_per_block size of plane[0]:
Since: 5 * 8 != 4 * 4 * 10;
Seems you mis-set the block_w/h, per your
Re: [PATCH v2 0/2] Add initial support for slimport anx7625
On Fri, Oct 11, 2019 at 02:20:47AM +, Xin Ji wrote: > Hi all, > > The following series add initial support for the Slimport ANX7625 > transmitter, a > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > device. > > This is the initial version, any mistakes, please let me know, I will fix it > in > the next series. > > Thanks, > Xin > I'm not a domain expert but I like these patches now. Reviewed-by: Dan Carpenter regards, dan carpenter
Re: [PATCH v2 4/4] drm/komeda: Adds gamma and color-transform support for DOU-IPS
On Friday, 11 October 2019 11:12:51 BST Lowry Li (Arm Technology China) wrote:
> Hi Mihail,
> On Fri, Oct 11, 2019 at 08:54:03AM +, Mihail Atanassov wrote:
> > Hi James, Lowry,
> >
> > On Friday, 11 October 2019 06:45:50 BST james qian wang (Arm Technology
> > China) wrote:
> > > From: "Lowry Li (Arm Technology China)"
> > >
> > > Adds gamma and color-transform support for DOU-IPS.
> > > Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
> > > If color management changed, set gamma and color-transform accordingly.
> > >
> > > Signed-off-by: Lowry Li (Arm Technology China)
> > > ---
> > > .../arm/display/komeda/d71/d71_component.c| 24 +++
> > > .../gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
> > > .../drm/arm/display/komeda/komeda_pipeline.h | 3 +++
> > > .../display/komeda/komeda_pipeline_state.c| 6 +
> > > 4 files changed, 35 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > index c3d29c0b051b..e7e5a8e4430e 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > @@ -942,15 +942,39 @@ static int d71_merger_init(struct d71_dev *d71,
> > > static void d71_improc_update(struct komeda_component *c,
> > > struct komeda_component_state *state)
> > > {
> > > + struct drm_crtc_state *crtc_st = state->crtc->state;
> > I'm not sure it's a good idea to introduce a dependency on drm state
> > so far down in the HW funcs, is there a good reason for the direct prod?
> We dicussed about this before. To decide using this way is to avoid of
> duplicated state between DRM and Komeda.
Fair, r-b me.
>
> Regards,
> Lowry
> > > struct komeda_improc_state *st = to_improc_st(state);
> > > + struct d71_pipeline *pipe = to_d71_pipeline(c->pipeline);
> > > u32 __iomem *reg = c->reg;
> > > u32 index;
> > > + u32 mask = 0, ctrl = 0;
> > >
> > > for_each_changed_input(state, index)
> > > malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
> > > to_d71_input_id(state, index));
> > >
> > > malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
> > > +
> > > + if (crtc_st->color_mgmt_changed) {
> > > + mask |= IPS_CTRL_FT | IPS_CTRL_RGB;
> > > +
> > > + if (crtc_st->gamma_lut) {
> > > + malidp_write_group(pipe->dou_ft_coeff_addr, FT_COEFF0,
> > > +KOMEDA_N_GAMMA_COEFFS,
> > > +st->fgamma_coeffs);
> > > + ctrl |= IPS_CTRL_FT; /* enable gamma */
> > > + }
> > > +
> > > + if (crtc_st->ctm) {
> > > + malidp_write_group(reg, IPS_RGB_RGB_COEFF0,
> > > +KOMEDA_N_CTM_COEFFS,
> > > +st->ctm_coeffs);
> > > + ctrl |= IPS_CTRL_RGB; /* enable gamut */
> > > + }
> > > + }
> > > +
> > > + if (mask)
> > > + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
> > > }
> > >
> > > static void d71_improc_dump(struct komeda_component *c, struct seq_file
> > > *sf)
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > index 9beeda04818b..406b9d0ca058 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > @@ -590,6 +590,8 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> > >
> > > crtc->port = kcrtc->master->of_output_port;
> > >
> > > + drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
> > > +
> > > return err;
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > > index b322f52ba8f2..c5ab8096c85d 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > > @@ -11,6 +11,7 @@
> > > #include
> > > #include
> > > #include "malidp_utils.h"
> > > +#include "komeda_color_mgmt.h"
> > >
> > > #define KOMEDA_MAX_PIPELINES 2
> > > #define KOMEDA_PIPELINE_MAX_LAYERS 4
> > > @@ -324,6 +325,8 @@ struct komeda_improc {
> > > struct komeda_improc_state {
> > > struct komeda_component_state base;
> > > u16 hsize, vsize;
> > > + u32 fgamma_coeffs[KOMEDA_N_GAMMA_COEFFS];
> > > + u32 ctm_coeffs[KOMEDA_N_CTM_COEFFS];
> > > };
> > >
> > > /* display timing controller */
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > > index 0ba9c6aa3708..4a40b37eb1a6 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > > +++
[Bug 111979] [5.2/5.3][drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted!
https://bugs.freedesktop.org/show_bug.cgi?id=111979 Bug ID: 111979 Summary: [5.2/5.3][drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: major Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: udo...@xs4all.nl Seen on both AMD 2400g and 3400g APU's, we find these in dmesg of 5.3.5.: 85.232749] fuse: init (API version 7.31) [18161.173791] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! [18166.037697] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered [18171.153568] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! [18186.261621] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered or on 5.2.17 sometimes: [ 7596.392996] sd 11:0:0:0: [sde] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00 [97954.657336] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! [97959.535278] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=2542528, emitted seq=2542531 [97959.535342] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0 [97959.535346] [drm] GPU recovery disabled. Then the graphics stop working and the machine GUI is unusable until reboot. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: fbtft: fbtft-core: Fix last line displayed on fbcon
From: Michael Hennerich
For the special case when fbtft_mkdirty() is called with with -1 for the y
coordinate, the height is truncated by 1.
This isn't required, and causes the last line to not update.
Signed-off-by: Michael Hennerich
Signed-off-by: Alexandru Ardelean
---
drivers/staging/fbtft/fbtft-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index cf5700a2ea66..90eec45d11fc 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -317,7 +317,7 @@ static void fbtft_mkdirty(struct fb_info *info, int y, int
height)
/* special case, needed ? */
if (y == -1) {
y = 0;
- height = info->var.yres - 1;
+ height = info->var.yres;
}
/* Mark display lines/area as dirty */
--
2.20.1
