The huge majority of GPIOs have their direction and initial value set
right after being obtained by one of the gpiod_get() functions. The
integer GPIO API had gpio_request_one() that took a convenience flags
parameter allowing to specify an direction and value applied to the
returned GPIO. This fea
Hi Linus,
This is radeon and intel fixes, and is a small bit larger than I'm
guessing you'd like it to be,
i915: fixes 32-bit highmem i915 blank screen, semaphore hang and runtime
pm fix
radeon: gpuvm stability fix for hangs since 3.15, and hang/reboot
regression on TN/RL devices,
The only s
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140725/ee35011f/attachment.html>
ext part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140725/0dbab815/attachment.html>
On 25.07.2014 08:51, Alex Deucher wrote:
> We need to make sure we have a new enough firmware with
> the fixed nop packet.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_kms.c | 6 ++
> include/uapi/drm/radeon_drm.h | 1 +
> 2 files changed, 7 insertions(+)
>
>
On 25.07.2014 11:05, Michel D?nzer wrote:
> On 25.07.2014 08:51, Alex Deucher wrote:
>> We need to make sure we have a new enough firmware with
>> the fixed nop packet.
>>
>> Signed-off-by: Alex Deucher
>> ---
>> drivers/gpu/drm/radeon/radeon_kms.c | 6 ++
>> include/uapi/drm/radeon_drm.h
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140725/299be71d/attachment-0001.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140725/2e69e470/attachment.html>
On 25.07.2014 11:06, Michel D?nzer wrote:
> On 25.07.2014 11:05, Michel D?nzer wrote:
>> On 25.07.2014 08:51, Alex Deucher wrote:
>>> We need to make sure we have a new enough firmware with
>>> the fixed nop packet.
>>>
>>> Signed-off-by: Alex Deucher
>>> ---
>>> drivers/gpu/drm/radeon/radeon_kms
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140725/e2b64684/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/20140725/cd8aaf18/attachment.html>
From: Fabio Estevam
Since commit fe32c9f34b9e ("drm: drop redundant drm_file->is_master")
we should use drm_is_master, otherwise the following build error is seen:
drivers/staging/imx-drm/imx-drm-core.c: In function 'imx_drm_driver_preclose':
drivers/staging/imx-drm/imx-drm-core.c:185:11: error:
On Fri, Jul 25, 2014 at 1:23 AM, Laurent Pinchart
wrote:
>> diff --git a/Documentation/gpio/consumer.txt
>> b/Documentation/gpio/consumer.txt index 7ff30d2..a3fb1d7 100644
>> --- a/Documentation/gpio/consumer.txt
>> +++ b/Documentation/gpio/consumer.txt
>> @@ -29,13 +29,24 @@ gpiod_get() functions
On Fri, Jul 25, 2014 at 1:10 AM, Arnd Bergmann wrote:
> On Friday 25 July 2014 00:04:58 Alexandre Courbot wrote:
>> I'm not sure how this could be applied harmlessly though - maybe through
>> a dedicated branch for -next? Problem is that a lot of new code is not
>> yet merged into mainline, and co
issue?
--
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/20140725/51a35e37/attachment.html>
Hi
On Fri, Jul 25, 2014 at 5:08 AM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Since commit fe32c9f34b9e ("drm: drop redundant drm_file->is_master")
> we should use drm_is_master, otherwise the following build error is seen:
>
> drivers/staging/imx-drm/imx-drm-core.c: In function 'imx_drm_dr
On 2014? 07? 24? 19:23, Andrzej Hajda wrote:
> Hi Inki,
>
> +CC: Thierry and Alexandre
>
> On 07/18/2014 12:56 PM, Inki Dae wrote:
>> This patch adds below two flags for LPM transfer, and it attaches LPM flags
>> to a msg in accordance with master's mode_flags set by LCD Panel driver.
>>
>> MIPI_
On Thu, Jul 24, 2014 at 11:38:28PM +0200, David Herrmann wrote:
> On Thu, Jul 24, 2014 at 11:52 AM, Daniel Vetter wrote:
> > On Wed, Jul 23, 2014 at 05:26:42PM +0200, David Herrmann wrote:
> >> +static inline bool drm_is_master(const struct drm_file *file)
> >> +{
> >
> > Hm, we don't have any mea
On Thu, Jul 24, 2014 at 10:56:07AM -0400, Rob Clark wrote:
[snip]
> ok, it's entirely possibly that I'm missunderstanding a bit your proposal..
Yeah I get that feeling a bit too. I'll cut out the technical details for
now and will try to concentrate on one example. Maybe that clarifies.
[snip]
On Thu, Jul 24, 2014 at 10:59:36PM +0800, Shawn Guo wrote:
> On Thu, Jul 24, 2014 at 12:38:59PM +0200, Daniel Vetter wrote:
> > > > > +static int imx_drm_suspend(struct device *dev)
> > > > > +{
> > > > > + struct drm_device *drm_dev = dev_get_drvdata(dev);
> > > > > + struct drm_connector
On 2014? 07? 24? 19:48, Andrzej Hajda wrote:
> +CC: Thierry and Alexandre
>
> On 07/18/2014 12:56 PM, Inki Dae wrote:
>> This patch adds LPM transfer support for video or command data.
>>
>> With this patch, Exynos MIPI DSI controller can transfer command or
>> video data with HS or LP mode in acc
Am 25.07.2014 um 05:05 schrieb Alex Deucher:
> On Thu, Jul 24, 2014 at 10:24 PM, Michel D?nzer wrote:
>> On 25.07.2014 11:06, Michel D?nzer wrote:
>>> On 25.07.2014 11:05, Michel D?nzer wrote:
On 25.07.2014 08:51, Alex Deucher wrote:
> We need to make sure we have a new enough firmware wi
On Thu, Jul 24, 2014 at 6:12 AM, Daniel Vetter
wrote:
> In my review of
>
> commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9
> Author: Rob Clark
> Date: Fri May 30 11:37:03 2014 -0400
>
> drm: add object property typ
>
> I asked for a check to make sure that we never leak an fb from the
> g
The mixer graphic layer 0 isn't blended as default by commit
0377f4ed9f1aed30292c4e3c87f24e028ae26f36(drm/exynos: Don't blend mixer
layer 0). But it needs to be blended with graphic layer 0 if video layer
is enabled by vp because video layer is bottom.
Signed-off-by: Joonyoung Shim
---
drivers/g
On Fri, Jul 25, 2014 at 4:15 AM, Daniel Vetter wrote:
> On Thu, Jul 24, 2014 at 10:56:07AM -0400, Rob Clark wrote:
> [snip]
>
>> ok, it's entirely possibly that I'm missunderstanding a bit your proposal..
>
> Yeah I get that feeling a bit too. I'll cut out the technical details for
> now and will
Daniel,
Your commit 2225a28fd916 ("drm/i915: Ditch UMS config option") is
included in today's linux-next (ie, next-20140725). It removes the
Kconfig symbol DRM_I915_UMS.
It didn't remove the two (negative) checks for CONFIG_DRM_I915_UMS.
These checks are superfluous as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Damien Lespiau (2):
intel: Sync the command parser version parameter from kernel
intel: Sync typo fix from the kernel sources.
Daniel Kurtz (8):
eyxnos: install exynos tests if HAVE_INSTALL_TESTS
exynos: fix two warnings
On Fri, Jul 25, 2014 at 11:30:55AM +0200, Christian K?nig wrote:
> Am 25.07.2014 um 05:05 schrieb Alex Deucher:
> >On Thu, Jul 24, 2014 at 10:24 PM, Michel D?nzer
> >wrote:
> >>On 25.07.2014 11:06, Michel D?nzer wrote:
> >>>On 25.07.2014 11:05, Michel D?nzer wrote:
> On 25.07.2014 08:51, Alex
On 24 Jul 04:25 PM, Darren Etheridge wrote:
> On 07/11/2014 09:18 AM, Ezequiel Garcia wrote:
> >Hello all,
> >
> >This patchset adds the required changes to support an optional backlight
> >and GPIO for the tilcdc panel driver.
> >
> >There was some code to support a backlight, but it was somewhat
Use the new devm_gpiod_get_optional() to simplify the probe code.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/panel/panel-simple.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.
ssue?
Or did I misunderstand, something and it is expected not to get KDE up and
running?
--
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/20140725/6a27b95f/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140725/415bc473/attachment.html>
On Thu, Jul 24, 2014 at 11:47:55AM +0200, Lucas Stach wrote:
> > +static int imx_drm_resume(struct device *dev)
> > +{
> > + struct drm_device *drm_dev = dev_get_drvdata(dev);
> > + struct drm_connector *connector;
> > +
> > + drm_modeset_lock_all(drm_dev);
> > + list_for_each_entry(connect
HDMI currently stops working after a system suspend/resume cycle. The
cause is that the mode setting states in hardware gets lost and isn't
restored across the suspend/resume cycle.
The patch adds a very basic suspend/resume support to imx-drm driver,
and calls drm_helper_resume_force_mode() in .
On Thu, Jul 24, 2014 at 11:38:52AM +0200, Philipp Zabel wrote:
> Hi Shawn,
>
> Am Donnerstag, den 24.07.2014, 17:17 +0800 schrieb Shawn Guo:
> > HDMI currently stops working after a system suspend/resume cycle. It
> > turns out that the cause is the imx-hdmi encoder .dpms hook doesn't get
> > cal
On Thu, Jul 24, 2014 at 11:56:32AM +0200, Marc Kleine-Budde wrote:
> >> @@ -696,6 +696,44 @@ static int imx_drm_platform_remove(struct
> >> platform_device *pdev)
> >>return 0;
> >> }
> >>
> >> +#if CONFIG_PM_SLEEP
> >
> > use #ifdef
>
> ...or remove #if/#ifdef and mark as __maybe_unused
On Thu, 24 Jul 2014, Greg Kroah-Hartman wrote:
> On Fri, Jul 25, 2014 at 12:04:58AM +0900, Alexandre Courbot wrote:
> > The huge majority of GPIOs have their direction and initial value set
> > right after being obtained by one of the gpiod_get() functions. The
> > integer GPIO API had gpio_reques
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140725/732e1b77/attachment.html>
ccel". Is
that still necessary with your xf86-video-ati patch ?
--
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/20140725/5b6e7d76/attachment.html>
nd). No "Accel" or other option was set (and yes, it's Accel
with 7.4.0).
--
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/20140725/a1e8215d/attachment.html>
On Thu, May 22, 2014 at 07:00:50PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> Share the waitqueue that drm_irq uses when performing the vblank evade
> trick for atomic pipe updates.
>
> v2: Keep intel_pipe_handle_vblank() (Chris)
>
> Suggested-by: Daniel Vetter
>
ttachments/20140725/177810a3/attachment.html>
Older firmware didn't support the new nop packet.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cik.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 44d25da..80a7ce0 100644
--- a/dri
n comment
#83, appearing again at the end of dmesg's output. So, no luck for me yet.
--
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-dev
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140725/7c5bf9e2/attachment.html>
ition type is set to "OpenGL
3.1" and the Qt graphic system is set to "Native".
--
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/20140725/74e7b7d6/attachment.html>
We're going to need this for atomic.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c| 4 +--
drivers/gpu/drm/drm_crtc_helper.c | 2 +-
drivers/gpu/drm/drm_edid.c| 6 ++--
drivers/gpu/drm/drm_fb_helper.c | 6 ++--
drive
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140725/38072c21/attachment.html>
I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx
Playstation1 Emulator to the Powerpc-architecture. When running certain
games (for instance "Vagrant Stories") during longer cut-scenes i get a
reproducible crash of the radeon drm driver (i.e. it always crashes at
certain points
From: "Matwey V. Kornilov"
The format change is to fix the following compilation issue:
../drivers/gpu/drm/omapdrm/omap_plane.c: In function 'omap_plane_pre_apply':
../drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects
argument of type 'unsigned int', but argument 5 has type
From: "Matwey V. Kornilov"
The single one use-case for data_pa member of the struct pat is to carry a
value of dma_addr_t type.
This patch solves the following compilation error:
../drivers/gpu/drm/omapdrm/omap_dmm_tiler.c: In function 'dmm_txn_append':
../drivers/gpu/drm/omapdrm/omap_dmm_tiler
51 matches
Mail list logo