On Thu, May 24, 2018 at 06:32:37AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180524 09:20]:
> > On Mon, May 21, 2018 at 08:48:32AM -0700, Tony Lindgren wrote:
> > > Well if you have some better mechanism in mind let's try it out. Short of
> > > sprinkling
On Thu, May 24, 2018 at 06:32:37AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180524 09:20]:
> > On Mon, May 21, 2018 at 08:48:32AM -0700, Tony Lindgren wrote:
> > > Well if you have some better mechanism in mind let's try it out. Short of
> > > sprinkling pm_runtime_force_suspend/resume
* Johan Hovold [180524 09:20]:
> On Mon, May 21, 2018 at 08:48:32AM -0700, Tony Lindgren wrote:
> >
> > Yes the bug for closed ports needs to be fixed for sure.
>
> I did some forensic on this and it seems this problem has "always" been
> there. Specifically, closed ports have
* Johan Hovold [180524 09:20]:
> On Mon, May 21, 2018 at 08:48:32AM -0700, Tony Lindgren wrote:
> >
> > Yes the bug for closed ports needs to be fixed for sure.
>
> I did some forensic on this and it seems this problem has "always" been
> there. Specifically, closed ports have never been
On Mon, May 21, 2018 at 08:48:32AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180521 13:50]:
> > On Thu, May 17, 2018 at 10:10:38AM -0700, Tony Lindgren wrote:
> > > * Johan Hovold [180517 10:12]:
> > > Well in that case we should just stick with -1 value
On Mon, May 21, 2018 at 08:48:32AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180521 13:50]:
> > On Thu, May 17, 2018 at 10:10:38AM -0700, Tony Lindgren wrote:
> > > * Johan Hovold [180517 10:12]:
> > > Well in that case we should just stick with -1 value for the
> > > autosuspend. And just
* Johan Hovold [180521 13:50]:
> On Thu, May 17, 2018 at 10:10:38AM -0700, Tony Lindgren wrote:
> > * Johan Hovold [180517 10:12]:
> > > No, defaulting to "on" (i.e. calling pm_runtime_forbid()) wouldn't work
> > > either as that would also prevent the device
* Johan Hovold [180521 13:50]:
> On Thu, May 17, 2018 at 10:10:38AM -0700, Tony Lindgren wrote:
> > * Johan Hovold [180517 10:12]:
> > > No, defaulting to "on" (i.e. calling pm_runtime_forbid()) wouldn't work
> > > either as that would also prevent the device from runtime suspending
> > > just
On Thu, May 17, 2018 at 10:10:38AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180517 10:12]:
> > [ Sorry about the late reply. ]
> >
> > On Wed, May 09, 2018 at 06:57:06AM -0700, Tony Lindgren wrote:
> > > * Johan Hovold [180509 13:12]:
> >
> > > > It
On Thu, May 17, 2018 at 10:10:38AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180517 10:12]:
> > [ Sorry about the late reply. ]
> >
> > On Wed, May 09, 2018 at 06:57:06AM -0700, Tony Lindgren wrote:
> > > * Johan Hovold [180509 13:12]:
> >
> > > > It seems we really should not be using the
* Johan Hovold [180517 10:12]:
> [ Sorry about the late reply. ]
>
> On Wed, May 09, 2018 at 06:57:06AM -0700, Tony Lindgren wrote:
> > * Johan Hovold [180509 13:12]:
>
> > > It seems we really should not be using the negative autosuspend to
> > > configure
* Johan Hovold [180517 10:12]:
> [ Sorry about the late reply. ]
>
> On Wed, May 09, 2018 at 06:57:06AM -0700, Tony Lindgren wrote:
> > * Johan Hovold [180509 13:12]:
>
> > > It seems we really should not be using the negative autosuspend to
> > > configure the RPM behaviour the way these
On Wed, May 09, 2018 at 07:05:50AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180509 09:20]:
> > On Tue, May 08, 2018 at 05:56:08PM +0200, Sebastian Reichel wrote:
> > > I think using open/close for runtime pm is good enough for GPS,
> > > since it regularly sends data and
On Wed, May 09, 2018 at 07:05:50AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180509 09:20]:
> > On Tue, May 08, 2018 at 05:56:08PM +0200, Sebastian Reichel wrote:
> > > I think using open/close for runtime pm is good enough for GPS,
> > > since it regularly sends data and draws lots of power
[ Sorry about the late reply. ]
On Wed, May 09, 2018 at 06:57:06AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180509 13:12]:
> > It seems we really should not be using the negative autosuspend to
> > configure the RPM behaviour the way these drivers do. Perhaps a new
> >
[ Sorry about the late reply. ]
On Wed, May 09, 2018 at 06:57:06AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180509 13:12]:
> > It seems we really should not be using the negative autosuspend to
> > configure the RPM behaviour the way these drivers do. Perhaps a new
> > mechanism is needed.
* Johan Hovold [180509 09:20]:
> On Tue, May 08, 2018 at 05:56:08PM +0200, Sebastian Reichel wrote:
> > I think using open/close for runtime pm is good enough for GPS,
> > since it regularly sends data and draws lots of power anyways.
> > But devices, that have an out-of-band
* Johan Hovold [180509 09:20]:
> On Tue, May 08, 2018 at 05:56:08PM +0200, Sebastian Reichel wrote:
> > I think using open/close for runtime pm is good enough for GPS,
> > since it regularly sends data and draws lots of power anyways.
> > But devices, that have an out-of-band wakeup signal can do
* Johan Hovold [180509 13:12]:
> While this seems to fix the idling of closed ports here too, I'm not
> sure we can move use_autosuspend to startup() like this.
>
> First, this flag should be set before registering the tty so that udev
> can be used to update the attributes.
>
* Johan Hovold [180509 13:12]:
> While this seems to fix the idling of closed ports here too, I'm not
> sure we can move use_autosuspend to startup() like this.
>
> First, this flag should be set before registering the tty so that udev
> can be used to update the attributes.
>
> Second, this
[ Updating subject and adding linux-serial, linux-pm and linux-omap. ]
On Tue, May 08, 2018 at 09:49:04AM -0700, Tony Lindgren wrote:
> * Tony Lindgren [180508 08:54]:
> > * Tony Lindgren [180508 08:47]:
> > > * Tony Lindgren [180508
[ Updating subject and adding linux-serial, linux-pm and linux-omap. ]
On Tue, May 08, 2018 at 09:49:04AM -0700, Tony Lindgren wrote:
> * Tony Lindgren [180508 08:54]:
> > * Tony Lindgren [180508 08:47]:
> > > * Tony Lindgren [180508 08:22]:
> > > > * Johan Hovold [180508 07:00]:
> > > > >
On Wed, May 09, 2018 at 11:18:31AM +0200, Johan Hovold wrote:
> I've cooked up a patch which I'll be sending as a reply to this mail.
Forgot to add the in-reply-to header of course. For the interested, the
patch can be found here:
On Wed, May 09, 2018 at 11:18:31AM +0200, Johan Hovold wrote:
> I've cooked up a patch which I'll be sending as a reply to this mail.
Forgot to add the in-reply-to header of course. For the interested, the
patch can be found here:
[ Changing the subject line as this is thread is no longer about DT
bindings.
Also adding linux-serial and linux-pm while keeping some context. ]
On Tue, May 08, 2018 at 05:56:08PM +0200, Sebastian Reichel wrote:
> Hi,
>
> On Mon, May 07, 2018 at 06:34:39PM +0200, Johan Hovold wrote:
> > On
[ Changing the subject line as this is thread is no longer about DT
bindings.
Also adding linux-serial and linux-pm while keeping some context. ]
On Tue, May 08, 2018 at 05:56:08PM +0200, Sebastian Reichel wrote:
> Hi,
>
> On Mon, May 07, 2018 at 06:34:39PM +0200, Johan Hovold wrote:
> > On
* Tony Lindgren [180508 08:54]:
> * Tony Lindgren [180508 08:47]:
> > * Tony Lindgren [180508 08:22]:
> > > * Johan Hovold [180508 07:00]:
> > > > With the negative autosuspend set in both omap drivers probe functions,
> >
* Tony Lindgren [180508 08:54]:
> * Tony Lindgren [180508 08:47]:
> > * Tony Lindgren [180508 08:22]:
> > > * Johan Hovold [180508 07:00]:
> > > > With the negative autosuspend set in both omap drivers probe functions,
> > > > this is the expected behaviour. Which I think we must fix.
> > >
>
Hi,
On Mon, May 07, 2018 at 06:34:39PM +0200, Johan Hovold wrote:
> On Mon, May 07, 2018 at 08:45:15AM -0700, Tony Lindgren wrote:
> > * Johan Hovold [180507 03:03]:
> > > On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote:
> > >
> > > > Having said all of this,
Hi,
On Mon, May 07, 2018 at 06:34:39PM +0200, Johan Hovold wrote:
> On Mon, May 07, 2018 at 08:45:15AM -0700, Tony Lindgren wrote:
> > * Johan Hovold [180507 03:03]:
> > > On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote:
> > >
> > > > Having said all of this, serdev does not
* Tony Lindgren [180508 08:47]:
> * Tony Lindgren [180508 08:22]:
> > * Johan Hovold [180508 07:00]:
> > > With the negative autosuspend set in both omap drivers probe functions,
> > > this is the expected behaviour. Which I think we must
* Tony Lindgren [180508 08:47]:
> * Tony Lindgren [180508 08:22]:
> > * Johan Hovold [180508 07:00]:
> > > With the negative autosuspend set in both omap drivers probe functions,
> > > this is the expected behaviour. Which I think we must fix.
> >
> > Yes indeed. I've been using my script for
* Tony Lindgren [180508 08:22]:
> * Johan Hovold [180508 07:00]:
> > With the negative autosuspend set in both omap drivers probe functions,
> > this is the expected behaviour. Which I think we must fix.
>
> Yes indeed. I've been using my script for years now
* Tony Lindgren [180508 08:22]:
> * Johan Hovold [180508 07:00]:
> > With the negative autosuspend set in both omap drivers probe functions,
> > this is the expected behaviour. Which I think we must fix.
>
> Yes indeed. I've been using my script for years now and have
> completely missed the
* Johan Hovold [180508 07:00]:
> On Mon, May 07, 2018 at 10:50:32AM -0700, Tony Lindgren wrote:
> > I don't know, they are there for the ports that don't have any
> > serdev device. But if there is a serdev child node, the sysfs
> > disappear for the 8250 port like it's
* Johan Hovold [180508 07:00]:
> On Mon, May 07, 2018 at 10:50:32AM -0700, Tony Lindgren wrote:
> > I don't know, they are there for the ports that don't have any
> > serdev device. But if there is a serdev child node, the sysfs
> > disappear for the 8250 port like it's /dev/ttyS* entry. That is
On Mon, May 07, 2018 at 10:50:32AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180507 16:36]:
> > On Mon, May 07, 2018 at 08:45:15AM -0700, Tony Lindgren wrote:
> > > Hi,
> > >
> > > * Johan Hovold [180507 03:03]:
> > > > On Fri, May 04, 2018 at 01:42:13PM
On Mon, May 07, 2018 at 10:50:32AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180507 16:36]:
> > On Mon, May 07, 2018 at 08:45:15AM -0700, Tony Lindgren wrote:
> > > Hi,
> > >
> > > * Johan Hovold [180507 03:03]:
> > > > On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote:
> >
* Johan Hovold [180507 16:36]:
> On Mon, May 07, 2018 at 08:45:15AM -0700, Tony Lindgren wrote:
> > Hi,
> >
> > * Johan Hovold [180507 03:03]:
> > > On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote:
> > >
> > > > Having said all of this,
* Johan Hovold [180507 16:36]:
> On Mon, May 07, 2018 at 08:45:15AM -0700, Tony Lindgren wrote:
> > Hi,
> >
> > * Johan Hovold [180507 03:03]:
> > > On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote:
> > >
> > > > Having said all of this, serdev does not yet support runtime PM
On Mon, May 07, 2018 at 08:45:15AM -0700, Tony Lindgren wrote:
> Hi,
>
> * Johan Hovold [180507 03:03]:
> > On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote:
> >
> > > Having said all of this, serdev does not yet support runtime PM (at
> > > all). Tony is
On Mon, May 07, 2018 at 08:45:15AM -0700, Tony Lindgren wrote:
> Hi,
>
> * Johan Hovold [180507 03:03]:
> > On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote:
> >
> > > Having said all of this, serdev does not yet support runtime PM (at
> > > all). Tony is currently looking into
Hi,
* Johan Hovold [180507 03:03]:
> On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote:
>
> > Having said all of this, serdev does not yet support runtime PM (at
> > all). Tony is currently looking into it. Fortunately serdev allows
> > us to enable runtime PM
Hi,
* Johan Hovold [180507 03:03]:
> On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote:
>
> > Having said all of this, serdev does not yet support runtime PM (at
> > all). Tony is currently looking into it. Fortunately serdev allows
> > us to enable runtime PM by default (once
On Fri, May 04, 2018 at 02:04:15PM +0200, H. Nikolaus Schaller wrote:
> It should be possible to cover this by a timer that is started
> in this case. If there is serdev data received after assuming the module
> is turned off, the driver has detected the wrong case - and can safely
> close the
On Fri, May 04, 2018 at 02:04:15PM +0200, H. Nikolaus Schaller wrote:
> It should be possible to cover this by a timer that is started
> in this case. If there is serdev data received after assuming the module
> is turned off, the driver has detected the wrong case - and can safely
> close the
On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote:
> Having said all of this, serdev does not yet support runtime PM (at
> all). Tony is currently looking into it. Fortunately serdev allows
> us to enable runtime PM by default (once implemented), since we know
> the remote side
On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote:
> Having said all of this, serdev does not yet support runtime PM (at
> all). Tony is currently looking into it. Fortunately serdev allows
> us to enable runtime PM by default (once implemented), since we know
> the remote side
On Thu, May 03, 2018 at 11:35:21AM +0200, H. Nikolaus Schaller wrote:
> I have realized that the w2sg0004 is an exception (although a Sirf chip)
> that it does not provide a WAKEUP signal. And another significant
> difference is that we have to keep the serdev UART enabled even if there
> is no
On Thu, May 03, 2018 at 11:35:21AM +0200, H. Nikolaus Schaller wrote:
> I have realized that the w2sg0004 is an exception (although a Sirf chip)
> that it does not provide a WAKEUP signal. And another significant
> difference is that we have to keep the serdev UART enabled even if there
> is no
On Wed, May 02, 2018 at 08:16:11AM -0500, Rob Herring wrote:
> On Wed, May 2, 2018 at 3:16 AM, Johan Hovold wrote:
> > On Tue, May 01, 2018 at 09:05:42AM -0500, Rob Herring wrote:
> >> On Thu, Apr 26, 2018 at 4:10 AM, Johan Hovold wrote:
> >> > On Wed, Apr 25,
On Wed, May 02, 2018 at 08:16:11AM -0500, Rob Herring wrote:
> On Wed, May 2, 2018 at 3:16 AM, Johan Hovold wrote:
> > On Tue, May 01, 2018 at 09:05:42AM -0500, Rob Herring wrote:
> >> On Thu, Apr 26, 2018 at 4:10 AM, Johan Hovold wrote:
> >> > On Wed, Apr 25, 2018 at 01:16:58PM -0500, Rob
* Sebastian Reichel [180504 13:40]:
> Hi,
>
> On Fri, May 04, 2018 at 02:04:15PM +0200, H. Nikolaus Schaller wrote:
> > > Am 04.05.2018 um 13:42 schrieb Sebastian Reichel :
> > >> I think it does not need much more (if at all) than a gpio controller on
> > >>
* Sebastian Reichel [180504 13:40]:
> Hi,
>
> On Fri, May 04, 2018 at 02:04:15PM +0200, H. Nikolaus Schaller wrote:
> > > Am 04.05.2018 um 13:42 schrieb Sebastian Reichel :
> > >> I think it does not need much more (if at all) than a gpio controller on
> > >> the OMAP3 chip (I think the clocks
Hi,
On Fri, May 04, 2018 at 02:04:15PM +0200, H. Nikolaus Schaller wrote:
> > Am 04.05.2018 um 13:42 schrieb Sebastian Reichel :
> >> I think it does not need much more (if at all) than a gpio controller on
> >> the OMAP3 chip (I think the clocks are active anyways for use by the
Hi,
On Fri, May 04, 2018 at 02:04:15PM +0200, H. Nikolaus Schaller wrote:
> > Am 04.05.2018 um 13:42 schrieb Sebastian Reichel :
> >> I think it does not need much more (if at all) than a gpio controller on
> >> the OMAP3 chip (I think the clocks are active anyways for use by the other
> >>
Hi Sebastian,
> Am 04.05.2018 um 13:42 schrieb Sebastian Reichel :
>
> [+cc Tony]
>
> Hi,
>
>> I think it does not need much more (if at all) than a gpio controller on
>> the OMAP3 chip (I think the clocks are active anyways for use by the other
>> UARTs).
>>
>> We had
Hi Sebastian,
> Am 04.05.2018 um 13:42 schrieb Sebastian Reichel :
>
> [+cc Tony]
>
> Hi,
>
>> I think it does not need much more (if at all) than a gpio controller on
>> the OMAP3 chip (I think the clocks are active anyways for use by the other
>> UARTs).
>>
>> We had proposed years ago to
[+cc Tony]
Hi,
On Fri, May 04, 2018 at 07:16:00AM +0200, H. Nikolaus Schaller wrote:
> > Am 03.05.2018 um 20:50 schrieb Andreas Kemnade :
> > On Thu, 3 May 2018 11:35:21 +0200
> > H. Nikolaus Schaller wrote:
> >
> >> I have realized that the w2sg0004
[+cc Tony]
Hi,
On Fri, May 04, 2018 at 07:16:00AM +0200, H. Nikolaus Schaller wrote:
> > Am 03.05.2018 um 20:50 schrieb Andreas Kemnade :
> > On Thu, 3 May 2018 11:35:21 +0200
> > H. Nikolaus Schaller wrote:
> >
> >> I have realized that the w2sg0004 is an exception (although a Sirf chip)
> >>
Hi Andreas,
> Am 03.05.2018 um 20:50 schrieb Andreas Kemnade :
>
> On Thu, 3 May 2018 11:35:21 +0200
> H. Nikolaus Schaller wrote:
>
>
>> I have realized that the w2sg0004 is an exception (although a Sirf chip)
>> that it does not provide a WAKEUP
Hi Andreas,
> Am 03.05.2018 um 20:50 schrieb Andreas Kemnade :
>
> On Thu, 3 May 2018 11:35:21 +0200
> H. Nikolaus Schaller wrote:
>
>
>> I have realized that the w2sg0004 is an exception (although a Sirf chip)
>> that it does not provide a WAKEUP signal. And another significant
>> difference
On Thu, 3 May 2018 11:35:21 +0200
H. Nikolaus Schaller wrote:
> I have realized that the w2sg0004 is an exception (although a Sirf chip)
> that it does not provide a WAKEUP signal. And another significant
> difference is that we have to keep the serdev UART enabled even if
On Thu, 3 May 2018 11:35:21 +0200
H. Nikolaus Schaller wrote:
> I have realized that the w2sg0004 is an exception (although a Sirf chip)
> that it does not provide a WAKEUP signal. And another significant
> difference is that we have to keep the serdev UART enabled even if there
> is no
On Wed, May 2, 2018 at 3:16 AM, Johan Hovold wrote:
> On Tue, May 01, 2018 at 09:05:42AM -0500, Rob Herring wrote:
>> On Thu, Apr 26, 2018 at 4:10 AM, Johan Hovold wrote:
>> > On Wed, Apr 25, 2018 at 01:16:58PM -0500, Rob Herring wrote:
>> >> On Tue, Apr 24,
On Wed, May 2, 2018 at 3:16 AM, Johan Hovold wrote:
> On Tue, May 01, 2018 at 09:05:42AM -0500, Rob Herring wrote:
>> On Thu, Apr 26, 2018 at 4:10 AM, Johan Hovold wrote:
>> > On Wed, Apr 25, 2018 at 01:16:58PM -0500, Rob Herring wrote:
>> >> On Tue, Apr 24, 2018 at 11:34 AM, Johan Hovold
On Tue, May 01, 2018 at 09:05:42AM -0500, Rob Herring wrote:
> On Thu, Apr 26, 2018 at 4:10 AM, Johan Hovold wrote:
> > On Wed, Apr 25, 2018 at 01:16:58PM -0500, Rob Herring wrote:
> >> On Tue, Apr 24, 2018 at 11:34 AM, Johan Hovold wrote:
> >> > Add binding
On Tue, May 01, 2018 at 09:05:42AM -0500, Rob Herring wrote:
> On Thu, Apr 26, 2018 at 4:10 AM, Johan Hovold wrote:
> > On Wed, Apr 25, 2018 at 01:16:58PM -0500, Rob Herring wrote:
> >> On Tue, Apr 24, 2018 at 11:34 AM, Johan Hovold wrote:
> >> > Add binding for u-blox GNSS receivers.
> >> >
>
On Thu, Apr 26, 2018 at 4:10 AM, Johan Hovold wrote:
> On Wed, Apr 25, 2018 at 01:16:58PM -0500, Rob Herring wrote:
>> On Tue, Apr 24, 2018 at 11:34 AM, Johan Hovold wrote:
>> > Add binding for u-blox GNSS receivers.
>> >
>> > Note that the u-blox product
On Thu, Apr 26, 2018 at 4:10 AM, Johan Hovold wrote:
> On Wed, Apr 25, 2018 at 01:16:58PM -0500, Rob Herring wrote:
>> On Tue, Apr 24, 2018 at 11:34 AM, Johan Hovold wrote:
>> > Add binding for u-blox GNSS receivers.
>> >
>> > Note that the u-blox product names encodes form factor (e.g. "neo"),
On Wed, Apr 25, 2018 at 01:16:58PM -0500, Rob Herring wrote:
> On Tue, Apr 24, 2018 at 11:34 AM, Johan Hovold wrote:
> > Add binding for u-blox GNSS receivers.
> >
> > Note that the u-blox product names encodes form factor (e.g. "neo"),
> > chipset (e.g. "8") and variant (e.g.
On Wed, Apr 25, 2018 at 01:16:58PM -0500, Rob Herring wrote:
> On Tue, Apr 24, 2018 at 11:34 AM, Johan Hovold wrote:
> > Add binding for u-blox GNSS receivers.
> >
> > Note that the u-blox product names encodes form factor (e.g. "neo"),
> > chipset (e.g. "8") and variant (e.g. "q"), but that only
On Tue, Apr 24, 2018 at 11:34 AM, Johan Hovold wrote:
> Add binding for u-blox GNSS receivers.
>
> Note that the u-blox product names encodes form factor (e.g. "neo"),
> chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and
> chipset is used for the compatible
On Tue, Apr 24, 2018 at 11:34 AM, Johan Hovold wrote:
> Add binding for u-blox GNSS receivers.
>
> Note that the u-blox product names encodes form factor (e.g. "neo"),
> chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and
> chipset is used for the compatible strings (for now).
Add binding for u-blox GNSS receivers.
Note that the u-blox product names encodes form factor (e.g. "neo"),
chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and
chipset is used for the compatible strings (for now).
Signed-off-by: Johan Hovold
---
Add binding for u-blox GNSS receivers.
Note that the u-blox product names encodes form factor (e.g. "neo"),
chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and
chipset is used for the compatible strings (for now).
Signed-off-by: Johan Hovold
---
76 matches
Mail list logo