Hi Marcel,
Sorry about the late reply. I got side-tracked with other things.
On Tue, May 08, 2018 at 10:03:57PM +0200, Marcel Holtmann wrote:
> Hi Johan,
>
> >> I have one concern, though. While providing raw data by
> >> default is fine generally, it is a problem with device
> >>
Hi Marcel,
Sorry about the late reply. I got side-tracked with other things.
On Tue, May 08, 2018 at 10:03:57PM +0200, Marcel Holtmann wrote:
> Hi Johan,
>
> >> I have one concern, though. While providing raw data by
> >> default is fine generally, it is a problem with device
> >>
Hi Johan,
>> I have one concern, though. While providing raw data by
>> default is fine generally, it is a problem with device
>> auto-discovery. I think there should be some IOCTL from
>> the start, that can be used to inform userspace about
>> the raw protocol being used
Hi Johan,
>> I have one concern, though. While providing raw data by
>> default is fine generally, it is a problem with device
>> auto-discovery. I think there should be some IOCTL from
>> the start, that can be used to inform userspace about
>> the raw protocol being used
On Tue, May 08, 2018 at 09:49:36AM +0200, Marcel Holtmann wrote:
> Hi Johan,
>
> I have one concern, though. While providing raw data by
> default is fine generally, it is a problem with device
> auto-discovery. I think there should be some IOCTL from
> the start, that can be
On Tue, May 08, 2018 at 09:49:36AM +0200, Marcel Holtmann wrote:
> Hi Johan,
>
> I have one concern, though. While providing raw data by
> default is fine generally, it is a problem with device
> auto-discovery. I think there should be some IOCTL from
> the start, that can be
Hi Johan,
I have one concern, though. While providing raw data by
default is fine generally, it is a problem with device
auto-discovery. I think there should be some IOCTL from
the start, that can be used to inform userspace about
the raw protocol being used (i.e.
Hi Johan,
I have one concern, though. While providing raw data by
default is fine generally, it is a problem with device
auto-discovery. I think there should be some IOCTL from
the start, that can be used to inform userspace about
the raw protocol being used (i.e.
On Mon, May 07, 2018 at 09:06:44PM +0200, Marcel Holtmann wrote:
> >> I have one concern, though. While providing raw data by
> >> default is fine generally, it is a problem with device
> >> auto-discovery. I think there should be some IOCTL from
> >> the start, that can be used to inform
On Mon, May 07, 2018 at 09:06:44PM +0200, Marcel Holtmann wrote:
> >> I have one concern, though. While providing raw data by
> >> default is fine generally, it is a problem with device
> >> auto-discovery. I think there should be some IOCTL from
> >> the start, that can be used to inform
Hi Johan,
>>> This series adds a new subsystem for GNSS receivers (e.g. GPS
>>> receivers).
>>>
>>> While GNSS receivers are typically accessed using a UART interface they
>>> often also support other I/O interfaces such as I2C, SPI and USB, while
>>> yet other devices use iomem or even some
Hi Johan,
>>> This series adds a new subsystem for GNSS receivers (e.g. GPS
>>> receivers).
>>>
>>> While GNSS receivers are typically accessed using a UART interface they
>>> often also support other I/O interfaces such as I2C, SPI and USB, while
>>> yet other devices use iomem or even some
On Fri, May 04, 2018 at 03:27:41PM +0200, Sebastian Reichel wrote:
> Hi Johan,
>
> On Tue, Apr 24, 2018 at 06:34:51PM +0200, Johan Hovold wrote:
> > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > receivers).
> >
> > While GNSS receivers are typically accessed using a UART
On Fri, May 04, 2018 at 03:27:41PM +0200, Sebastian Reichel wrote:
> Hi Johan,
>
> On Tue, Apr 24, 2018 at 06:34:51PM +0200, Johan Hovold wrote:
> > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > receivers).
> >
> > While GNSS receivers are typically accessed using a UART
Hi Pavel,
(*) I have those in mind:
Nokia N900: The phone has GPS integrated into the modem and uses
ISI encapsulated data. The protocol has been reverse engineered
and it should be possible to write a kernel driver for handling
the GPS packets and dumping the raw
Hi Pavel,
(*) I have those in mind:
Nokia N900: The phone has GPS integrated into the modem and uses
ISI encapsulated data. The protocol has been reverse engineered
and it should be possible to write a kernel driver for handling
the GPS packets and dumping the raw
Hi!
> > > (*) I have those in mind:
> > >
> > > Nokia N900: The phone has GPS integrated into the modem and uses
> > > ISI encapsulated data. The protocol has been reverse engineered
> > > and it should be possible to write a kernel driver for handling
> > > the GPS packets and dumping the raw
Hi!
> > > (*) I have those in mind:
> > >
> > > Nokia N900: The phone has GPS integrated into the modem and uses
> > > ISI encapsulated data. The protocol has been reverse engineered
> > > and it should be possible to write a kernel driver for handling
> > > the GPS packets and dumping the raw
Hi,
On Fri, May 04, 2018 at 10:03:15PM +0200, Pavel Machek wrote:
> > > Finally, note that documentation (including kerneldoc) remains to be
> > > written, but hopefully this will not hinder review given that the
> > > current interfaces are fairly self-describing.
> >
> > Great work. I like
Hi,
On Fri, May 04, 2018 at 10:03:15PM +0200, Pavel Machek wrote:
> > > Finally, note that documentation (including kerneldoc) remains to be
> > > written, but hopefully this will not hinder review given that the
> > > current interfaces are fairly self-describing.
> >
> > Great work. I like
Hi!
> > Finally, note that documentation (including kerneldoc) remains to be
> > written, but hopefully this will not hinder review given that the
> > current interfaces are fairly self-describing.
>
> Great work. I like your design decisions. I have quite a few devices
> with have non-serial
Hi!
> > Finally, note that documentation (including kerneldoc) remains to be
> > written, but hopefully this will not hinder review given that the
> > current interfaces are fairly self-describing.
>
> Great work. I like your design decisions. I have quite a few devices
> with have non-serial
Hi Johan,
On Tue, Apr 24, 2018 at 06:34:51PM +0200, Johan Hovold wrote:
> This series adds a new subsystem for GNSS receivers (e.g. GPS
> receivers).
>
> While GNSS receivers are typically accessed using a UART interface they
> often also support other I/O interfaces such as I2C, SPI and USB,
Hi Johan,
On Tue, Apr 24, 2018 at 06:34:51PM +0200, Johan Hovold wrote:
> This series adds a new subsystem for GNSS receivers (e.g. GPS
> receivers).
>
> While GNSS receivers are typically accessed using a UART interface they
> often also support other I/O interfaces such as I2C, SPI and USB,
On Thu, Apr 26, 2018 at 12:10:02PM +0200, H. Nikolaus Schaller wrote:
> > Am 25.04.2018 um 10:11 schrieb Johan Hovold :
> >
> > On Tue, Apr 24, 2018 at 09:44:08PM +0200, H. Nikolaus Schaller wrote:
> >
> >>> Am 24.04.2018 um 19:50 schrieb Johan Hovold :
> >>
On Thu, Apr 26, 2018 at 12:10:02PM +0200, H. Nikolaus Schaller wrote:
> > Am 25.04.2018 um 10:11 schrieb Johan Hovold :
> >
> > On Tue, Apr 24, 2018 at 09:44:08PM +0200, H. Nikolaus Schaller wrote:
> >
> >>> Am 24.04.2018 um 19:50 schrieb Johan Hovold :
> >> You could have simply reused what
Hi Johan,
> Am 25.04.2018 um 10:11 schrieb Johan Hovold :
>
> On Tue, Apr 24, 2018 at 09:44:08PM +0200, H. Nikolaus Schaller wrote:
>
>>> Am 24.04.2018 um 19:50 schrieb Johan Hovold :
>
>>> I think it should be done the other way round (if I understand you
Hi Johan,
> Am 25.04.2018 um 10:11 schrieb Johan Hovold :
>
> On Tue, Apr 24, 2018 at 09:44:08PM +0200, H. Nikolaus Schaller wrote:
>
>>> Am 24.04.2018 um 19:50 schrieb Johan Hovold :
>
>>> I think it should be done the other way round (if I understand you
>>> correctly), that is, by adding
On Wed, Apr 25, 2018 at 10:48:19AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 24, 2018 at 06:34:51PM +0200, Johan Hovold wrote:
> > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > receivers).
>
> YEAH
>
> Thanks so much for doing this, great work!
Thanks!
> > This all
On Wed, Apr 25, 2018 at 10:48:19AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 24, 2018 at 06:34:51PM +0200, Johan Hovold wrote:
> > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > receivers).
>
> YEAH
>
> Thanks so much for doing this, great work!
Thanks!
> > This all
On Tue, Apr 24, 2018 at 06:34:51PM +0200, Johan Hovold wrote:
> This series adds a new subsystem for GNSS receivers (e.g. GPS
> receivers).
YEAH
Thanks so much for doing this, great work!
> While GNSS receivers are typically accessed using a UART interface they
> often also support other
On Tue, Apr 24, 2018 at 06:34:51PM +0200, Johan Hovold wrote:
> This series adds a new subsystem for GNSS receivers (e.g. GPS
> receivers).
YEAH
Thanks so much for doing this, great work!
> While GNSS receivers are typically accessed using a UART interface they
> often also support other
On Tue, Apr 24, 2018 at 09:44:08PM +0200, H. Nikolaus Schaller wrote:
> > Am 24.04.2018 um 19:50 schrieb Johan Hovold :
> > I think it should be done the other way round (if I understand you
> > correctly), that is, by adding support for configurations were WAKEUP is
> > left
On Tue, Apr 24, 2018 at 09:44:08PM +0200, H. Nikolaus Schaller wrote:
> > Am 24.04.2018 um 19:50 schrieb Johan Hovold :
> > I think it should be done the other way round (if I understand you
> > correctly), that is, by adding support for configurations were WAKEUP is
> > left not connected to
On Tue, Apr 24, 2018 at 10:59:48PM +0200, Andreas Kemnade wrote:
> On Tue, 24 Apr 2018 22:13:19 +0200
> Pavel Machek wrote:
>
> > Hi!
> >
> > > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > > receivers).
> >
> > Actually... I'd just call it GPS subsystem.
On Tue, Apr 24, 2018 at 10:59:48PM +0200, Andreas Kemnade wrote:
> On Tue, 24 Apr 2018 22:13:19 +0200
> Pavel Machek wrote:
>
> > Hi!
> >
> > > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > > receivers).
> >
> > Actually... I'd just call it GPS subsystem. Yes, GPS is a
On Tue, Apr 24, 2018 at 10:13:19PM +0200, Pavel Machek wrote:
> Hi!
>
> > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > receivers).
>
> Actually... I'd just call it GPS subsystem. Yes, GPS is a bit
> misleading, but so is GNSS. We'd like Loran to use similar interface,
>
On Tue, Apr 24, 2018 at 10:13:19PM +0200, Pavel Machek wrote:
> Hi!
>
> > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > receivers).
>
> Actually... I'd just call it GPS subsystem. Yes, GPS is a bit
> misleading, but so is GNSS. We'd like Loran to use similar interface,
>
On Wed, Apr 25, 2018 at 08:26:59AM +0200, Pavel Machek wrote:
> Hi!
>
> > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > receivers).
> >
> > While GNSS receivers are typically accessed using a UART interface they
> > often also support other I/O interfaces such as I2C, SPI and
On Wed, Apr 25, 2018 at 08:26:59AM +0200, Pavel Machek wrote:
> Hi!
>
> > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > receivers).
> >
> > While GNSS receivers are typically accessed using a UART interface they
> > often also support other I/O interfaces such as I2C, SPI and
Hi Pavel,
>> This series adds a new subsystem for GNSS receivers (e.g. GPS
>> receivers).
>
> Actually... I'd just call it GPS subsystem. Yes, GPS is a bit
> misleading, but so is GNSS. We'd like Loran to use similar interface,
> right? We'd like to QZSS to use similar interface, too…
GNSS is
Hi Pavel,
>> This series adds a new subsystem for GNSS receivers (e.g. GPS
>> receivers).
>
> Actually... I'd just call it GPS subsystem. Yes, GPS is a bit
> misleading, but so is GNSS. We'd like Loran to use similar interface,
> right? We'd like to QZSS to use similar interface, too…
GNSS is
Hi!
> This series adds a new subsystem for GNSS receivers (e.g. GPS
> receivers).
>
> While GNSS receivers are typically accessed using a UART interface they
> often also support other I/O interfaces such as I2C, SPI and USB, while
> yet other devices use iomem or even some form of
Hi!
> This series adds a new subsystem for GNSS receivers (e.g. GPS
> receivers).
>
> While GNSS receivers are typically accessed using a UART interface they
> often also support other I/O interfaces such as I2C, SPI and USB, while
> yet other devices use iomem or even some form of
On Tue, 24 Apr 2018 22:13:19 +0200
Pavel Machek wrote:
> Hi!
>
> > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > receivers).
>
> Actually... I'd just call it GPS subsystem. Yes, GPS is a bit
> misleading, but so is GNSS. We'd like Loran to use similar
On Tue, 24 Apr 2018 22:13:19 +0200
Pavel Machek wrote:
> Hi!
>
> > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > receivers).
>
> Actually... I'd just call it GPS subsystem. Yes, GPS is a bit
> misleading, but so is GNSS. We'd like Loran to use similar interface,
> right?
> As proof-of-concept I have implemented drivers for receivers based on
> two common GNSS chipsets (SiRFstar and u-blox), but due to lack of
> hardware these have so far only been tested using mockup devices and a
> USB-serial-based GPS device (using out-of-tree code). [ Let me know if
> you've
> As proof-of-concept I have implemented drivers for receivers based on
> two common GNSS chipsets (SiRFstar and u-blox), but due to lack of
> hardware these have so far only been tested using mockup devices and a
> USB-serial-based GPS device (using out-of-tree code). [ Let me know if
> you've
Hi!
> This series adds a new subsystem for GNSS receivers (e.g. GPS
> receivers).
Actually... I'd just call it GPS subsystem. Yes, GPS is a bit
misleading, but so is GNSS. We'd like Loran to use similar interface,
right? We'd like to QZSS to use similar interface, too...
Hi!
> This series adds a new subsystem for GNSS receivers (e.g. GPS
> receivers).
Actually... I'd just call it GPS subsystem. Yes, GPS is a bit
misleading, but so is GNSS. We'd like Loran to use similar interface,
right? We'd like to QZSS to use similar interface, too...
> Am 24.04.2018 um 19:50 schrieb Johan Hovold :
>
> On Tue, Apr 24, 2018 at 07:40:00PM +0200, H. Nikolaus Schaller wrote:
>> Hi Johan,
>>
>>> Am 24.04.2018 um 18:34 schrieb Johan Hovold :
>
>>> As proof-of-concept I have implemented drivers for receivers
> Am 24.04.2018 um 19:50 schrieb Johan Hovold :
>
> On Tue, Apr 24, 2018 at 07:40:00PM +0200, H. Nikolaus Schaller wrote:
>> Hi Johan,
>>
>>> Am 24.04.2018 um 18:34 schrieb Johan Hovold :
>
>>> As proof-of-concept I have implemented drivers for receivers based on
>>> two common GNSS chipsets
On Tue, Apr 24, 2018 at 07:40:00PM +0200, H. Nikolaus Schaller wrote:
> Hi Johan,
>
> > Am 24.04.2018 um 18:34 schrieb Johan Hovold :
> > As proof-of-concept I have implemented drivers for receivers based on
> > two common GNSS chipsets (SiRFstar and u-blox), but due to lack of
On Tue, Apr 24, 2018 at 07:40:00PM +0200, H. Nikolaus Schaller wrote:
> Hi Johan,
>
> > Am 24.04.2018 um 18:34 schrieb Johan Hovold :
> > As proof-of-concept I have implemented drivers for receivers based on
> > two common GNSS chipsets (SiRFstar and u-blox), but due to lack of
> > hardware
Hi Johan,
> Am 24.04.2018 um 18:34 schrieb Johan Hovold :
>
> This series adds a new subsystem for GNSS receivers (e.g. GPS
> receivers).
Great!
>
> While GNSS receivers are typically accessed using a UART interface they
> often also support other I/O interfaces such as I2C,
Hi Johan,
> Am 24.04.2018 um 18:34 schrieb Johan Hovold :
>
> This series adds a new subsystem for GNSS receivers (e.g. GPS
> receivers).
Great!
>
> While GNSS receivers are typically accessed using a UART interface they
> often also support other I/O interfaces such as I2C, SPI and USB,
This series adds a new subsystem for GNSS receivers (e.g. GPS
receivers).
While GNSS receivers are typically accessed using a UART interface they
often also support other I/O interfaces such as I2C, SPI and USB, while
yet other devices use iomem or even some form of remote-processor
messaging
This series adds a new subsystem for GNSS receivers (e.g. GPS
receivers).
While GNSS receivers are typically accessed using a UART interface they
often also support other I/O interfaces such as I2C, SPI and USB, while
yet other devices use iomem or even some form of remote-processor
messaging
58 matches
Mail list logo