[PATCH 2/8] drm/rockchip: Get rid of some unnecessary code

2016-09-18 Thread Mark yao
On 2016年09月14日 20:54, Tomasz Figa wrote:
> Current code implements prepare_fb and cleanup_fb callbacks only to
> grab/release fb references, which is already done by atomic framework
> when creating/destryoing plane state. Let's remove these
> unused bits.
>
> Signed-off-by: Tomasz Figa 
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 --
>   1 file changed, 18 deletions(-)

Hi Tomasz

I think we can't get rid of the prepare_fb and cleanup_fb

see the reason:
commit 44d0237a26395ac94160cf23f32769013b365590
Author: Mark Yao 
Date:   Fri Apr 29 11:37:20 2016 +0800

 drm/rockchip: vop: fix iommu crash with async atomic

 After async atomic_commit callback, drm_atomic_clean_old_fb will
 clean all old fb, but because async, the old fb may be also on
 the vop hardware, dma will access the old fb buffer, clean old
 fb will cause iommu page fault.

 Reference the fb and unreference it when the fb actuall swap out
 from vop hardware.


> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 7e811cf..68988c6 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -641,22 +641,6 @@ static void vop_plane_destroy(struct drm_plane *plane)
>   drm_plane_cleanup(plane);
>   }
>   
> -static int vop_plane_prepare_fb(struct drm_plane *plane,
> - struct drm_plane_state *new_state)
> -{
> - if (plane->state->fb)
> - drm_framebuffer_reference(plane->state->fb);
> -
> - return 0;
> -}
> -
> -static void vop_plane_cleanup_fb(struct drm_plane *plane,
> -  struct drm_plane_state *old_state)
> -{
> - if (old_state->fb)
> - drm_framebuffer_unreference(old_state->fb);
> -}
> -
>   static int vop_plane_atomic_check(struct drm_plane *plane,
>  struct drm_plane_state *state)
>   {
> @@ -849,8 +833,6 @@ static void vop_plane_atomic_update(struct drm_plane 
> *plane,
>   }
>   
>   static const struct drm_plane_helper_funcs plane_helper_funcs = {
> - .prepare_fb = vop_plane_prepare_fb,
> - .cleanup_fb = vop_plane_cleanup_fb,
>   .atomic_check = vop_plane_atomic_check,
>   .atomic_update = vop_plane_atomic_update,
>   .atomic_disable = vop_plane_atomic_disable,


-- 
ï¼­ark Yao




[Bug 102401] Radeon Displayport Audio Warping

2016-09-18 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=102401

--- Comment #13 from Maxqia  ---
Looking back with an extra year of programming knowledge, it seems like commit
7726e72b3d6879ee5fc743a230eb6f5afa12844b doesn't do anything except add a
drm_detect_monitor_audio to the hdmi audio pathway ..., before that commit only
Displayport was checked for audio. Anyways, issue still present.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 102401] Radeon Displayport Audio Warping

2016-09-18 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=102401

Maxqia  changed:

   What|Removed |Added

 Attachment #185441|0   |1
is obsolete||

--- Comment #14 from Maxqia  ---
Created attachment 238501
  --> https://bugzilla.kernel.org/attachment.cgi?id=238501&action=edit
Explained Patch

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[PATCH 2/8] drm/rockchip: Get rid of some unnecessary code

2016-09-18 Thread Tomasz Figa
Hi Mark,

On Sun, Sep 18, 2016 at 10:50 AM, Mark yao  wrote:
> On 2016年09月14日 20:54, Tomasz Figa wrote:
>>
>> Current code implements prepare_fb and cleanup_fb callbacks only to
>> grab/release fb references, which is already done by atomic framework
>> when creating/destryoing plane state. Let's remove these
>> unused bits.
>>
>> Signed-off-by: Tomasz Figa 
>> ---
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 --
>>   1 file changed, 18 deletions(-)
>
>
> Hi Tomasz
>
> I think we can't get rid of the prepare_fb and cleanup_fb

I think I have to disagree. Please see below for detailed explanation.

>
> see the reason:
> commit 44d0237a26395ac94160cf23f32769013b365590
> Author: Mark Yao 
> Date:   Fri Apr 29 11:37:20 2016 +0800
>
> drm/rockchip: vop: fix iommu crash with async atomic
>
> After async atomic_commit callback, drm_atomic_clean_old_fb will
> clean all old fb, but because async, the old fb may be also on
> the vop hardware, dma will access the old fb buffer, clean old
> fb will cause iommu page fault.

I think the above is not quite right. Atomic plane state holds a
reference to its fb and old state is not supposed to be destroyed
until the flip completes.

Indeed current rockchip_atomic_commit implementation has following
order of calls: rockchip_atomic_wait_for_complete(),
drm_atomic_helper_cleanup_planes(), drm_atomic_state_free(). This
means that .cleanup_fb() is called from
drm_atomic_helper_cleanup_planes() just before drm_atomic_state_free()
will release references by destroying old plane states. Note that both
are called already after rockchip_atomic_wait_for_complete(), so it
should be already safe to free the old fbs.

So the above fix doesn't really do anything, possibly just covers the
race condition of the original wait for vblank function by delaying
drm_atomic_state_free() a bit.

Moreover, the whole series has been thoroughly tested in Chrome OS 4.4
kernel, including async commits. (There is still a possibility some
newer upstream changes slightly modified the semantics, but I couldn't
find such difference. Actually one of the advantages of atomic helpers
was to avoid manually refcounting the fbs from the driver.)

Best regards,
Tomasz


[Bug 117151] amdgpu: Fails to initialize R7 260x (Bonaire)

2016-09-18 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=117151

Parker Reed  changed:

   What|Removed |Added

 Resolution|CODE_FIX|PATCH_ALREADY_AVAILABLE

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[PATCH v3 1/4] drm/bridge: Add RGB to VGA bridge support

2016-09-18 Thread Meng Yi
Hi Maxime,

> +
> +static struct drm_encoder *
> +dumb_vga_best_encoder(struct drm_connector *connector)
> +{
> + struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> +
> + return vga->bridge.encoder;
> +}
> +
> +static struct drm_connector_helper_funcs dumb_vga_con_helper_funcs = {
> + .get_modes  = dumb_vga_get_modes,
> + .best_encoder   = dumb_vga_best_encoder,
> +};
> +

We have a 1:1 relationship between connectors and encoders, and the driver
is relying on the atomic helpers: we can drop the custom ->best_encoder(),
and let the core call drm_atomic_helper_best_encoder() for us.

Meng


[PATCH v3 1/4] drm/bridge: Add RGB to VGA bridge support

2016-09-18 Thread Laurent Pinchart
Hi Maxime,

Thank you for the patch.

On Thursday 08 Sep 2016 14:17:48 Maxime Ripard wrote:
> Some boards have an entirely passive RGB to VGA bridge, based on either
> DACs or resistor ladders.
> 
> Those might or might not have an i2c bus routed to the VGA connector in
> order to access the screen EDIDs.
> 
> Add a bridge that doesn't do anything but expose the modes available on the
> screen, either based on the EDIDs if available, or based on the XGA
> standards.
> 
> Acked-by: Rob Herring 
> Signed-off-by: Maxime Ripard 
> ---
>  .../bindings/display/bridge/rgb-to-vga-bridge.txt  |  52 +
>  drivers/gpu/drm/bridge/Kconfig |   6 +
>  drivers/gpu/drm/bridge/Makefile|   1 +
>  drivers/gpu/drm/bridge/rgb-to-vga.c| 232 ++
>  4 files changed, 291 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
> 
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> new file mode 100644
> index ..83a053fb51a0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> @@ -0,0 +1,52 @@
> +Passive RGB to VGA bridge
> +-
> +
> +This binding is aimed for entirely passive RGB to VGA bridges that do not
> +require any configuration.

Couldn't it also support active RGB to VGA bridges that don't require any 
configuration ? It would seem a bit pointless to define a separate DT binding 
for them.

> +Required properties:
> +
> +- compatible: Must be "rgb-to-vga-bridge"
> +
> +Required nodes:
> +
> +This device has two video ports. Their connections are modeled using the OF
> +graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 for RGB input
> +- Video port 1 for VGA output
> +
> +
> +Example
> +---
> +
> +bridge {
> + compatible = "rgb-to-vga-bridge";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint {
> + remote-endpoint = <&tcon0_out_vga>;
> + };
> + };
> +
> + port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint {
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> +};
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index b590e678052d..42b95adf5091 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -17,6 +17,12 @@ config DRM_ANALOGIX_ANX78XX
> the HDMI output of an application processor to MyDP
> or DisplayPort.
> 
> +config DRM_RGB_TO_VGA
> + tristate "Dumb RGB to VGA Bridge support"
> + select DRM_KMS_HELPER
> + help
> +   Support for passive RGB to VGA bridges
> +
>  config DRM_DW_HDMI
>   tristate
>   select DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/bridge/Makefile
> b/drivers/gpu/drm/bridge/Makefile index efdb07e878f5..3bb8cbe09fe9 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,6 +1,7 @@
>  ccflags-y := -Iinclude/drm
> 
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> +obj-$(CONFIG_DRM_RGB_TO_VGA) += rgb-to-vga.o
>  obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> diff --git a/drivers/gpu/drm/bridge/rgb-to-vga.c
> b/drivers/gpu/drm/bridge/rgb-to-vga.c new file mode 100644
> index ..84b1b10198a4
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/rgb-to-vga.c
> @@ -0,0 +1,232 @@
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct dumb_vga {
> + struct drm_bridge   bridge;
> + struct drm_connectorconnector;
> +
> + struct i2c_adapter  *ddc;
> +};
> +
> +static inline struct dumb_vga *
> +drm_bridge_to_dumb_vga(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct dumb_vga, bridge);
> +}
> +
> +static inline struct dumb_vga *
> +drm_connector_to_dumb_vga(struct drm_connector *connector)
> +{
> + return container_of(connector, struct dumb_vga, connector);
> +}
> +
> +static int dumb_vga_get_modes(struct drm_connector *connector)
> +{
> + struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> + struct edid *edid;
> + int ret;
> +
> +   

[PATCH v3 1/4] drm/bridge: Add RGB to VGA bridge support

2016-09-18 Thread Laurent Pinchart
On Sunday 18 Sep 2016 13:01:16 Laurent Pinchart wrote:
> On Thursday 08 Sep 2016 14:17:48 Maxime Ripard wrote:
> > Some boards have an entirely passive RGB to VGA bridge, based on either
> > DACs or resistor ladders.
> > 
> > Those might or might not have an i2c bus routed to the VGA connector in
> > order to access the screen EDIDs.
> > 
> > Add a bridge that doesn't do anything but expose the modes available on
> > the screen, either based on the EDIDs if available, or based on the XGA
> > standards.
> > 
> > Acked-by: Rob Herring 
> > Signed-off-by: Maxime Ripard 
> > ---
> > 
> >  .../bindings/display/bridge/rgb-to-vga-bridge.txt  |  52 +
> >  drivers/gpu/drm/bridge/Kconfig |   6 +
> >  drivers/gpu/drm/bridge/Makefile|   1 +
> >  drivers/gpu/drm/bridge/rgb-to-vga.c| 232 
> >  4 files changed, 291 insertions(+)
> >  create mode 100644
> > 
> > Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > new file mode 100644
> > index ..83a053fb51a0
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > @@ -0,0 +1,52 @@
> > +Passive RGB to VGA bridge
> > +-
> > +
> > +This binding is aimed for entirely passive RGB to VGA bridges that do not
> > +require any configuration.
> 
> Couldn't it also support active RGB to VGA bridges that don't require any
> configuration ? It would seem a bit pointless to define a separate DT
> binding for them.

I'm thinking in particular about the ADV7123 
(http://www.analog.com/media/en/technical-documentation/data-sheets/ADV7123.pdf)
 that already has a DT binding. Would it be feasible to 
combine the two, and support both devices with a single driver ?

> > +Required properties:
> > +
> > +- compatible: Must be "rgb-to-vga-bridge"
> > +
> > +Required nodes:
> > +
> > +This device has two video ports. Their connections are modeled using the
> > OF +graph bindings specified in
> > Documentation/devicetree/bindings/graph.txt. +
> > +- Video port 0 for RGB input
> > +- Video port 1 for VGA output
> > +
> > +
> > +Example
> > +---
> > +
> > +bridge {
> > +   compatible = "rgb-to-vga-bridge";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port at 0 {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   reg = <0>;
> > +
> > +   vga_bridge_in: endpoint {
> > +   remote-endpoint = <&tcon0_out_vga>;
> > +   };
> > +   };
> > +
> > +   port at 1 {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   reg = <1>;
> > +
> > +   vga_bridge_out: endpoint {
> > +   remote-endpoint = <&vga_con_in>;
> > +   };
> > +   };
> > +   };
> > +};

-- 
Regards,

Laurent Pinchart



[ADV7393] DRM Encoder Slave or DRM Bridge

2016-09-18 Thread Laurent Pinchart
Hi Vikas,

On Monday 12 Sep 2016 17:59:36 Vikas Patil wrote:
> Dear All,
> 
> I am trying to understand difference between "DRM Encoder slave
> driver" and "DRM bridge driver" as I need to write one for ADV7393
> Video Encoder Chip for the custom target
> based on DRA74x having following display connection.
> 
> VOUT1 --> ADV7393 --> CVBS Out(ADV7393 is on I2C)
> 
> Could anyone here explain what is the difference between two and which
> I need to implement for ADV7393 and why?

The DRM slave encoder predates the DRM bridge frameworks. It's now considered 
as legacy and should not be used. All new code should target DRM bridge.

> I could see adv7393 driver available at "drivers/media/i2c/adv7393.c"
> in linux 4.4.14. Can I use this driver? My feeling is I can not use
> but why could not much understand.
> or Do I need to base my driver something like
> "drivers/gpu/drm/i2c/adv7511.c", however I also see it is converted to
> bridge driver and moved to  "drivers/gpu/drm/bridge/adv7511.c" [1]
> 
> [1] http://www.spinics.net/lists/dri-devel/msg113244.html

-- 
Regards,

Laurent Pinchart



[PATCH v4.1 01/14] drm: Centralize format information

2016-09-18 Thread Laurent Pinchart
Various pieces of information about DRM formats (number of planes, color
depth, chroma subsampling, ...) are scattered across different helper
functions in the DRM core. Callers of those functions often need to
access more than a single parameter of the format, leading to
inefficiencies due to multiple lookups.

Centralize all format information in a data structure and create a
function to look up information based on the format 4CC.

Signed-off-by: Laurent Pinchart 
---
Changes since v4:

- Fixed depth value of DRM_FORMAT_[AXRGB]{4} formats to match
  current code
- Documented the depth field as legacy
---
 Documentation/gpu/drm-kms.rst |  3 ++
 drivers/gpu/drm/drm_fourcc.c  | 84 +++
 include/drm/drm_fourcc.h  | 21 +++
 3 files changed, 108 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index f9a991bb87d4..85c4c49f4436 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -63,6 +63,9 @@ Frame Buffer Functions Reference
 DRM Format Handling
 ===

+.. kernel-doc:: include/drm/drm_fourcc.h
+   :internal:
+
 .. kernel-doc:: drivers/gpu/drm/drm_fourcc.c
:export:

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 29c56b4331e0..39f09c564111 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -103,6 +103,90 @@ char *drm_get_format_name(uint32_t format)
 EXPORT_SYMBOL(drm_get_format_name);

 /**
+ * drm_format_info - query information for a given format
+ * @format: pixel format (DRM_FORMAT_*)
+ *
+ * Returns:
+ * The instance of struct drm_format_info that describes the pixel format, or
+ * NULL if the format is unsupported.
+ */
+const struct drm_format_info *drm_format_info(u32 format)
+{
+   static const struct drm_format_info formats[] = {
+   { .format = DRM_FORMAT_C8,  .depth = 8,  
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_RGB332,  .depth = 8,  
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_BGR233,  .depth = 8,  
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XRGB,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XBGR,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_RGBX,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_BGRX,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_ARGB,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_ABGR,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_RGBA,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_BGRA,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XRGB1555,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XBGR1555,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_RGBX5551,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_BGRX5551,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_ARGB1555,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_ABGR1555,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_RGBA5551,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_BGRA5551,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_RGB565,  .depth = 16, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_BGR565,  .depth = 16, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_RGB888,  .depth = 24, 
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_BGR888,  .depth = 24, 
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XRGB,.depth = 24, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub 

UDL: screen update breakage

2016-09-18 Thread Noralf Trønnes

Den 13.09.2016 16:44, skrev poma:
> https://bugzilla.redhat.com/show_bug.cgi?id=1375566
>
> Guys,
> do you use such a device - DisplayLink GPU USB2.0 ?
>

I haven't got such a display.
You can try to revert just the changes in udl_handle_damage().
The other changes are for fbdev.

Noralf.



[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650

2016-09-18 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=153121

Kontantin Ivanov  changed:

   What|Removed |Added

   Severity|normal  |low

--- Comment #38 from Kontantin Ivanov  ---
There is an opinion that the problem is not inside radeon driver but inside
i915/intel driver. I downgraded my system to Ubuntu 14.04 (3.11 kernel) and
tried to install fglrx (proprietary AMD driver). It doesn't  works. X server
starts normally but screen is show me last image (kubuntu start splash and
mouse cursor) and then it freezes. Xorg.log does'n show anything. Digging
deeper I found some solution that requires modified intel driver
.
Unfortunately the man, who developed it, removed the package from launchpad.

I've changed urgency to low again, because who cares about old, stupid
hardware.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[PATCH 10/23] drm: omapdrm: Use atomic state instead of local device state

2016-09-18 Thread Laurent Pinchart
Hi Daniel,

On Monday 06 Jun 2016 04:14:59 Laurent Pinchart wrote:
> On Wednesday 11 May 2016 09:37:56 Daniel Vetter wrote:
> > On Tue, May 10, 2016 at 04:24:11PM +0300, Tomi Valkeinen wrote:
> >> On 26/04/16 23:35, Laurent Pinchart wrote:
> >>> Instead of conditioning planes update based on the hardware device
> >>> state, use the CRTC state stored in the atomic state. This reduces the
> >>> dependency from the DRM layer to the DSS layer.
> >>> 
> >>> Signed-off-by: Laurent Pinchart 
> >>> ---
> >>> 
> >>>  drivers/gpu/drm/omapdrm/omap_crtc.c | 23 ++-
> >>>  1 file changed, 14 insertions(+), 9 deletions(-)
> >>> 
> >>> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> >>> b/drivers/gpu/drm/omapdrm/omap_crtc.c index 6359d7933b93..4c56d6a68390
> >>> 100644
> >>> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> >>> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> >>> @@ -381,18 +381,23 @@ static void omap_crtc_atomic_flush(struct
> >>> drm_crtc *crtc,
> >>> 
> >>>   WARN_ON(omap_crtc->vblank_irq.registered);
> >>> 
> >>> - if (dispc_mgr_is_enabled(omap_crtc->channel)) {
> >>> + /*
> >>> +  * Only flush the CRTC if it is currently active. CRTCs that require
> >>> a
> >>> +  * mode set are disabled prior plane updates and enabled afterwards.
> >>> +  * They are thus not active, regardless of what their state report.
> >>> +  */
> >>> + if (!crtc->state->active ||
> >>> drm_atomic_crtc_needs_modeset(crtc->state))
> >>> + return;
> >> 
> >> If the DRM core doesn't track whether a CRTC HW is enabled at the
> >> moment, maybe omapdrm should? I guess the above works, but that if()
> >> makes me a bit uneasy, as it's not really obvious, and the logic behind
> >> it could possibly change later...
> >> 
> >> A "if (crtc->is_hw_enabled)" would be much more readable.
> 
> The whole point of this patch is to remove local state and rely on DRM core
> state, so I'd like to avoid that if possible.
> 
> > Look at the active_only paramater of the planes_commit helper. That should
> > do exactly what you want.
> 
> The drm_atomic_helper_commit_planes() helper has this check
> 
> if (active_only && !crtc->state->active)
> continue;
> 
> funcs->atomic_flush(crtc, old_crtc_state);
> 
> I could thus remove the !crtc->state->active check, but the
> drm_atomic_crtc_needs_modeset() check would need to stay, wouldn't it ? When
> CRTCs go through a modeset they are disabled prior to plane updates, but
> their state active status can still be true. Or should that be fixed in the
> core ?

Any comment on this ? Knowing whether the CRTC hardware is enabled is helpful 
to implement the flush() function. Would it make sense to add a new "is 
hardware enabled" flag to the CRTC structure (or possibly the CRTC state 
structure, but given that there is by definition a single instance of the 
hardware state the CRTC structure would make more sense) ?

-- 
Regards,

Laurent Pinchart



[Bug 97605] AMDGPU Black Screen when Booting

2016-09-18 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97605

--- Comment #6 from James Payne  ---
Hi Michel/Timo

I have previously managed to get the system booting (albeit with the same
screen issues) but for some reason the newer kernels (I've tried 4.7RC6 and
DRM-Next as of today 18th Sept) and both are failing to boot entirely, don't
even get to bring up the wired network which I have managed to open a SSH
session between two laptops to at least interrogate the non functioning laptop
now. Though messing with the kernels seems to have caused some huge corruption
on the filesystem through all the system buttoning I'm having to do :) Another
reinstall required I think.

Is there a specific kernel (maybe not bleeding edge) that I can try? - fyi I
also have a Broadcom wireless which is attempting to compile a kernel module
during each deb install, I noticed on those two kernels the module failed to
compile correctly so might be where the issue is coming from.

For reference, I originally posted this on launchpad which has a few more
details collected from apport:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1597079

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/95f1399c/attachment.html>


[Bug 97605] AMDGPU Black Screen when Booting

2016-09-18 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97605

--- Comment #7 from James Payne  ---
Just noticed I did list the kernels I had previously tried in the Ubuntu bug
report:

v4.7-rc5-yakkety/
v4.4.4-wily/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/fe8db372/attachment.html>


[PATCH] drm/udl: Fix for the X server screen update

2016-09-18 Thread poma
Fix for DisplayLink GPU USB2.0 device X server screen update

Within X server on top of DisplayLink GPU USB2.0 device,
screen content is not refreshed i.e. updated,
which is the most basic functionality of the screen.

This partially (udl_handle_damage()) reverts commit:

- e375882406d0cc24030746638592004755ed4ae0
  "drm/udl: Use drm_fb_helper deferred_io support"

Thanks Noralf for the tip.

$ modinfo udl
filename:   /lib/modules/4.7.4-234.fc24.x86_64/updates/udl.ko
license:GPL
alias:  usb:v17E9p*d*dc*dsc*dp*icFFisc00ip00in*
depends:
intree: Y
vermagic:   4.7.4-234.fc24.x86_64 SMP mod_unload 
parm:   fb_bpp:int
parm:   fb_defio:int

$ dmesg | grep udl
[   41.888469] udl: module verification failed: signature and/or required key 
missing - tainting kernel
[   42.156988] udl 1-2:1.0: fb1: udldrmfb frame buffer device
[   42.158940] [drm] Initialized udl on minor 1
[   42.159676] usbcore: registered new interface driver udl

$ grep udl /var/log/Xorg.0.log
[71.194] (**) |   |-->Device "udl0"

Tested-by: poma 
---
 drivers/gpu/drm/udl/udl_drv.h |  2 ++
 drivers/gpu/drm/udl/udl_fb.c  | 39 +--
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 0b03d34..4a064ef 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -81,6 +81,8 @@ struct udl_framebuffer {
struct drm_framebuffer base;
struct udl_gem_object *obj;
bool active_16; /* active on the 16-bit channel */
+   int x1, y1, x2, y2; /* dirty rect */
+   spinlock_t dirty_lock;
 };

 #define to_udl_fb(x) container_of(x, struct udl_framebuffer, base)
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index d5df555..b2b42d2 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -90,6 +90,9 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, int 
y,
struct urb *urb;
int aligned_x;
int bpp = (fb->base.bits_per_pixel / 8);
+   int x2, y2;
+   bool store_for_later = false;
+   unsigned long flags;

if (!fb->active_16)
return 0;
@@ -115,6 +118,38 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
(y + height > fb->base.height))
return -EINVAL;

+   /* if we are in atomic just store the info
+  can't test inside spin lock */
+   if (in_atomic())
+   store_for_later = true;
+
+   x2 = x + width - 1;
+   y2 = y + height - 1;
+
+   spin_lock_irqsave(&fb->dirty_lock, flags);
+
+   if (fb->y1 < y)
+   y = fb->y1;
+   if (fb->y2 > y2)
+   y2 = fb->y2;
+   if (fb->x1 < x)
+   x = fb->x1;
+   if (fb->x2 > x2)
+   x2 = fb->x2;
+
+   if (store_for_later) {
+   fb->x1 = x;
+   fb->x2 = x2;
+   fb->y1 = y;
+   fb->y2 = y2;
+   spin_unlock_irqrestore(&fb->dirty_lock, flags);
+   return 0;
+   }
+
+   fb->x1 = fb->y1 = INT_MAX;
+   fb->x2 = fb->y2 = 0;
+
+   spin_unlock_irqrestore(&fb->dirty_lock, flags);
start_cycles = get_cycles();

urb = udl_get_urb(dev);
@@ -122,14 +157,14 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
return 0;
cmd = urb->transfer_buffer;

-   for (i = y; i < height ; i++) {
+   for (i = y; i <= y2 ; i++) {
const int line_offset = fb->base.pitches[0] * i;
const int byte_offset = line_offset + (x * bpp);
const int dev_byte_offset = (fb->base.width * bpp * i) + (x * 
bpp);
if (udl_render_hline(dev, bpp, &urb,
 (char *) fb->obj->vmapping,
 &cmd, byte_offset, dev_byte_offset,
-width * bpp,
+(x2 - x + 1) * bpp,
 &bytes_identical, &bytes_sent))
goto error;
}
-- 
2.7.4




[PATCH v4 0/3] gpu: drm: exynos_hdmi: Code refactoring on hdmi ddc and phy

2016-09-18 Thread Inki Dae
Hi,

Thanks for your contribution.

Seems good to me. Will picked them up soon if no critical issues.

Thanks,
Inki Dae


2016-08-31 15:14 GMT+09:00 Milo Kim :

> v4:
>   Only DRM patchset is sent, DTS patch was sent separately.
>
> Milo Kim (3):
>   gpu: drm: exynos_hdmi: Move DDC logic into single function
>   gpu: drm: exynos_hdmi: Move PHY logic into single function
>   gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator
> bulk consumer
>
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 112 ++
> -
>  1 file changed, 59 insertions(+), 53 deletions(-)
>
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/c3287d43/attachment.html>


[GIT PULL] exynos-drm-fixes

2016-09-18 Thread Inki Dae
Hi Dave,

   Just fixup to runtime pm usage and some cleanups.

   Please kindly let me know if there is any problem.

   Ps. We will request git-pull for -next soon if no critical issue,
   which includes only code refactoring on hdmi ddc and phy.

Thanks,
Inki Dae

The following changes since commit 09cb5b78af52208afb9f1b194c8a9154df4a4782:

  Merge tag 'drm-vc4-fixes-2016-09-14' of https://github.com/anholt/linux into 
drm-fixes (2016-09-17 07:57:55 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-fixes

for you to fetch changes up to f14b71e73240a6264f5ea71879219f97fd227e34:

  Subject: [PATCH, RESEND] drm: exynos: avoid unused function warning 
(2016-09-18 22:52:29 +0900)


Arnd Bergmann (1):
  Subject: [PATCH, RESEND] drm: exynos: avoid unused function warning

Marek Szyprowski (4):
  drm/exynos: fimc: fix system and runtime pm integration
  drm/exynos: gsc: fix system and runtime pm integration
  drm/exynos: rotator: fix system and runtime pm integration
  drm/exynos: g2d: fix system and runtime pm integration

Shuah Khan (1):
  exynos-drm: Fix unsupported GEM memory type error message to be clear

 drivers/gpu/drm/exynos/exynos_drm_fb.c  |6 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   29 ++-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |   29 ++-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   34 ---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   26 ++--
 5 files changed, 18 insertions(+), 106 deletions(-)


[Bug 94900] HD6950 GPU lockup loop with various steam games (octodad[always], saints row 4[always], dead island[always], grid autosport[sometimes])

2016-09-18 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94900

--- Comment #25 from russianneuromancer at ya.ru ---
But how this will affect performance with other games that doesn't freeze?
There is no other way to fix this?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/ea5eae49/attachment-0001.html>


[Bug 97849] kworker uses 100% CPU when using _only_ HDMI output with AMDGPU on Carrizo R7 (vanilla 4.7.4)

2016-09-18 Thread bugzilla-dae...@freedesktop.org
▒
amdgpu_hotplug_work_func   
▒
drm_helper_hpd_irq_event   
▒
amdgpu_connector_dp_detect 
▒
amdgpu_atombios_encoder_set_edp_panel_power
▒
amdgpu_atom_execute_table  
▒
  - amdgpu_atom_execute_table_locked   
▒
 - 1.57% atom_op_calltable 
▒
- amdgpu_atom_execute_table_locked 
▒
   - 1.51% atom_op_test
▒
atom_get_src_int



-   76.00% 0.17%  kworker/3:0  [amdgpu]  [k] cail_reg_read 
▒
   - 75.83% cail_reg_read  
▒
75.66% amdgpu_mm_rreg



-   75.91%75.91%  kworker/3:0  [amdgpu]  [k] amdgpu_mm_rreg
▒
 ret_from_fork 
▒
 kthread   
▒
 worker_thread 
▒
 process_one_work  
▒
 amdgpu_hotplug_work_func  
▒
 drm_helper_hpd_irq_event  
▒
   - amdgpu_connector_dp_detect
▒
  - 75.88% amdgpu_atombios_encoder_set_edp_panel_power 
▒
 - 75.73% amdgpu_atom_execute_table
▒
  amdgpu_atom_execute_table_locked 
▒
  atom_op_calltable
▒
  amdgpu_atom_execute_table_locked 
▒
  atom_op_test 
▒
- atom_get_src_int 
▒
   - 75.64% cail_reg_read  
▒
amdgpu_mm_rreg

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/07feea32/attachment-0001.html>


[Bug 97634] [amdgpu SI] multigpu setup crashes during boot when dpm=1

2016-09-18 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97634

--- Comment #4 from Arek Ruśniak  ---
For new drm-next-4.9-wip and drm-next-4.9 symptoms are the same as before.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/44631405/attachment.html>


[PATCH 0/5] drm/amdgpu: Fine-tuning for several function implementations

2016-09-18 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 18 Sep 2016 18:38:48 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (5):
  Use kmalloc_array() in amdgpu_debugfs_gca_config_read()
  Improve determination of sizes in two functions
  Rename a jump label in amdgpu_debugfs_regs_read()
  Rename a jump label in amdgpu_device_init()
  Adjust checks for null pointers in nine functions

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 68 +++---
 1 file changed, 33 insertions(+), 35 deletions(-)

-- 
2.10.0



[PATCH 1/5] drm/amdgpu: Use kmalloc_array() in amdgpu_debugfs_gca_config_read()

2016-09-18 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 18 Sep 2016 17:00:52 +0200

A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index df7ab245..2709ebd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2438,7 +2438,7 @@ static ssize_t amdgpu_debugfs_gca_config_read(struct file 
*f, char __user *buf,
if (size & 0x3 || *pos & 0x3)
return -EINVAL;

-   config = kmalloc(256 * sizeof(*config), GFP_KERNEL);
+   config = kmalloc_array(256, sizeof(*config), GFP_KERNEL);
if (!config)
return -ENOMEM;

-- 
2.10.0



[PATCH 2/5] drm/amdgpu: Improve determination of sizes in two functions

2016-09-18 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 18 Sep 2016 17:24:47 +0200

Replace the specification of data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 2709ebd..96a2457 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -855,7 +855,7 @@ static void amdgpu_atombios_fini(struct amdgpu_device *adev)
 static int amdgpu_atombios_init(struct amdgpu_device *adev)
 {
struct card_info *atom_card_info =
-   kzalloc(sizeof(struct card_info), GFP_KERNEL);
+   kzalloc(sizeof(*atom_card_info), GFP_KERNEL);

if (!atom_card_info)
return -ENOMEM;
@@ -1224,7 +1224,8 @@ static int amdgpu_early_init(struct amdgpu_device *adev)
}

adev->ip_block_status = kcalloc(adev->num_ip_blocks,
-   sizeof(struct amdgpu_ip_block_status), 
GFP_KERNEL);
+   sizeof(*adev->ip_block_status),
+   GFP_KERNEL);
if (adev->ip_block_status == NULL)
return -ENOMEM;

-- 
2.10.0



[PATCH 3/5] drm/amdgpu: Rename a jump label in amdgpu_debugfs_regs_read()

2016-09-18 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 18 Sep 2016 17:35:24 +0200

Adjust jump labels according to the current Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 96a2457..2b8ba97 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2208,13 +2208,13 @@ static ssize_t amdgpu_debugfs_regs_read(struct file *f, 
char __user *buf,
uint32_t value;

if (*pos > adev->rmmio_size)
-   goto end;
+   goto check_bank;

value = RREG32(*pos >> 2);
r = put_user(value, (uint32_t *)buf);
if (r) {
result = r;
-   goto end;
+   goto check_bank;
}

result += 4;
@@ -,8 +,7 @@ static ssize_t amdgpu_debugfs_regs_read(struct file *f, 
char __user *buf,
*pos += 4;
size -= 4;
}
-
-end:
+ check_bank:
if (use_bank) {
amdgpu_gfx_select_se_sh(adev, 0x, 0x, 
0x);
mutex_unlock(&adev->grbm_idx_mutex);
-- 
2.10.0



[PATCH 4/5] drm/amdgpu: Rename a jump label in amdgpu_device_init()

2016-09-18 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 18 Sep 2016 17:50:09 +0200

Adjust jump labels according to the current Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 2b8ba97..fed4854 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1566,18 +1566,18 @@ int amdgpu_device_init(struct amdgpu_device *adev,
/* Read BIOS */
if (!amdgpu_get_bios(adev)) {
r = -EINVAL;
-   goto failed;
+   goto check_runtime;
}
/* Must be an ATOMBIOS */
if (!adev->is_atom_bios) {
dev_err(adev->dev, "Expecting atombios for GPU\n");
r = -EINVAL;
-   goto failed;
+   goto check_runtime;
}
r = amdgpu_atombios_init(adev);
if (r) {
dev_err(adev->dev, "amdgpu_atombios_init failed\n");
-   goto failed;
+   goto check_runtime;
}

/* See if the asic supports SR-IOV */
@@ -1595,7 +1595,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
if (!adev->bios) {
dev_err(adev->dev, "Card not posted and no BIOS - 
ignoring\n");
r = -EINVAL;
-   goto failed;
+   goto check_runtime;
}
DRM_INFO("GPU not posted. posting now...\n");
amdgpu_atom_asic_init(adev->mode_info.atom_context);
@@ -1605,7 +1605,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
r = amdgpu_atombios_get_clock_info(adev);
if (r) {
dev_err(adev->dev, "amdgpu_atombios_get_clock_info failed\n");
-   goto failed;
+   goto check_runtime;
}
/* init i2c buses */
amdgpu_atombios_i2c_init(adev);
@@ -1614,7 +1614,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
r = amdgpu_fence_driver_init(adev);
if (r) {
dev_err(adev->dev, "amdgpu_fence_driver_init failed\n");
-   goto failed;
+   goto check_runtime;
}

/* init the mode config */
@@ -1624,7 +1624,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
if (r) {
dev_err(adev->dev, "amdgpu_init failed\n");
amdgpu_fini(adev);
-   goto failed;
+   goto check_runtime;
}

adev->accel_working = true;
@@ -1634,7 +1634,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
r = amdgpu_ib_pool_init(adev);
if (r) {
dev_err(adev->dev, "IB initialization failed (%d).\n", r);
-   goto failed;
+   goto check_runtime;
}

r = amdgpu_ib_ring_tests(adev);
@@ -1682,12 +1682,11 @@ int amdgpu_device_init(struct amdgpu_device *adev,
r = amdgpu_late_init(adev);
if (r) {
dev_err(adev->dev, "amdgpu_late_init failed\n");
-   goto failed;
+   goto check_runtime;
}

return 0;
-
-failed:
+ check_runtime:
if (runtime)
vga_switcheroo_fini_domain_pm_ops(adev->dev);
return r;
-- 
2.10.0



[PATCH 5/5] drm/amdgpu: Adjust checks for null pointers in nine functions

2016-09-18 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 18 Sep 2016 18:32:28 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* The script "checkpatch.pl" can point information out like the following.

  Comparison to NULL could be written !…

  Thus fix the affected source code places.

* Do also not use curly brackets at corresponding source code places
  where a single statement should be sufficient.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33 +++---
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index fed4854..b5b7cfb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -251,7 +251,7 @@ static int amdgpu_vram_scratch_init(struct amdgpu_device 
*adev)
 {
int r;

-   if (adev->vram_scratch.robj == NULL) {
+   if (!adev->vram_scratch.robj) {
r = amdgpu_bo_create(adev, AMDGPU_GPU_PAGE_SIZE,
 PAGE_SIZE, true, AMDGPU_GEM_DOMAIN_VRAM,
 AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED,
@@ -283,9 +283,9 @@ static void amdgpu_vram_scratch_fini(struct amdgpu_device 
*adev)
 {
int r;

-   if (adev->vram_scratch.robj == NULL) {
+   if (!adev->vram_scratch.robj)
return;
-   }
+
r = amdgpu_bo_reserve(adev->vram_scratch.robj, false);
if (likely(r == 0)) {
amdgpu_bo_kunmap(adev->vram_scratch.robj);
@@ -359,9 +359,9 @@ static int amdgpu_doorbell_init(struct amdgpu_device *adev)
return -EINVAL;

adev->doorbell.ptr = ioremap(adev->doorbell.base, 
adev->doorbell.num_doorbells * sizeof(u32));
-   if (adev->doorbell.ptr == NULL) {
+   if (!adev->doorbell.ptr)
return -ENOMEM;
-   }
+
DRM_INFO("doorbell mmio base: 0x%08X\n", (uint32_t)adev->doorbell.base);
DRM_INFO("doorbell mmio size: %u\n", (unsigned)adev->doorbell.size);

@@ -456,7 +456,7 @@ static int amdgpu_wb_init(struct amdgpu_device *adev)
 {
int r;

-   if (adev->wb.wb_obj == NULL) {
+   if (!adev->wb.wb_obj) {
r = amdgpu_bo_create(adev, AMDGPU_MAX_WB * 4, PAGE_SIZE, true,
 AMDGPU_GEM_DOMAIN_GTT, 0,  NULL, NULL,
 &adev->wb.wb_obj);
@@ -657,7 +657,7 @@ int amdgpu_dummy_page_init(struct amdgpu_device *adev)
if (adev->dummy_page.page)
return 0;
adev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO);
-   if (adev->dummy_page.page == NULL)
+   if (!adev->dummy_page.page)
return -ENOMEM;
adev->dummy_page.addr = pci_map_page(adev->pdev, adev->dummy_page.page,
0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
@@ -679,7 +679,7 @@ int amdgpu_dummy_page_init(struct amdgpu_device *adev)
  */
 void amdgpu_dummy_page_fini(struct amdgpu_device *adev)
 {
-   if (adev->dummy_page.page == NULL)
+   if (!adev->dummy_page.page)
return;
pci_unmap_page(adev->pdev, adev->dummy_page.addr,
PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
@@ -1226,10 +1226,10 @@ static int amdgpu_early_init(struct amdgpu_device *adev)
adev->ip_block_status = kcalloc(adev->num_ip_blocks,
sizeof(*adev->ip_block_status),
GFP_KERNEL);
-   if (adev->ip_block_status == NULL)
+   if (!adev->ip_block_status)
return -ENOMEM;

-   if (adev->ip_blocks == NULL) {
+   if (!adev->ip_blocks) {
DRM_ERROR("No IP blocks found!\n");
return r;
}
@@ -1525,9 +1525,9 @@ int amdgpu_device_init(struct amdgpu_device *adev,
adev->rmmio_base = pci_resource_start(adev->pdev, 5);
adev->rmmio_size = pci_resource_len(adev->pdev, 5);
adev->rmmio = ioremap(adev->rmmio_base, adev->rmmio_size);
-   if (adev->rmmio == NULL) {
+   if (!adev->rmmio)
return -ENOMEM;
-   }
+
DRM_INFO("register mmio base: 0x%08X\n", (uint32_t)adev->rmmio_base);
DRM_INFO("register mmio size: %u\n", (unsigned)adev->rmmio_size);

@@ -1542,7 +1542,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
break;
}
}
-   if (adev->rio_mem == NULL)
+   if (!adev->rio_mem)
DRM_ERROR("Unable to find PCI I/O BAR\n");

/* early init functions */
@@ -1758,9 +1758,8 @@ int amdgpu_suspend_kms(struct drm_device *dev, bool 
suspend, bool fbcon)
struct drm_connector *connector;
int r;

-   if (dev == NULL || dev->dev_private == NULL) {
+   if (!dev || !dev->dev_private)
return -ENODEV;
-   }

adev = dev->dev_p

[PATCH] drm/udl: Fix for the X server screen update

2016-09-18 Thread Noralf Trønnes

Den 18.09.2016 15:48, skrev poma:
> Fix for DisplayLink GPU USB2.0 device X server screen update
>
> Within X server on top of DisplayLink GPU USB2.0 device,
> screen content is not refreshed i.e. updated,
> which is the most basic functionality of the screen.
>
> This partially (udl_handle_damage()) reverts commit:
>
> - e375882406d0cc24030746638592004755ed4ae0
>"drm/udl: Use drm_fb_helper deferred_io support"
>
> Thanks Noralf for the tip.
>
> $ modinfo udl
> filename:   /lib/modules/4.7.4-234.fc24.x86_64/updates/udl.ko
> license:GPL
> alias:  usb:v17E9p*d*dc*dsc*dp*icFFisc00ip00in*
> depends:
> intree: Y
> vermagic:   4.7.4-234.fc24.x86_64 SMP mod_unload
> parm:   fb_bpp:int
> parm:   fb_defio:int
>
> $ dmesg | grep udl
> [   41.888469] udl: module verification failed: signature and/or required key 
> missing - tainting kernel
> [   42.156988] udl 1-2:1.0: fb1: udldrmfb frame buffer device
> [   42.158940] [drm] Initialized udl on minor 1
> [   42.159676] usbcore: registered new interface driver udl
>
> $ grep udl /var/log/Xorg.0.log
> [71.194] (**) |   |-->Device "udl0"
>
> Tested-by: poma 
> ---
>   drivers/gpu/drm/udl/udl_drv.h |  2 ++
>   drivers/gpu/drm/udl/udl_fb.c  | 39 +--
>   2 files changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index 0b03d34..4a064ef 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -81,6 +81,8 @@ struct udl_framebuffer {
>   struct drm_framebuffer base;
>   struct udl_gem_object *obj;
>   bool active_16; /* active on the 16-bit channel */
> + int x1, y1, x2, y2; /* dirty rect */
> + spinlock_t dirty_lock;
>   };
>   
>   #define to_udl_fb(x) container_of(x, struct udl_framebuffer, base)
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index d5df555..b2b42d2 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -90,6 +90,9 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
> int y,
>   struct urb *urb;
>   int aligned_x;
>   int bpp = (fb->base.bits_per_pixel / 8);
> + int x2, y2;
> + bool store_for_later = false;
> + unsigned long flags;
>   
>   if (!fb->active_16)
>   return 0;
> @@ -115,6 +118,38 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
> int y,
>   (y + height > fb->base.height))
>   return -EINVAL;
>   
> + /* if we are in atomic just store the info
> +can't test inside spin lock */
> + if (in_atomic())
> + store_for_later = true;
> +
> + x2 = x + width - 1;
> + y2 = y + height - 1;
> +
> + spin_lock_irqsave(&fb->dirty_lock, flags);

You can drop the spinlock and store_for_later since it always runs in
process context.
Which means that there's no need to store x1/x2/y1/y2 in fb.

> +
> + if (fb->y1 < y)
> + y = fb->y1;
> + if (fb->y2 > y2)
> + y2 = fb->y2;
> + if (fb->x1 < x)
> + x = fb->x1;
> + if (fb->x2 > x2)
> + x2 = fb->x2;
> +
> + if (store_for_later) {
> + fb->x1 = x;
> + fb->x2 = x2;
> + fb->y1 = y;
> + fb->y2 = y2;
> + spin_unlock_irqrestore(&fb->dirty_lock, flags);
> + return 0;
> + }
> +
> + fb->x1 = fb->y1 = INT_MAX;
> + fb->x2 = fb->y2 = 0;
> +
> + spin_unlock_irqrestore(&fb->dirty_lock, flags);
>   start_cycles = get_cycles();
>   
>   urb = udl_get_urb(dev);
> @@ -122,14 +157,14 @@ int udl_handle_damage(struct udl_framebuffer *fb, int 
> x, int y,
>   return 0;
>   cmd = urb->transfer_buffer;
>   
> - for (i = y; i < height ; i++) {
> + for (i = y; i <= y2 ; i++) {
>   const int line_offset = fb->base.pitches[0] * i;
>   const int byte_offset = line_offset + (x * bpp);
>   const int dev_byte_offset = (fb->base.width * bpp * i) + (x * 
> bpp);
>   if (udl_render_hline(dev, bpp, &urb,
>(char *) fb->obj->vmapping,
>&cmd, byte_offset, dev_byte_offset,
> -  width * bpp,

There is obviously something wrong with the use of height/width here
as a substitute for y2 and the x1 formula.
If you add a printk here you can see how they differ.

Noralf.

> +  (x2 - x + 1) * bpp,
>&bytes_identical, &bytes_sent))
>   goto error;
>   }



[PATCH -next] drm/sun4i: backend: remove redundant dev_err call in sun4i_backend_bind()

2016-09-18 Thread Maxime Ripard
On Thu, Sep 15, 2016 at 03:25:58AM +, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 
> Signed-off-by: Wei Yongjun 

Queued, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/257caa2c/attachment.sig>


[PATCH 1/4] drm/sun4i: rgb: Declare RGB encoder and connector as MIPI DPI

2016-09-18 Thread Maxime Ripard
Hi,

On Thu, Sep 15, 2016 at 11:13:59PM +0800, Chen-Yu Tsai wrote:
> The 18 or 24 bit parallel RGB LCD panel interface found on Allwinner
> SoCs matches the description of MIPI DPI. Declare the RGB encoder and
> connector as MIPI DPI.

Unfortunately, even it that patch might be true (is there a public
spec for that standard?), this breaks the user-space, so there's no
way we change this.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/808e0518/attachment.sig>


[PATCH 3/4] drm/sun4i: dotclock: Allow divider = 127

2016-09-18 Thread Maxime Ripard
On Thu, Sep 15, 2016 at 11:14:01PM +0800, Chen-Yu Tsai wrote:
> The dot clock divider is 7 bits wide, and the divider range is 1 ~ 127,
> or 6 ~ 127 if phase offsets are used. The 0 register value also
> represents a divider of 1 or bypass.
> 
> Make the end condition of the for loop inclusive of 127 in the
> round_rate callback.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/34bb122f/attachment.sig>


[PATCH 2/4] drm/sun4i: dotclock: Fix clock rate read back calcation

2016-09-18 Thread Maxime Ripard
On Thu, Sep 15, 2016 at 11:14:00PM +0800, Chen-Yu Tsai wrote:
> When reading back the divider set in the register, we mask off the
> bits that aren't part of the divider. Unfortunately the mask used
> here was not converted from the field width.
> 
> Fix this by converting the field width to a proper bit mask.
> 
> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/2de11cb7/attachment.sig>


[PATCH 4/4] drm/sun4i: dotclock: Round to closest clock rate

2016-09-18 Thread Maxime Ripard
Hi,

On Thu, Sep 15, 2016 at 11:14:02PM +0800, Chen-Yu Tsai wrote:
> With display pixel clocks we want to have the closest possible clock
> rate, to minimize timing and refresh rate skews. Whether the actual
> clock rate is higher or lower than the requested rate is less important.
> 
> Also check candidates against the requested rate, rather than the
> ideal parent rate, the varying dividers also influence the difference
> between the requested rate and the rounded rate.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/gpu/drm/sun4i/sun4i_dotclock.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c 
> b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> index 3eb99784f371..d401156490f3 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> @@ -90,7 +90,8 @@ static long sun4i_dclk_round_rate(struct clk_hw *hw, 
> unsigned long rate,
>   goto out;
>   }
>  
> - if ((rounded < ideal) && (rounded > best_parent)) {
> + if (abs(rate - rounded / i) <
> + abs(rate - best_parent / best_div)) {

I'm not sure what you're trying to do here. Why is the divider involved?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/6b595f6e/attachment.sig>


[Bug 97852] Unreal Engine corrupted preview viewport

2016-09-18 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97852

Bug ID: 97852
   Summary: Unreal Engine corrupted preview viewport
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: mw at graph-ix.net
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 126603
  --> https://bugs.freedesktop.org/attachment.cgi?id=126603&action=edit
Viewport corruption

Unreal Engine 4.13.1 editor shows corrupted preview viewports when at least one
of the following post-processing effects is active in a viewport:
* Motion Blur
* Tonemapper

A screenshot of a viewport segment is attached.

When both effects are turned off, viewports appear to render correctly.


Graphics card: AMD TONGA chipset (Radeo R9 380)
Mesa version: 12.1~git160091700.073129c~x~padoka0 on Ubuntu 16.04 with
Padoka PPA
glxinfo:
  OpenGL core profile version string: 4.3 (Core Profile) Mesa 12.1.0-devel -
padoka PPA
  OpenGL version string: 3.0 Mesa 12.1.0-devel - padoka PPA
  OpenGL ES profile version string: OpenGL ES 3.1 Mesa 12.1.0-devel - padoka
PPA

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/12948292/attachment-0001.html>


[Bug 96449] Dying Light reports OpenGL version 3.0 with mesa-git

2016-09-18 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96449

--- Comment #7 from Adam Bolte  ---
MESA_GL_VERSION_OVERRIDE=3.3COMPAT does not work for me. Jan, did it work for
you? All I get is either a crash (after the loading screen), or a blank screen
with sound playing in the background. The warning about a lack of support for
3.3 compatibility profiles does not go away.

I've tried launching steam with "export MESA_GL_VERSION_OVERRIDE=3.3COMPAT" ran
in the xterm prior, and I've tried using MESA_GL_VERSION_OVERRIDE=3.3COMPAT as
an argument to the game from within the Steam launch options. No difference
either way.

Is this a different issue? Should I open a separate bug?

Also, can we get a link to where the decision was made to not support the
compatibility profile, or a quick explanation as to why this is the case?
Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/fe6d474a/attachment.html>


[Bug 97856] Computer restart playing 3D games (possibly overheating)

2016-09-18 Thread bugzilla-dae...@freedesktop.org
ard graphics card model, probably getting to the end
of its lifespan soon but I hope this report is valuable in some way, anyway.
Thank you for the good work on these open drivers. If I were able to use them
on my primary system I'd certainly do it, even if the fglrx legacy system is a
little bit smoother, since it would be a lot more convenient than maitaning a
separare gaming system in my machine. Thanks again for the contributions to the
FOSS community and for the time reading this report!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/09a36cac/attachment.html>


[Bug 97856] Computer restart playing 3D games (possibly overheating)

2016-09-18 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97856

--- Comment #1 from Alex Henry  ---
Forgot to mention, if relevant: the fglrx driver I'm using on my alternate
system is from the AMD website, not from the Debian repositories. The installer
file is named amd-driver-installer-catalyst-13.1-legacy-linux-x86.x86_64.run .

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/4df0aa69/attachment.html>


[PATCH] drm: bridge: analogix/dp: mark symbols static where possible

2016-09-18 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:1053:5: warning: no previous 
prototype for 'analogix_dp_get_modes' [-Wmissing-prototypes]
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:1097:1: warning: no previous 
prototype for 'analogix_dp_detect' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks both functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index efac8ab..e6f7290 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1050,7 +1050,7 @@ out:
return ret;
 }

-int analogix_dp_get_modes(struct drm_connector *connector)
+static int analogix_dp_get_modes(struct drm_connector *connector)
 {
struct analogix_dp_device *dp = to_dp(connector);
struct edid *edid = (struct edid *)dp->edid;
@@ -1093,7 +1093,7 @@ static const struct drm_connector_helper_funcs 
analogix_dp_connector_helper_func
.best_encoder = analogix_dp_best_encoder,
 };

-enum drm_connector_status
+static enum drm_connector_status
 analogix_dp_detect(struct drm_connector *connector, bool force)
 {
struct analogix_dp_device *dp = to_dp(connector);
-- 
2.7.4



[RFC PATCH v2 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite

2016-09-18 Thread Krzysztof Kozlowski
On Sun, Sep 18, 2016 at 09:03:48PM +0200, Krzysztof Kozlowski wrote:
> On Sun, Sep 18, 2016 at 10:27:38PM +0800, Randy Li wrote:
> > It is actually a lvds panel connected through a rga-lvds bridge.
> > The touchscreen is communicated with i2c bus but the driver is not
> > support now.
> > 
> > Signed-off-by: Randy Li 
> 
> Subject: ARM: dts: exynos
> 
> > ---
> >  arch/arm/boot/dts/exynos4412-itop-elite.dts | 54 
> > +++--
> >  1 file changed, 52 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts 
> > b/arch/arm/boot/dts/exynos4412-itop-elite.dts
> > index b08705e..9ef0505 100644
> > --- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
> > +++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
> > @@ -138,6 +138,36 @@
> > assigned-clocks = <&clock CLK_MOUT_CAM0>;
> > assigned-clock-parents = <&clock CLK_XUSBXTI>;
> > };
> > +
> > +   vcc_sys_lcd: sys-lcd {
> 
> No underscores, use hyphens.

Ah wait, it's a label, so underscore seems ok. My mistake.

> 
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "vcc_5v";
> > +   regulator-min-microvolt = <500>;
> > +   regulator-max-microvolt = <500>;
> > +   gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
> 
> Isn't this one of S5M8767 PMIC regulators? If so, then it should be
> defined there... On the other hand, the PMIC supports GPIO enable
> control only for buck9...
> 
> > +   };
> > +
> > +   panel: panel at 0 {
> > +   compatible = "chunghwa,claa070wp03xg";
> > +
> > +   power-supply = <&vcc_sys_lcd>;
> > +   enable-gpios = <&gpl0 2 GPIO_ACTIVE_HIGH>;
> > +   backlight = <&bl>;
> > +
> > +   port {
> > +   lcd_ep: endpoint {
> 
> lcd-ep

No need, the same.

Best regards,
Krzysztof

> 
> > +   remote-endpoint = <&rga_lvds>;
> > +   };
> > +   };
> > +   };
> > +
> > +   bl: backlight {
> > +   compatible = "pwm-backlight";
> > +   pwms = <&pwm 1 500 PWM_POLARITY_INVERTED>;
> > +   brightness-levels = <0 5 12 16 32 64 128 255>;
> > +   default-brightness-level = <5>;
> > +   power-supply = <&vcc_sys_lcd>;
> > +   };
> >  };
> >  
> >  &adc {
> > @@ -215,9 +245,9 @@
> >  
> >  &pwm {
> > status = "okay";
> > -   pinctrl-0 = <&pwm0_out>;
> > +   pinctrl-0 = <&pwm0_out &pwm1_out>;
> > pinctrl-names = "default";
> > -   samsung,pwm-outputs = <0>;
> > +   samsung,pwm-outputs = <0>, <1>;
> >  };
> >  
> >  &sdhci_2 {
> > @@ -238,3 +268,23 @@
> >  &serial_2 {
> > status = "okay";
> >  };
> > +
> > +&i2c_3 {
> > +   status = "okay";
> > +};
> > +
> > +&fimd {
> 
> Please put these nodes in alphabetical order. I asked about it for
> initial DTS and it applies still.
> 
> > +   pinctrl-0 = <&lcd_clk &lcd_data24>;
> > +   pinctrl-names = "default";
> > +   status = "okay";
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   port at 3 {
> > +   reg = <3>;
> > +   rga_lvds: endpoint {
> 
> rga-lvds
> 
> Best regards,
> Krzysztof
> 
> > +   remote-endpoint = <&lcd_ep>;
> > +   };
> > +   };
> > +   };
> > +};
> > -- 
> > 2.7.4
> > 


[Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-09-18 Thread Thorsten Leemhuis
Hi! James & Paulo: What's the current status of this? Was this issue
discussed elsewhere or even fixed in between? Just asking, because this
issue is on the list of regressions for 4.8. Ciao, Thorsten

On 01.09.2016 00:25, James Bottomley wrote:
> On Wed, 2016-08-31 at 21:51 +, Zanoni, Paulo R wrote:
>> Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu:
>>> On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote:
 On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> We seem to have an xrandr regression with skylake now.  What's
> happening is that I can get output on to a projector, but the 
> system is losing video when I change the xrandr sessions (like 
> going from a --above b to a --same-as b).  The main screen goes
> blank, which is basically a reboot situation.  Unfortunately, I
> can't seem to get the logs out of systemd to see if there was a
> dump to dmesg (the system was definitely responding).
>
> I fell back to 4.6.2 which worked perfectly, so this is
> definitely 
> some sort of regression.  I'll be able to debug more fully when
> I 
> get back home from the Linux Security Summit.

 I'm home now.  Unfortunately, my monitor isn't as problematic as
 the
 projector, but by flipping between various modes and separating
 and
 overlaying the panels with --above and --same-as (xrandr), I can
 eventually get it to the point where the main LCD panel goes
 black 
 and can only be restarted by specifying a different mode.

 This seems to be associated with these lines in the X

 [ 14714.389] (EE) intel(0): failed to set mode: Invalid argument
 [22]

 But the curious thing is that even if this fails with the error 
 message once, it may succeed a second time, so it looks to be a 
 transient error translation problem from the kernel driver.

 I've attached the full log below.

 This is only with a VGA output.  I currently don't have a HDMI 
 dongle, but I'm in the process of acquiring one.
>>>
>>> After more playing around, I'm getting thousands of these in the
>>> kernel
>>> log (possibly millions: the log wraps very fast):
>>>
>>> [23504.873606] [drm:intel_dp_start_link_train [i915]] *ERROR*
>>> failed
>>> to train DP, aborting
>>>
>>> And then finally it gives up with 
>>>
>>> [25023.770951] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
>>> *ERROR* CPU pipe B FIFO underrun
>>> [25561.926075] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
>>> *ERROR* CPU pipe A FIFO underrun
>>>
>>> And the crtc for the VGA output becomes non-responsive to any
>>> configuration command.  This requires a reboot and sometimes a UEFI
>>> variable reset before it comes back.
>>
>> Please see this discussion:
>> https://patchwork.freedesktop.org/patch/103237/
>>
>> Do you have this patch on your tree? Does the problem go away if you
>> revert it?
> 
> Yes, I've got it, it went in in 4.8-rc3 according to git:
> 
> commit 58e311b09c319183254d9220c50a533e7157c9ab
> Author: Matt Roper 
> Date:   Thu Aug 4 14:08:00 2016 -0700
> 
> drm/i915/gen9: Give one extra block per line for SKL plane WM
> calculations
> 
> Reverting it causes the secondary display not to sync pretty much at
> all.  However, in the flickers I can see, it does work OK and doesn't
> now crash switching from --same-as to --above and back
> 
> I also still get the logs filling up with the link training errors.
> 
> On balance, although the behaviour is different, it's not an
> improvement because if I can't sync with the projector, I can't really
> use this as a fix.
> 
> James


[PATCH] dma-buf/sw_sync: mark sync_timeline_create() static

2016-09-18 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for 
'sync_timeline_create' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/dma-buf/sw_sync.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 62e8e6d..6f16c85 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -84,7 +84,7 @@ static inline struct sync_pt *fence_to_sync_pt(struct fence 
*fence)
  * Creates a new sync_timeline. Returns the sync_timeline object or NULL in
  * case of error.
  */
-struct sync_timeline *sync_timeline_create(const char *name)
+static struct sync_timeline *sync_timeline_create(const char *name)
 {
struct sync_timeline *obj;

-- 
2.7.4



[PATCH] drm/nouveau/core: add missing header dependencies

2016-09-18 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous 
prototype for 'nvkm_firmware_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous 
prototype for 'nvkm_firmware_put' [-Wmissing-prototypes]

In fact, both functions are declared in
drivers/gpu/drm/nouveau/include/nvkm/core/firmware.h,
so this patch adds missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
index 34ecd4a..058ff46 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
@@ -20,6 +20,7 @@
  * DEALINGS IN THE SOFTWARE.
  */
 #include 
+#include 

 /**
  * nvkm_firmware_get - load firmware from the official nvidia/chip/ directory
-- 
2.7.4



[PATCH] drm/msm: add missing header dependencies

2016-09-18 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/msm/msm_debugfs.c:141:5: warning: no previous prototype for 
'msm_debugfs_init' [-Wmissing-prototypes]
drivers/gpu/drm/msm/msm_debugfs.c:158:6: warning: no previous prototype for 
'msm_debugfs_cleanup' [-Wmissing-prototypes]

In fact, both functions are declared in drivers/gpu/drm/msm/msm_debugfs.h,
so this patch adds missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/msm/msm_debugfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/msm_debugfs.c 
b/drivers/gpu/drm/msm/msm_debugfs.c
index 663f2b6..3c85373 100644
--- a/drivers/gpu/drm/msm/msm_debugfs.c
+++ b/drivers/gpu/drm/msm/msm_debugfs.c
@@ -18,6 +18,7 @@
 #ifdef CONFIG_DEBUG_FS
 #include "msm_drv.h"
 #include "msm_gpu.h"
+#include "msm_debugfs.h"

 static int msm_gpu_show(struct drm_device *dev, struct seq_file *m)
 {
-- 
2.7.4



[PATCH] drm/amdgpu: add missing header dependencies

2016-09-18 Thread Baoyou Xie
We get 6 warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c:629:6: warning: no previous prototype for 
'dce_v8_0_disable_dce' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c:730:6: warning: no previous prototype 
for 'dce_v10_0_disable_dce' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c:699:6: warning: no previous prototype 
for 'dce_v11_0_disable_dce' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:40:5: warning: no previous prototype 
for 'amdgpu_gfx_scratch_get' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:62:6: warning: no previous prototype 
for 'amdgpu_gfx_scratch_free' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:84:6: warning: no previous prototype 
for 'amdgpu_gfx_parse_disable_cu' [-Wmissing-prototypes]

In fact, these functions are declared in
drivers/gpu/drm/amd/amdgpu/dce_v8_0.h
drivers/gpu/drm/amd/amdgpu/dce_v10_0.h
drivers/gpu/drm/amd/amdgpu/dce_v11_0.h
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h,
so this patch adds missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 1 +
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   | 1 +
 4 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index a074edd..01a42b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -24,6 +24,7 @@
  */
 #include 
 #include "amdgpu.h"
+#include "amdgpu_gfx.h"

 /*
  * GPU scratch registers helpers function.
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index bc5bb4e..fb943ee 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -35,6 +35,7 @@
 #include "dce/dce_10_0_d.h"
 #include "dce/dce_10_0_sh_mask.h"
 #include "dce/dce_10_0_enum.h"
+#include "dce_v10_0.h"
 #include "oss/oss_3_0_d.h"
 #include "oss/oss_3_0_sh_mask.h"
 #include "gmc/gmc_8_1_d.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index b93eba0..1555d6d 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -35,6 +35,7 @@
 #include "dce/dce_11_0_d.h"
 #include "dce/dce_11_0_sh_mask.h"
 #include "dce/dce_11_0_enum.h"
+#include "dce_v11_0.h"
 #include "oss/oss_3_0_d.h"
 #include "oss/oss_3_0_sh_mask.h"
 #include "gmc/gmc_8_1_d.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index abd5213..ef7add9 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -34,6 +34,7 @@

 #include "dce/dce_8_0_d.h"
 #include "dce/dce_8_0_sh_mask.h"
+#include "dce_v8_0.h"

 #include "gca/gfx_7_2_enum.h"

-- 
2.7.4



[PATCH] drm/amdgpu: amend amdgpu_gfx_parse_disable_cu() declaration

2016-09-18 Thread Baoyou Xie
In amdgpu_gfx.h, the declaration of amdgpu_gfx_parse_disable_cu()
is incorrect.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 4 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 5 -
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index 01a42b6..8575039 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -82,7 +82,9 @@ void amdgpu_gfx_scratch_free(struct amdgpu_device *adev, 
uint32_t reg)
  * The bitmask of CUs to be disabled in the shader array determined by se and
  * sh is stored in mask[se * max_sh + sh].
  */
-void amdgpu_gfx_parse_disable_cu(unsigned *mask, unsigned max_se, unsigned 
max_sh)
+void amdgpu_gfx_parse_disable_cu(unsigned int *mask,
+   unsigned int max_se,
+   unsigned int max_sh)
 {
unsigned se, sh, cu;
const char *p;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
index 51321e1..0b9ad4f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
@@ -27,6 +27,9 @@
 int amdgpu_gfx_scratch_get(struct amdgpu_device *adev, uint32_t *reg);
 void amdgpu_gfx_scratch_free(struct amdgpu_device *adev, uint32_t reg);

-unsigned amdgpu_gfx_parse_disable_cu(unsigned *mask, unsigned max_se, unsigned 
max_sh);
+void
+amdgpu_gfx_parse_disable_cu(unsigned int *mask,
+  unsigned int max_se,
+  unsigned int max_sh);

 #endif
-- 
2.7.4



[PATCH] drm/bochs: mark bochs_connector_get_modes() static

2016-09-18 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/bochs/bochs_kms.c:181:5: warning: no previous prototype for 
'bochs_connector_get_modes' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 207a2cb..0b4e5d1 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -178,7 +178,7 @@ static void bochs_encoder_init(struct drm_device *dev)
 }


-int bochs_connector_get_modes(struct drm_connector *connector)
+static int bochs_connector_get_modes(struct drm_connector *connector)
 {
int count;

-- 
2.7.4



[PATCH] drm/exynos: mark exynos_dp_crtc_clock_enable() static

2016-09-18 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/exynos/exynos_dp.c:46:5: warning: no previous prototype for 
'exynos_dp_crtc_clock_enable' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/exynos/exynos_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
b/drivers/gpu/drm/exynos/exynos_dp.c
index 4f08505..528229f 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -43,7 +43,7 @@ struct exynos_dp_device {
struct analogix_dp_plat_data plat_data;
 };

-int exynos_dp_crtc_clock_enable(struct analogix_dp_plat_data *plat_data,
+static int exynos_dp_crtc_clock_enable(struct analogix_dp_plat_data *plat_data,
bool enable)
 {
struct exynos_dp_device *dp = to_dp(plat_data);
-- 
2.7.4



[PATCH] drm/mediatek: mark symbols static where possible

2016-09-18 Thread Baoyou Xie
We get 4 warnings when building kernel with W=1:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1089:6: warning: no previous prototype for 
'mtk_hdmi_audio_enable' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1095:6: warning: no previous prototype for 
'mtk_hdmi_audio_disable' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1101:5: warning: no previous prototype for 
'mtk_hdmi_audio_set_param' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1627:5: warning: no previous prototype for 
'mtk_hdmi_audio_digital_mute' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks both functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 334562d..be4e19c 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1086,19 +1086,19 @@ static int mtk_hdmi_output_init(struct mtk_hdmi *hdmi)
return 0;
 }

-void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
+static void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
 {
mtk_hdmi_aud_enable_packet(hdmi, true);
hdmi->audio_enable = true;
 }

-void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
+static void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
 {
mtk_hdmi_aud_enable_packet(hdmi, false);
hdmi->audio_enable = false;
 }

-int mtk_hdmi_audio_set_param(struct mtk_hdmi *hdmi,
+static int mtk_hdmi_audio_set_param(struct mtk_hdmi *hdmi,
 struct hdmi_audio_param *param)
 {
if (!hdmi->audio_enable) {
@@ -1624,7 +1624,8 @@ static void mtk_hdmi_audio_shutdown(struct device *dev, 
void *data)
mtk_hdmi_audio_disable(hdmi);
 }

-int mtk_hdmi_audio_digital_mute(struct device *dev, void *data, bool enable)
+static int
+mtk_hdmi_audio_digital_mute(struct device *dev, void *data, bool enable)
 {
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);

-- 
2.7.4



[PATCH] drm/amdgpu: mark symbols static where possible

2016-09-18 Thread Baoyou Xie
We get 7 warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1990:5: warning: no previous 
prototype for 'amdgpu_pre_soft_reset' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1548:5: warning: no previous 
prototype for 'amdgpu_connector_virtual_dpms' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1560:5: warning: no previous 
prototype for 'amdgpu_connector_virtual_set_property' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:330:5: warning: no previous prototype 
for 'amdgpu_cs_list_validate' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/dce_virtual.c:98:6: warning: no previous prototype 
for 'dce_virtual_stop_mc_access' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/dce_virtual.c:130:6: warning: no previous prototype 
for 'dce_virtual_resume_mc_access' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/dce_virtual.c:136:6: warning: no previous prototype 
for 'dce_virtual_set_vga_render_state' [-Wmissing-prototypes]

In fact, all of the functions are only used in the file
in which they are declared and don't need a declaration,
but can be made static.

So this patch marks both functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 6 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/dce_virtual.c   | 6 +++---
 4 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 319a5e1..decbba5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1545,7 +1545,8 @@ static int amdgpu_connector_virtual_mode_valid(struct 
drm_connector *connector,
return MODE_OK;
 }

-int amdgpu_connector_virtual_dpms(struct drm_connector *connector, int mode)
+static int
+amdgpu_connector_virtual_dpms(struct drm_connector *connector, int mode)
 {
return 0;
 }
@@ -1557,7 +1558,8 @@ amdgpu_connector_virtual_detect(struct drm_connector 
*connector, bool force)
return connector_status_connected;
 }

-int amdgpu_connector_virtual_set_property(struct drm_connector *connector,
+static int
+amdgpu_connector_virtual_set_property(struct drm_connector *connector,
  struct drm_property *property,
  uint64_t val)
 {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index d80e5d3..b408eea 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -327,7 +327,7 @@ retry:
return r;
 }

-int amdgpu_cs_list_validate(struct amdgpu_cs_parser *p,
+static int amdgpu_cs_list_validate(struct amdgpu_cs_parser *p,
struct list_head *validated)
 {
struct amdgpu_bo_list_entry *lobj;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c38dc47..09b809d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1987,7 +1987,7 @@ static bool amdgpu_check_soft_reset(struct amdgpu_device 
*adev)
return asic_hang;
 }

-int amdgpu_pre_soft_reset(struct amdgpu_device *adev)
+static int amdgpu_pre_soft_reset(struct amdgpu_device *adev)
 {
int i, r = 0;

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c 
b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
index 00663a7..2d02acd 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
@@ -95,7 +95,7 @@ static bool dce_virtual_is_display_hung(struct amdgpu_device 
*adev)
return false;
 }

-void dce_virtual_stop_mc_access(struct amdgpu_device *adev,
+static void dce_virtual_stop_mc_access(struct amdgpu_device *adev,
  struct amdgpu_mode_mc_save *save)
 {
switch (adev->asic_type) {
@@ -127,13 +127,13 @@ void dce_virtual_stop_mc_access(struct amdgpu_device 
*adev,

return;
 }
-void dce_virtual_resume_mc_access(struct amdgpu_device *adev,
+static void dce_virtual_resume_mc_access(struct amdgpu_device *adev,
struct amdgpu_mode_mc_save *save)
 {
return;
 }

-void dce_virtual_set_vga_render_state(struct amdgpu_device *adev,
+static void dce_virtual_set_vga_render_state(struct amdgpu_device *adev,
bool render)
 {
return;
-- 
2.7.4



[PATCH] drm/amdgpu: remove unused functions

2016-09-18 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:146:5: warning: no previous 
prototype for 'pool_to_domain' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/cz_smc.c:104:5: warning: no previous prototype for 
'cz_send_msg_to_smc_with_parameter_async' [-Wmissing-prototypes]

In fact, both functions are called by no one and not exported,
so this patch removes them.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 8 
 drivers/gpu/drm/amd/amdgpu/cz_smc.c| 7 ---
 2 files changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index d080d08..dba8a5b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -143,14 +143,6 @@ int amdgpu_amdkfd_resume(struct amdgpu_device *rdev)
return r;
 }

-u32 pool_to_domain(enum kgd_memory_pool p)
-{
-   switch (p) {
-   case KGD_POOL_FRAMEBUFFER: return AMDGPU_GEM_DOMAIN_VRAM;
-   default: return AMDGPU_GEM_DOMAIN_GTT;
-   }
-}
-
 int alloc_gtt_mem(struct kgd_dev *kgd, size_t size,
void **mem_obj, uint64_t *gpu_addr,
void **cpu_ptr)
diff --git a/drivers/gpu/drm/amd/amdgpu/cz_smc.c 
b/drivers/gpu/drm/amd/amdgpu/cz_smc.c
index 69ac373c4..db67e0c 100644
--- a/drivers/gpu/drm/amd/amdgpu/cz_smc.c
+++ b/drivers/gpu/drm/amd/amdgpu/cz_smc.c
@@ -101,13 +101,6 @@ int cz_send_msg_to_smc(struct amdgpu_device *adev, u16 msg)
return 0;
 }

-int cz_send_msg_to_smc_with_parameter_async(struct amdgpu_device *adev,
-   u16 msg, u32 parameter)
-{
-   WREG32(mmSMU_MP1_SRBM2P_ARG_0, parameter);
-   return cz_send_msg_to_smc_async(adev, msg);
-}
-
 int cz_send_msg_to_smc_with_parameter(struct amdgpu_device *adev,
u16 msg, u32 parameter)
 {
-- 
2.7.4



[PATCH] drm/msm/adreno: move function declarations to header file

2016-09-18 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/msm/adreno/a3xx_gpu.c:535:17: warning: no previous prototype 
for 'a3xx_gpu_init' [-Wmissing-prototypes]
drivers/gpu/drm/msm/adreno/a4xx_gpu.c:624:17: warning: no previous prototype 
for 'a4xx_gpu_init' [-Wmissing-prototypes]

In fact, both functions are declared in
drivers/gpu/drm/msm/adreno/adreno_device.c, but should be declared in
a header file. So this patch moves both function declarations to
drivers/gpu/drm/msm/adreno/adreno_gpu.h.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 3 ---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h| 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 5127b75..7250ffc 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -25,9 +25,6 @@ bool hang_debug = false;
 MODULE_PARM_DESC(hang_debug, "Dump registers when hang is detected (can be 
slow!)");
 module_param_named(hang_debug, hang_debug, bool, 0600);

-struct msm_gpu *a3xx_gpu_init(struct drm_device *dev);
-struct msm_gpu *a4xx_gpu_init(struct drm_device *dev);
-
 static const struct adreno_info gpulist[] = {
{
.rev   = ADRENO_REV(3, 0, 5, ANY_ID),
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index a54f6e0..07d99bd 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -311,4 +311,7 @@ static inline void adreno_gpu_write(struct adreno_gpu *gpu,
gpu_write(&gpu->base, reg - 1, data);
 }

+struct msm_gpu *a3xx_gpu_init(struct drm_device *dev);
+struct msm_gpu *a4xx_gpu_init(struct drm_device *dev);
+
 #endif /* __ADRENO_GPU_H__ */
-- 
2.7.4



[PATCH] drm/amdgpu: clean function declaration in amdgpu_pm.c up

2016-09-18 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:37:6: warning: no previous prototype for 
'amdgpu_pm_acpi_event_handler' [-Wmissing-prototypes]

In fact, this function is declared in
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c, but should be
declared in a header file, thus can be recognized in other file.

So this patch moves the declaration into
drivers/gpu/drm/amd/amdgpu/amdgpu.h.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 3208608..8e3d9b2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -2466,6 +2466,7 @@ struct amdgpu_afmt_acr {
 };

 struct amdgpu_afmt_acr amdgpu_afmt_acr(uint32_t clock);
+extern void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev);

 /* amdgpu_acpi.c */
 #if defined(CONFIG_ACPI)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 5cd7b73..eaaba0d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -32,7 +32,6 @@
 #include "amd_acpi.h"
 #include "atom.h"

-extern void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev);
 /* Call the ATIF method
  */
 /**
-- 
2.7.4



[RFC PATCH v2 0/2] adding panel claa070wp03xg support for exynos

2016-09-18 Thread Randy Li
I am trying to add LCD panel with LVDS interface for exynos 4412 topeet
itop. That board using a bridge chip to convert the parallel RGB signal
to LVDS signal. I could make a fb0 node appear in system now. But I can't
make it work yet. redirecting the urandom to fb0 won't make anything
change in panel.

The timing for this panel is calcuated from Hyundai T7, but it looks
different to the vendor's kernel. But those timings settings is disabled, so
I decided not to use it.

I attach them as references:
/* From Hyundai T7 */
static struct s3cfb_lcd hs101h = {
.width = 1280,
.height = 800,
.bpp = 24,
.freq = 60,

.timing = {
.h_fp = 49,
.h_bp = 17,
.h_sw = 33,
.v_fp = 4,
.v_fpe = 1,
.v_bp = 15,
.v_bpe = 1,
.v_sw = 6,
},

.polarity = {
.rise_vclk = 0,
.inv_hsync = 1,
.inv_vsync = 1,
.inv_vden = 0,
},
};
/* From vendor */
static struct s3cfb_lcd dummy_mipi_lcd = {  
 
.width = 800,   
  
.height = 1280, 
.bpp = 24,  
   
.freq = 60, 

.timing = { 
 
.h_fp = 16, 
   
.h_bp = 140,

.h_sw = 14, 

.v_fp = 8,  
 
//.v_fpe = 2,   
  
.v_bp = 4,  
 
//.v_bpe = 1,   
  
.v_sw = 4,  

.cmd_allow_len = 4, 
  
},  
  

.polarity = {   
  
.rise_vclk = 0, 
 
.inv_hsync = 0, 
  
.inv_vsync = 0, 
  
.inv_vden = 0,  
  
},  
  
}


Randy Li (2):
  ARM: dts: samsung: add rga-lvds panel in itop elite
  drm/panel: Add support for Chunghwa CLAA070WP03XG panel

 .../display/panel/chunghwa,claa070wp03xg.txt   |  7 +++
 arch/arm/boot/dts/exynos4412-itop-elite.dts| 54 +-
 drivers/gpu/drm/panel/panel-simple.c   | 27 +++
 3 files changed, 86 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt

-- 
2.7.4



[RFC PATCH v2 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

2016-09-18 Thread Randy Li
The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
supported by the simple panel driver.

Signed-off-by: Randy Li 
---
 .../display/panel/chunghwa,claa070wp03xg.txt   |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 27 ++
 2 files changed, 34 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt 
b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
new file mode 100644
index 000..dd22685
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
@@ -0,0 +1,7 @@
+Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "chunghwa,claa070wp03xg"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f178998..3204e6b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -583,6 +583,30 @@ static const struct panel_desc avic_tm070ddh03 = {
},
 };

+static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
+   .clock = 66770,
+   .hdisplay = 800,
+   .hsync_start = 800 + 49,
+   .hsync_end = 800 + 49 + 33,
+   .htotal = 800 + 49 + 33 + 17,
+   .vdisplay = 1280,
+   .vsync_start = 1280 + 1,
+   .vsync_end = 1280 + 1 + 7,
+   .vtotal = 1280 + 1 + 7 + 15,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc chunghwa_claa070wp03xg = {
+   .modes = &chunghwa_claa070wp03xg_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 94,
+   .height = 150,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -1544,6 +1568,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
}, {
+   .compatible = "chunghwa,claa070wp03xg",
+   .data = &chunghwa_claa070wp03xg,
+   }, {
.compatible = "chunghwa,claa101wa01a",
.data = &chunghwa_claa101wa01a
}, {
-- 
2.7.4



[RFC PATCH v2 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite

2016-09-18 Thread Randy Li
It is actually a lvds panel connected through a rga-lvds bridge.
The touchscreen is communicated with i2c bus but the driver is not
support now.

Signed-off-by: Randy Li 
---
 arch/arm/boot/dts/exynos4412-itop-elite.dts | 54 +++--
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts 
b/arch/arm/boot/dts/exynos4412-itop-elite.dts
index b08705e..9ef0505 100644
--- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
+++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
@@ -138,6 +138,36 @@
assigned-clocks = <&clock CLK_MOUT_CAM0>;
assigned-clock-parents = <&clock CLK_XUSBXTI>;
};
+
+   vcc_sys_lcd: sys-lcd {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
+   };
+
+   panel: panel at 0 {
+   compatible = "chunghwa,claa070wp03xg";
+
+   power-supply = <&vcc_sys_lcd>;
+   enable-gpios = <&gpl0 2 GPIO_ACTIVE_HIGH>;
+   backlight = <&bl>;
+
+   port {
+   lcd_ep: endpoint {
+   remote-endpoint = <&rga_lvds>;
+   };
+   };
+   };
+
+   bl: backlight {
+   compatible = "pwm-backlight";
+   pwms = <&pwm 1 500 PWM_POLARITY_INVERTED>;
+   brightness-levels = <0 5 12 16 32 64 128 255>;
+   default-brightness-level = <5>;
+   power-supply = <&vcc_sys_lcd>;
+   };
 };

 &adc {
@@ -215,9 +245,9 @@

 &pwm {
status = "okay";
-   pinctrl-0 = <&pwm0_out>;
+   pinctrl-0 = <&pwm0_out &pwm1_out>;
pinctrl-names = "default";
-   samsung,pwm-outputs = <0>;
+   samsung,pwm-outputs = <0>, <1>;
 };

 &sdhci_2 {
@@ -238,3 +268,23 @@
 &serial_2 {
status = "okay";
 };
+
+&i2c_3 {
+   status = "okay";
+};
+
+&fimd {
+   pinctrl-0 = <&lcd_clk &lcd_data24>;
+   pinctrl-names = "default";
+   status = "okay";
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 3 {
+   reg = <3>;
+   rga_lvds: endpoint {
+   remote-endpoint = <&lcd_ep>;
+   };
+   };
+   };
+};
-- 
2.7.4



[PATCH] drm/amdgpu: add function declaration in amdgpu.h

2016-09-18 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c:502:10: warning: no previous prototype 
for 'init_cond_exec' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c:514:6: warning: no previous prototype 
for 'patch_cond_exec' [-Wmissing-prototypes]

In fact, both functions are not declared in any files.

So this patch declares them in drivers/gpu/drm/amd/amdgpu/amdgpu.h.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 8e3d9b2..7b71cbe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -396,6 +396,8 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct 
fence **fence);
 void amdgpu_fence_process(struct amdgpu_ring *ring);
 int amdgpu_fence_wait_empty(struct amdgpu_ring *ring);
 unsigned amdgpu_fence_count_emitted(struct amdgpu_ring *ring);
+unsigned int init_cond_exec(struct amdgpu_ring *ring);
+void patch_cond_exec(struct amdgpu_ring *ring, unsigned int offset);

 /*
  * BO.
-- 
2.7.4



[RFC PATCH v2 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite

2016-09-18 Thread Krzysztof Kozlowski
On Sun, Sep 18, 2016 at 10:27:38PM +0800, Randy Li wrote:
> It is actually a lvds panel connected through a rga-lvds bridge.
> The touchscreen is communicated with i2c bus but the driver is not
> support now.
> 
> Signed-off-by: Randy Li 

Subject: ARM: dts: exynos

> ---
>  arch/arm/boot/dts/exynos4412-itop-elite.dts | 54 
> +++--
>  1 file changed, 52 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts 
> b/arch/arm/boot/dts/exynos4412-itop-elite.dts
> index b08705e..9ef0505 100644
> --- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
> +++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
> @@ -138,6 +138,36 @@
>   assigned-clocks = <&clock CLK_MOUT_CAM0>;
>   assigned-clock-parents = <&clock CLK_XUSBXTI>;
>   };
> +
> + vcc_sys_lcd: sys-lcd {

No underscores, use hyphens.

> + compatible = "regulator-fixed";
> + regulator-name = "vcc_5v";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;

Isn't this one of S5M8767 PMIC regulators? If so, then it should be
defined there... On the other hand, the PMIC supports GPIO enable
control only for buck9...

> + };
> +
> + panel: panel at 0 {
> + compatible = "chunghwa,claa070wp03xg";
> +
> + power-supply = <&vcc_sys_lcd>;
> + enable-gpios = <&gpl0 2 GPIO_ACTIVE_HIGH>;
> + backlight = <&bl>;
> +
> + port {
> + lcd_ep: endpoint {

lcd-ep

> + remote-endpoint = <&rga_lvds>;
> + };
> + };
> + };
> +
> + bl: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm 1 500 PWM_POLARITY_INVERTED>;
> + brightness-levels = <0 5 12 16 32 64 128 255>;
> + default-brightness-level = <5>;
> + power-supply = <&vcc_sys_lcd>;
> + };
>  };
>  
>  &adc {
> @@ -215,9 +245,9 @@
>  
>  &pwm {
>   status = "okay";
> - pinctrl-0 = <&pwm0_out>;
> + pinctrl-0 = <&pwm0_out &pwm1_out>;
>   pinctrl-names = "default";
> - samsung,pwm-outputs = <0>;
> + samsung,pwm-outputs = <0>, <1>;
>  };
>  
>  &sdhci_2 {
> @@ -238,3 +268,23 @@
>  &serial_2 {
>   status = "okay";
>  };
> +
> +&i2c_3 {
> + status = "okay";
> +};
> +
> +&fimd {

Please put these nodes in alphabetical order. I asked about it for
initial DTS and it applies still.

> + pinctrl-0 = <&lcd_clk &lcd_data24>;
> + pinctrl-names = "default";
> + status = "okay";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port at 3 {
> + reg = <3>;
> + rga_lvds: endpoint {

rga-lvds

Best regards,
Krzysztof

> + remote-endpoint = <&lcd_ep>;
> + };
> + };
> + };
> +};
> -- 
> 2.7.4
>