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
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
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
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:
>
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>
_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>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/cc7abf73/attachment.html>
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.
>>
>>
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
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
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
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
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
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
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/cc8c57bf/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>
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>
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>
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>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/f719da7f/attachment.html>
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
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 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
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
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
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/c231ef48/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/08264c8d/attachment.html>
bbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/3f3d3117/attachment.html>
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>
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,
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
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
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
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
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
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_mixer.c | 125 +-
1 file changed, 6
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
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
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
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 | 89 ---
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/exynos7_drm_decon.c | 125 -
1 file changed, 5
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 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.
>>>
>
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
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
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/
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
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
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
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
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
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 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
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>
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
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 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 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
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
62 matches
Mail list logo
