Hi,
I am implementing HDMI hotplug feature for i.MX6 platform,
the basic function has already been done and works
But there is is an "issue",
When bootup system without HDMI cable attached, fbdev is initialised
with fbsize: 1024x768, after plug-in HDMI cable, I can see in debug log,
display's va
ow really.
Okay, I understand. Can you take this pull request for 3.11 instead?
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/20130620/3a96aadc/attachment.pgp>
An awful lot of drivers, mostly DRI drivers, are still mucking with
MTRRs directly as opposed to using ioremap_wc() or similar interfaces.
In addition to the architecture dependency, this is really undesirable
because MTRRs are a limited resource, whereas page table attributes are not.
Furthermore
On 06/20/2013 10:06 PM, Russell King - ARM Linux wrote:
> On Thu, Jun 20, 2013 at 09:46:03PM +0200, Sebastian Hesselbarth wrote:
>> +ref_pix = 3 + mode->hsync_start - mode->hdisplay;
>> +de_pix_s = mode->htotal - mode->hdisplay;
>> +de_pix_e = de_pix_s + mode->hdisplay;
>>
Thanks Mr. Dae, nothing else for this series.
On Fri, Jun 21, 2013 at 10:47 AM, Inki Dae wrote:
>
>
>
> 2013/6/20 Rahul Sharma
>>
>> Thanks Mr. Kim,
>>
>> I will post v4 with aforesaid change.
>>
>
> You don't need to re-post it. I gonna change it to "ARM/dts: change
> compatible strings for Ex
2013/6/20 Rahul Sharma
> Thanks Mr. Kim,
>
> I will post v4 with aforesaid change.
>
>
You don't need to re-post it. I gonna change it to "ARM/dts: change
compatible strings for Exynos5250 hdmi subsystem", and merge it. Is there
another you want?
Thanks,
Inki Dae
regards,
> Rahul Sharma.
>
> O
An awful lot of drivers, mostly DRI drivers, are still mucking with
MTRRs directly as opposed to using ioremap_wc() or similar interfaces.
In addition to the architecture dependency, this is really undesirable
because MTRRs are a limited resource, whereas page table attributes are not.
Furthermore
+Mike
On Tue, Jun 18, 2013 at 7:54 PM, Rahul Sharma wrote:
> With this patch, it is at par with Exynos5250 and Exynos4 clocks
> where sclk_pixel ID is assigned to a divider clock but in real,
> sclk_pixel is listed under gate clocks (enum value).
>
> Alternate to this, I can allocate a new ID, di
+Mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma wrote:
> hdmi driver needs to change the parent of hdmi clock
> to pixel clock or hdmiphy clock, based on the stability
> of hdmiphy. This patch is exposing the mux for changing
> the parent.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentati
+Mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma wrote:
> Listing sclk_hdmiphy at 0th position in the list of parents is
> causing wrong configuration in reg SRC_DISP10.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/clk/samsung/clk-exynos5420.c |2 +-
> 1 file changed, 1 insertion(+),
+Mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma wrote:
> Adding sysmmu clock for tv for exynos5420.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
> drivers/clk/samsung/clk-exynos5420.c |3 ++-
> 2 f
+Mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma wrote:
> Add sclk_hdmiphy to the list of exposed clocks. This is required
> by hdmi driver to change the parent of hdmi clock.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
> dri
+Mike
On Mon, Jun 10, 2013 at 4:31 PM, Rahul Sharma wrote:
> 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
> ---
>
+Mike
On Mon, Jun 10, 2013 at 4:31 PM, Rahul Sharma wrote:
> 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/bindin
+Mike
On Mon, Jun 10, 2013 at 4:31 PM, Rahul Sharma wrote:
> 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-clo
+Mike
On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma wrote:
> 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 clo
+Mike
On Mon, Jun 10, 2013 at 4:17 PM, Rahul Sharma wrote:
> 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
>>
>
On Fri, Jun 21, 2013 at 10:02 AM, Mike Turquette wrote:
> Quoting Kukjin Kim (2013-06-19 07:01:17)
>> On 06/19/13 13:04, Rahul Sharma wrote:
>> > + mike
>> >
>> Mike, I'm waiting for your reply on this. If you're OK, let me take this
>> series on top of exynos5420 stuff in samsung tree.
>>
>> Of c
This fixes the wrong sync generation and sync calculation. It has only
been tested 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
Quoting Kukjin Kim (2013-06-19 07:01:17)
> On 06/19/13 13:04, Rahul Sharma wrote:
> > + mike
> >
> Mike, I'm waiting for your reply on this. If you're OK, let me take this
> series on top of exynos5420 stuff in samsung tree.
>
> Of course, if any concerns, please let me know.
I never got these p
On Thu, Jun 20, 2013 at 09:46:03PM +0200, Sebastian Hesselbarth wrote:
> + ref_pix = 3 + mode->hsync_start - mode->hdisplay;
> + de_pix_s = mode->htotal - mode->hdisplay;
> + de_pix_e = de_pix_s + mode->hdisplay;
> + hs_pix_s = mode->hsync_start - mode->hdisplay;
>
> -Original Message-
> From: Lucas Stach [mailto:l.stach at pengutronix.de]
> Sent: Thursday, June 20, 2013 7:11 PM
> To: Inki Dae
> Cc: 'Russell King - ARM Linux'; 'Inki Dae'; 'linux-fbdev'; 'YoungJun Cho';
> 'Kyungmin Park'; 'myungjoo.ham'; 'DRI mailing list'; linux-arm-
> kernel at lis
Adding information about clocks to the binding documentation
for exynos mixer and hdmi.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/video/exynos_hdmi.txt | 14 +-
Documentation/devicetree/bindings/video/exynos_mixer.txt |4
2 files changed, 17 insert
From: Sachin Kamat
Exynos SoCs use pinctrl to configure GPIOs. Update the document
to reflect this change.
Signed-off-by: Sachin Kamat
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/video/exynos_hdmi.txt |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff -
Add pinctrl node for hdmi-hpd gpio pin to exynos5420
device tree files.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.
Add clocks for hdmi and mixer for exynos5420 SoC.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5420.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 93caef7..5fa4093 100644
--- a/arch/arm/boo
Add hdmi, mixer, ddc device tree nodes for Exynos 5420 SoC.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 20
arch/arm/boot/dts/exynos5420.dtsi |8
2 files changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/exynos54
Hdmi Subsystem nodes shares many properties across exynos5 SoCs
(exynos5250 and exyno5420). Common code is moved to exynos5.dtsi
which is included in exyno5250 and exynos5420 SoC files.
It also renames the hdmi and mixer nodes as per dt naming
convention in the format name at phy_add.
Signed-off-
From: Andrew Bresticker
This adds device-tree nodes for the i2c busses on Exynos
5420 platforms.
Signed-off-by: Andrew Bresticker
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5420.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/
I2C nodes shares many properties across exynos5 SoCs (exynos5250
and exyno5420). Common code is moved to exynos5.dtsi which is
included in exyno5250 and exynos5420 SoC files.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5.dtsi| 36 +
arch/arm/
Common properties for I2C and Hdmi Subsystem is moved to exynos5
dtsi file. It also adds Device tree nodes and clocks information
for exynos5420 SoC. It adds pinctrl node for hdmi hpd gpio and
update binding documents.
This patch is based on v3.11-next/soc-exynos5420-pinctrl branch
at http://git.k
> -Original Message-
> From: Lucas Stach [mailto:l.stach at pengutronix.de]
> Sent: Thursday, June 20, 2013 4:47 PM
> To: Inki Dae
> Cc: 'Russell King - ARM Linux'; 'Inki Dae'; 'linux-fbdev'; 'YoungJun Cho';
> 'Kyungmin Park'; 'myungjoo.ham'; 'DRI mailing list'; linux-arm-
> kernel at lis
On Thu, Jun 20, 2013 at 01:00:36PM +0200, Thierry Reding wrote:
> On Thu, Jun 20, 2013 at 12:46:21PM +0200, Laurent Pinchart wrote:
> > Hi Thierry,
> >
> > On Thursday 20 June 2013 12:40:26 Thierry Reding wrote:
> > > On Thu, Jun 20, 2013 at 12:17:25PM +0200, Laurent Pinchart wrote:
> > > > On Thu
Hi Linus,
one core fix, but mostly radeon fixes for s/r and big endian UVD support,
and a fix to stop the GPU being reset for no good reason, and crashing
people's machines.
Dave.
The following changes since commit df63d3ecbca514bad99513b2401448d19a9bb92e:
Merge tag 'drm-intel-fixes-2013-06
On Wed, Jun 19, 2013 at 01:45:45AM +0200, Laurent Pinchart wrote:
> Hello Adam,
>
> Ping ?
>
> Daniel, would it help getting the driver in v3.11 if I resubmit it now with a
> get_modes operation that just returns 0 ?
Yeah, I guess that works, too.
-Daniel
>
> On Friday 14 June 2013 16:03:19 D
> -Original Message-
> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
> Behalf Of Russell King - ARM Linux
> Sent: Thursday, June 20, 2013 3:29 AM
> To: Inki Dae
> Cc: linux-fbdev; DRI mai
From: Alex Deucher
Hi Dave,
Just one more fix for radeon. Patch from Jerome to avoid GPU
resets due to false positives when the ring is empty.
The following changes since commit c139b1ee4e36374af705660af6172d7477352792:
drm/radeon: fix UVD on big endian (2013-06-14 17:05:57 -0400)
are
* Maarten Lankhorst wrote:
> Well they've helped me with some of the changes and contributed some
> code and/or fixes, but if acked-by is preferred I'll use that..
Such contributions can be credited in the changelog, and/or copyright
notices, and/or the code itself. The signoff chain on the o
On Thu, Jun 20, 2013 at 12:45 AM, Laurent Pinchart
wrote:
> The enabled field has been removed from struct drm_plane. Don't use it
> in the driver.
Applied to -next,
Dave.
>>
>> Signed-off-by: Benoit Parrot
>
> Acked-by: Rob Clark
Applied to -next,
thanks,
Dave.
Op 20-06-13 13:55, Ingo Molnar schreef:
> * Maarten Lankhorst wrote:
>
>> Changes since RFC patch v1:
>> - Updated to use atomic_long instead of atomic, since the reservation_id
>> was a long.
>> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
>> - removed mutex_locked_set_res
On Fri, Jun 21, 2013 at 06:37:30AM +1000, Dave Airlie wrote:
> > git://anongit.freedesktop.org/tegra/linux.git drm/fixes
> >
> > for you to fetch changes up to 2b15aa0fd466a4b2defdfd84c0b5168804b3eb33:
> >
> > gpu: host1x: Rework CPU syncpoint increment (2013-06-20 12:21:38 +0200)
> >
> > I kno
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/fdadba66/attachment.html>
* Maarten Lankhorst wrote:
> +The algorithm that TTM came up with for dealing with this problem is quite
> +simple. [...]
'TTM' here reads like a person - but in reality it's the TTM graphics
subsystem, right?
Please clarify this portion of the text.
Thanks,
Ingo
||
--
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/20130620/2ec56af5/attachment.html>
* Maarten Lankhorst wrote:
> Changes since RFC patch v1:
> - Updated to use atomic_long instead of atomic, since the reservation_id was
> a long.
> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
> - removed mutex_locked_set_reservation_id (or w/e it was called)
> Changes si
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/6fee18aa/attachment.html>
> git://anongit.freedesktop.org/tegra/linux.git drm/fixes
>
> for you to fetch changes up to 2b15aa0fd466a4b2defdfd84c0b5168804b3eb33:
>
> gpu: host1x: Rework CPU syncpoint increment (2013-06-20 12:21:38 +0200)
>
> I know this comes awfully late and is much bigger than I'd like. It's
> all my f
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/1823eb33/attachment.html>
When CONFIG_PROVE_LOCKING is not enabled, more tests are expected to
pass unexpectedly, but there no tests that should start to fail that
pass with CONFIG_PROVE_LOCKING enabled.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c |8 +---
1 file changed, 5 insertions(+), 3 deleti
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 264 +++-
1 file changed, 261 insertions(+), 3 deletions(-)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index 37faefd..d554f3f 100644
--- a/lib/locking-selftest.c
+++ b/lib
None of the ww_mutex codepaths should be taken in the 'normal'
mutex calls. The easiest way to verify this is by using the
normal mutex calls, and making sure o.ctx is unmodified.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 62
This stresses the lockdep code in some ways specifically useful to
ww_mutexes. It adds checks for most of the common locking errors.
Changes since v1:
- Add tests to verify reservation_id is untouched.
- Use L() and U() macros where possible.
Changes since v2:
- Use the ww_mutex api directly.
From: Daniel Vetter
Injects EDEADLK conditions at pseudo-random interval, with exponential
backoff up to UINT_MAX (to ensure that every lock operation still
completes in a reasonable time).
This way we can test the wound slowpath even for ww mutex users where
contention is never expected, and th
Changes since RFC patch v1:
- Updated to use atomic_long instead of atomic, since the reservation_id was a
long.
- added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
- removed mutex_locked_set_reservation_id (or w/e it was called)
Changes since RFC patch v2:
- remove use of __mutex
This will allow me to call functions that have multiple arguments if fastpath
fails.
This is required to support ticket mutexes, because they need to be able to
pass an
extra argument to the fail function.
Originally I duplicated the functions, by adding
__mutex_fastpath_lock_retval_arg.
This e
Changes since v4:
- Some documentation cleanups.
- Added a lot more tests to cover all the DEBUG_LOCKS_WARN_ON cases.
- Added EDEADLK tests.
- Split off the normal mutex tests to a separate patch.
- Added a patch to not allow tests to fail that succeed with PROVE_LOCKING
enabled.
---
Daniel Vett
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/ef7d0ab4/attachment-0001.html>
T_ON() condition drop the
> > !dev->irq_enabled in case DRIVER_HAVE_IRQ isn't set.
>
> Or we could force drivers to set drm->irq_enabled, I'm fine with that as
> well.
> I can fix the documentation if that would be the preferred solution.
Thinking about it some more, the latter seems more appropriate. Consider
some driver that doesn't set DRIVER_HAVE_IRQ but also doesn't initialize
interrupts manually. If so it'll cause DRM_IOCTL_WAIT_VBLANK to block
indefinitely.
On the other hand perhaps the check at the beginning of drm_wait_vblank
should be improved. Maybe make it something like this:
if (drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
if (!drm_dev_to_irq(dev))
return -EINVAL;
if (!dev->irq_enabled)
return -EINVAL;
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/20130620/2d9f4896/attachment.pgp>
tion in other
textures is already starting.
--
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/20130620/21da2ace/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/82f8b661/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/1b611fdd/attachment.html>
L attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/5bce7ee3/attachment.html>
et drm->irq_enabled = 1, as otherwise things
> > > like DRM_IOCTL_WAIT_VBLANK won't work properly.
> >
> > That's only needed if DRIVER_HAVE_IRQ is set, otherwise the
> > drm_wait_vblank() function skips the irq_enabled check.
>
> Not quite. There's another check for dev->irq_enabled in the
> DRM_WAIT_ON() so it'll never actually block.
Indeed.
> Arguably this could be solved by making the DRM_WAIT_ON() condition drop the
> !dev->irq_enabled in case DRIVER_HAVE_IRQ isn't set.
Or we could force drivers to set drm->irq_enabled, I'm fine with that as well.
I can fix the documentation if that would be the preferred solution.
> I'll see if I can find the time to come up with a patch.
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/ccec4b09/attachment.pgp>
)
> function skips the irq_enabled check.
Not quite. There's another check for dev->irq_enabled in the
DRM_WAIT_ON() so it'll never actually block. Arguably this could be
solved by making the DRM_WAIT_ON() condition drop the !dev->irq_enabled
in case DRIVER_HAVE_IRQ isn't set.
I'll see if I can find the time to come up with a patch.
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/20130620/dac54ffe/attachment-0001.pgp>
;http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/3fe39495/attachment.pgp>
Hi Dave,
Could you please pull the following four shmob-drm patches for v3.11 ?
The following changes since commit dc28aa072f502433b6adc5c9ae8f56955c07580a:
gpu:drm:tilcdc: get preferred_bpp value from DT (2013-06-20 14:08:01 +1000)
are available in the git repository at:
git://linuxtv.org
ion manually
> you also need to manually set drm->irq_enabled = 1, as otherwise things
> like DRM_IOCTL_WAIT_VBLANK won't work properly.
That's only needed if DRIVER_HAVE_IRQ is set, otherwise the drm_wait_vblank()
function skips the irq_enabled check.
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/04e70f6b/attachment.pgp>
Am Donnerstag, den 20.06.2013, 17:24 +0900 schrieb Inki Dae:
[...]
> > > In addition, please see the below more detail examples.
> > >
> > > The conventional way (without dmabuf-sync) is:
> > > Task A
> > >
> > > 1. CPU accesses buf
> > > 2. Send the buf to Task B
> >
_VBLANK won't work properly.
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/20130620/47a949f9/attachment.pgp>
From: Alex Deucher
Hi Dave,
Just one more fix for radeon. Patch from Jerome to avoid GPU
resets due to false positives when the ring is empty.
The following changes since commit c139b1ee4e36374af705660af6172d7477352792:
drm/radeon: fix UVD on big endian (2013-06-14 17:05:57 -0400)
are
From: Dave Airlie
This uses the cursor hotspot info from userspace and passes
it to the qxl hw layer.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_display.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drive
From: Dave Airlie
So it looks like for virtual hw cursors on QXL we need to inform
the "hw" device what the cursor hotspot parameters are. This
makes sense if you think the host has to draw the cursor and interpret
clicks from it. However the current modesetting interface doesn't support
passing
Hello Rahul,
This patch is exactly same with v2 2/4 and only rebased on v3 1/3, so my
ack is valid for this patch.
On 2013? 06? 19? 21:51, Rahul Sharma wrote:
> Add support for exynos5420 mixer IP in the drm mixer driver.
>
> Signed-off-by: Rahul Sharma
Acked-by: Seung-Woo Kim
Anyway, this p
Am Donnerstag, den 20.06.2013, 09:17 +0100 schrieb Russell King - ARM
Linux:
> On Thu, Jun 20, 2013 at 09:47:07AM +0200, Lucas Stach wrote:
> > Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
> > >
> > > > -Original Message-
> > > > From: dri-devel-bounces+inki.dae=samsung.com
Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
>
> > -Original Message-
> > From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> > [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
> > Behalf Of Russell King - ARM Linux
> > Sent: T
Hi Rahul,
On Thursday 20 of June 2013 07:41:53 Rahul Sharma wrote:
> Hi Tomasz, Lucas,
>
> How does this patch look to you ? Please share your views.
Looks fine now. Have my
Reviewed-by: Tomasz Figa
for the whole series.
Best regards,
Tomasz
> regards,
> Rahul Sharma.
>
> On Wed, Jun 19, 2
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/5d354bf6/attachment-0001.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/c4274402/attachment.html>
On Thu, Jun 20, 2013 at 09:47:07AM +0200, Lucas Stach wrote:
> Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
> >
> > > -Original Message-
> > > From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> > > [mailto:dri-devel-bounces+inki.dae=samsung.com at lists
Hi,
I am implementing HDMI hotplug feature for i.MX6 platform,
the basic function has already been done and works
But there is is an "issue",
When bootup system without HDMI cable attached, fbdev is initialised
with fbsize: 1024x768, after plug-in HDMI cable, I can see in debug log,
display's v
From: Wei Yongjun
The dereference should be moved below the NULL test.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/i915/i915_gem_context.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
On Thu, Jun 20, 2013 at 01:00:36PM +0200, Thierry Reding wrote:
> On Thu, Jun 20, 2013 at 12:46:21PM +0200, Laurent Pinchart wrote:
> > Hi Thierry,
> >
> > On Thursday 20 June 2013 12:40:26 Thierry Reding wrote:
> > > On Thu, Jun 20, 2013 at 12:17:25PM +0200, Laurent Pinchart wrote:
> > > > On Thu
Hi Tomasz, Lucas,
How does this patch look to you ? Please share your views.
regards,
Rahul Sharma.
On Wed, Jun 19, 2013 at 6:21 PM, Rahul Sharma
wrote:
> This patch adds new combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which rep
https://bugzilla.kernel.org/show_bug.cgi?id=58021
wippbox at gmx.net changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Wed, Jun 19, 2013 at 01:45:45AM +0200, Laurent Pinchart wrote:
> Hello Adam,
>
> Ping ?
>
> Daniel, would it help getting the driver in v3.11 if I resubmit it now with a
> get_modes operation that just returns 0 ?
Yeah, I guess that works, too.
-Daniel
>
> On Friday 14 June 2013 16:03:19 D
https://bugs.freedesktop.org/show_bug.cgi?id=65963
--- Comment #2 from Damian Nowak ---
Thanks for taking a look at it. Package versions as follows. Pasting a
PKGBUILDs so you can see the flags for compilation.
extra/mesa 9.1.3-1
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/
https://bugs.freedesktop.org/show_bug.cgi?id=65968
Alex Deucher changed:
What|Removed |Added
Attachment #81105|text/plain |image/jpeg
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=65963
Alex Deucher changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=65958
--- Comment #2 from Alex Deucher ---
Does setting the env var RADEON_VA=0 in your /etc/environment fix the issue?
This looks like a mesa issue.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=65968
--- Comment #4 from Andreas Ringlstetter ---
PS:
I will not be able to test with 9.0 or 9.1 since one of the shaders causes a
segfault while compiling in these version. This has only recently (last 1-2
months) been fixed in git.
This was caused
https://bugs.freedesktop.org/show_bug.cgi?id=65968
Andreas Ringlstetter changed:
What|Removed |Added
Attachment #81105|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=65968
--- Comment #2 from Andreas Ringlstetter ---
Created attachment 81107
--> https://bugs.freedesktop.org/attachment.cgi?id=81107&action=edit
glxinfo log
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=65968
--- Comment #1 from Andreas Ringlstetter ---
Created attachment 81106
--> https://bugs.freedesktop.org/attachment.cgi?id=81106&action=edit
Xorg log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=65968
Priority: medium
Bug ID: 65968
Assignee: dri-devel@lists.freedesktop.org
Summary: Massive memory corruption in Planetary Annihilation
Alpha
Severity: normal
Classificatio
Op 20-06-13 13:55, Ingo Molnar schreef:
> * Maarten Lankhorst wrote:
>
>> Changes since RFC patch v1:
>> - Updated to use atomic_long instead of atomic, since the reservation_id
>> was a long.
>> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
>> - removed mutex_locked_set_res
When CONFIG_PROVE_LOCKING is not enabled, more tests are expected to
pass unexpectedly, but there no tests that should start to fail that
pass with CONFIG_PROVE_LOCKING enabled.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c |8 +---
1 file changed, 5 insertions(+), 3 deleti
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 264 +++-
1 file changed, 261 insertions(+), 3 deletions(-)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index 37faefd..d554f3f 100644
--- a/lib/locking-selftest.c
+++ b/lib
None of the ww_mutex codepaths should be taken in the 'normal'
mutex calls. The easiest way to verify this is by using the
normal mutex calls, and making sure o.ctx is unmodified.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 62
From: Daniel Vetter
Injects EDEADLK conditions at pseudo-random interval, with exponential
backoff up to UINT_MAX (to ensure that every lock operation still
completes in a reasonable time).
This way we can test the wound slowpath even for ww mutex users where
contention is never expected, and th
1 - 100 of 121 matches
Mail list logo
