On Mon, 15 Jun 2020 at 17:57, Krzysztof Kozlowski wrote:
>
> On Mon, Jun 15, 2020 at 05:23:28PM +0300, Vladimir Oltean wrote:
> > On Mon, 15 Jun 2020 at 16:41, Krzysztof Kozlowski wrote:
> > >
> > > On Mon, Jun 15, 2020 at 04:12:28PM +0300, Vladimir Oltean wrote:
> > > > On Mon, 15 Jun 2020 at 16
On Mon, Jun 15, 2020 at 05:23:28PM +0300, Vladimir Oltean wrote:
> On Mon, 15 Jun 2020 at 16:41, Krzysztof Kozlowski wrote:
> >
> > On Mon, Jun 15, 2020 at 04:12:28PM +0300, Vladimir Oltean wrote:
> > > On Mon, 15 Jun 2020 at 16:10, Mark Brown wrote:
> > >
> > > >
> > > > It's a bit unusual to ne
On Mon, 15 Jun 2020 at 16:41, Krzysztof Kozlowski wrote:
>
> On Mon, Jun 15, 2020 at 04:12:28PM +0300, Vladimir Oltean wrote:
> > On Mon, 15 Jun 2020 at 16:10, Mark Brown wrote:
> >
> > >
> > > It's a bit unusual to need to actually free the IRQ over suspend -
> > > what's driving that requiremen
On Mon, Jun 15, 2020 at 04:12:28PM +0300, Vladimir Oltean wrote:
> On Mon, 15 Jun 2020 at 16:10, Mark Brown wrote:
>
> >
> > It's a bit unusual to need to actually free the IRQ over suspend -
> > what's driving that requirement here?
>
> clk_disable_unprepare(dspi->clk); is driving the requireme
On Mon, Jun 15, 2020 at 04:29:15PM +0300, Vladimir Oltean wrote:
> On Mon, 15 Jun 2020 at 16:24, Mark Brown wrote:
> > I see - this could be fixed by having the interrupt handler bounce the
> > clock on, there's a little overhead from that but hopefully not too
> > much. That should also help wi
On Mon, 15 Jun 2020 at 16:28, Krzysztof Kozlowski wrote:
>
> On Mon, Jun 15, 2020 at 04:14:06PM +0300, Vladimir Oltean wrote:
> > On Mon, 15 Jun 2020 at 16:10, Krzysztof Kozlowski wrote:
> > >
> >
> > >
> > > It is a slightly different bug which so this patch should have a follow
> > > up.
> > >
On Mon, 15 Jun 2020 at 16:24, Mark Brown wrote:
>
> On Mon, Jun 15, 2020 at 04:12:28PM +0300, Vladimir Oltean wrote:
> > On Mon, 15 Jun 2020 at 16:10, Mark Brown wrote:
>
> > > It's a bit unusual to need to actually free the IRQ over suspend -
> > > what's driving that requirement here?
>
> > clk
On Mon, Jun 15, 2020 at 04:14:06PM +0300, Vladimir Oltean wrote:
> On Mon, 15 Jun 2020 at 16:10, Krzysztof Kozlowski wrote:
> >
>
> >
> > It is a slightly different bug which so this patch should have a follow
> > up.
> >
> > Best regards,
> > Krzysztof
> >
>
> Why is it a different bug? It's th
On Mon, Jun 15, 2020 at 04:12:28PM +0300, Vladimir Oltean wrote:
> On Mon, 15 Jun 2020 at 16:10, Mark Brown wrote:
> > It's a bit unusual to need to actually free the IRQ over suspend -
> > what's driving that requirement here?
> clk_disable_unprepare(dspi->clk); is driving the requirement - sam
On Mon, 15 Jun 2020 at 16:10, Krzysztof Kozlowski wrote:
>
>
> It is a slightly different bug which so this patch should have a follow
> up.
>
> Best regards,
> Krzysztof
>
Why is it a different bug? It's the same bug.
On Mon, 15 Jun 2020 at 16:10, Mark Brown wrote:
>
> It's a bit unusual to need to actually free the IRQ over suspend -
> what's driving that requirement here?
clk_disable_unprepare(dspi->clk); is driving the requirement - same as
in dspi_remove case, the module will fault when its registers are
On Mon, Jun 15, 2020 at 03:56:01PM +0300, Vladimir Oltean wrote:
> On Mon, 15 Jun 2020 at 15:35, Mark Brown wrote:
> >
>
> >
> > Indeed. The upshot of all this is that the interrupt needs to be freed
> > not disabled before the clocks are disabled, or some other mechanism
> > needs to be used to
On Mon, Jun 15, 2020 at 03:56:01PM +0300, Vladimir Oltean wrote:
> And the down-shot is that whatever is done in dspi_remove (free_irq)
> also needs to be done in dspi_suspend, but with extra care in
> dspi_resume not only to request the irq again, but also to flush the
> module's FIFOs and clear
On Mon, Jun 15, 2020 at 12:23:41PM +0300, Vladimir Oltean wrote:
> On Mon, 15 Jun 2020 at 11:18, Marc Kleine-Budde wrote:
> >
> > On 6/15/20 10:07 AM, Krzysztof Kozlowski wrote:
> > > If interrupt comes late, during probe error path or device remove (could
> > > be triggered with CONFIG_DEBUG_SHIR
On Mon, 15 Jun 2020 at 15:35, Mark Brown wrote:
>
>
> Indeed. The upshot of all this is that the interrupt needs to be freed
> not disabled before the clocks are disabled, or some other mechanism
> needs to be used to ensure that the interrupt handler won't attempt to
> access the hardware when
On Mon, Jun 15, 2020 at 10:17:07AM +0200, Marc Kleine-Budde wrote:
> On 6/15/20 10:07 AM, Krzysztof Kozlowski wrote:
> > If interrupt comes late, during probe error path or device remove (could
> > be triggered with CONFIG_DEBUG_SHIRQ), the interrupt handler
> > dspi_interrupt() will access registe
On Mon, 15 Jun 2020 at 11:18, Marc Kleine-Budde wrote:
>
> On 6/15/20 10:07 AM, Krzysztof Kozlowski wrote:
> > If interrupt comes late, during probe error path or device remove (could
> > be triggered with CONFIG_DEBUG_SHIRQ), the interrupt handler
> > dspi_interrupt() will access registers with t
On 6/15/20 10:07 AM, Krzysztof Kozlowski wrote:
> If interrupt comes late, during probe error path or device remove (could
> be triggered with CONFIG_DEBUG_SHIRQ), the interrupt handler
> dspi_interrupt() will access registers with the clock being disabled. This
> leads to external abort on non-li
If interrupt comes late, during probe error path or device remove (could
be triggered with CONFIG_DEBUG_SHIRQ), the interrupt handler
dspi_interrupt() will access registers with the clock being disabled. This
leads to external abort on non-linefetch on Toradex Colibri VF50 module
(with Vybrid VF5x
19 matches
Mail list logo
