[PATCH 20/34] drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c
On Tue, Mar 11, 2014 at 8:30 PM, Daniel Vetter wrote: > There's not really any value in stating that no locking is needed. And > even if the comment is useful, a check for the right mutex at the > beginning of the function is better since that can't be ingored as > easily as a bit of documentation. > > Note that drm_mode_probed_add in drm_crtc.c is also changed, the next > patch will move this into drm_modes.c > > v2: Don't add locking WARN_ONs where it is not strictly required (i.e. > the two functions to validate/prune mode lists). This made radeon blow up hard, I kinda expect other drivers also, >Mar 20 01:14:21 crydee kernel: [ cut here ] Mar 20 01:14:21 crydee kernel: WARNING: CPU: 3 PID: 882 at /home/airlied/kernel/linux-2.6/drivers/gpu/drm/drm_crtc.c:94 drm_warn_on_modeset_not_all_locked+0x48/0x76 [drm]() Mar 20 01:14:21 crydee kernel: Modules linked in: firewire_ohci firewire_core crc_itu_t ehci_pci ohci_pci ehci_hcd ohci_hcd radeon(+) hwmon i2c_algo_bit drm_kms_helper ttm drm i2c_core Mar 20 01:14:21 crydee kernel: CPU: 3 PID: 882 Comm: systemd-udevd Not tainted 3.14.0-rc7+ #67 Mar 20 01:14:21 crydee kernel: Hardware name: Gigabyte Technology Co., Ltd. GA-A75M-UD2H/GA-A75M-UD2H, BIOS F4 09/16/2011 Mar 20 01:14:21 crydee kernel: 88022311f9c8 814b5b21 Mar 20 01:14:21 crydee kernel: 88022311fa00 81039e11 a001882f 880036b92000 Mar 20 01:14:21 crydee kernel: 880224c85000 880224c85690 88022311fa10 Mar 20 01:14:21 crydee kernel: Call Trace: Mar 20 01:14:21 crydee kernel: [] dump_stack+0x4d/0x66 Mar 20 01:14:21 crydee kernel: [] warn_slowpath_common+0x7a/0x93 Mar 20 01:14:21 crydee kernel: [] ? drm_warn_on_modeset_not_all_locked+0x48/0x76 [drm] Mar 20 01:14:21 crydee kernel: [] warn_slowpath_null+0x15/0x17 Mar 20 01:14:21 crydee kernel: [] drm_warn_on_modeset_not_all_locked+0x48/0x76 [drm] Mar 20 01:14:21 crydee kernel: [] drm_helper_disable_unused_functions+0x11/0x103 [drm_kms_helper] Mar 20 01:14:21 crydee kernel: [] radeon_fbdev_init+0xb2/0xcf [radeon] Mar 20 01:14:21 crydee kernel: [] radeon_modeset_init+0x763/0x951 [radeon] Mar 20 01:14:21 crydee kernel: [] radeon_driver_load_kms+0xc5/0x171 [radeon] Mar 20 01:14:21 crydee kernel: [] drm_dev_register+0x7f/0xf8 [drm] Mar 20 01:14:21 crydee kernel: [] drm_get_pci_dev+0xfe/0x1c8 [drm] Mar 20 01:14:21 crydee kernel: [] ? trace_hardirqs_on+0xd/0xf Mar 20 01:14:21 crydee kernel: [] radeon_pci_probe+0xa8/0xaf [radeon] Mar 20 01:14:21 crydee kernel: [] local_pci_probe+0x38/0x7d Mar 20 01:14:21 crydee kernel: [] pci_device_probe+0xc6/0xec Mar 20 01:14:21 crydee kernel: [] driver_probe_device+0x98/0x1b3 Mar 20 01:14:21 crydee kernel: [] __driver_attach+0x5c/0x7e Mar 20 01:14:21 crydee kernel: [] ? __device_attach+0x38/0x38 Mar 20 01:14:21 crydee kernel: [] bus_for_each_dev+0x79/0x83 Mar 20 01:14:21 crydee kernel: [] driver_attach+0x19/0x1b Mar 20 01:14:21 crydee kernel: [] bus_add_driver+0x109/0x1d3 Mar 20 01:14:21 crydee kernel: [] driver_register+0x89/0xc5 Mar 20 01:14:21 crydee kernel: [] __pci_register_driver+0x5b/0x5e Mar 20 01:14:21 crydee kernel: [] ? 0xa01c0fff Mar 20 01:14:21 crydee kernel: [] drm_pci_init+0x69/0xec [drm] Mar 20 01:14:21 crydee kernel: [] ? 0xa01c0fff Mar 20 01:14:21 crydee kernel: [] radeon_init+0x97/0xb5 [radeon] Dave.
[RFCv3 04/14] drm/exynos: Restrict plane loops to only operate on overlay planes
On Thu, Mar 20, 2014 at 3:31 AM, Daniel Vetter wrote:
> On Wed, Mar 19, 2014 at 10:26:13PM +0800, Daniel Kurtz wrote:
>> On Wed, Mar 19, 2014 at 7:51 PM, Daniel Vetter wrote:
>> > On Tue, Mar 18, 2014 at 05:22:49PM -0700, Matt Roper wrote:
>> >> Before we add additional types of planes to the DRM plane list, ensure
>> >> that existing loops over all planes continue to operate only on
>> >> "overlay" planes and ignore primary & cursor planes.
>> >>
>> >> Cc: Inki Dae
>> >> Signed-off-by: Matt Roper
>> >> ---
>> >> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 ++
>> >> 1 file changed, 6 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> >> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> >> index 06f1b2a..2fa2685 100644
>> >> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> >> @@ -127,6 +127,9 @@ static void disable_plane_to_crtc(struct drm_device
>> >> *dev,
>> >>* (encoder->crtc)
>> >>*/
>> >> list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
>> >> + if (plane->type != DRM_PLANE_TYPE_OVERLAY)
>> >
>> > I think a drm_for_each_legacy_plane iteration helper would be neat for
>> > this one and the following i915 patch.
>> > -Daniel
>> >
>> >> + continue;
>> >> +
>> >> if (plane->crtc == old_crtc) {
>> >> /*
>> >>* do not change below call order.
>> >> @@ -247,6 +250,9 @@ static void exynos_drm_encoder_disable(struct
>> >> drm_encoder *encoder)
>> >>
>> >> /* all planes connected to this encoder should be also disabled. */
>> >> list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
>> >> + if (plane->type != DRM_PLANE_TYPE_OVERLAY)
>> >> + continue;
>> >> +
>> >> if (plane->crtc == encoder->crtc)
>> >> plane->funcs->disable_plane(plane);
>> >> }
>>
>> The original loop disables all planes attached to a crtc when
>> disabling an encoder attached to the same crtc. It was added by:
>>
>> commit bcf4cef94294992f7cd11d5a90fa58b0eae6c795
>> Author: Inki Dae
>> Date: Fri Aug 24 10:54:12 2012 -0700
>>
>> drm/exynos: Disable plane when released
>>
>> this patch ensures that each plane connected to encoder is disabled
>> when released, by adding disable callback function of encoder helper
>>
>> we had faced with one issue that invalid memory is accessed by dma
>> once drm is released and then the dma is turned on again. actually,
>> in our case, page fault was incurred with iommu. the reason is that
>> a gem buffer accessed by the dma is also released once drm is released.
>>
>> so this patch would fix this issue ensuring the dma is disabled
>> when released.
>>
>>
>> An encoder receives and encodes the mixed output of all of the
>> planes/overlays. It would seem that whether the individual planes
>> themselves are enabled or not should be completely independent of the
>> status any encoder. However, I find the code in exynos_drm_encoder.c
>> very difficult to follow, so perhaps there is some extra linkage
>> between encoder/crtc/plane that is exynos specific.
>>
>> In any case, judging from the commit message, this disable loop should
>> probably still iterate over all of the planes, not just the
>> "DRM_PLANE_TYPE_OVERLAY" ones. So, I think this new patch is
>> incorrect.
>
> It keeps full backwars compatibility with existing semantics, which is the
> right thing to do in such a case. It could be that exynos simply has a
> bug, but imo that should be a separate patch outside of this series.
Indeed... I missed the fact that in the existing code, the "priv"
(now primary) plane is not added to the plane_list, so it wouldn't
actually be disabled in this loop here anyway.
New question: are the planes that will become DRM_PLANE_TYPE_CURSOR
formerly "priv", or not?
If they were not, then I think the backwards- and forwards- compatible loop is:
list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
if (plane->type == DRM_PLANE_TYPE_PRIMARY)
continue;
/* do something with legacy planes */
}
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[GIT PULL] exynos-drm-fixes
Hi Dave, Just fixed resource release issue at open fail. Thanks, Inki Dae The following changes since commit 27410e8248c64f5c6d28891389083b1022c15a10: drm: Fix use-after-free in the shadow-attache exit code (2014-03-18 13:09:03 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-fixes for you to fetch changes up to 85d898bf8f638b7a23af95dc7d32b4a72c178637: drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c (2014-03-20 11:42:24 +0900) Daniel Kurtz (1): drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-)
[Bug 76382] New: Mesa Gallium egllog _eglLog
https://bugs.freedesktop.org/show_bug.cgi?id=76382 Priority: medium Bug ID: 76382 Assignee: dri-devel at lists.freedesktop.org Summary: Mesa Gallium egllog _eglLog Severity: major Classification: Unclassified OS: Linux (All) Reporter: f1r31c3r at gmail.com Hardware: All Status: NEW Version: 9.0 Component: Drivers/Gallium/i915g Product: Mesa Hi all. Sorry in advance for any spelling blurb as i am using match sticks to hold me eyes open. I found a bug in the mesa, particularly related to the include files used in src/gallium/x11 files that contain the include egllog.h that define _elLog cant find the it. Not sure if the environment variable set for the source code under the gallium directory is not set right. Put simply even though the include is specified in the source file it does not actually include it and hence the compile fails due to "undefined reference _eglLog" Seems that it only ever fails to compile when gallium has been enabled. egl enabled with gles1 and 2 is fine but enable gallium and the compile error occurs. Hope it helps. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/275aed5c/attachment.html>
[Bug 76382] Mesa Gallium egllog _eglLog
https://bugs.freedesktop.org/show_bug.cgi?id=76382 --- Comment #1 from Chris --- Aaa poop. I meant to type /src/gallium/state_trackers/egl/x11 as the directory in the source code to the file that includes egllog.h but does not seem to actually find the egllog.h file path at compile time. native_x11.c was one of the files that bunked out on compile so i picked it to see why. Of course other files that use the egllog.h include compile fine but not any of them. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/fbd17939/attachment-0001.html>
[RFCv3 07/14] drm: Specify primary plane at CRTC initialization (v2)
Hi,
2014-03-19 9:22 GMT+09:00 Matt Roper :
> Add primary plane as a parameter to drm_crtc_init() and update all
> existing DRM drivers to use a helper-provided primary plane.
>
> v2: Update msm & omap drivers to use existing "private" planes as primary
> planes instead of helper [Rob Clark]
>
> Tested-by: Rob Clark
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/armada/armada_crtc.c | 4 +++-
> drivers/gpu/drm/ast/ast_mode.c | 4 +++-
> drivers/gpu/drm/bochs/bochs_kms.c | 4 +++-
> drivers/gpu/drm/cirrus/cirrus_mode.c | 4 +++-
> drivers/gpu/drm/drm_crtc.c | 9 -
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +++-
> drivers/gpu/drm/gma500/psb_intel_display.c | 4 +++-
> drivers/gpu/drm/i915/intel_display.c | 4 +++-
> drivers/gpu/drm/mgag200/mgag200_mode.c | 4 +++-
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 5 -
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 5 -
> drivers/gpu/drm/nouveau/dispnv04/crtc.c| 4 +++-
> drivers/gpu/drm/nouveau/nv50_display.c | 4 +++-
> drivers/gpu/drm/omapdrm/omap_crtc.c| 2 +-
> drivers/gpu/drm/qxl/qxl_display.c | 4 +++-
> drivers/gpu/drm/radeon/radeon_display.c| 4 +++-
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4 +++-
> drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 3 ++-
> drivers/gpu/drm/tegra/dc.c | 4 +++-
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4 +++-
> drivers/gpu/drm/udl/udl_modeset.c | 4 +++-
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 4 +++-
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 +++-
> drivers/staging/imx-drm/imx-drm-core.c | 4 +++-
> include/drm/drm_crtc.h | 5 +
> 25 files changed, 81 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c
> b/drivers/gpu/drm/armada/armada_crtc.c
> index d8e3982..0a14d24 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -1030,6 +1030,7 @@ int armada_drm_crtc_create(struct drm_device *dev,
> unsigned num,
> {
> struct armada_private *priv = dev->dev_private;
> struct armada_crtc *dcrtc;
> + struct drm_plane *primary;
> void __iomem *base;
> int ret;
>
> @@ -1086,7 +1087,8 @@ int armada_drm_crtc_create(struct drm_device *dev,
> unsigned num,
>
> priv->dcrtc[dcrtc->num] = dcrtc;
>
> - drm_crtc_init(dev, &dcrtc->crtc, &armada_crtc_funcs);
> + primary = drm_primary_helper_create_plane(dev);
> + drm_crtc_init(dev, &dcrtc->crtc, primary, &armada_crtc_funcs);
> drm_crtc_helper_add(&dcrtc->crtc, &armada_crtc_helper_funcs);
>
> drm_object_attach_property(&dcrtc->crtc.base, priv->csc_yuv_prop,
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index cca063b..44f0d32 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -626,13 +626,15 @@ static const struct drm_crtc_funcs ast_crtc_funcs = {
> static int ast_crtc_init(struct drm_device *dev)
> {
> struct ast_crtc *crtc;
> + struct drm_plane *primary;
> int i;
>
> crtc = kzalloc(sizeof(struct ast_crtc), GFP_KERNEL);
> if (!crtc)
> return -ENOMEM;
>
> - drm_crtc_init(dev, &crtc->base, &ast_crtc_funcs);
> + primary = drm_primary_helper_create_plane(dev);
> + drm_crtc_init(dev, &crtc->base, primary, &ast_crtc_funcs);
> drm_mode_crtc_set_gamma_size(&crtc->base, 256);
> drm_crtc_helper_add(&crtc->base, &ast_crtc_helper_funcs);
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 62ec7d4..182f5c9 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -129,8 +129,10 @@ static void bochs_crtc_init(struct drm_device *dev)
> {
> struct bochs_device *bochs = dev->dev_private;
> struct drm_crtc *crtc = &bochs->crtc;
> + struct drm_plane *primary;
>
> - drm_crtc_init(dev, crtc, &bochs_crtc_funcs);
> + primary = drm_primary_helper_create_plane(dev);
> + drm_crtc_init(dev, crtc, primary, &bochs_crtc_funcs);
> drm_mode_crtc_set_gamma_size(crtc, 256);
> drm_crtc_helper_add(crtc, &bochs_helper_funcs);
> }
> diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
> b/drivers/gpu/drm/cirrus/cirrus_mode.c
> index 530f78f..449246f 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_mode.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
> @@ -381,6 +381,7 @@ static void cirrus_crtc_init(struct drm_device *dev)
> {
> struct cirrus_device *cdev = dev->dev_private;
> struct cirrus_crtc *cirrus_crtc;
> + struct drm_plane *primary;
> int i;
>
> cirrus_crtc = kzalloc(sizeof(struct cirrus_crtc) +
> @@ -390,7 +391,8 @@ static void cirrus_crtc_init(struct drm_device *dev)
> if (cirrus_crtc == NULL)
> return;
>
> -
[Bug 76382] Mesa Gallium egllog _eglLog
https://bugs.freedesktop.org/show_bug.cgi?id=76382 --- Comment #2 from Matt Turner --- Post a build log. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/f77dcb45/attachment-0001.html>
[PATCH 8/9] drm/exynos/fimd: use polarization flags provided by drm_display_mode
Thanks for your contributions,
2014-03-17 19:27 GMT+09:00 Andrzej Hajda :
> The patch replaces fimd private bindings for signal polarization by
> polarization flags provided by drm_display_mode.
>
This patch needs below patch not merged yet,
drm: drm_display_mode: add signal polarity flags
So let me pick up all of your path series except for patch 7 and 8.
And for these two patches, later.
Your opinion?
Thanks,
Inki Dae
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 15d6b37..dbfad4e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -115,7 +115,6 @@ struct fimd_context {
> unsigned intdefault_win;
> unsigned long irq_flags;
> u32 vidcon0;
> - u32 vidcon1;
> boolsuspended;
> int pipe;
> wait_queue_head_t wait_vsync_queue;
> @@ -232,7 +231,11 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
> return;
>
> /* setup polarity values */
> - vidcon1 = ctx->vidcon1;
> + vidcon1 = 0;
> + if (mode->pol_flags & DRM_MODE_FLAG_POL_DE_NEGEDGE)
> + vidcon1 |= VIDCON1_INV_VDEN;
> + if (mode->pol_flags & DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE)
> + vidcon1 |= VIDCON1_INV_VCLK;
> if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> vidcon1 |= VIDCON1_INV_VSYNC;
> if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> @@ -875,11 +878,6 @@ static int fimd_probe(struct platform_device *pdev)
> ctx->dev = dev;
> ctx->suspended = true;
>
> - if (of_property_read_bool(dev->of_node, "samsung,invert-vden"))
> - ctx->vidcon1 |= VIDCON1_INV_VDEN;
> - if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
> - ctx->vidcon1 |= VIDCON1_INV_VCLK;
> -
> ctx->bus_clk = devm_clk_get(dev, "fimd");
> if (IS_ERR(ctx->bus_clk)) {
> dev_err(dev, "failed to get bus clock\n");
> --
> 1.8.3.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: enable render-nodes by default
Hi! On 03/17/2014 05:43 PM, David Herrmann wrote: > We introduced render-nodes about 1/2 year ago and no problems showed up. > Remove the drm_rnodes argument and enable them by default now. So what about the malicious execbuf command stream problem? Do we require all drivers that enable render-nodes to have a mechanism to prevent this in place? /Thomas
[PATCH 8/9] drm/exynos/fimd: use polarization flags provided by drm_display_mode
On 03/20/2014 07:03 AM, Inki Dae wrote:
> Thanks for your contributions,
>
>
> 2014-03-17 19:27 GMT+09:00 Andrzej Hajda :
>> The patch replaces fimd private bindings for signal polarization by
>> polarization flags provided by drm_display_mode.
>>
>
> This patch needs below patch not merged yet,
> drm: drm_display_mode: add signal polarity flags
>
> So let me pick up all of your path series except for patch 7 and 8.
> And for these two patches, later.
>
> Your opinion?
Yes, please do it.
Regards
Andrzej
>
> Thanks,
> Inki Dae
>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 12 +---
>> 1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 15d6b37..dbfad4e 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -115,7 +115,6 @@ struct fimd_context {
>> unsigned intdefault_win;
>> unsigned long irq_flags;
>> u32 vidcon0;
>> - u32 vidcon1;
>> boolsuspended;
>> int pipe;
>> wait_queue_head_t wait_vsync_queue;
>> @@ -232,7 +231,11 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
>> return;
>>
>> /* setup polarity values */
>> - vidcon1 = ctx->vidcon1;
>> + vidcon1 = 0;
>> + if (mode->pol_flags & DRM_MODE_FLAG_POL_DE_NEGEDGE)
>> + vidcon1 |= VIDCON1_INV_VDEN;
>> + if (mode->pol_flags & DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE)
>> + vidcon1 |= VIDCON1_INV_VCLK;
>> if (mode->flags & DRM_MODE_FLAG_NVSYNC)
>> vidcon1 |= VIDCON1_INV_VSYNC;
>> if (mode->flags & DRM_MODE_FLAG_NHSYNC)
>> @@ -875,11 +878,6 @@ static int fimd_probe(struct platform_device *pdev)
>> ctx->dev = dev;
>> ctx->suspended = true;
>>
>> - if (of_property_read_bool(dev->of_node, "samsung,invert-vden"))
>> - ctx->vidcon1 |= VIDCON1_INV_VDEN;
>> - if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
>> - ctx->vidcon1 |= VIDCON1_INV_VCLK;
>> -
>> ctx->bus_clk = devm_clk_get(dev, "fimd");
>> if (IS_ERR(ctx->bus_clk)) {
>> dev_err(dev, "failed to get bus clock\n");
>> --
>> 1.8.3.2
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: add phy settings for RB resolutions
On Wed, Mar 12, 2014 at 10:28 PM, Shirish S wrote:
> This patch adds support for the below mentioned
> pixel clocks in Exynos5250.
> Without them, following display modes won't
> be supported:
>
> 71 MHz - 1280x800 at 60Hz RB
> 73.25 MHz - 800x600 at 120Hz RB
> 88.75 MHz - 1440x900 at 60Hz RB
> 115.5 MHz - 1024x768 at 120Hz RB
> 119 MHz - 1680x1050 at 60Hz RB
>
> Signed-off-by: Shirish S
> ---
> V2: Incorporated review comments
>
> drivers/gpu/drm/exynos/exynos_hdmi.c | 45
> ++
> 1 file changed, 45 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 12fdf55..406d89d 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -304,6 +304,24 @@ static const struct hdmiphy_config
> hdmiphy_v14_configs[] = {
> },
> },
> {
> + .pixel_clock = 7100,
> + .conf = {
> + 0x01, 0x91, 0x1e, 0x15, 0x40, 0x3c, 0xce, 0x08,
> + 0x04, 0x20, 0xb2, 0xd8, 0x45, 0xa0, 0xac, 0x80,
> + 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> + 0x54, 0xad, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 7325,
> + .conf = {
> + 0x01, 0xd1, 0x1f, 0x15, 0x40, 0x18, 0xe9, 0x08,
> + 0x02, 0xa0, 0xb7, 0xd8, 0x45, 0xa0, 0xac, 0x80,
> + 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> + 0x54, 0xa8, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> .pixel_clock = 74176000,
> .conf = {
> 0x01, 0xd1, 0x3e, 0x35, 0x40, 0x5b, 0xde, 0x08,
> @@ -331,6 +349,15 @@ static const struct hdmiphy_config
> hdmiphy_v14_configs[] = {
> },
> },
> {
> + .pixel_clock = 8875,
> + .conf = {
> + 0x01, 0x91, 0x25, 0x17, 0x40, 0x30, 0xfe, 0x08,
> + 0x06, 0x20, 0xde, 0xd8, 0x45, 0xa0, 0xac, 0x80,
> + 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> + 0x54, 0x8a, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> .pixel_clock = 10650,
> .conf = {
> 0x01, 0xd1, 0x2c, 0x12, 0x40, 0x0c, 0x09, 0x08,
> @@ -349,6 +376,24 @@ static const struct hdmiphy_config
> hdmiphy_v14_configs[] = {
> },
> },
> {
> + .pixel_clock = 11550,
> + .conf = {
> + 0x01, 0xd1, 0x30, 0x1a, 0x40, 0x40, 0x10, 0x04,
> + 0x04, 0xa0, 0x21, 0xd9, 0x45, 0xa0, 0xac, 0x80,
> + 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> + 0x54, 0xaa, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 11900,
>
We have found that the 119MHz clock doesn't work in Chrome OS (the clock
doesn't stabilize), so we removed it. We should probably remove it here as
well.
St?phane
+ .conf = {
> + 0x01, 0x91, 0x32, 0x14, 0x40, 0x60, 0xd8, 0x08,
> + 0x06, 0x20, 0x2a, 0xd9, 0x45, 0xa0, 0xac, 0x80,
> + 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> + 0x54, 0x9d, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> .pixel_clock = 14625,
> .conf = {
> 0x01, 0xd1, 0x3d, 0x15, 0x40, 0x18, 0xfd, 0x08,
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/e78b48d3/attachment.html>
[PATCH v2] drm: enable render-nodes by default
Hi On Thu, Mar 20, 2014 at 7:43 AM, Thomas Hellstrom wrote: > On 03/17/2014 05:43 PM, David Herrmann wrote: >> We introduced render-nodes about 1/2 year ago and no problems showed up. >> Remove the drm_rnodes argument and enable them by default now. > > So what about the malicious execbuf command stream problem? Do we > require all drivers that enable > render-nodes to have a mechanism to prevent this in place? No, that's no requirement. Render-nodes provide a secure API, if the underlying driver does no command-stream validation (I guess for performance-reasons and lack of VM), it's an implementation detail, not an API. Furthermore, you can always set higher restrictions on the render-node char-dev in case this bothers you. Cheers David
Intel G41 doesn't see any screens connected after suspend/resume
On Wed, Mar 19, 2014 at 08:15:05PM -0400, Nikolay Martynov wrote: > Hi > > > > > Perhaps you failed to install the modules that go with the kernel? > I've built today's git version. The system boots but short after I > log into X session system freezes. > > I can login via ssh and see dmesg: > > [ 58.699131] general protection fault: [#1] SMP > [ 58.699173] Modules linked in: nls_utf8 udf crc_itu_t rfcomm bnep > bluetooth 6lowpan_iphc binfmt_misc snd_usb_audio snd_usbmidi_lib > gpio_ich ppdev gspca_zc3xx gspca_main videodev snd_hda_codec_realtek > dm_multipath snd_hda_codec_generic snd_hda_intel scsi_dh snd_hda_codec > snd_hwdep snd_pcm snd_seq_midi coretemp snd_seq_midi_event kvm_intel > snd_rawmidi snd_seq kvm snd_seq_device snd_timer snd lpc_ich soundcore > serio_raw parport_pc lp mac_hid asus_atk0110 parport raid10 raid456 > async_raid6_recov async_memcpy async_pq async_xor async_tx xor > raid6_pq raid0 multipath linear hid_generic usbhid hid raid1 i915 > atl1e video i2c_algo_bit drm_kms_helper drm > [ 58.699510] CPU: 0 PID: 1638 Comm: Xorg Tainted: GW > 3.14.0-rc7-custom #2 > [ 58.699537] Hardware name: System manufacturer System Product > Name/P5G41-M LE, BIOS 050606/11/2010 > [ 58.699578] task: 8800d0f498d0 ti: 8800cfcb8000 task.ti: > 8800cfcb8000 > [ 58.699603] RIP: 0010:[] [] > i915_gem_object_set_cache_level+0x8a/0x310 [i915] > [ 58.699677] RSP: 0018:8800cfcb9d60 EFLAGS: 00010246 > [ 58.699701] RAX: 880036444000 RBX: dead00100098 RCX: > 8800cfcfd158 > [ 58.699725] RDX: 8800cfcfcfd8 RSI: 8800d086d0d0 RDI: > 88011b401800 > [ 58.699749] RBP: 8800cfcb9d90 R08: 00017340 R09: > 88011fc17340 > [ 58.699772] R10: ea0003421b40 R11: a00a1e33 R12: > 8800cfcfcf00 > [ 58.699796] R13: 0001 R14: 8800cf36c800 R15: > 8800cfcfcfc0 > [ 58.699821] FS: 7f3af20e1980() GS:88011fc0() > knlGS: > [ 58.699856] CS: 0010 DS: ES: CR0: 80050033 > [ 58.699876] CR2: 7f52d8659000 CR3: d0fa2000 CR4: > 000407f0 > [ 58.699899] Stack: > [ 58.699910] 0001cfcb9d88 8800cf36c800 8800cfcfcf00 > fffe > [ 58.699945] 0001 8800cf36c800 8800cfcb9dc0 > a00a5144 > [ 58.699978] 8800d0ea3000 006f fff2 > 8800cfcb9e20 > [ 58.700010] Call Trace: > [ 58.700010] [] i915_gem_set_caching_ioctl+0x84/0xf0 > [i915] > [ 58.700010] [] drm_ioctl+0x4d2/0x600 [drm] > [ 58.700010] [] ? native_sched_clock+0x35/0x90 > [ 58.700010] [] ? native_sched_clock+0x35/0x90 > [ 58.700010] [] ? sched_clock+0x9/0x10 > [ 58.700010] [] do_vfs_ioctl+0x2e0/0x4c0 > [ 58.700010] [] ? vtime_account_user+0x54/0x60 > [ 58.700010] [] SyS_ioctl+0x81/0xa0 > [ 58.700010] [] tracesys+0xe1/0xe6 > [ 58.700010] Code: 90 f6 40 40 0f 0f 85 46 01 00 00 48 8b 42 68 49 > 39 c7 48 8d 50 98 75 e9 44 8b 6d d4 0f 1f 44 00 00 49 8b 46 30 f6 40 > 1c 20 75 25 43 20 20 74 1f 4c 89 ee 48 89 df e8 95 9e ff ff 84 c0 > 75 10 > [ 58.700010] RIP [] > i915_gem_object_set_cache_level+0x8a/0x310 [i915] > [ 58.700010] RSP > [ 58.725088] ---[ end trace c84dd3681cbb815b ]--- > > Is this something expected on current git > (ec45c7550806d1373db6915a4031a7ae2542d61f)? QA just reported it as well, https://bugs.freedesktop.org/show_bug.cgi?id=76384 If you can find the corresponding line for i915_gem_object_set_cache_level+0x8a (gdb /path/to/i915.ko; list *i915_gem_object_set_cache_level+0x8a) that would help. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 0/6] File Sealing & memfd_create()
Hi On Thu, Mar 20, 2014 at 4:49 AM, Linus Torvalds wrote: > Is there really any use-case where the sealer isn't also the same > thing that *created* the file in the first place? Because I would be a > ton happier with the notion that you can only seal things that you > yourself created. At that point, the exclusive reference isn't such a > big deal any more, but more importantly, you can't play random > denial-of-service games on files that aren't really yours. My first idea was to add MFD_ALLOW_SEALING as memfd_create() flag, which enables the sealing-API for that file. Then I looked at POSIX mandatory locking and noticed that it provides similar restrictions on _all_ files. Mandatory locks can be more easily removed, but an attacker could just re-apply them in a loop, so that's not really an argument. Furthermore, sealing requires _write_ access so I wonder what kind of DoS attacks are possible with sealing that are not already possible with write access? And sealing is only possible if no writable, shared mapping exists. So even if an attacker seals a file, all that happens is EPERM, not SIGBUS (still a possible denial-of-service scenario). But I understand that it is quite hard to review all the possible scenarios. So I'm fine with checking inode-ownership permissions for SET_SEALS. We could also make sealing a one-shot operation. Given that in a no-trust situation there is never a guarantee that the other side drops its references, re-using a sealed file is usually not possible. However, in sane environments, this could be a nice optimization in case the other side plays along. The one-shot semantics would allow dropping reference-checks entirely. The inode-ownership semantics would still require it. Thanks David
[PATCH v2] drm: enable render-nodes by default
On 03/20/2014 08:36 AM, David Herrmann wrote: > Hi > > On Thu, Mar 20, 2014 at 7:43 AM, Thomas Hellstrom > wrote: >> On 03/17/2014 05:43 PM, David Herrmann wrote: >>> We introduced render-nodes about 1/2 year ago and no problems showed up. >>> Remove the drm_rnodes argument and enable them by default now. >> So what about the malicious execbuf command stream problem? Do we >> require all drivers that enable >> render-nodes to have a mechanism to prevent this in place? > No, that's no requirement. Render-nodes provide a secure API, if the > underlying driver does no command-stream validation (I guess for > performance-reasons and lack of VM), it's an implementation detail, > not an API. Furthermore, you can always set higher restrictions on the > render-node char-dev in case this bothers you. I'm merely trying to envision the situation where a distro wants to create, for example an udev rule for the render nodes. How should the distro know that the implementation is not insecure? Historically drm has refused to upstream drivers without a proper command validation mechanism in place (via for example), but that validation mechanism only needed to make sure no random system memory was ever accessible to an authenticated DRM client. Now, render nodes are designed to provide also user data isolation. But if we allow insecure implementations, wouldn't that compromise the whole idea? Now that we have a secure API within reach, wouldn't it be reasonable to require implementations to also be secure, following earlier DRM practices? Or am I missing something? /Thomas > > Cheers > David
[PATCH v2] drm: enable render-nodes by default
Hi Thomas On Thu, Mar 20, 2014 at 9:48 AM, Thomas Hellstrom wrote: > I'm merely trying to envision the situation where a distro wants to > create, for example an udev rule for the render nodes. > > How should the distro know that the implementation is not insecure? > > Historically drm has refused to upstream drivers without a proper > command validation mechanism in place (via for example), > but that validation mechanism only needed to make sure no random system > memory was ever accessible to an authenticated DRM client. I expect all drivers to protect system-memory. All that I am talking about is one exec-buffer writing to memory of another _GPU_ buffer that this client doesn't have access to. But maybe driver authors can give some insights. I'd even expect non-texture/data GPU buffers to be protected. > Now, render nodes are designed to provide also user data isolation. But > if we allow insecure implementations, wouldn't that compromise the whole > idea? > Now that we have a secure API within reach, wouldn't it be reasonable to > require implementations to also be secure, following earlier DRM practices? I don't understand what this has to do with render-nodes? The API _is_ secure. What would be the gain of disabling render-nodes for broken (even deliberately) drivers? User-space is not going to assume drivers are broken and rely on hand-crafted exec-buffers that cross buffer boundaries. So yes, we're fooling our selves with API guarantees that drivers cannot deliver, but what's the downside? Thanks David
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
The I2C address (reg) is required for the TDA998x driver to be loaded and initialized. Signed-off-by: Jean-Francois Moine --- This patch applies to linux-next. --- Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt index d7df01c..fc7effa 100644 --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt @@ -3,6 +3,8 @@ Device-Tree bindings for the NXP TDA998x HDMI transmitter Required properties; - compatible: must be "nxp,tda998x" + - reg: I2C address - must be <0x70> + Optional properties: - interrupts: interrupt number and trigger type default: polling -- 1.9.1
[PATCH v2] drm: enable render-nodes by default
On 03/20/2014 10:05 AM, David Herrmann wrote: > Hi Thomas > > On Thu, Mar 20, 2014 at 9:48 AM, Thomas Hellstrom > wrote: >> I'm merely trying to envision the situation where a distro wants to >> create, for example an udev rule for the render nodes. >> >> How should the distro know that the implementation is not insecure? >> >> Historically drm has refused to upstream drivers without a proper >> command validation mechanism in place (via for example), >> but that validation mechanism only needed to make sure no random system >> memory was ever accessible to an authenticated DRM client. > I expect all drivers to protect system-memory. All that I am talking > about is one exec-buffer writing to memory of another _GPU_ buffer > that this client doesn't have access to. But maybe driver authors can > give some insights. I'd even expect non-texture/data GPU buffers to be > protected. > >> Now, render nodes are designed to provide also user data isolation. But >> if we allow insecure implementations, wouldn't that compromise the whole >> idea? >> Now that we have a secure API within reach, wouldn't it be reasonable to >> require implementations to also be secure, following earlier DRM practices? > I don't understand what this has to do with render-nodes? The API _is_ > secure. What would be the gain of disabling render-nodes for broken > (even deliberately) drivers? User-space is not going to assume drivers > are broken and rely on hand-crafted exec-buffers that cross buffer > boundaries. So yes, we're fooling our selves with API guarantees that > drivers cannot deliver, but what's the downside? > > Thanks > David OK, let me give one example: A user logs in to a system where DRI clients use render nodes. The system grants rw permission on the render nodes for the console user. User starts editing a secret document, starts some GPGPU structural FEM computations of the Pentagon building. Locks the screen and goes for lunch. A malicious user logs in using fast user switching and becomes the owner of the render node. Tries to map a couple of random offsets, but that fails, due to security checks. Now crafts a malicious command stream to dump all GPU memory to a file. Steals the first user's secret document and the intermediate Pentagon data. Logs out and starts data mining. Now if we require drivers to block these malicious command streams this can never happen, and distros can reliably grant rw access to the render nodes to the user currently logged into the console. I guest basically what I'm trying to say that with the legacy concept it was OK to access all GPU memory, because an authenticated X user basically had the same permissions. With render nodes we're allowing multiple users into the GPU at the same time, and it's not OK anymore for a client to access another clients GPU buffer through a malicious command stream. /Thomas
[PATCH v2] drm: enable render-nodes by default
Hi On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom wrote: > A user logs in to a system where DRI clients use render nodes. The > system grants rw permission on the render nodes for the console user. > User starts editing a secret document, starts some GPGPU structural FEM > computations of the Pentagon building. Locks the screen and goes for lunch. > > A malicious user logs in using fast user switching and becomes the owner > of the render node. Tries to map a couple of random offsets, but that > fails, due to security checks. Now crafts a malicious command stream to > dump all GPU memory to a file. Steals the first user's secret document > and the intermediate Pentagon data. Logs out and starts data mining. > > Now if we require drivers to block these malicious command streams this > can never happen, and distros can reliably grant rw access to the render > nodes to the user currently logged into the console. > > I guest basically what I'm trying to say that with the legacy concept it > was OK to access all GPU memory, because an authenticated X user > basically had the same permissions. > > With render nodes we're allowing multiple users into the GPU at the same > time, and it's not OK anymore for a client to access another clients GPU > buffer through a malicious command stream. Yes, I understand the attack scenario, but that's not related to render-nodes at all. The exact same races exist on the legacy node: 1) If you can do fast-user switching, you can spawn your own X-server, get authenticated on your own server and you are allowed into the GPU. You cannot map other user's buffers because they're on a different master-object, but you _can_ craft malicious GPU streams and access the other user's buffer. 2) If you can do fast-user switching, switch to an empty VT, open the legacy node and you automatically become DRM-Master because there is no active master. Now you can do anything on the DRM node, including crafting malicious GPU streams. Given that the legacy node is always around and _always_ has these races, why should we prevent render-nodes from appearing just because the _driver_ is racy? I mean, there is no gain in that.. if it opens a new race, as you assumed, then yes, we should avoid it. But at least for all drivers supporting render-nodes so far, they either are entirely safe or the just described races exist on both nodes. Thanks David
[PATCH] drm/mm: Fix search for smallest hole satisfying constraints
On Mit, 2014-03-19 at 11:38 +0100, Daniel Vetter wrote: > On Wed, Mar 19, 2014 at 05:42:27PM +0900, Michel D?nzer wrote: > > On Die, 2014-03-18 at 11:01 +0100, Daniel Vetter wrote: > > > On Tue, Mar 18, 2014 at 09:58:14AM +0900, Michel D?nzer wrote: > > > > From: Michel D?nzer > > > > > > > > entry->size is the size of the node, not the size of the hole after it. > > > > So the code would actually find the hole which can satisfy the > > > > constraints and which is preceded by the smallest node, not the smallest > > > > hole satisfying the constraints. > > > > > > > > Reported-by: "Huang, FrankR" > > > > Signed-off-by: Michel D?nzer > > > > > > But drm-next just gained my kerneldoc patch for drm_mm, so can you please > > > respin your patch and update the docs too? > > > > What kind of update are you thinking of? > > you've changed the function parameters, which breaks the kerneldoc. v2 is > ok in that regard. Ah, I see. > > Meanwhile, I've submitted a less invasive v2 fix. > > Reviewed-by: Daniel Vetter on that one. Merci! :) > > BTW, do you think the fix would interact properly with coloring? > > Coloring only adjusts start/end so won't affect the size of the hole. If > you really see benefits from best_match I've been wondering about the potential effects of this fix... I hope it won't cause regressions. > then I guess you could look into pessimising holes which need to be > split, presuming radeon has a pile of alignment or otherwise > constrained buffers. E.g. textures with 2D tiling can require pretty large alignment, so that might indeed be interesting. -- Earthling Michel D?nzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
[Bug 75494] Kabini [Radeon HD 8240] Xorg segfault on resume from suspend with glamor and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75494 --- Comment #7 from Jarno Lepp?nen --- This problem seems to be fixed in mainline kernel version 3.14-rc7. Closing bug. Thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/52c58f37/attachment.html>
[Bug 75494] Kabini [Radeon HD 8240] Xorg segfault on resume from suspend with glamor and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75494 Jarno Lepp?nen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/d9b0fb98/attachment.html>
[PATCH v2] drm: enable render-nodes by default
On 03/20/2014 10:43 AM, David Herrmann wrote: > Hi > > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom > wrote: >> A user logs in to a system where DRI clients use render nodes. The >> system grants rw permission on the render nodes for the console user. >> User starts editing a secret document, starts some GPGPU structural FEM >> computations of the Pentagon building. Locks the screen and goes for lunch. >> >> A malicious user logs in using fast user switching and becomes the owner >> of the render node. Tries to map a couple of random offsets, but that >> fails, due to security checks. Now crafts a malicious command stream to >> dump all GPU memory to a file. Steals the first user's secret document >> and the intermediate Pentagon data. Logs out and starts data mining. >> >> Now if we require drivers to block these malicious command streams this >> can never happen, and distros can reliably grant rw access to the render >> nodes to the user currently logged into the console. >> >> I guest basically what I'm trying to say that with the legacy concept it >> was OK to access all GPU memory, because an authenticated X user >> basically had the same permissions. >> >> With render nodes we're allowing multiple users into the GPU at the same >> time, and it's not OK anymore for a client to access another clients GPU >> buffer through a malicious command stream. > Yes, I understand the attack scenario, but that's not related to > render-nodes at all. The exact same races exist on the legacy node: I was under the impression that render nodes were designed to fix these issues? > > 1) If you can do fast-user switching, you can spawn your own X-server, > get authenticated on your own server and you are allowed into the GPU. > You cannot map other user's buffers because they're on a different > master-object, but you _can_ craft malicious GPU streams and access > the other user's buffer. But with legacy nodes, drivers can (and should IMO) throw out all data from GPU memory on master drop, and then block dropped master authenticated clients from GPU, until their master becomes active again or dies (in which case they are killed). In line with a previous discussion we had. Now you can't do this with render nodes, so yes they do open up a new race that requires command stream validation. > > 2) If you can do fast-user switching, switch to an empty VT, open the > legacy node and you automatically become DRM-Master because there is > no active master. Now you can do anything on the DRM node, including > crafting malicious GPU streams. I believe the above solution should work for this case as well. > > Given that the legacy node is always around and _always_ has these > races, why should we prevent render-nodes from appearing just because > the _driver_ is racy? I mean, there is no gain in that.. if it opens a > new race, as you assumed, then yes, we should avoid it. But at least > for all drivers supporting render-nodes so far, they either are > entirely safe or the just described races exist on both nodes. My suggestion is actually not to prevent render nodes from appearing, but rather that we should restrict them to drivers with command stream verification and / or per process virtual memory, and I also think we should plug the above races on legacy nodes. That way legacy nodes would use the old "master owns it all" model, while render nodes could allow multiple users at the same time. /Thomas
[PATCH 1/1] drm/gma500: Code cleanup - remove double variable assignment
The same assignment has already been taken place before in the drm_driver struct Signed-off-by: Arthur Borsboom --- drivers/gpu/drm/gma500/psb_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c index b686e56..edb903b 100644 --- a/drivers/gpu/drm/gma500/psb_drv.c +++ b/drivers/gpu/drm/gma500/psb_drv.c @@ -358,7 +358,6 @@ static int psb_driver_load(struct drm_device *dev, unsigned long flags) dev->vblank_disable_allowed = true; dev->max_vblank_count = 0xff; /* only 24 bits of frame count */ - dev->driver->get_vblank_counter = psb_get_vblank_counter; psb_modeset_init(dev); psb_fbdev_init(dev); -- 1.9.0
[PATCH 3/6] shm: add memfd_create() syscall
Hi On Thu, Mar 20, 2014 at 10:01 AM, Pavel Emelyanov wrote: > On 03/20/2014 12:47 PM, Cyrill Gorcunov wrote: >> If I'm not mistaken in something obvious, this looks similar to >> /proc/pid/map_files >> feature, Pavel? > > It is, but the map_files will work "in the opposite direction" :) In the memfd > case one first gets an FD, then mmap()s it; in the /proc/pis/map_files case > one > should first mmap() a region, then open it via /proc/self/map_files. > > But I don't know whether this matters. Yes, you can replace memfd_create() so far with: p = mmap(NULL, size, ..., MAP_ANON | MAP_SHARED, -1, 0); sprintf(path, "/proc/self/map_files/%lx-%lx", p, p + size); fd = open(path, O_RDWR); However, map_files is only enabled with CONFIG_CHECKPOINT_RESTORE, the /proc/pid/map_files/ directory is root-only (at least I get EPERM if non-root), it doesn't provide the "name" argument which is very handy for debugging, it doesn't explicitly support sealing (it requires MAP_ANON to be backed by shmem) and it's a very weird API for something this simple. Thanks David
[Intel-gfx] [PATCH 1/4] drm: Added plane alpha and color blending property
On Sat, Mar 08, 2014 at 01:51:16PM +0530, sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> This patch creates a generic blending enum property.
> Drivers may support subset of these values.
>
> Cc: airlied at linux.ie
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Sagar Kamble
> ---
> drivers/gpu/drm/drm_crtc.c | 33 +
> include/drm/drm_crtc.h | 25 +
> 2 files changed, 58 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 4e43fc2..15281a3 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -4147,3 +4147,36 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> idr_destroy(&dev->mode_config.crtc_idr);
> }
> EXPORT_SYMBOL(drm_mode_config_cleanup);
> +
> +struct drm_property *drm_mode_create_blend_property(struct drm_device *dev,
> + unsigned int supported_factors)
> +{
> + static const struct drm_prop_enum_list props[] = {
> + { DRM_BLEND_NONE, "none" },
> + { DRM_BLEND_ZERO, "zero" },
> + { DRM_BLEND_ONE,"one" },
> + { DRM_BLEND_SRC_COLOR, "src-color" },
> + { DRM_BLEND_ONE_MINUS_SRC_COLOR,"one-minus-src-color" },
> + { DRM_BLEND_DST_COLOR, "dst-color" },
> + { DRM_BLEND_ONE_MINUS_DST_COLOR,"one-minus-dst-color" },
> + { DRM_BLEND_SRC_ALPHA, "src-alpha" },
> + { DRM_BLEND_ONE_MINUS_SRC_ALPHA,"one-minus-src-alpha" },
> + { DRM_BLEND_DST_ALPHA, "dst-alpha" },
> + { DRM_BLEND_ONE_MINUS_DST_ALPHA,"one-minus-dst-alpha" },
> + { DRM_BLEND_CONSTANT_COLOR, "constant-color" },
> + { DRM_BLEND_ONE_MINUS_CONSTANT_COLOR,
> "one-minus-constant-color" },
> + { DRM_BLEND_CONSTANT_ALPHA, "constant-alpha" },
> + { DRM_BLEND_ONE_MINUS_CONSTANT_ALPHA,
> "one-minus-constant-alpha" },
> + { DRM_BLEND_SRC_ALPHA_SATURATE, "alpha-saturate" },
> + { DRM_BLEND_SRC1_COLOR, "src1-color" },
> + { DRM_BLEND_ONE_MINUS_SRC1_COLOR, "one-minus-src1-color"
> },
> + { DRM_BLEND_SRC1_ALPHA, "src1-alpha" },
> + { DRM_BLEND_ONE_MINUS_SRC1_ALPHA, "one-minus-src1-alpha"
> },
> + { DRM_BLEND_PREMULTIPLIED_ALPHA,"pre-multiplied-alpha" }
Again, whether the fbs are premultipled or not is orthogonal to how we
want to blend the plane. I still think it'd be better to add
premultiplied fb DRM formats.
--
Damien
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On Thu, Mar 20, 2014 at 01:32:24PM +0100, Sebastian Hesselbarth wrote: > On 03/20/2014 09:58 AM, Jean-Francois Moine wrote: >> The I2C address (reg) is required for the TDA998x driver to be loaded >> and initialized. >> >> Signed-off-by: Jean-Francois Moine >> --- >> This patch applies to linux-next. >> --- >> Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt >> b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt >> index d7df01c..fc7effa 100644 >> --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt >> +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt >> @@ -3,6 +3,8 @@ Device-Tree bindings for the NXP TDA998x HDMI transmitter >> Required properties; >> - compatible: must be "nxp,tda998x" >> >> + - reg: I2C address - must be <0x70> > > TDA9983b datasheet says: > > "Bits A0 and A1 of the I2C-bus device address are externally selected > by pins A0 and A1." > > Therefore, 0x70, 0x71, 0x72, and 0x73 are valid i2c addresses. Thanks Sebastian, those kinds of details are very important to get right when it comes to the binding doc, much more so than what's in the code. It probably makes more sense not to specify what the address actually is. After all, that's a specification by the data sheet and software shouldn't really care what that is. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[RFCv3 03/14] drm: Add primary plane helpers
On Thu, Mar 20, 2014 at 12:01 AM, Matt Roper wrote: > On Wed, Mar 19, 2014 at 01:24:23PM +0100, Daniel Vetter wrote: >> On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote: >> > When we expose non-overlay planes to userspace, they will become >> > accessible via standard userspace plane API's. We should be able to >> > handle the standard plane operations against primary planes in a generic >> > way via the page flip handler and modeset handler. >> > >> > Drivers that can program primary planes more efficiently, that want to >> > use their own primary plane structure to track additional information, >> > or that don't have the limitations assumed by the helpers are free to >> > provide their own implementation of some or all of these handlers. >> > >> > Signed-off-by: Matt Roper >> >> One thing I've noticed with planes is that we don't have any per-plane >> size limits. Which will be annoying for cursors at least, but looking at >> intel's hw history there are other planes with limits smaller than >> dev->mode_config.max_widht/height. >> >> I think as part of the universal plane work here we should add this to the >> getplane ioctl (we can extend at the end with full backwards compat) and >> use the max_width/height as default for primary/overlay planes and >> cursor_width/height for cursor planes. > > I'm not sure I understand how to (cleanly) extend the existing ioctl > safely. Userspace (libdrm) allocates a drm_mode_get_plane structure on > the stack with a specific size. If we try to extend this structure to > return more information, and have the kernel write into the new fields, > aren't we just going to be spilling over into other userspace stack > variables if we run an old libdrm on the new kernel? The only > approaches I see that could make this work would be huge ugly hacks: > * Reclaiming the top few bits of plane_id to use as "I sent you the >new, larger structure" capability flags (which assumes plane ID's are >always small enough to leave those bits 0 on current kernels; this >would effectively reduce our plane ID address space). > * Figure out a way to encode extra information as bogus pixel formats >and shove it into the format list returned to userspace. Presumably >userspace would just ignore/skip the bogus formats. > > I suppose we could add a new GetPlane2 ioctl or something that returned > more info, but I figured it was probably easier to just shove max plane > size (and a bunch of other plane capabilities / limitations) into some > new read-only plane properties. Read-only properties are easy to extend > if we find other pieces of information we want to return in the future, > so that seems like the most natural interface to me. The size userspace expects is passed in through the ioctl number. It then zero-extends the structure correctly for both forward and backwards compatibility. Which means that yeah, we can extend the struct at the end, recompile libdrm and as long as the kernel treats 0 in the new fields sanely. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 1/2] drm/crtc-helper: fix locking for drm_helper_disable_unused_functions
We have two calling contexts for thise function:
- In the crtc helper code itself as part of the ->set_config
implementation. In this calling context all modeset locks are
already held, as they should.
- In drivers not implementing fastboot before the fbdev/fbcon setup
and initialization. This has been added for all drivers in
commit 76a39dbfb2d1bc45219839e5a95d4ceaf6ca114f
Author: Daniel Vetter
Date: Sun Jan 20 23:12:54 2013 +0100
drm/fb-helper: don't disable everything in initial_config
In this calling context we do not hold any modeset locks since the
immediately following call to initialize the fbev emulation grabs
all these locks themselves.
- There are two exceptions to the above rule: shmob doesn't have fbdev
emulation support. I've manually checked the callchain up to the
driver load function and no kms locks are held.
The right fix therefore is to split this helper into an internal and
external version and add the required locking to the function exported
to drivers.
This remedies locking inconsistencies exposed by me adding locking
WARNs as part of the recent kerneldoc abi polishing done in
commit 62ff94a5492175759546f8bc61383189d6b49122
Author: Daniel Vetter
Date: Thu Jan 23 22:18:47 2014 +0100
drm/crtc-helper: remove LOCKING from kerneldoc
and
commit 63951385052f7974155fa38f962f0f4e9847f90a
Author: Daniel Vetter
Date: Thu Jan 23 15:14:15 2014 +0100
drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index a85517854073..9d8fb32357c0 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -278,17 +278,7 @@ drm_encoder_disable(struct drm_encoder *encoder)
encoder->bridge->funcs->post_disable(encoder->bridge);
}
-/**
- * drm_helper_disable_unused_functions - disable unused objects
- * @dev: DRM device
- *
- * This function walks through the entire mode setting configuration of @dev.
It
- * will remove any crtc links of unused encoders and encoder links of
- * disconnected connectors. Then it will disable all unused encoders and crtcs
- * either by calling their disable callback if available or by calling their
- * dpms callback with DRM_MODE_DPMS_OFF.
- */
-void drm_helper_disable_unused_functions(struct drm_device *dev)
+static void __drm_helper_disable_unused_functions(struct drm_device *dev)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
@@ -323,6 +313,23 @@ void drm_helper_disable_unused_functions(struct drm_device
*dev)
}
}
}
+
+/**
+ * drm_helper_disable_unused_functions - disable unused objects
+ * @dev: DRM device
+ *
+ * This function walks through the entire mode setting configuration of @dev.
It
+ * will remove any crtc links of unused encoders and encoder links of
+ * disconnected connectors. Then it will disable all unused encoders and crtcs
+ * either by calling their disable callback if available or by calling their
+ * dpms callback with DRM_MODE_DPMS_OFF.
+ */
+void drm_helper_disable_unused_functions(struct drm_device *dev)
+{
+ drm_modeset_lock_all(dev);
+ __drm_helper_disable_unused_functions(dev);
+ drm_modeset_unlock_all(dev);
+}
EXPORT_SYMBOL(drm_helper_disable_unused_functions);
/*
--
1.8.4.rc3
[PATCH 2/2] drm/fb-helper: improve drm_fb_helper_initial_config locking
The locking in drm_fb_helper_initial_config is a bit troublesome for a few reasons: - We can't just wrap the entire function up into modeset locks since the fbdev registration might call down into fbcon code, which then through our ->set_par implementation needs to be able to grab all modeset locks. So we'd have a neat deadlock. - This implies though that all current callers don't hold any modeset locks by necessity, so we have free reign to grab any modeset locks we need to grab. - The private state of the fbdev helper doesn't need any protection through locks, since once we have the fbdev registered it is mostly invariant or protected through the modeset locking in ->set_par and other callbacks. We can fully rely on driver having non-racy setup sequences here. For the initial config computation we actually may not grab locks since drivers which provide their own magic sauce (like i915) might need to grab locks themselves. - We should grab locks though when we probe outputs. Currently there's not much risk, but already now userspace could start poking at sysfs files and so probe concurrently. I expect that in the future driver init will be much more async, and since probing is really time-consuming this is a prime candidate. - We must not hold any crtc->mutex locks while calling probe functions since those might need to lock a crtc for e.g. load detection. i915 is such a driver. Also it's the probing calls which hit upon piles of new locking asserts I've recently added in commit 62ff94a5492175759546f8bc61383189d6b49122 Author: Daniel Vetter Date: Thu Jan 23 22:18:47 2014 +0100 drm/crtc-helper: remove LOCKING from kerneldoc and commit 63951385052f7974155fa38f962f0f4e9847f90a Author: Daniel Vetter Date: Thu Jan 23 15:14:15 2014 +0100 drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c Hence the right fix is to grab the mode_config mutex, but only that and only right around the probe calls. It seems to be sufficient to shut up all the locking WARNINGs I see on i915 and nouveau in drm_fb_helper_initial_config. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_fb_helper.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 87876198801d..16f271e21b9c 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1536,9 +1536,11 @@ bool drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel) drm_fb_helper_parse_command_line(fb_helper); + mutex_lock(&dev->mode_config.mutex); count = drm_fb_helper_probe_connector_modes(fb_helper, dev->mode_config.max_width, dev->mode_config.max_height); + mutex_unlock(&dev->mode_config.mutex); /* * we shouldn't end up with no modes here. */ -- 1.8.4.rc3
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On Thu, 20 Mar 2014 13:32:24 +0100 Sebastian Hesselbarth wrote: > > + - reg: I2C address - must be <0x70> > > TDA9983b datasheet says: > > "Bits A0 and A1 of the I2C-bus device address are externally selected > by pins A0 and A1." > > Therefore, 0x70, 0x71, 0x72, and 0x73 are valid i2c addresses. Sebastian, That's interesting! For the Cubox and the AMX33XX boards, the I2C address of the HDMI registers is 0x70, and the I2C address of the CEC registers is 0x34. For other boards using the TDA998x family, if the I2C address is different from 0x70, have you an idea about what can be the CEC I2C address? (this value is actually hard-coded in the TDA998x driver) -- Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[PATCH 1/2] drm/crtc-helper: fix locking for drm_helper_disable_unused_functions
On Thu, Mar 20, 2014 at 02:01:21PM +0100, Daniel Vetter wrote:
> We have two calling contexts for thise function:
>
> - In the crtc helper code itself as part of the ->set_config
> implementation. In this calling context all modeset locks are
> already held, as they should.
>
> - In drivers not implementing fastboot before the fbdev/fbcon setup
> and initialization. This has been added for all drivers in
>
> commit 76a39dbfb2d1bc45219839e5a95d4ceaf6ca114f
> Author: Daniel Vetter
> Date: Sun Jan 20 23:12:54 2013 +0100
>
> drm/fb-helper: don't disable everything in initial_config
>
> In this calling context we do not hold any modeset locks since the
> immediately following call to initialize the fbev emulation grabs
> all these locks themselves.
>
> - There are two exceptions to the above rule: shmob doesn't have fbdev
> emulation support. I've manually checked the callchain up to the
> driver load function and no kms locks are held.
>
> The right fix therefore is to split this helper into an internal and
> external version and add the required locking to the function exported
> to drivers.
>
> This remedies locking inconsistencies exposed by me adding locking
> WARNs as part of the recent kerneldoc abi polishing done in
>
> commit 62ff94a5492175759546f8bc61383189d6b49122
> Author: Daniel Vetter
> Date: Thu Jan 23 22:18:47 2014 +0100
>
> drm/crtc-helper: remove LOCKING from kerneldoc
>
> and
>
> commit 63951385052f7974155fa38f962f0f4e9847f90a
> Author: Daniel Vetter
> Date: Thu Jan 23 15:14:15 2014 +0100
>
> drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc_helper.c | 29 ++---
> 1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index a85517854073..9d8fb32357c0 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -278,17 +278,7 @@ drm_encoder_disable(struct drm_encoder *encoder)
> encoder->bridge->funcs->post_disable(encoder->bridge);
> }
>
> -/**
> - * drm_helper_disable_unused_functions - disable unused objects
> - * @dev: DRM device
> - *
> - * This function walks through the entire mode setting configuration of
> @dev. It
> - * will remove any crtc links of unused encoders and encoder links of
> - * disconnected connectors. Then it will disable all unused encoders and
> crtcs
> - * either by calling their disable callback if available or by calling their
> - * dpms callback with DRM_MODE_DPMS_OFF.
> - */
> -void drm_helper_disable_unused_functions(struct drm_device *dev)
> +static void __drm_helper_disable_unused_functions(struct drm_device *dev)
> {
> struct drm_encoder *encoder;
> struct drm_connector *connector;
> @@ -323,6 +313,23 @@ void drm_helper_disable_unused_functions(struct
> drm_device *dev)
> }
> }
> }
> +
> +/**
> + * drm_helper_disable_unused_functions - disable unused objects
> + * @dev: DRM device
> + *
> + * This function walks through the entire mode setting configuration of
> @dev. It
> + * will remove any crtc links of unused encoders and encoder links of
> + * disconnected connectors. Then it will disable all unused encoders and
> crtcs
> + * either by calling their disable callback if available or by calling their
> + * dpms callback with DRM_MODE_DPMS_OFF.
> + */
> +void drm_helper_disable_unused_functions(struct drm_device *dev)
> +{
> + drm_modeset_lock_all(dev);
> + __drm_helper_disable_unused_functions(dev);
> + drm_modeset_unlock_all(dev);
> +}
> EXPORT_SYMBOL(drm_helper_disable_unused_functions);
drm_helper_disable_unused_functions() is called by
drm_crtc_helper_disable() which is expected to be holding the lock.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[GIT PULL] gma500-next
Hi Dave, Here's the patches for the 3.15 merge window. Summary of what's included: - SGX MMU support - SGX IRQ handling (Page faults and blitter fences) - Minor Cedarview and Poulsbo unification - Work queue for ASLE interrupt work - Various cleanups, style fixes and removal of dead code Thanks Patrik The following changes since commit 786a7828bc74b9b1466e83abb200b75f80f94121: Merge branch 'drm-next-3.15' of git:// people.freedesktop.org/~deathsimple/linux into drm-next (2014-03-05 14:52:19 +1000) are available in the git repository at: git://github.com/patjak/drm-gma500 gma500-next for you to fetch changes up to 75144097014d1bca861b403e7e2093549114d0c9: drm/gma500: remove stub .open/postclose (2014-03-18 00:47:09 +0100) Arthur Borsboom (3): drm/gma500: Code cleanup - removal of centralized exiting of function drm/gma500: Code cleanup - style fixes drm/gma500: Code cleanup - inline documentation David Herrmann (1): drm/gma500: remove stub .open/postclose Patrik Jakobsson (12): drm/gma500: Make SGX MMU driver actually do something drm/gma500: Add support for SGX interrupts drm/gma500: Give MMU code it's own header file drm/gma500: Add first piece of blitter code drm/gma500: Hook up the MMU drm/gma500: Always trap MMU page faults drm/gma500: Remove unused ioctls drm/gma500: Add backing type and base align to psb_gem_create() drm/gma500: Move asle interrupt work into a work task drm/gma500: Unify _get_core_freq for cdv and psb drm/gma500: Unify encoder mode fixup drm/gma500/cdv: Cedarview display cleanups Thierry Reding (1): drm/gma500: Remove dead code drivers/gpu/drm/gma500/Makefile| 2 + drivers/gpu/drm/gma500/blitter.c | 51 drivers/gpu/drm/gma500/blitter.h | 22 ++ drivers/gpu/drm/gma500/cdv_device.c| 40 +-- drivers/gpu/drm/gma500/cdv_intel_crt.c | 9 +- drivers/gpu/drm/gma500/cdv_intel_display.c | 71 ++--- drivers/gpu/drm/gma500/cdv_intel_hdmi.c| 9 +- drivers/gpu/drm/gma500/framebuffer.c | 2 +- drivers/gpu/drm/gma500/gem.c | 56 +--- drivers/gpu/drm/gma500/gem.h | 21 ++ drivers/gpu/drm/gma500/gma_device.c| 56 drivers/gpu/drm/gma500/gma_device.h| 21 ++ drivers/gpu/drm/gma500/gma_display.c | 7 + drivers/gpu/drm/gma500/gma_display.h | 3 + drivers/gpu/drm/gma500/gtt.c | 45 +++- drivers/gpu/drm/gma500/gtt.h | 3 +- drivers/gpu/drm/gma500/mmu.c | 297 ++--- drivers/gpu/drm/gma500/mmu.h | 93 +++ drivers/gpu/drm/gma500/oaktrail_hdmi.c | 9 +- drivers/gpu/drm/gma500/opregion.c | 25 +- drivers/gpu/drm/gma500/psb_device.c| 42 +-- drivers/gpu/drm/gma500/psb_drv.c | 404 - drivers/gpu/drm/gma500/psb_drv.h | 203 --- drivers/gpu/drm/gma500/psb_intel_display.c | 30 +-- drivers/gpu/drm/gma500/psb_intel_drv.h | 2 - drivers/gpu/drm/gma500/psb_irq.c | 81 +- include/drm/gma_drm.h | 70 + 27 files changed, 722 insertions(+), 952 deletions(-) create mode 100644 drivers/gpu/drm/gma500/blitter.c create mode 100644 drivers/gpu/drm/gma500/blitter.h create mode 100644 drivers/gpu/drm/gma500/gem.h create mode 100644 drivers/gpu/drm/gma500/gma_device.c create mode 100644 drivers/gpu/drm/gma500/gma_device.h create mode 100644 drivers/gpu/drm/gma500/mmu.h -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/b8b7d5e3/attachment.html>
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On Thu, 20 Mar 2014 14:01:56 +0100 Jean-Francois Moine wrote: > For other boards using the TDA998x family, if the I2C address is > different from 0x70, have you an idea about what can be the CEC I2C > address? (this value is actually hard-coded in the TDA998x driver) I had a look again on the tda998x driver from NXP and the linux tda998x driver: - the NXP driver handles the TDAs 19989, 19988, 9984, 9983 and 9981. It accesses the tda registers only at I2C address 0x70 and 0x34 (hard-coded values in the driver). - the linux tda998x driver handles only the TDAs 19988 and 19989. As we have no documentation about the chips TDA 19988 and 19989, may the HDMI I2C addresses of these chips be different from 0x70? -- Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[PATCH 1/2] drm/crtc-helper: fix locking for drm_helper_disable_unused_functions
We have two calling contexts for thise function:
- In the crtc helper code itself as part of the ->set_config
implementation. In this calling context all modeset locks are
already held, as they should.
- In drivers not implementing fastboot before the fbdev/fbcon setup
and initialization. This has been added for all drivers in
commit 76a39dbfb2d1bc45219839e5a95d4ceaf6ca114f
Author: Daniel Vetter
Date: Sun Jan 20 23:12:54 2013 +0100
drm/fb-helper: don't disable everything in initial_config
In this calling context we do not hold any modeset locks since the
immediately following call to initialize the fbev emulation grabs
all these locks themselves.
- There are two exceptions to the above rule: shmob doesn't have fbdev
emulation support. I've manually checked the callchain up to the
driver load function and no kms locks are held.
The right fix therefore is to split this helper into an internal and
external version and add the required locking to the function exported
to drivers.
This remedies locking inconsistencies exposed by me adding locking
WARNs as part of the recent kerneldoc abi polishing done in
commit 62ff94a5492175759546f8bc61383189d6b49122
Author: Daniel Vetter
Date: Thu Jan 23 22:18:47 2014 +0100
drm/crtc-helper: remove LOCKING from kerneldoc
and
commit 63951385052f7974155fa38f962f0f4e9847f90a
Author: Daniel Vetter
Date: Thu Jan 23 15:14:15 2014 +0100
drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c
v2: It helps when I actually git add the entire thing.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index a85517854073..5d2b7a5716e6 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -278,17 +278,7 @@ drm_encoder_disable(struct drm_encoder *encoder)
encoder->bridge->funcs->post_disable(encoder->bridge);
}
-/**
- * drm_helper_disable_unused_functions - disable unused objects
- * @dev: DRM device
- *
- * This function walks through the entire mode setting configuration of @dev.
It
- * will remove any crtc links of unused encoders and encoder links of
- * disconnected connectors. Then it will disable all unused encoders and crtcs
- * either by calling their disable callback if available or by calling their
- * dpms callback with DRM_MODE_DPMS_OFF.
- */
-void drm_helper_disable_unused_functions(struct drm_device *dev)
+static void __drm_helper_disable_unused_functions(struct drm_device *dev)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
@@ -323,6 +313,23 @@ void drm_helper_disable_unused_functions(struct drm_device
*dev)
}
}
}
+
+/**
+ * drm_helper_disable_unused_functions - disable unused objects
+ * @dev: DRM device
+ *
+ * This function walks through the entire mode setting configuration of @dev.
It
+ * will remove any crtc links of unused encoders and encoder links of
+ * disconnected connectors. Then it will disable all unused encoders and crtcs
+ * either by calling their disable callback if available or by calling their
+ * dpms callback with DRM_MODE_DPMS_OFF.
+ */
+void drm_helper_disable_unused_functions(struct drm_device *dev)
+{
+ drm_modeset_lock_all(dev);
+ __drm_helper_disable_unused_functions(dev);
+ drm_modeset_unlock_all(dev);
+}
EXPORT_SYMBOL(drm_helper_disable_unused_functions);
/*
@@ -552,7 +559,7 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
}
}
- drm_helper_disable_unused_functions(dev);
+ __drm_helper_disable_unused_functions(dev);
return 0;
}
@@ -776,7 +783,7 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
set->connectors[i]->funcs->dpms(set->connectors[i], DRM_MODE_DPMS_ON);
}
}
- drm_helper_disable_unused_functions(dev);
+ __drm_helper_disable_unused_functions(dev);
} else if (fb_changed) {
set->crtc->x = set->x;
set->crtc->y = set->y;
@@ -1009,7 +1016,7 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
}
/* disable the unused connectors while restoring the modesetting */
- drm_helper_disable_unused_functions(dev);
+ __drm_helper_disable_unused_functions(dev);
}
EXPORT_SYMBOL(drm_helper_resume_force_mode);
--
1.8.4.rc3
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On Thu, Mar 20, 2014 at 02:01:56PM +0100, Jean-Francois Moine wrote: > On Thu, 20 Mar 2014 13:32:24 +0100 > Sebastian Hesselbarth wrote: > > > > + - reg: I2C address - must be <0x70> > > > > TDA9983b datasheet says: > > > > "Bits A0 and A1 of the I2C-bus device address are externally selected > > by pins A0 and A1." > > > > Therefore, 0x70, 0x71, 0x72, and 0x73 are valid i2c addresses. > > Sebastian, > > That's interesting! > > For the Cubox and the AMX33XX boards, the I2C address of the HDMI > registers is 0x70, and the I2C address of the CEC registers is 0x34. > > For other boards using the TDA998x family, if the I2C address is > different from 0x70, have you an idea about what can be the CEC I2C > address? (this value is actually hard-coded in the TDA998x driver) For the TDA9983, it's configurable as Sebastian says. For the TDA19988, they're fixed at 0x70 and 0x34. To put it another way: it is chip specific, and is specified by the data sheet, not by the software, and should not be specified as an "required value" with any particular value in the DT binding specification. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[PATCH 2/2] drm/fb-helper: improve drm_fb_helper_initial_config locking
The locking in drm_fb_helper_initial_config is a bit troublesome for a few reasons: - We can't just wrap the entire function up into modeset locks since the fbdev registration might call down into fbcon code, which then through our ->set_par implementation needs to be able to grab all modeset locks. So we'd have a neat deadlock. - This implies though that all current callers don't hold any modeset locks by necessity, so we have free reign to grab any modeset locks we need to grab. - The private state of the fbdev helper doesn't need any protection through locks, since once we have the fbdev registered it is mostly invariant or protected through the modeset locking in ->set_par and other callbacks. We can fully rely on driver having non-racy setup sequences here. For the initial config computation we actually may not grab locks since drivers which provide their own magic sauce (like i915) might need to grab locks themselves. - We should grab locks though when we probe outputs. Currently there's not much risk, but already now userspace could start poking at sysfs files and so probe concurrently. I expect that in the future driver init will be much more async, and since probing is really time-consuming this is a prime candidate. - We must not hold any crtc->mutex locks while calling probe functions since those might need to lock a crtc for e.g. load detection. i915 is such a driver. Also it's the probing calls which hit upon piles of new locking asserts I've recently added in commit 62ff94a5492175759546f8bc61383189d6b49122 Author: Daniel Vetter Date: Thu Jan 23 22:18:47 2014 +0100 drm/crtc-helper: remove LOCKING from kerneldoc and commit 63951385052f7974155fa38f962f0f4e9847f90a Author: Daniel Vetter Date: Thu Jan 23 15:14:15 2014 +0100 drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c Hence the right fix is to grab the mode_config mutex, but only that and only right around the probe calls. It seems to be sufficient to shut up all the locking WARNINGs I see on i915 and nouveau in drm_fb_helper_initial_config. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_fb_helper.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 87876198801d..16f271e21b9c 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1536,9 +1536,11 @@ bool drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel) drm_fb_helper_parse_command_line(fb_helper); + mutex_lock(&dev->mode_config.mutex); count = drm_fb_helper_probe_connector_modes(fb_helper, dev->mode_config.max_width, dev->mode_config.max_height); + mutex_unlock(&dev->mode_config.mutex); /* * we shouldn't end up with no modes here. */ -- 1.8.4.rc3
[PATCH] ARM: dts: exynos4210-universal: add fimd polarization settings
The patch adds polarization flags to fimd node.
It fixes parallel display support.
Signed-off-by: Andrzej Hajda
---
Hi Inki,
Since polarization patches were not merged, polarization
settings should be provided to fimd via properties.
This patch fixes it.
Regards
Andrzej
---
arch/arm/boot/dts/exynos4210-universal_c210.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 21ca0b978..477208d 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -351,6 +351,8 @@
pinctrl-0 = <&lcd_clk>, <&lcd_data24>;
pinctrl-names = "default";
status = "okay";
+ samsung,invert-vden;
+ samsung,invert-vclk;
display-timings {
timing {
clock-frequency = <23492370>;
--
1.8.3.2
[PATCH 1/2] drm/crtc-helper: fix locking for drm_helper_disable_unused_functions
On Thu, Mar 20, 2014 at 02:26:34PM +0100, Daniel Vetter wrote: > We have two calling contexts for thise function: > > - In the crtc helper code itself as part of the ->set_config > implementation. In this calling context all modeset locks are > already held, as they should. > > - In drivers not implementing fastboot before the fbdev/fbcon setup > and initialization. This has been added for all drivers in > > commit 76a39dbfb2d1bc45219839e5a95d4ceaf6ca114f > Author: Daniel Vetter > Date: Sun Jan 20 23:12:54 2013 +0100 > > drm/fb-helper: don't disable everything in initial_config > > In this calling context we do not hold any modeset locks since the > immediately following call to initialize the fbev emulation grabs > all these locks themselves. > > - There are two exceptions to the above rule: shmob doesn't have fbdev > emulation support. I've manually checked the callchain up to the > driver load function and no kms locks are held. > > The right fix therefore is to split this helper into an internal and > external version and add the required locking to the function exported > to drivers. > > This remedies locking inconsistencies exposed by me adding locking > WARNs as part of the recent kerneldoc abi polishing done in > > commit 62ff94a5492175759546f8bc61383189d6b49122 > Author: Daniel Vetter > Date: Thu Jan 23 22:18:47 2014 +0100 > > drm/crtc-helper: remove LOCKING from kerneldoc > > and > > commit 63951385052f7974155fa38f962f0f4e9847f90a > Author: Daniel Vetter > Date: Thu Jan 23 15:14:15 2014 +0100 > > drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c > > v2: It helps when I actually git add the entire thing. > > Cc: Chris Wilson > Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
Intel G41 doesn't see any screens connected after suspend/resume
2014-03-20 3:46 GMT-04:00 Chris Wilson : > On Wed, Mar 19, 2014 at 08:15:05PM -0400, Nikolay Martynov wrote: >> Hi >> >> > >> > Perhaps you failed to install the modules that go with the kernel? >> I've built today's git version. The system boots but short after I >> log into X session system freezes. >> >> I can login via ssh and see dmesg: >> >> [ 58.699131] general protection fault: [#1] SMP >> [ 58.699173] Modules linked in: nls_utf8 udf crc_itu_t rfcomm bnep >> bluetooth 6lowpan_iphc binfmt_misc snd_usb_audio snd_usbmidi_lib >> gpio_ich ppdev gspca_zc3xx gspca_main videodev snd_hda_codec_realtek >> dm_multipath snd_hda_codec_generic snd_hda_intel scsi_dh snd_hda_codec >> snd_hwdep snd_pcm snd_seq_midi coretemp snd_seq_midi_event kvm_intel >> snd_rawmidi snd_seq kvm snd_seq_device snd_timer snd lpc_ich soundcore >> serio_raw parport_pc lp mac_hid asus_atk0110 parport raid10 raid456 >> async_raid6_recov async_memcpy async_pq async_xor async_tx xor >> raid6_pq raid0 multipath linear hid_generic usbhid hid raid1 i915 >> atl1e video i2c_algo_bit drm_kms_helper drm >> [ 58.699510] CPU: 0 PID: 1638 Comm: Xorg Tainted: GW >> 3.14.0-rc7-custom #2 >> [ 58.699537] Hardware name: System manufacturer System Product >> Name/P5G41-M LE, BIOS 050606/11/2010 >> [ 58.699578] task: 8800d0f498d0 ti: 8800cfcb8000 task.ti: >> 8800cfcb8000 >> [ 58.699603] RIP: 0010:[] [] >> i915_gem_object_set_cache_level+0x8a/0x310 [i915] >> [ 58.699677] RSP: 0018:8800cfcb9d60 EFLAGS: 00010246 >> [ 58.699701] RAX: 880036444000 RBX: dead00100098 RCX: >> 8800cfcfd158 >> [ 58.699725] RDX: 8800cfcfcfd8 RSI: 8800d086d0d0 RDI: >> 88011b401800 >> [ 58.699749] RBP: 8800cfcb9d90 R08: 00017340 R09: >> 88011fc17340 >> [ 58.699772] R10: ea0003421b40 R11: a00a1e33 R12: >> 8800cfcfcf00 >> [ 58.699796] R13: 0001 R14: 8800cf36c800 R15: >> 8800cfcfcfc0 >> [ 58.699821] FS: 7f3af20e1980() GS:88011fc0() >> knlGS: >> [ 58.699856] CS: 0010 DS: ES: CR0: 80050033 >> [ 58.699876] CR2: 7f52d8659000 CR3: d0fa2000 CR4: >> 000407f0 >> [ 58.699899] Stack: >> [ 58.699910] 0001cfcb9d88 8800cf36c800 8800cfcfcf00 >> fffe >> [ 58.699945] 0001 8800cf36c800 8800cfcb9dc0 >> a00a5144 >> [ 58.699978] 8800d0ea3000 006f fff2 >> 8800cfcb9e20 >> [ 58.700010] Call Trace: >> [ 58.700010] [] i915_gem_set_caching_ioctl+0x84/0xf0 >> [i915] >> [ 58.700010] [] drm_ioctl+0x4d2/0x600 [drm] >> [ 58.700010] [] ? native_sched_clock+0x35/0x90 >> [ 58.700010] [] ? native_sched_clock+0x35/0x90 >> [ 58.700010] [] ? sched_clock+0x9/0x10 >> [ 58.700010] [] do_vfs_ioctl+0x2e0/0x4c0 >> [ 58.700010] [] ? vtime_account_user+0x54/0x60 >> [ 58.700010] [] SyS_ioctl+0x81/0xa0 >> [ 58.700010] [] tracesys+0xe1/0xe6 >> [ 58.700010] Code: 90 f6 40 40 0f 0f 85 46 01 00 00 48 8b 42 68 49 >> 39 c7 48 8d 50 98 75 e9 44 8b 6d d4 0f 1f 44 00 00 49 8b 46 30 f6 40 >> 1c 20 75 25 43 20 20 74 1f 4c 89 ee 48 89 df e8 95 9e ff ff 84 c0 >> 75 10 >> [ 58.700010] RIP [] >> i915_gem_object_set_cache_level+0x8a/0x310 [i915] >> [ 58.700010] RSP >> [ 58.725088] ---[ end trace c84dd3681cbb815b ]--- >> >> Is this something expected on current git >> (ec45c7550806d1373db6915a4031a7ae2542d61f)? > > QA just reported it as well, > https://bugs.freedesktop.org/show_bug.cgi?id=76384 > > If you can find the corresponding line for > i915_gem_object_set_cache_level+0x8a > (gdb /path/to/i915.ko; list *i915_gem_object_set_cache_level+0x8a) > that would help. (gdb) list *i915_gem_object_set_cache_level+0x8a 0x24e3a is in i915_gem_object_set_cache_level (drivers/gpu/drm/i915/i915_gem.c:3147). 3142 * crossing memory domains and dying. 3143 */ 3144if (HAS_LLC(dev)) 3145return true; 3146 3147if (!drm_mm_node_allocated(gtt_space)) 3148return true; 3149 3150if (list_empty(>t_space->node_list)) 3151return true; Please let me know if there's anything else I can do. -- Martynov Nikolay. Email: mar.kolya at gmail.com
Intel G41 doesn't see any screens connected after suspend/resume
On Thu, Mar 20, 2014 at 09:38:17AM -0400, Nikolay Martynov wrote:
> (gdb) list *i915_gem_object_set_cache_level+0x8a
> 0x24e3a is in i915_gem_object_set_cache_level
> (drivers/gpu/drm/i915/i915_gem.c:3147).
> 3142 * crossing memory domains and dying.
> 3143 */
> 3144if (HAS_LLC(dev))
> 3145return true;
> 3146
> 3147if (!drm_mm_node_allocated(gtt_space))
> 3148return true;
> 3149
> 3150if (list_empty(>t_space->node_list))
> 3151return true;
>
> Please let me know if there's anything else I can do.
Can you please try:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 13fc490d1f62..4f71125493fd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3676,7 +3676,7 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
enum i915_cache_level cache_level)
{
struct drm_device *dev = obj->base.dev;
- struct i915_vma *vma;
+ struct i915_vma *vma, *next;
int ret;
if (obj->cache_level == cache_level)
@@ -3687,7 +3687,7 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
return -EBUSY;
}
- list_for_each_entry(vma, &obj->vma_list, vma_link) {
+ list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link) {
if (!i915_gem_valid_gtt_space(dev, &vma->node, cache_level)) {
ret = i915_vma_unbind(vma);
if (ret)
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On Thu, 20 Mar 2014 14:32:18 +0100 Sebastian Hesselbarth wrote: > Ok, I had another round of google'ing and found this: > http://hipstercircuits.com/wp-content/uploads/2013/05/TDA19988.pdf > > There, the datasheet specifically for TDA19988 only states 0x70 and > 0x34 as the two i2c addresses. Therefore, TDA19988 has fixed i2c > addresses while TDA9983b has configurable (main) i2c address. > > Not as easy as we thought ;) > > I suggest reword the reg property to: > "- reg: shall be set to the I2C address" > > and optionally list all known addresses for each TDA[1]998x in the > binding. Thanks for the link. OK, then, as the linux tda998x driver handles only the tda 19988 and 19989 chips, the HDMI I2C address is always 0x70. So, question: Russell and Sebastian, do you still want an other patch? Other question: the CEC address is hard-coded to 0x34 in the driver. Should it be configurable in the DT? -- Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[Bug 75433] xserver crashes after suspend with radeonsi and glamor, poor 2d performance
https://bugs.freedesktop.org/show_bug.cgi?id=75433 blaze changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from blaze --- Fixed since I've updated kernel to 3.14rc7. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/b621b303/attachment.html>
[Intel-gfx] [PATCH 1/4] drm: Added plane alpha and color blending property
On Sat, Mar 08, 2014 at 01:51:16PM +0530, sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> This patch creates a generic blending enum property.
> Drivers may support subset of these values.
>
> Cc: airlied at linux.ie
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Sagar Kamble
> ---
> drivers/gpu/drm/drm_crtc.c | 33 +
> include/drm/drm_crtc.h | 25 +
> 2 files changed, 58 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 4e43fc2..15281a3 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -4147,3 +4147,36 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> idr_destroy(&dev->mode_config.crtc_idr);
> }
> EXPORT_SYMBOL(drm_mode_config_cleanup);
> +
> +struct drm_property *drm_mode_create_blend_property(struct drm_device *dev,
> + unsigned int supported_factors)
> +{
> + static const struct drm_prop_enum_list props[] = {
> + { DRM_BLEND_NONE, "none" },
> + { DRM_BLEND_ZERO, "zero" },
> + { DRM_BLEND_ONE,"one" },
> + { DRM_BLEND_SRC_COLOR, "src-color" },
> + { DRM_BLEND_ONE_MINUS_SRC_COLOR,"one-minus-src-color" },
> + { DRM_BLEND_DST_COLOR, "dst-color" },
> + { DRM_BLEND_ONE_MINUS_DST_COLOR,"one-minus-dst-color" },
> + { DRM_BLEND_SRC_ALPHA, "src-alpha" },
> + { DRM_BLEND_ONE_MINUS_SRC_ALPHA,"one-minus-src-alpha" },
> + { DRM_BLEND_DST_ALPHA, "dst-alpha" },
> + { DRM_BLEND_ONE_MINUS_DST_ALPHA,"one-minus-dst-alpha" },
> + { DRM_BLEND_CONSTANT_COLOR, "constant-color" },
> + { DRM_BLEND_ONE_MINUS_CONSTANT_COLOR,
> "one-minus-constant-color" },
> + { DRM_BLEND_CONSTANT_ALPHA, "constant-alpha" },
> + { DRM_BLEND_ONE_MINUS_CONSTANT_ALPHA,
> "one-minus-constant-alpha" },
> + { DRM_BLEND_SRC_ALPHA_SATURATE, "alpha-saturate" },
> + { DRM_BLEND_SRC1_COLOR, "src1-color" },
> + { DRM_BLEND_ONE_MINUS_SRC1_COLOR, "one-minus-src1-color"
> },
> + { DRM_BLEND_SRC1_ALPHA, "src1-alpha" },
> + { DRM_BLEND_ONE_MINUS_SRC1_ALPHA, "one-minus-src1-alpha"
> },
> + { DRM_BLEND_PREMULTIPLIED_ALPHA,"pre-multiplied-alpha" }
> + };
Another few notes:
- You seem to assume that there's a need for DRM_BLEND_NONE, what would it
do? The property should default to DRM_BLEND_SRC_COLOR ie "Take the
color from this plane for the blending".
- There's no need to expose SRC1 variants, this was done in GL to expose a
second color the fragment shader can output, not applicable here.
--
Damien
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On Thu, Mar 20, 2014 at 02:52:21PM +0100, Jean-Francois Moine wrote: > Thanks for the link. > > OK, then, as the linux tda998x driver handles only the tda 19988 and > 19989 chips, the HDMI I2C address is always 0x70. > > So, question: Russell and Sebastian, do you still want an other patch? > > Other question: the CEC address is hard-coded to 0x34 in the driver. > Should it be configurable in the DT? As we haven't had a mainline non-rc kernel release with this in yet, we have more scope in what we can do to sort this out. What I'd suggest is: 1. change the DT compatible strings the driver has to accept both nxp,tda19988 and nxp,tda19989, and set the appropriate device in the DT file (tda19988). I'm a bit nervous about using "nxp,tda1998x" in case we're clashing with devices with different characteristics. 2. specify that the i2c reg address must exist, but not specify what it should be - leave that open. 3. assume that there's a CEC at 0x34 for these two devices. If we wish to extend support to tda998x, then we'd need to modify the driver quite a bit anyway. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[PATCH v2] drm: enable render-nodes by default
On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote: > On 03/20/2014 10:43 AM, David Herrmann wrote: > > Hi > > > > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom > > wrote: > >> A user logs in to a system where DRI clients use render nodes. The > >> system grants rw permission on the render nodes for the console user. > >> User starts editing a secret document, starts some GPGPU structural FEM > >> computations of the Pentagon building. Locks the screen and goes for > >> lunch. > >> > >> A malicious user logs in using fast user switching and becomes the owner > >> of the render node. Tries to map a couple of random offsets, but that > >> fails, due to security checks. Now crafts a malicious command stream to > >> dump all GPU memory to a file. Steals the first user's secret document > >> and the intermediate Pentagon data. Logs out and starts data mining. > >> > >> Now if we require drivers to block these malicious command streams this > >> can never happen, and distros can reliably grant rw access to the render > >> nodes to the user currently logged into the console. > >> > >> I guest basically what I'm trying to say that with the legacy concept it > >> was OK to access all GPU memory, because an authenticated X user > >> basically had the same permissions. > >> > >> With render nodes we're allowing multiple users into the GPU at the same > >> time, and it's not OK anymore for a client to access another clients GPU > >> buffer through a malicious command stream. > > Yes, I understand the attack scenario, but that's not related to > > render-nodes at all. The exact same races exist on the legacy node: > > I was under the impression that render nodes were designed to fix these > issues? > > > > > 1) If you can do fast-user switching, you can spawn your own X-server, > > get authenticated on your own server and you are allowed into the GPU. > > You cannot map other user's buffers because they're on a different > > master-object, but you _can_ craft malicious GPU streams and access > > the other user's buffer. > > But with legacy nodes, drivers can (and should IMO) throw out all data > from GPU memory on master drop, > and then block dropped master authenticated clients from GPU, until > their master becomes active again or dies (in which case they are > killed). In line with a previous discussion we had. Now you can't do > this with render nodes, so yes they do open up > a new race that requires command stream validation. > > > > > 2) If you can do fast-user switching, switch to an empty VT, open the > > legacy node and you automatically become DRM-Master because there is > > no active master. Now you can do anything on the DRM node, including > > crafting malicious GPU streams. > > I believe the above solution should work for this case as well. > > > > > Given that the legacy node is always around and _always_ has these > > races, why should we prevent render-nodes from appearing just because > > the _driver_ is racy? I mean, there is no gain in that.. if it opens a > > new race, as you assumed, then yes, we should avoid it. But at least > > for all drivers supporting render-nodes so far, they either are > > entirely safe or the just described races exist on both nodes. > > My suggestion is actually not to prevent render nodes from appearing, > but rather that we should restrict them to drivers with command stream > verification and / or per process virtual memory, and I also think we > should plug the above races on legacy nodes. That way legacy nodes would > use the old "master owns it all" model, while render nodes could allow > multiple users at the same time. FYI both radeon and nouveau (last time i check) can not be abuse to access random VRAM or buffer bind by another process (except if the buffer is share of course). So there is no way (modulo any bug in command stream checking or hardware) to abuse render node to access any memory that you do not have the right to access. I am pretty sure this stands for Intel too, i do not know if others drm driver have this kind of assurance. In any case this is not a render node issue and there is no reasons to force full VRAM eviction or anything like that. Cheers, J?r?me
[PATCH v2] drm: enable render-nodes by default
On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse wrote: > On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote: >> On 03/20/2014 10:43 AM, David Herrmann wrote: >> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom >> > wrote: >> > Given that the legacy node is always around and _always_ has these >> > races, why should we prevent render-nodes from appearing just because >> > the _driver_ is racy? I mean, there is no gain in that.. if it opens a >> > new race, as you assumed, then yes, we should avoid it. But at least >> > for all drivers supporting render-nodes so far, they either are >> > entirely safe or the just described races exist on both nodes. >> >> My suggestion is actually not to prevent render nodes from appearing, >> but rather that we should restrict them to drivers with command stream >> verification and / or per process virtual memory, and I also think we >> should plug the above races on legacy nodes. That way legacy nodes would >> use the old "master owns it all" model, while render nodes could allow >> multiple users at the same time. > > FYI both radeon and nouveau (last time i check) can not be abuse to access > random VRAM or buffer bind by another process (except if the buffer is share > of course). I'm not aware of any restrictions in nouveau that would prevent you from accessing any vram... there are a number of copy engines accessible that would allow you to copy one region to another, and I'm not aware of code to validate pushbuf contents (it would have to parse the pushbuf and know which methods store source/destination addresses). You could probably get creative and use that to overwrite the MMU tables, to then gain the ability to read/write any part of system memory... but perhaps the engines won't allow you to do that, not sure. (Or perhaps the PDE isn't mapped into VRAM. Again, not sure.) -ilia
[PATCH v2] drm: enable render-nodes by default
On 03/20/2014 03:36 PM, Jerome Glisse wrote: > > In any case this is not a render node issue and there is no reasons to force > full VRAM eviction or anything like that. This comment suggests you haven't read the discussion fully. VRAM eviction was discussed in the context of legacy nodes. This is a render node issue because with legacy nodes you can work around insufficient command checking. With render nodes you can't. /Thomas > Cheers, > J?r?me
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On Thu, 20 Mar 2014 14:31:10 + Russell King - ARM Linux wrote: > 1. change the DT compatible strings the driver has to accept both >nxp,tda19988 and nxp,tda19989, and set the appropriate device >in the DT file (tda19988). I'm a bit nervous about using >"nxp,tda1998x" in case we're clashing with devices with different >characteristics. The Cubox is sold with either the TDA19988 or the TDA19989 (I don't know about the AMX33XX boards). Then, setting the exact type in the DT would ask for 2 differents DTs or for having two tda998x definitions in a same DT... -- Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[PATCH 0/6] File Sealing & memfd_create()
Hi On Thu, Mar 20, 2014 at 3:41 PM, One Thousand Gnomes wrote: > I think you want two things at minimum > > owner to seal > root can always override Why should root be allowed to override? > I would query the name too. Right now your assumption is 'shmem only' but > that might change with other future use cases or types (eg some driver > file handles) so SHMEM_ in the fcntl might become misleading. I'm fine with F_SET/GET_SEALS. But given you suggested requiring MFD_ALLOW_SEALS for sealing, I don't see why we couldn't limit this interface entirely to memfd_create(). > Whether you want some way to undo a seal without an exclusive reference as > the file owner is another question. No. You are never allowed to undo a seal but with an exclusive reference. This interface was created for situations _without_ any trust relationship. So if the owner is allowed to undo seals, the interface doesn't make any sense. The only options I see is to not allow un-sealing at all (which I'm fine with) or tracking users (which is way too much overhead). Thanks David
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On Thu, Mar 20, 2014 at 9:59 AM, Jean-Francois Moine wrote: > On Thu, 20 Mar 2014 14:31:10 + > Russell King - ARM Linux wrote: > >> 1. change the DT compatible strings the driver has to accept both >>nxp,tda19988 and nxp,tda19989, and set the appropriate device >>in the DT file (tda19988). I'm a bit nervous about using >>"nxp,tda1998x" in case we're clashing with devices with different >>characteristics. > > The Cubox is sold with either the TDA19988 or the TDA19989 (I don't > know about the AMX33XX boards). Then, setting the exact type in the DT > would ask for 2 differents DTs or for having two tda998x definitions in > a same DT... fyi: On the AM335x (BeagleBone Black), the NXP's chip ink shows, 88BHN so TDA19988 Regards, -- Robert Nelson http://www.rcn-ee.com/
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On Thu, Mar 20, 2014 at 03:59:35PM +0100, Jean-Francois Moine wrote: > On Thu, 20 Mar 2014 14:31:10 + > Russell King - ARM Linux wrote: > > > 1. change the DT compatible strings the driver has to accept both > >nxp,tda19988 and nxp,tda19989, and set the appropriate device > >in the DT file (tda19988). I'm a bit nervous about using > >"nxp,tda1998x" in case we're clashing with devices with different > >characteristics. > > The Cubox is sold with either the TDA19988 or the TDA19989 (I don't > know about the AMX33XX boards). Then, setting the exact type in the DT > would ask for 2 differents DTs or for having two tda998x definitions in > a same DT... I'm not saying that it has to match the physical device fitted - I'm merely suggesting not using nxp,tda1998x which could (and as Sebastian has found, does) conflict with other devices with different properties. We still auto-detect the exact device type by reading the ID register because that's the most reliable way to detect exactly what kind of device is fitted to the board. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[RFC libdrm 0/6] Add NVIDIA Tegra support
On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding wrote: > From: Thierry Reding > > Hi, > > This series adds libdrm-tegra with a very lightweight API on top of the > kernel interfaces. Most of the functions provided here have been in use > in various driver efforts in different incarnations. This is an attempt > to consolidate, so I'm looking for review comments especially by Erik > to ensure it can be used by grate. Is there anything I can do to move this series along?
[PATCH v2] drm: enable render-nodes by default
On Thu, Mar 20, 2014 at 03:59:17PM +0100, Thomas Hellstrom wrote: > On 03/20/2014 03:36 PM, Jerome Glisse wrote: > > > > In any case this is not a render node issue and there is no reasons to force > > full VRAM eviction or anything like that. > > This comment suggests you haven't read the discussion fully. > > VRAM eviction was discussed in the context of legacy nodes. > > This is a render node issue because with legacy nodes you can work > around insufficient command checking. > With render nodes you can't. On radeon you can not abuse the GPU period legacy node or not. My comment was about the fact that this is a driver issue and not a render node issue. I would consider driver that allow to abuse the GPU block to access any memory as broken no matter if we are talking about legacy or new render node. Cheers, J?r?me > > /Thomas > > > Cheers, > > J?r?me
[PATCH v4 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
crtc *crtc,
> goto finish;
> }
>
> - /* Currently we only support 64x64 cursors */
> - if (width != 64 || height != 64) {
> - DRM_ERROR("we currently only support 64x64 cursors\n");
> + /* Check for which cursor types we support */
> + if (!((width == 64 && height == 64) ||
> + (width == 128 && height == 128 && !IS_GEN2(dev)) ||
> + (width == 256 && height == 256 && !IS_GEN2(dev {
> + DRM_DEBUG("Cursor dimension not supported\n");
> return -EINVAL;
> }
>
> @@ -10331,6 +10364,16 @@ static void intel_crtc_init(struct drm_device *dev,
> int pipe)
>
> drm_crtc_init(dev, &intel_crtc->base, &intel_crtc_funcs);
>
> + if (IS_GEN2(dev)) {
> + intel_crtc->max_cursor_width = GEN2_CURSOR_WIDTH;
> + intel_crtc->max_cursor_height = GEN2_CURSOR_HEIGHT;
> + } else {
> + intel_crtc->max_cursor_width = CURSOR_WIDTH;
> + intel_crtc->max_cursor_height = CURSOR_HEIGHT;
> + }
> + dev->mode_config.cursor_width = intel_crtc->max_cursor_width;
> + dev->mode_config.cursor_height = intel_crtc->max_cursor_height;
> +
> drm_mode_crtc_set_gamma_size(&intel_crtc->base, 256);
> for (i = 0; i < 256; i++) {
> intel_crtc->lut_r[i] = i;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 9c70905..eca4a0a 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -78,6 +78,12 @@
> #define MAX_OUTPUTS 6
> /* maximum connectors per crtcs in the mode set */
>
> +/* Maximum cursor sizes */
> +#define GEN2_CURSOR_WIDTH 64
> +#define GEN2_CURSOR_HEIGHT 64
> +#define CURSOR_WIDTH 256
> +#define CURSOR_HEIGHT 256
> +
> #define INTEL_I2C_BUS_DVO 1
> #define INTEL_I2C_BUS_SDVO 2
>
> @@ -364,6 +370,7 @@ struct intel_crtc {
> uint32_t cursor_addr;
> int16_t cursor_x, cursor_y;
> int16_t cursor_width, cursor_height;
> + int16_t max_cursor_width, max_cursor_height;
> bool cursor_visible;
>
> struct intel_crtc_config config;
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/e3620f4f/attachment.sig>
[RFCv3 04/14] drm/exynos: Restrict plane loops to only operate on overlay planes
On Thu, Mar 20, 2014 at 09:56:24AM +0800, Daniel Kurtz wrote:
> On Thu, Mar 20, 2014 at 3:31 AM, Daniel Vetter wrote:
> > On Wed, Mar 19, 2014 at 10:26:13PM +0800, Daniel Kurtz wrote:
> >> On Wed, Mar 19, 2014 at 7:51 PM, Daniel Vetter wrote:
> >> > On Tue, Mar 18, 2014 at 05:22:49PM -0700, Matt Roper wrote:
> >> >> Before we add additional types of planes to the DRM plane list, ensure
> >> >> that existing loops over all planes continue to operate only on
> >> >> "overlay" planes and ignore primary & cursor planes.
> >> >>
> >> >> Cc: Inki Dae
> >> >> Signed-off-by: Matt Roper
> >> >> ---
> >> >> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 ++
> >> >> 1 file changed, 6 insertions(+)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> >> >> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> >> >> index 06f1b2a..2fa2685 100644
> >> >> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> >> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> >> >> @@ -127,6 +127,9 @@ static void disable_plane_to_crtc(struct drm_device
> >> >> *dev,
> >> >>* (encoder->crtc)
> >> >>*/
> >> >> list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> >> >> + if (plane->type != DRM_PLANE_TYPE_OVERLAY)
> >> >
> >> > I think a drm_for_each_legacy_plane iteration helper would be neat for
> >> > this one and the following i915 patch.
> >> > -Daniel
> >> >
> >> >> + continue;
> >> >> +
> >> >> if (plane->crtc == old_crtc) {
> >> >> /*
> >> >>* do not change below call order.
> >> >> @@ -247,6 +250,9 @@ static void exynos_drm_encoder_disable(struct
> >> >> drm_encoder *encoder)
> >> >>
> >> >> /* all planes connected to this encoder should be also disabled.
> >> >> */
> >> >> list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> >> >> + if (plane->type != DRM_PLANE_TYPE_OVERLAY)
> >> >> + continue;
> >> >> +
> >> >> if (plane->crtc == encoder->crtc)
> >> >> plane->funcs->disable_plane(plane);
> >> >> }
> >>
> >> The original loop disables all planes attached to a crtc when
> >> disabling an encoder attached to the same crtc. It was added by:
> >>
> >> commit bcf4cef94294992f7cd11d5a90fa58b0eae6c795
> >> Author: Inki Dae
> >> Date: Fri Aug 24 10:54:12 2012 -0700
> >>
> >> drm/exynos: Disable plane when released
> >>
> >> this patch ensures that each plane connected to encoder is disabled
> >> when released, by adding disable callback function of encoder helper
> >>
> >> we had faced with one issue that invalid memory is accessed by dma
> >> once drm is released and then the dma is turned on again. actually,
> >> in our case, page fault was incurred with iommu. the reason is that
> >> a gem buffer accessed by the dma is also released once drm is released.
> >>
> >> so this patch would fix this issue ensuring the dma is disabled
> >> when released.
> >>
> >>
> >> An encoder receives and encodes the mixed output of all of the
> >> planes/overlays. It would seem that whether the individual planes
> >> themselves are enabled or not should be completely independent of the
> >> status any encoder. However, I find the code in exynos_drm_encoder.c
> >> very difficult to follow, so perhaps there is some extra linkage
> >> between encoder/crtc/plane that is exynos specific.
> >>
> >> In any case, judging from the commit message, this disable loop should
> >> probably still iterate over all of the planes, not just the
> >> "DRM_PLANE_TYPE_OVERLAY" ones. So, I think this new patch is
> >> incorrect.
> >
> > It keeps full backwars compatibility with existing semantics, which is the
> > right thing to do in such a case. It could be that exynos simply has a
> > bug, but imo that should be a separate patch outside of this series.
>
> Indeed... I missed the fact that in the existing code, the "priv"
> (now primary) plane is not added to the plane_list, so it wouldn't
> actually be disabled in this loop here anyway.
>
> New question: are the planes that will become DRM_PLANE_TYPE_CURSOR
> formerly "priv", or not?
> If they were not, then I think the backwards- and forwards- compatible loop
> is:
>
> list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> if (plane->type == DRM_PLANE_TYPE_PRIMARY)
> continue;
> /* do something with legacy planes */
> }
Cursor planes haven't been exposed at all as plane objects before, not
even as private driver objects. So they'd need to be excluded here too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2] drm: enable render-nodes by default
On Thu, Mar 20, 2014 at 10:44:10AM -0400, Ilia Mirkin wrote: > On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse wrote: > > On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote: > >> On 03/20/2014 10:43 AM, David Herrmann wrote: > >> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom > >> > wrote: > >> > Given that the legacy node is always around and _always_ has these > >> > races, why should we prevent render-nodes from appearing just because > >> > the _driver_ is racy? I mean, there is no gain in that.. if it opens a > >> > new race, as you assumed, then yes, we should avoid it. But at least > >> > for all drivers supporting render-nodes so far, they either are > >> > entirely safe or the just described races exist on both nodes. > >> > >> My suggestion is actually not to prevent render nodes from appearing, > >> but rather that we should restrict them to drivers with command stream > >> verification and / or per process virtual memory, and I also think we > >> should plug the above races on legacy nodes. That way legacy nodes would > >> use the old "master owns it all" model, while render nodes could allow > >> multiple users at the same time. > > > > FYI both radeon and nouveau (last time i check) can not be abuse to access > > random VRAM or buffer bind by another process (except if the buffer is share > > of course). > > I'm not aware of any restrictions in nouveau that would prevent you > from accessing any vram... there are a number of copy engines > accessible that would allow you to copy one region to another, and I'm > not aware of code to validate pushbuf contents (it would have to parse > the pushbuf and know which methods store source/destination > addresses). You could probably get creative and use that to overwrite > the MMU tables, to then gain the ability to read/write any part of > system memory... but perhaps the engines won't allow you to do that, > not sure. (Or perhaps the PDE isn't mapped into VRAM. Again, not > sure.) > > -ilia Well i obviously have not look at that in long time, but if the nouveau API can be abuse than i consider this a broken by design. I know command checking is painfull and CPU intensive but we have done it in radeon for a reason. Cheers, J?r?me
[RFCv3 07/14] drm: Specify primary plane at CRTC initialization (v2)
On Thu, Mar 20, 2014 at 02:43:11PM +0900, Inki Dae wrote: > Your patch would make kms requests to be broken. Exynos drm uses a > wrapper structure, exynos_plane, including original drm_plane, and > also a overlay object specific to exynos should be sent to crtc driver > through exynos_plane. > > And re-factoring patch series for exynos drm framework will go to > -next soon. So how about that other maintainers can adopt your primary > plane feature individually later? For this, I guess you would need to > keep backward compatibility. We would really need the testing enough > for such feature and big changes. All my review thus far has been aimed at reducing subsystem-wide changes to drivers. I think we can do the full primary plane conversion without touching drivers at all. Of course there's a bit of cleanup, but driver maintainers can merge that at their own pace (and so avoid ugly conflicts with ongoing work). I'm still working on how to reduce the impact for the cursor plane conversion as much as possible, but that's going to be fairly hard unfortunately. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v4 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
crtc *crtc,
> goto finish;
> }
>
> - /* Currently we only support 64x64 cursors */
> - if (width != 64 || height != 64) {
> - DRM_ERROR("we currently only support 64x64 cursors\n");
> + /* Check for which cursor types we support */
> + if (!((width == 64 && height == 64) ||
> + (width == 128 && height == 128 && !IS_GEN2(dev)) ||
> + (width == 256 && height == 256 && !IS_GEN2(dev {
> + DRM_DEBUG("Cursor dimension not supported\n");
> return -EINVAL;
> }
>
> @@ -10331,6 +10364,16 @@ static void intel_crtc_init(struct drm_device *dev,
> int pipe)
>
> drm_crtc_init(dev, &intel_crtc->base, &intel_crtc_funcs);
>
> + if (IS_GEN2(dev)) {
> + intel_crtc->max_cursor_width = GEN2_CURSOR_WIDTH;
> + intel_crtc->max_cursor_height = GEN2_CURSOR_HEIGHT;
> + } else {
> + intel_crtc->max_cursor_width = CURSOR_WIDTH;
> + intel_crtc->max_cursor_height = CURSOR_HEIGHT;
> + }
> + dev->mode_config.cursor_width = intel_crtc->max_cursor_width;
> + dev->mode_config.cursor_height = intel_crtc->max_cursor_height;
> +
> drm_mode_crtc_set_gamma_size(&intel_crtc->base, 256);
> for (i = 0; i < 256; i++) {
> intel_crtc->lut_r[i] = i;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 9c70905..eca4a0a 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -78,6 +78,12 @@
> #define MAX_OUTPUTS 6
> /* maximum connectors per crtcs in the mode set */
>
> +/* Maximum cursor sizes */
> +#define GEN2_CURSOR_WIDTH 64
> +#define GEN2_CURSOR_HEIGHT 64
> +#define CURSOR_WIDTH 256
> +#define CURSOR_HEIGHT 256
> +
> #define INTEL_I2C_BUS_DVO 1
> #define INTEL_I2C_BUS_SDVO 2
>
> @@ -364,6 +370,7 @@ struct intel_crtc {
> uint32_t cursor_addr;
> int16_t cursor_x, cursor_y;
> int16_t cursor_width, cursor_height;
> + int16_t max_cursor_width, max_cursor_height;
> bool cursor_visible;
>
> struct intel_crtc_config config;
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/7c05d963/attachment.sig>
[PATCH 0/6] File Sealing & memfd_create()
Hi On Thu, Mar 20, 2014 at 4:32 PM, wrote: > Why not make sealing an attribute of the "struct file", and enforce it > at the VFS layer? That way all file system objects would have access > to sealing interface, and for memfd_shmem, you can't get another > struct file pointing at the object, the security properties would be > identical. Sealing as introduced here is an inode-attribute, not "struct file". This is intentional. For instance, a gfx-client can get a read-only FD via /proc/self/fd/ and pass it to the compositor so it can never overwrite the contents (unless the compositor has write-access to the inode itself, in which case it can just re-open it read-write). Furthermore, I don't see any use-case besides memfd for sealing, so I purposely avoided changing core VFS interfaces. Protecting page-allocation/access for SEAL_WRITE like I do in shmem.c is not that easy to do generically. So if we moved this interface to "struct inode", all that would change is moving "u32 seals;" from one struct to the other. Ok, some protections might get easily implemented generically, but I without proper insight in the underlying implemenation, I couldn't verify all paths and possible races. Isn't keeping the API generic enough so far? Changing the underlying implementation can be done once we know what we want. Thanks David
[PATCH v2] drm: enable render-nodes by default
On 03/20/2014 04:34 PM, Jerome Glisse wrote: > On Thu, Mar 20, 2014 at 03:59:17PM +0100, Thomas Hellstrom wrote: >> On 03/20/2014 03:36 PM, Jerome Glisse wrote: >>> In any case this is not a render node issue and there is no reasons to force >>> full VRAM eviction or anything like that. >> This comment suggests you haven't read the discussion fully. >> >> VRAM eviction was discussed in the context of legacy nodes. >> >> This is a render node issue because with legacy nodes you can work >> around insufficient command checking. >> With render nodes you can't. > On radeon you can not abuse the GPU period legacy node or not. My comment > was about the fact that this is a driver issue and not a render node issue. > I would consider driver that allow to abuse the GPU block to access any > memory as broken no matter if we are talking about legacy or new render > node. > > Cheers, > J?r?me > Great. Then I assume you don't have an issue with not enabling render-nodes for those broken drivers, (or at least a sysfs property or something similar flagging those device nodes as broken)? Thanks, Thomas
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On Thu, 20 Mar 2014 15:19:34 + Russell King - ARM Linux wrote: > I'm not saying that it has to match the physical device fitted - I'm > merely suggesting not using nxp,tda1998x which could (and as Sebastian > has found, does) conflict with other devices with different properties. > > We still auto-detect the exact device type by reading the ID register > because that's the most reliable way to detect exactly what kind of > device is fitted to the board. I don't see the problem. Actually the driver handles the tda9989, tda19988 and tda19989 (2 variants). If some board has, for example, the tda9983 and if the driver is extended to handle this chip (i.e. mainly ignore the CEC part), setting 'nxp,tda998x' in the associated DT will still work. There could be a problem if somebody would write a specific driver for, say, a tda9985. But, then, the compatible would be 'nxp,tda9985'. -- Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[PATCH 0/6] File Sealing & memfd_create()
On Wed, Mar 19, 2014 at 08:06:45PM +0100, David Herrmann wrote: > > This series introduces the concept of "file sealing". Sealing a file restricts > the set of allowed operations on the file in question. Multiple seals are > defined and each seal will cause a different set of operations to return EPERM > if it is set. The following seals are introduced: > > * SEAL_SHRINK: If set, the inode size cannot be reduced > * SEAL_GROW: If set, the inode size cannot be increased > * SEAL_WRITE: If set, the file content cannot be modified Looking at your patches, and what files you are modifying, you are enforcing this in the low-level file system. Why not make sealing an attribute of the "struct file", and enforce it at the VFS layer? That way all file system objects would have access to sealing interface, and for memfd_shmem, you can't get another struct file pointing at the object, the security properties would be identical. Cheers, - Ted
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On Thu, Mar 20, 2014 at 04:54:40PM +0100, Jean-Francois Moine wrote: > On Thu, 20 Mar 2014 15:19:34 + > Russell King - ARM Linux wrote: > > > I'm not saying that it has to match the physical device fitted - I'm > > merely suggesting not using nxp,tda1998x which could (and as Sebastian > > has found, does) conflict with other devices with different properties. > > > > We still auto-detect the exact device type by reading the ID register > > because that's the most reliable way to detect exactly what kind of > > device is fitted to the board. > > I don't see the problem. > > Actually the driver handles the tda9989, tda19988 and tda19989 (2 > variants). If some board has, for example, the tda9983 and if the > driver is extended to handle this chip (i.e. mainly ignore the CEC > part), setting 'nxp,tda998x' in the associated DT will still work. So you have to encode in the driver that if you see a tda9983 device, you don't touch the CEC part. Now think about how you'd handle a tda998x compatible device but with the CEC stuff at a different I2C address. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[PATCH v4 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
On Thu, Mar 20, 2014 at 05:30:43PM +0200, Imre Deak wrote: > On Mon, 2014-03-10 at 17:06 +0530, sagar.a.kamble at intel.com wrote: > > From: Sagar Kamble > > > > With this patch we allow larger cursor planes of sizes 128x128 > > and 256x256. > > > > v2: Added more precise check on size while setting cursor plane. > > > > v3: Changes related to restructuring cursor size restrictions > > and DRM_DEBUG usage. > > > > v4: Indentation related changes for setting cursor control and > > implementing DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT > > > > Testcase: igt/kms_cursor_crc > > Cc: Daniel Vetter > > Cc: Jani Nikula > > Cc: David Airlie > > Cc: dri-devel at lists.freedesktop.org > > Cc: linux-kernel at vger.kernel.org > > Signed-off-by: G, Pallavi > > Signed-off-by: Sagar Kamble > > Looks ok: > Reviewed-by: Imre Deak Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 0/6] File Sealing & memfd_create()
On Thu, Mar 20, 2014 at 04:48:30PM +0100, David Herrmann wrote: > On Thu, Mar 20, 2014 at 4:32 PM, wrote: > > Why not make sealing an attribute of the "struct file", and enforce it > > at the VFS layer? That way all file system objects would have access > > to sealing interface, and for memfd_shmem, you can't get another > > struct file pointing at the object, the security properties would be > > identical. > > Sealing as introduced here is an inode-attribute, not "struct file". > This is intentional. For instance, a gfx-client can get a read-only FD > via /proc/self/fd/ and pass it to the compositor so it can never > overwrite the contents (unless the compositor has write-access to the > inode itself, in which case it can just re-open it read-write). Hmm, good point. I had forgotten about the /proc/self/fd hole. Hmm... what if we have a SEAL_PROC which forces the permissions of /proc/self/fd to be 000? So if it is a property of the attribute, SEAL_WRITE and SEAL_GROW is basically equivalent to using chattr to set the immutable and append-only attribute, except for the "you can't undo the seal unless you have exclusive access to the inode" magic. That does make it pretty memfd_create specific and not a very general API, which is a little unfortunate; hence why I'm trying to explore ways of making a bit more generic and hopefully useful for more use cases. Cheers, - Ted
[PATCH v2] drm: enable render-nodes by default
On Thu, Mar 20, 2014 at 04:49:42PM +0100, Thomas Hellstrom wrote: > On 03/20/2014 04:34 PM, Jerome Glisse wrote: > > On Thu, Mar 20, 2014 at 03:59:17PM +0100, Thomas Hellstrom wrote: > >> On 03/20/2014 03:36 PM, Jerome Glisse wrote: > >>> In any case this is not a render node issue and there is no reasons to > >>> force > >>> full VRAM eviction or anything like that. > >> This comment suggests you haven't read the discussion fully. > >> > >> VRAM eviction was discussed in the context of legacy nodes. > >> > >> This is a render node issue because with legacy nodes you can work > >> around insufficient command checking. > >> With render nodes you can't. > > On radeon you can not abuse the GPU period legacy node or not. My comment > > was about the fact that this is a driver issue and not a render node issue. > > I would consider driver that allow to abuse the GPU block to access any > > memory as broken no matter if we are talking about legacy or new render > > node. > > > > Cheers, > > J?r?me > > > > Great. Then I assume you don't have an issue with not enabling > render-nodes for those broken drivers, > (or at least a sysfs property or something similar flagging those device > nodes as broken)? > > Thanks, > Thomas > > Yes, broken driver should not have render node, at leadt in my view. Cheers, J?r?me
[PATCH v2] ASoC: tda998x: Fix lack of required reg in DT documentation
The I2C address (reg) is required for the TDA998x driver to be loaded and initialized. Signed-off-by: Jean-Francois Moine --- - v2 - don't force the I2C address to be 0x70 This patch applies to linux-next. --- Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt index d7df01c..fc7effa 100644 --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt @@ -3,6 +3,8 @@ Device-Tree bindings for the NXP TDA998x HDMI transmitter Required properties; - compatible: must be "nxp,tda998x" + - reg: I2C address + Optional properties: - interrupts: interrupt number and trigger type default: polling -- 1.9.1 -- Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[PATCH 1/1] drm/gma500: Code cleanup - inline documentation
Mainly styling fixes of inline documentation
Signed-off-by: Arthur Borsboom
---
drivers/gpu/drm/gma500/framebuffer.c | 36 ++--
drivers/gpu/drm/gma500/psb_intel_display.c | 35 ++--
drivers/gpu/drm/gma500/psb_intel_reg.h | 259 +
drivers/gpu/drm/gma500/psb_irq.c | 64 +++
4 files changed, 181 insertions(+), 213 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index e7fcc14..0dd015a 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -103,8 +103,10 @@ static int psbfb_pan(struct fb_var_screeninfo *var, struct
fb_info *info)
* the actual fb is mapped. In our case that isn't quite true.
*/
if (psbfb->gtt->npage) {
- /* GTT roll shifts in 4K pages, we need to shift the right
- number of pages */
+ /*
+* GTT roll shifts in 4K pages, we need to shift the right
+ number of pages
+*/
int pages = info->fix.line_length >> 12;
psb_gtt_roll(dev, psbfb->gtt, var->yoffset * pages);
}
@@ -229,7 +231,7 @@ static struct fb_ops psbfb_unaccel_ops = {
.fb_ioctl = psbfb_ioctl,
};
-/**
+/*
* psb_framebuffer_init- initialize a framebuffer
* @dev: our DRM device
* @fb: framebuffer to set up
@@ -270,7 +272,7 @@ static int psb_framebuffer_init(struct drm_device *dev,
return 0;
}
-/**
+/*
* psb_framebuffer_create - create a framebuffer backed by gt
* @dev: our DRM device
* @mode_cmd: the description of the requested mode
@@ -302,7 +304,7 @@ static struct drm_framebuffer *psb_framebuffer_create
return &fb->base;
}
-/**
+/*
* psbfb_alloc - allocate frame buffer memory
* @dev: the DRM device
* @aligned_size: space needed
@@ -327,7 +329,7 @@ static struct gtt_range *psbfb_alloc(struct drm_device
*dev, int aligned_size)
return NULL;
}
-/**
+/*
* psbfb_create- create a framebuffer
* @fbdev: the framebuffer device
* @sizes: specification of the layout
@@ -386,9 +388,9 @@ static int psbfb_create(struct psb_fbdev *fbdev,
if (backing == NULL) {
/*
-* We couldn't get the space we wanted, fall back to the
-* display engine requirement instead. The HW requires
-* the pitch to be 64 byte aligned
+* We couldn't get the space we wanted, fall back to the
+* display engine requirement instead. The HW requires
+* the pitch to be 64 byte aligned
*/
gtt_roll = 0; /* Don't use GTT accelerated scrolling */
@@ -489,7 +491,7 @@ out_err1:
return ret;
}
-/**
+/*
* psb_user_framebuffer_create - create framebuffer
* @dev: our DRM device
* @filp: client file
@@ -549,9 +551,11 @@ static int psbfb_probe(struct drm_fb_helper *helper,
if (bytespp == 3) /* no 24bit packed */
bytespp = 4;
- /* If the mode will not fit in 32bit then switch to 16bit to get
+ /*
+* If the mode will not fit in 32bit then switch to 16bit to get
a console on full resolution. The X mode setting server will
- allocate its own 32bit GEM framebuffer */
+ allocate its own 32bit GEM framebuffer
+*/
if (ALIGN(sizes->fb_width * bytespp, 64) * sizes->fb_height >
dev_priv->vram_stolen_size) {
sizes->surface_bpp = 16;
@@ -633,7 +637,7 @@ static void psbfb_output_poll_changed(struct drm_device
*dev)
drm_fb_helper_hotplug_event(&fbdev->psb_fb_helper);
}
-/**
+/*
* psb_user_framebuffer_create_handle - add hamdle to a framebuffer
* @fb: framebuffer
* @file_priv: our DRM file
@@ -652,7 +656,7 @@ static int psb_user_framebuffer_create_handle(struct
drm_framebuffer *fb,
return drm_gem_handle_create(file_priv, &r->gem, handle);
}
-/**
+/*
* psb_user_framebuffer_destroy- destruct user created fb
* @fb: framebuffer
*
@@ -666,7 +670,7 @@ static void psb_user_framebuffer_destroy(struct
drm_framebuffer *fb)
/* Let DRM do its clean up */
drm_framebuffer_cleanup(fb);
- /* We are no longer using the resource in GEM */
+ /* We are no longer using the resource in GEM */
drm_gem_object_unreference_unlocked(&r->gem);
kfree(fb);
}
@@ -761,7 +765,7 @@ void psb_modeset_init(struct drm_device *dev)
dev->mode_config.funcs = &psb_mode_funcs;
/* set memory base */
- /* Oaktrail and Poulsbo should use BAR 2*/
+ /* Oaktrail and Poulsbo should use BAR 2 */
pci_read_config_dword(dev->pdev, PSB_BSM, (u32 *)
&(dev->mode_config
[PATCH 1/1] drm/gma500: Code cleanup - styling
Removed line return in the middle of function argument list. Signed-off-by: Arthur Borsboom --- drivers/gpu/drm/gma500/psb_intel_display.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c b/drivers/gpu/drm/gma500/psb_intel_display.c index b11cbd6..eb91fa7 100644 --- a/drivers/gpu/drm/gma500/psb_intel_display.c +++ b/drivers/gpu/drm/gma500/psb_intel_display.c @@ -547,8 +547,7 @@ void psb_intel_crtc_init(struct drm_device *dev, int pipe, gma_crtc->mode_dev = mode_dev; gma_crtc->cursor_addr = 0; - drm_crtc_helper_add(&gma_crtc->base, - dev_priv->ops->crtc_helper); + drm_crtc_helper_add(&gma_crtc->base, dev_priv->ops->crtc_helper); /* Setup the array of drm_connector pointer array */ gma_crtc->mode_set.crtc = &gma_crtc->base; -- 1.9.0
[PATCH] ASoC: tda998x: Change the compatible strings
The tda998x driver accepts 3 chips only from the TDA998x family.
This patch changes the driver to accept only these chips.
Signed-off-by: Jean-Francois Moine
---
Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 4 ++--
drivers/gpu/drm/i2c/tda998x_drv.c | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index fc7effa..e3f3d65 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -1,7 +1,7 @@
Device-Tree bindings for the NXP TDA998x HDMI transmitter
Required properties;
- - compatible: must be "nxp,tda998x"
+ - compatible: may be "nxp,tda9989", "nxp,tda19988" or "nxp,tda19989"
- reg: I2C address
@@ -20,7 +20,7 @@ Optional properties:
Example:
tda998x: hdmi-encoder {
- compatible = "nxp,tda998x";
+ compatible = "nxp,tda19988";
reg = <0x70>;
interrupt-parent = <&gpio0>;
interrupts = <27 2>;/* falling edge */
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 48af5ca..fd6751c 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1367,7 +1367,9 @@ fail:
#ifdef CONFIG_OF
static const struct of_device_id tda998x_dt_ids[] = {
- { .compatible = "nxp,tda998x", },
+ { .compatible = "nxp,tda9989", },
+ { .compatible = "nxp,tda19988", },
+ { .compatible = "nxp,tda19989", },
{ }
};
MODULE_DEVICE_TABLE(of, tda998x_dt_ids);
--
1.9.1
[PATCH v2] drm: enable render-nodes by default
On Thu, Mar 20, 2014 at 6:28 AM, Thomas Hellstrom wrote: > On 03/20/2014 10:43 AM, David Herrmann wrote: >> Hi >> >> On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom >> wrote: >>> A user logs in to a system where DRI clients use render nodes. The >>> system grants rw permission on the render nodes for the console user. >>> User starts editing a secret document, starts some GPGPU structural FEM >>> computations of the Pentagon building. Locks the screen and goes for lunch. >>> >>> A malicious user logs in using fast user switching and becomes the owner >>> of the render node. Tries to map a couple of random offsets, but that >>> fails, due to security checks. Now crafts a malicious command stream to >>> dump all GPU memory to a file. Steals the first user's secret document >>> and the intermediate Pentagon data. Logs out and starts data mining. >>> >>> Now if we require drivers to block these malicious command streams this >>> can never happen, and distros can reliably grant rw access to the render >>> nodes to the user currently logged into the console. >>> >>> I guest basically what I'm trying to say that with the legacy concept it >>> was OK to access all GPU memory, because an authenticated X user >>> basically had the same permissions. >>> >>> With render nodes we're allowing multiple users into the GPU at the same >>> time, and it's not OK anymore for a client to access another clients GPU >>> buffer through a malicious command stream. >> Yes, I understand the attack scenario, but that's not related to >> render-nodes at all. The exact same races exist on the legacy node: > > I was under the impression that render nodes were designed to fix these > issues? > >> >> 1) If you can do fast-user switching, you can spawn your own X-server, >> get authenticated on your own server and you are allowed into the GPU. >> You cannot map other user's buffers because they're on a different >> master-object, but you _can_ craft malicious GPU streams and access >> the other user's buffer. > > But with legacy nodes, drivers can (and should IMO) throw out all data > from GPU memory on master drop, > and then block dropped master authenticated clients from GPU, until > their master becomes active again or dies (in which case they are > killed). In line with a previous discussion we had. Now you can't do > this with render nodes, so yes they do open up > a new race that requires command stream validation. > >> >> 2) If you can do fast-user switching, switch to an empty VT, open the >> legacy node and you automatically become DRM-Master because there is >> no active master. Now you can do anything on the DRM node, including >> crafting malicious GPU streams. > > I believe the above solution should work for this case as well. > >> >> Given that the legacy node is always around and _always_ has these >> races, why should we prevent render-nodes from appearing just because >> the _driver_ is racy? I mean, there is no gain in that.. if it opens a >> new race, as you assumed, then yes, we should avoid it. But at least >> for all drivers supporting render-nodes so far, they either are >> entirely safe or the just described races exist on both nodes. > > My suggestion is actually not to prevent render nodes from appearing, > but rather that we should restrict them to drivers with command stream > verification and / or per process virtual memory, and I also think we > should plug the above races on legacy nodes. That way legacy nodes would > use the old "master owns it all" model, while render nodes could allow > multiple users at the same time. > hmm, if you only have global gpu virtual memory (rather than per-process), it would still be kinda nice to support render nodes if app had some way to figure out whether or not it's gpu buffers were secure. Ie. an app that was using the gpu for something secure could simply choose not to if the hw/driver could not guarantee that another process using the gpu could not get access to the buffers.. BR, -R > > /Thomas > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: enable render-nodes by default
On Thu, Mar 20, 2014 at 10:44 AM, Ilia Mirkin wrote: > On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse wrote: >> On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote: >>> On 03/20/2014 10:43 AM, David Herrmann wrote: >>> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom >>> > wrote: >>> > Given that the legacy node is always around and _always_ has these >>> > races, why should we prevent render-nodes from appearing just because >>> > the _driver_ is racy? I mean, there is no gain in that.. if it opens a >>> > new race, as you assumed, then yes, we should avoid it. But at least >>> > for all drivers supporting render-nodes so far, they either are >>> > entirely safe or the just described races exist on both nodes. >>> >>> My suggestion is actually not to prevent render nodes from appearing, >>> but rather that we should restrict them to drivers with command stream >>> verification and / or per process virtual memory, and I also think we >>> should plug the above races on legacy nodes. That way legacy nodes would >>> use the old "master owns it all" model, while render nodes could allow >>> multiple users at the same time. >> >> FYI both radeon and nouveau (last time i check) can not be abuse to access >> random VRAM or buffer bind by another process (except if the buffer is share >> of course). > > I'm not aware of any restrictions in nouveau that would prevent you > from accessing any vram... there are a number of copy engines > accessible that would allow you to copy one region to another, and I'm > not aware of code to validate pushbuf contents (it would have to parse > the pushbuf and know which methods store source/destination > addresses). You could probably get creative and use that to overwrite > the MMU tables, to then gain the ability to read/write any part of > system memory... but perhaps the engines won't allow you to do that, > not sure. (Or perhaps the PDE isn't mapped into VRAM. Again, not > sure.) Please ignore this totally wrong comment. While there is indeed no pushbuf validation, every process (well, every open() of the drm node) gets its own virtual memory space for all GPU's with MMU's (nv50+). -ilia
[PATCH 3/6] shm: add memfd_create() syscall
On 03/19/2014 12:06 PM, David Herrmann wrote: > memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor > that you can pass to mmap(). It explicitly allows sealing and > avoids any connection to user-visible mount-points. Thus, it's not > subject to quotas on mounted file-systems, but can be used like > malloc()'ed memory, but with a file-descriptor to it. > > memfd_create() does not create a front-FD, but instead returns the raw > shmem file, so calls like ftruncate() can be used. Also calls like fstat() > will return proper information and mark the file as regular file. Sealing > is explicitly supported on memfds. > > Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not > subject to quotas and alike. This syscall would also be useful to Android, since it would satisfy the requirement for providing atomically unlinked tmpfs fds that ashmem provides (although upstreamed solutions to ashmem's other functionalities are still needed). My only comment is that I think memfd_* is sort of a new namespace. Since this is providing shmem files, it seems it might be better named something like shmfd_create() or my earlier suggestion of shmget_fd(). Otherwise, when talking about functionality like sealing, which is only available on shmfs, we'll have to say "shmfs/tmpfs/memfd" or risk confusing folks who might not initially grasp that its all the same underneath. thanks -john
[PATCH v2] drm: enable render-nodes by default
On 03/20/2014 06:34 PM, Rob Clark wrote: > On Thu, Mar 20, 2014 at 6:28 AM, Thomas Hellstrom > wrote: >> On 03/20/2014 10:43 AM, David Herrmann wrote: >>> Hi >>> >>> On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom >>> wrote: A user logs in to a system where DRI clients use render nodes. The system grants rw permission on the render nodes for the console user. User starts editing a secret document, starts some GPGPU structural FEM computations of the Pentagon building. Locks the screen and goes for lunch. A malicious user logs in using fast user switching and becomes the owner of the render node. Tries to map a couple of random offsets, but that fails, due to security checks. Now crafts a malicious command stream to dump all GPU memory to a file. Steals the first user's secret document and the intermediate Pentagon data. Logs out and starts data mining. Now if we require drivers to block these malicious command streams this can never happen, and distros can reliably grant rw access to the render nodes to the user currently logged into the console. I guest basically what I'm trying to say that with the legacy concept it was OK to access all GPU memory, because an authenticated X user basically had the same permissions. With render nodes we're allowing multiple users into the GPU at the same time, and it's not OK anymore for a client to access another clients GPU buffer through a malicious command stream. >>> Yes, I understand the attack scenario, but that's not related to >>> render-nodes at all. The exact same races exist on the legacy node: >> I was under the impression that render nodes were designed to fix these >> issues? >> >>> 1) If you can do fast-user switching, you can spawn your own X-server, >>> get authenticated on your own server and you are allowed into the GPU. >>> You cannot map other user's buffers because they're on a different >>> master-object, but you _can_ craft malicious GPU streams and access >>> the other user's buffer. >> But with legacy nodes, drivers can (and should IMO) throw out all data >> from GPU memory on master drop, >> and then block dropped master authenticated clients from GPU, until >> their master becomes active again or dies (in which case they are >> killed). In line with a previous discussion we had. Now you can't do >> this with render nodes, so yes they do open up >> a new race that requires command stream validation. >> >>> 2) If you can do fast-user switching, switch to an empty VT, open the >>> legacy node and you automatically become DRM-Master because there is >>> no active master. Now you can do anything on the DRM node, including >>> crafting malicious GPU streams. >> I believe the above solution should work for this case as well. >> >>> Given that the legacy node is always around and _always_ has these >>> races, why should we prevent render-nodes from appearing just because >>> the _driver_ is racy? I mean, there is no gain in that.. if it opens a >>> new race, as you assumed, then yes, we should avoid it. But at least >>> for all drivers supporting render-nodes so far, they either are >>> entirely safe or the just described races exist on both nodes. >> My suggestion is actually not to prevent render nodes from appearing, >> but rather that we should restrict them to drivers with command stream >> verification and / or per process virtual memory, and I also think we >> should plug the above races on legacy nodes. That way legacy nodes would >> use the old "master owns it all" model, while render nodes could allow >> multiple users at the same time. >> > hmm, if you only have global gpu virtual memory (rather than > per-process), it would still be kinda nice to support render nodes if > app had some way to figure out whether or not it's gpu buffers were > secure. If there is only global GPU memory there's of course also the option of providing a command stream verifier. > Ie. an app that was using the gpu for something secure could > simply choose not to if the hw/driver could not guarantee that another > process using the gpu could not get access to the buffers.. IMO that should work fine, but we need to provide a way for user-space to determine whether the render node is secure or not. Perhaps a sysfs attribute and / or a drm getparam() parameter? /Thomas > > BR, > -R > >> /Thomas >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/dri-devel&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=FdvSEw9pF7e8FqQQ9dlatoXG%2BSm0ueWrIhyOeI%2BOc64%3D%0A&s=926ef90112ced9636ddbf2873c3770bdf06ca244ec32744fe33e478b93e0d695
[PATCH v2] drm: enable render-nodes by default
On Thu, Mar 20, 2014 at 4:54 PM, Thomas Hellstrom wrote: > On 03/20/2014 06:34 PM, Rob Clark wrote: >> On Thu, Mar 20, 2014 at 6:28 AM, Thomas Hellstrom >> wrote: >>> On 03/20/2014 10:43 AM, David Herrmann wrote: Hi On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom wrote: > A user logs in to a system where DRI clients use render nodes. The > system grants rw permission on the render nodes for the console user. > User starts editing a secret document, starts some GPGPU structural FEM > computations of the Pentagon building. Locks the screen and goes for > lunch. > > A malicious user logs in using fast user switching and becomes the owner > of the render node. Tries to map a couple of random offsets, but that > fails, due to security checks. Now crafts a malicious command stream to > dump all GPU memory to a file. Steals the first user's secret document > and the intermediate Pentagon data. Logs out and starts data mining. > > Now if we require drivers to block these malicious command streams this > can never happen, and distros can reliably grant rw access to the render > nodes to the user currently logged into the console. > > I guest basically what I'm trying to say that with the legacy concept it > was OK to access all GPU memory, because an authenticated X user > basically had the same permissions. > > With render nodes we're allowing multiple users into the GPU at the same > time, and it's not OK anymore for a client to access another clients GPU > buffer through a malicious command stream. Yes, I understand the attack scenario, but that's not related to render-nodes at all. The exact same races exist on the legacy node: >>> I was under the impression that render nodes were designed to fix these >>> issues? >>> 1) If you can do fast-user switching, you can spawn your own X-server, get authenticated on your own server and you are allowed into the GPU. You cannot map other user's buffers because they're on a different master-object, but you _can_ craft malicious GPU streams and access the other user's buffer. >>> But with legacy nodes, drivers can (and should IMO) throw out all data >>> from GPU memory on master drop, >>> and then block dropped master authenticated clients from GPU, until >>> their master becomes active again or dies (in which case they are >>> killed). In line with a previous discussion we had. Now you can't do >>> this with render nodes, so yes they do open up >>> a new race that requires command stream validation. >>> 2) If you can do fast-user switching, switch to an empty VT, open the legacy node and you automatically become DRM-Master because there is no active master. Now you can do anything on the DRM node, including crafting malicious GPU streams. >>> I believe the above solution should work for this case as well. >>> Given that the legacy node is always around and _always_ has these races, why should we prevent render-nodes from appearing just because the _driver_ is racy? I mean, there is no gain in that.. if it opens a new race, as you assumed, then yes, we should avoid it. But at least for all drivers supporting render-nodes so far, they either are entirely safe or the just described races exist on both nodes. >>> My suggestion is actually not to prevent render nodes from appearing, >>> but rather that we should restrict them to drivers with command stream >>> verification and / or per process virtual memory, and I also think we >>> should plug the above races on legacy nodes. That way legacy nodes would >>> use the old "master owns it all" model, while render nodes could allow >>> multiple users at the same time. >>> >> hmm, if you only have global gpu virtual memory (rather than >> per-process), it would still be kinda nice to support render nodes if >> app had some way to figure out whether or not it's gpu buffers were >> secure. > > If there is only global GPU memory there's of course also the option of > providing a > command stream verifier. well, that wouldn't really help separate buffers from other contexts (since a3xx and later has various load/store instructions).. At the moment, I have two cases: 1) MMU... gpu has no direct access to system memory, so other than access to other contexts buffers, the system is secure 2) no-MMU... vram carveout and set some registers to limit access to addresses within that range In case #1 we could implement per-context vm.. just a matter of writing some code. Doing it the naive way requires draining the command queue on context switches and getting the CPU involved, which isn't so terribly awesome. The downstream android driver does context switches on the CP itself (ie. bang some registers to point the MMU at new set of tables and TLB flush).. but it needs to be confirmed that this can be done securely (ie. restricted to
I915: OOPSes on linux-3.14-rc7
On Thu, Mar 20, 2014 at 05:56:20PM +0100, Peter Senna Tschudin wrote: > When Fedora updated the Kernel package from 3.12 to 3.13 my notebook > stopped booting (Kernel freezes) when a 2560 x 1440 high res monitor > is attached. I have tried using 3.13.6 from kernel.org and the problem > persists. The problem can be partially solved by passing nomodeset to > Kernel which will make the Kernel to boot, but the screens never comes > to life. When using 3.14-rc7 it boots again, the screen works, but > with some oops messages. > > How can I help fixing this issue? > > I've reported te bug at: > https://bugzilla.redhat.com/show_bug.cgi?id=1072557 For the oops message (well it's just a WARNING, a real oops would kill your driver for real) please file a bug report on bugs.freedesktop.org against dri -> drm (intel). The information we need is the full dmesg fore the entire boot when enabling drm.debug=0xe on the kernel cmdline. For the boot hang you've reported on the redhat bz if you want to move it forward I suggest to do a reverse bisect betwen 3.13 and 3.14-rc7 to figure out which bug _fixed_ your problem and then tell me that. I'll submit it for backporting to stable kernels. Google should find you some nice howtos for reverse bisecting kerneels. Cheers, Daniel > > drm related dmesg lines on linux-3.14-rc7: > [1.602225] [drm] Initialized drm 1.1.0 20060810 > [1.795184] [drm] Memory usable by graphics device = 2048M > [1.860121] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [1.860124] [drm] Driver supports precise vblank timestamp query. > [1.860259] vgaarb: device changed decodes: > PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem > [1.910948] [drm] GMBUS [i915 gmbus panel] timed out, falling back > to bit banging on pin 3 > [1.943111] [drm] Wrong MCH_SSKPD value: 0x16040307 > [1.943117] [drm] This can cause pipe underruns and display issues. > [1.943120] [drm] Please upgrade your BIOS to fix this. > [2.192641] [drm:ironlake_disable_pch_transcoder] *ERROR* failed to > disable transcoder A > [2.454038] Console: switching to colour frame buffer device 170x48 > [2.461511] i915 :00:02.0: fb0: inteldrmfb frame buffer device > [2.461514] i915 :00:02.0: registered panic notifier > [2.462577] ACPI: Video Device [GFX0] (multi-head: yes rom: yes post: no) > [2.467139] acpi device:05: registered as cooling_device4 > [2.467447] input: Video Bus as > /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input9 > [2.467696] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > minor 0 > [3.709772] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off > > > OOPSes on linux-3.14-rc7: > WARNING: CPU: 3 PID: 124 at drivers/gpu/drm/i915/intel_display.c:450 > i9xx_clock+0x81/0xb0 [i915]() > Modules linked in: i915(+) i2c_algo_bit drm_kms_helper drm i2c_core video > CPU: 3 PID: 124 Comm: systemd-udevd Not tainted 3.14.0-rc7 #1 > Hardware name: TOSHIBA PORTEGE R830/Portable PC, BIOS Version 4.10 > 01/08/2013 > 0009 8804345f7818 8168e6d2 > 8804345f7850 8108199d 88043787f6d8 0100 > 0001d4c0 88043787f000 8804345f7860 > Call Trace: > [] dump_stack+0x45/0x56 > [] warn_slowpath_common+0x7d/0xa0 > [] warn_slowpath_null+0x1a/0x20 > [] i9xx_clock+0x81/0xb0 [i915] > [] i9xx_crtc_clock_get.isra.31+0x1d0/0x2c0 [i915] > [] ironlake_get_pipe_config+0x209/0x2f0 [i915] > [] intel_modeset_setup_hw_state+0xb4/0xc20 [i915] > [] intel_modeset_gem_init+0x3d/0x50 [i915] > [] i915_driver_load+0xc98/0xe10 [i915] > [] drm_dev_register+0x7b/0x160 [drm] > [] drm_get_pci_dev+0xa0/0x220 [drm] > [] i915_pci_probe+0x3b/0x60 [i915] > [] local_pci_probe+0x45/0xa0 > [] pci_device_probe+0xd1/0x130 > [] driver_probe_device+0x125/0x3a0 > [] __driver_attach+0x93/0xa0 > [] ? __device_attach+0x40/0x40 > [] bus_for_each_dev+0x63/0xa0 > [] driver_attach+0x1e/0x20 > [] bus_add_driver+0x180/0x250 > [] ? 0xa0146fff > [] driver_register+0x64/0xf0 > [] ? 0xa0146fff > [] __pci_register_driver+0x4b/0x50 > [] drm_pci_init+0x11a/0x130 [drm] > [] ? 0xa0146fff > [] i915_init+0x6a/0x6c [i915] > [] do_one_initcall+0xd2/0x180 > [] ? set_memory_nx+0x43/0x50 > [] load_module+0x1bb6/0x2580 > [] ? store_uevent+0x40/0x40 > [] ? copy_module_from_fd.isra.47+0x121/0x180 > [] SyS_finit_module+0x86/0xb0 > [] system_call_fastpath+0x16/0x1b > ---[ end trace 628c8f95ba351f1a ]--- > > WARNING: CPU: 3 PID: 124 at drivers/gpu/drm/i915/intel_display.c:450 > i9xx_clock+0x81/0xb0 [i915]() > Modules linked in: i915(+) i2c_algo_bit drm_kms_helper drm i2c_core video > CPU: 3 PID: 124 Comm: systemd-udevd Tainted: GW3.14.0-rc7 #1 > Hardware name: TOSHIBA PORTEGE R830/Portable PC, BIOS Version 4.10 > 01/08/2013 > 0009 8804345f7500 8168e6d2 > 8804345f7538 f
[Bug 42960] Display does not work when resuming from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=42960 --- Comment #11 from Sandeep --- I attempted to check if it was a backlight problem, following the troubleshooting steps here: https://wiki.archlinux.org/index.php/Backlight Booting with those kernel parameters doesn't help in my case. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/3adb21cd/attachment.html>
[Bug 42960] Display does not work when resuming from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=42960 --- Comment #12 from Sandeep --- Note: Suspend and resume works fine on Windows - the laptop's LVDS display is active and working even after suspend and resume. I remember that this problem used to occur for Catalyst as well, around version 11.5 , but it got fixed a few months afterwards, and the LVDS display was active after suspend and resume. I haven't used Catalyst for several months, so cannot comment on whether it still works fine now. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/dcd09d0b/attachment.html>
[PATCH 00/16] Atomic/nuclear modeset/pageflip
On Wed, Mar 19, 2014 at 5:23 AM, Rob Clark wrote: > > Hm, do you have some pointers to read up on this? I still think a more > > elaborate fail scheme is overkill, but maybe reading a bit of android > code > > convinces me differently ;-) > > sadly no pointers to anything to read (but ofc would be interested if > anyone else does).. > The hardware composer HAL is probably the best reference for what Android needs from display. It's defined and documented here (see struct hwc_composer_device_1): *https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/hwcomposer.h <https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/hwcomposer.h>* (You can disregard any HWC 1.0 specific behavior in that documentation, that's only around for legacy reasons and we strongly encourage vendors not to implement HWC 1.0 anymore.) Vendors need to ship a compliant HWC HAL implementation on their devices. We don't mandate anything about their userspace/kernel interface beyond that. > * I kinda would still like to add to the atomic ioctl some way to indicate >ok/error on a bit finer granularity than per-ioctl. Ie. perhaps an >array where userspace can ask for results per KMS object (crtc/plane)? >Something along these lines would give the kernel a bit more flexibility >to deal with some of the edge cases which come up when you gang crtcs >for ultra high resolution displays. In short, it would let the driver >"steal" some of the planes if needed from userspace. > >This would also, conveniently, be pretty similar to how (AFAIU) hw >compositor and ADF work on android. Which seems like it would be useful >to eventually enable android devices to use an upstream display driver. > >For this we could pretty easily just throw in a placeholder that we >could replace later with an optional ptr to __user array. I think >that would be fine for an initial version, but I just wanted to throw >this idea out there, because I think it will become important. > SurfaceFlinger needs the HWC HAL to return a retire fence fd on each flip, for each display. Per-interface return data would be a good fit for this, but per-CRTC or per-plane would work too (userspace could assemble a per-interface fence by merging finer-grained fences). It's up to the vendor whether their HWC HAL does fine-grained error handling and renegotiation like you're describing. Typically they don't, they just push that complexity into userspace instead. e.g. if the display controller needs to gang together two planes for a given configuration, the HWC HAL's prepare() op will already know to set aside that extra plane and plan accordingly. ------ next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/43734f08/attachment.html>
[pci] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_crtc.c:94 drm_warn_on_modeset_not_all_locked()
On Thu, Mar 20, 2014 at 6:41 AM, Fengguang Wu wrote:
> Greetings,
>
> I got the below dmesg and the first bad commit is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/resource
>
> commit aa11fc58dc71c27701b1f9a529a36a38d4337722
> Author: Bjorn Helgaas
> AuthorDate: Fri Mar 7 13:39:01 2014 -0700
> Commit: Bjorn Helgaas
> CommitDate: Wed Mar 19 15:00:16 2014 -0600
>
> PCI: Check all IORESOURCE_TYPE_BITS in pci_bus_alloc_from_region()
>
> When allocating space from a bus resource, i.e., from apertures leading to
> this bus, make sure the entire resource type matches. The previous code
> assumed the IORESOURCE_TYPE_BITS field was a bitmask with only a single
> bit
> set, but this is not true. IORESOURCE_TYPE_BITS is really an enumeration,
> and we have to check all the bits.
>
> See 72dcb1197228 ("resources: Add register address resource type").
>
> No functional change. If we used this path for allocating IRQs, DMA
> channels, or bus numbers, this would fix a bug because those types are
> indistinguishable when masked by IORESOURCE_IO | IORESOURCE_MEM. But we
> don't, so this shouldn't make any difference.
>
> Signed-off-by: Bjorn Helgaas
Thanks (I think). I'm afraid I'm going to need some more help to
debug this. I built aa11fc58dc with the config you supplied and
booted it on qemu with no real issues (it didn't boot all the way
because the config doesn't include a driver for my root disk, but
that's to be expected).
The dmesg you supplied is for some other commit 2d18516 that I don't
have, so I'm confused about why it's not from aa11fc58dc.
I did reproduce what appears to be basically the same problem with
a654dc797f3e, which is the 20140320 linux-next tree. I backed up to
93ecdc077282, which is where pci/next was merged (this includes
aa11fc58dc), but I could not reproduce the problem there.
So bottom line, I'm confused because your bisection doesn't match what
I'm seeing, and I don't want to spend more time flailing around.
Bjorn
> ++++
> |
>| aa11fc58dc | 2d18516523 |
> ++++
> | boot_successes
>| 19 | 0 |
> | boot_failures
>| 1 | 19 |
> | BUG:unable_to_handle_kernel_NULL_pointer_dereference
>| 1 | 1 |
> | Oops
>| 1 | 1 |
> | EIP_is_at_rapl_pmu_init
>| 1 | 1 |
> | Kernel_panic-not_syncing:Attempted_to_kill_init_exitcode=
>| 1 | 1 |
> | backtrace:rapl_pmu_init
>| 1 | 1 |
> | backtrace:kernel_init_freeable
>| 1 | 19 |
> |
> WARNING:CPU:PID:at_drivers/gpu/drm/drm_crtc.c:drm_warn_on_modeset_not_all_locked()
> | 0 | 18 |
> |
> WARNING:CPU:PID:at_drivers/gpu/drm/drm_crtc_helper.c:drm_helper_encoder_in_use()
>| 0 | 18 |
> |
> WARNING:CPU:PID:at_drivers/gpu/drm/drm_crtc_helper.c:drm_helper_crtc_in_use()
> | 0 | 18 |
> |
> WARNING:CPU:PID:at_drivers/gpu/drm/drm_crtc_helper.c:drm_helper_probe_single_connector_modes()
> | 0 | 18 |
> | WARNING:CPU:PID:at_drivers/gpu/drm/drm_modes.c:drm_mode_probed_add()
>| 0 | 18 |
> |
> WARNING:CPU:PID:at_drivers/gpu/drm/drm_modes.c:drm_mode_connector_list_update()
> | 0 | 18 |
> | backtrace:drm_helper_disable_unused_functions
>| 0 | 18 |
> | backtrace:cirrus_fbdev_init
>| 0 | 18 |
> | backtrace:cirrus_modeset_init
>| 0 | 18
Intel G41 doesn't see any screens connected after suspend/resume
2014-03-20 9:43 GMT-04:00 Chris Wilson :
> On Thu, Mar 20, 2014 at 09:38:17AM -0400, Nikolay Martynov wrote:
>> (gdb) list *i915_gem_object_set_cache_level+0x8a
>> 0x24e3a is in i915_gem_object_set_cache_level
>> (drivers/gpu/drm/i915/i915_gem.c:3147).
>> 3142 * crossing memory domains and dying.
>> 3143 */
>> 3144if (HAS_LLC(dev))
>> 3145return true;
>> 3146
>> 3147if (!drm_mm_node_allocated(gtt_space))
>> 3148return true;
>> 3149
>> 3150if (list_empty(>t_space->node_list))
>> 3151return true;
>>
>> Please let me know if there's anything else I can do.
>
> Can you please try:
>
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 13fc490d1f62..4f71125493fd 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3676,7 +3676,7 @@ int i915_gem_object_set_cache_level(struct
> drm_i915_gem_object *obj,
> enum i915_cache_level cache_level)
> {
> struct drm_device *dev = obj->base.dev;
> - struct i915_vma *vma;
> + struct i915_vma *vma, *next;
> int ret;
>
> if (obj->cache_level == cache_level)
> @@ -3687,7 +3687,7 @@ int i915_gem_object_set_cache_level(struct
> drm_i915_gem_object *obj,
> return -EBUSY;
> }
>
> - list_for_each_entry(vma, &obj->vma_list, vma_link) {
> + list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link) {
> if (!i915_gem_valid_gtt_space(dev, &vma->node, cache_level)) {
> ret = i915_vma_unbind(vma);
> if (ret)
>
> --
Yes, that seem to help. It didn't freeze anymore in 15 mins I used it. Thanks!
--
Martynov Nikolay.
Email: mar.kolya at gmail.com
[PATCH 3/6] shm: add memfd_create() syscall
On Wed, Mar 19, 2014 at 08:06:48PM +0100, David Herrmann wrote: > memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor > that you can pass to mmap(). It explicitly allows sealing and > avoids any connection to user-visible mount-points. Thus, it's not > subject to quotas on mounted file-systems, but can be used like > malloc()'ed memory, but with a file-descriptor to it. > > memfd_create() does not create a front-FD, but instead returns the raw > shmem file, so calls like ftruncate() can be used. Also calls like fstat() > will return proper information and mark the file as regular file. Sealing > is explicitly supported on memfds. > > Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not > subject to quotas and alike. If I'm not mistaken in something obvious, this looks similar to /proc/pid/map_files feature, Pavel?
[PATCH 3/6] shm: add memfd_create() syscall
On 03/20/2014 03:29 PM, David Herrmann wrote: > Hi > > On Thu, Mar 20, 2014 at 10:01 AM, Pavel Emelyanov > wrote: >> On 03/20/2014 12:47 PM, Cyrill Gorcunov wrote: >>> If I'm not mistaken in something obvious, this looks similar to >>> /proc/pid/map_files >>> feature, Pavel? >> >> It is, but the map_files will work "in the opposite direction" :) In the >> memfd >> case one first gets an FD, then mmap()s it; in the /proc/pis/map_files case >> one >> should first mmap() a region, then open it via /proc/self/map_files. >> >> But I don't know whether this matters. > > Yes, you can replace memfd_create() so far with: > p = mmap(NULL, size, ..., MAP_ANON | MAP_SHARED, -1, 0); > sprintf(path, "/proc/self/map_files/%lx-%lx", p, p + size); > fd = open(path, O_RDWR); > > However, map_files is only enabled with CONFIG_CHECKPOINT_RESTORE, the > /proc/pid/map_files/ directory is root-only (at least I get EPERM if > non-root), Yes. But this is something we'd also like to have fixed :) Having two parties willing the same makes it easier for the patch to get accepted. > it doesn't provide the "name" argument which is very handy > for debugging, What if we make mmap's shmem_zero_setup() generate a meaningful name, would it solve the debugging issue? > it doesn't explicitly support sealing (it requires MAP_ANON to be backed > by shmem) Can you elaborate on this? The fd generated by sys_memfd() will be shmem-backed, so will be the file opened via map_files link for the MAP_ANON | MAP_SHARED mapping. So what are the problems to make it support sealing? > and it's a very weird API for something this simple. :) Thanks, Pavel
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On 03/20/2014 09:58 AM, Jean-Francois Moine wrote: > The I2C address (reg) is required for the TDA998x driver to be loaded > and initialized. > > Signed-off-by: Jean-Francois Moine > --- > This patch applies to linux-next. > --- > Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt > b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt > index d7df01c..fc7effa 100644 > --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt > +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt > @@ -3,6 +3,8 @@ Device-Tree bindings for the NXP TDA998x HDMI transmitter > Required properties; > - compatible: must be "nxp,tda998x" > > + - reg: I2C address - must be <0x70> TDA9983b datasheet says: "Bits A0 and A1 of the I2C-bus device address are externally selected by pins A0 and A1." Therefore, 0x70, 0x71, 0x72, and 0x73 are valid i2c addresses. Sebastian > Optional properties: > - interrupts: interrupt number and trigger type > default: polling >
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On 03/20/2014 02:01 PM, Jean-Francois Moine wrote: > On Thu, 20 Mar 2014 13:32:24 +0100 > Sebastian Hesselbarth wrote: > >>> + - reg: I2C address - must be <0x70> >> >> TDA9983b datasheet says: >> >> "Bits A0 and A1 of the I2C-bus device address are externally selected >> by pins A0 and A1." >> >> Therefore, 0x70, 0x71, 0x72, and 0x73 are valid i2c addresses. > > Sebastian, > > That's interesting! > > For the Cubox and the AMX33XX boards, the I2C address of the HDMI > registers is 0x70, and the I2C address of the CEC registers is 0x34. > > For other boards using the TDA998x family, if the I2C address is > different from 0x70, have you an idea about what can be the CEC I2C > address? (this value is actually hard-coded in the TDA998x driver) > Ok, I had another round of google'ing and found this: http://hipstercircuits.com/wp-content/uploads/2013/05/TDA19988.pdf There, the datasheet specifically for TDA19988 only states 0x70 and 0x34 as the two i2c addresses. Therefore, TDA19988 has fixed i2c addresses while TDA9983b has configurable (main) i2c address. Not as easy as we thought ;) I suggest reword the reg property to: "- reg: shall be set to the I2C address" and optionally list all known addresses for each TDA[1]998x in the binding. Sebastian
[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation
On 03/20/2014 02:52 PM, Jean-Francois Moine wrote: > On Thu, 20 Mar 2014 14:32:18 +0100 > Sebastian Hesselbarth wrote: > >> Ok, I had another round of google'ing and found this: >> http://hipstercircuits.com/wp-content/uploads/2013/05/TDA19988.pdf >> >> There, the datasheet specifically for TDA19988 only states 0x70 and >> 0x34 as the two i2c addresses. Therefore, TDA19988 has fixed i2c >> addresses while TDA9983b has configurable (main) i2c address. >> >> Not as easy as we thought ;) >> >> I suggest reword the reg property to: >> "- reg: shall be set to the I2C address" >> >> and optionally list all known addresses for each TDA[1]998x in the >> binding. > > Thanks for the link. > > OK, then, as the linux tda998x driver handles only the tda 19988 and > 19989 chips, the HDMI I2C address is always 0x70. > > So, question: Russell and Sebastian, do you still want an other patch? Up to Russell, but reg property is required for i2c slaves and should be documented. > Other question: the CEC address is hard-coded to 0x34 in the driver. > Should it be configurable in the DT? Looking at nxp's website, detailed information about TDA[1]998x have vanished. Luckily, there are some hints in the parametric search: There is TDA998[14] without any CEC support and TDA1998[89] with CEC support. Both TDA19988 and TDA19989 have fixed i2c addresses 0x70 and 0x34 respectively. So, the answer is: Let the driver access CEC i2c slave only if it is TDA1998[89]. The HDMI part should be quite compatible with TDA998x, so if anyone has it on his board, he is invited to add proper support. For the binding, reg address should contain reg property to the HDMI i2c slave. Add proper compatibles/i2c_ids for nxp,tda19988 and nxp,tda19989 and check that to add the CEC i2c slave on 0x34. If, someday there will be a tda19990 with configurable addresses, I am sure you can derive it from i2c main address, e.g. 0x70<>0x34, 0x71<>0x35, aso. No need to take care of configurable CEC slave address now, neither in the driver nor binding. Sebastian
[PATCH 0/6] File Sealing & memfd_create()
> My first idea was to add MFD_ALLOW_SEALING as memfd_create() flag, > which enables the sealing-API for that file. Then I looked at POSIX This actually seems the most sensible to me. The reason being that if I have some existing used object there is no way on earth I can be sure who has existing references to it, and we don't have revoke() to fix that. So it pretty much has to be a new object in a sane programming model. > mandatory locking and noticed that it provides similar restrictions on > _all_ files. Mandatory locks can be more easily removed, but an The fact someone got it past a standards body doesn't make it a good idea. > attacker could just re-apply them in a loop, so that's not really an > argument. Furthermore, sealing requires _write_ access so I wonder > what kind of DoS attacks are possible with sealing that are not > already possible with write access? And sealing is only possible if no > writable, shared mapping exists. So even if an attacker seals a file, > all that happens is EPERM, not SIGBUS (still a possible > denial-of-service scenario). I think you want two things at minimum owner to seal root can always override I would query the name too. Right now your assumption is 'shmem only' but that might change with other future use cases or types (eg some driver file handles) so SHMEM_ in the fcntl might become misleading. Whether you want some way to undo a seal without an exclusive reference as the file owner is another question. Alan
[PATCH 0/6] File Sealing & memfd_create()
On Thu, 20 Mar 2014 16:12:54 +0100 David Herrmann wrote: > Hi > > On Thu, Mar 20, 2014 at 3:41 PM, One Thousand Gnomes > wrote: > > I think you want two things at minimum > > > > owner to seal > > root can always override > > Why should root be allowed to override? Because root can already override it by say mmapping the kernel memory and patching. It also tends to be valuable for debugging horrible problems with complex systems. Imposing fake restrictions on root just causes annoyance when doing stuff like debugging but doesn't actually change the security situation. > > I'm fine with F_SET/GET_SEALS. But given you suggested requiring > MFD_ALLOW_SEALS for sealing, I don't see why we couldn't limit this > interface entirely to memfd_create(). But if someone does find a non memfd use for it then it's useful not to have to go "this fnctl for memfd, that fnctl for the other" Just planning ahead. > > Whether you want some way to undo a seal without an exclusive reference as > > the file owner is another question. > > No. You are never allowed to undo a seal but with an exclusive > reference. This interface was created for situations _without_ any > trust relationship. So if the owner is allowed to undo seals, the > interface doesn't make any sense. The only options I see is to not > allow un-sealing at all (which I'm fine with) or tracking users (which > is way too much overhead). Ok - that makes sense
[PATCH 3/6] shm: add memfd_create() syscall
On 03/20/2014 12:47 PM, Cyrill Gorcunov wrote: > On Wed, Mar 19, 2014 at 08:06:48PM +0100, David Herrmann wrote: >> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor >> that you can pass to mmap(). It explicitly allows sealing and >> avoids any connection to user-visible mount-points. Thus, it's not >> subject to quotas on mounted file-systems, but can be used like >> malloc()'ed memory, but with a file-descriptor to it. >> >> memfd_create() does not create a front-FD, but instead returns the raw >> shmem file, so calls like ftruncate() can be used. Also calls like fstat() >> will return proper information and mark the file as regular file. Sealing >> is explicitly supported on memfds. >> >> Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not >> subject to quotas and alike. > > If I'm not mistaken in something obvious, this looks similar to > /proc/pid/map_files > feature, Pavel? Thanks, Cyrill. It is, but the map_files will work "in the opposite direction" :) In the memfd case one first gets an FD, then mmap()s it; in the /proc/pis/map_files case one should first mmap() a region, then open it via /proc/self/map_files. But I don't know whether this matters. Thanks, Pavel
[PATCH 0/6] File Sealing & memfd_create()
On Thu, 20 Mar 2014 11:32:51 -0400 tytso at mit.edu wrote: > On Wed, Mar 19, 2014 at 08:06:45PM +0100, David Herrmann wrote: > > > > This series introduces the concept of "file sealing". Sealing a file > > restricts > > the set of allowed operations on the file in question. Multiple seals are > > defined and each seal will cause a different set of operations to return > > EPERM > > if it is set. The following seals are introduced: > > > > * SEAL_SHRINK: If set, the inode size cannot be reduced > > * SEAL_GROW: If set, the inode size cannot be increased > > * SEAL_WRITE: If set, the file content cannot be modified > > Looking at your patches, and what files you are modifying, you are > enforcing this in the low-level file system. > > Why not make sealing an attribute of the "struct file", and enforce it > at the VFS layer? That way all file system objects would have access > to sealing interface, and for memfd_shmem, you can't get another > struct file pointing at the object, the security properties would be > identical. Would it be more sensible to have a "sealer" which is a "device" which you give a file handle too and it gives you back a sealable one. So for the memfd case you'd create a private handle, pass it to the sealer, and then pass the sealer handles to everyone else. You have to implicitly trust the creator of the object has - handed you the object you expect - sealed it so that appears no weaker but means you can meaningfully created sealed versions of arbitary objects and if you want have non-sealed ones around with it being up to the creator if they want for example to simply close the unsealed one immediately afterwards. Alan
I915: OOPSes on linux-3.14-rc7
When Fedora updated the Kernel package from 3.12 to 3.13 my notebook stopped booting (Kernel freezes) when a 2560 x 1440 high res monitor is attached. I have tried using 3.13.6 from kernel.org and the problem persists. The problem can be partially solved by passing nomodeset to Kernel which will make the Kernel to boot, but the screens never comes to life. When using 3.14-rc7 it boots again, the screen works, but with some oops messages. How can I help fixing this issue? I've reported te bug at: https://bugzilla.redhat.com/show_bug.cgi?id=1072557 drm related dmesg lines on linux-3.14-rc7: [1.602225] [drm] Initialized drm 1.1.0 20060810 [1.795184] [drm] Memory usable by graphics device = 2048M [1.860121] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [1.860124] [drm] Driver supports precise vblank timestamp query. [1.860259] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [1.910948] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3 [1.943111] [drm] Wrong MCH_SSKPD value: 0x16040307 [1.943117] [drm] This can cause pipe underruns and display issues. [1.943120] [drm] Please upgrade your BIOS to fix this. [2.192641] [drm:ironlake_disable_pch_transcoder] *ERROR* failed to disable transcoder A [2.454038] Console: switching to colour frame buffer device 170x48 [2.461511] i915 :00:02.0: fb0: inteldrmfb frame buffer device [2.461514] i915 :00:02.0: registered panic notifier [2.462577] ACPI: Video Device [GFX0] (multi-head: yes rom: yes post: no) [2.467139] acpi device:05: registered as cooling_device4 [2.467447] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input9 [2.467696] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [3.709772] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off OOPSes on linux-3.14-rc7: WARNING: CPU: 3 PID: 124 at drivers/gpu/drm/i915/intel_display.c:450 i9xx_clock+0x81/0xb0 [i915]() Modules linked in: i915(+) i2c_algo_bit drm_kms_helper drm i2c_core video CPU: 3 PID: 124 Comm: systemd-udevd Not tainted 3.14.0-rc7 #1 Hardware name: TOSHIBA PORTEGE R830/Portable PC, BIOS Version 4.10 01/08/2013 0009 8804345f7818 8168e6d2 8804345f7850 8108199d 88043787f6d8 0100 0001d4c0 88043787f000 8804345f7860 Call Trace: [] dump_stack+0x45/0x56 [] warn_slowpath_common+0x7d/0xa0 [] warn_slowpath_null+0x1a/0x20 [] i9xx_clock+0x81/0xb0 [i915] [] i9xx_crtc_clock_get.isra.31+0x1d0/0x2c0 [i915] [] ironlake_get_pipe_config+0x209/0x2f0 [i915] [] intel_modeset_setup_hw_state+0xb4/0xc20 [i915] [] intel_modeset_gem_init+0x3d/0x50 [i915] [] i915_driver_load+0xc98/0xe10 [i915] [] drm_dev_register+0x7b/0x160 [drm] [] drm_get_pci_dev+0xa0/0x220 [drm] [] i915_pci_probe+0x3b/0x60 [i915] [] local_pci_probe+0x45/0xa0 [] pci_device_probe+0xd1/0x130 [] driver_probe_device+0x125/0x3a0 [] __driver_attach+0x93/0xa0 [] ? __device_attach+0x40/0x40 [] bus_for_each_dev+0x63/0xa0 [] driver_attach+0x1e/0x20 [] bus_add_driver+0x180/0x250 [] ? 0xa0146fff [] driver_register+0x64/0xf0 [] ? 0xa0146fff [] __pci_register_driver+0x4b/0x50 [] drm_pci_init+0x11a/0x130 [drm] [] ? 0xa0146fff [] i915_init+0x6a/0x6c [i915] [] do_one_initcall+0xd2/0x180 [] ? set_memory_nx+0x43/0x50 [] load_module+0x1bb6/0x2580 [] ? store_uevent+0x40/0x40 [] ? copy_module_from_fd.isra.47+0x121/0x180 [] SyS_finit_module+0x86/0xb0 [] system_call_fastpath+0x16/0x1b ---[ end trace 628c8f95ba351f1a ]--- WARNING: CPU: 3 PID: 124 at drivers/gpu/drm/i915/intel_display.c:450 i9xx_clock+0x81/0xb0 [i915]() Modules linked in: i915(+) i2c_algo_bit drm_kms_helper drm i2c_core video CPU: 3 PID: 124 Comm: systemd-udevd Tainted: GW3.14.0-rc7 #1 Hardware name: TOSHIBA PORTEGE R830/Portable PC, BIOS Version 4.10 01/08/2013 0009 8804345f7500 8168e6d2 8804345f7538 8108199d 8804345f7608 0100 0001d4c0 880434076b18 8804345f7548 Call Trace: [] dump_stack+0x45/0x56 [] warn_slowpath_common+0x7d/0xa0 [] warn_slowpath_null+0x1a/0x20 [] i9xx_clock+0x81/0xb0 [i915] [] i9xx_crtc_clock_get.isra.31+0x1d0/0x2c0 [i915] [] ironlake_get_pipe_config+0x209/0x2f0 [i915] [] check_crtc_state+0x11e/0xc60 [i915] [] intel_modeset_check_state+0x2bb/0x7b0 [i915] [] ? ilk_wm_get_hw_state+0x1bc/0x2b0 [i915] [] intel_modeset_setup_hw_state+0x97e/0xc20 [i915] [] intel_modeset_gem_init+0x3d/0x50 [i915] [] i915_driver_load+0xc98/0xe10 [i915] [] drm_dev_register+0x7b/0x160 [drm] [] drm_get_pci_dev+0xa0/0x220 [drm] [] i915_pci_probe+0x3b/0x60 [i915] [] local_pci_probe+0x45/0xa0 [] pci_device_probe+0xd1/0x130 [] driver_probe_device+0x125/0x3a0 [] __driver_attach+0x93/0xa0 [] ? __device_attach+0x40/0x40
[Bug 76382] Mesa Gallium egllog _eglLog
https://bugs.freedesktop.org/show_bug.cgi?id=76382 --- Comment #3 from Chris --- (In reply to comment #2) > Post a build log. I would love to but now it compiles fine. It seems that when you compile and install it first with -gallium -opnvg -xa disabled it compiles and installs. After that if you recompile it with the above 3 enabled it compiles fine. i guess it pulls the ellog header from the location it is installed to in the system. I shall run a build on the 10.1 version and see if it still compiles fine and see if i can output the buildlog at the same time. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/87481c1d/attachment-0001.html>
[PATCH 00/16] Atomic/nuclear modeset/pageflip
On Thu, Mar 20, 2014 at 6:34 PM, Greg Hackmann wrote: > On Wed, Mar 19, 2014 at 5:23 AM, Rob Clark wrote: >> >> > Hm, do you have some pointers to read up on this? I still think a more >> > elaborate fail scheme is overkill, but maybe reading a bit of android >> > code >> > convinces me differently ;-) >> >> sadly no pointers to anything to read (but ofc would be interested if >> anyone else does).. > > > The hardware composer HAL is probably the best reference for what Android > needs from display. It's defined and documented here (see struct > hwc_composer_device_1): > > https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/hwcomposer.h > cool, thx for the link > (You can disregard any HWC 1.0 specific behavior in that documentation, > that's only around for legacy reasons and we strongly encourage vendors not > to implement HWC 1.0 anymore.) > > Vendors need to ship a compliant HWC HAL implementation on their devices. > We don't mandate anything about their userspace/kernel interface beyond > that. > >> >> * I kinda would still like to add to the atomic ioctl some way to >> indicate >>ok/error on a bit finer granularity than per-ioctl. Ie. perhaps an >>array where userspace can ask for results per KMS object (crtc/plane)? >>Something along these lines would give the kernel a bit more >> flexibility >>to deal with some of the edge cases which come up when you gang crtcs >>for ultra high resolution displays. In short, it would let the driver >>"steal" some of the planes if needed from userspace. >> >>This would also, conveniently, be pretty similar to how (AFAIU) hw >>compositor and ADF work on android. Which seems like it would be >> useful >>to eventually enable android devices to use an upstream display driver. >> >>For this we could pretty easily just throw in a placeholder that we >>could replace later with an optional ptr to __user array. I think >>that would be fine for an initial version, but I just wanted to throw >>this idea out there, because I think it will become important. > > > SurfaceFlinger needs the HWC HAL to return a retire fence fd on each flip, > for each display. Per-interface return data would be a good fit for this, > but per-CRTC or per-plane would work too (userspace could assemble a > per-interface fence by merging finer-grained fences). oh, that's right.. I'm glad you reminded me, I do remember now talk of a field which drivers could use to return some opaque (to drm core) handle/value/token/whatever.. hmm, for the non-vsync'd multi-display case, does it matter much one ioctl per display vs one globally? If no, I'd vote for just one output field in the ioctl struct which can be whatever the driver wants it to.. that would be pretty simple. > It's up to the vendor whether their HWC HAL does fine-grained error handling > and renegotiation like you're describing. Typically they don't, they just > push that complexity into userspace instead. e.g. if the display controller > needs to gang together two planes for a given configuration, the HWC HAL's > prepare() op will already know to set aside that extra plane and plan > accordingly. Well, I suspect that this is in the HWC HAL at all is a strong indication that we should think about including this somehow in the atomic ioctl.. considering that the trend for wayland compositors is a fairly generic userspace just using kms+gbm directly. I suspect the alternative will only be an atomic2 ioctl at some point ;-) A crazy idea.. if atomic ioctl could atomically both write and then read some properties. Maybe kill two birds with one stone by letting userspace both specify a set of properties it wants to write, and also a set to read. BR, -R >
3.14 radeon regression: radeon is broken (pci bug?)
80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 60 77 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 ff:10.4 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 [8086:3cb4] (rev 06) Subsystem: Micro-Star International Co., Ltd. Device [1462:7760] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snbep_uncore 00: 86 80 b4 3c 00 00 10 00 06 00 80 08 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 60 77 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 ff:10.5 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 [8086:3cb5] (rev 06) Subsystem: Micro-Star International Co., Ltd. Device [1462:7760] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snbep_uncore 00: 86 80 b5 3c 00 00 10 00 06 00 80 08 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 60 77 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 ff:10.6 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 [8086:3cb6] (rev 06) Subsystem: Micro-Star International Co., Ltd. Device [1462:7760] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00: 86 80 b6 3c 00 00 10 00 06 00 80 08 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 60 77 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 ff:10.7 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 [8086:3cb7] (rev 06) Subsystem: Micro-Star International Co., Ltd. Device [1462:7760] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00: 86 80 b7 3c 00 00 10 00 06 00 80 08 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 60 77 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 ff:11.0 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 DDRIO [8086:3cb8] (rev 06) Subsystem: Micro-Star International Co., Ltd. Device [1462:7760] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/6a575a62/attachment-0002.bin> -- next part -- 00:00.0 Host bridge [0600]: Intel Corporation Xeon E5/Core i7 DMI2 [8086:3c00] (rev 06) Subsystem: Micro-Star International Co., Ltd. Device [1462:7760] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00: 86 80 00 3c 00 00 10 00 06 00 00 06 10 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 60 77 30: 00 00 00 00 90 00 00 00 00 00 00 00 00 01 00 00 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a [8086:3c02] (rev 06) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00: 86 80 02 3c 07 04 10 00 06 00 04 06 10 00 81 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 00 00 20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 10 00 00:02.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a [8086:3c04] (rev 06) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities:
