Re: [linux-sunxi] Re: [PATCH v3 04/11] drm/sun4i: abstract the layer type
在 2017-04-05 10:27，Chen-Yu Tsai 写道：
On Wed, Apr 5, 2017 at 3:53 AM, Icenowy Zheng wrote:
在 2017年04月05日 03:28, Sean Paul 写道:
On Thu, Mar 30, 2017 at 03:46:06AM +0800, Icenowy Zheng wrote:
As we are going to add support for the Allwinner DE2 Mixer in
sun4i-drm
driver, we will finally have two types of layer.
Abstract the layer type to void * and a ops struct, which contains
the
only function used by crtc -- get the drm_plane struct of the layer.
Signed-off-by: Icenowy Zheng
---
Refactored patch in v3.
drivers/gpu/drm/sun4i/sun4i_crtc.c | 19 +++
drivers/gpu/drm/sun4i/sun4i_crtc.h | 3 ++-
drivers/gpu/drm/sun4i/sun4i_layer.c | 19 ++-
drivers/gpu/drm/sun4i/sun4i_layer.h | 2 +-
drivers/gpu/drm/sun4i/sunxi_layer.h | 17 +
5 files changed, 49 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sunxi_layer.h
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index 3c876c3a356a..33854ee7f636 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -29,6 +29,7 @@
#include "sun4i_crtc.h"
#include "sun4i_drv.h"
#include "sun4i_layer.h"
+#include "sunxi_layer.h"
#include "sun4i_tcon.h"
static void sun4i_crtc_atomic_begin(struct drm_crtc *crtc,
@@ -149,7 +150,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct
drm_device
*drm,
scrtc->tcon = tcon;
/* Create our layers */
- scrtc->layers = sun4i_layers_init(drm, scrtc->backend);
+ scrtc->layers = (void **)sun4i_layers_init(drm, scrtc);
if (IS_ERR(scrtc->layers)) {
dev_err(drm->dev, "Couldn't create the planes\n");
return NULL;
@@ -157,14 +158,15 @@ struct sun4i_crtc *sun4i_crtc_init(struct
drm_device *drm,
/* find primary and cursor planes for
drm_crtc_init_with_planes
*/
for (i = 0; scrtc->layers[i]; i++) {
- struct sun4i_layer *layer = scrtc->layers[i];
+ void *layer = scrtc->layers[i];
+ struct drm_plane *plane =
scrtc->layer_ops->get_plane(layer);
- switch (layer->plane.type) {
+ switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
- primary = &layer->plane;
+ primary = plane;
break;
case DRM_PLANE_TYPE_CURSOR:
- cursor = &layer->plane;
+ cursor = plane;
break;
default:
break;
@@ -190,10 +192,11 @@ struct sun4i_crtc *sun4i_crtc_init(struct
drm_device *drm,
/* Set possible_crtcs to this crtc for overlay planes */
for (i = 0; scrtc->layers[i]; i++) {
uint32_t possible_crtcs =
BIT(drm_crtc_index(&scrtc->crtc));
- struct sun4i_layer *layer = scrtc->layers[i];
+ void *layer = scrtc->layers[i];
+ struct drm_plane *plane =
scrtc->layer_ops->get_plane(layer);
- if (layer->plane.type == DRM_PLANE_TYPE_OVERLAY)
- layer->plane.possible_crtcs =
possible_crtcs;
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY)
+ plane->possible_crtcs = possible_crtcs;
}
return scrtc;
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.h
b/drivers/gpu/drm/sun4i/sun4i_crtc.h
index 230cb8f0d601..a4036ee44cf8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.h
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.h
@@ -19,7 +19,8 @@ struct sun4i_crtc {
struct sun4i_backend*backend;
struct sun4i_tcon *tcon;
- struct sun4i_layer **layers;
+ void**layers;
+ const struct sunxi_layer_ops*layer_ops;
I think you should probably take a different approach to abstract the
layer
type. How about creating
struct sunxi_layer {
struct drm_plane plane;
}
base and then subclassing that for sun4i and sun8i? By doing this you
can
avoid
the nasty casting and you can also get rid of the get_plane() hook
and
layer_ops.
For the situation that using ** things are easily to get weird.
That code could be reworked, by initializing the layers directly within
the crtc init code. If you look at rockchip's drm driver, you'll see
they do this. There is a good reason to do it this way, as you need
to first create the primary and cursor layers, pass them in when you
create the crtc, then initialize any additional layers with the
possible_crtcs bitmap.
I feel that it's still more proper to offload plane creation code
to *_layers_init function, as:
1. We cannot assume the cursor layer's
existance. In fact currently no code in sun4i-drm (including this
patchset) create a cursor l
Re: [PATCH v4 06/11] drm/sun4i: add support for Allwinner DE2 mixers
于 2017年4月20日 GMT+08:00 下午4:37:07, Maxime Ripard
写到:
On Tue, Apr 18, 2017 at 06:47:56PM +0800, Icenowy Zheng wrote:
>> + /* Get the physical address of the buffer in memory */
>> + gem = drm_fb_cma_get_gem_obj(fb, 0);
>> +
>> + DRM_DEBUG_DRIVER("Using GEM @ %pad\n", &gem->paddr);
>> +
>> + /* Compute the start of the displayed memory */
>> + bpp = fb->format->cpp[0];
>> + paddr = gem->paddr + fb->offsets[0];
>> + paddr += (state->src_x >> 16) * bpp;
>> + paddr += (state->src_y >> 16) * fb->pitches[0];
>> +
>> + DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
>> +
>> + paddr_u32 = (uint32_t) paddr;
>
>How does that work on 64-bits systems ?
The hardware is not designed to work on 64-bit systems.
Even 64-bit A64/H5 has also 3GiB memory limit.
That's a fragile assumption.
Yes, it's only the basical reason.
The address cell in mixer hardware is also only 32-bit.
So we should just keep the force conversion here. If we then really
met 4GiB-capable AW SoC without changing DE2, I think we should have
other way to limit CMA pool inside 4GiB.
The register name looks like this is only the lower 32 bits that you
can set here, and that there is another register for the upper 32 bits
of that address somewhere.
Maybe... but no one can verify this as their's no currently any user
which has 4GiB+ DRAM.
I think we should keep this until Allwinner really made a 4GiB-capable
hardware.
In that case, please use the lower_32_bits and upper_32_bits helper,
and don't cast it that way.
If it isn't the case, you should set the DMA mask (through
dma_set_mask) so that we only allocate memory that can be accessed by
this device.
How to do it?
Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v5 02/11] clk: sunxi-ng: add support for DE2 CCU
在 2017-04-24 16:51，Maxime Ripard 写道：
Hi,
On Sun, Apr 23, 2017 at 06:37:45PM +0800, Icenowy Zheng wrote:
+static const struct of_device_id sunxi_de2_clk_ids[] = {
+ {
+ .compatible = "allwinner,sun8i-a83t-de2-clk",
+ .data = &sun8i_a83t_de2_clk_desc,
+ },
+ {
+ .compatible = "allwinner,sun50i-h5-de2-clk",
+ .data = &sun50i_a64_de2_clk_desc,
+ },
+ /*
+* The Allwinner A64 SoC needs some bit to be poke in syscon to make
+* DE2 really working.
+* So there's currently no A64 compatible here.
+* H5 shares the same reset line with A64, so here H5 is using the
+* clock description of A64.
+*/
+ { }
+};
So that A64 driver would require more than just what you defined in
the binding in order to operate?
Yes. When trying to do A64 driver, I will send out first a patch to
add the needed binding bit.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v2 10/11] ARM: sun8i: h3: add display engine pipeline for TVE
在 2017-06-07 17:42，Maxime Ripard 写道：
On Mon, Jun 05, 2017 at 12:01:48AM +0800, Icenowy Zheng wrote:
+ soc {
+ display_clocks: clock@100 {
+ compatible = "allwinner,sun8i-a83t-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_BUS_DE>,
+<&ccu CLK_DE>;
+ clock-names = "bus",
+ "mod";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ assigned-clocks = <&ccu CLK_DE>;
+ assigned-clock-parents = <&ccu CLK_PLL_DE>;
+ assigned-clock-rates = <43200>;
+ };
We discussed that already a few times, but there's no reason to do
so. If you need a downstream clock at a particular rate, call
clk_set_rate on it, period.
Whether its parent will be coming from PLL_DE or some other more
appriopriate clock is not relevant and doesn't make any difference.
The clock framework is not so smart to deal with these infomations:
- CLK_PLL_PERIPH should always be 600MHz
- CLK_TVE should always be 216MHz
- CLK_DE (in fact CLK_MIXER{0,1}) should be larger than 300MHz (for 4K)
So we have to specify CLK_DE to be 432MHz, and then it will set
CLK_PLL_DE to this value, then the CLK_TVE can be set to 216MHz with
divider 2.
For DE there's no a real hardware block clock requirement, set it to
=300MHz is for 4K output support.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/11] drm: sun4i: add support for the TV encoder in H3 SoC
在 2017-06-07 17:38，Maxime Ripard 写道：
On Mon, Jun 05, 2017 at 12:01:45AM +0800, Icenowy Zheng wrote:
Allwinner H3 features a TV encoder similar to the one in earlier SoCs,
but has a internal fixed clock divider that divides the TCON1 clock
(called TVE clock in datasheet) by 11.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Quirk part rewritten.
drivers/gpu/drm/sun4i/sun4i_tv.c | 35
++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c
b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 338b9e5bb2a3..b9ff6d5ea67a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -169,14 +170,21 @@ struct tv_mode {
const struct resync_parameters *resync_params;
};
+struct sun4i_tv_quirks {
+ int fixed_divider;
+};
+
struct sun4i_tv {
struct drm_connectorconnector;
struct drm_encoder encoder;
struct clk *clk;
+ struct clk *mod_clk;
struct regmap *regs;
struct reset_control*reset;
+ const struct sun4i_tv_quirks *quirks;
+
struct sun4i_drv*drv;
};
@@ -391,6 +399,12 @@ static void sun4i_tv_mode_set(struct drm_encoder
*encoder,
struct sun4i_tcon *tcon = crtc->tcon;
const struct tv_mode *tv_mode = sun4i_tv_find_tv_by_mode(mode);
+ if (tv->quirks->fixed_divider) {
+ DRM_DEBUG_DRIVER("Applying fixed divider %d on TVE clock\n",
+tv->quirks->fixed_divider);
+ mode->crtc_clock *= tv->quirks->fixed_divider;
+ }
+
You're not allowed to change the mode in mode_set, and you shouldn't
even change it. The output pixel clock is still 27MHz.
You should implement that using the states, as we discussed already.
After reading the comments at include/drm/drm_modeset_helper_vtables.h,
I think the atomic_check function is allowed to directly change
the adjust_mode of crtc_state.
And according to other comments at include/drm/drm_modes.h, the
crtc_clock in adjust_mode should be the clock to be really feed
to the hardware.
So I think I can just change this in atomic_check.
However, the mode_set function of sun4i_tv seems to be not
regarding adjusted_mode and still use original mode.
So my current design is:
- Multiply adjusted_mode in atomic_check.
- Feed adjust_mode to TCON code in mode_set function.
Is this proper?
(From my own understanding to the comments I think so.)
___
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: [linux-sunxi] Re: [PATCH v2 01/11] dt-bindings: update the binding for Allwinner H3 TVE support
在 2017-06-10 05:24，Jernej Škrabec 写道：
Hi!
Dne petek, 09. junij 2017 ob 18:51:02 CEST je Icenowy Zheng napisal(a):
于 2017年6月10日 GMT+08:00 上午12:49:15, Maxime Ripard
electrons.com> 写到:
>On Wed, Jun 07, 2017 at 04:48:50PM +0800, Icenowy Zheng wrote:
>> >> @@ -189,6 +211,8 @@ supported.
>> >>
>> >> Required properties:
>> >>- compatible: value must be one of:
>> >> * allwinner,sun8i-v3s-de2-mixer
>> >>
>> >> +* allwinner,sun8i-h3-de2-mixer0
>> >> +* allwinner,sun8i-h3-de2-mixer1
>> >
>> >Again, please explain why we need to have different compatibles
>> >here. If it's only about the number of planes, this should be dealt
>> >with a property, not a compatible.
>>
>> Only mixer0 has "VEP" and write-back support, at least on H3.
>
>What is that VEP? writeback support can also be expressed by a
>property.
I don't know what VEP is...
VEP is probably Video Enhancement Processor (?). Although I'm not sure
if that
is really mixer specific. Icenowy, can you explain where did you get
this info?
In
lichee/linux-3.4/drivers/video/sunxi/disp2/disp/de/lowlevel_sun8iw7/de_feat.c:
static const int de_is_support_vep[] = {
/* DISP0 CH0 */
1,
/* DISP0 CH1 */
0,
/* DISP0 CH2 */
0,
/* DISP0 CH3 */
0,
/* DISP1 CH0 */
0,
/* DISP1 CH1 */
0,
};
Best regards,
Jernej
But we are really facing different cores, like sun50i-a64-mmc
and sun50i-a64-emmc.
>Maxime
--
You received this message because you are subscribed to the Google
Groups
"linux-sunxi" group. To unsubscribe from this group and stop receiving
emails from it, send an email to
linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2
在 2017-06-10 22:57，icen...@aosc.io 写道： 在 2017-06-09 22:46，Maxime Ripard 写道： On Thu, Jun 08, 2017 at 01:01:53PM +0800, icen...@aosc.io wrote: 在 2017-06-07 22:38，Maxime Ripard 写道： > On Wed, Jun 07, 2017 at 06:01:02PM +0800, Icenowy Zheng wrote: > > >I have no idea what this is supposed to be doing either. > > > > > >I might be wrong, but I really feel like there's a big mismatch > > >between your commit log, and what you actually implement. > > > > > >In your commit log, you should state: > > > > > >A) What is the current behaviour > > >B) Why that is a problem > > >C) How do you address it > > > > > >And you don't. > > > > > >However, after discussing it with Chen-Yu, it seems like you're trying > > >to have all the mixers probed before the TCONs. If that is so, there's > > >nothing specific to the H3 here, and we also have the same issue on > > >dual-pipeline DE1 (A10, A20, A31). Chen-Yu worked on that a bit, but > > >the easiest solution would be to move from a DFS algorithm to walk > > >down the graph to a BFS one. > > > > > >That way, we would add all mixers first, then the TCONs, then the > > >encoders, and the component framework will probe them in order. > > > > No. I said that they're swappable, however, I don't want to > > implement the swap now, but hardcode 0-0 1-1 connection. > > We're on the same page, it's definitely not what I was mentionning > here. This would require a significant rework, and the usecase is > still unclear for now. > > > However, as you and Chen-Yu said, device tree should reflect the > > real hardware, there will be bonus endpoints for the swapped > > connection. > > If by bonus you mean connections from mixer 0 to tcon 1 and mixer 1 to > tcon 0, then yes, we're going to need it. > > > What I want to do is to ignore the bonus connection, in order to > > prevent them from confusing the code. > > > > If you just change the bind sequence, I think it cannot be > > prevented that wrong connections will be bound. > > This is where I don't follow you anymore. The component framework > doesn't list connections but devices. The swapped connections do not > matter here, we have the same set of devices: mixer0, mixer1, tcon0 > and tcon1. > > The thing that does change with your patch is that before, the binding > sequence would have been mixer0, tcon0, tcon1, mixer1. With your > patch, it's mixer0, tcon0, mixer1, tcon1. > > So, again, stating what issue you were seeing before making this patch > would be very helpful to see what you're trying to do / fix. So maybe I can drop the forward search (searching output) code, and keep only the backward search (search input) code in TCON? Forward search code is only used when binding, but backward search is used for TCON to find connected mixer. It is hard to talk about a solution, when it's not clear what the issue is. So please state > > >A) What is the current behaviour > > >B) Why that is a problem > > >C) How do you address it We'll talk about a solution once this is done. (All those things are based on the assumption that mixer0, mixer1, tcon0 and tcon1 are all enabled in DT. If one group of mixer-tcon pair is fully disabled in DT it will behave properly.) So there's a temporary workaround -- only enable one pipeline and disable the unused mixer and tcon totally. It's shown to work with this commit reverted in my local TVE branch. (The swappable_input value is also deleted from H3 TCON's quirks) For the backward search: A) The current behaviour is to take the first engine found, which will be wrong in the situation of tcon1 if mixer0 and mixer1 are both enabled: mixer0 is taken for tcon1 instead of mixer1. B) It takes mixer0 as it matches the first endpoint of tcon0's input. C) It's a logic failure in the backward search, as it only considered the DE1 situation, in which TCONs will only have one engine as input. For the bind process: A) The current behaviour is to try to bind all output endpoints of the engine, during binding all outputs of mixer0, these will happen: 1. tcon1 is bound with mixer0 as its engine if backward searching is not fixed. 2. tcon1 fails to be bound as its engine is not yet bound when backward searching works properly, then sun4i_drv will refuse to continue as a component is not properly bound. B) The binding process in sun4i_drv will bind a component that is not really an working output of the forward component, but only exists in the endpoint list as a theortically possible output (in fact not an real output). C) I
Re: [PATCH v2 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2
在 2017-06-09 22:46，Maxime Ripard 写道： On Thu, Jun 08, 2017 at 01:01:53PM +0800, icen...@aosc.io wrote: 在 2017-06-07 22:38，Maxime Ripard 写道： > On Wed, Jun 07, 2017 at 06:01:02PM +0800, Icenowy Zheng wrote: > > >I have no idea what this is supposed to be doing either. > > > > > >I might be wrong, but I really feel like there's a big mismatch > > >between your commit log, and what you actually implement. > > > > > >In your commit log, you should state: > > > > > >A) What is the current behaviour > > >B) Why that is a problem > > >C) How do you address it > > > > > >And you don't. > > > > > >However, after discussing it with Chen-Yu, it seems like you're trying > > >to have all the mixers probed before the TCONs. If that is so, there's > > >nothing specific to the H3 here, and we also have the same issue on > > >dual-pipeline DE1 (A10, A20, A31). Chen-Yu worked on that a bit, but > > >the easiest solution would be to move from a DFS algorithm to walk > > >down the graph to a BFS one. > > > > > >That way, we would add all mixers first, then the TCONs, then the > > >encoders, and the component framework will probe them in order. > > > > No. I said that they're swappable, however, I don't want to > > implement the swap now, but hardcode 0-0 1-1 connection. > > We're on the same page, it's definitely not what I was mentionning > here. This would require a significant rework, and the usecase is > still unclear for now. > > > However, as you and Chen-Yu said, device tree should reflect the > > real hardware, there will be bonus endpoints for the swapped > > connection. > > If by bonus you mean connections from mixer 0 to tcon 1 and mixer 1 to > tcon 0, then yes, we're going to need it. > > > What I want to do is to ignore the bonus connection, in order to > > prevent them from confusing the code. > > > > If you just change the bind sequence, I think it cannot be > > prevented that wrong connections will be bound. > > This is where I don't follow you anymore. The component framework > doesn't list connections but devices. The swapped connections do not > matter here, we have the same set of devices: mixer0, mixer1, tcon0 > and tcon1. > > The thing that does change with your patch is that before, the binding > sequence would have been mixer0, tcon0, tcon1, mixer1. With your > patch, it's mixer0, tcon0, mixer1, tcon1. > > So, again, stating what issue you were seeing before making this patch > would be very helpful to see what you're trying to do / fix. So maybe I can drop the forward search (searching output) code, and keep only the backward search (search input) code in TCON? Forward search code is only used when binding, but backward search is used for TCON to find connected mixer. It is hard to talk about a solution, when it's not clear what the issue is. So please state > > >A) What is the current behaviour > > >B) Why that is a problem > > >C) How do you address it We'll talk about a solution once this is done. (All those things are based on the assumption that mixer0, mixer1, tcon0 and tcon1 are all enabled in DT. If one group of mixer-tcon pair is fully disabled in DT it will behave properly.) For the backward search: A) The current behaviour is to take the first engine found, which will be wrong in the situation of tcon1 if mixer0 and mixer1 are both enabled: mixer0 is taken for tcon1 instead of mixer1. B) It takes mixer0 as it matches the first endpoint of tcon0's input. C) It's a logic failure in the backward search, as it only considered the DE1 situation, in which TCONs will only have one engine as input. For the bind process: A) The current behaviour is to try to bind all output endpoints of the engine, during binding all outputs of mixer0, these will happen: 1. tcon1 is bound with mixer0 as its engine if backward searching is not fixed. 2. tcon1 fails to be bound as its engine is not yet bound when backward searching works properly, then sun4i_drv will refuse to continue as a component is not properly bound. B) The binding process in sun4i_drv will bind a component that is not really an working output of the forward component, but only exists in the endpoint list as a theortically possible output (in fact not an real output). C) I tested with this patch's sun4i_drv_node_is_swappable_de2_mixer function masked (always return false), and then the multiple mixer+tcon situations don't work properly. P.S. I think the BFS solution is really a dirty hack -- although we bind components, not connections, we should decide the nex
Re: [PATCH v6 08/13] drm/sun4i: add support for Allwinner DE2 mixers
在 2017-05-05 00:50，icen...@aosc.io 写道：
在 2017-05-04 21:05，Maxime Ripard 写道：
On Thu, May 04, 2017 at 07:48:53PM +0800, Icenowy Zheng wrote:
Allwinner have a new "Display Engine 2.0" in their new SoCs, which
comes
with mixers to do graphic processing and feed data to TCON, like the
old
backends and frontends.
Add support for the mixer on Allwinner V3s SoC; it's the simplest
one.
Currently a lot of functions are still missing -- more investigations
are needed to gain enough information for them.
Signed-off-by: Icenowy Zheng
---
Changes in v6:
- Rebased on wens's multi-pipeline patchset.
Changes in v5:
- Changed some code alignment.
- Request real 32-bit DMA (prepare for 64-bit SoCs).
Changes in v4:
- Killed some dead code according to Jernej.
drivers/gpu/drm/sun4i/Kconfig | 10 +
drivers/gpu/drm/sun4i/Makefile | 3 +
drivers/gpu/drm/sun4i/sun8i_layer.c | 140 +
drivers/gpu/drm/sun4i/sun8i_layer.h | 36
drivers/gpu/drm/sun4i/sun8i_mixer.c | 394
drivers/gpu/drm/sun4i/sun8i_mixer.h | 137 +
6 files changed, 720 insertions(+)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
diff --git a/drivers/gpu/drm/sun4i/Kconfig
b/drivers/gpu/drm/sun4i/Kconfig
index 5a8227f37cc4..15557484520d 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -22,3 +22,13 @@ config DRM_SUN4I_BACKEND
original Allwinner Display Engine, which has a backend to
do some alpha blending and feed graphics to TCON. If M is
selected the module will be called sun4i-backend.
+
+config DRM_SUN4I_SUN8I_MIXER
DRM_SUN8I_MIXER?
+ tristate "Support for Allwinner Display Engine 2.0 Mixer"
+ depends on DRM_SUN4I
+ default MACH_SUN8I
+ help
+ Choose this option if you have an Allwinner SoC with the
+ Allwinner Display Engine 2.0, which has a mixer to do some
+ graphics mixture and feed graphics to TCON, If M is
+ selected the module will be called sun8i-mixer.
diff --git a/drivers/gpu/drm/sun4i/Makefile
b/drivers/gpu/drm/sun4i/Makefile
index a08df56759e3..a876c6b3027c 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -8,7 +8,10 @@ sun4i-tcon-y += sun4i_crtc.o
sun4i-backend-y += sun4i_backend.o sun4i_layer.o
+sun8i-mixer-y += sun8i_mixer.o sun8i_layer.o
+
obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
+obj-$(CONFIG_DRM_SUN4I_SUN8I_MIXER)+= sun8i-mixer.o
obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
new file mode 100644
index ..48f33d8e013b
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -0,0 +1,140 @@
+/*
+ * Copyright (C) Icenowy Zheng
+ *
+ * Based on sun4i_layer.h, which is:
+ * Copyright (C) 2015 Free Electrons
+ * Copyright (C) 2015 NextThing Co
+ *
+ * Maxime Ripard
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+
+#include "sun8i_layer.h"
+#include "sun8i_mixer.h"
+
+struct sun8i_plane_desc {
+ enum drm_plane_type type;
+ const uint32_t *formats;
+ uint32_tnformats;
+};
+
+static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ return 0;
+}
This isn't needed.
+static void sun8i_mixer_layer_atomic_disable(struct drm_plane
*plane,
+ struct drm_plane_state
*old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_layer_enable(mixer, layer->id, false);
+}
+
+static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
+ sun8i_mixer_layer_enable(mixer, layer->id, true);
+}
+
+static struct drm_plane_helper_funcs sun8i_mixer_layer
Re: [PATCH v6 08/13] drm/sun4i: add support for Allwinner DE2 mixers
在 2017-05-05 00:57，icen...@aosc.io 写道：
在 2017-05-05 00:50，icen...@aosc.io 写道：
在 2017-05-04 21:05，Maxime Ripard 写道：
On Thu, May 04, 2017 at 07:48:53PM +0800, Icenowy Zheng wrote:
Allwinner have a new "Display Engine 2.0" in their new SoCs, which
comes
with mixers to do graphic processing and feed data to TCON, like the
old
backends and frontends.
Add support for the mixer on Allwinner V3s SoC; it's the simplest
one.
Currently a lot of functions are still missing -- more
investigations
are needed to gain enough information for them.
Signed-off-by: Icenowy Zheng
---
Changes in v6:
- Rebased on wens's multi-pipeline patchset.
Changes in v5:
- Changed some code alignment.
- Request real 32-bit DMA (prepare for 64-bit SoCs).
Changes in v4:
- Killed some dead code according to Jernej.
drivers/gpu/drm/sun4i/Kconfig | 10 +
drivers/gpu/drm/sun4i/Makefile | 3 +
drivers/gpu/drm/sun4i/sun8i_layer.c | 140 +
drivers/gpu/drm/sun4i/sun8i_layer.h | 36
drivers/gpu/drm/sun4i/sun8i_mixer.c | 394
drivers/gpu/drm/sun4i/sun8i_mixer.h | 137 +
6 files changed, 720 insertions(+)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
diff --git a/drivers/gpu/drm/sun4i/Kconfig
b/drivers/gpu/drm/sun4i/Kconfig
index 5a8227f37cc4..15557484520d 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -22,3 +22,13 @@ config DRM_SUN4I_BACKEND
original Allwinner Display Engine, which has a backend to
do some alpha blending and feed graphics to TCON. If M is
selected the module will be called sun4i-backend.
+
+config DRM_SUN4I_SUN8I_MIXER
DRM_SUN8I_MIXER?
+ tristate "Support for Allwinner Display Engine 2.0 Mixer"
+ depends on DRM_SUN4I
+ default MACH_SUN8I
+ help
+ Choose this option if you have an Allwinner SoC with the
+ Allwinner Display Engine 2.0, which has a mixer to do some
+ graphics mixture and feed graphics to TCON, If M is
+ selected the module will be called sun8i-mixer.
diff --git a/drivers/gpu/drm/sun4i/Makefile
b/drivers/gpu/drm/sun4i/Makefile
index a08df56759e3..a876c6b3027c 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -8,7 +8,10 @@ sun4i-tcon-y += sun4i_crtc.o
sun4i-backend-y += sun4i_backend.o sun4i_layer.o
+sun8i-mixer-y += sun8i_mixer.o sun8i_layer.o
+
obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
+obj-$(CONFIG_DRM_SUN4I_SUN8I_MIXER)+= sun8i-mixer.o
obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
new file mode 100644
index ..48f33d8e013b
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -0,0 +1,140 @@
+/*
+ * Copyright (C) Icenowy Zheng
+ *
+ * Based on sun4i_layer.h, which is:
+ * Copyright (C) 2015 Free Electrons
+ * Copyright (C) 2015 NextThing Co
+ *
+ * Maxime Ripard
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+
+#include "sun8i_layer.h"
+#include "sun8i_mixer.h"
+
+struct sun8i_plane_desc {
+ enum drm_plane_type type;
+ const uint32_t *formats;
+ uint32_tnformats;
+};
+
+static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ return 0;
+}
This isn't needed.
+static void sun8i_mixer_layer_atomic_disable(struct drm_plane
*plane,
+ struct drm_plane_state
*old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_layer_enable(mixer, layer->id, false);
+}
+
+static void sun8i_mixer_layer_atomic_update(struct drm_plane
*plane,
+ struct drm_plane_state *old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
+ sun8i_mixer_layer_enable(mixer, layer->id, true
Re: [PATCH v6 08/13] drm/sun4i: add support for Allwinner DE2 mixers
在 2017-05-04 21:05，Maxime Ripard 写道：
On Thu, May 04, 2017 at 07:48:53PM +0800, Icenowy Zheng wrote:
Allwinner have a new "Display Engine 2.0" in their new SoCs, which
comes
with mixers to do graphic processing and feed data to TCON, like the
old
backends and frontends.
Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
Currently a lot of functions are still missing -- more investigations
are needed to gain enough information for them.
Signed-off-by: Icenowy Zheng
---
Changes in v6:
- Rebased on wens's multi-pipeline patchset.
Changes in v5:
- Changed some code alignment.
- Request real 32-bit DMA (prepare for 64-bit SoCs).
Changes in v4:
- Killed some dead code according to Jernej.
drivers/gpu/drm/sun4i/Kconfig | 10 +
drivers/gpu/drm/sun4i/Makefile | 3 +
drivers/gpu/drm/sun4i/sun8i_layer.c | 140 +
drivers/gpu/drm/sun4i/sun8i_layer.h | 36
drivers/gpu/drm/sun4i/sun8i_mixer.c | 394
drivers/gpu/drm/sun4i/sun8i_mixer.h | 137 +
6 files changed, 720 insertions(+)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
diff --git a/drivers/gpu/drm/sun4i/Kconfig
b/drivers/gpu/drm/sun4i/Kconfig
index 5a8227f37cc4..15557484520d 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -22,3 +22,13 @@ config DRM_SUN4I_BACKEND
original Allwinner Display Engine, which has a backend to
do some alpha blending and feed graphics to TCON. If M is
selected the module will be called sun4i-backend.
+
+config DRM_SUN4I_SUN8I_MIXER
DRM_SUN8I_MIXER?
+ tristate "Support for Allwinner Display Engine 2.0 Mixer"
+ depends on DRM_SUN4I
+ default MACH_SUN8I
+ help
+ Choose this option if you have an Allwinner SoC with the
+ Allwinner Display Engine 2.0, which has a mixer to do some
+ graphics mixture and feed graphics to TCON, If M is
+ selected the module will be called sun8i-mixer.
diff --git a/drivers/gpu/drm/sun4i/Makefile
b/drivers/gpu/drm/sun4i/Makefile
index a08df56759e3..a876c6b3027c 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -8,7 +8,10 @@ sun4i-tcon-y += sun4i_crtc.o
sun4i-backend-y += sun4i_backend.o sun4i_layer.o
+sun8i-mixer-y += sun8i_mixer.o sun8i_layer.o
+
obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
+obj-$(CONFIG_DRM_SUN4I_SUN8I_MIXER)+= sun8i-mixer.o
obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
new file mode 100644
index ..48f33d8e013b
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -0,0 +1,140 @@
+/*
+ * Copyright (C) Icenowy Zheng
+ *
+ * Based on sun4i_layer.h, which is:
+ * Copyright (C) 2015 Free Electrons
+ * Copyright (C) 2015 NextThing Co
+ *
+ * Maxime Ripard
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+
+#include "sun8i_layer.h"
+#include "sun8i_mixer.h"
+
+struct sun8i_plane_desc {
+ enum drm_plane_type type;
+ const uint32_t *formats;
+ uint32_tnformats;
+};
+
+static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ return 0;
+}
This isn't needed.
+static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
+ struct drm_plane_state
*old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_layer_enable(mixer, layer->id, false);
+}
+
+static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
+ sun8i_mixer_layer_enable(mixer, layer->id, true);
+}
+
+static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs =
{
+
Re: [PATCH v6 08/13] drm/sun4i: add support for Allwinner DE2 mixers
在 2017-05-04 21:05，Maxime Ripard 写道：
On Thu, May 04, 2017 at 07:48:53PM +0800, Icenowy Zheng wrote:
Allwinner have a new "Display Engine 2.0" in their new SoCs, which
comes
with mixers to do graphic processing and feed data to TCON, like the
old
backends and frontends.
Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
Currently a lot of functions are still missing -- more investigations
are needed to gain enough information for them.
Signed-off-by: Icenowy Zheng
---
Changes in v6:
- Rebased on wens's multi-pipeline patchset.
Changes in v5:
- Changed some code alignment.
- Request real 32-bit DMA (prepare for 64-bit SoCs).
Changes in v4:
- Killed some dead code according to Jernej.
drivers/gpu/drm/sun4i/Kconfig | 10 +
drivers/gpu/drm/sun4i/Makefile | 3 +
drivers/gpu/drm/sun4i/sun8i_layer.c | 140 +
drivers/gpu/drm/sun4i/sun8i_layer.h | 36
drivers/gpu/drm/sun4i/sun8i_mixer.c | 394
drivers/gpu/drm/sun4i/sun8i_mixer.h | 137 +
6 files changed, 720 insertions(+)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
diff --git a/drivers/gpu/drm/sun4i/Kconfig
b/drivers/gpu/drm/sun4i/Kconfig
index 5a8227f37cc4..15557484520d 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -22,3 +22,13 @@ config DRM_SUN4I_BACKEND
original Allwinner Display Engine, which has a backend to
do some alpha blending and feed graphics to TCON. If M is
selected the module will be called sun4i-backend.
+
+config DRM_SUN4I_SUN8I_MIXER
DRM_SUN8I_MIXER?
+ tristate "Support for Allwinner Display Engine 2.0 Mixer"
+ depends on DRM_SUN4I
+ default MACH_SUN8I
+ help
+ Choose this option if you have an Allwinner SoC with the
+ Allwinner Display Engine 2.0, which has a mixer to do some
+ graphics mixture and feed graphics to TCON, If M is
+ selected the module will be called sun8i-mixer.
diff --git a/drivers/gpu/drm/sun4i/Makefile
b/drivers/gpu/drm/sun4i/Makefile
index a08df56759e3..a876c6b3027c 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -8,7 +8,10 @@ sun4i-tcon-y += sun4i_crtc.o
sun4i-backend-y += sun4i_backend.o sun4i_layer.o
+sun8i-mixer-y += sun8i_mixer.o sun8i_layer.o
+
obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
+obj-$(CONFIG_DRM_SUN4I_SUN8I_MIXER)+= sun8i-mixer.o
obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
new file mode 100644
index ..48f33d8e013b
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -0,0 +1,140 @@
+/*
+ * Copyright (C) Icenowy Zheng
+ *
+ * Based on sun4i_layer.h, which is:
+ * Copyright (C) 2015 Free Electrons
+ * Copyright (C) 2015 NextThing Co
+ *
+ * Maxime Ripard
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+
+#include "sun8i_layer.h"
+#include "sun8i_mixer.h"
+
+struct sun8i_plane_desc {
+ enum drm_plane_type type;
+ const uint32_t *formats;
+ uint32_tnformats;
+};
+
+static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ return 0;
+}
This isn't needed.
+static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
+ struct drm_plane_state
*old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_layer_enable(mixer, layer->id, false);
+}
+
+static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
+ sun8i_mixer_layer_enable(mixer, layer->id, true);
+}
+
+static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs =
{
+
Re: [linux-sunxi] [PATCH v6 11/13] ARM: dts: sun8i: add DE2 nodes for V3s SoC
在 2017-05-05 11:31，Chen-Yu Tsai 写道：
On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng wrote:
Allwinner V3s SoC features a "Display Engine 2.0" with only one TCON
which have RGB LCD output.
Please also mention that it only has one mixer.
For the subject, you could just say "Add device nodes for the display
pipeline".
Add device nodes for it as well as the TCON.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 87
1 file changed, 87 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 71075969e5e6..0a895179d8ae 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -41,6 +41,10 @@
*/
#include
+#include
+#include
+#include
+#include
/ {
#address-cells = <1>;
@@ -59,6 +63,12 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-v3s-display-engine";
+ allwinner,pipelines = <&de2_mixer0>;
+ status = "disabled";
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = IRQ_TYPE_LEVEL_LOW)>,
@@ -93,6 +103,83 @@
#size-cells = <1>;
ranges;
+ de2_clocks: clock@100 {
+ compatible = "allwinner,sun50i-h5-de2-clk";
I am a bit skeptical about this. Since the V3S only has one mixer, do
the clocks
for the second one even exist?
It's described in the de_clock.c in the BSP source code, and in hardware
these bits can be really set (although without clock output).
So I use this compatible which has still the extra clocks.
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_DE>,
+<&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ de2_mixer0: mixer@110 {
+ compatible = "allwinner,sun8i-v3s-de2-mixer";
+ reg = <0x0110 0x10>;
+ clocks = <&de2_clocks CLK_MIXER0>,
+<&de2_clocks CLK_BUS_MIXER0>;
+ clock-names = "mod",
+ "bus";
Nit: could you list the bus clock first?
Regards
ChenYu
+ resets = <&de2_clocks RST_MIXER0>;
+ assigned-clocks = <&de2_clocks CLK_MIXER0>;
+ assigned-clock-rates = <15000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer0_out_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon0_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ tcon0: lcd-controller@1c0c000 {
+ compatible = "allwinner,sun8i-v3s-tcon";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON0>,
+<&ccu CLK_TCON0>;
+ clock-names = "ahb",
+ "tcon-ch0";
+ clock-output-names = "tcon-pixel-clock";
+ resets = <&ccu RST_BUS_TCON0>;
+ reset-names = "lcd";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon0_in_mixer0: endpoint@0 {
+
Re: [PATCH v2 14/20] drm/sun4i: tcon: multiply the vtotal when not in interlace
在 2017-05-03 19:59，Maxime Ripard 写道：
It appears that the total vertical resolution needs to be doubled when
we're not in interlaced. Make sure that is the case.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 0f91ec8a4b26..efa079c1a3f5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -272,9 +272,9 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
/* Set vertical display timings */
bp = mode->crtc_vtotal - mode->crtc_vsync_start;
DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
-mode->vtotal, bp);
+mode->crtc_vtotal, bp);
regmap_write(tcon->regs, SUN4I_TCON1_BASIC4_REG,
-SUN4I_TCON1_BASIC4_V_TOTAL(mode->vtotal) |
+SUN4I_TCON1_BASIC4_V_TOTAL(mode->crtc_vtotal * 2) |
For TVE the value should directly be mode->vtotal, but not
mode->crtc_vtotal * 2.
vtotal is 625 when PAL. crtc_vtotal is thus 312, but if we restore the
vtotal value by doubling crtv_vtotal, we got 624, which will lead to
instability of the image displayed. (the image will loop to go higher
and then go lower, because wrong vtotal value)
Tested on patched H3 TV encoder.
I used a logic slightly changed from your v1 code:
```
val = mode->vtotal;
if (!(mode->flags & DRM_MODE_FLAG_INTERLACE))
val = val * 2;
regmap_write(tcon->regs, SUN4I_TCON1_BASIC4_REG,
SUN4I_TCON1_BASIC4_V_TOTAL(val) |
SUN4I_TCON1_BASIC4_V_BACKPORCH(bp));
```
SUN4I_TCON1_BASIC4_V_BACKPORCH(bp));
/* Set Hsync and Vsync length */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v6 05/13] drm/sun4i: abstract a engine type
在 2017-05-05 10:56，Chen-Yu Tsai 写道：
On Thu, May 4, 2017 at 7:48 PM, Icenowy Zheng wrote:
As we are going to add support for the Allwinner DE2 engine in
sun4i-drm
driver, we will finally have two types of display engines -- the DE1
backend and the DE2 mixer. They both do some display blending and feed
graphics data to TCON, so I choose to call them both "engine" here.
These engines composite different layers into a final image which is
then sent out to the TCONs. As such, "compositor" would be an accurate
name.
However, "engine" is OK, since Allwinner calls this stuff Display
Engine
1.0 and 2.0. Hope there won't be a 3.0 ...
Maybe you should note that in your commit message. That is justifies
the name.
Abstract the engine type to a new struct with an ops struct, which
contains
functions that should be called outside the engine-specified code (in
TCON, CRTC or TV Encoder code).
Signed-off-by: Icenowy Zheng
---
Changes in v6:
- Rebased on wens's multi-pipeline patchset.
- Split out Makefile changes.
Changes in v5:
- Really made a sunxi_engine struct type, and moved ops pointer
into it.
- Added checked ops wrappers.
- Changed the second parameter of layers_init from crtc to engine.
Changes in v4:
- Comments to tag the color correction functions as optional.
- Check before calling the optional functions.
- Change layers_init to satisfy new PATCH v4 04/11.
drivers/gpu/drm/sun4i/sun4i_backend.c | 68 -
drivers/gpu/drm/sun4i/sun4i_backend.h | 17 +++---
drivers/gpu/drm/sun4i/sun4i_crtc.c| 11 ++--
drivers/gpu/drm/sun4i/sun4i_crtc.h| 4 +-
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_drv.h | 2 +-
drivers/gpu/drm/sun4i/sun4i_layer.c | 8 +--
drivers/gpu/drm/sun4i/sun4i_layer.h | 5 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c| 36 ++-
drivers/gpu/drm/sun4i/sun4i_tv.c | 9 ++-
drivers/gpu/drm/sun4i/sunxi_engine.h | 112
++
11 files changed, 198 insertions(+), 76 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index e53107418add..611cdcb9c182 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -25,6 +25,8 @@
#include "sun4i_backend.h"
#include "sun4i_drv.h"
+#include "sun4i_layer.h"
+#include "sunxi_engine.h"
static const u32 sunxi_rgb2yuv_coef[12] = {
0x0107, 0x0204, 0x0064, 0x0108,
@@ -32,41 +34,38 @@ static const u32 sunxi_rgb2yuv_coef[12] = {
0x01c1, 0x3e88, 0x3fb8, 0x0808
};
-void sun4i_backend_apply_color_correction(struct sun4i_backend
*backend)
+static void sun4i_backend_apply_color_correction(struct sunxi_engine
*engine)
{
int i;
DRM_DEBUG_DRIVER("Applying RGB to YUV color correction\n");
/* Set color correction */
- regmap_write(backend->regs, SUN4I_BACKEND_OCCTL_REG,
+ regmap_write(engine->regs, SUN4I_BACKEND_OCCTL_REG,
SUN4I_BACKEND_OCCTL_ENABLE);
for (i = 0; i < 12; i++)
- regmap_write(backend->regs,
SUN4I_BACKEND_OCRCOEF_REG(i),
+ regmap_write(engine->regs,
SUN4I_BACKEND_OCRCOEF_REG(i),
sunxi_rgb2yuv_coef[i]);
}
-EXPORT_SYMBOL(sun4i_backend_apply_color_correction);
-void sun4i_backend_disable_color_correction(struct sun4i_backend
*backend)
+static void sun4i_backend_disable_color_correction(struct
sunxi_engine *engine)
{
DRM_DEBUG_DRIVER("Disabling color correction\n");
/* Disable color correction */
- regmap_update_bits(backend->regs, SUN4I_BACKEND_OCCTL_REG,
+ regmap_update_bits(engine->regs, SUN4I_BACKEND_OCCTL_REG,
SUN4I_BACKEND_OCCTL_ENABLE, 0);
}
-EXPORT_SYMBOL(sun4i_backend_disable_color_correction);
-void sun4i_backend_commit(struct sun4i_backend *backend)
+static void sun4i_backend_commit(struct sunxi_engine *engine)
{
DRM_DEBUG_DRIVER("Committing changes\n");
- regmap_write(backend->regs, SUN4I_BACKEND_REGBUFFCTL_REG,
+ regmap_write(engine->regs, SUN4I_BACKEND_REGBUFFCTL_REG,
SUN4I_BACKEND_REGBUFFCTL_AUTOLOAD_DIS |
SUN4I_BACKEND_REGBUFFCTL_LOADCTL);
}
-EXPORT_SYMBOL(sun4i_backend_commit);
void sun4i_backend_layer_enable(struct sun4i_backend *backend,
int layer, bool enable)
@@ -81,7 +80,7 @@ void sun4i_backend_layer_enable(struct sun4i_backend
*backend,
else
val = 0;
- regmap_update_bits(backend->regs, SUN4I_BACKEND_MODCTL_REG,
+ regmap_update_bits(backend->engine.regs,
SUN4I_BACKEND_MODCTL_REG,
SUN4I_BACKEND_MODCTL_LAY_EN(layer),
Re: [linux-sunxi] [PATCH v2 20/20] ARM: sun5i: a10s-olinuxino: Enable HDMI
在 2017-05-11 03:23，Maxime Ripard 写道：
Hi,
On Thu, May 04, 2017 at 04:05:18PM +0800, Chen-Yu Tsai wrote:
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
wrote:
> The A10s Olinuxino has an HDMI connector. Make sure we can use it.
>
> Acked-by: Chen-Yu Tsai
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 29 +-
> 1 file changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
> index 894f874a5beb..1d13b6407222 100644
> --- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
> +++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
> @@ -63,6 +63,17 @@
> stdout-path = "serial0:115200n8";
> };
>
> + connector {
> + compatible = "hdmi-connector";
> + type = "a";
Just curious, should we take this into consideration when creating
drm_connector?
I'm not sure, no other driver does so. And I haven't seen any of our
boards with a HDMI-B, C or mini-HDMI connector.
Tablets usually come with micro-HDMI connector.
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 v7 11/13] ARM: sun8i: v3s: add device nodes for DE2 display pipeline
在 2017-05-15 17:24，Maxime Ripard 写道：
On Mon, May 15, 2017 at 12:30:43AM +0800, Icenowy Zheng wrote:
+ de2_clocks: clock@100 {
display_clocks would be better there, we don't have to dissociate de1
with de2
How about de_clocks ? (See A80 DTSI)
+ compatible = "allwinner,sun8i-v3s-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_DE>,
+<&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ de2_mixer0: mixer@110 {
and mixer0 here is enough too.
Is there several of them? Why not just use mixer if there's only one?
Nope, here it's tagged 0 only for consistency with other SoCs.
+ compatible = "allwinner,sun8i-v3s-de2-mixer";
+ reg = <0x0110 0x10>;
+ clocks = <&de2_clocks CLK_MIXER0>,
+<&de2_clocks CLK_BUS_MIXER0>;
+ clock-names = "mod",
+ "bus";
+ resets = <&de2_clocks RST_MIXER0>;
+ assigned-clocks = <&de2_clocks CLK_MIXER0>;
+ assigned-clock-rates = <15000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer0_out_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon0_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ tcon0: lcd-controller@1c0c000 {
+ compatible = "allwinner,sun8i-v3s-tcon";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON0>,
+<&ccu CLK_TCON0>;
+ clock-names = "ahb",
+ "tcon-ch0";
+ clock-output-names = "tcon-pixel-clock";
+ resets = <&ccu RST_BUS_TCON0>;
+ reset-names = "lcd";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon0_in_mixer0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&mixer0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
+
You have an extra new line here.
Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 11/13] ARM: sun8i: v3s: add device nodes for DE2 display pipeline
在 2017-05-17 17:27，icen...@aosc.io 写道：
在 2017-05-15 17:24，Maxime Ripard 写道：
On Mon, May 15, 2017 at 12:30:43AM +0800, Icenowy Zheng wrote:
+ de2_clocks: clock@100 {
display_clocks would be better there, we don't have to dissociate de1
with de2
How about de_clocks ? (See A80 DTSI)
Oh I regretted... de here indicates "de1".
display_clocks is better.
+ compatible = "allwinner,sun8i-v3s-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_DE>,
+<&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ de2_mixer0: mixer@110 {
and mixer0 here is enough too.
Is there several of them? Why not just use mixer if there's only one?
Nope, here it's tagged 0 only for consistency with other SoCs.
+ compatible = "allwinner,sun8i-v3s-de2-mixer";
+ reg = <0x0110 0x10>;
+ clocks = <&de2_clocks CLK_MIXER0>,
+<&de2_clocks CLK_BUS_MIXER0>;
+ clock-names = "mod",
+ "bus";
+ resets = <&de2_clocks RST_MIXER0>;
+ assigned-clocks = <&de2_clocks CLK_MIXER0>;
+ assigned-clock-rates = <15000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer0_out_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon0_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ tcon0: lcd-controller@1c0c000 {
+ compatible = "allwinner,sun8i-v3s-tcon";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON0>,
+<&ccu CLK_TCON0>;
+ clock-names = "ahb",
+ "tcon-ch0";
+ clock-output-names = "tcon-pixel-clock";
+ resets = <&ccu RST_BUS_TCON0>;
+ reset-names = "lcd";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon0_in_mixer0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&mixer0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
+
You have an extra new line here.
Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC
在 2017-05-23 20:53，Maxime Ripard 写道： On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote: Hi, Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a): > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec wrote: > > Hi, > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard > > > electrons.com> 写到: > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: > >> >> Allwinner H3 features a TV encoder similar to the one in earlier > >> > > >> >SoCs, > >> > > >> >> but with some different points about clocks: > >> >> - It has a mod clock and a bus clock. > >> >> - The mod clock must be at a fixed rate to generate signal. > >> > > >> >Why? > >> > >> It's experiment result by Jernej. > >> > >> The clock rates in BSP kernel is also specially designed > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. > > > > My experiments and search through BSP code showed that TVE seems to have > > additional fixed predivider 8. So if you want to generate 27 MHz clock, > > unit has to be feed with 216 MHz. > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a bit low for > > DE2, > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate 216 MHz. > > This clock is then divided by 8 internaly to get final 27 MHz. > > > > Please note that I don't have any hard evidence to support that, only > > experimental data. However, only that explanation make sense to me. > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both use 27 MHz > > base clock. Further experiments are needed to check if there is any > > possibility to have other resolutions by manipulating clocks and give > > other proper settings. I plan to do that, but not in very near future. > > You only have composite video output, and those are the only 2 standard > resolutions that make any sense. Right, other resolutions are for VGA. Anyway, I did some more digging in A10 and R40 datasheets. I think that H3 TVE unit is something in between. R40 TVE has a setting to select "up sample". That might be just another translation of oversampling :) I didn't know it could be applied to composite signals though, but I guess this is just another analog signal after all. Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP driver on R40 has this setting enabled only for PAL and NTSC and it is always 216 MHz. I think that H3 may have this hardwired to 216 MHz and this would be the reason why 216 MHz is needed. Has anyone else any better explanation? That's already a pretty good one. Either way, wether this is upsampling, oversampling or just a pre-divider, this can and should be dealt with in the mode_set callback, and not in the probe. I got a better idea -- let TVE driver have the CLK_TVE as an input and create a subclock output with divider 16, and feed this subclock to TCON lcd-ch1. This is a model of the real hardware -- the clock divider is in TVE, not TCON. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC
在 2017-06-01 02:43，Maxime Ripard 写道： On Wed, May 24, 2017 at 04:25:46PM +0800, Icenowy Zheng wrote: 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard 写到: >On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote: >> 在 2017-05-23 20:53，Maxime Ripard 写道： >> > On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote: >> > > Hi, >> > > >> > > Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai >napisal(a): >> > > > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec > >> > > wrote: >> > > > > Hi, >> > > > > >> > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng >napisal(a): >> > > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard >> > > > > >> > > > > electrons.com> 写到: >> > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng >wrote: >> > > > >> >> Allwinner H3 features a TV encoder similar to the one in >earlier >> > > > >> > >> > > > >> >SoCs, >> > > > >> > >> > > > >> >> but with some different points about clocks: >> > > > >> >> - It has a mod clock and a bus clock. >> > > > >> >> - The mod clock must be at a fixed rate to generate >signal. >> > > > >> > >> > > > >> >Why? >> > > > >> >> > > > >> It's experiment result by Jernej. >> > > > >> >> > > > >> The clock rates in BSP kernel is also specially designed >> > > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. >> > > > > >> > > > > My experiments and search through BSP code showed that TVE >seems to have >> > > > > additional fixed predivider 8. So if you want to generate 27 >MHz clock, >> > > > > unit has to be feed with 216 MHz. >> > > > > >> > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a >bit low for >> > > > > DE2, >> > > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to >generate 216 MHz. >> > > > > This clock is then divided by 8 internaly to get final 27 >MHz. >> > > > > >> > > > > Please note that I don't have any hard evidence to support >that, only >> > > > > experimental data. However, only that explanation make sense >to me. >> > > > > >> > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which >both use 27 MHz >> > > > > base clock. Further experiments are needed to check if there >is any >> > > > > possibility to have other resolutions by manipulating clocks >and give >> > > > > other proper settings. I plan to do that, but not in very >near future. >> > > > >> > > > You only have composite video output, and those are the only 2 >standard >> > > > resolutions that make any sense. >> > > >> > > Right, other resolutions are for VGA. >> > > >> > > Anyway, I did some more digging in A10 and R40 datasheets. I >think >> > > that H3 TVE >> > > unit is something in between. R40 TVE has a setting to select "up >> > > sample". >> > >> > That might be just another translation of oversampling :) >> > >> > I didn't know it could be applied to composite signals though, but >I >> > guess this is just another analog signal after all. >> > >> > > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP >> > > driver on R40 >> > > has this setting enabled only for PAL and NTSC and it is always >216 >> > > MHz. I >> > > think that H3 may have this hardwired to 216 MHz and this would >be >> > > the reason >> > > why 216 MHz is needed. >> > > >> > > Has anyone else any better explanation? >> > >> > That's already a pretty good one. >> > >> > Either way, wether this is upsampling, oversampling or just a >> > pre-divider, this can and should be dealt with in the mode_set >> > callback, and not in the probe. >> >> I got a better idea -- let TVE driver have the CLK_TVE as an >> input and create a subclock output with divider 16, and feed this >> subclock to TCON lcd-ch1. >> >> This is a model of the real hardware -- the clock divider is in >> TVE, not TCON. > >That's definitely not a good representation of the hardware. There's >one clock, it goes to the TCON, period. No, I still think it goes to the TVE as: 1. it's named TVE in datasheet. Feel free to come up with a better, more sensible explanation? 2. Generating signal with such a low resolution but such a high dotclock is not a good situation. What? What do you mean? The pixel clock is 27MHz, I'm pretty sure we agree on that. Yes, so I don't think the TCON code should set the clock to any value rather than 27MHz. So we should create a clock with divider in TVE, and feed it to TCON. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2
在 2017-05-24 16:14，Maxime Ripard 写道：
On Sat, May 20, 2017 at 02:00:22AM +0800, Icenowy Zheng wrote:
于 2017年5月20日 GMT+08:00 上午1:57:53, Maxime Ripard
写到:
>On Thu, May 18, 2017 at 12:43:46AM +0800, Icenowy Zheng wrote:
>> Some SoC's DE2 has two mixers. Defaultly the mixer0 is connected to
>> tcon0 and mixer1 is connected to tcon1; however by setting a bit
>> the connection can be swapped.
>>
>> As we now hardcode the default connection, ignore the bonus endpoint
>for
>> the mixer's output and the TCON's input, as they stands for the
>swapped
>> connection.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> drivers/gpu/drm/sun4i/sun4i_drv.c | 27 ++
>> drivers/gpu/drm/sun4i/sun4i_tcon.c | 39
>+-
>> drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 ++
>> 3 files changed, 59 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
>b/drivers/gpu/drm/sun4i/sun4i_drv.c
>> index 1dd1948025d2..29bf1325ded6 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
>> @@ -173,6 +173,13 @@ static bool sun4i_drv_node_is_frontend(struct
>device_node *node)
>>of_device_is_compatible(node,
>"allwinner,sun8i-a33-display-frontend");
>> }
>>
>> +static bool sun4i_drv_node_is_swappable_de2_mixer(struct device_node
>*node)
>> +{
>> + /* The V3s has only one mixer-tcon pair, so it's not listed here.
>*/
>> + return of_device_is_compatible(node,
>"allwinner,sun8i-h3-de2-mixer0") ||
>> + of_device_is_compatible(node,
"allwinner,sun8i-h3-de2-mixer1");
>> +}
>> +
>> static bool sun4i_drv_node_is_tcon(struct device_node *node)
>> {
>>return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
>> @@ -249,6 +256,26 @@ static int sun4i_drv_add_endpoints(struct device
>*dev,
>>}
>>}
>>
>> + /*
>> + * The second endpoint of the output of a swappable DE2 mixer
>> + * is the TCON after connection swapping.
>> + * Ignore it now, as we now hardcode mixer0->tcon0,
>> + * mixer1->tcon1 connection.
>> + */
>> + if (sun4i_drv_node_is_swappable_de2_mixer(node)) {
>> + struct of_endpoint endpoint;
>> +
>> + if (of_graph_parse_endpoint(ep, &endpoint)) {
>> + DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
>> + continue;
>> + }
>> +
>> + if (endpoint.id) {
>> + DRM_DEBUG_DRIVER("Endpoint is an unused
connection for DE2
>mixer... skipping\n");
>> + continue;
>> + }
>> + }
>> +
>>/* Walk down our tree */
>>count += sun4i_drv_add_endpoints(dev, match, remote);
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index f44a37a5993d..89a215ff2370 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -425,7 +425,8 @@ static int sun4i_tcon_init_regmap(struct device
>*dev,
>> * requested via the get_id function of the engine.
>> */
>> static struct sunxi_engine *sun4i_tcon_find_engine(struct sun4i_drv
>*drv,
>> - struct device_node *node)
>> + struct device_node *node,
>> + bool skip_bonus_ep)
>> {
>>struct device_node *port, *ep, *remote;
>>struct sunxi_engine *engine;
>> @@ -439,6 +440,20 @@ static struct sunxi_engine
>*sun4i_tcon_find_engine(struct sun4i_drv *drv,
>>if (!remote)
>>continue;
>>
>> + if (skip_bonus_ep) {
>> + struct of_endpoint endpoint;
>> +
>> + if (of_graph_parse_endpoint(ep, &endpoint)) {
>> + DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
>> + continue;
>> + }
>> +
>> + if (endpoint.id) {
>> + DRM_DEBUG_DRIVER("S
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC
在 2017-05-24 15:30，Maxime Ripard 写道： On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote: 在 2017-05-23 20:53，Maxime Ripard 写道： > On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote: > > Hi, > > > > Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a): > > > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec > > wrote: > > > > Hi, > > > > > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): > > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard > > > > > > > electrons.com> 写到: > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: > > > >> >> Allwinner H3 features a TV encoder similar to the one in earlier > > > >> > > > > >> >SoCs, > > > >> > > > > >> >> but with some different points about clocks: > > > >> >> - It has a mod clock and a bus clock. > > > >> >> - The mod clock must be at a fixed rate to generate signal. > > > >> > > > > >> >Why? > > > >> > > > >> It's experiment result by Jernej. > > > >> > > > >> The clock rates in BSP kernel is also specially designed > > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. > > > > > > > > My experiments and search through BSP code showed that TVE seems to have > > > > additional fixed predivider 8. So if you want to generate 27 MHz clock, > > > > unit has to be feed with 216 MHz. > > > > > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a bit low for > > > > DE2, > > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate 216 MHz. > > > > This clock is then divided by 8 internaly to get final 27 MHz. > > > > > > > > Please note that I don't have any hard evidence to support that, only > > > > experimental data. However, only that explanation make sense to me. > > > > > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both use 27 MHz > > > > base clock. Further experiments are needed to check if there is any > > > > possibility to have other resolutions by manipulating clocks and give > > > > other proper settings. I plan to do that, but not in very near future. > > > > > > You only have composite video output, and those are the only 2 standard > > > resolutions that make any sense. > > > > Right, other resolutions are for VGA. > > > > Anyway, I did some more digging in A10 and R40 datasheets. I think > > that H3 TVE > > unit is something in between. R40 TVE has a setting to select "up > > sample". > > That might be just another translation of oversampling :) > > I didn't know it could be applied to composite signals though, but I > guess this is just another analog signal after all. > > > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP > > driver on R40 > > has this setting enabled only for PAL and NTSC and it is always 216 > > MHz. I > > think that H3 may have this hardwired to 216 MHz and this would be > > the reason > > why 216 MHz is needed. > > > > Has anyone else any better explanation? > > That's already a pretty good one. > > Either way, wether this is upsampling, oversampling or just a > pre-divider, this can and should be dealt with in the mode_set > callback, and not in the probe. I got a better idea -- let TVE driver have the CLK_TVE as an input and create a subclock output with divider 16, and feed this subclock to TCON lcd-ch1. This is a model of the real hardware -- the clock divider is in TVE, not TCON. That's definitely not a good representation of the hardware. There's one clock, it goes to the TCON, period. However, the TV encoder has a constraint on that clock rate. This can be easily implemented using a custom encoder state where you'd set the multiplier to set on that clock, and the TCON will use it. P.S. how to do such a custom state? Should I do the multiplying in sun4i_tv_mode_to_drm_mode? 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 v2 00/11] Support for H3 Composite Output support
在 2017-06-05 00:01，Icenowy Zheng 写道： Allwinner H3 SoC features a TV Encoder like the one in Allwinner A13, which can only output TV Composite signal. The display pipeline of H3 is also special -- it has two mixers and two TCONs, of which the connection can be swapped. The TCONs do not have channel 0 (as they are all connected to internal bridges, TVE and HDMI TX). Add support for the display pipeline and the TVE in H3, in order to make it possible to display something with mainline kernel with H3. The image quality of TVE is bad, so HDMI is a better output -- this patchset also prepared the mixers and TCONs for HDMI output, and the HDMI controller driver is already done by Jernej Skrabec. So if possible, please apply PATCH 1~5 and 8,9 as soon as possible, so that Jernej can submit his HDMI patches. Currently the jack detection feature of the TVE is still not so clear -- so it's not implemented in this version. Thus the TV output shouldn't be defaultly enabled now. Icenowy Zheng (11): dt-bindings: update the binding for Allwinner H3 TVE support drm: sun4i: add support for H3 mixers drm: sun4i: ignore swapped mixer<->tcon connection for DE2 drm: sun4i: add support for H3's TCON0/1 drm: sun4i: add compatible for H3 display engine drm: sun4i: add color space correction support for DE2 mixer drm: sun4i: add support for the TV encoder in H3 SoC clk: sunxi-ng: allow CLK_DE to set CLK_PLL_DE for H3 clk: sunxi-ng: export CLK_PLL_DE for H3 ARM: sun8i: h3: add display engine pipeline for TVE [DO NOT MERGE] ARM: sun8i: h3: enable TV output on Orange Pi PC Maxime, could you pick some patches that you think appliable in this series? (especially PATCH 1, the binding patch) I think they can be useful. Thanks! .../bindings/display/sunxi/sun4i-drm.txt | 37 +++- arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 12 ++ arch/arm/boot/dts/sun8i-h3.dtsi| 186 + drivers/clk/sunxi-ng/ccu-sun8i-h3.c| 2 +- drivers/clk/sunxi-ng/ccu-sun8i-h3.h| 3 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 46 + drivers/gpu/drm/sun4i/sun4i_tcon.c | 113 ++--- drivers/gpu/drm/sun4i/sun4i_tcon.h | 3 + drivers/gpu/drm/sun4i/sun4i_tv.c | 35 +++- drivers/gpu/drm/sun4i/sun8i_mixer.c| 53 ++ drivers/gpu/drm/sun4i/sun8i_mixer.h| 6 +- include/dt-bindings/clock/sun8i-h3-ccu.h | 2 + 12 files changed, 463 insertions(+), 35 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2
在 2017-06-07 22:38，Maxime Ripard 写道： On Wed, Jun 07, 2017 at 06:01:02PM +0800, Icenowy Zheng wrote: >I have no idea what this is supposed to be doing either. > >I might be wrong, but I really feel like there's a big mismatch >between your commit log, and what you actually implement. > >In your commit log, you should state: > >A) What is the current behaviour >B) Why that is a problem >C) How do you address it > >And you don't. > >However, after discussing it with Chen-Yu, it seems like you're trying >to have all the mixers probed before the TCONs. If that is so, there's >nothing specific to the H3 here, and we also have the same issue on >dual-pipeline DE1 (A10, A20, A31). Chen-Yu worked on that a bit, but >the easiest solution would be to move from a DFS algorithm to walk >down the graph to a BFS one. > >That way, we would add all mixers first, then the TCONs, then the >encoders, and the component framework will probe them in order. No. I said that they're swappable, however, I don't want to implement the swap now, but hardcode 0-0 1-1 connection. We're on the same page, it's definitely not what I was mentionning here. This would require a significant rework, and the usecase is still unclear for now. However, as you and Chen-Yu said, device tree should reflect the real hardware, there will be bonus endpoints for the swapped connection. If by bonus you mean connections from mixer 0 to tcon 1 and mixer 1 to tcon 0, then yes, we're going to need it. What I want to do is to ignore the bonus connection, in order to prevent them from confusing the code. If you just change the bind sequence, I think it cannot be prevented that wrong connections will be bound. This is where I don't follow you anymore. The component framework doesn't list connections but devices. The swapped connections do not matter here, we have the same set of devices: mixer0, mixer1, tcon0 and tcon1. The thing that does change with your patch is that before, the binding sequence would have been mixer0, tcon0, tcon1, mixer1. With your patch, it's mixer0, tcon0, mixer1, tcon1. So, again, stating what issue you were seeing before making this patch would be very helpful to see what you're trying to do / fix. So maybe I can drop the forward search (searching output) code, and keep only the backward search (search input) code in TCON? Forward search code is only used when binding, but backward search is used for TCON to find connected mixer. 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: [linux-sunxi] Re: [PATCH 5/7] drm/sun4i: backend: Offset layer buffer address by DRAM starting address
在 2017-10-16 16:00，Maxime Ripard 写道： Hi, I've applied all the other patches. On Sat, Oct 14, 2017 at 12:02:50PM +0800, Chen-Yu Tsai wrote: The display backend, as well as other peripherals that have a DRAM clock gate and access DRAM directly, bypassing the system bus, address the DRAM starting from 0x0, while physical addresses the system uses starts from 0x4000 (or 0x2000 in A80's case). Correct the address configured into the backend layer registers by PHYS_OFFSET to account for this. However, I'm a bit confused at this. The driver has been working so far, which it wouldn't have been able to if the address was wrong. How was this problem noticed, and how can that fix not be an issue in itself? On devices with <=1GiB (0x4000) DRAM, the DRAM access will just wrap back and no problem would be seen. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/23] drm/sun4i: sun8i: properly support UI channels
在 2017-10-17 17:06，Maxime Ripard 写道：
The current code has the wrong macro to get the registers offsets of
the
UI-registers, with an off-by-0x1000 error.
It works so far by accident, since the UI channel used everywhere else
is
the number of VI planes, which has always been 1 so far, and the offset
between two UI channels is 0x1000.
No, I number the VI channels and UI channels in the same sequence, as
it's
also what Allwinner does -- VI channels and UI channels all have the
size
0x1000.
On H3/A64/A83T, the sequence is: 0 - VI, 1 - UI0(, 2 - UI1, 3 - UI2);
on V3s, the sequence is: 0 - VI0, 1 - VI1, 2 - UI.
This patch assumes that there's only one VI channel, which breaks V3s
support.
Let's correct that behaviour by setting the UI chan number in the
sun8i_ui
structure, and remove the hardcoded values pretty much everywhere. Once
we
have sane values, we can convert the macros to their actual definition.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 50
--
drivers/gpu/drm/sun4i/sun8i_mixer.h | 32 ++-
drivers/gpu/drm/sun4i/sun8i_ui.c| 12 ---
drivers/gpu/drm/sun4i/sun8i_ui.h| 1 +-
4 files changed, 46 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 1955b2a36ac5..5afe8ef709a5 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -37,14 +37,12 @@ static void sun8i_mixer_commit(struct sunxi_engine
*engine)
SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
}
-void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
- int layer, bool enable)
+void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer, struct
sun8i_ui *ui,
+ bool enable)
{
u32 val;
- /* Currently the first UI channel is used */
- int chan = mixer->cfg->vi_num;
- DRM_DEBUG_DRIVER("Enabling layer %d in channel %d\n", layer, chan);
+ DRM_DEBUG_DRIVER("Enabling layer %d in channel %d\n", ui->id,
ui->chan);
if (enable)
val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN;
@@ -52,16 +50,16 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer
*mixer,
val = 0;
regmap_update_bits(mixer->engine.regs,
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
+ SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ui->chan, ui->id),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
/* Set the alpha configuration */
regmap_update_bits(mixer->engine.regs,
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
+ SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ui->chan, ui->id),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK,
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF);
regmap_update_bits(mixer->engine.regs,
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
+ SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ui->chan, ui->id),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK,
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_DEF);
}
@@ -90,14 +88,13 @@ static int sun8i_mixer_drm_format_to_layer(struct
drm_plane *plane,
}
int sun8i_mixer_update_layer_coord(struct sun8i_mixer *mixer,
-int layer, struct drm_plane *plane)
+ struct sun8i_ui *ui)
{
+ struct drm_plane *plane = &ui->plane;
struct drm_plane_state *state = plane->state;
struct drm_framebuffer *fb = state->fb;
- /* Currently the first UI channel is used */
- int chan = mixer->cfg->vi_num;
- DRM_DEBUG_DRIVER("Updating layer %d\n", layer);
+ DRM_DEBUG_DRIVER("Updating layer %d\n", ui->id);
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H:
%u\n",
@@ -115,7 +112,7 @@ int sun8i_mixer_update_layer_coord(struct
sun8i_mixer *mixer,
state->crtc_h));
DRM_DEBUG_DRIVER("Updating channel size\n");
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_OVL_SIZE(chan),
+SUN8I_MIXER_CHAN_UI_OVL_SIZE(ui->chan),
SUN8I_MIXER_SIZE(state->crtc_w,
state->crtc_h));
}
@@ -123,35 +120,34 @@ int sun8i_mixer_update_layer_coord(struct
sun8i_mixer *mixer,
/* Set the line width */
DRM_DEBUG_DRIVER("Layer line width: %d bytes\n", fb->pitches[0]);
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_LAYER_PITCH(chan, layer),
+SUN8I_MIXER_CHAN_UI_LAYER_PITCH(ui->chan, ui->id),
fb->pitches[0]);
/* Se
Re: [PATCH 16/23] drm/sun4i: Add A83T support
在 2017-10-17 17:06，Maxime Ripard 写道：
Add support for the A83T display pipeline.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 +
drivers/gpu/drm/sun4i/sun8i_mixer.c | 4
4 files changed, 10 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 46df3b78ae9e..c0fa233ec1fc 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -90,6 +90,7 @@ Required properties:
* allwinner,sun6i-a31-tcon
* allwinner,sun6i-a31s-tcon
* allwinner,sun8i-a33-tcon
+ * allwinner,sun8i-a83t-tcon
Should be tcon0 -- tcon0 on A83T has only channel 0 and tcon1 has only
channel 1.
* allwinner,sun8i-v3s-tcon
- reg: base address and size of memory-mapped region
- interrupts: interrupt associated to this IP
@@ -209,6 +210,7 @@ supported.
Required properties:
- compatible: value must be one of:
+* allwinner,sun8i-a83t-de2-mixer
Since the capability of mixer0 and mixer1 are different (smart
backlight, write-back, VEP of the VI channel and extra UI
channels), I suggest to use ID-specific compatibles here.
* allwinner,sun8i-v3s-de2-mixer
- reg: base address and size of the memory-mapped region.
- clocks: phandles to the clocks feeding the mixer
@@ -236,6 +238,7 @@ Required properties:
* allwinner,sun6i-a31-display-engine
* allwinner,sun6i-a31s-display-engine
* allwinner,sun8i-a33-display-engine
+* allwinner,sun8i-a83t-display-engine
* allwinner,sun8i-v3s-display-engine
- allwinner,pipelines: list of phandle to the display engine
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index a27efad9bc76..439f116bb3b5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -189,6 +189,7 @@ static bool sun4i_drv_node_is_tcon(struct
device_node *node)
of_device_is_compatible(node, "allwinner,sun6i-a31-tcon") ||
of_device_is_compatible(node, "allwinner,sun6i-a31s-tcon") ||
of_device_is_compatible(node, "allwinner,sun8i-a33-tcon") ||
+ of_device_is_compatible(node, "allwinner,sun8i-a83t-tcon") ||
of_device_is_compatible(node, "allwinner,sun8i-v3s-tcon");
}
@@ -347,6 +348,7 @@ static const struct of_device_id
sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun6i-a31-display-engine" },
{ .compatible = "allwinner,sun6i-a31s-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
+ { .compatible = "allwinner,sun8i-a83t-display-engine" },
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
{ }
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 6a20a467ee6d..eb3c8bad4977 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1063,6 +1063,7 @@ static const struct of_device_id
sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun6i-a31-tcon", .data = &sun6i_a31_quirks
},
{ .compatible = "allwinner,sun6i-a31s-tcon", .data =
&sun6i_a31s_quirks },
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks
},
+ { .compatible = "allwinner,sun8i-a83t-tcon", .data =
&sun8i_v3s_quirks },
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = &sun8i_v3s_quirks
},
{ }
};
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 86c6c24b5105..c6030ce130d3 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -385,6 +385,10 @@ static const struct sun8i_mixer_cfg
sun8i_v3s_mixer_cfg = {
static const struct of_device_id sun8i_mixer_of_table[] = {
{
+ .compatible = "allwinner,sun8i-a83t-de2-mixer",
+ .data = &sun8i_v3s_mixer_cfg,
As I said, V3s has 2 VI channels, so it totally shouldn't share
config with A83T.
+ },
+ {
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = &sun8i_v3s_mixer_cfg,
},
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/10] Allwinner H3/H5/A64(DE2) SimpleFB support
在 2017-10-27 23:06，Icenowy Zheng 写道： This patchset adds support for the SimpleFB on Allwinner SoCs with "Display Engine 2.0". PATCH 1 to PATCH 3 are DE2 CCU fixes for H3/H5 SoCs. PATCH 4 adds the pipeline strings for DE2 SimpleFB. PATCH 5 to 7 adds necessary device tree nodes (DE2 CCU and SimpleFB) for H3/H5 SoCs. PATCH 8 to 10 are for Allwinner A64 SoC to enable SimpleFB. Icenowy Zheng (10): dt-bindings: fix the binding of Allwinner DE2 CCU of A83T and H3 clk: sunxi-ng: add support for Allwinner H3 DE2 CCU clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU dt-bindings: simplefb-sunxi: add pipelines for DE2 ARM: sun8i: h3/h5: add DE2 CCU device node for H3 arm64: allwinner: h5: add compatible string for DE2 CCU ARM: sunxi: h3/h5: add simplefb nodes dt-bindings: add binding for A64 DE2 CCU SRAM Sorry, but don't apply the following patches for two reasons: - the implementation of SRAM claiming in DE2 CCU is forgotten to be sent; - the patch that adds DE2 CCU have an error. arm64: allwinner: a64: add DE2 CCU for A64 SoC arm64: allwinner: a64: add simplefb for A64 SoC .../devicetree/bindings/clock/sun8i-de2.txt| 10 +++- .../bindings/display/simple-framebuffer-sunxi.txt | 4 ++ arch/arm/boot/dts/sun8i-h3.dtsi| 4 ++ arch/arm/boot/dts/sunxi-h3-h5.dtsi | 43 ++ arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 65 ++ arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 4 ++ drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 53 +- 7 files changed, 178 insertions(+), 5 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 01/13] dt-bindings: update the binding for Allwinner H3 DE2 support
在 2017-08-02 12:53，Jernej Škrabec 写道： Hi Icenowy, Dne torek, 01. avgust 2017 ob 15:12:52 CEST je Icenowy Zheng napisal(a): Allwinner H3 features a "Display Engine 2.0". Add device tree bindings for the following parts: - H3 TCONs - H3 Mixers - H3 Display engine Signed-off-by: Icenowy Zheng --- .../bindings/display/sunxi/sun4i-drm.txt | 25 ++ 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 2ee6ff0ef98e..92512953943e 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -87,18 +87,17 @@ Required properties: * allwinner,sun6i-a31-tcon * allwinner,sun6i-a31s-tcon * allwinner,sun8i-a33-tcon + * allwinner,sun8i-h3-tcon * allwinner,sun8i-v3s-tcon - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the TCON. Three are needed: - 'ahb': the interface clocks - - 'tcon-ch0': The clock driving the TCON channel 0 - resets: phandles to the reset controllers driving the encoder - "lcd": the reset line for the TCON channel 0 - clock-names: the clock names mentioned above - reset-names: the reset names mentioned above - - clock-output-names: Name of the pixel clock created - ports: A ports node with endpoint definitions as defined in Documentation/devicetree/bindings/media/video-interfaces.txt. The @@ -112,7 +111,23 @@ Required properties: channel the endpoint is associated to. If that property is not present, the endpoint number will be used as the channel number. -On SoCs other than the A33 and V3s, there is one more clock required: +For the following compatibles: + * allwinner,sun5i-a13-tcon + * allwinner,sun6i-a31-tcon + * allwinner,sun6i-a31s-tcon + * allwinner,sun8i-a33-tcon + * allwinner,sun8i-v3s-tcon +there is one more clock and one more property required: + - clocks: + - 'tcon-ch0': The clock driving the TCON channel 0 + - clock-output-names: Name of the pixel clock created + +For the following compatibles: + * allwinner,sun5i-a13-tcon + * allwinner,sun6i-a31-tcon + * allwinner,sun6i-a31s-tcon + * allwinner,sun8i-h3-tcon +there is one more clock required: - 'tcon-ch1': The clock driving the TCON channel 1 DRC @@ -207,6 +222,8 @@ supported. Required properties: - compatible: value must be one of: * allwinner,sun8i-v3s-de2-mixer +* allwinner,sun8i-h3-de2-mixer0 +* allwinner,sun8i-h3-de2-mixer1 About that, I concur with Maxime here, plane number properties would be better. If we don't do this now, we will never have it. But I still prefer different compatibles, as the capabilities are already proven to be different between mixer0 and mixer1, and furtherly we cannot promise Allwinner won't add more functions only available at mixer0. Then we will be trapped into a situation that we describe more and more functions via properties, but they should be encoded into the compatible. Reference: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/512902.html Regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 07/13] ARM: sun8i: h3: add display engine pipeline barebone
在 2017-08-02 12:47，Jernej Škrabec 写道：
Hi Icenowy,
Dne torek, 01. avgust 2017 ob 15:12:58 CEST je Icenowy Zheng
napisal(a):
As we have already the support for the DE2 on Allwinner H3, add the
display engine pipeline device tree nodes to its DTSI file.
The H5 pipeline has some differences and will be enabled later.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-h3.dtsi | 170
1 file changed, 170
insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
b/arch/arm/boot/dts/sun8i-h3.dtsi index b36f9f423c39..75ad7b65a7fc
100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -41,6 +41,8 @@
*/
#include "sunxi-h3-h5.dtsi"
+#include
+#include
/ {
cpus {
@@ -72,6 +74,174 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-h3-display-engine";
+ allwinner,pipelines = <&mixer0>,
+ <&mixer1>;
+ status = "disabled";
+ };
+
+ soc {
+ display_clocks: clock@100 {
+ compatible = "allwinner,sun8i-a83t-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_BUS_DE>,
+<&ccu CLK_DE>;
+ clock-names = "bus",
+ "mod";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ assigned-clocks = <&ccu CLK_DE>;
+ assigned-clock-parents = <&ccu CLK_PLL_DE>;
+ assigned-clock-rates = <43200>;
+ };
I believe Maxime ask you to use clk_set_rate() in the past:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/512909.html
Yes, but I think the frequency is still part of our configuration, not
forced
by the hardware.
If we set it in the driver, why don't we set it to 300MHz?
(In fact for pipelines without TVE we can really use 300MHz for CLK_DE,
and if
we do not want 4K we can even use lower frequency)
Regards,
Jernej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 = &dbidev->dbi;
+ int ret, idx;
+ u8 addr_mode = 0x00;
+
+ if (!drm_dev_enter(pipe->crtc.dev, &idx))
+ 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 ^= MIP
[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 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 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 = <&pio 7 4 GPIO_ACTIVE_HIGH>;
+reset-gpios = <&r_pio 2 21 GPIO_ACTIVE_HIGH>;
+};
+};
+
+...
--
2.30.2
[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
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 = &dbidev->dbi;
> + int ret, idx;
> + u8 addr_mode = 0x00;
> +
> + if (!drm_dev_enter(pipe->crtc.dev, &idx))
> + 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_INVE
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
[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(&ctx->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
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(&dsi->dev, ARRAY_SIZE(ctx-
> >supplies),
> ctx->supplies);
> - if (ret < 0) {
> - dev_err(&dsi->dev, "Couldn't get regulators\n");
> - return ret;
> - }
> + if (ret < 0)
> + return dev_err_probe(&dsi->dev, ret, "Couldn't get
> regulators\n");
>
> ctx->reset = devm_gpiod_get(&dsi->dev, "reset",
> GPIOD_OUT_LOW);
> - if (IS_ERR(ctx->reset)) {
> - dev_err(&dsi->dev, "Couldn't get our reset GPIO\n");
> - return PTR_ERR(ctx->reset);
> - }
> + if (IS_ERR(ctx->reset))
> + return dev_err_probe(&dsi->dev, PTR_ERR(ctx->reset),
> + "Couldn't get our reset
> GPIO\n");
>
> drm_panel_init(&ctx->panel, &dsi->dev, &k101_im2ba02_funcs,
> DRM_MODE_CONNECTOR_DSI);
[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(&ctx->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
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
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 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设备。
[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/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
> >
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: [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: [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 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
[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
[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 --- Th
[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
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
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] 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月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
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 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 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
[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
[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:
+ - |
+&dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "xingbangda,xbd599";
+reg = <0>;
+backlight = <&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 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 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 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 = &uart0;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&r_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 = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+ power-supply = <®_ldo_io0>;
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -84,6 +93,30 @@ &dai {
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dldo1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "xingbangda,xbd599";
+ reg = <0>;
+ reset-gpios = <&pio 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
+ iovcc-supply = <®_dldo2>;
+ vcc-supply = <®_ldo_io0>;
+ backlight = <&backlight>;
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -188,6 +221,10 @@ &r_pio {
*/
};
+&r_pwm {
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
--
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
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 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 = <&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 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 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 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 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 = &uart0;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&r_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 = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+ power-supply = <®_ldo_io0>;
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -84,6 +93,30 @@ &dai {
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dldo1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "xingbangda,xbd599";
+ reg = <0>;
+ reset-gpios = <&pio 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
+ iovcc-supply = <®_dldo2>;
+ vcc-supply = <®_ldo_io0>;
+ backlight = <&backlight>;
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -188,6 +221,10 @@ &r_pio {
*/
};
+&r_pwm {
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
--
2.24.1
___
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 = &uart0;
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&r_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 = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
> + power-supply = <®_ldo_io0>;
> + };
> +
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -84,6 +93,30 @@ &dai {
> status = "okay";
> };
>
> +&de {
> + status = "okay";
> +};
> +
> +&dphy {
> + status = "okay";
> +};
> +
> +&dsi {
> + vcc-dsi-supply = <®_dldo1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + panel@0 {
> + compatible = "xingbangda,xbd599";
> + reg = <0>;
> + reset-gpios = <&pio 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
> + iovcc-supply = <®_dldo2>;
> + vcc-supply = <®_ldo_io0>;
> + backlight = <&backlight>;
> + };
> +};
> +
> &ehci0 {
> status = "okay";
> };
> @@ -188,6 +221,10 @@ &r_pio {
>*/
> };
>
> +&r_pwm {
> + status = "okay";
> +};
> +
> &r_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] 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 = &uart0;
+ ethernet0 = &rtl8723cs;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <8>;
+ enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
+ power-supply = <&vdd_bl>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ i2c-csi {
+ compatible = "i2c-gpio";
+ sda-gpios = <&pio 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
+ scl-gpios = <&pio 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 = <&csi_mclk_pin>;
+ clocks = <&ccu CLK_CSI_MCLK>;
+ c
[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:
+ - |
+&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 = <&pio 3 24 GPIO_ACTIVE_HIGH>;
+backlight = <&backlight>;
+};
+};
+
+...
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 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 = &uart0;
+ ethernet0 = &rtl8723cs;
+ };
+
+ 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 = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
+ power-supply = <&vdd_bl>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ i2c-csi {
+ compatible = "i2c-gpio";
+ sda-gpios = <&pio 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
+ scl-gpios = <&pio 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";
[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 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 = <&pio 3 24 GPIO_ACTIVE_HIGH>;
+backlight = <&backlight>;
+};
+};
+
+...
--
2.23.0
___
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] 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(&bo->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
[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 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
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?
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 >[drm:drm_atomic_helper_wait_f
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
>---
> drivers/gp
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: [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设备。
[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/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 tha
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,
> + &rate_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_ */
>
