[GIT PULL FOR v4.13] Renesas R-Car DU driver changes
Hi Dave, The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://linuxtv.org/pinchartl/media.git drm/next/du for you to fetch changes up to fa5b4114202de0c1a7a64fd407af0b81ca529419: drm: rcar-du: Map memory through the VSP device (2017-06-09 12:25:38 +0100) The series interleaves DRM and V4L2 patches due to dependencies between the R- Car DU and VSP drivers. Mauro has acked all the V4L2 patches to go through your tree, and they don't conflict with anything queued for v4.13 in his tree. If I need to send any conflicting patches through Mauro's tree for v4.13, I'll make sure to base them on this branch. Kieran Bingham (3): v4l: vsp1: Postpone frame end handling in event of display list race v4l: vsp1: Extend VSP1 module API to allow DRM callbacks drm: rcar-du: Register a completion callback with VSP1 Laurent Pinchart (5): drm: rcar-du: Arm the page flip event after queuing the page flip v4l: rcar-fcp: Don't get/put module reference v4l: rcar-fcp: Add an API to retrieve the FCP device v4l: vsp1: Add API to map and unmap DRM buffers through the VSP drm: rcar-du: Map memory through the VSP device Magnus Damm (1): v4l: vsp1: Map the DL and video buffers through the proper bus master drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 30 --- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c| 83 --- drivers/gpu/drm/rcar-du/rcar_du_vsp.h| 2 + drivers/media/platform/rcar-fcp.c| 17 drivers/media/platform/vsp1/vsp1.h | 1 + drivers/media/platform/vsp1/vsp1_dl.c| 23 +-- drivers/media/platform/vsp1/vsp1_dl.h| 2 +- drivers/media/platform/vsp1/vsp1_drm.c | 41 drivers/media/platform/vsp1/vsp1_drm.h | 11 ++ drivers/media/platform/vsp1/vsp1_drv.c | 9 + drivers/media/platform/vsp1/vsp1_pipe.c | 13 ++- drivers/media/platform/vsp1/vsp1_video.c | 2 +- include/media/rcar-fcp.h | 5 +++ include/media/vsp1.h | 10 + 15 files changed, 215 insertions(+), 35 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: synopsys/dw-hdmi: Provide default configuration function for HDMI 2.0 PHY
Hi Jose,
On Friday 09 Jun 2017 13:53:12 Jose Abreu wrote:
> On 09-06-2017 12:04, Jose Abreu wrote:
> > Currently HDMI 2.0 PHYs do not have a default configuration function.
> >
> > As these PHYs have the same register layout as the 3D PHYs we can
> > safely use the default configuration function.
>
> I may have been a little to fast arriving at this conclusion. I
> mean most of the registers match but in the configuration
> function there are registers that do not match. Did you actually
> test this configuration function with an HDMI 2.0 phy? And did
> you test with different video modes? From my experience the phy
> may be wrongly configured and sometimes work anyway.
>
> Do please retest with as many video modes as you can and give me
> your phy ID (read from controller config reg HDMI_CONFIG2_ID).
The Renesas R-Car Gen3 HDMI PHY reports an DWC HDMI 2.0 TX PHY ID, but has a
configuration function (rcar_hdmi_phy_configure() in drivers/gpu/drm/rcar-
du/rcar_dw_hdmi.c) that doesn't match hdmi_phy_configure_dwc_hdmi_3d_tx().
From the information I have been given the layout of the configuration
registers haven't been changed by Renesas. I know we've briefly discussed this
in the past, but I'd appreciate if you could have a second look and tell me
what you think.
> > If, for some reason,
> >
> > the PHY is custom this change will not make any impact because
> > in configuration function we prefer the pdata provided configuration
> > function over the internal one.
> >
> > This patch is based on today's drm-misc-next branch.
> >
> > Signed-off-by: Jose Abreu
> > Cc: Kieran Bingham
> > Cc: Laurent Pinchart
> > Cc: Archit Taneja
> > Cc: Andrzej Hajda
> > Cc: Mark Yao
> > Cc: Carlos Palminha
> > ---
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index ead1124..10c8d8c 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -2170,6 +2170,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void
> > *dev_id)
> > .name = "DWC HDMI 2.0 TX PHY",
> > .gen = 2,
> > .has_svsret = true,
> > + .configure = hdmi_phy_configure_dwc_hdmi_3d_tx,
> > }, {
> > .type = DW_HDMI_PHY_VENDOR_PHY,
> > .name = "Vendor PHY",
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: dw-hdmi: Fix compilation breakage by selecting REGMAP_MMIO
The dw-hdmi driver switched to regmap-mmio, but lacks the dependency in
Kconfig. This can result in compilation breakages. Fix it by selecting
REGMAP_MMIO.
Fixes: 80e2f97968b5 ("drm: bridge: dw-hdmi: Switch to regmap for register
access")
Reported-by: kbuild test robot
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/synopsys/Kconfig | 1 +
1 file changed, 1 insertion(+)
Archit,
This is a v4.12 regression fix. While not super critical, it would be
nice if it could get merged in v4.12.
diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 40d2827a6d19..53e78d092d18 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -1,6 +1,7 @@
config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
+ select REGMAP_MMIO
config DRM_DW_HDMI_AHB_AUDIO
tristate "Synopsys Designware AHB Audio interface"
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/1] drm: Add Grain Media GM12U320 kms driver
Hi, On 09-06-17 22:59, Marco Diego Aurélio Mesquita wrote: Hi Devs! On Thu, Jun 8, 2017 at 4:08 AM, Hans de Goede wrote: I don't think that using cma for the gm12u320 is a good idea, it will typically be used as a secondary GPU output together with a real GPU extending the desktop by being a prime display output. So for the memory management stuff I would keep the code copied from the udl driver (which we may later split out in a separate helper lib for devices where the framebuffer is in normal system memory and we have some scather-gather capable process copying it to the real device over e.g. USB) I got the PL111 driver and stripped all device specific code. Also, I added the get_modes and driver usb probe functions from gm12u320. The resulting code is available in https://gitlab.com/marcodiego/dummy-display-driver . Cool, I'm glad to see that you are making progress on this! Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101368] Nouveau regression GT218M in Kernel 4.11 Won't Boot
https://bugs.freedesktop.org/show_bug.cgi?id=101368 --- Comment #1 from Ilia Mirkin --- Any particular reason you're blaming nouveau? >From the 4.10 log, it appears that i915 is the primary drm driver. What does "won't boot" mean? What happens if you specify 'nouveau.modeset=0' (which has the effect of disabling nouveau entirely but leaving i915 as it was)? -- 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] staging: vboxvideo: Add vboxvideo to drivers/staging
Hi, On 09-06-17 11:58, Hans de Goede wrote: This commit adds the vboxvideo drm/kms driver for the virtual graphics card used in Virtual Box virtual machines to drivers/staging. Why drivers/staging? This driver is already being patched into the kernel by several distros, thus it is good to get this driver upstream soon, so that work on the driver can be easily shared. At the same time we want to take our time to get this driver properly cleaned up before submitting it as a normal driver under drivers/gpu/drm, putting this driver in staging for now allows both. Note this driver has already been significantly cleaned up, when I started working on this the files under /usr/src/vboxguest/vboxvideo as installed by Virtual Box 5.1.18 Guest Additions had a total linecount of 52681 lines. The version in this commit has 7275 lines. Of those 7275 lines 3980 lines are in an osindependent directory which contains portable code which is shared with other guest platforms such as C-structure definitions for the virtual graphics card protocol and helper functions for using these structures to communicate with the card. Since these files are shared they are in the standard Virtual Box upstream code style and not in the kernel coding style. All files outside of the osindependent directory fully adhere to the kernel coding style. Cc: vbox-...@virtualbox.org Cc: Michael Thayer Signed-off-by: Hans de Goede --- .config|1 + I just noticed that a .config changes have managed to get added to this patch, sorry. Greg, lt me know if you want a new version if you can fix this up locally. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Slower 3D with kernel 4.11.x
Hi > On Sat, 3 Jun 2017 01:53:04 +, "Bridgman, John" > wrote: > > OK, no powerplay messages that time. Was performance back to what you > > expected ? > Yes, performance on 4.10.12 is what i call normal So is this a known problem? or should i start the bisect? Thanks higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946 pgp4juGWYRK0V.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Use vsnprintf extension %ph
On Wed, May 31, 2017 at 2:35 AM, Joe Perches wrote: > Using the extension saves a bit of code. > + seq_printf(m, "faux/mst: %*ph\n", 2, buf); > + seq_printf(m, "mst ctrl: %*ph\n", 1, buf); > + seq_printf(m, "branch oui: %*phN devid: ", 3, buf); All above may use shorter form, i.e. "..., "%Xph", buf);", where X is a constant written explicitly inplace. > + seq_printf(m, " revision: hw: %x.%x sw: %x.%x\n", > + buf[0x9] >> 4, buf[0x9] & 0xf, buf[0xa], buf[0xb]); Matter of taste, though buf[9], buf[10], buf[11] looks better to me :-) -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: vboxvideo: Add vboxvideo to drivers/staging
On Sat, Jun 10, 2017 at 03:07:14PM +0200, Hans de Goede wrote: > Hi, > > On 09-06-17 11:58, Hans de Goede wrote: > > This commit adds the vboxvideo drm/kms driver for the virtual graphics > > card used in Virtual Box virtual machines to drivers/staging. > > > > Why drivers/staging? This driver is already being patched into the kernel > > by several distros, thus it is good to get this driver upstream soon, so > > that work on the driver can be easily shared. > > > > At the same time we want to take our time to get this driver properly > > cleaned up before submitting it as a normal driver under drivers/gpu/drm, > > putting this driver in staging for now allows both. > > > > Note this driver has already been significantly cleaned up, when I started > > working on this the files under /usr/src/vboxguest/vboxvideo as installed > > by Virtual Box 5.1.18 Guest Additions had a total linecount of 52681 > > lines. The version in this commit has 7275 lines. > > > > Of those 7275 lines 3980 lines are in an osindependent directory which > > contains portable code which is shared with other guest platforms such as > > C-structure definitions for the virtual graphics card protocol and helper > > functions for using these structures to communicate with the card. Since > > these files are shared they are in the standard Virtual Box upstream code > > style and not in the kernel coding style. All files outside of the > > osindependent directory fully adhere to the kernel coding style. > > > > Cc: vbox-...@virtualbox.org > > Cc: Michael Thayer > > Signed-off-by: Hans de Goede > > --- > > .config|1 + > > I just noticed that a .config changes have managed > to get added to this patch, sorry. > > Greg, lt me know if you want a new version if you can fix this > up locally. New version please! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #155 from j...@dev1ce.com --- Running a gigabyte AMD R9 380 card and getting similar problems. the system boots, loads the driver and the fans briefly spin to 100% before the video goes completely dark and the monitor turns off. the card is detected as a Tonga PRO 285/380. this issue is going to become much more critical in the next week, as SteamOS just switched their AMD proprietary drivers for amdgpu open source drivers. -- 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 101368] Nouveau regression GT218M in Kernel 4.11 Won't Boot
https://bugs.freedesktop.org/show_bug.cgi?id=101368 --- Comment #2 from Ben Steel --- Thanks for the prompt response. nouveau.modeset=0 allows it to successfully boot all the way into the GUI. In successful 4.10 kernel boots, nouveau console messages are present. In unsuccessful 4.11 boots with console logging, the console messages would stop and the screen would experience bad scrolling (redraw problems) at unpredictable points in the list but never mentioning nouveau. I know that it didn't complete booting without the screen because the ssh daemon never came up, dashing my hopes for better logging. -- 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: [RFC 0/1] drm: Add Grain Media GM12U320 kms driver
Hi,
On 10-06-17 19:14, Marco Diego Aurélio Mesquita wrote:
Hi Devs!
On Fri, Jun 9, 2017 at 7:31 PM, Noralf Trønnes wrote:
Den 09.06.2017 22.59, skrev Marco Diego Aurélio Mesquita:
Hi Devs!
On Thu, Jun 8, 2017 at 4:08 AM, Hans de Goede wrote:
I don't think that using cma for the gm12u320 is a good idea, it will
typically be used as a secondary GPU output together with a real GPU
extending the desktop by being a prime display output. So for the memory
management stuff I would keep the code copied from the udl driver (which
we may later split out in a separate helper lib for devices where
the framebuffer is in normal system memory and we have some
scather-gather
capable process copying it to the real device over e.g. USB)
I got the PL111 driver and stripped all device specific code. Also, I
added the get_modes and driver usb probe functions from gm12u320. The
resulting code is available in
https://gitlab.com/marcodiego/dummy-display-driver .
The driver compiles, loads, identifies the device when I plug it,
/dev/fb1 is created adequately but it stops there. Gnome monitors tool
does not see it as a new monitor. What I expected was that it would be
seen as a new monitor and that I could even activate it. Instead,
syslog complains: "Cannot find any crtc or sizes".
Anyway, I think this is a first step. My first doubt: where should I
go from now? What should I change in the driver so that gnome monitors
tool sees it as a new monitor and I could activate it, even if it
works as a mere dummy device?
Second doubt is: is this really the simplest/best way? I mean, the
repaper driver that Emil pointed seems a lot simpler, wouldn't it be
better to mimic it? How complicated is it to modify the repaper driver
to build a dummy driver?
By dummy driver, I mean something that gnome monitors tools can
identify as a new monitor and I can activate it. I hope to reach a
point where the update or dirty callback is called. From that point on
it is just a matter of sending the framebuffer through USB the way
gm12u320 does currently.
I guess you have forgotten to replace connector detect, because I
didn't see you use drm_panel in your RFC.
(gm12u320_connector->panel is NULL afaict, so it's always disconnected)
static enum drm_connector_status gm12u320_connector_detect(struct
drm_connector
*connector, bool force)
{
-struct gm12u320_drm_connector *gm12u320_connector =
-to_gm12u320_connector(connector);
-
-return (gm12u320_connector->panel ?
-connector_status_connected :
-connector_status_disconnected);
+if (drm_device_is_unplugged(connector->dev))
+return connector_status_disconnected;
+
+return connector_status_connected;
}
I applied this change and now gnome monitors tool identifies it as
another monitor, thanks Noralf! There are still some problems: when I
activate it, gnome complains "could not set configuration for CRTC
284". I still don't know what causes this. Any idea?
Other problem I get is that the device is spontaneously disconnected
after some time. I'm not sure what causes this, but I think it happens
because it receives no data after an amount of time.
Correct, there is no way to blank (think DPMS off) the device, but
it will turn itself of it does not get any data for more then x seconds,
I don't remember what X was.
On the udl-based
driver, a workqueue is used to periodically send some data to the
device. Is there any problem using the same approach here? I mean,
won't using a workqueue to periodically send some data to the device
bring any conflict? If not, I'll start porting the code related to the
workqueue from the udl-based driver to the pl111-based driver.
Yes that is the right thing to do, notice that the workqueue is not
just there to fix the timeout issue, the workqueue is there to send a
full copy of the framebuffer (partial updates are not supported, but
USB-3 is fast enough to not worry about this) to the device, it will
this whenever it gets woken because either userspace gives us a new
framebuffer (flip) or userspace has marked some area dirty marking.
If the workqueue is not woken it will resend the last framebuffer after
a timeout to avoid the device turning off, but its primary use is
sending the framebuffer when updated.
That will probably improve the behavior of the device. Once I get it
behaving properly, my next step will be to finally try to update the
framebuffer of the device and get it to show something.
Does this approach seem sound?
This sounds good to me.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 195321] nouveau?/DRI3?: dual monitors unusable without running compton --paint-on-overlay
https://bugzilla.kernel.org/show_bug.cgi?id=195321 --- Comment #6 from Jimi (jimijames.b...@gmail.com) --- Well, that's some obscure yet vital information. Why does this site even have the option to report bugs in a category that nobody pays attention to, rather than directing a potential bug reporter to the right place? And before you say that nouveau would've pointed me to the right spot, keep in mind I have no reason yet to suspect this is even a bug with nouveau (though it is a possibility), and have a lot of reason to suspect it's a bug with the kernel, since upgrading and downgrading my kernel changes its behavior. Here's the new bug report in the proper place: https://bugs.freedesktop.org/show_bug.cgi?id=101372 -- 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 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #12 from Jimi (jimijames.b...@gmail.com) --- Turns out this bug has been getting ignored because of an extremely obscure fact about terrible bug report website organization, that I'm sure has screwed many other people in the past: https://bugzilla.kernel.org/show_bug.cgi?id=195321#c5 Thankfully, someone else posted it in the right place recently: https://bugs.freedesktop.org/show_bug.cgi?id=100399 Let's add our voices to that. -- 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 100399] Kernel invalid opcode on unbinding amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=100399 --- Comment #1 from jimijames.b...@gmail.com --- Me and many other people have been having this issue as well, and I only recently learned that freedesktop.org, NOT kernel.org, is the proper place to report it. Here's my bug report that's been getting ignored for almost a year and hopefully has extra information: https://bugzilla.kernel.org/show_bug.cgi?id=150731 -- 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 101368] Nouveau regression GT218M in Kernel 4.11 Won't Boot
https://bugs.freedesktop.org/show_bug.cgi?id=101368 --- Comment #3 from Ilia Mirkin --- OK, so after booting with nouveau.modeset=0, rmmod nouveau, and reinsert it without that option. As your system should be fully up, you should get the relevant info of what fails. -- 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/panel: st7789v: Add a dependency on the backlight framework
On Tue, May 30, 2017 at 11:01:36PM +0200, Maxime Ripard wrote: > The driver depends on the backlight functions, but we have no dependency > on it in Kconfig. Add this dependency to avoid breakages. > > Signed-off-by: Maxime Ripard Ping? 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
Re: [PATCH] drm: Use vsnprintf extension %ph
On Sat, 2017-06-10 at 19:12 +0300, Andy Shevchenko wrote: > On Wed, May 31, 2017 at 2:35 AM, Joe Perches wrote: > > Using the extension saves a bit of code. > > + seq_printf(m, "faux/mst: %*ph\n", 2, buf); > > + seq_printf(m, "mst ctrl: %*ph\n", 1, buf); > > + seq_printf(m, "branch oui: %*phN devid: ", 3, buf); > > All above may use shorter form, i.e. > "..., "%Xph", buf);", where X is a constant written explicitly inplace. I know. Consistency is better though. Note the use of DP_RECEIVER_CAP_SIZE, etc... ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/44] xen-swiotlb: consolidate xen_swiotlb_dma_ops
On Thu, Jun 08, 2017 at 03:25:32PM +0200, Christoph Hellwig wrote: > ARM and x86 had duplicated versions of the dma_ops structure, the > only difference is that x86 hasn't wired up the set_dma_mask, > mmap, and get_sgtable ops yet. On x86 all of them are identical > to the generic version, so they aren't needed but harmless. > > All the symbols used only for xen_swiotlb_dma_ops can now be marked > static as well. > > Signed-off-by: Christoph Hellwig > --- > arch/arm/xen/mm.c | 17 > arch/x86/xen/pci-swiotlb-xen.c | 14 --- > drivers/xen/swiotlb-xen.c | 93 > ++ > include/xen/swiotlb-xen.h | 62 +--- > 4 files changed, 49 insertions(+), 137 deletions(-) Yeeey! Reviewed-by: Konrad Rzeszutek Wilk ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/44] xen-swiotlb: implement ->mapping_error
On Thu, Jun 08, 2017 at 03:25:33PM +0200, Christoph Hellwig wrote: > DMA_ERROR_CODE is going to go away, so don't rely on it. Reviewed-by: Konrad Rzeszutek Wilk ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101377] Gigabyte R9 380 card fails to load, kernel reports bug
https://bugs.freedesktop.org/show_bug.cgi?id=101377 Bug ID: 101377 Summary: Gigabyte R9 380 card fails to load, kernel reports bug Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: j...@dev1ce.com Created attachment 131871 --> https://bugs.freedesktop.org/attachment.cgi?id=131871&action=edit dmesg output of load attempt loading the card as a module fails. fans spin up for 2 seconds, then back down, then blank screen. system is online but without video. see 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 v3 2/6] dt-bindings: display: Add Synopsys DW MIPI DSI DRM bridge driver
On 6/9/2017 6:31 PM, Rob Herring wrote: On Fri, Jun 09, 2017 at 10:43:07AM +0100, Jose Abreu wrote: Hello, On 09-06-2017 05:11, Archit Taneja wrote: Hi Philippe, Rob, On 06/08/2017 09:10 PM, Rob Herring wrote: Seems strange there's not also a pixel or bit clock? Or this gets driven from the phy? Since you mention phy here, I wanted to share a concern with the bindings. These bindings don't have a separate PHY DT node. The PHY is assumed as a part of the IP when integrated by a SoC. There are already rockchip and hisil DSI bindings that use this IP but don't define a PHY node. It's a similar situation with the DW-HDMI bindings. For example, when the DW HDMI is integrated in rockchip or renesas SoC, the bindings "rockchip,rk3288-dw-hdmi" or "renesas,r8a7795-dw-hdmi" are used, and they don't have a separate PHY DT node. I wasn't sure whether this is the right way to proceed or not for such IPs. Some advice would help us here. Thanks, Archit I just want to add that read/writes from/to phy are done using the controller (in HDMI and in MIPI DSI Host), so the only way to have a phy driver is that if some custom callbacks are provided or if the memory region is shared. Anyway, I agree with Archit in the sense that phy + controller are highly tied. Also, these two "pieces" are SoC specific and sometimes very different between SoC's because they can be customized so I think a different compatible string suits well here. When the phy is integrated like this, I agree that it doesn't make sense to have a separate phy node. Great. Thanks for the clarification Jose and Rob. Archit -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: dw-hdmi: Fix compilation breakage by selecting REGMAP_MMIO
On 6/10/2017 2:29 PM, Laurent Pinchart wrote:
The dw-hdmi driver switched to regmap-mmio, but lacks the dependency in
Kconfig. This can result in compilation breakages. Fix it by selecting
REGMAP_MMIO.
Fixes: 80e2f97968b5 ("drm: bridge: dw-hdmi: Switch to regmap for register
access")
Reported-by: kbuild test robot
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/synopsys/Kconfig | 1 +
1 file changed, 1 insertion(+)
Archit,
This is a v4.12 regression fix. While not super critical, it would be
nice if it could get merged in v4.12.
Sean,
Would you be fine with another drm-misc-fixes pull req? It looks like
we have a drm_of_find_panel_or_bridge() usage on imx which needs fixing
too. If so, I can queue this to drm-misc-fixes.
Thanks,
Archit
diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 40d2827a6d19..53e78d092d18 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -1,6 +1,7 @@
config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
+ select REGMAP_MMIO
config DRM_DW_HDMI_AHB_AUDIO
tristate "Synopsys Designware AHB Audio interface"
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
