drivers/video/fbdev/valkyriefb.h
Source file repositories/reference/linux-study-clean/drivers/video/fbdev/valkyriefb.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/video/fbdev/valkyriefb.h- Extension
.h- Size
- 5297 bytes
- Lines
- 197
- Domain
- Driver Families
- Bucket
- drivers/video
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
struct cmap_regsstruct vpregstruct valkyrie_regsstruct valkyrie_regvals
Annotated Snippet
struct cmap_regs {
unsigned char addr;
char pad1[VALKYRIE_REG_PADSIZE];
unsigned char lut;
};
/*
* Structure of the registers for the "valkyrie" display adaptor.
*/
struct vpreg { /* padded register */
unsigned char r;
char pad[VALKYRIE_REG_PADSIZE];
};
struct valkyrie_regs {
struct vpreg mode;
struct vpreg depth;
struct vpreg status;
struct vpreg reg3;
struct vpreg intr;
struct vpreg reg5;
struct vpreg intr_enb;
struct vpreg msense;
};
/*
* Register initialization tables for the valkyrie display.
*
* Dot clock rate is
* 3.9064MHz * 2**clock_params[2] * clock_params[1] / clock_params[0].
*/
struct valkyrie_regvals {
unsigned char mode;
unsigned char clock_params[3];
int pitch[2]; /* bytes/line, indexed by color_mode */
int hres;
int vres;
};
#ifndef CONFIG_MAC
/* Register values for 1024x768, 75Hz mode (17) */
/* I'm not sure which mode this is (16 or 17), so I'm defining it as 17,
* since the equivalent mode in controlfb (which I adapted this from) is
* also 17. Just because MacOS can't do this on Valkyrie doesn't mean we
* can't! :)
*
* I was going to use 12, 31, 3, which I found by myself, but instead I'm
* using 11, 28, 3 like controlfb, for consistency's sake.
*/
static struct valkyrie_regvals valkyrie_reg_init_17 = {
15,
{ 11, 28, 3 }, /* pixel clock = 79.55MHz for V=74.50Hz */
{ 1024, 0 },
1024, 768
};
/* Register values for 1024x768, 72Hz mode (15) */
/* This used to be 12, 30, 3 for pixel clock = 78.12MHz for V=72.12Hz, but
* that didn't match MacOS in the same video mode on this chip, and it also
* caused the 15" Apple Studio Display to not work in this mode. While this
* mode still doesn't match MacOS exactly (as far as I can tell), it's a lot
* closer now, and it works with the Apple Studio Display.
*
* Yes, even though MacOS calls it "72Hz", in reality it's about 70Hz.
*/
static struct valkyrie_regvals valkyrie_reg_init_15 = {
15,
{ 12, 29, 3 }, /* pixel clock = 75.52MHz for V=69.71Hz? */
/* I interpolated the V=69.71 from the vmode 14 and old 15
* numbers. Is this result correct?
*/
{ 1024, 0 },
1024, 768
};
/* Register values for 1024x768, 60Hz mode (14) */
static struct valkyrie_regvals valkyrie_reg_init_14 = {
14,
{ 15, 31, 3 }, /* pixel clock = 64.58MHz for V=59.62Hz */
{ 1024, 0 },
1024, 768
};
#endif /* !defined CONFIG_MAC */
/* Register values for 832x624, 75Hz mode (13) */
static struct valkyrie_regvals valkyrie_reg_init_13 = {
9,
Annotation
- Detected declarations: `struct cmap_regs`, `struct vpreg`, `struct valkyrie_regs`, `struct valkyrie_regvals`.
- Atlas domain: Driver Families / drivers/video.
- 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.