[PATCH v2 3/3] drm: rcar-du: Register a completion callback with VSP1

[Kieran Bingham]

Currently we process page flip events on every display interrupt,
however this does not take into consideration the processing time needed
by the VSP1 utilised in the pipeline.

Register a callback with the VSP driver to obtain completion events, and
track them so that we only perform page flips when the full display
pipeline has completed for the frame.

Signed-off-by: Kieran Bingham 

---
v2:
 - Commit message completely re-worded for patch re-work.
 - drm_crtc_handle_vblank() re-instated in event of rcrtc->pending
 - removed passing of unnecessary 'data' through callbacks
 - perform page flips from the VSP completion handler
 - add locking around pending flags

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 10 +++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  2 ++-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 29 +++-
 3 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 7391dd95c733..b7ff00bb45de 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -299,7 +299,7 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc 
*rcrtc)
  * Page Flip
  */
 
-static void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
+void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
 {
struct drm_pending_vblank_event *event;
struct drm_device *dev = rcrtc->crtc.dev;
@@ -328,7 +328,7 @@ static bool rcar_du_crtc_page_flip_pending(struct 
rcar_du_crtc *rcrtc)
bool pending;
 
spin_lock_irqsave(>event_lock, flags);
-   pending = rcrtc->event != NULL;
+   pending = (rcrtc->event != NULL) || (rcrtc->pending);
spin_unlock_irqrestore(>event_lock, flags);
 
return pending;
@@ -579,6 +579,12 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
 
if (status & DSSR_FRM) {
drm_crtc_handle_vblank(>crtc);
+
+   if (rcrtc->pending) {
+   trace_printk("VBlank loss due to VSP Overrun\n");
+   return IRQ_HANDLED;
+   }
+
rcar_du_crtc_finish_page_flip(rcrtc);
ret = IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index a7194812997e..b73ec6de7af4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -47,6 +47,7 @@ struct rcar_du_crtc {
 
struct drm_pending_vblank_event *event;
wait_queue_head_t flip_wait;
+   bool pending;
 
unsigned int outputs;
 
@@ -71,5 +72,6 @@ void rcar_du_crtc_resume(struct rcar_du_crtc *rcrtc);
 
 void rcar_du_crtc_route_output(struct drm_crtc *crtc,
   enum rcar_du_output output);
+void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc);
 
 #endif /* __RCAR_DU_CRTC_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index b0ff304ce3dc..1fcd311badb1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -28,6 +28,22 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_vsp.h"
 
+static void rcar_du_vsp_complete(void *private)
+{
+   struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;
+   struct drm_device *dev = crtc->crtc.dev;
+   unsigned long flags;
+   bool pending;
+
+   spin_lock_irqsave(>event_lock, flags);
+   pending = crtc->pending;
+   crtc->pending = false;
+   spin_unlock_irqrestore(>event_lock, flags);
+
+   if (pending)
+   rcar_du_crtc_finish_page_flip(crtc);
+}
+
 void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
 {
const struct drm_display_mode *mode = >crtc.state->adjusted_mode;
@@ -35,6 +51,8 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
struct vsp1_du_lif_config cfg = {
.width = mode->hdisplay,
.height = mode->vdisplay,
+   .callback = rcar_du_vsp_complete,
+   .callback_data = crtc,
};
struct rcar_du_plane_state state = {
.state = {
@@ -85,6 +103,17 @@ void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
 
 void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
 {
+   struct drm_device *dev = crtc->crtc.dev;
+   unsigned long flags;
+   bool pending;
+
+   spin_lock_irqsave(>event_lock, flags);
+   pending = crtc->pending;
+   crtc->pending = true;
+   spin_unlock_irqrestore(>event_lock, flags);
+
+   WARN_ON(pending);
+
vsp1_du_atomic_flush(crtc->vsp->vsp);
 }
 
-- 
git-series 0.9.1

[PATCH v2 1/3] v4l: vsp1: extend VSP1 module API to allow DRM callbacks

[Kieran Bingham]

To be able to perform page flips in DRM without flicker we need to be
able to notify the rcar-du module when the VSP has completed its
processing.

We must not have bidirectional dependencies on the two components to
maintain support for loadable modules, thus we extend the API to allow
a callback to be registered within the VSP DRM interface.

Signed-off-by: Kieran Bingham 

---
v2:
 - vsp1_du_setup_lif() uses config structure to set callbacks
 - vsp1_du_pipeline_frame_end() moved to interrupt section
 - vsp1_du_pipeline_frame_end registered in vsp1_drm_init()
   meaning of any NULL values
 - removed unnecessary 'private data' variables

 drivers/media/platform/vsp1/vsp1_drm.c | 20 
 drivers/media/platform/vsp1/vsp1_drm.h | 10 ++
 include/media/vsp1.h   |  3 +++
 3 files changed, 33 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 7dce55043379..85e5ebca82a5 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -36,6 +36,16 @@ void vsp1_drm_display_start(struct vsp1_device *vsp1)
vsp1_dlm_irq_display_start(vsp1->drm->pipe.output->dlm);
 }
 
+static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
+{
+   struct vsp1_drm *drm = to_vsp1_drm(pipe);
+
+   if (drm->du_complete && drm->du_pending) {
+   drm->du_complete(drm->du_private);
+   drm->du_pending = false;
+   }
+}
+
 /* 
-
  * DU Driver API
  */
@@ -95,6 +105,7 @@ int vsp1_du_setup_lif(struct device *dev, const struct 
vsp1_du_lif_config *cfg)
}
 
pipe->num_inputs = 0;
+   vsp1->drm->du_complete = NULL;
 
vsp1_dlm_reset(pipe->output->dlm);
vsp1_device_put(vsp1);
@@ -196,6 +207,13 @@ int vsp1_du_setup_lif(struct device *dev, const struct 
vsp1_du_lif_config *cfg)
if (ret < 0)
return ret;
 
+   /*
+* Register a callback to allow us to notify the DRM framework of frame
+* completion events.
+*/
+   vsp1->drm->du_complete = cfg->callback;
+   vsp1->drm->du_private = cfg->callback_data;
+
ret = media_pipeline_start(>output->entity.subdev.entity,
  >pipe);
if (ret < 0) {
@@ -504,6 +522,7 @@ void vsp1_du_atomic_flush(struct device *dev)
 
vsp1_dl_list_commit(pipe->dl);
pipe->dl = NULL;
+   vsp1->drm->du_pending = true;
 
/* Start or stop the pipeline if needed. */
if (!vsp1->drm->num_inputs && pipe->num_inputs) {
@@ -597,6 +616,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
pipe->lif = >lif->entity;
pipe->output = vsp1->wpf[0];
pipe->output->pipe = pipe;
+   pipe->frame_end = vsp1_du_pipeline_frame_end;
 
return 0;
 }
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index 9e28ab9254ba..3a53e9a60c73 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -33,8 +33,18 @@ struct vsp1_drm {
struct v4l2_rect compose;
unsigned int zpos;
} inputs[VSP1_MAX_RPF];
+
+   /* Frame syncronisation */
+   void (*du_complete)(void *);
+   void *du_private;
+   bool du_pending;
 };
 
+static inline struct vsp1_drm *to_vsp1_drm(struct vsp1_pipeline *pipe)
+{
+   return container_of(pipe, struct vsp1_drm, pipe);
+}
+
 int vsp1_drm_init(struct vsp1_device *vsp1);
 void vsp1_drm_cleanup(struct vsp1_device *vsp1);
 int vsp1_drm_create_links(struct vsp1_device *vsp1);
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index bfc701f04f3f..f6629f19f209 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -23,6 +23,9 @@ int vsp1_du_init(struct device *dev);
 struct vsp1_du_lif_config {
unsigned int width;
unsigned int height;
+
+   void (*callback)(void *);
+   void *callback_data;
 };
 
 int vsp1_du_setup_lif(struct device *dev, const struct vsp1_du_lif_config 
*cfg);
-- 
git-series 0.9.1

[PATCH v2 0/3] RCAR-DU, VSP1: Prevent pre-emptive frame flips on VSP1-DRM pipelines

[Kieran Bingham]

The RCAR-DU utilises a running VSPD pipeline to perform processing
for the display pipeline.

Changes to this pipeline are performed with an atomic flush operation which
updates the state in the VSPD. Due to the way the running pipeline is
operated, any flush operation has an implicit latency of one frame interval.

This comes about as the display list is committed, but not updated until the
next VSP1 interrupt. At this point the frame is being processed, but is not
complete until the following VSP1 frame end interrupt.

To prevent reporting page flips early, we must track this timing through the
VSP1, and only allow the rcar-du object to report the page-flip completion
event after the VSP1 has processed.

This series ensures that tearing and flicker is prevented, without introducing 
the
performance impact mentioned in the previous series.

[PATCH 1/3] extends the VSP1 to allow a callback to be registered giving the
VSP1 the ability to notify completion events
[PATCH 2/3] checks for race conditions in the commits of the display list, and
in such event postpones the sending of the completion event
[PATCH 3/3] Utilises the callback extension to send page flips at the end of
VSP processing.

These patches have been tested by introducing artificial delays in the commit
code paths and verifying that no visual tearing or flickering occurs.

Manual start/stop testing has also been performed

Kieran Bingham (3):
  v4l: vsp1: extend VSP1 module API to allow DRM callbacks
  v4l: vsp1: Postpone page flip in event of display list race
  drm: rcar-du: Register a completion callback with VSP1

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 10 +++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |  2 ++-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 29 ++-
 drivers/media/platform/vsp1/vsp1_dl.c   |  9 ++--
 drivers/media/platform/vsp1/vsp1_dl.h   |  2 +-
 drivers/media/platform/vsp1/vsp1_drm.c  | 22 -
 drivers/media/platform/vsp1/vsp1_drm.h  | 10 +-
 drivers/media/platform/vsp1/vsp1_pipe.c |  6 -
 drivers/media/platform/vsp1/vsp1_pipe.h |  2 ++-
 include/media/vsp1.h|  3 +++-
 10 files changed, 89 insertions(+), 6 deletions(-)

base-commit: 55e78dfc82988a79773ccca67e121f9a88df81c2
-- 
git-series 0.9.1

[PATCH v2 2/3] v4l: vsp1: Postpone page flip in event of display list race

[Kieran Bingham]

If we try to commit the display list while an update is pending, we have
missed our opportunity. The display list manager will hold the commit
until the next interrupt.

In this event, we inform the vsp1 completion callback handler so that
the du will not perform a page flip out of turn.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c   |  9 +++--
 drivers/media/platform/vsp1/vsp1_dl.h   |  2 +-
 drivers/media/platform/vsp1/vsp1_drm.c  |  4 +++-
 drivers/media/platform/vsp1/vsp1_pipe.c |  6 +-
 drivers/media/platform/vsp1/vsp1_pipe.h |  2 ++
 5 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index ad545aff4e35..f8e8c90f22bc 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -557,9 +557,10 @@ void vsp1_dlm_irq_display_start(struct vsp1_dl_manager 
*dlm)
spin_unlock(>lock);
 }
 
-void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
+int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 {
struct vsp1_device *vsp1 = dlm->vsp1;
+   int ret = 0;
 
spin_lock(>lock);
 
@@ -578,8 +579,10 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 * before interrupt processing. The hardware hasn't taken the update
 * into account yet, we'll thus skip one frame and retry.
 */
-   if (vsp1_read(vsp1, VI6_DL_BODY_SIZE) & VI6_DL_BODY_SIZE_UPD)
+   if (vsp1_read(vsp1, VI6_DL_BODY_SIZE) & VI6_DL_BODY_SIZE_UPD) {
+   ret = -EBUSY;
goto done;
+   }
 
/* The device starts processing the queued display list right after the
 * frame end interrupt. The display list thus becomes active.
@@ -606,6 +609,8 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 
 done:
spin_unlock(>lock);
+
+   return ret;
 }
 
 /* Hardware Setup */
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
b/drivers/media/platform/vsp1/vsp1_dl.h
index 7131aa3c5978..c772a1d92513 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -28,7 +28,7 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device 
*vsp1,
 void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_irq_display_start(struct vsp1_dl_manager *dlm);
-void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
+int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
 
 struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm);
 void vsp1_dl_list_put(struct vsp1_dl_list *dl);
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 85e5ebca82a5..6f2dd42ca01b 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -40,10 +40,12 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe)
 {
struct vsp1_drm *drm = to_vsp1_drm(pipe);
 
-   if (drm->du_complete && drm->du_pending) {
+   if (drm->du_complete && drm->du_pending && !pipe->dl_postponed) {
drm->du_complete(drm->du_private);
drm->du_pending = false;
}
+
+   pipe->dl_postponed = false;
 }
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 280ba0804699..3c5aae8767dd 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -297,10 +297,14 @@ bool vsp1_pipeline_ready(struct vsp1_pipeline *pipe)
 
 void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
 {
+   int ret;
+
if (pipe == NULL)
return;
 
-   vsp1_dlm_irq_frame_end(pipe->output->dlm);
+   ret = vsp1_dlm_irq_frame_end(pipe->output->dlm);
+   if (ret)
+   pipe->dl_postponed = true;
 
if (pipe->frame_end)
pipe->frame_end(pipe);
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index ac4ad261..65cc8fb76662 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -77,6 +77,7 @@ enum vsp1_pipeline_state {
  * @uds_input: entity at the input of the UDS, if the UDS is present
  * @entities: list of entities in the pipeline
  * @dl: display list associated with the pipeline
+ * @dl_postponed: identifies if the dl commit was caught by a race condition
  * @div_size: The maximum allowed partition size for the pipeline
  * @partitions: The number of partitions used to process one frame
  * @current_partition: The partition number currently being configured
@@ -107,6 +108,7 @@ struct vsp1_pipeline {
struct list_head entities;
 
struct vsp1_dl_list *dl;
+   bool dl_postponed;
 
unsigned int div_size;

[PATCH v5.1 10/10] drm: bridge: dw-hdmi: Move the driver to a separate directory.

[Laurent Pinchart]

The driver is already made of 5 separate source files. Move it to a
newly created directory named synopsys where more Synopsys bridge
drivers can be added later (for the DisplayPort controller for
instance).

Suggested-by: Jose Abreu 
Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
Changes since v5:

- Removed dw-hdmi Kconfig options from drivers/gpu/bridge/Kconfig

Changes since v4:

- Fixed typos in Kconfig
---
 drivers/gpu/drm/bridge/Kconfig | 26 ++
 drivers/gpu/drm/bridge/Makefile|  4 +---
 drivers/gpu/drm/bridge/synopsys/Kconfig| 23 +++
 drivers/gpu/drm/bridge/synopsys/Makefile   |  5 +
 .../drm/bridge/{ => synopsys}/dw-hdmi-ahb-audio.c  |  0
 .../gpu/drm/bridge/{ => synopsys}/dw-hdmi-audio.h  |  0
 .../drm/bridge/{ => synopsys}/dw-hdmi-i2s-audio.c  |  0
 drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.c|  0
 drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.h|  0
 9 files changed, 31 insertions(+), 27 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/synopsys/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/synopsys/Makefile
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi-ahb-audio.c (100%)
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi-audio.h (100%)
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi-i2s-audio.c (100%)
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.c (100%)
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.h (100%)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index eb8688ec6f18..02e211cd8129 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -24,30 +24,6 @@ config DRM_DUMB_VGA_DAC
help
  Support for RGB to VGA DAC based bridges
 
-config DRM_DW_HDMI
-   tristate
-   select DRM_KMS_HELPER
-
-config DRM_DW_HDMI_AHB_AUDIO
-   tristate "Synopsis Designware AHB Audio interface"
-   depends on DRM_DW_HDMI && SND
-   select SND_PCM
-   select SND_PCM_ELD
-   select SND_PCM_IEC958
-   help
- Support the AHB Audio interface which is part of the Synopsis
- Designware HDMI block.  This is used in conjunction with
- the i.MX6 HDMI driver.
-
-config DRM_DW_HDMI_I2S_AUDIO
-   tristate "Synopsis Designware I2S Audio interface"
-   depends on SND_SOC
-   depends on DRM_DW_HDMI
-   select SND_SOC_HDMI_CODEC
-   help
- Support the I2S Audio interface which is part of the Synopsis
- Designware HDMI block.
-
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
@@ -101,4 +77,6 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
 
 source "drivers/gpu/drm/bridge/adv7511/Kconfig"
 
+source "drivers/gpu/drm/bridge/synopsys/Kconfig"
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2e83a7855399..103f82e63102 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,9 +2,6 @@ ccflags-y := -Iinclude/drm
 
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
-obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
-obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
-obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
@@ -13,3 +10,4 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
b/drivers/gpu/drm/bridge/synopsys/Kconfig
new file mode 100644
index ..40d2827a6d19
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -0,0 +1,23 @@
+config DRM_DW_HDMI
+   tristate
+   select DRM_KMS_HELPER
+
+config DRM_DW_HDMI_AHB_AUDIO
+   tristate "Synopsys Designware AHB Audio interface"
+   depends on DRM_DW_HDMI && SND
+   select SND_PCM
+   select SND_PCM_ELD
+   select SND_PCM_IEC958
+   help
+ Support the AHB Audio interface which is part of the Synopsys
+ Designware HDMI block.  This is used in conjunction with
+ the i.MX6 HDMI driver.
+
+config DRM_DW_HDMI_I2S_AUDIO
+   tristate "Synopsys Designware I2S Audio interface"
+   depends on SND_SOC
+   depends on DRM_DW_HDMI
+   select SND_SOC_HDMI_CODEC
+   help
+ Support the I2S Audio interface which is part of the Synopsys
+ Designware HDMI block.
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile 
b/drivers/gpu/drm/bridge/synopsys/Makefile
new file mode 100644
index ..17aa7a65b57e
--- /dev/null
+++ 

Re: [RFC PATCH 1/3] v4l: vsp1: Register pipe with output WPF

[Kieran Bingham]

Hi Laurent,

Thanks for the review,

On 03/03/17 01:57, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Wednesday 01 Mar 2017 13:12:54 Kieran Bingham wrote:
>> The DRM object does not register the pipe with the WPF object. This is
>> used internally throughout the driver as a means of accessing the pipe.
>> As such this breaks operations which require access to the pipe from WPF
>> interrupts.
>>
>> Register the pipe inside the WPF object after it has been declared as
>> the output.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/media/platform/vsp1/vsp1_drm.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
>> b/drivers/media/platform/vsp1/vsp1_drm.c index cd209dccff1b..8e2aa3f8e52f
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_drm.c
>> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
>> @@ -596,6 +596,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
>>  pipe->bru = >bru->entity;
>>  pipe->lif = >lif->entity;
>>  pipe->output = vsp1->wpf[0];
>> +pipe->output->pipe = pipe;
> 
> The vsp1_irq_handler() function calls vsp1_pipeline_frame_end() with wpf-
>> pipe, which is currently NULL. With this patch the function will get a non-
> NULL pipeline and will thus proceed to calling vsp1_dlm_irq_frame_end():
> 
> void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
> {
>   if (pipe == NULL)
>   return;
> 
>   vsp1_dlm_irq_frame_end(pipe->output->dlm);
> 
>   if (pipe->frame_end)
>   pipe->frame_end(pipe);
> 
>   pipe->sequence++;
> }
> 
> pipe->frame_end is NULL, pipe->sequence doesn't matter, but we now end up 
> calling vsp1_dlm_irq_frame_end(). This is a major change regarding display 
> list processing, yet it seems to have no effect at all.

I was a bit surprised at this bit. I had expected vsp1_dlm_irq_frame_end() to be
more critical, but ultimately - it's only job is to handle a race condition on
DL commits which we (presumably) don't hit. At least we don't hit in our testing
more than $(DL_QTY) times, or I believe the display would have hung.

In fact we would have panic'd on a NULL dereference with pipe->dl:
pipe->dl = vsp1_dl_list_get(pipe->output->dlm);

where I don't see any checks on pipe->dl != NULL in the current code paths.

> The following commit is to blame for skipping the call to 
> vsp1_dlm_irq_frame_end().
> 
> commit ff7e97c94d9f7f370fe3ce2a72e85361ca22a605
> Author: Laurent Pinchart 
> Date:   Tue Jan 19 19:16:36 2016 -0200
> 
> [media] v4l: vsp1: Store pipeline pointer in rwpf
> 
> I've added a few debug print statements to vsp1_dlm_irq_frame_end(), and it 
> looks like we only hit the if (dlm->queued) test or none of them at all. It 
> looks like we've been lucky that nothing broke.
> 
> Restoring the previous behaviour should be safe, but it would be worth it 
> inspecting the code very carefully to make sure the logic is still correct. 
> I'll do it tomorrow if you don't beat me to it.

As far as I can tell it still seems correct. If we had ever hit this race, I
believe we would have leaked the DL, (which is quite a limited resource to us),
which if anything just raises the importance of this fix.

> 
> In any case, how about adding a
> 
> Fixes: ff7e97c94d9f ("[media] v4l: vsp1: Store pipeline pointer in rwpf")

Absolutely.

This seems worthy of a stable backport...? (though not critical)

The breakage was introduced in 4.6...

Should I add a CC: sta...@kernel.org #4.6+

> line ?
> 
>>  return 0;
>>  }
> 

-- 
Regards

Kieran Bingham

Re: [PATCH] dt-bindings: drm: rcar-du: Document optional reset properties

[Geert Uytterhoeven]

On Fri, Mar 3, 2017 at 8:03 PM, Geert Uytterhoeven  wrote:
>>> +Optional properties:
>>> +  - resets: A list of phandles + reset-specifier pairs, one for each entry
>>> in
>>
>> s/phandlers/phandle/
>
> You're seeing typos that do not exist ;-)

Ah, you mean plural vs. singular?
You're right, but I just copied that from the "clocks" description...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 7/9] drm: bridge: dw-hdmi: Add support for custom PHY configuration

[Laurent Pinchart]

Hi Jose,

(CC'ing Archit)

On Friday 03 Mar 2017 15:57:57 Jose Abreu wrote:
> On 02-03-2017 15:38, Laurent Pinchart wrote:
> > On Thursday 02 Mar 2017 14:50:02 Jose Abreu wrote:
> >> On 02-03-2017 13:41, Laurent Pinchart wrote:
>  Hmm, this is kind of confusing. Why do you need a phy_ops and
>  then a separate configure_phy function? Can't we just use phy_ops
>  always? If its external phy then it would need to implement all
>  phy_ops functions.
> >>> 
> >>> The phy_ops are indeed meant to support vendor PHYs. The
> >>> .configure_phy() operation is meant to support Synopsys PHYs that don't
> >>> comply with the HDMI TX MHL and 3D PHYs I2C register layout and thus
> >>> need a different configure function, but can share the other operations
> >>> with the HDMI TX MHL and 3D PHYs. Ideally I'd like to move that code to
> >>> the dw-hdmi core, but at the moment I don't have enough information to
> >>> decide whether the register layout corresponds to the standard Synopsys
> >>> HDMI TX 2.0 PHY or if it has been modified by the vendor. Once we'll
> >>> have a second SoC using the same PHY we should have more information to
> >>> consolidate the code. Of course, if you can share the HDMI TX 2.0 PHY
> >>> datasheet, I won't mind reworking the code now ;-)
> >> 
> >> Well, if I want to keep my job I can't share the datasheet, and I
> >> do want to keep my job :)
> > 
> > That's so selfish :-D
> > 
> >> As far as I know this shouldn't change much. I already used (it
> >> was like a year ago) the dw-hdmi driver in a HDMI TX 2.0 PHY.
> > 
> > I really wonder what exactly has been integrated in the Renesas R-Car Gen3
> > SoC. The PHY is certainly reported as an HDMI TX 2.0 PHY, but the
> > registers seem different compared to the 2.0 PHY you've tested.
> > 
> >> But I am not following your logic here, sorry: You are mentioning a
> >> custom phy, right?
> > 
> > Custom is probably a bad name. From what I've been told it's a standard
> > Synopsys PHY, but I can't rule out vendor-specific customizations.
> > 
> >> If its custom then it should implement its own phy_ops. And I don't think
> >> that phy logic should go into core, this should all be extracted because
> >> I really believe it will make the code easier to read. Imagine this
> >> 
> >> organization:
> >> Folders/Files:
> >> drm/bridge/dw-hdmi/dw-hdmi-core.c
> >> drm/bridge/dw-hdmi/dw-hdmi-phy-synopsys.c
> >> drm/bridge/dw-hdmi/dw-hdmi-phy-*renesas*.c
> >> drm/bridge/dw-hdmi/dw-hdmi-phy-something.c
> >> 
> >> Structures:
> >> dw_hdmi_pdata
> >> dw_hdmi_phy_pdata
> >> dw_hdmi_phy_ops
> > 
> > That looks good to me.
> > 
> >> As the phy is interacted using controller we would need to pass
> >> some callbacks to the phy, but ultimately the phy would be a
> >> platform driver which could have its own compatible string that
> >> would be associated with controller (not sure exactly about this
> >> because I only used this in non-dt).
> > 
> > We already have glue code, having to provide separate glue and PHY drivers
> > seems a bit overkill to me. If we could get rid of glue code by adding a
> > node for the PHY in DT that would be nice, but if we have to keep the
> > glue then we can as well use platform data there.
> > 
> >> This is just an idea though. I followed this logic in the RX side
> >> and its very easy to add a new phy now, its a matter of creating
> >> a new file, implement ops and associate it with controller. Of
> >> course some phys will be very similar, for that we can use minor
> >> tweaks via id detection.
> >> 
> >> What do you think?
> > 
> > It sounds neat overall, but I wonder whether it should really block this
> > series, or be added on top of it :-) I think we're already moving in the
> > right direction here.
> 
> This series is definitely a good starting point and a good
> improvement. We can think later about abstracting even more the
> phy from the controller. I think this will be a major step and
> will reflect better how the HW is modeled.
> 
> You can add my reviewed-by in all the patches in this series in
> your next submission (or in the merge).

Thank you !

> Also, if you do a next submission what do you think about moving
> all the dw-hdmi files to a new folder called for example
> 'synopsys' or 'dw-hdmi'? Because we already have 5 files. I think
> 'synopsys' instead of 'dw-hdmi' would be better because in the
> future we may add support for other protocols (for example
> display port).

I've posted a patch for that.

> Side note: I think you missed in the cc Archit Taneja

Oops, indeed :-/ Fixed on this patch, and I'll make sure to CC him on v5.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dt-bindings: drm: rcar-du: Document optional reset properties

[Geert Uytterhoeven]

Hi Laurent,

On Fri, Mar 3, 2017 at 8:17 PM, Laurent Pinchart
 wrote:
> On Friday 03 Mar 2017 20:03:09 Geert Uytterhoeven wrote:
>> On Fri, Mar 3, 2017 at 3:41 PM, Laurent Pinchart wrote:
>> > What's in the reset specifier ?
>>
>> That depends on the reset provider.
>>
>> See "[v2,1/4] dt-bindings: clock: renesas: cpg-mssr: Document reset control
>> support" (https://patchwork.kernel.org/patch/9536627/) for the Renesas
>> CPG/MSSR case.
>>
>> E.g. "resets = < 310>;"
>
> Thanks. I never know whether the specified is the combination of phandle +
> data, or is only the cells following the phandle.

Trick to remember: the #-cells property tells how many cells there
are in the specifier.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] dt-bindings: drm: rcar-du: Document optional reset properties

[Geert Uytterhoeven]

Hi Laurent,

On Fri, Mar 3, 2017 at 3:41 PM, Laurent Pinchart
 wrote:
> On Friday 03 Mar 2017 14:30:35 Geert Uytterhoeven wrote:
>> Document the optional properties for describing module resets, to
>> support resetting display channels and LVDS encoders on R-Car Gen2 and
>> Gen3.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>>  Documentation/devicetree/bindings/display/renesas,du.txt | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
>> b/Documentation/devicetree/bindings/display/renesas,du.txt index
>> 1a02f099a0ff0a3a..7873d53764a297c2 100644
>> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
>> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
>> @@ -36,6 +36,16 @@ Required Properties:
>>When supplied they must be named "dclkin.x" with "x" being the input
>>clock numerical index.
>>
>> +Optional properties:
>> +  - resets: A list of phandles + reset-specifier pairs, one for each entry
>> in
>
> s/phandlers/phandle/

You're seeing typos that do not exist ;-)

>> +the reset-names property.
>
> What's in the reset specifier ?

That depends on the reset provider.

See "[v2,1/4] dt-bindings: clock: renesas: cpg-mssr: Document reset control
support" (https://patchwork.kernel.org/patch/9536627/) for the Renesas
CPG/MSSR case.

E.g. "resets = < 310>;"

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] dt-bindings: drm: rcar-du: Document optional reset properties

[Laurent Pinchart]

Hi Geert,

On Friday 03 Mar 2017 20:03:09 Geert Uytterhoeven wrote:
> On Fri, Mar 3, 2017 at 3:41 PM, Laurent Pinchart wrote:
> > On Friday 03 Mar 2017 14:30:35 Geert Uytterhoeven wrote:
> >> Document the optional properties for describing module resets, to
> >> support resetting display channels and LVDS encoders on R-Car Gen2 and
> >> Gen3.
> >> 
> >> Signed-off-by: Geert Uytterhoeven 
> >> ---
> >> 
> >>  Documentation/devicetree/bindings/display/renesas,du.txt | 10 ++
> >>  1 file changed, 10 insertions(+)
> >> 
> >> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
> >> b/Documentation/devicetree/bindings/display/renesas,du.txt index
> >> 1a02f099a0ff0a3a..7873d53764a297c2 100644
> >> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> >> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> >> 
> >> @@ -36,6 +36,16 @@ Required Properties:
> >>When supplied they must be named "dclkin.x" with "x" being the
> >>input clock numerical index.
> >> 
> >> +Optional properties:
> >> +  - resets: A list of phandles + reset-specifier pairs, one for each
> >> entry in
> > 
> > s/phandlers/phandle/
> 
> You're seeing typos that do not exist ;-)
> 
> >> +the reset-names property.
> > 
> > What's in the reset specifier ?
> 
> That depends on the reset provider.
> 
> See "[v2,1/4] dt-bindings: clock: renesas: cpg-mssr: Document reset control
> support" (https://patchwork.kernel.org/patch/9536627/) for the Renesas
> CPG/MSSR case.
> 
> E.g. "resets = < 310>;"

Thanks. I never know whether the specified is the combination of phandle + 
data, or is only the cells following the phandle.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dt-bindings: drm: rcar-du: Document optional reset properties

[Laurent Pinchart]

Hi Geert,

On Friday 03 Mar 2017 20:04:26 Geert Uytterhoeven wrote:
> On Fri, Mar 3, 2017 at 8:03 PM, Geert Uytterhoeven wrote:
> >>> +Optional properties:
> >>> +  - resets: A list of phandles + reset-specifier pairs, one for each
> >>> entry in
> >> 
> >> s/phandlers/phandle/
> > 
> > You're seeing typos that do not exist ;-)
> 
> Ah, you mean plural vs. singular?

Yes that's what I meant.

> You're right, but I just copied that from the "clocks" description...

Oops :-)

-- 
Regards,

Laurent Pinchart

[PATCH v5 2/3] watchdog: renesas-wdt: add support for rza

[Chris Brandt]

Describe the WDT hardware in the RZ/A series.

Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Rob Herring 
---
v3:
* Add Acked-by, Reviewed-by.
v2:
* added to renesas-wdt.txt instead of creating a new file
* changed commit title
* added "renesas,rza-wdt" as a fallback
* added interrupts property
---
 Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
index da24e31..9e306af 100644
--- a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
@@ -2,10 +2,11 @@ Renesas Watchdog Timer (WDT) Controller
 
 Required properties:
 - compatible : Should be "renesas,-wdt", and
-  "renesas,rcar-gen3-wdt" as fallback.
+  "renesas,rcar-gen3-wdt" or "renesas,rza-wdt" as fallback.
   Examples with soctypes are:
 - "renesas,r8a7795-wdt" (R-Car H3)
 - "renesas,r8a7796-wdt" (R-Car M3-W)
+- "renesas,r7s72100-wdt" (RZ/A1)
 
   When compatible with the generic version, nodes must list the SoC-specific
   version corresponding to the platform first, followed by the generic
@@ -17,6 +18,7 @@ Required properties:
 Optional properties:
 - timeout-sec : Contains the watchdog timeout in seconds
 - power-domains : the power domain the WDT belongs to
+- interrupts: Some WDTs have an interrupt when used in interval timer mode
 
 Examples:
 
-- 
2.10.1

[PATCH v5 1/3] watchdog: add rza_wdt driver

[Chris Brandt]

Adds a watchdog timer driver for the Renesas RZ/A Series SoCs. A reset
handler is also included since a WDT overflow is the only method for
restarting an RZ/A SoC.

Signed-off-by: Chris Brandt 
---
v2:
* removed extra lines from file header comments
* changed (1<<#) to BIT(#)
* changed #define WTSCR_CKS(i) i to (i)
* changed format to #define SOMETHINGvalue (and align values)
* now check if clock rate < 16384
* added space before and after '/' for "(1000 * U8_MAX) / rate"
* changed dev_info to dev_dbg for printing max_hw_heartbeat_ms
* added watchdog_init_timeout() for user to set timeout in DT
* switched to using devm_watchdog_register_device()
* added error message if register fails
* simplified rza_wdt_probe() return
* removed function rza_wdt_remove()
---
 drivers/watchdog/Kconfig   |   8 ++
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/rza_wdt.c | 199 +
 3 files changed, 208 insertions(+)
 create mode 100644 drivers/watchdog/rza_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index acb00b5..123c516 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -701,6 +701,14 @@ config RENESAS_WDT
  This driver adds watchdog support for the integrated watchdogs in the
  Renesas R-Car and other SH-Mobile SoCs (usually named RWDT or SWDT).
 
+config RENESAS_RZAWDT
+   tristate "Renesas RZ/A WDT Watchdog"
+   depends on ARCH_RENESAS || COMPILE_TEST
+   select WATCHDOG_CORE
+   help
+ This driver adds watchdog support for the integrated watchdogs in the
+ Renesas RZ/A SoCs. These watchdogs can be used to reset a system.
+
 config ASPEED_WATCHDOG
tristate "Aspeed 2400 watchdog support"
depends on ARCH_ASPEED || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0c3d35e..84b897c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_LPC18XX_WATCHDOG) += lpc18xx_wdt.o
 obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
 obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
 obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
+obj-$(CONFIG_RENESAS_RZAWDT) += rza_wdt.o
 obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
 
 # AVR32 Architecture
diff --git a/drivers/watchdog/rza_wdt.c b/drivers/watchdog/rza_wdt.c
new file mode 100644
index 000..76a9c1f
--- /dev/null
+++ b/drivers/watchdog/rza_wdt.c
@@ -0,0 +1,199 @@
+/*
+ * Renesas RZ/A Series WDT Driver
+ *
+ * Copyright (C) 2017 Renesas Electronics America, Inc.
+ * Copyright (C) 2017 Chris Brandt
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_TIMEOUT30
+
+/* Watchdog Timer Registers */
+#define WTCSR  0
+#define WTCSR_MAGIC0xA500
+#define WTSCR_WT   BIT(6)
+#define WTSCR_TME  BIT(5)
+#define WTSCR_CKS(i)   (i)
+
+#define WTCNT  2
+#define WTCNT_MAGIC0x5A00
+
+#define WRCSR  4
+#define WRCSR_MAGIC0x5A00
+#define WRCSR_RSTE BIT(6)
+#define WRCSR_CLEAR_WOVF   0xA500  /* special value */
+
+struct rza_wdt {
+   struct watchdog_device wdev;
+   void __iomem *base;
+   struct clk *clk;
+};
+
+static int rza_wdt_start(struct watchdog_device *wdev)
+{
+   struct rza_wdt *priv = watchdog_get_drvdata(wdev);
+
+   /* Stop timer */
+   writew(WTCSR_MAGIC | 0, priv->base + WTCSR);
+
+   /* Must dummy read WRCSR:WOVF at least once before clearing */
+   readb(priv->base + WRCSR);
+   writew(WRCSR_CLEAR_WOVF, priv->base + WRCSR);
+
+   /*
+* Start timer with slowest clock source and reset option enabled.
+*/
+   writew(WRCSR_MAGIC | WRCSR_RSTE, priv->base + WRCSR);
+   writew(WTCNT_MAGIC | 0, priv->base + WTCNT);
+   writew(WTCSR_MAGIC | WTSCR_WT | WTSCR_TME | WTSCR_CKS(7),
+  priv->base + WTCSR);
+
+   return 0;
+}
+
+static int rza_wdt_stop(struct watchdog_device *wdev)
+{
+   struct rza_wdt *priv = watchdog_get_drvdata(wdev);
+
+   writew(WTCSR_MAGIC | 0, priv->base + WTCSR);
+
+   return 0;
+}
+
+static int rza_wdt_ping(struct watchdog_device *wdev)
+{
+   struct rza_wdt *priv = watchdog_get_drvdata(wdev);
+
+   writew(WTCNT_MAGIC | 0, priv->base + WTCNT);
+
+   return 0;
+}
+
+static int rza_wdt_restart(struct watchdog_device *wdev, unsigned long action,
+   void *data)
+{
+   struct rza_wdt *priv = watchdog_get_drvdata(wdev);
+
+   /* Stop timer */
+   writew(WTCSR_MAGIC | 0, priv->base + WTCSR);
+
+   /* Must dummy read WRCSR:WOVF at least once before clearing */
+   readb(priv->base + WRCSR);
+   writew(WRCSR_CLEAR_WOVF, 

[PATCH v5 3/3] ARM: dts: r7s72100: Add watchdog timer

[Chris Brandt]

Add watchdog timer support for RZ/A1.
For the RZ/A1, the only way to do a reset is to overflow the WDT, so this
is useful even if you don't need the watchdog functionality.

Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
---
v4:
* changed from timer@ to watchdog@
v3:
* added Reviewed-by
v2:
* changed "renesas,r7s72100-reset" to "renesas,r7s72100-wdt"
* changed "renesas,wdt-reset" to "renesas,rza-wdt"
* added interupt property (even though it is not used)
* added clocks property
---
 arch/arm/boot/dts/r7s72100.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index ed62e19..22f96b7 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -382,6 +382,13 @@
cache-level = <2>;
};
 
+   wdt: watchdog@fcfe {
+   compatible = "renesas,r7s72100-wdt", "renesas,rza-wdt";
+   reg = <0xfcfe 0x6>;
+   interrupts = ;
+   clocks = <_clk>;
+   };
+
i2c0: i2c@fcfee000 {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.10.1

[PATCH v5 0/3] watchdog: add wdt and reset for renesas r7s72100

[Chris Brandt]

Some Renesas SoCs do not have a reset register and the only way to do a SW
controlled reset is to use the watchdog timer. So while this series started
out by only adding a reset feature, now it's a full watchdog timer driver that
includes a reset handler.

The longest WDT overflow you can get with a RZ/A1 (R7S72100) with its 8-bit
wide counter is 125ms. Not very long.

However, by setting max_hw_heartbeat_ms, the watchdog core will now handle
pinging the WDT automatically and allow the user to set times as big as they
want. Therefore, the default timeout for this driver is 30 seconds.

Of course if system interrupts are disabled too long and wdt can't be pinged
by the watchdog core, then the system will reset before the user specified
timeout. But hey, it's better nothing.

This driver was tested on an RZ/A1 RSK board using watchdog-simple.c from
samples/watchdog/.

v5:
* rza_wdt.c changes only
* removed extra lines from file header comments
* changed (1<<#) to BIT(#)
* changed #define WTSCR_CKS(i) i to (i)
* changed format to #define SOMETHINGvalue (and align values)
* now check if clock rate < 16384
* added space before and after '/' for "(1000 * U8_MAX) / rate"
* changed dev_info to dev_dbg for printing max_hw_heartbeat_ms
* added watchdog_init_timeout() for user to set timeout in DT
* switched to using devm_watchdog_register_device()
* added error message if register fails
* simplified rza_wdt_probe() return
* removed function rza_wdt_remove()

v4:
* r7s72100.dtsi: changed from timer@ to watchdog@

v3:
* changed from a reset driver to a watchdog timer driver
* use udelay(20) instead of msleep for reset handler
* added Reviewed-by for r7s72100.dtsi and renesas-wdt.txt
* added Acked-by for renesas-wdt.txt

v2:
* added to renesas-wdt.txt instead of creating a new file
* changed "renesas,r7s72100-reset" to "renesas,r7s72100-wdt"
* changed "renesas,wdt-reset" to "renesas,rza-wdt"
* added "renesas,rza-wdt" as a fallback
* added interupt property (even though it is not used)
* added clocks property
* changed hard coded register values to defines
* added msleep to while(1) loop
* removed unnecessary #include files
* added Reviewed-by: Geert Uytterhoeven for renesas-reset.c

Chris Brandt (3):
  watchdog: add rza_wdt driver
  watchdog: renesas-wdt: add support for rza
  ARM: dts: r7s72100: Add watchdog timer

 .../devicetree/bindings/watchdog/renesas-wdt.txt   |   4 +-
 arch/arm/boot/dts/r7s72100.dtsi|   7 +
 drivers/watchdog/Kconfig   |   8 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/rza_wdt.c | 199 +
 5 files changed, 218 insertions(+), 1 deletion(-)
 create mode 100644 drivers/watchdog/rza_wdt.c

-- 
2.10.1

[PATCH v5 09/10] drm: bridge: dw-hdmi: Switch to regmap for register access

[Laurent Pinchart]

From: Neil Armstrong 

The Synopsys Designware HDMI TX Controller does not enforce register
access on platforms instanciating it. The current driver supports two
different types of memory-mapped flat register access, but in order to
support the Amlogic Meson SoCs integration, and provide a more generic
way to handle all sorts of register mapping, switch the register access
to use the regmap infrastructure.

In the case of registers that are not flat memory-mapped or do not
conform to the current driver implementation, a regmap struct can be
given in the plat_data and be used at probe or bind.

Since the AHB audio driver is only available with direct memory access,
only allow the I2S audio driver to be registered is directly
memory-mapped.

Signed-off-by: Neil Armstrong 
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Tested-by: Neil Armstrong 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 109 +--
 include/drm/bridge/dw_hdmi.h |   1 +
 2 files changed, 59 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 132c00685796..026a0dce7661 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -171,8 +172,8 @@ struct dw_hdmi {
unsigned int audio_n;
bool audio_enable;
 
-   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
-   u8 (*read)(struct dw_hdmi *hdmi, int offset);
+   unsigned int reg_shift;
+   struct regmap *regm;
 };
 
 #define HDMI_IH_PHY_STAT0_RX_SENSE \
@@ -183,42 +184,23 @@ struct dw_hdmi {
(HDMI_PHY_RX_SENSE0 | HDMI_PHY_RX_SENSE1 | \
 HDMI_PHY_RX_SENSE2 | HDMI_PHY_RX_SENSE3)
 
-static void dw_hdmi_writel(struct dw_hdmi *hdmi, u8 val, int offset)
-{
-   writel(val, hdmi->regs + (offset << 2));
-}
-
-static u8 dw_hdmi_readl(struct dw_hdmi *hdmi, int offset)
-{
-   return readl(hdmi->regs + (offset << 2));
-}
-
-static void dw_hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
-{
-   writeb(val, hdmi->regs + offset);
-}
-
-static u8 dw_hdmi_readb(struct dw_hdmi *hdmi, int offset)
-{
-   return readb(hdmi->regs + offset);
-}
-
 static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
 {
-   hdmi->write(hdmi, val, offset);
+   regmap_write(hdmi->regm, offset << hdmi->reg_shift, val);
 }
 
 static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
 {
-   return hdmi->read(hdmi, offset);
+   unsigned int val = 0;
+
+   regmap_read(hdmi->regm, offset << hdmi->reg_shift, );
+
+   return val;
 }
 
 static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
 {
-   u8 val = hdmi_readb(hdmi, reg) & ~mask;
-
-   val |= data & mask;
-   hdmi_writeb(hdmi, val, reg);
+   regmap_update_bits(hdmi->regm, reg << hdmi->reg_shift, mask, data);
 }
 
 static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 data, unsigned int reg,
@@ -1989,6 +1971,20 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
return -ENODEV;
 }
 
+static const struct regmap_config hdmi_regmap_8bit_config = {
+   .reg_bits   = 32,
+   .val_bits   = 8,
+   .reg_stride = 1,
+   .max_register   = HDMI_I2CM_FS_SCL_LCNT_0_ADDR,
+};
+
+static const struct regmap_config hdmi_regmap_32bit_config = {
+   .reg_bits   = 32,
+   .val_bits   = 32,
+   .reg_stride = 4,
+   .max_register   = HDMI_I2CM_FS_SCL_LCNT_0_ADDR << 2,
+};
+
 static struct dw_hdmi *
 __dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
@@ -1998,7 +1994,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
struct platform_device_info pdevinfo;
struct device_node *ddc_node;
struct dw_hdmi *hdmi;
-   struct resource *iores;
+   struct resource *iores = NULL;
int irq;
int ret;
u32 val = 1;
@@ -2022,22 +2018,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
mutex_init(>audio_mutex);
spin_lock_init(>audio_lock);
 
-   of_property_read_u32(np, "reg-io-width", );
-
-   switch (val) {
-   case 4:
-   hdmi->write = dw_hdmi_writel;
-   hdmi->read = dw_hdmi_readl;
-   break;
-   case 1:
-   hdmi->write = dw_hdmi_writeb;
-   hdmi->read = dw_hdmi_readb;
-   break;
-   default:
-   dev_err(dev, "reg-io-width must be 1 or 4\n");
-   return ERR_PTR(-EINVAL);
-   }
-
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
@@ -2051,11 

[PATCH v5 10/10] drm: bridge: dw-hdmi: Move the driver to a separate directory.

[Laurent Pinchart]

The driver is already made of 5 separate source files. Move it to a
newly created directory named synopsys where more Synopsys bridge
drivers can be added later (for the DisplayPort controller for
instance).

Suggested-by: Jose Abreu 
Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
Changes since v4:

- Fixed typos in Kconfig
---
 drivers/gpu/drm/bridge/Kconfig |  2 ++
 drivers/gpu/drm/bridge/Makefile|  4 +---
 drivers/gpu/drm/bridge/synopsys/Kconfig| 23 ++
 drivers/gpu/drm/bridge/synopsys/Makefile   |  5 +
 .../drm/bridge/{ => synopsys}/dw-hdmi-ahb-audio.c  |  0
 .../gpu/drm/bridge/{ => synopsys}/dw-hdmi-audio.h  |  0
 .../drm/bridge/{ => synopsys}/dw-hdmi-i2s-audio.c  |  0
 drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.c|  0
 drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.h|  0
 9 files changed, 31 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/synopsys/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/synopsys/Makefile
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi-ahb-audio.c (100%)
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi-audio.h (100%)
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi-i2s-audio.c (100%)
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.c (100%)
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.h (100%)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index eb8688ec6f18..68ceba083ca1 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -101,4 +101,6 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
 
 source "drivers/gpu/drm/bridge/adv7511/Kconfig"
 
+source "drivers/gpu/drm/bridge/synopsys/Kconfig"
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2e83a7855399..103f82e63102 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,9 +2,6 @@ ccflags-y := -Iinclude/drm
 
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
-obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
-obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
-obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
@@ -13,3 +10,4 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
b/drivers/gpu/drm/bridge/synopsys/Kconfig
new file mode 100644
index ..40d2827a6d19
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -0,0 +1,23 @@
+config DRM_DW_HDMI
+   tristate
+   select DRM_KMS_HELPER
+
+config DRM_DW_HDMI_AHB_AUDIO
+   tristate "Synopsys Designware AHB Audio interface"
+   depends on DRM_DW_HDMI && SND
+   select SND_PCM
+   select SND_PCM_ELD
+   select SND_PCM_IEC958
+   help
+ Support the AHB Audio interface which is part of the Synopsys
+ Designware HDMI block.  This is used in conjunction with
+ the i.MX6 HDMI driver.
+
+config DRM_DW_HDMI_I2S_AUDIO
+   tristate "Synopsys Designware I2S Audio interface"
+   depends on SND_SOC
+   depends on DRM_DW_HDMI
+   select SND_SOC_HDMI_CODEC
+   help
+ Support the I2S Audio interface which is part of the Synopsys
+ Designware HDMI block.
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile 
b/drivers/gpu/drm/bridge/synopsys/Makefile
new file mode 100644
index ..17aa7a65b57e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/Makefile
@@ -0,0 +1,5 @@
+#ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
+obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
similarity index 100%
rename from drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
rename to drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-audio.h 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-audio.h
similarity index 100%
rename from drivers/gpu/drm/bridge/dw-hdmi-audio.h
rename to drivers/gpu/drm/bridge/synopsys/dw-hdmi-audio.h
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
similarity index 100%
rename from drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
rename to drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
similarity index 

[PATCH v5 08/10] drm: bridge: dw-hdmi: Remove device type from platform data

[Laurent Pinchart]

From: Kieran Bingham 

The device type isn't used anymore now that workarounds and PHY-specific
operations are performed based on version information read at runtime.
Remove it.

Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
Tested-by: Neil Armstrong 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c| 2 --
 drivers/gpu/drm/imx/dw_hdmi-imx.c   | 2 --
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
 include/drm/bridge/dw_hdmi.h| 7 ---
 4 files changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index b835d81bb471..132c00685796 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -127,7 +127,6 @@ struct dw_hdmi {
struct drm_connector connector;
struct drm_bridge bridge;
 
-   enum dw_hdmi_devtype dev_type;
unsigned int version;
 
struct platform_device *audio;
@@ -2014,7 +2013,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
 
hdmi->plat_data = plat_data;
hdmi->dev = dev;
-   hdmi->dev_type = plat_data->dev_type;
hdmi->sample_rate = 48000;
hdmi->disabled = true;
hdmi->rxsense = true;
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index f645275e6e63..f039641070ac 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -175,7 +175,6 @@ static struct dw_hdmi_plat_data imx6q_hdmi_drv_data = {
.mpll_cfg   = imx_mpll_cfg,
.cur_ctr= imx_cur_ctr,
.phy_config = imx_phy_config,
-   .dev_type   = IMX6Q_HDMI,
.mode_valid = imx6q_hdmi_mode_valid,
 };
 
@@ -183,7 +182,6 @@ static struct dw_hdmi_plat_data imx6dl_hdmi_drv_data = {
.mpll_cfg = imx_mpll_cfg,
.cur_ctr  = imx_cur_ctr,
.phy_config = imx_phy_config,
-   .dev_type = IMX6DL_HDMI,
.mode_valid = imx6dl_hdmi_mode_valid,
 };
 
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index a6d4a0236e8f..d53827413996 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -237,7 +237,6 @@ static const struct dw_hdmi_plat_data 
rockchip_hdmi_drv_data = {
.mpll_cfg   = rockchip_mpll_cfg,
.cur_ctr= rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
-   .dev_type   = RK3288_HDMI,
 };
 
 static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index dd330259a3dc..545f04fae3b6 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -21,12 +21,6 @@ enum {
DW_HDMI_RES_MAX,
 };
 
-enum dw_hdmi_devtype {
-   IMX6Q_HDMI,
-   IMX6DL_HDMI,
-   RK3288_HDMI,
-};
-
 enum dw_hdmi_phy_type {
DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00,
DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2,
@@ -65,7 +59,6 @@ struct dw_hdmi_phy_ops {
 };
 
 struct dw_hdmi_plat_data {
-   enum dw_hdmi_devtype dev_type;
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
   struct drm_display_mode *mode);
 
-- 
Regards,

Laurent Pinchart

[PATCH v5 02/10] drm: bridge: dw-hdmi: Move CSC configuration out of PHY code

[Laurent Pinchart]

The color space converter isn't part of the PHY, move its configuration
out of PHY code.

Signed-off-by: Laurent Pinchart 
Tested-by: Neil Armstrong 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 25 ++---
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ce7496399ccf..906583beb08b 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -914,7 +914,7 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
 }
 
-static int hdmi_phy_configure(struct dw_hdmi *hdmi, int cscon)
+static int hdmi_phy_configure(struct dw_hdmi *hdmi)
 {
u8 val, msec;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
@@ -946,14 +946,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
return -EINVAL;
}
 
-   /* Enable csc path */
-   if (cscon)
-   val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH;
-   else
-   val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS;
-
-   hdmi_writeb(hdmi, val, HDMI_MC_FLOWCTRL);
-
/* gen2 tx power off */
dw_hdmi_phy_gen2_txpwron(hdmi, 0);
 
@@ -1028,10 +1020,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
 static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
 {
int i, ret;
-   bool cscon;
-
-   /*check csc whether needed activated in HDMI mode */
-   cscon = hdmi->sink_is_hdmi && is_color_space_conversion(hdmi);
 
/* HDMI Phy spec says to do the phy initialization sequence twice */
for (i = 0; i < 2; i++) {
@@ -1040,8 +1028,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
dw_hdmi_phy_enable_tmds(hdmi, 0);
dw_hdmi_phy_enable_powerdown(hdmi, true);
 
-   /* Enable CSC */
-   ret = hdmi_phy_configure(hdmi, cscon);
+   ret = hdmi_phy_configure(hdmi);
if (ret)
return ret;
}
@@ -1303,6 +1290,14 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
*hdmi)
clkdis &= ~HDMI_MC_CLKDIS_CSCCLK_DISABLE;
hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
}
+
+   /* Enable color space conversion if needed (for HDMI sinks only). */
+   if (hdmi->sink_is_hdmi && is_color_space_conversion(hdmi))
+   hdmi_writeb(hdmi, HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH,
+   HDMI_MC_FLOWCTRL);
+   else
+   hdmi_writeb(hdmi, HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS,
+   HDMI_MC_FLOWCTRL);
 }
 
 static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi)
-- 
Regards,

Laurent Pinchart

[PATCH v5 00/10] drm: bridge: dw-hdmi: Refactor PHY support

[Laurent Pinchart]

Hello,

This patch series refactors all the PHY handling code in order to allow
support of vendor PHYs and Synopsys DWC HDMI 2.0 TX PHYs.

The series starts with a few cleanups and small fixes. Patch 01/10 just
removes unused code, patch 02/10 moves the color converter code out of the PHY
configure function as it isn't PHY-dependent, and patch 03/10 enables color
conversion even for DVI as it is needed to output RGB when the input format is
YUV.

The next two patches fix the power down (04/10) and up (05/10) sequences to
comply with the HDMI TX PHY specifications. They are the biggest functional
changes in the whole set, and have been tested successfully (with the rest of
the series) on i.MX6Q, RK3288 and R-Car H3. The PLL PHY lock delay has been
measured to be between 300µs and 350µs on R-Car H3, between 400µs and 600µs on
i.MX6Q and between 150µs and 450µs on RK3288. The PHY power down delay has
been measured to be less than 50µs on all platforms, and was often close to
instant with power down reported in the first poll iteration. We should thus
be more than safe with a 5ms timeout.

Patch 06/10 breaks the PHY operations out. Glue code is then allowed to pass a
PHY operations structure to support vendor PHYs. The existing PHY support code
is turned into a default Synopsys PHYs implementation for those PHY
operations.

Patch 07/10 further refactors the Synopsys PHY configuration function to make
it modular, in order to support DWC HDMI 2.0 TX PHYs that have a very
different register layout compared to the currently supported PHYs. Glue code
is again allowed to provide a custom PHY configuration implementation, with
the existing PHY support code turned into the default implementation for all
currently supported Synopsys PHYs.

Patch 08/10 is a small cleanup that removes the now unneeded device type for
glue code platform data, and patch 09/10 follows by switching the driver to
regmap in order to support vendor-specific register access more easily.

Patch 10/10 is a v5 addition that moves the code to a new directory per Jose's
request. v5 also picked up review tags from the mailing list, and is rebased
on top of the latest drm-misc-next branch. The series is otherwise unchanged
compared to v4.

Archit, how would you like to proceed to get this merged ?

Kieran Bingham (2):
  drm: bridge: dw-hdmi: Add support for custom PHY configuration
  drm: bridge: dw-hdmi: Remove device type from platform data

Laurent Pinchart (6):
  drm: bridge: dw-hdmi: Remove unused functions
  drm: bridge: dw-hdmi: Move CSC configuration out of PHY code
  drm: bridge: dw-hdmi: Fix the PHY power down sequence
  drm: bridge: dw-hdmi: Fix the PHY power up sequence
  drm: bridge: dw-hdmi: Create PHY operations
  drm: bridge: dw-hdmi: Move the driver to a separate directory.

Neil Armstrong (2):
  drm: bridge: dw-hdmi: Enable CSC even for DVI
  drm: bridge: dw-hdmi: Switch to regmap for register access

 drivers/gpu/drm/bridge/Kconfig |   2 +
 drivers/gpu/drm/bridge/Makefile|   4 +-
 drivers/gpu/drm/bridge/synopsys/Kconfig|  23 +
 drivers/gpu/drm/bridge/synopsys/Makefile   |   5 +
 .../drm/bridge/{ => synopsys}/dw-hdmi-ahb-audio.c  |   0
 .../gpu/drm/bridge/{ => synopsys}/dw-hdmi-audio.h  |   0
 .../drm/bridge/{ => synopsys}/dw-hdmi-i2s-audio.c  |   0
 drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.c| 467 -
 drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.h|   0
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |   2 -
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c|   1 -
 include/drm/bridge/dw_hdmi.h   |  33 +-
 12 files changed, 335 insertions(+), 202 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/synopsys/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/synopsys/Makefile
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi-ahb-audio.c (100%)
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi-audio.h (100%)
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi-i2s-audio.c (100%)
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.c (88%)
 rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.h (100%)

-- 
Regards,

Laurent Pinchart

[PATCH v5 03/10] drm: bridge: dw-hdmi: Enable CSC even for DVI

[Laurent Pinchart]

From: Neil Armstrong 

If the input pixel format is not RGB, the CSC must be enabled in order to
provide valid pixel to DVI sinks.
This patch removes the hdmi only dependency on the CSC enabling.

Reviewed-by: Jose Abreu 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Neil Armstrong 
Tested-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 906583beb08b..d863b3393aee 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1291,8 +1291,8 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
*hdmi)
hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
}
 
-   /* Enable color space conversion if needed (for HDMI sinks only). */
-   if (hdmi->sink_is_hdmi && is_color_space_conversion(hdmi))
+   /* Enable color space conversion if needed */
+   if (is_color_space_conversion(hdmi))
hdmi_writeb(hdmi, HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH,
HDMI_MC_FLOWCTRL);
else
-- 
Regards,

Laurent Pinchart

[PATCH v5 01/10] drm: bridge: dw-hdmi: Remove unused functions

[Laurent Pinchart]

Most of the hdmi_phy_test_*() functions are unused. Remove them.

Signed-off-by: Laurent Pinchart 
Tested-by: Neil Armstrong 
Reviewed-by: Jose Abreu 
Tested-by: Nickey Yang 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 26 --
 1 file changed, 26 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 9a9ec27d9e28..ce7496399ccf 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -837,32 +837,6 @@ static inline void hdmi_phy_test_clear(struct dw_hdmi 
*hdmi,
  HDMI_PHY_TST0_TSTCLR_MASK, HDMI_PHY_TST0);
 }
 
-static inline void hdmi_phy_test_enable(struct dw_hdmi *hdmi,
-   unsigned char bit)
-{
-   hdmi_modb(hdmi, bit << HDMI_PHY_TST0_TSTEN_OFFSET,
- HDMI_PHY_TST0_TSTEN_MASK, HDMI_PHY_TST0);
-}
-
-static inline void hdmi_phy_test_clock(struct dw_hdmi *hdmi,
-  unsigned char bit)
-{
-   hdmi_modb(hdmi, bit << HDMI_PHY_TST0_TSTCLK_OFFSET,
- HDMI_PHY_TST0_TSTCLK_MASK, HDMI_PHY_TST0);
-}
-
-static inline void hdmi_phy_test_din(struct dw_hdmi *hdmi,
-unsigned char bit)
-{
-   hdmi_writeb(hdmi, bit, HDMI_PHY_TST1);
-}
-
-static inline void hdmi_phy_test_dout(struct dw_hdmi *hdmi,
- unsigned char bit)
-{
-   hdmi_writeb(hdmi, bit, HDMI_PHY_TST2);
-}
-
 static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, int msec)
 {
u32 val;
-- 
Regards,

Laurent Pinchart

[PATCH v5 04/10] drm: bridge: dw-hdmi: Fix the PHY power down sequence

[Laurent Pinchart]

The PHY requires us to wait for the PHY to switch to low power mode
after deasserting TXPWRON and before asserting PDDQ in the power down
sequence, otherwise power down will fail.

The PHY power down can be monitored though the TX_READY bit, available
through I2C in the PHY registers, or the TX_PHY_LOCK bit, available
through the HDMI TX registers. As the two are equivalent, let's pick the
easier solution of polling the TX_PHY_LOCK bit.

The power down code is currently duplicated in multiple places. To avoid
spreading multiple calls to a TX_PHY_LOCK poll function, we have to
refactor the power down code and group it all in a single function.

Tests showed that one poll iteration was enough for TX_PHY_LOCK to
become low, without requiring any additional delay. Retrying the read
five times with a 1ms to 2ms delay between each attempt should thus be
more than enough.

Signed-off-by: Laurent Pinchart 
Tested-by: Neil Armstrong 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 52 +---
 1 file changed, 43 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index d863b3393aee..85348ba6bb1c 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -116,6 +116,7 @@ struct dw_hdmi_i2c {
 struct dw_hdmi_phy_data {
enum dw_hdmi_phy_type type;
const char *name;
+   unsigned int gen;
bool has_svsret;
 };
 
@@ -914,6 +915,40 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
 }
 
+static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
+{
+   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
+   unsigned int i;
+   u16 val;
+
+   if (phy->gen == 1) {
+   dw_hdmi_phy_enable_tmds(hdmi, 0);
+   dw_hdmi_phy_enable_powerdown(hdmi, true);
+   return;
+   }
+
+   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+
+   /*
+* Wait for TX_PHY_LOCK to be deasserted to indicate that the PHY went
+* to low power mode.
+*/
+   for (i = 0; i < 5; ++i) {
+   val = hdmi_readb(hdmi, HDMI_PHY_STAT0);
+   if (!(val & HDMI_PHY_TX_PHY_LOCK))
+   break;
+
+   usleep_range(1000, 2000);
+   }
+
+   if (val & HDMI_PHY_TX_PHY_LOCK)
+   dev_warn(hdmi->dev, "PHY failed to power down\n");
+   else
+   dev_dbg(hdmi->dev, "PHY powered down in %u iterations\n", i);
+
+   dw_hdmi_phy_gen2_pddq(hdmi, 1);
+}
+
 static int hdmi_phy_configure(struct dw_hdmi *hdmi)
 {
u8 val, msec;
@@ -946,11 +981,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
return -EINVAL;
}
 
-   /* gen2 tx power off */
-   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
-
-   /* gen2 pddq */
-   dw_hdmi_phy_gen2_pddq(hdmi, 1);
+   dw_hdmi_phy_power_off(hdmi);
 
/* Leave low power consumption mode by asserting SVSRET. */
if (hdmi->phy->has_svsret)
@@ -1025,8 +1056,6 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
for (i = 0; i < 2; i++) {
dw_hdmi_phy_sel_data_en_pol(hdmi, 1);
dw_hdmi_phy_sel_interface_control(hdmi, 0);
-   dw_hdmi_phy_enable_tmds(hdmi, 0);
-   dw_hdmi_phy_enable_powerdown(hdmi, true);
 
ret = hdmi_phy_configure(hdmi);
if (ret)
@@ -1256,8 +1285,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
if (!hdmi->phy_enabled)
return;
 
-   dw_hdmi_phy_enable_tmds(hdmi, 0);
-   dw_hdmi_phy_enable_powerdown(hdmi, true);
+   dw_hdmi_phy_power_off(hdmi);
 
hdmi->phy_enabled = false;
 }
@@ -1827,23 +1855,29 @@ static const struct dw_hdmi_phy_data dw_hdmi_phys[] = {
{
.type = DW_HDMI_PHY_DWC_HDMI_TX_PHY,
.name = "DWC HDMI TX PHY",
+   .gen = 1,
}, {
.type = DW_HDMI_PHY_DWC_MHL_PHY_HEAC,
.name = "DWC MHL PHY + HEAC PHY",
+   .gen = 2,
.has_svsret = true,
}, {
.type = DW_HDMI_PHY_DWC_MHL_PHY,
.name = "DWC MHL PHY",
+   .gen = 2,
.has_svsret = true,
}, {
.type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY_HEAC,
.name = "DWC HDMI 3D TX PHY + HEAC PHY",
+   .gen = 2,
}, {
.type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY,
.name = "DWC HDMI 3D TX PHY",
+   .gen = 2,
}, {
.type = DW_HDMI_PHY_DWC_HDMI20_TX_PHY,
.name = "DWC HDMI 2.0 TX PHY",
+   .gen = 2,
.has_svsret = true,
}
 };
-- 
Regards,

Laurent Pinchart

[PATCH v5 06/10] drm: bridge: dw-hdmi: Create PHY operations

[Laurent Pinchart]

The HDMI TX controller support different PHYs whose programming
interface can vary significantly, especially with vendor PHYs that are
not provided by Synopsys. To support them, create a PHY operation
structure that can be provided by the platform glue layer. The existing
PHY handling code (limited to Synopsys PHY support) is refactored into a
set of default PHY operations that are used automatically when the
platform glue doesn't provide its own operations.

Signed-off-by: Laurent Pinchart 
Tested-by: Neil Armstrong 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 91 
 include/drm/bridge/dw_hdmi.h | 18 +++-
 2 files changed, 80 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 0aa3ad404f77..cb2703862be2 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -141,8 +141,12 @@ struct dw_hdmi {
u8 edid[HDMI_EDID_LEN];
bool cable_plugin;
 
-   const struct dw_hdmi_phy_data *phy;
-   bool phy_enabled;
+   struct {
+   const struct dw_hdmi_phy_ops *ops;
+   const char *name;
+   void *data;
+   bool enabled;
+   } phy;
 
struct drm_display_mode previous_mode;
 
@@ -831,6 +835,10 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi)
  HDMI_VP_CONF);
 }
 
+/* 
-
+ * Synopsys PHY Handling
+ */
+
 static inline void hdmi_phy_test_clear(struct dw_hdmi *hdmi,
   unsigned char bit)
 {
@@ -987,6 +995,7 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
 
 static int hdmi_phy_configure(struct dw_hdmi *hdmi)
 {
+   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
@@ -1019,7 +1028,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
dw_hdmi_phy_power_off(hdmi);
 
/* Leave low power consumption mode by asserting SVSRET. */
-   if (hdmi->phy->has_svsret)
+   if (phy->has_svsret)
dw_hdmi_phy_enable_svsret(hdmi, 1);
 
/* PHY reset. The reset signal is active high on Gen2 PHYs. */
@@ -1057,7 +1066,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
return dw_hdmi_phy_power_on(hdmi);
 }
 
-static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
+static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void *data,
+   struct drm_display_mode *mode)
 {
int i, ret;
 
@@ -1071,10 +1081,31 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
return ret;
}
 
-   hdmi->phy_enabled = true;
return 0;
 }
 
+static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, void *data)
+{
+   dw_hdmi_phy_power_off(hdmi);
+}
+
+static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+ void *data)
+{
+   return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
+   connector_status_connected : connector_status_disconnected;
+}
+
+static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
+   .init = dw_hdmi_phy_init,
+   .disable = dw_hdmi_phy_disable,
+   .read_hpd = dw_hdmi_phy_read_hpd,
+};
+
+/* 
-
+ * HDMI TX Setup
+ */
+
 static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
 {
u8 de;
@@ -1289,16 +1320,6 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
hdmi_writeb(hdmi, vsync_len, HDMI_FC_VSYNCINWIDTH);
 }
 
-static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
-{
-   if (!hdmi->phy_enabled)
-   return;
-
-   dw_hdmi_phy_power_off(hdmi);
-
-   hdmi->phy_enabled = false;
-}
-
 /* HDMI Initialization Step B.4 */
 static void dw_hdmi_enable_video_path(struct dw_hdmi *hdmi)
 {
@@ -1431,9 +1452,10 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
hdmi_av_composer(hdmi, mode);
 
/* HDMI Initializateion Step B.2 */
-   ret = dw_hdmi_phy_init(hdmi);
+   ret = hdmi->phy.ops->init(hdmi, hdmi->phy.data, >previous_mode);
if (ret)
return ret;
+   hdmi->phy.enabled = true;
 
/* HDMI Initialization Step B.3 */
dw_hdmi_enable_video_path(hdmi);
@@ -1548,7 +1570,11 @@ static void dw_hdmi_poweron(struct dw_hdmi *hdmi)
 
 static void dw_hdmi_poweroff(struct dw_hdmi *hdmi)
 {
-   dw_hdmi_phy_disable(hdmi);
+   if (hdmi->phy.enabled) {
+   hdmi->phy.ops->disable(hdmi, hdmi->phy.data);
+   

[PATCH v5 07/10] drm: bridge: dw-hdmi: Add support for custom PHY configuration

[Laurent Pinchart]

From: Kieran Bingham 

The DWC HDMI TX controller interfaces with a companion PHY. While
Synopsys provides multiple standard PHYs, SoC vendors can also integrate
a custom PHY.

Modularize PHY configuration to support vendor PHYs through platform
data. The existing PHY configuration code was originally written to
support the DWC HDMI 3D TX PHY, and seems to be compatible with the DWC
MLP PHY. The HDMI 2.0 PHY will require a separate configuration
function.

Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
Tested-by: Neil Armstrong 
Reviewed-by: Jose Abreu 
---
Changes since v1:

- Check pdata->phy_configure in hdmi_phy_configure() to avoid
  dereferencing NULL pointer.
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 109 ++-
 include/drm/bridge/dw_hdmi.h |   7 +++
 2 files changed, 81 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index cb2703862be2..b835d81bb471 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -118,6 +118,9 @@ struct dw_hdmi_phy_data {
const char *name;
unsigned int gen;
bool has_svsret;
+   int (*configure)(struct dw_hdmi *hdmi,
+const struct dw_hdmi_plat_data *pdata,
+unsigned long mpixelclock);
 };
 
 struct dw_hdmi {
@@ -860,8 +863,8 @@ static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, 
int msec)
return true;
 }
 
-static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
-unsigned char addr)
+void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
+  unsigned char addr)
 {
hdmi_writeb(hdmi, 0xFF, HDMI_IH_I2CMPHY_STAT0);
hdmi_writeb(hdmi, addr, HDMI_PHY_I2CM_ADDRESS_ADDR);
@@ -873,6 +876,7 @@ static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi, 
unsigned short data,
HDMI_PHY_I2CM_OPERATION_ADDR);
hdmi_phy_wait_i2c_done(hdmi, 1000);
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
 
 static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
 {
@@ -993,37 +997,67 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
return 0;
 }
 
-static int hdmi_phy_configure(struct dw_hdmi *hdmi)
+/*
+ * PHY configuration function for the DWC HDMI 3D TX PHY. Based on the 
available
+ * information the DWC MHL PHY has the same register layout and is thus also
+ * supported by this function.
+ */
+static int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,
+   const struct dw_hdmi_plat_data *pdata,
+   unsigned long mpixelclock)
 {
-   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
-   const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
 
/* PLL/MPLL Cfg - always match on final entry */
for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   mpll_config->mpixelclock)
+   if (mpixelclock <= mpll_config->mpixelclock)
break;
 
for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   curr_ctrl->mpixelclock)
+   if (mpixelclock <= curr_ctrl->mpixelclock)
break;
 
for (; phy_config->mpixelclock != ~0UL; phy_config++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   phy_config->mpixelclock)
+   if (mpixelclock <= phy_config->mpixelclock)
break;
 
if (mpll_config->mpixelclock == ~0UL ||
curr_ctrl->mpixelclock == ~0UL ||
-   phy_config->mpixelclock == ~0UL) {
-   dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
-   hdmi->hdmi_data.video_mode.mpixelclock);
+   phy_config->mpixelclock == ~0UL)
return -EINVAL;
-   }
+
+   dw_hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce,
+ HDMI_3D_TX_PHY_CPCE_CTRL);
+   dw_hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp,
+ HDMI_3D_TX_PHY_GMPCTRL);
+   dw_hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0],
+ HDMI_3D_TX_PHY_CURRCTRL);
+
+   dw_hdmi_phy_i2c_write(hdmi, 0, HDMI_3D_TX_PHY_PLLPHBYCTRL);
+   dw_hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_MSM_CTRL_CKO_SEL_FB_CLK,
+ HDMI_3D_TX_PHY_MSM_CTRL);
+
+   

[PATCH v5 05/10] drm: bridge: dw-hdmi: Fix the PHY power up sequence

[Laurent Pinchart]

When powering the PHY up we need to wait for the PLL to lock. This is
done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register
(interrupt-based wait could be implemented as well but is likely
overkill). The bit is asserted when the PLL locks, but the current code
incorrectly waits for the bit to be deasserted. Fix it, and while at it,
replace the udelay() with a sleep as the code never runs in
non-sleepable context.

To be consistent with the power down implementation move the poll loop
to the power off function.

Signed-off-by: Laurent Pinchart 
Tested-by: Neil Armstrong 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 65 +++-
 1 file changed, 37 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 85348ba6bb1c..0aa3ad404f77 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -949,9 +949,44 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
dw_hdmi_phy_gen2_pddq(hdmi, 1);
 }
 
+static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
+{
+   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
+   unsigned int i;
+   u8 val;
+
+   if (phy->gen == 1) {
+   dw_hdmi_phy_enable_powerdown(hdmi, false);
+
+   /* Toggle TMDS enable. */
+   dw_hdmi_phy_enable_tmds(hdmi, 0);
+   dw_hdmi_phy_enable_tmds(hdmi, 1);
+   return 0;
+   }
+
+   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
+   dw_hdmi_phy_gen2_pddq(hdmi, 0);
+
+   /* Wait for PHY PLL lock */
+   for (i = 0; i < 5; ++i) {
+   val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
+   if (val)
+   break;
+
+   usleep_range(1000, 2000);
+   }
+
+   if (!val) {
+   dev_err(hdmi->dev, "PHY PLL failed to lock\n");
+   return -ETIMEDOUT;
+   }
+
+   dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);
+   return 0;
+}
+
 static int hdmi_phy_configure(struct dw_hdmi *hdmi)
 {
-   u8 val, msec;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
@@ -1019,33 +1054,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_CKCALCTRL_OVERRIDE,
   HDMI_3D_TX_PHY_CKCALCTRL);
 
-   dw_hdmi_phy_enable_powerdown(hdmi, false);
-
-   /* toggle TMDS enable */
-   dw_hdmi_phy_enable_tmds(hdmi, 0);
-   dw_hdmi_phy_enable_tmds(hdmi, 1);
-
-   /* gen2 tx power on */
-   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
-   dw_hdmi_phy_gen2_pddq(hdmi, 0);
-
-   /* Wait for PHY PLL lock */
-   msec = 5;
-   do {
-   val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
-   if (!val)
-   break;
-
-   if (msec == 0) {
-   dev_err(hdmi->dev, "PHY PLL not locked\n");
-   return -ETIMEDOUT;
-   }
-
-   udelay(1000);
-   msec--;
-   } while (1);
-
-   return 0;
+   return dw_hdmi_phy_power_on(hdmi);
 }
 
 static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
-- 
Regards,

Laurent Pinchart

Re: [PATCH v4 7/9] drm: bridge: dw-hdmi: Add support for custom PHY configuration

[Jose Abreu]

Hi Laurent,


On 02-03-2017 15:38, Laurent Pinchart wrote:
> Hi Jose,
>
> On Thursday 02 Mar 2017 14:50:02 Jose Abreu wrote:
>> On 02-03-2017 13:41, Laurent Pinchart wrote:
 Hmm, this is kind of confusing. Why do you need a phy_ops and
 then a separate configure_phy function? Can't we just use phy_ops
 always? If its external phy then it would need to implement all
 phy_ops functions.
>>> The phy_ops are indeed meant to support vendor PHYs. The .configure_phy()
>>> operation is meant to support Synopsys PHYs that don't comply with the
>>> HDMI TX MHL and 3D PHYs I2C register layout and thus need a different
>>> configure function, but can share the other operations with the HDMI TX
>>> MHL and 3D PHYs. Ideally I'd like to move that code to the dw-hdmi core,
>>> but at the moment I don't have enough information to decide whether the
>>> register layout corresponds to the standard Synopsys HDMI TX 2.0 PHY or
>>> if it has been modified by the vendor. Once we'll have a second SoC using
>>> the same PHY we should have more information to consolidate the code. Of
>>> course, if you can share the HDMI TX 2.0 PHY datasheet, I won't mind
>>> reworking the code now ;-)
>> Well, if I want to keep my job I can't share the datasheet, and I
>> do want to keep my job :)
> That's so selfish :-D
>
>> As far as I know this shouldn't change much. I already used (it
>> was like a year ago) the dw-hdmi driver in a HDMI TX 2.0 PHY.
> I really wonder what exactly has been integrated in the Renesas R-Car Gen3 
> SoC. The PHY is certainly reported as an HDMI TX 2.0 PHY, but the registers 
> seem different compared to the 2.0 PHY you've tested.
>
>> But I am not following your logic here, sorry: You are mentioning a
>> custom phy, right?
> Custom is probably a bad name. From what I've been told it's a standard 
> Synopsys PHY, but I can't rule out vendor-specific customizations.
>
>> If its custom then it should implement its own phy_ops. And I don't think
>> that phy logic should go into core, this should all be extracted because I
>> really believe it will make the code easier to read. Imagine this
>> organization:
>>
>> Folders/Files:
>> drm/bridge/dw-hdmi/dw-hdmi-core.c
>> drm/bridge/dw-hdmi/dw-hdmi-phy-synopsys.c
>> drm/bridge/dw-hdmi/dw-hdmi-phy-*renesas*.c
>> drm/bridge/dw-hdmi/dw-hdmi-phy-something.c
>> Structures:
>> dw_hdmi_pdata
>> dw_hdmi_phy_pdata
>> dw_hdmi_phy_ops
> That looks good to me.
>
>> As the phy is interacted using controller we would need to pass
>> some callbacks to the phy, but ultimately the phy would be a
>> platform driver which could have its own compatible string that
>> would be associated with controller (not sure exactly about this
>> because I only used this in non-dt).
> We already have glue code, having to provide separate glue and PHY drivers 
> seems a bit overkill to me. If we could get rid of glue code by adding a node 
> for the PHY in DT that would be nice, but if we have to keep the glue then we 
> can as well use platform data there.
>
>> This is just an idea though. I followed this logic in the RX side
>> and its very easy to add a new phy now, its a matter of creating
>> a new file, implement ops and associate it with controller. Of
>> course some phys will be very similar, for that we can use minor
>> tweaks via id detection.
>>
>> What do you think?
> It sounds neat overall, but I wonder whether it should really block this 
> series, or be added on top of it :-) I think we're already moving in the 
> right 
> direction here.
>

This series is definitely a good starting point and a good
improvement. We can think later about abstracting even more the
phy from the controller. I think this will be a major step and
will reflect better how the HW is modeled.

You can add my reviewed-by in all the patches in this series in
your next submission (or in the merge).

Also, if you do a next submission what do you think about moving
all the dw-hdmi files to a new folder called for example
'synopsys' or 'dw-hdmi'? Because we already have 5 files. I think
'synopsys' instead of 'dw-hdmi' would be better because in the
future we may add support for other protocols (for example
display port).

Side note: I think you missed in the cc Archit Taneja

Best regards,
Jose Miguel Abreu

Re: [PATCH] dt-bindings: drm: rcar-du: Document optional reset properties

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Friday 03 Mar 2017 14:30:35 Geert Uytterhoeven wrote:
> Document the optional properties for describing module resets, to
> support resetting display channels and LVDS encoders on R-Car Gen2 and
> Gen3.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/devicetree/bindings/display/renesas,du.txt | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
> b/Documentation/devicetree/bindings/display/renesas,du.txt index
> 1a02f099a0ff0a3a..7873d53764a297c2 100644
> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -36,6 +36,16 @@ Required Properties:
>When supplied they must be named "dclkin.x" with "x" being the input
>clock numerical index.
> 
> +Optional properties:
> +  - resets: A list of phandles + reset-specifier pairs, one for each entry
> in

s/phandlers/phandle/

> +the reset-names property.

What's in the reset specifier ?

> +  - reset-names: Names of the resets. This property is model-dependent.
> +- R8A779[0123456] use one reset for a group of one or more successive
> +  channels, and one reset per LVDS encoder (if available). The resets
> +  must be named "du.x" with "x" being the numerical index of the lowest
> +  channel in the group. The LVDS resets must be named "lvds.x" with
> "x" +  being the LVDS encoder numerical index.
> +
>  Required nodes:
> 
>  The connections to the DU output video ports are modeled using the OF graph

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm: rcar-du: Make sure DRM planes are created by VSP1

[Laurent Pinchart]

Hi Jacopo,

On Friday 03 Mar 2017 13:37:56 jacopo mondi wrote:
> On 03/03/2017 12:26, Laurent Pinchart wrote:
> > On Friday 03 Mar 2017 09:09:38 Jacopo Mondi wrote:
> >> On Gen3 platforms compositing planes are allocated  by VSP on behalf of
> >> DRM/KMS. If VSP support is not compiled in, vsp1 initialization stub
> >> routine is called, leading to invalid memory accesses later on when un-
> >> initialized planes are accessed.
> >> 
> >> Fail explicitly earlier if planes are not properly created.
> >> 
> >> Signed-off-by: Jacopo Mondi 
> >> ---
> >> 
> >>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >> 
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index b5d3f16..7f56c09 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >> @@ -616,6 +616,9 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> >>ret = rcar_du_vsp_init(vsp);
> >>if (ret < 0)
> >>return ret;
> >> +
> >> +  if (!vsp->planes)
> >> +  return -EINVAL;
> > 
> > Given that this code is only called when the DU hardware requires the VSP
> > to operate, how about modifying the rcar_du_vsp_init() stub function to
> > return - ENXIO instead of 0 ? That way you won't need to add an
> > additional check here.
>
> Ok, I'll make sure it is only called there also.
> 
> > Ideally we should require VSP through Kconfig as well. If you feel like
> > submitting a patch (and testing it with various combinations of module and
> > built-in) it would be appreciated.
> 
> That would be ideal.
> Am I wrong or the condition that selects DRM_RCAR_VSP is (DRM_RCAR_DU &&
> Gen3-platform)? Implying that on Gen2 DU can live without VSP enabled?

That's correct. On Gen2 VSP isn't required to operate the display.

> >>}
> >>
> >>}

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm: rcar-du: Make sure planes are created by VSP

[Laurent Pinchart]

Hi Jacopo,

Thank you for the patch.

On Friday 03 Mar 2017 13:58:56 Jacopo Mondi wrote:
> On Gen3 platforms compositing planes are allocated  by VSP on behalf of
> DRM/KMS.
> If VSP support is not compiled in, vsp initialization stub routine is
> called. Return an error from that stub to fail explicitly, otherwise
> accessing planes leads to invalid memory errors.

I'll rephrase this to talk about "VSP compositor support in the DU driver", as 
"VSP support" is ambiguous and could mean the VSP driver. Apart from that,

Reviewed-by: Laurent Pinchart 

No need to resubmit, I'll fix the commit message when applying.

> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h index 510dcc9..f1d0f18 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> @@ -68,7 +68,7 @@ void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
>  void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
>  void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
>  #else
> -static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp) { return 0; };
> +static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp) { return
> -ENXIO; }; static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
> { }; static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
> static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };

-- 
Regards,

Laurent Pinchart

[PATCH] drm: rcar-du: Make sure planes are created by VSP

[Jacopo Mondi]

On Gen3 platforms compositing planes are allocated  by VSP on behalf of
DRM/KMS.
If VSP support is not compiled in, vsp initialization stub routine is
called. Return an error from that stub to fail explicitly, otherwise
accessing planes leads to invalid memory errors.

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index 510dcc9..f1d0f18 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -68,7 +68,7 @@ void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
 void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
 void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
 #else
-static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp) { return 0; };
+static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp) { return -ENXIO; };
 static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
 static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
 static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
-- 
2.7.4

[PATCH] dt-bindings: drm: rcar-du: Document optional reset properties

[Geert Uytterhoeven]

Document the optional properties for describing module resets, to
support resetting display channels and LVDS encoders on R-Car Gen2 and
Gen3.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/display/renesas,du.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
b/Documentation/devicetree/bindings/display/renesas,du.txt
index 1a02f099a0ff0a3a..7873d53764a297c2 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -36,6 +36,16 @@ Required Properties:
   When supplied they must be named "dclkin.x" with "x" being the input
   clock numerical index.
 
+Optional properties:
+  - resets: A list of phandles + reset-specifier pairs, one for each entry in
+the reset-names property.
+  - reset-names: Names of the resets. This property is model-dependent.
+- R8A779[0123456] use one reset for a group of one or more successive
+  channels, and one reset per LVDS encoder (if available). The resets
+  must be named "du.x" with "x" being the numerical index of the lowest
+  channel in the group. The LVDS resets must be named "lvds.x" with "x"
+  being the LVDS encoder numerical index.
+
 Required nodes:
 
 The connections to the DU output video ports are modeled using the OF graph
-- 
2.7.4

Re: [PATCH] drm: rcar-du: Make sure DRM planes are created by VSP1

[jacopo mondi]

HI Laurent,

On 03/03/2017 12:26, Laurent Pinchart wrote:

Hi Jacopo,

Thank you for the patch.

On Friday 03 Mar 2017 09:09:38 Jacopo Mondi wrote:

On Gen3 platforms compositing planes are allocated  by VSP on behalf of
DRM/KMS.
If VSP support is not compiled in, vsp1 initialization stub routine is
called, leading to invalid memory accesses later on when un-initialized
planes are accessed.

Fail explicitly earlier if planes are not properly created.

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index b5d3f16..7f56c09 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -616,6 +616,9 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
ret = rcar_du_vsp_init(vsp);
if (ret < 0)
return ret;
+
+   if (!vsp->planes)
+   return -EINVAL;


Given that this code is only called when the DU hardware requires the VSP to
operate, how about modifying the rcar_du_vsp_init() stub function to return -
ENXIO instead of 0 ? That way you won't need to add an additional check here.



Ok, I'll make sure it is only called there also.


Ideally we should require VSP through Kconfig as well. If you feel like
submitting a patch (and testing it with various combinations of module and
built-in) it would be appreciated.


That would be ideal.
Am I wrong or the condition that selects DRM_RCAR_VSP is (DRM_RCAR_DU && 
Gen3-platform)? Implying that on Gen2 DU can live without VSP enabled?


Thanks
   j





}
}

[PATCH 1/2] arm64: dts: r8a7795: Remove unit-addresses and regs from integrated caches

[Geert Uytterhoeven]

The Cortex-A57/A53 cache controllers are integrated controllers, and
thus the device nodes representing them should not have unit-addresses
or reg properties.

Fixes: 6f7bf82cc912441f ("arm64: dts: r8a7795: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 13833aa8e035be04..67a8d2a4c9b568cc 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -110,17 +110,15 @@
enable-method = "psci";
};
 
-   L2_CA57: cache-controller@0 {
+   L2_CA57: cache-controller-0 {
compatible = "cache";
-   reg = <0>;
power-domains = < R8A7795_PD_CA57_SCU>;
cache-unified;
cache-level = <2>;
};
 
-   L2_CA53: cache-controller@100 {
+   L2_CA53: cache-controller-1 {
compatible = "cache";
-   reg = <0x100>;
power-domains = < R8A7795_PD_CA53_SCU>;
cache-unified;
cache-level = <2>;
-- 
2.7.4

[PATCH 2/2] arm64: dts: r8a7796: Remove unit-address and reg from integrated cache

[Geert Uytterhoeven]

The Cortex-A57 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.

Fixes: 1561f20760ec96db ("arm64: dts: r8a7796: Add Renesas R8A7796 SoC support")
Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index f02dfdce92406f67..b950dcec9ace96a1 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -48,9 +48,8 @@
enable-method = "psci";
};
 
-   L2_CA57: cache-controller@0 {
+   L2_CA57: cache-controller-0 {
compatible = "cache";
-   reg = <0>;
power-domains = < R8A7796_PD_CA57_SCU>;
cache-unified;
cache-level = <2>;
-- 
2.7.4

[PATCH 0/2] arm64: dts: renesas: Remove unit-addresses and regs from integrated caches

[Geert Uytterhoeven]

Hi Simon, Magnus,

This patch series removes the bogus unit-addresses and reg properties
from the device nodes representing Cortex-A57/A53 cache controllers.

Note that the latter were added to remove warnings from dtc when using
W=1:

Warning (unit_address_vs_reg): Node /cache-controller@0 has a unit name, 
but no reg property

In hindsight, adding the reg properties turned out to be the wrong fix.
Indeed, the Cortex-A57/A53 cache controllers are integrated controllers,
and thus the device nodes representing them should not have
unit-addresses or reg properties.

This series does not have a runtime effect, as Linux doesn't rely much
on the properties of the cache-controller nodes.

After this patch has been accepted, I'll submit a similar series to fix
the DTS files for the Renesas arm32 SoCs.

Thanks for applying!

Geert Uytterhoeven (2):
  arm64: dts: r8a7795: Remove unit-addresses and regs from integrated
caches
  arm64: dts: r8a7796: Remove unit-address and reg from integrated cache

 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 ++
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 3 +--
 2 files changed, 3 insertions(+), 6 deletions(-)

-- 
2.7.4

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] media: platform: Renesas IMR driver

[Sergei Shtylyov]

On 03/03/2017 02:58 PM, Geert Uytterhoeven wrote:


+  - "renesas,imr-lx4-v3m" for R-Car V3M.



"renesas,-EPROBE_DEFER-imr-lx4"



   Huh? :-)


Do you know the part number of V3M?


   No, but using the names from the manual I don't need it.


Gr{oetje,eeting}s,

Geert


MBR, Sergei

Re: [PATCH] media: platform: Renesas IMR driver

[Geert Uytterhoeven]

On Fri, Mar 3, 2017 at 12:56 PM, Sergei Shtylyov
 wrote:
>>> +  - "renesas,imr-lx4-v3m" for R-Car V3M.
>>
>>
>> "renesas,-EPROBE_DEFER-imr-lx4"
>
>
>Huh? :-)

Do you know the part number of V3M?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Hello!

On 03/03/2017 02:24 PM, Geert Uytterhoeven wrote:


--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt



+- compatible: "renesas,imr-lx4-", "renesas,imr-lx4" as a fallback for


"renesas,-imr-lx4"


+  the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs,
+  where the examples with  are:
+  - "renesas,imr-lx4-h3" for R-Car H3,


"renesas,r8a7795-imr-lx4"


   The IMR core names were copied from the manual verbatim (just in lower case).


+  - "renesas,imr-lx4-m3-w" for R-Car M3-W,


"renesas,r8a7796-imr-lx4"


+  - "renesas,imr-lx4-v3m" for R-Car V3M.


"renesas,-EPROBE_DEFER-imr-lx4"


   Huh? :-)


Gr{oetje,eeting}s,

Geert


MBR, Sergei

Re: [PATCH v2 3/3] arm64: renesas: r8a7796: Enable SCIF DMA

[Geert Uytterhoeven]

Hi Simon,

On Thu, Mar 2, 2017 at 3:36 PM, Simon Horman  wrote:
> On Tue, Feb 21, 2017 at 03:27:25PM +0100, Geert Uytterhoeven wrote:
>> On Wed, Dec 7, 2016 at 5:44 PM, Ulrich Hecht
>>  wrote:
>> > Signed-off-by: Ulrich Hecht 
>> > ---
>> >  arch/arm64/boot/dts/renesas/r8a7796.dtsi | 13 +
>> >  1 file changed, 13 insertions(+)
>> >
>> > diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
>> > b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
>> > index c5f0df5..782063a 100644
>> > --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
>> > +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
>> > @@ -430,6 +430,9 @@
>> >  < CPG_CORE R8A7796_CLK_S3D1>,
>> >  <_clk>;
>> > clock-names = "fck", "brg_int", "scif_clk";
>> > +   dmas = < 0x51>, < 0x50>,
>> > +  < 0x51>, < 0x50>;
>> > +   dma-names = "tx", "rx", "tx", "rx";
>> > power-domains = < R8A7796_PD_ALWAYS_ON>;
>> > status = "disabled";
>>
>> Apparently the DMA properties were added to the HSCIF nodes instead
>> of the SCIF nodes while applying this patch?
>>
>> 3 lines of context is not sufficient to distinguish between the various SCIF
>> and HSCIF nodes :-(
>
> Thanks, I have updated renesas-devel accordingly.
>
> I notice in renesas-devel there seems to be one "tx", "rx" DMA per SCIF
> rather than two added in Ulrich's patch. Is there a reason for that?

You mean renesas-drivers?

Oops, looks like I cherry-picked an older version of the patch, and failed to
notice after reverting your wrong version
(perhaps the final version was never part of a pull request from Uli?).

BTW, your version  is wrong, too: the second pair of DMA channels
should point to dmac2, not dmac1, e.g.:

  scif0: serial@e6e6 {
  compatible = "renesas,scif-r8a7796",
   "renesas,rcar-gen3-scif", "renesas,scif";
  reg = <0 0xe6e6 0 64>;
  interrupts = ;
  clocks = < CPG_MOD 207>,
   < CPG_CORE R8A7796_CLK_S3D1>,
   <_clk>;
  clock-names = "fck", "brg_int", "scif_clk";
  +   dmas = < 0x51>, < 0x50>,
- +  < 0x51>, < 0x50>;
+ +  < 0x51>, < 0x50>;

  +   dma-names = "tx", "rx", "tx", "rx";
  power-domains = < R8A7796_PD_ALWAYS_ON>;
  status = "disabled";
  };

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] phy: core: fix the condition to enable pm_runtime in phy_create()

[Yoshihiro Shimoda]

This patch fixes an issue that phy_create() never enables the pm_runtime.
And then, we can remove calling the pm_runtime_{en,dis}able from some
phy drivers.

Fixes: ff764963479a ("drivers: phy: add generic PHY framework")
Cc: sta...@vger.kernel.org # v3.13+
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/phy/phy-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index a268f4d..17e350f 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -759,7 +759,7 @@ struct phy *phy_create(struct device *dev, struct 
device_node *node,
if (ret)
goto put_dev;
 
-   if (pm_runtime_enabled(dev)) {
+   if (!pm_runtime_enabled(dev)) {
pm_runtime_enable(>dev);
pm_runtime_no_callbacks(>dev);
}
-- 
1.9.1

Re: [RFC PATCH 3/3] drm: rcar-du: Register a completion callback with VSP1

[Kieran Bingham]

Hi Laurent,

On 03/03/17 02:17, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Wednesday 01 Mar 2017 13:12:56 Kieran Bingham wrote:
>> Updating the state in a running VSP1 requires two interrupts from the
>> VSP. Initially, the updated state will be committed - but only after the
>> VSP1 has completed processing it's current frame will the new state be
>> taken into account. As such, the committed state will only be 'completed'
>> after an extra frame completion interrupt.
>>
>> Track this delay, by passing the frame flip event through the VSP
>> module; It will be returned only when the frame has completed and can be
>> returned to the caller.
> 
> I'll check the interrupt sequence logic tomorrow, it's a bit too late now. 
> Please see below for additional comments.

No worries

> 
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  8 +-
>>  drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  1 +-
>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 34 ++-
>>  3 files changed, 41 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 7391dd95c733..0a824633a012
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>> @@ -328,7 +328,7 @@ static bool rcar_du_crtc_page_flip_pending(struct
>> rcar_du_crtc *rcrtc) bool pending;
>>
>>  spin_lock_irqsave(>event_lock, flags);
>> -pending = rcrtc->event != NULL;
>> +pending = (rcrtc->event != NULL) || (rcrtc->pending != NULL);
>>  spin_unlock_irqrestore(>event_lock, flags);
>>
>>  return pending;
>> @@ -578,6 +578,12 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
>> rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
>>
>>  if (status & DSSR_FRM) {
>> +
>> +if (rcrtc->pending) {
>> +trace_printk("VBlank loss due to VSP Overrun\n");
>> +return IRQ_HANDLED;
>> +}
>> +
>>  drm_crtc_handle_vblank(>crtc);
>>  rcar_du_crtc_finish_page_flip(rcrtc);
>>  ret = IRQ_HANDLED;
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h index a7194812997e..8374a858446a
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> @@ -46,6 +46,7 @@ struct rcar_du_crtc {
>>  bool started;
>>
>>  struct drm_pending_vblank_event *event;
>> +struct drm_pending_vblank_event *pending;
>>  wait_queue_head_t flip_wait;
>>
>>  unsigned int outputs;
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 71e70e1e0881..408375aff1a0
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> @@ -28,6 +28,26 @@
>>  #include "rcar_du_kms.h"
>>  #include "rcar_du_vsp.h"
>>
>> +static void rcar_du_vsp_complete(void *private, void *data)
>> +{
>> +struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;
>> +struct drm_device *dev = crtc->crtc.dev;
>> +struct drm_pending_vblank_event *event;
>> +bool match;
>> +unsigned long flags;
>> +
>> +spin_lock_irqsave(>event_lock, flags);
>> +event = crtc->event;
>> +crtc->event = data;
>> +match = (crtc->event == crtc->pending);
>> +crtc->pending = NULL;
>> +spin_unlock_irqrestore(>event_lock, flags);
>> +
>> +/* Safety checks */
>> +WARN(event, "Event lost by VSP completion callback\n");
>> +WARN(!match, "Stored pending event, does not match completion\n");
> 
> I understand you want to be safe, and I assume these have never been 
> triggered 
> in your tests. I'd rather replace them by a mechanism that doesn't require 
> passing the event to the VSP driver, and that wouldn't require adding a 
> pending field to the rcar_du_crtc structure. 

Ok - understandable, I started this way - but hit problems, which I think were
unrelated. Anyway, I switched to 'moving' the event so that I could be sure
rcar_du_crtc_finish_page_flip() couldn't have an event to send.

I can switch back to keeping it's 'ownership' in rcar-du.

> Wouldn't adding a WARN_ON(rcrtc-
>> event) in rcar_du_crtc_atomic_begin() in the if (crtc->state->event) block 
>> do 
> the job ?

Yes, that would :D - I put those in just to be sure things were going as
expected, and there weren't any code paths I hadn't considered. But I think they
are 'unreachable' warnings anyway (at least at the moment).



> Would this get in the way of your trace_printk() debugging in 
> rcar_du_crtc_irq() ? Could you implement the debugging in a separate patch 
> without requiring to pass the event to the VSP driver ?

Moving the event wasn't necessarily about trace_printk debugging, but perhaps it
was part of me debugging why I hadn't got things working correctly.

Moving the 

Re: [PATCH] drm: rcar-du: Make sure DRM planes are created by VSP1

[Laurent Pinchart]

Hi Jacopo,

Thank you for the patch.

On Friday 03 Mar 2017 09:09:38 Jacopo Mondi wrote:
> On Gen3 platforms compositing planes are allocated  by VSP on behalf of
> DRM/KMS.
> If VSP support is not compiled in, vsp1 initialization stub routine is
> called, leading to invalid memory accesses later on when un-initialized
> planes are accessed.
> 
> Fail explicitly earlier if planes are not properly created.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index b5d3f16..7f56c09 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -616,6 +616,9 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
>   ret = rcar_du_vsp_init(vsp);
>   if (ret < 0)
>   return ret;
> +
> + if (!vsp->planes)
> + return -EINVAL;

Given that this code is only called when the DU hardware requires the VSP to 
operate, how about modifying the rcar_du_vsp_init() stub function to return -
ENXIO instead of 0 ? That way you won't need to add an additional check here.

Ideally we should require VSP through Kconfig as well. If you feel like 
submitting a patch (and testing it with various combinations of module and 
built-in) it would be appreciated.

>   }
>   }

-- 
Regards,

Laurent Pinchart

Re: [PATCH] media: platform: Renesas IMR driver

[Geert Uytterhoeven]

Hi Sergei,

On Thu, Mar 2, 2017 at 10:00 PM, Sergei Shtylyov
 wrote:
> --- /dev/null
> +++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt

> +- compatible: "renesas,imr-lx4-", "renesas,imr-lx4" as a fallback 
> for

"renesas,-imr-lx4"

> +  the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs,
> +  where the examples with  are:
> +  - "renesas,imr-lx4-h3" for R-Car H3,

"renesas,r8a7795-imr-lx4"

> +  - "renesas,imr-lx4-m3-w" for R-Car M3-W,

"renesas,r8a7796-imr-lx4"

> +  - "renesas,imr-lx4-v3m" for R-Car V3M.

"renesas,-EPROBE_DEFER-imr-lx4"

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] media: platform: Renesas IMR driver

[Sergei Shtylyov]

From: Konstantin Kozhevnikov 

The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to any shape that is
split into triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer light
extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
can be added later...

[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts,  added the binding document, ported the driver to the
modern kernel, renamed the UAPI header file and the guard  macros to match
the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
help, made use of the BIT()/GENMASK() macros, sorted #include's, removed
leading  dots and fixed grammar in the comments, fixed up indentation to
use tabs where possible, renamed DLSR, CMRCR.DY1{0|2}, and ICR bits to
match the manual, changed the prefixes of the CMRCR[2]/TRI{M|C}R bits/
fields to match the manual, removed non-existent TRIMR.D{Y|U}D{X|V}M bits,
added/used the IMR bits, separated the register offset/bit #define's,
sorted the instruction macros by opcode, masked the register address in
WTL[2]/WTS instruction macros, avoided setting reserved bits when writing
to CMRCCR[2]/TRIMCR, used the SR bits instead of a bare number, removed
*inline* from .c file, fixed lines over 80 columns, removed useless parens,
operators, casts, braces, variables, #include's, statements, and even 1
function, inserted empty line after desclaration, removed extra empty
lines, reordered some local variable desclarations, removed calls to
4l2_err() on kmalloc() failure, fixed the error returned by imr_default(),
avoided code duplication in the IRQ handler, used '__packed' for the UAPI
structures, enclosed the macro parameters in parens, exchanged the values
of IMR_MAP_AUTO{S|D}G macros.]

Signed-off-by: Konstantin Kozhevnikov 

Signed-off-by: Sergei Shtylyov 

---
Changes in version 2:
- renamed the ICR bits to match the manual;
- added/used the IMR bits;
- changed the prefixes of the CMRCR[2]/TRI{M|C}R bits/fields to match the
  manual;
- renamed the CMRCR.DY1{0|2} bits to match the manual;
- removed non-existent TRIMR.D{Y|U}D{X|V}M bits;
- used the SR bits instead of a bare number;
- sorted the instruction macros by opcode, removing redundant parens;
- masked the register address in WTL[2]/WTS instruction macros;
- avoided setting reserved bits when writing to CMRCCR[2]/TRIMCR;
- mentioned the video capture data as a texture source in the binding and the
  patch description;
- documented the SoC specific "compatible" values;
- clarified the "interrupts" and "clocks" property text;
- updated the patch description.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   28 
 drivers/media/platform/Kconfig   |   13 
 drivers/media/platform/Makefile  |1 
 drivers/media/platform/rcar_imr.c| 1926 +++
 include/uapi/linux/rcar_imr.h|   94 
 5 files changed, 2062 insertions(+)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -0,0 +1,28 @@
+Renesas R-Car Image Renderer (Distortion Correction Engine)
+---
+
+The image renderer, or the distortion correction engine, is a drawing processor
+with a simple instruction system capable of referencing video capture data or
+data in an external memory as 2D texture data and performing texture mapping
+and drawing with respect to any shape that is split into triangular objects.
+
+Required properties:
+
+- compatible: "renesas,imr-lx4-", "renesas,imr-lx4" as a fallback for
+  the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs,
+  where the examples with  are:
+  - "renesas,imr-lx4-h3" for R-Car H3,
+  - "renesas,imr-lx4-m3-w" for R-Car M3-W,
+  - "renesas,imr-lx4-v3m" for R-Car V3M.
+- reg: offset and length of the register block;
+- interrupts: single interrupt specifier;
+- clocks: single clock phandle/specifier pair.
+
+Example:
+
+   imr-lx4@fe86 {
+   compatible = "renesas,imr-lx4-h3", "renesas,imr-lx4";
+   reg = <0 0xfe86 0 0x2000>;
+   interrupts = ;
+   clocks = < CPG_MOD 823>;
+   };
Index: media_tree/drivers/media/platform/Kconfig
===
--- media_tree.orig/drivers/media/platform/Kconfig
+++ media_tree/drivers/media/platform/Kconfig
@@ -399,6 +399,19 @@ config VIDEO_RENESAS_FCP

Re: [RFC PATCH 2/3] v4l: vsp1: extend VSP1 module API to allow DRM callback registration

[Kieran Bingham]

Hi Laurent,

On 03/03/17 02:11, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Wednesday 01 Mar 2017 13:12:55 Kieran Bingham wrote:
>> To be able to perform page flips in DRM without flicker we need to be
>> able to notify the rcar-du module when the VSP has completed its
>> processing.
>>
>> To synchronise the page flip events for userspace, we move the required
>> event through the VSP to track the data flow. When the frame is
>> completed, the event can be returned back to the originator through the
>> registered callback.
>>
>> We must not have bidirectional dependencies on the two components to
>> maintain support for loadable modules, thus we extend the API to allow
>> a callback to be registered within the VSP DRM interface.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |  2 +-
>>  drivers/media/platform/vsp1/vsp1_drm.c | 42 +--
>>  drivers/media/platform/vsp1/vsp1_drm.h | 12 -
>>  include/media/vsp1.h   |  6 +++-
>>  4 files changed, 58 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index b5bfbe50bd87..71e70e1e0881
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> @@ -81,7 +81,7 @@ void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
>>
>>  void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
>>  {
>> -vsp1_du_atomic_flush(crtc->vsp->vsp);
>> +vsp1_du_atomic_flush(crtc->vsp->vsp, NULL);
>>  }
>>
>>  /* Keep the two tables in sync. */
>> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
>> b/drivers/media/platform/vsp1/vsp1_drm.c index 8e2aa3f8e52f..743cbce48d0c
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_drm.c
>> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
 >> @@ -52,6 +52,40 @@ int vsp1_du_init(struct device *dev)
>>  EXPORT_SYMBOL_GPL(vsp1_du_init);
>>
>>  /**
>> + * vsp1_du_register_callback - Register VSP completion notifier callback
>> + *
>> + * Allow the DRM framework to register a callback with us to notify the end
>> of + * processing each frame. This allows synchronisation for page
>> flipping. + *
>> + * @dev: the VSP device
>> + * @callback: the callback function to notify the DU module
>> + * @private: private structure data to pass with the callback
>> + *
>> + */
>> +void vsp1_du_register_callback(struct device *dev,
>> +   void (*callback)(void *, void *),
>> +   void *private)
>> +{
>> +struct vsp1_device *vsp1 = dev_get_drvdata(dev);
>> +
>> +vsp1->drm->du_complete = callback;
>> +vsp1->drm->du_private = private;
>> +}
>> +EXPORT_SYMBOL_GPL(vsp1_du_register_callback);
> 
> As they're not supposed to change at runtime while the display is running, 
> how 
> about passing the callback and private data pointer to the 
> vsp1_du_setup_lif() 
> function ? Feel free to create a structure for all the parameters passed to 
> the function if you think we'll have too much (which would, as a side effect, 
> made updates to the API easier in the future as changes to the two subsystems 
> will be easier to decouple).

Sure, that's fine. I think a config structure makes sense here.

>> +static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
>> +{
>> +struct vsp1_drm *drm = to_vsp1_drm(pipe);
>> +
>> +if (drm->du_complete && drm->active_data)
>> +drm->du_complete(drm->du_private, drm->active_data);
>> +
>> +/* The pending frame is now active */
>> +drm->active_data = drm->pending_data;
>> +drm->pending_data = NULL;
>> +}
> 
> I would move this function to the "Interrupt Handling" section.

Ack.

>> +/**
>>   * vsp1_du_setup_lif - Setup the output part of the VSP pipeline
>>   * @dev: the VSP device
>>   * @width: output frame width in pixels
>> @@ -99,7 +133,8 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
>> width, }
>>
>>  pipe->num_inputs = 0;
>> -
>> +pipe->frame_end = NULL;
> 
> You can drop this if ...
> 
>> +vsp1->drm->du_complete = NULL;
>>  vsp1_dlm_reset(pipe->output->dlm);
>>  vsp1_device_put(vsp1);
>>
>> @@ -196,6 +231,8 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
>> width, if (ret < 0)
>>  return ret;
>>
>> +pipe->frame_end = vsp1_du_pipeline_frame_end;
>> +

> 
> ... you move this to vsp1_drm_init().

Done.


> 
>>  ret = media_entity_pipeline_start(>output->entity.subdev.entity,
>>>pipe);
>>  if (ret < 0) {
>> @@ -420,7 +457,7 @@ static unsigned int rpf_zpos(struct vsp1_device *vsp1,
>> struct vsp1_rwpf *rpf) * vsp1_du_atomic_flush - Commit an atomic update
>>   * @dev: the VSP device
>>   */
>> -void vsp1_du_atomic_flush(struct device *dev)
>> +void vsp1_du_atomic_flush(struct device *dev, void *data)
>>  {
>>   

Re: [PATCH v4 1/3] watchdog: add rza_wdt driver

[Geert Uytterhoeven]

Hi Chris,

On Thu, Mar 2, 2017 at 4:38 PM, Chris Brandt  wrote:
>> > +   /*
>> > +* Since the max possible timeout of our 8-bit count register is
>> less
>> > +* than a second, we must use max_hw_heartbeat_ms.
>> > +*/
>> > +   priv->wdev.max_hw_heartbeat_ms = (1000 * U8_MAX)/rate;
>>
>> space before and after /
>
> OK.
> #Funny because checkpatch.pl said it didn't like a space on one side but
>  not the other, so I choose no spaces and it was happy. I'm way below 80
>  characters for that line so it doesn't matter to me.

Just drop the parentheses? Standard C operator precedence is fine here.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 4/7] arm: dts: r7s72100: Add pin controller node

[Geert Uytterhoeven]

Hi Chris,

On Thu, Mar 2, 2017 at 9:17 PM, Chris Brandt  wrote:
> On Tuesday, February 21, 2017, jacopo mondi wrote:
>> > +   gpio-controller;
>> > +   #gpio-cells = <2>;
>> > +   gpio-ranges = < 0 0 16>;
>>
>> Not all ports have 16 pins available.
>> This is one of the differences between different RZ/A1 SoC versions
>> (RZ/A1H, RZ/A1L etc)
>>
>> I'll change the number of pins to the actual available ones on each port
>> for r7s72100 (RZ/A1H)
>
> But wait, what if someone wants to use a RZ/A1L???
>
> I don't want to make a separate dtsi file for RZ/A1L.
>
> Is it possible to change the number of port pins in the board dts file?
> For example:
>   RZ/A1H: P5_0 - P5_10
>   RZ/A1L: P5_0 - P5_16

That's 17 pins, not 16?

>
> So, in a rza1l-board.dts file I would put:
>
>  {
> gpio-ranges = < 0 80 16>;
> }
>
> Will this work?

Yes, overriding should work. But the number of pins is an SoC-property, not
a board-property?

Are the differences between RZ/A1H and RZ/A1L just the number of pins?
If yes, you could use a hierarchical DTS structure:

rza1h-.dts:

#include "rza1h.dtsi"

// board specifics here

rza1l-.dts:

#include "rza1l.dtsi"

// board specifics here

rza1h.dtsi:

#include "rza.dtsi"  // r7s72100.dtsi?

// base SoC overrides
 {
gpio-ranges = < 0 80 11>;
}

rza1l.dtsi:

#include "rza.dtsi"  // r7s72100.dtsi?

// base SoC overrides
 {
gpio-ranges = < 0 80 16>;
}

Actual naming of DTS files TBD.
We could also decide to not have rza1h.dtsi, and assume the base dtsi is for
RZ/A1H.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] drm: rcar-du: Make sure DRM planes are created by VSP1

[Jacopo Mondi]

On Gen3 platforms compositing planes are allocated  by VSP on behalf of
DRM/KMS.
If VSP support is not compiled in, vsp1 initialization stub routine is
called, leading to invalid memory accesses later on when un-initialized
planes are accessed.

Fail explicitly earlier if planes are not properly created.

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index b5d3f16..7f56c09 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -616,6 +616,9 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
ret = rcar_du_vsp_init(vsp);
if (ret < 0)
return ret;
+
+   if (!vsp->planes)
+   return -EINVAL;
}
}
 
-- 
2.7.4