From: Sinan Kaya <okaya@codeaurora.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: dmaengine <dmaengine@vger.kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Timur Tabi <timur@codeaurora.org>,
devicetree <devicetree@vger.kernel.org>,
cov@codeaurora.org, Vinod Koul <vinod.koul@intel.com>,
jcm@redhat.com, Andy Gross <agross@codeaurora.org>,
Arnd Bergmann <arnd@arndb.de>,
linux-arm-msm@vger.kernel.org,
linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V10 7/7] dma: qcom_hidma: add support for object hierarchy
Date: Wed, 30 Dec 2015 10:28:30 -0500 [thread overview]
Message-ID: <5683F81E.5050406@codeaurora.org> (raw)
In-Reply-To: <CAHp75Vd-ku1E4+BWGwtL06mO7EZHFmwCvwFiAhLUVwrJHNKD7w@mail.gmail.com>
On 12/19/2015 1:37 PM, Andy Shevchenko wrote:
> On Thu, Dec 17, 2015 at 7:01 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
>> In order to create a relationship model between the channels and the
>> management object, we are adding support for object hierarchy to the
>> drivers. This patch simplifies the userspace application development.
>> We will not have to traverse different firmware paths based on device
>> tree or ACPI baed kernels.
>>
>> No matter what flavor of kernel is used, objects will be represented as
>> platform devices.
>>
>> The new layout is as follows:
>>
>> hidmam_10: hidma-mgmt@0x5A000000 {
>> compatible = "qcom,hidma-mgmt-1.0";
>> ...
>>
>> hidma_10: hidma@0x5a010000 {
>> compatible = "qcom,hidma-1.0";
>> ...
>> }
>> }
>>
>> The hidma_mgmt_init detects each instance of the hidma-mgmt-1.0 objects
>> in device tree and calls into the channel driver to create platform devices
>> for each child of the management object.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>
>
>> +What: /sys/devices/platform/hidma-*/chid
>> + /sys/devices/platform/QCOM8061:*/chid
>> +Date: Dec 2015
>> +KernelVersion: 4.4
>> +Contact: "Sinan Kaya <okaya@cudeaurora.org>"
>> +Description:
>> + Contains the ID of the channel within the HIDMA instance.
>> + It is used to associate a given HIDMA channel with the
>> + priority and weight calls in the management interface.
>
>> -module_platform_driver(hidma_mgmt_driver);
>> +#ifdef CONFIG_OF
>> +static int object_counter;
>> +
>> +static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
>> +{
>> + struct platform_device *pdev_parent = of_find_device_by_node(np);
>> + struct platform_device_info pdevinfo;
>> + struct of_phandle_args out_irq;
>> + struct device_node *child;
>> + struct resource *res;
>> + const __be32 *cell;
>
> Always BE ?
Yes, as Timur indicated device tree is big endian all the time.
>
>> + int ret = 0, size, i, num;
>> + u64 addr, addr_size;
>
> resource_size_t
These values are read from the device tree blob using of_read_number function. of_read_number
returns a u64.
>
>> +
>> + for_each_available_child_of_node(np, child) {
>> + int iter = 0;
>> +
>> + cell = of_get_property(child, "reg", &size);
>> + if (!cell) {
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> +
>> + size /= (sizeof(*cell));
>
> Redundant parens. I think it might be good to use common sense for
> operator precedence, here is a radical example of ignoring it. And
> this is not the first case.
Removed. Note that I copied most of this function from another driver.
>
>> + num = size /
>> + (of_n_addr_cells(child) + of_n_size_cells(child)) + 1;
>> +
>> + /* allocate a resource array */
>> + res = kcalloc(num, sizeof(*res), GFP_KERNEL);
>> + if (!res) {
>> + ret = -ENOMEM;
>> + goto out;
>> + }
>> +
>> + /* read each reg value */
>> + i = 0;
>> + while (i < size) {
>> + addr = of_read_number(&cell[i],
>> + of_n_addr_cells(child));
>> + i += of_n_addr_cells(child);
>> +
>> + addr_size = of_read_number(&cell[i],
>> + of_n_size_cells(child));
>> + i += of_n_size_cells(child);
>> +
>> + res[iter].start = addr;
>> + res[iter].end = res[iter].start + addr_size - 1;
>> + res[iter].flags = IORESOURCE_MEM;
>
> res->start = …
> …
> res++;
ok
>
>> + iter++;
>> + }
>> +
>> + ret = of_irq_parse_one(child, 0, &out_irq);
>> + if (ret)
>> + goto out;
>> +
>> + res[iter].start = irq_create_of_mapping(&out_irq);
>> + res[iter].name = "hidma event irq";
>> + res[iter].flags = IORESOURCE_IRQ;
>
> Ditto.
ok
>
>> +
>> + pdevinfo.fwnode = &child->fwnode;
>> + pdevinfo.parent = pdev_parent ? &pdev_parent->dev : NULL;
>> + pdevinfo.name = child->name;
>> + pdevinfo.id = object_counter++;
>> + pdevinfo.res = res;
>> + pdevinfo.num_res = num;
>> + pdevinfo.data = NULL;
>> + pdevinfo.size_data = 0;
>> + pdevinfo.dma_mask = DMA_BIT_MASK(64);
>> + platform_device_register_full(&pdevinfo);
>> +
>> + kfree(res);
>> + res = NULL;
>> + }
>> +out:
>
>> + kfree(res);
>
>
>> +
>> + return ret;
>> +}
>> +#endif
>> +
>> +static int __init hidma_mgmt_init(void)
>> +{
>> +#ifdef CONFIG_OF
>> + struct device_node *child;
>> +
>> + for (child = of_find_matching_node(NULL, hidma_mgmt_match); child;
>> + child = of_find_matching_node(child, hidma_mgmt_match)) {
>> + /* device tree based firmware here */
>> + hidma_mgmt_of_populate_channels(child);
>> + of_node_put(child);
>> + }
>
> And why this is can't be done in probe of parent node driver?
The populate function creates platform objects using platform_device_register_full function above.
The hidma device driver later probes the object during object enumeration phase.
I tried moving platform_device_register_full into the probe context. The objects got generated but hidma
device driver didn't probe the object. I suppose we are required to create the objects before the probing starts.
I copied this pattern from another driver.
>
>> +#endif
>> + platform_driver_register(&hidma_mgmt_driver);
>> +
>> + return 0;
>> +}
>> +module_init(hidma_mgmt_init);
>
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
WARNING: multiple messages have this Message-ID (diff)
From: okaya@codeaurora.org (Sinan Kaya)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V10 7/7] dma: qcom_hidma: add support for object hierarchy
Date: Wed, 30 Dec 2015 10:28:30 -0500 [thread overview]
Message-ID: <5683F81E.5050406@codeaurora.org> (raw)
In-Reply-To: <CAHp75Vd-ku1E4+BWGwtL06mO7EZHFmwCvwFiAhLUVwrJHNKD7w@mail.gmail.com>
On 12/19/2015 1:37 PM, Andy Shevchenko wrote:
> On Thu, Dec 17, 2015 at 7:01 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
>> In order to create a relationship model between the channels and the
>> management object, we are adding support for object hierarchy to the
>> drivers. This patch simplifies the userspace application development.
>> We will not have to traverse different firmware paths based on device
>> tree or ACPI baed kernels.
>>
>> No matter what flavor of kernel is used, objects will be represented as
>> platform devices.
>>
>> The new layout is as follows:
>>
>> hidmam_10: hidma-mgmt at 0x5A000000 {
>> compatible = "qcom,hidma-mgmt-1.0";
>> ...
>>
>> hidma_10: hidma at 0x5a010000 {
>> compatible = "qcom,hidma-1.0";
>> ...
>> }
>> }
>>
>> The hidma_mgmt_init detects each instance of the hidma-mgmt-1.0 objects
>> in device tree and calls into the channel driver to create platform devices
>> for each child of the management object.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>
>
>> +What: /sys/devices/platform/hidma-*/chid
>> + /sys/devices/platform/QCOM8061:*/chid
>> +Date: Dec 2015
>> +KernelVersion: 4.4
>> +Contact: "Sinan Kaya <okaya@cudeaurora.org>"
>> +Description:
>> + Contains the ID of the channel within the HIDMA instance.
>> + It is used to associate a given HIDMA channel with the
>> + priority and weight calls in the management interface.
>
>> -module_platform_driver(hidma_mgmt_driver);
>> +#ifdef CONFIG_OF
>> +static int object_counter;
>> +
>> +static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
>> +{
>> + struct platform_device *pdev_parent = of_find_device_by_node(np);
>> + struct platform_device_info pdevinfo;
>> + struct of_phandle_args out_irq;
>> + struct device_node *child;
>> + struct resource *res;
>> + const __be32 *cell;
>
> Always BE ?
Yes, as Timur indicated device tree is big endian all the time.
>
>> + int ret = 0, size, i, num;
>> + u64 addr, addr_size;
>
> resource_size_t
These values are read from the device tree blob using of_read_number function. of_read_number
returns a u64.
>
>> +
>> + for_each_available_child_of_node(np, child) {
>> + int iter = 0;
>> +
>> + cell = of_get_property(child, "reg", &size);
>> + if (!cell) {
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> +
>> + size /= (sizeof(*cell));
>
> Redundant parens. I think it might be good to use common sense for
> operator precedence, here is a radical example of ignoring it. And
> this is not the first case.
Removed. Note that I copied most of this function from another driver.
>
>> + num = size /
>> + (of_n_addr_cells(child) + of_n_size_cells(child)) + 1;
>> +
>> + /* allocate a resource array */
>> + res = kcalloc(num, sizeof(*res), GFP_KERNEL);
>> + if (!res) {
>> + ret = -ENOMEM;
>> + goto out;
>> + }
>> +
>> + /* read each reg value */
>> + i = 0;
>> + while (i < size) {
>> + addr = of_read_number(&cell[i],
>> + of_n_addr_cells(child));
>> + i += of_n_addr_cells(child);
>> +
>> + addr_size = of_read_number(&cell[i],
>> + of_n_size_cells(child));
>> + i += of_n_size_cells(child);
>> +
>> + res[iter].start = addr;
>> + res[iter].end = res[iter].start + addr_size - 1;
>> + res[iter].flags = IORESOURCE_MEM;
>
> res->start = ?
> ?
> res++;
ok
>
>> + iter++;
>> + }
>> +
>> + ret = of_irq_parse_one(child, 0, &out_irq);
>> + if (ret)
>> + goto out;
>> +
>> + res[iter].start = irq_create_of_mapping(&out_irq);
>> + res[iter].name = "hidma event irq";
>> + res[iter].flags = IORESOURCE_IRQ;
>
> Ditto.
ok
>
>> +
>> + pdevinfo.fwnode = &child->fwnode;
>> + pdevinfo.parent = pdev_parent ? &pdev_parent->dev : NULL;
>> + pdevinfo.name = child->name;
>> + pdevinfo.id = object_counter++;
>> + pdevinfo.res = res;
>> + pdevinfo.num_res = num;
>> + pdevinfo.data = NULL;
>> + pdevinfo.size_data = 0;
>> + pdevinfo.dma_mask = DMA_BIT_MASK(64);
>> + platform_device_register_full(&pdevinfo);
>> +
>> + kfree(res);
>> + res = NULL;
>> + }
>> +out:
>
>> + kfree(res);
>
>
>> +
>> + return ret;
>> +}
>> +#endif
>> +
>> +static int __init hidma_mgmt_init(void)
>> +{
>> +#ifdef CONFIG_OF
>> + struct device_node *child;
>> +
>> + for (child = of_find_matching_node(NULL, hidma_mgmt_match); child;
>> + child = of_find_matching_node(child, hidma_mgmt_match)) {
>> + /* device tree based firmware here */
>> + hidma_mgmt_of_populate_channels(child);
>> + of_node_put(child);
>> + }
>
> And why this is can't be done in probe of parent node driver?
The populate function creates platform objects using platform_device_register_full function above.
The hidma device driver later probes the object during object enumeration phase.
I tried moving platform_device_register_full into the probe context. The objects got generated but hidma
device driver didn't probe the object. I suppose we are required to create the objects before the probing starts.
I copied this pattern from another driver.
>
>> +#endif
>> + platform_driver_register(&hidma_mgmt_driver);
>> +
>> + return 0;
>> +}
>> +module_init(hidma_mgmt_init);
>
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-12-30 15:28 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-17 17:01 [PATCH V10 0/7] dma: add Qualcomm Technologies HIDMA driver Sinan Kaya
2015-12-17 17:01 ` Sinan Kaya
2015-12-17 17:01 ` [PATCH V10 1/7] dma: qcom_bam_dma: move to qcom directory Sinan Kaya
2015-12-17 17:01 ` Sinan Kaya
2015-12-17 17:01 ` [PATCH V10 2/7] dma: hidma: Add Device Tree support Sinan Kaya
2015-12-17 17:01 ` Sinan Kaya
2015-12-19 4:17 ` Rob Herring
2015-12-19 4:17 ` Rob Herring
2015-12-21 22:01 ` Okaya
2015-12-21 22:01 ` Okaya at codeaurora.org
2015-12-17 17:01 ` [PATCH V10 3/7] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya
2015-12-17 17:01 ` Sinan Kaya
2015-12-17 17:01 ` [PATCH V10 4/7] dma: add Qualcomm Technologies HIDMA channel driver Sinan Kaya
2015-12-17 17:01 ` Sinan Kaya
2015-12-17 17:01 ` [PATCH V10 5/7] dma: qcom_hidma: implement lower level hardware interface Sinan Kaya
2015-12-17 17:01 ` Sinan Kaya
2015-12-17 17:01 ` [PATCH V10 6/7] dma: qcom_hidma: add debugfs hooks Sinan Kaya
2015-12-17 17:01 ` Sinan Kaya
2015-12-17 17:01 ` [PATCH V10 7/7] dma: qcom_hidma: add support for object hierarchy Sinan Kaya
2015-12-17 17:01 ` Sinan Kaya
2015-12-19 7:14 ` kbuild test robot
2015-12-19 7:14 ` kbuild test robot
2015-12-19 7:14 ` kbuild test robot
2015-12-19 7:37 ` kbuild test robot
2015-12-19 7:37 ` kbuild test robot
2015-12-19 7:37 ` kbuild test robot
2015-12-21 22:05 ` Okaya
2015-12-21 22:05 ` Okaya at codeaurora.org
[not found] ` <1450371684-23415-8-git-send-email-okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-12-19 18:37 ` Andy Shevchenko
2015-12-19 18:37 ` Andy Shevchenko
2015-12-19 18:37 ` Andy Shevchenko
2015-12-21 22:05 ` Timur Tabi
2015-12-21 22:05 ` Timur Tabi
2015-12-30 15:28 ` Sinan Kaya [this message]
2015-12-30 15:28 ` Sinan Kaya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5683F81E.5050406@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=agross@codeaurora.org \
--cc=andy.shevchenko@gmail.com \
--cc=arnd@arndb.de \
--cc=cov@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=jcm@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=timur@codeaurora.org \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.