Hello again, hope you are still reading my texts...
I digged through the code and narrowed down the issue I wanted to fix.
It appears to be related to the `bool thermal_active` dpm struct
member and this piece of code:
if (rdev->asic->dpm.force_performance_level) {
if
On Monday 11 August 2014, 01:19:32, ?? ?? wrote:
> Hello again, hope you are still reading my texts...
>
> I digged through the code and narrowed down the issue I wanted to fix.
> It appears to be related to the `bool thermal_active` dpm struct
> member and this piece of code:
>
> if
ons with R600_DEBUG=help).
Anyway, this is probably related to comment #3.
--
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/20140811/44
https://bugzilla.kernel.org/show_bug.cgi?id=67681
--- Comment #31 from KernelBug <3fdd1e5d at opayq.com> ---
I wonder if any of the developers are aware that there is not one distro this
works on? Meaning there isn't the support for it in Linux, which I was hoping
was going to come from the
2014-08-11 1:53 GMT+04:00 Niels Ole Salscheider
:
> On Monday 11 August 2014, 01:19:32, ?? ?? wrote:
>> Hello again, hope you are still reading my texts...
>>
>> I digged through the code and narrowed down the issue I wanted to fix.
>> It appears to be related to the `bool thermal_active`
On 2014? 08? 08? 18:55, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote:
>> On 2014? 08? 08? 16:03, Thierry Reding wrote:
>>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
On 2014? 08? 07? 22:55, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140811/33a5466f/attachment.html>
/archives/dri-devel/attachments/20140811/06812fda/attachment-0001.html>
On Monday 11 August 2014, 08:03:57, ?? ?? wrote:
> 2014-08-11 1:53 GMT+04:00 Niels Ole Salscheider
>
> :
> > On Monday 11 August 2014, 01:19:32, ?? ?? wrote:
> >> Hello again, hope you are still reading my texts...
> >>
> >> I digged through the code and narrowed down the issue I
On 2014? 08? 08? 18:40, Andrzej Hajda wrote:
> On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
>> On 08/08/2014 09:37 AM, Inki Dae wrote:
>>> On 2014? 08? 08? 16:03, Thierry Reding wrote:
On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
> On 2014? 08? 07? 22:55, Thierry Reding
E_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
> >>>>
> >>>> That would may why we are mentioning same comments repeatedly.
> >>>>
> >>>> In my case, host driver waits for the lane stop state (LP-11), and then
> >>>> disables HS clock to transmit command data in LPM. Of course, I'm not
> >>>> sure that yet it's correct way.
> >>>
> >>> That's confusing. How can the lane go to LP-11 when the clock is still
> >>> running?
> >>
> >> Actually, we are doing so. If the clock is still running then dsi driver
> >> will wait for stop state of the clock and data lanes. Know that this is
> >> valid only when initial time - just one time since power up.
> >>
> >>/* Check clock and data lane state are stop state */
> >>timeout = 100;
> >>do {
> >>if (timeout-- == 0) {
> >>dev_err(dsi->dev, "waiting for bus lanes timed out\n");
> >>return -EFAULT;
> >>}
> >>
> >>reg = readl(dsi->reg_base + DSIM_STATUS_REG);
> >>if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
> >>!= DSIM_STOP_STATE_DAT(lanes_mask))
> >>continue;
> >>} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
> >>
> >>>
> >>>> In Tegra, What to do for it?
> >>>
> >>> There are two bits in two separate registers for this:
> >>>
> >>> DSI_HOST_CONTROL:
> >>> bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
> >>> packets
> >>> - 0 = LOW: low speed
> >>> - 1 = HIGH: high speed
> >>>
> >>> DSI_CONTROL:
> >>> bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
> >>> - 0 = CONTINUOUS: HS clock is on all the time
> >>> - 1 = TX_ONLY: HS clock is only active during HS
> >>> transmissions
> >>>
> >>> So if the peripheral supports non-continuous mode of operation we set
> >>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
> >>> remains on all the time.
> >>>
> >>> When a packet is to be transmitted in high speed mode, we set the
> >>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
> >>> cleared.
> >>
> >> That is exactly what I want. In your case, if you want to transmit
> >> command data in Low Power Mode in case of supporting non-continuous
> >> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
> >> would clear DSI_HIGH_SPEED_TRANS (LOW).
> >>
> >> So I guess,
> >>
> >> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
> >> disable DSI_HIGH_SPEED_TRANS; <- LOW
> >> enable DSI_HS_CLK_CTRL; <- TX_ONLY
> >> }
> >>
> >> transmit command data <- in LPM.
> >>
> >> However, what if the peripheral doesn't support non-continuous but want
> >> to transmit command data in LPM? Is that impossible?
> >
> > The above is actually more like this:
> >
> > if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
> > clear DSI_HS_CLK_CTRL;
> > else
> > set DSI_HS_CLK_CTRL;
> >
> > if (msg->flags & MIPI_DSI_MSG_USE_LPM)
> > clear DSI_HIGH_SPEED_TRANS;
> > else
> > set DSI_HIGH_SPEED_TRANS;
> >
> > So for peripherals that don't support non-continuous clock mode, this
> > will result in the following for low-power transmissions:
> >
> > clear DSI_HS_CLK_CTRL; /* HS clock always on */
> > clear DSI_HIGH_SPEED_TRANS;
>
> Right, then how host driver should check it if peripheral doesn't
> support non-continuous clock mode? Or how the peripheral should notify
> it to host driver? It would need a new flag instead of
> MIPI_DSI_MODE_NON_CONTINUOUS.
MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to
set to signal that they support non-continuous mode. If devices don't
have that set, then the controller should always provide the HS clock.
So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral
does *not* support non-continuous mode.
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/20140811/36706a79/attachment-0001.sig>
On 2014? 08? 11? 16:24, Thierry Reding wrote:
> On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
>> On 2014? 08? 08? 18:55, Thierry Reding wrote:
>>> On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote:
On 2014? 08? 08? 16:03, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at
gp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/a5028c73/attachment.sig>
re enthusiast |Mesa and X developer
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 234 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/d4d0b01d/attachment.sig>
On 08/11/2014 09:09 AM, Inki Dae wrote:
> On 2014? 08? 08? 18:40, Andrzej Hajda wrote:
>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
>>> On 08/08/2014 09:37 AM, Inki Dae wrote:
On 2014? 08? 08? 16:03, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/b6e321f2/attachment.html>
de.
With the above two flags we can cover four cases:
1) non-continuous mode with messages transmitted in low-power mode
2) non-continuous mode with messages transmitted in high-speed mode
3) continuous mode with messages transmitted in low-power mode
4) continuous mode with messages transmitted in high-speed mode
What other cases do you think we need to support?
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/20140811/45e0812a/attachment.sig>
On 2014? 08? 11? 16:44, Andrzej Hajda wrote:
> On 08/11/2014 09:09 AM, Inki Dae wrote:
>> On 2014? 08? 08? 18:40, Andrzej Hajda wrote:
>>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
On 08/08/2014 09:37 AM, Inki Dae wrote:
> On 2014? 08? 08? 16:03, Thierry Reding wrote:
>> On Fri,
On 08/11/2014 09:44 AM, Andrzej Hajda wrote:
> On 08/11/2014 09:09 AM, Inki Dae wrote:
>> On 2014? 08? 08? 18:40, Andrzej Hajda wrote:
>>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
On 08/08/2014 09:37 AM, Inki Dae wrote:
> On 2014? 08? 08? 16:03, Thierry Reding wrote:
>> On Fri,
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/03f2e3af/attachment.html>
On 2014? 08? 11? 16:50, Thierry Reding wrote:
> On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote:
>> On 2014? 08? 11? 16:24, Thierry Reding wrote:
>>> On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
On 2014? 08? 08? 18:55, Thierry Reding wrote:
> [...]
> The above is
Christian K?nig ---
Going to take a look as soon as I have time.
--
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/20140811/8b4da
ment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/d71a3994/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/f19c8aba/attachment.html>
On 08.08.2014 22:34, Alex Deucher wrote:
> On Fri, Aug 8, 2014 at 9:31 AM, Alex Deucher wrote:
>> On Fri, Aug 8, 2014 at 4:50 AM, Michel D?nzer wrote:
>>> On 08.08.2014 17:44, Christian K?nig wrote:
>>> On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher
>>> wrote:
We should be using
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/99950195/attachment-0001.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/5f661ce7/attachment.html>
Am 07.08.2014 um 21:43 schrieb Alex Deucher:
> 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
_CTRL on Tegra because
> > that tells the controller to turn off the HS clock between high-speed
> > transmissions.
> >
> > MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power
> > mode.
> >
> > With the above two flags we can cover four cases:
> >
> > 1) non-continuous mode with messages transmitted in low-power mode
> > 2) non-continuous mode with messages transmitted in high-speed mode
> > 3) continuous mode with messages transmitted in low-power mode
>
> In case of 3), it would mean "set DSI_HS_CLK_CTRL" and "clear
> DSI_HIGH_SPEED_TRANS". However, msg->flags has MIPI_DSI_MSG_USE_LPM but
> dsi->mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right.
> You mean that continuous mode is set by default implicitly?
Yes, if the MIPI_DSI_MODE_NON_CONTINUOUS flag is not specified, then it
means the peripheral supports only continuous mode.
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/20140811/6a21266b/attachment.sig>
000, tmp->eoffset:
0x, size:0x0010
[ 988.176054] radeon :01:00.0: soffset:0x0010, eoffset: 0x0020
[ 988.176078] radeon :01:00.0: tmp->soffset:0x, tmp->eoffset:
0x, size:0x0010
--
You are receiving this mail because:
You are the assignee
qq.com
--
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/20140811/78305d44/attachment.html>
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/58b47302/attachment.html>
On 08/10/2014 08:02 PM, Mario Kleiner wrote:
> On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:
>> On 08/10/2014 05:11 AM, Mario Kleiner wrote:
>>> Resent this time without HTML formatting which lkml doesn't like.
>>> Sorry.
>>>
>>> On 08/09/2014 03:58 PM, Thomas Hellstrom wrote:
On 08/09/2014
Hi,
there is some hardware than can do 2D compositing with an arbitrary
number of planes. I'm not sure what the absolute maximum number of
planes is, but for the discussion, let's say it is 100.
There are many complicated, dynamic constraints on how many, what size,
etc. planes can be used at
On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> Hi,
Hi,
> there is some hardware than can do 2D compositing with an arbitrary
> number of planes. I'm not sure what the absolute maximum number of
> planes is, but for the discussion, let's say it is 100.
>
> There are many
TML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/b832deff/attachment-0001.html>
On Sun, 10 Aug 2014, Guenter Roeck wrote:
> spin_is_locked() always returns false in uniprocessor configurations
> and can therefore not be used with BUG_ON. Replace it with
> assert_spin_locked(), which exists for that very purpose.
>
It may be helpful to assess whether any of these sites
rubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/fa58d451/attachment.html>
/archives/dri-devel/attachments/20140811/47864ddf/attachment.html>
On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> Hi,
>
> there is some hardware than can do 2D compositing with an arbitrary
> number of planes. I'm not sure what the absolute maximum number of
> planes is, but for the discussion, let's say it is 100.
>
> There are many
On Mon, 11 Aug 2014 11:57:10 +0100
Damien Lespiau wrote:
> On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> > Hi,
>
> Hi,
>
> > there is some hardware than can do 2D compositing with an arbitrary
> > number of planes. I'm not sure what the absolute maximum number of
> > planes
Hi Daniel,
you make perfect sense as usual. :-)
Comments below.
On Mon, 11 Aug 2014 14:06:36 +0200
Daniel Vetter wrote:
> On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> > Hi,
> >
> > there is some hardware than can do 2D compositing with an arbitrary
> > number of planes.
On Mon, Aug 11, 2014 at 03:07:33PM +0300, Pekka Paalanen wrote:
> > > there is some hardware than can do 2D compositing with an arbitrary
> > > number of planes. I'm not sure what the absolute maximum number of
> > > planes is, but for the discussion, let's say it is 100.
> > >
> > > There are
On Mon, Aug 11, 2014 at 8:06 AM, Daniel Vetter wrote:
> On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
>> Hi,
>>
>> there is some hardware than can do 2D compositing with an arbitrary
>> number of planes. I'm not sure what the absolute maximum number of
>> planes is, but for the
On Mon, 11 Aug 2014 14:14:56 +0100
Damien Lespiau wrote:
> On Mon, Aug 11, 2014 at 03:07:33PM +0300, Pekka Paalanen wrote:
> > > > there is some hardware than can do 2D compositing with an arbitrary
> > > > number of planes. I'm not sure what the absolute maximum number of
> > > > planes is, but
On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> Hi,
>
> there is some hardware than can do 2D compositing with an arbitrary
> number of planes. I'm not sure what the absolute maximum number of
> planes is, but for the discussion, let's say it is 100.
>
> There are many
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/f0c598e8/attachment-0001.html>
On Mon, Aug 11, 2014 at 12:03 AM, ?? ?? wrote:
> 2014-08-11 1:53 GMT+04:00 Niels Ole Salscheider
> :
>> On Monday 11 August 2014, 01:19:32, ?? ?? wrote:
>>> Hello again, hope you are still reading my texts...
>>>
>>> I digged through the code and narrowed down the issue I wanted
On Mon, Aug 11, 2014 at 5:08 AM, Christian K?nig
wrote:
> Am 07.08.2014 um 21:43 schrieb Alex Deucher:
>
>> 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:
On Mon, Aug 11, 2014 at 4:42 AM, Michel D?nzer wrote:
> On 08.08.2014 22:34, Alex Deucher wrote:
>> On Fri, Aug 8, 2014 at 9:31 AM, Alex Deucher
>> wrote:
>>> On Fri, Aug 8, 2014 at 4:50 AM, Michel D?nzer wrote:
On 08.08.2014 17:44, Christian K?nig wrote:
On Thu, Aug 7, 2014 at
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140811/8dfdf30e/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/2318a8fe/attachment-0001.html>
On Mon, Aug 11, 2014 at 12:11:21PM +0200, Thomas Hellstrom wrote:
> On 08/10/2014 08:02 PM, Mario Kleiner wrote:
> > On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:
> >> On 08/10/2014 05:11 AM, Mario Kleiner wrote:
> >>> Resent this time without HTML formatting which lkml doesn't like.
> >>>
On Mon, Aug 11, 2014 at 09:32:32AM -0400, Rob Clark wrote:
> On Mon, Aug 11, 2014 at 8:06 AM, Daniel Vetter wrote:
> > Personally I'd expose a bunch of planes with kms (enough so that you can
> > reap the usual benefits planes bring wrt video-playback and stuff like
> > that). So perhaps
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/22e25830/attachment.html>
sa-dri-dbg and firefox-dbg is definitely installed.
Any suggestions ?
--
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/2014
On Mon, Aug 11, 2014 at 03:47:22PM +0300, Pekka Paalanen wrote:
> > > What if I cannot even pick a maximum number of planes, but wanted to
> > > (as the hardware allows) let the 2D compositing scale up basically
> > > unlimited while becoming just slower and slower?
> > >
> > > I think at that
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/20140811/5c19ff4c/attachment.html>
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/d0780b49/attachment.html>
? Are you sure your HDMI
cable is good?
--
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/20140811/b8215e3c/attachment.html>
nts/20140811/3f37df71/attachment.html>
On Mon, Aug 11, 2014 at 05:35:31PM +0200, Daniel Vetter wrote:
> On Mon, Aug 11, 2014 at 03:47:22PM +0300, Pekka Paalanen wrote:
> > > > What if I cannot even pick a maximum number of planes, but wanted to
> > > > (as the hardware allows) let the 2D compositing scale up basically
> > > > unlimited
https://bugzilla.kernel.org/show_bug.cgi?id=76321
--- Comment #9 from Alex Deucher ---
(In reply to Pali Roh?r from comment #8)
> Created attachment 146011 [details]
> patch for get/set dpm state
>
>
> It is implemented in attached patch. I tested it and it working fine on my
> system. My
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/115d06e4/attachment.html>
the patch from attachment 104443 applied though,
everything is back to normal again.
--
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/20140811/6e5ebe58/attachment.html>
On Fri, Aug 08, 2014 at 04:23:40PM +0530, sonika.jindal at intel.com wrote:
> From: Sonika Jindal
>
> Adding new defines, older one will be removed in the last patch in the series.
> This is to rename the defines to have levels instead of values for vswing and
> pre-emph levels as the values may
On Fri, Aug 08, 2014 at 04:23:41PM +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
> eDP1.4 where the values are different.
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=76321
Pali Roh?r changed:
What|Removed |Added
Attachment #146011|0 |1
is obsolete|
lending in
overlays, or downscaled video, it's probably not a problem, and
something that gets your pixels on the screen at all is sufficient)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/9e912647/attachment.sig>
On Mon, Aug 11, 2014 at 07:09:11PM +0300, Ville Syrj?l? wrote:
> On Mon, Aug 11, 2014 at 05:35:31PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 11, 2014 at 03:47:22PM +0300, Pekka Paalanen wrote:
> > > > > What if I cannot even pick a maximum number of planes, but wanted to
> > > > > (as the
which could do some fpu calculations)) which I think is not
reasonable.
--
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/20140
On Mon, Aug 11, 2014 at 10:16:24AM -0700, Eric Anholt wrote:
> Daniel Vetter writes:
>
> > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> >> Hi,
> >>
> >> there is some hardware than can do 2D compositing with an arbitrary
> >> number of planes. I'm not sure what the absolute
Signed-off-by: Oleg Chernovskiy
---
drivers/gpu/drm/radeon/ci_dpm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 022561e..d416bb2 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
re 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/20140811/b5713c3d/attachment.html>
onsi system is because I think the llvm
dependency is just painful to work with.)
--
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/at
t --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/e2159901/attachment.html>
On Mon, Aug 11, 2014 at 1:53 PM, Oleg Chernovskiy
wrote:
> Signed-off-by: Oleg Chernovskiy
Applied to my fixes tree. Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/ci_dpm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/a1132b97/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=76321
--- Comment #11 from Alex Deucher ---
Applied to my tree. thanks.
--
You are receiving this mail because:
You are watching the assignee of the bug.
? Does booting with
radeon.audio=0 on the kernel command line in grub help?
--
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/20140
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/24f2f500/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/66fba82a/attachment.html>
On Mon, 11 Aug 2014, sanjeev sharma wrote:
> Hello David,
>
> Here is the old discussion carried out on this.
>
> http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802
>
I'm suggesting that if you don't want to incur the cost of the
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/20140811/9d42f34b/attachment-0001.html>
On Mon, Aug 11, 2014 at 4:53 PM, David Rientjes wrote:
> On Mon, 11 Aug 2014, sanjeev sharma wrote:
>
>> Hello David,
>>
>> Here is the old discussion carried out on this.
>>
>> http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802
>>
>
>
On Mon, 11 Aug 2014, Rob Clark wrote:
> > I'm suggesting that if you don't want to incur the cost of the conditional
> > everytime you call a certain function with assert_spin_locked() that you
> > could covert these to lockdep_assert_held() so the check is only done when
> > lockdep is enabled
Hello everyone.
I'm currently working on a DRM/KMS driver for the Silicon Motion SM712
graphics card. Avoid the flicking between the VT-switching on my
computer is what I want.
This antiquated card doesn't support 3D and OpenGL stuff, but provide
simple 2D acceleration by a drawing processor.
_list, node)
> irqmask |= irq->irqmask;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/78aaef92/attachment.html>
domo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/aaa44903/attachment-0001.html>
info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/87a70c32/attachment-0001.html>
On 08/11/2014 04:45 AM, David Rientjes wrote:
> On Sun, 10 Aug 2014, Guenter Roeck wrote:
>
>> spin_is_locked() always returns false in uniprocessor configurations
>> and can therefore not be used with BUG_ON. Replace it with
>> assert_spin_locked(), which exists for that very purpose.
>>
>
> It
On Mon, Aug 11, 2014 at 9:42 AM, Tom Li wrote:
> Hello everyone.
>
> I'm currently working on a DRM/KMS driver for the Silicon Motion SM712
> graphics card. Avoid the flicking between the VT-switching on my
> computer is what I want.
> This antiquated card doesn't support 3D and OpenGL stuff, but
intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/8cbce307/attachment.sig>
93 matches
Mail list logo
