ething that enumerated all the
supply properties on the device.
-- 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/20140721/95478fb9/attachment.sig>
>-Original Message-
>From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>Of Jerome Glisse
>Sent: Monday, July 21, 2014 7:06 PM
>To: Gabbay, Oded
>Cc: Lewycky, Andrew; Pinchuk, Evgeny; Daenzer, Michel; linux-
>kernel at vger.kernel.org; dri-devel at lists.freedes
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/248c0fd3/attachment.html>
that requires separate properties, not multiple regulators in one
property.
Perhaps one idea to solve this would be to make the regulator API return
a regulator handle that in fact controls an array of regulators? Adding
Mark.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/6c3166be/attachment.sig>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/5257ff2a/attachment.html>
On 21/07/14 21:59, Jerome Glisse wrote:
> On Mon, Jul 21, 2014 at 09:36:44PM +0300, Oded Gabbay wrote:
>> On 21/07/14 21:14, Jerome Glisse wrote:
>>> On Mon, Jul 21, 2014 at 08:42:58PM +0300, Oded Gabbay wrote:
On 21/07/14 18:54, Jerome Glisse wrote:
> On Mon, Jul 21, 2014 at 05:12:06PM +0
On 21/07/14 21:22, Daniel Vetter wrote:
> On Mon, Jul 21, 2014 at 7:28 PM, Oded Gabbay wrote:
>>> I'm not sure whether we can do the same trick with the hw scheduler. But
>>> then unpinning hw contexts will drain the pipeline anyway, so I guess we
>>> can just stop feeding the hw scheduler until i
On 21/07/14 21:14, Jerome Glisse wrote:
> On Mon, Jul 21, 2014 at 08:42:58PM +0300, Oded Gabbay wrote:
>> On 21/07/14 18:54, Jerome Glisse wrote:
>>> On Mon, Jul 21, 2014 at 05:12:06PM +0300, Oded Gabbay wrote:
On 21/07/14 16:39, Christian K?nig wrote:
> Am 21.07.2014 14:36, schrieb Oded G
On 21/07/14 18:54, Jerome Glisse wrote:
> On Mon, Jul 21, 2014 at 05:12:06PM +0300, Oded Gabbay wrote:
>> On 21/07/14 16:39, Christian K?nig wrote:
>>> Am 21.07.2014 14:36, schrieb Oded Gabbay:
On 20/07/14 20:46, Jerome Glisse wrote:
> On Thu, Jul 17, 2014 at 04:57:25PM +0300, Oded Gabbay
Hi Boris,
On Monday 21 July 2014 16:18:10 Boris BREZILLON wrote:
> On Mon, 21 Jul 2014 15:47:52 +0200 Laurent Pinchart wrote:
> > On Monday 21 July 2014 15:43:13 Boris BREZILLON wrote:
> >> On Mon, 21 Jul 2014 15:30:35 +0200 Thierry Reding wrote:
> >>> On Mon, Jul 21, 2014 at 03:22:05PM +0200, Lau
Hi Boris and Thierry,
On Monday 21 July 2014 16:21:36 Boris BREZILLON wrote:
> On Mon, 21 Jul 2014 15:54:12 +0200 Thierry Reding wrote:
> > On Mon, Jul 21, 2014 at 03:47:52PM +0200, Laurent Pinchart wrote:
> >> On Monday 21 July 2014 15:43:13 Boris BREZILLON wrote:
> >>> On Mon, 21 Jul 2014 15:30:
On 21/07/14 20:05, Daniel Vetter wrote:
> On Mon, Jul 21, 2014 at 11:58:52AM -0400, Jerome Glisse wrote:
>> On Mon, Jul 21, 2014 at 05:25:11PM +0200, Daniel Vetter wrote:
>>> On Mon, Jul 21, 2014 at 03:39:09PM +0200, Christian K?nig wrote:
Am 21.07.2014 14:36, schrieb Oded Gabbay:
> On 20/
On Mon, Jul 21, 2014 at 7:28 PM, Oded Gabbay wrote:
>> I'm not sure whether we can do the same trick with the hw scheduler. But
>> then unpinning hw contexts will drain the pipeline anyway, so I guess we
>> can just stop feeding the hw scheduler until it runs dry. And then unpin
>> and evict.
> So
Hi Thierry,
On Mon, Jul 21, 2014 at 6:24 PM, Thierry Reding
wrote:
> On Mon, Jul 21, 2014 at 04:58:25PM +0530, Ajay kumar wrote:
>> On Mon, Jul 21, 2014 at 12:40 PM, Thierry Reding
>> wrote:
>> > On Fri, Jul 18, 2014 at 02:13:58AM +0530, Ajay Kumar wrote:
>> >> From: Rahul Sharma
>> >>
>> >> Th
, please advice me what commits to revert.
--
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/20140721/bb7bc160/attachment.html>
On Mon, Jul 21, 2014 at 11:29:23PM +, Bridgman, John wrote:
> >> >> So even if I really wanted to, and I may agree with you
> >> >> theoretically on that, I can't fulfill your desire to make the
> >> >> "kernel being able to preempt at any time and be able to decrease
> >> >> or increase user q
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/88a3bb07/attachment.html>
On Mon, Jul 21, 2014 at 11:58:52AM -0400, Jerome Glisse wrote:
> On Mon, Jul 21, 2014 at 05:25:11PM +0200, Daniel Vetter wrote:
> > On Mon, Jul 21, 2014 at 03:39:09PM +0200, Christian K?nig wrote:
> > > Am 21.07.2014 14:36, schrieb Oded Gabbay:
> > > >On 20/07/14 20:46, Jerome Glisse wrote:
> > > >
On Tue, Jul 22, 2014 at 12:56:13AM +0300, Oded Gabbay wrote:
> On 21/07/14 22:28, Jerome Glisse wrote:
> > On Mon, Jul 21, 2014 at 10:23:43PM +0300, Oded Gabbay wrote:
> >> On 21/07/14 21:59, Jerome Glisse wrote:
> >>> On Mon, Jul 21, 2014 at 09:36:44PM +0300, Oded Gabbay wrote:
> On 21/07/14
uvd.h.
--
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/20140721/2bb36b23/attachment.html>
On Mon, Jul 21, 2014 at 03:43:13PM +0200, Boris BREZILLON wrote:
> How about using a list instead of an array ?
> This way we can add elements to this list when parsing the EDID.
>
> Or we can just define a maximum size for the bus_formats array when
> retrieving this info from EDID. If I'm correc
Hi Thierry,
On Mon, Jul 21, 2014 at 1:22 PM, Thierry Reding
wrote:
> On Fri, Jul 18, 2014 at 12:18:05PM +0530, Ajay kumar wrote:
>> Hi Thierry,
>>
>> Thanks for your comments.
>>
>> On Fri, Jul 18, 2014 at 4:18 AM, Thierry Reding
>> wrote:
>> > On Fri, Jul 18, 2014 at 02:20:39AM +0530, Ajay kuma
Hi Thierry,
On Mon, Jul 21, 2014 at 1:44 PM, Thierry Reding
wrote:
> On Fri, Jul 18, 2014 at 02:13:49AM +0530, Ajay Kumar wrote:
>> Add drm_panel controls to support powerup/down of the
>> eDP panel, if one is present at the sink side.
>>
>> Signed-off-by: Ajay Kumar
>> ---
>> .../devicetree/bi
Hi Dave,
Another fixes pull for radeon. This one is a little bigger than I'd like,
but fixes a stability issue with GPUVM that led to GPU hangs that was
introduced in 3.15. Also included is a system hang/reboot regression fix
for dpm on TN/RL hardware.
The following changes since commit e898c79
Hi Thierry,
On Mon, Jul 21, 2014 at 1:52 PM, Thierry Reding
wrote:
> On Fri, Jul 18, 2014 at 02:13:54AM +0530, Ajay Kumar wrote:
> [...]
>> Also, remove the drm_connector implementation from ptn3460,
>> since the same is implemented using panel_binder.
>
> I think that's a step backwards. In fact
On Mon, Jul 21, 2014 at 03:39:09PM +0200, Christian K?nig wrote:
> Am 21.07.2014 14:36, schrieb Oded Gabbay:
> >On 20/07/14 20:46, Jerome Glisse wrote:
> >>On Thu, Jul 17, 2014 at 04:57:25PM +0300, Oded Gabbay wrote:
> >>>Forgot to cc mailing list on cover letter. Sorry.
> >>>
> >>>As a continuatio
[+cc Jingoo]
On Fri, Jul 18, 2014 at 12:50 PM, James Bottomley
wrote:
> On Fri, 2014-07-18 at 11:17 -0700, Greg KH wrote:
>> On Fri, Jul 18, 2014 at 09:54:32AM -0700, James Bottomley wrote:
>> > On Fri, 2014-07-18 at 09:43 -0700, Greg KH wrote:
>> > > On Fri, Jul 18, 2014 at 12:22:13PM -0400, Joh
On 21/07/14 16:39, Christian K?nig wrote:
> Am 21.07.2014 14:36, schrieb Oded Gabbay:
>> On 20/07/14 20:46, Jerome Glisse wrote:
>>> On Thu, Jul 17, 2014 at 04:57:25PM +0300, Oded Gabbay wrote:
Forgot to cc mailing list on cover letter. Sorry.
As a continuation to the existing discus
Hi Inki,
On Mon, Jul 21, 2014 at 1:21 PM, Inki Dae wrote:
> On 2014? 07? 18? 05:43, Ajay Kumar wrote:
>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>
>> This patchset also consolidates various inpu
On Mon, Jul 21, 2014 at 12:40 PM, Thierry Reding
wrote:
> On Fri, Jul 18, 2014 at 02:13:58AM +0530, Ajay Kumar wrote:
>> From: Rahul Sharma
>>
>> This patch adds ps8622 lvds bridge discovery code to the dp driver.
>>
>> Signed-off-by: Rahul Sharma
>> Signed-off-by: Ajay Kumar
>> ---
>> drivers
On 2014? 07? 18? 05:43, Ajay Kumar wrote:
> Modify the driver to invoke callbacks for the next bridge
> in the bridge chain.
> Also, remove the drm_connector implementation from ptn3460,
> since the same is implemented using panel_binder.
>
> Signed-off-by: Ajay Kumar
> ---
> drivers/gpu/drm/bri
On 2014? 07? 18? 05:43, Ajay Kumar wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> This patchset also consolidates various inputs from the drm community
> regarding the bridge chaining concept
; > err = drm_bridge_add(&bridge->base);
> > if (err < 0)
> > return err;
> >
> > dev_set_drvdata(dev, bridge);
> > ...
> > }
> >
> > drm_bridge_add() would add the bridge to a global list of bridge devices
> > which drm_bridge_get()/of_drm_find_bridge() can use to find the one that
> > it needs. The above has the big advantage that
> > it'sdev->mode_config.bridge_list completely
> > independent of the underlying bus that the bridge is on. It could be I2C
> > or SPI, platform device or PCI device.
> >
> > Thierry
> Ok. This is all about making the bridge driver confine to the driver model.
> But, I would need a drm_device pointer to register the bridge to DRM core.
> How do I get it?
Once you've obtained a reference to the DRM bridge from your driver you
should carry it around until you've set up the DRM device. Then you can
hook it up, which possibly requires a new function (since it's what the
drm_bridge_init() used to do).
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/20140721/0e4bd46b/attachment-0001.sig>
>
> Are the open source drivers for the evergreen cards (and newer) under active
> development?
Yes.
--
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/20140721/dea2c565/attachment.html>
Hi Thierry,
On Mon, Jul 21, 2014 at 12:36 PM, Thierry Reding
wrote:
> On Fri, Jul 18, 2014 at 02:13:57AM +0530, Ajay Kumar wrote:
>> From: Vincent Palatin
>>
>> Add DT binding documentation for ps8622/ps8625 bridge driver.
>>
>> Signed-off-by: Vincent Palatin
>> Signed-off-by: Ajay Kumar
>> --
On Mon, 21 Jul 2014 15:54:12 +0200
Thierry Reding wrote:
> On Mon, Jul 21, 2014 at 03:47:52PM +0200, Laurent Pinchart wrote:
> > Hi Boris,
> >
> > On Monday 21 July 2014 15:43:13 Boris BREZILLON wrote:
> > > On Mon, 21 Jul 2014 15:30:35 +0200 Thierry Reding wrote:
> > > > On Mon, Jul 21, 2014 at
https://bugzilla.kernel.org/show_bug.cgi?id=80851
Bug ID: 80851
Summary: Radeon[Trinity HD 7520G] Resume Results in Blank
Screen, no backlight
Product: Drivers
Version: 2.5
Kernel Version: 3.15.6
Hardware: x86-64
On Mon, 21 Jul 2014 15:47:52 +0200
Laurent Pinchart wrote:
> Hi Boris,
>
> On Monday 21 July 2014 15:43:13 Boris BREZILLON wrote:
> > On Mon, 21 Jul 2014 15:30:35 +0200 Thierry Reding wrote:
> > > On Mon, Jul 21, 2014 at 03:22:05PM +0200, Laurent Pinchart wrote:
> > >> On Monday 21 July 2014 14:
p://lists.freedesktop.org/archives/dri-devel/attachments/20140721/0495e0fc/attachment.html>
On 07/17/2014 11:01 AM, YoungJun Cho wrote:
> To support LCD I80 interface, the DSI host should register
> TE interrupt handler from the TE GPIO of attached panel.
> So the panel generates a tearing effect synchronization signal
> then the DSI host calls the CRTC device manager to trigger
> to tran
of an array ?
> > This way we can add elements to this list when parsing the EDID.
> >
> > Or we can just define a maximum size for the bus_formats array when
> > retrieving this info from EDID. If I'm correct we have at most 18 bus
> > formats:
> > - 3 color formats:
> >* RGB 4:4:4
> >* YCbCr 4:4:4
> >* YCbCr 4:4:2
> > - 6 color depths: 6, 8, 10, 12, 14 and 16 bits per color
>
> bpc isn't a bitmask, so EDID supports up to three formats only.
>
> The color_formats field is computed in the drm_add_display_info() function.
> You could easily turn it into a local variable and allocate and fill the
> formats array at the end of the function.
But you also need to be careful to keep whatever formats the driver
might have set explicitly.
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/20140721/2013db14/attachment.sig>
Hi Boris,
On Monday 21 July 2014 15:43:13 Boris BREZILLON wrote:
> On Mon, 21 Jul 2014 15:30:35 +0200 Thierry Reding wrote:
> > On Mon, Jul 21, 2014 at 03:22:05PM +0200, Laurent Pinchart wrote:
> >> On Monday 21 July 2014 14:55:23 Thierry Reding wrote:
> >>> On Mon, Jul 21, 2014 at 02:34:28PM +020
On Mon, 21 Jul 2014 15:30:35 +0200
Thierry Reding wrote:
> On Mon, Jul 21, 2014 at 03:22:05PM +0200, Laurent Pinchart wrote:
> > Hi Thierry,
> >
> > On Monday 21 July 2014 14:55:23 Thierry Reding wrote:
> > > On Mon, Jul 21, 2014 at 02:34:28PM +0200, Boris BREZILLON wrote:
> > > > On Mon, 21 Jul
Am 21.07.2014 14:36, schrieb Oded Gabbay:
> On 20/07/14 20:46, Jerome Glisse wrote:
>> On Thu, Jul 17, 2014 at 04:57:25PM +0300, Oded Gabbay wrote:
>>> Forgot to cc mailing list on cover letter. Sorry.
>>>
>>> As a continuation to the existing discussion, here is a v2 patch series
>>> restructured
On 20/07/14 20:46, Jerome Glisse wrote:
> On Thu, Jul 17, 2014 at 04:57:25PM +0300, Oded Gabbay wrote:
>> Forgot to cc mailing list on cover letter. Sorry.
>>
>> As a continuation to the existing discussion, here is a v2 patch series
>> restructured with a cleaner history and no totally-different-e
A standalone driver to describe signal routing seems like an
> overly complex solution to me. I would prefer making the routing a properly
> of
> the link instead of a separate device.
I don't think the above is overly complex. After all the panel expects
RGB888, so it makes no sense to make it "configurable" to anything else.
Similarly if the encoder or bridge provides RGB666 then that's a fixed
function, too. So to represent this combination accurately you'll need
some form of translation entity inbetween, and it may just as well be a
bridge than something custom for that particular link.
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/20140721/59b85ab0/attachment.sig>
Sure. One of the problems I see with replacing color_formats and bpc
with the above is that some of the bits within color_formats are set
when the EDID is parsed. That implies that if they are replaced with
an array of formats, the array would need to be reallocated during EDID
parsing. Tha
On Mon, Jul 21, 2014 at 10:23:43PM +0300, Oded Gabbay wrote:
> On 21/07/14 21:59, Jerome Glisse wrote:
> > On Mon, Jul 21, 2014 at 09:36:44PM +0300, Oded Gabbay wrote:
> >> On 21/07/14 21:14, Jerome Glisse wrote:
> >>> On Mon, Jul 21, 2014 at 08:42:58PM +0300, Oded Gabbay wrote:
> On 21/07/14
> >
> > So, you're suggesting to add an RGB to RGB drm_bridge driver (and
> > the appropriate DT bindings) to handle this case, right ?
>
> Yes, exactly.
Wouldn't it be possible to implement RGB666 -> RGB888 support in a less
complex way ? A standalone driver to describe signal routing seems like an
overly complex solution to me. I would prefer making the routing a properly of
the link instead of a separate device.
--
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/20140721/3e8f6277/attachment-0001.sig>
ving color_formats and bpc would be a waste of time.
--
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/20140721/72642444/attachment.sig>
On Mon, Jul 21, 2014 at 09:41:29PM +0300, Oded Gabbay wrote:
> On 21/07/14 21:22, Daniel Vetter wrote:
> > On Mon, Jul 21, 2014 at 7:28 PM, Oded Gabbay wrote:
> >>> I'm not sure whether we can do the same trick with the hw scheduler. But
> >>> then unpinning hw contexts will drain the pipeline any
On Mon, Jul 21, 2014 at 09:36:44PM +0300, Oded Gabbay wrote:
> On 21/07/14 21:14, Jerome Glisse wrote:
> > On Mon, Jul 21, 2014 at 08:42:58PM +0300, Oded Gabbay wrote:
> >> On 21/07/14 18:54, Jerome Glisse wrote:
> >>> On Mon, Jul 21, 2014 at 05:12:06PM +0300, Oded Gabbay wrote:
> On 21/07/14
each color).
> > >
> > > Anyway I'll propose a patch series adding a new field to
> > > drm_display_info to encode the mediabus format (as discussed with
> > > Laurent and you).
> > >
> > > >
> > > > Also, like Laurent said, this shouldn't go into the device tree, since
> > > > it's already implied by the panel's compatible value, so we'd be
> > > > duplicating information.
> > >
> > > Again, this is not necessarily true (depending on your board design).
> > > One can decide to connect an RGB888 panel on an RGB666 bus and connect
> > > the missing pins to ground.
> >
> > I think in that case the board design itself could be considered as an
> > RGB888 to RGB666 bridge, and I think that's what the device tree should
> > be describing rather than a panel with a variable number of input
> > formats.
>
> So, you're suggesting to add an RGB to RGB drm_bridge driver (and
> the appropriate DT bindings) to handle this case, right ?
Yes, exactly.
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/20140721/1f75eb5f/attachment.sig>
is is what both of
> > > >>> you had in mind.
> > > >>
> > > >> I think it is, but just to make sure I understand you correctly, could
> > > >> you just show how the drm_display_info structure would look like ?
> > > >
> > > > The new drm_display_info structure should look like this [2] (except
> > > > that color_formats and bpc have not be removed yet), and [1] is just
> > > > here to show how the video_bus_format enum would look like.
> > > >
> > > > [1] http://code.bulix.org/rfd0yx-86557
> > > > [2] http://code.bulix.org/7n03b4-86556
> > >
> > > Quoting from your paste:
> > >
> > > + const enum video_bus_format *bus_formats;
> > > + int nbus_formats;
> > >
> > > Do we really need more than one?
> >
> > We do if we want to replace the color_formats and bpc fields.
> >
>
> Yes, that's what I was about to answer :-).
Maybe we don't need to replace color_formats and bpc field immediately.
That could be done in a follow-up patch.
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/20140721/a5e6d501/attachment.sig>
e_add(&bridge->base);
if (err < 0)
return err;
dev_set_drvdata(dev, bridge);
...
}
drm_bridge_add() would add the bridge to a global list of bridge devices
which drm_bridge_get()/of_drm_find_bridge() can use to find the one that
it needs. The above has the big advantage that it's completely
independent of the underlying bus that the bridge is on. It could be I2C
or SPI, platform device or PCI device.
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/20140721/4dd28f51/attachment-0001.sig>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/31bb6697/attachment.html>
.org/archives/dri-devel/2014-May/059685.html
-- 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/20140721/6a685afb/attachment.sig>
On Mon, 21 Jul 2014 14:16:42 +0200
Laurent Pinchart wrote:
> Hi Thierry,
>
> On Monday 21 July 2014 14:12:47 Thierry Reding wrote:
> > On Mon, Jul 21, 2014 at 11:57:37AM +0200, Boris BREZILLON wrote:
> > > On Mon, 21 Jul 2014 11:32:55 +0200 Laurent Pinchart wrote:
> > >> On Monday 21 July 2014 1
On Mon, 21 Jul 2014 14:15:16 +0200
Thierry Reding wrote:
> On Fri, Jul 18, 2014 at 04:51:52PM +0200, Boris BREZILLON wrote:
> > Hi Thierry,
> >
> > Oops, I missed this reply.
> >
> > On Tue, 15 Jul 2014 12:31:37 +0200
> > Thierry Reding wrote:
> >
> > > On Tue, Jul 15, 2014 at 12:06:19PM +020
this is what both of
> >>> you had in mind.
> >>
> >> I think it is, but just to make sure I understand you correctly, could
> >> you just show how the drm_display_info structure would look like ?
> >
> > The new drm_display_info structure should look like this [2] (except
> > that color_formats and bpc have not be removed yet), and [1] is just
> > here to show how the video_bus_format enum would look like.
> >
> > [1] http://code.bulix.org/rfd0yx-86557
> > [2] http://code.bulix.org/7n03b4-86556
>
> Quoting from your paste:
>
> + const enum video_bus_format *bus_formats;
> + int nbus_formats;
>
> Do we really need more than one?
We do if we want to replace the color_formats and bpc fields.
--
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/20140721/69e9ee35/attachment-0001.sig>
like Laurent said, this shouldn't go into the device tree, since
> > it's already implied by the panel's compatible value, so we'd be
> > duplicating information.
>
> Again, this is not necessarily true (depending on your board design).
> One can decide to connect an RGB888 panel on an RGB666 bus and connect
> the missing pins to ground.
I think in that case the board design itself could be considered as an
RGB888 to RGB666 bridge, and I think that's what the device tree should
be describing rather than a panel with a variable number of input
formats.
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/20140721/c0a93c42/attachment.sig>
On Mon, Jul 21, 2014 at 08:42:58PM +0300, Oded Gabbay wrote:
> On 21/07/14 18:54, Jerome Glisse wrote:
> > On Mon, Jul 21, 2014 at 05:12:06PM +0300, Oded Gabbay wrote:
> >> On 21/07/14 16:39, Christian K?nig wrote:
> >>> Am 21.07.2014 14:36, schrieb Oded Gabbay:
> On 20/07/14 20:46, Jerome Gli
list
> > > the available formats.
> > >
> > > As this implies quite a few changes in crtc core and some drm drivers
> > > (nouveau, i915 and radeon), I'd like to be sure this is what both of you
> > > had in mind.
> >
> > I think it is, but just to make sure I understand you correctly, could you
> > just show how the drm_display_info structure would look like ?
> >
>
> The new drm_display_info structure should look like this [2] (except
> that color_formats and bpc have not be removed yet), and [1] is just
> here to show how the video_bus_format enum would look like.
>
> [1] http://code.bulix.org/rfd0yx-86557
> [2] http://code.bulix.org/7n03b4-86556
Quoting from your paste:
+ const enum video_bus_format *bus_formats;
+ int nbus_formats;
Do we really need more than 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/20140721/309fb551/attachment.sig>
From: Thierry Reding
The return type of exec_lookup() is struct nvkm_output *, so it should
return NULL rather than 0.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/c
Hi
On Mon, Jul 21, 2014 at 1:24 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> The drm_copy_field() function copies strings into userspace buffers, so
> the first parameter needs to have a __user annotation to avoid warnings
> from the sparse checker.
Reviewed-by: David Herrmann
Thanks
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/a08ca840/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/4cb017b2/attachment.html>
From: Christian K?nig
Unused and unimplemented. Also fix specifying the
kernel flag incorrectly at one occasion.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 2 +-
drivers/gpu/drm/radeon/radeon_fb.c | 3 +--
drivers/gpu/drm/radeon/radeon_gem.c | 7 +++
3 files
ause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/06f7d3dc/attachment.html>
From: Thierry Reding
The drm_copy_field() function copies strings into userspace buffers, so
the first parameter needs to have a __user annotation to avoid warnings
from the sparse checker.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 de
From: Thierry Reding
sparse complains about these functions missing a prototype, but looking
closer they aren't (and likely not supposed to be) used outside of this
source file, so they can be made static.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_mst_topology.c | 30 +++
On 07/21/2014 11:19 AM, Thierry Reding wrote:
> On Mon, Jul 21, 2014 at 10:56:08AM +0200, Andrzej Hajda wrote:
>> On 07/18/2014 03:49 AM, YoungJun Cho wrote:
>>> Hi Thierry,
>>>
>>> Thank you a lot for kind comments.
>>>
>>> On 07/17/2014 07:36 PM, Thierry Reding wrote:
On Thu, Jul 17, 2014 at
From: Thierry Reding
The final parameter to ttm_bo_reserve() is a pointer, therefore callers
should use NULL instead of 0.
Fixes a bunch of sparse warnings of this type:
warning: Using plain integer as NULL pointer
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/ast/ast_drv.h
org/archives/dri-devel/attachments/20140721/601c6d29/attachment.html>
On 2014? 07? 19? 05:36, Sjoerd Simons wrote:
> The exynos DRM module currently is not automatically loaded when build as a
> module. This is due to the simple fact that it doesn't have any
> MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed
> previously
> as it wasn't possible a
On Mon, Jul 21, 2014 at 05:25:11PM +0200, Daniel Vetter wrote:
> On Mon, Jul 21, 2014 at 03:39:09PM +0200, Christian K?nig wrote:
> > Am 21.07.2014 14:36, schrieb Oded Gabbay:
> > >On 20/07/14 20:46, Jerome Glisse wrote:
> > >>On Thu, Jul 17, 2014 at 04:57:25PM +0300, Oded Gabbay wrote:
> > >>>Forg
On Mon, 21 Jul 2014 11:32:55 +0200
Laurent Pinchart wrote:
> Hi Boris,
>
> On Monday 21 July 2014 11:24:38 Boris BREZILLON wrote:
> > On Mon, 21 Jul 2014 10:59:12 +0200 Thierry Reding wrote:
> > > On Fri, Jul 18, 2014 at 05:43:34PM +0200, Boris BREZILLON wrote:
> > > [...]
> > >
> > >>> + -
On Mon, Jul 21, 2014 at 05:12:06PM +0300, Oded Gabbay wrote:
> On 21/07/14 16:39, Christian K?nig wrote:
> >Am 21.07.2014 14:36, schrieb Oded Gabbay:
> >>On 20/07/14 20:46, Jerome Glisse wrote:
> >>>On Thu, Jul 17, 2014 at 04:57:25PM +0300, Oded Gabbay wrote:
> Forgot to cc mailing list on cove
On Mon, Jul 21, 2014 at 7:27 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Unused and unimplemented. Also fix specifying the
> kernel flag incorrectly at one occasion.
>
> Signed-off-by: Christian K?nig
Applied to my 3.17 tree.
Alex
> ---
> drivers/gpu/drm/radeon/radeon.h | 2 +
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/b61f9a59/attachment.html>
ata);
msg.tx_buf = data;
return dsi->ops->transfer(dsi->host, &msg);
}
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/20140721/457df664/attachment.sig>
Am 21.07.2014 09:01, schrieb Daniel Vetter:
> On Sun, Jul 20, 2014 at 01:46:53PM -0400, Jerome Glisse wrote:
>> On Thu, Jul 17, 2014 at 04:57:25PM +0300, Oded Gabbay wrote:
>>> Forgot to cc mailing list on cover letter. Sorry.
>>>
>>> As a continuation to the existing discussion, here is a v2 patch
Hi Boris,
On Monday 21 July 2014 11:24:38 Boris BREZILLON wrote:
> On Mon, 21 Jul 2014 10:59:12 +0200 Thierry Reding wrote:
> > On Fri, Jul 18, 2014 at 05:43:34PM +0200, Boris BREZILLON wrote:
> > [...]
> >
> >>> + - atmel,panel: Should contain a phandle with 2 parameters.
> >>> + The f
On Mon, 21 Jul 2014 10:59:12 +0200
Thierry Reding wrote:
> On Fri, Jul 18, 2014 at 05:43:34PM +0200, Boris BREZILLON wrote:
> [...]
> > > > > > > + - atmel,panel: Should contain a phandle with 2 parameters.
> > > > > > > + The first cell is a phandle to a DRM panel device
> > > > > > > + The
Hi Inki,
On 07/09/2014 04:47 PM, Inki Dae wrote:
> On 2014? 07? 03? 22:10, Andrzej Hajda wrote:
>> This set of independent patches contains various improvement and fixes
>> for exynos_drm ipp framework.
>> The patchset is based on exynos-drm-next branch.
>>
> Did you test ipp module using libdrm?
tml
That link is the only one which contains "Nokia I/F command list" on the
internet (that is, according to Google). But since this is already part
of the mipi_display.h header file we may as well use it.
I wonder if perhaps the READ_DDB_START and READ_DDB_CONTINUE commands
could be used as a replacement for this display ID.
Adding Guennadi, Tomi, Paul and Imre on Cc since they were involved with
the original patch that added mipi_display.h. Perhaps they remember what
the origin of this command is.
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/20140721/2254a498/attachment.sig>
r the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/3d08f353/attachment-0001.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/9401cda5/attachment.html>
he assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/0cb2ba5a/attachment.html>
nd blue are encoded on 5 bits.
Yes, I agree that bps is not a good fit for what you need here.
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/20140721/afb8110f/attachment.sig>
On 07/18/2014 03:49 AM, YoungJun Cho wrote:
> Hi Thierry,
>
> Thank you a lot for kind comments.
>
> On 07/17/2014 07:36 PM, Thierry Reding wrote:
>> On Thu, Jul 17, 2014 at 06:01:25PM +0900, YoungJun Cho wrote:
>> [...]
>>> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
>>> b/drivers/gpu/drm/
On Mon, Jul 21, 2014 at 7:23 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> sparse complains about these functions missing a prototype, but looking
> closer they aren't (and likely not supposed to be) used outside of this
> source file, so they can be made static.
>
> Signed-off-by: Thierry
On Mon, Jul 21, 2014 at 7:15 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> The final parameter to ttm_bo_reserve() is a pointer, therefore callers
> should use NULL instead of 0.
>
> Fixes a bunch of sparse warnings of this type:
>
> warning: Using plain integer as NULL pointer
>
>
: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/b240f88d/attachment-0001.sig>
dp->panel_node = of_parse_phandle(dev->of_node, "edp-panel", 0);
There should be no need to store the struct device_node * obtained here
in the context like this.
> + if (dp->panel_node) {
> + dp->edp_panel = of_drm_find_panel(dp->panel_node);
> + of_node_put(dp->panel_node);
Especially since after this that pointer may become invalid.
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/20140721/1da77184/attachment.sig>
Am 18.07.2014 19:06, schrieb Alex Deucher:
> On Fri, Jul 18, 2014 at 12:10 PM, Alex Deucher
> wrote:
>> On Fri, Jul 18, 2014 at 7:56 AM, Christian K?nig
>> wrote:
>>> From: Christian K?nig
>>>
>>> VM sizes smaller than 1GB doesn't make much sense anyway.
>>>
>>> Signed-off-by: Christian K?nig
Am 19.07.2014 14:37, schrieb Grigori Goronzy:
> On 19.07.2014 13:57, Christian K?nig wrote:
>> Yeah, I'm still playing a bit with this.
>>
>> You need to consider the page directory size as well. If we have 4GB
>> address space (32bits) and 12bits in the page, 12bits in the page tables
>> then ther
Am 19.07.2014 03:15, schrieb Michel D?nzer:
> On 19.07.2014 00:47, Christian K?nig wrote:
>> Am 18.07.2014 05:07, schrieb Michel D?nzer:
> [PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI
I'm still not very keen with this change since I still don't understand
the reason
ature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/65f1e4f2/attachment-0001.sig>
gt; >> > + and video_disable.
> >> > + -panel-unprepare-delay:
> >> > + delay value in ms required for panel_post_disable process
> >> > + Delay in ms needed for the panel LCD unit to
> >> > + to powerdown completely, and the minimum delay
> >> > needed
> >> > + before powering it on again.
> >
> > These delays are all panel specific and they don't vary per board, so
> > they shouldn't go into the device tree at all.
> But, fetching them from device tree would allow us to support all lvds
> panels in this single driver.
You can do that even without having this data in device tree. My point
is that this is redundant information once you know the panel's specific
compatible value. Therefore there shouldn't be a need to list this in
device tree again.
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/20140721/101f9956/attachment.sig>
1 - 100 of 110 matches
Mail list logo
