On 04/10, Jonathan Cameron wrote: > On Thu, 7 Apr 2022 00:23:29 -0300 > Maíra Canal <maira.canal@xxxxxx> wrote: > > > Hi everyone, I am Maíra Canal an undergrad student at the University > > of São Paulo, Brazil, pursuing > > computer engineering. I wish to participate in the GSoC 2021 as a part > > of the Linux Foundation, IIO Project. > > Hi Maíra, > > Nice to 'meet' you ;) > > > > > I have been contributing to the Linux kernel for a couple of months > > and have more than 20 > > accepted patches in a couple of subsystems. > > > > I started looking through the catalog of Analog Devices Inc. and I'm > > pretty interested in writing a driver for gyroscopes, inertial > > measurement units (IMUs), magnetometers, pressure sensors, proximity > > sensors, or temperature sensors. But, while looking through the > > catalog, I could not figure out a sensor that would be relevant to > > Linux Kernel. I mean, I would like to work on a sensor that would be > > relevant to the community and to Analog Devices Inc. > > > > In that sense, I would like to know if anyone in the IIO community > > could recommend a sensor that would make sense for the company and the > > IIO community. Any suggestion is appreciated! > > I'm not going to recommend a particular sensor, but more offer some general > tips on what 'sort' of device makes a good target for a GSOC. > Finding a sensor means trawling datasheets and I'm tight on time today > + I've no real insight into what the ADI folk might like to see > supported! > > The nature of a GSOC driver submission is often a little different to > how an experienced driver author might go about things, simply because you > will / should be looking for feedback at more stages of development and > hopefully to upstream things in multiple stages. An old hand at IIO > drivers will often just jump directly to a driver supporting all the > features they wish to target. As such, the 'perfect' device to target > should meet a few requirements that may not be true for the approach of jumping > straight to the end goal. Note this is equally true for other people > starting out writing drivers - though they can often do very simple > devices first and that is not a good plan for a GSOC project where > you need to have a progression during the project. > > Try to find something that offers some advanced features to provide > stretch goals but make sure the basic functionality will work with > a much simpler driver. So devices that provide straight forward > registers to access the latest channel value are great, whereas > those that only offer a streaming interfaces / fifo may be less suitable. > However if they offer both that is perfect as the fifo make a good > later feature for a GSOC project if things are going particularly > well! For a real stretch goal, find a device with features that > we don't support at all today (perhaps new sensor types, or some > other new feature) as they'll give you the experience of defining > new ABI + possibly modifying the IIO core to meet some requirements. > > Another thing to look at it is whether the part is sufficiently > different from those supported by existing drivers to justify a > separate driver. If not, you may find your GSOC project becomes > simply adding an ID! (then rapidly choosing a second device to > work on). > > Hope that provides a few hints on what to look at. Probably the best > way around is to suggest one or more parts you think look interesting > then we can give feedback on whether we think they'd be a good choice > or not. Hi Jonathan, I really appreciate the answer. Thank you for your attention and time! During the week, I ended up picking the ADXL375 accelerometer (although I am open to any change proposed by ADI or the IIO community). Based on that device, I wrote a proposal and I would appreciate if you provide some feedback on the device choice and proposal: https://pt.overleaf.com/read/xsmmdpvzqrhd. Regards, Maíra > > Good luck! > > Jonathan > > > > > > > Sincerely, > > Maíra Canal >
