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 no
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
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, for
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
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev
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.
>
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.
...
>> +terga_soc_fo
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 (of
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 = dev_pm_opp_get_opp_table(d
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.
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);
>
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
> shar
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 arou
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 (!device_property_p
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: Dmitry
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 resour
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 resour
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 resour
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 kernel.
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:
> > > > +/**
> > > > +
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 wh
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 | \
> +SNDRV_PCM_INFO_INT
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 vers
22 matches
Mail list logo
