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

Groups > linux.kernel > #1456378 > unrolled thread

Re: [PATCH 10/10] dmaengine: qcom_hidma: add MSI support for interrupts

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: [PATCH 10/10] dmaengine: qcom_hidma: add MSI support for  interrupts Vinod Koul <vinod.koul@intel.com> - 2016-08-04 14:40 +0200
    Re: [PATCH 10/10] dmaengine: qcom_hidma: add MSI support for  interrupts Sinan Kaya <okaya@codeaurora.org> - 2016-08-04 16:10 +0200
      Re: [PATCH 10/10] dmaengine: qcom_hidma: add MSI support for  interrupts Vinod Koul <vinod.koul@intel.com> - 2016-08-08 10:10 +0200
        Re: [PATCH 10/10] dmaengine: qcom_hidma: add MSI support for  interrupts okaya@codeaurora.org - 2016-08-08 13:50 +0200

#1456378 — Re: [PATCH 10/10] dmaengine: qcom_hidma: add MSI support for interrupts

On Sun, Jul 24, 2016 at 10:38:11AM -0400, Sinan Kaya wrote:
> >> +       if (rc)
> >> +               dev_warn(&pdev->dev,
> >> +                        "failed to request MSI irq, falling back to wired IRQ\n");
> >> +       return rc;
> >> +#else
> >> +       return -EINVAL;
> > 
> > -EINVAL doesnt sound apt here..
> 
> What should I use? -ENOENT ?

that sounds okay or EIO

> >> +                       return false;
> >> +
> >> +               ret = strcmp(of_compat, "qcom,hidma-1.1");
> >> +       } else {
> >> +               ret = strcmp(acpi_device_hid(adev), "QCOM8062");
> > 
> > Okay if you ahve a device ID then why do we need new binding? This device as
> > you said implies the support for MSI interrupts.
> 
> 
> Yes, I do have a new device ID for platforms with MSI capability. 
> 
> Which new binding are you referring to?

If you have "QCOM8062" why do you need DT to tell hidma-1.1 ?

-- 
~Vinod

[toc] | [next] | [standalone]

#1456414

On 8/4/2016 8:46 AM, Vinod Koul wrote:
>> > Yes, I do have a new device ID for platforms with MSI capability. 
>> > 
>> > Which new binding are you referring to?
> If you have "QCOM8062" why do you need DT to tell hidma-1.1 ?

Unfortunately, DT cannot do a binding with the ACPI names. Similarly, ACPI
cannot do a binding with the DT name. 

The structure of binding name is also subject to different kind of rules
for DT and ACPI.

This driver supports both device tree and ACPI. That's why, two different
names are required.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

[toc] | [prev] | [next] | [standalone]

#1457598

On Thu, Aug 04, 2016 at 09:59:43AM -0400, Sinan Kaya wrote:
> On 8/4/2016 8:46 AM, Vinod Koul wrote:
> >> > Yes, I do have a new device ID for platforms with MSI capability. 
> >> > 
> >> > Which new binding are you referring to?
> > If you have "QCOM8062" why do you need DT to tell hidma-1.1 ?
> 
> Unfortunately, DT cannot do a binding with the ACPI names. Similarly, ACPI
> cannot do a binding with the DT name. 
> 
> The structure of binding name is also subject to different kind of rules
> for DT and ACPI.
> 
> This driver supports both device tree and ACPI. That's why, two different
> names are required.

Hmmm, wasn't the who get_property stuff supposed to make properties work on
both ACPi & DT. I am not sure though about the current state of affairs on
that.

-- 
~Vinod

[toc] | [prev] | [next] | [standalone]

#1457740

On 2016-08-08 04:14, Vinod Koul wrote:
> On Thu, Aug 04, 2016 at 09:59:43AM -0400, Sinan Kaya wrote:
>> On 8/4/2016 8:46 AM, Vinod Koul wrote:
>> >> > Yes, I do have a new device ID for platforms with MSI capability.
>> >> >
>> >> > Which new binding are you referring to?
>> > If you have "QCOM8062" why do you need DT to tell hidma-1.1 ?
>> 
>> Unfortunately, DT cannot do a binding with the ACPI names. Similarly, 
>> ACPI
>> cannot do a binding with the DT name.
>> 
>> The structure of binding name is also subject to different kind of 
>> rules
>> for DT and ACPI.
>> 
>> This driver supports both device tree and ACPI. That's why, two 
>> different
>> names are required.
> 
> Hmmm, wasn't the who get_property stuff supposed to make properties 
> work on
> both ACPi & DT. I am not sure though about the current state of affairs 
> on
> that.


Get property works. It is able to abstract device driver properties. A 
driver doesn't need to know whether it is coming from acpi dsd or of.

However, no such mechanism exists for driver names due to nature of 
different naming requirements.

Of has its own match table and acpi has its own. Acpi also has 
ridiculous 8 character name limitation.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web