ide.
>
> So from my side I think we should move ahead with Maarten's work and
> figure the android side out once there's real interest.
The downside of that is that we may end up with two different ways to
synchronize buffers if it turns out that we can't make Android (or other
use-cases) work with DMA fence. However I don't think that justifies
postponing this patch set indefinitely.
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/20140620/94d2464b/attachment.sig>
Hello Jean-Francois Moine,
This is a semi-automatic email about new static checker warnings.
The patch fc275a74eb81: "drm/i2c: tda998x: free the CEC device on
encoder_destroy" from Jan 25, 2014, leads to the following Smatch
complaint:
drivers/gpu/drm/i2c/tda998x_drv.c:1194 tda998x_encoder_des
&innolux_n156bge_l21,
> + }, {
This patch should also be adding a device tree binding document for this
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/20140620/ef38df6c/attachment.sig>
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/20140620/4bbaeb5c/attachment.html>
On 20 June 2014 18:27, ?meric MASCHINO wrote:
> 2014-06-20 2:06 GMT+02:00 Dave Airlie :
>> So to run in AGP mode you need a chipset specific driver to manage the
>> chipsets AGP GART and other features, that the GPU drivers can talk
>> to.
>
> Do the GPU drivers then talk differently to the graphi
Hi All,
On 18 June 2014 17:04, Rahul Sharma wrote:
> mixer_wait_for_vblank function expects that the upcoming
> vsync interrupt handler routine will clear the
> wait_vsync_event atomic variable.
>
> For this to happen, interrupts should be enabled and
> disabled properly.
>
> Signed-off-by: Rahul
On Fri, Jun 20, 2014 at 7:59 AM, Siarhei Siamashka
wrote:
>
> On Fri, 4 Apr 2014 17:22:01 +0800
> Daniel Kurtz wrote:
>
> > Kernel access to the eyxnos fbdev framebuffer is via its gem object's
> > kernel mapping (kvaddr, stored in info->screen_base).
> >
> > User space access is provided by mma
https://bugzilla.kernel.org/show_bug.cgi?id=68151
Fabian changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Just ping, any comments?
Thanks
Tiejun
On 2014/6/19 17:53, Tiejun Chen wrote:
> Originally the reason to probe ISA bridge instead of Dev31:Fun0
> is to make graphics device passthrough work easy for VMM, that
> only need to expose ISA bridge to let driver know the real
> hardware underneath. This
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140620/b1f595f9/attachment-0001.html>
Hi
On Wed, Jun 18, 2014 at 8:33 AM, Zhaowei Yuan
wrote:
> If user uses wrong ioctl command with _IOC_NONE and argument size
> greater than 0, it can cause NULL pointer access from memset of line
> 463. If _IOC_NONE, don't memset to 0 for kdata.
>
> Signed-off-by: Zhaowei Yuan
Reviewed-by: Davi
https://bugzilla.kernel.org/show_bug.cgi?id=65121
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Re-send the patch to remove the unnecessary initialization and the comment
> This change implements msm drm specific fb_mmap function for fb device
> to properly map the fb address to userspace.
>
> Signed-off-by: Hai Li
> Signed-off-by: Stephane Viau
> ---
> drivers/gpu/drm/msm/msm_fbdev.c | 3
Il 19/06/2014 11:53, Tiejun Chen ha scritto:
> so this mean that isa bridge is still represented with Dev31:Func0
> like the native OS. Furthermore, currently we're pushing VGA
> passthrough support into qemu upstream, and with some discussion,
> we wouldn't set the bridge class type and just expos
Well I have no clue about forwarding the intel gpu to virtualized
hosts and also no idea who could review this really. There's been a
bit a discussion around the iommu mapping forwarding and similar
topics though. So I really wonder how well our driver works in this
use case ...
-Daniel
On Fri, Ju
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/2014 02:15 PM, Wolfram Sang wrote:
> On Thu, Jun 19, 2014 at 07:59:57PM -0700, 'Greg Kroah-Hartman'
> wrote:
>> On Fri, Jun 20, 2014 at 11:36:03AM +0900, Jingoo Han wrote:
>>> On Friday, June 20, 2014 3:49 AM, Wolfram Sang wrote:
Pr
ping.
On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar
wrote:
> From: Rahul Sharma
>
> This patch adds ps8622 lvds bridge discovery code to the dp driver.
>
> Signed-off-by: Rahul Sharma
> Signed-off-by: Ajay Kumar
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c |5 +
> 1 file changed, 5
ping.
On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar
wrote:
> From: Vincent Palatin
>
> This patch adds drm_bridge driver for parade DisplayPort
> to LVDS bridge chip.
>
> Signed-off-by: Vincent Palatin
> Signed-off-by: Andrew Bresticker
> Signed-off-by: Sean Paul
> Signed-off-by: Rahul Sharma
ping.
On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar
wrote:
> exynos_dp supports a simple bridge chain with ptn3460 bridge
> and an LVDS panel attached to it.
> This patch creates the bridge chain with ptn3460 as the head
> of the list and panel_binder being the tail.
>
> Signed-off-by: Ajay Kumar
ping.
On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar
wrote:
> Modify the driver to invoke callbacks for the next bridge
> in the bridge chain.
> Also, remove the drm_connector implementation from ptn3460,
> since the same is implemented using panel_binder.
>
> Signed-off-by: Ajay Kumar
> ---
> d
ping.
On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar
wrote:
> Add a dummy bridge which binds all of the drm_bridge callbacks
> to corresponding drm_panel callbacks.
>
> In theory, this is just a glue layer for the last bridge and
> the panel attached to it.
>
> This driver also implements the requ
ping.
On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar
wrote:
> Add drm_panel controls to support powerup/down of the
> eDP panel, if one is present at the sink side.
>
> Signed-off-by: Ajay Kumar
> ---
> .../devicetree/bindings/video/exynos_dp.txt|2 +
> drivers/gpu/drm/exynos/Kconfig
ping.
On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar
wrote:
> Add helper functions to create bridge chain and to call the
> corresponding next_bridge functions.
>
> Signed-off-by: Ajay Kumar
> Suggested-by: Rob Clark
> ---
> include/drm/drm_crtc.h | 72
> +
ping.
On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar
wrote:
> This patch adds a simple driver to handle all the LCD and LED
> powerup/down routines needed to support eDP/LVDS panels.
>
> The LCD and LED units are usually powered up via regulators,
> and almost on all boards, we will have a BACKLIG
ping.
On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar
wrote:
> Most of the panels need an init sequence as mentioned below:
> -- poweron LCD unit/LCD_EN
> -- start video data
> -- poweron LED unit/BACKLIGHT_EN
> And, a de-init sequence as mentioned below:
> -- powero
ping.
On Wed, Jun 11, 2014 at 11:56 PM, Ajay Kumar
wrote:
> Move the DP training and video enable from the hotplug handler into
> a seperate function and call the same during dpms ON.
>
> With existing code, DP HPD should be generated just few ms before
> calling enable_irq in dp_poweron.
>
> Th
ping.
On Wed, Jun 11, 2014 at 11:56 PM, Ajay Kumar
wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> I have tested this after adding few DT changes for exynos5250-snow,
> exynos5420-peach-pit
://lists.freedesktop.org/archives/dri-devel/attachments/20140620/3cb256cd/attachment.html>
On Friday, June 20, 2014 3:49 AM, Wolfram Sang wrote:
>
> Pretty much a year ago, Tushar cleaned up a lot of deprecated uses of
> devm_request_and_ioremap, yet some remains are still left. Remove the last two
> users, and let the function rest in peace. I'd suggest that this series is
> picked up
On Mon, Jun 02, 2014 at 11:15:51AM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> If the user is interested in getting accurate vblank sequence
> numbers all the time they may disable the vblank disable timer
> entirely. In that case it seems appropriate to kick start t
On Mon, May 26, 2014 at 02:46:32PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> The new watermaek update mechanism requires interrupts to work
s/watermaek/watermark/
> correctly. Because of this we need interrupts while disabling crtcs
> during suspend. So move the
This change implements msm drm specific fb_mmap function for fb device
to properly map the fb address to userspace.
Signed-off-by: Hai Li
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/msm_fbdev.c | 38 --
1 file changed, 36 insertions(+), 2 deletions(-
.
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140620/a3f4ece6/attachment-0001.sig>
On Fri, Jun 20, 2014 at 1:42 AM, Greg KH wrote:
>> I'm actually concerned about this trend. Downgrading things to WARN_ON
>> can allow a security bug in the kernel to continue to exist, for
>> example, or make the error message disappear.
>
> A BUG_ON makes any error message disappear pretty quic
2014-06-20 2:06 GMT+02:00 Dave Airlie :
> So to run in AGP mode you need a chipset specific driver to manage the
> chipsets AGP GART and other features, that the GPU drivers can talk
> to.
Do the GPU drivers then talk differently to the graphics card when
there's a GART? I mean, are there differen
On Fri, Jun 20, 2014 at 12:39 AM, H. Peter Anvin wrote:
>>> Aside: This is a pet peeve of mine and recently I've switched to
>>> rejecting all patch that have a BUG_ON, period.
>>
>> Please do, I have been for a few years now as well for the same reasons
>> you cite.
>>
>
> I'm actually concerned
On Fri, Jun 20, 2014 at 10:11 AM, Laszlo Kertesz
wrote:
>
> On 6/20/2014 4:30 PM, bugzilla-daemon at freedesktop.org wrote:
>
> Comment # 25 on bug 72921 from Alex Deucher
>
> (In reply to comment #24)
>> Created attachment 101420 [details]
>> dmesg with working bapm patch
>>
>> I can confirm that
On 19.06.2014 19:20, Marek Ol??k wrote:
> Hi Michel,
>
> 3.15 doesn't contain Christian's fix yet, so it should be always
> broken for everybody. The fix is currently only in 3.16.
>
> Alternatively, you can cherry-pick the fix to 3.15, but it doesn't
> apply cleanly.
That's a good point. Sorry,
On 20 June 2014 03:17, ?meric MASCHINO wrote:
> DRI gurus,
>
> If I'm not mistaken, the current Linux graphics stack is as follows
> (excluding Wayland protocol and LLVM or GLAMOR-based approaches):
>
> X11/OpenGL app -> libX/Mesa -> DDX driver/Mesa DRI module -> kernel
> DRM -> hardware
>
> What'
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140620/229a312f/attachment.html>
pply that right now while I'm remembering it :)
Yay, great! Thank you both!
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org
On 20 June 2014 04:19, Greg KH wrote:
> On Thu, Jun 19, 2014 at 01:45:30PM -0400, Rob Clark wrote:
>> On Thu, Jun 19, 2014 at 1:00 PM, Greg KH
>> wrote:
>> > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote:
>> >> On Wed, Jun 18, 2014 at 9:13 PM, Greg KH
>> >> wrote:
>> >> > On Wed, J
https://bugzilla.kernel.org/show_bug.cgi?id=65121
--- Comment #11 from xerofoify at gmail.com ---
It seems to be only the opener or maintainer of this subsystem who can close
it.
Cheers Nick
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=65121
--- Comment #10 from xerofoify at gmail.com ---
Our you sure, other people seem to
be able to do it with other bugs.
Thanks Nick
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=65121
--- Comment #9 from Dave Airlie ---
kernel bugzilla sucks I can't change bug states.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=62541
xerofoify at gmail.com changed:
What|Removed |Added
CC||xerofoify at gmail.com
--- Commen
https://bugzilla.kernel.org/show_bug.cgi?id=65121
xerofoify at gmail.com changed:
What|Removed |Added
CC||xerofoify at gmail.com
--- Commen
On Fri, 4 Apr 2014 17:22:01 +0800
Daniel Kurtz wrote:
> Kernel access to the eyxnos fbdev framebuffer is via its gem object's
> kernel mapping (kvaddr, stored in info->screen_base).
>
> User space access is provided by mmap(), read() and write() of /dev/fb/fb0.
> These functions also only use s
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140620/6acfe9b1/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140620/5d1e448f/attachment-0001.html>
From: Fabio Estevam
SOC_IMX6SL does not have the IPU block, so remove it from the Kconfig entry.
Signed-off-by: Fabio Estevam
---
drivers/gpu/ipu-v3/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
index 2f228a2
51 matches
Mail list logo
