Re: [PATCH 0/3] R-Car JPEG Processing Unit
Hi Mikhail, Just one small thing, see below... On 07/21/2015 04:00 AM, Mikhail Ulyanov wrote: > This series of patches contains a driver for the JPEG codec integrated > peripheral found in the Renesas R-Car SoCs and associated DT documentation. > > This series of patches is against the 'master' branch of > linuxtv.org/media_tree.git > > v4l2-compliance -s > > Driver Info: > Driver name : rcar_jpu > Card type : rcar_jpu encoder > Bus info : platform:fe98.jpu > Driver version: 4.2.0 > Capabilities : 0x84204000 > Video Memory-to-Memory Multiplanar > Streaming > Extended Pix Format > Device Capabilities > Device Caps : 0x04204000 > Video Memory-to-Memory Multiplanar > Streaming > Extended Pix Format > > Compliance test for device /dev/video0 (not using libv4l2): > > Required ioctls: > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second video open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > > Debug ioctls: > test VIDIOC_DBG_G/S_REGISTER: OK > test VIDIOC_LOG_STATUS: OK (Not Supported) > > Input ioctls: > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 0 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > test VIDIOC_G/S_EDID: OK (Not Supported) > > Control ioctls: > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK > test VIDIOC_QUERYCTRL: OK > test VIDIOC_G/S_CTRL: OK > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > Standard Controls: 2 Private Controls: 0 > > Format ioctls: > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > test VIDIOC_G/S_PARM: OK (Not Supported) > test VIDIOC_G_FBUF: OK (Not Supported) > test VIDIOC_G_FMT: OK > test VIDIOC_TRY_FMT: OK > test VIDIOC_S_FMT: OK > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > test Cropping: OK (Not Supported) > test Composing: OK (Not Supported) > test Scaling: OK > > Codec ioctls: > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) > test VIDIOC_G_ENC_INDEX: OK (Not Supported) > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) > > Buffer ioctls: > warn: v4l2-test-buffers.cpp(542): VIDIOC_CREATE_BUFS not > supported > warn: v4l2-test-buffers.cpp(542): VIDIOC_CREATE_BUFS not > supported Can you add support for this? There is a v4l2_m2m_ioctl_create_bufs helper function, so all you need to do is stick in that helper and have jpu_queue_setup verify and user fmt->fmt.imagesize as the size if fmt is non-NULL. Please run v4l2-compliance again after it's been added. I plan on reviewing and hopefully making a pull request for this on Friday. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] staging: lirc: sasem: fix whitespace style issue
From: Adi Ratiu checkpatch.pl gives an error on line 188 because it uses more than 8 spaces indentation. This patch converts the 8 spaces to a tab. Signed-off-by: Adi Ratiu --- drivers/staging/media/lirc/lirc_sasem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/lirc/lirc_sasem.c b/drivers/staging/media/lirc/lirc_sasem.c index 8ebee96..c14ca7e 100644 --- a/drivers/staging/media/lirc/lirc_sasem.c +++ b/drivers/staging/media/lirc/lirc_sasem.c @@ -185,7 +185,7 @@ static void deregister_from_lirc(struct sasem_context *context) __func__, retval); else dev_info(&context->dev->dev, -"Deregistered Sasem driver (minor:%d)\n", minor); +"Deregistered Sasem driver (minor:%d)\n", minor); } -- 2.4.6 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Jul 22 04:00:20 CEST 2015 git branch: test git hash: 6727d4fce95586e60922bdaf57b8a0eb99482557 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-51-ga53cea2 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-rc1-i686: OK linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] R-Car JPEG Processing Unit
Hi Mikhail, On Wed, Jul 22, 2015 at 04:19:53AM +0300, Mikhail Ulyanov wrote: > Hi Simon, > > 2015-07-22 3:41 GMT+03:00 Simon Horman : > > Hi Mikhail, > > > > On Tue, Jul 21, 2015 at 05:00:19AM +0300, Mikhail Ulyanov wrote: > >> This series of patches contains a driver for the JPEG codec integrated > >> peripheral found in the Renesas R-Car SoCs and associated DT documentation. > > > > I am wondering if you have any plans to post patches to integrate this > > change on any Reneas boards - by which I mean patches to update dts and/or > > dtsi files. I would be very happy to see such patches submitted for review. > Yes, i have such plans. I suppose it was already (partially)reviewed. > https://www.marc.info/?l=linux-sh&m=140867246726948&w=4 > As soon as driver patches will be accepted i will resubmit this patches. Excellent. Sorry for forgetting about having seen the patch at the URL above. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] R-Car JPEG Processing Unit
Hi Simon, 2015-07-22 3:41 GMT+03:00 Simon Horman : > Hi Mikhail, > > On Tue, Jul 21, 2015 at 05:00:19AM +0300, Mikhail Ulyanov wrote: >> This series of patches contains a driver for the JPEG codec integrated >> peripheral found in the Renesas R-Car SoCs and associated DT documentation. > > I am wondering if you have any plans to post patches to integrate this > change on any Reneas boards - by which I mean patches to update dts and/or > dtsi files. I would be very happy to see such patches submitted for review. Yes, i have such plans. I suppose it was already (partially)reviewed. https://www.marc.info/?l=linux-sh&m=140867246726948&w=4 As soon as driver patches will be accepted i will resubmit this patches. -- W.B.R, Mikhail. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] R-Car JPEG Processing Unit
Hi Mikhail, On Tue, Jul 21, 2015 at 05:00:19AM +0300, Mikhail Ulyanov wrote: > This series of patches contains a driver for the JPEG codec integrated > peripheral found in the Renesas R-Car SoCs and associated DT documentation. I am wondering if you have any plans to post patches to integrate this change on any Reneas boards - by which I mean patches to update dts and/or dtsi files. I would be very happy to see such patches submitted for review. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Op 21-07-15 om 21:00 schreef Steven Toth: On Tue, Jul 21, 2015 at 2:07 PM, Tycho Lürsen wrote: Op 21-07-15 om 18:19 schreef Steven Toth: On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen wrote: Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? No lock, or partial lock. Thanks. That's even worse than expected, given that the patch adjusts the TS interface, and has nothing to do with tuning, lock, rf or signal status. It still feels like something else is going on, some other unexpected race for example. I can't reproduce that behavior, but given that you can Can you please try this? in si2168.c, change: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); to /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 0); ... recompile and retest? Thx. I recompiled and tested with this change (still without saa716x or dvbloopback) with TVheadend and all is well. Going to test this with dvbloopback, and if all goes well with saa716x too. But not today. Regards, Tycho. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] drm/exynos: Convert g2d_userptr_get_dma_addr() to use get_vaddr_frames()
On Sat 18-07-15 12:14:12, Inki Dae wrote:
> On 2015년 07월 17일 19:31, Hans Verkuil wrote:
> > On 07/17/2015 12:29 PM, Inki Dae wrote:
> >> On 2015년 07월 17일 19:20, Hans Verkuil wrote:
> >>> On 07/13/2015 04:55 PM, Jan Kara wrote:
> From: Jan Kara
>
> Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
> This removes the knowledge about vmas and mmap_sem locking from exynos
> driver. Also it fixes a problem that the function has been mapping user
> provided address without holding mmap_sem.
> >>>
> >>> I'd like to see an Ack from one of the exynos drm driver maintainers
> >>> before
> >>> I merge this.
> >>>
> >>> Inki, Marek?
> >>
> >> I already gave Ack but it seems that Jan missed it while updating.
> >>
> >> Anyway,
> >> Acked-by: Inki Dae
> >
> > Thanks!
>
> Oops, sorry. This patch would incur a build warning. Below is my comment.
>
> @@ -456,65 +455,38 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
> drm_device *drm_dev,
> return ERR_PTR(-ENOMEM);
>
> atomic_set(&g2d_userptr->refcount, 1);
> +g2d_userptr->size = size;
>
> start = userptr & PAGE_MASK;
> offset = userptr & ~PAGE_MASK;
> end = PAGE_ALIGN(userptr + size);
> npages = (end - start) >> PAGE_SHIFT;
> -g2d_userptr->npages = npages;
> -
> -pages = drm_calloc_large(npages, sizeof(struct page *));
> -if (!pages) {
> -DRM_ERROR("failed to allocate pages.\n");
> -ret = -ENOMEM;
> +g2d_userptr->vec = frame_vector_create(npages);
> +if (!g2d_userptr->vec)
>
> You would need ret = -EFAULT here. And below is a patch posted already,
> http://www.spinics.net/lists/dri-devel/msg85321.html
The error should IMHO be -ENOMEM because frame_vector_create() fails only
if we fail to allocate the structure. Attached is the updated version of
the patch. Hans, can you please pick this one?
> ps. please, ignore the codes related to build error in the patch.
>
> With the change, Acked-by: Inki Dae
Thanks and sorry for making so many stupid mistakes in the Exynos driver.
Honza
--
Jan Kara
SUSE Labs, CR
>From e1ce3781eb0a3ffe045055f4145bc60ee7b2a6b5 Mon Sep 17 00:00:00 2001
From: Jan Kara
Date: Wed, 4 Dec 2013 14:41:22 +0100
Subject: [PATCH 9/9] drm/exynos: Convert g2d_userptr_get_dma_addr() to use
get_vaddr_frames()
Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
This removes the knowledge about vmas and mmap_sem locking from exynos
driver. Also it fixes a problem that the function has been mapping user
provided address without holding mmap_sem.
Acked-by: Inki Dae
Signed-off-by: Jan Kara
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 89 ++
drivers/gpu/drm/exynos/exynos_drm_gem.c | 97 -
3 files changed, 30 insertions(+), 157 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 43003c4ad80b..b364562dc6c1 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -77,6 +77,7 @@ config DRM_EXYNOS_VIDI
config DRM_EXYNOS_G2D
bool "Exynos DRM G2D"
depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_G2D
+ select FRAME_VECTOR
help
Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 81a250830808..7584834a53c9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -190,10 +190,8 @@ struct g2d_cmdlist_userptr {
dma_addr_t dma_addr;
unsigned long userptr;
unsigned long size;
- struct page **pages;
- unsigned int npages;
+ struct frame_vector *vec;
struct sg_table *sgt;
- struct vm_area_struct *vma;
atomic_t refcount;
bool in_pool;
bool out_of_list;
@@ -363,6 +361,7 @@ static void g2d_userptr_put_dma_addr(struct drm_device *drm_dev,
{
struct g2d_cmdlist_userptr *g2d_userptr =
(struct g2d_cmdlist_userptr *)obj;
+ struct page **pages;
if (!obj)
return;
@@ -382,19 +381,21 @@ out:
exynos_gem_unmap_sgt_from_dma(drm_dev, g2d_userptr->sgt,
DMA_BIDIRECTIONAL);
- exynos_gem_put_pages_to_userptr(g2d_userptr->pages,
- g2d_userptr->npages,
- g2d_userptr->vma);
+ pages = frame_vector_pages(g2d_userptr->vec);
+ if (!IS_ERR(pages)) {
+ int i;
- exynos_gem_put_vma(g2d_userptr->vma);
+ for (i = 0; i < frame_vector_count(g2d_userptr->vec); i++)
+ set_page_dirty_lock(pages[i]);
+ }
+ put_vaddr_frames(g2d_userptr->vec);
+ frame_vector_destroy(g2d_userptr->vec);
if (!g2d_userptr->out_of_list)
list_del_init(&g2d_userptr->list);
sg_free_table(g2d_userptr->sgt);
kfree(g2d_userptr->sgt);
-
-
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Op 21-07-15 om 21:02 schreef Steven Toth: On Tue, Jul 21, 2015 at 2:59 PM, Tycho Lürsen wrote: Op 21-07-15 om 20:07 schreef Tycho Lürsen: Op 21-07-15 om 18:19 schreef Steven Toth: On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen wrote: Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? No lock, or partial lock. I've compiled a 4.2-RC3, this time without support for my TBS 6285 cards (so no saa716x) and without dvbloopback kernel module (so no MythTV) Result with your patch and only DVBSky T982 cards: TVheadend is fine with it. Lock and tune are OK. Going to test some more scenario's, I'll keep you informed. Regards, Tycho Thank you sir. In which case, please disregard my last email relating to changing: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); - Steve I've screwed up, last test was without your patch, sorry. I'll recompile with your suggested change. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Tue, Jul 21, 2015 at 2:59 PM, Tycho Lürsen wrote: > > > Op 21-07-15 om 20:07 schreef Tycho Lürsen: >> >> >> >> Op 21-07-15 om 18:19 schreef Steven Toth: >>> >>> On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen >>> wrote: Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. >>> >>> We have no differences, its Antti's si2168 driver. If Antti doesn't >>> like the approach for tri-stating, he's free to suggest and >>> alternative. I suggested two alternatives yesterday. >>> Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. >>> >>> That's pretty bizarre results, although thank you for testing. :) >>> >>> When you say it can't tune, do you mean the signal does not lock, or >>> that no video appears? >>> >> No lock, or partial lock. > > I've compiled a 4.2-RC3, this time without support for my TBS 6285 cards (so > no saa716x) and without dvbloopback kernel module (so no MythTV) > > > Result with your patch and only DVBSky T982 cards: TVheadend is fine with > it. Lock and tune are OK. > Going to test some more scenario's, I'll keep you informed. > Regards, > Tycho Thank you sir. In which case, please disregard my last email relating to changing: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Tue, Jul 21, 2015 at 2:07 PM, Tycho Lürsen wrote: > > > Op 21-07-15 om 18:19 schreef Steven Toth: >> >> On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen >> wrote: >>> >>> Hi Steven, >>> I was too curious to wait for you and Antti to settle your differences, >>> so I >>> tested again against a 4.2-RC2 >>> I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees >>> the first system in the .delsys line in si2168.c, >>> so when it looks like this: >>> SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 >>> I'm good. >> >> We have no differences, its Antti's si2168 driver. If Antti doesn't >> like the approach for tri-stating, he's free to suggest and >> alternative. I suggested two alternatives yesterday. >> >>> Result: >>> With your patch both MythTV and Tvheadend still can't tune. Without it, >>> everything is ok. >>> >>> I'm not very interested in czap results, only in real use cases. For me >>> that's MythTV, but just to be sure I also tested with TVheadend. >> >> That's pretty bizarre results, although thank you for testing. :) >> >> When you say it can't tune, do you mean the signal does not lock, or >> that no video appears? >> > No lock, or partial lock. Thanks. That's even worse than expected, given that the patch adjusts the TS interface, and has nothing to do with tuning, lock, rf or signal status. It still feels like something else is going on, some other unexpected race for example. I can't reproduce that behavior, but given that you can Can you please try this? in si2168.c, change: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); to /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 0); ... recompile and retest? Thx. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Op 21-07-15 om 20:07 schreef Tycho Lürsen: Op 21-07-15 om 18:19 schreef Steven Toth: On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen wrote: Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? No lock, or partial lock. I've compiled a 4.2-RC3, this time without support for my TBS 6285 cards (so no saa716x) and without dvbloopback kernel module (so no MythTV) Result with your patch and only DVBSky T982 cards: TVheadend is fine with it. Lock and tune are OK. Going to test some more scenario's, I'll keep you informed. Regards, Tycho -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Op 21-07-15 om 18:19 schreef Steven Toth: On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen wrote: Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? No lock, or partial lock. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen wrote: > Hi Steven, > I was too curious to wait for you and Antti to settle your differences, so I > tested again against a 4.2-RC2 > I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees > the first system in the .delsys line in si2168.c, > so when it looks like this: > SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 > I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. > > Result: > With your patch both MythTV and Tvheadend still can't tune. Without it, > everything is ok. > > I'm not very interested in czap results, only in real use cases. For me > that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. Regards, Tycho. Op 20-07-15 om 18:32 schreef Steven Toth: On Mon, Jul 20, 2015 at 12:06 PM, Tycho Lürsen wrote: Hi Steven, I was not aware of the fact that your patch depends on dvb-core as in 4.2-RC2 (and up, I guess) I tested against 3.18.18 and 4.1.2. That might explain the failures. Anyhow, as soon as Antti and you are on the same page regarding this patch, I'll test again against a 4.2-RC>1 Regards, Tycho. Thank you Tycho. I specifically only tested on 4.2, with the entire tree. No attempt was made to backport or otherwise test in environments outside on prior kernels. - Steve -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] tw68: Move PCI vendor and device IDs to pci_ids.h
This commits moves the Intersil/Techwell PCI vendor ID, and
the device IDs for the TW68 PCI video capture cards.
This will allow to support future Intersil/Techwell devices
without duplicating the IDs.
Signed-off-by: Ezequiel Garcia
---
v2:
* Fixed three additional uses of the defines I missed on v1.
drivers/media/pci/tw68/tw68-core.c | 21 +++--
drivers/media/pci/tw68/tw68.h | 16
include/linux/pci_ids.h| 9 +
3 files changed, 20 insertions(+), 26 deletions(-)
diff --git a/drivers/media/pci/tw68/tw68-core.c
b/drivers/media/pci/tw68/tw68-core.c
index c135165..04706cc 100644
--- a/drivers/media/pci/tw68/tw68-core.c
+++ b/drivers/media/pci/tw68/tw68-core.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
@@ -70,13 +71,13 @@ static atomic_t tw68_instance = ATOMIC_INIT(0);
* added under vendor 0x1797 (Techwell Inc.) as subsystem IDs.
*/
static const struct pci_device_id tw68_pci_tbl[] = {
- {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_6800)},
- {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_6801)},
- {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_6804)},
- {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_6816_1)},
- {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_6816_2)},
- {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_6816_3)},
- {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_6816_4)},
+ {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_TECHWELL_6800)},
+ {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_TECHWELL_6801)},
+ {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_TECHWELL_6804)},
+ {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_TECHWELL_6816_1)},
+ {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_TECHWELL_6816_2)},
+ {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_TECHWELL_6816_3)},
+ {PCI_DEVICE(PCI_VENDOR_ID_TECHWELL, PCI_DEVICE_ID_TECHWELL_6816_4)},
{0,}
};
@@ -263,15 +264,15 @@ static int tw68_initdev(struct pci_dev *pci_dev,
}
switch (pci_id->device) {
- case PCI_DEVICE_ID_6800:/* TW6800 */
+ case PCI_DEVICE_ID_TECHWELL_6800: /* TW6800 */
dev->vdecoder = TW6800;
dev->board_virqmask = TW68_VID_INTS;
break;
- case PCI_DEVICE_ID_6801:/* Video decoder for TW6802 */
+ case PCI_DEVICE_ID_TECHWELL_6801: /* Video decoder for TW6802 */
dev->vdecoder = TW6801;
dev->board_virqmask = TW68_VID_INTS | TW68_VID_INTSX;
break;
- case PCI_DEVICE_ID_6804:/* Video decoder for TW6804 */
+ case PCI_DEVICE_ID_TECHWELL_6804: /* Video decoder for TW6804 */
dev->vdecoder = TW6804;
dev->board_virqmask = TW68_VID_INTS | TW68_VID_INTSX;
break;
diff --git a/drivers/media/pci/tw68/tw68.h b/drivers/media/pci/tw68/tw68.h
index 93f2335..ef51e4d 100644
--- a/drivers/media/pci/tw68/tw68.h
+++ b/drivers/media/pci/tw68/tw68.h
@@ -42,22 +42,6 @@
#defineUNSET (-1U)
-/* system vendor and device ID's */
-#definePCI_VENDOR_ID_TECHWELL 0x1797
-#definePCI_DEVICE_ID_6800 0x6800
-#definePCI_DEVICE_ID_6801 0x6801
-#definePCI_DEVICE_ID_AUDIO20x6802
-#definePCI_DEVICE_ID_TS3 0x6803
-#definePCI_DEVICE_ID_6804 0x6804
-#definePCI_DEVICE_ID_AUDIO50x6805
-#definePCI_DEVICE_ID_TS6 0x6806
-
-/* tw6816 based cards */
-#definePCI_DEVICE_ID_6816_1 0x6810
-#definePCI_DEVICE_ID_6816_2 0x6811
-#definePCI_DEVICE_ID_6816_3 0x6812
-#definePCI_DEVICE_ID_6816_4 0x6813
-
#define TW68_NORMS ( \
V4L2_STD_NTSC| V4L2_STD_PAL | V4L2_STD_SECAM| \
V4L2_STD_PAL_M | V4L2_STD_PAL_Nc| V4L2_STD_PAL_60)
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index fcff8f8..d9ba49c 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2332,6 +2332,15 @@
#define PCI_VENDOR_ID_CAVIUM 0x177d
+#define PCI_VENDOR_ID_TECHWELL 0x1797
+#define PCI_DEVICE_ID_TECHWELL_68000x6800
+#define PCI_DEVICE_ID_TECHWELL_68010x6801
+#define PCI_DEVICE_ID_TECHWELL_68040x6804
+#define PCI_DEVICE_ID_TECHWELL_6816_1 0x6810
+#define PCI_DEVICE_ID_TECHWELL_6816_2 0x6811
+#define PCI_DEVICE_ID_TECHWELL_6816_3 0x6812
+#define PCI_DEVICE_ID_TECHWELL_6816_4 0x6813
+
#define PCI_VENDOR_ID_BELKIN 0x1799
#define PCI_DEVICE_ID_BELKIN_F5D7010V7 0x701f
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 14/15] cec: s5p-cec: Add s5p-cec driver
Hello,
On 2015-07-16 15:09, Hans Verkuil wrote:
Marek, Kamil,
On 06/29/15 12:14, Hans Verkuil wrote:
From: Kamil Debski
Add CEC interface driver present in the Samsung Exynos range of
SoCs.
The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/platform/s5p-cec/s5p_cec.c
b/drivers/media/platform/s5p-cec/s5p_cec.c
new file mode 100644
index 000..0f16d00
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/s5p_cec.c
@@ -0,0 +1,283 @@
+/* drivers/media/platform/s5p-cec/s5p_cec.c
+ *
+ * Samsung S5P CEC driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is based on the "cec interface driver for exynos soc" by
+ * SangPil Moon.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "exynos_hdmi_cec.h"
+#include "regs-cec.h"
+#include "s5p_cec.h"
+
+#define CEC_NAME "s5p-cec"
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+static int s5p_cec_enable(struct cec_adapter *adap, bool enable)
+{
+ struct s5p_cec_dev *cec = container_of(adap, struct s5p_cec_dev, adap);
+ int ret;
+
+ if (enable) {
+ ret = pm_runtime_get_sync(cec->dev);
+
+ adap->phys_addr = 0x100b;
This is a bogus physical address. The actual physical address has to be derived
from the EDID that is read by the HDMI transmitter.
I think in the case of this driver it will have to be userspace that assigns
the physical address after reading the EDID from drm/kms?
How did you test this, Kamil?
If I remember correctly, physical address has been derived from EDID in the
userspace (it is available in /sys/class/drm/*) and passed to s5p-cec
driver by
appropriate ioctl.
I don't know what is the reason for the above 'adap->phys_addr = 0x100b'
assignment.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
