Re: [PATCHv6 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

[Ong, Hean Loong]

Hi Laurent,

I removed the examples for the HDMI in the draft below. The connections
between the VIP and Display Port IP or any display connector are
determined by HW logic. There are currently no SW defined encoders or
connectors that is connected to the AVALON-ST other than the Intel VIP
Frame Buffer II. Therefore there are no examples for the Display Port
encoder and connector.

On Mon, 2017-08-21 at 08:09 +0300, Laurent Pinchart wrote:
> Hi Hean Loong,
> 
> On Monday, 21 August 2017 04:40:09 EEST Ong, Hean Loong wrote:
> > 
> > On Fri, 2017-08-18 at 16:11 +0300, Laurent Pinchart wrote:
> > > 
> > > On Friday 18 Aug 2017 08:34:44 Ong, Hean Loong wrote:
> > > > 
> > > > 
> > > > Hi Laurent,
> > > > Thanks for the comments, I drafted a copy of the DT bindings
> > > > based
> > > > on your recommendations and inputs. I inserted the changes
> > > > below the
> > > > previous comments. 
> > > [snip]
> > > 
> > > > 
> > > > 
> > > > Intel Video and Image Processing(VIP) Frame Buffer II bindings
> > > > 
> > > > Supported hardware: Intel FPGA SoC Arria10 and above with
> > > > display
> > > > portIP
> > > > 
> > > > The Video Frame Buffer II in Video Image Processing (VIP) suite
> > > > is
> > > > an IP core that interfaces between system memory and Avalon-ST
> > > > video
> > > > ports. The IP core can be configured to support the memory
> > > > reader (from
> > > > memory to Avalon-ST) and/or memory writer (from Avalon-ST to
> > > > memory)
> > > > interfaces.
> > > > 
> > > > Connections between the Frame Buffer II and other video IP
> > > > cores in
> > > > the system are modelled using the OF graph DT bindings. The
> > > > Frame
> > > > Buffer II node has up to two OF graph ports. When the memory
> > > > writer
> > > > interface is enabled, port 0 maps to the Avalon-ST Input (din)
> > > > port.
> > > > When the memory reader interface is enabled, port 1 maps to the
> > > > Avalon-
> > > > ST Output (dout) port.
> > > > 
> > > > More information the FPGA video IP component can be acquired
> > > > from
> > > > https://www.altera.com/content/dam/altera-www/global/en_US/pdfs
> > > > \
> > > > /literature/ug/ug_vip.pdf
> > > > 
> > > > New bindings:
> > > > =
> > > How are the bindings "new" ? You can omit that title.
> > Noted.
> > 
> > > 
> > > > 
> > > > 
> > > > Required properties:
> > > > 
> > > > - compatible: "altr,vip-frame-buffer-2.0"
> > > > - reg: Physical base address and length of the framebuffer
> > > > controller's registers.
> > > > - altr,max-width: The maximum width of the framebuffer in
> > > > pixels.
> > > > - altr,max-height: The maximum height of the framebuffer in
> > > > pixels.
> > > > - altr,mem-port-width = the bus width of the avalon master
> > > > port 
> > > > on the frame reader
> > > You need to mention the ports here as they are mandatory. I would
> > > move the second paragraph from the introduction to here. You
> > > should also
> > > refer to the file defining the OF graph DT bindings. You can find
> > > examples
> > > in other DT bindings.
> > Noted
> > 
> > > 
> > > > 
> > > > 
> > > > Example:
> > > > 
> > > >  +-+  +---+  ++  +-
> > > > --+
> > > >  |  D  |  | Frame |  | DP/HDMI TX |  |
> > > > DP/HDMI   |
> > > >  |  D  |->| Buffer II |->| Controller |->|
> > > > Connector |
> > > >  |  R  |  |   |  ||  | 
> > > >   |
> > > >  +-+  +---+  ++  +-
> > > > --+
> > > > 
> > > > framebuffer@10280 {
> > > > compatible = "altr,vip-frame-buffer-2.0";
> > > > reg = <0x0001 0x0280 0x0040>;
> > > > altr,max-width = <1280>;
> > > > altr,max-height = <720>;
> > > > altr,mem-port-width = <128>;
> > > > 
> > > > ports {
> > > > #address-cells = <1>;
> > > > #size-cells = <0>;
> > > > 
> > > > port@1 {
> > > > reg = <1>;
> > > > fb_output: endpoint {
> > > > remote-endpoint =
> > > > <_encoder_input>;
> > > > };
> > > > };
> > > > };
> > > > };
> > > > 
> > > > If there is a need to scale the Frame Buffer II IP cores in
> > > > the pipeline, each node would have its own node, connected
> > > > through ports and endpoints. 
> > > > 
> > > > hdmi-encoder@. {
> > > > compatible = "altr,hdmi-tx-16.0";
> > > This was just an example, please use the real compatible string
> > > of
> > > the HDMI controller (and please submit DT bindings for the HDMI
> > > controller
> > > :-)). Please also fill the reg property with values from a real
> > > example.
> > I was trying to get overall picture to be correct before I proceed
> > further. We currently do not have support for HDMI therefore I
> > would
> > omit this 

[Bug 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101691

--- Comment #33 from Ethan Hsieh  ---
Based on Michel's comment in #23, there are two separate issues here.
So, the test result in comment#20 should be

Test Result:
1. AC Mode: (Power Adapter)
Device 1 (5916):
$ DRI_PRIME=1 glxgear: no corruption issue
$ DRI_PRIME=1 glxgear -fullscreen: tearing
Device 2 (5917):
$ DRI_PRIME=1 glxgear: corruption (!!!)
$ DRI_PRIME=1 glxgear -fullscreen: tearing

2. DC Mode: (Battery)
Device 1 (5916):
$ DRI_PRIME=1 glxgear: no corruption issue
$ DRI_PRIME=1 glxgear -fullscreen: tearing
Device 2 (5917):
$ DRI_PRIME=1 glxgear: no corruption issue
$ DRI_PRIME=1 glxgear -fullscreen: tearing

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

[Bug 102300] Missing 1920x1080_59.94Hz mode (Second monitor shows black screen but has signal)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102300

--- Comment #7 from Michel Dänzer  ---
According to the log file, the ASUS monitor only lists the 60 Hz 1920x1080 mode
in its EDID. So it seems clear that's what the monitor wants to be fed, but for
some reason we don't seem to be generating it properly.

Any chance you can try if a kernel built from the amd-staging-4.12 or
amd-staging-drm-next branch of https://cgit.freedesktop.org/~agd5f/linux/ with
CONFIG_DRM_AMD_DC=y works better?

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

[Bug 101026] RX 550 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101026

--- Comment #6 from Alex Deucher  ---
(In reply to dwagner from comment #5)
> ... and also later...
> [   133.973] (--) AMDGPU(0): HDMI max TMDS frequency 30KHz
> ...
> [   152.286] (--) AMDGPU(0): HDMI max TMDS frequency 30KHz
> ... 
> etc., seemingly as often as the EDID is re-read/re-considered.
> 

The message is from the xserver, not the driver.  It's warning you because the
clock for the mode exceeds the max TMDS clock as stated by the EDID.

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

Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

[Dave Airlie]

> Yeah, maybe it's time to disconnect the "default display device" idea
> from the VGA arbiter.  I have no idea what (if any) dependencies X has
> on the legacy VGA resources.  I assume X works fine on power, where it
> sounds like those resources are rarely or never available.

The question on non-x86 archs, is what is the correct device to default to.

On x86 we use the legacy VGA resources as a pointer, as this is the device
the BIOS appeared on at boot so hopefully should be one you can see stuff on.

On non-x86 I've no idea how to decide if there are multiple devices, maybe the
firmware needs to tag something for the kernel if there are. Otherwise
you'd just
be picking something in probe order.

I think the idea of these patches is to separate default display
device from the arbiter.

X uses the arbiter on x86 if required (it's horrible, and it's rare we
have to nowadays),
but for finding the default device it justs uses the sysfs boot_vga flag.

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

Re: [PATCH v3] drm/bridge/sii8620: add remote control support

[Sean Young]

Hi,

Some review comments below.

On Wed, Aug 23, 2017 at 09:03:18AM +0200, Hans Verkuil wrote:
> Maciej,
> 
> I'm cross-posting this to linux-media and the rc maintainer Sean Young.
> 
> Note that various RC defines have been renamed in the upcoming 4.14. It might 
> be
> better to base your code on top of https://git.linuxtv.org/media_tree.git/
> which has those patches merged.
> 
> Regards,
> 
>   Hans
> 
> On 08/21/2017 11:33 AM, Maciej Purski wrote:
> > MHL specification defines Remote Control Protocol(RCP) to
> > send input events between MHL devices.
> > The driver now recognizes RCP messages and reacts to them
> > by reporting key events to input subsystem, allowing
> > a user to control a device using TV remote control.
> > 
> > Changes in v2:
> > - use RC subsystem (including CEC keymap)
> > - RC device initialized in attach drm_bridge callback and
> >   removed in detach callback. This is necessary, because RC_CORE,
> >   which is needed during rc_dev init, is loaded after sii8620.
> >   DRM bridge is binded later which solves the problem.
> > - add RC_CORE dependency
> > 
> > Changes in v3:
> > - fix error handling in init_rcp and in attach callback
> > 
> > Signed-off-by: Maciej Purski 
> > ---
> >  drivers/gpu/drm/bridge/Kconfig   |   2 +-
> >  drivers/gpu/drm/bridge/sil-sii8620.c | 101 
> > +--
> >  include/drm/bridge/mhl.h |   4 ++
> >  3 files changed, 101 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index adf9ae0..6ef901c 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -71,7 +71,7 @@ config DRM_PARADE_PS8622
> >  
> >  config DRM_SIL_SII8620
> > tristate "Silicon Image SII8620 HDMI/MHL bridge"
> > -   depends on OF
> > +   depends on OF && RC_CORE
> > select DRM_KMS_HELPER
> > help
> >   Silicon Image SII8620 HDMI/MHL bridge chip driver.
> > diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
> > b/drivers/gpu/drm/bridge/sil-sii8620.c
> > index 2d51a22..e072bca 100644
> > --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> > +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> > @@ -28,6 +28,8 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> > +
> >  #include "sil-sii8620.h"
> >  
> >  #define SII8620_BURST_BUF_LEN 288
> > @@ -58,6 +60,7 @@ enum sii8620_mt_state {
> >  struct sii8620 {
> > struct drm_bridge bridge;
> > struct device *dev;
> > +   struct rc_dev *rc_dev;
> > struct clk *clk_xtal;
> > struct gpio_desc *gpio_reset;
> > struct gpio_desc *gpio_int;
> > @@ -431,6 +434,16 @@ static void sii8620_mt_rap(struct sii8620 *ctx, u8 
> > code)
> > sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RAP, code);
> >  }
> >  
> > +static void sii8620_mt_rcpk(struct sii8620 *ctx, u8 code)
> > +{
> > +   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPK, code);
> > +}
> > +
> > +static void sii8620_mt_rcpe(struct sii8620 *ctx, u8 code)
> > +{
> > +   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPE, code);
> > +}
> > +
> >  static void sii8620_mt_read_devcap_send(struct sii8620 *ctx,
> > struct sii8620_mt_msg *msg)
> >  {
> > @@ -1753,6 +1766,25 @@ static void sii8620_send_features(struct sii8620 
> > *ctx)
> > sii8620_write_buf(ctx, REG_MDT_XMIT_WRITE_PORT, buf, ARRAY_SIZE(buf));
> >  }
> >  
> > +static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)
> > +{
> > +   bool pressed = !(scancode & MHL_RCP_KEY_RELEASED_MASK);
> > +
> > +   scancode &= MHL_RCP_KEY_ID_MASK;
> > +
> > +   if (!ctx->rc_dev) {
> > +   dev_dbg(ctx->dev, "RCP input device not initialized\n");
> > +   return false;
> > +   }
> > +
> > +   if (pressed)
> > +   rc_keydown(ctx->rc_dev, RC_TYPE_CEC, scancode, 0);
> > +   else
> > +   rc_keyup(ctx->rc_dev);
> > +
> > +   return true;
> > +}
> > +
> >  static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
> >  {
> > u8 ints[MHL_INT_SIZE];
> > @@ -1804,19 +1836,25 @@ static void sii8620_msc_mt_done(struct sii8620 *ctx)
> >  
> >  static void sii8620_msc_mr_msc_msg(struct sii8620 *ctx)
> >  {
> > -   struct sii8620_mt_msg *msg = sii8620_msc_msg_first(ctx);
> > +   struct sii8620_mt_msg *msg;
> > u8 buf[2];
> >  
> > -   if (!msg)
> > -   return;
> > -
> > sii8620_read_buf(ctx, REG_MSC_MR_MSC_MSG_RCVD_1ST_DATA, buf, 2);
> >  
> > switch (buf[0]) {
> > case MHL_MSC_MSG_RAPK:
> > +   msg = sii8620_msc_msg_first(ctx);
> > +   if (!msg)
> > +   return;
> > msg->ret = buf[1];
> > ctx->mt_state = MT_STATE_DONE;
> > break;
> > +   case MHL_MSC_MSG_RCP:
> > +   if (!sii8620_rcp_consume(ctx, buf[1]))
> > +   sii8620_mt_rcpe(ctx,
> > +   MHL_RCPE_STATUS_INEFFECTIVE_KEY_CODE);
> > +   sii8620_mt_rcpk(ctx, buf[1]);
> > +   break;
> > default:
> >  

Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

[Ard Biesheuvel]

On 22 August 2017 at 23:19, Bjorn Helgaas  wrote:
> On Mon, Aug 21, 2017 at 11:53:01AM +0100, Lorenzo Pieralisi wrote:
>> On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:
>> > A system without PCI legacy resources (e.g. ARM64) may find that no
>> > default/boot VGA device has been marked, because the VGA arbiter
>> > checks for legacy resource decoding before marking a card as default.
>>
>> I do not understand this paragraph, in particular:
>>
>> - "A system without PCI legacy resources (e.g. ARM64)". What does this
>>   mean ? I take this as "ARM64 does not support IO space"; if a PCI host
>>   bridge supports IO space, there is nothing from an architectural
>>   point of view that prevents an MMIO based IO space implementation to
>>   work on ARM64. It is PCI bridge specific, not arch specific.
>
> This reference to ARM64 is the same thing I stumbled over.  Maybe it
> could be written along the lines of:
>
>   The VGA arbiter selects a default VGA device that is enabled and
>   reachable via the legacy VGA resources (mem 0xa-0xb, io
>   0x3b0-0x3bb, io 0x3c0-0x3df, etc).
>
>   If there is no such device, e.g., because there's no enabled VGA
>   device, the host bridge doesn't support access to those legacy
>   resources, or a PCI-PCI bridge doesn't have VGA Enable set, a
>   platform may select an arbitrary device by calling
>   vga_set_default_device().
>
> Then I think this patch changes the previous behavior by allowing the
> arbiter to select a device that is enabled and has a driver but may
> not be reachable via the legacy VGA resources.
>
> I don't know what all the consequences of that would be, but it does
> muddy the VGA arbiter waters a bit.  AIUI, the main reason for the
> arbiter is to allow multiple legacy VGA devices by manipulating bridge
> VGA Enable bits so only one receives the legacy resources at a time.
>
> These devices that do not need the legacy resources don't need that
> special treatment because they don't care about the bridge VGA Enable
> bits and several can coexist in the system with no need for VGA
> arbitration.
>
> I guess the powerpc fixup_vga() already selects a device that doesn't
> need the VGA resources, so we already have that situation.
>

Perhaps it is unclear that the whole point of tinkering with the VGA
arbiter is that X may refuse to use a GFX card if it is not tagged as
the default VGA device by the arbiter. I have suggested before that
fixing X may be more appropriate in this case, given that ownership of
the legacy VGA resources may not correlate at all with being the
primary display device on non-x86 architectures.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tegra: trace: Fix path to include

[Dmitry Osipenko]

On 23.08.2017 20:13, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The TRACE_INCLUDE_FILE macro needs to specify the path relative to the
> define_trace.h header rather than relative to the file defining it.
> 
> Reported-by: Dmitry Osipenko 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/tegra/trace.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tegra/trace.h b/drivers/gpu/drm/tegra/trace.h
> index e9b7cdad5c4c..5a1ab4046e92 100644
> --- a/drivers/gpu/drm/tegra/trace.h
> +++ b/drivers/gpu/drm/tegra/trace.h
> @@ -63,6 +63,6 @@ DEFINE_EVENT(register_access, sor_readl,
>  
>  /* This part must be outside protection */
>  #undef TRACE_INCLUDE_PATH
> -#define TRACE_INCLUDE_PATH .
> +#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/tegra
>  #define TRACE_INCLUDE_FILE trace
>  #include 
> 

This variant works too!

Tested-by: Dmitry Osipenko 

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

[PATCH] drm/amdgpu: check memory allocation failure

[Christophe JAILLET]

Check memory allocation failure and return -ENOMEM in such a case.

'num_post_dep_syncobjs' still has to be set to 0 before the test in order
to have it initialized if 'amdgpu_cs_parser_fini()' is called to free
resources.

The calling graph would be, in such a case!
   failure in amdgpu_cs_process_syncobj_out_dep()
  ---> error code returned by amdgpu_cs_dependencies()
 --> amdgpu_cs_parser_fini() is called

Signed-off-by: Christophe JAILLET 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 15d4a28d73bb..baa90df90aea 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1079,6 +1079,9 @@ static int amdgpu_cs_process_syncobj_out_dep(struct 
amdgpu_cs_parser *p,
 GFP_KERNEL);
p->num_post_dep_syncobjs = 0;
 
+   if (!p->post_dep_syncobjs)
+   return -ENOMEM;
+
for (i = 0; i < num_deps; ++i) {
p->post_dep_syncobjs[i] = drm_syncobj_find(p->filp, 
deps[i].handle);
if (!p->post_dep_syncobjs[i])
-- 
2.11.0

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

[PATCH] drm: pl111: constify amba_id

[Arvind Yadav]

amba_id are not supposed to change at runtime. All functions
working with const amba_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index ac8771b..522875c 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -243,7 +243,7 @@ static int pl111_amba_remove(struct amba_device *amba_dev)
return 0;
 }
 
-static struct amba_id pl111_id_table[] = {
+static const struct amba_id pl111_id_table[] = {
{
.id = 0x0004,
.mask = 0x000f,
-- 
2.7.4

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

Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

[Bjorn Helgaas]

On Wed, Aug 23, 2017 at 02:48:42PM +0100, Ard Biesheuvel wrote:
> On 22 August 2017 at 23:19, Bjorn Helgaas  wrote:
> > On Mon, Aug 21, 2017 at 11:53:01AM +0100, Lorenzo Pieralisi wrote:
> >> On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:
> >> > A system without PCI legacy resources (e.g. ARM64) may find that no
> >> > default/boot VGA device has been marked, because the VGA arbiter
> >> > checks for legacy resource decoding before marking a card as default.
> >>
> >> I do not understand this paragraph, in particular:
> >>
> >> - "A system without PCI legacy resources (e.g. ARM64)". What does this
> >>   mean ? I take this as "ARM64 does not support IO space"; if a PCI host
> >>   bridge supports IO space, there is nothing from an architectural
> >>   point of view that prevents an MMIO based IO space implementation to
> >>   work on ARM64. It is PCI bridge specific, not arch specific.
> >
> > This reference to ARM64 is the same thing I stumbled over.  Maybe it
> > could be written along the lines of:
> >
> >   The VGA arbiter selects a default VGA device that is enabled and
> >   reachable via the legacy VGA resources (mem 0xa-0xb, io
> >   0x3b0-0x3bb, io 0x3c0-0x3df, etc).
> >
> >   If there is no such device, e.g., because there's no enabled VGA
> >   device, the host bridge doesn't support access to those legacy
> >   resources, or a PCI-PCI bridge doesn't have VGA Enable set, a
> >   platform may select an arbitrary device by calling
> >   vga_set_default_device().
> >
> > Then I think this patch changes the previous behavior by allowing the
> > arbiter to select a device that is enabled and has a driver but may
> > not be reachable via the legacy VGA resources.
> >
> > I don't know what all the consequences of that would be, but it does
> > muddy the VGA arbiter waters a bit.  AIUI, the main reason for the
> > arbiter is to allow multiple legacy VGA devices by manipulating bridge
> > VGA Enable bits so only one receives the legacy resources at a time.
> >
> > These devices that do not need the legacy resources don't need that
> > special treatment because they don't care about the bridge VGA Enable
> > bits and several can coexist in the system with no need for VGA
> > arbitration.
> >
> > I guess the powerpc fixup_vga() already selects a device that doesn't
> > need the VGA resources, so we already have that situation.
> >
> 
> Perhaps it is unclear that the whole point of tinkering with the VGA
> arbiter is that X may refuse to use a GFX card if it is not tagged as
> the default VGA device by the arbiter. I have suggested before that
> fixing X may be more appropriate in this case, given that ownership of
> the legacy VGA resources may not correlate at all with being the
> primary display device on non-x86 architectures.

Yeah, maybe it's time to disconnect the "default display device" idea
from the VGA arbiter.  I have no idea what (if any) dependencies X has
on the legacy VGA resources.  I assume X works fine on power, where it
sounds like those resources are rarely or never available.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 0/5] MAP_DIRECT and block-map-atomic files

[Dan Williams]

Changes since v5 [1]:
* Compile fixes from a much improved coccinelle semantic patch (thanks
  Julia!) that adds a 'flags' argument to all the ->mmap()
  implementations in the kernel. (0day-kbuild-robot)

* Make the deprecated MAP_DENYWRITE and MAP_EXECUTABLE flags return
  EOPNOTSUPP with the new mmap3() syscall. (Kirill)

* Minor changelog updates.

* Updated cover letter with a clarified summary and checklist of
  questions to answer before proceeding further.

---

MAP_DIRECT is a mechanism to ask the kernel to atomically manage the
file-offset to physical-address block relationship of a mapping relative
to any memory-mapped access. It is complimentary to the proposed
MAP_SYNC mechanism which makes the same guarantee relative to cpu
faults. MAP_DIRECT goes a step further and makes this guarantee for
agents that may not generate mmu faults, but at the cost of restricting
the kernel's ability to mutate the block-map at will.

MAP_SYNC is preferred for scenarios that want full filesystem feature
support while avoiding fsync/msync overhead, but also do not need to
contend with hypervisors or RDMA agents that do not give the kernel an
mmu fault. In other words, the need for MAP_DIRECT is driven by the
scarcity of SVM capable hardware (Shared Virtual Memory, where hardware
generates mmu faults), hypervisors like Xen that need to interrogate the
physical address layout of a file to maintain their own physical-address
mapping metadata outside the kernel, and peer-to-peer DMA use cases that
always bypass the mmu.

The MAP_DIRECT mechanism allows a filesystem to be used for capacity
provisioning and access control where these aforementioned applications
would otherwise be forced to roll a custom solution on top of a raw
device-file.

Questions:
1/ Is the definition of MAP_DIRECT constrained enough to allow us to
   make the restrictions it imposes on the kernel finer grained over time?

2/ Do the XFS changes look sane? They attempt to avoid adding any
   overhead to the non-MAP_DIRECT case at the expense of the new
   i_mapdcount atomic counter in the XFS inode.

3/ While the generic MAP_DIRECT description warns that the block-map may
   not be actually be immutable for the lifetime of the mapping it also
   does not preclude a filesystem from making that guarantee. In fact,
   Dave wants to be able to get a stable view of the physical mapping
   [2], and Xen has a need to do the same [3]. Do we want userspace to
   start making "XFS + MAP_DIRECT == Immutable" assumptions, or do we
   need a separate mechanism for that guarantee?

[1]: https://lkml.org/lkml/2017/8/16/114
[2]: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1467677.html
[3]: https://lists.xen.org/archives/html/xen-devel/2017-04/msg00419.html

---

Dan Williams (5):
  vfs: add flags parameter to ->mmap() in 'struct file_operations'
  fs, xfs: introduce S_IOMAP_SEALED
  mm: introduce mmap3 for safely defining new mmap flags
  fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges
  fs, fcntl: add F_MAP_DIRECT


 arch/arc/kernel/arc_hostlink.c |3 -
 arch/mips/kernel/vdso.c|2 
 arch/powerpc/kernel/proc_powerpc.c |3 -
 arch/powerpc/kvm/book3s_64_vio.c   |3 -
 arch/powerpc/platforms/cell/spufs/file.c   |   21 ++--
 arch/powerpc/platforms/powernv/opal-prd.c  |3 -
 arch/um/drivers/mmapper_kern.c |3 -
 arch/x86/entry/syscalls/syscall_32.tbl |1 
 arch/x86/entry/syscalls/syscall_64.tbl |1 
 drivers/android/binder.c   |3 -
 drivers/char/agp/frontend.c|3 -
 drivers/char/bsr.c |3 -
 drivers/char/hpet.c|6 +
 drivers/char/mbcs.c|3 -
 drivers/char/mbcs.h|3 -
 drivers/char/mem.c |   11 +-
 drivers/char/mspec.c   |9 +-
 drivers/char/uv_mmtimer.c  |6 +
 drivers/dax/device.c   |3 -
 drivers/dma-buf/dma-buf.c  |4 +
 drivers/firewire/core-cdev.c   |3 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|3 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|3 -
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |5 +
 drivers/gpu/drm/arc/arcpgu_drv.c   |5 +
 drivers/gpu/drm/ast/ast_drv.h  |3 -
 drivers/gpu/drm/ast/ast_ttm.c  |3 -
 drivers/gpu/drm/bochs/bochs.h  |3 -
 drivers/gpu/drm/bochs/bochs_mm.c   |3 -
 drivers/gpu/drm/cirrus/cirrus_drv.h|3 -
 drivers/gpu/drm/cirrus/cirrus_ttm.c|3 -
 drivers/gpu/drm/drm_gem.c 

[radeon-alex:amd-staging-drm-next 756/816] drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:78:25: fatal error: asm/fpu/api.h: No such file or directory

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   f1d227e3e7d367350633a49e99cdaf72d2ff5c34
commit: 72e114de66e47103e367d33f5dff3a281cffc799 [756/816] drm/amd/display: 
remove DCN1 guard as DCN1 is already open sourced.
config: parisc-allmodconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 72e114de66e47103e367d33f5dff3a281cffc799
# save the attached .config to linux build tree
make.cross ARCH=parisc 

All errors (new ones prefixed by >>):

   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/modules/inc/mod_freesync.h:57:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:48,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:52,
from drivers/gpu/drm/amd/amdgpu/vce_v3_0.c:30:
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:78:25: fatal error: 
>> asm/fpu/api.h: No such file or directory
#include 
^
   compilation terminated.

vim +78 drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h

e37527a2 Harry Wentland 2017-08-23  77  
af05f214 Alex Deucher   2017-06-15 @78  #include 
af05f214 Alex Deucher   2017-06-15  79  

:: The code at line 78 was first introduced by commit
:: af05f2141c60c05ad58616f4aa5cce9817c8ceeb drm/amdgpu/display: Enable DCN 
in DC

:: TO: Alex Deucher 
:: CC: Alex Deucher 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:amd-staging-drm-next 61/816] sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 'readl'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   f1d227e3e7d367350633a49e99cdaf72d2ff5c34
commit: 1f5f2691ef56d0d2eda46e03539efe2003633e8e [61/816] ASoC: AMD: enable 
ACP3x drivers build
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1f5f2691ef56d0d2eda46e03539efe2003633e8e
# save the attached .config to linux build tree
make.cross ARCH=sparc 

All errors (new ones prefixed by >>):

   In file included from sound/soc/amd/raven/acp3x-pcm-dma.c:26:0:
   sound/soc/amd/raven/acp3x.h: In function 'rv_readl':
>> sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 
>> 'readl' [-Werror=implicit-function-declaration]
 return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
   sound/soc/amd/raven/acp3x.h: In function 'rv_writel':
>> sound/soc/amd/raven/acp3x.h:33:2: error: implicit declaration of function 
>> 'writel' [-Werror=implicit-function-declaration]
 writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
 ^~
   sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
>> sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of 
>> function 'devm_ioremap' [-Werror=implicit-function-declaration]
 adata->acp3x_base = devm_ioremap(>dev, res->start,
 ^~~~
   sound/soc/amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
 adata->acp3x_base = devm_ioremap(>dev, res->start,
   ^
   cc1: some warnings being treated as errors

vim +/readl +28 sound/soc/amd/raven/acp3x.h

b835e6cf Maruthi Srinivas Bayyavarapu 2017-03-27  25  
b835e6cf Maruthi Srinivas Bayyavarapu 2017-03-27  26  static inline u32 
rv_readl(void __iomem *base_addr)
b835e6cf Maruthi Srinivas Bayyavarapu 2017-03-27  27  {
b835e6cf Maruthi Srinivas Bayyavarapu 2017-03-27 @28return readl(base_addr 
- ACP3x_PHY_BASE_ADDRESS);
b835e6cf Maruthi Srinivas Bayyavarapu 2017-03-27  29  }
b835e6cf Maruthi Srinivas Bayyavarapu 2017-03-27  30  
b835e6cf Maruthi Srinivas Bayyavarapu 2017-03-27  31  static inline void 
rv_writel(u32 val, void __iomem *base_addr)
b835e6cf Maruthi Srinivas Bayyavarapu 2017-03-27  32  {
b835e6cf Maruthi Srinivas Bayyavarapu 2017-03-27 @33writel(val, base_addr - 
ACP3x_PHY_BASE_ADDRESS);

:: The code at line 28 was first introduced by commit
:: b835e6cfc3fa2eafeaa7cf3ba43cdf01d4b1f904 ASoC: AMD: add ACP3.0 PCI driver

:: TO: Maruthi Srinivas Bayyavarapu 
:: CC: Alex Deucher 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm-intel:drm-intel-nightly 1258/1268] drivers/gpu/drm/tve200/tve200_display.c:339:9: error: passing argument 6 of 'drm_simple_display_pipe_init' from incompatible pointer type

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head:   3adc9e3cacefe82619fc56ec78a0ca3a67a4b00c
commit: 179c02fe90a4104d32e92a46b9ff4ecc32bf3647 [1258/1268] drm/tve200: Add 
new driver for TVE200
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 179c02fe90a4104d32e92a46b9ff4ecc32bf3647
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/tve200/tve200_display.c: In function 'tve200_display_init':
>> drivers/gpu/drm/tve200/tve200_display.c:339:9: error: passing argument 6 of 
>> 'drm_simple_display_pipe_init' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
>connector.connector);
^
   In file included from drivers/gpu/drm/tve200/tve200_drm.h:97:0,
from drivers/gpu/drm/tve200/tve200_display.c:26:
   include/drm/drm_simple_kms_helper.h:121:5: note: expected 'const uint64_t * 
{aka const long long unsigned int *}' but argument is of type 'struct 
drm_connector *'
int drm_simple_display_pipe_init(struct drm_device *dev,
^~~~
>> drivers/gpu/drm/tve200/tve200_display.c:336:8: error: too few arguments to 
>> function 'drm_simple_display_pipe_init'
 ret = drm_simple_display_pipe_init(drm, >pipe,
   ^~~~
   In file included from drivers/gpu/drm/tve200/tve200_drm.h:97:0,
from drivers/gpu/drm/tve200/tve200_display.c:26:
   include/drm/drm_simple_kms_helper.h:121:5: note: declared here
int drm_simple_display_pipe_init(struct drm_device *dev,
^~~~
   cc1: some warnings being treated as errors

vim +/drm_simple_display_pipe_init +339 drivers/gpu/drm/tve200/tve200_display.c

   311  
   312  int tve200_display_init(struct drm_device *drm)
   313  {
   314  struct tve200_drm_dev_private *priv = drm->dev_private;
   315  int ret;
   316  static const u32 formats[] = {
   317  DRM_FORMAT_XRGB,
   318  DRM_FORMAT_XBGR,
   319  DRM_FORMAT_RGB565,
   320  DRM_FORMAT_BGR565,
   321  DRM_FORMAT_XRGB1555,
   322  DRM_FORMAT_XBGR1555,
   323  /*
   324   * The controller actually supports any YCbCr ordering,
   325   * for packed YCbCr. This just lists the orderings that
   326   * DRM supports.
   327   */
   328  DRM_FORMAT_YUYV,
   329  DRM_FORMAT_YVYU,
   330  DRM_FORMAT_UYVY,
   331  DRM_FORMAT_VYUY,
   332  /* This uses three planes */
   333  DRM_FORMAT_YUV420,
   334  };
   335  
 > 336  ret = drm_simple_display_pipe_init(drm, >pipe,
   337 _display_funcs,
   338 formats, ARRAY_SIZE(formats),
 > 339 >connector.connector);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101026] RX 550 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101026

--- Comment #5 from dwagner  ---
Sure can do: This I find in Xorg.0.log:

[36.956] (--) AMDGPU(0): HDMI max TMDS frequency 30KHz
[36.956] (II) AMDGPU(0): Printing probed modes for output HDMI-A-0
[36.956] (II) AMDGPU(0): Modeline "3840x2160"x60.0  594.00  3840 4016 4104
4400  2160 2168 2178 2250 +hsync +vsync (135.0 kHz eP)
[36.956] (II) AMDGPU(0): Modeline "4096x2160"x60.0  594.00  4096 4184 4272
4400  2160 2168 2178 2250 +hsync +vsync (135.0 kHz e)
[36.956] (II) AMDGPU(0): Modeline "4096x2160"x50.0  594.00  4096 5064 5152
5280  2160 2168 2178 2250 +hsync +vsync (112.5 kHz e)
[36.956] (II) AMDGPU(0): Modeline "4096x2160"x59.9  593.41  4096 4184 4272
4400  2160 2168 2178 2250 +hsync +vsync (134.9 kHz e)
[36.956] (II) AMDGPU(0): Modeline "4096x2160"x30.0  297.00  4096 4184 4272
4400  2160 2168 2178 2250 +hsync +vsync (67.5 kHz e)
[36.956] (II) AMDGPU(0): Modeline "4096x2160"x25.0  297.00  4096 5064 5152
5280  2160 2168 2178 2250 +hsync +vsync (56.2 kHz e)
[36.956] (II) AMDGPU(0): Modeline "4096x2160"x24.0  297.00  4096 5116 5204
5500  2160 2168 2178 2250 +hsync +vsync (54.0 kHz e)
[36.956] (II) AMDGPU(0): Modeline "4096x2160"x30.0  296.70  4096 4184 4272
4400  2160 2168 2178 2250 +hsync +vsync (67.4 kHz e)
[36.956] (II) AMDGPU(0): Modeline "4096x2160"x24.0  296.70  4096 5116 5204
5500  2160 2168 2178 2250 +hsync +vsync (53.9 kHz e)
[36.956] (II) AMDGPU(0): Output HDMI-A-0 using initial mode 3840x2160 +0+0
... and also later...
[   133.973] (--) AMDGPU(0): HDMI max TMDS frequency 30KHz
...
[   152.286] (--) AMDGPU(0): HDMI max TMDS frequency 30KHz
... 
etc., seemingly as often as the EDID is re-read/re-considered.

>From the first parameter of the Modelines one can already see that modes with
594.00 MHz clock are found, and indeed, the "3840x2160" mode at 60Hz is used,
as both xrandr and the connected display report:

HDMI-A-0 connected 3840x2160+0+0 (normal left inverted right x axis y axis)
1600mm x 900mm
   3840x2160 60.00*+  50.0059.9430.0025.0024.0029.97   
23.98

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

[radeon-alex:drm-next-4.14-wip 38/44] drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:950:6: error: implicit declaration of function 'ttm_populate_and_map_pages'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.14-wip
head:   9f7373596843431b63965965f1059d39600db3a2
commit: d47a6c4783b8461b6c6d24b53ce35b7a3dfa92a1 [38/44] drm/amd/amdgpu: Use 
new TTM populate/map helper function
config: i386-randconfig-a1-08231053 (attached as .config)
compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
reproduce:
git checkout d47a6c4783b8461b6c6d24b53ce35b7a3dfa92a1
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: In function 
'amdgpu_ttm_tt_populate':
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:950:6: error: implicit declaration 
>> of function 'ttm_populate_and_map_pages' 
>> [-Werror=implicit-function-declaration]
 r = ttm_populate_and_map_pages(adev->dev, >ttm);
 ^
   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: In function 
'amdgpu_ttm_tt_unpopulate':
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:983:2: error: implicit declaration 
>> of function 'ttm_unmap_and_unpopulate_pages' 
>> [-Werror=implicit-function-declaration]
 ttm_unmap_and_unpopulate_pages(adev->dev, >ttm);
 ^
   cc1: some warnings being treated as errors

vim +/ttm_populate_and_map_pages +950 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

   949  
 > 950  r = ttm_populate_and_map_pages(adev->dev, >ttm);
   951  trace_mappings:
   952  if (likely(!r))
   953  amdgpu_trace_dma_map(ttm);
   954  return r;
   955  }
   956  
   957  static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
   958  {
   959  struct amdgpu_device *adev;
   960  struct amdgpu_ttm_tt *gtt = (void *)ttm;
   961  bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
   962  
   963  if (gtt && gtt->userptr) {
   964  kfree(ttm->sg);
   965  ttm->page_flags &= ~TTM_PAGE_FLAG_SG;
   966  return;
   967  }
   968  
   969  if (slave)
   970  return;
   971  
   972  adev = amdgpu_ttm_adev(ttm->bdev);
   973  
   974  amdgpu_trace_dma_unmap(ttm);
   975  
   976  #ifdef CONFIG_SWIOTLB
   977  if (swiotlb_nr_tbl()) {
   978  ttm_dma_unpopulate(>ttm, adev->dev);
   979  return;
   980  }
   981  #endif
   982  
 > 983  ttm_unmap_and_unpopulate_pages(adev->dev, >ttm);
   984  }
   985  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [radeon-alex:drm-next-4.14-wip 39/44] drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of function 'ttm_populate_and_map_pages'

[StDenis, Tom]

Odd.  I mean I had build tested it even though I don't have radeon cards to 
devel with (other than my tahiti I guess but I rarely use that).

Tom

From: Deucher, Alexander
Sent: Wednesday, August 23, 2017 17:12
To: StDenis, Tom; kbuild test robot
Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Koenig, Christian
Subject: RE: [radeon-alex:drm-next-4.14-wip 39/44] 
drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of 
function 'ttm_populate_and_map_pages'

> -Original Message-
> From: StDenis, Tom
> Sent: Wednesday, August 23, 2017 5:08 PM
> To: kbuild test robot
> Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Deucher, Alexander;
> Koenig, Christian
> Subject: Re: [radeon-alex:drm-next-4.14-wip 39/44]
> drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of
> function 'ttm_populate_and_map_pages'
>
> The only way this would be possible if if the commit
> d1c99475f269a85e0a1916c949526cb22b157271 didn't make it into the public
> staging tree.

It's there:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.14-wip=49ad04f2eae72fe928716efe557c73d1f346b9fd
Built fine here.

Alex

>
> Tom
>
>
> 
> From: kbuild test robot 
> Sent: Wednesday, August 23, 2017 16:52
> To: StDenis, Tom
> Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Deucher, Alexander;
> Koenig, Christian
> Subject: [radeon-alex:drm-next-4.14-wip 39/44]
> drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of
> function 'ttm_populate_and_map_pages'
>
> tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.14-wip
> head:   9f7373596843431b63965965f1059d39600db3a2
> commit: 217dcd53c963af28d04c357aed922f1faa20 [39/44] drm/radeon:
> use new TTM populate/dma map helper functions
> config: xtensa-allmodconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 4.9.0
> reproduce:
> wget https://raw.githubusercontent.com/01org/lkp-
> tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 217dcd53c963af28d04c357aed922f1faa20
> # save the attached .config to linux build tree
> make.cross ARCH=xtensa
>
> All errors (new ones prefixed by >>):
>
>drivers/gpu/drm/radeon/radeon_ttm.c: In function
> 'radeon_ttm_tt_populate':
> >> drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration
> of function 'ttm_populate_and_map_pages' [-Werror=implicit-function-
> declaration]
>  return ttm_populate_and_map_pages(rdev->dev, >ttm);
>  ^
>drivers/gpu/drm/radeon/radeon_ttm.c: In function
> 'radeon_ttm_tt_unpopulate':
> >> drivers/gpu/drm/radeon/radeon_ttm.c:796:2: error: implicit declaration
> of function 'ttm_unmap_and_unpopulate_pages' [-Werror=implicit-
> function-declaration]
>  ttm_unmap_and_unpopulate_pages(rdev->dev, >ttm);
>  ^
>cc1: some warnings being treated as errors
>
> vim +/ttm_populate_and_map_pages +763
> drivers/gpu/drm/radeon/radeon_ttm.c
>
>762
>  > 763  return ttm_populate_and_map_pages(rdev->dev, >ttm);
>764  }
>765
>766  static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
>767  {
>768  struct radeon_device *rdev;
>769  struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm);
>770  bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>771
>772  if (gtt && gtt->userptr) {
>773  kfree(ttm->sg);
>774  ttm->page_flags &= ~TTM_PAGE_FLAG_SG;
>775  return;
>776  }
>777
>778  if (slave)
>779  return;
>780
>781  rdev = radeon_get_rdev(ttm->bdev);
>782  #if IS_ENABLED(CONFIG_AGP)
>783  if (rdev->flags & RADEON_IS_AGP) {
>784  ttm_agp_tt_unpopulate(ttm);
>785  return;
>786  }
>787  #endif
>788
>789  #ifdef CONFIG_SWIOTLB
>790  if (swiotlb_nr_tbl()) {
>791  ttm_dma_unpopulate(>ttm, rdev->dev);
>792  return;
>793  }
>794  #endif
>795
>  > 796  ttm_unmap_and_unpopulate_pages(rdev->dev, >ttm);
>797  }
>798
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [radeon-alex:drm-next-4.14-wip 39/44] drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of function 'ttm_populate_and_map_pages'

[Deucher, Alexander]

> -Original Message-
> From: StDenis, Tom
> Sent: Wednesday, August 23, 2017 5:08 PM
> To: kbuild test robot
> Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Deucher, Alexander;
> Koenig, Christian
> Subject: Re: [radeon-alex:drm-next-4.14-wip 39/44]
> drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of
> function 'ttm_populate_and_map_pages'
> 
> The only way this would be possible if if the commit
> d1c99475f269a85e0a1916c949526cb22b157271 didn't make it into the public
> staging tree.

It's there:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.14-wip=49ad04f2eae72fe928716efe557c73d1f346b9fd
Built fine here.

Alex

> 
> Tom
> 
> 
> 
> From: kbuild test robot 
> Sent: Wednesday, August 23, 2017 16:52
> To: StDenis, Tom
> Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Deucher, Alexander;
> Koenig, Christian
> Subject: [radeon-alex:drm-next-4.14-wip 39/44]
> drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of
> function 'ttm_populate_and_map_pages'
> 
> tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.14-wip
> head:   9f7373596843431b63965965f1059d39600db3a2
> commit: 217dcd53c963af28d04c357aed922f1faa20 [39/44] drm/radeon:
> use new TTM populate/dma map helper functions
> config: xtensa-allmodconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 4.9.0
> reproduce:
> wget https://raw.githubusercontent.com/01org/lkp-
> tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 217dcd53c963af28d04c357aed922f1faa20
> # save the attached .config to linux build tree
> make.cross ARCH=xtensa
> 
> All errors (new ones prefixed by >>):
> 
>drivers/gpu/drm/radeon/radeon_ttm.c: In function
> 'radeon_ttm_tt_populate':
> >> drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration
> of function 'ttm_populate_and_map_pages' [-Werror=implicit-function-
> declaration]
>  return ttm_populate_and_map_pages(rdev->dev, >ttm);
>  ^
>drivers/gpu/drm/radeon/radeon_ttm.c: In function
> 'radeon_ttm_tt_unpopulate':
> >> drivers/gpu/drm/radeon/radeon_ttm.c:796:2: error: implicit declaration
> of function 'ttm_unmap_and_unpopulate_pages' [-Werror=implicit-
> function-declaration]
>  ttm_unmap_and_unpopulate_pages(rdev->dev, >ttm);
>  ^
>cc1: some warnings being treated as errors
> 
> vim +/ttm_populate_and_map_pages +763
> drivers/gpu/drm/radeon/radeon_ttm.c
> 
>762
>  > 763  return ttm_populate_and_map_pages(rdev->dev, >ttm);
>764  }
>765
>766  static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
>767  {
>768  struct radeon_device *rdev;
>769  struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm);
>770  bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>771
>772  if (gtt && gtt->userptr) {
>773  kfree(ttm->sg);
>774  ttm->page_flags &= ~TTM_PAGE_FLAG_SG;
>775  return;
>776  }
>777
>778  if (slave)
>779  return;
>780
>781  rdev = radeon_get_rdev(ttm->bdev);
>782  #if IS_ENABLED(CONFIG_AGP)
>783  if (rdev->flags & RADEON_IS_AGP) {
>784  ttm_agp_tt_unpopulate(ttm);
>785  return;
>786  }
>787  #endif
>788
>789  #ifdef CONFIG_SWIOTLB
>790  if (swiotlb_nr_tbl()) {
>791  ttm_dma_unpopulate(>ttm, rdev->dev);
>792  return;
>793  }
>794  #endif
>795
>  > 796  ttm_unmap_and_unpopulate_pages(rdev->dev, >ttm);
>797  }
>798
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [radeon-alex:drm-next-4.14-wip 39/44] drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of function 'ttm_populate_and_map_pages'

[StDenis, Tom]

The only way this would be possible if if the commit 
d1c99475f269a85e0a1916c949526cb22b157271 didn't make it into the public staging 
tree.

Tom



From: kbuild test robot 
Sent: Wednesday, August 23, 2017 16:52
To: StDenis, Tom
Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; 
Koenig, Christian
Subject: [radeon-alex:drm-next-4.14-wip 39/44] 
drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of 
function 'ttm_populate_and_map_pages'

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.14-wip
head:   9f7373596843431b63965965f1059d39600db3a2
commit: 217dcd53c963af28d04c357aed922f1faa20 [39/44] drm/radeon: use new 
TTM populate/dma map helper functions
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 217dcd53c963af28d04c357aed922f1faa20
# save the attached .config to linux build tree
make.cross ARCH=xtensa

All errors (new ones prefixed by >>):

   drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
>> drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of 
>> function 'ttm_populate_and_map_pages' [-Werror=implicit-function-declaration]
 return ttm_populate_and_map_pages(rdev->dev, >ttm);
 ^
   drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_unpopulate':
>> drivers/gpu/drm/radeon/radeon_ttm.c:796:2: error: implicit declaration of 
>> function 'ttm_unmap_and_unpopulate_pages' 
>> [-Werror=implicit-function-declaration]
 ttm_unmap_and_unpopulate_pages(rdev->dev, >ttm);
 ^
   cc1: some warnings being treated as errors

vim +/ttm_populate_and_map_pages +763 drivers/gpu/drm/radeon/radeon_ttm.c

   762
 > 763  return ttm_populate_and_map_pages(rdev->dev, >ttm);
   764  }
   765
   766  static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
   767  {
   768  struct radeon_device *rdev;
   769  struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm);
   770  bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
   771
   772  if (gtt && gtt->userptr) {
   773  kfree(ttm->sg);
   774  ttm->page_flags &= ~TTM_PAGE_FLAG_SG;
   775  return;
   776  }
   777
   778  if (slave)
   779  return;
   780
   781  rdev = radeon_get_rdev(ttm->bdev);
   782  #if IS_ENABLED(CONFIG_AGP)
   783  if (rdev->flags & RADEON_IS_AGP) {
   784  ttm_agp_tt_unpopulate(ttm);
   785  return;
   786  }
   787  #endif
   788
   789  #ifdef CONFIG_SWIOTLB
   790  if (swiotlb_nr_tbl()) {
   791  ttm_dma_unpopulate(>ttm, rdev->dev);
   792  return;
   793  }
   794  #endif
   795
 > 796  ttm_unmap_and_unpopulate_pages(rdev->dev, >ttm);
   797  }
   798

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:drm-next-4.14-wip 39/44] drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of function 'ttm_populate_and_map_pages'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.14-wip
head:   9f7373596843431b63965965f1059d39600db3a2
commit: 217dcd53c963af28d04c357aed922f1faa20 [39/44] drm/radeon: use new 
TTM populate/dma map helper functions
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 217dcd53c963af28d04c357aed922f1faa20
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
>> drivers/gpu/drm/radeon/radeon_ttm.c:763:2: error: implicit declaration of 
>> function 'ttm_populate_and_map_pages' [-Werror=implicit-function-declaration]
 return ttm_populate_and_map_pages(rdev->dev, >ttm);
 ^
   drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_unpopulate':
>> drivers/gpu/drm/radeon/radeon_ttm.c:796:2: error: implicit declaration of 
>> function 'ttm_unmap_and_unpopulate_pages' 
>> [-Werror=implicit-function-declaration]
 ttm_unmap_and_unpopulate_pages(rdev->dev, >ttm);
 ^
   cc1: some warnings being treated as errors

vim +/ttm_populate_and_map_pages +763 drivers/gpu/drm/radeon/radeon_ttm.c

   762  
 > 763  return ttm_populate_and_map_pages(rdev->dev, >ttm);
   764  }
   765  
   766  static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
   767  {
   768  struct radeon_device *rdev;
   769  struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm);
   770  bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
   771  
   772  if (gtt && gtt->userptr) {
   773  kfree(ttm->sg);
   774  ttm->page_flags &= ~TTM_PAGE_FLAG_SG;
   775  return;
   776  }
   777  
   778  if (slave)
   779  return;
   780  
   781  rdev = radeon_get_rdev(ttm->bdev);
   782  #if IS_ENABLED(CONFIG_AGP)
   783  if (rdev->flags & RADEON_IS_AGP) {
   784  ttm_agp_tt_unpopulate(ttm);
   785  return;
   786  }
   787  #endif
   788  
   789  #ifdef CONFIG_SWIOTLB
   790  if (swiotlb_nr_tbl()) {
   791  ttm_dma_unpopulate(>ttm, rdev->dev);
   792  return;
   793  }
   794  #endif
   795  
 > 796  ttm_unmap_and_unpopulate_pages(rdev->dev, >ttm);
   797  }
   798  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102380] intel_gpu_top: Test requirement not met in function drm_open_driver_master, file drmtest.c:391:

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102380

Bug ID: 102380
   Summary: intel_gpu_top: Test requirement not met in function
drm_open_driver_master, file drmtest.c:391:
   Product: DRI
   Version: unspecified
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mqajj...@10mail.org

After upgraded intel_gpu_tools to 19.1 I can't run intel_gpu_top from terminal
inside dektop session:

Test requirement not met in function drm_open_driver_master, file
drmtest.c:391:
Test requirement: drmSetMaster(fd) == 0
Can't become DRM master, please check if no other DRM client is running.
Last errno: 22, Invalid argument
SKIP (-1.000s)

It works when switching to different Virtual Console. It worked with 1.16
version I used before.

See also:
https://bbs.archlinux.org/viewtopic.php?pid=1732114

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

[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102358

--- Comment #6 from har...@gmx.de ---
BTW:

... setting environment variable LIBGL_DRI3_DISABLE (to switch back to DRI2)
fixes the freeze too ...

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

[radeon-alex:amd-staging-4.12 472/1215] sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of function 'pci_enable_msi'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.12
head:   aa4ac19d28d34607b90d055439ce421be9e6fc11
commit: ea915b0b0414e1086ba7cc1aaf78f9cd4f746631 [472/1215] ASoC: AMD: enable 
ACP3x drivers build
config: blackfin-allyesconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ea915b0b0414e1086ba7cc1aaf78f9cd4f746631
# save the attached .config to linux build tree
make.cross ARCH=blackfin 

All errors (new ones prefixed by >>):

   sound/soc/amd/raven/pci-acp3x.c: In function 'snd_acp3x_probe':
>> sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of 
>> function 'pci_enable_msi' [-Werror=implicit-function-declaration]
 ret = pci_enable_msi(pci);
   ^~
>> sound/soc/amd/raven/pci-acp3x.c:122:2: error: implicit declaration of 
>> function 'pci_disable_msi' [-Werror=implicit-function-declaration]
 pci_disable_msi(pci);
 ^~~
   sound/soc/amd/raven/pci-acp3x.c: At top level:
   sound/soc/amd/raven/pci-acp3x.c:159:1: warning: data definition has no type 
or storage class
module_pci_driver(acp3x_driver);
^
>> sound/soc/amd/raven/pci-acp3x.c:159:1: error: type defaults to 'int' in 
>> declaration of 'module_pci_driver' [-Werror=implicit-int]
   sound/soc/amd/raven/pci-acp3x.c:159:1: warning: parameter names (without 
types) in function declaration
   sound/soc/amd/raven/pci-acp3x.c:152:26: warning: 'acp3x_driver' defined but 
not used [-Wunused-variable]
static struct pci_driver acp3x_driver  = {
 ^~~~
   cc1: some warnings being treated as errors

vim +/pci_enable_msi +58 sound/soc/amd/raven/pci-acp3x.c

eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   29  
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   30  static int 
snd_acp3x_probe(struct pci_dev *pci,
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   31  
const struct pci_device_id *pci_id)
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   32  {
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   33   int ret;
c24c2859 Maruthi Srinivas Bayyavarapu 2017-03-29   34   u32 addr, val;
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   35   struct acp3x_dev_data 
*adata;
c24c2859 Maruthi Srinivas Bayyavarapu 2017-03-29   36   struct 
platform_device_info pdevinfo;
c24c2859 Maruthi Srinivas Bayyavarapu 2017-03-29   37   unsigned int irqflags;
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   38  
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   39   if 
(pci_enable_device(pci)) {
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   40   
dev_err(>dev, "pci_enable_device failed\n");
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   41   return -ENODEV;
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   42   }
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   43  
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   44   ret = 
pci_request_regions(pci, "AMD ACP3x audio");
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   45   if (ret < 0) {
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   46   
dev_err(>dev, "pci_request_regions failed\n");
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   47   goto 
disable_pci;
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   48   }
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   49  
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   50   adata = 
devm_kzalloc(>dev, sizeof(struct acp3x_dev_data),
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   51   
GFP_KERNEL);
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   52   if (adata == NULL) {
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   53   ret = -ENOMEM;
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   54   goto 
release_regions;
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   55   }
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   56  
c24c2859 Maruthi Srinivas Bayyavarapu 2017-03-29   57   /* check for msi 
interrupt support */
c24c2859 Maruthi Srinivas Bayyavarapu 2017-03-29  @58   ret = 
pci_enable_msi(pci);
c24c2859 Maruthi Srinivas Bayyavarapu 2017-03-29   59   if (ret)
c24c2859 Maruthi Srinivas Bayyavarapu 2017-03-29   60   /* msi is not 
enabled */
c24c2859 Maruthi Srinivas Bayyavarapu 2017-03-29   61   irqflags = 
IRQF_SHARED;
c24c2859 Maruthi Srinivas Bayyavarapu 2017-03-29   62   else
c24c2859 Maruthi Srinivas Bayyavarapu 2017-03-29   63   /* msi is 
enabled */
c24c2859 Maruthi Srinivas Bayyavarapu 2017-03-29   64   irqflags = 0;
c24c2859 Maruthi Srinivas Bayyavarapu 2017-03-29   65  
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   66   addr = 
pci_resource_start(pci, 0);
eb91fe3e Maruthi Srinivas Bayyavarapu 2017-03-27   67   adata->acp3x_base = 
ioremap(addr, 

Re: [PATCH][drm-next] drm/amdgpu: remove duplicate return statement

[Felix Kuehling]

I must have added that accidentally when cherry-picking an internal
patch for upstreaming. Thanks for catching it.

Reviewed-by: Felix Kuehling 

Regards,
  Felix


On 2017-08-23 09:17 AM, Colin King wrote:
> From: Colin Ian King 
>
> Remove a redundant identical return statement, it has no use.
>
> Detected by CoverityScan, CID#1454586 ("Structurally dead code")
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
> index fb6e5dbd5a03..309f2419c6d8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
> @@ -155,7 +155,6 @@ static const struct kfd2kgd_calls kfd2kgd = {
>  struct kfd2kgd_calls *amdgpu_amdkfd_gfx_8_0_get_functions(void)
>  {
>   return (struct kfd2kgd_calls *)
> - return (struct kfd2kgd_calls *)
>  }
>  
>  static inline struct amdgpu_device *get_amdgpu_device(struct kgd_dev *kgd)

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

[Bug 101026] RX 550 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101026

--- Comment #4 from Harry Wentland  ---
Do you mind posting the logs? We might just need to cleanup the messages (i.e.
not print them).

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

[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102358

--- Comment #5 from Thomas Hellström  ---
This looks odd. 

That commit actually only adds a wait for all swaps to be scheduled at
glFinish(), so it shouldn't really be causing any grief unless the server
somehow forgets to send the right events or the dri3 wait_for_sbc is broken...

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

[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102358

--- Comment #4 from har...@gmx.de ---
Created attachment 133719
  --> https://bugs.freedesktop.org/attachment.cgi?id=133719=edit
gdb all tread backtrace

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

Re: [PATCH 06/14] drm/cirrus: Use 32bpp by default

[Matthew Garrett]

On Wed, Aug 23, 2017 at 09:10:09PM +0530, Varad Gautam wrote:
> Hi Matthew,
> 
> On Sat, Aug 19, 2017 at 2:02 PM, Matthew Garrett  wrote:
> > On Fri, Aug 18, 2017 at 09:19:11PM +0530, Varad Gautam wrote:
> >> From: Stéphane Marchesin 
> >>
> >> initially reviewed for ChromiumOS at:
> >> https://chromium-review.googlesource.com/339093
> >> Signed-off-by: Stéphane Marchesin 
> >
> > 1280x1024x24 fits in 4MB, 1280x1024x32 doesn't. That seems like it's
> > going to be a visible change in behaviour.
> >
> 
> Right, 800x600 is the highest we can go for >24bpp, so we now switch
> to that instead of 1280x1024. fb creation fails in
> cirrus_check_framebuffer if the w*h*bpp doesn't fit, and plane updates
> get rejected when atomic is enabled later on.

So users who want 1280x1024 now have to change their configuration. Is 
that the intent? It seems odd to change user-visible behaviour for 
everyone just to fix ChromeOS in a VM.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/tegra: trace: Fix path to include

[Thierry Reding]

From: Thierry Reding 

The TRACE_INCLUDE_FILE macro needs to specify the path relative to the
define_trace.h header rather than relative to the file defining it.

Reported-by: Dmitry Osipenko 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/trace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/trace.h b/drivers/gpu/drm/tegra/trace.h
index e9b7cdad5c4c..5a1ab4046e92 100644
--- a/drivers/gpu/drm/tegra/trace.h
+++ b/drivers/gpu/drm/tegra/trace.h
@@ -63,6 +63,6 @@ DEFINE_EVENT(register_access, sor_readl,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/tegra
 #define TRACE_INCLUDE_FILE trace
 #include 
-- 
2.13.3

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

[Bug 102319] Crashes and freezes when switching VTs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102319

--- Comment #5 from Marcin Mielniczuk  ---
As for suspending the Nvidia GPU - I ran 

DRI_PRIME=1 xed

inside my DM manager to make sure that the Nvidia GPU remains powered on. The
problem persists even then.

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

[Bug 102319] Crashes and freezes when switching VTs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102319

--- Comment #4 from Marcin Mielniczuk  ---
Created attachment 133718
  --> https://bugs.freedesktop.org/attachment.cgi?id=133718=edit
journal with nouveau.modeset=0

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

[Bug 102319] Crashes and freezes when switching VTs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102319

--- Comment #3 from Marcin Mielniczuk  ---
Created attachment 133717
  --> https://bugs.freedesktop.org/attachment.cgi?id=133717=edit
dmesg with nouveau.modeset=0

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

[Bug 102319] Crashes and freezes when switching VTs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102319

--- Comment #2 from Marcin Mielniczuk  ---
With nouveau.modeset=0 I get a black screen in the tty the DM is running in.
Attaching the journal and dmesg.

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

Re: [PATCH 06/14] drm/cirrus: Use 32bpp by default

[Varad Gautam]

Hi Matthew,

On Sat, Aug 19, 2017 at 2:02 PM, Matthew Garrett  wrote:
> On Fri, Aug 18, 2017 at 09:19:11PM +0530, Varad Gautam wrote:
>> From: Stéphane Marchesin 
>>
>> initially reviewed for ChromiumOS at:
>> https://chromium-review.googlesource.com/339093
>> Signed-off-by: Stéphane Marchesin 
>
> 1280x1024x24 fits in 4MB, 1280x1024x32 doesn't. That seems like it's
> going to be a visible change in behaviour.
>

Right, 800x600 is the highest we can go for >24bpp, so we now switch
to that instead of 1280x1024. fb creation fails in
cirrus_check_framebuffer if the w*h*bpp doesn't fit, and plane updates
get rejected when atomic is enabled later on.

Regards,
Varad

> --
> Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102358

Michel Dänzer  changed:

   What|Removed |Added

 CC||thellst...@vmware.com

--- Comment #3 from Michel Dänzer  ---
Thomas, any ideas?

(In reply to haro41 from comment #2)
> Yes, i did it via 'git bisect'.

Thanks. Any chance you can get a backtrace[0] of the hanging process?

[0] Ideally of all threads, something like "thread apply all bt full" in gdb.

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

[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102358

--- Comment #2 from har...@gmx.de ---
Yes, i did it via 'git bisect'.

Here is the first related commit:

d5ba75f8881f0869dc16f71f7395514c0a35b6e2 is the first bad commit
commit d5ba75f8881f0869dc16f71f7395514c0a35b6e2
Author: Thomas Hellstrom 
Date:   Tue Jun 20 19:24:34 2017 +0200

st/dri2 Plumb the flush_swapbuffer functionality through to dri3

Implement the state tracker manager drawable interface flush_swapbuffer
method by plumbing it through to dri3 if available.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Marek Olšák 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 

:04 04 8df730d2ac95b42435c96043da0eb6fba5f6861c
4179b3bb9a075169627eb00de5780bbbe8abea02 M  src


I hope it makes sense and can help you.

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

[Bug 102372] [dc] [kabini] Errors during startup - X doesn't start

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102372

Mike Lothian  changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #2 from Mike Lothian  ---
The driver is built in, I noticed Dave spotted the same (or similar issue) 

Harry Wentland said he sent a patch fixing the issue but I don't think it's
included in your tree yet and I'm not sure which is the right patch

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

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=194761

--- Comment #83 from Rich (f...@bitservices.org.uk) ---
For anyone reading this, this is still broken in Kernel 4.12.8 (currently
latest).

Really concerned that this bug doesn't get fixed before 4.9 is no longer the
latest LONGTERM. Still wondering about my previous comment re: just reverting
the offending commit due to the severity of the regression before a proper fix
can be implemented.

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

[Bug 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101691

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #133711|text/x-log  |text/plain
  mime type||

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

[Bug 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101691

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #133710|text/x-log  |text/plain
  mime type||

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

Re: [PATCH] drm/sun4i: use of_graph_get_remote_endpoint()

[Maxime Ripard]

Hi,

On Thu, Aug 10, 2017 at 04:36:43AM +, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> Now, we can use of_graph_get_remote_endpoint(). Let's use it.
> 
> Signed-off-by: Kuninori Morimoto 

Queued for 4.15, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553

--- Comment #16 from Vedran Miletić  ---
And an equivalent one for r600, sorry for double comment:
http://paul.rutgers.edu/~jv356/piglit/radeon-latest-5/problems.html

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

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553

--- Comment #15 from Vedran Miletić  ---
Jan Vesely is maintaining a table of test results:
http://paul.rutgers.edu/~jv356/piglit/gcn-latest-3/problems.html

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

[Bug 102372] [dc] [kabini] Errors during startup - X doesn't start

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102372

--- Comment #1 from Alex Deucher  ---
Please attach your full dmesg output from when the driver loaded and your xorg
log.

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

[pull] drm/msm: msm-next for 4.14

[Rob Clark]

Hi Dave,

Updates for 4.14..  I have some further patches from Jordan to add
multiple priority levels and pre-emption, but those will probably be
for 4.15 to give me time for the mesa parts.

The following changes since commit 8f93e043d048b671c32c6f0a5102fefa800c4618:

  drm/msm: gpu: don't abuse dma_alloc for non-DMA allocations
(2017-08-01 19:39:00 -0400)

are available in the git repository at:

  git://people.freedesktop.org/~robclark/linux tags/drm-msm-next-2017-08-22

for you to fetch changes up to d1f08d82176246c6d8a2f1dc26be3638ed4a6083:

  drm/msm/mdp5: mark runtime_pm functions as __maybe_unused
(2017-08-22 13:20:40 -0400)


Archit Taneja (7):
  drm/msm/mdp5: Use runtime PM get/put API instead of toggling clocks
  drm/msm/hdmi: Set up runtime PM for HDMI
  drm/msm/dsi: Set up runtime PM for DSI
  drm/msm/dsi: Implement RPM suspend/resume callbacks
  drm/msm/mdp5: Don't use mode_set helper funcs for encoders and CRTCs
  drm/msm/mdp5: Write to SMP registers even if allocations don't change
  drm/msm/mdp5: Set up runtime PM for MDSS

Arnd Bergmann (2):
  drm/msm: remove unused variable
  drm/msm/mdp5: mark runtime_pm functions as __maybe_unused

Jordan Crouse (4):
  drm/msm: Remove uneeded platform dev members
  drm/msm: Add A5XX hardware fault detection
  drm/msm: Attach the GPU MMU when it is created
  drm/msm: Add a helper function for in-kernel buffer allocations

Rob Clark (7):
  drm/msm: remove unused define
  drm/msm/mdp5: add tracking for clk enable-count
  drm/msm: add modeset module param
  drm/msm: don't track fbdev's gem object separately
  drm/msm: add helper to allocate stolen fb
  drm/msm: make msm_framebuffer_init() static
  drm/msm/mdp5: make helper function static

 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  2 -
 drivers/gpu/drm/msm/adreno/a3xx_gpu.h   |  1 -
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |  2 -
 drivers/gpu/drm/msm/adreno/a4xx_gpu.h   |  1 -
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 51 --
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h   |  1 -
 drivers/gpu/drm/msm/adreno/a5xx_power.c | 14 ++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 53 +++---
 drivers/gpu/drm/msm/dsi/dsi.c   |  5 ++
 drivers/gpu/drm/msm/dsi/dsi.h   |  2 +
 drivers/gpu/drm/msm/dsi/dsi_host.c  | 94 ++---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c   |  2 +-
 drivers/gpu/drm/msm/hdmi/hdmi.c |  2 +
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c  |  4 ++
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c   | 63 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c |  7 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 27 ---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 12 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 27 ---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 54 +++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  7 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c| 63 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 59 +---
 drivers/gpu/drm/msm/msm_drv.c   | 36 ++
 drivers/gpu/drm/msm/msm_drv.h   | 12 ++--
 drivers/gpu/drm/msm/msm_fb.c| 45 +++-
 drivers/gpu/drm/msm/msm_fbdev.c | 57 ++-
 drivers/gpu/drm/msm/msm_gem.c   | 46 
 drivers/gpu/drm/msm/msm_gpu.c   | 85 ++
 drivers/gpu/drm/msm/msm_kms.h   |  2 +
 drivers/gpu/drm/msm/msm_ringbuffer.c| 12 ++--
 31 files changed, 574 insertions(+), 274 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102300] Missing 1920x1080_59.94Hz mode (Second monitor shows black screen but has signal)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102300

--- Comment #6 from f...@mt2015.com ---
Section "Device"
Identifier "Radeon R9 285"
Driver "amdgpu"
Option "AccelMethod" "glamor"
Option "DRI" "3"
Option "TearFree" "on"
Option "ColorTiling" "on"
Option "ColorTiling2D" "on"
EndSection

This was all in 20-amdgpu.conf originally, doesn't matter if I add
monitors+screen or not. I have to run these commands after every restart, or no
signal:

xrandr --newmode "mymode" 148.35  1920 2008 2052 2200  1080 1084 1089 1125
+hsync +vsync
xrandr --addmode DVI-I-1 mymode
xrandr --output DVI-I-1 --right-of DVI-D-0 --mode mymode

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

[Bug 102300] Missing 1920x1080_59.94Hz mode (Second monitor shows black screen but has signal)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102300

--- Comment #5 from f...@mt2015.com ---
(In reply to Michel Dänzer from comment #4)
> Please attach the Xorg configuration snippets you created in
> /etc/X11/xorg.conf.d and/or /usr/share/X11/xorg.conf.d , in particular
> anything related to a mode named "1920x1080_60.00".

I forgot to mention, that is irrelevant. The problem happened before i had
anything configured in xorg.conf.d (also fixed it since obviously that mode
doesn't exist).

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

[Bug 101987] Loud fan and maximum GPU fan speed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101987

--- Comment #2 from mirh  ---
Bug 41762, bug 66963, bug 90263. 

If you want to still keep fglrx driver (or nevertheless experiment with
toggling open-source one) *and* an updated operating system, I'd recommend
Manjaro.

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

[PATCH][drm-next] drm/amdgpu: remove duplicate return statement

[Colin King]

From: Colin Ian King 

Remove a redundant identical return statement, it has no use.

Detected by CoverityScan, CID#1454586 ("Structurally dead code")

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
index fb6e5dbd5a03..309f2419c6d8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
@@ -155,7 +155,6 @@ static const struct kfd2kgd_calls kfd2kgd = {
 struct kfd2kgd_calls *amdgpu_amdkfd_gfx_8_0_get_functions(void)
 {
return (struct kfd2kgd_calls *)
-   return (struct kfd2kgd_calls *)
 }
 
 static inline struct amdgpu_device *get_amdgpu_device(struct kgd_dev *kgd)
-- 
2.14.1

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

Re: Etnaviv crashes on glmark2

[Fabio Estevam]

Hi Lucas,

On Wed, Aug 23, 2017 at 9:06 AM, Lucas Stach  wrote:

>> I don't recognize this either, I haven't seen a kernel memory managment 
>> error while
>> running glmark2 (or anything w/ etnaviv) for a long time. Strange.
>
> This might also be related to the used xf86-video-armada version. Are
> you sure you are using the latest git version?

I am not using X11, so xf86-video-armada is not being used in this test.

In case it helps, here is the complete SD card image I am using:
https://www.dropbox.com/s/9nryemx9vkdvsdh/sdcard.img?dl=0

It is an image generated by Buildroot and contains bootloader, kernel,
rootfs for imx6qsabresd, but you can easily re-use it on a different
board by rewriting the bootloader.

Just copy it directly to the SD card: sudo dd if=sdcard.img
of=/dev/mmcblk0; sync

In order to reproduce the failure, just run 'glmark2-es2-drm' and wait
until it completes. The crash always happen after the last test runs.

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

Re: [PATCH] drm/doc: Document ioctl errno value patterns

[Daniel Vetter]

On Fri, Aug 18, 2017 at 07:43:28PM +0200, Daniel Vetter wrote:
> We're not super-consistent about these, but I think it's worth to
> document at least the commmon patterns.
> 
> v2:
> - Add a not about ENOTTY (it's just a confusing name, but used
> exactly what it's meant for in DRM) (Chris).
> - Unconfuse the text for ENODEV (Daniel)
> - Move text undert the IOCTL heading (Chris).
> - typos
> 
> Cc: Daniel Stone 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: "Zhang, Tina" 
> Reviewed-by: Chris Wilson 
> Signed-off-by: Daniel Vetter 

Pushed to drm-misc-next.
-Daniel

> ---
>  Documentation/gpu/drm-uapi.rst | 55 
> ++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 679373b4a03f..a2214cc1f821 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -168,6 +168,61 @@ IOCTL Support on Device Nodes
>  .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
> :doc: driver specific ioctls
>  
> +Recommended IOCTL Return Values
> +---
> +
> +In theory a driver's IOCTL callback is only allowed to return very few error
> +codes. In practice it's good to abuse a few more. This section documents 
> common
> +practice within the DRM subsystem:
> +
> +ENOENT:
> +Strictly this should only be used when a file doesn't exist e.g. when
> +calling the open() syscall. We reuse that to signal any kind of 
> object
> +lookup failure, e.g. for unknown GEM buffer object handles, unknown 
> KMS
> +object handles and similar cases.
> +
> +ENOSPC:
> +Some drivers use this to differentiate "out of kernel memory" from 
> "out
> +of VRAM". Sometimes also applies to other limited gpu resources used 
> for
> +rendering (e.g. when you have a special limited compression buffer).
> +Sometimes resource allocation/reservation issues in command 
> submission
> +IOCTLs are also signalled through EDEADLK.
> +
> +Simply running out of kernel/system memory is signalled through 
> ENOMEM.
> +
> +EPERM/EACCESS:
> +Returned for an operation that is valid, but needs more privileges.
> +E.g. root-only or much more common, DRM master-only operations return
> +this when when called by unpriviledged clients. There's no clear
> +difference between EACCESS and EPERM.
> +
> +ENODEV:
> +Feature (like PRIME, modesetting, GEM) is not supported by the 
> driver.
> +
> +ENXIO:
> +Remote failure, either a hardware transaction (like i2c), but also 
> used
> +when the exporting driver of a shared dma-buf or fence doesn't 
> support a
> +feature needed.
> +
> +EINTR:
> +DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL 
> can
> +return EINTR and in such a case should be restarted with the IOCTL
> +parameters left unchanged.
> +
> +EIO:
> +The GPU died and couldn't be resurrected through a reset. Modesetting
> +hardware failures are signalled through the "link status" connector
> +property.
> +
> +EINVAL:
> +Catch-all for anything that is an invalid argument combination which
> +cannot work.
> +
> +IOCTL also use other error codes like ETIME, EFAULT, EBUSY, ENOTTY but their
> +usage is in line with the common meanings. The above list tries to just 
> document
> +DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning 
> of
> +"this IOCTL does not exist", and is used exactly as such in DRM.
> +
>  .. kernel-doc:: include/drm/drm_ioctl.h
> :internal:
>  
> -- 
> 2.13.3
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Etnaviv crashes on glmark2

[Lucas Stach]

Hi Fabio,

Am Mittwoch, den 23.08.2017, 10:46 +0200 schrieb Wladimir J. van der
Laan:
> > Etnaviv isn't CMA based, so this is certainly not a valid fix. It
> > probably doesn't crash anymore, as it isn't properly freeing the pages
> > backing the GEM object.
> > 
> > I've seen this crash in the early days of etnaviv a few times, but it
> > hasn't happened to me in a long time.
> 
> I don't recognize this either, I haven't seen a kernel memory managment error 
> while
> running glmark2 (or anything w/ etnaviv) for a long time. Strange.

This might also be related to the used xf86-video-armada version. Are
you sure you are using the latest git version?

Regards,
Lucas

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

[Bug 102372] [dc] [kabini] Errors during startup - X doesn't start

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102372

Bug ID: 102372
   Summary: [dc] [kabini] Errors during startup - X doesn't start
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: m...@fireburn.co.uk

Created attachment 133715
  --> https://bugs.freedesktop.org/attachment.cgi?id=133715=edit
Dmesg

Logs filled with errors, managed to SSH in and capture the dmesg before
rebooting

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

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||100199


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=100199
[Bug 100199] [performance] clover: implement non-blocking clEnqueueWriteBuffer
and clEnqueueReadBuffer
-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/omap: work-around for omap3 display enable

[Tomi Valkeinen]


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

On 13/06/17 12:02, Tomi Valkeinen wrote:
> Seems that on omap3 enabling a crtc without any planes causes a sync
> lost flood. This only happens on the first enable, and after that it
> works. This looks like an HW issue.
> 
> It's unclear why this is happening or how to fix it, but as a quick
> work-around, this patch enables i734 errata work-around for omap2 and
> omap3 too. The errata work-around enables and disables the LCD output
> with a plane once when waking up the DSS IP, and it seems to resolve the
> omap3 problem too. It is unclear if omap2 has the same issue, but it
> probably has and the WA should have no side effects so it should be safe
> to enable on omap2 too.

I was again debugging and testing this problem, and I don't think this patch
works very well. I'm getting endless sync losts again.

Here's another try, this time changing how the omapdrm commits the new setup.
At least for me this seems to work better.

 Tomi


From fc5cc9678e130196012c17b37e555d53d3d3476b Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen 
Date: Wed, 23 Aug 2017 12:19:02 +0300
Subject: [PATCHv2] drm/omap: work-around for omap3 display enable

Seems that on omap3 enabling a crtc without any planes causes a sync
lost flood. This only happens on the first enable, and after that it
works. This looks like an HW issue and it's unclear why this is
happening or how to fix it.

This started happening after 897145d0c7010b4e07fa9bc674b1dfb9a2c6fff9
("drm/omapdrm: Move commit_modeset_enables() before commit_planes()")
which, as a work-around, changed omapdrm first to do the modeset enable,
and plane set only after that. This WA should be fine on all DSS
versions, but apparently OMAP3 DSS is an exception.

This patch reverts that work-around for OMAP3 DSS.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 47 --
 1 file changed, 30 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 9b3c36b48356..cdf5b0601eba 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -84,23 +84,36 @@ static void omap_atomic_commit_tail(struct drm_atomic_state 
*old_state)
/* Apply the atomic update. */
drm_atomic_helper_commit_modeset_disables(dev, old_state);
 
-   /* With the current dss dispc implementation we have to enable
-* the new modeset before we can commit planes. The dispc ovl
-* configuration relies on the video mode configuration been
-* written into the HW when the ovl configuration is
-* calculated.
-*
-* This approach is not ideal because after a mode change the
-* plane update is executed only after the first vblank
-* interrupt. The dispc implementation should be fixed so that
-* it is able use uncommitted drm state information.
-*/
-   drm_atomic_helper_commit_modeset_enables(dev, old_state);
-   omap_atomic_wait_for_completion(dev, old_state);
-
-   drm_atomic_helper_commit_planes(dev, old_state, 0);
-
-   drm_atomic_helper_commit_hw_done(old_state);
+   if (priv->omaprev != 0x3430) {
+   /* With the current dss dispc implementation we have to enable
+* the new modeset before we can commit planes. The dispc ovl
+* configuration relies on the video mode configuration been
+* written into the HW when the ovl configuration is
+* calculated.
+*
+* This approach is not ideal because after a mode change the
+* plane update is executed only after the first vblank
+* interrupt. The dispc implementation should be fixed so that
+* it is able use uncommitted drm state information.
+*/
+   drm_atomic_helper_commit_modeset_enables(dev, old_state);
+   omap_atomic_wait_for_completion(dev, old_state);
+
+   drm_atomic_helper_commit_planes(dev, old_state, 0);
+
+   drm_atomic_helper_commit_hw_done(old_state);
+   } else {
+   /*
+* OMAP3 DSS seems to have issues with the work-around above,
+* resulting in endless sync losts if a crtc is enabled without
+* a plane. For now, skip the WA for OMAP3.
+*/
+   drm_atomic_helper_commit_planes(dev, old_state, 0);
+
+   drm_atomic_helper_commit_modeset_enables(dev, old_state);
+
+   drm_atomic_helper_commit_hw_done(old_state);
+   }
 
/*
 * Wait for completion of the page flips to ensure that old buffers
-- 
2.7.4


___
dri-devel mailing list

[Bug 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101691

--- Comment #32 from Ethan Hsieh  ---
Created attachment 133712
  --> https://bugs.freedesktop.org/attachment.cgi?id=133712=edit
syslog

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

Re: [PATCH libdrm v2 2/2] android: amdgpu: fix build break

[Chih-Wei Huang]

2017-08-21 20:18 GMT+08:00 Emil Velikov :
> On 17 August 2017 at 04:31, Chih-Wei Huang  wrote:
>> Ping. Is there any other concern to merge the fix?
>>
> My earlier suggestion was to use the respective Android build system
> variable, instead of hardcoding the actual path.

Oh. Sorry I didn't really get your point.
But IMO that's not possible.
TARGET_OUT_ETC is not a valid path in the target device.
Unless you want to see a more complex rule like
/($notdir $(TARGET_OUT_ETC))/hwdata/amdgpu.ids ...

> Merged v2 of the series, although I reserve my right of "I told you
> so" as this comes to bite :-)


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101691

--- Comment #31 from Ethan Hsieh  ---
Created attachment 133711
  --> https://bugs.freedesktop.org/attachment.cgi?id=133711=edit
Xorg.0.log

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

[Bug 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101691

--- Comment #30 from Ethan Hsieh  ---
Created attachment 133710
  --> https://bugs.freedesktop.org/attachment.cgi?id=133710=edit
kern.log (drm.debug=0xe)

Here is the timestamp of kern.log

--- DC mode ---
1. timestamp: 16:49
$ DRI_PRIME=1 glxgears
2. timestamp: 16:50
Stop glxgears
3. timestamp: 16:51
plug power adaptor in
--- AC mode ---
4. timestamp: 16:52
$ DRI_PRIME=1 glxgears
===> corruption!!! <===
5. timestamp: 16:53
Stop glxgears
6. timestamp: 16:54
$ glxgears
7. timestamp: 16:55
Stop glxgears

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

Re: Etnaviv crashes on glmark2

[Wladimir J. van der Laan]

> Etnaviv isn't CMA based, so this is certainly not a valid fix. It
> probably doesn't crash anymore, as it isn't properly freeing the pages
> backing the GEM object.
> 
> I've seen this crash in the early days of etnaviv a few times, but it
> hasn't happened to me in a long time.

I don't recognize this either, I haven't seen a kernel memory managment error 
while
running glmark2 (or anything w/ etnaviv) for a long time. Strange.

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

Re: [PATCH] drm/amdgpu: check memory allocation failure

[Christian König]

Am 23.08.2017 um 07:52 schrieb Christophe JAILLET:

Check memory allocation failure and return -ENOMEM in such a case.

'num_post_dep_syncobjs' still has to be set to 0 before the test in order
to have it initialized if 'amdgpu_cs_parser_fini()' is called to free
resources.

The calling graph would be, in such a case!
failure in amdgpu_cs_process_syncobj_out_dep()
   ---> error code returned by amdgpu_cs_dependencies()
  --> amdgpu_cs_parser_fini() is called

Signed-off-by: Christophe JAILLET 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 15d4a28d73bb..baa90df90aea 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1079,6 +1079,9 @@ static int amdgpu_cs_process_syncobj_out_dep(struct 
amdgpu_cs_parser *p,
 GFP_KERNEL);
p->num_post_dep_syncobjs = 0;
  
+	if (!p->post_dep_syncobjs)

+   return -ENOMEM;
+
for (i = 0; i < num_deps; ++i) {
p->post_dep_syncobjs[i] = drm_syncobj_find(p->filp, 
deps[i].handle);
if (!p->post_dep_syncobjs[i])



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

Re: [v2] timers: Fix excessive granularity of new timers after a nohz idle

[jeffy]

Hi Thierry,

i hit a compile error with this patch:

  CC  drivers/gpu/drm/tegra/trace.o
In file included from drivers/gpu/drm/tegra/trace.h:68:0,
 from drivers/gpu/drm/tegra/trace.c:2:
./include/trace/define_trace.h:88:43: fatal error: ./trace.h: No such 
file or directory

compilation terminated.
scripts/Makefile.build:311: recipe for target 
'drivers/gpu/drm/tegra/trace.o' failed



On 08/22/2017 04:43 PM, Nicholas Piggin wrote:

+++ b/drivers/gpu/drm/tegra/Makefile
@@ -24,4 +24,6 @@ tegra-drm-$(CONFIG_ARCH_TEGRA_186_SOC) += \
parker/dsi.o \
parker/sor.o

+tegra-drm-y += trace.o
+


maybe we need this:

+++ b/drivers/gpu/drm/tegra/Makefile
@@ -19,4 +19,6 @@ tegra-drm-y := \

 tegra-drm-y += trace.o

+CFLAGS_trace.o := -I$(src)
+
 obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o

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

[Bug 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101691

--- Comment #29 from Michel Dänzer  ---
(In reply to qwang13 from comment #28)
> Again, Would you create another bug to separately track tearing issue as
> Michel comment#23 said?

Per comment 27, the tearing is already fixed with current upstream versions, so
there's no point in creating another report here for that.

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

Re: Etnaviv crashes on glmark2

[Lucas Stach]

Am Dienstag, den 22.08.2017, 12:59 -0300 schrieb Fabio Estevam:
> On Tue, Aug 22, 2017 at 9:47 AM, Fabio Estevam  wrote:
> > Hi,
> >
> > I am running kernel 4.12.8 and mesa 17.1.6 on a imx6q, but glmark2
> > never runs successfully until the end. It always crashes like this:
> >
> > ** Failed to set swap interval. Results may be bounded above by refresh 
> > rate.
> > [conditionals] fragment-steps=0:vertex-steps=0: FPS: 63 FrameTime: 15.873 ms
> > [  288.732107] Unable to handle kernel paging request at virtual
> > address 00e71a74
> > [  288.739394] pgd = ee52c000
> > [  288.742115] [00e71a74] *pgd=
> > [  288.745782] Internal error: Oops: 5 [#1] SMP ARM
> > [  288.750409] Modules linked in:
> > [  288.753481] CPU: 0 PID: 221 Comm: glmark2-es2-drm Not tainted 4.12.8 #1
> > [  288.760101] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > [  288.766635] task: ee420c40 task.stack: ee4f
> > [  288.771181] PC is at page_mapping+0xc/0xa4
> > [  288.775291] LR is at set_page_dirty+0x14/0xc8
> 
> If I use the generic drm_gem_cma_free_object() function instead the
> error does not happen anymore:
> https://pastebin.com/edx37jNG
> 
> Not sure if this is a valid fix though. Any comments?

Etnaviv isn't CMA based, so this is certainly not a valid fix. It
probably doesn't crash anymore, as it isn't properly freeing the pages
backing the GEM object.

I've seen this crash in the early days of etnaviv a few times, but it
hasn't happened to me in a long time.

Regards,
Lucas

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

[Bug 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101691

--- Comment #28 from qwang13  ---
hi @Timo Aaltonen

Again, Would you create another bug to separately track tearing issue as Michel
comment#23 said?

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

Re: [PATCH] drm/bridge/sii8620: add remote control support

[Hans Verkuil]

On 08/16/2017 01:55 PM, Andrzej Hajda wrote:
> On 03.08.2017 10:28, Hans Verkuil wrote:
>> Hi Maciej,
>>
>> Unfortunately I do not have the MHL spec, but I was wondering what the
>> relationship between RCP and CEC is. CEC has remote control support as
>> well, so is RCP that subset of the CEC specification or is it completely
>> separate?
> 
> We also do not have MHL specs. From my research it looks like MHL
> consortium was mainly focused on supporting different input devices -
> remote control, mice, keyboard, touchscreen, game controller, etc. In
> public data sheets of some chips Lattice/Silicon Image (main MHL chip
> producer) suggest they do not support CEC pass-through via MHL[1].
> On the other side superMHL extends RCP with support for multiple devices
> [2], so for me it looks like RCP wants to be an alternative to CEC.
> But all this is just my interpretation of info found on the Net.

Surely Samsung must have access to the MHL specs? (I know, big company,
hard to figure out who to talk to)

I ask because the devil is often in the details. I recently fixed the CEC
auto-repeat implementation that was subtly wrong. It is very desirable
if this driver was based on the actual spec. You should definitely test
auto-repeat.

I gather that the scancodes for keys in MHL are identical to those of CEC?
Since in your v3 patch you reuse those.

Regards,

Hans

> 
> [1]:
> http://www.latticesemi.com/~/media/LatticeSemi/Documents/DataSheets/ASSP/SiI-DS-1128_Public.pdf?document_id=51627
> [2]: https://en.wikipedia.org/wiki/Mobile_High-Definition_Link#superMHL
> 
> Regards
> Andrzej
> 
>>
>> I'm CC-ing Sean Young and the linux-media mailinglist as well since Sean
>> maintains the rc subsystem. Which you probably should use, but I'm not the
>> expert on that.
>>
>> Regards,
>>
>>  Hans
>>
>> On 08/03/17 09:44, Maciej Purski wrote:
>>> MHL specification defines Remote Control Protocol(RCP) to
>>> send input events between MHL devices.
>>> The driver now recognizes RCP messages and reacts to them
>>> by reporting key events to input subsystem, allowing
>>> a user to control a device using TV remote control.
>>>
>>> Signed-off-by: Maciej Purski 
>>> ---
>>>  drivers/gpu/drm/bridge/sil-sii8620.c | 188 
>>> ++-
>>>  include/drm/bridge/mhl.h |   4 +
>>>  2 files changed, 187 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
>>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>>> index 2d51a22..7e75f2f 100644
>>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>>> @@ -19,6 +19,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -58,6 +59,7 @@ enum sii8620_mt_state {
>>>  struct sii8620 {
>>> struct drm_bridge bridge;
>>> struct device *dev;
>>> +   struct input_dev *rcp_input_dev;
>>> struct clk *clk_xtal;
>>> struct gpio_desc *gpio_reset;
>>> struct gpio_desc *gpio_int;
>>> @@ -106,6 +108,82 @@ struct sii8620_mt_msg {
>>> sii8620_cb continuation;
>>>  };
>>>  
>>> +static struct {
>>> +   u16 key;
>>> +   u16 extra_key;
>>> +   bool autorepeat;
>>> +}  rcp_keymap[] = {
>>> +   [0x00] = { KEY_SELECT },
>>> +   [0x01] = { KEY_UP, 0, true },
>>> +   [0x02] = { KEY_DOWN, 0, true },
>>> +   [0x03] = { KEY_LEFT, 0, true },
>>> +   [0x04] = { KEY_RIGHT, 0, true },
>>> +
>>> +   [0x05] = { KEY_RIGHT, KEY_UP, true },
>>> +   [0x06] = { KEY_RIGHT, KEY_DOWN, true },
>>> +   [0x07] = { KEY_LEFT,  KEY_UP, true },
>>> +   [0x08] = { KEY_LEFT,  KEY_DOWN, true },
>>> +
>>> +   [0x09] = { KEY_MENU },
>>> +   [0x0A] = { KEY_UNKNOWN },
>>> +   [0x0B] = { KEY_UNKNOWN },
>>> +   [0x0C] = { KEY_BOOKMARKS },
>>> +   [0x0D] = { KEY_EXIT },
>>> +
>>> +   [0x20] = { KEY_NUMERIC_0 },
>>> +   [0x21] = { KEY_NUMERIC_1 },
>>> +   [0x22] = { KEY_NUMERIC_2 },
>>> +   [0x23] = { KEY_NUMERIC_3 },
>>> +   [0x24] = { KEY_NUMERIC_4 },
>>> +   [0x25] = { KEY_NUMERIC_5 },
>>> +   [0x26] = { KEY_NUMERIC_6 },
>>> +   [0x27] = { KEY_NUMERIC_7 },
>>> +   [0x28] = { KEY_NUMERIC_8 },
>>> +   [0x29] = { KEY_NUMERIC_9 },
>>> +
>>> +   [0x2A] = { KEY_DOT },
>>> +   [0x2B] = { KEY_ENTER },
>>> +   [0x2C] = { KEY_CLEAR },
>>> +
>>> +   [0x30] = { KEY_CHANNELUP, 0, true },
>>> +   [0x31] = { KEY_CHANNELDOWN, 0, true },
>>> +
>>> +   [0x33] = { KEY_SOUND },
>>> +   [0x35] = { KEY_PROGRAM }, /* Show Information */
>>> +
>>> +   [0x37] = { KEY_PAGEUP, 0, true },
>>> +   [0x38] = { KEY_PAGEDOWN, 0, true },
>>> +
>>> +   [0x41] = { KEY_VOLUMEUP, 0, true },
>>> +   [0x42] = { KEY_VOLUMEDOWN, 0, true },
>>> +   [0x43] = { KEY_MUTE },
>>> +   [0x44] = { KEY_PLAY },
>>> +   [0x45] = { KEY_STOP },
>>> +   [0x46] = { KEY_PLAYPAUSE }, /* Pause */
>>> +   [0x47] = { KEY_RECORD },
>>> +   [0x48] = { KEY_REWIND, 0, true },
>>> +   [0x49] = { KEY_FASTFORWARD, 0, true },
>>> +   [0x4A] = { KEY_EJECTCD },
>>> +   [0x4B] = { KEY_NEXTSONG, 0, true }, 

Re: [PATCH v3] drm/bridge/sii8620: add remote control support

[Hans Verkuil]

Maciej,

I'm cross-posting this to linux-media and the rc maintainer Sean Young.

Note that various RC defines have been renamed in the upcoming 4.14. It might be
better to base your code on top of https://git.linuxtv.org/media_tree.git/
which has those patches merged.

Regards,

Hans

On 08/21/2017 11:33 AM, Maciej Purski wrote:
> MHL specification defines Remote Control Protocol(RCP) to
> send input events between MHL devices.
> The driver now recognizes RCP messages and reacts to them
> by reporting key events to input subsystem, allowing
> a user to control a device using TV remote control.
> 
> Changes in v2:
> - use RC subsystem (including CEC keymap)
> - RC device initialized in attach drm_bridge callback and
>   removed in detach callback. This is necessary, because RC_CORE,
>   which is needed during rc_dev init, is loaded after sii8620.
>   DRM bridge is binded later which solves the problem.
> - add RC_CORE dependency
> 
> Changes in v3:
> - fix error handling in init_rcp and in attach callback
> 
> Signed-off-by: Maciej Purski 
> ---
>  drivers/gpu/drm/bridge/Kconfig   |   2 +-
>  drivers/gpu/drm/bridge/sil-sii8620.c | 101 
> +--
>  include/drm/bridge/mhl.h |   4 ++
>  3 files changed, 101 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index adf9ae0..6ef901c 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -71,7 +71,7 @@ config DRM_PARADE_PS8622
>  
>  config DRM_SIL_SII8620
>   tristate "Silicon Image SII8620 HDMI/MHL bridge"
> - depends on OF
> + depends on OF && RC_CORE
>   select DRM_KMS_HELPER
>   help
> Silicon Image SII8620 HDMI/MHL bridge chip driver.
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 2d51a22..e072bca 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -28,6 +28,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #include "sil-sii8620.h"
>  
>  #define SII8620_BURST_BUF_LEN 288
> @@ -58,6 +60,7 @@ enum sii8620_mt_state {
>  struct sii8620 {
>   struct drm_bridge bridge;
>   struct device *dev;
> + struct rc_dev *rc_dev;
>   struct clk *clk_xtal;
>   struct gpio_desc *gpio_reset;
>   struct gpio_desc *gpio_int;
> @@ -431,6 +434,16 @@ static void sii8620_mt_rap(struct sii8620 *ctx, u8 code)
>   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RAP, code);
>  }
>  
> +static void sii8620_mt_rcpk(struct sii8620 *ctx, u8 code)
> +{
> + sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPK, code);
> +}
> +
> +static void sii8620_mt_rcpe(struct sii8620 *ctx, u8 code)
> +{
> + sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPE, code);
> +}
> +
>  static void sii8620_mt_read_devcap_send(struct sii8620 *ctx,
>   struct sii8620_mt_msg *msg)
>  {
> @@ -1753,6 +1766,25 @@ static void sii8620_send_features(struct sii8620 *ctx)
>   sii8620_write_buf(ctx, REG_MDT_XMIT_WRITE_PORT, buf, ARRAY_SIZE(buf));
>  }
>  
> +static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)
> +{
> + bool pressed = !(scancode & MHL_RCP_KEY_RELEASED_MASK);
> +
> + scancode &= MHL_RCP_KEY_ID_MASK;
> +
> + if (!ctx->rc_dev) {
> + dev_dbg(ctx->dev, "RCP input device not initialized\n");
> + return false;
> + }
> +
> + if (pressed)
> + rc_keydown(ctx->rc_dev, RC_TYPE_CEC, scancode, 0);
> + else
> + rc_keyup(ctx->rc_dev);
> +
> + return true;
> +}
> +
>  static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
>  {
>   u8 ints[MHL_INT_SIZE];
> @@ -1804,19 +1836,25 @@ static void sii8620_msc_mt_done(struct sii8620 *ctx)
>  
>  static void sii8620_msc_mr_msc_msg(struct sii8620 *ctx)
>  {
> - struct sii8620_mt_msg *msg = sii8620_msc_msg_first(ctx);
> + struct sii8620_mt_msg *msg;
>   u8 buf[2];
>  
> - if (!msg)
> - return;
> -
>   sii8620_read_buf(ctx, REG_MSC_MR_MSC_MSG_RCVD_1ST_DATA, buf, 2);
>  
>   switch (buf[0]) {
>   case MHL_MSC_MSG_RAPK:
> + msg = sii8620_msc_msg_first(ctx);
> + if (!msg)
> + return;
>   msg->ret = buf[1];
>   ctx->mt_state = MT_STATE_DONE;
>   break;
> + case MHL_MSC_MSG_RCP:
> + if (!sii8620_rcp_consume(ctx, buf[1]))
> + sii8620_mt_rcpe(ctx,
> + MHL_RCPE_STATUS_INEFFECTIVE_KEY_CODE);
> + sii8620_mt_rcpk(ctx, buf[1]);
> + break;
>   default:
>   dev_err(ctx->dev, "%s message type %d,%d not supported",
>   __func__, buf[0], buf[1]);
> @@ -2102,11 +2140,62 @@ static void sii8620_cable_in(struct sii8620 *ctx)
>   enable_irq(to_i2c_client(ctx->dev)->irq);
>  }
>  
> +static void 

Re: [PATCH v6 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS

[Sandy Huang]

在 2017/8/22 10:48, Rob Herring 写道:

On Fri, Aug 18, 2017 at 04:09:49PM +0800, Sandy Huang wrote:

This patch add Document for Rockchip Soc RK3288 LVDS,
This based on the patches from Mark yao and Heiko Stuebner.

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---
Changes:
 - use data-mapping instead of rockchip,data-mapping and rockchip,data-width
 - move rockchip,output to lvds node

  .../bindings/display/rockchip/rockchip-lvds.txt| 100 +
  1 file changed, 100 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
new file mode 100644
index 000..a33821b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
@@ -0,0 +1,100 @@
+Rockchip RK3288 LVDS interface
+
+
+Required properties:
+- compatible: matching the soc type, one of
+   - "rockchip,rk3288-lvds";
+
+- reg: physical base address of the controller and length
+   of memory mapped region.
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+- clock-names: must contain "pclk_lvds"
+
+- avdd1v0-supply: regulator phandle for 1.0V analog power
+- avdd1v8-supply: regulator phandle for 1.8V analog power
+- avdd3v3-supply: regulator phandle for 3.3V analog power
+
+- rockchip,grf: phandle to the general register files syscon
+- rockchip,output: "rgb", "lvds" or "duallvds", This describes the output face.


s/face/interface/


thanks, this will be fix at next version;


+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this controller.
+
+Required nodes:
+
+The lvds has two video ports as described by
+   Documentation/devicetree/bindings/media/video-interfaces.txt.
+Their connections are modeled using the OF graph bindings specified in
+   Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP inputs


with 2 endpoints...

yes, lvds port0 remote endpoint maybe vopb or vopl, i will add this 
describe at next version.



+- video port 1 for either a panel or subsequent encoder
+
+the lvds panel described by
+   Documentation/devicetree/bindings/display/panel/simple-panel.txt
+
+Panel required properties:
+- ports for remote LVDS output
+
+Panel optional properties:
+- data-mapping: should be "vesa-24","jeida-24" or "jeida-18".
+This describes decribed by:
+   Documentation/devicetree/bindings/display/panel/panel-lvds.txt
+
+Example:
+
+lvds_panel: lvds-panel {
+   status = "okay";


Don't show status in examples.


thanks, this will be fix at next version;

+   compatible = "auo,b101ean01";
+   enable-gpios = < 21 GPIO_ACTIVE_HIGH>;
+   data-mapping = "jeida-24";
+
+   ports {
+   panel_in_lvds: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+};
+
+For Rockchip RK3288:
+
+   lvds: lvds@ff96c000 {
+   compatible = "rockchip,rk3288-lvds";
+   rockchip,grf = <>;
+   reg = <0xff96c000 0x4000>;
+   clocks = < PCLK_LVDS_PHY>;
+   clock-names = "pclk_lvds";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <_ctl>;
+   avdd1v0-supply = <_lcd>;
+   avdd1v8-supply = <_lcd>;
+   avdd3v3-supply = <_33>;
+   rockchip,output = "rgb";
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   lvds_in: port@0 {
+   reg = <0>;
+
+   lvds_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_lvds>;
+   };
+   lvds_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_lvds>;
+   };
+   };
+
+   lvds_out: port@1 {
+   reg = <1>;
+
+   lvds_out_panel: endpoint {
+   remote-endpoint = <_in_lvds>;
+   };
+   };
+   };
+   };
--
2.7.4




___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip





___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH v7 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS

[Sandy Huang]

This patch add Document for Rockchip Soc RK3288 LVDS,
This based on the patches from Mark yao and Heiko Stuebner.

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---

Changes according to Rob Herring's review.

 .../bindings/display/rockchip/rockchip-lvds.txt| 99 ++
 1 file changed, 99 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
new file mode 100644
index 000..da6939e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
@@ -0,0 +1,99 @@
+Rockchip RK3288 LVDS interface
+
+
+Required properties:
+- compatible: matching the soc type, one of
+   - "rockchip,rk3288-lvds";
+
+- reg: physical base address of the controller and length
+   of memory mapped region.
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+- clock-names: must contain "pclk_lvds"
+
+- avdd1v0-supply: regulator phandle for 1.0V analog power
+- avdd1v8-supply: regulator phandle for 1.8V analog power
+- avdd3v3-supply: regulator phandle for 3.3V analog power
+
+- rockchip,grf: phandle to the general register files syscon
+- rockchip,output: "rgb", "lvds" or "duallvds", This describes the output 
interface
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this controller.
+
+Required nodes:
+
+The lvds has two video ports as described by
+   Documentation/devicetree/bindings/media/video-interfaces.txt
+Their connections are modeled using the OF graph bindings specified in
+   Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
+- video port 1 for either a panel or subsequent encoder
+
+the lvds panel described by
+   Documentation/devicetree/bindings/display/panel/simple-panel.txt
+
+Panel required properties:
+- ports for remote LVDS output
+
+Panel optional properties:
+- data-mapping: should be "vesa-24","jeida-24" or "jeida-18".
+This describes decribed by:
+   Documentation/devicetree/bindings/display/panel/panel-lvds.txt
+
+Example:
+
+lvds_panel: lvds-panel {
+   compatible = "auo,b101ean01";
+   enable-gpios = < 21 GPIO_ACTIVE_HIGH>;
+   data-mapping = "jeida-24";
+
+   ports {
+   panel_in_lvds: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+};
+
+For Rockchip RK3288:
+
+   lvds: lvds@ff96c000 {
+   compatible = "rockchip,rk3288-lvds";
+   rockchip,grf = <>;
+   reg = <0xff96c000 0x4000>;
+   clocks = < PCLK_LVDS_PHY>;
+   clock-names = "pclk_lvds";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <_ctl>;
+   avdd1v0-supply = <_lcd>;
+   avdd1v8-supply = <_lcd>;
+   avdd3v3-supply = <_33>;
+   rockchip,output = "rgb";
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   lvds_in: port@0 {
+   reg = <0>;
+
+   lvds_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_lvds>;
+   };
+   lvds_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_lvds>;
+   };
+   };
+
+   lvds_out: port@1 {
+   reg = <1>;
+
+   lvds_out_panel: endpoint {
+   remote-endpoint = <_in_lvds>;
+   };
+   };
+   };
+   };
-- 
2.7.4


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

[PATCH v7 0/3] Add support Rockchip Soc LVDS

[Sandy Huang]

this patches add support Rockchip RK3288 LVDS support, based on patches from
Mark yao[0] and Heiko Stuebner[1].

[0]: https://github.com/RockchipOpensourceCommunity/popmetal-kernel-3.14
[1]: http://lists.infradead.org/pipermail/linux-rockchip/2015-April/002830.html

Changes:
- Update rockchip_lvds_encoder_helper_funcs to atomic API
- Add bridge function for RGB/LVDS convert to other output type
- Fix some unreasonable define
- Adapter to the latest rockchip DRM driver framework
- Add pinctrl for RGB output type
- Reseved some define for rockchip next Soc

Sandy Huang (3):
  dt-bindings: display: Add Document for Rockchip Soc LVDS
  ARM: dts: Add LVDS info for rk3288
  drm/rockchip: Add support for Rockchip Soc LVDS

 .../bindings/display/rockchip/rockchip-lvds.txt|  99 
 arch/arm/boot/dts/rk3288.dtsi  |  52 ++
 drivers/gpu/drm/rockchip/Kconfig   |   9 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   1 +
 drivers/gpu/drm/rockchip/rockchip_lvds.c   | 582 +
 drivers/gpu/drm/rockchip/rockchip_lvds.h   | 114 
 8 files changed, 860 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

-- 
2.7.4


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

[PATCH v7 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Sandy Huang]

This adds support for Rockchip soc lvds found on rk3288
Based on the patches from Mark yao and Heiko Stuebner

Signed-off-by: Sandy Huang 
Signed-off-by: Mark Yao 
Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
 drivers/gpu/drm/rockchip/rockchip_lvds.c| 582 
 drivers/gpu/drm/rockchip/rockchip_lvds.h| 114 ++
 6 files changed, 709 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 50c41c0..80672f4 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -59,3 +59,12 @@ config ROCKCHIP_INNO_HDMI
  This selects support for Rockchip SoC specific extensions
  for the Innosilicon HDMI driver. If you want to enable
  HDMI on RK3036 based SoC, you should select this option.
+
+config ROCKCHIP_LVDS
+   bool "Rockchip LVDS support"
+   depends on DRM_ROCKCHIP
+   help
+ Choose this option to enable support for Rockchip LVDS controllers.
+ Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
+ support LVDS, rgb, dual LVDS output mode. say Y to enable its
+ driver.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index fa8dc9d..a881d2c 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -12,5 +12,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o 
cdn-dp-reg.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index c41f48a..082c251 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -445,6 +445,8 @@ static int __init rockchip_drm_init(void)
 
num_rockchip_sub_drivers = 0;
ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_DRM_ROCKCHIP);
+   ADD_ROCKCHIP_SUB_DRIVER(rockchip_lvds_driver,
+   CONFIG_ROCKCHIP_LVDS);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
CONFIG_ROCKCHIP_ANALOGIX_DP);
ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index c7e96b8..498dfbc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -69,5 +69,6 @@ extern struct platform_driver dw_hdmi_rockchip_pltfm_driver;
 extern struct platform_driver dw_mipi_dsi_driver;
 extern struct platform_driver inno_hdmi_driver;
 extern struct platform_driver rockchip_dp_driver;
+extern struct platform_driver rockchip_lvds_driver;
 extern struct platform_driver vop_platform_driver;
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
new file mode 100644
index 000..86d9a8c
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -0,0 +1,582 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Mark Yao 
+ *  Sandy Huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+#include "rockchip_lvds.h"
+
+#define DISPLAY_OUTPUT_RGB 0
+#define DISPLAY_OUTPUT_LVDS1
+#define DISPLAY_OUTPUT_DUAL_LVDS   2
+
+#define connector_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, connector)
+
+#define encoder_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, encoder)
+
+/**
+ * rockchip_lvds_soc_data - rockchip lvds Soc private data
+ * @ch1_offset: lvds channel 1 registe offset
+ * grf_soc_con6: general registe offset for