On 24.06.2023 02:41, Marijn Suijten wrote:
> Enable MDSS and DSI, and configure the Samsung SOFEF01-M ams597ut01
> 6.0" 1080x2520 panel.
>
> Signed-off-by: Marijn Suijten
> ---
> .../dts/qcom/sm6125-sony-xperia-seine-pdx201.dts | 59
> ++
> 1 file changed, 59
On 24.06.2023 02:41, Marijn Suijten wrote:
> Add the DT nodes that describe the MDSS hardware on SM6125, containing
> one MDP (display controller) together with a single DSI and DSI PHY. No
> DisplayPort support is added for now.
>
> Signed-off-by: Marijn Suijten
> ---
>
On Sat, 24 Jun 2023 02:41:05 +0200, Marijn Suijten wrote:
> Document the SM6125 MDSS.
>
> Signed-off-by: Marijn Suijten
> ---
> .../bindings/display/msm/qcom,sm6125-mdss.yaml | 206
> +
> 1 file changed, 206 insertions(+)
>
My bot found errors running 'make
ifficult to determine since this patch can not easily
be reverted.
Guenter
---
# bad: [8d2be868b42c08290509c60515865f4de24ea704] Add linux-next specific files
for 20230623
# good: [45a3e24f65e90a047bef86f927ebdc4c710edaa1] Linux 6.4-rc7
git bisect start 'HEAD' 'v6.4-rc7'
# good: [a5838c78db6a3a02e8d2
On 24.06.2023 02:41, Marijn Suijten wrote:
> Enable and configure the dispcc node on SM6125 for consumption by MDSS
> later on.
>
> Signed-off-by: Marijn Suijten
> ---
> arch/arm64/boot/dts/qcom/sm6125.dtsi | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git
On 24.06.2023 02:41, Marijn Suijten wrote:
> We have a working RPM XO clock; no other driver except rpmcc should be
> parenting directly to the fixed-factor xo_board clock nor should it be
> reachable by that global name. Remove the name to that effect, so that
> every clock relation is
On 24.06.2023 02:41, Marijn Suijten wrote:
> SM6125 features only a single PHY (despite a secondary PHY PLL source
> being available to the disp_cc_mdss_pclk0_clk_src clock), and downstream
> sources for this "trinket" SoC do not define the typical "vcca"
> regulator to be available nor used.
>
>
On 24.06.2023 02:41, Marijn Suijten wrote:
> Add definitions for the display hardware used on the Qualcomm SM6125
> platform.
>
> Signed-off-by: Marijn Suijten
> ---
[...]
> +static const struct dpu_perf_cfg sm6125_perf_data = {
> + .max_bw_low = 410,
> + .max_bw_high = 410,
> +
On 24.06.2023 02:41, Marijn Suijten wrote:
> The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
> be passed from DT, and should be required by the bindings.
>
> Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
> bindings")
> Signed-off-by: Marijn
On 24.06.2023 02:40, Marijn Suijten wrote:
> This node has always resided in the wrong spot, making it somewhat
> harder to contribute new node entries while maintaining proper sorting
> around it. Move the node up to sit after hsusb_phy1 where it maintains
> proper numerial
numerical
sorting on
On 24.06.2023 02:40, Marijn Suijten wrote:
> Bring up the SM6125 DPU now that all preliminary series (such as INTF
> TE) have been merged (for me to test the hardware properly)
We should not repeat the same mistake in the future.. Finding a
balance between releasing early and releasing what we can
On 6/23/2023 5:09 PM, Abhinav Kumar wrote:
On 6/22/2023 5:13 PM, Dmitry Baryshkov wrote:
On 23/06/2023 02:48, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers of sub
blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Add wrapper
function to dump
Document the SM6125 MDSS.
Signed-off-by: Marijn Suijten
---
.../bindings/display/msm/qcom,sm6125-mdss.yaml | 206 +
1 file changed, 206 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml
We have a working RPM XO clock; no other driver except rpmcc should be
parenting directly to the fixed-factor xo_board clock nor should it be
reachable by that global name. Remove the name to that effect, so that
every clock relation is explicitly defined in DTS.
Signed-off-by: Marijn Suijten
SM6125 features only a single PHY (despite a secondary PHY PLL source
being available to the disp_cc_mdss_pclk0_clk_src clock), and downstream
sources for this "trinket" SoC do not define the typical "vcca"
regulator to be available nor used.
Signed-off-by: Marijn Suijten
---
Enable MDSS and DSI, and configure the Samsung SOFEF01-M ams597ut01
6.0" 1080x2520 panel.
Signed-off-by: Marijn Suijten
---
.../dts/qcom/sm6125-sony-xperia-seine-pdx201.dts | 59 ++
1 file changed, 59 insertions(+)
diff --git
Document availability of the 14nm DSI PHY on SM6125.
Signed-off-by: Marijn Suijten
---
Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
Add the DT nodes that describe the MDSS hardware on SM6125, containing
one MDP (display controller) together with a single DSI and DSI PHY. No
DisplayPort support is added for now.
Signed-off-by: Marijn Suijten
---
arch/arm64/boot/dts/qcom/sm6125.dtsi | 190 ++-
Enable and configure the dispcc node on SM6125 for consumption by MDSS
later on.
Signed-off-by: Marijn Suijten
---
arch/arm64/boot/dts/qcom/sm6125.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi
Add definitions for the display hardware used on the Qualcomm SM6125
platform.
Signed-off-by: Marijn Suijten
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h | 173 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 +
SM6125's UBWC hardware decoder is version 3.0, and supports decoding
UBWC 1.0.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/msm_mdss.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index
Document general compatibility of the DSI controller on SM6125.
Signed-off-by: Marijn Suijten
---
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
be passed from DT, and should be required by the bindings.
Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
bindings")
Signed-off-by: Marijn Suijten
---
SM6125 is identical to SM6375 except that while downstream also defines
a throttle clock, its presence results in timeouts whereas SM6375
requires it to not observe any timeouts.
Signed-off-by: Marijn Suijten
---
Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml | 1 +
1 file
On SM6125 the dispcc block is gated behind VDDCX: allow this domain to
be configured.
Signed-off-by: Marijn Suijten
---
Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git
The downsteam driver for dispcc only ever gets and puts this clock
without ever using it in the clocktree; this unnecessary workaround was
never ported to mainline, hence the driver doesn't consume this clock
and shouldn't be required by the bindings.
Fixes: 8397c9c0c26b ("dt-bindings: clock: add
This node has always resided in the wrong spot, making it somewhat
harder to contribute new node entries while maintaining proper sorting
around it. Move the node up to sit after hsusb_phy1 where it maintains
proper numerial sorting on the (first of its many) reg address property.
Fixes:
Bring up the SM6125 DPU now that all preliminary series (such as INTF
TE) have been merged (for me to test the hardware properly), and most
other conflicting work (barring ongoing catalog *improvements*) has made
its way in as well or is still being discussed.
The second part of the series
On sabato 17 giugno 2023 20:04:20 CEST Sumitra Sharma wrote:
> kmap() has been deprecated in favor of the kmap_local_page()
> due to high cost, restricted mapping space, the overhead of a
> global lock for synchronization, and making the process sleep
> in the absence of free slots.
>
>
On 6/22/2023 5:13 PM, Dmitry Baryshkov wrote:
On 23/06/2023 02:48, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers of sub
blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Add wrapper
function to dump hardware blocks that contain sub blocks.
The pull request you sent on Fri, 23 Jun 2023 16:48:56 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-06-23
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a92b7d26c743b9dc06d520f863d624e94978a1d9
Thank you!
--
Deet-doot-dot, I am a bot.
On 6/23/2023 1:18 PM, Marijn Suijten wrote:
On 2023-06-23 23:10:56, Dmitry Baryshkov wrote:
There is no confusion between what was said earlier and now.
This line is calculating the number of pclks needed to transmit one line
of the compressed data:
hdisplay =
On Fri, 23 Jun 2023 at 14:18, Alex Deucher wrote:
>
> are available in the Git repository at:
>
> https://gitlab.freedesktop.org/agd5f/linux.git
> tags/amd-drm-fixes-6.4-2023-06-23
That's not a valid signed tag.
Yes, it's a tag. But it doesn't actually have any cryptographic
signing, and
In many testing circumstances, we will want to just create a new device
and test against that. If we create a default device, it can be annoying
to have to manually select the new device instead of choosing the only
one that exists.
The param, enable_default, is defaulted to true to maintain
VKMS now supports creating and using virtual devices!
In addition to the enabling logic, this commit also prevents users from
adding new objects once a card is registered.
Signed-off-by: Jim Shargo
---
drivers/gpu/drm/vkms/vkms_configfs.c | 37 +++--
drivers/gpu/drm/vkms/vkms_crtc.c | 4
This is a small refactor to make ConfigFS support easier. This should be
a no-op refactor.
Signed-off-by: Jim Shargo
---
drivers/gpu/drm/vkms/vkms_drv.c| 13 +++--
drivers/gpu/drm/vkms/vkms_drv.h| 9 ++---
drivers/gpu/drm/vkms/vkms_output.c | 2 +-
3 files changed, 18
This change adds the basic scaffolding for ConfigFS, including setting
up the default directories. It does not allow for the registration of
configfs-backed devices, which is complex and provided in a follow-up
commit.
This CL includes docs about using ConfigFS with VKMS, but I'll summarize
in
This change supports multiple CRTCs, encoders, connectors instead of one
of each per device.
Since ConfigFS-based devices will support multiple crtcs, it's useful to
move all of the writeback/composition data from being per-"output" to
being per-CRTC.
Since there's still only ever one CRTC, this
This is a small refactor to make ConfigFS support easier. Once we
support ConfigFS, there can be multiple devices instantiated by the
driver, and so moving everything into managed memory makes things much
easier.
This should be a no-op refactor.
Signed-off-by: Jim Shargo
---
Intro
=
At long last, we're back!
This patchset adds basic ConfigFS support to VKMS, allowing users to
build new DRM devices with user-defined DRM objects and object
relationships by creating, writing, and symlinking files.
Usage
=
After installing these patches, you can create a VKMS
On Fri, Jun 23, 2023 at 09:10:57PM +0800, Qi Zheng wrote:
> On 2023/6/23 14:29, Dave Chinner wrote:
> > On Thu, Jun 22, 2023 at 05:12:02PM +0200, Vlastimil Babka wrote:
> > > On 6/22/23 10:53, Qi Zheng wrote:
> > Yes, I suggested the IDR route because radix tree lookups under RCU
> > with
On 6/23/2023 1:28 PM, Marijn Suijten wrote:
On 2023-06-23 14:37:12, Dmitry Baryshkov wrote:
In fact I asked to make it 0xf00 + 0x10 or 0xf80 + 0x10 to also cover
the CTL registers, but that change didn't make it through. 0x29c is an
arbitrary number that I have no clue what it was based
On 2023-06-23 05:08, Christian König wrote:
> Some Android CTS is testing for that.
>
It's not entirely clear what "that" is, other than by the subject title
of the patch. Something like "Record and return the signalling time of
merged fences, as well as regular fences, since some Android CTS(?)
On Fri, Jun 23, 2023 at 02:05:20PM -0700, Lucas De Marchi wrote:
> On Fri, Jun 23, 2023 at 12:48:13PM -0700, Kenneth Graunke wrote:
> > On Friday, June 23, 2023 8:49:05 AM PDT Lucas De Marchi wrote:
> > > On Thu, Jun 22, 2023 at 04:37:21PM -0700, Kenneth Graunke wrote:
> > > >On Thursday, June 22,
On Thu, Jun 22, 2023 at 04:53:21PM +0800, Qi Zheng wrote:
> In preparation for implementing lockless slab shrink,
> we need to dynamically allocate the nfsd-client shrinker,
> so that it can be freed asynchronously using kfree_rcu().
> Then it doesn't need to wait for RCU read-side critical
>
On 6/23/2023 2:33 PM, Marijn Suijten wrote:
On 2023-06-23 13:34:06, Abhinav Kumar wrote:
On 6/23/2023 1:14 PM, Marijn Suijten wrote:
On 2023-06-23 10:29:51, Abhinav Kumar wrote:
The concept is quite simple
one pixel per clock for uncompresssed without widebubus
2 pixels per clock for
On Fri, Jun 23, 2023 at 2:15 PM Julia Lawall wrote:
>
> Use array_size to protect against multiplication overflows.
>
> The changes were done using the following Coccinelle semantic patch:
>
> //
> @@
> size_t e1,e2;
> expression COUNT;
> identifier alloc =
Hi Yunxiang,
kernel test robot noticed the following build errors:
url:
https://github.com/intel-lab-lkp/linux/commits/UPDATE-20230624-040209/Yunxiang-Li/drm-amdgpu-fix-missing-fence-reserve-in-amdgpu_vm_sdma_commit/20230622-002915
base: the 2th patch of
Hi Yunxiang,
kernel test robot noticed the following build errors:
url:
https://github.com/intel-lab-lkp/linux/commits/UPDATE-20230624-040209/Yunxiang-Li/drm-amdgpu-fix-missing-fence-reserve-in-amdgpu_vm_sdma_commit/20230622-002915
base: the 2th patch of
Hi Linus,
Can you please pull this directly,
Thanks,
Dave.
On Sat, 24 Jun 2023 at 07:18, Alex Deucher wrote:
>
> Hi Dave, Daniel, Linus,
>
> Last few fixes for 6.4. Dave already sent out the drm-fixes PR this week.
> I was out of the office earlier in the week and just got this out now.
>
>
On 2023-06-23 13:34:06, Abhinav Kumar wrote:
>
>
> On 6/23/2023 1:14 PM, Marijn Suijten wrote:
> > On 2023-06-23 10:29:51, Abhinav Kumar wrote:
> >
> >> The concept is quite simple
> >>
> >> one pixel per clock for uncompresssed without widebubus
> >>
> >> 2 pixels per clock for uncompressed
Use array_size to protect against multiplication overflows.
This follows up on the following patches by Kees Cook from 2018.
42bc47b35320 ("treewide: Use array_size() in vmalloc()")
fad953ce0b22 ("treewide: Use array_size() in vzalloc()")
The changes were done using the following Coccinelle
Use array_size to protect against multiplication overflows.
The changes were done using the following Coccinelle semantic patch:
//
@@
expression E1, E2;
constant C1, C2;
identifier alloc = {vmalloc,vzalloc};
@@
(
alloc(C1 * C2,...)
|
alloc(
- (E1) * (E2)
Use array_size to protect against multiplication overflows.
The changes were done using the following Coccinelle semantic patch:
//
@@
size_t e1,e2;
expression COUNT;
identifier alloc = {vmalloc,vzalloc,kvmalloc,kvzalloc};
@@
(
alloc(
- (e1) * (e2)
+
Use array_size to protect against multiplication overflows.
The changes were done using the following Coccinelle semantic patch:
//
@@
size_t e1,e2;
expression COUNT;
identifier alloc = {vmalloc,vzalloc,kvmalloc,kvzalloc};
@@
(
alloc(
- (e1) * (e2)
+
Use array_size to protect against multiplication overflows.
The changes were done using the following Coccinelle semantic patch:
//
@@
expression E1, E2;
constant C1, C2;
identifier alloc = {vmalloc,vzalloc};
@@
(
alloc(C1 * C2,...)
|
alloc(
- (E1) * (E2)
Use array_size to protect against multiplication overflows.
The changes were done using the following Coccinelle semantic patch:
//
@@
expression E1, E2;
constant C1, C2;
identifier alloc = {vmalloc,vzalloc};
@@
(
alloc(C1 * C2,...)
|
alloc(
- (E1) * (E2)
Hi Yunxiang,
kernel test robot noticed the following build errors:
url:
https://github.com/intel-lab-lkp/linux/commits/UPDATE-20230624-040209/Yunxiang-Li/drm-amdgpu-fix-missing-fence-reserve-in-amdgpu_vm_sdma_commit/20230622-002915
base: the 2th patch of
Hi Dave, Daniel, Linus,
Last few fixes for 6.4. Dave already sent out the drm-fixes PR this week.
I was out of the office earlier in the week and just got this out now.
The following changes since commit 9bd9be5cbaf8a8faa175ef4fba04a5623281debe:
Merge tag 'drm-misc-fixes-2023-06-21' of
On Fri, Jun 23, 2023 at 2:49 AM Dave Airlie wrote:
>
> Hey Linus,
>
> very quiet last week, just two misc fixes, one dp-mst and one qaic.
>
> Should be all ready for the merge window next week.
Was out of the office this week and didn't get to -fixes until today.
Will send the PR to everyone
On Fri, Jun 23, 2023 at 12:48:13PM -0700, Kenneth Graunke wrote:
On Friday, June 23, 2023 8:49:05 AM PDT Lucas De Marchi wrote:
On Thu, Jun 22, 2023 at 04:37:21PM -0700, Kenneth Graunke wrote:
>On Thursday, June 22, 2023 11:27:30 AM PDT Lucas De Marchi wrote:
>> Most of the context workarounds
Hi Carlos!
Em 23/06/2023 12:25, Carlos Eduardo Gallo Filho escreveu:
The "YVU420 DRM_MODE_FB_MODIFIERS set without modifier" test
hadn't DRM_MODE_FB_MODIFIERS set, so that it was in fact testing
another case, while the "YVU420 Normal sizes" test in turn was with
DRM_MODE_FB_MODIFIERS set and
On 6/23/2023 1:14 PM, Marijn Suijten wrote:
On 2023-06-23 10:29:51, Abhinav Kumar wrote:
The concept is quite simple
one pixel per clock for uncompresssed without widebubus
2 pixels per clock for uncompressed with widebus (only enabled for DP
not DSI)
3 bytes worth of data for compressed
On 2023-06-17 03:48:33, Dmitry Baryshkov wrote:
> On 17/06/2023 01:12, Marijn Suijten wrote:
> > On 2023-06-16 13:03:15, Dmitry Baryshkov wrote:
> >> To simplify making changes to the hardware block definitions, expand
> >> corresponding macros. This way making all the changes are more obvious
>
On 2023-06-23 14:37:12, Dmitry Baryshkov wrote:
> > In fact I asked to make it 0xf00 + 0x10 or 0xf80 + 0x10 to also cover
> > the CTL registers, but that change didn't make it through. 0x29c is an
> > arbitrary number that I have no clue what it was based on.
>
> This should have been NAKed. or
On 2023-06-23 12:36:06, Abhinav Kumar wrote:
>
>
> On 6/22/2023 11:57 PM, Marijn Suijten wrote:
> > On 2023-06-23 08:54:39, Marijn Suijten wrote:
> >> On 2023-06-22 22:47:04, Abhinav Kumar wrote:
> >>> On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
> All DSC_BLK_1_2 declarations incorrectly
On 2023-06-23 14:32:55, Neil Armstrong wrote:
> Document the optional displayport controller subnode of the SM8550 MDSS.
>
> Acked-by: Rob Herring
> Signed-off-by: Neil Armstrong
Reviewed-by: Marijn Suijten
> ---
> .../devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml | 8
>
On 2023-06-23 14:32:54, Neil Armstrong wrote:
> Document the optional displayport controller subnode of the SM8450 MDSS.
>
> Acked-by: Rob Herring
> Signed-off-by: Neil Armstrong
Reviewed-by: Marijn Suijten
> ---
> .../devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml | 8
>
On 2023-06-23 14:32:53, Neil Armstrong wrote:
> Document the optional displayport controller subnode of the SM8350 MDSS.
>
> Acked-by: Rob Herring
> Signed-off-by: Neil Armstrong
Reviewed-by: Marijn Suijten
> ---
> Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml | 6
>
On 2023-06-23 23:10:56, Dmitry Baryshkov wrote:
> >> There is no confusion between what was said earlier and now.
> >>
> >> This line is calculating the number of pclks needed to transmit one line
> >> of the compressed data:
> >>
> >> hdisplay =
Calling dma_resv_reserve_fences a second time would not reserve memory
correctly, this is quite unintuitive and the current debug build option
cannot catch this error reliably because of the slack in max_fences.
Rework the function to allow multiple invocations, also make reserve
check stricter.
On 2023-06-23 10:29:51, Abhinav Kumar wrote:
> The concept is quite simple
>
> one pixel per clock for uncompresssed without widebubus
>
> 2 pixels per clock for uncompressed with widebus (only enabled for DP
> not DSI)
>
> 3 bytes worth of data for compressed without widebus
>
> 6 bytes
On 23/06/2023 23:02, Marijn Suijten wrote:
On 2023-06-23 12:54:17, Abhinav Kumar wrote:
On 6/23/2023 12:26 AM, Marijn Suijten wrote:
On 2023-06-22 17:32:17, Abhinav Kumar wrote:
On 6/22/2023 5:17 PM, Dmitry Baryshkov wrote:
On 23/06/2023 03:14, Abhinav Kumar wrote:
On 6/19/2023 2:06
On 2023-06-23 12:54:17, Abhinav Kumar wrote:
>
>
> On 6/23/2023 12:26 AM, Marijn Suijten wrote:
> > On 2023-06-22 17:32:17, Abhinav Kumar wrote:
> >>
> >>
> >> On 6/22/2023 5:17 PM, Dmitry Baryshkov wrote:
> >>> On 23/06/2023 03:14, Abhinav Kumar wrote:
>
>
> On 6/19/2023 2:06 PM,
Calling dma_resv_reserve_fences a second time would not reserve memory
correctly, this is quite unintuitive and the current debug build option
cannot catch this error reliably because of the slack in max_fences.
Rework the function to allow multiple invocations, also make reserve
check stricter.
On Friday, June 23, 2023 8:49:05 AM PDT Lucas De Marchi wrote:
> On Thu, Jun 22, 2023 at 04:37:21PM -0700, Kenneth Graunke wrote:
> >On Thursday, June 22, 2023 11:27:30 AM PDT Lucas De Marchi wrote:
> >> Most of the context workarounds tweak masked registers, but not all. For
> >> masked
On 6/23/2023 12:26 AM, Marijn Suijten wrote:
On 2023-06-22 17:32:17, Abhinav Kumar wrote:
On 6/22/2023 5:17 PM, Dmitry Baryshkov wrote:
On 23/06/2023 03:14, Abhinav Kumar wrote:
On 6/19/2023 2:06 PM, Dmitry Baryshkov wrote:
Provide actual documentation for the pclk and hdisplay
On 6/23/2023 12:40 PM, Dmitry Baryshkov wrote:
On 23/06/2023 22:37, Abhinav Kumar wrote:
On 6/23/2023 4:37 AM, Dmitry Baryshkov wrote:
On 23/06/2023 09:54, Marijn Suijten wrote:
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2
On 23/06/2023 22:37, Abhinav Kumar wrote:
On 6/23/2023 4:37 AM, Dmitry Baryshkov wrote:
On 23/06/2023 09:54, Marijn Suijten wrote:
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block
On 6/23/2023 4:37 AM, Dmitry Baryshkov wrote:
On 23/06/2023 09:54, Marijn Suijten wrote:
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block
length.
This includes the common block
On 6/22/2023 11:57 PM, Marijn Suijten wrote:
On 2023-06-23 08:54:39, Marijn Suijten wrote:
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block
On Fri, Jun 23, 2023 at 08:09:53PM +0200, Geert Uytterhoeven wrote:
> On Fri, Jun 23, 2023 at 7:54 PM Sam Ravnborg wrote:
> > On Fri, Jun 23, 2023 at 08:50:19PM +0300, Laurent Pinchart wrote:
> > > On Thu, Jun 22, 2023 at 11:21:51AM +0200, Geert Uytterhoeven wrote:
> > > > Add DT support, by:
> >
On Fri, Jun 23, 2023 at 07:55:22PM +0200, Geert Uytterhoeven wrote:
> On Fri, Jun 23, 2023 at 6:50 PM Laurent Pinchart wrote:
> > On Thu, Jun 22, 2023 at 11:21:36AM +0200, Geert Uytterhoeven wrote:
> > > Unify primary and overlay plane allocation:
> > > - Enhance shmob_drm_plane_create() so it
On 2023-06-23 04:03, Boris Brezillon wrote:
> On Fri, 23 Jun 2023 09:52:04 +0200
> Boris Brezillon wrote:
>
>> Drivers that can delegate waits to the firmware/GPU pass the scheduled
>> fence to drm_sched_job_add_dependency(), and issue wait commands to
>> the firmware/GPU at job submission time.
Hi Sam, Laurent,
On Fri, Jun 23, 2023 at 7:54 PM Sam Ravnborg wrote:
> On Fri, Jun 23, 2023 at 08:50:19PM +0300, Laurent Pinchart wrote:
> > On Thu, Jun 22, 2023 at 11:21:51AM +0200, Geert Uytterhoeven wrote:
> > > Add DT support, by:
> > > 1. Creating a panel bridge from DT, and attaching it
On 6/23/2023 6:58 AM, Dmitry Baryshkov wrote:
Ryan pointed out [1] that some (most) of of sub-blocks do not fill the
field `name'. Further research showed that we can drop the fields `name'
and `id' and further simplify the catalog. The handling code also
usually knows, which sub-block it is
Hi Fei,
Thanks for review. I put my answers inline below.
Regards,
Zhanjun
On 2023-06-22 6:20 p.m., Yang, Fei wrote:
> The previouse i915_gem_object_create_internal already set it with
proper
> value before function return. This hard coded setting is incorrect for
> platforms like MTL, thus
Hi Laurent,
On Fri, Jun 23, 2023 at 6:50 PM Laurent Pinchart
wrote:
> On Thu, Jun 22, 2023 at 11:21:36AM +0200, Geert Uytterhoeven wrote:
> > Unify primary and overlay plane allocation:
> > - Enhance shmob_drm_plane_create() so it can be used to create the
> > primary plane, too,
> > -
On Fri, Jun 23, 2023 at 08:50:19PM +0300, Laurent Pinchart wrote:
> Hi Geert,
>
> Thank you for the patch.
>
> On Thu, Jun 22, 2023 at 11:21:51AM +0200, Geert Uytterhoeven wrote:
> > Add DT support, by:
> > 1. Creating a panel bridge from DT, and attaching it to the encoder,
> > 2. Replacing
On Fri, Jun 23, 2023 at 07:51:07PM +0200, Geert Uytterhoeven wrote:
> Hi Laurent,
>
> On Fri, Jun 23, 2023 at 6:39 PM Laurent Pinchart
> wrote:
> > On Thu, Jun 22, 2023 at 11:21:35AM +0200, Geert Uytterhoeven wrote:
> > > Move legacy interface handling to the connector setup code.
> > > Set up
Hi Geert,
On Fri, Jun 23, 2023 at 07:41:36PM +0200, Geert Uytterhoeven wrote:
> On Fri, Jun 23, 2023 at 5:34 PM Laurent Pinchart wrote:
> > On Fri, Jun 23, 2023 at 05:22:45PM +0200, Geert Uytterhoeven wrote:
> > > On Fri, Jun 23, 2023 at 5:11 PM Laurent Pinchart wrote:
> > > > On Fri, Jun 23,
Hi Laurent,
On Fri, Jun 23, 2023 at 6:39 PM Laurent Pinchart
wrote:
> On Thu, Jun 22, 2023 at 11:21:35AM +0200, Geert Uytterhoeven wrote:
> > Move legacy interface handling to the connector setup code.
> > Set up bus_flags and bus_formats in display_info according to the
> > bus format and panel
Hi Geert,
Thank you for the patch.
On Thu, Jun 22, 2023 at 11:21:51AM +0200, Geert Uytterhoeven wrote:
> Add DT support, by:
> 1. Creating a panel bridge from DT, and attaching it to the encoder,
> 2. Replacing the custom connector with a bridge connector,
> 3. Obtaining clock
On 6/23/2023 4:25 AM, Dmitry Baryshkov wrote:
On 23/06/2023 08:47, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block itself, enc subblocks and some empty
space around.
Hi Laurent,
On Fri, Jun 23, 2023 at 5:34 PM Laurent Pinchart
wrote:
> On Fri, Jun 23, 2023 at 05:22:45PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Jun 23, 2023 at 5:11 PM Laurent Pinchart wrote:
> > > On Fri, Jun 23, 2023 at 06:07:44PM +0300, Laurent Pinchart wrote:
> > > > On Thu, Jun 22,
Applied. Thanks!
Alex
On Thu, Jun 22, 2023 at 3:32 AM Yueh-Shun Li wrote:
>
> Spell "transmission" properly.
>
> Found by searching for keyword "tranm".
>
> Signed-off-by: Yueh-Shun Li
> ---
> .../gpu/drm/amd/display/dc/dcn31/dcn31_hpo_dp_stream_encoder.c | 2 +-
> 1 file changed, 1
On 6/23/2023 12:19 AM, Marijn Suijten wrote:
On 2023-06-22 17:01:34, Abhinav Kumar wrote:
More interesting would be a link to the Mesa MR upstreaming this
bitfield to dsi.xml [2] (which I have not found on my own yet).
[2]:
On Fri, Jun 23, 2023 at 01:37:58PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 23, 2023 at 12:35:45PM -0400, Peter Xu wrote:
>
> > It seems the previous concern on using gup was majorly fork(), if this is
> > it:
> >
> >
Hi Geert,
Thank you for the patch.
On Thu, Jun 22, 2023 at 11:21:50AM +0200, Geert Uytterhoeven wrote:
> Complete the conversion to atomic mode setting by converting the
> connector, and setting the DRIVER_ATOMIC flag.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
>
On Fri, Jun 23, 2023 at 6:48 PM Limonciello, Mario
wrote:
>
>
> On 6/23/2023 11:28 AM, Rafael J. Wysocki wrote:
> > On Fri, Jun 23, 2023 at 5:57 PM Limonciello, Mario
> > wrote:
> >>
> >> On 6/23/2023 9:52 AM, Rafael J. Wysocki wrote:
> >>> On Wed, Jun 21, 2023 at 7:47 AM Evan Quan wrote:
>
1 - 100 of 265 matches
Mail list logo
