On Thu, Feb 14, 2013 at 3:28 PM, Steven Rostedt wrote:
> On Thu, 2013-02-14 at 15:19 +0100, Borislav Petkov wrote:
>> On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote:
>> > Hi Steven,
>> >
>> > Since about a year ago we've switched drm/i9
ped the tree for today.
Meh, that fail was already reported from Wu's kernel builder a few
days ago, but no patch yet showed up to fix things. Since the i915
side of that work isn't ready yet either I've dropped the offending
patches.
-Daniel
--
Daniel Vetter
Software E
On Fri, Feb 15, 2013 at 12:27 AM, Stephen Rothwell
wrote:
> Hi Daniel,
>
> On Thu, 14 Feb 2013 15:19:53 +0100 Borislav Petkov wrote:
>>
>> On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote:
>> >
>> > Since about a year ago we've switched
}
> +#endif /* CONFIG_VT_CONSOLE_SLEEP */
>
> /*
> * Device power management
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/i
o_crtc_mapping[pipe];
+
+ if (!crtc->enabled)
+ continue;
+
+ intel_crtc_restore_mode(crtc);
}
i915_redisable_vga(dev);
The issue is that we save a pointer to the fb (since those are refco
On Sun, Feb 17, 2013 at 2:38 PM, Daniel Vetter wrote:
> 2. The new i915 force restore code is indeed missing a safety check
> compared to the old crtc helper based one:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6eb38
On Sun, Feb 17, 2013 at 5:31 PM, Hugh Dickins wrote:
> On Sun, 17 Feb 2013, Daniel Vetter wrote:
>> On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
>> > On Sat, 16 Feb 2013, Hugh Dickins wrote:
>> >> On Sat, 16 Feb 2013, Linus Torvalds wrote:
>> >&g
On Wed, Feb 13, 2013 at 07:40:05PM +0100, Daniel Vetter wrote:
> On Tue, Jan 22, 2013 at 7:55 PM, David Woodhouse wrote:
> > On Mon, 2013-01-21 at 19:48 +0100, Daniel Vetter wrote:
> >> We already have the quirk entry for the mobile platform, but also
> >> reports on s
gt; to keep.
If a driver needs its own irq setup/teardown magic, I'd prefer if we
simply extract the useful parts of the common code into a little
helper that drivers can call, and don't add new&fancy callbacks and
interface. At least not without really good reasons.
/me has seen en
> up like this, I get nothing but "no signal" after leaving BIOS mode. Turning
> the tv on/off, cable plug/unplug does not help.
Can you please boot in that configuration on latest kernel with
drm.debug=0xe added to your kernel cmdline and then attach the
complete dmesg?
Thanks,
rk without intel_agp module!\n");
return -ENODEV;
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
ybridge);
+
+ driver.driver_features &=
+ ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);
return drm_get_pci_dev(pdev, ent, &driver);
}
Yours, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line &quo
driver bound by
accident to the intel graphics? You can check that with lspci -k
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
eg Kroah-Hartman
Acked-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index ff2819e..682156a 10064
On Mon, Oct 15, 2012 at 5:11 PM, Greg KH wrote:
> On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
>> Hi Greg&stable-team,
>>
>> The below patch papers over a graphics corruption issue in 3.5/3.6. The
>> regression happened due to pwrite tunings in
generic exporter that would allocate the dma_buf at the right spot for
all cases, but I think we should consider this to not draw ourselves
into an ugly api corner.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsu
n a MacbookPro10,1.
My apologies for the long delay in answering, I've somehow mixed up
different bugreports and thought I've sent you a patch to test
already. Anyway, please test
https://patchwork.kernel.org/patch/1728111/
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corp
nel.org/patch/1728111/
>
> Tested-by: Henrik Rydberg
Can you please boot with drm.debug=0xe added to your kernel cmdline
with that patch applied and attach the full dmesg?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscr
110
> [<80147224>] ? process_one_work+0x104/0x380
> [<8013d963>] ? internal_add_timer+0x13/0x40
> [<80344f10>] ? poke_blanked_console+0xb0/0xb0
> [<80147797>] ? worker_thread+0x107/0x3a0
> [<80147690>] ? rescuer_thread+0x1c0/0x1c0
> [<8014bd7c>] ? kt
-by-one error:
>
> /* Scour memory looking for the VBT signature */
> for (i = 0; i + 4 < size; i++) {
>
> If that matters or not, I do not know. Any more tests would have to
> wait until tomorrow.
Yeah, the utter lack of a vbt fits very nicely, thanks for checking,
I&
On Thu, Nov 22, 2012 at 10:35:22PM +0100, Krzysztof Mazur wrote:
> On Thu, Nov 22, 2012 at 09:17:54PM +0100, Daniel Vetter wrote:
> > Hi,
> >
> >
> > Since a dpms ioctl call tends to follow a modeset, this likely only
> > results in that dpms call enabling
On Fri, Jan 11, 2013 at 6:26 PM, Nikola Pajkovsky wrote:
> bug still kicking even w/ (drm/i915: Revert shrinker changes from "Track
> unbound pages")
Could be a different bug, can you please attach the error_state somewhere?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Co
e requested hole", both should apply to 3.7 without fuzz.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
...
>>>
>>> Is there another acpi_video? device? In my case two showed up in 3.7
>>> whereas in 3.6 there was one. In 3.7 it was controlling the wrong one
>>> apparently.
>>
>> Well, this seems not to be the case, I have only one acpi_video:
>>
On Mon, Jan 14, 2013 at 7:58 AM, Nikola Pajkovsky wrote:
> Daniel Vetter writes:
>
>> On Fri, Jan 11, 2013 at 6:26 PM, Nikola Pajkovsky
>> wrote:
>>> bug still kicking even w/ (drm/i915: Revert shrinker changes from "Track
>>> unbound pages")
'm wrong.
>
> Daniel, do you agree with this?
Yeah, seems like the sanest thing to do given the situation and lack
of any understanding what's actually going on.
/me goes back to screaming silently
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48
g at runtime.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
I think it'd be good if we could merge this for 3.7 ...
-Daniel
> ---
> include/linux/dma-buf.h | 99
> ---
> 1 file changed, 99 deletions(-)
>
&g
at this particular elephant is only wreaking havoc in 3.4
and earlier?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
Airlie is pushing back a bit ...
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
l built with "my" config file, intel_iommu=igfx_off
> passed
> [*] dmesg for the kernel built with "my" config file, iommu=off and
> intel_iommu=off passed
>
> Hope we can squash those bugs!
>
> Best regards,
>
>
>
> Mihai
>
>
>
>
way to reproduce) please
grab the i915_error_state file from debugfs and file a bug on
bugs.freedesktop.org against DRM - DRI (Intel). We do know of a few recent
issues introduced around 3.7 kernels, preliminary patches are floating
around. The error state should be good enough to decide whether you&#x
->mode.clock (but lost you from cc).
I'll forward his patch asap (still digging through the mail flood from
vacation).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "un
in the code that
this additional protection is required due to half-done fastboot
support? I'd like to merge it asap and forward the patch to
Dave/Linus.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from thi
9ddf106d381
> Author: Daniel Vetter
> Date: Mon Jul 2 20:28:59 2012 +0200
>
> drm/i915: read out the modeset hw state at load and resume time
>
> but then combined with
>
> commit b0a2658acb5bf9ca86b4aab011b7106de3af0add
> Author: Daniel Vetter
> Date: Tue D
.
>> and file a bug on
>> bugs.freedesktop.org against DRM - DRI (Intel).
>
> Would it still be useful for me to file a bug? (Just going through the
> new-account confirmation dance now.)
Looks like the ilk bug tracked at
https://bugs.freedesktop.org/show_bug.cgi?id=55984
-Danie
athan Corbet
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
Documentation/kernel-doc-nano-HOWTO.txt | 362
1 file changed, 362 deletions(-)
delete mode 100644 Documentation/kernel-doc-nano-HOWTO.txt
diff --git a/Documentation/kernel-doc-nano-HOWT
ged(struct drm_device
> *drm)
> {
> struct sun4i_drv *drv = drm->dev_private;
>
> - if (drv->fbdev)
> - drm_fbdev_cma_hotplug_event(drv->fbdev);
> + drm_fbdev_cma_hotplug_event(drv->fbdev);
> }
>
> static const struct drm_
gt;ddc_bus);
> drm_connector_unregister(connector);
> drm_connector_cleanup(connector);
> kfree(connector);
> @@ -835,11 +834,9 @@ out:
>
> failed_find:
> mutex_unlock(&dev->mode_config.mutex);
> - if (lvds_priv->ddc_bus)
> -
FP_KERNEL);
> + entry->buflist = kcalloc(count, sizeof(*entry->buflist), GFP_KERNEL);
> if (!entry->buflist) {
> mutex_unlock(&dev->struct_mutex);
> atomic_dec(&dev->buf_alloc);
> --
> 2.10.0
>
> __
_gem.c | 44 +++-
> 2 files changed, 49 insertions(+), 53 deletions(-)
>
> --
> 2.10.0
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
patch.
> Sounds like I should revert?
I thought I looked at the entire situation and since we register
(since recently) all connectors in drm_dev_register() there shouldn't
be an issue for any other driver. Imo no need to revert anything here
- until someone complains with a bug report and proves me wrong ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
if (ret)
> + goto err_fbdev_fini;
> +
> if (is_support_iommu)
> arm_iommu_release_mapping(mapping);
> return 0;
> +err_fbdev_fini:
> + rockchip_drm_fbdev_fini(drm_dev);
> err_vblank_cleanup:
> drm_vblank_cleanup(drm_dev);
> err_kms
g). The dma-buf sync ioctl allows userspace to prepare the
> dma-buf for CPU access, which should include waiting upon rendering.
> (Some drivers may need to do more work to ensure that the dma-buf mmap
> is coherent as well as complete.)
>
> Signed-off-by: Chris Wilson
> Cc: Sumit
rt this. There's a problem in the fbdev helper code
> which stops me fixing this quickly, so better to revert it.
Hm, what's the trouble wih fbdev? But yeah given this trouble I'd go
with a revert for now. For the real fix I guess we could just squash
it all in one, kinda pointless to go overboard for this.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
handled in MAINTAINERS.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
emulation doesn't do that for you. If you need/want to shut down
all the crtcs on driver unload, you need to do that yourself. There's
atomic helpers to do that for you that for you.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Fri, Sep 23, 2016 at 01:52:49PM +0100, Brian Starkey wrote:
> On Fri, Sep 23, 2016 at 12:58:46PM +0200, Daniel Vetter wrote:
> > On Fri, Sep 23, 2016 at 11:34 AM, Liviu Dudau wrote:
> > > rmmod-ing the hdlcd module generates a WARN() splat as the vsync is still
> > >
On Fri, Sep 23, 2016 at 03:05:03PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 23, 2016 at 03:13:15PM +0200, Daniel Vetter wrote:
> > Hm, maybe we should simply not call ->lastclose for kms drivers. That is
> > kinda only a hack for ums/dri1 drivers.
>
> Are you
On Fri, Sep 23, 2016 at 03:42:52PM +0100, Brian Starkey wrote:
> On Fri, Sep 23, 2016 at 03:13:15PM +0200, Daniel Vetter wrote:
> > On Fri, Sep 23, 2016 at 01:52:49PM +0100, Brian Starkey wrote:
> > > On Fri, Sep 23, 2016 at 12:58:46PM +0200, Daniel Vetter wrote:
> > > &
id *)dp->edid;
> @@ -1093,7 +1093,7 @@ static const struct drm_connector_helper_funcs
> analogix_dp_connector_helper_func
> .best_encoder = analogix_dp_best_encoder,
> };
>
> -enum drm_connector_status
> +static enum drm_connector_status
> analogix_dp_detect(str
ue.
I've thrown this one already into drm-misc, and it's wrapped up in my
latest pull to Dave already.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
f scanout engines which you need to dynamically
allocate.
> On 2016年07月26日 17:51, Mark yao wrote:
> > On 2016年07月26日 16:26, Daniel Vetter wrote:
> > > On Tue, Jul 26, 2016 at 03:46:32PM +0800, Mark Yao wrote:
> > > > >What is share plane:
> > > > >Plane hard
=
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---
> ¯\_(ツ)_/¯
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
>
> > ret = component_bind_all(dev, drm);
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ed_work(&dev->mode_config.output_poll_work,
> DRM_OUTPUT_POLL_PERIOD);
> + schedule_delayed_work(&dev->mode_config.output_poll_work,
> delay);
> }
> EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
>
> --
> 2.9.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
onnal, that can be set to NULL.
> >
> > OK.
> >
> > >> if (!IS_ERR(tcon->panel))
> > >> drm_panel_disable(tcon->panel);
> > >> @@ -230,6 +228,9 @@ int sun4i_rgb_init(struct drm_device *drm)
> > >>
On Thu, Sep 01, 2016 at 09:41:35AM +0200, Tomeu Vizoso wrote:
> Also provide some pointers for building IGT as some kernel hackers might
> not be that familiar with building stuff on Linux distros.
>
> Signed-off-by: Tomeu Vizoso
> Cc: Daniel Vetter
Applied to drm-misc,
ent
(if there's an event) from your update hook. That /should/ work, but I
didn't test it myself. flip_done not happening is when the
driver/helpers fail to submit the event for some reason or another.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
t possible
> + */
> +
> + bpp = (fb->base.bits_per_pixel + 7) / 8;
> + size = cmd->pitches[0] * cmd->height;
> + if (!bpp ||
> + bpp > 4 ||
> + cmd->pitches[0] < bpp * fb->base.width ||
> + cmd->pitches[
arm-kernel/2014-August/279071.html
simpledrm isn't a real driver, but only meant to be used to drive the
firmware framebuffer in early boot until a real driver takes over. It's a
replacement really for all the various uefi/vesa/whatever fbdev drivers.
Full reliance on the firmware very much intended.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
eded to simpledrmfb. And totally
up to the folks enabling this whether it should be there upfront or only
once needed for a given platform.
-Daniel
>
> Luc Verhaegen.
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
n, mode);
> > +
> > + return 1;
> > +}
> > +
> > +static const struct drm_connector_helper_funcs sdrm_conn_hfuncs = {
> > + .get_modes = sdrm_conn_get_modes,
> > + .best_encoder = drm_atomic_helper_best_en
r a full modeset is required. At least
with atomic that's easy to fix:
- When the connector state changes we simply need to set the
connectors_changed boolean in the corresponding CRTC state.
- We can use the probe lifecycle counter from above to do that: If it's
changed in atomic_check, t
On Sat, Aug 06, 2016 at 10:26:09PM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > Hm, I can't see v1 anywhere, but I think it'd be better. You can't store
> > any transient state related to the current update in struct drm_plane. In
> > this c
hes) so I can apply it?
-Daniel
>
>
> Regards
>
> David Binderman
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Those are warnings which don't even show up with this
enabled. Just sending this out again in the hopes some has a clue
what's going on.
Cc: Jani Nikula
Cc: Markus Heiser
Cc: Jonathan Corbet
Signed-off-by: Daniel Vetter
---
Documentation/conf.py | 2 +-
1 file changed, 1 insertion(
l fences. What it really tests is the fence
interface (which is public in the uapi headers and all that), but to be
able to do that we need some (hw-independent way) to expose fences, which
this provides.
Long term we might even do this as a proper interface (with some
restrictions to make it safe and avoid userspace pulling the kernel over
the table). And then rip out sw_sync entirely.
Imo there's no need at all for docs for this.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+
> > /*
> > * platform dp driver need containor_of the plat_data to get
> > * the driver private data, so we need to store the point of
> > @@ -1333,13 +1419,6 @@ int analogix_dp_bind(struct device *dev, struct
> > drm_device *drm_dev,
> > phy_power_on(dp->phy);
> > - if (dp->plat_data->panel) {
> > - if (drm_panel_prepare(dp->plat_data->panel)) {
> > - DRM_ERROR("failed to setup the panel\n");
> > - return -EBUSY;
> > - }
> > - }
> > -
> > analogix_dp_init_dp(dp);
> > ret = devm_request_threaded_irq(&pdev->dev, dp->irq,
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > index b456380..43108d7 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > @@ -178,6 +178,9 @@ struct analogix_dp_device {
> > boolforce_hpd;
> > unsigned char edid[EDID_BLOCK_LENGTH * 2];
> > + struct mutexpanel_lock;
> > + boolpanel_is_modeset;
> > +
> > struct analogix_dp_plat_data *plat_data;
> > };
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Aug 08, 2016 at 05:04:03PM +0100, Brian Starkey wrote:
> Hi,
>
> On Mon, Jul 25, 2016 at 05:08:21PM +0200, Daniel Vetter wrote:
> > On Mon, Jul 25, 2016 at 01:54:06PM +0100, Brian Starkey wrote:
> > > Hi Russell,
> > >
> > > On Mon, Jul 25, 20
On Mon, Aug 08, 2016 at 05:25:38PM +0100, Jose Abreu wrote:
> Hi,
>
>
> On 05-08-2016 09:13, Chris Wilson wrote:
> > On Fri, Aug 05, 2016 at 10:06:08AM +0200, Daniel Vetter wrote:
> >> On Fri, Aug 05, 2016 at 12:01:25AM +0100, Russell King - ARM Linux wrote:
> >
nsertions(+), 26 deletions(-)
> >
> > --
> > 2.7.4
> >
> > ___________
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t notifier. Or maybe I entirely misunderstand your code ...
Wrt fixing: Just adding it to the recently added stub is of course
also a working solution.
-Daniel
PS: Can you pls review the 2 patches I submitted with you on cc? I
won't merge my own patches without proper review, so without that done
they're stuck.
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
/ 0xff | ASLE_CBLV_VALID;
>
> --
> 1.9.1
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
as in 20150805, so we have fortunately not gotten worse.
> Let's keep it that way and also fix these drivers.
>
> v2: changes from v1 [0]:
>
> o This now supports iteration, this extends our coverage on the report
>
> o Update documentation and commit log to accept the
int udl_fb_release(struct fb_info *info, int
> user)
>
> ufbdev->fb_count--;
>
> +#ifdef CONFIG_FB_DEFERRED_IO
> if ((ufbdev->fb_count == 0) && (info->fbdefio)) {
> fb_deferred_io_cleanup(info);
> kfree(info->fbdefio);
&
On Wed, Aug 24, 2016 at 12:02 PM, Arnd Bergmann wrote:
> On Wednesday, August 24, 2016 11:01:17 AM CEST Daniel Vetter wrote:
>> On Wed, Aug 24, 2016 at 10:27 AM, Arnd Bergmann wrote:
>> > A cleanup in v4.8 dropped several dependencies, but caused the udl driver
>>
On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez wrote:
> On Wed, Aug 24, 2016 at 08:55:55AM +0200, Daniel Vetter wrote:
>> On Fri, Jun 17, 2016 at 12:54 AM, Luis R. Rodriguez
>> wrote:
>> > Thou shalt not make firmware calls early on init or probe.
>
> &
On Thu, Aug 25, 2016 at 8:37 PM, Peter Zijlstra wrote:
> Poking at lock internals is not cool. Since I'm going to change the
> implementation this will break, take it out.
>
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Signed-off-by: Peter Zijlstra (Intel)
It's horri
o the
>> request_firmware. Everything else we handle already in the kernel.
>
> OK so lets just get this userspace event done, and we're set.
Ah great. As long as that special wait-for-rootfs-pls firmware request
is still allowed, i915&gfx folks will be happy. We will call it fr
22465] [drm:drm_atomic_helper_commit_modeset_enables] enabling
> [ENCODER:26:None-26]
> [ 70.422490] [drm:drm_atomic_state_default_clear] Clearing atomic state
> dad61e00
> [ 70.422504] [drm:drm_mode_object_unreference] OBJ ID: 23 (4)
> [ 70.422519] [drm:drm_atomic_state_free] Freeing atomic state dad61e00
> [ 70.422532] [drm:drm_mode_object_reference] OBJ ID: 29 (2)
> [ 70.422546] [drm:drm_lastclose] driver lastclose completed
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
ep only msm and qxl
headers do this (the other __user annotations in uapi/drm are for
pointers, where it's correct). Adding those maintainers.
Also, if you use u64_to_user_ptr helper macro sparse should have
caught this (if not we'd need to improve the macro).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Yep, those looks pointless indeed.
>
>> Also, if you use u64_to_user_ptr helper macro sparse should have
>> caught this (if not we'd need to improve the macro).
>
> And qxl should actually use it.
>
> Fix attached (compile-tested only so far), does that look ok?
Yup. Assumin
intel-wired-...@lists.osuosl.org
> > > > Cc: net...@vger.kernel.org
> > > > Signed-off-by: Chris Wilson
> > > > [Jani: bikeshed repainted]
> > > > Signed-off-by: Jani Nikula
> > >
> > > Jeff, please make sure this gets submitted to me soon.
> >
> > Expect it later tonight, just finishing up testing.
>
> Tested-by: Aaron Brown
Hm, I seem to be blind, but I can't find it anywhere in -rc6. Does someone
have the sha1 from Linus' git for this patch?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ly display.
>
> "probed"
>
> >
> > Also, remove the mode_fixup() calls as these are no longer needed
> > because mode_valid() will be called before.
> >
> > NOTE: Not even compiled tested
>
> Compile-tested and Reviewed-by: Eric Anholt
Push
_
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt; > > Not sure if intentional, but I like it.
> > >
> > > > }
> > > > + /*
> > > > +* Having this flag means user mode pends on event which will
> > > > never
> > > > +* reach due to lack of at least on
unction. As you look to be the author
> > of it,
> > any reason why the signature of the function doesn't match the
> > drm_fb_helper_ one
> > being called through? (I'm talking about int vs bool for the state/suspend
> > arguments).
>
> I don't remember, but probably to match drm_fbdev_cma_set_suspend()
> which uses int. drm_fb_helper_set_suspend*() uses bool, but calls
> into fb_set_suspend() which uses int, but as a boolean.
I'd be happy to apply a patch which changes them all to bool ...
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
plane);
> int atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state);
> int atmel_hlcdc_plane_prepare_ahb_routing(struct drm_crtc_state *c_state);
>
> +void atmel_hlcdc_gamma_set(struct drm_crtc *c, u16 r, u16 g, u16 b, int idx);
> +void atmel_hlcdc_gamma_get(struct drm_crtc *c, u16 *r, u16 *g, u16 *b, int
> idx);
> +
> void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
>
> int atmel_hlcdc_crtc_create(struct drm_device *dev);
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
>state->gamma_lut->data;
> +
> + for (idx = 0; idx < ATMEL_HLCDC_CLUT_SIZE; idx++, lut++) {
> + u32 val = ((lut->red << 8) & 0xff) |
> + (lut->green & 0xff00) |
> + (lut->blue >> 8);
> +
> + atmel_hlcdc_layer_write_clut(&plane->layer, idx, val);
> + }
> +}
> +
> static void atmel_hlcdc_plane_update_buffers(struct atmel_hlcdc_plane *plane,
> struct atmel_hlcdc_plane_state *state)
> {
> @@ -768,6 +796,7 @@ static void atmel_hlcdc_plane_atomic_update(struct
> drm_plane *p,
> atmel_hlcdc_plane_update_pos_and_size(plane, state);
> atmel_hlcdc_plane_update_general_settings(plane, state);
> atmel_hlcdc_plane_update_format(plane, state);
> + atmel_hlcdc_plane_update_clut(plane);
> atmel_hlcdc_plane_update_buffers(plane, state);
> atmel_hlcdc_plane_update_disc_area(plane, state);
>
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jun 20, 2017 at 11:55:01AM +0200, Peter Rosin wrote:
> On 2017-06-20 11:40, Daniel Vetter wrote:
> > On Sat, Jun 17, 2017 at 07:48:02PM +0200, Peter Rosin wrote:
> >> All layers of all supported chips support this, the only variable is the
> >> base address
.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+ ret = crtc->funcs->gamma_set(crtc, r, g, b,
> + crtc->gamma_size, &ctx);
> + if (ret)
> + break;
> }
> - out:
> - drm_modeset_unlock_all(dev);
> - return rc;
>
| 1 -
> include/drm/drm_fb_helper.h | 32 ---
> include/drm/drm_modeset_helper_vtables.h| 16
> 36 files changed, 171 insertions(+), 640 deletions(-)
>
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote:
> On 21/06/17 04:38 PM, Daniel Vetter wrote:
> > On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
> >> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> >> totally obso
27;ve left in to make it clear this isn't
anything for merging.
Cheers, Daniel
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: "GitAuthor: Daniel Vetter"
Cc: Guneshwor Singh
Cc: Hardik T Shah
Cc: Julia Lawall
Cc: Vinod Koul
Cc: "Subhransu S. Prusty"
Cc: Libin Yang
On Wed, Jun 21, 2017 at 11:40:52AM +0200, Peter Rosin wrote:
> On 2017-06-21 09:38, Daniel Vetter wrote:
> > On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
> >> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> >> totally obso
e136ff6fda09f2d799 DRM: Armada: Add Armada DRM
> driver
>
> :: TO: Russell King
> :: CC: Russell King
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jun 21, 2017 at 11:50:01AM -0700, Eric Anholt wrote:
> Now that we're using the atomic helpers for fence waits, we can use
> the same codepath as drm_atomic_helper_commit() does for async,
> getting rid of our custom vc4_commit struct.
\o/
On the series: Acked-by:
_round_rate() does
> not return the expected rate.
Alexey reviewed it already, and Dave acked it for merging through
drm-misc, so applied.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
401 - 500 of 3914 matches
Mail list logo
