Hi all, this patch series implement MIPI rx DPI feature. Please help to review.
This is the v7 version, rebase DT on the latest code,
removed HDCP patch(I'll upload HDCP feature by a new patch).
Any mistakes, please let me know, I'll fix it in the next series.
Change history:
v7:
- Rebase DT
Hi Lucas,
On Mon, 2021-05-17 at 12:52 +0200, Lucas Stach wrote:
> Hi Ezequiel,
>
> Am Sonntag, dem 16.05.2021 um 19:40 -0300 schrieb Ezequiel Garcia:
> > Hi Lucas,
> >
> > On Fri, 2021-04-16 at 12:54 +0200, Lucas Stach wrote:
> > > Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin
This patch fixes checkpatch warning about multiple line dereference.
Signed-off-by: Khoa Tran Minh
---
drivers/staging/rtl8712/rtl8712_xmit.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl8712_xmit.c
b/drivers/staging/rtl8712
ver.
> > >
> > > A few changes and fixes are applied to the A31 CSI controller driver, in
> > > order
> > > to support the MIPI CSI-2 use-case.
> >
> > Besides the compile error for patch 2/16, I also get several other compile
> > e
Hi everyone,
On Fri 15 Jan 21, 21:01, Paul Kocialkowski wrote:
> As some D-PHY controllers support both Rx and Tx mode, we need a way for
> users to explicitly request one or the other. For instance, Rx mode can
> be used along with MIPI CSI-2 while Tx mode can be used with MIPI DSI.
>
>
(for MIPI DSI), a submode is introduced for D-PHY in the PHY
> > API.
> > This allows adding Rx support in the A31 D-PHY driver.
> >
> > A few changes and fixes are applied to the A31 CSI controller driver, in
> > order
> > to support the MIPI CSI-2 use-case.
>
gt;
> A few changes and fixes are applied to the A31 CSI controller driver, in order
> to support the MIPI CSI-2 use-case.
Besides the compile error for patch 2/16, I also get several other compile
errors:
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c: In function
‘sun6i_csi_v4l2_fwnode_ini
Hi,
On Wed 26 May 21, 13:50, Hans Verkuil wrote:
> On 15/01/2021 21:01, Paul Kocialkowski wrote:
> > As some D-PHY controllers support both Rx and Tx mode, we need a way for
> > users to explicitly request one or the other. For instance, Rx mode can
> > be used along with MIPI CSI-2 while Tx mode
On 15/01/2021 21:01, Paul Kocialkowski wrote:
> As some D-PHY controllers support both Rx and Tx mode, we need a way for
> users to explicitly request one or the other. For instance, Rx mode can
> be used along with MIPI CSI-2 while Tx mode can be used with MIPI DSI.
>
> Introduce new MIPI D-PHY
to store the
references frame or tile size data.
This series clashes with this patch:
https://patchwork.linuxtv.org/project/linux-media/patch/20210427071554.625-1-jernej.skra...@siol.net/
and this patch series:
https://patchwork.linuxtv.org/project/linux-media/cover/20210401144336.2495479-1
The hardware require to allocate few auxiliary buffers to store the
>> references frame or tile size data.
>
> This series clashes with this patch:
>
> https://patchwork.linuxtv.org/project/linux-media/patch/20210427071554.625-1-jernej.skra...@siol.net/
>
> and this patch seri
Fixed a coding style issue - add blank after declation
Signed-off-by: Dongkyu Kim
---
drivers/staging/rtl8723bs/core/rtw_cmd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c
b/drivers/staging/rtl8723bs/core/rtw_cmd.c
index
On Sun, May 23, 2021 at 10:21:51AM +0900, Donggyu Kim wrote:
> Signed-off-by:Donggyu Kim
The subject needs a subsystem prefix, the subject is too long, and there
is no commit message. Run scripts/checkpatch.pl on your patches.
regards,
dan carpenter
Signed-off-by:Donggyu Kim
---
drivers/staging/rtl8723bs/core/rtw_cmd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c
b/drivers/staging/rtl8723bs/core/rtw_cmd.c
index e1a8f8b47edd..40d99644ddc7 100644
--- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
From: Donggyu Kim
Signed-off-by: Donggyu Kim
---
drivers/staging/rtl8723bs/core/rtw_cmd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c
b/drivers/staging/rtl8723bs/core/rtw_cmd.c
index e1a8f8b47edd..40d99644ddc7 100644
---
{
> struct mlme_priv *pmlmepriv;
> +
> pmlmepriv = &(padapter->mlmepriv);
>
> if (check_fwstate(pmlmepriv, WIFI_AP_STATE) == true)
> --
> 2.30.1 (Apple Git-130)
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a p
---
drivers/staging/rtl8723bs/core/rtw_cmd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c
b/drivers/staging/rtl8723bs/core/rtw_cmd.c
index e1a8f8b47edd..40d99644ddc7 100644
--- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
+++
s->size;
> > - /* GCC complains when we assign a char * to a void *, so these
> > -* casts are necessary unfortunately. */
> > + /*
> > +* GCC complains when we assign a char * to a void *, so these
> > +* casts are necessary unfortunately.
> &
o these
> - * casts are necessary unfortunately. */
> + /*
> + * GCC complains when we assign a char * to a void *, so these
> + * casts are necessary unfortunately.
> + */
Not related to your patch, but assigning a char pointer to a void
pointer is fine and GCC wil
On Tue, 18 May 2021 13:16:26 +0300
Dan Carpenter wrote:
> On Tue, May 18, 2021 at 05:56:47PM +0800, Tang Bin wrote:
> > In the function ad7746_probe(), the initialized value of 'ret' is unused,
> > because it will be assigned by the function i2c_smbus_write_byte_data(),
> > thus remove it.
> >
int ret = 0;" just introduces a static checker warning about
> > unused assignments and disables the static checker warning for
> > uninitialized variables so we want to remove that.
> >
> Got it, I will send this patch for you.
I fall a bit different on this and would con
Le dimanche 16 mai 2021 à 20:04 -0300, Ezequiel Garcia a écrit :
> Hi Hans,
>
> On Thu, 2021-05-06 at 14:50 +0200, Hans Verkuil wrote:
> > On 05/05/2021 17:20, Benjamin Gaignard wrote:
> > >
> > > Le 05/05/2021 à 16:55, Hans Verkuil a écrit :
> > > > On 20/04/2021 14:10, Benjamin Gaignard wrote:
On Tue, May 18, 2021 at 05:56:47PM +0800, Tang Bin wrote:
> In the function ad7746_probe(), the initialized value of 'ret' is unused,
> because it will be assigned by the function i2c_smbus_write_byte_data(),
> thus remove it.
>
> Signed-off-by: Tang Bin
Thanks!
Reviewed-by: Dan Carpenter
In the function ad7746_probe(), the initialized value of 'ret' is unused,
because it will be assigned by the function i2c_smbus_write_byte_data(),
thus remove it.
Signed-off-by: Tang Bin
---
drivers/staging/iio/cdc/ad7746.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
downside to leaving it as-is.
The unused "int ret = 0;" just introduces a static checker warning about
unused assignments and disables the static checker warning for
uninitialized variables so we want to remove that.
Got it, I will send this patch for you
On Mon, May 17, 2021 at 11:00:06PM +0800, Tang Bin wrote:
> @@ -730,11 +730,7 @@ static int ad7746_probe(struct i2c_client *client,
> if (ret < 0)
> return ret;
>
> - ret = devm_iio_device_register(indio_dev->dev.parent, indio_dev);
> - if (ret)
> - return
Hi Marcelo:
On 2021/5/18 6:14, Marcelo Schmitt wrote:
Hi Tang,
The patch looks overall good, though I think it could be split into two
pieces: one for simplifying ret declaration and another for removing the
check after device register.
Despite that, I guess Lucas might already be working
Hi Tang,
The patch looks overall good, though I think it could be split into two
pieces: one for simplifying ret declaration and another for removing the
check after device register.
Despite that, I guess Lucas might already be working on similar changes.
https://lore.kernel.org/linux-iio/cover
In the function ad7746_probe(), the return value of
devm_iio_device_register() can be zero or ret, thus it is
unnecessary to repeated check here. And delete unused
initialized value of 'ret', because it will be assigned by
the function i2c_smbus_write_byte_data().
Signed-off-by: Tang Bin
---
Am Montag, dem 17.05.2021 um 10:23 -0300 schrieb Ezequiel Garcia:
> On Mon, 2021-05-17 at 12:52 +0200, Lucas Stach wrote:
> > Hi Ezequiel,
> >
> > Am Sonntag, dem 16.05.2021 um 19:40 -0300 schrieb Ezequiel Garcia:
> > > Hi Lucas,
> > >
> > > On Fri, 2021-04-16 at 12:54 +0200, Lucas Stach wrote:
On Mon, 2021-05-17 at 12:52 +0200, Lucas Stach wrote:
> Hi Ezequiel,
>
> Am Sonntag, dem 16.05.2021 um 19:40 -0300 schrieb Ezequiel Garcia:
> > Hi Lucas,
> >
> > On Fri, 2021-04-16 at 12:54 +0200, Lucas Stach wrote:
> > > Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
> >
Em Mon, 17 May 2021 10:05:27 +0200
Pavel Machek escreveu:
> No. Take a look at triggers; for example hdd monitor should look very
> much like existing disk trigger.
Hmm... after looking at triggers, I'm not sure if this is the right
interface, nor if we're talking about the same thing.
See, at
Hi Ezequiel,
Am Sonntag, dem 16.05.2021 um 19:40 -0300 schrieb Ezequiel Garcia:
> Hi Lucas,
>
> On Fri, 2021-04-16 at 12:54 +0200, Lucas Stach wrote:
> > Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
> > > In order to be able to share the control hardware block between
>
On Sun, May 16, 2021 at 12:53:35PM +0200, Mauro Carvalho Chehab wrote:
> +static int nuc_wmi_query_leds_nuc6(struct device *dev)
> +{
> + // FIXME: add a check for the specific models that are known to work
> + struct nuc_wmi *priv = dev_get_drvdata(dev);
> + u8 cmd,
On Sun, May 16, 2021 at 12:53:30PM +0200, Mauro Carvalho Chehab wrote:
> - leds = output[0];
> + if (ver != LED_API_NUC6) {
> + ret = nuc_nmi_cmd(dev, LED_VERSION_CONTROL, input, output);
Does this need to be checked?
if (ret)
return ret;
> +
Em Mon, 17 May 2021 10:57:49 +0200
Mauro Carvalho Chehab escreveu:
> Em Mon, 17 May 2021 10:05:27 +0200
> Pavel Machek escreveu:
> > No. Take a look at triggers; for example hdd monitor should look very
> > much like existing disk trigger.
Btw, is there a way to trigger brightness?
When a
On Mon, May 17, 2021 at 11:02:58AM +0200, Mauro Carvalho Chehab wrote:
> Em Mon, 17 May 2021 10:18:57 +0200
> Greg KH escreveu:
>
> > On Sun, May 16, 2021 at 12:53:28PM +0200, Mauro Carvalho Chehab wrote:
> > > Hi Greg,
> > >
> > > This series add support for the LEDs found at Intel NUCs since
Em Mon, 17 May 2021 10:18:57 +0200
Greg KH escreveu:
> On Sun, May 16, 2021 at 12:53:28PM +0200, Mauro Carvalho Chehab wrote:
> > Hi Greg,
> >
> > This series add support for the LEDs found at Intel NUCs since
> > NUC version 6.
> >
> > On several NUC models, the function of the LEDs are
Em Mon, 17 May 2021 10:05:27 +0200
Pavel Machek escreveu:
> Hi!
>
> > > > - Need to validate the uAPI and document it before moving
> > > >this driver out of staging.
> > >
> > > > - Stabilize and document its sysfs interface.
> > >
> > > Would you mind starting with this
On Sun, May 16, 2021 at 12:53:29PM +0200, Mauro Carvalho Chehab wrote:
> Some Intel Next Unit of Computing (NUC) machines have
> software-configured LEDs that can be used to display a
> variety of events:
>
> - Power State
> - HDD Activity
> - Ethernet
> - WiFi
> -
On Sun, May 16, 2021 at 12:53:28PM +0200, Mauro Carvalho Chehab wrote:
> Hi Greg,
>
> This series add support for the LEDs found at Intel NUCs since
> NUC version 6.
>
> On several NUC models, the function of the LEDs are programmable,
> which allow them to indicate several different hardware
Hi!
> > > - Need to validate the uAPI and document it before moving
> > >this driver out of staging.
> >
> > > - Stabilize and document its sysfs interface.
> >
> > Would you mind starting with this one?
>
> Do you mean writing the ABI document for it? Surely I can do that,
> but
Hi Pavel,
Em Sun, 16 May 2021 20:21:50 +0200
Pavel Machek escreveu:
> Hi!
>
> > - Need to validate the uAPI and document it before moving
> >this driver out of staging.
>
> > - Stabilize and document its sysfs interface.
>
> Would you mind starting with this one?
Do you mean
Hi Hans,
On Thu, 2021-05-06 at 14:50 +0200, Hans Verkuil wrote:
> On 05/05/2021 17:20, Benjamin Gaignard wrote:
> >
> > Le 05/05/2021 à 16:55, Hans Verkuil a écrit :
> > > On 20/04/2021 14:10, Benjamin Gaignard wrote:
> > > > The HEVC HANTRO driver needs to know the number of bits to skip at
> >
Hi Lucas,
On Fri, 2021-04-16 at 12:54 +0200, Lucas Stach wrote:
> Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
> > In order to be able to share the control hardware block between
> > VPUs use a syscon instead a ioremap it in the driver.
> > To keep the compatibility with
Hi!
> - Need to validate the uAPI and document it before moving
>this driver out of staging.
> - Stabilize and document its sysfs interface.
Would you mind starting with this one? We should have existing APIs
for most of functionality described...
We really don't want to merge code
Hi Mauro,
On 5/16/21 3:53 AM, Mauro Carvalho Chehab wrote:
> diff --git a/drivers/staging/nuc-led/Kconfig b/drivers/staging/nuc-led/Kconfig
> new file mode 100644
> index ..0f870f45bf44
> --- /dev/null
> +++ b/drivers/staging/nuc-led/Kconfig
> @@ -0,0 +1,11 @@
> +#
Now that most functionality were merged at the driver,
update its TODO list, and add a "TODO" comment for the two
WMI API commands that are currently not implemented.
In summary:
- on Rev 0.64, command 0x07 (LED_NOTIFICATION) is meant to store
all config settings at EEPROM. That doesn't seem
Some Intel Next Unit of Computing (NUC) machines have
software-configured LEDs that can be used to display a
variety of events:
- Power State
- HDD Activity
- Ethernet
- WiFi
- Power Limit
They can even be controlled directly via software, without
any
has associated
method \AMW0.WMAA
...
Low failures: 1
wmi: GUID 86CCFD48-205E-4A77-9C48-2021CBEDE341 has multiple associated
methods WMTF defined, this is a firmware bug that leads to ambiguous behaviour.
Anyway, this was good enough to test that this patch will be
producing
Improve the logic in order to support not only S0 brightness,
but also the brightness for other indicators and for all
power states.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/nuc-led/nuc-wmi.c | 369 --
1 file changed, 249 insertions(+), 120
The NUC6 WMI API is really simple: it has just 2 messages,
that retrieves everything for a LED, and it has just 2 LEDs.
Add support for retrieving and set brightness and color.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/nuc-led/nuc-wmi.c | 198 --
1
The blink control logic for NUC6 API is somewhat messy, as it
uses a single register for controlling both the blink type
and the frequency, using a random order.
Let's use the same API as defined for other versions,
splitting this setting on two different properties.
Signed-off-by: Mauro
The is_visible logic for it is plain wrong:
1. it is used only during devnode creation;
2. it was using the wrong field (id, instead of indicator).
Fix it.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/nuc-led/nuc-wmi.c | 30 --
1 file changed, 12
The control indicators for WMI version 1.0 (used on NUCi10
and above) are on different locations.
The main difference is on single color LEDs.
Also, the Power State brightness names are defined on a
different way, and there are 3 groups instead of 4.
As the driver was written with some tables
Add routines to allow seeing and changing the LED colors.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/nuc-led/nuc-wmi.c | 244 --
1 file changed, 228 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/nuc-led/nuc-wmi.c
The hardware blink logic works for both Power State and Software
controlled LEDs.
Just like brightness, there is one different blink behavior
per different power state. Due to that, the logic is somewhat
more complex than what it would be expected otherwise.
Signed-off-by: Mauro Carvalho Chehab
There are two possible values for HDD activity behavior:
- 0 Normally off, ON when active
- 1 Normally on, OFF when active
Implement a logic to set it.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/nuc-led/nuc-wmi.c | 77 +++
1 file
The power limit indicator may have 2 behaviors:
1. Its color gradually changes from green to red;
2. It displays a single color
Add support for it.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/nuc-led/nuc-wmi.c | 93 +++
1 file changed, 93 insertions(+)
The Ethernet type indicator can be configured to show the status
of LAN1, LAN1 or both. Add support for it.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/nuc-led/nuc-wmi.c | 89 +++
1 file changed, 89 insertions(+)
diff --git
Hi Greg,
This series add support for the LEDs found at Intel NUCs since
NUC version 6.
On several NUC models, the function of the LEDs are programmable,
which allow them to indicate several different hardware events.
They can even be programmed to represent an userspace-driven event.
Some
There's no documented way to detect if the WMI API is valid,
as, when it is not valid, it just returns 4 zeros.
However, as having a value of 0x00 for the blinking state
is not valid, we can check for it at detection time, in
order to disable LEDs control on devices that won't
support it.
drivers/staging/nuc-led/nuc-wmi.c: In function ‘nuc_nmi_cmd’:
drivers/staging/nuc-led/nuc-wmi.c:242:6: warning: variable ‘size’ set
but not used [-Wunused-but-set-variable]
242 | int size, ret;
| ^~~~
Signed-off-by: Mauro Carvalho Chehab
---
There are currently 3 known API releases:
-
https://www.intel.com/content/www/us/en/support/articles/23426/intel-nuc/intel-nuc-kits.html
-
https://raw.githubusercontent.com/nomego/intel_nuc_led/master/specs/INTEL_WMI_LED_0.64.pdf
-
Now that the core logic is in place, let's add support to
adjust the S0 brightness level.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/nuc-led/nuc-wmi.c | 79 +++
1 file changed, 79 insertions(+)
diff --git a/drivers/staging/nuc-led/nuc-wmi.c
On Sat, Apr 10, 2021 at 5:02 AM Stephen Boyd wrote:
>
> Quoting Michal Simek (2021-04-08 03:40:29)
> >
> >
> > On 4/8/21 12:26 PM, Shubhrajyoti Datta wrote:
> > > On Sun, Mar 7, 2021 at 1:50 AM Rob Herring wrote:
> > >>
> > >> On Wed, Feb 24, 2021 at 06:40:40PM +0530, Shubhrajyoti Datta wrote:
>
Le jeudi 06 mai 2021 à 14:11 +0100, John Cox a écrit :
> > On 05/05/2021 17:20, Benjamin Gaignard wrote:
> > >
> > > Le 05/05/2021 à 16:55, Hans Verkuil a écrit :
> > > > On 20/04/2021 14:10, Benjamin Gaignard wrote:
> > > > > The HEVC HANTRO driver needs to know the number of bits to skip at
> >
>On 05/05/2021 17:20, Benjamin Gaignard wrote:
>>
>> Le 05/05/2021 à 16:55, Hans Verkuil a écrit :
>>> On 20/04/2021 14:10, Benjamin Gaignard wrote:
The HEVC HANTRO driver needs to know the number of bits to skip at
the beginning of the slice header.
That is a hardware specific
On 05/05/2021 17:20, Benjamin Gaignard wrote:
>
> Le 05/05/2021 à 16:55, Hans Verkuil a écrit :
>> On 20/04/2021 14:10, Benjamin Gaignard wrote:
>>> The HEVC HANTRO driver needs to know the number of bits to skip at
>>> the beginning of the slice header.
>>> That is a hardware specific
On Wed, 2021-05-05 at 16:55 +0200, Hans Verkuil wrote:
> On 20/04/2021 14:10, Benjamin Gaignard wrote:
> > The HEVC HANTRO driver needs to know the number of bits to skip at
> > the beginning of the slice header.
> > That is a hardware specific requirement so create a dedicated control
> > for
Le mercredi 05 mai 2021 à 16:18 +0100, John Cox a écrit :
> > The HEVC HANTRO driver needs to know the number of bits to skip at
> > the beginning of the slice header.
> > That is a hardware specific requirement so create a dedicated control
> > for this purpose.
> >
> > Signed-off-by: Benjamin
Le 05/05/2021 à 16:55, Hans Verkuil a écrit :
On 20/04/2021 14:10, Benjamin Gaignard wrote:
The HEVC HANTRO driver needs to know the number of bits to skip at
the beginning of the slice header.
That is a hardware specific requirement so create a dedicated control
for this purpose.
>The HEVC HANTRO driver needs to know the number of bits to skip at
>the beginning of the slice header.
>That is a hardware specific requirement so create a dedicated control
>for this purpose.
>
>Signed-off-by: Benjamin Gaignard
>---
> .../userspace-api/media/drivers/hantro.rst| 19
On 20/04/2021 14:10, Benjamin Gaignard wrote:
> The HEVC HANTRO driver needs to know the number of bits to skip at
> the beginning of the slice header.
> That is a hardware specific requirement so create a dedicated control
> for this purpose.
>
> Signed-off-by: Benjamin Gaignard
> ---
>
Hi Benjamin,
Some comments:
On 20/04/2021 14:10, Benjamin Gaignard wrote:
> Implement all the logic to get G2 hardware decoding HEVC frames.
> It supports up level 5.1 HEVC stream.
> It doesn't support yet 10 bits formats or the scaling feature.
>
> Add HANTRO HEVC dedicated control to skip
ize data.
This series clashes with this patch:
https://patchwork.linuxtv.org/project/linux-media/patch/20210427071554.625-1-jernej.skra...@siol.net/
and this patch series:
https://patchwork.linuxtv.org/project/linux-media/cover/20210401144336.2495479-1-emil.l.veli...@gmail.com/
For both P
to buffer length).
+ */
+ if (!V4L2_TYPE_IS_OUTPUT(vq->type))
Please use V4L2_TYPE_IS_CAPTURE here.
Also, why is this change needed in rkvdec, but not in cedrus
or hantro?
As a matter of fact I think it is needed in all three, because later on,
whenever a driver uses vb2_get_plane_payload(), without such a patch it
Sakari Ailus wrote:
> > > > Hi Deepak,
> > > >
> > > > If you're touching all these lines, I might do a little more. Please see
> > > > the comments below.
> > > >
> > > Hello Sakari,
> > > I can definitely include oth
Hi Andrzej,
Thanks a lot for picking this up.
On Tue, 2021-05-04 at 13:37 +0200, Andrzej Pietrasiewicz wrote:
> From: Ezequiel Garcia
>
> The driver should only set the payload on .buf_prepare if the
> buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused
> set by userspace then
From: Ezequiel Garcia
The driver should only set the payload on .buf_prepare if the
buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused
set by userspace then v4l2-core will set it to buffer length.
Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver")
Signed-off-by:
On Fri, Apr 30, 2021 at 06:03:38PM +0100, Jonathan Cameron wrote:
> On Wed, 28 Apr 2021 16:51:44 +0200
> Mauro Carvalho Chehab wrote:
>
> > Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal
> > with usage counter")
> > added pm_runtime_resume_and_get() in order to
Trivial code reformatting changes done according to the coding
style guidelines. These code changes overall improve code readability
and also address chackpatch complaints.
Signed-off-by: Deepak R Varma
---
drivers/staging/media/atomisp/pci/sh_css_version.c | 4 ++--
1 file changed, 2
Several trivial code reformatting changes done according to the coding
style guidelines. These code changes overall improve code organisation
and readability and also address many chackpatch error, warning and
check complaints.
Signed-off-by: Deepak R Varma
---
Several trivial code reformatting changes done according to the coding
style guidelines. These code changes overall improve code organisation
and readability and also address many chackpatch error, warning and
check complaints.
Signed-off-by: Deepak R Varma
---
Several trivial code reformatting changes done according to the coding
style guidelines. These code changes overall improve code organisation
and readability and also address many chackpatch error, warning and
check complaints.
Signed-off-by: Deepak R Varma
---
Several trivial code reformatting changes done according to the coding
style guidelines. These changes improves code organisation and readability
and also 4 address many chackpatch error, warning and check complaints.
Signed-off-by: Deepak R Varma
---
This patch set overall improves the code organisation and readability of
the files of atomisp drivers. There are several complaints reported by
checkpatch including ERROR and WARNING types on the files under atomisp/pci
directory.
The changes are proposed on a per file basis since there are many
rrors.
>
> While there's nothing wrong with the current usage on this driver,
> as we're getting rid of the pm_runtime_get_sync() call all over
> the media subsystem, let's remove the last occurrence on this
> driver.
Not sure there is nothing wrong in here before your patch...
&
ching all these lines, I might do a little more. Please see
> > > the comments below.
> > >
> > Hello Sakari,
> > I can definitely include other changes, but then it will be many different
> > types of changes into a single patch. Will that be okay?
> >
&
errors.
>
> Use the new API, in order to cleanup the error check logic.
>
> Signed-off-by: Mauro Carvalho Chehab
NOP patch so
Reviewed-by: Jonathan Cameron
> ---
> drivers/staging/media/tegra-video/csi.c | 3 +--
> drivers/staging/media/tegra-video/vi.c | 3 +--
&g
gt; >
> Hello Sakari,
> I can definitely include other changes, but then it will be many different
> types of changes into a single patch. Will that be okay?
>
> I was planning to address one issue per patch as I think the volume of
> change is going to be high. I mentioned that in th
On Fri, 30 Apr 2021 18:08:36 +0100
Jonathan Cameron wrote:
> On Wed, 28 Apr 2021 16:51:46 +0200
> Mauro Carvalho Chehab wrote:
>
> > Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal
> > with usage counter")
> > added pm_runtime_resume_and_get() in order to
On Wed, 28 Apr 2021 16:51:46 +0200
Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
> usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
>
> Use the new
On Wed, 28 Apr 2021 16:51:42 +0200
Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
> usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
>
> Use the new
On Wed, 28 Apr 2021 16:51:45 +0200
Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
> usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
>
> Use the new
On Wed, 28 Apr 2021 16:51:44 +0200
Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
> usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
>
> Use the new
s into a single patch. Will that be okay?
I was planning to address one issue per patch as I think the volume of
change is going to be high. I mentioned that in the notes section of the patch
message.
Let me know if you still suggest I combine those.
Thank you,
deepak.
> On Fri, Apr 30,
Hi Deepak,
If you're touching all these lines, I might do a little more. Please see
the comments below.
On Fri, Apr 30, 2021 at 09:10:12PM +0530, Deepak R Varma wrote:
> Misplaced braces makes it difficult to follow the code easily. This also
> goes against the code style guidelines. This
Misplaced braces makes it difficult to follow the code easily. This also
goes against the code style guidelines. This resolved following checkpatch
complaints:
ERROR: open brace '{' following function definitions go on the next line
ERROR: that open brace { should be on the previous line
I'm not sure that having two interfaces with different
semantics to do the job is doing us any favours here. But again, that
discussion has already been had.
And I realise that this is partly also your motive here (even if the old
interface isn't going to go away).
> > > compile-tested only.
> > >
801 - 900 of 94028 matches
Mail list logo
