What is the scenario if I have to install a device that does not have drivers in Kernel?

I am working with device tree but I need some bigger picture understanding first in order to go into details.

Let's assume there is a video encoding device that is attached with embedded hardware like raspberry pi using I2C may be or SPI (interface does not matter for now). In my understanding there is a big chance that you will get the drivers of most hardware in the Linux Kernel but if you do not find the driver for that particular device.

What will be our option here? Do I have to write the drivers on my own? Then I have to put those drivers in Linux Kernel and then enable them in the device tree?

How to write those drivers (I am not asking for a tutorial but in general) is it exactly like how we write drivers in embedded systems like STM32 where we have to set data on registers and then get data from registers, managing bits of data etc?

I just need some big picture information so that I can then go into the detail and use it as a rough guide in the world of linux drivers.

There's linux kernel documents online explaining that driver wrtiting process.

My uninitiated understanding of it is that devices have a pci or usb ID. From that the kernel module & firmware are loaded. If it's not pci or usb, it's the port that's driven.

Writing code for the kernel is a serious business and a high coding standard is required. If your code is sub-par, you can write a driver which combines it's own source files with kernel files. This is common with realtek drivers. Many companies hire kernel devs; but realtek's don't. So guys write drivers on github which do this. I recently built drivers for the RTL8821CU and the RTL88x2BU and RinCat & morrownr both have drivers that compile on 5.x kernels and install. They are good examples. Why not study them?

If you don't have experience, i2c is easy but exposes hardware. The GPIO stuff is a pain in the gooseberries. Enjoy yourself.

Originally Posted by zua5248 What will be our option here?

What are your chip selection criteria?
Are you choosing a chip using just board/hardware-oriented criteria such as chip size, number of pins, power consumption, availability, vendor relationships?
Or is there a system perspective that includes software features and compatibility, and availability of driver(s) for your kernel?

Originally Posted by zua5248 Do I have to write the drivers on my own?

Since that can be riskiest and/or most expensive path, you need to check all resources. Make inquires to the chip manufacturer. Besides the Linux kernel github, check the appropriate mailing lists (e.g. linux-media) for any developments pertaining to the chip in question.
Alternatively you could hire someone (or an outfit) to do the development for you.
Beware of licensing issues. I'm not a lawyer, but if you base your new driver on an existing Linux kernel driver (which is under GPL), then your work is also GPL. It you want/need to develop proprietary code (think Nvidia), then you would need to use a "clean room" method.

Originally Posted by zua5248 Then I have to put those drivers in Linux Kernel and then enable them in the device tree?

Broadly speaking, yes.

Originally Posted by zua5248 How to write those drivers (I am not asking for a tutorial but in general) is it exactly like how we write drivers in embedded systems like STM32 where we have to set data on registers and then get data from registers, managing bits of data etc?

That sounds like an unstructured microcontroller perspective.
A kernel device driver has two salient interfaces: the device or hardware interface, and the kernel or subsystem interface.

So far you have only (crudely) described the device or hardware interface. The Linux kernel has many software layers, and uses hardware abstraction or encapsulation for HW portability and/or HW substitution. So accesses to device registers will utilize macros or (primitive) functions rather than explicit assignment statements. The control bits and fields of device registers will be referenced by macros/mnemonics rather than numeric values in the source code.

The other salient interface of a Linux device driver is its flip side, for the the kernel or subsystem interface. The structure or capabilities of the driver will depend on where the driver fits in the kernel framework. The layered implementation of the kernel divides it into subsystems, and each subsystem can have its own framework. The capabilities a driver exposes (to its higher layer) is (typically) through ops vectors, rather than exporting its function names.

A video encoder would be part of the Video4Linux subsystem. Refer to this (old) presentation for basic concepts and resources: https://events.static.linuxfound.org...012_debski.pdf

Note that code submitted for inclusion in the mainline kernel source must adhere to the kernel coding style. Suggest that you use kernel coding style from the start, rather than make a mess and try to clean up later.

Regards

Good points.

The funny thing here is that he won't want to say what he has on his mind, because it's 'top secret.' But if his 'top secret' ideas work, he'll still have to ram it down somebody's throat to sell it.