* [Guidance Request] LFX Mentee looking to contribute to ASoC / DT
@ 2025-07-24 22:50 Jihed Chaibi
2025-07-25 13:33 ` Mark Brown
0 siblings, 1 reply; 4+ messages in thread
From: Jihed Chaibi @ 2025-07-24 22:50 UTC (permalink / raw)
To: linux-sound
Cc: devicetree, broonie, robh+dt, krzk+dt, conor+dt, shuah,
kuninori.morimoto.gx
Hello,
My name is Jihed Chaibi. I am currently a mentee in the Linux
Foundation Mentorship Program, working with Shuah Khan.
With a professional background in embedded systems and a strong
personal interest in audio that extends to my own projects, the ASoC
subsystem seems like the perfect place to blend these two passions.
I'm eager to apply my experience with hardware bring-up and Device
Trees by becoming an active contributor.
To get familiar with the subsystem, I have:
- Studied the ASoC framework (the Codec/Platform/Machine driver model).
- Learned about the core audio interfaces (I2S, SAI, PCM, PDM, TDM etc.).
- Analyzed existing DT sound card implementations to understand
simple-audio-card in practice.
As I look to deepen my involvement, I am writing to seek advice on
where I can best apply my efforts. I'm particularly interested in
finding a substantive task where my skills would be a good fit, such
as:
- Enabling audio support for a new board using Device Trees.
- Assisting with bug fixes or small feature additions in the ASoC C drivers.
- Tackling items from the TODO list where my DT experience would
be applicable.
- Helping with other driver enhancements or cleanups within the
ASoC framework.
Any guidance on finding a suitable project would be highly appreciated!
Thank you for your time and for your work on the kernel.
Best regards,
Jihed CHAIBI
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Guidance Request] LFX Mentee looking to contribute to ASoC / DT
2025-07-24 22:50 [Guidance Request] LFX Mentee looking to contribute to ASoC / DT Jihed Chaibi
@ 2025-07-25 13:33 ` Mark Brown
2025-08-07 22:28 ` Jihed Chaibi
0 siblings, 1 reply; 4+ messages in thread
From: Mark Brown @ 2025-07-25 13:33 UTC (permalink / raw)
To: Jihed Chaibi
Cc: linux-sound, devicetree, robh+dt, krzk+dt, conor+dt, shuah,
kuninori.morimoto.gx
[-- Attachment #1: Type: text/plain, Size: 2116 bytes --]
On Fri, Jul 25, 2025 at 12:50:15AM +0200, Jihed Chaibi wrote:
> My name is Jihed Chaibi. I am currently a mentee in the Linux
> Foundation Mentorship Program, working with Shuah Khan.
> With a professional background in embedded systems and a strong
> personal interest in audio that extends to my own projects, the ASoC
> subsystem seems like the perfect place to blend these two passions.
> I'm eager to apply my experience with hardware bring-up and Device
> Trees by becoming an active contributor.
That's great. To be honest it sounds like you're already very up to
speed so I'm not sure I'm going to have anything here that isn't pretty
generic.
> As I look to deepen my involvement, I am writing to seek advice on
> where I can best apply my efforts. I'm particularly interested in
> finding a substantive task where my skills would be a good fit, such
> as:
> - Enabling audio support for a new board using Device Trees.
> - Assisting with bug fixes or small feature additions in the ASoC C drivers.
> - Tackling items from the TODO list where my DT experience would
> be applicable.
> - Helping with other driver enhancements or cleanups within the
> ASoC framework.
> Any guidance on finding a suitable project would be highly appreciated!
One big thing with embedded stuff like this is hardware access to test -
an awful lot of stuff is going to be hard to work on just purely with
software. Given that it's probably useful to take a look at what
systems you have or can readily get hold of and then consider what
problems they have that might be good to work on - things like board
enablement would be an obvious example there, and it's common that
boards have some support but pretty basic so there's useful things can
be done extending that (eg, leaving a lot of features unused and just
supporting basic playback/capture). Knowing what you've got to hand
would make it a lot easier to suggest concrete ideas.
It's worth noting that a lot of x86 laptops these days are ASoC based,
their SoCs are built in the same way as mobile SoCs, so might be worth
considering those too.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Guidance Request] LFX Mentee looking to contribute to ASoC / DT
2025-07-25 13:33 ` Mark Brown
@ 2025-08-07 22:28 ` Jihed Chaibi
2025-08-08 13:01 ` Mark Brown
0 siblings, 1 reply; 4+ messages in thread
From: Jihed Chaibi @ 2025-08-07 22:28 UTC (permalink / raw)
To: Mark Brown
Cc: linux-sound, devicetree, robh+dt, krzk+dt, conor+dt, shuah,
kuninori.morimoto.gx
On Fri, Jul 25, 2025 at 3:33 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, Jul 25, 2025 at 12:50:15AM +0200, Jihed Chaibi wrote:
>
> > My name is Jihed Chaibi. I am currently a mentee in the Linux
> > Foundation Mentorship Program, working with Shuah Khan.
>
> > With a professional background in embedded systems and a strong
> > personal interest in audio that extends to my own projects, the ASoC
> > subsystem seems like the perfect place to blend these two passions.
> > I'm eager to apply my experience with hardware bring-up and Device
> > Trees by becoming an active contributor.
>
> That's great. To be honest it sounds like you're already very up to
> speed so I'm not sure I'm going to have anything here that isn't pretty
> generic.
>
> > As I look to deepen my involvement, I am writing to seek advice on
> > where I can best apply my efforts. I'm particularly interested in
> > finding a substantive task where my skills would be a good fit, such
> > as:
>
> > - Enabling audio support for a new board using Device Trees.
> > - Assisting with bug fixes or small feature additions in the ASoC C drivers.
> > - Tackling items from the TODO list where my DT experience would
> > be applicable.
> > - Helping with other driver enhancements or cleanups within the
> > ASoC framework.
>
> > Any guidance on finding a suitable project would be highly appreciated!
>
> One big thing with embedded stuff like this is hardware access to test -
> an awful lot of stuff is going to be hard to work on just purely with
> software. Given that it's probably useful to take a look at what
> systems you have or can readily get hold of and then consider what
> problems they have that might be good to work on - things like board
> enablement would be an obvious example there, and it's common that
> boards have some support but pretty basic so there's useful things can
> be done extending that (eg, leaving a lot of features unused and just
> supporting basic playback/capture). Knowing what you've got to hand
> would make it a lot easier to suggest concrete ideas.
>
> It's worth noting that a lot of x86 laptops these days are ASoC based,
> their SoCs are built in the same way as mobile SoCs, so might be worth
> considering those too.
Hi Mark, and everyone,
Thank you for the thoughtful advice, I am currently researching a few
newer boards to order, specifically looking for ones with incomplete
audio support.
For an immediate contribution that I can start on without specific
hardware, I've been digging into the DT bindings and identified a
challenge I'd like to help solve.
While learning to configure audio, I found that discovering the valid
routing strings (simple-audio-card,routing) for a lot of codecs is
kind of difficult. Currently, for most codecs, the only way to find
those is to read the ASoC C driver source for the specific codec. This
seems problematic for a few reasons:
- It creates a high barrier for developers who are focused on
board bring-up, forcing them to navigate complex C driver code just to
configure a (simple) device tree node.
- The process is inefficient and error-prone, as typos when
copying strings can lead to audio routes failing silently and being
difficult to debug.
I believe documenting these strings directly in each codec's DT
binding file (.yaml) would be a significant improvement. It would make
the binding self-contained and greatly improve the experience for
anyone setting up audio on a board.
Does this seem like a useful contribution? If you agree, I can get
started immediately on preparing a patch for a popular codec to serve
as an example.
Thanks again for your time,
Jihed
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Guidance Request] LFX Mentee looking to contribute to ASoC / DT
2025-08-07 22:28 ` Jihed Chaibi
@ 2025-08-08 13:01 ` Mark Brown
0 siblings, 0 replies; 4+ messages in thread
From: Mark Brown @ 2025-08-08 13:01 UTC (permalink / raw)
To: Jihed Chaibi
Cc: linux-sound, devicetree, robh+dt, krzk+dt, conor+dt, shuah,
kuninori.morimoto.gx
[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]
On Fri, Aug 08, 2025 at 12:28:16AM +0200, Jihed Chaibi wrote:
> For an immediate contribution that I can start on without specific
> hardware, I've been digging into the DT bindings and identified a
> challenge I'd like to help solve.
> While learning to configure audio, I found that discovering the valid
> routing strings (simple-audio-card,routing) for a lot of codecs is
> kind of difficult. Currently, for most codecs, the only way to find
> those is to read the ASoC C driver source for the specific codec. This
> seems problematic for a few reasons:
The names are supposed to be documented in the bindings FWIW, but yes
this is an oversight in a bunch of bindings. The general theory is that
the pins on the edges of devices should be named after the pins on the
device so hopefully if you just work from the schematic things will work
out without ever having to reference the bindings.
> I believe documenting these strings directly in each codec's DT
> binding file (.yaml) would be a significant improvement. It would make
> the binding self-contained and greatly improve the experience for
> anyone setting up audio on a board.
> Does this seem like a useful contribution? If you agree, I can get
> started immediately on preparing a patch for a popular codec to serve
> as an example.
Yes, that'd definitely be useful. There are some bindings that document
these properties already (eg, wm8731) but it's just a text list rather
than a property so can't be automatically checked which would be another
step further. Just getting information into the binding documents at
all for CODECs that don't yet have it would be good though.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-08-08 13:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-24 22:50 [Guidance Request] LFX Mentee looking to contribute to ASoC / DT Jihed Chaibi
2025-07-25 13:33 ` Mark Brown
2025-08-07 22:28 ` Jihed Chaibi
2025-08-08 13:01 ` Mark Brown
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).