lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 8 Jul 2017 22:33:53 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     Sebastian Reichel <sebastian.reichel@...labora.co.uk>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Motorola Droid 4 Audio Support

* Sebastian Reichel <sebastian.reichel@...labora.co.uk> [170708 04:34]:
> Hi,
> 
> On Fri, Jul 07, 2017 at 10:27:53PM -0700, Tony Lindgren wrote:
> > * Sebastian Reichel <sebastian.reichel@...labora.co.uk> [170707 09:43]:
> > > I got working sound on Droid 4 with mainline \o/. The codec is
> > > currently missing support for detecting if something has been
> > > plugged into the 3.5mm connector, since that seems to require
> > > some closed source firmware and needs further investigation. I
> > > think this can be added later.
> > 
> > Hey that's great! I'll give it a try this weekend.. Does that mean
> > that 3G voice calls work too now or is something more needed there?
> 
> I added some text about that in the 3rd patch. Basically the codec driver
> is ready (maybe a few quirks will be needed, though), but the soundcard
> driver is not. It currently assumes CPU <-> Voice Codec, but
> actually its a network of CPU, Voice Codec, Modem(s?) and Bluetooth.

OK

> > For the CPCAP PMIC macro interrupts I think it's best to set up
> > a separate driver as it seems separate from the core CPCAP
> > functionality. So I think we can just move the unused "cpcap-m2"
> > IRQ banks out of motorola-cpcap.c and put them into a separate child
> > driver that loads it's firmware on init and provides interrupts for
> > the 3.5mm connector.
> 
> I also think the macro block fw handling should not be handled in
> the driver for the audio codec. IIRC it is also used to provide a
> blink feature for the status LEDs. OTOH some of the registers of the
> audio-codec are also used for 3.5mm detection. I also did not yet look
> into the details of this one.

Also the battery driver has three mystery interrupts coming from the
macro. At least the cycle count is missing so maybe that too comes
from the macro.

Regards,

Tony

Powered by blists - more mailing lists