Hi Jacopo,
There's still a s/dealy/delay/ in $SUBJECT
On 12/04/2021 10:34, Jacopo Mondi wrote:
> Add a delay after the OV490 chip is put in reset state. The reset
> signal shall be held for at least 250 useconds.
>
> Signed-off-by: Jacopo Mondi
I added this on v3...
Reviewe
gly.
>
> Fixes: 34009bffc1c6 ("media: i2c: Add RDACM20 driver")
> Fixes: e9f817689789 ("media: dt-bindings: media: i2c: Add bindings for IMI
> RDACM2x")
> Signed-off-by: Mauro Carvalho Chehab
Indeed, confirmed,
Reviewed-by: Kieran Bingham
> ---
> MAINTAIN
Hi Geert,
On 29/03/2021 09:30, Geert Uytterhoeven wrote:
> Hi Kieran,
>
> On Mon, Mar 22, 2021 at 6:20 PM Kieran Bingham
> wrote:
>> Three general purpose LEDs are provided on the Falcon CPU board.
>>
>> Connect GP_LED1, GP_LED2, and GP_LED3 to the gpio-leds f
Three general purpose LEDs are provided on the Falcon CPU board.
Connect GP_LED1, GP_LED2, and GP_LED3 to the gpio-leds frameworks as
indicator LEDs.
These LEDs are arranged in a block of four LEDs on the board itself, but
the fourth LED is as yet unidentified.
Signed-off-by: Kieran Bingham
before
using the OV490.
Perhaps possible to update the comment a little, but nothing that matters.
Reviewed-by: Kieran Bingham
> ret = max9271_configure_gmsl_link(>serializer);
> if (ret)
>
On 15/03/2021 13:15, Jacopo Mondi wrote:
> Re-phrase a comment in .bound() callback to make it clear we register
> a subdev notifier and remove a redundant comment about disabling i2c
> auto-ack.
>
> No functional changes intended.
>
> Signed-off-by: Jacopo Mondi
Review
uot;)
> Signed-off-by: Jacopo Mondi
Reviewed-by: Kieran Bingham
> ---
> drivers/media/i2c/rdacm21.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/rdacm21.c b/drivers/media/i2c/rdacm21.c
> index 50a9b0d8255d..07cf077d8efd 100644
>
640 ID mismatch: (0x01)
>
> Fixes: a59f853b3b4b ("media: i2c: Add driver for RDACM21 camera module")
> Signed-off-by: Jacopo Mondi
Sometime it might be nice to see this look more like the GPIO
interfaces, but I think this is fine for now.
Reviewed-by: Kieran Bingham
>
tainly a good thing to fix here.
Reviewed-by: Kieran Bingham
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/max9271.c | 7 +++
> drivers/media/i2c/max9271.h | 9 +
> drivers/media/i2c/rdacm20.c | 2 +-
> drivers/media/i2c/rdacm21.c | 3 +--
> 4 files chan
arly.
Reviewed-by: Kieran Bingham
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/max9271.c | 30 +++---
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/i2c/max9271.c b/drivers/media/i2c/max9271.c
> ind
it with a more compact for() loop.
>
> No functional changes intended.
>
> Reviewed-by: Kieran Bingham
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/rdacm20.c | 29 +
> 1 file changed, 13 inse
ll its users in the driver.
>
> Reviewed-by: Kieran Bingham
Still holds ;-)
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/rdacm20.c | 38 -
> 1 file changed, 16 insertions(+), 22 deletions(-)
>
>
the sparse warning replacing
> the cast with a bitwise & operation.
>
> Reported-by: Hans Verkuil
> Signed-off-by: Jacopo Mondi
Sounds good to me.
Reviewed-by: Kieran Bingham
> ---
> drivers/media/i2c/rdacm21.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On 05/03/2021 14:10, Geert Uytterhoeven wrote:
> Hi Kieran,
>
> On Thu, Mar 4, 2021 at 5:53 PM Kieran Bingham
> wrote:
>> Three general purpose LEDs are provided on the Falcon CPU board.
>>
>> Connect GP_LED1, GP_LED2, and GP_LED3 to the gpio-leds framewor
Three general purpose LEDs are provided on the Falcon CPU board.
Connect GP_LED1, GP_LED2, and GP_LED3 to the gpio-leds frameworks.
These LEDs are arranged in a block of four LEDs on the board itself, but
the fourth LED is as yet unidentified.
Signed-off-by: Kieran Bingham
---
arch/arm64/boot
t;>
>>> On Wed, Feb 17, 2021 at 01:01:26PM +, Kieran Bingham wrote:
>>>> On 16/02/2021 17:41, Jacopo Mondi wrote:
>>>>> During the camera module initialization the image sensor PID is read to
>>>>> verify it can correctly be identified. T
Hi Barry
On 21/02/2021 21:35, Barry Song wrote:
> lx_current depends on the per_cpu current_task which exists on x86 only:
>
> arch$ git grep current_task | grep -i per_cpu
> x86/include/asm/current.h:DECLARE_PER_CPU(struct task_struct *, current_task);
>
- should that be made more
distinct?
- Seeing the duplication of the MAX9271_DEFAULT_ADDR / ping again
really makes me want to see that wrapped in the max9271.c ;-)
- Likely needs squashed with relevant changes in max9286?
But even with those thoughts, I don't think this is necessarily wrong
On 16/02/2021 17:41, Jacopo Mondi wrote:
> With the camera modules initialization routines now running with
> the noise immunity threshold enabled, it is possible to restore
> the bit rate of the I2C transactions transported on the GMSL control
> channel to 339 Kbps.
>
> The 339 Kbps bit rate
ile fail, but it would fail a test (if bisecting
was testing the capture).
Seems to look ok, given the previous patch as a dependency:
Reviewed-by: Kieran Bingham
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/max9286.c | 24 +++-
> 1 file changed, 19
On 16/02/2021 17:41, Jacopo Mondi wrote:
> Re-phrase a comment in .bound() callback to make it clear we register
> a subdev notifier and remove a redundant comment about disabling i2c
> auto-ack.
>
> No functional changes intended.
>
> Signed-off-by: Jacopo Mondi
> ---
>
Hi Jacopo,
On 16/02/2021 17:41, Jacopo Mondi wrote:
> Provide a macro to define the reverse channel amplitude to
> be used to compensate the remote serializer noise immunity.
>
> While at it, update a comment.
Reviewed-by: Kieran Bingham
>
> Signed-off-by: Jacopo Mondi
ide of the call :-)
Reviewed-by: Kieran Bingham
> ---
> drivers/media/i2c/max9286.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/i2c/max9286.c b/drivers/media/i2c/max9286.c
> index 1f14cd817fbf..4afb5ca06448 100644
> --- a
ore this now, but I can't see an easy way to factor out the
initialisation value, and I like the idea of caching the current stored
value.
So
Reviewed-by: Kieran Bingham
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/max9286.c | 10 +-
> 1 file changed, 5 insertions(+),
Hi Jacopo,
On 16/02/2021 17:41, Jacopo Mondi wrote:
> The OV10640 image sensor reset and powerdown on signals are controlled
> by the embedded OV490 ISP. The current reset procedure does not respect
> the 1 millisecond power-up delay and releases the reset signal before
> the powerdown one.
>
>
On 16/02/2021 17:41, Jacopo Mondi wrote:
> The parameters to max9286_i2c_mux_configure() fits on the previous
> line. Adjust it.
>
> Cosmetic change only.
Cosmetic tag ;-)
Reviewed-by: Kieran Bingham
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/max92
s 'probe' anyway, so it's likely
better handled down there...?
But ... it's not essential at this point in the series, so if you want
to keep this patch as is,
Reviewed-by: Kieran Bingham
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/rdacm20.c | 1 +
> drivers/media/i2
635 in reset earlier sounds good to me, but I don't know
beyond that what implications there would be. If it's working better
that's good though.
Reviewed-by: Kieran Bingham
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/rdacm20.c | 25 +++--
> 1 file
Hi Jacopo,
On 16/02/2021 17:41, Jacopo Mondi wrote:
> The camera module initialization routine does not check the return
> value of a few functions. Fix that.
>
Sounds quite valid to me.
Reviewed-by: Kieran Bingham
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/
lieve i've seen occur), it will retry.
Because there is a functional change you might want to update the
commit, but I still think this is a good change overall.
Reviewed-by: Kieran Bingham
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/rdacm20.c | 27 ++--
ripts that rely on this string to know if the
camera was found ... but I can fix that ;-)
Reviewed-by: Kieran Bingham
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/rdacm20.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/r
MAX9271_GPIO1OUT);
> + ret = max9271_set_gpios(>serializer, MAX9271_GPIO1OUT);
> if (ret)
> return ret;
> usleep_range(10000, 15000);
> @@ -560,13 +560,7 @@ static int rdacm20_probe(struct i2c_client *client)
> if (!dev)
> return -ENOMEM;
&g
omehow?
I guess we can't keep 'test bisectability' with this very easily so it
probably doesn't matter too much, the end result will be the interesting
part.
Reviewed-by: Kieran Bingham
> }
>
> static int rdacm20_probe(struct i2c_client *client)
>
On 20/01/2021 10:36, Sakari Ailus wrote:
> On Wed, Jan 20, 2021 at 10:17:14AM +0000, Kieran Bingham wrote:
>> Hi Lad,
>>
>> On 20/01/2021 09:01, Lad Prabhakar wrote:
>>> Fix OV772x build breakage by selecting V4L2_FWNODE config:
>>>
>>> ia64-l
; Reported-by: kernel test robot
> Signed-off-by: Lad Prabhakar
I see this driver uses subdev API too.
Should the driver also select VIDEO_V4L2_SUBDEV_API?
Or is that covered sufficiently already on any platforms that would use
the driver?
Reviewed-by: Kieran Bingham
> ---
> drivers
Hi Daniel,
On 18/01/2021 00:34, Daniel Scally wrote:
> ACPI devices with _HID INT3472 are currently matched to the tps68470
> driver, however this does not cover all situations in which that _HID
> occurs. We've encountered three possibilities:
>
> 1. On Chrome OS devices, an ACPI device with
et = -EINVAL;
>
> if (!(vdev->device_caps & V4L2_CAP_IO_MC))
> p->mbus_code = 0;
>
> mbus_code = p->mbus_code;
> CLEAR_AFTER_FIELD(p, type);
So would that mean ^^^ should also be sufficient to remove the need for
that memset?
: Ricardo Ribalda
Reviewed-by: Kieran Bingham
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> index 724c7333b6e5..a
Hi Ricardo,
On 11/01/2021 14:54, Ricardo Ribalda wrote:
> Core code already clears reserved fields of struct
> v4l2_pix_format_mplane, check: 4e1e0eb0e074 ("media: v4l2-ioctl: Zero
> v4l2_plane_pix_format reserved fields").
>
> Cc: Sakari Ailus
> Signed-off-by: Ricardo Ribalda
This is just
: Ricardo Ribalda
Reviewed-by: Kieran Bingham
> ---
> drivers/media/pci/intel/ipu3/ipu3-cio2.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> index 36e354ecf71e..c5376de8cb8a 1006
;reserved, 0, sizeof(f->reserved));
I can't yet see anything that clears the reserved formats on queue
initialisations, so I don't think we can remove that yet unless I've
missed something anyway.
Seems like there is a lot more that could be cleared in core ...
But - as I said, I think that's
: Ricardo Ribalda
Reviewed-by: Kieran Bingham
> ---
> drivers/media/test-drivers/vicodec/vicodec-core.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/media/test-drivers/vicodec/vicodec-core.c
> b/drivers/media/test-drivers/vicodec/vicodec-core.c
> index
Hi Ricardo,
On 11/01/2021 14:54, Ricardo Ribalda wrote:
> Core code already clears reserved fields of struct
> v4l2_pix_format_mplane, check: 4e1e0eb0e074 ("media: v4l2-ioctl: Zero
> v4l2_plane_pix_format reserved fields").
Reviewed-by: Kieran Bingham
> Cc: Benoi
lds").
Indeed, these are the only memsets here ...
With the $TITLE fixed as spotted by Ezequiel,
Reviewed-by: Kieran Bingham
>
> Cc: Maxime Ripard
> Cc: Chen-Yu Tsai
> Signed-off-by: Ricardo Ribalda
> ---
> drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c |
c
> +++ b/drivers/media/platform/rcar_jpu.c
There's a memset(cap->reserved...) in jpu_querycap()
Is that also applicable and covered by the core?
Looking at v4l_querycap() it doesn't seem to be so:
Reviewed-by: Kieran Bingham
> @@ -793,7 +793,6 @@ static int __jpu_try_fmt(struct jpu_c
> Signed-off-by: Ricardo Ribalda
I love a good cleanup series.
Reviewed-by: Kieran Bingham
> ---
> drivers/media/platform/rcar_fdp1.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/media/platform/rcar_fdp1.c
> b/drivers/media/platform/rcar_fd
Hi Dan,
On 04/01/2021 22:02, Daniel Scally wrote:
>>>>> On 04/01/2021 13:35, Kieran Bingham wrote:
>>>>>>> +/*
>>>>>>> + * Extend this array with ACPI Hardware IDs of devices known to be
>>>>>>> working
>>>
Hi Dan,
On 04/01/2021 15:31, Daniel Scally wrote:
> Hi Kieran
>
> On 04/01/2021 15:13, Kieran Bingham wrote:
>> Hi Dan,
>>
>> On 04/01/2021 13:55, Daniel Scally wrote:
>>> Hi Kieran
>>>
>>> On 04/01/2021 13:35, Kieran Bingham wrote:
>&g
Hi Dan,
On 04/01/2021 13:55, Daniel Scally wrote:
> Hi Kieran
>
> On 04/01/2021 13:35, Kieran Bingham wrote:
>>> +/*
>>> + * Extend this array with ACPI Hardware IDs of devices known to be working
>>> + * plus the number of link-frequenc
}
> +
> + if (obj->buffer.length > size) {
> + dev_err(>dev, "Given buffer is too small\n");
> + ret = -EINVAL;
> + goto out_free_buff;
> + }
> +
> + memcpy(data, obj->buffer.pointer, obj->buffer.length)
Hi Christophe,
On 12/12/2020 17:41, Christophe JAILLET wrote:
> A previous 'rcar_fcp_get()' call must be undone in the error handling path,
> as already done in the remove function.
Reviewed-by: Kieran Bingham
> Fixes: 94fcdf829793 ("[media] v4l: vsp1: Add FCP support&
Hi Daniel,
On 30/11/2020 13:31, Daniel Scally wrote:
> On platforms where ACPI is designed for use with Windows, resources
> that are intended to be consumed by sensor devices are sometimes in
> the _CRS of a dummy INT3472 device upon which the sensor depends. This
> driver binds to the dummy
Hi Tom,
On 27/11/2020 17:58, t...@redhat.com wrote:
> From: Tom Rix
>
> The macro use will already have a semicolon.
>
> Signed-off-by: Tom Rix
Seems to be the only occurrence in this file.
Reviewed-by: Kieran Bingham
> ---
> drivers/net/wireless/cisco/airo.c | 2 +-
ink being explicit is a good thing anyway.
Reviewed-by: Kieran Bingham
> ---
> drivers/media/i2c/rdacm20.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/i2c/rdacm20.c b/drivers/media/i2c/rdacm20.c
> index 1ed928c4ca70..1
ked as reserved.
>
> Fixes: 34009bffc1c6 ("media: i2c: Add RDACM20 driver")
> Signed-off-by: Jacopo Mondi
Took me a few reads of this and the datasheet to be sure :S
But now I am :-D
Reviewed-by: Kieran Bingham
> ---
> drivers/media/i2c/max9271.c | 8
> 1
s address to
> v4l2_i2c_subdev_init() which accepts a pointer to const. Make them const
> to allow the compiler to put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
Reviewed-by: Kieran Bingham
> ---
> drivers/media/i2c/rdacm20.c | 4 ++--
> 1 file changed, 2 insertions(+),
f-by: Jacopo Mondi
Tested-by: Kieran Bingham
Reviewed-by: Kieran Bingham
> ---
> arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi
> b/arch/arm64/boot/dts/ren
.
>
> Kieran, I know you have a working setup with RDACM20, the final patches are
> meant for ease your testing. Can you give this series a spin ?
After some rabbit-holes :-D:
A 5-camera capture on Salvator-X - https://pasteboard.co/JAW0PSr.png
For this series, on both Eagle-V3M and Salvator-X
On 17/11/2020 13:36, Jacopo Mondi wrote:
> Hi Kieran,
>
> On Mon, Nov 16, 2020 at 02:47:49PM +0000, Kieran Bingham wrote:
>> On 16/11/2020 13:52, Jacopo Mondi wrote:
>>> The RDACM21 is a GMSL camera supporting 1280x1080 resolution images
>>> developed by IMI base
@@ -14750,6 +14750,18 @@ F: drivers/media/i2c/max9271.c
> F: drivers/media/i2c/max9271.h
> F: drivers/media/i2c/rdacm20.c
>
> +RDACM21 Camera Sensor
> +M: Jacopo Mondi
> +M: Kieran Bingham
> +M: Laurent Pinchart
> +M: Niklas Söderlund
> +L: linux-me
On 16/11/2020 10:03, Jacopo Mondi wrote:
> Hi Laurent,
>
> On Mon, Nov 16, 2020 at 11:08:33AM +0200, Laurent Pinchart wrote:
>> Hi Jacopo,
>>
>> On Sat, Nov 14, 2020 at 03:04:57PM +0100, Jacopo Mondi wrote:
>>> On Thu, Nov 12, 2020 at 10:31:05PM +,
y probed when used in combination with
> the max9286 deserializer.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Kieran Bingham
> ---
> drivers/media/i2c/max9286.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/i
additionalProperties: false
>
> @@ -243,6 +264,8 @@ examples:
> gpio-controller;
> #gpio-cells = <2>;
>
> +maxim,initial-reverse-channel-mV = <170>;
> +
Sounds good to me.
Reviewed-by: Kieran Bingham
> ports {
>#address-cells = <1>;
>#size-cells = <0>;
>
RS
> @@ -14750,6 +14750,18 @@ F: drivers/media/i2c/max9271.c
> F: drivers/media/i2c/max9271.h
> F: drivers/media/i2c/rdacm20.c
>
> +RDACM21 Camera Sensor
> +M: Jacopo Mondi
> +M: Kieran Bingham
> +M: Laurent Pinchart
> +M: Niklas Söderlund
> +L:
Hi Jacopo,
On 16/10/2020 14:04, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Fri, Oct 16, 2020 at 2:56 PM Jacopo Mondi wrote:
>> On Fri, Oct 16, 2020 at 01:50:34PM +0200, Geert Uytterhoeven wrote:
>>> On Fri, Oct 16, 2020 at 12:09 PM Jacopo Mondi
>>> wrote:
Document the
for both rdacm20 and rdacm21 camera modules
> to be correctly probed when used in combination with the max9286
> deserializer.
My only fear here would be that perhaps on other cameras we need a more
fine-grained control of the amplitudes?
But I'll leave that discussion to the binding itself
/* It is not possible express values (100 < x < 130) */
'possible to express'
> + chan_amplitude = chan_amplitude < 130
> +? 30 : chan_amplitude - 100;
We could round < 115 to 100, and >= 115 to 130, but that's probably more
effort that it's worth, so I think
MP_X);
> + usleep_range(2000, 2500);
> +}
This gets moved later on in the same series. It's probably better to put
it in the right place now.
With that,
Reviewed-by: Kieran Bingham
> +
> static int max9286_setup(struct max9286_priv *priv)
> {
> /*
> @
Hi Jacopo,
On 15/10/2020 19:27, Jacopo Mondi wrote:
> Adjust reverse channel amplitude according to the presence of
> the 'high-threshold" DTS property.
>
> If no high threshold compensation is required, start with a low
> amplitude (100mV) and increase it after the remote serializers
> have
Hi Hans,
On 14/10/2020 12:23, Hans de Goede wrote:
> Hi,
>
> On 10/14/20 1:09 PM, Kieran Bingham wrote:
>> Hi Hans, Sasha,
>>
>> As mentioned on https://github.com/linux-surface/kernel/issues/63, I'm
>> afraid I've bisected a boot time issue on the Microso
Hi Hans, Sasha,
As mentioned on https://github.com/linux-surface/kernel/issues/63, I'm
afraid I've bisected a boot time issue on the Microsoft Surface Go 2 to
this commit on the stable 5.8 tree.
The effect as reported there is that the boot process stalls just after
loading the usbhid module.
On 23/09/2020 14:13, George Prekas wrote:
> Hi Kieran,
>
> On 9/22/2020 2:11 PM, Kieran Bingham wrote:
>> Hi George,
>>
>> On 22/09/2020 18:17, Prekas, George wrote:
>>>
>>> On 9/22/2020 9:32 AM, Jan Kiszka wrote:
>>>>
>>>> On 2
Hi George,
On 22/09/2020 18:17, Prekas, George wrote:
>
> On 9/22/2020 9:32 AM, Jan Kiszka wrote:
>>
>> On 22.09.20 16:28, George Prekas wrote:
>>> If the next pointer is NULL, list_for_each gets stuck in an infinite
>>> loop.
>>>
>>> Signed-off-by: George Prekas
>>> ---
>>>
Hi Andy,
On 17/09/2020 15:08, Andy Shevchenko wrote:
> On Thu, Sep 17, 2020 at 4:31 PM Kieran Bingham
> wrote:
>> On 17/09/2020 10:47, Dan Scally wrote:
>>> On 17/09/2020 08:53, Greg KH wrote:
>>>> On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote
Hi Dan, Greg,
On 17/09/2020 10:47, Dan Scally wrote:
> Hi Greg - thanks for the comments, appreciate it (sorry there's so many,
> I'm new to both C and kernel work)
>
> On 17/09/2020 08:53, Greg KH wrote:
>> On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote:
>>> MAINTAINERS
Hi Dan,
On 16/09/2020 14:22, Dan Scally wrote:
> Hi Sakari - thanks for the comments
>
> On 16/09/2020 10:17, Sakari Ailus wrote:
>> Moi Daniel and Heikki,
>>
>> On Wed, Sep 16, 2020 at 12:28:27AM +0100, Daniel Scally wrote:
>>> From: Heikki Krogerus
>>>
>>> This implements the remaining
On 25/08/2020 05:56, Joe Perches wrote:
> Use semicolons and braces.
>
> Signed-off-by: Joe Perches
Reviewed-by: Kieran Bingham
> ---
> drivers/staging/media/atomisp/pci/atomisp_subdev.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git
ight;
> base3= base2 + bpl_uv * lines_uv;
> - if (dev->fmt->uvswap)
> - tmp = base2, base2 = base3, base3 = tmp;
> + if (dev->fmt->uvswap) {
> + tmp = base2;
&
Hi Joe,
Nice, I only see three of these on the linux-media list, so I'll only
look at those, but I'm pleased to see this is treewide ;-)
Definitely prefer this.
On 25/08/2020 05:56, Joe Perches wrote:
> Use semicolons and braces.
>
> Signed-off-by: Joe Perches
Reviewed-by: Kiera
On 27/08/2020 15:53, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu
>
> Add FDP1 device nodes to R8A774E1 (RZ/G2H) SoC dtsi.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Kieran Bingham
I'd really love to know if peopl
Hi Kaaira,
Thank you for this series.
I have tested it, and indeed it works well, which is great work.
I know this has been hard to debug some of the code paths!
There are a few bits that are hard for me to understand, with the graph
walking/initialisation - so I think either some better
Hi Kaaira,
On 19/08/2020 19:04, Kaaira Gupta wrote:
> If multiple captures try to enable stream, start their stream but do not
> initialise the pipeline again. Also, don't start the thread separately.
> Starting their streams will update the use count and their frames would
> be processed by the
Hi Kaaira,
On 19/08/2020 19:04, Kaaira Gupta wrote:
> Start another capture, if one is already running, by checking for
> existing pipe. If it exists already, don't fail to start second capture,
> instead join it to the already running pipeline.
> Use the same stream struct used by already
Hi Kaaira,
On 19/08/2020 19:04, Kaaira Gupta wrote:
> Multiple streams will share same stream struct if we want them to run on
> same thread. So remove it from vimc_cap struct so that it doesn't get
> destroyed when one of the capture does, and allocate it memory
> dynamically. Use kref with it
Hi Kaaira,
On 19/08/2020 19:04, Kaaira Gupta wrote:
> Make separate functions for stopping streaming of entities in path of a
> particular stream and stopping thread. This is needed to ensure that
> thread doesn't stop when one device stops streaming in case of multiple
> streams.
>
>
Hi Kaaira, Dafna,
On 28/08/2020 21:37, Dafna Hirschfeld wrote:
> Hi,
>
> Am 21.08.20 um 23:01 schrieb Kaaira Gupta:
>> Hi,
>>
>> On Fri, Aug 21, 2020 at 05:11:23PM +0200, Dafna Hirschfeld wrote:
>>>
>>>
>>> Am 19.08.20 um 20:04 schrieb Kaaira Gupta:
Separate the process of initialising
Hi Mauro,
I see the fixes branch is open now ... could you pick this one up
please? Or do I need to send a pull request?
--
Regards
Kieran
On 16/07/2020 11:25, Kieran Bingham wrote:
> The files maintained as part of the RDACM20 were incorrectly sorted
> while they were added.
>
Hi Alex,
On 18/06/2020 17:32, Kieran Bingham wrote:
> Hi Alex,
>
> On 02/04/2020 19:35, Alex Riesen wrote:
>> As all known variants of the Salvator board have the HDMI decoder
>> chip (the ADV7482) connected to the SSI4 on R-Car SoC, the ADV7482
>> endpoint and
Hi Petr,
On 21/08/2020 09:55, Jan Kiszka wrote:
> On 21.08.20 10:08, Petr Mladek wrote:
>> On Fri 2020-08-14 23:31:23, John Ogness wrote:
>>> Hi,
>>>
>>> When we brought in the new lockless printk ringbuffer, we overlooked the gdb
>>> scripts. Here are a set of patches to implement gdb support
et_source_entity() moving patch.
But it does show that vimc_get_source_entity() can return NULL which
might have to be checked... though perhaps we 'know' it will always be
valid ...
Also, following the links for each entity, for each frame sounds like
quite a lot of work. I wonder if the
Hi Kaaira,
On 19/08/2020 19:04, Kaaira Gupta wrote:
> Move the function vimc_get_source_entity() to vimc-common.c to make it
> reusable.
>
> Signed-off-by: Kaaira Gupta
Reviewed-by: Kieran Bingham
> ---
> drivers/media/test-drivers/vimc/vimc-common.c | 14 +++
>
Hi Randy,
On 13/08/2020 19:35, Randy Dunlap wrote:
> On 8/12/20 11:58 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> News: The merge window has opened, so please do not add any v5.10
>> related material to your linux-next included branches until after the
>> merge window closes again.
>>
>> Changes
Hi Kaaira,
On 31/07/2020 18:22, Kaaira Gupta wrote:
> Hi everyone,
>
> On Wed, Jul 29, 2020 at 05:24:25PM +0200, Dafna Hirschfeld wrote:
>>
>>
>> On 29.07.20 15:27, Kieran Bingham wrote:
>>> Hi Dafna, Kaaira,
>>>
>>> On 29/07/2020 14:16, Da
Hi Dafna, Kaaira,
On 29/07/2020 14:16, Dafna Hirschfeld wrote:
>
>
> On 29.07.20 15:05, Kieran Bingham wrote:
>> Hi Dafna,
>>
>> On 28/07/2020 15:00, Dafna Hirschfeld wrote:
>>>
>>>
>>> On 28.07.20 14:07, Dafna Hirschfeld wrote:
&
Hi Dafna,
On 28/07/2020 15:00, Dafna Hirschfeld wrote:
>
>
> On 28.07.20 14:07, Dafna Hirschfeld wrote:
>> Hi
>>
>> On 28.07.20 13:39, Kaaira Gupta wrote:
>>> On Mon, Jul 27, 2020 at 02:54:30PM -0300, Helen Koike wrote:
>>>> Hi,
>>>>
Hi Stefano,
On 27/07/2020 15:37, Stefano Garzarella wrote:
> On Mon, Jul 27, 2020 at 03:26:42PM +0100, Kieran Bingham wrote:
>> Hi Greg, Sasha,
>>
>> On 27/07/2020 15:04, Greg Kroah-Hartman wrote:
>>> From: Stefano Garzarella
>>>
>>> [ Upstream
Hi all,
+Dafna for the thread discussion, as she's missed from the to/cc list.
On 24/07/2020 13:21, Kaaira Gupta wrote:
> On Fri, Jul 24, 2020 at 02:15:21PM +0200, Niklas Söderlund wrote:
> Hi,
>
>> Hi Kaaira,
>>
>> Thanks for your work.
>
> Thanks for yours :D
>
>>
>> On 2020-07-24 17:32:10
Stefano Garzarella
> Signed-off-by: Andrew Morton
> Reviewed-by: Jan Kiszka
> Reviewed-by: Kieran Bingham
> Link: http://lkml.kernel.org/r/20200722102239.313231-1-sgarz...@redhat.com
> Signed-off-by: Linus Torvalds
> Signed-off-by: Sasha Levin
> ---
> scripts/gdb/linux/s
Hi Sakari,
On 23/07/2020 23:28, Sakari Ailus wrote:
> Hi Kieran,
>
> On Thu, Jul 16, 2020 at 10:02:24AM +0100, Kieran Bingham wrote:
>> Hi Sakari,
>>
>> This is the output of checkpatch --strict on this driver. Sorry for not
>> detailing this in the commit
n Python: There is no member named name.
>>
>> This patch fixes the issue taking the module name from the 'struct
>> attribute'.
>>
It might not be needed if this gets in to v5.8 in time, but perhaps:
Fixes: ed66f991bb19 ("module: Refactor section attr into bin attr
1 - 100 of 1162 matches
Mail list logo
