Re: [PATCH v7 1/6] drm/tidss: Remove Video Port to Output Port coupling
On 06/02/2023 19:34, Aradhya Bhatia wrote:
On 06-Feb-23 18:35, Tomi Valkeinen wrote:
On 05/02/2023 15:08, Aradhya Bhatia wrote:
Hi Tomi,
Thanks for the review!
On 03-Feb-23 16:53, Tomi Valkeinen wrote:
On 25/01/2023 13:35, Aradhya Bhatia wrote:
Make DSS Video Ports agnostic of output bus types.
DSS controllers have had a 1-to-1 coupling between its VPs and its
output ports. This no longer stands true for the new AM625 DSS. This
coupling, hence, has been removed by renaming the 'vp_bus_type' to
'output_port_bus_type' because the VPs are essentially agnostic of the
bus type and it is the output ports which have a bus type.
The AM625 DSS has 2 VPs but requires 3 output ports to support its
Dual-Link OLDI video output coming from a single VP.
Not a biggie, but this sentence is a bit odd here at the end. Shouldn't
it be after the "...stands true for the new AM625 DSS."?
Yes! It should be. Will make the edit.
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/tidss/tidss_dispc.c | 47 +
drivers/gpu/drm/tidss/tidss_dispc.h | 21 +++--
drivers/gpu/drm/tidss/tidss_drv.h | 5 +--
drivers/gpu/drm/tidss/tidss_irq.h | 2 +-
drivers/gpu/drm/tidss/tidss_kms.c | 12
5 files changed, 48 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 165365b515e1..c1c4faccbddc 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -61,7 +61,7 @@ const struct dispc_features dispc_k2g_feats = {
.min_pclk_khz = 4375,
.max_pclk_khz = {
- [DISPC_VP_DPI] = 15,
+ [DISPC_PORT_DPI] = 15,
},
/*
@@ -96,7 +96,6 @@ const struct dispc_features dispc_k2g_feats = {
.vp_name = { "vp1" },
.ovr_name = { "ovr1" },
.vpclk_name = { "vp1" },
- .vp_bus_type = { DISPC_VP_DPI },
.vp_feat = { .color = {
.has_ctm = true,
@@ -109,6 +108,9 @@ const struct dispc_features dispc_k2g_feats = {
.vid_name = { "vid1" },
.vid_lite = { false },
.vid_order = { 0 },
+
+ .num_output_ports = 1,
+ .output_port_bus_type = { DISPC_PORT_DPI },
};
Just thinking out loud, as these will get more complex in the future,
maybe we should finally group them with struct. E.g. we could define
struct array for vps, like (just hacky example):
struct {
const char *name;
const char *clkname;
struct tidss_vp_feat feat;
} vps[TIDSS_MAX_PORTS];
and then use them as:
.vps = {
{
.name = "kala",
.clkname = "kissa",
.feat.color.has_ctm = true,
}, {
.name = "kala2",
.clkname = "kissa2",
.feat.color.has_ctm = false,
},
},
Perhaps something to try in the future.
Yes, agreed! Having that structure will tidy this up.
I will keep this under future work.
static const u16 tidss_am65x_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
@@ -140,8 +142,8 @@ static const u16
tidss_am65x_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
const struct dispc_features dispc_am65x_feats = {
.max_pclk_khz = {
- [DISPC_VP_DPI] = 165000,
- [DISPC_VP_OLDI] = 165000,
+ [DISPC_PORT_DPI] = 165000,
+ [DISPC_PORT_OLDI] = 165000,
},
.scaling = {
@@ -171,7 +173,6 @@ const struct dispc_features dispc_am65x_feats = {
.vp_name = { "vp1", "vp2" },
.ovr_name = { "ovr1", "ovr2" },
.vpclk_name = { "vp1", "vp2" },
- .vp_bus_type = { DISPC_VP_OLDI, DISPC_VP_DPI },
.vp_feat = { .color = {
.has_ctm = true,
@@ -185,6 +186,9 @@ const struct dispc_features dispc_am65x_feats = {
.vid_name = { "vid", "vidl1" },
.vid_lite = { false, true, },
.vid_order = { 1, 0 },
+
+ .num_output_ports = 2,
+ .output_port_bus_type = { DISPC_PORT_OLDI, DISPC_PORT_DPI },
};
static const u16 tidss_j721e_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
@@ -229,8 +233,8 @@ static const u16
tidss_j721e_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
const struct dispc_features dispc_j721e_feats = {
.max_pclk_khz = {
- [DISPC_VP_DPI] = 17,
- [DISPC_VP_INTERNAL] = 60,
+ [DISPC_PORT_DPI] = 17,
+ [DISPC_PORT_INTERNAL] = 60,
},
.scaling = {
@@ -260,9 +264,7 @@ const struct dispc_features dispc_j721e_feats = {
.vp_name = { "vp1", "vp2", "vp3", "vp4" },
.ovr_name = { "ovr1", "ovr2", "ovr3", "ovr4" },
.vpclk_name = { "vp1", "vp2", "vp3", "vp4" },
- /* Currently hard coded VP routing (see dispc_initial_config()) */
- .vp_bus_type = { DISPC_VP_INTERNAL, DISPC_VP_DPI,
- DISPC_VP_INTERNAL, DISPC_VP_DPI, },
+
I think this line feed is extra.
Okay! Will remove that from all SoC feat structs.
.vp_
Re: [PATCH v7 1/6] drm/tidss: Remove Video Port to Output Port coupling
On 06-Feb-23 18:35, Tomi Valkeinen wrote:
> On 05/02/2023 15:08, Aradhya Bhatia wrote:
>> Hi Tomi,
>>
>> Thanks for the review!
>>
>> On 03-Feb-23 16:53, Tomi Valkeinen wrote:
>>> On 25/01/2023 13:35, Aradhya Bhatia wrote:
Make DSS Video Ports agnostic of output bus types.
DSS controllers have had a 1-to-1 coupling between its VPs and its
output ports. This no longer stands true for the new AM625 DSS. This
coupling, hence, has been removed by renaming the 'vp_bus_type' to
'output_port_bus_type' because the VPs are essentially agnostic of the
bus type and it is the output ports which have a bus type.
The AM625 DSS has 2 VPs but requires 3 output ports to support its
Dual-Link OLDI video output coming from a single VP.
>>>
>>> Not a biggie, but this sentence is a bit odd here at the end. Shouldn't
>>> it be after the "...stands true for the new AM625 DSS."?
>>
>> Yes! It should be. Will make the edit.
>>
>>>
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/tidss/tidss_dispc.c | 47 +
drivers/gpu/drm/tidss/tidss_dispc.h | 21 +++--
drivers/gpu/drm/tidss/tidss_drv.h | 5 +--
drivers/gpu/drm/tidss/tidss_irq.h | 2 +-
drivers/gpu/drm/tidss/tidss_kms.c | 12
5 files changed, 48 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 165365b515e1..c1c4faccbddc 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -61,7 +61,7 @@ const struct dispc_features dispc_k2g_feats = {
.min_pclk_khz = 4375,
.max_pclk_khz = {
- [DISPC_VP_DPI] = 15,
+ [DISPC_PORT_DPI] = 15,
},
/*
@@ -96,7 +96,6 @@ const struct dispc_features dispc_k2g_feats = {
.vp_name = { "vp1" },
.ovr_name = { "ovr1" },
.vpclk_name = { "vp1" },
- .vp_bus_type = { DISPC_VP_DPI },
.vp_feat = { .color = {
.has_ctm = true,
@@ -109,6 +108,9 @@ const struct dispc_features dispc_k2g_feats = {
.vid_name = { "vid1" },
.vid_lite = { false },
.vid_order = { 0 },
+
+ .num_output_ports = 1,
+ .output_port_bus_type = { DISPC_PORT_DPI },
};
>>>
>>> Just thinking out loud, as these will get more complex in the future,
>>> maybe we should finally group them with struct. E.g. we could define
>>> struct array for vps, like (just hacky example):
>>>
>>> struct {
>>> const char *name;
>>> const char *clkname;
>>> struct tidss_vp_feat feat;
>>> } vps[TIDSS_MAX_PORTS];
>>>
>>> and then use them as:
>>>
>>> .vps = {
>>> {
>>> .name = "kala",
>>> .clkname = "kissa",
>>> .feat.color.has_ctm = true,
>>> }, {
>>> .name = "kala2",
>>> .clkname = "kissa2",
>>> .feat.color.has_ctm = false,
>>> },
>>> },
>>>
>>> Perhaps something to try in the future.
>>>
>>
>> Yes, agreed! Having that structure will tidy this up.
>> I will keep this under future work.
>>
static const u16 tidss_am65x_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
@@ -140,8 +142,8 @@ static const u16
tidss_am65x_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
const struct dispc_features dispc_am65x_feats = {
.max_pclk_khz = {
- [DISPC_VP_DPI] = 165000,
- [DISPC_VP_OLDI] = 165000,
+ [DISPC_PORT_DPI] = 165000,
+ [DISPC_PORT_OLDI] = 165000,
},
.scaling = {
@@ -171,7 +173,6 @@ const struct dispc_features dispc_am65x_feats = {
.vp_name = { "vp1", "vp2" },
.ovr_name = { "ovr1", "ovr2" },
.vpclk_name = { "vp1", "vp2" },
- .vp_bus_type = { DISPC_VP_OLDI, DISPC_VP_DPI },
.vp_feat = { .color = {
.has_ctm = true,
@@ -185,6 +186,9 @@ const struct dispc_features dispc_am65x_feats = {
.vid_name = { "vid", "vidl1" },
.vid_lite = { false, true, },
.vid_order = { 1, 0 },
+
+ .num_output_ports = 2,
+ .output_port_bus_type = { DISPC_PORT_OLDI, DISPC_PORT_DPI },
};
static const u16 tidss_j721e_common_regs[DISPC_COMMON_REG_TABLE_LEN]
= {
@@ -229,8 +233,8 @@ static const u16
tidss_j721e_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
const struct dispc_features dispc_j721e_feats = {
.max_pclk_khz = {
- [DISPC_VP_DPI] = 17,
- [DISPC_VP_INTERNAL] = 60,
+ [DISPC_PORT_DPI] = 17,
+ [DISPC_PORT_INTERNAL] = 60,
},
.scaling = {
@@ -260,9 +264,7 @@ const struct dispc_features dis
Re: [PATCH v7 1/6] drm/tidss: Remove Video Port to Output Port coupling
On 05/02/2023 15:08, Aradhya Bhatia wrote:
Hi Tomi,
Thanks for the review!
On 03-Feb-23 16:53, Tomi Valkeinen wrote:
On 25/01/2023 13:35, Aradhya Bhatia wrote:
Make DSS Video Ports agnostic of output bus types.
DSS controllers have had a 1-to-1 coupling between its VPs and its
output ports. This no longer stands true for the new AM625 DSS. This
coupling, hence, has been removed by renaming the 'vp_bus_type' to
'output_port_bus_type' because the VPs are essentially agnostic of the
bus type and it is the output ports which have a bus type.
The AM625 DSS has 2 VPs but requires 3 output ports to support its
Dual-Link OLDI video output coming from a single VP.
Not a biggie, but this sentence is a bit odd here at the end. Shouldn't
it be after the "...stands true for the new AM625 DSS."?
Yes! It should be. Will make the edit.
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/tidss/tidss_dispc.c | 47 +
drivers/gpu/drm/tidss/tidss_dispc.h | 21 +++--
drivers/gpu/drm/tidss/tidss_drv.h | 5 +--
drivers/gpu/drm/tidss/tidss_irq.h | 2 +-
drivers/gpu/drm/tidss/tidss_kms.c | 12
5 files changed, 48 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 165365b515e1..c1c4faccbddc 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -61,7 +61,7 @@ const struct dispc_features dispc_k2g_feats = {
.min_pclk_khz = 4375,
.max_pclk_khz = {
- [DISPC_VP_DPI] = 15,
+ [DISPC_PORT_DPI] = 15,
},
/*
@@ -96,7 +96,6 @@ const struct dispc_features dispc_k2g_feats = {
.vp_name = { "vp1" },
.ovr_name = { "ovr1" },
.vpclk_name = { "vp1" },
- .vp_bus_type = { DISPC_VP_DPI },
.vp_feat = { .color = {
.has_ctm = true,
@@ -109,6 +108,9 @@ const struct dispc_features dispc_k2g_feats = {
.vid_name = { "vid1" },
.vid_lite = { false },
.vid_order = { 0 },
+
+ .num_output_ports = 1,
+ .output_port_bus_type = { DISPC_PORT_DPI },
};
Just thinking out loud, as these will get more complex in the future,
maybe we should finally group them with struct. E.g. we could define
struct array for vps, like (just hacky example):
struct {
const char *name;
const char *clkname;
struct tidss_vp_feat feat;
} vps[TIDSS_MAX_PORTS];
and then use them as:
.vps = {
{
.name = "kala",
.clkname = "kissa",
.feat.color.has_ctm = true,
}, {
.name = "kala2",
.clkname = "kissa2",
.feat.color.has_ctm = false,
},
},
Perhaps something to try in the future.
Yes, agreed! Having that structure will tidy this up.
I will keep this under future work.
static const u16 tidss_am65x_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
@@ -140,8 +142,8 @@ static const u16
tidss_am65x_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
const struct dispc_features dispc_am65x_feats = {
.max_pclk_khz = {
- [DISPC_VP_DPI] = 165000,
- [DISPC_VP_OLDI] = 165000,
+ [DISPC_PORT_DPI] = 165000,
+ [DISPC_PORT_OLDI] = 165000,
},
.scaling = {
@@ -171,7 +173,6 @@ const struct dispc_features dispc_am65x_feats = {
.vp_name = { "vp1", "vp2" },
.ovr_name = { "ovr1", "ovr2" },
.vpclk_name = { "vp1", "vp2" },
- .vp_bus_type = { DISPC_VP_OLDI, DISPC_VP_DPI },
.vp_feat = { .color = {
.has_ctm = true,
@@ -185,6 +186,9 @@ const struct dispc_features dispc_am65x_feats = {
.vid_name = { "vid", "vidl1" },
.vid_lite = { false, true, },
.vid_order = { 1, 0 },
+
+ .num_output_ports = 2,
+ .output_port_bus_type = { DISPC_PORT_OLDI, DISPC_PORT_DPI },
};
static const u16 tidss_j721e_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
@@ -229,8 +233,8 @@ static const u16
tidss_j721e_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
const struct dispc_features dispc_j721e_feats = {
.max_pclk_khz = {
- [DISPC_VP_DPI] = 17,
- [DISPC_VP_INTERNAL] = 60,
+ [DISPC_PORT_DPI] = 17,
+ [DISPC_PORT_INTERNAL] = 60,
},
.scaling = {
@@ -260,9 +264,7 @@ const struct dispc_features dispc_j721e_feats = {
.vp_name = { "vp1", "vp2", "vp3", "vp4" },
.ovr_name = { "ovr1", "ovr2", "ovr3", "ovr4" },
.vpclk_name = { "vp1", "vp2", "vp3", "vp4" },
- /* Currently hard coded VP routing (see dispc_initial_config()) */
- .vp_bus_type = { DISPC_VP_INTERNAL, DISPC_VP_DPI,
- DISPC_VP_INTERNAL, DISPC_VP_DPI, },
+
I think this line feed is extra.
Okay! Will remove that from all SoC feat structs.
.vp_feat = { .color = {
.has_ctm = true,
.gamma_size = 1024,
@@ -273,6 +275,11 @@ const struct dispc_features dispc_j721
Re: [PATCH v7 1/6] drm/tidss: Remove Video Port to Output Port coupling
Hi Tomi,
Thanks for the review!
On 03-Feb-23 16:53, Tomi Valkeinen wrote:
> On 25/01/2023 13:35, Aradhya Bhatia wrote:
>> Make DSS Video Ports agnostic of output bus types.
>>
>> DSS controllers have had a 1-to-1 coupling between its VPs and its
>> output ports. This no longer stands true for the new AM625 DSS. This
>> coupling, hence, has been removed by renaming the 'vp_bus_type' to
>> 'output_port_bus_type' because the VPs are essentially agnostic of the
>> bus type and it is the output ports which have a bus type.
>>
>> The AM625 DSS has 2 VPs but requires 3 output ports to support its
>> Dual-Link OLDI video output coming from a single VP.
>
> Not a biggie, but this sentence is a bit odd here at the end. Shouldn't
> it be after the "...stands true for the new AM625 DSS."?
Yes! It should be. Will make the edit.
>
>> Signed-off-by: Aradhya Bhatia
>> ---
>> drivers/gpu/drm/tidss/tidss_dispc.c | 47 +
>> drivers/gpu/drm/tidss/tidss_dispc.h | 21 +++--
>> drivers/gpu/drm/tidss/tidss_drv.h | 5 +--
>> drivers/gpu/drm/tidss/tidss_irq.h | 2 +-
>> drivers/gpu/drm/tidss/tidss_kms.c | 12
>> 5 files changed, 48 insertions(+), 39 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
>> b/drivers/gpu/drm/tidss/tidss_dispc.c
>> index 165365b515e1..c1c4faccbddc 100644
>> --- a/drivers/gpu/drm/tidss/tidss_dispc.c
>> +++ b/drivers/gpu/drm/tidss/tidss_dispc.c
>> @@ -61,7 +61,7 @@ const struct dispc_features dispc_k2g_feats = {
>> .min_pclk_khz = 4375,
>> .max_pclk_khz = {
>> - [DISPC_VP_DPI] = 15,
>> + [DISPC_PORT_DPI] = 15,
>> },
>> /*
>> @@ -96,7 +96,6 @@ const struct dispc_features dispc_k2g_feats = {
>> .vp_name = { "vp1" },
>> .ovr_name = { "ovr1" },
>> .vpclk_name = { "vp1" },
>> - .vp_bus_type = { DISPC_VP_DPI },
>> .vp_feat = { .color = {
>> .has_ctm = true,
>> @@ -109,6 +108,9 @@ const struct dispc_features dispc_k2g_feats = {
>> .vid_name = { "vid1" },
>> .vid_lite = { false },
>> .vid_order = { 0 },
>> +
>> + .num_output_ports = 1,
>> + .output_port_bus_type = { DISPC_PORT_DPI },
>> };
>
> Just thinking out loud, as these will get more complex in the future,
> maybe we should finally group them with struct. E.g. we could define
> struct array for vps, like (just hacky example):
>
> struct {
> const char *name;
> const char *clkname;
> struct tidss_vp_feat feat;
> } vps[TIDSS_MAX_PORTS];
>
> and then use them as:
>
> .vps = {
> {
> .name = "kala",
> .clkname = "kissa",
> .feat.color.has_ctm = true,
> }, {
> .name = "kala2",
> .clkname = "kissa2",
> .feat.color.has_ctm = false,
> },
> },
>
> Perhaps something to try in the future.
>
Yes, agreed! Having that structure will tidy this up.
I will keep this under future work.
>> static const u16 tidss_am65x_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
>> @@ -140,8 +142,8 @@ static const u16
>> tidss_am65x_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
>> const struct dispc_features dispc_am65x_feats = {
>> .max_pclk_khz = {
>> - [DISPC_VP_DPI] = 165000,
>> - [DISPC_VP_OLDI] = 165000,
>> + [DISPC_PORT_DPI] = 165000,
>> + [DISPC_PORT_OLDI] = 165000,
>> },
>> .scaling = {
>> @@ -171,7 +173,6 @@ const struct dispc_features dispc_am65x_feats = {
>> .vp_name = { "vp1", "vp2" },
>> .ovr_name = { "ovr1", "ovr2" },
>> .vpclk_name = { "vp1", "vp2" },
>> - .vp_bus_type = { DISPC_VP_OLDI, DISPC_VP_DPI },
>> .vp_feat = { .color = {
>> .has_ctm = true,
>> @@ -185,6 +186,9 @@ const struct dispc_features dispc_am65x_feats = {
>> .vid_name = { "vid", "vidl1" },
>> .vid_lite = { false, true, },
>> .vid_order = { 1, 0 },
>> +
>> + .num_output_ports = 2,
>> + .output_port_bus_type = { DISPC_PORT_OLDI, DISPC_PORT_DPI },
>> };
>> static const u16 tidss_j721e_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
>> @@ -229,8 +233,8 @@ static const u16
>> tidss_j721e_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
>> const struct dispc_features dispc_j721e_feats = {
>> .max_pclk_khz = {
>> - [DISPC_VP_DPI] = 17,
>> - [DISPC_VP_INTERNAL] = 60,
>> + [DISPC_PORT_DPI] = 17,
>> + [DISPC_PORT_INTERNAL] = 60,
>> },
>> .scaling = {
>> @@ -260,9 +264,7 @@ const struct dispc_features dispc_j721e_feats = {
>> .vp_name = { "vp1", "vp2", "vp3", "vp4" },
>> .ovr_name = { "ovr1", "ovr2", "ovr3", "ovr4" },
>> .vpclk_name = { "vp1", "vp2", "vp3", "vp4" },
>> - /* Currently hard coded VP routing (see dispc_initial_config()) */
>> - .vp_bus_type = { DISPC_VP_INTERNAL, DISPC_VP_DPI,
>> - DISPC_VP_INTERNAL, DISPC_VP_DPI, },
>> +
>
> I think this line fee
Re: [PATCH v7 1/6] drm/tidss: Remove Video Port to Output Port coupling
On 25/01/2023 13:35, Aradhya Bhatia wrote:
Make DSS Video Ports agnostic of output bus types.
DSS controllers have had a 1-to-1 coupling between its VPs and its
output ports. This no longer stands true for the new AM625 DSS. This
coupling, hence, has been removed by renaming the 'vp_bus_type' to
'output_port_bus_type' because the VPs are essentially agnostic of the
bus type and it is the output ports which have a bus type.
The AM625 DSS has 2 VPs but requires 3 output ports to support its
Dual-Link OLDI video output coming from a single VP.
Not a biggie, but this sentence is a bit odd here at the end. Shouldn't
it be after the "...stands true for the new AM625 DSS."?
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/tidss/tidss_dispc.c | 47 +
drivers/gpu/drm/tidss/tidss_dispc.h | 21 +++--
drivers/gpu/drm/tidss/tidss_drv.h | 5 +--
drivers/gpu/drm/tidss/tidss_irq.h | 2 +-
drivers/gpu/drm/tidss/tidss_kms.c | 12
5 files changed, 48 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 165365b515e1..c1c4faccbddc 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -61,7 +61,7 @@ const struct dispc_features dispc_k2g_feats = {
.min_pclk_khz = 4375,
.max_pclk_khz = {
- [DISPC_VP_DPI] = 15,
+ [DISPC_PORT_DPI] = 15,
},
/*
@@ -96,7 +96,6 @@ const struct dispc_features dispc_k2g_feats = {
.vp_name = { "vp1" },
.ovr_name = { "ovr1" },
.vpclk_name = { "vp1" },
- .vp_bus_type = { DISPC_VP_DPI },
.vp_feat = { .color = {
.has_ctm = true,
@@ -109,6 +108,9 @@ const struct dispc_features dispc_k2g_feats = {
.vid_name = { "vid1" },
.vid_lite = { false },
.vid_order = { 0 },
+
+ .num_output_ports = 1,
+ .output_port_bus_type = { DISPC_PORT_DPI },
};
Just thinking out loud, as these will get more complex in the future,
maybe we should finally group them with struct. E.g. we could define
struct array for vps, like (just hacky example):
struct {
const char *name;
const char *clkname;
struct tidss_vp_feat feat;
} vps[TIDSS_MAX_PORTS];
and then use them as:
.vps = {
{
.name = "kala",
.clkname = "kissa",
.feat.color.has_ctm = true,
}, {
.name = "kala2",
.clkname = "kissa2",
.feat.color.has_ctm = false,
},
},
Perhaps something to try in the future.
static const u16 tidss_am65x_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
@@ -140,8 +142,8 @@ static const u16
tidss_am65x_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
const struct dispc_features dispc_am65x_feats = {
.max_pclk_khz = {
- [DISPC_VP_DPI] = 165000,
- [DISPC_VP_OLDI] = 165000,
+ [DISPC_PORT_DPI] = 165000,
+ [DISPC_PORT_OLDI] = 165000,
},
.scaling = {
@@ -171,7 +173,6 @@ const struct dispc_features dispc_am65x_feats = {
.vp_name = { "vp1", "vp2" },
.ovr_name = { "ovr1", "ovr2" },
.vpclk_name = { "vp1", "vp2" },
- .vp_bus_type = { DISPC_VP_OLDI, DISPC_VP_DPI },
.vp_feat = { .color = {
.has_ctm = true,
@@ -185,6 +186,9 @@ const struct dispc_features dispc_am65x_feats = {
.vid_name = { "vid", "vidl1" },
.vid_lite = { false, true, },
.vid_order = { 1, 0 },
+
+ .num_output_ports = 2,
+ .output_port_bus_type = { DISPC_PORT_OLDI, DISPC_PORT_DPI },
};
static const u16 tidss_j721e_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
@@ -229,8 +233,8 @@ static const u16
tidss_j721e_common_regs[DISPC_COMMON_REG_TABLE_LEN] = {
const struct dispc_features dispc_j721e_feats = {
.max_pclk_khz = {
- [DISPC_VP_DPI] = 17,
- [DISPC_VP_INTERNAL] = 60,
+ [DISPC_PORT_DPI] = 17,
+ [DISPC_PORT_INTERNAL] = 60,
},
.scaling = {
@@ -260,9 +264,7 @@ const struct dispc_features dispc_j721e_feats = {
.vp_name = { "vp1", "vp2", "vp3", "vp4" },
.ovr_name = { "ovr1", "ovr2", "ovr3", "ovr4" },
.vpclk_name = { "vp1", "vp2", "vp3", "vp4" },
- /* Currently hard coded VP routing (see dispc_initial_config()) */
- .vp_bus_type = { DISPC_VP_INTERNAL, DISPC_VP_DPI,
- DISPC_VP_INTERNAL, DISPC_VP_DPI, },
+
I think this line feed is extra.
.vp_feat = { .color = {
.has_ctm = true,
.gamma_size = 1024,
@@ -273,6 +275,11 @@ const struct dispc_features dispc_j721e_feats = {
.vid_name = { "vid1",
