On Tue, Sep 27, 2022 at 03:12:00PM -0400, Hamza Mahfooz wrote:
> Address the following error:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c: In function
> ‘dc_stream_remove_writeback’:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:527:55: error:
> array subscript [0, 0
NO_IRQ is used to check the return of irq_of_parse_and_map().
On some architecture NO_IRQ is 0, on other architectures it is -1.
irq_of_parse_and_map() returns 0 on error, independent of NO_IRQ.
So use 0 instead of using NO_IRQ.
Signed-off-by: Christophe Leroy
---
drivers/video/fbdev/mb862xx/
On Wed, Oct 05, 2022 at 11:48:41PM +0200, Jason A. Donenfeld wrote:
> Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
> simply use the get_random_{u8,u16}() functions, which are faster than
> wasting the additional bytes from a 32-bit value.
>
> Signed-off-by: Jason A. Don
On Wed, Oct 05, 2022 at 11:48:44PM +0200, Jason A. Donenfeld wrote:
> With no callers left of prandom_u32() and prandom_bytes(), remove these
> deprecated wrappers.
>
> Signed-off-by: Jason A. Donenfeld
Reviewed-by: Kees Cook
--
Kees Cook
With no callers left of prandom_u32() and prandom_bytes(), remove these
deprecated wrappers.
Signed-off-by: Jason A. Donenfeld
---
include/linux/prandom.h | 12
1 file changed, 12 deletions(-)
diff --git a/include/linux/prandom.h b/include/linux/prandom.h
index 78db003bc290..e0a075
On Wed, Oct 05, 2022 at 11:48:43PM +0200, Jason A. Donenfeld wrote:
> The prandom_bytes() function has been a deprecated inline wrapper around
> get_random_bytes() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real f
On Wed, Oct 05, 2022 at 11:48:43PM +0200, Jason A. Donenfeld wrote:
> The prandom_bytes() function has been a deprecated inline wrapper around
> get_random_bytes() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real f
The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function.
Signed-off-by: Jason A. Donenfeld
---
arch/powerpc/crypto/crc-vp
The prandom_u32() function has been a deprecated inline wrapper around
get_random_u32() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function.
Signed-off-by: Jason A. Donenfeld
---
Documentation/networking/filte
On Wed, Oct 05, 2022 at 11:48:40PM +0200, Jason A. Donenfeld wrote:
> Rather than incurring a division or requesting too many random bytes for
> the given range, use the prandom_u32_max() function, which only takes
> the minimum required bytes from the RNG and avoids divisions.
Yes please!
Since
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value.
Signed-off-by: Jason A. Donenfeld
---
crypto/testmgr.c | 8 +++
On Wed, Oct 05, 2022 at 11:48:39PM +0200, Jason A. Donenfeld wrote:
> Hi folks,
>
> This is a five part treewide cleanup of random integer handling. The
> rules for random integers are:
>
> - If you want a secure or an insecure random u64, use get_random_u64().
> - If you want a secure or an inse
On Wed, Oct 5, 2022 at 9:16 PM Kees Cook wrote:
>
> On Wed, Oct 05, 2022 at 11:48:40PM +0200, Jason A. Donenfeld wrote:
> > Rather than incurring a division or requesting too many random bytes for
> > the given range, use the prandom_u32_max() function, which only takes
> > the minimum required by
Rather than incurring a division or requesting too many random bytes for
the given range, use the prandom_u32_max() function, which only takes
the minimum required bytes from the RNG and avoids divisions.
Signed-off-by: Jason A. Donenfeld
---
arch/x86/mm/pat/cpa-test.c| 4 +-
From: allen chen
Add driver to read data-lanes and max-pixel-clock-mhz from dt property to
restrict output bandwidth.
Signed-off-by: Allen chen
Signed-off-by: Pin-yen Lin
---
drivers/gpu/drm/bridge/ite-it6505.c | 36 ++---
1 file changed, 33 insertions(+), 3 deletions(
From: allen chen
Add properties to restrict dp output data-lanes and clock.
Signed-off-by: Pin-Yen Lin
Signed-off-by: Allen Chen
---
.../bindings/display/bridge/ite,it6505.yaml | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/display
From: allen chen
This series let driver can read properties from dt to restrict dp output
bandwidth.
Changes in v3:
-Rename property name.
allen chen (2):
dt-bindings: it6505: add properties to restrict output bandwidth
drm/bridge: add it6505 driver to read data-lanes and
max-pixel-cloc
On 10/5/22 19:18, Thomas Zimmermann wrote:
>
>
> Am 30.09.22 um 17:29 schrieb Javier Martinez Canillas:
>> The drm_atomic_helper_damage_merged() helper merges all the damage clips
>> into one rectangle. If there are multiple damage clips that aren't close
>> to each other, the resulting rectangle
Hi all,
On Wed, 5 Oct 2022 12:45:31 -0400 Hamza Mahfooz wrote:
>
> On 2022-10-05 11:30, Alex Deucher wrote:
> > @Mahfooz, Hamza
> > @Aurabindo Pillai can you get this fixed up?
> >
>
> Seems like this is a false positive for GCC versions pre-12, because I'm not
> seeing this warning on GCC 1
On Wed, 5 Oct 2022 14:17:17 -0600
Alex Williamson wrote:
> On Thu, 29 Sep 2022 14:48:35 -0300
> Jason Gunthorpe wrote:
>
> > When converting to directly create the vfio_device the mdev driver has to
> > put a vfio_register_emulated_iommu_dev() in the probe() and a pairing
> > vfio_unregister_gr
On 10/5/2022 11:16 AM, Marijn Suijten wrote:
dsi_populate_dsc_params() is called prior to dsi_update_dsc_timing() and
already computes a value for slice_chunk_size, whose value doesn't need
to be recomputed and re-set here.
Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration"
On 10/5/2022 11:16 AM, Marijn Suijten wrote:
This exact same math is used to compute bytes_in_slice above in
dsi_update_dsc_timing(), also used to fill slice_chunk_size.
Fixes: b9080324d6ca ("drm/msm/dsi: add support for dsc data")
Signed-off-by: Marijn Suijten
Reviewed-by: Abhinav Kumar
On 2022-10-06 00:11:06, Dmitry Baryshkov wrote:
> On 06/10/2022 00:08, Marijn Suijten wrote:
> > [..]
> > Aside fixing that to assign these values (through the proper constants)
> > to dsc->mux_word_size, is it worth looking for the right parameters for
> > other bpc or return -EINVAL if bpc isn't
On 10/5/2022 11:16 AM, Marijn Suijten wrote:
Multiplying a value by 2 and adding 1 to it always results in a value
that is uneven, and that 1 gets truncated immediately when performing
integer division by 2 again. There is no "rounding" possible here.
After that target_bpp_x16 is used to sto
On 06/10/2022 00:08, Marijn Suijten wrote:
On 2022-10-05 22:58:48, Marijn Suijten wrote:
On 2022-10-05 22:31:43, Dmitry Baryshkov wrote:
[..]
In fact, could you please take a look if we can switch to using this
function and drop our code?
[..]
Do you want me to do this in a v3, before applyi
On 2022-10-05 22:58:48, Marijn Suijten wrote:
> On 2022-10-05 22:31:43, Dmitry Baryshkov wrote:
> > [..]
> > In fact, could you please take a look if we can switch to using this
> > function and drop our code?
>
> [..]
>
> Do you want me to do this in a v3, before applying this fractional-bits
> fi
On 05/10/2022 23:58, Marijn Suijten wrote:
On 2022-10-05 22:31:43, Dmitry Baryshkov wrote:
On Wed, 5 Oct 2022 at 21:17, Marijn Suijten
wrote:
drm_dsc_config's bits_per_pixel field holds a fractional value with 4
bits, which all panel drivers should adhere to for
drm_dsc_pps_payload_pack() to
On 2022-10-05 22:31:43, Dmitry Baryshkov wrote:
> On Wed, 5 Oct 2022 at 21:17, Marijn Suijten
> wrote:
> >
> > drm_dsc_config's bits_per_pixel field holds a fractional value with 4
> > bits, which all panel drivers should adhere to for
> > drm_dsc_pps_payload_pack() to generate a valid payload. A
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 67ae4f7434cee86ee318d46fb10b8a9840ad2e81 Add linux-next specific
files for 20221005
Error/Warning reports:
https://lore.kernel.org/linux-mm/202209060229.dvuyxjbv-...@intel.com
https
On Thu, 6 Oct 2022 at 04:38, Linus Torvalds
wrote:
>
> On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie wrote:
> >
> > This is very conflict heavy, mostly the correct answer is picking
> > the version from drm-next.
>
> Ugh, yes, that was a bit annoying.
>
> I get the same end result as you did, but I
Hi Jagan,
On 05.10.2022 17:12, Jagan Teki wrote:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
>
> The final bridge supports both the Exynos and i.MX8MM DSI devices.
>
> Changes for v7:
> * fix the drm bridge attach chain for exynos
On Thu, 29 Sep 2022 14:48:35 -0300
Jason Gunthorpe wrote:
> When converting to directly create the vfio_device the mdev driver has to
> put a vfio_register_emulated_iommu_dev() in the probe() and a pairing
> vfio_unregister_group_dev() in the remove.
>
> This was missed for gvt, add it.
>
> Cc:
Hi, Thomas.
Because you've been the one who's been working on drm_fb_helper.c the most the
last
few years I wanted to pick your brain a bit.
I was porting vmwgfx to drm_fb_helper code which is largely trivial, just
removing
all of vmwgfx_fb.c and replacing it with a call to drm_fbdev_generic_se
On Tue, 2022-10-04 at 16:46 -0400, Rodrigo Siqueira Jordao wrote:
>
> On 2022-10-04 16:24, Lyude Paul wrote:
> > Yikes, it appears somehow I totally made a mistake here. We're currently
> > checking to see if drm_dp_add_payload_part2() returns a non-zero value to
> > indicate success. That's total
On Wed, 5 Oct 2022 at 21:17, Marijn Suijten
wrote:
>
> drm_dsc_config's bits_per_pixel field holds a fractional value with 4
> bits, which all panel drivers should adhere to for
> drm_dsc_pps_payload_pack() to generate a valid payload. All code in the
> DSI driver here seems to assume that this f
On 10/3/2022 05:00, Tvrtko Ursulin wrote:
On 03/10/2022 08:53, Tvrtko Ursulin wrote:
On 30/09/2022 18:44, John Harrison wrote:
On 9/30/2022 02:22, Tvrtko Ursulin wrote:
On 29/09/2022 17:21, John Harrison wrote:
On 9/29/2022 00:42, Tvrtko Ursulin wrote:
On 29/09/2022 03:18, john.c.harri...@in
On 2022-10-05 07:19:11, Abhinav Kumar wrote:
> > [..]
> >
> > Or are you suggesting to "redo" the DSC integration work based on a
> > (much) newer display techpack (SDE driver)?
>
> There is no need to redo the DSC integration now.
>
> The code I am referring to is here :
>
> https://git.codeli
The pull request you sent on Wed, 5 Oct 2022 13:41:47 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-10-05
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7e6739b9336e61fe23ca4e2c8d1fda8f19f979bf
Thank you!
--
Deet-doot-dot, I am a bot.
https://kor
On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie wrote:
>
> This is very conflict heavy, mostly the correct answer is picking
> the version from drm-next.
Ugh, yes, that was a bit annoying.
I get the same end result as you did, but I do wonder if the drm
people should try to keep some kind of separate
On 2022-10-05 08:33:23, Abhinav Kumar wrote:
[..]
> hmm downstream seems to have the & just before the reg write
>
> https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/DISPLAY.LA.2.0.r1-08000-WAIPIO.0/msm/sde/sde_hw_dsc_1_2.c#L310
https://git.codelinaro.org/c
According to the comment this DPU register contains the bits per pixel
as a 6.4 fractional value, conveniently matching the contents of
bits_per_pixel in struct drm_dsc_config which also uses 4 fractional
bits. However, the downstream source this implementation was
copy-pasted from has its bpp fie
The bpg_offset array contains negative BPG offsets which fill the full 8
bits of a char thanks to two's complement: this however results in those
bits bleeding into the next field when the value is packed into DSC PPS
by the drm_dsc_helper function, which only expects range_bpg_offset to
contain 6-
dsi_populate_dsc_params() is called prior to dsi_update_dsc_timing() and
already computes a value for slice_chunk_size, whose value doesn't need
to be recomputed and re-set here.
Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
Signed-off-by: Marijn Suijten
---
drivers/gpu/
drm_dsc_config's bits_per_pixel field holds a fractional value with 4
bits, which all panel drivers should adhere to for
drm_dsc_pps_payload_pack() to generate a valid payload. All code in the
DSI driver here seems to assume that this field doesn't contain any
fractional bits, hence resulting in t
This exact same math is used to compute bytes_in_slice above in
dsi_update_dsc_timing(), also used to fill slice_chunk_size.
Fixes: b9080324d6ca ("drm/msm/dsi: add support for dsc data")
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 4 +---
1 file changed, 1 insertion(+)
slice_per_intf is already computed for intf_width, which holds the same
value as hdisplay.
Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
Reviewed-by: Bjorn Andersson
Reviewed-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
Reviewed-by: Vinod Koul
Signed-off-by: Marijn Sui
Various removals of complex yet unnecessary math, fixing all uses of
drm_dsc_config::bits_per_pixel to deal with the fact that this field
includes four fractional bits, and finally making sure that
range_bpg_offset contains values 6-bits wide to prevent overflows in
drm_dsc_pps_payload_pack().
Alt
Multiplying a value by 2 and adding 1 to it always results in a value
that is uneven, and that 1 gets truncated immediately when performing
integer division by 2 again. There is no "rounding" possible here.
After that target_bpp_x16 is used to store a multiplication of
bits_per_pixel by 16 which
On Wed, 05 Oct 2022, Jani Nikula wrote:
> On Wed, 05 Oct 2022, Vinay Belgaumkar wrote:
>> Move it to the RPS source file.
>>
>> v2: Separate out code movement and functional changes (Jani)
>>
>> Signed-off-by: Vinay Belgaumkar
>
> Reviewed-by: Jani Nikula
PS. Sorry, I'll leave patch 2 for some
On Wed, 05 Oct 2022, Vinay Belgaumkar wrote:
> Move it to the RPS source file.
>
> v2: Separate out code movement and functional changes (Jani)
>
> Signed-off-by: Vinay Belgaumkar
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 157 +
> drivers
Am 30.09.22 um 17:29 schrieb Javier Martinez Canillas:
The drm_atomic_helper_damage_merged() helper merges all the damage clips
into one rectangle. If there are multiple damage clips that aren't close
to each other, the resulting rectangle could be quite big.
Instead of using that function hel
On 2022-10-05 11:30, Alex Deucher wrote:
@Mahfooz, Hamza
@Aurabindo Pillai can you get this fixed up?
Seems like this is a false positive for GCC versions pre-12, because I'm
not seeing this warning on GCC 12.2.
However, we can fix this for older GCC versions with the following:
diff --git
On 30/09/2022 12:45, Thomas Zimmermann wrote:
Hi,
looks good to me. Let's wait until next week before landing the patch,
so that others can comment on it.
applied to drm-misc-next
Thanks,
--
Jocelyn
Best regards
Thomas
Am 30.09.22 um 11:47 schrieb Jocelyn Falempe:
The current ast driv
Read the values stored in the SLPC structures. Remove the
fields that are no longer valid (like RPS interrupts) as
well.
v2: Move all functionality changes to this patch (Jani)
v3: Fix compile warning and if condition (Jani)
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/intel_rps.
Move it to the RPS source file.
v2: Separate out code movement and functional changes (Jani)
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 157 +
drivers/gpu/drm/i915/gt/intel_rps.c | 163 ++
drivers/gpu/drm/i915/gt
Remove the RPS related information that is not valid when
SLPC is enabled.
v2: Add version numbers and address other comments (Jani)
v3: Fix compile warning
Signed-off-by: Vinay Belgaumkar
Vinay Belgaumkar (2):
drm/i915: Add a wrapper for frequency debugfs
drm/i915/slpc: Update the frequenc
On 10/4/2022 3:39 PM, Marijn Suijten wrote:
On 2022-10-04 15:31:10, Abhinav Kumar wrote:
On 10/4/2022 2:57 PM, Marijn Suijten wrote:
[..]
Alas, as explained in the cover letter I opted to perform the masking in
the PPS packing code as the DSC block code also reads these values, and
would s
@Mahfooz, Hamza
@Aurabindo Pillai can you get this fixed up?
Thanks,
Alex
On Tue, Oct 4, 2022 at 7:39 AM Mark Brown wrote:
>
> On Tue, Oct 04, 2022 at 02:05:58PM +1100, Stephen Rothwell wrote:
> > On Tue, 4 Oct 2022 12:24:37 +1000 David Airlie wrote:
> > > On Tue, Oct 4, 2022 at 12:21 PM Steph
Hi
Am 05.10.22 um 00:28 schrieb Javier Martinez Canillas:
On 9/19/22 15:04, Thomas Zimmermann wrote:
Use a damage iterator to process damage areas individually. Merging
damage areas can resul tin large updates of unchanged framebuffer
result in
regions. As USB is rather slow, it's better to
Hi,
On Fri, Sep 30, 2022 at 7:20 AM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Sep 29, 2022 at 9:25 PM Jason Yen
> wrote:
> >
> > This chip can not handle aux defer if the host directly program
> > its aux registers to access edid/dpcd. So we need let software
> > to handle the aux defer situation
Look like an explicit fixing up of mode_flags is required for DSIM IP
present in i.MX8M Mini/Nano SoCs.
At least the LCDIF + DSIM needs active low sync polarities in order
to correlate the correct sync flags of the surrounding components in
the chain to make sure the whole pipeline can work proper
Samsung MIPI DSIM master can also be found in i.MX8MM SoC.
Add compatible and associated driver_data for it.
v7, v6:
* none
v3:
* enable DSIM_QUIRK_FIXUP_SYNC_POL quirk
v5:
* [mszyprow] rebased and adjusted to the new driver initialization
* drop quirk
v4:
* none
v3:
* enable DSIM_QUIRK_FIXUP
eLCDIF is expecting to have input_bus_flags as DE_LOW in order to
set active low during valid data transfer on each horizontal line.
Add DE_LOW flag via drm bridge timings.
v7, v6:
* none
v5:
* rebased based on updated bridge changes
v4, v3, v2, v1:
* none
Signed-off-by: Jagan Teki
---
drive
Samsung MIPI DSIM bridge can also be found in i.MX8MM SoC.
Add dt-bingings for it.
v7, v6, v5, v4:
* none
v3:
* collect Rob Acked-by
v2:
* updated comments
v1:
* new patch
Acked-by: Rob Herring
Signed-off-by: Jagan Teki
---
Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt |
Look like PLL PMS_P offset value varies between platforms that have
Samsung DSIM IP.
However, there is no clear evidence for it as both Exynos and i.MX
8M Mini Application Processor Reference Manual is still referring
the PMS_P offset as 13.
The offset 13 is not working for i.MX8M Mini SoCs but t
The child devices in MIPI DSI can be binding with OF-graph
and also via child nodes.
The OF-graph interface represents the child devices via
remote and associated endpoint numbers like
dsi {
compatible = "fsl,imx8mm-mipi-dsim";
ports {
port@0 {
reg = <0>;
Finding the right input bus format throughout the pipeline is hard
so add atomic_get_input_bus_fmts callback and initialize with the
default RGB888_1X24 bus format on DSI-end.
This format can be used in pipeline for negotiating bus format between
the DSI-end of this bridge and the other component
DSI host initialization handling in previous exynos dsi driver has
some pitfalls. It initializes the host during host transfer() hook
that is indeed not the desired call flow for I2C and any other DSI
configured downstream bridges.
Host transfer() is usually triggered for downstream DSI panels or
In i.MX8M Mini/Nano SoC the DSI Phy requires a MIPI DPHY bit
to reset in order to activate the PHY and that can be done via
upstream i.MX8M blk-ctrl driver.
So, mark the phy get as optional.
v7, v6, v5, v4, v3, v2:
* none
v1:
* new patch
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/sa
Samsung MIPI DSIM controller is common DSI IP that can be used in various
SoCs like Exynos, i.MX8M Mini/Nano.
In order to access this DSI controller between various platform SoCs,
the ideal way to incorporate this in the drm stack is via the drm bridge
driver.
This patch is trying to differentiat
This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.
The final bridge supports both the Exynos and i.MX8MM DSI devices.
Changes for v7:
* fix the drm bridge attach chain for exynos drm dsi driver
* fix the hw_type checking logic
Changes for
Hi
Am 05.10.22 um 00:59 schrieb Javier Martinez Canillas:
On 9/19/22 15:04, Thomas Zimmermann wrote:
Add register constants for the framebuffer scanout addresses and
update the related helper functions. No functional changes.
Signed-off-by: Thomas Zimmermann
---
Reviewed-by: Javier Martinez
On 05/10/2022 11:34, Guillaume Ranquet wrote:
> On Tue, 04 Oct 2022 17:05, Krzysztof Kozlowski
> wrote:
>> On 04/10/2022 13:55, Guillaume Ranquet wrote:
No. You said what the code is doing. I think I understand this. You
still do not need more compatibles. Your sentence did not clarify i
On 10/4/2022 3:11 PM, Marijn Suijten wrote:
On 2022-10-04 10:03:07, Abhinav Kumar wrote:
On 10/1/2022 12:08 PM, Marijn Suijten wrote:
According to the comment this DPU register contains the bits per pixel
as a 6.4 fractional value, conveniently matching the contents of
bits_per_pixel in st
Hi Thomas,
On 05/10/2022 13:11, Thomas Hellström wrote:
Commit 39a2bd34c933 ("drm/i915: Use the vma resource as argument for gtt
binding / unbinding") introduced a regression that due to the vma resource
tracking of the binding state, dpt ptes were not correctly repopulated.
Fix this by clearing
On 2022-10-05 12:10, Sascha Hauer wrote:
On Wed, Oct 05, 2022 at 12:51:57PM +0200, Dan Johansen wrote:
Den 05.10.2022 kl. 12.06 skrev Sascha Hauer:
On Wed, Sep 28, 2022 at 10:39:27AM +0200, Dan Johansen wrote:
Den 28.09.2022 kl. 10.37 skrev Sascha Hauer:
On Tue, Sep 27, 2022 at 07:53:54PM +0
Commit 39a2bd34c933 ("drm/i915: Use the vma resource as argument for gtt
binding / unbinding") introduced a regression that due to the vma resource
tracking of the binding state, dpt ptes were not correctly repopulated.
Fix this by clearing the vma resource state before repopulating.
The state will
In drm_atomic_helper_check_crtc_state(), do not add a new plane state
to the global state if it does not exist already. Adding a new plane
state will result in overhead for the plane during the atomic-commit
step.
For the test in drm_atomic_helper_check_crtc_state() to succeed, it
is important tha
Rename the atomic helper function drm_atomic_helper_check_crtc_state()
to drm_atomic_helper_check_crtc_primary_plane() and only check for an
attached primary plane. Adapt callers.
Instead of having one big function to check for various CRTC state
conditions, we rather want smaller functions that d
(was: drm/atomic-helper: Don't allocated plane state in CRTC check)
Fix the test for a CRTC's primary plane and clean up the test function
to only do the test. Up to v3, this patchset was a single patch, but
the cleanup turns it into a series.
v4:
* clean up the helper function (Ville)
T
On Wed, 05 Oct 2022, Jiri Slaby wrote:
> On 04. 10. 22, 12:52, Jani Nikula wrote:
>> On Tue, 04 Oct 2022, "Jiri Slaby (SUSE)" wrote:
>>> When DRM_I915=y and BACKLIGHT_CLASS_DEVICE=m, the build fails:
>>> ld: drivers/gpu/drm/i915/display/intel_backlight.o: in function
>>> `intel_backlight_device_
On 04. 10. 22, 12:52, Jani Nikula wrote:
On Tue, 04 Oct 2022, "Jiri Slaby (SUSE)" wrote:
When DRM_I915=y and BACKLIGHT_CLASS_DEVICE=m, the build fails:
ld: drivers/gpu/drm/i915/display/intel_backlight.o: in function
`intel_backlight_device_register':
intel_backlight.c:(.text+0x5587): undefined
On Wed, Oct 05, 2022 at 12:51:57PM +0200, Dan Johansen wrote:
>
> Den 05.10.2022 kl. 12.06 skrev Sascha Hauer:
> > On Wed, Sep 28, 2022 at 10:39:27AM +0200, Dan Johansen wrote:
> > > Den 28.09.2022 kl. 10.37 skrev Sascha Hauer:
> > > > On Tue, Sep 27, 2022 at 07:53:54PM +0200, Dan Johansen wrote:
Den 05.10.2022 kl. 12.06 skrev Sascha Hauer:
On Wed, Sep 28, 2022 at 10:39:27AM +0200, Dan Johansen wrote:
Den 28.09.2022 kl. 10.37 skrev Sascha Hauer:
On Tue, Sep 27, 2022 at 07:53:54PM +0200, Dan Johansen wrote:
Den 26.09.2022 kl. 12.30 skrev Michael Riesch:
Hi Sascha,
On 9/26/22 10:04,
The drm_connectors that are embedded in writeback connectors won't be
embedded in intel_connectors, so we can't assume being able to convert a
drm_connector to intel_connector when iterating all the connectors we
have. Use the drm connector list filtering to skip writeback connectors.
Note: We cou
Add new function drm_connector_list_iter_filter_begin() to initialize
connector list iterator with a filter function. Subsequent iteration on
the list will only return connectors on which the filter function
returns true.
Cc: Arun R Murthy
Cc: Suraj Kandpal
Cc: Ville Syrjälä
Signed-off-by: Jani
Currently i915 assumes all drm_connectors it encounters are embedded in
intel_connectors that i915 allocated. The drm_writeback_connector forces
a design where this is not the case; we can't provide our own connector,
and writeback embeds the drm_connector it initializes itself.
To use drm writeba
On Wed, Sep 28, 2022 at 10:39:27AM +0200, Dan Johansen wrote:
>
> Den 28.09.2022 kl. 10.37 skrev Sascha Hauer:
> > On Tue, Sep 27, 2022 at 07:53:54PM +0200, Dan Johansen wrote:
> > > Den 26.09.2022 kl. 12.30 skrev Michael Riesch:
> > > > Hi Sascha,
> > > >
> > > > On 9/26/22 10:04, Sascha Hauer w
From: Eberhard Stoll
I'm currently working on a board with stm32mp157 SOC which contains
a synposys LTDC to DSI bridge (drm/stm/dw_mipi_dsi-stm.c). In this
configuration i observe a overclocking of the LVDS pixel clock.
The reason for this is, that the synopsys bridge increases the DSI
lane cloc
From: Eberhard Stoll
Remove LVDS panel overclocking for some configurations by disabling
burst mode for this chip
With burst mode enabled, some DSI controllers increase their DSI lane
clock beyond the clock which is needed to transfer all pixel data.
But this driver operates with a pixel clock
On Tue, 04 Oct 2022 17:05, Krzysztof Kozlowski
wrote:
>On 04/10/2022 13:55, Guillaume Ranquet wrote:
>>> No. You said what the code is doing. I think I understand this. You
>>> still do not need more compatibles. Your sentence did not clarify it
>>> because it did not answer at all to question "wh
Add support for Reset using GPUCC driver for GPU. This helps to ensure
that GPU state is reset by making sure that CX head switch is collapsed.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ar
Add an optional reference to GPUCC reset which can be used to ensure cx
gdsc collapse during gpu recovery.
Signed-off-by: Akhil P Oommen
Acked-by: Rob Herring
Acked-by: Krzysztof Kozlowski
---
(no changes since v5)
Changes in v5:
- Nit: Remove a duplicate blank line (Krzysztof)
Changes in v4
Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.
Signed-off-by: Akhil P Oommen
Reviewed-by: Dmitry Baryshkov
---
(no changes since v3)
Changes in v3:
- Convert 'struct qcom_reset_ops cx_gdsc_reset' to 'static const' (Krzysztof)
Changes in v2:
- Minor update to use
Add a reset op compatible function to poll for gdsc collapse. This is
required because:
1. We don't wait for it to turn OFF at hardware for VOTABLE GDSCs.
2. There is no way for client drivers (eg. gpu driver) to do
put-with-wait for these gdscs which is required in some scenarios
(eg. GPU
Allow soc specific clk drivers to specify a custom reset operation. We
will use this in an upcoming patch to allow gpucc driver to specify a
differet reset operation for cx_gdsc.
Signed-off-by: Akhil P Oommen
Reviewed-by: Dmitry Baryshkov
---
(no changes since v3)
Changes in v3:
- Use pointer
Add necessary definitions in gpucc bindings to ensure gpu cx gdsc collapse
through 'reset' framework for SC7280.
Signed-off-by: Akhil P Oommen
Acked-by: Krzysztof Kozlowski
---
(no changes since v1)
include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++
1 file changed, 3 insertions(+)
diff -
Some clients like adreno gpu driver would like to ensure that its gdsc
is collapsed at hardware during a gpu reset sequence. This is because it
has a votable gdsc which could be ON due to a vote from another subsystem
like tz, hyp etc or due to an internal hardware signal. To allow
this, gpucc dr
On Tue, 04 Oct 2022, Vinay Belgaumkar wrote:
> Read the values stored in the SLPC structures. Remove the
> fields that are no longer valid (like RPS interrupts) as
> well.
>
> v2: Move all functionality changes to this patch (Jani)
>
> Signed-off-by: Vinay Belgaumkar
> ---
> drivers/gpu/drm/i915
On 04/10/2022 14:28, Christian König wrote:
> Otherwise we would crash if the job is not resubmitted.
>
> v2: fix second usage of s_fence->parent as well.
>
> Signed-off-by: Christian König
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 5 +++--
> 1 file changed,
1 - 100 of 105 matches
Mail list logo
