Re: [linux-sunxi] [PATCH v4 1/2] drm/sun4i: Add mode_set callback to the engine

2021-05-31 Thread Priit Laes
On Fri, May 28, 2021 at 11:30:35PM +0300, Roman Stratiienko wrote:
> Create callback to allow updating engine's registers on mode change.
> 
> Signed-off-by: Roman Stratiienko 
> Reviewed-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/sun4i/sun4i_crtc.c   |  3 +++
>  drivers/gpu/drm/sun4i/sunxi_engine.h | 12 
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c 
> b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> index 45d9eb552d86..8f01a6b2bbef 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> @@ -146,6 +146,9 @@ static void sun4i_crtc_mode_set_nofb(struct drm_crtc 
> *crtc)
>   struct sun4i_crtc *scrtc = drm_crtc_to_sun4i_crtc(crtc);
>  
>   sun4i_tcon_mode_set(scrtc->tcon, encoder, mode);
> +
> + if (scrtc->engine->ops->mode_set)
> + scrtc->engine->ops->mode_set(scrtc->engine, mode);
>  }
>  
>  static const struct drm_crtc_helper_funcs sun4i_crtc_helper_funcs = {
> diff --git a/drivers/gpu/drm/sun4i/sunxi_engine.h 
> b/drivers/gpu/drm/sun4i/sunxi_engine.h
> index 548710a936d5..7faa844646ff 100644
> --- a/drivers/gpu/drm/sun4i/sunxi_engine.h
> +++ b/drivers/gpu/drm/sun4i/sunxi_engine.h
> @@ -9,6 +9,7 @@
>  struct drm_plane;
>  struct drm_device;
>  struct drm_crtc_state;
> +struct drm_display_mode;
>  
>  struct sunxi_engine;
>  
> @@ -108,6 +109,17 @@ struct sunxi_engine_ops {
>* This function is optional.
>*/
>   void (*vblank_quirk)(struct sunxi_engine *engine);
> +
> + /**
> +  * @mode_set:
> +  *
> +  * This callback is used to update engine registers that
> +  * responsible for display frame size and other mode attributes.

This sentence needs a little grammatical fixup.

> +  *
> +  * This function is optional.
> +  */
> + void (*mode_set)(struct sunxi_engine *engine,
> +  struct drm_display_mode *mode);
>  };
>  
>  /**
> -- 
> 2.30.2
> 
> -- 
> 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.
> To view this discussion on the web, visit 
> https://groups.google.com/d/msgid/linux-sunxi/20210528203036.17999-2-r.stratiienko%40gmail.com.


Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed

2019-03-19 Thread Priit Laes
On Mon, Jan 21, 2019 at 07:13:07PM +0100, Jernej Škrabec wrote:
> Dne ponedeljek, 21. januar 2019 ob 14:34:33 CET je Priit Laes napisal(a):
> > On Mon, Jan 21, 2019 at 08:37:29AM +0000, Priit Laes wrote:
> > > On Fri, Jan 18, 2019 at 10:51:10PM +0100, Jernej Škrabec wrote:
> > > > Dne četrtek, 17. januar 2019 ob 08:24:02 CET je Priit Laes napisal(a):
> > > > > On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote:
> > > > > > Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a):
> > > > > > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote:
> > > > > > > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes 
> napisal(a):
> > > > > > > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec 
> wrote:
> > > > > > > > > > Currently MP clocks don't consider adjusting parent rate
> > > > > > > > > > even if
> > > > > > > > > > they
> > > > > > > > > > are allowed to do so. Such behaviour considerably lowers
> > > > > > > > > > amount of
> > > > > > > > > > possible rates, which is very inconvenient when such clock
> > > > > > > > > > is used
> > > > > > > > > > for
> > > > > > > > > > pixel clock, for example.
> > > > > > > > > > 
> > > > > > > > > > In order to improve the situation, adjusting parent rate is
> > > > > > > > > > considered
> > > > > > > > > > when allowed.
> > > > > > > > > > 
> > > > > > > > > > This code is inspired by clk_divider_bestdiv() function,
> > > > > > > > > > which
> > > > > > > > > > does
> > > > > > > > > > basically the same thing for different clock type.
> > > > > > > > > 
> > > > > > > > > This patch seems to break the eMMC support on
> > > > > > > > > Olinuxino-Lime2-eMMC
> > > > > > > > > boards:
> > > > > > > > > 
> > > > > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly
> > > > > > > > > filesystem
> > > > > > > > > EXT4-fs (mmcblk1p4): write access will be enabled during
> > > > > > > > > recovery
> > > > > > > > > sunxi-mmc 1c11000.mmc: data error, sending stop command
> > > > > > > > > sunxi-mmc 1c11000.mmc: send stop command failed
> > > > > > > > 
> > > > > > > > I'm not familiar with A20. What is interesting is that emmc
> > > > > > > > clocks
> > > > > > > > don't
> > > > > > > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any
> > > > > > > > difference.
> > > > > > > > 
> > > > > > > > Can you post content of clk_summary with and without this patch?
> > > > > > > 
> > > > > > > In both cases I booted from FEL with rootfs on sdcard and tried to
> > > > > > > mount
> > > > > > > partition from eMMC to /mnt. With your patch, last step it fails.
> > > > > > > 
> > > > > > > pre-patch working:
> > > > > > > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2
> > > > > > > is
> > > > > > > off?)
> > > > > > > 
> > > > > > > post-patch not working:
> > > > > > > pll-periph[600MHz] ->  mmc2[500Mhz], (ahb-mmc2 is enabled)
> > > > > > > 
> > > > > > > Also, attached the logs.
> > > > > > 
> > > > > > Thanks. Just one more request. Can you enable debug messages in mmc
> > > > > > driver?
> > > > > > I'm interested in output of this line:
> > > > > > 
> > > > > > dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n",
> > > > > > 
> > > > > > clock, rate);
> > > > > 
> > > > > 1c11000 is eMMC:
> > > > > [snip]
> >

[RESEND PATCH] drm/sun4i: hdmi: Improve compatibility with hpd-less HDMI displays

2019-03-05 Thread Priit Laes
From: Priit Laes 

Even though HDMI connector features hotplug detect pin (HPD), there
are older devices which do not support it. For these devices fall
back to additional check on I2C bus to probe for EDID data.

One known example is HDMI/DVI display with following edid:

$ xxd -p display.edid
000005a1e0030100150f0103800f05780a0f6ea05748
9a2610474f20010101010101010101010101010101012a08804520e0
0b10200040009536001800fd0034441a2403000a202020202020
001000310a202020202020202020202000102a4030701300
782d111e006b

$ edid-decode display.edid
EDID version: 1.3
Manufacturer: AMA Model 3e0 Serial Number 1
Digital display
Maximum image size: 15 cm x 5 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Display x,y Chromaticity:
  Red:   0.6250, 0.3398
  Green: 0.2841, 0.6044
  Blue:  0.1494, 0.0644
  White: 0.2802, 0.3105

Established timings supported:
  640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
Standard timings supported:
Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm
   640  672  672  709 hborder 0
   480  484  484  491 vborder 0
   -hsync -vsync
   VertFreq: 60 Hz, HorFreq: 29478 Hz
Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz
Dummy block
Dummy block
Checksum: 0x6b (valid)

Now, current implementation is still flawed, as HDMI uses the
HPD signal to indicate that the source should re-read the EDID
due to change in device capabilities. With current HPD polling
implementation we would most certainly miss those notifications
as one can try just swapping two HDMI monitors really fast.

Proper fix would be skipping the HPD pin detection and relying
on just EDID fetching and acting on its changes.

CC: Russell King 
Signed-off-by: Priit Laes 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 416da5376701..44d5d50b7ada 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -242,14 +242,18 @@ sun4i_hdmi_connector_detect(struct drm_connector 
*connector, bool force)
struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
unsigned long reg;
 
-   if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
-  reg & SUN4I_HDMI_HPD_HIGH,
-  0, 50)) {
-   cec_phys_addr_invalidate(hdmi->cec_adap);
-   return connector_status_disconnected;
-   }
-
-   return connector_status_connected;
+   /* TODO: Drop HPD polling and instead keep track of EDID changes */
+   if (!readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
+   reg & SUN4I_HDMI_HPD_HIGH,
+   0, 50))
+   return connector_status_connected;
+
+   /* Fall back to EDID in case display does not support HPD */
+   if (!IS_ERR(hdmi->i2c) && drm_probe_ddc(hdmi->i2c))
+   return connector_status_connected;
+
+   cec_phys_addr_invalidate(hdmi->cec_adap);
+   return connector_status_disconnected;
 }
 
 static const struct drm_connector_funcs sun4i_hdmi_connector_funcs = {
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] [PATCH v3 05/11] drm/bridge: Add Analogix anx6345 support

2019-02-18 Thread Priit Laes
On Thu, Feb 14, 2019 at 09:09:51PM -0800, Vasily Khoruzhick wrote:
> From: Icenowy Zheng 
> 
> The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
> for portable devices. This driver adds initial support for RGB to eDP
> mode, without HPD and interrupts.
> 
> This is a configuration usually seen in eDP applications.
> 
> Signed-off-by: Icenowy Zheng 
> Signed-off-by: Vasily Khoruzhick 
> ---
>  drivers/gpu/drm/bridge/analogix/Kconfig   |  11 +
>  drivers/gpu/drm/bridge/analogix/Makefile  |   1 +
>  .../drm/bridge/analogix/analogix-anx6345.c| 845 ++
>  .../drm/bridge/analogix/analogix-i2c-dptx.c   |   2 +-
>  .../drm/bridge/analogix/analogix-i2c-dptx.h   |   8 +
>  .../bridge/analogix/analogix-i2c-txcommon.h   |   3 +
>  6 files changed, 869 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> 

[ ... ]

> +
> +static int anx6345_start(struct anx6345 *anx6345)
> +{
> + int err;
> +
> + if (!anx6345->powered)
> + anx6345_poweron(anx6345);
> +
> + /* Power on needed modules */
> + err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
> +  SP_POWERDOWN_CTRL_REG,
> +  SP_VIDEO_PD | SP_LINK_PD);
> +
> + err = anx6345_tx_initialization(anx6345);
> + if (err) {
> + DRM_ERROR("Failed transmitter initialization: %d\n", err);
> + goto err_poweroff;

You can move the whole err_poweroff section from below here and drop the goto.

> + }
> +
> + /*
> +  * This delay seems to help keep the hardware in a good state. Without
> +  * it, there are times where it fails silently.
> +  */
> + usleep_range(1, 15000);
> +
> + return 0;
> +
> +err_poweroff:
> + DRM_ERROR("Failed DisplayPort transmitter initialization: %d\n", err);
> + anx6345_poweroff(anx6345);
> +
> + return err;
> +}
> +

[ ... ]
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/sun4i: hdmi: Improve compatibility with hpd-less HDMI displays

2019-01-23 Thread Priit Laes
From: Priit Laes 

Even though HDMI connector features hotplug detect pin (HPD), there
are older devices which do not support it. For these devices fall
back to additional check on I2C bus to probe for EDID data.

One known example is HDMI/DVI display with following edid:

$ xxd -p display.edid
000005a1e0030100150f0103800f05780a0f6ea05748
9a2610474f20010101010101010101010101010101012a08804520e0
0b10200040009536001800fd0034441a2403000a202020202020
001000310a202020202020202020202000102a4030701300
782d111e006b

$ edid-decode display.edid
EDID version: 1.3
Manufacturer: AMA Model 3e0 Serial Number 1
Digital display
Maximum image size: 15 cm x 5 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Display x,y Chromaticity:
  Red:   0.6250, 0.3398
  Green: 0.2841, 0.6044
  Blue:  0.1494, 0.0644
  White: 0.2802, 0.3105

Established timings supported:
  640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
Standard timings supported:
Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm
   640  672  672  709 hborder 0
   480  484  484  491 vborder 0
   -hsync -vsync
   VertFreq: 60 Hz, HorFreq: 29478 Hz
Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz
Dummy block
Dummy block
Checksum: 0x6b (valid)

Now, current implementation is still flawed, as HDMI uses the
HPD signal to indicate that the source should re-read the EDID
due to change in device capabilities. With current HPD polling
implementation we would most certainly miss those notifications
as one can try just swapping two HDMI monitors really fast.

Proper fix would be skipping the HPD pin detection and relying
on just EDID fetching and acting on its changes.

CC: Russell King 
Signed-off-by: Priit Laes 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 25f4d676fd82..3b80380bc76e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -242,14 +242,18 @@ sun4i_hdmi_connector_detect(struct drm_connector 
*connector, bool force)
struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
unsigned long reg;
 
-   if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
-  reg & SUN4I_HDMI_HPD_HIGH,
-  0, 50)) {
-   cec_phys_addr_invalidate(hdmi->cec_adap);
-   return connector_status_disconnected;
-   }
-
-   return connector_status_connected;
+   /* TODO: Drop HPD polling and instead keep track of EDID changes */
+   if (!readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
+   reg & SUN4I_HDMI_HPD_HIGH,
+   0, 50))
+   return connector_status_connected;
+
+   /* Fall back to EDID in case display does not support HPD */
+   if (!IS_ERR(hdmi->i2c) && drm_probe_ddc(hdmi->i2c))
+   return connector_status_connected;
+
+   cec_phys_addr_invalidate(hdmi->cec_adap);
+   return connector_status_disconnected;
 }
 
 static const struct drm_connector_funcs sun4i_hdmi_connector_funcs = {
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [linux-sunxi] Re: HDMI/DVI spurious failure

2019-01-22 Thread Priit Laes
On Mon, Jan 21, 2019 at 02:25:17PM +0100, Maxime Ripard wrote:
> On Fri, Jan 18, 2019 at 02:51:26PM +0000, Priit Laes wrote:
> > On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote:
> > > On Fri, Jan 18, 2019 at 10:10:53AM +, Priit Laes wrote:
> > > > > > > > > It doesn't look related to the clock rate itself, since it 
> > > > > > > > > doesn't
> > > > > > > > > change between the two cases. However, in one case the DDC 
> > > > > > > > > clock is
> > > > > > > > > enabled and in the other it's disabled.
> > > > > > > > > 
> > > > > > > > > Was it taken at the same time? Maybe you can try with that 
> > > > > > > > > patch?
> > > > > > > > > http://code.bulix.org/z7jmkm-555344?raw
> > > > > > > > 
> > > > > > > > Thanks, after doing ~50+ boots I haven't seen a single failure.
> > > > > > > > 
> > > > > > > > Previously I had following failure cases which are now both 
> > > > > > > > fixed:
> > > > > > > > 
> > > > > > > > a) Linux without u-boot HDMI, where one in every 6-7 boots 
> > > > > > > > failed.
> > > > > > > > b) u--boot with hdmi enabled switching to simplefb and then 
> > > > > > > > switching
> > > > > > > > to kms, where previously all boots ended up with garbled screen.
> > > > > > > 
> > > > > > > So it's not really a fix, but it really looks like the clock is 
> > > > > > > not
> > > > > > > enabled when it should.
> > > > > > > 
> > > > > > > Can you describe your test scenario a bit more? What are you doing
> > > > > > > exactly, just booting? When do you start using the display? When 
> > > > > > > did
> > > > > > > you capture the debugfs output that you pasted?
> > > > > > 
> > > > > > Display is already connected via HDMI to the board. I don't really
> > > > > > remove it, I just boot the device and let it start Xorg.
> > > > > > Meanwhile I just ssh into the device and capture debugfs output.
> > > > > > See my 3 testing scenarios below.
> > > > > > 
> > > > > > Kernel also includes one extra patch to fall back to DDC, in case 
> > > > > > HPD
> > > > > > fails. Mostly the same I already submitted last November [1].
> > > > > 
> > > > > Do you have the same issue without that patch?
> > > > 
> > > > Can't really test this display without this patch and I do not have 
> > > > other
> > > > HDMI/DVI screens. And this issue does not happen with other HDMI 
> > > > displays
> > > > that I have here.
> > > 
> > > Can't you just force the monitor to be reported as present? It's not
> > > great and we don't want to merge it, but that would allow you to test
> > > that setup without too many interferences.
> > 
> > Baseline is clean u-boot / linux. U-boot does not detect/enable display.
> > 
> > 1) Booting Linux with drm.debug=0xe
> > 
> > * Linux does not detect/enable display
> > 
> > 2) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e
> > 
> > * Linux detects display, but display is garbled, and proper edid data is 
> > detected:
> > 
> > [snip]
> > pll-video1 000   32700  0   
> >   0  5
> >pll-video1-2x   000   65400  0   
> >   0  5
> >   hdmi-tmds00025153846  0   
> >   0  5
> >  hdmi-ddc  000   89835  0   
> >   0  5
> > [/snip]
> > 
> > 3) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e
> > And also one extra patch for Linux where HDMI DDC clock marked as critical
> > 
> > Linux detects and initializes display properly:
> > [snip]
> > pll-video1 110   32700  0   
> >   0  5
> >pll-video1-2x   110   65400  0   
> >   0  5
> >   hdmi-tmds 

[PATCH] drm/sun4i: hdmi: Fix usage of TMDS clock

2019-01-22 Thread Priit Laes
From: Priit Laes 

Although TMDS clock is required for HDMI to properly function,
nobody called clk_prepare_enable(). This fixes reference counting
issues and makes sure clock is running when it needs to be running.

Due to TDMS clock being parent clock for DDC clock, TDMS clock
was turned on/off for each EDID probe, causing spurious failures
for certain HDMI/DVI screens.

Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")

Signed-off-by: Priit Laes 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 061d2e0d9011..25f4d676fd82 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -92,6 +92,8 @@ static void sun4i_hdmi_disable(struct drm_encoder *encoder)
val = readl(hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
val &= ~SUN4I_HDMI_VID_CTRL_ENABLE;
writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
+
+   clk_disable_unprepare(hdmi->tmds_clk);
 }
 
 static void sun4i_hdmi_enable(struct drm_encoder *encoder)
@@ -112,6 +114,8 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder)
val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE;
 
writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
+
+   clk_prepare_enable(hdmi->tmds_clk);
 }
 
 static void sun4i_hdmi_mode_set(struct drm_encoder *encoder,
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed

2019-01-22 Thread Priit Laes
On Mon, Jan 21, 2019 at 08:37:29AM +, Priit Laes wrote:
> On Fri, Jan 18, 2019 at 10:51:10PM +0100, Jernej Škrabec wrote:
> > Dne četrtek, 17. januar 2019 ob 08:24:02 CET je Priit Laes napisal(a):
> > > On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote:
> > > > Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a):
> > > > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote:
> > > > > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes 
> > > > > > napisal(a):
> > > > > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote:
> > > > > > > > Currently MP clocks don't consider adjusting parent rate even if
> > > > > > > > they
> > > > > > > > are allowed to do so. Such behaviour considerably lowers amount 
> > > > > > > > of
> > > > > > > > possible rates, which is very inconvenient when such clock is 
> > > > > > > > used
> > > > > > > > for
> > > > > > > > pixel clock, for example.
> > > > > > > > 
> > > > > > > > In order to improve the situation, adjusting parent rate is
> > > > > > > > considered
> > > > > > > > when allowed.
> > > > > > > > 
> > > > > > > > This code is inspired by clk_divider_bestdiv() function, which
> > > > > > > > does
> > > > > > > > basically the same thing for different clock type.
> > > > > > > 
> > > > > > > This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC
> > > > > > > boards:
> > > > > > > 
> > > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly 
> > > > > > > filesystem
> > > > > > > EXT4-fs (mmcblk1p4): write access will be enabled during recovery
> > > > > > > sunxi-mmc 1c11000.mmc: data error, sending stop command
> > > > > > > sunxi-mmc 1c11000.mmc: send stop command failed
> > > > > > 
> > > > > > I'm not familiar with A20. What is interesting is that emmc clocks
> > > > > > don't
> > > > > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any
> > > > > > difference.
> > > > > > 
> > > > > > Can you post content of clk_summary with and without this patch?
> > > > > 
> > > > > In both cases I booted from FEL with rootfs on sdcard and tried to 
> > > > > mount
> > > > > partition from eMMC to /mnt. With your patch, last step it fails.
> > > > > 
> > > > > pre-patch working:
> > > > > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 is
> > > > > off?)
> > > > > 
> > > > > post-patch not working:
> > > > > pll-periph[600MHz] ->  mmc2[500Mhz], (ahb-mmc2 is enabled)
> > > > > 
> > > > > Also, attached the logs.
> > > > 
> > > > Thanks. Just one more request. Can you enable debug messages in mmc
> > > > driver?
> > > > I'm interested in output of this line:
> > > > 
> > > > dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n",
> > > > 
> > > > clock, rate);
> > > 
> > > 1c11000 is eMMC:
> > > [snip]
> > > [1.961644] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 
> > > 40
> > > [2.004091] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 
> > > 40
> > > [2.020296] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 
> > > 40
> > > [2.039917] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 
> > > 40
> > > [2.047847] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 
> > > 40
> > > [2.055053] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 
> > > 40
> > > [2.065256] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 
> > > 40
> > > [2.092351] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 
> > > 40
> > > [2.168725] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 
> > > 40
> > > [2.189403] sunxi-mmc 1c11000.mmc: setting clk to 5200

Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed

2019-01-21 Thread Priit Laes
On Fri, Jan 18, 2019 at 10:51:10PM +0100, Jernej Škrabec wrote:
> Dne četrtek, 17. januar 2019 ob 08:24:02 CET je Priit Laes napisal(a):
> > On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote:
> > > Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a):
> > > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote:
> > > > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes napisal(a):
> > > > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote:
> > > > > > > Currently MP clocks don't consider adjusting parent rate even if
> > > > > > > they
> > > > > > > are allowed to do so. Such behaviour considerably lowers amount of
> > > > > > > possible rates, which is very inconvenient when such clock is used
> > > > > > > for
> > > > > > > pixel clock, for example.
> > > > > > > 
> > > > > > > In order to improve the situation, adjusting parent rate is
> > > > > > > considered
> > > > > > > when allowed.
> > > > > > > 
> > > > > > > This code is inspired by clk_divider_bestdiv() function, which
> > > > > > > does
> > > > > > > basically the same thing for different clock type.
> > > > > > 
> > > > > > This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC
> > > > > > boards:
> > > > > > 
> > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem
> > > > > > EXT4-fs (mmcblk1p4): write access will be enabled during recovery
> > > > > > sunxi-mmc 1c11000.mmc: data error, sending stop command
> > > > > > sunxi-mmc 1c11000.mmc: send stop command failed
> > > > > 
> > > > > I'm not familiar with A20. What is interesting is that emmc clocks
> > > > > don't
> > > > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any
> > > > > difference.
> > > > > 
> > > > > Can you post content of clk_summary with and without this patch?
> > > > 
> > > > In both cases I booted from FEL with rootfs on sdcard and tried to mount
> > > > partition from eMMC to /mnt. With your patch, last step it fails.
> > > > 
> > > > pre-patch working:
> > > > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 is
> > > > off?)
> > > > 
> > > > post-patch not working:
> > > > pll-periph[600MHz] ->  mmc2[500Mhz], (ahb-mmc2 is enabled)
> > > > 
> > > > Also, attached the logs.
> > > 
> > > Thanks. Just one more request. Can you enable debug messages in mmc
> > > driver?
> > > I'm interested in output of this line:
> > > 
> > > dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n",
> > > 
> > >   clock, rate);
> > 
> > 1c11000 is eMMC:
> > [snip]
> > [1.961644] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
> > [2.004091] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
> > [2.020296] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
> > [2.039917] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
> > [2.047847] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
> > [2.055053] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
> > [2.065256] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
> > [2.092351] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
> > [2.168725] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
> > [2.189403] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded
> > 5200 [2.203340] sunxi-mmc 1c11000.mmc: setting clk to 5200,
> > rounded 5200 [2.211412] sunxi-mmc 1c11000.mmc: setting clk to
> > 5200, rounded 5200 [4.967865] sunxi-mmc 1c11000.mmc: setting
> > clk to 5200, rounded 5200 [8.755345] sunxi-mmc 1c11000.mmc:
> > setting clk to 5200, rounded 5200 [9.082510] sunxi-mmc
> > 1c11000.mmc: setting clk to 5200, rounded 5200
> > 
> > Here I tried to mount partition from eMMC...
> > 
> > [   72.167311] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded
> > 5200 [   72.269629] sunxi-mmc 1c11000.mmc: data error, sending stop
> &g

Re: [linux-sunxi] Re: HDMI/DVI spurious failure

2019-01-20 Thread Priit Laes
On Thu, Jan 17, 2019 at 12:33:40PM +0100, Maxime Ripard wrote:
> On Wed, Jan 16, 2019 at 08:35:16PM +0000, Priit Laes wrote:
> > On Wed, Jan 16, 2019 at 08:24:42PM +0100, Maxime Ripard wrote:
> > > Hi Priit,
> > > 
> > > On Wed, Jan 16, 2019 at 07:58:54AM +, Priit Laes wrote:
> > > > > On Mon, Jan 14, 2019 at 01:29:34PM +, Priit Laes wrote:
> > > > > > I have a somewhat curious case with one HDMI/DVI screen that fails
> > > > > > to initialize properly every 6-7 boots. The display itself is also
> > > > > > somewhat flawed (missing HPD pin and the VSYNC/HSYNC pulse width
> > > > > > is set to 0 in EDID), but I suspect there could be some issues
> > > > > > regarding timing in A20 HDMI driver in Linux.
> > > > > > 
> > > > ...
> > > > 
> > > > > It doesn't look related to the clock rate itself, since it doesn't
> > > > > change between the two cases. However, in one case the DDC clock is
> > > > > enabled and in the other it's disabled.
> > > > > 
> > > > > Was it taken at the same time? Maybe you can try with that patch?
> > > > > http://code.bulix.org/z7jmkm-555344?raw
> > > > 
> > > > Thanks, after doing ~50+ boots I haven't seen a single failure.
> > > > 
> > > > Previously I had following failure cases which are now both fixed:
> > > > 
> > > > a) Linux without u-boot HDMI, where one in every 6-7 boots failed.
> > > > b) u--boot with hdmi enabled switching to simplefb and then switching
> > > > to kms, where previously all boots ended up with garbled screen.
> > > 
> > > So it's not really a fix, but it really looks like the clock is not
> > > enabled when it should.
> > > 
> > > Can you describe your test scenario a bit more? What are you doing
> > > exactly, just booting? When do you start using the display? When did
> > > you capture the debugfs output that you pasted?
> > 
> > Display is already connected via HDMI to the board. I don't really
> > remove it, I just boot the device and let it start Xorg.
> > Meanwhile I just ssh into the device and capture debugfs output.
> > See my 3 testing scenarios below.
> > 
> > Kernel also includes one extra patch to fall back to DDC, in case HPD
> > fails. Mostly the same I already submitted last November [1].
> 
> Do you have the same issue without that patch?

Can't really test this display without this patch and I do not have other
HDMI/DVI screens. And this issue does not happen with other HDMI displays
that I have here.

> > For u-boot I have also some extra patches, to detect HPD-less HDMI
> > displays [2] + relax some EDID timing checks [3] so u-boot can actually
> > initialize my screen.
> 
> Do you have the same issues without those patches?

Yes. Without those patches display is not detected by u-boot (issues with
missing hpd pin and stricter edid checks), so kernel initializes display.

Disabling those patches is mostly the same as disabling the HDMI support
in u-boot the kernel side.

> > So first configuration with 100% failures:
> > 1) u-boot initializes HDMI ( A20-OLinuXino-Lime2-eMMC_defconfig )
> > 2) Linux switches to simplefb
> > ... somewhere around here blinking cursor is replaced with garbage
> > on screen 
> > 3) Linux switches to kms
> > 4) Xorg starts
> > 
> > Second scenario with failure every 6-7 boots:
> > 1) Disabled HDMI in u-boot for my board
> > 2) Linux sets up kms (sometimes fails here)
> > 3) Xorg starts
> > 4) ssh to machine and take the clock dump
> 
> Do you have the DRM fbdev emulation enabled in that case or is Xorg
> the first to setup the kms driver? Do you have some logs and a
> configuration?

Xorg logs for scenario 1 and 2 are basically the same whether or not
HDMI is enabled in u-boot. Now, differences arise when DDC clock is
marked as critical. Attached files:
* Xorg.0.ddc-critical.log
* Xorg.0.ddc-default.log

Also attached drm.debug outputs.

> Maxime
> 
> -- 
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com


Linux with (edid fallback + clk_critical patch)



[12.552] 
X.Org X Server 1.19.2
Release Date: 2017-03-02
[12.553] X Protocol Version 11, Revision 0
[12.553] Build Operating System: Linux 4.9.0-8-armmp-lpae armv7l Debian
[12.553] Current Operating System: Linux xxx-screen 
5.0.0-rc1-00021-g9b31f15d4c57 #76 SMP Fri Jan 18 11:12:40 EET 2019 armv7l
[12.553] Kernel command line: console=ttyS0,115200n8 root=/dev/mmcblk0p1 
rootwa

Re: [linux-sunxi] Re: HDMI/DVI spurious failure

2019-01-20 Thread Priit Laes
On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote:
> On Fri, Jan 18, 2019 at 10:10:53AM +0000, Priit Laes wrote:
> > > > > > > It doesn't look related to the clock rate itself, since it doesn't
> > > > > > > change between the two cases. However, in one case the DDC clock 
> > > > > > > is
> > > > > > > enabled and in the other it's disabled.
> > > > > > > 
> > > > > > > Was it taken at the same time? Maybe you can try with that patch?
> > > > > > > http://code.bulix.org/z7jmkm-555344?raw
> > > > > > 
> > > > > > Thanks, after doing ~50+ boots I haven't seen a single failure.
> > > > > > 
> > > > > > Previously I had following failure cases which are now both fixed:
> > > > > > 
> > > > > > a) Linux without u-boot HDMI, where one in every 6-7 boots failed.
> > > > > > b) u--boot with hdmi enabled switching to simplefb and then 
> > > > > > switching
> > > > > > to kms, where previously all boots ended up with garbled screen.
> > > > > 
> > > > > So it's not really a fix, but it really looks like the clock is not
> > > > > enabled when it should.
> > > > > 
> > > > > Can you describe your test scenario a bit more? What are you doing
> > > > > exactly, just booting? When do you start using the display? When did
> > > > > you capture the debugfs output that you pasted?
> > > > 
> > > > Display is already connected via HDMI to the board. I don't really
> > > > remove it, I just boot the device and let it start Xorg.
> > > > Meanwhile I just ssh into the device and capture debugfs output.
> > > > See my 3 testing scenarios below.
> > > > 
> > > > Kernel also includes one extra patch to fall back to DDC, in case HPD
> > > > fails. Mostly the same I already submitted last November [1].
> > > 
> > > Do you have the same issue without that patch?
> > 
> > Can't really test this display without this patch and I do not have other
> > HDMI/DVI screens. And this issue does not happen with other HDMI displays
> > that I have here.
> 
> Can't you just force the monitor to be reported as present? It's not
> great and we don't want to merge it, but that would allow you to test
> that setup without too many interferences.

Baseline is clean u-boot / linux. U-boot does not detect/enable display.

1) Booting Linux with drm.debug=0xe

* Linux does not detect/enable display

2) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e

* Linux detects display, but display is garbled, and proper edid data is 
detected:

[snip]
pll-video1 000   32700  0 0 
 5
   pll-video1-2x   000   65400  0 0 
 5
  hdmi-tmds00025153846  0 0 
 5
 hdmi-ddc  000   89835  0 0 
 5
[/snip]

3) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e
And also one extra patch for Linux where HDMI DDC clock marked as critical

Linux detects and initializes display properly:
[snip]
pll-video1 110   32700  0 0 
 5
   pll-video1-2x   110   65400  0 0 
 5
  hdmi-tmds11025153846  0 0 
 5
 hdmi-ddc  110   89835  0 0 
 5
[/snip]


> Maxime
> 
> -- 
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 
> -- 
> 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: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed

2019-01-17 Thread Priit Laes
On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote:
> Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a):
> > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote:
> > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes napisal(a):
> > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote:
> > > > > Currently MP clocks don't consider adjusting parent rate even if they
> > > > > are allowed to do so. Such behaviour considerably lowers amount of
> > > > > possible rates, which is very inconvenient when such clock is used for
> > > > > pixel clock, for example.
> > > > > 
> > > > > In order to improve the situation, adjusting parent rate is considered
> > > > > when allowed.
> > > > > 
> > > > > This code is inspired by clk_divider_bestdiv() function, which does
> > > > > basically the same thing for different clock type.
> > > > 
> > > > This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC
> > > > boards:
> > > > 
> > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem
> > > > EXT4-fs (mmcblk1p4): write access will be enabled during recovery
> > > > sunxi-mmc 1c11000.mmc: data error, sending stop command
> > > > sunxi-mmc 1c11000.mmc: send stop command failed
> > > 
> > > I'm not familiar with A20. What is interesting is that emmc clocks don't
> > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any difference.
> > > 
> > > Can you post content of clk_summary with and without this patch?
> > 
> > In both cases I booted from FEL with rootfs on sdcard and tried to mount
> > partition from eMMC to /mnt. With your patch, last step it fails.
> > 
> > pre-patch working:
> > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 is off?)
> > 
> > post-patch not working:
> > pll-periph[600MHz] ->  mmc2[500Mhz], (ahb-mmc2 is enabled)
> > 
> > Also, attached the logs.
> 
> Thanks. Just one more request. Can you enable debug messages in mmc driver? 
> I'm interested in output of this line:
> 
> dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n",
>   clock, rate);

1c11000 is eMMC:
[snip]
[1.961644] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
[2.004091] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
[2.020296] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
[2.039917] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
[2.047847] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
[2.055053] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
[2.065256] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
[2.092351] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
[2.168725] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40
[2.189403] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200
[2.203340] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200
[2.211412] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200
[4.967865] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200
[8.755345] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200
[9.082510] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200

Here I tried to mount partition from eMMC...

[   72.167311] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200
[   72.269629] sunxi-mmc 1c11000.mmc: data error, sending stop command
[   73.268999] sunxi-mmc 1c11000.mmc: send stop command failed
[/snip]

And clock tree:
[snip]
pll-periph-base330  12  0 0 
 5
   pll-periph  660   6  0 0 
 5
  mmc2 3305000  0 0 
 5
 mmc2_sample   1105000  0   120 
 5
 mmc2_output   1105000  060 
 5
  ahb 18   180   3  0 0 
 5
 ahb-mmc2  110   3  0 0 
 5
[/snip]


And without patch:
[snip]
[2.003341] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40
[2.019479] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40
[2.039144] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40
[2.047129] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40
[ 

Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed

2019-01-17 Thread Priit Laes
On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote:
> Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes napisal(a):
> > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote:
> > > Currently MP clocks don't consider adjusting parent rate even if they
> > > are allowed to do so. Such behaviour considerably lowers amount of
> > > possible rates, which is very inconvenient when such clock is used for
> > > pixel clock, for example.
> > > 
> > > In order to improve the situation, adjusting parent rate is considered
> > > when allowed.
> > > 
> > > This code is inspired by clk_divider_bestdiv() function, which does
> > > basically the same thing for different clock type.
> > 
> > This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC boards:
> > 
> > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem
> > EXT4-fs (mmcblk1p4): write access will be enabled during recovery
> > sunxi-mmc 1c11000.mmc: data error, sending stop command
> > sunxi-mmc 1c11000.mmc: send stop command failed
> > 
> 
> I'm not familiar with A20. What is interesting is that emmc clocks don't have 
> CLK_SET_RATE_PARENT flag set, so you shouldn't see any difference.
> 
> Can you post content of clk_summary with and without this patch?

In both cases I booted from FEL with rootfs on sdcard and tried to mount
partition from eMMC to /mnt. With your patch, last step it fails.

pre-patch working:
pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 is off?)

post-patch not working:
pll-periph[600MHz] ->  mmc2[500Mhz], (ahb-mmc2 is enabled)

Also, attached the logs.

> 
> Best regards,
> Jernej
> 
> > 
> > $ git bisect log
> > git bisect start
> > # good: [3df407b2a5346db1c48809706ece7a8616c79e0b] mmc: dw_mmc-bluefield:
> > simplify the probe() function git bisect good
> > 3df407b2a5346db1c48809706ece7a8616c79e0b
> > # bad: [00d59fde8532b2d42e80909d2e58678755e04da9] Merge tag 'mmc-v4.21' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc git bisect bad
> > 00d59fde8532b2d42e80909d2e58678755e04da9
> > # good: [01e421feec0817bb3141eaae4c517410d193d440] Merge branch 'fixes' into
> > next git bisect good 01e421feec0817bb3141eaae4c517410d193d440
> > # bad: [1eefdec18eded41833401cfd64749643ff72e7da] Merge branch
> > 'locking-core-for-linus' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad
> > 1eefdec18eded41833401cfd64749643ff72e7da
> > # good: [eaa76499711535fd64d747cc4ef0d78ab0fd41c6] Merge tag 'mtd/for-4.21'
> > of git://git.infradead.org/linux-mtd git bisect good
> > eaa76499711535fd64d747cc4ef0d78ab0fd41c6
> > # good: [4e4390ad067a61ce4e7607bd0df31f19a4caa36a] Merge tag
> > 'leds-for-4.21-rc1' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds git
> > bisect good 4e4390ad067a61ce4e7607bd0df31f19a4caa36a
> > # bad: [c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698] Merge
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next git bisect
> > bad c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698
> > # bad: [e4b99d415c3908581d4703203e1e805f043a3e71] Merge branch
> > 'irq-core-for-linus' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad
> > e4b99d415c3908581d4703203e1e805f043a3e71
> > # bad: [ffe05540d18013db62c43627836a3638e9a2c7aa] Merge branches
> > 'clk-renesas', 'clk-allwinner', 'clk-tegra', 'clk-meson' and 'clk-rockchip'
> > into clk-next git bisect bad ffe05540d18013db62c43627836a3638e9a2c7aa
> > # good: [1a501c8defe950571316d5ddd917bf44f5ed7bd4] Merge branches
> > 'clk-managed-registration', 'clk-spdx', 'clk-remove-basic' and
> > 'clk-ops-const' into clk-next git bisect good
> > 1a501c8defe950571316d5ddd917bf44f5ed7bd4
> > # good: [e74581b79ddd9b49b8c61e2791fc4dffc0245afb] Merge tag
> > 'meson-clk-4.21-2' of https://github.com/BayLibre/clk-meson into clk-meson
> > git bisect good e74581b79ddd9b49b8c61e2791fc4dffc0245afb
> > # good: [60baf75e3f5b76043c25328ac0c5320aaef5ea41] Merge tag
> > 'clk-renesas-for-v4.21-tag2' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into
> > clk-renesas git bisect good 60baf75e3f5b76043c25328ac0c5320aaef5ea41
> > # bad: [a41f85b6017ee20952a60e4330bcae2527fe2c2a] Merge tag
> > 'sunxi-clk-for-4.21' of
> > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into
> > clk-allwinner git bisect bad a41f85b6017ee20952a60e4330bcae2527fe2c2a
> > # bad: [ee678706e46d0d185c27cc214ad97828e0643159] clk: sunxi-ng: a64: Fix
> > gate bit of DSI DPHY git bisect bad
> > ee678

Re: [linux-sunxi] Re: HDMI/DVI spurious failure

2019-01-17 Thread Priit Laes
On Wed, Jan 16, 2019 at 08:24:42PM +0100, Maxime Ripard wrote:
> Hi Priit,
> 
> On Wed, Jan 16, 2019 at 07:58:54AM +0000, Priit Laes wrote:
> > > On Mon, Jan 14, 2019 at 01:29:34PM +, Priit Laes wrote:
> > > > I have a somewhat curious case with one HDMI/DVI screen that fails
> > > > to initialize properly every 6-7 boots. The display itself is also
> > > > somewhat flawed (missing HPD pin and the VSYNC/HSYNC pulse width
> > > > is set to 0 in EDID), but I suspect there could be some issues
> > > > regarding timing in A20 HDMI driver in Linux.
> > > > 
> > ...
> > 
> > > It doesn't look related to the clock rate itself, since it doesn't
> > > change between the two cases. However, in one case the DDC clock is
> > > enabled and in the other it's disabled.
> > > 
> > > Was it taken at the same time? Maybe you can try with that patch?
> > > http://code.bulix.org/z7jmkm-555344?raw
> > 
> > Thanks, after doing ~50+ boots I haven't seen a single failure.
> > 
> > Previously I had following failure cases which are now both fixed:
> > 
> > a) Linux without u-boot HDMI, where one in every 6-7 boots failed.
> > b) u--boot with hdmi enabled switching to simplefb and then switching
> > to kms, where previously all boots ended up with garbled screen.
> 
> So it's not really a fix, but it really looks like the clock is not
> enabled when it should.
> 
> Can you describe your test scenario a bit more? What are you doing
> exactly, just booting? When do you start using the display? When did
> you capture the debugfs output that you pasted?

Display is already connected via HDMI to the board. I don't really
remove it, I just boot the device and let it start Xorg.
Meanwhile I just ssh into the device and capture debugfs output.
See my 3 testing scenarios below.

Kernel also includes one extra patch to fall back to DDC, in case HPD
fails. Mostly the same I already submitted last November [1].

For u-boot I have also some extra patches, to detect HPD-less HDMI
displays [2] + relax some EDID timing checks [3] so u-boot can actually
initialize my screen.

So first configuration with 100% failures:
1) u-boot initializes HDMI ( A20-OLinuXino-Lime2-eMMC_defconfig )
2) Linux switches to simplefb
... somewhere around here blinking cursor is replaced with garbage
on screen 
3) Linux switches to kms
4) Xorg starts

Second scenario with failure every 6-7 boots:
1) Disabled HDMI in u-boot for my board
2) Linux sets up kms (sometimes fails here)
3) Xorg starts
4) ssh to machine and take the clock dump

Third scenario with no failures (but not suitable in long term..)
1) Disabled sun4i HDMI driver (CONFIG_DRM_SUN4I_HDMI=n) in Linux
2) u-boot sets up HDMI
3) Linux continues with simplefb
4) Xorg (with fbdev) starts


[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/613168.html
[2] https://lists.denx.de/pipermail/u-boot/2018-December/352541.html
[3] https://lists.denx.de/pipermail/u-boot/2018-December/352540.html
> 
> Thanks!
> Maxime
> 
> -- 
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [linux-sunxi] Re: HDMI/DVI spurious failure

2019-01-16 Thread Priit Laes
On Tue, Jan 15, 2019 at 10:49:51AM +0100, Maxime Ripard wrote:
> Hi,
> 
> (Sending those kind of bug reports to linux-sunxi doesn't really work,
> you should Cc at least the ML involved in the development of the
> driver at fault).

OK, sorry for that.

> 
> On Mon, Jan 14, 2019 at 01:29:34PM +, Priit Laes wrote:
> > I have a somewhat curious case with one HDMI/DVI screen that fails
> > to initialize properly every 6-7 boots. The display itself is also
> > somewhat flawed (missing HPD pin and the VSYNC/HSYNC pulse width
> > is set to 0 in EDID), but I suspect there could be some issues
> > regarding timing in A20 HDMI driver in Linux.
> > 
...

> It doesn't look related to the clock rate itself, since it doesn't
> change between the two cases. However, in one case the DDC clock is
> enabled and in the other it's disabled.
> 
> Was it taken at the same time? Maybe you can try with that patch?
> http://code.bulix.org/z7jmkm-555344?raw

Thanks, after doing ~50+ boots I haven't seen a single failure.

Previously I had following failure cases which are now both fixed:

a) Linux without u-boot HDMI, where one in every 6-7 boots failed.
b) u--boot with hdmi enabled switching to simplefb and then switching
to kms, where previously all boots ended up with garbled screen.

Priit :)
> 
> Maxime
> 
> -- 
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 
> -- 
> 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: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed

2019-01-10 Thread Priit Laes
On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote:
> Currently MP clocks don't consider adjusting parent rate even if they
> are allowed to do so. Such behaviour considerably lowers amount of
> possible rates, which is very inconvenient when such clock is used for
> pixel clock, for example.
> 
> In order to improve the situation, adjusting parent rate is considered
> when allowed.
> 
> This code is inspired by clk_divider_bestdiv() function, which does
> basically the same thing for different clock type.

This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC boards:

EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem
EXT4-fs (mmcblk1p4): write access will be enabled during recovery
sunxi-mmc 1c11000.mmc: data error, sending stop command
sunxi-mmc 1c11000.mmc: send stop command failed


$ git bisect log
git bisect start
# good: [3df407b2a5346db1c48809706ece7a8616c79e0b] mmc: dw_mmc-bluefield: 
simplify the probe() function
git bisect good 3df407b2a5346db1c48809706ece7a8616c79e0b
# bad: [00d59fde8532b2d42e80909d2e58678755e04da9] Merge tag 'mmc-v4.21' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
git bisect bad 00d59fde8532b2d42e80909d2e58678755e04da9
# good: [01e421feec0817bb3141eaae4c517410d193d440] Merge branch 'fixes' into 
next
git bisect good 01e421feec0817bb3141eaae4c517410d193d440
# bad: [1eefdec18eded41833401cfd64749643ff72e7da] Merge branch 
'locking-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 1eefdec18eded41833401cfd64749643ff72e7da
# good: [eaa76499711535fd64d747cc4ef0d78ab0fd41c6] Merge tag 'mtd/for-4.21' of 
git://git.infradead.org/linux-mtd
git bisect good eaa76499711535fd64d747cc4ef0d78ab0fd41c6
# good: [4e4390ad067a61ce4e7607bd0df31f19a4caa36a] Merge tag 
'leds-for-4.21-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
git bisect good 4e4390ad067a61ce4e7607bd0df31f19a4caa36a
# bad: [c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next
git bisect bad c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698
# bad: [e4b99d415c3908581d4703203e1e805f043a3e71] Merge branch 
'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad e4b99d415c3908581d4703203e1e805f043a3e71
# bad: [ffe05540d18013db62c43627836a3638e9a2c7aa] Merge branches 'clk-renesas', 
'clk-allwinner', 'clk-tegra', 'clk-meson' and 'clk-rockchip' into clk-next
git bisect bad ffe05540d18013db62c43627836a3638e9a2c7aa
# good: [1a501c8defe950571316d5ddd917bf44f5ed7bd4] Merge branches 
'clk-managed-registration', 'clk-spdx', 'clk-remove-basic' and 'clk-ops-const' 
into clk-next
git bisect good 1a501c8defe950571316d5ddd917bf44f5ed7bd4
# good: [e74581b79ddd9b49b8c61e2791fc4dffc0245afb] Merge tag 'meson-clk-4.21-2' 
of https://github.com/BayLibre/clk-meson into clk-meson
git bisect good e74581b79ddd9b49b8c61e2791fc4dffc0245afb
# good: [60baf75e3f5b76043c25328ac0c5320aaef5ea41] Merge tag 
'clk-renesas-for-v4.21-tag2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into 
clk-renesas
git bisect good 60baf75e3f5b76043c25328ac0c5320aaef5ea41
# bad: [a41f85b6017ee20952a60e4330bcae2527fe2c2a] Merge tag 
'sunxi-clk-for-4.21' of 
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into clk-allwinner
git bisect bad a41f85b6017ee20952a60e4330bcae2527fe2c2a
# bad: [ee678706e46d0d185c27cc214ad97828e0643159] clk: sunxi-ng: a64: Fix gate 
bit of DSI DPHY
git bisect bad ee678706e46d0d185c27cc214ad97828e0643159
# bad: [65b6657672388b72822e0367f06d41c1e3ffb5bb] clk: sunxi-ng: Use u64 for 
calculation of NM rate
git bisect bad 65b6657672388b72822e0367f06d41c1e3ffb5bb
# good: [db7548934603d9eda12649dff97ea5c29884405d] clk: sunxi-ng: sun50i: h6: 
Fix MMC clock mux width
git bisect good db7548934603d9eda12649dff97ea5c29884405d
# bad: [3f790433c3cb27ecaf2ca0e07ac25964e4fd9f15] clk: sunxi-ng: Adjust MP 
clock parent rate when allowed
git bisect bad 3f790433c3cb27ecaf2ca0e07ac25964e4fd9f15
# first bad commit: [3f790433c3cb27ecaf2ca0e07ac25964e4fd9f15] clk: sunxi-ng: 
Adjust MP clock parent rate when allowed


> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/clk/sunxi-ng/ccu_mp.c | 64 +--
>  1 file changed, 62 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
> index 5d0af4051737..0357349eb767 100644
> --- a/drivers/clk/sunxi-ng/ccu_mp.c
> +++ b/drivers/clk/sunxi-ng/ccu_mp.c
> @@ -40,6 +40,61 @@ static void ccu_mp_find_best(unsigned long parent, 
> unsigned long rate,
>   *p = best_p;
>  }
>  
> +static unsigned long ccu_mp_find_best_with_parent_adj(struct clk_hw *hw,
> +   unsigned long *parent,
> +   unsigned long rate,
> +   unsigned int max_m,
> +  

Re: [PATCH] drm/sun4i: hdmi: Improve compatibility with non-hotplug capable connectors

2018-12-06 Thread Priit Laes
On Tue, Nov 20, 2018 at 09:58:41AM +0100, Maxime Ripard wrote:
> On Mon, Nov 19, 2018 at 10:26:38AM +, Russell King - ARM Linux wrote:
> > On Mon, Nov 19, 2018 at 09:19:34AM +0100, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > On Fri, Nov 16, 2018 at 07:18:29PM +0200, Priit Laes wrote:
> > > > From: Priit Laes 
> > > > 
> > > > Even though HDMI connector features hotplug detect pin (HPD), there are
> > > > devices that which do not support it.
> > > 
> > > Which devices?
> > > 
> > > > For these devices fall back to additional check on I2C bus. Of
> > > > course, there might be also devices that do not wire DDC pins too,
> > > > so we don't really know whether cable has been connected.
> > > 
> > > Again, which devices?
> > > 
> > > > 
> > > > Signed-off-by: Priit Laes 
> > > > Signed-off-by: Priit Laes 
> > > 
> > > You only need one :)
> > > 
> > > > ---
> > > 
> > > You're doing basically two things in that patch, first adding the
> > > fallback to the DDC probe if the hotplug mechanism couldn't detect the
> > > display, and then returning a status unknown if both fail.
> > > 
> > > While I don't really have an opinion on the first one, it's mandatory
> > > for every HDMI device to be able to retrieve the EDID through the
> > > DDC. If a device was to disallow that, it would violate the HDMI, and
> > > I'm not sure we want to start supporting those devices.
> > 
> > There is also the problem that HDMI uses the HPD signal to indicate
> > that the source should re-read the EDID due to the EDID changing.
> > In HDMI, you don't necessarily have a fixed-for-all-time EDID, but
> > one which can change depending on what devices are in the HDMI path.
> > 
> > Consider, for example, an AV amplifier which needs to subsitute the
> > audio capabilities when it is turned on, but when in standby needs
> > to pass through the TVs audio capabilities.  It informs the source
> > by momentarily deasserting the HDMI HPD signal, which is the HDMI
> > way to inform the source that the EDID should be re-read.
> > 
> > If you're going to use "read EDID" as the hotplug method, I think
> > you need to keep track of when it changes so that EDID updates are
> > correctly handled.
> 
> I didn't think about that, thanks for bringing it up!

Well, currently this is broken anyway, becuse we are doing the polling
due to missing HPD interrupt. You can test by quickly switching between
two different monitors that both have proper HPD pin.

> 
> Maxime
> 
> -- 
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/sun4i: hdmi: Improve compatibility with non-hotplug capable connectors

2018-11-19 Thread Priit Laes
On Mon, Nov 19, 2018 at 09:19:34AM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Fri, Nov 16, 2018 at 07:18:29PM +0200, Priit Laes wrote:
> > From: Priit Laes 
> > 
> > Even though HDMI connector features hotplug detect pin (HPD), there are
> > devices that which do not support it.
> 
> Which devices?

Device I have here is labelled "AMATIC INDUSTRIES PT-MULTI-1" and
based on the TFP401APZP chip.

> 
> > For these devices fall back to additional check on I2C bus. Of
> > course, there might be also devices that do not wire DDC pins too,
> > so we don't really know whether cable has been connected.
> 
> Again, which devices?

OK, let's skip the part without DDC. I was probably thinking about
VGA cables when I was writing that..

> > 
> > Signed-off-by: Priit Laes 
> > Signed-off-by: Priit Laes 
> 
> You only need one :)
> 
> > ---
> >  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 12 
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
> > b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> > index 061d2e0d9011..bded09af1340 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> > @@ -238,14 +238,18 @@ sun4i_hdmi_connector_detect(struct drm_connector 
> > *connector, bool force)
> > struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
> > unsigned long reg;
> >  
> > -   if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
> > +   if (!readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
> >reg & SUN4I_HDMI_HPD_HIGH,
> >0, 50)) {
> > -   cec_phys_addr_invalidate(hdmi->cec_adap);
> > -   return connector_status_disconnected;
> > +   return connector_status_connected;
> > }
> >  
> > -   return connector_status_connected;
> > +   if (!IS_ERR(hdmi->i2c) && drm_probe_ddc(hdmi->i2c))
> > +   return connector_status_connected;
> > +
> > +   cec_phys_addr_invalidate(hdmi->cec_adap);
> > +
> > +   return connector_status_unknown;
> 
> You're doing basically two things in that patch, first adding the
> fallback to the DDC probe if the hotplug mechanism couldn't detect the
> display, and then returning a status unknown if both fail.

Agreed. 'connector_status_disconnected' is the way to go.

> While I don't really have an opinion on the first one, it's mandatory
> for every HDMI device to be able to retrieve the EDID through the
> DDC. If a device was to disallow that, it would violate the HDMI, and
> I'm not sure we want to start supporting those devices.

Yes, Even if someone runs into those non-spec devices, then there's
also possibility to use the force argument.

Thanks for review!

> 
> Maxime
> 
> -- 
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/sun4i: hdmi: Improve compatibility with non-hotplug capable connectors

2018-11-17 Thread Priit Laes
From: Priit Laes 

Even though HDMI connector features hotplug detect pin (HPD), there are
devices that which do not support it. For these devices fall back to
additional check on I2C bus. Of course, there might be also devices
that do not wire DDC pins too, so we don't really know whether cable
has been connected.

Signed-off-by: Priit Laes 
Signed-off-by: Priit Laes 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 061d2e0d9011..bded09af1340 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -238,14 +238,18 @@ sun4i_hdmi_connector_detect(struct drm_connector 
*connector, bool force)
struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
unsigned long reg;
 
-   if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
+   if (!readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
   reg & SUN4I_HDMI_HPD_HIGH,
   0, 50)) {
-   cec_phys_addr_invalidate(hdmi->cec_adap);
-   return connector_status_disconnected;
+   return connector_status_connected;
}
 
-   return connector_status_connected;
+   if (!IS_ERR(hdmi->i2c) && drm_probe_ddc(hdmi->i2c))
+   return connector_status_connected;
+
+   cec_phys_addr_invalidate(hdmi->cec_adap);
+
+   return connector_status_unknown;
 }
 
 static const struct drm_connector_funcs sun4i_hdmi_connector_funcs = {
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [linux-sunxi] [PATCH 01/10] drm/sun4i: sun6i_mipi_dsi: Compute burst mode loop N1 instruction delay

2018-11-04 Thread Priit Laes
On Sat, Nov 03, 2018 at 03:38:51PM +0530, Jagan Teki wrote:
> Loop N1 instruction delay for burst mode lcd panel are
> computed as per BSP code.
> 
> Reference code is available in BSP
> (in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
> dsi_dev[sel]->dsi_inst_loop_num.bits.loop_n1=
> (panel->lcd_ht-panel->lcd_x)*(150)/(panel->lcd_dclk_freq*8) - 50;
> => (((mode->htotal - mode->hdisplay) * 150) / ((mode->clock / 1000) * 8)) - 
> 50;
> 
> So use the similar computation for loop N1 delay.
> 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 86430efd9054..da152c21ec62 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -394,7 +394,14 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
>  static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi,
> struct drm_display_mode *mode)
>  {
> - u16 delay = 50 - 1;
> + struct mipi_dsi_device *device = dsi->device;
> + u16 delay;
> +
> + if (device->mode_flags == MIPI_DSI_MODE_VIDEO_BURST)

This looks fishy, as mode_flags is supposedly bitfield.

I guess you actually want mode_flags & MIPI_DSI_MODE_VIDEO_BURST. Other
patches are also affected by this.


> + delay = (((mode->htotal - mode->hdisplay) * 150) /
> + ((mode->clock / 1000) * 8)) - 50;
> + else
> + delay = 50 - 1;
>  
>   regmap_write(dsi->regs, SUN6I_DSI_INST_LOOP_NUM_REG(0),
>SUN6I_DSI_INST_LOOP_NUM_N0(50 - 1) |
> -- 
> 2.18.0.321.gffc6fa0e3
> 
> -- 
> 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: [linux-sunxi] [PATCH v3 20/25] drm/panel: Add Techstar TS8550B MIPI-DSI LCD panel

2018-10-29 Thread Priit Laes
On Sat, Oct 27, 2018 at 03:25:29PM +0530, Jagan Teki wrote:
> On Fri, Oct 26, 2018 at 9:43 PM Priit Laes  wrote:
> >
> > On Fri, Oct 26, 2018 at 08:13:39PM +0530, Jagan Teki wrote:
> > > Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI
> > > LCD panel. Add panel driver for it.
> > >
> > > Signed-off-by: Jagan Teki 
> > > Tested-by: Jagan Teki 
> > > ---
> > > Changes for v3:
> > > - new patch
> > > Changes for v2:
> > > - none
> > >
> > >  drivers/gpu/drm/panel/Kconfig |   9 +
> > >  drivers/gpu/drm/panel/Makefile|   1 +
> > >  .../gpu/drm/panel/panel-techstar-ts8550b.c| 346 ++
> > >  3 files changed, 356 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/panel/panel-techstar-ts8550b.c
> > >
> > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > > index 20b88c275421..d0d4e60f5153 100644
> > > --- a/drivers/gpu/drm/panel/Kconfig
> > > +++ b/drivers/gpu/drm/panel/Kconfig
> > > @@ -195,4 +195,13 @@ config DRM_PANEL_SITRONIX_ST7789V
> > > Say Y here if you want to enable support for the Sitronix
> > > ST7789V controller for 240x320 LCD panels
> > >
> > > +config DRM_PANEL_TECHSTAR_TS8550B
> > > + tristate "Techstar TS8550B MIPI-DSI panel driver"
> > > + depends on OF
> > > + depends on DRM_MIPI_DSI
> > > + depends on BACKLIGHT_CLASS_DEVICE
> > > + help
> > > +   Say Y if you want to enable support for panels based on the
> > > +   Techstar TS8550B MIPI-DSI interface.
> > > +
> > >  endmenu
> > > diff --git a/drivers/gpu/drm/panel/Makefile 
> > > b/drivers/gpu/drm/panel/Makefile
> > > index 04696bb85218..88011f06edb8 100644
> > > --- a/drivers/gpu/drm/panel/Makefile
> > > +++ b/drivers/gpu/drm/panel/Makefile
> > > @@ -20,3 +20,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += 
> > > panel-seiko-43wvf1g.o
> > >  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> > >  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> > >  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> > > +obj-$(CONFIG_DRM_PANEL_TECHSTAR_TS8550B) += panel-techstar-ts8550b.o
> > > diff --git a/drivers/gpu/drm/panel/panel-techstar-ts8550b.c 
> > > b/drivers/gpu/drm/panel/panel-techstar-ts8550b.c
> > > new file mode 100644
> > > index ..8baca71595a7
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/panel/panel-techstar-ts8550b.c
> > > @@ -0,0 +1,346 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (C) 2019, Amarula Solutions.
> > > + * Author: Jagan Teki 
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +
> > > +struct ts8550b {
> > > + struct drm_panelpanel;
> > > + struct mipi_dsi_device  *dsi;
> > > +
> > > + struct backlight_device *backlight;
> > > + struct regulator*dvdd;
> > > + struct regulator*avdd;
> > > + struct gpio_desc*reset;
> > > +
> > > + boolis_enabled;
> > > + boolis_prepared;
> > > +};
> > > +
> > > +static inline struct ts8550b *panel_to_ts8550b(struct drm_panel *panel)
> > > +{
> > > + return container_of(panel, struct ts8550b, panel);
> > > +}
> > > +
> > > +static inline int ts8550b_dcs_write_seq(struct ts8550b *ctx, const void 
> > > *seq,
> > > + size_t len)
> > > +{
> > > + return mipi_dsi_dcs_write_buffer(ctx->dsi, seq, len);
> > > +};
> > > +
> > > +#define ts8550b_dcs_write_seq_static(ctx, seq...)\
> > > + ({  \
> > > + static const u8 d[] = { seq };  \
> > > + ts8550b_dcs_write_seq(ctx, d, ARRAY_SIZE(d));   \
> > > +  

Re: [linux-sunxi] [PATCH v3 20/25] drm/panel: Add Techstar TS8550B MIPI-DSI LCD panel

2018-10-29 Thread Priit Laes
On Fri, Oct 26, 2018 at 08:13:39PM +0530, Jagan Teki wrote:
> Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI
> LCD panel. Add panel driver for it.
> 
> Signed-off-by: Jagan Teki 
> Tested-by: Jagan Teki 
> ---
> Changes for v3:
> - new patch
> Changes for v2:
> - none
> 
>  drivers/gpu/drm/panel/Kconfig |   9 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  .../gpu/drm/panel/panel-techstar-ts8550b.c| 346 ++
>  3 files changed, 356 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-techstar-ts8550b.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 20b88c275421..d0d4e60f5153 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -195,4 +195,13 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>  
> +config DRM_PANEL_TECHSTAR_TS8550B
> + tristate "Techstar TS8550B MIPI-DSI panel driver"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y if you want to enable support for panels based on the
> +   Techstar TS8550B MIPI-DSI interface.
> +
>  endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 04696bb85218..88011f06edb8 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -20,3 +20,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += 
> panel-seiko-43wvf1g.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
>  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TECHSTAR_TS8550B) += panel-techstar-ts8550b.o
> diff --git a/drivers/gpu/drm/panel/panel-techstar-ts8550b.c 
> b/drivers/gpu/drm/panel/panel-techstar-ts8550b.c
> new file mode 100644
> index ..8baca71595a7
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-techstar-ts8550b.c
> @@ -0,0 +1,346 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019, Amarula Solutions.
> + * Author: Jagan Teki 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct ts8550b {
> + struct drm_panelpanel;
> + struct mipi_dsi_device  *dsi;
> +
> + struct backlight_device *backlight;
> + struct regulator*dvdd;
> + struct regulator*avdd;
> + struct gpio_desc*reset;
> +
> + boolis_enabled;
> + boolis_prepared;
> +};
> +
> +static inline struct ts8550b *panel_to_ts8550b(struct drm_panel *panel)
> +{
> + return container_of(panel, struct ts8550b, panel);
> +}
> +
> +static inline int ts8550b_dcs_write_seq(struct ts8550b *ctx, const void *seq,
> + size_t len)
> +{
> + return mipi_dsi_dcs_write_buffer(ctx->dsi, seq, len);
> +};
> +
> +#define ts8550b_dcs_write_seq_static(ctx, seq...)\
> + ({  \
> + static const u8 d[] = { seq };  \
> + ts8550b_dcs_write_seq(ctx, d, ARRAY_SIZE(d));   \
> + })
> +
> +static void ts8550b_init_sequence(struct ts8550b *ctx)

This seems to be pretty "standard" MIPI-based display, utilizing
bunch of manufacturer-specific commands during init sequence.

Standard MIPI commands fall between 0x00..0xAF and are defined in 

> +{
> + ts8550b_dcs_write_seq_static(ctx, 0x01, 0x00);


MIPI_DCS_SOFT_RESET

> + msleep(200);
> + ts8550b_dcs_write_seq_static(ctx, 0xFF, 0x77, 0x01, 0x00, 0x00, 0x11);
> + ts8550b_dcs_write_seq_static(ctx, 0xD1, 0x11);
> + ts8550b_dcs_write_seq_static(ctx, 0x11, 0x00);

MIPI_DCS_EXIT_SLEEP_MODE

> + msleep(200);
> + ts8550b_dcs_write_seq_static(ctx, 0xFF, 0x77, 0x01, 0x00, 0x00, 0x10);
> + ts8550b_dcs_write_seq_static(ctx, 0xC0, 0xE9, 0x03);
> + ts8550b_dcs_write_seq_static(ctx, 0xC1, 0x12, 0x02);
> + ts8550b_dcs_write_seq_static(ctx, 0xC2, 0x07, 0x06);
> + ts8550b_dcs_write_seq_static(ctx, 0xB0, 0x00, 0x0E, 0x15, 0x0F, 0x11,
> +  0x08, 0x08, 0x08, 0x08, 0x23, 0x04, 0x13,
> +  0x12, 0x2B, 0x34, 0x1F);
> + ts8550b_dcs_write_seq_static(ctx, 0xB1, 0x00, 0x0E, 0x95, 0x0F, 0x13,
> +  0x07, 0x09, 0x08, 0x08, 0x22, 0x04, 0x10,
> +  0x0E, 0x2C, 0x34, 0x1F);
> + ts8550b_dcs_write_seq_static(ctx, 0xFF, 0x77, 0x01, 0x00, 0x00, 0x11);
> + ts8550b_dcs_write_seq_static(ctx, 0xB0, 0x45);
> + ts8550b_dcs_write_seq_static(ctx, 0xB1, 0x13);
> + ts8550b_dcs_write_seq_static(ctx, 0xB2, 

Re: [PATCH v4 00/15] drm/sun4i: Add A83t LVDS support

2017-12-14 Thread Priit Laes
On Thu, Dec 07, 2017 at 04:58:45PM +0100, Maxime Ripard wrote:
> Hi,
> 
> Here is an attempt at supporting the LVDS output in our DRM driver. This
> has been tested on the A83T (with DE2), but since everything is basically
> in the TCON, it should also be usable on the older SoCs with minor
> modifications.

I managed to get the single-channel LVDS working on an A10 tablet after
doing those minor modifications (although, the colours are off a bit).
So in general this series looks good :)

> 
> This was the occasion to refactor a bunch of things. The most notable ones
> would be the documentation, and split of the UI layers in the mixer code,
> and the switch to kfifo for our endpoint parsing code in the driver that
> fixes an issue introduced by the switch to BFS.
> 
> Let me know what you think,
> Maxime
> 
> Changes from v3:
>   - Collect the tags
>   - Use SPDX headers when possible
>   - Added the new mixer configuration options
>   - Changed the LVDS clock for lvds-alt instead of lvds-pll
>   - Removed the MIPI PLL from the A31s
>   - Changed the LVDS_ANA0 macros name to reflect the generation they were
> introduced in, and added a comment to mention the changes needed to
> support the older SoCs
> 
> Changes from v2:
>   - Move the module clock rate to the mixer structure
>   - Adjusted the simple-panel documentation for power-supply
>   - Changed the compatible for the first A83t mixer to mixer 0
>   - Rebased on top of current drm-misc
>   - Split out the A83t bindings in its separate patch
> 
> Changes from v1:
>   - Added a fix for the error path handling in the TCON
>   - Enable the TCON by default
>   - Removed the patch that changes the channels offset but kept most of the
> modifications as a cleanup
>   - Deal with the LVDS clock being able to have another PLL parent on some
> SoCs
>   - Renamed the TCON compatible to TCON-TV, following the convention used
> on newer SoCs
>   - Removed the hardcoded timings
>   - Moved LVDS enable quirks to a separate function
>   - Used clock indices define in the DT
>   - Removed the hardcoded clock rate in the DT and moved it to the driver
>   - Changed sun8i_mixer_planes to sun8i_mixer_ui_planes to be consistent
>   - Added the various tags collected
>   - Rebased on top of 4.15
> 
> Maxime Ripard (15):
>   dt-bindings: panel: lvds: Document power-supply property
>   drm/panel: lvds: Add support for the power-supply property
>   dt-bindings: display: sun4i-drm: Add LVDS properties
>   dt-bindings: display: sun4i-drm: Add A83T pipeline
>   drm/sun4i: Fix error path handling
>   drm/sun4i: Force the mixer rate at 150MHz
>   drm/sun4i: Create minimal multipliers and dividers
>   drm/sun4i: Add LVDS support
>   drm/sun4i: Add A83T support
>   ARM: dts: sun8i: a83t: Add display pipeline
>   ARM: dts: sun8i: a83t: Enable the PWM
>   ARM: dts: sun8i: a83t: Add LVDS pins group
>   ARM: dts: sun8i: a83t: Add the PWM pin group
>   ARM: dts: sun8i: a711: Reinstate the PMIC compatible
>   ARM: dts: sun8i: a711: Enable the LCD
> 
>  Documentation/devicetree/bindings/display/panel/panel-common.txt |   6 ++-
>  Documentation/devicetree/bindings/display/panel/panel-lvds.txt   |   1 +-
>  Documentation/devicetree/bindings/display/panel/simple-panel.txt |   2 +-
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt|  12 +++-
>  arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts|  62 
> ++-
>  arch/arm/boot/dts/sun8i-a83t.dtsi|  99 
> -
>  drivers/gpu/drm/panel/panel-lvds.c   |  23 
> +++-
>  drivers/gpu/drm/sun4i/Makefile   |   1 +-
>  drivers/gpu/drm/sun4i/sun4i_dotclock.c   |  10 ++-
>  drivers/gpu/drm/sun4i/sun4i_drv.c|   1 +-
>  drivers/gpu/drm/sun4i/sun4i_lvds.c   | 177 
> +++-
>  drivers/gpu/drm/sun4i/sun4i_lvds.h   |  18 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 251 
> +++-
>  drivers/gpu/drm/sun4i/sun4i_tcon.h   |  31 
> +-
>  drivers/gpu/drm/sun4i/sun8i_mixer.c  |  20 
> ++-
>  drivers/gpu/drm/sun4i/sun8i_mixer.h  |   3 +-
>  16 files changed, 710 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
> 
> base-commit: 3b71239181e5429702387666f1ac70a9e6856cce
> -- 
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 15/23] drm/sun4i: Add LVDS support

2017-10-24 Thread Priit Laes
On Tue, Oct 17, 2017 at 11:06:22AM +0200, Maxime Ripard wrote:
> The TCON supports the LVDS interface to output to a panel or a bridge.
> Let's add support for it.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/Makefile |   1 +-
>  drivers/gpu/drm/sun4i/sun4i_lvds.c | 183 -
>  drivers/gpu/drm/sun4i/sun4i_lvds.h |  18 +++-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 193 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.h |  25 -
>  5 files changed, 419 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
> 
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index cfba2c07519c..6fee15d016ef 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -10,6 +10,7 @@ sun4i-drm-hdmi-y+= sun4i_hdmi_tmds_clk.o
>  
>  sun4i-tcon-y += sun4i_tcon.o
>  sun4i-tcon-y += sun4i_rgb.o
> +sun4i-tcon-y += sun4i_lvds.o
>  sun4i-tcon-y += sun4i_dotclock.o
>  sun4i-tcon-y += sun4i_crtc.o

[...]

> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 3efa1ab045cd..6a20a467ee6d 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -31,10 +31,52 @@
>  #include "sun4i_crtc.h"
>  #include "sun4i_dotclock.h"
>  #include "sun4i_drv.h"
> +#include "sun4i_lvds.h"
>  #include "sun4i_rgb.h"
>  #include "sun4i_tcon.h"
>  #include "sunxi_engine.h"

[...]

>  static void sun4i_tcon_channel_set_status(struct sun4i_tcon *tcon, int 
> channel,
> bool enabled)
>  {
> @@ -69,9 +111,13 @@ void sun4i_tcon_set_status(struct sun4i_tcon *tcon,
>  const struct drm_encoder *encoder,
>  bool enabled)
>  {
> + bool is_lvds = false;
>   int channel;
>  
>   switch (encoder->encoder_type) {
> + case DRM_MODE_ENCODER_LVDS:
> + is_lvds = true;
> + /* Fallthrough */
>   case DRM_MODE_ENCODER_NONE:
>   channel = 0;
>   break;
> @@ -84,10 +130,47 @@ void sun4i_tcon_set_status(struct sun4i_tcon *tcon,
>   return;
>   }
>  
> + if (is_lvds && !enabled)
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_IF_REG,
> +SUN4I_TCON0_LVDS_IF_EN, 0);
> +
>   regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
>  SUN4I_TCON_GCTL_TCON_ENABLE,
>  enabled ? SUN4I_TCON_GCTL_TCON_ENABLE : 0);
>  
> + if (is_lvds && enabled) {
> + u8 val;
> +
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_IF_REG,
> +SUN4I_TCON0_LVDS_IF_EN,
> +SUN4I_TCON0_LVDS_IF_EN);
> +

OK, this part below seems to be quite A83T specific, as A10/A20
has different register bits.

For example ANA0 bits:

A10:
#define SUN4I_TCON0_LVDS_ANA0_EN_MB BIT(22)

But here it is:
#define SUN4I_TCON0_LVDS_ANA0_EN_MB BIT(31)


Also, the programming sequence for A10/A20 (from u-boot),
and my initial patchset. (I haven't yet had time to get output working
on top of your stuff).

1. Set ANA0 (0x220) 
2. Set ANA1 
3. Update ANA1

regmap_write(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
 SUN4I_TCON0_LVDS_ANA0_CK_EN |
 SUN4I_TCON0_LVDS_ANA0_REG_V |
 SUN4I_TCON0_LVDS_ANA0_REG_C |
 SUN4I_TCON0_LVDS_ANA0_EN_MB |
 SUN4I_TCON0_LVDS_ANA0_PD |
 SUN4I_TCON0_LVDS_ANA0_DCHS);

udelay(2000);

regmap_write(tcon->regs, SUN4I_TCON0_LVDS_ANA1_REG,
 SUN4I_TCON0_LVDS_ANA1_INIT);

udelay(1000);

regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA1_REG,
   SUN4I_TCON0_LVDS_ANA1_UPDATE,
   SUN4I_TCON0_LVDS_ANA1_UPDATE);


> + regmap_write(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
> +  SUN4I_TCON0_LVDS_ANA0_C(2) |
> +  SUN4I_TCON0_LVDS_ANA0_V(3) |
> +  SUN4I_TCON0_LVDS_ANA0_PD(2) |
> +  SUN4I_TCON0_LVDS_ANA0_EN_LDO);
> + udelay(2);
> +
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
> +SUN4I_TCON0_LVDS_ANA0_EN_MB,
> +SUN4I_TCON0_LVDS_ANA0_EN_MB);
> + udelay(2);
> +
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
> +SUN4I_TCON0_LVDS_ANA0_EN_DRVC,
> +SUN4I_TCON0_LVDS_ANA0_EN_DRVC);
> +
> + if (sun4i_tcon_get_pixel_depth(encoder) == 18)
> + val = 7;
> + else
> + val = 0xf;
> +
> +

Re: [PATCH 15/23] drm/sun4i: Add LVDS support

2017-10-23 Thread Priit Laes
On Tue, Oct 17, 2017 at 11:06:22AM +0200, Maxime Ripard wrote:
> The TCON supports the LVDS interface to output to a panel or a bridge.
> Let's add support for it.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/Makefile |   1 +-
>  drivers/gpu/drm/sun4i/sun4i_lvds.c | 183 -
>  drivers/gpu/drm/sun4i/sun4i_lvds.h |  18 +++-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 193 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.h |  25 -
>  5 files changed, 419 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
> 

[...]

> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 3efa1ab045cd..6a20a467ee6d 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c

[...]
> @@ -698,6 +858,26 @@ static int sun4i_tcon_bind(struct device *dev, struct 
> device *master,
>   return ret;
>   }
>  
> + /*
> +  * This can only be made optional since we've had DT nodes
> +  * without the LVDS reset properties.
> +  *
> +  * If the property is missing, just disable LVDS, and print a
> +  * warning.
> +  */
> + tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
> + if (IS_ERR(tcon->lvds_rst)) {
> + dev_err(dev, "Couldn't get our reset line\n");
> + return PTR_ERR(tcon->lvds_rst);
> + } else if (tcon->lvds_rst) {
> + has_lvds = true;
> + reset_control_reset(tcon->lvds_rst);
> + } else {
> + has_lvds = false;
> + dev_warn(dev,
> +  "Missing LVDS reset property, you should consider 
> upgrading your DT\n");

This will generate annoying warning for tcon1 on A10/A20.

> + }
> +
>   ret = sun4i_tcon_init_clocks(dev, tcon);
>   if (ret) {
>   dev_err(dev, "Couldn't init our TCON clocks\n");
> @@ -729,7 +909,18 @@ static int sun4i_tcon_bind(struct device *dev, struct 
> device *master,
>   goto err_free_clocks;
>   }
>  
> - ret = sun4i_rgb_init(drm, tcon);
> + /*
> +  * If we have an LVDS panel connected to the TCON, we should
> +  * just probe the LVDS connector. Otherwise, just probe RGB as
> +  * we used to.
> +  */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [linux-sunxi] Re: [PATCH 2/8] ARM: sun4i: Add display blocks for the sun4i dtsi.

2017-02-13 Thread Priit Laes
On Mon, 2017-02-13 at 17:20 +0800, Chen-Yu Tsai wrote:
> On Mon, Feb 13, 2017 at 5:16 PM, Maxime Ripard
> <maxime.rip...@free-electrons.com> wrote:
> > Hi,
> > 
> > On Sat, Feb 11, 2017 at 07:43:59PM +0200, Priit Laes wrote:
> > > Added basic display pipeline consisting of tcon, display backend
> > > and
> > > frontend blocks.
> > > 
> > > Signed-off-by: Priit Laes <pl...@plaes.org>
> > > ---
> > >  arch/arm/boot/dts/sun4i-a10.dtsi | 104
> > > +++
> > >  1 file changed, 104 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi
> > > b/arch/arm/boot/dts/sun4i-a10.dtsi
> > > index ba20b48..70991c9 100644
> > > --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> > > +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> > > @@ -779,6 +779,45 @@
> > >   #size-cells = <0>;
> > >   };
> > > 
> > > + tcon0: lcd-controller@1c0c000 {
> > > + compatible = "allwinner,sun5i-a13-tcon";
> > 
> > There's a few bits here and there that need to be setup differently
> > in
> > A10, so you cannot reuse that compatible (same thing for the
> > other).
> > 
> > Also, I'd really like to have all the blocks listed here, and not
> > only
> > the first pipeline. Ideally, on the A10, the two pipelines should
> > be
> > enabled too.
> 
> The display pipeline driver has to be fixed before that can happen
> though. And I haven't started to work on what I proposed yet. Though
> if someone wants to take over I can forward any design plans I have.

Well, my plan was to get at least minimum bits mainlined and then build
additional features on top.

Wens, it would be cool though, if you could share your plans.

Unfortunately I have only single A10 device (with LVDS and mini-HDMI)
but I don't actually have other LVDS-displays I could easily use with
A20 devices (I have CubieTruck and A20-Olinuxino Micro).

Päikest,
Priit :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/8] ARM: sun4i: Add display blocks for the sun4i dtsi.

2017-02-12 Thread Priit Laes
Added basic display pipeline consisting of tcon, display backend and
frontend blocks.

Signed-off-by: Priit Laes <pl...@plaes.org>
---
 arch/arm/boot/dts/sun4i-a10.dtsi | 104 +++
 1 file changed, 104 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index ba20b48..70991c9 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -779,6 +779,45 @@
#size-cells = <0>;
};
 
+   tcon0: lcd-controller@1c0c000 {
+   compatible = "allwinner,sun5i-a13-tcon";
+   reg = <0x01c0c000 0x1000>;
+   interrupts = <44>;
+   resets = <_ch0_clk 1>;
+   reset-names = "lcd";
+   clocks = <_gates 36>,
+<_ch0_clk>,
+<_ch1_clk>;
+   clock-names = "ahb",
+ "tcon-ch0",
+ "tcon-ch1";
+   clock-output-names = "tcon-pixel-clock";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tcon0_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   tcon0_in_be0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_out_tcon0>;
+   };
+   };
+
+   tcon0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+   };
+
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun4i-a10-mmc";
reg = <0x01c0f000 0x1000>;
@@ -1328,5 +1367,70 @@
clocks = <_gates 7>;
status = "disabled";
};
+
+   fe0: display-frontend@1e0 {
+   compatible = "allwinner,sun5i-a13-display-frontend";
+   reg = <0x01e0 0x2>;
+   interrupts = <47>;
+   clocks = <_gates 46>, <_fe0_clk>,
+<_gates 25>;
+   clock-names = "ahb", "mod",
+ "ram";
+   resets = <_fe0_clk>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   fe0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   fe0_out_be0: endpoint {
+   remote-endpoint = <_in_fe0>;
+   };
+   };
+   };
+   };
+
+   be0: display-backend@1e6 {
+   compatible = "allwinner,sun5i-a13-display-backend";
+   reg = <0x01e6 0x1>;
+   clocks = <_gates 44>, <_be0_clk>,
+<_gates 26>;
+   clock-names = "ahb", "mod",
+ "ram";
+   resets = <_be0_clk>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   be0_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   be0_in_fe0: endpoint@0 {
+   reg =

[PATCH 5/8] drm/sun4i: Add encoder type argument to sun4i_tcon0_mode_set

2017-02-12 Thread Priit Laes
Depending on the output type, we have to enable/disable some
bits conditionally.

Signed-off-by: Priit Laes <pl...@plaes.org>
---
 drivers/gpu/drm/sun4i/sun4i_rgb.c  | 2 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 ++-
 drivers/gpu/drm/sun4i/sun4i_tcon.h | 3 ++-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index f5e86fe..3d4eb05 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -179,7 +179,7 @@ static void sun4i_rgb_encoder_mode_set(struct drm_encoder 
*encoder,
struct sun4i_drv *drv = rgb->drv;
struct sun4i_tcon *tcon = drv->tcon;
 
-   sun4i_tcon0_mode_set(tcon, mode);
+   sun4i_tcon0_mode_set(tcon, mode, DRM_MODE_ENCODER_DAC);
 
clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index ea2906f..71d0087 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -124,7 +124,8 @@ static int sun4i_tcon_get_clk_delay(struct drm_display_mode 
*mode,
 }
 
 void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
- struct drm_display_mode *mode)
+ struct drm_display_mode *mode,
+ int type)
 {
unsigned int bp, hsync, vsync;
u8 clk_delay;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 166064b..b040e10 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -188,7 +188,8 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, bool 
enable);
 void sun4i_tcon_switch_interlace(struct sun4i_tcon *tcon,
 bool enable);
 void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
- struct drm_display_mode *mode);
+ struct drm_display_mode *mode,
+ int type);
 void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
  struct drm_display_mode *mode);
 
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 7/8] drm/sun4i: Add various bits and pieces to enable LVDS support on sun4i

2017-02-12 Thread Priit Laes
TODO: We still rely on u-boot for lvds reset bit setup :(

Signed-off-by: Priit Laes <pl...@plaes.org>
---
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 29 
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 54 --
 drivers/gpu/drm/sun4i/sun4i_tcon.h | 15 +++
 3 files changed, 90 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index 2ba4705..de738e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -114,6 +114,35 @@ static void sun4i_lvds_encoder_enable(struct drm_encoder 
*encoder)
/* encoder->bridge can be NULL; drm_bridge_enable checks for it */
drm_bridge_enable(encoder->bridge);
 
+   /* Enable the LVDS */
+   regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_IF_REG,
+  SUN4I_TCON0_LVDS_IF_ENABLE,
+  SUN4I_TCON0_LVDS_IF_ENABLE);
+
+   /*
+* TODO: SUN4I_TCON0_LVDS_ANA0_REG_C and SUN4I_TCON0_LVDS_ANA0_PD
+* registers span 3 bits, but we only set upper 2 for both
+* of them based on values taken from Allwinner driver.
+*/
+   regmap_write(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
+SUN4I_TCON0_LVDS_ANA0_CK_EN |
+SUN4I_TCON0_LVDS_ANA0_REG_V |
+SUN4I_TCON0_LVDS_ANA0_REG_C |
+SUN4I_TCON0_LVDS_ANA0_EN_MB |
+SUN4I_TCON0_LVDS_ANA0_PD |
+SUN4I_TCON0_LVDS_ANA0_DCHS);
+
+   udelay(2000);
+
+   regmap_write(tcon->regs, SUN4I_TCON0_LVDS_ANA1_REG,
+SUN4I_TCON0_LVDS_ANA1_INIT);
+
+   udelay(1000);
+
+   regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA1_REG,
+  SUN4I_TCON0_LVDS_ANA1_UPDATE,
+  SUN4I_TCON0_LVDS_ANA1_UPDATE);
+
sun4i_tcon_channel_enable(tcon, 0);
 }
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 71d0087..468a3ce 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -18,6 +18,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,7 @@
 #include "sun4i_crtc.h"
 #include "sun4i_dotclock.h"
 #include "sun4i_drv.h"
+#include "sun4i_lvds.h"
 #include "sun4i_rgb.h"
 #include "sun4i_tcon.h"
 
@@ -169,12 +171,29 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
 SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
 
/* Set Hsync and Vsync length */
-   hsync = mode->crtc_hsync_end - mode->crtc_hsync_start;
-   vsync = mode->crtc_vsync_end - mode->crtc_vsync_start;
-   DRM_DEBUG_DRIVER("Setting HSYNC %d, VSYNC %d\n", hsync, vsync);
-   regmap_write(tcon->regs, SUN4I_TCON0_BASIC3_REG,
-SUN4I_TCON0_BASIC3_V_SYNC(vsync) |
-SUN4I_TCON0_BASIC3_H_SYNC(hsync));
+   if (type != DRM_MODE_ENCODER_LVDS) {
+   // Not needed for LVDS?
+   hsync = mode->crtc_hsync_end - mode->crtc_hsync_start;
+   vsync = mode->crtc_vsync_end - mode->crtc_vsync_start;
+   DRM_DEBUG_DRIVER("Setting HSYNC %d, VSYNC %d\n", hsync, vsync);
+   regmap_write(tcon->regs, SUN4I_TCON0_BASIC3_REG,
+SUN4I_TCON0_BASIC3_V_SYNC(vsync) |
+SUN4I_TCON0_BASIC3_H_SYNC(hsync));
+   }
+
+   if (type == DRM_MODE_ENCODER_LVDS) {
+   /* Setup bit depth */
+   /* TODO: Figure out where to get display bit depth
+* val = (1: 18-bit, 0: 24-bit)
+* TODO: Should we set more registers:
+* BIT(28) - LVDS_DIRECTION
+* BIT(27) - LVDS_MODE
+* BIT(23) - LVDS_CORRECT_MODE
+*/
+   regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_IF_REG,
+  SUN4I_TCON0_LVDS_IF_BITWIDTH,
+  SUN4I_TCON0_LVDS_IF_BITWIDTH);
+   }
 
/* Setup the polarity of the various signals */
if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
@@ -183,8 +202,15 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
 
+
+   /* Set proper DCLK phase value */
+   if (type == DRM_MODE_ENCODER_LVDS)
+   val |= SUN4I_TCON0_IO_POL_DCLK_PHASE(1);
+
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
-  SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | 
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
+  SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
+  SUN4I_TCON0_IO_POL_VSYNC_POSITIVE |
+  SUN4I_TCON0_I

[PATCH 1/8] ARM: sunxi_defconfig: Enable simple panel

2017-02-12 Thread Priit Laes
From: Jonathan Liu 

Signed-off-by: Jonathan Liu 
---
 arch/arm/configs/sunxi_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index da92c25..7abe6a4 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -153,3 +153,7 @@ CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
 CONFIG_DEBUG_FS=y
 CONFIG_CRYPTO_DEV_SUN4I_SS=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_BACKLIGHT_PWM=y
+CONFIG_DRM_PANEL_SIMPLE=y
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 8/8] ARM: dts: sun4i: gemei-g9: Add LVDS display support

2017-02-12 Thread Priit Laes
Signed-off-by: Priit Laes <pl...@plaes.org>
---
 arch/arm/boot/dts/sun4i-a10-gemei-g9.dts | 95 +---
 1 file changed, 86 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts 
b/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
index 9616cde..c19f906 100644
--- a/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
+++ b/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
@@ -1,5 +1,5 @@
 /*
- * Copyright 2015 Priit Laes
+ * Copyright 2015-2017 Priit Laes
  *
  * Priit Laes <pl...@plaes.org>
  *
@@ -48,28 +48,69 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "Gemei G9 Tablet";
compatible = "gemei,g9", "allwinner,sun4i-a10";
 
+   /*
+* TODO:
+*   2x cameras via CSI
+*   AXP battery management
+*   NAND
+*   OTG
+*   Touchscreen - gt801_2plus1 @ i2c adapter 2 @ 0x48
+*   HDMI output
+*/
+
aliases {
serial0 = 
};
 
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <_backlight_pin>;
+   /* TODO: Figure out proper parameters */
+   pwms = < 0 5 PWM_POLARITY_INVERTED>;
+   brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+   enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+   default-brightness-level = <8>;
+   };
+
chosen {
stdout-path = "serial0:115200n8";
};
+
+   panel: panel {
+   compatible = "lg,lp097x02-slq2";
+   pinctrl-names = "default";
+   pinctrl-0 = <_enable_pin _lvds0_pins>;
+   enable-gpios = < 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   panel_input: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+   };
+
+   display-engine {
+   compatible = "allwinner,sun5i-a13-display-engine";
+   allwinner,pipelines = <>;
+   };
+};
+
+ {
+   status = "okay";
 };
 
-/*
- * TODO:
- *   2x cameras via CSI
- *   AXP battery management
- *   NAND
- *   OTG
- *   Touchscreen - gt801_2plus1 @ i2c adapter 2 @ 0x48
- */
  {
/* PH15 controls power to external amplifier (ft2012q) */
pinctrl-names = "default";
@@ -90,6 +131,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
@@ -159,6 +204,27 @@
pins = "PH15";
function = "gpio_out";
};
+
+   lcd_backlight_pin: lcd_backlight_pin@0 {
+   pins = "PH7";
+   function = "gpio_out";
+   };
+
+   lcd_enable_pin: lcd_enable_pin@0 {
+   pins = "PH8";
+   function = "gpio_out";
+   };
+
+   lcd_lvds0_pins: lcd_lvds0_pins@0 {
+   pins =  "PD0", "PD1", "PD2", "PD3", "PD4", "PD5", "PD6", "PD7", 
"PD8", "PD9";
+   function = "lvds0";
+   };
+};
+
+ {
+pinctrl-names = "default";
+pinctrl-0 = <_pins_a>;
+status = "okay";
 };
 
 _dcdc2 {
@@ -194,6 +260,17 @@
status = "okay";
 };
 
+ {
+   mode = "lvds";
+   status = "okay";
+};
+
+_out {
+   tcon0_out_panel: endpoint@1 {
+   reg = <0>;
+   remote-endpoint = <_input>;
+   };
+};
 
   {
pinctrl-names = "default";
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/8] drm/panel: simple: Add support for LG LP097x02-slq2 panel

2017-02-12 Thread Priit Laes
Add simple-panel support for the LG LP097x02-slq2, which is 10"
1024x768 LVDS panel.

Signed-off-by: Priit Laes <pl...@plaes.org>
---
 drivers/gpu/drm/panel/panel-simple.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..2948fed 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1205,6 +1205,28 @@ static const struct panel_desc lg_lp097qx1_spa1 = {
},
 };
 
+static const struct drm_display_mode lg_lp097x02_slq2_mode = {
+.clock = 10,
+.hdisplay = 1024,
+.hsync_start = 1024 + 260,
+.hsync_end = 1024 + 260 + 1,
+.htotal = 1024 + 260 + 1 + 799,
+.vdisplay = 768,
+.vsync_start = 768 + 16,
+.vsync_end = 768 + 16 + 1,
+.vtotal = 768 + 16 + 1 + 15,
+.vrefresh = 60,
+};
+
+static const struct panel_desc lg_lp097x02_slq2 = {
+.modes = _lp097x02_slq2_mode,
+.num_modes = 1,
+.size = {
+.width = 197,
+.height = 147,
+},
+};
+
 static const struct drm_display_mode lg_lp120up1_mode = {
.clock = 162300,
.hdisplay = 1920,
@@ -1817,6 +1839,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "lg,lp097qx1-spa1",
.data = _lp097qx1_spa1,
}, {
+   .compatible = "lg,lp097x02-slq2",
+   .data = _lp097x02_slq2,
+   }, {
.compatible = "lg,lp120up1",
.data = _lp120up1,
}, {
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 6/8] drm/sun4i: Add initial LVDS stub

2017-02-12 Thread Priit Laes
Signed-off-by: Priit Laes <pl...@plaes.org>
---
 drivers/gpu/drm/sun4i/Makefile |   1 +
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 247 +
 drivers/gpu/drm/sun4i/sun4i_lvds.h |  15 +++
 3 files changed, 263 insertions(+)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h

diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index d625a82..5dfbe16 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_DRM_SUN4I)   += sun4i-drm.o 
sun4i-tcon.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_backend.o
 obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
+obj-$(CONFIG_DRM_SUN4I)+= sun4i_lvds.o
diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
new file mode 100644
index 000..2ba4705
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -0,0 +1,247 @@
+/*
+ * Copyright (C) 2016 Priit Laes
+ *
+ * Priit Laes <pl...@plaes.org>
+ *
+ * Based on sun4i_rgb.c by Maxime Ripard <maxime.rip...@free-electrons.com>
+ *
+ * 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 
+#include 
+
+#include "sun4i_drv.h"
+#include "sun4i_tcon.h"
+
+struct sun4i_lvds {
+   struct drm_connectorconnector;
+   struct drm_encoder  encoder;
+
+   struct sun4i_drv*drv;
+};
+
+static inline struct sun4i_lvds *
+drm_connector_to_sun4i_lvds(struct drm_connector *connector)
+{
+   return container_of(connector, struct sun4i_lvds,
+   connector);
+}
+
+static inline struct sun4i_lvds *
+drm_encoder_to_sun4i_lvds(struct drm_encoder *encoder)
+{
+   return container_of(encoder, struct sun4i_lvds,
+   encoder);
+}
+
+static int sun4i_lvds_get_modes(struct drm_connector *connector)
+{
+   struct sun4i_lvds *lvds =
+   drm_connector_to_sun4i_lvds(connector);
+   struct sun4i_drv *drv = lvds->drv;
+   struct sun4i_tcon *tcon = drv->tcon;
+
+   return drm_panel_get_modes(tcon->panel);
+}
+
+static int sun4i_lvds_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
+{
+   DRM_DEBUG_DRIVER("LVDS mode valid!\n");
+   return MODE_OK;
+}
+
+static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
+   .get_modes  = sun4i_lvds_get_modes,
+   .mode_valid = sun4i_lvds_mode_valid,
+};
+
+static enum drm_connector_status
+sun4i_lvds_connector_detect(struct drm_connector *connector, bool force)
+{
+   return connector_status_connected;
+}
+
+static void
+sun4i_lvds_connector_destroy(struct drm_connector *connector)
+{
+   struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
+   struct sun4i_drv *drv = lvds->drv;
+   struct sun4i_tcon *tcon = drv->tcon;
+
+   drm_panel_detach(tcon->panel);
+   drm_connector_cleanup(connector);
+}
+
+static struct drm_connector_funcs sun4i_lvds_con_funcs = {
+   .dpms   = drm_atomic_helper_connector_dpms,
+   .detect = sun4i_lvds_connector_detect,
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .destroy= sun4i_lvds_connector_destroy,
+   .reset  = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
+};
+
+static int sun4i_lvds_atomic_check(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+   return 0;
+}
+
+static void sun4i_lvds_encoder_enable(struct drm_encoder *encoder)
+{
+   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
+   struct sun4i_drv *drv = lvds->drv;
+   struct sun4i_tcon *tcon = drv->tcon;
+
+   DRM_DEBUG_DRIVER("Enabling LVDS output\n");
+
+   if (!IS_ERR(tcon->panel)) {
+   drm_panel_prepare(tcon->panel);
+   drm_panel_enable(tcon->panel);
+   }
+
+   /* encoder->bridge can be NULL; drm_bridge_enable checks for it */
+   drm_bridge_enable(encoder->bridge);
+
+   sun4i_tcon_channel_enable(tcon, 0);
+}
+
+static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder)
+{
+   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
+   struct sun4i_drv *drv = lvds->d

[PATCH 0/8] drm/sun4i: Add basic LVDS support for A10

2017-02-12 Thread Priit Laes
This series adds initial LVDS functionality for A10 SoC and includes
display blocks (TCON, backend and frontend) for A10 dtsi and implements 
of mode property for TCON to allow switching between rgb/lvds output.

This series has been tested on Gemei G9 A10 tablet, but still relies
on u-boot to properly set up LVDS reset controller.

---

Jonathan Liu (1):
  ARM: sunxi_defconfig: Enable simple panel

Priit Laes (7):
  ARM: sun4i: Add display blocks for the sun4i dtsi.
  drm/panel: simple: Add support for LG LP097x02-slq2 panel
  drm/sun4i: Add optional 'mode' property to TCON
  drm/sun4i: Add encoder type argument to sun4i_tcon0_mode_set
  drm/sun4i: Add initial LVDS stub
  drm/sun4i: Add various bits and pieces to enable LVDS support on sun4i
  ARM: dts: sun4i: gemei-g9: Add LVDS display support

 .../bindings/display/sunxi/sun4i-drm.txt   |   3 +
 arch/arm/boot/dts/sun4i-a10-gemei-g9.dts   |  95 ++-
 arch/arm/boot/dts/sun4i-a10.dtsi   | 104 
 arch/arm/configs/sunxi_defconfig   |   4 +
 drivers/gpu/drm/panel/panel-simple.c   |  25 ++
 drivers/gpu/drm/sun4i/Makefile |   1 +
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 276 +
 drivers/gpu/drm/sun4i/sun4i_lvds.h |  15 ++
 drivers/gpu/drm/sun4i/sun4i_rgb.c  |   2 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  57 -
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  18 +-
 11 files changed, 580 insertions(+), 20 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h

-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 4/8] drm/sun4i: Add optional 'mode' property to TCON

2017-02-12 Thread Priit Laes
Add variable to enable either 'rgb' or 'lvds' output.

Signed-off-by: Priit Laes <pl...@plaes.org>
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index b82c004..c367ede 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -43,6 +43,9 @@ Required properties:
  - reset-names: the reset names mentioned above
  - clock-output-names: Name of the pixel clock created
 
+- mode: Defines which encoder will be enabled. Values are 'rgb', 'lvds'.
+  Defaults to 'rgb' if not set.
+
 - ports: A ports node with endpoint definitions as defined in
   Documentation/devicetree/bindings/media/video-interfaces.txt. The
   first port should be the input endpoint, the second one the output
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[linux-sunxi] Re: [PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver

2016-05-12 Thread Priit Laes
On Wed, 2016-05-11 at 15:15 -0700, Stephen Boyd wrote:
> On 05/10, Priit Laes wrote:
> > 
> > On Mon, 2016-05-09 at 15:39 -0700, Stephen Boyd wrote:
> > > 
> > > On 05/09, Stephen Boyd wrote:
> > > > 
> > > > 
> > > > 
> > > > Ok I applied this one to clk-next.
> > > > 
> > > And I squashed this in to silence the following checker warning.
> > > 
> > > drivers/clk/sunxi/clk-sun4i-display.c:110:33: warning: Variable
> > > length array is used.
> > > 
> > > ---8<---
> > > diff --git a/drivers/clk/sunxi/clk-sun4i-display.c
> > > b/drivers/clk/sunxi/clk-sun4i-display.c
> > > index f02e250e64ed..f8ff6c4a5633 100644
> > > --- a/drivers/clk/sunxi/clk-sun4i-display.c
> > > +++ b/drivers/clk/sunxi/clk-sun4i-display.c
> > > @@ -107,7 +107,7 @@ static int
> > > sun4i_a10_display_reset_xlate(struct
> > > reset_controller_dev *rcdev,
> > >  static void __init sun4i_a10_display_init(struct device_node
> > > *node,
> > >    const struct
> > > sun4i_a10_display_clk_data *data)
> > >  {
> > > - const char *parents[data->parents];
> > > + const char *parents[4];
> > This change breaks at least de_[bf]e clocks which have 3 clock
> > parents.

> I just used the largest data->parents number, which was 4. How
> does that break anything?

If you look at the sun4i_a10_display_init, it contains this block:

    ret = of_clk_parent_fill(node, parents, ARRAY_SIZE(parents));
    if (ret != ARRAY_SIZE(parents)) {
        pr_err("%s: Could not retrieve the parents\n", clk_name);
        goto unmap;
    }

of_clk_parent_fill returns 3 for de_be/de_fe nodes, and
ARRAY_SIZE(parents) is 4.

Päikest,
Priit :)


[linux-sunxi] Re: [PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver

2016-05-10 Thread Priit Laes
On Mon, 2016-05-09 at 15:39 -0700, Stephen Boyd wrote:
> On 05/09, Stephen Boyd wrote:
> > 
> > 
> > Ok I applied this one to clk-next.
> > 
> And I squashed this in to silence the following checker warning.
> 
> drivers/clk/sunxi/clk-sun4i-display.c:110:33: warning: Variable
> length array is used.
> 
> ---8<---
> diff --git a/drivers/clk/sunxi/clk-sun4i-display.c
> b/drivers/clk/sunxi/clk-sun4i-display.c
> index f02e250e64ed..f8ff6c4a5633 100644
> --- a/drivers/clk/sunxi/clk-sun4i-display.c
> +++ b/drivers/clk/sunxi/clk-sun4i-display.c
> @@ -107,7 +107,7 @@ static int sun4i_a10_display_reset_xlate(struct
> reset_controller_dev *rcdev,
>  static void __init sun4i_a10_display_init(struct device_node *node,
>    const struct
> sun4i_a10_display_clk_data *data)
>  {
> - const char *parents[data->parents];
> + const char *parents[4];
>  const char *clk_name = node->name;
>  struct reset_data *reset_data;
>  struct clk_divider *div = NULL;
> @@ -126,8 +126,8 @@ static void __init sun4i_a10_display_init(struct
> device_node *node,
>  return;
>  }
>  
> - ret = of_clk_parent_fill(node, parents, data->parents);
> - if (ret != data->parents) {
> + ret = of_clk_parent_fill(node, parents,
> ARRAY_SIZE(parents));
> + if (ret != ARRAY_SIZE(parents)) {
>  pr_err("%s: Could not retrieve the parents\n",
> clk_name);
>  goto unmap;
>  }

This change breaks at least de_[bf]e clocks which have 3 clock parents.



[linux-sunxi] [PATCH v2 00/26] drm: Add Allwinner A10 display engine support

2016-02-20 Thread Priit Laes
On Thu, 2016-01-14 at 16:24 +0100, Maxime Ripard wrote:
> Hi everyone,
> 
> The Allwinner SoCs (except for the very latest ones) all share the
> same set of controllers, loosely coupled together to form the display
> pipeline.
> 
> Depending on the SoC, the number of instances of the controller will
> change (2 instances of each in the A10, only one in the A13, for
> example), and the output availables will change too (HDMI, composite,
> VGA on the A20, none of them on the A13).
> 
> On most featured SoCs, it looks like that:
> 
>  ++
>  |                    RAM                
>      |
>  ++
>        |            |      |            |
>        v            |      |            v
>  ++ |      | ++
>  |    Frontend    | |      | |    Frontend    |
>  ++ |      | ++
>          |          |      |         |
>          v          |      |         v
>  ++ |      | ++
>  |    Backend     |<+      +>|    Backend     |
>  ++          ++
>          |                           |
>          v                           v
>  ++          ++---> LVDS
>  |      TCON      |          |      TCON    
>   |---> RGB
>  ++          ++
>        |       +---+       +---+          |
>        |           |       |            
>   |
>        v           v       v            
>   v
>  ++  ++  ++---> VGA
>  | TV Encoder |  |    HDMI    |  | TV Encoder |---> Composite
>  ++  ++  ++
> 
> The current code only assumes that there is a single instance of all
> the controllers. It also supports only the RGB and Composite
> interfaces.

I found some time to play with it (with intention to get it running
also on sun7i and sun4i) and ran into this when trying to build
sun4i_drm as module:

ERROR: "sun4i_tcon1_mode_set" [drivers/gpu/drm/sun4i/sun4i_tv.ko] undefined!
ERROR: "sun4i_backend_apply_color_correction" 
[drivers/gpu/drm/sun4i/sun4i_tv.ko] undefined!
ERROR: "sun4i_tcon_channel_disable" [drivers/gpu/drm/sun4i/sun4i_tv.ko] 
undefined!
ERROR: "sun4i_tcon_channel_enable" [drivers/gpu/drm/sun4i/sun4i_tv.ko] 
undefined!
ERROR: "clk_unregister_composite" [drivers/gpu/drm/sun4i/sun4i_tcon.ko] 
undefined!
ERROR: "sun4i_rgb_init" [drivers/gpu/drm/sun4i/sun4i_tcon.ko] undefined!
ERROR: "clk_register_composite" [drivers/gpu/drm/sun4i/sun4i_tcon.ko] undefined!
ERROR: "sun4i_backend_update_layer_coord" [drivers/gpu/drm/sun4i/sun4i-drm.ko] 
undefined!
ERROR: "sun4i_backend_update_layer_formats" 
[drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_tcon_channel_disable" [drivers/gpu/drm/sun4i/sun4i-drm.ko] 
undefined!
ERROR: "sun4i_tcon_enable_vblank" [drivers/gpu/drm/sun4i/sun4i-drm.ko] 
undefined!
ERROR: "sun4i_backend_update_layer_buffer" [drivers/gpu/drm/sun4i/sun4i-drm.ko] 
undefined!
ERROR: "sun4i_backend_layer_enable" [drivers/gpu/drm/sun4i/sun4i-drm.ko] 
undefined!
ERROR: "sun4i_tcon_channel_enable" [drivers/gpu/drm/sun4i/sun4i-drm.ko] 
undefined!
ERROR: "sun4i_tcon_enable" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_tcon_disable" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_tcon0_mode_set" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_backend_commit" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed



> 
> Let me know what you think,
> Maxime
> 
> Changes from v1:
>   - Rebased on top of 4.4
> 
>   - Merged the clock drivers for the display and TCON channel 0
> clocks
>   - Replaced the container_of calls in the display reset clocks to an
>     inline function
>   - Checked the return code of of_clk_parent_fill in the clocks
>     drivers
>   - Checked the return code of of_clk_add_provider in the tcon-ch1
> and
>     PLL3 clocks
>   - Added missing clocks headers
>   - Created a composite clock unregister function
> 
>   - Moved the binding documentation to
>     Documentation/devicetree/bindings/display
>   - Added the clocks binding documentation
>   - Added the Olimex vendor to the list of DT vendors
>   - Moved to the OF graph representation and the component framework
> 
>   - Moved the reset cells count check into the reset 

[linux-sunxi] [PATCH v2 16/26] drm: Add Allwinner A10 Display Engine support

2016-01-17 Thread Priit Laes
On Sat, 2016-01-16 at 17:11 +0200, Priit Laes wrote:
> On Thu, 2016-01-14 at 16:24 +0100, Maxime Ripard wrote:
> > The Allwinner A10 and subsequent SoCs share the same display
> > pipeline, with
> > variations in the number of controllers (1 or 2), or the presence
> > or not of
> > some output (HDMI, TV, VGA) or not.
[...]
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> > b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> > new file mode 100644
> > index ..68072b8cddab
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> > @@ -0,0 +1,54 @@
> > +/*
> > + * 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 "sun4i_drv.h"
> > +
> > +static void sun4i_de_output_poll_changed(struct drm_device *drm)
> > +{
> > +   struct sun4i_drv *drv = drm->dev_private;
> > +
> > +   if (drv->fbdev)
> > +   drm_fbdev_cma_hotplug_event(drv->fbdev);
> > +}
> > +
> > +static const struct drm_mode_config_funcs
> > sun4i_de_mode_config_funcs
> > = {
> > +   .output_poll_changed=
> > sun4i_de_output_poll_changed,
> > +   .atomic_check   = drm_atomic_helper_check,
> > +   .atomic_commit  = drm_atomic_helper_commit,
> > +   .fb_create  = drm_fb_cma_create,
> > +};
> > +
> > +struct drm_fbdev_cma *sun4i_framebuffer_init(struct drm_device
> > *drm)
> > +{
> > +   drm_mode_config_reset(drm);
> > +
> > +   drm->mode_config.max_width = 8192;
> > +   drm->mode_config.max_height = 8192;
> 
> Shouldn't these be 1920 x 1080 as per A10 User manual?

I was wrong here. 8192x8192 it is.

>

Päikest,
Priit Laes :)


[linux-sunxi] [PATCH v2 16/26] drm: Add Allwinner A10 Display Engine support

2016-01-16 Thread Priit Laes
          int layer, struct drm_plane
> *plane);
> +int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
> +       int layer, struct drm_plane
> *plane);
> +
> +#endif /* _SUN4I_BACKEND_H_ */
> 
[...]
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> new file mode 100644
> index ..cc7dedc5d256
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -0,0 +1,325 @@
> +/*
> + * 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 
> +#include 
> +#include 
> +
> +#include "sun4i_crtc.h"
> +#include "sun4i_drv.h"
> +#include "sun4i_framebuffer.h"
> +#include "sun4i_layer.h"
> +#include "sun4i_tcon.h"

[...]

> +static struct drm_driver sun4i_drv_driver = {
> + .driver_features= DRIVER_GEM | DRIVER_MODESET |
> DRIVER_PRIME | DRIVER_ATOMIC,
> +
> + /* Generic Operations */
> + .fops   = _drv_fops,
> + .name   = "sun4i-drm",
> + .desc   = "Allwinner sun4i Display
> Engine",
> + .date   = "20150629",

2016something ?

> + .major  = 1,
> + .minor  = 0,
> +
> + /* GEM Operations */
> + .dumb_create= drm_gem_cma_dumb_create,
> + .dumb_destroy   = drm_gem_dumb_destroy,
> + .dumb_map_offset= drm_gem_cma_dumb_map_offset,
> + .gem_free_object= drm_gem_cma_free_object,
> + .gem_vm_ops = _gem_cma_vm_ops,
> +
> + /* PRIME Operations */
> + .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> + .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> + .gem_prime_import   = drm_gem_prime_import,
> + .gem_prime_export   = drm_gem_prime_export,
> + .gem_prime_get_sg_table =
> drm_gem_cma_prime_get_sg_table,
> + .gem_prime_import_sg_table =
> drm_gem_cma_prime_import_sg_table,
> + .gem_prime_vmap = drm_gem_cma_prime_vmap,
> + .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
> + .gem_prime_mmap = drm_gem_cma_prime_mmap,
> +
> + /* Frame Buffer Operations */
> +
> + /* VBlank Operations */
> + .get_vblank_counter = drm_vblank_count,
> + .enable_vblank  = sun4i_drv_enable_vblank,
> + .disable_vblank = sun4i_drv_disable_vblank,
> +};
> +
[...]
> diff --git a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> new file mode 100644
> index ..68072b8cddab
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> @@ -0,0 +1,54 @@
> +/*
> + * 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 "sun4i_drv.h"
> +
> +static void sun4i_de_output_poll_changed(struct drm_device *drm)
> +{
> + struct sun4i_drv *drv = drm->dev_private;
> +
> + if (drv->fbdev)
> + drm_fbdev_cma_hotplug_event(drv->fbdev);
> +}
> +
> +static const struct drm_mode_config_funcs sun4i_de_mode_config_funcs
> = {
> + .output_poll_changed= sun4i_de_output_poll_changed,
> + .atomic_check   = drm_atomic_helper_check,
> + .atomic_commit  = drm_atomic_helper_commit,
> + .fb_create  = drm_fb_cma_create,
> +};
> +
> +struct drm_fbdev_cma *sun4i_framebuffer_init(struct drm_device *drm)
> +{
> + drm_mode_config_reset(drm);
> +
> + drm->mode_config.max_width = 8192;
> + drm->mode_config.max_height = 8192;

Shouldn't these be 1920 x 1080 as per A10 User manual?

> +
> + drm->mode_config.funcs = _de_mode_config_funcs;
> +
> + return drm_fbdev_cma_init(drm, 32,
> +   drm->mode_config.num_crtc,
> +   drm->mode_config.num_connector);
> +}
> +
> +void sun4i_framebuffer_free(struct drm_device *drm)
> +{
> + struct sun4i_drv *drv = drm->dev_private;
> +
> + drm_fbdev_cma_fini(drv->fbdev);
> + drm_mode_config_cleanup(drm);
> +}
[...]

Päikest,
Priit Laes :)


[linux-sunxi] [PATCH v2 05/26] clk: sunxi: Add display and TCON0 clocks driver

2016-01-16 Thread Priit Laes
On Thu, 2016-01-14 at 16:24 +0100, Maxime Ripard wrote:
> The A10 SoCs and its relatives has a special clock controller to drive the
> display engines (both frontend and backend), that have a lot in common with
> the clock to drive the first TCON channel.
> 
> Add a driver to support both.

...

> +static void __init sun4i_a10_display_init(struct device_node *node,
> +   struct sun4i_a10_display_clk_data 
> *data)
> +{
> + const char *parents[data->parents];
> + const char *clk_name = node->name;
> + struct reset_data *reset_data;
> + struct clk_divider *div = NULL;
> + struct clk_gate *gate;
> + struct clk_mux *mux;
> + void __iomem *reg;
> + struct clk *clk;
> + int i;

warning: unused variable 'i'

> +
> + of_property_read_string(node, "clock-output-names", _name);
> +
> + reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> + if (IS_ERR(reg)) {
> + pr_err("%s: Could not map the clock registers\n", clk_name);
> + return;
> + }

...

Thanks for working on this feature ;)

Päikest,
Priit Laes