Re: [PATCH 0/3] serdev support for n_gsm
Hi! > and sorry about the reply latency. This is quite a lot to think about. > > I'm also adding Kishon and Mark on CC (e.g. for the phy and ASoC > bits). I just wanted to ask... any news here? > > For some user space examples, I have posted scripts to send and receive > > SMS at [3], and Pavel has ofono patches [4] below. Seems like we can > > also add support to ModemManager along the similar lines. And for the > > serdev drivers, those implement standard Linux interfaces for apps > > to use. > > > > For PM, about a year ago I tried making things work with a user space > > solution and it sucked big time[5]. The power management makes sense > > to do in the kernel driver at least in this case as there are shared > > GPIO pins between the USB PHY and TS 27.010 UART. The shared GPIOs > > are handled by the phy-mapphone-mdm6600 driver. > > > > With the serdev n_gsm MFD driver, the only thing that needs to be done > > to idle the modem is to enable autosuspend for the OHCI interface. So > > no spefific coordination between various components is needed for PM > > beyond that. Things idle just fine using PM runtime. > > Yeah, I don't envy you trying to get this to work (and now I'm getting > dragged into it ;) ). Yeah, and now I'm in, too. I'd really like to have an useful phone. Droid4 seems like best candidate. > It would really help with a high-level outline of the modem and its > components. I've done my best to derive it from these patches and the > code you link to, but that info needs to go in the patch descriptions > (or cover letter). Are you ready for the crazyness? There are two modems in droid 4. I don't care about the LTE one. The GSM one is connected with few USB channels, and few multiplexed channels over UART. One of USB channels is standard AT commands. One of USB channels is QMI. But using USB means big power consumption, so it is better to use multiplexed channels over UART. Few of those look vaguely like AT commands, but voice and sms and ... are going over separate channels. One of those contains NMEA data (packet in AT lookalike). > > Sure that's doable. But notice that we actually need to kick the > > serdev GNSS interface to get more data. It's not a passive GNSS > > data feed in this case. So it's not going to be just a case of > > cat /dev/motmdm4 > /dev/ugnss. Without the serdev GNSS driver, > > it would be some-custom-app -i /dev/motmdm4 -o /dev/ugnss. > > Yeah, I remember us discussing that briefly off list. > > > And without the n_gsm serdev support, it's a mess of some app > > similar to [5] initializing n_gsm, trying to deal with the USB > > PHY PM, dealing with Motorola custom packet numbering, kicking > > GNSS device, feeding data to /dev/ugnss. Hmm I think I've already > > been there just to be able to type AT commands to the modem and > > it did not work :) > > It's a mess indeed, but I'd rather see user-space dealing with until we > figure out how best to do it in the kernel. ;) Userspace should be shielded from hardware-specific mess :-(. > > Anyways, for the serdev kernel drivers, the criteria I've tried > > to follow is: "Can this serdev device driver make user space > > apps use standard Linux interfaces for the hardware?" > > > > So for the serdev Alsa ASoC driver, user space can use the standard > > Alsa interface for setting voice call volume. And for the serdev > > GNSS driver, user space can use /dev/gnss0. > > I understand. Both drivers appears to be using AT commands for control. > It would be interesting to hear what Mark has to say about the codec > driver too. Moving AT handling into the kernel scares me a bit. If we > already have a telephony stack to deal with it in user-space, my > inclination is to let it continue to handle it. These "Motorola AT" commands are really a bit different from standard AT commands. I was working on userspace, and got something... but could not get SMSes to work. > Modem-managed GNSS is also different from receivers connected directly > to the host. It's really the modem that drives the GNSS receiver, and > offers a higher-level interface to the host, for example, by buffering > output which the host can later request. It may or may not be the > kernel's job to periodically poll the modem to recreate an NMEA feed so > to speak. > > But the end-result of having it accessible through a standard interface > is of course appealing. We'd really like unified interface for the GPS receivers, please. In the Droid4 case, there's separate channel on the UART that has just the GPS... so it is really quite similar to normal GPS. We won't have proper driver for the modem anytime soon, but it would be good to be able to use the GPS in the meantime. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital
Re: [PATCH 0/3] serdev support for n_gsm
Hi! > > And without the n_gsm serdev support, it's a mess of some app > > similar to [5] initializing n_gsm, trying to deal with the USB > > PHY PM, dealing with Motorola custom packet numbering, kicking > > GNSS device, feeding data to /dev/ugnss. Hmm I think I've already > > been there just to be able to type AT commands to the modem and > > it did not work :) > > It's a mess indeed, but I'd rather see user-space dealing with until we > figure out how best to do it in the kernel. ;) > > > Anyways, for the serdev kernel drivers, the criteria I've tried > > to follow is: "Can this serdev device driver make user space > > apps use standard Linux interfaces for the hardware?" > > > > So for the serdev Alsa ASoC driver, user space can use the standard > > Alsa interface for setting voice call volume. And for the serdev > > GNSS driver, user space can use /dev/gnss0. > > I understand. Both drivers appears to be using AT commands for control. > It would be interesting to hear what Mark has to say about the codec > driver too. Moving AT handling into the kernel scares me a bit. If we > already have a telephony stack to deal with it in user-space, my > inclination is to let it continue to handle it. The userspace part of the telephony stack uses ALSA mixers to do... well... audio mixer configuration for phone calls, and it would be good if Droid 4 could keep the same interface. > Modem-managed GNSS is also different from receivers connected directly > to the host. It's really the modem that drives the GNSS receiver, and > offers a higher-level interface to the host, for example, by buffering > output which the host can later request. It may or may not be the > kernel's job to periodically poll the modem to recreate an NMEA feed so > to speak. > > But the end-result of having it accessible through a standard interface > is of course appealing. Yes please. On N900, there's special (socket-based) interface to the GPS... and it si painful. Plus, it will take some time before modem support on Droid 4 stabilizes... and it would be very welcome to be able to use the GPS in the meantime. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 0/3] serdev support for n_gsm
Hi,
* Johan Hovold [190124 16:39]:
> This series adds a new interface (gsm_serdev) but no users, which is not
> something we normally accept. I think you need to post the lot, at least
> as an RFC in order for the full picture to be visible.
Sure I can post them all as RFC series maybe this coming
weekend when I get a chance.
> Similarly, including an example device tree would also help with the
> overall picture. I've been able to derive the following (from your code
> and already merged phy driver binding doc):
>
> mdm6600_phy: usb-phy {
> compatible = "motorola,mapphone-mdm6600";
> enable-gpios = < 31 GPIO_ACTIVE_LOW>;
> power-gpios = < 22 GPIO_ACTIVE_HIGH>;
> reset-gpios = < 17 GPIO_ACTIVE_HIGH>;
> motorola,mode-gpios = < 20 GPIO_ACTIVE_HIGH>,
> < 21 GPIO_ACTIVE_HIGH>;
> motorola,cmd-gpios = < 7 GPIO_ACTIVE_HIGH>,
>< 8 GPIO_ACTIVE_HIGH>,
>< 14 GPIO_ACTIVE_HIGH>;
> motorola,status-gpios = < 20 GPIO_ACTIVE_HIGH>,
> < 21 GPIO_ACTIVE_HIGH>,
> < 23 GPIO_ACTIVE_HIGH>;
> #phy-cells = <0>;
> };
>
>{
> gsm-mux? {
> compatible = "motorola,mapphone-mdm6600-serdev";
> phy = <_phy>;
>
> gnss {
> compatible = "motorola,mapphone-mdm6600-gnss";
> };
>
> audio-codec {
>
> };
> };
> };
>
>{
> phys = <_phy>;
> };
>
> Which brings us back to the question of how to model modems. You've
> already added a phy-driver for something which really is some sort of
> modem representation.
That is not a "modem representation".
It's just doing what's typically done for drivers with firmware
like let's say WLAN pwrseq driver on SDIO bus. So start device,
enable clocks for the PHY so Linux won't oops when loading
ohci-platform device driver. It does not have much anything to
do beyond enabling communication over Linux standard buses like
TS 27.010 and USB. For more info, please see commit 5d1ebbda0318
("phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on
Droid 4").
It's too bad the USB PHY for the Linux SoC OHCI is on the modem
and clocked from the modem instead of what is usually done
where it would be clocked by the Linux running SoC. And too bad
some of the GPIO pins are shared with the TS 27.010 port. But hey,
it's just bad hardware design and not much we can do about it.
And it can be all isolated in the USB PHY driver.
> > And without the n_gsm serdev support, it's a mess of some app
> > similar to [5] initializing n_gsm, trying to deal with the USB
> > PHY PM, dealing with Motorola custom packet numbering, kicking
> > GNSS device, feeding data to /dev/ugnss. Hmm I think I've already
> > been there just to be able to type AT commands to the modem and
> > it did not work :)
>
> It's a mess indeed, but I'd rather see user-space dealing with until we
> figure out how best to do it in the kernel. ;)
Well we really do not have user space dealing with it. And I'm
not planning on working on the user space approach any longer
for n_gsm, Motorola custom packet layer, and shared GPIO pins
for PM. That was proven to be a dead end alread and not worth
continuing.
For kicking the GNSS, that can be certainly done with a kernel
serdev driver or some custom user space app. With the $subject
patch we now have both options available unlike earlier.
> > Anyways, for the serdev kernel drivers, the criteria I've tried
> > to follow is: "Can this serdev device driver make user space
> > apps use standard Linux interfaces for the hardware?"
> >
> > So for the serdev Alsa ASoC driver, user space can use the standard
> > Alsa interface for setting voice call volume. And for the serdev
> > GNSS driver, user space can use /dev/gnss0.
>
> I understand. Both drivers appears to be using AT commands for control.
> It would be interesting to hear what Mark has to say about the codec
> driver too. Moving AT handling into the kernel scares me a bit. If we
> already have a telephony stack to deal with it in user-space, my
> inclination is to let it continue to handle it.
Right, too bad it's AT commands instead of let's say just
register offsets to a mem region on the modem. Or even some
enumerated commands. And yes it's the firmware doing all
kinds of things, just like with a let's say a WLAN driver.
And no, we don't really have a telephony stack to deal with it
in the user-space. But with the $subject patch it becomes doable
for the parts it makes sense to do, for ofono, ModemManager and
my phone scripts too.
For the Alsa driver, we need to configure the i2s channel
on the PMIC for time division
Re: [PATCH 0/3] serdev support for n_gsm
Hi Tony,
and sorry about the reply latency. This is quite a lot to think about.
I'm also adding Kishon and Mark on CC (e.g. for the phy and ASoC bits).
On Mon, Jan 21, 2019 at 09:01:16AM -0800, Tony Lindgren wrote:
> Hi,
>
> * Johan Hovold [190121 10:57]:
> > Adding Marcel on CC.
> >
> > On Fri, Jan 18, 2019 at 12:59:58PM +0100, Greg Kroah-Hartman wrote:
> > > On Sun, Jan 13, 2019 at 05:25:25PM -0800, Tony Lindgren wrote:
> > > > Hi all,
> > > >
> > > > Here's a series of patches to add initial serdev support to n_gsm
> > > > TS 27.010 line discipline.
> > > >
> > > > This allows handling vendor specific protocols on top of TS 27.010 and
> > > > allows creating simple serdev drivers where it makes sense. So far I've
> > > > tested it with droid 4 for it's modem to provide char devices for AT
> > > > ports, modem PM support, and serdev drivers for GNSS and Alsa ASoC.
> > > >
> > > > I'll be posting the related MFD, GNSS and Alsa ASoC drivers separately.
> > > > For reference, the MFD driver is at [0], the GNSS driver at [1], and
> > > > the Alsa ASoC driver at [2] below.
> > >
> > > I have applied the first two patches to my tree, as those are nice
> > > cleanups.
> > >
> > > The last one I want some feedback from the serdev developers to verify
> > > all is set up properly, and Johan, to see if this ends up conflicting
> > > with the gnss code, as that would not be good.
> >
> > I think we need to have a discussion about how to model modems generally
> > before getting into implementation details.
> >
> > Modems are currently managed by user space (e.g. through ofono) and
> > I'm not sure that moving only parts of its responsibilities into the
> > kernel is necessarily the right thing to do. You still need coordination
> > between the various components for things like power management.
>
> At least now we do have the option of doing kernel drivers or user
> space apps whichever way we want to :)
>
> And we can now do the user space apps without having to implement
> any of the Motorola custom packet numbering layer on top of TS 27.010
> for each app.
>
> For some user space examples, I have posted scripts to send and receive
> SMS at [3], and Pavel has ofono patches [4] below. Seems like we can
> also add support to ModemManager along the similar lines. And for the
> serdev drivers, those implement standard Linux interfaces for apps
> to use.
>
> For PM, about a year ago I tried making things work with a user space
> solution and it sucked big time[5]. The power management makes sense
> to do in the kernel driver at least in this case as there are shared
> GPIO pins between the USB PHY and TS 27.010 UART. The shared GPIOs
> are handled by the phy-mapphone-mdm6600 driver.
>
> With the serdev n_gsm MFD driver, the only thing that needs to be done
> to idle the modem is to enable autosuspend for the OHCI interface. So
> no spefific coordination between various components is needed for PM
> beyond that. Things idle just fine using PM runtime.
Yeah, I don't envy you trying to get this to work (and now I'm getting
dragged into it ;) ).
It would really help with a high-level outline of the modem and its
components. I've done my best to derive it from these patches and the
code you link to, but that info needs to go in the patch descriptions
(or cover letter).
This series adds a new interface (gsm_serdev) but no users, which is not
something we normally accept. I think you need to post the lot, at least
as an RFC in order for the full picture to be visible.
Similarly, including an example device tree would also help with the
overall picture. I've been able to derive the following (from your code
and already merged phy driver binding doc):
mdm6600_phy: usb-phy {
compatible = "motorola,mapphone-mdm6600";
enable-gpios = < 31 GPIO_ACTIVE_LOW>;
power-gpios = < 22 GPIO_ACTIVE_HIGH>;
reset-gpios = < 17 GPIO_ACTIVE_HIGH>;
motorola,mode-gpios = < 20 GPIO_ACTIVE_HIGH>,
< 21 GPIO_ACTIVE_HIGH>;
motorola,cmd-gpios = < 7 GPIO_ACTIVE_HIGH>,
< 8 GPIO_ACTIVE_HIGH>,
< 14 GPIO_ACTIVE_HIGH>;
motorola,status-gpios = < 20 GPIO_ACTIVE_HIGH>,
< 21 GPIO_ACTIVE_HIGH>,
< 23 GPIO_ACTIVE_HIGH>;
#phy-cells = <0>;
};
{
gsm-mux? {
compatible = "motorola,mapphone-mdm6600-serdev";
phy = <_phy>;
gnss {
compatible = "motorola,mapphone-mdm6600-gnss";
};
audio-codec {
};
};
};
{
phys = <_phy>;
};
Which brings us back to the question of
Re: [PATCH 0/3] serdev support for n_gsm
Hi, * Johan Hovold [190121 10:57]: > Adding Marcel on CC. > > On Fri, Jan 18, 2019 at 12:59:58PM +0100, Greg Kroah-Hartman wrote: > > On Sun, Jan 13, 2019 at 05:25:25PM -0800, Tony Lindgren wrote: > > > Hi all, > > > > > > Here's a series of patches to add initial serdev support to n_gsm > > > TS 27.010 line discipline. > > > > > > This allows handling vendor specific protocols on top of TS 27.010 and > > > allows creating simple serdev drivers where it makes sense. So far I've > > > tested it with droid 4 for it's modem to provide char devices for AT > > > ports, modem PM support, and serdev drivers for GNSS and Alsa ASoC. > > > > > > I'll be posting the related MFD, GNSS and Alsa ASoC drivers separately. > > > For reference, the MFD driver is at [0], the GNSS driver at [1], and > > > the Alsa ASoC driver at [2] below. > > > > I have applied the first two patches to my tree, as those are nice > > cleanups. > > > > The last one I want some feedback from the serdev developers to verify > > all is set up properly, and Johan, to see if this ends up conflicting > > with the gnss code, as that would not be good. > > I think we need to have a discussion about how to model modems generally > before getting into implementation details. > > Modems are currently managed by user space (e.g. through ofono) and > I'm not sure that moving only parts of its responsibilities into the > kernel is necessarily the right thing to do. You still need coordination > between the various components for things like power management. At least now we do have the option of doing kernel drivers or user space apps whichever way we want to :) And we can now do the user space apps without having to implement any of the Motorola custom packet numbering layer on top of TS 27.010 for each app. For some user space examples, I have posted scripts to send and receive SMS at [3], and Pavel has ofono patches [4] below. Seems like we can also add support to ModemManager along the similar lines. And for the serdev drivers, those implement standard Linux interfaces for apps to use. For PM, about a year ago I tried making things work with a user space solution and it sucked big time[5]. The power management makes sense to do in the kernel driver at least in this case as there are shared GPIO pins between the USB PHY and TS 27.010 UART. The shared GPIOs are handled by the phy-mapphone-mdm6600 driver. With the serdev n_gsm MFD driver, the only thing that needs to be done to idle the modem is to enable autosuspend for the OHCI interface. So no spefific coordination between various components is needed for PM beyond that. Things idle just fine using PM runtime. > TS 27.010 may make it seem like we can move everything into the kernel, > but Tony's to-be-posted Motorola MFD driver is still exposing character > devices for most of the muxed ports. If I understand things correctly, > there also still needs to be some coordination with USB over which some > channels are handled (e.g. IP over USB, gnss over muxed UART). Hmm yes now we can do either user space daemons or kernel serdev drivers. For USB, the modem data connection already works with USB OHCI over QMI. So it's is already handled and separated out of this. The USB PHY and TS 27.010 UART have shared GPIO pins handled by the USB PHY driver. The USB PHY is integrated into the modem with the shared GPIO pins controlling the PHY and the TS 27.010 UART PM.. But it's working for PM and like I mentioned modem PM works as long as OHCI is set to autosuspend. Well the modem also wants to see TS 27.010 connected before idling. > Instead of adding these extra layers, only to export most ports to user > space again, it may be better to hook into the various kernel subsystems > through dedicated user-space-implementation interfaces such as the > suggested ugnss interface, which means that user space feeds gnss data > into the kernel which in turn makes it available through a standard > interface. Sure that's doable. But notice that we actually need to kick the serdev GNSS interface to get more data. It's not a passive GNSS data feed in this case. So it's not going to be just a case of cat /dev/motmdm4 > /dev/ugnss. Without the serdev GNSS driver, it would be some-custom-app -i /dev/motmdm4 -o /dev/ugnss. And without the n_gsm serdev support, it's a mess of some app similar to [5] initializing n_gsm, trying to deal with the USB PHY PM, dealing with Motorola custom packet numbering, kicking GNSS device, feeding data to /dev/ugnss. Hmm I think I've already been there just to be able to type AT commands to the modem and it did not work :) Anyways, for the serdev kernel drivers, the criteria I've tried to follow is: "Can this serdev device driver make user space apps use standard Linux interfaces for the hardware?" So for the serdev Alsa ASoC driver, user space can use the standard Alsa interface for setting voice call volume. And for the serdev GNSS driver, user space can use /dev/gnss0. I
Re: [PATCH 0/3] serdev support for n_gsm
Adding Marcel on CC. On Fri, Jan 18, 2019 at 12:59:58PM +0100, Greg Kroah-Hartman wrote: > On Sun, Jan 13, 2019 at 05:25:25PM -0800, Tony Lindgren wrote: > > Hi all, > > > > Here's a series of patches to add initial serdev support to n_gsm > > TS 27.010 line discipline. > > > > This allows handling vendor specific protocols on top of TS 27.010 and > > allows creating simple serdev drivers where it makes sense. So far I've > > tested it with droid 4 for it's modem to provide char devices for AT > > ports, modem PM support, and serdev drivers for GNSS and Alsa ASoC. > > > > I'll be posting the related MFD, GNSS and Alsa ASoC drivers separately. > > For reference, the MFD driver is at [0], the GNSS driver at [1], and > > the Alsa ASoC driver at [2] below. > > I have applied the first two patches to my tree, as those are nice > cleanups. > > The last one I want some feedback from the serdev developers to verify > all is set up properly, and Johan, to see if this ends up conflicting > with the gnss code, as that would not be good. I think we need to have a discussion about how to model modems generally before getting into implementation details. Modems are currently managed by user space (e.g. through ofono) and I'm not sure that moving only parts of its responsibilities into the kernel is necessarily the right thing to do. You still need coordination between the various components for things like power management. TS 27.010 may make it seem like we can move everything into the kernel, but Tony's to-be-posted Motorola MFD driver is still exposing character devices for most of the muxed ports. If I understand things correctly, there also still needs to be some coordination with USB over which some channels are handled (e.g. IP over USB, gnss over muxed UART). Instead of adding these extra layers, only to export most ports to user space again, it may be better to hook into the various kernel subsystems through dedicated user-space-implementation interfaces such as the suggested ugnss interface, which means that user space feeds gnss data into the kernel which in turn makes it available through a standard interface. This would also allow things to work for other transports such as USB CDC for which the mux protocol isn't used. Johan
Re: [PATCH 0/3] serdev support for n_gsm
On Sun, Jan 13, 2019 at 05:25:25PM -0800, Tony Lindgren wrote: > Hi all, > > Here's a series of patches to add initial serdev support to n_gsm > TS 27.010 line discipline. > > This allows handling vendor specific protocols on top of TS 27.010 and > allows creating simple serdev drivers where it makes sense. So far I've > tested it with droid 4 for it's modem to provide char devices for AT > ports, modem PM support, and serdev drivers for GNSS and Alsa ASoC. > > I'll be posting the related MFD, GNSS and Alsa ASoC drivers separately. > For reference, the MFD driver is at [0], the GNSS driver at [1], and > the Alsa ASoC driver at [2] below. I have applied the first two patches to my tree, as those are nice cleanups. The last one I want some feedback from the serdev developers to verify all is set up properly, and Johan, to see if this ends up conflicting with the gnss code, as that would not be good. thanks, greg k-h
Re: [PATCH 0/3] serdev support for n_gsm
On Sun 2019-01-13 17:25:25, Tony Lindgren wrote: > Hi all, > > Here's a series of patches to add initial serdev support to n_gsm > TS 27.010 line discipline. > > This allows handling vendor specific protocols on top of TS 27.010 and > allows creating simple serdev drivers where it makes sense. So far I've > tested it with droid 4 for it's modem to provide char devices for AT > ports, modem PM support, and serdev drivers for GNSS and Alsa ASoC. > > I'll be posting the related MFD, GNSS and Alsa ASoC drivers separately. > For reference, the MFD driver is at [0], the GNSS driver at [1], and > the Alsa ASoC driver at [2] below. For the series: Acked-by: Pavel Machek Thanks for doing this! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
