y thing this series won't deal with is exactly that.
>
> Sorry, no, I got confused.
>
> The series *does* already deal with that, as the pipeline is built before the
> check
> for OVL_ADAPTOR components, so that will get probed.
Are you sure? Because who is actually adding the O
Y" ought
> to be enough for those.
>
> >
> > $ git grep -w fb_register_client
> > arch/arm/mach-pxa/am200epd.c: fb_register_client(_fb_notif);
> > drivers/leds/trigger/ledtrig-backlight.c: ret =
> > fb_register_client(>notifier);
> > drivers/
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
.atomic_begin = vmw_du_crtc_atomic_begin,
> > --
> > 2.34.1
> >
>
> Thanks, but that doesn't look correct. We do want to make sure the
> drm_crtc_vblank_off is actually called when outputs are disabled.
> Since this is my regression it's perfectly fine if yo
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
gt; > > > > returned as the
> > > > > > -string here. The name "memory" is reserved to refer to normal
> > > > > > system memory.
> > > > > > +string here.
> > > > > > +
> > > > > > +
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(>file->f_count) != 0L;
> > }
> >
> > If we end up
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
this series got picked
... but there you go - I'm sure that you won't mind and that the example will
be more than good enough for you.
I've tested this series with the DSI0 output and it works. Nice! No
need for my DSI0 patch for the MT8395 anymore.
But I can't get it to work with the DisplayPort
won't mind and that the example will
be more than good enough for you.
I've tested this series with the DSI0 output and it works. Nice! No
need for my DSI0 patch for the MT8395 anymore.
But I can't get it to work with the DisplayPort output, that is the
dp_intf1/dp_tx interface. I don' know how
its upstream
> before this series got picked
>
> ... but there you go - I'm sure that you won't mind and that the example will
> be more than good enough for you.
I've tested this series with the DSI0 output and it works. Nice! No
need for my DSI0 patch for the MT8395 anymore.
But
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
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
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!!
u've already said that you aren't concerned with performance on
> epoll() upthread. So afaict then there's really not a lot more to
> discuss other than take the patch and see whether we get any complaints.
Two closing thoughts:
(1) I wonder if this won't cause userspace regressions for the semantics
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 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
merge this only after seeing the
> main drivers/i2c accepting the new terminology. So we don't have a
> risk of that getting push back and new names there and we having
> to rename it once again.
I basically agree with this patch (without the eDP part).
But the documentation is st
; Thomas
Zimmermann ; David Airlie ; Daniel
Vetter ; open list:DRM DRIVERS
; open list
Subject: Re: [PATCH v6 1/1] drm/bridge: it6505: fix hibernate to resume no
display issue
On Tue, Apr 23, 2024 at 10:16 AM kuro wrote:
>
> From: Kuro
>
> ITE added a FIFO reset bit for input
; main drivers/i2c accepting the new terminology. So we don't have a
>> > risk of that getting push back and new names there and we having
>> > to rename it once again.
>>
>> Just to be explicit, did you want me to remove the Acked-by in v3, or will
>> yo
ast worth discussing what's more important because epoll()
is very widely used and it's not that we haven't favored performance
before.
But you've already said that you aren't concerned with performance on
epoll() upthread. So afaict then there's really not a lot more to
discuss other than take the patc
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,
hi, Kees Cook,
we noticed a WARNING is our boot tests.
as we understand, the WARNING is not introduced by this patch, instead, just
changing stats as below.
however, we failed to bisect
"dmesg.WARNING:at_lib/refcount.c:#refcount_warn_saturate"
which shows in parent commit to ca
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]
72,10 +72,11 @@ config ROCKCHIP_DW_MIPI_DSI
> > enable MIPI DSI on RK3288 or RK3399 based SoC, you should
> > select this option.
> > config ROCKCHIP_INNO_HDMI
> > bool "Rockchip specific extensions for Innosilicon HDMI"
> > + depends on
>
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:
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
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
remove
> > the explicit shutdown/remove handling in the panel drivers. Most of
> > the patches to improve DRM modeset drivers [2] [3] [4] have now
> > landed.
> >
> > In contrast to my V1 series, I broke the V2 series up a lot
> > more. Since a few of the pane
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
st to my V1 series, I broke the V2 series up a lot
> more. Since a few of the panel drivers in V1 already landed, we had
> fewer total drivers and so we could devote a patch to each panel.
> Also, since we were now relying on DRM modeset drivers I felt like we
> should split the patches for eac
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:
> 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 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
d.
>
> Note: Class-based device instantiation is a legacy mechanism which
> shouldn't be used in new code, so we can rule out that this argument
> may be needed again in the future.
>
> Signed-off-by: Heiner Kallweit
For the record, I will apply this patch once A
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. With the recently
> introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
> but also saves space.
] [drm:dpu_encoder_phys_cmd_control_vblank_irq] *ERROR*
vblank irq err id:31 pp:0 ret:-22, enable true/0
[ 355.090460] [drm:dpu_encoder_phys_cmd_control_vblank_irq] *ERROR*
vblank irq err id:31 pp:0 ret:-22, enable false/0
Unfortunately with this patch, turning the CRTC off via ./modetest -M msm -a
-w 81:ACTIVE:0
On 2024-05-01 00:55, Christoph Hellwig wrote:
> On Fri, Apr 26, 2024 at 05:17:52PM -0700, David Wei wrote:
>> On 2024-04-02 5:20 pm, Mina Almasry wrote:
>>> @@ -69,20 +106,26 @@ net_iov_binding(const struct net_iov *niov)
>>> */
>>> typedef unsigned long __bitwise netmem_ref;
>>>
>>> +static
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 all means, let's grab reference
>
On Sun, May 05, 2024 at 01:03:07PM -0700, Linus Torvalds wrote:
> On Sun, 5 May 2024 at 12:46, Al Viro wrote:
> >
> > I've no problem with having epoll grab a reference, but if we make that
> > a universal requirement ->poll() instances can rely upon,
>
> Al, we're note "making that a
On Sun, 5 May 2024 at 13:02, David Laight wrote:
>
> How much is the extra pair of atomics going to hurt performance?
> IIRC a lot of work was done to (try to) make epoll lockless.
If this makes people walk away from epoll, that would be absolutely
*lovely*. Maybe they'd start using io_uring
On Sun, May 05, 2024 at 09:46:05AM -0700, Linus Torvalds wrote:
> WHY?
>
> Why cannot you and Al just admit that the problem is in epoll. Always
> has been, always will be.
Nobody (well, nobody who'd ever read epoll) argues that epoll is not
a problem.
> The fact is, it's not dma-buf that is
From: Linus Torvalds
> Sent: 05 May 2024 18:56
>
> epoll can call out to vfs_poll() with a file pointer that may race with
> the last 'fput()'. That would make f_count go down to zero, and while
> the ep->mtx locking means that the resulting file pointer tear-down will
> be blocked until the poll
On Sun, 5 May 2024 at 12:46, Al Viro wrote:
>
> I've no problem with having epoll grab a reference, but if we make that
> a universal requirement ->poll() instances can rely upon,
Al, we're note "making that a requirement".
It always has been.
Otgherwise, the docs should have shouted out DAMN
On Sat, May 04, 2024 at 08:53:47AM -0700, Linus Torvalds wrote:
> poll_wait
> -> __pollwait
> -> get_file (*boom*)
>
> but the boom is very small because the poll_wait() will be undone by
> poll_freewait(), and normally poll/select has held the file count
> elevated.
Not quite. It's
On Wed, Apr 24, 2024 at 04:14:07PM -0700, Alexey Makhalov wrote:
> +#define VMWARE_CMD_GETVERSION10
> +#define VMWARE_CMD_GETHZ 45
> +#define VMWARE_CMD_GETVCPU_INFO 68
> +#define VMWARE_CMD_STEALCLOCK91
Ok, what part in
&q
; - note about returning zero rather than something like EPOLLERR|POLLHUP
>for a file that is going away
I did look at that 0 return as well and agreed this is the right choice,
but adding the comment is a good idea.
Anyway, patch still looks fine to me. I'd word wrap the comment section
above epi_fget() wider, but that's just a stylistic choice...
--
Jens Axboe
epoll can call out to vfs_poll() with a file pointer that may race with
the last 'fput()'. That would make f_count go down to zero, and while
the ep->mtx locking means that the resulting file pointer tear-down will
be blocked until the poll returns, it means that f_count is already
dead, and any
On 5/3/24 3:11 PM, Linus Torvalds wrote:
> epoll is a mess, and does various invalid things in the name of
> performance.
>
> Let's try to rein it in a bit. Something like this, perhaps?
>
> Not-yet-signed-off-by: Linus Torvalds
> ---
>
> This is entirely untested, thus the
On Sun, 5 May 2024 at 03:50, Christian Brauner wrote:
>
> And I agree with you that for some instances it's valid to take another
> reference to a file from f_op->poll() but then they need to use
> get_file_active() imho and simply handle the case where f_count is zero.
I think this is
(a)
Thanks T.J for the reply!!
On 5/4/2024 4:43 AM, T.J. Mercier wrote:
> It looks like a similar conclusion about epoll was reached at:
> https://lore.kernel.org/all/a87d7ef8-2c59-4dc5-ba0a-b821d1eff...@amd.com/
>
I am unaware of this discussion. Thanks...
> I agree with Christian that it should
Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from
known context") by error replaced spin_unlock_irqrestore() with
spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite
sync_print_obj() is called from sync_debugfs_show(), lockdep complains
ariable is confusing I would get rid of it
> completely. Can you
> send a patch that removes the timeout variable and here just does:
>
> if (wait_for_completion_timeout(flip_done, HZ) == 0) {
Can do. I think, though, that using 'time_left' is still easier to
understand. However,
have support for proper locking for a selected set of registers
> > > (LNKCTL2 is not yet among them but likely will be in the future) to
> > > avoid losing concurrent updates.
> > >
> > > Suggested-by: Lukas Wunner
> > > Signed-off-by: Ilpo Järvinen
On Sat, May 04, 2024 at 08:40:25AM -0700, Linus Torvalds wrote:
> On Sat, 4 May 2024 at 08:32, Linus Torvalds
> wrote:
> >
> > Now, during this TOTALLY INNOCENT sock_poll(), in another thread, the
> > file closing completes, eventpoll_release() finishes [..]
>
> Actually, Al is right that
; Yuran Pereira; Neil Armstrong; Sumit Semwal;
Benni Steini; Marijn Suijten; Daniel Vetter; David Airlie; Jessica Zhang;
Maarten Lankhorst; Sam Ravnborg; Thomas Zimmermann; linux-ker...@vger.kernel.org
Subject: Re: [RFT PATCH v2 19/48] drm/panel: novatek-nt36672a: Don't call
unprepare+disable
Hi Douglas Anderson,
Poco F1 is one of the main user for this panel. I tested the patch in my Poco
F1 running postmarketOS. It works fine. Thank you. The panel itself requires
other extra fixes to work properly which I intend to upstream in the upcoming
weeks. But your patch doesn't break
Hi Douglas Anderson,
Poco F1 is one of the main user for this panel. I tested the patch in my Poco
F1 running postmarketOS. It works fine. Thank you. The panel itself requires
other extra fixes to work properly which I intend to upstream in the upcoming
weeks. But your patch doesn't break
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 wonder if we could *really* fix this by
> Return -EINVAL on error instead of success. Also on the success path,
> return a literal zero instead of "return result;"
How do you think about to omit the initialisation for the variable “result”
in another update step?
Regards,
Markus
From: Rob Clark
These tables were made non-const in commit 3cba4a2cdff3 ("drm/msm/a6xx:
Update ROQ size in coredump") in order to avoid powering up the GPU when
reading back a devcoredump. Instead let's just stash the count that is
potentially read from hw in struct a6xx_gpu_state_obj, and make
On Sat, 4 May 2024 at 08:40, Linus Torvalds
wrote:
>
> And maybe it's even *only* dma-buf that does that fget() in its
> ->poll() function. Even *then* it's not a dma-buf.c bug.
They all do in the sense that they do
poll_wait
-> __pollwait
-> get_file (*boom*)
but the boom is very
On Sat, 4 May 2024 at 08:32, Linus Torvalds
wrote:
>
> Now, during this TOTALLY INNOCENT sock_poll(), in another thread, the
> file closing completes, eventpoll_release() finishes [..]
Actually, Al is right that ep_item_poll() should be holding the
ep->mtx, so eventpoll_release() ->
On Sat, 4 May 2024 at 02:37, Christian Brauner wrote:
>
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -244,13 +244,18 @@ static __poll_t dma_buf_poll(struct file *file,
> poll_table *poll)
> if (!dmabuf || !dmabuf->resv)
> return EPOLLERR;
>
> +
Hi Florian,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-tip/drm-tip linus/master v6.9-rc6 next-20240503]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Hi Shawn,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20240501]
[cannot apply to v6.9-rc6 v6.9-rc5 v6.9-rc4 linus/master v6.9-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
Hi Florian,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-tip/drm-tip linus/master v6.9-rc6 next-20240503]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
The "ret" variable is zero. No need to check.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index
Return -EINVAL on error instead of success. Also on the success path,
return a literal zero instead of "return result;"
Fixes: e098bc9612c2 ("drm/amd/pm: optimize the power related source code
layout")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c | 4
On Fri, May 03, 2024 at 04:20:24PM +, Ashok Kumar wrote:
>
> Is there a list of exceptions to the checkpatch information that we can
> ignore in general.
>
For Greg's subsystems ignore the warning about extra parentheses.
You can search on lore for if a patch has been patch h
On Sat, May 04, 2024 at 12:39:00AM +0100, Al Viro wrote:
> On Fri, May 03, 2024 at 04:16:15PM -0700, Linus Torvalds wrote:
> > On Fri, 3 May 2024 at 15:07, Al Viro wrote:
> > >
> > > Suppose your program calls select() on a pipe and dmabuf, sees data to be
> > > read
> > > from pipe, reads it,
On Fri, May 03, 2024 at 02:33:37PM -0700, Linus Torvalds wrote:
> On Fri, 3 May 2024 at 14:24, Al Viro wrote:
> >
> > Can we get to ep_item_poll(epi, ...) after eventpoll_release_file()
> > got past __ep_remove()? Because if we can, we have a worse problem -
> > epi freed under us.
>
> Look at
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
; .atomic_check = vmw_du_crtc_atomic_check,
> .atomic_begin = vmw_du_crtc_atomic_begin,
> --
> 2.34.1
>
Thanks, but that doesn't look correct. We do want to make sure the
drm_crtc_vblank_off is actually called when outputs are disabled.
Since this is my regression it's perfectly fi
> 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,
> > sadly.
> >
> > > > However, the migration stuff should really not be
On 5/3/2024 5:02 PM, Dmitry Baryshkov wrote:
On Sat, 4 May 2024 at 01:38, Abhinav Kumar wrote:
On 5/3/2024 1:20 PM, Dmitry Baryshkov wrote:
On Fri, 3 May 2024 at 22:42, Abhinav Kumar wrote:
On 5/3/2024 11:15 AM, Dmitry Baryshkov wrote:
In order to validate drm/msm register
On Sat, 4 May 2024 at 01:38, Abhinav Kumar wrote:
>
>
>
> On 5/3/2024 1:20 PM, Dmitry Baryshkov wrote:
> > On Fri, 3 May 2024 at 22:42, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 5/3/2024 11:15 AM, Dmitry Baryshkov wrote:
> >>> In order to validate drm/msm register definition files against
On Fri, 3 May 2024 at 16:39, Al Viro wrote:
>
> *IF* those files are on purely internal filesystem, that's probably
> OK; do that with something on something mountable (char device,
> sysfs file, etc.) and you have a problem with filesystem staying
> busy.
Yeah, I agree, it's a bit annoying in
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 adding epi_fget(), we'll have 2 cases of using
> "atomic_long_inc_not_zero" for
On Fri, May 03, 2024 at 04:16:15PM -0700, Linus Torvalds wrote:
> On Fri, 3 May 2024 at 15:07, Al Viro wrote:
> >
> > Suppose your program calls select() on a pipe and dmabuf, sees data to be
> > read
> > from pipe, reads it, closes both pipe and dmabuf and exits.
> >
> > Would you expect that
On Sat, May 04, 2024 at 12:03:18AM +0100, Al Viro wrote:
> On Fri, May 03, 2024 at 03:46:25PM -0700, Kees Cook wrote:
> > On Fri, May 03, 2024 at 02:52:38PM -0700, Linus Torvalds wrote:
> > > That means that the file will be released - and it means that you have
> > > violated all the refcounting
On Fri, 3 May 2024 at 15:07, Al Viro wrote:
>
> Suppose your program calls select() on a pipe and dmabuf, sees data to be read
> from pipe, reads it, closes both pipe and dmabuf and exits.
>
> Would you expect that dmabuf file would stick around for hell knows how long
> after that? I would
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 8fe5aa67b167..e469dd9288cc
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -240,6 +240,10 @@ static __poll_t dma_buf_poll(struct file *file,
> poll_table *poll)
> struct dma_re
n
> > > drm_atomic_helper_shutdown
> > > drm_atomic_helper_disable_all
> > > drm_atomic_commit
> > > drm_atomic_helper_commit
> > > commit_tail
> > > drm_atomic_helper_commit_tail
> > >
On Fri, May 03, 2024 at 03:46:25PM -0700, Kees Cook wrote:
> On Fri, May 03, 2024 at 02:52:38PM -0700, Linus Torvalds wrote:
> > That means that the file will be released - and it means that you have
> > violated all the refcounting rules for poll().
>
> I feel like I've been looking at this too
On Fri, May 03, 2024 at 02:52:38PM -0700, Linus Torvalds wrote:
> That means that the file will be released - and it means that you have
> violated all the refcounting rules for poll().
I feel like I've been looking at this too long. I think I see another
problem here, but with dmabuf even when
On 5/3/2024 1:20 PM, Dmitry Baryshkov wrote:
On Fri, 3 May 2024 at 22:42, Abhinav Kumar wrote:
On 5/3/2024 11:15 AM, Dmitry Baryshkov wrote:
In order to validate drm/msm register definition files against schema,
reuse the nodebugfs build step. The validation entry is guarded by
the
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 behaviour of disable_outputs in
drm_atomic_helper.c:1211.
Fixes: 7b0062036c3b ("drm/vmwgfx: Implement virtual crc generation")
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 terminology for users of
> I2C_ALGOBIT
On Fri, May 03, 2024 at 11:01:45PM +0100, Al Viro wrote:
> Having ->poll() instance itself grab reference is really asking for problem,
> even on the boxen that have CONFIG_EPOLL turned off. select(2) is enough;
> it will take care of references grabbed by __pollwait(), but it doesn't
> know
On Fri, May 03, 2024 at 02:52:38PM -0700, Linus Torvalds wrote:
> On Fri, 3 May 2024 at 14:45, Al Viro wrote:
> >
> > How do you get through eventpoll_release_file() while someone
> > has entered ep_item_poll()?
>
> Doesn't matter.
>
> Look, it's enough that the file count has gone down to
On Fri, 3 May 2024 at 14:45, Al Viro wrote:
>
> How do you get through eventpoll_release_file() while someone
> has entered ep_item_poll()?
Doesn't matter.
Look, it's enough that the file count has gone down to zero. You may
not even have gotten to eventpoll_release_file() yet - the important
On Fri, May 03, 2024 at 02:33:37PM -0700, Linus Torvalds wrote:
> Look at the hack in __ep_remove(): if it is concurrent with
> eventpoll_release_file(), it will hit this code
>
> spin_lock(>f_lock);
> if (epi->dying && !force) {
> spin_unlock(>f_lock);
>
'if.*>prepared' -- drivers/gpu/drm/panel
- git grep 'if.*>enabled' -- drivers/gpu/drm/panel
-
-In the patch ("drm/panel: Check for already prepared/enabled in drm_panel")
-we've moved this check to the core. Now we can most definitely remove the
-check from the individual panels and sav
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 functions themselves.
A recent effort was made to fix as many DRM
1 - 100 of 351376 matches
Mail list logo
