There are several thermal sensors that only have a low-speed bus
interface but output valid video data. This patchset enables support
for the AMG88xx "Grid-Eye" sensor family.
Cc: Attila Kinali
Cc: Marek Vasut
Cc: Luca Barbato
Cc: Laurent Pinchart
Signed-off-by: Matt Ranostay
---
Changes from
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 Nov 26 05:00:20 CET 2016
media-tree git hash:d3d83ee20afda16ad0133ba00f63c11a8d842a35
media_build git
On Fri, Nov 25, 2016 at 2:34 PM, Jason Gunthorpe
wrote:
> On Fri, Nov 25, 2016 at 12:16:30PM -0500, Serguei Sagalovitch wrote:
>
>> b) Allocation may not have CPU address at all - only GPU one.
>
> But you don't expect RDMA to work in the case, right?
>
> GPU people need to stop doing this windo
The check assumes that we end on zero but actually we end on -1. Change
the post-op to a pre-op so that we do end on zero. Techinically now we
only loop 499 times instead of 500 but that's fine.
Fixes: dc12b124353b ("[media] media: ti-vpe: vpdma: Add abort channel desc and
cleanup APIs")
Signed
On Fri, Nov 25, 2016 at 09:40:10PM +0100, Christian König wrote:
> We call this "userptr" and it's just a combination of get_user_pages() on
> command submission and making sure the returned list of pages stays valid
> using a MMU notifier.
Doesn't that still pin the page?
> The "big" problem wi
On 16-11-25 12:20 PM, Serguei Sagalovitch wrote:
>
>> A white list may end up being rather complicated if it has to cover
>> different CPU generations and system architectures. I feel this is a
>> decision user space could easily make.
>>
>> Logan
> I agreed that it is better to leave up to user sp
On 16-11-25 03:40 PM, Christian König wrote:
> Am 25.11.2016 um 20:32 schrieb Jason Gunthorpe:
>> This assumes the commands are fairly short lived of course, the
>> expectation of the mmu notifiers is that a flush is reasonably prompt
>
> Correct, this is another problem. GFX command submissions u
On 2016-11-25 03:26 PM, Felix Kuehling wrote:
On 16-11-25 12:20 PM, Serguei Sagalovitch wrote:
A white list may end up being rather complicated if it has to cover
different CPU generations and system architectures. I feel this is a
decision user space could easily make.
Logan
I agreed that it
Am 25.11.2016 um 20:32 schrieb Jason Gunthorpe:
On Fri, Nov 25, 2016 at 02:22:17PM +0100, Christian König wrote:
Like you say below we have to handle short lived in the usual way, and
that covers basically every device except IB MRs, including the
command queue on a NVMe drive.
Well a problem
On Fri, Nov 25, 2016 at 02:49:50PM -0500, Serguei Sagalovitch wrote:
> GPU could perfectly access all VRAM. It is only issue for p2p without
> special interconnect and CPU access. Strictly speaking as long as we
> have "bus address" we could have RDMA but I agreed that for
> RDMA we could/shoul
On 2016-11-25 02:34 PM, Jason Gunthorpe wrote:
On Fri, Nov 25, 2016 at 12:16:30PM -0500, Serguei Sagalovitch wrote:
b) Allocation may not have CPU address at all - only GPU one.
But you don't expect RDMA to work in the case, right?
GPU people need to stop doing this windowed memory stuff :)
On Thu, Nov 24, 2016 at 11:58:17PM -0800, Christoph Hellwig wrote:
> On Thu, Nov 24, 2016 at 11:11:34AM -0700, Logan Gunthorpe wrote:
> > * Regular DAX in the FS doesn't work at this time because the FS can
> > move the file you think your transfer to out from under you. Though I
> > understand the
Hi Alan,
On Friday 25 Nov 2016 10:21:21 Alan Stern wrote:
> On Fri, 25 Nov 2016, Sakari Ailus wrote:
> > On Thu, Nov 24, 2016 at 09:15:39PM -0500, Alan Stern wrote:
> >> On Fri, 25 Nov 2016, Laurent Pinchart wrote:
> >>> Dear linux-pm developers, what's the suggested way to ensure that a
> >>> run
On Fri, Nov 25, 2016 at 12:16:30PM -0500, Serguei Sagalovitch wrote:
> b) Allocation may not have CPU address at all - only GPU one.
But you don't expect RDMA to work in the case, right?
GPU people need to stop doing this windowed memory stuff :)
Jason
--
To unsubscribe from this list: send t
On Fri, Nov 25, 2016 at 02:22:17PM +0100, Christian König wrote:
> >Like you say below we have to handle short lived in the usual way, and
> >that covers basically every device except IB MRs, including the
> >command queue on a NVMe drive.
>
> Well a problem which wasn't mentioned so far is that
On Fri, Nov 25, 2016 at 06:02:45PM +0200, Laurent Pinchart wrote:
> Sakari Ailus (CC'ed) has expressed the opinion that we might want to go one
> step further and treat error pointers the same way we treat NULL or ZERO
> pointers today, by just returning without logging anything. The reasoning is
On Fri, Nov 25, 2016 at 03:57:51PM +0200, Laurent Pinchart wrote:
> diff --git a/mm/slab.c b/mm/slab.c
> index 0b0550ca85b4..a7eb830c6684 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -3819,6 +3819,8 @@ void kfree(const void *objp)
>
> if (unlikely(ZERO_OR_NULL_PTR(objp)))
>
On 2016-11-25 08:22 AM, Christian König wrote:
Serguei, what is your plan in GPU land for migration? Ie if I have a
CPU mapped page and the GPU moves it to VRAM, it becomes non-cachable
- do you still allow the CPU to access it? Or do you swap it back to
cachable memory if the CPU touches it?
Well, I guess there's some consensus building to do. The existing
options are:
* Device DAX: which could work but the problem I see with it is that it
only allows one application to do these transfers. Or there would have
to be some user-space coordination to figure which application gets what
A white list may end up being rather complicated if it has to cover
different CPU generations and system architectures. I feel this is a
decision user space could easily make.
Logan
I agreed that it is better to leave up to user space to check what is
working
and what is not. I found that writ
Add the OUT_FENCE_PTR property to writeback connectors, to enable
userspace to get a fence which will signal once the writeback is
complete. It is not allowed to request an out-fence without a
framebuffer attached to the connector.
A timeline is added to drm_writeback_connector for use by the writ
Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.
Drivers should initialize a writeback connector with
drm_writeback_connector_init() which takes care of setting up all the
writeba
We're going to use the same format list for output formats, so rename
everything related to input formats to avoid confusion.
Signed-off-by: Brian Starkey
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 24
drivers/gpu/drm/arm/malidp_hw.h |8
From: Liviu Dudau
Mali-DP display processors are able to write the composition result to a
memory buffer via the SE.
Add entry points in the HAL for enabling/disabling this feature, and
implement support for it on DP650 and DP550. DP500 acts differently and
so is omitted from this change.
Signe
Add a layer bit for the SE memory-write, and add it to the pixel format
matrix for DP550/DP650.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/arm/malidp_hw.c | 28 ++--
drivers/gpu/drm/arm/malidp_hw.h |1 +
2 files changed, 15 insertions(+), 14 deletions(-)
diff
Hi,
This is v3 of my series introducing a new connector type:
DRM_MODE_CONNECTOR_WRITEBACK
See v1 and v2 here: [1] [2]
Writeback connectors are used to expose the memory writeback engines
found in some display controllers, which can write a CRTC's
composition result to a memory buffer.
This is u
Mali-DP has a memory writeback engine which can be used to write the
composition result to a memory buffer. Expose this functionality as a
DRM writeback connector on supported hardware.
Changes since v1:
Daniel Vetter:
- Don't require a modeset when writeback routing changes
- Make writeback co
On 25/11/16 06:06 AM, Christian König wrote:
> Well Serguei send me a couple of documents about QPI when we started to
> discuss this internally as well and that's exactly one of the cases I
> had in mind when writing this.
>
> If I understood it correctly for such systems P2P is technical possi
Hi Walter,
On Friday 25 Nov 2016 15:47:49 walter harms wrote:
> Am 25.11.2016 14:57, schrieb Laurent Pinchart:
> > On Friday 25 Nov 2016 13:28:35 Dan Carpenter wrote:
> >> A recent cleanup introduced a potential dereference of -EFAULT when we
> >> call kfree(map->menu_info).
> >
> > I should have
On Fri, 25 Nov 2016, Sakari Ailus wrote:
> Hi Alan and others,
>
> On Thu, Nov 24, 2016 at 09:15:39PM -0500, Alan Stern wrote:
> > On Fri, 25 Nov 2016, Laurent Pinchart wrote:
> >
> > > Dear linux-pm developers, what's the suggested way to ensure that a
> > > runtime-
> > > pm-enabled driver ca
Add Makefiles and Kconfig files to build the camss driver.
Signed-off-by: Todor Tomov
---
drivers/media/platform/qcom/Kconfig | 5 +
drivers/media/platform/qcom/Makefile| 1 +
drivers/media/platform/qcom/camss-8x16/Makefile | 12
3 files changed, 18 ins
Add DT binding document for Qualcomm Camera subsystem driver.
Signed-off-by: Todor Tomov
---
.../devicetree/bindings/media/qcom,camss.txt | 196 +
1 file changed, 196 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/qcom,camss.txt
diff --git a/
These files control the CSID modules which handle the protocol and application
layer of the CSI2 receivers.
Signed-off-by: Todor Tomov
---
drivers/media/platform/qcom/camss-8x16/csid.c | 1071 +
drivers/media/platform/qcom/camss-8x16/csid.h | 82 ++
2 files changed, 115
Add a document to describe Qualcomm Camera Subsystem driver.
Signed-off-by: Todor Tomov
---
Documentation/media/v4l-drivers/index.rst | 1 +
Documentation/media/v4l-drivers/qcom_camss.rst | 124 +
2 files changed, 125 insertions(+)
create mode 100644 Documentation
These files control the VFE module. The VFE has different input interfaces.
The PIX input interface feeds the input data to an image processing pipeline.
Three RDI input interfaces bypass the image processing pipeline. The VFE also
contains the AXI bus interface which writes the output data to memo
These files handle the video device nodes of the camss driver.
Signed-off-by: Todor Tomov
---
drivers/media/platform/qcom/camss-8x16/video.c | 597 +
drivers/media/platform/qcom/camss-8x16/video.h | 67 +++
2 files changed, 664 insertions(+)
create mode 100644 drivers/m
These files implement the platform driver code.
Signed-off-by: Todor Tomov
---
drivers/media/platform/qcom/camss-8x16/camss.c | 603 +
drivers/media/platform/qcom/camss-8x16/camss.h | 93
2 files changed, 696 insertions(+)
create mode 100644 drivers/media/platform/
These files control the ISPIF module which handles the routing of the data
streams from the CSIDs to the inputs of the VFE.
Signed-off-by: Todor Tomov
---
drivers/media/platform/qcom/camss-8x16/ispif.c | 1105
drivers/media/platform/qcom/camss-8x16/ispif.h | 85 ++
2 f
Add an entry for Qualcomm Camera subsystem driver.
Signed-off-by: Todor Tomov
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 411e3b8..0740aee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9971,6 +9971,14 @@ T: git
git://git.ker
These files control the CSIPHY modules which are responsible for the physical
layer of the CSI2 receivers.
Signed-off-by: Todor Tomov
---
drivers/media/platform/qcom/camss-8x16/csiphy.c | 685
drivers/media/platform/qcom/camss-8x16/csiphy.h | 77 +++
2 files changed, 76
This patchset adds basic support for the Qualcomm Camera Subsystem found
on Qualcomm MSM8916 and APQ8016 processors.
The driver implements V4L2, Media controller and V4L2 subdev interfaces.
Camera sensor using V4L2 subdev interface in the kernel is supported.
The driver is implemented using as a
Am 25.11.2016 14:57, schrieb Laurent Pinchart:
> Hi Dan,
>
> Thank you for the patch.
>
> On Friday 25 Nov 2016 13:28:35 Dan Carpenter wrote:
>> A recent cleanup introduced a potential dereference of -EFAULT when we
>> call kfree(map->menu_info).
>
> I should have caught that, my apologies :-(
Hi Shailendra,
Thank you for the patch.
On Friday 25 Nov 2016 10:14:32 Shailendra Verma wrote:
> v4l2_fh_init is already done.So call the v4l2_fh_exit in error condition
> before returing from the function.
>
> Signed-off-by: Shailendra Verma
> ---
> drivers/media/platform/omap3isp/ispvideo.c
Hi Dan,
Thank you for the patch.
On Friday 25 Nov 2016 13:28:35 Dan Carpenter wrote:
> A recent cleanup introduced a potential dereference of -EFAULT when we
> call kfree(map->menu_info).
I should have caught that, my apologies :-(
Thinking a bit more about this class of problems, would the fol
Use dev_dbg() to tell about the progress of the graph traversal algorithm.
This is intended to make debugging of the algorithm easier.
Signed-off-by: Sakari Ailus
---
drivers/media/media-entity.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/medi
Commit 3801bc7d1b8d ("[media] media: Media Controller fix to not let
stream_count go negative") added a sanity check for negative stream_count,
but a failure of the check remained silent. Make sure the failure is
noticed.
Signed-off-by: Sakari Ailus
---
drivers/media/media-entity.c | 8
The media_entity_pipeline_start() and media_entity_pipeline_stop()
functions are renamed as media_pipeline_start() and media_pipeline_stop(),
respectively. The reason is two-fold: the pipeline struct is, rightly,
already called media_pipeline (rather than media_entity_pipeline) and what
this really
With media_entity_graph_walk_next() getting more and more complicated (and
especially so with has_routing() support added), split the function into
two.
Signed-off-by: Sakari Ailus
---
drivers/media/media-entity.c | 56
1 file changed, 30 insertions(+
Hi folks,
This patchset contains a few cleanups and fixes for graph traversal and
pipeline starting and stopping.
The set prepares for further routing changes without still making any of
them. I'll post further patches on routing in the near future.
Niklas: these go on top of your two patches in
There's a sanity check for the stream count remaining positive or zero on
error path, but instead of performing the check on the traversed entity it
is performed on the entity where traversal ends. Fix this.
Fixes: commit 3801bc7d1b8d ("[media] media: Media Controller fix to not let
stream_count
> A recent cleanup introduced a potential dereference of -EFAULT when we
> call kfree(map->menu_info).
>
> Fixes: 4cc5bed1caeb ("[media] uvcvideo: Use memdup_user() rather than
> duplicating its implementation")
> Signed-off-by: Dan Carpenter
Thanks for your information.
> diff --git a/driver
Hi Shailendra,
Thank you for the patch.
The subject line is missing something (and has an extra -), I would phrase it
as
"v4l: vsp1: Clean up file handle in open() error path"
(Mauro's scripts will add the "[media]" prefix when applying, so there's no
need to add it manually)
The same commen
Am 24.11.2016 um 18:55 schrieb Logan Gunthorpe:
Hey,
On 24/11/16 02:45 AM, Christian König wrote:
E.g. it can happen that PCI device A exports it's BAR using ZONE_DEVICE.
Not PCI device B (a SATA device) can directly read/write to it because
it is on the same bus segment, but PCI device C (a ne
Am 24.11.2016 um 17:42 schrieb Jason Gunthorpe:
On Wed, Nov 23, 2016 at 06:25:21PM -0700, Logan Gunthorpe wrote:
On 23/11/16 02:55 PM, Jason Gunthorpe wrote:
Only ODP hardware allows changing the DMA address on the fly, and it
works at the page table level. We do not need special handling for
Two fixes to make vivid work correctly with HSV.
Regards,
Hans
The following changes since commit d3d83ee20afda16ad0133ba00f63c11a8d842a35:
[media] DaVinci-VPFE-Capture: fix error handling (2016-11-25 07:57:07 -0200)
are available in the git repository at:
git://linuxtv.org/hverku
Hi Mauro,
It's just a single patch, but I'd like to get that into 4.10. Now that the
cec framework moves out of staging I prefer to get this kernel API change
in before more CEC drivers are added.
Regards,
Hans
The following changes since commit 4cc5bed1caeb6d40f2f41c4c5eb83368691fbffb:
A recent cleanup introduced a potential dereference of -EFAULT when we
call kfree(map->menu_info).
Fixes: 4cc5bed1caeb ("[media] uvcvideo: Use memdup_user() rather than
duplicating its implementation")
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/us
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
tags/media/v4.9-4
For a fix at the firmware load logic at the tuner-xc2028 driver.
Regards,
Mauro
---
The following changes since commit 9c763584b7c8911106bb77af7e648bef09af9d80:
Linux 4.9-rc6 (
Em Fri, 25 Nov 2016 20:02:57 +1100
Vincent McIntyre escreveu:
> Hi list,
>
> I sent a patch for this issue, could someone take a look?
>
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg105340.html
Patch applied. Next time, please add your Signed-off-by:
Thanks,
Mauro
--
To unsub
On Tue, Aug 02, 2016 at 07:44:07AM +0200, Heiner Kallweit wrote:
> I think we can get rid of the spinlock protecting the kthread from being
> interrupted by a wakeup in certain parts.
> Even with the current implementation of the kthread the only lost wakeup
> scenario could happen if the wakeup oc
Em Wed, 16 Nov 2016 07:29:11 -0700
Shuah Khan escreveu:
> Change ALSA driver to use Media Controller API to share media resources
> with DVB, and V4L2 drivers on a AU0828 media device.
>
> Media Controller specific initialization is done after sound card is
> registered. ALSA creates Media inte
Em Wed, 16 Nov 2016 07:29:10 -0700
Shuah Khan escreveu:
> Change au0828 to use Media Device Allocator API to allocate media device
> with the parent usb struct device as the key, so it can be shared with the
> snd_usb_audio driver.
>
> Signed-off-by: Shuah Khan
I missed a v5 for this patch. Th
Em Fri, 18 Nov 2016 14:45:10 -0700
Shuah Khan escreveu:
> Media Device Allocator API to allows multiple drivers share a media device.
> Using this API, drivers can allocate a media device with the shared struct
> device as the key. Once the media device is allocated by a driver, other
> drivers c
Hi list,
I sent a patch for this issue, could someone take a look?
http://www.mail-archive.com/linux-media@vger.kernel.org/msg105340.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://
On 11/25/16, Sean Young wrote:
>
> So if I understand you correctly, if you change the keymap, like you
> changed 0xfe47 to KEY_PAUSE, then "ir-keytable -s rc1 -t" show you the
> correct (new) key? So as far as ir-keytable is concerned, everything
> works?
>
> However when you try to use the new m
Em Mon, 21 Nov 2016 17:35:42 +0100
Arnd Bergmann escreveu:
> On Saturday, November 19, 2016 12:56:57 PM CET Mauro Carvalho Chehab wrote:
> > As Arnd reported:
> >
> > With gcc-5 or higher on x86, we can get a bogus warning in the
> > dvb-net code:
> >
> > drivers/media/dvb-core/dvb_
The cec_allocate_adapter function doesn't need the parent device, only the
cec_register_adapter function needs it.
Drop the cec_devnode parent field, since devnode.dev.parent can be used
instead.
This change makes the framework consistent with other frameworks where the
parent device is not used
On Thu, Nov 24, 2016 at 11:11:34AM -0700, Logan Gunthorpe wrote:
> * Regular DAX in the FS doesn't work at this time because the FS can
> move the file you think your transfer to out from under you. Though I
> understand there's been some work with XFS to solve that issue.
The file system will nev
Hi Javi,
On Wed, Nov 23, 2016 at 04:15:11PM +, Javi Merino wrote:
> On Wed, Nov 23, 2016 at 05:10:42PM +0200, Sakari Ailus wrote:
> > Hi Javi,
>
> Hi Sakari,
>
> > On Wed, Nov 23, 2016 at 10:09:57AM +, Javi Merino wrote:
> > > In asd's configured with V4L2_ASYNC_MATCH_OF, if the v4l2 sub
69 matches
Mail list logo
