lkml.org 
[lkml]   [2010]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] PL330: Add PL330 DMA controller driver
On 3/25/2010 7:32 PM, Marc Zyngier wrote:
> On Thu, 25 Mar 2010 19:05:47 +0900, Joonyoung Shim
> <jy0922.shim@samsung.com> wrote:
>> On 3/25/2010 6:32 PM, Marc Zyngier wrote:
>>> On Thu, 25 Mar 2010 18:01:00 +0900, Joonyoung Shim
>>> <jy0922.shim@samsung.com> wrote:
>>>> On 3/25/2010 2:44 PM, Marc Zyngier wrote:
>>>>> On Thu, 25 Mar 2010 12:17:15 +0900
>>>>> Joonyoung Shim <jy0922.shim@samsung.com> wrote:
>>>>>
>>>>>> + writew(imm, desc_pool_virt);
>>>> Right. The write[bwl] is api for address ioremapped of io device. I
> will
>>>> change these.
>>>>
>>>>> Does anything ensure that this won't generate an unaligned access?
>>>>>
>>>> PL330 DMA controller fetches variable length instructions that consist
>>> of
>>>> one to six bytes, so i think unaligned access is no problem.
>>> I'm not too concerned about the device side of things. I'm more worried
>>> about the CPU access when writing the 'imm' value to memory.
>>>
>>> Consider desc_pool_virt 16bit aligned when entering the function.
> Writing
>>> the opcode makes it unaligned and then writing the 'imm' value will
>>> result
>>> as an unaligned access.
>>>
>> Why desc_pool_virt should be aligned more than 16bit?
>
> There is reason for desc_pool_virt to be 16bit aligned. It's just that you
> have 50% chance that it will.
> In such case, you will write 'imm' to a non 16bit-aligned address. In my
> book, that's bad.
>
> Same for pl330_dmamov(), which tries to write a 32bit value without
> checking the proper alignment.
> In such case, please use the put_unaligned macro to handle the possible
> unaligned access.
>

OK. i will use put_unaligned.
Thanks.


\
 
 \ /
  Last update: 2010-03-25 12:51    [W:0.079 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site