Hi Dmitry,
On 30/04/24 15:45, Dmitry Baryshkov wrote:
On Tue, Apr 30, 2024 at 02:41:21PM +0530, Vignesh Raman wrote:
Now the testlist is used from IGT build, so update
xfails with the new testlist.
Signed-off-by: Vignesh Raman
---
.../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 47 +++--
Hi Helen,
On 30/04/24 20:01, Helen Koike wrote:
On 30/04/2024 06:11, Vignesh Raman wrote:
Skip driver specific tests and skip kms tests for
panfrost driver since it is not a kms driver.
Signed-off-by: Vignesh Raman
---
.../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 14 +-
Hi Dmitry,
On 30/04/24 15:47, Dmitry Baryshkov wrote:
On Tue, Apr 30, 2024 at 02:41:18PM +0530, Vignesh Raman wrote:
Stop vendoring the testlist into the kernel. Instead, use the
testlist from the IGT build to ensure we do not miss renamed
or newly added tests.
Signed-off-by: Vignesh Raman
--
On 06.05.24 16:30, David Wang wrote:
>> On 30.04.24 08:13, David Wang wrote:
>> And confirmed that the warning is caused by
>> 07ed11afb68d94eadd4ffc082b97c2331307c5ea and reverting it can fix.
>
> The kernel warning still shows up in 6.9.0-rc7.
> (I think 4 high load processes on a 2-Core VM c
Found some files in Staging Drivers for which checkpatch.pl throws a CHECK to
+remove CamelCase.
For instance in program vt6655/card.c find the usage of CamelCase as
i) Variable names eg: &priv->apTD0Rings[0]
ii) Function names eg: void CARDvSafeResetRx(
Note: some of the functions are
+static fu
Both virtio_gpu_queue_ctrl_buffer and virtio_gpu_queue_cursor use
virtqueue_add_sgs to upload the structure virtio_gpu_vbuffer * vbuf
to virtqueue. However, when the vbuf fails to upload and virtqueue_add_sgs
returns -EIO or -ENOMEM, the vbuf will not be able to be free by
virtio_gpu_dequeue_*_func
Hi Maxime,
On 5/6/24 15:59, Maxime Ripard wrote:
Hi Andy,
Thanks a lot for giving it a try
All the issues you raised in your review are fixed.
On Sat, Apr 27, 2024 at 06:44:54PM GMT, Andy Yan wrote:
And after this whole series applied on linux 6.9-rc4, the display on rk3036
kylin is lost, I
On Mon, May 06, 2024 at 03:04:15PM +0200, Daniel Vetter wrote:
> On Sat, May 04, 2024 at 11:03:03AM +1000, Dave Airlie wrote:
> > > Let me know if this understanding is correct.
> > >
> > > Or what would you like to do in such situation?
> > >
> > > >
> > > > Not sure how it is really a good idea.
On Thu, May 02, 2024 at 03:33:50PM +0100, Tvrtko Ursulin wrote:
>
> Hi all,
>
> Continuing after the brief IRC discussion yesterday regarding work queues
> being prone to deadlocks or not, I had a browse around the code base and
> ended up a bit confused.
>
> When drm_sched_init documents and al
No more direct use of VMWARE_HYPERCALL macro should be allowed.
Signed-off-by: Alexey Makhalov
---
arch/x86/include/asm/vmware.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index 2ac87068184a..84a31f579a30 100644
--- a/arch/x8
VMware hypercalls use I/O port, VMCALL or VMMCALL instructions.
Add __tdx_hypercall path to support TDX guests.
No change in high bandwidth hypercalls, as only low bandwidth
ones are supported for TDX guests.
Co-developed-by: Tim Merrifield
Signed-off-by: Tim Merrifield
Signed-off-by: Alexey Ma
Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
Eliminate arch specific code.
drivers/gpu/drm/vmwgfx/vmwgfx_msg_arm64.h: implement arm64 variant
of vmware_hypercall. And keep it here until introduction of ARM64
VMWare hypervisor interface.
Signed-off-by: Alexey Makhalov
Reviewed-by:
Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
Eliminate arch specific code. No functional changes intended.
Signed-off-by: Alexey Makhalov
Reviewed-by: Nadav Amit
Reviewed-by: Zack Rusin
Acked-by: Dmitry Torokhov
---
drivers/input/mouse/vmmouse.c | 78 ++-
Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
Eliminate arch specific code. No functional changes intended.
Signed-off-by: Alexey Makhalov
Reviewed-by: Nadav Amit
Reviewed-by: Jeff Sipek
---
drivers/ptp/ptp_vmw.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(
Introduce vmware_hypercall family of functions. It is a common
implementation to be used by the VMware guest code and virtual
device drivers in architecture independent manner.
The API consists of vmware_hypercallX and vmware_hypercall_hb_{out,in}
set of functions by analogy with KVM hypercall API
Move VMware hypercall macros to vmware.h. This is a prerequisite for
the introduction of vmware_hypercall API. No functional changes besides
exporting vmware_hypercall_mode symbol.
Signed-off-by: Alexey Makhalov
Reviewed-by: Nadav Amit
---
arch/x86/include/asm/vmware.h | 72
VCPU_RESERVED and LEGACY_X2APIC are not VMware hypercall commands.
These are bits in return value of VMWARE_CMD_GETVCPU_INFO command.
Change VMWARE_CMD_ prefix to GETVCPU_INFO_ one. And move bit-shift
operation to the macro body.
Signed-off-by: Alexey Makhalov
---
arch/x86/kernel/cpu/vmware.c |
VMware hypercalls invocations were all spread out across the kernel
implementing same ABI as in-place asm-inline. With encrypted memory
and confidential computing it became harder to maintain every changes
in these hypercall implementations.
Intention of this patchset is to introduce arch independ
The DSI controller needs this clock to be enabled in order to be able to
access the registers. Make it critical for that purpose.
Signed-off-by: Alex Bee
---
drivers/clk/rockchip/clk-rk3128.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/rockchip/clk-rk3128.c
b/drivers/clk/roc
The InnoSilicon DPHY found in RK3128 SoCs supports DSI/LVDS/TTL with a
maximum transfer rate of 1 Gbps per lane. While at it also add the newly
exported PCLK_MIPIPHY clock id to RK3128_PD_VIO powerdomain as the phy is
part of it.
Signed-off-by: Alex Bee
---
arch/arm/boot/dts/rockchip/rk3128.dtsi
Add the Designware MIPI DSI controller and it's port nodes.
Signed-off-by: Alex Bee
---
arch/arm/boot/dts/rockchip/rk3128.dtsi | 36 ++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi
b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index d1
The DesignWare MIPI DSI controller found RK3128 SoCs supports up to 4 dsi
data lanes. Similar to PX30/RK356x/RV1126 it uses an external DPHY.
Signed-off-by: Alex Bee
---
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 20 +++
1 file changed, 20 insertions(+)
diff --git a/drivers
Document the MIPI DSI controller for Rockchip RK3128. The integration is
similar to PX30 so it's bindings-constraints can be re-used.
Signed-off-by: Alex Bee
---
.../bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documentation/d
The DPHY driver requires to specify a pclk so it gets exported here. I also
dropped the CLK_IGNORE_UNUSED-flag as we will enable the clock on demand.
Signed-off-by: Alex Bee
---
drivers/clk/rockchip/clk-rk3128.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rock
The DPHY's APB clock is required to be exposed in order to be able to
enable it and access the phy's registers.
Signed-off-by: Alex Bee
---
include/dt-bindings/clock/rk3128-cru.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dt-bindings/clock/rk3128-cru.h
b/include/dt-bindings/clo
This series aims to add support for the DesignWare MIPI DSI controller and
the Innoslicon DPHY found in RK3128 SoCs. The code additions are rather
tiny: It only need some code in the Rockchip dw-mipi-dsi glue layer for
this SoC and some changes in the clock driver. Support for the DPHY has
already
On Mon, May 6, 2024 at 2:30 AM Charan Teja Kalla
wrote:
>
> Hi TJ,
>
> Seems I have got answers from [1], where it is agreed upon epoll() is
> the source of issue.
>
> Thanks a lot for the discussion.
>
> [1] https://lore.kernel.org/lkml/2d631f0615918...@google.com/
>
> Thanks
> Charan
On 5/6/2024 8:02 PM, Janusz Krzysztofik wrote:
This reverts commit 1f33dc0c1189efb9ae19c6fc22b64dd3e26261fb.
There was a patch supposed to fix an issue of illegal attempts to free a
still active i915 VMA object when parking a GT believed to be idle,
reported by CI on 2-GT Meteor Lake. As a sol
On Mon, 6 May 2024 at 10:46, Stefan Metzmacher wrote:
>
> I think it's a very important detail that epoll does not take
> real references. Otherwise an application level 'close()' on a socket
> would not trigger a tcp disconnect, when an fd is still registered with
> epoll.
Yes, exactly.
epoll()
This reverts commit 1f33dc0c1189efb9ae19c6fc22b64dd3e26261fb.
There was a patch supposed to fix an issue of illegal attempts to free a
still active i915 VMA object when parking a GT believed to be idle,
reported by CI on 2-GT Meteor Lake. As a solution, an extra wakeref for
a Primary GT was acqui
On Mon, May 06, 2024 at 10:57:17AM -0400, Sean Anderson wrote:
> On 5/6/24 03:35, Laurent Pinchart wrote:
> > On Mon, May 06, 2024 at 09:29:36AM +0200, Maxime Ripard wrote:
> >> Hi Laurent, Sean,
> >>
> >> On Sat, May 04, 2024 at 03:21:18PM GMT, Laurent Pinchart wrote:
> >> > On Fri, May 03, 2024
Am Freitag, 3. Mai 2024, 23:33:12 CEST schrieb Douglas Anderson:
> It's the responsibility of a correctly written DRM modeset driver to
> call drm_atomic_helper_shutdown() at shutdown time and that should be
> disabling / unpreparing the panel if needed. Panel drivers shouldn't
> be calling these f
Am Freitag, 3. Mai 2024, 23:33:11 CEST schrieb Douglas Anderson:
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if
Am Freitag, 3. Mai 2024, 23:32:58 CEST schrieb Douglas Anderson:
> It's the responsibility of a correctly written DRM modeset driver to
> call drm_atomic_helper_shutdown() at shutdown time and that should be
> disabling / unpreparing the panel if needed. Panel drivers shouldn't
> be calling these f
Am Freitag, 3. Mai 2024, 23:32:57 CEST schrieb Douglas Anderson:
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if
Am Freitag, 3. Mai 2024, 23:32:54 CEST schrieb Douglas Anderson:
> It's the responsibility of a correctly written DRM modeset driver to
> call drm_atomic_helper_shutdown() at shutdown time and that should be
> disabling / unpreparing the panel if needed. Panel drivers shouldn't
> be calling these f
Am Freitag, 3. Mai 2024, 23:32:53 CEST schrieb Douglas Anderson:
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if
Am Freitag, 3. Mai 2024, 23:32:50 CEST schrieb Douglas Anderson:
> It's the responsibility of a correctly written DRM modeset driver to
> call drm_atomic_helper_shutdown() at shutdown time and that should be
> disabling / unpreparing the panel if needed. Panel drivers shouldn't
> be calling these f
Am Freitag, 3. Mai 2024, 23:32:49 CEST schrieb Douglas Anderson:
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if
Am Freitag, 3. Mai 2024, 23:32:55 CEST schrieb Douglas Anderson:
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if
Am Freitag, 3. Mai 2024, 23:32:56 CEST schrieb Douglas Anderson:
> It's the responsibility of a correctly written DRM modeset driver to
> call drm_atomic_helper_shutdown() at shutdown time and that should be
> disabling / unpreparing the panel if needed. Panel drivers shouldn't
> be calling these f
Am 05.05.24 um 22:53 schrieb Linus Torvalds:
On Sun, 5 May 2024 at 13:30, Al Viro wrote:
0. special-cased ->f_count rule for ->poll() is a wart and it's
better to get rid of it.
1. fs/eventpoll.c is a steaming pile of shit and I'd be glad to see
git rm taken to it. Short of that, by
Hi,
On Thu, May 2, 2024 at 4:55 PM Hsin-Yi Wang wrote:
>
> On Thu, May 2, 2024 at 4:48 PM Douglas Anderson wrote:
> >
> > As evidenced by in-field reports, this panel shipped on pompom but we
> > never added the ID and thus we're stuck w/ conservative timings. The
> > panel was part of early pat
Hi,
On Tue, Apr 23, 2024 at 6:55 PM Xuxin Xiong
wrote:
>
> Hi Doug, thank you!
> We had reported this info to the CSOT to correct the vendor id.
> If they confirm to fix this with the same product ID, we will submit a
> patch to fix this.
FYI, "top posting" like this is generally frowned upon on
On 5/3/2024 3:13 PM, Jakub Kicinski wrote:
> On Tue, 30 Apr 2024 17:38:09 + Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix the
Hi Janusz,
On 4/16/2024 6:40 PM, Rodrigo Vivi wrote:
On Tue, Apr 16, 2024 at 10:09:46AM +0200, Janusz Krzysztofik wrote:
Hi Rodrigo,
On Tuesday, 16 April 2024 03:16:31 CEST Rodrigo Vivi wrote:
On Mon, Apr 15, 2024 at 09:53:09PM +0200, Janusz Krzysztofik wrote:
We defer actually closing, unbi
Hi,
On Mon, May 6, 2024 at 7:04 AM Quentin Schulz wrote:
>
> Hi Douglas,
>
> On 5/3/24 11:32 PM, Douglas Anderson wrote:
> > [You don't often get email from diand...@chromium.org. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > It's the responsibility o
On Mon, May 6, 2024, at 16:53, Arnd Bergmann wrote:
> On Mon, May 6, 2024, at 15:14, Daniel Vetter wrote:
>>
>> This one is. And it doesn't need to be simpledrm, just a drm kms driver
>> with fbdev emulation. Heck even if you have an fbdev driver you should
>> control the corresponding backlight ex
On 5/6/24 03:35, Laurent Pinchart wrote:
> On Mon, May 06, 2024 at 09:29:36AM +0200, Maxime Ripard wrote:
>> Hi Laurent, Sean,
>>
>> On Sat, May 04, 2024 at 03:21:18PM GMT, Laurent Pinchart wrote:
>> > On Fri, May 03, 2024 at 05:54:32PM -0400, Sean Anderson wrote:
>> > > I have discovered a bug in
On Mon, May 6, 2024, at 15:14, Daniel Vetter wrote:
> On Fri, May 03, 2024 at 01:22:10PM -0700, Florian Fainelli wrote:
>> On 5/3/24 12:45, Arnd Bergmann wrote:
>> > On Fri, May 3, 2024, at 21:28, Florian Fainelli wrote:
>> > > Android devices in recovery mode make use of a framebuffer device to
>>
On Mon, May 06, 2024 at 02:47:23PM +0200, Daniel Vetter wrote:
> On Sun, May 05, 2024 at 01:53:48PM -0700, Linus Torvalds wrote:
> > On Sun, 5 May 2024 at 13:30, Al Viro wrote:
> > >
> > > 0. special-cased ->f_count rule for ->poll() is a wart and it's
> > > better to get rid of it.
> > >
> >
On 5/6/24 07:16, Tomi Valkeinen wrote:
> Hi,
>
> On 04/05/2024 00:54, Sean Anderson wrote:
>> Hi,
>>
>> I have discovered a bug in the displayport driver on drm-misc-next. To
>> trigger it, run
>>
>> echo fd4a.display > /sys/bus/platform/drivers/zynqmp-dpsub/unbind
>>
>> The system will become
The kernel warning still shows up in 6.9.0-rc7.
(I think 4 high load processes on a 2-Core VM could easily trigger the kernel
warning.)
Thanks
David
Am 04.05.24 um 20:20 schrieb Linus Torvalds:
On Sat, 4 May 2024 at 08:32, Linus Torvalds
wrote:
Lookie here, the fundamental issue is that epoll can call '->poll()'
on a file descriptor that is being closed concurrently.
Thinking some more about this, and replying to myself...
Actually, I won
On Mon, May 06, 2024 at 11:27:04AM +0200, Christian Brauner wrote:
> On Mon, May 06, 2024 at 10:45:35AM +0200, Christian Brauner wrote:
> > > The fact is, it's not dma-buf that is violating any rules. It's epoll.
> >
> > I agree that epoll() not taking a reference on the file is at least
> > unexp
Il 06/05/24 15:17, Michael Walle ha scritto:
Hi Angelo,
On Mon May 6, 2024 at 1:22 PM CEST, AngeloGioacchino Del Regno wrote:
The problem with this is that you need DDP_COMPONENT_DRM_OVL_ADAPTOR... which is
a software thing and not HW, so that can't be described in devicetree.
The only thing t
Hi Sima,
On 5/6/24 3:38 PM, Daniel Vetter wrote:
> On Mon, May 06, 2024 at 02:05:12PM +0200, Maxime Ripard wrote:
>> Hi,
>>
>> On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de Goede wrote:
>>> Hi dma-buf maintainers, et.al.,
>>>
>>> Various people have been working on making complex/MIPI cameras wo
Problem statement: During the system boot time, an application request
for the bulk volume of cleared range bias memory when the clear_avail
is zero, we dont fallback into normal allocation method as we had an
unnecessary clear_avail check which prevents the fallback method leads
to fb allocation f
On Mon, May 06, 2024 at 02:05:12PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de Goede wrote:
> > Hi dma-buf maintainers, et.al.,
> >
> > Various people have been working on making complex/MIPI cameras work OOTB
> > with mainline Linux kernels and an openso
Use the device resource managed version of drm_bridge_add(). This
simplifies the error handling and we can get rid of tc_remove_bridge().
Also, add a check for the return code.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 21 -
1 file changed, 4 insert
The reset line of this bridge must be released while the DSI data lanes
and DSI clock lane are in LP-11 mode. After that the DSI clock has to be
turned on, which is a requirement to have I2C work.
To achieve this, use the new .lp11_notify() callback where the reset
line is released. Set .pre_enabl
Implement the delays according to Figure 8-10 and 8-11 of the datasheet.
In particular, the datasheet states that the *maximum* time between
enabling the VDDIO and VDD is 10ms. Currently, as implemented this is
always violated. Of course, this is only a best effort because we cannot
be sure enablin
Move the bridge power-up and power-down handling into own functions.
This is a preparation patch to fix the power-up sequencing of the
bridge. No functional change.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 21 +
1 file changed, 17 insertions(+), 4
Provide bitfield macros for the individual fields in the LVDS timing
registers and get rid of the magic values.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 52 +--
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/drivers
Instead of hardcoding the settings for just one (unknown) particular
frequency and lane setting, compute the DSI link parameters using the
handy phy_mipi_dphy_get_default_config() helper function.
The DSI_START and DSI_BUSY registers were removed in version 0.6 of the
datasheet. It seems that it a
The PLL setting was hardcoded to a LVDS clock between 60MHz and 135MHz.
This adds support for slower frequencies. Also, rework the reset
sequence to match the initialization sequence provided by the vendor.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 50 +
Split the initialization code in tc_bridge_enable() into specific
functions. This is a preparation for further code cleanup and fixes.
No functional change.
While at it, rename tc_bridge_enable() to the more specific
tc358775_bridge_enable().
Signed-off-by: Michael Walle
---
drivers/gpu/drm/br
The driver assumes a DSI link with four lanes for now and has the LVDS
clock divider hardcoded to either 3 or 6. Take the number of lanes into
account, too. Also, explicitly set the clock source to the DSI clock.
While at it, replace the TC358775_LVCFG_PCLKDIV() and
TC358775_LVCFG_LVDLINK() inline
Reformat the indentation of the mipi_dsi_device_info initialization.
While at it, move it to the top of the function.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
The LVDS link can either be a single link or a dual link. No need for a
u8. Replace it with a bool "lvds_dual_link".
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc3587
To cite the datasheet on VSDELAY:
During DSI link speed is slower than that of LVDS link’s, data needs
to be buffer within 775XBG before outputting to prevent data from
underflow. Register field VPCTRL[VSDELAY] is used to for this purpose
This driver assumes that the DSI link speed is the pi
A missing regulator node will automatically be replaced by a dummy. Thus
regulators are optional anyway. Remove the error message.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/dr
The DSI bridge also supports access via DSI in-band reads and writes.
Prepare the driver for that by converting all the access functions to
regmap. This also have the advantage that it will make tracing and
debugging easier and we can use all the bit manipulation helpers from
regmap.
Signed-off-by
Drop the FLD_VAL macro, just use bit shifts. This is a preparation patch
to switch to regmap and to remove the FLD_VAL().
While at it, reformat the LV_x enum.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 36 ++--
1 file changed, 6 insertio
The bridge has some limitations regarding the horizontal display
timings. In particular, the pulse width has to be at least 8 pixels
and all horizontal timings have to be a multiple of two pixels, except
for the front porch which is ignored by the bridge anyway.
To accommodate that, add pixels to
The regulator id is given without the "-supply" postfix. With that
fixed, the driver will look up the correct regulator from the device
tree.
Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 4 ++--
1 file c
drm_bridge_dsi_lp11_notify() shall be called while both the clock and
data lanes are still in LP-11 mode. Add the callback.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/dr
, 283 deletions(-)
---
base-commit: 9221b2819b8a4196eecf5476d66201be60fbcf29
change-id: 20240506-tc358775-fix-powerup-53f490043179
As per specification in drivers/gpu/drm/drm_bridge.c the data lanes
should be in LP-11 mode after .pre_enable() has been run. HS mode of the
data lanes are enabled with mtk_dsi_start(). Therefore, move that call
to the .enable() callback.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/mediatek
Some bridges have very strict power-up reqirements. In this case, the
Toshiba TC358775. The reset has to be deasserted while *both* the DSI
clock and DSI data lanes are in LP-11 mode. After the reset is relased,
the bridge needs the DSI clock to actually be able to process I2C
access. This access w
On Fri, May 03, 2024 at 08:29:39PM +, Zeng, Oak wrote:
> > > But we have use case where we want to fault-in pages other than the
> > > page which contains the GPU fault address, e.g., user malloc'ed or
> > > mmap'ed 8MiB buffer, and no CPU touching of this buffer before GPU
> > > access it. Le
Hello dri maintainers/developers,
This is a 31-day syzbot report for the dri subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/dri
During the period, 0 new issues were detected and 0 were fixed.
In total, 16 issues are still open and 31 have been
Hi Angelo,
On Mon May 6, 2024 at 1:22 PM CEST, AngeloGioacchino Del Regno wrote:
> > The problem with this is that you need DDP_COMPONENT_DRM_OVL_ADAPTOR...
> > which is
> > a software thing and not HW, so that can't be described in devicetree.
> >
> > The only thing this series won't deal with
On Fri, May 03, 2024 at 01:22:10PM -0700, Florian Fainelli wrote:
> On 5/3/24 12:45, Arnd Bergmann wrote:
> > On Fri, May 3, 2024, at 21:28, Florian Fainelli wrote:
> > > Android devices in recovery mode make use of a framebuffer device to
> > > provide an user interface. In a GKI configuration tha
On Sat, May 04, 2024 at 11:03:03AM +1000, Dave Airlie wrote:
> > Let me know if this understanding is correct.
> >
> > Or what would you like to do in such situation?
> >
> > >
> > > Not sure how it is really a good idea.
> > >
> > > Adaptive locality of memory is still an unsolved problem in Linux
On Fri, May 03, 2024 at 10:46:40PM -0400, Zack Rusin wrote:
> On Fri, May 3, 2024 at 6:29 PM Ian Forbes wrote:
> >
> > This function was removed in the referenced fixes commit and caused a
> > regression. This is because the presence of this function, even though it
> > is a noop, changes the beha
Il 06/05/24 11:11, Michael Walle ha scritto:
Hi Angelo,
On Tue Apr 9, 2024 at 2:02 PM CEST, AngeloGioacchino Del Regno wrote:
+static int mtk_drm_of_get_ddp_ep_cid(struct device_node *node,
+int output_port, enum mtk_drm_crtc_path
crtc_path,
Not sure what'
On Fri, May 03, 2024 at 06:06:03PM +0100, Tvrtko Ursulin wrote:
>
> On 03/05/2024 16:58, Alex Deucher wrote:
> > On Fri, May 3, 2024 at 11:33 AM Daniel Vetter wrote:
> > >
> > > On Fri, May 03, 2024 at 01:58:38PM +0100, Tvrtko Ursulin wrote:
> > > >
> > > > [And I forgot dri-devel.. doing well!
On Sun, May 05, 2024 at 01:53:48PM -0700, Linus Torvalds wrote:
> On Sun, 5 May 2024 at 13:30, Al Viro wrote:
> >
> > 0. special-cased ->f_count rule for ->poll() is a wart and it's
> > better to get rid of it.
> >
> > 1. fs/eventpoll.c is a steaming pile of shit and I'd be glad to see
>
On Fri, May 03, 2024 at 04:41:19PM -0700, Linus Torvalds wrote:
> On Fri, 3 May 2024 at 16:23, Kees Cook wrote:
> >
> > static bool __must_check get_dma_buf_unless_doomed(struct dma_buf *dmabuf)
> > {
> > return atomic_long_inc_not_zero(&dmabuf->file->f_count) != 0L;
> > }
> >
> > If we en
On Fri, May 03, 2024 at 10:53:03PM +0100, Al Viro wrote:
> On Fri, May 03, 2024 at 02:42:22PM -0700, Linus Torvalds wrote:
> > On Fri, 3 May 2024 at 14:36, Al Viro wrote:
> > >
> > > ... the last part is no-go - poll_wait() must be able to grab a reference
> > > (well, the callback in it must)
> >
On Thu, May 2, 2024 at 11:03 AM Hsin-Te Yuan wrote:
>
> For some SoCs, the TDM setting is not to shift the first audio data bit,
> which is not the default setting of anx7625. In such cases, the TDM
> setting should be changed according to the device tree property.
>
> Signed-off-by: Hsin-Te Yuan
Hi Maxime,
On 5/6/24 2:05 PM, Maxime Ripard wrote:
> Hi,
>
> On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de Goede wrote:
>> Hi dma-buf maintainers, et.al.,
>>
>> Various people have been working on making complex/MIPI cameras work OOTB
>> with mainline Linux kernels and an opensource userspace s
Hi,
On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de Goede wrote:
> Hi dma-buf maintainers, et.al.,
>
> Various people have been working on making complex/MIPI cameras work OOTB
> with mainline Linux kernels and an opensource userspace stack.
>
> The generic solution adds a software ISP (for Deba
Hi dma-buf maintainers, et.al.,
Various people have been working on making complex/MIPI cameras work OOTB
with mainline Linux kernels and an opensource userspace stack.
The generic solution adds a software ISP (for Debayering and 3A) to
libcamera. Libcamera's API guarantees that buffers handed to
Il 06/05/24 12:56, AngeloGioacchino Del Regno ha scritto:
Il 06/05/24 12:02, Michael Walle ha scritto:
Hi Angelo,
On Tue Apr 30, 2024 at 1:33 PM CEST, AngeloGioacchino Del Regno wrote:
This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
NIO-12L with both hardcoded paths, OF grap
Hi,
On 04/05/2024 00:54, Sean Anderson wrote:
Hi,
I have discovered a bug in the displayport driver on drm-misc-next. To
trigger it, run
echo fd4a.display > /sys/bus/platform/drivers/zynqmp-dpsub/unbind
The system will become unresponsive and (after a bit) splat with a hard
LOCKUP. One co
Il 06/05/24 12:02, Michael Walle ha scritto:
Hi Angelo,
On Tue Apr 30, 2024 at 1:33 PM CEST, AngeloGioacchino Del Regno wrote:
This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
NIO-12L with both hardcoded paths, OF graph support and partially
hardcoded paths (meaning main displ
1 - 100 of 124 matches
Mail list logo
