Hello,
syzbot found the following issue on:
HEAD commit:022ce8862dff Merge tag 'i2c-for-6.4-rc6' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1048185328
kernel config: https://syzkaller.appspot.com/x/.config?x=3c980bfe8b399968
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still be wrong even if we remove the #ifdef and #endif guards.
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still be wrong even if we remove the #ifdef and #endif guards.
From: Sui Jingfeng
The vga_is_firmware_default() function is arch-dependent, it's probably
wrong if we simply remove the arch guard. As the VRAM BAR which contains
firmware framebuffer may move, while the lfb_base and lfb_size members of
the screen_info does not change accordingly. In short, it
From: Sui Jingfeng
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately due to the fact that apertures list will be
freed dynamically, the location and size information of the firmware fb
will be lost after dedicated drivers call
From: Sui Jingfeng
Per Documentation/process/license-rules.rst, the SPDX MIT identifier is
equivalent to including the entire MIT license text from
LICENSES/preferred/MIT.
Replace the MIT license text with the equivalent SPDX identifier.
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten
From: Sui Jingfeng
This patch replaces the leading space with a tab and removes the double
blank line, no functional change.
Cc: Bjorn Helgaas
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
Reviewed-by: Andi
From: Sui Jingfeng
The io_state variable in the vga_arb_write() function is declared with
unsigned int type, while the vga_str_to_iostate() function takes int *
type. To keep them consistent, replace the third argument of
vga_str_to_iostate() function with the unsigned int * type.
Cc: Bjorn
From: Sui Jingfeng
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
device(pdev->class != 0x0300) out. There no need to process the non-display
PCI device.
Cc: Bjorn Helgaas
Signed-off-by: Sui
The vga_is_firmware_default() function is arch-dependent, it's probably
wrong if we simply remove the arch guard. As the VRAM BAR which contains
firmware framebuffer may move, while the lfb_base and lfb_size members of
the screen_info does not change accordingly. In short, it should take the
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
device(pdev->class != 0x0300) out. There no need to process the non-display
PCI device.
Cc: Bjorn Helgaas
Signed-off-by: Sui Jingfeng
---
Per Documentation/process/license-rules.rst, the SPDX MIT identifier is
equivalent to including the entire MIT license text from
LICENSES/preferred/MIT.
Replace the MIT license text with the equivalent SPDX identifier.
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
The io_state variable in the vga_arb_write() function is declared with
unsigned int type, while the vga_str_to_iostate() function takes int *
type. To keep them consistent, replace the third argument of
vga_str_to_iostate() function with the unsigned int * type.
Cc: Bjorn Helgaas
Signed-off-by:
This patch replaces the leading space with a tab and removes the double
blank line, no functional change.
Cc: Bjorn Helgaas
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
Reviewed-by: Andi Shyti
---
From: Sui Jingfeng <15330273...@189.cn>
The vga_is_firmware_default() function is arch-dependent, it's probably
wrong if we simply remove the arch guard. As the VRAM BAR which contains
firmware framebuffer may move, while the lfb_base and lfb_size members of
the screen_info does not change
Quoting Douglas Anderson (2023-06-12 16:53:03)
> Memory for the "struct device" for any given device isn't supposed to
> be released until the device's release() is called. This is important
> because someone might be holding a kobject reference to the "struct
> device" and might try to access one
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 52 ++--
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 41 ++---
The INTF_SDM845_MASK features mask is zero. Drop it completely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 4
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 --
The MERGE_3D_SM8150_MASK features mask is zero. Drop it completely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 3 ---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 3 ---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h |
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
---
.../drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 14 --
The INTF_SDM845_MASK features mask is zero. Drop it completely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 4
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 --
The MERGE_3D_SM8150_MASK features mask is zero. Drop it completely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 3 ---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 3 ---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h |
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 52 ++--
Hi, Matthias:
Matthias Brugger 於 2023年5月29日 週一 下午10:07寫道：
>
> Hi Chun-Kuang Hu,
>
> Can you help to merge the missing DT-binding patches in this series?
Apply display binding of this series to mediatek-drm-next [1].
[1]
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 15 +++---
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 81 +++---
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 16 +++---
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 11 +--
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 55 +
Shift dpu_ctl_cfg contents to correct the indentation of CTL blocks.
This is done in preparation to expanding the rest of hardware block
defines, so that all blocks have similar indentation.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 46 +++---
To simplify making changes to the hardware block definitions, expand
corresponding macros. This way making all the changes are more obvious
and visible in the source files.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 11 +-
Drop useless zero assignments to the dpu_ctl_cfg::features field.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 3 ---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 3 ---
2 files changed, 6 deletions(-)
diff --git
Since there is always just a single MDP_TOP instance, drop the enum
dpu_mdp and corresponding index value.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 2 +-
Drop useless zero assignments to the dpu_mdp_cfg::features field.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h | 1 -
Follow the DP example and define MSM_DSI_CONTROLLER_n enumeration.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index
There is always a single MDP TOP block. Drop the mdp_count field and
stop declaring dpu_mdp_cfg instances as arrays.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 7 ++---
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 7 ++---
Use more standard initialisation for .clk_ctrls definitions. Define a
single .clk_ctrls field and use array init inside.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 22 +
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 18 +++---
For each LM there is at max 1 peer LM which can be driven by the same
CTL, so there no need to have a mask instead of just an ID of the peer
LM.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 2 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 4 +--
sm6115 and qcm2290 do not have INTF_0. Drop corresponding interface
definitions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 -
In several catalog entries we did not use existing MSM_DP_CONTROLLER_n
constants. Fill them in. Also use freshly defined MSM_DSI_CONTROLLER_n
for DSI interfaces.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 6 +++---
Having a macro with 10 arguments doesn't seem like a good idea. It makes
it inherently harder to compare the actual structure values. Also this
leads to adding macros covering varieties of the block.
As it was previously discussed, inline all foo_BLK macros in order to
ease performing changes to
Each MERGE_3D block has just two registers. Correct the block length
accordingly.
Fixes: 4369c93cf36b ("drm/msm/dpu: initial support for merge3D hardware block")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
1 file changed, 1 insertion(+), 1
During IRQ conversion we have lost the PP_DONE interrupts for sc7280
platform. This was left unnoticed, because this interrupt is only used
for CMD outputs and probably no sc7[12]80 systems use DSI CMD panels.
Fixes: 667e9985ee24 ("drm/msm/dpu: replace IRQ lookup with the data in hw
catalog")
Memory for the "struct device" for any given device isn't supposed to
be released until the device's release() is called. This is important
because someone might be holding a kobject reference to the "struct
device" and might try to access one of its members even after any
other
During a frame transfer in command mode, there could be frequent
LP11 <-> HS transitions when multiple DCS commands are sent mid-frame or
if the DSI controller is running on slow clock and is throttled. To
minimize frame latency due to these transitions, it is recommended to
send the frame in a
' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Linus-Walleij/fbdev-media-Use-GPIO-descriptors-for-VIA-GPIO/20230612-214746
base: git://linuxtv.org/media_tree.git master
patch link:
https
The commit 007ac0262b0d ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE")
breaks panels which send DSI commands in their .unprepare callbacks.
Migrate to using .disable for that for some SDM845 panels.
Co-developed-by: Joel Selvaraj
Signed-off-by: Joel Selvaraj
Signed-off-by: Caleb Connolly
---
In order to read the EDID from an eDP panel, you not only need to
power on the bridge chip itself but also the panel. In the ps8640
driver, this was made to work by having the bridge chip manually power
the panel on by calling pre_enable() on everything connectorward on
the bridge chain. This
On 2023-06-12 21:25:34, Dmitry Baryshkov wrote:
> Add definitions of DSPP blocks present on the sdm845 platform. This
> should enable color-management on sdm845-bassed devices.
>
> Signed-off-by: Dmitry Baryshkov
And with this, the CTM property is back on SDM845 and functions as
intended: I am
On 2023-06-12 21:25:33, Dmitry Baryshkov wrote:
> We can not support color management without DSPP blocks being provided
> in the HW catalog. Do not enable color management for CRTCs if num_dspps
> is 0.
>
> Fixes: 4259ff7ae509 ("drm/msm/dpu: add support for pcc color block in dpu
> driver")
>
Hi Arnd,
On Mon, Jun 12, 2023 at 02:43:59PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When CONFIG_PNP is disabled, the mchbar_addr variable is only written but
> not read:
>
> drivers/gpu/drm/i915/soc/intel_gmch.c: In function
> 'intel_alloc_mchbar_resource':
>
On 13/06/2023 01:01, Bjorn Andersson wrote:
Using devres to depopulate the aux bus made sure that upon a probe
deferral the EDP panel device would be destroyed and recreated upon next
attempt.
But the struct device which the devres is tied to is the DPUs
(drm_dev->dev), which may be happen
FWIW: Should have a response to this very soon, figured out the cause of my
MST issues so I should be able to test this very soon
On Fri, 2023-06-09 at 18:49 +0800, Wayne Lin wrote:
> [Why]
> The sequence for collecting down_reply from source perspective should
> be:
>
> Request_n->repeat (get
On 13/06/2023 01:10, Bjorn Andersson wrote:
From: Bjorn Andersson
Some platforms provides a mechanism for configuring the mapping between
(one or two) DisplayPort intfs and their PHYs.
In particular SC8180X provides this functionality, without a default
configuration, resulting in no
' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Linus-Walleij/fbdev-media-Use-GPIO-descriptors-for-VIA-GPIO/20230612-214746
base: git://linuxtv.org/media_tree.git master
patch link:
https
From: Bjorn Andersson
Some platforms provides a mechanism for configuring the mapping between
(one or two) DisplayPort intfs and their PHYs.
In particular SC8180X provides this functionality, without a default
configuration, resulting in no connection between its two external
DisplayPort
The DP component's unbind operation walks through the submodules to
unregister and clean things up. But if the unbind happens because the DP
controller itself is being removed, all the memory for those submodules
has just been freed.
Change the order of these operations to avoid the many
Using devres to depopulate the aux bus made sure that upon a probe
deferral the EDP panel device would be destroyed and recreated upon next
attempt.
But the struct device which the devres is tied to is the DPUs
(drm_dev->dev), which may be happen after the DP controller is torn
down.
Indications
Hi,
On Mon, Jun 12, 2023 at 9:03 AM Maxime Ripard wrote:
>
> > > I guess we can have
> > > something much simpler with a bunch of helpers that would register a
> > > i2c-hid device and would be called by the panel driver itself.
> > >
> > > And then, since everything is self-contained managing
Hi everyone,
> Perhaps we should first think through what an ancillary device really
> is. My understanding is that it is used to talk to secondary addresses
> of a multi-address I2C slave device.
As I mentioned somewhere before, this is not the case. Ancillary devices
are when one *driver*
On 12/06/2023 22:35, Abhinav Kumar wrote:
On 6/12/2023 11:25 AM, Dmitry Baryshkov wrote:
Add definitions of DSPP blocks present on the sdm845 platform. This
should enable color-management on sdm845-bassed devices.
Signed-off-by: Dmitry Baryshkov
---
On 6/12/2023 11:25 AM, Dmitry Baryshkov wrote:
Add definitions of DSPP blocks present on the sdm845 platform. This
should enable color-management on sdm845-bassed devices.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 21 +++
1 file
The vga_is_firmware_default() function is arch-dependent, it's probably
wrong if we simply remove the arch guard. As the VRAM BAR which contains
firmware framebuffer may move, while the lfb_base and lfb_size members of
the screen_info does not change accordingly. In short, it should take the
From: Sui Jingfeng
Per Documentation/process/license-rules.rst, the SPDX MIT identifier is
equivalent to including the entire MIT license text from
LICENSES/preferred/MIT.
Replace the MIT license text with the equivalent SPDX identifier.
Signed-off-by: Sui Jingfeng
Reviewed-by: Andi Shyti
From: Sui Jingfeng
This patch replaces the leading space with a tab and removes the double
blank line, no functional change.
Signed-off-by: Sui Jingfeng
Reviewed-by: Andi Shyti
---
drivers/pci/vgaarb.c | 108 -
include/linux/vgaarb.h | 4 +-
2
From: Sui Jingfeng
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
device(pdev->class != 0x0300) out. There no need to process the non-display
PCI device.
Signed-off-by: Sui Jingfeng
---
From: Sui Jingfeng
The io_state variable in the vga_arb_write() function is declared with
unsigned int type, while the vga_str_to_iostate() function takes int *
type. To keep them consistent, replace the third argument of
vga_str_to_iostate() function with the unsigned int * type.
From: Sui Jingfeng
The vga_is_firmware_default() function is arch-dependent, it's probably
wrong if we simply remove the arch guard. As the VRAM BAR which contains
firmware framebuffer may move, while the lfb_base and lfb_size members of
the screen_info does not change accordingly. In short, it
On 2023-06-12 21:30:05, Dmitry Baryshkov wrote:
> On 12/06/2023 12:21, Marijn Suijten wrote:
> > On 2023-06-12 11:15:53, Marijn Suijten wrote:
> >> On 2023-06-12 06:16:16, Dmitry Baryshkov wrote:
> >>> CCF can try enabling VCO before the rate has been programmed. This can
> >>> cause clock lockups
Hi,
On 2023/5/8 11:09, Huacai Chen wrote:
LoongArch now provides kernel_fpu_begin() and kernel_fpu_end() that are
used like the x86 counterparts in commit 2b3bd32ea3a22ea2d ("LoongArch:
Provide kernel fpu functions"), so we can enable DC_FP on LoongArch for
supporting more DCN devices.
On 6/12/2023 11:25 AM, Dmitry Baryshkov wrote:
We can not support color management without DSPP blocks being provided
in the HW catalog. Do not enable color management for CRTCs if num_dspps
is 0.
Fixes: 4259ff7ae509 ("drm/msm/dpu: add support for pcc color block in dpu
driver")
On 12/06/2023 11:21, Thomas Zimmermann wrote:
Hi
Am 12.06.23 um 05:16 schrieb Dmitry Baryshkov:
Since commit 93e81e38e197 ("drm/fb_helper: Minimize damage-helper
overhead") the drm_fb_helper_funcs::fb_dirty helper is required for
proper dirty/damage processing. The drm/msm driver requires that
Title typo that I missed: implemenation -> implemen*T*ation :)
On 2023-06-12 11:14:41, Marijn Suijten wrote:
On 12/06/2023 13:48, Thomas Zimmermann wrote:
Hi
Am 12.06.23 um 11:14 schrieb Marijn Suijten:
On 2023-06-12 06:16:15, Dmitry Baryshkov wrote:
Since commit 93e81e38e197 ("drm/fb_helper: Minimize damage-helper
overhead") the drm_fb_helper_funcs::fb_dirty helper is required for
proper
Conor Dooley writes:
> On Mon, Jun 12, 2023 at 09:47:12AM +0200, Thomas Zimmermann wrote:
>> Am 11.06.23 um 01:18 schrieb Javier Martinez Canillas:
>
>> > But I will be OK to drop the "solomon,ssd130?fb-i2c" compatible strings
>> > from the DRM driver and only match against the new
On 12/06/2023 12:21, Marijn Suijten wrote:
On 2023-06-12 11:15:53, Marijn Suijten wrote:
On 2023-06-12 06:16:16, Dmitry Baryshkov wrote:
CCF can try enabling VCO before the rate has been programmed. This can
cause clock lockups and/or other boot issues. Program the VCO to the
minimal PLL rate
Add definitions of DSPP blocks present on the sdm845 platform. This
should enable color-management on sdm845-bassed devices.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 21 +++
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git
We can not support color management without DSPP blocks being provided
in the HW catalog. Do not enable color management for CRTCs if num_dspps
is 0.
Fixes: 4259ff7ae509 ("drm/msm/dpu: add support for pcc color block in dpu
driver")
Reported-by: Yongqin Liu
Signed-off-by: Dmitry Baryshkov
---
Change adreno_is_a690() prototype to accept the const struct adreno_gpu
pointer instead of a non-const one. This fixes the following warning:
In file included from drivers/gpu/drm/msm/msm_drv.c:33:
drivers/gpu/drm/msm/adreno/adreno_gpu.h: In function ‘adreno_is_a660_family’:
On 2023/6/13 02:15, Rob Herring wrote:
On Sun, Jun 11, 2023 at 12:49 AM Sui Jingfeng wrote:
Reviewed-by: Sui Jingfeng
On 2023/6/10 04:17, Rob Herring wrote:
On Mon, Apr 10, 2023 at 5:26 PM Rob Herring wrote:
Etnaviv doesn't use anything from of_platform.h, but depends on
of.h,
On Sun, Jun 11, 2023 at 12:49 AM Sui Jingfeng wrote:
>
> Reviewed-by: Sui Jingfeng
>
>
> On 2023/6/10 04:17, Rob Herring wrote:
> > On Mon, Apr 10, 2023 at 5:26 PM Rob Herring wrote:
> >> Etnaviv doesn't use anything from of_platform.h, but depends on
> >> of.h, of_device.h, and
On 2023-06-12 10:26:39, Abhinav Kumar wrote:
>
>
> On 6/11/2023 3:03 PM, Marijn Suijten wrote:
> > On 2023-06-09 15:57:18, Jessica Zhang wrote:
> >> Add documentation comments explaining the pclk_rate and hdisplay math
> >> related to DSC.
> >>
> >> Signed-off-by: Jessica Zhang
> >> ---
> >>
On Mon, Jun 12, 2023 at 09:47:12AM +0200, Thomas Zimmermann wrote:
> Am 11.06.23 um 01:18 schrieb Javier Martinez Canillas:
> > But I will be OK to drop the "solomon,ssd130?fb-i2c" compatible strings
> > from the DRM driver and only match against the new "solomon,ssd130?-i2c"
> > compatible
On 6/11/2023 3:03 PM, Marijn Suijten wrote:
On 2023-06-09 15:57:18, Jessica Zhang wrote:
Add documentation comments explaining the pclk_rate and hdisplay math
related to DSC.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 10 ++
1 file changed, 10
On 6/12/2023 5:21 AM, Pekka Paalanen wrote:
On Fri, 9 Jun 2023 19:11:25 -0400
Christopher Braga wrote:
On 6/9/2023 12:30 PM, Simon Ser wrote:
Hi Christopher,
On Friday, June 9th, 2023 at 17:52, Christopher Braga
wrote:
The new COLOROP objects also expose a number of KMS
Hello,
avkras...@sberdevices.ru wrote on Tue, 23 May 2023 13:16:34 +0300:
> This adds support for OTP area access on MX30LFxG18AC chip series.
Jaime, any feedback on this? Will you test it?
How are we supposed to test the OTP is locked? I see this is still an
open point.
>
> Signed-off-by:
On 12.06.2023 17:26, Neil Armstrong wrote:
> "low" was written "lov", fix this.
>
> Fixes: 99d33ee61cb0 ("arm64: dts: qcom: sm8550: Add missing RPMhPD OPP
> levels")
> Signed-off-by: Neil Armstrong
> ---
https://lore.kernel.org/linux-arm-msm/1d3c05f5-c1bd-6844-1788-8df0b863a...@linaro.org/
On Mon, 12 Jun 2023 16:59:02 +0200
Boris Brezillon wrote:
> Hi Christian,
>
> On Mon, 12 Jun 2023 15:16:03 +0200
> Christian König wrote:
>
> > Am 08.06.23 um 15:23 schrieb Donald Robson:
> > > This patch adds support for 'native' dependencies to DRM scheduler. In
> > > drivers that use a
Sam Ravnborg writes:
Hello Sam,
> Hi Thomas,
>
> Nice series, quite some preparations.
>
> On Mon, Jun 12, 2023 at 04:07:38PM +0200, Thomas Zimmermann wrote:
[...]
>> fbdev/smscufx: Detect registered fb_info from refcount
> I did not try to understand the code, so others must review.
>
No
Hi Doug,
On Thu, Jun 08, 2023 at 07:38:58AM -0700, Doug Anderson wrote:
> On Thu, Jun 8, 2023 at 12:17 AM Maxime Ripard wrote:
> >
> > Hi Douglas,
> >
> > On Wed, Jun 07, 2023 at 02:49:22PM -0700, Douglas Anderson wrote:
> > >
> > > The big motivation for this patch series is mostly described in
Hi Thomas,
Nice series, quite some preparations.
On Mon, Jun 12, 2023 at 04:07:38PM +0200, Thomas Zimmermann wrote:
> Add the new config option FB_DEVICE. If enabled, fbdev provides
> traditional userspace interfaces in devfs, sysfs and procfs, such
> as /dev/fb0 or /proc/fb.
>
> Modern Linux
Hi Thomas,
On Mon, Jun 12, 2023 at 04:07:59PM +0200, Thomas Zimmermann wrote:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the cleanup calls for both data
> structures. The init calls are already in the correct order.
>
> Signed-off-by: Thomas
On Mon, Jun 12, 2023 at 04:08:12PM +0200, Thomas Zimmermann wrote:
> Move the logic to create and destroy fbdev devices into the new
> helpers fb_device_create() and fb_device_destroy().
>
> There was a call to fb_cleanup_device() in do_unregister_framebuffer()
> that was too late. The device had
[Public]
> -Original Message-
> From: Kuehling, Felix
> Sent: Monday, June 12, 2023 11:25 AM
> To: Lu Hongfei ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; open list:AMD
> KFD ; open list:DRM DRIVERS de...@lists.freedesktop.org>; open list
1 - 100 of 258 matches
Mail list logo
