Re: [PATCH v2 5/6] drm/panel: st7703: Drive XBD599 panel at higher clock rate
在 2024-02-25星期日的 17:46 +0100，Frank Oltmanns写道： > Hi Maxime, > > On 2024-02-22 at 11:29:51 +0100, Maxime Ripard > wrote: > > [[PGP Signed Part:Undecided]] > > On Sun, Feb 11, 2024 at 04:42:43PM +0100, Frank Oltmanns wrote: > > > > > > On 2024-02-08 at 20:05:08 +0100, Maxime Ripard > > > wrote: > > > > [[PGP Signed Part:Undecided]] > > > > Hi Frank, > > > > > > > > On Mon, Feb 05, 2024 at 04:22:28PM +0100, Frank Oltmanns wrote: > > > > > This panel is used in the pinephone that runs on a Allwinner > > > > > A64 SOC. > > > > > The SOC requires pll-mipi to run at more than 500 MHz. > > > > > > > > > > This is the relevant clock tree: > > > > > pll-mipi > > > > > tcon0 > > > > > tcon-data-clock > > > > > > > > > > tcon-data-clock has to run at 1/4 the DSI per-lane bit rate. > > > > > The XBD599 > > > > > has 24 bpp and 4 lanes. Therefore, the resulting requested > > > > > tcon-data-clock rate is: > > > > > crtc_clock * 1000 * (24 / 4) / 4 > > > > > > > > > > tcon-data-clock runs at tcon0 / 4 (fixed divisor), so it > > > > > requests a > > > > > parent rate of > > > > > 4 * (crtc_clock * 1000 * (24 / 4) / 4) > > > > > > > > > > Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate > > > > > of pll-mipi. > > > > > > > > > > pll-mipi's constraint to run at 500MHz or higher forces us to > > > > > have a > > > > > crtc_clock >= 8 kHz if we want a 60 Hz vertical refresh > > > > > rate. > > > > > > > > > > Change [hv]sync_(start|end) so that we reach a clock rate of > > > > > 83502 kHz > > > > > so that it is high enough to align with pll-pipi limits. > > > > > > > > > > Signed-off-by: Frank Oltmanns > > > > > > > > That commit log is great, but it's kind of off-topic. It's a > > > > panel > > > > driver, it can be used on any MIPI-DSI controller, the only > > > > relevant > > > > information there should be the panel timings required in the > > > > datasheet. > > > > > > > > The PLL setup is something for the MIPI-DSI driver to adjust, > > > > not for > > > > the panel to care for. > > > > > > > > > > I absolutely agree. It even was the reason for my submission of a > > > sunxi-ng patch series last year that was accepted, to make pll- > > > mipi more > > > flexible. :) > > > > > > The only remaining option I currently see for adjusting the > > > sunxi-ng > > > driver to further accomodate the panel, is trying to use a higher > > > divisor than 4 for calculating tcon-data-clock from tcon0. I > > > remember > > > reading a discussion about this, but as far as I remember that > > > proposal > > > was rejected (by you, IIRC). > > > > > > While I appreciate other suggestion as well, I'll look into > > > options for > > > using a different divisor than 4. > > > > Like I said, I'm not against the patch at all, it looks great to me > > on > > principle. I just think you should completely rephrase the commit > > log > > using the datasheet as the only reliable source of the display > > timings. > > Whether sun4i can work around the panel requirements is something > > completely orthogonal to the discussion, and thus the commit log. > > > > I was trying to follow the guidelines [1] for describing the reason > behind my changes to the panel. My original commit message was a lot > shorter, which, understandably, resulted in follow up questions [2]. > With the current commit log, I'm trying to address those questions. > According to the device tree, the panel is only used in the > pinephone. > The only reason for the change is that the SoC used by the only user > of > this panel can not provide the rate the panel requests with the > current > values. I think this information is relevant. > > Unfortunately, as described in [2], I cannot back these values with > any > datasheets because I couldn't find any. I could only find hints that > they are not publicly available. Icenowy (added to CC) submitted the > original values. Sorry but this kind of things are just magic from the vendor that I could hardly explain... > > Best regards, > Frank > > [1]: > https://www.kernel.org/doc/html/v6.7/process/submitting-patches.html#describe-your-changes > [2]: https://lore.kernel.org/lkml/87wmsvo0fh@oltmanns.dev/ > > > > > Maxime > > > > [[End of PGP Signed Part]] >
Re: [v3 4/6] drm/vs: Add KMS crtc
在 2023-12-07星期四的 19:31 +0800，Keith Zhao写道：
>
>
> On 2023/12/7 16:41, Icenowy Zheng wrote:
> > 在 2023-12-04星期一的 20:33 +0800，Keith Zhao写道：
> > *snip*
> >
> > > +static void update_cursor_plane(struct vs_dc *dc, struct
> > > vs_plane
> > > *plane,
> > > + struct drm_plane *drm_plane,
> > > + struct drm_atomic_state
> > > *drm_state)
> > > +{
> > > + struct drm_plane_state *state =
> > > drm_atomic_get_new_plane_state(drm_state,
> > > +
> > >
> > > drm_plane);
> > > + struct vs_plane_state *plane_state =
> > > to_vs_plane_state(state);
> > > + struct drm_framebuffer *drm_fb = state->fb;
> > > + struct dc_hw_cursor cursor;
> > > +
> > > + cursor.address = plane_state->dma_addr[0];
> > > + cursor.x = state->crtc_x;
> > > + cursor.y = state->crtc_y;
> >
> > From my experiments on poking with registers on T-Head TH1520 (also
> > uses DC8200 display controller and a similar driver), the DC8200
> > hardware have a different definition of cursor position X and Y
> > with
> > the CRTC plane state.
> >
> > For CRTC plane state, hot_x and hot_y are only provided as
> > reference,
> > and the cursor should be displayed with its (0,0) drawn to (crtc_x,
> > crtc_y) ([XY]_crtc are values specified in CRTC state, the right
> > part
> > of the assignments here), when the cursor is moved to (0,0) but the
> > hot
> > point is not (0,0), it could be negative.
> >
> > However, for DC8200 registers definition, cursor XY position could
> > not
> > be negative -- the cursor will disappear then; because in its
> > definition, the cursor XY position should be where the cursor is
> > pointing to, instead of its (0,0). DC8200 will draw (0,0) of the
> > cursor
> > to (x - hot_x, y - hot_y). So to met the expectation of the KMS
> > plane
> > settings, the DC8200 position should be set to (crtc_x + hot_x,
> > crtc_y
> > + hot_y) instead. Thus these two lines of code should be:
> >
> > ```
> > cursor.x = state->crtc_x + drm_fb->hot_x;
> > cursor.y = state->crtc_y + drm_fb->hot_y;
> > ```
Well I realized that this change is not correct too: when moving the
mouse cursor with the screen rotated, the mouse cursor will disappear
at some screen border.
My current idea is:
As the CRTC hot point is just a reference, we can just ignore it, and
use the HW hot point to implement negative cursor position.
The patch is like the follow:
-cursor.x = state->crtc_x;
-cursor.y = state->crtc_y;
-cursor.hot_x = drm_fb->hot_x;
-cursor.hot_y = drm_fb->hot_y;
+if (state->crtc_x > 0) {
+cursor.x = state->crtc_x;
+cursor.hot_x = 0;
+} else {
+cursor.hot_x = -state->crtc_x;
+cursor.x = 0;
+}
+if (state->crtc_y > 0) {
+cursor.y = state->crtc_y;
+cursor.hot_y = 0;
+} else {
+cursor.hot_y = -state->crtc_y;
+cursor.y = 0;
+}
drm_fb could just be removed in this function then because it's no
longer needed (it's used to get the cursor's hot point, which we
ignored now).
> >
> >
> > > + cursor.hot_x = drm_fb->hot_x;
> > > + cursor.hot_y = drm_fb->hot_y;
> > > + cursor.display_id = to_vs_display_id(dc, state->crtc);
> > > + update_cursor_size(state, );
> > > + cursor.enable = true;
> > > +
> > > + dc_hw_update_cursor(>hw, cursor.display_id, );
> > > +}
> > *snip
> hello Icenowy:
> you are deep understanding on dc8200.
> by the way of practice
> I tested this change on the debian desktop, is there a way to compare
> the cursor behavior change?
> Thanks
>
>
>
Re: [v3 4/6] drm/vs: Add KMS crtc
在 2023-12-07星期四的 19:31 +0800，Keith Zhao写道：
>
>
> On 2023/12/7 16:41, Icenowy Zheng wrote:
> > 在 2023-12-04星期一的 20:33 +0800，Keith Zhao写道：
> > *snip*
> >
> > > +static void update_cursor_plane(struct vs_dc *dc, struct
> > > vs_plane
> > > *plane,
> > > + struct drm_plane *drm_plane,
> > > + struct drm_atomic_state
> > > *drm_state)
> > > +{
> > > + struct drm_plane_state *state =
> > > drm_atomic_get_new_plane_state(drm_state,
> > > +
> > >
> > > drm_plane);
> > > + struct vs_plane_state *plane_state =
> > > to_vs_plane_state(state);
> > > + struct drm_framebuffer *drm_fb = state->fb;
> > > + struct dc_hw_cursor cursor;
> > > +
> > > + cursor.address = plane_state->dma_addr[0];
> > > + cursor.x = state->crtc_x;
> > > + cursor.y = state->crtc_y;
> >
> > From my experiments on poking with registers on T-Head TH1520 (also
> > uses DC8200 display controller and a similar driver), the DC8200
> > hardware have a different definition of cursor position X and Y
> > with
> > the CRTC plane state.
> >
> > For CRTC plane state, hot_x and hot_y are only provided as
> > reference,
> > and the cursor should be displayed with its (0,0) drawn to (crtc_x,
> > crtc_y) ([XY]_crtc are values specified in CRTC state, the right
> > part
> > of the assignments here), when the cursor is moved to (0,0) but the
> > hot
> > point is not (0,0), it could be negative.
> >
> > However, for DC8200 registers definition, cursor XY position could
> > not
> > be negative -- the cursor will disappear then; because in its
> > definition, the cursor XY position should be where the cursor is
> > pointing to, instead of its (0,0). DC8200 will draw (0,0) of the
> > cursor
> > to (x - hot_x, y - hot_y). So to met the expectation of the KMS
> > plane
> > settings, the DC8200 position should be set to (crtc_x + hot_x,
> > crtc_y
> > + hot_y) instead. Thus these two lines of code should be:
> >
> > ```
> > cursor.x = state->crtc_x + drm_fb->hot_x;
> > cursor.y = state->crtc_y + drm_fb->hot_y;
> > ```
> >
> >
> > > + cursor.hot_x = drm_fb->hot_x;
> > > + cursor.hot_y = drm_fb->hot_y;
> > > + cursor.display_id = to_vs_display_id(dc, state->crtc);
> > > + update_cursor_size(state, );
> > > + cursor.enable = true;
> > > +
> > > + dc_hw_update_cursor(>hw, cursor.display_id, );
> > > +}
> > *snip
> hello Icenowy:
> you are deep understanding on dc8200.
> by the way of practice
> I tested this change on the debian desktop, is there a way to compare
> the cursor behavior change?
Try selecting some small-sized text in a textbox?
> Thanks
>
>
>
Re: [v3 4/6] drm/vs: Add KMS crtc
在 2023-12-04星期一的 20:33 +0800，Keith Zhao写道：
*snip*
> +static void update_cursor_plane(struct vs_dc *dc, struct vs_plane
> *plane,
> + struct drm_plane *drm_plane,
> + struct drm_atomic_state *drm_state)
> +{
> + struct drm_plane_state *state =
> drm_atomic_get_new_plane_state(drm_state,
> +
> drm_plane);
> + struct vs_plane_state *plane_state =
> to_vs_plane_state(state);
> + struct drm_framebuffer *drm_fb = state->fb;
> + struct dc_hw_cursor cursor;
> +
> + cursor.address = plane_state->dma_addr[0];
> + cursor.x = state->crtc_x;
> + cursor.y = state->crtc_y;
From my experiments on poking with registers on T-Head TH1520 (also
uses DC8200 display controller and a similar driver), the DC8200
hardware have a different definition of cursor position X and Y with
the CRTC plane state.
For CRTC plane state, hot_x and hot_y are only provided as reference,
and the cursor should be displayed with its (0,0) drawn to (crtc_x,
crtc_y) ([XY]_crtc are values specified in CRTC state, the right part
of the assignments here), when the cursor is moved to (0,0) but the hot
point is not (0,0), it could be negative.
However, for DC8200 registers definition, cursor XY position could not
be negative -- the cursor will disappear then; because in its
definition, the cursor XY position should be where the cursor is
pointing to, instead of its (0,0). DC8200 will draw (0,0) of the cursor
to (x - hot_x, y - hot_y). So to met the expectation of the KMS plane
settings, the DC8200 position should be set to (crtc_x + hot_x, crtc_y
+ hot_y) instead. Thus these two lines of code should be:
```
cursor.x = state->crtc_x + drm_fb->hot_x;
cursor.y = state->crtc_y + drm_fb->hot_y;
```
> + cursor.hot_x = drm_fb->hot_x;
> + cursor.hot_y = drm_fb->hot_y;
> + cursor.display_id = to_vs_display_id(dc, state->crtc);
> + update_cursor_size(state, );
> + cursor.enable = true;
> +
> + dc_hw_update_cursor(>hw, cursor.display_id, );
> +}
*snip
Re: [PATCH] drm/loongson: Add support for the DC in LS2K1000 SoC
在 2023-10-12星期四的 00:26 +0800，Sui Jingfeng写道：
> LS2K1000 is a low end SoC (two core 1.0gHz), it don't has dedicated
> VRAM.
> It requires the framebuffer to be phisically continguous to scanout.
> The
> display controller in LS2K1000 don't has built-in GPIO hardware, the
> structure (register bit field) of its pixel, DC, GPU, DDR PLL are
> also
> defferent from other model. But for the display controller itself,
> Most of
> hardware features of it are same with ls7a1000.
>
> Below is a simple dts for it.
Why don't you write a proper, YAML-formatted binding?
This will help handling the correctness of device trees, and a binding
is required to allow the driver to enter.
>
> aliases {
> i2c0 =
> i2c1 =
> };
>
> reserved-memory {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> display_reserved: framebuffer@3000 {
> compatible = "shared-dma-pool";
> reg = <0x0 0x2000 0x0 0x0800>; /* 128M */
> linux,cma-default;
> };
> };
>
> i2c0: i2c-gpio-0 {
> compatible = "i2c-gpio";
> scl-gpios = < 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> sda-gpios = < 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> i2c-gpio,delay-us = <5>; /* ~100 kHz */
> status = "okay";
> };
>
> i2c1: i2c-gpio-1 {
> compatible = "i2c-gpio";
> scl-gpios = < 33 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> sda-gpios = < 32 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> i2c-gpio,delay-us = <5>; /* ~100 kHz */
> status = "okay";
> };
>
> display-controller@6,0 {
> reg = <0x3000 0x0 0x0 0x0 0x0>;
> interrupt-parent = <>;
> interrupts = <28 IRQ_TYPE_LEVEL_HIGH>
> memory-region = <_reserved>;
Is a system-wide CMA pool enough for this usage? And for a display
controller, will 128M be too much? (I assume the Vivante GPU do not
require contingous memory).
> status = "okay";
> };
>
> This patch is tested on ls2k1000 evaluation board.
>
> $ dmesg | grep ":00:06.0"
>
> loongson :00:06.0: Found LS2K1000 SoC, revision: 0
> loongson :00:06.0: [drm] dc: 250MHz, ddr: 400MHz, gpu: 228MHz
> loongson :00:06.0: [drm] Using of reserved mem:
> 800@0x2000
> loongson :00:06.0: [drm] VRAM: 8192 pages ready
> loongson :00:06.0: [drm] GTT: 32768 pages ready
> loongson :00:06.0: [drm] display pipe-0 has a DVO
> loongson :00:06.0: [drm] display pipe-1 has a DVO
> loongson :00:06.0: [drm] Total 2 outputs
> loongson :00:06.0: [drm] registered irq: 28
> [drm] Initialized loongson 1.0.0 20220701 for :00:06.0 on minor
> 0
> loongson :00:06.0: [drm] fb0: loongsondrmfb frame buffer device
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/loongson/Makefile | 1 +
> drivers/gpu/drm/loongson/loongson_device.c | 59 +++
> drivers/gpu/drm/loongson/lsdc_drv.c | 44 -
> drivers/gpu/drm/loongson/lsdc_drv.h | 9 ++
> drivers/gpu/drm/loongson/lsdc_gfxpll.c | 11 +-
> drivers/gpu/drm/loongson/lsdc_gfxpll.h | 4 +
> drivers/gpu/drm/loongson/lsdc_gfxpll_2k1000.c | 141
> drivers/gpu/drm/loongson/lsdc_i2c.c | 41 +
> drivers/gpu/drm/loongson/lsdc_i2c.h | 4 +
> drivers/gpu/drm/loongson/lsdc_pixpll.c | 153
> +-
> drivers/gpu/drm/loongson/lsdc_pixpll.h | 4 +
> drivers/gpu/drm/loongson/lsdc_probe.c | 27
> drivers/gpu/drm/loongson/lsdc_probe.h | 2 +
> drivers/gpu/drm/loongson/lsdc_regs.h | 36 +
> 14 files changed, 528 insertions(+), 8 deletions(-)
> create mode 100644 drivers/gpu/drm/loongson/lsdc_gfxpll_2k1000.c
>
> diff --git a/drivers/gpu/drm/loongson/Makefile
> b/drivers/gpu/drm/loongson/Makefile
> index 91e72bd900c1..d6e709e19fba 100644
> --- a/drivers/gpu/drm/loongson/Makefile
> +++ b/drivers/gpu/drm/loongson/Makefile
> @@ -7,6 +7,7 @@ loongson-y := \
> lsdc_drv.o \
> lsdc_gem.o \
> lsdc_gfxpll.o \
> + lsdc_gfxpll_2k1000.o \
> lsdc_i2c.o \
> lsdc_irq.o \
> lsdc_output_7a1000.o \
> diff --git a/drivers/gpu/drm/loongson/loongson_device.c
> b/drivers/gpu/drm/loongson/loongson_device.c
> index 9986c8a2a255..67274d9e3b12 100644
> --- a/drivers/gpu/drm/loongson/loongson_device.c
> +++ b/drivers/gpu/drm/loongson/loongson_device.c
> @@ -6,6 +6,7 @@
> #include
>
> #include "lsdc_drv.h"
> +#include "lsdc_probe.h"
>
> static const struct lsdc_kms_funcs ls7a1000_kms_funcs = {
> .create_i2c = lsdc_create_i2c_chan,
> @@ -25,6 +26,20 @@ static const struct lsdc_kms_funcs
> ls7a2000_kms_funcs = {
> .crtc_init = ls7a2000_crtc_init,
> };
>
> +/*
> + * Most of hardware features of ls2k1000 are same with ls7a1000, we
> take the
> + * ls7a1000_kms_funcs as a prototype, copy and modify to form a
> variant for
> + *
[PATCH] drm/amdgpu: fix SI failure due to doorbells allocation
SI hardware does not have doorbells at all, however currently the code
will try to do the allocation and thus fail, makes SI AMDGPU not usable.
Fix this failure by skipping doorbells allocation when doorbells count
is zero.
Fixes: 54c30d2a8def ("drm/amdgpu: create kernel doorbell pages")
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
index d0249ada91d30..599aece42017a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
@@ -142,6 +142,10 @@ int amdgpu_doorbell_create_kernel_doorbells(struct
amdgpu_device *adev)
int r;
int size;
+ /* SI HW does not have doorbells, skip allocation */
+ if (adev->doorbell.num_kernel_doorbells == 0)
+ return 0;
+
/* Reserve first num_kernel_doorbells (page-aligned) for kernel ops */
size = ALIGN(adev->doorbell.num_kernel_doorbells * sizeof(u32),
PAGE_SIZE);
--
2.39.1
Re: [PATCH 2/3] clk: sunxi-ng: a64: keep tcon0 clock rate when pll-video0's rate changes
在 2023-08-07星期一的 11:48 +0200，Frank Oltmanns写道：
>
> On 2023-08-07 at 17:43:52 +0800, Icenowy Zheng
> wrote:
> > 在 2023-08-07星期一的 11:36 +0200，Frank Oltmanns写道：
> > > From: Icenowy Zheng
> > >
> > > Notify TCON0 clock (and in consequence PLL-MIPI by
> > > CLK_SET_RATE_PARENT)
> > > to reset when PLL-Video0 changes (because of HDMI PHY clk which
> > > is a
> > > child of PLL-Video0 and has CLK_SET_RATE_PARENT set). In this way
> > > we
> > > can
> > > get clock tree to satisfy both pipelines.
> >
> > Well for fixing one's patch that contains SoB, use the following
> > format:
> >
> > Signed-off-by: A
> > [B: fixed something]
> > Signed-off-by: B
>
> Ah, okay. Will do. But I keep A in the "From: " line, correct?
Yes.
>
> Thanks,
> Frank
>
> > > ---
> > > drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 15 +++
> > > 1 file changed, 15 insertions(+)
> > >
> > > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > > b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > > index ef567775fc95..93beedb0428e 100644
> > > --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > > @@ -943,6 +943,17 @@ static struct ccu_mux_nb sun50i_a64_cpu_nb =
> > > {
> > > .bypass_index = 1, /* index of 24 MHz oscillator */
> > > };
> > >
> > > +/*
> > > + * Since PLL-Video0 is an ancestor of both tcon0 and HDMI PYH,
> > > tcon0
> > > clock will
> > > + * conflict with HDMI PHY clock which is on another display
> > > pipeline.
> > > + *
> > > + * Therefore, a notifier is required to restore the rate of
> > > TCON0
> > > when the rate
> > > + * of PLL-Video0 changed.
> > > + */
> > > +static struct ccu_rate_reset_nb
> > > sun50i_a64_pll_video0_reset_tcon0_nb
> > > = {
> > > + .common = _video0_clk.common,
> > > +};
> > > +
> > > static int sun50i_a64_ccu_probe(struct platform_device *pdev)
> > > {
> > > void __iomem *reg;
> > > @@ -978,6 +989,10 @@ static int sun50i_a64_ccu_probe(struct
> > > platform_device *pdev)
> > > ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
> > > _a64_cpu_nb);
> > >
> > > + /* Reset the rate of TCON0 clock when PLL-VIDEO0 is
> > > changed
> > > */
> > > + sun50i_a64_pll_video0_reset_tcon0_nb.target_clk =
> > > tcon0_clk.common.hw.clk;
> > > + ccu_rate_reset_notifier_register(_a64_pll_video0_r
> > > eset
> > > _tcon0_nb);
> > > +
> > > return 0;
> > > }
> > >
> > >
Re: [PATCH 2/3] clk: sunxi-ng: a64: keep tcon0 clock rate when pll-video0's rate changes
在 2023-08-07星期一的 11:36 +0200，Frank Oltmanns写道：
> From: Icenowy Zheng
>
> Notify TCON0 clock (and in consequence PLL-MIPI by
> CLK_SET_RATE_PARENT)
> to reset when PLL-Video0 changes (because of HDMI PHY clk which is a
> child of PLL-Video0 and has CLK_SET_RATE_PARENT set). In this way we
> can
> get clock tree to satisfy both pipelines.
Well for fixing one's patch that contains SoB, use the following
format:
Signed-off-by: A
[B: fixed something]
Signed-off-by: B
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> index ef567775fc95..93beedb0428e 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> @@ -943,6 +943,17 @@ static struct ccu_mux_nb sun50i_a64_cpu_nb = {
> .bypass_index = 1, /* index of 24 MHz oscillator */
> };
>
> +/*
> + * Since PLL-Video0 is an ancestor of both tcon0 and HDMI PYH, tcon0
> clock will
> + * conflict with HDMI PHY clock which is on another display
> pipeline.
> + *
> + * Therefore, a notifier is required to restore the rate of TCON0
> when the rate
> + * of PLL-Video0 changed.
> + */
> +static struct ccu_rate_reset_nb sun50i_a64_pll_video0_reset_tcon0_nb
> = {
> + .common = _video0_clk.common,
> +};
> +
> static int sun50i_a64_ccu_probe(struct platform_device *pdev)
> {
> void __iomem *reg;
> @@ -978,6 +989,10 @@ static int sun50i_a64_ccu_probe(struct
> platform_device *pdev)
> ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
> _a64_cpu_nb);
>
> + /* Reset the rate of TCON0 clock when PLL-VIDEO0 is changed
> */
> + sun50i_a64_pll_video0_reset_tcon0_nb.target_clk =
> tcon0_clk.common.hw.clk;
> + ccu_rate_reset_notifier_register(_a64_pll_video0_reset
> _tcon0_nb);
> +
> return 0;
> }
>
>
Re: [PATCH 1/3] clk: sunxi-ng: add support for rate resetting notifier
在 2023-08-07星期一的 11:36 +0200，Frank Oltmanns写道：
> From: Icenowy Zheng
>
> In some situaitons, we will want a clock rate be kept while its
> parent
> can change, for example, to make dual-head work on A64, TCON0 clock
> needs to be kept for LCD display and its parent (or grandparent)
> PLL-Video0 need to be changed for HDMI display. (There's a quirk on
> A64
> that HDMI PHY can only use PLL-Video0, not PLL-Video1).
>
> Add a notifier helper to create such kind of rate keeping notifier by
> reset the rate after the parent changed.
>
> Signed-off-by: Icenowy Zheng
> ---
> drivers/clk/sunxi-ng/ccu_common.c | 22 ++
> drivers/clk/sunxi-ng/ccu_common.h | 12
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-
> ng/ccu_common.c
> index 8d28a7a079d0..434fa46ad460 100644
> --- a/drivers/clk/sunxi-ng/ccu_common.c
> +++ b/drivers/clk/sunxi-ng/ccu_common.c
> @@ -87,6 +87,28 @@ int ccu_pll_notifier_register(struct ccu_pll_nb
> *pll_nb)
> }
> EXPORT_SYMBOL_NS_GPL(ccu_pll_notifier_register, SUNXI_CCU);
>
> +static int ccu_rate_reset_notifier_cb(struct notifier_block *nb,
> + unsigned long event, void
> *data)
> +{
> + struct ccu_rate_reset_nb *rate_reset =
> to_ccu_rate_reset_nb(nb);
> +
> + if (event == PRE_RATE_CHANGE) {
> + rate_reset->saved_rate = clk_get_rate(rate_reset-
> >target_clk);
In fact I think we should have a better way to save the intended clock
rate ;-)
> + } else if (event == POST_RATE_CHANGE) {
> + clk_set_rate(rate_reset->target_clk, rate_reset-
> >saved_rate);
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
> +int ccu_rate_reset_notifier_register(struct ccu_rate_reset_nb
> *rate_reset_nb)
> +{
> + rate_reset_nb->clk_nb.notifier_call =
> ccu_rate_reset_notifier_cb;
> +
> + return clk_notifier_register(rate_reset_nb->common->hw.clk,
> + _reset_nb->clk_nb);
> +}
> +
> static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device
> *dev,
> struct device_node *node, void __iomem
> *reg,
> const struct sunxi_ccu_desc *desc)
> diff --git a/drivers/clk/sunxi-ng/ccu_common.h b/drivers/clk/sunxi-
> ng/ccu_common.h
> index fbf16c6b896d..6b0b05fae123 100644
> --- a/drivers/clk/sunxi-ng/ccu_common.h
> +++ b/drivers/clk/sunxi-ng/ccu_common.h
> @@ -69,4 +69,16 @@ int devm_sunxi_ccu_probe(struct device *dev, void
> __iomem *reg,
> void of_sunxi_ccu_probe(struct device_node *node, void __iomem *reg,
> const struct sunxi_ccu_desc *desc);
>
> +struct ccu_rate_reset_nb {
> + struct notifier_block clk_nb;
> + struct ccu_common *common;
> +
> + struct clk *target_clk;
> + unsigned long saved_rate;
> +};
> +
> +#define to_ccu_rate_reset_nb(_nb) container_of(_nb, struct
> ccu_rate_reset_nb, clk_nb)
> +
> +int ccu_rate_reset_notifier_register(struct ccu_rate_reset_nb
> *rate_reset_nb);
> +
> #endif /* _COMMON_H_ */
>
Re: [PATCH] drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID
在 2023-06-14星期三的 14:31 -0700，Doug Anderson写道：
> Hi,
>
> On Wed, Jun 14, 2023 at 1:22 AM AngeloGioacchino Del Regno
> wrote:
> >
> > Il 13/06/23 01:32, Douglas Anderson ha scritto:
> > > In order to read the EDID from an eDP panel, you not only need to
> > > power on the bridge chip itself but also the panel. In the ps8640
> > > driver, this was made to work by having the bridge chip manually
> > > power
> > > the panel on by calling pre_enable() on everything connectorward
> > > on
> > > the bridge chain. This worked OK, but...
> > >
> > > ...when trying to do the same thing on ti-sn65dsi86, feedback was
> > > that
> > > this wasn't a great idea. As a result, we designed the "DP AUX"
> > > bus. With the design we ended up with the panel driver itself was
> > > in
> > > charge of reading the EDID. The panel driver could power itself
> > > on and
> > > the bridge chip was able to power itself on because it
> > > implemented the
> > > DP AUX bus.
> > >
> > > Despite the fact that we came up with a new scheme, implemented
> > > in on
> > > ti-sn65dsi86, and even implemented it on parade-ps8640, we still
> > > kept
> > > the old code around. This was because the new scheme required a
> > > DT
> > > change. Previously the panel was a simple "platform_device" and
> > > in DT
> > > at the top level. With the new design the panel needs to be
> > > listed in
> > > DT under the DP controller node. The old code allowed us to
> > > properly
> > > fetch EDIDs with ps8640 with the old DTs.
> > >
> > > Unfortunately, the old code stopped working as of commit
> > > 102e80d1fa2c
> > > ("drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs").
> > > There
> > > are cases at bootup where connector->state->state is NULL and the
> > > kernel crashed at:
> > > * drm_atomic_bridge_chain_pre_enable
> > > * drm_atomic_get_old_bridge_state
> > > * drm_atomic_get_old_private_obj_state
> > >
> > > A bit of digging was done to see if there was an easy fix but
> > > there
> > > was nothing obvious. Instead, the only device using ps8640 the
> > > "old"
> > > way had its DT updated so that the panel was no longer a simple
> > > "platform_deice". See commit c2d94f72140a ("arm64: dts: mediatek:
> > > mt8173-elm: Move display to ps8640 auxiliary bus") and commit
> > > 113b5cc06f44 ("arm64: dts: mediatek: mt8173-elm: remove panel
> > > model
> > > number in DT").
> > >
> > > Let's delete the old, crashing code so nobody gets tempted to
> > > copy it
> > > or figure out how it works (since it doesn't).
> > >
> > > NOTE: from a device tree "purist" point of view, we're supposed
> > > to
> > > keep old device trees working and this patch is technically
> > > "against
> > > policy". Reasons I'm still proposing it anyway:
> > > 1. Officially, old mt8173-elm device trees worked via the "little
> > > white lie" approach. The DT would list an
> > > arbitrary/representative
> > > panel that would be used for power sequencing. The mode
> > > information
> > > in the panel driver would then be ignored / overridden by the
> > > EDID
> > > reading code in ps8640. I don't feel too terrible breaking
> > > DTs that
> > > contained the wrong "compatible" string to begin with. NOTE
> > > that
> > > any old device trees that _didn't_ lie about their compatible
> > > will
> > > still work because the mode information will come from the
> > > hardcoded panels in panel-edp.
> > > 2. The only users of the old code were Chromebooks and
> > > Chromebooks
> > > don't bake their DTs into the BIOS (they are bundled with the
> > > kernel). Thus we don't need to worry about breaking someone
> > > using
> > > an old DT with a new kernel.
> > > 3. The old code was crashing anyway. If someone wants to fix the
> > > old
> > > code instead of deleting it then they have my blessing, but
> > > without
> > > a proper fix the old code isn't useful.
> > >
> > > I'll list this as "Fixing" the code that made the old code start
> > > failing. There's not lots of reason to bring this back any
> > > further
> > > than that.
> >
> > Hoping to see removal of non-aux EDID reading code from all drivers
> > that can
> > support aux-bus is exactly why I moved Elm to the proper... aux-
> > bus.. so...
> >
> > Yes! Let's go!
> >
> > >
> > > Fixes: 102e80d1fa2c ("drm/bridge: ps8640: Use atomic variants of
> > > drm_bridge_funcs")
> >
> > ...but this Fixes tag will cause this commit to be backported to
> > kernel versions
> > before my commit moving Elm to aux-bus, and break display on those.
> >
> > I would suggest to either find a different Fixes tag, or don't add
> > any, since
> > technically this is a deprecation commit. We could imply that the
> > old technique
> > is deprecated since kernel version X.Y and get away with it.
> >
> > Otherwise, if you want it backported *anyway*, the safest way would
> > be to Cc it
> > to stable and explicitly say which versions should it be backported
> > to.
>
> The problem is
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
在 2023-05-29星期一的 18:28 +0200，Matthias Brugger写道：
>
>
> On 29/05/2023 10:45, Icenowy Zheng wrote:
> > 在 2023-05-29星期一的 10:02 +0200，AngeloGioacchino Del Regno写道：
> > > Il 26/05/23 16:24, Doug Anderson ha scritto:
> > > > Hi,
> > > >
> > > > On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng
> > > > wrote:
> > > > >
> > > > > Currently a specific panel number is used in the Elm DTSI,
> > > > > which
> > > > > is
> > > > > corresponded to a 12" panel. However, according to the
> > > > > official
> > > > > Chrome
> > > > > OS devices document, Elm refers to Acer Chromebook R13,
> > > > > which, as
> > > > > the
> > > > > name specifies, uses a 13.3" panel, which comes with EDID
> > > > > information.
> > > > >
> > > > > As the kernel currently prioritizes the hardcoded timing
> > > > > parameters
> > > > > matched with the panel number compatible, a wrong timing will
> > > > > be
> > > > > applied
> > > > > to the 13.3" panel on Acer Chromebook R13, which leads to
> > > > > blank
> > > > > display.
> > > > >
> > > > > Because the Elm DTSI is shared with Hana board, and Hana
> > > > > corresponds to
> > > > > multiple devices from 11" to 14", a certain panel model
> > > > > number
> > > > > shouldn't
> > > > > be present, and driving the panel according to its EDID
> > > > > information is
> > > > > necessary.
> > > > >
> > > > > Signed-off-by: Icenowy Zheng
> > > > > ---
> > > > > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > We went through a bunch of back-and-forth here but in the end
> > > > in
> > > > the
> > > > ChromeOS tree we have "edp-panel" as the "compatible" here in
> > > > the
> > > > ChromeOS 5.15 tree and this makes sense.
> > > >
> > > > Reviewed-by: Douglas Anderson
> > > >
> > > > ...in theory one would wish for a "Fixes" tag, but I think in
> > > > previous
> > > > discussions it was decided that it was too complicated.
> > > > Hardcoding
> > > > the
> > > > other compatible string has always been technically wrong, but
> > > > I
> > > > guess
> > > > it worked at some point in time. The more correct way (as
> > > > you're
> > > > doing
> > > > here) needs the DP AUX bus support and the generic eDP panels,
> > > > both
> > > > of
> > > > which are significantly newer than the elm dts. So I guess
> > > > leaving
> > > > no
> > > > "Fixes" tag is OK, or perhaps you could do the somewhat weak:
> > > >
> > > > Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move
> > > > display
> > > > to ps8640 auxiliary bus")
> > >
> > > I remember I didn't change the compatible to panel-edp because it
> > > didn't
> > > work at that time, but it does now... I'm not sure what actually
> > > fixed that
> > > and if the commit(s) was/were backported to that suggested point,
> > > so
> > > I
> > > would leave the Fixes tag out, as that may break older kernel.
> >
> > Well at least I developed this patch on v6.3.
> >
> > (In fact the same kernel config do not boot to system at all on
> > v6.0/v6.1 when I do make olddefconfig then build)
> >
>
> I applied the patch without the fixes tag. Lets stay on the secure
> side to not
> break older kernels.
Well I think this patch is at least meaningful to get backported to
v6.3.
Should we cc sta...@vger.kernel.org ?
>
> Regards,
> Matthias
>
> > >
> > > Anyway, for this commit:
> > >
> > > Reviewed-by: AngeloGioacchino Del Regno
> > >
> >
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
在 2023-05-29星期一的 10:02 +0200，AngeloGioacchino Del Regno写道：
> Il 26/05/23 16:24, Doug Anderson ha scritto:
> > Hi,
> >
> > On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng
> > wrote:
> > >
> > > Currently a specific panel number is used in the Elm DTSI, which
> > > is
> > > corresponded to a 12" panel. However, according to the official
> > > Chrome
> > > OS devices document, Elm refers to Acer Chromebook R13, which, as
> > > the
> > > name specifies, uses a 13.3" panel, which comes with EDID
> > > information.
> > >
> > > As the kernel currently prioritizes the hardcoded timing
> > > parameters
> > > matched with the panel number compatible, a wrong timing will be
> > > applied
> > > to the 13.3" panel on Acer Chromebook R13, which leads to blank
> > > display.
> > >
> > > Because the Elm DTSI is shared with Hana board, and Hana
> > > corresponds to
> > > multiple devices from 11" to 14", a certain panel model number
> > > shouldn't
> > > be present, and driving the panel according to its EDID
> > > information is
> > > necessary.
> > >
> > > Signed-off-by: Icenowy Zheng
> > > ---
> > > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > We went through a bunch of back-and-forth here but in the end in
> > the
> > ChromeOS tree we have "edp-panel" as the "compatible" here in the
> > ChromeOS 5.15 tree and this makes sense.
> >
> > Reviewed-by: Douglas Anderson
> >
> > ...in theory one would wish for a "Fixes" tag, but I think in
> > previous
> > discussions it was decided that it was too complicated. Hardcoding
> > the
> > other compatible string has always been technically wrong, but I
> > guess
> > it worked at some point in time. The more correct way (as you're
> > doing
> > here) needs the DP AUX bus support and the generic eDP panels, both
> > of
> > which are significantly newer than the elm dts. So I guess leaving
> > no
> > "Fixes" tag is OK, or perhaps you could do the somewhat weak:
> >
> > Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move
> > display
> > to ps8640 auxiliary bus")
>
> I remember I didn't change the compatible to panel-edp because it
> didn't
> work at that time, but it does now... I'm not sure what actually
> fixed that
> and if the commit(s) was/were backported to that suggested point, so
> I
> would leave the Fixes tag out, as that may break older kernel.
Well at least I developed this patch on v6.3.
(In fact the same kernel config do not boot to system at all on
v6.0/v6.1 when I do make olddefconfig then build)
>
> Anyway, for this commit:
>
> Reviewed-by: AngeloGioacchino Del Regno
>
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
在 2023-05-26星期五的 07:24 -0700，Doug Anderson写道：
> Hi,
>
> On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng wrote:
> >
> > Currently a specific panel number is used in the Elm DTSI, which is
> > corresponded to a 12" panel. However, according to the official
> > Chrome
> > OS devices document, Elm refers to Acer Chromebook R13, which, as
> > the
> > name specifies, uses a 13.3" panel, which comes with EDID
> > information.
> >
> > As the kernel currently prioritizes the hardcoded timing parameters
> > matched with the panel number compatible, a wrong timing will be
> > applied
> > to the 13.3" panel on Acer Chromebook R13, which leads to blank
> > display.
> >
> > Because the Elm DTSI is shared with Hana board, and Hana
> > corresponds to
> > multiple devices from 11" to 14", a certain panel model number
> > shouldn't
> > be present, and driving the panel according to its EDID information
> > is
> > necessary.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> We went through a bunch of back-and-forth here but in the end in the
> ChromeOS tree we have "edp-panel" as the "compatible" here in the
> ChromeOS 5.15 tree and this makes sense.
I only have Elm, so I am curious that do all Hana's only rely on panel
EDID to use different displays?
BTW The Chrome OS document say that Elm and Hana are both board based
on Oak baseboard, should the DTSI be renamed mt8173-oak.dtsi, and still
let mt8173-elm.dts include it and then set model information?
>
> Reviewed-by: Douglas Anderson
>
> ...in theory one would wish for a "Fixes" tag, but I think in
> previous
> discussions it was decided that it was too complicated. Hardcoding
> the
> other compatible string has always been technically wrong, but I
> guess
> it worked at some point in time. The more correct way (as you're
> doing
> here) needs the DP AUX bus support and the generic eDP panels, both
> of
> which are significantly newer than the elm dts. So I guess leaving no
> "Fixes" tag is OK, or perhaps you could do the somewhat weak:
Well I remembered when I was developing the support for Pine64
Pinebook, which is also an ARM64 laptop with an eDP panel (via a DPI-
eDP bridge, ANX6345). At first I didn't use any panel node in the DT,
and the kernel maintainers argued to the bridge that seems to be
connected to nothing (because DP is a discoverable port), and
fortunately 2 Pinebook SKUs (11.6" and 14") is finally reduced to one,
and it's then possible to hardcode a panel model in the Pinebook DT.
According to my memory, the need to specify the panel is to properly
handle eDP panel power up timing, because it's not a very standard
thing. (Well, in my memory, when I was testing that code, on a
(engineering sample) 14" Pinebook, the EDID timing overrided the
hardcoded 11.6" timing and it properly works, the 14" panel is 1366x768
but the 11.6" panel is 1920x1080.)
(BTW when I checked the DT of Olimex TERES-I, which uses the same DPI-
eDP bridge, it is still in the status of a dangling bridge, and of
course it works ;-) )
>
> Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move display
> to ps8640 auxiliary bus")
Well this sound quite reasonable, as the kernel should have proper AUX
support at this commit.
[PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
Currently a specific panel number is used in the Elm DTSI, which is
corresponded to a 12" panel. However, according to the official Chrome
OS devices document, Elm refers to Acer Chromebook R13, which, as the
name specifies, uses a 13.3" panel, which comes with EDID information.
As the kernel currently prioritizes the hardcoded timing parameters
matched with the panel number compatible, a wrong timing will be applied
to the 13.3" panel on Acer Chromebook R13, which leads to blank display.
Because the Elm DTSI is shared with Hana board, and Hana corresponds to
multiple devices from 11" to 14", a certain panel model number shouldn't
be present, and driving the panel according to its EDID information is
necessary.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index d452cab28c67..737737528eed 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -285,7 +285,7 @@ ps8640_out: endpoint {
aux-bus {
panel: panel {
- compatible = "lg,lp120up1";
+ compatible = "edp-panel";
power-supply = <_fixed_3v3>;
backlight = <>;
--
2.39.1
Re: [PATCH] drm/sun4i: mixer: fix scanline for V3s and D1
在 2022-05-22星期日的 10:36 +0200，Jernej Škrabec写道：
> Hi!
>
> Dne sobota, 21. maj 2022 ob 15:34:43 CEST je Genfu Pan napisal(a):
> > Accrording the SDK from Allwinner, the scanline value of yuv and
> > rgb for
> > V3s are both 1024.
>
> s/scanline value/scanline length/
>
> Which SDK? All SDKs that I have or found on internet don't mention
> YUV nor RGB
> scanline limit. That doesn't mean there is none, I'm just unable to
> verify
> your claim. Did you test this by yourself? Also, please make YUV
> scanline
> change separate patch with fixes tag.
BTW I think chip manuals all say that the chip supports NxN resolution
in DE2 chapter, e.g. the V3 datasheet says DE2 "Output size up to
1024x1024".
However there's no information about D1's second mixer.
>
> > The is also the same for mixer 1 of D1. Currently the
> > scanline value of rgb is hardcoded to 2048 for all SOCs.
> >
> > Change the scanline_yuv property of V3s to 1024. > Add the
> > scanline_rgb
> > property to the mixer config and replace the hardcoded value with
> > it before
> > scaling.
>
> I guess RGB scanline patch would also need fixes tag, since it fixes
> existing
> bug.
>
> >
> > Signed-off-by: Genfu Pan
> > ---
> > drivers/gpu/drm/sun4i/sun8i_mixer.c | 13 -
> > drivers/gpu/drm/sun4i/sun8i_mixer.h | 1 +
> > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 3 +--
> > 3 files changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > b/drivers/gpu/drm/sun4i/sun8i_mixer.c index 875a1156c..e64e08207
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > @@ -567,6 +567,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_a83t_mixer0_cfg = { .ccsc = CCSC_MIXER0_LAYOUT,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
> > };
> > @@ -575,6 +576,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_a83t_mixer1_cfg = { .ccsc = CCSC_MIXER1_LAYOUT,
> > .scaler_mask= 0x3,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 1,
> > .vi_num = 1,
> > };
> > @@ -584,6 +586,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_h3_mixer0_cfg
> > = { .mod_rate = 43200,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
> > };
> > @@ -593,6 +596,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_r40_mixer0_cfg
> > = { .mod_rate = 29700,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
> > };
> > @@ -602,6 +606,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_r40_mixer1_cfg
> > = { .mod_rate = 29700,
> > .scaler_mask= 0x3,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 1,
> > .vi_num = 1,
> > };
> > @@ -610,7 +615,8 @@ static const struct sun8i_mixer_cfg
> > sun8i_v3s_mixer_cfg
> > = { .vi_num = 2,
> > .ui_num = 1,
> > .scaler_mask = 0x3,
> > - .scanline_yuv = 2048,
> > + .scanline_yuv = 1024,
> > + .scanline_rgb = 1024,
> > .ccsc = CCSC_MIXER0_LAYOUT,
> > .mod_rate = 15000,
> > };
> > @@ -620,6 +626,7 @@ static const struct sun8i_mixer_cfg
> > sun20i_d1_mixer0_cfg
> > = { .mod_rate = 29700,
> > .scaler_mask= 0x3,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 1,
> > .vi_num = 1,
> > };
> > @@ -629,6 +636,7 @@ static const struct sun8i_mixer_cfg
> > sun20i_d1_mixer1_cfg
> > = { .mod_rate = 29700,
> > .scaler_mask= 0x1,
> > .scanline_yuv = 1024,
> > + .scanline_rgb = 1024,
> > .ui_num = 0,
> > .vi_num = 1,
> > };
> > @@ -638,6 +646,7 @@ static const struct sun8i_mixer_cfg
> > sun50i_a64_mixer0_cfg = { .mod_rate = 29700,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 4096,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
> > };
> > @@ -647,6 +656,7 @@ static const struct sun8i_mixer_cfg
> > sun50i_a64_mixer1_cfg = { .mod_rate = 29700,
> > .scaler_mask= 0x3,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 1,
> > .vi_num = 1,
> > };
> > @@ -657,6 +667,7 @@ static const struct sun8i_mixer_cfg
> > sun50i_h6_mixer0_cfg
> > = { .mod_rate = 6,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 4096,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
Re: [PATCH] drm/nouveau/bios: Use HWSQ entry 1 for PowerBook6,1
在 2022-02-14星期一的 11:07 -0500，Ilia Mirkin写道：
> I'm not saying this is wrong, but could you file a bug at
> gitlab.freedesktop.org/drm/nouveau/-/issues and include the VBIOS
> (/sys/kernel/debug/dri/0/vbios.rom)? That would make it easier to
> review the full situation.
Created at https://gitlab.freedesktop.org/drm/nouveau/-/issues/158 .
>
> On Mon, Feb 14, 2022 at 11:03 AM Icenowy Zheng wrote:
> >
> > On PowerBook6,1 (PowerBook G4 867 12") HWSQ entry 0 (which is
> > currently
> > always used by nouveau) fails, but the BIOS declares 2 HWSQ entries
> > and
> > entry 1 works.
> >
> > Add a quirk to use HWSQ entry 1.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > drivers/gpu/drm/nouveau/nouveau_bios.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
> > b/drivers/gpu/drm/nouveau/nouveau_bios.c
> > index e8c445eb11004..2691d0e0cf9f1 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bios.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
> > @@ -1977,6 +1977,13 @@ static int load_nv17_hw_sequencer_ucode(struct
> > drm_device *dev,
> > if (!hwsq_offset)
> > return 0;
> >
> > +#ifdef __powerpc__
> > + /* HWSQ entry 0 fails on PowerBook G4 867 12" (Al) */
> > + if (of_machine_is_compatible("PowerBook6,1"))
> > + return load_nv17_hwsq_ucode_entry(dev, bios,
> > + hwsq_offset + sz,
> > 1);
> > +#endif
> > +
> > /* always use entry 0? */
> > return load_nv17_hwsq_ucode_entry(dev, bios, hwsq_offset +
> > sz, 0);
> > }
> > --
> > 2.30.2
> >
[PATCH] drm/nouveau/bios: Use HWSQ entry 1 for PowerBook6,1
On PowerBook6,1 (PowerBook G4 867 12") HWSQ entry 0 (which is currently
always used by nouveau) fails, but the BIOS declares 2 HWSQ entries and
entry 1 works.
Add a quirk to use HWSQ entry 1.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/nouveau/nouveau_bios.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index e8c445eb11004..2691d0e0cf9f1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -1977,6 +1977,13 @@ static int load_nv17_hw_sequencer_ucode(struct
drm_device *dev,
if (!hwsq_offset)
return 0;
+#ifdef __powerpc__
+ /* HWSQ entry 0 fails on PowerBook G4 867 12" (Al) */
+ if (of_machine_is_compatible("PowerBook6,1"))
+ return load_nv17_hwsq_ucode_entry(dev, bios,
+ hwsq_offset + sz, 1);
+#endif
+
/* always use entry 0? */
return load_nv17_hwsq_ucode_entry(dev, bios, hwsq_offset + sz, 0);
}
--
2.30.2
Re: [PATCH] drm/panel: k101-im2ba02: Make use of the helper function dev_err_probe()
在 2021-09-16星期四的 18:42 +0800，Cai Huoqing写道：
> When possible use dev_err_probe help to properly deal with the
> PROBE_DEFER error, the benefit is that DEFER issue will be logged
> in the devices_deferred debugfs file.
> And using dev_err_probe() can reduce code size, and the error value
> gets printed.
>
> Signed-off-by: Cai Huoqing
Looks good to me, and thanks for pointing out this helper.
Acked-by: Icenowy Zheng
> ---
> drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> index 2a602aee61c3..cb0bb3076099 100644
> --- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> +++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> @@ -456,16 +456,13 @@ static int k101_im2ba02_dsi_probe(struct
> mipi_dsi_device *dsi)
>
> ret = devm_regulator_bulk_get(>dev, ARRAY_SIZE(ctx-
> >supplies),
> ctx->supplies);
> - if (ret < 0) {
> - dev_err(>dev, "Couldn't get regulators\n");
> - return ret;
> - }
> + if (ret < 0)
> + return dev_err_probe(>dev, ret, "Couldn't get
> regulators\n");
>
> ctx->reset = devm_gpiod_get(>dev, "reset",
> GPIOD_OUT_LOW);
> - if (IS_ERR(ctx->reset)) {
> - dev_err(>dev, "Couldn't get our reset GPIO\n");
> - return PTR_ERR(ctx->reset);
> - }
> + if (IS_ERR(ctx->reset))
> + return dev_err_probe(>dev, PTR_ERR(ctx->reset),
> + "Couldn't get our reset
> GPIO\n");
>
> drm_panel_init(>panel, >dev, _im2ba02_funcs,
> DRM_MODE_CONNECTOR_DSI);
Re: [PATCH 3/4] drm/tiny: add simple-dbi driver
在 2021-08-02星期一的 17:08 +0200，Thomas Zimmermann写道：
> Hi
>
> Am 02.08.21 um 08:35 schrieb Icenowy Zheng:
> > Add a driver for generic MIPI DBI panels initialized with MIPI DCS
> > commands.
> >
> > Currently a ST7789V-based panel is added to it. This panel has its
> > configuration pre-programmed into the controller, so no vendor-
> > specific
> > configuration is needed.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > drivers/gpu/drm/tiny/Kconfig | 12 ++
> > drivers/gpu/drm/tiny/Makefile | 1 +
> > drivers/gpu/drm/tiny/simple-dbi.c | 244
> > ++
> > 3 files changed, 257 insertions(+)
> > create mode 100644 drivers/gpu/drm/tiny/simple-dbi.c
> >
> > diff --git a/drivers/gpu/drm/tiny/Kconfig
> > b/drivers/gpu/drm/tiny/Kconfig
> > index d31be274a2bd..6cfc57b68a46 100644
> > --- a/drivers/gpu/drm/tiny/Kconfig
> > +++ b/drivers/gpu/drm/tiny/Kconfig
> > @@ -144,6 +144,18 @@ config TINYDRM_REPAPER
> >
> > If M is selected the module will be called repaper.
> >
> > +config TINYDRM_SIMPLE_DBI
> > + tristate "DRM support for generic MIPI DBI panels"
> > + depends on DRM && SPI
> > + select DRM_KMS_HELPER
> > + select DRM_KMS_CMA_HELPER
> > + select DRM_MIPI_DBI
> > + help
> > + DRM driver for generic DBI panels that are MIPI DCS
> > compatible
> > + and needs no vendor-specific setup commands.
> > +
> > + If M is selected the module will be called simple-dbi.
> > +
> > config TINYDRM_ST7586
> > tristate "DRM support for Sitronix ST7586 display panels"
> > depends on DRM && SPI
> > diff --git a/drivers/gpu/drm/tiny/Makefile
> > b/drivers/gpu/drm/tiny/Makefile
> > index e09942895c77..2553de651aa3 100644
> > --- a/drivers/gpu/drm/tiny/Makefile
> > +++ b/drivers/gpu/drm/tiny/Makefile
> > @@ -13,3 +13,4 @@ obj-$(CONFIG_TINYDRM_MI0283QT)+=
> > mi0283qt.o
> > obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
> > obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
> > obj-$(CONFIG_TINYDRM_ST7735R) += st7735r.o
> > +obj-$(CONFIG_TINYDRM_SIMPLE_DBI) += simple-dbi.o
> > diff --git a/drivers/gpu/drm/tiny/simple-dbi.c
> > b/drivers/gpu/drm/tiny/simple-dbi.c
> > new file mode 100644
> > index ..2b207e43d500
> > --- /dev/null
> > +++ b/drivers/gpu/drm/tiny/simple-dbi.c
> > @@ -0,0 +1,244 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * DRM driver for display panels with configuration preset and
> > needs only
> > + * standard MIPI DCS commands to bring up.
> > + *
> > + * Copyright (C) 2021 Sipeed
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MIPI_DCS_ADDRESS_MODE_BGR BIT(3)
> > +#define MIPI_DCS_ADDRESS_MODE_REVERSE BIT(5)
> > +#define MIPI_DCS_ADDRESS_MODE_RTL BIT(6)
> > +#define MIPI_DCS_ADDRESS_MODE_BTT BIT(7)
> > +
> > +struct simple_dbi_cfg {
> > + const struct drm_display_mode mode;
> > + unsigned int left_offset;
> > + unsigned int top_offset;
> > + bool inverted;
> > + bool write_only;
> > + bool bgr;
> > + bool right_to_left;
> > + bool bottom_to_top;
> > +};
> > +
> > +struct simple_dbi_priv {
> > + struct mipi_dbi_dev dbidev; /* Must be first for
> > .release() */
>
> Which release?
Ah, some copy-n-paste waste.
Will drop this in v2.
>
> > + const struct simple_dbi_cfg *cfg;
> > +};
> > +
> > +static void simple_dbi_pipe_enable(struct drm_simple_display_pipe
> > *pipe,
> > + struct drm_crtc_state *crtc_state,
> > + struct drm_plane_state
> > *plane_state)
> > +{
> > + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe-
> > >crtc.dev);
> > + struct simple_dbi_priv *priv = container_of(dbidev,
> > + struct
> > simple_dbi_priv,
> > + dbidev);
> > +
Re: [PATCH 3/4] drm/tiny: add simple-dbi driver
在 2021-08-02星期一的 14:35 +0800，Icenowy Zheng写道：
> Add a driver for generic MIPI DBI panels initialized with MIPI DCS
> commands.
>
> Currently a ST7789V-based panel is added to it. This panel has its
> configuration pre-programmed into the controller, so no vendor-
> specific
> configuration is needed.
>
> Signed-off-by: Icenowy Zheng
> ---
> drivers/gpu/drm/tiny/Kconfig | 12 ++
> drivers/gpu/drm/tiny/Makefile | 1 +
> drivers/gpu/drm/tiny/simple-dbi.c | 244
> ++
> 3 files changed, 257 insertions(+)
> create mode 100644 drivers/gpu/drm/tiny/simple-dbi.c
>
> diff --git a/drivers/gpu/drm/tiny/Kconfig
> b/drivers/gpu/drm/tiny/Kconfig
> index d31be274a2bd..6cfc57b68a46 100644
> --- a/drivers/gpu/drm/tiny/Kconfig
> +++ b/drivers/gpu/drm/tiny/Kconfig
> @@ -144,6 +144,18 @@ config TINYDRM_REPAPER
>
> If M is selected the module will be called repaper.
>
> +config TINYDRM_SIMPLE_DBI
> + tristate "DRM support for generic MIPI DBI panels"
> + depends on DRM && SPI
> + select DRM_KMS_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_MIPI_DBI
> + help
> + DRM driver for generic DBI panels that are MIPI DCS
> compatible
> + and needs no vendor-specific setup commands.
> +
> + If M is selected the module will be called simple-dbi.
> +
> config TINYDRM_ST7586
> tristate "DRM support for Sitronix ST7586 display panels"
> depends on DRM && SPI
> diff --git a/drivers/gpu/drm/tiny/Makefile
> b/drivers/gpu/drm/tiny/Makefile
> index e09942895c77..2553de651aa3 100644
> --- a/drivers/gpu/drm/tiny/Makefile
> +++ b/drivers/gpu/drm/tiny/Makefile
> @@ -13,3 +13,4 @@ obj-$(CONFIG_TINYDRM_MI0283QT)+=
> mi0283qt.o
> obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
> obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
> obj-$(CONFIG_TINYDRM_ST7735R) += st7735r.o
> +obj-$(CONFIG_TINYDRM_SIMPLE_DBI) += simple-dbi.o
> diff --git a/drivers/gpu/drm/tiny/simple-dbi.c
> b/drivers/gpu/drm/tiny/simple-dbi.c
> new file mode 100644
> index ..2b207e43d500
> --- /dev/null
> +++ b/drivers/gpu/drm/tiny/simple-dbi.c
> @@ -0,0 +1,244 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * DRM driver for display panels with configuration preset and needs
> only
> + * standard MIPI DCS commands to bring up.
> + *
> + * Copyright (C) 2021 Sipeed
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MIPI_DCS_ADDRESS_MODE_BGR BIT(3)
> +#define MIPI_DCS_ADDRESS_MODE_REVERSE BIT(5)
> +#define MIPI_DCS_ADDRESS_MODE_RTL BIT(6)
> +#define MIPI_DCS_ADDRESS_MODE_BTT BIT(7)
> +
> +struct simple_dbi_cfg {
> + const struct drm_display_mode mode;
> + unsigned int left_offset;
> + unsigned int top_offset;
> + bool inverted;
> + bool write_only;
> + bool bgr;
> + bool right_to_left;
> + bool bottom_to_top;
> +};
> +
> +struct simple_dbi_priv {
> + struct mipi_dbi_dev dbidev; /* Must be first for
> .release() */
> + const struct simple_dbi_cfg *cfg;
> +};
> +
> +static void simple_dbi_pipe_enable(struct drm_simple_display_pipe
> *pipe,
> + struct drm_crtc_state *crtc_state,
> + struct drm_plane_state *plane_state)
> +{
> + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe-
> >crtc.dev);
> + struct simple_dbi_priv *priv = container_of(dbidev,
> + struct
> simple_dbi_priv,
> + dbidev);
> + struct mipi_dbi *dbi = >dbi;
> + int ret, idx;
> + u8 addr_mode = 0x00;
> +
> + if (!drm_dev_enter(pipe->crtc.dev, ))
> + return;
> +
> + DRM_DEBUG_KMS("\n");
> +
> + ret = mipi_dbi_poweron_reset(dbidev);
> + if (ret)
> + goto out_exit;
> +
> + mipi_dbi_command(dbi, MIPI_DCS_EXIT_SLEEP_MODE);
> + msleep(5);
> +
> + /* Currently tinydrm supports 16bit only now */
> + mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT,
> + MIPI_DCS_PIXEL_FMT_16BIT);
> +
> + if (priv->cfg->inverted)
> + mipi_dbi_command(dbi, MIPI_DCS_ENTER_INVERT_MODE)
[PATCH 4/4] MAINTAINERS: add simple-dbi driver
As I pushed the simple-dbi driver, add myself as the maintainer now. Signed-off-by: Icenowy Zheng --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3a00771b9fe2..e05c4910c062 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5803,6 +5803,13 @@ S: Maintained F: Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c +DRM DRIVER FOR GENERIC MIPI-DBI LCD PANELS +M: Icenowy Zheng +S: Maintained +T: git git://anongit.freedesktop.org/drm/drm-misc +F: Documentation/devicetree/bindings/display/simple-dbi.yaml +F: drivers/gpu/drm/tiny/simple-dbi.c + DRM DRIVER FOR GENERIC USB DISPLAY M: Noralf Trønnes S: Maintained -- 2.30.2
[PATCH 2/4] dt-bindings: display: add binding for simple-dbi panels
As we're going to introduce a driver for MIPI DBI panels that need only
standard MIPI-DCS commands to initialize (usually because the controller
has some configuration pre-programmed), add a DT binding file for it,
which now includes only one DBI Type C Option 3 panel, ZSX154-B1206.
Signed-off-by: Icenowy Zheng
---
.../bindings/display/simple-dbi.yaml | 72 +++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/simple-dbi.yaml
diff --git a/Documentation/devicetree/bindings/display/simple-dbi.yaml
b/Documentation/devicetree/bindings/display/simple-dbi.yaml
new file mode 100644
index ..f49b0fda0935
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/simple-dbi.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/simple-dbi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic MIPI DCS-compatible DBI panels Device Tree Bindings
+
+maintainers:
+ - Icenowy Zheng
+
+description:
+ This binding is for display panels that utilizes MIPI DBI Type C, follows
+ MIPI DCS and needs no vendor-specific initialization commands.
+
+properties:
+ compatible:
+oneOf:
+ - description:
+ Zhishengxin ZSX154-B1206 1.54" 240x240 SPI LCD
+items:
+ - const: zsx,zsx154-b1206
+
+ spi-max-frequency:
+maximum: 3000
+
+ dc-gpios:
+maxItems: 1
+description: Display data/command selection (D/CX)
+
+ backlight: true
+ reg: true
+ reset-gpios: true
+ rotation: true
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: panel/panel-common.yaml#
+ - if:
+ properties:
+compatible:
+ contains:
+const: zsx,zsx154-b1206
+
+then:
+ required:
+- dc-gpios
+- reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+display@0 {
+compatible = "zsx,zsx154-b1206";
+reg = <0>;
+spi-max-frequency = <3000>;
+dc-gpios = < 7 4 GPIO_ACTIVE_HIGH>;
+reset-gpios = <_pio 2 21 GPIO_ACTIVE_HIGH>;
+};
+};
+
+...
--
2.30.2
[PATCH 1/4] dt-bindings: vendor-prefixes: add Zhishengxin
Shenzhen Zhishengxin Technology Co., Ltd. is a LCD module supplier. Add vendor prefix for it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 62cb1d9341f5..d8fdec851f38 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1334,6 +1334,8 @@ patternProperties: description: Zinitix Co., Ltd "^zkmagic,.*": description: Shenzhen Zkmagic Technology Co., Ltd. + "^zsx,.*": +description: Shenzhen Zhishengxin Technology Co., Ltd. "^zte,.*": description: ZTE Corp. "^zyxel,.*": -- 2.30.2
[PATCH 0/4] Add simple-dbi tinydrm driver
This patchset adds a tinydrm driver called simple-dbi, which is a driver that utilizes only standardized commands in MIPI DCS to activate a MIPI DBI panel that requires no extra configuration, usually because the configuration is pre-programmed into the OTP of the LCD controller. Icenowy Zheng (4): dt-bindings: vendor-prefixes: add Zhishengxin dt-bindings: display: add binding for simple-dbi panels drm/tiny: add simple-dbi driver MAINTAINERS: add simple-dbi driver .../bindings/display/simple-dbi.yaml | 72 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 7 + drivers/gpu/drm/tiny/Kconfig | 12 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/simple-dbi.c | 244 ++ 6 files changed, 338 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/simple-dbi.yaml create mode 100644 drivers/gpu/drm/tiny/simple-dbi.c -- 2.30.2
[PATCH 3/4] drm/tiny: add simple-dbi driver
Add a driver for generic MIPI DBI panels initialized with MIPI DCS
commands.
Currently a ST7789V-based panel is added to it. This panel has its
configuration pre-programmed into the controller, so no vendor-specific
configuration is needed.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/tiny/Kconfig | 12 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/simple-dbi.c | 244 ++
3 files changed, 257 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/simple-dbi.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index d31be274a2bd..6cfc57b68a46 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -144,6 +144,18 @@ config TINYDRM_REPAPER
If M is selected the module will be called repaper.
+config TINYDRM_SIMPLE_DBI
+ tristate "DRM support for generic MIPI DBI panels"
+ depends on DRM && SPI
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DBI
+ help
+ DRM driver for generic DBI panels that are MIPI DCS compatible
+ and needs no vendor-specific setup commands.
+
+ If M is selected the module will be called simple-dbi.
+
config TINYDRM_ST7586
tristate "DRM support for Sitronix ST7586 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index e09942895c77..2553de651aa3 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_TINYDRM_MI0283QT)+= mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
obj-$(CONFIG_TINYDRM_ST7735R) += st7735r.o
+obj-$(CONFIG_TINYDRM_SIMPLE_DBI) += simple-dbi.o
diff --git a/drivers/gpu/drm/tiny/simple-dbi.c
b/drivers/gpu/drm/tiny/simple-dbi.c
new file mode 100644
index ..2b207e43d500
--- /dev/null
+++ b/drivers/gpu/drm/tiny/simple-dbi.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for display panels with configuration preset and needs only
+ * standard MIPI DCS commands to bring up.
+ *
+ * Copyright (C) 2021 Sipeed
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MIPI_DCS_ADDRESS_MODE_BGR BIT(3)
+#define MIPI_DCS_ADDRESS_MODE_REVERSE BIT(5)
+#define MIPI_DCS_ADDRESS_MODE_RTL BIT(6)
+#define MIPI_DCS_ADDRESS_MODE_BTT BIT(7)
+
+struct simple_dbi_cfg {
+ const struct drm_display_mode mode;
+ unsigned int left_offset;
+ unsigned int top_offset;
+ bool inverted;
+ bool write_only;
+ bool bgr;
+ bool right_to_left;
+ bool bottom_to_top;
+};
+
+struct simple_dbi_priv {
+ struct mipi_dbi_dev dbidev; /* Must be first for .release() */
+ const struct simple_dbi_cfg *cfg;
+};
+
+static void simple_dbi_pipe_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state,
+ struct drm_plane_state *plane_state)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+ struct simple_dbi_priv *priv = container_of(dbidev,
+ struct simple_dbi_priv,
+ dbidev);
+ struct mipi_dbi *dbi = >dbi;
+ int ret, idx;
+ u8 addr_mode = 0x00;
+
+ if (!drm_dev_enter(pipe->crtc.dev, ))
+ return;
+
+ DRM_DEBUG_KMS("\n");
+
+ ret = mipi_dbi_poweron_reset(dbidev);
+ if (ret)
+ goto out_exit;
+
+ mipi_dbi_command(dbi, MIPI_DCS_EXIT_SLEEP_MODE);
+ msleep(5);
+
+ /* Currently tinydrm supports 16bit only now */
+ mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT,
+MIPI_DCS_PIXEL_FMT_16BIT);
+
+ if (priv->cfg->inverted)
+ mipi_dbi_command(dbi, MIPI_DCS_ENTER_INVERT_MODE);
+ else
+ mipi_dbi_command(dbi, MIPI_DCS_EXIT_INVERT_MODE);
+
+ if (priv->cfg->bgr)
+ addr_mode |= MIPI_DCS_ADDRESS_MODE_BGR;
+
+ if (priv->cfg->right_to_left)
+ addr_mode |= MIPI_DCS_ADDRESS_MODE_RTL;
+
+ if (priv->cfg->bottom_to_top)
+ addr_mode |= MIPI_DCS_ADDRESS_MODE_BTT;
+
+ switch (dbidev->rotation) {
+ default:
+ break;
+ case 90:
+ addr_mode ^= MIPI_DCS_ADDRESS_MODE_REVERSE;
+ addr_mode ^= MIPI_DCS_ADDRESS_MODE_RTL;
+ break;
+ case 180:
+ addr_mode ^= MIPI_DCS_ADDRESS_MODE_RTL;
+ addr_mode ^= MIPI_DCS_ADDRESS_MODE_BTT;
+ b
[PATCH] drm/rockchip: kick firmware-based framebuffer when initializing
Since U-Boot now supports EFI and FB passing via EFI GOP, when booting rockchip SoCs via EFI, a EFI FB is available. However, currently when re-initializing display pipeline, the EFI FB is not removed, lead to fbcon not working (because the EFI FB is no longer bound to the display pipeline although it's still /dev/fb0 and fbcon is bound to it). Add some code for removing firmware-based FB when initializing KMS of rockchipdrm. Tested on Pinebook Pro (RK3399) with U-Boot patchset for initializing eDP display applied. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index 212bd87c0c4a..3905fce6ce0b 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -158,6 +158,9 @@ static int rockchip_drm_bind(struct device *dev) */ drm_dev->irq_enabled = true; + /* Remove early framebuffers (ie. efifb) */ + drm_fb_helper_remove_conflicting_framebuffers(NULL, "rockchipdrmfb", false); + ret = rockchip_drm_fbdev_init(drm_dev); if (ret) goto err_unbind_all; -- 2.30.2
Re: [PATCH] drm/panel: feiyang-fy07024di26a30d: cleanup if panel attaching failed
于 2021年1月6日 GMT+08:00 下午5:47:20, Jagan Teki 写到:
>On Sat, Nov 28, 2020 at 6:23 PM Icenowy Zheng wrote:
>>
>> Attaching the panel can fail, so cleanup work is necessary, otherwise
>> a pointer to freed struct drm_panel* will remain in drm_panel code.
>>
>> Do the cleanup if panel attaching failed.
>>
>> Fixes: 69dc678abc2b ("drm/panel: Add Feiyang FY07024DI26A30-D
>MIPI-DSI LCD panel")
>
>The fact that this has failed to probe due to recent changes in
>sun6i_mipi_dsi.c I don't know how to put that into the commit message.
It's not related, we shouldn't assume this panel driver will always
be used with sunxi SoCs.
It's a panel driver bug that cannot deal with -EPROBE_DEFER well.
>> Signed-off-by: Icenowy Zheng
>> ---
>
>Reviewed-by: Jagan Teki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: ilitek-ili9881c: fix attach failure cleanup
When mipi_dsi_attach() fails (e.g. got a -EPROBE_DEFER), the panel should
be removed, otherwise a pointer to it will be kept and then lead to
use-after-free when DRM panel codes are called (e.g. the panel is probed
again).
Fix this by adding cleanup code after mipi_dsi_attach() failure.
Fixes: 26aec25593c2 ("drm/panel: Add Ilitek ILI9881c panel driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 0145129d7c66..22f2268f00f7 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -674,7 +674,13 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->lanes = 4;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_panel_remove(>panel);
+ return ret;
+ }
+
+ return 0;
}
static int ili9881c_dsi_remove(struct mipi_dsi_device *dsi)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: feiyang-fy07024di26a30d: cleanup if panel attaching failed
Attaching the panel can fail, so cleanup work is necessary, otherwise
a pointer to freed struct drm_panel* will remain in drm_panel code.
Do the cleanup if panel attaching failed.
Fixes: 69dc678abc2b ("drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD
panel")
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index 581661b506f8..f9c1f7bc8218 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -227,7 +227,13 @@ static int feiyang_dsi_probe(struct mipi_dsi_device *dsi)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->lanes = 4;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_panel_remove(>panel);
+ return ret;
+ }
+
+ return 0;
}
static int feiyang_dsi_remove(struct mipi_dsi_device *dsi)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] dt-bindings: ili9881c: add compatible string for Feixin K101-IM2BYL02
Feixin K101-IM2BYL02 is a drop-in replacement of K101-IM2BA02 panel (which is already supported by panel-feixin-k101-im2ba02 driver) with the same pinout. It utilizes an Ilitek ILI9881C controller chip, so its compatible string should be added to ilitek,ili9881c file. Add the compatible string for it. Signed-off-by: Icenowy Zheng --- .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml index a39332276bab2..c60b3bd74337e 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml @@ -14,6 +14,7 @@ properties: items: - enum: - bananapi,lhr050h41 +- feixin,k101-im2byl02 - const: ilitek,ili9881c -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/panel: ilitek-ili9881c: prepare for adding support for extra panels
There're more panels with ILI9881C controller than the Bananapi one
supported by this driver.
Extract the mode and init sequence part, to prepare the driver for
adding new panels.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 56 ---
1 file changed, 37 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 3ed8635a6fbdf..4f8e6865029f1 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -20,14 +21,6 @@
#include
-struct ili9881c {
- struct drm_panelpanel;
- struct mipi_dsi_device *dsi;
-
- struct regulator*power;
- struct gpio_desc*reset;
-};
-
enum ili9881c_op {
ILI9881C_SWITCH_PAGE,
ILI9881C_COMMAND,
@@ -45,6 +38,21 @@ struct ili9881c_instr {
} arg;
};
+struct ili9881c_desc {
+ const struct ili9881c_instr *init;
+ const size_t init_length;
+ const struct drm_display_mode *mode;
+};
+
+struct ili9881c {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+ const struct ili9881c_desc *desc;
+
+ struct regulator*power;
+ struct gpio_desc*reset;
+};
+
#define ILI9881C_SWITCH_PAGE_INSTR(_page) \
{ \
.op = ILI9881C_SWITCH_PAGE, \
@@ -64,7 +72,7 @@ struct ili9881c_instr {
}, \
}
-static const struct ili9881c_instr ili9881c_init[] = {
+static const struct ili9881c_instr lhr050h41_init[] = {
ILI9881C_SWITCH_PAGE_INSTR(3),
ILI9881C_COMMAND_INSTR(0x01, 0x00),
ILI9881C_COMMAND_INSTR(0x02, 0x00),
@@ -311,8 +319,8 @@ static int ili9881c_prepare(struct drm_panel *panel)
gpiod_set_value(ctx->reset, 0);
msleep(20);
- for (i = 0; i < ARRAY_SIZE(ili9881c_init); i++) {
- const struct ili9881c_instr *instr = _init[i];
+ for (i = 0; i < ctx->desc->init_length; i++) {
+ const struct ili9881c_instr *instr = >desc->init[i];
if (instr->op == ILI9881C_SWITCH_PAGE)
ret = ili9881c_switch_page(ctx, instr->arg.page);
@@ -368,7 +376,7 @@ static int ili9881c_unprepare(struct drm_panel *panel)
return 0;
}
-static const struct drm_display_mode bananapi_default_mode = {
+static const struct drm_display_mode lhr050h41_default_mode = {
.clock = 62000,
.hdisplay = 720,
@@ -380,6 +388,9 @@ static const struct drm_display_mode bananapi_default_mode
= {
.vsync_start= 1280 + 10,
.vsync_end = 1280 + 10 + 10,
.vtotal = 1280 + 10 + 10 + 20,
+
+ .width_mm = 62,
+ .height_mm = 110,
};
static int ili9881c_get_modes(struct drm_panel *panel,
@@ -388,12 +399,12 @@ static int ili9881c_get_modes(struct drm_panel *panel,
struct ili9881c *ctx = panel_to_ili9881c(panel);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, _default_mode);
+ mode = drm_mode_duplicate(connector->dev, ctx->desc->mode);
if (!mode) {
dev_err(>dsi->dev, "failed to add mode %ux%ux@%u\n",
- bananapi_default_mode.hdisplay,
- bananapi_default_mode.vdisplay,
- drm_mode_vrefresh(_default_mode));
+ ctx->desc->mode->hdisplay,
+ ctx->desc->mode->vdisplay,
+ drm_mode_vrefresh(ctx->desc->mode));
return -ENOMEM;
}
@@ -402,8 +413,8 @@ static int ili9881c_get_modes(struct drm_panel *panel,
mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
- connector->display_info.width_mm = 62;
- connector->display_info.height_mm = 110;
+ connector->display_info.width_mm = mode->width_mm;
+ connector->display_info.height_mm = mode->height_mm;
return 1;
}
@@ -426,6 +437,7 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
return -ENOMEM;
mipi_dsi_set_drvdata(dsi, ctx);
ctx->dsi = dsi;
+ ctx->desc = of_device_get_match_data(>dev);
drm_panel_init(>panel, >dev, _funcs,
DRM_MODE_CONNECTOR_DSI);
@@ -467,8 +479,14 @@ static int ili9881c_dsi_remove(struct mipi_dsi_device *dsi)
return 0;
}
+static const struct ili9881c_desc lhr050h41_desc = {
+ .init = lhr050h41_init,
+ .init_length = ARRAY_SIZE(lhr050h41_init),
+ .mode = _default_mode,
+};
+
static cons
[PATCH 3/4] drm/panel: ilitek-ili9881c: add support for Feixin K101-IM2BYL02 panel
Feixin K101-IM2BYL02 is a new panel by Feixin designed as a replacement
to their K101-IM2BA02 panel. This panel utilizes the Ilitek ILI9881C
controller.
Add this panel's initialzation sequence and timing to ILI9881C driver.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 217 ++
1 file changed, 217 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 4f8e6865029f1..638108c519f02 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -260,6 +260,199 @@ static const struct ili9881c_instr lhr050h41_init[] = {
ILI9881C_COMMAND_INSTR(0xD3, 0x3F),
};
+static const struct ili9881c_instr k101_im2byl02_init[] = {
+ ILI9881C_SWITCH_PAGE_INSTR(3),
+ ILI9881C_COMMAND_INSTR(0x01, 0x00),
+ ILI9881C_COMMAND_INSTR(0x02, 0x00),
+ ILI9881C_COMMAND_INSTR(0x03, 0x73),
+ ILI9881C_COMMAND_INSTR(0x04, 0x00),
+ ILI9881C_COMMAND_INSTR(0x05, 0x00),
+ ILI9881C_COMMAND_INSTR(0x06, 0x08),
+ ILI9881C_COMMAND_INSTR(0x07, 0x00),
+ ILI9881C_COMMAND_INSTR(0x08, 0x00),
+ ILI9881C_COMMAND_INSTR(0x09, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0A, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0B, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0C, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0D, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0E, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0F, 0x00),
+ ILI9881C_COMMAND_INSTR(0x10, 0x00),
+ ILI9881C_COMMAND_INSTR(0x11, 0x00),
+ ILI9881C_COMMAND_INSTR(0x12, 0x00),
+ ILI9881C_COMMAND_INSTR(0x13, 0x00),
+ ILI9881C_COMMAND_INSTR(0x14, 0x00),
+ ILI9881C_COMMAND_INSTR(0x15, 0x00),
+ ILI9881C_COMMAND_INSTR(0x16, 0x00),
+ ILI9881C_COMMAND_INSTR(0x17, 0x00),
+ ILI9881C_COMMAND_INSTR(0x18, 0x00),
+ ILI9881C_COMMAND_INSTR(0x19, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1A, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1B, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1C, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1D, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1E, 0x40),
+ ILI9881C_COMMAND_INSTR(0x1F, 0xC0),
+ ILI9881C_COMMAND_INSTR(0x20, 0x06),
+ ILI9881C_COMMAND_INSTR(0x21, 0x01),
+ ILI9881C_COMMAND_INSTR(0x22, 0x06),
+ ILI9881C_COMMAND_INSTR(0x23, 0x01),
+ ILI9881C_COMMAND_INSTR(0x24, 0x88),
+ ILI9881C_COMMAND_INSTR(0x25, 0x88),
+ ILI9881C_COMMAND_INSTR(0x26, 0x00),
+ ILI9881C_COMMAND_INSTR(0x27, 0x00),
+ ILI9881C_COMMAND_INSTR(0x28, 0x3B),
+ ILI9881C_COMMAND_INSTR(0x29, 0x03),
+ ILI9881C_COMMAND_INSTR(0x2A, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2B, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2C, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2D, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2E, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2F, 0x00),
+ ILI9881C_COMMAND_INSTR(0x30, 0x00),
+ ILI9881C_COMMAND_INSTR(0x31, 0x00),
+ ILI9881C_COMMAND_INSTR(0x32, 0x00),
+ ILI9881C_COMMAND_INSTR(0x33, 0x00),
+ ILI9881C_COMMAND_INSTR(0x34, 0x00), /* GPWR1/2 non overlap time 2.62us
*/
+ ILI9881C_COMMAND_INSTR(0x35, 0x00),
+ ILI9881C_COMMAND_INSTR(0x36, 0x00),
+ ILI9881C_COMMAND_INSTR(0x37, 0x00),
+ ILI9881C_COMMAND_INSTR(0x38, 0x00),
+ ILI9881C_COMMAND_INSTR(0x39, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3A, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3B, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3C, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3D, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3E, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3F, 0x00),
+ ILI9881C_COMMAND_INSTR(0x40, 0x00),
+ ILI9881C_COMMAND_INSTR(0x41, 0x00),
+ ILI9881C_COMMAND_INSTR(0x42, 0x00),
+ ILI9881C_COMMAND_INSTR(0x43, 0x00),
+ ILI9881C_COMMAND_INSTR(0x44, 0x00),
+ ILI9881C_COMMAND_INSTR(0x50, 0x01),
+ ILI9881C_COMMAND_INSTR(0x51, 0x23),
+ ILI9881C_COMMAND_INSTR(0x52, 0x45),
+ ILI9881C_COMMAND_INSTR(0x53, 0x67),
+ ILI9881C_COMMAND_INSTR(0x54, 0x89),
+ ILI9881C_COMMAND_INSTR(0x55, 0xAB),
+ ILI9881C_COMMAND_INSTR(0x56, 0x01),
+ ILI9881C_COMMAND_INSTR(0x57, 0x23),
+ ILI9881C_COMMAND_INSTR(0x58, 0x45),
+ ILI9881C_COMMAND_INSTR(0x59, 0x67),
+ ILI9881C_COMMAND_INSTR(0x5A, 0x89),
+ ILI9881C_COMMAND_INSTR(0x5B, 0xAB),
+ ILI9881C_COMMAND_INSTR(0x5C, 0xCD),
+ ILI9881C_COMMAND_INSTR(0x5D, 0xEF),
+ ILI9881C_COMMAND_INSTR(0x5E, 0x00),
+ ILI9881C_COMMAND_INSTR(0x5F, 0x01),
+ ILI9881C_COMMAND_INSTR(0x60, 0x01),
+ ILI9881C_COMMAND_INSTR(0x61, 0x06),
+ ILI9881C_COMMAND_INSTR(0x62, 0x06),
+ ILI9881C_COMMAND_INSTR(0x63, 0x07),
+ ILI9881C_COMMAND_INSTR(0x64, 0x07),
+ ILI9881C_COMMAND_INSTR(0x65, 0x00),
+ ILI9881C_COMMAND_INSTR(0x66, 0x00),
+ ILI9881C_COMMAND_INSTR(0x67, 0x02),
+ ILI9881C_COMMAND_INSTR(0x68, 0x02
[PATCH 0/4] Add support for Feixin K101-IM2BYL02 panel
The controller chip of Feixin K101-IM2BA02 is going to be discontinued, so Feixin start to provide K101-IM2BYL02 panel as a replacement, which utilizes Ilitek ILI9881C controller. Add support for K101-IM2BYL02 panel. By the way, is there a way that can try both kind of panels in the same kernel/DTB combo? K101-IM2BYL02 has the same pinout with K101-IM2BA02, and PineTab schedule to switch to it w/o modifying the mainboard. Icenowy Zheng (4): drm/panel: ilitek-ili9881c: prepare for adding support for extra panels dt-bindings: ili9881c: add compatible string for Feixin K101-IM2BYL02 drm/panel: ilitek-ili9881c: add support for Feixin K101-IM2BYL02 panel [DO NOT MERGE] arm64: allwinner: dts: a64: enable K101-IM2BYL02 panel for PineTab .../display/panel/ilitek,ili9881c.yaml| 1 + .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 10 + drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 273 -- 3 files changed, 265 insertions(+), 19 deletions(-) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] [DO NOT MERGE] arm64: allwinner: dts: a64: enable K101-IM2BYL02 panel for PineTab
Newer PineTab may switch to K101-IM2BYL02.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
index dc4ab6b434f97..15c4f5b5b17a7 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -152,6 +152,7 @@ {
vcc-dsi-supply = <_dldo1>;
status = "okay";
+#if 0
panel@0 {
compatible = "feixin,k101-im2ba02";
reg = <0>;
@@ -161,6 +162,15 @@ panel@0 {
reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
backlight = <>;
};
+#endif
+
+ panel@0 {
+ compatible = "feixin,k101-im2byl02";
+ reg = <0>;
+ power-supply = <_dc1sw>;
+ reset-gpios = < 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+ backlight = <>;
+ };
};
{
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 13/13] arm64: dts: sun50i-a64-pinephone: Add touchscreen support
于 2020年7月1日 GMT+08:00 下午6:31:26, Ondrej Jirman 写到:
>Pinephone has a Goodix GT917S capacitive touchscreen controller on
>I2C0 bus. Add support for it.
>
>Signed-off-by: Ondrej Jirman
>Acked-by: Linus Walleij
>---
> .../dts/allwinner/sun50i-a64-pinephone.dtsi | 19 +++
> 1 file changed, 19 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
>index 85a7aa5efd32..2d5694446d17 100644
>--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
>+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
>@@ -123,6 +123,25 @@ {
> status = "okay";
> };
>
>+ {
>+ pinctrl-names = "default";
>+ pinctrl-0 = <_pins>;
>+ status = "okay";
>+
>+ touchscreen@5d {
>+ compatible = "goodix,gt917s", "goodix,gt911";
Please drop gt911 here. GT917S belong to the GT1x product line, not the same
line with GT911.
You will see this in the driver.
>+ reg = <0x5d>;
>+ interrupt-parent = <>;
>+ interrupts = <7 4 IRQ_TYPE_LEVEL_HIGH>; /* PH4 */
>+ irq-gpios = < 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
>+ reset-gpios = < 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
>+ AVDD28-supply = <_ldo_io0>;
>+ VDDIO-supply = <_ldo_io0>;
>+ touchscreen-size-x = <720>;
>+ touchscreen-size-y = <1440>;
>+ };
>+};
>+
> {
> status = "okay";
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
于 2020年3月20日 GMT+08:00 下午5:11:22, Linus Walleij 写到: >On Fri, Mar 20, 2020 at 9:07 AM Icenowy Zheng wrote: >> 于 2020年3月19日 GMT+08:00 下午10:14:27, Linus Walleij > 写到: >> >On Mon, Mar 16, 2020 at 2:37 PM Icenowy Zheng >wrote: > >> >As noticed in the review of the driver, this display is very close >to >> >himax,hx8363. >> > >> >I think the best is to determin what actual display controller it >is, >> >I think it is some kind of Ilitek controller since Ilitek ili9342 is >> >clearly very similar. >> >> It's Sitronix ST7703, same as the Librem 5 panel. > >Heh, I wonder how it comes that it is so similar to Ilitek. >I guess I will never understand how the silicon ecosystem works >in asia (I did read a lot of Bunnie Huang's articles and hardware >hacking book to try to understand...) > >This file should be named sitronix,st7703.yaml then. > >According to the code in the Librem 5: >https://source.puri.sm/Librem5/linux-next/blob/imx8-current-librem5/drivers/gpu/drm/panel/panel-sitronix-st7701.c >The actual name of the display is Techstar ts8550b. Sorry, for Librem 5 panel, I mean Rocktech JH057N00900 here. This is also the code that my patchset based on. >And the display controller is st7701, so maybe we should >actually name it sitronix,st770x.yaml if there are some >sub-variants of st770x? > >> >properties: >> > compatible: >> >items: >> > - const: xingbangda,xbd599 >> > - const: ilitek,ili9342 >> > >> >Possibly use oneOf and add support for the himax,hx8363 >> >already while you're at it. > >This should at least be: > >compatible: > items: > - enum: > - xingbangda,xbd599 > - himax,hx8363 > - techstar,ts8550b > - enum: > - sitronix,st7701 > - sitronix,st7703 > >So panel nodes using this panel become >compatible = "xingbangda,sbd599", "sitronix,st7703" >etc. > >This way it is straight-forward for drivers to identify the panel >vendor and display controller. > >Yours, >Linus Walleij > >___ >linux-arm-kernel mailing list >linux-arm-ker...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 使用 K-9 Mail 发送自我的Android设备。 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
于 2020年3月19日 GMT+08:00 下午10:14:27, Linus Walleij 写到: >Hi Icenowy, > >On Mon, Mar 16, 2020 at 2:37 PM Icenowy Zheng wrote: > >> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel. >> >> Add its device tree binding. >> >> Signed-off-by: Icenowy Zheng >(...) > >> +properties: >> + compatible: >> +const: xingbangda,xbd599 > >As noticed in the review of the driver, this display is very close to >himax,hx8363. > >I think the best is to determin what actual display controller it is, >I think it is some kind of Ilitek controller since Ilitek ili9342 is >clearly very similar. It's Sitronix ST7703, same as the Librem 5 panel. > >The best would be something like name the bindings >ilitek-ili9342.yaml and then: > >properties: > compatible: >items: > - const: xingbangda,xbd599 > - const: ilitek,ili9342 > >Possibly use oneOf and add support for the himax,hx8363 >already while you're at it. > >Yours, >Linus Walleij > >___ >linux-arm-kernel mailing list >linux-arm-ker...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 使用 K-9 Mail 发送自我的Android设备。 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v2 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
在 2020-03-16星期一的 21:35 +0800，Icenowy Zheng写道：
> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
>
> Add its device nodes.
>
> Signed-off-by: Icenowy Zheng
> ---
> No changes in v2.
>
> .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37
> +++
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> index cefda145c3c9..96d9150423e0 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> @@ -16,6 +16,15 @@ aliases {
> serial0 =
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42
> 46 51 56 62 68 75 83 91 100>;
Should I drop the 0 here and replace it with 14?
I have heard community complaining about setting 0 to brightness make
the screen black.
(I think in this situation bl_power or blank the DSI panel can still
totally shut down the backlight).
> + default-brightness-level = <15>;
> + enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
> + power-supply = <_ldo_io0>;
> + };
> +
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -84,6 +93,30 @@ {
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + vcc-dsi-supply = <_dldo1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + panel@0 {
> + compatible = "xingbangda,xbd599";
> + reg = <0>;
> + reset-gpios = < 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
> + iovcc-supply = <_dldo2>;
> + vcc-supply = <_ldo_io0>;
> + backlight = <>;
> + };
> +};
> +
> {
> status = "okay";
> };
> @@ -188,6 +221,10 @@ _pio {
>*/
> };
>
> +_pwm {
> + status = "okay";
> +};
> +
> _rsb {
> status = "okay";
>
> --
> 2.24.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
display.
Add its device nodes.
Signed-off-by: Icenowy Zheng
---
No changes in v2.
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index cefda145c3c9..96d9150423e0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -16,6 +16,15 @@ aliases {
serial0 =
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42 46 51
56 62 68 75 83 91 100>;
+ default-brightness-level = <15>;
+ enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+ power-supply = <_ldo_io0>;
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -84,6 +93,30 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ vcc-dsi-supply = <_dldo1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "xingbangda,xbd599";
+ reg = <0>;
+ reset-gpios = < 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
+ iovcc-supply = <_dldo2>;
+ vcc-supply = <_ldo_io0>;
+ backlight = <>;
+ };
+};
+
{
status = "okay";
};
@@ -188,6 +221,10 @@ _pio {
*/
};
+_pwm {
+ status = "okay";
+};
+
_rsb {
status = "okay";
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm: panel: add Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
Xingbangda, which is used on PinePhone final assembled phones.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Raised copyright info to 2020.
- Sort panel operation functions.
- Sort inclusion.
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-xingbangda-xbd599.c | 366 ++
3 files changed, 376 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a1723c1b5fbf..cf0c59015a44 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -433,6 +433,15 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+config DRM_PANEL_XINGBANGDA_XBD599
+ tristate "Xingbangda XBD599 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Xingbangda XBD599
+ MIPI DSI Video Mode panel.
+
config DRM_PANEL_XINPENG_XPP055C272
tristate "Xinpeng XPP055C272 panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 96a883cd6630..c84ed5215984 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -46,4 +46,5 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_XINGBANGDA_XBD599) += panel-xingbangda-xbd599.o
obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
new file mode 100644
index ..8d56b6579111
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xingbangda XBD599 MIPI-DSI panel driver
+ *
+ * Copyright (C) 2019-2020 Icenowy Zheng
+ *
+ * Based on panel-rocktech-jh057n00900.c, which is:
+ * Copyright (C) Purism SPC 2019
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Manufacturer specific Commands send via DSI */
+#define ST7703_CMD_ALL_PIXEL_OFF 0x22
+#define ST7703_CMD_ALL_PIXEL_ON 0x23
+#define ST7703_CMD_SETDISP 0xB2
+#define ST7703_CMD_SETRGBIF 0xB3
+#define ST7703_CMD_SETCYC 0xB4
+#define ST7703_CMD_SETBGP 0xB5
+#define ST7703_CMD_SETVCOM 0xB6
+#define ST7703_CMD_SETOTP 0xB7
+#define ST7703_CMD_SETPOWER_EXT 0xB8
+#define ST7703_CMD_SETEXTC 0xB9
+#define ST7703_CMD_SETMIPI 0xBA
+#define ST7703_CMD_SETVDC 0xBC
+#define ST7703_CMD_SETSCR 0xC0
+#define ST7703_CMD_SETPOWER 0xC1
+#define ST7703_CMD_UNK_C6 0xC6
+#define ST7703_CMD_SETPANEL 0xCC
+#define ST7703_CMD_SETGAMMA 0xE0
+#define ST7703_CMD_SETEQ0xE3
+#define ST7703_CMD_SETGIP1 0xE9
+#define ST7703_CMD_SETGIP2 0xEA
+
+static const char * const regulator_names[] = {
+ "iovcc",
+ "vcc",
+};
+
+struct xbd599 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+ bool prepared;
+};
+
+static inline struct xbd599 *panel_to_xbd599(struct drm_panel *panel)
+{
+ return container_of(panel, struct xbd599, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int xbd599_init_sequence(struct xbd599 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+ int ret;
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
+ 0xF1, 0x12, 0x83);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
+ 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
+ 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02,
[PATCH v2 0/5] Add support for PinePhone LCD panel
This patchset adds support for the LCD panel of PinePhone. The first 3 patches are for the panel itself, and the last 2 patches are for enabling it on PinePhone. PATCH 4 is the fix of a bug in sun6i_mipi_dsi which will gets triggered on XBD599. Icenowy Zheng (5): dt-bindings: vendor-prefixes: Add Xingbangda dt-bindings: panel: add binding for Xingbangda XBD599 panel drm: panel: add Xingbangda XBD599 panel drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone .../display/panel/xingbangda,xbd599.yaml | 50 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-xingbangda-xbd599.c | 366 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 10 +- 7 files changed, 470 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation
The max() function call in horizontal timing calculation shouldn't pad a length already subtracted with overhead to overhead, instead it should only prevent the set timing to underflow. Signed-off-by: Icenowy Zheng --- No changes in v2. drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 059939789730..5f2313c40328 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -555,7 +555,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HSA_PACKET_OVERHEAD10 hsa = max((unsigned int)HSA_PACKET_OVERHEAD, - (mode->hsync_end - mode->hsync_start) * Bpp - HSA_PACKET_OVERHEAD); + (mode->hsync_end - mode->hsync_start) * Bpp) - HSA_PACKET_OVERHEAD; /* * The backporch is set using a blanking packet (4 @@ -564,7 +564,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBP_PACKET_OVERHEAD6 hbp = max((unsigned int)HBP_PACKET_OVERHEAD, - (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD); + (mode->htotal - mode->hsync_end) * Bpp) - HBP_PACKET_OVERHEAD; /* * The frontporch is set using a sync event (4 bytes) @@ -574,7 +574,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HFP_PACKET_OVERHEAD16 hfp = max((unsigned int)HFP_PACKET_OVERHEAD, - (mode->hsync_start - mode->hdisplay) * Bpp - HFP_PACKET_OVERHEAD); + (mode->hsync_start - mode->hdisplay) * Bpp) - HFP_PACKET_OVERHEAD; /* * The blanking is set using a sync event (4 bytes) @@ -583,8 +583,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBLK_PACKET_OVERHEAD 10 hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, - (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp - - HBLK_PACKET_OVERHEAD); + (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp) - + HBLK_PACKET_OVERHEAD; /* * And I'm not entirely sure what vblk is about. The driver in -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] dt-bindings: vendor-prefixes: Add Xingbangda
Shenzhen Xingbangda Display Technology Co., Ltd is a company which produces LCD modules. It supplies the LCD panels of the PinePhone series (the developers' kit and the final phone). Add the vendor prefix of it. Signed-off-by: Icenowy Zheng --- No changes in v2. Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 23ca95bee298..0d9e966eff19 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1106,6 +1106,8 @@ patternProperties: description: Xiaomi Technology Co., Ltd. "^xillybus,.*": description: Xillybus Ltd. + "^xingbangda,.*": +description: Shenzhen Xingbangda Display Technology Co., Ltd "^xinpeng,.*": description: Shenzhen Xinpeng Technology Co., Ltd "^xlnx,.*": -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel.
Add its device tree binding.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Example fix.
- Format fix.
.../display/panel/xingbangda,xbd599.yaml | 50 +++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
new file mode 100644
index ..b27bcf11198f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/xingbangda,xbd599.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xingbangda XBD599 5.99in MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: xingbangda,xbd599
+ reg: true
+ backlight: true
+ reset-gpios: true
+ vcc-supply:
+description: regulator that supplies the VCC voltage
+ iovcc-supply:
+description: regulator that supplies the IOVCC voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - vcc-supply
+ - iovcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "xingbangda,xbd599";
+reg = <0>;
+backlight = <>;
+iovcc-supply = <_dldo2>;
+vcc-supply = <_ldo_io0>;
+};
+};
+
+...
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm: panel: add Xingbangda XBD599 panel
于 2020年3月14日 GMT+08:00 下午4:00:00, Sam Ravnborg 写到:
>Hi Icenowy
>
>A few details in the following.
>
> Sam
>
>On Thu, Mar 12, 2020 at 12:33:27AM +0800, Icenowy Zheng wrote:
>> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
>> Xingbangda, which is used on PinePhone final assembled phones.
>>
>> Add support for it.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> drivers/gpu/drm/panel/Kconfig | 9 +
>> drivers/gpu/drm/panel/Makefile| 1 +
>> .../gpu/drm/panel/panel-xingbangda-xbd599.c | 367
>++
>> 3 files changed, 377 insertions(+)
>> create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
>>
>> +++ b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
>> @@ -0,0 +1,367 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Xingbangda XBD599 MIPI-DSI panel driver
>> + *
>> + * Copyright (C) 2019 Icenowy Zheng
>2020?
The work started at Mid 2019.
Is 2019-2020 okay?
>
>> + *
>> + * Based on panel-rocktech-jh057n00900.c, which is:
>> + * Copyright (C) Purism SPC 2019
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>Sort alphabetically.
>
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define DRV_NAME "panel-xingbangda-xbd599"
>No reason for this indirection, it is only used once
>
>> +
>> +/* Manufacturer specific Commands send via DSI */
>> +#define ST7703_CMD_ALL_PIXEL_OFF 0x22
>> +#define ST7703_CMD_ALL_PIXEL_ON 0x23
>> +#define ST7703_CMD_SETDISP 0xB2
>> +#define ST7703_CMD_SETRGBIF 0xB3
>> +#define ST7703_CMD_SETCYC0xB4
>> +#define ST7703_CMD_SETBGP0xB5
>> +#define ST7703_CMD_SETVCOM 0xB6
>> +#define ST7703_CMD_SETOTP0xB7
>> +#define ST7703_CMD_SETPOWER_EXT 0xB8
>> +#define ST7703_CMD_SETEXTC 0xB9
>> +#define ST7703_CMD_SETMIPI 0xBA
>> +#define ST7703_CMD_SETVDC0xBC
>> +#define ST7703_CMD_SETSCR0xC0
>> +#define ST7703_CMD_SETPOWER 0xC1
>> +#define ST7703_CMD_UNK_C60xC6
>> +#define ST7703_CMD_SETPANEL 0xCC
>> +#define ST7703_CMD_SETGAMMA 0xE0
>> +#define ST7703_CMD_SETEQ 0xE3
>> +#define ST7703_CMD_SETGIP1 0xE9
>> +#define ST7703_CMD_SETGIP2 0xEA
>> +
>> +static const char * const regulator_names[] = {
>> +"iovcc",
>> +"vcc",
>> +};
>> +
>> +struct xbd599 {
>> +struct device *dev;
>> +struct drm_panel panel;
>> +struct gpio_desc *reset_gpio;
>> +struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
>> +bool prepared;
>> +};
>> +
>> +static inline struct xbd599 *panel_to_xbd599(struct drm_panel
>*panel)
>> +{
>> +return container_of(panel, struct xbd599, panel);
>> +}
>> +
>> +#define dsi_dcs_write_seq(dsi, cmd, seq...) do {\
>> +static const u8 d[] = { seq }; \
>> +int ret;\
>> +ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
>> +if (ret < 0)\
>> +return ret; \
>> +} while (0)
>> +
>> +static int xbd599_init_sequence(struct xbd599 *ctx)
>> +{
>> +struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
>> +struct device *dev = ctx->dev;
>> +int ret;
>> +
>> +/*
>> + * Init sequence was supplied by the panel vendor.
>> + */
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
>> + 0xF1, 0x12, 0x83);
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
>> + 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
>> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
>> + 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4F, 0x11,
>> + 0x00, 0x00, 0x37);
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT,
>> + 0x25, 0x22, 0x20, 0x03);
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF,
>> + 0x10, 0x10, 0x05, 0x05, 0x03, 0xFF, 0x00, 0x00,
>> + 0x00, 0x00);
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR,
>> + 0x73, 0x73, 0x50, 0x50, 0x00, 0xC0, 0x08, 0x70,
>&g
[PATCH 0/5] Add support for PinePhone LCD panel
This patchset adds support for the LCD panel of PinePhone. The first 3 patches are for the panel itself, and the last 2 patches are for enabling it on PinePhone. PATCH 4 is the fix of a bug in sun6i_mipi_dsi which will gets triggered on XBD599. Icenowy Zheng (5): dt-bindings: vendor-prefixes: Add Xingbangda dt-bindings: panel: add binding for Xingbangda XBD599 panel drm: panel: add Xingbangda XBD599 panel drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone .../display/panel/xingbangda,xbd599.yaml | 50 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-xingbangda-xbd599.c | 367 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 10 +- 7 files changed, 471 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
display.
Add its device nodes.
Signed-off-by: Icenowy Zheng
---
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index cefda145c3c9..96d9150423e0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -16,6 +16,15 @@ aliases {
serial0 =
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42 46 51
56 62 68 75 83 91 100>;
+ default-brightness-level = <15>;
+ enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+ power-supply = <_ldo_io0>;
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -84,6 +93,30 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ vcc-dsi-supply = <_dldo1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "xingbangda,xbd599";
+ reg = <0>;
+ reset-gpios = < 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
+ iovcc-supply = <_dldo2>;
+ vcc-supply = <_ldo_io0>;
+ backlight = <>;
+ };
+};
+
{
status = "okay";
};
@@ -188,6 +221,10 @@ _pio {
*/
};
+_pwm {
+ status = "okay";
+};
+
_rsb {
status = "okay";
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation
The max() function call in horizontal timing calculation shouldn't pad a length already subtracted with overhead to overhead, instead it should only prevent the set timing to underflow. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 059939789730..5f2313c40328 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -555,7 +555,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HSA_PACKET_OVERHEAD10 hsa = max((unsigned int)HSA_PACKET_OVERHEAD, - (mode->hsync_end - mode->hsync_start) * Bpp - HSA_PACKET_OVERHEAD); + (mode->hsync_end - mode->hsync_start) * Bpp) - HSA_PACKET_OVERHEAD; /* * The backporch is set using a blanking packet (4 @@ -564,7 +564,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBP_PACKET_OVERHEAD6 hbp = max((unsigned int)HBP_PACKET_OVERHEAD, - (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD); + (mode->htotal - mode->hsync_end) * Bpp) - HBP_PACKET_OVERHEAD; /* * The frontporch is set using a sync event (4 bytes) @@ -574,7 +574,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HFP_PACKET_OVERHEAD16 hfp = max((unsigned int)HFP_PACKET_OVERHEAD, - (mode->hsync_start - mode->hdisplay) * Bpp - HFP_PACKET_OVERHEAD); + (mode->hsync_start - mode->hdisplay) * Bpp) - HFP_PACKET_OVERHEAD; /* * The blanking is set using a sync event (4 bytes) @@ -583,8 +583,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBLK_PACKET_OVERHEAD 10 hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, - (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp - - HBLK_PACKET_OVERHEAD); + (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp) - + HBLK_PACKET_OVERHEAD; /* * And I'm not entirely sure what vblk is about. The driver in -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] Add support for PinePhone LCD panel
This patchset adds support for the LCD panel of PinePhone. The first 3 patches are for the panel itself, and the last 2 patches are for enabling it on PinePhone. PATCH 4 is the fix of a bug in sun6i_mipi_dsi which will gets triggered on XBD599. Icenowy Zheng (5): dt-bindings: vendor-prefixes: Add Xingbangda dt-bindings: panel: add binding for Xingbangda XBD599 panel drm: panel: add Xingbangda XBD599 panel drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone .../display/panel/xingbangda,xbd599.yaml | 50 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-xingbangda-xbd599.c | 367 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 10 +- 7 files changed, 471 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm: panel: add Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
Xingbangda, which is used on PinePhone final assembled phones.
Add support for it.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-xingbangda-xbd599.c | 367 ++
3 files changed, 377 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index da3b84602cdd..d648f40469c7 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -413,6 +413,15 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+config DRM_PANEL_XINGBANGDA_XBD599
+ tristate "Xingbangda XBD599 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Xingbangda XBD599
+ MIPI DSI Video Mode panel.
+
config DRM_PANEL_XINPENG_XPP055C272
tristate "Xinpeng XPP055C272 panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index af1e2a3cc5fc..d9645f079e59 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,4 +44,5 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_XINGBANGDA_XBD599) += panel-xingbangda-xbd599.o
obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
new file mode 100644
index ..68a5d8bb7f26
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
@@ -0,0 +1,367 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xingbangda XBD599 MIPI-DSI panel driver
+ *
+ * Copyright (C) 2019 Icenowy Zheng
+ *
+ * Based on panel-rocktech-jh057n00900.c, which is:
+ * Copyright (C) Purism SPC 2019
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "panel-xingbangda-xbd599"
+
+/* Manufacturer specific Commands send via DSI */
+#define ST7703_CMD_ALL_PIXEL_OFF 0x22
+#define ST7703_CMD_ALL_PIXEL_ON 0x23
+#define ST7703_CMD_SETDISP 0xB2
+#define ST7703_CMD_SETRGBIF 0xB3
+#define ST7703_CMD_SETCYC 0xB4
+#define ST7703_CMD_SETBGP 0xB5
+#define ST7703_CMD_SETVCOM 0xB6
+#define ST7703_CMD_SETOTP 0xB7
+#define ST7703_CMD_SETPOWER_EXT 0xB8
+#define ST7703_CMD_SETEXTC 0xB9
+#define ST7703_CMD_SETMIPI 0xBA
+#define ST7703_CMD_SETVDC 0xBC
+#define ST7703_CMD_SETSCR 0xC0
+#define ST7703_CMD_SETPOWER 0xC1
+#define ST7703_CMD_UNK_C6 0xC6
+#define ST7703_CMD_SETPANEL 0xCC
+#define ST7703_CMD_SETGAMMA 0xE0
+#define ST7703_CMD_SETEQ0xE3
+#define ST7703_CMD_SETGIP1 0xE9
+#define ST7703_CMD_SETGIP2 0xEA
+
+static const char * const regulator_names[] = {
+ "iovcc",
+ "vcc",
+};
+
+struct xbd599 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+ bool prepared;
+};
+
+static inline struct xbd599 *panel_to_xbd599(struct drm_panel *panel)
+{
+ return container_of(panel, struct xbd599, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int xbd599_init_sequence(struct xbd599 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+ int ret;
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
+ 0xF1, 0x12, 0x83);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
+ 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
+ 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4F, 0x11,
+ 0x00, 0x0
[PATCH 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel.
Add its device tree binding.
Signed-off-by: Icenowy Zheng
---
.../display/panel/xingbangda,xbd599.yaml | 50 +++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
new file mode 100644
index ..62816b34de31
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/xingbangda,xbd599.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xingbangda XBD599 5.99in MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: xingbangda,xbd599
+ reg: true
+ backlight: true
+ reset-gpios: true
+ vcc-supply:
+ description: regulator that supplies the VCC voltage
+ iovcc-supply:
+ description: regulator that supplies the IOVCC voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - vcc-supply
+ - iovcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "xingbangda,xbd599";
+reg = <0>;
+backlight = <>;
+iovcc-supply = <_dldo2>;
+vcc-supply = <_ldo_io0>;
+};
+};
+
+...
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] dt-bindings: vendor-prefixes: Add Xingbangda
Shenzhen Xingbangda Display Technology Co., Ltd is a company which produces LCD modules. It supplies the LCD panels of the PinePhone series (the developers' kit and the final phone). Add the vendor prefix of it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b8e9ef79cab9..038a2180d34b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1102,6 +1102,8 @@ patternProperties: description: Xiaomi Technology Co., Ltd. "^xillybus,.*": description: Xillybus Ltd. + "^xingbangda,.*": +description: Shenzhen Xingbangda Display Technology Co., Ltd "^xinpeng,.*": description: Shenzhen Xinpeng Technology Co., Ltd "^xlnx,.*": -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
在 2020-03-06星期五的 09:46 +0100，Enric Balletbo i Serra写道： > Hi Ondrej, > > On 5/3/20 20:35, Ondřej Jirman wrote: > > Hi, > > > > On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote: > > > On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra > > > wrote: > > > > Hi Vasily, > > > > > > CC: Icenowy and Ondrej > > > > Would you mind to check which firmware version is running the > > > > anx7688 in > > > > PinePhone, I think should be easy to check with i2c-tools. > > > > > > Icenowy, Ondrej, can you guys please check anx7688 firmware > > > version? > > > > i2cget 0 0x28 0x00 w > > 0x > > > > i2cget 0 0x28 0x02 w > > 0x7688 > > > > i2cget 0 0x28 0x80 w > > 0x > > > > Can you check the value for 0x81 too? root@ice-pinephone [ ~ ] # i2cdump 0 0x28 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x28, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: aa aa 88 76 ac 00 00 00 00 00 00 00 00 00 05 05???v?.?? 10: 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000... 20: 00 00 00 00 00 00 00 00 00 00 00 24 f2 e4 ff 00...$??.. 30: 06 40 00 04 94 11 20 ff ff 03 00 bf ff ff 10 01?@.??? ..?.?..?? 40: 72 a4 00 09 00 08 05 84 15 40 17 00 00 0a 00 e0r?.?.@?..?.? 50: 00 00 00 0a 10 00 e0 df ff ff 00 00 00 10 71 00...??.??.?q. 60: 10 10 04 29 2d 21 10 01 09 13 00 03 e8 13 88 00???)-!.. 70: 00 19 18 83 16 5c 11 00 ff 00 00 0d 04 38 42 07.\???8B? 80: 00 00 00 00 00 74 1b 19 44 08 75 00 00 00 00 00.t??D?u. 90: 01 02 00 00 00 00 03 00 ff 30 00 59 01 00 00 00???..0.Y?... a0: 00 ff fe ff ff 00 00 00 00 00 00 00 00 00 00 02..?? b0: 00 00 00 00 00 00 40 00 28 00 00 00 00 44 08 00..@.(D?. c0: 00 00 00 00 80 00 10 01 0a 10 18 00 00 fd 00 00?.?..?.. d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 50 10 08 50 00 02 00 70 00 00 30 10 0b 02 1c 01P??P.?.p..0? f0: 00 0b 07 00 94 11 7f 00 00 00 00 00 00 01 0e ff.??.???..??. root@ice-pinephone [ ~ ] # i2cdump 0 0x2c No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x2c, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: 29 1f 88 76 00 ac 11 00 11 20 10 10 00 00 00 00)??v.??.? ?? 10: 03 00 ff 8f ff 7f 00 00 00 00 05 00 10 0a 0c 00?..?.??.???. 20: 00 00 00 00 99 06 c0 00 00 00 00 00 00 00 02 00???...?. 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00?... 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00?... 80: 01 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00?%.. 90: 0f 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00??.. a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Thanks, > Enric > > > > regards, > > o. > > > > > > Thanks in advance, > > > > Enric > > > > > > > > [snip] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
于 2020年3月6日 GMT+08:00 上午2:29:33, Vasily Khoruzhick 写到: >On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra > wrote: >> >> Hi Vasily, > >CC: Icenowy and Ondrej >> >> Would you mind to check which firmware version is running the anx7688 >in >> PinePhone, I think should be easy to check with i2c-tools. > >Icenowy, Ondrej, can you guys please check anx7688 firmware version? At 0x2c, 0x80 is 0x01, 0x81 is 0x25 01.25, right? > >> Thanks in advance, >> Enric >> >> [snip] -- 使用 K-9 Mail 发送自我的Android设备。 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/33] drm/panel-feixin-k101-im2ba02: Fix dotclock
于 2020年3月3日 GMT+08:00 上午4:34:22, Ville Syrjala
写到:
>From: Ville Syrjälä
>
>The currently listed dotclock disagrees with the currently
>listed vrefresh rate. Change the dotclock to match the vrefresh.
>
>Someone tell me which (if either) of the dotclock or vreresh is
>correct?
dotclock is correct and vrefresh is only a placeholder value.
>
>Cc: Icenowy Zheng
>Cc: Sam Ravnborg
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>index fddbfddf6566..8debee85f4ec 100644
>--- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>@@ -391,7 +391,7 @@ static int k101_im2ba02_unprepare(struct drm_panel
>*panel)
> }
>
> static const struct drm_display_mode k101_im2ba02_default_mode = {
>- .clock = 7,
>+ .clock = 67286,
> .vrefresh = 60,
>
> .hdisplay = 800,
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: analogix-anx6345: fix set of link bandwidth
于 2020年2月26日 GMT+08:00 下午6:58:43, Thomas Zimmermann 写到:
>Hi Iceynow,
>
>Torsten asked me to merge your patch via drm-misc-next. I'd add the
>additional cc and fixes tags that Torsten listed. Are you OK with that?
I think this fixes a driver (and a board) available in 5.6.
Maybe it should enter fixes?
>
>Best regards
>Thomas
>
>Am 22.02.20 um 03:43 schrieb Icenowy Zheng:
>>
>>
>> 于 2020年2月22日 GMT+08:00 上午1:13:28, Torsten Duwe 写到:
>>> On Sat, Feb 22, 2020 at 12:51:27AM +0800, Icenowy Zheng wrote:
>>>> Current code tries to store the link rate (in bps, which is a big
>>>> number) in a u8, which surely overflow. Then it's converted back to
>>>> bandwidth code (which is thus 0) and written to the chip.
>>>>
>>>> The code sometimes works because the chip will automatically
>fallback
>>> to
>>>> the lowest possible DP link rate (1.62Gbps) when get the invalid
>>> value.
>>>> However, on the eDP panel of Olimex TERES-I, which wants 2.7Gbps
>>> link,
>>>> it failed.
>>>>
>>>> As we had already read the link bandwidth as bandwidth code in
>>> earlier
>>>> code (to check whether it is supported), use it when setting
>>> bandwidth,
>>>> instead of converting it to link rate and then converting back.
>>>>
>>>> Fixes: e1cff82c1097 ("drm/bridge: fix anx6345 compilation for
>v5.5")
>>>> Signed-off-by: Icenowy Zheng
>>>> ---
>>>> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 3 +--
>>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>>> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>>>> index 56f55c53abfd..2dfa2fd2a23b 100644
>>>> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>>>> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>>>> @@ -210,8 +210,7 @@ static int anx6345_dp_link_training(struct
>>> anx6345 *anx6345)
>>>>if (err)
>>>>return err;
>>>>
>>>> - dpcd[0] = drm_dp_max_link_rate(anx6345->dpcd);
>>>> - dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
>>>> + dpcd[0] = dp_bw;
>>>
>>> Why do you make this assignment and not use dp_bw directly in the
>call?
>>
>> Because the dpcd array is then written as a continous array
>> back to DPCD.
>>
>>>
>>>>err = regmap_write(anx6345->map[I2C_IDX_DPTX],
>>>> SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
>>> ^^
>>>>if (err)
>>>> --
>>>> 2.24.1
>>>
>>> BTW, my version is only a bit more verbose:
>>>
>>> https://patchwork.freedesktop.org/patch/354344/
>>>
>>> Torsten
>>
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: analogix-anx6345: fix set of link bandwidth
Current code tries to store the link rate (in bps, which is a big
number) in a u8, which surely overflow. Then it's converted back to
bandwidth code (which is thus 0) and written to the chip.
The code sometimes works because the chip will automatically fallback to
the lowest possible DP link rate (1.62Gbps) when get the invalid value.
However, on the eDP panel of Olimex TERES-I, which wants 2.7Gbps link,
it failed.
As we had already read the link bandwidth as bandwidth code in earlier
code (to check whether it is supported), use it when setting bandwidth,
instead of converting it to link rate and then converting back.
Fixes: e1cff82c1097 ("drm/bridge: fix anx6345 compilation for v5.5")
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index 56f55c53abfd..2dfa2fd2a23b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -210,8 +210,7 @@ static int anx6345_dp_link_training(struct anx6345 *anx6345)
if (err)
return err;
- dpcd[0] = drm_dp_max_link_rate(anx6345->dpcd);
- dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
+ dpcd[0] = dp_bw;
err = regmap_write(anx6345->map[I2C_IDX_DPTX],
SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
if (err)
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: analogix-anx6345: fix set of link bandwidth
于 2020年2月22日 GMT+08:00 上午1:13:28, Torsten Duwe 写到:
>On Sat, Feb 22, 2020 at 12:51:27AM +0800, Icenowy Zheng wrote:
>> Current code tries to store the link rate (in bps, which is a big
>> number) in a u8, which surely overflow. Then it's converted back to
>> bandwidth code (which is thus 0) and written to the chip.
>>
>> The code sometimes works because the chip will automatically fallback
>to
>> the lowest possible DP link rate (1.62Gbps) when get the invalid
>value.
>> However, on the eDP panel of Olimex TERES-I, which wants 2.7Gbps
>link,
>> it failed.
>>
>> As we had already read the link bandwidth as bandwidth code in
>earlier
>> code (to check whether it is supported), use it when setting
>bandwidth,
>> instead of converting it to link rate and then converting back.
>>
>> Fixes: e1cff82c1097 ("drm/bridge: fix anx6345 compilation for v5.5")
>> Signed-off-by: Icenowy Zheng
>> ---
>> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>> index 56f55c53abfd..2dfa2fd2a23b 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>> @@ -210,8 +210,7 @@ static int anx6345_dp_link_training(struct
>anx6345 *anx6345)
>> if (err)
>> return err;
>>
>> -dpcd[0] = drm_dp_max_link_rate(anx6345->dpcd);
>> -dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
>> +dpcd[0] = dp_bw;
>
>Why do you make this assignment and not use dp_bw directly in the call?
Because the dpcd array is then written as a continous array
back to DPCD.
>
>> err = regmap_write(anx6345->map[I2C_IDX_DPTX],
>> SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
> ^^
>> if (err)
>> --
>> 2.24.1
>
>BTW, my version is only a bit more verbose:
>
>https://patchwork.freedesktop.org/patch/354344/
>
> Torsten
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] dt-bindings: arm: sunxi: add binding for PineTab tablet
Add the device tree binding for Pine64's PineTab tablet, which uses Allwinner A64 SoC. Signed-off-by: Icenowy Zheng Reviewed-by: Rob Herring --- Changes in v2: - Added Review tag by Rob. Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 327ce6730823..159060b65c5d 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -636,6 +636,11 @@ properties: - const: pine64,pinebook - const: allwinner,sun50i-a64 + - description: Pine64 PineTab +items: + - const: pine64,pinetab + - const: allwinner,sun50i-a64 + - description: Pine64 SoPine Baseboard items: - const: pine64,sopine-baseboard -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel
Feixin K101 IM2BA02 is a 10.1" 800x1280 4-lane MIPI-DSI panel.
Add device tree binding for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Set backlight property to optional. (Technically this panel requires
backlight, but theortically it can be not adjustable.)
- Tweaked the example to pass schema check.
.../display/panel/feixin,k101-im2ba02.yaml| 55 +++
1 file changed, 55 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
new file mode 100644
index ..be1ecce9c3c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/feixin,k101-im2ba02.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Feixin K101 IM2BA02 10.1" MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: feixin,k101-im2ba02
+ reg: true
+ backlight: true
+ reset-gpios: true
+ avdd-supply:
+ description: regulator that supplies the AVDD voltage
+ dvdd-supply:
+ description: regulator that supplies the DVDD voltage
+ cvdd-supply:
+ description: regulator that supplies the CVDD voltage
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - dvdd-supply
+ - cvdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "feixin,k101-im2ba02";
+reg = <0>;
+avdd-supply = <_dc1sw>;
+dvdd-supply = <_dc1sw>;
+cvdd-supply = <_ldo_io1>;
+reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>;
+backlight = <>;
+};
+};
+
+...
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/5] Add support for Pine64 PineTab
This patchset tries to add support for the PineTab tablet from Pine64. As it uses a specific MIPI-DSI panel, the support of the panel should be introduced first, with its DT binding. Then a device tree is added. Compared to v1 of the patchset, the accelerometer support is temporarily removed because a DT binding is lacked (although a proper driver exists). Icenowy Zheng (5): dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel drm/panel: Add Feixin K101 IM2BA02 panel dt-bindings: arm: sunxi: add binding for PineTab tablet arm64: dts: allwinner: a64: add support for PineTab .../devicetree/bindings/arm/sunxi.yaml| 5 + .../display/panel/feixin,k101-im2ba02.yaml| 55 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 6 + arch/arm64/boot/dts/allwinner/Makefile| 1 + .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 460 +++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 526 ++ 9 files changed, 1065 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/panel: Add Feixin K101 IM2BA02 panel
Feixin K101 IM2BA02 is a 800x1280 4-lane MIPI-DSI LCD panel.
Add a panel driver for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Use regulator_bulk.
- Small code fixes.
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 526 ++
4 files changed, 542 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 98cf0b034f61..2ec9ae62478a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5251,6 +5251,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
S: Maintained
F: drivers/gpu/drm/tve200/
+DRM DRIVER FOR FEIXIN K101 IM2BA02 MIPI-DSI LCD PANELS
+M: Icenowy Zheng
+S: Maintained
+F: drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
+F: Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
+
DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
M: Jagan Teki
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ae44ac2ec106..4641ec804e5e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -50,6 +50,15 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_FEIXIN_K101_IM2BA02
+ tristate "Feixin K101 IM2BA02 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Feixin K101 IM2BA02
+ 4-lane 800x1280 MIPI DSI panel.
+
config DRM_PANEL_FEIYANG_FY07024DI26A30D
tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7c4d3c581fd4..442c17ccc62e 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
new file mode 100644
index ..fddbfddf6566
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
@@ -0,0 +1,526 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-2020 Icenowy Zheng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define K101_IM2BA02_INIT_CMD_LEN 2
+
+static const char * const regulator_names[] = {
+ "dvdd",
+ "avdd",
+ "cvdd"
+};
+
+struct k101_im2ba02 {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+ struct gpio_desc*reset;
+};
+
+static inline struct k101_im2ba02 *panel_to_k101_im2ba02(struct drm_panel
*panel)
+{
+ return container_of(panel, struct k101_im2ba02, panel);
+}
+
+struct k101_im2ba02_init_cmd {
+ u8 data[K101_IM2BA02_INIT_CMD_LEN];
+};
+
+static const struct k101_im2ba02_init_cmd k101_im2ba02_init_cmds[] = {
+ /* Switch to page 0 */
+ { .data = { 0xE0, 0x00 } },
+
+ /* Seems to be some password */
+ { .data = { 0xE1, 0x93} },
+ { .data = { 0xE2, 0x65 } },
+ { .data = { 0xE3, 0xF8 } },
+
+ /* Lane number, 0x02 - 3 lanes, 0x03 - 4 lanes */
+ { .data = { 0x80, 0x03 } },
+
+ /* Sequence control */
+ { .data = { 0x70, 0x02 } },
+ { .data = { 0x71, 0x23 } },
+ { .data = { 0x72, 0x06 } },
+
+ /* Switch to page 1 */
+ { .data = { 0xE0, 0x01 } },
+
+ /* Set VCOM */
+ { .data = { 0x00, 0x00 } },
+ { .data = { 0x01, 0x66 } },
+ /* Set VCOM_Reverse */
+ { .data = { 0x03, 0x00 } },
+ { .data = { 0x04, 0x25 } },
+
+ /* Set Gamma Power, VG[MS][PN] */
+ { .data = { 0x17, 0x00 } },
+ { .data = { 0x18, 0x6D } },
+ { .data = { 0x19, 0x00 } },
+ { .data = { 0x1A, 0x00 } },
+ { .data = { 0x1B, 0xBF } }, /* VGMN = -4.5V */
+ { .data = { 0x1C, 0x00 } },
+
+ /* Set Gate Power */
+ { .data = { 0x1F, 0x3E } }, /* VGH_R = 15V */
+ { .data = { 0x20, 0x28 } }, /* VGL_R = -11V */
+ { .data = { 0x21, 0x28 } }, /* VGL_R2 = -
[PATCH v2 1/5] dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd
Shenzhen Feixin Photoelectics Co., Ltd is a company to provide LCD modules. Add its vendor prefix. Signed-off-by: Icenowy Zheng Acked-by: Sam Ravnborg Acked-by: Rob Herring --- Changes in v2: - Added ACKs from Sam and Rob. Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 97c0a06b35cd..07d52254427b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -337,6 +337,8 @@ patternProperties: description: Fastrax Oy "^fcs,.*": description: Fairchild Semiconductor + "^feixin,.*": +description: Shenzhen Feixin Photoelectic Co., Ltd "^feiyang,.*": description: Shenzhen Fly Young Technology Co.,LTD. "^firefly,.*": -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] arm64: dts: allwinner: a64: add support for PineTab
PineTab is a 10.1" tablet by Pine64 with Allwinner A64 inside.
It includes the following peripherals:
USB:
- A microUSB Type-B port connected to the OTG-capable USB PHY of
Allwinner A64. The ID pin is connected to a GPIO of the A64 SoC, and the
Vbus is connected to the Vbus of AXP803 PMIC. These enables OTG
functionality on this port.
- A USB Type-A port is connected to the internal hub attached to the
non-OTG USB PHY of Allwinner A64.
- There are reserved pins for an external keyboard connected to the
internal hub.
Power:
- The microUSB port has its Vbus connected to AXP803, mentioned above.
- A DC jack (of a strange size, 2.5mm outer diameter) is connected to
the ACIN of AXP803.
- A Li-Polymer battery is connected to the battery pins of AXP803.
Storage:
- An tradition Pine64 eMMC slot is on the board, mounted with an eMMC
module by factory.
- An external microSD slot is hidden under a protect case.
Display:
- A MIPI-DSI LCD panel (800x1280) is connected to the DSI port of A64 SoC.
- A mini HDMI port.
Input:
- A touch panel attached to a Goodix GT9271 touch controller.
- Volume keys connected to the LRADC of the A64 SoC.
Camera:
- An OV5640 CMOS camera is at rear, connected to the CSI bus of A64 SoC.
- A GC2145 CMOS camera is at front, shares the same CSI bus with OV5640.
Audio:
- A headphone jack is conencted to the SoC's internal codec.
- A speaker connected is to the Line Out port of SoC's internal codec, via
an amplifier.
Misc:
- Debug UART is muxed with the headphone jack, with the switch next to
the microSD slot.
- A bosch BMA223 accelerometer is connected to the I2C bus of A64 SoC.
- Wi-Fi and Bluetooth are available via a RTL8723CS chip, similar to the
one in Pinebook.
This commit adds a basically usable device tree for it, implementing
most of the features mentioned above. HDMI is not supported now because
bad LCD-HDMI coexistence situation of mainline A64 display driver, the
front camera currently lacks a driver and a facility to share the bus
with the rear one, and the accelerometer currently lacks a DT binding.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Remove I2C pinmuxes.
- Dropped binding-less accelerometer.
- Used exponent curve for backlight.
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../boot/dts/allwinner/sun50i-a64-pinetab.dts | 460 ++
2 files changed, 461 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index cf4f78617c3f..6dad63881cd3 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-lts.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
new file mode 100644
index ..c76c94855f43
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -0,0 +1,460 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+#include "sun50i-a64-cpu-opp.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "PineTab";
+ compatible = "pine64,pinetab", "allwinner,sun50i-a64";
+
+ aliases {
+ serial0 =
+ ethernet0 =
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42 46 51
56 62 68 75 83 91 100>;
+ default-brightness-level = <15>;
+ enable-gpios = < 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
+ power-supply = <_bl>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ i2c-csi {
+ compatible = "i2c-gpio";
+ sda-gpios = < 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
+ scl-gpios = < 4 12 GPIO_ACTIVE_HIGH>; /* PE12 */
+ i2c-gpio,delay-us = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Rear camera */
+ ov5640: camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-
[PATCH 3/5] drm/panel: Add Feixin K101 IM2BA02 panel
Feixin K101 IM2BA02 is a 800x1280 4-lane MIPI-DSI LCD panel.
Add a panel driver for it.
Signed-off-by: Icenowy Zheng
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 548 ++
4 files changed, 564 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 908399316455..ef7d13125344 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5218,6 +5218,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
S: Maintained
F: drivers/gpu/drm/tve200/
+DRM DRIVER FOR FEIXIN K101 IM2BA02 MIPI-DSI LCD PANELS
+M: Icenowy Zheng
+S: Maintained
+F: drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
+F: Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
+
DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
M: Jagan Teki
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ae44ac2ec106..4641ec804e5e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -50,6 +50,15 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_FEIXIN_K101_IM2BA02
+ tristate "Feixin K101 IM2BA02 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Feixin K101 IM2BA02
+ 4-lane 800x1280 MIPI DSI panel.
+
config DRM_PANEL_FEIYANG_FY07024DI26A30D
tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7c4d3c581fd4..442c17ccc62e 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
new file mode 100644
index ..45a62bdabb3f
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
@@ -0,0 +1,548 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-2020 Icenowy Zheng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define K101_IM2BA02_INIT_CMD_LEN 2
+
+struct k101_im2ba02 {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+
+ struct regulator*dvdd;
+ struct regulator*avdd;
+ struct regulator*cvdd;
+ struct gpio_desc*reset;
+};
+
+static inline struct k101_im2ba02 *panel_to_k101_im2ba02(struct drm_panel
*panel)
+{
+ return container_of(panel, struct k101_im2ba02, panel);
+}
+
+struct k101_im2ba02_init_cmd {
+ u8 data[K101_IM2BA02_INIT_CMD_LEN];
+};
+
+static const struct k101_im2ba02_init_cmd k101_im2ba02_init_cmds[] = {
+ /* Switch to page 0 */
+ { .data = { 0xE0, 0x00 } },
+
+ /* Seems to be some password */
+ { .data = { 0xE1, 0x93} },
+ { .data = { 0xE2, 0x65 } },
+ { .data = { 0xE3, 0xF8 } },
+
+ /* Lane number, 0x02 - 3 lanes, 0x03 - 4 lanes */
+ { .data = { 0x80, 0x03 } },
+
+ /* Sequence control */
+ { .data = { 0x70, 0x02 } },
+ { .data = { 0x71, 0x23 } },
+ { .data = { 0x72, 0x06 } },
+
+ /* Switch to page 1 */
+ { .data = { 0xE0, 0x01 } },
+
+ /* Set VCOM */
+ { .data = { 0x00, 0x00 } },
+ { .data = { 0x01, 0x66 } },
+ /* Set VCOM_Reverse */
+ { .data = { 0x03, 0x00 } },
+ { .data = { 0x04, 0x25 } },
+
+ /* Set Gamma Power, VG[MS][PN] */
+ { .data = { 0x17, 0x00 } },
+ { .data = { 0x18, 0x6D } },
+ { .data = { 0x19, 0x00 } },
+ { .data = { 0x1A, 0x00 } },
+ { .data = { 0x1B, 0xBF } }, /* VGMN = -4.5V */
+ { .data = { 0x1C, 0x00 } },
+
+ /* Set Gate Power */
+ { .data = { 0x1F, 0x3E } }, /* VGH_R = 15V */
+ { .data = { 0x20, 0x28 } }, /* VGL_R = -11V */
+ { .data = { 0x21, 0x28 } }, /* VGL_R2 = -11V */
+ { .data = { 0x22, 0x0E } }, /* PA[6:4] = 0, PA[0] = 0 */
+
+ /* Set Panel */
+ { .data = { 0x37, 0x09 } }
[PATCH 0/5] Add support for Pine64 PineTab
This patchset tries to add support for the PineTab tablet from Pine64. As it uses a specific MIPI-DSI panel, the support of the panel should be introduced first, with its DT binding. Then a device tree is added. Thanks to the community's contributions these years, we now have most of the functionalities of the tablet available in this device tree. Icenowy Zheng (5): dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel drm/panel: Add Feixin K101 IM2BA02 panel dt-bindings: arm: sunxi: add binding for PineTab tablet arm64: dts: allwinner: a64: add support for PineTab .../devicetree/bindings/arm/sunxi.yaml| 5 + .../display/panel/feixin,k101-im2ba02.yaml| 54 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 6 + arch/arm64/boot/dts/allwinner/Makefile| 1 + .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 461 +++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 548 ++ 9 files changed, 1087 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] dt-bindings: arm: sunxi: add binding for PineTab tablet
Add the device tree binding for Pine64's PineTab tablet, which uses Allwinner A64 SoC. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 327ce6730823..159060b65c5d 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -636,6 +636,11 @@ properties: - const: pine64,pinebook - const: allwinner,sun50i-a64 + - description: Pine64 PineTab +items: + - const: pine64,pinetab + - const: allwinner,sun50i-a64 + - description: Pine64 SoPine Baseboard items: - const: pine64,sopine-baseboard -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd
Shenzhen Feixin Photoelectics Co., Ltd is a company to provide LCD modules. Add its vendor prefix. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 3dab8150dae7..a6d53bbbe33d 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -335,6 +335,8 @@ patternProperties: description: Fastrax Oy "^fcs,.*": description: Fairchild Semiconductor + "^feixin,.*": +description: Shenzhen Feixin Photoelectic Co., Ltd "^feiyang,.*": description: Shenzhen Fly Young Technology Co.,LTD. "^firefly,.*": -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] arm64: dts: allwinner: a64: add support for PineTab
PineTab is a 10.1" tablet by Pine64 with Allwinner A64 inside.
It includes the following peripherals:
USB:
- A microUSB Type-B port connected to the OTG-capable USB PHY of
Allwinner A64. The ID pin is connected to a GPIO of the A64 SoC, and the
Vbus is connected to the Vbus of AXP803 PMIC. These enables OTG
functionality on this port.
- A USB Type-A port is connected to the internal hub attached to the
non-OTG USB PHY of Allwinner A64.
- There are reserved pins for an external keyboard connected to the
internal hub.
Power:
- The microUSB port has its Vbus connected to AXP803, mentioned above.
- A DC jack (of a strange size, 2.5mm outer diameter) is connected to
the ACIN of AXP803.
- A Li-Polymer battery is connected to the battery pins of AXP803.
Storage:
- An tradition Pine64 eMMC slot is on the board, mounted with an eMMC
module by factory.
- An external microSD slot is hidden under a protect case.
Display:
- A MIPI-DSI LCD panel (800x1280) is connected to the DSI port of A64 SoC.
- A mini HDMI port.
Input:
- A touch panel attached to a Goodix GT9271 touch controller.
- Volume keys connected to the LRADC of the A64 SoC.
Camera:
- An OV5640 CMOS camera is at rear, connected to the CSI bus of A64 SoC.
- A GC2145 CMOS camera is at front, shares the same CSI bus with OV5640.
Audio:
- A headphone jack is conencted to the SoC's internal codec.
- A speaker connected is to the Line Out port of SoC's internal codec, via
an amplifier.
Misc:
- Debug UART is muxed with the headphone jack, with the switch next to
the microSD slot.
- A bosch BMA223 accelerometer is connected to the I2C bus of A64 SoC.
- Wi-Fi and Bluetooth are available via a RTL8723CS chip, similar to the
one in Pinebook.
This commit adds a basically usable device tree for it, implementing
most of the features mentioned above. HDMI is not supported now because
bad LCD-HDMI coexistence situation of mainline A64 display driver, and
the front camera currently lacks a driver and a facility to share the
bus with the rear one.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../boot/dts/allwinner/sun50i-a64-pinetab.dts | 461 ++
2 files changed, 462 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index cf4f78617c3f..6dad63881cd3 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-lts.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
new file mode 100644
index ..1dfa3668636e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "PineTab";
+ compatible = "pine64,pinetab", "allwinner,sun50i-a64";
+
+ aliases {
+ serial0 =
+ ethernet0 =
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <8>;
+ enable-gpios = < 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
+ power-supply = <_bl>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ i2c-csi {
+ compatible = "i2c-gpio";
+ sda-gpios = < 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
+ scl-gpios = < 4 12 GPIO_ACTIVE_HIGH>; /* PE12 */
+ i2c-gpio,delay-us = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Rear camera */
+ ov5640: camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_mclk_pin>;
+ clocks = < CLK_CSI_MCLK>;
+ clock-names = "xclk";
+
+ AVDD-supply = <_dldo3>;
+
[PATCH 2/5] dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel
Feixin K101 IM2BA02 is a 10.1" 800x1280 4-lane MIPI-DSI panel.
Add device tree binding for it.
Signed-off-by: Icenowy Zheng
---
.../display/panel/feixin,k101-im2ba02.yaml| 54 +++
1 file changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
new file mode 100644
index ..7176d14893ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/feixin,k101-im2ba02.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Feixin K101 IM2BA02 10.1" MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: feixin,k101-im2ba02
+ reg: true
+ backlight: true
+ reset-gpios: true
+ avdd-supply:
+ description: regulator that supplies the AVDD voltage
+ dvdd-supply:
+ description: regulator that supplies the DVDD voltage
+ cvdd-supply:
+ description: regulator that supplies the CVDD voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - avdd-supply
+ - dvdd-supply
+ - cvdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "feixin,k101-im2ba02";
+reg = <0>;
+avdd-supply = <_dc1sw>;
+dvdd-supply = <_dc1sw>;
+cvdd-supply = <_ldo_io1>;
+reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>;
+backlight = <>;
+};
+};
+
+...
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Lima] [RFC v1 0/1] drm: lima: devfreq and cooling device support
于 2019年12月24日 GMT+08:00 下午7:28:41, Martin Blumenstingl 写到: >Hi Alyssa, > >On Mon, Dec 16, 2019 at 4:48 PM Alyssa Rosenzweig > wrote: >> >> If so much code is being duplicated over, I'm wondering if it makes >> sense for us to move some of the common devfreq code to core DRM >> helpers? >if you have any recommendation where to put it then please let me know >(I am not familiar with the DRM subsystem at all) > >my initial idea was that the devfreq logic needs the same information >that the scheduler needs (whether we're submitting something to be >executed, there was a timeout, ...). >however, looking at drivers/gpu/drm/scheduler/ this seems pretty >stand-alone so I'm not sure it should go there >also the Mali-4x0 GPUs have some "PMU" which *may* be used instead of It's optional. We cannot promise its existance on a given hardware, and I heard that at least on Allwinner H5 Mali PMU is broken. >polling the statistics internally >so this is where I realize that with my current knowledge I don't know >enough about lima, panfrost, DRM or the devfreq subsystem to get a >good idea where to put the code. > > >Martin >___ >lima mailing list >l...@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/lima -- 使用 K-9 Mail 发送自我的Android设备。 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm/sun4i: dsi: Fix video start delay computation
于 2019年10月7日 GMT+08:00 下午7:51:48, Maxime Ripard 写到: >On Mon, Oct 07, 2019 at 12:03:00AM +0800, Icenowy Zheng wrote: >> From: Jagan Teki >> >> The LCD timing definitions between Linux DRM vs Allwinner are >different, >> below diagram shows this clear differences. >> >>Active Front Sync Back >>Region Porch >Porch >> ><---><><--><--> >> //| >> // | >> // |.. > >> >> <- [hv]display -> >> <- [hv]sync_start > >> <- [hv]sync_end --> >> < [hv]total >--> >> >> <- lcd_[xy] > <- lcd_[hv]spw -> >><-- lcd_[hv]bp -> >> < lcd_[hv]t >--> >> >> The DSI driver misinterpreted the vbp term from the BSP code to refer >> only to the backporch, when in fact it was backporch + sync. Thus the >> driver incorrectly used the vertical front porch plus sync in its >> calculation of the DRQ set bit value, when it should not have >included >> the sync timing. >> >> Including additional sync timings leads to flip_done timed out as: >> >> WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 >drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 >> [CRTC:46:crtc-0] vblank wait timed out >> Modules linked in: >> CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted >5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 >> Hardware name: Allwinner sun8i Family >> Workqueue: events deferred_probe_work_func >> [] (unwind_backtrace) from [] >(show_stack+0x10/0x14) >> [] (show_stack) from [] (dump_stack+0x84/0x98) >> [] (dump_stack) from [] (__warn+0xfc/0x114) >> [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) >> [] (warn_slowpath_fmt) from [] >(drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) >> [] (drm_atomic_helper_wait_for_vblanks.part.1) from >[] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) >> [] (drm_atomic_helper_commit_tail_rpm) from [] >(commit_tail+0x40/0x6c) >> [] (commit_tail) from [] >(drm_atomic_helper_commit+0xbc/0x128) >> [] (drm_atomic_helper_commit) from [] >(restore_fbdev_mode_atomic+0x1cc/0x1dc) >> [] (restore_fbdev_mode_atomic) from [] >(drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) >> [] (drm_fb_helper_restore_fbdev_mode_unlocked) from >[] (drm_fb_helper_set_par+0x30/0x54) >> [] (drm_fb_helper_set_par) from [] >(fbcon_init+0x560/0x5ac) >> [] (fbcon_init) from [] (visual_init+0xbc/0x104) >> [] (visual_init) from [] >(do_bind_con_driver+0x1b0/0x390) >> [] (do_bind_con_driver) from [] >(do_take_over_console+0x13c/0x1c4) >> [] (do_take_over_console) from [] >(do_fbcon_takeover+0x74/0xcc) >> [] (do_fbcon_takeover) from [] >(notifier_call_chain+0x44/0x84) >> [] (notifier_call_chain) from [] >(__blocking_notifier_call_chain+0x48/0x60) >> [] (__blocking_notifier_call_chain) from [] >(blocking_notifier_call_chain+0x18/0x20) >> [] (blocking_notifier_call_chain) from [] >(register_framebuffer+0x1e0/0x2f8) >> [] (register_framebuffer) from [] >(__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) >> [] (__drm_fb_helper_initial_config_and_unlock) from >[] (drm_fbdev_client_hotplug+0xe8/0x1b8) >> [] (drm_fbdev_client_hotplug) from [] >(drm_fbdev_generic_setup+0x88/0x118) >> [] (drm_fbdev_generic_setup) from [] >(sun4i_drv_bind+0x128/0x160) >> [] (sun4i_drv_bind) from [] >(try_to_bring_up_master+0x164/0x1a0) >> [] (try_to_bring_up_master) from [] >(__component_add+0x94/0x140) >> [] (__component_add) from [] >(sun6i_dsi_probe+0x144/0x234) >> [] (sun6i_dsi_probe) from [] >(platform_drv_probe+0x48/0x9c) >> [] (platform_drv_probe) from [] >(really_probe+0x1dc/0x2c8) >> [] (really_probe) from [] >(driver_probe_device+0x60/0x160) >> [] (driver_probe_device) from [] >(bus_for_each_drv+0x74/0xb8) >> [] (bus_for_each_drv) from [] >(__device_attach+0xd0/0x13c) >> [] (__device_attach) from [] >(bus_probe_device+0x84/0x8c) >> [] (bus_probe_device) from [] >(deferred_probe_work_func+0x64/0x90) >> [] (deferred_probe_work_func) fro
[PATCH v2 3/3] drm/sun4i: sun6i_mipi_dsi: fix DCS long write packet length
The packet length of DCS long write packet should not be added with 1
when constructing long write packet.
Fix this.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 8fe8051c34e6..c958ca9bae63 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -832,8 +832,8 @@ static u32 sun6i_dsi_dcs_build_pkt_hdr(struct sun6i_dsi
*dsi,
u32 pkt = msg->type;
if (msg->type == MIPI_DSI_DCS_LONG_WRITE) {
- pkt |= ((msg->tx_len + 1) & 0x) << 8;
- pkt |= (((msg->tx_len + 1) >> 8) & 0x) << 16;
+ pkt |= ((msg->tx_len) & 0x) << 8;
+ pkt |= (((msg->tx_len) >> 8) & 0x) << 16;
} else {
pkt |= (((u8 *)msg->tx_buf)[0] << 8);
if (msg->tx_len > 1)
--
2.21.0
[PATCH v2 2/3] drm/sun4i: dsi: fix the overhead of the horizontal front porch
The formula in the BSP kernel indicates that a 16-byte overhead is used when sending the HFP. However, this value is currently set to 6 in the sun6i_mipi_dsi driver, which makes some panels flashing. Fix this overhead value. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index b8a0d0501ca7..8fe8051c34e6 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -569,11 +569,12 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD); /* -* The frontporch is set using a blanking packet (4 -* bytes + payload + 2 bytes). Its minimal size is -* therefore 6 bytes +* The frontporch is set using a sync event (4 bytes) +* and two blanking packets (each one is 4 bytes + +* payload + 2 bytes). Its minimal size is therefore +* 16 bytes */ -#define HFP_PACKET_OVERHEAD6 +#define HFP_PACKET_OVERHEAD16 hfp = max((unsigned int)HFP_PACKET_OVERHEAD, (mode->hsync_start - mode->hdisplay) * Bpp - HFP_PACKET_OVERHEAD); -- 2.21.0
[PATCH v2 1/3] drm/sun4i: dsi: Fix video start delay computation
From: Jagan Teki The LCD timing definitions between Linux DRM vs Allwinner are different, below diagram shows this clear differences. Active Front Sync Back Region Porch Porch <---><><--><--> //| // | // |.. <- [hv]display -> <- [hv]sync_start > <- [hv]sync_end --> < [hv]total --> <- lcd_[xy] > <- lcd_[hv]spw -> <-- lcd_[hv]bp -> < lcd_[hv]t --> The DSI driver misinterpreted the vbp term from the BSP code to refer only to the backporch, when in fact it was backporch + sync. Thus the driver incorrectly used the vertical front porch plus sync in its calculation of the DRQ set bit value, when it should not have included the sync timing. Including additional sync timings leads to flip_done timed out as: WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 [CRTC:46:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 Hardware name: Allwinner sun8i Family Workqueue: events deferred_probe_work_func [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x84/0x98) [] (dump_stack) from [] (__warn+0xfc/0x114) [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) [] (drm_atomic_helper_commit_tail_rpm) from [] (commit_tail+0x40/0x6c) [] (commit_tail) from [] (drm_atomic_helper_commit+0xbc/0x128) [] (drm_atomic_helper_commit) from [] (restore_fbdev_mode_atomic+0x1cc/0x1dc) [] (restore_fbdev_mode_atomic) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] (drm_fb_helper_set_par+0x30/0x54) [] (drm_fb_helper_set_par) from [] (fbcon_init+0x560/0x5ac) [] (fbcon_init) from [] (visual_init+0xbc/0x104) [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) [] (do_bind_con_driver) from [] (do_take_over_console+0x13c/0x1c4) [] (do_take_over_console) from [] (do_fbcon_takeover+0x74/0xcc) [] (do_fbcon_takeover) from [] (notifier_call_chain+0x44/0x84) [] (notifier_call_chain) from [] (__blocking_notifier_call_chain+0x48/0x60) [] (__blocking_notifier_call_chain) from [] (blocking_notifier_call_chain+0x18/0x20) [] (blocking_notifier_call_chain) from [] (register_framebuffer+0x1e0/0x2f8) [] (register_framebuffer) from [] (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) [] (__drm_fb_helper_initial_config_and_unlock) from [] (drm_fbdev_client_hotplug+0xe8/0x1b8) [] (drm_fbdev_client_hotplug) from [] (drm_fbdev_generic_setup+0x88/0x118) [] (drm_fbdev_generic_setup) from [] (sun4i_drv_bind+0x128/0x160) [] (sun4i_drv_bind) from [] (try_to_bring_up_master+0x164/0x1a0) [] (try_to_bring_up_master) from [] (__component_add+0x94/0x140) [] (__component_add) from [] (sun6i_dsi_probe+0x144/0x234) [] (sun6i_dsi_probe) from [] (platform_drv_probe+0x48/0x9c) [] (platform_drv_probe) from [] (really_probe+0x1dc/0x2c8) [] (really_probe) from [] (driver_probe_device+0x60/0x160) [] (driver_probe_device) from [] (bus_for_each_drv+0x74/0xb8) [] (bus_for_each_drv) from [] (__device_attach+0xd0/0x13c) [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) [] (bus_probe_device) from [] (deferred_probe_work_func+0x64/0x90) [] (deferred_probe_work_func) from [] (process_one_work+0x204/0x420) [] (process_one_work) from [] (worker_thread+0x274/0x5a0) [] (worker_thread) from [] (kthread+0x11c/0x14c) [] (kthread) from [] (ret_from_fork+0x14/0x2c) Exception stack(0xde539fb0 to 0xde539ff8) 9fa0: 9fc0: 9fe0: 0013 ---[ end trace 495200a78b24980e ]--- random: fast init done [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] flip_done timed out With the terms(as described in above diagram) fixed, the panel displays correctly without any timeouts. Tested-by: Merlijn Wajer Signed-off-by: Jagan Teki ---
[PATCH v2 0/3] drm/sun4i: dsi: misc fixes
This patchset contains several fixes to the sun6i_mipi_dsi driver. First, it's a rebased version of video start delay porch fix from Jagan Teki. The next patch fixes the overhead of HFP packet, according to the source code of BSP [1]. The final patch fixes DCS long write, which fixes initialization issue with a panel with ST7703 controller (XBD599 panel used by PinePhone). This seems to be a misread of [2]. (The formula in [2] is para_num+1, and the code of the sun6i_mipi_dsi driver uses tx_len, which is the length including the command; thus tx_len is equal to para_num+1, so it shouldn't be added with 1 for another time.) Icenowy Zheng (2): drm/sun4i: dsi: fix the overhead of the horizontal front porch drm/sun4i: sun6i_mipi_dsi: fix DCS long write packet length Jagan Teki (1): drm/sun4i: dsi: Fix video start delay computation [1] https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L920 [2] https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L227 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) -- 2.21.0
Re: [linux-sunxi] [PATCH 3/3] Revert "drm/sun4i: dsi: Rework a bit the hblk calculation"
在 2019-10-06日的 22:44 +0800，Icenowy Zheng写道： > 在 2019-10-03四的 09:53 +0530，Jagan Teki写道： > > Hi Wens, > > > > On Tue, Oct 1, 2019 at 1:34 PM Icenowy Zheng > > wrote: > > > This reverts commit 62e7511a4f4dcf07f753893d3424decd9466c98b. > > > > > > This commit, although claimed as a refactor, in fact changed the > > > formula. > > > > > > By expanding the original formula, we can find that the const 10 > > > is > > > not > > > substracted, instead it's added to the value (because 10 is > > > negative > > > when calculating hsa, and hsa itself is negative when calculating > > > hblk). > > > This breaks the similar pattern to other formulas, so restoring > > > the > > > original formula is more proper. > > > > > > Signed-off-by: Icenowy Zheng > > > --- > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 ++--- > > > 1 file changed, 2 insertions(+), 7 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > index 2d3e822a7739..cb5fd19c0d0d 100644 > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > @@ -577,14 +577,9 @@ static void sun6i_dsi_setup_timings(struct > > > sun6i_dsi *dsi, > > > (mode->hsync_start - mode->hdisplay) * > > > Bpp - HFP_PACKET_OVERHEAD); > > > > > > /* > > > -* The blanking is set using a sync event (4 > > > bytes) > > > -* and a blanking packet (4 bytes + payload + 2 > > > -* bytes). Its minimal size is therefore 10 > > > bytes. > > > +* hblk seems to be the line + porches length. > > > */ > > > -#define HBLK_PACKET_OVERHEAD 10 > > > - hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, > > > - (mode->htotal - (mode->hsync_end - > > > mode- > > > > hsync_start)) * Bpp - > > > - HBLK_PACKET_OVERHEAD); > > > + hblk = mode->htotal * Bpp - hsa; > > > > The original formula is correct according to BSP [1] and work with > > my > > panels which I have tested before. May be the horizontal timings on > > panels you have leads to negative value. > > Do you tested the same timing with BSP kernel? > > It's quite difficult to get a negative value here, because the value > is > quite big (includes mode->hdisplay * Bpp). By re-checking with the BSP source code, I found that the constant in the HFP formula is indeed wrong -- it should be 16, not 6. > > Strangely, only change the formula here back makes the timing > translated from FEX file works (tested on PineTab and PinePhone > production ver). The translation rule is from [1]. > > So I still insist on the patch because it's needed by experiment. > > [1] http://linux-sunxi.org/LCD > > > [1] > > https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L919
Re: [linux-sunxi] [PATCH 3/3] Revert "drm/sun4i: dsi: Rework a bit the hblk calculation"
在 2019-10-03四的 09:53 +0530，Jagan Teki写道： > Hi Wens, > > On Tue, Oct 1, 2019 at 1:34 PM Icenowy Zheng wrote: > > This reverts commit 62e7511a4f4dcf07f753893d3424decd9466c98b. > > > > This commit, although claimed as a refactor, in fact changed the > > formula. > > > > By expanding the original formula, we can find that the const 10 is > > not > > substracted, instead it's added to the value (because 10 is > > negative > > when calculating hsa, and hsa itself is negative when calculating > > hblk). > > This breaks the similar pattern to other formulas, so restoring the > > original formula is more proper. > > > > Signed-off-by: Icenowy Zheng > > --- > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 ++--- > > 1 file changed, 2 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > index 2d3e822a7739..cb5fd19c0d0d 100644 > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > @@ -577,14 +577,9 @@ static void sun6i_dsi_setup_timings(struct > > sun6i_dsi *dsi, > > (mode->hsync_start - mode->hdisplay) * > > Bpp - HFP_PACKET_OVERHEAD); > > > > /* > > -* The blanking is set using a sync event (4 bytes) > > -* and a blanking packet (4 bytes + payload + 2 > > -* bytes). Its minimal size is therefore 10 bytes. > > +* hblk seems to be the line + porches length. > > */ > > -#define HBLK_PACKET_OVERHEAD 10 > > - hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, > > - (mode->htotal - (mode->hsync_end - mode- > > >hsync_start)) * Bpp - > > - HBLK_PACKET_OVERHEAD); > > + hblk = mode->htotal * Bpp - hsa; > > The original formula is correct according to BSP [1] and work with my > panels which I have tested before. May be the horizontal timings on > panels you have leads to negative value. Do you tested the same timing with BSP kernel? It's quite difficult to get a negative value here, because the value is quite big (includes mode->hdisplay * Bpp). Strangely, only change the formula here back makes the timing translated from FEX file works (tested on PineTab and PinePhone production ver). The translation rule is from [1]. So I still insist on the patch because it's needed by experiment. [1] http://linux-sunxi.org/LCD > > [1] > https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L919
Re: [linux-sunxi] [PATCH 1/3] Revert "drm/sun4i: dsi: Change the start delay calculation"
于 2019年10月3日 GMT+08:00 下午9:19:16, Maxime Ripard 写到: >On Thu, Oct 03, 2019 at 12:38:43PM +0530, Jagan Teki wrote: >> On Tue, Oct 1, 2019 at 1:33 PM Icenowy Zheng wrote: >> > >> > This reverts commit da676c6aa6413d59ab0a80c97bbc273025e640b2. >> > >> > The original commit adds a start parameter to the calculation of >the >> > start delay according to some old BSP versions from Allwinner. >However, >> > there're two ways to add this delay -- add it in DSI controller or >add >> > it in the TCON. Add it in both controllers won't work. >> > >> > The code before this commit is picked from new versions of BSP >kernel, >> > which has a comment for the 1 that says "put start_delay to tcon". >By >> > checking the sun4i_tcon0_mode_set_cpu() in sun4i_tcon driver, it >has >> > already added this delay, so we shouldn't repeat to add the delay >in DSI >> > controller, otherwise the timing won't match. >> >> Thanks for this change. look like this is proper reason for adding + >> 1. also adding bsp code links here might help for future reference. >> >> Otherwise, >> >> Reviewed-by: Jagan Teki > >The commit log was better in this one. I ended up merging this one, >with your R-b. Please note that Jagan's v11 3/7 is still needed. > >Maxime -- 使用 K-9 Mail 发送自我的Android设备。
Re: [PATCH v11 4/7] dt-bindings: sun6i-dsi: Add VCC-DSI supply property
于 2019年10月3日 GMT+08:00 下午7:47:33, Maxime Ripard 写到: >On Thu, Oct 03, 2019 at 12:15:24PM +0530, Jagan Teki wrote: >> Allwinner MIPI DSI controllers are supplied with SoC DSI >> power rails via VCC-DSI pin. >> >> Some board still work without supplying this but give more >> faith on datasheet and hardware schematics and document this >> supply property in required property list. >> >> Reviewed-by: Rob Herring >> Tested-by: Merlijn Wajer >> Signed-off-by: Jagan Teki >> --- >> .../bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml | 3 >+++ >> 1 file changed, 3 insertions(+) >> >> diff --git >a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml >b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml >> index 47950fced28d..9d4c25b104f6 100644 >> --- >a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml >> +++ >b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml >> @@ -36,6 +36,9 @@ properties: >>resets: >> maxItems: 1 >> >> + vcc-dsi-supply: >> +description: VCC-DSI power supply of the DSI encoder >> + > >The driver treats it as mandatory, so I've added it to the binding, as >suggested by the commit log. No. The regulator_get function will return dummy regulator, rather than fail, if the regulator is not specified. > >Maxime -- 使用 K-9 Mail 发送自我的Android设备。
Re: [PATCH v11 2/7] drm/sun4i: dsi: Update start value in video start delay
于 2019年10月3日 GMT+08:00 下午2:45:22, Jagan Teki 写到:
>start value in video start delay was changed in
>commit da676c6aa641 ("drm/sun4i: dsi: Change the start delay
>calculation")
>to match the legacy BSP driver [1].
>
>So, using this existing start delay computation gives the wrong
>start delay value for the "bananapi,s070wv20-ct16" panel. Due to
>this the panel trigger below flip_done timed out as during kernel
>bootup:
>
>WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429
>drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0
> [CRTC:46:crtc-0] vblank wait timed out
> Modules linked in:
>CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: GW
>5.1.0-next-20190514-00025-gf928bc7cc146 #15
> Hardware name: Allwinner sun8i Family
> Workqueue: events deferred_probe_work_func
>[] (unwind_backtrace) from []
>(show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x84/0x98)
> [] (dump_stack) from [] (__warn+0xfc/0x114)
> [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68)
>[] (warn_slowpath_fmt) from []
>(drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0)
>[] (drm_atomic_helper_wait_for_vblanks.part.1) from
>[] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c)
>[] (drm_atomic_helper_commit_tail_rpm) from []
>(commit_tail+0x40/0x6c)
>[] (commit_tail) from []
>(drm_atomic_helper_commit+0xbc/0x128)
>[] (drm_atomic_helper_commit) from []
>(restore_fbdev_mode_atomic+0x1cc/0x1dc)
>[] (restore_fbdev_mode_atomic) from []
>(drm_fb_helper_pan_display+0xac/0x1d0)
>[] (drm_fb_helper_pan_display) from []
>(fb_pan_display+0xcc/0x134)
>[] (fb_pan_display) from []
>(bit_update_start+0x14/0x30)
>[] (bit_update_start) from []
>(fbcon_switch+0x3d8/0x4e0)
>[] (fbcon_switch) from []
>(redraw_screen+0x174/0x238)
>[] (redraw_screen) from []
>(fbcon_prepare_logo+0x3c4/0x400)
>[] (fbcon_prepare_logo) from []
>(fbcon_init+0x3c8/0x5ac)
> [] (fbcon_init) from [] (visual_init+0xbc/0x104)
>[] (visual_init) from []
>(do_bind_con_driver+0x1b0/0x390)
>[] (do_bind_con_driver) from []
>(do_take_over_console+0x13c/0x1c4)
>[] (do_take_over_console) from []
>(do_fbcon_takeover+0x74/0xcc)
>[] (do_fbcon_takeover) from []
>(notifier_call_chain+0x44/0x84)
>[] (notifier_call_chain) from []
>(__blocking_notifier_call_chain+0x48/0x60)
>[] (__blocking_notifier_call_chain) from []
>(blocking_notifier_call_chain+0x18/0x20)
>[] (blocking_notifier_call_chain) from []
>(register_framebuffer+0x1e0/0x2f8)
>[] (register_framebuffer) from []
>(__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c)
>[] (__drm_fb_helper_initial_config_and_unlock) from
>[] (drm_fbdev_client_hotplug+0xe8/0x1b8)
>[] (drm_fbdev_client_hotplug) from []
>(drm_fbdev_generic_setup+0x88/0x118)
>[] (drm_fbdev_generic_setup) from []
>(sun4i_drv_bind+0x128/0x160)
>[] (sun4i_drv_bind) from []
>(try_to_bring_up_master+0x164/0x1a0)
>[] (try_to_bring_up_master) from []
>(__component_add+0x94/0x140)
>[] (__component_add) from []
>(sun6i_dsi_probe+0x144/0x234)
>[] (sun6i_dsi_probe) from []
>(platform_drv_probe+0x48/0x9c)
>[] (platform_drv_probe) from []
>(really_probe+0x1dc/0x2c8)
>[] (really_probe) from []
>(driver_probe_device+0x60/0x160)
>[] (driver_probe_device) from []
>(bus_for_each_drv+0x74/0xb8)
>[] (bus_for_each_drv) from []
>(__device_attach+0xd0/0x13c)
>[] (__device_attach) from []
>(bus_probe_device+0x84/0x8c)
>[] (bus_probe_device) from []
>(deferred_probe_work_func+0x64/0x90)
>[] (deferred_probe_work_func) from []
>(process_one_work+0x204/0x420)
>[] (process_one_work) from []
>(worker_thread+0x274/0x5a0)
> [] (worker_thread) from [] (kthread+0x11c/0x14c)
> [] (kthread) from [] (ret_from_fork+0x14/0x2c)
> Exception stack(0xde539fb0 to 0xde539ff8)
>9fa0:
>
>9fc0:
>
> 9fe0: 0013
> ---[ end trace 755e10f62b83f396 ]---
> Console: switching to colour frame buffer device 100x30
>[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0]
>flip_done timed out
>[drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
>[CONNECTOR:48:DSI-1] flip_done timed out
>[drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
>[PLANE:30:plane-0] flip_done timed out
>
>To fix this, adjust the start delay computation according to the
>new BSP code [2].
>
>Unfortunately we don't have any evidence or documentation for this
>reassignment to 1 in new bsp, but it is working with below mainline
>supported panels in A33, A64.
>- bananapi,s070wv20-ct16
>- feiyang,fy07024di26a30d
>- techstar,ts8550b
>
>So, use the start as per new bsp code since it is working in all
>the supported panels.
>
>[1]
>https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/legacy/disp/de_bsp/de/ebios/de_dsi.c#L682
>[2]
>https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/lowlevel_sun8iw5/de_dsi.c#L807
>
>Signed-off-by: Jagan Teki
>---
>
Re: [PATCH v11 1/7] drm/sun4i: dsi: Fix TCON DRQ set bits
于 2019年10月3日 GMT+08:00 下午2:45:21, Jagan Teki 写到: >The LCD timing definitions between Linux DRM vs Allwinner are >different, >below diagram shows this clear differences. > > Active Front Sync Back > Region Porch Porch ><---><><--><--> > //| > // | >// |.. > > ><- [hv]display -> ><- [hv]sync_start > ><- [hv]sync_end --> >< [hv]total >--> > ><- lcd_[xy] ><- lcd_[hv]spw -> > <-- lcd_[hv]bp -> >< lcd_[hv]t >--> > >The DSI driver misinterpreted the hbp term from the BSP code to refer >only to the backporch, when in fact it was backporch + sync. Thus the >driver incorrectly used the horizontal front porch plus sync in its >calculation of the DRQ set bit value, when it should not have included >the sync timing. > >Including additional sync timings leads to flip_done timed out as: I don't think attaching this error infomation is useful at all. It's just timing mismatch. > >WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 >drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 >[CRTC:46:crtc-0] vblank wait timed out >Modules linked in: >CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted >5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 >Hardware name: Allwinner sun8i Family >Workqueue: events deferred_probe_work_func >[] (unwind_backtrace) from [] >(show_stack+0x10/0x14) >[] (show_stack) from [] (dump_stack+0x84/0x98) >[] (dump_stack) from [] (__warn+0xfc/0x114) >[] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) >[] (warn_slowpath_fmt) from [] >(drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) >[] (drm_atomic_helper_wait_for_vblanks.part.1) from >[] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) >[] (drm_atomic_helper_commit_tail_rpm) from [] >(commit_tail+0x40/0x6c) >[] (commit_tail) from [] >(drm_atomic_helper_commit+0xbc/0x128) >[] (drm_atomic_helper_commit) from [] >(restore_fbdev_mode_atomic+0x1cc/0x1dc) >[] (restore_fbdev_mode_atomic) from [] >(drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) >[] (drm_fb_helper_restore_fbdev_mode_unlocked) from >[] (drm_fb_helper_set_par+0x30/0x54) >[] (drm_fb_helper_set_par) from [] >(fbcon_init+0x560/0x5ac) >[] (fbcon_init) from [] (visual_init+0xbc/0x104) >[] (visual_init) from [] >(do_bind_con_driver+0x1b0/0x390) >[] (do_bind_con_driver) from [] >(do_take_over_console+0x13c/0x1c4) >[] (do_take_over_console) from [] >(do_fbcon_takeover+0x74/0xcc) >[] (do_fbcon_takeover) from [] >(notifier_call_chain+0x44/0x84) >[] (notifier_call_chain) from [] >(__blocking_notifier_call_chain+0x48/0x60) >[] (__blocking_notifier_call_chain) from [] >(blocking_notifier_call_chain+0x18/0x20) >[] (blocking_notifier_call_chain) from [] >(register_framebuffer+0x1e0/0x2f8) >[] (register_framebuffer) from [] >(__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) >[] (__drm_fb_helper_initial_config_and_unlock) from >[] (drm_fbdev_client_hotplug+0xe8/0x1b8) >[] (drm_fbdev_client_hotplug) from [] >(drm_fbdev_generic_setup+0x88/0x118) >[] (drm_fbdev_generic_setup) from [] >(sun4i_drv_bind+0x128/0x160) >[] (sun4i_drv_bind) from [] >(try_to_bring_up_master+0x164/0x1a0) >[] (try_to_bring_up_master) from [] >(__component_add+0x94/0x140) >[] (__component_add) from [] >(sun6i_dsi_probe+0x144/0x234) >[] (sun6i_dsi_probe) from [] >(platform_drv_probe+0x48/0x9c) >[] (platform_drv_probe) from [] >(really_probe+0x1dc/0x2c8) >[] (really_probe) from [] >(driver_probe_device+0x60/0x160) >[] (driver_probe_device) from [] >(bus_for_each_drv+0x74/0xb8) >[] (bus_for_each_drv) from [] >(__device_attach+0xd0/0x13c) >[] (__device_attach) from [] >(bus_probe_device+0x84/0x8c) >[] (bus_probe_device) from [] >(deferred_probe_work_func+0x64/0x90) >[] (deferred_probe_work_func) from [] >(process_one_work+0x204/0x420) >[] (process_one_work) from [] >(worker_thread+0x274/0x5a0) >[] (worker_thread) from [] (kthread+0x11c/0x14c) >[] (kthread) from [] (ret_from_fork+0x14/0x2c) >Exception stack(0xde539fb0 to 0xde539ff8) >9fa0: > >9fc0: > >9fe0: 0013 >---[ end trace b57eb1e5c64c6b8b ]--- >random: fast init done >[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] >flip_done timed out >[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* >[CONNECTOR:48:DSI-1] flip_done timed out
Re: [PATCH 0/3] drm/sun4i: dsi: misc timing fixes
在 2019-10-02三的 12:36 +0200，Maxime Ripard写道： > Hi, > > On Tue, Oct 01, 2019 at 04:02:50PM +0800, Icenowy Zheng wrote: > > This patchset fixes some portion of timing calculation in > > sun6i_mipi_dsi > > driver according to the BSP driver. > > > > Two of the patches are reverting, one is fixing some misread of the > > BSP > > source code, another is fixing a wrong refactor that actually > > breaks the > > formula. > > > > The other non-reverting patch is fixing a porch error which is > > usually > > seen in the original driver commit. Most of porch errors are then > > fixed, > > but this one gets ignored. > > > > By applying these patches, several DSI panels are tested to be > > driven > > properly by the timing provided by the vendor, including the LCD > > panel > > of PinePhone "Don't Be Evil" DevKit, the final PinePhone panel and > > the > > panel on PineTab. Without these patches they need dirty timing > > hacks to > > work. > > Thanks for going after that issue. Can you provide references to the > BSP on the various patches? For patch 1: [1] for setting delay 1 in DSI controller, [2] for setting real delay in TCON controller. For patch 2: [3] Patch 3 is reverting a breaking change, so I didn't check it in the BSP. It can be verified by mathmatical calculation. [1] https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L730 [2] https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_lcd.c#L369 [3] https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L780 > > Ideally, having the panel drivers, and the panel datasheet would > help. > > Thanks! > Maxime > > PS: where can we get one of those devices?
[PATCH 2/3] drm/sun4i: dsi: fix DRQ calculation
According to the BSP source code, when calculating the magic DRQ value
outside burst mode, a formula of "lcd_ht - lcd_x - lcd_hbp", which is
interpreted as right margin (HFP value). However, currently the
sun6i_mipi_dsi driver code calculates it wrongly as HFP + sync length,
which lead to timing error.
Fix the DRQ calculation by change it to use HFP.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index c86e11631ebc..2d3e822a7739 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -436,9 +436,9 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
SUN6I_DSI_BURST_LINE_SYNC_POINT(SUN6I_DSI_SYNC_POINT));
val = SUN6I_DSI_TCON_DRQ_ENABLE_MODE;
- } else if ((mode->hsync_end - mode->hdisplay) > 20) {
+ } else if ((mode->hsync_start - mode->hdisplay) > 20) {
/* Maagic */
- u16 drq = (mode->hsync_end - mode->hdisplay) - 20;
+ u16 drq = (mode->hsync_start - mode->hdisplay) - 20;
drq *= mipi_dsi_pixel_format_to_bpp(device->format);
drq /= 32;
--
2.21.0
[PATCH 3/3] Revert "drm/sun4i: dsi: Rework a bit the hblk calculation"
This reverts commit 62e7511a4f4dcf07f753893d3424decd9466c98b. This commit, although claimed as a refactor, in fact changed the formula. By expanding the original formula, we can find that the const 10 is not substracted, instead it's added to the value (because 10 is negative when calculating hsa, and hsa itself is negative when calculating hblk). This breaks the similar pattern to other formulas, so restoring the original formula is more proper. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 2d3e822a7739..cb5fd19c0d0d 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -577,14 +577,9 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, (mode->hsync_start - mode->hdisplay) * Bpp - HFP_PACKET_OVERHEAD); /* -* The blanking is set using a sync event (4 bytes) -* and a blanking packet (4 bytes + payload + 2 -* bytes). Its minimal size is therefore 10 bytes. +* hblk seems to be the line + porches length. */ -#define HBLK_PACKET_OVERHEAD 10 - hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, - (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp - - HBLK_PACKET_OVERHEAD); + hblk = mode->htotal * Bpp - hsa; /* * And I'm not entirely sure what vblk is about. The driver in -- 2.21.0
[PATCH 0/3] drm/sun4i: dsi: misc timing fixes
This patchset fixes some portion of timing calculation in sun6i_mipi_dsi driver according to the BSP driver. Two of the patches are reverting, one is fixing some misread of the BSP source code, another is fixing a wrong refactor that actually breaks the formula. The other non-reverting patch is fixing a porch error which is usually seen in the original driver commit. Most of porch errors are then fixed, but this one gets ignored. By applying these patches, several DSI panels are tested to be driven properly by the timing provided by the vendor, including the LCD panel of PinePhone "Don't Be Evil" DevKit, the final PinePhone panel and the panel on PineTab. Without these patches they need dirty timing hacks to work. Icenowy Zheng (3): Revert "drm/sun4i: dsi: Change the start delay calculation" drm/sun4i: dsi: fix DRQ calculation Revert "drm/sun4i: dsi: Rework a bit the hblk calculation" drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) -- 2.21.0
[PATCH 1/3] Revert "drm/sun4i: dsi: Change the start delay calculation"
This reverts commit da676c6aa6413d59ab0a80c97bbc273025e640b2.
The original commit adds a start parameter to the calculation of the
start delay according to some old BSP versions from Allwinner. However,
there're two ways to add this delay -- add it in DSI controller or add
it in the TCON. Add it in both controllers won't work.
The code before this commit is picked from new versions of BSP kernel,
which has a comment for the 1 that says "put start_delay to tcon". By
checking the sun4i_tcon0_mode_set_cpu() in sun4i_tcon driver, it has
already added this delay, so we shouldn't repeat to add the delay in DSI
controller, otherwise the timing won't match.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 1636344ba9ec..c86e11631ebc 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -365,8 +365,7 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
struct drm_display_mode *mode)
{
- u16 start = clamp(mode->vtotal - mode->vdisplay - 10, 8, 100);
- u16 delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start;
+ u16 delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1;
if (delay > mode->vtotal)
delay = delay % mode->vtotal;
--
2.21.0
[PATCH] drm/lima: allow to retry when allocating memory for BO
Currently, when allocating the memory for BO by Mesa, the lima kernel
driver set only GFP_DMA32 flag; and this allocation may fail when the
memory is relatively adequate, thus retrying is needed.
Add the GFP flags for retrying memory allocation.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/lima/lima_object.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/lima/lima_object.c
b/drivers/gpu/drm/lima/lima_object.c
index 87123b1d083c..1389aa1b948b 100644
--- a/drivers/gpu/drm/lima/lima_object.c
+++ b/drivers/gpu/drm/lima/lima_object.c
@@ -91,7 +91,9 @@ struct lima_bo *lima_bo_create(struct lima_device *dev, u32
size,
goto err_out;
}
} else {
- mapping_set_gfp_mask(bo->gem.filp->f_mapping, GFP_DMA32);
+ mapping_set_gfp_mask(bo->gem.filp->f_mapping,
+GFP_DMA32 | __GFP_RETRY_MAYFAIL |
+__GFP_NOWARN);
bo->pages = drm_gem_get_pages(>gem);
if (IS_ERR(bo->pages)) {
ret = ERR_CAST(bo->pages);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard 写到: >On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: >> > > Maybe instead of edp-connector one would introduce integrator's >specific >> > > connector, for example with compatible >"olimex,teres-edp-connector" >> > > which should follow edp abstract connector rules? This will be at >least >> > > consistent with below presentation[1] - eDP requirements depends >on >> > > integrator. Then if olimex has standard way of dealing with >panels >> > > present in olimex/teres platforms the driver would then create >> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I >guess. >> > > Anyway it still looks fishy for me :), maybe because I am not >> > > familiarized with details of these platforms. >> > >> > That makes sense yes >> >> Actually, it makes no sense at all. Current implementation for >anx6345 >> driver works fine as is with any panel specified assuming panel >delays >> are long enough for connected panel. It just doesn't use panel >timings >> from the driver. Creating a platform driver for connector itself >looks >> redundant since it can't be reused, it doesn't describe actual >> hardware and it's just defeats purpose of DT by introducing >> board-specific code. > >I'm not sure where you got the idea that the purpose of DT is to not >have any board-specific code. > >It's perfectly fine to have some, that's even why there's a compatible >assigned to each and every board. > >What the DT is about is allowing us to have a generic behaviour that >we can detect: we can have a given behaviour for a given board, and a >separate one for another one, and this will be evaluated at runtime. > >This is *exactly* what this is about: we can have a compatible that >sets a given, more specific, behaviour (olimex,teres-edp-connector) >while saying that this is compatible with the generic behaviour >(edp-connector). That way, any OS will know what quirk to apply if >needed, and if not that it can use the generic behaviour. > >And we could create a generic driver, for the generic behaviour if >needed. > >> There's another issue: if we introduce edp-connector we'll have to >> specify power up delays somewhere (in dts? or in platform driver?), >so >> edp-connector doesn't really solve the issue of multiple panels with >> same motherboard. > >And that's what that compatible is about :) Maybe we can introduce a connector w/o any driver just like hdmi-connector? > >> I'd say DT overlays should be preferred solution here, not another >> connector binding. > >Overlays are a way to apply a device tree dynamically. It's orthogonal >to the binding. > >Maxime > >-- >Maxime Ripard, Bootlin >Embedded Linux and Kernel engineering >https://bootlin.com -- 使用 K-9 Mail 发送自我的Android设备。
Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
于 2019年2月5日 GMT+08:00 上午12:26:43, Vasily Khoruzhick 写到:
>On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard
> wrote:
>>
>> Hi,
>>
>> On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
>> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i:
>rgb:
>> > Validate the clock rate") prevents some panel and bridges from
>working with
>> > sun4i driver.
>> >
>> > Unfortunately, dotclock frequency for some modes are not achievable
>on
>> > sunxi hardware, and there's a slight deviation in rate returned by
>> > clk_round_rate(), so they fail this check.
>> >
>> > Experiments show that panels and bridges work fine with this slight
>> > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP
>panel
>> > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and
>works just
>> > fine.
>> >
>> > This patch adds a 1% tolerence to the dot clock check when bridge
>is
>> > connected.
>> >
>> > Signed-off-by: Vasily Khoruzhick
>>
>> I'm not sure we want to make exceptions for all the hardware
>> combination we face, but we should go for something more generic (and
>> easier to maintain instead).
>>
>> IIRC, from the previous discussion, HDMI had a tolerancy requirement
>> in the standard. Do you know if there's such a thing for eDP? That
>> would solve the issue for all the eDP displays at once.
>
>I don't have access to eDP standard - vesa.org says it's available to
>members only.
Try out to grab an old version?
I remember 1.0 is open.
>
>> Maxime
>>
>> --
>> Maxime Ripard, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>
>___
>linux-arm-kernel mailing list
>linux-arm-ker...@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: gpu: add bus clock for Mali Midgard GPUs
在 2018-11-27二的 15:42 +0800，Icenowy Zheng写道： > Some SoCs adds a bus clock gate to the Mali Midgard GPU. > > Add the binding for the bus clock. > > Signed-off-by: Icenowy Zheng Could anyone have a check on this patchset? > --- > Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 6 > ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali- > midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali- > midgard.txt > index 18a2cde2e5f3..02f870cd60e6 100644 > --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > @@ -31,6 +31,12 @@ Optional properties: > > - clocks : Phandle to clock for the Mali Midgard device. > > +- clock-names : Specify the names of the clocks specified in clocks > + when multiple clocks are present. > +* bus: bus clock for the GPU > +* core: clock driving the GPU itself (When only one clock is > present, > + assume it's this clock.) > + > - mali-supply : Phandle to regulator for the Mali device. Refer to >Documentation/devicetree/bindings/regulator/regulator.txt for > details. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] dt-bindings: gpu: add Allwinner H6 Mali Midgard binding
Allwinner H6 SoC uses a Mali T720 GPU, which is one of the GPUs in the
Midgard GPU product line.
Add binding for the H6 Mali Midgard GPU.
Signed-off-by: Icenowy Zheng
---
.../devicetree/bindings/gpu/arm,mali-midgard.txt| 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index 02f870cd60e6..c897dd7be48f 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -18,6 +18,7 @@ Required properties:
+ "amlogic,meson-gxm-mali"
+ "rockchip,rk3288-mali"
+ "rockchip,rk3399-mali"
++ "allwinner,sun50i-h6-mali"
- reg : Physical base address of the device and length of the register area.
@@ -44,6 +45,18 @@ Optional properties:
for details.
+Vendor-specific bindings
+
+
+The Mali GPU is integrated very differently from one SoC to
+another. In order to accomodate those differences, you have the option
+to specify one more vendor-specific compatible, among:
+
+ - allwinner,sun50i-h6-mali
+Required properties:
+ * resets: phandle to the reset line for the GPU
+
+
Example for a Mali-T760:
gpu@ffa3 {
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: gpu: add bus clock for Mali Midgard GPUs
Some SoCs adds a bus clock gate to the Mali Midgard GPU. Add the binding for the bus clock. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt index 18a2cde2e5f3..02f870cd60e6 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt @@ -31,6 +31,12 @@ Optional properties: - clocks : Phandle to clock for the Mali Midgard device. +- clock-names : Specify the names of the clocks specified in clocks + when multiple clocks are present. +* bus: bus clock for the GPU +* core: clock driving the GPU itself (When only one clock is present, + assume it's this clock.) + - mali-supply : Phandle to regulator for the Mali device. Refer to Documentation/devicetree/bindings/regulator/regulator.txt for details. -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/sun4i: tcon: prevent tcon->panel dereference if NULL
在 2018-10-08一的 11:21 +0200，Maxime Ripard写道：
> On Fri, Oct 05, 2018 at 11:59:51PM +0200, Giulio Benetti wrote:
> > If tcon->panel pointer is NULL, trying to dereference from it
> > (i.e. tcon->panel->connector) will cause a null pointer
> > dereference.
> >
> > Add tcon->panel null pointer check before calling
> > sun4i_tcon0_mode_set_dithering().
> >
> > Signed-off-by: Giulio Benetti
> > Fixes: f11adcecbd5f ("drm/sun4i: tcon: Add dithering support for
> > RGB565/RGB666 LCD panels")
> > Reviewed-by: Chen-Yu Tsai
>
> Applied both, thanks!
Please bring them to 4.20.
Currently in 4.20-rc1, bridge support of sun4i-drm is broken because of
this problem.
> Maxime
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] dt-bindings: Add ANX6345 DP/eDP transmitter binding
于 2018年10月26日 GMT+08:00 上午2:30:03, Rob Herring 写到: >On Thu, Oct 18, 2018 at 08:40:11PM +0800, Icenowy Zheng wrote: >> 在 2018-10-18四的 14:23 +0300，Laurent Pinchart写道： >> > Hi Icenowy, >> > >> > On Thursday, 18 October 2018 13:00:05 EEST Icenowy Zheng wrote: >> > > 在 2018-10-18四的 11:53 +0300，Laurent Pinchart写道： >> > > > On Thursday, 18 October 2018 10:33:22 EEST Icenowy Zheng wrote: >> > > > > The ANX6345 is an ultra-low power DisplayPort/eDP transmitter >> > > > > designed >> > > > > for portable devices. >> > > > > >> > > > > Add a binding document for it. >> > > > > >> > > > > Signed-off-by: Icenowy Zheng >> > > > > --- >> > > > > >> > > > > .../bindings/display/bridge/anx6345.txt | 39 >> > > > > +++ >> > > > > >> > > > > 1 file changed, 39 insertions(+) >> > > > > create mode 100644 >> > > > > >> > > > > Documentation/devicetree/bindings/display/bridge/anx6345.txt >> > > > > >> > > > > diff --git >> > > > > >a/Documentation/devicetree/bindings/display/bridge/anx6345.txt >> > > > > >b/Documentation/devicetree/bindings/display/bridge/anx6345.txt >> > > > > new >> > > > > file >> > > > > mode 100644 >> > > > > index ..0689d4eb5f65 >> > > > > --- /dev/null >> > > > > +++ >> > > > > >b/Documentation/devicetree/bindings/display/bridge/anx6345.txt >> > > > > @@ -0,0 +1,39 @@ >> > > > > +Analogix ANX6345 eDP Transmitter >> > > > > + >> > > > > + >> > > > > +The ANX6345 is an ultra-low power Full-HD eDP transmitter >> > > > > designed >> > > > > for >> > > > > +portable devices. >> > > > > + >> > > > > +Required properties: >> > > > > + >> > > > > + - compatible : "analogix,anx6345" >> > > > > + - reg : I2C address of the device >> > > > > + - reset-gpios : Which GPIO to use for reset >> > > > > + >> > > > > +Optional properties: >> > > > > + >> > > > > + - dvdd12-supply: Regulator for 1.2V digital core >> > > > > power. >> > > > > + - dvdd25-supply: Regulator for 2.5V digital core >> > > > > power. >> > > > >> > > > Shouldn't these to supplies be mandatory ? >> > > >> > > Yes they should. >> > > >> > > > > + - panel-supply : Regulator for the power of >> > > > > the panel. >> > > > >> > > > Shouldn't the panel supply for specified in the DT node of the >> > > > panel >> > > > ? >> > > >> > > However, eDP panel can be probed, may vary on the same device, >and >> > > we >> > > don't have a generic binding for it... >> > >> > Shouldn't we fix that ? :-) >> >> Maybe we should create a connector binding instead of a panel >binding? > >There's not any such thing as a standard eDP connector, is there? >Otherwise, that's just creating a generic panel binding in disguise. >Maybe if eDP interface is standardized enough in terms of power >control, >control lines, EDID at least sometimes present, etc., then we could eDP has the same display signal set with DP, including AUX which carries DPCD and EDID (if present). But I don't know whether other lines are standardized, including power, backlight, etc. >have >some sort of generic eDP panel/connector binding. > >Rob > >___ >linux-arm-kernel mailing list >linux-arm-ker...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/9] arm64: allwinner: a64: enable ANX6345 bridge on Pinebook
于 2018年10月18日 GMT+08:00 下午11:17:35, Vasily Khoruzhick 写到:
>Hi Icenowy,
>
>On Thursday, October 18, 2018 12:33:25 AM PDT Icenowy Zheng wrote:
>> Pinebook has an ANX6345 bridge connected to the RGB666 LCD output,
>and
>> the I2C controlling signals are connected to R_I2C bus.
>>
>> Enable it in the device tree, and add a usable EDID from the panel's
>> datasheet (at least 14" Pinebook used a panel without EDID).
>
>There's no EDID in dts and 14" Pinebook uses a panel with EDID. Is it
>leftover
>of old comment?
Yes, it is.
>
>Regards,
>Vasily
>
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> .../dts/allwinner/sun50i-a64-pinebook.dts | 43
>+++
>> 1 file changed, 43 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts index
>> 77fac84797e9..d7c14d0d61f9 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> @@ -66,6 +66,10 @@
>> };
>> };
>>
>> + {
>> +status = "okay";
>> +};
>> +
>> {
>> phys = < 0>;
>> phy-names = "usb";
>> @@ -76,6 +80,10 @@
>> status = "okay";
>> };
>>
>> + {
>> +status = "okay";
>> +};
>> +
>> {
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins>;
>> @@ -127,6 +135,27 @@
>> status = "okay";
>> };
>>
>> +_i2c {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_i2c_pins_a>;
>> +status = "okay";
>> +
>> +anx6345: anx6345@38 {
>> +compatible = "analogix,anx6345";
>> +reg = <0x38>;
>> +reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
>> +panel-supply = <_dc1sw>;
>> +dvdd25-supply = <_dldo2>;
>> +dvdd12-supply = <_fldo1>;
>> +
>> +port {
>> +anx6345_in: endpoint {
>> +remote-endpoint = <_out_anx6345>;
>> +};
>> +};
>> +};
>> +};
>> +
>> _rsb {
>> status = "okay";
>>
>> @@ -267,6 +296,20 @@
>> vcc-hdmi-supply = <_dldo1>;
>> };
>>
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_rgb666_pins>;
>> +
>> +status = "okay";
>> +};
>> +
>> +_out {
>> +tcon0_out_anx6345: endpoint@0 {
>> +reg = <0>;
>> +remote-endpoint = <_in>;
>> +};
>> +};
>> +
>> {
>> pinctrl-names = "default";
>> pinctrl-0 = <_pb_pins>;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] [DO NOT MERGE] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
在 2018-10-18四的 14:18 +0200，Maxime Ripard写道：
> On Thu, Oct 18, 2018 at 02:31:01PM +0300, Laurent Pinchart wrote:
> > Hello,
> >
> > On Thursday, 18 October 2018 12:42:58 EEST Maxime Ripard wrote:
> > > On Thu, Oct 18, 2018 at 11:18:06AM +0200, Daniel Vetter wrote:
> > > > On Thu, Oct 18, 2018 at 10:55 AM Laurent Pinchart wrote:
> > > > > On Thursday, 18 October 2018 10:33:27 EEST Icenowy Zheng
> > > > > wrote:
> > > > > > From: Chen-Yu Tsai
> > > > > >
> > > > > > The panels shipped with Allwinner devices are very
> > > > > > "generic", i.e.
> > > > > > they do not have model numbers or reliable sources of
> > > > > > information
> > > > > > for the timings (that we know of) other than the fex files
> > > > > > shipped
> > > > > > on them. The dot clock frequency provided in the fex files
> > > > > > have all
> > > > > > been rounded to the nearest MHz, as that is the unit used
> > > > > > in them.
> > > > > >
> > > > > > We were using the simple panel "urt,umsh-8596md-t" as a
> > > > > > substitute
> > > > > > for the A13 Q8 tablets in the absence of a specific model
> > > > > > for what
> > > > > > may be many different but otherwise timing compatible
> > > > > > panels. This
> > > > > > was usable without any visual artifacts or side effects,
> > > > > > until the
> > > > > > dot clock rate check was added in commit bb43d40d7c83
> > > > > > ("drm/sun4i:
> > > > > > rgb: Validate the clock rate").
> > > > > >
> > > > > > The reason this check fails is because the dotclock
> > > > > > frequency for
> > > > > > this model is 33.26 MHz, which is not achievable with our
> > > > > > dot clock
> > > > > > hardware, and the rate returned by clk_round_rate deviates
> > > > > > slightly,
> > > > > > causing the driver to reject the display mode.
> > > > > >
> > > > > > The LCD panels have some tolerance on the dot clock
> > > > > > frequency, even
> > > > > > if it's not specified in their datasheets.
> > > > > >
> > > > > > This patch adds a 5% tolerence to the dot clock check.
> > > > >
> > > > > Why do you think this shouldn't be merged ?
> > > >
> > > > It pisses of a lot of people who really insist upon accurate
> > > > timing.
> > >
> > > It's not just about accurate timings. That 5% is a made-up limit,
> > > that
> > > never have really been confirmed by looking at the typical
> > > tolerancies
> > > of panels.
> > >
> > > And while being to relaxed might make some panels work that are
> > > not
> > > working currently, it might also break some panels that currently
> > > work
> > > and won't now, and ideally, we should really be able to let those
> > > panels work if they can, and filter out resolutions if they
> > > can't.
> > >
> > > > I think a better fix would be to have a dotclock range in
> > > > drm_panel,
> > > > and some magic to figure out which one of these we can actually
> > > > do. Then tell userspace that this is the mode is should
> > > > request. That way userspace knows what the actual
> > > > dotclock/refresh
> > > > rate is, and the panel still works.
> > >
> > > It's not just about panels, but also bridges with EDID where the
> > > tolerancy is not exposed.
> >
> > Given that the tolerance is a property of the panel or bridge, I
> > agree with
> > Daniel that it should be implemented there, or at least in
> > cooperation with
> > drm_panel and drm_bridge.
>
> How are we supposed to deal with panels without any documentation
> then?
>
> > Semi-related information, I think the CEA and VESA standards allow
> > a 0.5%
> > clock tolerance. What is the maximum clock frequency deviation
> > required for
> > this platform ?
>
> Looks like it does indeed. That's definetely good to know.
Then maybe we can choose to allow 0.5% error when a bridge is attached?
>
> Thanks!
> Maxime
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/bridge: move ANA78xx driver to analogix subdirectory
As ANA78xx chips are designed and produced by Analogix Semiconductor,
Inc, move their driver codes into analogix subdirectory.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/bridge/Kconfig | 10 --
drivers/gpu/drm/bridge/Makefile| 4 ++--
drivers/gpu/drm/bridge/analogix/Kconfig| 10 ++
drivers/gpu/drm/bridge/analogix/Makefile | 1 +
.../gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c | 0
.../gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h | 0
6 files changed, 13 insertions(+), 12 deletions(-)
rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (100%)
rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h (100%)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 9eeb8ef0b174..8a7ffb3256d8 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -15,16 +15,6 @@ config DRM_PANEL_BRIDGE
menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
-config DRM_ANALOGIX_ANX78XX
- tristate "Analogix ANX78XX bridge"
- select DRM_KMS_HELPER
- select REGMAP_I2C
- ---help---
- ANX78XX is an ultra-low Full-HD SlimPort transmitter
- designed for portable devices. The ANX78XX transforms
- the HDMI output of an application processor to MyDP
- or DisplayPort.
-
config DRM_CDNS_DSI
tristate "Cadence DPI/DSI bridge"
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f8..a6c7dd7727ea 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
@@ -12,8 +11,9 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
-obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+
+obj-y += analogix/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index 80f286fa3a69..27b37aa2ea77 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,3 +1,13 @@
config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config DRM_ANALOGIX_ANX78XX
+ tristate "Analogix ANX78XX bridge"
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ ---help---
+ ANX78XX is an ultra-low Full-HD SlimPort transmitter
+ designed for portable devices. The ANX78XX transforms
+ the HDMI output of an application processor to MyDP
+ or DisplayPort.
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index cd4010ba6890..eb41be845055 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,2 +1,3 @@
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
similarity index 100%
rename from drivers/gpu/drm/bridge/analogix-anx78xx.c
rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
similarity index 100%
rename from drivers/gpu/drm/bridge/analogix-anx78xx.h
rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm/bridge: split some definitions of ANX78xx to dedicated headers
Some definitions currently in analogix-anx78xx.h are not restricted to the ANX78xx series, but also applicable to other DisplayPort transmitters by Analogix. Split out them to dedicated headers, and make analogix-anx78xx.h include them. Signed-off-by: Icenowy Zheng --- .../drm/bridge/analogix/analogix-anx78xx.h| 464 +- .../drm/bridge/analogix/analogix-i2c-dptx.h | 248 ++ .../bridge/analogix/analogix-i2c-txcommon.h | 237 + 3 files changed, 490 insertions(+), 459 deletions(-) create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h index 38753c870137..8aa1eca306d3 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h @@ -15,9 +15,12 @@ #ifndef __ANX78xx_H #define __ANX78xx_H -#define TX_P0 0x70 +#include "analogix-i2c-dptx.h" +#include "analogix-i2c-txcommon.h" + +#define TX_P0 ANALOGIX_I2C_DPTX #define TX_P1 0x7a -#define TX_P2 0x72 +#define TX_P2 ANALOGIX_I2C_TXCOMMON #define RX_P0 0x7e #define RX_P1 0x80 @@ -225,463 +228,6 @@ #define SP_CLEAR_AVMUTEBIT(4) #define SP_SET_AVMUTE BIT(0) -/***/ -/* Register definition of device address 0x70 */ -/***/ - -/* HDCP Status Register */ -#define SP_TX_HDCP_STATUS_REG 0x00 -#define SP_AUTH_FAIL BIT(5) -#define SP_AUTHEN_PASS BIT(1) - -/* HDCP Control Register 0 */ -#define SP_HDCP_CTRL0_REG 0x01 -#define SP_RX_REPEATER BIT(6) -#define SP_RE_AUTH BIT(5) -#define SP_SW_AUTH_OK BIT(4) -#define SP_HARD_AUTH_ENBIT(3) -#define SP_HDCP_ENC_EN BIT(2) -#define SP_BKSV_SRM_PASS BIT(1) -#define SP_KSVLIST_VLD BIT(0) -/* HDCP Function Enabled */ -#define SP_HDCP_FUNCTION_ENABLED (BIT(0) | BIT(1) | BIT(2) | BIT(3)) - -/* HDCP Receiver BSTATUS Register 0 */ -#defineSP_HDCP_RX_BSTATUS0_REG 0x1b -/* HDCP Receiver BSTATUS Register 1 */ -#defineSP_HDCP_RX_BSTATUS1_REG 0x1c - -/* HDCP Embedded "Blue Screen" Content Registers */ -#define SP_HDCP_VID0_BLUE_SCREEN_REG 0x2c -#define SP_HDCP_VID1_BLUE_SCREEN_REG 0x2d -#define SP_HDCP_VID2_BLUE_SCREEN_REG 0x2e - -/* HDCP Wait R0 Timing Register */ -#define SP_HDCP_WAIT_R0_TIME_REG 0x40 - -/* HDCP Link Integrity Check Timer Register */ -#define SP_HDCP_LINK_CHECK_TIMER_REG 0x41 - -/* HDCP Repeater Ready Wait Timer Register */ -#define SP_HDCP_RPTR_RDY_WAIT_TIME_REG 0x42 - -/* HDCP Auto Timer Register */ -#define SP_HDCP_AUTO_TIMER_REG 0x51 - -/* HDCP Key Status Register */ -#define SP_HDCP_KEY_STATUS_REG 0x5e - -/* HDCP Key Command Register */ -#define SP_HDCP_KEY_COMMAND_REG0x5f -#define SP_DISABLE_SYNC_HDCP BIT(2) - -/* OTP Memory Key Protection Registers */ -#define SP_OTP_KEY_PROTECT1_REG0x60 -#define SP_OTP_KEY_PROTECT2_REG0x61 -#define SP_OTP_KEY_PROTECT3_REG0x62 -#define SP_OTP_PSW10xa2 -#define SP_OTP_PSW20x7e -#define SP_OTP_PSW30xc6 - -/* DP System Control Registers */ -#define SP_DP_SYSTEM_CTRL_BASE (0x80 - 1) -/* Bits for DP System Control Register 2 */ -#define SP_CHA_STA BIT(2) -/* Bits for DP System Control Register 3 */ -#define SP_HPD_STATUS BIT(6) -#define SP_STRM_VALID BIT(2) -/* Bits for DP System Control Register 4 */ -#define SP_ENHANCED_MODE BIT(3) - -/* DP Video Control Register */ -#define SP_DP_VIDEO_CTRL_REG 0x84 -#define SP_COLOR_F_MASK0x06 -#define SP_COLOR_F_SHIFT 1 -#define SP_BPC_MASK0xe0 -#define SP_BPC_SHIFT 5 -# define SP_BPC_6BITS 0x00 -# define SP_BPC_8BITS 0x01 -# define SP_BPC_10BITS0x02 -# define SP_BPC_12BITS0x03 - -/* DP Audio Control Register */ -#define SP_DP_AUDIO_CTRL_REG 0x87 -#define SP_AUD_EN BIT(0) - -/* 10us Pulse Generate Timer Registers */ -#define SP_I2C_GEN_10US_TIMER0_REG 0x88 -#define SP_I2C_GEN_10US_TIMER1_REG 0x89 - -/* Packet Send Control Register */ -#define SP_PACKET_SEND_CTRL_REG0x90 -#define SP_AUD
[PATCH 9/9] [DO NOT MERGE] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
From: Chen-Yu Tsai
The panels shipped with Allwinner devices are very "generic", i.e.
they do not have model numbers or reliable sources of information
for the timings (that we know of) other than the fex files shipped
on them. The dot clock frequency provided in the fex files have all
been rounded to the nearest MHz, as that is the unit used in them.
We were using the simple panel "urt,umsh-8596md-t" as a substitute
for the A13 Q8 tablets in the absence of a specific model for what
may be many different but otherwise timing compatible panels. This
was usable without any visual artifacts or side effects, until the
dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
rgb: Validate the clock rate").
The reason this check fails is because the dotclock frequency for
this model is 33.26 MHz, which is not achievable with our dot clock
hardware, and the rate returned by clk_round_rate deviates slightly,
causing the driver to reject the display mode.
The LCD panels have some tolerance on the dot clock frequency, even
if it's not specified in their datasheets.
This patch adds a 5% tolerence to the dot clock check.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index bf068da6b12e..23bdc449eacc 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -92,13 +92,14 @@ static enum drm_mode_status sun4i_rgb_mode_valid(struct
drm_encoder *crtc,
DRM_DEBUG_DRIVER("Vertical parameters OK\n");
+ /* Check against a 5% tolerance for the dot clock */
tcon->dclk_min_div = 6;
tcon->dclk_max_div = 127;
rounded_rate = clk_round_rate(tcon->dclk, rate);
- if (rounded_rate < rate)
+ if (rounded_rate < rate * 19 / 20 )
return MODE_CLOCK_LOW;
- if (rounded_rate > rate)
+ if (rounded_rate > rate * 21 / 20)
return MODE_CLOCK_HIGH;
DRM_DEBUG_DRIVER("Clock rate OK\n");
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
