On Wed, May 24, 2023 at 01:52:14PM +0200, Thorsten Leemhuis wrote:
> On 22.05.23 14:51, Sakari Ailus wrote:
> > On Mon, May 22, 2023 at 02:11:29PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> >> On 22.05.23 13:59, Sakari Ailus wrote:
> >>> On Mon, May 22, 2023 at 12:53:52PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>>> On 28.04.23 09:16, Sakari Ailus wrote:
> >>>>> On Fri, Apr 28, 2023 at 08:43:21AM +0200, Jacopo Mondi wrote:
> >>>>>> On Fri, Apr 28, 2023 at 08:33:30AM +0200, Alexander Stein wrote:
> >>>>>>> Am Freitag, 28. April 2023, 08:31:54 CEST schrieb Jacopo Mondi:
> >>>>>>>> On Fri, Apr 28, 2023 at 08:24:22AM +0200, Alexander Stein wrote:
> >>>>>>>>> Am Donnerstag, 27. April 2023, 18:01:38 CEST schrieb Jacopo Mondi:
> >>>>>>>>>> On Thu, Apr 27, 2023 at 04:40:46PM +0200, Alexander Stein wrote:
> >>>>>>>>>>> I have a setup on my TQMa6x (imx6q-mba6a.dts) with a tc358743 attached
> >>>>>>>>>>> to
> >>>>>>>>>>> the MIPI CSI input.
> >>>>>>>>>>> I noticed that since commit 1f391df44607 ("media: v4l2-async: Use
> >>>>>>>>>>> endpoints in __v4l2_async_nf_add_fwnode_remote()") the async subdevice
> >>>>>>>>>>> probing does not work anymore. If I revert that, it is working again,
> >>>>>>>>>>> even on next-20230425.
> >>>>>>>>>>
> >>>>>>>>>> A similar issue has been discussed at
> >>>>>>>>>> https://www.spinics.net/lists/linux-media/msg223351.html
> >>>>>>>>>>
> >>>>>>>>>> Unfortunately there was no conclusion as far as I can tell if not that
> >>>>>>>>>> imx6 is now broken
> >>>>>>>>>
> >>>>>>>>> Thanks for the link, seems like a non-trivial thing :(
> >>>>>>>>>
> >>>>>>>>> From a glimpse, this series seems to deal with multiple async subdevs:
> >>>>>>>>> https://lore.kernel.org/all/20230330115853.1628216-1-sakari.ailus@xxxxxxxx
> >>>>>>>>> tel.com/
> >>>>>>>>>
> >>>>>>>>> So imx-media-csi should be adjusted as well, no?
> >>>>>>>>
> >>>>>>>> It would really be helpful if you can give that series a spin on imx6
> >>>>>>>> if you already have a test setup.
> >>>>>>>
> >>>>>>> I tried, but it failed to apply on my current development tree. What base does
> >>>>>>> this series apply to? Is there also a repository available I can fetch from?
> >>>>>>
> >>>>>> Sakari could tell, for me it applied on v6.3-rc2 but I recall I had to
> >>>>>> manually fix a few things.
> >>>>>
> >>>>> Don't try v1, it won't work. I missed some object relation changes in the
> >>>>> linked lists. I'll post v2, hopefully some time next week, to address these
> >>>>> issues.
> >>>>
> >>>> Hi, Thorsten here, the Linux kernel's regression tracker.
> >>>>
> >>>> I see that v2[1] got a lot of ACKs, but is not even yet in next. And
> >>>> it's a lot of patches, so maybe too much for backporting to stable
> >>>> kernels. Which leads to the question: Will the regression this thread is
> >>>> about (introduced in 5.19 afaics) ever be fixed in v6.1?
> >>>> Normally/Ideally it should be.
> >>>
> >>> We'll need v3 (at least), a problem that's not trivial to fix was
> >>> identified with v2. There patches aren't really fixes either: it's new
> >>> functionality that wasn't there previously. I.MX6 just happened to work due
> >>> to missing checks in the V4L2 async framework, what it needs was never
> >>> supported (without this set).
> >>>
> >>> Dropping endpoint matching will break adv748x driver that relies on it.
> >>>
> >>> So I'd expect i.MX6 to work again once we have this set in, but I wouldn't
> >>> try to backport the set.
> >>
> >> Thx for the update. Makes me wonder if reverting the culprit[1] is an
> >> option. Assuming the problem still happens. Alexander, is that the case?
> >>
> >> Ciao, Thorsten
> >>
> >> [1] 1f391df4460 ("media: v4l2-async: Use endpoints in
> >> __v4l2_async_nf_add_fwnode_remote()") (v5.19-rc1; authored by Laurent,
> >> commited by Mauro (both now CCed))
> >
> > I prioritise an in-kernel driver over a staging driver.
>
> Sorry, can't follow. I track regressions all over the kernel and try to
> follow the best I can, but here I failed, as I have no idea which
> staging driver I mean.
>
> I see a regression that is not really addressed and I wonder if there is
> a way to fix this until a proper solution is ready. Usually in this
> cases the culprit is reverted, unless that itself would cause another
> regression. Is that the case here? It sounds a bit like it, but would be
> great if somebody could confirm that.
As I explained earlier, reverting the patch will break adv748x.
--
Sakari Ailus
