On Fri, 03 May 2024, Rodrigo Vivi wrote:
> On Fri, May 03, 2024 at 02:04:15PM -0700, Easwar Hariharan wrote:
>> On 5/3/2024 12:34 PM, Rodrigo Vivi wrote:
>> > On Fri, May 03, 2024 at 06:13:24PM +, Easwar Hariharan wrote:
>> >> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced
>>
Hi,
On Sat, Apr 27, 2024 at 06:12:26PM GMT, Andy Yan wrote:
> On 4/23/24 18:45, Maxime Ripard wrote:
> > The new HDMI connector infrastructure allows to remove some boilerplate,
> > especially to generate infoframes. Let's switch to it.
> >
> > Reviewed-by: Heiko Stuebner
> > Acked-by: Heiko
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 get
> the following error:
> [ 178.999421]
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,
> 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
unexpected and contradicts the usual code patterns for the sake of
performance and that it very likely is the case that most callers of
f_op->poll() don't
On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
> The current mipi_dsi_*_write_seq() macros are non-intutitive because
> they contain a hidden "return" statement that will return out of the
> _caller_ of the macro. Let's mark them as deprecated and instead
> introduce some new macros that
On Mon, Apr 29, 2024 at 4:26 PM Doug Anderson wrote:
> So I guess I'd say that I ended up being pretty happy with the
> "context" even if it does feel a little over engineered and I'd argue
> to keep it that way. That being said, if you feel strongly about it
> then we can perhaps get others to
On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
> Consensus on the mailing lists is that panels shouldn't use a table of
> init commands but should instead use init functions. We'll use the
> same concepts as the recently introduced
> mipi_dsi_generic_write_seq_multi() to make this
-Original Message-
From: Robert Foss
Sent: Tuesday, April 23, 2024 9:50 PM
To: Kuro Chung (鐘仕廷)
Cc: Allen Chen ; Pin-yen Lin ;
Kenneth Hung (洪家倫) ; Kuro Chung
; Andrzej Hajda
; Neil Armstrong ; Laurent
Pinchart ; Jonas Karlman ;
Jernej Skrabec ; Maarten Lankhorst
; Maxime Ripard
On Fri, May 3, 2024 at 11:36 PM Douglas Anderson wrote:
> 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
On Fri, 03. May 14:08, Dmitry Antipov wrote:
> On 5/3/24 11:18 AM, Christian König wrote:
>
> > Attached is a compile only tested patch, please verify if it fixes your
> > problem.
>
> LGTM, and this is similar to get_file() in __pollwait() and fput() in
> free_poll_entry() used in
On Mon, May 06, 2024 at 08:52:39AM GMT, Linus Walleij wrote:
> On Fri, May 3, 2024 at 11:36 PM Douglas Anderson
> wrote:
>
> > 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
On Fri, 3 May 2024 14:32:41 -0700, Douglas Anderson wrote:
>
> 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
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 the displayport driver on drm-misc-next. To
>
On Thu, Apr 18, 2024 at 10:55:39PM +0200, Heiner Kallweit wrote:
> 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
> instantiation") removed the last call to i2c_mux_add_adapter() with a
> non-null class argument. Therefore the class argument can be removed.
>
> Note:
Hi Heiko,
On 4/25/24 9:55 PM, Heiko Stuebner wrote:
From: Heiko Stuebner
The rk3588 VOP2 has 4 video-ports, yet the driver currently only
configures the first 3, as used on the rk3568.
I'm wondering whether we should update the drawing at the top of the
driver then?
Add another block
Hi everyone,
I've tried to debug this syzkaller's bug report
Here is my minimized proof-of-concept
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define err_msg(msg) do {perror(msg); exit(1);} while(0)
void *close_thread(void
Hi Heiko,
On 4/25/24 9:55 PM, Heiko Stuebner wrote:
From: Heiko Stuebner
The clock is in Hz while the value checked against is in kHz, so
actual frequencies will never be able to be below to max value.
Fix this by specifying the max-value in Hz too.
Fixes: 5a028e8f062f ("drm/rockchip: vop2:
enabled at (263164): release_sock
(net/core/sock.c:3560)
[ 2.725080][ T1] softirqs last disabled at (263162): release_sock
(net/core/sock.c:3549)
[2.726210][T1] ---[ end trace ]---
The kernel config and materials to reproduce are available at:
https://d
On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
> Consensus on the mailing lists is that panels shouldn't use a table of
> init commands but should instead use init functions. With the recently
> introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
> but also saves space.
On Fri, May 3, 2024 at 11:38 PM Douglas Anderson wrote:
> 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
On Fri, May 3, 2024 at 11:38 PM Douglas Anderson wrote:
> 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
On Fri, May 3, 2024 at 11:38 PM Douglas Anderson wrote:
> 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
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 the displayport driver on drm-misc-next. To
> > trigger it, run
> >
> > echo fd4a.display >
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's your base branch is, but "enum
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
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
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.
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
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
---
deletions(-)
---
base-commit: 9221b2819b8a4196eecf5476d66201be60fbcf29
change-id: 20240506-tc358775-fix-powerup-53f490043179
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
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
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
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
Hi,
On Fri, May 03, 2024 at 03:34:12PM -0400, Rodrigo Vivi wrote:
> On Fri, May 03, 2024 at 06:13:24PM +, 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
> >
Hi Christian, Others.
In order to support exhaustive eviction there are some changes that I
think needs to be made to drm_exec:
1) Trylock support
(This is for ttm_bo_vm, ttm_buffer_object_init_reserved, and also for
the eviction path where I think we want to make a trylock pass before a
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
Am 03.05.24 um 20:13 schrieb Easwar Hariharan:
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 terminology for users of
I2C_ALGOBIT bitbanging interface,
Am 03.05.24 um 20:13 schrieb Easwar Hariharan:
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 terminology for users of
I2C_ALGOBIT bitbanging interface,
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
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
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/5/2024 9:50 PM, Charan Teja Kalla wrote:
> Thanks T.J for the reply!!
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
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
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
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
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 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(>file->f_count) != 0L;
> > }
> >
> > If we end up
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
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
From: Kuro
New patch description for v7 patch
modify code from
it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET, 0x02); to
it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET,
TX_FIFO_RESET); for macro define
New patch description for v6 patch
From: Kuro
ITE added a FIFO reset bit for input video. When system power resume,
the TTL input of it6505 may get some noise before video signal stable
and the hardware function reset is required.
But the input FIFO reset will also trigger error interrupts of output module
rising.
Thus, it6505
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
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
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
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
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
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 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()
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
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
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
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
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
---
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
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
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
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
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
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
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
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
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
> >
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
> unexpected and contradicts the usual code patterns for the sake of
> performance
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 display through OF graph and external
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
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
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.
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
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
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
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 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
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
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
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
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
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
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
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
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
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
>
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,
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,
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
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
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
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
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.
1 - 100 of 131 matches
Mail list logo
