When the current context is running,
1] If release() or streamoff() is called on the current context,
it waits until the job is aborted or finished.
2] If the job is finished, driver will call the v4l2_m2m_job_finish().
3] If the job is aborted inside device_run callback, then driver
has to i
When the current context is running,
1] If release is called, it waits until the job is finished.
2] As soon as the job is finished, v4l2_mem_ctx_release()tries to
release the vb2 queues.
3] But if the current context can be scheduled in the v4l2_m2m_job_finish()
it schedules the context and
On Fri, Sep 20, 2013 at 11:04:40AM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
>
> On Tuesday 17 September 2013 09:11 PM, Felipe Balbi wrote:
> > On Wed, Sep 04, 2013 at 02:27:06PM +0530, Kishon Vijay Abraham I wrote:
> >> On Tuesday 03 September 2013 09:20 PM, Greg KH wrote:
> >>> On Tue, Sep
Hi Greg,
On Tuesday 17 September 2013 09:11 PM, Felipe Balbi wrote:
> On Wed, Sep 04, 2013 at 02:27:06PM +0530, Kishon Vijay Abraham I wrote:
>> On Tuesday 03 September 2013 09:20 PM, Greg KH wrote:
>>> On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote:
Hi Greg,
Resending it as it bounced from kernel mailing group
On Wed, Sep 18, 2013 at 3:53 PM, Mark Rutland wrote:
> [adding lakml]
>
> On Wed, Sep 18, 2013 at 11:11:53AM +0100, Yuvaraj Kumar C D wrote:
>> Without the "clock-frequency" property in arch timer node, could able
>> to see the below crash dump
Hi Dmitry,
On Fri, Sep 20, 2013 at 2:52 AM, Dmitry Torokhov
wrote:
> On Wed, Sep 18, 2013 at 12:41:11AM +0530, Manish Badarkhe wrote:
>> Hi Dmitry,
>>
>> On Wed, Sep 18, 2013 at 12:22 AM, Dmitry Torokhov
>> wrote:
>> > Hi Manish,
>> >
>> > On Sun, Sep 15, 2013 at 01:22:23AM +0530, Manish Badarkh
dcdbas was explicitly initializing DMA masks thusly:
dcdbas_pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
dcdbas_pdev->dev.dma_mask = &dcdbas_pdev->dev.coherent_dma_mask;
which bypasses the architecture check. Moreover, it is creating the
dcdbas_pdev device itself, and using the
register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info. So lets
make that be the case. This avoids a direct reference to the DMA
masks by this driver.
Signed-off-by: Russell King
---
drivers/dma/edma.c |6 ++
1 files
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
> Provide a helper to set both the DMA and coherent DMA masks to the
> same value - this avoids duplicated code in a number of drivers,
> sometimes with buggy error handling, and also allows us identify
> which drivers do things differently.
>
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
Provide a helper to set both the DMA and coherent DMA masks to the
same value - this avoids duplicated code in a number of drivers,
sometimes with buggy error handling, and also allows us identify
which drivers do things differently.
Signed-off-by: Russell King
---
Documentation/DMA-API-HOWTO.tx
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM - notably how the DMA mask
should be setup.
However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some cases
On Wed, Sep 18, 2013 at 12:41:11AM +0530, Manish Badarkhe wrote:
> Hi Dmitry,
>
> On Wed, Sep 18, 2013 at 12:22 AM, Dmitry Torokhov
> wrote:
> > Hi Manish,
> >
> > On Sun, Sep 15, 2013 at 01:22:23AM +0530, Manish Badarkhe wrote:
> >> Update the code to use devm_* API so that driver core will mana
Since Operating Performance Points(OPP) functions are specific to
device specific power management, be specific and rename opp.h
to pm_opp.h
Reported-by: Randy Dunlap
Signed-off-by: Nishanth Menon
---
Documentation/power/opp.txt |2 +-
arch/arm/mach-imx/mach-imx6q.c |
Hi,
Based on [1], Randy rightly pointed out that OPP functions and data
structures could be a bit specific to Power management.
So, the following series is based on v3.12-rc1 tag.
If folks like it broken in a different way, I am open to suggestions.
Nishanth Menon (3):
PM / OPP: rename functi
Since Operating Performance Points(OPP) functions are specific to
device specific power management, be specific and rename opp_*
accessors in OPP library with dev_pm_opp_* equivalent.
Impacted functions are:
opp_get_voltage
opp_get_freq
opp_get_opp_count
opp_find_freq_exact
opp_find_freq_floor
opp
Since Operating Performance Points(OPP) data structures are specific
to device specific power management, be specific and rename opp_* data
structures in OPP library with dev_pm_opp_* equivalent.
Impacted structures are:
struct opp
enum opp_event
Minor checkpatch warning fixes as a result of this
On 16:03-20130919, Nishanth Menon wrote:
> Hi,
>
> Based on [1], Randy rightly pointed out that OPP functions and data
> structures could be a bit specific to Power management.
>
> So, the following series is based on v3.12-rc1 tag.
>
> If folks like it broken in a dif
24 matches
Mail list logo
