arch/arm/mach-omap1/board-osk.c
Source file repositories/reference/linux-study-clean/arch/arm/mach-omap1/board-osk.c
File Facts
- System
- Linux kernel
- Corpus path
arch/arm/mach-omap1/board-osk.c- Extension
.c- Size
- 12694 bytes
- Lines
- 455
- Domain
- Architecture Layer
- Bucket
- arch/arm
- Inferred role
- Architecture Layer: implementation source
- Status
- source implementation candidate
Why This File Exists
CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/gpio/consumer.hlinux/gpio/driver.hlinux/gpio/machine.hlinux/kernel.hlinux/init.hlinux/platform_device.hlinux/interrupt.hlinux/irq.hlinux/i2c.hlinux/leds.hlinux/smc91x.hlinux/omapfb.hlinux/mtd/mtd.hlinux/mtd/partitions.hlinux/mtd/physmap.hlinux/mfd/tps65010.hlinux/platform_data/gpio-omap.hlinux/platform_data/omap1_bl.hlinux/soc/ti/omap1-io.hasm/mach-types.hasm/mach/arch.hasm/mach/map.htc.hflash.hmux.hhardware.husb.hcommon.h
Detected Declarations
function osk_tps_setupfunction osk_tps_teardownfunction osk_init_smc91xfunction osk_init_cffunction osk_init
Annotated Snippet
#include <linux/gpio/consumer.h>
#include <linux/gpio/driver.h>
#include <linux/gpio/machine.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/i2c.h>
#include <linux/leds.h>
#include <linux/smc91x.h>
#include <linux/omapfb.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/physmap.h>
#include <linux/mfd/tps65010.h>
#include <linux/platform_data/gpio-omap.h>
#include <linux/platform_data/omap1_bl.h>
#include <linux/soc/ti/omap1-io.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include "tc.h"
#include "flash.h"
#include "mux.h"
#include "hardware.h"
#include "usb.h"
#include "common.h"
/* Name of the GPIO chip used by the OMAP for GPIOs 0..15 */
#define OMAP_GPIO_LABEL "gpio-0-15"
/* At OMAP5912 OSK the Ethernet is directly connected to CS1 */
#define OMAP_OSK_ETHR_START 0x04800300
/* TPS65010 has four GPIOs. nPG and LED2 can be treated like GPIOs with
* alternate pin configurations for hardware-controlled blinking.
*/
#define OSK_TPS_GPIO_USB_PWR_EN 0
#define OSK_TPS_GPIO_LED_D3 1
#define OSK_TPS_GPIO_LAN_RESET 2
#define OSK_TPS_GPIO_DSP_PWR_EN 3
#define OSK_TPS_GPIO_LED_D9 4
#define OSK_TPS_GPIO_LED_D2 5
static struct mtd_partition osk_partitions[] = {
/* bootloader (U-Boot, etc) in first sector */
{
.name = "bootloader",
.offset = 0,
.size = SZ_128K,
.mask_flags = MTD_WRITEABLE, /* force read-only */
},
/* bootloader params in the next sector */
{
.name = "params",
.offset = MTDPART_OFS_APPEND,
.size = SZ_128K,
.mask_flags = 0,
}, {
.name = "kernel",
.offset = MTDPART_OFS_APPEND,
.size = SZ_2M,
.mask_flags = 0
}, {
.name = "filesystem",
.offset = MTDPART_OFS_APPEND,
.size = MTDPART_SIZ_FULL,
.mask_flags = 0
}
};
static struct physmap_flash_data osk_flash_data = {
.width = 2,
.set_vpp = omap1_set_vpp,
.parts = osk_partitions,
.nr_parts = ARRAY_SIZE(osk_partitions),
};
static struct resource osk_flash_resource = {
/* this is on CS3, wherever it's mapped */
.flags = IORESOURCE_MEM,
};
static struct platform_device osk5912_flash_device = {
.name = "physmap-flash",
.id = 0,
.dev = {
Annotation
- Immediate include surface: `linux/gpio/consumer.h`, `linux/gpio/driver.h`, `linux/gpio/machine.h`, `linux/kernel.h`, `linux/init.h`, `linux/platform_device.h`, `linux/interrupt.h`, `linux/irq.h`.
- Detected declarations: `function osk_tps_setup`, `function osk_tps_teardown`, `function osk_init_smc91x`, `function osk_init_cf`, `function osk_init`.
- Atlas domain: Architecture Layer / arch/arm.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.