Re: [PATCH v2 13/13] ARM: s3c24xx: camif: include header with prototypes and unify declaration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 12, 2020 at 03:11:41PM +0200, Sylwester Nawrocki wrote:
> On 12.08.2020 13:28, Arnd Bergmann wrote:
> > On Wed, Aug 12, 2020 at 12:46 PM Sylwester Nawrocki
> > <s.nawrocki@xxxxxxxxxxx> wrote:
> >> On 12.08.2020 11:14, Arnd Bergmann wrote:
> >>>
> >>> It seems there have never been any callers and the entire file
> >>> can just be removed, with the rest of that platform_data header
> >>> file moved to drivers/media/platform/s3c-camif/.
> >>
> >> Yes, it seems that patch never made it to mainline:
> >> https://protect2.fireeye.com/v1/url?k=abe5f73a-f6293cfe-abe47c75-0cc47a314e9a-7fafe832d055d852&q=1&e=2596ffb6-c4cb-492a-8c6f-a0e261567842&u=https%3A%2F%2Fgit.linuxtv.org%2Fsnawrocki%2Fmedia.git%2Fcommit%2F%3Fh%3Dtesting%2Fs3c-camif%26id%3D355cbf835aff2aabf78390931cbbaa608af77967
> > 
> > I suppose it would still apply if anyone was interested, but I see your
> > point.
> > 
> >> I doubt there are still users of camera on the s3c2440 boards
> >> with current mainline kernels, if any at all, there are much
> >> better HW alternatives right now.
> > 
> > I see two board files (and no DT) instantiate the camif device:
> > NexVision Nexcoder 2440 and the FriendlyARM mini2440.
> > 
> > Can you say whether the camif on those would actually work
> > at all without your patch? If not, we know that there are no
> > users of that driver and could either drop it completely or move
> > it to staging for a release or two.
> 
> Without additional patches the camif will not work, the driver 
> needs an instance of struct s3c_camif_plat_data which specifies
> what image sensor is attached.
> 
> I think we can drop the driver, together with the s3c_camif_device
> platform device definitions. It can always be added again if anyone
> ever needs it or converts the platform to DT.

Since the header was in /include/media I assumed there might be some
user-space tools using it. But if it is not the case, I'll drop the code
then.

 
> IMO all non-DT code in arch/arm/mach-s3c24xx is a candidate for
> removal, it just adds to the maintenance effort and I seriously
> doubt there are now any users of it.

That is quite tricky... I really do not know whether there are any real
world users of S3C24xx and S3C64xx platforms. Evalkits are mostly not
available for buying so I do not expect new designs. However still
existing ones might be somewhere... Few years ago, back in Samsung, I
mentioned removing them. That time I think Marek or you Sylwester, said
that there are industrial applications using S3C24xx. I believe, why
not. The trouble is - how to find such users? How to get in touch for
testing or at least for bug reports if something is broken?

Or even more important - is it worth to spend effort and time on this?
If there is no single production system using recent Linux kernel, the
answer should be negative...

Best regards,
Krzysztof



[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux for Synopsys ARC Processors]    
  • [Linux on Unisoc (RDA Micro) SoCs]     [Linux Actions SoC]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  •   Powered by Linux