Remove the check for _rtw_enqueue_cmd(), because
rtw_enqueue_cmd() already has a check of NULL pointer,
so this condition is not possible.
Signed-off-by: Qiang Ma
---
drivers/staging/rtl8188eu/core/rtw_cmd.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/r
On 16/06/2021 09:50, Xin Ji wrote:
> The basic anx7625 driver only support MIPI DSI rx signal input.
> This patch add MIPI DPI rx input configuration support, after apply
> this patch, the driver can support DSI rx or DPI rx by adding
> 'bus-type' in DT.
>
> Reviewed-b
Add audio HDMI codec function support, enable it through device true flag
"analogix,audio-enable".
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 227 ++
drivers/gpu/drm/bridge/analogix/anx7625.h | 5 +
2 files changed, 232 i
The basic anx7625 driver only support MIPI DSI rx signal input.
This patch add MIPI DPI rx input configuration support, after apply
this patch, the driver can support DSI rx or DPI rx by adding
'bus-type' in DT.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridg
At some time, the original code may return non zero value, force return 0
if operation finished.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/a
Hi all, this patch series implement MIPI rx DPI feature. Please help to review.
This is the v8 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:
v8: F
On Mon, Jun 14, 2021 at 01:12:56PM +0300, Laurent Pinchart wrote:
> Hi Xin,
>
> Thank you for the patch.
>
> On Fri, Jun 11, 2021 at 05:13:33PM +0800, Xin Ji wrote:
> > Add MIPI rx DPI input feature support.
>
> Could you expand the commit message to explain what t
Hi Xin,
Thank you for the patch.
On Fri, Jun 11, 2021 at 05:13:33PM +0800, Xin Ji wrote:
> Add MIPI rx DPI input feature support.
Could you expand the commit message to explain what this feature is ?
> Reviewed-by: Robert Foss
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/
On Fri, May 21, 2021 at 12:30:41AM +0530, Deepak R Varma wrote:
> 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 at
Add audio HDMI codec function support, enable it through device true flag
"analogix,audio-enable".
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 227 ++
drivers/gpu/drm/bridge/analogix/anx7625.h | 5 +
2 files changed, 232 i
Add MIPI rx DPI input feature support.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 245 --
drivers/gpu/drm/bridge/analogix/anx7625.h | 18 +-
2 files changed, 203 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm
At some time, the original code may return non zero value, force return 0
if operation finished.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/a
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:
- Re
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 Gaig
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.
>
> Introduc
(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.
>
> 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 P
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
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 e1a8f8b47edd..40d99644ddc7
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
--- a/drivers/staging/rtl872
{
> 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 patch that
---
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
+++ b/drivers/staging/rtl8723
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.
> > +
ese
> - * 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.
> >
>
sed "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
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
reg
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 a/driv
n't a
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 pat
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 on
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
---
dri
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, input[NUM_INPUT_ARG
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 L
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 progra
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
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
> - Po
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 eve
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 I
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 wri
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 o
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 wit
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 @@
> +# SPDX-License-Identif
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 hardw
26D34390B7 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
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 deletions(-
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 fil
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 Carvalho
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 inserti
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 to
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
b/drivers/staging/nuc-led
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 change
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 a/drivers/staging/nuc-led/nuc-
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 model
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.
Signed-
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
---
drivers
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
-
https://www.intel.com/co
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
b/drivers/s
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 requ
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 requirement
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 this
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 Ga
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.
Signed-off-b
>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
> ---
> .../use
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 some
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
*/
+ 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 patc
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 includ
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 v4l2
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: Ezequiel
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 automati
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 insertions
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
---
drivers/staging/media/atomisp/pci/
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
---
.../staging/media/atomisp/pci/sh_c
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
---
.../staging/media/atomisp/pci/sh_c
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
---
.../staging/media/atomisp/pci/atomisp_csi2.c
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 yo
801 - 900 of 99420 matches
Mail list logo
