diff mode works best with dclk 33.33 MHz using cpll_333m 33.33
MHz. The remaining modes work best at 8 * 33.33 MHz = 266.67 Mhz. By
default 200 MHz can be obtained by using gpll_200m as parent at 200
MHz. Alternatively cpll_333m can be used at 250 MHz, resulting in a
noticable speedup.
This allows the panel to be run at the recommended 33.33 MHz sclk,
decreasing frame processing times by a bit more than a ms. This only
works in direct mode by setting EBC_DSP_CTRL_DSP_SDCLK_DIV to 0. This
behaviour is not documented in the Rockchip RK3568 TRM, but is used by
the Lenovo Smart Paper.
LUT mode and 3WIN mode are not compatible with this setting and need
to be run at sclk 25 MHz (dclk 200 MHz, clock divider of
8). Previously 31.25 MHz were supported by setting dclk to 250 MHz,
which resulted in CPLL_333M to be set to 250 MHz.
* define dma-names for uart1 (tx, rx)
* fix bluetooth dts entry (as suggested by user hrdl and from the q64a
dts)
Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
While still chasing various artifacts, it seems that limiting the
max-brightness of the chip to 125, AND limiting the current to below 20
mA, yields robust results.
LOW to EDGE_FALLING.
My notes:
- I think the interrupt should indeed be FALLING EDGE, and the level low
interrupt type documented here:
63355b9884/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml (L86)
is a remnant from the android cyttsp5 driver, which in turn is a remnant
of the android cyttsp4 driver.
The android driver has this if-statement where it basically supports
both level and falling edge interrupts:
8da04464e2/drivers/input/touchscreen/cyttsp5/cyttsp5_core.c (L5962)
However, when I grep for this level_irq_udelay variable, it is not used
anywhere in the cyttsp5 android driver. However, the cyttsp4 driver
actually uses it to add a delay to the interrupt handler, which makes
sense when you trigger on level low:
8da04464e2/drivers/input/touchscreen/cyttsp4_core.c (L1238)
Summarizing, I think the dt scheme and the pinenote dts should be fixed.
In case that you agree with my assessment, could you by chance advise me
how to proceed?
to activate the frequency shift for the boost converter switching
frequency from 500 kHz to 560 kHz. This reduces observed flickering of
the backlight during certain operations (one extreme flickering state
was observed for warm backlight brightness 186 and cold backlight
brightness 255).
Flickering can be even more reduced by activating the 1 Mhz switching
frequency (boolean currently commented out). However, activating this
option is associated with a reduced efficiency of the driver. Also, any
potential side effects associated with the Pinenote hardware should be
checked by someone with more in-depth knowledge of the Pinenote
hardware.
enable in arch/arm64/boot/dts/rockchip/rk3566-pinenote.dtsi, node rk_rga
todo: the entry does not define resets for the rga as this leads to a
kernel panic. Therefore module unloading does not work at the moment and
the module should be blacklisted to prevent accidental loading.
This reverts commit b88c5c8eeed0351dfc589777fe9e7581f5519dba. I
suspect this commits introduces artefacts that can potentially damage
the display if not interrupted.
and don't allow redraws when redraw_delay <= 0
Previously changing waveforms using redraw_delay=0 could cause pixels
to be stuck in what was previously their WAITING state without
shrinking clip_ongoing_or_waiting. The display would stay responsive,
but the refresh thread would occupy the CPU, causing the kernel to
warn about soft lockups.
This change resets all pixels to IDLE when modifying the LUT. At this
point all pixels are either IDLE or WAITING. Pixels that are intended
to be redrawn would become WAITING in the same iteration.
Extend mode ioctl to get/set the dither mode and the redraw delay.
Add zero_waveform ioctl that causes the controller to drive the
display with an all-neutral phase buffer. This allows measuring the
VCOM using the following protocol:
1. Perform IOCTL zero_waveform(set_zero_waveform_mode=1,
zero_waveform_mode=1)
2. Confirm that the phase buffer is all zero. zero_waveform_mode needs
to be 1 after ICTL zero_waveform(set_zero_waveform_mode=0).
3. Perform the VCOM measurement.
4. Perform IOCTL zero_waveform(set_zero_waveform_mode=1,
zero_waveform_mode=0)
changes in uAPI:
- Change IOCTL define from IOWR to IOW
changes in driver:
- Instead of packed Y4 use 1 byte per pixel similar to the rest of the
driver
- Enhance error handling
changes in uAPI:
- Generalise structure to allow reading and writing as well as future
generalisations of mode
- Rename ioctl and structure
changes in driver:
- Accomodate new ioctl
changes in uAPI:
- Uses drm_mode_rect to not leak an include from include/linux (drm_rect)
- make ioctl parameter 64bit clean (https://www.kernel.org/doc/html/latest/process/botching-up-ioctls.html)
- change the IOCTL define from IOWR to IOW, since we don't plan on
reading anything from kernel.
- fix the ROCKCHIP_EBC_HINT_BIT_DEPTH_MASK to mask every bits used.
- add a default_hint field in the structure, so it can be set in one go,
instead of relying on first setting the parameter.
changes in driver:
- setting default_hint now uses the new field from uAPI struct, and
write it to the kernel parameter
- rect_hint count is now variable and controlled from userland.
