On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote:
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> +config PWM_CRC
> + bool "Intel Crystalcove (CRC) PWM support"
> + depends on X86 && INTEL_SOC_PMIC
> + help
> + Generic PWM framework driver for Crystalcove (CRC) PM
no longer happens.
--
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/20150430/1a11f798/attachment.html>
Hello Gustavo!
Gustavo Padovan wrote:
> Hi Tobias,
>
> 2015-04-30 Tobias Jakobi :
>
>> First step in allowing a more generic way to setup complex
>> blending for the different layers.
>>
>> Signed-off-by: Tobias Jakobi
>> ---
>> drivers/gpu/drm/exynos/exynos_mixer.c | 74
>> +
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150430/47c9dda5/attachment.html>
TML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150430/364805e1/attachment.html>
ng 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/20150430/4793b765/attachment.html>
These files are built off of a tristate Kconfig option and also contain
modular function calls so they should explicitly include module.h to
avoid compile breakage during header shuffles done in the future.
Cc: David Airlie
Cc: Mark Yao
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Paul
eedesktop.org/archives/dri-devel/attachments/20150430/ecf09403/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/20150430/35e82543/attachment.html>
and without it (just more often with nine).
--
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/20150430/2878e4ee/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150430/4ec70621/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/20150430/6bb62176/attachment.html>
5
xorg-server 1.17.1-5
--
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/20150430/488db785/attachment.html>
org/archives/dri-devel/attachments/20150430/6b51a40f/attachment.html>
From: Gustavo Padovan
The planes are already disabled by the drm_atomic_helper_commit() code
so we don't need to disable the in these two places.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c| 11 ---
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 8 --
From: Gustavo Padovan
Run dpms operations through the atomic intefaces. This basically removes
the .dpms() callback from econders and crtcs and use .disable() and
.enable() to turn the crtc on and off.
v2: Address comments by Joonyoung:
- make hdmi code call ->disable() instead of ->dpms
From: Gustavo Padovan
Everything starts disabled so we don't really need to disable anything.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/e
From: Gustavo Padovan
Now that no one is using the functions exported by exynos_drm_plane due
to the atomic conversion we can make remove some of the them or make them
static.
v2: remove unused exynos_drm_crtc
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 90 +
From: Gustavo Padovan
PageFlips now use the atomic helper to work through the atomic modesetting
API. Async page flips are not supported yet.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 63 +---
drivers/gpu/drm/exynos/exynos_drm_fb.
From: Gustavo Padovan
Now that phase 1 and 2 are complete switch .set_config helper to
use the atomic one.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b
From: Gustavo Padovan
Now that phase 1 and 2 are complete we can switch the update/disable_plane
callbacks to their atomic version.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 3 +++
drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 ++--
2 files changed, 5 inser
From: Gustavo Padovan
Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
track of the framebuffer pointer and reference.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/exynos
From: Gustavo Padovan
Set CRTC, planes and connectors to use the default implementations from
the atomic helper library. The helpers will work to keep track of state
for each DRM object.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/bridge/ps8622.c | 4
drivers/gpu/drm/brid
From: Gustavo Padovan
The new atomic infrastructure needs the .mode_set_nofb() callback to
update CRTC timings before setting any plane.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 60 +---
1 file changed, 9 insertions(+), 51 deleti
From: Gustavo Padovan
The atomic helper to disable planes also uses the optional
.atomic_disable() helper. The unique operation it does is calling
.win_disable()
exynos_drm_fb_get_buf_cnt() needs a fb check too to avoid a null pointer.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos
From: Gustavo Padovan
Rip out the check from exynos_update_plane() and create
exynos_check_plane() for the check phase enabling use to use
the atomic helpers to call our check and update phases when updating
planes.
Update all users of exynos_update_plane() accordingly to call
exynos_check_plane
Hi,
Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.
v2: fixes comments by Joonyoung
- remove unused var in patch 09
- use ->disable instead of outdated ->dpms in hdmi code
- remove WARN_ON from cr
Hello Olof,
On 04/30/2015 05:57 PM, Olof Johansson wrote:
> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman wrote:
>> Krzysztof Kozlowski writes:
>
> This should fix issue reported by Javier [1][2].
>
> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
> esp
2015-04-30 Tobias Jakobi :
> Hello Gustavo!
>
>
> Gustavo Padovan wrote:
> > Hi Tobias,
> >
> > 2015-04-30 Tobias Jakobi :
> >
> >> First step in allowing a more generic way to setup complex
> >> blending for the different layers.
> >>
> >> Signed-off-by: Tobias Jakobi
> >> ---
> >> drivers/
On Thu, Apr 30, 2015 at 03:43:02PM +0100, Chris Wilson wrote:
> On Thu, Apr 30, 2015 at 05:30:50PM +0300, Dan Carpenter wrote:
> > We switched from calling i915_gem_alloc_context_obj() to calling
> > i915_gem_alloc_object() so the error handling needs to be updated to
> > check for NULL instead of
We switched from calling i915_gem_alloc_context_obj() to calling
i915_gem_alloc_object() so the error handling needs to be updated to
check for NULL instead of IS_ERR().
Fixes: 149c86e74fe4 ('drm/i915: Allocate context objects from stolen')
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/d
Clock rates are stored in an unsigned long field, but ->round_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are reported using negative error codes), which can lead
to long overflow if the clock rate exceed 2Ghz.
Change ->round_rate() prototype to return 0
Hello,
As previously discussed in this thread [1], this series is changing
clk_ops' ->round_rate()/->determine_rate() prototypes to avoid long
overflows when the returned rate is exceeding 2Ghz.
Most of those changes have been compile-tested, but none of them have
been tested on real hardware (th
Hi Tobias,
2015-04-30 Tobias Jakobi :
> First step in allowing a more generic way to setup complex
> blending for the different layers.
>
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 74
> +--
> 1 file changed, 63 insertions(+)
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 809f840..5a435aa 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/d
This updates the blending setup when the layer configuration
changes (triggered by mixer_win_{commit,disable}).
Extra care has to be taken for the layer that is currently
being enabled/disabled.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 23 +++
Previously blending setup was static and most of it was
done in mixer_win_reset().
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exy
This analyses the current layer configuration (which layers
are enabled, which have alpha-pixelformat, etc.) and setups
blending accordingly.
We currently disable all kinds of blending for the bottom-most
layer, since configuration of the mixer background is not
yet exposed.
Also blending is only
First step in allowing a more generic way to setup complex
blending for the different layers.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 74 +--
1 file changed, 63 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/ex
Hello,
here's the rework of the layer blending setup that I discussed with Joonyoung
in the past days. There's still
some TODOs in the code, but more or less it does what it's supposed to do. What
still bothers me a bit is that I
currently call blending reconfig in mixer_cfg_layer(). It would
On Tue, Mar 17, 2015 at 12:56:32PM +0100, Jan Kara wrote:
> Provide new function get_vaddr_pfns(). This function maps virtual
> addresses from given start and fills given array with page frame numbers of
> the corresponding pages. If given start belongs to a normal vma, the function
> grabs refere
Le 30/04/2015 16:39, Boris Brezillon a écrit :
> All modes exposed by simple panels should be tagged as driver defined
> modes.
> Moreover, if a panel supports only one mode, this mode is obviously the
> preferred one.
>
> Doing this also fix a problem occurring when a 'video=' parameter is passe
All modes exposed by simple panels should be tagged as driver defined
modes.
Moreover, if a panel supports only one mode, this mode is obviously the
preferred one.
Doing this also fix a problem occurring when a 'video=' parameter is passed
on the kernel cmdline. In some cases the user provided mod
drm_display_mode_from_videomode() is already calling drm_mode_set_name() on
the provided mode.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panel/panel-simple.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
i
On Thu, Apr 30, 2015 at 05:30:50PM +0300, Dan Carpenter wrote:
> We switched from calling i915_gem_alloc_context_obj() to calling
> i915_gem_alloc_object() so the error handling needs to be updated to
> check for NULL instead of IS_ERR().
I had a patch to change i915_gem_alloc_object() to report t
2015-04-22 17:20 GMT-03:00 Alex Deucher :
> On Tue, Apr 21, 2015 at 2:09 PM, Todd Previte wrote:
>> Displayport compliance test 4.2.2.6 requires that a source device be capable
>> of
>> detecting a corrupt EDID. The test specification states that the sink device
>> sets up the EDID with an invali
Hi Dave, just one fix for v4.1-rc2. Plenty of travel last week all
around, I'm sure we'll find more to worry about...
BR,
Jani.
The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
are available in the git repository at:
gi
The current iteration in get_dsi_id_from_intf() is wrong:
instead of iterating until hw_cfg->intf.count, we need to iterate
until MDP5_INTF_NUM_MAX here.
Let's take the example of msm8x16:
hw_cfg->intf.count = 1
intfs[0] = INTF_Disabled
intfs[1] = INTF_DSI
If we stop iterating once i reaches
u could test.
It just disables using UVD semaphores for now.
--
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/2015043
On 04/29/2015 07:57 PM, Lee Jones wrote:
> On Wed, 29 Apr 2015, Shobhit Kumar wrote:
>
>> On some Intel SoC platforms, the panel enable/disable signals are
>> controlled by CRC PMIC. Add those control as a new GPIO in a lookup
>> table for gpio-crystalcove chip during CRC driver load
>>
>> v2: Mak
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150430/fb92aac9/attachment.html>
ts.freedesktop.org/archives/dri-devel/attachments/20150430/a1fb4212/attachment.html>
Hi Emil,
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
owner at vger.kernel.org] On Behalf Of Emil Velikov
Sent: Wednesday, April 29, 2015 5:00 PM
>
> Hi Kamil,
>
> Allow me to put a few suggestions:
>
> On 29 April 2015 at 11:02, Kamil Debski wrote:
> > This is the first versio
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Jan Outhuis changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=95911
Christian König changed:
What|Removed |Added
CC||deathsimple at vodafone.de
--- Comment
Avoid such errors at compilation time:
format '%d' expects argument of type 'int', but argument 3 has type
'size_t'
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_hos
https://bugzilla.kernel.org/show_bug.cgi?id=95911
--- Comment #9 from gitne at excite.co.jp ---
(In reply to Michel Dänzer from comment #8)
> Can you attach the kernel log from before and across suspend/resume as well?
I can try but there seems to be nothing worth noting before resume. Is there
On Thu, Apr 30, 2015 at 9:40 AM, Javier Martinez Canillas
wrote:
> Hello Olof,
>
> On 04/30/2015 05:57 PM, Olof Johansson wrote:
>> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman wrote:
>>> Krzysztof Kozlowski writes:
>>
>> This should fix issue reported by Javier [1][2].
>>
>> Te
Hi Dave,
Am Montag, 20. April 2015, 09:30:06 schrieb Mark yao:
> Hi Dave
> I'm interesting to maintain the rockchip drm, so add entry for
> Rockchip drm.
> and some fixes.
can you consider these as fixes for 4.1?
Thanks
Heiko
>
> Can you land them?
>
> The following changes s
https://bugzilla.kernel.org/show_bug.cgi?id=95911
Michel Dänzer changed:
What|Removed |Added
CC||christian.koenig at amd.com
--- Comment
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150430/d38bf5cc/attachment.html>
On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman wrote:
> Krzysztof Kozlowski writes:
>
>> 2015-04-30 2:31 GMT+09:00 Kevin Hilman :
>>> Krzysztof Kozlowski writes:
>>>
After adding display power domain for Exynos5250 in commit
2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos52
2015-04-30 2:31 GMT+09:00 Kevin Hilman :
> Krzysztof Kozlowski writes:
>
>> After adding display power domain for Exynos5250 in commit
>> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
>> display on Chromebook Snow and others stopped working after boot.
>>
>> The reason for
Krzysztof Kozlowski writes:
> 2015-04-30 2:31 GMT+09:00 Kevin Hilman :
>> Krzysztof Kozlowski writes:
>>
>>> After adding display power domain for Exynos5250 in commit
>>> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
>>> display on Chromebook Snow and others stopped wor
https://bugzilla.kernel.org/show_bug.cgi?id=97561
Bug ID: 97561
Summary: Regression: Issue with ATI HD 6570 (possibly others)
HDMI output Purple Line
Product: Drivers
Version: 2.5
Kernel Version: 4.0 and above
Hardware:
https://bugzilla.kernel.org/show_bug.cgi?id=96351
--- Comment #33 from George Cheban ---
Sorry guys, made it hang up by opening player fullscreen and by grabbing it to
top of working space. For now can't even boot to any kernel because of "Minimal
Bash-like line editing is supported". Will try to
https://bugzilla.kernel.org/show_bug.cgi?id=96351
--- Comment #32 from George Cheban ---
Created attachment 175331
--> https://bugzilla.kernel.org/attachment.cgi?id=175331&action=edit
Screenshot
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=96351
--- Comment #31 from George Cheban ---
Compiled a new kernel v4.1:
# git checkout -b v4.1
# git revert 1a81b94...
/* 30 minutes to find out how to quit from VIM :D */
# make oldconfig
# make -j3 && make modules_install && make install
# reboot
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150430/4728a1d5/attachment.html>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150430/237fdb73/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/20150430/2074d7f5/attachment.html>
RI3 enabled.
--
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/20150430/e66d0d5f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=96351
--- Comment #30 from Michel Dänzer ---
Commit 1a81b94d4fc8470848eb80e39a6001c48cc3fc29 is specific to the c6x
architecture, so it can't be the cause of your problem. Looks like something
went wrong during the bisection. Most likely, you incorrect
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150430/e5e9e58f/attachment-0001.html>
-1 lines).
--
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/20150430/313b929f/attachment.html>
++ b/lib/Target/R600/SIInstructions.td
--
File to patch: ^C
--
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/attachmen
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150430/813c4c6b/attachment.html>
77 matches
Mail list logo
