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
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
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>
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 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
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
Hi,
On 07/21/2014 08:18 PM, Andrzej Hajda wrote:
> 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 0
Hi Thierry,
Now I understand what you mean.
I'll implement common DSI helper functions.
Thank you.
Best regards YJ
On 07/21/2014 06:35 PM, Thierry Reding wrote:
> On Fri, Jul 18, 2014 at 10:49:35AM +0900, YoungJun Cho wrote:
>> Hi Thierry,
>>
>> Thank you a lot for kind comments.
>>
>> On 07/17
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 | 223
> ++--
> 3 files c
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 22 July 2014 14:21, Alexandre Courbot wrote:
> DRM maintainers, could I have a comment about this patch? A bunch of
> Nouveau changes depend on it.
I'm not sure we really have anyone who is in a great position to comment,
my major issue would be its allocate a large chunk of RAM that might
no
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>
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 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
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>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140722/0d3bff67/attachment.html>
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
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
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
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,
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
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 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 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
>
> 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 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
> > >
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>
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 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 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
;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
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>
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
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
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 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 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
s scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140722/05f56e8a/attachment.html>
On 19.07.2014 00:09, Alex Deucher wrote:
> Now that fallback to gtt is fixed for cpu access, we can
> remove this limit.
>
> bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=78717
>
> v2: use new gart_pin_size to accurately track available gtt.
> v3: fix comment
[...]
> @@ -55,10 +55,14 @@ i
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 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
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 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
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'
>> .transfer() so make sure the return types are consistent.
>>
On 22/07/14 12:21, 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 schedule any more work
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140722/7b6b5f5c/attachment.html>
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 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 22 July 2014 18:52, Russell King - ARM Linux
wrote:
> 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
>>
>>
Hi Thierry,
On 07/22/2014 04:49 PM, Thierry Reding wrote:
> On Tue, Jul 22, 2014 at 12:41:21PM +0900, YoungJun Cho wrote:
>> On 07/21/2014 08:18 PM, Andrzej Hajda wrote:
>>> On 07/21/2014 11:19 AM, Thierry Reding wrote:
On Mon, Jul 21, 2014 at 10:56:08AM +0200, Andrzej Hajda wrote:
> On 0
Hi Thierry,
YoungJun's comment refreshed my memory about mipi_dsi_dcs_write return
value. It should be rather int than ssize_t. Why?
.transfer() returns the number of read bytes or error, but in case
of dcs write no bytes are read, so it in fact returns error or 0.
This is why return value was imp
Hi Andrzej,
On 07/22/2014 07:12 PM, Andrzej Hajda wrote:
> 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 G
This is a temporary solution and should be made by more
generic way.
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
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140722/1c1df522/attachment.html>
Hi Varka,
This irq handler should be registered in attach() and unregistered in
detach().
The devm_* APIs are released(freed) in remove(), right?
Logically the panel could be attached and detached several times after
dsi is probed and not removed.
So I don't use devm_* APIs.
Thank you.
Best r
On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
> On 22/07/14 12:21, 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
On Tue, Jul 22, 2014 at 09:12:20AM +0200, 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 addin
On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote:
> 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/radeo
Hey,
op 22-07-14 06:05, Dave Airlie schreef:
> 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 Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote:
> > Am 22.07.2014 06:05, schrieb Dave Airlie:
> > >On 9 July 2014 22:29, Maarten Lankhorst > >canonical.com> wrote:
> > >>Signed-off-by: Maarten Lankhorst
> > >>---
>
Hi Varka,
On 07/22/2014 08:14 PM, Varka Bhadram wrote:
> On 07/22/2014 04:40 PM, YoungJun Cho wrote:
>> Hi Varka,
>>
>> This irq handler should be registered in attach() and unregistered in
>> detach().
>>
>> The devm_* APIs are released(freed) in remove(), right?
>>
>> Logically the panel could b
On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote:
> > Am 22.07.2014 06:05, schrieb Dave Airlie:
> > >On 9 July 2014 22:29, Maarten Lankhorst > >canonical.com> wrote:
> > >>Signed-off-by: Maarten Lankhorst
> > >>---
>
Am 22.07.2014 13:57, schrieb Daniel Vetter:
> On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
>> On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote:
>>> Am 22.07.2014 06:05, schrieb Dave Airlie:
On 9 July 2014 22:29, Maarten Lankhorst >>> canonical.com> wrote:
>
Hello,
This patch series is a proposal to describe the different data formats used
by HW components to connect with each other.
This is just a copy of the existing V4L2_MBUS_FMT defintions with a neutral
name so that it can be used by V4L2 and DRM/KMS subsystem.
This series also makes use of thi
Add RGB444 format using a 12 bits bus and RGB565 using a 16 bits bus.
These formats will later be used by atmel-hlcdc driver.
Signed-off-by: Boris BREZILLON
---
include/uapi/linux/v4l2-mediabus.h| 2 ++
include/uapi/linux/video-bus-format.h | 4 +++-
2 files changed, 5 insertions(+), 1 dele
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 VIDEO_BUS_FMT_
definitions.
Signed-off-by: Boris BREZILLON
---
include/uapi
Foxlink's fl500wvr00-a0t supports RGB888 format.
Signed-off-by: Boris BREZILLON
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 42fd6d1..f1e49fd 100644
--- a/drivers/gp
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 display.
This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB
Provide a way to specify panel requirement in terms of supported media bus
format (particularly useful for panels connected to an RGB or LVDS bus).
Signed-off-by: Boris BREZILLON
---
drivers/gpu/drm/panel/panel-simple.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/pan
27;s not good, I'm learning it now
P.P.S. And thanks for your hard work!
---
[1] https://bugs.freedesktop.org/show_bug.cgi?id=79806
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/a
Hello,
This patch series adds support for Atmel HLCDC (HLCD Controller) available
on some Atmel SoCs (i.e. the sama5d3 family).
The HLCDC actually provides a Display Controller and a PWM device, hence I
decided to declare an MFD device exposing 2 subdevices: a display
controller and a PWM chip.
T
The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
family or sama5d3 family) exposes 2 subdevices:
- a display controller (controlled by a DRM driver)
- a PWM chip
The MFD device provides a regmap and several clocks (those connected
to this hardware block) to its subdevices.
The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
family or sama5d3 family) exposes 2 subdevices:
- a display controller (controlled by a DRM driver)
- a PWM chip
This patch adds documentation for atmel-hlcdc DT bindings.
Signed-off-by: Boris BREZILLON
---
.../devicetree/b
The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
at91sam9x5 family or sama5d3 family) provide a PWM device.
This driver add support for a PWM chip exposing a single PWM device (which
will most likely be used to drive a backlight device).
Signed-off-by: Boris BREZILLON
---
The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
at91sam9x5 family or sama5d3 family) provide a PWM device.
The DT bindings used for this PWM device is following the default 3 cells
bindings described in Documentation/devicetree/bindings/pwm/pwm.txt.
Signed-off-by: Boris BR
The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.
This display controller supports at least one primary plane and might
provide several overlays and an hardware cursor depending on the IP
The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.
The HLCDC block provides a single RGB output port, and only supports LCD
panels connection to LCD panels for now.
The atmel,panel propert
The HLCDC (HLCD Controller) IP supports 4 different output mode (RGB444,
RGB565, RGB666 and RGB888) and the pin muxing will depend on the chosen
RGB mode.
Split pin definitions to be able to set pin config according to the
selected mode.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama
Define the HLCDC (HLCD Controller) IP available on some sama5d3 SoCs
(i.e. sama5d31, sama5d33, sama5d34 and sama5d36) in sama5d3 dtsi file.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama5d3_lcd.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch
Add LCD panel related nodes (backlight, regulators and panel) to sama5d3
Display Module dtsi.
Reference LCD pin muxing used by sama5d3xek boards.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama5d3xdm.dtsi | 58 +++
1 file changed, 58 insertions(+)
Define alternative pin muxing for the LCDC pins.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama5d3_lcd.dtsi | 50 ++
1 file changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3_lcd.dtsi
b/arch/arm/boot/dts/sama5d3_lcd.dtsi
index 2186b8
Enable LCD related nodes.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama5d31ek.dts | 20
arch/arm/boot/dts/sama5d33ek.dts | 20
arch/arm/boot/dts/sama5d34ek.dts | 20
arch/arm/boot/dts/sama5d36ek.dts | 20 +
On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote:
> Am 22.07.2014 13:57, schrieb Daniel Vetter:
> >On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
> >>On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote:
> >>>Am 22.07.2014 06:05, schrieb Dave Airlie:
>
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.
Applied.
Thanks,
Inki Dae
>
> Regards
> Andrzej
>
>
> Andrzej Hajda (12):
> drm/exynos/ipp
Am 22.07.2014 15:26, schrieb Daniel Vetter:
> On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote:
>> Am 22.07.2014 13:57, schrieb Daniel Vetter:
>>> On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote:
On 2014? 07? 17? 18:01, YoungJun Cho wrote:
> Hi,
>
> This series adds LCD I80 interface display support for Exynos DRM driver.
> The FIMD(display controller) specification describes it as "LCD I80 interface"
> and the DSI specification describes it as "Command mode interface".
>
> This is based
https://bugzilla.kernel.org/show_bug.cgi?id=80901
Bug ID: 80901
Summary: [radeon] loading corrupts lspci entry + unloading
crashes kernel
Product: Drivers
Version: 2.5
Kernel Version: 3.16.0
Hardware: IA-64
https://bugzilla.kernel.org/show_bug.cgi?id=80901
--- Comment #1 from Andrea Patern? ---
Created attachment 143911
--> https://bugzilla.kernel.org/attachment.cgi?id=143911&action=edit
System Journal log
System log on failure
--
You are receiving this mail because:
You are watching the assign
https://bugzilla.kernel.org/show_bug.cgi?id=80901
--- Comment #2 from Andrea Patern? ---
Created attachment 143921
--> https://bugzilla.kernel.org/attachment.cgi?id=143921&action=edit
Kernel config
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=80901
Andrea Patern? changed:
What|Removed |Added
Attachment #143901|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=80901
Andrea Patern? changed:
What|Removed |Added
Attachment #143911|application/octet-stream|text/plain
mime type|
op 22-07-14 14:19, Christian K?nig schreef:
> Am 22.07.2014 13:57, schrieb Daniel Vetter:
>> On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
>>> On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote:
Am 22.07.2014 06:05, schrieb Dave Airlie:
> On 9 July 2014 22:29,
https://bugzilla.kernel.org/show_bug.cgi?id=80901
Andrea Patern? changed:
What|Removed |Added
Attachment #143921|application/octet-stream|text/plain
mime type|
> No, you really shouldn't be doing much in the check anyway, it's meant to be
> a lightweight check. If you're not ready yet because of a lockup simply
> return not signaled yet.
It's not only the lockup case from radeon I have in mind here. For
userspace queues it might be necessary to call co
op 22-07-14 16:24, Christian K?nig schreef:
>> No, you really shouldn't be doing much in the check anyway, it's meant to be
>> a lightweight check. If you're not ready yet because of a lockup simply
>> return not signaled yet.
> It's not only the lockup case from radeon I have in mind here. For u
https://bugzilla.kernel.org/show_bug.cgi?id=80901
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #3 fr
https://bugzilla.kernel.org/show_bug.cgi?id=80901
--- Comment #4 from Andrea Patern? ---
It does.
gandalf at the_shire ~ ? LIBGL_DEBUG=1 DRI_PRIME=1 glxinfo | grep "renderer
string"
libGL: Can't open configuration file /home/gandalf/.drirc: No such file or
directory.
libGL: Can't open configurat
https://bugzilla.kernel.org/show_bug.cgi?id=80901
--- Comment #5 from Andrea Patern? ---
Created attachment 143931
--> https://bugzilla.kernel.org/attachment.cgi?id=143931&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
1 - 100 of 154 matches
Mail list logo
