[PATCH 02/14] video: nokia_rx51: Drop obsolete video code

[Pali Rohár]

Hello!

On Sunday 23 January 2022 08:54:24 Simon Glass wrote:
> Hi Pali,
> 
> On Sun, 23 Jan 2022 at 07:57, Pali Rohár <pali at kernel.org> wrote:
> >
> > On Sunday 23 January 2022 07:36:22 Simon Glass wrote:
> > > Hi Pali,
> > >
> > > On Sun, 23 Jan 2022 at 07:08, Pali Rohár <pali at kernel.org> wrote:
> > > >
> > > > + Maemo
> > > >
> > > > On Sunday 23 January 2022 07:04:03 Simon Glass wrote:
> > > > > Drop this code which uses a header that is about to be deleted.
> > > >
> > > > And what / where is the replacement?
> > >
> > > This is DM_VIDEO. There are quite a few example drivers in
> > > drivers/video - perhaps the mxsfb.c one is a reasonable example. See
> > > the top of video_uclass.c for how frame-buffer allocation works.
> >
> > I have already WIP patches for usage of video-uclass.c but because
> > reviewing of N900 patches is slow, I have not sent them yet.
> 
> Who is reviewing them?

Lokesh is reviewing omap3 and n900 patches.

> If you send the patches I can review them and
> we can get them applied for this release.

I have already wrote in other thread I do not want to send too many
patches if I see that review process is slow. And also because I totally
lost the track what was send, what was not and what depends on what. And
I do not want to work on too many things in paralel if I see that it
took half year or more to make patches in acceptable form.

> >
> > So could you please do NOT remove N900 support? I would really
> > appreciative for reviewing pending patches instead of sending patches
> > with board removal.
> 
> This is not a board removal, just dropping a feature.

... feature which is essential and without which board is unusable.

> >
> > Note that there is some issue with video_post_bind(), it throws
> > false-positive error "Video device '%s' cannot allocate frame buffer
> > memory" with "return -ENOSPC". If I remove that "return -ENOSPC" it is
> > working fine.
> 
> Do you need U-Boot to allocate the frame buffer. If so, this is likely
> because your driver is not bound before relocation. See the comment
> around that message in the code.
> 
> Regards,
> Simon

I did not spend too much time for investigation. I just saw that
removing that comment and returning makes it fully working.