Hi Dave,
So first of a few pull requests for drm-next for 3.16 this week from me.
This here is the coverity stuff, all nicely reviewed. As discussed on irc
I've dropped the ast patch since you have the proper fix. Nothing in here
is imo -fixes material, especially with an already grumpy Linus
Hi Thierry,
On Tue, Apr 22, 2014 at 2:57 PM, Thierry Reding
wrote:
> On Tue, Apr 22, 2014 at 04:09:18AM +0530, Ajay Kumar wrote:
>> This patch adds ps8622 lvds bridge discovery code to the dp driver.
>>
>> Signed-off-by: Rahul Sharma
>> Signed-off-by: Ajay Kumar
>> ---
>> Changes since V1:
>>
So I just wanted to add a new field to struct drm_device and
accidentally stumbled over something. According to comments
dev->open_count is protected by dev->count_lock, but that's totally
not the case. It's protected by drm_global_mutex.
Unfortunately the vga switcheroo callbacks took this
To get rid of the dev->bus->get_irq callback we need to pass in the
desired irq explicitly into drm_irq_install. To avoid having to do the
same for drm_irq_unistall just track it internally. That leaves
drivers with less room to botch things up.
v2: Add the hunk lost in an earlier patch to this
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/2b8c7d86/attachment-0001.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/4714cbf4/attachment.html>
ast, how it need to be ;).
--
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/20140422/db5d649d/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140422/fece8496/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/f9de221f/attachment.html>
||
--
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/20140422/0079429f/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/e158ef05/attachment-0001.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/7644dbec/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/ee293a16/attachment.html>
||
--
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/20140422/00cb0166/attachment.html>
hts... some screenshots i will attach.
And yeah swrast works OK, fglrx too :)
--
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/20
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/e7df4d0d/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/474ae78f/attachment-0001.html>
for these lockups?
--
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/20140422/06ff2b22/attachment.html>
Hi Thierry,
On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding
wrote:
> On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
>> Register exynos_dp_panel before the list of exynos crtcs and
>> connectors are probed.
>>
>> This is needed because exynos_dp_panel should be registered to
>> the
Hi Thierry,
On Tue, Apr 22, 2014 at 1:56 PM, Thierry Reding
wrote:
> On Tue, Apr 22, 2014 at 04:09:12AM +0530, Ajay Kumar wrote:
>> This patch adds a simple driver to handle all the LCD and LED
>> powerup/down routines needed to support eDP/eDP-LVDS panels
>> supported on exynos boards.
>>
>>
https://bugzilla.kernel.org/show_bug.cgi?id=73901
--- Comment #16 from Pali Roh?r ---
My bad, I'm using tlp which calling:
$ echo on > /sys/bus/pci/devices/:01:00.0/power/control
when notebook is running on ac. And this prevent runpm to work correctly. After
I blacklisted radeon card in tlp
Hi Jingoo,
On Tue, Apr 22, 2014 at 12:52 PM, Jingoo Han wrote:
>
> On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
> >
> > This patch adds a simple driver to handle all the LCD and LED
> > powerup/down routines needed to support eDP/eDP-LVDS panels
> > supported on exynos boards.
> >
> >
n support pre_enable and post_disable, why not
drm_panel provide that both should work in tandem?
> There's got to be a better way to solve this.
>
> Thierry
Thanks and Regards,
Ajay Kumar
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/366ae5de/attachment.html>
Hi Sean,
On Tue, Apr 22, 2014 at 7:01 PM, Sean Paul wrote:
>
> On Mon, Apr 21, 2014 at 6:39 PM, Ajay Kumar
> wrote:
> > This patch adds a drm_bridge driver for the PS8622 DisplayPort to LVDS
> > bridge chip.
> >
> > Signed-off-by: Andrew Bresticker
> > Signed-off-by: Sean Paul
> >
private;
> > +
> > + mutex_lock(_bridge->enable_mutex);
> > +
> > + if (!ps_bridge->enabled)
> > + goto out;
> > +
> > + ps_bridge->enabled = false;
> > +
> > + drm_panel_disable(ps_bridge->panel);
> > + msleep(PS8622_PWMO_END_T12_MS);
> > +
> > + /*
> > + * This doesn't matter if the regulators are turned off, but
> something
> > + * else might keep them on. In that case, we want to assert the
> slp gpio
> > + * to lower power.
> > + */
> > + if (gpio_is_valid(ps_bridge->gpio_slp_n))
> > + gpio_set_value(ps_bridge->gpio_slp_n, 0);
> > +
> > + drm_panel_post_disable(ps_bridge->panel);
> > + if (ps_bridge->v12)
> > + regulator_disable(ps_bridge->v12);
> > +
> > + /*
> > + * Sleep for at least the amount of time that it takes the power
> rail to
> > + * fall to prevent asserting the rst gpio from doing anything.
> > + */
> > + usleep_range(PS8622_POWER_FALL_T16_MAX_US,
> > + 2 * PS8622_POWER_FALL_T16_MAX_US);
> > + if (gpio_is_valid(ps_bridge->gpio_rst_n))
> > + gpio_set_value(ps_bridge->gpio_rst_n, 0);
> > +
> > + msleep(PS8622_POWER_OFF_T17_MS);
> > +
> > +out:
> > + mutex_unlock(_bridge->enable_mutex);
> > +}
> > +
> > +static void ps8622_post_disable(struct drm_bridge *bridge)
> > +{
> > +}
>
> How about just removing this empty function?
That is not possible. Because the bridge callbacks are called in this
fashion:
bridge->funcs->post_disable(bridge);
So, if that particular callback turns NULL, it will crash!
>
[.]
>
> Best regards,
> Jingoo Han
>
>
Regards,
Ajay Kumar
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/5c712e01/attachment-0001.html>
Hi Dave,
this is the first pull request for stashed radeon fixes for 3.15.
Highlights:
1. Further PLL parameter fixes.
2. Fixes for HPD on DP
3. Could of different PM fixes
4. Disabling DPM on RV770
The following changes since commit a42892ed10585c5511e8a3e53f0350b4e2242050:
Merge branch
On Tue, Apr 22, 2014 at 04:19:45PM +0200, Daniel Vetter wrote:
> The introduction of primary planes has apparently caused a bit of fb
> refcounting fun for people. That makes it a good time to clean up the
> arcane rules and slight differences between ->update_plane and
> ->set_config. The new
Am Dienstag, den 22.04.2014, 09:23 +0200 schrieb Thierry Reding:
> On Mon, Apr 21, 2014 at 01:43:18PM -0600, Stephen Warren wrote:
> > On 04/17/2014 06:02 AM, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Properties referencing GPIOs should use the plural suffix -gpios. This
> > >
|--- |FIXED
--- Comment #4 from Iaroslav ---
fixed after update
--
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/20140
On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> To implement hotplug detection in a race-free manner, drivers must call
> drm_kms_helper_poll_init() before hotplug events can be triggered. Such
> events can be triggered right after any of the encoders
On Tue, Apr 22, 2014 at 05:09:32PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Add a helper function that allows drivers to statically set the unique
> name of the device. This will allow platform and USB drivers to get rid
> of their DRM bus implementations and directly use
On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
>
> This patch adds a drm_bridge driver for the PS8622 DisplayPort to LVDS
> bridge chip.
>
> Signed-off-by: Andrew Bresticker
> Signed-off-by: Sean Paul
> Signed-off-by: Rahul Sharma
> Signed-off-by: Ajay Kumar
> ---
> Changes since V1:
On Tue, Apr 22, 2014 at 04:42:19PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> There's no need for this to be modifiable. Make it const so that it can
> be put into the .rodata section.
>
> Signed-off-by: Thierry Reding
Reviewed-by: Daniel Vetter
> ---
>
On Tue, Apr 22, 2014 at 04:09:09PM +0200, Daniel Vetter wrote:
> On Tue, Apr 22, 2014 at 01:06:22PM +0300, Ville Syrj?l? wrote:
> > On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote:
> > > The introduction of primary planes has apparently caused a bit of fb
> > > refcounting fun for
er doesn't matter one bit. It may happen to work
most of the time, but as soon as one of the resources that your panel
driver needs isn't there when the panel is probed, then it won't be
registered and of_drm_find_panel() will still return NULL.
Usually the right thing to do in that case would be to return (and
propagate) -EPROBE_DEFER so that your driver's probe is deferred and
retried when other drivers have been probed. That way it should
eventually get a non-NULL panel.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/392c4797/attachment.sig>
isn't specific to one SoC. And the name doesn't imply that either. Also
each panel is still identified by the specific compatible value, which
makes it easier to find out which driver supports the panel.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/a60d37de/attachment.sig>
From: Thierry Reding
Instead of the current implementation, reuse the recently introduced
master/component framework, which is equivalent in most regards. One
issue is that there is no device to bind the DRM driver to. In order
to still allow the driver to be probed, expose
From: Thierry Reding
Add a helper function that allows drivers to statically set the unique
name of the device. This will allow platform and USB drivers to get rid
of their DRM bus implementations and directly use drm_dev_alloc() and
drm_dev_register().
Signed-off-by:
From: Thierry Reding
Some drivers, such as graphics drivers in the DRM subsystem, do not have
a real device that they can bind to. They are often composed of several
devices, each having their own driver. The master/component framework
can be used in these situations to
From: Thierry Reding
Similarly to what can be done for device drivers, allow driver-specific
data to be attached to a master. This is necessary for masters whose
device is already bound to by a different driver and therefore cannot be
used to store the driver-specific data.
From: Thierry Reding
Currently the component/master framework allows only a single master to
be registered against a struct device. A master is uniquely identified
by the device and the master operations table, but the current API does
not pass enough information along to
From: Thierry Reding
Hi,
This series converts the Tegra DRM driver to the master/component
framework. The length of the series and the list of people in Cc is
mostly due to the fact that Tegra has some special requirements as
opposed to other drivers and therefore requires
From: Michel D?nzer
The way the tile mode array index was calculated only makes sense for
the CIK specific macrotile mode array. For SI, we need to use one of the
tile mode array indices reserved for displayable surfaces.
This happened to result in correct display most
Am 15.04.2014 18:44, schrieb Alex Deucher:
> Need to properly unregister the hwmon device on driver
> unload.
>
> v2: minor clean up
>
> bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=73931
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
Added to my 3.15 queue.
Sorry for the
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/07b16def/attachment.html>
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/8811c326/attachment.html>
From: Thierry Reding
A race condition currently exists on Tegra, where it can happen that a
monitor attached via HDMI isn't detected during the initial FB helper
setup, but the hotplug event happens too early to be processed by the
poll helpers because they haven't been
From: Thierry Reding
To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the
From: Thierry Reding
There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 2 +-
From: Daniel Vetter
Some drivers need to be able to have a perfect race-free fbcon setup.
Current drivers only enable hotplug processing after the call to
drm_fb_helper_initial_config which leaves a tiny but important race.
This race is especially noticable on embedded
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/20140422/a7b6a0a1/attachment.html>
On Tue, Apr 22, 2014 at 4:28 PM, Ville Syrj?l?
wrote:
>> Not sure what to do here really.
>
> Just s/drm_gem_object_unreference_unlocked/drm_gem_object_unreference/
> and grab struct_mutex by hand around both operations?
I was kinda hoping for someone to go ahead and fix the entire fb
tracking
is 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/20140422/709e6476/attachment-0001.html>
Am 22.04.2014 14:17, schrieb Alex Deucher:
> Should be 5 rather than 4.
>
> Noticed-by: Mathias Fr?hlich
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
Added to my 3.15 queue.
Christian.
> ---
> drivers/gpu/drm/radeon/cik_sdma.c | 2 +-
> 1 file changed, 1 insertion(+), 1
https://bugzilla.kernel.org/show_bug.cgi?id=74121
--- Comment #2 from Alan ---
(Please also email the driver maintainers or relevant list)
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=74121
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Regression|No
On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
>
> This patch adds a simple driver to handle all the LCD and LED
> powerup/down routines needed to support eDP/eDP-LVDS panels
> supported on exynos boards.
>
> The LCD and LED units are usually powered up via regulators,
> and almost on all
The introduction of primary planes has apparently caused a bit of fb
refcounting fun for people. That makes it a good time to clean up the
arcane rules and slight differences between ->update_plane and
->set_config. The new rules are:
- The core holds a reference for both the new and the old fb
https://bugzilla.kernel.org/show_bug.cgi?id=74331
--- Comment #1 from Alan ---
Reporting it here is fine for an upstream kernel, but this is mostly used to
track bugs not necessarily fix them.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=74331
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
>
> From: Andrew Bresticker
>
> Certain bridge chips use a GPIO to indicate the cable status instead
> of the I_DP_HPD pin. This adds an optional device-tree property,
> "samsung,hpd-gpio", to the exynos-dp controller which indicates that
>
On Tue, Apr 22, 2014 at 01:06:22PM +0300, Ville Syrj?l? wrote:
> On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote:
> > The introduction of primary planes has apparently caused a bit of fb
> > refcounting fun for people. That makes it a good time to clean up the
> > arcane rules and
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings and cpu timings.
>
> Changelog v2:
> - Adds unit address (commented by Sachin Kamat)
> Changelog v3:
> - Removes optional delay, size properties
On Tue, Apr 22, 2014 at 07:34:03AM -0400, Rob Clark wrote:
> So what about, rather than adding drm_panel support to each bridge
> individually, we introduce a drm_panel_bridge (with a form of
> chaining).. ie:
>
> struct drm_panel_bridge {
> struct drm_bridge base;
> struct drm_panel
https://bugzilla.kernel.org/show_bug.cgi?id=74551
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
On Tue, Apr 22, 2014 at 12:07:41PM +, Sharma, Shashank wrote:
> Thanks again David,
> Comments inline.
Three things:
- Please don't send out .pptx files to upstream/public mailing lists,
that's just not how the upstream community works.
- Please either fix up ms outlook to do proper
Hi
On Tue, Apr 22, 2014 at 2:44 PM, Florian Weimer wrote:
> I didn't find that very convincing. But in v2, seals are monotonic, so
> checking them should be reliable enough.
Ok.
> What happens when you create a loop device on a write-sealed descriptor?
Any write-back to the loop-device will
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/20140422/c1b91c86/attachment.html>
Use %pad for dma_addr_t, because a dma_addr_t type can vary
based on build options. So, it prevents possible build warnings
in printks.
Signed-off-by: Jingoo Han
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 +-
2 files changed, 2
On 04/22/2014 01:55 PM, David Herrmann wrote:
> Hi
>
> On Tue, Apr 22, 2014 at 11:10 AM, Florian Weimer
> wrote:
>> Ah. What do you recommend for recipient to recognize such descriptors?
>> Would they just try to seal them and reject them if this fails?
>
> This highly depends on your use-case.
Hi YoungJun,
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> Some phy control registers are not kept after software reset.
> So this patch makes the clocks containing phy control to be set
> after software reset.
>
> Signed-off-by: YoungJun Cho
> Acked-by: Inki Dae
> Acked-by: Kyungmin Park
>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/bb6e4646/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/3a6dd10d/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/f534f2e0/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/fd4aea29/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/bc631898/attachment.html>
Hi
On Tue, Apr 22, 2014 at 11:10 AM, Florian Weimer wrote:
> Ah. What do you recommend for recipient to recognize such descriptors?
> Would they just try to seal them and reject them if this fails?
This highly depends on your use-case. Please see the initial email in
this thread. It describes
On Tue, Apr 22, 2014 at 12:08 PM, Thierry Reding
wrote:
> void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
> *helper,
>const struct drm_fb_helper_funcs *funcs)
> {
> helper->funcs = funcs;
> helper->dev = dev;
> }
>
> So I wonder
Hi
On Tue, Apr 22, 2014 at 12:21 PM, Sharma, Shashank
wrote:
> 1) Why do you register only a single property? Why not register a separate
> property for each color-correction that is available? This way you can drop
> the property-id and use the high-level DRM-prop IDs/names.
>>> That?s the
On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote:
> On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
>> Separation of the interfaces exposed by the device from the device itself
>> seems to me a good thing. I would even consider it as a biggest
>> advantage of this solution :)
On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote:
> The introduction of primary planes has apparently caused a bit of fb
> refcounting fun for people. That makes it a good time to clean up the
> arcane rules and slight differences between ->update_plane and
> ->set_config. The new
On Tue, Apr 22, 2014 at 01:29:54PM +0200, Andrzej Hajda wrote:
> On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote:
> > On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
> >> Separation of the interfaces exposed by the device from the device itself
> >> seems to me a good thing.
buse already.
>
> In any case this should be a separate patch.
I agree. This patch mostly mechanically replaces things and this bug did
already exist previously. So let's fix it separately (if at all).
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/45302ad3/attachment.sig>
836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/bc54b184/attachment.sig>
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
const struct drm_fb_helper_funcs *funcs)
{
helper->funcs = funcs;
helper->dev = dev;
}
So I wonder if that's still what we want or whether drivers should
simply be doing that manually if they need to. Having a function for it
gives us a place to document things, though, and perhaps at some point
we'll have to extend this, so it may be a good idea after all, even if
it's just the two lines currently.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/b398c072/attachment.sig>
Thanks again David,
Comments inline.
Regards
Shashank
-Original Message-
From: David Herrmann [mailto:dh.herrm...@gmail.com]
Sent: Tuesday, April 22, 2014 5:10 PM
To: Sharma, Shashank
Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org;
Ville Syrj?l?; Thierry
On Tue, Apr 22, 2014 at 4:07 AM, Ilia Mirkin wrote:
> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot
> wrote:
>> Skip the creation of a software channel for GK20A as software methods
>> are not yet supported.
>
> How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all
> the
> -Original Message-
> From: Christian K?nig [mailto:deathsimple at vodafone.de]
> Sent: Tuesday, April 22, 2014 5:17 AM
> To: Alex Deucher; dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH] drm/radeon/aux: fix hpd assignment for aux bus
>
> Am 22.04.2014
On Thu, Apr 17, 2014 at 12:02:07AM +0200, Laurent Pinchart wrote:
> And another comment...
>
> On Friday 11 April 2014 23:36:07 Daniel Vetter wrote:
> > To get rid of the dev->bus->get_irq callback we need to pass in the
> > desired irq explicitly into drm_irq_install. To avoid having to do the
>
On Monday 21 April 2014 17:26:15 Ed Tomlinson wrote:
> On Monday 21 April 2014 15:08:24 Ed Tomlinson wrote:
> > On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote:
> > > On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote:
> > > > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote:
> > > >
Hi
On Tue, Apr 22, 2014 at 6:11 AM, Sharma, Shashank
wrote:
> Gentle reminder
Usual approach is to send any proposals as inline plain-text. It's
really hard to comment on attachments, especially if it's an MS-office
format. Anyhow, some comments on the proposal:
1) Why do you register only a
On 04/22/2014 03:07 AM, Ilia Mirkin wrote:
> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot
> wrote:
>> Skip the creation of a software channel for GK20A as software methods
>> are not yet supported.
>
> How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all
> the 3D
doesn't have to know that kind of detail.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/cd96a7aa/attachment.sig>
From: Rob Clark
Signed-off-by: Rob Clark
---
Note: I move the position of the getchar() at the end, so we don't
stop the cursor test immediately if not testing w/ vblank sync
flipping. The previous position of the getchar() seemed to make
no sense, but please let me
Am 22.04.2014 08:02, schrieb Alex Deucher:
> The hpd (hot plug detect) pin assignment got lost
> in the conversion to to the common i2c over aux
> code. Without this information, aux transactions
> do not work properly. Fixes DP failures.
>
> Signed-off-by: Alex Deucher
Added to my 3.15 queue.
d-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/bbdd43b3/attachment.sig>
On 04/09/2014 11:31 PM, David Herrmann wrote:
> On Tue, Apr 8, 2014 at 3:00 PM, Florian Weimer wrote:
>> How do you keep these promises on network and FUSE file systems?
>
> I don't. This is shmem only.
Ah. What do you recommend for recipient to recognize such descriptors?
Would they just
On 04/22/2014 08:48 AM, Ben Skeggs wrote:
> On Tue, Apr 22, 2014 at 4:03 AM, Ilia Mirkin wrote:
>> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot
>> wrote:
>>> Pad the microcode to a multiple of 0x40 bytes, otherwise firmware will
>>
>> bytes or u32's? From the code, I'm guessing the
The introduction of primary planes has apparently caused a bit of fb
refcounting fun for people. That makes it a good time to clean up the
arcane rules and slight differences between ->update_plane and
->set_config. The new rules are:
- The core holds a reference for both the new and the old fb
rudimentary initialization.
>
> Hm yeah I think this should be sufficient, too. It would be good to
> extract this minimal initialization into a new drm_fb_helper_prepare
> function and update the kerneldoc a bit more. Maybe as a patch on top of
> mine?
>
> Then we could merge this all as an early tegra-next pull to Dave.
Sounds like a good idea. I'll go prepare a patch.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/29d75edf/attachment.sig>
1 - 100 of 146 matches
Mail list logo