https://bugs.freedesktop.org/show_bug.cgi?id=84140
--- Comment #21 from Marek Ol??k ---
The context should be fully initialized to do anything no matter what the user
API is, is that right, Christian?
The auxiliary context is for cases when you don't have any context around and
need to submit
ice itself did
> > > not expose its own backlight controlling circuitry if an external one
> > > was being used. But since the bridge has no business controlling the
> > > backlight, having the backlight phandle in the bridge is not correct.
> > >
> > > So I think what you could do in the driver instead is always expose the
> > > backlight device. If the panel used a different backlight, the PS8622's
> > > internal on simply wouldn't be accessed. It would still be possible to
> > > control the backlight in sysfs, but that shouldn't be a problem (only
> > > root can access it)
> >
> > That would be like simple exposing a feature which cannot be used
> > by the user, ideally which "should not be" used by the user.
>
> And it won't be used unless they access the sysfs files directly. There
> are a lot of cases where we expose functionality that cannot be
> meaningfully used by the user. For example, a GPIO may not be routed to
> anything on a board, yet we don't explicitly hide any specific GPIOs
> from users.
>
> > > That said, I have no strong objections to the boolean property if you
> > > feel like it's really necessary.
> >
> > Won't you think having a boolean property for an optional
> > feature of the device, is better than all these?
>
> Like I said, I'm indifferent on the matter. I don't think it's necessary
> to hide the backlight device, but if you want to, please feel free to do
> so.
DT typically use
status = "disabled"
to disable devices. In this case we don't want to disable the ps8622
completely, but just one of its functions. Maybe a "backlight-status" property
could be used for that ? If that's considered too verbose, I would be fine
with a "disable-" boolean property too.
> Another alternative would be not to expose it at all and not have the
> boolean property since you don't seem to have a way to test it in the
> first place (or at least there's no device support upstream where it's
> needed).
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/120398b0/attachment.sig>
forms using
> > > drm_bridge is increasing.
> >
> > That's exactly why I'd like to use the component framework now, as the
> > conversion will become more complex as time goes by.
>
> No it won't. If we ever do decide that component framework is a better
> fit then the conversion may be more work but it would still be largely
> mechanical.
Are you volunteering to perform the conversion ? :-)
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/ebf533d3/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=82551
--- Comment #12 from Javier Fernandez ---
Hello,
I?been away from home (holydays), today i have come back, and when booting
PC. again same problems.
I was using 3.16.0-14-lowlatency
i then upgraded to 3.16.0-16-lowlatency, with no success.
https://bugzilla.kernel.org/show_bug.cgi?id=85021
Bug ID: 85021
Summary: radeon: Allow one to set "mid" to
power_dpm_force_performance_level
Product: Drivers
Version: 2.5
Kernel Version: 3.16.2
Hardware: All
Now that vddci has been fixed for dpm, we can let the GPUs
use their maximum values when not using the reference ones.
Fixes bug 69721: Can't reach maximum memory speed (or core
speed) when using dpm=1 on r600g on cards not sticking to
reference board
Tested on kernel 3.17-rc7 on a cayman
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/d1bfff1b/attachment.html>
Typo: this should be "Tested on kernel 3.17-rc6 on..."
Alexandre Demers
On 23/09/14 12:42 AM, Alexandre Demers wrote:
> Now that vddci has been fixed for dpm, we can let the GPUs
> use their maximum values when not using the reference ones.
>
> Fixes bug 69721: Can't reach maximum memory speed
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
splay controller, in
> which case there's a dependency loop.
I don't see how component/master would solve that differently than the
current proposal for DRM bridge (or the existing DRM panel for that
matter).
> > > > Without this patchset, you cannot bring an X server based display on
> > > > snow and peach_pit. Also, day by day the number of platforms using
> > > > drm_bridge is increasing.
> > >
> > > That's exactly why I'd like to use the component framework now, as the
> > > conversion will become more complex as time goes by.
> >
> > No it won't. If we ever do decide that component framework is a better
> > fit then the conversion may be more work but it would still be largely
> > mechanical.
>
> Are you volunteering to perform the conversion ? :-)
No. I'm still convinced that we won't need it. Less work for everyone.
=)
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/c1ba15c0/attachment.sig>
rs is that you get a phandle
> > to the bridge. The job of the operating system is to give drivers a way
> > to resolve that phandle to some object and provide an API to access that
> > object.
>
> I agree it's not relevant whether we use a simple phandle or complex
> graph. What matter is that we have a standard way to express the video
> paths, which everybody uses.
Not necessarily. Consistency is always good, but I think simplicity
trumps consistency. What matters isn't how the phandle is referenced in
the device tree, what matters is that it is referenced and that it makes
sense in the context of the specific device. Anything else is the job of
the OS.
While there are probably legitimate cases where the video graph is
useful and makes sense, in many cases terms like ports and endpoints are
simply confusing.
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/4c62ebb0/attachment.sig>
lf did
> > > > not expose its own backlight controlling circuitry if an external one
> > > > was being used. But since the bridge has no business controlling the
> > > > backlight, having the backlight phandle in the bridge is not correct.
> > > >
> > > > So I think what you could do in the driver instead is always expose the
> > > > backlight device. If the panel used a different backlight, the PS8622's
> > > > internal on simply wouldn't be accessed. It would still be possible to
> > > > control the backlight in sysfs, but that shouldn't be a problem (only
> > > > root can access it)
> > >
> > > That would be like simple exposing a feature which cannot be used
> > > by the user, ideally which "should not be" used by the user.
> >
> > And it won't be used unless they access the sysfs files directly. There
> > are a lot of cases where we expose functionality that cannot be
> > meaningfully used by the user. For example, a GPIO may not be routed to
> > anything on a board, yet we don't explicitly hide any specific GPIOs
> > from users.
> >
> > > > That said, I have no strong objections to the boolean property if you
> > > > feel like it's really necessary.
> > >
> > > Won't you think having a boolean property for an optional
> > > feature of the device, is better than all these?
> >
> > Like I said, I'm indifferent on the matter. I don't think it's necessary
> > to hide the backlight device, but if you want to, please feel free to do
> > so.
>
> DT typically use
>
> status = "disabled"
>
> to disable devices. In this case we don't want to disable the ps8622
> completely, but just one of its functions. Maybe a "backlight-status"
> property
> could be used for that ? If that's considered too verbose, I would be fine
> with a "disable-" boolean property too.
Another alternative would be to make the backlight a subnode:
ps8622: bridge at ... {
compatible = "parade,ps8622";
...
backlight {
...
status = "disabled";
...
};
};
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/a9e55868/attachment-0001.sig>
at a different level then.
DT should describe the hardware and this particular bridge device simply
doesn't have a means to connect more than a single input or more than a
single output.
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/fe5e0667/attachment.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,
can easily be derived. The input for the second device will be the first
implicitly. No need to explicitly describe that in DT. Doing it
explicitly would be redundant.
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/5a5a6533/attachment.sig>
be the one to
> >> > control backlight. How else is the bridge supposed to know when to turn
> >> > backlight on or off?
> >> >
> >> > > > What you did in v6 of this series was look up a backlight device and
> >> > > > then not use it. That seemed unnecessary. Looking at v6 again the
> >> > > > reason
> >> > > > for getting a phandle to the backlight was so that the device itself
> >> > > > did
> >> > > > not expose its own backlight controlling circuitry if an external one
> >> > > > was being used. But since the bridge has no business controlling the
> >> > > > backlight, having the backlight phandle in the bridge is not correct.
> >> > > >
> >> > > > So I think what you could do in the driver instead is always expose
> >> > > > the
> >> > > > backlight device. If the panel used a different backlight, the
> >> > > > PS8622's
> >> > > > internal on simply wouldn't be accessed. It would still be possible
> >> > > > to
> >> > > > control the backlight in sysfs, but that shouldn't be a problem (only
> >> > > > root can access it)
> >> > >
> >> > > That would be like simple exposing a feature which cannot be used
> >> > > by the user, ideally which "should not be" used by the user.
> >> >
> >> > And it won't be used unless they access the sysfs files directly. There
> >> > are a lot of cases where we expose functionality that cannot be
> >> > meaningfully used by the user. For example, a GPIO may not be routed to
> >> > anything on a board, yet we don't explicitly hide any specific GPIOs
> >> > from users.
> >> >
> >> > > > That said, I have no strong objections to the boolean property if you
> >> > > > feel like it's really necessary.
> >> > >
> >> > > Won't you think having a boolean property for an optional
> >> > > feature of the device, is better than all these?
> >> >
> >> > Like I said, I'm indifferent on the matter. I don't think it's necessary
> >> > to hide the backlight device, but if you want to, please feel free to do
> >> > so.
> >>
> >> DT typically use
> >>
> >> status = "disabled"
> >>
> >> to disable devices. In this case we don't want to disable the ps8622
> >> completely, but just one of its functions. Maybe a "backlight-status"
> >> property
> >> could be used for that ? If that's considered too verbose, I would be fine
> >> with a "disable-" boolean property too.
> >
> > Another alternative would be to make the backlight a subnode:
> >
> > ps8622: bridge at ... {
> > compatible = "parade,ps8622";
> > ...
> >
> > backlight {
> > ...
> > status = "disabled";
> > ...
> > };
> In the above case, how do I query the status of backlight sub node in
> the driver?
Something like this should work:
struct device_node *np;
np = of_get_child_by_name(dev->of_node, "backlight");
if (np) {
if (of_device_is_available(np)) {
/* register backlight device */
}
of_node_put(np);
}
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/1d01d3db/attachment-0001.sig>
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
t
are user-visible because that can lead to issues.
What were the problems having this as "depends on"?
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/1e4fa501/attachment.sig>
ou need a reference here in order to do so, given it presumably
> doesn't feed directly into the DSI block?
It seems like the hardware default is to use a parent clock unsuitable
for the DSI low-power mode, but as discussed elsewhere this should be
fixed in the clock driver where we already have a way to statically set
the parent clock at boot time.
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/0b023b63/attachment.sig>
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:
>>
> Why do we need a complex graph when it can be handled using a simple
> phandle?
Maybe in your case
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 10:43:36 +0200 Boris BREZILLON > free-electrons.com> wrote:
> [...]
> > > diff --git a/drivers/gpu/drm/atmel-hlcdc/Kconfig
> > >
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
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 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 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
>
gether). Then once you're out of the
DRM device everything would be a bridge until you get to a panel.
I think we discussed this a while back in the context of bridge
chaining.
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/1987b87a/attachment.sig>
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>
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/20140923/c40fb431/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140923/65d067ac/attachment.html>
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>
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>
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:
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>
, 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>
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
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 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
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 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 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
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
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
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,
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 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:
>
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
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
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
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>
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
https://bugzilla.kernel.org/show_bug.cgi?id=85021
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1
vel/attachments/20140923/abaa9973/attachment.html>
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
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
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
---
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,
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
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
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 +
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.
6 vddc, vddci;
>> - u32 max_sclk_vddc, max_mclk_vddci, max_mclk_vddc;
>> int i;
>> if ((rdev->pm.dpm.new_active_crtc_count > 1) ||
>> @@ -2950,29 +2949,6 @@ static void si_apply_state_adjust_rules(struct
>> radeon_device *rdev,
>> }
>>
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
>
>
This should allow the audio driver to get a better
idea of whether the sink is connected or not.
v2: fix copy/paste typo noticed by David Henningsson
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 10 ++
drivers/gpu/drm/radeon/r600_hdmi.c | 5 +
2
Clean up the enable sequence as well.
V2: clean up duplicate defines
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 4 ++--
drivers/gpu/drm/radeon/dce6_afmt.c | 4 ++--
drivers/gpu/drm/radeon/evergreen_hdmi.c | 39 +
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>
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:
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:
> 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
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 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:
> 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
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 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
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
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
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:
> 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
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
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
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
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
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>
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>
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>
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>
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>
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>
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>
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
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
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
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
>
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
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
---
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
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
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
>
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.
1 - 100 of 130 matches
Mail list logo
