All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.