[Gta04-owner] [PATCH 2/3] ASoC: twl4030: allow voice port to be connected externally.
neilb at suse.de
Wed Nov 12 06:37:22 CET 2014
(cc list trimmed, as I don't think this is directly relevant to many of
On Mon, 10 Nov 2014 07:46:50 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:
> Am 10.11.2014 um 00:25 schrieb NeilBrown <neilb at suse.de>:
> > On Sat, 8 Nov 2014 09:26:22 +0000 Mark Brown <broonie at kernel.org> wrote:
> >> On Sat, Nov 08, 2014 at 11:38:03AM +1100, NeilBrown wrote:
> >>> If voice port on twl4030 is not connected to a McBSP (or similar)
> >>> then we cannot configure the format the way we normally do for a DAI.
> >> Yes we can, you need to represent the DAI link to whatever else the
> >> device is connected to in the driver like we do anything else - and in
> >> any case this isn't a device specific issue so we shouldn't be doing
> >> something driver specific to solve it. Look at something like speyside.
> > Hi Mark,
> > thanks for the reply ... I might need a little bit more help though.
> > I had a look at sound/soc/samsung/speyside.c, but I'm not entirely sure what
> > I'm looking for.
> > Presumably this is an audio processor not unlike the audio module in the
> > twl4030.
> > I see that there are 3 dai-links:
> > CPU-DSP
> > DSP-CODEC
> > Baseband
> > Presumably "Baseband" is similar, in purpose at least, to the "voice"
> > interface on the twl4030.
> > Each dai-link has a "cpu_dai_name" and a "codec_dai_name", even though it
> > appears that only "CPU-DSP" is connected to the CPU. Maybe that naming is
> > the source of some of my confusion.
> > "Baseband" declares
> > .cpu_dai_name = "wm8996-aif2",
> > so wm8996 is something with 2 audio interfaces, (aif), and this is the second
> > one? Maybe the wm8996 is the audio module, so what is the "speyside"?
> > http://opensource.wolfsonmicro.com/content/speyside-audio
> > says it is a "reference platform". Does that mean it is a board with a bunch
> > of chips soldered onto it? If it were a board it should be described by a
> > dts file, not by a pile of C code (I thought), so I must be wrong about that.
> > In my case, I have a board with a GSM module and the twl4030 module. Each
> > has an audio interface and these are connected. I assume that I need to
> > express this connection in the dts file.
> > The GSM module doesn't currently appear in the dts file as it is usb-attached.
> > However I've been thinking that we will need to add it so we can express
> > power-on controls (twiddling some GPIOs). So let's suppose we have the GSM
> > module in the dts file (child of a USB interface)
> It is a quite complex connection pattern and I am not sure if the modem is really
> a logical child of the USB interface. Powering up/down the USB interface has nothing
> to do with the modem power. Rather, it continues to operate if USB is suspended
> and the modem notifies USB that it has become active.
> The connections on this GTA04 board are:
> Modem USB <—> CPU USB
> Modem PCM <—> TWL4030 Voice <—> OMAP3 McBSP4 (yes, it is a 3-way connection)
> Modem Power control <—> 1 or 2 GPIOs (depending on board variant)
> The reason for the 3-way connection is that user space can chose if the GSM
> voice is routed directly to the TWL codec (low latency, independent of CPU) or
> goes through the CPU (e.g. for DTAM or voice scrambling by software) and
> then through the other PCM link between the CPU and the TWL.
> This is why I would make the McBSP4 a separate sound card.
> And, this is why it needs some control and tri-state of the TWL4030 and OMAP3
> McBSP4 since only one can provide a digital PCM stream to the modem.
> One more thing to consider for a general solution is that there are modem modules
> that communicate data through UART or SPI - but otherwise have a similar connection
> for digital audio. So forcing the power control driver to be a subnode of USB doesn’t
> appear general enough to me.
> Finally, this connection pattern is not specific to this modem (OPTION GTM601) on this
> GTA04 board. We plan to use a Gemalto PHS8 in the Pyra-Handheld and the Neo900
> devices - but the general connection pattern as defined above remains the same.
> So my proposal is to have a specific wwan-power driver for this type of modems.
> And power control can and should be kept separately from USB (except the case
> where only 1 GPIO exists and USB must be tapped to detect the modem power
> state). You can find work in progress for this approach here:
I've had a few thoughts about this.
I would certainly like a way to turn the modem on/off without poking at GPIOs.
I'm not convinced that an 'rfkill' is the best interface though. 'rfkill'
should be just for turning of 'rf'. The modem does provide some (Limited)
functionality without generating rf (e.g. inspecting the address book on the
SIM), and there is no reason to disable that when rf is not wanted.
The most general mechanism for turning power on/off that is used in the
kernel is simply that power is turned on when the device is used, and turned
of when it is not in use. Applying that logic to usb-devices is not entirely
straight forward but I think it is worth exploring.
Normally when the power is removed from a USB device it disappears
completely. Any /dev/XXX etc device that it created is removed.
That makes it difficult to start using the device.
However there is a feature in the Linux USB stack called "usb persist",
described in Documentation/usb/persist.txt.
The focus of this it to allow devices to "persist" over system suspend/resume
when the bus would be powered off. The idea is that when the bus comes
back on, the devices are enumerated, and if one is found that "exactly"
matches a "persistent" device that was there previously, then it is assumed
to be the same device and the cycle is treated as "reset" instead of "detach"
followed by "attach".
I would like to try to enable the same thing for runtime-pm suspend/resume.
i.e. when the last /dev/ttyHS* device is closed, the hso driver tells the usb
bus that everything is inactive, and the usb bus powers down. That tells
the hso driver to power down, and it fiddles with the GPIO lines as required.
The hso device would be marked to persisted so the devices remain.
When /dev/ttyHS* is re-opened, the hso driver powers up the modem and then
tells the USB bus it is needed again so it wakes up. It then finds exactly
the same hso device and so everything "just works".
That's the theory anyway. There is a long way from theory to practice, and
thing may well change on the way.
With respect to device-tree, the representation in device-tree doesn't have
to perfectly matter the code organisation in Linux. It is quite possible
for one Linux driver to implement several different device-tree node types
and tune its behaviour accordingly. There are certainly cases of drivers
which can connect to a USB buss or and SDIO buss and maybe even an SPI or
So describing a power manager as a child of a USB bus does not prevent it
from also being described as the child of a UART on a different board.
How the audio paths fit into all of this, I don't really know yet. If they
need to be described in devicetree, then describing a connection between a
mcbsp and a child of a USB bus seems to make sense. Exactly how the drivers
access and use that information is a separate question.
> > and the twl4030 as well
> > (beneath an i2c interface).
> > The twl4030 needs to know the master/polarity of the clk/frm lines. The GSM
> > module declares that these are. So presumably we need some sort of linkage.
> > Ahhhh... I found Documentation/devicetree/bindings/sound/simple-card.txt
> > So I need to make the "voice" port on the twl4030 look like a "cpu" end of a
> > dai-link, and create a "codec" end in the GSM module, and use "sound-dai" to
> > point from the twl4030 to the GSM module.
> What I wonder a little is that we have all these dai-links working since your 3.7
> kernel for GTA04. Is it necessary to re-invent a solution or should we just make
> the solution device tree compatible?
That is exactly the goal. But what exactly does "device tree compatible"
mean in this context? I'm not clear on that but I do have some pointers now
that I can explore.
On the side issue of exactly how to control the Option Modem in the GTA04a4,
there are a couple of things I'm unclear on.
1/ When I was playing with this quite some months ago, I concluded that I
couldn't actually power it down by manipulating GPIO186.
Toggling that would bring it from 'off' to 'on', but to turn it off I had
to set GPIO186 to 0, then issue "AT$QCPWRDN".
Can you reliably turn it off just by toggling that line?
2/ What is GPIO175 for?
Your driver does seem to touch it. I cannot even be sure from the
schematic where it is an input or and output...
> > Then I use frame-master, bitclock-master, bitclock-inversion, frame-inversion
> > for the settings I need.
> > I suspect I can make that work.
> > Am I on the right track?
> > Thanks,
> > NeilBrown
> > _______________________________________________
> > Gta04-owner mailing list
> > Gta04-owner at goldelico.com
> > http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
> Gta04-owner mailing list
> Gta04-owner at goldelico.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 811 bytes
Desc: OpenPGP digital signature
More information about the Gta04-owner