ssdfb: add missing break in switch. Unbreaks contrast setting for SSD1353

spotted by hannken@

Merge thorpej-cfargs2.

conditionally put back the include of <uvm/uvm_page.h>

This is a kludge to fix the build on some ports. According to pmap(9),
including <uvm/uvm_extern.h> should be sufficient to use
"bool pmap_is_m

conditionally put back the include of <uvm/uvm_page.h>

This is a kludge to fix the build on some ports. According to pmap(9),
including <uvm/uvm_extern.h> should be sufficient to use
"bool pmap_is_modified(struct vm_page *pg)". However, on several ports,
the function is implemented as a macro and depends on implementation
details of "struct vm_page *", which is normally an incomplete forward
declaration only. XXX revert when all ports are fixed.

show more ...

ssdfb: revert rev 1.14

Can't run the worker thread MPSAFE with spi(4) yet because most controller
drivers still lack MP safety. Cause issues when using multiple displays.

ssdfb: support the SSD1353 controller and the DEP 160128A(1)-RGB display

DEP 160128A is a 160x128 18-bit RGB OLED display module advertised as
having an 8-bit parallel I/O interface. The controller

ssdfb: support the SSD1353 controller and the DEP 160128A(1)-RGB display

DEP 160128A is a 160x128 18-bit RGB OLED display module advertised as
having an 8-bit parallel I/O interface. The controller can however attach
serially via spi(4) by moving jumper resistors J1 and J2 to GND position.

show more ...

ssdfb: prepare for supporting rgb color displays

ssdfb: make it work on big-endian

ssdfb: define SSD1353 command set

also adjust some SSD1322 command names

ssdfb(4): remove code for dealing with non-MPSAFE attachment

spi(4) was marked MPSAFE some time ago, so we're always on an
MPSAFE parent device.

Merge thorpej-cfargs branch:

Simplify and make extensible the config_search() / config_found() /
config_attach() interfaces: rather than having different variants for
which arguments you want pass a

Merge thorpej-cfargs branch:

Simplify and make extensible the config_search() / config_found() /
config_attach() interfaces: rather than having different variants for
which arguments you want pass along, just have a single call that
takes a variadic list of tag-value arguments.

Adjust all call sites:
- Simplify wherever possible; don't pass along arguments that aren't
actually needed.
- Don't be explicit about what interface attribute is attaching if
the device only has one. (More simplification.)
- Add a config_probe() function to be used in indirect configuiration
situations, making is visibly easier to see when indirect config is
in play, and allowing for future change in semantics. (As of now,
this is just a wrapper around config_match(), but that is an
implementation detail.)

Remove unnecessary or redundant interface attributes where they're not
needed.

There are currently 5 "cfargs" defined:
- CFARG_SUBMATCH (submatch function for direct config)
- CFARG_SEARCH (search function for indirect config)
- CFARG_IATTR (interface attribte)
- CFARG_LOCATORS (locators array)
- CFARG_DEVHANDLE (devhandle_t - wraps OFW, ACPI, etc. handles)

...and a sentinel value CFARG_EOL.

Add some extra sanity checking to ensure that interface attributes
aren't ambiguous.

Use CFARG_DEVHANDLE in MI FDT, OFW, and ACPI code, and macppc and shark
ports to associate those device handles with device_t instance. This
will trickle trough to more places over time (need back-end for pre-OFW
Sun OBP; any others?).

show more ...

Round of uvm.h cleanup.

The poorly named uvm.h is generally supposed to be for uvm-internal
users only.

- Narrow it to files that actually need it -- mostly files that need
to query whether curlw

Round of uvm.h cleanup.

The poorly named uvm.h is generally supposed to be for uvm-internal
users only.

- Narrow it to files that actually need it -- mostly files that need
to query whether curlwp is the pagedaemon, which should maybe be
exposed by an external header.

- Use uvm_extern.h where feasible and uvm_*.h for things not exposed
by it. We should split up uvm_extern.h but this will serve for now
to reduce the uvm.h dependencies.

- Use uvm_stat.h and #ifdef UVMHIST uvm.h for files that use
UVMHIST(ubchist), since ubchist is declared in uvm.h but the
reference evaporates if UVMHIST is not defined, so we reduce header
file dependencies.

- Make uvm_device.h and uvm_swap.h independently includable while
here.

ok chs@

show more ...

UVM locking changes, proposed on tech-kern:

- Change the lock on uvm_object, vm_amap and vm_anon to be a RW lock.
- Break v_interlock and vmobjlock apart. v_interlock remains a mutex.
- Do partial

UVM locking changes, proposed on tech-kern:

- Change the lock on uvm_object, vm_amap and vm_anon to be a RW lock.
- Break v_interlock and vmobjlock apart. v_interlock remains a mutex.
- Do partial PV list locking in the x86 pmap. Others to follow later.

show more ...

fix hang when SSDFB_ATTACH_FLAG_CONSOLE used with spi

ssdfb: add support for SSD1322

allow to have a per-product init function

use __SHIFTIN

add missing kthread_exit

revert previous as suggested by mrg IPL_SCHED is correct here

- include uvm.h before uvm_device.h
- don't need IPL_SCHED here

ensure the device's UVM pager object is present before using uvm_pageratop

formatting

add ssdfb

The ssdfb driver provides wsdisplay(4) support for OLED/PLED framebuffer
modules based on one of the following controller chips:

- Solomon Systech Ltd SSD1306
- Sino Wealth Electronic Ltd

add ssdfb

The ssdfb driver provides wsdisplay(4) support for OLED/PLED framebuffer
modules based on one of the following controller chips:

- Solomon Systech Ltd SSD1306
- Sino Wealth Electronic Ltd SH1106

It supports xf86-video-wsfb and can optionally attach as the console.

Some products that should work with this driver include:
- Adafruit 0.96" 128x64 OLED graphic display
- Adafruit 1.3" 128x64 OLED graphic display
- Adafruit 128x32 OLED graphic display
- Adafruit PiOLED 128x32 Monochome OLED for Raspberry Pi
- "GM009605" commonly distributed with Arduino starter kits
- display modules made by Chengdu Heltec Automation technology co. LTD

Note: I used the name ssdfb(4) because that's what OpenBSD calls their
driver but the implementation is entirely unique to NetBSD.

show more ...