[PATCH] drm/gma500: dont expose bytes from kernel stack
DOT_MAX},
69 .m = {.min = MRST_M_MIN_100, .max = MRST_M_MAX_100},
70 .p1 = {.min = MRST_P1_MIN, .max = MRST_P1_MAX_1},
71 .find_pll = mrst_lvds_find_best_pll,
72 },
73 { /* MRST_LIMIT_SDVO */
74 .vco = {.min = 140, .max = 280},
75 .n = {.min = 3, .max = 7},
76 .m = {.min = 80, .max = 137},
77 .p1 = {.min = 1, .max = 2},
78 .p2 = {.dot_limit = 20, .p2_slow = 10, .p2_fast = 10},
79 .find_pll = mrst_sdvo_find_best_pll,
80 },
81 };
82
83 #define MRST_M_MIN 10
84 static const u32 oaktrail_m_converts[] = {
85 0x2B, 0x15, 0x2A, 0x35, 0x1A, 0x0D, 0x26, 0x33, 0x19, 0x2C,
86 0x36, 0x3B, 0x1D, 0x2E, 0x37, 0x1B, 0x2D, 0x16, 0x0B, 0x25,
87 0x12, 0x09, 0x24, 0x32, 0x39, 0x1c,
88 };
89
90 static const struct gma_limit_t *mrst_limit(struct drm_crtc *crtc,
91 int refclk)
92 {
93 const struct gma_limit_t *limit = NULL;
94 struct drm_device *dev = crtc->dev;
95 struct drm_psb_private *dev_priv = dev->dev_private;
96
97 if (gma_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)
98 || gma_pipe_has_type(crtc, INTEL_OUTPUT_MIPI)) {
99 switch (dev_priv->core_freq) {
100 case 100:
101 limit = &mrst_limits[MRST_LIMIT_LVDS_100L];
102 break;
103 case 166:
104 limit = &mrst_limits[MRST_LIMIT_LVDS_83];
105 break;
106 case 200:
107 limit = &mrst_limits[MRST_LIMIT_LVDS_100];
108 break;
109 }
110 } else if (gma_pipe_has_type(crtc, INTEL_OUTPUT_SDVO)) {
111 limit = &mrst_limits[MRST_LIMIT_SDVO];
112 } else {
113 limit = NULL;
114 dev_err(dev->dev, "mrst_limit Wrong display type.\n");
115 }
116
117 return limit;
118 }
119
120 /** Derive the pixel clock for the given refclk and divisors for 8xx
chips. */
121 static void mrst_lvds_clock(int refclk, struct gma_clock_t *clock)
122 {
123 clock->dot = (refclk * clock->m) / (14 * clock->p1);
124 }
125
126 static void mrst_print_pll(struct gma_clock_t *clock)
127 {
128 DRM_DEBUG_DRIVER("dotclock=%d, m=%d, m1=%d, m2=%d, n=%d,
p1=%d, p2=%d\n",
129 clock->dot, clock->m, clock->m1, clock->m2,
clock->n,
130 clock->p1, clock->p2);
131 }
132
133 static bool mrst_sdvo_find_best_pll(const struct gma_limit_t *limit,
134 struct drm_crtc *crtc, int target,
135 int refclk, struct gma_clock_t
*best_clock)
136 {
137 struct gma_clock_t clock;
138 u32 target_vco, actual_freq;
139 s32 freq_error, min_error = 10;
140
> 141 memset(clock, 0, sizeof(struct gma_clock_t));
142 memset(best_clock, 0, sizeof(*best_clock));
143
144 for (clock.m = limit->m.min; clock.m <= limit->m.max;
clock.m++) {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 25540 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/83b2e6ee/attachment-0001.obj>
[RFC 0/2] New feature: Framebuffer processors
On 22 August 2016 at 19:44, Marek Szyprowski wrote: > Dear all, > > This is the initial proposal for extending DRM API with generic support for > hardware modules, which can be used for processing image data from the one > memory buffer to another. Typical memory-to-memory operations are: > rotation, scaling, colour space conversion or mix of them. In this proposal > I named such hardware modules a framebuffer processors. > > Embedded SoCs are known to have a number of hardware blocks, which perform > such operations. They can be used in paralel to the main GPU module to > offload CPU from processing grapics or video data. One of example use of > such modules is implementing video overlay, which usually requires color > space conversion from NV12 (or similar) to RGB32 color space and scaling to > target window size. > > Till now there was no generic, hardware independent API for performing such > operations. Exynos DRM driver has its own custom extension called IPP > (Image Post Processing), but frankly speaking, it is over-engineered and not > really used in open-source. I didn't indentify similar API in other DRM > drivers, besides those which expose complete support for the whole GPU. So I'm with the others in that it's a road we've travelled and learned from, generic accel API don't work very well long term. What will happen is the next generation exynos will have a command queue for it's dma engine or whatever and someone will shoehorn that into this API because this API exists, even if it isn't suitable. What are the requirements for having this API, what userspace feature is driving it, compositors?, toolkit rendering? Dave.
[PATCH v3 1/5] drm/rockchip: sort registers define by chip's number
On 2016å¹´08æ23æ¥ 04:30, Sean Paul wrote: > On Thu, Aug 18, 2016 at 6:02 AM, Mark yao wrote: >> On 2016å¹´08æ18æ¥ 17:11, Daniel Vetter wrote: >>> On Thu, Aug 18, 2016 at 05:08:14PM +0800, Mark yao wrote: > Hi Sean > > Thanks for send v3 patch for rk3399 vop support. > > But sorry for that, I had changed my mind, those patches are deprecated, > I have new rk3399 patch on my downstream kernel, I will upstream soon. >>> Wut? Imo merge Sean's patch here, and then rebase your downstream patches >>> on top of it. That you have a downstream tree which is out of sync with >>> upstream shouldn't be a reason to stall upstream development. >>> -Daniel >>> >> Yeah, Sorry for that. >> >> In fact, on my downstream kernel, also have those patches, my new rk3399 >> patches are based on them, >> but the new rk3399 patches will cover the those patches, Sean's patches is >> old version. >> >> I just want to fast forward, don't want to send two version drivers to >> upstream. >> but if you and Dave feel ok for that, I have no problem:-) . >> >> merged Sean's patches and then apply new version patches. >> > Ok, so can I get a review/ack for these revised patches then? > Something is better than nothing, and there's a bunch of stuff that > depends on these changes. > > Sean Yes, But I miss your [PATCH v3 0/5] and [PATCH v3 4/5]. do you mean the lost patches use v2 version? > > >> Thanks. >> >> -- >> ï¼ark Yao >> >> > > -- ï¼ark Yao
[Bug 95306] Random Blank(black) screens on "Carrizo"
https://bugs.freedesktop.org/show_bug.cgi?id=95306 --- Comment #8 from Michel Dänzer --- (In reply to Tom from comment #7) > Kernel: 4.7.1 > Glib2: 2.49.5.11.gb82682e-1 > Problem: Screen blanked once after 2 hours but turned back on after > switching to console and back to X. After 10 minutes it blanked for good. > > Kernel: 4.7.2 > Glib2: 2.49.5.11.gb82682e-1 > Problem: Ran for 1h 30m without any issue. Blanked after suspending for 15 > minutes and resuming. Please attach the corresponding Xorg log file. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/06614d2b/attachment.html>
Mullins support in xf86-video-amdgpu
On 23/08/16 10:18 AM, Reid Hekman wrote: > > I was encouraged by a commit I saw today to add Sea Islands PCI ids to > xf86-video-amdgpu. However I did not see MULLINS included. Are there > other showstoppers preventing inclusion? I assume the commit you're referring to was the one adding the *Southern* Islands (SI) PCI IDs. Since Mullins is Sea Islands (CIK), it should already be supported by the amdgpu kernel driver; its omission from xf86-video-amdgpu is probably just an oversight. Can you send a patch to the amd-gfx mailing list? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
linux-next: build failure after merge of the drm-intel tree
Hi all,
After merging the drm-intel tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from drivers/gpio/gpiolib-of.c:19:0:
include/linux/io-mapping.h:115:31: fatal error: asm/pgtable_types.h: No such
file or directory
In file included from drivers/gpu/drm/nouveau/include/nvif/os.h:16:0,
from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3,
from drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3,
from drivers/gpu/drm/nouveau/include/nvkm/core/client.h:3,
from drivers/gpu/drm/nouveau/nvkm/core/client.c:24:
include/linux/io-mapping.h:115:31: fatal error: asm/pgtable_types.h: No such
file or directory
and many more.
Caused by commit
cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about the
io-mapping")
I have used the drm-intel tree from next-20160822 for today.
--
Cheers,
Stephen Rothwell
[PATCH] Re: Mullins support in xf86-video-amdgpu
On 23/08/16 11:57 AM, Reid Hekman wrote: > On 08/22/2016 08:27 PM, Michel Dänzer wrote: >> On 23/08/16 10:18 AM, Reid Hekman wrote: >>> >>> I was encouraged by a commit I saw today to add Sea Islands PCI ids to >>> xf86-video-amdgpu. However I did not see MULLINS included. Are there >>> other showstoppers preventing inclusion? >> >> I assume the commit you're referring to was the one adding the >> *Southern* Islands (SI) PCI IDs. Since Mullins is Sea Islands (CIK), it >> should already be supported by the amdgpu kernel driver; its omission >> from xf86-video-amdgpu is probably just an oversight. Can you send a >> patch to the amd-gfx mailing list? >> > > Michael, oops, yes, sorry, apparently my head was on the wrong AMD > islands. Admittedly I'm a total newb at this, but David's script makes > this seem fairly simple. Does the following look correct? It looks good, but it fails to apply for me for some reason. How did you generate the patch? Ideally, generate a patch (with a proper commit log) with git format-patch and send it with git send-email. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH] Re: Mullins support in xf86-video-amdgpu
On Mon, Aug 22, 2016 at 10:57 PM, Reid Hekman wrote:
> On 08/22/2016 08:27 PM, Michel Dänzer wrote:
>>
>> On 23/08/16 10:18 AM, Reid Hekman wrote:
>>>
>>>
>>> I was encouraged by a commit I saw today to add Sea Islands PCI ids to
>>> xf86-video-amdgpu. However I did not see MULLINS included. Are there
>>> other showstoppers preventing inclusion?
>>
>>
>> I assume the commit you're referring to was the one adding the
>> *Southern* Islands (SI) PCI IDs. Since Mullins is Sea Islands (CIK), it
>> should already be supported by the amdgpu kernel driver; its omission
>> from xf86-video-amdgpu is probably just an oversight. Can you send a
>> patch to the amd-gfx mailing list?
>>
>
> Michael, oops, yes, sorry, apparently my head was on the wrong AMD islands.
> Admittedly I'm a total newb at this, but David's script makes this seem
> fairly simple. Does the following look correct?
>
> Regards,
> Reid
>
> ---
> diff -aur a/src/amdgpu_chipinfo_gen.h b/src/amdgpu_chipinfo_gen.h
> --- a/src/amdgpu_chipinfo_gen.h 2016-08-22 21:25:49.101755291 -0500
> +++ b/src/amdgpu_chipinfo_gen.h 2016-08-22 21:41:26.758967344 -0500
> @@ -100,6 +100,22 @@
> { 0x983D, CHIP_FAMILY_KABINI },
> { 0x983E, CHIP_FAMILY_KABINI },
> { 0x983F, CHIP_FAMILY_KABINI },
> + { 0x9850, CHIP_FAMILY_MULLINS },
> + { 0x9851, CHIP_FAMILY_MULLINS },
> + { 0x9852, CHIP_FAMILY_MULLINS },
> + { 0x9853, CHIP_FAMILY_MULLINS },
> + { 0x9854, CHIP_FAMILY_MULLINS },
> + { 0x9855, CHIP_FAMILY_MULLINS },
> + { 0x9856, CHIP_FAMILY_MULLINS },
> + { 0x9857, CHIP_FAMILY_MULLINS },
> + { 0x9858, CHIP_FAMILY_MULLINS },
> + { 0x9859, CHIP_FAMILY_MULLINS },
> + { 0x985a, CHIP_FAMILY_MULLINS },
> + { 0x985b, CHIP_FAMILY_MULLINS },
> + { 0x985c, CHIP_FAMILY_MULLINS },
> + { 0x985d, CHIP_FAMILY_MULLINS },
> + { 0x985e, CHIP_FAMILY_MULLINS },
> + { 0x985f, CHIP_FAMILY_MULLINS },
> { 0x1304, CHIP_FAMILY_KAVERI },
> { 0x1305, CHIP_FAMILY_KAVERI },
> { 0x1306, CHIP_FAMILY_KAVERI },
> diff -aur a/src/amdgpu_chipset_gen.h b/src/amdgpu_chipset_gen.h
> --- a/src/amdgpu_chipset_gen.h 2016-08-22 21:25:49.101755291 -0500
> +++ b/src/amdgpu_chipset_gen.h 2016-08-22 21:41:26.758967344 -0500
> @@ -100,6 +100,22 @@
>{ PCI_CHIP_KABINI_983D, "KABINI" },
>{ PCI_CHIP_KABINI_983E, "KABINI" },
>{ PCI_CHIP_KABINI_983F, "KABINI" },
> + { PCI_CHIP_MULLINS 9850, "MULLINS" },
> + { PCI_CHIP_MULLINS 9851, "MULLINS" },
> + { PCI_CHIP_MULLINS 9852, "MULLINS" },
> + { PCI_CHIP_MULLINS 9853, "MULLINS" },
> + { PCI_CHIP_MULLINS 9854, "MULLINS" },
> + { PCI_CHIP_MULLINS 9855, "MULLINS" },
> + { PCI_CHIP_MULLINS 9856, "MULLINS" },
> + { PCI_CHIP_MULLINS 9857, "MULLINS" },
> + { PCI_CHIP_MULLINS 9858, "MULLINS" },
> + { PCI_CHIP_MULLINS 9859, "MULLINS" },
> + { PCI_CHIP_MULLINS 985a, "MULLINS" },
> + { PCI_CHIP_MULLINS 985b, "MULLINS" },
> + { PCI_CHIP_MULLINS 985c, "MULLINS" },
> + { PCI_CHIP_MULLINS 985d, "MULLINS" },
> + { PCI_CHIP_MULLINS 985e, "MULLINS" },
> + { PCI_CHIP_MULLINS 985f, "MULLINS" },
>{ PCI_CHIP_KAVERI_1304, "KAVERI" },
>{ PCI_CHIP_KAVERI_1305, "KAVERI" },
>{ PCI_CHIP_KAVERI_1306, "KAVERI" },
> diff -aur a/src/amdgpu_pci_chipset_gen.h b/src/amdgpu_pci_chipset_gen.h
> --- a/src/amdgpu_pci_chipset_gen.h 2016-08-22 21:25:49.104755254 -0500
> +++ b/src/amdgpu_pci_chipset_gen.h 2016-08-22 21:41:26.758967344 -0500
> @@ -100,6 +100,22 @@
> { PCI_CHIP_KABINI_983D, PCI_CHIP_KABINI_983D, RES_SHARED_VGA },
> { PCI_CHIP_KABINI_983E, PCI_CHIP_KABINI_983E, RES_SHARED_VGA },
> { PCI_CHIP_KABINI_983F, PCI_CHIP_KABINI_983F, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9850, PCI_CHIP_MULLINS 9850, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9851, PCI_CHIP_MULLINS 9851, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9852, PCI_CHIP_MULLINS 9852, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9853, PCI_CHIP_MULLINS 9853, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9854, PCI_CHIP_MULLINS 9854, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9855, PCI_CHIP_MULLINS 9855, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9856, PCI_CHIP_MULLINS 9856, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9857, PCI_CHIP_MULLINS 9857, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9858, PCI_CHIP_MULLINS 9858, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9859, PCI_CHIP_MULLINS 9859, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 985a, PCI_CHIP_MULLINS 985a, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 985b, PCI_CHIP_MULLINS 985b, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 985c, PCI_CHIP_MULLINS 985c, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 985d, PCI_CHIP_MULLINS 985d, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 985e, PCI_CHIP_MULLINS 985e, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 985f, PCI_CHIP_MULLINS 985f, RES_SHARED_VGA },
> { PCI_CHIP_KAVERI_1304, PCI_CHIP_KAVERI_1304, RES_SHARED_VGA },
> { PCI_CHIP_KAVERI_1305, PCI_CHIP_KAVERI_1305, RES_SHARED_VGA },
> { PCI_CHIP_KAVERI_1306, PCI_CHIP_KAVERI_1306, RES_SHARED_VGA },
> diff -aur a/src/amdgpu_pci_device_match_gen.h
> b/src/amdgpu_pci_device_match_gen.h
> --- a/src/a
[PATCH v2] drm/udl: Ensure channel is selected before using the device.
On Mon, Aug 22, 2016 at 11:17:34PM +0100, Jamie Lentin wrote:
> Lift configuration command from udlfb. This appears to be essential for
> at least a Rextron VCUD-60, without which no URB communication occurs.
>
> Signed-off-by: Jamie Lentin
> ---
> udl_encoder_commit() is too late to do this set up in it seems. This
> setup doesn't need to be performed again after a suspend, although this
> is somewhat academic until I send the patch adding suspend and resume
> functions.
>
> Tested with a Rextron VCUD-60 attached to a Thinkpad X201s on Linux 4.7.0
Applied to drm-misc, thanks.
-Daniel
>
> Cheers,
> ---
> drivers/gpu/drm/udl/udl_main.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
> index 33dbfb2..29f0207 100644
> --- a/drivers/gpu/drm/udl/udl_main.c
> +++ b/drivers/gpu/drm/udl/udl_main.c
> @@ -16,6 +16,8 @@
> /* -BULK_SIZE as per usb-skeleton. Can we get full page and avoid overhead?
> */
> #define BULK_SIZE 512
>
> +#define NR_USB_REQUEST_CHANNEL 0x12
> +
> #define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE)
> #define WRITES_IN_FLIGHT (4)
> #define MAX_VENDOR_DESCRIPTOR_SIZE 256
> @@ -90,6 +92,26 @@ success:
> return true;
> }
>
> +/*
> + * Need to ensure a channel is selected before submitting URBs
> + */
> +static int udl_select_std_channel(struct udl_device *udl)
> +{
> + int ret;
> + u8 set_def_chn[] = {0x57, 0xCD, 0xDC, 0xA7,
> + 0x1C, 0x88, 0x5E, 0x15,
> + 0x60, 0xFE, 0xC6, 0x97,
> + 0x16, 0x3D, 0x47, 0xF2};
> +
> + ret = usb_control_msg(udl->udev,
> + usb_sndctrlpipe(udl->udev, 0),
> + NR_USB_REQUEST_CHANNEL,
> + (USB_DIR_OUT | USB_TYPE_VENDOR), 0, 0,
> + set_def_chn, sizeof(set_def_chn),
> + USB_CTRL_SET_TIMEOUT);
> + return ret < 0 ? ret : 0;
> +}
> +
> static void udl_release_urb_work(struct work_struct *work)
> {
> struct urb_node *unode = container_of(work, struct urb_node,
> @@ -301,6 +323,9 @@ int udl_driver_load(struct drm_device *dev, unsigned long
> flags)
> goto err;
> }
>
> + if (udl_select_std_channel(udl))
> + DRM_ERROR("Selecting channel failed\n");
> +
> if (!udl_alloc_urb_list(dev, WRITES_IN_FLIGHT, MAX_TRANSFER)) {
> DRM_ERROR("udl_alloc_urb_list failed\n");
> goto err;
> --
> 2.8.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts
On Mon, Aug 22, 2016 at 12:49:30PM -0300, Mauro Carvalho Chehab wrote: > Em Mon, 22 Aug 2016 20:41:45 +0530 > Sumit Semwal escreveu: > > > Include dma-buf sphinx documentation into top level index. > > > > Signed-off-by: Sumit Semwal > > --- > > Documentation/index.rst | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Documentation/index.rst b/Documentation/index.rst > > index e0fc72963e87..8d05070122c2 100644 > > --- a/Documentation/index.rst > > +++ b/Documentation/index.rst > > @@ -14,6 +14,8 @@ Contents: > > :maxdepth: 2 > > > > kernel-documentation > > + dma-buf/intro > > + dma-buf/guide > > media/media_uapi > > media/media_kapi > > media/dvb-drivers/index > > IMHO, the best would be, instead, to add an index with a toctree > with both intro and guide, and add dma-buf/index instead. > > We did that for media too (patches not merged upstream yet), together > with a patchset that will allow building just a subset of the books. I'm also not too sure about whether dma-buf really should be it's own subdirectory. It's plucked from the device-drivers.tmpl, I think an overall device-drivers/ for all the misc subsystems and support code would be better. Then one toc there, which fans out to either kernel-doc and overview docs. -Daniel > > Regards, > Mauro > > PS.: That's the content of our index.rst file, at > Documentation/media/index.rst: > > Linux Media Subsystem Documentation > === > > Contents: > > .. toctree:: >:maxdepth: 2 > >media_uapi >media_kapi >dvb-drivers/index >v4l-drivers/index > > .. only:: subproject > >Indices >=== > >* :ref:`genindex` > > > Thanks, > Mauro > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 2/2] drm/msm: protect against faults from copy_from_user() in submit ioctl
On Mon, Aug 22, 2016 at 03:38:05PM -0400, Rob Clark wrote:
> An evil userspace could try to cause deadlock by passing an unfaulted-in
> GEM bo as submit->bos (or submit->cmds) table. Which will trigger
> msm_gem_fault() while we already hold struct_mutex. See:
>
> https://github.com/freedreno/msmtest/blob/master/evilsubmittest.c
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.h| 6 ++
> drivers/gpu/drm/msm/msm_gem.c| 9 +
> drivers/gpu/drm/msm/msm_gem_submit.c | 3 +++
> 3 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index a35c1b6..957801e 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -157,6 +157,12 @@ struct msm_drm_private {
> struct shrinker shrinker;
>
> struct msm_vblank_ctrl vblank_ctrl;
> +
> + /* task holding struct_mutex.. currently only used in submit path
> + * to detect and reject faults from copy_from_user() for submit
> + * ioctl.
> + */
> + struct task_struct *struct_mutex_task;
> };
>
> struct msm_format {
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 8dfdeec..f6b8945 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -196,11 +196,20 @@ int msm_gem_fault(struct vm_area_struct *vma, struct
> vm_fault *vmf)
> {
> struct drm_gem_object *obj = vma->vm_private_data;
> struct drm_device *dev = obj->dev;
> + struct msm_drm_private *priv = dev->dev_private;
> struct page **pages;
> unsigned long pfn;
> pgoff_t pgoff;
> int ret;
>
> + /* This should only happen if userspace tries to pass a mmap'd
> + * but unfaulted gem bo vaddr into submit ioctl, triggering
> + * a page fault while struct_mutex is already held. This is
> + * not a valid use-case so just bail.
> + */
> + if (priv->struct_mutex_task == current)
READ_ONCE here I think. Otherwise should at least work, though I still
think it's sloppy ;-)
-Daniel
> + return VM_FAULT_SIGBUS;
> +
> /* Make sure we don't parallel update on a fault, nor move or remove
>* something from beneath our feet
>*/
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 03d4ce2..0be57a9 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -426,6 +426,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> if (ret)
> return ret;
>
> + priv->struct_mutex_task = current;
> +
> if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
> if (out_fence_fd < 0) {
> @@ -549,6 +551,7 @@ out:
> out_unlock:
> if (ret && (out_fence_fd >= 0))
> put_unused_fd(out_fence_fd);
> + priv->struct_mutex_task = NULL;
> mutex_unlock(&dev->struct_mutex);
> return ret;
> }
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v4 2/5] drm/fb-helper: Add drm_fb_helper_set_suspend_lock()
On Mon, Aug 22, 2016 at 10:25:22PM +0200, Noralf Trønnes wrote:
> This adds a function that also takes the console lock before calling
> fb_set_suspend() in contrast to drm_fb_helper_set_suspend() which is
> a plain wrapper around fb_set_suspend().
> Resume is run asynchronously using a worker if the console lock is
> already taken. This is modelled after the i915 driver.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_helper.c | 57
> +
> include/drm/drm_fb_helper.h | 9 +++
> 2 files changed, 66 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index ce54e98..897e6f4 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -29,6 +29,7 @@
> */
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> +#include
> #include
> #include
> #include
> @@ -618,6 +619,16 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper
> *helper)
> kfree(helper->crtc_info);
> }
>
> +static void drm_fb_helper_resume_worker(struct work_struct *work)
> +{
> + struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
> + resume_work);
> +
> + console_lock();
> + fb_set_suspend(helper->fbdev, 0);
> + console_unlock();
> +}
> +
> static void drm_fb_helper_dirty_work(struct work_struct *work)
> {
> struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
> @@ -649,6 +660,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct
> drm_fb_helper *helper,
> {
> INIT_LIST_HEAD(&helper->kernel_fb_list);
> spin_lock_init(&helper->dirty_lock);
> + INIT_WORK(&helper->resume_work, drm_fb_helper_resume_worker);
> INIT_WORK(&helper->dirty_work, drm_fb_helper_dirty_work);
> helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
> helper->funcs = funcs;
> @@ -1035,6 +1047,51 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper
> *fb_helper, int state)
> }
> EXPORT_SYMBOL(drm_fb_helper_set_suspend);
>
> +/**
> + * drm_fb_helper_set_suspend_lock - wrapper around fb_set_suspend that also
> + * takes the console lock
> + * @fb_helper: driver-allocated fbdev helper
> + * @state: desired state, zero to resume, non-zero to suspend
> + *
> + * A wrapper around fb_set_suspend() that takes the console lock. If the lock
> + * isn't available on resume, a worker is tasked with waiting for the lock
> + * to become available. The console lock can be pretty contented on resume
> + * due to all the printk activity.
> + *
> + * This function can be called multiple times with the same state since
> + * &fb_info->state is checked to see if fbdev is running or not before
> locking.
> + *
> + * Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
> + */
> +void drm_fb_helper_set_suspend_lock(struct drm_fb_helper *fb_helper, int
> state)
We generally call the functions which take the locks themselves _unlocked
(or the version that requires locks to be held _locked). Other nit: I
think added a sentence to the kerneldoc of drm_fb_helper_set_suspend to
instead use this one (since it avoids lock contention on resume) would be
good.
Otherwise looks great.
And if you're bored, following up with a bunch of patches to roll this out
to drivers would be awesome ;-)
> +{
> + if (!fb_helper || !fb_helper->fbdev)
> + return;
> +
> + /* make sure there's no pending/ongoing resume */
> + flush_work(&fb_helper->resume_work);
> +
> + if (state) { /* suspend */
Hm, one more nit: rename state to suspend and you both make the
declaration more self-explanatory, and can drop these 2 comments here.
Thanks, Daniel
> + if (fb_helper->fbdev->state != FBINFO_STATE_RUNNING)
> + return;
> +
> + console_lock();
> +
> + } else { /* resume */
> + if (fb_helper->fbdev->state == FBINFO_STATE_RUNNING)
> + return;
> +
> + if (!console_trylock()) {
> + schedule_work(&fb_helper->resume_work);
> + return;
> + }
> + }
> +
> + fb_set_suspend(fb_helper->fbdev, state);
> + console_unlock();
> +}
> +EXPORT_SYMBOL(drm_fb_helper_set_suspend_lock);
> +
> static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
>u16 blue, u16 regno, struct fb_info *info)
> {
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index db8d478..db7e861 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -176,6 +176,7 @@ struct drm_fb_helper_connector {
> * the screen buffer
> * @dirty_lock: spinlock protecting @dirty_clip
> * @dirty_work: worker used to flush the framebuffer
> + * @resume_work: worker used during resume if the console lock is already
> taken
> *
> * This i
[PATCH v4 4/5] drm: simpledrm: add fbdev fallback support
On Mon, Aug 22, 2016 at 10:25:24PM +0200, Noralf Trønnes wrote:
> Create a simple fbdev device during SimpleDRM setup so legacy user-space
> and fbcon can use it.
>
> Original work by David Herrmann.
>
> Cc: dh.herrmann at gmail.com
> Signed-off-by: Noralf Trønnes
> ---
>
> Changes from version 3:
> - Remove #ifdef CONFIG_DRM_FBDEV_EMULATION
> - Use drm_fb_helper_set_suspend_lock()
> - Don't access the native framebuffer directly, but do blitting here as well.
> - Use the drm_fb_helper_sys_*() functions instead of the cfb versions.
> - Remove FBINFO_CAN_FORCE_OUTPUT flag which doesn't work now.
> - Pass struct drm_fb_helper around instead of struct sdrm_fbdev.
>
> Changes from version 2:
> - Switch to using drm_fb_helper in preparation for future panic handling
> which needs an enabled pipeline.
>
> Changes from version 1:
> No changes
>
> Changes from previous version:
> - Remove the DRM_SIMPLEDRM_FBDEV kconfig option and use DRM_FBDEV_EMULATION
> - Suspend fbcon/fbdev when the pipeline is enabled, resume in lastclose
> - Add FBINFO_CAN_FORCE_OUTPUT flag so we get oops'es on the console
>
> drivers/gpu/drm/simpledrm/Kconfig | 3 +
> drivers/gpu/drm/simpledrm/Makefile | 2 +-
> drivers/gpu/drm/simpledrm/simpledrm.h | 5 +
> drivers/gpu/drm/simpledrm/simpledrm_drv.c | 4 +
> drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 201
>
> drivers/gpu/drm/simpledrm/simpledrm_kms.c | 14 ++
> 6 files changed, 228 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>
> diff --git a/drivers/gpu/drm/simpledrm/Kconfig
> b/drivers/gpu/drm/simpledrm/Kconfig
> index f45b25d..3257590 100644
> --- a/drivers/gpu/drm/simpledrm/Kconfig
> +++ b/drivers/gpu/drm/simpledrm/Kconfig
> @@ -13,6 +13,9 @@ config DRM_SIMPLEDRM
> SimpleDRM supports "simple-framebuffer" DeviceTree objects and
> compatible platform framebuffers.
>
> + If fbdev support is enabled, this driver will also provide an fbdev
> + compatibility layer that supports fbcon, mmap is not supported.
> +
> If unsure, say Y.
>
> To compile this driver as a module, choose M here: the
> diff --git a/drivers/gpu/drm/simpledrm/Makefile
> b/drivers/gpu/drm/simpledrm/Makefile
> index f6a62dc..5474f7f 100644
> --- a/drivers/gpu/drm/simpledrm/Makefile
> +++ b/drivers/gpu/drm/simpledrm/Makefile
> @@ -1,4 +1,4 @@
> simpledrm-y := simpledrm_drv.o simpledrm_kms.o simpledrm_gem.o \
> - simpledrm_damage.o
> + simpledrm_damage.o simpledrm_fbdev.o
>
> obj-$(CONFIG_DRM_SIMPLEDRM) := simpledrm.o
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm.h
> b/drivers/gpu/drm/simpledrm/simpledrm.h
> index 0739581..d4eb52c 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm.h
> +++ b/drivers/gpu/drm/simpledrm/simpledrm.h
> @@ -16,6 +16,7 @@
> #include
>
> struct simplefb_format;
> +struct drm_fb_helper;
> struct regulator;
> struct clk;
>
> @@ -23,6 +24,7 @@ struct sdrm_device {
> struct drm_device *ddev;
> struct drm_simple_display_pipe pipe;
> struct drm_connector conn;
> + struct drm_fb_helper *fb_helper;
>
> /* framebuffer information */
> const struct simplefb_format *fb_sformat;
> @@ -42,6 +44,7 @@ struct sdrm_device {
> struct regulator **regulators;
> };
>
> +void sdrm_lastclose(struct drm_device *ddev);
> int sdrm_drm_modeset_init(struct sdrm_device *sdrm);
>
> int sdrm_dirty(struct drm_framebuffer *fb,
> @@ -82,5 +85,7 @@ struct sdrm_framebuffer {
> int sdrm_fb_init(struct drm_device *ddev, struct sdrm_framebuffer *fb,
>const struct drm_mode_fb_cmd2 *mode_cmd,
>struct sdrm_gem_object *obj);
> +void sdrm_fbdev_init(struct sdrm_device *sdrm);
> +void sdrm_fbdev_cleanup(struct sdrm_device *sdrm);
>
> #endif /* SDRM_DRV_H */
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> b/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> index 17c1b55..fe752c6 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> +++ b/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> @@ -47,6 +47,7 @@ static const struct vm_operations_struct sdrm_gem_vm_ops = {
> static struct drm_driver sdrm_drm_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = &sdrm_drm_fops,
> + .lastclose = sdrm_lastclose,
>
> .gem_free_object = sdrm_gem_free_object,
> .gem_vm_ops = &sdrm_gem_vm_ops,
> @@ -451,6 +452,8 @@ static int sdrm_simplefb_probe(struct platform_device
> *pdev)
> if (ret)
> goto err_regulators;
>
> + sdrm_fbdev_init(sdrm);
> +
> DRM_INFO("Initialized %s on minor %d\n", ddev->driver->name,
>ddev->primary->index);
>
> @@ -476,6 +479,7 @@ static int sdrm_simplefb_remove(struct platform_device
> *pdev)
> struct drm_device *ddev = platform_get_drvdata(pdev);
> struct sdrm_device *sdrm = ddev->dev_private;
>
> + sd
[PATCH v4 3/5] drm: add SimpleDRM driver
On Mon, Aug 22, 2016 at 10:25:23PM +0200, Noralf Trønnes wrote:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
>
> Userspace can create dumb-buffers which can be blit into the real
> framebuffer similar to UDL. No access to the real framebuffer is allowed
> (compared to earlier version of this driver) to avoid security issues.
> Furthermore, this way we can support arbitrary modes as long as we have a
> conversion-helper.
>
> The driver was originally written by David Herrmann in 2014.
> My main contribution is to make use of drm_simple_kms_helper and
> rework the probe path to avoid use of the deprecated drm_platform_init()
> and drm_driver.{load,unload}().
> Additions have also been made for later changes to the Device Tree binding
> document, like support for clocks, regulators and having the node under
> /chosen. This code was lifted verbatim from simplefb.c.
>
> Cc: dh.herrmann at gmail.com
> Cc: libv at skynet.be
> Signed-off-by: Noralf Trønnes
> ---
>
> Changes from version 3:
> - Reworked gem code to match udl
> - Dropped PRIME support
> - Dropped dirty_info_property, it's gone
> - Don't use drm_device.platformdev it's deprecated
> - Remove struct sdrm_device #ifdef's
> - Split out sdrm_fb_init() from sdrm_fb_create(), needed by fbdev code
> - Simplify drm_clip validation by extending the check in
> sdrm_dirty() and drop the one in sdrm_blit()
> - Removed sdrm_dirty_all_unlocked() which was unused.
>
> Changes from version 2:
> - Remove superfluos module.h includes
> - Move includes from header to source files
> - Set plane.fb before flushing in pipe update, or else the previous one
> gets flushed
> - Added check for vblank event in sdrm_display_pipe_update()
>
> Changes from version 1:
> - Move platform_set_drvdata() before drm_dev_register()
> - Remove drm_legacy_mmap() call.
> - Set mode_config.{min,max}_{width,height} to the actual dimensions
> of the native framebuffer
> - Remove plane positioning since it won't work with the simple display pipe,
> meaning sdrm_display_pipe_check() isn't necessary either
> - Support the additions to the Device Tree binding document, including
> clocks, regulators and having the node under /chosen
>
> Changes from previous version:
> - Remove FB_SIMPLE=n dependency to avoid kconfig recursive error
> - Changed module name to match kconfig help text: sdrm -> simpledrm
> - Use drm_simple_display_pipe
> - Replace deprecated drm_platform_init()
> - sdrm_dumb_create(): drm_gem_object_unreference() -> *_unlocked()
> - sdrm_dumb_map_offset(): drm_gem_object_lookup() remove drm_device parameter
> - sdrm_drm_mmap() changes:
> Remove struct_mutex locking
> Add drm_vma_offset_{lock,unlock}_lookup()
> drm_mmap() -> drm_legacy_mmap()
> - dma_buf_begin_cpu_access() doesn't require start and length anymore
> - Use drm_cvt_mode() instead of open coding a mode
> - Fix format conversion. In the intermediate step, store the 8/6/5 bit color
> value in the upper part of the 16-bit color variable, not the lower.
> - Support clips == NULL in sdrm_dirty()
> - Set mode_config.preferred_depth
> - Attach mode_config.dirty_info_property to connector
>
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/simpledrm/Kconfig| 19 +
> drivers/gpu/drm/simpledrm/Makefile | 4 +
> drivers/gpu/drm/simpledrm/simpledrm.h| 86 +
> drivers/gpu/drm/simpledrm/simpledrm_damage.c | 235
> drivers/gpu/drm/simpledrm/simpledrm_drv.c| 543
> +++
> drivers/gpu/drm/simpledrm/simpledrm_gem.c| 202 ++
> drivers/gpu/drm/simpledrm/simpledrm_kms.c| 234
> 9 files changed, 1326 insertions(+)
> create mode 100644 drivers/gpu/drm/simpledrm/Kconfig
> create mode 100644 drivers/gpu/drm/simpledrm/Makefile
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_damage.c
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_gem.c
> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_kms.c
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index fc35731..a54cc8d 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -290,3 +290,5 @@ source "drivers/gpu/drm/arc/Kconfig"
> source "drivers/gpu/drm/hisilicon/Kconfig"
>
> source "drivers/gpu/drm/mediatek/Kconfig"
> +
> +source "drivers/gpu/drm/simpledrm/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index e3dba6f..eba32ad 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -83,3 +83,4 @@ obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
> obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
> obj-$(CONFIG_DRM_ARCPGU)+= arc/
> obj-y
[PATCH] drm/simple-helpers: Always add planes to the state update
Our update function is hooked to the single plane, which might not get
called for crtc-only updates. Which is surprising, so fix this by
always adding the plane.
While at it document how&when the event should be sent out better in
the kerneldoc.
Cc: Noralf Trønnes
Cc: andrea.merello at gmail.com
Tested-and-Reported-by: andrea.merello at gmail.com
Signed-off-by: Daniel Vetter
---
I'm not entirely sure we really want to put the responsibility for
this onto driver. Plan B) would be to remove the kerneldoc I added
here and call the right function from drm_simple_kms_plane_atomic_update.
That way simple drivers don't need to deal with that detail, and in
general those drivers don't care that much about the miniscule
possible race a generic implementation would cause. What do you
suggest as the best approach?
-Daniel
---
drivers/gpu/drm/drm_simple_kms_helper.c | 7 +++
include/drm/drm_simple_kms_helper.h | 6 ++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index bada17166512..447631018426 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -34,6 +34,12 @@ static const struct drm_encoder_funcs
drm_simple_kms_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
+static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+ return drm_atomic_add_affected_planes(state->state, crtc);
+}
+
static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
{
struct drm_simple_display_pipe *pipe;
@@ -57,6 +63,7 @@ static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc)
}
static const struct drm_crtc_helper_funcs drm_simple_kms_crtc_helper_funcs = {
+ .atomic_check = drm_simple_kms_crtc_check,
.disable = drm_simple_kms_crtc_disable,
.enable = drm_simple_kms_crtc_enable,
};
diff --git a/include/drm/drm_simple_kms_helper.h
b/include/drm/drm_simple_kms_helper.h
index 269039722f91..826946ca2b82 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -60,6 +60,12 @@ struct drm_simple_display_pipe_funcs {
*
* This function is called when the underlying plane state is updated.
* This hook is optional.
+*
+* This is the function drivers should submit the
+* &drm_pending_vblank_event from. Using either
+* drm_crtc_arm_vblank_event(), when the driver supports vblank
+* interrupt handling, or drm_crtc_send_vblank_event() directly in case
+* the hardware lacks vblank support entirely.
*/
void (*update)(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state);
--
2.8.1
[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code
Hi Russell,
On 08/12/2016 04:15 PM, Russell King wrote:
> Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC
> implementation.
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/bridge/Kconfig| 7 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/dw-hdmi-cec.c | 344
> ++
> drivers/gpu/drm/bridge/dw-hdmi.c | 64 +-
> include/linux/platform_data/dw_hdmi-cec.h | 16 ++
> 5 files changed, 421 insertions(+), 11 deletions(-)
> create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-cec.c
> create mode 100644 include/linux/platform_data/dw_hdmi-cec.h
>
> +static unsigned int parse_hdmi_addr(const struct edid *edid)
> +{
> + if (!edid || edid->extensions == 0)
> + return (u16)~0;
> +
> + return cec_get_edid_phys_addr((u8 *)edid,
> + EDID_LENGTH * (edid->extensions + 1), NULL);
> +}
> +
> +static int dw_hdmi_cec_notify(struct notifier_block *nb, unsigned long event,
> + void *data)
> +{
> + struct dw_hdmi_cec *cec = container_of(nb, struct dw_hdmi_cec, nb);
> + union hdmi_event *event_block = data;
> + unsigned int phys;
> +
> + dev_info(event_block->base.source, "event %lu\n", event);
> +
> + if (event_block->base.source != cec->adap->devnode.parent)
> + return NOTIFY_OK;
> +
> + switch (event) {
> + case HDMI_CONNECTED:
> + break;
> +
> + case HDMI_DISCONNECTED:
> + cec_s_phys_addr(cec->adap, CEC_PHYS_ADDR_INVALID, false);
> + break;
> +
> + case HDMI_NEW_EDID:
> + phys = parse_hdmi_addr(event_block->edid.edid);
> + cec_s_phys_addr(cec->adap, phys, false);
> + break;
> + }
> +
> + return NOTIFY_OK;
> +}
Wouldn't it make a lot of sense to integrate this into the cec framework?
All you need is to pass an hdmi_notifier_dev as argument to
cec_allocate_adapter()
and you can integrate this.
If you are OK with that, then I can make patches for that.
Regards,
Hans
[Bug 97428] Specific OpenGL applications deadlock on AMD GPU drivers
https://bugs.freedesktop.org/show_bug.cgi?id=97428 Vitaly Ostrosablin changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Vitaly Ostrosablin --- Yes, that worked, many thanks! Looks like this was Steam's bug rather than driver's failure. *** This bug has been marked as a duplicate of bug 97174 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/f9e22309/attachment.html>
[Bug 97174] Assault Android Cactus freezing on Mesa 12
https://bugs.freedesktop.org/show_bug.cgi?id=97174 Vitaly Ostrosablin changed: What|Removed |Added CC||tmp6154 at yandex.ru --- Comment #11 from Vitaly Ostrosablin --- *** Bug 97428 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/e86fab02/attachment.html>
[urgent] drm/fb-helper: Fix the dummy remove_conflicting_framebuffers
On Mon, Aug 22, 2016 at 09:44:52PM +0100, Chris Wilson wrote:
> We always need to remove conflicting framebuffers if any other fb driver
> is enabled, and not just if we are setting up an fbdev ourselves.
>
> Unfortunately remove_conflicting_framebuffers() was incorrectly stubbed
> out if !fbdev rather than !fb leading to major memory corruption (and
> corrupt filesystems) upon boot.
>
> Fixes: 44adece57e26 ("drm/fb-helper: Add a dummy
> remove_conflicting_framebuffers")
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Tobias Jakobi
> Cc: Noralf Trønnes
> Cc: tomi.valkeinen at ti.com
> Cc: dh.herrmann at gmail.com
> Cc: Alex Deucher
It's only in -misc, so not super urgent. Applied, thanks.
-Daniel
> ---
> include/drm/drm_fb_helper.h | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 97889a90ff23..f811d755c254 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -282,12 +282,6 @@ drm_pick_cmdline_mode(struct drm_fb_helper_connector
> *fb_helper_conn,
> int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
> drm_connector *connector);
> int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
> struct drm_connector *connector);
> -static inline int
> -drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> - const char *name, bool primary)
> -{
> - return remove_conflicting_framebuffers(a, name, primary);
> -}
> #else
> static inline int drm_fb_helper_modinit(void)
> {
> @@ -482,11 +476,17 @@ drm_fb_helper_remove_one_connector(struct drm_fb_helper
> *fb_helper,
> return 0;
> }
>
> +#endif
> +
> static inline int
> drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> const char *name, bool primary)
> {
> +#if IS_ENABLED(CONFIG_FB)
> + return remove_conflicting_framebuffers(a, name, primary);
> +#else
> return 0;
> -}
> #endif
> +}
> +
> #endif
> --
> 2.9.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v6 6/8] Documentation: bindings: add dt documentation for rk3399 dmc
Hi Lin,
On 2016ë
08ì 22ì¼ 07:16, hl wrote:
> Hi Chanwoo Choi,
>
> On 2016å¹´08æ17æ¥ 12:50, Chanwoo Choi wrote:
>> Hi Lin,
>>
>> On 2016ë
08ì 17ì¼ 07:36, Lin Huang wrote:
>>> This patch adds the documentation for rockchip rk3399 dmc driver.
>>>
>>> Signed-off-by: Lin Huang
>>> ---
>>> Changes in v6:
>>> -Add more detail in Documentation
>>>
>>> Changes in v5:
>>> -None
>>>
>>> Changes in v4:
>>> -None
>>>
>>> Changes in v3:
>>> -None
>>>
>>> Changes in v2:
>>> -None
>>>
>>> Changes in v1:
>>> -None
>>> .../devicetree/bindings/devfreq/rk3399_dmc.txt | 84
>>> ++
>>> 1 file changed, 84 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
>>> b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
>>> new file mode 100644
>>> index 000..e73067c
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
>>> @@ -0,0 +1,84 @@
>>> +* Rockchip rk3399 DMC(Dynamic Memory Controller) device
>>> +
>>> +Required properties:
>>> +- compatible: Must be "rockchip,rk3399-dmc".
>>> +- devfreq-events: Node to get ddr loading, Refer to
>>> + Documentation/devicetree/bindings/devfreq/rockchip-dif.txt
>>> +- interrupts: The interrupt number to the cpu. The interrupt specifier
>>> format
>>> + depends on the interrupt controller. it should be dcf interrupts,
>>> + when ddr dvfs finish, it will happen.
>> If possible, you better to keep the indentation with other properties.
>> s/it->It, dcf->DCF, ddr->DDR
>>
>>
>>> +- clocks: Phandles for clock specified in "clock-names" property
>>> +- clock-names : The name of clock used by the DFI, must be "pclk_ddr_mon";
>>> +- operating-points-v2: Refer to
>>> Documentation/devicetree/bindings/power/opp.txt
>>> + for details.
>> ditto.
>>
>>> +- center-supply: Dmc supply node.
>> s/Dmc/DMC becaue DMC an abbreviation.
>>
>>> +- status: Marks the node enabled/disabled.
>>> +
>>> +Optional properties:
>>> +- ddr_timing: ddr timing need to pass to arm trust firmware
>>> +- upthreshold: the upthreshold to simpleondeamnd policy
>>> +- downdifferential: The downdifferential to simpleondeamnd policy
>>> +
>>> +Example:
>>> +ddr_timing: ddr_timing {
>>> +compatible = "rockchip,ddr-timing";
>> I can't find the 'rockchip,ddr-timing' driver on linux-next git repo
>> (20160816).
>> If ddr_timing includes the only properties for ddr_timing,
>> I recommend you make the separate a .dtsi file including
>> the ddr timing configuration. I add the reference and an example on below.
>>
>>> +ddr3_speed_bin = <21>;
>>> +pd_idle = <0>;
>>> +sr_idle = <0>;
>>> +sr_mc_gate_idle = <0>;
>>> +srpd_lite_idle= <0>;
>>> +standby_idle = <0>;
>>> +dram_dll_dis_freq = <300>;
>>> +phy_dll_dis_freq = <125>;
>>> +
>>> +ddr3_odt_dis_freq = <333>;
>>> +ddr3_drv = ;
>>> +ddr3_odt = ;
>>> +phy_ddr3_ca_drv = ;
>>> +phy_ddr3_dq_drv = ;
>>> +phy_ddr3_odt = ;
>>> +
>>> +lpddr3_odt_dis_freq = <333>;
>>> +lpddr3_drv = ;
>>> +lpddr3_odt = ;
>>> +phy_lpddr3_ca_drv = ;
>>> +phy_lpddr3_dq_drv = ;
>>> +phy_lpddr3_odt = ;
>>> +
>>> +lpddr4_odt_dis_freq = <333>;
>>> +lpddr4_drv = ;
>>> +lpddr4_dq_odt = ;
>>> +lpddr4_ca_odt = ;
>>> +phy_lpddr4_ca_drv = ;
>>> +phy_lpddr4_ck_cs_drv = ;
>>> +phy_lpddr4_dq_drv = ;
>>> +phy_lpddr4_odt = ;
>>> +};
>>> +
>>> +dmc_opp_table: dmc_opp_table {
>>> +compatible = "operating-points-v2";
>>> +
>>> +opp00 {
>>> +opp-hz = /bits/ 64 <3>;
>>> +opp-microvolt = <90>;
>>> +};
>>> +opp01 {
>>> +opp-hz = /bits/ 64 <66600>;
>>> +opp-microvolt = <90>;
>>> +};
>>> +};
>>> +
>>> +dmc: dmc {
>>> +compatible = "rockchip,rk3399-dmc";
>>> +devfreq-events = <&dfi>;
>>> +interrupts = ;
>>> +clocks = <&cru SCLK_DDRCLK>;
>>> +clock-names = "dmc_clk";
>>> +ddr_timing = <&ddr_timing>;
>> You can use the following '#include' instead of 'ddr_timing'
>> because the ddr_timing is not a device driver. Instead,
>> the rk3399-dmc must need the ddr timing configuration.
>>
>> #include "rk3399-dmc-timing-conf.dtsi"
>>
>> You can refer the similar usage case[1].
>> The *.conf.dtsi is used on exynos3250 tmu dt node[2].
>>
>> [1] arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
>> [2] arch/arm/boot/dts/exynos3250.dtsi, 224 line.
>>
>>> +operating-points-v2 = <&dmc_opp_table>;
>>> +center-supply = <&ppvar_centerlogic>;
>>> +upthreshold = <15>;
>>> +downdifferential = <10>;
>>> +status = "disabled";
>>> +};
>>> +
>>>
>> For example,
>> I think that
[PATCH v7 6/8] Documentation: bindings: add dt documentation for rk3399 dmc
Hi Lin,
I reply the on v6 patch[1].
If you have another opinion, please let me know.
If my suggestion is not reasonable, we need to discuss it.
[1] https://lkml.org/lkml/2016/8/23/28
Best Regards,
Chanwoo Choi
On 2016ë
08ì 22ì¼ 12:36, Lin Huang wrote:
> This patch adds the documentation for rockchip rk3399 dmc driver.
>
> Signed-off-by: Lin Huang
> ---
> Changes in v7:
> -None
>
> Changes in v6:
> -Add more detail in Documentation
>
> Changes in v5:
> -None
>
> Changes in v4:
> -None
>
> Changes in v3:
> -None
>
> Changes in v2:
> -None
>
> Changes in v1:
> -None
> .../devicetree/bindings/devfreq/rk3399_dmc.txt | 85
> ++
> 1 file changed, 85 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
>
> diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> new file mode 100644
> index 000..b787abb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> @@ -0,0 +1,85 @@
> +* Rockchip rk3399 DMC(Dynamic Memory Controller) device
> +
> +Required properties:
> +- compatible: Must be "rockchip,rk3399-dmc".
> +- devfreq-events: Node to get DDR loading, Refer to
> + Documentation/devicetree/bindings/devfreq/rockchip-dfi.txt
> +- interrupts: The interrupt number to the CPU. The interrupt specifier format
> + depends on the interrupt controller. It should be DCF interrupts,
> + when DDR dvfs finish, it will happen.
> +- clocks: Phandles for clock specified in "clock-names" property
> +- clock-names : The name of clock used by the DFI, must be "pclk_ddr_mon";
> +- operating-points-v2: Refer to
> Documentation/devicetree/bindings/power/opp.txt
> +for details.
> +- center-supply: DMC supply node.
> +- status: Marks the node enabled/disabled.
> +
> +Optional properties:
> +- ddr_timing: DDR timing need to pass to arm trust firmware
> +- upthreshold: The upthreshold to simpleondeamnd policy
> +- downdifferential: The downdifferential to simpleondeamnd policy
> +
> +Example:
> +
> + ddr_timing: ddr_timing {
> + compatible = "rockchip,ddr-timing";
> + ddr3_speed_bin = <21>;
> + pd_idle = <0>;
> + sr_idle = <0>;
> + sr_mc_gate_idle = <0>;
> + srpd_lite_idle = <0>;
> + standby_idle = <0>;
> + dram_dll_dis_freq = <300>;
> + phy_dll_dis_freq = <125>;
> +
> + ddr3_odt_dis_freq = <333>;
> + ddr3_drv = ;
> + ddr3_odt = ;
> + phy_ddr3_ca_drv = ;
> + phy_ddr3_dq_drv = ;
> + phy_ddr3_odt = ;
> +
> + lpddr3_odt_dis_freq = <333>;
> + lpddr3_drv = ;
> + lpddr3_odt = ;
> + phy_lpddr3_ca_drv = ;
> + phy_lpddr3_dq_drv = ;
> + phy_lpddr3_odt = ;
> +
> + lpddr4_odt_dis_freq = <333>;
> + lpddr4_drv = ;
> + lpddr4_dq_odt = ;
> + lpddr4_ca_odt = ;
> + phy_lpddr4_ca_drv = ;
> + phy_lpddr4_ck_cs_drv = ;
> + phy_lpddr4_dq_drv = ;
> + phy_lpddr4_odt = ;
> + };
> +
> + dmc_opp_table: dmc_opp_table {
> + compatible = "operating-points-v2";
> +
> + opp00 {
> + opp-hz = /bits/ 64 <3>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <66600>;
> + opp-microvolt = <90>;
> + };
> + };
> +
> + dmc: dmc {
> + compatible = "rockchip,rk3399-dmc";
> + devfreq-events = <&dfi>;
> + interrupts = ;
> + clocks = <&cru SCLK_DDRCLK>;
> + clock-names = "dmc_clk";
> + ddr_timing = <&ddr_timing>;
> + operating-points-v2 = <&dmc_opp_table>;
> + center-supply = <&ppvar_centerlogic>;
> + upthreshold = <15>;
> + downdifferential = <10>;
> + status = "disabled";
> + };
> +
>
[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code
On Tue, Aug 23, 2016 at 09:21:17AM +0200, Hans Verkuil wrote:
> Hi Russell,
>
> On 08/12/2016 04:15 PM, Russell King wrote:
> > Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC
> > implementation.
> >
> > Signed-off-by: Russell King
> > ---
> > drivers/gpu/drm/bridge/Kconfig| 7 +
> > drivers/gpu/drm/bridge/Makefile | 1 +
> > drivers/gpu/drm/bridge/dw-hdmi-cec.c | 344
> > ++
> > drivers/gpu/drm/bridge/dw-hdmi.c | 64 +-
> > include/linux/platform_data/dw_hdmi-cec.h | 16 ++
> > 5 files changed, 421 insertions(+), 11 deletions(-)
> > create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-cec.c
> > create mode 100644 include/linux/platform_data/dw_hdmi-cec.h
> >
>
>
>
> > +static unsigned int parse_hdmi_addr(const struct edid *edid)
> > +{
> > + if (!edid || edid->extensions == 0)
> > + return (u16)~0;
> > +
> > + return cec_get_edid_phys_addr((u8 *)edid,
> > + EDID_LENGTH * (edid->extensions + 1), NULL);
> > +}
> > +
> > +static int dw_hdmi_cec_notify(struct notifier_block *nb, unsigned long
> > event,
> > + void *data)
> > +{
> > + struct dw_hdmi_cec *cec = container_of(nb, struct dw_hdmi_cec, nb);
> > + union hdmi_event *event_block = data;
> > + unsigned int phys;
> > +
> > + dev_info(event_block->base.source, "event %lu\n", event);
> > +
> > + if (event_block->base.source != cec->adap->devnode.parent)
> > + return NOTIFY_OK;
> > +
> > + switch (event) {
> > + case HDMI_CONNECTED:
> > + break;
> > +
> > + case HDMI_DISCONNECTED:
> > + cec_s_phys_addr(cec->adap, CEC_PHYS_ADDR_INVALID, false);
> > + break;
> > +
> > + case HDMI_NEW_EDID:
> > + phys = parse_hdmi_addr(event_block->edid.edid);
> > + cec_s_phys_addr(cec->adap, phys, false);
> > + break;
> > + }
> > +
> > + return NOTIFY_OK;
> > +}
>
> Wouldn't it make a lot of sense to integrate this into the cec framework?
>
> All you need is to pass an hdmi_notifier_dev as argument to
> cec_allocate_adapter()
> and you can integrate this.
>
> If you are OK with that, then I can make patches for that.
It's not just about CEC. It's also used for passing information between
the video and audio parts, so tying this into CEC is wrong.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[PATCH v7 4/8] Documentation: bindings: add dt documentation for dfi controller
Hi Lin,
On 2016ë
08ì 22ì¼ 12:36, Lin Huang wrote:
> This patch adds the documentation for rockchip dfi devfreq-event driver.
>
> Signed-off-by: Lin Huang
> ---
> Changes in v7:
> -None
>
> Changes in v6:
> -None
>
> Changes in v5:
> -None
>
> Changes in v4:
> -None
>
> Changes in v3:
> -None
>
> Changes in v2:
> -None
>
> Changes in v1:
> -None
> .../bindings/devfreq/event/rockchip-dfi.txt | 20
>
> 1 file changed, 20 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
>
> diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> new file mode 100644
> index 000..bf42255
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> @@ -0,0 +1,20 @@
> +
> +* Rockchip rk3399 DFI device
> +
> +Required properties:
> +- compatible: Must be "rockchip,rk3399-dfi".
> +- reg: physical base address of each DFI and length of memory mapped region
> +- rockchip,pmu: phandle to the syscon managing the "pmu general register
> files"
> +- clocks: phandles for clock specified in "clock-names" property
> +- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
> +
> +Example:
> + dfi: dfi at 0xff63 {
> + reg = <0x00 0xff63 0x00 0x4000>;
> + compatible = "rockchip,rk3399-dfi";
> + rockchip,pmu = <&pmugrf>;
> + clocks = <&cru PCLK_DDR_MON>;
> + clock-names = "pclk_ddr_mon";
> + status = "disabled";
> + };
> +
>
I reviewed this patch on previous version[1] already.
[1] https://lkml.org/lkml/2016/8/16/913
There are minor requirement. If you modify it,
I'll finish the review of this patch.
--
Best Regards,
Chanwoo Choi
[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code
Hi Russell, On 08/12/16 16:15, Russell King wrote: > + ret = devm_request_threaded_irq(&pdev->dev, cec->irq, > + dw_hdmi_cec_hardirq, > + dw_hdmi_cec_thread, IRQF_SHARED, > + DEV_NAME, cec->adap); > + if (ret < 0) > + return ret; > + > + ret = cec_register_adapter(cec->adap); > + if (ret < 0) > + return ret; > + > + /* > + * CEC documentation says we must not call cec_delete_adapter > + * after a successful call to cec_register_adapter(). > + */ > + devm_remove_action(&pdev->dev, dw_hdmi_cec_del, cec); > + > + hdmi_register_notifier(&cec->nb); The notifier is registered here, but who provides CEC with the initial physical address? As I understand it, it only tells you when things change, not what the initial state is. Regards, Hans
[PATCH] drm-misc: arm64 now also must be compile-tested before pushing
hisilicon unfortunately requires this since it's a warn-fest on 32bit builds. Cc: seanpaul at chromium.org Cc: sumit.semwal at linaro.org Cc: sumit.semwal at linaro.org Cc: architt at codeaurora.org Signed-off-by: Daniel Vetter --- drm-misc.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drm-misc.rst b/drm-misc.rst index 521be4aceceb..2f30e18d9095 100644 --- a/drm-misc.rst +++ b/drm-misc.rst @@ -26,8 +26,8 @@ Right now the only hard merge criteria are: in through separate pull requests. Those topic branches can still be maintained with the dim_ tooling, but that's of course entirely optional. -* All the x86 and arm DRM drivers need to still compile. To simplify this we - track defconfigs for both platforms in the `drm-intel-rerere` branch. +* All the x86, arm and arm64 DRM drivers need to still compile. To simplify this + we track defconfigs for all three platforms in the `drm-intel-rerere` branch. * The goal is to also pre-check everything with CI. Unfortunately neither the arm side (using kernelci.org and generic i-g-t tests) nor the Intel side -- 2.9.3
i865, drm_modeset_lock_all: BUG: unable to handle kernel NULL pointer dereference at 00000104
This on a P4 PC with 82865G chipset and onboard Intel graphics. 4.7.0 worked fine, current 4.8 git shows NULL pointer dereference as shown below at the end of dmesg. [0.00] Linux version 4.8.0-rc3-00013-gef0e1ea (mroos at vanalynx) (gcc version 5.4.0 20160609 (Debian 5.4.0-6) ) #34 Tue Aug 23 10:03:49 EEST 2016 [0.00] x86/fpu: Legacy x87 FPU detected. [0.00] x86/fpu: Using 'eager' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e6000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x7ef2fbff] usable [0.00] BIOS-e820: [mem 0x7ef2fc00-0x7ef2] ACPI NVS [0.00] BIOS-e820: [mem 0x7ef3-0x7ef3] ACPI data [0.00] BIOS-e820: [mem 0x7ef4-0x7efe] ACPI NVS [0.00] BIOS-e820: [mem 0x7eff-0x7eff] reserved [0.00] BIOS-e820: [mem 0xfecf-0xfecf0fff] reserved [0.00] BIOS-e820: [mem 0xfed2-0xfed9] reserved [0.00] debug: ignoring loglevel setting. [0.00] Notice: NX (Execute Disable) protection missing in CPU! [0.00] SMBIOS 2.3 present. [0.00] DMI: MicroLink /D865GLC , BIOS BF86510A.86A.0077.P25.0508040031 08/04/2005 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x7ef2f max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 disabled [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- UC [0.00] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [c00ff780] [0.00] initial memory mapped: [mem 0x-0x01ff] [0.00] Base memory trampoline at [c009b000] 9b000 size 16384 [0.00] BRK [0x01ad7000, 0x01ad7fff] PGTABLE [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F61E0 14 (v00 ACPIAM) [0.00] ACPI: RSDT 0x7EF3 38 (v01 INTEL D865GLC 20050804 MSFT 0097) [0.00] ACPI: FACP 0x7EF30200 81 (v02 INTEL D865GLC 20050804 MSFT 0097) [0.00] ACPI: DSDT 0x7EF30370 004305 (v01 INTEL D865GLC 0001 MSFT 010D) [0.00] ACPI: FACS 0x7EF4 40 [0.00] ACPI: APIC 0x7EF30300 68 (v01 INTEL D865GLC 20050804 MSFT 0097) [0.00] ACPI: ASF! 0x7EF34680 99 (v16 LEGEND I865PASF 0001 MSFT 010D) [0.00] ACPI: TCPA 0x7EF34719 34 (v01 INTEL TBLOEMID 0001 MSFT 0097) [0.00] ACPI: WDDT 0x7EF3474D 40 (v01 INTEL OEMWDDT 0001 MSFT 010D) [0.00] ACPI: Local APIC address 0xfee0 [0.00] 1143MB HIGHMEM available. [0.00] 887MB LOWMEM available. [0.00] mapped low ram: 0 - 377fe000 [0.00] low ram: 0 - 377fe000 [0.00] BRK [0x01ad8000, 0x01ad8fff] PGTABLE [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] Normal [mem 0x0100-0x377fdfff] [0.00] HighMem [mem 0x377fe000-0x7ef2efff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x0009efff] [0.00] node 0: [mem 0x0010-0x7ef2efff] [0.00] Initmem setup node 0 [mem 0x1000-0x7ef2efff] [0.00] On node 0 totalpages: 519885 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3998 pages, LIFO batch:0 [0.00] Normal zone: 1744 pages used for memmap [0.00] Normal zone: 223230 pages, LIFO batch:31 [0.00] HighMem zone: 292657 pages, LIFO batch:31 [0.00] Using APIC driver default [0.00] Reserving Intel graphics memory at 0x7f00-0x7fff [0.00] ACPI: PM-Timer IO Port: 0x408 [0.00] ACPI: Local APIC address 0xfee0 [0.00] APIC: NR_CPUS/possible_cpus limit of 1 reached. Processor 1/0x1 ignored. [0.0
i865, drm_modeset_lock_all: BUG: unable to handle kernel NULL pointer dereference at 00000104
On Tue, Aug 23, 2016 at 12:58:43PM +0300, Meelis Roos wrote: > This on a P4 PC with 82865G chipset and onboard Intel graphics. 4.7.0 > worked fine, current 4.8 git shows NULL pointer dereference as shown > below at the end of dmesg. > > [ 10.066261] BUG: unable to handle kernel NULL pointer dereference at > 0104 > [ 10.066273] IP: [] mutex_lock+0xa/0x15 > [ 10.066287] *pde = > [ 10.066295] Oops: 0002 [#1] > [ 10.066302] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper > syscopyarea sysfillrect sysimgblt fb_sys_fops drm iTCO_wdt > iTCO_vendor_support ppdev evdev snd_intel8x0 snd_ac97_codec ac97_bus psmouse > snd_pcm snd_timer snd pcspkr uhci_hcd ehci_pci soundcore sr_mod ehci_hcd > serio_raw i2c_i801 usbcore i2c_smbus cdrom lpc_ich mfd_core rng_core e100 mii > floppy parport_pc parport acpi_cpufreq button processor usb_common eeprom > lm85 hwmon_vid autofs4 > [ 10.066378] CPU: 0 PID: 132 Comm: systemd-udevd Not tainted > 4.8.0-rc3-00013-gef0e1ea #34 > [ 10.066389] Hardware name: MicroLink > /D865GLC, BIOS BF86510A.86A.0077.P25.0508040031 > 08/04/2005 > [ 10.066401] task: f62db800 task.stack: f597 > [ 10.066409] EIP: 0060:[] EFLAGS: 00010286 CPU: 0 > [ 10.066417] EIP is at mutex_lock+0xa/0x15 > [ 10.066424] EAX: 0104 EBX: 0104 ECX: EDX: 8000 > [ 10.066432] ESI: EDI: 0104 EBP: f5be8000 ESP: f5971b58 > [ 10.066439] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 > [ 10.066446] CR0: 80050033 CR2: 0104 CR3: 35945000 CR4: 06d0 > [ 10.066453] Stack: > [ 10.066459] f503d740 f824dddf f61170c0 f61170c0 f82371ae > f850f40e 0001 > [ 10.066476] f61170c0 f5971bcc f5be8000 f9c2d401 0001 f8236fcc > 0001 > [ 10.066491] f5144014 f5be8104 0008 f9c5267c 0007 f61170c0 > f5144400 f9c4ff00 > [ 10.066507] Call Trace: > [ 10.066526] [] ? drm_modeset_lock_all+0x27/0xb3 [drm] > [ 10.066545] [] ? drm_encoder_cleanup+0x1a/0x132 [drm] > [ 10.066559] [] ? drm_atomic_helper_connector_reset+0x3f/0x5c > [drm_kms_helper] > [ 10.066644] [] ? intel_dvo_init+0x569/0x788 [i915] Looks like an incorrect call to drm_encoder_cleanup() from the error path. If we hit the error path we have never called drm_encoder_init. Please try: diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c index 47bdf9dad0d3..b9e5a63a7c9e 100644 --- a/drivers/gpu/drm/i915/intel_dvo.c +++ b/drivers/gpu/drm/i915/intel_dvo.c @@ -554,7 +554,6 @@ void intel_dvo_init(struct drm_device *dev) return; } - drm_encoder_cleanup(&intel_encoder->base); kfree(intel_dvo); kfree(intel_connector); } -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm/doc: Add a few words on validation with IGT
Also provide some pointers for building IGT as some kernel hackers might not be that familiar with building stuff on Linux distros. Signed-off-by: Tomeu Vizoso Cc: Daniel Vetter --- Documentation/gpu/drm-uapi.rst | 37 + 1 file changed, 37 insertions(+) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 94876938aef3..5e425ab83dc1 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -112,3 +112,40 @@ interfaces. Especially since all hardware-acceleration interfaces to userspace are driver specific for efficiency and other reasons these interfaces can be rather substantial. Hence every driver has its own chapter. + +Validating changes with IGT +=== + +There's a collection of tests that aims to cover the whole functionality of +DRM drivers and that can be used to check that changes to DRM drivers or the +core don't regress existing functionality. This test suite is called IGT and +its code can be found in https://cgit.freedesktop.org/xorg/app/intel-gpu-tools. + +To build IGT, start by installing its build dependencies. In Debian-based +systems:: + + # apt-get build-dep intel-gpu-tools + +And in Fedora-based systems:: + + # dnf builddep intel-gpu-tools + +Then clone the repository:: + + $ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools + +Configure the build system and start the build:: + + $ cd intel-gpu-tools && ./autogen.sh && make -j6 + +Download the piglit dependency:: + + $ ./scripts/run-tests.sh -d + +And run the tests:: + + $ ./scripts/run-tests.sh -t kms -t core -s + +run-tests.sh is a wrapper around piglit that will execute the tests matching +the -t options. A report in HTML format will be available in +./results/html/index.html. Results can be compared with piglit. -- 2.7.4
[RFC 0/2] New feature: Framebuffer processors
Hi, On 22 August 2016 at 16:23, Rob Clark wrote: > I guess a lot comes down to 'how long before hw designers bolt a CP to > the thing'.. at that point, I think you especially don't want a > per-blit kernel interface. Regardless of whether or not we want it, we already _have_ it, in the form of V4L2 M2M. There are already a few IP blocks working on that, I believe. If V4L2 <-> KMS interop is painful, well, we need to fix that anyway ... Cheers, Daniel
[PATCH 16/18] drm/etnaviv: handle MMU exception in IRQ handler
2016-08-22 13:01 GMT+02:00 Lucas Stach :
> Bit 30 of the interrupt status signals an MMU exception. Handle this
> condition properly and dump some useful registers.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12
> drivers/gpu/drm/etnaviv/state_hi.xml.h | 9 +
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 4c706438c7c8..923f6c78e1af 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1402,6 +1402,18 @@ static irqreturn_t irq_handler(int irq, void *data)
> intr &= ~VIVS_HI_INTR_ACKNOWLEDGE_AXI_BUS_ERROR;
> }
>
> + if (intr & VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION) {
> + int i;
> +
> + dev_err(gpu->dev, "MMU fault status 0x%08x\n",
> + gpu_read(gpu, VIVS_MMUv2_STATUS));
> + for (i = 0; i < 4; i++)
> + dev_err(gpu->dev, "MMU %d fault addr
> 0x%08x\n",
> + i, gpu_read(gpu,
> + VIVS_MMUv2_EXCEPTION_ADDR(i)));
> + intr &= ~VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION;
> + }
> +
> while ((event = ffs(intr)) != 0) {
> struct fence *fence;
>
> diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h
> b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> index 807a3d9e0dd5..43c73e2ed34f 100644
> --- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
> +++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> @@ -8,10 +8,10 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng
> git clone git://0x04.net/rules-ng-ng
>
> The rules-ng-ng source files this header was generated from are:
> -- state_hi.xml ( 24309 bytes, from 2015-12-12 09:02:53)
> -- common.xml ( 18437 bytes, from 2015-12-12 09:02:53)
> +- state_hi.xml ( 25620 bytes, from 2016-08-19 22:07:37)
> +- common.xml ( 20583 bytes, from 2016-06-07 05:22:38)
>
> -Copyright (C) 2015
> +Copyright (C) 2016
> */
>
>
> @@ -78,9 +78,10 @@ Copyright (C) 2015
> #define VIVS_HI_AXI_STATUS_DET_RD_ERR 0x0200
>
> #define VIVS_HI_INTR_ACKNOWLEDGE 0x0010
> -#define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK
> 0x7fff
> +#define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK
> 0x3fff
> #define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__SHIFT 0
> #define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC(x) (((x) <<
> VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__SHIFT) &
> VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK)
> +#define VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION 0x4000
> #define VIVS_HI_INTR_ACKNOWLEDGE_AXI_BUS_ERROR 0x8000
>
> #define VIVS_HI_INTR_ENBL 0x0014
Where can I find the rnndb patch? Just share it and I will take care
that it gets integrated.
greets
--
Christian Gmeiner, MSc
https://soundcloud.com/christian-gmeiner
i865, drm_modeset_lock_all: BUG: unable to handle kernel NULL pointer dereference at 00000104
> Looks like an incorrect call to drm_encoder_cleanup() from the error > path. If we hit the error path we have never called drm_encoder_init. > Please try: > > diff --git a/drivers/gpu/drm/i915/intel_dvo.c > b/drivers/gpu/drm/i915/intel_dvo.c > index 47bdf9dad0d3..b9e5a63a7c9e 100644 > --- a/drivers/gpu/drm/i915/intel_dvo.c > +++ b/drivers/gpu/drm/i915/intel_dvo.c > @@ -554,7 +554,6 @@ void intel_dvo_init(struct drm_device *dev) > return; > } > > - drm_encoder_cleanup(&intel_encoder->base); > kfree(intel_dvo); > kfree(intel_connector); > } It works - the BUG is gone. Now I get just [drm:__intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun [ 10.499523] agpgart-intel :00:00.0: Intel 865 Chipset [ 10.499623] agpgart-intel :00:00.0: detected gtt size: 131072K total, 131072K mappable [ 10.499928] agpgart-intel :00:00.0: detected 16384K stolen memory [ 10.500939] [drm] Memory usable by graphics device = 128M [ 10.501029] [drm] Replacing VGA console driver [ 10.502804] Console: switching to colour dummy device 80x25 [ 10.504746] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 10.504760] [drm] Driver supports precise vblank timestamp query. [ 11.210224] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 11.237197] [drm] RC6 disabled, disabling runtime PM support [ 11.237407] [drm] initialized overlay support [ 11.362560] [drm:__intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun [ 11.418776] i915 :00:02.0: No connectors reported connected with modes [ 11.418792] [drm] Cannot find any crtc or sizes - going 1024x768 [ 11.421148] fbcon: inteldrmfb (fb0) is primary device [ 11.448292] Console: switching to colour frame buffer device 128x48 [ 11.458643] i915 :00:02.0: fb0: inteldrmfb frame buffer device -- Meelis Roos (mroos at linux.ee)
[PATCH 16/18] drm/etnaviv: handle MMU exception in IRQ handler
Hi Christian, Am Dienstag, den 23.08.2016, 11:58 +0200 schrieb Christian Gmeiner: > 2016-08-22 13:01 GMT+02:00 Lucas Stach : > > Bit 30 of the interrupt status signals an MMU exception. Handle this > > condition properly and dump some useful registers. > > > > Signed-off-by: Lucas Stach > > --- [...] > > > > > > @@ -78,9 +78,10 @@ Copyright (C) 2015 > > #define VIVS_HI_AXI_STATUS_DET_RD_ERR 0x0200 > > > > #define VIVS_HI_INTR_ACKNOWLEDGE 0x0010 > > -#define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK > > 0x7fff > > +#define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK > > 0x3fff > > #define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__SHIFT 0 > > #define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC(x) (((x) << > > VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__SHIFT) & > > VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK) > > +#define VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION 0x4000 > > #define VIVS_HI_INTR_ACKNOWLEDGE_AXI_BUS_ERROR 0x8000 > > > > #define VIVS_HI_INTR_ENBL 0x0014 > > Where can I find the rnndb patch? Just share it and I will take care > that it gets integrated. > Sorry about that. It's still on my machine at home. Will post it in the evening. Regards, Lucas
i865, drm_modeset_lock_all: BUG: unable to handle kernel NULL pointer dereference at 00000104
On Tue, Aug 23, 2016 at 02:35:03PM +0300, Meelis Roos wrote: > > Looks like an incorrect call to drm_encoder_cleanup() from the error > > path. If we hit the error path we have never called drm_encoder_init. > > Please try: > > > > diff --git a/drivers/gpu/drm/i915/intel_dvo.c > > b/drivers/gpu/drm/i915/intel_dvo.c > > index 47bdf9dad0d3..b9e5a63a7c9e 100644 > > --- a/drivers/gpu/drm/i915/intel_dvo.c > > +++ b/drivers/gpu/drm/i915/intel_dvo.c > > @@ -554,7 +554,6 @@ void intel_dvo_init(struct drm_device *dev) > > return; > > } > > > > - drm_encoder_cleanup(&intel_encoder->base); > > kfree(intel_dvo); > > kfree(intel_connector); > > } > > It works - the BUG is gone. > > Now I get just > [drm:__intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun Other than the annoying underrun, is everything else as expected? i.e. no connected outputs? Have we lost dvo detection? -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH v13 4/7] drm/i915/skl: Update plane watermarks atomically during plane updates
Op 22-08-16 om 18:50 schreef Lyude: > Thanks to Ville for suggesting this as a potential solution to pipe > underruns on Skylake. > > On Skylake all of the registers for configuring planes, including the > registers for configuring their watermarks, are double buffered. New > values written to them won't take effect until said registers are > "armed", which is done by writing to the PLANE_SURF (or in the case of > cursor planes, the CURBASE register) register. Applied, thanks. Can you resend 6/7 and 7/7?
i865, drm_modeset_lock_all: BUG: unable to handle kernel NULL pointer dereference at 00000104
> > > Looks like an incorrect call to drm_encoder_cleanup() from the error > > > path. If we hit the error path we have never called drm_encoder_init. > > > Please try: > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dvo.c > > > b/drivers/gpu/drm/i915/intel_dvo.c > > > index 47bdf9dad0d3..b9e5a63a7c9e 100644 > > > --- a/drivers/gpu/drm/i915/intel_dvo.c > > > +++ b/drivers/gpu/drm/i915/intel_dvo.c > > > @@ -554,7 +554,6 @@ void intel_dvo_init(struct drm_device *dev) > > > return; > > > } > > > > > > - drm_encoder_cleanup(&intel_encoder->base); > > > kfree(intel_dvo); > > > kfree(intel_connector); > > > } > > > > It works - the BUG is gone. > > > > Now I get just > > [drm:__intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun > > Other than the annoying underrun, is everything else as expected? i.e. > no connected outputs? Have we lost dvo detection? Yes, as expected - there is no monitor connected. -- Meelis Roos (mroos at linux.ee)
[RESEND PATCH v2 1/3] drm: dw_hdmi: use of_get_i2c_adapter_by_node interface
Hello Russell, On 08/18/2016 05:32 PM, Russell King - ARM Linux wrote: > On Tue, Aug 16, 2016 at 11:26:43PM +0300, Vladimir Zapolskiy wrote: >> This change is needed to properly lock I2C bus driver, which serves >> DDC. >> >> The change fixes an overflow over zero of I2C bus driver user counter: >> >> root at imx6q:~# lsmod >> Not tainted >> dw_hdmi_ahb_audio 4082 0 - Live 0xbf02c000 >> dw_hdmi_imx 3498 0 - Live 0xbf00d000 >> dw_hdmi 16398 2 dw_hdmi_ahb_audio,dw_hdmi_imx, Live 0xbf004000 >> i2c_imx 16687 0 - Live 0xbf017000 >> >> root at imx6q:~# rmmod dw_hdmi_imx >> root at imx6q:~# lsmod >> Not tainted >> dw_hdmi_ahb_audio 4082 0 - Live 0xbf02c000 >> dw_hdmi 16398 1 dw_hdmi_ahb_audio, Live 0xbf004000 >> i2c_imx 16687 -1 - Live 0xbf017000 >> ^^ >> >> root at imx6q:~# rmmod i2c_imx >> rmmod: ERROR: Module i2c_imx is in use >> >> Note that prior to this change put_device() coupled with >> of_find_i2c_adapter_by_node() was missing on error path of >> dw_hdmi_bind(), added i2c_put_adapter() there along with the change. > > I *guess* this is the right thing, but it would be nice to see the > results with the patch applied in the commit description. Nevertheless: > > Acked-by: Russell King > thank you for review. For information this is a result after applying the fix (+1 to i2c_imx users): root at imx6q# lsmod Not tainted dw_hdmi_ahb_audio 4082 0 - Live 0xbf02c000 i2c_imx 16687 1 - Live 0xbf011000 dw_hdmi_imx 3498 0 - Live 0xbf00d000 dw_hdmi 18925 2 dw_hdmi_ahb_audio,dw_hdmi_imx, Live 0xbf004000 root at imx6q:~# rmmod dw_hdmi_imx root at imx6q:~# lsmod Not tainted dw_hdmi_ahb_audio 4082 0 - Live 0xbf02c000 i2c_imx 16687 0 - Live 0xbf011000 dw_hdmi 18925 1 dw_hdmi_ahb_audio, Live 0xbf004000 No weird negative use count. I have another pending change against DW HDMI, to avoid git-am conflicts I'll rebase it on top of this one and resend today later on. > > I'd also like to see the DDC bits extracted from the various imx > drivers, because this is surely common code - I've had this floating > around for a few years but never got around to finishing it off and > submitting it. If folk think this is a good idea, and want to take > the idea on, that's fine by me. > > drivers/gpu/drm/Makefile| 2 + > drivers/gpu/drm/bridge/dw-hdmi.c| 98 > + > drivers/gpu/drm/drm_ddc_connector.c | 91 ++ > drivers/gpu/drm/imx/imx-tve.c | 59 ++ > include/drm/drm_ddc_connector.h | 33 + > 5 files changed, 163 insertions(+), 120 deletions(-) I've briefly reviewed the changes and in my opinion this is a good to have generalization of DDC connector, hopefully DRM people agree. Moreover I assume that in case of getting modes over I2C/DDC most of the .get_modes callbacks share almost the same code sequence: drm_get_edid() drm_detect_hdmi_monitor() drm_mode_connector_update_edid_property() drm_add_edid_modes() drm_edid_to_eld() I'm not absolutely sure, but probably this can be generalized as well. -- With best wishes, Vladimir
[PATCH] drm: Don't allow legacy cursor updates to stall others or be stalled
Legacy cursor updates are entirely asynchronous with respect to all
other users of the atomic pipeline. They neither wait for any
outstanding flips, nor do they cause subsequent flips to be delayed. The
only ordering we do require is given by making the legacy cursor update
nonblocking (so the sequence of userspace calls from a process is
ordered from the pov of the client).
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9abe0a242f96..9441fb9d9637 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1422,9 +1422,11 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
state->crtcs[i].commit = commit;
- ret = stall_checks(crtc, nonblock);
- if (ret)
- return ret;
+ if (!state->legacy_cursor_update) {
+ ret = stall_checks(crtc, nonblock);
+ if (ret)
+ return ret;
+ }
/* Drivers only send out events when at least either current or
* new CRTC state is active. Complete right away if everything
@@ -1989,7 +1991,7 @@ void drm_atomic_helper_swap_state(struct drm_atomic_state
*state,
swap(state->crtcs[i].state, crtc->state);
crtc->state->state = NULL;
- if (state->crtcs[i].commit) {
+ if (state->crtcs[i].commit && !state->legacy_cursor_update) {
spin_lock(&crtc->commit_lock);
list_add(&state->crtcs[i].commit->commit_entry,
&crtc->commit_list);
--
2.9.3
[PATCH] drm: Don't allow legacy cursor updates to stall others or be stalled
On Tue, Aug 23, 2016 at 11:48:34AM +0100, Chris Wilson wrote: > Legacy cursor updates are entirely asynchronous with respect to all > other users of the atomic pipeline. They neither wait for any > outstanding flips, nor do they cause subsequent flips to be delayed. The > only ordering we do require is given by making the legacy cursor update > nonblocking (so the sequence of userspace calls from a process is s/nonblocking/blocking/! > ordered from the pov of the client). -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm: Don't allow legacy cursor updates to stall others or be stalled
On Tue, Aug 23, 2016 at 11:48:34AM +0100, Chris Wilson wrote: > Legacy cursor updates are entirely asynchronous with respect to all > other users of the atomic pipeline. They neither wait for any > outstanding flips, nor do they cause subsequent flips to be delayed. The > only ordering we do require is given by making the legacy cursor update > nonblocking (so the sequence of userspace calls from a process is > ordered from the pov of the client). Hmm, it is also not entirely true. A modeset (reconfiguration of the pipe size) would require all cursor updates to be flushed, or else we may make the cursor out-of-bounds which can cause GPU hangs. At the moment, I think that is governed by the crtc lock and the blocking nature of the modeset + cursor update. But in the future we want far more fine grained control over (mostly) asynchronous updates. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 16/18] drm/etnaviv: handle MMU exception in IRQ handler
On Mon, Aug 22, 2016 at 7:01 AM, Lucas Stach wrote:
> Bit 30 of the interrupt status signals an MMU exception. Handle this
> condition properly and dump some useful registers.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12
> drivers/gpu/drm/etnaviv/state_hi.xml.h | 9 +
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 4c706438c7c8..923f6c78e1af 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1402,6 +1402,18 @@ static irqreturn_t irq_handler(int irq, void *data)
> intr &= ~VIVS_HI_INTR_ACKNOWLEDGE_AXI_BUS_ERROR;
> }
>
> + if (intr & VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION) {
> + int i;
> +
> + dev_err(gpu->dev, "MMU fault status 0x%08x\n",
> + gpu_read(gpu, VIVS_MMUv2_STATUS));
Drive-by comment, and I don't know if this is the case w/ vivante, but
on adreno I have observed that when I get iommu faults (for example,
bad texture state or something like that) I tend to get a *lot* of
iommu faults, not just one.
If that is the case here, you might want to ratelimit the dev_err prints..
BR,
-R
> + for (i = 0; i < 4; i++)
> + dev_err(gpu->dev, "MMU %d fault addr
> 0x%08x\n",
> + i, gpu_read(gpu,
> + VIVS_MMUv2_EXCEPTION_ADDR(i)));
> + intr &= ~VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION;
> + }
> +
> while ((event = ffs(intr)) != 0) {
> struct fence *fence;
>
> diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h
> b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> index 807a3d9e0dd5..43c73e2ed34f 100644
> --- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
> +++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> @@ -8,10 +8,10 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng
> git clone git://0x04.net/rules-ng-ng
>
> The rules-ng-ng source files this header was generated from are:
> -- state_hi.xml ( 24309 bytes, from 2015-12-12 09:02:53)
> -- common.xml ( 18437 bytes, from 2015-12-12 09:02:53)
> +- state_hi.xml ( 25620 bytes, from 2016-08-19 22:07:37)
> +- common.xml ( 20583 bytes, from 2016-06-07 05:22:38)
>
> -Copyright (C) 2015
> +Copyright (C) 2016
> */
>
>
> @@ -78,9 +78,10 @@ Copyright (C) 2015
> #define VIVS_HI_AXI_STATUS_DET_RD_ERR 0x0200
>
> #define VIVS_HI_INTR_ACKNOWLEDGE 0x0010
> -#define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK
> 0x7fff
> +#define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK
> 0x3fff
> #define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__SHIFT 0
> #define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC(x) (((x) <<
> VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__SHIFT) &
> VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK)
> +#define VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION 0x4000
> #define VIVS_HI_INTR_ACKNOWLEDGE_AXI_BUS_ERROR 0x8000
>
> #define VIVS_HI_INTR_ENBL 0x0014
> --
> 2.8.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Don't allow legacy cursor updates to stall others or be stalled
On Tue, Aug 23, 2016 at 12:26:44PM +0100, Chris Wilson wrote: > On Tue, Aug 23, 2016 at 11:48:34AM +0100, Chris Wilson wrote: > > Legacy cursor updates are entirely asynchronous with respect to all > > other users of the atomic pipeline. They neither wait for any > > outstanding flips, nor do they cause subsequent flips to be delayed. The > > only ordering we do require is given by making the legacy cursor update > > nonblocking (so the sequence of userspace calls from a process is > > ordered from the pov of the client). > > Hmm, it is also not entirely true. A modeset (reconfiguration of the > pipe size) would require all cursor updates to be flushed, or else we > may make the cursor out-of-bounds which can cause GPU hangs. At the > moment, I think that is governed by the crtc lock and the blocking > nature of the modeset + cursor update. But in the future we want far > more fine grained control over (mostly) asynchronous updates. Yup, that's why I chickened out of fixing this properly ;-) What we could do is set a flag that it's a modeset in drm_crtc_commit, and hand a flag to stall_check to only look for modeset updates. Entirely elliding isn't a good idea. The other issue is how to order cursor updates through the legacy update ioctl against atomic updates on the plane. Not that userspace should mix those, but it could, and we need to make sure they're ordered properly. This is especially painful when watermarks have changed, which is entirely driver-dependent. At that point it's probably time to ragequit. Aside: i915 atomic commit is atm stalling way too much, it signals hw_done too late. Iirc I've sprinkled a fixme into either the commit or code about what needs to be done for that. Legacy cursor updates with hw_done signalled early enough (i.e. when we wrote the register, before the hw has committed the update) should fix this stalling issue too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v2] drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()
This adds a function that also takes the console lock before calling
fb_set_suspend() in contrast to drm_fb_helper_set_suspend() which is
a plain wrapper around fb_set_suspend().
Resume is run asynchronously using a worker if the console lock is
already taken. This is modelled after the i915 driver.
Signed-off-by: Noralf Trønnes
---
Daniel,
I haven't got time to convert drivers to use this and now that simpledrm
won't be using it we can wait with this if you prefer, and I'll bundle it
with tinydrm when the time comes.
Noralf.
Changes from version 1:
- Change function name to drm_fb_helper_set_suspend_unlocked()
- Use suspend as argument name to increase readability
drivers/gpu/drm/drm_fb_helper.c | 62 -
include/drm/drm_fb_helper.h | 9 ++
2 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ce54e98..2886df5 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -29,6 +29,7 @@
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
#include
#include
#include
@@ -618,6 +619,16 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper
*helper)
kfree(helper->crtc_info);
}
+static void drm_fb_helper_resume_worker(struct work_struct *work)
+{
+ struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
+ resume_work);
+
+ console_lock();
+ fb_set_suspend(helper->fbdev, 0);
+ console_unlock();
+}
+
static void drm_fb_helper_dirty_work(struct work_struct *work)
{
struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
@@ -649,6 +660,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct
drm_fb_helper *helper,
{
INIT_LIST_HEAD(&helper->kernel_fb_list);
spin_lock_init(&helper->dirty_lock);
+ INIT_WORK(&helper->resume_work, drm_fb_helper_resume_worker);
INIT_WORK(&helper->dirty_work, drm_fb_helper_dirty_work);
helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
helper->funcs = funcs;
@@ -1026,7 +1038,9 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
* @fb_helper: driver-allocated fbdev helper
* @state: desired state, zero to resume, non-zero to suspend
*
- * A wrapper around fb_set_suspend implemented by fbdev core
+ * A wrapper around fb_set_suspend implemented by fbdev core.
+ * Use drm_fb_helper_set_suspend_unlocked() if you don't need to take
+ * the lock yourself
*/
void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state)
{
@@ -1035,6 +1049,52 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper
*fb_helper, int state)
}
EXPORT_SYMBOL(drm_fb_helper_set_suspend);
+/**
+ * drm_fb_helper_set_suspend_unlocked - wrapper around fb_set_suspend that also
+ * takes the console lock
+ * @fb_helper: driver-allocated fbdev helper
+ * @state: desired state, zero to resume, non-zero to suspend
+ *
+ * A wrapper around fb_set_suspend() that takes the console lock. If the lock
+ * isn't available on resume, a worker is tasked with waiting for the lock
+ * to become available. The console lock can be pretty contented on resume
+ * due to all the printk activity.
+ *
+ * This function can be called multiple times with the same state since
+ * &fb_info->state is checked to see if fbdev is running or not before locking.
+ *
+ * Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
+ */
+void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
+ int suspend)
+{
+ if (!fb_helper || !fb_helper->fbdev)
+ return;
+
+ /* make sure there's no pending/ongoing resume */
+ flush_work(&fb_helper->resume_work);
+
+ if (suspend) {
+ if (fb_helper->fbdev->state != FBINFO_STATE_RUNNING)
+ return;
+
+ console_lock();
+
+ } else {
+ if (fb_helper->fbdev->state == FBINFO_STATE_RUNNING)
+ return;
+
+ if (!console_trylock()) {
+ schedule_work(&fb_helper->resume_work);
+ return;
+ }
+ }
+
+ fb_set_suspend(fb_helper->fbdev, suspend);
+ console_unlock();
+}
+EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
+
static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, u16 regno, struct fb_info *info)
{
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index db8d478..5bde508 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -176,6 +176,7 @@ struct drm_fb_helper_connector {
* the screen buffer
* @dirty_lock: spinlock protecting @dirty_clip
* @dirty_work: worker used to flush the framebuffer
+ * @resume_work: worker used during resume if th
[PATCH v2] drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()
On Tue, Aug 23, 2016 at 01:54:06PM +0200, Noralf Trønnes wrote:
> This adds a function that also takes the console lock before calling
> fb_set_suspend() in contrast to drm_fb_helper_set_suspend() which is
> a plain wrapper around fb_set_suspend().
> Resume is run asynchronously using a worker if the console lock is
> already taken. This is modelled after the i915 driver.
>
> Signed-off-by: Noralf Trønnes
> ---
>
> Daniel,
>
> I haven't got time to convert drivers to use this and now that simpledrm
> won't be using it we can wait with this if you prefer, and I'll bundle it
> with tinydrm when the time comes.
Well it's ready, and maybe someone else has a need for it already. Applied
it already, thanks a lot for the quick respin.
-Daniel
>
> Noralf.
>
>
> Changes from version 1:
> - Change function name to drm_fb_helper_set_suspend_unlocked()
> - Use suspend as argument name to increase readability
>
> drivers/gpu/drm/drm_fb_helper.c | 62
> -
> include/drm/drm_fb_helper.h | 9 ++
> 2 files changed, 70 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index ce54e98..2886df5 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -29,6 +29,7 @@
> */
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> +#include
> #include
> #include
> #include
> @@ -618,6 +619,16 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper
> *helper)
> kfree(helper->crtc_info);
> }
>
> +static void drm_fb_helper_resume_worker(struct work_struct *work)
> +{
> + struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
> + resume_work);
> +
> + console_lock();
> + fb_set_suspend(helper->fbdev, 0);
> + console_unlock();
> +}
> +
> static void drm_fb_helper_dirty_work(struct work_struct *work)
> {
> struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
> @@ -649,6 +660,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct
> drm_fb_helper *helper,
> {
> INIT_LIST_HEAD(&helper->kernel_fb_list);
> spin_lock_init(&helper->dirty_lock);
> + INIT_WORK(&helper->resume_work, drm_fb_helper_resume_worker);
> INIT_WORK(&helper->dirty_work, drm_fb_helper_dirty_work);
> helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
> helper->funcs = funcs;
> @@ -1026,7 +1038,9 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
> * @fb_helper: driver-allocated fbdev helper
> * @state: desired state, zero to resume, non-zero to suspend
> *
> - * A wrapper around fb_set_suspend implemented by fbdev core
> + * A wrapper around fb_set_suspend implemented by fbdev core.
> + * Use drm_fb_helper_set_suspend_unlocked() if you don't need to take
> + * the lock yourself
> */
> void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state)
> {
> @@ -1035,6 +1049,52 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper
> *fb_helper, int state)
> }
> EXPORT_SYMBOL(drm_fb_helper_set_suspend);
>
> +/**
> + * drm_fb_helper_set_suspend_unlocked - wrapper around fb_set_suspend that
> also
> + * takes the console lock
> + * @fb_helper: driver-allocated fbdev helper
> + * @state: desired state, zero to resume, non-zero to suspend
> + *
> + * A wrapper around fb_set_suspend() that takes the console lock. If the lock
> + * isn't available on resume, a worker is tasked with waiting for the lock
> + * to become available. The console lock can be pretty contented on resume
> + * due to all the printk activity.
> + *
> + * This function can be called multiple times with the same state since
> + * &fb_info->state is checked to see if fbdev is running or not before
> locking.
> + *
> + * Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
> + */
> +void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
> + int suspend)
> +{
> + if (!fb_helper || !fb_helper->fbdev)
> + return;
> +
> + /* make sure there's no pending/ongoing resume */
> + flush_work(&fb_helper->resume_work);
> +
> + if (suspend) {
> + if (fb_helper->fbdev->state != FBINFO_STATE_RUNNING)
> + return;
> +
> + console_lock();
> +
> + } else {
> + if (fb_helper->fbdev->state == FBINFO_STATE_RUNNING)
> + return;
> +
> + if (!console_trylock()) {
> + schedule_work(&fb_helper->resume_work);
> + return;
> + }
> + }
> +
> + fb_set_suspend(fb_helper->fbdev, suspend);
> + console_unlock();
> +}
> +EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
> +
> static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
>u16 blue, u16 regno, struct fb_info *info)
> {
> diff --
[PATCH v4 5/5] drm: simpledrm: honour remove_conflicting_framebuffers()
On Mon, Aug 22, 2016 at 10:25:25PM +0200, Noralf Trønnes wrote:
> There is currently no non-fbdev mechanism in place to kick out
> simpledrm when the real hw-driver is probed. As a stop gap until
> that is in place, honour remove_conflicting_framebuffers() and
> delete the simple-framebuffer platform device when it's called.
>
> Signed-off-by: Noralf Trønnes
> ---
>
> Changes from version 3:
> - drm_device.platformdev is deprecated, use to_platform_device(ddev->dev).
> - fb_helper might have been released in sdrm_fbdev_fb_destroy(),
> so open code drm_fb_helper_release_fbi()
> - Strengthen the test in sdrm_fbdev_event_notify() that we're the one.
>
> Changes from version 2:
> - Don't forget to free fb_info when kicked out.
>
> drivers/gpu/drm/simpledrm/Kconfig | 5 +++
> drivers/gpu/drm/simpledrm/simpledrm.h | 2 +
> drivers/gpu/drm/simpledrm/simpledrm_drv.c | 3 ++
> drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 62
> -
> 4 files changed, 70 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/simpledrm/Kconfig
> b/drivers/gpu/drm/simpledrm/Kconfig
> index 3257590..4275d13 100644
> --- a/drivers/gpu/drm/simpledrm/Kconfig
> +++ b/drivers/gpu/drm/simpledrm/Kconfig
> @@ -16,6 +16,11 @@ config DRM_SIMPLEDRM
> If fbdev support is enabled, this driver will also provide an fbdev
> compatibility layer that supports fbcon, mmap is not supported.
>
> + WARNING
> + fbdev must be enabled for simpledrm to disable itself when a real
> + hw-driver is probed. It relies on remove_conflicting_framebuffers()
> + to be called by the hw-driver.
> +
> If unsure, say Y.
>
> To compile this driver as a module, choose M here: the
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm.h
> b/drivers/gpu/drm/simpledrm/simpledrm.h
> index d4eb52c..3cca196 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm.h
> +++ b/drivers/gpu/drm/simpledrm/simpledrm.h
> @@ -87,5 +87,7 @@ int sdrm_fb_init(struct drm_device *ddev, struct
> sdrm_framebuffer *fb,
>struct sdrm_gem_object *obj);
> void sdrm_fbdev_init(struct sdrm_device *sdrm);
> void sdrm_fbdev_cleanup(struct sdrm_device *sdrm);
> +void sdrm_fbdev_kickout_init(void);
> +void sdrm_fbdev_kickout_exit(void);
>
> #endif /* SDRM_DRV_H */
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> b/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> index fe752c6..0750652 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> +++ b/drivers/gpu/drm/simpledrm/simpledrm_drv.c
> @@ -531,12 +531,15 @@ static int __init sdrm_init(void)
> }
> }
>
> + sdrm_fbdev_kickout_init();
> +
> return 0;
> }
> module_init(sdrm_init);
>
> static void __exit sdrm_exit(void)
> {
> + sdrm_fbdev_kickout_exit();
> platform_driver_unregister(&sdrm_simplefb_driver);
> }
> module_exit(sdrm_exit);
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> index c6596ad..7c6db2c 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> +++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> @@ -44,6 +44,20 @@ static int sdrm_fb_mmap(struct fb_info *info, struct
> vm_area_struct *vma)
> return -ENODEV;
> }
>
> +/*
> + * Releasing has to be done outside the notifier callchain when we're
> + * kicked out, since do_unregister_framebuffer() calls put_fb_info()
> + * after the notifier has run.
> + * Open code drm_fb_helper_release_fbi() since fb_helper is freed at
> + * this point when kicked out.
> + */
> +static void sdrm_fbdev_fb_destroy(struct fb_info *info)
> +{
> + if (info->cmap.len)
> + fb_dealloc_cmap(&info->cmap);
> + framebuffer_release(info);
> +}
> +
> static struct fb_ops sdrm_fbdev_ops = {
> .owner = THIS_MODULE,
> .fb_fillrect= drm_fb_helper_sys_fillrect,
> @@ -53,6 +67,7 @@ static struct fb_ops sdrm_fbdev_ops = {
> .fb_set_par = drm_fb_helper_set_par,
> .fb_setcmap = drm_fb_helper_setcmap,
> .fb_mmap= sdrm_fb_mmap,
> + .fb_destroy = sdrm_fbdev_fb_destroy,
> };
>
> static int sdrm_fbdev_create(struct drm_fb_helper *helper,
> @@ -110,6 +125,9 @@ static int sdrm_fbdev_create(struct drm_fb_helper *helper,
> fbi->screen_base = obj->vmapping;
> fbi->fix.smem_len = sdrm->fb_size;
>
> + fbi->apertures->ranges[0].base = sdrm->fb_base;
> + fbi->apertures->ranges[0].size = sdrm->fb_size;
> +
> return 0;
>
> err_fbi_release:
> @@ -188,9 +206,13 @@ void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
> sdrm->fb_helper = NULL;
> fbdev = to_sdrm_fbdev(fb_helper);
>
> - drm_fb_helper_unregister_fbi(fb_helper);
> + /* it might have been kicked out */
> + if (registered_fb[fbdev->fb_helper.fbdev->node])
> + drm_fb_helper_unregister_fbi(fb_helper);
> +
> + /* freeing fb_info is done in fb_ops.fb_destroy() */
> +
> cancel_
[PATCH 0/3] drm/tilcdc: Some fixes for LCDC rev1
Hi, I found some missing bits for rev1 of the LCDC and here are some of the changes I am using to use the DRM driver on an LCDCK (which has a rev1). 1/3 seems required by rev1 of the IP and without it my the LCDC on my LCDK keeps can't sync, 2/3 is required by the driver logic, while 3/3 is less of a requirement. Although 1,2/3 would have fitted drm-fixes I based them on drm-next as 2/3 would conflict with the recent changes in drm-next. Another thing which is also an absolute requirement for the rev1 but with which rev2 seems to cope fine is the palette loading (even if the DRM uses >= 16bpp formats), dixit the TRM: "12-, 16-, and 24-BPP modes do not need a palette; i.e., the pixel data is the desired RGB value. However, the first 32 bytes are still considered a palette. The first entry should be 4000h (bit 14 is 1) while the remaining entries must be filled with 0.". ATM I am using a local crude way of loading the palette to verify the missing bits to get the DRM driver properly working on the LCDK (as I haven't seen how things work in the DRM subsystem I can't post any proper change for that). The posted changes and the above mentioned palette loading missing bit are specific to the DRM driver. However there are other shortcomings to the proper functioning of the LCDC on some platforms (I am currently focusing on the LCDK but I guess it should be true for all da850 based systems), which are not inherent to the DRM driver driver but which strongly relate to it: - The pixel clock rate setting (eg. currently the davinci clk can't cope properly with the DRM driver way of setting the clock and doesn't use the common clock framework) - The memory bandwidth/latency requirements for the LCDC are not met with the default priority settings (apparently there is a fix in da850_lcd_hw_init of: http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=blob;f=arch/arm/mach-davinci/board-omapl138-lcdk.c;h=689b4f304011e09e262782cf8c4b96eba00ac28b;hb=HEAD). Of course this one affects both the DRM and framebuffer systems. Hence to test the LCDK my crude local changes include (ie. on top of the posted changes and some dts or sync_lost recovery bits): - palette loading - tweak of the pixel clock to cope with davinci clk - adjustment of the memory master priorities BTW, with the recent changes of tilcdc from drm-next, I see this warning when loading the module: "drm:drm_helper_disable_unused_functions [drm_kms_helper]] *ERROR* Called for atomic driver, this is not what you want." Regards, Karl Karl Beldan (3): drm/tilcdc: Adjust the FB_CEILING address drm/tilcdc: Enable EOF interrupts for v1 LCDC drm/tilcdc: Advertise the DRM_FORMATs according to the IP revision drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4 +++- drivers/gpu/drm/tilcdc/tilcdc_plane.c | 7 ++- 2 files changed, 9 insertions(+), 2 deletions(-) -- 2.9.2
[PATCH 1/3] drm/tilcdc: Adjust the FB_CEILING address
The LCDC seems to expect its framebuffer ceiling address pointer to be an inclusive bound. The IP rev2 seems to cope with that but rev1 (as found on the LCDK) don't. Also note that this is what the framebuffer code does in da8xx-fb.c. Since, as the TRM puts it, "The 2 LSBs are hardwired to 00b", the dma_addr_t can be decremented without cast. I tested it with a v2 (AM335x, rev 0x4F201000) and an LCDK (v1). Signed-off-by: Karl Beldan --- drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c index 25d6b22..89d6916 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c @@ -80,7 +80,7 @@ static void set_scanout(struct drm_crtc *crtc, struct drm_framebuffer *fb) end = start + (crtc->mode.vdisplay * fb->pitches[0]); tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, start); - tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, end); + tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, end - 1); if (tilcdc_crtc->curr_fb) drm_flip_work_queue(&tilcdc_crtc->unref_work, -- 2.9.2
[PATCH 2/3] drm/tilcdc: Enable EOF interrupts for v1 LCDC
This got accidentally dropped in the fixed commit and is required for
the driver to properly work on the rev1 IP, such as found on the LCDK.
Fixes: 2b2080d7e9ae ("drm/tilcdc: Get rid of complex ping-pong mechanism")
Signed-off-by: Karl Beldan
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 89d6916..163f111 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -98,6 +98,8 @@ static void tilcdc_crtc_enable_irqs(struct drm_device *dev)
if (priv->rev == 1) {
tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
LCDC_V1_UNDERFLOW_INT_ENA);
+ tilcdc_set(dev, LCDC_DMA_CTRL_REG,
+ LCDC_V1_END_OF_FRAME_INT_ENA);
} else {
tilcdc_write(dev, LCDC_INT_ENABLE_SET_REG,
LCDC_V2_UNDERFLOW_INT_ENA |
--
2.9.2
[PATCH 3/3] drm/tilcdc: Advertise the DRM_FORMATs according to the IP revision
ATM the driver unconditionally advertises support for some 24bpp and
32bpp formats while version 1 of the IP only supports up to 16bpp.
Signed-off-by: Karl Beldan
---
drivers/gpu/drm/tilcdc/tilcdc_plane.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
index 41911e3..11285f6 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
@@ -114,12 +114,17 @@ static const struct drm_plane_helper_funcs
plane_helper_funcs = {
int tilcdc_plane_init(struct drm_device *dev,
struct drm_plane *plane)
{
+ struct tilcdc_drm_private *priv = dev->dev_private;
+ unsigned int num_formats = ARRAY_SIZE(tilcdc_formats);
int ret;
+ if (priv->rev == 1)
+ num_formats = 1;
+
ret = drm_plane_init(dev, plane, 1,
&tilcdc_plane_funcs,
tilcdc_formats,
-ARRAY_SIZE(tilcdc_formats),
+num_formats,
true);
if (ret) {
dev_err(dev->dev, "Failed to initialize plane: %d\n", ret);
--
2.9.2
[PATCH] drm/doc: Add a few words on validation with IGT
On Tue, Aug 23, 2016 at 11:15:31AM +0200, Tomeu Vizoso wrote: > Also provide some pointers for building IGT as some kernel hackers might > not be that familiar with building stuff on Linux distros. > > Signed-off-by: Tomeu Vizoso > Cc: Daniel Vetter > --- > Documentation/gpu/drm-uapi.rst | 37 + > 1 file changed, 37 insertions(+) > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index 94876938aef3..5e425ab83dc1 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -112,3 +112,40 @@ interfaces. Especially since all hardware-acceleration > interfaces to > userspace are driver specific for efficiency and other reasons these > interfaces can be rather substantial. Hence every driver has its own > chapter. > + > +Validating changes with IGT > +=== I think it'd be good to move this at least ahead of the vblank section. The vblank section is pure legacy stuff, so best if we leave it at the bottom. > + > +There's a collection of tests that aims to cover the whole functionality of > +DRM drivers and that can be used to check that changes to DRM drivers or the > +core don't regress existing functionality. This test suite is called IGT and > +its code can be found in > https://cgit.freedesktop.org/xorg/app/intel-gpu-tools. Daniel Stone just did a rebranding of igt, it's now in /drm/igt-gpu-tests. Or at least should be once the updates trickle through. Please confirm with Daniel before respinning. Aside on that rebranding: I think we could do a similar rebranding in igt as IGT Gpu Tests in the igt documentation. If you feel like doing that at least. -Daniel > + > +To build IGT, start by installing its build dependencies. In Debian-based > +systems:: > + > + # apt-get build-dep intel-gpu-tools > + > +And in Fedora-based systems:: > + > + # dnf builddep intel-gpu-tools > + > +Then clone the repository:: > + > + $ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > + > +Configure the build system and start the build:: > + > + $ cd intel-gpu-tools && ./autogen.sh && make -j6 > + > +Download the piglit dependency:: > + > + $ ./scripts/run-tests.sh -d > + > +And run the tests:: > + > + $ ./scripts/run-tests.sh -t kms -t core -s > + > +run-tests.sh is a wrapper around piglit that will execute the tests matching > +the -t options. A report in HTML format will be available in > +./results/html/index.html. Results can be compared with piglit. > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts
On Tue, 23 Aug 2016 08:01:35 +0200 Daniel Vetter wrote: > I'm also not too sure about whether dma-buf really should be it's own > subdirectory. It's plucked from the device-drivers.tmpl, I think an > overall device-drivers/ for all the misc subsystems and support code would > be better. Then one toc there, which fans out to either kernel-doc and > overview docs. I'm quite convinced it shouldn't be. If you get a chance, could you have a look at the "RFC: The beginning of a proper driver-api book" series I posted yesterday (yes, I should have copied more of you, sorry)? It shows the direction I would like to go with driver API documentation, and, assuming we go that way, I'd like the dma-buf documentation to fit into that. Thanks, jon
[PATCH v3 1/5] drm/rockchip: sort registers define by chip's number
On Mon, Aug 22, 2016 at 8:40 PM, Mark yao wrote: > On 2016å¹´08æ23æ¥ 04:30, Sean Paul wrote: >> >> On Thu, Aug 18, 2016 at 6:02 AM, Mark yao wrote: >>> >>> On 2016å¹´08æ18æ¥ 17:11, Daniel Vetter wrote: On Thu, Aug 18, 2016 at 05:08:14PM +0800, Mark yao wrote: >> >> Hi Sean >> >> Thanks for send v3 patch for rk3399 vop support. >> >> But sorry for that, I had changed my mind, those patches are >> deprecated, >> I have new rk3399 patch on my downstream kernel, I will upstream soon. Wut? Imo merge Sean's patch here, and then rebase your downstream patches on top of it. That you have a downstream tree which is out of sync with upstream shouldn't be a reason to stall upstream development. -Daniel >>> Yeah, Sorry for that. >>> >>> In fact, on my downstream kernel, also have those patches, my new rk3399 >>> patches are based on them, >>> but the new rk3399 patches will cover the those patches, Sean's patches >>> is >>> old version. >>> >>> I just want to fast forward, don't want to send two version drivers to >>> upstream. >>> but if you and Dave feel ok for that, I have no problem:-) . >>> >>> merged Sean's patches and then apply new version patches. >>> >> Ok, so can I get a review/ack for these revised patches then? >> Something is better than nothing, and there's a bunch of stuff that >> depends on these changes. >> >> Sean > > Yes, But I miss your [PATCH v3 0/5] and [PATCH v3 4/5]. do you mean the lost > patches use v2 version? > Yes, v2 4/5 was reviewed as-is, so I just applied it. Sean > >> >> >>> Thanks. >>> >>> -- >>> ï¼ark Yao >>> >>> >> >> > > > -- > ï¼ark Yao > >
[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts
On Tue, Aug 23, 2016 at 3:08 PM, Jonathan Corbet wrote: > On Tue, 23 Aug 2016 08:01:35 +0200 > Daniel Vetter wrote: > >> I'm also not too sure about whether dma-buf really should be it's own >> subdirectory. It's plucked from the device-drivers.tmpl, I think an >> overall device-drivers/ for all the misc subsystems and support code would >> be better. Then one toc there, which fans out to either kernel-doc and >> overview docs. > > I'm quite convinced it shouldn't be. > > If you get a chance, could you have a look at the "RFC: The beginning of > a proper driver-api book" series I posted yesterday (yes, I should have > copied more of you, sorry)? It shows the direction I would like to go > with driver API documentation, and, assuming we go that way, I'd like the > dma-buf documentation to fit into that. Looks real pretty, ack on that. And we can always split up more, e.g. by extracting dma-buf.rst (and merg the current dma-buffer-sharing.txt into that one). I think the more interesting story is, what's your plan with all the other driver related subsystem? Especially the ones which already have full directories of their own, like e.g. Documentation/gpio/. I think those should be really part of the infrastructure section (or something equally high-level), together with other awesome servies like pwm, regman, irqchip, ... And then there's also the large-scale subsystems like media or gpu. What's the plan to tie them all together? Personally I'm leaning towards keeping the existing directories (where they exist already), but inserting links into the overall driver-api section. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[drm-intel:for-linux-next 14/16] htmldocs: drivers/gpu/drm/i915/intel_dp.c:5063: warning: No description found for parameter 'dev_priv'
l_edp_drrs_disable - Disable DRRS
b33a2815 Vandana Kannan 2015-02-13 5183 * @intel_dp: DP struct
b33a2815 Vandana Kannan 2015-02-13 5184 *
b33a2815 Vandana Kannan 2015-02-13 5185 */
85cb48a1 Maarten Lankhorst 2016-08-09 5186 void
intel_edp_drrs_disable(struct intel_dp *intel_dp,
85cb48a1 Maarten Lankhorst 2016-08-09 5187
struct intel_crtc_state *old_crtc_state)
c395578e Vandana Kannan 2015-01-22 @5188 {
c395578e Vandana Kannan 2015-01-22 5189 struct drm_device *dev
= intel_dp_to_dev(intel_dp);
fac5e23e Chris Wilson2016-07-04 5190 struct drm_i915_private
*dev_priv = to_i915(dev);
c395578e Vandana Kannan 2015-01-22 5191
:: The code at line 5063 was first introduced by commit
:: 439d7ac0879f9fd4c56f212e03477f358133c56c drm/i915: Add support for DRRS
to switch RR
:: TO: Pradeep Bhat
:: CC: Daniel Vetter
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6422 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/8020c425/attachment-0001.obj>
[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts
Hi Jon, On 23 August 2016 at 18:38, Jonathan Corbet wrote: > On Tue, 23 Aug 2016 08:01:35 +0200 > Daniel Vetter wrote: > >> I'm also not too sure about whether dma-buf really should be it's own >> subdirectory. It's plucked from the device-drivers.tmpl, I think an >> overall device-drivers/ for all the misc subsystems and support code would >> be better. Then one toc there, which fans out to either kernel-doc and >> overview docs. > > I'm quite convinced it shouldn't be. > > If you get a chance, could you have a look at the "RFC: The beginning of > a proper driver-api book" series I posted yesterday (yes, I should have > copied more of you, sorry)? It shows the direction I would like to go > with driver API documentation, and, assuming we go that way, I'd like the > dma-buf documentation to fit into that. > Thanks for your comments, and direction. I'll rework the patches on top of yours then. I'll have a look at your patches to think about how do we handle API guides / detailed documentation as well. > Thanks, > > jon Best, Sumit.
[PATCH] drm-misc: Rename drm-misc defconfigs to end with _defconfig
Instead of -defconfig, to be consistent with in-tree naming convention Cc: daniel.vetter at intel.com Cc: sumit.semwal at linaro.org Cc: architt at codeaurora.org Signed-off-by: Sean Paul --- drm-misc-arm64-defconfig => drm-misc-arm64_defconfig | 0 drm-misc-arm-defconfig => drm-misc-arm_defconfig | 0 drm-misc-x86-defconfig => drm-misc-x86_defconfig | 0 3 files changed, 0 insertions(+), 0 deletions(-) rename drm-misc-arm64-defconfig => drm-misc-arm64_defconfig (100%) rename drm-misc-arm-defconfig => drm-misc-arm_defconfig (100%) rename drm-misc-x86-defconfig => drm-misc-x86_defconfig (100%) diff --git a/drm-misc-arm64-defconfig b/drm-misc-arm64_defconfig similarity index 100% rename from drm-misc-arm64-defconfig rename to drm-misc-arm64_defconfig diff --git a/drm-misc-arm-defconfig b/drm-misc-arm_defconfig similarity index 100% rename from drm-misc-arm-defconfig rename to drm-misc-arm_defconfig diff --git a/drm-misc-x86-defconfig b/drm-misc-x86_defconfig similarity index 100% rename from drm-misc-x86-defconfig rename to drm-misc-x86_defconfig -- 2.8.0.rc3.226.g39d4020
[PATCH 1/1] drm/vmwgfx: avoid possible NULL pointer dereference
Hi Heinrich,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.8-rc3 next-20160823]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience) to record what (public, well-known) commit your patch series was
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url:
https://github.com/0day-ci/linux/commits/Heinrich-Schuchardt/drm-vmwgfx-avoid-possible-NULL-pointer-dereference/20160822-051807
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-x016-201634 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c: In function 'vmw_cmd_res_reloc_add':
>> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:656:3: warning: 'return' with no
>> value, in function returning non-void [-Wreturn-type]
return;
^~
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:646:12: note: declared here
static int vmw_cmd_res_reloc_add(struct vmw_private *dev_priv,
^
vim +/return +656 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
640 * @sw_context: Pointer to the software context.
641 * @id_loc: Pointer to where the id that needs translation is located.
642 * @res: Valid pointer to a struct vmw_resource.
643 * @p_val: If non null, a pointer to the struct
vmw_resource_validate_node
644 * used for this resource is returned here.
645 */
646 static int vmw_cmd_res_reloc_add(struct vmw_private *dev_priv,
647 struct vmw_sw_context *sw_context,
648 uint32_t *id_loc,
649 struct vmw_resource *res,
650 struct vmw_resource_val_node **p_val)
651 {
652 int ret;
653 struct vmw_resource_val_node *node;
654
655 if (!p_val)
> 656 return;
657
658 *p_val = NULL;
659
660 ret = vmw_resource_relocation_add(&sw_context->res_relocations,
661res,
662id_loc -
sw_context->buf_start);
663 if (unlikely(ret != 0))
664 return ret;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 32267 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/11424178/attachment-0001.obj>
[Bug 97371] AMDGPU/Iceland amdgpu: failed testing IB on ring 9/10
https://bugs.freedesktop.org/show_bug.cgi?id=97371 --- Comment #11 from Alex Deucher --- The patch will go upstream in the -fixes pull this week. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/4f55d11d/attachment.html>
[Bug 95306] Random Blank(black) screens on "Carrizo"
https://bugs.freedesktop.org/show_bug.cgi?id=95306 --- Comment #9 from Tom --- Created attachment 125978 --> https://bugs.freedesktop.org/attachment.cgi?id=125978&action=edit Xorg.log: Screen blanked during boot. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/9c265afe/attachment.html>
[RESEND PATCH v13 6/7] drm/i915: Move CRTC updating in atomic_commit into it's own hook
Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of intel_atomic_commit_tail()
(intel_atomic_commit() for stable branches) into it's own function, and
add an appropriate display function hook for it.
Based off of Matt Rope's suggestions
Changes since v1:
- Drop pipe_config->base.active check in intel_update_crtcs() since we
check that before calling the function
Signed-off-by: Lyude
Reviewed-by: Matt Roper
[omitting CC for stable, since this patch will need to be changed for
such backports first]
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_display.c | 74 +---
2 files changed, 54 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff96b7a..04b4fd6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -514,6 +514,8 @@ struct drm_i915_display_funcs {
struct drm_atomic_state *old_state);
void (*crtc_disable)(struct intel_crtc_state *old_crtc_state,
struct drm_atomic_state *old_state);
+ void (*update_crtcs)(struct drm_atomic_state *state,
+unsigned int *crtc_vblank_mask);
void (*audio_codec_enable)(struct drm_connector *connector,
struct intel_encoder *encoder,
const struct drm_display_mode
*adjusted_mode);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b10bea6..330df69 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14198,6 +14198,52 @@ static bool needs_vblank_wait(struct intel_crtc_state
*crtc_state)
return false;
}
+static void intel_update_crtc(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ struct drm_crtc_state *old_crtc_state,
+ unsigned int *crtc_vblank_mask)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc_state *pipe_config = to_intel_crtc_state(crtc->state);
+ bool modeset = needs_modeset(crtc->state);
+
+ if (modeset) {
+ update_scanline_offset(intel_crtc);
+ dev_priv->display.crtc_enable(pipe_config, state);
+ } else {
+ intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
+ }
+
+ if (drm_atomic_get_existing_plane_state(state, crtc->primary)) {
+ intel_fbc_enable(
+ intel_crtc, pipe_config,
+ to_intel_plane_state(crtc->primary->state));
+ }
+
+ drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
+
+ if (needs_vblank_wait(pipe_config))
+ *crtc_vblank_mask |= drm_crtc_mask(crtc);
+}
+
+static void intel_update_crtcs(struct drm_atomic_state *state,
+ unsigned int *crtc_vblank_mask)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_crtc_state;
+ int i;
+
+ for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
+ if (!crtc->state->active)
+ continue;
+
+ intel_update_crtc(crtc, state, old_crtc_state,
+ crtc_vblank_mask);
+ }
+}
+
static void intel_atomic_commit_tail(struct drm_atomic_state *state)
{
struct drm_device *dev = state->dev;
@@ -14296,17 +14342,9 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
intel_modeset_verify_disabled(dev);
}
- /* Now enable the clocks, plane, pipe, and connectors that we set up. */
+ /* Complete the events for pipes that have now been disabled */
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
- struct intel_crtc_state *pipe_config =
- to_intel_crtc_state(crtc->state);
-
- if (modeset && crtc->state->active) {
- update_scanline_offset(to_intel_crtc(crtc));
- dev_priv->display.crtc_enable(pipe_config, state);
- }
/* Complete events for now disable pipes here. */
if (modeset && !crtc->state->active && crtc->state->event) {
@@ -14316,21 +14354,11 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
[RESEND PATCH v13 7/7] drm/i915/skl: Update DDB values atomically with wms/plane attrs
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.
The first major change in this patch is skl_update_crtcs(), which
handles ensuring that we order each CRTC update in our atomic commits
properly so that they honor the DDB flush order.
The second major change in this patch is the order in which we flush the
pipes. While the previous order may have worked, it can't be used in
this approach since it no longer will do the right thing. For example,
using the old ddb flush order:
We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
allocation looks like this:
| A | B |xxx|
Since we're performing the ddb updates after performing any CRTC
disablements in intel_atomic_commit_tail(), the space to the right of
pipe B is unallocated.
1. Flush pipes with new allocation contained into old space. None
apply, so we skip this
2. Flush pipes having their allocation reduced, but overlapping with a
previous allocation. None apply, so we also skip this
3. Flush pipes that got more space allocated. This applies to A and B,
giving us the following update order: A, B
This is wrong, since updating pipe A first will cause it to overlap with
B and potentially burst into flames. Our new order (see the code
comments for details) would update the pipes in the proper order: B, A.
As well, we calculate the order for each DDB update during the check
phase, and reference it later in the commit phase when we hit
skl_update_crtcs().
This long overdue patch fixes the rest of the underruns on Skylake.
Changes since v1:
- Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm()
Changes since v2:
- Use the method for updating CRTCs that Ville suggested
- In skl_update_wm(), only copy the watermarks for the crtc that was
passed to us
Changes since v3:
- Small comment fix in skl_ddb_allocation_overlaps()
Changes since v4:
- Remove the second loop in intel_update_crtcs() and use Ville's
suggestion for updating the ddb allocations in the right order
- Get rid of the second loop and just use the ddb state as it updates
to determine what order to update everything in (thanks for the
suggestion Ville)
- Simplify skl_ddb_allocation_overlaps()
- Split actual overlap checking into it's own helper
Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
[omitting CC for stable, since this patch will need to be changed for
such backports first]
Testcase: kms_cursor_legacy
Testcase: plane-all-modeset-transition
Signed-off-by: Lyude
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
Cc: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 93 +---
drivers/gpu/drm/i915/intel_drv.h | 7 ++
drivers/gpu/drm/i915/intel_pm.c | 200 ---
3 files changed, 132 insertions(+), 168 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 330df69..f9273f4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13483,16 +13483,23 @@ static void verify_wm_state(struct drm_crtc *crtc,
hw_entry->start, hw_entry->end);
}
- /* cursor */
- hw_entry = &hw_ddb.plane[pipe][PLANE_CURSOR];
- sw_entry = &sw_ddb->plane[pipe][PLANE_CURSOR];
-
- if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
- DRM_ERROR("mismatch in DDB state pipe %c cursor "
- "(expected (%u,%u), found (%u,%u))\n",
- pipe_name(pipe),
- sw_entry->start, sw_entry->end,
- hw_entry->start, hw_entry->end);
+ /*
+* cursor
+* If the cursor plane isn't active, we may not have updated it's ddb
+* allocation. In that case since the ddb allocation will be updated
+* once the plane becomes visible, we can skip this check
+*/
+ if (intel_crtc->cursor_addr) {
+ hw_entry = &hw_ddb.plane[pipe][PLANE_CURSOR];
+ sw_entry = &sw_ddb->plane[pipe][PLANE_CURSOR];
+
+ if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
+ DRM_ERROR("mismatch in DDB state pipe %c cursor "
+ "(expected (%u,%u), found (%u,%u))\n",
+ pipe_name(pipe),
+ sw_entry->start, sw_entry->end,
+ hw_entry->start, hw_entry->end);
+ }
}
}
@@ -14244,6 +14251,65 @@ static void intel_update_crtcs(struct drm_atomic_state
*state,
}
}
+static void skl_update_crtcs(struct drm_atomic_state *state,
+
[drm-intel:topic/drm-misc 3/3] htmldocs: drivers/gpu/drm/drm_fb_helper.c:1069: warning: No description found for parameter 'suspend'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: cfe63423d9be3e7020296c3dfb512768a83cd099
commit: cfe63423d9be3e7020296c3dfb512768a83cd099 [3/3] drm/fb-helper: Add
drm_fb_helper_set_suspend_unlocked()
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_fb_helper.c:1069: warning: No description found for
>> parameter 'suspend'
>> drivers/gpu/drm/drm_fb_helper.c:1069: warning: Excess function parameter
>> 'state' description in 'drm_fb_helper_set_suspend_unlocked'
drivers/gpu/drm/drm_fb_helper.c:1070: warning: No description found for
parameter 'suspend'
drivers/gpu/drm/drm_fb_helper.c:1070: warning: Excess function parameter
'state' description in 'drm_fb_helper_set_suspend_unlocked'
Documentation/gpu/drm-kms.rst:13: WARNING: Could not lex literal_block as
"C". Highlighting skipped.
Documentation/gpu/drm-kms-helpers.rst:16: WARNING: Could not lex
literal_block as "C". Highlighting skipped.
Documentation/gpu/i915.rst:57: WARNING: Could not lex literal_block as "C".
Highlighting skipped.
Documentation/gpu/drm-internals.rst:286: WARNING: undefined label:
vga_switcheroo (if the link has no caption the label must precede a section
header)
vim +/suspend +1069 drivers/gpu/drm/drm_fb_helper.c
1053 * takes the console lock
1054 * @fb_helper: driver-allocated fbdev helper
1055 * @state: desired state, zero to resume, non-zero to suspend
1056 *
1057 * A wrapper around fb_set_suspend() that takes the console lock. If
the lock
1058 * isn't available on resume, a worker is tasked with waiting for the
lock
1059 * to become available. The console lock can be pretty contented on
resume
1060 * due to all the printk activity.
1061 *
1062 * This function can be called multiple times with the same state since
1063 * &fb_info->state is checked to see if fbdev is running or not before
locking.
1064 *
1065 * Use drm_fb_helper_set_suspend() if you need to take the lock
yourself.
1066 */
1067 void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
1068 int suspend)
> 1069 {
1070 if (!fb_helper || !fb_helper->fbdev)
1071 return;
1072
1073 /* make sure there's no pending/ongoing resume */
1074 flush_work(&fb_helper->resume_work);
1075
1076 if (suspend) {
1077 if (fb_helper->fbdev->state != FBINFO_STATE_RUNNING)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6422 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/78f63634/attachment.obj>
[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts
On Tue, 23 Aug 2016 15:28:55 +0200 Daniel Vetter wrote: > I think the more interesting story is, what's your plan with all the > other driver related subsystem? Especially the ones which already have > full directories of their own, like e.g. Documentation/gpio/. I think > those should be really part of the infrastructure section (or > something equally high-level), together with other awesome servies > like pwm, regman, irqchip, ... And then there's also the large-scale > subsystems like media or gpu. What's the plan to tie them all > together? Personally I'm leaning towards keeping the existing > directories (where they exist already), but inserting links into the > overall driver-api section. To say I have a plan is to overstate things somewhat... One objective I do have, though, is to declutter Documentation/. Presenting people looking for docs with a 270-file directory is unfriendly to say the least. We don't organize the code that way; the average in the kernel is <... find | wc -l ... > about 15 files/directory, which is rather more manageable. Someday I'd like Documentation/ to look a lot more like the top-level directory. It seems to me that we have a few basic types of stuff here: - Driver API documentation, obviously, is a lot of it, and I would like to organize it better and to move it out of the top-level directory. - Hardware usage information - module parameters, sysfs files, supported hardware information, graphic descriptions of the ancestry of hardware engineers, etc. The readership for this stuff is quite different, and I think it should be separate; often it's intertwined with API information at the moment. - Other usage information - a lot of what's under filesystems/ for example, and more. - Core API documentation. - Kernel development tools - the stuff I started pulling together into the dev-tools/ subdirectory. - How to deal with this unruly mob - SubmittingPatches, CodingStyle, development-process, etc. There's process stuff, and general development documents like volatile-considered-harmful.txt or memory-barriers.txt We can go a long way by organizing this stuff within the formatted documentation, but I really think we need to organize the directory structure as well. I see that as a slow-moving process that will take years, but I do think it's a direction we should go. jon
[Bug 91960] [i915] kernel warning hsw_unclaimed_reg_debug intel_uncore.c:619
https://bugs.freedesktop.org/show_bug.cgi?id=91960 --- Comment #7 from Renan Birck --- Ubuntu 16.04 mainline kernel, ASUS Z450LA laptop, has a similar error: Ago 23 11:33:48 alpha kernel: [ cut here ] Ago 23 11:33:48 alpha kernel: WARNING: CPU: 2 PID: 3045 at /mnt/disk2/xenial/drivers/gpu/drm/i915/intel_uncore.c:619 hsw_unclaimed_reg_debug+0x69/0x90 [i915]() Ago 23 11:33:48 alpha kernel: Unclaimed register detected before reading register 0x22384 Ago 23 11:33:48 alpha kernel: Modules linked in: rfcomm msr pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) bnep binfmt_misc nls_iso8859_1 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media btusb btrtl btbcm btintel intel_rapl bluetooth x86_pkg_temp_thermal arc4 intel_powerclamp coretemp snd_hda_codec_hdmi kvm_intel kvm rtl8723be(OE) btcoexist(OE) irqbypass rtl_pci(OE) snd_hda_codec_realtek crct10dif_pclmul rtlwifi(OE) crc32_pclmul mac80211 snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core asus_nb_wmi asus_wmi snd_hwdep snd_pcm sparse_keymap aesni_intel cfg80211 snd_seq_midi snd_seq_midi_event aes_x86_64 lrw snd_rawmidi rtsx_pci_ms snd_seq gf128mul glue_helper memstick ablk_helper cryptd snd_seq_device input_leds joydev serio_raw snd_timer Ago 23 11:33:48 alpha kernel: dw_dmac snd dw_dmac_core soundcore mac_hid mei_me int3402_thermal shpchp 8250_dw snd_soc_sst_acpi mei int3400_thermal processor_thermal_device spi_pxa2xx_platform acpi_thermal_rel int340x_thermal_zone intel_soc_dts_iosf intel_pch_thermal lpc_ich i2c_designware_platform tpm_crb i2c_designware_core acpi_pad parport_pc ppdev lp parport autofs4 hid_generic usbhid hid uas usb_storage rtsx_pci_sdmmc i915 psmouse i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt r8169 ahci fb_sys_fops mii libahci drm rtsx_pci wmi sdhci_acpi video sdhci fjes Ago 23 11:33:48 alpha kernel: CPU: 2 PID: 3045 Comm: Xorg Tainted: G OE 4.4.0-34-generic #53 Ago 23 11:33:48 alpha kernel: Hardware name: ASUSTeK COMPUTER INC. Z450LA/Z450LA, BIOS Z450LA.204 08/12/2015 Ago 23 11:33:48 alpha kernel: 0086 f47942d3 88024ed03cd8 813f11b3 Ago 23 11:33:48 alpha kernel: 88024ed03d20 c025fde0 88024ed03d10 81081102 Ago 23 11:33:48 alpha kernel: 880035ac 00022384 880035ac4568 00022384 Ago 23 11:33:48 alpha kernel: Call Trace: Ago 23 11:33:48 alpha kernel:[] dump_stack+0x63/0x90 Ago 23 11:33:48 alpha kernel: [] warn_slowpath_common+0x82/0xc0 Ago 23 11:33:48 alpha kernel: [] warn_slowpath_fmt+0x5c/0x80 Ago 23 11:33:48 alpha kernel: [] hsw_unclaimed_reg_debug+0x69/0x90 [i915] Ago 23 11:33:48 alpha kernel: [] gen6_read32+0x59/0x1a0 [i915] Ago 23 11:33:48 alpha kernel: [] intel_lrc_irq_handler+0xe5/0x240 [i915] Ago 23 11:33:48 alpha kernel: [] gen8_gt_irq_handler+0x217/0x240 [i915] Ago 23 11:33:48 alpha kernel: [] gen8_irq_handler+0xa1/0x740 [i915] Ago 23 11:33:48 alpha kernel: [] handle_irq_event_percpu+0x8d/0x1d0 Ago 23 11:33:48 alpha kernel: [] handle_irq_event+0x3e/0x60 Ago 23 11:33:48 alpha kernel: [] handle_edge_irq+0x7d/0x150 Ago 23 11:33:48 alpha kernel: [] handle_irq+0x1a/0x30 Ago 23 11:33:48 alpha kernel: [] do_IRQ+0x4b/0xd0 Ago 23 11:33:48 alpha kernel: [] common_interrupt+0x82/0x82 Ago 23 11:33:48 alpha kernel:[] ? gen8_emit_request+0x224/0x320 [i915] Ago 23 11:33:48 alpha kernel: [] __i915_add_request+0x147/0x210 [i915] Ago 23 11:33:48 alpha kernel: [] i915_gem_execbuffer_retire_commands+0x26/0x30 [i915] Ago 23 11:33:48 alpha kernel: [] intel_execlists_submission+0x2eb/0x410 [i915] Ago 23 11:33:48 alpha kernel: [] i915_gem_do_execbuffer.isra.25+0xfa0/0x12a0 [i915] Ago 23 11:33:48 alpha kernel: [] i915_gem_execbuffer2+0xb2/0x240 [i915] Ago 23 11:33:48 alpha kernel: [] ? i915_gem_busy_ioctl+0x92/0xe0 [i915] Ago 23 11:33:48 alpha kernel: [] drm_ioctl+0x152/0x540 [drm] Ago 23 11:33:48 alpha kernel: [] ? i915_gem_execbuffer+0x310/0x310 [i915] Ago 23 11:33:48 alpha kernel: [] do_vfs_ioctl+0x29f/0x490 Ago 23 11:33:48 alpha kernel: [] SyS_ioctl+0x79/0x90 Ago 23 11:33:48 alpha kernel: [] entry_SYSCALL_64_fastpath+0x16/0x71 Ago 23 11:33:48 alpha kernel: ---[ end trace 62f496b552421664 ]--- PID 3045 is Xorg in this case. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/28449294/attachment-0001.html>
[Bug 91960] [i915] kernel warning hsw_unclaimed_reg_debug intel_uncore.c:619
https://bugs.freedesktop.org/show_bug.cgi?id=91960 --- Comment #8 from Renan Birck --- (In reply to Renan Birck from comment #7) > Ubuntu 16.04 mainline kernel, ASUS Z450LA laptop, has a similar error: [...] A correction: it's not the mainline kernel; rather, it's the default kernel rebuilt with a patch to fix this bug: https://bugzilla.kernel.org/show_bug.cgi?id=107971 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/f7e40dea/attachment.html>
[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts
On Tue, Aug 23, 2016 at 08:16:33AM -0600, Jonathan Corbet wrote: > On Tue, 23 Aug 2016 15:28:55 +0200 > Daniel Vetter wrote: > > > I think the more interesting story is, what's your plan with all the > > other driver related subsystem? Especially the ones which already have > > full directories of their own, like e.g. Documentation/gpio/. I think > > those should be really part of the infrastructure section (or > > something equally high-level), together with other awesome servies > > like pwm, regman, irqchip, ... And then there's also the large-scale > > subsystems like media or gpu. What's the plan to tie them all > > together? Personally I'm leaning towards keeping the existing > > directories (where they exist already), but inserting links into the > > overall driver-api section. > > To say I have a plan is to overstate things somewhat... > > One objective I do have, though, is to declutter Documentation/. > Presenting people looking for docs with a 270-file directory is > unfriendly to say the least. We don't organize the code that way; the > average in the kernel is <... find | wc -l ... > about 15 > files/directory, which is rather more manageable. Someday I'd like > Documentation/ to look a lot more like the top-level directory. > > It seems to me that we have a few basic types of stuff here: > > - Driver API documentation, obviously, is a lot of it, and I would like >to organize it better and to move it out of the top-level directory. > > - Hardware usage information - module parameters, sysfs files, supported >hardware information, graphic descriptions of the ancestry of hardware >engineers, etc. The readership for this stuff is quite different, and >I think it should be separate; often it's intertwined with API >information at the moment. > > - Other usage information - a lot of what's under filesystems/ for >example, and more. Hm yeah, I don't have a plan really for what to do with usage docs for users (as opposed to api docs for kernel developers). With DRM comparatively few people end up writing userspace for our apis, hence I think this is a lower priority issue for us. Definitely something I'd like to address eventually. I think for drivers a big part here is documenting the ioctls and all the other uapi bits&pieces. > - Core API documentation. Personally I'm very much interesting in dragging all the locking primitives into the rst/sphinx world. We already make heavy use fo ww_mutex, and we started to make rather heavy use of rcu in drm and drm/i915. I'd like to be able to directly reference these underlying primitives. For KS I'll try to convince Paul that this is an awesome idea ;-) > - Kernel development tools - the stuff I started pulling together into >the dev-tools/ subdirectory. > > - How to deal with this unruly mob - SubmittingPatches, CodingStyle, >development-process, etc. There's process stuff, and general >development documents like volatile-considered-harmful.txt or >memory-barriers.txt tbh I think the process stuff is important enough that we should imo leave it in the top-level Documentation/ directory. Maybe collated together into a contributing.rst index file (besides the top-level index.rst ofc). > We can go a long way by organizing this stuff within the formatted > documentation, but I really think we need to organize the directory > structure as well. I see that as a slow-moving process that will take > years, but I do think it's a direction we should go. Fully agreed on the larger-scale picture, and I think what I've seen thus far from you looks great. Was simply wondering whether you have a more concrete plane for drivers specifically already. I'm wondering whether we should have Documentation/drivers/(gpu|media|...) too, but otoh nesting things too deeply isn't great either. Starting out with a proper driver directory in there is definitely the right step forward though. We can shuffle the other bits into that later on anytime we like really. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 1/2] drm: simple_kms_helper: make connector optional at init time
On Tue, Aug 23, 2016 at 04:05:57PM +0200, Andrea Merello wrote:
> drm_simple_display_pipe_init() pretendes to attach a connector
> to the display pipe.
>
> In case a drm bridge has to be used, then it's the bridge that
> takes care of connectors.
>
> This patch makes the connector parameter optional for
> drm_simple_display_pipe_init(), so that a drm bridge could
> handle connector by itslef later.
>
> Signed-off-by: Andrea Merello
> Cc: David Airlie
> Cc: Noralf Trønnes
> Cc: Daniel Vetter
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 0a02efe..3a48c7c 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -139,7 +139,7 @@ static const struct drm_plane_funcs
> drm_simple_kms_plane_funcs = {
> * @funcs: callbacks for the display pipe (optional)
> * @formats: array of supported formats (%DRM_FORMAT_*)
> * @format_count: number of elements in @formats
> - * @connector: connector to attach and register
> + * @connector: connector to attach and register (optional)
> *
> * Sets up a display pipeline which consist of a really simple
> * plane-crtc-encoder pipe coupled with the provided connector.
I think a few more words when a NULL @connector here would be great,
essentially what you've written already in the changelog. Plus then in
patch 2 add a cross-link here to the new function your adding - that
happens automatically if you append ().
btw pls also check the generated output using
$ make DOCBOOKS="" htmldocs
to make sure the links are all pretty.
-Daniel
> @@ -181,7 +181,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev,
> encoder->possible_crtcs = 1 << drm_crtc_index(crtc);
> ret = drm_encoder_init(dev, encoder, &drm_simple_kms_encoder_funcs,
> DRM_MODE_ENCODER_NONE, NULL);
> - if (ret)
> + if (ret || !connector)
> return ret;
>
> return drm_mode_connector_attach_encoder(connector, encoder);
> --
> 2.7.4
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 2/2] drm: simple_kms_helper: add support for bridges
On Tue, Aug 23, 2016 at 04:08:04PM +0200, Andrea Merello wrote:
> Introduce drm_simple_display_pipe_attach_bridge() in order
> to make it possible to use drm encoders with the simple display
> pipes managed by simple_kms_helpers
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Andrea Merello
> Cc: Noralf Trønnes
> Cc: Daniel Vetter
> Cc: David Airlie
Threading of your patch series is somehow broken, usually that should all
work nicely if you've set up git send-email.
One question: Should we ahve a drm_simple_display_pipe_detach_bridge (for
cleanup) too?
-Daniel
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 3a48c7c..05ee61d 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -133,6 +133,28 @@ static const struct drm_plane_funcs
> drm_simple_kms_plane_funcs = {
> };
>
> /**
> + * drm_simple_display_pipe_attach_bridge - Attach a bridge to the display
> pipe
> + * @pipe: simple display pipe object
> + * @bridge: bridge to attach
> + *
> + * Makes it possible to still use the drm_simple_display_pipe helpers when
> + * a DRM bridge has to be used.
> + * Note that you probably want to initialize the pipe by passing a NULL
> + * connector to drm_simple_display_pipe_init()
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe
> *pipe,
> + struct drm_bridge *bridge)
> +{
> + bridge->encoder = &pipe->encoder;
> + pipe->encoder.bridge = bridge;
> + return drm_bridge_attach(pipe->encoder.dev, bridge);
> +}
> +EXPORT_SYMBOL(drm_simple_display_pipe_attach_bridge);
> +
> +/**
> * drm_simple_display_pipe_init - Initialize a simple display pipeline
> * @dev: DRM device
> * @pipe: simple display pipe object to initialize
> diff --git a/include/drm/drm_simple_kms_helper.h
> b/include/drm/drm_simple_kms_helper.h
> index 2690397..1d73bcf 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -85,6 +85,9 @@ struct drm_simple_display_pipe {
> const struct drm_simple_display_pipe_funcs *funcs;
> };
>
> +int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe
> *pipe,
> + struct drm_bridge *bridge);
> +
> int drm_simple_display_pipe_init(struct drm_device *dev,
> struct drm_simple_display_pipe *pipe,
> const struct drm_simple_display_pipe_funcs *funcs,
> --
> 2.7.4
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] gpu: ipu-v3: fix a possible NULL dereference
On Tue, Aug 16, 2016 at 9:33 AM, LABBE Corentin
wrote:
> of_match_device could return NULL, and so cause a NULL pointer
> dereference later.
>
> For fixing this problem, we use of_device_get_match_data(), this will
> simplify the code a little by using a standard function for
> getting the match data.
>
> Signed-off-by: LABBE Corentin
> ---
> drivers/gpu/ipu-v3/ipu-common.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
> index 99dcacf..05a9cc6 100644
> --- a/drivers/gpu/ipu-v3/ipu-common.c
> +++ b/drivers/gpu/ipu-v3/ipu-common.c
> @@ -1207,15 +1207,13 @@ EXPORT_SYMBOL_GPL(ipu_dump);
>
> static int ipu_probe(struct platform_device *pdev)
> {
> - const struct of_device_id *of_id =
> - of_match_device(imx_ipu_dt_ids, &pdev->dev);
> struct ipu_soc *ipu;
> struct resource *res;
> unsigned long ipu_base;
> int i, ret, irq_sync, irq_err;
> const struct ipu_devtype *devtype;
>
> - devtype = of_id->data;
> + devtype = of_device_get_match_data(&pdev->dev);
While you avoid the of_id dereference, it's possible that
of_device_get_match_data() returns NULL, so you're really just moving
the oops around.
Sean
>
> irq_sync = platform_get_irq(pdev, 0);
> irq_err = platform_get_irq(pdev, 1);
> --
> 2.7.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: introduce bridge detaching mechanism
On Tue, Aug 23, 2016 at 04:10:04PM +0200, Andrea Merello wrote:
> Up to now, once a bridge has been attached to a DRM device, it cannot
> be undone.
>
> In particular you couldn't rmmod/insmod a DRM driver that uses a bridge,
> because the bridge would remain bound to the first (dead) driver instance.
>
> This patch fixes this by introducing drm_encoder_detach() and a ->detach
> callback in drm_bridge_funcs for the bridge to be notified about detaches.
>
> It's DRM/KMS driver responsibility to call drm_encoder_detach().
>
> Suggested-by: Daniel Vetter
> Suggested-by: Lucas Stach
> Signed-off-by: Andrea Merello
> Cc: Archit Taneja
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Lucas Stach
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 2555430..c4ace90 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -125,6 +125,39 @@ int drm_bridge_attach(struct drm_device *dev, struct
> drm_bridge *bridge)
> EXPORT_SYMBOL(drm_bridge_attach);
>
> /**
> + * drm_bridge_detach - deassociate given bridge from its DRM device
> + *
> + * @bridge: bridge control structure
> + *
> + * called by a kms driver to unlink one of our encoder/bridge to the given
> + * bridge.
> + *
> + * Note that tearing down links between the bridge and our encoder/bridge
> + * objects needs to be handled by the kms driver itself
> + *
> + * RETURNS:
> + * Zero on success, error code on failure
> + */
> +int drm_bridge_detach(struct drm_bridge *bridge)
Generally detach/cleanup functions have a return type of void - there's no
way (usually) to bail out on errors anyway.
> +{
> + int ret;
> +
> + if (!bridge || !bridge->dev)
Hence WARN_ON here probably.
> + return -EINVAL;
> +
> + if (bridge->funcs->detach) {
> + ret = bridge->funcs->detach(bridge);
Same for the callback to the backend.
> + if (ret)
> + return ret;
> + }
> +
> + bridge->dev = NULL;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_bridge_detach);
> +
> +/**
> * DOC: bridge callbacks
> *
> * The &drm_bridge_funcs ops are populated by the bridge driver. The DRM
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b618b50..eef4db8 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1766,6 +1766,7 @@ struct drm_plane {
> */
> struct drm_bridge_funcs {
> int (*attach)(struct drm_bridge *bridge);
> + int (*detach)(struct drm_bridge *bridge);
kerneldoc for @detach is missing here. And I think it'd be good to also
make the kerneldoc for @attach a stand-alone comment and flesh it out a
bit.
You might also need to include this into the simple pipe series so that
you can wire up detach support for those helpers too.
Otherwise looks all good I think.
Thanks, Daniel
>
> /**
>* @mode_fixup:
> @@ -3196,6 +3197,7 @@ extern int drm_bridge_add(struct drm_bridge *bridge);
> extern void drm_bridge_remove(struct drm_bridge *bridge);
> extern struct drm_bridge *of_drm_find_bridge(struct device_node *np);
> extern int drm_bridge_attach(struct drm_device *dev, struct drm_bridge
> *bridge);
> +extern int drm_bridge_detach(struct drm_bridge *bridge);
>
> bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
> const struct drm_display_mode *mode,
> --
> 2.7.4
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/fb-helper: Make docs for fb_set_suspend wrappers consistent
I figured I might as well go ocd and make them booleans and rename the
locked version too.
Reported-by: kbuild test robot
Cc: Noralf Trønnes
Fixes: cfe63423d9be ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()")
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 8
include/drm/drm_fb_helper.h | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 10585c462d85..e1af1d08511b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1035,13 +1035,13 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
/**
* drm_fb_helper_set_suspend - wrapper around fb_set_suspend
* @fb_helper: driver-allocated fbdev helper
- * @state: desired state, zero to resume, non-zero to suspend
+ * @suspend: whether to suspend or resume
*
* A wrapper around fb_set_suspend implemented by fbdev core.
* Use drm_fb_helper_set_suspend_unlocked() if you don't need to take
* the lock yourself
*/
-void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state)
+void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool suspend)
{
if (fb_helper && fb_helper->fbdev)
fb_set_suspend(fb_helper->fbdev, state);
@@ -1052,7 +1052,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
* drm_fb_helper_set_suspend_unlocked - wrapper around fb_set_suspend that also
* takes the console lock
* @fb_helper: driver-allocated fbdev helper
- * @state: desired state, zero to resume, non-zero to suspend
+ * @suspend: whether to suspend or resume
*
* A wrapper around fb_set_suspend() that takes the console lock. If the lock
* isn't available on resume, a worker is tasked with waiting for the lock
@@ -1065,7 +1065,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
* Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
*/
void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
- int suspend)
+ bool suspend)
{
if (!fb_helper || !fb_helper->fbdev)
return;
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 0c6e53d9ce68..6c812e3c8bfc 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -265,9 +265,9 @@ void drm_fb_helper_cfb_copyarea(struct fb_info *info,
void drm_fb_helper_cfb_imageblit(struct fb_info *info,
const struct fb_image *image);
-void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state);
+void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool suspend);
void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
- int suspend);
+ bool suspend);
int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
@@ -421,7 +421,7 @@ static inline void drm_fb_helper_cfb_imageblit(struct
fb_info *info,
}
static inline void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper,
-int state)
+bool suspend)
{
}
--
2.9.3
[PATCH] drm/bridge: dw-hdmi: Delete unnecessary assignment for the field "owner"
On Tue, Aug 16, 2016 at 7:58 AM, SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Tue, 16 Aug 2016 13:52:19 +0200
>
> The field "owner" is set by the core.
> Thus delete an unneeded initialisation.
>
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
> Signed-off-by: Markus Elfring
Applied to -misc
Sean
> ---
> drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
> b/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
> index 122bb01..8f2d137 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
> @@ -640,7 +640,6 @@ static struct platform_driver snd_dw_hdmi_driver = {
> .remove = snd_dw_hdmi_remove,
> .driver = {
> .name = DRIVER_NAME,
> - .owner = THIS_MODULE,
> .pm = PM_OPS,
> },
> };
> --
> 2.9.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/rockchip: Delete unnecessary assignment for the field "owner"
On Tue, Aug 16, 2016 at 8:43 AM, SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Tue, 16 Aug 2016 14:25:35 +0200
>
> The field "owner" is set by the core.
> Thus delete an unneeded initialisation.
>
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
> Signed-off-by: Markus Elfring
Applied to -misc
Sean
> ---
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 1 -
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 89aadbf..0e63ee2 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -445,7 +445,6 @@ static struct platform_driver rockchip_dp_driver = {
> .remove = rockchip_dp_remove,
> .driver = {
>.name = "rockchip-dp",
> - .owner = THIS_MODULE,
>.pm = &rockchip_dp_pm_ops,
>.of_match_table = of_match_ptr(rockchip_dp_dt_ids),
> },
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index 919992c..b7f59c4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -305,7 +305,6 @@ static struct platform_driver vop_platform_driver = {
> .remove = vop_remove,
> .driver = {
> .name = "rockchip-vop",
> - .owner = THIS_MODULE,
> .of_match_table = of_match_ptr(vop_driver_dt_match),
> },
> };
> --
> 2.9.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/rockchip: Don't continue trying to enable crtc on failure
On Wed, Aug 17, 2016 at 3:28 AM, Yakir Yang wrote:
> Sean,
>
> On 08/16/2016 07:12 AM, Sean Paul wrote:
>>
>> If vop_enable fails, don't continue on, it causes system hangs.
>>
>> Signed-off-by: Sean Paul
>
>
> Also meet this problem on my Rk3399 Kevin board. VOP just failed to get the
> pm_runtime at resume time, but ï½ï½ï½ï½er still just continue without
> anything
> enable rightly, oops, and then system crashed :(
>
> So this patch looks good to me, and also fix my problem, thanks:
>
> ï¼²ï½
viewed-by: Yakir Yang
> Tested-by: Yakir Yang
>
Applied to -misc
Sean
> Thanks,
> - Yakir
>
>> ---
>>
>> This patch uses the new DRM_DEV_ERROR logging, so it should be applied on
>> top of "[PATCH 2/2] drm/rockchip: Use DRM_DEV_ERROR in vop".
>>
>> Changes in v2:
>> - Escalate dev_err to WARN_ON for clk_enable failures (Daniel
>> Vetter)
>>
>> Sean
>>
>>
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 31
>> -
>> 1 file changed, 17 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index ec8ad00..a176d03 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -428,7 +428,7 @@ static void vop_dsp_hold_valid_irq_disable(struct vop
>> *vop)
>> spin_unlock_irqrestore(&vop->irq_lock, flags);
>> }
>> -static void vop_enable(struct drm_crtc *crtc)
>> +static int vop_enable(struct drm_crtc *crtc)
>> {
>> struct vop *vop = to_vop(crtc);
>> int ret;
>> @@ -436,26 +436,20 @@ static void vop_enable(struct drm_crtc *crtc)
>> ret = pm_runtime_get_sync(vop->dev);
>> if (ret < 0) {
>> dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
>> - return;
>> + goto err_put_pm_runtime;
>> }
>> ret = clk_enable(vop->hclk);
>> - if (ret < 0) {
>> - dev_err(vop->dev, "failed to enable hclk - %d\n", ret);
>> - return;
>> - }
>> + if (WARN_ON(ret < 0))
>> + goto err_put_pm_runtime;
>> ret = clk_enable(vop->dclk);
>> - if (ret < 0) {
>> - dev_err(vop->dev, "failed to enable dclk - %d\n", ret);
>> + if (WARN_ON(ret < 0))
>> goto err_disable_hclk;
>> - }
>> ret = clk_enable(vop->aclk);
>> - if (ret < 0) {
>> - dev_err(vop->dev, "failed to enable aclk - %d\n", ret);
>> + if (WARN_ON(ret < 0))
>> goto err_disable_dclk;
>> - }
>> /*
>> * Slave iommu shares power, irq and clock with vop. It was
>> associated
>> @@ -485,7 +479,7 @@ static void vop_enable(struct drm_crtc *crtc)
>> drm_crtc_vblank_on(crtc);
>> - return;
>> + return 0;
>> err_disable_aclk:
>> clk_disable(vop->aclk);
>> @@ -493,6 +487,9 @@ err_disable_dclk:
>> clk_disable(vop->dclk);
>> err_disable_hclk:
>> clk_disable(vop->hclk);
>> +err_put_pm_runtime:
>> + pm_runtime_put_sync(vop->dev);
>> + return ret;
>> }
>> static void vop_crtc_disable(struct drm_crtc *crtc)
>> @@ -912,10 +909,16 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
>> u16 vact_st = adjusted_mode->vtotal - adjusted_mode->vsync_start;
>> u16 vact_end = vact_st + vdisplay;
>> uint32_t val;
>> + int ret;
>> WARN_ON(vop->event);
>> - vop_enable(crtc);
>> + ret = vop_enable(crtc);
>> + if (ret) {
>> + DRM_DEV_ERROR(vop->dev, "Failed to enable vop (%d)\n",
>> ret);
>> + return;
>> + }
>> +
>> /*
>> * If dclk rate is zero, mean that scanout is stop,
>> * we don't need wait any more.
>
>
>
[PATCH v2] io-mapping.h: s/PAGE_KERNEL_IO/PAGE_KERNEL/
PAGE_KERNEL_IO is an x86-ism. Though it is used to define the pgprot_t
used for the iomapped region, it itself is just PAGE_KERNEL. On all
other arches, PAGE_KERNEL_IO is undefined so in a general header we must
refrain from using it.
v2: include pgtable for pgprot_combine()
Reported-by: Stephen Rothwell
Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about
the io-mapping")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Joonas Lahtinen
Cc: linux-mm at kvack.org
---
include/linux/io-mapping.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index b4c4b5c4216d..a87dd7fffc0a 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -112,7 +112,7 @@ io_mapping_unmap(void __iomem *vaddr)
#else
#include
-#include
+#include
/* Create the io_mapping object*/
static inline struct io_mapping *
@@ -123,7 +123,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
iomap->base = base;
iomap->size = size;
iomap->iomem = ioremap_wc(base, size);
- iomap->prot = pgprot_writecombine(PAGE_KERNEL_IO);
+ iomap->prot = pgprot_writecombine(PAGE_KERNEL);
return iomap;
}
--
2.9.3
[PATCH 2/2] drm: simple_kms_helper: add support for bridges
On Tue, Aug 23, 2016 at 05:39:36PM +0200, Andrea Merello wrote: > On Tue, Aug 23, 2016 at 5:20 PM, Daniel Vetter wrote: > > > On Tue, Aug 23, 2016 at 04:08:04PM +0200, Andrea Merello wrote: > > > Introduce drm_simple_display_pipe_attach_bridge() in order > > > to make it possible to use drm encoders with the simple display > > > pipes managed by simple_kms_helpers > > > > > > Suggested-by: Daniel Vetter > > > Signed-off-by: Andrea Merello > > > Cc: Noralf Trønnes > > > Cc: Daniel Vetter > > > Cc: David Airlie > > > > Threading of your patch series is somehow broken, usually that should all > > work nicely if you've set up git send-email. > > > > One question: Should we ahve a drm_simple_display_pipe_detach_bridge (for > > cleanup) too? > > > > Unsure if it worths. May be nice to have a balanced pair, but it would > probably end up in > a quite redundant one-line func, that only calls drm_bridge_detach with the > very same argument. > > ..But of course if you want I can add it in v2 series. Yes it's just going to be a one-line, but it'll do a typecast and so better encapsulate the internals of the simple pipe helper. I think that's worth it - we have piles&piles of functions and #defines just to make little one-line bits of code a notch more readable. And yes the symmetry is nice too ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 1/4] ARM: dts: exynos: Enable HDMI for Arndale Octa board
* Support HDMI display data channel
I2C #2 is assigned for the HDMI DDC. It enables the EDID access.
* GPIO for HDMI hot plug detect
GPX3_7 is used. The HPD awareness is done when the GPIO is active high and
single ended.
* Enable HDMI block in Exynos5420
HDMI PLL consumes 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator requires
1.8V LDO7 (PVDD_ANAIP_1V8).
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Rob Herring
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Milo Kim
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 39a3b81..df362a2 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -70,6 +70,23 @@
status = "disabled";
};
+&i2c_2 {
+ samsung,i2c-slave-addr = <0x50>;
+ status = "okay";
+
+ hdmiddc at 50 {
+ compatible = "samsung,exynos4210-hdmiddc";
+ reg = <0x50>;
+ };
+};
+
+&hdmi {
+ hpd-gpios = <&gpx3 7 GPIO_OPEN_SOURCE>;
+ vdd_osc-supply = <&ldo7_reg>;
+ vdd_pll-supply = <&ldo6_reg>;
+ status = "okay";
+};
+
&hsi2c_4 {
status = "okay";
--
1.9.1
[PATCH 2/4] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'
This patch enables getting a HPD GPIO descriptor quickly.
The exynos-hdmi driver uses "hpd" for HDMI hot plug detection.
static int hdmi_resources_init(struct hdmi_context *hdata)
{
...
hdata->hpd_gpio = devm_gpiod_get(dev, "hpd", GPIOD_IN);
...
}
This calls 'of_find_gpio()' and it generates the GPIO consumer ID by referring
GPIO suffix. So 'hpd-gpios' is preferred on getting a GPIO descriptor.
However, if the device tree uses 'hpd-gpio', then the exynos-hdmi driver
always retries to get a GPIO descriptor because the first GPIO suffix is not
'gpio' but 'gpios'. So you always see the debug message below.
of_get_named_gpiod_flags: can't parse 'hpd-gpios' property of node
'/soc/hdmi at 1453[0]'
Use the preferred property, 'hpd-gpios' instead of 'hpd-gpio'.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Rob Herring
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Milo Kim
---
Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 4 ++--
arch/arm/boot/dts/exynos4210-universal_c210.dts | 2 +-
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 2 +-
arch/arm/boot/dts/exynos5250-arndale.dts | 2 +-
arch/arm/boot/dts/exynos5250-smdk5250.dts| 2 +-
arch/arm/boot/dts/exynos5250-snow-common.dtsi| 2 +-
arch/arm/boot/dts/exynos5250-spring.dts | 2 +-
arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 +-
arch/arm/boot/dts/exynos5420-smdk5420.dts| 2 +-
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 2 +-
arch/arm/boot/dts/exynos5800-peach-pi.dts| 2 +-
11 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
index a2ec4c1..6394ea9 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
@@ -9,7 +9,7 @@ Required properties:
- reg: physical base address of the hdmi and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
-- hpd-gpio: following information about the hotplug gpio pin.
+- hpd-gpios: following information about the hotplug gpio pin.
a) phandle of the gpio controller node.
b) pin number within the gpio controller.
c) optional flags and pull up/down.
@@ -56,7 +56,7 @@ Example:
compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
- hpd-gpio = <&gpx3 7 1>;
+ hpd-gpios = <&gpx3 7 1>;
ddc = <&hdmi_ddc_node>;
phy = <&hdmi_phy_node>;
samsung,syscon-phandle = <&pmu_system_controller>;
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 9a75e3e..cf95202 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -269,7 +269,7 @@
};
&hdmi {
- hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_hpd>;
hdmi-en-supply = <&hdmi_en>;
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 58ad48e7..be644fe 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -227,7 +227,7 @@
};
&hdmi {
- hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_hpd>;
vdd-supply = <&ldo8_reg>;
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index ea70603..3d981f3 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -152,7 +152,7 @@
};
&hdmi {
- hpd-gpio = <&gpx3 7 GPIO_ACTIVE_LOW>;
+ hpd-gpios = <&gpx3 7 GPIO_ACTIVE_LOW>;
vdd_osc-supply = <&ldo10_reg>;
vdd_pll-supply = <&ldo8_reg>;
vdd-supply = <&ldo8_reg>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 381af13..7f27263 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -116,7 +116,7 @@
};
&hdmi {
- hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
};
&i2c_0 {
diff --git a/arch/arm/boot/dts/exynos5250-snow-
[PATCH 3/4] gpu: drm: exynos_hdmi: Use consolidated function on binding DDC DT property
Handle legacy and raw 'ddc' parsing in single function.
And it also removes goto condition.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Rob Herring
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Milo Kim
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2275efe..6a636f2 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1760,7 +1760,7 @@ static const struct component_ops hdmi_component_ops = {
.unbind = hdmi_unbind,
};
-static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
+static struct device_node *hdmi_ddc_dt_binding(struct device *dev)
{
const char *compatible_str = "samsung,exynos4210-hdmiddc";
struct device_node *np;
@@ -1769,7 +1769,13 @@ static struct device_node
*hdmi_legacy_ddc_dt_binding(struct device *dev)
if (np)
return of_get_next_parent(np);
- return NULL;
+ np = of_parse_phandle(dev->of_node, "ddc", 0);
+ if (!np)
+ return NULL;
+
+ of_node_put(dev->of_node);
+
+ return np;
}
static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
@@ -1811,18 +1817,12 @@ static int hdmi_probe(struct platform_device *pdev)
return ret;
}
- ddc_node = hdmi_legacy_ddc_dt_binding(dev);
- if (ddc_node)
- goto out_get_ddc_adpt;
-
- ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
+ ddc_node = hdmi_ddc_dt_binding(dev);
if (!ddc_node) {
DRM_ERROR("Failed to find ddc node in device tree\n");
return -ENODEV;
}
- of_node_put(dev->of_node);
-out_get_ddc_adpt:
hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
if (!hdata->ddc_adpt) {
DRM_ERROR("Failed to get ddc i2c adapter by node\n");
--
1.9.1
[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts
Am 23.08.2016 um 08:01 schrieb Daniel Vetter : > On Mon, Aug 22, 2016 at 12:49:30PM -0300, Mauro Carvalho Chehab wrote: >> Em Mon, 22 Aug 2016 20:41:45 +0530 >> Sumit Semwal escreveu: >> >>> Include dma-buf sphinx documentation into top level index. >>> >>> Signed-off-by: Sumit Semwal >>> --- >>> Documentation/index.rst | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/Documentation/index.rst b/Documentation/index.rst >>> index e0fc72963e87..8d05070122c2 100644 >>> --- a/Documentation/index.rst >>> +++ b/Documentation/index.rst >>> @@ -14,6 +14,8 @@ Contents: >>>:maxdepth: 2 >>> >>>kernel-documentation >>> + dma-buf/intro >>> + dma-buf/guide >>>media/media_uapi >>>media/media_kapi >>>media/dvb-drivers/index >> >> IMHO, the best would be, instead, to add an index with a toctree >> with both intro and guide, and add dma-buf/index instead. >> >> We did that for media too (patches not merged upstream yet), together >> with a patchset that will allow building just a subset of the books. Since 606b9ac, one more *pro* of a index.rst file in a sub-folder is, that you can reduce your roundtrips. Add a conf.py to your subfolder and compile only your sub-folder with e.g. make SPHINXDIRS="dma-buf" htmldocs * http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=606b9ac81a63ab3adb7e61206b9ae34ee186a89d One / the example (Mauro mentioned) is media commit b32feba * http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=b32febad77068b4a28daf7b7e063438d0cca8a42 > I'm also not too sure about whether dma-buf really should be it's own > subdirectory. It's plucked from the device-drivers.tmpl, I think an > overall device-drivers/ for all the misc subsystems and support code would > be better. If the sub-folder named 'device-drivers' use: make SPHINXDIRS="device-drivers" htmldocs -- Markus -- > Then one toc there, which fans out to either kernel-doc and > overview docs. > -Daniel > >> >> Regards, >> Mauro >> >> PS.: That's the content of our index.rst file, at >> Documentation/media/index.rst: >> >> Linux Media Subsystem Documentation >> === >> >> Contents: >> >> .. toctree:: >> :maxdepth: 2 >> >> media_uapi >> media_kapi >> dvb-drivers/index >> v4l-drivers/index >> >> .. only:: subproject >> >> Indices >> === >> >> * :ref:`genindex` >> >> >> Thanks, >> Mauro >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
[PATCH] drm/doc: Document uapi requirements in DRM
Everyone knows them, except all the new folks joining from the ARM side haven't lived through all the pain of the past years and are entirely surprised when I raise this. Definitely time to document this. Last time this was a big discussion was about 6 years ago, when qcom tried to land a kernel driver without userspace. Dave Airlie made the rules really clear: http://airlied.livejournal.com/73115.html This write-up here is essentially what I've put into a presentation a while ago, which was also reviewed by Dave: http://blog.ffwll.ch/2015/05/gfx-kernel-upstreaming-requirements.html v2: Fix typos Eric&Rob spotted. v3: Nitpick from Jani. Cc: Dave Airlie Cc: Oded Gabbay Cc: Russell King Cc: Tomi Valkeinen Cc: Eric Anholt Cc: Thomas Hellstrom Cc: Sinclair Yeh Cc: Lucas Stach Cc: Benjamin Gaignard Cc: Mark Yao Cc: Laurent Pinchart Cc: Ben Skeggs Cc: Rob Clark Cc: CK Hu Cc: Xinliang Liu Cc: Philipp Zabel Cc: Stefan Agner Cc: Inki Dae Cc: Maxime Ripard Cc: Boris Brezillon Cc: Jani Nikula Cc: Daniel Vetter Cc: Thierry Reding Cc: Christian König Cc: Alex Deucher Cc: Gerd Hoffmann Cc: Brian Starkey Cc: Liviu Dudau Cc: Alexey Brodkin Acked-by: Dave Airlie Reviewed-by: Rob Clark Reviewed-by: Christian König Reviewed-by: Eric Anholt Reviewed-by: Jani Nikula Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-uapi.rst | 67 ++ 1 file changed, 67 insertions(+) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 94876938aef3..12b47c30fe2e 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -36,6 +36,73 @@ Primary Nodes, DRM Master and Authentication Open-Source Userspace Requirements == +The DRM subsystem has stricter requirements than most other kernel subsystems on +what the userspace side for new uAPI needs to look like. This section here +explains what exactly those requirements are, and why they exist. + +The short summary is that any addition of DRM uAPI requires corresponding +open-sourced userspace patches, and those patches must be reviewed and ready for +merging into a suitable and canonical upstream project. + +GFX devices (both display and render/GPU side) are really complex bits of +hardware, with userspace and kernel by necessity having to work together really +closely. The interfaces, for rendering and modesetting, must be extremely wide +and flexible, and therefore it is almost always impossible to precisely define +them for every possible corner case. This in turn makes it really practically +infeasible to differentiate between behaviour that's required by userspace, and +which must not be changed to avoid regressions, and behaviour which is only an +accidental artifact of the current implementation. + +Without access to the full source code of all userspace users that means it +becomes impossible to change the implementation details, since userspace could +depend upon the accidental behaviour of the current implementation in minute +details. And debugging such regressions without access to source code is pretty +much impossible. As a consequence this means: + +- The Linux kernel's "no regression" policy holds in practice only for + open-source userspace of the DRM subsystem. DRM developers are perfectly fine + if closed-source blob drivers in userspace use the same uAPI as the open + drivers, but they must do so in the exact same way as the open drivers. + Creative (ab)use of the interfaces will, and in the past routinely has, lead + to breakage. + +- Any new userspace interface must have an open-source implementation as + demonstration vehicle. + +The other reason for requiring open-source userspace is uAPI review. Since the +kernel and userspace parts of a GFX stack must work together so closely, code +review can only assess whether a new interface achieves its goals by looking at +both sides. Making sure that the interface indeed covers the use-case fully +leads to a few additional requirements: + +- The open-source userspace must not be a toy/test application, but the real + thing. Specifically it needs to handle all the usual error and corner cases. + These are often the places where new uAPI falls apart and hence essential to + assess the fitness of a proposed interface. + +- The userspace side must be fully reviewed and tested to the standards of that + userspace project. For e.g. mesa this means piglit testcases and review on the + mailing list. This is again to ensure that the new interface actually gets the + job done. + +- The userspace patches must be against the canonical upstream, not some vendor + fork. This is to make sure that no one cheats on the review and testing + requirements by doing a quick fork. + +- The kernel patch can only be merged after all the above requirements are met, + but it **must** be merged **before** the userspace patches land. uAPI always flows + from the k
[PATCH 2/2] drm: simple_kms_helper: add support for bridges
Introduce drm_simple_display_pipe_attach_bridge() in order
to make it possible to use drm encoders with the simple display
pipes managed by simple_kms_helpers
Suggested-by: Daniel Vetter
Signed-off-by: Andrea Merello
Cc: Noralf Trønnes
Cc: Daniel Vetter
Cc: David Airlie
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 3a48c7c..05ee61d 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -133,6 +133,28 @@ static const struct drm_plane_funcs
drm_simple_kms_plane_funcs = {
};
/**
+ * drm_simple_display_pipe_attach_bridge - Attach a bridge to the display pipe
+ * @pipe: simple display pipe object
+ * @bridge: bridge to attach
+ *
+ * Makes it possible to still use the drm_simple_display_pipe helpers when
+ * a DRM bridge has to be used.
+ * Note that you probably want to initialize the pipe by passing a NULL
+ * connector to drm_simple_display_pipe_init()
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe *pipe,
+ struct drm_bridge *bridge)
+{
+ bridge->encoder = &pipe->encoder;
+ pipe->encoder.bridge = bridge;
+ return drm_bridge_attach(pipe->encoder.dev, bridge);
+}
+EXPORT_SYMBOL(drm_simple_display_pipe_attach_bridge);
+
+/**
* drm_simple_display_pipe_init - Initialize a simple display pipeline
* @dev: DRM device
* @pipe: simple display pipe object to initialize
diff --git a/include/drm/drm_simple_kms_helper.h
b/include/drm/drm_simple_kms_helper.h
index 2690397..1d73bcf 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -85,6 +85,9 @@ struct drm_simple_display_pipe {
const struct drm_simple_display_pipe_funcs *funcs;
};
+int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe *pipe,
+ struct drm_bridge *bridge);
+
int drm_simple_display_pipe_init(struct drm_device *dev,
struct drm_simple_display_pipe *pipe,
const struct drm_simple_display_pipe_funcs *funcs,
--
2.7.4
[PATCH] drm/fsl-dcu: Fix endian issue when using clk_register_divider
> >>fsl_dev->pix_clk = clk_register_divider(dev, pix_clk_name, > >>pix_clk_in_name, 0, base + DCU_DIV_RATIO, > >> - 0, 8, CLK_DIVIDER_ROUND_CLOSEST, NULL); > >> + 24, 8, CLK_DIVIDER_ROUND_CLOSEST, NULL); > > > > Tested-by: Meng Yi > > > > On LS1021A-TWR board. > > Yeah I wanted to give this a try on Vybrid, but I don't think that works > since on > Vybrid the IP is little endian... > > We need to come up with a solution which takes that into account. > Alternatively we can put the offset into the SoC specific structure... > Ok, I will do this these days. Best Regards, Meng
[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code
On 08/23/16 09:59, Russell King - ARM Linux wrote:
> On Tue, Aug 23, 2016 at 09:21:17AM +0200, Hans Verkuil wrote:
>> Hi Russell,
>>
>> On 08/12/2016 04:15 PM, Russell King wrote:
>>> Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC
>>> implementation.
>>>
>>> Signed-off-by: Russell King
>>> ---
>>> drivers/gpu/drm/bridge/Kconfig| 7 +
>>> drivers/gpu/drm/bridge/Makefile | 1 +
>>> drivers/gpu/drm/bridge/dw-hdmi-cec.c | 344
>>> ++
>>> drivers/gpu/drm/bridge/dw-hdmi.c | 64 +-
>>> include/linux/platform_data/dw_hdmi-cec.h | 16 ++
>>> 5 files changed, 421 insertions(+), 11 deletions(-)
>>> create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-cec.c
>>> create mode 100644 include/linux/platform_data/dw_hdmi-cec.h
>>>
>>
>>
>>
>>> +static unsigned int parse_hdmi_addr(const struct edid *edid)
>>> +{
>>> + if (!edid || edid->extensions == 0)
>>> + return (u16)~0;
>>> +
>>> + return cec_get_edid_phys_addr((u8 *)edid,
>>> + EDID_LENGTH * (edid->extensions + 1), NULL);
>>> +}
>>> +
>>> +static int dw_hdmi_cec_notify(struct notifier_block *nb, unsigned long
>>> event,
>>> + void *data)
>>> +{
>>> + struct dw_hdmi_cec *cec = container_of(nb, struct dw_hdmi_cec, nb);
>>> + union hdmi_event *event_block = data;
>>> + unsigned int phys;
>>> +
>>> + dev_info(event_block->base.source, "event %lu\n", event);
>>> +
>>> + if (event_block->base.source != cec->adap->devnode.parent)
>>> + return NOTIFY_OK;
>>> +
>>> + switch (event) {
>>> + case HDMI_CONNECTED:
>>> + break;
>>> +
>>> + case HDMI_DISCONNECTED:
>>> + cec_s_phys_addr(cec->adap, CEC_PHYS_ADDR_INVALID, false);
>>> + break;
>>> +
>>> + case HDMI_NEW_EDID:
>>> + phys = parse_hdmi_addr(event_block->edid.edid);
>>> + cec_s_phys_addr(cec->adap, phys, false);
>>> + break;
>>> + }
>>> +
>>> + return NOTIFY_OK;
>>> +}
>>
>> Wouldn't it make a lot of sense to integrate this into the cec framework?
>>
>> All you need is to pass an hdmi_notifier_dev as argument to
>> cec_allocate_adapter()
>> and you can integrate this.
>>
>> If you are OK with that, then I can make patches for that.
>
> It's not just about CEC. It's also used for passing information between
> the video and audio parts, so tying this into CEC is wrong.
I'm not saying that the hdmi notifier should be integrated, just that the
CEC core can register itself as a notifier and handle cec_s_phys_addr.
Regards,
Hans
[PATCH 4/4] gpu: drm: exynos_hdmi: Use consolidated function on binding PHY DT property
Handle legacy and raw 'phy' parsing in single function.
And it also removes goto condition.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Rob Herring
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Milo Kim
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 6a636f2..bb2d6d4 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1778,11 +1778,22 @@ static struct device_node *hdmi_ddc_dt_binding(struct
device *dev)
return np;
}
-static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
+static struct device_node *hdmi_phy_dt_binding(struct device *dev)
{
const char *compatible_str = "samsung,exynos4212-hdmiphy";
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, compatible_str);
+ if (np)
+ return np;
+
+ np = of_parse_phandle(dev->of_node, "phy", 0);
+ if (!np)
+ return NULL;
+
+ of_node_put(dev->of_node);
- return of_find_compatible_node(NULL, NULL, compatible_str);
+ return np;
}
static int hdmi_probe(struct platform_device *pdev)
@@ -1829,19 +1840,13 @@ static int hdmi_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
- phy_node = hdmi_legacy_phy_dt_binding(dev);
- if (phy_node)
- goto out_get_phy_port;
-
- phy_node = of_parse_phandle(dev->of_node, "phy", 0);
+ phy_node = hdmi_phy_dt_binding(dev);
if (!phy_node) {
DRM_ERROR("Failed to find hdmiphy node in device tree\n");
ret = -ENODEV;
goto err_ddc;
}
- of_node_put(dev->of_node);
-out_get_phy_port:
if (hdata->drv_data->is_apb_phy) {
hdata->regs_hdmiphy = of_iomap(phy_node, 0);
if (!hdata->regs_hdmiphy) {
--
1.9.1
[PATCH] drm/bridge: introduce bridge detaching mechanism
Up to now, once a bridge has been attached to a DRM device, it cannot
be undone.
In particular you couldn't rmmod/insmod a DRM driver that uses a bridge,
because the bridge would remain bound to the first (dead) driver instance.
This patch fixes this by introducing drm_encoder_detach() and a ->detach
callback in drm_bridge_funcs for the bridge to be notified about detaches.
It's DRM/KMS driver responsibility to call drm_encoder_detach().
Suggested-by: Daniel Vetter
Suggested-by: Lucas Stach
Signed-off-by: Andrea Merello
Cc: Archit Taneja
Cc: David Airlie
Cc: Daniel Vetter
Cc: Lucas Stach
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 2555430..c4ace90 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -125,6 +125,39 @@ int drm_bridge_attach(struct drm_device *dev, struct
drm_bridge *bridge)
EXPORT_SYMBOL(drm_bridge_attach);
/**
+ * drm_bridge_detach - deassociate given bridge from its DRM device
+ *
+ * @bridge: bridge control structure
+ *
+ * called by a kms driver to unlink one of our encoder/bridge to the given
+ * bridge.
+ *
+ * Note that tearing down links between the bridge and our encoder/bridge
+ * objects needs to be handled by the kms driver itself
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
+ */
+int drm_bridge_detach(struct drm_bridge *bridge)
+{
+ int ret;
+
+ if (!bridge || !bridge->dev)
+ return -EINVAL;
+
+ if (bridge->funcs->detach) {
+ ret = bridge->funcs->detach(bridge);
+ if (ret)
+ return ret;
+ }
+
+ bridge->dev = NULL;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_bridge_detach);
+
+/**
* DOC: bridge callbacks
*
* The &drm_bridge_funcs ops are populated by the bridge driver. The DRM
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b618b50..eef4db8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1766,6 +1766,7 @@ struct drm_plane {
*/
struct drm_bridge_funcs {
int (*attach)(struct drm_bridge *bridge);
+ int (*detach)(struct drm_bridge *bridge);
/**
* @mode_fixup:
@@ -3196,6 +3197,7 @@ extern int drm_bridge_add(struct drm_bridge *bridge);
extern void drm_bridge_remove(struct drm_bridge *bridge);
extern struct drm_bridge *of_drm_find_bridge(struct device_node *np);
extern int drm_bridge_attach(struct drm_device *dev, struct drm_bridge
*bridge);
+extern int drm_bridge_detach(struct drm_bridge *bridge);
bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
--
2.7.4
[PATCH 2/2] drm: simple_kms_helper: add support for bridges
On Tue, Aug 23, 2016 at 5:20 PM, Daniel Vetter wrote:
> On Tue, Aug 23, 2016 at 04:08:04PM +0200, Andrea Merello wrote:
> > Introduce drm_simple_display_pipe_attach_bridge() in order
> > to make it possible to use drm encoders with the simple display
> > pipes managed by simple_kms_helpers
> >
> > Suggested-by: Daniel Vetter
> > Signed-off-by: Andrea Merello
> > Cc: Noralf Trønnes
> > Cc: Daniel Vetter
> > Cc: David Airlie
>
> Threading of your patch series is somehow broken, usually that should all
> work nicely if you've set up git send-email.
>
> One question: Should we ahve a drm_simple_display_pipe_detach_bridge (for
> cleanup) too?
>
Unsure if it worths. May be nice to have a balanced pair, but it would
probably end up in
a quite redundant one-line func, that only calls drm_bridge_detach with the
very same argument.
..But of course if you want I can add it in v2 series.
(ACK for all other things)
Andrea
> -Daniel
>
> >
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index 3a48c7c..05ee61d 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -133,6 +133,28 @@ static const struct drm_plane_funcs
> drm_simple_kms_plane_funcs = {
> > };
> >
> > /**
> > + * drm_simple_display_pipe_attach_bridge - Attach a bridge to the
> display pipe
> > + * @pipe: simple display pipe object
> > + * @bridge: bridge to attach
> > + *
> > + * Makes it possible to still use the drm_simple_display_pipe helpers
> when
> > + * a DRM bridge has to be used.
> > + * Note that you probably want to initialize the pipe by passing a NULL
> > + * connector to drm_simple_display_pipe_init()
> > + *
> > + * Returns:
> > + * Zero on success, negative error code on failure.
> > + */
> > +int drm_simple_display_pipe_attach_bridge(struct
> drm_simple_display_pipe *pipe,
> > + struct drm_bridge *bridge)
> > +{
> > + bridge->encoder = &pipe->encoder;
> > + pipe->encoder.bridge = bridge;
> > + return drm_bridge_attach(pipe->encoder.dev, bridge);
> > +}
> > +EXPORT_SYMBOL(drm_simple_display_pipe_attach_bridge);
> > +
> > +/**
> > * drm_simple_display_pipe_init - Initialize a simple display pipeline
> > * @dev: DRM device
> > * @pipe: simple display pipe object to initialize
> > diff --git a/include/drm/drm_simple_kms_helper.h
> b/include/drm/drm_simple_kms_helper.h
> > index 2690397..1d73bcf 100644
> > --- a/include/drm/drm_simple_kms_helper.h
> > +++ b/include/drm/drm_simple_kms_helper.h
> > @@ -85,6 +85,9 @@ struct drm_simple_display_pipe {
> > const struct drm_simple_display_pipe_funcs *funcs;
> > };
> >
> > +int drm_simple_display_pipe_attach_bridge(struct
> drm_simple_display_pipe *pipe,
> > + struct drm_bridge *bridge);
> > +
> > int drm_simple_display_pipe_init(struct drm_device *dev,
> > struct drm_simple_display_pipe *pipe,
> > const struct drm_simple_display_pipe_funcs *funcs,
> > --
> > 2.7.4
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/2e28e30d/attachment-0001.html>
[PATCH 0/4] ARM: dts: exynos: Enable HDMI in Arndale Octa board
This patch-set enables HDMI in Arndale Octa board and fixes HPD DT property. It also includes code refactoring on ddc and phy. Milo Kim (4): ARM: dts: exynos: Enable HDMI for Arndale Octa board ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio' gpu: drm: exynos_hdmi: Use consolidated function on binding DDC DT property gpu: drm: exynos_hdmi: Use consolidated function on binding PHY DT property .../bindings/display/exynos/exynos_hdmi.txt| 4 +-- arch/arm/boot/dts/exynos4210-universal_c210.dts| 2 +- arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 2 +- arch/arm/boot/dts/exynos5250-arndale.dts | 2 +- arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +- arch/arm/boot/dts/exynos5250-snow-common.dtsi | 2 +- arch/arm/boot/dts/exynos5250-spring.dts| 2 +- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 17 + arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 +- arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 +- arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 2 +- arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 41 -- 13 files changed, 52 insertions(+), 30 deletions(-) -- 1.9.1
[PATCH 1/2] drm: simple_kms_helper: make connector optional at init time
drm_simple_display_pipe_init() pretendes to attach a connector
to the display pipe.
In case a drm bridge has to be used, then it's the bridge that
takes care of connectors.
This patch makes the connector parameter optional for
drm_simple_display_pipe_init(), so that a drm bridge could
handle connector by itslef later.
Signed-off-by: Andrea Merello
Cc: David Airlie
Cc: Noralf Trønnes
Cc: Daniel Vetter
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 0a02efe..3a48c7c 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -139,7 +139,7 @@ static const struct drm_plane_funcs
drm_simple_kms_plane_funcs = {
* @funcs: callbacks for the display pipe (optional)
* @formats: array of supported formats (%DRM_FORMAT_*)
* @format_count: number of elements in @formats
- * @connector: connector to attach and register
+ * @connector: connector to attach and register (optional)
*
* Sets up a display pipeline which consist of a really simple
* plane-crtc-encoder pipe coupled with the provided connector.
@@ -181,7 +181,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev,
encoder->possible_crtcs = 1 << drm_crtc_index(crtc);
ret = drm_encoder_init(dev, encoder, &drm_simple_kms_encoder_funcs,
DRM_MODE_ENCODER_NONE, NULL);
- if (ret)
+ if (ret || !connector)
return ret;
return drm_mode_connector_attach_encoder(connector, encoder);
--
2.7.4
[GIT PULL] drm/rockchip: Support rk3399/PSR + fixes
Hi Dave, This pull request contains the following rockchip drm changes: - Introduce support for rk3399 vop/crtc - Add PSR framework to the rockchip driver - Implement PSR in the rockchip analogix edp driver - Fix panel on/off in analogix to avoid damaging panels - Some miscellaneous fixes to clean up logs and code readability Sean The following changes since commit fc93ff608b15ae32cde3006b7af860b59cac20ec: Merge tag 'drm-intel-next-2016-08-08' of git://anongit.freedesktop.org/drm-intel into drm-next (2016-08-15 16:53:57 +1000) are available in the git repository at: ssh://people.freedesktop.org/~seanpaul/dogwood for-next for you to fetch changes up to 808263393198b9b0f9d53b9983330fb4298851ec: drm/rockchip: analogix_dp: drop unnecessary probe deferral "error" print (2016-08-23 11:44:37 -0400) Brian Norris (1): drm/rockchip: analogix_dp: drop unnecessary probe deferral "error" print Mark Yao (5): drm/rockchip: sort registers define by chip's number drm/rockchip: vop: introduce VOP_REG_MASK drm/rockchip: vop: add rk3399 vop support dt-bindings: sort Rockchip vop compatible by chip's number dt-bindings: add compatible strings for big/little rockchip vops Sean Paul (7): drm/bridge: analogix_dp: Ensure the panel is properly prepared/unprepared drm/rockchip: Convert psr_list_mutex to spinlock and use it drm/rockchip: Don't use a delayed worker for psr state changes drm/rockchip: Use a spinlock to protect psr state drm/rockchip: A couple small fixes to psr drm/rockchip: Improve analogix-dp psr handling drm/rockchip: Enable vblank without event Yakir Yang (4): drm/rockchip: vop: export line flag function drm/rockchip: add an common abstracted PSR driver drm/bridge: analogix_dp: add the PSR function support drm/rockchip: analogix_dp: implement PSR function .../bindings/display/rockchip/rockchip-vop.txt | 4 +- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 182 ++- drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 + drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 51 + drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 34 +++ drivers/gpu/drm/rockchip/Makefile | 2 +- drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 70 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 3 + drivers/gpu/drm/rockchip/rockchip_drm_drv.h| 6 + drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 12 + drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 245 + drivers/gpu/drm/rockchip/rockchip_drm_psr.h| 26 +++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 198 ++--- drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 7 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 242 ++-- drivers/gpu/drm/rockchip/rockchip_vop_reg.h| 193 include/drm/bridge/analogix_dp.h | 3 + 17 files changed, 1168 insertions(+), 118 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h
[PATCH] gpu: ipu-v3: fix a possible NULL dereference
On 23/08/2016 17:24, Sean Paul wrote:
> On Tue, Aug 16, 2016 at 9:33 AM, LABBE Corentin
> wrote:
>> of_match_device could return NULL, and so cause a NULL pointer
>> dereference later.
>>
>> For fixing this problem, we use of_device_get_match_data(), this will
>> simplify the code a little by using a standard function for
>> getting the match data.
>>
>> Signed-off-by: LABBE Corentin
>> ---
>> drivers/gpu/ipu-v3/ipu-common.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/ipu-v3/ipu-common.c
>> b/drivers/gpu/ipu-v3/ipu-common.c
>> index 99dcacf..05a9cc6 100644
>> --- a/drivers/gpu/ipu-v3/ipu-common.c
>> +++ b/drivers/gpu/ipu-v3/ipu-common.c
>> @@ -1207,15 +1207,13 @@ EXPORT_SYMBOL_GPL(ipu_dump);
>>
>> static int ipu_probe(struct platform_device *pdev)
>> {
>> - const struct of_device_id *of_id =
>> - of_match_device(imx_ipu_dt_ids, &pdev->dev);
>> struct ipu_soc *ipu;
>> struct resource *res;
>> unsigned long ipu_base;
>> int i, ret, irq_sync, irq_err;
>> const struct ipu_devtype *devtype;
>>
>> - devtype = of_id->data;
>> + devtype = of_device_get_match_data(&pdev->dev);
>
> While you avoid the of_id dereference, it's possible that
> of_device_get_match_data() returns NULL, so you're really just moving
> the oops around.
>
> Sean
>
Hello
I apologize for didnt seen that, I will send an updated patch which fix that.
Regards
[PATCH 0/3] drm/tilcdc: Some fixes for LCDC rev1
Thanks a lot! This is very helpful as I do not have LCDC rev1 HW my self, but only am335x based boards. On 08/23/16 15:56, Karl Beldan wrote: > Hi, > > I found some missing bits for rev1 of the LCDC and here are some of the > changes I am using to use the DRM driver on an LCDCK (which has a rev1). > 1/3 seems required by rev1 of the IP and without it my the LCDC on my > LCDK keeps can't sync, 2/3 is required by the driver logic, while 3/3 > is less of a requirement. I'll drop 3/3, because my recent patches should take care of that: http://www.spinics.net/lists/devicetree/msg138885.html However, there will be v2 round of those patches. Only the DT binding and its default value should change. > Although 1,2/3 would have fitted drm-fixes I based them on drm-next as > 2/3 would conflict with the recent changes in drm-next. > I'll pick these two up for my next pull request. Thanks! > Another thing which is also an absolute requirement for the rev1 but > with which rev2 seems to cope fine is the palette loading (even if the DRM > uses >= 16bpp formats), dixit the TRM: > "12-, 16-, and 24-BPP modes do not need a palette; i.e., the pixel data is > the desired RGB value. However, the first 32 bytes are still considered a > palette. The first entry should be 4000h (bit 14 is 1) while the remaining > entries must be filled with 0.". > ATM I am using a local crude way of loading the palette to verify the > missing bits to get the DRM driver properly working on the LCDK (as I > haven't seen how things work in the DRM subsystem I can't post any proper > change for that). > I see. Reading from the TRM, that should be done for rev2 too. I'll try to come up with a patch for that at some point, unless you send me one first. > The posted changes and the above mentioned palette loading missing bit > are specific to the DRM driver. > > However there are other shortcomings to the proper functioning of the > LCDC on some platforms (I am currently focusing on the LCDK but I guess > it should be true for all da850 based systems), which are not inherent to > the DRM driver driver but which strongly relate to it: > > - The pixel clock rate setting (eg. currently the davinci clk can't cope > properly with the DRM driver way of setting the clock and doesn't use > the common clock framework) > - The memory bandwidth/latency requirements for the LCDC are not met > with the default priority settings (apparently there is a fix in > da850_lcd_hw_init of: > http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=blob;f=arch/arm/mach-davinci/board-omapl138-lcdk.c;h=689b4f304011e09e262782cf8c4b96eba00ac28b;hb=HEAD). > Of course this one affects both the DRM and framebuffer systems. > There is also memory bandwidth issues on am335x and we are still looking for a proper system level fix. > Hence to test the LCDK my crude local changes include (ie. on top of the > posted changes and some dts or sync_lost recovery bits): > - palette loading > - tweak of the pixel clock to cope with davinci clk If you have proper a fixes for these, please send a patch. The palette loading is something I can probably do myself too, but the clock thing is something that I at least can not test. > - adjustment of the memory master priorities > That would be a system level fix and I can not say whether or not to take such a fix. > > BTW, with the recent changes of tilcdc from drm-next, I see this warning > when loading the module: > "drm:drm_helper_disable_unused_functions [drm_kms_helper]] *ERROR* Called for > atomic driver, this is not what you want." > That is also fixed in my latest patch series above. Best regards, Jyri > > Regards, > Karl > > > Karl Beldan (3): > drm/tilcdc: Adjust the FB_CEILING address > drm/tilcdc: Enable EOF interrupts for v1 LCDC > drm/tilcdc: Advertise the DRM_FORMATs according to the IP revision > > drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4 +++- > drivers/gpu/drm/tilcdc/tilcdc_plane.c | 7 ++- > 2 files changed, 9 insertions(+), 2 deletions(-) >
[PATCH v2] io-mapping.h: s/PAGE_KERNEL_IO/PAGE_KERNEL/
On Tue, Aug 23, 2016 at 04:50:24PM +0100, Chris Wilson wrote:
> PAGE_KERNEL_IO is an x86-ism. Though it is used to define the pgprot_t
> used for the iomapped region, it itself is just PAGE_KERNEL. On all
> other arches, PAGE_KERNEL_IO is undefined so in a general header we must
> refrain from using it.
>
> v2: include pgtable for pgprot_combine()
>
> Reported-by: Stephen Rothwell
> Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata
> about the io-mapping")
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Joonas Lahtinen
> Cc: linux-mm at kvack.org
This one seems to have worked out, applied to dinq.
Thanks, Daniel
> ---
> include/linux/io-mapping.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
> index b4c4b5c4216d..a87dd7fffc0a 100644
> --- a/include/linux/io-mapping.h
> +++ b/include/linux/io-mapping.h
> @@ -112,7 +112,7 @@ io_mapping_unmap(void __iomem *vaddr)
> #else
>
> #include
> -#include
> +#include
>
> /* Create the io_mapping object*/
> static inline struct io_mapping *
> @@ -123,7 +123,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
> iomap->base = base;
> iomap->size = size;
> iomap->iomem = ioremap_wc(base, size);
> - iomap->prot = pgprot_writecombine(PAGE_KERNEL_IO);
> + iomap->prot = pgprot_writecombine(PAGE_KERNEL);
>
> return iomap;
> }
> --
> 2.9.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
linux-next: build failure after merge of the drm-intel tree
On Tue, Aug 23, 2016 at 11:56:14AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-intel tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from drivers/gpio/gpiolib-of.c:19:0:
> include/linux/io-mapping.h:115:31: fatal error: asm/pgtable_types.h: No such
> file or directory
> In file included from drivers/gpu/drm/nouveau/include/nvif/os.h:16:0,
> from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3,
> from drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3,
> from drivers/gpu/drm/nouveau/include/nvkm/core/client.h:3,
> from drivers/gpu/drm/nouveau/nvkm/core/client.c:24:
> include/linux/io-mapping.h:115:31: fatal error: asm/pgtable_types.h: No such
> file or directory
>
> and many more.
>
> Caused by commit
>
> cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about
> the io-mapping")
>
> I have used the drm-intel tree from next-20160822 for today.
Should be fixed now, thanks for reporting.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 2/2] drm: simple_kms_helper: add support for bridges
On Tue, Aug 23, 2016 at 5:54 PM, Daniel Vetter wrote: > On Tue, Aug 23, 2016 at 05:39:36PM +0200, Andrea Merello wrote: > > On Tue, Aug 23, 2016 at 5:20 PM, Daniel Vetter wrote: > > > > > On Tue, Aug 23, 2016 at 04:08:04PM +0200, Andrea Merello wrote: > > > > Introduce drm_simple_display_pipe_attach_bridge() in order > > > > to make it possible to use drm encoders with the simple display > > > > pipes managed by simple_kms_helpers > > > > > > > > Suggested-by: Daniel Vetter > > > > Signed-off-by: Andrea Merello > > > > Cc: Noralf Trønnes > > > > Cc: Daniel Vetter > > > > Cc: David Airlie > > > > > > Threading of your patch series is somehow broken, usually that should > all > > > work nicely if you've set up git send-email. > > > > > > One question: Should we ahve a drm_simple_display_pipe_detach_bridge > (for > > > cleanup) too? > > > > > > > Unsure if it worths. May be nice to have a balanced pair, but it would > > probably end up in > > a quite redundant one-line func, that only calls drm_bridge_detach with > the > > very same argument. > > > > ..But of course if you want I can add it in v2 series. > > Yes it's just going to be a one-line, but it'll do a typecast and so > better encapsulate the internals of the simple pipe helper. I'm unsure about what do you mean here. Why a typecast? Wouldn't it be simply drm_simple_display_pipe_detach_bridge(struct drm_bridge *bridge) calling in turn drm_detach_bridge(struct drm_bridge *bridge) with the very same argument? Or if you want to stay behind the pipe, then it could be drm_simple_display_pipe_detach_bridge(struct drm_simple_display_pipe *pipe), but I would say it just does something like drm_bridge_detach(pipe->encoder.bridge), so I don't really get your point about the cast, sorry.. > I think that's > worth it - we have piles&piles of functions and #defines just to make > little one-line bits of code a notch more readable. > > And yes the symmetry is nice too ;-) > OK, then I'll add it :) Andrea > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160823/4b952b0d/attachment.html>
[PATCH] drm/nouveau/tegra: Modify error handling
On Mon, Aug 15, 2016 at 6:54 AM, Amitoj Kaur Chawla wrote: > iommu_domain_alloc returns NULL on error so replace an incorrect > IS_ERR check with a NULL check. > > The Coccinelle semantic patch used to find this issue is as follows: > @@ > expression e; > statement S; > @@ > > *e = iommu_domain_alloc(...); > if (IS_ERR(e)) S > > Signed-off-by: Amitoj Kaur Chawla Reviewed-by: Alexandre Courbot
[PATCH v4 5/5] drm: simpledrm: honour remove_conflicting_framebuffers()
Den 23.08.2016 14:41, skrev Daniel Vetter:
> On Mon, Aug 22, 2016 at 10:25:25PM +0200, Noralf Trønnes wrote:
>> There is currently no non-fbdev mechanism in place to kick out
>> simpledrm when the real hw-driver is probed. As a stop gap until
>> that is in place, honour remove_conflicting_framebuffers() and
>> delete the simple-framebuffer platform device when it's called.
>>
>> Signed-off-by: Noralf Trønnes
>> ---
>> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>> b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>> index c6596ad..7c6db2c 100644
>> --- a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>> +++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>> @@ -44,6 +44,20 @@ static int sdrm_fb_mmap(struct fb_info *info, struct
>> vm_area_struct *vma)
>> return -ENODEV;
>> }
>>
>> +/*
>> + * Releasing has to be done outside the notifier callchain when we're
>> + * kicked out, since do_unregister_framebuffer() calls put_fb_info()
>> + * after the notifier has run.
>> + * Open code drm_fb_helper_release_fbi() since fb_helper is freed at
>> + * this point when kicked out.
>> + */
>> +static void sdrm_fbdev_fb_destroy(struct fb_info *info)
>> +{
>> +if (info->cmap.len)
>> +fb_dealloc_cmap(&info->cmap);
>> +framebuffer_release(info);
>> +}
>> +
>> static struct fb_ops sdrm_fbdev_ops = {
>> .owner = THIS_MODULE,
>> .fb_fillrect= drm_fb_helper_sys_fillrect,
>> @@ -53,6 +67,7 @@ static struct fb_ops sdrm_fbdev_ops = {
>> .fb_set_par = drm_fb_helper_set_par,
>> .fb_setcmap = drm_fb_helper_setcmap,
>> .fb_mmap= sdrm_fb_mmap,
>> +.fb_destroy = sdrm_fbdev_fb_destroy,
>> };
>>
>> static int sdrm_fbdev_create(struct drm_fb_helper *helper,
>> @@ -110,6 +125,9 @@ static int sdrm_fbdev_create(struct drm_fb_helper
>> *helper,
>> fbi->screen_base = obj->vmapping;
>> fbi->fix.smem_len = sdrm->fb_size;
>>
>> +fbi->apertures->ranges[0].base = sdrm->fb_base;
>> +fbi->apertures->ranges[0].size = sdrm->fb_size;
>> +
>> return 0;
>>
>> err_fbi_release:
>> @@ -188,9 +206,13 @@ void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
>> sdrm->fb_helper = NULL;
>> fbdev = to_sdrm_fbdev(fb_helper);
>>
>> -drm_fb_helper_unregister_fbi(fb_helper);
>> +/* it might have been kicked out */
>> +if (registered_fb[fbdev->fb_helper.fbdev->node])
>> +drm_fb_helper_unregister_fbi(fb_helper);
>> +
>> +/* freeing fb_info is done in fb_ops.fb_destroy() */
>> +
>> cancel_work_sync(&fb_helper->dirty_work);
>> -drm_fb_helper_release_fbi(fb_helper);
>>
>> drm_framebuffer_unregister_private(fb_helper->fb);
>> drm_framebuffer_cleanup(fb_helper->fb);
>> @@ -199,3 +221,39 @@ void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
>> drm_fb_helper_fini(fb_helper);
>> kfree(fbdev);
>> }
>> +
>> +static int sdrm_fbdev_event_notify(struct notifier_block *self,
>> + unsigned long action, void *data)
>> +{
>> +struct sdrm_device *sdrm;
>> +struct fb_event *event = data;
>> +struct fb_info *info = event->info;
>> +struct drm_fb_helper *fb_helper = info->par;
>> +
>> +if (action != FB_EVENT_FB_UNREGISTERED)
>> +return NOTIFY_DONE;
>> +
>> +if (!fb_helper || !fb_helper->dev || fb_helper->fbdev != info)
>> +return NOTIFY_DONE;
>> +
>> +sdrm = fb_helper->dev->dev_private;
>> +
>> +if (sdrm && sdrm->fb_helper == fb_helper)
>> +platform_device_del(to_platform_device(fb_helper->dev->dev));
>> +
>> +return NOTIFY_DONE;
>> +}
> One problem this leaves behind is that registering of the new fbdev driver
> is too late - by that point we've already set up the entire driver,
> including modeset. If fbdev meanwhile does a dpms off or something like
> that all hell will break loose.
I don't understand how fbdev registration comes into play here. Drivers call
remove_conflicting_framebuffers very early so simpledrm is gone by the time
they register anything.
For simpledrm, fbdev doing blank/unblank is a no-op since fb_ops.fb_blank
is not implemented. So a fb_blank() just results in fbcon doing a
software blank.
> I think the only option is to add a new notifier chain for fbdev removal,
> called from remove_conflicting_framebuffers (even for CONFIG_FB=n, so need
> a fallback in core/fb_notify.c like with the other notifier I think). That
> would at least keep things working if fbdev is entirely disabled. Or have
> I entirely misunderstood how this works?
How about extending the new wrapper you just added. Something like this:
static int find_simpledrm_cb(struct device *dev, void *data)
{
struct platform_device *pdev = to_platform_device(dev);
char *name = data;
DRM_INFO("Switching to %s from simpledrm\n", name);
platform_device_del(pdev);
return 0;
}
/* not sure where this function should go */
void drm_remove_simpledrm(const char *name)
{
struct device_drive
[PATCH v4 5/5] drm: simpledrm: honour remove_conflicting_framebuffers()
On Tue, Aug 23, 2016 at 7:52 PM, Noralf Trønnes wrote:
>>> +static int sdrm_fbdev_event_notify(struct notifier_block *self,
>>> + unsigned long action, void *data)
>>> +{
>>> + struct sdrm_device *sdrm;
>>> + struct fb_event *event = data;
>>> + struct fb_info *info = event->info;
>>> + struct drm_fb_helper *fb_helper = info->par;
>>> +
>>> + if (action != FB_EVENT_FB_UNREGISTERED)
>>> + return NOTIFY_DONE;
>>> +
>>> + if (!fb_helper || !fb_helper->dev || fb_helper->fbdev != info)
>>> + return NOTIFY_DONE;
>>> +
>>> + sdrm = fb_helper->dev->dev_private;
>>> +
>>> + if (sdrm && sdrm->fb_helper == fb_helper)
>>> +
>>> platform_device_del(to_platform_device(fb_helper->dev->dev));
>>> +
>>> + return NOTIFY_DONE;
>>> +}
>>
>> One problem this leaves behind is that registering of the new fbdev driver
>> is too late - by that point we've already set up the entire driver,
>> including modeset. If fbdev meanwhile does a dpms off or something like
>> that all hell will break loose.
>
>
> I don't understand how fbdev registration comes into play here. Drivers call
> remove_conflicting_framebuffers very early so simpledrm is gone by the time
> they register anything.
>
> For simpledrm, fbdev doing blank/unblank is a no-op since fb_ops.fb_blank
> is not implemented. So a fb_blank() just results in fbcon doing a
> software blank.
Maybe my scenario wasn't entirely clear:
- prereq: fbdev emulation in drm is disabled
1. simpledrm loads and sets up the firmware fb
2. real driver loads, first calls
drm_fb_helper_remove_conflicting_framebuffer. Nothing happens because
CONFIG_FB=n.
3. real driver start loading, remapping the gart and what not else
4. something is drawn using fbcon, simplerdrm writes through the now
invalid mapping
-> BOOM
You have code to listen to the framebuffer registration notifier, but
I think even that happens way too late. Or at least I didn't spot any
code in remove_conflicting_framebuffers which would call down into
that notifier. Or maybe I entirely misunderstand your code ...
Wrt fixing: Just adding it to the recently added stub is of course
also a working solution.
-Daniel
PS: Can you pls review the 2 patches I submitted with you on cc? I
won't merge my own patches without proper review, so without that done
they're stuck.
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/fb-helper: Make docs for fb_set_suspend wrappers consistent
Den 23.08.2016 17:27, skrev Daniel Vetter:
> I figured I might as well go ocd and make them booleans and rename the
> locked version too.
>
> Reported-by: kbuild test robot
> Cc: Noralf Trønnes
> Fixes: cfe63423d9be ("drm/fb-helper: Add
> drm_fb_helper_set_suspend_unlocked()")
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 8
> include/drm/drm_fb_helper.h | 6 +++---
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 10585c462d85..e1af1d08511b 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1035,13 +1035,13 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
> /**
>* drm_fb_helper_set_suspend - wrapper around fb_set_suspend
>* @fb_helper: driver-allocated fbdev helper
> - * @state: desired state, zero to resume, non-zero to suspend
> + * @suspend: whether to suspend or resume
>*
>* A wrapper around fb_set_suspend implemented by fbdev core.
>* Use drm_fb_helper_set_suspend_unlocked() if you don't need to take
>* the lock yourself
>*/
> -void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state)
> +void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool suspend)
> {
> if (fb_helper && fb_helper->fbdev)
> fb_set_suspend(fb_helper->fbdev, state);
Forgot to change state to suspend here.
> @@ -1052,7 +1052,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
>* drm_fb_helper_set_suspend_unlocked - wrapper around fb_set_suspend that
> also
>* takes the console lock
>* @fb_helper: driver-allocated fbdev helper
> - * @state: desired state, zero to resume, non-zero to suspend
> + * @suspend: whether to suspend or resume
>*
>* A wrapper around fb_set_suspend() that takes the console lock. If the
> lock
>* isn't available on resume, a worker is tasked with waiting for the lock
> @@ -1065,7 +1065,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
>* Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
>*/
> void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
> - int suspend)
> + bool suspend)
> {
> if (!fb_helper || !fb_helper->fbdev)
> return;
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 0c6e53d9ce68..6c812e3c8bfc 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -265,9 +265,9 @@ void drm_fb_helper_cfb_copyarea(struct fb_info *info,
> void drm_fb_helper_cfb_imageblit(struct fb_info *info,
>const struct fb_image *image);
>
> -void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state);
> +void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool
> suspend);
> void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
> - int suspend);
> + bool suspend);
>
> int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
>
> @@ -421,7 +421,7 @@ static inline void drm_fb_helper_cfb_imageblit(struct
> fb_info *info,
> }
>
> static inline void drm_fb_helper_set_suspend(struct drm_fb_helper
> *fb_helper,
> - int state)
> + bool suspend)
> {
> }
>
The _unlocked version also needs the bool change here in the #else section.
With that:
Acked-by: Noralf Trønnes
Thanks for fixing up my docs omission.
Noralf.
[PATCH] drm/fb-helper: Make docs for fb_set_suspend wrappers consistent
On Tue, Aug 23, 2016 at 08:53:05PM +0200, Noralf Trønnes wrote:
>
> Den 23.08.2016 17:27, skrev Daniel Vetter:
> > I figured I might as well go ocd and make them booleans and rename the
> > locked version too.
> >
> > Reported-by: kbuild test robot
> > Cc: Noralf Trønnes
> > Fixes: cfe63423d9be ("drm/fb-helper: Add
> > drm_fb_helper_set_suspend_unlocked()")
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 8
> > include/drm/drm_fb_helper.h | 6 +++---
> > 2 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 10585c462d85..e1af1d08511b 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1035,13 +1035,13 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
> > /**
> >* drm_fb_helper_set_suspend - wrapper around fb_set_suspend
> >* @fb_helper: driver-allocated fbdev helper
> > - * @state: desired state, zero to resume, non-zero to suspend
> > + * @suspend: whether to suspend or resume
> >*
> >* A wrapper around fb_set_suspend implemented by fbdev core.
> >* Use drm_fb_helper_set_suspend_unlocked() if you don't need to take
> >* the lock yourself
> >*/
> > -void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state)
> > +void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool
> > suspend)
> > {
> > if (fb_helper && fb_helper->fbdev)
> > fb_set_suspend(fb_helper->fbdev, state);
>
> Forgot to change state to suspend here.
Argh, silly me forgot to compile-check both variants.
>
> > @@ -1052,7 +1052,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
> >* drm_fb_helper_set_suspend_unlocked - wrapper around fb_set_suspend
> > that also
> >* takes the console lock
> >* @fb_helper: driver-allocated fbdev helper
> > - * @state: desired state, zero to resume, non-zero to suspend
> > + * @suspend: whether to suspend or resume
> >*
> >* A wrapper around fb_set_suspend() that takes the console lock. If the
> > lock
> >* isn't available on resume, a worker is tasked with waiting for the lock
> > @@ -1065,7 +1065,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
> >* Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
> >*/
> > void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
> > - int suspend)
> > + bool suspend)
> > {
> > if (!fb_helper || !fb_helper->fbdev)
> > return;
> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > index 0c6e53d9ce68..6c812e3c8bfc 100644
> > --- a/include/drm/drm_fb_helper.h
> > +++ b/include/drm/drm_fb_helper.h
> > @@ -265,9 +265,9 @@ void drm_fb_helper_cfb_copyarea(struct fb_info *info,
> > void drm_fb_helper_cfb_imageblit(struct fb_info *info,
> > const struct fb_image *image);
> > -void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state);
> > +void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool
> > suspend);
> > void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
> > - int suspend);
> > + bool suspend);
> > int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
> > @@ -421,7 +421,7 @@ static inline void drm_fb_helper_cfb_imageblit(struct
> > fb_info *info,
> > }
> > static inline void drm_fb_helper_set_suspend(struct drm_fb_helper
> > *fb_helper,
> > -int state)
> > +bool suspend)
> > {
> > }
>
> The _unlocked version also needs the bool change here in the #else section.
>
> With that:
> Acked-by: Noralf Trønnes
Both fixed and applied, thanks for the review.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[drm-intel:for-linux-next 1/1] include/linux/io-mapping.h:126:2: error: implicit declaration of function 'pgprot_writecombine'
On Wed, Aug 24, 2016 at 02:22:29AM +0800, kbuild test robot wrote: > tree: git://anongit.freedesktop.org/drm-intel for-linux-next > head: ac96b5566926af83463ddcf4655856033c092f26 > commit: ac96b5566926af83463ddcf4655856033c092f26 [1/1] io-mapping.h: > s/PAGE_KERNEL_IO/PAGE_KERNEL/ > config: microblaze-nommu_defconfig (attached as .config) > compiler: microblaze-linux-gcc (GCC) 4.9.0 > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout ac96b5566926af83463ddcf4655856033c092f26 > # save the attached .config to linux build tree > make.cross ARCH=microblaze > > All errors (new ones prefixed by >>): > >In file included from drivers/gpio/gpiolib-of.c:19:0: >include/linux/io-mapping.h: In function 'io_mapping_init_wc': > >> include/linux/io-mapping.h:126:2: error: implicit declaration of function > >> 'pgprot_writecombine' [-Werror=implicit-function-declaration] > iomap->prot = pgprot_writecombine(PAGE_KERNEL); > ^ > >> include/linux/io-mapping.h:126:14: error: incompatible types when > >> assigning to type 'pgprot_t' from type 'int' > iomap->prot = pgprot_writecombine(PAGE_KERNEL); > ^ >cc1: some warnings being treated as errors > > vim +/pgprot_writecombine +126 include/linux/io-mapping.h Grrr. diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h index a87dd7fffc0a..babd4c53a5aa 100644 --- a/include/linux/io-mapping.h +++ b/include/linux/io-mapping.h @@ -114,6 +114,10 @@ io_mapping_unmap(void __iomem *vaddr) #include #include +#ifdef pgprot_noncached_wc +#define pgprot_writecombine pgprot_noncached_wc +#endif + /* Create the io_mapping object*/ static inline struct io_mapping * io_mapping_init_wc(struct io_mapping *iomap, is what I have in mind. Looks like a divide between x86 and ppc (and their followers). -Chris -- Chris Wilson, Intel Open Source Technology Centre
