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...
Re
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
But it's 250 uS 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(&dev->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
era module")
> 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..07cf077d8
OV10640 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
nly 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
y.
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
> index c4955
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 insert
field and adjust all 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(+), 2
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 frameworks.
&
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);
> x86/kernel/cpu/common.c:DEFINE_PER_CPU(st
_init and _initialise - 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 thin
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 repr
ompile 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
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
> ---
> drivers/media/i2c/max92
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 inser
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.
>
> F
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
ld have to be done in it'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
> ---
> driver
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 +++-
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/
which I believe 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 +
ts 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
ge(1, 15000);
>
> - ret = max9271_set_gpios(dev->serializer, MAX9271_GPIO1OUT);
> + ret = max9271_set_gpios(&dev->serializer, MAX9271_GPIO1OUT);
> if (ret)
> return ret;
> usleep_range(1, 15000);
> @@ -560,13 +560,7 @@ s
update in max9286 somehow?
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
roperties")
> 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
&g
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 _HI
ret = -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 mem
icardo 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 9/9
icardo 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
t.mpix;
memset(f->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 clea
icardo 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: Benoit P
d fields").
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
> +++ 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(st
> 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_fdp1.c
>
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:
>>&
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-frequencies expected by their
= -ENODEV;
> + goto out_free_buff;
> + }
> +
> + if (obj->buffer.length > size) {
> + dev_err(&adev->dev, "Given buffer is too small\n");
> + ret = -EINVAL;
> + goto out_free_buff;
> + }
> +
> +
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 s
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 acpi
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
ddress 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(+),
Signed-off-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/bo
he DTS file.
>
> 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
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 +,
orrectly 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/drive
+ - maxim,initial-reverse-channel-mV
>
> 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 'maxim,high-thres
r 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 bind
/* 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
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 prob
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 Micr
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.
Ty
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
>>> ---
>>> scripts/gdb/linux/
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 .graph_
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
hift;
> base2= base + bpl * dev->height;
> base3= base2 + bpl_uv * lines_uv;
> - if (dev->fmt->uvswap)
> - tmp = base2, base2 = base3, base3 = tmp;
> + if (dev->fmt->uvswap) {
> +
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
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
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 comment
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 a
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 running
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 as
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.
>
> Signed-off-
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 pipel
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 the
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 for
or each frame sounds like
quite a lot of work. I wonder if the active source entity should be
cached in each VED ...
That could be done on top anyway...
Overall, this looks like it will work, so with comments addressed how
you wish,
Reviewed-by: Kieran Bingham
> +
> memc
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
tor section attr into bin attribute")
> Signed-off-by: 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
&g
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
Error occurred in 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: Refac
1 - 100 of 701 matches
Mail list logo
