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: Sat Mar 18 05:00:18 CET 2017
media-tree git hash:700ea5e0e0dd70420a04e703ff264cc133834cba
media_build git
Dear Sir,
Did you recieved my mail?
I have sent it twice without a response.
Castano Giovanni
To: Sumit Semwal
To: Riley Andrews
Cc: rom...@google.com
To: a...@android.com
To: Riley Andrews
Cc: de...@driverdev.osuosl.org
Cc: linux-ker...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Greg Kroah-Hartman
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media@vger.kernel.org
Cc:
Once upon a time, phys_addr_t was not everywhere in the kernel. These
days it is used enough places that having a separate Ion type doesn't
make sense. Remove the extra type and just use phys_addr_t directly.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.h | 12 +
With the expansion of dma-buf and the move for Ion to be come just an
allocator, the import mechanism is mostly useless. There isn't a kernel
component to Ion anymore and handles are private to Ion. Remove this
interface.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_ion.c
It started with a sporadic message in syslog:
"CAM tried to send a buffer larger than the ecount size"
This message is not the fault itself, but a consecutive fault, after a read
error from the CAM. This happens only on several CAMs, several hardware, and
of course sporadic.
It is a consecutive fa
ion_handle was introduced as an abstraction to represent a reference to
a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
emerged as the preferred standard for use in the kernel. This has made
the ion_handle an unnecessary abstraction and prone to race
conditions. ion_cl
The current model of Ion heap registration is based on the outdated
model of board files. The replacement for board files (devicetree)
isn't a good replacement for what Ion wants to do. In actuality, Ion
wants to show what memory is available in the system for something else
to figure out what to
Device specific platform support has been haphazard for Ion. There have
been several independent attempts and there are still objections to
what bindings exist right now. Just remove everything for a fresh start.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Kconfig
Hi Andrew,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc2 next-20170310]
[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/Andrew-F-Davis/Remove-unneeded-build-director
ION_IOC_MAP is the same as ION_IOC_SHARE. We really don't need two
identical interfaces. Remove it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_ion.c | 1 -
drivers/staging/android/ion/ion-ioctl.c | 1 -
drivers/staging/android/uapi/ion.h | 10 --
3 files
Nobody uses this interface externally. Drop it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 59 ---
1 file changed, 59 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 7d40233..5a8
The reference counting of dma_map calls was removed. Remove the
associated counter field as well.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion_priv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion_priv.h
b/drivers/staging/android/ion/ion
Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
The align field was supposed to be used to specify the alignment of
the allocation. Nobody actually does anything with it except to check
if the alignment specified is out of bounds. Since this has no effect
on the actual allocation, just remove it.
Signed-off-by: Laura Abbott
---
drivers/stagi
Now that we have proper caching, stop setting the DMA address manually.
It should be set after properly calling dma_map.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/staging/androi
When CMA was first introduced, its primary use was for DMA allocation
and the only way to get CMA memory was to call dma_alloc_coherent. This
put Ion in an awkward position since there was no device structure
readily available and setting one up messed up the coherency model.
These days, CMA can b
Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
useful to have an explicit name attached to each region. Store the name
in each CMA structure.
Signed-off-by: Laura Abbott
---
drivers/base/dma-contiguous.c | 5 +++--
include/linux/cma.h | 4 +++-
mm/cma.c
Hi Andrew,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc2 next-20170310]
[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/Andrew-F-Davis/Remove-unneeded-build-director
Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.
Signed-off-by: Laura Abbott
---
drivers/staging/android/
Ion is now moving towards a unified interfact. This makes the custom
ioctl interface unneeded. Remove it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_ion.c | 40
drivers/staging/android/ion/ion-ioctl.c | 11 -
drivers/staging/andr
The new method of syncing with dma_map means that the page faulting sync
implementation is no longer applicable. Remove it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 117 --
1 file changed, 117 deletions(-)
diff --git a/drivers/stag
Ion current has ion_priv.h and ion.h as header files. ion.h was intended
to be used for public APIs but Ion never ended up really having anything
public. Combine the two headers so there is only one internal header.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion-ioctl.c
Now that we call dma_map in the dma_buf API callbacks there is no need
to use the existing cache APIs. Remove the sync ioctl and the existing
bad dma_sync calls. Explicit caching can be handled with the dma_buf
sync API.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_ion.c
Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.
Signed-off-by: Laura Abbott
---
include/linux/cma.h | 2 ++
mm/cma.c| 14 ++
2 files changed, 16 insertions(+)
diff --git a/include
This never got set in the ioctl. Properly set a return value of 0 on
success.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 64c652b..8bd90ce 10064
Hi,
This is v2 of the series to do some serious Ion clean up in preparation for
moving out of staging. I got good feedback last time so this series mostly
attempts to address that feedback and do more still more cleanup. Highlights:
- All calls to DMA APIs should now be with a real actual proper
Mauro Carvalho Chehab writes:
> Em Wed, 15 Mar 2017 18:46:24 -0700
> Michael Zoran escreveu:
>
>> On Wed, 2017-03-15 at 22:08 -0300, Mauro Carvalho Chehab wrote:
>>
>> > No, I didn't. Thanks! Applied it but, unfortunately, didn't work.
>> > Perhaps I'm missing some other patch. I'm compiling it
Add support for the image renderer light extended 3 (IMR-LX3) found only in
the R-Car V2H (R8A7792) SoC. It's mostly the same as IMR-LSX3 but doesn't
support video capture data as a source of 2D textures.
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'media_tree.git' repo's 'mast
The extra pairs of parentheses are not needed and cause clang
warnings like this:
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:158:32: error: equality
comparison with extraneous parentheses [-Werror,-Wparentheses-equality]
if ((inst->work_bufs[i].size == 0))
We call this function with the lock held and should also return with the
lock held as well. This one error path is not-consistent because we
should return without the lock held.
Signed-off-by: Dan Carpenter
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
b/drivers/staging/
There are some error paths in atomisp_css_frame_allocate() which don't
initialize "res" so it could lead us to try release random memory.
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Dan Carpenter
diff --git a/drivers/staging/media/atomisp/pci/atomisp2
On 03/17/2017 05:33 PM, Hans Verkuil wrote:
Add support for the image renderer light SRAM extended 3 (IMR-LSX3) found
only in the R-Car V2H (R8A7792) SoC. It differs from IMR-LX4 in that it
supports only planar video formats but can use the video capture data for
the textures.
Signed-off-by:
Replace the open coded registration of the cdev and dev with the
new device_add_cdev() helper. The helper replaces a common pattern by
taking the proper reference against the parent device and adding both
the cdev and the device.
In doing so we have to remove a guard statement from cdev_del,
but t
Replace the open coded registration of the cdev and dev with the
new device_add_cdev() helper. The helper replaces a common pattern by
taking the proper reference against the parent device and adding both
the cdev and the device.
Signed-off-by: Logan Gunthorpe
Acked-by: Hans Verkuil
---
drivers
Replace the open coded registration of the cdev and dev with the
new device_add_cdev() helper. The helper replaces a common pattern by
taking the proper reference against the parent device and adding both
the cdev and the device.
At the same time we cleanup the error path through device_probe
func
Replace the open coded registration of the cdev and dev with the
new device_add_cdev() helper. The helper replaces a common pattern by
taking the proper reference against the parent device and adding both
the cdev and the device.
Signed-off-by: Logan Gunthorpe
Reviewed-by: Linus Walleij
---
dri
This is not as straightforward a conversion as the others
in this series. These drivers did not originally make use of
kobj.parent so they likely suffered from a use after free bug if
someone unregistered the devices while they are being used.
In order to make the conversions, switch from device_r
This replaces the suspect looking cdev.kobj.parent lines with the
equivalent cdev_set_parent function. This is a straightforward change
that's largely cosmetic but it does push the kobj.parent ownership
into char_dev.c where it belongs.
Signed-off-by: Logan Gunthorpe
---
drivers/infiniband/core/
This driver did not originally set kobj.parent so it likely had
potential a use after free bug which this patch fixes.
We convert from device_register to device_initialize/cdev_device_add.
While we are at it we use put_device instead of kfree (as recommended
by the device_initialize documentation)
Replace the open coded registration of the cdev and dev with the
new device_add_cdev() helper. The helper replaces a common pattern by
taking the proper reference against the parent device and adding both
the cdev and the device.
Signed-off-by: Logan Gunthorpe
Reviewed-by: Jason Gunthorpe
Review
Replace the open coded registration of the cdev and dev with the
new device_add_cdev() helper. The helper replaces a common pattern by
taking the proper reference against the parent device and adding both
the cdev and the device.
Signed-off-by: Logan Gunthorpe
Reviewed-by: Dan Williams
Reviewed-
This driver did not set kobj.parent so it likely suffered from
a potential use after free race if the user unregistered the
device while it was in use.
This was not so straightforward a conversion but I think this patch
cleans up its probe's error path significantly.
This patch adds device_initia
Hey,
This version of the series fixes the issue found by the kbuild test
robot with the rtc driver. I managed to reproduce the issue and this
series fixes the problem.
Logan
Changes since v4:
* Fix a kbuild robot issue with the rtc driver: the rtc driver sometimes
does not want to add the cd
Mostly straightforward, but we had to remove the rtc_dev_add/del_device
functions as they split up the cdev_add and the device_add.
Doing this also revealed that there was likely another subtle bug:
seeing cdev_add was done after device_register, the cdev probably
was not ready before device_add w
Very straightforward conversion to device_add_cdev. Drop cdev_add and
device_add and use cdev_device_add.
Signed-off-by: Logan Gunthorpe
---
drivers/pci/switch/switchtec.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci
From: Dan Williams
If device_add() fails, cleanup the cdev. Otherwise, we leak a kobj_map()
with a stale device number.
As Jason points out, there is a small possibility that userspace has
opened and mapped the device in the time between cdev_add() and the
device_add() failure. We need a new kil
Replace the open coded registration of the cdev and dev with the
new device_add_cdev() helper in evdev, joydev and mousedev. The helper
replaces a common pattern by taking the proper reference against the
parent device and adding both the cdev and the device.
Signed-off-by: Logan Gunthorpe
Acked-
Credit for this patch goes is shared with Dan Williams [1]. I've
taken things one step further to make the helper function more
useful and clean up calling code.
There's a common pattern in the kernel whereby a struct cdev is placed
in a structure along side a struct device which manages the life-
From: Jason Gunthorpe
The use after free is not triggerable here because the cdev holds
the module lock and the only device_unregister is only triggered by
module unload, however make the change for consistency.
To make this work the cdev_del needs to move out of the struct device
release functi
On 03/10/2017 12:53 AM, Sumit Semwal wrote:
> Hi Laura,
>
> Thanks for the patch.
>
> On 3 March 2017 at 03:14, Laura Abbott wrote:
>>
>> Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
>> useful to have an explicit name attached to each region. Store the name
>> in each
Em Fri, 17 Mar 2017 12:16:08 +
Russell King - ARM Linux escreveu:
> On Fri, Mar 17, 2017 at 01:02:07PM +0100, Philipp Zabel wrote:
> > I think most of the simple, fixed pipeline use cases could be handled by
> > libv4l2, by allowing to pass a v4l2 subdevice path to v4l2_open. If that
> > func
Implement DVBv5 PER.
Signed-off-by: Antti Palosaari
---
drivers/media/dvb-frontends/mn88472.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/media/dvb-frontends/mn88472.c
b/drivers/media/dvb-frontends/mn88472.c
index c7e5f63..f6938f96 100644
--- a/drivers/me
Implement DVBv5 signal strength on relative scale.
Signed-off-by: Antti Palosaari
---
drivers/media/dvb-frontends/mn88472.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-frontends/mn88472.c
b/drivers/media/dvb-frontends/mn884
Implement DVBv5 CNR.
Signed-off-by: Antti Palosaari
---
drivers/media/dvb-frontends/mn88472.c | 90 +-
drivers/media/dvb-frontends/mn88472_priv.h | 1 +
2 files changed, 88 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/mn88472.c
b/driv
On 03/16/2017 06:01 PM, Archit Taneja wrote:
>
>
> On 3/7/2017 10:12 PM, Neil Armstrong wrote:
>> Add documentation for added Bus Formats to describe RGB and YUS formats used
>
> s/YUS/YUV
Thanks again
>
>> as input to the Synopsys DesignWare HDMI TX Controller.
>>
>> Signed-off-by: Neil
On 03/16/2017 06:06 PM, Archit Taneja wrote:
>
>
> On 3/7/2017 10:12 PM, Neil Armstrong wrote:
>> In order to describe the RGB and YUB bus formats used to feed the
>
> s/YUB/YUV
Thanks for pointing me this !
Neil
>
>> Synopsys DesignWare HDMI TX Controller, add missing formats to the
>> list
On Fri, Mar 17, 2017 at 02:51:10PM +0100, Philipp Zabel wrote:
> On Fri, 2017-03-17 at 10:24 -0300, Mauro Carvalho Chehab wrote:
> [...]
> > The big question, waiting for an answer on the last 8 years is
> > who would do that? Such person would need to have several different
> > hardware from diffe
On 03/16/17 19:59, Sergei Shtylyov wrote:
> Add support for the image renderer light SRAM extended 3 (IMR-LSX3) found
> only in the R-Car V2H (R8A7792) SoC. It differs from IMR-LX4 in that it
> supports only planar video formats but can use the video capture data for
> the textures.
>
> Signed-o
Hi Sergei,
Sorry for the long wait before I got around to reviewing this, but here
are (finally!) my review comments.
On 03/09/17 21:08, Sergei Shtylyov wrote:
> From: Konstantin Kozhevnikov
>
> The image renderer, or the distortion correction engine, is a drawing
> processor with a simple inst
On Fri, Mar 17, 2017 at 10:33:15AM +, Brian Starkey wrote:
> Hi Ville,
>
> On Thu, Mar 16, 2017 at 07:36:56PM +0200, Ville Syrjälä wrote:
> >On Thu, Mar 16, 2017 at 07:05:12PM +0200, Sharma, Shashank wrote:
> >> On 3/16/2017 5:55 PM, Brian Starkey wrote:
> >> > On Thu, Mar 16, 2017 at 05:14:07
Em Fri, 17 Mar 2017 13:55:33 +0200
Sakari Ailus escreveu:
> Hi Russell,
>
> On 03/17/17 13:42, Russell King - ARM Linux wrote:
> > On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
> >> We're all very driver-development-driven, and userspace gets very little
> >> attention in gener
On Fri, 2017-03-17 at 10:24 -0300, Mauro Carvalho Chehab wrote:
[...]
> The big question, waiting for an answer on the last 8 years is
> who would do that? Such person would need to have several different
> hardware from different vendors, in order to ensure that it has
> a generic solution.
>
> I
On Fri, Mar 17, 2017 at 01:02:07PM +0100, Philipp Zabel wrote:
> I think most of the simple, fixed pipeline use cases could be handled by
> libv4l2, by allowing to pass a v4l2 subdevice path to v4l2_open. If that
> function internally would set up the media links to the
> nearest /dev/video interfa
Hi Marian,
On 15.03.2017 12:36, Marian Mihailescu wrote:
> Hi,
>
> After testing these patches, encoding using MFC fails when requesting
> buffers for capture (it works for output) with ENOMEM (it complains it
> cannot allocate memory on bank1).
> Did anyone else test encoding?
I have tested enc
Hi Russell,
On 03/17/17 13:42, Russell King - ARM Linux wrote:
> On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
>> We're all very driver-development-driven, and userspace gets very little
>> attention in general. So before just throwing in the towel we should take
>> a good look at
On Fri, 2017-03-17 at 11:42 +, Russell King - ARM Linux wrote:
> On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
> > We're all very driver-development-driven, and userspace gets very little
> > attention in general. So before just throwing in the towel we should take
> > a good lo
On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
> We're all very driver-development-driven, and userspace gets very little
> attention in general. So before just throwing in the towel we should take
> a good look at the reasons why there has been little or no development: is
> it beca
On 02/22/2017 05:22 PM, Shuah Khan wrote:
On Mon, Feb 20, 2017 at 6:38 AM, Marek Szyprowski
wrote:
Internal MFC driver device structure contains two pointers to devices used
for DMA memory allocation: mem_dev_l and mem_dev_r. Replace them with the
mem_dev[] array and use defines for accessing p
The dwc2 hardware doesn't like to do DMA transfers without
aligning data in DWORD. The driver also assumes that, even
when there's no DMA, at dwc2_read_packet().
That cause buffer overflows, preventing some drivers to work.
In the specific case of uvc_driver, it uses an array where
it caches the
Hi Ville,
On Thu, Mar 16, 2017 at 07:36:56PM +0200, Ville Syrjälä wrote:
On Thu, Mar 16, 2017 at 07:05:12PM +0200, Sharma, Shashank wrote:
On 3/16/2017 5:55 PM, Brian Starkey wrote:
> On Thu, Mar 16, 2017 at 05:14:07PM +0200, Sharma Shashank wrote:
>> On 3/16/2017 4:37 PM, Local user for Liviu
On Thu, Mar 16, 2017 at 07:36:56PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 16, 2017 at 07:05:12PM +0200, Sharma, Shashank wrote:
> > Regards
> >
> > Shashank
> >
> >
> > On 3/16/2017 5:55 PM, Brian Starkey wrote:
> > > Hi,
> > >
> > > On Thu, Mar 16, 2017 at 05:14:07PM +0200, Sharma Shashank w
72 matches
Mail list logo
