1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/docs/wiki/System_Architecture Sat Apr 13 19:28:39 2019 +0200
1.3 @@ -0,0 +1,103 @@
1.4 += System Architecture =
1.5 +
1.6 +A significant motivation for providing server programs is to isolate
1.7 +device-specific operations within separate components, thus preventing each
1.8 +component from having too broad access to low-level system functionality. The
1.9 +combination of components is then encouraged to achieve configuration
1.10 +objectives.
1.11 +
1.12 +For example, two computing systems that employ the same LCD controller might
1.13 +each employ different screen types and have different ways of controlling
1.14 +display behaviour. By defining explicit mechanisms for combining access to
1.15 +these different aspects of the hardware, common elements (such as the LCD
1.16 +controller) may be encapsulated by a device server that can be reused, with
1.17 +differing elements (such as the screen type) being described by separate
1.18 +resources or components that can be introduced as required.
1.19 +
1.20 +Here is how the Ben NanoNote's framebuffer is supported by components:
1.21 +
1.22 +######## A graph showing the relationship between components.
1.23 +
1.24 +{{{#!graphviz
1.25 +#format svg
1.26 +#transform notugly
1.27 +digraph nanonote_framebuffer {
1.28 + node [shape=rectangle,fontsize="13.0",fontname="Helvetica"];
1.29 +
1.30 + fb_drv [label="fb-drv"];
1.31 + dev_cpm_jz4740 [label="dev_cpm_jz4740\nClock configuration"];
1.32 + dev_display_qi_lb60 [label="dev_display_qi_lb60\nDisplay control"];
1.33 + dev_backlight_spi_ili8960 [label="dev_backlight_spi_ili8960\nBacklight control"];
1.34 + dev_spi_jz4740 [label="dev_spi_jz4740\nBacklight communication"];
1.35 +
1.36 + fb_drv -> dev_cpm_jz4740;
1.37 + fb_drv -> dev_display_qi_lb60 -> dev_backlight_spi_ili8960 -> dev_spi_jz4740;
1.38 +}
1.39 +}}}
1.40 +
1.41 +########
1.42 +
1.43 +And here is how the Letux 400's framebuffer is supported:
1.44 +
1.45 +######## A graph showing the relationship between components.
1.46 +
1.47 +{{{#!graphviz
1.48 +#format svg
1.49 +#transform notugly
1.50 +digraph letux400_framebuffer {
1.51 + node [shape=rectangle,fontsize="13.0",fontname="Helvetica"];
1.52 +
1.53 + fb_drv [label="fb-drv"];
1.54 + dev_cpm_jz4730 [label="dev_cpm_jz4730\nClock configuration"];
1.55 + dev_display_letux400 [label="dev_display_letux400\nDisplay control"];
1.56 + dev_backlight_pwm [label="dev_backlight_pwm\nBacklight control"];
1.57 + dev_pwm_jz4730 [label="dev_pwm_jz4730\nBacklight communication"];
1.58 +
1.59 + fb_drv -> dev_cpm_jz4730;
1.60 + fb_drv -> dev_display_letux400 -> dev_backlight_pwm -> dev_pwm_jz4730;
1.61 +}
1.62 +}}}
1.63 +
1.64 +########
1.65 +
1.66 +Note that fb-drv links to the same generic JZ4740 LCD controller library in
1.67 +both cases
1.68 +
1.69 +Here, the CPM device provides access to the clock and power management
1.70 +functionality, the display device provides access to the backlight and is
1.71 +responsible for configuring pins for the display. Device servers are connected
1.72 +using capabilities (object references).
1.73 +
1.74 +Meanwhile, panel information is provided via a dynamically-loaded library:
1.75 +
1.76 +######## A graph showing the acquisition of panel information.
1.77 +
1.78 +{{{#!graphviz
1.79 +#format svg
1.80 +#transform notugly
1.81 +digraph panel_information {
1.82 + node [shape=rectangle,fontsize="13.0",fontname="Helvetica"];
1.83 +
1.84 + subgraph {
1.85 + rank=min;
1.86 + fb_drv [label="fb-drv"];
1.87 + }
1.88 +
1.89 + paneldata [label="mips-jz4740-panel.txt\nLibrary details"];
1.90 + library [label="...\nLibrary with panel data"];
1.91 +
1.92 + paneldata -> fb_drv -> library;
1.93 +}
1.94 +}}}
1.95 +
1.96 +########
1.97 +
1.98 +This method of obtaining a configured library name in order to load it
1.99 +dynamically is effectively equivalent to having a symbolic link identifying
1.100 +the library referencing the desired, specific library to be used. Since the
1.101 +"rom" virtual filesystem does not appear to support symbolic links, this
1.102 +method is used instead.
1.103 +
1.104 +By providing well-defined interfacing mechanisms, the behaviour of driver code
1.105 +can be parameterised using external components, and a proliferation of
1.106 +specially-constructed device drivers is hopefully avoided.