@@ -414,7 +414,33 @@ to get the driver-private data allocated for that device.
414
414
The driver will initialize the fields of that spi_master, including the
415
415
bus number (maybe the same as the platform device ID) and three methods
416
416
used to interact with the SPI core and SPI protocol drivers. It will
417
- also initialize its own internal state.
417
+ also initialize its own internal state. (See below about bus numbering
418
+ and those methods.)
419
+
420
+ After you initialize the spi_master, then use spi_register_master() to
421
+ publish it to the rest of the system. At that time, device nodes for
422
+ the controller and any predeclared spi devices will be made available,
423
+ and the driver model core will take care of binding them to drivers.
424
+
425
+ If you need to remove your SPI controller driver, spi_unregister_master()
426
+ will reverse the effect of spi_register_master().
427
+
428
+
429
+ BUS NUMBERING
430
+
431
+ Bus numbering is important, since that's how Linux identifies a given
432
+ SPI bus (shared SCK, MOSI, MISO). Valid bus numbers start at zero. On
433
+ SOC systems, the bus numbers should match the numbers defined by the chip
434
+ manufacturer. For example, hardware controller SPI2 would be bus number 2,
435
+ and spi_board_info for devices connected to it would use that number.
436
+
437
+ If you don't have such hardware-assigned bus number, and for some reason
438
+ you can't just assign them, then provide a negative bus number. That will
439
+ then be replaced by a dynamically assigned number. You'd then need to treat
440
+ this as a non-static configuration (see above).
441
+
442
+
443
+ SPI MASTER METHODS
418
444
419
445
master->setup(struct spi_device *spi)
420
446
This sets up the device clock rate, SPI mode, and word sizes.
@@ -431,6 +457,9 @@ also initialize its own internal state.
431
457
state it dynamically associates with that device. If you do that,
432
458
be sure to provide the cleanup() method to free that state.
433
459
460
+
461
+ SPI MESSAGE QUEUE
462
+
434
463
The bulk of the driver will be managing the I/O queue fed by transfer().
435
464
436
465
That queue could be purely conceptual. For example, a driver used only
@@ -440,6 +469,9 @@ But the queue will probably be very real, using message->queue, PIO,
440
469
often DMA (especially if the root filesystem is in SPI flash), and
441
470
execution contexts like IRQ handlers, tasklets, or workqueues (such
442
471
as keventd). Your driver can be as fancy, or as simple, as you need.
472
+ Such a transfer() method would normally just add the message to a
473
+ queue, and then start some asynchronous transfer engine (unless it's
474
+ already running).
443
475
444
476
445
477
THANKS TO
0 commit comments