Build warning in drivers/dma/mmp_tdma.c

[zhouqiao@marvell.com (Qiao Zhou)]

On 12/04/2013 10:34 AM, Zhangfei Gao wrote:
> On Wed, Dec 4, 2013 at 10:28 AM, Qiao Zhou <zhouqiao@marvell.com> wrote:
>> On 12/04/2013 10:15 AM, Dan Williams wrote:
>>>
>>> On Tue, Dec 3, 2013 at 5:58 PM, Qiao Zhou <zhouqiao@marvell.com> wrote:
>>>>
>>>> On 12/04/2013 09:32 AM, Dan Williams wrote:
>>>>>
>>>>>
>>>>> Please read the question, you can refer to of_get_named_gen_pool() for
>>>>> why I have a question.  Something in the system needs to do the
>>>>> devm_gen_pool_create() for that device.  If you are removing the mmp2
>>>>> sram driver are you switching to the generic sram driver?  If so
>>>>> shouldn't you ensure it is built? Otherwise this will always fail:
>>>>
>>>>
>>>> For CPU_MMP2 specifically, it switches to use generic sram driver. But
>
> Do you mean CPU_MMP2 still need arch/arm/mach-mmp/sram.c?
> Is it can be replaced by drivers/misc/sram.c and be removed at all?
> So only "SRAM" is depends or selected.
drivers/misc/sram.c is enough for CPU_MMP2.
>
>>>> generally it may not use sram only, a DDR buffer(or other buffer) may
>>>> also
>>>> be a pool. So here we don't add "select SRAM" directly. In this case we
>>>> need
>>>> to enable CONFIG_SRAM in mmp2_defconfig.
>>>>
>>>> If no sram or other similar drivers are enabled, it will throw an error
>>>> for
>>>> warning.
>>>>
>>>
>>> Ok, So, please turn this into a compile time dependency (depends on
>>> (SRAM || MMP_SRAM)) so that someone does not need to boot a platform
>>> to figure out they forgot to enable a driver.
>>>
>> Actually I'm not sure it's good to add such dependency.
>> sound/core/memalloc.c provides the same way for sram buffer allocation. It
>> doesn't add such dependency.
>
> SRAM can be selected or depended, while MMP_SRAM should be removed latter.
OK.
>>
>> Zhangfei, Haojian, how do you think?
>>
>> --
>>
>> Best Regards
>> Qiao

-- 

Best Regards
Qiao