Hi,
On 12/30/20 2:38 PM, Mark Brown wrote:
> On Tue, Dec 29, 2020 at 04:33:09PM +0100, Hans de Goede wrote:
>> On 12/29/20 4:08 PM, Mark Brown wrote:
>>> The whole purpose of creating sound/core/jack.c is to abstract away the
>>> userspace interfaces from the drivers, most audio devices
On Tue, Dec 29, 2020 at 04:33:09PM +0100, Hans de Goede wrote:
> On 12/29/20 4:08 PM, Mark Brown wrote:
> > No, that's not the case. extcon is a port of an Android custom API that
> > looks very similar to what ended up in mainline, it was also a
> > combination of sysfs and uevents but a bit
On Tue, Dec 29, 2020 at 04:51:57PM +, Richard Fitzgerald wrote:
> On 29/12/2020 15:40, Hans de Goede wrote:
> > I guess we should move it out of drivers/extcon then though.
> > I suggest using: sound/soc/cirrus/arizona-jack-detect.c
> > Note that sound/soc/cirrus is a new dir here. Would that
Hi,
On 12/30/20 12:23 PM, Richard Fitzgerald wrote:
> On 30/12/2020 11:04, Hans de Goede wrote:
>> Hi,
>>
>> On 12/29/20 5:51 PM, Richard Fitzgerald wrote:
>>>
>>>
>>> On 29/12/2020 15:40, Hans de Goede wrote:
Hi,
On 12/29/20 4:15 PM, Mark Brown wrote:
> On Tue, Dec 29, 2020 at
On 30/12/2020 11:04, Hans de Goede wrote:
Hi,
On 12/29/20 5:51 PM, Richard Fitzgerald wrote:
On 29/12/2020 15:40, Hans de Goede wrote:
Hi,
On 12/29/20 4:15 PM, Mark Brown wrote:
On Tue, Dec 29, 2020 at 03:06:35PM +, Charles Keepax wrote:
There is maybe more argument for porting the
Hi,
On 12/29/20 5:51 PM, Richard Fitzgerald wrote:
>
>
> On 29/12/2020 15:40, Hans de Goede wrote:
>> Hi,
>>
>> On 12/29/20 4:15 PM, Mark Brown wrote:
>>> On Tue, Dec 29, 2020 at 03:06:35PM +, Charles Keepax wrote:
>>>
There is maybe more argument for porting the Arizona code across
On 29/12/2020 15:40, Hans de Goede wrote:
Hi,
On 12/29/20 4:15 PM, Mark Brown wrote:
On Tue, Dec 29, 2020 at 03:06:35PM +, Charles Keepax wrote:
There is maybe more argument for porting the Arizona code across
anyways, since for a long time Android didn't properly support extcon
On 29/12/2020 15:06, Charles Keepax wrote:
On Tue, Dec 29, 2020 at 02:57:38PM +0100, Hans de Goede wrote:
On 12/29/20 2:06 PM, Charles Keepax wrote:
On Mon, Dec 28, 2020 at 04:28:07PM +, Mark Brown wrote:
On Mon, Dec 28, 2020 at 02:16:04PM +0100, Hans de Goede wrote:
And more in
Hi,
On 12/29/20 4:15 PM, Mark Brown wrote:
> On Tue, Dec 29, 2020 at 03:06:35PM +, Charles Keepax wrote:
>
>> There is maybe more argument for porting the Arizona code across
>> anyways, since for a long time Android didn't properly support extcon
>> either. It supported the earlier out of
Hi,
On 12/29/20 4:08 PM, Mark Brown wrote:
> On Tue, Dec 29, 2020 at 02:57:38PM +0100, Hans de Goede wrote:
>> On 12/29/20 2:06 PM, Charles Keepax wrote:
>
>>> I would agree with Mark though that if extcon exists for external
>>> connectors it seems odd that audio jacks would have their own
>>>
On Tue, Dec 29, 2020 at 03:06:35PM +, Charles Keepax wrote:
> There is maybe more argument for porting the Arizona code across
> anyways, since for a long time Android didn't properly support extcon
> either. It supported the earlier out of tree switch stuff, extcon
Completely moving the
On Tue, Dec 29, 2020 at 02:57:38PM +0100, Hans de Goede wrote:
> On 12/29/20 2:06 PM, Charles Keepax wrote:
> > I would agree with Mark though that if extcon exists for external
> > connectors it seems odd that audio jacks would have their own
> > special way rather than just using the connector
On Tue, Dec 29, 2020 at 02:57:38PM +0100, Hans de Goede wrote:
> On 12/29/20 2:06 PM, Charles Keepax wrote:
> > On Mon, Dec 28, 2020 at 04:28:07PM +, Mark Brown wrote:
> >> On Mon, Dec 28, 2020 at 02:16:04PM +0100, Hans de Goede wrote:
> >>
> >>> And more in general AFAIK extcon is sort of
Hi,
On 12/29/20 2:06 PM, Charles Keepax wrote:
> On Mon, Dec 28, 2020 at 04:28:07PM +, Mark Brown wrote:
>> On Mon, Dec 28, 2020 at 02:16:04PM +0100, Hans de Goede wrote:
>>
>>> And more in general AFAIK extcon is sort of deprecated and it is
>>> not advised to use it for new code. I would
On Mon, Dec 28, 2020 at 04:28:07PM +, Mark Brown wrote:
> On Mon, Dec 28, 2020 at 02:16:04PM +0100, Hans de Goede wrote:
>
> > And more in general AFAIK extcon is sort of deprecated and it is
> > not advised to use it for new code. I would esp. not expect it to
> > be used for new
On Mon, Dec 28, 2020 at 02:16:04PM +0100, Hans de Goede wrote:
> And more in general AFAIK extcon is sort of deprecated and it is
> not advised to use it for new code. I would esp. not expect it to
> be used for new jack-detection code since we already have standard
> uAPI support for that
Hi,
On 12/28/20 1:21 PM, Mark Brown wrote:
> On Sun, Dec 27, 2020 at 10:12:19PM +0100, Hans de Goede wrote:
>> The Linux Arizona driver uses the MFD framework to create several
>> sub-devices for the Arizona codec and then uses a driver per function.
>>
>> The jack-detect support for the Arizona
On Sun, Dec 27, 2020 at 10:12:19PM +0100, Hans de Goede wrote:
> The Linux Arizona driver uses the MFD framework to create several
> sub-devices for the Arizona codec and then uses a driver per function.
>
> The jack-detect support for the Arizona codec is handled by the
> extcon-arizona driver.
The Linux Arizona driver uses the MFD framework to create several
sub-devices for the Arizona codec and then uses a driver per function.
The jack-detect support for the Arizona codec is handled by the
extcon-arizona driver. This driver exports info about the jack state
to userspace through the
19 matches
Mail list logo
