💾 Archived View for dioskouroi.xyz › thread › 29454227 captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
If, like me, you think of op-amps and some National Instruments analog-to-digital converters when you think of Analog Devices, you might be wondering what they're doing writing Linux drivers. The short answer is they're acquiring IP: They've bought Linear Technology (which makes tons of PMIC devices) and Maxim Integrated, who make tons of specialized PMIC, analog, RTC, interface, and other chips.
The link above is a press release, the full list of devices is here:
https://wiki.analog.com/resources/tools-software/linux-drive...
Part numbers prefixed with "LTC" are from Linear Tech, part numbers prefixed with "MAX" are Maxim, part numbers prefixed with "AD" are Analog Devices. Part numbers prefixed with "DS" are from Dallas Semiconductor, which was bought by Maxim a long time ago.
As someone who typically uses these devices in much smaller embedded systems, it's nice to have these hardware abstraction layers listed in one place, instead of having to transcribe it from the datasheet.
100%
This is the next logical step for semiconductor companies like AD, TI, etc.
AD doesn't tend to compete on cost, so high quality open source drivers become a key differentiator compared to other companies with lower cost parts, especially as these parts become increasingly complex. A 9 axis IMU with 10 different acquisition and buffering modes, built in algorithms, etc. becomes a lot more tractable if you don't have to write the whole driver from a datasheet.
Actually I think their plan is to continue not competing by acquiring all competition, as is now the norm in the semiconductor business. They call it "consolidation" but lets not mistake it for what it is.
Why are they doing Linux drivers then? They have to compete with international chips now.
I randomly clicked through the list, out of 10 drivers, 3 were written by independent devs, 5 by comapnies they acquired, and the rest by AD.
This looks just like some list of existing drivers, regardless of who wrote them.
AFAIK TI has always been very opensource friendly. All their SOCs are mainlined and maintained including pretty old ones.
Now if Broadcom starts to be opensource friendly then that would be a real change of heart.
Analog Devices also does DSPs such as the Blackfin which, as far as I know, were made in-house and can Linux (well, Linux without MMU, but still).
_If, like me, you think of op-amps and some National Instruments analog-to-digital converters when you think of Analog Devices, you might be wondering what they're doing writing Linux drivers_
That's a pretty dated view of ADI's business.
These days they make most of their cheddar in their high speed data converter business. They have GSPS ADCs and DACs available that are hundreds of dollars per chip.
The Kuiper Linux support for Xilinx Zynq and MPSoC is telling. That's coded language for 5G physical layer and electronic warfare/SIGINT uses.
I know it's a pretty dated view, but is it really true that most of their...profits? revenue? are in the high-speed high-dollar data converter segment? Sure, one of those chips might cost as much as a reel of other chips, but for every van with a SIGINT box, there are thousands of civilian electronic devices.
Linear Technology? I wonder if they can be convinced to open up the source of LTSpice. I'm sure that isn't something they haven't been asked about already... but if they are willing to give such a good simulator away for free, why not show off the source as well?
_if they are willing to give such a good simulator away for free, why not show off the source as well?_
Because giving away the source code to their simulator doesn't make any business sense in the way giving a Linux kernel driver does.
Giving away LTSPICE is an effort to commoditize their complements. The complement to an opamp is a high quality simulation model. The complement to a high speed data converter is a working Linux driver for JESD204B. Both decrease the effort involved for ADI's customer to use ADI's parts.
Giving away LTSpice source code doesn't achieve a similar aim.
That won't happen. They've specifically said that they maintain it because it helps them sell more product. They also encrypt their models. If they open source it, they lose both encryption and exclusivity.
I'd be happy if they'd just open-source the UI. I couldn't care less about the simulator secret sauce, but there is no reason it has to be saddled to a user interface that makes EAGLE look sane by comparison.
The simulator is free (specifically their models) so you buy their parts. As soon as it is opened up and populated with non-LT parts, the incentive disappears. I mean, LTSPICE is the sole reason I use LT parts in my designs.
PMIC = Power management integrated circuit
They bought Hittite too, hence the HMC parts. Too bad the ADI web site sucks. I really miss Linear Tech and Hittite web sites, as they were written for engineer.
Kind of a tangent, but I found:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
static bool ltc4306_is_volatile_reg(struct device *dev, unsigned int reg)
{
return (reg == LTC_REG_CONFIG) ? true : false;
}
Oh man, c'mon. That kind of thing bugs me. Just "return reg == LTC_REG_CONFIG" already, sheesh. (And maybe make it a preprocessor directive while you're at it?)
Int-> bool conversion is something that MSVC complained about (C4800) for the longest time for some kind of obscure reason. Wouldn’t surprise me if this code was written against a longer that had a similar warning OR that maybe this code is shared with their Windows driver and this needs to compile on both (at least that’s my attempt at finding the most generous explanation for that).
Sorry, what int -> bool conversion?
parameter reg is int, return value is bool.
Wouldn't this be a lot more meaningful if they were committing to get these drivers upstream?
It's similar to their LTspice strategy. It's free, but it's only for ADI devices. They want you to buy their stuff.
They'd rather make NetBSD device drivers to support development - every OS (incl. Haiku etc.) would be able to port them then.
Thank you, Analog! I've used a number of these chips -- first-party driver support will also raise the quality of ported drivers to other systems.
So good. Thank you!
So in other words Analog Devices won't be stuffed to upstream their driver work.
exactly, just upstream them, everyone's life will be easier
It baffles me how many times companies go "oh, instead of contributing these changes to an existing distribution, or the mainline, let's release our own shitty fork of that major distribution, which of course we will do a terrible job of keeping current with, and stop maintaining after about a year because the intern that was doing it moved on."
_glares at Hardkernel, Banana Pi_
Cookie consent form literally just has a giant accept button. (Decline is hidden in the text, one level deeper and the button is purposefully made to look like grey text - no clickable button outline).
Props for the driver thing though
file a complaint and make them pay out for it.
I couldn't parse the text. Are (or will) these drivers mainlined?
This seems very interesting to me, but is it any kind of big deal?
I use some of these chips, and took a random stab at one of the files to see what it contained, a SPI-bus i/o expander. It looks pretty useful.
I usually write my own drivers, but that gets to be more and more effort if I want to make use of more sophisticated functions, plus I can make mistakes by mis-reading the datasheet or just counting wrong. I might be discouraged from using a function that I don't quite understand, but a pre-written driver might get me past that.
Note that these "drivers" are routines that talk to fairly low level hardware ports of a Linux computer, and I might modify the code for use on a microcontroller without an OS.
Why are you writing your own drivers?
Good question. Maybe I'm unclear on the definition of "driver." I've used the term to describe the code that exercises the functions of the chip but provides human readable function headers. It's usually not ridiculously hard, interpreting things like register bit definitions and timing diagrams. And in the absence of published code, I'd have been on the hook to write it myself anyway. Often, talking to something like an ADC through a SPI port on a microcontroller might be 10 or 20 lines of code.