e ?
>
i915 working only if I compile kernel without acpi video dell-
laptop support (distributions compile kernel with these drivers)
and i915 is not good for usage. First it provides more then
thousand brightness levels and lot of (with low numbers)
completely turn display off. And if userspace map these thousand
levels into 5-10 levels (as nobody want to press brightness key
up/down 1000x) two lowest levels cause display off. With acpi
video and dell-laptop driver levels are mapped into small level
space in perfect way. So this is reason I want to use dell-laptop
for controlling brightness.
> Regards,
>
> Hans
--
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/20140923/171c20c9/attachment.sig>
Hi,
On 09/23/2014 10:06 PM, Pali Roh?r wrote:
> Hello,
>
> after big changes in acpi video/i915 code I cannot change display
> brightness on my Dell Latitude E6440 with kernel 3.17-rc6. With
> kernel 3.13 everything worked fine.
>
> More information about this problem:
>
> For configuring
://lists.freedesktop.org/archives/dri-devel/attachments/20140923/0a6d3d30/attachment-0001.sig>
On Mon, Sep 22, 2014 at 5:20 PM, C Bergstr?m
wrote:
> For clarity - My testing and the patch is required when the Intel driver
> isn't being used at all. After I finish some other testing I can see if
> bumblebee and intel driver + this patch will play nicely.
>
> How is a laptop with dual VGA
with Mesa/Mesa32, so I can't
test for certain right 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/20140923/25a0c
see df8fbc231b7e4a78dae2b02e116fe73e4ea63cb0
Signed-off-by: Stefan Br?ns
---
drivers/gpu/drm/i915/intel_dp.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fdff1d4..dafb169 100644
---
On Tue, Sep 23, 2014 at 9:56 AM, Rob Clark wrote:
> On Tue, Sep 23, 2014 at 4:47 AM, cym wrote:
>>
>> On Tuesday, September 23, 2014 03:20 AM, Rob Clark wrote:
>>>
>>> On Mon, Sep 22, 2014 at 7:02 AM, Mark yao
>>> wrote:
This adds support for Rockchip soc edp found on rk3288
On Tue, Sep 23, 2014 at 12:41:56PM -0300, Gustavo Padovan wrote:
> 2014-09-23 Ville Syrj?l? :
>
> > On Mon, Sep 22, 2014 at 07:23:10PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Move checks inside intel_crtc_cursor_set_obj() to
> > > intel_check_cursor_plane(), we
etter than
fbdev, which has nothing. But it's not good in the sense that it's not
what I'd design if I could start from scratch.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/392e26a0/attachment-0001.sig>
lvds-panel = <>;
>>> dsi-panel = <>;
>>> };
>>
>> Nothing says the bridge is connected to a panel, so "output" or such
>> would probably be better there.
>
> Hmm? How does the above not say that the bridge is connected to a panel?
Sorry, let me rephrase: nothing says the bridge must be connected to a
panel. The bridge could be connected to another encoder on some board.
And I don't think the bridge should know or care what kind of device it
is connected to.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/943d3ebd/attachment-0001.sig>
On Mon, 22 September 2014 Linus Torvalds
wrote:
> Adding proper people and mailing lists..
>
> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> appropriate, but hopefully somebody does. The fact that it makes
>
Hi Guennadi,
On Tue, 23 Sep 2014 14:33:20 +0200 (CEST)
Guennadi Liakhovetski wrote:
> Hi Boris,
>
> On Tue, 22 Jul 2014, Boris BREZILLON wrote:
>
> > Rename mediabus formats and move the enum into a separate header file so
> > that it can be used by DRM/KMS subsystem without any reference to
The tables:
* supported_devices_connector_convert
* supported_devices_connector_object_id_convert
* object_connector_convert
are used in redeon_atombios.c only, so declare them as static.
Signed-off-by: Michele Curti
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
legacy_connector_convert is used in radeon_combios.c only, so declare it as
static.
Signed-off-by: Michele Curti
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 6651177..3e5f6b7 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++
On Tue, Sep 23, 2014 at 11:53:53PM +0200, David Herrmann wrote:
> Hi
>
> On Tue, Sep 23, 2014 at 11:38 PM, Jerome Glisse wrote:
> > On Tue, Sep 23, 2014 at 03:46:47PM +0200, Daniel Vetter wrote:
> >> Really, the legacy buffer api should be dead, especially for all these
> >> newfangled drivers.
On Tue, Sep 23, 2014 at 03:46:47PM +0200, Daniel Vetter wrote:
> Really, the legacy buffer api should be dead, especially for all these
> newfangled drivers. I suspect this is copypasta from the transitioning
> days, which probably originated in radeon.
>
> Cc: David Airlie
> Cc: Alex Deucher
>
Am 23.09.2014 um 15:46 schrieb Daniel Vetter:
> Really, the legacy buffer api should be dead, especially for all these
> newfangled drivers. I suspect this is copypasta from the transitioning
> days, which probably originated in radeon.
>
> Cc: David Airlie
> Cc: Alex Deucher
> Cc: "Christian
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/20140923/e95b336f/attachment-0001.sig>
aining to it stored in C code. Extremes are
> never good, we need to find a reasonable middle-ground here. I believe OF
> graph fulfills that requirement, it might be slightly more verbose than a
> single phandle, but it's also much more versatile.
Oh well, yet another one of these things where we'll never reach an
agreement I guess.
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/20140923/ca283220/attachment.sig>
atural in my opinion.
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/20140923/5e8911df/attachment.sig>
On Tuesday, September 23, 2014 03:20 AM, Rob Clark wrote:
> On Mon, Sep 22, 2014 at 7:02 AM, Mark yao wrote:
>> This adds support for Rockchip soc edp found on rk3288
>>
>> Signed-off-by: Mark Yao
>> Signed-off-by: Jeff Chen
>> ---
>> Changes in v2:
>> - fix code sytle
>> - use some define
mux, albeit maybe a virtual one.
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/20140923/c6d6149e/attachment.sig>
require the backlight to be adjustable, bridges don't.
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/20140923/38663124/attachment.sig>
VDS with just the
connector abstraction and it all just works. That makes it a pretty
good abstraction in my book.
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/20140923/6105f1cf/attachment-0001.sig>
bridge {
> > panels = < >;
> > };
> >
> > Alternatively:
> >
> > bridge {
> > lvds-panel = <>;
> > dsi-panel = <>;
> > };
>
> Nothing says the bridge is connected to a panel, so "output" or such
> would probably be better there.
Hmm? How does the above not say that the bridge is connected to a panel?
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/20140923/b32c1a4e/attachment.sig>
On Tue, Sep 23, 2014 at 04:22:55PM +0200, David Herrmann wrote:
> Hi
>
> On Tue, Sep 23, 2014 at 3:46 PM, Daniel Vetter
> wrote:
> > Only !P can be used together with a function list.
>
> You say !P, but you use !F?
Oops yeah this should read !F. !P is for including DOC: sections, dunno
why
Op 23-09-14 om 07:35 schreef Ben Skeggs:
> On Tue, Sep 23, 2014 at 2:23 AM, Ted Percival wrote:
>> 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).
>>>
>>> The fence sequence
Hi
On Tue, Sep 23, 2014 at 3:46 PM, Daniel Vetter
wrote:
> So the main part here is the extraction of drm_gem.h. With a bit of prep work
> to
> ditch the legacy mmap stuff out of gem/ttm drivers. Plus a few random pieces
> of
> leftover cleanup that I've missed in my earlier header rework or
Hi
On Tue, Sep 23, 2014 at 3:46 PM, Daniel Vetter
wrote:
> Only !P can be used together with a function list.
You say !P, but you use !F?
Thanks
David
> Cc: Ville Syrj?l?
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl | 2 +-
> 1 file changed, 1 insertion(+), 1
On Tuesday 23 September 2014 03:52:48 C Bergstr?m wrote:
> Here's where I originally found it
> https://github.com/Bumblebee-Project/Bumblebee/issues/159
> (Adding Peter to cc chain)
>
> I guess there's already a bug id and some (snarky?) comments
>
Hi
On Tue, Sep 23, 2014 at 3:46 PM, Daniel Vetter
wrote:
> v2: Don't forget git add, noticed by David.
>
> Cc: David Herrmann
Acked-by: David Herrmann
Thanks
David
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/armada/armada_gem.h | 2 +
> drivers/gpu/drm/ast/ast_drv.h
On Tue, Sep 23, 2014 at 04:15:05PM +0200, David Herrmann wrote:
> Hi
>
> On Tue, Sep 23, 2014 at 3:46 PM, Daniel Vetter
> wrote:
> > Leftover from my previous header cleanup.
> >
> > This depends upon the patch to rework exynos mmap support, otherwise
> > it'll break exynos.
>
> What patch do
Hi
On Tue, Sep 23, 2014 at 3:46 PM, Daniel Vetter
wrote:
> In my header cleanup I've missed the debugfs functions completely.
I'd actually prefer a drm_debugfs.h, but I have some local patches
that refactor drm-debugfs stuff, anyway. So I can do it later myself:
Reviewed-by: David Herrmann
Hi
On Tue, Sep 23, 2014 at 3:46 PM, Daniel Vetter
wrote:
> Somehow I've missed these three, fix this up asap. Plus move
> drm_master_create since while at it.
s/since//
Reviewed-by: David Herrmann
Thanks
David
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_internal.h | 9
Hi Thierry,
On Tue, 23 Sep 2014 16:04:40 +0200
Thierry Reding wrote:
> On Tue, Jul 22, 2014 at 02:23:45PM +0200, Boris BREZILLON wrote:
> > Add bus_formats and nbus_formats fields and
> > drm_display_info_set_bus_formats helper function to specify the bus
> > formats supported by a given
On 23/09/14 15:51, Daniel Vetter wrote:
> On Tue, Sep 23, 2014 at 03:48:25PM +0300, Jani Nikula wrote:
>> On Mon, 15 Sep 2014, Daniel Vetter wrote:
>>> On Sat, Sep 13, 2014 at 06:25:54PM +0200, Mario Kleiner wrote:
The current drm-next misses Ville's original Patch 14/19, the one i first
Hi
On Tue, Sep 23, 2014 at 3:46 PM, Daniel Vetter
wrote:
> Leftover from my previous header cleanup.
>
> This depends upon the patch to rework exynos mmap support, otherwise
> it'll break exynos.
What patch do you mean? I cannot see any users of drm_vm_open_locked()
anywhere besides drm_gem.c
Hi Thierry,
On Tue, 23 Sep 2014 16:06:13 +0200
Thierry Reding wrote:
> On Tue, Jul 22, 2014 at 02:23:47PM +0200, Boris BREZILLON wrote:
> > Foxlink's fl500wvr00-a0t supports RGB888 format.
> >
> > Signed-off-by: Boris BREZILLON
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 1 +
> > 1
Hi
On Tue, Sep 23, 2014 at 3:46 PM, Daniel Vetter
wrote:
> Now that we've removed the copypasted users in gem/ttm we can
> relegate the legacy buffer mapping support to where it belongs.
> Also give it the proper drm_legacy_ prefix.
>
> While at it statify drm_mmap_locked, somehow I've missed
Hi
On Tue, Sep 23, 2014 at 3:46 PM, Daniel Vetter
wrote:
> The only user I could dig out was i915 back when ums+gem was still a
> thing. But we've just very much killed that, and even when someone
> screams about that we should resurrect that with a special hack
> (wrapping drm_gem_mmap) in
rubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/d26f970a/attachment.sig>
Hi
On Tue, Sep 23, 2014 at 3:46 PM, Daniel Vetter
wrote:
> Really, the legacy buffer api should be dead, especially for all these
> newfangled drivers. I suspect this is copypasta from the transitioning
> days, which probably originated in radeon.
>
> Cc: David Airlie
> Cc: Alex Deucher
> Cc:
at *bus_formats;
> + int nbus_formats;
unsigned int here too, please.
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/20140923/eb3115e2/attachment.sig>
On Mon, 22 Sep 2014, Joe Perches wrote:
> The return value is not used by callers of this function
> nor by uses of the DRM_ERROR macro so change the function
> to return void.
>
> Signed-off-by: Joe Perches
Reviewed-by: Jani Nikula
> ---
> This change is associated to a desire to eventually
On 2014?09?23? 15:48, Daniel Vetter wrote:
> On Mon, Sep 22, 2014 at 09:32:19AM +0800, Mark yao wrote:
>> On 2014?09?20? 08:03, Rob Clark wrote:
>>> On Fri, Sep 19, 2014 at 1:47 AM, Mark yao
>>> wrote:
diff --git a/include/uapi/drm/rockchip_drm.h
b/include/uapi/drm/rockchip_drm.h
On Tue, Sep 23, 2014 at 04:00:44PM +0300, Jani Nikula wrote:
> On Mon, 22 Sep 2014, Joe Perches wrote:
> > The return value is not used by callers of this function
> > nor by uses of the DRM_ERROR macro so change the function
> > to return void.
> >
> > Signed-off-by: Joe Perches
>
>
On Tue, Sep 23, 2014 at 03:48:25PM +0300, Jani Nikula wrote:
> On Mon, 15 Sep 2014, Daniel Vetter wrote:
> > On Sat, Sep 13, 2014 at 06:25:54PM +0200, Mario Kleiner wrote:
> >> The current drm-next misses Ville's original Patch 14/19, the one i first
> >> objected, then objected to my objection.
On Mon, 15 Sep 2014, Daniel Vetter wrote:
> On Sat, Sep 13, 2014 at 06:25:54PM +0200, Mario Kleiner wrote:
>> The current drm-next misses Ville's original Patch 14/19, the one i first
>> objected, then objected to my objection. It is needed to avoid actual
>> regressions. Attached a trivially
Only !P can be used together with a function list.
Cc: Ville Syrj?l?
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index
v2: Don't forget git add, noticed by David.
Cc: David Herrmann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_gem.h | 2 +
drivers/gpu/drm/ast/ast_drv.h | 2 +
drivers/gpu/drm/bochs/bochs.h | 2 +
drivers/gpu/drm/cirrus/cirrus_drv.h | 2 +
In my header cleanup I've missed the debugfs functions completely.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_internal.h | 28
include/drm/drmP.h | 25 -
2 files changed, 28 insertions(+), 25 deletions(-)
diff --git
Somehow I've missed these three, fix this up asap. Plus move
drm_master_create since while at it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_internal.h | 9 +
include/drm/drmP.h | 7 ---
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git
Leftover from my previous header cleanup.
This depends upon the patch to rework exynos mmap support, otherwise
it'll break exynos.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_internal.h | 1 +
drivers/gpu/drm/drm_vm.c | 1 -
include/drm/drmP.h | 1 -
3 files changed,
Now that we've removed the copypasted users in gem/ttm we can
relegate the legacy buffer mapping support to where it belongs.
Also give it the proper drm_legacy_ prefix.
While at it statify drm_mmap_locked, somehow I've missed that in my
previous header rework.
Signed-off-by: Daniel Vetter
---
The only user I could dig out was i915 back when ums+gem was still a
thing. But we've just very much killed that, and even when someone
screams about that we should resurrect that with a special hack
(wrapping drm_gem_mmap) in i915, not in the core code.
So good riddance to another entry point of
Really, the legacy buffer api should be dead, especially for all these
newfangled drivers. I suspect this is copypasta from the transitioning
days, which probably originated in radeon.
Cc: David Airlie
Cc: Alex Deucher
Cc: "Christian K?nig"
Cc: David Herrmann
Cc: Rashika
Cc: Josh Triplett
So the main part here is the extraction of drm_gem.h. With a bit of prep work to
ditch the legacy mmap stuff out of gem/ttm drivers. Plus a few random pieces of
leftover cleanup that I've missed in my earlier header rework or just stumbled
over while working on this.
With this drmP.h really
It seems good to me.
For the serie
Reviewed-by: Alexandre Demers
For for 1 and 5
Tested-by: Alexandre Demers on kernel 3.17-rc6
On Tue, Sep 23, 2014 at 9:52 AM, Alex Deucher wrote:
> On Tue, Sep 23, 2014 at 1:08 AM, Alexandre Demers
> wrote:
>> Typo: this should be "Tested on kernel
On Tue, Sep 23, 2014 at 2:23 AM, Ted Percival wrote:
> 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).
>>
>> The fence sequence should not be reset after creation, the old value
ally implemented as DRM CRTC
> object and outputs (DSI, eDP, HDMI) as encoder (often with a connector
> tied to it).
Ok. Thanks for the clarifications.
Tomi
------ next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/5596e299/attachment-0001.sig>
On 2014?09?22? 23:54, Arnd Bergmann wrote:
> On Monday 22 September 2014 17:15:06 Boris BREZILLON wrote:
+
+ /* TODO(djkurtz): fetch the mapping start/size from somewhere */
+ mapping = arm_iommu_create_mapping(_bus_type, 0x1000,
+
On 2014?09?22? 22:43, Arnd Bergmann wrote:
> On Monday 22 September 2014 18:48:54 Mark yao wrote:
>> diff --git a/drivers/gpu/drm/rockchip/Kconfig
>> b/drivers/gpu/drm/rockchip/Kconfig
>> new file mode 100644
>> index 000..7146c80
>> --- /dev/null
>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>>
--- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/83cc7267/attachment-0001.sig>
On Tuesday 23 September 2014 13:47:40 Andrzej Hajda wrote:
> On 09/23/2014 01:23 PM, Laurent Pinchart wrote:
> > On Tuesday 23 September 2014 13:18:30 Andrzej Hajda wrote:
> >> On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
> >>> On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
>
On 2014?09?23? 03:10, Rob Clark wrote:
> Ok, couple more small comments.. this time I actually had time to go
> through the entire patch, not just the uapi
>
>
> On Mon, Sep 22, 2014 at 6:48 AM, Mark yao wrote:
>> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>>
>>
Hi Thierry,
On Tuesday 23 September 2014 07:55:34 Thierry Reding wrote:
> On Tue, Sep 23, 2014 at 03:00:37AM +0300, Laurent Pinchart wrote:
> > On Monday 22 September 2014 13:35:15 Thierry Reding wrote:
> >> On Mon, Sep 22, 2014 at 04:53:22PM +0530, Ajay kumar wrote:
> >>> On Mon, Sep 22, 2014 at
On 09/23/2014 01:52 PM, Laurent Pinchart wrote:
> On Tuesday 23 September 2014 13:47:40 Andrzej Hajda wrote:
>> On 09/23/2014 01:23 PM, Laurent Pinchart wrote:
>>> On Tuesday 23 September 2014 13:18:30 Andrzej Hajda wrote:
On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
> On Tuesday 23
Hi Thierry,
On Tuesday 23 September 2014 12:10:33 Thierry Reding wrote:
> On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote:
> > On 09/23/2014 10:35 AM, Thierry Reding wrote:
> [...]
>
> > > But I agree that it would be nice to unify bridges and encoders more. It
> > > should be
Hi Boris,
On Tue, 22 Jul 2014, Boris BREZILLON wrote:
> Rename mediabus formats and move the enum into a separate header file so
> that it can be used by DRM/KMS subsystem without any reference to the V4L2
> subsystem.
>
> Old V4L2_MBUS_FMT_ definitions are now macros that points to
non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/e8b08e9e/attachment-0001.sig>
On Tuesday 23 September 2014 13:18:30 Andrzej Hajda wrote:
> On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
> > On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
> >> On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
> >>> On 23/09/14 09:21, Thierry Reding wrote:
> > Well, I can write
e easier to read. Then again, it's simple to add /*
lvds */ comment on the full graph for clarity.
Also, I don't know if anything stops us from naming "port at 0" to "lvds".
All the sub-nodes of "ports" are ports, so it's implicit. But then
again, I don't see that really buying much, as a simple comment does the
trick also.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/41e4d77b/attachment-0001.sig>
On Tuesday 23 September 2014 11:53:15 Thierry Reding wrote:
> On Tue, Sep 23, 2014 at 12:30:20PM +0300, Tomi Valkeinen wrote:
> > On 23/09/14 09:21, Thierry Reding wrote:
> > >> Well, I can write almost any kind of bindings, and then evidently my
> > >> device would work. For me, on my board.
> >
On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
> On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
> > On 23/09/14 09:21, Thierry Reding wrote:
> >>> Well, I can write almost any kind of bindings, and then evidently my
> >>> device would work. For me, on my board.
> >>
> >> Well, that's
On 2014?09?22? 21:24, Boris BREZILLON wrote:
> Hi Mark,
>
> You'll find some comments inline.
> Anyway, I wouldn't call it a review (your driver is using some concepts
> I'm not used to, like IOMMUs) but rather a collection of nitpicks :-).
>
> I haven't been through the whole driver yet, but I'll
On 09/23/2014 01:23 PM, Laurent Pinchart wrote:
> On Tuesday 23 September 2014 13:18:30 Andrzej Hajda wrote:
>> On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
>>> On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
> On 23/09/14 09:21,
vel/attachments/20140923/abaa9973/attachment.html>
On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
> On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
>> On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
>>> On 23/09/14 09:21, Thierry Reding wrote:
> Well, I can write almost any kind of bindings, and then evidently my
> device would
https://bugzilla.kernel.org/show_bug.cgi?id=85021
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1
ail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/b47ffd49/attachment.html>
2014-09-23 Ville Syrj?l? :
> On Mon, Sep 22, 2014 at 07:23:10PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Move checks inside intel_crtc_cursor_set_obj() to
> > intel_check_cursor_plane(), we only use they there so move them out to
> > make the merge of
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/bdd45983/attachment-0001.sig>
On 09/23/2014 12:10 PM, Thierry Reding wrote:
> On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote:
>> On 09/23/2014 10:35 AM, Thierry Reding wrote:
> [...]
>>> But I agree that it would be nice to unify bridges and encoders more. It
>>> should be possible to make encoder always a
the drivers we end up
always going the links the other way, the performance penalty may be
somewhat big. (If I recall right).
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/e60657b3/attachment-0001.sig>
ces, so the gain seems
rather minimal.
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/20140923/d6bc8343/attachment-0001.sig>
On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
> On 23/09/14 09:21, Thierry Reding wrote:
>
>>> Well, I can write almost any kind of bindings, and then evidently my
>>> device would work. For me, on my board.
>>
>> Well, that's the whole problem with DT. For many devices we only have a
>> single
, eDP, HDMI) as encoder (often with a connector
tied to it).
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/20140923/edeacdd9/attachment.sig>
Hi Thierry,
On 23/09/2014 10:42, Thierry Reding :
> On Tue, Sep 23, 2014 at 09:24:36AM +0200, Boris BREZILLON wrote:
>> Hi Thierry,
>>
>> On Tue, 23 Sep 2014 08:32:33 +0200
>> Thierry Reding wrote:
>>
>>> On Mon, Sep 22, 2014 at 09:18:11PM +0200, Boris BREZILLON wrote:
On Mon, 8 Sep 2014
-
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/2ad7c64b/attachment-0001.sig>
er second).
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/20140923/9f458a14/attachment.sig>
On 09/23/2014 10:35 AM, Thierry Reding wrote:
> On Tue, Sep 23, 2014 at 09:24:12AM +0200, Andrzej Hajda wrote:
>> Hi Thierry, Tomi,
>>
>> On 09/23/2014 08:04 AM, Thierry Reding wrote:
>>> On Mon, Sep 22, 2014 at 05:23:25PM +0300, Tomi Valkeinen wrote:
On 22/09/14 11:06, Thierry Reding wrote:
vice specific custom descriptions if there's a very important reason
for that. And I can't come up with any reason.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/588c734b/attachment-0001.sig>
On Tue, Sep 23, 2014 at 11:25 AM, Thierry Reding
wrote:
> On Tue, Sep 23, 2014 at 03:00:37AM +0300, Laurent Pinchart wrote:
>> On Monday 22 September 2014 13:35:15 Thierry Reding wrote:
>> > On Mon, Sep 22, 2014 at 04:53:22PM +0530, Ajay kumar wrote:
>> > > On Mon, Sep 22, 2014 at 4:11 PM,
ter to represent it at least as a virtual mux or bridge, or
perhaps a "mux panel".
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/20140923/d1b217ac/attachment-0001.sig>
panel = <>;
};
dsi {
panel = <>;
};
};
While it's true that it'd be more difficult to parse that in a generic
way I also think it's a whole lot more readable than some abstract graph
where a lot of context is simply lost.
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/20140923/0b833cf3/attachment.sig>
On Tue, Sep 23, 2014 at 9:46 AM, Daniel Vetter
wrote:
> So the main part here is the extraction of drm_gem.h. With a bit of prep work
> to
> ditch the legacy mmap stuff out of gem/ttm drivers. Plus a few random pieces
> of
> leftover cleanup that I've missed in my earlier header rework or just
On Mon, Sep 22, 2014 at 07:23:10PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Move checks inside intel_crtc_cursor_set_obj() to
> intel_check_cursor_plane(), we only use they there so move them out to
> make the merge of intel_crtc_cursor_set_obj() into
>
On Mon, Sep 22, 2014 at 07:23:09PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Now that universal planes are in place we don't need this plane unref on
> failures.
>
> Suggested-by: Ville Syrj?l?
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/i915/intel_display.c | 8
On Mon, Sep 22, 2014 at 07:23:08PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Fold intel_pipe_set_base() in the update primary plane path merging
> pieces of code that are common to both paths.
>
> Basically the the pin/unpin procedures are the same for both paths
> and some
think that's wrong but I don't care enough to object.
> Now that I have your attention :-), could you review this series [1] ?
> The HLCDC KMS depends on those changes (which you and Laurent
> suggested).
My attention span tends to be very short these days. No promises. =)
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/20140923/5023e006/attachment-0001.sig>
1 - 100 of 130 matches
Mail list logo
