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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Correct the composition

Dear Arnd:

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.

2018-01-20 19:11 GMT+08:00 Vincent Chen <deanbo422@xxxxxxxxx>:
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux