Sorry for the long description of my problem :-)
I have been handed a task to perform simple reads and writes to/from an I2C device on our new PC based board design. The board will be built using Portwell's Qseven mini PC which uses an Intel Tunnel Creek (ATOM) processor (essentially an x86 processor) and an EG20T IOH chip.
The I2C slave device is a TI AIC3254 audio codec. OS is Ubuntu 10.04 LTS 32 bit.
uname -a
Linux Torchwood 2.6.32-41-generic #88-Ubuntu SMP Thu Mar 29 13:08:43 UTC 2012 i686 GNU/Linux
The PC portion of this device will be essentially a general purpose PC.
The PC/OS needs to load the codec (registers) via I2C at system init. After that the codec will be controlled by an Atmel processor which will be a second master on the I2C bus (remaining silent until init is complete). The ATOM will have no additional direct interaction with the AIC3254.
All that I need to do, as far as I know, is to copy the codec's "program" to it over the I2C bus then read it back (poor man's load check).
It seems the logical approach is to use a userspace program to talk to the AIC3254 rather than try to create a device driver. However, after I modprobe i2c-dev; depmod -a no I2C bus appears in /dev and i2cdetect from i2c_tools finds no buses (devices?).
What I need is some understanding of Linux I2C access coding. Complete noob here.
Do I need a device driver after all? I don't need any fancy interface for general programs too use, just one simple read/write to bus/page/register. Perhaps a simple char mode driver? I've read something that suggests such things exist.
Do I need to put a *new_device* and *delete_device* file in /sys/bus/i2c/devices/i2c-0/?
Even with i2c-dev.ko installed no i2c-x "file" appears in /sys/bus/i2c/devices/ What am I missing here?
Can I assume or find out if this kernel knows about EG20T IOH chips? Or are these chips generic enough that i2c-dev can deal with them?
Will I need i2c-core.ko? It isn't found on the Ubuntu image. What do I need to apt-get to have it if I need it?
Do I have any use for the i2c-algo_???.ko's?
Sorry to be such a noob. Thanks for any help.
I think you need to add i2c support in your board support file when you build the kernel for the target. We use an Atmel based board to do i2c, and during kernel init, it calls i2c_register_board_info() to register the i2c devices. Then you can access them using i2c-tools, and userspace apps. Note we are using 3.2.6 kernel, but similar calls are likely needed for 2.6 kernels
Related
Helo All,
I am trying to learn embedded linux.
Please provide clarity on below:
As DTB provides Board and SOC related information will it be sufficient to make sure correct drivers will be enabled?
How a correct driver will get selected and will it happen during build time or kernel runtime based on the DTB?
How are drivers for platform devices(UART, SPI, I2C etc) handled in Linux? I mean as different SOC's have different implementations(register and bit fields will be different) of these peripherals how a single driver will be able to handle both SOC's?
Is it sufficient to have well defined DTB about board and kernel to make Linux up and running on any platform.
Thanks,
Suraj
I am new to linux kernel debugging. I have a radeon graphics card and I am doing some graphics driver development for my embedded system. Before making a custom driver for another radeon card, I want to know how the graphics driver behaves in linux. I have studied a bit on DRM, GEM/TTM, KMS, Framebuffers; but I want to see them actually happening on linux systems. I have Ubuntu system with kernel 3.10.x
I want to debug the driver and see the following. Please help how to do it.
How to access framebuffer and see what is currently being drawn. (This is more of a curiosity)
Wish to see how TTM and GART tables are maintained and interpret them(any link would also help) and KMS as my display is DVI-D
How DMA is playing role here. Can I begin without DMA (over PCI for time being etc..)
Minimal device driver requirement to draw some raw pixels on screen
Unlike linux, devices in my embedded system are not treated as files. So need to understand them and reinterpret them for my system.
Plan is to make Mesa over it. Just I am in the beginning stage. So any help would be appreciated.
Thanks
Background:
I am developing a tool which boots up a custom build of Linux and boots into QT based desktop for x86 based machine. My custom Linux runs from USB and when the it boots on a machine with certain brand of sound cards connected, then my tool runs to a live lock situation with a lot of interrupts. I doubt its some problem with APIC driver but the system is renderd useless and I have to poweroff the system.
My Question:
I would like to simulate the same situation by using a kernel driver or module. I am not sure if I can cause an interrupt to fire from a module. I have a experience with I2C or SPI which causes interrupts on ARM based Linux boards. But i dont know how to do it from a module
Could anybody please suggest me how to cause an interrupt from a driver?
Just create a module with an interrupt forkbomb in it. Google it. It'll only take a second for your vm to halt.
http://www.tldp.org/LDP/tlk/dd/interrupts.html
I have been studying linux driver recently,
as those articles I read said, the device driver modules are likely to be automatically loaded on demand by kernel, I am therefore wondering about the recipe how kernel figures out which module to load for a specific device(sound card, I2C/spi device, etc), I also cannot thoroughly imagine how the kernel detects each hardware device while boot-time .
answers relevant to embedded linux are prefered , PC linux are also welcome !
3Q
I think you are mixing two different things, which is hardware detection, and on demand module loading.
In some cases, the kernel is explicitely doing a module request. However, in most cases, the kernel itself does not do any "on demand loading".
But wait, you must be mistaken, if I plug my shiny new webcam, isn't
the module automagically loaded ?
Yes it is, but not by the kernel. All the kernel does is calling a userspace program with so called "hotplug event" or "uevent" as arguments. On Linux PC, this userspace program is usually udev, but on embedded system, you can use for example mdev. You can find a more detailed explanation here and here
Regarding the second part of your question, the kernel is doing hardware discovery only if the hardware is discoverable. Example of discoverable hardware is USB and PCI. Example of non discoverable harwdare busses is SPI or I2C.
In the latter cases, the presence of a particular device on a given bus is either encoded directly in the kernel, or given to him by the booloader. Google for "device tree" for an example of the latter.
To sum things up : Hardware detection is done by the kernel, and module loading is done by userspace, with information provided by the kernel.
I'm looking for either a kernel mode call that I can make from a driver, a userland utility, or a system call that will ask the Kernel to look at the PCI bus and either completely re-run its initialization, or initialize a specific device. Specifically, I need the Kernel to recognize a device that was added to the bus after boot and then configure its address space, interrupt, and other configuration parameters, and finally enable the device so that I can load the driver for it (unless this all happens as part of the driver load).
I'm stuck on the 2.4.x series Kernel for this, and am currently working with 2.4.20, but will be moving to 2.4.37 if it matters. The distro is a stripped down Red Hat 7.3 running in a ram disk, but I can add in whatever tools are needed to get this working (as long as they play nice with 2.4 series).
If some background would help clarify what I'm trying to do: From a cold boot, once in Linux I use GPIO to program an FPGA. Part of the FPGA, once programmed, implements a simple PCI device. Currently, after programming the FPGA, I reboot the system and Linux recognizes the device after coming up and loads the driver for it.
Instead of needing that reboot, I'd like to simply ask the Kernel to do whatever it does during boot up to find PCI devices (I have the Kernel configured to find PCI devices on its own, instead of asking the BIOS for that information, so the BIOS won't need to know about this device (I hope)).
I believe that Linux is capable of seeing the device after it is programmed but before a reboot, because scanpci will show the device after I program it, as will lspci -H 1. I just need a way to get it into /proc/pci, configured and enabled.
This below command will help the user to rescan it complete root hub.
echo "1" > /sys/class/pci_bus/0000\:00/rescan
You could speed up the reboot with kexec, if you don't figure out how to get the PCI scan redone. You could ask this on the LKML, if you haven't already.
unloading/reloading the module doesn't help, does it?
http://www.linuxjournal.com/article/5633 suggests you should be able to do it with 2.4 kernels using pcihpfs.
If that isn't working, maybe the driver doesn't support hotplug?
It would probably crash the system if you reconfigured the addresses of other PCI devices while they are in use.
A better way would be to just configure the new card. If your kernel has support for Cardus devices, it already knows how to configure a newly-inserted PCI device (which is what Cardbus is). You just need to figure out how to get the kernel to do it...
It should be possible for a kernel module to do this. Even if you can't get built-in hotplug code, you should be able to set the pci resources using calls to pci_bus_write_config_dword() and friends. There is probably some IRQ routing setup to do as well.