some minor dal cleanups and example of future patches
Subsystems (4)
So whenever I look at DAL I find myself trying to figure out what all of it does, and this leads me to deleting things, so I'm just sending out some stuff that I cleaned today.
One thing I noticed in passing is the displayport code seems possibly endian unsafe, it casts bytes read from hardware into bitfields, this is the best defined behaviour and is generally a pattern we try to steer away from.
The porting the displayport code to use drm defines is the sort of example of a cleanup patch that might cause problems for you in code sharing, but is the exact sort of patch that has been applied to other drivers in the past.
Dave.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 20161213064112.20004-1-airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
PATCH 1/8 dc: remove dc hub - this seems unused.
From: Dave Airlie <[email protected]>
--- drivers/gpu/drm/amd/display/dc/core/dc.c | 27 ---------------------- drivers/gpu/drm/amd/display/dc/dc.h | 17 -------------- .../drm/amd/display/dc/dce110/dce110_mem_input.c | 1 - .../gpu/drm/amd/display/dc/dce80/dce80_mem_input.c | 1 - drivers/gpu/drm/amd/display/dc/inc/hw/mem_input.h | 3 --- 5 files changed, 49 deletions(-)
drivers/gpu/drm/amd/display/dc/core/dc.c +0 -27
@@ -1828,30 +1828,3 @@ const struct dc_stream_status *dc_stream_get_status(return &stream->status; } -bool dc_init_dchub (struct dc *dc,struct dchub_init_data *dh_data) -{ -int i; -struct core_dc *core_dc =DC_TO_CORE (dc); -struct mem_input *mi =NULL ; - -for (i =0 ; i < core_dc->res_pool->pipe_count; i++) { -if (core_dc->res_pool->mis[i] !=NULL ) { - mi = core_dc->res_pool->mis[i]; -break ; - } - } -if (mi ==NULL ) { -dm_error ("no mem_input!\n" ); -return false; - } - -if (mi->funcs->mem_input_update_dchub) - mi->funcs->mem_input_update_dchub (mi, dh_data); -else -ASSERT (mi->funcs->mem_input_update_dchub); - - -return true; - -} -
drivers/gpu/drm/amd/display/dc/dc.h +0 -17
@@ -157,21 +157,6 @@ struct dc {struct dc_debug debug; }; -enum frame_buffer_mode { -FRAME_BUFFER_MODE_LOCAL_ONLY =0 , -FRAME_BUFFER_MODE_ZFB_ONLY , -FRAME_BUFFER_MODE_MIXED_ZFB_AND_LOCAL , -} ; - -struct dchub_init_data { -bool dchub_initialzied; -bool dchub_info_valid; -int64_t zfb_phys_addr_base; -int64_t zfb_mc_base_addr; -uint64_t zfb_size_in_byte; -enum frame_buffer_mode fb_mode; -}; -struct dc_init_data {struct hw_asic_id asic_id;void *driver;/* ctx */
@@ -192,8 +177,6 @@ struct dc *dc_create(const struct dc_init_data *init_params);void dc_destroy (struct dc **dc); -bool dc_init_dchub (struct dc *dc,struct dchub_init_data *dh_data); -/******************************************************************************* * Surface Interfaces ******************************************************************************/
drivers/gpu/drm/amd/display/dc/dce110/dce110_mem_input.c +0 -1
@@ -396,7 +396,6 @@ static struct mem_input_funcs dce110_mem_input_funcs = { dce_mem_input_program_surface_config, .mem_input_is_flip_pending = dce110_mem_input_is_flip_pending, - .mem_input_update_dchub = NULL };/*****************************************/ /* Constructor, Destructor */
drivers/gpu/drm/amd/display/dc/dce80/dce80_mem_input.c +0 -1
@@ -54,7 +54,6 @@ static struct mem_input_funcs dce80_mem_input_funcs = { dce_mem_input_program_surface_config, .mem_input_is_flip_pending = dce110_mem_input_is_flip_pending, - .mem_input_update_dchub = NULL };/*****************************************/
drivers/gpu/drm/amd/display/dc/inc/hw/mem_input.h +0 -3
@@ -98,9 +98,6 @@ struct mem_input_funcs { bool horizontal_mirror); bool (*mem_input_is_flip_pending)(struct mem_input *mem_input); - -void (*mem_input_update_dchub)(struct mem_input *mem_input, - struct dchub_init_data *dh_data); };#endif
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
PATCH 2/8 dal: remove some unused wrappers
In reply to a message not in the archiveFrom: Dave Airlie <[email protected]>
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 4 ---- 1 file changed, 4 deletions(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c +0 -4
@@ -36,10 +36,6 @@#include "amdgpu_dm_types.h" #include "amdgpu_pm.h" -#define dm_alloc (size) kzalloc(size, GFP_KERNEL) -#define dm_realloc (ptr, size) krealloc(ptr, size, GFP_KERNEL) -#define dm_free (ptr) kfree(ptr) -/****************************************************************************** * IRQ Interfaces. *****************************************************************************/
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 20161213064112.20004-3-airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Re: [PATCH 2/8] dal: remove some unused wrappers
They are still used all over the place (e.g. dc/dce110/dce110_resource.c:413).
We should at least do an spatch to use kzalloc/krealloc/kfree across the board if the wrappers are an issue.
NAKed
Harry
Quoted 13 lines · Dave Airlie
From: Dave Airlie <[email protected]>
Signed-off-by Dave Airlie <[email protected]>--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 4 ---- 1 file changed, 4 deletions(-)drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c +0
-0
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c line 41
Quoted 10 lines
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c +0
-4@@ -36,10 +36,6 @@#include "amdgpu_dm_types.h" #include "amdgpu_pm.h" -#define dm_alloc (size) kzalloc(size, GFP_KERNEL) -#define dm_realloc (ptr, size) krealloc(ptr, size, GFP_KERNEL) -#define dm_free (ptr) kfree(ptr) -/****************************************************************************** * IRQ Interfaces. *****************************************************************************/
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): f30d9730-8d3d-4b9d-ced2-4a1bb93138d2-5C7GfCeVMHo@public.gmane.org
Re: [PATCH 2/8] dal: remove some unused wrappers
Quoted 5 lines · Harry Wentland
They are still used all over the place (e.g.
dc/dce110/dce110_resource.c:413).We should at least do an spatch to use kzalloc/krealloc/kfree across the board if the wrappers are an issue.
Please do.
Alex
Quoted 31 lines
NAKed
Harry
Quoted 25 lines · Dave Airlie
From: Dave Airlie <[email protected]>
Signed-off-by Dave Airlie <[email protected]>--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 4 ---- 1 file changed, 4 deletions(-)drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c +0
-4@@ -36,10 +36,6 @@#include "amdgpu_dm_types.h" #include "amdgpu_pm.h" -#define dm_alloc (size) kzalloc(size, GFP_KERNEL) -#define dm_realloc (ptr, size) krealloc(ptr, size, GFP_KERNEL) -#define dm_free (ptr) kfree(ptr) -/****************************************************************************** * IRQ Interfaces.
Quoted 6 lines
Quoted 2 lines
*****************************************************************************/
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/8] dal: remove some unused wrappers
In reply to a message not in the archiveOn 15 Dec. 2016 02:27, "Harry Wentland" <[email protected]> wrote:
They are still used all over the place (e.g. dc/dce110/dce110_resource.c:41 3).
We should at least do an spatch to use kzalloc/krealloc/kfree across the board if the wrappers are an issue.
Some are used, these 3 defines are not, there is another header defining them,
But yes it would be good to drop all alloc wrappers
Dave.
NAKed
Harry
Quoted 26 lines · Dave Airlie
From: Dave Airlie <[email protected]>
Signed-off-by Dave Airlie <[email protected]>--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 4 ---- 1 file changed, 4 deletions(-)drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c +0
-4@@ -36,10 +36,6 @@#include "amdgpu_dm_types.h" #include "amdgpu_pm.h" -#define dm_alloc (size) kzalloc(size, GFP_KERNEL) -#define dm_realloc (ptr, size) krealloc(ptr, size, GFP_KERNEL) -#define dm_free (ptr) kfree(ptr) -/********************************************************** ******************** * IRQ Interfaces. ************************************************************
*****************/
Quoted 1 line
_______________________________________________
amd-gfx mailing list [email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/8] dal: remove some unused wrappers
In reply to a message not in the archiveHi Harry,
Quoted 8 lines · Harry Wentland
They are still used all over the place (e.g.
dc/dce110/dce110_resource.c:413).We should at least do an spatch to use kzalloc/krealloc/kfree across the board if the wrappers are an issue.
NAKed
[Ignoring all the heat around the DC/DAL topic for a moment]
Pardon for reviving this old thread, yet I believe it's beneficial, esp. for the less experienced open-source/kernel devs.
There is little-to-no merit of keeping dead code in upstream kernels. That is, unless there's a series in discussion which uses the code ;-)
NACKs like this one are not cool, furthermore the tend to alienate/push away people trying to help. With DC/DAL in mind, I think you/others want all the help people can offer ;-)
Regards,
Emil
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): CACvgo53HxQq4HhizR-+VY4W7cGb5O3XXmLUNhEGbipeo8ODjWA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: [PATCH 2/8] dal: remove some unused wrappers
Hi Emil,
Thing is, with all due respect, the vast majority of DC contributions are likely to come from AMD at the moment. The code is in high flux and requires knowledge about the hardware that the public does not possess.
That's not to say that submissions aren't welcomed. But on code that is in flux don't be shocked if you get a higher percentage of NAKs than in other parts of the driver which are relatively static.
It's a bit of a catch. The public (re: Linux) wants open, stable, efficient, and featureful drivers but then they want to dictate to the vendor exactly how that's going to be executed. That doesn't really work in practice or theory. The kernel team has standards that AMD has to meet but the process to get there won't always make everyone happy.
Once DC is actually cleaned up, validated, and merged into the kernel I suspect the RB/NAK ratio will clean up.
Cheers,
Tom
________________________________
From: amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of Emil Velikov <[email protected]>
Sent: Monday, December 19, 2016 07:46
To: Wentland, Harry
Cc: amd-gfx mailing list
Subject: Re: [PATCH 2/8] dal: remove some unused wrappers
Hi Harry,
Quoted 8 lines · Harry Wentland
They are still used all over the place (e.g.
dc/dce110/dce110_resource.c:413).We should at least do an spatch to use kzalloc/krealloc/kfree across the board if the wrappers are an issue.
NAKed
[Ignoring all the heat around the DC/DAL topic for a moment]
Pardon for reviving this old thread, yet I believe it's beneficial, esp. for the less experienced open-source/kernel devs.
There is little-to-no merit of keeping dead code in upstream kernels. That is, unless there's a series in discussion which uses the code ;-)
NACKs like this one are not cool, furthermore the tend to alienate/push away people trying to help. With DC/DAL in mind, I think you/others want all the help people can offer ;-)
Regards,
Emil
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - lists.freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx Archives. Using amd-gfx: To post a message to all the list members, send email ...
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): CY4PR12MB1768D6FCEC097FCDE97E314EF7910-rpdhrqHFk06yjjPBNVDk/[email protected]
Re: [PATCH 2/8] dal: remove some unused wrappers
Quoted 3 lines · Tom
Hi Emil,
Hey there, Tom.
Seems my "ignoring the heat around DC/DAL ..." wasn't enough and things have gone there :-(
Cutting down to the important piece...
Quoted 3 lines
It's a bit of a catch. The public (re: Linux) wants open, stable, efficient, and featureful drivers but then they want to dictate to the vendor exactly how that's going to be executed. That doesn't really work in practice or theory. The kernel team has standards that AMD has to meet but the process to get there won't always make everyone happy.
... here.
Intel has managed to get there and it would be amazing if the whole AMD team paves in that direction. It's not quick or easy route, yet you can use any of the materials (presentations, etc.) from Daniel Vetter's blog.
I'm stupid^Wnice enough to repeat one unwritten rule(?) in a hope that people who do not know it will take note.
And yes, rules are _not_ mean to be all fun all/most of the time :-\
To reiterate in a different light: upstream kernel should not (and does not most of the time) cater for non-upstream kernel code.
Thanks
EmilP.S. Please try to avoid html emails and/or top-posting.
_______________________________________________
amd-gfx mailing list [email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): CACvgo5220YNkWfW0xWr9Sn6a-tN8Ja02CZu65H2UWTQh+d_EZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: [PATCH 2/8] dal: remove some unused wrappers
Quoted 1 line
Intel has managed to get there
I am not 100% sure.
E.g. http://www.phoronix.com/scan.php?page=article&item=intel-win10-mesa121&num=1
In general Intel driver under Linux is still behind MS Windows version.
Regards,
Serguei Sagalovitch
From: amd-gfx <[email protected]> on behalf of Emil Velikov <[email protected]>
Sent: December 21, 2016 9:50 AM
To: StDenis, Tom
Cc: Wentland, Harry; amd-gfx mailing list
Subject: Re: [PATCH 2/8] dal: remove some unused wrappers
Quoted 3 lines · Tom
Hi Emil,
Hey there, Tom.
Seems my "ignoring the heat around DC/DAL ..." wasn't enough and things have gone there :-(
Cutting down to the important piece...
Quoted 3 lines
It's a bit of a catch. The public (re: Linux) wants open, stable, efficient, and featureful drivers but then they want to dictate to the vendor exactly how that's going to be executed. That doesn't really work in practice or theory. The kernel team has standards that AMD has to meet but the process to get there won't always make everyone happy.
... here.
Intel has managed to get there and it would be amazing if the whole AMD team paves in that direction. It's not quick or easy route, yet you can use any of the materials (presentations, etc.) from Daniel Vetter's blog.
I'm stupid^Wnice enough to repeat one unwritten rule(?) in a hope that people who do not know it will take note.
And yes, rules are _not_ mean to be all fun all/most of the time :-\
To reiterate in a different light: upstream kernel should not (and does not most of the time) cater for non-upstream kernel code.
Thanks
EmilP.S. Please try to avoid html emails and/or top-posting.
_______________________________________________
amd-gfx mailing list [email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - lists.freedesktop.org
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx Archives. Using amd-gfx: To post a message to all the list members, send email ...
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): SN1PR12MB07034F6B1DB5696FC2DA9729FE930-z7L1TMIYDg6P/[email protected]
Re: [PATCH 2/8] dal: remove some unused wrappers
Quoted 7 lines · Serguei
Quoted 1 line
Intel has managed to get there
I am not 100% sure.
E.g. http://www.phoronix.com/scan.php?page=article&item=intel-win10-mesa121&num=1In general Intel driver under Linux is still behind MS Windows version.
The article is pretty old (6 months as of today) and no longer applicable. AFAICT on virtually every chipset, but Gen7, the Linux driver reached and even has surpassed the respective Windows and/or Android ones. Check the Wikipedia page [1] for exact details ;-)
Side node:
Although amd-gfx is ok, other mailing lists will _explicitly_ discard HTML emails. If you/others are interested in participating in open-source communities, I'll repeat my suggestion - avoid html/top-posting.
Please ?
Thanks
Emil
[1] https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/8] dal: remove some unused wrappers
In reply to a message not in the archiveHi Emil,
Quoted 16 lines · Emil Velikov
Hi Harry,
Quoted 8 lines · Harry Wentland
They are still used all over the place (e.g.
dc/dce110/dce110_resource.c:413).We should at least do an spatch to use kzalloc/krealloc/kfree across the board if the wrappers are an issue.
NAKed
[Ignoring all the heat around the DC/DAL topic for a moment]
Pardon for reviving this old thread, yet I believe it's beneficial, esp. for the less experienced open-source/kernel devs.
Quoted 7 lines
There is little-to-no merit of keeping dead code in upstream kernels. That is, unless there's a series in discussion which uses the code ;-)
NACKs like this one are not cool, furthermore the tend to alienate/push away people trying to help. With DC/DAL in mind, I think you/others want all the help people can offer ;-)
Very good point. I think Dave set me straight pretty quickly there. :)
I'll make sure I'll take a much closer look at patches in the future before considering NAKs. My impression here was that this code was not dead, which was obviously a wrong one and a good indication that a lot of the DC codebase is still quite messy.
Thanks,
Harry
Quoted 3 lines
Regards,
Emil
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
PATCH 3/8 dal: drop register logger and pid/tgid getters
In reply to a message not in the archiveFrom: Dave Airlie <[email protected]>
While I'm sure this is useful I think we should bring it back later.
It's usage of pid/tgid is incorrect, you have to get/put pid/tgids not store them away.
--- .../drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 10 -- drivers/gpu/drm/amd/display/dc/basics/Makefile | 2 +- .../drm/amd/display/dc/basics/register_logger.c | 197 --------------------- drivers/gpu/drm/amd/display/dc/dm_services.h | 16 -- .../drm/amd/display/include/dal_register_logger.h | 42 ----- 5 files changed, 1 insertion(+), 266 deletions(-) delete mode 100644 drivers/gpu/drm/amd/display/dc/basics/register_logger.c delete mode 100644 drivers/gpu/drm/amd/display/include/dal_register_logger.h
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c +0 -10
@@ -447,13 +447,3 @@ void dal_notify_setmode_complete(struct dc_context *ctx,/*TODO*/ }/* End of calls to notification */ - -long dm_get_pid (void ) -{ -return current->pid; -} - -long dm_get_tgid (void ) -{ -return current->tgid; -}
drivers/gpu/drm/amd/display/dc/basics/Makefile +1 -1
@@ -4,7 +4,7 @@ # subcomponents. BASICS = conversion.o fixpt31_32.o fixpt32_32.o grph_object_id.o \ - logger.o log_helpers.o register_logger.o signal_types.o vector.o + logger.o log_helpers.o signal_types.o vector.o AMD_DAL_BASICS = $(addprefix $(AMDDALPATH)/dc/basics/,$(BASICS))
drivers/gpu/drm/amd/display/dc/basics/register_logger.c deleted +0 -197
197 lines not on this page · raw message
drivers/gpu/drm/amd/display/dc/dm_services.h +0 -16
@@ -109,12 +109,6 @@ static inline uint32_t dm_read_reg_func( value =cgs_read_register (ctx->cgs_device, address); -#if defined(__DAL_REGISTER_LOGGER__) -if (true ==dal_reg_logger_should_dump_register ()) { -dal_reg_logger_rw_count_increment (); -DRM_INFO ("%s DC_READ_REG: 0x%x 0x%x\n" , func_name, address, value); - } -#endif return value; }
@@ -127,13 +121,6 @@ static inline void dm_write_reg_func( uint32_t value, const char *func_name) { -#if defined(__DAL_REGISTER_LOGGER__) -if (true ==dal_reg_logger_should_dump_register ()) { -dal_reg_logger_rw_count_increment (); -DRM_INFO ("%s DC_WRITE_REG: 0x%x 0x%x\n" , func_name, address, value); - } -#endif -if (address ==0 ) {DC_ERR ("invalid register write. address = 0" );return ;
@@ -418,7 +405,4 @@ bool dm_dmcu_set_pipe(struct dc_context *ctx, unsigned int controller_id);#define dm_log_to_buffer (buffer, size, fmt, args)\ vsnprintf(buffer, size, fmt, args) -long dm_get_pid (void ); -long dm_get_tgid (void ); -#endif /* __DM_SERVICES_H__ */
drivers/gpu/drm/amd/display/include/dal_register_logger.h deleted +0 -42
42 lines not on this page · raw message
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 20161213064112.20004-4-airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Re: [PATCH 3/8] dal: drop register logger and pid/tgid getters
Am 13.12.2016 um 07:41 schrieb Dave Airlie:
Quoted 3 lines
From: Dave Airlie <[email protected]>
While I'm sure this is useful I think we should bring it back later.
Actually we have a trace point in the amdgpu module whenever we access a register.
If I'm not completely mistaken this allows us to have all the same functionality as this code.
Regards,
Christian.
Quoted 326 lines
It's usage of pid/tgid is incorrect, you have to get/put pid/tgids not store them away.
Signed-off-by Dave Airlie <[email protected]>--- .../drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 10 -- drivers/gpu/drm/amd/display/dc/basics/Makefile | 2 +- .../drm/amd/display/dc/basics/register_logger.c | 197 --------------------- drivers/gpu/drm/amd/display/dc/dm_services.h | 16 -- .../drm/amd/display/include/dal_register_logger.h | 42 ----- 5 files changed, 1 insertion(+), 266 deletions(-)delete mode 100644
drivers/gpu/drm/amd/display/dc/basics/register_logger.cdelete mode 100644drivers/gpu/drm/amd/display/include/dal_register_logger.hdrivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c +0
-10@@ -447,13 +447,3 @@ void dal_notify_setmode_complete(struct dc_context *ctx,/*TODO*/ }/* End of calls to notification */ - -long dm_get_pid (void ) -{ -return current->pid; -} - -long dm_get_tgid (void ) -{ -return current->tgid; -}drivers/gpu/drm/amd/display/dc/basics/Makefile +1
-1@@ -4,7 +4,7 @@ # subcomponents. BASICS = conversion.o fixpt31_32.o fixpt32_32.o grph_object_id.o \ - logger.o log_helpers.o register_logger.o signal_types.o vector.o + logger.o log_helpers.o signal_types.o vector.o AMD_DAL_BASICS = $(addprefix $(AMDDALPATH)/dc/basics/,$(BASICS))drivers/gpu/drm/amd/display/dc/basics/register_logger.c deleted +0
-197@@ -1,197 +0,0 @@ -/* -* Copyright 2012-15 Advanced Micro Devices, Inc. -* -* Permission is hereby granted, free of charge, to any person obtaining a -* copy of this software and associated documentation files (the "Software"), -* to deal in the Software without restriction, including without limitation -* the rights to use, copy, modify, merge, publish, distribute, sublicense, -* and/or sell copies of the Software, and to permit persons to whom the -* Software is furnished to do so, subject to the following conditions: -* -* The above copyright notice and this permission notice shall be included in -* all copies or substantial portions of the Software. -* -* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL -* THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR -* OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, -* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR -* OTHER DEALINGS IN THE SOFTWARE. -* -* Authors: AMD -* -*/ - -#include "dm_services.h" -#include "include/dal_types.h" -#include "include/logger_interface.h" -#include "logger.h" - -/****************************************************************************** -* Register Logger. -* A facility to create register R/W logs. -* Currently used for DAL Test. -*****************************************************************************/ - -/****************************************************************************** -* Private structures -*****************************************************************************/ -struct dal_reg_dump_stack_location { -const char *current_caller_func; -long current_pid; -long current_tgid; -uint32_t rw_count;/* register access counter for current function. */ -}; - -/* This the maximum number of nested calls to the 'reg_dump' facility. */ -#define DAL_REG_DUMP_STACK_MAX_SIZE 32 - -struct dal_reg_dump_stack { -int32_t stack_pointer; -struct dal_reg_dump_stack_location - stack_locations[DAL_REG_DUMP_STACK_MAX_SIZE ]; -uint32_t total_rw_count;/* Total count for *all* functions. */ -}; - -static struct dal_reg_dump_stack reg_dump_stack = {0 }; - -/****************************************************************************** -* Private functions -*****************************************************************************/ - -/* Check if current process is the one which requested register dump. -* The reason for the check: -* mmCRTC_STATUS_FRAME_COUNT is accessed by dal_controller_get_vblank_counter(). -* Which runs all the time when at least one display is connected. -* (Triggered by drm_mode_page_flip_ioctl()). */ -static bool is_reg_dump_process (void ) -{ -uint32_t i; - -/* walk the list of our processes */ -for (i =0 ; i < reg_dump_stack.stack_pointer; i++) { -struct dal_reg_dump_stack_location *stack_location - = ®_dump_stack.stack_locations[i]; - -if (stack_location->current_pid ==dm_get_pid () - && stack_location->current_tgid ==dm_get_tgid ()) -return true; - } - -return false; -} - -static bool dal_reg_dump_stack_is_empty (void ) -{ -if (reg_dump_stack.stack_pointer <=0 ) -return true; -else -return false; -} - -static struct dal_reg_dump_stack_location *dal_reg_dump_stack_push (void ) -{ -struct dal_reg_dump_stack_location *current_location =NULL ; - -if (reg_dump_stack.stack_pointer >=DAL_REG_DUMP_STACK_MAX_SIZE ) { -/* stack is full */ -dm_output_to_console ("[REG_DUMP]: %s: stack is full!\n" , - __func__); - }else { - current_location = - ®_dump_stack.stack_locations[reg_dump_stack.stack_pointer]; - ++reg_dump_stack.stack_pointer; - } - -return current_location; -} - -static struct dal_reg_dump_stack_location *dal_reg_dump_stack_pop (void ) -{ -struct dal_reg_dump_stack_location *current_location =NULL ; - -if (dal_reg_dump_stack_is_empty ()) { -/* stack is empty */ -dm_output_to_console ("[REG_DUMP]: %s: stack is empty!\n" , - __func__); - }else { - --reg_dump_stack.stack_pointer; - current_location = - ®_dump_stack.stack_locations[reg_dump_stack.stack_pointer]; - } - -return current_location; -} - -/****************************************************************************** -* Public functions -*****************************************************************************/ - -void dal_reg_logger_push (const char *caller_func) -{ -struct dal_reg_dump_stack_location *free_stack_location; - - free_stack_location =dal_reg_dump_stack_push (); - -if (NULL == free_stack_location) -return ; - -memset (free_stack_location,0 ,sizeof (*free_stack_location)); - - free_stack_location->current_caller_func = caller_func; - free_stack_location->current_pid =dm_get_pid (); - free_stack_location->current_tgid =dm_get_tgid (); - -dm_output_to_console ("[REG_DUMP]:%s - start (pid:%ld, tgid:%ld)\n" , - caller_func, - free_stack_location->current_pid, - free_stack_location->current_tgid); -} - -void dal_reg_logger_pop (void ) -{ -struct dal_reg_dump_stack_location *top_stack_location; - - top_stack_location =dal_reg_dump_stack_pop (); - -if (NULL == top_stack_location) { -dm_output_to_console ("[REG_DUMP]:%s - Stack is Empty!\n" , - __func__); -return ; - } - -dm_output_to_console ( -"[REG_DUMP]:%s - end." \ -" Reg R/W Count: Total=%d Function=%d. (pid:%ld, tgid:%ld)\n" , - top_stack_location->current_caller_func, - reg_dump_stack.total_rw_count, - top_stack_location->rw_count, -dm_get_pid (), -dm_get_tgid ()); - -memset (top_stack_location,0 ,sizeof (*top_stack_location)); -} - -void dal_reg_logger_rw_count_increment (void ) -{ - ++reg_dump_stack.total_rw_count; - - ++reg_dump_stack.stack_locations - [reg_dump_stack.stack_pointer -1 ].rw_count; -} - -bool dal_reg_logger_should_dump_register (void ) -{ -if (true ==dal_reg_dump_stack_is_empty ()) -return false; - -if (false ==is_reg_dump_process ()) -return false; - -return true; -} - -/****************************************************************************** -* End of File. -*****************************************************************************/ drivers/gpu/drm/amd/display/dc/dm_services.h +0
-16@@ -109,12 +109,6 @@ static inline uint32_t dm_read_reg_func( value =cgs_read_register (ctx->cgs_device, address); -#if defined(__DAL_REGISTER_LOGGER__) -if (true ==dal_reg_logger_should_dump_register ()) { -dal_reg_logger_rw_count_increment (); -DRM_INFO ("%s DC_READ_REG: 0x%x 0x%x\n" , func_name, address, value); - } -#endif return value; }@@ -127,13 +121,6 @@ static inline void dm_write_reg_func( uint32_t value, const char *func_name) { -#if defined(__DAL_REGISTER_LOGGER__) -if (true ==dal_reg_logger_should_dump_register ()) { -dal_reg_logger_rw_count_increment (); -DRM_INFO ("%s DC_WRITE_REG: 0x%x 0x%x\n" , func_name, address, value); - } -#endif -if (address ==0 ) {DC_ERR ("invalid register write. address = 0" );return ;@@ -418,7 +405,4 @@ bool dm_dmcu_set_pipe(struct dc_context *ctx, unsigned int controller_id);#define dm_log_to_buffer (buffer, size, fmt, args)\ vsnprintf(buffer, size, fmt, args) -long dm_get_pid (void ); -long dm_get_tgid (void ); -#endif /* __DM_SERVICES_H__ */ drivers/gpu/drm/amd/display/include/dal_register_logger.h deleted +0
-32@@ -1,42 +0,0 @@ -/* -* Copyright 2012-15 Advanced Micro Devices, Inc. -* -* Permission is hereby granted, free of charge, to any person obtaining a -* copy of this software and associated documentation files (the "Software"), -* to deal in the Software without restriction, including without limitation -* the rights to use, copy, modify, merge, publish, distribute, sublicense, -* and/or sell copies of the Software, and to permit persons to whom the -* Software is furnished to do so, subject to the following conditions: -* -* The above copyright notice and this permission notice shall be included in -* all copies or substantial portions of the Software. -* -* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL -* THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR -* OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, -* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR -* OTHER DEALINGS IN THE SOFTWARE. -* -* Authors: AMD -* -*/ - -#ifndef __DAL_REGISTER_LOGGER__ -#define __DAL_REGISTER_LOGGER__ - -/**************** -* API functions -***************/ -
drivers/gpu/drm/amd/display/include/dal_register_logger.h line 42
Quoted 10 lines
drivers/gpu/drm/amd/display/include/dal_register_logger.h deleted +0
-10-/* dal_reg_logger_push - begin Register Logging */ -void dal_reg_logger_push (const char *caller_func); -/* dal_reg_logger_pop - stop Register Logging */ -void dal_reg_logger_pop (void ); - -/* for internal use of the Logger only */ -void dal_reg_logger_rw_count_increment (void ); -bool dal_reg_logger_should_dump_register (void ); - -#endif /* __DAL_REGISTER_LOGGER__ */
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
PATCH 4/8 dal: drop get platform info
In reply to a message not in the archiveFrom: Dave Airlie <[email protected]>
--- .../drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 7 ----- drivers/gpu/drm/amd/display/dc/dm_services.h | 32 ---------------------- 2 files changed, 39 deletions(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c +0 -7
@@ -77,13 +77,6 @@ void dal_isr_release_lock(struct dc_context *ctx)* End-of-IRQ Interfaces. *****************************************************************************/ -bool dm_get_platform_info (struct dc_context *ctx, -struct platform_info_params *params) -{ -/*TODO*/ -return false; -} - bool dm_write_persistent_data(struct dc_context *ctx, const struct dc_sink *sink, const char *module_name,
drivers/gpu/drm/amd/display/dc/dm_services.h +0 -32
@@ -282,38 +282,6 @@ bool dm_pp_get_static_clocks(/****** end of PP interfaces ******/ -enum platform_method { -PM_GET_AVAILABLE_METHODS =1 <<0 , -PM_GET_LID_STATE =1 <<1 , -PM_GET_EXTENDED_BRIGHNESS_CAPS =1 <<2 -}; - -struct platform_info_params { -enum platform_method method; -void *data; -}; - -struct platform_info_brightness_caps { -uint8_t ac_level_percentage; -uint8_t dc_level_percentage; -}; - -struct platform_info_ext_brightness_caps { -struct platform_info_brightness_caps basic_caps; -struct data_point { -uint8_t luminance; -uint8_t signal_level; - } data_points[99 ]; - -uint8_t data_points_num; -uint8_t min_input_signal; -uint8_t max_input_signal; -}; - -bool dm_get_platform_info ( -struct dc_context *ctx, -struct platform_info_params *params); -struct persistent_data_flag {bool save_per_link;bool save_per_edid;
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
PATCH 5/8 dal: drop setmode complete notifier
In reply to a message not in the archiveFrom: Dave Airlie <[email protected]>
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 13 ------------- 1 file changed, 13 deletions(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c +0 -13
@@ -427,16 +427,3 @@ bool dm_pp_get_static_clocks( }/**** end of power component interfaces ****/ - -/* Calls to notification */ - -void dal_notify_setmode_complete (struct dc_context *ctx, -uint32_t h_total, -uint32_t v_total, -uint32_t h_active, -uint32_t v_active, -uint32_t pix_clk_in_khz) -{ -/*TODO*/ -} -/* End of calls to notification */
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
PATCH 6/8 drm/dp-helper: add missing defines needed by AMD display core.
In reply to a message not in the archiveFrom: Dave Airlie <[email protected]>
These are all the ones required by the AMD display core.
--- include/drm/drm_dp_helper.h | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
include/drm/drm_dp_helper.h +20 -0
@@ -400,6 +400,8 @@# define DP_ADJUST_PRE_EMPHASIS_LANE1_MASK 0xc0# define DP_ADJUST_PRE_EMPHASIS_LANE1_SHIFT 6 +#define DP_ADJUST_REQUEST_POST_CURSOR2 0x20c +#define DP_TEST_REQUEST 0x218# define DP_TEST_LINK_TRAINING (1 << 0)# define DP_TEST_LINK_VIDEO_PATTERN (1 << 1)
@@ -415,6 +417,8 @@#define DP_TEST_PATTERN 0x221 +#define DP_TEST_MISC1 0x232 +#define DP_TEST_CRC_R_CR 0x240#define DP_TEST_CRC_G_Y 0x242#define DP_TEST_CRC_B_CB 0x244
@@ -423,6 +427,18 @@# define DP_TEST_CRC_SUPPORTED (1 << 5)# define DP_TEST_COUNT_MASK 0xf +#define DP_TEST_PHY_PATTERN 0x248 +#define DP_TEST_80BIT_CUSTOM_PATTERN_7_0 0x250 +#define DP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251 +#define DP_TEST_80BIT_CUSTOM_PATTERN_23_16 0x252 +#define DP_TEST_80BIT_CUSTOM_PATTERN_31_24 0x253 +#define DP_TEST_80BIT_CUSTOM_PATTERN_39_32 0x254 +#define DP_TEST_80BIT_CUSTOM_PATTERN_47_40 0x255 +#define DP_TEST_80BIT_CUSTOM_PATTERN_55_48 0x256 +#define DP_TEST_80BIT_CUSTOM_PATTERN_63_56 0x257 +#define DP_TEST_80BIT_CUSTOM_PATTERN_71_64 0x258 +#define DP_TEST_80BIT_CUSTOM_PATTERN_79_72 0x259 +#define DP_TEST_RESPONSE 0x260# define DP_TEST_ACK (1 << 0)# define DP_TEST_NAK (1 << 1)
@@ -443,6 +459,7 @@#define DP_SOURCE_OUI 0x300#define DP_SINK_OUI 0x400#define DP_BRANCH_OUI 0x500 +#define DP_BRANCH_REVISION_START 0x509#define DP_SET_POWER 0x600# define DP_SET_POWER_D0 0x1
@@ -563,6 +580,9 @@#define DP_RECEIVER_ALPM_STATUS 0x200b/* eDP 1.4 */ # define DP_ALPM_LOCK_TIMEOUT_ERROR (1 << 0) +#define DP_DP13_DPCD_REV 0x2200 +#define DP_DP13_MAX_LINK_RATE 0x2201 +/* DP 1.2 Sideband message defines */ /* peer device type - DP 1.2a Table 2-92 */ #define DP_PEER_DEVICE_NONE 0x0
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
PATCH 7/8 dal: port to using drm dpcd defines
In reply to a message not in the archiveFrom: Dave Airlie <[email protected]>
We only keep one list of these defines in the kernel, so we should use it.
--- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 8 +- drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 2 +- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 144 ++++++------- drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c | 2 +- drivers/gpu/drm/amd/display/include/dpcd_defs.h | 223 +-------------------- 5 files changed, 79 insertions(+), 300 deletions(-)
drivers/gpu/drm/amd/display/dc/core/dc_link.c +4 -4
@@ -1157,7 +1157,7 @@ static void dpcd_configure_panel_mode(/*set edp panel mode in receiver*/ core_link_read_dpcd ( link, -DPCD_ADDRESS_EDP_CONFIG_SET , +DP_EDP_CONFIGURATION_SET , &edp_config_set.raw,sizeof (edp_config_set.raw));
@@ -1169,7 +1169,7 @@ static void dpcd_configure_panel_mode( panel_mode_edp; result =core_link_write_dpcd ( link, -DPCD_ADDRESS_EDP_CONFIG_SET , +DP_EDP_CONFIGURATION_SET , &edp_config_set.raw,sizeof (edp_config_set.raw));
@@ -1190,13 +1190,13 @@ static void enable_stream_features(struct pipe_ctx *pipe_ctx)struct core_link *link = stream->sink->link;union down_spread_ctrl downspread; -core_link_read_dpcd (link,DPCD_ADDRESS_DOWNSPREAD_CNTL , +core_link_read_dpcd (link,DP_DOWNSPREAD_CTRL , &downspread.raw,sizeof (downspread)); downspread.bits.IGNORE_MSA_TIMING_PARAM = (stream->public.ignore_msa_timing_param) ?1 :0 ; -core_link_write_dpcd (link,DPCD_ADDRESS_DOWNSPREAD_CNTL , +core_link_write_dpcd (link,DP_DOWNSPREAD_CTRL , &downspread.raw,sizeof (downspread)); }
drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c +1 -1
@@ -872,7 +872,7 @@ void dal_ddc_service_i2c_query_dp_dual_mode_adaptor(enum {DP_SINK_CAP_SIZE = -DPCD_ADDRESS_EDP_CONFIG_CAP -DPCD_ADDRESS_DPCD_REV +1 +DP_EDP_CONFIGURATION_CAP -DP_DPCD_REV +1 }; bool dal_ddc_service_query_ddc_data(
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +72 -72
482 lines not on this page · raw message
drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c +1 -1
@@ -48,7 +48,7 @@ void dp_receiver_power_ctrl(struct core_link *link, bool on) state = on ?DP_POWER_STATE_D0 :DP_POWER_STATE_D3 ; -core_link_write_dpcd (link,DPCD_ADDRESS_POWER_STATE , &state, +core_link_write_dpcd (link,DP_SET_POWER , &state,sizeof (state)); }
drivers/gpu/drm/amd/display/include/dpcd_defs.h +1 -222
235 lines not on this page · raw message
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
PATCH 8/8 dal: assign correct enum for edp revision
In reply to a message not in the archiveFrom: Dave Airlie <[email protected]>
There are 2 edp enum revisions, no idea why, drop one, and just assign 1.1 to the default value.
--- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- drivers/gpu/drm/amd/display/include/dpcd_defs.h | 16 ---------------- 2 files changed, 1 insertion(+), 17 deletions(-)
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +1 -1
@@ -2129,7 +2129,7 @@ static void retrieve_link_cap(struct core_link *link) link->dpcd_caps.panel_mode_edp = edp_config_cap.bits.ALT_SCRAMBLER_RESET; - link->edp_revision =DPCD_EDP_REVISION_EDP_UNKNOWN ; + link->edp_revision =EDP_REVISION_11 ; link->public.test_pattern_enabled = false; link->public.compliance_test_state.raw =0 ;
drivers/gpu/drm/amd/display/include/dpcd_defs.h +0 -16
@@ -144,22 +144,6 @@ enum dpcd_psr_sink_states { PSR_SINK_STATE_SINK_INTERNAL_ERROR = 7, }; -/* This enum defines the Panel's eDP revision at DPCD 700h -* 00h = eDP v1.1 or lower -* 01h = eDP v1.2 -* 02h = eDP v1.3 (PSR support starts here) -* 03h = eDP v1.4 -* If unknown revision, treat as eDP v1.1, meaning least functionality set. -* This enum has values matched to eDP spec, thus values should not change. -*/ -enum dpcd_edp_revision { -DPCD_EDP_REVISION_EDP_V1_1 =0 , -DPCD_EDP_REVISION_EDP_V1_2 =1 , -DPCD_EDP_REVISION_EDP_V1_3 =2 , -DPCD_EDP_REVISION_EDP_V1_4 =3 , -DPCD_EDP_REVISION_EDP_UNKNOWN =DPCD_EDP_REVISION_EDP_V1_1 , -}; - union dpcd_rev { struct { uint8_t MINOR:4;
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Quoted 9 lines · Dave Airlie
So whenever I look at DAL I find myself trying to figure out what all of it does, and this leads me to deleting things, so I'm just sending out some stuff that I cleaned today.
One thing I noticed in passing is the displayport code seems possibly endian unsafe, it casts bytes read from hardware into bitfields, this is the best defined behaviour and is generally a pattern we try to steer away from.
Quoted 4 lines
The porting the displayport code to use drm defines is the sort of example of a cleanup patch that might cause problems for you in code sharing, but is the exact sort of patch that has been applied to other drivers in the past.
I've also just noticed every dpcd access (read/write) causes a traversal of the connector list.
Dave.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Edward O'Callaghan
Acked-byThis series is,
Quoted 14 lines · Dave Airlie
So whenever I look at DAL I find myself trying to figure out what all of it does, and this leads me to deleting things, so I'm just sending out some stuff that I cleaned today.
One thing I noticed in passing is the displayport code seems possibly endian unsafe, it casts bytes read from hardware into bitfields, this is the best defined behaviour and is generally a pattern we try to steer away from.
The porting the displayport code to use drm defines is the sort of example of a cleanup patch that might cause problems for you in code sharing, but is the exact sort of patch that has been applied to other drivers in the past.
Quoted 7 lines
Dave.
_______________________________________________
amd-gfx mailing list [email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
The series is Reviewed-by: Harry Wentland <[email protected]>
Quoted 4 lines · Dave Airlie
So whenever I look at DAL I find myself trying to figure out what all of it does, and this leads me to deleting things, so I'm just sending out some stuff that I cleaned today.
We really appreciate the cleanup working while looking at our code. There's still lots to clean up.
Quoted 5 lines
One thing I noticed in passing is the displayport code seems possibly endian unsafe, it casts bytes read from hardware into bitfields, this is the best defined behaviour and is generally a pattern we try to steer away from.
Yeah, we generally assume we run on x86. I haven't looked at all the bitfields lately but I do know that we generally use two definitions, one for little, one for big endian, for every bitfield.
Quoted 5 lines
The porting the displayport code to use drm defines is the sort of example of a cleanup patch that might cause problems for you in code sharing, but is the exact sort of patch that has been applied to other drivers in the past.
Thanks for the concrete example. I'm still discussing with some guys how exactly we want to deal with this in shared code but am confident this can be done, hence the r-b above.
Harry
Quoted 7 lines
Dave.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): b3875cd1-74e2-1902-abe7-e674a352855d-5C7GfCeVMHo@public.gmane.org
Quoted 10 lines · Harry Wentland
Quoted 4 lines · Dave Airlie
One thing I noticed in passing is the displayport code seems possibly endian unsafe, it casts bytes read from hardware into bitfields, this is the best defined behaviour and is generally a pattern we try to steer away from.
Yeah, we generally assume we run on x86. I haven't looked at all the bitfields lately but I do know that we generally use two definitions, one for little, one for big endian, for every bitfield.
The memory layout of C bit-fields doesn't only vary due to endianness, it's completely up to each architecture's ABI. This is just one reason why we generally avoid bit-fields for modelling fixed memory layouts.
Signature · 6 lines
Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx