Re: [PATCH v2] drm/vc4: Fix sleeps during the IRQ handler for DSI transactions.

2017-10-14 Thread Boris Brezillon
On Fri, 13 Oct 2017 17:12:55 -0700
Eric Anholt  wrote:

> VC4's DSI1 has a bug where the AXI connection is broken for 32-bit
> writes from the CPU, so we use the DMA engine to DMA 32-bit values
> into registers instead.  That sleeps, so we can't do it from the top
> half.
> 
> As a solution, use an interrupt thread so that all our writes happen
> when sleeping is is allowed.
> 
> v2: Use IRQF_ONESHOT (suggested by Boris)
> 
> Signed-off-by: Eric Anholt 

Reviewed-by: Boris Brezillon 

> ---
> 
> Boris, that cleanup ended up working and it looks great.  Thanks!
> 
>  drivers/gpu/drm/vc4/vc4_dsi.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
> index 554605af344e..3b74fda5662d 100644
> --- a/drivers/gpu/drm/vc4/vc4_dsi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c
> @@ -1360,6 +1360,25 @@ static void dsi_handle_error(struct vc4_dsi *dsi,
>   *ret = IRQ_HANDLED;
>  }
>  
> +/* Initial handler for port 1 where we need the reg_dma workaround.
> + * The register DMA writes sleep, so we can't do it in the top half.
> + * Instead we use IRQF_ONESHOT so that the IRQ gets disabled in the
> + * parent interrupt contrller until our interrupt thread is done.
> + */
> +static irqreturn_t vc4_dsi_irq_defer_to_thread_handler(int irq, void *data)
> +{
> + struct vc4_dsi *dsi = data;
> + u32 stat = DSI_PORT_READ(INT_STAT);
> +
> + if (!stat)
> + return IRQ_NONE;
> +
> + return IRQ_WAKE_THREAD;
> +}
> +
> +/* Normal IRQ handler for port 0, or the threaded IRQ handler for port
> + * 1 where we need the reg_dma workaround.
> + */
>  static irqreturn_t vc4_dsi_irq_handler(int irq, void *data)
>  {
>   struct vc4_dsi *dsi = data;
> @@ -1539,8 +1558,16 @@ static int vc4_dsi_bind(struct device *dev, struct 
> device *master, void *data)
>   /* Clear any existing interrupt state. */
>   DSI_PORT_WRITE(INT_STAT, DSI_PORT_READ(INT_STAT));
>  
> - ret = devm_request_irq(dev, platform_get_irq(pdev, 0),
> -vc4_dsi_irq_handler, 0, "vc4 dsi", dsi);
> + if (dsi->reg_dma_mem) {
> + ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0),
> + 
> vc4_dsi_irq_defer_to_thread_handler,
> + vc4_dsi_irq_handler,
> + IRQF_ONESHOT,
> + "vc4 dsi", dsi);
> + } else {
> + ret = devm_request_irq(dev, platform_get_irq(pdev, 0),
> +vc4_dsi_irq_handler, 0, "vc4 dsi", dsi);
> + }
>   if (ret) {
>   if (ret != -EPROBE_DEFER)
>   dev_err(dev, "Failed to get interrupt: %d\n", ret);

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


Re: [PATCH v2] drm/amd/powerplay: Remove unnecessary cast on void pointer

2017-10-14 Thread Christian König

Am 13.10.2017 um 19:33 schrieb Harsha Sharma:

Done with following coccinelle patch

@r@
expression x;
void* e;
type T;
identifier f;
@@
(
   *((T *)e)
|
   ((T *)x)[...]
|
   ((T*)x)->f
|

- (T*)
   e
)

Signed-off-by: Harsha Sharma 


Reviewed-by: Christian König 


---
Changes in v2:
  -Remove unnecessary parentheses
  -Remove one more useless cast

  drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c   |  6 +++---
  drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c  |  8 
  drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c |  2 +-
  drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c   |  6 +++---
  .../gpu/drm/amd/powerplay/hwmgr/processpptables.c|  2 +-
  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 20 ++--
  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_thermal.c   |  4 ++--
  drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c   | 12 ++--
  drivers/gpu/drm/amd/powerplay/hwmgr/vega10_thermal.c |  2 +-
  9 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
index bc839ff0bdd0..f22104c78dcb 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
@@ -474,7 +474,7 @@ static int cz_tf_upload_pptable_to_smu(struct pp_hwmgr 
*hwmgr, void *input,
PP_ASSERT_WITH_CODE((0 == ret && NULL != table),
"Fail to get clock table from SMU!", return 
-EINVAL;);
  
-	clock_table = (struct SMU8_Fusion_ClkTable *)table;

+   clock_table = table;
  
  	/* patch clock table */

PP_ASSERT_WITH_CODE((vddc_table->count <= CZ_MAX_HARDWARE_POWERLEVELS),
@@ -868,8 +868,8 @@ static int cz_tf_update_low_mem_pstate(struct pp_hwmgr 
*hwmgr,
  {
bool disable_switch;
bool enable_low_mem_state;
-   struct cz_hwmgr *hw_data = (struct cz_hwmgr *)(hwmgr->backend);
-   const struct phm_set_power_state_input *states = (struct 
phm_set_power_state_input *)input;
+   struct cz_hwmgr *hw_data = hwmgr->backend;
+   const struct phm_set_power_state_input *states = input;
const struct cz_power_state *pnew_state = 
cast_const_PhwCzPowerState(states->pnew_state);
  
  	if (hw_data->sys_info.nb_dpm_enable) {

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index 9547f265a8bb..5d63a1b18b39 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -469,7 +469,7 @@ int phm_reset_single_dpm_table(void *table,
  {
int i;
  
-	struct vi_dpm_table *dpm_table = (struct vi_dpm_table *)table;

+   struct vi_dpm_table *dpm_table = table;
  
  	dpm_table->count = count > max ? max : count;
  
@@ -484,7 +484,7 @@ void phm_setup_pcie_table_entry(

uint32_t index, uint32_t pcie_gen,
uint32_t pcie_lanes)
  {
-   struct vi_dpm_table *dpm_table = (struct vi_dpm_table *)table;
+   struct vi_dpm_table *dpm_table = table;
dpm_table->dpm_level[index].value = pcie_gen;
dpm_table->dpm_level[index].param1 = pcie_lanes;
dpm_table->dpm_level[index].enabled = 1;
@@ -494,7 +494,7 @@ int32_t phm_get_dpm_level_enable_mask_value(void *table)
  {
int32_t i;
int32_t mask = 0;
-   struct vi_dpm_table *dpm_table = (struct vi_dpm_table *)table;
+   struct vi_dpm_table *dpm_table = table;
  
  	for (i = dpm_table->count; i > 0; i--) {

mask = mask << 1;
@@ -566,7 +566,7 @@ int phm_find_boot_level(void *table,
  {
int result = -EINVAL;
uint32_t i;
-   struct vi_dpm_table *dpm_table = (struct vi_dpm_table *)table;
+   struct vi_dpm_table *dpm_table = table;
  
  	for (i = 0; i < dpm_table->count; i++) {

if (value == dpm_table->dpm_level[i].value) {
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c
index 953e0c9ad7cd..676f2e8bb2ee 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c
@@ -579,7 +579,7 @@ static ATOM_GPIO_PIN_LUT *get_gpio_lookup_table(void 
*device)
PP_ASSERT_WITH_CODE((NULL != table_address),
"Error retrieving BIOS Table Address!", return NULL;);
  
-	return (ATOM_GPIO_PIN_LUT *)table_address;

+   return table_address;
  }
  
  /**

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
index c062844b15f3..05e3f5302994 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
@@ -66,7 +66,7 @@ static struct atom_voltage_objects_info_v4_1 
*pp_atomfwctrl_get_voltage_info_tab
  "Error retrieving BIOS Table Address!",
  return NULL);
  
-return (struct atom_voltage_objects_info_v4_1 *)table_address;

+return table_address;
  }
  
  

Re: [PATCH v2] drm/vc4: Fix sleeps during the IRQ handler for DSI transactions.

2017-10-14 Thread Paul Menzel
Dear Eric,


Some nit picks where stuff contradicts the coding style.

Am Freitag, den 13.10.2017, 17:12 -0700 schrieb Eric Anholt:
> VC4's DSI1 has a bug where the AXI connection is broken for 32-bit
> writes from the CPU, so we use the DMA engine to DMA 32-bit values
> into registers instead.  That sleeps, so we can't do it from the top
> half.
> 
> As a solution, use an interrupt thread so that all our writes happen
> when sleeping is is allowed.
> 
> v2: Use IRQF_ONESHOT (suggested by Boris)
> 
> Signed-off-by: Eric Anholt 
> ---
> 
> Boris, that cleanup ended up working and it looks great.  Thanks!
> 
>  drivers/gpu/drm/vc4/vc4_dsi.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
> index 554605af344e..3b74fda5662d 100644
> --- a/drivers/gpu/drm/vc4/vc4_dsi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c
> @@ -1360,6 +1360,25 @@ static void dsi_handle_error(struct vc4_dsi *dsi,
>   *ret = IRQ_HANDLED;
>  }
>  
> +/* Initial handler for port 1 where we need the reg_dma workaround.
> + * The register DMA writes sleep, so we can't do it in the top half.
> + * Instead we use IRQF_ONESHOT so that the IRQ gets disabled in the
> + * parent interrupt contrller until our interrupt thread is done.
> + */

There should be a “blank comment line” at the beginning [1].

> The preferred style for long (multi-line) comments is:
> 
> /*
>  * This is the preferred style for multi-line
>  * comments in the Linux kernel source code.
>  * Please use it consistently.
>  *
>  * Description:  A column of asterisks on the left side,
>  * with beginning and ending almost-blank lines.
>  */

> +static irqreturn_t vc4_dsi_irq_defer_to_thread_handler(int irq, void *data)
> +{
> + struct vc4_dsi *dsi = data;
> + u32 stat = DSI_PORT_READ(INT_STAT);
> +
> + if (!stat)
> + return IRQ_NONE;
> +
> + return IRQ_WAKE_THREAD;
> +}
> +
> +/* Normal IRQ handler for port 0, or the threaded IRQ handler for port
> + * 1 where we need the reg_dma workaround.
> + */
>  static irqreturn_t vc4_dsi_irq_handler(int irq, void *data)
>  {
>   struct vc4_dsi *dsi = data;
> @@ -1539,8 +1558,16 @@ static int vc4_dsi_bind(struct device *dev, struct 
> device *master, void *data)
>   /* Clear any existing interrupt state. */
>   DSI_PORT_WRITE(INT_STAT, DSI_PORT_READ(INT_STAT));
>  
> - ret = devm_request_irq(dev, platform_get_irq(pdev, 0),
> -vc4_dsi_irq_handler, 0, "vc4 dsi", dsi);
> + if (dsi->reg_dma_mem) {
> + ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0),
> + 
> vc4_dsi_irq_defer_to_thread_handler,
> + vc4_dsi_irq_handler,
> + IRQF_ONESHOT,
> + "vc4 dsi", dsi);
> + } else {
> + ret = devm_request_irq(dev, platform_get_irq(pdev, 0),
> +vc4_dsi_irq_handler, 0, "vc4 dsi", dsi);
> + }

The braces should be removed [2].

> Do not unnecessarily use braces where a single statement will do.

>   if (ret) {
>   if (ret != -EPROBE_DEFER)
>   dev_err(dev, "Failed to get interrupt: %d\n", ret);


Thanks,

Paul


[1] https://www.kernel.org/doc/html/v4.13/process/coding-style.html#commenting
[2] 
https://www.kernel.org/doc/html/v4.13/process/coding-style.html#placing-braces-and-spaces

signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 196615] amdgpu - resume from suspend is no longer working on rx480

2017-10-14 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=196615

--- Comment #26 from cont...@florentflament.com ---
I just figured out that if instead of opening a 'Gnome on Xorg' session, I open
a 'Gnome' session (which, as far as I know, starts a 'Wayland Display Server'
instead of Xorg on my Fedora setup), then I don't have any more issues resuming
after a suspend. It works pretty well, no more amdgpu related error messages in
my journal.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCHv2 0/9] omapdrm: hdmi4: add CEC support

2017-10-14 Thread Hans Verkuil
On 10/12/2017 10:03 AM, Tomi Valkeinen wrote:
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 12/10/17 09:50, Hans Verkuil wrote:
> 
>>> I can't test with a TV, so no CEC for me... But otherwise I think the
>>> series works ok now, and looks ok. So I'll apply, but it's a bit late
>>> for the next merge window, so I'll aim for 4.15 with this.
>>
>> What is the status? Do you need anything from me? I'd like to get this in 
>> for 4.15.
> 
> Thanks for reminding. I think I would've forgotten...
> 
> I sent the pull request, so all should be fine.
> 
> If possible, please test the pull request, preferably with drm-next
> merged (git://people.freedesktop.org/~airlied/linux drm-next), as I
> don't have a CEC capable display.

Tested with drm-next. Works fine!

Great to finally see this merged!

Regards,

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


Re: [PATCHv4 0/4] tegra-cec: add Tegra HDMI CEC support

2017-10-14 Thread Hans Verkuil
Hi Thierry,

On 09/11/2017 02:29 PM, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This patch series adds support for the Tegra CEC functionality.
> 
> This v4 has been rebased to the latest 4.14 pre-rc1 mainline.
> 
> Please review! Other than for the bindings that are now Acked I have not
> received any feedback.

Can you or someone else from the Tegra maintainers review this?

I have not heard anything about this patch series, nor of the previous
versions of this series. What's the hold-up?

Regards,

Hans

> 
> The first patch documents the CEC bindings, the second adds support
> for this to tegra124.dtsi and enables it for the Jetson TK1.
> 
> The third patch adds the CEC driver itself and the final patch adds
> the cec notifier support to the drm/tegra driver in order to notify
> the CEC driver whenever the physical address changes.
> 
> I expect that the dts changes apply as well to the Tegra X1/X2 and possibly
> other Tegra SoCs, but I can only test this with my Jetson TK1 board.
> 
> The dt-bindings and the tegra-cec driver would go in through the media
> subsystem, the drm/tegra part through the drm subsystem and the dts
> changes through (I guess) the linux-tegra developers. Luckily they are
> all independent of one another.
> 
> To test this you need the CEC utilities from git://linuxtv.org/v4l-utils.git.
> 
> To build this:
> 
> git clone git://linuxtv.org/v4l-utils.git
> cd v4l-utils
> ./bootstrap.sh; ./configure
> make
> sudo make install # optional, you really only need utils/cec*
> 
> To test:
> 
> cec-ctl --playback # configure as playback device
> cec-ctl -S # detect all connected CEC devices
> 
> See here for the public CEC API:
> 
> https://hverkuil.home.xs4all.nl/spec/uapi/cec/cec-api.html
> 
> Regards,
> 
>   Hans
> 
> Changes since v3:
> 
> - Use the new CEC_CAP_DEFAULTS define
> - Use IS_ERR(cec->adap) instead of IS_ERR_OR_NULL(cec->adap)
>   (cec_allocate_adapter never returns a NULL pointer)
> - Drop the device_init_wakeup: wakeup is not (yet) supported by
>   the CEC framework and I have never tested it.
> 
> Hans Verkuil (4):
>   dt-bindings: document the tegra CEC bindings
>   ARM: tegra: add CEC support to tegra124.dtsi
>   tegra-cec: add Tegra HDMI CEC driver
>   drm/tegra: add cec-notifier support
> 
>  .../devicetree/bindings/media/tegra-cec.txt|  27 ++
>  MAINTAINERS|   8 +
>  arch/arm/boot/dts/tegra124-jetson-tk1.dts  |   4 +
>  arch/arm/boot/dts/tegra124.dtsi|  12 +-
>  drivers/gpu/drm/tegra/Kconfig  |   1 +
>  drivers/gpu/drm/tegra/drm.h|   3 +
>  drivers/gpu/drm/tegra/hdmi.c   |   9 +
>  drivers/gpu/drm/tegra/output.c |   6 +
>  drivers/media/platform/Kconfig |  11 +
>  drivers/media/platform/Makefile|   2 +
>  drivers/media/platform/tegra-cec/Makefile  |   1 +
>  drivers/media/platform/tegra-cec/tegra_cec.c   | 501 
> +
>  drivers/media/platform/tegra-cec/tegra_cec.h   | 127 ++
>  13 files changed, 711 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt
>  create mode 100644 drivers/media/platform/tegra-cec/Makefile
>  create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
>  create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h
> 

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


Re: [PATCH 20/48] drm: omapdrm: Merge the omapdrm and omapdss drivers

2017-10-14 Thread Sebastian Reichel
Hi,

On Fri, Oct 13, 2017 at 05:59:16PM +0300, Laurent Pinchart wrote:
> The split between the omapdss and omapdrm driver is historic and was due
> to other userspace APIs (FBDEV and V4L2) being supported in addition to
> DRM/KMS. Now that the drivers only supports the DRM/KMS API, there is no
> need to keep them separate anymore.
> 
> Merge the two drivers and remove the now unneeded omapdrm virtual
> platform device.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/omapdrm/Kconfig  |  5 +-
>  drivers/gpu/drm/omapdrm/Makefile | 25 ++
>  drivers/gpu/drm/omapdrm/dss/Kconfig  | 12 -
>  drivers/gpu/drm/omapdrm/dss/Makefile | 25 --
>  drivers/gpu/drm/omapdrm/dss/base.c   | 13 -
>  drivers/gpu/drm/omapdrm/dss/core.c   | 14 ++
>  drivers/gpu/drm/omapdrm/dss/dss.c| 23 -
>  drivers/gpu/drm/omapdrm/dss/omapdss.h|  4 --
>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 12 -
>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.h |  3 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c   | 82 
> ++--
>  drivers/gpu/drm/omapdrm/omap_drv.h   |  4 ++
>  12 files changed, 74 insertions(+), 148 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
> index b3d08c5f41d4..7e5080e45b16 100644
> --- a/drivers/gpu/drm/omapdrm/Kconfig
> +++ b/drivers/gpu/drm/omapdrm/Kconfig
> @@ -2,8 +2,11 @@ config DRM_OMAP
>   tristate "OMAP DRM"
>   depends on DRM
>   depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
> - select OMAP2_DSS
>   select DRM_KMS_HELPER
> + select HDMI
> + select OMAP2_DSS

As far as I can see "CONFIG_OMAP2_DSS" no longer exists after the merge,
so this can be dropped.

Otherwise:

Reviewed-by: Sebastian Reichel 

-- Sebastian

> + select OMAP2_DSS_INIT
> + select VIDEOMODE_HELPERS
>   default n
>   help
> DRM display driver for OMAP2/3/4 based boards.
> diff --git a/drivers/gpu/drm/omapdrm/Makefile 
> b/drivers/gpu/drm/omapdrm/Makefile
> index b391be7ecb6c..1dafa51ca00e 100644
> --- a/drivers/gpu/drm/omapdrm/Makefile
> +++ b/drivers/gpu/drm/omapdrm/Makefile
> @@ -21,4 +21,29 @@ omapdrm-y := omap_drv.o \
>  
>  omapdrm-$(CONFIG_DRM_FBDEV_EMULATION) += omap_fbdev.o
>  
> +# Core DSS files
> +omapdrm-y += \
> + dss/base.o \
> + dss/core.o \
> + dss/dispc.o \
> + dss/dispc_coefs.o \
> + dss/display.o \
> + dss/dss.o \
> + dss/dss-of.o \
> + dss/output.o \
> + dss/pll.o \
> + dss/video-pll.o
> +
> +omapdrm-$(CONFIG_OMAP2_DSS_DPI) += dss/dpi.o
> +omapdrm-$(CONFIG_OMAP2_DSS_VENC) += dss/venc.o
> +omapdrm-$(CONFIG_OMAP2_DSS_SDI) += dss/sdi.o
> +omapdrm-$(CONFIG_OMAP2_DSS_DSI) += dss/dsi.o
> +omapdrm-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += dss/hdmi_common.o dss/hdmi_wp.o \
> + dss/hdmi_pll.o dss/hdmi_phy.o
> +omapdrm-$(CONFIG_OMAP4_DSS_HDMI) += dss/hdmi4.o dss/hdmi4_core.o
> +omapdrm-$(CONFIG_OMAP4_DSS_HDMI_CEC) += dss/hdmi4_cec.o
> +omapdrm-$(CONFIG_OMAP5_DSS_HDMI) += dss/hdmi5.o dss/hdmi5_core.o
> +
> +ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
> +
>  obj-$(CONFIG_DRM_OMAP)   += omapdrm.o
> diff --git a/drivers/gpu/drm/omapdrm/dss/Kconfig 
> b/drivers/gpu/drm/omapdrm/dss/Kconfig
> index 39a30a64448a..157c5601e4be 100644
> --- a/drivers/gpu/drm/omapdrm/dss/Kconfig
> +++ b/drivers/gpu/drm/omapdrm/dss/Kconfig
> @@ -1,16 +1,6 @@
>  config OMAP2_DSS_INIT
>   bool
>  
> -menuconfig OMAP2_DSS
> -tristate "OMAP2+ Display Subsystem support"
> - select VIDEOMODE_HELPERS
> - select OMAP2_DSS_INIT
> - select HDMI
> -help
> -   OMAP2+ Display Subsystem support.
> -
> -if OMAP2_DSS
> -
>  config OMAP2_DSS_DEBUG
>   bool "Debug support"
>   default n
> @@ -126,5 +116,3 @@ config OMAP2_DSS_SLEEP_AFTER_VENC_RESET
>  
> This option enables the sleep, and is enabled by default. You can
> disable the sleep if it doesn't cause problems on your platform.
> -
> -endif
> diff --git a/drivers/gpu/drm/omapdrm/dss/Makefile 
> b/drivers/gpu/drm/omapdrm/dss/Makefile
> index 531b4d8075e5..3db4bf31aeaf 100644
> --- a/drivers/gpu/drm/omapdrm/dss/Makefile
> +++ b/drivers/gpu/drm/omapdrm/dss/Makefile
> @@ -1,26 +1 @@
>  obj-$(CONFIG_OMAP2_DSS_INIT) += omapdss-boot-init.o
> -obj-$(CONFIG_OMAP2_DSS) += omapdss.o
> -
> -# Core DSS files
> -omapdss-y := \
> - base.o \
> - display.o \
> - dss-of.o \
> - output.o \
> - core.o \
> - dss.o \
> - dispc.o \
> - dispc_coefs.o \
> - pll.o \
> - video-pll.o
> -
> -omapdss-$(CONFIG_OMAP2_DSS_DPI) += dpi.o
> -omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
> -omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o
> -omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
> -omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o hdmi_wp.o 
> hdmi_pll.o \
> - hdmi_phy.o
> -omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o
> -omapdss-$(CONFIG_OMAP4_DSS_HDMI_CEC) += hdmi4_cec.o
> -omapdss-$(CONFIG_OMAP5_DS

Re: [PATCHv4 0/4] tegra-cec: add Tegra HDMI CEC support

2017-10-14 Thread Thierry Reding
On Sat, Oct 14, 2017 at 02:08:31PM +0200, Hans Verkuil wrote:
> Hi Thierry,
> 
> On 09/11/2017 02:29 PM, Hans Verkuil wrote:
> > From: Hans Verkuil 
> > 
> > This patch series adds support for the Tegra CEC functionality.
> > 
> > This v4 has been rebased to the latest 4.14 pre-rc1 mainline.
> > 
> > Please review! Other than for the bindings that are now Acked I have not
> > received any feedback.
> 
> Can you or someone else from the Tegra maintainers review this?
> 
> I have not heard anything about this patch series, nor of the previous
> versions of this series. What's the hold-up?

Sorry about that. I've been meaning to look at this for a while now, but
never got around to it. From a quick glance this looks good. Let me take
this for a quick test-drive when I'm back at the office next week and
I'll report back.

Is there any particular ordering that we need to observe in order to
merge this? Looks to me like it would be safe to merge patches 1 and 3
through the CEC (media?) tree and take the others through DRM and Tegra
separately without breaking anything.

Thierry

> > The first patch documents the CEC bindings, the second adds support
> > for this to tegra124.dtsi and enables it for the Jetson TK1.
> > 
> > The third patch adds the CEC driver itself and the final patch adds
> > the cec notifier support to the drm/tegra driver in order to notify
> > the CEC driver whenever the physical address changes.
> > 
> > I expect that the dts changes apply as well to the Tegra X1/X2 and possibly
> > other Tegra SoCs, but I can only test this with my Jetson TK1 board.
> > 
> > The dt-bindings and the tegra-cec driver would go in through the media
> > subsystem, the drm/tegra part through the drm subsystem and the dts
> > changes through (I guess) the linux-tegra developers. Luckily they are
> > all independent of one another.
> > 
> > To test this you need the CEC utilities from 
> > git://linuxtv.org/v4l-utils.git.
> > 
> > To build this:
> > 
> > git clone git://linuxtv.org/v4l-utils.git
> > cd v4l-utils
> > ./bootstrap.sh; ./configure
> > make
> > sudo make install # optional, you really only need utils/cec*
> > 
> > To test:
> > 
> > cec-ctl --playback # configure as playback device
> > cec-ctl -S # detect all connected CEC devices
> > 
> > See here for the public CEC API:
> > 
> > https://hverkuil.home.xs4all.nl/spec/uapi/cec/cec-api.html
> > 
> > Regards,
> > 
> > Hans
> > 
> > Changes since v3:
> > 
> > - Use the new CEC_CAP_DEFAULTS define
> > - Use IS_ERR(cec->adap) instead of IS_ERR_OR_NULL(cec->adap)
> >   (cec_allocate_adapter never returns a NULL pointer)
> > - Drop the device_init_wakeup: wakeup is not (yet) supported by
> >   the CEC framework and I have never tested it.
> > 
> > Hans Verkuil (4):
> >   dt-bindings: document the tegra CEC bindings
> >   ARM: tegra: add CEC support to tegra124.dtsi
> >   tegra-cec: add Tegra HDMI CEC driver
> >   drm/tegra: add cec-notifier support
> > 
> >  .../devicetree/bindings/media/tegra-cec.txt|  27 ++
> >  MAINTAINERS|   8 +
> >  arch/arm/boot/dts/tegra124-jetson-tk1.dts  |   4 +
> >  arch/arm/boot/dts/tegra124.dtsi|  12 +-
> >  drivers/gpu/drm/tegra/Kconfig  |   1 +
> >  drivers/gpu/drm/tegra/drm.h|   3 +
> >  drivers/gpu/drm/tegra/hdmi.c   |   9 +
> >  drivers/gpu/drm/tegra/output.c |   6 +
> >  drivers/media/platform/Kconfig |  11 +
> >  drivers/media/platform/Makefile|   2 +
> >  drivers/media/platform/tegra-cec/Makefile  |   1 +
> >  drivers/media/platform/tegra-cec/tegra_cec.c   | 501 
> > +
> >  drivers/media/platform/tegra-cec/tegra_cec.h   | 127 ++
> >  13 files changed, 711 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt
> >  create mode 100644 drivers/media/platform/tegra-cec/Makefile
> >  create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
> >  create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h
> > 
> 


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


Re: [PATCHv4 0/4] tegra-cec: add Tegra HDMI CEC support

2017-10-14 Thread Hans Verkuil
On 10/14/2017 03:34 PM, Thierry Reding wrote:
> On Sat, Oct 14, 2017 at 02:08:31PM +0200, Hans Verkuil wrote:
>> Hi Thierry,
>>
>> On 09/11/2017 02:29 PM, Hans Verkuil wrote:
>>> From: Hans Verkuil 
>>>
>>> This patch series adds support for the Tegra CEC functionality.
>>>
>>> This v4 has been rebased to the latest 4.14 pre-rc1 mainline.
>>>
>>> Please review! Other than for the bindings that are now Acked I have not
>>> received any feedback.
>>
>> Can you or someone else from the Tegra maintainers review this?
>>
>> I have not heard anything about this patch series, nor of the previous
>> versions of this series. What's the hold-up?
> 
> Sorry about that. I've been meaning to look at this for a while now, but
> never got around to it. From a quick glance this looks good. Let me take
> this for a quick test-drive when I'm back at the office next week and
> I'll report back.

It would be great if you can test if the TK1 dts changes will also work
with the Jetson X1. It should, but I don't have a Jetson X1 to test with.

> Is there any particular ordering that we need to observe in order to
> merge this? Looks to me like it would be safe to merge patches 1 and 3
> through the CEC (media?) tree and take the others through DRM and Tegra
> separately without breaking anything.

Correct. Once I have your Ack I can make a pull request for patches 1+3.
Patches 2+4 would have to go through you.

Regards,

Hans

> 
> Thierry
> 
>>> The first patch documents the CEC bindings, the second adds support
>>> for this to tegra124.dtsi and enables it for the Jetson TK1.
>>>
>>> The third patch adds the CEC driver itself and the final patch adds
>>> the cec notifier support to the drm/tegra driver in order to notify
>>> the CEC driver whenever the physical address changes.
>>>
>>> I expect that the dts changes apply as well to the Tegra X1/X2 and possibly
>>> other Tegra SoCs, but I can only test this with my Jetson TK1 board.
>>>
>>> The dt-bindings and the tegra-cec driver would go in through the media
>>> subsystem, the drm/tegra part through the drm subsystem and the dts
>>> changes through (I guess) the linux-tegra developers. Luckily they are
>>> all independent of one another.
>>>
>>> To test this you need the CEC utilities from 
>>> git://linuxtv.org/v4l-utils.git.
>>>
>>> To build this:
>>>
>>> git clone git://linuxtv.org/v4l-utils.git
>>> cd v4l-utils
>>> ./bootstrap.sh; ./configure
>>> make
>>> sudo make install # optional, you really only need utils/cec*
>>>
>>> To test:
>>>
>>> cec-ctl --playback # configure as playback device
>>> cec-ctl -S # detect all connected CEC devices
>>>
>>> See here for the public CEC API:
>>>
>>> https://hverkuil.home.xs4all.nl/spec/uapi/cec/cec-api.html
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>> Changes since v3:
>>>
>>> - Use the new CEC_CAP_DEFAULTS define
>>> - Use IS_ERR(cec->adap) instead of IS_ERR_OR_NULL(cec->adap)
>>>   (cec_allocate_adapter never returns a NULL pointer)
>>> - Drop the device_init_wakeup: wakeup is not (yet) supported by
>>>   the CEC framework and I have never tested it.
>>>
>>> Hans Verkuil (4):
>>>   dt-bindings: document the tegra CEC bindings
>>>   ARM: tegra: add CEC support to tegra124.dtsi
>>>   tegra-cec: add Tegra HDMI CEC driver
>>>   drm/tegra: add cec-notifier support
>>>
>>>  .../devicetree/bindings/media/tegra-cec.txt|  27 ++
>>>  MAINTAINERS|   8 +
>>>  arch/arm/boot/dts/tegra124-jetson-tk1.dts  |   4 +
>>>  arch/arm/boot/dts/tegra124.dtsi|  12 +-
>>>  drivers/gpu/drm/tegra/Kconfig  |   1 +
>>>  drivers/gpu/drm/tegra/drm.h|   3 +
>>>  drivers/gpu/drm/tegra/hdmi.c   |   9 +
>>>  drivers/gpu/drm/tegra/output.c |   6 +
>>>  drivers/media/platform/Kconfig |  11 +
>>>  drivers/media/platform/Makefile|   2 +
>>>  drivers/media/platform/tegra-cec/Makefile  |   1 +
>>>  drivers/media/platform/tegra-cec/tegra_cec.c   | 501 
>>> +
>>>  drivers/media/platform/tegra-cec/tegra_cec.h   | 127 ++
>>>  13 files changed, 711 insertions(+), 1 deletion(-)
>>>  create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt
>>>  create mode 100644 drivers/media/platform/tegra-cec/Makefile
>>>  create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
>>>  create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h
>>>
>>

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


[PATCH v3] drm/tilcdc: Precalculate total frametime in tilcdc_crtc_set_mode()

2017-10-14 Thread Jyri Sarha
We need the total frame refresh time to check if we are too close to
vertical sync when updating the two framebuffer DMA registers and risk
a collision. This new method is more accurate that the previous that
based on mode's vrefresh value, which itself is inaccurate or may not
even be initialized.

Reported-by: Kevin Hao 
Fixes: 11abbc9f39e0 ("drm/tilcdc: Set framebuffer DMA address to HW only if 
CRTC is enabled")
Cc:  # v4.11+
Signed-off-by: Jyri Sarha 
Reviewed-by: Tomi Valkeinen 
---
This is the final version that is going to be in my tilcdc v4.15 pull request.

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 704db24..6ef4d1a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "tilcdc_drv.h"
 #include "tilcdc_regs.h"
@@ -48,6 +49,7 @@ struct tilcdc_crtc {
unsigned int lcd_fck_rate;
 
ktime_t last_vblank;
+   unsigned int hvtotal_us;
 
struct drm_framebuffer *curr_fb;
struct drm_framebuffer *next_fb;
@@ -292,6 +294,12 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
LCDC_V2_CORE_CLK_EN);
 }
 
+uint tilcdc_mode_hvtotal(const struct drm_display_mode *mode)
+{
+   return (uint) div_u64(1000llu * mode->htotal * mode->vtotal,
+ mode->clock);
+}
+
 static void tilcdc_crtc_set_mode(struct drm_crtc *crtc)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
@@ -459,6 +467,9 @@ static void tilcdc_crtc_set_mode(struct drm_crtc *crtc)
drm_framebuffer_get(fb);
 
crtc->hwmode = crtc->state->adjusted_mode;
+
+   tilcdc_crtc->hvtotal_us =
+   tilcdc_mode_hvtotal(&crtc->hwmode);
 }
 
 static void tilcdc_crtc_enable(struct drm_crtc *crtc)
@@ -642,7 +653,7 @@ int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
spin_lock_irqsave(&tilcdc_crtc->irq_lock, flags);
 
next_vblank = ktime_add_us(tilcdc_crtc->last_vblank,
-  100 / crtc->hwmode.vrefresh);
+  tilcdc_crtc->hvtotal_us);
tdiff = ktime_to_us(ktime_sub(next_vblank, ktime_get()));
 
if (tdiff < TILCDC_VBLANK_SAFETY_THRESHOLD_US)
-- 
1.9.1


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


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


[GIT PULL] tilcdc changes for 4.15

2017-10-14 Thread Jyri Sarha
Hi Dave,
Please pull the accumulated minor tilcdc changes and fixed for
v4.15. These small patches have been accumulated over a period of
several Linux releases.

Best regards and thanks,
Jyri

The following changes since commit ebec44a2456fbe5fe18aae88f6010f6878f0cb4a:

  BackMerge tag 'v4.14-rc3' into drm-next (2017-10-03 09:35:04 +1000)

are available in the git repository at:


  https://github.com/jsarha/linux tags/tilcdc-4.15

for you to fetch changes up to 44cd3939c111b78a9fc6e3136fb0f9b6f475f68a:

  drm/tilcdc: Remove redundant OF_DETACHED flag setting (2017-10-13
15:25:11 +0300)


tilcdc changes for v4.15


Arvind Yadav (2):
  drm/tilcdc: tilcdc_panel: make of_device_ids const.
  drm/tilcdc: tilcdc_tfp410: make of_device_ids const.

Cihangir Akturk (1):
  drm/tilcdc: switch to drm_*{get,put} helpers

Jyri Sarha (4):
  drm/tilcdc: Turn raster off in crtc reset, if it was on in the HW
  drm/tilcdc: Remove WARN_ON(!drm_modeset_is_locked(&crtc->mutex))
checks
  drm/tilcdc: Use tilcdc_crtc_shutdown() in tilcdc_crtc_destroy()
  drm/tilcdc: Precalculate total frametime in tilcdc_crtc_set_mode()

Stephen Boyd (1):
  drm/tilcdc: Remove redundant OF_DETACHED flag setting

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 57
++--
 drivers/gpu/drm/tilcdc/tilcdc_panel.c|  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c   |  4 +-
 4 files changed, 47 insertions(+), 17 deletions(-)

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


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


[Bug 103276] VEGA 64 3D Opengl does not work with kernel amd staging 4.13 on Fedora core 26

2017-10-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103276

Bug ID: 103276
   Summary: VEGA 64 3D Opengl does not work with kernel amd
staging 4.13 on Fedora core 26
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: giovanni.nic...@ticino.com
QA Contact: dri-devel@lists.freedesktop.org

from Xorg LOG


glamor: OpenGL accelerated X.org driver based.
[   292.479] (II) glamor: EGL version 1.4 (DRI2):
[   292.479] EGL_MESA_drm_image required.
WHAT MEANS THIS?
[   292.480] (EE) AMDGPU(G0): glamor detected, failed to initialize EGL.


AND GLXINFO says render LLVMPIPE

AND GLXGEARS WITH LIBGL_DEBUG=VERBOSE says scrreen does not support DRI2


if i start Gnome in root the  rendere is radeonsi and 3d accel works

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

2017-10-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103277

Bug ID: 103277
   Summary: [bisected] Systems hangs on resume from S3 sleep due
to "Match actual state during S3 resume" commit
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: jb5sgc1n@20mm.eu

After I updated my kernel to
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next as of
today (latest commit at this time:
1c630e83443a0f271c192ecfa0d94023661a) I noticed that my computer would no
longer wake up from S3 sleep - power LED goes on, but apart from that no
display and no reaction to any input (other than Num-Lock still switchable).

The difference to the ~2 weeks older kernel was 100% reproducable by just
doing:

- boot to console (no start of X11 required) and login as root
- echo "mem" >/sys/power/state
- wait till power LED blinks
- press some key to wake up the system
- observe no display output and no reaction to anything

GPU is a RX 460, CPU a Ryzen R7 1800X, board Asus X370 Pro, connected is one 4k
display via HDMI 2.0.

I bisected the git commits, and the one that causes the bug is:

>  7ae4acd21e9e264afb079e23d43bcf2238c7dbea
>  drm/amd/display: Match actual state during S3 resume.

After this, I went back to the current HEAD of amd-staging-drm-next and
(manually) reverted only commit 7ae4acd21e9e264afb079e23d43bcf2238c7dbea, and
this indeed results in a kernel that works fine with regards to resuming from
S3 sleep.

There are no noteworthy "dmesg"-emissions that accompany going to S3 sleep, but
the dmesg-output that I can collect ends slightly before the system actually
sleeps, so wether anything is emitted upon the wake-up attempt, I have no way
to know.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

2017-10-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103277

--- Comment #1 from dwagner  ---
Created attachment 134842
  --> https://bugs.freedesktop.org/attachment.cgi?id=134842&action=edit
dmesg of system before it fails to resume from S3 sleep

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 103102] Cannot wake-up with an AMD RX 480 on Linux 4.13 and Linux 4.14

2017-10-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103102

--- Comment #11 from Hadrien  ---
I've been setting vblank_time_us to 0x7fff, 0x, 0x00ff and I
get the same problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 103130] Mesa from git causes games to crash mid-play

2017-10-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103130

--- Comment #4 from Adam  ---
This is the repo that didn't work:
http://download.opensuse.org/repositories/home:/forkbomb:/turboAMD/openSUSE_Tumbleweed/


This is the one that did:
http://download.opensuse.org/repositories/home:/forkbomb:/turboAMD-stable/openSUSE_Tumbleweed/

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel