Re: [PATCH v6 2/3] clocksource/drivers/atcpit100: VDSO support

[Vincent Chen]

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