Hi Laurent, others,
On Sat, Feb 15, 2025 at 09:43:28PM +0200, Laurent Pinchart wrote:
> CC'ing Sakari.
>
> Sakari, would you pick this patch ?
Thanks! I wonder what happened -- it wasn't visible in Linuxtv.org
Patchwork but could be found via the message id.
It's in m
CC'ing Sakari.
Sakari, would you pick this patch ?
On Sat, Feb 15, 2025 at 08:57:24AM +0200, Sicelo wrote:
> On Mon, Oct 28, 2024 at 05:58:36PM +, Robin Murphy wrote:
> > It's no longer practical for the OMAP IOMMU driver to trick
> > arm_setup_iommu_dma_ops() into
ping) {
> + arm_iommu_detach_device(isp->dev);
> + arm_iommu_release_mapping(mapping);
> + }
> +
> /*
>* Create the ARM mapping, used by the ARM DMA mapping core to allocate
>* VAs. This will allocate a corresponding IOM
terfere with the core rproc->domain and we get the right DMA ops.
> + */
> + if (pdev->dev.archdata.mapping) {
> + struct dma_iommu_mapping *mapping =
> to_dma_iommu_mapping(&pdev->dev);
> +
> + arm_iommu_detach_device(&pdev->dev);
> +
es (OMA35 and
DM37) are still being sold and I still run various tests on them
periodically. There is also an AM3517 that I still periodically test.
Once Micron kills off the RAM and they run out of supply and Beacon
cannot sell them anymore, I'll submit a patch to remove the
unsupported / EOL boards.
>
> Thanks to everyone for the amazing work.
Thank you for all this. I haven't been as active lately, but I have
been following this.
adam
>
> Sincerely
> Sicelo
>
Hi
On Wed, Oct 30, 2024 at 01:38:11PM +0100, Joerg Roedel wrote:
> On Wed, Oct 30, 2024 at 12:20:31PM +0100, H. Nikolaus Schaller wrote:
> > Why that? There was a discussion and everyone agreed to remove omap2,
> > but not omap3 and later.
>
> I raised this question to make sure the things we mai
On Wed, Oct 30, 2024 at 12:20:31PM +0100, H. Nikolaus Schaller wrote:
> Why that? There was a discussion and everyone agreed to remove omap2,
> but not omap3 and later.
I raised this question to make sure the things we maintain are still
relevant. Developer and maintainers time is limited and we s
> patches attempt to bring it and its consumers sufficiently up-to-date
>> to work again, in a manner that's hopefully backportable. This is
>> largely all written by inspection, but I have managed to lightly boot
>> test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_
to work again, in a manner that's hopefully backportable. This is
> largely all written by inspection, but I have managed to lightly boot
> test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_device()
> working again.
My initial reflex would have been to just wipe the omap dri
anner that's hopefully backportable. This is
largely all written by inspection, but I have managed to lightly boot
test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_device()
working again.
This supersedes my previous patch[1]. Patches #1 and #2 are functionally
independent, and can
hopefully backportable. This is
> largely all written by inspection, but I have managed to lightly boot
> test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_device()
> working again.
>
> This supersedes my previous patch[1]. Patches #1 and #2 are functionally
> independe
recent evolution of the IOMMU API internals. These
> > patches attempt to bring it and its consumers sufficiently up-to-date
> > to work again, in a manner that's hopefully backportable. This is
> > largely all written by inspection, but I have managed to lightly boot
> > t
fficiently up-to-date
> to work again, in a manner that's hopefully backportable. This is
> largely all written by inspection, but I have managed to lightly boot
> test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_device()
> working again.
>
> This supersedes my prev
It's no longer practical for the OMAP IOMMU driver to trick
arm_setup_iommu_dma_ops() into ignoring its presence, so let's use the
same tactic as other IOMMU API users on 32-bit ARM and explicitly kick
the arch code's dma_iommu_mapping out of the way to avoid problems.
Fixes: 4720287c7bf7 ("iommu:
argely all written by inspection, but I have managed to lightly boot
test patch #3 on an OMAP4 Pandaboard to confirm iommu_probe_device()
working again.
This supersedes my previous patch[1]. Patches #1 and #2 are functionally
independent, and can be applied directly to their respective trees if
With the last external caller of bus_iommu_probe() now gone, make it
internal as it really should be.
Signed-off-by: Robin Murphy
---
drivers/iommu/iommu.c | 3 ++-
include/linux/iommu.h | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/i
The OMAP driver uses the generic "iommus" DT binding but is the final
holdout not implementing a corresponding .of_xlate method. Unfortunately
this now results in __iommu_probe_device() failing to find ops due to
client devices missing the expected IOMMU fwnode association. The legacy
DT parsing in
It's no longer practical for the OMAP IOMMU driver to trick
arm_setup_iommu_dma_ops() into ignoring its presence, so let's use the
same tactic as other IOMMU API users on 32-bit ARM and explicitly kick
the arch code's dma_iommu_mapping out of the way to avoid problems.
Fixes: 4720287c7bf7 ("iommu:
On Thu, Sep 28, 2023 at 01:36:06AM +0200, Ben Hutchings wrote:
> On Wed, 2023-09-20 at 13:30 +0200, Greg Kroah-Hartman wrote:
> > 4.19-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Gr
On Wed, 2023-09-20 at 13:30 +0200, Greg Kroah-Hartman wrote:
> 4.19-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Greg Kroah-Hartman
>
> commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream.
>
> In co
5.4-stable review patch. If anyone has any objections, please let me know.
--
From: Greg Kroah-Hartman
commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream.
In commit 9011e49d54dc ("modules: only allow symbol_get of
EXPORT_SYMBOL_GPL modules") the use of sym
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Greg Kroah-Hartman
commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream.
In commit 9011e49d54dc ("modules: only allow symbol_get of
EXPORT_SYMBOL_GPL modules") the use of sym
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Greg Kroah-Hartman
commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream.
In commit 9011e49d54dc ("modules: only allow symbol_get of
EXPORT_SYMBOL_GPL modules") the use of sym
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Greg Kroah-Hartman
commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream.
In commit 9011e49d54dc ("modules: only allow symbol_get of
EXPORT_SYMBOL_GPL modules") the use of sym
5.10-stable review patch. If anyone has any objections, please let me know.
--
From: Greg Kroah-Hartman
commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream.
In commit 9011e49d54dc ("modules: only allow symbol_get of
EXPORT_SYMBOL_GPL modules") the use of sym
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Greg Kroah-Hartman
commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream.
In commit 9011e49d54dc ("modules: only allow symbol_get of
EXPORT_SYMBOL_GPL modules") the use of sym
6.4-stable review patch. If anyone has any objections, please let me know.
--
From: Greg Kroah-Hartman
commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream.
In commit 9011e49d54dc ("modules: only allow symbol_get of
EXPORT_SYMBOL_GPL modules") the use of sym
6.5-stable review patch. If anyone has any objections, please let me know.
--
From: Greg Kroah-Hartman
commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream.
In commit 9011e49d54dc ("modules: only allow symbol_get of
EXPORT_SYMBOL_GPL modules") the use of sym
Hi!
> > I'm skeptical about adding now a property for a device that we don't
> > support, because we -now- think it's a good idea. I might be wrong,
> > but my assumption is that when someone will want to support an
> > 'advanced' device, it's easy to add "movable" or whatever else to the
> > list
; >
> > > On Fri, Aug 30, 2019 at 12:16:35PM +0200, Marco Felsch wrote:
> > > > The patch adds the initial connector parsing code, so we can move from a
> > > > driver specific parsing code to a generic one. Currently only the
> > > > generic f
Hi Marco,
Apologies for the delay.
On Wed, Oct 02, 2019 at 10:07:35AM +0200, Marco Felsch wrote:
> Hi Sakari,
>
> On 19-10-02 10:03, Sakari Ailus wrote:
> > Hi Marco,
> >
> > On Fri, Aug 30, 2019 at 12:16:35PM +0200, Marco Felsch wrote:
> > > The patch add
t; Regards,
>
> Hans
>
> On 5/18/19 3:07 AM, Niklas Söderlund wrote:
> > Hi,
> >
> > This series adds support for two (or more) capture devices to be
> > connected to the same senors and run simultaneously. Each capture device
> > can be started a
Hi Bingbu,
On Tue, Oct 08, 2019 at 12:21:27PM +0800, bingbu@intel.com wrote:
> From: Bingbu Cao
>
> This patch add more details for the resolution change blocks
> It can help the developer to understand the main resolution
> change blocks in ImgU.
>
> Signed-off-by:
On 10/9/19 5:53 PM, Dafna Hirschfeld wrote:
> Userspace can disable links and create pipelines that
> do not start with a source entity. Trying to stream
> from such a pipeline should fail with -EPIPE
> currently this is not handled and cause kernel crash.
>
> Reproducing the crash:
> media-ctl -d
independent of each other.
>
> Patch 1/3 and 2/3 deals with solving the issues that arises once two
> capture devices can be part of the same pipeline. While 3/3 allows for
> two capture devices to be part of the same pipeline and thus allows for
> simultaneously use.
>
> Th
From: Bingbu Cao
Currently, we can build ipu3 driver code without any
warnings with W=1, so the extra compiler flags in Makefile
and the item in TODO file can be removed.
Signed-off-by: Bingbu Cao
Signed-off-by: Sakari Ailus
Cc: Mauro Carvalho Chehab
---
drivers/staging/media/ipu3/Makefile |
From: Bingbu Cao
The data type conversion of the IEFD CU inputs in ipu3 uapi
is ambiguities, add some clarification to help user to
understand this conversion.
Signed-off-by: Bingbu Cao
Suggested-by: Sakari Ailus
Cc: Sakari Ailus
Cc: Tomasz Figa
Cc: Laurent Pinchart
---
drivers/staging/med
On 10/8/19 10:20 AM, Jacopo Mondi wrote:
> On Tue, Oct 08, 2019 at 10:06:34AM +0200, Pavel Machek wrote:
>> On Tue 2019-10-08 09:58:28, Jacopo Mondi wrote:
>>> Pavel,
>>>
>>> On Tue, Oct 08, 2019 at 09:40:52AM +0200, Pavel Machek wrote:
On Mon 2019-10-07 18:29:03, Jacopo Mondi wrote:
> Add
On 10/7/19 6:29 PM, Jacopo Mondi wrote:
> Add documentation for the V4L2_CID_CAMERA_SENSOR_ROTATION camera
> control. The newly added read-only control reports the camera device
> mounting rotation.
>
> Signed-off-by: Jacopo Mondi
> ---
> .../media/uapi/v4l/ext-ctrls-camera.rst | 116 +
remove unused code
Signed-off-by: Jan Pieter van Woerkom
---
diff -ru a/drivers/media/usb/dvb-usb-v2/dvbsky.c
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c 2019-10-22 13:15:31.598029247
+0200
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c 2019-10-22 12
Hi Sakari,
gentle ping.
On 19-10-02 10:07, Marco Felsch wrote:
> Hi Sakari,
>
> On 19-10-02 10:03, Sakari Ailus wrote:
> > Hi Marco,
> >
> > On Fri, Aug 30, 2019 at 12:16:35PM +0200, Marco Felsch wrote:
> > > The patch adds the initial connector parsing code
This patchset removes code and declarations that are
not used.
- The first patch removes the declarations EXPORT_SYMBOL_GPL.
Those are not needed since vimc is now a single kernel module
so it does not need to export any symbol.
- The second patch removes the function vimc_pipeline_s_stream
in the
vimc is a single kernel module and does not need to
export any symbols therefore there is no need for these
declarations.
Signed-off-by: Dafna Hirschfeld
---
drivers/media/platform/vimc/vimc-common.c | 8
drivers/media/platform/vimc/vimc-streamer.c | 1 -
2 files changed, 9 deletions(
The function 'vimc_pipeline_s_stream' is not used and can be
removed.
Signed-off-by: Dafna Hirschfeld
---
drivers/media/platform/vimc/vimc-common.c | 28 ---
drivers/media/platform/vimc/vimc-common.h | 11 -
2 files changed, 39 deletions(-)
diff --git a/drivers/media
Support to emulate touch devices in vivid driver.
Signed-off-by: Vandana BN
---
drivers/media/platform/vivid/Makefile | 3 +-
drivers/media/platform/vivid/vivid-core.c | 134 ++-
drivers/media/platform/vivid/vivid-core.h | 18 ++
drivers/media/platform/vivid/vivid-ctrl
v4l_s_fmt, for VFL_TYPE_TOUCH, sets unneeded members of
the v4l2_pix_format structure to default values.This was
missing in v4l_g_fmt, which would lead to failures in
v4l2-compliance tests.
Signed-off-by: Vandana BN
---
drivers/media/v4l2-core/v4l2-ioctl.c | 33 +++-
1 fi
This patch adds support for touch devices in the vivid driver.
Current code provides a framework for touch support and passes
compliance tests.
TODO: Add touch emulation.
Thank you.
Regards,
Vandana.
Vandana BN (2):
v4l2-core: fix touch support in v4l_g_fmt
vivid: Add touch support
drivers
On 10/21/19 11:48 AM, Tomasz Figa wrote:
> On Mon, Oct 21, 2019 at 6:38 PM Hans Verkuil wrote:
>>
>> On 10/21/19 11:26 AM, Tomasz Figa wrote:
>>> On Mon, Oct 21, 2019 at 5:41 PM Hans Verkuil wrote:
On 10/8/19 11:11 AM, Boris Brezillon wrote:
> This is part of the multiplanar and sin
On Mon, Oct 21, 2019 at 6:38 PM Hans Verkuil wrote:
>
> On 10/21/19 11:26 AM, Tomasz Figa wrote:
> > On Mon, Oct 21, 2019 at 5:41 PM Hans Verkuil wrote:
> >>
> >> On 10/8/19 11:11 AM, Boris Brezillon wrote:
> >>> This is part of the multiplanar and singleplanar unification process.
> >>> v4l2_ext
On 10/21/19 11:26 AM, Tomasz Figa wrote:
> On Mon, Oct 21, 2019 at 5:41 PM Hans Verkuil wrote:
>>
>> On 10/8/19 11:11 AM, Boris Brezillon wrote:
>>> This is part of the multiplanar and singleplanar unification process.
>>> v4l2_ext_pix_format is supposed to work for both cases.
>>>
>>> We also add
On Mon, Oct 21, 2019 at 5:41 PM Hans Verkuil wrote:
>
> On 10/8/19 11:11 AM, Boris Brezillon wrote:
> > This is part of the multiplanar and singleplanar unification process.
> > v4l2_ext_pix_format is supposed to work for both cases.
> >
> > We also add the concept of modifiers already employed in
On 10/8/19 11:11 AM, Boris Brezillon wrote:
> This is part of the multiplanar and singleplanar unification process.
> v4l2_ext_pix_format is supposed to work for both cases.
>
> We also add the concept of modifiers already employed in DRM to expose
> HW-specific formats (like tiled or compressed f
Print the node name during endpoint parsing for better debuggability.
Depends-on: ("lib/vsprintf: Add %pfw conversion specifier for printing fwnode
names")
Signed-off-by: Sakari Ailus
---
drivers/media/v4l2-core/v4l2-fwnode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --g
When driver is built as module and probe during insmod is deferred
because of sensor subdevs, there is NULL pointer deference because
mdev is cleaned up and then access it from v4l2_device_unregister().
Fix the wrong mdev and v4l2 dev odder in error path of probe.
This fixes below null pointer def
Hi Biju,
Thanks for your work.
On 2019-10-15 11:57:54 +0100, Biju Das wrote:
> This patch series add VIN/CSI-2 driver support for RZ/G2N SoC.
For the whole series,
Reviewed-by: Niklas Söderlund
>
> Biju Das (4):
> media: dt-bindings: rcar-vin: Add R8A774B1 support
> med
Sometimes the remotes sends 4 bits rather than 5. This makes the pointer
much more reliable.
Signed-off-by: Sean Young
---
utils/keytable/bpf_protocols/imon_rsc.c | 66 +
1 file changed, 35 insertions(+), 31 deletions(-)
diff --git a/utils/keytable/bpf_protocols/imon_rsc
Destroy the mutex initialised by the driver in probe.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 24f4197cf7ad
Hi Jacopo,
(Cc'ing the devicetree list.)
On Mon, Oct 07, 2019 at 06:29:03PM +0200, Jacopo Mondi wrote:
> Add the 'location' device property, used to specify a device mounting
> position. The property is particularly meaningful for mobile devices
> with a well defined usage orientation.
>
> Signe
Hi Jacopo,
On Mon, Oct 07, 2019 at 06:29:08PM +0200, Jacopo Mondi wrote:
> Add an helper function to parse common device properties in the same
> way as v4l2_fwnode_endpoint_parse() parses common endpoint properties.
>
> Parse the 'rotation' and 'location' properties from the firmware
> interface
mera sensor properties
> https://patchwork.kernel.org/cover/6443/
> "[PATCH v3 00/11] media: Report camera sensor properties"
> https://patchwork.kernel.org/project/linux-media/list/?series=173571
>
> I here included Hans' comments. Most notable changes
>
> v3
On Fri, Oct 18, 2019 at 05:31:40PM +0200, Janusz Krzysztofik wrote:
> Commit a8fa55078a77 ("media: v4l2-subdev: Verify arguments in
> v4l2_subdev_call()") and commit 374d62e7aa50 ("media: v4l2-subdev:
> Verify v4l2_subdev_call() pad config argument") introduced a few local
> functions, unfortunatel
Commit a8fa55078a77 ("media: v4l2-subdev: Verify arguments in
v4l2_subdev_call()") and commit 374d62e7aa50 ("media: v4l2-subdev:
Verify v4l2_subdev_call() pad config argument") introduced a few local
functions, unfortunately with arguments of type __u32, reserved for use
in Linux uAPI. Use u32 ins
Instead of keeping track of the power state ourselves, let runtime PM
handle it.
This also splits handling controls between side effect management and
writing the new configuration to the sensor's registers.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c | 199 ++
If there was an error in starting streaming, put the runtime usage count
of the device.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiap
Hi folks,
Here's a few patches remaining from my previous smiapp and omap3isp sets.
Sakari Ailus (3):
omap3isp: Don't restart CCDC if we're about to stop
smiapp: Avoid maintaining power state information
smiapp: Put the device again if starting streaming fails
drivers/media/i2c/smiapp/smi
The omap3isp driver set the new buffer and enabled the CCDC in a situation
a new buffer was available but streaming was about to be stopped on the
CCDC. This lead to frequent system crashes in case there were buffers
queued when streming was being stopped.
Fix this by first checking whether there'
On 10/18/19 12:20, Seung-Woo Kim wrote:
>>From isp_video_release(), &isp->video_lock is held and subsequent
> vb2_fop_release() tries to lock vdev->lock which is same with the
> previous one. Replace vb2_fop_release() with _vb2_fop_release() to
> fix the recursive locking.
>
> Fixes: 1380f5754cb0
>From isp_video_release(), &isp->video_lock is held and subsequent
vb2_fop_release() tries to lock vdev->lock which is same with the
previous one. Replace vb2_fop_release() with _vb2_fop_release() to
fix the recursive locking.
Fixes: 1380f5754cb0 ("[media] videobuf2: Add missing lock held on
vb2_
ideo_bitrate=1000;"
> >> ! filesink location=gstenc.h264
> >>
> >> Loic, could you give it a try on db820c too?
> >>
> >> Here is the info on the bug which I try to fix with current patch:
> >>
> >> https://bugs.96boards.org/show_bug.cgi?id=
=NV12,width=1280,height=960,framerate=24/1 !
>> v4l2h264enc
>> extra-controls="controls,h264_profile=4,h264_level="5",video_bitrate=1000;"
>> ! filesink location=gstenc.h264
>>
>> Loic, could you give it a try on db820c too?
>>
>> Here is
ot;controls,h264_profile=4,h264_level="5",video_bitrate=1000;"
> ! filesink location=gstenc.h264
>
> Loic, could you give it a try on db820c too?
>
> Here is the info on the bug which I try to fix with current patch:
>
> https://bugs.96boards.org/show_bug.cgi?id=513
&
The isp was marked to have failed to stop if stopping streaming on an
external subdev failed. The return value from the external subdev should
be ignored instead as it is not part of the ISP and thus the ISP does not
need to be reset for that reason.
Signed-off-by: Sakari Ailus
---
drivers/media
Earlier it was possible that the parts of the driver that assumed runtime
PM was enabled were being called before runtime PM was enabled in the
driver's probe function. So enable runtime PM before registering the
sub-device.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c
Rename the confusingly named smiapp_update_mode() function as
smiapp_pll_blanking_update(). The function is used to calculate new PLL
and blanking configuration after binning or scaling configuration has been
changed.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c | 6 +++
The sensor configuration since it was previously powered off was not
changed, so no need to update the PLL configuration etc. What is necessary
though is to re-apply the configuration to the sensor's registers.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c | 4
1 fi
The driver implementation assumed the binning limits could change
dynamically based on the binning configuration. This is not actually the
case; these limits are static and suitable to be used with all binning
configurations but possibly not optimal limit for many of those
configurations.
Signed-o
Use non-binned limits when binning is disabled and binned when they're
enabled.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c | 27 +++---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers
Hi folks,
This set cleans up binning limit handling and fixes runtime PM use by
enabling runtime PM *before* any functionality requiring runtime PM may be
used.
Also a small omap3isp fix is included.
Sakari Ailus (7):
smiapp: Don't get binning limits dynamically
smiapp: Move binning configur
Only write the binning configuration at stream start. It has no effect
otherwise.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c | 43 +-
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/driv
> > I doubt you can handle pci memory bars like regular ram when it comes to
> > dma and iommu support. There is a reason we have p2pdma in the first
> > place ...
>
> The thing is that such bars would be actually backed by regular host
> RAM. Do we really need the complexity of real PCI bar hand
Hi,
> That could be still a guest physical address. Like on a bare metal
> system with TrustZone, there could be physical memory that is not
> accessible to the CPU.
Hmm. Yes, maybe. We could use the dma address of the (first page of
the) guest buffer. In case of a secure buffer the guest ha
Hi Niklas, Laurent,
On Tue, Oct 15, 2019 at 01:11:07AM +0300, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Mon, Oct 14, 2019 at 02:16:15AM +0200, Niklas Söderlund wrote:
> > Most Gen3 boards can output frames in NV12 format, add support for th
On Thu, Oct 17, 2019 at 4:44 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > > Also note that the guest manages the address space, so the host can't
> > > simply allocate guest page addresses.
> >
> > Is this really true? I'm not an expert in this area, but on a bare
> > metal system it's the hardware or
On Thu, Oct 17, 2019 at 4:19 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > That said, Chrome OS would use a similar model, except that we don't
> > use ION. We would likely use minigbm backed by virtio-gpu to allocate
> > appropriate secure buffers for us and then import them to the V4L2
> > driver.
>
>
On Tue, Oct 15, 2019 at 11:06 PM Dmitry Morozov
wrote:
>
> Hello Gerd,
>
> On Dienstag, 15. Oktober 2019 09:54:22 CEST Gerd Hoffmann wrote:
> > On Mon, Oct 14, 2019 at 03:05:03PM +0200, Dmitry Morozov wrote:
> > > On Montag, 14. Oktober 2019 14:34:43 CEST Gerd Hoffmann wrote:
> > > > Hi,
> > > >
Hi,
> > Also note that the guest manages the address space, so the host can't
> > simply allocate guest page addresses.
>
> Is this really true? I'm not an expert in this area, but on a bare
> metal system it's the hardware or firmware that sets up the various
> physical address allocations on
Hi,
> That said, Chrome OS would use a similar model, except that we don't
> use ION. We would likely use minigbm backed by virtio-gpu to allocate
> appropriate secure buffers for us and then import them to the V4L2
> driver.
What exactly is a "secure buffer"? I guess a gem object where read
a
> Hmm, the cross-device buffer sharing framework I have in mind would
> basically be a buffer registry. virtio-gpu would create buffers as
> usual, create a identifier somehow (details to be hashed out), attach
> the identifier to the dma-buf so it can be used as outlined above.
Using physical ad
On Mon, Oct 14, 2019 at 9:19 PM Gerd Hoffmann wrote:
>
> > > Well. I think before even discussing the protocol details we need a
> > > reasonable plan for buffer handling. I think using virtio-gpu buffers
> > > should be an optional optimization and not a requirement. Also the
> > > motivation
Adds new file for describing new metadata format V4L2_META_FMT_VIVID added in
vivid driver.
Signed-off-by: Vandana BN
---
Change in V3 - modified pixfmt-meta-vivid.rst to have dual GFDL and GPL license.
---
Documentation/media/uapi/v4l/meta-formats.rst | 1 +
.../media/uapi/v4l/pixfmt-meta-viv
On Fri, Oct 11, 2019 at 5:54 PM Dmitry Morozov
wrote:
>
> Hi Tomasz,
>
> On Mittwoch, 9. Oktober 2019 05:55:45 CEST Tomasz Figa wrote:
> > On Tue, Oct 8, 2019 at 12:09 AM Dmitry Morozov
> >
> > wrote:
> > > Hi Tomasz,
> > >
> > > On Montag, 7. Oktober 2019 16:14:13 CEST Tomasz Figa wrote:
> > > >
Vandana,
Can you post a v3 with this proposed license?
Thanks!
Hans
On 10/16/19 9:45 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 4 Oct 2019 13:59:00 +0200
> Hans Verkuil escreveu:
>
>> On 10/4/19 1:55 PM, Vandana BN wrote:
>>> Adds new file for describing new metadata format V4L2_META_
Hi Steve,
On Wed, Oct 16, 2019 at 4:11 PM Steve Longerbeam wrote:
> FIM is available on the above nodes (/dev/video0 and /dev/video3), after
> enabling links to them. So please try:
>
> # media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
> # v4l2-ctl -d0 --list-ctrls
>
> # media-ctl -l "
Em Fri, 4 Oct 2019 13:59:00 +0200
Hans Verkuil escreveu:
> On 10/4/19 1:55 PM, Vandana BN wrote:
> > Adds new file for describing new metadata format V4L2_META_FMT_VIVID added
> > in vivid driver.
> >
> > Signed-off-by: Vandana BN
> > ---
> > Documentation/media/uapi/v4l/meta-formats.rst | 1
On 10/16/19 11:54 AM, Fabio Estevam wrote:
On Wed, Oct 16, 2019 at 2:31 PM Steve Longerbeam wrote:
If /dev/video2 is the "ipu1_ic_prpvf capture" node, it's because FIM is
not yet available on those nodes. The FIM is only available on the
"ipuX_csiY capture" nodes. It's on my plate to fix th
On Wed, Oct 16, 2019 at 2:31 PM Steve Longerbeam wrote:
> If /dev/video2 is the "ipu1_ic_prpvf capture" node, it's because FIM is
> not yet available on those nodes. The FIM is only available on the
> "ipuX_csiY capture" nodes. It's on my plate to fix that.
On a 5.3.6 kernel on imx6dl-sabreauto:
On 10/16/19 6:04 AM, Fabio Estevam wrote:
Hi Steve,
On Tue, Oct 15, 2019 at 10:18 PM Steve Longerbeam wrote:
Here's a quick example that uses the end-of-frame method to measure fi's
(all other FIM controls are left at the default values):
v4l2-ctl -d0 --set-ctrl=fim_enable=1
# disable inp
The touch timer is set up in intf1. If the second interface does not exist,
the timer and touch input device are not setup and we get the following
error, when touch events are reported via intf0.
Reported-by: syzbot+f49d12d34f2321cf4...@syzkaller.appspotmail.com
Signed-off-by: Sean Young
---
dr
ned in the API, and to have the
num_ref_idx_l[01]_active_minus1 fields only be used for
num_ref_idx_l[01]_active_minus1, and not have them sometimes contain the
values of another field.
[1] https://patchwork.linuxtv.org/patch/58580/
[2]
https://github.com/intel/libva/blob/95eb8cf469367b532b391042f
uct file *file, void *priv,
> + struct v4l2_output *o)
> +{
> + struct video_device *vfd = video_devdata(file);
> +
> + if (o->index > 0)
> + return -EINVAL;
> +
> + memset(o, 0, sizeof(*o));
> +
1 - 100 of 98796 matches
Mail list logo
