Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1280711 > unrolled thread

Re: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to  request a channel Peter Ujfalusi <peter.ujfalusi@ti.com> - 2015-12-01 11:00 +0100
    Re: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to  request a channel Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-12-01 11:10 +0100

#1280711 — Re: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

On 11/30/2015 04:51 PM, Andy Shevchenko wrote:
>> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>> +{
>> +       struct dma_device *device, *_d;
>> +       struct dma_chan *chan = NULL;
>> +
>> +       /* If device-tree is present get slave info from here */
>> +       if (dev->of_node)
>> +               chan = of_dma_request_slave_channel(dev->of_node, name);
>> +
>> +       /* If device was enumerated by ACPI get slave info from here */
>> +       if (ACPI_HANDLE(dev) && !chan)
> 
> The preferable way is to use
> has_acpi_companion() instead of ACPI_HANDLE().

I have done this part based on the dma_request_slave_channel_reason().
Will switch to use the has_acpi_companion() for the next RFC.

>> +               chan = acpi_dma_request_slave_chan_by_name(dev, name);
>> +
>> +       if (chan)
>> +               return chan;
>> +

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1280723

On Tue, Dec 1, 2015 at 11:56 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 11/30/2015 04:51 PM, Andy Shevchenko wrote:
>>> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>>> +{
>>> +       struct dma_device *device, *_d;
>>> +       struct dma_chan *chan = NULL;
>>> +
>>> +       /* If device-tree is present get slave info from here */
>>> +       if (dev->of_node)
>>> +               chan = of_dma_request_slave_channel(dev->of_node, name);
>>> +
>>> +       /* If device was enumerated by ACPI get slave info from here */
>>> +       if (ACPI_HANDLE(dev) && !chan)
>>
>> The preferable way is to use
>> has_acpi_companion() instead of ACPI_HANDLE().
>
> I have done this part based on the dma_request_slave_channel_reason().

Understood, though that function was implemented before
has_acpi_companion() has been introduced.

> Will switch to use the has_acpi_companion() for the next RFC.

Good.

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web