From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Mike Leach <mike.leach@linaro.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arm-msm@vger.kernel.org,
Coresight ML <coresight@lists.linaro.org>,
Stephen Boyd <swboyd@chromium.org>,
robin.murphy@arm.com
Subject: Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
Date: Wed, 03 Jun 2020 15:54:17 +0530 [thread overview]
Message-ID: <f0357072de96970b641bbd0da98c1d61@codeaurora.org> (raw)
In-Reply-To: <CAJ9a7VhMbdqVBHxEXGYxFkgPnnQqNnDAz=wkHP3s7Ntw0iLmKA@mail.gmail.com>
Hi Mike,
Thanks again for looking at this.
On 2020-06-03 03:42, Mike Leach wrote:
[...]
>>
>> SMMU/IOMMU won't be able to do much here as it is the client's
>> responsiblity to
>> properly shutdown and SMMU device link just makes sure that
>> SMMU(supplier) shutdown is
>> called only after its consumers shutdown callbacks are called.
>
> I think this use case can be handled slightly differently than the
> general requirements for modular CoreSight drivers.
>
> What is needed here is a way of stopping the underlying ETR hardware
> from issuing data to the SMMU, until the entire device has been shut
> down, in a way that does not remove the driver, breaking existing
> references and causing a system crash.
>
> We could introduce a new mode to the ETR driver - e.g.
> CS_MODE_SHUTDOWN.
>
> At the end of the block tmc_shutdown(struct amba_device *adev), set
> drvdata->mode to CS_MODE_SHUTDOWN & remove the coresight_unregister().
> This new mode can be used to prevent the underlying hardware from
> being able to restart until the device is re-powered.
>
> This mode can be detected in the code that enables / disables the ETR
> and handled appropriately (updates to tmc_enable_etr_sink and
> tmc_disable_etr_sink).
> This mode will persist until the device is re-started - but because we
> are on the device shutdown path this is not an issue.
>
> This should leave the CoreSight infrastructure stable until the
> drivers are shut down normally as part of the device power down
> process.
>
Sounds good to me, but if the coresight_unregister() is the trouble
point
causing these crashes, then can't we just remove that from
tmc_shutdown()
callback? This would be like maintaining the same behaviour as now where
on reboot/shutdown we basically don't do anything except for disabling
ETR.
This way, we do not have to introduce any new mode as well. To be exact,
in
tmc_shutdown() we just disable ETR and then return without unregistering
which should not cause any issues since this is shutdown not the remove
callback which is a requirement for making coresight modular like below:
static void tmc_shutdown(struct amba_device *adev)
{
unsigned long flags;
struct tmc_drvdata *drvdata = amba_get_drvdata(adev);
spin_lock_irqsave(&drvdata->spinlock, flags);
if (drvdata->mode == CS_MODE_DISABLED)
goto out;
if (drvdata->config_type == TMC_CONFIG_TYPE_ETR)
tmc_etr_disable_hw(drvdata);
/*
* We do not care about coresight unregister here unlike remove
* callback which is required for making coresight modular
since
* the system is going down after this.
*/
out:
spin_unlock_irqrestore(&drvdata->spinlock, flags);
}
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Mike Leach <mike.leach@linaro.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
linux-arm-msm@vger.kernel.org,
Coresight ML <coresight@lists.linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Stephen Boyd <swboyd@chromium.org>,
robin.murphy@arm.com,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
Date: Wed, 03 Jun 2020 15:54:17 +0530 [thread overview]
Message-ID: <f0357072de96970b641bbd0da98c1d61@codeaurora.org> (raw)
In-Reply-To: <CAJ9a7VhMbdqVBHxEXGYxFkgPnnQqNnDAz=wkHP3s7Ntw0iLmKA@mail.gmail.com>
Hi Mike,
Thanks again for looking at this.
On 2020-06-03 03:42, Mike Leach wrote:
[...]
>>
>> SMMU/IOMMU won't be able to do much here as it is the client's
>> responsiblity to
>> properly shutdown and SMMU device link just makes sure that
>> SMMU(supplier) shutdown is
>> called only after its consumers shutdown callbacks are called.
>
> I think this use case can be handled slightly differently than the
> general requirements for modular CoreSight drivers.
>
> What is needed here is a way of stopping the underlying ETR hardware
> from issuing data to the SMMU, until the entire device has been shut
> down, in a way that does not remove the driver, breaking existing
> references and causing a system crash.
>
> We could introduce a new mode to the ETR driver - e.g.
> CS_MODE_SHUTDOWN.
>
> At the end of the block tmc_shutdown(struct amba_device *adev), set
> drvdata->mode to CS_MODE_SHUTDOWN & remove the coresight_unregister().
> This new mode can be used to prevent the underlying hardware from
> being able to restart until the device is re-powered.
>
> This mode can be detected in the code that enables / disables the ETR
> and handled appropriately (updates to tmc_enable_etr_sink and
> tmc_disable_etr_sink).
> This mode will persist until the device is re-started - but because we
> are on the device shutdown path this is not an issue.
>
> This should leave the CoreSight infrastructure stable until the
> drivers are shut down normally as part of the device power down
> process.
>
Sounds good to me, but if the coresight_unregister() is the trouble
point
causing these crashes, then can't we just remove that from
tmc_shutdown()
callback? This would be like maintaining the same behaviour as now where
on reboot/shutdown we basically don't do anything except for disabling
ETR.
This way, we do not have to introduce any new mode as well. To be exact,
in
tmc_shutdown() we just disable ETR and then return without unregistering
which should not cause any issues since this is shutdown not the remove
callback which is a requirement for making coresight modular like below:
static void tmc_shutdown(struct amba_device *adev)
{
unsigned long flags;
struct tmc_drvdata *drvdata = amba_get_drvdata(adev);
spin_lock_irqsave(&drvdata->spinlock, flags);
if (drvdata->mode == CS_MODE_DISABLED)
goto out;
if (drvdata->config_type == TMC_CONFIG_TYPE_ETR)
tmc_etr_disable_hw(drvdata);
/*
* We do not care about coresight unregister here unlike remove
* callback which is required for making coresight modular
since
* the system is going down after this.
*/
out:
spin_unlock_irqrestore(&drvdata->spinlock, flags);
}
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-06-03 10:24 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 8:02 [PATCH 0/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF Sai Prakash Ranjan
2020-06-01 8:02 ` Sai Prakash Ranjan
2020-06-01 8:02 ` [PATCH 1/2] coresight: tmc: Add enable flag to indicate the status of ETR/ETF Sai Prakash Ranjan
2020-06-01 8:02 ` Sai Prakash Ranjan
2020-06-01 13:27 ` Mike Leach
2020-06-01 13:27 ` Mike Leach
2020-06-01 17:13 ` Sai Prakash Ranjan
2020-06-01 17:13 ` Sai Prakash Ranjan
2020-06-01 8:02 ` [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF Sai Prakash Ranjan
2020-06-01 8:02 ` Sai Prakash Ranjan
2020-06-01 13:35 ` Mike Leach
2020-06-01 13:35 ` Mike Leach
2020-06-01 17:15 ` Sai Prakash Ranjan
2020-06-01 17:15 ` Sai Prakash Ranjan
2020-06-01 21:28 ` Mathieu Poirier
2020-06-01 21:28 ` Mathieu Poirier
2020-06-02 7:30 ` Sai Prakash Ranjan
2020-06-02 7:30 ` Sai Prakash Ranjan
2020-06-02 22:12 ` Mike Leach
2020-06-02 22:12 ` Mike Leach
2020-06-03 10:24 ` Sai Prakash Ranjan [this message]
2020-06-03 10:24 ` Sai Prakash Ranjan
2020-06-03 11:27 ` Mike Leach
2020-06-03 11:27 ` Mike Leach
2020-06-03 12:14 ` Sai Prakash Ranjan
2020-06-03 12:14 ` Sai Prakash Ranjan
2020-06-03 13:22 ` Mike Leach
2020-06-03 13:22 ` Mike Leach
2020-06-03 13:34 ` Robin Murphy
2020-06-03 13:34 ` Robin Murphy
2020-06-03 13:43 ` Sai Prakash Ranjan
2020-06-03 13:43 ` Sai Prakash Ranjan
2020-06-03 13:51 ` Mike Leach
2020-06-03 13:51 ` Mike Leach
2020-06-03 14:02 ` Sai Prakash Ranjan
2020-06-03 14:02 ` Sai Prakash Ranjan
2020-06-03 17:44 ` Mathieu Poirier
2020-06-03 17:44 ` Mathieu Poirier
2020-06-04 7:27 ` Sai Prakash Ranjan
2020-06-04 7:27 ` Sai Prakash Ranjan
2020-06-08 14:07 ` Sai Prakash Ranjan
2020-06-08 14:07 ` Sai Prakash Ranjan
2020-06-09 15:27 ` Mathieu Poirier
2020-06-09 15:27 ` Mathieu Poirier
2020-06-09 15:37 ` Sai Prakash Ranjan
2020-06-09 15:37 ` Sai Prakash Ranjan
2020-06-03 11:37 ` Robin Murphy
2020-06-03 11:37 ` Robin Murphy
2020-06-03 12:00 ` Sai Prakash Ranjan
2020-06-03 12:00 ` Sai Prakash Ranjan
2020-06-03 12:21 ` Robin Murphy
2020-06-03 12:21 ` Robin Murphy
2020-06-03 12:26 ` Sai Prakash Ranjan
2020-06-03 12:26 ` Sai Prakash Ranjan
2020-06-03 13:40 ` Robin Murphy
2020-06-03 13:40 ` Robin Murphy
2020-06-03 13:51 ` Sai Prakash Ranjan
2020-06-03 13:51 ` Sai Prakash Ranjan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f0357072de96970b641bbd0da98c1d61@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=coresight@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=robin.murphy@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=swboyd@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.