date:20140807

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

2014-08-07 Thread Inki Dae

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 really makes to
>> > transmit video data in low power mode. It also seems like low power mode
>> > is what all peripherals need to support (if they can do command mode).
>> > Hence I'd like to propose the attached patch that makes all command
>> > messages use low power mode.
>>
>> To use low power mode, I think SoC drivers should add more codes:
>> checking xxx_MSG_LPM, and maybe disabling HS clock. My patch does
>> exactly that,
>> http://www.spinics.net/lists/linux-samsung-soc/msg34866.html
>
> I agree in general that DSI host drivers need to check the flags to make
> a decision about which mode to enable. But your patch also introduces
> additional flags that I don't think are necessary (at least for any of
> the use-cases discussed so far).
>
> As I understand it the MIPI_DSI_MODE_CMD_LPM and MIPI_DSI_MODE_VIDEO_LPM
> flags that you introduce would advertise that the device only supports
> low power mode for command or video modes respectively. However, I doubt

Not so. My intention is to add LPM support for video and command data
transfers because mipi-dsi framework enforces implicitly using HS mode
for
by default.

> that there really are devices that only support low power video mode. It
> wouldn't make much sense because you'd get a maximum of 10 MHz for the
> clock, which is about 1.6 frames per second at 1920x1080 resolution (not
> counting blanking). And even with lower resolutions such as 1024x768 it
> would be somewhere around 4 frames per second. And I think it's
> reasonable to assume that we'll see that kind of resolution become very
> rare in the future.
>
> So my point is that devices which support video mode will always support
> high speed mode for video transmission too. Similarly, if a device
> supports command mode, then it will likely support it in low-power mode,
> and optionally in high speed mode too.
>
>> And what I and Andrzej don't make sure is non-continuous clock mode. Do
>> you know how non-continuous clock mode is related to HS clock?
>
> As far as I can tell non-continuous mode simply means that the host can
> turn off the HS clock after a high-speed transmission. I think Andrzej
> mentioned this already in another subthread, but this is an optional
> mode that peripherals can support if they have extra circuitry that
> provides an internal clock. Peripherals that don't have such circuitry
> may rely on the HS clock to perform in between transmissions and
> therefore require the HS clock to be always on (continuous mode). That's
> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the
> peripheral supports non-continuous mode and therefore the host can turn
> the HS clock off after high-speed transmissions.

What I don't make sure is this sentence. With
MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
One is,
1. host controller will generates signals if a bit of a register
related to non-contiguous clock mode is set or unset.
2. And then video data is transmitted to panel in HS mode.
3. And then D-PHY detects LP-11 signal (positive and negative lane all
are high).
4. And then D-PHY disables HS clock of host controller.
5. At this time, operation mode of host controller becomes LPM.

Other is,
1. host controller will generates signals if a bit of a register
related to non-contiguous clock mode is set or unset.
2. And then D-PHY detects LP-11 signal (positive and negative lane all
are high).
3. And then video data is transmitted to panel in LPM.
4. At this time, operation mode of host controller becomes LPM.

It seems that you says latter case.

I really know that with non-contiguous clock mode, HS clock of host
controller can be disabled. My question is who controls HS clock in
this case. D-PHY or host controller?
In other words, with LPM and MIPI_DSI_CLOCK_NON_CONTIUOUS flags,
should the host driver check these two flags to disable HS clock? or
In this case, does the D-PHY disable HS clock regardless of host
driver?

I think we should make sure that to handle LP and HS modes correctly.

>
> If a device doesn't specify that flag then the host needs to keep the HS
> clock running all the time.
>
>> > The .transfer() function was really designed with initialization
>> > commands in mind, so it doesn't deal with mixing video data and commands
>> > anyway and for initialization low-power mode should be fast enough. The
>> > downside is that it may not be optimal for some peripherals, but it
>> > gives us a good solution for the general case since it should support
>> > all devices.
>> >
>> > If we absolutely must have faster initialization, or if we come across a
>> > device that can only initialize in high speed mode, then I think we
>> > should int

[PATCH 3/3] drm: Use vblank_disable_and_save in drm_vblank_cleanup()

2014-08-07 Thread Mario Kleiner

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, e.g.,
>>> on nouveau-kms. This can cause the gpu vblank irq's to not get
>>> disabled before freeing the dev->vblank array, so if a
>>> vblank irq fires and calls into drm_handle_vblank() after
>>> drm_vblank_cleanup() completes, it will cause use-after-free
>>> access to dev->vblank array.
>>>
>>> Call vblank_disable_and_save unconditionally, so vblank irqs
>>> are guaranteed to be off, before we delete the data structures
>>> on which they operate.
>>>
>>> Signed-off-by: Mario Kleiner 
>>> Cc: stable at vger.kernel.org
> Imo cc: stable isn't justified for these patches which fix stuff that
> normal users don't really see (driver load failure and module reload for
> kms drivers never tends to happen for normal users).
>
> So I've dropped that and pulled the 2 patches Ville reviewd into my
> topic/vblank-rework branch for 3.18.
>
> Thanks, Daniel

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 always make me nervous, given how dependent my 
main application is on this for its timing, so i want to move through it 
in slow motion.

Btw. wrt to nouveau "No idea what games nouveau is playign with that 
flag, but this patch should be fine at least for drivers that don't do 
such things." (Villes comment).

Nouveau currently doesn't support hw vblank counter queries at all. The 
dev->driver->get_vblank_count() is just hooked up to drm_vblank_count(), 
so it's a no-op. Therefore nouveau can't allow disabling of vblank irq 
during "normal" operation as it would lose all vblank counts during the 
off period. That's why it leaves dev->vblank_disable_allowed = false;

Pre NV-50 apparently doesn't have any hw vblank counter register, but 
NV50+ seems to have one. I'll probably give implementing this a try for 
3.18 if nobody else does.

I'm not sure about all the new embedded drivers, if they have hw vblank 
counters?

thanks,
-mario

>
>> No idea what games nouveau is playign with that flag, but this patch
>> should be fine at least for drivers that don't do such things.
>>
>> Reviewed-by: Ville Syrj?l? 
>>
>>> ---
>>>   drivers/gpu/drm/drm_irq.c | 5 -
>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>>> index 89e91e3..22e2bba9 100644
>>> --- a/drivers/gpu/drm/drm_irq.c
>>> +++ b/drivers/gpu/drm/drm_irq.c
>>> @@ -164,6 +164,7 @@ static void vblank_disable_fn(unsigned long arg)
>>>   void drm_vblank_cleanup(struct drm_device *dev)
>>>   {
>>> int crtc;
>>> +   unsigned long irqflags;
>>>   
>>> /* Bail if the driver didn't call drm_vblank_init() */
>>> if (dev->num_crtcs == 0)
>>> @@ -171,7 +172,9 @@ void drm_vblank_cleanup(struct drm_device *dev)
>>>   
>>> for (crtc = 0; crtc < dev->num_crtcs; crtc++) {
>>> del_timer_sync(&dev->vblank[crtc].disable_timer);
>>> -   vblank_disable_fn((unsigned long)&dev->vblank[crtc]);
>>> +   spin_lock_irqsave(&dev->vbl_lock, irqflags);
>>> +   vblank_disable_and_save(dev, crtc);
>>> +   spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
>>> }
>>>   
>>> kfree(dev->vblank);
>>> -- 
>>> 1.9.1
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> -- 
>> Ville Syrj?l?
>> Intel OTC
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 81644] Random crashes on RadeonSI with Chromium.

2014-08-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=81644

--- Comment #44 from Maciej  ---
Testing Oibaf repo with kernel 3.16 under Ubuntu Gnome 14.04 - no issues after
few hours using Chrome Beta (even tried with #ignore-gpu-blacklist flag). At
least on my machine (7770) this issue looks to be Ubuntu 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>

[Bug 81644] Random crashes on RadeonSI with Chromium.

2014-08-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=81644

--- Comment #45 from Aaron B  ---
I'm on Arch, from Mint, and have the issue on both. If you still don't have a
crash for a while, lets start comparing chrome/DE settings. I'm on an R9 270X,
which is a 7850 reclocked AFAIK.

-- 
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/62331b79/attachment.html>

[Bug 82279] New: SDL applications crash when changing video mode: double free or corruption

2014-08-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=82279

Priority: medium
Bug ID: 82279
Assignee: dri-devel at lists.freedesktop.org
Summary: SDL applications crash when changing video mode:
double free or corruption
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: xamaniqinqu at gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/radeonsi
Product: Mesa

Created attachment 104195
--> https://bugs.freedesktop.org/attachment.cgi?id=104195&action=edit
GDB backtrace of Dosbox crash.

Overview:
SDL applications crash when changing video mode, "corrupted double-linked
list" and "double free or corruption" are printed to stderr. The applications
tested are Dosbox and Enemy Territory: Quake Wars.

Steps to reproduce:
1) Install an abandonware game such as Commander Keen 4
2) Run it in Dosbox
3) Depending on the game, press a key to start the game proper

Actual results:
The application crashes upon changing video mode.

Expected results:
The application changes video mode without causing a crash.

Build date and platform:
Build date of all components: 2014-08-07
Platform: Gentoo GNU/Linux x86_64
Linux kernel version: 3.16

Additional information:
Bisecting revealed the culprit commit to be
"58d2afa2232060b88f9c444ce7a0d6e63c841bb2: radeonsi: fix leaking the bound
state on destruction v2". See attachments for backtraces.

--
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/58e6e2e8/attachment.html>

91 matches

Mail list logo