Hi Mauro,
The second patch renames two CEC events in the public API. Since these were
introduced for 4.14, now is the time to do the rename before they become
part of the ABI. While working with and working on the cec-gpio driver to
debug CEC issues I realized that optionally being able to monitor
Benjamin,
Can you please review this patch and the stm32-cec patch?
Thanks!
Hans
On 08/04/2017 12:41 PM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Use the new CEC_CAP_DEFAULTS define in this driver.
> This also adds the CEC_CAP_RC capability which was missing here
> (and this is al
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 Aug 17 05:00:15 CEST 2017
media-tree git hash:ec0c3ec497cabbf3bfa03a9eb5edcc252190a4e0
media_build gi
Hi Sakari,
On 2017/8/16 0:23, Sakari Ailus wrote:
Hi Wenyou,
On Thu, Aug 10, 2017 at 05:06:44PM +0800, Wenyou Yang wrote:
Add the media entity pads initialization.
Signed-off-by: Wenyou Yang
The patch itself seems fine. However the driver is lacking support for
get_fmt which I think would
From: Fabio Estevam
platform_get_resource() may fail and in this case a NULL dereference
will occur.
Prevent this from happening by returning an error on
platform_get_resource() failure.
Fixes: b0444f18e0b18abce ("[media] coda: add i.MX6 VDOA driver")
Signed-off-by: Fabio Estevam
---
drivers
Hi Kieran,
Thank you for the patch.
On Monday 14 Aug 2017 16:13:24 Kieran Bingham wrote:
> The fragment write function relies on the code never asking it to
> write more than the entries available in the list.
>
> Currently with each list body containing 256 entries, this is fine,
> but we can r
Hi Jonathan,
> I like the basic idea of this patch set a lot btw!
Thanks!
> Jonathan
Could you delete irrelevant parts of the message, please? I nearly
missed your other comment which would have been a great loss!
> I'm trying to get my head around whether this is a sufficient set of
> condit
Hi Jacek,
Thanks for the review.
On Wed, Aug 16, 2017 at 10:27:27PM +0200, Jacek Anaszewski wrote:
> Hi Sakari,
>
> Thanks for the patch. One issue below.
>
> On 08/16/2017 02:55 PM, Sakari Ailus wrote:
> > From: Sakari Ailus
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > .../devicetree/bi
struct v4l2_subdev.host_priv is intended to be used by another driver. This
is hardly good design but back in the days of platform data was a quick
hack to get things done.
As the sub-device specific bus information can be stored to the ISP driver
specific struct allocated along with v4l2_async_su
Hi Sakari,
Thanks for the patch.
I have few more remarks regarding LED class device naming and
pm handling below.
On 08/16/2017 02:55 PM, Sakari Ailus wrote:
> From: Sakari Ailus
>
> Add a LED flash class driver for the as3654a flash controller. A V4L2 flash
> driver for it already exists (dri
Hi Sakari,
Thanks for the patch. One issue below.
On 08/16/2017 02:55 PM, Sakari Ailus wrote:
> From: Sakari Ailus
>
> Signed-off-by: Sakari Ailus
> ---
> .../devicetree/bindings/leds/ams,as3645a.txt | 56
> ++
> 1 file changed, 56 insertions(+)
> create mode 10064
Hi Sakari,
On 08/16/2017 02:54 PM, Sakari Ailus wrote:
> Hi everyone,
>
> This set adds support for the AS3645A flash driver which can be found e.g.
> in Nokia N9.
>
> The set depeds on the flash patches here so I'd prefer to merge this
> through mediatree.
>
> https://git.linuxtv.org/sailus/me
Hi Sakari,
Thank you for the patch.
On Wednesday 16 Aug 2017 20:39:43 Sakari Ailus wrote:
> struct v4l2_subdev.host_priv is intended to be used by another driver. This
> is hardly good design but back in the days of platform data was a quick
> hack to get things done.
>
> As the sub-device speci
struct v4l2_subdev.host_priv is intended to be used by another driver. This
is hardly good design but back in the days of platform data was a quick
hack to get things done.
As the sub-device specific bus information can be stored to the ISP driver
specific struct allocated along with v4l2_async_su
On Wed, Aug 16, 2017 at 08:24:19PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
>
> Thank you for the patch.
>
> On Wednesday 16 Aug 2017 20:05:52 Sakari Ailus wrote:
> > struct v4l2_subdev.host_priv is intended to be used by another driver. This
> > is hardly good design but back in the days of p
Hi Sakari,
Thank you for the patch.
On Wednesday 16 Aug 2017 20:05:52 Sakari Ailus wrote:
> struct v4l2_subdev.host_priv is intended to be used by another driver. This
> is hardly good design but back in the days of platform data was a quick
> hack to get things done.
>
> As the sub-device speci
struct v4l2_subdev.host_priv is intended to be used by another driver. This
is hardly good design but back in the days of platform data was a quick
hack to get things done.
As the sub-device specific bus information can be stored to the ISP driver
specific struct allocated along with v4l2_async_su
On Mon, Aug 07, 2017 at 09:09:26AM +0200, Matthias Reichl wrote:
> Hi Sean!
>
> On Sun, Aug 06, 2017 at 09:56:55AM +0100, Sean Young wrote:
> > The rc device is created before the input device, so if ir-keytable runs
> > too early the input device does not exist yet.
> >
> > Ensure that rule fire
struct v4l2_subdev.host_priv is intended to be used by another driver. This
is hardly good design but back in the days of platform data was a quick
hack to get things done.
As the sub-device specific bus information can be stored to the ISP driver
specific struct allocated along with v4l2_async_su
> Right:
>
> drivers/i2c/i2c-core-base.c:2310:15: error: 'i2c_release_bounce_buf'
> undeclared here (not in a function)
> EXPORT_SYMBOL_GPL(i2c_release_bounce_buf);
Thanks. I am just now working on V4 currently which is a redesign.
I'll write more in an hour or so.
signature.asc
Description:
The first argument of function snd_ctl_new1 is of type const struct
snd_kcontrol_new * but in this file the variable is passed by value
to this function. This generated ""incompatible type for argument"
error. So, pass the variable by reference.
Signed-off-by: Bhumika Goyal
---
I was not able to
Hi Edgar,
Thank you for the patch.
On Tuesday 15 Aug 2017 12:59:47 Edgar Thier wrote:
> Use flags the device exposes for UVC controls.
In addition to explaining what the patch does, the commit message should
explain why the change is needed. What is the problem you're trying to address
here ?
The first argument of function snd_ctl_new1 is of type const struct
snd_kcontrol_new * but in this file the variable is passed by value to
this function.
This generated ""incompatible type for argument" error. So, pass the
variable by reference.
Signed-off-by: Bhumika Goyal
---
I was not able to
Hi Wolfram,
On Tue, Jul 18, 2017 at 12:23 PM, Wolfram Sang
wrote:
> One helper checks if DMA is suitable and optionally creates a bounce
> buffer, if not. The other function returns the bounce buffer and makes
> sure the data is properly copied back to the message.
>
> Signed-off-by: Wolfram Sang
Hello Sakari,
I haven't looked at the driver, but just have a comment about the I2C subsystem.
On Wed, Aug 16, 2017 at 2:55 PM, Sakari Ailus
wrote:
[snip]
> +
> +static const struct of_device_id as3645a_of_table[] = {
> + { .compatible = "ams,as3645a" },
> + { },
> +};
> +MODULE_DE
Hi everyone,
This set adds support for the AS3645A flash driver which can be found e.g.
in Nokia N9.
The set depeds on the flash patches here so I'd prefer to merge this
through mediatree.
https://git.linuxtv.org/sailus/media_tree.git/log/?h=flash>
Jacek: would that be ok for you?
Since the RF
From: Sakari Ailus
Add the as3645a flash controller to the DT source as well as the flash
property with the as3645a device phandle to the sensor DT node.
Signed-off-by: Sakari Ailus
Reviewed-by: Sebastian Reichel
---
arch/arm/boot/dts/omap3-n9.dts | 1 +
arch/arm/boot/dts/omap3-n950-n9
From: Sakari Ailus
Signed-off-by: Sakari Ailus
---
.../devicetree/bindings/leds/ams,as3645a.txt | 56 ++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/ams,as3645a.txt
diff --git a/Documentation/devicetree/bindings/leds/ams
From: Sakari Ailus
Add a LED flash class driver for the as3654a flash controller. A V4L2 flash
driver for it already exists (drivers/media/i2c/as3645a.c), and this driver
is based on that.
Signed-off-by: Sakari Ailus
---
MAINTAINERS | 6 +
drivers/leds/Kconfig| 8 +
Hi Sakari,
Thank you for the patch.
On Wednesday 16 Aug 2017 15:51:49 Sakari Ailus wrote:
> The CSI PHY is associated with a CSI receiver. The code assumes this
> receiver is a CSI2 module and relies on the CSI2 module object heavily to
> access the ISP or pipeline objects. However, the receiver
The PHY configuration was obtained from DT when the PHY was acquired but
the same was not done when it was released. Fix this.
Signed-off-by: Sakari Ailus
---
drivers/media/platform/omap3isp/ispcsiphy.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/driv
From: Pavel Machek
ISP CSI1 module needs all the bits correctly set to work.
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pavel Machek
Signed-off-by: Sakari Ailus
Tested-by: Laurent Pinchart # on
Beagleboard-xM + MPT9P031
---
drivers/media/platform/omap3isp/ispccp2.c | 7 +--
drivers/
The CSI PHY is associated with a CSI receiver. The code assumes this
receiver is a CSI2 module and relies on the CSI2 module object heavily to
access the ISP or pipeline objects. However, the receiver could also be a
CSI1/CCP2 module.
Pass a new CSI receiver entity pointer to the CSI PHY acquire f
The PHY is still relevant for CCP2.
Signed-off-by: Sakari Ailus
Tested-by: Laurent Pinchart # on
Beagleboard-xM + MPT9P031
---
drivers/media/platform/omap3isp/ispcsiphy.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
b/dri
From: Pavel Machek
Add support for parsing CSI1 configuration.
Signed-off-by: Pavel Machek
Signed-off-by: Sakari Ailus
Reviewed-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
Tested-by: Laurent Pinchart # on
Beagleboard-xM + MPT9P031
---
drivers/media/platform/omap3isp/isp.c | 1
Hi folks,
Here's a respin of the omap3isp ccp2 support patches.
since v1:
- Root out patches already merged or not needed (omapisp: Ignore endpoints
with invalid configuration).
- Rework the patch skipping CSI-2 receiver configuration for CCP2
("omap3isp: Skip CSI-2 receiver initialisation
The patches depend on the ccp2 patches here:
https://git.linuxtv.org/sailus/media_tree.git/log/?h=ccp2>
On Wed, Aug 16, 2017 at 02:20:17PM +0300, Sakari Ailus wrote:
> Hi folks,
>
> We have a large influx of new, unmerged, drivers that are now parsing
> fwnode endpoints and each one of them is d
Hi Stan,
On Wednesday 16 Aug 2017 14:46:50 Stanimir Varbanov wrote:
> On 08/15/2017 01:04 PM, Hans Verkuil wrote:
> > On 08/14/17 10:41, Stanimir Varbanov wrote:
> >> Hi,
> >>
> >> This RFC patch is intended to give to the drivers a choice to change
> >> the default behavior of the v4l2-core DMA
Some CSI-2 transmitters will finish an ongoing frame whereas others will
not. Document that receiver drivers should not assume a particular
behaviour but to work in both cases.
Signed-off-by: Sakari Ailus
---
Documentation/media/kapi/csi2.rst | 10 ++
1 file changed, 10 insertions(+)
di
As we begin to add support for systems with Media controller pipelines
controlled by more than one device driver, it is essential that we
precisely define the responsibilities of each component in the stream
control and common practices.
Specifically, streaming control is done per sub-device and s
Hi folks,
I've updated the patch documenting the s_stream() video op calling for MC
enabled devices based on the review comments.
since v1:
- Split "stopping the transmitter" documentation to a separate patch and move
it to
csi2.rst which is a better place for it.
- Precise that the added s_
On 03.08.2017 10:28, Hans Verkuil wrote:
> Hi Maciej,
>
> Unfortunately I do not have the MHL spec, but I was wondering what the
> relationship between RCP and CEC is. CEC has remote control support as
> well, so is RCP that subset of the CEC specification or is it completely
> separate?
We also d
Hi Hans,
On 08/15/2017 01:04 PM, Hans Verkuil wrote:
> On 08/14/17 10:41, Stanimir Varbanov wrote:
>> Hi,
>>
>> This RFC patch is intended to give to the drivers a choice to change
>> the default behavior of the v4l2-core DMA mapping direction from
>> DMA_TO/FROM_DEVICE (depending on the buffer ty
The current practice is that drivers iterate over their endpoints and
parse each endpoint separately. This is very similar in a number of
drivers, implement a generic function for the job. Driver specific matters
can be taken into account in the driver specific callback.
Convert the omap3isp as an
Hi folks,
(Resending, got Niklas's e-mail wrong.)
We have a large influx of new, unmerged, drivers that are now parsing
fwnode endpoints and each one of them is doing this a little bit
differently. The needs are still exactly the same for the graph data
structure is device independent. This is st
This is the preferred way to parse the endpoints.
Signed-off-by: Sakari Ailus
---
drivers/media/v4l2-core/v4l2-fwnode.c | 51 +++
include/media/v4l2-fwnode.h | 7 +
2 files changed, 58 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.
Hi folks,
We have a large influx of new, unmerged, drivers that are now parsing
fwnode endpoints and each one of them is doing this a little bit
differently. The needs are still exactly the same for the graph data
structure is device independent. This is still a non-trivial task and the
majority o
This is the preferred way to parse the endpoints.
Signed-off-by: Sakari Ailus
---
drivers/media/v4l2-core/v4l2-fwnode.c | 51 +++
include/media/v4l2-fwnode.h | 7 +
2 files changed, 58 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.
The current practice is that drivers iterate over their endpoints and
parse each endpoint separately. This is very similar in a number of
drivers, implement a generic function for the job. Driver specific matters
can be taken into account in the driver specific callback.
Convert the omap3isp as an
Em Tue, 15 Aug 2017 20:51:09 +0100
Jemma Denson escreveu:
> Hi Mauro,
>
> On 13/08/17 20:35, Mauro Carvalho Chehab wrote:
>
> > This Kaffeine's BZ:
> > https://bugs.kde.org/show_bug.cgi?id=374693
> >
> > affects SkyStar S2 PCI DVB-S/S2 rev 3.3 device. It could be due to
> > a Kernel bug.
>
Make this const as it is only used during a copy operation.
Done using Coccinelle.
Signed-off-by: Bhumika Goyal
---
drivers/media/pci/solo6x10/solo6x10-g723.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/solo6x10/solo6x10-g723.c
b/drivers/media/pci/solo6
Make this const as it only passed as the 1st argument to the function
snd_ctl_new1, which is of type const.
Done using Coccinelle.
Signed-off-by: Bhumika Goyal
---
drivers/media/pci/cx88/cx88-alsa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx88/cx88-a
Make these const. Done using Coccinelle.
Bhumika Goyal (2):
[media] cx88: make snd_kcontrol_new const
[media] solo6x10: make snd_kcontrol_new const
drivers/media/pci/cx88/cx88-alsa.c | 2 +-
drivers/media/pci/solo6x10/solo6x10-g723.c | 2 +-
2 files changed, 2 insertions(+), 2 deleti
On 08/04/2017 12:41 PM, Hans Verkuil wrote:
Use the new CEC_CAP_DEFAULTS define in the s5p-cec driver.
Signed-off-by: Hans Verkuil
Acked-by: Sylwester Nawrocki
On 08/04/2017 12:41 PM, Hans Verkuil wrote:
The CEC_CAP_LOG_ADDRS, CEC_CAP_TRANSMIT, CEC_CAP_PASSTHROUGH and
CEC_CAP_RC capabilities are normally always present.
Add a CEC_CAP_DEFAULTS define that ORs these four caps to simplify
drivers.
Signed-off-by: Hans Verkuil
Reviewed-by: Sylwester Naw
On Wed, Aug 16, 2017 at 10:13:05AM +0200, Pavel Machek wrote:
> On Wed 2017-08-16 10:33:45, Sakari Ailus wrote:
> > The et8ek8 driver combines I²C register writes to a single array that it
> > passes to i2c_transfer(). The maximum number of writes is 48 at once,
> > decrease it to 8 and make more t
On Wed 2017-08-16 10:33:45, Sakari Ailus wrote:
> The et8ek8 driver combines I²C register writes to a single array that it
> passes to i2c_transfer(). The maximum number of writes is 48 at once,
> decrease it to 8 and make more transfers if needed, thus avoiding a
> warning on stack usage.
Dunno.
From: Yasunari Takiguchi
I add an e-mail address and re-send this mail again.
This is MAINTAINERS file update about the driver for
the Sony CXD2880 DVB-T2/T tuner + demodulator.
[Change list]
Changes in V3
MAINTAINERS
-no change
Signed-off-by: Yasunari Takiguchi
Signed-off-by: Masayu
The et8ek8 driver combines I²C register writes to a single array that it
passes to i2c_transfer(). The maximum number of writes is 48 at once,
decrease it to 8 and make more transfers if needed, thus avoiding a
warning on stack usage.
Signed-off-by: Sakari Ailus
---
Pavel: this is just compile te
On 08/10/2017 10:33 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Document the bindings for the cec-gpio module for hardware where the
> CEC pin is connected to a GPIO pin.
No need to review this, there will be a v3 that will add a second optional
HPD gpio.
Regards,
Hans
>
> Signe
The free_irq() function could be called from interrupt context,
which is invalid. Move this to the thread.
In the interrupt handler we just request that the thread disables
the irq. This is done through an atomic so we don't need to add
any spinlocks.
Signed-off-by: Hans Verkuil
---
drivers/med
61 matches
Mail list logo
