Op 10-06-13 03:55, Fengguang Wu schreef:
> 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
Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all implementations, the slowpath
unlock path definitely isn't. This fixes the following lockdep splat:
[ 13.044313] [ cut here ]
[ 13.044367] WARNING: at /c/kernel-tests
On Mon, Jun 10, 2013 at 9:04 AM, Maarten Lankhorst
wrote:
> ^ Stacktrace points at the warning being called from panic. At that point I
> no longer trust anything to be sane.
> I don't know much about the panic handling in drm, but it's definitely not
> related to your original issue.
The locki
On Sun, Jun 09, 2013 at 07:01:39PM -0400, Matthew Garrett wrote:
> 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
> f
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
This patch is already posted at
http://www.mail-archive.com/linux-samsung-soc@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 documentatio
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
於 日，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
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
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
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
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
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
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
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
Applied.
Thanks,
Inki Dae
2013/6/6 Joonyoung Shim
> On 06/06/2013 03:14 AM, Tomasz Figa wrote:
>
>> On Sunday 19 of May 2013 13:26:57 Tomasz Figa wrote:
>>
>>> Hi,
>>>
>>> On Wednesday 01 of May 2013 21:02:25 Tomasz Figa wrote:
>>>
Much of the code in Exynos DRM subsystem is generic enoug
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
acceleration
-
Applied.
Thanks,
Inki Dae
2013/6/5 Seung-Woo Kim
> This patch set removes tracking logs and function name duplications.
> This is for the next tree and based on exynos-drm-next branch.
>
> YoungJun Cho (2):
> drm/exynos: Remove tracking log functions
> drm/exynos: Clean up logs for DRM_ERR
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 support
> most people should be able to use this feature. The driver is totaly
>
https://bugs.freedesktop.org/show_bug.cgi?id=65377
--- Comment #8 from Alex Deucher ---
Created attachment 80624
--> https://bugs.freedesktop.org/attachment.cgi?id=80624&action=edit
don't register a radeon backlight
This patch should skip adding a radeon backlight interface on your mac.
--
Y
https://bugs.freedesktop.org/show_bug.cgi?id=65611
Priority: medium
Bug ID: 65611
Assignee: dri-devel@lists.freedesktop.org
Summary: UVD accelerated decoding causes hangs (ARUBA - HD
7540D)
Severity: normal
Classification
Radeon probably needs something similar. See attached untested patch.
Alex
On Sun, Jun 9, 2013 at 7:01 PM, Matthew Garrett
wrote:
> 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
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 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
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=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
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
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
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
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 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
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 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
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
>
> 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=64471
Nicholas Miell changed:
What|Removed |Added
CC||nmi...@gmail.com
--- Comment #7 from Ni
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)
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]
>
> 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 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 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
>>
>> 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
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
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
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
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
>
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
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, 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 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 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 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 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
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
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
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, 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 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
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
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
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
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/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
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
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 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: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 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 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
On 2013? 06? 07? 20:24, Maarten Lankhorst wrote:
> Op 07-06-13 04:32, ??? schreef:
>> Hello Maarten,
>>
>> On 2013? 06? 05? 22:23, Maarten Lankhorst wrote:
>>> Op 31-05-13 10:54, Seung-Woo Kim schreef:
dma-buf attachment has only exporter private data, but importer private
data
ca
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
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130610/b6fb7fea/attachment.html>
Op 10-06-13 03:55, Fengguang Wu schreef:
> 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
Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all implementations, the slowpath
unlock path definitely isn't. This fixes the following lockdep splat:
[ 13.044313] [ cut here ]
[ 13.044367] WARNING: at /c/kernel-tests
On Mon, Jun 10, 2013 at 9:04 AM, Maarten Lankhorst
wrote:
> ^ Stacktrace points at the warning being called from panic. At that point I
> no longer trust anything to be sane.
> I don't know much about the panic handling in drm, but it's definitely not
> related to your original issue.
The locki
On Sun, Jun 09, 2013 at 07:01:39PM -0400, Matthew Garrett wrote:
> 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
> f
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
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
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
? ??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
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
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
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
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
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
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
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
, 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 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
_
> 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>
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 support
> most people should be able to use this feature. The driver is totaly
>
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>
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>
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/cd6ac60c/attachment.html>
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 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
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
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/3fe80ec4/attachment.html>
1 - 100 of 132 matches
Mail list logo
