From: Padma Venkat <padma.kvr@gmail.com> To: Arnd Bergmann <arnd@arndb.de> Cc: Padmavathi Venna <padma.v@samsung.com>, linux-samsung-soc@vger.kernel.org, devicetree-discuss@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, sbkim73@samsung.com, broonie@opensource.wolfsonmicro.com, kgene.kim@samsung.com, jassisinghbrar@gmail.com, vinod.koul@intel.com, grant.likely@secretlab.ca, jon-hunter@ti.com, boojin.kim@samsung.com, thomas.abraham@linaro.org Subject: Re: [PATCH] ARM: SAMSUNG: dma: Remove unnecessary code Date: Tue, 5 Feb 2013 21:24:55 +0530 [thread overview] Message-ID: <CAAgF-Bf4Jhv1AKFdkNMHtrPojHgt2a2L2bg=dJvfsEq=cmbFkg@mail.gmail.com> (raw) In-Reply-To: <201302051113.22720.arnd@arndb.de> Hi Arnd, On Tue, Feb 5, 2013 at 4:43 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Tuesday 05 February 2013, Padma Venkat wrote: >> On Mon, Feb 4, 2013 at 11:13 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> > On Monday 04 February 2013, Padmavathi Venna wrote: >> >> diff --git a/arch/arm/plat-samsung/dma-ops.c b/arch/arm/plat-samsung/dma-ops.c >> >> index 71d58dd..ec0d731 100644 >> >> --- a/arch/arm/plat-samsung/dma-ops.c >> >> +++ b/arch/arm/plat-samsung/dma-ops.c >> >> @@ -23,23 +23,15 @@ static unsigned samsung_dmadev_request(enum dma_ch dma_ch, >> >> struct device *dev, char *ch_name) >> >> { >> >> dma_cap_mask_t mask; >> >> - void *filter_param; >> >> >> >> dma_cap_zero(mask); >> >> dma_cap_set(param->cap, mask); >> >> >> >> - /* >> >> - * If a dma channel property of a device node from device tree is >> >> - * specified, use that as the fliter parameter. >> >> - */ >> >> - filter_param = (dma_ch == DMACH_DT_PROP) ? >> >> - (void *)param->dt_dmach_prop : (void *)dma_ch; >> >> - >> >> if (dev->of_node) >> >> return (unsigned)dma_request_slave_channel(dev, ch_name); >> >> else >> >> return (unsigned)dma_request_channel(mask, pl330_filter, >> >> - filter_param); >> >> + (void *)dma_ch); >> >> } >> > >> > This still looks wrong to me, because the pl330_filter function now tkes >> > a struct dma_pl330_filter_args pointer argument, not dma_ch name. >> >> Below is my understanding about generic dma and our discussion on >> previous versions of my patches. >> >> I can’t pass single dma channel number(may be not dma_ch name in your >> comment above) as void* argument to pl330_filter. Because I also need >> to compare against the dma controller device node, as my requested >> channel can belong to any of the available dma controller on SoC. So >> I either need to pass pointer to dma_spec as void* argument which >> holds the dma controller node and required channel number or I can >> pass pointer to dma_pl330_filter_args as per your dw_dmac patches. > > Right. > >> If I pass pointer to dma_spec I can have a check like below in my >> filter function >> return ((chan->private == dma_spec->np) && (chan->chan_id == dma_spec->args[0])) >> >> Or if I pass dma_pl330_filter_args I can have a check like below. >> return ((chan->device == &fargs->pdmac->ddma) && (chan->chan_id == >> fargs->chan_id)); >> >> I modified the pl330_filter function based on your dw_dmac patches. >> Indeed I don’t need to pass pointer to pdmac object as 3rd arg in >> of_dma_controller_register . Even I pass NULL here works for me. >> Can I pass NULL here as the third argument in of_dma_controller_register? > > These are all not the issues I am referring to in my comment above. > I think it works either way, even if you pass NULL to > of_dma_controller_register, although using it for the pdmac object > seems cleaner to me. > >> Please clarify me which is best way of doing this and correct me if my >> understanding is wrong. > > My point was that in the samsung_dmadev_request quoted above, you > refer to the same pl330_filter filter function, but the argument there > is a pointer to 'enum dma_ch', which is not compatible with any of > the methods you list, neither the dma_pl330_filter_args nor the > raw property. > > Also, if you change the calling conventions for the pl330_filter > function, you should change both the caller and the function in the > same patch. In none of my patches I have changed the pl330_filter args. This function always takes the same argument void*. In non-DT case 'enum dma_ch' was typecasted to void* and in DT case I am passing a pointer to dma_pl330_filter_args and in pl330_filter function they are converted back. In both cases it finally comes down to dma_request_channel which takes them as void* which in turn calls the pl330_filter. I think this is what you are pointing to. Please let me know if I am still wrong :( . > > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Thanks Padma
WARNING: multiple messages have this Message-ID (diff)
From: padma.kvr@gmail.com (Padma Venkat) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] ARM: SAMSUNG: dma: Remove unnecessary code Date: Tue, 5 Feb 2013 21:24:55 +0530 [thread overview] Message-ID: <CAAgF-Bf4Jhv1AKFdkNMHtrPojHgt2a2L2bg=dJvfsEq=cmbFkg@mail.gmail.com> (raw) In-Reply-To: <201302051113.22720.arnd@arndb.de> Hi Arnd, On Tue, Feb 5, 2013 at 4:43 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Tuesday 05 February 2013, Padma Venkat wrote: >> On Mon, Feb 4, 2013 at 11:13 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> > On Monday 04 February 2013, Padmavathi Venna wrote: >> >> diff --git a/arch/arm/plat-samsung/dma-ops.c b/arch/arm/plat-samsung/dma-ops.c >> >> index 71d58dd..ec0d731 100644 >> >> --- a/arch/arm/plat-samsung/dma-ops.c >> >> +++ b/arch/arm/plat-samsung/dma-ops.c >> >> @@ -23,23 +23,15 @@ static unsigned samsung_dmadev_request(enum dma_ch dma_ch, >> >> struct device *dev, char *ch_name) >> >> { >> >> dma_cap_mask_t mask; >> >> - void *filter_param; >> >> >> >> dma_cap_zero(mask); >> >> dma_cap_set(param->cap, mask); >> >> >> >> - /* >> >> - * If a dma channel property of a device node from device tree is >> >> - * specified, use that as the fliter parameter. >> >> - */ >> >> - filter_param = (dma_ch == DMACH_DT_PROP) ? >> >> - (void *)param->dt_dmach_prop : (void *)dma_ch; >> >> - >> >> if (dev->of_node) >> >> return (unsigned)dma_request_slave_channel(dev, ch_name); >> >> else >> >> return (unsigned)dma_request_channel(mask, pl330_filter, >> >> - filter_param); >> >> + (void *)dma_ch); >> >> } >> > >> > This still looks wrong to me, because the pl330_filter function now tkes >> > a struct dma_pl330_filter_args pointer argument, not dma_ch name. >> >> Below is my understanding about generic dma and our discussion on >> previous versions of my patches. >> >> I can?t pass single dma channel number(may be not dma_ch name in your >> comment above) as void* argument to pl330_filter. Because I also need >> to compare against the dma controller device node, as my requested >> channel can belong to any of the available dma controller on SoC. So >> I either need to pass pointer to dma_spec as void* argument which >> holds the dma controller node and required channel number or I can >> pass pointer to dma_pl330_filter_args as per your dw_dmac patches. > > Right. > >> If I pass pointer to dma_spec I can have a check like below in my >> filter function >> return ((chan->private == dma_spec->np) && (chan->chan_id == dma_spec->args[0])) >> >> Or if I pass dma_pl330_filter_args I can have a check like below. >> return ((chan->device == &fargs->pdmac->ddma) && (chan->chan_id == >> fargs->chan_id)); >> >> I modified the pl330_filter function based on your dw_dmac patches. >> Indeed I don?t need to pass pointer to pdmac object as 3rd arg in >> of_dma_controller_register . Even I pass NULL here works for me. >> Can I pass NULL here as the third argument in of_dma_controller_register? > > These are all not the issues I am referring to in my comment above. > I think it works either way, even if you pass NULL to > of_dma_controller_register, although using it for the pdmac object > seems cleaner to me. > >> Please clarify me which is best way of doing this and correct me if my >> understanding is wrong. > > My point was that in the samsung_dmadev_request quoted above, you > refer to the same pl330_filter filter function, but the argument there > is a pointer to 'enum dma_ch', which is not compatible with any of > the methods you list, neither the dma_pl330_filter_args nor the > raw property. > > Also, if you change the calling conventions for the pl330_filter > function, you should change both the caller and the function in the > same patch. In none of my patches I have changed the pl330_filter args. This function always takes the same argument void*. In non-DT case 'enum dma_ch' was typecasted to void* and in DT case I am passing a pointer to dma_pl330_filter_args and in pl330_filter function they are converted back. In both cases it finally comes down to dma_request_channel which takes them as void* which in turn calls the pl330_filter. I think this is what you are pointing to. Please let me know if I am still wrong :( . > > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Thanks Padma
next prev parent reply other threads:[~2013-02-05 15:54 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-04 8:47 [PATCH] ARM: SAMSUNG: dma: Remove unnecessary code Padmavathi Venna 2013-02-04 8:47 ` Padmavathi Venna 2013-02-04 17:43 ` Arnd Bergmann 2013-02-04 17:43 ` Arnd Bergmann 2013-02-05 8:04 ` Padma Venkat 2013-02-05 8:04 ` Padma Venkat 2013-02-05 11:13 ` Arnd Bergmann 2013-02-05 11:13 ` Arnd Bergmann 2013-02-05 15:54 ` Padma Venkat [this message] 2013-02-05 15:54 ` Padma Venkat 2013-02-05 23:51 ` Arnd Bergmann 2013-02-05 23:51 ` Arnd Bergmann 2013-02-14 3:47 Padmavathi Venna 2013-02-14 3:47 ` Padmavathi Venna
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='CAAgF-Bf4Jhv1AKFdkNMHtrPojHgt2a2L2bg=dJvfsEq=cmbFkg@mail.gmail.com' \ --to=padma.kvr@gmail.com \ --cc=arnd@arndb.de \ --cc=boojin.kim@samsung.com \ --cc=broonie@opensource.wolfsonmicro.com \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=grant.likely@secretlab.ca \ --cc=jassisinghbrar@gmail.com \ --cc=jon-hunter@ti.com \ --cc=kgene.kim@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=padma.v@samsung.com \ --cc=sbkim73@samsung.com \ --cc=thomas.abraham@linaro.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: linkBe 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.