RE=1
--
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/20130206/6b707010/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #20 from Paul Heldens ---
xonotic-linux64-glx
LIBGL_ALWAYS_SOFTWARE=1 starts correctly 5x in a row
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel
Hi Laurent
> Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> and DU1 LVDS outputs will require information about the panels that will
> be connected to those outputs.
>
> Signed-off-by: Laurent Pinchart
> ---
> arch/arm/mach-shmobile/board-marzen.c | 65
> ++
On Thu, Jan 31, 2013 at 11:14:34AM +0100, Laurent Pinchart wrote:
> Hi Simon,
>
> On Thursday 31 January 2013 15:35:20 Simon Horman wrote:
> > On Thu, Jan 31, 2013 at 02:45:01AM +0100, Laurent Pinchart wrote:
> > > From: Phil Edworthy
> > >
> > > Signed-off-by: Phil Edworthy
> > > [Rename devic
On Thu, Jan 31, 2013 at 02:45:02AM +0100, Laurent Pinchart wrote:
> The R-Car Display Unit (DU) DRM driver supports both superposition
> processors and all eight planes in RGB and YUV formats without alpha
> blending.
>
> Only VGA and LVDS encoders and connectors are currently supported.
>
> Sign
On 2013-02-06 16:44, Alex Deucher wrote:
> On Wed, Feb 6, 2013 at 6:11 AM, Tomi Valkeinen wrote:
>> What is an encoder? Something that takes a video signal in, and lets the
>> CPU store the received data to memory? Isn't that a decoder?
>>
>> Or do you mean something that takes a video signal in,
Binding Documents for drm-devices are placed in
Documentation/devicetree/bindings/drm/*. But these devices are common
for v4l framework, hence moved to a common place
Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to
associate them with exynos soc series.
Signed-off-by: Rahul
Binding Documents for drm-devices are placed in
Documentation/devicetree/bindings/drm/*. But these devices are common
for v4l framework, hence moved to a common place at
Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to
associate them with exynos soc series.
Signed-off-by: Rah
t. It might make some sense to keep it in order to
scope the related fields but struct host1x isn't very large yet, so I
think omitting host1x_intr should be fine.
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/20130206/5ff704d7/attachment-0001.pgp>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/20c000a7/attachment.html>
without
corruption) than wrong with the patches applied
--
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/20130206/10042d7b/attachment.html>
n HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/a06e42d5/attachment.html>
happen with every try, best test
3x
--
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/20130206/b999a80c/attachment-0001.html>
> -Original Message-
> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
> owner at vger.kernel.org] On Behalf Of Sylwester Nawrocki
> Sent: Wednesday, February 06, 2013 8:24 PM
> To: Inki Dae
> Cc: 'Sachin Kamat'; linux-media at vger.kernel.org; dri-
> devel at lists.freede
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/cf3cb7ad/attachment.html>
ch.
--
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/20130206/1e514ba0/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130206/a206714d/attachment.html>
Hi Laurent
> Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> and DU1 LVDS outputs will require information about the panels that will
> be connected to those outputs.
>
> Signed-off-by: Laurent Pinchart
> ---
> arch/arm/mach-shmobile/board-marzen.c | 65
> ++
On 2013? 02? 06? 17:51, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
>> Sent: Wednesday, February 06, 2013 5:03 PM
>> To: Inki Dae
>> Cc: linux-media at vger.kernel.org; dri-devel at lists.freedesktop.org;
>> devicetree-discuss at l
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/a626033d/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/6150c19f/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/35237c13/attachment.html>
Hi Sylwester,
On Wed, Feb 6, 2013 at 8:20 PM, Sylwester Nawrocki
wrote:
> Hi Rahul,
>
> On 02/06/2013 03:57 PM, Rahul Sharma wrote:
>> Binding Documents for drm-devices are placed in
>> Documentation/devicetree/bindings/drm/*. But these devices are common
>> for v4l framework, hence moved to a co
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/eccfff55/attachment.html>
From: Dave Airlie
There seems to be a bad interaction between gem/shmem and defio on top,
I get list corruption on the page lru in the shmem code.
Turn it off for now until we get some more digging done.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_fb.c | 4 ++--
1 file changed, 2 i
> -Original Message-
> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> Sent: Wednesday, February 06, 2013 5:03 PM
> To: Inki Dae
> Cc: linux-media at vger.kernel.org; dri-devel at lists.freedesktop.org;
> devicetree-discuss at lists.ozlabs.org; k.debski at samsung.com;
> s.nawroc
From: Dave Airlie
Okay you don't really want to use udl devices as your console, but if
you are unlucky enough to do so, you run into a lot of schedule while atomic
due to printk being called from all sorts of funky places. So check if we
are in an atomic context, and queue the damage for later,
On Wed, Feb 6, 2013 at 4:00 PM, Tomi Valkeinen wrote:
>> not always a perfect match to the hardware. For example a lot of GPUs
>> have a DVO encoder which feeds a secondary encoder like an sil164 DVO
>> to TMDS encoder.
>
> Right. I think mapping the DRM entities to CDF ones is one of the bigger
On 6 February 2013 16:53, Sylwester Nawrocki wrote:
> On 02/06/2013 09:51 AM, Inki Dae wrote:
> [...]
> So I propose following classification, which seems less inaccurate:
>
> GPU: g2d, g3d
> Media: mfc, fimc, fimc-lite, fimc-is, mipi-csis, gsc
> Video: fimd, hdmi, eDP, mipi-dsim
Thanks Inki a
t;http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/fd0826ee/attachment.html>
p://lists.freedesktop.org/archives/dri-devel/attachments/20130206/04d38e41/attachment.html>
ave one encoder driver running multiple encoder devices.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/93812717/attachment-0001.pgp>
> -Original Message-
> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> Sent: Wednesday, February 06, 2013 2:30 PM
> To: linux-media at vger.kernel.org; dri-devel at lists.freedesktop.org;
> devicetree-discuss at lists.ozlabs.org
> Cc: k.debski at samsung.com; sachin.kamat at linaro
Hi Mr. Paul,
On Wed, Feb 6, 2013 at 3:20 PM, Paul Menzel
wrote:
> Am Mittwoch, den 06.02.2013, 09:54 +0530 schrieb Vikas Sajjan:
>> Add support for parsing the display-timing node using video helper
>> function.
>>
>> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
>> exis
From: Dave Airlie
While looking at plymouth on udl I noticed that plymouth was trying
to use its fb plugin not its drm one, it was trying to drmOpen a driver called
usb not udl, noticed that we actually had out driver pointing at the wrong
device.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm
On Thursday, February 07, 2013 2:08 AM, Bjorn Helgaas wrote
>
> On Wed, Feb 6, 2013 at 7:27 AM, Alex Deucher wrote:
> > On Wed, Feb 6, 2013 at 12:18 AM, Jingoo Han wrote:
> >> Use PCI_EXP_LNKCAP_SLS_2_5GB and PCI_EXP_LNKCAP_SLS_5_0GB instead
> >> of hardcoded values for readability. These bit de
Hi Rahul,
On 02/06/2013 03:57 PM, Rahul Sharma wrote:
> Binding Documents for drm-devices are placed in
> Documentation/devicetree/bindings/drm/*. But these devices are common
> for v4l framework, hence moved to a common place
> Documentation/devicetree/bindings/video/. 'exynos_' prefix is added t
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #19 from Andy Furniss ---
(In reply to comment #18)
> https://bugs.freedesktop.org/attachment.cgi?id=74306
I've tried quite hard on both 64 bit and 32 bit setups and with both patches
applied can no longer get any corruption.
One th
On Monday 04 February 2013 03:35 PM, Marcus Lorentzon wrote:
> On 02/02/2013 12:35 AM, Laurent Pinchart wrote:
>> Hi Marcus,
>>
>> On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote:
>>> On 01/08/2013 05:36 PM, Tomasz Figa wrote:
On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon
ce and simple.
But it is a bit limiting when thinking about complex display chips. Will
that work for all cases? I'm not sure.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/a765fdbf/attachment.pgp>
Use PCI_EXP_LNKCAP_SLS_2_5GB and PCI_EXP_LNKCAP_SLS_5_0GB instead
of hardcoded values for readability. These bit definitions were
added by commit 130f1b8 ("PCI: Add PCIe Link Capability link speed
and width names")
Signed-off-by: Jingoo Han
---
drivers/gpu/drm/drm_pci.c |4 ++--
1 files chan
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130206/d1dc76e3/attachment.html>
On Wed, 06 Feb 2013, Tomi Valkeinen wrote:
>> 6. Miscellaneous
>>
>>
>> - If the OMAP3 DSS driver is used as a model for the DSI support
>> implementation, Daniel Vetter requested the DSI bus lock semaphore to be
>> killed as it prevents lockdep from working correctly (referenc
From: Benjamin Gaignard
Install test programs is useful in cross compilation case.
By default the behavior is the same and test programs aren't installed in
$bindir.
If --enable-install-test-programs is set then test programs are installed in
$bindir
Signed-off-by: Benjamin Gaignard
---
conf
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #18 from Paul Heldens ---
https://bugs.freedesktop.org/attachment.cgi?id=74306
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-deve
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #17 from Paul Heldens ---
Created attachment 74306
--> https://bugs.freedesktop.org/attachment.cgi?id=74306&action=edit
corruption after patches
looks a bit different, also xonotic seems to start more often right (without
corruptio
On 6 February 2013 13:02, Inki Dae wrote:
>
> Looks good to me but please add document for it.
Yes. I will. I was planning to send the bindings document patch along
with the dt patches (adding node entries to dts files).
Sylwester had suggested adding this to
Documentation/devicetree/bindings/med
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #16 from Paul Heldens ---
just applied
> Try also applying the patch of
> https://bugs.freedesktop.org/show_bug.cgi?id=60034
same problem still
though it started 3x well, then when I open my browser with some pages, and
retry, th
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #15 from Paul Heldens ---
fix v2 ( 3.8.0-rc6 x86_64)
radeon :01:00.0: DMA copy src buffer too small (7516413696 18382848)
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
still the xonotic garbage, though it does not
On 05.02.2013 01:54, Thierry Reding wrote:
> On Mon, Feb 04, 2013 at 09:17:45PM -0800, Terje Bergström wrote:
>> Yeah, it's actually working around the host1x duplicate naming.
>> host1x_syncpt_get takes struct host1x as parameter, but that's different
>> host1x than in this code.
>
> So maybe a b
On 05.02.2013 01:54, Thierry Reding wrote:
> On Mon, Feb 04, 2013 at 09:17:45PM -0800, Terje Bergstr?m wrote:
>> Yeah, it's actually working around the host1x duplicate naming.
>> host1x_syncpt_get takes struct host1x as parameter, but that's different
>> host1x than in this code.
>
> So maybe a b
development
boards. It's not just once or twice that we've used a transcoder or two
between a SoC and a panel, because we haven't had the final panel yet.
Also, sometimes there are small simple chips in the video pipeline, that
do things like level shifting or ESD protection. In some cases these
chips just work automatically, but in some cases one needs to setup
regulators and gpios to get them up and running (for example,
http://www.ti.com/product/tpd12s015). And if that's the case, then I
believe having a CDF "transcoder" driver for the chip is the easiest
solution.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/859ff3ff/attachment.pgp>
On 05.02.2013 01:15, Thierry Reding wrote:
> On Mon, Feb 04, 2013 at 08:41:25PM -0800, Terje Bergström wrote:
>> This is used by debugfs code to direct to debugfs, and
>> nvhost_debug_dump() to send via printk.
>
> Yes, that was precisely my point. Why bother providing the same data via
> several
On 05.02.2013 01:15, Thierry Reding wrote:
> On Mon, Feb 04, 2013 at 08:41:25PM -0800, Terje Bergstr?m wrote:
>> This is used by debugfs code to direct to debugfs, and
>> nvhost_debug_dump() to send via printk.
>
> Yes, that was precisely my point. Why bother providing the same data via
> several
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #14 from Jerome Glisse ---
Try also applying the patch of
https://bugs.freedesktop.org/show_bug.cgi?id=60034
--
You are receiving this mail because:
You are the assignee for the bug.
___
d
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #13 from Jerome Glisse ---
Created attachment 74303
--> https://bugs.freedesktop.org/attachment.cgi?id=74303&action=edit
Fix v2
This v2 avoid the kernel message. Weird you still have issue i don't here with
this patch.
--
You are
On 06.02.2013 12:38, Thierry Reding wrote:
> On Wed, Feb 06, 2013 at 12:29:26PM -0800, Terje Bergström wrote:
>> This was done purely, because I'm hiding the struct size from the
>> caller. If the caller needs to allocate, I need to expose the struct in
>> a header, not just a forward declaration.
On 06.02.2013 12:38, Thierry Reding wrote:
> On Wed, Feb 06, 2013 at 12:29:26PM -0800, Terje Bergstr?m wrote:
>> This was done purely, because I'm hiding the struct size from the
>> caller. If the caller needs to allocate, I need to expose the struct in
>> a header, not just a forward declaration.
On Wed, Feb 06, 2013 at 12:29:26PM -0800, Terje Bergström wrote:
> On 05.02.2013 00:42, Thierry Reding wrote:
[...]
> > Or if that doesn't work it would still be preferable to allocate memory
> > in host1x_syncpt_wait() directly instead of going through the wrapper.
>
> This was done purely, becau
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #12 from Paul Heldens ---
still has the problem with that patch
noticed this in dmesg:
radeon :01:00.0: DMA copy src buffer too small (4295180288 18382848)
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
radeon :0
On 05.02.2013 00:42, Thierry Reding wrote:
> On Mon, Feb 04, 2013 at 08:29:08PM -0800, Terje Bergström wrote:
>> host1x_get_host() actually needs that, so this #include should've also
>> been in previous patch.
>
> No need to if you pass struct device * instead. You might need
> linux/device.h ins
On 05.02.2013 00:42, Thierry Reding wrote:
> On Mon, Feb 04, 2013 at 08:29:08PM -0800, Terje Bergstr?m wrote:
>> host1x_get_host() actually needs that, so this #include should've also
>> been in previous patch.
>
> No need to if you pass struct device * instead. You might need
> linux/device.h ins
On 02/06/2013 09:51 AM, Inki Dae wrote:
[...]
> I think that it's better to go to gpu than media and we can divide Exynos
> IPs into the bellow categories,
>
> Media : mfc
> GPU : g2d, g3d, fimc, gsc
Heh, nice try! :) GPU and FIMC ? FIMC is a camera subsystem (hence 'C'
in the acronym), so what
On 04.02.2013 23:43, Thierry Reding wrote:
> My point was that you could include the call to host1x_syncpt_reset()
> within host1x_syncpt_init(). That will keep unneeded code out of the
> host1x_probe() function. Also you don't want to use the syncpoints
> uninitialized, right?
Of course, sorry, I
On 04.02.2013 23:43, Thierry Reding wrote:
> My point was that you could include the call to host1x_syncpt_reset()
> within host1x_syncpt_init(). That will keep unneeded code out of the
> host1x_probe() function. Also you don't want to use the syncpoints
> uninitialized, right?
Of course, sorry, I
https://bugs.freedesktop.org/show_bug.cgi?id=60034
--- Comment #15 from Jerome Glisse ---
I attached fix for xonotic to the xonotic bug
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@list
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #11 from Jerome Glisse ---
Created attachment 74300
--> https://bugs.freedesktop.org/attachment.cgi?id=74300&action=edit
Fix
Can you check if that patch fix it for you ?
--
You are receiving this mail because:
You are the assigne
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vmw
On 2013? 02? 06? 09:56, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren
> wrote:
>> On 02/05/2013 05:37 PM, Sean Paul wrote:
>>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
>>> wrote:
n 02/05/2013 04:42 PM, Sean Paul wrote:
> Use the compatible string in the devi
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/sis/sis_mm.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/sis/sis_mm.c b/dri
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/via/via_mm.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/via/via_mm.c b/dri
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo
Acked-by: Daniel Vetter
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_gem_context.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
dif
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo
Cc: David Airlie
Cc: Kukjin Kim
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/driv
Convert to the much saner new idr interface.
Only compile tested.
* drm_ctxbitmap_next() error handling in drm_addctx() seems broken.
drm_ctxbitmap_next() return -errno on failure not -1.
Signed-off-by: Tejun Heo
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_c
idr_destroy() can destroy idr by itself and idr_remove_all() is being
deprecated. Drop its usage.
* drm_ctxbitmap_cleanup() was calling idr_remove_all() but forgetting
idr_destroy() thus leaking all buffered free idr_layers. Replace it
with idr_destroy().
Signed-off-by: Tejun Heo
Cc: David
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/via/via_mm.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/via/via_mm.c b/
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/sis/sis_mm.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/sis/sis_mm.c b/
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo
Acked-by: Daniel Vetter
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_gem_context.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo
Cc: David Airlie
Cc: Kukjin Kim
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/d
Convert to the much saner new idr interface.
Only compile tested.
* drm_ctxbitmap_next() error handling in drm_addctx() seems broken.
drm_ctxbitmap_next() return -errno on failure not -1.
Signed-off-by: Tejun Heo
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/dr
https://bugs.freedesktop.org/show_bug.cgi?id=60034
--- Comment #14 from Andy Furniss ---
(In reply to comment #13)
> Created attachment 74299 [details] [review]
> Fix
>
> Do this fix the etqw issue for you too ?
Yes it fixes etqw, but not xonotic.
--
You are receiving this mail because:
You a
idr_destroy() can destroy idr by itself and idr_remove_all() is being
deprecated. Drop its usage.
* drm_ctxbitmap_cleanup() was calling idr_remove_all() but forgetting
idr_destroy() thus leaking all buffered free idr_layers. Replace it
with idr_destroy().
Signed-off-by: Tejun Heo
Cc: David
From: Jesse Barnes
Rather than building a config which may or may not work, let the driver
build an initial fb config. This allows the driver to use the BIOS boot
configuration for example, displaying kernel messages and the initial fb
console on the same outputs the BIOS lit up at boot time. I
On Tue, Feb 5, 2013 at 6:56 PM, 김승우 wrote:
>
>
> On 2013년 02월 06일 09:56, Sean Paul wrote:
>> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren wrote:
>>> On 02/05/2013 05:37 PM, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
wrote:
> n 02/05/2013 04:42 PM, Sean Paul
On Tue, Feb 5, 2013 at 6:56 PM, ??? wrote:
>
>
> On 2013? 02? 06? 09:56, Sean Paul wrote:
>> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren
>> wrote:
>>> On 02/05/2013 05:37 PM, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
wrote:
> n 02/05/2013 04:42 PM, Sean P
From: Ajay Kumar
This patch adds device tree match table for Exynos G2D controller.
Signed-off-by: Ajay Kumar
Signed-off-by: Sachin Kamat
---
Patch based on exynos-drm-fixes branch of Inki Dae's tree:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
Changes since v1:
Modif
This patch adds device tree based discovery support to G2D driver
Signed-off-by: Sachin Kamat
---
Based on for_v3.9 branch of below tree:
git://linuxtv.org/snawrocki/samsung.git
Changes since v1:
* Addressed review comments from Sylwester .
* Modified the compatible string as per the discussions
https://bugs.freedesktop.org/show_bug.cgi?id=60034
--- Comment #13 from Jerome Glisse ---
Created attachment 74299
--> https://bugs.freedesktop.org/attachment.cgi?id=74299&action=edit
Fix
Do this fix the etqw issue for you too ?
--
You are receiving this mail because:
You are the assignee fo
tes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/24f8cd55/attachment.pgp>
On 02/06/2013 09:56 AM, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren
> wrote:
>> On 02/05/2013 05:37 PM, Sean Paul wrote:
>>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
>>> wrote:
n 02/05/2013 04:42 PM, Sean Paul wrote:
> Use the compatible string in the device
are transported,
> + inf_msg("parameter left for chip specific analysis:%s\n", g_settings);
Missing space in front of `%s`.
> + LEAVE(0);
> +}
> +
> +
> +static void claim(void)
> +{
> + inf_msg("+-SMI Driver Information+");
> + inf_msg("Release type : " RELEASE_TYPE "\n");
> + inf_msg("Driver version: v" _version_ "\n");
> + inf_msg("Support products:\n"
> + SUPPORT_CHIP);
> + inf_msg("Support OS:\n"
> + SUPPORT_OS);
> + inf_msg("Support ARCH: " SUPPORT_ARCH "\n");
> + inf_msg("+---+");
> +}
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 10)
> +static int __init lynxfb_init()
> +{
> + char *option ;
> + int ret;
> + smi_indent = 0;
> + ENTER();
> + claim();
> +#ifdef MODULE
> + option = g_option;
> +#else
> + if (fb_get_options("lynxfb", &option))
> + LEAVE(-ENODEV);
> +#endif
> +
> + lynxfb_setup(option);
> + ret = pci_register_driver(&lynxfb_driver);
> + LEAVE(ret);
> +}
> +#else /* kernel version >= 2.6.10*/
Missing space at end in front of `*/`.
> +int __init lynxfb_init(void)
> +{
> + char *option;
> + int ret;
> + smi_indent = 0;
> + ENTER();
> + claim();
> +#ifdef MODULE
> + option = g_option;
> + lynxfb_setup(option);
> +#else
> + /* do nothing */
> +#endif
> + ret = pci_register_driver(&lynxfb_driver);
> + LEAVE(ret);
> +}
> +#endif
> + module_init(lynxfb_init);
> +
> +#ifdef MODULE
> +static void __exit lynxfb_exit()
> +{
> + ENTER();
> + inf_msg(_moduleName_ " exit\n");
> + pci_unregister_driver(&lynxfb_driver);
> + LEAVE();
> +}
> + module_exit(lynxfb_exit);
> +#endif
> +
> +#ifdef MODULE
> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 10)
> + module_param(g_option, charp, S_IRUGO);
> +#else
> + /* be ware that PARM and param */
s,ware,aware,
The comment does not make any sense to me. Please rephrase.
> + MODULE_PARM(g_option, "s");
> +#endif
> +
> + MODULE_PARM_DESC(g_option,
> + "\n\t\tCommon options:\n"
> + "\t\tnoaccel:disable 2d capabilities\n"
> + "\t\tnomtrr:disable MTRR attribute for video memory\n"
> + "\t\tdualview:dual frame buffer feature enabled\n"
> + "\t\tnohwc:disable hardware cursor\n"
Missing spaces after `:`.
> + "\t\tUsual example:\n"
> + "\t\tinsmod ./lynxfb.ko g_option=\"noaccel, nohwc,
> 1280x1024-8 at 60\"\n"
> + "\t\tFor more detail chip specific options, please
> refer to \"Lynxfb User Mnual\" or readme\n"
For more detail*ed* chip specific options, please refer to \"Lynxfb User
M*a*nul\" re README*.*
Please add an URL and the path to the README.
> + );
> +#endif
> +
> + MODULE_AUTHOR("monk liu");
1. Missing space in front of email address `<`.
2. Please capitalize names correctly: Monk Liu. You could also put the
Chinese(?) characters in parentheses after it.
Applying your patch, Git complains about white space errors.
$ git am /tmp/0001-Siliconmotion-initial-patch.patch
Applying: Siliconmotion initial patch
/src/linux/.git/rebase-apply/patch:86: trailing whitespace.
sm750/sm718/sm712/sm722/sm502. Say Y if you have such a
/src/linux/.git/rebase-apply/patch:88: trailing whitespace.
To compile this driver as a module, choose M here: the
/src/linux/.git/rebase-apply/patch:802: new blank line at EOF.
+
/src/linux/.git/rebase-apply/patch:1207: new blank line at EOF.
+
/src/linux/.git/rebase-apply/patch:1456: new blank line at EOF.
+
warning: squelched 8 whitespace errors
warning: 13 lines add whitespace errors.
You have to fix those. Especially if tools warn you about this. You can
enable colors in Git [1] and `git diff` or `git show` will mark white
space issues with red.
If this is supposed to be the final version, please be more thorough
next time. White space issues and spelling mistakes can be easily fixed
beforehand by using Git correctly and a spell checker!
Thanks,
Paul
[1] http://git-scm.com/book/ch7-1.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130206/81fbaed0/attachment-0001.pgp>
On Wed, Feb 6, 2013 at 7:27 AM, Alex Deucher wrote:
> On Wed, Feb 6, 2013 at 12:18 AM, Jingoo Han wrote:
>> Use PCI_EXP_LNKCAP_SLS_2_5GB and PCI_EXP_LNKCAP_SLS_5_0GB instead
>> of hardcoded values for readability. These bit definitions were
>> added by commit 130f1b8 ("PCI: Add PCIe Link Capabili
Binding Documents for drm-devices are placed in
Documentation/devicetree/bindings/drm/*. But these devices are common
for v4l framework, hence moved to a common place
Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to
associate them with exynos soc series.
Signed-off-by: Rahul
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drive
Add display-timing node parsing to drm fimd and depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html
It also adds pinctrl support for drm fimd.
changes since v4:
- addressed comments from Paul Menzel
, to modify the co
ou 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/20130206/9630e65c/attachment.html>
Binding Documents for drm-devices are placed in
Documentation/devicetree/bindings/drm/*. But these devices are common
for v4l framework, hence moved to a common place at
Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to
associate them with exynos soc series.
Signed-off-by: Rah
On Wed, Feb 6, 2013 at 9:42 AM, Stephen Warren wrote:
> On 02/05/2013 05:37 PM, Sean Paul wrote:
>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
>> wrote:
>>> n 02/05/2013 04:42 PM, Sean Paul wrote:
Use the compatible string in the device tree to determine which
registers/functions t
On 5 February 2013 15:03, Sylwester Nawrocki wrote:
> On 02/05/2013 04:03 AM, Inki Dae wrote:
> [...]
>>> Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same
>>> comptible string will be used for this one too.
>>>
And please check if exynos4212 and 4412 SoCs have same fimg-2d ip.
>
1 - 100 of 128 matches
Mail list logo
