2018-01-18 19:08 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>:
> On Mon, Jan 15, 2018 at 6:57 AM, Greentime Hu <green.hu@xxxxxxxxx> wrote:
>> From: Rick Chen <rickchen36@xxxxxxxxx>
>>
>> VDSO needs real-time cycle count to ensure the time accuracy.
>> Unlike others, nds32 architecture does not define clock source,
>> hence VDSO needs atcpit100 offering real-time cycle count
>> to derive the correct time.
>>
>> Signed-off-by: Vincent Chen <vincentc@xxxxxxxxxxxxx>
>> Signed-off-by: Rick Chen <rickchen36@xxxxxxxxx>
>> Signed-off-by: Greentime Hu <green.hu@xxxxxxxxx>
>
> I'm a bit puzzled by this patch, can you explain how the vdso actually
> manages to access the clock hardware? It looks like you make the
> physical address and the register offset available to user space, but
> how does it end up accessing it?
>
> Arnd
Dear Arnd:
Accessing clock hardware in vdso can be divided to 2 step.
1. Setup an additional memory mapping for clock hardware in user space
when establishing
vdso-needed memory mapping
In arch_setup_additional_pages(), kernel establishes memory
mapping for vdso's text and vdata page
in user space. In order to make clock hardware be accessible in
user space, we try to establish an
additional memory mapping for clock hardware here based on clock
information from driver. This page is
located between vdata page and vdso text page. For safety, this
region for clock accessing is read-only.
2. Accessing clock hardware in vdso
After step 1, clock hardware is accessible in user space
through memory-mapped IO. However, it is not
enough to access a specific register. Therefore, we store register
offset information in vdata page to make it
visible in user space. Now, vdso can derive the address of counter
register by summation of __get_timerpage()
and counter register offset where __get_timerpage() is used to
derive the virtual address of memory-mapped
clock.
Vincent
