[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OS3PR01MB65937881AFAA1D8C575E63DABADC9@OS3PR01MB6593.jpnprd01.prod.outlook.com>
Date: Thu, 16 Sep 2021 15:54:52 +0000
From: Min Li <min.li.xe@...esas.com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: "arnd@...db.de" <arnd@...db.de>,
"derek.kiernan@...inx.com" <derek.kiernan@...inx.com>,
"dragan.cvetic@...inx.com" <dragan.cvetic@...inx.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"lee.jones@...aro.or" <lee.jones@...aro.or>
Subject: RE: [PATCH misc v2 2/2] misc: Add Renesas Synchronization Management
Unit (SMU) support
>
> Please put that link in the changelog comment and in the .c code as well so
> that people know where to find it.
>
> > >
> > > Why is this new api not a standard one?
> > >
> >
> > There is no actual standard for the GNSS assisted partial timing
> > support (APTS) In terms of Linux kernel API
>
> Then make one! :)
Yes it is on our roadmap to do that for next release
>
> > > What is the standard here?
> > >
> > > What do other devices do and why is this a new api?
> > >
> >
> > There is really no standard for APTS and different company has its own
> > hw/sw solutions
>
> But userspace has to all deal with this in a standard way somehow, right?
> What libraries and apis do they interact with there?
So far there is none. Some companies just use userspace driver and don't bother
kernel
>
> > > > Current version provides kernel API's to support the following
> > > > functions -set combomode to enable SYNCE clock support -read
> > > > dpll's state to determine if the dpll is locked to the GNSS
> > > > channel -read dpll's ffo (fractional frequency offset) in ppqt
> > >
> > > Why do all of these have to be in the kernel at all?
> > >
> >
> > Because all these API's need spi/i2c accesses to the RSMU card and
> > spi/i2c accesses have been abstracted to the MFD driver in kernel
>
> Why not just do this all from userspace then? You can have spi/i2c
> userspace code, right? Why does this have to be a kernel driver?
>
We used to do everything in userspace. But since PHC (ptp hardware clock) came along, we decided
to move the driver part to kernel. Please take a look at drivers/ptp/ptp_clockmatrix.c for reference.
Recently, we have some functions like APTS that doesn't belong to PTP or anything else so we have to split those functions
to RSMU misc driver and i2c/spi bus accesses to RSMU MFD driver.
Powered by blists - more mailing lists