On 2 June 2014 02:38, Matthew Garrett wrote:
> From: Seth Forshee
>
> During graphics driver initialization its useful to be able to mux only
> the DDC to the inactive client in order to read the EDID. Add a
> switch_ddc callback to allow capable handlers to provide this
> functionality, and add
Hi Linus,
This is the main drm merge window pull request, changes all over the place,
mostly normal levels of churn.
Highlights:
drm:
more cleanups, fix race on connector/encoder naming, docs updates, object
locking rework in prep for atomic modeset
i915:
mipi DSI support, valleyview power
ht also need to
specify radeon.gartsize=1024 or larger on the kernel command line.
--
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/attachment
raw anything anymore. Would
that really be an improvement?
--
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/20140612/c516bdef/attachment.html>
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140612/ccd38425/attachment.html>
rry
-- 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/20140612/68bd7c46/attachment.sig>
lled, check which
of its conditions are not met.
--
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/20140612/49320ee5/attachment.html>
The code assume that this array has 32 elements but because of a missing
comma, then it only has 31. This array is only used when error occurs
and debugging is enabled so it's not very serious.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
b/drivers/gp
ven that -ENOENT is used *a lot* in DRM (many, if not most, of the
instances returning the error from an IOCTL), I wonder how this can be
resolved. Given that userspace may rely on this error code and that we
can't break userspace I don't see a way out.
Thierry
[0]: https://lkml.org/lkml/2012/12/23/75
-- 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/20140612/94537cec/attachment-0001.sig>
On Thu, Jun 12, 2014 at 09:18:40AM +0200, Thierry Reding wrote:
> On Wed, Jun 11, 2014 at 09:21:21AM -0700, St?phane Marchesin wrote:
> > On Tue, Jun 10, 2014 at 4:04 AM, Thierry Reding
> > wrote:
> > > From: Thierry Reding
> > >
> > > The DRM_TEGRA_GEM_SET_FLAGS IOCTL can be used to set the flag
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140612/7d1f5a39/attachment.html>
libgcc_s.so.
--
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/20140612/38fe3877/attachment.html>
nly thing we'd
> ever be able to return is -EINVAL for ioctls, which is completely
> pointless.
I disagree. -EINVAL makes perfect sense because one of the arguments
passed into the IOCTL (the handle) is invalid.
> So my approach is to throw the vfs experts opinion into the win
Please do so, and you might want to try 3.15.0 as well.
I've tested multiple piglit runs over night with my Bonaire and 3.15.0
and that seemed to work perfectly fine.
Going to test Alex drm-next-3.16 a bit more as well.
Christian.
Am 11.06.2014 12:56, schrieb Marek Ol??k:
> I only tested Bonai
ccessful.
--
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/20140612/aff4b0e3/attachment-0001.html>
This driver defines its own irqchip using the generic chip
infrastructure, and hence needs the GENERIC_IRQ_CHIP Kconfig
symbol enabled, or get this build error:
drivers/built-in.o: In function `ipu_probe':
:(.text+0x49ea4c): undefined reference to `irq_generic_chip_ops'
:(.text+0x49ea5c): undefine
On Thu, Jun 12, 2014 at 04:05:32PM +0200, Arnd Bergmann wrote:
> This driver defines its own irqchip using the generic chip
> infrastructure, and hence needs the GENERIC_IRQ_CHIP Kconfig
> symbol enabled, or get this build error:
>
> drivers/built-in.o: In function `ipu_probe':
> :(.text+0x49ea4c)
On Thursday 12 June 2014 15:23:54 Russell King - ARM Linux wrote:
> On Thu, Jun 12, 2014 at 04:05:32PM +0200, Arnd Bergmann wrote:
> > This driver defines its own irqchip using the generic chip
> > infrastructure, and hence needs the GENERIC_IRQ_CHIP Kconfig
> > symbol enabled, or get this build er
On Thu, Jun 12, 2014 at 04:51:26PM +0200, Arnd Bergmann wrote:
> On Thursday 12 June 2014 15:23:54 Russell King - ARM Linux wrote:
> > On Thu, Jun 12, 2014 at 04:05:32PM +0200, Arnd Bergmann wrote:
> > > This driver defines its own irqchip using the generic chip
> > > infrastructure, and hence need
On Thursday 12 June 2014 16:04:19 Russell King - ARM Linux wrote:
> On Thu, Jun 12, 2014 at 04:51:26PM +0200, Arnd Bergmann wrote:
> > On Thursday 12 June 2014 15:23:54 Russell King - ARM Linux wrote:
> > > On Thu, Jun 12, 2014 at 04:05:32PM +0200, Arnd Bergmann wrote:
> > > > This driver defines i
The VGA arbiter does not allow devices to "own" resources that it
doesn't "decode". However, it does allow devices to "lock" resources
that it doesn't decode. This gets us into trouble because locking
the resource goes through the same bridge routing updates regardless
of whether we decode the re
On Thursday 12 June 2014 16:50:15 Russell King wrote:
> DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on
> DRM_PANEL && DRM. This is nonsense for two reasons:
>
> (a) DRM_PANEL already depends on DRM, so DRM_PANEL can not be enabled
> without DRM first being enabled. Hence the
On Thursday 12 June 2014 16:50:20 Russell King wrote:
> Rather than DRM_PANEL_LD9040 selecting SPI, which then results in an
> increase in the probability of Kconf reporting circular dependencies
> (we're one "select" away from that right now), make this depend on
> SPI instead. This is akin to ha
On Thu, Jun 12, 2014 at 06:00:07PM +0200, Arnd Bergmann wrote:
> On Thursday 12 June 2014 16:50:15 Russell King wrote:
> > DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on
> > DRM_PANEL && DRM. This is nonsense for two reasons:
> >
> > (a) DRM_PANEL already depends on DRM, so DR
On Thursday 12 June 2014 17:04:34 Russell King - ARM Linux wrote:
>
> In which case, that's a bug for DRM_PANEL_SIMPLE which uses the same
> mechanism. Since everything is going to be in the same boat, the
> menu should depend on DRM && DRM_PANEL.
>
Right, I actually have a patch for DRM_PANEL_
cted? :)
--
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/20140612/fbedac9b/attachment.html>
On Wed, Jun 11, 2014 at 5:58 PM, Dave Airlie wrote:
>
> This is the main drm merge window pull request, changes all over the place,
> mostly normal levels of churn.
Hmm.
I just had the machine reboot on me when booting this and starting X,
leaving nothing in the logs.
This is on a bog-standard
On Thu, Jun 12, 2014 at 12:06 PM, Linus Torvalds
wrote:
>
> I just had the machine reboot on me when booting this and starting X,
> leaving nothing in the logs.
Ok, I can't recreate it, and as such I can't be sure that it was even
the drm merge that causes it (although the timing was suspicious).
https://bugzilla.kernel.org/show_bug.cgi?id=74911
Ivan Bulatovic changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=77751
Bug ID: 77751
Summary: radeon: unable to set temperature warning levels
Product: Drivers
Version: 2.5
Kernel Version: 3.15
Hardware: All
OS: Linux
Tree: Mainli
On 06/11/2014 04:24 PM, Borislav Petkov wrote:
> On Wed, Jun 11, 2014 at 03:53:55PM +0800, Lai Jiangshan wrote:
>> When I tried to review the linux kernel on Windows in my laptop
>> and incidentally found that it failed to open the aux.c.
>>
>> And Microsoft tells me:
>> (http://msdn.microsoft.com/
On 06/11/2014 04:24 PM, Borislav Petkov wrote:
> On Wed, Jun 11, 2014 at 03:53:55PM +0800, Lai Jiangshan wrote:
>> When I tried to review the linux kernel on Windows in my laptop
>> and incidentally found that it failed to open the aux.c.
>>
>> And Microsoft tells me:
>> (http://msdn.microsoft.com/
Ping?
On Fri, Apr 11, Olaf Hering wrote:
> qemu as used by xend/xm toolstack uses a different subvendor id.
> Bind the drm driver also to this emulated card.
>
> Signed-off-by: Olaf Hering
> ---
> drivers/gpu/drm/cirrus/cirrus_drv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/d
On Mon, Jun 9, 2014 at 7:41 PM, Alexandre Courbot wrote:
> On Mon, May 19, 2014 at 6:22 PM, Lucas Stach
> wrote:
>> Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding:
>>> On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote:
>>> > Some architectures (e.g. ARM) need the C
This panel is used by the Medcom Wide and supported by the
simple-panel driver.
Signed-off-by: Alban Bedel
---
drivers/gpu/drm/panel/panel-simple.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-s
Rather than DRM_PANEL_LD9040 selecting SPI, which then results in an
increase in the probability of Kconf reporting circular dependencies
(we're one "select" away from that right now), make this depend on
SPI instead. This is akin to having some driver select DRM.
Having some drivers depend on a
Rather than DRM_PANEL_LD9040 selecting SPI, which then results in an
increase in the probability of Kconf reporting circular dependencies
(we're one "select" away from that right now), make this depend on
SPI instead. This is akin to having some driver select DRM.
Having some drivers depend on a
DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on
DRM_PANEL && DRM. This is nonsense for two reasons:
(a) DRM_PANEL already depends on DRM, so DRM_PANEL can not be enabled
without DRM first being enabled. Hence the && DRM is useless.
(b) These two configs are already beneath a
DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on
DRM_PANEL && DRM. This is nonsense for two reasons:
(a) DRM_PANEL already depends on DRM, so DRM_PANEL can not be enabled
without DRM first being enabled. Hence the && DRM is useless.
(b) These two configs are already beneath a
39 matches
Mail list logo
