Hi Linus,
like all good pull reqs this ends with a revert, so it must mean we
tested it,
This pull is missing nouveau, Ben has been stuck trying to track down a
very longstanding bug that revealed itself due to some other changes, I've
asked him to send you a direct pull request for nouveau o
On 2014? 08? 07? 22:17, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 20:09, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
On 2014? 08? 07? 18:09, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 0
On Thu, Aug 7, 2014 at 6:46 PM, Brian Norris
wrote:
> Hi,
>
> On Tue, Aug 05, 2014 at 08:08:57PM -0400, Nick Krause wrote:
>> On Tue, Aug 5, 2014 at 9:59 AM, Fengguang Wu
>> wrote:
>> > Hello,
>> >
>> > This is an old BUG that still lives in linux-next.
>> >
>> > [4.284620] device id = 2670
On 2014? 08? 07? 20:09, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 18:09, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
On 2014? 08? 07? 15:58, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 0
does ipu-v3 need to
select GENERIC_IRQ_CHIP
otherwise on my arm test builds I get a failure to link due to missing
irq symbols.
Dave.
On 2014? 08? 07? 18:09, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 15:58, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
2014-08-06 16:43 GMT+09:00 Thierry Reding :
> [...]
> As far as I can tel
On Thu, Aug 07, 2014 at 11:31:15AM -0400, Alex Deucher wrote:
> On Thu, Aug 7, 2014 at 11:27 AM, Dan Carpenter
> wrote:
> > We can easily return -ENOMEM here if kzalloc() fails.
> >
> > Signed-off-by: Dan Carpenter
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
> > b/drivers/gpu/drm/ra
We can easily return -ENOMEM here if kzalloc() fails.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drivers/gpu/drm/radeon/radeon_vm.c
index ccae4d9..d15d987 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -483,6 +483,
Hi Dave,
Latest version of the userptr stuff after yesterday's discussions.
If you're ok with it, please apply, otherwise, we'll push to 3.18.
The following changes since commit 21d70354bba9965a098382fc4d7fb17e138111f3:
drm: move drm_stub.c to drm_drv.c (2014-08-06 19:10:44 +1000)
are availab
Hi
On Thu, Aug 7, 2014 at 3:04 PM, Chris Wilson
wrote:
> Despite the claims of
>
> commit 48ba813701eb14b3008edefef4a0789b328e278c
> Author: David Herrmann
> Date: Tue Jul 22 18:46:09 2014 +0200
>
> drm: drop redundant drm_file->is_master
>
> drm_file->is_master is not synomous with havin
Am 07.08.2014 um 17:01 schrieb Jerome Glisse:
> On Thu, Aug 07, 2014 at 04:30:33PM +0200, Christian K?nig wrote:
>> From: Christian K?nig
>
> Can we get proper change log with motivation for doing that, use case,
> why it can not be done any other ways ...
>
> Change log is invaluable information
The GFX CP is split up into two different engines - the PFP and the ME
(starting with SI you additionally get the CE as well).
The PFP is responsible for reading commands out of memory and forwarding
it to the ME (or the CE). Some commands can be executed on the PFP as
well, like simple registe
So what's difference between WRITE_DATA with PFP vs ME? Would it also
be preferable for DMA_DATA and COPY_DATA?
Marek
On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher wrote:
> On Thu, Aug 7, 2014 at 3:46 AM, Michel D?nzer wrote:
>> From: Michel D?nzer
>>
>> Not doing this causes piglit hangs[0] on
I'm 100% sure that I've fixed that as well with a follow up patch. Looks
like that one didn't made it into 3.17
Christian.
Am 07.08.2014 um 17:31 schrieb Alex Deucher:
> On Thu, Aug 7, 2014 at 11:27 AM, Dan Carpenter
> wrote:
>> We can easily return -ENOMEM here if kzalloc() fails.
>>
>> Signe
Am 07.08.2014 um 16:32 schrieb Alex Deucher:
> On Thu, Aug 7, 2014 at 7:33 AM, Christian K?nig
> wrote:
>> From: Marco A Benatto
>>
>> Adding a Frames Per Second estimation logic on UVD handles
>> when it has being used. This estimation is per handle basis
>> and will help on DPM profile calcula
On 08/07/2014 08:50 AM, Daniel Vetter wrote:
> On Thu, Aug 7, 2014 at 2:50 AM, Mario Kleiner
> wrote:
>> I'm not sure about all the new embedded drivers, if they have hw vblank
>> counters?
> Quick grep says a lot don't have it or at least not implemented - they
> use drm_vblank_count. Thinking ab
05,
> >> }, {
> >> + .compatible = "optronics,b101xtn01",
> >
> > From the commit message this panel is from AU Optronics, so it should
> > use the auo vendor prefix.
>
> so, "auo,b101xtn01" works for everyone?
Yeah, that's consistent with the other ones from AUO, so looking good to
me.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/aabfedfd/attachment.sig>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/2826ed8a/attachment.html>
On 2014? 08? 07? 15:58, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>> 2014-08-06 16:43 GMT+09:00 Thierry Reding :
>>> On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote:
On 2014? 08? 05? 20:12, Thierry Reding wrote:
>>> [...]
> I think that low
From: Michel D?nzer
Not doing this causes piglit hangs[0] on my Cape Verde card. No issues on
Bonaire and Kaveri though.
[0] Same symptoms as those fixed on CIK by 'drm/radeon: set VM base addr
using the PFP v2'.
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_vm.c | 4 +++-
1
This patch is a DRM Driver for Rockchip Socs, driver provides an abstraction
for the graphics hardware, such as lcd controller and connector interface.
Signed-off-by: mark yao
---
changes since v1:
Adviced by Daniel Vetter:
- Switch to universal plane API's
---
drivers/gpu/drm/Kconfig
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_drv.c| 3 ++-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_vm.c | 3 +++
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_dr
From: Christian K?nig
This patch allows to create zero sized TTM buffer
objects for driver internal use.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drive
On Wed, 6 Aug 2014 22:29:54 +0200 Daniel Vetter wrote:
> On Wed, Aug 06, 2014 at 10:03:46PM +0300, Mihai Don?u wrote:
> > Hi,
> >
> > This just happened to me:
> >
> > Aug 6 21:37:37 mdontu-l kernel: [ cut here ]
> > Aug 6 21:37:37 mdontu-l kernel: WARNING: CPU: 3 PID: 4
Ping, Thierry?
On Fri, Jul 25, 2014 at 11:47 PM, Alexandre Courbot
wrote:
> Use the new devm_gpiod_get_optional() to simplify the probe code.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/panel/panel-simple.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
On 2014? 07? 29? 22:16, Andrzej Hajda wrote:
> On 07/29/2014 02:08 PM, Inki Dae wrote:
>> On 2014? 07? 29? 20:39, Andrzej Hajda wrote:
>>> On 07/29/2014 05:42 AM, Inki Dae wrote:
On 2014? 07? 29? 00:50, Andrzej Hajda wrote:
> On 07/28/2014 04:00 AM, Inki Dae wrote:
>> This patch adds L
t;> should be transmitted in low power mode (see LP Transmission in 2.1
> >>> "Definitions" of the MIPI DSI specification).
> >>>
> >>
> >> Hm.. I see. I meant,
> >>
> >> if (flags & MIPI_DSI_MSG_USE_LPM)
> >>disable HS clock <- required.
> >>
> >> transmit command data <- in LPM.
> >
> > No. Disabling the HS clock is not required for LPM mode. In fact if the
> > peripheral specifies that it doesn't support non-continuous mode then
> > the HS clock must *never* be disabled as long as the peripheral is in
> > use.
> >
> > MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
> > need to be considered separately.
>
> I mentioned already LPM and NON_CONTINUOUS are unrelated.
>
> It seems that you say the only way to transfer command data in LPM is
> non-continuous clock mode.
No, that's not what I'm saying.
> However, you said and also the spec says, "Non-continuous mode simply
> means that the clock lane enters LP-11 between HS transmissions".
> Doesn't *between HS transmissions" mean the command data is transmitted
> in HS, *not in LPM*, and clock lane enters LP-11 between them?
Not necessarily. You can transmit command packets in high-speed mode,
but you don't have to. If you transmit packets in low power mode, then
the HS clock isn't involved in the transmission and the clock lane may
enter LP-11 during the whole transmission (if non-continuous mode is
enabled).
> We have one lcd panel, nt35502a, which needs LPM transfer support
> because it should receive some initial commands with LPM by default
> hardware setting, and we faced with that the panel didn't work without
> disabling HS clock before transmitting command data. How can you explain
> that?
The specification clearly says that (5.6.1 "Clock Requirements"):
All DSI transmitters and receivers shall support continuous
clock behavior on the Clock Lane, and optionally may support
non-continuous clock behavior.
So if you need to "disable HS clock" for command data to be successfully
transmitted, either the panel doesn't comply to the specification, or
whatever you do to "disable HS clock" doesn't do what you think it does.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/5e5efd5b/attachment.sig>
Hi,
On Tue, Aug 05, 2014 at 08:08:57PM -0400, Nick Krause wrote:
> On Tue, Aug 5, 2014 at 9:59 AM, Fengguang Wu
> wrote:
> > Hello,
> >
> > This is an old BUG that still lives in linux-next.
> >
> > [4.284620] device id = 2670
> > [4.286157] SBC-GXx flash: IO:0x258-0x259 MEM:0xdc000-0xdf
On Thu, Aug 7, 2014 at 11:32 AM, Christian K?nig
wrote:
> Am 07.08.2014 um 16:32 schrieb Alex Deucher:
>
>> On Thu, Aug 7, 2014 at 7:33 AM, Christian K?nig
>> wrote:
>>>
>>> From: Marco A Benatto
>>>
>>> Adding a Frames Per Second estimation logic on UVD handles
>>> when it has being used. This
https://bugzilla.kernel.org/show_bug.cgi?id=81021
--- Comment #14 from Alex Deucher ---
The information in radeon_pm_info represents the current GPU power state. It
will vary dynamically with GPU load. E.g., if you are rendering stuff on your
desktop, the GPU clocks and voltages will ramp up/do
https://bugzilla.kernel.org/show_bug.cgi?id=81021
--- Comment #13 from LiNuxXer ---
(In reply to Alex Deucher from comment #11)
> Yes, I can add a module parameter to force it on.
That's great news, thank you! I was beginning to think that I'd have to compile
my kernel from now on.
BTW, I notic
upports non-continuous mode, then the DSI host should automatically
> >>> disable the HS clock between high-speed transmissions. That means if a
> >>> packet is transmitted in low power mode the DSI host will not be
> >>> transmitting in high-speed mode and therefore disable the HS clock.
> >>
> >> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
> >> for LPM transfer, lanes should be LP-11 state and also HS clock of the
> >> host controller should be disabled.
> >
> > No. I don't think any transmissions can happen when all lanes are in
> > LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
> > should be transmitted in low power mode (see LP Transmission in 2.1
> > "Definitions" of the MIPI DSI specification).
> >
>
> Hm.. I see. I meant,
>
> if (flags & MIPI_DSI_MSG_USE_LPM)
>disable HS clock <- required.
>
> transmit command data <- in LPM.
No. Disabling the HS clock is not required for LPM mode. In fact if the
peripheral specifies that it doesn't support non-continuous mode then
the HS clock must *never* be disabled as long as the peripheral is in
use.
MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
need to be considered separately.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/9366efea/attachment.sig>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/88567fc5/attachment.html>
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/0be2c5b8/attachment.html>
ions. That would be P8 or 8 pipes.
--
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/20140807/6d2a6e16/attachment.html>
Despite the claims of
commit 48ba813701eb14b3008edefef4a0789b328e278c
Author: David Herrmann
Date: Tue Jul 22 18:46:09 2014 +0200
drm: drop redundant drm_file->is_master
drm_file->is_master is not synomous with having drm_file->master ==
drm_file->minor->master. This is because drm_file->
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/dfe0ecca/attachment.html>
been optimized out
(gdb) p rscreen->info
value has been optimized out
(gdb) p pipe_interleave_bytes
$1 = 256
(gdb) p num_pipes
$2 = 12
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http:/
From: Marco A Benatto
Adding a Frames Per Second estimation logic on UVD handles
when it has being used. This estimation is per handle basis
and will help on DPM profile calculation.
v2 (chk): fix timestamp type, move functions around and
cleanup code a bit.
Signed-off-by: Marco A Ben
https://bugzilla.kernel.org/show_bug.cgi?id=81021
--- Comment #12 from Alex Deucher ---
Created attachment 145411
--> https://bugzilla.kernel.org/attachment.cgi?id=145411&action=edit
add a bapm module parameter
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=81021
--- Comment #11 from Alex Deucher ---
(In reply to LiNuxXer from comment #10)
>
> 3) One question remains -- can't bapm enabling become at least a parameter?
> Or is it already?
Yes, I can add a module parameter to force it on.
--
You are rece
gt; > supports non-continuous mode, then the DSI host should automatically
> > disable the HS clock between high-speed transmissions. That means if a
> > packet is transmitted in low power mode the DSI host will not be
> > transmitting in high-speed mode and therefore disa
On Thu, Aug 7, 2014 at 11:38 AM, Marek Ol??k wrote:
> So what's difference between WRITE_DATA with PFP vs ME? Would it also
> be preferable for DMA_DATA and COPY_DATA?
The PFP comes before the ME in the pipeline. Note that there is no
PFP (or CE) on the compute queues so we can't use PFP (or CE)
arco Antonio Benatto
Linux user ID: #506236
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/c5f6542e/attachment.html>
On Thu, Aug 7, 2014 at 11:27 AM, Dan Carpenter
wrote:
> We can easily return -ENOMEM here if kzalloc() fails.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index ccae4d9..d15d987 100644
> --- a/drivers/gpu/drm/radeo
On Tue, Aug 05, 2014 at 04:38:16PM +0530, sonika.jindal at intel.com wrote:
> From: Sonika Jindal
>
> Rename the defines to have levels instead of values for vswing and pre-emph
> levels as the values may differ in other scenarios like low vswing of eDP 1.4
> where the values are different.
> Upd
, whereas the MSG_LPM flag is only used to mark a
packet to be transmitted in low power mode (as opposed to high speed
mode). For peripherals that don't support non-continuous mode the
NON_CONTINUOUS flag needs to be set. But the driver for the peripheral
can still initiate low power mode packet transmissions by setting the
MSG_LPM flag.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/1a3904eb/attachment.sig>
On Thu, Aug 07, 2014 at 04:30:33PM +0200, Christian K?nig wrote:
> From: Christian K?nig
Can we get proper change log with motivation for doing that, use case,
why it can not be done any other ways ...
Change log is invaluable information and empty change log is the worst
thing ever.
>
> Sign
440 {
> };
That's pretty much the same thing that I proposed, except that it
reverses the link between the two. In fact I tried something similar to
that before, but it has a couple of problems: if the secondary device
does not have a compatible string (that's probably not valid in device
tree to begin with) then there's no way for the device to report what
format it expects or what number of lanes it uses. But those are
parameters that are needed to set up the DSI (and display controllers).
One other problem with the above is that the dependency implied by your
"secondary_dsi" property is the wrong way around. The above would mean
that &panel requires &dsiB's services to function, but that's not the
case. If anything it's the other way around. &panel could still work
standalone (though only drive the left half of the screen).
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/d374b834/attachment-0001.sig>
On Thu, Aug 7, 2014 at 7:32 AM, Dave Airlie wrote:
> does ipu-v3 need to
>
> select GENERIC_IRQ_CHIP
>
> otherwise on my arm test builds I get a failure to link due to missing
> irq symbols.
Which defconfig you use in order to trigger the failure?
On 08/07/2014 09:25 AM, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote:
>> Hi Thierry,
>>
>> Nice case.
>>
>> On 08/05/2014 05:39 PM, Thierry Reding wrote:
>>> Hi everyone,
>>>
>>> I've been working on adding support for a panel that uses what's
>>> commonly k
On Thu, Aug 7, 2014 at 7:33 AM, Christian K?nig
wrote:
> From: Marco A Benatto
>
> Adding a Frames Per Second estimation logic on UVD handles
> when it has being used. This estimation is per handle basis
> and will help on DPM profile calculation.
>
> v2 (chk): fix timestamp type, move functions
ecause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/e594c488/attachment.html>
_flush-related-updates.patch
Type: text/x-diff
Size: 3275 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/d03eda17/attachment-0001.patch>
deletions(-)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/b481e2c5/attachment.sig>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/5771aca5/attachment.sig>
ilable
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/c7c0ad90/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=81021
--- Comment #10 from LiNuxXer ---
(In reply to Alex Deucher from comment #8)
> I'm not sure why you don't think you need a GPU driver installed. When the
> driver is installed it not only allows the GPU to dynamically adjust it
> clocks and volta
Am 07.08.2014 um 08:55 schrieb Daniel Vetter:
> On Wed, Aug 06, 2014 at 11:45:48PM -0400, Jerome Glisse wrote:
>> On Wed, Aug 06, 2014 at 10:24:31PM +0200, Daniel Vetter wrote:
>>> On Wed, Aug 06, 2014 at 02:34:16PM -0400, Jerome Glisse wrote:
On Wed, Aug 06, 2014 at 07:17:25PM +0200, Christia
From: Christian K?nig
It needs to be anonymous memory (no file mappings)
and we are requried to install an MMU notifier.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/d
From: Christian K?nig
Whenever userspace mapping related to our userptr change
we wait for it to become idle and unmap it from GTT.
v2: rebased, fix mutex unlock in error path
v3: improve commit message
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/Kconfig| 1 +
drivers
From: Christian K?nig
This way we test userptr availability at BO creation time instead of first use.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c | 18 +-
include/uapi/drm/radeon_drm.h | 1 +
2 files changed, 18 insertions(+), 1 deletion(-)
di
From: Christian K?nig
Avoid problems with writeback by limiting userptr to anonymous memory.
v2: add commit and code comments
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c | 3 ++-
drivers/gpu/drm/radeon/radeon_ttm.c | 10 ++
include/uapi/drm/radeon_drm.h
From: Christian K?nig
This patch adds an IOCTL for turning a pointer supplied by
userspace into a buffer object.
It imposes several restrictions upon the memory being mapped:
1. It must be page aligned (both start/end addresses, i.e ptr and size).
2. It must be normal system memory, not a poin
https://bugzilla.kernel.org/show_bug.cgi?id=81021
--- Comment #9 from LiNuxXer ---
(In reply to Kertesz Laszlo from comment #3)
> [...]
> Additionally, even if fglrx eables turbo core boost, sometimes something
> weird happens and even the nominal speed is reported as maximum, in effect
> you can
On Wed, Aug 06, 2014 at 04:31:30PM -0400, Rob Clark wrote:
> LVDS panel, make/model described as:
>
> AU Optronics Corporation - B101XTN01.0 (H/W:0A)
>
> See:
> http://www.encore-electronic.com/media/B101XTN01.0.pdf
I've made it a custom to mention which board a panel is used on in the
commit me
Add a module paramter to enable bapm on APUs. It's disabled
by default on certain APUs due to stability issues. This
option makes it easier to test and to enable it on systems that
are stable.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=81021
Signed-off-by: Alex Deucher
---
drivers/gpu/d
On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote:
> Hi Thierry,
>
> Nice case.
>
> On 08/05/2014 05:39 PM, Thierry Reding wrote:
> > Hi everyone,
> >
> > I've been working on adding support for a panel that uses what's
> > commonly known as dual-channel DSI. Sometimes this is referre
o data in HS mode.
Like I said, with low power mode you can't meet the bandwidth
requirements of any reasonable resolution and framerate, so I would
assume that video data can always be transmitted in HS mode. So even if
some device required video data transmission to use low power mode, then
that should be considered the oddball peripheral and it could be handled
by an extra flag.
By default we should still assume high-speed mode for video data packet
transmissions. We can address those quirks when we actually encounter
peripherals that don't work under those assumptions.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/769ccea8/attachment.sig>
On Thu, Aug 7, 2014 at 2:50 AM, Mario Kleiner
wrote:
> Ok, good with me, thanks. Ville, thanks for the review. I'll review and test
> your vblank series next week when i have access to suitable machines and
> enough time. I need to go through this in single-step mode, vblank on/off
> changes alway
On Wed, Aug 06, 2014 at 11:45:48PM -0400, Jerome Glisse wrote:
> On Wed, Aug 06, 2014 at 10:24:31PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 06, 2014 at 02:34:16PM -0400, Jerome Glisse wrote:
> > > On Wed, Aug 06, 2014 at 07:17:25PM +0200, Christian K?nig wrote:
> > > > Am 06.08.2014 um 18:08 sc
Hi Thierry,
Nice case.
On 08/05/2014 05:39 PM, Thierry Reding wrote:
> Hi everyone,
>
> I've been working on adding support for a panel that uses what's
> commonly known as dual-channel DSI. Sometimes this is referred to as
> ganged-mode as well.
>
> What is it, you ask? It's essentially a hack t
On Thu, Aug 7, 2014 at 3:33 AM, Thierry Reding
wrote:
> On Wed, Aug 06, 2014 at 04:31:30PM -0400, Rob Clark wrote:
>> LVDS panel, make/model described as:
>>
>> AU Optronics Corporation - B101XTN01.0 (H/W:0A)
>>
>> See:
>> http://www.encore-electronic.com/media/B101XTN01.0.pdf
>
> I've made it a
On Thu, Aug 7, 2014 at 2:50 AM, Mario Kleiner
wrote:
> I'm not sure about all the new embedded drivers, if they have hw vblank
> counters?
Quick grep says a lot don't have it or at least not implemented - they
use drm_vblank_count. Thinking about this, should we use that as a
signal to also set d
Hi YoungJun, Thierry,
On 07/31/2014 06:14 AM, YoungJun Cho wrote:
> This patch adds some generic functions for DCS like below
> to standize on common APIs rather than per-driver
> implementations.
>
> mipi_dcs_enter_sleep_mode() / mipi_dcs_exit_sleep_mode()
> - These are required to disable / enab
ug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/f1fba7f0/attachment.html>
es/dri-devel/attachments/20140807/200690f1/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/a193dc34/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/443e1d98/attachment-0001.html>
> state on destruction v2".
Christian, any ideas?
--
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/20140807/8f21211b/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/3514cee5/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/1da76fa8/attachment.html>
sbox-${VERSION}.conf.
--
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/20140807/6d15a331/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/f8770736/attachment-0001.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/56b983fd/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/eb5c9220/attachment.html>
lists.freedesktop.org/archives/dri-devel/attachments/20140807/58e6e2e8/attachment.html>
On 08/06/2014 03:57 PM, Daniel Vetter wrote:
> On Wed, Aug 06, 2014 at 01:51:41PM +0300, Ville Syrj?l? wrote:
>> On Wed, Aug 06, 2014 at 03:22:46AM +0200, Mario Kleiner wrote:
>>> Calling vblank_disable_fn() will cause that function to no-op
>>> if !dev->vblank_disable_allowed for some kms drivers,
2014-08-06 16:43 GMT+09:00 Thierry Reding :
> On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote:
>> On 2014? 08? 05? 20:12, Thierry Reding wrote:
> [...]
>> > I think that low power mode is more often used for command transmission
>> > (in host-driven mode). I'm not sure how much sense it re
u 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/20140807/62331b79/attachment.html>
14.04 only.
--
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/20140807/2e481b0d/attachment-0001.html>
91 matches
Mail list logo
