Skip to content

ASoC: intel: bytcr_rt5651: add remove function to disable jack - #1149

Merged
plbossart merged 1 commit into
thesofproject:topic/sof-devfrom
juimonen:rt5651_fix
Sep 5, 2019
Merged

plbossart merged 1 commit into
thesofproject:topic/sof-devfrom
juimonen:rt5651_fix

Conversation

@juimonen

Copy link
Copy Markdown

When removing sof module the rt5651 jack handler will oops
if jack detection is not disabled. So add remove function,
which disables the jack detection.

Signed-off-by: Jaska Uimonen jaska.uimonen@intel.com

@juimonen

Copy link
Copy Markdown
Author

a long shot following rt5682 fix...

@wenqingfu

Copy link
Copy Markdown

SOFCI TEST

@juimonen
juimonen force-pushed the rt5651_fix branch 2 times, most recently from 4622638 to f37b0df Compare August 23, 2019 12:35
@plbossart

Copy link
Copy Markdown
Member

@juimonen you may want to work with Hans De Goede (@jwrdegoede), he's done quite a bit of rt5651 support for baytrail tablets and might have devices you can test this patch on. Though those devices are usually BYT-CR and we don't support them well with SOF so far due to this stupid SSP2-SSP0 swap.

@jwrdegoede

jwrdegoede commented Aug 24, 2019 via email

Copy link
Copy Markdown

@juimonen

Copy link
Copy Markdown
Author

@jwrdegoede ok thanks! I'll try still to do couple of more iterations internally, I'll then think what to do...

When removing sof module the support_button_press function will oops
because hp_jack pointer is not checked for NULL. So add a check to fix
this.

Signed-off-by: Jaska Uimonen <jaska.uimonen@intel.com>
@juimonen

Copy link
Copy Markdown
Author

@plbossart in rt5651 the headset detection work seems to be cancelled when the module is removed. However if I add a null check in the support_button_press function we don't get oops in module removal anymore. Don't know if this is a correct fix though... @jwrdegoede any thoughts?

Comment thread sound/soc/codecs/rt5651.c

/* Button press support only works with internal jack-detection */
return (rt5651->hp_jack->status & SND_JACK_MICROPHONE) &&
rt5651->gpiod_hp_det == NULL;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you look at the caller, the hp_jack is set to NULL after calling this function:

static void rt5651_disable_jack_detect(struct snd_soc_component *component)
{
	struct rt5651_priv *rt5651 = snd_soc_component_get_drvdata(component);

	disable_irq(rt5651->irq);
	rt5651_cancel_work(rt5651);

	if (rt5651_support_button_press(rt5651)) {
		rt5651_disable_micbias1_ovcd_irq(component);
		rt5651_disable_micbias1_for_ovcd(component);
		snd_soc_jack_report(rt5651->hp_jack, 0, SND_JACK_BTN_0);
	}

	rt5651->hp_jack = NULL;
}

so something is fishy here.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@plbossart yes for sure. I guess I'm delaying something with the addition or someone is calling set_jack(NULL) twice. As I understand this will access NULL if you call it twice? Not sure of the semantics of set_jack, I guess you should be able to call it twice with NULL...

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@juimonen there was a recent addition in soc-core.c to call set_jack(NULL) for robustness.

snd_soc_component_set_jack(component, NULL, NULL);

Do you think this could be the reason?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it is, I think this fix is correct.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the commit that added this change: 3bb936f

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ranjani yeah could be... I don't have the rt5651 device to test this, usually these devices don't reboot nicely after kernel oops, so it is really hard also with remote access device.

@ranj063 ranj063 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@juimonen @plbossart this fix looks right to me.

@plbossart

Copy link
Copy Markdown
Member

This PR was not tested by SOF CI, so has anyone actually tried the code on a platform with rt5651?

@juimonen

juimonen commented Sep 5, 2019

Copy link
Copy Markdown
Author

@plbossart only @Jiangxinx tested on device with rt5651: #1059 (comment)

@plbossart

Copy link
Copy Markdown
Member

@plbossart only @Jiangxinx tested on device with rt5651: #1059 (comment)

ok, thanks for the pointer.

@plbossart
plbossart merged commit fa20ceb into thesofproject:topic/sof-dev Sep 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants