linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: k.kozlowski@samsung.com (Krzysztof Kozlowski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] ASoC: samsung: pass DMA channels as pointers
Date: Wed, 18 Nov 2015 10:26:49 +0900	[thread overview]
Message-ID: <564BD3D9.7000701@samsung.com> (raw)
In-Reply-To: <25607973.ZAWqqjj8F4@wuerfel>

On 17.11.2015 19:24, Arnd Bergmann wrote:
> On Tuesday 17 November 2015 10:16:36 Krzysztof Kozlowski wrote:
>> On 14.11.2015 02:22, Arnd Bergmann wrote:
>>> ARM64 allmodconfig produces a bunch of warnings when building the
>>> samsung ASoC code:
>>>
>>> sound/soc/samsung/dmaengine.c: In function 'samsung_asoc_init_dma_data':
>>> sound/soc/samsung/dmaengine.c:53:32: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>>>    playback_data->filter_data = (void *)playback->channel;
>>> sound/soc/samsung/dmaengine.c:60:31: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>>>    capture_data->filter_data = (void *)capture->channel;
>>>
>>> We could easily shut up the warning by adding an intermediate cast,
>>> but there is a bigger underlying problem: The use of IORESOURCE_DMA
>>> to pass data from platform code to device drivers is dubious to start
>>> with, as what we really want is a pointer that can be passed into
>>> a filter function.
>>>
>>> Note that on s3c64xx, the pl08x DMA data is already a pointer, but
>>> gets cast to resource_size_t so we can pass it as a resource, and it
>>> then gets converted back to a pointer. In contrast, the data we pass
>>> for s3c24xx is an index into a device specific table, and we artificially
>>> convert that into a pointer for the filter function.
>>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>
>> The patch looks good. I have only two questions below.
> 
> Thanks for taking a look!
> 
>>> @@ -1338,11 +1325,8 @@ static int samsung_i2s_probe(struct platform_device *pdev)
>>>               sec_dai->dma_playback.dma_addr = regs_base + I2STXDS;
>>>               sec_dai->dma_playback.ch_name = "tx-sec";
>>>  
>>> -             if (!np) {
>>> -                     res = platform_get_resource(pdev, IORESOURCE_DMA, 2);
>>> -                     if (res)
>>> -                             sec_dai->dma_playback.channel = res->start;
>>> -             }
>>> +             if (!np)
>>> +                     sec_dai->dma_playback.slave = i2s_pdata->dma_play_sec;
>>
>> I cannot this resource in original patch nor setting the 'dma_play_sec'
>> part. I guess this does not really matter as newer platforms were
>> converted to DT so 'np' will be set, right?
> 
> Yes, that sounds correct.
> 
>>> @@ -367,12 +367,6 @@ static int spdif_probe(struct platform_device *pdev)
>>>  
>>>       dev_dbg(&pdev->dev, "Entered %s\n", __func__);
>>>  
>>> -     dma_res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
>>> -     if (!dma_res) {
>>> -             dev_err(&pdev->dev, "Unable to get dma resource.\n");
>>> -             return -ENXIO;
>>> -     }
>>> -
>>>       mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>       if (!mem_res) {
>>>               dev_err(&pdev->dev, "Unable to get register resource.\n");
>>> @@ -432,7 +426,7 @@ static int spdif_probe(struct platform_device *pdev)
>>>  
>>>       spdif_stereo_out.dma_size = 2;
>>>       spdif_stereo_out.dma_addr = mem_res->start + DATA_OUTBUF;
>>> -     spdif_stereo_out.channel = dma_res->start;
>>> +     spdif_stereo_out.slave = spdif_pdata->dma_playback;
>>>  
>>>       spdif->dma_playback = &spdif_stereo_out;
>>
>> No one sets ioresources and pdata for spdif device. No in-kernel board
>> files for it?
> 
> Hmm, probably also a missing conversion to devicetree. The symbol used to be 
> 
>  config SND_SOC_SAMSUNG_SMDK_SPDIF
>         tristate "SoC S/PDIF Audio support for SMDK"
> -       depends on SND_SOC_SAMSUNG && (MACH_SMDKC100 || MACH_SMDKC110 || MACH_SMDKV210 || MACH_SMDKV310 || MACH_SMDK4212)
> +       depends on SND_SOC_SAMSUNG
>         select SND_SAMSUNG_SPDIF
> 
> We still support all four of the above boards, but they are all DT-only
> and neither spdif.c nor smdk-spdif.c ever gained DT support. Is there
> anything I should change in this patch for this?

No, I think it is okay. I'll review the v2 you sent.

Best regards,
Krzysztof

      reply	other threads:[~2015-11-18  1:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-13 17:22 [PATCH 1/3] ASoC: samsung: pass DMA channels as pointers Arnd Bergmann
2015-11-13 17:23 ` [PATCH 2/3] ASoC: s3c24xx-i2s: pass DMA channels as platform data Arnd Bergmann
2015-11-17  1:36   ` Krzysztof Kozlowski
2015-11-17 10:19     ` Arnd Bergmann
2015-11-13 17:24 ` [PATCH 3/3] ASoC: samsung: pass filter function as pointer Arnd Bergmann
2015-11-17  0:45   ` Krzysztof Kozlowski
2015-11-17 10:25     ` Arnd Bergmann
2015-11-17  1:16 ` [PATCH 1/3] ASoC: samsung: pass DMA channels as pointers Krzysztof Kozlowski
2015-11-17 10:24   ` Arnd Bergmann
2015-11-18  1:26     ` Krzysztof Kozlowski [this message]

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=564BD3D9.7000701@samsung.com \
    --to=k.kozlowski@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).