Re: [RESEND PATCH 0/2] media: uapi: Expose VP8 probability lengths as defines

2020-11-10 Thread Ezequiel Garcia
Hi Emmanuel, Thanks for the patch. On Mon, 9 Nov 2020 at 15:37, Emmanuel Gil Peyrot wrote: > > These values will be used by various drivers implementing the VP8 > stateless API. > > This had been suggested by Ezequiel Garcia for the Cedrus VP8 driver. > > The only driver using this API (until

[PATCH v3] media: cedrus: Add support for VP8 decoding

2020-11-10 Thread Jernej Skrabec
VP8 in Cedrus shares same engine as H264. Note that it seems necessary to call bitstream parsing functions, to parse frame header, otherwise decoded image is garbage. This is contrary to what is driver supposed to do. However, values are not really used, so this might be acceptable. It's possible

Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

2020-11-10 Thread Dmitry Osipenko
10.11.2020 23:29, Thierry Reding пишет: >> +/* legacy device-trees don't have OPP table */ >> +if (!device_property_present(dc->dev, "operating-points-v2")) >> +return 0; > "Legacy" is a bit confusing here. For one, no device trees currently > have these tables and secondly,

Re: [PATCH v1 07/30] soc/tegra: Add sync state API

2020-11-10 Thread Dmitry Osipenko
11.11.2020 00:22, Dmitry Osipenko пишет: > I added a special spell checking rule for this typo, but it does help > reliably. does *not* ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

2020-11-10 Thread Dmitry Osipenko
10.11.2020 23:32, Mark Brown пишет: > On Tue, Nov 10, 2020 at 09:29:45PM +0100, Thierry Reding wrote: >> On Thu, Nov 05, 2020 at 02:44:08AM +0300, Dmitry Osipenko wrote: > >>> + /* >>> +* Voltage scaling is optional and trying to set voltage for a dummy >>> +* regulator will error out.

Re: [PATCH v1 07/30] soc/tegra: Add sync state API

2020-11-10 Thread Dmitry Osipenko
10.11.2020 23:47, Thierry Reding пишет: ... > tegra_soc_for_each_device > > I wonder if you copy/pasted this or if you got really lucky to mistype > this all three times. Copied of course :) I added a special spell checking rule for this typo, but it does help reliably. ... >> +

Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

2020-11-10 Thread Dmitry Osipenko
10.11.2020 23:29, Thierry Reding пишет: >> + >> +dc->opp_table = dev_pm_opp_get_opp_table(dc->dev); >> +if (IS_ERR(dc->opp_table)) >> +return dev_err_probe(dc->dev, PTR_ERR(dc->opp_table), >> + "failed to prepare OPP table\n"); >> + >> +if

Re: [PATCH v1 18/30] pwm: tegra: Support OPP and core voltage scaling

2020-11-10 Thread Dmitry Osipenko
10.11.2020 23:50, Thierry Reding пишет: > On Thu, Nov 05, 2020 at 02:44:15AM +0300, Dmitry Osipenko wrote: > [...] >> +static void tegra_pwm_deinit_opp_table(void *data) >> +{ >> +struct device *dev = data; >> +struct opp_table *opp_table; >> + >> +opp_table =

Re: [PATCH 12/13] drivers/staging/unisys/visorhba: convert stats to use seqnum_ops

2020-11-10 Thread Shuah Khan
On 11/10/20 1:42 PM, Greg KH wrote: On Tue, Nov 10, 2020 at 12:53:38PM -0700, Shuah Khan wrote: seqnum_ops api is introduced to be used when a variable is used as a sequence/stat counter and doesn't guard object lifetimes. This clearly differentiates atomic_t usages that guard object lifetimes.

Re: [PATCH v1 18/30] pwm: tegra: Support OPP and core voltage scaling

2020-11-10 Thread Thierry Reding
On Thu, Nov 05, 2020 at 02:44:15AM +0300, Dmitry Osipenko wrote: [...] > +static void tegra_pwm_deinit_opp_table(void *data) > +{ > + struct device *dev = data; > + struct opp_table *opp_table; > + > + opp_table = dev_pm_opp_get_opp_table(dev); > + dev_pm_opp_of_remove_table(dev);

Re: [PATCH v1 07/30] soc/tegra: Add sync state API

2020-11-10 Thread Thierry Reding
On Thu, Nov 05, 2020 at 02:44:04AM +0300, Dmitry Osipenko wrote: > Introduce sync state API that will be used by Tegra device drivers. This > new API is primarily needed for syncing state of SoC devices that are left > ON after bootloader or permanently enabled. All these devices belong to a >

Re: [PATCH 12/13] drivers/staging/unisys/visorhba: convert stats to use seqnum_ops

2020-11-10 Thread Greg KH
On Tue, Nov 10, 2020 at 12:53:38PM -0700, Shuah Khan wrote: > seqnum_ops api is introduced to be used when a variable is used as > a sequence/stat counter and doesn't guard object lifetimes. This > clearly differentiates atomic_t usages that guard object lifetimes. > > seqnum32 variables wrap

Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

2020-11-10 Thread Mark Brown
On Tue, Nov 10, 2020 at 09:29:45PM +0100, Thierry Reding wrote: > On Thu, Nov 05, 2020 at 02:44:08AM +0300, Dmitry Osipenko wrote: > > + /* > > +* Voltage scaling is optional and trying to set voltage for a dummy > > +* regulator will error out. > > +*/ > > + if

Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

2020-11-10 Thread Thierry Reding
On Thu, Nov 05, 2020 at 02:44:08AM +0300, Dmitry Osipenko wrote: > Add OPP and SoC core voltage scaling support to the display controller > driver. This is required for enabling system-wide DVFS on older Tegra > SoCs. > > Tested-by: Peter Geis > Tested-by: Nicolas Chauvet > Signed-off-by:

[PATCH 12/13] drivers/staging/unisys/visorhba: convert stats to use seqnum_ops

2020-11-10 Thread Shuah Khan
seqnum_ops api is introduced to be used when a variable is used as a sequence/stat counter and doesn't guard object lifetimes. This clearly differentiates atomic_t usages that guard object lifetimes. seqnum32 variables wrap around to INT_MIN when it overflows and should not be used to guard

[PATCH 09/13] drivers/staging/rtl8723bs: convert stats to use seqnum_ops

2020-11-10 Thread Shuah Khan
seqnum_ops api is introduced to be used when a variable is used as a sequence/stat counter and doesn't guard object lifetimes. This clearly differentiates atomic_t usages that guard object lifetimes. seqnum32 variables wrap around to INT_MIN when it overflows and should not be used to guard

[PATCH 11/13] drivers/staging/rtl8188eu: convert stats to use seqnum_ops

2020-11-10 Thread Shuah Khan
seqnum_ops api is introduced to be used when a variable is used as a sequence/stat counter and doesn't guard object lifetimes. This clearly differentiates atomic_t usages that guard object lifetimes. seqnum32 variables wrap around to INT_MIN when it overflows and should not be used to guard

Re: [PATCH v3 00/11] Introduce Simple atomic counters

2020-11-10 Thread Dan Carpenter
On Fri, Oct 16, 2020 at 03:51:25PM -0700, Kees Cook wrote: > On Fri, Oct 16, 2020 at 12:53:13PM +0200, Peter Zijlstra wrote: > > That's like saying: "I'm too lazy to track what I've looked at already". > > You're basically proposing to graffiti "Kees was here -- 16/10/2020" all > > over the

Re: [PATCH v3 01/11] firmware: raspberrypi: Introduce devm_rpi_firmware_get()

2020-11-10 Thread Nicolas Saenz Julienne
Hi Bartosz, thanks for the feedback. On Thu, 2020-11-05 at 10:42 +0100, Bartosz Golaszewski wrote: > On Thu, Nov 5, 2020 at 10:28 AM Nicolas Saenz Julienne > wrote: > > Hi Bartosz, thanks for the review. > > > > On Thu, 2020-11-05 at 10:13 +0100, Bartosz Golaszewski wrote: > > > > +/** > > > >

Re: [PATCH v4 0/4] MT7621 PCIe PHY

2020-11-10 Thread Sergio Paracuellos
Hi, On Sat, Oct 31, 2020 at 1:22 PM Sergio Paracuellos wrote: > > This series adds support for the PCIe PHY found in the Mediatek > MT7621 SoC. > > This is the first attempt to get feedback of what is missing in > this driver to be promoted from staging. > > There is also a 'mt7621-pci' driver

Re: [PATCH v2] drivers: most: add ALSA sound driver

2020-11-10 Thread Dan Carpenter
On Fri, Nov 06, 2020 at 05:30:54PM +0100, Christian Gromm wrote: > +static struct list_head adpt_list; > + > +#define MOST_PCM_INFO (SNDRV_PCM_INFO_MMAP | \ > +SNDRV_PCM_INFO_MMAP_VALID | \ > +SNDRV_PCM_INFO_BATCH | \ > +

Re: [PATCH RFC PKS/PMEM 05/58] kmap: Introduce k[un]map_thread

2020-11-10 Thread Thomas Gleixner
On Mon, Nov 09 2020 at 20:59, Ira Weiny wrote: > On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote: > Also, we can convert the new memcpy_*_page() calls to kmap_local() as well. > [For now my patch just uses kmap_atomic().] > > I've not looked at all of the patches in your latest