About Raspberry Pie Kernel compilation and Driver Authoring (2)

A few days ago, the raspberry Pie 2 of the kernel compile run work, these days focused on the raspberry Pie Gpio operation, then it is time to get it out

We know that the gpio operation is driven by the basic operation, then the study of a board, a version of the kernel, the first to start with the Gpio.

The underlying GPIO operation has the following:

Ioremap maps The register address, Readl reads the value on the register, Writel writes the data to the register.

GPIO action macros provided with the kernel

A new Gpio operation is now in contact: Using the gpio_chip structure, the GPIO function is manipulated with object-oriented thinking.

In the 3.18.16 kernel I use, the gpio operation of the raspberry chip bcm2836 is performed by the bcm2708 Gpio operation of the kernel, presumably with a high similarity of the two.

The driver code found from the Internet is attached.

At the beginning of the study, look at the chip manual, use its address to address mapping, and then rewrite, the plot is very dog blood, is failure, whether the bus address or physical address, are failures.

The reason is unknown, finally found the following code on the Internet, compiled after the success of the operation, analysis of its use of the gpio_chip structure of the conclusion.

#include <linux/kernel.h>  
#include <linux/module.h>
#include <linux/device.h> &NBSP
#include <mach/platform.h>       
#include <linux/platform_device.h>
#include <linux/types.h>  
#include <linux/fs.h>   
#include <linux/ioctl.h >  
#include <linux/cdev.h>  
#include <linux/delay.h>  
#include <linux/ Uaccess.h>
#include <linux/init.h> 
#include <linux/gpio.h>
 
// class declares kernel module driver information, which is udev capable of automatically generating the appropriate file
static dev_t Pi_led_devno;//device number
static struct class *pi_led_class;
static struct Cdev Pi_led_class_dev;
 
struct gpio_chip *gpiochip;
 
#define Led_pin  //gpio 4
 

static int is_right_chip (struct gpio_chip *chip, void *data)//This function is the Gpiochip_find function call kernel, after which the kernel calls a function to find the gpio_chip structure body
{

if (strcmp (data, chip->label) = = 0)
return 1;
return 0;
}

The initialization function after the kernel is loaded.
static int __init pi_led_init (void)
{
struct device *dev;
int major; Automatic allocation of main device numbers
Major = Alloc_chrdev_region (&pi_led_devno,0,1,driver_name);
Register_chrdev registers the character device to make the system aware that there are LEDs in this module.

Cdev_init (&pi_led_class_dev, &pi_led_dev_fops);
Major = Cdev_add (&pi_led_class_dev,pi_led_devno,1);
Register class
Pi_led_class = Class_create (this_module,driver_name);

dev = device_create (Pi_led_class, null,pi_led_devno,null,driver_name);

Gpiochip = Gpiochip_find ("Bcm2708_gpio", is_right_chip); This function is the function used to find the gpio_chip structure of the Register, which is implemented by the kernel * (1)
Gpiochip->direction_output (Gpiochip, Led_pin, 1);
Gpiochip->set (Gpiochip, Led_pin, 1); * (2)
PRINTK ("PI led init ok!\n");
return 0;
}
The destroy function after the kernel unloads.
void Pi_led_exit (void)
{
Gpiochip->set (gpiochip, Led_pin, 0);
Gpio_free (Led_pin);
Device_destroy (PI_LED_CLASS,PI_LED_DEVNO);
Class_destroy (Pi_led_class);
Cdev_del (&pi_led_class_dev);
Unregister_chrdev_region (Pi_led_devno, 1);
PRINTK ("Pi led exit ok!\n");

}

Module_init (Pi_led_init);
Module_exit (Pi_led_exit);

Module_description ("rasp Led Driver");
Module_author ("52pi.net");
Module_license ("GPL");

* (1) the "Bcm2708_gpio" string is the lable member of the gpio_chip structure to be used, which can be understood as its name, and can be seen after the GPIO structure is found in the bcm2708_ GPIO.C file, but this file has two, respectively in mach-bcm2708 and mach-bcm2709 two folders, a simple look, two files are basically the same, found in the inside:

static void Bcm2708_gpio_set (struct gpio_chip *gc, unsigned offset, int value)

function, this function is the final destination of the function called in * (2), the implementation is still the READL and Writel functions, so that is, these two functions can still be used, I print it to modify, recompile the kernel, the kernel prints the following information

[52.190213] *********ADDR---0xf320001c//actual read and write addresses
[52.195631] *******1****0x6770696f//Read data on registers
[52.200735] *******2****0x6770696f

The chip manual describes the GPIO corresponding register physical address should be 0x2020 001c, bus address 0x7e20 001c

View print information The address is different from two, and the analysis may be the corresponding address of the bcm2708. Or a register address that is mapped by the kernel, which is more likely.

Then the previous use of the address of the Ioremap map can not be used because the exception should be the kernel of its register restrictions, do not allow arbitrary mapping, I have not found the relevant evidence.

So according to 0XF320001C's address rewrite their previous use of READL and Writel implementation of the drive, found this successful, and restart the raspberry pie, this address can also use, then I analyze this

The address is already under the control of the kernel and cannot be remap, or even remap, and cannot be used.

Many friends use the three application layer of the GPIO call to operate it, but this is not kernel-driven, and I analyzed the source code of WIRINGPI, found that it is by calling the MEM driver for address mapping, so as to achieve the purpose of operating registers.

MEM Device node is/dev/mem, the main device number is 1, memory, belongs to the character device, you can through the kernel source major view the main device number 1 macro, and then search this macro, you can find its driver.

Now that I've found an operational address for a GPIO register, I'll also have time to analyze why it is this address, and then I can work on it, possibly write some other driver, but I may not send it again, and the next step is to start studying Uboot, The goal is to be able to start a bootloader command line. Interested friends can add to the concern.