On Tue, 22 Jul 2014 17:48:18 +0200
Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 5:42 PM, Alex Deucher
> wrote:
> >> Fence-based syncing between userspace queues submitted stuff through
> >> doorbells and anything submitted by the general simply wont work.
> >> Which is why I think the doorbel
On 07/22/2014 03:23 AM, Inki Dae wrote:
> On 2014? 07? 21? 23:01, Andrzej Hajda wrote:
>> 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 effe
On 07/22/2014 11:50 AM, YoungJun Cho wrote:
> Hi,
>
> On 07/22/2014 04:28 PM, Andrzej Hajda wrote:
>> Hi Thierry,
>>
>> Thanks for the patch.
>>
>> On 07/22/2014 09:12 AM, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> This function returns the value of the struct mipi_dsi_host_ops'
>>> .t
On Tue, Jul 22, 2014 at 8:39 AM, ?? ?? wrote:
> Hello all!
>
> I have some spare time and knowledge in C to try to fix some bugs I am
> seeing on my machine.
> So I've checked out and compiled all git trees that I may need and now I'm
> beginning to read articles.
>
> And this is the point
On Mon, Jul 21, 2014 at 6:10 PM, Thierry Reding
wrote:
> On Mon, Jul 21, 2014 at 05:28:13PM +0530, Ajay kumar wrote:
>> 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 dr
On 11 Jul 11:18 AM, Ezequiel Garcia wrote:
> Hello all,
>
> This patchset adds the required changes to support an optional backlight
> and GPIO for the tilcdc panel driver.
>
> There was some code to support a backlight, but it was somewhat broken
> and undocumented. I've followed the nice implem
On Tue, Jul 22, 2014 at 11:19 AM, Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 4:39 PM, Christian K?nig
> wrote:
>> Am 22.07.2014 16:27, schrieb Maarten Lankhorst:
>>
>>> op 22-07-14 16:24, Christian K?nig schreef:
>
> No, you really shouldn't be doing much in the check anyway, it's mea
On Mon, Jul 21, 2014 at 8:14 PM, Thierry Reding
wrote:
> On Mon, Jul 21, 2014 at 08:06:01PM +0530, Ajay kumar wrote:
>> 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
On 07/22/2014 10:12 AM, Thierry Reding wrote:
> On Tue, Jul 22, 2014 at 09:32:58AM +0200, Andrzej Hajda wrote:
>> On 07/22/2014 09:12 AM, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> Currently the mipi_dsi_dcs_write() function requires the DCS command
>>> byte to be embedded within the w
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_vm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drivers/gpu/drm/radeon/radeon_vm.c
index fa41e0d7..725d366 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
++
On Tue, Jul 22, 2014 at 11:21 AM, Daniel Vetter
wrote:
> On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay wrote:
>>> Exactly, just prevent userspace from submitting more. And if you have
>>> misbehaving userspace that submits too much, reset the gpu and tell it
>>> that you're sorry but won't sched
On 22/07/14 10:40, Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 09:28:51AM +0200, Daniel Vetter wrote:
>> On Mon, Jul 21, 2014 at 03:03:07PM -0400, Jerome Glisse wrote:
>>> 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
On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay wrote:
>> Exactly, just prevent userspace from submitting more. And if you have
>> misbehaving userspace that submits too much, reset the gpu and tell it
>> that you're sorry but won't schedule any more work.
>
> I'm not sure how you intend to know if
On 22/07/14 10:28, Daniel Vetter wrote:
> On Mon, Jul 21, 2014 at 03:03:07PM -0400, Jerome Glisse wrote:
>> 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 wh
Hi,
On 07/22/2014 10:23 AM, Inki Dae wrote:
> On 2014? 07? 21? 23:01, Andrzej Hajda wrote:
>> 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
On 22/07/14 10:23, Daniel Vetter wrote:
> On Mon, Jul 21, 2014 at 10:23:43PM +0300, Oded Gabbay wrote:
>> But Jerome, the core problem still remains in effect, even with your
>> suggestion. If an application, either via userspace queue or via ioctl,
>> submits a long-running kernel, than the CPU in
On 22/07/14 02:05, 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 +0
On Tue, Jul 22, 2014 at 8:39 AM, ?? ?? wrote:
> Hello all!
>
> I have some spare time and knowledge in C to try to fix some bugs I am
> seeing on my machine.
> So I've checked out and compiled all git trees that I may need and now I'm
> beginning to read articles.
>
> And this is the point
On Thu, Jul 17, 2014 at 4:43 PM, Ajay Kumar wrote:
> Move the DP training and video enable from the hotplug handler into
> a seperate function and call the same during dpms ON.
>
> With existing code, DP HPD should be generated just few ms before
> calling enable_irq in dp_poweron.
>
> This patch
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140722/1c1df522/attachment.html>
ture
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140722/a394e038/attachment.sig>
Am 22.07.2014 06:05, schrieb Dave Airlie:
> On 9 July 2014 22:29, Maarten Lankhorst
> wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/radeon/radeon.h| 15 +-
>> drivers/gpu/drm/radeon/radeon_device.c | 60 -
>> drivers/gpu/drm/radeon/radeon_fence.c |
On 2014? 07? 21? 23:01, Andrzej Hajda wrote:
> 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
not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140722/0129faf7/attachment.sig>
;s consistent). By the law of
least surprise people will actually expect mipi_dsi_dcs_write() to take
a command as a second parameter.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Des
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140722/7b6b5f5c/attachment.html>
On 2014? 07? 21? 18:23, Andrzej Hajda wrote:
> 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-n
On Sun, Jul 13, 2014 at 12:18:58PM +0100, Russell King wrote:
> drivers/gpu/drm/rcar-du/rcar_du_drv.c:190:5: warning: "CONFIG_PM_SLEEP" is
> not defined [-Wundef]
>
> Always use #ifdef with CONFIG symbols, never just bare #if
>
> Signed-off-by: Russell King
Ping?
> ---
> drivers/gpu/drm/rcar
On Sun, Jul 13, 2014 at 12:19:03PM +0100, Russell King wrote:
> drivers/gpu/drm/shmobile/shmob_drm_drv.c:300:5: warning: "CONFIG_PM_SLEEP" is
> not defined [-Wundef]
>
> Always use #ifdef with CONFIG symbols, never just bare #if
>
> Signed-off-by: Russell King
Ping?
> ---
> drivers/gpu/drm/s
On Fri, Jul 11, 2014 at 09:03:44PM +0100, Russell King wrote:
> David,
>
> Please incorporate the latest Armada DRM updates, which can be found at:
>
> git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-armada-devel
Ping?
>
> with SHA1 9611cb93fa65dde199f4f888bd034ffc80c7adf0, based on v3.16-
bridge->base.dev = dev;
> >> > bridge->base.funcs = &foo_bridge_funcs;
> >> >
> >> > 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).
>
> Ok. We can have 2 parts:
>
> Non-DRM part:
> In order to get a reference for drm_bridge in my encoder driver, I
> should be using
> of_drm_find_bridge(). In order to do that, I should have already added
> the bridge
> into a static list of bridges(using something like drm_bridge_add).
> Also, bridge_funcs pointer is assigned to the bridge object in the
> bridge driver itself.
>
> DRM part:
> Assuming that the bridge driver probe will take care of calling
> drm_bridge_add(),
> I can then call drm_bridge_init from encoder driver, with a drm_bridge pointer
> and a drm_device pointer, which will actually register the bridge into DRM
> core.
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/20140722/ff287b7c/attachment-0001.sig>
On Wed, Jul 09, 2014 at 10:34:58AM +0100, Russell King wrote:
> David,
>
> Please incorporate the latest msm drm update for component changes, which can
> be found at:
>
> git://ftp.arm.linux.org.uk/~rmk/linux-arm.git component-for-drm
Ping?
>
> with SHA1 84448288546d13d7e06fd6638fb78ddff55
play identification information.
> - The first read byte identifies the OLED module's manufacturer.
> - The Second read byte is used to track the OLED module/driver version.
> - The third read byte identifies the OLED module/driver.
Okay, that explains things a little better. Can you point me to the
document that this is from?
But what I was trying to say is that if the Read IDs command isn't an
official DCS command, maybe it would be a better idea to use the DDB
instead. I assume that even if it isn't the same information it would
at least be a superset and therefore a suitable replacement.
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/20140722/8da24a5b/attachment.sig>
On Tue, Jul 22, 2014 at 09:28:51AM +0200, Daniel Vetter wrote:
> On Mon, Jul 21, 2014 at 03:03:07PM -0400, Jerome Glisse wrote:
> > 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
> > >
On 07/22/2014 09:12 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> Use a static inline function for upcasting a struct drm_panel to the
> driver-specific structure. The advantage over using a macro is that it
> gives us additional type checking.
>
> Signed-off-by: Thierry Reding
Acked-by: A
On 07/22/2014 09:12 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> Currently the mipi_dsi_dcs_write() function requires the DCS command
> byte to be embedded within the write buffer whereas mipi_dsi_dcs_read()
> has a separate parameter. Make them more symmetrical by adding an extra
> comman
On 07/22/2014 09:12 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> When executing DCS commands, use the channel associated with the DSI
> peripheral rather than one explicitly specified in the function call.
> Devices shouldn't be able to step on each others' toes like this.
>
> Signed-off-b
On Mon, Jul 21, 2014 at 03:03:07PM -0400, Jerome Glisse wrote:
> 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
Hi Thierry,
Thanks for the patch.
On 07/22/2014 09:12 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> This function returns the value of the struct mipi_dsi_host_ops'
> .transfer() so make sure the return types are consistent.
>
> Signed-off-by: Thierry Reding
Acked-by: Andrzej Hajda
--
On Mon, Jul 21, 2014 at 10:23:43PM +0300, Oded Gabbay wrote:
> But Jerome, the core problem still remains in effect, even with your
> suggestion. If an application, either via userspace queue or via ioctl,
> submits a long-running kernel, than the CPU in general can't stop the
> GPU from running it
From: Thierry Reding
Use a static inline function for upcasting a struct drm_panel to the
driver-specific structure. The advantage over using a macro is that it
gives us additional type checking.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/panel/panel-s6e8aa0.c | 5 -
1 file changed,
From: Thierry Reding
Currently the mipi_dsi_dcs_write() function requires the DCS command
byte to be embedded within the write buffer whereas mipi_dsi_dcs_read()
has a separate parameter. Make them more symmetrical by adding an extra
command parameter to mipi_dsi_dcs_write().
Also update the S6E
From: Thierry Reding
When executing DCS commands, use the channel associated with the DSI
peripheral rather than one explicitly specified in the function call.
Devices shouldn't be able to step on each others' toes like this.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_mipi_dsi.c
From: Thierry Reding
This function returns the value of the struct mipi_dsi_host_ops'
.transfer() so make sure the return types are consistent.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_mipi_dsi.c| 4 ++--
drivers/gpu/drm/panel/panel-s6e8aa0.c | 4 ++--
include/drm/drm_mipi
s scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140722/05f56e8a/attachment.html>
This panel is used by the Medcom Wide and supported by the
simple-panel driver.
Signed-off-by: Alban Bedel
---
v2: * Added the v/hsync pulses for correctness (the panel doesn't
really needs them)
* Fixed the size to report the physical size in mm
---
.../bindings/panel/innolux,n156bge-
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140722/0d3bff67/attachment.html>
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/20140722/984a1511/attachment.html>
ee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140722/fa02499a/attachment-0001.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140722/fbd1beda/attachment.html>
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 21:14, Jerome Glisse wrote:
> On Mon, Jul 21, 2014 at 08:42:58PM +0
uires and reconfigure itself accordingly. This should be able to work
with an arbitrary bridge -> [bridge... ->] panel chain where each
element in the chain can reconfigure depending on what the next element
requires (or fail if it can't work, which should really never happen).
Thierry
--
--
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/20140722/bc009dff/attachment.html>
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 suppor
101 - 154 of 154 matches
Mail list logo
