On 03.12.2017 11:57, Jemma Denson wrote: > On 02/12/17 23:59, Soeren Moch wrote: >> On 02.12.2017 20:49, Mauro Carvalho Chehab wrote: >>> Em Sat, 2 Dec 2017 18:51:16 +0000 >>> Jemma Denson <jdenson@xxxxxxxxx> escreveu: >>>> Would I be correct in thinking the main blocker to this is the *_ff >>>> features >>>> used by the S2-6400 card? There's plenty of other cards using this >>>> chipset >>>> that don't need that part. >>>> >>>> Would a solution for now to be a driver with the ff components >>>> stripped out, >>>> and then the ff API work can be done later when / if there's any >>>> interest? >>> Works for me. In such case (and provided that the driver without >>> *_ff are >>> in good shape), we could merge it under drivers/media (instead of >>> merging >>> it on staging). >> All the entries in the TODO file are not specific for saa716x_ff. > > Ah, it's been a few months since I looked at that. I think some of the > things listed I had already identified as problems - checkpatch > especially, Finding checkpatch problems is easy... > and the irq code probably needs a bit more auto-detection. > I'm not sure I've seen how the other issues manifest themselves so I > might need some explanation of that (off list if you prefer) > >>>> I guess a problem would be finding a maintainer, I'm happy to put >>>> together >>>> a stripped down driver just supporting the TBS card I use (I >>>> already have >>>> one I use with dkms), but I'm not sure I have the time or knowledge >>>> of this >>>> chipset to be a maintainer. >> There is chipset specific stuff to fix, especially irq handling. > > Is this the module parameter kludges or something else? > >>> As we're talking more about touching at uAPI, probably it doesn't >>> require >>> chipsed knowledge. Only time and interest on doing it. >>> >>> Please sync with Soeren. Perhaps if you both could help on it, it would >>> make the task easier. >> As I already wrote to different people off-list: I'm happy to support >> more cards with the saa7160 bridge and maintain these in this driver. As >> hobbyist programmer this of course makes no sense to me, if the hardware >> I own (S2-6400) is not supported. >> > > Hence my comment about finding a maintainer - I had assumed if the > immediate result didn't support your card you probably wouldn't be > willing > to do that. > > What I'm trying to do here is get *something* merged, and then once > that work is done any interested parties can add to it. Or at the very > least if some patches are left OOT the constant workload required to > keep that up to date should be reduced significantly because they'll be > far less to look after. > Why not merge the driver as-is? The community would get support for several cards, easy access to the code without the need for separate git repositories or dkms packages, and a maintainer that understands the hardware and driver code. The whole purpose of driver development is bringing support for existing hardware to available user applications, preferably with existing APIs. And exactly that is in this pull request. In the whole discussion I cannot find a single reason, how merging this driver would violate the linux development principles. > One of the problems though is choosing which fork to use. I *think* there > are 2 - the one you've got which is the original powARman branch and the > one I would be using is the CrazyCat / Luis / TBS line. There are > going to be > some differences but hopefully that's all frontend support based and > one cut > down to a single frontend would end up a good base to add the rest back > in. > I think my repository represents the main development branch, just maintained by different people (adding Manu, Andreas, Oliver, in case they want to object). The CrazyCat repo is not a fork (including history), it is just a snapshot of the driver plus several patches. I already promised to help with adding TBS support. Regards, Soeren > I'm looking at maybe finding time over christmas break. > > > Jemma
