On Fri, Aug 12, 2016 at 12:17 PM, Sricharan wrote:
> Hi,
>
>>When things go wrong on the gpu, we can get *thousands* of faults. With
>>so many pr_err() prints, which were slowing down resuming the iommu,
>>drm/msm would think the GPU had actually hung and reset it.
>>
>>Wire up the fault reportin
Hi,
>When things go wrong on the gpu, we can get *thousands* of faults. With
>so many pr_err() prints, which were slowing down resuming the iommu,
>drm/msm would think the GPU had actually hung and reset it.
>
>Wire up the fault reporting, so instead we get a small ratelimited print
>of the fault
Hi,
>We need to disable stall on memory access after a fault, otherwise the
>device using the iommu will be perma-wedged with no access to memory.
>This was causing drm/msm to be unable to recover the gpu after an iommu
>fault.
>
>Signed-off-by: Rob Clark
>---
> drivers/iommu/msm_iommu.c | 1 +
>
Hi,
>> > The of_configure_dma() function configures both the DMA masks and ops.
>> > Moving DMA ops configuration to probe time would thus also delay
>> > configuration of the DMA masks, which might not be safe. To avoid issues
>>
>> Do we know any example cases when it might be unsafe? I think we
Hi Tomaz,
>> The dma_ops gets configured for the device generically during
>> the device_attach call. So remove it from the platform bus probe.
>> Similarly remove the deconfigure calls as well, since it is
>> now called form the device_detach path.
>
>Doesn't this patch need to be squashed with p
Hi Tomaz,
>> + if (ops->add_device)
>> + ops = ops->add_device(dev) ? ops : NULL;
>
>Patch description fails to mention anything about this change. Also it
>looks slightly incorrect to lose the error condition here. I think we
>should at least print some error m
When things go wrong on the gpu, we can get *thousands* of faults. With
so many pr_err() prints, which were slowing down resuming the iommu,
drm/msm would think the GPU had actually hung and reset it.
Wire up the fault reporting, so instead we get a small ratelimited print
of the fault address fr
We need to disable stall on memory access after a fault, otherwise the
device using the iommu will be perma-wedged with no access to memory.
This was causing drm/msm to be unable to recover the gpu after an iommu
fault.
Signed-off-by: Rob Clark
---
drivers/iommu/msm_iommu.c | 1 +
1 file changed
Hi Tomasz,
On Friday 12 Aug 2016 16:31:47 Tomasz Figa wrote:
> On Tue, Aug 9, 2016 at 7:49 AM, Sricharan R wrote:
> > From: Laurent Pinchart
> >
> > The of_configure_dma() function configures both the DMA masks and ops.
> > Moving DMA ops configuration to probe time would thus also delay
> > con
On Fri, Aug 12, 2016 at 10:40 AM, Rob Clark wrote:
> On Fri, Aug 12, 2016 at 10:32 AM, Rob Clark wrote:
>> On Fri, Aug 12, 2016 at 9:48 AM, Sricharan wrote:
>>> Hi,
>>>
> btw, the current state, at least on linaro integration branch, fault
> handling doesn't work so well (ie. dev
Hi,
>>>
> btw, the current state, at least on linaro integration branch, fault
> handling doesn't work so well (ie. device never gets resumed).. which
> is a bit unfortunate for a gpu (and results in a *lot* of rebooting on
> my part when debugging userspace). I ha
On Fri, Aug 12, 2016 at 10:32 AM, Rob Clark wrote:
> On Fri, Aug 12, 2016 at 9:48 AM, Sricharan wrote:
>> Hi,
>>
btw, the current state, at least on linaro integration branch, fault
handling doesn't work so well (ie. device never gets resumed).. which
is a bit unfortuna
On Fri, Aug 12, 2016 at 9:48 AM, Sricharan wrote:
> Hi,
>
>>> btw, the current state, at least on linaro integration branch, fault
>>> handling doesn't work so well (ie. device never gets resumed).. which
>>> is a bit unfortunate for a gpu (and results in a *lot* of rebooting on
>>
Hi,
>> btw, the current state, at least on linaro integration branch, fault
>> handling doesn't work so well (ie. device never gets resumed).. which
>> is a bit unfortunate for a gpu (and results in a *lot* of rebooting on
>> my part when debugging userspace). I haven't had time y
On Fri, Aug 12, 2016 at 9:03 AM, Sricharan wrote:
> Hi Rob,
>
> btw, the current state, at least on linaro integration branch, fault
> handling doesn't work so well (ie. device never gets resumed).. which
> is a bit unfortunate for a gpu (and results in a *lot* of rebooting on
> my
Hi Rob,
btw, the current state, at least on linaro integration branch, fault
handling doesn't work so well (ie. device never gets resumed).. which
is a bit unfortunate for a gpu (and results in a *lot* of rebooting on
my part when debugging userspace). I haven't had time yet t
On Fri, Aug 12, 2016 at 3:00 AM, Sricharan wrote:
> Hi Rob,
>
>>> btw, the current state, at least on linaro integration branch, fault
>>> handling doesn't work so well (ie. device never gets resumed).. which
>>> is a bit unfortunate for a gpu (and results in a *lot* of rebooting on
>>> my part wh
Hi,
On Tue, Aug 9, 2016 at 7:49 AM, Sricharan R wrote:
> +
> + if (ops->add_device)
> + ops = ops->add_device(dev) ? ops : NULL;
Patch description fails to mention anything about this change. Also it
looks slightly incorrect to lose the error condition here. I
Hi,
On Tue, Aug 9, 2016 at 7:49 AM, Sricharan R wrote:
> The dma_ops gets configured for the device generically during
> the device_attach call. So remove it from the platform bus probe.
> Similarly remove the deconfigure calls as well, since it is
> now called form the device_detach path.
Doesn
Hi,
On Tue, Aug 9, 2016 at 7:49 AM, Sricharan R wrote:
> From: Laurent Pinchart
>
> The of_configure_dma() function configures both the DMA masks and ops.
> Moving DMA ops configuration to probe time would thus also delay
> configuration of the DMA masks, which might not be safe. To avoid issues
Hi Rob,
>> btw, the current state, at least on linaro integration branch, fault
>> handling doesn't work so well (ie. device never gets resumed).. which
>> is a bit unfortunate for a gpu (and results in a *lot* of rebooting on
>> my part when debugging userspace). I haven't had time yet to compar
21 matches
Mail list logo
