Re: [RESEND PATCH 3/7] mm/gup: Change GUP fast to use flags rather than a write 'bool'
Hi Ira
Martin and I looked at your patch and agree that it doesn't change
functionality for Orangefs.
Reviewed-by: Mike Marshall
On Wed, Feb 20, 2019 at 12:32 AM wrote:
>
> From: Ira Weiny
>
> To facilitate additional options to get_user_pages_fast() change the
> singular write parameter to be gup_flags.
>
> This patch does not change any functionality. New functionality will
> follow in subsequent patches.
>
> Some of the get_user_pages_fast() call sites were unchanged because they
> already passed FOLL_WRITE or 0 for the write parameter.
>
> Signed-off-by: Ira Weiny
> ---
> arch/mips/mm/gup.c | 11 ++-
> arch/powerpc/kvm/book3s_64_mmu_hv.c| 4 ++--
> arch/powerpc/kvm/e500_mmu.c| 2 +-
> arch/powerpc/mm/mmu_context_iommu.c| 4 ++--
> arch/s390/kvm/interrupt.c | 2 +-
> arch/s390/mm/gup.c | 12 ++--
> arch/sh/mm/gup.c | 11 ++-
> arch/sparc/mm/gup.c| 9 +
> arch/x86/kvm/paging_tmpl.h | 2 +-
> arch/x86/kvm/svm.c | 2 +-
> drivers/fpga/dfl-afu-dma-region.c | 2 +-
> drivers/gpu/drm/via/via_dmablit.c | 3 ++-
> drivers/infiniband/hw/hfi1/user_pages.c| 3 ++-
> drivers/misc/genwqe/card_utils.c | 2 +-
> drivers/misc/vmw_vmci/vmci_host.c | 2 +-
> drivers/misc/vmw_vmci/vmci_queue_pair.c| 6 --
> drivers/platform/goldfish/goldfish_pipe.c | 3 ++-
> drivers/rapidio/devices/rio_mport_cdev.c | 4 +++-
> drivers/sbus/char/oradax.c | 2 +-
> drivers/scsi/st.c | 3 ++-
> drivers/staging/gasket/gasket_page_table.c | 4 ++--
> drivers/tee/tee_shm.c | 2 +-
> drivers/vfio/vfio_iommu_spapr_tce.c| 3 ++-
> drivers/vhost/vhost.c | 2 +-
> drivers/video/fbdev/pvr2fb.c | 2 +-
> drivers/virt/fsl_hypervisor.c | 2 +-
> drivers/xen/gntdev.c | 2 +-
> fs/orangefs/orangefs-bufmap.c | 2 +-
> include/linux/mm.h | 4 ++--
> kernel/futex.c | 2 +-
> lib/iov_iter.c | 7 +--
> mm/gup.c | 10 +-
> mm/util.c | 8
> net/ceph/pagevec.c | 2 +-
> net/rds/info.c | 2 +-
> net/rds/rdma.c | 3 ++-
> 36 files changed, 81 insertions(+), 65 deletions(-)
>
> diff --git a/arch/mips/mm/gup.c b/arch/mips/mm/gup.c
> index 0d14e0d8eacf..4c2b4483683c 100644
> --- a/arch/mips/mm/gup.c
> +++ b/arch/mips/mm/gup.c
> @@ -235,7 +235,7 @@ int __get_user_pages_fast(unsigned long start, int
> nr_pages, int write,
> * get_user_pages_fast() - pin user pages in memory
> * @start: starting user address
> * @nr_pages: number of pages from start to pin
> - * @write: whether pages will be written to
> + * @gup_flags: flags modifying pin behaviour
> * @pages: array that receives pointers to the pages pinned.
> * Should be at least nr_pages long.
> *
> @@ -247,8 +247,8 @@ int __get_user_pages_fast(unsigned long start, int
> nr_pages, int write,
> * requested. If nr_pages is 0 or negative, returns 0. If no pages
> * were pinned, returns -errno.
> */
> -int get_user_pages_fast(unsigned long start, int nr_pages, int write,
> - struct page **pages)
> +int get_user_pages_fast(unsigned long start, int nr_pages,
> + unsigned int gup_flags, struct page **pages)
> {
> struct mm_struct *mm = current->mm;
> unsigned long addr, len, end;
> @@ -273,7 +273,8 @@ int get_user_pages_fast(unsigned long start, int
> nr_pages, int write,
> next = pgd_addr_end(addr, end);
> if (pgd_none(pgd))
> goto slow;
> - if (!gup_pud_range(pgd, addr, next, write, pages, &nr))
> + if (!gup_pud_range(pgd, addr, next, gup_flags & FOLL_WRITE,
> + pages, &nr))
> goto slow;
> } while (pgdp++, addr = next, addr != end);
> local_irq_enable();
> @@ -289,7 +290,7 @@ int get_user_pages_fast(unsigned long start, int
> nr_pages, int write,
> pages += nr;
>
> ret = get_user_pages_unlocked(start, (end - start) >> PAGE_SHIFT,
> - pages, write ? FOLL_WRITE : 0);
> +
Re: [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API
On Thu, Feb 07, 2019 at 09:37:08PM +0530, Souptick Joarder wrote: > On Thu, Feb 7, 2019 at 9:27 PM Mike Rapoport wrote: > > > > Hi Souptick, > > > > On Thu, Feb 07, 2019 at 09:19:47PM +0530, Souptick Joarder wrote: > > > Hi Mike, > > > > > > Just thought to take opinion for documentation before placing it in v3. > > > Does it looks fine ? > > > > Overall looks good to me. Several minor points below. > > Thanks Mike. Noted. > Shall I consider it as *Reviewed-by:* with below changes ? Yeah, sure. > > > > > +/** > > > + * __vm_insert_range - insert range of kernel pages into user vma > > > + * @vma: user vma to map to > > > + * @pages: pointer to array of source kernel pages > > > + * @num: number of pages in page array > > > + * @offset: user's requested vm_pgoff > > > + * > > > + * This allow drivers to insert range of kernel pages into a user vma. > > > > allows > > > + * > > > + * Return: 0 on success and error code otherwise. > > > + */ > > > +static int __vm_insert_range(struct vm_area_struct *vma, struct page > > > **pages, > > > + unsigned long num, unsigned long offset) > > > > > > > > > +/** > > > + * vm_insert_range - insert range of kernel pages starts with non zero > > > offset > > > + * @vma: user vma to map to > > > + * @pages: pointer to array of source kernel pages > > > + * @num: number of pages in page array > > > + * > > > + * Maps an object consisting of `num' `pages', catering for the user's > >@num pages > > > + * requested vm_pgoff > > > + * > > > + * If we fail to insert any page into the vma, the function will return > > > + * immediately leaving any previously inserted pages present. Callers > > > + * from the mmap handler may immediately return the error as their caller > > > + * will destroy the vma, removing any successfully inserted pages. Other > > > + * callers should make their own arrangements for calling unmap_region(). > > > + * > > > + * Context: Process context. Called by mmap handlers. > > > + * Return: 0 on success and error code otherwise. > > > + */ > > > +int vm_insert_range(struct vm_area_struct *vma, struct page **pages, > > > + unsigned long num) > > > > > > > > > +/** > > > + * vm_insert_range_buggy - insert range of kernel pages starts with zero > > > offset > > > + * @vma: user vma to map to > > > + * @pages: pointer to array of source kernel pages > > > + * @num: number of pages in page array > > > + * > > > + * Similar to vm_insert_range(), except that it explicitly sets > > > @vm_pgoff to > > > > the offset > > > > > + * 0. This function is intended for the drivers that did not consider > > > + * @vm_pgoff. > > > + * > > > + * Context: Process context. Called by mmap handlers. > > > + * Return: 0 on success and error code otherwise. > > > + */ > > > +int vm_insert_range_buggy(struct vm_area_struct *vma, struct page > > > **pages, > > > + unsigned long num) > > > > > > > -- > > Sincerely yours, > > Mike. > > > -- Sincerely yours, Mike.
Re: [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API
Hi Souptick, On Thu, Feb 07, 2019 at 09:19:47PM +0530, Souptick Joarder wrote: > Hi Mike, > > Just thought to take opinion for documentation before placing it in v3. > Does it looks fine ? Overall looks good to me. Several minor points below. > +/** > + * __vm_insert_range - insert range of kernel pages into user vma > + * @vma: user vma to map to > + * @pages: pointer to array of source kernel pages > + * @num: number of pages in page array > + * @offset: user's requested vm_pgoff > + * > + * This allow drivers to insert range of kernel pages into a user vma. allows > + * > + * Return: 0 on success and error code otherwise. > + */ > +static int __vm_insert_range(struct vm_area_struct *vma, struct page **pages, > + unsigned long num, unsigned long offset) > > > +/** > + * vm_insert_range - insert range of kernel pages starts with non zero offset > + * @vma: user vma to map to > + * @pages: pointer to array of source kernel pages > + * @num: number of pages in page array > + * > + * Maps an object consisting of `num' `pages', catering for the user's @num pages > + * requested vm_pgoff > + * > + * If we fail to insert any page into the vma, the function will return > + * immediately leaving any previously inserted pages present. Callers > + * from the mmap handler may immediately return the error as their caller > + * will destroy the vma, removing any successfully inserted pages. Other > + * callers should make their own arrangements for calling unmap_region(). > + * > + * Context: Process context. Called by mmap handlers. > + * Return: 0 on success and error code otherwise. > + */ > +int vm_insert_range(struct vm_area_struct *vma, struct page **pages, > + unsigned long num) > > > +/** > + * vm_insert_range_buggy - insert range of kernel pages starts with zero > offset > + * @vma: user vma to map to > + * @pages: pointer to array of source kernel pages > + * @num: number of pages in page array > + * > + * Similar to vm_insert_range(), except that it explicitly sets @vm_pgoff to the offset > + * 0. This function is intended for the drivers that did not consider > + * @vm_pgoff. > + * > + * Context: Process context. Called by mmap handlers. > + * Return: 0 on success and error code otherwise. > + */ > +int vm_insert_range_buggy(struct vm_area_struct *vma, struct page **pages, > + unsigned long num) > -- Sincerely yours, Mike.
Re: [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API
On Thu, Jan 31, 2019 at 03:43:39PM +0530, Souptick Joarder wrote:
> On Thu, Jan 31, 2019 at 2:09 PM Mike Rapoport wrote:
> >
> > On Thu, Jan 31, 2019 at 08:38:12AM +0530, Souptick Joarder wrote:
> > > Previouly drivers have their own way of mapping range of
> > > kernel pages/memory into user vma and this was done by
> > > invoking vm_insert_page() within a loop.
> > >
> > > As this pattern is common across different drivers, it can
> > > be generalized by creating new functions and use it across
> > > the drivers.
> > >
> > > vm_insert_range() is the API which could be used to mapped
> > > kernel memory/pages in drivers which has considered vm_pgoff
> > >
> > > vm_insert_range_buggy() is the API which could be used to map
> > > range of kernel memory/pages in drivers which has not considered
> > > vm_pgoff. vm_pgoff is passed default as 0 for those drivers.
> > >
> > > We _could_ then at a later "fix" these drivers which are using
> > > vm_insert_range_buggy() to behave according to the normal vm_pgoff
> > > offsetting simply by removing the _buggy suffix on the function
> > > name and if that causes regressions, it gives us an easy way to revert.
> > >
> > > Signed-off-by: Souptick Joarder
> > > Suggested-by: Russell King
> > > Suggested-by: Matthew Wilcox
> > > ---
> > > include/linux/mm.h | 4 +++
> > > mm/memory.c| 81
> > > ++
> > > mm/nommu.c | 14 ++
> > > 3 files changed, 99 insertions(+)
> > >
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index 80bb640..25752b0 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -2565,6 +2565,10 @@ unsigned long change_prot_numa(struct
> > > vm_area_struct *vma,
> > > int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
> > > unsigned long pfn, unsigned long size, pgprot_t);
> > > int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct
> > > page *);
> > > +int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
> > > + unsigned long num);
> > > +int vm_insert_range_buggy(struct vm_area_struct *vma, struct page
> > > **pages,
> > > + unsigned long num);
> > > vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> > > unsigned long pfn);
> > > vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long
> > > addr,
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index e11ca9d..0a4bf57 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -1520,6 +1520,87 @@ int vm_insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > > EXPORT_SYMBOL(vm_insert_page);
> > >
> > > +/**
> > > + * __vm_insert_range - insert range of kernel pages into user vma
> > > + * @vma: user vma to map to
> > > + * @pages: pointer to array of source kernel pages
> > > + * @num: number of pages in page array
> > > + * @offset: user's requested vm_pgoff
> > > + *
> > > + * This allows drivers to insert range of kernel pages they've allocated
> > > + * into a user vma.
> > > + *
> > > + * If we fail to insert any page into the vma, the function will return
> > > + * immediately leaving any previously inserted pages present. Callers
> > > + * from the mmap handler may immediately return the error as their caller
> > > + * will destroy the vma, removing any successfully inserted pages. Other
> > > + * callers should make their own arrangements for calling unmap_region().
> > > + *
> > > + * Context: Process context.
> > > + * Return: 0 on success and error code otherwise.
> > > + */
> > > +static int __vm_insert_range(struct vm_area_struct *vma, struct page
> > > **pages,
> > > + unsigned long num, unsigned long offset)
> > > +{
> > > + unsigned long count = vma_pages(vma);
> > > + unsigned long uaddr = vma->vm_start;
> > > + int ret, i;
> > > +
> > > + /* Fail if the user requested offset is beyond the end of the
> > > object */
> > > + if (offset > num)
> > > +
Re: [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API
uccess and error code otherwise.
> + */
> +int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
> + unsigned long num)
> +{
> + return __vm_insert_range(vma, pages, num, vma->vm_pgoff);
> +}
> +EXPORT_SYMBOL(vm_insert_range);
> +
> +/**
> + * vm_insert_range_buggy - insert range of kernel pages starts with zero
> offset
> + * @vma: user vma to map to
> + * @pages: pointer to array of source kernel pages
> + * @num: number of pages in page array
> + *
> + * Maps a set of pages, always starting at page[0]
Here I'd add something like:
Similar to vm_insert_range(), except that it explicitly sets @vm_pgoff to
0. This function is intended for the drivers that did not consider
@vm_pgoff.
> vm_insert_range_buggy() is the API which could be used to map
> range of kernel memory/pages in drivers which has not considered
> vm_pgoff. vm_pgoff is passed default as 0 for those drivers.
> + *
> + * Context: Process context. Called by mmap handlers.
> + * Return: 0 on success and error code otherwise.
> + */
> +int vm_insert_range_buggy(struct vm_area_struct *vma, struct page **pages,
> + unsigned long num)
> +{
> + return __vm_insert_range(vma, pages, num, 0);
> +}
> +EXPORT_SYMBOL(vm_insert_range_buggy);
> +
> static vm_fault_t insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> pfn_t pfn, pgprot_t prot, bool mkwrite)
> {
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 749276b..21d101e 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -473,6 +473,20 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned
> long addr,
> }
> EXPORT_SYMBOL(vm_insert_page);
>
> +int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
> + unsigned long num)
> +{
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(vm_insert_range);
> +
> +int vm_insert_range_buggy(struct vm_area_struct *vma, struct page **pages,
> + unsigned long num)
> +{
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(vm_insert_range_buggy);
> +
> /*
> * sys_brk() for the most part doesn't need the global kernel
> * lock, except when an application is doing something nasty
> --
> 1.9.1
>
--
Sincerely yours,
Mike.
Re: [PATCH v2 1/9] mm: Introduce new vm_insert_range API
On Mon, Dec 03, 2018 at 09:51:45AM +0530, Souptick Joarder wrote:
> Hi Mike,
>
> On Sun, Dec 2, 2018 at 4:43 PM Mike Rapoport wrote:
> >
> > On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> > > Previouly drivers have their own way of mapping range of
> > > kernel pages/memory into user vma and this was done by
> > > invoking vm_insert_page() within a loop.
> > >
> > > As this pattern is common across different drivers, it can
> > > be generalized by creating a new function and use it across
> > > the drivers.
> > >
> > > vm_insert_range is the new API which will be used to map a
> > > range of kernel memory/pages to user vma.
> > >
> > > This API is tested by Heiko for Rockchip drm driver, on rk3188,
> > > rk3288, rk3328 and rk3399 with graphics.
> > >
> > > Signed-off-by: Souptick Joarder
> > > Reviewed-by: Matthew Wilcox
> > > Tested-by: Heiko Stuebner
> > > ---
> > > include/linux/mm_types.h | 3 +++
> > > mm/memory.c | 38 ++
> > > mm/nommu.c | 7 +++
> > > 3 files changed, 48 insertions(+)
> > >
> > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > > index 5ed8f62..15ae24f 100644
> > > --- a/include/linux/mm_types.h
> > > +++ b/include/linux/mm_types.h
> > > @@ -523,6 +523,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb,
> > > struct mm_struct *mm,
> > > extern void tlb_finish_mmu(struct mmu_gather *tlb,
> > > unsigned long start, unsigned long end);
> > >
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count);
> > > +
> >
> > This seem to belong to include/linux/mm.h, near vm_insert_page()
>
> Ok, I will change it. Apart from this change does it looks good ?
With this change you can add
Reviewed-by: Mike Rapoport
> >
> > > static inline void init_tlb_flush_pending(struct mm_struct *mm)
> > > {
> > > atomic_set(&mm->tlb_flush_pending, 0);
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 15c417e..84ea46c 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -1478,6 +1478,44 @@ static int insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > >
> > > /**
> > > + * vm_insert_range - insert range of kernel pages into user vma
> > > + * @vma: user vma to map to
> > > + * @addr: target user address of this page
> > > + * @pages: pointer to array of source kernel pages
> > > + * @page_count: number of pages need to insert into user vma
> > > + *
> > > + * This allows drivers to insert range of kernel pages they've allocated
> > > + * into a user vma. This is a generic function which drivers can use
> > > + * rather than using their own way of mapping range of kernel pages into
> > > + * user vma.
> > > + *
> > > + * If we fail to insert any page into the vma, the function will return
> > > + * immediately leaving any previously-inserted pages present. Callers
> > > + * from the mmap handler may immediately return the error as their caller
> > > + * will destroy the vma, removing any successfully-inserted pages. Other
> > > + * callers should make their own arrangements for calling unmap_region().
> > > + *
> > > + * Context: Process context. Called by mmap handlers.
> > > + * Return: 0 on success and error code otherwise
> > > + */
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + unsigned long uaddr = addr;
> > > + int ret = 0, i;
> > > +
> > > + for (i = 0; i < page_count; i++) {
> > > + ret = vm_insert_page(vma, uaddr, pages[i]);
> > > + if (ret < 0)
> > > + return ret;
> > > + uaddr += PAGE_SIZE;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL(vm_insert_range);
> > > +
> > > +/**
> > > * vm_insert_page - insert single page into user vma
> > > * @vma: user vma to map to
> > > * @addr: target user address of this page
> > > diff --git a/mm/nommu.c b/mm/nommu.c
> > > index 749276b..d6ef5c7 100644
> > > --- a/mm/nommu.c
> > > +++ b/mm/nommu.c
> > > @@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > > EXPORT_SYMBOL(vm_insert_page);
> > >
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + return -EINVAL;
> > > +}
> > > +EXPORT_SYMBOL(vm_insert_range);
> > > +
> > > /*
> > > * sys_brk() for the most part doesn't need the global kernel
> > > * lock, except when an application is doing something nasty
> > > --
> > > 1.9.1
> > >
> >
> > --
> > Sincerely yours,
> > Mike.
> >
>
--
Sincerely yours,
Mike.
Re: [PATCH v2 1/9] mm: Introduce new vm_insert_range API
On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized by creating a new function and use it across
> the drivers.
>
> vm_insert_range is the new API which will be used to map a
> range of kernel memory/pages to user vma.
>
> This API is tested by Heiko for Rockchip drm driver, on rk3188,
> rk3288, rk3328 and rk3399 with graphics.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
> Tested-by: Heiko Stuebner
> ---
> include/linux/mm_types.h | 3 +++
> mm/memory.c | 38 ++
> mm/nommu.c | 7 +++
> 3 files changed, 48 insertions(+)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 5ed8f62..15ae24f 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -523,6 +523,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb, struct
> mm_struct *mm,
> extern void tlb_finish_mmu(struct mmu_gather *tlb,
> unsigned long start, unsigned long end);
>
> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> + struct page **pages, unsigned long page_count);
> +
This seem to belong to include/linux/mm.h, near vm_insert_page()
> static inline void init_tlb_flush_pending(struct mm_struct *mm)
> {
> atomic_set(&mm->tlb_flush_pending, 0);
> diff --git a/mm/memory.c b/mm/memory.c
> index 15c417e..84ea46c 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1478,6 +1478,44 @@ static int insert_page(struct vm_area_struct *vma,
> unsigned long addr,
> }
>
> /**
> + * vm_insert_range - insert range of kernel pages into user vma
> + * @vma: user vma to map to
> + * @addr: target user address of this page
> + * @pages: pointer to array of source kernel pages
> + * @page_count: number of pages need to insert into user vma
> + *
> + * This allows drivers to insert range of kernel pages they've allocated
> + * into a user vma. This is a generic function which drivers can use
> + * rather than using their own way of mapping range of kernel pages into
> + * user vma.
> + *
> + * If we fail to insert any page into the vma, the function will return
> + * immediately leaving any previously-inserted pages present. Callers
> + * from the mmap handler may immediately return the error as their caller
> + * will destroy the vma, removing any successfully-inserted pages. Other
> + * callers should make their own arrangements for calling unmap_region().
> + *
> + * Context: Process context. Called by mmap handlers.
> + * Return: 0 on success and error code otherwise
> + */
> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> + struct page **pages, unsigned long page_count)
> +{
> + unsigned long uaddr = addr;
> + int ret = 0, i;
> +
> + for (i = 0; i < page_count; i++) {
> + ret = vm_insert_page(vma, uaddr, pages[i]);
> + if (ret < 0)
> + return ret;
> + uaddr += PAGE_SIZE;
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(vm_insert_range);
> +
> +/**
> * vm_insert_page - insert single page into user vma
> * @vma: user vma to map to
> * @addr: target user address of this page
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 749276b..d6ef5c7 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned
> long addr,
> }
> EXPORT_SYMBOL(vm_insert_page);
>
> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> + struct page **pages, unsigned long page_count)
> +{
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(vm_insert_range);
> +
> /*
> * sys_brk() for the most part doesn't need the global kernel
> * lock, except when an application is doing something nasty
> --
> 1.9.1
>
--
Sincerely yours,
Mike.
Re: [PATCH 1/9] mm: Introduce new vm_insert_range API
On Mon, Nov 19, 2018 at 11:15:15PM +0530, Souptick Joarder wrote: > On Mon, Nov 19, 2018 at 9:56 PM Mike Rapoport wrote: > > > > On Mon, Nov 19, 2018 at 08:43:09PM +0530, Souptick Joarder wrote: > > > Hi Mike, > > > > > > On Sat, Nov 17, 2018 at 8:07 PM Matthew Wilcox > > > wrote: > > > > > > > > On Sat, Nov 17, 2018 at 12:26:38PM +0530, Souptick Joarder wrote: > > > > > On Fri, Nov 16, 2018 at 11:59 PM Mike Rapoport > > > > > wrote: > > > > > > > + * vm_insert_range - insert range of kernel pages into user vma > > > > > > > + * @vma: user vma to map to > > > > > > > + * @addr: target user address of this page > > > > > > > + * @pages: pointer to array of source kernel pages > > > > > > > + * @page_count: no. of pages need to insert into user vma > > > > > > > + * > > > > > > > + * This allows drivers to insert range of kernel pages they've > > > > > > > allocated > > > > > > > + * into a user vma. This is a generic function which drivers can > > > > > > > use > > > > > > > + * rather than using their own way of mapping range of kernel > > > > > > > pages into > > > > > > > + * user vma. > > > > > > > > > > > > Please add the return value and context descriptions. > > > > > > > > > > > > > > > > Sure I will wait for some time to get additional review comments and > > > > > add all of those requested changes in v2. > > > > > > > > You could send your proposed wording now which might remove the need > > > > for a v3 if we end up arguing about the wording. > > > > > > Does this description looks good ? > > > > > > /** > > > * vm_insert_range - insert range of kernel pages into user vma > > > * @vma: user vma to map to > > > * @addr: target user address of this page > > > * @pages: pointer to array of source kernel pages > > > * @page_count: number of pages need to insert into user vma > > > * > > > * This allows drivers to insert range of kernel pages they've allocated > > > * into a user vma. This is a generic function which drivers can use > > > * rather than using their own way of mapping range of kernel pages into > > > * user vma. > > > * > > > * Context - Process context. Called by mmap handlers. > > > > Context: > > > > > * Return - int error value > > > > Return: > > > > > * 0- OK > > > * -EINVAL - Invalid argument > > > * -ENOMEM - No memory > > > * -EFAULT - Bad address > > > * -EBUSY - Device or resource busy > > > > I don't think that elaborate description of error values is needed, just "0 > > on success and error code otherwise" would be sufficient. > > /** > * vm_insert_range - insert range of kernel pages into user vma > * @vma: user vma to map to > * @addr: target user address of this page > * @pages: pointer to array of source kernel pages > * @page_count: number of pages need to insert into user vma > * > * This allows drivers to insert range of kernel pages they've allocated > * into a user vma. This is a generic function which drivers can use > * rather than using their own way of mapping range of kernel pages into > * user vma. > * > * Context: Process context. Called by mmap handlers. > * Return: 0 on success and error code otherwise > */ Looks good to me. -- Sincerely yours, Mike.
Re: [PATCH 1/9] mm: Introduce new vm_insert_range API
On Mon, Nov 19, 2018 at 08:43:09PM +0530, Souptick Joarder wrote: > Hi Mike, > > On Sat, Nov 17, 2018 at 8:07 PM Matthew Wilcox wrote: > > > > On Sat, Nov 17, 2018 at 12:26:38PM +0530, Souptick Joarder wrote: > > > On Fri, Nov 16, 2018 at 11:59 PM Mike Rapoport wrote: > > > > > + * vm_insert_range - insert range of kernel pages into user vma > > > > > + * @vma: user vma to map to > > > > > + * @addr: target user address of this page > > > > > + * @pages: pointer to array of source kernel pages > > > > > + * @page_count: no. of pages need to insert into user vma > > > > > + * > > > > > + * This allows drivers to insert range of kernel pages they've > > > > > allocated > > > > > + * into a user vma. This is a generic function which drivers can use > > > > > + * rather than using their own way of mapping range of kernel pages > > > > > into > > > > > + * user vma. > > > > > > > > Please add the return value and context descriptions. > > > > > > > > > > Sure I will wait for some time to get additional review comments and > > > add all of those requested changes in v2. > > > > You could send your proposed wording now which might remove the need > > for a v3 if we end up arguing about the wording. > > Does this description looks good ? > > /** > * vm_insert_range - insert range of kernel pages into user vma > * @vma: user vma to map to > * @addr: target user address of this page > * @pages: pointer to array of source kernel pages > * @page_count: number of pages need to insert into user vma > * > * This allows drivers to insert range of kernel pages they've allocated > * into a user vma. This is a generic function which drivers can use > * rather than using their own way of mapping range of kernel pages into > * user vma. > * > * Context - Process context. Called by mmap handlers. Context: > * Return - int error value Return: > * 0- OK > * -EINVAL - Invalid argument > * -ENOMEM - No memory > * -EFAULT - Bad address > * -EBUSY - Device or resource busy I don't think that elaborate description of error values is needed, just "0 on success and error code otherwise" would be sufficient. > */ > -- Sincerely yours, Mike.
Re: [PATCH 1/9] mm: Introduce new vm_insert_range API
On Thu, Nov 15, 2018 at 09:15:30PM +0530, Souptick Joarder wrote:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized by creating a new function and use it across
> the drivers.
>
> vm_insert_range is the new API which will be used to map a
> range of kernel memory/pages to user vma.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
> ---
> include/linux/mm_types.h | 3 +++
> mm/memory.c | 28
> mm/nommu.c | 7 +++
> 3 files changed, 38 insertions(+)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 5ed8f62..15ae24f 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -523,6 +523,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb, struct
> mm_struct *mm,
> extern void tlb_finish_mmu(struct mmu_gather *tlb,
> unsigned long start, unsigned long end);
>
> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> + struct page **pages, unsigned long page_count);
> +
> static inline void init_tlb_flush_pending(struct mm_struct *mm)
> {
> atomic_set(&mm->tlb_flush_pending, 0);
> diff --git a/mm/memory.c b/mm/memory.c
> index 15c417e..da904ed 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1478,6 +1478,34 @@ static int insert_page(struct vm_area_struct *vma,
> unsigned long addr,
> }
>
> /**
> + * vm_insert_range - insert range of kernel pages into user vma
> + * @vma: user vma to map to
> + * @addr: target user address of this page
> + * @pages: pointer to array of source kernel pages
> + * @page_count: no. of pages need to insert into user vma
> + *
> + * This allows drivers to insert range of kernel pages they've allocated
> + * into a user vma. This is a generic function which drivers can use
> + * rather than using their own way of mapping range of kernel pages into
> + * user vma.
Please add the return value and context descriptions.
> + */
> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> + struct page **pages, unsigned long page_count)
> +{
> + unsigned long uaddr = addr;
> + int ret = 0, i;
> +
> + for (i = 0; i < page_count; i++) {
> + ret = vm_insert_page(vma, uaddr, pages[i]);
> + if (ret < 0)
> + return ret;
> + uaddr += PAGE_SIZE;
> + }
> +
> + return ret;
> +}
> +
> +/**
> * vm_insert_page - insert single page into user vma
> * @vma: user vma to map to
> * @addr: target user address of this page
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 749276b..d6ef5c7 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned
> long addr,
> }
> EXPORT_SYMBOL(vm_insert_page);
>
> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> + struct page **pages, unsigned long page_count)
> +{
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(vm_insert_range);
> +
> /*
> * sys_brk() for the most part doesn't need the global kernel
> * lock, except when an application is doing something nasty
> --
> 1.9.1
>
--
Sincerely yours,
Mike.
ITE IT9303FN: af9035_ctrl_msg: command=2b failed fw error=21
Hi guys, I'm not sure if this is the right place to post this. I have this card http://www.gadgetaddict.net/myphone-dtv-dongle/ Is there a chance to get this working on the Raspberry Pi 3 based on below's dmesg output? [ 2412.224084] usb 1-1: new high-speed USB device number 10 using ehci-pci [ 2412.582937] usb 1-1: New USB device found, idVendor=048d, idProduct=9306 [ 2412.582943] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 2412.643448] [1746] usb 1-1: dvb_usbv2_probe: bInterfaceNumber=0 [ 2412.643463] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 0b 00 00 00 03 02 00 00 12 22 db ea [ 2412.648672] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 07 00 00 01 06 93 6b f9 [ 2412.648684] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 0b 00 00 01 01 02 00 00 38 4f ad c6 [ 2412.652713] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 05 01 00 83 7b ff [ 2412.652722] usb 1-1: dvb_usb_af9035: prechip_version=83 chip_version=01 chip_type=9306 [ 2412.652727] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 06 00 22 02 01 fd dc [ 2412.656734] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 08 02 00 00 00 00 00 fd ff [ 2412.656743] [1746] usb 1-1: af9035_identify_state: reply=00 00 00 00 [ 2412.656747] usb 1-1: dvb_usb_v2: found a 'ITE 9303 Generic' in cold state [ 2412.656750] [1746] usb 1-1: dvb_usbv2_download_firmware: [ 2412.656810] usb 1-1: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9303-01.fw' [ 2412.656814] [1746] usb 1-1: af9035_download_firmware: [ 2412.656818] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 0b 00 00 03 01 02 00 00 49 c5 35 b5 [ 2412.661103] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 05 03 00 00 fc ff [ 2412.661116] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 04 03 00 00 03 41 00 03 41 80 06 41 93 1a 02 12 bf 02 41 93 22 00 00 a2 af e4 33 90 7c 00 f0 a2 dd e4 33 a3 f0 7e 4b 7f fc 7c 44 7d ca 7b 04 12 a1 aa 4b [ 2412.666246] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 04 00 fb ff [ 2412.666258] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=48 [ 2412.666285] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 05 03 00 00 01 41 ad 29 5f e4 ff 74 3b 2f f5 82 e4 34 f5 f5 83 74 ff f0 0f ef b4 40 ee c2 dd c2 af 74 89 90 f5 3b f0 74 41 a3 f0 74 4c 90 f5 5b f0 4b 6b [ 2412.670091] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 05 00 fa ff [ 2412.670102] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=96 [ 2412.670108] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 06 03 00 00 01 41 d6 29 74 00 a3 f0 74 2f 90 f5 3d f0 74 f5 a3 f0 74 44 90 f5 5d f0 74 76 a3 f0 74 89 90 f5 3f f0 74 2c a3 f0 74 44 90 f5 5f f0 74 fc 3e [ 2412.673737] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 06 00 f9 ff [ 2412.673747] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=144 [ 2412.673753] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 07 03 00 00 01 41 ff 29 68 a3 f0 74 89 90 f5 41 f0 74 31 a3 f0 74 44 90 f5 61 f0 74 6f a3 f0 74 87 90 f5 43 f0 74 59 a3 f0 74 43 90 f5 63 f0 74 04 9e b5 [ 2412.678121] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 07 00 f8 ff [ 2412.678133] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=192 [ 2412.678138] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 08 03 00 00 01 42 28 29 a3 f0 74 87 90 f5 45 f0 74 e1 a3 f0 74 43 90 f5 65 f0 74 e3 a3 f0 74 88 90 f5 47 f0 74 3a a3 f0 74 42 90 f5 67 f0 74 a2 a3 57 e0 [ 2412.681865] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 08 00 f7 ff [ 2412.681875] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=240 [ 2412.681882] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 09 03 00 00 01 42 51 29 f0 90 f5 3a e0 54 fe 44 01 f0 c2 ae c2 8e 43 8e 10 d2 df 75 c0 50 53 89 0f 43 89 20 75 8b be 75 8d be d2 8e c2 c1 c2 ae d2 8d 0e [ 2412.685887] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 09 00 f6 ff [ 2412.685899] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=288 [ 2412.685906] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 0a 03 00 00 01 42 7a 29 be 12 88 3c e4 90 79 04 f0 90 d9 24 e0 54 fe 44 01 f0 e4 90 49 62 f0 90 7c 01 e0 24 ff 92 dd 90 7c 00 e0 24 ff 92 af 22 90 39 a9 [ 2412.690693] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 0a 00 f5 ff [ 2412.690704] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=336 [ 2412.690710] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 0b 03 00 00 01 42 a3 29 f7 04 e0 70 24 c2 ae c2 8e 43 8e 10 d2 df 75 c0 50 53 89 0f 43 89 20 75 8b be 75 8d be d2 8e c2 c1 c2 ae 90 49 62 f0 80 24 e6 0b [ 2412.695033] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 0b 00 f4 ff [ 2412.695044] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=384 [ 2412.695050] [1746] usb 1-1: dvb_usb_v2_generic_io: >>> 35 00 29 0c 03 00 00 01 42 cc 29 c2 ae c2 8e 43 8e 10 d2 df 75 c0 d0 53 89 0f 43 89 20 75 8b be 75 8d be d2 8e c2 c1 d2 ae 90 49 62 74 01 f0 d2 be 12 88 3c 80 ed [ 2412.698733] [1746] usb 1-1: dvb_usb_v2_generic_io: <<< 04 0c 00 f3 ff [ 2412.698742] [1746] usb 1-1: af9035_download_firmware_new: data uploaded=432 [ 241
Re: dvb usb issues since kernel 4.9
On Tue, 2018-01-09 at 22:26 +0100, Jesper Dangaard Brouer wrote:
>
> I've previously experienced that you can be affected by the scheduler
> granularity, which is adjustable (with CONFIG_SCHED_DEBUG=y):
>
> $ grep -H . /proc/sys/kernel/sched_*_granularity_ns
> /proc/sys/kernel/sched_min_granularity_ns:225
> /proc/sys/kernel/sched_wakeup_granularity_ns:300
>
> The above numbers were confirmed on the RPi2 (see[2]). With commit
> 4cd13c21b207 ("softirq: Let ksoftirqd do its job"), I expect/assume that
> softirq processing latency is bounded by the sched_wakeup_granularity_ns,
> which with 3 ms is not good enough for their use-case.
Note of caution wrt twiddling sched_wakeup_granularity_ns: it must
remain < sched_latency_ns/2 else you effectively disable wakeup
preemption completely, turning CFS into a tick granularity scheduler.
-Mike
Re: [PATCH] media: pvrusb2: Convert timers to use timer_setup()
Ack'ed (separate formal reply)
-Mike
On Wed, 25 Oct 2017, Kees Cook wrote:
> Eek, sorry, this uses timer_setup_on_stack() which is only in -next.
> If you can Ack this, I can carry it in the timer tree.
>
> Thanks!
>
> -Kees
>
> On Tue, Oct 24, 2017 at 5:22 PM, Kees Cook wrote:
> > In preparation for unconditionally passing the struct timer_list pointer to
> > all timer callbacks, switch to using the new timer_setup() and from_timer()
> > to pass the timer pointer explicitly.
> >
> > Cc: Mike Isely
> > Cc: Mauro Carvalho Chehab
> > Cc: linux-media@vger.kernel.org
> > Signed-off-by: Kees Cook
> > ---
> > drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 64
> > ++---
> > 1 file changed, 36 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> > b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> > index ad5b25b89699..8289ee482f49 100644
> > --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> > +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> > @@ -330,10 +330,10 @@ static void pvr2_hdw_state_log_state(struct pvr2_hdw
> > *);
> > static int pvr2_hdw_cmd_usbstream(struct pvr2_hdw *hdw,int runFl);
> > static int pvr2_hdw_commit_setup(struct pvr2_hdw *hdw);
> > static int pvr2_hdw_get_eeprom_addr(struct pvr2_hdw *hdw);
> > -static void pvr2_hdw_quiescent_timeout(unsigned long);
> > -static void pvr2_hdw_decoder_stabilization_timeout(unsigned long);
> > -static void pvr2_hdw_encoder_wait_timeout(unsigned long);
> > -static void pvr2_hdw_encoder_run_timeout(unsigned long);
> > +static void pvr2_hdw_quiescent_timeout(struct timer_list *);
> > +static void pvr2_hdw_decoder_stabilization_timeout(struct timer_list *);
> > +static void pvr2_hdw_encoder_wait_timeout(struct timer_list *);
> > +static void pvr2_hdw_encoder_run_timeout(struct timer_list *);
> > static int pvr2_issue_simple_cmd(struct pvr2_hdw *,u32);
> > static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> > unsigned int timeout,int probe_fl,
> > @@ -2373,18 +2373,15 @@ struct pvr2_hdw *pvr2_hdw_create(struct
> > usb_interface *intf,
> > }
> > if (!hdw) goto fail;
> >
> > - setup_timer(&hdw->quiescent_timer, pvr2_hdw_quiescent_timeout,
> > - (unsigned long)hdw);
> > + timer_setup(&hdw->quiescent_timer, pvr2_hdw_quiescent_timeout, 0);
> >
> > - setup_timer(&hdw->decoder_stabilization_timer,
> > - pvr2_hdw_decoder_stabilization_timeout,
> > - (unsigned long)hdw);
> > + timer_setup(&hdw->decoder_stabilization_timer,
> > + pvr2_hdw_decoder_stabilization_timeout, 0);
> >
> > - setup_timer(&hdw->encoder_wait_timer, pvr2_hdw_encoder_wait_timeout,
> > - (unsigned long)hdw);
> > + timer_setup(&hdw->encoder_wait_timer, pvr2_hdw_encoder_wait_timeout,
> > + 0);
> >
> > - setup_timer(&hdw->encoder_run_timer, pvr2_hdw_encoder_run_timeout,
> > - (unsigned long)hdw);
> > + timer_setup(&hdw->encoder_run_timer, pvr2_hdw_encoder_run_timeout,
> > 0);
> >
> > hdw->master_state = PVR2_STATE_DEAD;
> >
> > @@ -3539,10 +3536,16 @@ static void pvr2_ctl_read_complete(struct urb *urb)
> > complete(&hdw->ctl_done);
> > }
> >
> > +struct hdw_timer {
> > + struct timer_list timer;
> > + struct pvr2_hdw *hdw;
> > +};
> >
> > -static void pvr2_ctl_timeout(unsigned long data)
> > +static void pvr2_ctl_timeout(struct timer_list *t)
> > {
> > - struct pvr2_hdw *hdw = (struct pvr2_hdw *)data;
> > + struct hdw_timer *timer = from_timer(timer, t, timer);
> > + struct pvr2_hdw *hdw = timer->hdw;
> > +
> > if (hdw->ctl_write_pend_flag || hdw->ctl_read_pend_flag) {
> > hdw->ctl_timeout_flag = !0;
> > if (hdw->ctl_write_pend_flag)
> > @@ -3564,7 +3567,10 @@ static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> > {
> > unsigned int idx;
> > int status = 0;
> > - struct timer_list timer;
> > + struct hdw_timer timer = {
> > + .hdw = hdw,
> > + };
> > +
> > if (!hdw->ctl_lock_held) {
> > pvr2_trace(PVR2_TRACE_ERROR_LEGS,
> >"Attempted to execute control transfer
Re: [PATCH] media: pvrusb2: Convert timers to use timer_setup()
Acked-By: Mike Isely
On Tue, 24 Oct 2017, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Mike Isely
> Cc: Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Kees Cook
> ---
> drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 64
> ++---
> 1 file changed, 36 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> index ad5b25b89699..8289ee482f49 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> @@ -330,10 +330,10 @@ static void pvr2_hdw_state_log_state(struct pvr2_hdw *);
> static int pvr2_hdw_cmd_usbstream(struct pvr2_hdw *hdw,int runFl);
> static int pvr2_hdw_commit_setup(struct pvr2_hdw *hdw);
> static int pvr2_hdw_get_eeprom_addr(struct pvr2_hdw *hdw);
> -static void pvr2_hdw_quiescent_timeout(unsigned long);
> -static void pvr2_hdw_decoder_stabilization_timeout(unsigned long);
> -static void pvr2_hdw_encoder_wait_timeout(unsigned long);
> -static void pvr2_hdw_encoder_run_timeout(unsigned long);
> +static void pvr2_hdw_quiescent_timeout(struct timer_list *);
> +static void pvr2_hdw_decoder_stabilization_timeout(struct timer_list *);
> +static void pvr2_hdw_encoder_wait_timeout(struct timer_list *);
> +static void pvr2_hdw_encoder_run_timeout(struct timer_list *);
> static int pvr2_issue_simple_cmd(struct pvr2_hdw *,u32);
> static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> unsigned int timeout,int probe_fl,
> @@ -2373,18 +2373,15 @@ struct pvr2_hdw *pvr2_hdw_create(struct usb_interface
> *intf,
> }
> if (!hdw) goto fail;
>
> - setup_timer(&hdw->quiescent_timer, pvr2_hdw_quiescent_timeout,
> - (unsigned long)hdw);
> + timer_setup(&hdw->quiescent_timer, pvr2_hdw_quiescent_timeout, 0);
>
> - setup_timer(&hdw->decoder_stabilization_timer,
> - pvr2_hdw_decoder_stabilization_timeout,
> - (unsigned long)hdw);
> + timer_setup(&hdw->decoder_stabilization_timer,
> + pvr2_hdw_decoder_stabilization_timeout, 0);
>
> - setup_timer(&hdw->encoder_wait_timer, pvr2_hdw_encoder_wait_timeout,
> - (unsigned long)hdw);
> + timer_setup(&hdw->encoder_wait_timer, pvr2_hdw_encoder_wait_timeout,
> + 0);
>
> - setup_timer(&hdw->encoder_run_timer, pvr2_hdw_encoder_run_timeout,
> - (unsigned long)hdw);
> + timer_setup(&hdw->encoder_run_timer, pvr2_hdw_encoder_run_timeout, 0);
>
> hdw->master_state = PVR2_STATE_DEAD;
>
> @@ -3539,10 +3536,16 @@ static void pvr2_ctl_read_complete(struct urb *urb)
> complete(&hdw->ctl_done);
> }
>
> +struct hdw_timer {
> + struct timer_list timer;
> + struct pvr2_hdw *hdw;
> +};
>
> -static void pvr2_ctl_timeout(unsigned long data)
> +static void pvr2_ctl_timeout(struct timer_list *t)
> {
> - struct pvr2_hdw *hdw = (struct pvr2_hdw *)data;
> + struct hdw_timer *timer = from_timer(timer, t, timer);
> + struct pvr2_hdw *hdw = timer->hdw;
> +
> if (hdw->ctl_write_pend_flag || hdw->ctl_read_pend_flag) {
> hdw->ctl_timeout_flag = !0;
> if (hdw->ctl_write_pend_flag)
> @@ -3564,7 +3567,10 @@ static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> {
> unsigned int idx;
> int status = 0;
> - struct timer_list timer;
> + struct hdw_timer timer = {
> + .hdw = hdw,
> + };
> +
> if (!hdw->ctl_lock_held) {
> pvr2_trace(PVR2_TRACE_ERROR_LEGS,
> "Attempted to execute control transfer without
> lock!!");
> @@ -3621,8 +3627,8 @@ static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> hdw->ctl_timeout_flag = 0;
> hdw->ctl_write_pend_flag = 0;
> hdw->ctl_read_pend_flag = 0;
> - setup_timer(&timer, pvr2_ctl_timeout, (unsigned long)hdw);
> - timer.expires = jiffies + timeout;
> + timer_setup_on_stack(&timer.timer, pvr2_ctl_timeout, 0);
> + timer.timer.expires = jiffies + timeout;
>
> if (write_len && write_data) {
> hdw->cmd_debug_state = 2;
> @@ -3677,7 +3683,7 @@ status);
> }
>
> /* Start timer */
> - add_timer(&timer);
> + add_timer(&timer.timer);
>
> /* Now wait
Re: [PATCH 05/24] media: v4l2-dev: convert VFL_TYPE_* into an enum
Acked-By: Mike Isely
On Mon, 9 Oct 2017, Mauro Carvalho Chehab wrote:
> Using enums makes easier to document, as it can use kernel-doc
> markups. It also allows cross-referencing, with increases the
> kAPI readability.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/media/kapi/v4l2-dev.rst | 17 ++---
> drivers/media/pci/cx88/cx88-blackbird.c | 3 +-
> drivers/media/pci/cx88/cx88-video.c | 10 +++---
> drivers/media/pci/cx88/cx88.h | 4 +--
> drivers/media/pci/saa7134/saa7134-video.c | 2 ++
> drivers/media/usb/cx231xx/cx231xx-video.c | 2 ++
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 2 ++
> drivers/media/usb/tm6000/tm6000-video.c | 2 ++
> drivers/media/v4l2-core/v4l2-dev.c| 10 +++---
> include/media/v4l2-dev.h | 59
> +--
> include/media/v4l2-mediabus.h | 30
> 11 files changed, 98 insertions(+), 43 deletions(-)
>
> diff --git a/Documentation/media/kapi/v4l2-dev.rst
> b/Documentation/media/kapi/v4l2-dev.rst
> index b29aa616c267..7bb0505b60f1 100644
> --- a/Documentation/media/kapi/v4l2-dev.rst
> +++ b/Documentation/media/kapi/v4l2-dev.rst
> @@ -196,11 +196,18 @@ device.
> Which device is registered depends on the type argument. The following
> types exist:
>
> -- ``VFL_TYPE_GRABBER``: ``/dev/videoX`` for video input/output devices
> -- ``VFL_TYPE_VBI``: ``/dev/vbiX`` for vertical blank data (i.e. closed
> captions, teletext)
> -- ``VFL_TYPE_RADIO``: ``/dev/radioX`` for radio tuners
> -- ``VFL_TYPE_SDR``: ``/dev/swradioX`` for Software Defined Radio tuners
> -- ``VFL_TYPE_TOUCH``: ``/dev/v4l-touchX`` for touch sensors
> +==
> ==
> +:c:type:`vfl_devnode_type` Device nameUsage
> +==
> ==
> +``VFL_TYPE_GRABBER`` ``/dev/videoX`` for video input/output
> devices
> +``VFL_TYPE_VBI`` ``/dev/vbiX`` for vertical blank data
> (i.e.
> + closed captions, teletext)
> +``VFL_TYPE_RADIO`` ``/dev/radioX`` for radio tuners
> +``VFL_TYPE_SUBDEV````/dev/v4l-subdevX`` for V4L2 subdevices
> +``VFL_TYPE_SDR`` ``/dev/swradioX`` for Software Defined Radio
> + (SDR) tuners
> +``VFL_TYPE_TOUCH`` ``/dev/v4l-touchX`` for touch sensors
> +==
> ==
>
> The last argument gives you a certain amount of control over the device
> device node number used (i.e. the X in ``videoX``). Normally you will pass -1
> diff --git a/drivers/media/pci/cx88/cx88-blackbird.c
> b/drivers/media/pci/cx88/cx88-blackbird.c
> index e3101f04941c..0e0952e60795 100644
> --- a/drivers/media/pci/cx88/cx88-blackbird.c
> +++ b/drivers/media/pci/cx88/cx88-blackbird.c
> @@ -805,8 +805,7 @@ static int vidioc_querycap(struct file *file, void *priv,
>
> strcpy(cap->driver, "cx88_blackbird");
> sprintf(cap->bus_info, "PCI:%s", pci_name(dev->pci));
> - cx88_querycap(file, core, cap);
> - return 0;
> + return cx88_querycap(file, core, cap);
> }
>
> static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
> diff --git a/drivers/media/pci/cx88/cx88-video.c
> b/drivers/media/pci/cx88/cx88-video.c
> index 7d25ecd4404b..9be682cdb644 100644
> --- a/drivers/media/pci/cx88/cx88-video.c
> +++ b/drivers/media/pci/cx88/cx88-video.c
> @@ -806,8 +806,8 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void
> *priv,
> return 0;
> }
>
> -void cx88_querycap(struct file *file, struct cx88_core *core,
> -struct v4l2_capability *cap)
> +int cx88_querycap(struct file *file, struct cx88_core *core,
> + struct v4l2_capability *cap)
> {
> struct video_device *vdev = video_devdata(file);
>
> @@ -825,11 +825,14 @@ void cx88_querycap(struct file *file, struct cx88_core
> *core,
> case VFL_TYPE_VBI:
> cap->device_caps |= V4L2_CAP_VBI_CAPTURE;
> break;
> + default:
> + return -EINVAL;
> }
> cap->capabilities = cap->device_caps | V4L2_CAP_VIDEO_CAPTURE |
> V4L2_CAP_VBI_CAPTURE | V4L2_CAP_DEVICE_CAPS;
> if (core->board.radio.type == CX88_RADIO)
> cap->capabilities |= V4L2_CAP_RADIO;
> + return 0;
> }
> EXPORT_SYMBOL(cx88_querycap);
>
> @@ -841,8 +844,7 @@ static int vidioc_querycap(st
Re: usb/media/pvrusb2: warning in pvr2_send_request_ex/usb_submit_urb
What you have here is way beyond just feeding random crap in via the syscall interface. To cause this you have to fake the presence of a pvrusb2 compatible *hardware* USB device and then lie about its endpoint configuration. Is that really a concern here? Are we now saying that any kernel driver which talks via USB must now also specifically verify the exact expected USB endpoint configuration? Where does that end? How about the vendor-specific RPC protocol that the hardware actually implements over the bulk endpoint? It's likely that the pvrusb2 driver may be making assumptions about the expected responses over that protocol. Please realize that I'm not dismissing this. I can see some merit in this. But I'm just a bit surprised that now we're going this far. Is this really the intention? You're talking about code (pvrusb2_send_request_ex()) that hasn't changed in about 10 years. With this level of paranoia there's got to be a pretty target-rich environment over the set of kernel-supported USB devices. To take this another step, wouldn't that same level of paranoia be a concern for any externally connected PCI-Express device? Because that's another external way into the computer that involves very non-trivial and very hardware-centric protocols. Thunderbolt devices would be an example of this. -Mike On Wed, 20 Sep 2017, Andrey Konovalov wrote: > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18). > > There seems to be no check on endpoint type before submitting bulk urb > in pvr2_send_request_ex(). > > usb 1-1: New USB device found, idVendor=2040, idProduct=7500 > usb 1-1: New USB device strings: Mfr=0, Product=255, SerialNumber=0 > usb 1-1: Product: a > gadgetfs: configuration #6 > pvrusb2: Hardware description: WinTV HVR-1950 Model 750xx > usb 1-1: BOGUS urb xfer, pipe 3 != type 1 > [ cut here ] > WARNING: CPU: 1 PID: 2713 at drivers/usb/core/urb.c:449 > usb_submit_urb+0xf8a/0x11d0 > Modules linked in: > CPU: 1 PID: 2713 Comm: pvrusb2-context Not tainted > 4.14.0-rc1-42251-gebb2c2437d80 #210 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > task: 88006b7a18c0 task.stack: 880069978000 > RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448 > RSP: 0018:88006997f990 EFLAGS: 00010286 > RAX: 0029 RBX: 880063661900 RCX: > RDX: 0029 RSI: 86876d60 RDI: ed000d32ff24 > RBP: 88006997fa90 R08: 11000d32fdca R09: > R10: R11: R12: 11000d32ff39 > R13: 0001 R14: 0003 R15: 880068bbed68 > FS: () GS:88006c60() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 01032000 CR3: 6a0ff000 CR4: 06f0 > Call Trace: > pvr2_send_request_ex+0xa57/0x1d80 > drivers/media/usb/pvrusb2/pvrusb2-hdw.c:3645 > pvr2_hdw_check_firmware drivers/media/usb/pvrusb2/pvrusb2-hdw.c:1812 > pvr2_hdw_setup_low drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2107 > pvr2_hdw_setup drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2250 > pvr2_hdw_initialize+0x548/0x3c10 drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2327 > pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:118 > pvr2_context_thread_func+0x361/0x8c0 > drivers/media/usb/pvrusb2/pvrusb2-context.c:167 > kthread+0x3a1/0x470 kernel/kthread.c:231 > ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431 > Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 ee 82 89 fe 45 89 > e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 40 c0 ea 86 e8 30 1b dc fc <0f> > ff e9 9b f7 ff ff e8 aa 95 25 fd e9 80 f7 ff ff e8 50 74 f3 > ---[ end trace 6919030503719da6 ]--- > -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
GP fault in cx18 module from v4l-dvb drivers on linuxtv.org (Ubuntu 17.04)
Having a problem with a #GP fault when loading the cx18 driver from v4l-dvb from the linuxtv.org site. Device: Hauppauge HVR-1600 (lspci output at pastebin.com/e7G52kqQ) (ATSC signals) Environment: Ubuntu 17.04, kernel 4.10.0-33-generic, 64-bit Hardware: Motherboard: Gigabyte GA-B150M-D3H (16GB RAM) I've downloaded the v4l-dvb kernel drivers, built them, and installed them. I was unable to use the built-in drivers as I needed the cx18-i2c driver. >From the stack trace included with the pastebin link above it appears the problem is in find_ref_lock() when called from c18_probe() if that helps immediately. Things I've tried: -- Remove kernel drivers/Reboot/Install v4l-dvb drivers/build/install/modprobe -- Do a 'make rminstall' to remove drivers and attempt install/modprobe again I found it interesting that even though the #GP happens and the /dev entries are not created, the cx18 module still loads (as found with lsmod) but no cx18-i2c was loaded.
[PATCH] usb: core: urb make use of usb_endpoint_maxp_mult
Since usb_endpoint_maxp now returns only lower 11 bits mult
calculation here isn't correct anymore and that breaks webcam
for me. Patch make use of usb_endpoint_maxp_mult instead of
direct calculation.
Fixes: abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return
only packet size")
Signed-off-by: Mike Krinkin
---
drivers/usb/core/urb.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index 0be49a1..d75cb8c 100644
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -412,11 +412,8 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
}
/* "high bandwidth" mode, 1-3 packets/uframe? */
- if (dev->speed == USB_SPEED_HIGH) {
- int mult = 1 + ((max >> 11) & 0x03);
- max &= 0x07ff;
- max *= mult;
- }
+ if (dev->speed == USB_SPEED_HIGH)
+ max *= usb_endpoint_maxp_mult(&ep->desc);
if (urb->number_of_packets <= 0)
return -EINVAL;
--
2.7.4
--
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] include sys/sysmacros.h for major() & minor()
Linux C libraries are looking to disentangle sysmacros.h from the sys/types.h header to clean up namespace pollution. Since these macros are provided in glibc/etc... today, switch to pulling in this header directly. Signed-off-by: Mike Frysinger --- contrib/test/mc_nextgen_test.c| 1 + lib/libv4lconvert/control/libv4lcontrol.c | 1 + utils/libmedia_dev/get_media_devices.c| 1 + utils/media-ctl/libmediactl.c | 1 + 4 files changed, 4 insertions(+) diff --git a/contrib/test/mc_nextgen_test.c b/contrib/test/mc_nextgen_test.c index a62fd13..4ba37b0 100644 --- a/contrib/test/mc_nextgen_test.c +++ b/contrib/test/mc_nextgen_test.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include diff --git a/lib/libv4lconvert/control/libv4lcontrol.c b/lib/libv4lconvert/control/libv4lcontrol.c index 3c8335c..59f28b1 100644 --- a/lib/libv4lconvert/control/libv4lcontrol.c +++ b/lib/libv4lconvert/control/libv4lcontrol.c @@ -20,6 +20,7 @@ */ #include +#include #include #include #include diff --git a/utils/libmedia_dev/get_media_devices.c b/utils/libmedia_dev/get_media_devices.c index e3a2200..edfeb41 100644 --- a/utils/libmedia_dev/get_media_devices.c +++ b/utils/libmedia_dev/get_media_devices.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include #include diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c index 4a82d24..16dddbe 100644 --- a/utils/media-ctl/libmediactl.c +++ b/utils/media-ctl/libmediactl.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include -- 2.6.2 -- 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
Questions about dvbv5-scan (missing fields)
Hi I hope this is the right list to ask. I am looking at using dvbv5 for one of my projects. However there are some fields that I cant seem to get, in particular tsid pmt service_type (TV?Radio etc) net netid example output in VDR format CBS Drama:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:14640:0:0:0: Showcase TV:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:15296:0:0:0: Box Nation:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:14416:0:0:0: Horror Channel:538000:S0B8C34D12I1M64T8G32Y0:T:27500:6129:6130,6131:0:0:14480:0:0:0: 365 Travel:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:14784:0:0:0: Television X:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:15232:0:0:0: 5 USA:538000:S0B8C34D12I1M64T8G32Y0:T:27500:6689:6690,6691:0:0:12992:0:0:0: 5*:538000:S0B8C34D12I1M64T8G32Y0:T:27500:6673:6674,6675:0:0:12928:0:0:0: QUEST:538000:S0B8C34D12I1M64T8G32Y0:T:27500:6929:6930,6931:0:0:14498:0:0:0: A can be seen there is loads of zeros where entries should be thanks -- 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: Geniatech / Mygica T230
latest dvb modules in my kernel? no, not really, but rather recent anyway - I don't think there are any relevant changes after that ok http://git.linuxtv.org/cgit.cgi/media_build.git/about/ if you want, you can add the latest media_tree to ~any kernel by following the instruction there ok, noted but I doubt that will help in your case * [crope] (cr...@otitsun.oulu.fi): Antti Palosaari www.palosaari.fi * [crope] #linuxtv * [crope] kornbluth.freenode.net :Frankfurt, Germany * [crope] idle 96:04:21, signon: Mon Jul 27 14:42:22 * [crope] End of WHOIS list. On 6 November 2015 at 06:34, Olli Salonen wrote: > Hi Mike, > > Can you also paste the dmesg output here, so we can see if the driver > is starting up correctly? > > Cheers, > -olli > > On 3 November 2015 at 23:35, Mike Parkins wrote: >> Hi, >> I can't get this dvb-t2 USB device to work despite the linuxtv site >> claiming it is working since 3.19 kernel. I tried talking to the driver >> team on IRC a few months ago and they said they would look at it but I have >> recently pulled the linuxtv git tree and compiled it on my Linux Mint 4.09 >> kernel system and it has not changed. Below is the output of a typical >> tuning attempt: >> >> mp@Aurorabox ~ $ dvbv5-scan uk-CrystalPalace -I CHANNEL >> Scanning frequency #1 49000 >> Lock (0x1f) C/N= 28.25dB >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x11c0 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1200 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1240 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1280 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1600 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1640 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1680 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x16c0 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1700 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1740 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1780 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1804 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1a40 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1a80 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1ac0 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1b00 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the PMT table for service 0x1c00 >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the NIT table >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while reading the SDT table >> WARNING: no SDT table - storing channel(s) without their names >> Storing Service ID 4164: '490.00MHz#4164' >> Storing Service ID 4287: '490.00MHz#4287' >> Storing Service ID 4288: '490.00MHz#4288' >> Storing Service ID 4352: '490.00MHz#4352' >> Storing Service ID 4416: '490.00MHz#4416' >> Scanning frequency #2 51400 >> Lock (0x1f) Signal= -29.00dBm C/N= 21.50dB >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while waiting for PAT table >> Scanning frequency #3 545833000 >> Lock (0x1f) Signal= -30.00dBm C/N= 31.00dB >> ERRORdvb_read_sections: no data read on section filter >> ERRORerror while waiting for PAT table >> Scanning frequency #4 50600 >> Lock (0x1f) Signal= -30.00dBm C/N= 28.50dB >> ERRORdvb_read_sections: no data read on
Geniatech / Mygica T230
Hi, I can't get this dvb-t2 USB device to work despite the linuxtv site claiming it is working since 3.19 kernel. I tried talking to the driver team on IRC a few months ago and they said they would look at it but I have recently pulled the linuxtv git tree and compiled it on my Linux Mint 4.09 kernel system and it has not changed. Below is the output of a typical tuning attempt: mp@Aurorabox ~ $ dvbv5-scan uk-CrystalPalace -I CHANNEL Scanning frequency #1 49000 Lock (0x1f) C/N= 28.25dB ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x11c0 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1200 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1240 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1280 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1600 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1640 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1680 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x16c0 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1700 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1740 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1780 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1804 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1a40 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1a80 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1ac0 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1b00 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the PMT table for service 0x1c00 ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the NIT table ERRORdvb_read_sections: no data read on section filter ERRORerror while reading the SDT table WARNING: no SDT table - storing channel(s) without their names Storing Service ID 4164: '490.00MHz#4164' Storing Service ID 4287: '490.00MHz#4287' Storing Service ID 4288: '490.00MHz#4288' Storing Service ID 4352: '490.00MHz#4352' Storing Service ID 4416: '490.00MHz#4416' Scanning frequency #2 51400 Lock (0x1f) Signal= -29.00dBm C/N= 21.50dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #3 545833000 Lock (0x1f) Signal= -30.00dBm C/N= 31.00dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #4 50600 Lock (0x1f) Signal= -30.00dBm C/N= 28.50dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #5 48200 Lock (0x1f) Signal= -30.00dBm C/N= 21.75dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #6 529833000 Lock (0x1f) Signal= -29.00dBm C/N= 21.75dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #7 53800 Lock (0x1f) Signal= -29.00dBm C/N= 16.50dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #8 57000 Lock (0x1f) Signal= -46.00dBm C/N= 26.50dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table Scanning frequency #9 58600 Lock (0x1f) Signal= -39.00dBm C/N= 26.25dB ERRORdvb_read_sections: no data read on section filter ERRORerror while waiting for PAT table mp@Aurorabox ~ $ -- 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 v2 5/6] media/usb/pvrusb2: Support for V4L2_CTRL_WHICH_DEF_VAL
Looks good to me (still), including now the change I had previously
suggested. For the record, the ack still applies. (I guess you can
consider this to be an ack of the ack...)
-Mike
On Thu, 29 Oct 2015, Ricardo Ribalda Delgado wrote:
> This driver does not use the control infrastructure.
> Add support for the new field which on structure
> v4l2_ext_controls
>
> Acked-by: Mike Isely
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> index 1c5f85bf7ed4..81f788b7b242 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> @@ -628,6 +628,7 @@ static int pvr2_g_ext_ctrls(struct file *file, void *priv,
> struct pvr2_v4l2_fh *fh = file->private_data;
> struct pvr2_hdw *hdw = fh->channel.mc_head->hdw;
> struct v4l2_ext_control *ctrl;
> + struct pvr2_ctrl *cptr;
> unsigned int idx;
> int val;
> int ret;
> @@ -635,8 +636,15 @@ static int pvr2_g_ext_ctrls(struct file *file, void
> *priv,
> ret = 0;
> for (idx = 0; idx < ctls->count; idx++) {
> ctrl = ctls->controls + idx;
> - ret = pvr2_ctrl_get_value(
> - pvr2_hdw_get_ctrl_v4l(hdw, ctrl->id), &val);
> + cptr = pvr2_hdw_get_ctrl_v4l(hdw, ctrl->id);
> + if (cptr) {
> + if (ctls->which == V4L2_CTRL_WHICH_DEF_VAL)
> + pvr2_ctrl_get_def(cptr, &val);
> + else
> + ret = pvr2_ctrl_get_value(cptr, &val);
> + } else
> + ret = -EINVAL;
> +
> if (ret) {
> ctls->error_idx = idx;
> return ret;
> @@ -658,6 +666,10 @@ static int pvr2_s_ext_ctrls(struct file *file, void
> *priv,
> unsigned int idx;
> int ret;
>
> + /* Default value cannot be changed */
> + if (ctls->which == V4L2_CTRL_WHICH_DEF_VAL)
> + return -EINVAL;
> +
> ret = 0;
> for (idx = 0; idx < ctls->count; idx++) {
> ctrl = ctls->controls + idx;
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 v2 07/10] media/usb/pvrusb2: Support for V4L2_CTRL_WHICH_DEF_VAL
The code you've added is carefully checking the return pointer from
pvr2_hdw_get_ctrl_v4l() yet the original code did not operate this way.
The result is that now there's this "unbalanced" effect where it appears
that the validity of the pvr2_ctrl instance is only checked on one side
of the if-statement. I would recommend instead to elevate the call to
pvr2_hdw_get_ctrl_v4l() out of the if-statement - since in both cases
it's being called the same way both times. Then do the validity check
in that one spot and that simplifies the if-statement all the way down
to choosing between pvr2_ctrl_get_value() vs pvr2_ctrl_get_def().
It's not a correctness comment; what you have should work fine. So I'm
ack'ing this in any case:
Acked-By: Mike Isely
But you can do the above pretty easily & safely, and simplify it a bit
further.
-Mike
On Fri, 21 Aug 2015, Ricardo Ribalda Delgado wrote:
> This driver does not use the control infrastructure.
> Add support for the new field which on structure
> v4l2_ext_controls
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> index 1c5f85bf7ed4..43b2f2214798 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> @@ -628,6 +628,7 @@ static int pvr2_g_ext_ctrls(struct file *file, void *priv,
> struct pvr2_v4l2_fh *fh = file->private_data;
> struct pvr2_hdw *hdw = fh->channel.mc_head->hdw;
> struct v4l2_ext_control *ctrl;
> + struct pvr2_ctrl *cptr;
> unsigned int idx;
> int val;
> int ret;
> @@ -635,8 +636,18 @@ static int pvr2_g_ext_ctrls(struct file *file, void
> *priv,
> ret = 0;
> for (idx = 0; idx < ctls->count; idx++) {
> ctrl = ctls->controls + idx;
> - ret = pvr2_ctrl_get_value(
> + if (ctls->which == V4L2_CTRL_WHICH_DEF_VAL) {
> + cptr = pvr2_hdw_get_ctrl_v4l(hdw, ctrl->id);
> + if (cptr)
> + pvr2_ctrl_get_def(cptr, &val);
> + else
> + ret = -EINVAL;
> +
> +
> + } else
> + ret = pvr2_ctrl_get_value(
> pvr2_hdw_get_ctrl_v4l(hdw, ctrl->id), &val);
> +
> if (ret) {
> ctls->error_idx = idx;
> return ret;
> @@ -658,6 +669,10 @@ static int pvr2_s_ext_ctrls(struct file *file, void
> *priv,
> unsigned int idx;
> int ret;
>
> + /* Default value cannot be changed */
> + if (ctls->which == V4L2_CTRL_WHICH_DEF_VAL)
> + return -EINVAL;
> +
> ret = 0;
> for (idx = 0; idx < ctls->count; idx++) {
> ctrl = ctls->controls + idx;
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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] [media] i2c/adv7511: Fix license, set to GPL v2
Okay, I split it up and sent it to the proper lists.
Just noticed I forgot to set the "in-reply-to" headers though. Hope that won't
be a problem.
On 11-08-15 13:45, Hans Verkuil wrote:
Hi Mike,
Please split up this patch: these are two different drivers with different
authors and different subsystems.
The media/i2c/adv7511.c patch I can handle, but the patch for the drm driver
should go to the dri-devel mailinglist. I can't take that change.
Easiest is just to post two patches, one for each driver.
Regards,
Hans
On 07/28/15 12:57, Mike Looijmans wrote:
Header claims GPL v2, so make the MODULE_LICENSE reflect that properly.
Signed-off-by: Mike Looijmans
---
drivers/gpu/drm/i2c/adv7511_core.c | 2 +-
drivers/media/i2c/adv7511.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/adv7511_core.c
b/drivers/gpu/drm/i2c/adv7511_core.c
index 2564b5d..12e8134 100644
--- a/drivers/gpu/drm/i2c/adv7511_core.c
+++ b/drivers/gpu/drm/i2c/adv7511_core.c
@@ -956,4 +956,4 @@ module_exit(adv7511_exit);
MODULE_AUTHOR("Lars-Peter Clausen ");
MODULE_DESCRIPTION("ADV7511 HDMI transmitter driver");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 02d76c6..1a4275d 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -41,7 +41,7 @@ MODULE_PARM_DESC(debug, "debug level (0-2)");
MODULE_DESCRIPTION("Analog Devices ADV7511 HDMI Transmitter Device Driver");
MODULE_AUTHOR("Hans Verkuil");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
#define MASK_ADV7511_EDID_RDY_INT 0x04
#define MASK_ADV7511_MSEN_INT 0x40
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
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] i2c/adv7511: Fix license, set to GPL v2
Header claims GPL v2, so make the MODULE_LICENSE reflect that properly.
Signed-off-by: Mike Looijmans
---
drivers/media/i2c/adv7511.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 95bcd40..497ee00 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -40,7 +40,7 @@ MODULE_PARM_DESC(debug, "debug level (0-2)");
MODULE_DESCRIPTION("Analog Devices ADV7511 HDMI Transmitter Device Driver");
MODULE_AUTHOR("Hans Verkuil");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
#define MASK_ADV7511_EDID_RDY_INT 0x04
#define MASK_ADV7511_MSEN_INT 0x40
--
1.9.1
--
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] [media] i2c/adv7511: Fix license, set to GPL v2
Header claims GPL v2, so make the MODULE_LICENSE reflect that properly.
Signed-off-by: Mike Looijmans
---
drivers/gpu/drm/i2c/adv7511_core.c | 2 +-
drivers/media/i2c/adv7511.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/adv7511_core.c
b/drivers/gpu/drm/i2c/adv7511_core.c
index 2564b5d..12e8134 100644
--- a/drivers/gpu/drm/i2c/adv7511_core.c
+++ b/drivers/gpu/drm/i2c/adv7511_core.c
@@ -956,4 +956,4 @@ module_exit(adv7511_exit);
MODULE_AUTHOR("Lars-Peter Clausen ");
MODULE_DESCRIPTION("ADV7511 HDMI transmitter driver");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 02d76c6..1a4275d 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -41,7 +41,7 @@ MODULE_PARM_DESC(debug, "debug level (0-2)");
MODULE_DESCRIPTION("Analog Devices ADV7511 HDMI Transmitter Device Driver");
MODULE_AUTHOR("Hans Verkuil");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
#define MASK_ADV7511_EDID_RDY_INT 0x04
#define MASK_ADV7511_MSEN_INT 0x40
--
1.9.1
--
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] [media] imageon-bridge: Add module license information
Comment header specifies GPL-2, so add a MODULE_LICENSE("GPL v2").
This fixes the driver failing to load when built as module:
imageon_bridge: module license 'unspecified' taints kernel.
imageon_bridge: Unknown symbol ...
As an extra service, also add a description.
Signed-off-by: Mike Looijmans
---
drivers/media/platform/imageon-bridge.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/imageon-bridge.c
b/drivers/media/platform/imageon-bridge.c
index 9550695..a69b6da 100644
--- a/drivers/media/platform/imageon-bridge.c
+++ b/drivers/media/platform/imageon-bridge.c
@@ -317,3 +317,6 @@ static struct platform_driver imageon_bridge_driver = {
.remove = imageon_bridge_remove,
};
module_platform_driver(imageon_bridge_driver);
+
+MODULE_DESCRIPTION("Imageon video bridge");
+MODULE_LICENSE("GPL v2");
--
1.9.1
--
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
Disappearing dvb-usb stick IT9137FN (Kworld 499-2T)
Hi I have the above usb stick (dual frontend) which works fine for a while then just vanishes. ie: frontend just goes eg ls /dev/dvb (I have a permanent DVB card as well) /dev/dvb/adapter0 /dev/dvb/adapter1 /dev/dvb/adapter2 goes to ls /dev/dvb (I have a permanent DVB card as well) /dev/dvb/adapter0 To get it back I have plug/unplug several times (rebooting the box seems to make no difference) I am currently on fedora 21, but this seems to be a continual issue , through at least fedora 18 to date I cant see anything obvious in dmesg or the logs Any ideas -- 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: rt-mutex usage in i2c
On Sat, Mar 14, 2015 at 1:32 PM, Wolfram Sang wrote:
> On Sat, Mar 14, 2015 at 12:27:03PM +0100, Wolfram Sang wrote:
>> Hi Sebastian,
>>
>> > - i2c_transfer() has this piece:
>> > 2091 if (in_atomic() || irqs_disabled()) {
>> > 2092 ret = i2c_trylock_adapter(adap);
>> >
>> > is this irqs_disabled() is what bothers me and should not be there.
>> > pxa does a spin_lock_irq() which would enable interrupts on return /
>> > too early.
>> > mxs has a wait_for_completion() which needs irqs enabled _and_ makes
>> > in_atomic() problematic, too. I have't checked other drivers but the
>> > commit, that introduced it, does not explain why it is required.
That was some time ago, but as far as I remember, PIO in i2c_pxa was
required to enable communication with PMIC in interrupt context.
>> I haven't really looked into it, but a quick search gave me this thread
>> explaining the intention of the code in question:
>>
>> http://lists.lm-sensors.org/pipermail/i2c/2007-November/002268.html
>>
>> Regards,
>>
>>Wolfram
>>
>
> And adding a recent mail address from Mike to cc.
>
--
Sincerely yours,
Mike.
--
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] [media] [pvrusb2]: remove dead retry cmd code
Sorry been asleep at the wheel here. I'll take a look.
Please realize that the code path being talked about here HAS worked -
because the encoder does tend to fail and this is how the driver
recovers.
-Mike
On Fri, 16 Jan 2015, Hans Verkuil wrote:
> On 01/16/2015 12:29 PM, Haim Daniel wrote:
> > It looks that "if (try_count < 20) continue" jumps to end of the do ...
> > while(0) loop and goes out.
>
> Ah, you are right. But that is obviously not what was intended, so just
> removing
> it is not a proper 'fix'.
>
> Mike, can you take a look at this?
>
> Regards,
>
> Hans
>
> >
> > --hd.
> > On Fri, 2015-01-16 at 11:57 +0100, Hans Verkuil wrote:
> >> On 01/05/2015 11:38 PM, Haim Daniel wrote:
> >>> In case a command is timed out, current flow sets the retry_flag
> >>> and does nothing.
> >>
> >> Really? That's not how I read the code: it retries up to 20 times before
> >> bailing out.
> >>
> >> Perhaps you missed the "if (try_count < 20) continue;" line?
> >>
> >> Regards,
> >>
> >>Hans
> >>
> >>>
> >>> Signed-off-by: Haim Daniel
> >>> ---
> >>> drivers/media/usb/pvrusb2/pvrusb2-encoder.c | 15 +--
> >>> 1 file changed, 1 insertion(+), 14 deletions(-)
> >>>
> >>> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> >>> b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> >>> index f7702ae..02028aa 100644
> >>> --- a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> >>> +++ b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
> >>> @@ -145,8 +145,6 @@ static int pvr2_encoder_cmd(void *ctxt,
> >>> u32 *argp)
> >>> {
> >>> unsigned int poll_count;
> >>> - unsigned int try_count = 0;
> >>> - int retry_flag;
> >>> int ret = 0;
> >>> unsigned int idx;
> >>> /* These sizes look to be limited by the FX2 firmware implementation */
> >>> @@ -213,8 +211,6 @@ static int pvr2_encoder_cmd(void *ctxt,
> >>> break;
> >>> }
> >>>
> >>> - retry_flag = 0;
> >>> - try_count++;
> >>> ret = 0;
> >>> wrData[0] = 0;
> >>> wrData[1] = cmd;
> >>> @@ -245,11 +241,9 @@ static int pvr2_encoder_cmd(void *ctxt,
> >>> }
> >>> if (rdData[0] && (poll_count < 1000)) continue;
> >>> if (!rdData[0]) {
> >>> - retry_flag = !0;
> >>> pvr2_trace(
> >>> PVR2_TRACE_ERROR_LEGS,
> >>> - "Encoder timed out waiting for us"
> >>> - "; arranging to retry");
> >>> + "Encoder timed out waiting for us");
> >>> } else {
> >>> pvr2_trace(
> >>> PVR2_TRACE_ERROR_LEGS,
> >>> @@ -269,13 +263,6 @@ static int pvr2_encoder_cmd(void *ctxt,
> >>> ret = -EBUSY;
> >>> break;
> >>> }
> >>> - if (retry_flag) {
> >>> - if (try_count < 20) continue;
> >>> - pvr2_trace(
> >>> - PVR2_TRACE_ERROR_LEGS,
> >>> - "Too many retries...");
> >>> - ret = -EBUSY;
> >>> - }
> >>> if (ret) {
> >>> del_timer_sync(&hdw->encoder_run_timer);
> >>> hdw->state_encoder_ok = 0;
> >>>
> >>
> >
> >
>
> --
> 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
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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] next-20140324 drivers/staging/media/sn9c102/sn9c102_hv7131r.c fix style warnings flagged by checkpatch.pl.
Signed-off-by: Mike Sampson
---
drivers/staging/media/sn9c102/sn9c102_hv7131r.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/media/sn9c102/sn9c102_hv7131r.c
b/drivers/staging/media/sn9c102/sn9c102_hv7131r.c
index 26a9111..51b24e0 100644
--- a/drivers/staging/media/sn9c102/sn9c102_hv7131r.c
+++ b/drivers/staging/media/sn9c102/sn9c102_hv7131r.c
@@ -23,7 +23,7 @@
#include "sn9c102_devtable.h"
-static int hv7131r_init(struct sn9c102_device* cam)
+static int hv7131r_init(struct sn9c102_device *cam)
{
int err = 0;
@@ -137,8 +137,8 @@ static int hv7131r_init(struct sn9c102_device* cam)
}
-static int hv7131r_get_ctrl(struct sn9c102_device* cam,
- struct v4l2_control* ctrl)
+static int hv7131r_get_ctrl(struct sn9c102_device *cam,
+ struct v4l2_control *ctrl)
{
switch (ctrl->id) {
case V4L2_CID_GAIN:
@@ -176,8 +176,8 @@ static int hv7131r_get_ctrl(struct sn9c102_device* cam,
}
-static int hv7131r_set_ctrl(struct sn9c102_device* cam,
- const struct v4l2_control* ctrl)
+static int hv7131r_set_ctrl(struct sn9c102_device *cam,
+ const struct v4l2_control *ctrl)
{
int err = 0;
@@ -197,6 +197,7 @@ static int hv7131r_set_ctrl(struct sn9c102_device* cam,
case V4L2_CID_BLACK_LEVEL:
{
int r = sn9c102_i2c_read(cam, 0x01);
+
if (r < 0)
return -EIO;
err += sn9c102_i2c_write(cam, 0x01,
@@ -211,10 +212,10 @@ static int hv7131r_set_ctrl(struct sn9c102_device* cam,
}
-static int hv7131r_set_crop(struct sn9c102_device* cam,
- const struct v4l2_rect* rect)
+static int hv7131r_set_crop(struct sn9c102_device *cam,
+ const struct v4l2_rect *rect)
{
- struct sn9c102_sensor* s = sn9c102_get_sensor(cam);
+ struct sn9c102_sensor *s = sn9c102_get_sensor(cam);
int err = 0;
u8 h_start = (u8)(rect->left - s->cropcap.bounds.left) + 1,
v_start = (u8)(rect->top - s->cropcap.bounds.top) + 1;
@@ -226,8 +227,8 @@ static int hv7131r_set_crop(struct sn9c102_device* cam,
}
-static int hv7131r_set_pix_format(struct sn9c102_device* cam,
- const struct v4l2_pix_format* pix)
+static int hv7131r_set_pix_format(struct sn9c102_device *cam,
+ const struct v4l2_pix_format *pix)
{
int err = 0;
@@ -347,7 +348,7 @@ static const struct sn9c102_sensor hv7131r = {
};
-int sn9c102_probe_hv7131r(struct sn9c102_device* cam)
+int sn9c102_probe_hv7131r(struct sn9c102_device *cam)
{
int devid, err;
--
1.7.10.4
--
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 v6 0/5] clk: clock deregistration support
Quoting Sylwester Nawrocki (2013-10-15 13:04:17)
> Hi,
>
> (adding linux-media mailing list at Cc)
>
> On 09/25/2013 11:47 AM, Laurent Pinchart wrote:
> > On Tuesday 24 September 2013 23:38:44 Sylwester Nawrocki wrote:
> [...]
> >> The only issue I found might be at the omap3isp driver, which provides
> >> clock to its sub-drivers and takes reference on the sub-driver modules.
> >> When sub-driver calls clk_get() all modules would get locked in memory,
> >> due to circular reference. One solution to that could be to pass NULL
> >> struct device pointer, as in the below patch.
> >
> > Doesn't that introduce race conditions ? If the sub-drivers require the
> > clock,
> > they want to be sure that the clock won't disappear beyond their backs. I
> > agree that the circular dependency needs to be solved somehow, but we
> > probably
> > need a more generic solution. The problem will become more widespread in the
> > future with DT-based device instantiation in both V4L2 and KMS.
>
> I'm wondering whether subsystems and drivers itself should be written so
> they deal with such dependencies they are aware of.
>
> There is similar situation in the regulator API, regulator_get() simply
> takes a reference on a module providing the regulator object.
>
> Before a "more generic solution" is available, what do you think about
> keeping obtaining a reference on a clock provider module in clk_get() and
> doing clk_get(), clk_prepare_enable(), ..., clk_unprepare_disable(),
> clk_put() in sub-driver whenever a clock is actively used, to avoid
> permanent circular reference ?
Laurent,
Did you have any feedback on this proposal? I would like to merge these
patches so that folks with clock driver modules can use them properly.
We can fix up things in the core code as we figure them out.
Regards,
Mike
>
> --
> Thanks,
> Sylwester
>
> >> -8<--
> >> From ca5963041aad67e31324cb5d4d5e2cfce1706d4f Mon Sep 17 00:00:00 2001
> >> From: Sylwester Nawrocki
> >> Date: Thu, 19 Sep 2013 23:52:04 +0200
> >> Subject: [PATCH] omap3isp: Pass NULL device pointer to clk_register()
> >>
> >> Signed-off-by: Sylwester Nawrocki
> >> ---
> >>drivers/media/platform/omap3isp/isp.c | 15 ++-
> >>drivers/media/platform/omap3isp/isp.h |1 +
> >>2 files changed, 11 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/omap3isp/isp.c
> >> b/drivers/media/platform/omap3isp/isp.c
> >> index df3a0ec..d7f3c98 100644
> >> --- a/drivers/media/platform/omap3isp/isp.c
> >> +++ b/drivers/media/platform/omap3isp/isp.c
> >> @@ -290,9 +290,11 @@ static int isp_xclk_init(struct isp_device *isp)
> >> struct clk_init_data init;
> >> unsigned int i;
> >>
> >> +for (i = 0; i< ARRAY_SIZE(isp->xclks); ++i)
> >> +isp->xclks[i] = ERR_PTR(-EINVAL);
> >> +
> >> for (i = 0; i< ARRAY_SIZE(isp->xclks); ++i) {
> >> struct isp_xclk *xclk =&isp->xclks[i];
> >> -struct clk *clk;
> >>
> >> xclk->isp = isp;
> >> xclk->id = i == 0 ? ISP_XCLK_A : ISP_XCLK_B;
> >> @@ -306,9 +308,9 @@ static int isp_xclk_init(struct isp_device *isp)
> >>
> >> xclk->hw.init =&init;
> >>
> >> -clk = devm_clk_register(isp->dev,&xclk->hw);
> >> -if (IS_ERR(clk))
> >> -return PTR_ERR(clk);
> >> +xclk->clk = clk_register(NULL,&xclk->hw);
> >> +if (IS_ERR(xclk->clk))
> >> +return PTR_ERR(xclk->clk);
> >>
> >> if (pdata->xclks[i].con_id == NULL&&
> >> pdata->xclks[i].dev_id == NULL)
> >> @@ -320,7 +322,7 @@ static int isp_xclk_init(struct isp_device *isp)
> >>
> >> xclk->lookup->con_id = pdata->xclks[i].con_id;
> >> xclk->lookup->dev_id = pdata->xclks[i].dev_id;
> >> -xclk->lookup->clk = clk;
> >> +xclk->lookup->clk = xclk->clk;
> >>
> >> clkdev_add(xclk->lookup);
> >> }
> >> @@ -335,6 +337,9 @@ static void isp_xclk_cleanup(struct isp_device *isp)
> >> for (i = 0; i< ARRAY_SIZE(isp->xclks); ++i) {
> >> struct isp_xclk *xclk =&isp->xclks[
Re: [PATCH 02/14] pvrusb2: fix sparse warning
Acked-by: Mike Isely
-Mike
On Fri, 4 Oct 2013, Hans Verkuil wrote:
> From: Hans Verkuil
>
> drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2871:13: warning: symbol
> 'pvr2_hdw_get_detected_std' was not declared. Should it be static?
>
> Signed-off-by: Hans Verkuil
> Cc: Mike Isely
> ---
> drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> index c4d51d7..ea05f67 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> @@ -2868,7 +2868,7 @@ static void pvr2_subdev_set_control(struct pvr2_hdw
> *hdw, int id,
> pvr2_subdev_set_control(hdw, id, #lab, (hdw)->lab##_val); \
> }
>
> -v4l2_std_id pvr2_hdw_get_detected_std(struct pvr2_hdw *hdw)
> +static v4l2_std_id pvr2_hdw_get_detected_std(struct pvr2_hdw *hdw)
> {
> v4l2_std_id std;
> std = (v4l2_std_id)hdw->std_mask_avail;
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: [REVIEWv2 PATCH 07/12] pvrusb2: use v4l2_dev instead of the deprecated parent field.
Acked-By: Mike Isely
-Mike
On Wed, 12 Jun 2013, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/usb/pvrusb2/pvrusb2-hdw.c |4
> drivers/media/usb/pvrusb2/pvrusb2-hdw.h |4
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c |7 ---
> 3 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> index d329209..c4d51d7 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> @@ -2704,6 +2704,10 @@ static void pvr2_hdw_remove_usb_stuff(struct pvr2_hdw
> *hdw)
> pvr2_hdw_render_useless(hdw);
> }
>
> +void pvr2_hdw_set_v4l2_dev(struct pvr2_hdw *hdw, struct video_device *vdev)
> +{
> + vdev->v4l2_dev = &hdw->v4l2_dev;
> +}
>
> /* Destroy hardware interaction structure */
> void pvr2_hdw_destroy(struct pvr2_hdw *hdw)
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.h
> b/drivers/media/usb/pvrusb2/pvrusb2-hdw.h
> index 1a135cf..4184707 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.h
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.h
> @@ -22,6 +22,7 @@
>
> #include
> #include
> +#include
> #include "pvrusb2-io.h"
> #include "pvrusb2-ctrl.h"
>
> @@ -138,6 +139,9 @@ const char *pvr2_hdw_get_device_identifier(struct
> pvr2_hdw *);
> /* Called when hardware has been unplugged */
> void pvr2_hdw_disconnect(struct pvr2_hdw *);
>
> +/* Sets v4l2_dev of a video_device struct */
> +void pvr2_hdw_set_v4l2_dev(struct pvr2_hdw *, struct video_device *);
> +
> /* Get the number of defined controls */
> unsigned int pvr2_hdw_get_ctrl_count(struct pvr2_hdw *);
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> index 82f619b..d77069e 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -870,8 +871,8 @@ static void pvr2_v4l2_dev_destroy(struct pvr2_v4l2_dev
> *dip)
> static void pvr2_v4l2_dev_disassociate_parent(struct pvr2_v4l2_dev *dip)
> {
> if (!dip) return;
> - if (!dip->devbase.parent) return;
> - dip->devbase.parent = NULL;
> + if (!dip->devbase.v4l2_dev->dev) return;
> + dip->devbase.v4l2_dev->dev = NULL;
> device_move(&dip->devbase.dev, NULL, DPM_ORDER_NONE);
> }
>
> @@ -1321,7 +1322,7 @@ static void pvr2_v4l2_dev_init(struct pvr2_v4l2_dev
> *dip,
> if (nr_ptr && (unit_number >= 0) && (unit_number < PVR_NUM)) {
> mindevnum = nr_ptr[unit_number];
> }
> - dip->devbase.parent = &usbdev->dev;
> + pvr2_hdw_set_v4l2_dev(hdw, &dip->devbase);
> if ((video_register_device(&dip->devbase,
> dip->v4l_type, mindevnum) < 0) &&
> (video_register_device(&dip->devbase,
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 v8 1/7] media: V4L2: add temporary clock helpers
Quoting Barry Song (2013-04-11 01:59:28) > 2013/4/11 Guennadi Liakhovetski : > > On Thu, 11 Apr 2013, Barry Song wrote: > > > >> 2013/4/11 Guennadi Liakhovetski : > >> > Hi Barry > >> > > >> > On Thu, 11 Apr 2013, Barry Song wrote: > >> > > >> >> Hi Guennadi, > >> >> > >> >> > Typical video devices like camera sensors require an external clock > >> >> > source. > >> >> > Many such devices cannot even access their hardware registers without > >> >> > a > >> >> > running clock. These clock sources should be controlled by their > >> >> > consumers. > >> >> > This should be performed, using the generic clock framework. > >> >> > Unfortunately > >> >> > so far only very few systems have been ported to that framework. This > >> >> > patch > >> >> > adds a set of temporary helpers, mimicking the generic clock API, to > >> >> > V4L2. > >> >> > Platforms, adopting the clock API, should switch to using it. > >> >> > Eventually > >> >> > this temporary API should be removed. > >> >> > >> >> > Signed-off-by: Guennadi Liakhovetski > >> >> > --- > >> >> > >> >> for your patch 1/8 and 3/8, i think it makes a lot of senses to let > >> >> the object manages its own clock by itself. > >> >> is it possible for us to implement v4l2-clk.c directly as an instance > >> >> of standard clk driver for those systems which don't have generic > >> >> clock, and remove the V4L2 clock APIs like v4l2_clk_get, > >> >> v4l2_clk_enable from the first day? i mean v4l2-clk.c becomes a temp > >> >> and fake clock controller driver. finally, after people have > >> >> generically clk, remove it. > >> > > >> > I don't think you can force-enable the CFF on systems, that don't support > >> > it, e.g. PXA. > >> > >> yes. we can. clock is only a framework, has it any limitation to > >> implement a driver instance on any platform? > > > > So, you enable CFF, it provides its own clk_* implementation like > > clk_get_rate() etc. Now, PXA already has it defined in > > arch/arm/mach-pxa/clock.c. Don't think this is going to fly. > > agree. > Hi, I came into this thread late and don't have the actual patches in my inbox for review. That said, I don't understand why V4L2 cares about the clk framework *implementation*? The clk.h api is the same for platforms using the common struct clk and those still using the legacy method of defining their own struct clk. If drivers are only consumers of the clk.h api then the implementation underneath should not matter. Regards, Mike > > > > Thanks > > Guennadi > > > >> people have tried to move to common clk and generic framework for a > >> long time, now you still try to provide a v4l2 specific clock APIs, it > >> just makes v4l2 unacceptable and much complex. > >> > >> > > >> > Thanks > >> > Guennadi > >> > > >> >> > v8: Updated both (C) dates > >> >> > >> >> > drivers/media/v4l2-core/Makefile |2 +- > >> >> > drivers/media/v4l2-core/v4l2-clk.c | 177 > >> >> > > >> >> > include/media/v4l2-clk.h | 54 +++ > >> >> > 3 files changed, 232 insertions(+), 1 deletions(-) > >> >> > create mode 100644 drivers/media/v4l2-core/v4l2-clk.c > >> >> > create mode 100644 include/media/v4l2-clk.h > >> >> > >> >> > diff --git a/drivers/media/v4l2-core/Makefile > >> >> > b/drivers/media/v4l2-core/Makefile > >> >> > index aa50c46..628c630 100644 > >> >> > --- a/drivers/media/v4l2-core/Makefile > >> >> > +++ b/drivers/media/v4l2-core/Makefile > >> >> > @@ -5,7 +5,7 @@ > >> >> > tuner-objs := tuner-core.o > >> >> > >> >> > videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o > >> >> > v4l2-fh.o \ > >> >> > - v4l2-event.o v4l2-ctrls.o v4l2-subdev.o > >> >> > + v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o > >> >> > ifeq ($(CONFIG_COMPAT),y) > >> >> >videodev-objs += v4l2-compat-ioctl32.o > >> >> > endif > >> >> > diff --git a/drivers/media/v4l2-core/v4l2-clk.c > >> >> > b/drivers/media/v4l2-core/v4l2-clk.c > >> >> > new file mode 100644 > >> >> > index 000..d7cc13e > >> >> > --- /dev/null > >> >> > +++ b/drivers/media/v4l2-core/v4l2-clk.c > >> >> > @@ -0,0 +1,177 @@ > >> >> > >> >> -barry > > -barry > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 v2 1/2] omap3isp: Use the common clock framework
Quoting Laurent Pinchart (2013-04-04 04:51:40)
> Expose the two ISP external clocks XCLKA and XCLKB as common clocks for
> subdev drivers.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Mike Turquette
Regards,
Mike
> ---
> drivers/media/platform/omap3isp/isp.c | 270
> --
> drivers/media/platform/omap3isp/isp.h | 22 ++-
> include/media/omap3isp.h | 10 +-
> 3 files changed, 218 insertions(+), 84 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c
> index 6e5ad8e..694470d 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -55,6 +55,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -148,6 +149,194 @@ void omap3isp_flush(struct isp_device *isp)
> isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_REVISION);
> }
>
> +/*
> -
> + * XCLK
> + */
> +
> +#define to_isp_xclk(_hw) container_of(_hw, struct isp_xclk, hw)
> +
> +static void isp_xclk_update(struct isp_xclk *xclk, u32 divider)
> +{
> + switch (xclk->id) {
> + case ISP_XCLK_A:
> + isp_reg_clr_set(xclk->isp, OMAP3_ISP_IOMEM_MAIN,
> ISP_TCTRL_CTRL,
> + ISPTCTRL_CTRL_DIVA_MASK,
> + divider << ISPTCTRL_CTRL_DIVA_SHIFT);
> + break;
> + case ISP_XCLK_B:
> + isp_reg_clr_set(xclk->isp, OMAP3_ISP_IOMEM_MAIN,
> ISP_TCTRL_CTRL,
> + ISPTCTRL_CTRL_DIVB_MASK,
> + divider << ISPTCTRL_CTRL_DIVB_SHIFT);
> + break;
> + }
> +}
> +
> +static int isp_xclk_prepare(struct clk_hw *hw)
> +{
> + struct isp_xclk *xclk = to_isp_xclk(hw);
> +
> + omap3isp_get(xclk->isp);
> +
> + return 0;
> +}
> +
> +static void isp_xclk_unprepare(struct clk_hw *hw)
> +{
> + struct isp_xclk *xclk = to_isp_xclk(hw);
> +
> + omap3isp_put(xclk->isp);
> +}
> +
> +static int isp_xclk_enable(struct clk_hw *hw)
> +{
> + struct isp_xclk *xclk = to_isp_xclk(hw);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&xclk->lock, flags);
> + isp_xclk_update(xclk, xclk->divider);
> + xclk->enabled = true;
> + spin_unlock_irqrestore(&xclk->lock, flags);
> +
> + return 0;
> +}
> +
> +static void isp_xclk_disable(struct clk_hw *hw)
> +{
> + struct isp_xclk *xclk = to_isp_xclk(hw);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&xclk->lock, flags);
> + isp_xclk_update(xclk, 0);
> + xclk->enabled = false;
> + spin_unlock_irqrestore(&xclk->lock, flags);
> +}
> +
> +static unsigned long isp_xclk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct isp_xclk *xclk = to_isp_xclk(hw);
> +
> + return parent_rate / xclk->divider;
> +}
> +
> +static u32 isp_xclk_calc_divider(unsigned long *rate, unsigned long
> parent_rate)
> +{
> + u32 divider;
> +
> + if (*rate >= parent_rate) {
> + *rate = parent_rate;
> + return ISPTCTRL_CTRL_DIV_BYPASS;
> + }
> +
> + divider = DIV_ROUND_CLOSEST(parent_rate, *rate);
> + if (divider >= ISPTCTRL_CTRL_DIV_BYPASS)
> + divider = ISPTCTRL_CTRL_DIV_BYPASS - 1;
> +
> + *rate = parent_rate / divider;
> + return divider;
> +}
> +
> +static long isp_xclk_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
> + isp_xclk_calc_divider(&rate, *parent_rate);
> + return rate;
> +}
> +
> +static int isp_xclk_set_rate(struct clk_hw *hw, unsigned long rate,
> +unsigned long parent_rate)
> +{
> + struct isp_xclk *xclk = to_isp_xclk(hw);
> + unsigned long flags;
> + u32 divider;
> +
> + divider = isp_xclk_calc_divider(&rate, parent_rate);
> +
> + spin_lock_irqsave(&xclk->lock, flags);
> +
> + xclk->divider = divider;
> + if (xclk->enabled)
> + isp_xclk_update(xclk, divider);
> +
> + spin_unlock_irqrestore(&xclk->lock, flags);
> +
> + dev_dbg(xclk->isp->dev, "%s: cam_xclk%c set to %lu Hz (div %u)\n",
> + __func__, xclk->id
Re: [PATCH] [media] s5p-mfc: Change MFC clock reference w.r.t Common Clock Framework
Quoting Prasanna Kumar (2013-03-25 22:20:51)
> From: Prasanna Kumar
>
> According to Common Clock framework , modified the method of getting
> clock for MFC Block.
>
> Signed-off-by: Prasanna Kumar
> ---
> drivers/media/platform/s5p-mfc/s5p_mfc_pm.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
> index 6aa38a5..b8ac8f6 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
> @@ -50,7 +50,7 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
> goto err_p_ip_clk;
> }
>
> - pm->clock = clk_get(&dev->plat_dev->dev, dev->variant->mclk_name);
> + pm->clock = clk_get_parent(pm->clock_gate);
Ok, I'll bite. Why make this change? Was there an issue using
clkdev/clk_get to get the clock you needed?
Regards,
Mike
> if (IS_ERR(pm->clock)) {
> mfc_err("Failed to get MFC clock\n");
> ret = PTR_ERR(pm->clock);
> --
> 1.7.5.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: dvb-usb-it913x dissapeared kernel 3.7.2
On 21/01/2013, Mauro Carvalho Chehab wrote: > Em Mon, 21 Jan 2013 15:47:49 + > Mike Martin escreveu: > >> After updating the kernel on Fedora 18 module dvb-usb-it913x seems to >> have dissapeared. >> >> This has meant my dvb stick ( ID 1b80:e409 Afatech IT9137FN Dual DVB-T >> [KWorld UB499-2T]) no longer works >> >> Is this a Redhat only thing or is it upstream > > See this bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=895460 > > Basically, DVB_USB_V2 wasn't selected. The kernel-3.7.2-204.fc18 should > fix this issue. > >> -- >> 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 > > > -- > > Cheers, > Mauro > Seems to be fixed now -- 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/2] OMAP3 ISP: Simplify clock usage
Quoting Laurent Pinchart (2013-01-21 10:54:38) > Hi Tony, > > On Monday 21 January 2013 09:18:12 Tony Lindgren wrote: > > * Laurent Pinchart [130121 05:37]: > > > On Monday 14 January 2013 17:10:15 Mike Turquette wrote: > > > > Quoting Laurent Pinchart (2013-01-08 05:43:52) > > > > > > > > > Hello, > > > > > > > > > > Now that the OMAP3 supports the common clock framework, clock rate > > > > > back-propagation is available for the ISP clocks. Instead of setting > > > > > the cam_mclk parent clock rate to control the cam_mclk clock rate, we > > > > > can mark the dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting > > > > > back-propagation, and set the cam_mclk rate directly. This simplifies > > > > > the ISP clocks configuration. > > > > > > > > I'm pleased to see this feature get used on OMAP. Plus your driver gets > > > > a negative diffstat :) > > > > > > > > Reviewed-by: Mike Turquette > > > > > > Thanks. > > > > > > Would you like to take the arch/ patch in your tree, or should I push it > > > through the linux-media tree along with the omap3isp patch ? > > > > The arch/arm/*omap* clock changes need to be queued by Paul to avoid > > potential stupid merge conflicts when the clock data gets moved to > > live under drivers/clk/omap. > > OK. The omap3isp patch can go through Paul's tree as well, it won't conflict > with other changes to the driver in this merge window. > > Paul, can you take both patches together ? If so I'll send you a pull request. > +1 I don't take in driver changes/adaptations through the clk tree unless it is necessary to avoid painful conflicts or merge ordering issues. This has only happened a few times for MFD devices, etc. Typically the clk-next branch is only used for changes to the clk framework core or clk drivers. Regards, Mike > -- > Regards, > > Laurent Pinchart -- 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
dvb-usb-it913x dissapeared kernel 3.7.2
After updating the kernel on Fedora 18 module dvb-usb-it913x seems to have dissapeared. This has meant my dvb stick ( ID 1b80:e409 Afatech IT9137FN Dual DVB-T [KWorld UB499-2T]) no longer works Is this a Redhat only thing or is it upstream -- 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/2] OMAP3 ISP: Simplify clock usage
Quoting Laurent Pinchart (2013-01-08 05:43:52) > Hello, > > Now that the OMAP3 supports the common clock framework, clock rate > back-propagation is available for the ISP clocks. Instead of setting the > cam_mclk parent clock rate to control the cam_mclk clock rate, we can mark the > dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting back-propagation, and set > the cam_mclk rate directly. This simplifies the ISP clocks configuration. > I'm pleased to see this feature get used on OMAP. Plus your driver gets a negative diffstat :) Reviewed-by: Mike Turquette > Laurent Pinchart (2): > ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to > dpll4_m5 > omap3isp: Set cam_mclk rate directly > > arch/arm/mach-omap2/cclock3xxx_data.c | 10 +- > drivers/media/platform/omap3isp/isp.c | 18 ++ > drivers/media/platform/omap3isp/isp.h |8 +++- > 3 files changed, 14 insertions(+), 22 deletions(-) > > -- > Regards, > > Laurent Pinchart -- 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
s5p-mfc cyclic refresh and slicing
I'm using the MFC on an S5PV210 to encode H264. I'm interested in enabling cyclic intra refresh and fixed size slices. I've set the controls V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB to 1 V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE to V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_BYTES V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_BYTES to 20 * 1024 I've checked that these are making it to the driver, but they seem to have no effect on the encode. Are there any limitations, or other controls that need to be set to enable these? Cheers, Mike -- 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 33/68] [media] pvrusb2: get rid of warning: no previous prototype
Acked-By: Mike Isely
On Sat, 27 Oct 2012, Mauro Carvalho Chehab wrote:
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c:199:5: warning: no previous
> prototype for 'pvr2_s_std' [-Wmissing-prototypes]
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c:368:5: warning: no previous
> prototype for 'pvr2_s_frequency' [-Wmissing-prototypes]
>
> Cc: Mike Isely
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> index db249ca..6930676 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> @@ -196,7 +196,7 @@ static int pvr2_g_std(struct file *file, void *priv,
> v4l2_std_id *std)
> return ret;
> }
>
> -int pvr2_s_std(struct file *file, void *priv, v4l2_std_id *std)
> +static int pvr2_s_std(struct file *file, void *priv, v4l2_std_id *std)
> {
> struct pvr2_v4l2_fh *fh = file->private_data;
> struct pvr2_hdw *hdw = fh->channel.mc_head->hdw;
> @@ -365,7 +365,7 @@ static int pvr2_s_tuner(struct file *file, void *priv,
> struct v4l2_tuner *vt)
> vt->audmode);
> }
>
> -int pvr2_s_frequency(struct file *file, void *priv, struct v4l2_frequency
> *vf)
> +static int pvr2_s_frequency(struct file *file, void *priv, struct
> v4l2_frequency *vf)
> {
> struct pvr2_v4l2_fh *fh = file->private_data;
> struct pvr2_hdw *hdw = fh->channel.mc_head->hdw;
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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] pvr2: fix minor storage
Completely agree! Thanks for spotting that one.
Signed-off-by: Mike Isely
-Mike
On Thu, 25 Oct 2012, Alan Cox wrote:
> From: Alan Cox
>
> This should have break statements in it.
>
> Signed-off-by: Alan Cox
> ---
>
> drivers/media/usb/pvrusb2/pvrusb2-hdw.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> index fb828ba..299751a 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> @@ -3563,9 +3563,9 @@ void pvr2_hdw_v4l_store_minor_number(struct pvr2_hdw
> *hdw,
>enum pvr2_v4l_type index,int v)
> {
> switch (index) {
> - case pvr2_v4l_type_video: hdw->v4l_minor_number_video = v;
> - case pvr2_v4l_type_vbi: hdw->v4l_minor_number_vbi = v;
> - case pvr2_v4l_type_radio: hdw->v4l_minor_number_radio = v;
> + case pvr2_v4l_type_video: hdw->v4l_minor_number_video = v;break;
> + case pvr2_v4l_type_vbi: hdw->v4l_minor_number_vbi = v;break;
> + case pvr2_v4l_type_radio: hdw->v4l_minor_number_radio = v;break;
> default: break;
> }
> }
>
> --
> 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
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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
MFC Encode on S5PV210 hangs
Hi All, I'm trying to use the MFC encoder to generate an H264 bitstream using the V4L2 interface. I've tried using my own application, and also the example encode application here: git://git.infradead.org/users/kmpark/public-apps Both exhibit the same behavior. Input frames are queued up until the input queue is full, but only one frame is emitted (which I guess is the H264 header). The encoder then just sits there. I'm not sure where to start looking, so any advice is appreciated. Cheers, Mike -- 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: RFC: Core + Radio profile
On Wed, 22 Aug 2012, Mauro Carvalho Chehab wrote: > Em 22-08-2012 07:11, Hans Verkuil escreveu: > > I've added some more core profile requirements. > > >> > >> Streaming I/O is not supported by radio nodes. > > Hmm... pvrusb2/ivtv? Ok, it makes sense to move it to use the alsa > mpeg API there. If we're enforcing it, we should deprecate the current way > there, and make it use ALSA. I am unaware of any ALSA MPEG API. It's entirely likely that this is because I haven't been paying attention. Nevertheless, can you please point me at any documentation on this so I can get up to speed? Currently the pvrusb2 driver does not attempt to perform any processing or filtering of the data stream, so radio data is just the same mpeg stream as video (but without any real embedded video data). If I have to get into the business of processing the MPEG data in order to adhere to this proposal, then that will be a very big deal for this driver. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: s5p-fimc capturing interlaced BT656
Hi Sylwester, On Fri, 2012-08-03 at 21:17 +0200, Sylwester Nawrocki wrote: > Hi Mike, > > On 08/02/2012 02:48 PM, Mike Dyer wrote: > > Hi All, > > > > I'm using the S5PV210 camera IF and capturing BT656 video from a TVP5150 > > video decoder. > > > > I notice that the capture driver ignores the field interlace flags > > reported by the 'sensor' and always uses 'V4L2_FIELD_NONE'. It also > > seems each field ends up in it's own frame, using only half the height. > > s5p-fimc driver doesn't support the interlaced video capture, as we had > no such use case yet. Patches adding it are welcome. > > > What would need to be done to store both fields in a single frame, for > > example in a V4L2_FIELD_INTERLACE_TB/BT format? > > Firstly, it would good to figure out FIMC register settings that would > allow storing both fields in a single frame. I _suspect_ it's as simple > as setting CAM_INTERLACE bit in CIGCTRL register. Have you perhaps tried > it already ? > > For a quick test a patch as below might be sufficient. > > > diff --git a/drivers/media/video/s5p-fimc/fimc-reg.c > b/drivers/media/video/s5p-fimc/fimc-reg.c > index 1fc4ce8..19afa1a 100644 > --- a/drivers/media/video/s5p-fimc/fimc-reg.c > +++ b/drivers/media/video/s5p-fimc/fimc-reg.c > @@ -576,6 +576,8 @@ int fimc_hw_set_camera_polarity(struct fimc_dev *fimc, > if (cam->flags & V4L2_MBUS_FIELD_EVEN_LOW) > cfg |= FIMC_REG_CIGCTRL_INVPOLFIELD; > > + cfg |= FIMC_REG_CIGCTRL_INTERLACE; > + > writel(cfg, fimc->regs + FIMC_REG_CIGCTRL); > > return 0; > > > -- > > Thanks, > Sylwester I have indeed tried setting that, but with no effect. However, checking through the datasheet for the FIMC I discovered a DMA output (CIOCTRL) register bit called 'Weave_Out'. The description is: "Even and Odd fields can be weaved together and combined to form a complete progressive frame by hardware. This field is useful for interlace DMA output mode (Interlace_out or CAM_INTERLACE). Even field address (1st frame start address) is used weave address. Odd fields address (2nd frame start address) is ignored." This does produce full sized frames, but I still seem to only be getting one field per frame, with a blank line inserted between each real line. Setting both interlace and weave doesn't seem to help. So, something still missing... I wonder if the irq handler is getting called for each field, maybe we need to wait for two interrupts before dequeing the frame? Cheers, Mike -- 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
s5p-fimc capturing interlaced BT656
Hi All, I'm using the S5PV210 camera IF and capturing BT656 video from a TVP5150 video decoder. I notice that the capture driver ignores the field interlace flags reported by the 'sensor' and always uses 'V4L2_FIELD_NONE'. It also seems each field ends up in it's own frame, using only half the height. What would need to be done to store both fields in a single frame, for example in a V4L2_FIELD_INTERLACE_TB/BT format? Cheers, Mike -- 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] pvrusb2: Declare MODULE_FIRMWARE usage
Acked-By: Mike Isely
-Mike
On Thu, 26 Jul 2012, Tim Gardner wrote:
> Cc: Mike Isely
> Cc: Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Tim Gardner
> ---
> drivers/media/video/pvrusb2/pvrusb2-devattr.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
> b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
> index d8c8982..adc501d3 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
> @@ -54,8 +54,9 @@ static const struct pvr2_device_client_desc
> pvr2_cli_29xxx[] = {
> { .module_id = PVR2_CLIENT_ID_DEMOD },
> };
>
> +#define PVR2_FIRMWARE_29xxx "v4l-pvrusb2-29xxx-01.fw"
> static const char *pvr2_fw1_names_29xxx[] = {
> - "v4l-pvrusb2-29xxx-01.fw",
> + PVR2_FIRMWARE_29xxx,
> };
>
> static const struct pvr2_device_desc pvr2_device_29xxx = {
> @@ -87,8 +88,9 @@ static const struct pvr2_device_client_desc
> pvr2_cli_24xxx[] = {
> { .module_id = PVR2_CLIENT_ID_DEMOD },
> };
>
> +#define PVR2_FIRMWARE_24xxx "v4l-pvrusb2-24xxx-01.fw"
> static const char *pvr2_fw1_names_24xxx[] = {
> - "v4l-pvrusb2-24xxx-01.fw",
> + PVR2_FIRMWARE_24xxx,
> };
>
> static const struct pvr2_device_desc pvr2_device_24xxx = {
> @@ -369,8 +371,9 @@ static const struct pvr2_device_client_desc
> pvr2_cli_73xxx[] = {
> .i2c_address_list = "\x42"},
> };
>
> +#define PVR2_FIRMWARE_73xxx "v4l-pvrusb2-73xxx-01.fw"
> static const char *pvr2_fw1_names_73xxx[] = {
> - "v4l-pvrusb2-73xxx-01.fw",
> + PVR2_FIRMWARE_73xxx,
> };
>
> static const struct pvr2_device_desc pvr2_device_73xxx = {
> @@ -475,8 +478,9 @@ static const struct pvr2_dvb_props pvr2_751xx_dvb_props =
> {
> };
> #endif
>
> +#define PVR2_FIRMWARE_75xxx "v4l-pvrusb2-73xxx-01.fw"
> static const char *pvr2_fw1_names_75xxx[] = {
> - "v4l-pvrusb2-73xxx-01.fw",
> + PVR2_FIRMWARE_75xxx,
> };
>
> static const struct pvr2_device_desc pvr2_device_750xx = {
> @@ -556,7 +560,10 @@ struct usb_device_id pvr2_device_table[] = {
> };
>
> MODULE_DEVICE_TABLE(usb, pvr2_device_table);
> -
> +MODULE_FIRMWARE(PVR2_FIRMWARE_29xxx);
> +MODULE_FIRMWARE(PVR2_FIRMWARE_24xxx);
> +MODULE_FIRMWARE(PVR2_FIRMWARE_73xxx);
> +MODULE_FIRMWARE(PVR2_FIRMWARE_75xxx);
>
> /*
>Stuff for Emacs to see, in order to encourage consistent editing style:
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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
atsc_epg 64-bit bug / fault tolerance
I was looking at using the dvb-apps when I had a hangup with atsc_epg.
This issue had been previously reported from what I found at
http://www.mail-archive.com/linux-media@vger.kernel.org/msg44661.html
but had not been resolved from what I could tell.
Below I'm including a patch to fix the segfault on 64-bit builds and
also to improve tolerance of the fault I found when a segment was read
with a mode of '?' (don't ask me why, but I could try to give more
information if desired).
The first three changes in the patch are about using an appropriately
sized type rather than casting a pointer to a larger type; this fixes
the segfault. The last change involves nulling the title text when it
fails to parse rather than failing altogether.
Thanks,
Mike Slegeir
diff -r 4030c51d6e7b util/atsc_epg/atsc_epg.c
--- a/util/atsc_epg/atsc_epg.cTue Apr 10 16:44:06 2012 +0200
+++ b/util/atsc_epg/atsc_epg.cSat May 12 18:15:04 2012 -0500
@@ -60,8 +60,8 @@
void (*old_handler)(int);
struct atsc_string_buffer {
-int buf_len;
-int buf_pos;
+size_t buf_len;
+size_t buf_pos;
char *string;
};
@@ -507,8 +507,8 @@
event->msg_pos = channel->msg_buf.buf_pos;
if(0 > atsc_text_segment_decode(seg,
(uint8_t **)&channel->msg_buf.string,
-(size_t *)&channel->msg_buf.buf_len,
-(size_t *)&channel->msg_buf.buf_pos)) {
+ &channel->msg_buf.buf_len,
+ &channel->msg_buf.buf_pos)) {
fprintf(stderr, "%s(): error calling "
"atsc_text_segment_decode()\n",
__FUNCTION__);
@@ -653,15 +653,18 @@
e_info->title_pos = curr_info->title_buf.buf_pos;
if(0 > atsc_text_segment_decode(seg,
(uint8_t **)&curr_info->title_buf.string,
-(size_t *)&curr_info->title_buf.buf_len,
-(size_t *)&curr_info->title_buf.buf_pos)) {
+ &curr_info->title_buf.buf_len,
+ &curr_info->title_buf.buf_pos)) {
fprintf(stderr, "%s(): error calling "
"atsc_text_segment_decode()\n",
__FUNCTION__);
-return -1;
+e_info->title_len = 0;
}
-e_info->title_len = curr_info->title_buf.buf_pos -
-e_info->title_pos + 1;
+else
+{
+e_info->title_len = curr_info->title_buf.buf_pos -
+e_info->title_pos + 1;
+}
}
}
}
--
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
[GIT PULL FOR 3.5] pvrusb2 driver updates
Mauro: Please pull - this includes a long-awaited change courtesy of Hans Verkuil which finally transitions the driver to video_ioctl2. -Mike Isely The following changes since commit a1ac5dc28d2b4ca78e183229f7c595ffd725241c: [media] gspca - sn9c20x: Change the exposure setting of Omnivision sensors (2012-05-03 15:29:56 -0300) are available in the git repository at: git://git.linuxtv.org/mcisely/pvrusb2-20120504.git pvrusb2-merge-20120504 Hans Verkuil (1): pvrusb2: convert to video_ioctl2 Mike Isely (9): pvrusb2: Stop statically initializing reserved struct fields to zero pvrusb2: Clean up pvr2_hdw_get_detected_std() pvrusb2: Implement querystd for videodev_ioctl2 pvrusb2: Transform video standard detection result into read-only control ID pvrusb2: Fix truncated video standard names (trivial) pvrusb2: Base available video standards on what hardware supports pvrusb2: Trivial tweak to get rid of some redundant dereferences pvrusb2: Get rid of obsolete code for video standard enumeration pvrusb2: For querystd, start with list of hardware-supported standards drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h |6 +- drivers/media/video/pvrusb2/pvrusb2-hdw.c | 193 +--- drivers/media/video/pvrusb2/pvrusb2-hdw.h |9 +- drivers/media/video/pvrusb2/pvrusb2-v4l2.c | 1343 ++-- 4 files changed, 735 insertions(+), 816 deletions(-) -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
Compusa VC-211A no video
I'm having a tough time getting a Compusa "VC-211A" USB video grabber working under Fedora 16 on a Dell E521. [root@shellder ~]# uname -a Linux shellder.falciani.com 3.1.9-1.fc16.i686 #1 SMP Fri Jan 13 17:14:41 UTC 2012 i686 i686 i386 GNU/Linux Jan 22 15:15:44 shellder kernel: [59072.105044] usb 1-7: new high speed USB device number 5 using ehci_hcd Jan 22 15:15:44 shellder kernel: [59072.220074] usb 1-7: New USB device found, idVendor=eb1a, idProduct=2820 Jan 22 15:15:44 shellder kernel: [59072.220081] usb 1-7: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Jan 22 15:15:44 shellder kernel: [59072.220656] em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0) Jan 22 15:15:44 shellder kernel: [59072.220815] em28xx #0: chip ID is em2820 (or em2710) Jan 22 15:15:44 shellder kernel: [59072.290926] em28xx #0: board has no eeprom Jan 22 15:15:44 shellder kernel: [59072.337170] em28xx #0: found i2c device @ 0x4a [saa7113h] Jan 22 15:15:44 shellder kernel: [59072.370919] em28xx #0: Your board has no unique USB ID. Jan 22 15:15:44 shellder kernel: [59072.370924] em28xx #0: A hint were successfully done, based on i2c devicelist hash. Jan 22 15:15:44 shellder kernel: [59072.370929] em28xx #0: This method is not 100% failproof. Jan 22 15:15:44 shellder kernel: [59072.370934] em28xx #0: If the board were missdetected, please email this log to: Jan 22 15:15:44 shellder kernel: [59072.370938] em28xx #0: V4L Mailing List Jan 22 15:15:44 shellder kernel: [59072.370943] em28xx #0: Board detected as EM2860/SAA711X Reference Design Jan 22 15:15:44 shellder kernel: [59072.434031] em28xx #0: Identified as EM2860/SAA711X Reference Design (card=19) Jan 22 15:15:44 shellder kernel: [59072.434037] em28xx #0: Registering snapshot button... Jan 22 15:15:44 shellder kernel: [59072.434165] input: em28xx snapshot button as /devices/pci:00/:00:0b.1/usb1/1-7/input/input17 Jan 22 15:15:44 shellder kernel: [59072.701150] saa7115 6-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx #0) Jan 22 15:15:45 shellder kernel: [59073.146869] em28xx #0: Config register raw data: 0x00 Jan 22 15:15:45 shellder kernel: [59073.173739] em28xx #0: v4l2 driver version 0.1.3 Jan 22 15:15:45 shellder kernel: [59073.427419] em28xx #0: V4L2 video device registered as video0 Jan 22 15:15:45 shellder mtp-probe: checking bus 1, device 5: "/sys/devices/pci:00/:00:0b.1/usb1/1-7" Jan 22 15:15:45 shellder mtp-probe: bus: 1, device: 5 was not an MTP device UCView and VLC: No video to be captured lsusb (at a later date) Bus 001 Device 005: ID eb1a:2820 eMPIA Technology, Inc. I've tried: modprobe -r em28xx modprobe em28xx card=74 Results: No video UCview modprobe -r em28xx modprobe em28xx card=5 Results: No video UCview modprobe -r em28xx modprobe em28xx card=1 Results: No video UCview Any ideas? I had great hope in the card=74 until I saw that it expected a EM2800 and this seems to be a EM2820. Also, the device looks a lot like this but is marked differently http://www.cooldrives.com/usb-video-vcr-camcorder-analog-video-svideo-adapter.html Any idea on how to select Composite Video input? Thanks -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mike Falciani http://nj.falciani.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
DVB - attach to an open frontend device
Not too sure if this is possible but what I want to do is this open frontend set frequency add demux filters etc record then while this is running I want to attach to the same process and add further demux filters (without retuning - same frequency) any tips? -- 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] [media] v4l2: punt generated pdf files
On Wed, Oct 26, 2011 at 09:24, Mike Frysinger wrote: > These don't belong in the tree, and we have a .gitignore on them already > (not sure how these slipped in), so punt the compiled files. hrm, i thought default git send-email/format-patch didn't include binary updates when deleting in the diff. not sure what's going on here. i can resend if people want with the -D flag. -mike -- 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: Problem with TeVii S-470
24.10.2011 17:32, Josu Lazkano пишет: 2011/10/24 Mike Mironov: 24.10.2011 15:29, Josu Lazkano пишет: 2011/10/24 Mike Mironov: Hello! I have this card http://www.linuxtv.org/wiki/index.php/TeVii_S470 I try to use it under Debian Squeeze, but I can't get channel data from it. I try to use drivers from 2.6.38, 2.6.39 kernels, s2-liplianin drivers Hello again, actually, I am using this method for Tevii S660 and S470: apt-get install linux-headers-`uname -r` build-essential mkdir /usr/local/src/dvb cd /usr/local/src/dvb wget http://mercurial.intuxication.org/hg/s2-liplianin/archive/tip.zip unzip tip.zip cd s2-liplianin-0b7d3cc65161 make CONFIG_DVB_FIREDTV:=n make install Both methods works for me on a Debian Squeeze (2.6.32). Here more info: http://linuxtv.org/wiki/index.php/TeVii_S470 As your can see in quoted text I always try to use this drivers. Result is same. I'll always read WiKi link. I know that another users use this card without problems. I have good signal quality (88% signal and 79-80% snr). But in my 2 linux systems I can't get channel data. Scan work fine(!). -- 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: Problem with TeVii S-470
24.10.2011 15:29, Josu Lazkano пишет: 2011/10/24 Mike Mironov: Hello! I have this card http://www.linuxtv.org/wiki/index.php/TeVii_S470 I try to use it under Debian Squeeze, but I can't get channel data from it. I try to use drivers from 2.6.38, 2.6.39 kernels, s2-liplianin drivers with 2.6.32 kernel, last linux-media drivers with 2.6.32 With all drivers I can scan channels, but then a I'll try to lock channel I get some error in syslog (module cx23885 loaded with debug=1) cx23885[0]/0: [f373ec80/27] cx23885_buf_queue - append to active cx23885[0]/0: [f373ebc0/28] wakeup reg=477 buf=477 cx23885[0]/0: queue is not empty - append to active and finally a lot of cx23885[0]/0: [f42c4240/6] timeout - dma=0x03c5c000 cx23885[0]/0: [f42c4180/7] timeout - dma=0x3322b000 cx23885[0]/0: [f4374440/8] timeout - dma=0x33048000 cx23885[0]/0: [f4374140/9] timeout - dma=0x03d68000 In other machine this work under Windows. Under Linux I have same effects. It's problem in drivers or in card? That addition information need to resolve this problem? Hello Mike, I have same device on same OS, try this: mkdir /usr/local/src/dvbcd /usr/local/src/dvbwget http://tevii.com/100315_Beta_linux_tevii_ds3000.rarunrar x 100315_Beta_linux_tevii_ds3000.rarcp dvb-fe-ds3000.fw /lib/firmware/tar xjvf linux-tevii-ds3000.tar.bz2cd linux-tevii-ds3000make&& make install Regards. I'll try use this drivers today, but for this devices drivers exist in kernel from 2.6.33. So it must work with in-kernel drivers. P.S. Firmware from this archive I put in /lib/firmware before all tests. $ md5sum /lib/firmware/dvb-fe-ds3000.fw a32d17910c4f370073f9346e71d34b80 /lib/firmware/dvb-fe-ds3000.fw -- 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
Problem with TeVii S-470
Hello! I have this card http://www.linuxtv.org/wiki/index.php/TeVii_S470 I try to use it under Debian Squeeze, but I can't get channel data from it. I try to use drivers from 2.6.38, 2.6.39 kernels, s2-liplianin drivers with 2.6.32 kernel, last linux-media drivers with 2.6.32 With all drivers I can scan channels, but then a I'll try to lock channel I get some error in syslog (module cx23885 loaded with debug=1) cx23885[0]/0: [f373ec80/27] cx23885_buf_queue - append to active cx23885[0]/0: [f373ebc0/28] wakeup reg=477 buf=477 cx23885[0]/0: queue is not empty - append to active and finally a lot of cx23885[0]/0: [f42c4240/6] timeout - dma=0x03c5c000 cx23885[0]/0: [f42c4180/7] timeout - dma=0x3322b000 cx23885[0]/0: [f4374440/8] timeout - dma=0x33048000 cx23885[0]/0: [f4374140/9] timeout - dma=0x03d68000 In other machine this work under Windows. Under Linux I have same effects. It's problem in drivers or in card? That addition information need to resolve this problem? -- 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: [PATCHv2 5/8] [media] pvrusb2: initialize standards mask before detecting standard
On Wed, 5 Oct 2011, Mauro Carvalho Chehab wrote:
> Em 05-10-2011 11:00, Mike Isely escreveu:
> >
> > Mauro:
> >
> > With the line you've just added, then the " = arg" assignment in the
> > immediate prior line is effectively dead code. Try this instead:
>
> Look better:
>
> > > v4l2_std_id *std = arg;
> > > + *std = V4L2_STD_ALL;
>
> The above code is creating a pointer 'std' of the type 'v4l2_std_id', and
> initializing the pointer with the void *arg.
Oh yeah, you're absolutely right. I got visually tricked by the well
known confusing C initialization syntax when dealing with pointers!
I've got to not respond to stuff like this in the morning until I've
finished waking up. Duh...
>
> Then, it is doing an indirect reference to the pointer, filling its
> contents with V4L2_STD_ALL value.
>
> The code above is sane (and, btw, it works). After those patches, the
> detection code will detect PAL/M or NTSC/M depending on the channel I
> tune here (my cable operator broadcasts some channels with one format,
> and others with the other one). Before this patch and the msp3400, it
> would return a mask with PAL/M and PAL/60 or a mask with all NTSC/M formats.
Regarding your first version of the patch:
Acked-By: Mike Isely
-Mike
>
> Regards,
> Mauro.
>
> >
> > case VIDIOC_QUERYSTD:
> > {
> > - v4l2_std_id *std = arg;
> > + v4l2_std_id *std = V4L2_STD_ALL;
> > ret = pvr2_hdw_get_detected_std(hdw, std);
> > break;
> > }
> >
> >-Mike
> >
> >
> > On Tue, 4 Oct 2011, Mauro Carvalho Chehab wrote:
> >
> > > Signed-off-by: Mauro Carvalho Chehab
> > > ---
> > > drivers/media/video/pvrusb2/pvrusb2-v4l2.c |1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> > > b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> > > index 0d029da..ce7ac45 100644
> > > --- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> > > +++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> > > @@ -230,6 +230,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
> > > unsigned int cmd, void *arg)
> > > case VIDIOC_QUERYSTD:
> > > {
> > > v4l2_std_id *std = arg;
> > > + *std = V4L2_STD_ALL;
> > > ret = pvr2_hdw_get_detected_std(hdw, std);
> > > break;
> > > }
> > >
> >
>
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: [PATCHv2 5/8] [media] pvrusb2: initialize standards mask before detecting standard
Mauro:
With the line you've just added, then the " = arg" assignment in the
immediate prior line is effectively dead code. Try this instead:
case VIDIOC_QUERYSTD:
{
- v4l2_std_id *std = arg;
+ v4l2_std_id *std = V4L2_STD_ALL;
ret = pvr2_hdw_get_detected_std(hdw, std);
break;
}
-Mike
On Tue, 4 Oct 2011, Mauro Carvalho Chehab wrote:
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/video/pvrusb2/pvrusb2-v4l2.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> index 0d029da..ce7ac45 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> @@ -230,6 +230,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
> unsigned int cmd, void *arg)
> case VIDIOC_QUERYSTD:
> {
> v4l2_std_id *std = arg;
> + *std = V4L2_STD_ALL;
> ret = pvr2_hdw_get_detected_std(hdw, std);
> break;
> }
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 2/2] [media] pvrusb2: implement VIDIOC_QUERYSTD
Acked-By: Mike Isely
-Mike
On Mon, 3 Oct 2011, Mauro Carvalho Chehab wrote:
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/video/pvrusb2/pvrusb2-hdw.c |7 +++
> drivers/media/video/pvrusb2/pvrusb2-hdw.h |3 +++
> drivers/media/video/pvrusb2/pvrusb2-v4l2.c |7 +++
> 3 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
> b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
> index e98d382..5a6f24d 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
> @@ -2993,6 +2993,13 @@ static void pvr2_subdev_set_control(struct pvr2_hdw
> *hdw, int id,
> pvr2_subdev_set_control(hdw, id, #lab, (hdw)->lab##_val); \
> }
>
> +int pvr2_hdw_get_detected_std(struct pvr2_hdw *hdw, v4l2_std_id *std)
> +{
> + v4l2_device_call_all(&hdw->v4l2_dev, 0,
> + video, querystd, std);
> + return 0;
> +}
> +
> /* Execute whatever commands are required to update the state of all the
> sub-devices so that they match our current control values. */
> static void pvr2_subdev_update(struct pvr2_hdw *hdw)
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.h
> b/drivers/media/video/pvrusb2/pvrusb2-hdw.h
> index d7753ae..6654658 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-hdw.h
> +++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.h
> @@ -214,6 +214,9 @@ struct pvr2_stream *pvr2_hdw_get_video_stream(struct
> pvr2_hdw *);
> int pvr2_hdw_get_stdenum_value(struct pvr2_hdw *hdw,struct v4l2_standard
> *std,
> unsigned int idx);
>
> +/* Get the detected video standard */
> +int pvr2_hdw_get_detected_std(struct pvr2_hdw *hdw, v4l2_std_id *std);
> +
> /* Enable / disable retrieval of CPU firmware or prom contents. This must
> be enabled before pvr2_hdw_cpufw_get() will function. Note that doing
> this may prevent the device from running (and leaving this mode may
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> index e27f8ab..0d029da 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> @@ -227,6 +227,13 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
> unsigned int cmd, void *arg)
> break;
> }
>
> + case VIDIOC_QUERYSTD:
> + {
> + v4l2_std_id *std = arg;
> + ret = pvr2_hdw_get_detected_std(hdw, std);
> + break;
> + }
> +
> case VIDIOC_G_STD:
> {
> int val = 0;
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: [uclinux-dist-devel] [PATCH 3/4] v4l2: add vs6624 sensor driver
On Wed, Sep 14, 2011 at 03:28, Scott Jiang wrote: >>> +#ifdef CONFIG_VIDEO_ADV_DEBUG >> >> just use DEBUG ? >> > no, v4l2 use CONFIG_VIDEO_ADV_DEBUG ok, i was thinking this was something we added (since we have "ADVxxx" parts) >>> + v4l_info(client, "chip found @ 0x%02x (%s)\n", >>> + client->addr << 1, client->adapter->name); >> >> is that "<< 1" correct ? i dont think so ... > > every driver under media I see use this, so what's wrong? meh, they're all wrong imo then :p. they're shifting the address to accommodate datasheets that incorrectly specify the i2c "address" with the read/write as bit 0. but it's fine for this driver to do that if it's the standard that the rest of the v4l code has adopted. -mike -- 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: [uclinux-dist-devel] [PATCH 3/4] v4l2: add vs6624 sensor driver
On Tue, Sep 13, 2011 at 14:34, Scott Jiang wrote:
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
>
> +obj-$(CONFIG_VIDEO_VS6624) += vs6624.o
> obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
should be after vpx, not before ?
> --- /dev/null
> +++ b/drivers/media/video/vs6624.c
>
> +#include
run these patches through checkpatch.pl ? this should be linux/gpio.h ...
> +static const u16 vs6624_p1[] = {
> +static const u16 vs6624_p2[] = {
add comments as to what these are for ?
> +static inline int vs6624_read(struct v4l2_subdev *sd, u16 index)
> +static inline int vs6624_write(struct v4l2_subdev *sd, u16 index,
> + u8 value)
should these be inline ? they're a little "fat" ... better to let the
compiler choose
> +static int vs6624_writeregs(struct v4l2_subdev *sd, const u16 *regs)
> +{
> + u16 reg, data;
> +
> + while (*regs != 0x00) {
> + reg = *regs++;
> + data = *regs++;
> +
> + vs6624_write(sd, reg, (u8)data);
what's the point of declaring data as u16 if the top 8 bits are never used ?
> +static int vs6624_g_chip_ident(struct v4l2_subdev *sd,
> + struct v4l2_dbg_chip_ident *chip)
> +{
> + int rev;
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> + rev = vs6624_read(sd, VS6624_FW_VSN_MAJOR) << 8
> + | vs6624_read(sd, VS6624_FW_VSN_MINOR);
i'm a little surprised the compiler didnt warn about this. usually
bit shifts + bitwise operators want paren to keep things clear.
> +#ifdef CONFIG_VIDEO_ADV_DEBUG
just use DEBUG ?
> + v4l_info(client, "chip found @ 0x%02x (%s)\n",
> + client->addr << 1, client->adapter->name);
is that "<< 1" correct ? i dont think so ...
-mike
--
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: [uclinux-dist-devel] [PATCH 4/4] v4l2: add blackfin capture bridge driver
On Tue, Sep 13, 2011 at 14:34, Scott Jiang wrote:
> --- /dev/null
> +++ b/drivers/media/video/blackfin/Kconfig
> @@ -0,0 +1,10 @@
> +config VIDEO_BLACKFIN_CAPTURE
> + tristate "Blackfin Video Capture Driver"
> + depends on VIDEO_DEV && BLACKFIN
> + select VIDEOBUF2_DMA_CONTIG
since the code needs i2c, this needs to list I2C under depends
> --- /dev/null
> +++ b/drivers/media/video/blackfin/bfin_capture.c
>
> +#include
> +#include
> +#include
i think at least these three are unused and should get punted
> +static int __devinit bcap_probe(struct platform_device *pdev)
> +{
> + struct bcap_device *bcap_dev;
> + struct video_device *vfd;
> + struct i2c_adapter *i2c_adap;
you need to include linux/i2c.h for this
> +static struct platform_driver bcap_driver = {
> + .driver = {
> + .name = CAPTURE_DRV_NAME,
> + .owner = THIS_MODULE,
> + },
> + .probe = bcap_probe,
> + .remove = __devexit_p(bcap_remove),
> +};
no suspend/resume ? :)
> +MODULE_DESCRIPTION("Analog Devices video capture driver");
should mention the device part name in the desc
> --- /dev/null
> +++ b/drivers/media/video/blackfin/ppi.c
>
> +struct ppi_if *create_ppi_instance(const struct ppi_info *info)
> +void delete_ppi_instance(struct ppi_if *ppi)
should be ppi_{create,delete}_instance to match existing ppi_xxx style
-mike
--
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: [uclinux-dist-devel] [PATCH 2/4] v4l2: add adv7183 decoder driver
On Tue, Sep 13, 2011 at 14:34, Scott Jiang wrote: > --- /dev/null > +++ b/drivers/media/video/adv7183_regs.h > > +#define ADV7183_IN_CTRL 0x00 /* Input control */ should be a space after the #define, not a tab > --- /dev/null > +++ b/include/media/adv7183.h > > +#define ADV7183_16BIT_OUT 1 same here -mike -- 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: Bug in HVR1300. Found part of a patch, if reverted
On Thu, May 12, 2011 at 10:14 AM, Mike wrote:
Hi there
in the latest kernel (and all those since when the patch was written) this
patch is still required for the HVR-1300 to work, any chance of it getting
incorporated?
thanks
Mike
Hello Mike,
Please try out the following patch which has been submitted upstream,
which should fix the actual underlying problem (the patch that has
been circulating in Launchpad 439163 doesn't fix the *actual* issue).
https://launchpadlibrarian.net/74557311/frontend_dvb_init.patch
The above patch has been submitted for upstream inclusion, so feedback
from users would be useful.
Thanks,
Devin
Hi Devin,
thankyou very much for investigating and patching.
unfortunately for me, my system (ubuntu 10.04 with 2.6.32-32) will not
boot to try it...
After downloading source via "git clone
git://linuxtv.org/media_build.git" and successfully patching, compiling
and installing the modules using a text terminal, i reboot and before i
get to X my system hangs about 30 seconds into the boot process right
after a bunch of messages warning me about using backported media build
on an old kernel ("don't use it for production" etc etc).
i would be more than happy to test your patch but i'm sorry i'm not sure
what to do about that booting problem. i think i will need to try to
find a way to re-install the standard ubuntu media modules into my
2.6.32-32 module directories (whilst running a different kernel) to even
allow my system to boot on 2.6.32-32 !!
Mike
--
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 RFCv3 17/17] [media] return -ENOTTY for unsupported ioctl's at legacy drivers
For the pvrusb2 portion of this patch:
Acked-By: Mike Isely
-Mike
On Wed, 6 Jul 2011, Mauro Carvalho Chehab wrote:
> Those drivers are not relying at the V4L2 core to handle the ioctl's.
> So, we need to manually patch them every time a change goes to the
> core.
>
> Signed-off-by: Mauro Carvalho Chehab
>
> diff --git a/drivers/media/video/et61x251/et61x251_core.c
> b/drivers/media/video/et61x251/et61x251_core.c
> index d7efb33..9a1e80a 100644
> --- a/drivers/media/video/et61x251/et61x251_core.c
> +++ b/drivers/media/video/et61x251/et61x251_core.c
> @@ -2480,16 +2480,8 @@ static long et61x251_ioctl_v4l2(struct file *filp,
> case VIDIOC_S_PARM:
> return et61x251_vidioc_s_parm(cam, arg);
>
> - case VIDIOC_G_STD:
> - case VIDIOC_S_STD:
> - case VIDIOC_QUERYSTD:
> - case VIDIOC_ENUMSTD:
> - case VIDIOC_QUERYMENU:
> - case VIDIOC_ENUM_FRAMEINTERVALS:
> - return -EINVAL;
> -
> default:
> - return -EINVAL;
> + return -ENOTTY;
>
> }
> }
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> index 573749a..e27f8ab 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
> @@ -369,11 +369,6 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
> unsigned int cmd, void *arg)
> break;
> }
>
> - case VIDIOC_S_AUDIO:
> - {
> - ret = -EINVAL;
> - break;
> - }
> case VIDIOC_G_TUNER:
> {
> struct v4l2_tuner *vt = (struct v4l2_tuner *)arg;
> @@ -850,7 +845,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file,
> unsigned int cmd, void *arg)
> #endif
>
> default :
> - ret = -EINVAL;
> + ret = -ENOTTY;
> break;
> }
>
> diff --git a/drivers/media/video/sn9c102/sn9c102_core.c
> b/drivers/media/video/sn9c102/sn9c102_core.c
> index d8eece8..16cb07c 100644
> --- a/drivers/media/video/sn9c102/sn9c102_core.c
> +++ b/drivers/media/video/sn9c102/sn9c102_core.c
> @@ -3187,16 +3187,8 @@ static long sn9c102_ioctl_v4l2(struct file *filp,
> case VIDIOC_S_AUDIO:
> return sn9c102_vidioc_s_audio(cam, arg);
>
> - case VIDIOC_G_STD:
> - case VIDIOC_S_STD:
> - case VIDIOC_QUERYSTD:
> - case VIDIOC_ENUMSTD:
> - case VIDIOC_QUERYMENU:
> - case VIDIOC_ENUM_FRAMEINTERVALS:
> - return -EINVAL;
> -
> default:
> - return -EINVAL;
> + return -ENOTTY;
>
> }
> }
> diff --git a/drivers/media/video/uvc/uvc_v4l2.c
> b/drivers/media/video/uvc/uvc_v4l2.c
> index cdd967b..7afb97b 100644
> --- a/drivers/media/video/uvc/uvc_v4l2.c
> +++ b/drivers/media/video/uvc/uvc_v4l2.c
> @@ -83,7 +83,7 @@ static int uvc_ioctl_ctrl_map(struct uvc_video_chain *chain,
> default:
> uvc_trace(UVC_TRACE_CONTROL, "Unsupported V4L2 control type "
> "%u.\n", xmap->v4l2_type);
> - ret = -EINVAL;
> + ret = -ENOTTY;
> goto done;
> }
>
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: [beagleboard] [PATCH v8 2/2] Add support for mt9p031 sensor in Beagleboard XM.
PLEASE TAKE NOTE - THIS IS THE THIRD TIME I HAVE ASKED FOR UNSUBSCRIBE
The email address lwal...@bluechiptechnology.co.uk nneds to be deleted
urgently. This is a former employee, I have to monitor this email box and it
is full of this beagleboard messaging which is no longer relevant to this
business.;
PLEASE ACTION URGENTLY
M G Gulliford
Blue Chip Te4chnology Ltd
-Original Message-
From: "Javier Martin"
Sent: 20/06/2011 12:21
To: "linux-media@vger.kernel.org"
Cc: "g.liakhovet...@gmx.de" ;
"laurent.pinch...@ideasonboard.com" ;
"carlight...@yahoo.co.nz" ;
"beaglebo...@googlegroups.com" ;
"mch_...@yahoo.com.cn" ; "Javier Martin"
Subject: [beagleboard] [PATCH v8 2/2] Add support for mt9p031 sensor in
Beagleboard XM.
Use new platform data ext_freq and target_freq.
Signed-off-by: Javier Martin
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap3beagle-camera.c | 95
arch/arm/mach-omap2/board-omap3beagle.c| 50
3 files changed, 146 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3beagle-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..05cd983 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -179,6 +179,7 @@ obj-$(CONFIG_MACH_OMAP_2430SDP) +=
board-2430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
+ board-omap3beagle-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c
b/arch/arm/mach-omap2/board-omap3beagle-camera.c
new file mode 100644
index 000..96b4f95
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
@@ -0,0 +1,95 @@
+#include
+#include
+
+#include
+
+#include
+#include
+#include "devices.h"
+#include "../../../drivers/media/video/omap3isp/isp.h"
+
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
+#define MT9P031_EXT_FREQ 2100
+
+static struct regulator *reg_1v8, *reg_2v8;
+
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev->v4l2_dev);
+
+ return isp->platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+}
+
+static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
+{
+ /* Set RESET_BAR to !active */
+ gpio_set_value(MT9P031_RESET_GPIO, !active);
+
+ return 0;
+}
+
+static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
+ .set_xclk = beagle_cam_set_xclk,
+ .reset = beagle_cam_reset,
+ .ext_freq = MT9P031_EXT_FREQ,
+ .target_freq= 4800,
+ .version= MT9P031_COLOR_VERSION,
+};
+
+static struct i2c_board_info mt9p031_camera_i2c_device = {
+ I2C_BOARD_INFO("mt9p031", 0x48),
+ .platform_data = &beagle_mt9p031_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
+ {
+ .board_info = &mt9p031_camera_i2c_device,
+ .i2c_adapter_id = 2,
+ },
+ { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+ {
+ .subdevs = mt9p031_camera_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 0,
+ .clk_pol = 1,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ { },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+ .subdevs = beagle_camera_subdevs,
+};
+
+static int __init beagle_camera_init(void)
+{
+ if (!machine_is_omap3_beagle() || !cpu_is_omap3630())
+ return 0;
+
+ reg_1v8 = regulator_get(NULL, "cam_1v8");
+ if (IS_ERR(reg_1v8))
+ pr_err("%s: cannot get cam_1v8 regulator\n", __func__);
+ else
+ regulator_enable(reg_1v8);
+
+ reg_2v8 = regulator_get(NULL, "cam_2v8");
+ if (IS_ERR(reg_2v8))
+ pr_err("%s: cannot get cam_2v8 regulator\n", __func__);
+ else
+ regulator_enable(reg_2v8);
+
+ omap_register_i2c_bus(2, 100, NULL, 0);
+ gpio_request(MT9P031_RESET_GPIO, "cam_rst");
+ gpio_direction_output(MT9P031_RESET_GPIO, 0);
+ omap3_init_camera(&beagle_isp_platform_data);
+ return 0;
+}
+late_initcall(beagle_camera_init);
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
ind
Re: [RFCv6 PATCH 04/10] pvrusb2: fix g/s_tuner support.
I understand that this patch would not have been need had the pvrusb2
driver been using videodev_ioctl2. This is a situation that I'm going
to (finally) remedy ASAP. In the mean time...
Acked-By: Mike Isely
-Mike
On Tue, 14 Jun 2011, Hans Verkuil wrote:
> From: Hans Verkuil
>
> The tuner-core subdev requires that the type field of v4l2_tuner is
> filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't
> use that yet, so we have to do it manually based on whether the current
> input is radio or not.
>
> Tested with my pvrusb2.
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/video/pvrusb2/pvrusb2-hdw.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
> b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
> index 9d0dd08..e98d382 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
> @@ -3046,6 +3046,8 @@ static void pvr2_subdev_update(struct pvr2_hdw *hdw)
> if (hdw->input_dirty || hdw->audiomode_dirty || hdw->force_dirty) {
> struct v4l2_tuner vt;
> memset(&vt, 0, sizeof(vt));
> + vt.type = (hdw->input_val == PVR2_CVAL_INPUT_RADIO) ?
> + V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
> vt.audmode = hdw->audiomode_val;
> v4l2_device_call_all(&hdw->v4l2_dev, 0, tuner, s_tuner, &vt);
> }
> @@ -5171,6 +5173,8 @@ void pvr2_hdw_status_poll(struct pvr2_hdw *hdw)
> {
> struct v4l2_tuner *vtp = &hdw->tuner_signal_info;
> memset(vtp, 0, sizeof(*vtp));
> + vtp->type = (hdw->input_val == PVR2_CVAL_INPUT_RADIO) ?
> + V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
> hdw->tuner_signal_stale = 0;
> /* Note: There apparently is no replacement for VIDIOC_CROPCAP
> using v4l2-subdev - therefore we can't support that AT ALL right
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: Bug in HVR1300. Found part of a patch, if reverted
Hi there in the latest kernel (and all those since when the patch was written) this patch is still required for the HVR-1300 to work, any chance of it getting incorporated? thanks Mike > Hi list, > > there seems to be a bug in cx88 (HVR1300) that is responsible for not > switching channels, and not being able to scan. > Complete description can be found on launchpad: > > https://bugs.launchpad.net/mythtv/+bug/439163 (starting from comment #16) > > Anyway, i digged it down to this patch: > http://www.mail-archive.com/linuxtv-commits@xxx/msg02195.html > > When reverting the following part of the patch it starts working again: > > snip-- > > diff -r 576096447a45 -r d2eedb425718 > linux/drivers/media/video/cx88/cx88-dvb.c > - --- a/linux/drivers/media/video/cx88/cx88-dvb.c Thu Dec 18 07:28:18 2008 > - -0200 > +++ b/linux/drivers/media/video/cx88/cx88-dvb.c Thu Dec 18 07:28:35 2008 > - -0200 > @@ -1135,40 +1135,44 @@ static int cx8802_dvb_advise_acquire(str > * on the bus. Take the bus from the cx23416 and enable the > * cx22702 demod > */ > - - cx_set(MO_GP0_IO, 0x0080); /* cx22702 out of reset and > enable */ > + /* Toggle reset on cx22702 leaving i2c active */ > + cx_set(MO_GP0_IO, 0x0080); > + udelay(1000); > + cx_clear(MO_GP0_IO, 0x0080); > + udelay(50); > + cx_set(MO_GP0_IO, 0x0080); > + udelay(1000); > + /* enable the cx22702 pins */ > cx_clear(MO_GP0_IO, 0x0004); > udelay(1000); > break; > - -snip > > Regards > > Frank Sagurna -- 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] media/radio/wl1273: fix build errors
On Sun, Feb 27, 2011 at 12:51, Randy Dunlap wrote: > From: Randy Dunlap > > RADIO_WL1273 needs to make sure that the mfd core is built to avoid > build errors: > > ERROR: "mfd_add_devices" [drivers/mfd/wl1273-core.ko] undefined! > ERROR: "mfd_remove_devices" [drivers/mfd/wl1273-core.ko] undefined! 2.6.38 stable worthy ? now in mainline as 1b149bbe9156d2eb2afd5a072bd61ad0d4bfaca7 ... -mike -- 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 3/6] [media] pvrusb2: check for allocation failures
I'll look at the surrounding code and see what makes sense there. Having an error leg for allocation failures is a useful thing. -Mike Dan Carpenter wrote: On Fri, Mar 25, 2011 at 11:33:36PM -0500, Mike Isely wrote: Acked-By: Mike Isely I'd need to reformat this one to get it to apply... :/ It doesn't actually fix the bug so it's not worth it. regards, dan carpenter -- 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 -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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 6/6] [media] pvrusb2: replace !0 with 1
That's an opinion which I as the driver author disagree with. Strongly.
How hard is it to read "not false"?
Nacked-By: Mike Isely
On Sat, 26 Mar 2011, Dan Carpenter wrote:
> Using !0 is less readable than just saying 1.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c
> b/drivers/media/video/pvrusb2/pvrusb2-std.c
> index 9bebc08..ca4f67b 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-std.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-std.c
> @@ -158,7 +158,7 @@ int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char
> *buf,
> cnt++;
> buf += cnt;
> buf_size -= cnt;
> - mMode = !0;
> + mMode = 1;
> cmsk = sp->id;
> continue;
> }
> @@ -190,7 +190,7 @@ int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char
> *buf,
>
> if (idPtr)
> *idPtr = id;
> - return !0;
> + return 1;
> }
>
> unsigned int pvr2_std_id_to_str(char *buf, unsigned int buf_size,
> @@ -217,10 +217,10 @@ unsigned int pvr2_std_id_to_str(char *buf, unsigned int
> buf_size,
> buf_size -= c2;
> buf += c2;
> }
> - cfl = !0;
> + cfl = 1;
> c2 = scnprintf(buf, buf_size,
> "%s-", gp->name);
> - gfl = !0;
> + gfl = 1;
> } else {
> c2 = scnprintf(buf, buf_size, "/");
> }
> @@ -315,7 +315,7 @@ static int pvr2_std_fill(struct v4l2_standard *std,
> v4l2_std_id id)
> std->name[bcnt] = 0;
> pvr2_trace(PVR2_TRACE_STD, "Set up standard idx=%u name=%s",
> std->index, std->name);
> - return !0;
> + return 1;
> }
>
> /*
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 5/5] [media] pvrusb2: delete generic_standards_cnt
Are you actually serious about this? Well it's a small change...
Acked-By: Mike Isely
On Sat, 26 Mar 2011, Dan Carpenter wrote:
> The generic_standards_cnt define is only used in one place and it's
> more readable to just call ARRAY_SIZE(generic_standards) directly.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c
> b/drivers/media/video/pvrusb2/pvrusb2-std.c
> index d5a679f..9bebc08 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-std.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-std.c
> @@ -287,13 +287,11 @@ static struct v4l2_standard generic_standards[] = {
> }
> };
>
> -#define generic_standards_cnt ARRAY_SIZE(generic_standards)
> -
> static struct v4l2_standard *match_std(v4l2_std_id id)
> {
> unsigned int idx;
>
> - for (idx = 0; idx < generic_standards_cnt; idx++) {
> + for (idx = 0; idx < ARRAY_SIZE(generic_standards); idx++) {
> if (generic_standards[idx].id & id)
> return generic_standards + idx;
> }
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 4/6] [media] pvrusb2: fix camel case variables
It not worth this scale of source code disruption to the source code
just to rename a bunch of variables. I'm sorry, but...
Nacked-By: Mike Isely
On Sat, 26 Mar 2011, Dan Carpenter wrote:
> This patch renames some variables to bring them more in line with
> kernel CodingStyle.
>
> arrPtr => arr
> arrSize => arr_size
> bufPtr => buf
> bufSize => buf_size
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c
> b/drivers/media/video/pvrusb2/pvrusb2-std.c
> index b214f77..d5a679f 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-std.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-std.c
> @@ -115,26 +115,26 @@ static const struct std_name std_items[] = {
> * Search an array of std_name structures and return a pointer to the
> * element with the matching name.
> */
> -static const struct std_name *find_std_name(const struct std_name *arrPtr,
> - unsigned int arrSize,
> - const char *bufPtr,
> - unsigned int bufSize)
> +static const struct std_name *find_std_name(const struct std_name *arr,
> + unsigned int arr_size,
> + const char *buf,
> + unsigned int buf_size)
> {
> unsigned int idx;
> const struct std_name *p;
>
> - for (idx = 0; idx < arrSize; idx++) {
> - p = arrPtr + idx;
> - if (strlen(p->name) != bufSize)
> + for (idx = 0; idx < arr_size; idx++) {
> + p = arr + idx;
> + if (strlen(p->name) != buf_size)
> continue;
> - if (!memcmp(bufPtr, p->name, bufSize))
> + if (!memcmp(buf, p->name, buf_size))
> return p;
> }
> return NULL;
> }
>
> -int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char *bufPtr,
> -unsigned int bufSize)
> +int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char *buf,
> +unsigned int buf_size)
> {
> v4l2_std_id id = 0;
> v4l2_std_id cmsk = 0;
> @@ -144,27 +144,27 @@ int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char
> *bufPtr,
> char ch;
> const struct std_name *sp;
>
> - while (bufSize) {
> + while (buf_size) {
> if (!mMode) {
> cnt = 0;
> - while ((cnt < bufSize) && (bufPtr[cnt] != '-'))
> + while ((cnt < buf_size) && (buf[cnt] != '-'))
> cnt++;
> - if (cnt >= bufSize)
> + if (cnt >= buf_size)
> return 0; /* No more characters */
> sp = find_std_name(std_groups, ARRAY_SIZE(std_groups),
> -bufPtr, cnt);
> +buf, cnt);
> if (!sp)
> return 0; /* Illegal color system name */
> cnt++;
> - bufPtr += cnt;
> - bufSize -= cnt;
> + buf += cnt;
> + buf_size -= cnt;
> mMode = !0;
> cmsk = sp->id;
> continue;
> }
> cnt = 0;
> - while (cnt < bufSize) {
> - ch = bufPtr[cnt];
> + while (cnt < buf_size) {
> + ch = buf[cnt];
> if (ch == ';') {
> mMode = 0;
> break;
> @@ -174,7 +174,7 @@ int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char
> *bufPtr,
> cnt++;
> }
> sp = find_std_name(std_items, ARRAY_SIZE(std_items),
> -bufPtr, cnt);
> +buf, cnt);
> if (!sp)
> return 0; /* Illegal modulation system ID */
> t = sp->id & cmsk;
> @@ -182,10 +182,10 @@ int pvr2_std_str_to_id(v4l2_std_id *idPtr, const char
> *bufPtr,
> return 0; /* Specific color + modulation system
>illegal */
> id |= t;
> - if (cnt < bufSize)
> + if (cnt < buf_size)
> cnt++;
> - bufPtr += cnt;
> - bufSize -= cnt;
> +
Re: [PATCH 3/6] [media] pvrusb2: check for allocation failures
Acked-By: Mike Isely On Sat, 26 Mar 2011, Dan Carpenter wrote: > This function returns NULL on failure so lets do that if kzalloc() > fails. There is a separate problem that the caller for this function > doesn't check for errors... > > Signed-off-by: Dan Carpenter > > diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c > b/drivers/media/video/pvrusb2/pvrusb2-std.c > index 370a9ab..b214f77 100644 > --- a/drivers/media/video/pvrusb2/pvrusb2-std.c > +++ b/drivers/media/video/pvrusb2/pvrusb2-std.c > @@ -388,6 +388,9 @@ struct v4l2_standard *pvr2_std_create_enum(unsigned int > *countptr, > > stddefs = kzalloc(sizeof(struct v4l2_standard) * std_cnt, > GFP_KERNEL); > + if (!stddefs) > + return NULL; > + > for (idx = 0; idx < std_cnt; idx++) > stddefs[idx].index = idx; > > -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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 2/6] [media] pvrusb2: fix remaining checkpatch.pl complaints
I am OK with the #include change, but NOT the if-statement change. But
since it's bundled into one patch...
Nacked-By: Mike Isely
On Sat, 26 Mar 2011, Dan Carpenter wrote:
> * Include instead of .
> * Remove unneeded curly braces.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c
> b/drivers/media/video/pvrusb2/pvrusb2-std.c
> index a5d4867..370a9ab 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-std.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-std.c
> @@ -20,7 +20,7 @@
>
> #include "pvrusb2-std.h"
> #include "pvrusb2-debug.h"
> -#include
> +#include
> #include
>
> struct std_name {
> @@ -294,9 +294,8 @@ static struct v4l2_standard *match_std(v4l2_std_id id)
> unsigned int idx;
>
> for (idx = 0; idx < generic_standards_cnt; idx++) {
> - if (generic_standards[idx].id & id) {
> + if (generic_standards[idx].id & id)
> return generic_standards + idx;
> - }
> }
> return NULL;
> }
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 1/6] [media] pvrusb2: white space changes
I vehemently object to this scale of disruption to the pvrusb2 driver
source code purely to move around a bunch of braces and whitespace.
ESPECIALLY the massive ridiculous changes having to do with if-statement
syntax!
Nacked-By: Mike Isely
On Sat, 26 Mar 2011, Dan Carpenter wrote:
> * Broke up if statements so that the condition and the body are on
> separate lines.
> * Added spaces around commas and other operator characters.
> * Removed extra blank lines.
> * Added blank lines after declarations.
> * Changed C99 comments into kernel style.
> * Fixed checkpatch complaints where "{" char was on its own line but it
> wasn't the start of a function.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c
> b/drivers/media/video/pvrusb2/pvrusb2-std.c
> index ca9f83a..a5d4867 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-std.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-std.c
> @@ -28,39 +28,38 @@ struct std_name {
> v4l2_std_id id;
> };
>
> -
> #define CSTD_PAL \
> - (V4L2_STD_PAL_B| \
> - V4L2_STD_PAL_B1| \
> - V4L2_STD_PAL_G| \
> - V4L2_STD_PAL_H| \
> - V4L2_STD_PAL_I| \
> - V4L2_STD_PAL_D| \
> - V4L2_STD_PAL_D1| \
> - V4L2_STD_PAL_K| \
> - V4L2_STD_PAL_M| \
> - V4L2_STD_PAL_N| \
> - V4L2_STD_PAL_Nc| \
> + (V4L2_STD_PAL_B | \
> + V4L2_STD_PAL_B1 | \
> + V4L2_STD_PAL_G | \
> + V4L2_STD_PAL_H | \
> + V4L2_STD_PAL_I | \
> + V4L2_STD_PAL_D | \
> + V4L2_STD_PAL_D1 | \
> + V4L2_STD_PAL_K | \
> + V4L2_STD_PAL_M | \
> + V4L2_STD_PAL_N | \
> + V4L2_STD_PAL_Nc | \
>V4L2_STD_PAL_60)
>
> #define CSTD_NTSC \
> - (V4L2_STD_NTSC_M| \
> - V4L2_STD_NTSC_M_JP| \
> - V4L2_STD_NTSC_M_KR| \
> + (V4L2_STD_NTSC_M| \
> + V4L2_STD_NTSC_M_JP | \
> + V4L2_STD_NTSC_M_KR | \
>V4L2_STD_NTSC_443)
>
> #define CSTD_ATSC \
> - (V4L2_STD_ATSC_8_VSB| \
> + (V4L2_STD_ATSC_8_VSB | \
>V4L2_STD_ATSC_16_VSB)
>
> #define CSTD_SECAM \
> - (V4L2_STD_SECAM_B| \
> - V4L2_STD_SECAM_D| \
> - V4L2_STD_SECAM_G| \
> - V4L2_STD_SECAM_H| \
> - V4L2_STD_SECAM_K| \
> - V4L2_STD_SECAM_K1| \
> - V4L2_STD_SECAM_L| \
> + (V4L2_STD_SECAM_B | \
> + V4L2_STD_SECAM_D | \
> + V4L2_STD_SECAM_G | \
> + V4L2_STD_SECAM_H | \
> + V4L2_STD_SECAM_K | \
> + V4L2_STD_SECAM_K1 | \
> + V4L2_STD_SECAM_L | \
>V4L2_STD_SECAM_LC)
>
> #define TSTD_B (V4L2_STD_PAL_B|V4L2_STD_SECAM_B)
> @@ -82,39 +81,40 @@ struct std_name {
>
> /* Mapping of standard bits to color system */
> static const struct std_name std_groups[] = {
> - {"PAL",CSTD_PAL},
> - {"NTSC",CSTD_NTSC},
> - {"SECAM",CSTD_SECAM},
> - {"ATSC",CSTD_ATSC},
> + {"PAL", CSTD_PAL},
> + {"NTSC", CSTD_NTSC},
> + {"SECAM", CSTD_SECAM},
> + {"ATSC", CSTD_ATSC},
> };
>
> /* Mapping of standard bits to modulation system */
> static const struct std_name std_items[] = {
> - {"B",TSTD_B},
> - {"B1",TSTD_B1},
> - {"D",TSTD_D},
> - {"D1",TSTD_D1},
> - {"G",TSTD_G},
> - {"H",TSTD_H},
> - {"I",TSTD_I},
> - {"K",TSTD_K},
> - {"K1",TSTD_K1},
> - {"L",TSTD_L},
> - {"LC",V4L2_STD_SECAM_LC},
> - {"M",TSTD_M},
> - {"Mj",V4L2_STD_NTSC_M_JP},
> - {"443",V4L2_STD_NTSC_443},
> - {"Mk",V4L2_STD_NTSC_M_KR},
> - {"N",TSTD_N},
> - {"Nc",TSTD_Nc},
> - {"60",TSTD_60},
> - {"8VSB",V4L2_STD_ATSC_8_VSB},
> - {"16VSB",V4L2_STD_ATSC_16_VSB},
> + {"B", TSTD_B},
> + {"B1",TSTD_B1},
> + {"D", TSTD_D},
> + {"D1",TSTD_D1},
> + {"G", TSTD_G},
> + {"H", TSTD_H},
> + {"I", TSTD_I},
> + {"K", TSTD_K},
> + {"K1",TSTD_K1},
> + {"L", TSTD_L},
> + {"LC",V4L2_STD_SECAM_LC},
> + {"M", TSTD_M},
> + {"Mj",V4L2_STD_NTSC_M_JP},
> + {"443", V4L2_STD_NTSC_443},
> + {"Mk",V4L2_STD_NTSC_M_KR},
> + {"N", TSTD_N},
> + {"Nc",TSTD_Nc},
> + {&qu
[GIT PATCHES FOR 2.6.39] pvrusb2 driver fixes / improvements
Mauro: Please pull the following patches. Note also that the "Implement support for Terratec Grabster AV400" is not as big of a change as it might sound. The work to implement that really amounted to just some extra table entries, plus those changes have been out in the wild via the standalone pvrusb2 driver for quite some time. Getting that into the kernel is long overdue. -Mike The following changes since commit 41f3becb7bef489f9e8c35284dd88a1ff59b190c: Hans Verkuil (1): [media] V4L DocBook: update V4L2 version are available in the git repository at: git://git.linuxtv.org/mcisely/pvrusb2-dev.git pvrusb2-merge-2 Mike Isely (2): pvrusb2: Implement support for Terratec Grabster AV400 pvrusb2: Remove dead code Xiaochen Wang (1): pvrusb2: check kmalloc return value drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.c | 18 +++ drivers/media/video/pvrusb2/pvrusb2-devattr.c | 24 + drivers/media/video/pvrusb2/pvrusb2-hdw.c | 24 ++--- drivers/media/video/pvrusb2/pvrusb2-v4l2.c|2 - 4 files changed, 58 insertions(+), 10 deletions(-) -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: compilation warnings/errors
On Fri, 11 Mar 2011, Mike Isely wrote: > On Fri, 11 Mar 2011, Mauro Carvalho Chehab wrote: > > > /home/mchehab/new_build/v4l/pvrusb2-v4l2.c: In function > > 'pvr2_v4l2_do_ioctl': > > /home/mchehab/new_build/v4l/pvrusb2-v4l2.c:798:23: warning: variable 'cap' > > set but not used [-Wunused-but-set-variable] > > I will look into these. I'm a little puzzled right now since silly > stuff like this usually doesn't get by me. Unfortunately I can't look > at it right this minute. Expect to hear from me on Sunday. I looked at these two warnings. It's dead code that should be removed. Amazingly enough, this particular bit of crap has been in the driver, unnoticed, since 2008! I have a pull request coming for more pvrusb2 patches, probably in a few more hours, once I'm done testing. A fix for this will be in the patch set. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: compilation warnings/errors
On Fri, 11 Mar 2011, Mauro Carvalho Chehab wrote: > /home/mchehab/new_build/v4l/pvrusb2-v4l2.c: In function 'pvr2_v4l2_do_ioctl': > /home/mchehab/new_build/v4l/pvrusb2-v4l2.c:798:23: warning: variable 'cap' > set but not used [-Wunused-but-set-variable] I will look into these. I'm a little puzzled right now since silly stuff like this usually doesn't get by me. Unfortunately I can't look at it right this minute. Expect to hear from me on Sunday. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: v4l-utils-0.8.3 and KVDR
KVDR has a number of different parameters including -xforce xv-mode on startup and disable overlay-mod -ddont switch modeline during xv with kernel 2.6.35 I run KVDR with -x as I have an NVIDIA graphics. Running on 2.6.38 KVDR -x doesn't produce any log. The display appears and immediately disappears although there is a process running. With KVDR -d I get a display window but no picture but the attached log is produced. I hope this helps Mike libv4l2: open: 4 request == VIDIOC_G_FMT pixelformat: BGR3 384x288 field: 0 bytesperline: 0 imagesize331776 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 0, description: RGB-8 (3-3-2) result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB1 48x32 field: 3 bytesperline: 48 imagesize1536 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB1 768x288 field: 3 bytesperline: 768 imagesize221184 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 1, description: RGB-16 (5/B-6/G-5/R) result == 0 request == VIDIOC_TRY_FMT pixelformat: RGBP 48x32 field: 3 bytesperline: 768 imagesize24576 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGBP 768x288 field: 3 bytesperline: 1536 imagesize442368 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 2, description: RGB-24 (B-G-R) result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR3 48x32 field: 3 bytesperline: 1536 imagesize49152 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR3 768x288 field: 3 bytesperline: 2304 imagesize663552 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 3, description: RGB-32 (B-G-R) result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR4 48x32 field: 3 bytesperline: 2304 imagesize73728 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR4 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 4, description: RGB-32 (R-G-B) result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB4 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB4 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 5, description: Greyscale-8 result == 0 request == VIDIOC_TRY_FMT pixelformat: GREY 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: GREY 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 6, description: YUV 4:2:2 planar (Y-Cb-Cr) result == 0 request == VIDIOC_TRY_FMT pixelformat: 422P 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: 422P 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 7, description: YVU 4:2:0 planar (Y-Cb-Cr) result == 0 request == VIDIOC_TRY_FMT pixelformat: YV12 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: YV12 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 8, description: YUV 4:2:0 planar (Y-Cb-Cr) result == 0 request == VIDIOC_TRY_FMT pixelformat: YU12 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: YU12 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 9, description: YUV 4:2:2 (U-Y-V-Y) result == 0 request == VIDIOC_TRY_FMT pixelformat: UYVY 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: UYVY 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 10, description: RGB3 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB3 48x32 field: 3 bytesperline: 144 imagesize4608 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB3 768x288 field: 3 bytesperline: 2304 imagesize663552 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 11, description: result == -1 (Invalid argument) request == VIDIOC_ENUMINPUT result == 0 request == VIDIOC_ENUMSTD result == 0 libv4l1: open: 4 request == VIDIOC_QUERYCAP result == 0 request == VIDIOC_G_FBUF result == 0 request == VIDIOC_S_FBUF result == 0 libv4l2: close: 4 libv4l1: close: 4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.
[GIT PULL FOR 2.6.39] pvrusb2 driver
Mauro, [Note: This is my first real attempt at using git to get changes pulled, so please let me know if I missed a step. These changes are all relatively minor and have been sitting around for while. There will be more to follow once I'm sure I am doing this process correctly... -Mike Isely] The following changes since commit 5ed4bbdae09d207d141759e013a0f3c24ae76ecc: Mauro Carvalho Chehab (1): [media] tuner-core: Don't touch at standby during tuner_lookup are available in the git repository at: git://git.linuxtv.org/mcisely/pvrusb2-dev.git pvrusb2-merge-1 Mike Isely (5): pvrusb2: Handle change of mode before handling change of video standard pvrusb2: Minor cosmetic code tweak pvrusb2: Fix a few missing default control values, for cropping pvrusb2: Minor VBI tweak to help potential CC support pvrusb2: Use sysfs_attr_init() where appropriate Servaas Vandenberghe (1): pvrusb2: width and height maximum values. drivers/media/video/pvrusb2/pvrusb2-hdw.c | 60 +++ drivers/media/video/pvrusb2/pvrusb2-sysfs.c |9 2 files changed, 43 insertions(+), 26 deletions(-) -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
v4l-utils-0.8.3 and KVDR
My understanding of the "wrappers"contained in this library is that v4l applications should work with kernels from 2.6.36 onwards if the compat.so is preloaded. I use KVDR for watching and controlling VDR on my TV. Xine and Xineliboutput or not options as they don't provide TV out and TV out fronm the video card is also not an option because of where things are in the house. KVDR fails with Xv-VIDIOCGCAP: Invalid argument Xv-VIDIOCGMBUF: Invalid argument works perfectly fine on linux-2.6.35 Anyone have any ideas Mike -- 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 3/3] ir-kbd-i2c: improve remote behavior with z8 behind usb
On Fri, 21 Jan 2011, Jarod Wilson wrote: > On Fri, Jan 21, 2011 at 10:31:42AM -0600, Mike Isely wrote: > > > > The pvrusb2 change is obviously trivial so I have no issue with it. > > > > Acked-By: Mike Isely > > > > Note the spelling of my last name "Isely" not "Isley". A good way to > > remember is to think of the normal word "wisely" and just drop the > > leading "w". (And yes, is...@isely.net and is...@pobox.com lead to the > > same inbox.) > > Thanks Mike, apologies about the misspelling, I didn't catch it until > after I hit send. I had the Isley Brothers in my head. :) No problem. It's a very common mistake. And no, I'm not related to them. For the record, I generally don't get concerned about the spelling of my name, unless the error causes problems (e.g. lost e-mail) or the error gets propagated to a large list where it might multiply... Anyway, sorry also about taking this thread off topic. Enough said... -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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 3/3] ir-kbd-i2c: improve remote behavior with z8 behind usb
On Fri, 21 Jan 2011, Mike Isely wrote: > > Note the spelling of my last name "Isely" not "Isley". A good way to > remember is to think of the normal word "wisely" and just drop the > leading "w". (And yes, is...@isely.net and is...@pobox.com lead to the > same inbox.) And of course having said that, I then failed to fix the cc list. Sorry about that. D'Oh!!! -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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 3/3] ir-kbd-i2c: improve remote behavior with z8 behind usb
The pvrusb2 change is obviously trivial so I have no issue with it.
Acked-By: Mike Isely
Note the spelling of my last name "Isely" not "Isley". A good way to
remember is to think of the normal word "wisely" and just drop the
leading "w". (And yes, is...@isely.net and is...@pobox.com lead to the
same inbox.)
-Mike
On Thu, 20 Jan 2011, Jarod Wilson wrote:
> Add the same "are you ready?" i2c_master_send() poll command to
> get_key_haup_xvr found in lirc_zilog, which is apparently seen in
> the Windows driver for the PVR-150 w/a z8. This stabilizes what is
> received from both the HD-PVR and HVR-1950, even with their polling
> intervals at the default of 100, thus the removal of the custom
> 260ms polling_interval in pvrusb2-i2c-core.c.
>
> CC: Andy Walls
> CC: Mike Isley
> Signed-off-by: Jarod Wilson
> ---
> drivers/media/video/ir-kbd-i2c.c | 13 +
> drivers/media/video/pvrusb2/pvrusb2-i2c-core.c |1 -
> 2 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/video/ir-kbd-i2c.c
> b/drivers/media/video/ir-kbd-i2c.c
> index d2b20ad..a221ad6 100644
> --- a/drivers/media/video/ir-kbd-i2c.c
> +++ b/drivers/media/video/ir-kbd-i2c.c
> @@ -128,6 +128,19 @@ static int get_key_haup(struct IR_i2c *ir, u32 *ir_key,
> u32 *ir_raw)
>
> static int get_key_haup_xvr(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
> {
> + int ret;
> + unsigned char buf[1] = { 0 };
> +
> + /*
> + * This is the same apparent "are you ready?" poll command observed
> + * watching Windows driver traffic and implemented in lirc_zilog. With
> + * this added, we get far saner remote behavior with z8 chips on usb
> + * connected devices, even with the default polling interval of 100ms.
> + */
> + ret = i2c_master_send(ir->c, buf, 1);
> + if (ret != 1)
> + return (ret < 0) ? ret : -EINVAL;
> +
> return get_key_haup_common (ir, ir_key, ir_raw, 6, 3);
> }
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> index ccc8849..451ecd4 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> @@ -597,7 +597,6 @@ static void pvr2_i2c_register_ir(struct pvr2_hdw *hdw)
> init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
> init_data->type = RC_TYPE_RC5;
> init_data->name = hdw->hdw_desc->description;
> - init_data->polling_interval = 260; /* ms From lirc_zilog */
> /* IR Receiver */
> info.addr = 0x71;
> info.platform_data = init_data;
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 19 Jan 2011, Jarod Wilson wrote: > On Jan 19, 2011, at 8:20 AM, Mike Isely wrote: > > > This probing behavior does not happen for HVR-1950 (or HVR-1900) since > > there's only one possible IR configuration there. > > Just to be 100% clear, the device I'm poking it is definitely an > HVR-1950, using ir_scheme PVR2_IR_SCHEME_ZILOG, so the probe bits > shouldn't coming into play with anything I'm doing. Only just now > started looking at the pvrusb2 code. Wow, there's a LOT of it. ;) Yes, and yes :-) The standalone driver version (which is loaded with ifdef's that allow compilation back to 2.6.11) makes the in-kernel driver look small by comparison. There is a fair degree of compartmentalization between the modules. The roadmap to what it does for just HVR-1950 you can find by first looking at the declarations in pvrusb2-devattr.h and then the device-specific configurations in pvrusb2-devattr.c. From there you can usually grep your way around to see how those configuration bits affect the rest of the driver. Most of the really fun stuff is in pvrusb2-hdw.c. Pretty much everything else supports or uses that central component. The actual stuff which deals with I2C is not that large. Beyond making the access possible at all, the driver largely just tries to stay out of the way of external logic that needs to reach the bus. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 19 Jan 2011, Jean Delvare wrote: > Hi Andy, > > On Sun, 16 Jan 2011 14:20:49 -0500, Andy Walls wrote: > > 3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if > > adding some new fields for struct IR_i2c_init_data is acceptable. > > Specifically, I'd like to add a transceiver_lock mutex, a transceiver > > reset callback, and a data pointer for that reset callback. > > (Only lirc_zilog would use the reset callback and data pointer.) > > Adding fields to these structures is perfectly fine, if you need to do > that, just go on. > > But I'm a little confused about the names you chose, > "ir_transceiver_lock" and "transceiver_lock". These seem too > TX-oriented for a mutex that is supposed to synchronize TX and RX > access. It's particularly surprising for the ir-kbd-i2c driver, which > as far as I know only supports RX. The name "xcvr_lock" you used for > lirc_zilog seems more appropriate. Actually the term "transceiver" is normally understood to mean both directions. Otherwise it would be "receiver" or "transmitter". Another screwy as aspect of english, and I say this as a native english speaker. The term "xcvr" is usually just considered to be shorthand for "transceiver". -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 19 Jan 2011, Andy Walls wrote: [...] > > So the HVR-1950 only has Z8's capable of both Tx and Rx? No HVR-1950 > has an Rx only Z8 unit? As far as I know, that is indeed the case - Tx and Rx always. It's the older 24xxx devices where there could be a difference, and that's why the probe only takes place there. (And in the receive-only 24xxx configuration it's not a Z8 but something wierd that is only accessible through FX2 commands not via I2C, which is why the bridge driver emulates the older I2C chip, making IR reception behave like the original 29xxx device.) -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 19 Jan 2011, Andy Walls wrote: > On Wed, 2011-01-19 at 13:40 +0100, Jean Delvare wrote: > > On Wed, 19 Jan 2011 07:21:58 -0500, Andy Walls wrote: > > > For debugging, you might want to hack in a probe of address 0x70 for > > > your HVR-1950, to ensure the Tx side responds in the bridge driver. > > > > ... keeping in mind that the Z8 doesn't seem to like quick writes, so > > short reads should be used for probing purpose. > > > > Noted. Thanks. > > Actually, I think that might be due to the controller in the USB > connected devices (hdpvr and pvrusb2). The PCI connected devices, like > cx18 cards, don't have a problem with the Z8, the default I2C probe > method, and i2c-algo-bit. > (A good example of why only bridge drivers should do any required > probing.) > > > Looking at the code in pvrusb2, it appears to already use a 0 length > read for a probe: > > http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/pvrusb2/pvrusb2-i2c-core.c;h=ccc884948f34b385563ccbf548c5f80b33cd4f08;hb=refs/heads/staging/for_2.6.38-rc1#l542 Yes but that function is used in two places: (1) If a bus scan is performed during initialization (normally it isn't), and (2) it is called once ONLY for a 24xxx device (targeting 0x71) in order to determine if it is dealing with the MCE variant. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 19 Jan 2011, Andy Walls wrote: > On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote: > > > > Not working with > > lirc_zilog yet, it fails to load, due to an -EIO ret to one of the > > i2c_master_send() calls in lirc_zilog during probe of the TX side. Haven't > > looked into it any more than that yet. > > Well technically lirc_zilog doesn't "probe" anymore. It relies on the > bridge driver telling it the truth. The bridge driver (pvrusb2) still does one probe if it's a 24xxx device: It probes 0x71 in order to determine if it is dealing with an MCE variant device. Hauppauge did not change the USB ID when they released the 24xxx MCE variant (which has the IR blaster, thus the zilog device). The only way to tell the two devices apart is by discovering the existence of the zilog device - and the bridge driver needs to do this in order to properly disable its "emulated" I2C IR receiver which would otherwise be needed for the non-MCE device. Based on the discussion here, could that probe be a source of trouble on the 24XXX MCE device? This probing behavior does not happen for HVR-1950 (or HVR-1900) since there's only one possible IR configuration there. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [RFC PATCH] pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c
On Sun, 16 Jan 2011, Andy Walls wrote: > On Sun, 2011-01-16 at 20:27 -0600, Mike Isely wrote: [,,,] > > Right now, yes. In the near future, I need to use to to pass 3 > non-const items though: > > 1. A "struct mutex *transceiver_lock" so that the bridge driver can pass > a mutex to multiple modules accessing the Z8. That would be a per > device instance mutex, instantiated and initialized by the bridge > driver. The use case where this would be needed is a setup where > ir-kbd-i2c handles Z8 IR Rx and lirc_zilog handles only Z8 IR Tx of the > same chip. > > 2. A bridge driver provided "void (*reset_ir_chip)(struct i2c_adapter > *adap)", or maybe "void (*reset_ir_chip)(void *priv)", callback to > reset the transceiver chip when it gets hung. The original lirc_pvr150 > module had some hard coded reset function names and calls in it, but > they were removed with the rename to lirc_zilog and move into the > kernel. I'd like to get that ability back. > > 3. A bridge driver provided private data structure for the "void *priv" > argument of the aforementioned reset callback. This would also be a per > device object instantiated and initialized by the bridge driver. > I follow. Makes sense. Something to consider, perhaps for the future: Seems like what you have here amounts to some configuration data which will always be read-only, and other data which maps to the "context" in which the driver is being used (e.g. mutex instance, callback private context pointer, etc). That configuration data, if packed up into its own struct, could then be squirreled away at compile-time by the bridge driver and provided as part of a single table lookup. This only makes sense if there are a lot of configuration bits - but here I count 6 different items. > > > I believe I follow this and it looks good. The concept looks very > > simple and it's nice that the changes are really only in a single spot. > > Just thinking ahead about making the setup table-driven and not > > requiring data segment storage. > > With the patch right now it could be constant, I think. You would have > to use some generic name, like "pvrusb2 IR", instead of > hdw->hdw_desc->description though. > > For my future plans, if you don't provide a reset callback and don't > wish to provide a mutex, then yes you can keep it constant. > > I suspect not providing a reset callback may be OK. > > Not providing a mutex is also OK but it imposes a limitation: only one > IR module should be allowed to use the Z8 chip. That means > only lirc_zilog for IR Tx/Rx with Rx through LIRC, or > only ir-kbd-i2c for IR Rx through the the Linux input subsystem. For the future, I have no problem providing a reset callback. And given what you've said, I see no reason to do anything here which would constrain what you're trying to accomplish. But if down the road you do set up a separate configuration struct which this context struct might point to, then I'd like to update the pvrusb2 driver to take advantage of it. But this is no big deal for now. > > > -Mike > > > > > > Acked-By: Mike Isely > > Thanks. I'll pull this into my Z8 branch then. You're welcome. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [RFC PATCH] pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c
Andy:
Is the IR_i2c_init_data struct instance required to remain around for
the life of the driver's registration and is that why you stuffed it
into the pvr2_hdw struct? Second: If the first question is yes, then is
that struct considered to be read-only once it is set up and passed
through to the i2c device registration function? In other words, could
that structure be a const static initialized at compile time, perhaps
as part of a table definition?
I believe I follow this and it looks good. The concept looks very
simple and it's nice that the changes are really only in a single spot.
Just thinking ahead about making the setup table-driven and not
requiring data segment storage.
-Mike
Acked-By: Mike Isely
On Sun, 16 Jan 2011, Andy Walls wrote:
>
> When registering an IR Rx device with the I2C subsystem, provide more detailed
> information about the IR device and default remote configuration for the IR
> driver modules.
>
> Also explicitly register any IR Tx device with the I2C subsystem.
>
> Signed-off-by: Andy Walls
> Cc: Mike Isely
>
> --
> Mike,
>
> As discussed on IRC, this patch will enable lirc_zilog to bind to Zilog
> Z8 IR units on devices supported by pvrusb2.
>
> Please review and comment. This patch could have been written a number
> of ways. The way I chose was very direct: hard-coding information in a
> single function.
>
> A git branch with this change, and the updated lirc_zilog, is here:
>
> git://linuxtv.org/awalls/media_tree.git z8-pvrusb2
>
>
> http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8-pvrusb2
>
> Regards,
> Andy
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> index ac94a8b..305e6aa 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> +++ b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> @@ -40,6 +40,7 @@
> #include "pvrusb2-io.h"
> #include
> #include
> +#include
> #include "pvrusb2-devattr.h"
>
> /* Legal values for PVR2_CID_HSM */
> @@ -202,6 +203,7 @@ struct pvr2_hdw {
>
> /* IR related */
> unsigned int ir_scheme_active; /* IR scheme as seen from the outside */
> + struct IR_i2c_init_data ir_init_data; /* params passed to IR modules */
>
> /* Frequency table */
> unsigned int freqTable[FREQTABLE_SIZE];
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> index 7cbe18c..ccc8849 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> @@ -19,6 +19,7 @@
> */
>
> #include
> +#include
> #include "pvrusb2-i2c-core.h"
> #include "pvrusb2-hdw-internal.h"
> #include "pvrusb2-debug.h"
> @@ -48,13 +49,6 @@ module_param_named(disable_autoload_ir_video,
> pvr2_disable_ir_video,
> MODULE_PARM_DESC(disable_autoload_ir_video,
>"1=do not try to autoload ir_video IR receiver");
>
> -/* Mapping of IR schemes to known I2C addresses - if any */
> -static const unsigned char ir_video_addresses[] = {
> - [PVR2_IR_SCHEME_ZILOG] = 0x71,
> - [PVR2_IR_SCHEME_29XXX] = 0x18,
> - [PVR2_IR_SCHEME_24XXX] = 0x18,
> -};
> -
> static int pvr2_i2c_write(struct pvr2_hdw *hdw, /* Context */
> u8 i2c_addr, /* I2C address we're talking to */
> u8 *data, /* Data to write */
> @@ -574,26 +568,56 @@ static void do_i2c_scan(struct pvr2_hdw *hdw)
> static void pvr2_i2c_register_ir(struct pvr2_hdw *hdw)
> {
> struct i2c_board_info info;
> - unsigned char addr = 0;
> + struct IR_i2c_init_data *init_data = &hdw->ir_init_data;
> if (pvr2_disable_ir_video) {
> pvr2_trace(PVR2_TRACE_INFO,
> "Automatic binding of ir_video has been disabled.");
> return;
> }
> - if (hdw->ir_scheme_active < ARRAY_SIZE(ir_video_addresses)) {
> - addr = ir_video_addresses[hdw->ir_scheme_active];
> - }
> - if (!addr) {
> + memset(&info, 0, sizeof(struct i2c_board_info));
> + switch (hdw->ir_scheme_active) {
> + case PVR2_IR_SCHEME_24XXX: /* FX2-controlled IR */
> + case PVR2_IR_SCHEME_29XXX: /* Original 29xxx device */
> + init_data->ir_codes = RC_MAP_HAUPPAUGE_NEW;
> + init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP;
> + init_data->type = RC_TYPE_RC5;
>
Re: Volunteers needed: BKL removal: replace .ioctl by .unlocked_ioctl
I'll take care of the pvrusb2 driver. How soon does this need to be completed? -Mike On Sat, 18 Dec 2010, Hans Verkuil wrote: > On Saturday, December 18, 2010 12:31:26 Hans Verkuil wrote: > > Driver list: > > > > saa7146 (Hans Verkuil) > > mem2mem_testdev (Pawel Osciak or Marek Szyprowski) > > cx23885 (Steve Toth) > > cx18-alsa (Andy Walls) > > omap24xxcam (Sakari Ailus or David Cohen) > > au0828 (Janne Grunau) > > cpia2 (Andy Walls or Hans Verkuil) > > cx231xx (Mauro Carvalho Chehab) > > davinci (Muralidharan Karicheri) > > saa6588 (Hans Verkuil) > > pvrusb2 (Mike Isely) > > usbvision (Hans Verkuil) > > s5p-fimc (Sylwester Nawrocki) > > fsl-viu (Anatolij Gustschin) > > tlg2300 (Mauro Carvalho Chehab) > > zr364xx (Hans de Goede) > > soc_camera (Guennadi Liakhovetski) > > usbvideo/vicam (Hans de Goede) > > s2255drv (Pete Eberlein) > > bttv (Mauro Carvalho Chehab) > > stk-webcam (Hans de Goede) > > se401 (Hans de Goede) > > si4713-i2c (Hans Verkuil) > > dsbr100 (Hans Verkuil) > > Oops, si4713-i2c and saa6588 are subdevs, so those two can be removed from > this list. > > Regards, > > Hans > > -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
Accessing running dvb device
Hi I am trying to run multiple recordings on my dvb device (rtl2832). However when I try to access the frontend settings when a recording is active get_frontend returns nothing. This is using the Linux::DVB::DVBT module any suggestions -- 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
rtl2832u usb dvb id 1b80:d395
hi Still have one or two probs I have tried both anttis and jan trees, both of them compile but do not load modules or create dvb device when modprobed Using the realtek driver (1.4.2) I have the following issue one (and now only one) mux fails to pick up any channels, the channels are as clear as day my digibox with the same same connection >>> tune to: >>> 530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE WARNING: >>> tuning failed!!! The only difference I can see is this in dvbtune mux that works dvbtune -f 482167000 Using DVB card "Realtek RTL2832 DVB-T RTL2836 DTMB" tuning DVB-T (in United Kingdom) to 482167000 Hz polling Getting frontend event FE_STATUS: polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Event: Frequency: 492767000 SymbolRate: 0 FEC_inner: 2 Bit error rate: 206 Signal strength: 14135 SNR: 19 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC failing mux dvbtune -f 530167000 Using DVB card "Realtek RTL2832 DVB-T RTL2836 DTMB" tuning DVB-T (in United Kingdom) to 530167000 Hz polling Getting frontend event FE_STATUS: polling polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Event: Frequency: 540767000 SymbolRate: 0 FEC_inner: 2 Bit error rate: 19616 Signal strength: 14135 SNR: 16 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC The only difference I can see is the SNR and ber (19616) any ideas -- 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
rtl2832u usb dvb id 1b80:d395
hi Still have one or two probs I have tried both anttis and jan trees, both of them compile but do not load modules or create dvb device when modprobed Using the realtek driver (1.4.2) I have the following issue one (and now only one) mux fails to pick up any channels, the channels are as clear as day my digibox with the same same connection >>> tune to: >>> 530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE WARNING: >>> tuning failed!!! The only difference I can see is this in dvbtune mux that works dvbtune -f 482167000 Using DVB card "Realtek RTL2832 DVB-T RTL2836 DTMB" tuning DVB-T (in United Kingdom) to 482167000 Hz polling Getting frontend event FE_STATUS: polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Event: Frequency: 492767000 SymbolRate: 0 FEC_inner: 2 Bit error rate: 206 Signal strength: 14135 SNR: 19 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC failing mux dvbtune -f 530167000 Using DVB card "Realtek RTL2832 DVB-T RTL2836 DTMB" tuning DVB-T (in United Kingdom) to 530167000 Hz polling Getting frontend event FE_STATUS: polling polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Event: Frequency: 540767000 SymbolRate: 0 FEC_inner: 2 Bit error rate: 19616 Signal strength: 14135 SNR: 16 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC The only difference I can see is the SNR and ber (19616) any ideas -- 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: Problems with using dvb_usb_rtl2832u
On 27 November 2010 17:05, Mike Martin wrote: > On 27 November 2010 16:33, Anca Emanuel wrote: >> On Sat, Nov 27, 2010 at 6:14 PM, Mike Martin wrote: >>> Hi >>> >>> I am using this driver with USB 1b80:s395 >> >> It's not possible to be s395, please send what "lsusb" prints. >> And if you have other info, like the product info, etc. >> > > sorry typo 1b80:d395 > further info Dvbstreamer works but very few other dvb* utilities - confused now -- 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: Problems with using dvb_usb_rtl2832u
On 27 November 2010 16:33, Anca Emanuel wrote: > On Sat, Nov 27, 2010 at 6:14 PM, Mike Martin wrote: >> Hi >> >> I am using this driver with USB 1b80:s395 > > It's not possible to be s395, please send what "lsusb" prints. > And if you have other info, like the product info, etc. > sorry typo 1b80:d395 -- 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
