[10:58] <mchehab> b-rad: I just applied your patches for em28xx-based dual-TS boards...
[10:59] <mchehab> please test, as there are some em28xx cleanups and improvements applied after those
[10:59] <mchehab> and I don't have any dual-TS em28xx board here to test myself
[14:15] <mchehab> b-rad: btw, when you need to send a new version of a patch inside a patch series, please re-send the entire patch series, as otherwise we very likely will be missing the newer versions of the patches.
[14:30] <b-rad> thanks Mauro, will test
[14:30] <b-rad> will resend all patches in future, have been regenerating entire series and only sending in the ones affected
[14:31] <b-rad> oooh nice, you cleaned out half my queue :D
[14:36] <b-rad> I notice some of my v1/etc did not get deprecated, I will review what you committed so far
[14:38] <mchehab> b-rad: yeah, please do that... I'm lost with your other patches :-)
[14:38] <mchehab> something weird seemed to happen back in Jan...
[14:39] <b-rad> yikes one set got merged that shouldn't have been
[14:39] <mchehab> I didn't receive some patches on my inbox...
[14:39] <mchehab> and patchwork also missed some patches
[14:39] <b-rad> krufky said the original way was bad, so I did it another way, then someone else piped up and said no the original way was correct
[14:40] <mchehab> well, send a fixme patch
[14:40] <b-rad> will do after I'm fully awake
[14:40] <mchehab> :-)
[14:42] <mchehab> if you send those patches today, I'll just skip the remaining patches from you, as I'm afraid that I could be applying the wrong patchsets
[14:43] <mchehab> my plan is to cleanup my patch queue today
[14:43] <mchehab> (not sure if I'll be able to do it, though, as there are still lots of pending patches there)
[14:44] <mchehab> still 286 patches tehre
[14:44] <b-rad> I will lol
[14:45] <b-rad> yes please skip what is left of mine and I'll make sure everything is ok
[14:45] <mchehab> but I was able to apply 223 patches already during the morning
[14:45] <b-rad> only 12 left of mine, so shouldn't take long after I eat
[14:45] <mchehab> ok
[14:45] <mchehab> I'll mark them as Superseded
[14:45] <b-rad> btw what is the view on adding v3 stats to frontends? (i know they're deprecated)
[14:46] <b-rad> I get a lot of complaints about old software only using v3
[14:49] <b-rad> so I added enough to si2157 and si2168 to make them happy, but unsure if deprectaed ioctl patch would be accepted
[14:54] <mchehab> IMHO, the best would be to add a "generic" v3 stats at the core...
[14:54] <mchehab> and get rid of the per-driver handlers
[14:54] <mchehab> it shouldn't be hard to implement
[14:56] <mchehab> if you have some time, feel free to submit such patches
[14:56] <b-rad> for si2168 I am just taking the v5 stats and converting them to v3
[14:57] <b-rad> so I'm sure a core operation could transform any available v5 stats
[14:57] <mchehab> that's what every other drivers are doing
[14:57] <b-rad> I will into it
[15:02] <mchehab> E. g. something like this:
[15:02] <mchehab> 	case FE_READ_SNR:
[15:02] <mchehab> 		if (!fe->ops.read_snr) {
[15:02] <mchehab> 			if (c->cnr.stat[0].scale == FE_SCALE_DECIBEL)
[15:02] <mchehab> 				*parg = div_s64(c->cnr.stat[0].svalue, 100);
[15:02] <mchehab> 		else {
[15:02] <mchehab> 			if (fepriv->thread)
[15:02] <mchehab> 				err = fe->ops.read_snr(fe, parg);
[15:02] <mchehab> 			else
[15:02] <mchehab> 				err = -EAGAIN;
[15:02] <mchehab> 		}
[15:02] <mchehab> 		break;
[15:02] <mchehab> at dvb_frontend.c
[15:03] <mchehab> you need to check the scale... if  FE_SCALE_DECIBEL, divide by 100
[15:03] <b-rad> yep
[15:04] <mchehab> if FE_SCALE_NOT_AVAILABLE, then the counter is not available (not sure if it should return an error or zero - probably depends on the stats)
[15:05] <mchehab> anyway, I'm pretty sure it is simple enough to write something there that will allow us to get rid of dvbv3 support on drivers that have already dvbv5 stats
[15:05] <b-rad> will revise my stat set to be like this
[15:05] <mchehab> thanks!
[15:06] <b-rad> only driver change would be modifying si2157 stat_work
[15:06] <b-rad> I added rf_strength ioctl for get around that stat function delaying 2s at init and then only polling every 2s
[15:12] <mchehab> the idea of not polling the drivers is that it could cause excess I2C traffic
[15:12] <mchehab> with usually is not a good idea
[15:12] <mchehab> (if userspace misbehaves)
[15:14] <mchehab> on frontends I care most, there is a logic there preventing too fast stats request
[15:14] <b-rad> the fe is fine, because read_status gets all stats (for at least our two main fe)
[15:15] <mchehab> take a look, for example, at mb86a20s_read_signal_strength()
[15:15] <mchehab> drivers/media/dvb-frontends/mb86a20s.c
[15:15] <b-rad> but the tuner rf strength can be 2s stale by the time it is refreshed
[15:15] <mchehab> 	if (state->get_strength_time &&
[15:15] <mchehab> 	   (!time_after(jiffies, state->get_strength_time)))
[15:15] <mchehab> 		return c->strength.stat[0].uvalue;
[15:15] <b-rad> will look, thanks
[15:15] <mchehab> that prevents the risk of some userspace app to start a thread doing:
[15:15] <b-rad> i have the fe calling tuners rf_strength to work around the delay
[15:16] <mchehab> while (1) { ioctl (FE_some_stat_ioctl); } 
[15:16] <b-rad> indeed
[15:16] <b-rad> thanks for the tips, I won't bug you anymore until I resend my patches :)
[15:18] <mchehab> ok
[15:18] <mchehab> let me go back to patch reviews :-)
[15:21] *** laurent\ has quit IRC (Remote host closed the connection)
[16:12] <nst> mchehab: ping - thanks for accepting the cxd2099 series! however, things seriously got messed up during merge. there are three commits missing, and it was v1 that was (partially merged) while v2 got partially superseded...
[16:12] <mchehab> gah
[16:12] <mchehab> send fixup patches, please
[16:13] <nst> okay, will do in a few minutes. after applying them the ngene series should apply cleanly aswell
[16:15] <mchehab> there are some other cxd patches at another patch
[16:15] <mchehab> I'm finishing to apply
[16:41] <nst> mchehab: fixup posted (glad git got quite clever so rebasing really only left what's missing) - the patches are quite important since right now there's some breakage in ngene and ddbridge without them. re the two ngene fixes, I'll just drop the debug stuff and repost, was just copying what was there.
[16:43] <mchehab> ok
[17:17] <mchehab> nst: 4 patches applied
[17:22] <nst> mchehab: seen the mail notifications, thank you! doing a runtime test of the ngene patches sans debug_ci_xfer now (to check this didn't break anything by accident) and'll post those two aswell in a few minutes
[17:22] <mchehab> ok
[17:49] <nst> mchehab: posted. nb, noticed your dvb_module_*() i2c helpers, will adapt both ngene and ddbridge to use them, besides some other minors, but not today. :)
[17:49] <mchehab> Ok!
[17:55] <mchehab> applied
[17:55] <mchehab> just waiting for b-rad patch series :-)
[17:56] <mchehab> and start reviewing the new Sony driver
[17:57] <b-rad> little bits and pieces were missing
[17:57] <b-rad> i have one patch done, I think four left and I'll resend
[17:57] <mchehab> ok
[17:57] <b-rad> for the series where patches just went awol should I resend fresh v1 patchset with only them?
[17:58] <nst> mchehab: lovely! thanks for picking everything up, especially all users of the aging ngene cards will be very happy and thankful.
[17:58] <b-rad> random fixes I was going to send in one series
[17:58] <mchehab> b-rad: you can start "fresh" with v1
[17:58] <nst> might eventually get back to you regarding the S2X things, but "not today" aswell
[17:59] <mchehab> all other patches from you are marked as superseded and were removed from our queue
[17:59] <b-rad> ok
[17:59] <mchehab> nst: yeah, S2X will likely require a few rounds
[17:59] <mchehab> I suggest that you submit first the API bits - let's discuss it first
[18:00] <mchehab> as the caps patch will likely require some care
[18:01] <mchehab> let's hope crope can join us on such discussions... the more the merrier, specially for uAPI
[18:01] <mchehab> once we set the uAPI/docs, the patches themselves should be trivial
[18:01] <mchehab> to modify
[18:02] <nst> mchehab: note that the fe_caps enum currently already misses a few FEC variants, mainly everything after FEC_AUTO from fe_code_rate
[18:02] <mchehab> yes, I know
[18:02] <mchehab> current caps misses *a lot*
[18:02] <nst> for everything else, S2X is not much more than S2, but with a few more modulations, code rates and rolloffs
[18:02] <mchehab> specially for standards like ISDB and DMB
[18:03] <nst> (from what I could gather, that is)
[18:04] <nst> so not sure if a SYS_DVBS2X would really be needed, since there are no additional fancy properties as it seems
[18:04] <mchehab> that's something for discussions
[18:05] <mchehab> but anyway, userspace should be able to know what it supports
[18:05] <nst> yeah.
[18:05] <mchehab> (and dvb_frontend kernel core should be able to validate invalid requests)
[18:06] <mchehab> like returning an error code if userspace requests a new S2X modulation on "pure" S2 devices
[18:07] <mchehab> we need first to agree at API - dvb core improvements is just a desired improvement - once we have a way for the drivers to tell what caps it supports
[18:07] <mchehab> per delivery system type
[18:08] <mchehab> (and/or per property)
[18:08] <mchehab> I suspect that a per-property caps would work fine
[18:08] <nst> shouldn't this already be the case? I mean, AFAIK, if ie. I request FE_CAN_QAM_AUTO when the frontend (demod driver) doesn't has that in it's caps, DVB core already throws an error?
[18:11] <nst> same should apply for the code rates though. if one requests FEC_1_4 from ie stv0910, it'll work, doing the same against stv090x should yield an error
[18:11] <mchehab> no, the dvb core doesn't do much validation
[18:11] <mchehab> it is done at drivers
[18:11] <mchehab> (or not)
[18:12] <nst> rather "or not" supposedly then...
[18:13] <mchehab> in thesis, if the driver can tell the core that property DTV_MODULATION only accepts APSK, the core could return an error code directly, without bothering the driver
[18:13] <mchehab> with would reduce the amount of code at drivers
[18:13] <mchehab> and eliminating sources of troubles
[18:15] <nst> i see. so basically, somewhere around the dvb_register_frontend() step, the core should take note of .caps and act based on that accordingly later on
[18:30] <mchehab> yes, something like that
[18:31] <mchehab> or use some driver callback that would just return the caps - without touching at the hardware - whatever works best
[18:33] <mchehab> that could work better, on devices that support multiple delsys
[18:33] <mchehab> I mean, once a delsys is selected, the caps will be returned and the core can cache the results
[19:24] <b-rad> @mchehab, both series resubmitted
[19:24] <b-rad> I think I got them all covered, and passes compilation
[20:05] <zrafa> Hey, hi, I have an atom tablet (baytrail soc). The camera sensor is a ov2640. I built latest kernel 4.15.5 with atomisp ov2640 drivers as modules
[20:05] <zrafa> But nothing
[20:06] <zrafa> I was waiting to have /dev/video* but the modules loaded did not report anything,and /dev/video files do not exist
[20:06] <zrafa> Some ideas to verify to try? Is is the problem that the drivers are in staging?