Re: [PATCH v4 3/9] drm/mediatek: add ddp component AAL1
Hi, Stu:
On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> This patch add component AAL1 and
> rename AAL to AAL0
>
Reviewed-by: CK Hu
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
> 4 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 47ffa240bd25..7217665f4b5d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -110,7 +110,7 @@ static const unsigned int
> mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> };
>
> static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> - [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
> + [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> [DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
> [DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 4672317e3ad1..0919039805aa 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -218,7 +218,8 @@ struct mtk_ddp_comp_match {
> };
>
> static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX]
> = {
> - [DDP_COMPONENT_AAL] = { MTK_DISP_AAL, 0, &ddp_aal },
> + [DDP_COMPONENT_AAL0]= { MTK_DISP_AAL, 0, &ddp_aal },
> + [DDP_COMPONENT_AAL1]= { MTK_DISP_AAL, 1, &ddp_aal },
> [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
> [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, NULL },
> [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, NULL },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 0828cf8bf85c..eee3c0cc2632 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -41,7 +41,8 @@ enum mtk_ddp_comp_type {
> };
>
> enum mtk_ddp_comp_id {
> - DDP_COMPONENT_AAL,
> + DDP_COMPONENT_AAL0,
> + DDP_COMPONENT_AAL1,
> DDP_COMPONENT_BLS,
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_COLOR1,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index a2ca90fc403c..a415260f3d5f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -149,7 +149,7 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
> static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_COLOR0,
> - DDP_COMPONENT_AAL,
> + DDP_COMPONENT_AAL0,
> DDP_COMPONENT_OD,
> DDP_COMPONENT_RDMA0,
> DDP_COMPONENT_UFOE,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/9] drm/mediatek: add ddp component OD1
Hi, Stu:
On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> This patch add the component OD1 and
> rename the OD to OD1
rename the OD to OD0
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
> 4 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 7217665f4b5d..58e44349e315 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -114,7 +114,7 @@ static const unsigned int
> mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> [DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
> [DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
> - [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
> + [DDP_COMPONENT_OD0] = MT8173_MUTEX_MOD_DISP_OD,
> [DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
> [DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
> [DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
> @@ -139,7 +139,7 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
> cur,
> } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
> *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
> value = OVL_MOUT_EN_RDMA;
> - } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
> + } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
> *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD_MOUT_EN_RDMA0;
> } else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 0919039805aa..87acf6be87f6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -227,7 +227,8 @@ static const struct mtk_ddp_comp_match
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_DSI0]= { MTK_DSI,0, NULL },
> [DDP_COMPONENT_DSI1]= { MTK_DSI,1, NULL },
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> - [DDP_COMPONENT_OD] = { MTK_DISP_OD,0, &ddp_od },
> + [DDP_COMPONENT_OD0] = { MTK_DISP_OD,0, &ddp_od },
> + [DDP_COMPONENT_OD1] = { MTK_DISP_OD,1, &ddp_od },
> [DDP_COMPONENT_OVL0]= { MTK_DISP_OVL, 0, NULL },
> [DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, NULL },
> [DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index eee3c0cc2632..9b19fc4423f1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -50,7 +50,8 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_DSI0,
> DDP_COMPONENT_DSI1,
> DDP_COMPONENT_GAMMA,
> - DDP_COMPONENT_OD,
> + DDP_COMPONENT_OD0,
> + DDP_COMPONENT_OD1,
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_OVL1,
> DDP_COMPONENT_PWM0,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index a415260f3d5f..08d5d0b47bfe 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -150,7 +150,7 @@ static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] =
> {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_AAL0,
> - DDP_COMPONENT_OD,
> + DDP_COMPONENT_OD0,
> DDP_COMPONENT_RDMA0,
> DDP_COMPONENT_UFOE,
> DDP_COMPONENT_DSI0,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 5/9] drm/mediatek: add ddp component PWM1
Hi, Stu:
On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> This patch add component PWM1 in mtk_ddp_matches
>
Reviewed-by: CK Hu
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 87acf6be87f6..a5c7ac2d162d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -232,6 +232,7 @@ static const struct mtk_ddp_comp_match
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_OVL0]= { MTK_DISP_OVL, 0, NULL },
> [DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, NULL },
> [DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
> + [DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
> [DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
> [DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
> [DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/scheduler: add documentation
If there are no more objections/suggestions I will send the patch with
the changes suggested by Alex and Christian later today.
Nayan
On Fri, May 25, 2018 at 8:24 PM, Alex Deucher wrote:
> On Fri, May 25, 2018 at 12:45 AM, Nayan Deshmukh
> wrote:
>> convert existing raw comments into kernel-doc format as well
>> as add new documentation
>>
>> Signed-off-by: Alex Deucher
>> Signed-off-by: Nayan Deshmukh
>
> Looks good. just a couple comments below to clarify the language.
> With those fixed:
> Reviewed-by: Alex Deucher
>
>> ---
>> drivers/gpu/drm/scheduler/gpu_scheduler.c | 214
>> --
>> include/drm/gpu_scheduler.h | 153 +
>> 2 files changed, 296 insertions(+), 71 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> index 44d480768dfe..c70c983e3e74 100644
>> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> @@ -21,6 +21,29 @@
>> *
>> */
>>
>> +/**
>> + * DOC: Overview
>> + *
>> + * The GPU scheduler provides entities which allow userspace to push jobs
>> + * into software queues which are then scheduled on a hardware run queue.
>> + * The software queues have a priority among them. The scheduler selects
>> the entities
>> + * from the run queue using FIFO. The scheduler provides dependency handling
>
> a FIFO
>
>> + * features among jobs. The driver is supposed to provide functions for
>> backend
>
> The driver provides callback functions for backend
>
>> + * operations to the scheduler like submitting a job to hardware run queue,
>> + * returning the dependency of a job etc.
>> + *
>> + * The organisation of the scheduler is the following:-
>
> drop the -
>
>> + *
>> + * 1. Each ring buffer has one scheduler
>
> Each hw run queue
>
>> + * 2. Each scheduler has multiple run queues with different priorities
>> + *(i.e. HIGH_HW,HIGH_SW, KERNEL, NORMAL)
>
> s/i.e./e.g.,/
>
>> + * 3. Each run queue has a queue of entities to schedule
>
> Each scheduler run queue has a queue of entities to schedule
>
>> + * 4. Entities themselves maintain a queue of jobs that will be scheduled on
>> + *the hardware.
>> + *
>> + * The jobs in a entity are always scheduled in the order that they were
>> pushed.
>> + */
>> +
>> #include
>> #include
>> #include
>> @@ -39,7 +62,13 @@ static bool drm_sched_entity_is_ready(struct
>> drm_sched_entity *entity);
>> static void drm_sched_wakeup(struct drm_gpu_scheduler *sched);
>> static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb
>> *cb);
>>
>> -/* Initialize a given run queue struct */
>> +/**
>> + * drm_sched_rq_init - initialize a given run queue struct
>> + *
>> + * @rq: scheduler run queue
>> + *
>> + * Initializes a scheduler runqueue.
>> + */
>> static void drm_sched_rq_init(struct drm_sched_rq *rq)
>> {
>> spin_lock_init(&rq->lock);
>> @@ -47,6 +76,14 @@ static void drm_sched_rq_init(struct drm_sched_rq *rq)
>> rq->current_entity = NULL;
>> }
>>
>> +/**
>> + * drm_sched_rq_add_entity - add an entity
>> + *
>> + * @rq: scheduler run queue
>> + * @entity: scheduler entity
>> + *
>> + * Adds a scheduler entity to the run queue.
>> + */
>> static void drm_sched_rq_add_entity(struct drm_sched_rq *rq,
>> struct drm_sched_entity *entity)
>> {
>> @@ -57,6 +94,14 @@ static void drm_sched_rq_add_entity(struct drm_sched_rq
>> *rq,
>> spin_unlock(&rq->lock);
>> }
>>
>> +/**
>> + * drm_sched_rq_remove_entity - remove an entity
>> + *
>> + * @rq: scheduler run queue
>> + * @entity: scheduler entity
>> + *
>> + * Removes a scheduler entity from the run queue.
>> + */
>> static void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
>>struct drm_sched_entity *entity)
>> {
>> @@ -70,9 +115,9 @@ static void drm_sched_rq_remove_entity(struct
>> drm_sched_rq *rq,
>> }
>>
>> /**
>> - * Select an entity which could provide a job to run
>> + * drm_sched_rq_select_entity - Select an entity which could provide a job
>> to run
>> *
>> - * @rq The run queue to check.
>> + * @rq: scheduler run queue to check.
>> *
>> * Try to find a ready entity, returns NULL if none found.
>> */
>> @@ -112,15 +157,16 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
>> }
>>
>> /**
>> - * Init a context entity used by scheduler when submit to HW ring.
>> + * drm_sched_entity_init - Init a context entity used by scheduler when
>> + * submit to HW ring.
>> *
>> - * @sched The pointer to the scheduler
>> - * @entity The pointer to a valid drm_sched_entity
>> - * @rq The run queue this entity belongs
>> - * @guilty atomic_t set to 1 when a job on this queue
>> - * is found to be guilty causing a timeout
>> + * @sched: scheduler instance
>> + * @entity: scheduler entity to init
>> + * @rq: the run queue this entity be
Re: [PATCH v4 6/9] drm/mediatek: add ddp component PWM2
Hi, Stu:
On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> This patch add component PWM2
>
Reviewed-by: CK Hu
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index a5c7ac2d162d..86e8c9e5df41 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -233,6 +233,7 @@ static const struct mtk_ddp_comp_match
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, NULL },
> [DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
> [DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
> + [DDP_COMPONENT_PWM2]= { MTK_DISP_PWM, 2, NULL },
> [DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
> [DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
> [DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 9b19fc4423f1..e00c2e798abd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -56,6 +56,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_OVL1,
> DDP_COMPONENT_PWM0,
> DDP_COMPONENT_PWM1,
> + DDP_COMPONENT_PWM2,
> DDP_COMPONENT_RDMA0,
> DDP_COMPONENT_RDMA1,
> DDP_COMPONENT_RDMA2,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 7/9] drm/mediatek: add connection from OD1 to RDMA1
Hi, Stu:
On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> This patch add the connection from OD1 to RDMA1 for ext path.
>
Reviewed-by: CK Hu
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 58e44349e315..8bfc0debd2c2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -75,6 +75,7 @@
>
> #define OVL0_MOUT_EN_COLOR0 0x1
> #define OD_MOUT_EN_RDMA0 0x1
> +#define OD1_MOUT_EN_RDMA1BIT(16)
> #define UFOE_MOUT_EN_DSI00x1
> #define COLOR0_SEL_IN_OVL0 0x1
> #define OVL1_MOUT_EN_COLOR1 0x1
> @@ -151,6 +152,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
> cur,
> } else if (cur == DDP_COMPONENT_GAMMA && next == DDP_COMPONENT_RDMA1) {
> *addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
> value = GAMMA_MOUT_EN_RDMA1;
> + } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
> + *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> + value = OD1_MOUT_EN_RDMA1;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/8] drm/bridge: fix dependency for lvds-encoder
On Fri, May 25, 2018 at 5:50 PM, Arnd Bergmann wrote:
> The DRM panel bridge code is built into the kms helpers module, so we
> get a link error when trying to use it from a built-in driver while the
> kms helper is a loadable module:
>
> drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
> lvds-encoder.c:(.text+0x124): undefined reference to
> `devm_drm_panel_bridge_add'
>
> This adds a the same dependency in the lvds-encoder that we use for all
> the other users of the panel bridge. I did not bisect the problem, but
> from inspection it seems to date back to the patch that separated out
> the panel bridge from lvds encoder.
>
> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the
> lvds-encoder bridge.")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 8/9] drm/mediatek: add third ddp path
Hi, Stu:
One inline comment.
On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> This patch create third crtc by third ddp path
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +--
> 3 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 658b8dd45b83..2d6aa150a9ff 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -539,6 +539,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> int ret;
> int i;
>
> + if (!path)
> + return 0;
> +
> for (i = 0; i < path_len; i++) {
> enum mtk_ddp_comp_id comp_id = path[i];
> struct device_node *node;
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 08d5d0b47bfe..3d279a299383 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -232,6 +232,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> if (ret < 0)
> goto err_component_unbind;
>
> + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> + private->data->third_len);
> + if (ret < 0)
> + goto err_component_unbind;
> +
> /* Use OVL device for all DMA memory allocations */
> np = private->comp_node[private->data->main_path[0]] ?:
>private->comp_node[private->data->ext_path[0]];
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index c3378c452c0a..d867e2683923 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -17,8 +17,8 @@
> #include
> #include "mtk_drm_ddp_comp.h"
>
> -#define MAX_CRTC 2
> -#define MAX_CONNECTOR2
> +#define MAX_CRTC 3
> +#define MAX_CONNECTOR3
MAX_CONNECTOR is useless, maybe we just need to remove it in a clean up
patch. Or you could keep its value.
Regards,
CK
>
> struct device;
> struct device_node;
> @@ -33,6 +33,9 @@ struct mtk_mmsys_driver_data {
> unsigned int main_len;
> const enum mtk_ddp_comp_id *ext_path;
> unsigned int ext_len;
> + const enum mtk_ddp_comp_id *third_path;
> + unsigned int third_len;
> +
> bool shadow_register;
> };
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 9/9] drm/mediatek: Add support for mediatek SOC MT2712
Hi, Stu:
Two inline comment.
On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> This patch add support for the Mediatek MT2712 DISP subsystem.
> There are two OVL engine and three disp output in MT2712.
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 39
> ++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 +
> 2 files changed, 77 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 8bfc0debd2c2..3b22b48a6022 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -61,6 +61,24 @@
> #define MT8173_MUTEX_MOD_DISP_PWM1 24
> #define MT8173_MUTEX_MOD_DISP_OD 25
>
> +#define MT2712_MUTEX_MOD_DISP_PWM2 10
> +#define MT2712_MUTEX_MOD_DISP_OVL0 11
> +#define MT2712_MUTEX_MOD_DISP_OVL1 12
> +#define MT2712_MUTEX_MOD_DISP_RDMA0 13
> +#define MT2712_MUTEX_MOD_DISP_RDMA1 14
> +#define MT2712_MUTEX_MOD_DISP_RDMA2 15
> +#define MT2712_MUTEX_MOD_DISP_WDMA0 16
> +#define MT2712_MUTEX_MOD_DISP_WDMA1 17
> +#define MT2712_MUTEX_MOD_DISP_COLOR0 18
> +#define MT2712_MUTEX_MOD_DISP_COLOR1 19
> +#define MT2712_MUTEX_MOD_DISP_AAL0 20
> +#define MT2712_MUTEX_MOD_DISP_UFOE 22
> +#define MT2712_MUTEX_MOD_DISP_PWM0 23
> +#define MT2712_MUTEX_MOD_DISP_PWM1 24
> +#define MT2712_MUTEX_MOD_DISP_OD025
> +#define MT2712_MUTEX_MOD2_DISP_AAL1 33
> +#define MT2712_MUTEX_MOD2_DISP_OD1 34
> +
> #define MT2701_MUTEX_MOD_DISP_OVL3
> #define MT2701_MUTEX_MOD_DISP_WDMA 6
> #define MT2701_MUTEX_MOD_DISP_COLOR 7
> @@ -110,6 +128,26 @@ static const unsigned int
> mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> };
>
> +static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
> + [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
> + [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
> + [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
> + [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
> + [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
> + [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
> + [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
> + [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
> + [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
> + [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
> + [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
> + [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
> + [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
> + [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
> +};
> +
> static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> @@ -430,6 +468,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
>
> static const struct of_device_id ddp_driver_dt_match[] = {
> { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
> + { .compatible = "mediatek,mt2712-disp-mutex", .data = mt2712_mutex_mod},
> { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
> {},
> };
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 3d279a299383..3a866e1d6af4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -146,6 +146,32 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] =
> {
> DDP_COMPONENT_DPI0,
> };
>
> +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
> + DDP_COMPONENT_OVL0,
> + DDP_COMPONENT_COLOR0,
> + DDP_COMPONENT_AAL0,
> + DDP_COMPONENT_OD0,
> + DDP_COMPONENT_RDMA0,
> + DDP_COMPONENT_DPI0,
> + DDP_COMPONENT_PWM0,
> +};
> +
> +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_ext[] = {
> + DDP_COMPONENT_OVL1,
> + DDP_COMPONENT_COLOR1,
> + DDP_COMPONENT_AAL1,
> + DDP_COMPONENT_OD1,
> + DDP_COMPONENT_RDMA1,
> + DDP_COMPONENT_DPI1,
Where do you define DDP_COMPONENT_DPI1?
> + DDP_COMPONENT_PWM1,
> +};
> +
> +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] = {
> + DDP_COMPONENT_RDMA2,
> + DDP_COMPONENT_DSI2,
Where do you define DDP_COMPONENT_DSI2?
Regards,
CK
> + DDP_COMPONENT_PWM2,
> +};
> +
> static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_COLOR0,
> @@ -173,6 +199,15 @@ stat
Re: [PATCH 7/8] drm/bridge: fix dependency for lvds-encoder
Hi Arnd,
Thank you for the patch.
On Friday, 25 May 2018 18:50:14 EEST Arnd Bergmann wrote:
> The DRM panel bridge code is built into the kms helpers module, so we
> get a link error when trying to use it from a built-in driver while the
> kms helper is a loadable module:
>
> drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
> lvds-encoder.c:(.text+0x124): undefined reference to
> `devm_drm_panel_bridge_add'
>
> This adds a the same dependency in the lvds-encoder that we use for all
> the other users of the panel bridge. I did not bisect the problem, but
> from inspection it seems to date back to the patch that separated out
> the panel bridge from lvds encoder.
>
> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the
> lvds-encoder bridge.") Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/bridge/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 6caa47834194..cf47bfa7a050 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -46,6 +46,7 @@ config DRM_DUMB_VGA_DAC
> config DRM_LVDS_ENCODER
> tristate "Transparent parallel to LVDS encoder support"
> depends on OF
> + select DRM_KMS_HELPER
> select DRM_PANEL_BRIDGE
> help
> Support for transparent parallel to LVDS encoders that don't require
Wouldn't it be better to apply the following ?
config DRM_PANEL_BRIDGE
def_bool y
depends on DRM_BRIDGE
- depends on DRM_KMS_HELPER
+ select DRM_KMS_HELPER
select DRM_PANEL
help
DRM bridge wrapper of DRM panels
Otherwise you'll potentially have to patch every user of DRM_PANEL_BRIDGE as
done in this patch.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/8] drm/bridge: fix dependency for lvds-encoder
On Mon, May 28, 2018 at 10:02 AM, Laurent Pinchart
wrote:
> Hi Arnd,
>
> Thank you for the patch.
>
> On Friday, 25 May 2018 18:50:14 EEST Arnd Bergmann wrote:
>> The DRM panel bridge code is built into the kms helpers module, so we
>> get a link error when trying to use it from a built-in driver while the
>> kms helper is a loadable module:
>>
>> drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
>> lvds-encoder.c:(.text+0x124): undefined reference to
>> `devm_drm_panel_bridge_add'
>>
>> This adds a the same dependency in the lvds-encoder that we use for all
>> the other users of the panel bridge. I did not bisect the problem, but
>> from inspection it seems to date back to the patch that separated out
>> the panel bridge from lvds encoder.
>>
>> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the
>> lvds-encoder bridge.") Signed-off-by: Arnd Bergmann
>> ---
>> drivers/gpu/drm/bridge/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index 6caa47834194..cf47bfa7a050 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -46,6 +46,7 @@ config DRM_DUMB_VGA_DAC
>> config DRM_LVDS_ENCODER
>> tristate "Transparent parallel to LVDS encoder support"
>> depends on OF
>> + select DRM_KMS_HELPER
>> select DRM_PANEL_BRIDGE
>> help
>> Support for transparent parallel to LVDS encoders that don't require
>
> Wouldn't it be better to apply the following ?
>
> config DRM_PANEL_BRIDGE
> def_bool y
> depends on DRM_BRIDGE
> - depends on DRM_KMS_HELPER
> + select DRM_KMS_HELPER
> select DRM_PANEL
> help
>DRM bridge wrapper of DRM panels
>
> Otherwise you'll potentially have to patch every user of DRM_PANEL_BRIDGE as
> done in this patch.
Select isn't recursive, so this won't work unfortunately :-/
-Daniel
> --
> Regards,
>
> Laurent Pinchart
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/scheduler: add documentation
On Fri, May 25, 2018 at 6:45 AM, Nayan Deshmukh
wrote:
> convert existing raw comments into kernel-doc format as well
> as add new documentation
>
> Signed-off-by: Alex Deucher
> Signed-off-by: Nayan Deshmukh
> ---
> drivers/gpu/drm/scheduler/gpu_scheduler.c | 214
> --
> include/drm/gpu_scheduler.h | 153 +
> 2 files changed, 296 insertions(+), 71 deletions(-)
Please also include all the new scheduler docs into
Documentation/gpu/drm-mm.rst (I think that's the most suitable place)
and make sure the resulting docs look good and hyperlinks all work
correctly using
$ make htmldocs
Thanks, Daniel
>
> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> index 44d480768dfe..c70c983e3e74 100644
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> @@ -21,6 +21,29 @@
> *
> */
>
> +/**
> + * DOC: Overview
> + *
> + * The GPU scheduler provides entities which allow userspace to push jobs
> + * into software queues which are then scheduled on a hardware run queue.
> + * The software queues have a priority among them. The scheduler selects the
> entities
> + * from the run queue using FIFO. The scheduler provides dependency handling
> + * features among jobs. The driver is supposed to provide functions for
> backend
> + * operations to the scheduler like submitting a job to hardware run queue,
> + * returning the dependency of a job etc.
> + *
> + * The organisation of the scheduler is the following:-
> + *
> + * 1. Each ring buffer has one scheduler
> + * 2. Each scheduler has multiple run queues with different priorities
> + *(i.e. HIGH_HW,HIGH_SW, KERNEL, NORMAL)
> + * 3. Each run queue has a queue of entities to schedule
> + * 4. Entities themselves maintain a queue of jobs that will be scheduled on
> + *the hardware.
> + *
> + * The jobs in a entity are always scheduled in the order that they were
> pushed.
> + */
> +
> #include
> #include
> #include
> @@ -39,7 +62,13 @@ static bool drm_sched_entity_is_ready(struct
> drm_sched_entity *entity);
> static void drm_sched_wakeup(struct drm_gpu_scheduler *sched);
> static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb
> *cb);
>
> -/* Initialize a given run queue struct */
> +/**
> + * drm_sched_rq_init - initialize a given run queue struct
> + *
> + * @rq: scheduler run queue
> + *
> + * Initializes a scheduler runqueue.
> + */
> static void drm_sched_rq_init(struct drm_sched_rq *rq)
> {
> spin_lock_init(&rq->lock);
> @@ -47,6 +76,14 @@ static void drm_sched_rq_init(struct drm_sched_rq *rq)
> rq->current_entity = NULL;
> }
>
> +/**
> + * drm_sched_rq_add_entity - add an entity
> + *
> + * @rq: scheduler run queue
> + * @entity: scheduler entity
> + *
> + * Adds a scheduler entity to the run queue.
> + */
> static void drm_sched_rq_add_entity(struct drm_sched_rq *rq,
> struct drm_sched_entity *entity)
> {
> @@ -57,6 +94,14 @@ static void drm_sched_rq_add_entity(struct drm_sched_rq
> *rq,
> spin_unlock(&rq->lock);
> }
>
> +/**
> + * drm_sched_rq_remove_entity - remove an entity
> + *
> + * @rq: scheduler run queue
> + * @entity: scheduler entity
> + *
> + * Removes a scheduler entity from the run queue.
> + */
> static void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
>struct drm_sched_entity *entity)
> {
> @@ -70,9 +115,9 @@ static void drm_sched_rq_remove_entity(struct drm_sched_rq
> *rq,
> }
>
> /**
> - * Select an entity which could provide a job to run
> + * drm_sched_rq_select_entity - Select an entity which could provide a job
> to run
> *
> - * @rq The run queue to check.
> + * @rq: scheduler run queue to check.
> *
> * Try to find a ready entity, returns NULL if none found.
> */
> @@ -112,15 +157,16 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
> }
>
> /**
> - * Init a context entity used by scheduler when submit to HW ring.
> + * drm_sched_entity_init - Init a context entity used by scheduler when
> + * submit to HW ring.
> *
> - * @sched The pointer to the scheduler
> - * @entity The pointer to a valid drm_sched_entity
> - * @rq The run queue this entity belongs
> - * @guilty atomic_t set to 1 when a job on this queue
> - * is found to be guilty causing a timeout
> + * @sched: scheduler instance
> + * @entity: scheduler entity to init
> + * @rq: the run queue this entity belongs
> + * @guilty: atomic_t set to 1 when a job on this queue
> + * is found to be guilty causing a timeout
> *
> - * return 0 if succeed. negative error code on failure
> + * Returns 0 on success or a negative error code on failure.
> */
> int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
> struct drm_sched_entity *entity,
> @@ -149,10 +195,10 @@ in
Re: [PATCH v1 1/7] drm/mediatek: move dpi private data to device
Hi, Bibby:
Some inline comment.
On Mon, 2018-05-14 at 15:52 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> move clock factor and edge enable setting to private data.
>
I think this modification is to separate different part of dpi driver
for different chip.
Describe more for this.
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 82
> ++---
> drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 2 +-
> 2 files changed, 66 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index e80a603e5fb0..993dc44368bd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -71,11 +71,13 @@ struct mtk_dpi {
> struct clk *tvd_clk;
> int irq;
> struct drm_display_mode mode;
> + const struct mtk_dpi_conf *conf;
> enum mtk_dpi_out_color_format color_format;
> enum mtk_dpi_out_yc_map yc_map;
> enum mtk_dpi_out_bit_num bit_num;
> enum mtk_dpi_out_channel_swap channel_swap;
> bool power_sta;
> + int refcount;
> u8 power_ctl;
> };
>
> @@ -115,6 +117,12 @@ struct mtk_dpi_yc_limit {
> u16 c_bottom;
> };
>
> +struct mtk_dpi_conf {
> + unsigned int (*cal_factor)(int clock);
> + const u32 reg_h_fre_con;
> + bool edge_sel_en;
> +};
> +
> static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
> {
> u32 tmp = readl(dpi->regs + offset) & ~mask;
> @@ -340,7 +348,13 @@ static void mtk_dpi_config_swap_input(struct mtk_dpi
> *dpi, bool enable)
>
> static void mtk_dpi_config_2n_h_fre(struct mtk_dpi *dpi)
> {
> - mtk_dpi_mask(dpi, DPI_H_FRE_CON, H_FRE_2N, H_FRE_2N);
> + mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, H_FRE_2N, H_FRE_2N);
> +}
> +
> +static void mtk_dpi_config_disable_edge(struct mtk_dpi *dpi)
> +{
> + if (dpi->conf->edge_sel_en)
> + mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
> }
>
> static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
> @@ -368,6 +382,12 @@ static void mtk_dpi_config_color_format(struct mtk_dpi
> *dpi,
>
> static void mtk_dpi_power_off(struct mtk_dpi *dpi, enum mtk_dpi_power_ctl
> pctl)
> {
> + if (WARN_ON(dpi->refcount == 0))
> + return;
> +
> + if (--dpi->refcount != 0)
> + return;
> +
I think 'refcount' should be moved to an independent patch.
> dpi->power_ctl &= ~pctl;
>
> if ((dpi->power_ctl & DPI_POWER_START) ||
> @@ -385,16 +405,19 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi, enum
> mtk_dpi_power_ctl pctl)
>
> static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum mtk_dpi_power_ctl pctl)
> {
> - int ret;
> + int ret = 0;
> +
> + if (++dpi->refcount != 1)
> + return 0;
>
> dpi->power_ctl |= pctl;
>
> if (!(dpi->power_ctl & DPI_POWER_START) &&
> !(dpi->power_ctl & DPI_POWER_ENABLE))
> - return 0;
> + goto err_refcount;
>
> if (dpi->power_sta)
> - return 0;
> + goto err_refcount;
>
> ret = clk_prepare_enable(dpi->engine_clk);
> if (ret) {
> @@ -416,6 +439,8 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum
> mtk_dpi_power_ctl pctl)
> clk_disable_unprepare(dpi->engine_clk);
> err_eng:
> dpi->power_ctl &= ~pctl;
> +err_refcount:
> + dpi->refcount--;
> return ret;
> }
>
> @@ -433,16 +458,13 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> unsigned long pll_rate;
> unsigned int factor;
>
> + if (!dpi) {
> + dev_err(dpi->dev, "invalid argument\n");
> + return -EINVAL;
> + }
> /* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */
> pix_rate = 1000UL * mode->clock;
> - if (mode->clock <= 27000)
> - factor = 16 * 3;
> - else if (mode->clock <= 84000)
> - factor = 8 * 3;
> - else if (mode->clock <= 167000)
> - factor = 4 * 3;
> - else
> - factor = 2 * 3;
> + factor = dpi->conf->cal_factor(mode->clock);
> pll_rate = pix_rate * factor;
>
> dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n",
> @@ -518,6 +540,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> mtk_dpi_config_yc_map(dpi, dpi->yc_map);
> mtk_dpi_config_color_format(dpi, dpi->color_format);
> mtk_dpi_config_2n_h_fre(dpi);
> + mtk_dpi_config_disable_edge(dpi);
What does this do? Separate this to an independent patch and describe
what does this do.
> mtk_dpi_sw_reset(dpi, false);
>
> return 0;
> @@ -656,6 +679,31 @@ static const struct component_ops mtk_dpi_component_ops
> = {
> .unbind = mtk_dpi_unbind,
> };
>
> +static unsigned int mt8173_calculate_factor(int clock)
> +{
> + if (clock <= 27000)
> + return 16 * 3;
> + else if (clock <= 74250)
Why do y
Re: [PATCH v1 2/7] drm/mediatek: fix to get right bridge for dpi encoder
Hi, Bibby:
Some inline comment.
On Mon, 2018-05-14 at 15:52 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> 1, dpi is an encoder, there is an bridge in the struct
> of decoder, we could use it.
The encoder.bridge is assigned in drm_bridge_attach(), so I think the
design is to assign this member in drm_bridge_attach().
Any assignment outside this function may conflict with this design.
> 2, using of_graph_get_remote_port_parent to get right
> bridge in device tree.
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 0a44ab175422..2b8b34c72697 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -63,7 +63,6 @@ enum mtk_dpi_out_color_format {
> struct mtk_dpi {
> struct mtk_ddp_comp ddp_comp;
> struct drm_encoder encoder;
> - struct drm_bridge *bridge;
> void __iomem *regs;
> struct device *dev;
> struct clk *engine_clk;
> @@ -643,8 +642,8 @@ static int mtk_dpi_bind(struct device *dev, struct device
> *master, void *data)
>
> /* Currently DPI0 is fixed to be driven by OVL1 */
> dpi->encoder.possible_crtcs = BIT(1);
> -
> - ret = drm_bridge_attach(&dpi->encoder, dpi->bridge, NULL);
> + dpi->encoder.bridge->encoder = &dpi->encoder;
This is done inside drm_bridge_attach().
> + ret = drm_bridge_attach(&dpi->encoder, dpi->encoder.bridge, NULL);
> if (ret) {
> dev_err(dev, "Failed to attach bridge: %d\n", ret);
> goto err_cleanup;
> @@ -709,7 +708,7 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct mtk_dpi *dpi;
> struct resource *mem;
> - struct device_node *bridge_node;
> + struct device_node *ep, *bridge_node;
> int comp_id;
> const struct of_device_id *match;
> int ret;
> @@ -759,15 +758,21 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - bridge_node = of_graph_get_remote_node(dev->of_node, 0, 0);
> - if (!bridge_node)
> + ep = of_graph_get_next_endpoint(dev->of_node, NULL);
> + if (ep) {
> + bridge_node = of_graph_get_remote_port_parent(ep);
> + of_node_put(ep);
> + }
> + if (!bridge_node) {
> + dev_err(dev, "Failed to find bridge node\n");
> return -ENODEV;
> + }
This looks like mt8173 has the same bug, so send this patch
independently and it would be more quick to merge.
For mtk_dsi, it use drm_of_find_panel_or_bridge(), so I think you could
use the same function to get bridge.
Regards,
CK
>
> dev_info(dev, "Found bridge node: %pOF\n", bridge_node);
>
> - dpi->bridge = of_drm_find_bridge(bridge_node);
> + dpi->encoder.bridge = of_drm_find_bridge(bridge_node);
> of_node_put(bridge_node);
> - if (!dpi->bridge)
> + if (!dpi->encoder.bridge)
> return -EPROBE_DEFER;
>
> comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/scheduler: add documentation
I have done that already, sent a patch with this one. The last patch
of this series. I have tried to take care of all the hyperlinks.
On Mon, May 28, 2018 at 1:39 PM, Daniel Vetter wrote:
> On Fri, May 25, 2018 at 6:45 AM, Nayan Deshmukh
> wrote:
>> convert existing raw comments into kernel-doc format as well
>> as add new documentation
>>
>> Signed-off-by: Alex Deucher
>> Signed-off-by: Nayan Deshmukh
>> ---
>> drivers/gpu/drm/scheduler/gpu_scheduler.c | 214
>> --
>> include/drm/gpu_scheduler.h | 153 +
>> 2 files changed, 296 insertions(+), 71 deletions(-)
>
> Please also include all the new scheduler docs into
> Documentation/gpu/drm-mm.rst (I think that's the most suitable place)
> and make sure the resulting docs look good and hyperlinks all work
> correctly using
>
> $ make htmldocs
>
> Thanks, Daniel
>
>>
>> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> index 44d480768dfe..c70c983e3e74 100644
>> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> @@ -21,6 +21,29 @@
>> *
>> */
>>
>> +/**
>> + * DOC: Overview
>> + *
>> + * The GPU scheduler provides entities which allow userspace to push jobs
>> + * into software queues which are then scheduled on a hardware run queue.
>> + * The software queues have a priority among them. The scheduler selects
>> the entities
>> + * from the run queue using FIFO. The scheduler provides dependency handling
>> + * features among jobs. The driver is supposed to provide functions for
>> backend
>> + * operations to the scheduler like submitting a job to hardware run queue,
>> + * returning the dependency of a job etc.
>> + *
>> + * The organisation of the scheduler is the following:-
>> + *
>> + * 1. Each ring buffer has one scheduler
>> + * 2. Each scheduler has multiple run queues with different priorities
>> + *(i.e. HIGH_HW,HIGH_SW, KERNEL, NORMAL)
>> + * 3. Each run queue has a queue of entities to schedule
>> + * 4. Entities themselves maintain a queue of jobs that will be scheduled on
>> + *the hardware.
>> + *
>> + * The jobs in a entity are always scheduled in the order that they were
>> pushed.
>> + */
>> +
>> #include
>> #include
>> #include
>> @@ -39,7 +62,13 @@ static bool drm_sched_entity_is_ready(struct
>> drm_sched_entity *entity);
>> static void drm_sched_wakeup(struct drm_gpu_scheduler *sched);
>> static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb
>> *cb);
>>
>> -/* Initialize a given run queue struct */
>> +/**
>> + * drm_sched_rq_init - initialize a given run queue struct
>> + *
>> + * @rq: scheduler run queue
>> + *
>> + * Initializes a scheduler runqueue.
>> + */
>> static void drm_sched_rq_init(struct drm_sched_rq *rq)
>> {
>> spin_lock_init(&rq->lock);
>> @@ -47,6 +76,14 @@ static void drm_sched_rq_init(struct drm_sched_rq *rq)
>> rq->current_entity = NULL;
>> }
>>
>> +/**
>> + * drm_sched_rq_add_entity - add an entity
>> + *
>> + * @rq: scheduler run queue
>> + * @entity: scheduler entity
>> + *
>> + * Adds a scheduler entity to the run queue.
>> + */
>> static void drm_sched_rq_add_entity(struct drm_sched_rq *rq,
>> struct drm_sched_entity *entity)
>> {
>> @@ -57,6 +94,14 @@ static void drm_sched_rq_add_entity(struct drm_sched_rq
>> *rq,
>> spin_unlock(&rq->lock);
>> }
>>
>> +/**
>> + * drm_sched_rq_remove_entity - remove an entity
>> + *
>> + * @rq: scheduler run queue
>> + * @entity: scheduler entity
>> + *
>> + * Removes a scheduler entity from the run queue.
>> + */
>> static void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
>>struct drm_sched_entity *entity)
>> {
>> @@ -70,9 +115,9 @@ static void drm_sched_rq_remove_entity(struct
>> drm_sched_rq *rq,
>> }
>>
>> /**
>> - * Select an entity which could provide a job to run
>> + * drm_sched_rq_select_entity - Select an entity which could provide a job
>> to run
>> *
>> - * @rq The run queue to check.
>> + * @rq: scheduler run queue to check.
>> *
>> * Try to find a ready entity, returns NULL if none found.
>> */
>> @@ -112,15 +157,16 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
>> }
>>
>> /**
>> - * Init a context entity used by scheduler when submit to HW ring.
>> + * drm_sched_entity_init - Init a context entity used by scheduler when
>> + * submit to HW ring.
>> *
>> - * @sched The pointer to the scheduler
>> - * @entity The pointer to a valid drm_sched_entity
>> - * @rq The run queue this entity belongs
>> - * @guilty atomic_t set to 1 when a job on this queue
>> - * is found to be guilty causing a timeout
>> + * @sched: scheduler instance
>> + * @entity: scheduler entity to init
>> + * @rq: the run queue this entity belongs
>> + * @guilty: atomic_t set to 1 when a job on this queue
Re: [PATCH v1 4/7] drm/mediatek: add hdmi driver for different hardware
Hi, Bibby:
On Mon, 2018-05-14 at 15:52 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> This patch adds hdmi driver suppot for both MT2701 and MT7623.
> And also support other (existing or future) chips that use
> the same binding and driver.
I think this patch should be separated to at least two patches.
The first is to isolate the different part for mt8173. And the second is
to add mt2701 part.
Regards,
CK
>
> Signed-off-by: Chunhui Dai
> ---
> drivers/gpu/drm/mediatek/Makefile | 4 +-
> drivers/gpu/drm/mediatek/mtk_hdmi.c| 91 +---
> drivers/gpu/drm/mediatek/mtk_hdmi.h| 28 +++
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 157 +
> drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 1 +
> drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 307
> +
> drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 129 +--
> 7 files changed, 568 insertions(+), 149 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> create mode 100644 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index ce83c396a742..44464893c1cb 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -18,6 +18,8 @@ obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
> mediatek-drm-hdmi-objs := mtk_cec.o \
> mtk_hdmi.o \
> mtk_hdmi_ddc.o \
> - mtk_mt8173_hdmi_phy.o
> + mtk_mt2701_hdmi_phy.o \
> + mtk_mt8173_hdmi_phy.o \
> + mtk_hdmi_phy.o
>
> obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 59a11026dceb..85e280962aad 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -233,6 +233,7 @@ static void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi,
> bool black)
> static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi, bool enable)
> {
> struct arm_smccc_res res;
> + struct mtk_hdmi_phy *hdmi_phy = phy_get_drvdata(hdmi->phy);
>
> /*
>* MT8173 HDMI hardware has an output control bit to enable/disable HDMI
> @@ -240,8 +241,13 @@ static void mtk_hdmi_hw_make_reg_writable(struct
> mtk_hdmi *hdmi, bool enable)
>* The ARM trusted firmware provides an API for the HDMI driver to set
>* this control bit to enable HDMI output in supervisor mode.
>*/
> - arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904, 0x8000,
> - 0, 0, 0, 0, 0, &res);
> + if (hdmi_phy->conf && hdmi_phy->conf->tz_enabled)
> + arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904,
> + 0x8000, 0, 0, 0, 0, 0, &res);
> + else
> + regmap_update_bits(hdmi->sys_regmap,
> +hdmi->sys_offset + HDMI_SYS_CFG20,
> +HDMI_PSECUR_EN, enable ? 0 : HDMI_PSECUR_EN);
>
> regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
> HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
> @@ -1437,6 +1443,7 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi
> *hdmi,
> struct platform_device *cec_pdev;
> struct regmap *regmap;
> struct resource *mem;
> + const char *phy_name;
> int ret;
>
> ret = mtk_hdmi_get_all_clk(hdmi, np);
> @@ -1445,9 +1452,20 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi
> *hdmi,
> return ret;
> }
>
> + ret = of_property_read_string(np, "phy-names", &phy_name);
> + if (ret < 0) {
> + dev_err(dev, "Failed to read phy-names: %d\n", ret);
> + return ret;
> + }
> + hdmi->phy = devm_phy_get(dev, phy_name);
> + if (IS_ERR(hdmi->phy)) {
> + ret = PTR_ERR(hdmi->phy);
> + dev_err(dev, "Failed to get HDMI PHY: %d\n", ret);
> + return ret;
> + }
> +
> /* The CEC module handles HDMI hotplug detection */
> - cec_np = of_find_compatible_node(np->parent, NULL,
> - "mediatek,mt8173-cec");
> + cec_np = of_parse_phandle(np, "cec", 0);
> if (!cec_np) {
> dev_err(dev, "Failed to find CEC node\n");
> return -EINVAL;
> @@ -1486,8 +1504,14 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi
> *hdmi,
> return PTR_ERR(hdmi->regs);
>
> remote = of_graph_get_remote_node(np, 1, 0);
> - if (!remote)
> - return -EINVAL;
> + if (!remote) {
> + i2c_np = of_parse_phandle(np, "ddc-i2c-bus", 0);
> + if (!i2c_np) {
> + dev_err(dev, "Failed to find ddc-i2c-bus node\n");
> + return -EINVAL
Re: [PATCH v1 7/7] drm/mediatek: config component output by device node port
Hi, Bibby:
On Mon, 2018-05-14 at 15:52 +0800, Bibby Hsieh wrote:
> We can select output component by device node port.
> Main path default output component is DSI.
> External path default output component is DPI.
Config the HW routine by device tree is a good idea. But I would like
this to be more general. My idea is:
1. Each component has one or two endpoint in device tree. The first and
the last has one, and the others has two.
2. Remove mt_mtk_ddp_main[] and mt_mtk_ddp_ext[], use multiple
link list (One display path has one link list, two display path has two
link list) to generate it by parsing device tree in mtk_drm_probe().
Stu has planed to do this in future. You could wait him or you could do
this first.
Regards,
CK
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 37
> ++
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 4 ++--
> 2 files changed, 35 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index f4fb86ab7b8d..05333769d862 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -24,6 +24,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "mtk_drm_crtc.h"
> #include "mtk_drm_ddp.h"
> @@ -133,7 +135,7 @@ static const struct drm_mode_config_funcs
> mtk_drm_mode_config_funcs = {
> .atomic_commit = mtk_atomic_commit,
> };
>
> -static const enum mtk_ddp_comp_id mt2701_mtk_ddp_main[] = {
> +static enum mtk_ddp_comp_id mt2701_mtk_ddp_main[] = {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_RDMA0,
> DDP_COMPONENT_COLOR0,
> @@ -141,12 +143,12 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_main[]
> = {
> DDP_COMPONENT_DSI0,
> };
>
> -static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
> +static enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
> DDP_COMPONENT_RDMA1,
> DDP_COMPONENT_DPI0,
> };
>
> -static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> +static enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_AAL,
> @@ -157,7 +159,7 @@ static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] =
> {
> DDP_COMPONENT_PWM0,
> };
>
> -static const enum mtk_ddp_comp_id mt8173_mtk_ddp_ext[] = {
> +static enum mtk_ddp_comp_id mt8173_mtk_ddp_ext[] = {
> DDP_COMPONENT_OVL1,
> DDP_COMPONENT_COLOR1,
> DDP_COMPONENT_GAMMA,
> @@ -411,6 +413,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
>
> /* Iterate over sibling DISP function blocks */
> for_each_child_of_node(dev->of_node->parent, node) {
> + struct device_node *port, *ep, *remote;
> const struct of_device_id *of_id;
> enum mtk_ddp_comp_type comp_type;
> int comp_id;
> @@ -470,6 +473,32 @@ static int mtk_drm_probe(struct platform_device *pdev)
>
> private->ddp_comp[comp_id] = comp;
> }
> +
> + if (comp_type != MTK_DSI && comp_type != MTK_DPI) {
> + port = of_graph_get_port_by_id(node, 0);
> + if (!port)
> + continue;
> + ep = of_get_child_by_name(port, "endpoint");
> + of_node_put(port);
> + if (!ep)
> + continue;
> + remote = of_graph_get_remote_port_parent(ep);
> + of_node_put(ep);
> + if (!remote)
> + continue;
> + of_id = of_match_node(mtk_ddp_comp_dt_ids, remote);
> + if (!of_id)
> + continue;
> + comp_type = (enum mtk_ddp_comp_type)of_id->data;
> + for (i = 0; i < private->data->main_len - 1; i++)
> + if (private->data->main_path[i] == comp_id)
> + private->data->main_path[i + 1] =
> + mtk_ddp_comp_get_id(node, comp_type);
> + for (i = 0; i < private->data->ext_len - 1; i++)
> + if (private->data->ext_path[i] == comp_id)
> + private->data->ext_path[i + 1] =
> + mtk_ddp_comp_get_id(node, comp_type);
> + }
> }
>
> if (!private->mutex_node) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index c3378c452c0a..2bcba8eb06f4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -29,9 +29,9 @@ struct drm_property;
> struct regmap;
>
> struct mtk_mmsys_driver_data {
> - const enum mtk_ddp_comp_id *main_path;
> + enum mtk_ddp_comp_id *ma
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #14 from Michel Dänzer --- (In reply to tempel.julian from comment #13) > So there might be an actual connection to pageflipping? Yeah, the problem seems to be a bad interaction between page flipping and cursor updates. FWIW, page flipping can be disabled with xf86-video-amdgpu as well, with Option "EnablePageFlip" "false" -- 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
About the DRM Mediatek patches
Hi, Ulrich, I found two DRM-Mediatek related patches as below from you. https://patchwork.kernel.org/patch/10009039/ https://patchwork.kernel.org/patch/10009049/ Did you have any plans to send the new version (There are some comments from Philipp)? If not, may I send the new version? Thanks. -- Bibby ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106671] Frequent lock ups for AMD RX 550 graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=106671 Michel Dänzer changed: What|Removed |Added Component|Driver/AMDgpu |Drivers/Gallium/radeonsi Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org Version|unspecified |18.0 QA Contact|xorg-t...@lists.x.org |dri-devel@lists.freedesktop ||.org Product|xorg|Mesa --- Comment #1 from Michel Dänzer --- Please attach the corresponding full Xorg log and dmesg output. This is most likely between Mesa and the kernel; xf86-video-amdgpu doesn't contain any GPU specific rendering code which could cause hangs. I'd recommend trying latest upstream versions of Mesa (18.1) and the kernel, and if it still happens, also try getting the current microcode files from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu . -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 5/7] drm/mediatek: implement connection from BLS to DPI0
Hi, Bibby:
On Mon, 2018-05-14 at 15:52 +0800, Bibby Hsieh wrote:
> Modify display driver to support connection from BLS to DPI.
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 8130f3dab661..289a68c6731f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -35,6 +35,7 @@
> #define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030
> #define DISP_REG_CONFIG_OUT_SEL 0x04c
> #define DISP_REG_CONFIG_DSI_SEL 0x050
> +#define DISP_REG_CONFIG_DPI_SEL 0x064
>
> #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> #define DISP_REG_MUTEX(n)(0x24 + 0x20 * (n))
> @@ -84,7 +85,10 @@
>
> #define OVL_MOUT_EN_RDMA 0x1
> #define BLS_TO_DSI_RDMA1_TO_DPI1 0x8
> +#define BLS_TO_DPI_RDMA1_TO_DSI 0x2
> #define DSI_SEL_IN_BLS 0x0
> +#define DPI_SEL_IN_BLS 0x0
> +#define DSI_SEL_IN_RDMA 0x1
>
> struct mtk_disp_mutex {
> int id;
> @@ -189,9 +193,17 @@ static void mtk_ddp_sout_sel(void __iomem *config_regs,
>enum mtk_ddp_comp_id cur,
>enum mtk_ddp_comp_id next)
> {
> - if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
> + if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
> writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
> config_regs + DISP_REG_CONFIG_OUT_SEL);
When BLS->DIP0, DISP_REG_CONFIG_DSI_SEL and DISP_REG_CONFIG_DPI_SEL are
configured. I think these two register should be configured when
BLS->DSI0.
Regards,
CK
> + } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> + writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
> +config_regs + DISP_REG_CONFIG_OUT_SEL);
> + writel_relaxed(DSI_SEL_IN_RDMA,
> +config_regs + DISP_REG_CONFIG_DSI_SEL);
> + writel_relaxed(DPI_SEL_IN_BLS,
> +config_regs + DISP_REG_CONFIG_DPI_SEL);
> + }
> }
>
> void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
Hi Kieran, Morimoto-san,
On Fri, Apr 27, 2018 at 6:57 PM, Kieran Bingham
wrote:
> The DU1 external dot clock is provided by the fixed frequency clock
> generator X21, while the DU0 and DU3 clocks are provided by the
> programmable Versaclock5 clock generator.
>
> Enable the clocks, and the HDMI encoder for the M3-N Salvator-X board
> and hook it up to the HDMI connector.
>
> Based on patches from Takeshi Kihara
>
> Signed-off-by: Kieran Bingham
>
> ---
> v2:
> - Remove LVDS clocks from DU node
> - Merge DU Clocks and HDMI enablement
> ---
> .../boot/dts/renesas/r8a77965-salvator-x.dts | 28 +++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
> b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
> index 75d890d91df9..340a3c72b65a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
> @@ -19,3 +19,31 @@
> reg = <0x0 0x4800 0x0 0x7800>;
> };
> };
> +
> +&du {
> + clocks = <&cpg CPG_MOD 724>,
> +<&cpg CPG_MOD 723>,
> +<&cpg CPG_MOD 721>,
> +<&versaclock5 1>,
> +<&x21_clk>,
> +<&versaclock5 2>;
> + clock-names = "du.0", "du.1", "du.3",
> + "dclkin.0", "dclkin.1", "dclkin.3";
> +};
> +
> +&hdmi0 {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + reg = <1>;
> + rcar_dw_hdmi0_out: endpoint {
> + remote-endpoint = <&hdmi0_con>;
> + };
> + };
> + };
> +};
> +
> +&hdmi0_con {
> + remote-endpoint = <&rcar_dw_hdmi0_out>;
> +};
I think the hdmi0 and hdmi0_con parts can be moved to salvator-common.dtsi.
Can we do that now (with stubs?), or does this have to wait until r8a77965 has
received HDMI sound support?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 3/7] drm/mediatek: add dpi driver for mt2701 and mt7623
Hi, Bibby:
On Mon, 2018-05-14 at 15:52 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> This patch adds dpi driver suppot for both mt2701 and mt7623.
> And also support other (existing or future) chips that use
> the same binding and driver.
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 24 ++--
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
> 2 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 2b8b34c72697..e1af1d0d213d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -640,8 +640,7 @@ static int mtk_dpi_bind(struct device *dev, struct device
> *master, void *data)
> }
> drm_encoder_helper_add(&dpi->encoder, &mtk_dpi_encoder_helper_funcs);
>
> - /* Currently DPI0 is fixed to be driven by OVL1 */
> - dpi->encoder.possible_crtcs = BIT(1);
> + dpi->encoder.possible_crtcs = BIT(0) | BIT(1);
This modification influence not only mt2701, but also mt8173. So move
this to an independent patch.
Regards,
CK
> dpi->encoder.bridge->encoder = &dpi->encoder;
> ret = drm_bridge_attach(&dpi->encoder, dpi->encoder.bridge, NULL);
> if (ret) {
> @@ -690,12 +689,33 @@ static unsigned int mt8173_calculate_factor(int clock)
> return 2 * 3;
> }
>
> +static unsigned int mt2701_calculate_factor(int clock)
> +{
> + if (clock <= 64000)
> + return 16;
> + else if (clock <= 128000)
> + return 8;
> + else if (clock <= 256000)
> + return 4;
> + else
> + return 2;
> +}
> +
> static const struct mtk_dpi_conf mt8173_conf = {
> .cal_factor = mt8173_calculate_factor,
> .reg_h_fre_con = 0xe0,
> };
>
> +static const struct mtk_dpi_conf mt2701_conf = {
> + .cal_factor = mt2701_calculate_factor,
> + .reg_h_fre_con = 0xb0,
> + .edge_sel_en = true,
> +};
> +
> static const struct of_device_id mtk_dpi_of_ids[] = {
> + { .compatible = "mediatek,mt2701-dpi",
> + .data = &mt2701_conf,
> + },
> { .compatible = "mediatek,mt8173-dpi",
> .data = &mt8173_conf,
> },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index a2ca90fc403c..f4fb86ab7b8d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -372,6 +372,7 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> { .compatible = "mediatek,mt8173-disp-ufoe", .data = (void
> *)MTK_DISP_UFOE },
> { .compatible = "mediatek,mt2701-dsi",.data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8173-dsi",.data = (void *)MTK_DSI },
> + { .compatible = "mediatek,mt2701-dpi",.data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt8173-dpi",.data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt2701-disp-mutex", .data = (void
> *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt8173-disp-mutex", .data = (void
> *)MTK_DISP_MUTEX },
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 6/7] drm/mediatek: add a error return value when clock driver has been prepared
Hi, Bibby: On Mon, 2018-05-14 at 15:52 +0800, Bibby Hsieh wrote: > DRM driver get the comp->clk by of_clk_get(), we only > assign NULL to comp->clk when error happened, but do > not return the error number. > Reviewed-by: CK Hu > Signed-off-by: Bibby Hsieh > --- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > index 4672317e3ad1..d38a5303f8fc 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > @@ -283,7 +283,7 @@ int mtk_ddp_comp_init(struct device *dev, struct > device_node *node, > comp->irq = of_irq_get(node, 0); > comp->clk = of_clk_get(node, 0); > if (IS_ERR(comp->clk)) > - comp->clk = NULL; > + return PTR_ERR(comp->clk); > > /* Only DMA capable components need the LARB property */ > comp->larb_dev = NULL; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/sun4i: mark PM functions as __maybe_unused
On Fri, May 25, 2018 at 05:50:08PM +0200, Arnd Bergmann wrote:
> Disabling CONFIG_PM produces a compile time warning when these
> functions are not referenced:
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1072:12: error:
> 'sun6i_dsi_runtime_suspend' defined but not used [-Werror=unused-function]
> static int sun6i_dsi_runtime_suspend(struct device *dev)
> ^
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1043:12: error:
> 'sun6i_dsi_runtime_resume' defined but not used [-Werror=unused-function]
> static int sun6i_dsi_runtime_resume(struct device *dev)
> ^~~~
>
> Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller
> support")
> Signed-off-by: Arnd Bergmann
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #15 from tempel.jul...@gmail.com --- I just tried that option with the xf86 amdgpu DDX driver and as expected, stuttering disappears in exchange for tearing close to the very top of the screen. I'm really glad you could confirm the issue, the absent reports of other users really worried me that I'd have to live forever with 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
Re: [PATCH 2/8] drm/amdgpu: fix 32-bit build warning
On Fri, May 25, 2018 at 6:50 PM, Arnd Bergmann wrote:
> Casting a pointer to a 64-bit type causes a warning on 32-bit targets:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:473:24: error: cast from
> pointer to integer of different size [-Werror=pointer-to-int-cast]
> lower_32_bits((uint64_t)wptr));
> ^
> drivers/gpu/drm/amd/amdgpu/amdgpu.h:1701:53: note: in definition of macro
> 'WREG32'
> #define WREG32(reg, v) amdgpu_mm_wreg(adev, (reg), (v), 0)
> ^
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:473:10: note: in expansion
> of macro 'lower_32_bits'
> lower_32_bits((uint64_t)wptr));
> ^
>
> The correct method is to cast to 'uintptr_t'.
>
> Fixes: d5a114a6c5f7 ("drm/amdgpu: Add GFXv9 kfd2kgd interface functions")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> index 8f37991df61b..f0c0d3953f69 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
> @@ -470,9 +470,9 @@ static int kgd_hqd_load(struct kgd_dev *kgd, void *mqd,
> uint32_t pipe_id,
> WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_HI),
>upper_32_bits(guessed_wptr));
> WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_POLL_ADDR),
> - lower_32_bits((uint64_t)wptr));
> + lower_32_bits((uintptr_t)wptr));
> WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_POLL_ADDR_HI),
> - upper_32_bits((uint64_t)wptr));
> + upper_32_bits((uintptr_t)wptr));
> WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_PQ_WPTR_POLL_CNTL1),
>get_queue_mask(adev, pipe_id, queue_id));
> }
> --
> 2.9.0
>
There is a change scheduled for the next merge window that will cause
this file to not build anymore on 32-bit targets (because the amdkfd
driver is not supported on 32 bit targets).
Never the less I'm taking the patch for good measure.
This patch is:
Reviewed-by: Oded Gabbay
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/12] dt-bindings: tc358754: add DT bindings
Hi Maciej,
Thank you for the patch.
On Monday, 28 May 2018 12:47:11 EEST Maciej Purski wrote:
> The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
> Bindings describe power supplies, reset gpio and video interfaces.
>
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Maciej Purski
> ---
> .../bindings/display/bridge/toshiba,tc358764.txt | 42 +++
> 1 file changed, 42 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt new
> file mode 100644
> index 000..d09bdc2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> @@ -0,0 +1,42 @@
> +TC358764 MIPI-DSI to LVDS panel bridge
> +
> +Required properties:
> + - compatible: "toshiba,tc358764"
> + - reg: the virtual channel number of a DSI peripheral
> + - vddc-supply: core voltage supply
> + - vddio-supply: I/O voltage supply
> + - vddmipi-supply: MIPI voltage supply
> + - vddlvds133-supply: LVDS1 3.3V voltage supply
> + - vddlvds112-supply: LVDS1 1.2V voltage supply
That's a lot of power supplies. Could some of them be merged together ? See
https://patchwork.freedesktop.org/patch/216058/ for an earlier discussion on
the same subject.
> + - reset-gpios: a GPIO spec for the reset pin
> +
> +The device node can contain zero to two 'port' child nodes, each with one
> +child
> +'endpoint' node, according to the bindings defined in [1].
> +The following are properties specific to those nodes.
> +
> +port:
> + - reg: (required) can be 0 for DSI port or 1 for LVDS port;
This seems pretty vague to me. It could be read as meaning that ports are
completely optional, and that the port number you list can be used, but that
something else could be used to.
Let's make the port nodes mandatory. I propose the following.
Required nodes:
The TC358764 has DSI and LVDS ports whose connections are described using the
OF graph bindings defined in Documentation/devicetree/bindings/graph.txt. The
device node must contain one 'port' child node per DSI and LVDS port. The port
nodes are numbered as follows.
Port Number
---
DSI Input 0
LVDS Output 1
Each port node must contain endpoint nodes describing the hardware
connections.
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + bridge@0 {
> + reg = <0>;
> + compatible = "toshiba,tc358764";
> + vddc-supply = <&vcc_1v2_reg>;
> + vddio-supply = <&vcc_1v8_reg>;
> + vddmipi-supply = <&vcc_1v2_reg>;
> + vddlvds133-supply = <&vcc_3v3_reg>;
> + vddlvds112-supply = <&vcc_1v2_reg>;
> + reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@1 {
> + reg = <1>;
> + lvds_ep: endpoint {
> + remote-endpoint = <&panel_ep>;
> + };
> + };
> + };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106658] 2500u HP Envy x360 Hangs randomly
https://bugs.freedesktop.org/show_bug.cgi?id=106658 Michel Dänzer changed: What|Removed |Added Attachment #139775|text/x-log |text/plain mime type|| -- 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 199493] no audio over HDMI with amdgpu.dc=1 (on R9 380X)
https://bugzilla.kernel.org/show_bug.cgi?id=199493 --- Comment #6 from har...@gmx.de --- This issue (no HDMI sound with amdgpu_dc=1) still exist in 4.17.0-rc7. The following warning is the first of many others in dmesg log: [ 10.067233] WARNING: CPU: 11 PID: 367 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x102/0x150 [amdgpu] [ 10.067235] Modules linked in: amdgpu(+) intel_powerclamp binfmt_misc coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc btusb btrtl btbcm btintel bluetooth wmi_bmof chash snd_hda_codec_hdmi i2c_algo_bit gpu_sched drbg ttm snd_hda_intel drm_kms_helper ansi_cprng snd_hda_codec joydev snd_hwdep syscopyarea sysfillrect snd_hda_core sysimgblt fb_sys_fops ecdh_generic snd_pcm drm snd_timer snd aesni_intel soundcore aes_x86_64 crypto_simd cryptd glue_helper sg lpc_ich mfd_core evdev shpchp wmi button uinput ip_tables x_tables autofs4 hid_generic usbhid hid ext4 crc32c_generic crc16 mbcache jbd2 fscrypto sd_mod xhci_pci xhci_hcd ahci crc32c_intel libahci ehci_pci libata ehci_hcd e100 i2c_i801 scsi_mod mii usbcore [ 10.067346] CPU: 11 PID: 367 Comm: systemd-udevd Not tainted 4.17.0-rc7 #2 [ 10.067427] RIP: 0010:generic_reg_update_ex+0x102/0x150 [amdgpu] [ 10.067429] RSP: 0018:b8ed4071f3f8 EFLAGS: 00010246 [ 10.067433] RAX: b8ed4071f418 RBX: 8e337604cf00 RCX: [ 10.067435] RDX: RSI: RDI: 8e339fb96e00 [ 10.067437] RBP: b8ed4071f468 R08: R09: [ 10.067438] R10: b8ed4071f480 R11: 0001 R12: 0001 [ 10.067440] R13: R14: 8e339aa0e000 R15: 8e335efe8188 [ 10.067443] FS: 7fa4782c88c0() GS:8e33a740() knlGS: [ 10.067445] CS: 0010 DS: ES: CR0: 80050033 [ 10.067447] CR2: 7fa4782f7a8c CR3: 0005dd52c003 CR4: 000606e0 [ 10.067449] Call Trace: [ 10.067544] dce110_stream_encoder_update_hdmi_info_packets+0x357/0x550 [amdgpu] [ 10.067628] dce110_apply_ctx_to_hw+0x6e5/0x860 [amdgpu] [ 10.067718] dc_commit_state+0x2de/0x540 [amdgpu] [ 10.067792] ? set_freesync_on_streams.part.6+0x4d/0x250 [amdgpu] [ 10.067867] ? mod_freesync_set_user_enable+0x11d/0x150 [amdgpu] [ 10.067951] amdgpu_dm_atomic_commit_tail+0x35b/0xd10 [amdgpu] [ 10.067967] ? drm_atomic_helper_swap_state+0x25a/0x380 [drm_kms_helper] [ 10.067980] ? _raw_spin_unlock+0x24/0x30 [ 10.067994] commit_tail+0x3a/0x70 [drm_kms_helper] [ 10.068004] drm_atomic_helper_commit+0x11c/0x130 [drm_kms_helper] [ 10.068015] restore_fbdev_mode_atomic+0x1b2/0x220 [drm_kms_helper] [ 10.068040] drm_fb_helper_restore_fbdev_mode_unlocked+0x47/0x90 [drm_kms_helper] [ 10.068050] drm_fb_helper_set_par+0x29/0x50 [drm_kms_helper] [ 10.068055] fbcon_init+0x4de/0x680 [ 10.068066] visual_init+0xcf/0x130 [ 10.068072] do_bind_con_driver+0x1ef/0x3f0 [ 10.068083] do_take_over_console+0x7b/0x180 [ 10.068090] do_fbcon_takeover+0x58/0xb0 [ 10.068095] notifier_call_chain+0x45/0x70 [ 10.068102] blocking_notifier_call_chain+0x44/0x60 [ 10.068108] register_framebuffer+0x294/0x350 [ 10.068126] __drm_fb_helper_initial_config_and_unlock+0x229/0x490 [drm_kms_helper] [ 10.068196] amdgpu_fbdev_init+0xc4/0xf0 [amdgpu] [ 10.068257] amdgpu_device_init+0xd60/0x1460 [amdgpu] [ 10.068268] ? kmalloc_order+0x18/0x40 [ 10.068327] amdgpu_driver_load_kms+0x78/0x200 [amdgpu] [ 10.068349] drm_dev_register+0x131/0x1c0 [drm] [ 10.068409] amdgpu_pci_probe+0x13f/0x200 [amdgpu] [ 10.068421] pci_device_probe+0xc8/0x140 [ 10.068429] driver_probe_device+0x302/0x470 [ 10.068436] __driver_attach+0xb9/0xe0 [ 10.068440] ? driver_probe_device+0x470/0x470 [ 10.068444] ? driver_probe_device+0x470/0x470 [ 10.068447] bus_for_each_dev+0x76/0xc0 [ 10.068455] bus_add_driver+0x164/0x260 [ 10.068459] ? 0xc0de5000 [ 10.068464] driver_register+0x57/0xc0 [ 10.068467] ? 0xc0de5000 [ 10.068471] do_one_initcall+0x5d/0x1e3 [ 10.068478] ? _cond_resched+0x15/0x40 [ 10.068483] ? kmem_cache_alloc_trace+0x18e/0x1e0 [ 10.068487] ? do_init_module+0x22/0x201 [ 10.068493] do_init_module+0x5b/0x201 [ 10.068498] load_module+0x21f8/0x2a50 [ 10.068511] ? ima_post_read_file+0x102/0x110 [ 10.068530] ? __do_sys_finit_module+0xe9/0x110 [ 10.068533] __do_sys_finit_module+0xe9/0x110 [ 10.068550] do_syscall_64+0x49/0xe0 [ 10.068555] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 10.068558] RIP: 0033:0x7fa477c098f9 [ 10.068560] RSP: 002b:7fffe9e1bbb8 EFLAGS: 0246 ORIG_RAX: 0139 [ 10.068563] RAX: ffda RBX: 557789eac330 RCX: 7fa477c098f9 [ 10.068565] RDX: RSI: 557789edf2b0 RDI: 0018 [ 10.068567] RBP: 557789edf2b0 R08: R09: [ 10.068569] R10: 0018 R11: 0246 R12: 0
[Bug 103047] lighting render issue in i915
https://bugs.freedesktop.org/show_bug.cgi?id=103047 --- Comment #3 from Steven Noonan --- Still running into this on another machine with Kaby Lake GT2 graphics. Can anyone take a look please? -- 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 0/6] drm/omap: Module parameter for display order configuration
On Wed, 21 Mar 2018 12:08:25 +0200 Peter Ujfalusi wrote: > Hi, > > Changes since v1: > - rebased it on drm-next > - Dropped the devm_kzalloc conversion patch > > Changes since RFC: > - Comments from Laurent have been addressed: > - Get alias ID once and store it for later use in sorting > - Commit message updated for 'drm/omap: Manage the usable omap_dss_device > list >within omap_drm_private' patch > - I have kept the first patch to convert to use devm_kzalloc for the private > struct as I still think it is as correct as the way Laurent is proposing. > > The series adds support for changing the order of the displays defined by DT > display aliases. > > The motivation to do such a thing is that for example the fb emulation is > treating the first display/crtc as the 'main' display and will create the > fb emulation based on the first display's properties. Hi, catering for fbdev seems strange to me. But if you do care, why is this a driver-specific option instead of a generic DRM fb emulation configuration option? > There are many custom applications using DRM directly and they assume that the > first connector is the 'main' display. This is very unfortunate, but I still think it would be better to fix all those apps than patch kernel drivers one at a time to cater for user preferences with driver-specific kernel options. > Afaik weston provides no means either to change the 'main/preferred' display. Please, do not use Weston as justification for this. If you have window positioning problems in Weston, please come talk to us on #wayland or wayland-devel@, so we can discuss what you *actually* need. Weston's behaviour in this respect has not been even defined yet, which makes a kernel option to work around it ever more awkward. The reason why Weston lacks this kind of configurability is that no-one has needed it yet, I mean, come forth with a proposal, as far as I can recall. If people keep working around it elsewhere, it is unlikely Weston ever gets it. > It should be the work of user space application (except the fb emulation) to > somehow deal with the 'main' display selection for their needs, but > unfortunately they are not capable of diong so for some reason. Aside from Weston, which apps are these? > We have boards with LCD panel and HDMI for example and in DT the LCD is set as > display0, but in certain useage scenarios it is desired to have the HDMI as > the > 'main' display instead of the LCD. > > With the kernel cmd line parameter it is possible to change the pre defined > order without recompiling the kernel/DT. > > If the board have two active displays: > 0 - LCD > 1 - HDMI > then: > omapdrm.displays=0,1 - represents the original order (LCD, HDMI) > omapdrm.displays=1,0 - represents reverse order (HDMI, LCD) > omapdrm.displays=0 - only the LCD is enabled > omapdrm.displays=1 - only the HDMI is enabled > omapdrm.displays=-1 - disable all displays > > The first 6 patch of the series is doing some generic clean up and prepares > the > code so the display ordering is going to be easy to add. Libweston has just received a bunch of patches rewriting the whole output configuration API. Now it allows force-enabling outputs and programming shared-CRTC clone mode. A next logical step would be to bring output layout configuration out of libweston and into weston, so that the layout could actually be configured at all. One could introduce the concept of a "primary" output at the same time and fix the window manager to do something useful with it. Thanks, pq > > Regards, > Peter > --- > Peter Ujfalusi (6): > drm/omap: Allocate drm_device earlier and unref it as last step > drm/omap: Manage the usable omap_dss_device list within > omap_drm_private > drm/omap: Separate the dssdevs array setup from the connect function > drm/omap: Do dss_device (display) ordering in omap_drv.c > drm/omap: dss: Remove display ordering from dss/display.c > drm/omap: Add kernel parameter to specify the desired display order > > drivers/gpu/drm/omapdrm/dss/display.c | 15 +-- > drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 +- > drivers/gpu/drm/omapdrm/omap_drv.c| 225 > +- > drivers/gpu/drm/omapdrm/omap_drv.h| 3 + > 4 files changed, 176 insertions(+), 70 deletions(-) > pgpTg8WTq1lak.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103047] lighting render issue in i915
https://bugs.freedesktop.org/show_bug.cgi?id=103047 Steven Noonan changed: What|Removed |Added Version|17.2|18.0 --- Comment #4 from Steven Noonan --- Bumping version as well, since this is hitting me on 18.0.4 and 18.1.0. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] amdkfd next 4.18
Hi Dave, Final amdkfd pull request for 4.18: - Build amdkfd's related files inside amdgpu only if amdkfd is built - Fix compile warning - Print info message in case ASIC is not supported by amdkfd Thanks, Oded The following changes since commit dd41fb8547c2422f3a3a75e7226525e8bba9381c: Merge branch 'drm-next-4.18' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-05-25 10:28:33 +1000) are available in the Git repository at: git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-next-2018-05-28 for you to fetch changes up to ebe1d22b57b86b6739f2739b5a0f52435596d84d: drm/amdgpu: fix 32-bit build warning (2018-05-25 17:50:09 +0200) Arnd Bergmann (1): drm/amdgpu: fix 32-bit build warning Oded Gabbay (1): drm/amdgpu: conditionally compile amdgpu's amdkfd files Tom Stellard (1): drm/amdgpu: Use dev_info() to report amdkfd is not supported for this ASIC drivers/gpu/drm/amd/amdgpu/Makefile | 13 -- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 49 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 12 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 4 +- 4 files changed, 66 insertions(+), 12 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/8] drm/bridge: fix dependency for lvds-encoder
On Mon, May 28, 2018 at 10:06 AM, Daniel Vetter wrote:
> On Mon, May 28, 2018 at 10:02 AM, Laurent Pinchart
> wrote:
>> Hi Arnd,
>>
>> Thank you for the patch.
>>
>> On Friday, 25 May 2018 18:50:14 EEST Arnd Bergmann wrote:
>>> The DRM panel bridge code is built into the kms helpers module, so we
>>> get a link error when trying to use it from a built-in driver while the
>>> kms helper is a loadable module:
>>>
>>> drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
>>> lvds-encoder.c:(.text+0x124): undefined reference to
>>> `devm_drm_panel_bridge_add'
>>>
>>> This adds a the same dependency in the lvds-encoder that we use for all
>>> the other users of the panel bridge. I did not bisect the problem, but
>>> from inspection it seems to date back to the patch that separated out
>>> the panel bridge from lvds encoder.
>>>
>>> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the
>>> lvds-encoder bridge.") Signed-off-by: Arnd Bergmann
>>> ---
>>> drivers/gpu/drm/bridge/Kconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>>> index 6caa47834194..cf47bfa7a050 100644
>>> --- a/drivers/gpu/drm/bridge/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/Kconfig
>>> @@ -46,6 +46,7 @@ config DRM_DUMB_VGA_DAC
>>> config DRM_LVDS_ENCODER
>>> tristate "Transparent parallel to LVDS encoder support"
>>> depends on OF
>>> + select DRM_KMS_HELPER
>>> select DRM_PANEL_BRIDGE
>>> help
>>> Support for transparent parallel to LVDS encoders that don't require
>>
>> Wouldn't it be better to apply the following ?
>>
>> config DRM_PANEL_BRIDGE
>> def_bool y
>> depends on DRM_BRIDGE
>> - depends on DRM_KMS_HELPER
>> + select DRM_KMS_HELPER
>> select DRM_PANEL
>> help
>>DRM bridge wrapper of DRM panels
>>
>> Otherwise you'll potentially have to patch every user of DRM_PANEL_BRIDGE as
>> done in this patch.
>
> Select isn't recursive, so this won't work unfortunately :-/
The problem is a bit different: select *is* recursive, which is part of the
reason we normally try to avoid it (it gets hard to disable certain
symbols or turn them into modules when there are lots of things selecting
them).
However, DRM_PANEL_BRIDGE is a silent 'bool' symbol that is
always enabled when DRM_BRIDGE is enabled. Making it 'select
DRM_KMS_HELPER' would lead to DRM_KMS_HELPER always
being built-in even if all other DRM drivers are configured as
loadable modules! Note these Makefile line in drivers/gpu/drm:
drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
The intention is definitely that drm_kms_helper can be a loadable module,
(it cannot be built-in when CONFIG_DRM=m) and the panel bridge
is simply a component that gets linked into it, as of commit 123387d5efa6
("drm/bridge: Build the panel wrapper in drm_kms_helper").
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/12] drm/exynos: move connector creation to attach callback
The current implementation assumes that the only possible peripheral
device for DSIM is a panel. Using an output bridge should also be
possible.
If an output bridge in available, don't create a new connector.
Instead add bridge to DSIM encdoer in dsi_host_attach().
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 35 +
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 94460b0..8957faf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1498,7 +1498,28 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
struct mipi_dsi_device *device)
{
struct exynos_dsi *dsi = host_to_dsi(host);
- struct drm_device *drm = dsi->connector.dev;
+ struct drm_encoder *encoder = &dsi->encoder;
+ struct drm_device *drm = encoder->dev;
+ struct drm_bridge *out_bridge;
+
+ out_bridge = of_drm_find_bridge(device->dev.of_node);
+ if (out_bridge) {
+ drm_bridge_attach(encoder, out_bridge, NULL);
+ } else {
+ int ret = exynos_dsi_create_connector(encoder);
+
+ if (ret) {
+ DRM_ERROR("failed to create connector ret = %d\n", ret);
+ drm_encoder_cleanup(encoder);
+ return ret;
+ }
+
+ dsi->panel = of_drm_find_panel(device->dev.of_node);
+ if (dsi->panel) {
+ drm_panel_attach(dsi->panel, &dsi->connector);
+ dsi->connector.status = connector_status_connected;
+ }
+ }
/*
* This is a temporary solution and should be made by more generic way.
@@ -1517,11 +1538,6 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- dsi->panel = of_drm_find_panel(device->dev.of_node);
- if (dsi->panel) {
- drm_panel_attach(dsi->panel, &dsi->connector);
- dsi->connector.status = connector_status_connected;
- }
exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
@@ -1650,13 +1666,6 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
if (ret < 0)
return ret;
- ret = exynos_dsi_create_connector(encoder);
- if (ret) {
- DRM_ERROR("failed to create connector ret = %d\n", ret);
- drm_encoder_cleanup(encoder);
- return ret;
- }
-
if (dsi->mic_bridge_node) {
mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
if (mic_bridge)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/12] Add TOSHIBA TC358764 DSI/LVDS bridge driver
Hi all, this patchset is a next attempt to add the tc358764 driver. The previous one can be found here: https://lists.freedesktop.org/archives/dri-devel/2014-February/053705.html Back then, TC358764 was added as a panel driver. The bridge is supposed to be a DSI peripheral. Currently exynos_dsi accepts only panels as its peripherals. Therefore, some logic in exynos_dsi had to be ammended. That is implemented in first 4 patches. Apart from the driver this patchset adds support for BOE HV070WSA-100 panel, which is used by TC358764 and dts nodes to exynos5250.dtsi and exynos5250-arndale.dtsi. Best regards, Maciej Purski Maciej Purski (12): drm/exynos: rename "bridge_node" to "mic_bridge_node" drm/exynos: move pm_runtime_get_sync() to exynos_dsi_init() drm/exynos: move connector creation to attach callback drm/exynos: add non-panel path to exynos_dsi_enable() panel/hv070wsa-100: add DT bindings drm/panel: add support for BOE HV070WSA-100 panel to simple-panel dt-bindings: tc358754: add DT bindings drm/bridge: tc358764: Add DSI to LVDS bridge driver ARM: dts: exynos5250: add mipi-phy node ARM: dts: exynos5250: add DSI node ARM: dts: exynos5250-arndale: add display regulators ARM: dts: exynos5250-arndale: add dsi and panel nodes .../bindings/display/bridge/toshiba,tc358764.txt | 42 ++ .../bindings/display/panel/boe,hv070wsa-100.txt| 7 + arch/arm/boot/dts/exynos5250-arndale.dts | 63 +++ arch/arm/boot/dts/exynos5250.dtsi | 20 + drivers/gpu/drm/bridge/Kconfig | 7 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/tc358764.c | 547 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 84 ++-- drivers/gpu/drm/panel/panel-simple.c | 25 + 9 files changed, 756 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt create mode 100644 Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt create mode 100644 drivers/gpu/drm/bridge/tc358764.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/12] drm/exynos: move pm_runtime_get_sync() to exynos_dsi_init()
In order to allow bridge drivers to use DSI transfers in their
pre_enable callbacks, pm_runtime_get_sync() should be performed before
exynos_dsi_enable(). DSIM_STATE_ENABLED flag now should not guard
from calling dsi_host_transfer() before enabling.
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 9599e6b..94460b0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1312,6 +1312,7 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
{
const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
+ pm_runtime_get_sync(dsi->dev);
exynos_dsi_reset(dsi);
exynos_dsi_enable_irq(dsi);
@@ -1388,7 +1389,6 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
ret = drm_panel_prepare(dsi->panel);
if (ret < 0) {
dsi->state &= ~DSIM_STATE_ENABLED;
- pm_runtime_put_sync(dsi->dev);
return;
}
@@ -1400,7 +1400,6 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
dsi->state &= ~DSIM_STATE_ENABLED;
exynos_dsi_set_display_enable(dsi, false);
drm_panel_unprepare(dsi->panel);
- pm_runtime_put_sync(dsi->dev);
return;
}
@@ -1566,9 +1565,6 @@ static ssize_t exynos_dsi_host_transfer(struct
mipi_dsi_host *host,
struct exynos_dsi_transfer xfer;
int ret;
- if (!(dsi->state & DSIM_STATE_ENABLED))
- return -EINVAL;
-
if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
ret = exynos_dsi_init(dsi);
if (ret)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/12] ARM: dts: exynos5250: add DSI node
The patch adds common part of DSI node for Exynos5250 platforms.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
arch/arm/boot/dts/exynos5250.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index a63b655..7403b96 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -739,6 +739,20 @@
syscon = <&pmu_system_controller>;
};
+ dsi_0: dsi@1450 {
+ compatible = "samsung,exynos4210-mipi-dsi";
+ reg = <0x1450 0x1>;
+ interrupts = ;
+ samsung,power-domain = <&pd_disp1>;
+ phys = <&mipi_phy 3>;
+ phy-names = "dsim";
+ clocks = <&clock CLK_DSIM0>, <&clock CLK_SCLK_MIPI1>;
+ clock-names = "bus_clk", "sclk_mipi";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
adc: adc@12d1 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D1 0x100>;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/12] drm/exynos: rename "bridge_node" to "mic_bridge_node"
When adding support for peripheral out bridges, the "bridge" name
becomes imprecise as it refers to a different device than the
"out_bridge".
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index eae44fd..9599e6b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -279,7 +279,7 @@ struct exynos_dsi {
struct list_head transfer_list;
const struct exynos_dsi_driver_data *driver_data;
- struct device_node *bridge_node;
+ struct device_node *mic_bridge_node;
};
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
- dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
+ dsi->mic_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
return 0;
}
@@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
struct drm_encoder *encoder = dev_get_drvdata(dev);
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
struct drm_device *drm_dev = data;
- struct drm_bridge *bridge;
+ struct drm_bridge *mic_bridge;
int ret;
drm_encoder_init(drm_dev, encoder, &exynos_dsi_encoder_funcs,
@@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
return ret;
}
- if (dsi->bridge_node) {
- bridge = of_drm_find_bridge(dsi->bridge_node);
- if (bridge)
- drm_bridge_attach(encoder, bridge, NULL);
+ if (dsi->mic_bridge_node) {
+ mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
+ if (mic_bridge)
+ drm_bridge_attach(encoder, mic_bridge, NULL);
}
return mipi_dsi_host_register(&dsi->dsi_host);
@@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device *pdev)
{
struct exynos_dsi *dsi = platform_get_drvdata(pdev);
- of_node_put(dsi->bridge_node);
+ of_node_put(dsi->mic_bridge_node);
pm_runtime_disable(&pdev->dev);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/12] panel/hv070wsa-100: add DT bindings
The patch adds bindings to BOE HV070-WSA WSVGA panel. Bindings are compatible with simple panel bindings. Signed-off-by: Andrzej Hajda Signed-off-by: Maciej Purski --- .../devicetree/bindings/display/panel/boe,hv070wsa-100.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt diff --git a/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt new file mode 100644 index 000..bfc20ac --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt @@ -0,0 +1,7 @@ +BOE HV070WSA-100 7.01" WSVGA TFT LCD panel + +Required properties: +- compatible: should be "boe,hv070wsa-100" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/12] dt-bindings: tc358754: add DT bindings
The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
Bindings describe power supplies, reset gpio and video interfaces.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
.../bindings/display/bridge/toshiba,tc358764.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
new file mode 100644
index 000..d09bdc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
@@ -0,0 +1,42 @@
+TC358764 MIPI-DSI to LVDS panel bridge
+
+Required properties:
+ - compatible: "toshiba,tc358764"
+ - reg: the virtual channel number of a DSI peripheral
+ - vddc-supply: core voltage supply
+ - vddio-supply: I/O voltage supply
+ - vddmipi-supply: MIPI voltage supply
+ - vddlvds133-supply: LVDS1 3.3V voltage supply
+ - vddlvds112-supply: LVDS1 1.2V voltage supply
+ - reset-gpios: a GPIO spec for the reset pin
+
+The device node can contain zero to two 'port' child nodes, each with one
+child
+'endpoint' node, according to the bindings defined in [1].
+The following are properties specific to those nodes.
+
+port:
+ - reg: (required) can be 0 for DSI port or 1 for LVDS port;
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ bridge@0 {
+ reg = <0>;
+ compatible = "toshiba,tc358764";
+ vddc-supply = <&vcc_1v2_reg>;
+ vddio-supply = <&vcc_1v8_reg>;
+ vddmipi-supply = <&vcc_1v2_reg>;
+ vddlvds133-supply = <&vcc_3v3_reg>;
+ vddlvds112-supply = <&vcc_1v2_reg>;
+ reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@1 {
+ reg = <1>;
+ lvds_ep: endpoint {
+ remote-endpoint = <&panel_ep>;
+ };
+ };
+ };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/12] ARM: dts: exynos5250-arndale: add dsi and panel nodes
The patch adds bridge and panel nodes.
It adds also DSI properties specific for arndale board.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
arch/arm/boot/dts/exynos5250-arndale.dts | 39
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 80221fa..6f0b1c4 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -71,6 +71,17 @@
};
};
+ panel: panel {
+ compatible = "boe,hv070wsa-100";
+ power-supply = <&vcc_3v3_reg>;
+ enable-gpios = <&gpd1 3 GPIO_ACTIVE_HIGH>;
+ port {
+ panel_ep: endpoint {
+ remote-endpoint = <&bridge_out_ep>;
+ };
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -476,6 +487,34 @@
};
};
+&dsi_0 {
+ vddcore-supply = <&ldo8_reg>;
+ vddio-supply = <&ldo10_reg>;
+ samsung,pll-clock-frequency = <2400>;
+ samsung,burst-clock-frequency = <32000>;
+ samsung,esc-clock-frequency = <1000>;
+ status = "okay";
+
+ bridge@0 {
+ reg = <0>;
+ compatible = "toshiba,tc358764";
+ vddc-supply = <&vcc_1v2_reg>;
+ vddio-supply = <&vcc_1v8_reg>;
+ vddmipi-supply = <&vcc_1v2_reg>;
+ vddlvds133-supply = <&vcc_3v3_reg>;
+ vddlvds112-supply = <&vcc_1v2_reg>;
+ reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@1 {
+ reg = <1>;
+ bridge_out_ep: endpoint {
+ remote-endpoint = <&panel_ep>;
+ };
+ };
+ };
+};
+
&i2c_2 {
status = "okay";
/* used by HDMI DDC */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/12] drm/panel: add support for BOE HV070WSA-100 panel to simple-panel
The patch adds support for BOE HV070WSA-100 WSVGA 7.01 inch panel
in panel-simple driver. The panel is used in Exynos5250-arndale boards.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/panel/panel-simple.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab4..d5da58d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode boe_hv070wsa_mode = {
+ .clock = 40800,
+ .hdisplay = 1024,
+ .hsync_start = 1024 + 90,
+ .hsync_end = 1024 + 90 + 90,
+ .htotal = 1024 + 90 + 90 + 90,
+ .vdisplay = 600,
+ .vsync_start = 600 + 3,
+ .vsync_end = 600 + 3 + 4,
+ .vtotal = 600 + 3 + 4 + 3,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc boe_hv070wsa = {
+ .modes = &boe_hv070wsa_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 154,
+ .height = 90,
+ },
+};
+
static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
{
.clock = 71900,
@@ -2113,6 +2135,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
}, {
+ .compatible = "boe,hv070wsa-100",
+ .data = &boe_hv070wsa
+ }, {
.compatible = "boe,nv101wxmn51",
.data = &boe_nv101wxmn51,
}, {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] display: panel: Add KOE tx14d24vm1bpa display support (320x240)
Hi,
> Hi Thierry,
>
> > This commit adds support for KOE's 5.7" display.
> >
>
> Thierry, shall I perform some more work on this code, or is it
> eligible for applying to your tree?
Gentle ping. If Thierry is overworked - maybe there is a co-maintainer
so he/she could apply this patch?
>
> Best regards,
> Łukasz
>
> > Signed-off-by: Lukasz Majewski
> > ---
> > .../bindings/display/panel/koe,tx14d24vm1bpa.txt | 42
> > ++
> > drivers/gpu/drm/panel/panel-simple.c | 26
> > ++ 2 files changed, 68 insertions(+) create mode 100644
> > Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> > b/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> > new file mode 100644 index ..be7ac666807b --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> > @@ -0,0 +1,42 @@ +Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x
> > 240) TFT LCD panel +
> > +Required properties:
> > +- compatible: should be "koe,tx14d24vm1bpa"
> > +- backlight: phandle of the backlight device attached to the panel
> > +- power-supply: single regulator to provide the supply voltage
> > +
> > +Required nodes:
> > +- port: Parallel port mapping to connect this display
> > +
> > +This panel needs single power supply voltage. Its backlight is
> > conntrolled +via PWM signal.
> > +
> > +Example:
> > +
> > +
> > +Example device-tree definition when connected to iMX53 based board
> > +
> > + lcd_panel: lcd-panel {
> > + compatible = "koe,tx14d24vm1bpa";
> > + backlight = <&backlight_lcd>;
> > + power-supply = <®_3v3>;
> > +
> > + port {
> > + lcd_panel_in: endpoint {
> > + remote-endpoint =
> > <&lcd_display_out>;
> > + };
> > + };
> > + };
> > +
> > +Then one needs to extend the dispX node:
> > +
> > + lcd_display: disp1 {
> > +
> > + port@1 {
> > + reg = <1>;
> > +
> > + lcd_display_out: endpoint {
> > + remote-endpoint = <&lcd_panel_in>;
> > + };
> > + };
> > + };
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c index
> > d9984bdb5bb5..103b43ce7dee 100644 ---
> > a/drivers/gpu/drm/panel/panel-simple.c +++
> > b/drivers/gpu/drm/panel/panel-simple.c @@ -1268,6 +1268,29 @@ static
> > const struct panel_desc innolux_zj070na_01p = { },
> > };
> >
> > +static const struct display_timing koe_tx14d24vm1bpa_timing = {
> > + .pixelclock = { 558, 585, 620 },
> > + .hactive = { 320, 320, 320 },
> > + .hfront_porch = { 30, 30, 30 },
> > + .hback_porch = { 30, 30, 30 },
> > + .hsync_len = { 1, 5, 17 },
> > + .vactive = { 240, 240, 240 },
> > + .vfront_porch = { 6, 6, 6 },
> > + .vback_porch = { 5, 5, 5 },
> > + .vsync_len = { 1, 2, 11 },
> > + .flags = DISPLAY_FLAGS_DE_HIGH,
> > +};
> > +
> > +static const struct panel_desc koe_tx14d24vm1bpa = {
> > + .timings = &koe_tx14d24vm1bpa_timing,
> > + .num_timings = 1,
> > + .bpc = 6,
> > + .size = {
> > + .width = 115,
> > + .height = 86,
> > + },
> > +};
> > +
> > static const struct display_timing koe_tx31d200vm0baa_timing = {
> > .pixelclock = { 3960, 4320, 4800 },
> > .hactive = { 1280, 1280, 1280 },
> > @@ -2204,6 +2227,9 @@ static const struct of_device_id
> > platform_of_match[] = { .compatible = "innolux,zj070na-01p",
> > .data = &innolux_zj070na_01p,
> > }, {
> > + .compatible = "koe,tx14d24vm1bpa",
> > + .data = &koe_tx14d24vm1bpa,
> > + }, {
> > .compatible = "koe,tx31d200vm0baa",
> > .data = &koe_tx31d200vm0baa,
> > }, {
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
pgpgPfWg_pWcs.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/12] drm/exynos: add non-panel path to exynos_dsi_enable()
As DSIM can now have a bridge connected as a peripheral, it should be
possible to successfully enable exynos_dsi, when there is no panel
provided.
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 8957faf..7d92e50 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1382,27 +1382,26 @@ static void exynos_dsi_enable(struct drm_encoder
*encoder)
if (dsi->state & DSIM_STATE_ENABLED)
return;
- pm_runtime_get_sync(dsi->dev);
-
- dsi->state |= DSIM_STATE_ENABLED;
-
- ret = drm_panel_prepare(dsi->panel);
- if (ret < 0) {
- dsi->state &= ~DSIM_STATE_ENABLED;
- return;
+ if (dsi->panel) {
+ ret = drm_panel_prepare(dsi->panel);
+ if (ret < 0) {
+ return;
+ }
}
exynos_dsi_set_display_mode(dsi);
exynos_dsi_set_display_enable(dsi, true);
- ret = drm_panel_enable(dsi->panel);
- if (ret < 0) {
- dsi->state &= ~DSIM_STATE_ENABLED;
- exynos_dsi_set_display_enable(dsi, false);
- drm_panel_unprepare(dsi->panel);
- return;
+ if (dsi->panel) {
+ ret = drm_panel_enable(dsi->panel);
+ if (ret < 0) {
+ exynos_dsi_set_display_enable(dsi, false);
+ drm_panel_unprepare(dsi->panel);
+ return;
+ }
}
+ dsi->state |= DSIM_STATE_ENABLED;
dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/12] ARM: dts: exynos5250-arndale: add display regulators
The patch adds fixed regulators used by DSI/LVDS bridge
and panel. Regulators are named according to schematics.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
arch/arm/boot/dts/exynos5250-arndale.dts | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 7a8a5c5..80221fa 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -97,6 +97,30 @@
reg = <2>;
regulator-name = "hdmi-en";
};
+
+ vcc_1v2_reg: regulator@3 {
+ compatible = "regulator-fixed";
+ reg = <3>;
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ };
+
+ vcc_1v8_reg: regulator@4 {
+ compatible = "regulator-fixed";
+ reg = <4>;
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ vcc_3v3_reg: regulator@5 {
+ compatible = "regulator-fixed";
+ reg = <5>;
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
};
fixed-rate-clocks {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/12] drm/bridge: tc358764: Add DSI to LVDS bridge driver
Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge. Signed-off-by: Andrzej Hajda Signed-off-by: Maciej Purski --- drivers/gpu/drm/bridge/Kconfig| 7 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/tc358764.c | 547 ++ 3 files changed, 555 insertions(+) create mode 100644 drivers/gpu/drm/bridge/tc358764.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index fa2c799..58e19af 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -110,6 +110,13 @@ config DRM_THINE_THC63LVD1024 ---help--- Thine THC63LVD1024 LVDS/parallel converter driver. +config DRM_TOSHIBA_TC358764 + tristate "TC358764 DSI/LVDS bridge" + depends on DRM && DRM_PANEL + depends on OF + select DRM_MIPI_DSI + select VIDEOMODE_HELPERS + config DRM_TOSHIBA_TC358767 tristate "Toshiba TC358767 eDP bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 35f88d4..bf7c0ce 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o obj-$(CONFIG_DRM_SII902X) += sii902x.o obj-$(CONFIG_DRM_SII9234) += sii9234.o obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o +obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ diff --git a/drivers/gpu/drm/bridge/tc358764.c b/drivers/gpu/drm/bridge/tc358764.c new file mode 100644 index 000..0bd520a --- /dev/null +++ b/drivers/gpu/drm/bridge/tc358764.c @@ -0,0 +1,547 @@ +/* + * Copyright (C) 2018 Samsung Electronics Co., Ltd + * + * Authors: + * Andrzej Hajda + * Maciej Purski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. + * + */ + +#include + +#include +#include +#include + +#include +#include + +#include +#include +#include + +#include +#include +#include + +#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) << (end)) +#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end)) + +/* PPI layer registers */ +#define PPI_STARTPPI 0x0104 /* START control bit */ +#define PPI_LPTXTIMECNT0x0114 /* LPTX timing signal */ +#define PPI_LANEENABLE 0x0134 /* Enables each lane */ +#define PPI_TX_RX_TA 0x013C /* BTA timing parameters */ +#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */ +#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */ +#define PPI_D2S_CLRSIPOCOUNT 0x016C /* Assertion timer for Lane 2 */ +#define PPI_D3S_CLRSIPOCOUNT 0x0170 /* Assertion timer for Lane 3 */ +#define PPI_START_FUNCTION 1 + +/* DSI layer registers */ +#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */ +#define DSI_LANEENABLE 0x0210 /* Enables each lane */ +#define DSI_RX_START 1 + +/* Video path registers */ +#define VP_CTRL0x0450 /* Video Path Control */ +#define VP_CTRL_MSF(v) FLD_VAL(v, 0, 0) /* Magic square in RGB666 */ +#define VP_CTRL_VTGEN(v) FLD_VAL(v, 4, 4) /* Use chip clock for timing */ +#define VP_CTRL_EVTMODE(v) FLD_VAL(v, 5, 5) /* Event mode */ +#define VP_CTRL_RGB888(v) FLD_VAL(v, 8, 8) /* RGB888 mode */ +#define VP_CTRL_VSDELAY(v) FLD_VAL(v, 31, 20) /* VSYNC delay */ +#define VP_CTRL_HSPOL BIT(17) /* Polarity of HSYNC signal */ +#define VP_CTRL_DEPOL BIT(18) /* Polarity of DE signal */ +#define VP_CTRL_VSPOL BIT(19) /* Polarity of VSYNC signal */ +#define VP_HTIM1 0x0454 /* Horizontal Timing Control 1 */ +#define VP_HTIM1_HBP(v)FLD_VAL(v, 24, 16) +#define VP_HTIM1_HSYNC(v) FLD_VAL(v, 8, 0) +#define VP_HTIM2 0x0458 /* Horizontal Timing Control 2 */ +#define VP_HTIM2_HFP(v)FLD_VAL(v, 24, 16) +#define VP_HTIM2_HACT(v) FLD_VAL(v, 10, 0) +#define VP_VTIM1 0x045C /* Vertical Timing Control 1 */ +#define VP_VTIM1_VBP(v)FLD_VAL(v, 23, 16) +#define VP_VTIM1_VSYNC(v) FLD_VAL(v, 7, 0) +#define VP_VTIM2 0x0460 /* Vertical Timing Control 2 */ +#define VP_VTIM2_VFP(v)FLD_VAL(v, 23, 16) +#define VP_VTIM2_VACT(v) FLD_VAL(v, 10, 0) +#define VP_VFUEN 0x0464 /*
[PATCH 09/12] ARM: dts: exynos5250: add mipi-phy node
The patch adds phy node, required by MIPI devices.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
arch/arm/boot/dts/exynos5250.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 2daf505..a63b655 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -733,6 +733,12 @@
#phy-cells = <0>;
};
+ mipi_phy: video-phy@10040710 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ #phy-cells = <1>;
+ syscon = <&pmu_system_controller>;
+ };
+
adc: adc@12d1 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D1 0x100>;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 RESEND] display: panel: Add AUO g070vvn01 display support (800x480)
Hi,
> Hi Thierry,
>
> > This commit adds support for AUO's 7.0" display.
> >
>
> Thierry, shall I perform some more work on this code, or is it
> eligible for applying to your tree?
Gentle ping. If Thierry is overworked - maybe there is a co-maintainer
so he/she could apply this patch?
>
> Best regards,
> Łukasz
>
> > Signed-off-by: Lukasz Majewski
> > Reviewed-by: Rob Herring
> >
> > ---
> > Changes for v3:
> > - Remove not used 'bus-format-override = "rgb565";' property
> >
> > Changes for v2:
> > - Add *.txt suffix to the auo,g070wn01 file
> > ---
> > .../bindings/display/panel/auo,g070vvn01.txt | 29
> >
> > drivers/gpu/drm/panel/panel-simple.c | 31
> > ++ 2 files changed, 60 insertions(+) create mode
> > 100644
> > Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
> > b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
> > new file mode 100644 index ..49e4105378f6 --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
> > @@ -0,0 +1,29 @@ +AU Optronics Corporation 7.0" FHD (800 x 480) TFT
> > LCD panel +
> > +Required properties:
> > +- compatible: should be "auo,g070vvn01"
> > +- backlight: phandle of the backlight device attached to the panel
> > +- power-supply: single regulator to provide the supply voltage
> > +
> > +Required nodes:
> > +- port: Parallel port mapping to connect this display
> > +
> > +This panel needs single power supply voltage. Its backlight is
> > conntrolled +via PWM signal.
> > +
> > +Example:
> > +
> > +
> > +Example device-tree definition when connected to iMX6Q based board
> > +
> > + lcd_panel: lcd-panel {
> > + compatible = "auo,g070vvn01";
> > + backlight = <&backlight_lcd>;
> > + power-supply = <®_display>;
> > +
> > + port {
> > + lcd_panel_in: endpoint {
> > + remote-endpoint =
> > <&lcd_display_out>;
> > + };
> > + };
> > + };
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c index
> > cbf1ab404ee7..d9984bdb5bb5 100644 ---
> > a/drivers/gpu/drm/panel/panel-simple.c +++
> > b/drivers/gpu/drm/panel/panel-simple.c @@ -581,6 +581,34 @@ static
> > const struct panel_desc auo_b133htn01 = { },
> > };
> >
> > +static const struct display_timing auo_g070vvn01_timings = {
> > + .pixelclock = { 3330, 34209000, 4500 },
> > + .hactive = { 800, 800, 800 },
> > + .hfront_porch = { 20, 40, 200 },
> > + .hback_porch = { 87, 40, 1 },
> > + .hsync_len = { 1, 48, 87 },
> > + .vactive = { 480, 480, 480 },
> > + .vfront_porch = { 5, 13, 200 },
> > + .vback_porch = { 31, 31, 29 },
> > + .vsync_len = { 1, 1, 3 },
> > +};
> > +
> > +static const struct panel_desc auo_g070vvn01 = {
> > + .timings = &auo_g070vvn01_timings,
> > + .num_timings = 1,
> > + .bpc = 8,
> > + .size = {
> > + .width = 152,
> > + .height = 91,
> > + },
> > + .delay = {
> > + .prepare = 200,
> > + .enable = 50,
> > + .disable = 50,
> > + .unprepare = 1000,
> > + },
> > +};
> > +
> > static const struct drm_display_mode auo_g104sn02_mode = {
> > .clock = 4,
> > .hdisplay = 800,
> > @@ -2095,6 +2123,9 @@ static const struct of_device_id
> > platform_of_match[] = { .compatible = "auo,b133xtn01",
> > .data = &auo_b133xtn01,
> > }, {
> > + .compatible = "auo,g070vvn01",
> > + .data = &auo_g070vvn01,
> > + }, {
> > .compatible = "auo,g104sn02",
> > .data = &auo_g104sn02,
> > }, {
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
pgpKWyDs2Xn_h.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103047] lighting render issue in i915
https://bugs.freedesktop.org/show_bug.cgi?id=103047 Steven Noonan changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes |.org|ktop.org Component|Drivers/DRI/i915|Drivers/DRI/i965 QA Contact|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes |.org|ktop.org --- Comment #5 from Steven Noonan --- Oh, I had this tagged against i915 which doesn't make sense. Switching to i965. -- 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 0/6] drm/omap: Module parameter for display order configuration
Hi, On 28/05/18 13:55, Pekka Paalanen wrote: >> The series adds support for changing the order of the displays defined by DT >> display aliases. >> >> The motivation to do such a thing is that for example the fb emulation is >> treating the first display/crtc as the 'main' display and will create the >> fb emulation based on the first display's properties. > > Hi, > > catering for fbdev seems strange to me. But if you do care, why is this Strange how? Because we should get rid of it? Sure. But it's there, and it's being used by almost everyone, at least in the form of fb console. > a driver-specific option instead of a generic DRM fb emulation > configuration option? That'd be fine for me, but I think the actual code to do this "create-connectors-in-this-order" work is still driver specific. Perhaps we could have a simple option to just choose the "main" display for fbdev (without chaing the way the connectors are created), though, which could perhaps be common code. >> There are many custom applications using DRM directly and they assume that >> the >> first connector is the 'main' display. > > This is very unfortunate, but I still think it would be better to fix > all those apps than patch kernel drivers one at a time to cater for > user preferences with driver-specific kernel options. I agree, but it's still a problem because we don't have access to those apps. And they keep popping up when e.g. being used on a new platform with multiple displays. >> Afaik weston provides no means either to change the 'main/preferred' display. > > Please, do not use Weston as justification for this. If you have window > positioning problems in Weston, please come talk to us on #wayland or > wayland-devel@, so we can discuss what you *actually* need. Weston is just one piece of the puzzle. If Weston was the only problem, then yes, we'd be working on Weston. But it's the combination of fbdev, custom DRM based apps and Weston. > Weston's behaviour in this respect has not been even defined yet, which > makes a kernel option to work around it ever more awkward. > > The reason why Weston lacks this kind of configurability is that no-one > has needed it yet, I mean, come forth with a proposal, as far as I can > recall. If people keep working around it elsewhere, it is unlikely Weston > ever gets it. > >> It should be the work of user space application (except the fb emulation) to >> somehow deal with the 'main' display selection for their needs, but >> unfortunately they are not capable of diong so for some reason. > > Aside from Weston, which apps are these? Mostly custom proprietary apps. But I think also Qt's DRM backend had this problem, although I might remember wrong or it might have been improved. Overall, I don't like these module parameters much. But they did solve issues our customers were having quite easily. I am fine with dropping this from mainline, and just carrying it in the TI kernel until we've come up with other solutions to the problems. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] ARM: defconfig: Update the vexpress defconfig
Update the Versatile Express defconfig to match the Kconfig changes in the kernel. Cc: Sudeep Holla Cc: Lorenzo Pieralisi Signed-off-by: Linus Walleij --- arch/arm/configs/vexpress_defconfig | 12 1 file changed, 12 deletions(-) diff --git a/arch/arm/configs/vexpress_defconfig b/arch/arm/configs/vexpress_defconfig index edae1c58fe80..226fe4bfb487 100644 --- a/arch/arm/configs/vexpress_defconfig +++ b/arch/arm/configs/vexpress_defconfig @@ -21,20 +21,17 @@ CONFIG_MODULE_UNLOAD=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_VEXPRESS_DCSCB=y CONFIG_ARCH_VEXPRESS_TC2_PM=y -# CONFIG_SWP_EMULATE is not set CONFIG_SMP=y CONFIG_HAVE_ARM_ARCH_TIMER=y CONFIG_MCPM=y CONFIG_VMSPLIT_2G=y CONFIG_NR_CPUS=8 CONFIG_ARM_PSCI=y -CONFIG_AEABI=y CONFIG_CMA=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="console=ttyAMA0" CONFIG_CPU_IDLE=y -CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y CONFIG_VFP=y CONFIG_NEON=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set @@ -61,7 +58,6 @@ CONFIG_MTD_PHYSMAP=y CONFIG_MTD_PHYSMAP_OF=y CONFIG_MTD_PLATRAM=y CONFIG_MTD_UBI=y -CONFIG_PROC_DEVICETREE=y CONFIG_VIRTIO_BLK=y # CONFIG_SCSI_PROC_FS is not set CONFIG_BLK_DEV_SD=y @@ -85,7 +81,6 @@ CONFIG_HW_RANDOM_VIRTIO=y CONFIG_I2C=y CONFIG_I2C_VERSATILE=y CONFIG_SENSORS_VEXPRESS=y -CONFIG_REGULATOR=y CONFIG_REGULATOR_VEXPRESS=y CONFIG_FB=y CONFIG_FB_ARMCLCD=y @@ -95,8 +90,6 @@ CONFIG_LOGO=y # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_SOUND=y CONFIG_SND=y -CONFIG_SND_MIXER_OSS=y -CONFIG_SND_PCM_OSS=y # CONFIG_SND_DRIVERS is not set CONFIG_SND_ARMAACI=y CONFIG_HID_DRAGONRISE=y @@ -133,9 +126,6 @@ CONFIG_VIRTIO_MMIO=y CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set -# CONFIG_EXT3_FS_XATTR is not set -CONFIG_EXT4_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y CONFIG_JFFS2_FS=y @@ -149,11 +139,9 @@ CONFIG_9P_FS=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_DEBUG_INFO=y -CONFIG_DEBUG_FS=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_KERNEL=y CONFIG_DETECT_HUNG_TASK=y # CONFIG_SCHED_DEBUG is not set CONFIG_DEBUG_USER=y -# CONFIG_CRYPTO_ANSI_CPRNG is not set # CONFIG_CRYPTO_HW is not set -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] ARM: defconfig: Enable the PL111 DRM driver on vexpress
This updates the Versatile defconfig to use the new P111 DRM driver that is merged in the DRM subsystem. We deactivate the old CLCD driver and activate the Pl111 DRM driver and the SiI9022 HDMI bridge. We activate DMA memory allocation using CMA so that the special graphics memory for the on-board CLCD can be used. Cc: Sudeep Holla Cc: Lorenzo Pieralisi Signed-off-by: Linus Walleij --- arch/arm/configs/vexpress_defconfig | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/configs/vexpress_defconfig b/arch/arm/configs/vexpress_defconfig index 226fe4bfb487..392ed3b3613c 100644 --- a/arch/arm/configs/vexpress_defconfig +++ b/arch/arm/configs/vexpress_defconfig @@ -48,6 +48,7 @@ CONFIG_NET_9P=y CONFIG_NET_9P_VIRTIO=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y +CONFIG_DMA_CMA=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_BLOCK=y @@ -78,13 +79,16 @@ CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_VIRTIO_CONSOLE=y CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_VIRTIO=y -CONFIG_I2C=y CONFIG_I2C_VERSATILE=y CONFIG_SENSORS_VEXPRESS=y CONFIG_REGULATOR_VEXPRESS=y -CONFIG_FB=y -CONFIG_FB_ARMCLCD=y -CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_DRM=y +CONFIG_DRM_PANEL_SIMPLE=y +CONFIG_DRM_SII902X=y +CONFIG_DRM_PL111=y +CONFIG_FB_MODE_HELPERS=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] ARM: dts: Modernize the Vexpress PL111 integration
The Versatile Express was submitted with the actual display
bridges unconnected (but defined in the device tree) and
mock "panels" encoded in the device tree node of the PL111
controller.
This doesn't even remotely describe the actual Versatile
Express hardware. Exploit the SiI9022 bridge by connecting
the PL111 pads to it, making it use EDID or fallback values
to drive the monitor.
The also has to use the reserved memory through the
CMA pool rather than by open coding a memory region and
remapping it explicitly in the driver. To achieve this,
a reserved-memory node must exist in the root of the
device tree, so we need to pull that out of the
motherboard .dtsi include files, and push it into each
top-level device tree instead.
We do the same manouver for all the Versatile Express
boards, taking into account the different location of the
video RAM depending on which chip select is used on
each platform.
This plays nicely with the new PL111 DRM driver and
follows the standard ways of assigning bridges and
memory pools for graphics.
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Cc: Liviu Dudau
Cc: Mali DP Maintainers
Cc: Robin Murphy
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Fix up the memory address for the -rs1 tiles to 0x1800
- Drop a bunch of extraneous reg props from the DVI adapter
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 44 ++
arch/arm/boot/dts/vexpress-v2m.dtsi | 45 ++-
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 14 ++
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts| 14 ++
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 14 ++
arch/arm/boot/dts/vexpress-v2p-ca9.dts| 41 +++--
arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts| 14 ++
.../boot/dts/arm/rtsm_ve-motherboard.dtsi | 37 +++
8 files changed, 105 insertions(+), 118 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index 7b8ff5b3b912..69f6a9436325 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -43,11 +43,6 @@
bank-width = <4>;
};
- v2m_video_ram: vram@2, {
- compatible = "arm,vexpress-vram";
- reg = <2 0x 0x0080>;
- };
-
ethernet@2,0200 {
compatible = "smsc,lan9118", "smsc,lan9115";
reg = <2 0x0200 0x1>;
@@ -224,6 +219,14 @@
dvi-transmitter@39 {
compatible = "sil,sii9022-tpi",
"sil,sii9022";
reg = <0x39>;
+
+ ports {
+ port@0 {
+ dvi_bridge_in:
endpoint {
+
remote-endpoint = <&clcd_pads>;
+ };
+ };
+ };
};
dvi-transmitter@60 {
@@ -254,37 +257,16 @@
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
- memory-region = <&v2m_video_ram>;
- max-memory-bandwidth = <5035>; /*
16bpp @ 25.175MHz */
+ /* 800x600 16bpp @36MHz works fine */
+ max-memory-bandwidth = <5400>;
+ memory-region = <&vram>;
port {
- v2m_clcd_pads: endpoint {
- remote-endpoint =
<&v2m_clcd_panel>;
+ clcd_pads: endpoint {
+ remote-endpoint =
<&dvi_bridge_in>;
arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
};
};
-
- panel {
- compatible = "panel-dpi";
-
- port {
- v2m_clcd_panel:
endpoint {
- rem
[PATCH 0/4] Switch Versatile Express to use PL111 DRM driver
Hi Sudeep/Lorenzo, this series of 4 patches (maybe you have even queued the first patch) will switch the Versatile Express over to using the new PL111 DRM driver instead of the old fbdev driver. There are both DTS updates and defconfig updates. Surely too late for v4.18 but should be fine for v4.19 (I will likely remind you if you forget it after v4.18-rc1.) The defconfig and DTS need to changed in lockstep, but usually the ARM SoC maintainers want them as two separate pull requests anyway. I think this could be quite useful, hopefully enabling things such as the generic Android and Chromium DRM hwcomposer: https://memcpy.io/android-enabling-mainline-graphics.html the improvement will be most drastic on the CA0 Versatile Express as this has only PL111 graphics on the core tile, but the fallback PL111 on the motherboard is also working for all models now. We are using CMA and CMA DMA buffers with existing DT bindings to hammer the system down to use the assigned special memory when we use the PL111 on the motherboard. Please queue this in your Versatile Express tree. To complete the transition for PL111 DRM for all ARM reference designs only Integrator/CP remains because of the special RGBA 5551 mode, but I will fix that too, hopefully also in time for kernel v4.19. The QEMU system emulator model for Versatile Express has been patched to certainly cope with these new changes as well: https://git.qemu.org/?p=qemu.git;a=commit;h=0b72476810a83de270194b1de65027e4be204779 Linus Walleij (4): ARM: dts: Restructure Vexpress motherboard includes ARM: dts: Modernize the Vexpress PL111 integration ARM: defconfig: Update the vexpress defconfig ARM: defconfig: Enable the PL111 DRM driver on vexpress arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 692 +- arch/arm/boot/dts/vexpress-v2m.dtsi | 691 + arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 17 +- arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts| 19 +- arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 19 +- arch/arm/boot/dts/vexpress-v2p-ca9.dts| 46 +- arch/arm/configs/vexpress_defconfig | 24 +- arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts| 14 + .../boot/dts/arm/rtsm_ve-motherboard.dtsi | 37 +- .../boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 5 +- 10 files changed, 773 insertions(+), 791 deletions(-) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] ARM: dts: Restructure Vexpress motherboard includes
It is a bit unorthodox to just include a file in the middle
of a another DTS file, it breaks the pattern from other device
trees and also makes it really hard to reference things
across the files with phandles.
Restructure the include for the Versatile Express motherboards
to happen at the top of the file, reference the target nodes
directly, and indent the motherboard .dtsi files to reflect
their actual depth in the hiearchy.
This is a purely syntactic change that result in the same
DTB files from the DTS/DTSI files.
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Cc: Robin Murphy
Cc: Liviu Dudau
Cc: Mali DP Maintainers
Signed-off-by: Linus Walleij
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 706 +-
arch/arm/boot/dts/vexpress-v2m.dtsi | 704 -
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 3 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts| 5 +-
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 5 +-
arch/arm/boot/dts/vexpress-v2p-ca9.dts| 5 +-
.../boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 5 +-
7 files changed, 718 insertions(+), 715 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index 35714ff6f467..7b8ff5b3b912 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -17,426 +17,430 @@
* CHANGES TO vexpress-v2m.dtsi!
*/
- motherboard {
- model = "V2M-P1";
- arm,hbi = <0x190>;
- arm,vexpress,site = <0>;
- arm,v2m-memory-map = "rs1";
- compatible = "arm,vexpress,v2m-p1", "simple-bus";
- #address-cells = <2>; /* SMB chipselect number and offset */
- #size-cells = <1>;
- #interrupt-cells = <1>;
- ranges;
-
- flash@0, {
- compatible = "arm,vexpress-flash", "cfi-flash";
- reg = <0 0x 0x0400>,
- <4 0x 0x0400>;
- bank-width = <4>;
- };
+/ {
+ smb@800 {
+ motherboard {
+ model = "V2M-P1";
+ arm,hbi = <0x190>;
+ arm,vexpress,site = <0>;
+ arm,v2m-memory-map = "rs1";
+ compatible = "arm,vexpress,v2m-p1", "simple-bus";
+ #address-cells = <2>; /* SMB chipselect number and
offset */
+ #size-cells = <1>;
+ #interrupt-cells = <1>;
+ ranges;
- psram@1, {
- compatible = "arm,vexpress-psram", "mtd-ram";
- reg = <1 0x 0x0200>;
- bank-width = <4>;
- };
+ flash@0, {
+ compatible = "arm,vexpress-flash", "cfi-flash";
+ reg = <0 0x 0x0400>,
+ <4 0x 0x0400>;
+ bank-width = <4>;
+ };
- v2m_video_ram: vram@2, {
- compatible = "arm,vexpress-vram";
- reg = <2 0x 0x0080>;
- };
+ psram@1, {
+ compatible = "arm,vexpress-psram", "mtd-ram";
+ reg = <1 0x 0x0200>;
+ bank-width = <4>;
+ };
- ethernet@2,0200 {
- compatible = "smsc,lan9118", "smsc,lan9115";
- reg = <2 0x0200 0x1>;
- interrupts = <15>;
- phy-mode = "mii";
- reg-io-width = <4>;
- smsc,irq-active-high;
- smsc,irq-push-pull;
- vdd33a-supply = <&v2m_fixed_3v3>;
- vddvario-supply = <&v2m_fixed_3v3>;
- };
+ v2m_video_ram: vram@2, {
+ compatible = "arm,vexpress-vram";
+ reg = <2 0x 0x0080>;
+ };
- usb@2,0300 {
- compatible = "nxp,usb-isp1761";
- reg = <2 0x0300 0x2>;
- interrupts = <16>;
- port1-otg;
- };
+ ethernet@2,0200 {
+ compatible = "smsc,lan9118", "smsc,lan9115";
+ reg = <2 0x0200 0x1>;
+ interrupts = <15>;
+ phy-mode = "mii";
+ reg-io-width = <4>;
+
Re: [PATCH] gpu: drm: etnaviv: Change return type to vm_fault_t
Hi Souptick,
Am Montag, den 21.05.2018, 22:42 +0530 schrieb Souptick Joarder:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Ref- commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>
> Previously vm_insert_page() returns err which driver
> mapped into VM_FAULT_* type. The new function
> vmf_insert_page() will replace this inefficiency by
> returning VM_FAULT_* type.
>
> A non-fatal signal being delivered to a task which is
> in the middle of a page fault may well end up in an
> infinite loop, attempting to handle the page fault and
> failing forever.
>
> On seeing NOPAGE, the fault handler believes the PTE
> is in the page table, so does nothing before it returns
> to arch code. It will end up returning to userspace if
> the signal is non-fatal, at which point it'll go right
> back into the page fault handler, and mutex_lock_interruptible()
> will immediately fail. So we've converted a sleeping lock
> into the most expensive spinlock.
>
> I don't think the graphics drivers really want to be
> interrupted by any signal. I think they want to be
> interruptible by fatal signals and should use the
> mutex_lock_killable / fatal_signal_pending family of
> functions. So mutex_lock_interruptible() is replaced
> by mutex_lock_killable()
I don't think the other thread discussing this issue has reached a
proper conclusion and I would rather not pull in a patch based on thin
reasoning. If we want to change this behavior I would really like to
see the issue it is solving and it should be a separate patch, not
intermixed with some return value change.
Regards,
Lucas
> vmf_error() is the newly introduce inline function
> in 4.17-rc6.
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.h | 3 ++-
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 31 ++---
> --
> 2 files changed, 8 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> index a54f0b7..f6777f0 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -62,7 +63,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device
> *dev, void *data,
> struct drm_file *file);
>
> int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct *vma);
> -int etnaviv_gem_fault(struct vm_fault *vmf);
> +vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf);
> int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, u64
> *offset);
> struct sg_table *etnaviv_gem_prime_get_sg_table(struct
> drm_gem_object *obj);
> void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index fcc969f..d9b13f0 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -180,7 +180,7 @@ int etnaviv_gem_mmap(struct file *filp, struct
> vm_area_struct *vma)
> return obj->ops->mmap(obj, vma);
> }
>
> -int etnaviv_gem_fault(struct vm_fault *vmf)
> +vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct drm_gem_object *obj = vma->vm_private_data;
> @@ -191,20 +191,19 @@ int etnaviv_gem_fault(struct vm_fault *vmf)
>
> /*
>* Make sure we don't parallel update on a fault, nor move
> or remove
> - * something from beneath our feet. Note that
> vm_insert_page() is
> + * something from beneath our feet. Note that
> vmf_insert_page() is
>* specifically coded to take care of this, so we don't have
> to.
>*/
> - ret = mutex_lock_interruptible(&etnaviv_obj->lock);
> + ret = mutex_lock_killable(&etnaviv_obj->lock);
> if (ret)
> - goto out;
> -
> + return VM_FAULT_NOPAGE;
> /* make sure we have pages attached now */
> pages = etnaviv_gem_get_pages(etnaviv_obj);
> mutex_unlock(&etnaviv_obj->lock);
>
> if (IS_ERR(pages)) {
> ret = PTR_ERR(pages);
> - goto out;
> + return vmf_error(ret);
> }
>
> /* We don't use vmf->pgoff since that has the fake offset:
> */
> @@ -215,25 +214,7 @@ int etnaviv_gem_fault(struct vm_fault *vmf)
> VERB("Inserting %p pfn %lx, pa %lx", (void *)vmf->address,
>page_to_pfn(page), page_to_pfn(page) << PAGE_SHIFT);
>
> - ret = vm_insert_page(vma, vmf->address, page);
> -
> -out:
> - switch (ret) {
> - case -EAGAIN:
> - case 0:
> - case -ERESTARTSYS:
> - case -EINTR:
> - case -EBUSY:
> - /*
> - * EBUSY is ok: this just means that another thread
> - * already did t
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On Sat, May 26, 2018 at 06:56:22PM +0300, Dmitry Osipenko wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either become fully transparent or gain adjustment
> of the pixels component values.
>
> Color keying is found in a large number of devices whose capabilities
> often differ, but they still have enough common features in range to
> standardize color key properties. This commit adds nine generic DRM plane
> properties related to the color keying to cover various HW capabilities.
>
> This patch is based on the initial work done by Laurent Pinchart, most of
> credits for this patch goes to him.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_atomic.c | 36 ++
> drivers/gpu/drm/drm_blend.c | 229 +++
> include/drm/drm_blend.h | 3 +
> include/drm/drm_plane.h | 77
> 4 files changed, 345 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 895741e9cd7d..5b808cb68654 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> state->rotation = val;
> } else if (property == plane->zpos_property) {
> state->zpos = val;
> + } else if (property == plane->colorkey.mode_property) {
> + state->colorkey.mode = val;
> + } else if (property == plane->colorkey.min_property) {
> + state->colorkey.min = val;
> + } else if (property == plane->colorkey.max_property) {
> + state->colorkey.max = val;
> + } else if (property == plane->colorkey.format_property) {
> + state->colorkey.format = val;
> + } else if (property == plane->colorkey.mask_property) {
> + state->colorkey.mask = val;
> + } else if (property == plane->colorkey.inverted_match_property) {
> + state->colorkey.inverted_match = val;
> + } else if (property == plane->colorkey.replacement_mask_property) {
> + state->colorkey.replacement_mask = val;
> + } else if (property == plane->colorkey.replacement_value_property) {
> + state->colorkey.replacement_value = val;
> + } else if (property == plane->colorkey.replacement_format_property) {
> + state->colorkey.replacement_format = val;
> } else if (property == plane->color_encoding_property) {
> state->color_encoding = val;
> } else if (property == plane->color_range_property) {
> @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> *val = state->rotation;
> } else if (property == plane->zpos_property) {
> *val = state->zpos;
> + } else if (property == plane->colorkey.mode_property) {
> + *val = state->colorkey.mode;
> + } else if (property == plane->colorkey.min_property) {
> + *val = state->colorkey.min;
> + } else if (property == plane->colorkey.max_property) {
> + *val = state->colorkey.max;
> + } else if (property == plane->colorkey.format_property) {
> + *val = state->colorkey.format;
> + } else if (property == plane->colorkey.mask_property) {
> + *val = state->colorkey.mask;
> + } else if (property == plane->colorkey.inverted_match_property) {
> + *val = state->colorkey.inverted_match;
> + } else if (property == plane->colorkey.replacement_mask_property) {
> + *val = state->colorkey.replacement_mask;
> + } else if (property == plane->colorkey.replacement_value_property) {
> + *val = state->colorkey.replacement_value;
> + } else if (property == plane->colorkey.replacement_format_property) {
> + *val = state->colorkey.replacement_format;
> } else if (property == plane->color_encoding_property) {
> *val = state->color_encoding;
> } else if (property == plane->color_range_property) {
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index a16a74d7e15e..05e5632ce375 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -107,6 +107,11 @@
> * planes. Without this property the primary plane is always below the
> cursor
> * plane, and ordering between all other planes is undefined.
> *
> + * colorkey:
> + * Color keying is set up with drm_plane_create_colorkey_properties().
> + * It adds support for replacing a range of colors with a transparent
> + * color in the plane.
> + *
> * Note that all the property extensions described here apply either to the
> * plane or the CRTC (e.g. for the background color, which currently is not
> * exposed and assumed to be black).
> @@ -448,3 +453,227 @@ int drm_
[PATCH v2 0/2] drm/rockchip: try to fix vblank hang resulting from iommu irq change
This still tries to address the hang seen by Ezequiel Garcia on rk3288. As Tomasz noted, trying to count enablement can run into concurrency issues, so instead we'll just check if the vop is runtime-enabled to see if it could be the source of the irq and then just do our own clk_enable in the isr to bridge the possible gap between pm_runtime_enable and clk_enable in the core vop_enable() function. Display tested to still work on rk3328 and rk3399, but as I don't see the hang from Ezequiel I hope that this fixes it. changes in v2: - adapt approach ... don't try to count usage ourself, because of possible concurrency issues with vop enable/disable Heiko Stuebner (1): drm/rockchip: vop: split out core clock enablement into separate functions Sandy Huang (1): drm/rockchip: vop: fix irq disabled after vop driver probed drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 72 ++--- 1 file changed, 50 insertions(+), 22 deletions(-) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
From: Sandy Huang
The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in some
cases lead to a stall if the irq is triggered while the vop driver
still has it disabled, but the vop irq handler gets called.
But there is no real need to disable the irq, as the vop can simply
also track its enabled state and ignore irqs in that case.
For this we can simply check the power-domain state of the vop,
similar to how the iommu driver does it.
So remove the enable/disable handling and add appropriate condition
to the irq handler.
changes in v2:
- move to just check the power-domain state
- add clock handling
Signed-off-by: Sandy Huang
[add commit message, moved to pm_runtime_get_if_in_use]
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 28 ++---
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index b55156b8ba3b..615a5b44bfe9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -573,8 +573,6 @@ static int vop_enable(struct drm_crtc *crtc)
spin_unlock(&vop->reg_lock);
- enable_irq(vop->irq);
-
drm_crtc_vblank_on(crtc);
return 0;
@@ -618,8 +616,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
vop_dsp_hold_valid_irq_disable(vop);
- disable_irq(vop->irq);
-
vop->is_enabled = false;
/*
@@ -1195,6 +1191,16 @@ static irqreturn_t vop_isr(int irq, void *data)
uint32_t active_irqs;
int ret = IRQ_NONE;
+ /*
+* The irq is shared with the iommu. If the power-domain is off
+* the irq has to be targetted at the iommu.
+*/
+ if (!pm_runtime_get_if_in_use(vop->dev))
+ return IRQ_NONE;
+
+ if (WARN_ON(vop_core_clks_enable(vop)))
+ goto out;
+
/*
* interrupt register has interrupt status, enable and clear bits, we
* must hold irq_lock to avoid a race with enable/disable_vblank().
@@ -1209,8 +1215,11 @@ static irqreturn_t vop_isr(int irq, void *data)
spin_unlock(&vop->irq_lock);
/* This is expected for vop iommu irqs, since the irq is shared */
- if (!active_irqs)
- return IRQ_NONE;
+ if (!active_irqs) {
+ ret = IRQ_NONE;
+ vop_core_clks_disable(vop);
+ goto out;
+ }
if (active_irqs & DSP_HOLD_VALID_INTR) {
complete(&vop->dsp_hold_completion);
@@ -1236,6 +1245,10 @@ static irqreturn_t vop_isr(int irq, void *data)
DRM_DEV_ERROR(vop->dev, "Unknown VOP IRQs: %#02x\n",
active_irqs);
+ vop_core_clks_disable(vop);
+
+out:
+ pm_runtime_put(vop->dev);
return ret;
}
@@ -1614,9 +1627,6 @@ static int vop_bind(struct device *dev, struct device
*master, void *data)
if (ret)
goto err_disable_pm_runtime;
- /* IRQ is initially disabled; it gets enabled in power_on */
- disable_irq(vop->irq);
-
return 0;
err_disable_pm_runtime:
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/rockchip: vop: split out core clock enablement into separate functions
Judging from the iommu code, both the hclk and aclk are necessary for
register access. Split them off into separate functions from the regular
vop enablement, so that we can use them elsewhere as well.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 44 +++--
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 45847d4a2e14..b55156b8ba3b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -486,6 +486,31 @@ static void vop_line_flag_irq_disable(struct vop *vop)
spin_unlock_irqrestore(&vop->irq_lock, flags);
}
+static int vop_core_clks_enable(struct vop *vop)
+{
+ int ret;
+
+ ret = clk_enable(vop->hclk);
+ if (ret < 0)
+ return ret;
+
+ ret = clk_enable(vop->aclk);
+ if (ret < 0)
+ goto err_disable_hclk;
+
+ return 0;
+
+err_disable_hclk:
+ clk_disable(vop->hclk);
+ return ret;
+}
+
+static void vop_core_clks_disable(struct vop *vop)
+{
+ clk_disable(vop->aclk);
+ clk_disable(vop->hclk);
+}
+
static int vop_enable(struct drm_crtc *crtc)
{
struct vop *vop = to_vop(crtc);
@@ -497,17 +522,13 @@ static int vop_enable(struct drm_crtc *crtc)
return ret;
}
- ret = clk_enable(vop->hclk);
+ ret = vop_core_clks_enable(vop);
if (WARN_ON(ret < 0))
goto err_put_pm_runtime;
ret = clk_enable(vop->dclk);
if (WARN_ON(ret < 0))
- goto err_disable_hclk;
-
- ret = clk_enable(vop->aclk);
- if (WARN_ON(ret < 0))
- goto err_disable_dclk;
+ goto err_disable_core;
/*
* Slave iommu shares power, irq and clock with vop. It was associated
@@ -519,7 +540,7 @@ static int vop_enable(struct drm_crtc *crtc)
if (ret) {
DRM_DEV_ERROR(vop->dev,
"failed to attach dma mapping, %d\n", ret);
- goto err_disable_aclk;
+ goto err_disable_dclk;
}
spin_lock(&vop->reg_lock);
@@ -558,12 +579,10 @@ static int vop_enable(struct drm_crtc *crtc)
return 0;
-err_disable_aclk:
- clk_disable(vop->aclk);
err_disable_dclk:
clk_disable(vop->dclk);
-err_disable_hclk:
- clk_disable(vop->hclk);
+err_disable_core:
+ vop_core_clks_disable(vop);
err_put_pm_runtime:
pm_runtime_put_sync(vop->dev);
return ret;
@@ -609,8 +628,7 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
rockchip_drm_dma_detach_device(vop->drm_dev, vop->dev);
clk_disable(vop->dclk);
- clk_disable(vop->aclk);
- clk_disable(vop->hclk);
+ vop_core_clks_disable(vop);
pm_runtime_put(vop->dev);
mutex_unlock(&vop->vop_lock);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] drm: Begin an API for in-kernel clients
Den 24.05.2018 10.42, skrev Daniel Vetter:
On Wed, May 23, 2018 at 04:34:06PM +0200, Noralf Trønnes wrote:
This the beginning of an API for in-kernel clients.
First out is a way to get a framebuffer backed by a dumb buffer.
Only GEM drivers are supported.
The original idea of using an exported dma-buf was dropped because it
also creates an anonomous file descriptor which doesn't work when the
buffer is created from a kernel thread. The easy way out is to use
drm_driver.gem_prime_vmap to get the virtual address, which requires a
GEM object. This excludes the vmwgfx driver which is the only non-GEM
driver apart from the legacy ones. A solution for vmwgfx will have to be
worked out later if it wants to support the client API which it probably
will when we have a bootsplash client.
Signed-off-by: Noralf Trønnes
A few small nits below, with those addressed:
Reviewed-by: Daniel Vetter
---
[...]
+/**
+ * drm_client_new - Create a DRM client
+ * @dev: DRM device
+ *
+ * Returns:
+ * Pointer to a client or an error pointer on failure.
+ */
+struct drm_client_dev *drm_client_new(struct drm_device *dev)
Api nitpick:
int drm_client_init(struct drm_device *dev,
struct drm_client_dev *client)
and dropping the kzalloc from this structure here. This allows users of
this to embed the client struct into their own thing, which means the
->private backpointer isn't necessary. Allowing embedding is the preferred
interface in the kernel (since it's strictly more powerful, you can always
just kzalloc + _init to get the _new behaviour).
+{
+ struct drm_client_dev *client;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
+ !dev->driver->dumb_create || !dev->driver->gem_prime_vmap)
+ return ERR_PTR(-ENOTSUPP);
+
+ client = kzalloc(sizeof(*client), GFP_KERNEL);
+ if (!client)
+ return ERR_PTR(-ENOMEM);
+
+ client->dev = dev;
+
+ ret = drm_client_alloc_file(client);
+ if (ret) {
+ kfree(client);
+ return ERR_PTR(ret);
+ }
+
+ return client;
+}
+EXPORT_SYMBOL(drm_client_new);
+
[...]
+static struct drm_client_buffer *
+drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height,
u32 format)
+{
+ struct drm_mode_create_dumb dumb_args = { };
+ struct drm_device *dev = client->dev;
+ struct drm_client_buffer *buffer;
+ struct drm_gem_object *obj;
+ void *vaddr;
+ int ret;
+
+ buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
+ if (!buffer)
+ return ERR_PTR(-ENOMEM);
+
+ buffer->client = client;
+
+ dumb_args.width = width;
+ dumb_args.height = height;
+ dumb_args.bpp = drm_format_plane_cpp(format, 0) * 8;
+ ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
+ if (ret)
+ goto err_free;
+
+ buffer->handle = dumb_args.handle;
+ buffer->pitch = dumb_args.pitch;
+
+ obj = drm_gem_object_lookup(client->file, dumb_args.handle);
+ if (!obj) {
+ ret = -ENOENT;
+ goto err_delete;
+ }
+
+ buffer->gem = obj;
+
I'm paranoid, I think an
if (WARN_ON(!gem_prime_vmap))
return -EINVAL;
would be cool here.
This is already checked in drm_client_init().
Noralf.
Also perhaps the following comment:
/*
* FIXME: The dependency on GEM here isn't required, we could
* convert the driver handle to a dma-buf instead and use the
* backend-agnostic dma-buf vmap support instead. This would
* require that the handle2fd prime ioctl is reworked to pull the
* fd_install step out of the driver backend hooks, to make that
* final step optional for internal users.
*/
+ vaddr = dev->driver->gem_prime_vmap(obj);
+ if (!vaddr) {
+ ret = -ENOMEM;
+ goto err_delete;
+ }
+
+ buffer->vaddr = vaddr;
+
+ return buffer;
+
+err_delete:
+ drm_client_buffer_delete(buffer);
+err_free:
+ kfree(buffer);
+
+ return ERR_PTR(ret);
+}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/1] console/fbcon: Add support for deferred console takeover
Hi All, Allthough this patch has turned out pleasantly small / simpel, I guess it still might be somewhat controversial. So let me explain why this patch is necessary. Various (desktop oriented) Linux distributions have spend a lot of time to not show way too technial boot messages to end users during bootup. What we would really like for the boot experience is something like MacOS X / Windows 10 do. The (EFI) firmware boots up a logo and we leave that in place until the login-manager (e.g. gdm) starts and then the login-manager takes over the framebuffer including the current logo contents and fades that into the login screen. I've already written and upstreamed a patch for shim to not switch the EFI framebuffer to text-mode, unless it has some error message to display this is upstream now: https://github.com/rhboot/shim/commit/1ff4a36a23ac5c17144275ccb3e1e1061750a137 I've written a similar patch for grub2 to not switch to text-mode when using timeout_style=hidden for the menu and no key to show the menu is pressed. This has been posted upstream and I need to do a v2 addressing some small remarks. This brings us to the next piece of software taking over control of the framebuffer, the kernel. I already have a patch in -next to fix the i915 driver not taking over the BIOS used framebuffer (and thus loosing the vendor logo) on newer hardware: https://cgit.freedesktop.org/drm-intel/commit?id=011f22eb545a35f972036bb6a245c95c2e7e15a0 But this is only useful if we don't get fbcon binding to any fbdev devices showing up and replacing there contents with a black screen right away. That is where this patch comes in it defers fbcon binding to any registered fbdevs, until some output, any output at all, is send to the console (tty0), this way error messages will still get shown, but a well behaved userspace which does not spam the console with messages will retain the vendor logo from the EFI firmware all the way to the login screen. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] console/fbcon: Add support for deferred console takeover
Currently fbcon claims fbdevs as soon as they are registered and takes over
the console as soon as the first fbdev gets registered.
This behavior is undesirable in cases where a smooth graphical bootup is
desired, in such cases we typically want the contents of the framebuffer
(typically a vendor logo) to stay in place as is.
The current solution for this problem (on embedded systems) is to not
enable fbcon.
This commit adds a new FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER config option,
which when enabled defers fbcon taking over the console from the dummy
console until the first text is displayed on the console. Together with the
"quiet" kernel commandline option, this allows fbcon to still be used
together with a smooth graphical bootup, having it take over the console as
soon as e.g. an error message is logged.
Signed-off-by: Hans de Goede
---
drivers/video/console/Kconfig| 11 ++
drivers/video/console/dummycon.c | 46 --
drivers/video/fbdev/core/fbcon.c | 65
include/linux/console.h | 5 +++
4 files changed, 124 insertions(+), 3 deletions(-)
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 4110ba7d7ca9..e91edef98633 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -150,6 +150,17 @@ config FRAMEBUFFER_CONSOLE_ROTATION
such that other users of the framebuffer will remain normally
oriented.
+config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
+ bool "Framebuffer Console Deferred Takeover"
+ depends on FRAMEBUFFER_CONSOLE=y && DUMMY_CONSOLE=y
+ help
+ If enabled this defers the framebuffer console taking over the
+ console from the dummy console until the first text is displayed on
+ the console. This is useful in combination with the "quiet" kernel
+ commandline option to keep the framebuffer contents initially put up
+ by the firmware in place, rather then replacing the contents with a
+ black screen as soon as fbcon loads.
+
config STI_CONSOLE
bool "STI text console"
depends on PARISC && HAS_IOMEM
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index f2eafe2ed980..402409b8c575 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -26,6 +26,49 @@
#define DUMMY_ROWS CONFIG_DUMMY_CONSOLE_ROWS
#endif
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
+/* These are both protected by the console_lock */
+static RAW_NOTIFIER_HEAD(dummycon_output_nh);
+static bool dummycon_putc_called;
+
+void dummycon_register_output_notifier(struct notifier_block *nb)
+{
+ raw_notifier_chain_register(&dummycon_output_nh, nb);
+
+ if (dummycon_putc_called)
+ nb->notifier_call(nb, 0, NULL);
+}
+
+void dummycon_unregister_output_notifier(struct notifier_block *nb)
+{
+ raw_notifier_chain_unregister(&dummycon_output_nh, nb);
+}
+
+static void dummycon_putc(struct vc_data *vc, int c, int ypos, int xpos)
+{
+ dummycon_putc_called = true;
+ raw_notifier_call_chain(&dummycon_output_nh, 0, NULL);
+}
+
+static void dummycon_putcs(struct vc_data *vc, const unsigned short *s,
+ int count, int ypos, int xpos)
+{
+ if (!dummycon_putc_called) {
+ /* Ignore erases */
+ if (s[0] == vc->vc_video_erase_char)
+ return;
+
+ dummycon_putc_called = true;
+ }
+
+ raw_notifier_call_chain(&dummycon_output_nh, 0, NULL);
+}
+#else
+static void dummycon_putc(struct vc_data *vc, int c, int ypos, int xpos) { }
+static void dummycon_putcs(struct vc_data *vc, const unsigned short *s,
+ int count, int ypos, int xpos) { }
+#endif
+
static const char *dummycon_startup(void)
{
return "dummy device";
@@ -44,9 +87,6 @@ static void dummycon_init(struct vc_data *vc, int init)
static void dummycon_deinit(struct vc_data *vc) { }
static void dummycon_clear(struct vc_data *vc, int sy, int sx, int height,
int width) { }
-static void dummycon_putc(struct vc_data *vc, int c, int ypos, int xpos) { }
-static void dummycon_putcs(struct vc_data *vc, const unsigned short *s,
- int count, int ypos, int xpos) { }
static void dummycon_cursor(struct vc_data *vc, int mode) { }
static bool dummycon_scroll(struct vc_data *vc, unsigned int top,
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 3e330e0f56ed..f58c92571c7c 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -129,6 +129,12 @@ static inline void fbcon_map_override(void)
}
#endif /* CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY */
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
+static bool deferred_takeover = true;
+#else
+#define deferred_takeover false
+#endif
+
/* font data */
static char fontname
Re: [PATCH 0/1] console/fbcon: Add support for deferred console takeover
On Mon, 28 May 2018, Hans de Goede wrote: > Various (desktop oriented) Linux distributions have spend a lot of time > to not show way too technial boot messages to end users during bootup. > What we would really like for the boot experience is something like > MacOS X / Windows 10 do. The (EFI) firmware boots up a logo and we > leave that in place until the login-manager (e.g. gdm) starts and then > the login-manager takes over the framebuffer including the current logo > contents and fades that into the login screen. > > I've already written and upstreamed a patch for shim to not switch the > EFI framebuffer to text-mode, unless it has some error message to display > this is upstream now: > https://github.com/rhboot/shim/commit/1ff4a36a23ac5c17144275ccb3e1e1061750a137 > > I've written a similar patch for grub2 to not switch to text-mode when > using timeout_style=hidden for the menu and no key to show the menu is > pressed. This has been posted upstream and I need to do a v2 addressing > some small remarks. > > This brings us to the next piece of software taking over control of > the framebuffer, the kernel. > > I already have a patch in -next to fix the i915 driver not taking over > the BIOS used framebuffer (and thus loosing the vendor logo) on newer > hardware: > https://cgit.freedesktop.org/drm-intel/commit?id=011f22eb545a35f972036bb6a245c95c2e7e15a0 > > But this is only useful if we don't get fbcon binding to any fbdev > devices showing up and replacing there contents with a black screen > right away. > > That is where this patch comes in it defers fbcon binding to any registered > fbdevs, until some output, any output at all, is send to the console (tty0), > this way error messages will still get shown, but a well behaved userspace > which does not spam the console with messages will retain the vendor logo > from the EFI firmware all the way to the login screen. FWIW I think the main idea here is sound: just preserve whatever image the firmware decided to display until something noteworthy happens or gdm takes over. (And you could perhaps override the image in grub if you like, and preserve that until gdm instead.) BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g
https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #30 from Jerry Zuo --- The commit on amd-staging-drm-next I checked out for verification is: Author: Shaoyun Liu AuthorDate: Tue May 22 11:45:41 2018 -0400 Commit: Alex Deucher CommitDate: Thu May 24 10:28:35 2018 -0500 drm/amdgpu: Update GFX info structure to match what vega20 used Update to the latest version from the vbios team. Signed-off-by: Shaoyun Liu Acked-by: Alex Deucher Signed-off-by: Alex Deucher It was working for me to directly checkout the commit and build. It is 4.16-rc7 build. -- 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 8/8] drm/bridge: cdns: mark PM functions as __maybe_unused
+Thierry
Hi Arnd,
On Fri, 25 May 2018 17:50:15 +0200
Arnd Bergmann wrote:
> These two functions are unused in some configurations, and using
> __maybe_unused
> is the easiest way to shut up the harmless warnings:
>
> drivers/gpu/drm/bridge/cdns-dsi.c:1353:12: error: 'cdns_dsi_suspend' defined
> but not used [-Werror=unused-function]
> static int cdns_dsi_suspend(struct device *dev)
> ^~~~
> drivers/gpu/drm/bridge/cdns-dsi.c:1340:12: error: 'cdns_dsi_resume' defined
> but not used [-Werror=unused-function]
> static int cdns_dsi_resume(struct device *dev)
>
> Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
> Signed-off-by: Arnd Bergmann
Hm, I thought such a patch had already been applied by Thierry [1].
[1]https://www.spinics.net/lists/dri-devel/msg174363.html
> ---
> drivers/gpu/drm/bridge/cdns-dsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index c255fc3e1be5..f2d43f24acfb 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -1337,7 +1337,7 @@ static const struct mipi_dsi_host_ops cdns_dsi_ops = {
> .transfer = cdns_dsi_transfer,
> };
>
> -static int cdns_dsi_resume(struct device *dev)
> +static int __maybe_unused cdns_dsi_resume(struct device *dev)
> {
> struct cdns_dsi *dsi = dev_get_drvdata(dev);
>
> @@ -1350,7 +1350,7 @@ static int cdns_dsi_resume(struct device *dev)
> return 0;
> }
>
> -static int cdns_dsi_suspend(struct device *dev)
> +static int __maybe_unused cdns_dsi_suspend(struct device *dev)
> {
> struct cdns_dsi *dsi = dev_get_drvdata(dev);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video/omap: add module license tags
I got a bunch of warnings in a randconfig build:
WARNING: modpost: missing MODULE_LICENSE() in
drivers/video/fbdev/omap/lcd_ams_delta.o
WARNING: modpost: missing MODULE_LICENSE() in
drivers/video/fbdev/omap/lcd_inn1510.o
WARNING: modpost: missing MODULE_LICENSE() in
drivers/video/fbdev/omap/lcd_palmte.o
WARNING: modpost: missing MODULE_LICENSE() in
drivers/video/fbdev/omap/lcd_palmtt.o
These come from an earlier patch of mine that turned all display drivers
into separate modules. The fix is to add a MODULE_LICENSE tag. Since I'm
doing that, adding a description and author field also makes sense. I
went by the authors listed in the comment at the top of each file, but
removed Imre's Nokia email address that I assume is not valid any more,
since Imre is working at Intel these days.
Fixes: 81c44c2b2ce3 ("video/omap: fix modular build")
Cc: Imre Deak
Signed-off-by: Arnd Bergmann
---
drivers/video/fbdev/omap/lcd_ams_delta.c | 3 +++
drivers/video/fbdev/omap/lcd_h3.c| 3 +++
drivers/video/fbdev/omap/lcd_htcherald.c | 4
drivers/video/fbdev/omap/lcd_inn1510.c | 3 +++
drivers/video/fbdev/omap/lcd_inn1610.c | 3 +++
drivers/video/fbdev/omap/lcd_osk.c | 4
drivers/video/fbdev/omap/lcd_palmte.c| 3 +++
drivers/video/fbdev/omap/lcd_palmtt.c| 3 +++
drivers/video/fbdev/omap/lcd_palmz71.c | 3 +++
9 files changed, 29 insertions(+)
diff --git a/drivers/video/fbdev/omap/lcd_ams_delta.c
b/drivers/video/fbdev/omap/lcd_ams_delta.c
index a4ee947006c7..488b3e9a2646 100644
--- a/drivers/video/fbdev/omap/lcd_ams_delta.c
+++ b/drivers/video/fbdev/omap/lcd_ams_delta.c
@@ -197,3 +197,6 @@ static struct platform_driver ams_delta_panel_driver = {
};
module_platform_driver(ams_delta_panel_driver);
+MODULE_AUTHOR("Jonathan McDowell ");
+MODULE_DESCRIPTION("LCD panel support for the Amstrad E3 (Delta) videophone");
+MODULE_LICENSE("GPL");
diff --git a/drivers/video/fbdev/omap/lcd_h3.c
b/drivers/video/fbdev/omap/lcd_h3.c
index 796f4634c4c6..146dd962c69e 100644
--- a/drivers/video/fbdev/omap/lcd_h3.c
+++ b/drivers/video/fbdev/omap/lcd_h3.c
@@ -89,3 +89,6 @@ static struct platform_driver h3_panel_driver = {
};
module_platform_driver(h3_panel_driver);
+MODULE_AUTHOR("Imre Deak");
+MODULE_DESCRIPTION("LCD panel support for the TI OMAP H3 board");
+MODULE_LICENSE("GPL");
diff --git a/drivers/video/fbdev/omap/lcd_htcherald.c
b/drivers/video/fbdev/omap/lcd_htcherald.c
index 9d692f5b8025..db4ff1c6add9 100644
--- a/drivers/video/fbdev/omap/lcd_htcherald.c
+++ b/drivers/video/fbdev/omap/lcd_htcherald.c
@@ -66,3 +66,7 @@ static struct platform_driver htcherald_panel_driver = {
};
module_platform_driver(htcherald_panel_driver);
+
+MODULE_AUTHOR("Cory Maccarrone");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("LCD panel support for the HTC Herald");
diff --git a/drivers/video/fbdev/omap/lcd_inn1510.c
b/drivers/video/fbdev/omap/lcd_inn1510.c
index b284050f5471..8c334858f441 100644
--- a/drivers/video/fbdev/omap/lcd_inn1510.c
+++ b/drivers/video/fbdev/omap/lcd_inn1510.c
@@ -73,3 +73,6 @@ static struct platform_driver innovator1510_panel_driver = {
};
module_platform_driver(innovator1510_panel_driver);
+MODULE_AUTHOR("Imre Deak");
+MODULE_DESCRIPTION("LCD panel support for the TI OMAP1510 Innovator board");
+MODULE_LICENSE("GPL");
diff --git a/drivers/video/fbdev/omap/lcd_inn1610.c
b/drivers/video/fbdev/omap/lcd_inn1610.c
index 1841710e796f..9ca17b33d382 100644
--- a/drivers/video/fbdev/omap/lcd_inn1610.c
+++ b/drivers/video/fbdev/omap/lcd_inn1610.c
@@ -106,3 +106,6 @@ static struct platform_driver innovator1610_panel_driver = {
};
module_platform_driver(innovator1610_panel_driver);
+MODULE_AUTHOR("Imre Deak");
+MODULE_DESCRIPTION("LCD panel support for the TI OMAP1610 Innovator board");
+MODULE_LICENSE("GPL");
diff --git a/drivers/video/fbdev/omap/lcd_osk.c
b/drivers/video/fbdev/omap/lcd_osk.c
index b0be5771fe90..6545de8f6390 100644
--- a/drivers/video/fbdev/omap/lcd_osk.c
+++ b/drivers/video/fbdev/omap/lcd_osk.c
@@ -93,3 +93,7 @@ static struct platform_driver osk_panel_driver = {
};
module_platform_driver(osk_panel_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Imre Deak");
+MODULE_DESCRIPTION("LCD panel support for the TI OMAP OSK board");
diff --git a/drivers/video/fbdev/omap/lcd_palmte.c
b/drivers/video/fbdev/omap/lcd_palmte.c
index cef96386cf80..1d442c19799c 100644
--- a/drivers/video/fbdev/omap/lcd_palmte.c
+++ b/drivers/video/fbdev/omap/lcd_palmte.c
@@ -59,3 +59,6 @@ static struct platform_driver palmte_panel_driver = {
};
module_platform_driver(palmte_panel_driver);
+MODULE_AUTHOR("Romain Goyet ");
+MODULE_DESCRIPTION("LCD panel support for the Palm Tungsten E");
+MODULE_LICENSE("GPL");
diff --git a/drivers/video/fbdev/omap/lcd_palmtt.c
b/drivers/video/fbdev/omap/lcd_palmtt.c
index 627f13dae5ad..0b9f17a0fafe 100644
--- a/drivers/video/fbdev/omap/lcd_palmtt.c
+++ b/drivers/video/fbdev/omap/lcd_palmtt.c
@@ -72,3 +72,6 @@ static struct platform_driver palmtt_p
[Bug 199425] BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260
https://bugzilla.kernel.org/show_bug.cgi?id=199425 --- Comment #8 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- (In reply to mikita.lip...@amd.com from comment #6) > Created attachment 276173 [details] > Patch to either dublicate or reuse an existing crtc state that might pervent > use-after-free error in race condition > > Sorry, the previous patch is irrelevant and was attached by mistake! Please > try the one above. Thanks The patch seems to help. I was running the system the last days without any use-after-free. -- 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 09/12] ARM: dts: exynos5250: add mipi-phy node
On Mon, May 28, 2018 at 11:47 AM, Maciej Purski wrote:
> The patch adds phy node, required by MIPI devices.
>
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Maciej Purski
This have pretty small changes since original Andrzej's patch so
probably Andrzej's authorship should be preserved.
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 2daf505..a63b655 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -733,6 +733,12 @@
> #phy-cells = <0>;
> };
>
> + mipi_phy: video-phy@10040710 {
> + compatible = "samsung,s5pv210-mipi-video-phy";
No DTC warnings (make dtbs W=1)? reg is missing so DTC should complain.
Best regards,
Krzysztof
> + #phy-cells = <1>;
> + syscon = <&pmu_system_controller>;
> + };
> +
> adc: adc@12d1 {
> compatible = "samsung,exynos-adc-v1";
> reg = <0x12D1 0x100>;
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/12] ARM: dts: exynos5250: add DSI node
On Mon, May 28, 2018 at 11:54 AM, Maciej Purski wrote: > The patch adds common part of DSI node for Exynos5250 platforms. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Maciej Purski > --- > arch/arm/boot/dts/exynos5250.dtsi | 14 ++ > 1 file changed, 14 insertions(+) This should be squashed with previous patch because it is logically the same feature. The purpose of PHY is this DSI node so splitting it is slightly too much. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/12] ARM: dts: exynos5250-arndale: add dsi and panel nodes
On Mon, May 28, 2018 at 11:55 AM, Maciej Purski wrote:
> The patch adds bridge and panel nodes.
> It adds also DSI properties specific for arndale board.
>
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Maciej Purski
> ---
> arch/arm/boot/dts/exynos5250-arndale.dts | 39
>
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index 80221fa..6f0b1c4 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -71,6 +71,17 @@
> };
> };
>
> + panel: panel {
> + compatible = "boe,hv070wsa-100";
> + power-supply = <&vcc_3v3_reg>;
> + enable-gpios = <&gpd1 3 GPIO_ACTIVE_HIGH>;
> + port {
> + panel_ep: endpoint {
> + remote-endpoint = <&bridge_out_ep>;
> + };
> + };
> + };
> +
> regulators {
> compatible = "simple-bus";
> #address-cells = <1>;
> @@ -476,6 +487,34 @@
> };
> };
>
> +&dsi_0 {
Please put the node alphabetically, so before &dp.
Also this patch should be squashed with previous one (regulators),
because adding non-controllable fixed regulators on its own does not
bring benefits. Linux will not disable them. You added these
regulators for the bridge below. Without the bridge, their existence
does not have much sense.
Best regards,
Krzysztof
> + vddcore-supply = <&ldo8_reg>;
> + vddio-supply = <&ldo10_reg>;
> + samsung,pll-clock-frequency = <2400>;
> + samsung,burst-clock-frequency = <32000>;
> + samsung,esc-clock-frequency = <1000>;
> + status = "okay";
> +
> + bridge@0 {
> + reg = <0>;
> + compatible = "toshiba,tc358764";
> + vddc-supply = <&vcc_1v2_reg>;
> + vddio-supply = <&vcc_1v8_reg>;
> + vddmipi-supply = <&vcc_1v2_reg>;
> + vddlvds133-supply = <&vcc_3v3_reg>;
> + vddlvds112-supply = <&vcc_1v2_reg>;
> + reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@1 {
> + reg = <1>;
> + bridge_out_ep: endpoint {
> + remote-endpoint = <&panel_ep>;
> + };
> + };
> + };
> +};
> +
> &i2c_2 {
> status = "okay";
> /* used by HDMI DDC */
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb-helper: Fix typo on kerneldoc
On Thu, May 24, 2018 at 04:24:32PM +0200, Noralf Trønnes wrote:
>
> Den 24.05.2018 11.01, skrev Daniel Vetter:
> > Copypasta mistake.
> >
> > Fixes: 742547b73d27 ("drm/fb_helper: Create wrappers for blit, copyarea and
> > fillrect funcs")
> > Cc: Archit Taneja
> > Cc: Daniel Vetter
> > Cc: Gustavo Padovan
> > Cc: Maarten Lankhorst
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 0646b108030b..b7c5ae7f4bd6 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1164,7 +1164,7 @@ EXPORT_SYMBOL(drm_fb_helper_sys_imageblit);
> >* @info: fbdev registered by the helper
> >* @rect: info about rectangle to fill
> >*
> > - * A wrapper around cfb_imageblit implemented by fbdev core
> > + * A wrapper around cfb_fillrect implemented by fbdev core
> >*/
> > void drm_fb_helper_cfb_fillrect(struct fb_info *info,
> > const struct fb_fillrect *rect)
>
> Acked-by: Noralf Trønnes
Applied, thanks for taking a look.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106671] Frequent lock ups for AMD RX 550 graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=106671 --- Comment #4 from Alan W. Irwin --- Hi Michel: I have added your requested attachments. And if there are other data you need or other tests I can run, let me know. Meanwhile, all else seems well with this new computer (e.g., the lock ups are gone under my normal KDE desktop use since I bypassed using this card 3 days ago by displaying my desktop on an X server running on a different computer. But that is only a temporary workaround (another person needs to use that other computer's display and keyboard/mouse). Therefore, I need the RX 550 to work reliably on my new computer which is why I will be following your recommendations with regard to trying the latest kernel, mesa, and (if all else fails) firmware. But building kernel and mesa is going to take me considerable time for the reasons I mentioned in my original post. -- 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 106671] Frequent lock ups for AMD RX 550 graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=106671 --- Comment #3 from Alan W. Irwin --- Created attachment 139817 --> https://bugs.freedesktop.org/attachment.cgi?id=139817&action=edit dmesg output as requested -- 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: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree
> Well done on getting this far. Merging this is definitely going to be > non-trivial. Being out of tree for so long means you've ended up in a > place that will require retracing a bunch of steps to get upstream. > Just to clarify what is going on, while OpenChrome DRM (drm-openchrome repository) has been living outside of the mainline tree since Year 2011, I started tracking drm-next branch of Linux DRM tree very closely since September 2017. The current leading edge OpenChrome DRM code compiles against Linux 4.16, and when drm-next branch is updated to Linux 4.17 rc6 or rc7 code, the drm-next-4.18 branch (the present leading edge branch) will pull in the code. While I have removed drm/via subdirectory from the current drm-next-4.1* branches, I will restore it per your suggestion regarding VIA DRM. That being said, almost all the development activities of OpenChrome DRM goes on inside drm/openchrome subdirectory, and maybe you have some insights I am not aware of, but I would think it is a matter of creating a subdirectory drm/openchrome, and sticking OpenChrome DRM code there. That's how I have developed the code from some point on and have not encountered any side effects due to this. > I'm not going to insist on atomic modesetting, but I think it would > definitely make the driver simpler and easier for someone to review, > and I'm open to Daniel insisting on it. I think you'd be getting close > to clean slating most of this driver at that point, which considering > some bits below might not be the worst idea. > Okay, I will still stay with the position of wanting OpenChrome DRM to be "grandfathered" from the universal plane and atomic mode setting implementations for the initial mainlining, although I am open to those two items being added to the TODO list for the future. > > Other than the universal plane and atomic mode setting, I have several > > other concerns. > > > > 1) James left some unfinished acceleration related code inside OpenChrome > > DRM, but I do not plan to activate it for the initial mainlined version. Do > > I need to remove the code? > > Yes. > Okay, I was thinking I will have to do this, so I wanted to bring it up. I will start working on this in a week or so. > > 2) James appears to have implemented custom Libdrm ABI / API calls. I do > > not plan to activate it for the initial mainlined version. Do I need to > > remove the code? > > Yes. > Same as the previous answer. > > 3) Almost all the functions start with "via_" instead of "openchrome_" at > > this point. Do I need to convert them all to "'openchrome_'?" > > It would be nice, but possibly not essential. > I was thinking I "should" do this, but I wanted to see if the maintainer prefers me to do this. I will start working on this after I get the unfinished acceleration related code removed. > > 4) Is the essentially deprecated VIA DRM going to be removed from the Linux > > kernel tree? VIA DRM is DRI1 based, and OpenChrome DRM supersedes VIA DRM > > for obvious reasons. Since OpenChrome DRM supersedes VIA DRM, I strongly > > support deleting VIA DRM from the Linux kernel tree. > > No, since it shouldn't cause any problems with this, the current via > drm code is only enabled if userspace DRI1 stuff is around, I'm not > even sure there's a mesa driver that can use it at all. > Okay, I will leave VIA DRM alone. If someone else wants to remove it someday, I am okay with that. I believe the DRI1 Mesa code for VIA has been gone since Mesa 8, so nobody really uses VIA DRM anymore other than OpenChrome DDX. OpenChrome DDX can operate without DRI1. That being said, I do have plans to work on updating drm/r128, drm/savage, drm/mga, and drm/sis eventually to support at least KMS using personally developed reusable code base. When this happens (this has not really happened yet due to OpenChrome DRM taking so much of my development time), the existing DRI1 code will need to be tossed out. Will that be okay, or will they need to be implemented in a separate subdirectory? > I'm also not sure how the VIA output bridges are wired up, but we've > grown a lot of code for external bridges now and it might be that the > sil164 stuff could reuse that (or not). > The external video bridge interface (VIA calls it DVP, Digital Video Port) varies by the model, but for your information, OpenChrome DRM supports about 12 different generations of VIA Chrome (not counting S3 Graphics Chrome graphics) integrated graphics. In the Intel graphics world equivalent, it is roughly comparable to Gen 2 to Gen 4 graphics, sans the DirectX 10 functionality from Gen 4. Due to the number of VIA Chrome devices OpenChrome DRM needs to support, I personally prefer having a tighter integration of external transmitters / encoders with the OpenChrome DRM so that the end user has the best user experience. At least for VIA Technologies VT1632(A) DVI transmitter, I have verified full standby resume resto
[Bug 106670] AMD GPU Error, random lockup, Ryzen 2500U Vega 8 GPU
https://bugs.freedesktop.org/show_bug.cgi?id=106670 --- Comment #2 from JerryD --- Created attachment 139819 --> https://bugs.freedesktop.org/attachment.cgi?id=139819&action=edit Full dmesg text dmesg output -- 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 106670] AMD GPU Error, random lockup, Ryzen 2500U Vega 8 GPU
https://bugs.freedesktop.org/show_bug.cgi?id=106670 --- Comment #3 from JerryD --- (In reply to Ernst Sjöstrand from comment #1) > Please post some information about your hardware and the kernel version > you're running. Full dmesg is also good, shows what the driver says when > it's loading. I have attached the dmesg text. I also tried to use ssh from a remote machine to try to 'see' what is going on. The ssh session also completely locks up. I can reproduce this hange when running glxgears with vblank_mode=0. The time it takes is random, something like 10 to 30 minutes. -- 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/exynos: ipp: fix image broken issue
This patch changes userspace parameter but Kernel driver shouldn't touch such
parameter.
Please ignore this patch. Marek will post a generic solution soon, which fixes
the image broken issue without touching userspace parameter.
Thanks,
Inki Dae
2018년 05월 24일 10:04에 Inki Dae 이(가) 쓴 글:
> Fixed image broken issue while video play back with 854x480.
>
> GScaler device of Exynos5433 has IN_ID_MAX field in GSC_IN_CON
> register, which determines how much GScaler DMA has to drain
> data from system memory at once.
>
> Therefore, image size should be fixed up before IPP driver verifies
> whether gem buffer is enough for it or not.
>
> Changelog v2:
> - Fix align limit of image width size to 16bytes because with other values
> , 4 and 8bytes, it doesn't work.
> - Change the function name from gst_get_align_size to gst_set_align_limit.
> gst_set_align_limit function name is more reasonable.
> - Call fixup buffer function before calling size limit check.
> - Remove checking align of image offset, x and y. The offest values have
> no any limit but only size.
>
> Signed-off-by: Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 94
> +++--
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 18 +--
> drivers/gpu/drm/exynos/exynos_drm_ipp.h | 12 +
> 3 files changed, 106 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index e99dd1e..8bc31b5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -86,6 +86,28 @@ struct gsc_scaler {
> unsigned long main_vratio;
> };
>
> +/**
> + * struct gsc_driverdata - per device type driver data for init time.
> + *
> + * @limits: picture size limits array
> + * @clk_names: names of clocks needed by this variant
> + * @num_clocks: the number of clocks needed by this variant
> + * @has_in_ic_max: indicate whether GSCALER_IN_CON register has
> + * IN_IC_MAX field which means maxinum AXI
> + * read capability.
> + * @in_ic_max_shift: indicate which position IN_IC_MAX field is located.
> + * @in_ic_max_mask: A mask value to IN_IC_MAX field.
> + */
> +struct gsc_driverdata {
> + const struct drm_exynos_ipp_limit *limits;
> + int num_limits;
> + const char *clk_names[GSC_MAX_CLOCKS];
> + int num_clocks;
> + unsigned inthas_in_ic_max:1;
> + unsigned intin_ic_max_shift;
> + unsigned intin_ic_max_mask;
> +};
> +
> /*
> * A structure of gsc context.
> *
> @@ -96,6 +118,9 @@ struct gsc_scaler {
> * @id: gsc id.
> * @irq: irq number.
> * @rotation: supports rotation of src.
> + * @align_size: A size that GSC_SRCIMG_WIDTH value of GSC_SRCIMG_SIZE
> + * register should be aligned with(in byte).
> + * @driver_data: a pointer to gsc_driverdata.
> */
> struct gsc_context {
> struct exynos_drm_ipp ipp;
> @@ -114,20 +139,8 @@ struct gsc_context {
> int id;
> int irq;
> boolrotation;
> -};
> -
> -/**
> - * struct gsc_driverdata - per device type driver data for init time.
> - *
> - * @limits: picture size limits array
> - * @clk_names: names of clocks needed by this variant
> - * @num_clocks: the number of clocks needed by this variant
> - */
> -struct gsc_driverdata {
> - const struct drm_exynos_ipp_limit *limits;
> - int num_limits;
> - const char *clk_names[GSC_MAX_CLOCKS];
> - int num_clocks;
> + unsigned int align_size;
> + struct gsc_driverdata *driver_data;
> };
>
> /* 8-tap Filter Coefficient */
> @@ -1095,6 +1108,15 @@ static void gsc_start(struct gsc_context *ctx)
> gsc_write(cfg, GSC_ENABLE);
> }
>
> +static void gsc_fixup(struct exynos_drm_ipp *ipp,
> + struct exynos_drm_ipp_task *task)
> +{
> + struct gsc_context *ctx = container_of(ipp, struct gsc_context, ipp);
> + struct exynos_drm_ipp_buffer *src = &task->src;
> +
> + src->buf.width = ALIGN(src->buf.width, ctx->align_size);
> +}
> +
> static int gsc_commit(struct exynos_drm_ipp *ipp,
> struct exynos_drm_ipp_task *task)
> {
> @@ -1124,6 +1146,41 @@ static int gsc_commit(struct exynos_drm_ipp *ipp,
> return 0;
> }
>
> +static void gsc_set_align_limit(struct gsc_context *ctx)
> +{
> + const struct drm_exynos_ipp_limit *limits = ctx->driver_data->limits;
> +
> + if (ctx->driver_data->has_in_ic_max) {
> + u32 cfg, mask, shift;
> +
> + mask = ctx->driver_data->in_ic_max_mask;
> + shift = ctx->driver_data->in_ic_max_shift;
> +
> + pm_runtime_get_sync(ctx->dev);
> +
> + cfg = gsc_read(GSC_IN_CON);
> +
> + /*
> + * fix align limit to 16bytes. With other limit values, 4
> + * and 8, it doesn't work.
> + */
> + cfg = (cfg & ~(
[PATCH v2] drm/scheduler: add documentation
convert existing raw comments into kernel-doc format as well
as add new documentation
v2: reword the overview
Signed-off-by: Alex Deucher
Signed-off-by: Nayan Deshmukh
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 214 --
include/drm/gpu_scheduler.h | 153 +
2 files changed, 296 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 44d480768dfe..8c1e80c9b674 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -21,6 +21,29 @@
*
*/
+/**
+ * DOC: Overview
+ *
+ * The GPU scheduler provides entities which allow userspace to push jobs
+ * into software queues which are then scheduled on a hardware run queue.
+ * The software queues have a priority among them. The scheduler selects the
entities
+ * from the run queue using a FIFO. The scheduler provides dependency handling
+ * features among jobs. The driver is supposed to provide callback functions
for
+ * backend operations to the scheduler like submitting a job to hardware run
queue,
+ * returning the dependencies of a job etc.
+ *
+ * The organisation of the scheduler is the following:
+ *
+ * 1. Each hw run queue has one scheduler
+ * 2. Each scheduler has multiple run queues with different priorities
+ *(e.g., HIGH_HW,HIGH_SW, KERNEL, NORMAL)
+ * 3. Each scheduler run queue has a queue of entities to schedule
+ * 4. Entities themselves maintain a queue of jobs that will be scheduled on
+ *the hardware.
+ *
+ * The jobs in a entity are always scheduled in the order that they were
pushed.
+ */
+
#include
#include
#include
@@ -39,7 +62,13 @@ static bool drm_sched_entity_is_ready(struct
drm_sched_entity *entity);
static void drm_sched_wakeup(struct drm_gpu_scheduler *sched);
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb
*cb);
-/* Initialize a given run queue struct */
+/**
+ * drm_sched_rq_init - initialize a given run queue struct
+ *
+ * @rq: scheduler run queue
+ *
+ * Initializes a scheduler runqueue.
+ */
static void drm_sched_rq_init(struct drm_sched_rq *rq)
{
spin_lock_init(&rq->lock);
@@ -47,6 +76,14 @@ static void drm_sched_rq_init(struct drm_sched_rq *rq)
rq->current_entity = NULL;
}
+/**
+ * drm_sched_rq_add_entity - add an entity
+ *
+ * @rq: scheduler run queue
+ * @entity: scheduler entity
+ *
+ * Adds a scheduler entity to the run queue.
+ */
static void drm_sched_rq_add_entity(struct drm_sched_rq *rq,
struct drm_sched_entity *entity)
{
@@ -57,6 +94,14 @@ static void drm_sched_rq_add_entity(struct drm_sched_rq *rq,
spin_unlock(&rq->lock);
}
+/**
+ * drm_sched_rq_remove_entity - remove an entity
+ *
+ * @rq: scheduler run queue
+ * @entity: scheduler entity
+ *
+ * Removes a scheduler entity from the run queue.
+ */
static void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
struct drm_sched_entity *entity)
{
@@ -70,9 +115,9 @@ static void drm_sched_rq_remove_entity(struct drm_sched_rq
*rq,
}
/**
- * Select an entity which could provide a job to run
+ * drm_sched_rq_select_entity - Select an entity which could provide a job to
run
*
- * @rq The run queue to check.
+ * @rq: scheduler run queue to check.
*
* Try to find a ready entity, returns NULL if none found.
*/
@@ -112,15 +157,16 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
}
/**
- * Init a context entity used by scheduler when submit to HW ring.
+ * drm_sched_entity_init - Init a context entity used by scheduler when
+ * submit to HW ring.
*
- * @sched The pointer to the scheduler
- * @entity The pointer to a valid drm_sched_entity
- * @rq The run queue this entity belongs
- * @guilty atomic_t set to 1 when a job on this queue
- * is found to be guilty causing a timeout
+ * @sched: scheduler instance
+ * @entity: scheduler entity to init
+ * @rq: the run queue this entity belongs
+ * @guilty: atomic_t set to 1 when a job on this queue
+ * is found to be guilty causing a timeout
*
- * return 0 if succeed. negative error code on failure
+ * Returns 0 on success or a negative error code on failure.
*/
int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
struct drm_sched_entity *entity,
@@ -149,10 +195,10 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
EXPORT_SYMBOL(drm_sched_entity_init);
/**
- * Query if entity is initialized
+ * drm_sched_entity_is_initialized - Query if entity is initialized
*
- * @sched Pointer to scheduler instance
- * @entity The pointer to a valid scheduler entity
+ * @sched: Pointer to scheduler instance
+ * @entity: The pointer to a valid scheduler entity
*
* return true if entity is initialized, false otherwise
*/
@@ -
Re: [Xen-devel] [PATCH 3/8] drm/xen-front: fix 32-bit build warning
Hi,
On 05/25/2018 06:50 PM, Arnd Bergmann wrote:
In 32-bit kernel builds, we cannot cast between a pointer and a 64-bit
type:
In file included from drivers/gpu/drm/xen/xen_drm_front_cfg.c:18:
drivers/gpu/drm/xen/xen_drm_front.h: In function 'xen_drm_front_fb_to_cookie':
drivers/gpu/drm/xen/xen_drm_front.h:129:9: error: cast from pointer to integer
of different size [-Werror=pointer-to-int-cast]
return (u64)fb;
drivers/gpu/drm/xen/xen_drm_front.h: In function 'xen_drm_front_dbuf_to_cookie':
drivers/gpu/drm/xen/xen_drm_front.h:134:9: error: cast from pointer to integer
of different size [-Werror=pointer-to-int-cast]
return (u64)gem_obj;
drivers/gpu/drm/xen/xen_drm_front_shbuf.c: In function 'backend_unmap':
drivers/gpu/drm/xen/xen_drm_front_shbuf.c:125:4: error: cast from pointer to
integer of different size [-Werror=pointer-to-int-cast]
((phys_addr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
Using uintptr_t instead probably does what we want here, although it's
not clear to me why we assign a virtual address pointer to a phys_addr_t
in backend_unmap().
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/xen/xen_drm_front.h | 4 ++--
drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
b/drivers/gpu/drm/xen/xen_drm_front.h
index 2c2479b571ae..5693b4a4b02b 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -126,12 +126,12 @@ struct xen_drm_front_drm_info {
static inline u64 xen_drm_front_fb_to_cookie(struct drm_framebuffer *fb)
{
- return (u64)fb;
+ return (uintptr_t)fb;
}
static inline u64 xen_drm_front_dbuf_to_cookie(struct drm_gem_object *gem_obj)
{
- return (u64)gem_obj;
+ return (uintptr_t)gem_obj;
}
int xen_drm_front_mode_set(struct xen_drm_front_drm_pipeline *pipeline,
diff --git a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
index 8099cb343ae3..d333b67cc1a0 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
@@ -122,7 +122,7 @@ static void guest_calc_num_grefs(struct xen_drm_front_shbuf
*buf)
}
#define xen_page_to_vaddr(page) \
- ((phys_addr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
+ ((uintptr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
static int backend_unmap(struct xen_drm_front_shbuf *buf)
{
Thank you for your patch: this issue was already discussed [1] and
applied [2] to
drm-misc-next.
Thank you,
Oleksandr
[1] https://patchwork.freedesktop.org/patch/224359/
[2] https://patchwork.freedesktop.org/patch/224920/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix possible race conditions while unplugging DRM device
ping
On 05/22/2018 05:13 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
When unplugging a hotpluggable DRM device we first unregister it
with drm_dev_unregister and then set drm_device.unplugged flag which
is used to mark device critical sections with drm_dev_enter()/
drm_dev_exit() preventing access to device resources that are not
available after the device is gone.
But drm_dev_unregister may lead to hotplug uevent(s) fired to
user-space on card and/or connector removal, thus making it possible
for user-space to try accessing a disconnected device.
Fix this by first making sure device is properly marked as
disconnected and only then unregister it.
Fixes: bee330f3d672 ("drm: Use srcu to protect drm_device.unplugged")
Signed-off-by: Oleksandr Andrushchenko
Reported-by: Andrii Chepurnyi
Cc: "Noralf Trønnes"
---
drivers/gpu/drm/drm_drv.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b553a6f2ff0e..7af748ed1c58 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -369,13 +369,6 @@ EXPORT_SYMBOL(drm_dev_exit);
*/
void drm_dev_unplug(struct drm_device *dev)
{
- drm_dev_unregister(dev);
-
- mutex_lock(&drm_global_mutex);
- if (dev->open_count == 0)
- drm_dev_put(dev);
- mutex_unlock(&drm_global_mutex);
-
/*
* After synchronizing any critical read section is guaranteed to see
* the new value of ->unplugged, and any critical section which might
@@ -384,6 +377,13 @@ void drm_dev_unplug(struct drm_device *dev)
*/
dev->unplugged = true;
synchronize_srcu(&drm_unplug_srcu);
+
+ drm_dev_unregister(dev);
+
+ mutex_lock(&drm_global_mutex);
+ if (dev->open_count == 0)
+ drm_dev_put(dev);
+ mutex_unlock(&drm_global_mutex);
}
EXPORT_SYMBOL(drm_dev_unplug);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/scheduler: add documentation
Am 29.05.2018 um 07:53 schrieb Nayan Deshmukh:
convert existing raw comments into kernel-doc format as well
as add new documentation
v2: reword the overview
Signed-off-by: Alex Deucher
Signed-off-by: Nayan Deshmukh
Reviewed-by: Alex Deucher
Reviewed-by: Christian König
Going to push that into our branches later today,
Christian.
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 214 --
include/drm/gpu_scheduler.h | 153 +
2 files changed, 296 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 44d480768dfe..8c1e80c9b674 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -21,6 +21,29 @@
*
*/
+/**
+ * DOC: Overview
+ *
+ * The GPU scheduler provides entities which allow userspace to push jobs
+ * into software queues which are then scheduled on a hardware run queue.
+ * The software queues have a priority among them. The scheduler selects the
entities
+ * from the run queue using a FIFO. The scheduler provides dependency handling
+ * features among jobs. The driver is supposed to provide callback functions
for
+ * backend operations to the scheduler like submitting a job to hardware run
queue,
+ * returning the dependencies of a job etc.
+ *
+ * The organisation of the scheduler is the following:
+ *
+ * 1. Each hw run queue has one scheduler
+ * 2. Each scheduler has multiple run queues with different priorities
+ *(e.g., HIGH_HW,HIGH_SW, KERNEL, NORMAL)
+ * 3. Each scheduler run queue has a queue of entities to schedule
+ * 4. Entities themselves maintain a queue of jobs that will be scheduled on
+ *the hardware.
+ *
+ * The jobs in a entity are always scheduled in the order that they were
pushed.
+ */
+
#include
#include
#include
@@ -39,7 +62,13 @@ static bool drm_sched_entity_is_ready(struct
drm_sched_entity *entity);
static void drm_sched_wakeup(struct drm_gpu_scheduler *sched);
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb
*cb);
-/* Initialize a given run queue struct */
+/**
+ * drm_sched_rq_init - initialize a given run queue struct
+ *
+ * @rq: scheduler run queue
+ *
+ * Initializes a scheduler runqueue.
+ */
static void drm_sched_rq_init(struct drm_sched_rq *rq)
{
spin_lock_init(&rq->lock);
@@ -47,6 +76,14 @@ static void drm_sched_rq_init(struct drm_sched_rq *rq)
rq->current_entity = NULL;
}
+/**
+ * drm_sched_rq_add_entity - add an entity
+ *
+ * @rq: scheduler run queue
+ * @entity: scheduler entity
+ *
+ * Adds a scheduler entity to the run queue.
+ */
static void drm_sched_rq_add_entity(struct drm_sched_rq *rq,
struct drm_sched_entity *entity)
{
@@ -57,6 +94,14 @@ static void drm_sched_rq_add_entity(struct drm_sched_rq *rq,
spin_unlock(&rq->lock);
}
+/**
+ * drm_sched_rq_remove_entity - remove an entity
+ *
+ * @rq: scheduler run queue
+ * @entity: scheduler entity
+ *
+ * Removes a scheduler entity from the run queue.
+ */
static void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
struct drm_sched_entity *entity)
{
@@ -70,9 +115,9 @@ static void drm_sched_rq_remove_entity(struct drm_sched_rq
*rq,
}
/**
- * Select an entity which could provide a job to run
+ * drm_sched_rq_select_entity - Select an entity which could provide a job to
run
*
- * @rq The run queue to check.
+ * @rq: scheduler run queue to check.
*
* Try to find a ready entity, returns NULL if none found.
*/
@@ -112,15 +157,16 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
}
/**
- * Init a context entity used by scheduler when submit to HW ring.
+ * drm_sched_entity_init - Init a context entity used by scheduler when
+ * submit to HW ring.
*
- * @sched The pointer to the scheduler
- * @entity The pointer to a valid drm_sched_entity
- * @rq The run queue this entity belongs
- * @guilty atomic_t set to 1 when a job on this queue
- * is found to be guilty causing a timeout
+ * @sched: scheduler instance
+ * @entity: scheduler entity to init
+ * @rq: the run queue this entity belongs
+ * @guilty: atomic_t set to 1 when a job on this queue
+ * is found to be guilty causing a timeout
*
- * return 0 if succeed. negative error code on failure
+ * Returns 0 on success or a negative error code on failure.
*/
int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
struct drm_sched_entity *entity,
@@ -149,10 +195,10 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
EXPORT_SYMBOL(drm_sched_entity_init);
/**
- * Query if entity is initialized
+ * drm_sched_entity_is_initialized - Query if entity is initialized
*
- * @sched Pointer to scheduler instance
- * @entity The pointer t
Re: [PATCH v7 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
On 24.05.2018 18:41, Sandeep Panda wrote:
> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
>
> Changes in v1:
> - Rephrase the dt-binding descriptions to be more inline with existing
>bindings (Andrzej Hajda).
> - Add missing dt-binding that are parsed by corresponding driver
>(Andrzej Hajda).
>
> Changes in v2:
> - Remove edp panel specific dt-binding entries. Only keep bridge
>specific entries (Sean Paul).
> - Remove custom-modes dt entry since its usage is removed from driver also
> (Sean Paul).
> - Remove is-pluggable dt entry since this will not be needed anymore (Sean
> Paul).
>
> Changes in v3:
> - Remove irq-gpio dt entry and instead populate is an interrupt
>property (Rob Herring).
>
> Changes in v4:
> - Add link to bridge chip datasheet (Stephen Boyd)
> - Add vpll and vcc regulator supply bindings (Stephen Boyd)
> - Add ref clk optional dt binding (Stephen Boyd)
> - Add gpio-controller optional dt binding (Stephen Boyd)
>
> Changes in v5:
> - Use clock property to specify the input refclk (Stephen Boyd).
> - Update gpio cell and pwm cell numbers (Stephen Boyd).
>
> Changes in v6:
> - Add property to mention the lane mapping scheme and polarity inversion
>(Stephen Boyd).
>
> Signed-off-by: Sandeep Panda
> ---
> .../bindings/display/bridge/ti,sn65dsi86.txt | 89
> ++
> 1 file changed, 89 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> new file mode 100644
> index 000..4a771a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> @@ -0,0 +1,89 @@
> +SN65DSI86 DSI to eDP bridge chip
> +
> +
> +This is the binding for Texas Instruments SN65DSI86 bridge.
> +http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
> +
> +Required properties:
> +- compatible: Must be "ti,sn65dsi86"
> +- reg: i2c address of the chip, 0x2d as per datasheet
> +- enable-gpios: OF device-tree gpio specification for bridge_en pin
info about active high should be added
> +
> +- vccio-supply: A 1.8V supply that powers up the digital IOs.
> +- vpll-supply: A 1.8V supply that powers up the displayport PLL.
> +- vcca-supply: A 1.2V supply that powers up the analog circuits.
> +- vcc-supply: A 1.2V supply that powers up the digital core.
> +
> +Optional properties:
> +- interrupts: Specifier for the SN65DSI86 interrupt line.
> +- hpd-gpios: Specifications for HPD gpio pin.
Again, please specify active level.
> +
> +- gpio-controller: Marks the device has a GPIO controller.
> +- #gpio-cells: Should be two. The first cell is the pin number and
> + the second cell is used to specify flags.
> + See ../../gpio/gpio.txt for more information.
> +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of
> + the cell formats.
> +
> +- clock-names: should be "refclk"
> +- clocks: Specification for input reference clock. The reference
> + clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
> +
> +- lane-config: Specification to describe the logical to physical lane
> +mapping scheme and polarity inversion of lanes.
Please describe this property, I guess it is about DSI lanes, and it
should be exact(?) four pair of numbers, what are meaning and ranges of
both numbers. What should be assumed if property is not present. Btw you
can look into other bindings for reference, I guess there are already
bindings having such property.
Regards
Andrzej
> +
> +Required nodes:
> +
> +This device has two video ports. Their connections are modelled using the
> +OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 for DSI input
> +- Video port 1 for eDP output
> +
> +Example
> +---
> +
> +edp-bridge@2d {
> + compatible = "ti,sn65dsi86";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x2d>;
> +
> + enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
> +
> + vccio-supply = <&pm8916_l17>;
> + vcca-supply = <&pm8916_l6>;
> + vpll-supply = <&pm8916_l17>;
> + vcc-supply = <&pm8916_l6>;
> +
> + clock-names = "refclk";
> + clocks = <&input_refclk>;
> +
> + lane-config = <0 0>, /* Lane 0 logical is lane 0 phys (!inv) */
> + <1 1>, /* Lane 1 logical is lane 1 phys (inv) */
> + <2 0>, /* Lane 2 logical is lane 2 phys (!inv) */
> + <3 1>; /* Lane 3 logical is lane 3 phys (inv) */
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <
Re: [PATCH v2 0/6] drm/omap: Module parameter for display order configuration
On Mon, May 28, 2018 at 02:44:28PM +0300, Tomi Valkeinen wrote: > Hi, > > On 28/05/18 13:55, Pekka Paalanen wrote: > > >> The series adds support for changing the order of the displays defined by > >> DT > >> display aliases. > >> > >> The motivation to do such a thing is that for example the fb emulation is > >> treating the first display/crtc as the 'main' display and will create the > >> fb emulation based on the first display's properties. > > > > Hi, > > > > catering for fbdev seems strange to me. But if you do care, why is this > > Strange how? Because we should get rid of it? Sure. But it's there, and > it's being used by almost everyone, at least in the form of fb console. > > > a driver-specific option instead of a generic DRM fb emulation > > configuration option? > > That'd be fine for me, but I think the actual code to do this > "create-connectors-in-this-order" work is still driver specific. Perhaps > we could have a simple option to just choose the "main" display for > fbdev (without chaing the way the connectors are created), though, which > could perhaps be common code. Thus far the rules has been that we try to put the integrated panel first, and that's it. See drm_helper_move_panel_connectors_to_head(). If there's any standard, then imo that's it. Not a more generic "the first display is the preferred one" because frankly we don't know that - or how do you guess that I want to use my laptop just as a work-station, and never use the integrated panel when the hdmi thing is connected? You need configurability in userspace and fbdev for that. And yes, for fbdev some fbdev option would probably be best. We already have options/parsing to disable/force certain connectors, we could also have another flag to designate it the preferred primary. Also, the only thing where primary/secondary matters for fbdev emulation is for the vblank handling. Afaiui that was added for the gpu blob drivers being stupid and refusing to use kms. Definitely don't want to add huge driver-specific hacks for that :-) > >> There are many custom applications using DRM directly and they assume that > >> the > >> first connector is the 'main' display. > > > > This is very unfortunate, but I still think it would be better to fix > > all those apps than patch kernel drivers one at a time to cater for > > user preferences with driver-specific kernel options. > > I agree, but it's still a problem because we don't have access to those > apps. And they keep popping up when e.g. being used on a new platform > with multiple displays. > > >> Afaik weston provides no means either to change the 'main/preferred' > >> display. > > > > Please, do not use Weston as justification for this. If you have window > > positioning problems in Weston, please come talk to us on #wayland or > > wayland-devel@, so we can discuss what you *actually* need. > > Weston is just one piece of the puzzle. If Weston was the only problem, > then yes, we'd be working on Weston. But it's the combination of fbdev, > custom DRM based apps and Weston. > > > Weston's behaviour in this respect has not been even defined yet, which > > makes a kernel option to work around it ever more awkward. > > > > The reason why Weston lacks this kind of configurability is that no-one > > has needed it yet, I mean, come forth with a proposal, as far as I can > > recall. If people keep working around it elsewhere, it is unlikely Weston > > ever gets it. > > > >> It should be the work of user space application (except the fb emulation) > >> to > >> somehow deal with the 'main' display selection for their needs, but > >> unfortunately they are not capable of diong so for some reason. > > > > Aside from Weston, which apps are these? > > Mostly custom proprietary apps. But I think also Qt's DRM backend had > this problem, although I might remember wrong or it might have been > improved. > > Overall, I don't like these module parameters much. But they did solve > issues our customers were having quite easily. > > I am fine with dropping this from mainline, and just carrying it in the > TI kernel until we've come up with other solutions to the problems. Imo the fbdev one makes some sense, but if the only reason for it is the userspace gpu blob maybe not so much. For everything else, you need some form of configuration in userspace anyway. KMS doesn't have a concept of "primary" display, and I have no idea how we'd even make that happen everywhere. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: vgem: Change return type to vm_fault_t
On Thu, May 24, 2018 at 07:51:40PM +0530, Souptick Joarder wrote:
> On Thu, May 24, 2018 at 6:27 PM, Daniel Vetter wrote:
> > On Wed, May 23, 2018 at 03:05:35PM +0530, Souptick Joarder wrote:
> >> On Mon, May 14, 2018 at 9:56 PM, Daniel Vetter wrote:
> >> > On Thu, May 10, 2018 at 02:51:38PM -0400, Sean Paul wrote:
> >> >> On Thu, May 10, 2018 at 07:58:11PM +0530, Souptick Joarder wrote:
> >> >> > Hi Sean,
> >> >> >
> >> >> > On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder
> >> >> > wrote:
> >> >> > > Use new return type vm_fault_t for fault handler.
> >> >> > >
> >> >> > > Signed-off-by: Souptick Joarder
> >> >> > > Reviewed-by: Matthew Wilcox
> >> >> > > ---
> >> >> > > drivers/gpu/drm/vgem/vgem_drv.c | 5 ++---
> >> >> > > 1 file changed, 2 insertions(+), 3 deletions(-)
> >> >> > >
> >> >> > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
> >> >> > > b/drivers/gpu/drm/vgem/vgem_drv.c
> >> >> > > index 2524ff1..c64a859 100644
> >> >> > > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> >> >> > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> >> >> > > @@ -61,13 +61,13 @@ static void vgem_gem_free_object(struct
> >> >> > > drm_gem_object *obj)
> >> >> > > kfree(vgem_obj);
> >> >> > > }
> >> >> > >
> >> >> > > -static int vgem_gem_fault(struct vm_fault *vmf)
> >> >> > > +static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> >> >> > > {
> >> >> > > struct vm_area_struct *vma = vmf->vma;
> >> >> > > struct drm_vgem_gem_object *obj = vma->vm_private_data;
> >> >> > > /* We don't use vmf->pgoff since that has the fake offset */
> >> >> > > unsigned long vaddr = vmf->address;
> >> >> > > - int ret;
> >> >> > > + vm_fault_t ret = VM_FAULT_SIGBUS;
> >> >> > > loff_t num_pages;
> >> >> > > pgoff_t page_offset;
> >> >> > > page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
> >> >> > > @@ -77,7 +77,6 @@ static int vgem_gem_fault(struct vm_fault *vmf)
> >> >> > > if (page_offset > num_pages)
> >> >> > > return VM_FAULT_SIGBUS;
> >> >> > >
> >> >> > > - ret = -ENOENT;
> >> >> > > mutex_lock(&obj->pages_lock);
> >> >> > > if (obj->pages) {
> >> >> > > get_page(obj->pages[page_offset]);
> >> >> > > --
> >> >> > > 1.9.1
> >> >> > >
> >> >> >
> >> >> > Any further comment on this patch ?
> >> >>
> >> >> Patch looks good to me. My build test fails, though, since vm_fault_t
> >> >> doesn't
> >> >> exist in drm-misc-next yet.
> >> >
> >> > vm_fault_t is already in upstream, just needs Maarten to do a backmerge.
> >> > Which I think he's done by now ... Otherwise nag him more :-)
> >> > -Daniel
> >> >
> >> >>
> >> >> So, for now,
> >> >>
> >> >> Reviewed-by: Sean Paul
> >> >>
> >> >>
> >> >> --
> >> >> Sean Paul, Software Engineer, Google / Chromium OS
> >> >> ___
> >> >> dri-devel mailing list
> >> >> dri-devel@lists.freedesktop.org
> >> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >> >
> >> > --
> >> > Daniel Vetter
> >> > Software Engineer, Intel Corporation
> >> > http://blog.ffwll.ch
> >>
> >> Daniel/ Sean, is this patch already merged for 4.18 ?
> >
> > Nope, fell through the cracks. Thanks for the reminder, queued for 4.18
> > now.
> > -Daniel
>
> Thanks Daniel :).
> Few other similar drm driver patches are also candidates
> for 4.18. Are you the right Maintainer to make a request
> for the same ?
No, please try to find others. I'm occasionally picking stuff up that fell
through all the cracks, as a last resort, but if I make that a habit then
this doesn't scale. Please check with MAINTAINERS who's more appropriate
to get nag mails from you :-)
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: udl: Destroy framebuffer only if it was initialized
On Mon, May 28, 2018 at 04:27:11PM +0200, Emil Lundmark wrote:
> This fixes a NULL pointer dereference that can happen if the UDL
> driver is unloaded before the framebuffer is initialized. This can
> happen e.g. if the USB device is unplugged right after it was plugged
> in.
>
> As explained by Stéphane Marchesin:
>
> It happens when fbdev is disabled (which is the case for Chrome OS).
> Even though intialization of the fbdev part is optional (it's done in
> udlfb_create which is the callback for fb_probe()), the teardown isn't
> optional (udl_driver_unload -> udl_fbdev_cleanup ->
> udl_fbdev_destroy).
>
> Note that udl_fbdev_cleanup *tries* to be conditional (you can see it
> does if (!udl->fbdev)) but that doesn't work, because udl->fbdev is
> always set during udl_fbdev_init.
>
> Suggested-by: Sean Paul
> Signed-off-by: Emil Lundmark
You lost the r-b from Sean when resending, I'll leave that to Sean to
readd when he merges. Anyway, lgtm now with the more detailed explanation.
Acked-by: Daniel Vetter
> ---
> Changes in v2:
> - Updated commit message with explanation from Stéphane Marchesin
>
> drivers/gpu/drm/udl/udl_fb.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index 2ebdc6d5a76e..5754e37f741b 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -426,9 +426,11 @@ static void udl_fbdev_destroy(struct drm_device *dev,
> {
> drm_fb_helper_unregister_fbi(&ufbdev->helper);
> drm_fb_helper_fini(&ufbdev->helper);
> - drm_framebuffer_unregister_private(&ufbdev->ufb.base);
> - drm_framebuffer_cleanup(&ufbdev->ufb.base);
> - drm_gem_object_put_unlocked(&ufbdev->ufb.obj->base);
> + if (ufbdev->ufb.obj) {
> + drm_framebuffer_unregister_private(&ufbdev->ufb.base);
> + drm_framebuffer_cleanup(&ufbdev->ufb.base);
> + drm_gem_object_put_unlocked(&ufbdev->ufb.obj->base);
> + }
> }
>
> int udl_fbdev_init(struct drm_device *dev)
> --
> 2.17.0.921.gf22659ad46-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
Hi Morimoto-san,
On Tue, May 29, 2018 at 3:44 AM, Kuninori Morimoto
wrote:
>> > +&hdmi0_con {
>> > + remote-endpoint = <&rcar_dw_hdmi0_out>;
>> > +};
>>
>> I think the hdmi0 and hdmi0_con parts can be moved to salvator-common.dtsi.
>> Can we do that now (with stubs?), or does this have to wait until r8a77965
>> has
>> received HDMI sound support?
>
> HDMI sound doesn't use hdmi0_con.
> You can do it now, thanks
Thanks, so hdmi0_con can be moved now.
But HDMI sound does use hdmi0/ports/port@2. right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 30/41] drm/i915: Initialize HDCP2.2 and its MEI interface
On Fri, May 25, 2018 at 04:42:52PM +0530, Ramalingam C wrote:
>
>
> On Thursday 24 May 2018 01:36 PM, Daniel Vetter wrote:
> > On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C wrote:
> > > Initialize HDCP2.2 support. This includes the mei interface
> > > initialization along with required notifier registration.
> > >
> > > v2:
> > >mei interface handle is protected with mutex. [Chris Wilson]
> > > v3:
> > >Notifiers are used for the mei interface state.
> > > v4:
> > >Poll for mei client device state
> > >Error msg for out of mem [Uma]
> > >Inline req for init function removed [Uma]
> > >
> > > Signed-off-by: Ramalingam C
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 3 +-
> > > drivers/gpu/drm/i915/intel_drv.h | 5 +-
> > > drivers/gpu/drm/i915/intel_hdcp.c | 117
> > > +-
> > > drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
> > > 4 files changed, 122 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 62f82c4298ac..276eb49113e9 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -6368,7 +6368,8 @@ intel_dp_init_connector(struct intel_digital_port
> > > *intel_dig_port,
> > > intel_dp_add_properties(intel_dp, connector);
> > > if (is_hdcp_supported(dev_priv, port) &&
> > > !intel_dp_is_edp(intel_dp)) {
> > > - int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
> > > + int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim,
> > > + false);
> > > if (ret)
> > > DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
> > > }
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index ac943ec73987..750fc19f 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -442,7 +442,7 @@ struct intel_hdcp {
> > > /* mei interface related information */
> > > struct mei_cl_device *cldev;
> > > struct mei_hdcp_data mei_data;
> > > -
> > > + struct notifier_block mei_cldev_nb;
> > > struct delayed_work hdcp2_check_work;
> > > };
> > > @@ -1940,7 +1940,8 @@ void intel_hdcp_atomic_check(struct drm_connector
> > > *connector,
> > >struct drm_connector_state *old_state,
> > >struct drm_connector_state *new_state);
> > > int intel_hdcp_init(struct intel_connector *connector,
> > > - const struct intel_hdcp_shim *hdcp_shim);
> > > + const struct intel_hdcp_shim *hdcp_shim,
> > > + bool hdcp2_supported);
> > > int intel_hdcp_enable(struct intel_connector *connector);
> > > int intel_hdcp_disable(struct intel_connector *connector);
> > > int intel_hdcp_check_link(struct intel_connector *connector);
> > > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> > > b/drivers/gpu/drm/i915/intel_hdcp.c
> > > index f3f935046c31..9948e4b4e203 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > > @@ -11,6 +11,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include "intel_drv.h"
> > > #include "i915_reg.h"
> > > @@ -25,6 +26,7 @@ static int _intel_hdcp2_enable(struct intel_connector
> > > *connector);
> > > static int _intel_hdcp2_disable(struct intel_connector *connector);
> > > static void intel_hdcp2_check_work(struct work_struct *work);
> > > static int intel_hdcp2_check_link(struct intel_connector *connector);
> > > +static int intel_hdcp2_init(struct intel_connector *connector);
> > > static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> > > *intel_dig_port,
> > > const struct intel_hdcp_shim *shim)
> > > @@ -766,11 +768,15 @@ bool is_hdcp_supported(struct drm_i915_private
> > > *dev_priv, enum port port)
> > > }
> > > int intel_hdcp_init(struct intel_connector *connector,
> > > - const struct intel_hdcp_shim *hdcp_shim)
> > > + const struct intel_hdcp_shim *hdcp_shim,
> > > + bool hdcp2_supported)
> > > {
> > > struct intel_hdcp *hdcp = &connector->hdcp;
> > > int ret;
> > > + if (!hdcp_shim)
> > > + return -EINVAL;
> > > +
> > > ret = drm_connector_attach_content_protection_property(
> > > &connector->base);
> > > if (ret)
> > > @@ -779,7 +785,12 @@ int intel_hdcp_init(struct intel_connector
> > > *connector,
> > > hdcp->hdcp_shim = hdcp_shim;
> > > mutex_init(&hdcp->hdcp_mutex);
> > > INIT_DELAYED_WORK(&hdcp->hdcp_check_work,
> > > intel_hdcp_check_work);
> > > + INIT_DELAYED_WORK(&hdcp->hdcp2_check_work, intel_hdcp2_check_work);
> > >
Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2
On Mon, May 21, 2018 at 06:23:19PM +0530, Ramalingam C wrote: > The sequence for HDCP2.2 authentication and encryption is implemented > in I915. Encoder specific implementations are moved into hdcp_shim. > > Intel HWs supports HDCP2.2 through ME FW. Hence this series > introduces a client driver for mei bus, so that for HDCP2.2 > authentication, HDCP2.2 stack in I915 can avail the services from > ME FW. > > DRM_I915 selects INTEL_MEI_HDCP, which selects INTEL_MEI_ME and > INTEL_MEI. If we are interested in disabling the MEI_HDCP and MEI Bus > then we need an option to disable the HDCP2.2 in I915 > (like DRM_I915_HDCP2.2!?). Till then they are binded. > > Userspace interface remains unchanged as version agnostic. When > userspace request for HDCP enable, Kernel will detect the HDCP source > and sink's HDCP version(1.4/2.2)capability and enable the best capable > version for that combination. > > This series enables the HDCP2.2 for Type0 content streams. > > Thanks a lot for Usyskin, Alexander and Uma shankar for the review of v3. > Thanks Daniel vetter for guiding me to test and confirm that there is no > locking issue with respect to notifier usage between I915 and MEI_HDCP. > > Major Changes in v4: > - GMBus Changes to implement the burst read as generic > [Jani, Ville and Daniel] > - Polling is added for extra Notifier notification when I915 and > MEI_HDCP are modules. > - Comment and style issues and typos are fixed [Uma and Alexander] > - INTEL_MEI_HDCP, INTEL_MEI_ME and INTEL_MEI are selected by I915. > - Fixed the #if in include/linux/mei_hdcp.h for build issues. > > GMBus changes are added here for completeness of the series. They are > in review at https://patchwork.freedesktop.org/series/41632/ also. Please reply with a link to your github here (and include it in your next cover letter too). I can't ever find it when I need it :-/ Thanks, Daniel > > Ramalingam C (40): > drm: hdcp2.2 authentication msg definitions > drm: HDMI and DP specific HDCP2.2 defines > misc/mei/hdcp: Client driver for HDCP application > misc/mei/hdcp: Notifier chain for mei cldev state change > misc/mei/hdcp: Define ME FW interface for HDCP2.2 > linux/mei: Header for mei_hdcp driver interface > misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session > misc/mei/hdcp: Verify Receiver Cert and prepare km > misc/mei/hdcp: Verify H_prime > misc/mei/hdcp: Store the HDCP Pairing info > misc/mei/hdcp: Initiate Locality check > misc/mei/hdcp: Verify L_prime > misc/mei/hdcp: Prepare Session Key > misc/mei/hdcp: Repeater topology verification and ack > misc/mei/hdcp: Verify M_prime > misc/mei/hdcp: Enabling the HDCP authentication > misc/mei/hdcp: Closing wired HDCP2.2 Tx Session > drm/i915: wrapping all hdcp var into intel_hdcp > drm/i915: Define HDCP2.2 related variables > drm/i915: Define Intel HDCP2.2 registers > drm/i915: Wrappers for mei HDCP2.2 services > drm/i915: Implement HDCP2.2 receiver authentication > drm/i915: Implement HDCP2.2 repeater authentication > drm/i915: Enable and Disable HDCP2.2 port encryption > drm/i915: Implement HDCP2.2 En/Dis-able > drm/i915: Implement HDCP2.2 link integrity check > drm/i915: Handle HDCP2.2 downstream topology change > drm/i915: Pullout the bksv read and validation > drm/i915: Initialize HDCP2.2 and its MEI interface > drm/i915: Schedule hdcp_check_link in _intel_hdcp_enable > drm/i915: Enable superior HDCP ver that is capable > drm/i915: Enable HDCP1.4 incase of HDCP2.2 failure > drm/i915: hdcp_check_link only on CP_IRQ > drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ > drm/i915/gmbus: Increase the Bytes per Rd/Wr Op > drm/i915/gmbus: Enable burst read > drm/i915: Implement the HDCP2.2 support for DP > drm/i915: Implement the HDCP2.2 support for HDMI > drm/i915: Add HDCP2.2 support for DP connectors > drm/i915: Add HDCP2.2 support for HDMI connectors > > Tomas Winkler (1): > mei: bus: whitelist hdcp client > > drivers/gpu/drm/i915/Kconfig |1 + > drivers/gpu/drm/i915/i915_drv.h |3 + > drivers/gpu/drm/i915/i915_reg.h | 34 ++ > drivers/gpu/drm/i915/intel_display.c |7 +- > drivers/gpu/drm/i915/intel_dp.c | 370 +++- > drivers/gpu/drm/i915/intel_drv.h | 88 ++- > drivers/gpu/drm/i915/intel_hdcp.c| 1096 > -- > drivers/gpu/drm/i915/intel_hdmi.c| 189 +- > drivers/gpu/drm/i915/intel_i2c.c | 71 ++- > drivers/misc/mei/Kconfig |7 + > drivers/misc/mei/Makefile|2 + > drivers/misc/mei/bus-fixup.c | 16 + > drivers/misc/mei/hdcp/Makefile |6 + > drivers/misc/mei/hdcp/mei_hdcp.c | 817 + > drivers/misc/mei/hdcp/mei_hdcp.h | 415 + > include/drm/drm_dp_helper.h | 51 ++ > include/drm/drm_hdcp.h | 232 +++ > include/linux/mei_hdcp.h | 232 +++
Re: [PATCH] gpu: drm: drm_vm: Adding new typedef vm_fault_t
On Fri, May 25, 2018 at 02:00:33AM +0530, Souptick Joarder wrote:
> On Wed, May 16, 2018 at 10:09 AM, Souptick Joarder
> wrote:
> > On Thu, May 10, 2018 at 7:12 PM, Souptick Joarder
> > wrote:
> >> Use new return type vm_fault_t for fault handler. For
> >> now, this is just documenting that the function returns
> >> a VM_FAULT value rather than an errno. Once all instances
> >> are converted, vm_fault_t will become a distinct type.
> >>
> >> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
> >>
> >> Signed-off-by: Souptick Joarder
> >> Reviewed-by: Matthew Wilcox
> >> ---
> >> drivers/gpu/drm/drm_vm.c | 10 +-
> >> 1 file changed, 5 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> >> index 2660543..c330104 100644
> >> --- a/drivers/gpu/drm/drm_vm.c
> >> +++ b/drivers/gpu/drm/drm_vm.c
> >> @@ -100,7 +100,7 @@ static pgprot_t drm_dma_prot(uint32_t map_type, struct
> >> vm_area_struct *vma)
> >> * map, get the page, increment the use count and return it.
> >> */
> >> #if IS_ENABLED(CONFIG_AGP)
> >> -static int drm_vm_fault(struct vm_fault *vmf)
> >> +static vm_fault_t drm_vm_fault(struct vm_fault *vmf)
> >> {
> >> struct vm_area_struct *vma = vmf->vma;
> >> struct drm_file *priv = vma->vm_file->private_data;
> >> @@ -173,7 +173,7 @@ static int drm_vm_fault(struct vm_fault *vmf)
> >> return VM_FAULT_SIGBUS; /* Disallow mremap */
> >> }
> >> #else
> >> -static int drm_vm_fault(struct vm_fault *vmf)
> >> +static vm_fault_t drm_vm_fault(struct vm_fault *vmf)
> >> {
> >> return VM_FAULT_SIGBUS;
> >> }
> >> @@ -189,7 +189,7 @@ static int drm_vm_fault(struct vm_fault *vmf)
> >> * Get the mapping, find the real physical page to map, get the page, and
> >> * return it.
> >> */
> >> -static int drm_vm_shm_fault(struct vm_fault *vmf)
> >> +static vm_fault_t drm_vm_shm_fault(struct vm_fault *vmf)
> >> {
> >> struct vm_area_struct *vma = vmf->vma;
> >> struct drm_local_map *map = vma->vm_private_data;
> >> @@ -291,7 +291,7 @@ static void drm_vm_shm_close(struct vm_area_struct
> >> *vma)
> >> *
> >> * Determine the page number from the page offset and get it from
> >> drm_device_dma::pagelist.
> >> */
> >> -static int drm_vm_dma_fault(struct vm_fault *vmf)
> >> +static vm_fault_t drm_vm_dma_fault(struct vm_fault *vmf)
> >> {
> >> struct vm_area_struct *vma = vmf->vma;
> >> struct drm_file *priv = vma->vm_file->private_data;
> >> @@ -326,7 +326,7 @@ static int drm_vm_dma_fault(struct vm_fault *vmf)
> >> *
> >> * Determine the map offset from the page offset and get it from
> >> drm_sg_mem::pagelist.
> >> */
> >> -static int drm_vm_sg_fault(struct vm_fault *vmf)
> >> +static vm_fault_t drm_vm_sg_fault(struct vm_fault *vmf)
> >> {
> >> struct vm_area_struct *vma = vmf->vma;
> >> struct drm_local_map *map = vma->vm_private_data;
> >> --
> >> 1.9.1
> >>
> >
> > Daniel, if no further comment, we would like to get this patch
> > in queue for 4.18.
>
> We would like to get this in queue for 4.18.
Ok this dri1 legacy horrors, so I'm the fallback maintainer once more :-)
Merged, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
