kmalloc_array()/kcalloc() should be used to avoid potential overflow when
a multiplication is needed to compute the size of the requested memory.
So turn a kzalloc()+explicit size computation into an equivalent kcalloc().
Signed-off-by: Christophe JAILLET
---
drivers/video/backlight/pwm_bl.c |
On 2/2/22 10:37 AM, Akeem G Abodunrin wrote:
iommu_dev_has_feature() api has been removed by the commit 262948f8ba573
("iommu: Delete iommu_dev_has_feature()") - So this patch removes comment
about the api to avoid any confusion.
Signed-off-by: Akeem G Abodunrin
Cc: Lu Baolu
It's not a
Hi Christian,
Thanks for the reply :)
On 2022/2/1 15:56, Christian König wrote:
Hi Jia-Ju,
interesting that you have found those issues with an automated tool.
And yes that is a well design flaw within the radeon driver which can
happen on hardware faults, e.g. when radeon_ring_backup()
Ping,
This is a OOB read fix. Can someone please pick this up?
-Kees
On Wed, Jan 05, 2022 at 09:35:07AM -0800, Kees Cook wrote:
> The link_status array was not large enough to read the Adjust Request
> Post Cursor2 register, so remove the common helper function to avoid
> an OOB read, found
Ping. This is a OOB read fix. Can something send this to Linus please?
-Kees
On Wed, Jan 05, 2022 at 09:33:10AM -0800, Kees Cook wrote:
> The pcon_dsc_dpcd array holds 13 registers (0x92 through 0x9E). Fix the
> math to calculate the max size. Found from a -Warray-bounds build:
>
>
Hi Hsin-Yi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[cannot apply to robh/for-next drm-intel/for-linux-next v5.17-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base'
On 1/31/2022 1:05 PM, Dmitry Baryshkov wrote:
In order to simplify DP code, drop hand-coded loops over clock arrays,
replacing them with clk_bulk_* functions.
Signed-off-by: Dmitry Baryshkov
Tested-by: Jessica Zhang # RB3 (sdm845) and
RB5 (qrb5165)
Reviewed-by: Jessica Zhang
---
On 1/31/2022 1:05 PM, Dmitry Baryshkov wrote:
DPU driver contains code to parse clock items from device tree into
special data struct and then enable/disable/set rate for the clocks
using that data struct. However the DPU driver itself uses only parsing
and enabling/disabling part (the rate
Recently we added generic "edp-panel"s probed by EDID. To support
panels in this way we look at the panel ID in the EDID and look up the
panel in a table that has power sequence timings. If we find a panel
that's not in the table we will still attempt to use it but we'll use
conservative timings.
We'd like panels to be able to add things to debugfs underneath the
connector's directory. Let's plumb it through. A panel will be able to
put things in a "panel" directory under the connector's
directory. Note that debugfs is not ABI and so it's always possible
that the location that the panel
The ti-sn65dsi86 driver shouldn't hand-roll its own bridge
connector. It should use the normal drm_bridge_connector. Let's switch
to do that, removing all of the custom code.
NOTE: this still _doesn't_ implement DRM_BRIDGE_ATTACH_NO_CONNECTOR
support for ti-sn65dsi86 and that would still be a
The main goal of this series is the final patch in the series: to
allow test code to reliably find out if we ended up hitting the
"fallback" case of the generic edp-panel driver where we don't
recognize a panel and choose to use super conservative timing.
Version 1 of the patch actually landed
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add an API to reset the encoder related hw blocks to ensure
a proper teardown of the pipeline. At the moment this is being
used only for the writeback encoder but eventually we can start
using this for all interfaces.
Signed-off-by: Abhinav Kumar
---
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add writeback blocks to DPU resource manager so that
writeback encoders can request for writeback hardware blocks
through RM and their usage can be tracked.
Signed-off-by: Abhinav Kumar
[please excuse me for the duplicate, I've sent the email without
On 05/02/2022 00:17, Abhinav Kumar wrote:
add dpu encoder APIs to prepare and cleanup writeback job
for the writeback encoder. These shall be invoked from the
prepare_wb_job/cleanup_wb_job hooks of the drm_writeback
framework.
Having dpu-encoder-wide API for the single case of WB looks like an
On 05/02/2022 02:26, Kuogee Hsieh wrote:
On 2/4/2022 2:05 PM, Dmitry Baryshkov wrote:
On 04/02/2022 21:36, Kuogee Hsieh wrote:
Widebus feature will transmit two pixel data per pixel clock to
interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware
On 05/02/2022 00:17, Abhinav Kumar wrote:
Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.
This patch will change significantly if
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 57 +
On 2/4/2022 2:05 PM, Dmitry Baryshkov wrote:
On 04/02/2022 21:36, Kuogee Hsieh wrote:
Widebus feature will transmit two pixel data per pixel clock to
interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing engine
On 05/02/2022 00:17, Abhinav Kumar wrote:
Introduce the dpu_writeback module which serves as the
interface between dpu operations and the drm_writeback.
This module manages the connector related operations for
dpu writeback.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile
On 05/02/2022 00:17, Abhinav Kumar wrote:
Introduce the dpu_encoder_phys_* for the writeback interface
to handle writeback specific hardware programming.
Signed-off-by: Abhinav Kumar
Mostly looks ok, see minor comments bellow.
---
drivers/gpu/drm/msm/Makefile | 1
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add the dpu_hw_wb abstraction to program registers related to the
writeback block. These will be invoked once all the configuration
is set and ready to be programmed to the registers.
Reviewed-by: Dmitry Baryshkov
Few minor comments bellow.
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add writeback blocks to the sm8250 DPU hardware catalog. Other
chipsets support writeback too but add it to sm8250 to prototype
the feature so that it can be easily extended to other chipsets.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry
On 05/02/2022 00:17, Abhinav Kumar wrote:
kms_writeback test cases also verify with a null fb for the
writeback connector job. In addition there are also other
commit paths which can result in kickoffs without a valid
framebuffer like while closing the fb which results in the
callback to
On Mon, 31 Jan 2022 01:45:17 +0530, Rajeev Nandan wrote:
> In most cases, the default values of DSI PHY tuning registers should be
> sufficient as they are fully optimized. However, in some cases where
> extreme board parasitics cause the eye shape to degrade, the override
> bits can be used to
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add writeback block information while capturing the display
snapshot.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git
On 05/02/2022 00:17, Abhinav Kumar wrote:
Initialize dpu encoder and connector for writeback if the
target supports it in the catalog.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 37 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 62
On Thu, 03 Feb 2022 22:10:23 +0800, Hsin-Yi Wang wrote:
> List panel under aux-bus node if it's connected to anx7625's aux bus.
>
> Signed-off-by: Hsin-Yi Wang
> ---
> .../display/bridge/analogix,anx7625.yaml| 17 +
> 1 file changed, 17 insertions(+)
>
Reviewed-by: Rob
On 05/02/2022 00:17, Abhinav Kumar wrote:
Add changes to support writeback module in the dpu_hw_ctl
interface. In addition inroduce a reset_intf_cfg op to reset
the interface bits for the currently active interfaces in
the ctl path.
Signed-off-by: Abhinav Kumar
---
On 04/02/2022 21:36, Kuogee Hsieh wrote:
Widebus feature will transmit two pixel data per pixel clock to interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing engine register
setting to accommodate both widebus and
On 04/02/2022 21:36, Kuogee Hsieh wrote:
Divides horizontal width by 3 at timing engine of interface. There are
major part of compression (DSC) programming have to be done at DSC
controller which is not covered by this patch.
Signed-off-by: Kuogee Hsieh
---
On 04/02/2022 21:36, Kuogee Hsieh wrote:
Widebus feature will transmit two pixel data per pixel clock to interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing engine register
setting to accommodate both widebus and
On 04/02/2022 21:36, Kuogee Hsieh wrote:
Widebus feature will transmit two pixel data per pixel clock to interface.
This feature now is required to be enabled to easy migrant to higher
resolution applications in future. However since some legacy chipsets
does not support this feature, this
On Tue, Feb 01, 2022 at 12:01:53PM +0100, Christoph Niedermaier wrote:
> In the function panel_simple_probe() the pointer panel->desc is
> assigned to the passed pointer desc. If function panel_dpi_probe()
> is called panel->desc will be updated, but further on only desc
> will be evaluated. So
Add writeback block information while capturing the display
snapshot.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index
Initialize dpu encoder and connector for writeback if the
target supports it in the catalog.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 37 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 62 +
2 files changed, 88
kms_writeback test cases also verify with a null fb for the
writeback connector job. In addition there are also other
commit paths which can result in kickoffs without a valid
framebuffer like while closing the fb which results in the
callback to drm_atomic_helper_dirtyfb() which internally
add dpu encoder APIs to prepare and cleanup writeback job
for the writeback encoder. These shall be invoked from the
prepare_wb_job/cleanup_wb_job hooks of the drm_writeback
framework.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 34
Introduce the dpu_writeback module which serves as the
interface between dpu operations and the drm_writeback.
This module manages the connector related operations for
dpu writeback.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile | 1 +
Introduce the dpu_encoder_phys_* for the writeback interface
to handle writeback specific hardware programming.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 36 +-
Add an API to reset the encoder related hw blocks to ensure
a proper teardown of the pipeline. At the moment this is being
used only for the writeback encoder but eventually we can start
using this for all interfaces.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
Add changes to support writeback module in the dpu_hw_ctl
interface. In addition inroduce a reset_intf_cfg op to reset
the interface bits for the currently active interfaces in
the ctl path.
Signed-off-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +-
Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 57 +
1 file changed, 42 insertions(+), 15 deletions(-)
diff --git
Add writeback blocks to DPU resource manager so that
writeback encoders can request for writeback hardware blocks
through RM and their usage can be tracked.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +
Add the dpu_hw_wb abstraction to program registers related to the
writeback block. These will be invoked once all the configuration
is set and ready to be programmed to the registers.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile | 1 +
Add writeback blocks to the sm8250 DPU hardware catalog. Other
chipsets support writeback too but add it to sm8250 to prototype
the feature so that it can be easily extended to other chipsets.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 73
This series adds support for writeback block on DPU. Writeback
block is extremely useful to validate boards having no physical displays
in addition to many other use-cases where we want to get the output
of the display pipeline to examine whether issue is with the display
pipeline or with the
On Fri, Feb 4, 2022 at 10:53 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.02.22 um 14:43 schrieb Javier Martinez Canillas:
> > Add support to convert XR24 and 8-bit grayscale to reversed monochrome for
> > drivers that control monochromatic panels, that only have 1 bit per pixel.
> >
> > The
Hi
Am 04.02.22 um 20:31 schrieb Javier Martinez Canillas:
Hello Thomas,
Thanks a lot for your feedback.
On 2/4/22 16:52, Thomas Zimmermann wrote:
[snip]
+static void drm_fb_gray8_to_mono_reversed_line(u8 *dst, const u8 *src, size_t
pixels)
+{
+ unsigned int xb, i;
+
+ for (xb
The pull request you sent on Fri, 4 Feb 2022 16:09:15 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-02-04
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/31462d9e47cf6e2cb10a69c833b5e081fff7086d
Thank you!
--
Deet-doot-dot, I am a bot.
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> Accessing the one in fbmem.c without taking the right locks is a bad
> idea. Instead maintain our own private copy, which is fully protected
> by console_lock() (like everything else in fbcon.c). That copy is
> serialized
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> There's a bunch of confusions going on here:
> - The deferred fbcon setup notifier should only be cleaned up from
> fb_console_exit(), to be symmetric with fb_console_init()
> - We also need to make sure we don't race
On Mon, Jan 31, 2022 at 10:05:48PM +0100, Daniel Vetter wrote:
> con2fb_release_oldinfo() has a bunch more kfree() calls than
> fbcon_exit(), but since kfree() on NULL is harmless doing that in both
> places should be ok. This is also a bit more symmetric now again with
> fbcon_open also
Hi Daniel.
On Mon, Jan 31, 2022 at 10:05:47PM +0100, Daniel Vetter wrote:
> Ideally console_lock becomes an implementation detail of fbcon.c and
> doesn't show up anywhere in fbmem.c. We're still pretty far from that,
> but at least the register/unregister code is there now.
>
> With this the
On Mon, Jan 31, 2022 at 10:05:46PM +0100, Daniel Vetter wrote:
> This shouldn't be a problem in practice since until we've actually
> taken over the console there's nothing we've registered with the
> console/vt subsystem, so the exit/unbind path that check this can't
> do the wrong thing. But
On Fri, Feb 04, 2022 at 08:05:56PM +0100, Thomas Zimmermann wrote:
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
First the simplest ones:
- iosys_map_memset(): when abstracting system and I/O memory,
just like the memcpy() use case, memset() also has dedicated
On Mon, Jan 31, 2022 at 10:05:45PM +0100, Daniel Vetter wrote:
> Now we get to the real motiviation, because fbmem.c insists that
> that's the right lock for these.
>
> Ofc fbcon.c has a lot more places where it probably should call
> lock_fb_info(). But looking at fbmem.c at least most of these
Hi
Am 04.02.22 um 19:29 schrieb Christian König:
Oh, that's on my TODO list for years!
Am 04.02.22 um 18:48 schrieb Maarten Lankhorst:
Suballocating a buffer object is something that is not driver
generic, and is useful for other drivers as well.
Signed-off-by: Maarten Lankhorst
---
On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> No idea why con2fb_acquire_newinfo() initializes much less than
> fbcon_startup(), but so be it. From a quick look most of the
> un-initialized stuff should be fairly harmless, but who knows.
>
> Signed-off-by: Daniel Vetter
> Cc:
Currently we can get a warning on systems with eDP backlights like so:
nv_backlight: invalid backlight type
WARNING: CPU: 4 PID: 454 at drivers/video/backlight/backlight.c:420
backlight_device_register+0x226/0x250
This happens as a result of us not filling out props.type for the eDP
Hello Thomas,
Thanks a lot for your feedback.
On 2/4/22 16:52, Thomas Zimmermann wrote:
[snip]
>> +static void drm_fb_gray8_to_mono_reversed_line(u8 *dst, const u8 *src,
>> size_t pixels)
>> +{
>> +unsigned int xb, i;
>> +
>> +for (xb = 0; xb < pixels / 8; xb++) {
>
> In practice,
On Fri, Feb 04, 2022 at 07:48:10PM +0100, Thomas Zimmermann wrote:
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
In certain situations it's useful to be able to write to an
offset of the mapping. Add a dst_offset to iosys_map_memcpy_to().
Cc: Sumit Semwal
Cc: Christian König
Cc: Thomas
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
Use iosys_map to read fields from the dma_blob so access to IO and
system memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
Now the map is saved during creation, so use it to initialize the
golden context, reading from shmem and writing to either system or IO
memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc:
Hello Andy,
Thanks for your feedback.
On 2/4/22 15:26, Andy Shevchenko wrote:
> On Fri, Feb 04, 2022 at 02:43:45PM +0100, Javier Martinez Canillas wrote:
>> Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED
>> controllers that can be programmed via an I2C interface. This is
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
Add a variant of shmem_read() that takes a iosys_map pointer rather
than a plain pointer as argument. It's mostly a copy __shmem_rw() but
adapting the api and removing the write support since there's currently
only need to use iosys_map as
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
First the simplest ones:
- iosys_map_memset(): when abstracting system and I/O memory,
just like the memcpy() use case, memset() also has dedicated
functions to be called for using IO memory.
-
On 2/4/2022 01:55, Daniel Vetter wrote:
On Wed, Jan 19, 2022 at 9:35 PM wrote:
From: Rodrigo Vivi
GuC contains a consolidated table with a bunch of information about the
current device.
Previously, this information was spread and hardcoded to all the components
including GuC, i915 and
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
In certain situations it's useful to be able to write to an
offset of the mapping. Add a dst_offset to iosys_map_memcpy_to().
Cc: Sumit Semwal
Cc: Christian König
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc:
Widebus feature will transmit two pixel data per pixel clock to interface.
This feature now is required to be enabled to easy migrant to higher
resolution applications in future. However since some legacy chipsets
does not support this feature, this feature is enabled base on chip's
hardware
Divides horizontal width by 3 at timing engine of interface. There are
major part of compression (DSC) programming have to be done at DSC
controller which is not covered by this patch.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 22 ++
Widebus feature will transmit two pixel data per pixel clock to interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing engine register
setting to accommodate both widebus and non widebus application. Also
horizontal
split into 3 patches
1) widebus timing engine programming
2) dsc timing engine
3) enable widebus feature base on chip hardware revision
Kuogee Hsieh (3):
drm/msm/dp: revise timing engine programming to support widebus
feature
drm/msm/dp: revise timing engine programming to support
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
In certain situations it's useful to be able to write to an
offset of the mapping. Add a dst_offset to iosys_map_memcpy_to().
Cc: Sumit Semwal
Cc: Christian König
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc:
Oh, that's on my TODO list for years!
Am 04.02.22 um 18:48 schrieb Maarten Lankhorst:
Suballocating a buffer object is something that is not driver
generic, and is useful for other drivers as well.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/Makefile | 4 +-
It seems that some laptops will report having both an eDP and LVDS
connector, even though only the LVDS connector is actually hooked up. This
can lead to issues with backlight registration if the eDP connector ends up
getting registered before the LVDS connector, as the backlight device will
then
Suballocating a buffer object is something that is not driver
generic, and is useful for other drivers as well.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/Makefile | 4 +-
drivers/gpu/drm/drm_suballoc.c | 424 +
include/drm/drm_suballoc.h |
Now that the suballocation helper is generic, we can use it in amdgpu.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 29 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 21 +-
Use the generic suballocation helper lifted from amdgpu.
Note that the generic suballocator only allows a single alignment,
so we may waste a few more bytes for radeon_semaphore, shouldn't
be a big deal, could be re-added if needed.
Signed-off-by: Maarten Lankhorst
---
The suballocation manager itself is not dependent on any implementation detail,
and can be made generic. I want to potentially use it inside i915, as it looks
like a clean implementation to do so. :)
Looking for feedback and some testing, as I don't have a amdgpu/radeon myself.
Only compile
Use the saved ads_map to prepare the golden context. One difference from
the init context is that this function can be called before there is a
gem object (and thus the guc->ads_map) to calculare the size of the
golden context that should be allocated for that object.
So in this case the function
Currently guc_mmio_reg_add() relies on having enough memory available in
the array to add a new slot. It uses
`GEM_BUG_ON(count >= regset->size);` to protect going above the
threshold.
In order to allow guc_mmio_reg_add() to handle the memory allocation by
itself, it must return an error in case
Now that all the called functions from __guc_ads_init() are converted to
use ads_map, stop using ads_blob in __guc_ads_init().
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
Use iosys_map to write the fields ads.capture_*.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 10 +-
1 file changed, 5
Now that the regset list is prepared, convert guc_mmio_reg_state_init()
to use iosys_map to copy the array to the final location and
initialize additional fields in ads.reg_state_list.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele
Use iosys_map_memset() to zero the private data as ADS may be either
on system or IO memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c |
Now we have the access to content of GuC ADS either using iosys_map
API or using a temporary buffer. Remove guc->ads_blob as there shouldn't
be updates using the bare pointer anymore.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele
In the other places in this function, guc->ads_map is being protected
from access when it's not yet set. However the last check is actually
about guc->ads_golden_ctxt_size been set before. These checks should
always match as the size is initialized on the first call to
guc_prep_golden_context(),
Use iosys_map to read fields from the dma_blob so access to IO and
system memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
The ADS initialitazion was using 2 passes to calculate the regset sent
to GuC to initialize each engine: the first pass to just have the final
object size and the second to set each register in place in the final
gem object.
However in order to maintain an ordered set of registers to pass to guc,
Use iosys_map to write the fields system_info.mapping_table[][].
Since we already have the info_map around where needed, just use it
instead of going through guc->ads_map.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Now the map is saved during creation, so use it to initialize the
golden context, reading from shmem and writing to either system or IO
memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
Use iosys_map to write the policies update so access to IO and system
memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
Add helpers on top of iosys_map_read_field() /
iosys_map_write_field() functions so they always use the right
arguments and make code easier to read.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De
Rename struct dma_buf_map to struct iosys_map and corresponding APIs.
Over time dma-buf-map grew up to more functionality than the one used by
dma-buf: in fact it's just a shim layer to abstract system memory, that
can be accessed via regular load and store, from IO memory that needs to
be acessed
Convert intel_guc_ads_create() and initialization to use iosys_map
rather than plain pointer and save it in the guc struct. This will help
with additional updates to the ads_blob after the
creation/initialization by abstracting the IO vs system memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc:
Add a variant of shmem_read() that takes a iosys_map pointer rather
than a plain pointer as argument. It's mostly a copy __shmem_rw() but
adapting the api and removing the write support since there's currently
only need to use iosys_map as destination.
Reworking __shmem_rw() to share the
In certain situations it's useful to be able to write to an
offset of the mapping. Add a dst_offset to iosys_map_memcpy_to().
Cc: Sumit Semwal
Cc: Christian König
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Lucas De Marchi
---
First the simplest ones:
- iosys_map_memset(): when abstracting system and I/O memory,
just like the memcpy() use case, memset() also has dedicated
functions to be called for using IO memory.
- iosys_map_memcpy_from(): we may need to copy data from I/O
2nd version of https://patchwork.freedesktop.org/series/99378/
As first patch I'm including the dma-buf-map rename to iosys-map for
completeness and to allow the other patches to be reviewed. However the
first patch was also sent by itself.
I think all the feedback from v1 was incorporated in
The 2022 X.Org Foundation elections are rapidly approaching. We will be
forwarding instructions on the nomination process to membership in the
near future.
Please note that only current members can vote in the upcoming election,
and that the deadline for new memberships or renewals to vote in the
1 - 100 of 155 matches
Mail list logo
