On Mon, Jun 3, 2019 at 7:48 PM Rob Clark wrote:
>
> On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
> >
> > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
> > >
> > > On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
> > > >
> >
On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
>
> On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
> >
> > On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote:
> > >
> > > On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote:
> > > >
> > > > This solves a problem we see with drm/msm, caused by gettin
nce we don't currently have a better
> +* solution, and this code runs before the driver is probed and
> +* has a chance to intervene, use a simple blacklist to avoid
> +* ending up with iommu dma_ops:
> +*/
> + if (of_match_device(iommu_blacklist, de
On Sat, Dec 1, 2018 at 3:47 AM Rob Clark wrote:
>
> On Fri, Nov 30, 2018 at 9:05 PM Tomasz Figa wrote:
> >
> > On Thu, Nov 29, 2018 at 4:23 PM Tomasz Figa wrote:
> > >
> > > On Thu, Nov 29, 2018 at 12:03 PM Robin Murphy
> > > wrote:
> >
On Thu, Nov 29, 2018 at 4:23 PM Tomasz Figa wrote:
>
> On Thu, Nov 29, 2018 at 12:03 PM Robin Murphy wrote:
> >
> > On 29/11/2018 19:57, Tomasz Figa wrote:
> > > On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse
> > > wrote:
> > >>
> > >&g
On Thu, Nov 29, 2018 at 12:03 PM Robin Murphy wrote:
>
> On 29/11/2018 19:57, Tomasz Figa wrote:
> > On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse
> > wrote:
> >>
> >> On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote:
> >>> On Thu, N
On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse wrote:
>
> On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote:
> > On Thu, Nov 29, 2018 at 10:54 AM Christoph Hellwig wrote:
> > >
> > > On Thu, Nov 29, 2018 at 09:42:50AM -0500, Rob Clark wrote:
> > > > Maybe the thing we need to do is just i
[CC Marek]
On Thu, Nov 29, 2018 at 9:09 AM Daniel Vetter wrote:
>
> On Thu, Nov 29, 2018 at 5:57 PM Christoph Hellwig wrote:
> > On Thu, Nov 29, 2018 at 05:28:07PM +0100, Daniel Vetter wrote:
> > > Just spend a bit of time reading through the implementations already
> > > merged. Is the struct d
ap_sg() calls with dma_sync_sg_for_device{|cpu}()
> to do the cache maintenance.
>
> Signed-off-by: Vivek Gautam
> Suggested-by: Tomasz Figa
> Cc: Rob Clark
> Cc: Jordan Crouse
> Cc: Sean Paul
> ---
>
> Changes since v1:
> - Addressed Jordan's and Tomasz's c
On Sat, Nov 24, 2018 at 3:34 AM Will Deacon wrote:
>
> On Fri, Nov 23, 2018 at 03:06:29PM +0530, Vivek Gautam wrote:
> > On Fri, Nov 23, 2018 at 2:52 PM Tomasz Figa wrote:
> > > On Fri, Nov 23, 2018 at 6:13 PM Vivek Gautam
> > > wrote:
> > > > On
s an arm,smmu-v2 implementation with specific
> > > clock and power requirements.
> > > On msm8996, multiple cores, viz. mdss, video, etc. use this
> > > smmu. On sdm845, this smmu is used with gpu.
> > > Add bindings for the same.
> > >
> > > Signed-of
non-dma type. Using dma mapping APIs with that domain is bad.
> >
> > Replace dma_map_sg() calls with dma_sync_sg_for_device{|cpu}()
> > to do the cache maintenance.
> >
> > Signed-off-by: Vivek Gautam
> > Suggested-by: Tomasz Figa
> > ---
> >
>
On Fri, Sep 7, 2018 at 6:38 PM Vivek Gautam wrote:
>
> Hi Tomasz,
>
>
> On 9/7/2018 2:46 PM, Tomasz Figa wrote:
> > Hi Vivek,
> >
> > On Thu, Aug 30, 2018 at 11:46 PM Vivek Gautam
> > wrote:
> >> From: Sricharan R
> >>
> >> T
eanup pm runtime calls]
> Signed-off-by: Vivek Gautam
> Reviewed-by: Tomasz Figa
> Tested-by: Srinivas Kandagatla
> ---
> drivers/iommu/arm-smmu.c | 89
> +++-
> 1 file changed, 81 insertions(+), 8 deletions(-)
[snip]
> @
to its master, that is without
> > the context of the master device. So calling runtime apis in those places
> > separately.
> >
> > Signed-off-by: Sricharan R
> > [vivek: Cleanup pm runtime calls]
> > Signed-off-by: Vivek Gautam
> > Reviewed-by: T
Hi Robin,
On Fri, Jul 27, 2018 at 4:02 PM Vivek Gautam
wrote:
>
> This series provides the support for turning on the arm-smmu's
> clocks/power domains using runtime pm. This is done using
> device links between smmu and client devices. The device link
> framework keeps the two devices in correct
off in a system sleep.
> > Also add corresponding clock enable path in resume callback.
> >
> > Signed-off-by: Sricharan R
> > Signed-off-by: Archit Taneja
> > [vivek: rework for clock and pm ops]
> > Signed-off-by: Vivek Gautam
> > Reviewed-by: Toma
e/sleep callbacks to the
> >>> driver and also the functions to parse the smmu clocks
> >>> from DT and enable them in resume/suspend.
> >>>
> >>> Signed-off-by: Sricharan R
> >>> Signed-off-by: Archit Taneja
> >>> [vivek: Clock rework to
ed when the smmu is not linked to its master, that is without
> > the context of the master device. So calling runtime apis in those places
> > separately.
> >
> > Signed-off-by: Sricharan R
> > [vivek: Cleanup pm runtime calls]
> > Signed-off-by: Vivek Gautam
On Thu, Feb 22, 2018 at 10:45 PM, Robin Murphy wrote:
> [sorry, I had intended to reply sooner but clearly forgot]
>
>
> On 16/02/18 00:13, Tomasz Figa wrote:
>>
>> On Fri, Feb 16, 2018 at 2:14 AM, Robin Murphy
>> wrote:
>>>
&
On Fri, Feb 16, 2018 at 9:13 AM, Tomasz Figa wrote:
> On Fri, Feb 16, 2018 at 2:14 AM, Robin Murphy wrote:
>> On 15/02/18 04:17, Tomasz Figa wrote:
>> [...]
>>>>
>>>> Could you elaborate on what kind of locking you are concerned about?
>>>> As I
On Fri, Feb 16, 2018 at 2:14 AM, Robin Murphy wrote:
> On 15/02/18 04:17, Tomasz Figa wrote:
> [...]
>>>
>>> Could you elaborate on what kind of locking you are concerned about?
>>> As I explained before, the normally happening fast path would lock
>>> de
On Thu, Feb 15, 2018 at 12:17 PM, Tomasz Figa wrote:
> On Thu, Feb 15, 2018 at 1:03 AM, Robin Murphy wrote:
>> On 14/02/18 10:33, Vivek Gautam wrote:
>>>
>>> On Wed, Feb 14, 2018 at 2:46 PM, Tomasz Figa wrote:
>>>
>>> Adding Jordan to this thread a
On Thu, Feb 15, 2018 at 1:12 AM, Rob Clark wrote:
> On Wed, Feb 14, 2018 at 10:48 AM, Jordan Crouse
> wrote:
>> On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote:
>>>
>>> - When submitting commands to the GPU, the GPU driver will
>>> pm_runtime_g
On Thu, Feb 15, 2018 at 1:03 AM, Robin Murphy wrote:
> On 14/02/18 10:33, Vivek Gautam wrote:
>>
>> On Wed, Feb 14, 2018 at 2:46 PM, Tomasz Figa wrote:
>>
>> Adding Jordan to this thread as well.
>>
>>> On Wed, Feb 14, 2018 at 6:13 PM, Vivek Gautam
>
On Wed, Feb 14, 2018 at 6:13 PM, Vivek Gautam
wrote:
> Hi Tomasz,
>
> On Wed, Feb 14, 2018 at 11:08 AM, Tomasz Figa wrote:
>> On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam
>> wrote:
>>> Hi Tomasz,
>>>
>>> On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Fi
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 1
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
>> w
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,
>>>>
>>>&g
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:
>>> Whil
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:
>>>
>>&
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
&g
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
39 matches
Mail list logo
