cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Thu Apr 26 05:00:13 CEST 2018
media-tree git hash:a2b2eff6ac2716f499defa590a6ec4ba379d765e
media_build git hash:   f334f01f94f76ecff2816af5cc9e2ae2f54c06c8
v4l-utils git hash: 4b93ba494c108a1ab73c261bb22e25d72750b09d
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: 0.5.2-RC1
smatch version: 0.5.1
host hardware:  x86_64
host os:4.15.0-2-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
Check COMPILE_TEST: OK
linux-2.6.36.4-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-i686: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-i686: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-i686: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.101-i686: OK
linux-3.0.101-x86_64: OK
linux-3.1.10-i686: OK
linux-3.1.10-x86_64: OK
linux-3.2.101-i686: OK
linux-3.2.101-x86_64: OK
linux-3.3.8-i686: OK
linux-3.3.8-x86_64: OK
linux-3.4.113-i686: OK
linux-3.4.113-x86_64: OK
linux-3.5.7-i686: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-i686: OK
linux-3.6.11-x86_64: OK
linux-3.7.10-i686: OK
linux-3.7.10-x86_64: OK
linux-3.8.13-i686: OK
linux-3.8.13-x86_64: OK
linux-3.9.11-i686: OK
linux-3.9.11-x86_64: OK
linux-3.10.108-i686: WARNINGS
linux-3.10.108-x86_64: WARNINGS
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.56-i686: OK
linux-3.16.56-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.102-i686: OK
linux-3.18.102-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.51-i686: OK
linux-4.1.51-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.109-i686: OK
linux-4.4.109-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: OK
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: OK
linux-4.9.91-i686: OK
linux-4.9.91-x86_64: OK
linux-4.14.31-i686: OK
linux-4.14.31-x86_64: OK
linux-4.15.14-i686: OK
linux-4.15.14-x86_64: OK
linux-4.16-i686: OK
linux-4.16-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: OK

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Re: [PATCH 1/5] dma-buf: use parameter structure for dma_buf_attach

[kbuild test robot]

Hi Christian,

I love your patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.17-rc2 next-20180424]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/dma-buf-use-parameter-structure-for-dma_buf_attach/20180413-080639
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: powerpc64-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc64 

All errors (new ones prefixed by >>):

   drivers/staging/media/tegra-vde/tegra-vde.c: In function 
'tegra_vde_attach_dmabuf':
>> drivers/staging/media/tegra-vde/tegra-vde.c:534:13: error: 'dmabuf' 
>> undeclared (first use in this function); did you mean 'dma_buf'?
  .dmabuf = dmabuf
^~
dma_buf
   drivers/staging/media/tegra-vde/tegra-vde.c:534:13: note: each undeclared 
identifier is reported only once for each function it appears in

vim +534 drivers/staging/media/tegra-vde/tegra-vde.c

   521  
   522  static int tegra_vde_attach_dmabuf(struct device *dev,
   523 int fd,
   524 unsigned long offset,
   525 unsigned int min_size,
   526 struct dma_buf_attachment **a,
   527 dma_addr_t *addr,
   528 struct sg_table **s,
   529 size_t *size,
   530 enum dma_data_direction dma_dir)
   531  {
   532  struct dma_buf_attach_info attach_info = {
   533  .dev = dev,
 > 534  .dmabuf = dmabuf
   535  };
   536  struct dma_buf_attachment *attachment;
   537  struct dma_buf *dmabuf;
   538  struct sg_table *sgt;
   539  int err;
   540  
   541  dmabuf = dma_buf_get(fd);
   542  if (IS_ERR(dmabuf)) {
   543  dev_err(dev, "Invalid dmabuf FD\n");
   544  return PTR_ERR(dmabuf);
   545  }
   546  
   547  if ((u64)offset + min_size > dmabuf->size) {
   548  dev_err(dev, "Too small dmabuf size %zu @0x%lX, "
   549   "should be at least %d\n",
   550  dmabuf->size, offset, min_size);
   551  return -EINVAL;
   552  }
   553  
   554  attachment = dma_buf_attach(_info);
   555  if (IS_ERR(attachment)) {
   556  dev_err(dev, "Failed to attach dmabuf\n");
   557  err = PTR_ERR(attachment);
   558  goto err_put;
   559  }
   560  
   561  sgt = dma_buf_map_attachment(attachment, dma_dir);
   562  if (IS_ERR(sgt)) {
   563  dev_err(dev, "Failed to get dmabufs sg_table\n");
   564  err = PTR_ERR(sgt);
   565  goto err_detach;
   566  }
   567  
   568  if (sgt->nents != 1) {
   569  dev_err(dev, "Sparse DMA region is unsupported\n");
   570  err = -EINVAL;
   571  goto err_unmap;
   572  }
   573  
   574  *addr = sg_dma_address(sgt->sgl) + offset;
   575  *a = attachment;
   576  *s = sgt;
   577  
   578  if (size)
   579  *size = dmabuf->size - offset;
   580  
   581  return 0;
   582  
   583  err_unmap:
   584  dma_buf_unmap_attachment(attachment, sgt, dma_dir);
   585  err_detach:
   586  dma_buf_detach(dmabuf, attachment);
   587  err_put:
   588  dma_buf_put(dmabuf);
   589  
   590  return err;
   591  }
   592  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: noveau vs arm dma ops

[Russell King - ARM Linux]

On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote:
> On arm that doesn't work. The iommu api seems like a good fit, except
> the dma-api tends to get in the way a bit (drm/msm apparently has
> similar problems like tegra), and if you need contiguous memory
> dma_alloc_coherent is the only way to get at contiguous memory. There
> was a huge discussion years ago about that, and direct cma access was
> shot down because it would have exposed too much of the caching
> attribute mangling required (most arm platforms need wc-pages to not
> be in the kernel's linear map apparently).

I think you completely misunderstand ARM from what you've written above,
and this worries me greatly about giving DRM the level of control that
is being asked for.

Modern ARMs have a PIPT cache or a non-aliasing VIPT cache, and cache
attributes are stored in the page tables.  These caches are inherently
non-aliasing when there are multiple mappings (which is a great step
forward compared to the previous aliasing caches.)

As the cache attributes are stored in the page tables, this in theory
allows different virtual mappings of the same physical memory to have
different cache attributes.  However, there's a problem, and that's
called speculative prefetching.

Let's say you have one mapping which is cacheable, and another that is
marked as write combining.  If a cache line is speculatively prefetched
through the cacheable mapping of this memory, and then you read the
same physical location through the write combining mapping, it is
possible that you could read cached data.

So, it is generally accepted that all mappings of any particular
physical bit of memory should have the same cache attributes to avoid
unpredictable behaviour.

This presents a problem with what is generally called "lowmem" where
the memory is mapped in kernel virtual space with cacheable
attributes.  It can also happen with highmem if the memory is
kmapped.

This is why, on ARM, you can't use something like get_free_pages() to
grab some pages from the system, pass it to the GPU, map it into
userspace as write-combining, etc.  It _might_ work for some CPUs,
but ARM CPUs vary in how much prefetching they do, and what may work
for one particular CPU is in no way guaranteed to work for another
ARM CPU.

The official line from architecture folk is to assume that the caches
infinitely speculate, are of infinite size, and can writeback *dirty*
data at any moment.

The way to stop things like speculative prefetches to particular
physical memory is to, quite "simply", not have any cacheable
mappings of that physical memory anywhere in the system.

Now, cache flushes on ARM tend to be fairly expensive for GPU buffers.
If you have, say, an 8MB buffer (for a 1080p frame) and you need to
do a cache operation on that buffer, you'll be iterating over it
32 or maybe 64 bytes at a time "just in case" there's a cache line
present.  Referring to my previous email, where I detailed the
potential need for _two_ flushes, one before the GPU operation and
one after, and this becomes _really_ expensive.  At that point, you're
probably way better off using write-combine memory where you don't
need to spend CPU cycles performing cache flushing - potentially
across all CPUs in the system if cache operations aren't broadcasted.

This isn't a simple matter of "just provide some APIs for cache
operations" - there's much more that needs to be understood by
all parties here, especially when we have GPU drivers that can be
used with quite different CPUs.

It may well be that for some combinations of CPUs and workloads, it's
better to use write-combine memory without cache flushing, but for
other CPUs that tradeoff (for the same workload) could well be
different.

Older ARMs get more interesting, because they have aliasing caches.
That means the CPU cache aliases across different virtual space
mappings in some way, which complicates (a) the mapping of memory
and (b) handling the cache operations on it.

It's too late for me to go into that tonight, and I probably won't
be reading mail for the next week and a half, sorry.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: noveau vs arm dma ops

[Russell King - ARM Linux]

On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote:
> > - dma api hides the cache flushing requirements from us. GPUs love
> >   non-snooped access, and worse give userspace control over that. We want
> >   a strict separation between mapping stuff and flushing stuff. With the
> >   IOMMU api we mostly have the former, but for the later arch maintainers
> >   regularly tells they won't allow that. So we have drm_clflush.c.
> 
> The problem is that a cache flushing API entirely separate is hard. That
> being said if you look at my generic dma-noncoherent API series it tries
> to move that way.  So far it is in early stages and apparently rather
> buggy unfortunately.

And if folk want a cacheable mapping with explicit cache flushing, the
cache flushing must not be defined in terms of "this is what CPU seems
to need" but from the point of view of a CPU with infinite prefetching,
infinite caching and infinite capacity to perform writebacks of dirty
cache lines at unexpected moments when the memory is mapped in a
cacheable mapping.

(The reason for that is you're operating in a non-CPU specific space,
so you can't make any guarantees as to how much caching or prefetching
will occur by the CPU - different CPUs will do different amounts.)

So, for example, the sequence:

GPU writes to memory
CPU reads from cacheable memory

if the memory was previously dirty (iow, CPU has written), you need to
flush the dirty cache lines _before_ the GPU writes happen, but you
don't know whether the CPU has speculatively prefetched, so you need
to flush any prefetched cache lines before reading from the cacheable
memory _after_ the GPU has finished writing.

Also note that "flush" there can be "clean the cache", "clean and
invalidate the cache" or "invalidate the cache" as appropriate - some
CPUs are able to perform those three operations, and the appropriate
one depends on not only where in the above sequence it's being used,
but also on what the operations are.

So, the above sequence could be:

CPU invalidates cache for memory
(due to possible dirty cache lines)
GPU writes to memory
CPU invalidates cache for memory
(to get rid of any speculatively prefetched
 lines)
CPU reads from cacheable memory

Yes, in the above case, _two_ cache operations are required to ensure
correct behaviour.  However, if you know for certain that the memory was
previously clean, then the first cache operation can be skipped.

What I'm pointing out is there's much more than just "I want to flush
the cache" here, which is currently what DRM seems to assume at the
moment with the code in drm_cache.c.

If we can agree a set of interfaces that allows _proper_ use of these
facilities, one which can be used appropriately, then there shouldn't
be a problem.  The DMA API does that via it's ideas about who owns a
particular buffer (because of the above problem) and that's something
which would need to be carried over to such a cache flushing API (it
should be pretty obvious that having a GPU read or write memory while
the cache for that memory is being cleaned will lead to unexpected
results.)

Also note that things get even more interesting in a SMP environment
if cache operations aren't broadcasted across the SMP cluster (which
means cache operations have to be IPI'd to other CPUs.)

The next issue, which I've brought up before, is that exposing cache
flushing to userspace on architectures where it isn't already exposed
comes.  As has been shown by Google Project Zero, this risks exposing
those architectures to Spectre and Meltdown exploits where they weren't
at such a risk before.  (I've pretty much shown here that you _do_
need to control which cache lines get flushed to make these exploits
work, and flushing the cache by reading lots of data in liu of having
the ability to explicitly flush bits of cache makes it very difficult
to impossible for them to work.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH v3 01/11] media: dt-bindings: ov772x: add device tree binding

[Laurent Pinchart]

Hi Mita-san,

On Wednesday, 25 April 2018 19:19:11 EEST Akinobu Mita wrote:
> 2018-04-24 0:54 GMT+09:00 Akinobu Mita :
> > 2018-04-23 18:17 GMT+09:00 Laurent Pinchart:
> >> On Sunday, 22 April 2018 18:56:07 EEST Akinobu Mita wrote:
> >>> This adds a device tree binding documentation for OV7720/OV7725 sensor.
> >>> 
> >>> Cc: Jacopo Mondi 
> >>> Cc: Laurent Pinchart 
> >>> Cc: Hans Verkuil 
> >>> Cc: Sakari Ailus 
> >>> Cc: Mauro Carvalho Chehab 
> >>> Cc: Rob Herring 
> >>> Reviewed-by: Rob Herring 
> >>> Reviewed-by: Jacopo Mondi 
> >>> Signed-off-by: Akinobu Mita 
> >>> ---
> >>> * v3
> >>> - Add Reviewed-by: lines
> >>> 
> >>>  .../devicetree/bindings/media/i2c/ov772x.txt   | 42 +++
> >>>  MAINTAINERS|  1 +
> >>>  2 files changed, 43 insertions(+)
> >>>  create mode 100644
> >>>  Documentation/devicetree/bindings/media/i2c/ov772x.txt
> >>> 
> >>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov772x.txt
> >>> b/Documentation/devicetree/bindings/media/i2c/ov772x.txt new file mode
> >>> 100644
> >>> index 000..b045503
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/media/i2c/ov772x.txt
> >>> @@ -0,0 +1,42 @@
> >>> +* Omnivision OV7720/OV7725 CMOS sensor
> >>> +
> >>> +The Omnivision OV7720/OV7725 sensor supports multiple resolutions
> >>> output,
> >>> +such as VGA, QVGA, and any size scaling down from CIF to 40x30. It also
> >>> can +support the YUV422, RGB565/555/444, GRB422 or raw RGB output
> >>> formats. +
> >>> +Required Properties:
> >>> +- compatible: shall be one of
> >>> + "ovti,ov7720"
> >>> + "ovti,ov7725"
> >>> +- clocks: reference to the xclk input clock.
> >>> +- clock-names: shall be "xclk".
> >> 
> >> As there's a single clock we could omit clock-names, couldn't we ?
> > 
> > Sounds good.
> > 
> > I'll prepare another patch that replaces the clock consumer ID argument
> > of clk_get() from "xclk" to NULL, and remove the above line in this
> > bindings.
> 
> I thought it's easy to do.  However, there is a non-DT user
> (arch/sh/boards/mach-migor/setup.c) that defines a clock with "xclk" ID.
> 
> This can be resolved by retrying clk_get() with NULL if no entry
> with "xclk".  But should we do so or leave as is?

How about patching the board code to register the clock alias with

clk_add_alias(NULL, "0-0021", "video_clk", NULL);

-- 
Regards,

Laurent Pinchart

Re: noveau vs arm dma ops

[Daniel Vetter]

On Wed, Apr 25, 2018 at 5:33 PM, Christoph Hellwig  wrote:
> On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote:
>> > Coordinating the backport of a trivial helper in the arm tree is not
>> > the end of the world.  Really, this cowboy attitude is a good reason
>> > why graphics folks have such a bad rep.  You keep poking into random
>> > kernel internals, don't talk to anoyone and then complain if people
>> > are upset.  This shouldn't be surprising.
>>
>> Not really agreeing on the cowboy thing. The fundamental problem is that
>> the dma api provides abstraction that seriously gets in the way of writing
>> a gpu driver. Some examples:
>
> So talk to other people.  Maybe people share your frustation.  Or maybe
> other people have a way to help.
>
>> - We never want bounce buffers, ever. dma_map_sg gives us that, so there's
>>   hacks to fall back to a cache of pages allocated using
>>   dma_alloc_coherent if you build a kernel with bounce buffers.
>
> get_required_mask() is supposed to tell you if you are safe.  However
> we are missing lots of implementations of it for iommus so you might get
> some false negatives, improvements welcome.  It's been on my list of
> things to fix in the DMA API, but it is nowhere near the top.

I hasn't come up in a while in some fireworks, so I honestly don't
remember exactly what the issues have been. But

commit d766ef53006c2c38a7fe2bef0904105a793383f2
Author: Chris Wilson 
Date:   Mon Dec 19 12:43:45 2016 +

drm/i915: Fallback to single PAGE_SIZE segments for DMA remapping

and the various bits of code that a

$ git grep SWIOTLB -- drivers/gpu

turns up is what we're doing to hack around that stuff. And in general
(there's some exceptions) gpus should be able to address everything,
so I never fully understood where that's even coming from.

>> - dma api hides the cache flushing requirements from us. GPUs love
>>   non-snooped access, and worse give userspace control over that. We want
>>   a strict separation between mapping stuff and flushing stuff. With the
>>   IOMMU api we mostly have the former, but for the later arch maintainers
>>   regularly tells they won't allow that. So we have drm_clflush.c.
>
> The problem is that a cache flushing API entirely separate is hard. That
> being said if you look at my generic dma-noncoherent API series it tries
> to move that way.  So far it is in early stages and apparently rather
> buggy unfortunately.

I'm assuming this stuff here?

https://lkml.org/lkml/2018/4/20/146

Anyway got lost in all that work a bit, looks really nice.

>> - dma api hides how/where memory is allocated. Kinda similar problem,
>>   except now for CMA or address limits. So either we roll our own
>>   allocators and then dma_map_sg (and pray it doesn't bounce buffer), or
>>   we use dma_alloc_coherent and then grab the sgt to get at the CMA
>>   allocations because that's the only way. Which sucks, because we can't
>>   directly tell CMA how to back off if there's some way to make CMA memory
>>   available through other means (gpus love to hog all of memory, so we
>>   have shrinkers and everything).
>
> If you really care about doing explicitly cache flushing anyway (see
> above) allocating your own memory and mapping it where needed is by
> far the superior solution.  On cache coherent architectures
> dma_alloc_coherent is nothing but allocate memory + dma_map_single.
> On non coherent allocations the memory might come through a special
> pool or must be used through a special virtual address mapping that
> is set up either statically or dynamically.  For that case splitting
> allocation and mapping is a good idea in many ways, and I plan to move
> towards that once the number of dma mapping implementations is down
> to a reasonable number so that it can actually be done.

Yeah the above is pretty much what we do on x86. dma-api believes
everything is coherent, so dma_map_sg does the mapping we want and
nothing else (minus swiotlb fun). Cache flushing, allocations, all
done by the driver.

On arm that doesn't work. The iommu api seems like a good fit, except
the dma-api tends to get in the way a bit (drm/msm apparently has
similar problems like tegra), and if you need contiguous memory
dma_alloc_coherent is the only way to get at contiguous memory. There
was a huge discussion years ago about that, and direct cma access was
shot down because it would have exposed too much of the caching
attribute mangling required (most arm platforms need wc-pages to not
be in the kernel's linear map apparently).

Anything that separate these 3 things more (allocation pools, mapping
through IOMMUs and flushing cpu caches) sounds like the right
direction to me. Even if that throws some portability across platforms
away - drivers who want to control things in this much detail aren't
really portable (without some serious work) anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 

[PATCH] [RESEND] [media] omap3isp: support 64-bit version of omap3isp_stat_data

[Arnd Bergmann]

C libraries with 64-bit time_t use an incompatible format for
struct omap3isp_stat_data. This changes the kernel code to
support either version, by moving over the normal handling
to the 64-bit variant, and adding compatiblity code to handle
the old binary format with the existing ioctl command code.

Fortunately, the command code includes the size of the structure,
so the difference gets handled automatically. In the process of
eliminating the references to 'struct timeval' from the kernel,
I also change the way the timestamp is generated internally,
basically by open-coding the v4l2_get_timestamp() call.

Cc: Laurent Pinchart 
Cc: Sakari Ailus 
Signed-off-by: Arnd Bergmann 
---
I submitted this one in November and asked again in January,
still waiting for a review so it can be applied.
---
 drivers/media/platform/omap3isp/isph3a_aewb.c |  2 ++
 drivers/media/platform/omap3isp/isph3a_af.c   |  2 ++
 drivers/media/platform/omap3isp/isphist.c |  2 ++
 drivers/media/platform/omap3isp/ispstat.c | 21 +++--
 drivers/media/platform/omap3isp/ispstat.h |  4 +++-
 include/uapi/linux/omap3isp.h | 22 ++
 6 files changed, 50 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isph3a_aewb.c 
b/drivers/media/platform/omap3isp/isph3a_aewb.c
index d44626f20ac6..3c82dea4d375 100644
--- a/drivers/media/platform/omap3isp/isph3a_aewb.c
+++ b/drivers/media/platform/omap3isp/isph3a_aewb.c
@@ -250,6 +250,8 @@ static long h3a_aewb_ioctl(struct v4l2_subdev *sd, unsigned 
int cmd, void *arg)
return omap3isp_stat_config(stat, arg);
case VIDIOC_OMAP3ISP_STAT_REQ:
return omap3isp_stat_request_statistics(stat, arg);
+   case VIDIOC_OMAP3ISP_STAT_REQ_TIME32:
+   return omap3isp_stat_request_statistics_time32(stat, arg);
case VIDIOC_OMAP3ISP_STAT_EN: {
unsigned long *en = arg;
return omap3isp_stat_enable(stat, !!*en);
diff --git a/drivers/media/platform/omap3isp/isph3a_af.c 
b/drivers/media/platform/omap3isp/isph3a_af.c
index 99bd6cc21d86..4da25c84f0c6 100644
--- a/drivers/media/platform/omap3isp/isph3a_af.c
+++ b/drivers/media/platform/omap3isp/isph3a_af.c
@@ -314,6 +314,8 @@ static long h3a_af_ioctl(struct v4l2_subdev *sd, unsigned 
int cmd, void *arg)
return omap3isp_stat_config(stat, arg);
case VIDIOC_OMAP3ISP_STAT_REQ:
return omap3isp_stat_request_statistics(stat, arg);
+   case VIDIOC_OMAP3ISP_STAT_REQ_TIME32:
+   return omap3isp_stat_request_statistics_time32(stat, arg);
case VIDIOC_OMAP3ISP_STAT_EN: {
int *en = arg;
return omap3isp_stat_enable(stat, !!*en);
diff --git a/drivers/media/platform/omap3isp/isphist.c 
b/drivers/media/platform/omap3isp/isphist.c
index a4ed5d140d48..d4be3d0e06f9 100644
--- a/drivers/media/platform/omap3isp/isphist.c
+++ b/drivers/media/platform/omap3isp/isphist.c
@@ -435,6 +435,8 @@ static long hist_ioctl(struct v4l2_subdev *sd, unsigned int 
cmd, void *arg)
return omap3isp_stat_config(stat, arg);
case VIDIOC_OMAP3ISP_STAT_REQ:
return omap3isp_stat_request_statistics(stat, arg);
+   case VIDIOC_OMAP3ISP_STAT_REQ_TIME32:
+   return omap3isp_stat_request_statistics_time32(stat, arg);
case VIDIOC_OMAP3ISP_STAT_EN: {
int *en = arg;
return omap3isp_stat_enable(stat, !!*en);
diff --git a/drivers/media/platform/omap3isp/ispstat.c 
b/drivers/media/platform/omap3isp/ispstat.c
index 47cbc7e3d825..5967dfd0a9f7 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "isp.h"
 
@@ -237,7 +238,7 @@ static int isp_stat_buf_queue(struct ispstat *stat)
if (!stat->active_buf)
return STAT_NO_BUF;
 
-   v4l2_get_timestamp(>active_buf->ts);
+   ktime_get_ts64(>active_buf->ts);
 
stat->active_buf->buf_size = stat->buf_size;
if (isp_stat_buf_check_magic(stat, stat->active_buf)) {
@@ -500,7 +501,8 @@ int omap3isp_stat_request_statistics(struct ispstat *stat,
return PTR_ERR(buf);
}
 
-   data->ts = buf->ts;
+   data->ts.tv_sec = buf->ts.tv_sec;
+   data->ts.tv_usec = buf->ts.tv_nsec / NSEC_PER_USEC;
data->config_counter = buf->config_counter;
data->frame_number = buf->frame_number;
data->buf_size = buf->buf_size;
@@ -512,6 +514,21 @@ int omap3isp_stat_request_statistics(struct ispstat *stat,
return 0;
 }
 
+int omap3isp_stat_request_statistics_time32(struct ispstat *stat,
+   struct omap3isp_stat_data_time32 *data)
+{
+   struct omap3isp_stat_data data64;
+   int ret;
+
+   ret = 

Re: [PATCH v8 09/13] [media] vb2: add in-fence support to QBUF

[Ezequiel Garcia]

On 14 March 2018 at 12:55, Hans Verkuil  wrote:
> On 03/09/2018 09:49 AM, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> Receive in-fence from userspace and add support for waiting on them
>> before queueing the buffer to the driver. Buffers can't be queued to the
>> driver before its fences signal. And a buffer can't be queue to the driver
>
> queue -> queued
>
>> out of the order they were queued from userspace. That means that even if
>> it fence signal it must wait all other buffers, ahead of it in the queue,
>
> it fence signal -> its fence signals
> wait all -> wait for all
>
>> to signal first.
>>
>> If the fence for some buffer fails we do not queue it to the driver,
>> instead we mark it as error and wait until the previous buffer is done
>> to notify userspace of the error. We wait here to deliver the buffers back
>> to userspace in order.
>>
>> v9:   - rename fence to in_fence in many places
>>   - handle fences signalling with error better (Hans Verkuil)
>>
>> v8:   - improve comments and docs (Hans Verkuil)
>>   - fix unlocking of vb->fence_cb_lock on vb2_core_qbuf (Hans Verkuil)
>>   - move in-fences code that was in the out-fences patch here (Alex)
>>
>> v8:   - improve comments about fences with errors
>
> v9? Two v8 entries?
>
>>
>> v7:
>>   - get rid of the fence array stuff for ordering and just use
>>   get_num_buffers_ready() (Hans)
>>   - fix issue of queuing the buffer twice (Hans)
>>   - avoid the dma_fence_wait() in core_qbuf() (Alex)
>>   - merge preparation commit in
>>
>> v6:
>>   - With fences always keep the order userspace queues the buffers.
>>   - Protect in_fence manipulation with a lock (Brian Starkey)
>>   - check if fences have the same context before adding a fence array
>>   - Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
>>   - Clean up fence if __set_in_fence() fails (Brian Starkey)
>>   - treat -EINVAL from dma_fence_add_callback() (Brian Starkey)
>>
>> v5:   - use fence_array to keep buffers ordered in vb2 core when
>>   needed (Brian Starkey)
>>   - keep backward compat on the reserved2 field (Brian Starkey)
>>   - protect fence callback removal with lock (Brian Starkey)
>>
>> v4:
>>   - Add a comment about dma_fence_add_callback() not returning a
>>   error (Hans)
>>   - Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
>>   - select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
>>   - Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
>>   - Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
>>   -  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
>>   vb2_start_streaming() (Hans)
>>   - set IN_FENCE flags on __fill_v4l2_buffer (Hans)
>>   - Queue buffers to the driver as soon as they are ready (Hans)
>>   - call fill_user_buffer() after queuing the buffer (Hans)
>>   - add err: label to clean up fence
>>   - add dma_fence_wait() before calling vb2_start_streaming()
>>
>> v3:   - document fence parameter
>>   - remove ternary if at vb2_qbuf() return (Mauro)
>>   - do not change if conditions behaviour (Mauro)
>>
>> v2:
>>   - fix vb2_queue_or_prepare_buf() ret check
>>   - remove check for VB2_MEMORY_DMABUF only (Javier)
>>   - check num of ready buffers to start streaming
>>   - when queueing, start from the first ready buffer
>>   - handle queue cancel
>>
>> Signed-off-by: Gustavo Padovan 
>> ---
>>  drivers/media/common/videobuf2/videobuf2-core.c | 197 
>> 
>>  drivers/media/common/videobuf2/videobuf2-v4l2.c |  34 +++-
>>  drivers/media/v4l2-core/Kconfig |  33 
>>  include/media/videobuf2-core.h  |  14 +-
>>  4 files changed, 248 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
>> b/drivers/media/common/videobuf2/videobuf2-core.c
>> index d3f7bb33a54d..5de5e35cfc40 100644
>> --- a/drivers/media/common/videobuf2/videobuf2-core.c
>> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
>> @@ -352,6 +352,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
>> vb2_memory memory,
>>   vb->index = q->num_buffers + buffer;
>>   vb->type = q->type;
>>   vb->memory = memory;
>> + spin_lock_init(>fence_cb_lock);
>>   for (plane = 0; plane < num_planes; ++plane) {
>>   vb->planes[plane].length = plane_sizes[plane];
>>   vb->planes[plane].min_length = plane_sizes[plane];
>> @@ -891,20 +892,12 @@ void *vb2_plane_cookie(struct vb2_buffer *vb, unsigned 
>> int plane_no)
>>  }
>>  EXPORT_SYMBOL_GPL(vb2_plane_cookie);
>>
>> -void vb2_buffer_done(struct vb2_buffer *vb, enum vb2_buffer_state state)
>> +static void vb2_process_buffer_done(struct vb2_buffer *vb, enum 
>> 

Re: [PATCH v2 00/12] media: ov5640: Misc cleanup and improvements

[Maxime Ripard]

Hi Samuel,

On Tue, Apr 24, 2018 at 03:11:19PM -0700, Sam Bobrowicz wrote:
> FYI, still hard at work on this. Did some more experiments last week
> that seemed to corroborate the clock tree in the spreadsheet.

Ok, good, I'll send an updated version next week taking this into
account then. Thanks!

> It also seems that the output of the P divider cell, SCLK cell and
> MIPI Rate cell in the spreadsheet must have a ratio of 2x:1x:8x
> (respectively) in order for the sensor to work properly on my
> platform, and that the SCLK value must be close to the "rate"
> variable that you calculate and pass to set_mipi_pclk.

It might be quite simple to support actually. Most of the other
dividers were hardcoded in the driver, so maybe it's the case for
those as well. I'll check and see how it goes.

> Unfortunately, I've only got the sensor working well for 1080p@15Hz
> and 720p@30Hz, both with a SCLK of 42MHz (aka 84:42:336). I'm
> running experiments now trying to adjust the htot and vtot values to
> create different required rates, and also to try to get faster Mipi
> rates working. Any information you have on the requirements of the
> htot and vtot values with respect to vact and hact values would
> likely be helpful.

Unfortunately, I don't have an answer to that one.

> I'm also keeping an eye on the scaler clock, which I think may be
> affecting certain resolutions, but haven't been able to see it make a
> difference yet (see register 0x3824 and 0x460c)
> 
> I plan on pushing a set of patches once I get this figured out, we can
> discuss what I should base them on when I get closer to that point.
> I'm new to this process :)

I was planning on sending a new version based on your feedback for the
MIPI-CSI2 formula, most likely next week. I guess you could test them
and see how it goes. Or send patches on top of this version if you
prefer :)

You have more documentation on how to do that here:
https://www.kernel.org/doc/Documentation/process/submitting-patches.rst

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH/RFC 1/4] drm: Add colorkey properties

[Dmitry Osipenko]

On 17.12.2017 03:17, Laurent Pinchart wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either become fully transparent, or gain a
> programmable alpha value.
> 
> Color keying is found in a large number of devices whose capabilities
> often differ, but they still have enough common features in range to
> standardize color key properties. This commit adds four properties
> related to color keying named colorkey.min, colorkey.max, colorkey.alpha
> and colorkey.mode. Additional properties can be defined by drivers to
> expose device-specific features.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 

Note that this patch needs to be rebased now.

Re: [PATCH/RFC 0/4] Implement standard color keying properties

[Dmitry Osipenko]

Hello Laurent,

On 17.12.2017 03:17, Laurent Pinchart wrote:
> Hello,
> 
> This patch series is an attempt at implementing standard properties for color
> keying support in the KMS API.

I was looking at implementing colorkey support for NVIDIA Tegra (older Tegra's
in particular) and Daniel Vetter suggested that colorkey should be implemented
as a generic plane property, instead of a custom one that I had in the patch
[0]. I've applied your RFC patch and replaced custom property with the generic,
it works well.

Very likely that all HW should be capable of making pixel completely transparent
when it matches a specified color, that could be one of common modes. Though
there could be limitations, like Tegra's aren't able to do blending-over of
planes if colorkey'ing is enabled. The 'colorkey.mode' property allows driver to
expose both common properties and a custom ones. In case of Tegra we could
implement a common property such that atomic commit will be rejected if planes
blending mode aren't compatible with the enabled colorkey'ing, and have a custom
property for a custom HW-aware application that won't be rejected (for example
Opentegra's Xv extension). The common modes could be derived later, once generic
property will get more usage by a variety of drivers. For now I don't see any
issues with your approach and hope to see this series applied in upstream to get
use of them, please continue your effort.

[0] https://patchwork.kernel.org/patch/10342849/

[PATCH] [2] Add new dvb-t board ":Zolid Hybrid Tv Stick"

[mjs]

From 911e4ce75588f23ead083fd520a45af5336ee761 Mon Sep 17 00:00:00 2001
From: Marcel Stork 
Date: Wed, 25 Apr 2018 19:49:07 +0200
Subject: [PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick".

Extra code to be able to use this stick, only digital, not analog nor 
remote-control.

Changes to be committed:
modified: drivers/media/usb/em28xx/em28xx-cards.c
modified: drivers/media/usb/em28xx/em28xx-dvb.c
modified: drivers/media/usb/em28xx/em28xx.h

Signed-off-by: Marcel Stork 

---
 drivers/media/usb/em28xx/em28xx-cards.c | 30 +-
 drivers/media/usb/em28xx/em28xx-dvb.c   |  1 +
 drivers/media/usb/em28xx/em28xx.h   |  1 +
 3 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index 6e0e67d2..bc8b099f 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -87,6 +87,21 @@ static const struct em28xx_reg_seq default_digital[] = {
{   -1, -1, -1, -1},
 };
 
+/* Board :Zolid Hybrid Tv Stick */
+static struct em28xx_reg_seq zolid_tuner[] = {
+   {EM2820_R08_GPIO_CTRL,  0xfd,   0xff,   100},
+   {EM2820_R08_GPIO_CTRL,  0xfe,   0xff,   100},
+   {   -1, -1, 
-1,  -1},
+};
+
+static struct em28xx_reg_seq zolid_digital[] = {
+   {EM2820_R08_GPIO_CTRL,  0x6a,   0xff,   100},
+   {EM2820_R08_GPIO_CTRL,  0x7a,   0xff,   100},
+   {EM2880_R04_GPO,0x04,   0xff,   100},
+   {EM2880_R04_GPO,0x0c,   0xff,   100},
+   {   -1, -1, 
-1,  -1},
+};
+
 /* Board Hauppauge WinTV HVR 900 analog */
 static const struct em28xx_reg_seq hauppauge_wintv_hvr_900_analog[] = {
{EM2820_R08_GPIO_CTRL,  0x2d,   ~EM_GPIO_4, 10},
@@ -666,6 +681,16 @@ const struct em28xx_board em28xx_boards[] = {
.tuner_type= TUNER_ABSENT,
.is_webcam = 1, /* To enable sensor probe */
},
+   [EM2882_BOARD_ZOLID_HYBRID_TV_STICK] = {
+   .name   = ":ZOLID HYBRID TV STICK",
+   .tuner_type = TUNER_XC2028,
+   .tuner_gpio = zolid_tuner,
+   .decoder= EM28XX_TVP5150,
+   .xclk   = EM28XX_XCLK_FREQUENCY_12MHZ,
+   .mts_firmware   = 1,
+   .has_dvb= 1,
+   .dvb_gpio   = zolid_digital,
+   },
[EM2750_BOARD_DLCW_130] = {
/* Beijing Huaqi Information Digital Technology Co., Ltd */
.name  = "Huaqi DLCW-130",
@@ -2487,7 +2512,7 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2820_BOARD_UNKNOWN },
{ USB_DEVICE(0xeb1a, 0x2862),
.driver_info = EM2820_BOARD_UNKNOWN },
-   { USB_DEVICE(0xeb1a, 0x2863),
+   { USB_DEVICE(0xeb1a, 0x2863), /* used by :zolid hybrid tv stick */
.driver_info = EM2820_BOARD_UNKNOWN },
{ USB_DEVICE(0xeb1a, 0x2870),
.driver_info = EM2820_BOARD_UNKNOWN },
@@ -2688,6 +2713,7 @@ static const struct em28xx_hash_table 
em28xx_eeprom_hash[] = {
{0xb8846b20, EM2881_BOARD_PINNACLE_HYBRID_PRO, TUNER_XC2028},
{0x63f653bd, EM2870_BOARD_REDDO_DVB_C_USB_BOX, TUNER_ABSENT},
{0x4e913442, EM2882_BOARD_DIKOM_DK300, TUNER_XC2028},
+   {0x85dd871e, EM2882_BOARD_ZOLID_HYBRID_TV_STICK, TUNER_XC2028},
 };
 
 /* I2C devicelist hash table for devices with generic USB IDs */
@@ -2699,6 +2725,7 @@ static const struct em28xx_hash_table em28xx_i2c_hash[] = 
{
{0xc51200e3, EM2820_BOARD_GADMEI_TVR200, TUNER_LG_PAL_NEW_TAPC},
{0x4ba50080, EM2861_BOARD_GADMEI_UTV330PLUS, TUNER_TNF_5335MF},
{0x6b800080, EM2874_BOARD_LEADERSHIP_ISDBT, TUNER_ABSENT},
+   {0x27e10080, EM2882_BOARD_ZOLID_HYBRID_TV_STICK, TUNER_XC2028},
 };
 
 /* NOTE: introduce a separate hash table for devices with 16 bit eeproms */
@@ -3187,6 +3214,7 @@ void em28xx_setup_xc3028(struct em28xx *dev, struct 
xc2028_ctrl *ctl)
case EM2880_BOARD_TERRATEC_HYBRID_XS:
case EM2880_BOARD_TERRATEC_HYBRID_XS_FR:
case EM2881_BOARD_PINNACLE_HYBRID_PRO:
+   case EM2882_BOARD_ZOLID_HYBRID_TV_STICK:
ctl->demod = XC3028_FE_ZARLINK456;
break;
case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900_R2:
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index a54cb8dc..67b16036 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ 

[PATCH] [2] Remove 2 excess lines in driver module em28xx

[mjs]

From c5007d7596dd755fb5d95664d9eda9733d7df461 Mon Sep 17 00:00:00 2001
From: Marcel Stork 
Date: Wed, 25 Apr 2018 19:34:20 +0200
Subject: [PATCH] Remove 2 excess lines in driver module em28xx

A cosmetic change by combining two sets of boards into one set because having 
the same arguments.
 
Changes to be committed:
modified: drivers/media/usb/em28xx/em28xx-cards.c

Signed-off-by: Marcel Stork 

---
 drivers/media/usb/em28xx/em28xx-cards.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index 6e0e67d2..7fa9a00e 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3182,8 +3182,6 @@ void em28xx_setup_xc3028(struct em28xx *dev, struct 
xc2028_ctrl *ctl)
case EM2880_BOARD_EMPIRE_DUAL_TV:
case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900:
case EM2882_BOARD_TERRATEC_HYBRID_XS:
-   ctl->demod = XC3028_FE_ZARLINK456;
-   break;
case EM2880_BOARD_TERRATEC_HYBRID_XS:
case EM2880_BOARD_TERRATEC_HYBRID_XS_FR:
case EM2881_BOARD_PINNACLE_HYBRID_PRO:
-- 
2.11.0

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Dan Williams]

On Wed, Apr 25, 2018 at 10:44 AM, Alex Deucher  wrote:
> On Wed, Apr 25, 2018 at 2:41 AM, Christoph Hellwig  wrote:
>> On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote:
>>> > It has a non-coherent transaction mode (which the chipset can opt to
>>> > not implement and still flush), to make sure the AGP horror show
>>> > doesn't happen again and GPU folks are happy with PCIe. That's at
>>> > least my understanding from digging around in amd the last time we had
>>> > coherency issues between intel and amd gpus. GPUs have some bits
>>> > somewhere (in the pagetables, or in the buffer object description
>>> > table created by userspace) to control that stuff.
>>>
>>> Right.  We have a bit in the GPU page table entries that determines
>>> whether we snoop the CPU's cache or not.
>>
>> I can see how that works with the GPU on the same SOC or SOC set as the
>> CPU.  But how is that going to work for a GPU that is a plain old PCIe
>> card?  The cache snooping in that case is happening in the PCIe root
>> complex.
>
> I'm not a pci expert, but as far as I know, the device sends either a
> snooped or non-snooped transaction on the bus.  I think the
> transaction descriptor supports a no snoop attribute.  Our GPUs have
> supported this feature for probably 20 years if not more, going back
> to PCI.  Using non-snooped transactions have lower latency and faster
> throughput compared to snooped transactions.

Right, 'no snoop' and 'relaxed ordering' have been part of the PCI
spec since forever. With a plain old PCI-E card the root complex
indeed arranges for caches to be snooped. Although it's not always
faster depending on the platform. 'No snoop' traffic may be relegated
to less bus resources relative to the much more common snooped
traffic.

Re: [Mjpeg-users] [PATCH] media: zoran: move to dma-mapping interface

[Bernhard Praschinger]

Hallo

Christoph Hellwig wrote:

On Wed, Apr 25, 2018 at 09:08:13AM +0200, Arnd Bergmann wrote:

That probably also means it can use dma_mmap_coherent instead of the
handcrafted remap_pfn_range loop and the PageReserved abuse.


I'd rather not touch that code. How about adding a comment about
the fact that it should use dma_mmap_coherent()?


Maybe the real question is if there is anyone that actually cares
for this driver, or if we are better off just removing it?

Same is true for various other virt_to_bus using drivers, e.g. the
grotty atm drivers.


I would appreciate if somebody would removes the driver from the linux 
kernel. I suggested that some years ago 2014-06-23 (just scroll down):

https://sourceforge.net/p/mjpeg/mailman/mjpeg-users/?viewmonth=201406

You should also find that thread in the kernel-janit...@vger.kernel.org 
and linux-media@vger.kernel.org Mailinglist archive.


I know of one person that is still using this old type of card's but he 
uses a 2.6.x Kernel on a old machine, using old software releases.

https://sourceforge.net/p/mjpeg/mailman/mjpeg-users/?viewmonth=201709

That type of card were introduced about ~20 years ago. I think it is a 
good moment to say goodbye to that type of cards.


auf hoffentlich bald,

Berni the Chaos of Woodquarter

Email: shadowl...@utanet.at
www: http://www.lysator.liu.se/~gz/bernhard

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Alex Deucher]

On Wed, Apr 25, 2018 at 2:41 AM, Christoph Hellwig  wrote:
> On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote:
>> > It has a non-coherent transaction mode (which the chipset can opt to
>> > not implement and still flush), to make sure the AGP horror show
>> > doesn't happen again and GPU folks are happy with PCIe. That's at
>> > least my understanding from digging around in amd the last time we had
>> > coherency issues between intel and amd gpus. GPUs have some bits
>> > somewhere (in the pagetables, or in the buffer object description
>> > table created by userspace) to control that stuff.
>>
>> Right.  We have a bit in the GPU page table entries that determines
>> whether we snoop the CPU's cache or not.
>
> I can see how that works with the GPU on the same SOC or SOC set as the
> CPU.  But how is that going to work for a GPU that is a plain old PCIe
> card?  The cache snooping in that case is happening in the PCIe root
> complex.

I'm not a pci expert, but as far as I know, the device sends either a
snooped or non-snooped transaction on the bus.  I think the
transaction descriptor supports a no snoop attribute.  Our GPUs have
supported this feature for probably 20 years if not more, going back
to PCI.  Using non-snooped transactions have lower latency and faster
throughput compared to snooped transactions.

Alex

Re: [PATCH] media: zoran: move to dma-mapping interface

[Trent Piepho]

On Wed, 2018-04-25 at 14:22 -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 25 Apr 2018 17:58:25 +0200
> Arnd Bergmann  escreveu:
> 
> > On Wed, Apr 25, 2018 at 5:26 PM, Christoph Hellwig  > rg> wrote:
> > > On Wed, Apr 25, 2018 at 01:15:18PM +0200, Arnd Bergmann wrote:  
> > > > That thought had occurred to me as well. I removed the oldest ISDN
> > > > drivers already some years ago, and the OSS sound drivers
> > > > got removed as well, and comedi got converted to the dma-mapping
> > > > interfaces, so there isn't much left at all now. This is what we
> > > > have as of v4.17-rc1:  
> > > 
> > > Yes, I've been looking at various grotty old bits to purge.  Usually
> > > I've been looking for some non-tree wide patches and CCed the last
> > > active people to see if they care.  In a few cases people do, but
> > > most often no one does.  
> > 
> > Let's start with this one (zoran) then, as Mauro is keen on having
> > all media drivers compile-testable on x86-64 and arm.
> > 
> > Trent Piepho and Hans Verkuil both worked on this driver in the
> > 2008/2009 timeframe and those were the last commits from anyone
> > who appears to have tested their patches on actual hardware.
> 
> Zoran is a driver for old hardware. I don't doubt that are people
> out there still using it, but who knows?
> 
> I have a few those boards packed somewhere. I haven't work with PCI
> hardware for a while. If needed, I can try to seek for them and
> do some tests. I need first to unpack a machine with PCI slots...
> the NUCs I generally use for development don't have any :-)
> 
> Anyway, except for virt_to_bus() and related stuff, I think that this
> driver is in good shape, as Hans did a lot of work in the past to
> make it to use the current media framework.

I still have a zoran board.  And my recently purchased ryzen system has
PCI slots.  To my surprise they are not uncommon on new socket AM4
boards.  However, I think the zoran board I have is 5V PCI and that is
rather uncommon.  Also becoming uncommon is analog NTSC/PAL video that
this chip is designed for!

If anyone is using these still, they would be in legacy systems for
these legacy video formats.

Re: [PATCH] media: zoran: move to dma-mapping interface

[Mauro Carvalho Chehab]

Em Wed, 25 Apr 2018 17:58:25 +0200
Arnd Bergmann  escreveu:

> On Wed, Apr 25, 2018 at 5:26 PM, Christoph Hellwig  wrote:
> > On Wed, Apr 25, 2018 at 01:15:18PM +0200, Arnd Bergmann wrote:  
> >> That thought had occurred to me as well. I removed the oldest ISDN
> >> drivers already some years ago, and the OSS sound drivers
> >> got removed as well, and comedi got converted to the dma-mapping
> >> interfaces, so there isn't much left at all now. This is what we
> >> have as of v4.17-rc1:  
> >
> > Yes, I've been looking at various grotty old bits to purge.  Usually
> > I've been looking for some non-tree wide patches and CCed the last
> > active people to see if they care.  In a few cases people do, but
> > most often no one does.  
> 
> Let's start with this one (zoran) then, as Mauro is keen on having
> all media drivers compile-testable on x86-64 and arm.
> 
> Trent Piepho and Hans Verkuil both worked on this driver in the
> 2008/2009 timeframe and those were the last commits from anyone
> who appears to have tested their patches on actual hardware.

Zoran is a driver for old hardware. I don't doubt that are people
out there still using it, but who knows?

I have a few those boards packed somewhere. I haven't work with PCI
hardware for a while. If needed, I can try to seek for them and
do some tests. I need first to unpack a machine with PCI slots...
the NUCs I generally use for development don't have any :-)

Anyway, except for virt_to_bus() and related stuff, I think that this
driver is in good shape, as Hans did a lot of work in the past to
make it to use the current media framework.

> 
> Trent, Hans: do you have reason to believe that there might still
> be users out there?
> 
>Arnd



Thanks,
Mauro

[PATCH] media: intel-ipu3: cio2: Handle IRQs until INT_STS is cleared

[Yong Zhi]

From: Bingbu Cao 

Interrupt behavior shows that some time the frame end and frame start
of next frame is unstable and can range from several to hundreds
of micro-sec. In the case of ~10us, isr may not clear next sof interrupt
status in single handling, which prevents new interrupts from coming.

Fix this by handling all pending IRQs before exiting isr, so
any abnormal behavior results from very short interrupt status
changes is protected.

Signed-off-by: Andy Yeh 
Signed-off-by: Bingbu Cao 
Signed-off-by: Yong Zhi 
---
 drivers/media/pci/intel/ipu3/ipu3-cio2.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c 
b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
index 7d768ec..2902715 100644
--- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
+++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
@@ -640,18 +640,10 @@ static const char *const cio2_port_errs[] = {
"PKT2LONG",
 };
 
-static irqreturn_t cio2_irq(int irq, void *cio2_ptr)
+static void cio2_irq_handle_once(struct cio2_device *cio2, u32 int_status)
 {
-   struct cio2_device *cio2 = cio2_ptr;
void __iomem *const base = cio2->base;
struct device *dev = >pci_dev->dev;
-   u32 int_status, int_clear;
-
-   int_status = readl(base + CIO2_REG_INT_STS);
-   int_clear = int_status;
-
-   if (!int_status)
-   return IRQ_NONE;
 
if (int_status & CIO2_INT_IOOE) {
/*
@@ -770,9 +762,29 @@ static irqreturn_t cio2_irq(int irq, void *cio2_ptr)
int_status &= ~(CIO2_INT_IOIE | CIO2_INT_IOIRQ);
}
 
-   writel(int_clear, base + CIO2_REG_INT_STS);
if (int_status)
dev_warn(dev, "unknown interrupt 0x%x on INT\n", int_status);
+}
+
+static irqreturn_t cio2_irq(int irq, void *cio2_ptr)
+{
+   struct cio2_device *cio2 = cio2_ptr;
+   void __iomem *const base = cio2->base;
+   struct device *dev = >pci_dev->dev;
+   u32 int_status;
+
+   int_status = readl(base + CIO2_REG_INT_STS);
+   dev_dbg(dev, "isr enter - interrupt status 0x%x\n", int_status);
+   if (!int_status)
+   return IRQ_NONE;
+
+   do {
+   writel(int_status, base + CIO2_REG_INT_STS);
+   cio2_irq_handle_once(cio2, int_status);
+   int_status = readl(base + CIO2_REG_INT_STS);
+   if (int_status)
+   dev_dbg(dev, "pending status 0x%x\n", int_status);
+   } while (int_status);
 
return IRQ_HANDLED;
 }
-- 
2.7.4

[PATCH v4 0/2] Add support for ov7251 camera sensor

[Todor Tomov]

The ov7251 sensor is a 1/7.5-Inch B VGA (640x480) CMOS Digital Image
Sensor from Omnivision.

--

Version 4:
- remove OF dependency;
- use only stack memory in ov7251_write_seq_regs();
- use DIV_ROUND_UP to round up sleep interval after gpio config;
- minor style changes.

--

Version 3:
- DT binding: added that there shall be a single endpoint node in the port node;
- added a comment for regulator enable order;
- set exposure and gain with a single i2c transaction;
- caclulate sleep after gpio config from external clock frequency;
- use MEDIA_BUS_FMT_Y10_1X10 format code;
- lock for power state, controls, mode and start streaming;
- remove regulator_set_voltage();
- use probe_new();
- remove i2c_device_id table;
- change of_property_read_u32 to fwnode_property_read_u32;
- few corrections from checkpatch --strict.

--

Version 2:
- changed ov7251 node's name in DT binding example;
- SPDX licence identifier;
- better names for register value defines;
- remove power reference counting and leave a power state only;
- use v4l2_find_nearest_size() to find sensor mode by requested size;
- set ycbcr_enc, quantization and xfer_func in set_fmt;
- use struct fwnode_handle instead of struct device_node;
- add comment in driver about external clock value.

--

Todor Tomov (2):
  dt-bindings: media: Binding document for OV7251 camera sensor
  media: Add a driver for the ov7251 camera sensor

 .../devicetree/bindings/media/i2c/ov7251.txt   |   52 +
 drivers/media/i2c/Kconfig  |   12 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov7251.c | 1503 
 4 files changed, 1568 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7251.txt
 create mode 100644 drivers/media/i2c/ov7251.c

-- 
2.7.4

[PATCH v4 2/2] media: Add a driver for the ov7251 camera sensor

[Todor Tomov]

The ov7251 sensor is a 1/7.5-Inch B VGA (640x480) CMOS Digital Image
Sensor from Omnivision.

The driver supports the following modes:
- 640x480 30fps
- 640x480 60fps
- 640x480 90fps

Output format is 10bit B RAW - MEDIA_BUS_FMT_Y10_1X10.

The driver supports configuration via user controls for:
- exposure and gain;
- horizontal and vertical flip;
- test pattern.

Signed-off-by: Todor Tomov 
Reviewed-by: Jacopo Mondi 
---
 drivers/media/i2c/Kconfig  |   12 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov7251.c | 1503 
 3 files changed, 1516 insertions(+)
 create mode 100644 drivers/media/i2c/ov7251.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 541f0d28..3dd16c6 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -688,6 +688,18 @@ config VIDEO_OV5695
  To compile this driver as a module, choose M here: the
  module will be called ov5695.
 
+config VIDEO_OV7251
+   tristate "OmniVision OV7251 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE
+   help
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV7251 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov7251.
+
 config VIDEO_OV772X
tristate "OmniVision OV772x sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index ea34aee..c8585b1 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
 obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
+obj-$(CONFIG_VIDEO_OV7251) += ov7251.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
diff --git a/drivers/media/i2c/ov7251.c b/drivers/media/i2c/ov7251.c
new file mode 100644
index 000..c05a9de
--- /dev/null
+++ b/drivers/media/i2c/ov7251.c
@@ -0,0 +1,1503 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the OV7251 camera sensor.
+ *
+ * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2017-2018, Linaro Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define OV7251_SC_MODE_SELECT  0x0100
+#define OV7251_SC_MODE_SELECT_SW_STANDBY   0x0
+#define OV7251_SC_MODE_SELECT_STREAMING0x1
+
+#define OV7251_CHIP_ID_HIGH0x300a
+#define OV7251_CHIP_ID_HIGH_BYTE   0x77
+#define OV7251_CHIP_ID_LOW 0x300b
+#define OV7251_CHIP_ID_LOW_BYTE0x50
+#define OV7251_SC_GP_IO_IN10x3029
+#define OV7251_AEC_EXPO_0  0x3500
+#define OV7251_AEC_EXPO_1  0x3501
+#define OV7251_AEC_EXPO_2  0x3502
+#define OV7251_AEC_AGC_ADJ_0   0x350a
+#define OV7251_AEC_AGC_ADJ_1   0x350b
+#define OV7251_TIMING_FORMAT1  0x3820
+#define OV7251_TIMING_FORMAT1_VFLIPBIT(2)
+#define OV7251_TIMING_FORMAT2  0x3821
+#define OV7251_TIMING_FORMAT2_MIRROR   BIT(2)
+#define OV7251_PRE_ISP_00  0x5e00
+#define OV7251_PRE_ISP_00_TEST_PATTERN BIT(7)
+
+struct reg_value {
+   u16 reg;
+   u8 val;
+};
+
+struct ov7251_mode_info {
+   u32 width;
+   u32 height;
+   const struct reg_value *data;
+   u32 data_size;
+   u32 pixel_clock;
+   u32 link_freq;
+   u16 exposure_max;
+   u16 exposure_def;
+   struct v4l2_fract timeperframe;
+};
+
+struct ov7251 {
+   struct i2c_client *i2c_client;
+   struct device *dev;
+   struct v4l2_subdev sd;
+   struct media_pad pad;
+   struct v4l2_fwnode_endpoint ep;
+   struct v4l2_mbus_framefmt fmt;
+   struct v4l2_rect crop;
+   struct clk *xclk;
+   u32 xclk_freq;
+
+   struct regulator *io_regulator;
+   struct regulator *core_regulator;
+   struct regulator *analog_regulator;
+
+   const struct ov7251_mode_info *current_mode;
+
+   struct v4l2_ctrl_handler ctrls;
+   struct v4l2_ctrl *pixel_clock;
+   struct v4l2_ctrl *link_freq;
+   struct v4l2_ctrl *exposure;
+   struct v4l2_ctrl *gain;
+
+   /* Cached register values */
+   u8 aec_pk_manual;
+   u8 pre_isp_00;
+   u8 timing_format1;
+   u8 timing_format2;
+
+   struct mutex lock; /* lock to protect power state, ctrls and mode */
+   bool power_on;
+
+   struct gpio_desc *enable_gpio;
+};
+
+static inline struct ov7251 *to_ov7251(struct v4l2_subdev *sd)
+{
+   return container_of(sd, struct ov7251, sd);
+}
+
+static const struct reg_value ov7251_global_init_setting[] = {
+   

[PATCH v4 1/2] dt-bindings: media: Binding document for OV7251 camera sensor

[Todor Tomov]

Add the document for ov7251 device tree binding.

CC: Rob Herring 
CC: Mark Rutland 
CC: devicet...@vger.kernel.org
Signed-off-by: Todor Tomov 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/media/i2c/ov7251.txt   | 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7251.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov7251.txt 
b/Documentation/devicetree/bindings/media/i2c/ov7251.txt
new file mode 100644
index 000..8281151
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov7251.txt
@@ -0,0 +1,52 @@
+* Omnivision 1/7.5-Inch B VGA CMOS Digital Image Sensor
+
+The Omnivision OV7251 is a 1/7.5-Inch CMOS active pixel digital image sensor
+with an active array size of 640H x 480V. It is programmable through a serial
+I2C interface.
+
+Required Properties:
+- compatible: Value should be "ovti,ov7251".
+- clocks: Reference to the xclk clock.
+- clock-names: Should be "xclk".
+- clock-frequency: Frequency of the xclk clock.
+- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This 
corresponds
+  to the hardware pin XSHUTDOWN which is physically active low.
+- vdddo-supply: Chip digital IO regulator.
+- vdda-supply: Chip analog regulator.
+- vddd-supply: Chip digital core regulator.
+
+The device node shall contain one 'port' child node with a single 'endpoint'
+subnode for its digital output video port, in accordance with the video
+interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+{
+   ...
+
+   ov7251: camera-sensor@60 {
+   compatible = "ovti,ov7251";
+   reg = <0x60>;
+
+   enable-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_bw_default>;
+
+   clocks = < 200>;
+   clock-names = "xclk";
+   clock-frequency = <2400>;
+
+   vdddo-supply = <_dovdd_1v8>;
+   vdda-supply = <_avdd_2v8>;
+   vddd-supply = <_dvdd_1v2>;
+
+   port {
+   ov7251_ep: endpoint {
+   clock-lanes = <1>;
+   data-lanes = <0>;
+   remote-endpoint = <_ep>;
+   };
+   };
+   };
+   };
-- 
2.7.4

Re: [PATCH v3 01/11] media: dt-bindings: ov772x: add device tree binding

[Akinobu Mita]

2018-04-24 0:54 GMT+09:00 Akinobu Mita :
> 2018-04-23 18:17 GMT+09:00 Laurent Pinchart 
> :
>> Hi Mita-san,
>>
>> On Sunday, 22 April 2018 18:56:07 EEST Akinobu Mita wrote:
>>> This adds a device tree binding documentation for OV7720/OV7725 sensor.
>>>
>>> Cc: Jacopo Mondi 
>>> Cc: Laurent Pinchart 
>>> Cc: Hans Verkuil 
>>> Cc: Sakari Ailus 
>>> Cc: Mauro Carvalho Chehab 
>>> Cc: Rob Herring 
>>> Reviewed-by: Rob Herring 
>>> Reviewed-by: Jacopo Mondi 
>>> Signed-off-by: Akinobu Mita 
>>> ---
>>> * v3
>>> - Add Reviewed-by: lines
>>>
>>>  .../devicetree/bindings/media/i2c/ov772x.txt   | 42 +++
>>>  MAINTAINERS|  1 +
>>>  2 files changed, 43 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov772x.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov772x.txt
>>> b/Documentation/devicetree/bindings/media/i2c/ov772x.txt new file mode
>>> 100644
>>> index 000..b045503
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov772x.txt
>>> @@ -0,0 +1,42 @@
>>> +* Omnivision OV7720/OV7725 CMOS sensor
>>> +
>>> +The Omnivision OV7720/OV7725 sensor supports multiple resolutions output,
>>> +such as VGA, QVGA, and any size scaling down from CIF to 40x30. It also can
>>> +support the YUV422, RGB565/555/444, GRB422 or raw RGB output formats.
>>> +
>>> +Required Properties:
>>> +- compatible: shall be one of
>>> + "ovti,ov7720"
>>> + "ovti,ov7725"
>>> +- clocks: reference to the xclk input clock.
>>> +- clock-names: shall be "xclk".
>>
>> As there's a single clock we could omit clock-names, couldn't we ?
>
> Sounds good.
>
> I'll prepare another patch that replaces the clock consumer ID argument
> of clk_get() from "xclk" to NULL, and remove the above line in this
> bindings.

I thought it's easy to do.  However, there is a non-DT user
(arch/sh/boards/mach-migor/setup.c) that defines a clock with "xclk" ID.

This can be resolved by retrying clk_get() with NULL if no entry
with "xclk".  But should we do so or leave as is?

Re: [PATCH] media: zoran: move to dma-mapping interface

[Arnd Bergmann]

On Wed, Apr 25, 2018 at 5:26 PM, Christoph Hellwig  wrote:
> On Wed, Apr 25, 2018 at 01:15:18PM +0200, Arnd Bergmann wrote:
>> That thought had occurred to me as well. I removed the oldest ISDN
>> drivers already some years ago, and the OSS sound drivers
>> got removed as well, and comedi got converted to the dma-mapping
>> interfaces, so there isn't much left at all now. This is what we
>> have as of v4.17-rc1:
>
> Yes, I've been looking at various grotty old bits to purge.  Usually
> I've been looking for some non-tree wide patches and CCed the last
> active people to see if they care.  In a few cases people do, but
> most often no one does.

Let's start with this one (zoran) then, as Mauro is keen on having
all media drivers compile-testable on x86-64 and arm.

Trent Piepho and Hans Verkuil both worked on this driver in the
2008/2009 timeframe and those were the last commits from anyone
who appears to have tested their patches on actual hardware.

Trent, Hans: do you have reason to believe that there might still
be users out there?

   Arnd

Re: [PATCH v3 2/2] media: Add a driver for the ov7251 camera sensor

[Todor Tomov]

Hi,

On 25.04.2018 13:54, Sakari Ailus wrote:
> Hi Todor,
> 
> Thanks for the update. Just a few minor comments below.

Thanks for the review again, Sakari.
I'm preparing the next version.

Best regards,
Todor

Re: noveau vs arm dma ops

[Christoph Hellwig]

On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote:
> > Coordinating the backport of a trivial helper in the arm tree is not
> > the end of the world.  Really, this cowboy attitude is a good reason
> > why graphics folks have such a bad rep.  You keep poking into random
> > kernel internals, don't talk to anoyone and then complain if people
> > are upset.  This shouldn't be surprising.
> 
> Not really agreeing on the cowboy thing. The fundamental problem is that
> the dma api provides abstraction that seriously gets in the way of writing
> a gpu driver. Some examples:

So talk to other people.  Maybe people share your frustation.  Or maybe
other people have a way to help.

> - We never want bounce buffers, ever. dma_map_sg gives us that, so there's
>   hacks to fall back to a cache of pages allocated using
>   dma_alloc_coherent if you build a kernel with bounce buffers.

get_required_mask() is supposed to tell you if you are safe.  However
we are missing lots of implementations of it for iommus so you might get
some false negatives, improvements welcome.  It's been on my list of
things to fix in the DMA API, but it is nowhere near the top.

> - dma api hides the cache flushing requirements from us. GPUs love
>   non-snooped access, and worse give userspace control over that. We want
>   a strict separation between mapping stuff and flushing stuff. With the
>   IOMMU api we mostly have the former, but for the later arch maintainers
>   regularly tells they won't allow that. So we have drm_clflush.c.

The problem is that a cache flushing API entirely separate is hard. That
being said if you look at my generic dma-noncoherent API series it tries
to move that way.  So far it is in early stages and apparently rather
buggy unfortunately.

> - dma api hides how/where memory is allocated. Kinda similar problem,
>   except now for CMA or address limits. So either we roll our own
>   allocators and then dma_map_sg (and pray it doesn't bounce buffer), or
>   we use dma_alloc_coherent and then grab the sgt to get at the CMA
>   allocations because that's the only way. Which sucks, because we can't
>   directly tell CMA how to back off if there's some way to make CMA memory
>   available through other means (gpus love to hog all of memory, so we
>   have shrinkers and everything).

If you really care about doing explicitly cache flushing anyway (see
above) allocating your own memory and mapping it where needed is by
far the superior solution.  On cache coherent architectures
dma_alloc_coherent is nothing but allocate memory + dma_map_single.
On non coherent allocations the memory might come through a special
pool or must be used through a special virtual address mapping that
is set up either statically or dynamically.  For that case splitting
allocation and mapping is a good idea in many ways, and I plan to move
towards that once the number of dma mapping implementations is down
to a reasonable number so that it can actually be done.

Re: [PATCH] media: zoran: move to dma-mapping interface

[Christoph Hellwig]

On Wed, Apr 25, 2018 at 01:15:18PM +0200, Arnd Bergmann wrote:
> That thought had occurred to me as well. I removed the oldest ISDN
> drivers already some years ago, and the OSS sound drivers
> got removed as well, and comedi got converted to the dma-mapping
> interfaces, so there isn't much left at all now. This is what we
> have as of v4.17-rc1:

Yes, I've been looking at various grotty old bits to purge.  Usually
I've been looking for some non-tree wide patches and CCed the last
active people to see if they care.  In a few cases people do, but
most often no one does.

> My feeling is that we want to keep most of the arch specific
> ones, in particular removing the m68k drivers would break
> a whole class of machines.

For the arch specific ones it would good to just ping the relevant
maintainers.  Especially m68k and parisc folks seems to be very
responsive.

Re: [PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick"

[mjs]

Op Wed, 25 Apr 2018 11:45:05 -0300
Mauro Carvalho Chehab  schreef:

> Em Wed, 25 Apr 2018 14:24:09 +0200
> mjs  escreveu:
> 
> > Op Wed, 25 Apr 2018 08:18:55 -0300
> > Mauro Carvalho Chehab  schreef:
> >   
> > > Em Wed, 25 Apr 2018 12:11:10 +0200
> > > mjs  escreveu:
> > > 
> > > > Op Wed, 25 Apr 2018 06:16:20 -0300
> > > > Mauro Carvalho Chehab  schreef:
> > > >   
> > > > > Em Wed, 25 Apr 2018 11:09:50 +0200
> > > > > mjs  escreveu:
> > > > > 
> > > > > > From 0a3355b47dc465c6372d30fa4a36d1c5db6c0fe2 Mon Sep 17 00:00:00 
> > > > > > 2001
> > > > > > From: Marcel Stork 
> > > > > > Date: Wed, 25 Apr 2018 10:53:34 +0200
> > > > > > Subject: [PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick".
> > > > > > 
> > > > > > Extra code to be able to use this stick, only digital, not analog 
> > > > > > nor remote-control.
> > > > > > 
> > > > > > Changes to be committed:
> > > > > > modified:   em28xx-cards.c
> > > > > > modified:   em28xx-dvb.c
> > > > > > modified:   em28xx.h  
> > > > > 
> > > > > You forgot to add your Signed-off-by. That's mandatory for patches to
> > > > > be acepted.
> > > > 
> > > > Ok, still learning
> > > >   
> > > > > 
> > > > > > 
> > > > > > ---
> > > > > >  em28xx-cards.c | 30 +-
> > > > > >  em28xx-dvb.c   |  1 +
> > > > > >  em28xx.h   |  1 +
> > > > > >  3 files changed, 31 insertions(+), 1 deletion(-)  
> > > > > 
> > > > > 
> > > > > use git diff against upstream tree. This should be using
> > > > > a different paths there, e.g. drivers/media/usb/em28xx/...
> > > > 
> > > > This is actually against the upstream tree, in line with your advice in 
> > > > a previous mail.
> > > > After git clone... and ./build, I did not do "make install" but 
> > > > copy-paste out of the /media_build/linux/drivers/media/usb/em28xx
> > > > Reason, I do not have an experimental pc and some parts are 
> > > > experimental.
> > > > I did not want to take the risk to crash my working pc at this moment 
> > > > in time.
> > > > 
> > > > I will try to work around this problem.  
> > > 
> > > Upstream is actually this tree:
> > > 
> > >   https://git.linuxtv.org/media_tree.git/
> > > 
> > > The media_build tree is what we call a "backport tree" :-)
> > 
> > I started with 
> > "https://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches; in 
> > line with your advice in a previous mail.  
> 
> The first line there at "Patch preparation" says:
> 
>   "For Kernel media patches, they should be created against the Linux 
> Kernel master linux_media git tree[1]"
> 
> [1] With links to: http://git.linuxtv.org/media_tree.git
> 
> > Followed the text to 
> > "https://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device
> >  Drivers" basic approach.  
> 
> I see... here, information were indeed incomplete.
> 
> I just updated it.
> 
> 
> > Also to "https://git.linuxtv.org/media_build.git/about/;
> > I have used "git clone --depth=1 git://linuxtv.org/media_build.git" 
> > followed by ./build and copy/paste files mentioned above.
> > This is not the required upstream tree ?  
> 
> There's a similar instruction at media_tree.git/about, with is the one you
> would be using instead.
> 
> > 
> > Work around:
> > Added the path to all files manually.
> > This is acceptable ?  
> 
> An acceptable workaround would be to create another tree at the place
> it untars the driver's tarball (under linux dir), and do the
> diffs there.
> 
> The ./build script actually does something similar to that, if used
> with the --main-git option, but, if you're willing to use it, be
> careful to do on a separate clone, as otherwise it may destroy your
> work, as it will setup a different environment, and you'll lose
> any changes you've made inside that media_build cloned tree.

Oke, this time it will work.
Two new patches coming up soon.

Thanks,
  Marcel

[PATCH] media: smiapp: fix timeout checking in smiapp_read_nvm

[Colin King]

From: Colin Ian King 

The current code decrements the timeout counter i and the end of
each loop i is incremented, so the check for timeout will always
be false and hence the timeout mechanism is just a dead code path.
Potentially, if the RD_READY bit is not set, we could end up in
an infinite loop.

Fix this so the timeout starts from 1000 and decrements to zero,
if at the end of the loop i is zero we have a timeout condition.

Detected by CoverityScan, CID#1324008 ("Logically dead code")

Fixes: ccfc97bdb5ae ("[media] smiapp: Add driver")
Signed-off-by: Colin Ian King 
---
 drivers/media/i2c/smiapp/smiapp-core.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 3b7ace395ee6..e1f8208581aa 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -1001,7 +1001,7 @@ static int smiapp_read_nvm(struct smiapp_sensor *sensor,
if (rval)
goto out;
 
-   for (i = 0; i < 1000; i++) {
+   for (i = 1000; i > 0; i--) {
rval = smiapp_read(
sensor,
SMIAPP_REG_U8_DATA_TRANSFER_IF_1_STATUS, );
@@ -1012,11 +1012,10 @@ static int smiapp_read_nvm(struct smiapp_sensor *sensor,
if (s & SMIAPP_DATA_TRANSFER_IF_1_STATUS_RD_READY)
break;
 
-   if (--i == 0) {
-   rval = -ETIMEDOUT;
-   goto out;
-   }
-
+   }
+   if (!i) {
+   rval = -ETIMEDOUT;
+   goto out;
}
 
for (i = 0; i < SMIAPP_NVM_PAGE_SIZE; i++) {
-- 
2.17.0

Re: [PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick"

[Mauro Carvalho Chehab]

Em Wed, 25 Apr 2018 14:24:09 +0200
mjs  escreveu:

> Op Wed, 25 Apr 2018 08:18:55 -0300
> Mauro Carvalho Chehab  schreef:
> 
> > Em Wed, 25 Apr 2018 12:11:10 +0200
> > mjs  escreveu:
> >   
> > > Op Wed, 25 Apr 2018 06:16:20 -0300
> > > Mauro Carvalho Chehab  schreef:
> > > 
> > > > Em Wed, 25 Apr 2018 11:09:50 +0200
> > > > mjs  escreveu:
> > > >   
> > > > > From 0a3355b47dc465c6372d30fa4a36d1c5db6c0fe2 Mon Sep 17 00:00:00 2001
> > > > > From: Marcel Stork 
> > > > > Date: Wed, 25 Apr 2018 10:53:34 +0200
> > > > > Subject: [PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick".
> > > > > 
> > > > > Extra code to be able to use this stick, only digital, not analog nor 
> > > > > remote-control.
> > > > > 
> > > > > Changes to be committed:
> > > > >   modified:   em28xx-cards.c
> > > > >   modified:   em28xx-dvb.c
> > > > >   modified:   em28xx.h
> > > > 
> > > > You forgot to add your Signed-off-by. That's mandatory for patches to
> > > > be acepted.  
> > > 
> > > Ok, still learning
> > > 
> > > >   
> > > > > 
> > > > > ---
> > > > >  em28xx-cards.c | 30 +-
> > > > >  em28xx-dvb.c   |  1 +
> > > > >  em28xx.h   |  1 +
> > > > >  3 files changed, 31 insertions(+), 1 deletion(-)
> > > > 
> > > > 
> > > > use git diff against upstream tree. This should be using
> > > > a different paths there, e.g. drivers/media/usb/em28xx/...  
> > > 
> > > This is actually against the upstream tree, in line with your advice in a 
> > > previous mail.
> > > After git clone... and ./build, I did not do "make install" but 
> > > copy-paste out of the /media_build/linux/drivers/media/usb/em28xx
> > > Reason, I do not have an experimental pc and some parts are experimental.
> > > I did not want to take the risk to crash my working pc at this moment in 
> > > time.
> > > 
> > > I will try to work around this problem.
> > 
> > Upstream is actually this tree:
> > 
> > https://git.linuxtv.org/media_tree.git/
> > 
> > The media_build tree is what we call a "backport tree" :-)  
> 
> I started with 
> "https://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches; in 
> line with your advice in a previous mail.

The first line there at "Patch preparation" says:

"For Kernel media patches, they should be created against the Linux 
Kernel master linux_media git tree[1]"

[1] With links to: http://git.linuxtv.org/media_tree.git

> Followed the text to 
> "https://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device
>  Drivers" basic approach.

I see... here, information were indeed incomplete.

I just updated it.


> Also to "https://git.linuxtv.org/media_build.git/about/;
> I have used "git clone --depth=1 git://linuxtv.org/media_build.git" followed 
> by ./build and copy/paste files mentioned above.
> This is not the required upstream tree ?

There's a similar instruction at media_tree.git/about, with is the one you
would be using instead.

> 
> Work around:
> Added the path to all files manually.
> This is acceptable ?

An acceptable workaround would be to create another tree at the place
it untars the driver's tarball (under linux dir), and do the
diffs there.

The ./build script actually does something similar to that, if used
with the --main-git option, but, if you're willing to use it, be
careful to do on a separate clone, as otherwise it may destroy your
work, as it will setup a different environment, and you'll lose
any changes you've made inside that media_build cloned tree.

Thanks,
Mauro

[no subject]

[SHANE MISSLER]

--
Mein Name ist SHANE MISSLER. Ich habe den Jackpot im Wert von $451 
Millionen Lotto im Januar 2018 gewonnen. Ich habe eine Spende von 
€2.100.000  für Sie. Ich spende Ihnen diese Spende wegen der Liebe, die 
ich für die Menschheit und die Bedürftigen in der Gesellschaft habe. 
Bitte kontaktieren Sie mich für weitere Informationen.

Re: [PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick"

[mjs]

Op Wed, 25 Apr 2018 08:18:55 -0300
Mauro Carvalho Chehab  schreef:

> Em Wed, 25 Apr 2018 12:11:10 +0200
> mjs  escreveu:
> 
> > Op Wed, 25 Apr 2018 06:16:20 -0300
> > Mauro Carvalho Chehab  schreef:
> >   
> > > Em Wed, 25 Apr 2018 11:09:50 +0200
> > > mjs  escreveu:
> > > 
> > > > From 0a3355b47dc465c6372d30fa4a36d1c5db6c0fe2 Mon Sep 17 00:00:00 2001
> > > > From: Marcel Stork 
> > > > Date: Wed, 25 Apr 2018 10:53:34 +0200
> > > > Subject: [PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick".
> > > > 
> > > > Extra code to be able to use this stick, only digital, not analog nor 
> > > > remote-control.
> > > > 
> > > > Changes to be committed:
> > > > modified:   em28xx-cards.c
> > > > modified:   em28xx-dvb.c
> > > > modified:   em28xx.h  
> > > 
> > > You forgot to add your Signed-off-by. That's mandatory for patches to
> > > be acepted.
> > 
> > Ok, still learning
> >   
> > > 
> > > > 
> > > > ---
> > > >  em28xx-cards.c | 30 +-
> > > >  em28xx-dvb.c   |  1 +
> > > >  em28xx.h   |  1 +
> > > >  3 files changed, 31 insertions(+), 1 deletion(-)  
> > > 
> > > 
> > > use git diff against upstream tree. This should be using
> > > a different paths there, e.g. drivers/media/usb/em28xx/...
> > 
> > This is actually against the upstream tree, in line with your advice in a 
> > previous mail.
> > After git clone... and ./build, I did not do "make install" but copy-paste 
> > out of the /media_build/linux/drivers/media/usb/em28xx
> > Reason, I do not have an experimental pc and some parts are experimental.
> > I did not want to take the risk to crash my working pc at this moment in 
> > time.
> > 
> > I will try to work around this problem.  
> 
> Upstream is actually this tree:
> 
>   https://git.linuxtv.org/media_tree.git/
> 
> The media_build tree is what we call a "backport tree" :-)

I started with 
"https://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches; in line 
with your advice in a previous mail.
Followed the text to 
"https://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device
 Drivers" basic approach.
Also to "https://git.linuxtv.org/media_build.git/about/;
I have used "git clone --depth=1 git://linuxtv.org/media_build.git" followed by 
./build and copy/paste files mentioned above.
This is not the required upstream tree ?

Work around:
Added the path to all files manually.
This is acceptable ?

> 
> >
> 
> > > 
> > > > 
> > > > diff --git a/em28xx-cards.c b/em28xx-cards.c
> > > > index 6e0e67d..01b38a4 100644
> > > > --- a/em28xx-cards.c
> > > > +++ b/em28xx-cards.c
> > > > @@ -87,6 +87,21 @@ static const struct em28xx_reg_seq default_digital[] 
> > > > = {
> > > > {   -1, -1, -1, -1},
> > > >  };
> > > >  
> > > > +/* Board Zolid Hybrid Tv Stick */
> > > > +static struct em28xx_reg_seq zolid_tuner[] = {
> > > > +   {EM2820_R08_GPIO_CTRL,  0xfd,   0xff,   100},
> > > > +   {EM2820_R08_GPIO_CTRL,  0xfe,   0xff,   100},
> > > > +   {   -1, -1, 
> > > > -1,  -1},
> > > > +};
> > > > +
> > > > +static struct em28xx_reg_seq zolid_digital[] = {
> > > > +   {EM2820_R08_GPIO_CTRL,  0x6a,   0xff,   100},
> > > > +   {EM2820_R08_GPIO_CTRL,  0x7a,   0xff,   100},
> > > > +   {EM2880_R04_GPO,0x04,   0xff,   
> > > > 100},
> > > > +   {EM2880_R04_GPO,0x0c,   0xff,   
> > > > 100},
> > > > +   {   -1, -1, 
> > > > -1,  -1},
> > > > +};
> > > > +
> > > >  /* Board Hauppauge WinTV HVR 900 analog */
> > > >  static const struct em28xx_reg_seq hauppauge_wintv_hvr_900_analog[] = {
> > > > {EM2820_R08_GPIO_CTRL,  0x2d,   ~EM_GPIO_4, 10},
> > > > @@ -679,6 +694,16 @@ const struct em28xx_board em28xx_boards[] = {
> > > > .amux = EM28XX_AMUX_VIDEO,
> > > > } },
> > > > },
> > > > +   [EM2882_BOARD_ZOLID_HYBRID_TV_STICK] = {
> > > > +   .name   = ":ZOLID HYBRID TV STICK",
> > > > +   .tuner_type = TUNER_XC2028,
> > > > +   .tuner_gpio = zolid_tuner,
> > > > +   .decoder= EM28XX_TVP5150,
> > > > +   .xclk   = EM28XX_XCLK_FREQUENCY_12MHZ,
> > > > +   .mts_firmware   = 1,
> > > > +   .has_dvb= 1,
> > > > +   .dvb_gpio   = zolid_digital,
> > > > +   },
> > > > [EM2820_BOARD_KWORLD_PVRTV2800RF] = {
> > > > .name = "Kworld PVR TV 2800 RF",
> 

Re: [PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick"

[Mauro Carvalho Chehab]

Em Wed, 25 Apr 2018 12:11:10 +0200
mjs  escreveu:

> Op Wed, 25 Apr 2018 06:16:20 -0300
> Mauro Carvalho Chehab  schreef:
> 
> > Em Wed, 25 Apr 2018 11:09:50 +0200
> > mjs  escreveu:
> >   
> > > From 0a3355b47dc465c6372d30fa4a36d1c5db6c0fe2 Mon Sep 17 00:00:00 2001
> > > From: Marcel Stork 
> > > Date: Wed, 25 Apr 2018 10:53:34 +0200
> > > Subject: [PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick".
> > > 
> > > Extra code to be able to use this stick, only digital, not analog nor 
> > > remote-control.
> > > 
> > > Changes to be committed:
> > >   modified:   em28xx-cards.c
> > >   modified:   em28xx-dvb.c
> > >   modified:   em28xx.h
> > 
> > You forgot to add your Signed-off-by. That's mandatory for patches to
> > be acepted.  
> 
> Ok, still learning
> 
> >   
> > > 
> > > ---
> > >  em28xx-cards.c | 30 +-
> > >  em28xx-dvb.c   |  1 +
> > >  em28xx.h   |  1 +
> > >  3 files changed, 31 insertions(+), 1 deletion(-)
> > 
> > 
> > use git diff against upstream tree. This should be using
> > a different paths there, e.g. drivers/media/usb/em28xx/...  
> 
> This is actually against the upstream tree, in line with your advice in a 
> previous mail.
> After git clone... and ./build, I did not do "make install" but copy-paste 
> out of the /media_build/linux/drivers/media/usb/em28xx
> Reason, I do not have an experimental pc and some parts are experimental.
> I did not want to take the risk to crash my working pc at this moment in time.
> 
> I will try to work around this problem.

Upstream is actually this tree:

https://git.linuxtv.org/media_tree.git/

The media_build tree is what we call a "backport tree" :-)

>  

> >   
> > > 
> > > diff --git a/em28xx-cards.c b/em28xx-cards.c
> > > index 6e0e67d..01b38a4 100644
> > > --- a/em28xx-cards.c
> > > +++ b/em28xx-cards.c
> > > @@ -87,6 +87,21 @@ static const struct em28xx_reg_seq default_digital[] = 
> > > {
> > >   {   -1, -1, -1, -1},
> > >  };
> > >  
> > > +/* Board Zolid Hybrid Tv Stick */
> > > +static struct em28xx_reg_seq zolid_tuner[] = {
> > > + {EM2820_R08_GPIO_CTRL,  0xfd,   0xff,   100},
> > > + {EM2820_R08_GPIO_CTRL,  0xfe,   0xff,   100},
> > > + {   -1, -1, 
> > > -1,  -1},
> > > +};
> > > +
> > > +static struct em28xx_reg_seq zolid_digital[] = {
> > > + {EM2820_R08_GPIO_CTRL,  0x6a,   0xff,   100},
> > > + {EM2820_R08_GPIO_CTRL,  0x7a,   0xff,   100},
> > > + {EM2880_R04_GPO,0x04,   0xff,   100},
> > > + {EM2880_R04_GPO,0x0c,   0xff,   100},
> > > + {   -1, -1, 
> > > -1,  -1},
> > > +};
> > > +
> > >  /* Board Hauppauge WinTV HVR 900 analog */
> > >  static const struct em28xx_reg_seq hauppauge_wintv_hvr_900_analog[] = {
> > >   {EM2820_R08_GPIO_CTRL,  0x2d,   ~EM_GPIO_4, 10},
> > > @@ -679,6 +694,16 @@ const struct em28xx_board em28xx_boards[] = {
> > >   .amux = EM28XX_AMUX_VIDEO,
> > >   } },
> > >   },
> > > + [EM2882_BOARD_ZOLID_HYBRID_TV_STICK] = {
> > > + .name   = ":ZOLID HYBRID TV STICK",
> > > + .tuner_type = TUNER_XC2028,
> > > + .tuner_gpio = zolid_tuner,
> > > + .decoder= EM28XX_TVP5150,
> > > + .xclk   = EM28XX_XCLK_FREQUENCY_12MHZ,
> > > + .mts_firmware   = 1,
> > > + .has_dvb= 1,
> > > + .dvb_gpio   = zolid_digital,
> > > + },
> > >   [EM2820_BOARD_KWORLD_PVRTV2800RF] = {
> > >   .name = "Kworld PVR TV 2800 RF",
> > >   .tuner_type   = TUNER_TEMIC_PAL,
> > > @@ -2493,7 +2518,7 @@ struct usb_device_id em28xx_id_table[] = {
> > >   .driver_info = EM2820_BOARD_UNKNOWN },
> > >   { USB_DEVICE(0xeb1a, 0x2881),
> > >   .driver_info = EM2820_BOARD_UNKNOWN },
> > > - { USB_DEVICE(0xeb1a, 0x2883),
> > > + { USB_DEVICE(0xeb1a, 0x2883), /* used by zolid hybrid tv stick */
> > >   .driver_info = EM2820_BOARD_UNKNOWN },
> > >   { USB_DEVICE(0xeb1a, 0x2868),
> > >   .driver_info = EM2820_BOARD_UNKNOWN },
> > > @@ -2688,6 +2713,7 @@ static const struct em28xx_hash_table 
> > > em28xx_eeprom_hash[] = {
> > >   {0xb8846b20, EM2881_BOARD_PINNACLE_HYBRID_PRO, TUNER_XC2028},
> > >   {0x63f653bd, EM2870_BOARD_REDDO_DVB_C_USB_BOX, TUNER_ABSENT},
> > >   {0x4e913442, EM2882_BOARD_DIKOM_DK300, TUNER_XC2028},
> > > + {0x85dd871e, EM2882_BOARD_ZOLID_HYBRID_TV_STICK, TUNER_XC2028},
> > >  };
> > >  
> > >  /* I2C devicelist hash table for devices with generic USB IDs */
> > > @@ -2699,6 +2725,7 @@ static const struct 

[PATCH 1/2] dt-bindings: media: renesas-ceu: Add R-Mobile R8A7740

[Jacopo Mondi]

Add R-Mobile A1 R8A7740 SoC to the list of compatible values for the CEU
unit.

Signed-off-by: Jacopo Mondi 
---
 Documentation/devicetree/bindings/media/renesas,ceu.txt | 7 ---
 drivers/media/platform/renesas-ceu.c| 1 +
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
b/Documentation/devicetree/bindings/media/renesas,ceu.txt
index 3fc66df..8a7a616 100644
--- a/Documentation/devicetree/bindings/media/renesas,ceu.txt
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
@@ -2,14 +2,15 @@ Renesas Capture Engine Unit (CEU)
 --
 
 The Capture Engine Unit is the image capture interface found in the Renesas
-SH Mobile and RZ SoCs.
+SH Mobile, R-Mobile and RZ SoCs.
 
 The interface supports a single parallel input with data bus width of 8 or 16
 bits.
 
 Required properties:
-- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in RZ/A1H
-  and RZ/A1M SoCs.
+- compatible: Shall be one of the following values:
+   "renesas,r7s72100-ceu" for CEU units found in RZ/A1H and RZ/A1M SoCs
+   "renesas,r8a7740-ceu" for CEU units found in R-Mobile A1 R8A7740 SoCs
 - reg: Registers address base and size.
 - interrupts: The interrupt specifier.
 
diff --git a/drivers/media/platform/renesas-ceu.c 
b/drivers/media/platform/renesas-ceu.c
index 6599dba..c964a56 100644
--- a/drivers/media/platform/renesas-ceu.c
+++ b/drivers/media/platform/renesas-ceu.c
@@ -1545,6 +1545,7 @@ static const struct ceu_data ceu_data_sh4 = {
 #if IS_ENABLED(CONFIG_OF)
 static const struct of_device_id ceu_of_match[] = {
{ .compatible = "renesas,r7s72100-ceu", .data = _data_rz },
+   { .compatible = "renesas,r8a7740-ceu", .data = _data_rz },
{ }
 };
 MODULE_DEVICE_TABLE(of, ceu_of_match);
-- 
2.7.4

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Monday, April 23, 2018 05:11:14 PM Tomi Valkeinen wrote:
> On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:
> 
> > Ideally we should be able to build both drivers in the same kernel
> > (especially as modules).
> > 
> > I was hoping that it could be fixed easily but then I discovered
> > the root source of the problem:
> > 
> > drivers/gpu/drm/omapdrm/dss/display.o: In function 
> > `omapdss_unregister_display':
> > display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display'
> > drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): 
> > first defined here
> 
> The main problem is that omapdrm and omapfb are two different drivers
> for the same HW. You need to pick one, even if we would change those
> functions and fix the link issue.

With proper resource allocation in both drivers this shouldn't be
a problem - the one which allocates resources first will be used
(+ we can initialize omapdrm first in case it is built-in). This is
how similar situations are handled in other kernel subsystems.

It seems that the real root problem is commit f76ee892a99e ("omapfb:
copy omapdss & displays for omapfb") from Dec 2015 which resulted in
duplication of ~30 KLOC of code. The code in question seems to be
both fbdev & drm independent:

"
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for 
the
  display subsystem IPs used on OMAP (and related) SoCs. It offers only a
  kernel internal API, and does not implement anything for fbdev or drm.

* omapdss panels and encoders, located in
  drivers/video/fbdev/omap2/displays-new/. These are panel and external 
encoder
  drivers, which use APIs offered by omapdss driver. These also don't 
implement
  anything for fbdev or drm.
"

While I understand some motives behind this change I'm not overall
happy with it..

> At some point in time we could compile both as modules (but not
> built-in), but the only use for that was development/testing and in the
> end made our life more difficult. So, now you must fully disable one of
> them to enable the other. And, actually, we even have boot-time code,
> not included in the module itself, which gets enabled when omapdrm is
> enabled.

Do you mean some code in arch/arm/mach-omap2/ or something else?

> While it's of course good to support COMPILE_TEST, if using COMPILE_TEST
> with omapfb is problematic, I'm not sure if it's worth to spend time on
> that. We should be moving away from omapfb to omapdrm.

Is there some approximate schedule for omapfb removal available?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

[PATCH 2/2] ARM: dts: r8a7740: Enable CEU0

[Jacopo Mondi]

Enable CEU0 peripheral for Renesas R-Mobile A1 R8A7740.

Signed-off-by: Jacopo Mondi 
---
 arch/arm/boot/dts/r8a7740.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index afd3bc5..05ec41e 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -67,6 +67,16 @@
power-domains = <_d4>;
};
 
+   ceu0: ceu@fe91 {
+   reg = <0xfe91 0x100>;
+   compatible = "renesas,r8a7740-ceu";
+   interrupts = ;
+   clocks = <_clks R8A7740_CLK_CEU20>;
+   clock-names = "ceu20";
+   power-domains = <_a4mp>;
+   status = "disabled";
+   };
+
cmt1: timer@e6138000 {
compatible = "renesas,cmt-48-r8a7740", "renesas,cmt-48";
reg = <0xe6138000 0x170>;
-- 
2.7.4

Re: [PATCH] media: zoran: move to dma-mapping interface

[Arnd Bergmann]

On Wed, Apr 25, 2018 at 9:21 AM, Christoph Hellwig  wrote:
> On Wed, Apr 25, 2018 at 09:08:13AM +0200, Arnd Bergmann wrote:
>> > That probably also means it can use dma_mmap_coherent instead of the
>> > handcrafted remap_pfn_range loop and the PageReserved abuse.
>>
>> I'd rather not touch that code. How about adding a comment about
>> the fact that it should use dma_mmap_coherent()?
>
> Maybe the real question is if there is anyone that actually cares
> for this driver, or if we are better off just removing it?
>
> Same is true for various other virt_to_bus using drivers, e.g. the
> grotty atm drivers.

That thought had occurred to me as well. I removed the oldest ISDN
drivers already some years ago, and the OSS sound drivers
got removed as well, and comedi got converted to the dma-mapping
interfaces, so there isn't much left at all now. This is what we
have as of v4.17-rc1:

$ git grep -wl '\' drivers/
drivers/atm/ambassador.c
drivers/atm/firestream.c
drivers/atm/horizon.c
drivers/atm/zatm.c
drivers/block/swim3.c # power mac specific
drivers/gpu/drm/mga/mga_dma.c # commented out
drivers/infiniband/hw/nes/nes_verbs.c # commented out
drivers/isdn/hisax/netjet.c
drivers/net/appletalk/ltpc.c
drivers/net/ethernet/amd/au1000_eth.c # mips specific
drivers/net/ethernet/amd/ni65.c # only in comment
drivers/net/ethernet/apple/bmac.c # power mac specific
drivers/net/ethernet/apple/mace.c # power mac specific
drivers/net/ethernet/dec/tulip/de4x5.c  # trivially fixable
drivers/net/ethernet/i825xx/82596.c # m68k specific
drivers/net/ethernet/i825xx/lasi_82596.c # parisc specific
drivers/net/ethernet/i825xx/lib82596.c # only in comment
drivers/net/ethernet/sgi/ioc3-eth.c # mips specific
drivers/net/wan/cosa.c
drivers/net/wan/lmc/lmc_main.c
drivers/net/wan/z85230.c
drivers/scsi/3w-.c # only in comment
drivers/scsi/BusLogic.c
drivers/scsi/a2091.c # m68k specific
drivers/scsi/a3000.c # m68k specific
drivers/scsi/dc395x.c # only in comment
drivers/scsi/dpt_i2o.c
drivers/scsi/gvp11.c # m68k specific
drivers/scsi/mvme147.c # m68k specific
drivers/scsi/qla1280.c # comment only
drivers/staging/netlogic/xlr_net.c # mips specific
drivers/tty/serial/cpm_uart/cpm_uart_cpm2.c # ppc32 specific
drivers/vme/bridges/vme_ca91cx42.c

My feeling is that we want to keep most of the arch specific
ones, in particular removing the m68k drivers would break
a whole class of machines.

For the ones that don't have a comment on them, they
probably won't be missed much, but it's hard to know for
sure. What we do know is that they never worked on
x86_64, and most of them are for ISA cards.

Arnd

[PATCH 0/2] renesas: ceu: Add R-Mobile A1

[Jacopo Mondi]

Hello,
   this small series add R-Mobile A1 R8A7740 to the list of CEU supported
SoCs, and adds the CEU node to r8a7740.dtsi.

All the information on CEU clocks, power domains and memory regions have been
deducted from the now-deleted board file:
arch/arm/mach-shmobile/board-armadillo800eva.c

Thanks
   j

Jacopo Mondi (2):
  dt-bindings: media: renesas-ceu: Add R-Mobile R8A7740
  ARM: dts: r8a7740: Enable CEU0

 Documentation/devicetree/bindings/media/renesas,ceu.txt |  7 ---
 arch/arm/boot/dts/r8a7740.dtsi  | 10 ++
 drivers/media/platform/renesas-ceu.c|  1 +
 3 files changed, 15 insertions(+), 3 deletions(-)

--
2.7.4

[PATCH 1/2] dt-bindings: media: i2c: Add mt9t111 image sensor

[Jacopo Mondi]

Add device tree bindings documentation for Micron MT9T111/MT9T112 image
sensors.

Signed-off-by: Jacopo Mondi 
---
 Documentation/devicetree/bindings/mt9t112.txt | 41 +++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mt9t112.txt

diff --git a/Documentation/devicetree/bindings/mt9t112.txt 
b/Documentation/devicetree/bindings/mt9t112.txt
new file mode 100644
index 000..cbad475
--- /dev/null
+++ b/Documentation/devicetree/bindings/mt9t112.txt
@@ -0,0 +1,41 @@
+Micron 3.1Mp CMOS Digital Image Sensor
+--
+
+The Micron MT9T111 and MT9T112 are 1/4 inch 3.1Mp System-On-A-Chip (SOC) CMOS
+digital image sensors which support up to QXGA (2048x1536) image resolution in
+4/3 format.
+
+The sensors can be programmed through a two-wire serial interface and can
+work both in parallel data output mode as well as in MIPI CSI-2 mode.
+
+Required Properties:
+- compatible: shall be one of the following values
+   "micron,mt9t111" for MT9T111 sensors
+   "micron,mt9t112" for MT9T112 sensors
+
+Optional properties:
+- powerdown-gpios: reference to powerdown input GPIO signal. Pin name 
"STANDBY".
+  Active level is high.
+
+The device node shall contain one 'port' sub-node with one 'endpoint' child
+node, modeled accordingly to bindings described in:
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+
+   mt9t112@3d {
+   compatible = "micron,mt9t112";
+   reg = <0x3d>;
+
+   powerdown-gpios = < 2 GPIO_ACTIVE_HIGH>;
+
+   port {
+   mt9t112_out: endpoint {
+   pclk-sample = <1>;
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+
+
-- 
2.7.4

[PATCH 0/2] media: i2c: mt9t112: Add OF tree support

[Jacopo Mondi]

Hello,

this small series add device tree support for the MT9T112 image
sensor.

As in the device tree bindings I used 'semi-standard' name for the
'powerdown' GPIO, I have changed that for all other users of the mt9t112
driver (SH Ecovec only).

A note on clock: as the mt9t112 driver expects to receive the PPL parameter
configuration from platform data (I know...), new OF users are only supported
with an external clock frequency of 24MHz.

Thanks
   j

Jacopo Mondi (2):
  dt-bindings: media: i2c: Add mt9t111 image sensor
  media: i2c: mt9t112: Add device tree support

 Documentation/devicetree/bindings/mt9t112.txt | 41 +
 arch/sh/boards/mach-ecovec24/setup.c  |  4 +-
 drivers/media/i2c/mt9t112.c   | 87 +++
 3 files changed, 118 insertions(+), 14 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mt9t112.txt

--
2.7.4

[PATCH 2/2] media: i2c: mt9t112: Add device tree support

[Jacopo Mondi]

Add support for OF systems to mt9t112 image sensor driver.

As the devicetree bindings use standard name for 'powerdown' gpio, and while
at there, update the existing mt9t112 users to use the new name.

Signed-off-by: Jacopo Mondi 
---
 arch/sh/boards/mach-ecovec24/setup.c |  4 +-
 drivers/media/i2c/mt9t112.c  | 87 +++-
 2 files changed, 77 insertions(+), 14 deletions(-)

diff --git a/arch/sh/boards/mach-ecovec24/setup.c 
b/arch/sh/boards/mach-ecovec24/setup.c
index adc61d1..16de9ec 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -480,7 +480,7 @@ static struct gpiod_lookup_table tw9910_gpios = {
 static struct gpiod_lookup_table mt9t112_0_gpios = {
.dev_id = "0-003c",
.table  = {
-   GPIO_LOOKUP("sh7724_pfc", GPIO_PTA3, "standby",
+   GPIO_LOOKUP("sh7724_pfc", GPIO_PTA3, "powerdown",
GPIO_ACTIVE_HIGH),
},
 };
@@ -488,7 +488,7 @@ static struct gpiod_lookup_table mt9t112_0_gpios = {
 static struct gpiod_lookup_table mt9t112_1_gpios = {
.dev_id = "1-003c",
.table  = {
-   GPIO_LOOKUP("sh7724_pfc", GPIO_PTA4, "standby",
+   GPIO_LOOKUP("sh7724_pfc", GPIO_PTA4, "powerdown",
GPIO_ACTIVE_HIGH),
},
 };
diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
index af8cca9..704e7fb 100644
--- a/drivers/media/i2c/mt9t112.c
+++ b/drivers/media/i2c/mt9t112.c
@@ -32,6 +32,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 

@@ -77,6 +78,15 @@
 #define VAR(id, offset)  _VAR(id, offset, 0x)
 #define VAR8(id, offset) _VAR(id, offset, 0x8000)

+/*
+ * Default PLL configuration for 24MHz input clock
+ */
+static struct mt9t112_platform_data mt9t112_default_pdata_24MHz = {
+   .divider= {
+   0x49, 0x6, 0, 6, 0, 9, 9, 6, 0,
+   },
+};
+
 /
  * struct
  ***/
@@ -88,6 +98,7 @@ struct mt9t112_format {
 };

 struct mt9t112_priv {
+   struct device   *dev;
struct v4l2_subdev   subdev;
struct mt9t112_platform_data*info;
struct i2c_client   *client;
@@ -1066,13 +1077,39 @@ static int mt9t112_camera_probe(struct i2c_client 
*client)
return ret;
 }

+static int mt9t112_parse_dt(struct mt9t112_priv *priv)
+{
+   struct fwnode_handle *fwnode = dev_fwnode(priv->dev);
+   struct fwnode_handle *ep;
+   struct v4l2_fwnode_endpoint vep;
+   int ret;
+
+   ep = fwnode_graph_get_next_endpoint(fwnode, NULL);
+   if (IS_ERR_OR_NULL(ep)) {
+   dev_err(priv->dev, "No endpoint registered\n");
+   return PTR_ERR(ep);
+   }
+
+   ret = v4l2_fwnode_endpoint_parse(ep, );
+   fwnode_handle_put(ep);
+   if (ret) {
+   dev_err(priv->dev, "Unable to parse endpoint: %d\n", ret);
+   return ret;
+   }
+
+   if (vep.bus.parallel.flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
+   priv->info->flags = MT9T112_FLAG_PCLK_RISING_EDGE;
+
+   return 0;
+}
+
 static int mt9t112_probe(struct i2c_client *client,
 const struct i2c_device_id *did)
 {
struct mt9t112_priv *priv;
int ret;

-   if (!client->dev.platform_data) {
+   if (!client->dev.of_node && !client->dev.platform_data) {
dev_err(>dev, "mt9t112: missing platform data!\n");
return -EINVAL;
}
@@ -1081,23 +1118,39 @@ static int mt9t112_probe(struct i2c_client *client,
if (!priv)
return -ENOMEM;

-   priv->info = client->dev.platform_data;
priv->init_done = false;
-
-   v4l2_i2c_subdev_init(>subdev, client, _subdev_ops);
-
-   priv->clk = devm_clk_get(>dev, "extclk");
-   if (PTR_ERR(priv->clk) == -ENOENT) {
+   priv->dev = >dev;
+
+   if (client->dev.platform_data) {
+   priv->info = client->dev.platform_data;
+
+   priv->clk = devm_clk_get(>dev, "extclk");
+   if (PTR_ERR(priv->clk) == -ENOENT) {
+   priv->clk = NULL;
+   } else if (IS_ERR(priv->clk)) {
+   dev_err(>dev,
+   "Unable to get clock \"extclk\"\n");
+   return PTR_ERR(priv->clk);
+   }
+   } else {
+   /*
+* External clock frequencies != 24MHz are only supported
+* for non-OF systems.
+*/
priv->clk = NULL;
-   } else if (IS_ERR(priv->clk)) {
-   dev_err(>dev, "Unable to get clock \"extclk\"\n");
-   return PTR_ERR(priv->clk);
+   priv->info = 

Re: [PATCH v3 2/2] media: Add a driver for the ov7251 camera sensor

[Sakari Ailus]

Hi Todor,

Thanks for the update. Just a few minor comments below.

On Tue, Apr 24, 2018 at 06:01:07PM +0300, Todor Tomov wrote:
> The ov7251 sensor is a 1/7.5-Inch B VGA (640x480) CMOS Digital Image
> Sensor from Omnivision.
> 
> The driver supports the following modes:
> - 640x480 30fps
> - 640x480 60fps
> - 640x480 90fps
> 
> Output format is 10bit B RAW - MEDIA_BUS_FMT_Y10_1X10.
> 
> The driver supports configuration via user controls for:
> - exposure and gain;
> - horizontal and vertical flip;
> - test pattern.
> 
> Signed-off-by: Todor Tomov 
> Reviewed-by: Jacopo Mondi 
> ---
>  drivers/media/i2c/Kconfig  |   13 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/ov7251.c | 1501 
> 
>  3 files changed, 1515 insertions(+)
>  create mode 100644 drivers/media/i2c/ov7251.c
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 541f0d28..1ff7aaf 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -688,6 +688,19 @@ config VIDEO_OV5695
> To compile this driver as a module, choose M here: the
> module will be called ov5695.
>  
> +config VIDEO_OV7251
> + tristate "OmniVision OV7251 sensor support"
> + depends on OF

I think you could drop OF dependency.

> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CAMERA_SUPPORT
> + select V4L2_FWNODE
> + help
> +   This is a Video4Linux2 sensor-level driver for the OmniVision
> +   OV7251 camera.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ov7251.
> +
>  config VIDEO_OV772X
>   tristate "OmniVision OV772x sensor support"
>   depends on I2C && VIDEO_V4L2
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index ea34aee..c8585b1 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -70,6 +70,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
>  obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
>  obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
>  obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
> +obj-$(CONFIG_VIDEO_OV7251) += ov7251.o
>  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
>  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
>  obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
> diff --git a/drivers/media/i2c/ov7251.c b/drivers/media/i2c/ov7251.c
> new file mode 100644
> index 000..69e70a0
> --- /dev/null
> +++ b/drivers/media/i2c/ov7251.c
> @@ -0,0 +1,1501 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for the OV7251 camera sensor.
> + *
> + * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2017-2018, Linaro Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define OV7251_SC_MODE_SELECT0x0100
> +#define OV7251_SC_MODE_SELECT_SW_STANDBY 0x0
> +#define OV7251_SC_MODE_SELECT_STREAMING  0x1
> +
> +#define OV7251_CHIP_ID_HIGH  0x300a
> +#define OV7251_CHIP_ID_HIGH_BYTE 0x77
> +#define OV7251_CHIP_ID_LOW   0x300b
> +#define OV7251_CHIP_ID_LOW_BYTE  0x50
> +#define OV7251_SC_GP_IO_IN1  0x3029
> +#define OV7251_AEC_EXPO_00x3500
> +#define OV7251_AEC_EXPO_10x3501
> +#define OV7251_AEC_EXPO_20x3502
> +#define OV7251_AEC_AGC_ADJ_0 0x350a
> +#define OV7251_AEC_AGC_ADJ_1 0x350b
> +#define OV7251_TIMING_FORMAT10x3820
> +#define OV7251_TIMING_FORMAT1_VFLIP  BIT(2)
> +#define OV7251_TIMING_FORMAT20x3821
> +#define OV7251_TIMING_FORMAT2_MIRROR BIT(2)
> +#define OV7251_PRE_ISP_000x5e00
> +#define OV7251_PRE_ISP_00_TEST_PATTERN   BIT(7)
> +
> +struct reg_value {
> + u16 reg;
> + u8 val;
> +};
> +
> +struct ov7251_mode_info {
> + u32 width;
> + u32 height;
> + const struct reg_value *data;
> + u32 data_size;
> + u32 pixel_clock;
> + u32 link_freq;
> + u16 exposure_max;
> + u16 exposure_def;
> + struct v4l2_fract timeperframe;
> +};
> +
> +struct ov7251 {
> + struct i2c_client *i2c_client;
> + struct device *dev;
> + struct v4l2_subdev sd;
> + struct media_pad pad;
> + struct v4l2_fwnode_endpoint ep;
> + struct v4l2_mbus_framefmt fmt;
> + struct v4l2_rect crop;
> + struct clk *xclk;
> + u32 xclk_freq;
> +
> + struct regulator *io_regulator;
> + struct regulator *core_regulator;
> + struct regulator *analog_regulator;
> +
> + const struct ov7251_mode_info *current_mode;
> +
> + struct v4l2_ctrl_handler ctrls;
> + struct v4l2_ctrl *pixel_clock;
> + struct v4l2_ctrl *link_freq;
> + struct v4l2_ctrl *exposure;
> + struct v4l2_ctrl *gain;
> +
> + /* Cached register values */
> + u8 aec_pk_manual;
> + u8 

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Monday, April 23, 2018 10:55:57 AM Mauro Carvalho Chehab wrote:
> Em Mon, 23 Apr 2018 14:47:28 +0200
> Bartlomiej Zolnierkiewicz  escreveu:
> 
> > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > > Add stubs for omapfb_dss.h, in the case it is included by
> > > some driver when CONFIG_FB_OMAP2 is not defined, with can
> > > happen on ARM when DRM_OMAP is not 'n'.
> > > 
> > > That allows building such driver(s) with COMPILE_TEST.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab   
> > 
> > This patch should be dropped (together with patch #6/7) as it was
> > superseded by a better solution suggested by Laurent:
> > 
> > https://patchwork.kernel.org/patch/10325193/
> > 
> > ACK-ed by Tomi:
> > 
> > https://www.spinics.net/lists/dri-devel/msg171918.html
> > 
> > and already merged by you (commit 7378f1149884 "media: omap2:
> > omapfb: allow building it with COMPILE_TEST")..
> 
> I "ressurected" this patch due to patch 6/7.
> 
> The problem with the solution already acked/merged is that
> it works *only* if you don't try to build for ARM.
> 
> At the moment you want to build a FB_OMAP2-dependent driver
> on ARM with allyesc onfig, DRM_OMAP will be true, and FB_OMAP2
> will be disabled:
> 
>   menuconfig FB_OMAP2
>   tristate "OMAP2+ frame buffer support"
>   depends on FB
>   depends on DRM_OMAP = n
> 
> One solution might be to change the depends on to:
>   depends on (DRM_OMAP = n || COMPILE_TEST)
> 
> But someone pointed me that the above check was added to avoid building
> duplicated symbols. So, the above would cause build failures.
> 
> So, in order to build for ARM with DRM_OMAP selected (allyesconfig,
> allmodconfig), we have the following alternatives:
> 
>   1) apply patch 5/7;
>   2) make sure that FB_OMAP2 and DRM_OMAP won't declare the
>  same non-static symbols;
>   3) redesign FB_OMAP2 to work with DRM_OMAP built.
> 
> I suspect that (1) is easier.

I agree.

You can merge this patch through your tree with:

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 25 April 2018 13:10:43 EEST Tomi Valkeinen wrote:
> On 25/04/18 13:02, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
> >> On 25/04/18 12:03, Laurent Pinchart wrote:
> >>> Could we trim down omapfb to remove support for the devices supported by
> >>> omapdrm ?
> >> 
> >> I was thinking about just that. But, of course, it's not quite
> >> straightforward either.
> >> 
> >> We've got DSI manual update functionality in OMAP3-OMAP5 SoCs, which
> >> covers a lot of devices.
> > 
> > Sebastian is working on getting that feature in omapdrm, isn't he ?
> 
> Yes, and I keep pushing it forward because of the restructuring you're
> doing =) (feel free to comment on that thread). But agreed, it's getting
> better. When we have manual update support, I think the biggest missing
> feature is then in omapdrm.
> 
> >> And VRFB on OMAP2/3.
> > 
> > And that's something I'd really like to have in omapdrm too.
> 
> Considering how much headache TILER has given, I'm not exactly looking
> forward to it ;).
> 
> If we get manual update and VRFB, I think we are more or less covered on
> the supported HW features. It'll still break userspace apps which use
> omapfb, though. Unless we also port the omapfb specific IOCTLs and the
> sysfs files, which I believe we should not.

I agree with you, we shouldn't. We'll need a grace period before removing 
omapfb, if we ever do so.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 25/04/18 13:02, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
>> On 25/04/18 12:03, Laurent Pinchart wrote:
>>> Could we trim down omapfb to remove support for the devices supported by
>>> omapdrm ?
>>
>> I was thinking about just that. But, of course, it's not quite
>> straightforward either.
>>
>> We've got DSI manual update functionality in OMAP3-OMAP5 SoCs, which
>> covers a lot of devices.
> 
> Sebastian is working on getting that feature in omapdrm, isn't he ?

Yes, and I keep pushing it forward because of the restructuring you're
doing =) (feel free to comment on that thread). But agreed, it's getting
better. When we have manual update support, I think the biggest missing
feature is then in omapdrm.

>> And VRFB on OMAP2/3.
> 
> And that's something I'd really like to have in omapdrm too.

Considering how much headache TILER has given, I'm not exactly looking
forward to it ;).

If we get manual update and VRFB, I think we are more or less covered on
the supported HW features. It'll still break userspace apps which use
omapfb, though. Unless we also port the omapfb specific IOCTLs and the
sysfs files, which I believe we should not.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: noveau vs arm dma ops

[Daniel Vetter]

On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote:
> [discussion about this patch, which should have been cced to the iommu
>  and linux-arm-kernel lists, but wasn't:
>  https://www.spinics.net/lists/dri-devel/msg173630.html]
> 
> On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry Reding wrote:
> > > API from the iommu/dma-mapping code.  Drivers have no business poking
> > > into these details.
> > 
> > The interfaces that the above patch uses are all EXPORT_SYMBOL_GPL,
> > which is rather misleading if they are not meant to be used by drivers
> > directly.
> 
> The only reason the DMA ops are exported is because get_arch_dma_ops
> references (or in case of the coherent ones used to reference).  We
> don't let drivers assign random dma ops.
> 
> > 
> > > Thierry, please resend this with at least the iommu list and
> > > linux-arm-kernel in Cc to have a proper discussion on the right API.
> > 
> > I'm certainly open to help with finding a correct solution, but the
> > patch above was purposefully terse because this is something that I
> > hope we can get backported to v4.16 to unbreak Nouveau. Coordinating
> > such a backport between ARM and DRM trees does not sound like something
> > that would help getting this fixed in v4.16.
> 
> Coordinating the backport of a trivial helper in the arm tree is not
> the end of the world.  Really, this cowboy attitude is a good reason
> why graphics folks have such a bad rep.  You keep poking into random
> kernel internals, don't talk to anoyone and then complain if people
> are upset.  This shouldn't be surprising.

Not really agreeing on the cowboy thing. The fundamental problem is that
the dma api provides abstraction that seriously gets in the way of writing
a gpu driver. Some examples:

- We never want bounce buffers, ever. dma_map_sg gives us that, so there's
  hacks to fall back to a cache of pages allocated using
  dma_alloc_coherent if you build a kernel with bounce buffers.

- dma api hides the cache flushing requirements from us. GPUs love
  non-snooped access, and worse give userspace control over that. We want
  a strict separation between mapping stuff and flushing stuff. With the
  IOMMU api we mostly have the former, but for the later arch maintainers
  regularly tells they won't allow that. So we have drm_clflush.c.

- dma api hides how/where memory is allocated. Kinda similar problem,
  except now for CMA or address limits. So either we roll our own
  allocators and then dma_map_sg (and pray it doesn't bounce buffer), or
  we use dma_alloc_coherent and then grab the sgt to get at the CMA
  allocations because that's the only way. Which sucks, because we can't
  directly tell CMA how to back off if there's some way to make CMA memory
  available through other means (gpus love to hog all of memory, so we
  have shrinkers and everything).

For display drivers the dma api mostly works, until you start sharing
buffers with other devices.

So from our perspective it looks fairly often that core folks just don't
want to support gpu use-cases, so we play a bit more cowboy and get things
done some other way. Since this has been going on for years now we often
don't even bother to start a discussion first, since it tended to go
nowhere useful.
-Daniel

> > Granted, this issue could've been caught with a little more testing, but
> > in retrospect I think it would've been a lot better if ARM_DMA_USE_IOMMU
> > was just enabled unconditionally if it has side-effects that platforms
> > don't opt in to but have to explicitly opt out of.
> 
> Agreed on that count.  Please send a patch.

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
> On 25/04/18 12:03, Laurent Pinchart wrote:
> > Could we trim down omapfb to remove support for the devices supported by
> > omapdrm ?
> 
> I was thinking about just that. But, of course, it's not quite
> straightforward either.
> 
> We've got DSI manual update functionality in OMAP3-OMAP5 SoCs, which
> covers a lot of devices.

Sebastian is working on getting that feature in omapdrm, isn't he ?

> And VRFB on OMAP2/3.

And that's something I'd really like to have in omapdrm too.

> Those need omapfb.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 25/04/18 12:03, Laurent Pinchart wrote:

> Could we trim down omapfb to remove support for the devices supported by 
> omapdrm ?

I was thinking about just that. But, of course, it's not quite
straightforward either.

We've got DSI manual update functionality in OMAP3-OMAP5 SoCs, which
covers a lot of devices. And VRFB on OMAP2/3. Those need omapfb.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: noveau vs arm dma ops

[Russell King - ARM Linux]

On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote:
> [discussion about this patch, which should have been cced to the iommu
>  and linux-arm-kernel lists, but wasn't:
>  https://www.spinics.net/lists/dri-devel/msg173630.html]
> 
> On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry Reding wrote:
> > > API from the iommu/dma-mapping code.  Drivers have no business poking
> > > into these details.
> > 
> > The interfaces that the above patch uses are all EXPORT_SYMBOL_GPL,
> > which is rather misleading if they are not meant to be used by drivers
> > directly.

EXPORT_SYMBOL* means nothing as far as whether a driver should
be able to use the symbol or not - it merely means that the symbol is
made available to a module.  Modules cover much more than just device
drivers - we have library modules, filesystem modules, helper modules
to name a few non-driver classes of modules.

We also have symbols that are exported as part of the architecture
implementation detail of a public interface.  For example, the
public interface "copy_from_user" is implemented as an inline
function (actually several layers of inline functions) eventually
calling into arm_copy_from_user().  arm_copy_from_user() is exported,
but drivers (in fact no module) is allowed to make direct reference
to arm_copy_from_user() - it'd fail when software PAN is enabled.

The whole idea that "if a symbol is exported, it's fine for a driver
to use it" is a complete work of fiction, always has been, and always
will be.

We've had this with the architecture implementation details of the
DMA API before, and with the architecture implementation details of
the CPU cache flushing.  There's only so much commentry, or __
prefixes you can add to a symbol before things get rediculous, and
none of it stops people creating this abuse.  The only thing that
seems to prevent it is to make life hard for folk wanting to use
the symbols (eg, hiding the symbol prototype in a private header,
etc.)

Never, ever go under the covers of an interface.  If the interface
doesn't do what you want, _discuss_ it, don't just think "oh, that
architecture private facility looks like what I need, I'll use that
directly."

If you ever are on the side of trying to maintain those implementation
details that are abused in this way, you'll soon understand why this
behaviour by driver authors is soo annoying, and the maintainability
problems it creates.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick"

[Mauro Carvalho Chehab]

Em Wed, 25 Apr 2018 11:09:50 +0200
mjs  escreveu:

> From 0a3355b47dc465c6372d30fa4a36d1c5db6c0fe2 Mon Sep 17 00:00:00 2001
> From: Marcel Stork 
> Date: Wed, 25 Apr 2018 10:53:34 +0200
> Subject: [PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick".
> 
> Extra code to be able to use this stick, only digital, not analog nor 
> remote-control.
> 
> Changes to be committed:
>   modified:   em28xx-cards.c
>   modified:   em28xx-dvb.c
>   modified:   em28xx.h

You forgot to add your Signed-off-by. That's mandatory for patches to
be acepted.

> 
> ---
>  em28xx-cards.c | 30 +-
>  em28xx-dvb.c   |  1 +
>  em28xx.h   |  1 +
>  3 files changed, 31 insertions(+), 1 deletion(-)


use git diff against upstream tree. This should be using
a different paths there, e.g. drivers/media/usb/em28xx/...

> 
> diff --git a/em28xx-cards.c b/em28xx-cards.c
> index 6e0e67d..01b38a4 100644
> --- a/em28xx-cards.c
> +++ b/em28xx-cards.c
> @@ -87,6 +87,21 @@ static const struct em28xx_reg_seq default_digital[] = {
>   {   -1, -1, -1, -1},
>  };
>  
> +/* Board Zolid Hybrid Tv Stick */
> +static struct em28xx_reg_seq zolid_tuner[] = {
> + {EM2820_R08_GPIO_CTRL,  0xfd,   0xff,   100},
> + {EM2820_R08_GPIO_CTRL,  0xfe,   0xff,   100},
> + {   -1, -1, 
> -1,  -1},
> +};
> +
> +static struct em28xx_reg_seq zolid_digital[] = {
> + {EM2820_R08_GPIO_CTRL,  0x6a,   0xff,   100},
> + {EM2820_R08_GPIO_CTRL,  0x7a,   0xff,   100},
> + {EM2880_R04_GPO,0x04,   0xff,   100},
> + {EM2880_R04_GPO,0x0c,   0xff,   100},
> + {   -1, -1, 
> -1,  -1},
> +};
> +
>  /* Board Hauppauge WinTV HVR 900 analog */
>  static const struct em28xx_reg_seq hauppauge_wintv_hvr_900_analog[] = {
>   {EM2820_R08_GPIO_CTRL,  0x2d,   ~EM_GPIO_4, 10},
> @@ -679,6 +694,16 @@ const struct em28xx_board em28xx_boards[] = {
>   .amux = EM28XX_AMUX_VIDEO,
>   } },
>   },
> + [EM2882_BOARD_ZOLID_HYBRID_TV_STICK] = {
> + .name   = ":ZOLID HYBRID TV STICK",
> + .tuner_type = TUNER_XC2028,
> + .tuner_gpio = zolid_tuner,
> + .decoder= EM28XX_TVP5150,
> + .xclk   = EM28XX_XCLK_FREQUENCY_12MHZ,
> + .mts_firmware   = 1,
> + .has_dvb= 1,
> + .dvb_gpio   = zolid_digital,
> + },
>   [EM2820_BOARD_KWORLD_PVRTV2800RF] = {
>   .name = "Kworld PVR TV 2800 RF",
>   .tuner_type   = TUNER_TEMIC_PAL,
> @@ -2493,7 +2518,7 @@ struct usb_device_id em28xx_id_table[] = {
>   .driver_info = EM2820_BOARD_UNKNOWN },
>   { USB_DEVICE(0xeb1a, 0x2881),
>   .driver_info = EM2820_BOARD_UNKNOWN },
> - { USB_DEVICE(0xeb1a, 0x2883),
> + { USB_DEVICE(0xeb1a, 0x2883), /* used by zolid hybrid tv stick */
>   .driver_info = EM2820_BOARD_UNKNOWN },
>   { USB_DEVICE(0xeb1a, 0x2868),
>   .driver_info = EM2820_BOARD_UNKNOWN },
> @@ -2688,6 +2713,7 @@ static const struct em28xx_hash_table 
> em28xx_eeprom_hash[] = {
>   {0xb8846b20, EM2881_BOARD_PINNACLE_HYBRID_PRO, TUNER_XC2028},
>   {0x63f653bd, EM2870_BOARD_REDDO_DVB_C_USB_BOX, TUNER_ABSENT},
>   {0x4e913442, EM2882_BOARD_DIKOM_DK300, TUNER_XC2028},
> + {0x85dd871e, EM2882_BOARD_ZOLID_HYBRID_TV_STICK, TUNER_XC2028},
>  };
>  
>  /* I2C devicelist hash table for devices with generic USB IDs */
> @@ -2699,6 +2725,7 @@ static const struct em28xx_hash_table em28xx_i2c_hash[] 
> = {
>   {0xc51200e3, EM2820_BOARD_GADMEI_TVR200, TUNER_LG_PAL_NEW_TAPC},
>   {0x4ba50080, EM2861_BOARD_GADMEI_UTV330PLUS, TUNER_TNF_5335MF},
>   {0x6b800080, EM2874_BOARD_LEADERSHIP_ISDBT, TUNER_ABSENT},
> + {0x27e10080, EM2882_BOARD_ZOLID_HYBRID_TV_STICK, TUNER_XC2028},
>  };
>  
>  /* NOTE: introduce a separate hash table for devices with 16 bit eeproms */
> @@ -3187,6 +3214,7 @@ void em28xx_setup_xc3028(struct em28xx *dev, struct 
> xc2028_ctrl *ctl)
>   case EM2880_BOARD_TERRATEC_HYBRID_XS:
>   case EM2880_BOARD_TERRATEC_HYBRID_XS_FR:
>   case EM2881_BOARD_PINNACLE_HYBRID_PRO:
> + case EM2882_BOARD_ZOLID_HYBRID_TV_STICK:
>   ctl->demod = XC3028_FE_ZARLINK456;
>   break;
>   case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900_R2:
> diff --git a/em28xx-dvb.c b/em28xx-dvb.c
> index ebe62ff..640eafe 100644
> --- a/em28xx-dvb.c
> +++ b/em28xx-dvb.c
> @@ -1488,6 +1488,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
>   case 

Re: [PATCH 2/8] dmaengine: shdmac: Change platform check to CONFIG_ARCH_RENESAS

[Vinod Koul]

On Fri, Apr 20, 2018 at 03:28:28PM +0200, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
> 
> Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
> check, just like before support for Renesas ARM SoCs was added.
> 
> Instead of blindly changing all the #ifdefs, switch the main code block
> in sh_dmae_probe() to IS_ENABLED(), as this allows to remove all the
> remaining #ifdefs.
> 
> This will allow to drop ARCH_SHMOBILE on ARM in the near future.

Applied, thanks

-- 
~Vinod

Re: [PATCH v6 07/12] intel-ipu3: css: Add static settings for image pipeline

[Tomasz Figa]

Hi Yong,

On Fri, Mar 30, 2018 at 11:15 AM Yong Zhi  wrote:

> This adds coeff, config parameters etc const definitions for
> IPU3 programming.

> Signed-off-by: Yong Zhi 
> ---
>   drivers/media/pci/intel/ipu3/ipu3-tables.c | 9609

>   drivers/media/pci/intel/ipu3/ipu3-tables.h |   66 +
>   2 files changed, 9675 insertions(+)
>   create mode 100644 drivers/media/pci/intel/ipu3/ipu3-tables.c
>   create mode 100644 drivers/media/pci/intel/ipu3/ipu3-tables.h

I believe none of the 6 revisions of this patch actually reached the
mailing lists. It's too big. Could we do something about it? Splitting into
smaller patches might help, but we should provide a link in cover letter to
a public git branch where the whole series can be found applied to current
Linux.

Best regards,
Tomasz

[PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick"

[mjs]

From 0a3355b47dc465c6372d30fa4a36d1c5db6c0fe2 Mon Sep 17 00:00:00 2001
From: Marcel Stork 
Date: Wed, 25 Apr 2018 10:53:34 +0200
Subject: [PATCH] Add new dvb-t board ":Zolid Hybrid Tv Stick".

Extra code to be able to use this stick, only digital, not analog nor 
remote-control.

Changes to be committed:
modified:   em28xx-cards.c
modified:   em28xx-dvb.c
modified:   em28xx.h

---
 em28xx-cards.c | 30 +-
 em28xx-dvb.c   |  1 +
 em28xx.h   |  1 +
 3 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/em28xx-cards.c b/em28xx-cards.c
index 6e0e67d..01b38a4 100644
--- a/em28xx-cards.c
+++ b/em28xx-cards.c
@@ -87,6 +87,21 @@ static const struct em28xx_reg_seq default_digital[] = {
{   -1, -1, -1, -1},
 };
 
+/* Board Zolid Hybrid Tv Stick */
+static struct em28xx_reg_seq zolid_tuner[] = {
+   {EM2820_R08_GPIO_CTRL,  0xfd,   0xff,   100},
+   {EM2820_R08_GPIO_CTRL,  0xfe,   0xff,   100},
+   {   -1, -1, 
-1,  -1},
+};
+
+static struct em28xx_reg_seq zolid_digital[] = {
+   {EM2820_R08_GPIO_CTRL,  0x6a,   0xff,   100},
+   {EM2820_R08_GPIO_CTRL,  0x7a,   0xff,   100},
+   {EM2880_R04_GPO,0x04,   0xff,   100},
+   {EM2880_R04_GPO,0x0c,   0xff,   100},
+   {   -1, -1, 
-1,  -1},
+};
+
 /* Board Hauppauge WinTV HVR 900 analog */
 static const struct em28xx_reg_seq hauppauge_wintv_hvr_900_analog[] = {
{EM2820_R08_GPIO_CTRL,  0x2d,   ~EM_GPIO_4, 10},
@@ -679,6 +694,16 @@ const struct em28xx_board em28xx_boards[] = {
.amux = EM28XX_AMUX_VIDEO,
} },
},
+   [EM2882_BOARD_ZOLID_HYBRID_TV_STICK] = {
+   .name   = ":ZOLID HYBRID TV STICK",
+   .tuner_type = TUNER_XC2028,
+   .tuner_gpio = zolid_tuner,
+   .decoder= EM28XX_TVP5150,
+   .xclk   = EM28XX_XCLK_FREQUENCY_12MHZ,
+   .mts_firmware   = 1,
+   .has_dvb= 1,
+   .dvb_gpio   = zolid_digital,
+   },
[EM2820_BOARD_KWORLD_PVRTV2800RF] = {
.name = "Kworld PVR TV 2800 RF",
.tuner_type   = TUNER_TEMIC_PAL,
@@ -2493,7 +2518,7 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2820_BOARD_UNKNOWN },
{ USB_DEVICE(0xeb1a, 0x2881),
.driver_info = EM2820_BOARD_UNKNOWN },
-   { USB_DEVICE(0xeb1a, 0x2883),
+   { USB_DEVICE(0xeb1a, 0x2883), /* used by zolid hybrid tv stick */
.driver_info = EM2820_BOARD_UNKNOWN },
{ USB_DEVICE(0xeb1a, 0x2868),
.driver_info = EM2820_BOARD_UNKNOWN },
@@ -2688,6 +2713,7 @@ static const struct em28xx_hash_table 
em28xx_eeprom_hash[] = {
{0xb8846b20, EM2881_BOARD_PINNACLE_HYBRID_PRO, TUNER_XC2028},
{0x63f653bd, EM2870_BOARD_REDDO_DVB_C_USB_BOX, TUNER_ABSENT},
{0x4e913442, EM2882_BOARD_DIKOM_DK300, TUNER_XC2028},
+   {0x85dd871e, EM2882_BOARD_ZOLID_HYBRID_TV_STICK, TUNER_XC2028},
 };
 
 /* I2C devicelist hash table for devices with generic USB IDs */
@@ -2699,6 +2725,7 @@ static const struct em28xx_hash_table em28xx_i2c_hash[] = 
{
{0xc51200e3, EM2820_BOARD_GADMEI_TVR200, TUNER_LG_PAL_NEW_TAPC},
{0x4ba50080, EM2861_BOARD_GADMEI_UTV330PLUS, TUNER_TNF_5335MF},
{0x6b800080, EM2874_BOARD_LEADERSHIP_ISDBT, TUNER_ABSENT},
+   {0x27e10080, EM2882_BOARD_ZOLID_HYBRID_TV_STICK, TUNER_XC2028},
 };
 
 /* NOTE: introduce a separate hash table for devices with 16 bit eeproms */
@@ -3187,6 +3214,7 @@ void em28xx_setup_xc3028(struct em28xx *dev, struct 
xc2028_ctrl *ctl)
case EM2880_BOARD_TERRATEC_HYBRID_XS:
case EM2880_BOARD_TERRATEC_HYBRID_XS_FR:
case EM2881_BOARD_PINNACLE_HYBRID_PRO:
+   case EM2882_BOARD_ZOLID_HYBRID_TV_STICK:
ctl->demod = XC3028_FE_ZARLINK456;
break;
case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900_R2:
diff --git a/em28xx-dvb.c b/em28xx-dvb.c
index ebe62ff..640eafe 100644
--- a/em28xx-dvb.c
+++ b/em28xx-dvb.c
@@ -1488,6 +1488,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900:
case EM2882_BOARD_TERRATEC_HYBRID_XS:
case EM2880_BOARD_EMPIRE_DUAL_TV:
+   case EM2882_BOARD_ZOLID_HYBRID_TV_STICK:
dvb->fe[0] = dvb_attach(zl10353_attach,
_zl10353_xc3028_no_i2c_gate,
>i2c_adap[dev->def_i2c_bus]);
diff 

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 25 April 2018 09:24:14 EEST Tomi Valkeinen wrote:
> On 23/04/18 23:09, Mauro Carvalho Chehab wrote:
> >> I don't think it's worth it renaming the common symbols. They will change
> >> over time as omapdrm is under heavy rework, and it's painful enough
> >> without having to handle cross-tree changes.
> > 
> > It could just rename the namespace-conflicting FB_OMAP2 functions,
> > keeping the DRM ones as-is.
> 
> Yes, I'm fine with renaming omapfb functions if that helps. But still,
> if omapdrm is enabled in the kernel as module or built-in, omapfb will
> not work. So even if we get them to compile and link, it'll break at
> runtime one way or another.
> 
> >> Let's just live with the fact that both drivers
> >> can't be compiled at the same time, given that omapfb is deprecated.
> > 
> > IMO, a driver that it is deprecated, being in a state where it
> > conflicts with a non-deprecated driver that is under heavy rework
> > is a very good candidate to go to drivers/staging or even to /dev/null.
> 
> The problem is that it supports old devices which are not supported by
> omapdrm. But both omapfb and omapdrm support many of the same devices.

Could we trim down omapfb to remove support for the devices supported by 
omapdrm ?

-- 
Regards,

Laurent Pinchart

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Wed, Apr 25, 2018 at 09:56:43AM +0200, Thierry Reding wrote:
> And to add to the confusion, none of this seems to be an issue on 64-bit
> ARM where the generic DMA/IOMMU code from drivers/iommu/dma-iommu.c is
> used.

In the long term I want everyone to use that code.  Help welcome!

noveau vs arm dma ops

[Christoph Hellwig]

[discussion about this patch, which should have been cced to the iommu
 and linux-arm-kernel lists, but wasn't:
 https://www.spinics.net/lists/dri-devel/msg173630.html]

On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry Reding wrote:
> > API from the iommu/dma-mapping code.  Drivers have no business poking
> > into these details.
> 
> The interfaces that the above patch uses are all EXPORT_SYMBOL_GPL,
> which is rather misleading if they are not meant to be used by drivers
> directly.

The only reason the DMA ops are exported is because get_arch_dma_ops
references (or in case of the coherent ones used to reference).  We
don't let drivers assign random dma ops.

> 
> > Thierry, please resend this with at least the iommu list and
> > linux-arm-kernel in Cc to have a proper discussion on the right API.
> 
> I'm certainly open to help with finding a correct solution, but the
> patch above was purposefully terse because this is something that I
> hope we can get backported to v4.16 to unbreak Nouveau. Coordinating
> such a backport between ARM and DRM trees does not sound like something
> that would help getting this fixed in v4.16.

Coordinating the backport of a trivial helper in the arm tree is not
the end of the world.  Really, this cowboy attitude is a good reason
why graphics folks have such a bad rep.  You keep poking into random
kernel internals, don't talk to anoyone and then complain if people
are upset.  This shouldn't be surprising.

> Granted, this issue could've been caught with a little more testing, but
> in retrospect I think it would've been a lot better if ARM_DMA_USE_IOMMU
> was just enabled unconditionally if it has side-effects that platforms
> don't opt in to but have to explicitly opt out of.

Agreed on that count.  Please send a patch.

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Thierry Reding]

On Wed, Apr 25, 2018 at 09:30:39AM +0200, Daniel Vetter wrote:
> On Wed, Apr 25, 2018 at 12:09:05AM -0700, Christoph Hellwig wrote:
> > On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote:
> > > Can we please not nack everything right away? Doesn't really motivate
> > > me to show you all the various things we're doing in gpu to make the
> > > dma layer work for us. That kind of noodling around in lower levels to
> > > get them to do what we want is absolutely par-for-course for gpu
> > > drivers. If you just nack everything I point you at for illustrative
> > > purposes, then I can't show you stuff anymore.
> > 
> > No, it's not.  No driver (and that includes the magic GPUs) has
> > any business messing with dma ops directly.
> > 
> > A GPU driver imght have a very valid reason to disable the IOMMU,
> > but the code to do so needs to be at least in the arch code, maybe
> > in the dma-mapping/iommu code, not in the driver.
> > 
> > As a first step to get the discussion started we'll simply need
> > to move the code Thierry wrote into a helper in arch/arm and that
> > alone would be a massive improvement.  I'm not even talking about
> > minor details like actually using arm_get_dma_map_ops instead
> > of duplicating it.
> > 
> > And doing this basic trivial work really helps to get this whole
> > mess under control.
> 
> Ah ok. It did sound a bit like a much more cathegorical NAK than an "ack
> in principle, but we need to shuffle the implementation into the right
> place first". In the past we generally got a principled NAK on anything
> funny we've been doing with the dma api, and the dma api maintainer
> steaming off telling us we're incompetent idiots. I guess I've been
> branded a bit on this topic :-/
> 
> Really great that this is changing now.
> 
> On the patch itself: It might not be the right thing in all cases, since
> for certain compression formats the nv gpu wants larger pages (easy to
> allocate from vram, not so easy from main memory), so might need the iommu
> still. But currently that's not implemented:
> 
> https://www.spinics.net/lists/dri-devel/msg173932.html

To clarify: we do want to use the IOMMU, but we want to use it
explicitly via the IOMMU API rather than hiding it behind the DMA API.
We do the same thing in Tegra DRM where we don't want to use the DMA API
because it doesn't allow us to share the same mapping between multiple
display controllers in the same way the IOMMU API does. We've also been
thinking about using the IOMMU API directly in order to support process
isolation for devices that accept command streams from userspace.

Fortunately the issue I'm seeing with Nouveau doesn't happen with Tegra
DRM, which seems to be because we have an IOMMU group with multiple
devices and that prevents the DMA API from "hijacking" the IOMMU domain
for the group.

And to add to the confusion, none of this seems to be an issue on 64-bit
ARM where the generic DMA/IOMMU code from drivers/iommu/dma-iommu.c is
used.

Thierry


signature.asc
Description: PGP signature

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Thierry Reding]

On Wed, Apr 25, 2018 at 12:09:05AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote:
> > Can we please not nack everything right away? Doesn't really motivate
> > me to show you all the various things we're doing in gpu to make the
> > dma layer work for us. That kind of noodling around in lower levels to
> > get them to do what we want is absolutely par-for-course for gpu
> > drivers. If you just nack everything I point you at for illustrative
> > purposes, then I can't show you stuff anymore.
> 
> No, it's not.  No driver (and that includes the magic GPUs) has
> any business messing with dma ops directly.
> 
> A GPU driver imght have a very valid reason to disable the IOMMU,
> but the code to do so needs to be at least in the arch code, maybe
> in the dma-mapping/iommu code, not in the driver.
> 
> As a first step to get the discussion started we'll simply need
> to move the code Thierry wrote into a helper in arch/arm and that
> alone would be a massive improvement.  I'm not even talking about
> minor details like actually using arm_get_dma_map_ops instead
> of duplicating it.
> 
> And doing this basic trivial work really helps to get this whole
> mess under control.

That's a good idea and I can prepare patches for this, but I'd like to
make those changes on top of the fix to keep the option of getting this
into v4.16 if at all possible.

Thierry


signature.asc
Description: PGP signature

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Thierry Reding]

On Tue, Apr 24, 2018 at 11:43:35PM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 08:23:15AM +0200, Daniel Vetter wrote:
> > For more fun:
> > 
> > https://www.spinics.net/lists/dri-devel/msg173630.html
> > 
> > Yeah, sometimes we want to disable the iommu because the on-gpu
> > pagetables are faster ...
> 
> I am not on this list, but remote NAK from here.  This needs an
> API from the iommu/dma-mapping code.  Drivers have no business poking
> into these details.

The interfaces that the above patch uses are all EXPORT_SYMBOL_GPL,
which is rather misleading if they are not meant to be used by drivers
directly.

> Thierry, please resend this with at least the iommu list and
> linux-arm-kernel in Cc to have a proper discussion on the right API.

I'm certainly open to help with finding a correct solution, but the
patch above was purposefully terse because this is something that I
hope we can get backported to v4.16 to unbreak Nouveau. Coordinating
such a backport between ARM and DRM trees does not sound like something
that would help getting this fixed in v4.16.

The fundamental issue here is that the DMA/IOMMU integration is
something that has caused a number of surprising regressions in the past
because it tends to sneak in unexpectedly. For example the current
regression shows up only if CONFIG_ARM_DMA_USE_IOMMU=y because the DMA
API will then transparently create a second mapping and mess things up.
Everything works fine if that option is disabled. This is ultimately why
we didn't notice, since we don't enable that option by default. I do
have a patch that I plan to apply to the Tegra tree that will always
enable CONFIG_ARM_DMA_USE_IOMMU=y on Tegra to avoid any such surprises
in the future, but I can obviously only apply that once the above patch
is applied to Nouveau, otherwise we'll break Nouveau unconditionally.

Granted, this issue could've been caught with a little more testing, but
in retrospect I think it would've been a lot better if ARM_DMA_USE_IOMMU
was just enabled unconditionally if it has side-effects that platforms
don't opt in to but have to explicitly opt out of.

Thierry


signature.asc
Description: PGP signature

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Daniel Vetter]

On Wed, Apr 25, 2018 at 12:09:05AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote:
> > Can we please not nack everything right away? Doesn't really motivate
> > me to show you all the various things we're doing in gpu to make the
> > dma layer work for us. That kind of noodling around in lower levels to
> > get them to do what we want is absolutely par-for-course for gpu
> > drivers. If you just nack everything I point you at for illustrative
> > purposes, then I can't show you stuff anymore.
> 
> No, it's not.  No driver (and that includes the magic GPUs) has
> any business messing with dma ops directly.
> 
> A GPU driver imght have a very valid reason to disable the IOMMU,
> but the code to do so needs to be at least in the arch code, maybe
> in the dma-mapping/iommu code, not in the driver.
> 
> As a first step to get the discussion started we'll simply need
> to move the code Thierry wrote into a helper in arch/arm and that
> alone would be a massive improvement.  I'm not even talking about
> minor details like actually using arm_get_dma_map_ops instead
> of duplicating it.
> 
> And doing this basic trivial work really helps to get this whole
> mess under control.

Ah ok. It did sound a bit like a much more cathegorical NAK than an "ack
in principle, but we need to shuffle the implementation into the right
place first". In the past we generally got a principled NAK on anything
funny we've been doing with the dma api, and the dma api maintainer
steaming off telling us we're incompetent idiots. I guess I've been
branded a bit on this topic :-/

Really great that this is changing now.

On the patch itself: It might not be the right thing in all cases, since
for certain compression formats the nv gpu wants larger pages (easy to
allocate from vram, not so easy from main memory), so might need the iommu
still. But currently that's not implemented:

https://www.spinics.net/lists/dri-devel/msg173932.html

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] rcar-vin: fix null pointer dereference in rvin_group_get()

[Geert Uytterhoeven]

On Wed, Apr 25, 2018 at 1:45 AM, Niklas Söderlund
 wrote:
> Store the group pointer before disassociating the VIN from the group.

s/get/put/ in one-line summary?

> Fixes: 3bb4c3bc85bf77a7 ("media: rcar-vin: add group allocator functions")
> Reported-by: Colin Ian King 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 7bc2774a11232362..d3072e166a1ca24f 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -338,19 +338,21 @@ static int rvin_group_get(struct rvin_dev *vin)
>
>  static void rvin_group_put(struct rvin_dev *vin)
>  {
> -   mutex_lock(>group->lock);
> +   struct rvin_group *group = vin->group;

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] media: zoran: move to dma-mapping interface

[Christoph Hellwig]

On Wed, Apr 25, 2018 at 09:08:13AM +0200, Arnd Bergmann wrote:
> > That probably also means it can use dma_mmap_coherent instead of the
> > handcrafted remap_pfn_range loop and the PageReserved abuse.
> 
> I'd rather not touch that code. How about adding a comment about
> the fact that it should use dma_mmap_coherent()?

Maybe the real question is if there is anyone that actually cares
for this driver, or if we are better off just removing it?

Same is true for various other virt_to_bus using drivers, e.g. the
grotty atm drivers.

Re: [PATCH v4 5/5] drm: adv7511: Add support for i2c_new_secondary_device

[Archit Taneja]

On Tuesday 13 February 2018 11:18 PM, Kieran Bingham wrote:

From: Kieran Bingham 

The ADV7511 has four 256-byte maps that can be accessed via the main I2C
ports. Each map has it own I2C address and acts as a standard slave
device on the I2C bus.

Allow a device tree node to override the default addresses so that
address conflicts with other devices on the same bus may be resolved at
the board description level.


Queued to drm-misc-next



Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
---
v2:
  - Update missing edid-i2c address setting
  - Split out DT bindings
  - Rename and move the I2C default addresses to their own section

v3:
  - No change

v4:
  - Change registration order of packet/cec to fix error path and
simplify code change.
  - Collect Laurent's RB tag

  drivers/gpu/drm/bridge/adv7511/adv7511.h |  6 
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 42 ++--
  2 files changed, 33 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index d034b2cb5eee..73d8ccb97742 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -93,6 +93,11 @@
  #define ADV7511_REG_CHIP_ID_HIGH  0xf5
  #define ADV7511_REG_CHIP_ID_LOW   0xf6
  
+/* Hardware defined default addresses for I2C register maps */

+#define ADV7511_CEC_I2C_ADDR_DEFAULT   0x3c
+#define ADV7511_EDID_I2C_ADDR_DEFAULT  0x3f
+#define ADV7511_PACKET_I2C_ADDR_DEFAULT0x38
+
  #define ADV7511_CSC_ENABLEBIT(7)
  #define ADV7511_CSC_UPDATE_MODE   BIT(5)
  
@@ -321,6 +326,7 @@ enum adv7511_type {

  struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
+   struct i2c_client *i2c_packet;
struct i2c_client *i2c_cec;
  
  	struct regmap *regmap;

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index efa29db5fc2b..802bc433f54a 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -586,7 +586,7 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
/* Reading the EDID only works if the device is powered */
if (!adv7511->powered) {
unsigned int edid_i2c_addr =
-   (adv7511->i2c_main->addr << 1) + 4;
+   (adv7511->i2c_edid->addr << 1);
  
  		__adv7511_power_on(adv7511);
  
@@ -969,10 +969,10 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)

  {
int ret;
  
-	adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,

-adv->i2c_main->addr - 1);
+   adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
+   ADV7511_CEC_I2C_ADDR_DEFAULT);
if (!adv->i2c_cec)
-   return -ENOMEM;
+   return -EINVAL;
i2c_set_clientdata(adv->i2c_cec, adv);
  
  	adv->regmap_cec = devm_regmap_init_i2c(adv->i2c_cec,

@@ -1082,8 +1082,6 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
struct adv7511_link_config link_config;
struct adv7511 *adv7511;
struct device *dev = >dev;
-   unsigned int main_i2c_addr = i2c->addr << 1;
-   unsigned int edid_i2c_addr = main_i2c_addr + 4;
unsigned int val;
int ret;
  
@@ -1153,23 +1151,34 @@ static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id *id)

if (ret)
goto uninit_regulators;
  
-	regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);

-   regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
-main_i2c_addr - 0xa);
-   regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
-main_i2c_addr - 2);
-
adv7511_packet_disable(adv7511, 0x);
  
-	adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);

+   adv7511->i2c_edid = i2c_new_secondary_device(i2c, "edid",
+   ADV7511_EDID_I2C_ADDR_DEFAULT);
if (!adv7511->i2c_edid) {
-   ret = -ENOMEM;
+   ret = -EINVAL;
goto uninit_regulators;
}
  
+	regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,

+adv7511->i2c_edid->addr << 1);
+
+   adv7511->i2c_packet = i2c_new_secondary_device(i2c, "packet",
+   ADV7511_PACKET_I2C_ADDR_DEFAULT);
+   if (!adv7511->i2c_packet) {
+   ret = -EINVAL;
+   goto err_i2c_unregister_edid;
+   }
+
+   regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
+   

Re: [PATCH v4 2/5] dt-bindings: adv7511: Extend bindings to allow specifying slave map addresses

[Archit Taneja]

On Tuesday 13 February 2018 11:18 PM, Kieran Bingham wrote:

From: Kieran Bingham 

The ADV7511 has four 256-byte maps that can be accessed via the main I2C
ports. Each map has it own I2C address and acts as a standard slave
device on the I2C bus.

Extend the device tree node bindings to be able to override the default
addresses so that address conflicts with other devices on the same bus
may be resolved at the board description level.



Queued to drm-misc-next


Signed-off-by: Kieran Bingham 
Reviewed-by: Rob Herring 
Reviewed-by: Laurent Pinchart 
---
v2:
  - Fixed up reg: property description to account for multiple optional
addresses.
  - Minor reword to commit message to account for DT only change
  - Collected Robs RB tag

v3:
  - Split map register addresses into individual declarations.

v4:
  - Update commit title
  - Collect Laurent's RB tag
  - Fix nitpickings
  - Normalise I2C usage (I²C is harder to grep for)

  .../devicetree/bindings/display/bridge/adi,adv7511.txt | 18 --
  1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 0047b1394c70..2c887536258c 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -14,7 +14,13 @@ Required properties:
"adi,adv7513"
"adi,adv7533"
  
-- reg: I2C slave address

+- reg: I2C slave addresses
+  The ADV7511 internal registers are split into four pages exposed through
+  different I2C addresses, creating four register maps. Each map has it own
+  I2C address and acts as a standard slave device on the I2C bus. The main
+  address is mandatory, others are optional and revert to defaults if not
+  specified.
+
  
  The ADV7511 supports a large number of input data formats that differ by their

  color depth, color format, clock mode, bit justification and random
@@ -70,6 +76,9 @@ Optional properties:
rather than generate its own timings for HDMI output.
  - clocks: from common clock binding: reference to the CEC clock.
  - clock-names: from common clock binding: must be "cec".
+- reg-names : Names of maps with programmable addresses.
+   It can contain any map needing a non-default address.
+   Possible maps names are : "main", "edid", "cec", "packet"
  
  Required nodes:
  
@@ -88,7 +97,12 @@ Example
  
  	adv7511w: hdmi@39 {

compatible = "adi,adv7511w";
-   reg = <39>;
+   /*
+* The EDID page will be accessible on address 0x66 on the I2C
+* bus. All other maps continue to use their default addresses.
+*/
+   reg = <0x39>, <0x66>;
+   reg-names = "main", "edid";
interrupt-parent = <>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <_clock>;

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote:
> Can we please not nack everything right away? Doesn't really motivate
> me to show you all the various things we're doing in gpu to make the
> dma layer work for us. That kind of noodling around in lower levels to
> get them to do what we want is absolutely par-for-course for gpu
> drivers. If you just nack everything I point you at for illustrative
> purposes, then I can't show you stuff anymore.

No, it's not.  No driver (and that includes the magic GPUs) has
any business messing with dma ops directly.

A GPU driver imght have a very valid reason to disable the IOMMU,
but the code to do so needs to be at least in the arch code, maybe
in the dma-mapping/iommu code, not in the driver.

As a first step to get the discussion started we'll simply need
to move the code Thierry wrote into a helper in arch/arm and that
alone would be a massive improvement.  I'm not even talking about
minor details like actually using arm_get_dma_map_ops instead
of duplicating it.

And doing this basic trivial work really helps to get this whole
mess under control.

Re: [PATCH] media: zoran: move to dma-mapping interface

[Arnd Bergmann]

On Wed, Apr 25, 2018 at 8:15 AM, Christoph Hellwig  wrote:
> On Tue, Apr 24, 2018 at 10:40:45PM +0200, Arnd Bergmann wrote:
>> @@ -221,6 +222,7 @@ struct zoran_fh {
>>
>>   struct zoran_overlay_settings overlay_settings;
>>   u32 *overlay_mask;  /* overlay mask */
>> + dma_addr_t overlay_mask_dma;
>>   enum zoran_lock_activity overlay_active;/* feature currently in use? */
>>
>>   struct zoran_buffer_col buffers;/* buffers' info */
>> @@ -307,6 +309,7 @@ struct zoran {
>>
>>   struct zoran_overlay_settings overlay_settings;
>>   u32 *overlay_mask;  /* overlay mask */
>> + dma_addr_t overlay_mask_dma;
>>   enum zoran_lock_activity overlay_active;/* feature currently 
>> in use? */
>>
>>   wait_queue_head_t v4l_capq;
>> @@ -346,6 +349,7 @@ struct zoran {
>>
>>   /* zr36057's code buffer table */
>>   __le32 *stat_com;   /* stat_com[i] is indexed by 
>> dma_head/tail & BUZ_MASK_STAT_COM */
>> + dma_addr_t stat_com_dma;
>>
>>   /* (value & BUZ_MASK_FRAME) corresponds to index in pend[] queue */
>>   int jpg_pend[BUZ_MAX_FRAME];
>> diff --git a/drivers/media/pci/zoran/zoran_card.c 
>> b/drivers/media/pci/zoran/zoran_card.c
>> index a6b9ebd20263..dabd8bf77472 100644
>> --- a/drivers/media/pci/zoran/zoran_card.c
>> +++ b/drivers/media/pci/zoran/zoran_card.c
>> @@ -890,6 +890,7 @@ zoran_open_init_params (struct zoran *zr)
>>   /* User must explicitly set a window */
>>   zr->overlay_settings.is_set = 0;
>>   zr->overlay_mask = NULL;
>> + zr->overlay_mask_dma = 0;
>
> I don't think this zeroing is required, and given that 0 is a valid
> dma address on some platforms is also is rather confusing.:w

The driver does this everywhere, which I also noticed as unnecessary,
but it felt better to be consistent with the rest of the driver here than
to follow common practice.

There are some explicit 'if (zr->overlay_mask)' checks in the driver
that require overlay_mask to be initialized. I could set it to
DMA_ERROR_CODE, but you removed that ;-)

It's easy enough to remove the re-zeroing of the number though
if you still think that's better.

>>   mask_line_size = (BUZ_MAX_WIDTH + 31) / 32;
>> - reg = virt_to_bus(zr->overlay_mask);
>> + reg = zr->overlay_mask_dma;
>>   btwrite(reg, ZR36057_MMTR);
>> - reg = virt_to_bus(zr->overlay_mask + mask_line_size);
>> + reg = zr->overlay_mask_dma + mask_line_size;
>
> I think this would be easier to read if the reg assignments got
> removed, e.g.
>
> btwrite(zr->overlay_mask_dma, ZR36057_MMTR);
> btwrite(zr->overlay_mask_dma + mask_line_size, ZR36057_MMBR);
>
> Same in a few other places.

Right, good idea.

>> + virt_tab = (void *)get_zeroed_page(GFP_KERNEL);
>> + if (!mem || !virt_tab) {
>>   dprintk(1,
>>   KERN_ERR
>>   "%s: %s - get_zeroed_page (frag_tab) failed 
>> for buffer %d\n",
>>   ZR_DEVNAME(zr), __func__, i);
>> + kfree(mem);
>> + kfree(virt_tab);
>>   jpg_fbuffer_free(fh);
>>   return -ENOBUFS;
>>   }
>>   fh->buffers.buffer[i].jpg.frag_tab = (__le32 *)mem;
>> - fh->buffers.buffer[i].jpg.frag_tab_bus = virt_to_bus(mem);
>> + fh->buffers.buffer[i].jpg.frag_virt_tab = virt_tab;
>
> From a quick look it seems like frag_tab should be a dma_alloc_coherent
> allocation, or you would need a lot of cache sync operations.

Do you mean the table or the buffers it points to? In the code you
quote, we initialize the table with static data before mapping it,
so I would expect either interface to work fine here.

For the actual buffers, I tried to retain the current behavior and
regular kernel memory, in particular because I wasn't too sure
about changing the mmap() function without understanding what
it really does. ;-)

It looks like the buffers are never accessed from the kernel but
only from hardware and user space, so we don't care about whether
we get a mapping that is coherent between the kernel and hardware,
but we probably should ensure that the page table attributes are the
same in kernel and user space (at least powerpc gets a checkstop
for unmatched cacheability flags).

> That probably also means it can use dma_mmap_coherent instead of the
> handcrafted remap_pfn_range loop and the PageReserved abuse.

I'd rather not touch that code. How about adding a comment about
the fact that it should use dma_mmap_coherent()?

 Arnd

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Daniel Vetter]

On Wed, Apr 25, 2018 at 8:43 AM, Christoph Hellwig  wrote:
> On Wed, Apr 25, 2018 at 08:23:15AM +0200, Daniel Vetter wrote:
>> For more fun:
>>
>> https://www.spinics.net/lists/dri-devel/msg173630.html
>>
>> Yeah, sometimes we want to disable the iommu because the on-gpu
>> pagetables are faster ...
>
> I am not on this list, but remote NAK from here.  This needs an
> API from the iommu/dma-mapping code.  Drivers have no business poking
> into these details.

Can we please not nack everything right away? Doesn't really motivate
me to show you all the various things we're doing in gpu to make the
dma layer work for us. That kind of noodling around in lower levels to
get them to do what we want is absolutely par-for-course for gpu
drivers. If you just nack everything I point you at for illustrative
purposes, then I can't show you stuff anymore.

Just to make it clear: I do want to get this stuff sorted, and it's
awesome that someone from core finally takes a serious look at what
gpu folks have been doing for decades (instead of just telling us
we're incompetent and doing it all wrong and then steaming off), and
how to make this work without layering violations to no end. But
stopping the world until this is fixed isn't really a good option.

Thanks, Daniel

> Thierry, please resend this with at least the iommu list and
> linux-arm-kernel in Cc to have a proper discussion on the right API.



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Wed, Apr 25, 2018 at 08:23:15AM +0200, Daniel Vetter wrote:
> For more fun:
> 
> https://www.spinics.net/lists/dri-devel/msg173630.html
> 
> Yeah, sometimes we want to disable the iommu because the on-gpu
> pagetables are faster ...

I am not on this list, but remote NAK from here.  This needs an
API from the iommu/dma-mapping code.  Drivers have no business poking
into these details.

Thierry, please resend this with at least the iommu list and
linux-arm-kernel in Cc to have a proper discussion on the right API.

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote:
> > It has a non-coherent transaction mode (which the chipset can opt to
> > not implement and still flush), to make sure the AGP horror show
> > doesn't happen again and GPU folks are happy with PCIe. That's at
> > least my understanding from digging around in amd the last time we had
> > coherency issues between intel and amd gpus. GPUs have some bits
> > somewhere (in the pagetables, or in the buffer object description
> > table created by userspace) to control that stuff.
> 
> Right.  We have a bit in the GPU page table entries that determines
> whether we snoop the CPU's cache or not.

I can see how that works with the GPU on the same SOC or SOC set as the
CPU.  But how is that going to work for a GPU that is a plain old PCIe
card?  The cache snooping in that case is happening in the PCIe root
complex.

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Alex Deucher]

On Wed, Apr 25, 2018 at 2:13 AM, Daniel Vetter  wrote:
> On Wed, Apr 25, 2018 at 7:48 AM, Christoph Hellwig  wrote:
>> On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
>>> Out of curiosity, how much virtual flushing stuff is there still out
>>> there? At least in drm we've pretty much ignore this, and seem to be
>>> getting away without a huge uproar (at least from driver developers
>>> and users, core folks are less amused about that).
>>
>> As I've just been wading through the code, the following architectures
>> have non-coherent dma that flushes by virtual address for at least some
>> platforms:
>>
>>  - arm [1], arm64, hexagon, nds32, nios2, parisc, sh, xtensa, mips,
>>powerpc
>>
>> These have non-coherent dma ops that flush by physical address:
>>
>>  - arc, arm [1], c6x, m68k, microblaze, openrisc, sparc
>>
>> And these do not have non-coherent dma ops at all:
>>
>>  - alpha, h8300, riscv, unicore32, x86
>>
>> [1] arm ѕeems to do both virtually and physically based ops, further
>> audit needed.
>>
>> Note that using virtual addresses in the cache flushing interface
>> doesn't mean that the cache actually is virtually indexed, but it at
>> least allows for the possibility.
>>
>>> > I think the most important thing about such a buffer object is that
>>> > it can distinguish the underlying mapping types.  While
>>> > dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT,
>>> > dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give
>>> > back a dma_addr_t they are in now way interchangable.  And trying to
>>> > stuff them all into a structure like struct scatterlist that has
>>> > no indication what kind of mapping you are dealing with is just
>>> > asking for trouble.
>>>
>>> Well the idea was to have 1 interface to allow all drivers to share
>>> buffers with anything else, no matter how exactly they're allocated.
>>
>> Isn't that interface supposed to be dmabuf?  Currently dma_map leaks
>> a scatterlist through the sg_table in dma_buf_map_attachment /
>> ->map_dma_buf, but looking at a few of the callers it seems like they
>> really do not even want a scatterlist to start with, but check that
>> is contains a physically contiguous range first.  So kicking the
>> scatterlist our there will probably improve the interface in general.
>
> I think by number most drm drivers require contiguous memory (or an
> iommu that makes it look contiguous). But there's plenty others who
> have another set of pagetables on the gpu itself and can
> scatter-gather. Usually it's the former for display/video blocks, and
> the latter for rendering.
>
>>> dma-buf has all the functions for flushing, so you can have coherent
>>> mappings, non-coherent mappings and pretty much anything else. Or well
>>> could, because in practice people hack up layering violations until it
>>> works for the 2-3 drivers they care about. On top of that there's the
>>> small issue that x86 insists that dma is coherent (and that's true for
>>> most devices, including v4l drivers you might want to share stuff
>>> with), and gpus really, really really do want to make almost
>>> everything incoherent.
>>
>> How do discrete GPUs manage to be incoherent when attached over PCIe?
>
> It has a non-coherent transaction mode (which the chipset can opt to
> not implement and still flush), to make sure the AGP horror show
> doesn't happen again and GPU folks are happy with PCIe. That's at
> least my understanding from digging around in amd the last time we had
> coherency issues between intel and amd gpus. GPUs have some bits
> somewhere (in the pagetables, or in the buffer object description
> table created by userspace) to control that stuff.

Right.  We have a bit in the GPU page table entries that determines
whether we snoop the CPU's cache or not.

Alex

>
> For anything on the SoC it's presented as pci device, but that's
> extremely fake, and we can definitely do non-snooped transactions on
> drm/i915. Again, controlled by a mix of pagetables and
> userspace-provided buffer object description tables.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 23/04/18 23:09, Mauro Carvalho Chehab wrote:

>> I don't think it's worth it renaming the common symbols. They will change 
>> over 
>> time as omapdrm is under heavy rework, and it's painful enough without 
>> having 
>> to handle cross-tree changes.
> 
> It could just rename the namespace-conflicting FB_OMAP2 functions,
> keeping the DRM ones as-is.

Yes, I'm fine with renaming omapfb functions if that helps. But still,
if omapdrm is enabled in the kernel as module or built-in, omapfb will
not work. So even if we get them to compile and link, it'll break at
runtime one way or another.

>> Let's just live with the fact that both drivers 
>> can't be compiled at the same time, given that omapfb is deprecated.
> 
> IMO, a driver that it is deprecated, being in a state where it
> conflicts with a non-deprecated driver that is under heavy rework
> is a very good candidate to go to drivers/staging or even to /dev/null.

The problem is that it supports old devices which are not supported by
omapdrm. But both omapfb and omapdrm support many of the same devices.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Daniel Vetter]

On Wed, Apr 25, 2018 at 8:13 AM, Daniel Vetter  wrote:
> On Wed, Apr 25, 2018 at 7:48 AM, Christoph Hellwig  wrote:
>> On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
>>> Out of curiosity, how much virtual flushing stuff is there still out
>>> there? At least in drm we've pretty much ignore this, and seem to be
>>> getting away without a huge uproar (at least from driver developers
>>> and users, core folks are less amused about that).
>>
>> As I've just been wading through the code, the following architectures
>> have non-coherent dma that flushes by virtual address for at least some
>> platforms:
>>
>>  - arm [1], arm64, hexagon, nds32, nios2, parisc, sh, xtensa, mips,
>>powerpc
>>
>> These have non-coherent dma ops that flush by physical address:
>>
>>  - arc, arm [1], c6x, m68k, microblaze, openrisc, sparc
>>
>> And these do not have non-coherent dma ops at all:
>>
>>  - alpha, h8300, riscv, unicore32, x86
>>
>> [1] arm ѕeems to do both virtually and physically based ops, further
>> audit needed.
>>
>> Note that using virtual addresses in the cache flushing interface
>> doesn't mean that the cache actually is virtually indexed, but it at
>> least allows for the possibility.
>>
>>> > I think the most important thing about such a buffer object is that
>>> > it can distinguish the underlying mapping types.  While
>>> > dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT,
>>> > dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give
>>> > back a dma_addr_t they are in now way interchangable.  And trying to
>>> > stuff them all into a structure like struct scatterlist that has
>>> > no indication what kind of mapping you are dealing with is just
>>> > asking for trouble.
>>>
>>> Well the idea was to have 1 interface to allow all drivers to share
>>> buffers with anything else, no matter how exactly they're allocated.
>>
>> Isn't that interface supposed to be dmabuf?  Currently dma_map leaks
>> a scatterlist through the sg_table in dma_buf_map_attachment /
>> ->map_dma_buf, but looking at a few of the callers it seems like they
>> really do not even want a scatterlist to start with, but check that
>> is contains a physically contiguous range first.  So kicking the
>> scatterlist our there will probably improve the interface in general.
>
> I think by number most drm drivers require contiguous memory (or an
> iommu that makes it look contiguous). But there's plenty others who
> have another set of pagetables on the gpu itself and can
> scatter-gather. Usually it's the former for display/video blocks, and
> the latter for rendering.

For more fun:

https://www.spinics.net/lists/dri-devel/msg173630.html

Yeah, sometimes we want to disable the iommu because the on-gpu
pagetables are faster ...
-Daniel

>>> dma-buf has all the functions for flushing, so you can have coherent
>>> mappings, non-coherent mappings and pretty much anything else. Or well
>>> could, because in practice people hack up layering violations until it
>>> works for the 2-3 drivers they care about. On top of that there's the
>>> small issue that x86 insists that dma is coherent (and that's true for
>>> most devices, including v4l drivers you might want to share stuff
>>> with), and gpus really, really really do want to make almost
>>> everything incoherent.
>>
>> How do discrete GPUs manage to be incoherent when attached over PCIe?
>
> It has a non-coherent transaction mode (which the chipset can opt to
> not implement and still flush), to make sure the AGP horror show
> doesn't happen again and GPU folks are happy with PCIe. That's at
> least my understanding from digging around in amd the last time we had
> coherency issues between intel and amd gpus. GPUs have some bits
> somewhere (in the pagetables, or in the buffer object description
> table created by userspace) to control that stuff.
>
> For anything on the SoC it's presented as pci device, but that's
> extremely fake, and we can definitely do non-snooped transactions on
> drm/i915. Again, controlled by a mix of pagetables and
> userspace-provided buffer object description tables.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH] media: zoran: move to dma-mapping interface

[Christoph Hellwig]

On Tue, Apr 24, 2018 at 10:40:45PM +0200, Arnd Bergmann wrote:
> No drivers should use virt_to_bus() any more. This converts
> one of the few remaining ones to the DMA mapping interface.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/media/pci/zoran/Kconfig|  2 +-
>  drivers/media/pci/zoran/zoran.h| 10 +--
>  drivers/media/pci/zoran/zoran_card.c   | 10 +--
>  drivers/media/pci/zoran/zoran_device.c | 16 +-
>  drivers/media/pci/zoran/zoran_driver.c | 54 
> +-
>  5 files changed, 63 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/media/pci/zoran/Kconfig b/drivers/media/pci/zoran/Kconfig
> index 39ec35bd21a5..26f40e124a32 100644
> --- a/drivers/media/pci/zoran/Kconfig
> +++ b/drivers/media/pci/zoran/Kconfig
> @@ -1,6 +1,6 @@
>  config VIDEO_ZORAN
>   tristate "Zoran ZR36057/36067 Video For Linux"
> - depends on PCI && I2C_ALGOBIT && VIDEO_V4L2 && VIRT_TO_BUS
> + depends on PCI && I2C_ALGOBIT && VIDEO_V4L2
>   depends on !ALPHA
>   help
> Say Y for support for MJPEG capture cards based on the Zoran
> diff --git a/drivers/media/pci/zoran/zoran.h b/drivers/media/pci/zoran/zoran.h
> index 9bb3c21aa275..9ff3a9acb60a 100644
> --- a/drivers/media/pci/zoran/zoran.h
> +++ b/drivers/media/pci/zoran/zoran.h
> @@ -183,13 +183,14 @@ struct zoran_buffer {
>   struct zoran_sync bs;   /* DONE: info to return to application 
> */
>   union {
>   struct {
> - __le32 *frag_tab;   /* addresses of frag table */
> - u32 frag_tab_bus;   /* same value cached to save 
> time in ISR */
> + __le32 *frag_tab;   /* DMA addresses of frag table 
> */
> + void **frag_virt_tab;   /* virtual addresses of frag 
> table */
> + dma_addr_t frag_tab_dma;/* same value cached to save 
> time in ISR */
>   } jpg;
>   struct {
>   char *fbuffer;  /* virtual address of frame 
> buffer */
>   unsigned long fbuffer_phys;/* physical address of frame 
> buffer */
> - unsigned long fbuffer_bus;/* bus address of frame 
> buffer */
> + dma_addr_t fbuffer_dma;/* bus address of frame buffer */
>   } v4l;
>   };
>  };
> @@ -221,6 +222,7 @@ struct zoran_fh {
>  
>   struct zoran_overlay_settings overlay_settings;
>   u32 *overlay_mask;  /* overlay mask */
> + dma_addr_t overlay_mask_dma;
>   enum zoran_lock_activity overlay_active;/* feature currently in use? */
>  
>   struct zoran_buffer_col buffers;/* buffers' info */
> @@ -307,6 +309,7 @@ struct zoran {
>  
>   struct zoran_overlay_settings overlay_settings;
>   u32 *overlay_mask;  /* overlay mask */
> + dma_addr_t overlay_mask_dma;
>   enum zoran_lock_activity overlay_active;/* feature currently in 
> use? */
>  
>   wait_queue_head_t v4l_capq;
> @@ -346,6 +349,7 @@ struct zoran {
>  
>   /* zr36057's code buffer table */
>   __le32 *stat_com;   /* stat_com[i] is indexed by 
> dma_head/tail & BUZ_MASK_STAT_COM */
> + dma_addr_t stat_com_dma;
>  
>   /* (value & BUZ_MASK_FRAME) corresponds to index in pend[] queue */
>   int jpg_pend[BUZ_MAX_FRAME];
> diff --git a/drivers/media/pci/zoran/zoran_card.c 
> b/drivers/media/pci/zoran/zoran_card.c
> index a6b9ebd20263..dabd8bf77472 100644
> --- a/drivers/media/pci/zoran/zoran_card.c
> +++ b/drivers/media/pci/zoran/zoran_card.c
> @@ -890,6 +890,7 @@ zoran_open_init_params (struct zoran *zr)
>   /* User must explicitly set a window */
>   zr->overlay_settings.is_set = 0;
>   zr->overlay_mask = NULL;
> + zr->overlay_mask_dma = 0;

I don't think this zeroing is required, and given that 0 is a valid
dma address on some platforms is also is rather confusing.:w

>  
>   mask_line_size = (BUZ_MAX_WIDTH + 31) / 32;
> - reg = virt_to_bus(zr->overlay_mask);
> + reg = zr->overlay_mask_dma;
>   btwrite(reg, ZR36057_MMTR);
> - reg = virt_to_bus(zr->overlay_mask + mask_line_size);
> + reg = zr->overlay_mask_dma + mask_line_size;

I think this would be easier to read if the reg assignments got
removed, e.g.

btwrite(zr->overlay_mask_dma, ZR36057_MMTR);
btwrite(zr->overlay_mask_dma + mask_line_size, ZR36057_MMBR);

Same in a few other places.

> + virt_tab = (void *)get_zeroed_page(GFP_KERNEL);
> + if (!mem || !virt_tab) {
>   dprintk(1,
>   KERN_ERR
>   "%s: %s - get_zeroed_page (frag_tab) failed for 
> buffer %d\n",
>   ZR_DEVNAME(zr), __func__, i);
> + kfree(mem);
> + kfree(virt_tab);
>   

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Daniel Vetter]

On Wed, Apr 25, 2018 at 7:48 AM, Christoph Hellwig  wrote:
> On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
>> Out of curiosity, how much virtual flushing stuff is there still out
>> there? At least in drm we've pretty much ignore this, and seem to be
>> getting away without a huge uproar (at least from driver developers
>> and users, core folks are less amused about that).
>
> As I've just been wading through the code, the following architectures
> have non-coherent dma that flushes by virtual address for at least some
> platforms:
>
>  - arm [1], arm64, hexagon, nds32, nios2, parisc, sh, xtensa, mips,
>powerpc
>
> These have non-coherent dma ops that flush by physical address:
>
>  - arc, arm [1], c6x, m68k, microblaze, openrisc, sparc
>
> And these do not have non-coherent dma ops at all:
>
>  - alpha, h8300, riscv, unicore32, x86
>
> [1] arm ѕeems to do both virtually and physically based ops, further
> audit needed.
>
> Note that using virtual addresses in the cache flushing interface
> doesn't mean that the cache actually is virtually indexed, but it at
> least allows for the possibility.
>
>> > I think the most important thing about such a buffer object is that
>> > it can distinguish the underlying mapping types.  While
>> > dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT,
>> > dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give
>> > back a dma_addr_t they are in now way interchangable.  And trying to
>> > stuff them all into a structure like struct scatterlist that has
>> > no indication what kind of mapping you are dealing with is just
>> > asking for trouble.
>>
>> Well the idea was to have 1 interface to allow all drivers to share
>> buffers with anything else, no matter how exactly they're allocated.
>
> Isn't that interface supposed to be dmabuf?  Currently dma_map leaks
> a scatterlist through the sg_table in dma_buf_map_attachment /
> ->map_dma_buf, but looking at a few of the callers it seems like they
> really do not even want a scatterlist to start with, but check that
> is contains a physically contiguous range first.  So kicking the
> scatterlist our there will probably improve the interface in general.

I think by number most drm drivers require contiguous memory (or an
iommu that makes it look contiguous). But there's plenty others who
have another set of pagetables on the gpu itself and can
scatter-gather. Usually it's the former for display/video blocks, and
the latter for rendering.

>> dma-buf has all the functions for flushing, so you can have coherent
>> mappings, non-coherent mappings and pretty much anything else. Or well
>> could, because in practice people hack up layering violations until it
>> works for the 2-3 drivers they care about. On top of that there's the
>> small issue that x86 insists that dma is coherent (and that's true for
>> most devices, including v4l drivers you might want to share stuff
>> with), and gpus really, really really do want to make almost
>> everything incoherent.
>
> How do discrete GPUs manage to be incoherent when attached over PCIe?

It has a non-coherent transaction mode (which the chipset can opt to
not implement and still flush), to make sure the AGP horror show
doesn't happen again and GPU folks are happy with PCIe. That's at
least my understanding from digging around in amd the last time we had
coherency issues between intel and amd gpus. GPUs have some bits
somewhere (in the pagetables, or in the buffer object description
table created by userspace) to control that stuff.

For anything on the SoC it's presented as pci device, but that's
extremely fake, and we can definitely do non-snooped transactions on
drm/i915. Again, controlled by a mix of pagetables and
userspace-provided buffer object description tables.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Alex Deucher]

On Wed, Apr 25, 2018 at 1:48 AM, Christoph Hellwig  wrote:
> On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
>> Out of curiosity, how much virtual flushing stuff is there still out
>> there? At least in drm we've pretty much ignore this, and seem to be
>> getting away without a huge uproar (at least from driver developers
>> and users, core folks are less amused about that).
>
> As I've just been wading through the code, the following architectures
> have non-coherent dma that flushes by virtual address for at least some
> platforms:
>
>  - arm [1], arm64, hexagon, nds32, nios2, parisc, sh, xtensa, mips,
>powerpc
>
> These have non-coherent dma ops that flush by physical address:
>
>  - arc, arm [1], c6x, m68k, microblaze, openrisc, sparc
>
> And these do not have non-coherent dma ops at all:
>
>  - alpha, h8300, riscv, unicore32, x86
>
> [1] arm ѕeems to do both virtually and physically based ops, further
> audit needed.
>
> Note that using virtual addresses in the cache flushing interface
> doesn't mean that the cache actually is virtually indexed, but it at
> least allows for the possibility.
>
>> > I think the most important thing about such a buffer object is that
>> > it can distinguish the underlying mapping types.  While
>> > dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT,
>> > dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give
>> > back a dma_addr_t they are in now way interchangable.  And trying to
>> > stuff them all into a structure like struct scatterlist that has
>> > no indication what kind of mapping you are dealing with is just
>> > asking for trouble.
>>
>> Well the idea was to have 1 interface to allow all drivers to share
>> buffers with anything else, no matter how exactly they're allocated.
>
> Isn't that interface supposed to be dmabuf?  Currently dma_map leaks
> a scatterlist through the sg_table in dma_buf_map_attachment /
> ->map_dma_buf, but looking at a few of the callers it seems like they
> really do not even want a scatterlist to start with, but check that
> is contains a physically contiguous range first.  So kicking the
> scatterlist our there will probably improve the interface in general.
>
>> dma-buf has all the functions for flushing, so you can have coherent
>> mappings, non-coherent mappings and pretty much anything else. Or well
>> could, because in practice people hack up layering violations until it
>> works for the 2-3 drivers they care about. On top of that there's the
>> small issue that x86 insists that dma is coherent (and that's true for
>> most devices, including v4l drivers you might want to share stuff
>> with), and gpus really, really really do want to make almost
>> everything incoherent.
>
> How do discrete GPUs manage to be incoherent when attached over PCIe?

They can do CPU cache snooped (coherent) or non-snooped (incoherent)
DMA.  Also for things like APUs, they show up as a PCIe device, but
that actual GPU core is part of the same die as the CPU and they have
their own special paths to memory, etc.  The fact that they show up as
PCIe devices is mostly for enumeration purposes.

Alex

> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig