All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas tanure <tanureal@opensource.cirrus.com>
To: Stefan Binding <sbinding@opensource.cirrus.com>,
	'Hans de Goede' <hdegoede@redhat.com>,
	"'Rafael J. Wysocki'" <rafael@kernel.org>
Cc: 'Len Brown' <lenb@kernel.org>,
	'Mark Gross' <markgross@kernel.org>,
	'Liam Girdwood' <lgirdwood@gmail.com>,
	'Jaroslav Kysela' <perex@perex.cz>,
	'Mark Brown' <broonie@kernel.org>,
	'Takashi Iwai' <tiwai@suse.com>,
	"'moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
	MANAGEM...'"  <alsa-devel@alsa-project.org>,
	'ACPI Devel Maling List' <linux-acpi@vger.kernel.org>,
	<patches@opensource.cirrus.com>,
	'Platform Driver' <platform-driver-x86@vger.kernel.org>,
	'Linux Kernel Mailing List' <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 08/10] ACPI / scan: Create platform device for CLSA0100 and CSC3551 ACPI nodes
Date: Wed, 12 Jan 2022 13:05:02 +0000	[thread overview]
Message-ID: <e2d39d52-c139-a94a-94cc-88841d3638e3@opensource.cirrus.com> (raw)
In-Reply-To: <004001d7f5c6$7329d4d0$597d7e70$@opensource.cirrus.com>

On 12/20/21 17:24, Stefan Binding wrote:
> Hi,
> 
>> -----Original Message-----
>> From: Hans de Goede <hdegoede@redhat.com>
>> Sent: 17 December 2021 18:27
>> To: Rafael J. Wysocki <rafael@kernel.org>; Lucas Tanure
>> <tanureal@opensource.cirrus.com>; Stefan Binding
>> <sbinding@opensource.cirrus.com>
>> Cc: Len Brown <lenb@kernel.org>; Mark Gross <markgross@kernel.org>;
>> Liam Girdwood <lgirdwood@gmail.com>; Jaroslav Kysela <perex@perex.cz>;
>> Mark Brown <broonie@kernel.org>; Takashi Iwai <tiwai@suse.com>;
>> moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
>> <alsa-devel@alsa-project.org>; ACPI Devel Maling List <linux-
>> acpi@vger.kernel.org>; patches@opensource.cirrus.com; Platform Driver
>> <platform-driver-x86@vger.kernel.org>; Linux Kernel Mailing List <linux-
>> kernel@vger.kernel.org>
>> Subject: Re: [PATCH v6 08/10] ACPI / scan: Create platform device for
>> CLSA0100 and CSC3551 ACPI nodes
>>
>> Hi,
>>
>> On 12/17/21 18:19, Rafael J. Wysocki wrote:
>>> On Fri, Dec 17, 2021 at 12:57 PM Lucas Tanure
>>> <tanureal@opensource.cirrus.com> wrote:
>>>>
>>>> The ACPI device with CLSA0100 or CSC3551 is a sound card
>>>> with multiple instances of CS35L41 connectec by I2C to
>>>
>>> "connected" I suppose?
>>>
>>>> the main CPU.
>>>>
>>>> We add an ID to the i2c_multi_instantiate_ids list to enumerate
>>>> all I2C slaves correctly.
>>>>
>>>> Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>
>>>
>>> This requires an ACK from Hans.
>>>
>>> If you receive one, please feel free to add my ACK to it too.
>>
>> One problem which I see here is that this change conflicts with
>> this series:
>>
>> https://lore.kernel.org/all/20211210154050.3713-1-
>> sbinding@opensource.cirrus.com/
>>
>> I have reviewing that series on my todo list.
>>
>> One interesting question for you (Rafael) about that series is
>> that i2c-multi-instantiate.c, which after the series also handles
>> spi devices,is being moved to drivers/acpi .
>>
>> This is fine with me, but I wonder if it would not be better
>> to keep it under drivers/platform/x86 ? Since the new SPI
>> use-cases are also all on x86 laptops AFAICT.
>>
>> But back to this series, as said the 2 series conflict, since
>> both are being submitted by @opensource.cirrus.com people,
>> it would be good if the Cirrus folks can decide in which
>> order these series should be merged.
>>
>> It might be best to just move this one patch to the other series?
>> Thus removing the conflict between the 2 series.
>>
>> Regards,
>>
>> Hans
>>
> 
> We don’t really have a preference which order these two chains
> should be merged in. We would rebase the other chain if one
> got merged first.
> If pushed for an answer, maybe:
> https://lore.kernel.org/all/20211210154050.3713-1-sbinding@opensource.cirrus.com/
> should be merged first?
> 
> Thanks,
> Stefan
> 
>>
>>
>>>> ---
>>>>   drivers/acpi/scan.c                          |  3 +++
>>>>   drivers/platform/x86/i2c-multi-instantiate.c | 11 +++++++++++
>>>>   2 files changed, 14 insertions(+)
>>>>
>>>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>>>> index b7a6b982226e..8740cfa11f59 100644
>>>> --- a/drivers/acpi/scan.c
>>>> +++ b/drivers/acpi/scan.c
>>>> @@ -1712,8 +1712,11 @@ static bool
>> acpi_device_enumeration_by_parent(struct acpi_device *device)
>>>>          static const struct acpi_device_id i2c_multi_instantiate_ids[] = {
>>>>                  {"BSG1160", },
>>>>                  {"BSG2150", },
>>>> +               {"CSC3551", },
>>>>                  {"INT33FE", },
>>>>                  {"INT3515", },
>>>> +               /* Non-conforming _HID for Cirrus Logic already released */
>>>> +               {"CLSA0100", },
>>>>                  {}
>>>>          };
>>>>
>>>> diff --git a/drivers/platform/x86/i2c-multi-instantiate.c
>> b/drivers/platform/x86/i2c-multi-instantiate.c
>>>> index 4956a1df5b90..a889789b966c 100644
>>>> --- a/drivers/platform/x86/i2c-multi-instantiate.c
>>>> +++ b/drivers/platform/x86/i2c-multi-instantiate.c
>>>> @@ -147,6 +147,14 @@ static const struct i2c_inst_data int3515_data[]  =
>> {
>>>>          {}
>>>>   };
>>>>
>>>> +static const struct i2c_inst_data cs35l41_hda[] = {
>>>> +       { "cs35l41-hda", IRQ_RESOURCE_GPIO, 0 },
>>>> +       { "cs35l41-hda", IRQ_RESOURCE_GPIO, 0 },
>>>> +       { "cs35l41-hda", IRQ_RESOURCE_GPIO, 0 },
>>>> +       { "cs35l41-hda", IRQ_RESOURCE_GPIO, 0 },
>>>> +       {}
>>>> +};
>>>> +
>>>>   /*
>>>>    * Note new device-ids must also be added to i2c_multi_instantiate_ids in
>>>>    * drivers/acpi/scan.c: acpi_device_enumeration_by_parent().
>>>> @@ -154,7 +162,10 @@ static const struct i2c_inst_data int3515_data[]  =
>> {
>>>>   static const struct acpi_device_id i2c_multi_inst_acpi_ids[] = {
>>>>          { "BSG1160", (unsigned long)bsg1160_data },
>>>>          { "BSG2150", (unsigned long)bsg2150_data },
>>>> +       { "CSC3551", (unsigned long)cs35l41_hda },
>>>>          { "INT3515", (unsigned long)int3515_data },
>>>> +       /* Non-conforming _HID for Cirrus Logic already released */
>>>> +       { "CLSA0100", (unsigned long)cs35l41_hda },
>>>>          { }
>>>>   };
>>>>   MODULE_DEVICE_TABLE(acpi, i2c_multi_inst_acpi_ids);
>>>> --
>>>> 2.34.1
>>>>
>>>
> 
> 
As the ic2-multi-instantiate patch chain is still being worked out, we 
would like to submit a new chain for CLSA0100 id and a few fixes for the 
HDA cs35l41 driver.
And to avoid conflicts the ic2-multi-instantiate patch chain will wait 
for this new patch chain to be merged.

Thanks,
Lucas Tanure

WARNING: multiple messages have this Message-ID (diff)
From: Lucas tanure <tanureal@opensource.cirrus.com>
To: Stefan Binding <sbinding@opensource.cirrus.com>,
	'Hans de Goede' <hdegoede@redhat.com>,
	"'Rafael J. Wysocki'" <rafael@kernel.org>
Cc: "'moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
	MANAGEM...'" <alsa-devel@alsa-project.org>,
	'Liam Girdwood' <lgirdwood@gmail.com>,
	patches@opensource.cirrus.com, 'Takashi Iwai' <tiwai@suse.com>,
	'Mark Gross' <markgross@kernel.org>,
	'ACPI Devel Maling List' <linux-acpi@vger.kernel.org>,
	'Mark Brown' <broonie@kernel.org>,
	'Platform Driver' <platform-driver-x86@vger.kernel.org>,
	'Linux Kernel Mailing List' <linux-kernel@vger.kernel.org>,
	'Len Brown' <lenb@kernel.org>
Subject: Re: [PATCH v6 08/10] ACPI / scan: Create platform device for CLSA0100 and CSC3551 ACPI nodes
Date: Wed, 12 Jan 2022 13:05:02 +0000	[thread overview]
Message-ID: <e2d39d52-c139-a94a-94cc-88841d3638e3@opensource.cirrus.com> (raw)
In-Reply-To: <004001d7f5c6$7329d4d0$597d7e70$@opensource.cirrus.com>

On 12/20/21 17:24, Stefan Binding wrote:
> Hi,
> 
>> -----Original Message-----
>> From: Hans de Goede <hdegoede@redhat.com>
>> Sent: 17 December 2021 18:27
>> To: Rafael J. Wysocki <rafael@kernel.org>; Lucas Tanure
>> <tanureal@opensource.cirrus.com>; Stefan Binding
>> <sbinding@opensource.cirrus.com>
>> Cc: Len Brown <lenb@kernel.org>; Mark Gross <markgross@kernel.org>;
>> Liam Girdwood <lgirdwood@gmail.com>; Jaroslav Kysela <perex@perex.cz>;
>> Mark Brown <broonie@kernel.org>; Takashi Iwai <tiwai@suse.com>;
>> moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
>> <alsa-devel@alsa-project.org>; ACPI Devel Maling List <linux-
>> acpi@vger.kernel.org>; patches@opensource.cirrus.com; Platform Driver
>> <platform-driver-x86@vger.kernel.org>; Linux Kernel Mailing List <linux-
>> kernel@vger.kernel.org>
>> Subject: Re: [PATCH v6 08/10] ACPI / scan: Create platform device for
>> CLSA0100 and CSC3551 ACPI nodes
>>
>> Hi,
>>
>> On 12/17/21 18:19, Rafael J. Wysocki wrote:
>>> On Fri, Dec 17, 2021 at 12:57 PM Lucas Tanure
>>> <tanureal@opensource.cirrus.com> wrote:
>>>>
>>>> The ACPI device with CLSA0100 or CSC3551 is a sound card
>>>> with multiple instances of CS35L41 connectec by I2C to
>>>
>>> "connected" I suppose?
>>>
>>>> the main CPU.
>>>>
>>>> We add an ID to the i2c_multi_instantiate_ids list to enumerate
>>>> all I2C slaves correctly.
>>>>
>>>> Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>
>>>
>>> This requires an ACK from Hans.
>>>
>>> If you receive one, please feel free to add my ACK to it too.
>>
>> One problem which I see here is that this change conflicts with
>> this series:
>>
>> https://lore.kernel.org/all/20211210154050.3713-1-
>> sbinding@opensource.cirrus.com/
>>
>> I have reviewing that series on my todo list.
>>
>> One interesting question for you (Rafael) about that series is
>> that i2c-multi-instantiate.c, which after the series also handles
>> spi devices,is being moved to drivers/acpi .
>>
>> This is fine with me, but I wonder if it would not be better
>> to keep it under drivers/platform/x86 ? Since the new SPI
>> use-cases are also all on x86 laptops AFAICT.
>>
>> But back to this series, as said the 2 series conflict, since
>> both are being submitted by @opensource.cirrus.com people,
>> it would be good if the Cirrus folks can decide in which
>> order these series should be merged.
>>
>> It might be best to just move this one patch to the other series?
>> Thus removing the conflict between the 2 series.
>>
>> Regards,
>>
>> Hans
>>
> 
> We don’t really have a preference which order these two chains
> should be merged in. We would rebase the other chain if one
> got merged first.
> If pushed for an answer, maybe:
> https://lore.kernel.org/all/20211210154050.3713-1-sbinding@opensource.cirrus.com/
> should be merged first?
> 
> Thanks,
> Stefan
> 
>>
>>
>>>> ---
>>>>   drivers/acpi/scan.c                          |  3 +++
>>>>   drivers/platform/x86/i2c-multi-instantiate.c | 11 +++++++++++
>>>>   2 files changed, 14 insertions(+)
>>>>
>>>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>>>> index b7a6b982226e..8740cfa11f59 100644
>>>> --- a/drivers/acpi/scan.c
>>>> +++ b/drivers/acpi/scan.c
>>>> @@ -1712,8 +1712,11 @@ static bool
>> acpi_device_enumeration_by_parent(struct acpi_device *device)
>>>>          static const struct acpi_device_id i2c_multi_instantiate_ids[] = {
>>>>                  {"BSG1160", },
>>>>                  {"BSG2150", },
>>>> +               {"CSC3551", },
>>>>                  {"INT33FE", },
>>>>                  {"INT3515", },
>>>> +               /* Non-conforming _HID for Cirrus Logic already released */
>>>> +               {"CLSA0100", },
>>>>                  {}
>>>>          };
>>>>
>>>> diff --git a/drivers/platform/x86/i2c-multi-instantiate.c
>> b/drivers/platform/x86/i2c-multi-instantiate.c
>>>> index 4956a1df5b90..a889789b966c 100644
>>>> --- a/drivers/platform/x86/i2c-multi-instantiate.c
>>>> +++ b/drivers/platform/x86/i2c-multi-instantiate.c
>>>> @@ -147,6 +147,14 @@ static const struct i2c_inst_data int3515_data[]  =
>> {
>>>>          {}
>>>>   };
>>>>
>>>> +static const struct i2c_inst_data cs35l41_hda[] = {
>>>> +       { "cs35l41-hda", IRQ_RESOURCE_GPIO, 0 },
>>>> +       { "cs35l41-hda", IRQ_RESOURCE_GPIO, 0 },
>>>> +       { "cs35l41-hda", IRQ_RESOURCE_GPIO, 0 },
>>>> +       { "cs35l41-hda", IRQ_RESOURCE_GPIO, 0 },
>>>> +       {}
>>>> +};
>>>> +
>>>>   /*
>>>>    * Note new device-ids must also be added to i2c_multi_instantiate_ids in
>>>>    * drivers/acpi/scan.c: acpi_device_enumeration_by_parent().
>>>> @@ -154,7 +162,10 @@ static const struct i2c_inst_data int3515_data[]  =
>> {
>>>>   static const struct acpi_device_id i2c_multi_inst_acpi_ids[] = {
>>>>          { "BSG1160", (unsigned long)bsg1160_data },
>>>>          { "BSG2150", (unsigned long)bsg2150_data },
>>>> +       { "CSC3551", (unsigned long)cs35l41_hda },
>>>>          { "INT3515", (unsigned long)int3515_data },
>>>> +       /* Non-conforming _HID for Cirrus Logic already released */
>>>> +       { "CLSA0100", (unsigned long)cs35l41_hda },
>>>>          { }
>>>>   };
>>>>   MODULE_DEVICE_TABLE(acpi, i2c_multi_inst_acpi_ids);
>>>> --
>>>> 2.34.1
>>>>
>>>
> 
> 
As the ic2-multi-instantiate patch chain is still being worked out, we 
would like to submit a new chain for CLSA0100 id and a few fixes for the 
HDA cs35l41 driver.
And to avoid conflicts the ic2-multi-instantiate patch chain will wait 
for this new patch chain to be merged.

Thanks,
Lucas Tanure

  reply	other threads:[~2022-01-12 13:06 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17 11:56 [PATCH v6 00/10] Add support for CS35L41 in HDA systems Lucas Tanure
2021-12-17 11:56 ` Lucas Tanure
2021-12-17 11:56 ` [PATCH v6 01/10] ASoC: cs35l41: Convert tables to shared source code Lucas Tanure
2021-12-17 11:56   ` Lucas Tanure
2021-12-17 11:57 ` [PATCH v6 02/10] ASoC: cs35l41: Move cs35l41_otp_unpack to shared code Lucas Tanure
2021-12-17 11:57   ` Lucas Tanure
2021-12-17 11:57 ` [PATCH v6 03/10] ASoC: cs35l41: Move power initializations to reg_sequence Lucas Tanure
2021-12-17 11:57   ` Lucas Tanure
2021-12-17 11:57 ` [PATCH v6 04/10] ASoC: cs35l41: Create shared function for errata patches Lucas Tanure
2021-12-17 11:57   ` Lucas Tanure
2021-12-17 11:57 ` [PATCH v6 05/10] ASoC: cs35l41: Create shared function for setting channels Lucas Tanure
2021-12-17 11:57   ` Lucas Tanure
2021-12-17 11:57 ` [PATCH v6 06/10] ASoC: cs35l41: Create shared function for boost configuration Lucas Tanure
2021-12-17 11:57   ` Lucas Tanure
2021-12-17 11:57 ` [PATCH v6 07/10] hda: cs35l41: Add support for CS35L41 in HDA systems Lucas Tanure
2021-12-17 11:57   ` Lucas Tanure
2022-01-05  9:58   ` Charles Keepax
2022-01-05  9:58     ` Charles Keepax
2022-01-06 12:29   ` Andy Shevchenko
2022-01-06 12:29     ` Andy Shevchenko
2022-01-10 10:19     ` Andy Shevchenko
2022-01-10 10:19       ` Andy Shevchenko
2022-01-13 16:53     ` Lucas tanure
2022-01-13 16:53       ` Lucas tanure
2022-01-13 18:13       ` Andy Shevchenko
2022-01-13 18:13         ` Andy Shevchenko
2022-01-13 18:19         ` Andy Shevchenko
2022-01-13 18:19           ` Andy Shevchenko
2022-10-31  5:38     ` Dmitry Torokhov
2022-10-31  5:38       ` Dmitry Torokhov
2022-10-31 14:34       ` Andy Shevchenko
2022-10-31 14:34         ` Andy Shevchenko
2021-12-17 11:57 ` [PATCH v6 08/10] ACPI / scan: Create platform device for CLSA0100 and CSC3551 ACPI nodes Lucas Tanure
2021-12-17 11:57   ` Lucas Tanure
2021-12-17 17:19   ` Rafael J. Wysocki
2021-12-17 17:19     ` Rafael J. Wysocki
2021-12-17 18:26     ` Hans de Goede
2021-12-17 18:26       ` Hans de Goede
2021-12-20 13:01       ` Mark Brown
2021-12-20 13:01         ` Mark Brown
2021-12-20 17:24       ` Stefan Binding
2021-12-20 17:24         ` Stefan Binding
2022-01-12 13:05         ` Lucas tanure [this message]
2022-01-12 13:05           ` Lucas tanure
2022-01-12 20:00           ` Cameron Berkenpas
2022-01-12 20:00             ` Cameron Berkenpas
2022-01-13 15:52             ` tanureal
2022-01-13 15:52               ` tanureal
2021-12-17 11:57 ` [PATCH v6 09/10] ALSA: hda/realtek: Add support for Legion 7 16ACHg6 laptop Lucas Tanure
2021-12-17 11:57   ` Lucas Tanure
2021-12-17 11:57 ` [PATCH v6 10/10] ALSA: hda/realtek: Add CS35L41 support for Thinkpad laptops Lucas Tanure
2021-12-17 11:57   ` Lucas Tanure
2021-12-31 14:39 ` (subset) [PATCH v6 00/10] Add support for CS35L41 in HDA systems Mark Brown
2021-12-31 14:39   ` Mark Brown
2022-01-04 13:07   ` Takashi Iwai
2022-01-04 13:07     ` Takashi Iwai
2022-01-05 16:32     ` Takashi Iwai
2022-01-05 16:32       ` Takashi Iwai

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=e2d39d52-c139-a94a-94cc-88841d3638e3@opensource.cirrus.com \
    --to=tanureal@opensource.cirrus.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=lenb@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markgross@kernel.org \
    --cc=patches@opensource.cirrus.com \
    --cc=perex@perex.cz \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=sbinding@opensource.cirrus.com \
    --cc=tiwai@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.