On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
> Adding proper people and mailing lists..
>
> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> appropriate, but hopefully somebody does. The fact that it makes
On Tue, Sep 23, 2014 at 11:46 PM, Daniel Vetter
wrote:
> Really, the legacy buffer api should be dead, especially for all these
> newfangled drivers. I suspect this is copypasta from the transitioning
> days, which probably originated in radeon.
>
> Cc: David Airlie
> Cc: Alex Deucher
> Cc: "Ch
https://bugzilla.kernel.org/show_bug.cgi?id=83861
Yomi changed:
What|Removed |Added
CC||abyomi0 at gmail.com
--- Comment #2 from Yomi ---
https://bugzilla.kernel.org/show_bug.cgi?id=85021
Alexandre Demers changed:
What|Removed |Added
CC||alexandre.f.demers at gmail.co
https://bugzilla.kernel.org/show_bug.cgi?id=85021
--- Comment #4 from Alexandre Demers ---
Created attachment 151651
--> https://bugzilla.kernel.org/attachment.cgi?id=151651&action=edit
Script showing some information on the gpu
you will have to run this script using "sudo" or somthing similar
eceiving 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/20140924/90c4218a/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=85021
--- Comment #5 from higuita ---
The gpu is one old ATI HD2600XP AGP:
01:00.0 VGA compatible controller: AMD/ATI [Advanced Micro Devices, Inc.] RV630
XT [Radeon HD 2600 XT AGP]
I usually use this command to see what level the gpu is:
cat /sys/ke
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/a40411d1/attachment.html>
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/20140924/2ad82f11/attachment.html>
This patch resolves a issue that screen is shaked after resumed.
The issue could be incurred when overlay registers are updated to
new buffer while fimd is still transmitting video data.
So this patch make sure to wait for the completion of the transmission
if fimd is transmitting video data befo
https://bugzilla.kernel.org/show_bug.cgi?id=85021
--- Comment #6 from Alex Deucher ---
(In reply to higuita from comment #2)
> Auto will jump from level 0 to level 2, i never see level 1 being used in
> any place/app other than a maximized glxgears.
>
> tvtime or chrome+youtube+thml5 will jump t
From: Dave Airlie
This is step one towards allocating these on demand for legacy devices.
First group all the legacy struct members into their own structure and include
it into the main drm driver structure directly.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ati_pcigart.c | 4 +
On 09/23/2014 04:41 PM, Thierry Reding wrote:
> On Tue, Sep 23, 2014 at 12:34:54PM +0200, Andrzej Hajda wrote:
>> On 09/23/2014 12:10 PM, Thierry Reding wrote:
>>> On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote:
On 09/23/2014 10:35 AM, Thierry Reding wrote:
>>> [...]
> But I
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/ab8bb18d/attachment.html>
On Tue, 23 Sep 2014, Stefan Br?ns wrote:
> see df8fbc231b7e4a78dae2b02e116fe73e4ea63cb0
Andy beat you to it with
commit a8e98153627dfbb10ff4dd65729676115a932b2e
Author: Andy Shevchenko
Date: Mon Sep 1 14:12:01 2014 +0300
drm: i915: reduce memory footprint when debugging
on its way upstr
On Tue, Sep 23, 2014 at 08:04:07PM +0200, Stefan Br?ns wrote:
> see df8fbc231b7e4a78dae2b02e116fe73e4ea63cb0
>
> Signed-off-by: Stefan Br?ns
I already have such a patch:
commit a8e98153627dfbb10ff4dd65729676115a932b2e
Author: Andy Shevchenko
Date: Mon Sep 1 14:12:01 2014 +0300
drm: i915
The NXP TDA998x HDMI transmitter may transmit audio to the HDMI link
from 2 different sources, I2S and S/PDIF.
This patch set adds an interface between the HDMI transmitter and
the HDMI CODEC.
The interface is used by the TDA998x driver to update the audio
constraints from the display characteris
The audio constraints of the HDMI interface are defined by the EDID
which is sent by the connected device.
The HDMI transmitters may have one or many audio sources.
This patch adds two functions to the HDMI CODEC:
- it updates the audio constraints from the EDID,
- it gives the audio source type
This patch interfaces the HDMI transmitter with the audio system.
Signed-off-by: Jean-Francois Moine
---
.../devicetree/bindings/drm/i2c/tda998x.txt| 18 ++
drivers/gpu/drm/i2c/Kconfig| 1 +
drivers/gpu/drm/i2c/tda998x_drv.c | 299 +
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/20140924/4e186695/attachment.html>
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/20140924/a77d4694/attachment-0001.html>
Hi Dave,
Just noticed that you've picked up the header rework stuff already, so
I've rebased that out again. Otherwise just two stragglers from the vblank
rework and the universal cursor planes locking fix. Plus sprinkling
container_of all over fbdev emulation from Fabian.
Aside: I only have just
In psb_mmu_insert_pfn_sequence() we set the error code but don't use it
and the caller doesn't check for error either. I have changed it to
return an error and to check.
In psb_driver_load() there are a couple paths where we don't set an
error code on allocation failure. I've made those return -
https://bugzilla.kernel.org/show_bug.cgi?id=83861
--- Comment #3 from Yomi ---
Created attachment 151751
--> https://bugzilla.kernel.org/attachment.cgi?id=151751&action=edit
dmesg
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=83861
--- Comment #4 from Yomi ---
Created attachment 151761
--> https://bugzilla.kernel.org/attachment.cgi?id=151761&action=edit
Xorg.log
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=83861
--- Comment #5 from Francesco ---
please,. we need an answer if is possible, a solution!5 months with this bug ,
the bug is present on kernel 3.16 and on 3.17, we neeed a solutioN :'(
--
You are receiving this mail because:
You are watching the
. #if 1 ...#endif is changed
code. is the same as 1. Must do cpu_to_le32 transfer
By the way, u said writel() and readl() already convert to/from little
endian.
is based on the X86 arch implement?
--
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/20140924/ca81f200/attachment.html>
Hi,
On 09/24/2014 11:14 AM, Pali Roh?r wrote:
> On Wednesday 24 September 2014 10:59:41 Pali Roh?r wrote:
>> On Wednesday 24 September 2014 10:19:38 Hans de Goede wrote:
>>> Hi,
>>>
>>> On 09/23/2014 10:44 PM, Pali Roh?r wrote:
On Tuesday 23 September 2014 22:31:31 you wrote:
> Hi,
>
Clear omap_obj's paddr when unmapping the memory, so that it's easier to
catch bad use of the paddr.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
i
omap_framebuffer_pin() and omap_framebuffer_unpin() are currently
broken, as they cannot be called multiple times (i.e. pin, pin, unpin,
unpin), which is what happens in certain cases. This issue causes the
driver to possibly use 0 as an address for a displayed buffer, leading
to OCP error from DSS
Ping :)
Thanks,
BRs
Xiubo
> -Original Message-
> From: Xiubo Li [mailto:Li.Xiubo at freescale.com]
> Sent: Tuesday, August 12, 2014 11:30 AM
> To: airlied at linux.ie; dri-devel at lists.freedesktop.org
> Cc: Xiubo Li-B47053
> Subject: [PATCH 0/3] drm: Fix possible ZERO_SIZE_PTR pointe
Hi,
This is a modified version of the series I sent earlier
(http://comments.gmane.org/gmane.comp.video.dri.devel/113812). I haven't had
time to work on the locking issues, so I've dropped the patches related to that
so that the rest could get merged.
I have also added three new small patches (th
omapdrm should work fine even if fbdev is missing. The current driver
crashes in that case, though, as it is missing checks for the fbdev.
Add the checks so that we don't free fbdev or restore fbdev mode when
there's no fbdev.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c
This adds binding documentation for Rockchip SoC VOP driver.
Signed-off-by: Mark Yao
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem
Changes in v3: None
Changes in v4: None
Changes in v5: None
.../devicetree/bindings/video/rockchi
This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices. Future patches will add additional encoders/connectors,
such as eDP, HDMI.
The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two s
This patch adds the basic structure of a DRM Driver for Rockchip Socs.
Signed-off-by: Mark yao
---
Changes in v2:
- use the component framework to defer main drm driver probe
until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
master dev
This add a display subsystem comprise the all display interface nodes.
Signed-off-by: Mark Yao
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
the graphics subsystem.
Changes in v3: None
Changes in v4: None
Changes in v5: None
.../devicetree/bindings
doesn't care if the next entity has a backlight or not.
I don't know if we need a different representation for bridges and
panels. Thinking about backlight, the driver can just register the
backlight device if it needs one. There's no need to differentiate
bridges and panels for that. But maybe there are other reasons that
warrant different representations.
However, my current feeling is that there's no need for different
representations.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/0c858afa/attachment-0001.sig>
d...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/a9f85d9c/attachment-0001.sig>
gt; dell- laptop support (distributions compile kernel with
> >>>> these drivers) and i915 is not good for usage. First it
> >>>> provides more then thousand brightness levels and lot of
> >>>> (with low numbers) completely turn display off. And if
> >>>> userspace map these thousand levels into 5-10 levels (as
> >>>> nobody want to press brightness key up/down 1000x) two
> >>>> lowest levels cause display off.
> >>>
> >>> More and more laptops will only have working backlight
> >>> control at all when using i915, so userspace will need to
> >>> learn to better deal with backlight controls with these
> >>> ranges. And low pwm levels turning the backlight of is
> >>> normal for raw interfaces, if userspace does not want
> >>> this, then they should not go so low.
> >>
> >> So then kernel should report which low levels turn
> >> backlight off so userspace will know which levels should
> >> avoid. But this is not implemented yet.
> >>
> >>> I suggest that you file a bug against your desktop
> >>> environment that it is not using the backlight controls in
> >>> an optimal manner, from the kernel pov everything is
> >>> working fine.
> >>
> >> Once I will know which levels should not DE use I can
> >> report bug.
> >>
> >>>> With acpi
> >>>> video and dell-laptop driver levels are mapped into small
> >>>> level space in perfect way. So this is reason I want to
> >>>> use dell-laptop for controlling brightness.
> >>>
> >>> If you want to use dell-laptop, specify
> >>> acpi_backlight=vendor on the kernel commandline, that will
> >>> give you dell_laptop + intel_backlight as backlight
> >>> interfaces, and userspace should prefer dell_laptop.
> >>
> >> With acpi_backlight=vendor dell-laptop is not working, see
> >> my previous mail. In this case intel i915 drm driver
> >> ignore bios events for changing brightness. And userspace
> >> prefer to use dell_laptop which do nothing!
> >
> > Ok, that problematic commit is:
> >
> > ACPI / i915: ignore firmware requests for backlight change
> > 0b9f7d93ca6109048a4eb06332b666b6e29df4fe
> >
> > When I reverted it acpi_backlight=vendor started working
> > again (via dell_laptop). Without reverting that commit
> > dell_laptop simply do nothing.
> >
> > Tested and on my laptop Dell Latitude E6440 driver
> > dell_laptop does not work with above commit.
>
> Hmm, interesting, so when dell-laptop registers and makes a
> few calls using the dell-laptop acpi interface,
No, dell-laptop is *not* acpi driver. See my first mail. It uses
dell dcdbas driver which makes SMI calls for SMBIOS. But it (on
my machine! no idea about other older once) just forward
brightness change to intel driver. And it has useful brightness
levels (no lot of levels which turning display off).
And making SMI calls can be done also from userspace. There is
tool dellLcdBrightness in libsmbios package which for brightness.
And commit 0b9f7d93ca6109048a4eb06332b666b6e29df4fe broke
functionality of that tool.
> then you either stop getting key press events through the
> acpi-video-bus, or dell-laptop is just a shim around the i915
> interface with the firmware calling into itself on these
> models. Given that dell-laptop is ancient, the shim story is
> not that far fetched.
>
Brightness Fn keys are reported by WMI (dell-wmi driver), so they
working without dell-laptop and acpi video drivers perfectly.
> Do you still get an on screen display showing the brightness
> when using a kernel without this patch +
> acpi_backlight=vendor ?
>
Brightness Fn keys are reported to userspace (from WMI input
device) with any combination of video.use_native_backlight and
acpi_backlight kernel params.
> Regards,
>
> Hans
--
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/a1cc358f/attachment-0001.sig>
OMAP DSS hardware supports changing the output port to which an overlay
manager's video stream goes. For example, DPI video stream can come from
any of the four overlay managers on OMAP5.
However, as it's difficult to manage the change in the driver, the
omapdss driver does not support that at the
unpin_worker() calls omap_framebuffer_unpin() without any locks, which
looks very suspicious. However, both pin and unpin are always called via
the driver's private workqueue, so the access is synchronized that way.
Add a comment to make this clear.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu
When an error happens in omap_framebuffer_create(),
omap_framebuffer_create() calls omap_framebuffer_destroy() if the fb
struct has been allocated. However, that crashes, as
omap_framebuffer_destroy(), which calls drm_framebuffer_cleanup(),
should only be called after drm_framebuffer_init()
Fix th
omapdrm doesn't check if the width of the framebuffer and the color
format's bits-per-pixel match.
For example, using a display with a width of 1280, and a buffer
allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with
a 24 bits per pixel color format, leads to the following mismat
Hi,
On 09/23/2014 10:44 PM, Pali Roh?r wrote:
> On Tuesday 23 September 2014 22:31:31 you wrote:
>> Hi,
>>
>> On 09/23/2014 10:06 PM, Pali Roh?r wrote:
>>> Hello,
>>>
>>> after big changes in acpi video/i915 code I cannot change
>>> display brightness on my Dell Latitude E6440 with kernel
>>> 3.17
On Mon, Sep 22, 2014 at 06:48:54PM +0800, Mark yao wrote:
> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>
> Signed-off-by: Mark yao
> ---
> Changes in v2:
> - use the component framework to defer main drm driver probe
> until all VOP devices have been probed.
> - use
a list of input-configs. When panel1 is to
be enabled, "bridge1234-cfg1" config becomes active, and the bridge is
given this configuration.
I have to say the endpoint system feels cleaner than the above, but
perhaps it's possible to improve the method above somehow.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/3ae43015/attachment.sig>
to 5-10 levels (as
> > nobody want to press brightness key up/down 1000x) two
> > lowest levels cause display off.
>
> More and more laptops will only have working backlight control
> at all when using i915, so userspace will need to learn to
> better deal with backlight controls with these ranges. And
> low pwm levels turning the backlight of is normal for raw
> interfaces, if userspace does not want this, then they should
> not go so low.
>
So then kernel should report which low levels turn backlight off
so userspace will know which levels should avoid. But this is not
implemented yet.
> I suggest that you file a bug against your desktop environment
> that it is not using the backlight controls in an optimal
> manner, from the kernel pov everything is working fine.
>
Once I will know which levels should not DE use I can report bug.
> > With acpi
> > video and dell-laptop driver levels are mapped into small
> > level space in perfect way. So this is reason I want to use
> > dell-laptop for controlling brightness.
>
> If you want to use dell-laptop, specify acpi_backlight=vendor
> on the kernel commandline, that will give you dell_laptop +
> intel_backlight as backlight interfaces, and userspace should
> prefer dell_laptop.
With acpi_backlight=vendor dell-laptop is not working, see my
previous mail. In this case intel i915 drm driver ignore bios
events for changing brightness. And userspace prefer to use
dell_laptop which do nothing!
> But IMHO it would be better to file a bug
> with your desktop environment, and get that fixed to work
> properly with intel_backlight (or with raw backlight
> interfaces in general).
>
> Regards,
>
> Hans
>
> >> Regards,
> >>
> >> Hans
--
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/3f3e68c1/attachment-0001.sig>
And if
> > > userspace map these thousand levels into 5-10 levels (as
> > > nobody want to press brightness key up/down 1000x) two
> > > lowest levels cause display off.
> >
> > More and more laptops will only have working backlight
> > control at all when using i915, so userspace will need to
> > learn to better deal with backlight controls with these
> > ranges. And low pwm levels turning the backlight of is
> > normal for raw interfaces, if userspace does not want this,
> > then they should not go so low.
>
> So then kernel should report which low levels turn backlight
> off so userspace will know which levels should avoid. But
> this is not implemented yet.
>
> > I suggest that you file a bug against your desktop
> > environment that it is not using the backlight controls in
> > an optimal manner, from the kernel pov everything is
> > working fine.
>
> Once I will know which levels should not DE use I can report
> bug.
>
> > > With acpi
> > > video and dell-laptop driver levels are mapped into small
> > > level space in perfect way. So this is reason I want to
> > > use dell-laptop for controlling brightness.
> >
> > If you want to use dell-laptop, specify
> > acpi_backlight=vendor on the kernel commandline, that will
> > give you dell_laptop + intel_backlight as backlight
> > interfaces, and userspace should prefer dell_laptop.
>
> With acpi_backlight=vendor dell-laptop is not working, see my
> previous mail. In this case intel i915 drm driver ignore bios
> events for changing brightness. And userspace prefer to use
> dell_laptop which do nothing!
>
Ok, that problematic commit is:
ACPI / i915: ignore firmware requests for backlight change
0b9f7d93ca6109048a4eb06332b666b6e29df4fe
When I reverted it acpi_backlight=vendor started working again
(via dell_laptop). Without reverting that commit dell_laptop
simply do nothing.
Tested and on my laptop Dell Latitude E6440 driver dell_laptop
does not work with above commit.
> > But IMHO it would be better to file a bug
> > with your desktop environment, and get that fixed to work
> > properly with intel_backlight (or with raw backlight
> > interfaces in general).
> >
> > Regards,
> >
> > Hans
> >
> > >> Regards,
> > >>
> > >> Hans
--
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/dd8208f7/attachment-0001.sig>
On 2014?09?24? 16:20, Daniel Vetter wrote:
> On Mon, Sep 22, 2014 at 06:48:54PM +0800, Mark yao wrote:
>> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>>
>> Signed-off-by: Mark yao
>> ---
>> Changes in v2:
>> - use the component framework to defer main drm driver probe
>>
On 2014/9/24 7:35, Rob Clark wrote:
> On Tue, Sep 23, 2014 at 9:56 AM, Rob Clark wrote:
>> On Tue, Sep 23, 2014 at 4:47 AM, cym wrote:
>>> On Tuesday, September 23, 2014 03:20 AM, Rob Clark wrote:
On Mon, Sep 22, 2014 at 7:02 AM, Mark yao
wrote:
> This adds support for Rockchip s
On Wed, Sep 24, 2014 at 11:31 AM, Mark yao wrote:
> On 2014?09?24? 16:20, Daniel Vetter wrote:
>>
>> On Mon, Sep 22, 2014 at 06:48:54PM +0800, Mark yao wrote:
>>>
>>> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>>>
>>> Signed-off-by: Mark yao
>>> ---
>>> Changes in v2:
The DRM documentation says:
"If a page flip is already pending, the page_flip operation must return
-EBUSY."
Currently omapdrm returns -EINVAL instead. Fix omapdrm by returning
-EBUSY.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +-
1 file changed, 1 insertion(+),
omap_crtc's apply_worker does:
omap_irq_register(dev, &omap_crtc->apply_irq);
dispc_mgr_go(channel);
This is supposed to enable the vsync irq, and set the GO bit. The vsync
handler will later check if the HW has cleared the GO bit and queue
apply work.
However, what may happen is
On OMAP5 it is not possible to use TILER buffer with CPU when caching or
write-combining is used. Doing so leads to errors from the memory
manager.
However, on OMAP4, write-combining works fine.
This patch adds platform specific data for the TILER, and a function
tiler_get_cpu_cache_flags() which
Hi,
On 09/24/2014 02:53 PM, Pali Roh?r wrote:
> On Wednesday 24 September 2014 14:04:36 Hans de Goede wrote:
>> Hi,
>>
>> On 09/24/2014 11:14 AM, Pali Roh?r wrote:
>>> On Wednesday 24 September 2014 10:59:41 Pali Roh?r wrote:
On Wednesday 24 September 2014 10:19:38 Hans de Goede wrote:
>
Hello Christian K?nig,
This is a semi-automatic email about new static checker warnings.
The patch 3840a656f61f: "drm/radeon: fix AGP userptr handling" from
Sep 17, 2014, leads to the following Smatch complaint:
drivers/gpu/drm/radeon/radeon_ttm.c:708 radeon_ttm_tt_populate()
error: we
On Wed, Sep 24, 2014 at 6:24 AM, Daniel Vetter
wrote:
> Hi Dave,
>
> Just noticed that you've picked up the header rework stuff already, so
> I've rebased that out again. Otherwise just two stragglers from the vblank
> rework and the universal cursor planes locking fix. Plus sprinkling
> containe
Hi Dave, a couple of small fixes for 3.17 still.
BR,
Jani.
The following changes since commit 0f33be009b89d2268e94194dc4fd01a7851b6d51:
Linux 3.17-rc6 (2014-09-21 15:43:02 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-09-
This patch series adds a simple macro pm_runtime_last_busy_and_autosuspend()
which invokes pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend()
sequentially. Then we do a tree wide update of current patterns which are
present. As evident from log below this pattern is frequent in the
kernel
Use the new pm_runtime_last_busy_and_autosuspend helper instead of open
coding the same code
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/i915/intel_pm.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
Use the new pm_runtime_last_busy_and_autosuspend helper instead of open
coding the same code
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/nouveau/nouveau_connector.c |3 +--
drivers/gpu/drm/nouveau/nouveau_drm.c |9 +++--
2 files changed, 4 insertions(+), 8 deletions(-)
diff
Use the new pm_runtime_last_busy_and_autosuspend helper instead of open
coding the same code
Signed-off-by: Vinod Koul
---
drivers/gpu/vga/vga_switcheroo.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switch
Use the new pm_runtime_last_busy_and_autosuspend helper instead of open
coding the same code
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/radeon/radeon_connectors.c | 15 +--
drivers/gpu/drm/radeon/radeon_drv.c|5 ++---
drivers/gpu/drm/radeon/radeon_kms.c|6
ves/dri-devel/attachments/20140924/ceee0f03/attachment.html>
From: Gustavo Padovan
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to the
check() stage)
v2: take Vi
From: Gustavo Padovan
Now that universal planes are in place we don't need this plane unref on
failures.
Suggested-by: Ville Syrj?l?
Signed-off-by: Gustavo Padovan
Reviewed-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 12 +---
1 file changed, 1 insertion(+), 11 deleti
From: Gustavo Padovan
Even if the fb is the same we should still check if the sizes are
valid to be set.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 61
1 file changed, 41 insertions(+), 20 deletions(-)
diff --git a/drivers/gp
From: Gustavo Padovan
Move check inside intel_crtc_cursor_set_obj() to
intel_check_cursor_plane(), we only use it there so move them out to
make the merge of intel_crtc_cursor_set_obj() into
intel_check_cursor_plane() easier.
This is another step toward the atomic modesetting support and unifica
From: Gustavo Padovan
Merge it into the plane update_plane() callback and make other
users use the update_plane() functions instead.
The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
and merge both
From: Daniel Stone
Start the work of splitting the intel_crtc_page_flip() for later use
by the atomic modesetting API.
Signed-off-by: Daniel Stone
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 51 ++--
1 file changed, 37 insertions(+
From: Gustavo Padovan
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
Suggested-by: Ville Syrj?l?
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_crtc.c | 20 +---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
From: Gustavo Padovan
Take out the pin_fb code so commit phase can't fail anymore.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display
From: Gustavo Padovan
take out pin_fb code so the commit phase can't fail anymore.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_sprite.c | 63 +++--
1 file changed, 40 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprit
From: Gustavo Padovan
Use the macros makes the code cleaner and it also checks for a NULL fb.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_sprite.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/dr
From: Gustavo Padovan
After some refactor intel_primary_plane_setplane() does the same
as intel_pipe_set_base() so we can get rid of it and replace the calls
with intel_primary_plane_setplane().
v2: take Ville's comments:
- get the right arguments for update_plane()
- use drm_crt
On Wed, Sep 24, 2014 at 6:24 PM, Ilia Mirkin wrote:
> On Wed, Sep 24, 2014 at 6:24 AM, Daniel Vetter
> wrote:
>> Hi Dave,
>>
>> Just noticed that you've picked up the header rework stuff already, so
>> I've rebased that out again. Otherwise just two stragglers from the vblank
>> rework and the u
lists.freedesktop.org/archives/dri-devel/attachments/20140924/5ff5a664/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/a83e92c0/attachment.html>
vel/attachments/20140924/7e26bb88/attachment.html>
On Wed, Sep 24, 2014 at 09:44:54PM +0530, Vinod Koul wrote:
> Use the new pm_runtime_last_busy_and_autosuspend helper instead of open
> coding the same code
>
> Signed-off-by: Vinod Koul
Ack to merge through whatever tree is appropriate for this. Or tell me
when I should pick this up for drm-int
|5 with Radeon HD 5xxx |with Radeon HD 5xxx
--
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/20140924/e8238
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/20140924/cba9b1b4/attachment.html>
On Wed, Sep 24, 2014 at 12:24:53PM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> Just noticed that you've picked up the header rework stuff already, so
> I've rebased that out again. Otherwise just two stragglers from the vblank
> rework and the universal cursor planes locking fix. Plus sprinkling
>
Paulo Zanoni reported a lockdep splat with a locking inversion between
fpriv->fbs_lock and the modeset locks. This issue was introduced in
commit f2b50c1161590c3bcdbf3455fe4c575f1c1bd293
Author: Daniel Vetter
Date: Fri Sep 12 17:07:32 2014 +0200
drm: Fixup locking for universal cursor plan
From: Philipp Zabel
Decrementing the reference count of the previous endpoint node allows to
use the of_graph_get_next_endpoint function in a for_each_... style macro.
Prior to this patch, all current users of this function that actually pass
a non-NULL prev parameter should be changed to not dec
Hello,
This patch set adds support for the HDMI output port present on the Renesas
Koelsch board. Doing so requires two components, a driver for the external
ADV7511W HDMI encoder, and support for HDMI encoders in the DU driver.
The HDMI encoder drivers uses the DRM slave encoder framework and th
From: Philipp Zabel
Note that while of_graph_get_next_endpoint decrements the reference count
of the child node passed to it, of_node_put(child) still has to be called
manually when breaking out of the loop.
Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
---
include/linux/of_graph.h
All platforms now instantiate the DU through DT, platform data support
isn't needed anymore.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 10 -
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 -
drivers/gpu/
Add a new macro to downcast an rcar_du_encoder pointer to a drm_encoder
pointer and use it. This prepares for the replacement of the
rcar_drm_encoder encoder field with a drm_slave_encoder.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 8 +---
drivers/gpu/dr
DRM slave encoders require their associated struct drm_encoder instance
to be embedded in a struct drm_slave_encoder. This makes processing
encoders regardless of their types needlessly and painfully complex in
drivers that use a mix of slave encoders and custom encoders. Such a
driver will need to
SoCs that integrate the DU have no internal HDMI encoder, support
external encoders only.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 11 ++-
drivers/gpu/drm/rcar-du/Makefile | 2 +
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 30 +-
drivers/gp
From: Lars-Peter Clausen
The drm_get_edid() function performs direct I2C accesses to read EDID
blocks, assuming that the monitor DDC interface is directly connected to
the I2C bus. It can't thus be used with HDMI encoders that control the
DDC bus and expose EDID blocks through a different interfa
Replace the manual loop implementation with the macro to simplify the
code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du
The encoder DT node will be needed to register an external HDMI encoder.
Pass it to the rcar_du_encoder_init() function to prepare for HDMI
support.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 5 +++--
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 3 ++-
drivers
The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters
compatible with HDMI 1.4 and DVI 1.0. They're described in DT using the
OF graph bindings and a list of custom properties pertaining to the
input video bus configuration.
Cc: devicetree at vger.kernel.org
Signed-off-by: Lauren
Add DT nodes for the ADV7511 HDMI encoder and its HDMI output connector
and configure the DISP pin group that drives the HDMI transmitter DE
pin.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 50 ++-
1 file changed, 49 insertions(+),
From: Lars-Peter Clausen
This patch adds a driver for the Analog Devices adv7511. The adv7511 is
a standalone HDMI transmitter chip. It features a HDMI output interface
on one end and video and audio input interfaces on the other.
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Laurent Pinchar
org/archives/dri-devel/attachments/20140924/17ab2827/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/128a49d7/attachment.html>
1 - 100 of 137 matches
Mail list logo
