of_get_display_timing(s) use of_find_node_by_name
to get child node, this is incorrect, of_get_child_by_name
should be used instead. The patch fixes it.
Small typo is also corrected.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
drivers/video/of_display_timing.c | 6 +++---
1 fi
of_display_timings_exist is implemented incorrectly.
It tries to find property instead of node.
The function is not used anyway so the patch removes it.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
drivers/video/of_display_timing.c | 20
include/video/of_di
I have a laptop with an internal 1366x768 (16:9) display and I have
connected and external 1920x1080 (16:9) monitor via HDMI. By default the
display gets mirrored with only 1024x768 (4:3) because this is the
highest common resolution of the two reported by xrandr. I can switch to
a large desktop fo
On Wed, Sep 25, 2013 at 09:56:52AM +0200, Daniel Vetter wrote:
> On Wed, Sep 25, 2013 at 01:17:52PM +1000, Dave Airlie wrote:
> > On Mon, Sep 23, 2013 at 12:14 AM, Michael S. Tsirkin
> > wrote:
> > > On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote:
> > >> On Wed, Aug 21, 2013 a
Backlight can't be modified with this patch set - neither with function
keys nor
with the gui. It is a step backward to v3.11-rc1
Video driver: i915
FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012
acpi_backlight=video works.
Jörg
2013/9/24 Igor Gnatenko
> On Tue, 2013-09-24 at
On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote:
> Backlight can't be modified with this patch set - neither with function
> keys nor
> with the gui. It is a step backward to v3.11-rc1
Thanks for the test.
Please check /sys/class/backlight, is there only one link file
intel_backlight?
Hi,
Those two independent patches fixes DT display_timings related code.
The first patch replaces of_find_node_by_name by of_get_child_by_name.
Usage of of_find_node_by_name in such context is incorrect:
- we need only direct child, and this function looks for following nodes
on implementation i
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner wrote:
> I assume if a spin_lock_irqsave doesn't really disable interrupts on a
> RT kernel with normal spinlocks then local_irq_disable won't really
> disable interrupts either?
>
That is incorrect. On PREEMPT_RT, you are right about
spin_loc
Sorry for the late reply, I was at Linux Plumbers, and had a bunch of
stuff to catch up on when I returned.
On Sat, 21 Sep 2013 00:07:36 +0200
Mario Kleiner wrote:
> Steven, would it then be acceptable to convert that "faster" lock into a
> raw_spinlock_t or is this unacceptable? If so, the
On Wed, 25 Sep 2013 10:49:36 +0300
Ville Syrjälä wrote:
> The preempt_disable/enable is not needed. The spinlock serves the same
> purpose already.
As stated, that was only for the -rt patch, as spin_lock_irqsave does
not disable preemption nor does it even disable interrupts.
But I agree, th
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner wrote:
> But given the new situation, your proposal is great! If we push the
> clock readouts into the get_scanoutpos routine, we can make this robust
> without causing grief for the rt people and without the need for a new
> separate lock for
2013/9/25 Jani Nikula :
> On Wed, 25 Sep 2013, Aaron Lu wrote:
>> On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote:
>>> Backlight can't be modified with this patch set - neither with
>>> function keys nor with the gui. It is a step backward to v3.11-rc1
>
> So both hotkeys and GUI work in
On Wed, Sep 25, 2013 at 02:00:02PM +0200, Daniel Vetter wrote:
> In
>
> commit 81e49f811404f428a9d9a63295a0c267e802fa12
> Author: Glauber Costa
> Date: Wed Aug 28 10:18:13 2013 +1000
>
> i915: bail out earlier when shrinker cannot acquire mutex
>
> SHRINK_STOP was added to tell the core s
On Wed, Sep 25, 2013 at 04:58:39PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 24 Sep 2013, Aaron Lu wrote:
> > locate handle for ACPI video by HID, the problem is, ACPI video node
> > doesn't really have HID defined(i.e. no _HID control method is defined
>
> ACPI video is supposed to atta
I urgently request your partnership in a transaction.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Sep 24, 2013 at 01:41:00PM +0900, Inki Dae wrote:
> I can't see to hold ->mmap_sem when it calls find_vma() anywhere else.
Er... What, in your opinion, would protect the result of find_vma(), if
not that? E.g. if another thread does munmap() on that area... vma isn't
refcounted; there
On Wed, Sep 25, 2013 at 01:34:30PM +0900, Inki Dae wrote:
> It seems that we can use a new anon file instead of using drm file to
> resolve the issue.
Could you describe what are you trying to achieve with that ioctl() and
what semantics do you want from normal mmap()?
___
On Wed, Sep 25, 2013 at 07:53:13PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, September 24, 2013 05:47:31 PM Aaron Lu wrote:
> > According to Matthew Garrett, "Windows 8 leaves backlight control up
> > to individual graphics drivers rather than making ACPI calls itself.
> > There's plenty of evi
Let's go futher.
25.09.2013, 22:58, "Alex Ivanov" :
> 25.09.2013, 21:28, "Konrad Rzeszutek Wilk" :
>> I took a look at the arch/parisc/kernel/pci-dma.c and I see that
>> is mostly a flat platform. That is bus addresses == physical addresses.
>> Unless it is an pclx or pclx2 CPU type (huh?)
Hi Dave,
Just a few fixes for regressions and other serious stuff.
Two fix state tracking mismatches, together with an additional patch that
I've submitted to stable (somehow forgotten to tag it) we should have them
fixed now (I hope).
Cheers, Daniel
The following changes since commit 4a10c2ac
On Wed, Sep 25, 2013 at 05:47:48PM +0100, Damien Lespiau wrote:
> Hi,
>
> So this series looks like a good candidate to be merged in one tree.
>
> Beside the new 3d flags added to the mode structure, the other new API
> is the SET_CLIENT_CAP ioctl. It seems that this new ioctl could already
> be
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #24 from Paul Bodenbenner ---
(In reply to comment #23)
> (In reply to comment #22)
> > Bad news. On 3.12rc2 those patches don't work anymore. Same problem like at
> > starting this crq. HDMI audio seems to be totally disabled...
>
>
On Thursday 26 September 2013 04:25 PM, Russell King - ARM Linux wrote:
On Thu, Sep 26, 2013 at 04:21:36PM +0530, Archit Taneja wrote:
Hi,
On Friday 20 September 2013 04:41 AM, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #14 from Bruno Wolff III ---
After a bit of learning, I believe I am on my way to bisecting for the problem
commit. I can only do 2 tests a day (maybe 3 on weekends) and will probably
finish on Monday.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #13 from Andy Furniss ---
(In reply to comment #9)
> (In reply to comment #1)
> > IIRC it was the XBMC people that wanted the ntsc variants in the first place
> > as their player defaults to sync to video exactly and would need to res
Allows you to enable dither in the display hardware
when the monitor supports lower a lower bpc than the
current framebuffer format.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cik.c | 13 +++-
drivers/gpu/drm/radeon/evergreen.c | 11 ++
drivers/g
https://bugs.freedesktop.org/show_bug.cgi?id=69805
--- Comment #7 from Tom Stellard ---
At first glance, this looks to me like a bug I've run into before where the
IfConverter merges two ALU clauses and ends up creating one that is too big.
--
You are receiving this mail because:
You are the as
The FMT blocks control how data is sent from the backend
of the display pipe to to monitor. Proper set up of the
FMT blocks are required for 30bpp formats. Additionally,
dithering can be enabled on for better display with 18 and
24bpp displays. The exception is LVDS/eDP which atom
takes care of
Wrong subject, I need to fix my script ;-)
-Daniel
On Thu, Sep 26, 2013 at 10:48 AM, Daniel Vetter wrote:
> Hi Dave,
>
> Just a few fixes for regressions and other serious stuff.
>
> Two fix state tracking mismatches, together with an additional patch that
> I've submitted to stable (somehow forg
On Thu, Sep 26, 2013 at 09:51:23AM +0200, Takashi Iwai wrote:
> Hi,
>
> sorry for the lat response, as I've been traveling in the last weeks.
>
> At Thu, 19 Sep 2013 22:53:02 +0100,
> Russell King wrote:
> >
> > This code sequence is unsafe in modules:
> >
> > static u64 mask = DMA_BIT_MASK(som
On 25/09/13 14:51, Andrzej Hajda wrote:
> of_display_timings_exist is implemented incorrectly.
> It tries to find property instead of node.
> The function is not used anyway so the patch removes it.
>
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Kyungmin Park
> ---
> drivers/video/of_display
On Thu, Sep 26, 2013 at 04:21:36PM +0530, Archit Taneja wrote:
> Hi,
>
> On Friday 20 September 2013 04:41 AM, Russell King wrote:
>> The correct way for a driver to specify the coherent DMA mask is
>> not to directly access the field in the struct device, but to use
>> dma_set_coherent_mask(). On
On 25/09/13 14:51, Andrzej Hajda wrote:
> of_get_display_timing(s) use of_find_node_by_name
> to get child node, this is incorrect, of_get_child_by_name
> should be used instead. The patch fixes it.
> Small typo is also corrected.
>
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Kyungmin Park
>
Hi,
On Friday 20 September 2013 04:41 AM, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direc
The comment suggests that intention was to limit 16M cards to save memory while
code did something a bit different.
32bpp is a lot more useful with today's apps, such as Weston's fbdev backend
and 32M cards are probably hardly used in apps where dedicating a bit more to
pinned console would matter
On 25.09.13 16:13, Steven Rostedt wrote:
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner wrote:
But given the new situation, your proposal is great! If we push the
clock readouts into the get_scanoutpos routine, we can make this robust
without causing grief for the rt people and without the
https://bugs.freedesktop.org/show_bug.cgi?id=69245
--- Comment #2 from klondike ---
Hi Tom, managed to get some time to test and it seems to be as you say.
With development version of mesa + libdrm the issue seems to be gone. I'll try
test development version of mesa 9.2 branch and if it also fa
On 25.09.13 09:49, Ville Syrjälä wrote:
On Wed, Sep 25, 2013 at 06:32:10AM +0200, Mario Kleiner wrote:
On 23.09.13 10:38, Ville Syrjälä wrote:
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hur
https://bugs.freedesktop.org/show_bug.cgi?id=68244
dagg changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
>>>2013/8/18 stompdagg...@yahoo.com :
>>> 2013/8/18 stompdagg...@yahoo.com :
>> does the following patch: "[FIX][PATCH] drm/radeon: fix WREG32_OR macro
>> setting bits in a register" which you've commited fixes my
issue?
>Yes, I believe so! Sorry, I forgot to ping you about tha
https://bugs.freedesktop.org/show_bug.cgi?id=69723
--- Comment #4 from Alexandre Demers ---
Definitively something about sclk or mclk and the voltages, but I haven't had
the time to dig deeper for now. I've added some printk to be sure everything
was being maxed as supposed. Could it be a combo b
https://bugs.freedesktop.org/show_bug.cgi?id=69723
--- Comment #5 from Alex Deucher ---
Take a look at ni_apply_state_adjust_rules() to see how the power state is
adjusted based on various factors.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=69670
--- Comment #4 from Michel Dänzer ---
As you can see in the kwin stdout output, radeonsi only supports OpenGL 2.1 in
Mesa 9.2. I suspect the problem happens when kwin tries to create an OpenGL 3.x
context, but I wonder if this is radeonsi specifi
https://bugs.freedesktop.org/show_bug.cgi?id=69723
--- Comment #6 from Alexandre Demers ---
(In reply to comment #5)
> Take a look at ni_apply_state_adjust_rules() to see how the power state is
> adjusted based on various factors.
Ok, but I may have to wait until this weekend or at the beginning
Hi
> As I suspected, on your system all the performance levels are the same:
(...)
> [8.961704]power level 0sclk: 45000 mclk: 5 vddc:
> 950
> [8.961706]power level 1sclk: 45000 mclk: 5 vddc:
> 950
> [8.961708]power level
On Thu, Sep 26, 2013 at 1:49 PM, wrote:
> Hi
>
>> As I suspected, on your system all the performance levels are the same:
> (...)
>> [8.961704]power level 0sclk: 45000 mclk: 5 vddc:
>> 950
>> [8.961706]power level 1sclk: 45000 mclk: 5 vddc:
2013/9/19 Russell King - ARM Linux :
> This email is only being sent to the mailing lists in question, not to
> anyone personally. The list of individuals is far to great to do that.
> I'm hoping no mailing lists reject the patches based on the number of
> recipients.
Huh, I think it was enough t
From: Paulo Zanoni
Hi
These patches allow us to run the "module_reload" script from intel-gpu-tools on
Haswell. The script basically just removes i915.ko and loads it again.
There's a memory corruption fix and also the fix for fd.o #67813. Notice that
the first patch fixes the case where we bo
From: Paulo Zanoni
VGA whack-a-mole!
We need VGA to be disabled whenever our driver is working. So even
without reproducible bugs this patch makes sense, but we do have a bug
solved by this patch.
If you boot a Haswell machine with eDP+HDMI, then kill your display
manager and run:
echo 0 >
From: Paulo Zanoni
For some reason, every single time I try to run module_reload
something tries to read the connector sysfs files. This happens
after we destroy the encoders and before we destroy the connectors, so
when the sysfs read triggers the connector detect() function,
intel_conector->enc
From: Paulo Zanoni
The consoles who need to do something when unbinding or binding can
optionally implement these functions.
The current problem I'm trying to solve is that when i915+fbcon is
loaded on Haswell, if we disable the power well (to save power) the
VGA interface gets completely disabl
From: Paulo Zanoni
And create fb_bind and fb_unbind fb_ops that the drivers can
implement.
The current problem I'm trying to solve is that when i915+fbcon is
loaded on Haswell, if we disable the power well (to save power) the
VGA interface gets completely disabled, so when we unbind fbcon we
nee
From: Paulo Zanoni
If we run the following command on Haswell when the power well is
disabled:
echo 0 > /sys/class/vtconsole/vtcon1/bind
then we'll get thousands of consecutive interrupts because something
is trying to touch registers that are on the disabled power well. So
before we unbind t
On Thursday, September 26, 2013 09:49:03 AM Jörg Otte wrote:
> 2013/9/25 Jani Nikula :
> > On Wed, 25 Sep 2013, Jörg Otte wrote:
> >> 2013/9/25 Jani Nikula :
> >>> On Wed, 25 Sep 2013, Aaron Lu wrote:
> On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote:
> > Backlight can't be mod
https://bugs.freedesktop.org/show_bug.cgi?id=69076
--- Comment #1 from David "okias" Heidelberger ---
now it flickers for even GLX (git does that since 2 days circa)
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-dev
Hi Russell,
Thank you for the patch.
On Thursday 19 September 2013 22:56:02 Russell King wrote:
> The code sequence:
> isp->raw_dmamask = DMA_BIT_MASK(32);
> isp->dev->dma_mask = &isp->raw_dmamask;
> isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> bypasses the architectures ch
On Thu, Sep 26, 2013 at 11:46 PM, Vincent Stehlé
wrote:
> Make sure static function do_gma_backlight_set() is only defined when
> CONFIG_BACKLIGHT_CLASS_DEVICE is defined, as it is never called otherwise.
>
> This fixes the following warning:
>
> drivers/gpu/drm/gma500/backlight.c:29:13: warning
https://bugs.freedesktop.org/show_bug.cgi?id=59649
--- Comment #19 from Shawn Starr ---
Currently testing with: radeon.dpm=0 radeon.dynclks=1
No crashes so far after two days of dynclks, but I am not ready to say the gpu
resets are DPM related only still
--
You are receiving this mail because:
On 16 September 2013 18:10, Inki Dae wrote:
> CCing devicetree,
>
>> -Original Message-
>> From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
>> Sent: Tuesday, September 10, 2013 5:28 PM
>> To: Sean Paul
>> Cc: Inki Dae; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
>> sw0312.kim; Lu
59 matches
Mail list logo
