Hi Mark,
Please review comments inline...
On Wed, Sep 24, 2014 at 10:12 AM, Mark yao wrote:
> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>
> Signed-off-by: Mark yao
> ---
> Changes in v2:
> - use the component framework to defer main drm driver probe
> until all VO
On 25 September 2014 03:59, Daniel Vetter wrote:
> On Wed, Sep 24, 2014 at 6:24 PM, Ilia Mirkin wrote:
>> On Wed, Sep 24, 2014 at 6:24 AM, Daniel Vetter
>> wrote:
>>> Hi Dave,
>>>
>>> Just noticed that you've picked up the header rework stuff already, so
>>> I've rebased that out again. Otherwi
t; Hi, Daniel
>> this version is old, newest is v5. and I remove uapi at v5.
>> you can see v5 patch at:
>> https://lkml.org/lkml/2014/9/23/1061
>> thanks
> This version doesn't seem to be cc'ed to dri-devel, at least it didn't
> yet show up. Can you please double-check?
actually I cc the v5 version to dri-devel at lists.freedesktop.org.
and we can found the patch at
https://patchwork.kernel.org/patch/4967501/( *Project*: dri-devel)
>
> Thanks, Daniel
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/060a90f3/attachment-0001.html>
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/ac79655c/attachment.html>
e order. (This means that on little endian hosts such as x86, the
datum is transferred unchanged)
--
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
Hi Hans,
Thanks for following up and explaining the situation to Pali.
On 09/25/2014 02:21 AM, Pali Roh?r wrote:
> On Wednesday 24 September 2014 16:34:21 Hans de Goede wrote:
>> Ok, so the dell-laptop interface is just an obsolete wrapper
>> around the i915 opregion code, which shows that the ri
that a panel can be connected to. I think it
makes a lot of sense to describe things in the same way in DT.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/51dcebb2/attachment.sig>
Hi Laurent,
On Wed, Sep 24, 2014 at 10:04 PM, Laurent Pinchart
wrote:
> +- adi,input-style: The input components arrangement variant (1, 2 or 3).
What's the meaning of the numerical values 1, 2, and 3?
I found this code in "[PATCH 11/12] drm: Add adv7511 encoder driver":
+ input_style =
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/2be8444d/attachment-0001.html>
On Sun, Aug 24, 2014 at 4:50 PM, Daniel Kurtz wrote:
> Commit [0] stopped setting fix.smem_start and fix.smem_len when creating
> the fbdev.
>
> [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3
> drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}
>
> However, smem_len is used by some userland app
Op 17-09-14 om 15:09 schreef Christian K?nig:
> Am 17.09.2014 um 14:35 schrieb Maarten Lankhorst:
>> Not the whole world is a radeon! :-)
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/radeon/cik.c | 2 +-
>> drivers/gpu/drm/radeon/cik_sdma.c | 2 +-
>>
Hi Geert,
On Thursday 25 September 2014 09:06:46 Geert Uytterhoeven wrote:
> Hi Laurent,
>
> On Wed, Sep 24, 2014 at 10:04 PM, Laurent Pinchart
>
> wrote:
> > +- adi,input-style: The input components arrangement variant (1, 2 or 3).
>
> What's the meaning of the numerical values 1, 2, and 3?
>
On Thu, Sep 25, 2014 at 5:32 PM, Geert Uytterhoeven
wrote:
> On Sun, Aug 24, 2014 at 4:50 PM, Daniel Kurtz wrote:
>> Commit [0] stopped setting fix.smem_start and fix.smem_len when creating
>> the fbdev.
>>
>> [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3
>> drm/exynos/fbdev: don't set fix.smem/
Hi Laurent,
On Thu, Sep 25, 2014 at 11:57 AM, Laurent Pinchart
wrote:
> On Thursday 25 September 2014 09:06:46 Geert Uytterhoeven wrote:
>> On Wed, Sep 24, 2014 at 10:04 PM, Laurent Pinchart
>> wrote:
>> > +- adi,input-style: The input components arrangement variant (1, 2 or 3).
>>
>> What's the
On Thu, Sep 25, 2014 at 12:07 PM, Daniel Kurtz wrote:
> On Thu, Sep 25, 2014 at 5:32 PM, Geert Uytterhoeven
> wrote:
>> On Sun, Aug 24, 2014 at 4:50 PM, Daniel Kurtz
>> wrote:
>>> Commit [0] stopped setting fix.smem_start and fix.smem_len when creating
>>> the fbdev.
>>>
>>> [0] 2f1eab8d8ab59e7
Not the whole world is a radeon! :-)
Signed-off-by: Maarten Lankhorst
---
Changes:
- Removed interruptible parameter, only 1 place has a use for it,
and it's the only place that can hit it.
- Fail faster in radeon_semaphore_sync_resv.
- Make the break on error in radeon_cs.c more explicit.
- Up
Hi Laurent,
Am Mittwoch, den 24.09.2014, 23:04 +0300 schrieb Laurent Pinchart:
> Hello,
>
> This patch set adds support for the HDMI output port present on the Renesas
> Koelsch board. Doing so requires two components, a driver for the external
> ADV7511W HDMI encoder, and support for HDMI encode
ving 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/20140925/f510811c/attachment.html>
ext part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/e0810964/attachment-0001.html>
. . 0 24 8 16 16 16 0 0 0 Slow
--
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/20140925/11080996/attachment-0001.html>
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/b8fe62ad/attachment.html>
On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> Playing a bit with todays linux-next on my jetson, it seems this patch is
> still required for enabling the GPU. Is there anything blocking it (firmware
> not available yet in liux-firmware?)
I think initially I was waiting for the DRM patch "drm/nouv
Hi Dave,
please pull these fixes for the IPUv3 core driver.
The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
are available in the git repository at:
git://git.pengutronix.de/git/pza/linux.git tags/ipu-fixes-3.18
for yo
;s set up the VPR and disable it otherwise?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/907d4902/attachment.sig>
I have been doing a lot of work with LibDRM, including Multi-Monitor work on
Intel and VMWare. Do you guy?s know if there is an easy way to tell VMWare to
add more virtual display?s for testing? LibDRM reports something like 8
different connectors, and several CRTCs, so I know it at least suppor
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/80d14732/attachment.html>
re 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/20140925/94c5c961/attachment.html>
On 09/25/2014 10:41 AM, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
>> On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
>>> Playing a bit with todays linux-next on my jetson, it seems this patch is
>>> still required for enabling the GPU. Is there anything bl
ng. Append
radeon.dpm=0 to the kernel command line in grub.
--
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/20140925/f2abd821/attachment.html>
On 24/09/14 23:45, Oded Gabbay wrote:
> This patch adds the interface between the radeon driver and the amdkfd driver.
> The interface implementation is contained in radeon_kfd.c and radeon_kfd.h.
>
> The interface itself is represented by a pointer to struct
> kfd_dev. The pointer is located in
After several days uptime with a 3.16 kernel (generally running
Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
desktop workspaces) I've been seeing some really extreme slowdowns.
Mostly the slowdowns are associated with gpu-related tasks, like
opening new emacs windows, switchi
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/05748620/attachment.html>
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/2a9d2d79/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/73530568/attachment.html>
Hey,
On 25-09-14 20:55, Peter Hurley wrote:
> After several days uptime with a 3.16 kernel (generally running
> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
> desktop workspaces) I've been seeing some really extreme slowdowns.
>
> Mostly the slowdowns are associated with gpu
On Thu, Sep 25, 2014 at 2:55 PM, Peter Hurley
wrote:
> After several days uptime with a 3.16 kernel (generally running
> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
> desktop workspaces) I've been seeing some really extreme slowdowns.
>
> Mostly the slowdowns are associated
On 09/25/2014 02:55 PM, Peter Hurley wrote:
> After several days uptime with a 3.16 kernel (generally running
> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
> desktop workspaces) I've been seeing some really extreme slowdowns.
>
> Mostly the slowdowns are associated with gpu-
s.
--
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/20140925/42367d73/attachment.html>
On 09/25/2014 04:33 PM, Alex Deucher wrote:
> On Thu, Sep 25, 2014 at 2:55 PM, Peter Hurley
> wrote:
>> After several days uptime with a 3.16 kernel (generally running
>> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
>> desktop workspaces) I've been seeing some really extreme
On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
> There are six ttm patches queued for 3.16.4:
>
> drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
> drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
> drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch
>
On Mon, Sep 8, 2014 at 4:43 AM, Boris BREZILLON
wrote:
> Hello,
>
> This patch series adds support for Atmel HLCDC (HLCD Controller) available
> on some Atmel SoCs (i.e. the sama5d3 family).
>
> The HLCDC actually provides a Display Controller and a PWM device, hence I
> decided to declare an MFD
This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices. Future patches will add additional encoders/connectors,
such as eDP, HDMI.
The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two s
pe .
>
> IMO, this is pretty useless and I'd rather not see them in the drivers I
> maintain, sorry.
It is not a NACK from me; yet from a high-level perspective I agree with
Felipe.
-- 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/archives/dri-devel/attachments/20140925/739eb5dd/attachment.sig>
On Wed, Sep 24, 2014 at 10:28:07PM +0200, Rafael J. Wysocki wrote:
>
> OK, I guess this is as good as it gets.
>
> What tree would you like it go through?
Since rest of the patches are dependent upon 1st patch which should go thru
your tree, we should merge this thru your tree
Thanks
--
~Vinod
chment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/9a878e2f/attachment-0001.sig>
This patch adds the basic structure of a DRM Driver for Rockchip Socs.
Signed-off-by: Mark yao
---
Changes in v2:
- use the component framework to defer main drm driver probe
until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
master dev
Playing a bit with todays linux-next on my jetson, it seems this patch is
still required for enabling the GPU. Is there anything blocking it (firmware
not available yet in liux-firmware?)
On Mon, May 19, 2014 at 06:24:10PM +0900, Alexandre Courbot wrote:
> Signed-off-by: Alexandre Courbot
> ---
>
e lines with
a function which takes almost as many characters to type .
IMO, this is pretty useless and I'd rather not see them in the drivers I
maintain, sorry.
cheers
--
balbi
-- 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/archives/dri-devel/attachments/20140925/99ac80ca/attachment-0001.sig>
On Thu, 2014-09-25 at 18:41 +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
> > On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> > >Playing a bit with todays linux-next on my jetson, it seems this patch is
> > >still required for enabling the GPU. Is the
On Thursday, September 25, 2014 04:27:58 PM Wolfram Sang wrote:
>
> --Bn2rw/3z4jIqBvZU
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Thu, Sep 25, 2014 at 09:22:01AM -0500, Felipe Balbi wrote:
> > On Thu, Sep 25, 201
With 3.17-rc1 DPMS stopped working. I've bisected this to
d55b4af909bc16f7982c2b8b8656f0898158627b testing along the way with
xset dpms force off. Controller is:
NVIDIA Corporation G86 [Quadro NVS 290] (rev a1)
That commit doesn't revert cleanly. I took a look around and found a
couple of bu
On 2014?09?25? 00:20, Daniel Kurtz wrote:
> Hi Mark,
>
> Please review comments inline...
>
> On Wed, Sep 24, 2014 at 10:12 AM, Mark yao wrote:
>> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>>
>> Signed-off-by: Mark yao
>> ---
>> Changes in v2:
>> - use the component f
This fix a GPU lockup on 9400M (NVAC) when using acceleration, see #27501.
Signed-off-by: Pierre Moreau
---
drivers/gpu/drm/nouveau/core/engine/disp/nv50.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
b/drivers/gpu/drm/nouveau/core
noaccel option now defaults to null which has no effect, it can still equal 1,
which disables acceleration for all cards, or be a pci address and disable
acceleration for that card only
Signed-off-by: Pierre Moreau
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 16 +++-
1 file changed,
lane, base->crtc always is NULL. and disable_plane will fail.
maybe we can add "base->crtc = crtc" at update_plane, but it seems not good.
so I think still use "rockchip_plane->ctx" would be better.
-Mark
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/09d7bd76/attachment-0001.html>
This add a display subsystem comprise the all display interface nodes.
Signed-off-by: Mark Yao
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
the graphics subsystem.
Changes in v3: None
Changes in v4: None
Changes in v5: None
Changes in v6: None
..
This adds binding documentation for Rockchip SoC VOP driver.
Signed-off-by: Mark Yao
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem
Changes in v3: None
Changes in v4: None
Changes in v5: None
Changes in v6: None
.../devicetree/b
her processing backlight level change requests
> from firmware. - */
> - if (!acpi_video_verify_backlight_support()) {
> + if (should_ignore_backlight_request()) {
> DRM_DEBUG_KMS("opregion backlight request ignored\n");
> return 0;
> }
--
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/8935d34d/attachment-0001.sig>
On Thu, Sep 25, 2014 at 2:54 AM, Mark yao wrote:
> Hi, Daniel
> this version is old, newest is v5. and I remove uapi at v5.
> you can see v5 patch at:
> https://lkml.org/lkml/2014/9/23/1061
> thanks
>
> This version doesn't seem to be cc'ed to dri-devel, at least it didn't
> yet show up. Can you p
On Thu, 25 Sep 2014 14:55:02 -0400
Peter Hurley wrote:
> After several days uptime with a 3.16 kernel (generally running
> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
> desktop workspaces) I've been seeing some really extreme slowdowns.
>
> Mostly the slowdowns are associa
On Thursday, September 25, 2014 11:15:35 AM Aaron Lu wrote:
> Hi Hans,
>
> Thanks for following up and explaining the situation to Pali.
>
> On 09/25/2014 02:21 AM, Pali Roh?r wrote:
> > On Wednesday 24 September 2014 16:34:21 Hans de Goede wrote:
> >> Ok, so the dell-laptop interface is just an
On 09/23/2014 08:24 AM, Maarten Lankhorst wrote:
> Op 23-09-14 om 07:35 schreef Ben Skeggs:
>>> On 09/22/2014 03:08 AM, Maarten Lankhorst wrote:
This fixes a regression introduced by "drm/nouveau: rework to new fence
interface"
(commit 29ba89b2371d466).
>>
>> I'm still seeing issues
On Tue, Sep 23, 2014 at 10:12 PM, Mark yao wrote:
> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>
> Signed-off-by: Mark yao
Looks like my comments are addressed, so:
Reviewed-by: Rob Clark
> ---
> Changes in v2:
> - use the component framework to defer main drm driv
Thanks,
- Ted
-- next part --
A non-text attachment was scrubbed...
Name: dmesg-repro.gz
Type: application/gzip
Size: 32179 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/6255d4d4/attachment-0001.bin>
omapdrm doesn't check if the pitch of the framebuffer and the color
format's bits-per-pixel are compatible. omapdss requires that the stride
of a buffer is an integer number of pixels
For example, when using modetest with a display that has x resolution of
1280, and using packed 24 RGB mode (3 byt
65 matches
Mail list logo
