* [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).