[U-Boot] [RFC] 0/4] Add Pl330 DMA support

[Dinh Nguyen]

On Tue, Nov 1, 2016 at 3:43 PM, Dinh Nguyen <dinguyen at kernel.org> wrote:
>
>
> On 11/01/2016 03:42 PM, Marek Vasut wrote:
>> On 11/01/2016 09:39 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 11/01/2016 03:09 PM, Marek Vasut wrote:
>>>> On 11/01/2016 04:43 PM, Dinh Nguyen wrote:
>>>>>
>>>>>
>>>>> On 10/29/2016 02:59 PM, Marek Vasut wrote:
>>>>>> On 10/18/2016 05:50 PM, Dinh Nguyen wrote:
>>>>>>> On Sun, Oct 16, 2016 at 10:59 AM, Marek Vasut <marex at denx.de> wrote:
>>>>>>>> On 10/15/2016 12:10 AM, Dinh Nguyen wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/10/2016 10:52 AM, Dinh Nguyen wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes
>>>>>>>>>> use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
>>>>>>>>>>
>>>>>>>>>> This is only an RFC because after rebasing to v2016.11-rc1, I had to revert
>>>>>>>>>> the following patch "a78cd8613204 ARM: Rework and correct barrier definitions"
>>>>>>>>>> in order for this patch set to work correctly. With the above patch applied,
>>>>>>>>>> after the SDRAM scrubbing is complete, the SPL is failing to find the MMC
>>>>>>>>>> device.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I kinda figured out why patch "a78cd8613204 ARM: Rework and correct
>>>>>>>>> barrier definitions" is causing SPL to fail after the SDRAM scrub
>>>>>>>>> operation. It appears that before the above mentioned patch, the dmb()
>>>>>>>>> operation is defined as this:
>>>>>>>>>
>>>>>>>>> #define dmb()          __asm__ __volatile__ ("" : : : "memory")
>>>>>>>>>
>>>>>>>>> after the patch, the dmb is now:
>>>>>>>>>
>>>>>>>>> #define DMB    asm volatile ("dmb sy" : : : "memory")
>>>>>>>>>
>>>>>>>>> So the "dmb sy" as described in the ARM documentation is a "Full system
>>>>>>>>> DMB operation". For whatever reason, this change is causing the SPL
>>>>>>>>> error after the SDRAM scrub operation.
>>>>>>>>
>>>>>>>> Thanks for looking into this, can you poke into it some more ?
>>>>>>>>
>>>>>>>
>>>>>>> Of course..
>>>>>>
>>>>>> The patch is causing a failure even in normal operation -- if you boot
>>>>>> the socfpga board and type "reset", it won't reset with the patch.
>>>>>>
>>>>>
>>>>> Can I ask what board are you seeing this on? I'm seeing that on my Atlas
>>>>> board, it does not reset properly(even with the patch reverted). But
>>>>> "reset" is working fine on my devkit, with and without the patch.
>>>>
>>>> SoCKit and MCVEVK.
>>>>
>>>> I tried bisecting it, it worked on 2016.07 and doesn't on 2016.09 , and
>>>> I arrived at this patch. Maybe you can double-check this ?
>>>>
>>>
>>> Okay, I can check it on the SoCKit.
>>
>> It also happens on MCVEVK, but that's probably moot for your test ;-)
>>
>
> I don't have an MCVEVK.
>

The "reset" functionality is working fine on the SoCKit with 2016.11-rc3.

Dinh