Hi Linus,
This is the main pull request for the drm for 4.3. Nouveau is probably the
biggest
amount of changes in here, since it missed 4.2. Highlights below, along with
the usual
bunch of fixes. There are a few minor conflicts with your tree but nothing
you can't handle. All stuff outside drm
Am Freitag, 4. September 2015, 16:06:02 schrieb Rob Herring:
> On Tue, Sep 1, 2015 at 3:46 PM, Heiko Stuebner wrote:
> > Am Dienstag, 1. September 2015, 13:49:58 schrieb Yakir Yang:
> >> Split the dp core driver from exynos directory to bridge
> >> directory, and rename the core driver to analogix
On Fri, 4 Sep 2015 14:53:34 -0300
Danilo Cesar Lemes de Paula wrote:
> In the last few days I sent three features:
> Markdown support (patch series 1)
> Cross-reference hyperlink support (patch series 1)
> in-struct-body documentation (series 2)
>
> I assume you want a new patch series for the s
On Fri, Sep 04, 2015 at 12:48:02PM -0700, Doug Anderson wrote:
> Hi,
>
> On Fri, Sep 4, 2015 at 11:21 AM, Doug Anderson
> wrote:
> > Russell,
> >
> > On Sat, Aug 8, 2015 at 9:10 AM, Russell King
> > wrote:
> >> Adjust the pixel clock values in the N calculation to match the more
> >> accurate c
On 4 September 2015 at 17:33, Alex Deucher wrote:
> On Mon, Aug 24, 2015 at 1:08 PM, Alex Deucher
> wrote:
>> On Mon, Aug 24, 2015 at 12:34 PM, Emil Velikov
>> wrote:
>>> In the latest version of CUnit the fourth parameter of the CU_SuiteInfo
>>> struct is pSetUpFunc rather than *pTests.
>>>
>
Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.
vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.
Si
Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.
vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.
Si
On 2015ë
09ì 04ì¼ 16:19, Daniel Vetter wrote:
> On Fri, Sep 04, 2015 at 01:05:35PM +0900, Inki Dae wrote:
>> Hi Gustavo,
>>
>> I had already a review but I didn't give any comment to you. Sorry about
>> that. This patch looks good to me but one thing isn't clear. Below is my
>> comment.
>>
>>
ntents"
--
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/20150904/604f6c02/attachment.html>
Hi Inki,
2015-09-04 Inki Dae :
> Hi Gustavo,
>
> I had already a review but I didn't give any comment to you. Sorry about
> that. This patch looks good to me but one thing isn't clear. Below is my
> comment.
>
>
> On 2015ë
09ì 04ì¼ 05:14, Gustavo Padovan wrote:
> > From: Gustavo Padovan
From: Gustavo Padovan
Set one of the planes for each crtc driver as a cursor plane enabled
window managers to fully work on exynos.
Signed-off-by: Gustavo Padovan
---
v2: use the top window for cursor on each crtc
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++--
drivers/gpu/drm/ex
From: Gustavo Padovan
Define DEFAULT_WIN as zero to help set the primary plane on all CRTCs.
Some CRTCs were defining a variable to store the default window, but that
is not necessary as the default (primary) window is always the window zero.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/c05df9dd/attachment.html>
Russell,
On Fri, Sep 4, 2015 at 5:27 PM, Russell King - ARM Linux
wrote:
> On Fri, Sep 04, 2015 at 04:50:03PM -0700, Doug Anderson wrote:
>> Russell,
>>
>> On Fri, Sep 4, 2015 at 2:24 PM, Russell King - ARM Linux
>> wrote:
>> >> In your case you're probably making the value that Linux
>> >> aske
bbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/3f3d3117/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/08264c8d/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/c231ef48/attachment.html>
Hi Dave,
A few more fixes for amdgpu from the last few days:
- Fix several copy paste typos
- Resume from suspend fixes for VCE
- Fix the GPU scheduler warning in kfifo_out
- Re-enable GPUVM fault interrupts which were inadvertently disabled
- GPUVM page table hang fix when paging
The following c
From: Gustavo Padovan
Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 125 -
1 file changed, 5
From: Gustavo Padovan
Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 89 ---
1 file changed, 3
From: Gustavo Padovan
Instead of having a .clock_enable callback enable the dp clock directly
from FIMD.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 13 ---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5
drivers/gpu/drm/exynos/exynos_drm_fimd.c |
From: Gustavo Padovan
Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 -
drivers/gpu/drm/exynos/exynos7_drm_decon.c
From: Gustavo Padovan
This callback is no longer used by any of the exynos_crtc drivers, remove
it.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 10 --
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
2 files changed, 12 deletions(-)
diff --git a/driv
From: Gustavo Padovan
It turns out that .commit() was never executed, because
at the time .mode_set_nofb() called it ctx->suspended was still false
and .commit() would return. It removes the callback from FIMD DECON 7 and
DECON 5433.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/ex
From: Gustavo Padovan
Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_mixer.c | 125 +-
1 file changed, 6
From: Gustavo Padovan
Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 56 +---
1 file changed, 3
From: Gustavo Padovan
Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 40 +
1 file changed, 2
From: Gustavo Padovan
The DP device will be properly enabled at the enable() call just
after the bind call finishes.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/driv
From: Gustavo Padovan
Hi,
This series adds proper runtime PM suport to CRTCs and Encoders, so
now instead of relying on 'suspended' or 'enabled' flags to track when
the CRTC or Encoder is enabled we let the pm_runtime subsystem do it for us
and remove all the flags. This is a important step to t
Russell,
On Fri, Sep 4, 2015 at 2:24 PM, Russell King - ARM Linux
wrote:
>> Basically the spec is saying that you want both N and CTS to be
>> integral. ...as you say you really want:
>> CTS = (TMDS * N) / (128 * audio_freq)
>
> In the case of software-programmed CTS and N values, they have to
On Wed, Sep 2, 2015 at 11:27 PM, Yakir Yang wrote:
> Hi Rob,
>
> å¨ 09/03/2015 04:17 AM, Rob Herring åé:
>>
>> On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang wrote:
>>>
>>> Some edp screen do not have hpd signal, so we can't just return
>>> failed when hpd plug in detect failed.
>>
>> This is a
On Tue, Sep 1, 2015 at 3:46 PM, Heiko Stuebner wrote:
> Am Dienstag, 1. September 2015, 13:49:58 schrieb Yakir Yang:
>> Split the dp core driver from exynos directory to bridge
>> directory, and rename the core driver to analogix_dp_*,
>> leave the platform code to analogix_dp-exynos.
>>
>> Signed
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/f719da7f/attachment.html>
Kernel modules: radeon
--
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/20150904/a60105a0/attachment.html>
n ring 5 succeeded
thank you very much
markus
--
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/20150904/9957916f/attachment-0001.html>
m > /tmp/vbios.rom
echo 0 > rom
--
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/20150904/4f8c7065/attachment.html>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/877b5e3c/attachment.html>
On 09/02/2015 11:15 AM, Jonathan Corbet wrote:
> On Tue, 1 Sep 2015 14:57:33 -0300
> Danilo Cesar Lemes de Paula wrote:
>
>> Did you find time to check this patch? As you mentioned that you applied
>> the Markdown support for the linux-next tree, this patch might be needed
>> (maybe "wanted" is a
From: Christian König
Try to make better decisions which process to kill based on per
file OOM badness.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/staging/android/lowmemorykiller.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/staging/android
From: Christian König
Try to make better decisions which process to kill based on
per file OOM badness.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
mm/oom_kill.c | 20
1 file changed, 20 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 2b
From: Christian König
Large amounts of VRAM are usually not CPU accessible, so they are not mapped
into the processes address space. But since the device drivers usually support
swapping buffers from VRAM to system memory we can still run into an out of
memory situation when userspace starts to
From: Christian König
This allows device drivers to specify an additional badness for the OOM
and low memory killer when they allocate memory on behalf of userspace.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
fs/file_table.c| 1 +
include/linux/fs.h | 1 +
2 files chan
Hello everyone,
I'm currently working on the issue that when device drivers allocate memory on
behalf of an application the OOM killer usually doesn't knew about that unless
the application also get this memory mapped into their address space.
This is especially annoying for graphics drivers wher
On Fri, Sep 04, 2015 at 11:59:58AM +0200, Alex Vazquez wrote:
> Hi,all!
>
> I'm using atmel-hlcdc driver to control a LCD panel and an application uses
> the /dev/fb0 framebuffer created by the driver. The display works fine
> except that the panel's standard orientation is landscape mode (480x275
Hi Gustavo,
I had already a review but I didn't give any comment to you. Sorry about
that. This patch looks good to me but one thing isn't clear. Below is my
comment.
On 2015ë
09ì 04ì¼ 05:14, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Set one of the planes for each crtc driver as
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/cc8c57bf/attachment.html>
Russell,
On Sat, Aug 8, 2015 at 9:10 AM, Russell King
wrote:
> Given the TDMS clock, audio sample rate, and the N parameter, we can
> calculate the CTS value for the audio clock regenerator (ACR) using the
> following calculation given in the HDMI specification:
>
> CTS = ftdms * N / (128
Hi,
On Fri, Sep 4, 2015 at 11:21 AM, Doug Anderson wrote:
> Russell,
>
> On Sat, Aug 8, 2015 at 9:10 AM, Russell King
> wrote:
>> Adjust the pixel clock values in the N calculation to match the more
>> accurate clock values we're given by the DRM subsystem, which are the
>> kHz pixel rate, with
On Mon, Aug 24, 2015 at 1:08 PM, Alex Deucher wrote:
> On Mon, Aug 24, 2015 at 12:34 PM, Emil Velikov
> wrote:
>> In the latest version of CUnit the fourth parameter of the CU_SuiteInfo
>> struct is pSetUpFunc rather than *pTests.
>>
>> Seems like the CUnit ABI broke at some point, so let's the
chment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/46733cc4/attachment.sig>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/cc7abf73/attachment.html>
_match,
> },
> };
Applied with a slightly reworded commit message.
Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/089f6056/attachment-0001.sig>
commit message.
Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/9a45858c/attachment.sig>
Russell,
On Sat, Aug 8, 2015 at 9:10 AM, Russell King
wrote:
> We never set the ratio for CTS/N calculation for the audio clock
> regenerator (ACR) to anything but 100, so this adds pointless
> complexity. Should we support pixel repetition, we should update the
> CTS/N calculation code to use t
Russell,
On Sat, Aug 8, 2015 at 9:10 AM, Russell King
wrote:
> Adjust the pixel clock values in the N calculation to match the more
> accurate clock values we're given by the DRM subsystem, which are the
> kHz pixel rate, with any fractional kHz rounded down in the case of
> the non-240, non-480
On Thu, Sep 03, 2015 at 11:04:40AM +0200, Thierry Reding wrote:
> Conversely, if the panel isn't capable of generating an HPD signal, then
> I don't think it would be appropriate to make it a DT property. It would
> be better to hard-code it in the driver, lest someone forget to set the
> property
Russell,
On Sat, Aug 8, 2015 at 9:10 AM, Russell King
wrote:
> There's no need to be recursive when computing the N value for the ACR
> packet - we can instead calculate the multiplier prior to our switch()
> based lookup, and multiply the N value appropriately afterwards.
>
> Signed-off-by: Russ
On 03.09.2015 14:30, Yakir Yang wrote:
> Hi Krzysztof,
>
> å¨ 09/03/2015 08:58 AM, Krzysztof Kozlowski åé:
>> On 01.09.2015 14:49, Yakir Yang wrote:
>>> Split the dp core driver from exynos directory to bridge
>>> directory, and rename the core driver to analogix_dp_*,
>>> leave the platform
On 01.09.2015 15:07, Yakir Yang wrote:
Empty commit message. Please explain here why you want to add platform
device type support.
Actually the title is confusing. You are not adding support for platform
device types but rather adding a field containing type of device.
> Signed-off-by: Yakir Ya
On Fri, Sep 04, 2015 at 01:05:35PM +0900, Inki Dae wrote:
> Hi Gustavo,
>
> I had already a review but I didn't give any comment to you. Sorry about
> that. This patch looks good to me but one thing isn't clear. Below is my
> comment.
>
>
> On 2015ë
09ì 04ì¼ 05:14, Gustavo Padovan wrote:
>
On Thu, Sep 03, 2015 at 10:49:34AM -0700, Rafael Antognolli wrote:
> Hi, I'm back from vacation, so I'll be looking at this again.
>
> On Thu, Aug 20, 2015 at 04:26:42PM -0700, Rafael Antognolli wrote:
> > On Mon, Aug 17, 2015 at 10:02:04AM +0300, Jani Nikula wrote:
> > > On Fri, 14 Aug 2015, Rafa
h a way to negotiate this with
userspace, that should be a generic solution.
--
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/a
62 matches
Mail list logo
