From: Hans de Goede <hdegoede@redhat.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andy Shevchenko <andy@kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>
Subject: Re: RFC: pinctrl: baytrail: Need to fixup mux setting due to broken BIOS/DSDT
Date: Sun, 16 Jan 2022 22:54:26 +0100 [thread overview]
Message-ID: <d86caedb-4d34-4ded-d02d-a25e5e29072a@redhat.com> (raw)
In-Reply-To: <CAHp75VfpyYuB5q+L6P+3RB52mK89=PfpHx4JG-AM=M3HaJ5D3w@mail.gmail.com>
Hi,
On 1/16/22 22:11, Andy Shevchenko wrote:
> On Sat, Jan 15, 2022 at 6:45 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi Andy, Mika,
>>
>> For one of the x86 Android tablets with broken DSDTs which I'm working on
>> I need to change the mux value of pin 6 of SUS aka INT33FC:02 from 0 to 1,
>> this changes it from a normal GPIO to outputting the PMC's 32KHz clk.
>> This is needed for the jack-detection in the audio codec which needs an
>> external 32KHz clock to work and that is connected to pin 6 of SUS.
>>
>> On the Windows version of the same tablet (which uses slightly different
>> hardware, e.g. there is an embedded controller on the board which the
>> Android version lacks) there is an ACPI call to toggle the mux, since
>> the firmware does not set it for us.
>>
>> So the x86-android-tablets.c code for working around all the firmware
>> challenges on these devices will need a way to toggle the mux and
>> directly poking it itself is a bad idea because of the need
>> to serialize all accesses to the GPIO islands on byt, see:
>>
>> 39ce8150a079 ("pinctrl: baytrail: Serialize all register access")
>>
>> So I see 2 possible options:
>>
>> 1. Add a pingroup for this pin in drivers/pinctrl/intel/pinctrl-baytrail.c
>> and then mimick the pwm0 pinconf setting code from
>> drivers/gpu/drm/i915/display/intel_dsi_vbt.c in x86-android-tablets.c
>> This seems the cleanest, but I'm leaning a bit towards:
>
> If you meant
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_dsi_vbt.c#L858
> this is definitely the way to go.
Ok, I already figured as much, thank you for your input.
Regards,
Hans
prev parent reply other threads:[~2022-01-16 21:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-15 16:45 RFC: pinctrl: baytrail: Need to fixup mux setting due to broken BIOS/DSDT Hans de Goede
2022-01-16 21:11 ` Andy Shevchenko
2022-01-16 21:54 ` Hans de Goede [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d86caedb-4d34-4ded-d02d-a25e5e29072a@redhat.com \
--to=hdegoede@redhat.com \
--cc=andy.shevchenko@gmail.com \
--cc=andy@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).