Re: [PATCH] au8522: remove duplicate code

Reviewed-by: Devin Heitmueller <dheitmuel...@kernellabs.com> Devin On Tue, May 22, 2018 at 1:09 PM, Gustavo A. R. Silva <gust...@embeddedor.com> wrote: > This code has been there for nine years now, and it has been > working "good enough" since then [1]. > > Re

Re: [PATCH] au8522: remove duplicate code

Reviewed-by: Devin Heitmueller Devin On Tue, May 22, 2018 at 1:09 PM, Gustavo A. R. Silva wrote: > This code has been there for nine years now, and it has been > working "good enough" since then [1]. > > Remove duplicate code by getting rid of the if-else statement. >

Re: [media] duplicate code in media drivers

>> diff -u -p drivers/media/dvb-frontends/au8522_decoder.c >> /tmp/nothing/media/dvb-frontends/au8522_decoder.c >> --- drivers/media/dvb-frontends/au8522_decoder.c >> +++ /tmp/nothing/media/dvb-frontends/au8522_decoder.c >> @@ -280,14 +280,9 @@ static void setup_decoder_defaults(struc >>

Re: [media] duplicate code in media drivers

>> diff -u -p drivers/media/dvb-frontends/au8522_decoder.c >> /tmp/nothing/media/dvb-frontends/au8522_decoder.c >> --- drivers/media/dvb-frontends/au8522_decoder.c >> +++ /tmp/nothing/media/dvb-frontends/au8522_decoder.c >> @@ -280,14 +280,9 @@ static void setup_decoder_defaults(struc >>

Re: [PATCH] Support HVR-1200 analog video as a clone of HVR-1500. Tested, composite and s-video inputs.

On Sun, Sep 17, 2017 at 5:42 PM, Nigel Kettlewell wrote: > I propose the following patch to support Hauppauge HVR-1200 analog video, > nothing more than a clone of HVR-1500. Patch based on Linux 4.9 commit > 69973b830859bc6529a7a0468ba0d80ee5117826 > > I have

Re: [PATCH] Support HVR-1200 analog video as a clone of HVR-1500. Tested, composite and s-video inputs.

On Sun, Sep 17, 2017 at 5:42 PM, Nigel Kettlewell wrote: > I propose the following patch to support Hauppauge HVR-1200 analog video, > nothing more than a clone of HVR-1500. Patch based on Linux 4.9 commit > 69973b830859bc6529a7a0468ba0d80ee5117826 > > I have tested composite and S-Video inputs.

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

>> For what it's worth, I doubt most of the em28xx designs have the >> tvp5150 interrupt request line connected in any way. > > True. But, on embedded hardware, such line may be connected into the > SoC. Actually, from the IGEPv3 expansion diagram: > > >

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

>> For what it's worth, I doubt most of the em28xx designs have the >> tvp5150 interrupt request line connected in any way. > > True. But, on embedded hardware, such line may be connected into the > SoC. Actually, from the IGEPv3 expansion diagram: > > >

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

> Currently, the driver doesn't support (2), because, at the time > I wrote the driver, I didn't find a way to read the interrupts generated > by tvp5150 at em28xx[1], due to the lack of em28xx documentation, > but adding support for it shoudn't be hard. I may eventually do it > when I have some

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

> Currently, the driver doesn't support (2), because, at the time > I wrote the driver, I didn't find a way to read the interrupts generated > by tvp5150 at em28xx[1], due to the lack of em28xx documentation, > but adding support for it shoudn't be hard. I may eventually do it > when I have some

Re: [PATCH v4 7/8] v4l: Add signal lock status to source change events

> OK, but what can the application do with that event? If the glitch didn't > affect the video, then it is pointless. > > If the lock is lost, then normally you loose video as well. If not, then > applications are not interested in the event. What about free running mode (where some decoders

Re: [PATCH v4 7/8] v4l: Add signal lock status to source change events

> OK, but what can the application do with that event? If the glitch didn't > affect the video, then it is pointless. > > If the lock is lost, then normally you loose video as well. If not, then > applications are not interested in the event. What about free running mode (where some decoders

Re: [RFC] v4l2 support for thermopile devices

Hi Matt, > Need some input for the video pixel data types, which the device we > are using (see datasheet links below) is outputting pixel data in > little endian 16-bit of which a 12-bits signed value is used. Does it > make sense to do some basic processing on the data since greyscale is >

Re: [RFC] v4l2 support for thermopile devices

Hi Matt, > Need some input for the video pixel data types, which the device we > are using (see datasheet links below) is outputting pixel data in > little endian 16-bit of which a 12-bits signed value is used. Does it > make sense to do some basic processing on the data since greyscale is >

Re: [PATCH 17/31] media: au0828 video change to use v4l_enable_media_tuner()

Hi Shuah, Mauro, >> Did you test the code when the input is not a tuner, but, instead, >> Composite or S-Video connector, as shown at: >> https://mchehab.fedorapeople.org/mc-next-gen/au0828.png > > I am not sure if I did or not. I can double check this case. > Do you have concerns that this

Re: [PATCH 17/31] media: au0828 video change to use v4l_enable_media_tuner()

Hi Shuah, Mauro, >> Did you test the code when the input is not a tuner, but, instead, >> Composite or S-Video connector, as shown at: >> https://mchehab.fedorapeople.org/mc-next-gen/au0828.png > > I am not sure if I did or not. I can double check this case. > Do you have concerns that this

Re: [PATCH] [media] xc5000: Faster result reporting in xc_load_fw_and_init_tuner()

> Are you interested in a bit of software optimisation for the implementation > of the function "xc_load_fw_and_init_tuner"? To be clear, absolutely none of the code in question is performance sensitive (i.e. saving a couple of extra CPU cycles has no value in this case). Hence given that I'm

Re: [PATCH] [media] xc5000: Faster result reporting in xc_load_fw_and_init_tuner()

> Are you interested in a bit of software optimisation for the implementation > of the function "xc_load_fw_and_init_tuner"? To be clear, absolutely none of the code in question is performance sensitive (i.e. saving a couple of extra CPU cycles has no value in this case). Hence given that I'm

Re: [PATCH] cx231xx: correctly handling failed allocation

On Tue, Dec 29, 2015 at 1:53 PM, Insu Yun wrote: > Since kmalloc can be failed in memory pressure, > if not properly handled, NULL dereference can be happend > > Signed-off-by: Insu Yun > --- > drivers/media/usb/cx231xx/cx231xx-417.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git

Re: [PATCH] cx231xx: correctly handling failed allocation

On Tue, Dec 29, 2015 at 1:53 PM, Insu Yun wrote: > Since kmalloc can be failed in memory pressure, > if not properly handled, NULL dereference can be happend > > Signed-off-by: Insu Yun > --- > drivers/media/usb/cx231xx/cx231xx-417.c | 2 ++ > 1 file

Re: [PATCH v2 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

REBOOT; > - xhci->quirks |= XHCI_AVOID_BEI; > } > if (pdev->vendor == PCI_VENDOR_ID_INTEL && > pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) { > -- > 2.1.0 > Looks good for me to (tested with an HVR-950q on a 2013 Macb

Re: [PATCH v2 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

for me to (tested with an HVR-950q on a 2013 Macbook Pro (Haswell). Tested by: Devin Heitmueller dheitmuel...@kernellabs.com Thanks for your help, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: [PATCH v4] media: au0828 - convert to use videobuf2

Hi Shuah, > TRY_FMT and S_FMT both don't handle invalid pixelformats. Looks like > there is reason behind this based on the comments: > > /* format->fmt.pix.width only support 720 and height 480 */ > if (width != 720) > width = 720; > if (height != 480) >

Re: [PATCH v4] media: au0828 - convert to use videobuf2

Hi Shuah, TRY_FMT and S_FMT both don't handle invalid pixelformats. Looks like there is reason behind this based on the comments: /* format-fmt.pix.width only support 720 and height 480 */ if (width != 720) width = 720; if (height != 480)

Re: [PATCH v3 2/3] media: au0828 - convert to use videobuf2

>> - fh->type = type; >> - fh->dev = dev; >> - v4l2_fh_init(>fh, vdev); >> - filp->private_data = fh; >> + dprintk(1, >> + "%s called std_set %d dev_state %d stream users %d users >> %d\n", >> + __func__, dev->std_set_in_tuner_core,

Re: [PATCH v3 2/3] media: au0828 - convert to use videobuf2

- fh-type = type; - fh-dev = dev; - v4l2_fh_init(fh-fh, vdev); - filp-private_data = fh; + dprintk(1, + %s called std_set %d dev_state %d stream users %d users %d\n, + __func__, dev-std_set_in_tuner_core, dev-dev_state, +

Re: [PATCH v3 3/3] media: au0828 remove video and vbi buffer timeout work-around

> I couldn't reproduce what I was seeing when I did patch v2 series > work. What I noticed was that I was seeing a few too many green screens > and I had to re-tune xawtv when the timeout code is in place. My > thinking was that this timeout handling could be introducing blank > green frames when

Re: [PATCH v3 3/3] media: au0828 remove video and vbi buffer timeout work-around

I couldn't reproduce what I was seeing when I did patch v2 series work. What I noticed was that I was seeing a few too many green screens and I had to re-tune xawtv when the timeout code is in place. My thinking was that this timeout handling could be introducing blank green frames when there

Re: [PATCH v3 3/3] media: au0828 remove video and vbi buffer timeout work-around

Hi Shuah, On Mon, Jan 12, 2015 at 9:56 PM, Shuah Khan wrote: > au0828 does video and vbi buffer timeout handling to prevent > applications such as tvtime from hanging by ensuring that the > video frames continue to be delivered even when the ITU-656 > input isn't receiving any data. This

Re: [PATCH v3 3/3] media: au0828 remove video and vbi buffer timeout work-around

Hi Shuah, On Mon, Jan 12, 2015 at 9:56 PM, Shuah Khan shua...@osg.samsung.com wrote: au0828 does video and vbi buffer timeout handling to prevent applications such as tvtime from hanging by ensuring that the video frames continue to be delivered even when the ITU-656 input isn't receiving any

Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api

> this seems like a feature, not a bug. PulseAudio starts streaming before > clients push any data and likewise keeps sources active even after for some > time after clients stop recording. Closing VLC in your example doesn't > immediately close the ALSA device. look for module-suspend-on-idle in

Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api

this seems like a feature, not a bug. PulseAudio starts streaming before clients push any data and likewise keeps sources active even after for some time after clients stop recording. Closing VLC in your example doesn't immediately close the ALSA device. look for module-suspend-on-idle in your

Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api

> Sorry, I'm not convinced by that. If the device has to be controlled > exclusively, the right position is the open/close. Otherwise, the > program cannot know when it becomes inaccessible out of sudden during > its operation. I can say that I've definitely seen cases where if you configure a

Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api

Sorry, I'm not convinced by that. If the device has to be controlled exclusively, the right position is the open/close. Otherwise, the program cannot know when it becomes inaccessible out of sudden during its operation. I can say that I've definitely seen cases where if you configure a

Re: [PATCH 2/5] media: v4l2-core changes to use media tuner token api

Hello Shuah, >> What about G_INPUT and G_TUNER? Consider the following use case, which is >> entirely legal in the V4L2 API: > > Did you mean G_INPUT and G_STD here? I didn't see G_TUNER mentioned > below in the use-case. It can be either ENUM_INPUT or G_TUNER. Both return status information

Re: [PATCH 2/5] media: v4l2-core changes to use media tuner token api

Hello Shuah, What about G_INPUT and G_TUNER? Consider the following use case, which is entirely legal in the V4L2 API: Did you mean G_INPUT and G_STD here? I didn't see G_TUNER mentioned below in the use-case. It can be either ENUM_INPUT or G_TUNER. Both return status information that

Re: [PATCH 1/4] drivers/base: add managed token devres interfaces

On Mon, May 5, 2014 at 3:36 PM, Tejun Heo wrote: > On Mon, May 05, 2014 at 03:30:34PM -0400, Devin Heitmueller wrote: >> On Mon, May 5, 2014 at 3:26 PM, Tejun Heo wrote: >> > As such, please consider the patches nacked and try to find someone >> > who can shepherd the

Re: [PATCH 1/4] drivers/base: add managed token devres interfaces

Hi Tejun, On Mon, May 5, 2014 at 3:26 PM, Tejun Heo wrote: > As such, please consider the patches nacked and try to find someone > who can shepherd the code. Mauro, can you help out here? We actually discussed this proposal at length at the media summit last week. The patches are being pulled

Re: [PATCH 1/4] drivers/base: add managed token devres interfaces

Hi Tejun, On Mon, May 5, 2014 at 3:26 PM, Tejun Heo t...@kernel.org wrote: As such, please consider the patches nacked and try to find someone who can shepherd the code. Mauro, can you help out here? We actually discussed this proposal at length at the media summit last week. The patches are

Re: [PATCH 1/4] drivers/base: add managed token devres interfaces

On Mon, May 5, 2014 at 3:36 PM, Tejun Heo t...@kernel.org wrote: On Mon, May 05, 2014 at 03:30:34PM -0400, Devin Heitmueller wrote: On Mon, May 5, 2014 at 3:26 PM, Tejun Heo t...@kernel.org wrote: As such, please consider the patches nacked and try to find someone who can shepherd the code

Re: [PATCH 0/3] media/drx39xyj: fix DJH_DEBUG path null pointer dereferences, and compile errors.

On Fri, Feb 28, 2014 at 4:22 PM, Shuah Khan wrote: > This patch series fixes null pointer dereference boot failure as well as > compile errors. Seems kind of strange that I wasn't on the CC for this, since I was the original author of all that code (in fact, DJH are my initials). Mauro, did you

Re: [PATCH 0/3] media/drx39xyj: fix DJH_DEBUG path null pointer dereferences, and compile errors.

On Fri, Feb 28, 2014 at 4:22 PM, Shuah Khan shuah...@samsung.com wrote: This patch series fixes null pointer dereference boot failure as well as compile errors. Seems kind of strange that I wasn't on the CC for this, since I was the original author of all that code (in fact, DJH are my

Re: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19

On Tue, Dec 17, 2013 at 4:09 PM, Antti Palosaari wrote: > That shared DVB / V4L2 tuner is one problem that I have also currently (SDR > is on V4L2 API and DTV is provided via DVB API). I have decided to try model > where I separate RF tuner totally independent used DVB / V4L2 APIs, just to >

Re: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19

On Tue, Dec 17, 2013 at 4:09 PM, Antti Palosaari cr...@iki.fi wrote: That shared DVB / V4L2 tuner is one problem that I have also currently (SDR is on V4L2 API and DTV is provided via DVB API). I have decided to try model where I separate RF tuner totally independent used DVB / V4L2 APIs, just

Re: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19

s well supported and doesn't have this issue as it uses a different chip. > On 14/12/13 05:17 PM, Devin Heitmueller wrote: >> I had a patch kicking around which fixed part of the issue, but it >> didn't completely work because of the lgdt3305 having AGC enabled at >> chi

Re: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19

. The 950q though is well supported and doesn't have this issue as it uses a different chip. On 14/12/13 05:17 PM, Devin Heitmueller wrote: I had a patch kicking around which fixed part of the issue, but it didn't completely work because of the lgdt3305 having AGC enabled at chip powerup (which

Re: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19

> My basic problem is > > __tda18271_write_regs: [1-0060|M] ERROR: idx = 0x0, len = 39, i2c_transfer > returned: -32 > > where it attaches lgdt3305 before tda18271. Do you know a similar patch > that could help me? It's a totally different issue. The problem with the US Exeter has to do with

Re: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19

My basic problem is __tda18271_write_regs: [1-0060|M] ERROR: idx = 0x0, len = 39, i2c_transfer returned: -32 where it attaches lgdt3305 before tda18271. Do you know a similar patch that could help me? It's a totally different issue. The problem with the US Exeter has to do with the

Re: [PATCH 4/4] [media] em28xx: Fix vidioc fmt vid cap v4l2 compliance

On Tue, Jul 16, 2013 at 7:06 PM, Alban Browaeys wrote: > Set fmt.pix.priv to zero in vidioc_g_fmt_vid_cap > and vidioc_try_fmt_vid_cap. Any reason not to have the v4l2 core do this before dispatching to the driver? Set it to zero before the core calls g_fmt. This avoids all the drivers (most

Re: [PATCH 4/4] [media] em28xx: Fix vidioc fmt vid cap v4l2 compliance

On Tue, Jul 16, 2013 at 7:06 PM, Alban Browaeys alban.browa...@gmail.com wrote: Set fmt.pix.priv to zero in vidioc_g_fmt_vid_cap and vidioc_try_fmt_vid_cap. Any reason not to have the v4l2 core do this before dispatching to the driver? Set it to zero before the core calls g_fmt. This avoids

Re: [PATCH] xc5000: Add MODULE_FIRMWARE statements

On Wed, Jul 25, 2012 at 9:43 AM, Tim Gardner wrote: > Devin - Please have a closer look. XC5000A_FIRMWARE and XC5000C_FIRMWARE > are defined in the patch. Yup, my bad. I looked at the patch twice but for some reason didn't see the #define. I'm not really taking a position on whether this

Re: [PATCH] xc5000: Add MODULE_FIRMWARE statements

On Wed, Jul 25, 2012 at 9:15 AM, Tim Gardner wrote: > This will make modinfo more useful with regard > to discovering necessary firmware files. > > Cc: Mauro Carvalho Chehab > Cc: Michael Krufky > Cc: Eddi De Pieri > Cc: linux-me...@vger.kernel.org > Signed-off-by: Tim Gardner > --- >

Re: [PATCH] xc5000: Add MODULE_FIRMWARE statements

On Wed, Jul 25, 2012 at 9:15 AM, Tim Gardner tim.gard...@canonical.com wrote: This will make modinfo more useful with regard to discovering necessary firmware files. Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Michael Krufky mkru...@kernellabs.com Cc: Eddi De Pieri e...@depieri.net

Re: [PATCH] xc5000: Add MODULE_FIRMWARE statements

On Wed, Jul 25, 2012 at 9:43 AM, Tim Gardner tim.gard...@canonical.com wrote: Devin - Please have a closer look. XC5000A_FIRMWARE and XC5000C_FIRMWARE are defined in the patch. Yup, my bad. I looked at the patch twice but for some reason didn't see the #define. I'm not really taking a

e1000 driver and interrupt registration

netdev->base_addr = adapter->hw.io_base; Thanks in advance, -- Devin Heitmueller Senior Software Engineer AEP Networks, Inc. (formerly Netilla) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More m

e1000 driver and interrupt registration

; Thanks in advance, -- Devin Heitmueller Senior Software Engineer AEP Networks, Inc. (formerly Netilla) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read