linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Soeren Moch <smoch@web.de>
To: Jemma Denson <jdenson@gmail.com>,
	Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: "Tycho Lürsen" <tycholursen@gmail.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	linux-media@vger.kernel.org, "Manu Abraham" <manu@linuxtv.org>,
	"Andreas Regel" <andreas.regel@gmx.de>,
	"Oliver Endriss" <o.endriss@gmx.de>
Subject: Re: [GIT PULL] SAA716x DVB driver
Date: Sun, 3 Dec 2017 15:11:34 +0100	[thread overview]
Message-ID: <3251f1f3-ce9b-529d-b155-ac433d1b0ae5@web.de> (raw)
In-Reply-To: <335e279e-d498-135f-8077-770c77cf353b@gmail.com>



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@gmail.com> 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

  reply	other threads:[~2017-12-03 14:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-16 18:34 Soeren Moch
2017-07-20 10:49 ` Mauro Carvalho Chehab
2017-07-21 20:44 ` Soeren Moch
2017-08-27 10:30   ` Mauro Carvalho Chehab
2017-09-09 12:52     ` Soeren Moch
2017-09-09 21:20       ` Mauro Carvalho Chehab
2017-09-16 12:54         ` Soeren Moch
2017-09-16 17:49           ` Mauro Carvalho Chehab
2017-09-24 22:17             ` Soeren Moch
2017-11-24 16:28               ` Tycho Lürsen
2017-11-27 11:24                 ` Mauro Carvalho Chehab
2017-12-02 18:51                   ` Jemma Denson
2017-12-02 19:49                     ` Mauro Carvalho Chehab
2017-12-02 23:59                       ` Soeren Moch
2017-12-03 10:57                         ` Jemma Denson
2017-12-03 14:11                           ` Soeren Moch [this message]
2017-12-03 15:04                             ` Jemma Denson
2017-12-04 10:07                               ` Mauro Carvalho Chehab
2018-01-19 13:59                           ` Tycho Lürsen
2018-01-19 15:11                             ` Jemma Denson
2018-01-20 15:49                               ` Tycho Lürsen
2018-01-25 17:08                                 ` Jemma Denson
2017-11-28 18:35               ` [GIT PULL] " Mauro Carvalho Chehab
2017-12-02 23:58                 ` Soeren Moch
2017-08-23  9:56 ` [GIT PULL RESEND] " Soeren Moch
2018-03-07 15:14   ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3251f1f3-ce9b-529d-b155-ac433d1b0ae5@web.de \
    --to=smoch@web.de \
    --cc=andreas.regel@gmx.de \
    --cc=jdenson@gmail.com \
    --cc=linux-media@vger.kernel.org \
    --cc=manu@linuxtv.org \
    --cc=mchehab@infradead.org \
    --cc=mchehab@kernel.org \
    --cc=o.endriss@gmx.de \
    --cc=tycholursen@gmail.com \
    --subject='Re: [GIT PULL] SAA716x DVB driver' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).