---
drivers/staging/imx-drm/imx-ldb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/imx-drm/imx-ldb.c
b/drivers/staging/imx-drm/imx-ldb.c
index 7e59329..448f3ce 100644
--- a/drivers/staging/imx-drm/imx-ldb.c
+++ b/drivers/staging/imx-drm/imx-ldb.c
@@ -599,6 +599,8 @@ stati
---
drivers/staging/imx-drm/parallel-display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/imx-drm/parallel-display.c
b/drivers/staging/imx-drm/parallel-display.c
index 24aa9be..705a914 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131206/c846f9da/attachment.html>
y is it working?
--
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/20131206/50f30610/attachment-0001.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131206/daa47d57/attachment.html>
t;http://lists.freedesktop.org/archives/dri-devel/attachments/20131206/c7f8e78f/attachment.html>
.
--
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/20131206/7bdf3d57/attachment.html>
Hi Peter,
Am Donnerstag, den 05.12.2013, 23:45 +0100 schrieb Peter Seiderer:
> Signed-off-by: Peter Seiderer
> ---
> arch/arm/boot/dts/imx6q-sabrelite.dts | 3 +++
> drivers/staging/imx-drm/imx-drm-core.c | 27 +++
> drivers/staging/imx-drm/imx-drm.h |
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131206/b82cafb8/attachment-0001.html>
On Thu, Dec 05, 2013 at 04:37:39PM +0200, Tomi Valkeinen wrote:
> On 2013-11-27 12:54, Thierry Reding wrote:
>
> >> I am not sure about hardwiring devices to virtual channels.
> >> There could be devices which uses more than one virtual channel,
> >> in fact exynos-drm docs suggests that such hard
not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131206/6a4dcda7/attachment.pgp>
oading my network.
--
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/20131206/accd37dd/attachment.html>
as scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131206/29376d8d/attachment.pgp>
ves/dri-devel/attachments/20131206/63bca5f1/attachment.html>
available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131206/b167f37c/attachment-0001.pgp>
Am Freitag, den 06.12.2013, 14:14 +0100 schrieb Thierry Reding:
> On Thu, Dec 05, 2013 at 07:28:06PM +0100, Denis Carikli wrote:
> [...]
> > diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
> > b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
> [...]
> > @@ -155,6 +156,8 @@ static int ipu_pixfmt_to_m
On 12/05/2013 12:42 PM, Alex Deucher wrote:
> Well, we'd need to start swapping indirect buffers and the ring as
> well then which would get tricky as the CP at least does not have
> separate swapping controls for different things. Probably easier to
> fix up as appropriate for different asic fami
probing capabilities and characteristics. The equivalent for
panels would be something like EDID. If the panel provided EDID, then of
course you don't need to specify the mode, neither in DT nor in the
driver.
Yet, even with the availability of specifications and standard USB
classes, USB is still one of the areas where doing this is most common:
$ git grep -n 'USB_DEVICE_.*(' -- drivers/ | wc -l
829
And then there's things like drivers/hid/usbhid/hid-quirks.c and other
such things.
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/20131206/73eccdca/attachment.pgp>
f work.
Is the "mem-to-mem" the same as the "DMA channels" you mentioned? If it
only does DMA, why does it even need to worry about pixel formats?
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/20131206/1a271527/attachment.pgp>
On Fri, Dec 06, 2013 at 02:58:00PM +0100, Thierry Reding wrote:
> On Thu, Dec 05, 2013 at 12:45:17AM +0100, Laurent Pinchart wrote:
> > Hi Thierry,
> >
> > On Tuesday 26 November 2013 09:59:12 Thierry Reding wrote:
> > > On Tue, Nov 26, 2013 at 02:54:41AM +0100, Laurent Pinchart wrote:
> > > > On
port.
let us know if there is any information that we can give you to help out.
--
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/2
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131206/340b2fd2/attachment.html>
On Fri, Dec 6, 2013 at 8:58 AM, Kleber Sacilotto de Souza
wrote:
> On 12/05/2013 12:42 PM, Alex Deucher wrote:
>>
>> Well, we'd need to start swapping indirect buffers and the ring as
>> well then which would get tricky as the CP at least does not have
>> separate swapping controls for different t
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #4 from Christoph Haag ---
Created attachment 117751
--> https://bugzilla.kernel.org/attachment.cgi?id=117751&action=edit
kernel panic on reboot with runpm=1
3.13-rc3, same problems.
Also, here is a crappy picture of a kernel panic
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #5 from Alex Deucher ---
Does runpm work on my old runpm branch prior to merging with 3.13?
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.12-radeon-poweroff
--
You are receiving this mail because:
You are watching the
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131206/ce10f949/attachment.html>
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131206/e6802a2d/attachment.html>
ness/contrast) set on the TV.
--
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/20131206/ca106dca/attachment.html>
Gentle Reminder!
On Mon, Nov 25, 2013 at 2:21 PM, Shirish S wrote:
> With the current implementation of collecting edid modes,
> in case rb mode exists for a non rb mode of same resolution and
> vrefresh, the non-rb mode is never fed to display controller to be
> probed, as a result we lose on us
29 matches
Mail list logo
