As the title: Since which version did Linux kernel start to support V4L2 subdev model?
I am trying to look for some similar camera driver to start with, for developing our OV9282 camera driver. Since different Linux kernels have different driver models, we need to know it in advance.
In addition, who can tell me what's the difference between soc-camera (such as kernel/drivers/media/i2c/soc-camera/*.c) and non-soc-camera drivers (such as kernel/drivers/media/i2c/*.c)
Short answer
Using a few git log on random files, it looks like it was included un v3.6-rc1-292-g5bc3cb7.
More detailed answer
First, find v4l2 related files: find -name v4l2\*
Pick some of them, and find out when they were introduced, using git log.
Finally, use git describe with the commit ID to get the tag you're looking for.
✔ ~/src/linux $ git --no-pager log --pretty=oneline --reverse ./include/media/v4l2-clk.h
ff5430de70e8137daccecfa1211509f95fcc8d25 [media] V4L2: add temporary clock helpers
cf326dfebe612bf56c83d8fca7a7c1d1584c061f [media] V4L2: add v4l2-clock helpers to register and unregister a fixed-rate clock
774cc4c289152bfb77806ccae722a9ae2d29dd02 [media] V4L2: add a v4l2-clk helper macro to produce an I2C device ID
a37462b919e1368ea3cf4bb0cbdb00ca8e76959c [media] V4L: remove clock name from v4l2_clk API
4f528afcfbcac540c8690b41307cac5c22088ff1 [media] V4L: add CCF support to the v4l2_clk API
ac2841f3b80170415b63ae5ca8ea417f65244604 [media] v4l2-clk: add new macro for v4l2_clk_name_of()
3d83078a081a2bac7639d09404d85085368c8b66 [media] v4l2-clk: add new definition: V4L2_CLK_NAME_SIZE
68d9c47b1679ec8d55a005d39fc7a958ece82095 media: Convert to using %pOF instead of full_name
✔ ~/src/linux $ git describe ff5430de70e8137daccecfa1211509f95fcc8d25
v3.10-rc6-391-gff5430d
Any improvement for that solution is welcome!
Footnote: I couldn't manage to use git only commands to extract the first commit, in reversed order, see this question.
Related
I compiled BPF example from samples/bpf/pare_simple.c (from the Linux kernel tree) with very simple change:
SEC("simple")
int handle_ingress(struct __sk_buff *skb)
{
return TC_ACT_SHOT;
}
So I want ANY packets to be dropped. I install it as follows:
This happens on Ubuntu 16.04.3 LTS with kernel 4.4.0-98, llvm and clang of version 3.8 installed from packages, iproute2 is the latest from github.
$ tc qdisc add dev eth0 clsact
$ tc filter add dev eth0 ingress bpf \
object-file ./net-next.git/samples/bpf/parse_simple.o \
section simple verbose
Prog section 'simple' loaded (5)!
- Type: 3
- Instructions: 2 (0 over limit)
- License: GPL
Verifier analysis:
0: (b7) r0 = 2
1: (95) exit
processed 2 insns, stack depth 0
So it seems it installs successfully, however this filter/ebpf does not drop packets, I generate ingress traffic on eth0 interface, e.g. ICMP, and it passes on. What am I doing wrong?
TL;DR: You should add direct-action flag to the tc filter command, as in
tc filter add dev eth0 ingress bpf \
object-file ./net-next.git/samples/bpf/parse_simple.o \
section simple direct-action verbose
^^^^^^^^^^^^^
The short help for tc bpf filter bpf help mentions this flag, but is has not made its way to the tc-bpf(8) manual page at this time, if I remember correctly.
So, what is this flag for?
eBPF programs can be attached two ways with tc: as actions, or as classifiers. Classifiers, attached with tc filter add, are supposed to be used for filtering packets, and do not apply an action by default. Which means that their return values have the following meaning (from man tc-bpf):
0 , denotes a mismatch
-1 , denotes the default classid configured from the command line
else , everything else will override the default classid to provide a facility for non-linear matching
Actions attached with tc action add, on the other hand, can drop or mirror or perform other operations with packets, but they are not supposed to actually filter them.
Because eBPF is kind of more flexible than the traditional actions and filters of tc, you can actually do both at once, filter a packet (i.e. identify this packet) and perform an action on it. To reflect this flexibility, the direct-action, or da flag was added (for kernel 4.4 or newer, with matching iproute2 package). It tells the kernel to use the return values of actions (TC_ACT_SHOT, TC_ACT_OK, etc.) for classifiers. And this is what you need here to return TC_ACT_SHOT in a way the kernel understands you want to drop the packet.
If I remember correctly, the reason why we use this flag instead of just dropping filters for actions is that you need a filter anyway with tc to attach you action to? (to be confirmed). So with the direct-action flag you do not have to attach both one filter and one action, the filter can do both operations. This should be the preferred way to go for eBPF programming with tc.
I've looked through all of the spec code tables and can't find any way of detecting if the A turret has an M spindle.
To check for milling spindle on A turret (active tooling), look for NC spec "MULTIPLE MACHINE" / "CCM" No.3, bit 0. You can accomplish this using the SCOUT library by doing the following:
bool MSpindle = Okuma.Scout.SpecCode.NC.Bit(Okuma.Scout.Enums.NCSpecGroup.NC1MG, 3, 0);
Alternatively, you can use the GetMSpindleState() THINC API function in the CMSpindle Class of the Lathe Data API. It will throw a NotSupportedException if the MULTIPLE MACHINE spec is not active.
To check manually, open the file OSPMNGCD.CNC in the C:\OSP-P\ directory of the machine. Scroll down to the NC-SPEC CODE No.1 section and look for the MULTIPLE MACHINE spec. Use the following image as a guide to find the spec:
struct net_device has no member named pm_qos_req.
Where can I find the relevant API structure?
SHORT ANSWER
pm_qos_req field in struct net_device was using only for e1000e driver, therefore it was decided to move this field to e1000e driver structure, so that rest of drivers that use struct net_device will not waste a few bytes of memory when allocating struct net_device. See e2c6544829 commit for details.
If you are developing e1000e driver and having issues, you can back-port e2c6544829 commit to your kernel baseline.
Otherwise, if you are maintaining some driver which is not upstreamed and is using pm_qos_req, use e2c6544829 commit as reference to rework your driver. Basically you need to add pm_qos_req field to your driver struct and use it from that struct instead of struct net_device.
THE WHOLE INVESTIGATION
Here is how you can figure this out:
Download mainline kernel:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Checkout to corresponding tag (well, in your case you can skip this step):
$ git checkout v4.1-rc3
(v4.1-rc3 is a tag; all tags can be listed by git tag command)
Search for pm_qos_req text changed in include/linux/netdevice.h file, using git:
$ git log -S'pm_qos_req' --oneline -- include/linux/netdevice.h
It will give you next commits:
01d460d net: Remove remaining remnants of pm_qos from netdevice.h
e2c6544 e1000e: Move pm_qos_req to e1000e adapter
536721b net: kernel-doc compliant documentation for net_device
ed77134 PM QOS update
Top commit in that list is the last one (was added most recently).
Check out interested commits with git show command. You are particularly interested in e2c6544 commit (it's where .pm_qos_req was removed from struct net_device):
$ git show e2c6544
Pay attention to commit message:
e1000e is the only driver requiring pm_qos_req, instead of causing
every device to waste up to 240 bytes. Allocate it for the specific
driver.
Now we can checkout to previous kernel versions and check which drivers are using this pm_qos_req field.
$ git grep -n '\bpm_qos_req\b' v3.0 -- drivers/
From grep output we can see that only e1000e driver is using this field.
I would like to know if there is any documentation for the linux kernel regulator framework with device tree. I am totally lost with consumer name and lists. I need to add consumers from device tree but I cant see consumer list at all in the device tree files.
I am using AM335x based custom board based on TI sitara.
By reading both documentation (DeviceTree and Regulator) you should be able to find what you want. But as usual the best documentation is the code itself. The driver ti-abb-regulator is using the DeviceTree and the Regulator framework.
In addition, Federico has already said, there are so-called MFD(MultiFunction) devices. These are often referred PMIC(Power Management IC) that are used in conjunction with a SOC from TI. For AM335x it maybe TPS65217, TPS65910A, TPS65910x, TPS650250, etc. If so, that means some of them you can find follow this link: MFD.
I was just looking into this myself, and my conclusion is that the setup in device tree is pretty different from the way it's done in the board file.
What you'll need to do is to add your drivers to the device tree as well, and then use the "[name]-supply" notation, e.g.:
cpus {
cpu0 {
cpu0-supply = <&omap_tps65912_dcdc1>;
};
};
If you look for this in other board files, you'll see how it works.
I am having troubles with gpio interrupt issue.
According documentation for ep93xx ports A, B, F can be configured to generate interrupts.
quote:
Any of the 19 GPIO lines maybe configured to generate interrupts
However arch/arm/march-ep93xx/gpio.c is handling only interrupts from port A. And doesn't react to port B and F.
static void ep93xx_gpio_ab_irq_handler(unsigned int irq, struct irq_desc *desc)
{
unsigned char status;
int i;
printk(KERN_INFO "ep93xx_gpio_ab_irq_handler: irq=%u", irq);
I know printk is terrible in irq_handlers.
I am configuring iterrupts via sysfs.
GPIO 0,8 are wired with Port F if it is important to issue.
Also when enabling interrupts on port B without having configured port A i get following warning:
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:103 gpio_ensure_requested+0x54/0x118()
autorequest GPIO-1
Modules linked in:
[<c002696c>] (unwind_backtrace+0x0/0xf0) from [<c00399d4>] (warn_slowpath_fmt+0x54/0x78)
[<c00399d4>] (warn_slowpath_fmt+0x54/0x78) from [<c019dd90>] (gpio_ensure_requested+0x54/0x118)
[<c019dd90>] (gpio_ensure_requested+0x54/0x118) from [<c019e05c>] (gpio_direction_input+0xb0/0x150)
[<c019e05c>] (gpio_direction_input+0xb0/0x150) from [<c002c9a8>] (ep93xx_gpio_irq_type+0x3c/0x1d8)
[<c002c9a8>] (ep93xx_gpio_irq_type+0x3c/0x1d8) from [<c0066ad8>] (__irq_set_trigger+0x38/0x9c)
[<c0066ad8>] (__irq_set_trigger+0x38/0x9c) from [<c0066e14>] (__setup_irq+0x2d8/0x354)
[<c0066e14>] (__setup_irq+0x2d8/0x354) from [<c0066f38>] (request_threaded_irq+0xa8/0x140)
[<c0066f38>] (request_threaded_irq+0xa8/0x140) from [<c019e784>] (gpio_setup_irq+0x14c/0x260)
[<c019e784>] (gpio_setup_irq+0x14c/0x260) from [<c019ec1c>] (gpio_edge_store+0x90/0xac)
[<c019ec1c>] (gpio_edge_store+0x90/0xac) from [<c01be8fc>] (dev_attr_store+0x1c/0x28)
[<c01be8fc>] (dev_attr_store+0x1c/0x28) from [<c00e8b2c>] (sysfs_write_file+0x168/0x19c)
[<c00e8b2c>] (sysfs_write_file+0x168/0x19c) from [<c009a3d4>] (vfs_write+0xa4/0x160)
[<c009a3d4>] (vfs_write+0xa4/0x160) from [<c009a6a4>] (sys_write+0x3c/0x7c)
[<c009a6a4>] (sys_write+0x3c/0x7c) from [<c0020e40>] (ret_fast_syscall+0x0/0x2c)
---[ end trace ff56c09a294dbe68 ]---
I am using kernel version 2.6.34.14 with linux-2.6.34-ts7200_matt-6.tar.gz patch (hovewer it doesn't seem contain patches for gpio.c or gpiolib.c)
cross version:
binutils-2.23.1
gcc-4.7.3
glibc-2.17
Also i crawled through change history of gpio.c and gpiolib.c and didn't find anything that can be related to this issue.
Can someone give me and advice regarding this issue? I want interrupts on all ports (A,B,F) not just A.
There are a lot of question on this issue (and ARM irq OR interrupt). Please look at them.
We can see many changes by looking at more recent Linux 3.0 gpio.c change logs versus the 2.6.34 logs and the current version. You should be able to get the current Linux stable tree and extract these patches and back port them to your kernel. For instance, there is a bug where port C and F are swapped; I don't know if this is in your ts7200_matt variant.
Some important change sets to look at,
arm: Fold irq_set_chip/irq_set_handler
arm: Cleanup the irq namespace
arm: ep93xx: Use proper irq accessor functions
arm: ep93xx: Add basic interrupt info
ARM: ep93xx: irq_data conversion.
ARM: 5954/1: ep93xx: move gpio interrupt support to gpio.c
[ARM] 5243/1: ep93xx: bugfix, GPIO ports C and F are swapped
You may have #6, but it is worth looking at as it is basically the interrupt implementation for your controller. After about linux-3.0, your SOC's GPIO controller was moved to drivers/gpio/gpio-ep93xx.c. You may wish to look at these changes, but none seem to be related to your issue. You should be aware of structural changes to Linux. Ie, overall changes to interrupt handling and/or the generic GPIO infrastructure. A good guess is that Thomas Gleixner or Russell King will make these changes.
The patches can be extracted from a particular Linux stable tree with git format-patch b685004.. b0ec5cf1 gpio.c. This will create several patch files. Move them to your tree and apply with either git am or patch -p1. You may have to massage these files to get them to apply cleanly to your tree; if you take them all, even though they are not related to interrupt handling, you will have better luck doing this automatically. You can also look at the patch set and try to manually patch the file with a text editor.
None of this addresses your specific questions. However, it gives a path to merge changes from the latest Linux versions. Also, the previous stack overflow questions give details on the structure of the GPIO interrupt handling. Coupled with your data sheet, the Linux GPIO document, and the given change sets, you should be able to fix your own problem. Otherwise, you need someone familiar with the EP93xx and the question is fairly localized.
Note: The stack trace indicates that a GPIO is being used without a corresponding gpio_request()
. This is either a bug in the machine file or in the EP93xx GPIO interrupt handling code.
I had the same warning:
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:103 gpio_ensure_requested
From my research we have to call gpio_request_one / gpio_request, before gpio_direction_input.
It fixed the problem for me.
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=99789
http://e2e.ti.com/support/embedded/linux/f/354/p/119946/427889.aspx