Interrupt commands causes the CP to trigger an interrupt as the command
is processed, regardless of the GPU being done processing previous
commands. This is seen by the interrupt being delivered before the
fence is written on 8974 and is likely the cause of the additional
CP_WAIT_FOR_IDLE workaroun
On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam
wrote:
> Hi Tomasz,
>
> On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa wrote:
>> On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark wrote:
>>> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote:
On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote:
> O
Hi Tomasz,
On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa wrote:
> On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark wrote:
>> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote:
>>> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote:
On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote:
> Hi Vi
On Tue, Feb 13, 2018 at 7:25 PM, Vivek Gautam
wrote:
>>> +static int arm_smmu_init_clks(struct arm_smmu_device *smmu)
>>> +{
>>> + int i;
>>> + int num = smmu->num_clks;
>>> + const struct arm_smmu_match_data *data;
>>> +
>>> + if (num < 1)
>>> + return 0;
>>>
Hi Jordan,
On Wed, Feb 14, 2018 at 1:42 AM, Jordan Crouse wrote:
> On Tue, Feb 13, 2018 at 06:10:38PM +0900, Tomasz Figa wrote:
>> Hi Vivek,
>>
>> Thanks for the patch. Please see my comments inline.
>>
>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>> wrote:
>> > While handling the concerned i
On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark wrote:
> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote:
>> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote:
>>> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote:
Hi Vivek,
Thanks for the patch. Please see my comments inline.
>>>
On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote:
> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote:
>> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote:
>>> Hi Vivek,
>>>
>>> Thanks for the patch. Please see my comments inline.
>>>
>>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>>> wrot
On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote:
> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote:
>> Hi Vivek,
>>
>> Thanks for the patch. Please see my comments inline.
>>
>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>> wrote:
>>> While handling the concerned iommu, there should not be
On Tue, Feb 13, 2018 at 7:02 PM, Jordan Crouse wrote:
> On Tue, Feb 13, 2018 at 02:18:13PM -0500, Sean Paul wrote:
>> Hi dri-devel,
>> Qualcomm has been working for the past few weeks on forward porting their
>> downstream drm driver from 4.14 to mainline. Please consider this PR as a
>> request f
On Tue, Feb 13, 2018 at 02:18:13PM -0500, Sean Paul wrote:
> Hi dri-devel,
> Qualcomm has been working for the past few weeks on forward porting their
> downstream drm driver from 4.14 to mainline. Please consider this PR as a
> request for review, rather than an attempt at mainlining the code as i
On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul wrote:
> Hi dri-devel,
> Qualcomm has been working for the past few weeks on forward porting their
> downstream drm driver from 4.14 to mainline. Please consider this PR as a
> request for review, rather than an attempt at mainlining the code as it
> curr
Hi dri-devel,
Qualcomm has been working for the past few weeks on forward porting their
downstream drm driver from 4.14 to mainline. Please consider this PR as a
request for review, rather than an attempt at mainlining the code as it
currently stands. The goal is get this driver in shape over the n
On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see my comments inline.
>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
> wrote:
>> While handling the concerned iommu, there should not be a
>> need to power control the drm devices from iommu inter
On Tue, Feb 13, 2018 at 06:10:38PM +0900, Tomasz Figa wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see my comments inline.
>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
> wrote:
> > While handling the concerned iommu, there should not be a
> > need to power control the drm devices from
On Tue, Feb 13, 2018 at 9:57 PM, Robin Murphy wrote:
> On 13/02/18 08:24, Tomasz Figa wrote:
>>
>> Hi Vivek,
>>
>> Thanks for the patch. Please see my comments inline.
>>
>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>> wrote:
>>>
>>> From: Sricharan R
>>>
>>> The smmu device probe/remove and
On 13/02/18 12:54, Tomasz Figa wrote:
On Tue, Feb 13, 2018 at 9:00 PM, Robin Murphy wrote:
On 13/02/18 07:44, Tomasz Figa wrote:
Hi Vivek,
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
The device link allows the pm framework to tie the supplier and
consumer. So, whenever the consume
On Tue, Feb 13, 2018 at 9:00 PM, Robin Murphy wrote:
> On 13/02/18 07:44, Tomasz Figa wrote:
>>
>> Hi Vivek,
>>
>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>> wrote:
>>>
>>> The device link allows the pm framework to tie the supplier and
>>> consumer. So, whenever the consumer is powered-on t
On 13/02/18 08:24, Tomasz Figa wrote:
Hi Vivek,
Thanks for the patch. Please see my comments inline.
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its maste
On 13/02/18 07:44, Tomasz Figa wrote:
Hi Vivek,
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
The device link allows the pm framework to tie the supplier and
consumer. So, whenever the consumer is powered-on the supplier
is powered-on first.
There are however cases in which the consumer
Hi Vivek,
Thanks for the patch. Please see my comments inline.
On Fri, Feb 9, 2018 at 7:57 PM, Vivek Gautam
wrote:
> qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
> clock and power requirements. This smmu core is used with
> multiple masters on msm8996, viz. mdss, video, etc.
> Add
Hi Vivek,
Thanks for the patch. Please see my comments inline.
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
> While handling the concerned iommu, there should not be a
> need to power control the drm devices from iommu interface.
> If these drm devices need to be powered around this time,
Hi Vivek,
Thanks for the patch. Please see my comments inline.
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
> From: Sricharan R
>
> The smmu device probe/remove and add/remove master device callbacks
> gets called when the smmu is not linked to its master, that is without
> the context o
Hi Vivek,
Thanks for the patch. Please see some comments inline.
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
> From: Sricharan R
>
> The smmu needs to be functional only when the respective
> master's using it are active. The device_link feature
> helps to track such functional dependen
Hi Vivek,
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
> The device link allows the pm framework to tie the supplier and
> consumer. So, whenever the consumer is powered-on the supplier
> is powered-on first.
>
> There are however cases in which the consumer wants to power-on
> the supplie
Hi Vivek,
Thanks for the patch. Please see my comments inline.
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
> From: Sricharan R
>
> Finally add the device link between the master device and
> smmu, so that the smmu gets runtime enabled/disabled only when the
> master needs it. This is do
Hi Tomasz,
Please find my response inline below.
On Tue, Feb 13, 2018 at 1:33 PM, Tomasz Figa wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see some comments inline.
>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
> wrote:
>> From: Sricharan R
>>
>> The smmu needs to be functional only
Hi Tomasz,
On Tue, Feb 13, 2018 at 2:01 PM, Tomasz Figa wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see my comments inline.
Thanks for reviewing the patch series.
>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
> wrote:
>> From: Sricharan R
>>
>> Finally add the device link between
27 matches
Mail list logo
