On 06/10/2013 11:48 PM, Russell King - ARM Linux wrote:
> On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:
>> On 06/09/13 21:29, Russell King wrote:
>>> +static const struct armada_output_type armada_drm_conn_slave = {
>>> + .connector_type = DRM_MODE_CONNECTOR_HDMIA,
>>
>>
On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> I guess in the short term, the best I can think is keep those phys
> ioctls as a small patch on top of the upstream driver. It is ok to
> leave place-holder ioctl #'s in the upstream driver so that the ioctl
> #'s don't shift when you re
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 125 +++---
drivers/gpu/drm/armada/armada_hw.h |6 +-
2 files changed, 43 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_cr
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/Kconfig |6 +-
drivers/gpu/drm/armada/armada_crtc.c | 186 +++--
drivers/gpu/drm/armada/armada_crtc.h |5 +-
3 files changed, 135 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/armada/K
This patch adds hardware cursor support to the DRM driver for the
Marvell Armada SoCs.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/Kconfig |7 +
drivers/gpu/drm/armada/armada_crtc.c | 201 ++
drivers/gpu/drm/armada/armada_crtc.h |8 ++
3
This patch adds support for the pair of LCD controllers on the Marvell
Armada 510 SoCs. This driver supports:
- multiple contiguous scanout buffers for video and graphics
- shm backed cacheable buffer objects for X pixmaps for Vivante GPU
acceleration
- dual lcd0 and lcd1 crt operation
- video o
Okay, so the previous set didn't contain all the updates I wanted.
That's partly because of the timespan between making those changes
and re-posting the RFC.
This time, the "Add Armada DRM driver" commit contains all the
updates it should've had from last time!
However, I'm posting a slightly dif
On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > wrote:
> >> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> >>> On Sun, Jun 9, 2013 at 3:29 PM, Russell
d it with the same version of clang that you are using with Mesa?
--
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/20130610/f2fb152d/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/0ffc036d/attachment.html>
On 10.06.2013 23:43, Thierry Reding wrote:
> Can you post the corresponding wrappers to make it easier to discuss
> them? If they just wrap runtime PM calls then they don't solve the
> locality problems that Terje brought up.
I don't think the wrappers are applicable here. They're there in
downstr
This fixes the wrong sync generation and sync calculation. It has only
been tested for progressive modes. Sync timings for a bunch of modes
have also been verified with an oscilloscope near-end (TDA998x input)
and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
---
Note: This
Current DRM slave encoder API conflicts with auto-registration of i2c client
when using DT probed clients. To allow DRM slave encoders passed by DT, this
patch adds a check to drm_i2c_encoder_init for a non-NULL .of_node on
i2c_board_info and calls an of_i2c helper to get the i2c client device
inst
On Wed, Jun 5, 2013 at 5:16 PM, Ilia Mirkin wrote:
> On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
> wrote:
>> Hey,
>>
>> Op 04-06-13 20:38, Ilia Mirkin schreef:
>>> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
These chipsets include the VP2 engine which is composed of a bitstream
On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> >> I'd like to see all the ARM based drivers based on CMA if it can meet
> >> their requirements
> >>
On Mon, Jun 10, 2013 at 07:17:22PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
> wrote:
> > On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> >> I guess in the short term, the best I can think is keep those phys
> >> ioctls as a small patch on top
On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> I'd like to see all the ARM based drivers based on CMA if it can meet
> their requirements
> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
> come an unmaintainable
> nightmare for everyone, but mostly for me.
I
On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> I guess in the short term, the best I can think is keep those phys
> ioctls as a small patch on top of the upstream driver. It is ok to
> leave place-holder ioctl #'s in the upstream driver so that the ioctl
> #'s don't shift when you re
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/Kconfig |6 +-
drivers/gpu/drm/armada/armada_crtc.c | 186 +++--
drivers/gpu/drm/armada/armada_crtc.h |5 +-
3 files changed, 135 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/armada/K
This patch adds hardware cursor support to the DRM driver for the
Marvell Armada SoCs.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/Kconfig |7 +
drivers/gpu/drm/armada/armada_crtc.c | 201 ++
drivers/gpu/drm/armada/armada_crtc.h |8 ++
3
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 125 +++---
drivers/gpu/drm/armada/armada_hw.h |6 +-
2 files changed, 43 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_cr
Okay, so the previous set didn't contain all the updates I wanted.
That's partly because of the timespan between making those changes
and re-posting the RFC.
This time, the "Add Armada DRM driver" commit contains all the
updates it should've had from last time!
However, I'm posting a slightly dif
On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:
> On 06/09/13 21:29, Russell King wrote:
>> +/*
>> + * The spec is unclear about the polarities of the syncs.
>> + * We assume their non-inverted state is active high.
>> + */
>
> nit: "We confirmed their non-inv
This fixes the wrong sync generation and sync calculation for progressive
and interlaced modes. Sync timings for a bunch of modes have also been verified
with an oscilloscope near-end (TDA998x input) and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
---
Note: This patch is b
On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > wrote:
> >> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> >>> On Sun, Jun 9, 2013 at 3:29 PM, Russell
This fixes the wrong sync generation and sync calculation for progressive
and interlaced modes. Sync timings for a bunch of modes have also been verified
with an oscilloscope near-end (TDA998x input) and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
---
Note: This patch is b
On 06/10/2013 11:48 PM, Russell King - ARM Linux wrote:
On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:
On 06/09/13 21:29, Russell King wrote:
+static const struct armada_output_type armada_drm_conn_slave = {
+ .connector_type = DRM_MODE_CONNECTOR_HDMIA,
For a rew
On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:
> On 06/09/13 21:29, Russell King wrote:
>> +/*
>> + * The spec is unclear about the polarities of the syncs.
>> + * We assume their non-inverted state is active high.
>> + */
>
> nit: "We confirmed their non-inv
On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
> wrote:
> > +/* The mode_config.mutex will be held for this call */
> > +static int armada_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int
> > y,
> > + struct drm_framebuffer
ly other stuff) in there.
> >That'll prevent update_cdma_unlocked() from growing too much. It isn't
> >too bad right now, so maybe a helper isn't warranted yet, but I don't
> >think it'll hurt.
> >
> >>The not-so-beautiful aspect is that we do pm_runtime_get() in
> >>host1x_channel.c and pm_runtime_put() in host1x_cdma.c. For code
> >>readability it's be great to have them in the same file. I actually get
> >>questions every now and then because in downstream because of doing
> >>these operations in different files.
> >
> >With the above helper in place, we could move host1x_job_submit() to
> >job.c instead and have all the code in one file.
> >
> >Thierry
> >
> >* Unknown Key
> >* 0x7F3EB3A1
> >
>
> In downstream, we have 2 APIs which are wrapper over runtime PM
> calls. We call those from _submit and job complete.
>
> I wonder if we should follow the same here?
Can you post the corresponding wrappers to make it easier to discuss
them? If they just wrap runtime PM calls then they don't solve the
locality problems that Terje brought up.
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/20130610/956b386b/attachment-0001.pgp>
This fixes the wrong sync generation and sync calculation. It has only
been tested for progressive modes. Sync timings for a bunch of modes
have also been verified with an oscilloscope near-end (TDA998x input)
and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
---
Note: This
from Nicholas Miell ---
Also affects Double Fine's The Cave
--
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/20130610/
Current DRM slave encoder API conflicts with auto-registration of i2c client
when using DT probed clients. To allow DRM slave encoders passed by DT, this
patch adds a check to drm_i2c_encoder_init for a non-NULL .of_node on
i2c_board_info and calls an of_i2c helper to get the i2c client device
inst
On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote:
> I would like to get at least some of the driver upstream. I'd hate
> for it to have to live completely out of tree. I can think of a
> couple possibilities.
>
> 1) the best would be, if there was some way for the drm driver to know
> t
On Mon, Jun 10, 2013 at 03:59:34PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> wrote:
> > ARMADA_GEM_CREATE_PHYS is to deal with creating a gem buffer object for
> > a chunk of physical memory allocated by other means (eg, the Vmeta stuff.)
> > This allows
On 18:43 Fri 07 Jun , ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The string isn't modified so make it const.
>
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
Applied
Best Regards,
J.
> ---
On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
> wrote:
> > This patch adds support for the pair of LCD controllers on the Marvell
> > Armada 510 SoCs. This driver supports:
> > - multiple contiguous scanout buffers for video and graphics
On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
> wrote:
> > +/* The mode_config.mutex will be held for this call */
> > +static int armada_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int
> > y,
> > + struct drm_framebuffer
On Mon, 2013-06-10 at 13:59 +0200, Rafael J. Wysocki wrote:
> I happen to know that alternative solution to this problem is being worked on,
> so I'm going to wait until it is submitted and then we'll decide what to
> merge.
Sure.
> I'm slightly concerned about unregistering ACPI backlight cont
On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote:
> I would like to get at least some of the driver upstream. I'd hate
> for it to have to live completely out of tree. I can think of a
> couple possibilities.
>
> 1) the best would be, if there was some way for the drm driver to know
> t
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/1a67a773/attachment.html>
_
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part ------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/592c1047/attachment-0001.html>
, 68 insertions(+), 22
>>>> deletions(-)
>>>>
>>> Any comments for this series?
>>>
>>> Best regards,
>>> Tomasz
>>>
>> Ping.
>>
>> Best regards,
>> Tomasz
>>
>>
>>
> This series looks good to me.
>
> Acked-by: Joonyoung Shim
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/**majordomo-info.html<http://vger.kernel.org/majordomo-info.html>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/f19102c8/attachment.html>
On Mon, Jun 10, 2013 at 03:59:34PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> wrote:
> > ARMADA_GEM_CREATE_PHYS is to deal with creating a gem buffer object for
> > a chunk of physical memory allocated by other means (eg, the Vmeta stuff.)
> > This allows
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/2d5a18c4/attachment.html>
On Mon, Jun 10, 2013 at 7:38 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 07:17:22PM -0400, Rob Clark wrote:
>> On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
>> wrote:
>> > On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
>> >> I guess in the short term, the
On Mon, Jun 10, 2013 at 7:24 PM, Dave Airlie wrote:
>>>
>>> That makes the driver just be a dumb scanout only driver. Sorry,
>>> that *really* does not interest me one bit, because the CPU doing
>>> framebuffer accesses is pig slow.
>>
>> Well, yes that is basically what I am saying, unless we ca
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #35 from Tom Stellard ---
All of the proposed fixes have been merged to the LLVM tree, so what would be
helpful now is if people could post the output of R600_DEBUG=vs,fs,ps,sbdisasm
from the applications that don't work. It would al
On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
>> I guess in the short term, the best I can think is keep those phys
>> ioctls as a small patch on top of the upstream driver. It is ok to
>> leave place-holder ioctl #'s
On Mon, Jun 10, 2013 at 6:32 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
>> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
>> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
>> > wrote:
>> >> On Mon, Jun 10, 2013 at 11:57:32
On Mon, Jun 10, 2013 at 5:15 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote:
>> I would like to get at least some of the driver upstream. I'd hate
>> for it to have to live completely out of tree. I can think of a
>> couple possibilities.
>>
>> 1)
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/97655445/attachment.html>
On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
> wrote:
> > This patch adds support for the pair of LCD controllers on the Marvell
> > Armada 510 SoCs. This driver supports:
> > - multiple contiguous scanout buffers for video and graphics
org/archives/dri-devel/attachments/20130610/b267bd3c/attachment.html>
? ??2013-06-09 ? 19:01 -0400?Matthew Garrett ???
> Windows 8 leaves backlight control up to individual graphics drivers rather
> than making ACPI calls itself. There's plenty of evidence to suggest that
> the Intel driver for Windows doesn't use the ACPI interface, including the
> fact that it's br
On Mon, Jun 10, 2013 at 4:08 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 03:59:34PM -0400, Rob Clark wrote:
>> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
>> wrote:
>> > ARMADA_GEM_CREATE_PHYS is to deal with creating a gem buffer object for
>> > a chunk of physica
On Mon, Jun 10, 2013 at 09:31:38AM -0400, Konrad Rzeszutek Wilk wrote:
> On Sat, Jun 08, 2013 at 05:42:20PM +0100, James Simmons wrote:
> >
> > Hello
> >
> > Here is the first run at inspection of the VIA openchrome dri
> > driver. Now that the Xorg driver has been out over a year with KMS s
On Mon, Jun 10, 2013 at 7:38 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 07:17:22PM -0400, Rob Clark wrote:
>> On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
>> wrote:
>> > On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
>> >> I guess in the short term, the
On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
wrote:
> On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
>> I'd like to see all the ARM based drivers based on CMA if it can meet
>> their requirements
>> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/3fe80ec4/attachment.html>
On Mon, Jun 10, 2013 at 7:24 PM, Dave Airlie wrote:
>>>
>>> That makes the driver just be a dumb scanout only driver. Sorry,
>>> that *really* does not interest me one bit, because the CPU doing
>>> framebuffer accesses is pig slow.
>>
>> Well, yes that is basically what I am saying, unless we ca
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #32 from Tom Stellard ---
(In reply to comment #31)
> I rebuilt libclc from your repo now.
> Also update;rebuild;install the llvm,gallium,bfgminer.
>
> Same error still exists.
> Regards
> Erdem
Did you build it with the same versi
parent of hdmi and mixer block is mentioned as aclk200 which is
not correct. It is clocked by the ouput of aclk200_disp1. Hence
parent for mixer and hdmi clocks is changed to aclk200_disp1.
Signed-off-by: Rahul Sharma
---
drivers/clk/samsung/clk-exynos5250.c |4 ++--
1 file changed, 2 insert
Adding sysmmu clock for tv for exynos5250 SoC. It also
adds aclk200_disp1 mux which is the actual parent of the
disp1 block (contains hdmi, mixer, sysmmu_tv).
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5250-clock.txt |1 +
drivers/clk/samsung/clk-exynos5250
hdmi driver needs hdmiphy clock which is one of the parent
for hdmi mux clock. This is required while changing the parent
of mux clock.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5250-clock.txt |1 +
drivers/clk/samsung/clk-exynos5250.c
hdmi driver needs to change the parent of hdmi clock
frequently between pixel clock and hdmiphy clock. hdmiphy is
not stable after power on and for a short interval while changing
the phy configuration. For this duration pixel clock is used to
clock hdmi.
This patch is exposing the mux for changin
From: Arun Kumar K
This patch corrects the HDMI clock number given wrongly
in the documentation.
Signed-off-by: Arun Kumar K
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5250-clock.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Docu
Add clock changes for hdmi subsystem for exynos5250 SoC. These
include addition of new clocks like mout_hdmi and smmu_tv, associating
ID to clk_hdmiphy and some essential corrections.
This set is based on kukjin's for-next branch at
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.g
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #31 from Erdem U. Altınyurt ---
I rebuilt libclc from your repo now.
Also update;rebuild;install the llvm,gallium,bfgminer.
Same error still exists.
Regards
Erdem
--
You are receiving this mail because:
You are the assignee for the
>>
>> That makes the driver just be a dumb scanout only driver. Sorry,
>> that *really* does not interest me one bit, because the CPU doing
>> framebuffer accesses is pig slow.
>
> Well, yes that is basically what I am saying, unless we can find a
> different way (dmabuf? if there is some way to p
On 18:43 Fri 07 Jun , ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> The string isn't modified so make it const.
>
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-fbdev at vger.kernel.org
> Signed-off-by: Ville Syrj?l?
Applied
Best Regards,
J.
On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
>> I guess in the short term, the best I can think is keep those phys
>> ioctls as a small patch on top of the upstream driver. It is ok to
>> leave place-holder ioctl #'s
This patch is already posted at
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg18331.html
and
Reviewed-by: Doug Anderson
On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma
wrote:
> From: Arun Kumar K
>
> This patch corrects the HDMI clock number given wrongly
> in the document
On Mon, Jun 10, 2013 at 6:32 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
>> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
>> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
>> > wrote:
>> >> On Mon, Jun 10, 2013 at 11:57:32
>
> Here is the first run at inspection of the VIA openchrome dri
> driver. Now that the Xorg driver has been out over a year with KMS support
> most people should be able to use this feature. The driver is totaly
Just FYI this is a really bad idea, don't go releasing userspace code that u
On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
>> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>> wrote:
>> > This patch adds support for the pair of LCD controllers on the Marvell
>> > Armada 510 SoCs. This driver su
CC [M] drivers/gpu/drm/i915/i915_gem.o
/ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c: In function
‘i915_gem_object_bind_to_gtt’:
/ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c:3000:3: warning:
format ‘%ld’ expects argument of type ‘long int’, but argument 5 has
type ‘size_t’ [-Wformat]
On Mon, Jun 10, 2013 at 5:15 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote:
>> I would like to get at least some of the driver upstream. I'd hate
>> for it to have to live completely out of tree. I can think of a
>> couple possibilities.
>>
>> 1)
https://bugs.freedesktop.org/show_bug.cgi?id=64471
Nicholas Miell changed:
What|Removed |Added
CC||nmi...@gmail.com
--- Comment #7 from Ni
>
> Here's a small pull request for v3.11 that contains the GEM CMA DMA-BUF
> support patches. The content is identical to "[PATCH v3 0/5] GEM CMA DMA-BUF
> support" with acks picked up from the list.
Pulled, thanks,
Dave.
___
dri-devel mailing list
dri
https://bugs.freedesktop.org/show_bug.cgi?id=65438
--- Comment #11 from Tom Stellard ---
(In reply to comment #10)
> Yes, with your patch xfce starts fine.
> Do you need more info to find the real issue?
No, I think we have enough.
--
You are receiving this mail because:
You are the assignee f
On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> wrote:
>> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
>>> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>>> wrote:
>>> > This patch adds support for the pair of LCD contr
This patch renames check_timing to check_mode and removes the
unnecessary conversion of drm_display_mode to/from fb_videomode in
the hdmi driver.
v4:
1) Changed the commit message to add information related to renaming
the callbacks to check_mode.
2) Changed debug message to print 1/0 for interlac
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/cd6ac60c/attachment.html>
On Mon, Jun 10, 2013 at 4:08 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 03:59:34PM -0400, Rob Clark wrote:
>> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
>> wrote:
>> > ARMADA_GEM_CREATE_PHYS is to deal with creating a gem buffer object for
>> > a chunk of physica
on your mac.
--
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/20130610/069948bf/attachment.html>
Hi Matthew,
On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote:
> Windows 8 introduced new policy for backlight control by pushing it out to
> graphics drivers. This appears to have coincided with a range of vendors
> adding Windows 8 checks to their backlight control code which trigger ei
On Mon, 2013-06-10 at 13:59 +0200, Rafael J. Wysocki wrote:
> I happen to know that alternative solution to this problem is being worked on,
> so I'm going to wait until it is submitted and then we'll decide what to
> merge.
Sure.
> I'm slightly concerned about unregistering ACPI backlight cont
On Tue, Jun 04, 2013 at 02:11:27PM +0530, Mayuresh Kulkarni wrote:
> On Tuesday 28 May 2013 02:40 PM, Thierry Reding wrote:
> >* PGP Signed by an unknown key
> >
> >On Tue, May 28, 2013 at 08:45:03AM +0300, Terje Bergström wrote:
> >>On 27.05.2013 18:45, Thierry Reding wrote:
> >>>On Mon, May 27, 2
https://bugs.freedesktop.org/show_bug.cgi?id=65438
--- Comment #10 from had...@gmx.de ---
Yes, with your patch xfce starts fine.
Do you need more info to find the real issue?
--
You are receiving this mail because:
You are the assignee for the bug.
___
On 06/09/13 21:29, Russell King wrote:
> This patch adds support for the pair of LCD controllers on the Marvell
> Armada 510 SoCs. This driver supports:
> - multiple contiguous scanout buffers for video and graphics
> - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
>acceler
On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
>> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>> wrote:
>> > This patch adds support for the pair of LCD controllers on the Marvell
>> > Armada 510 SoCs. This driver su
On Sun, Jun 9, 2013 at 3:29 PM, Russell King
wrote:
> This patch adds support for the pair of LCD controllers on the Marvell
> Armada 510 SoCs. This driver supports:
> - multiple contiguous scanout buffers for video and graphics
> - shm backed cacheable buffer objects for X pixmaps for Vivante GP
https://bugs.freedesktop.org/show_bug.cgi?id=65254
--- Comment #13 from adam ---
I think the CPU/GPU si working as intended but it is not supported well by
anything but closed drivers or Windows. I hope this will be resolved soon.
--
You are receiving this mail because:
You are the assignee fo
From: Ville Syrj?l?
Rather than just printing the pixel format as a hex number, decode the
fourcc into human readable form, and also decode the LE vs. BE flag.
Keep printing the raw hex number too in case it contains non-printable
characters.
Some examples what the new drm_get_format_name() pro
On Sat, Jun 8, 2013 at 7:46 AM, Rafa? Mi?ecki wrote:
> 2013/6/7 :
>> From: Alex Deucher
>>
>> - remove adding 2 to checksum, this breaks certain monitors
>> - properly emit the AVI infoframe version, not emitting
>> the version breaks some monitors.
>>
>> This should fix blank screen when HDMI a
https://bugs.freedesktop.org/show_bug.cgi?id=65254
--- Comment #12 from Vladi ---
should I rma my cpu then?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lis
ight-if-firmware-.patch
Type: text/x-patch
Size: 1094 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/63595324/attachment.bin>
Maarten,
Sorry for the delay!
On Sun, Jun 09, 2013 at 08:58:44AM +0200, Maarten Lankhorst wrote:
> Hey,
>
> Op 06-06-13 09:28, Fengguang Wu schreef:
> > Hi Maarten,
> >
> > Thanks for the patch! I'll queue it for the tests.
> >
> >
> I haven't heard back from you yet, did it fix all lockdep iss
https://bugs.freedesktop.org/show_bug.cgi?id=65438
--- Comment #9 from Tom Stellard ---
Created attachment 80630
--> https://bugs.freedesktop.org/attachment.cgi?id=80630&action=edit
Possible Fix / Work Around
Can you try this patch? It should fix the segfault, but it looks to me like
the real
1 - 100 of 132 matches
Mail list logo
