* Re: [GIT PULL] Qualcomm ARM64 Defconfig updates for 5.4
From: Arnd Bergmann @ 2019-09-04 15:00 UTC (permalink / raw)
To: Andy Gross
Cc: linux-arm-msm, Bjorn Andersson, arm-soc, Kevin Hilman,
Olof Johansson, Linux ARM
In-Reply-To: <1567317285-8555-1-git-send-email-agross@kernel.org>
On Sun, Sep 1, 2019 at 7:54 AM Andy Gross <agross@kernel.org> wrote:
> Qualcomm ARM64 Based defconfig Updates for v5.4
>
> * Enable Qualcomm MSM8916 clock drivers
> * Add DRM_MSM to ARCH_QCOM defconfigs
> * Enable Qualcomm SM8150 clock and pinctrl drivers
Pulled into arm/defconfig.
Please remember to send pull requests to soc@kernel.org to have them
linked in the patchwork instance at
https://patchwork.kernel.org/project/linux-soc/list/
Thanks,
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Qualcomm ARM64 DT updates for 5.4
From: Arnd Bergmann @ 2019-09-04 15:03 UTC (permalink / raw)
To: Andy Gross
Cc: linux-arm-msm, Bjorn Andersson, arm-soc, Kevin Hilman,
Olof Johansson, Linux ARM
In-Reply-To: <1567317285-8555-2-git-send-email-agross@kernel.org>
On Sun, Sep 1, 2019 at 7:54 AM Andy Gross <agross@kernel.org> wrote:
> ----------------------------------------------------------------
> Qualcomm ARM64 Updates for v5.4
>
> * Add Lenovo Miix 630, HP Envy x2, and Asus Novago TP370QL support
> * Assorted cleanups for SDM845 nodes
> * Add video nodes, cpu coefficients, adsp, csdp, and
> fastrpc nodes for SDM845
> * Add coresight for MSM8996, SDM845, and MSM8998
> * Misc cleanups on QCS404 and PMS405
> * Update memory map for QCS404
> * Add wifi rails, update WCSS clocks, and add ADS unit names on QCS404
> * Add Longcheer and Samsung Galaxy A3U/A5U support
> * Add initial support for SM8150 and PM8150
>
Pulled into arm/dt, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 1/3] mmc: mmci: add hardware busy timeout feature
From: Ludovic BARRE @ 2019-09-04 15:04 UTC (permalink / raw)
To: Ulf Hansson
Cc: DTML, Alexandre Torgue, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, Rob Herring, Srinivas Kandagatla,
Maxime Coquelin, linux-stm32, Linux ARM
In-Reply-To: <CAPDyKFpOj8g+eY-vTxW4Sk+wVYTP1-4jDJB=nE=24eSubBvN-g@mail.gmail.com>
hi Ulf
On 8/26/19 1:39 PM, Ulf Hansson wrote:
> On Tue, 13 Aug 2019 at 12:00, Ludovic Barre <ludovic.Barre@st.com> wrote:
>>
>> From: Ludovic Barre <ludovic.barre@st.com>
>>
>> In some variants, the data timer starts and decrements
>> when the DPSM enters in Wait_R or Busy state
>> (while data transfer or MMC_RSP_BUSY), and generates a
>> data timeout error if the counter reach 0.
>
> I don't quite follow here, sorry. Can you please try to elaborate on
> the use case(s) more exactly?
>
> For example, what happens when a data transfer has just finished (for
> example when MCI_DATAEND has been received) and we are going to send a
> CMD12 to stop it? In this case the CMD12 has the MMC_RSP_BUSY flag
> set.
>
example with cmd25 (write multi block)
mmci_request
- mmci_start_data
set MMCIDATATIMER, MMCIDATALENGTH, MMCIMASK0
- mmci_start_command:
set MMCIARGUMENT, MMCICOMMAND (cmd25)
mmci_irq:
- irq MCI_CMDRESPEND
- irq MCI_DATAEND
- send cmd12 => mmci_start_command(host->stop_abort or data->stop)
these cmds have flag rsp_busy and no data associate
host->cmd = cmd (host->stop_abort or data->stop) for next irq
mmci_irq:
- irq MCI_CMDRESPEND
- irq BUSYD0END
- mmci_request_end
> Another example is the CMD5, which has no data with it.
>
>>
>> -Define max_busy_timeout (in ms) according to clock.
>> -Set data timer register if the command has rsp_busy flag.
>> If busy_timeout is not defined by framework, the busy
>> length after Data Burst is defined as 1 second
>> (refer: 4.6.2.2 Write of sd specification part1 v6-0).
>
> One second is not sufficient for all operations, like ERASE for
> example. However, I understand that you want to pick some value, as a
> safety. I guess that's fine.
>
> I am thinking that if the command has the MMC_RSP_BUSY flag set, the
> core should really provide a busy timeout for it. That said, maybe the
> host driver should splat a WARN in case there is not busy timeout
> specified.
Today, I just see a busy_timeout not defined on write request.
On erase request, the timeout is defined in function mmc_do_erase.
In core, there are several paths to done a write request, and I not
be sure to fix all. For safety, I preferred fix with the max value of
write request.
>
>> -Add MCI_DATATIMEOUT error management in mmci_cmd_irq.
>>
>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>> ---
>> drivers/mmc/host/mmci.c | 37 ++++++++++++++++++++++++++++++++-----
>> drivers/mmc/host/mmci.h | 3 +++
>> 2 files changed, 35 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
>> index c37e70dbe250..c50586540765 100644
>> --- a/drivers/mmc/host/mmci.c
>> +++ b/drivers/mmc/host/mmci.c
>> @@ -1075,6 +1075,7 @@ static void
>> mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
>> {
>> void __iomem *base = host->base;
>> + unsigned long long clks = 0;
>>
>> dev_dbg(mmc_dev(host->mmc), "op %02x arg %08x flags %08x\n",
>> cmd->opcode, cmd->arg, cmd->flags);
>> @@ -1097,6 +1098,19 @@ mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
>> else
>> c |= host->variant->cmdreg_srsp;
>> }
>> +
>> + if (host->variant->busy_timeout && !host->mrq->data) {
>
> Suppose this is a CMD12 command, having the MMC_RSP_BUSY flag set. The
> command would then be sent to stop the transmission and then
> host->mrq->data would also be set.
Sorry, it's a mistake introduce by v5.
I would keep the clear of datatimer when is not needed
(no data & no rsp busy, see below). But on cmd23 (set_block_count) with
datactrl_first variant property the datatimer should be protected.
To simplify and fix the code, I will remove the clear of datatimer
when there is no data & no rsp busy.
- if (host->variant->busy_timeout && !host->mrq->data) {
+ if (host->variant->busy_timeout && !cmd->flags & MMC_RSP_BUSY) {
+ ....
+ writel_relaxed(clks, host->base + MMCIDATATIMER);
+ }
>
> If I recall earlier what you stated about the new sdmmc variant, the
> CMD12 is needed to exit the DPSM. Hence don't you need to re-program a
> new value for the MMCIDATATIMER register for this scenario?
>
>> + if (cmd->flags & MMC_RSP_BUSY) {
>> + if (!cmd->busy_timeout)
>> + cmd->busy_timeout = 1000;
>> +
>> + clks = (unsigned long long)cmd->busy_timeout;
>> + clks *= host->cclk;
>
> Any problems with putting the above on one line?
No, it was just to not exceed 80 characters.
>
>> + do_div(clks, MSEC_PER_SEC);
>> + }
>> + writel_relaxed(clks, host->base + MMCIDATATIMER);
>
> This is writing zero to MMCIDATATIMER in case the MMC_RSP_BUSY isn't
> set, is that on purpose?
It was to clear the datatimer when the command has
no data & no rsp_busy. This allowed to look if the datatimer
was used and not correctly set with the right value (with datatimeout).
Like said above, I will remove this and set datatimer only
on rsp_busy flag.
>
>> + }
>> +
>> if (/*interrupt*/0)
>> c |= MCI_CPSM_INTERRUPT;
>>
>> @@ -1203,6 +1217,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>> {
>> void __iomem *base = host->base;
>> bool sbc, busy_resp;
>> + u32 err_msk;
>>
>> if (!cmd)
>> return;
>> @@ -1215,8 +1230,12 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>> * handling. Note that we tag on any latent IRQs postponed
>> * due to waiting for busy status.
>> */
>> - if (!((status|host->busy_status) &
>> - (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT|MCI_CMDSENT|MCI_CMDRESPEND)))
>> + err_msk = MCI_CMDCRCFAIL | MCI_CMDTIMEOUT;
>
> You might as well move the initial assignment of err_msk to the its
> declaration above.
>
OK, thx
>> + if (host->variant->busy_timeout && busy_resp)
>> + err_msk |= MCI_DATATIMEOUT;
>> +
>> + if (!((status | host->busy_status) &
>> + (err_msk | MCI_CMDSENT | MCI_CMDRESPEND)))
>> return;
>>
>> /* Handle busy detection on DAT0 if the variant supports it. */
>> @@ -1235,8 +1254,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>> * while, to allow it to be set, but tests indicates that it
>> * isn't needed.
>> */
>> - if (!host->busy_status &&
>> - !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
>> + if (!host->busy_status && !(status & err_msk) &&
>> (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
>>
>> writel(readl(base + MMCIMASK0) |
>> @@ -1290,6 +1308,9 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>> cmd->error = -ETIMEDOUT;
>> } else if (status & MCI_CMDCRCFAIL && cmd->flags & MMC_RSP_CRC) {
>> cmd->error = -EILSEQ;
>> + } else if (host->variant->busy_timeout && busy_resp &&
>> + status & MCI_DATATIMEOUT) {
>> + cmd->error = -ETIMEDOUT;
>> } else {
>> cmd->resp[0] = readl(base + MMCIRESPONSE0);
>> cmd->resp[1] = readl(base + MMCIRESPONSE1);
>> @@ -1948,6 +1969,8 @@ static int mmci_probe(struct amba_device *dev,
>> * Enable busy detection.
>> */
>> if (variant->busy_detect) {
>> + u32 max_busy_timeout = 0;
>> +
>> mmci_ops.card_busy = mmci_card_busy;
>> /*
>> * Not all variants have a flag to enable busy detection
>> @@ -1957,7 +1980,11 @@ static int mmci_probe(struct amba_device *dev,
>> mmci_write_datactrlreg(host,
>> host->variant->busy_dpsm_flag);
>> mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
>> - mmc->max_busy_timeout = 0;
>> +
>> + if (variant->busy_timeout)
>> + max_busy_timeout = ~0UL / (mmc->f_max / MSEC_PER_SEC);
>
> It looks like the max busy timeout is depending on the current picked
> clock rate, right?
>
> In such case, perhaps it's better to update mmc->max_busy_timeout as
> part of the ->set_ios() callback, as it's from there the clock rate
> gets updated. Or what do you think?
yes, it's possible
>
>> +
>> + mmc->max_busy_timeout = max_busy_timeout;
>> }
>>
>> /* Prepare a CMD12 - needed to clear the DPSM on some variants. */
>> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
>> index 833236ecb31e..d8b7f6774e8f 100644
>> --- a/drivers/mmc/host/mmci.h
>> +++ b/drivers/mmc/host/mmci.h
>> @@ -287,6 +287,8 @@ struct mmci_host;
>> * @signal_direction: input/out direction of bus signals can be indicated
>> * @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
>> * @busy_detect: true if the variant supports busy detection on DAT0.
>> + * @busy_timeout: true if the variant starts data timer when the DPSM
>> + * enter in Wait_R or Busy state.
>> * @busy_dpsm_flag: bitmask enabling busy detection in the DPSM
>> * @busy_detect_flag: bitmask identifying the bit in the MMCISTATUS register
>> * indicating that the card is busy
>> @@ -333,6 +335,7 @@ struct variant_data {
>> u8 signal_direction:1;
>> u8 pwrreg_clkgate:1;
>> u8 busy_detect:1;
>> + u8 busy_timeout:1;
>> u32 busy_dpsm_flag;
>> u32 busy_detect_flag;
>> u32 busy_detect_mask;
>> --
>> 2.17.1
>>
>
> Kind regards
> Uffe
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 02/10] KVM: arm/arm64: Factor out hypercall handling from PSCI code
From: Steven Price @ 2019-09-04 15:05 UTC (permalink / raw)
To: kbuild test robot
Cc: Mark Rutland, Christoffer Dall, kvm,
Radim =?unknown-8bit?B?S3LEjW3DocWZ?=, Catalin Marinas,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, kbuild-all, Marc Zyngier, Paolo Bonzini,
Julien Thierry, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <201909021437.rO6o0mHc%lkp@intel.com>
On 02/09/2019 08:06, kbuild test robot wrote:
> Hi Steven,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3-rc6 next-20190830]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Steven-Price/arm64-Stolen-time-support/20190901-185152
> config: i386-randconfig-a002-201935 (attached as .config)
> compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All error/warnings (new ones prefixed by >>):
>
> In file included from include/kvm/arm_hypercalls.h:7:0,
> from <command-line>:0:
>>> arch/x86/include/asm/kvm_emulate.h:349:22: error: 'NR_VCPU_REGS' undeclared here (not in a function)
> unsigned long _regs[NR_VCPU_REGS];
> ^~~~~~~~~~~~
This is because x86's asm/kvm_emulate.h can't be included by itself (and
doesn't even exist on other architectures). This new header file doesn't
make sense to include on x86, so I'll squash in the following to prevent
building the header file except on arm/arm64.
Steve
----8<----
diff --git a/include/Kbuild b/include/Kbuild
index c38f0d46b267..f775ea28716e 100644
--- a/include/Kbuild
+++ b/include/Kbuild
@@ -67,6 +67,8 @@ header-test- += keys/big_key-type.h
header-test- += keys/request_key_auth-type.h
header-test- += keys/trusted.h
header-test- += kvm/arm_arch_timer.h
+header-test-$(CONFIG_ARM) += kvm/arm_hypercalls.h
+header-test-$(CONFIG_ARM64) += kvm/arm_hypercalls.h
header-test- += kvm/arm_pmu.h
header-test-$(CONFIG_ARM) += kvm/arm_psci.h
header-test-$(CONFIG_ARM64) += kvm/arm_psci.h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [GIT PULL] Qualcomm Defconfig updates for 5.4
From: Arnd Bergmann @ 2019-09-04 15:05 UTC (permalink / raw)
To: Andy Gross
Cc: linux-arm-msm, Bjorn Andersson, arm-soc, Kevin Hilman,
Olof Johansson, Linux ARM
In-Reply-To: <1567317285-8555-3-git-send-email-agross@kernel.org>
On Sun, Sep 1, 2019 at 7:54 AM Andy Gross <agross@kernel.org> wrote:
> ----------------------------------------------------------------
> Qualcomm ARM Based defconfig Updates for v5.4
>
> * Add DRM_MSM to ARCH_QCOM defconfigs
Pulled into arm/defconfig, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 01/10] KVM: arm64: Document PV-time interface
From: Steven Price @ 2019-09-04 15:07 UTC (permalink / raw)
To: Andrew Jones
Cc: Mark Rutland, Radim Krčmář, kvm, Suzuki K Pouloze,
Marc Zyngier, linux-doc, Russell King, linux-kernel, James Morse,
linux-arm-kernel, Catalin Marinas, Paolo Bonzini, Will Deacon,
kvmarm, Julien Thierry
In-Reply-To: <20190904142250.ohnkunb5ocwbnx6z@kamzik.brq.redhat.com>
On 04/09/2019 15:22, Andrew Jones wrote:
> On Wed, Sep 04, 2019 at 02:55:15PM +0100, Steven Price wrote:
>> On 02/09/2019 13:52, Andrew Jones wrote:
>>> On Fri, Aug 30, 2019 at 04:25:08PM +0100, Steven Price wrote:
>>>> On 30/08/2019 15:47, Andrew Jones wrote:
>>>>> On Fri, Aug 30, 2019 at 09:42:46AM +0100, Steven Price wrote:
>> [...]
>>>>>> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
>>>>>> + PV-time feature is supported by the hypervisor.
>>>>>> +
>>>>>> +PV_TIME_ST
>>>>>> + Function ID: (uint32) : 0xC5000022
>>>>>> + Return value: (int64) : IPA of the stolen time data structure for this
>>>>>> + VCPU. On failure:
>>>>>> + NOT_SUPPORTED (-1)
>>>>>> +
>>>>>> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
>>>>>> +with inner and outer write back caching attributes, in the inner shareable
>>>>>> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
>>>>>> +meaningfully filled by the hypervisor (see structure below).
>>>>>> +
>>>>>> +PV_TIME_ST returns the structure for the calling VCPU.
>>>>>> +
>>>>>> +Stolen Time
>>>>>> +-----------
>>>>>> +
>>>>>> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
>>>>>> +
>>>>>> + Field | Byte Length | Byte Offset | Description
>>>>>> + ----------- | ----------- | ----------- | --------------------------
>>>>>> + Revision | 4 | 0 | Must be 0 for version 0.1
>>>>>> + Attributes | 4 | 4 | Must be 0
>>>>>
>>>>> The above fields don't appear to be exposed to userspace in anyway. How
>>>>> will we handle migration from one KVM with one version of the structure
>>>>> to another?
>>>>
>>>> Interesting question. User space does have access to them now it is
>>>> providing the memory, but it's not exactly an easy method. In particular
>>>> user space has no (simple) way of probing the kernel's supported version.
>>>>
>>>> I guess one solution would be to add an extra attribute on the VCPU
>>>> which would provide the revision information. The current kernel would
>>>> then reject any revision other than 0, but this could then be extended
>>>> to support other revision numbers in the future.
>>>>
>>>> Although there's some logic in saying we could add the extra attribute
>>>> when(/if) there is a new version. Future kernels would then be expected
>>>> to use the current version unless user space explicitly set the new
>>>> attribute.
>>>>
>>>> Do you feel this is something that needs to be addressed now, or can it
>>>> be deferred until another version is proposed?
>>>
>>> Assuming we'll want userspace to have the option of choosing version=0,
>>> and that we're fine with version=0 being the implicit choice, when nothing
>>> is selected, then I guess it can be left as is for now. If, OTOH, we just
>>> want migration to fail when attempting to migrate to another host with
>>> an incompatible stolen-time structure (i.e. version=0 is not selectable
>>> on hosts that implement later versions), then we should expose the version
>>> in some way now. Perhaps a VCPU's "PV config" should be described in a
>>> set of pseudo registers?
>>
>> I wouldn't have thought making migration fail if/when the host upgrades
>> to a new version would be particularly helpful - we'd want to provide
>> backwards compatibility. In particular for the suspend/resume case (I
>> want to be able to save my VM to disk, upgrade the host kernel and then
>> resume the VM).
>>
>> The only potential issue I see is the implicit "version=0 if not
>> specified". That seems solvable by rejecting setting the stolen time
>> base address if no version has been specified and the host kernel
>> doesn't support version=0.
>
> I think that's the same failure I was trying avoid by failing the
> migration instead. Maybe it's equivalent to fail at this vcpu-ioctl
> time though?
Yes this is effectively the same failure. But since we require the
vcpu-ioctl to enable stolen time this gives an appropriate place to
fail. Indeed this is the failure if migrating from a host with these
patches to one running an existing kernel with no stolen time support.
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 25/36] spi: s3c24xx: use devm_platform_ioremap_resource() to simplify code
From: Krzysztof Kozlowski @ 2019-09-04 15:09 UTC (permalink / raw)
To: Mark Brown
Cc: tmaimon77, palmer, tali.perry1, eric, ldewangan, linux-riscv,
festevam, f.fainelli, benjaminfair, shc_work, khilman, openbmc,
YueHaibing, michal.simek, jonathanh, yuenn, wens, agross,
bcm-kernel-feedback-list, linux-imx, linux-arm-msm, linux-tegra,
Andi Shyti, rjui, s.hauer, mripard,
linux-samsung-soc@vger.kernel.org, linux-mediatek,
linux-rpi-kernel, paul.walmsley, matthias.bgg, linux-amlogic,
linux-arm-kernel, baohua, sbranden, yamada.masahiro, avifishman70,
venture, linux-kernel@vger.kernel.org, linux-spi, thierry.reding,
wahrenst, kernel, kgene, shawnguo
In-Reply-To: <20190904143928.GB4348@sirena.co.uk>
On Wed, 4 Sep 2019 at 16:39, Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Sep 04, 2019 at 04:28:29PM +0200, Krzysztof Kozlowski wrote:
> > On Wed, 4 Sep 2019 at 16:00, YueHaibing <yuehaibing@huawei.com> wrote:
>
> > > Reported-by: Hulk Robot <hulkci@huawei.com>
>
> > This tag does not look real... First of all where is the report?
> > Second, it was reported by coccinelle.
> > Reported-by should be use to give real credits.
>
> I think it's reasonable, it's giving credit to the automated system
> they've got running coccinelle (which they do mention in their commit
> logs). It doesn't really hurt anyone and lets people see their system
> is finding stuff.
Running internally coccinelle is already credited with commit author.
The credits are coming with "From:" field.
Otherwise for commits I send I could use:
From: krzk
...
Reported-by: www.krzk.eu
Signed-off-by: krzk
To me it is ridiculous.
Different thing is that Reported-by is for fixing bugs or issues.
There is no bug here. There is no problem solved except making the
code smaller. That's not what is Reported-by for.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Qualcomm Driver updates for 5.4
From: Arnd Bergmann @ 2019-09-04 15:09 UTC (permalink / raw)
To: Andy Gross
Cc: linux-arm-msm, Bjorn Andersson, arm-soc, Kevin Hilman,
Olof Johansson, Linux ARM
In-Reply-To: <1567317285-8555-4-git-send-email-agross@kernel.org>
On Sun, Sep 1, 2019 at 7:54 AM Andy Gross <agross@kernel.org> wrote:
> Qualcomm ARM Based Driver Updates for v5.4
>
> * Add AOSS QMP support
> * Various fixups for Qualcomm SCM
> * Add socinfo driver
> * Add SoC serial number attribute and associated APIs
> * Add SM8150 and SC7180 support in Qualcomm SCM
> * Fixup max processor count in SMEM
>
Pulled into arm/drivers, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 3/3] Broadcom devicetree changes for 5.4
From: Arnd Bergmann @ 2019-09-04 15:12 UTC (permalink / raw)
To: Florian Fainelli
Cc: Kevin Hilman, Eric Anholt, arm-soc, bcm-kernel-feedback-list,
Stefan Wahren, Olof Johansson, Linux ARM
In-Reply-To: <20190819190552.11254-3-f.fainelli@gmail.com>
On Mon, Aug 19, 2019 at 9:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> This pull request contains Broadcom ARM-based SoCs Device Tree updates
> for 5.4, please pull the following:
>
> - Stefan does a bunch of preparatory work for supporting the Raspberry
> Pi 4in the next merge window correct register ranges (SPI, I2C,
> UART), define memory, HDMI and MMC properties at the board level
>
Pulled into arm/dt, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Texas Instruments K3 SoC changes for 5.4
From: Arnd Bergmann @ 2019-09-04 15:24 UTC (permalink / raw)
To: Tero Kristo
Cc: Nishanth Menon, Lokesh Vutla, SoC Team, arm-soc,
Santosh Shilimkar, Devshatwar, Nikhil,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <b838d666-ab3b-7d41-67d4-09d606c732da@ti.com>
On Fri, Aug 30, 2019 at 3:50 PM Tero Kristo <t-kristo@ti.com> wrote:
>
> Hello arm-soc maintainers,
>
> Here are the changes for TI K3 SoC family for 5.4. This pull request is
> based on top of drivers_soc_for_5.4 [1] from Santosh, basically because
> there is hard dependency on this pull towards that. Otherwise any of the
> DTS patches applying exclusive access flags will fail to compile.
>
> I am hoping this is fine, please holler if you have anything against
> this sequencing approach.
>
> [1] https://lkml.org/lkml/2019/8/26/1124
I pulled this into an arm/late branch this time, which simplifies
dealing with the dependency.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 1/2] ti-sysc driver changes for v5.3
From: Arnd Bergmann @ 2019-09-04 15:26 UTC (permalink / raw)
To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1566599057-142651@atomide.com>
On Sat, Aug 24, 2019 at 12:24 AM Tony Lindgren <tony@atomide.com> wrote:
> Driver changes for ti-sysc for v5.4
>
> Few changes to prepare for using a reset driver for PRM rstctrl mostly
> to deal with the clocks for reset. Then few minor clean-up patches and
> SPDX license identifier changes, and add a MAINTAINERs file entry.
Pulled this one into an arm/late branch, together with the three
other pull requests that depend on this one.
Don't worry about the arm/late name, I expect to send this off
together with the other branches, it's just easier for me to
describe what's in each of the top-level branches this way.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 2/4] more ti-sysc driver changes for v5.4
From: Arnd Bergmann @ 2019-09-04 15:26 UTC (permalink / raw)
To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1567016893-318461@atomide.com-2>
On Wed, Aug 28, 2019 at 8:35 PM Tony Lindgren <tony@atomide.com> wrote:
> more ti-sysc driver changes for omap variants for v5.4
>
> Few changes mostly to deal with sgx SoC glue quirk for omap36xx that
> is needed for the related sgx SoC glue dts branch. The other changes
> are to simplify sysc_check_one_child() sysc_check_children() to be void
> functions, and detect d2d module when debugging is enabled.
Pulled into arm/late, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 3/4] drop more legacy pdata for omaps for v5.4
From: Arnd Bergmann @ 2019-09-04 15:27 UTC (permalink / raw)
To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1567016893-318461@atomide.com-3>
On Wed, Aug 28, 2019 at 8:35 PM Tony Lindgren <tony@atomide.com> wrote:
> Drop legacy platform data omap variants for v5.4
>
> We can now drop more platform data in favor of dts data for most
> devices like cpsw, gpio, i2c, mmc, uart and watchdog.
>
> In general we can do this by dropping legacy "ti,hwmods" custom dts
> property, and the platform data assuming the related dts data is correct.
> This is best done as single patch as otherwise we'd have to revert two
> patches in case of any unexpected issues, and we're just removing data.
>
> Fro cpsw, before we can do this, we need to configure the cpsw mdio clocks
> properly in dts though in the first patch. For omap4 i2c, we've already
> dropped the platform data earlier, but have been still allocting it
> dynamically based on the dts data based on the "ti,hwmods" property, but
> that is no longer needed. For d2d, we are missing the dts data, so we
> first add it and then drop the platform data.
>
> For dra7, we drop platform data and "ti,hwmods" for mcasp and mcspi.
> We've already dropped platform data earlier for gpio, i2c, mmc, and
> uart so we just need to drop "ti,hwmods" property for those.
>
> Note that this branch is based on earlier ti-sysc-fixes branch.
Pulled into arm/late, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 4/4] sgx soc glue changes for omaps for v5.4
From: Arnd Bergmann @ 2019-09-04 15:27 UTC (permalink / raw)
To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1567016893-318461@atomide.com-4>
On Wed, Aug 28, 2019 at 8:35 PM Tony Lindgren <tony@atomide.com> wrote:
> SoC glue layer changes for SGX on omap variants for v5.4
>
> For a while we've had omap4 sgx glue layer defined in dts and probed
> with ti-sysc driver. This allows idling the sgx module for PM, and
> removes the need for custom platform glue layer code for any further
> driver changes.
>
> We first drop the unused legacy platform data for omap4 sgx. Then for
> omap5, we need add the missing clkctrl clock data so we can configure
> sgx. And we configure sgx for omap34xx, omap36xx and am3517.
>
> For am335x, we still have a dependency for rstctrl reset driver changes,
> so that will be added later on.
>
> Note that this branch is based on earlier ti-sysc branch for omap36xx
> glue layer quirk handling.
Pulled into arm/late, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] ARM: mvebu: dt64 for v5.4 (#2)
From: Arnd Bergmann @ 2019-09-04 15:38 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Andrew Lunn, Jason Cooper, Marek Behún, SoC Team, arm-soc,
Olof Johansson, Linux ARM, Sebastian Hesselbarth
In-Reply-To: <CAK8P3a0BqjtVoTrUedDGHBUv8gwL23XWqYM2831v7G+23i8++A@mail.gmail.com>
On Tue, Sep 3, 2019 at 11:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Sep 3, 2019 at 2:41 PM Gregory CLEMENT
> <gregory.clement@bootlin.com> wrote:
> > Here is the second pull request for dt64 for mvebu for v5.4.
> >
> > For the Turris Mox board there was dependencies with moxtet header which
> > was already merged in your arm/drivers branch. That the reason why I
> > merged this branch in my mvebu/dt64 branch.
> >
> > Let me know if it is a problem and if you want that I do it in a
> > different way.
>
> I don't really like this, but it's too late to do it right now. The problem is
> that I should have not picked up the patches from the list in the first
> place if there are these dependencies.
>
> This could have been communicated better in the patch series, but
> it really my own fault.
>
> > ----------------------------------------------------------------
> > mvebu dt64 for 5.4 (part 2)
> >
> > Add support for Turris Mox board (Armada 3720 SoC based)
> >
> > ----------------------------------------------------------------
> > Marek Behún (3):
> > arm64: dts: marvell: armada-37xx: add SPI CS1 pinctrl
> > dt-bindings: marvell: document Turris Mox compatible
> > arm64: dts: marvell: add DTS for Turris Mox
>
> I think the best way forward would be for me to apply the
> remaining patches on top of the arm/drivers branch, to avoid
> also pulling in your other DT changes into arm/drivers, or pulling
> in all of arm/drivers into arm/dt.
>
> Would that work for you?
I ended up creating an arm/late branch for other reasons, put
this branch in there as well.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] ARM: mvebu: dt64 for v5.4 (#2)
From: Gregory CLEMENT @ 2019-09-04 15:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, Jason Cooper, Marek Behún, SoC Team, arm-soc,
Olof Johansson, Linux ARM, Sebastian Hesselbarth
In-Reply-To: <CAK8P3a0igyBe-MQ9QcVMwCF4sx76MBVwtcsF=nFJf_sgYe2G2A@mail.gmail.com>
Hi Arnd,
> On Tue, Sep 3, 2019 at 11:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Tue, Sep 3, 2019 at 2:41 PM Gregory CLEMENT
>> <gregory.clement@bootlin.com> wrote:
>> > Here is the second pull request for dt64 for mvebu for v5.4.
>> >
>> > For the Turris Mox board there was dependencies with moxtet header which
>> > was already merged in your arm/drivers branch. That the reason why I
>> > merged this branch in my mvebu/dt64 branch.
>> >
>> > Let me know if it is a problem and if you want that I do it in a
>> > different way.
>>
>> I don't really like this, but it's too late to do it right now. The problem is
>> that I should have not picked up the patches from the list in the first
>> place if there are these dependencies.
>>
>> This could have been communicated better in the patch series, but
>> it really my own fault.
>>
>> > ----------------------------------------------------------------
>> > mvebu dt64 for 5.4 (part 2)
>> >
>> > Add support for Turris Mox board (Armada 3720 SoC based)
>> >
>> > ----------------------------------------------------------------
>> > Marek Behún (3):
>> > arm64: dts: marvell: armada-37xx: add SPI CS1 pinctrl
>> > dt-bindings: marvell: document Turris Mox compatible
>> > arm64: dts: marvell: add DTS for Turris Mox
>>
>> I think the best way forward would be for me to apply the
>> remaining patches on top of the arm/drivers branch, to avoid
>> also pulling in your other DT changes into arm/drivers, or pulling
>> in all of arm/drivers into arm/dt.
>>
>> Would that work for you?
>
> I ended up creating an arm/late branch for other reasons, put
> this branch in there as well.
OK thanks!
Gregory
>
> Arnd
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 05/10] KVM: arm64: Support stolen time reporting via shared structure
From: Steven Price @ 2019-09-04 15:53 UTC (permalink / raw)
To: Zenghui Yu, Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm
Cc: kvm, linux-doc, Catalin Marinas, Russell King, linux-kernel,
Paolo Bonzini
In-Reply-To: <d55d091f-1c0f-9c47-b7b2-95c87285335d@huawei.com>
On 03/09/2019 10:14, Zenghui Yu wrote:
> On 2019/8/30 16:42, Steven Price wrote:
>> Implement the service call for configuring a shared structure between a
>> VCPU and the hypervisor in which the hypervisor can write the time
>> stolen from the VCPU's execution time by other tasks on the host.
>>
>> The hypervisor allocates memory which is placed at an IPA chosen by user
>> space.
>
> It seems that no allocation happens in the hypervisor code. User space
> will do it instead?
Ah, yes I should update the commit message. User space does now allocate
the memory. Thanks for spotting that.
Steve
>> The hypervisor then updates the shared structure using
>> kvm_put_guest() to ensure single copy atomicity of the 64-bit value
>> reporting the stolen time in nanoseconds.
>>
>> Whenever stolen time is enabled by the guest, the stolen time counter is
>> reset.
>>
>> The stolen time itself is retrieved from the sched_info structure
>> maintained by the Linux scheduler code. We enable SCHEDSTATS when
>> selecting KVM Kconfig to ensure this value is meaningful.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>
> Thanks,
> zenghui
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] bus: imx-weim: remove incorrect __init annotations
From: Arnd Bergmann @ 2019-09-04 16:00 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer
Cc: Rob Herring, Arnd Bergmann, Sven Van Asbroeck, linux-kernel,
clang-built-linux, NXP Linux Team, Pengutronix Kernel Team,
Fabio Estevam, linux-arm-kernel
The probe function is no longer __init, so anything it calls now
must also be available at runtime, as Kbuild points out when building
with clang-9:
WARNING: vmlinux.o(.text+0x6e7040): Section mismatch in reference from the function weim_probe() to the function .init.text:imx_weim_gpr_setup()
The function weim_probe() references
the function __init imx_weim_gpr_setup().
This is often because weim_probe lacks a __init
annotation or the annotation of imx_weim_gpr_setup is wrong.
WARNING: vmlinux.o(.text+0x6e70f0): Section mismatch in reference from the function weim_probe() to the function .init.text:weim_timing_setup()
The function weim_probe() references
the function __init weim_timing_setup().
This is often because weim_probe lacks a __init
annotation or the annotation of weim_timing_setup is wrong.
Remove the remaining __init markings that are now wrong.
Fixes: 4a92f07816ba ("bus: imx-weim: use module_platform_driver()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I applied this on top of the patch taht introduced the build error
drivers/bus/imx-weim.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index 79af0c27f5a3..28bb65a5613f 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -76,7 +76,7 @@ static const struct of_device_id weim_id_table[] = {
};
MODULE_DEVICE_TABLE(of, weim_id_table);
-static int __init imx_weim_gpr_setup(struct platform_device *pdev)
+static int imx_weim_gpr_setup(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct property *prop;
@@ -126,10 +126,10 @@ static int __init imx_weim_gpr_setup(struct platform_device *pdev)
}
/* Parse and set the timing for this device. */
-static int __init weim_timing_setup(struct device *dev,
- struct device_node *np, void __iomem *base,
- const struct imx_weim_devtype *devtype,
- struct cs_timing_state *ts)
+static int weim_timing_setup(struct device *dev,
+ struct device_node *np, void __iomem *base,
+ const struct imx_weim_devtype *devtype,
+ struct cs_timing_state *ts)
{
u32 cs_idx, value[MAX_CS_REGS_COUNT];
int i, ret;
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 10/10] arm64: Retrieve stolen time as paravirtualized guest
From: Steven Price @ 2019-09-04 16:01 UTC (permalink / raw)
To: Andrew Jones
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190903084703.hwpelmr7fikb32nj@kamzik.brq.redhat.com>
On 03/09/2019 09:47, Andrew Jones wrote:
> On Fri, Aug 30, 2019 at 09:42:55AM +0100, Steven Price wrote:
>> Enable paravirtualization features when running under a hypervisor
>> supporting the PV_TIME_ST hypercall.
>>
>> For each (v)CPU, we ask the hypervisor for the location of a shared
>> page which the hypervisor will use to report stolen time to us. We set
>> pv_time_ops to the stolen time function which simply reads the stolen
>> value from the shared page for a VCPU. We guarantee single-copy
>> atomicity using READ_ONCE which means we can also read the stolen
>> time for another VCPU than the currently running one while it is
>> potentially being updated by the hypervisor.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> arch/arm64/include/asm/paravirt.h | 9 +-
>> arch/arm64/kernel/paravirt.c | 148 ++++++++++++++++++++++++++++++
>> arch/arm64/kernel/time.c | 3 +
>> include/linux/cpuhotplug.h | 1 +
>> 4 files changed, 160 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/paravirt.h b/arch/arm64/include/asm/paravirt.h
>> index 799d9dd6f7cc..125c26c42902 100644
>> --- a/arch/arm64/include/asm/paravirt.h
>> +++ b/arch/arm64/include/asm/paravirt.h
>> @@ -21,6 +21,13 @@ static inline u64 paravirt_steal_clock(int cpu)
>> {
>> return pv_ops.time.steal_clock(cpu);
>> }
>> -#endif
>> +
>> +int __init kvm_guest_init(void);
>> +
>> +#else
>> +
>> +#define kvm_guest_init()
>> +
>> +#endif // CONFIG_PARAVIRT
>>
>> #endif
>> diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
>> index 4cfed91fe256..5bf3be7ccf7e 100644
>> --- a/arch/arm64/kernel/paravirt.c
>> +++ b/arch/arm64/kernel/paravirt.c
>> @@ -6,13 +6,161 @@
>> * Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> */
>>
>> +#define pr_fmt(fmt) "kvmarm-pv: " fmt
>> +
>> +#include <linux/arm-smccc.h>
>> +#include <linux/cpuhotplug.h>
>> #include <linux/export.h>
>> +#include <linux/io.h>
>> #include <linux/jump_label.h>
>> +#include <linux/printk.h>
>> +#include <linux/psci.h>
>> +#include <linux/reboot.h>
>> +#include <linux/slab.h>
>> #include <linux/types.h>
>> +
>> #include <asm/paravirt.h>
>> +#include <asm/pvclock-abi.h>
>> +#include <asm/smp_plat.h>
>>
>> struct static_key paravirt_steal_enabled;
>> struct static_key paravirt_steal_rq_enabled;
>>
>> struct paravirt_patch_template pv_ops;
>> EXPORT_SYMBOL_GPL(pv_ops);
>> +
>> +struct kvmarm_stolen_time_region {
>> + struct pvclock_vcpu_stolen_time *kaddr;
>> +};
>> +
>> +static DEFINE_PER_CPU(struct kvmarm_stolen_time_region, stolen_time_region);
>> +
>> +static bool steal_acc = true;
>> +static int __init parse_no_stealacc(char *arg)
>> +{
>> + steal_acc = false;
>> + return 0;
>> +}
>> +
>> +early_param("no-steal-acc", parse_no_stealacc);
>
> Need to also add an 'ARM64' to the
> Documentation/admin-guide/kernel-parameters.txt entry for this.
Good point, thanks for the pointer.
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 00/10] arm64: Stolen time support
From: Steven Price @ 2019-09-04 16:02 UTC (permalink / raw)
To: Andrew Jones
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190903084921.zikiucdruymfgfsq@kamzik.brq.redhat.com>
On 03/09/2019 09:49, Andrew Jones wrote:
> On Tue, Sep 03, 2019 at 10:03:48AM +0200, Andrew Jones wrote:
>> Hi Steven,
>>
>> I had some fun testing this series with the KVM selftests framework. It
>> looks like it works to me, so you may add
>>
>> Tested-by: Andrew Jones <drjones@redhat.com>
>>
>
> Actually, I probably shouldn't be quite so generous with this tag yet,
> because I haven't yet tested the guest-side changes. To do that I'll
> need to start prototyping something for QEMU. I need to finish some other
> stuff first, but then I can do that.
Thanks for the testing, I'll wait for your other testing before adding
your Tested-by tag.
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] bus: imx-weim: remove incorrect __init annotations
From: Nick Desaulniers @ 2019-09-04 16:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sven Van Asbroeck, Rob Herring, Ilie Halip, Shawn Guo,
Sascha Hauer, LKML, clang-built-linux, NXP Linux Team,
Pengutronix Kernel Team, Nathan Chancellor, Fabio Estevam,
Linux ARM
In-Reply-To: <20190904160039.3350229-1-arnd@arndb.de>
On Wed, Sep 4, 2019 at 9:00 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> The probe function is no longer __init, so anything it calls now
> must also be available at runtime, as Kbuild points out when building
> with clang-9:
Thanks for the patch, this has already been addressed in:
https://patchwork.kernel.org/patch/11114307/
https://github.com/ClangBuiltLinux/linux/issues/645
>
> WARNING: vmlinux.o(.text+0x6e7040): Section mismatch in reference from the function weim_probe() to the function .init.text:imx_weim_gpr_setup()
> The function weim_probe() references
> the function __init imx_weim_gpr_setup().
> This is often because weim_probe lacks a __init
> annotation or the annotation of imx_weim_gpr_setup is wrong.
>
> WARNING: vmlinux.o(.text+0x6e70f0): Section mismatch in reference from the function weim_probe() to the function .init.text:weim_timing_setup()
> The function weim_probe() references
> the function __init weim_timing_setup().
> This is often because weim_probe lacks a __init
> annotation or the annotation of weim_timing_setup is wrong.
>
> Remove the remaining __init markings that are now wrong.
>
> Fixes: 4a92f07816ba ("bus: imx-weim: use module_platform_driver()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> I applied this on top of the patch taht introduced the build error
>
> drivers/bus/imx-weim.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> index 79af0c27f5a3..28bb65a5613f 100644
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -76,7 +76,7 @@ static const struct of_device_id weim_id_table[] = {
> };
> MODULE_DEVICE_TABLE(of, weim_id_table);
>
> -static int __init imx_weim_gpr_setup(struct platform_device *pdev)
> +static int imx_weim_gpr_setup(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> struct property *prop;
> @@ -126,10 +126,10 @@ static int __init imx_weim_gpr_setup(struct platform_device *pdev)
> }
>
> /* Parse and set the timing for this device. */
> -static int __init weim_timing_setup(struct device *dev,
> - struct device_node *np, void __iomem *base,
> - const struct imx_weim_devtype *devtype,
> - struct cs_timing_state *ts)
> +static int weim_timing_setup(struct device *dev,
> + struct device_node *np, void __iomem *base,
> + const struct imx_weim_devtype *devtype,
> + struct cs_timing_state *ts)
> {
> u32 cs_idx, value[MAX_CS_REGS_COUNT];
> int i, ret;
> --
> 2.20.0
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20190904160039.3350229-1-arnd%40arndb.de.
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.
From: Mathieu Poirier @ 2019-09-04 16:05 UTC (permalink / raw)
To: Greg KH
Cc: Jon Corbet, Coresight ML, open list:DOCUMENTATION,
linux-arm-kernel, Suzuki K. Poulose, Mike Leach
In-Reply-To: <20190904054809.GB4511@kroah.com>
On Tue, 3 Sep 2019 at 23:48, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Sep 03, 2019 at 04:51:40PM -0600, Mathieu Poirier wrote:
> > On Tue, 3 Sep 2019 at 13:59, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Thu, Aug 29, 2019 at 10:33:19PM +0100, Mike Leach wrote:
> > > > Update document to include the new sysfs features added during this
> > > > patchset.
> > > >
> > > > Updated to reflect the new sysfs component nameing schema.
> > > >
> > > > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > > > ---
> > > > .../testing/sysfs-bus-coresight-devices-etm4x | 183 +++++++++++-------
> > > > 1 file changed, 115 insertions(+), 68 deletions(-)
> > > >
> > > > diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > index 36258bc1b473..112c50ae9986 100644
> > > > --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > @@ -1,4 +1,4 @@
> > > > -What: /sys/bus/coresight/devices/<memory_map>.etm/enable_source
> > > > +What: /sys/bus/coresight/devices/etm<N>/enable_source
> > >
> > > You are renaming sysfs directories that have been around since:
> > >
> > > > Date: April 2015
> > >
> > > ???
> > >
> > > Really?
> > >
> > > That's brave.
> >
> >
> > When I worked on the coresight sysfs ABI a while back I specifically
> > added it at the "testing" level as I was well aware that things could
> > change in the future. According to the guidelines in the
> > documentation userspace can rely on it which was accurate since the
> > interface didn't change for 4 years. But the guidelines also mention
> > that changes can occur before the interfaces are move to stables, and
> > that programs are encouraged to manifest their interest by adding
> > their name to the "users" field.
> >
> > The interface was changed in 5.2 to support coresight from ACPI and
> > make things easier to understand for users. It is a lot more
> > intuitive to associate an ETM tracer with the CPU it belongs to by
> > referring to the CPU number than the memory mapped address. Given the
> > "testing" status of the interface and the absence of registered users
> > I decided to move forward with the change. If "testing" is too strict
> > for that I suggest to add an "experimental" category where it would be
> > more acceptable to change things as subsystems mature.
>
> "testing" is not really "testing" if you have userspace tools/programs
> assuming the location and contents of specific files in sysfs.
>
> You can change things in sysfs by creating new files, but to do
> wholesale renaming like you did here can be very dangerous as you might
> be breaking things.
Yes, something I have definitely considered.
> Usually new files are created, not existing ones
> moved.
In this case it would have meant a new symbolic link for every
coresight device, so twice a many entries under
$(SYS)/bus/coresight/device/. That would have been a lot of clutter
and an increasing source of problems as the number of CPU and sinks
increases. To me, and given the permissive definition of "testing"
found in the documentation, a clean break was a better option.
>
> What tools use these today? What is going to break?
Other than local shell scripts I am not aware of any tools using these
today. I am certainly open to discuss a better alternative but right
now, I just don't see one.
>
> thanks,
> greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 11/11] coresight: etm4x: docs: Adds detailed document for programming etm4x.
From: Mathieu Poirier @ 2019-09-04 16:09 UTC (permalink / raw)
To: Mike Leach
Cc: Jonathan Corbet, Greg Kroah-Hartman, Coresight ML,
Suzuki K. Poulose, open list:DOCUMENTATION, linux-arm-kernel
In-Reply-To: <CAJ9a7VhM1H+yGWCXw5q4ONELQfPX2Z+dhLqxPJ95CENV3MUarA@mail.gmail.com>
On Tue, 3 Sep 2019 at 16:47, Mike Leach <mike.leach@linaro.org> wrote:
>
> Hi Mathieu,
>
> On Tue, 3 Sep 2019 at 20:38, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >
> > Hi Mike,
> >
> > On Thu, Aug 29, 2019 at 10:33:21PM +0100, Mike Leach wrote:
> > > Add in detailed programmers reference for users wanting to program the
> > > CoreSight ETM 4.x driver using sysfs.
> > >
> > > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > > ---
> > > .../coresight/coresight-etm4x-reference.txt | 458 ++++++++++++++++++
> > > 1 file changed, 458 insertions(+)
> > > create mode 100644 Documentation/trace/coresight/coresight-etm4x-reference.txt
> > >
> > > diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.txt b/Documentation/trace/coresight/coresight-etm4x-reference.txt
> > > new file mode 100644
> > > index 000000000000..f0c370870992
> > > --- /dev/null
> > > +++ b/Documentation/trace/coresight/coresight-etm4x-reference.txt
> > > @@ -0,0 +1,458 @@
> > > +ETMv4 sysfs linux driver programming reference - v2.
> > > +====================================================
> > > +
> > > +Supplement to existing ETMv4 driver documentation.
> > > +
> > > +Sysfs files and directories
> > > +---------------------------
> > > +
> > > +Root: /sys/bus/coresight/devices/etm<N>
> > > +
> > > +
> > > +The following paragraphs explain the association between sysfs files and the
> > > +ETMv4 registers that they effect. Note the register names are given without
> > > +the ‘TRC’ prefix.
> > > +
> > > +File : mode (rw)
> > > +Trace Registers : {CONFIGR + others}
> > > +Notes : Bit select trace features. See ‘mode’ section below. Bits
> > > + in this will cause equivalent programming of trace config and
> > > + other registers to enable the features requested.
> > > +Syntax & eg : 'echo bitfield > mode'
> > > + bitfield up to 32 bits setting trace features.
> > > +Example : $> echo 0x > mode
> >
> > I suspect things look different on your end than they do on mine. The biggest
> > problem is related to multi-line fields. For instance the above looks like this
> > on my side:
> >
> > File : mode (rw)
> > Trace Registers : {CONFIGR + others}
> > Notes : Bit select trace features. See ‘mode’ section below. Bits
> > in this will cause equivalent programming of trace config and
> > other registers to enable the features requested.
> > Syntax & eg : 'echo bitfield > mode'
> > bitfield up to 32 bits setting trace features.
> > Example : $> echo 0x > mode
> >
> > It would be nicer to have multi-line fields aligned with the first line, such
> > as:
> >
> > File : mode (rw)
> > Trace Registers : {CONFIGR + others}
> > Notes : Bit select trace features. See ‘mode’ section below. Bits
> > in this will cause equivalent programming of trace config and
> > other registers to enable the features requested.
> > Syntax & eg : 'echo bitfield > mode'
> > bitfield up to 32 bits setting trace features.
> > Example : $> echo 0x > mode
> >
>
> Problem is I am not seeing any difference between what you say I am
> writing and what you prefer. When i looked at the file in my text
> editor the fields where aligned - I would not have submitted it
> otherwise.
Indeed - I suspected that much.
> I am happy to revisit it but we need a way of seeing a common view.
Agreed
>
>
> > I'm also not sure about the prompt, i.e "$>". I suspect it should be "$" and
> > an additional ">" got inserted.
>
> prompt came from examples lifted from a DB410 session. Don't really
> have any strong preference for what represents a prompt in the docs,
> so happy to change it to anything appropriate.
Ok, I wasn't sure if this was really the prompt you were getting of corruption.
>
> Regards
>
> Mike
>
> >
> > I wanted to read on but is it too difficult to know what is intentional and what
> > isn't. Please address and resend.
> >
> > Thanks,
> > Mathieu
> >
> > > +
> > > +File : reset (wo)
> > > +Trace Registers : All
> > > +Notes : Reset all programming to trace nothing / no logic programmed.
> > > +Syntax : 'echo 1 > reset'
> > > +
> > > +File : enable_source (wo)
> > > +Trace Registers : PRGCTLR, All hardware regs.
> > > +Notes : >0: Programs up the hardware with the current values held in
> > > + the driver and enables trace.
> > > + 0: disable trace hardware.
> > > +Syntax : 'echo 1 > enable_source'
> > > +
> > > +File : cpu (ro)
> > > +Trace Registers : None.
> > > +Notes : CPU ID that this ETM is attached to.
> > > +Example :$> cat cpu
> > > + $> 0
> > > +
> > > +File : addr_idx (rw)
> > > +Trace Registers : None.
> > > +Notes : Virtual register to index address comparator and range
> > > + features. Set index for first of the pair in a range.
> > > +Syntax : 'echo idx > addr_idx'
> > > + Where idx < nr_addr_cmp x 2
> > > +
> > > +File : addr_range (rw)
> > > +Trace Registers : ACVR[idx, idx+1], VIIECTLR
> > > +Notes : Pair of addresses for a range selected by addr_idx. Include
> > > + / exclude according to the optional parameter, or if omitted
> > > + uses the current ‘mode’ setting. Select comparator range in
> > > + control register. Error if index is odd value.
> > > +Depends : mode, addr_idx
> > > +Syntax : 'echo addr1 addr2 [exclude] > addr_range'
> > > + Where addr1 and addr2 define the range and addr1 < addr2.
> > > + Optional exclude value - 0 for include, 1 for exclude.
> > > +Example : $> echo 0x0000 0x2000 0 > addr_range
> > > +
> > > +File : addr_single (rw)
> > > +Trace Registers : ACVR[idx]
> > > +Notes : Set a single address comparator according to addr_idx. This
> > > + is used if the address comparator is used as part of event
> > > + generation logic etc.
> > > +Depends : addr_idx
> > > +Syntax : 'echo addr1 > addr_single'
> > > +
> > > +File : addr_start (rw)
> > > +Trace Registers : ACVR[idx], VISSCTLR
> > > +Notes : Set a trace start address comparator according to addr_idx.
> > > + Select comparator in control register.
> > > +Depends : addr_idx
> > > +Syntax : 'echo addr1 > addr_start'
> > > +
> > > +File : addr_stop (rw)
> > > +Trace Registers : ACVR[idx], VISSCTLR
> > > +Notes : Set a trace stop address comparator according to addr_idx.
> > > + Select comparator in control register.
> > > +Depends : addr_idx
> > > +Syntax : 'echo addr1 > addr_stop'
> > > +
> > > +File : addr_context (rw)
> > > +Trace Registers : ACATR[idx,{6:4}]
> > > +Notes : Link context ID comparator to address comparator addr_idx
> > > +Depends : addr_idx.
> > > +Syntax : 'echo ctxt_idx > addr_context'
> > > + Where ctxt_idx is the index of the linked context id / vmid
> > > + comparator.
> > > +
> > > +File : addr_ctxtype (rw)
> > > +Trace Registers : ACATR[idx,{3:2}]
> > > +Notes : Input value string. Set type for linked context ID comparator
> > > +Depends : addr_idx
> > > +Syntax : 'echo type > addr_ctxtype'
> > > + Type one of {all, vmid, ctxid, none}
> > > +Example : $> echo ctxid > addr_ctxtype
> > > +
> > > +File : addr_exlevel_s_ns (rw)
> > > +Trace Registers : ACATR[idx,{14:8}]
> > > +Notes : Set the ELx secure and non-secure matching bits for the
> > > + selected address comparator
> > > +Depends : addr_idx
> > > +Syntax : 'echo val > addr_exlevel_s_ns'
> > > + val is a 7 bit value for exception levels to exclude. Input
> > > + value shifted to correct bits in register.
> > > +Example : $> echo 0x4F > addr_exlevel_s_ns
> > > +
> > > +File : addr_instdatatype (rw)
> > > +Trace Registers : ACATR[idx,{1:0}]
> > > +Notes : Set the comparator address type for matching. Driver only
> > > + supports setting instruction address type.
> > > +Depends : addr_idx
> > > +
> > > +File : addr_cmp_view (ro)
> > > +Trace Registers : ACVR[idx, idx+1], ACATR[idx], VIIECTLR
> > > +Notes : Read the currently selected address comparator. If part of
> > > + address range then display both addresses.
> > > +Depends : addr_idx
> > > +Syntax : 'cat addr_cmp_view'
> > > +Example : $> cat addr_cmp_view
> > > + addr_cmp[0] range 0x0 0xffffffffffffffff include ctrl(0x4b00)
> > > +
> > > +File : nr_addr_cmp (ro)
> > > +Trace Registers : From IDR4
> > > +Notes : Number of address comparator pairs
> > > +
> > > +File : sshot_idx (rw)
> > > +Trace Registers : None
> > > +Notes : Select single shot register set.
> > > +
> > > +File : sshot_ctrl (rw)
> > > +Trace Registers : SSCCR[idx]
> > > +Notes : Access a single shot comparator control register.
> > > +Depends : sshot_idx
> > > +Syntax : 'echo val > sshot_ctrl'
> > > + Writes val into the selected control register.
> > > +
> > > +File : sshot_status (ro)
> > > +Trace Registers : SSCSR[idx]
> > > +Notes : Read a single shot comparator status register
> > > +Depends : sshot_idx
> > > +Syntax : 'cat sshot_status'
> > > + Read status.
> > > +Example : $> cat sshot_status
> > > + 0x1
> > > +
> > > +File : sshot_pe_ctrl (rw)
> > > +Trace Registers : SSPCICR[idx]
> > > +Notes : Access a single shot PE comparator input control register.
> > > +Depends : sshot_idx
> > > +Syntax : echo val > sshot_pe_ctrl
> > > + Writes val into the selected control register.
> > > +
> > > +File : ns_exlevel_vinst (rw)
> > > +Trace Registers : VICTLR{23:20}
> > > +Notes : Program non-secure exception level filters. Set / clear NS
> > > + exception filter bits. Setting ‘1’ excludes trace from the
> > > + exception level.
> > > +Syntax : 'echo bitfield > ns_exlevel_viinst'
> > > + Where bitfield contains bits to set clear for EL0 to EL2
> > > +Example : %> echo 0x4 > ns_exlevel_viinst
> > > + ; Exclude EL2 NS trace.
> > > +
> > > +File : vinst_pe_cmp_start_stop (rw)
> > > +Trace Registers : VIPCSSCTLR
> > > +Notes : Access PE start stop comparator input control registers
> > > +
> > > +File : bb_ctrl (rw)
> > > +Trace Registers : BBCTLR
> > > +Notes : Define ranges that Branch Broadcast will operate in.
> > > + Default (0x0) is all addresses.
> > > +Depends : BB enabled.
> > > +
> > > +File : cyc_threshold (rw)
> > > +Trace Registers : CCCTLR
> > > +Notes : Set the threshold for which cycle counts will be emitted.
> > > + Error if attempt to set below minimum defined in IDR3, masked
> > > + to width of valid bits.
> > > +Depends : CC enabled.
> > > +
> > > +File : syncfreq (rw)
> > > +Trace Registers : SYNCPR
> > > +Notes : Set trace synchronisation period. Power of 2 value, 0 (off)
> > > + or 8-20. Driver defaults to 12 (every 4096 bytes).
> > > +
> > > +File : cntr_idx (rw)
> > > +Trace Registers : none
> > > +Notes : Select the counter to access
> > > +Syntax : 'echo idx > cntr_idx'
> > > + Where idx < nr_cntr
> > > +
> > > +File : cntr_ctrl (rw)
> > > +Trace Registers : CNTCTLR[idx]
> > > +Notes : Set counter control value
> > > +Depends : cntr_idx
> > > +Syntax : 'echo val > cntr_ctrl'
> > > + Where val is per ETMv4 spec.
> > > +
> > > +File : cntrldvr (rw)
> > > +Trace Registers : CNTRLDVR[idx]
> > > +Notes : Set counter reload value
> > > +Depends : cntr_idx
> > > +Syntax : 'echo val > cntrldvr'
> > > + Where val is per ETMv4 spec.
> > > +
> > > +File : nr_cntr (ro)
> > > +Trace Registers : From IDR5
> > > +Notes : Number of counters implemented.
> > > +
> > > +File : ctxid_idx (rw)
> > > +Trace Registers : None
> > > +Notes : Select the context ID comparator to access
> > > +Syntax : 'echo idx > ctxid_idx'
> > > + Where idx < numcidc
> > > +
> > > +File : ctxid_pid (rw)
> > > +Trace Registers : CIDCVR[idx]
> > > +Notes : Set the context ID comparator value
> > > +Depends : ctxid_idx
> > > +
> > > +File : ctxid_masks (rw)
> > > +Trace Registers : CIDCCTLR0, CIDCCTLR1, CIDCVR<0-7>
> > > +Notes : Pair of values to set the byte masks for 1-8 context ID
> > > + comparators. Automatically clears masked bytes to 0 in CID
> > > + value registers.
> > > +Syntax : 'echo m3m2m1m0 [m7m6m5m4] > ctxid_masks'
> > > + 32 bit values made up of mask bytes, where mN represents a
> > > + byte mask value for Ctxt ID comparator N.
> > > + Second value not required on systems that have fewer than 4
> > > + context ID comparators
> > > +
> > > +File : numcidc (ro)
> > > +Trace Registers : From IDR4
> > > +Notes : Number of Context ID comparators
> > > +
> > > +File : vmid_idx (rw)
> > > +Trace Registers : None
> > > +Notes : Select the VM ID comparator to access.
> > > +Syntax : 'echo idx > vmid_idx'
> > > + Where idx < numvmidc
> > > +
> > > +File : vmid_val (rw)
> > > +Trace Registers : VMIDCVR[idx]
> > > +Notes : Set the VM ID comparator value
> > > +Depends : vmid_idx
> > > +
> > > +File : vmid_masks (rw)
> > > +Trace Registers : VMIDCCTLR0, VMIDCCTLR1, VMIDCVR<0-7>
> > > +Notes : Pair of values to set the byte masks for 1-8 VM ID
> > > + comparators. Automatically clears masked bytes to 0 in VMID
> > > + value registers.
> > > +Syntax : 'echo m3m2m1m0 [m7m6m5m4] > vmid_masks'
> > > + Where mN represents a byte mask value for VMID comparator N.
> > > + Second value not required on systems that have fewer than
> > > + 4 VMID comparators.
> > > +
> > > +File : numvmidc (ro)
> > > +Trace Registers : From IDR4
> > > +Notes : Number of VMID comparators
> > > +
> > > +File : res_idx (rw)
> > > +Trace Registers : None.
> > > +Notes : Select the resource selector control to access. Must be 2 or
> > > + higher as selectors 0 and 1 are hardwired.
> > > +Syntax : 'echo idx > res_idx'
> > > + Where 2 <= idx < nr_resource x 2
> > > +
> > > +File : res_ctrl (rw)
> > > +Trace Registers : RSCTLR[idx]
> > > +Notes : Set resource selector control value. Value per ETMv4 spec.
> > > +Depends : res_idx
> > > +Syntax : 'echo val > res_cntr'
> > > + Where val is per ETMv4 spec.
> > > +
> > > +File : nr_resource (ro)
> > > +Trace Registers : From IDR4
> > > +Notes : Number of resource selector pairs
> > > +
> > > +File : event (rw)
> > > +Trace Registers : EVENTCTRL0R
> > > +Notes : Set up to 4 implemented event fields.
> > > +Syntax : 'echo ev3ev2ev1ev0 > event'
> > > + Where evN is an 8 bit event field. Up to 4 event fields make up
> > > + the 32bit input value. Number of valid fields implementation
> > > + dependent defined in IDR0.
> > > +
> > > +File : event_instren (rw)
> > > +Trace Registers : EVENTCTRL1R
> > > +Notes : Choose events which insert event packets into trace stream.
> > > +Depends : EVENTCTRL0R
> > > +Syntax : 'echo bitfield > event_instren'
> > > + Where bitfield is up to 4 bits according to number of event
> > > + fields.
> > > +
> > > +File : event_ts (rw)
> > > +Trace Registers : TSCTLR
> > > +Notes : Set the event that will generate timestamp requests.
> > > +Depends : TS activated
> > > +Syntax : 'echo evfield > event_ts'
> > > + Where evfield is an 8 bit event selector.
> > > +
> > > +File : seq_idx (rw)
> > > +Trace Registers : None
> > > +Notes : Sequencer event register select - 0 to 2
> > > +
> > > +
> > > +File : seq_state (rw)
> > > +Trace Registers : SEQSTR
> > > +Notes : Sequencer current state - 0 to 3.
> > > +
> > > +File : seq_event (rw)
> > > +Trace Registers : SEQEVR[idx]
> > > +Notes : State transition event registers
> > > +Depends : seq_idx
> > > +Syntax : 'echo evBevF > seq_event'
> > > + Where evBevF is a 16 bit value made up of two event selectors,
> > > + evB - back, evF - forwards.
> > > +
> > > +File : seq_reset_event (rw)
> > > +Trace Registers : SEQRSTEVR
> > > +Notes : Sequencer reset event
> > > +Syntax : 'echo evfield > seq_reset_event'
> > > + Where evfield is an 8 bit event selector.
> > > +
> > > +File : nrseqstate (ro)
> > > +Trace Registers : From IDR5
> > > +Notes : Number of sequencer states (0 or 4)
> > > +
> > > +File : nr_pe_cmp (ro)
> > > +Trace Registers : From IDR4
> > > +Notes : Number of PE comparator inputs
> > > +
> > > +File : nr_ext_inp (ro)
> > > +Trace Registers : From IDR5
> > > +Notes : Number of external inputs
> > > +
> > > +File : nr_ss_cmp (ro)
> > > +Trace Registers : From IDR4
> > > +Notes : Number of Single Shot control registers
> > > +
> > > +Note: When programming any address comparator the driver will tag the
> > > +comparator with a type used - i.e. RANGE, SINGLE, START, STOP. Once this tag
> > > +is set, then only the values can be changed using the same sysfs file / type
> > > +used to program it.
> > > +
> > > +Thus:-
> > > +% echo 0 > addr_idx ; select address comparator 0
> > > +% echo 0x1000 0x5000 0 > addr_range ; set address range on comparators 0 and 1.
> > > +% echo 0x2000 > addr_start ; this will error as comparator 0 is a
> > > + ; range comparator
> > > +% echo 2 > addr_idx ; select address comparator 2
> > > +% echo 0x2000 > addr_start ; this is OK as comparator 2 is unused,
> > > +% echo 0x3000 > addr_stop ; this will error as comparator 2 a start
> > > + ; address comparator
> > > +% echo 2 > addr_idx ; select address comparator 3
> > > +% echo 0x3000 > addr_stop ; this is OK
> > > +
> > > +To remove programming on all the comparators (and all the other hardware) use
> > > +the reset parameter:
> > > +
> > > +% echo 1 > reset
> > > +
> > > +The ‘mode’ sysfs parameter.
> > > +---------------------------
> > > +
> > > +This is a bitfield selection parameter that sets the overall trace mode for the
> > > +ETM. The table below describes the bits, using the defines from the driver
> > > +source file, along with a description of the feature these represent. Many
> > > +features are optional and therefore dependent on implementation in the
> > > +hardware.
> > > +
> > > +Bit assignements shown below:-
> > > +
> > > +bit (0) : #define ETM_MODE_EXCLUDE
> > > +description : This is the default value for the include / exclude function when
> > > + setting address ranges. Set 1 for exclude range. When the mode
> > > + parameter is set this value is applied to the currently indexed
> > > + address range.
> > > +
> > > +bit (4) : #define ETM_MODE_BB
> > > +description : Set to enable branch broadcast if supported in hardware [IDR0].
> > > +
> > > +bit (5) : #define ETMv4_MODE_CYCACC
> > > +description : Set to enable cycle accurate trace if supported [IDR0].
> > > +
> > > +bit (6) : ETMv4_MODE_CTXID
> > > +description : Set to enable context ID tracing if supported in hardware [IDR2].
> > > +
> > > +bit (7) : ETM_MODE_VMID
> > > +description : Set to enable virtual machine ID tracing if supported [IDR2].
> > > +
> > > +bit (11) : ETMv4_MODE_TIMESTAMP
> > > +description : Set to enable timestamp generation if supported [IDR0].
> > > +
> > > +bit (12) : ETM_MODE_RETURNSTACK
> > > +description : Set to enable trace return stack use if supported [IDR0].
> > > +
> > > +bit (13-14) : ETM_MODE_QELEM(val)
> > > +description : ‘val’ determines level of Q element support enabled if
> > > + implemented by the ETM [IDR0]
> > > +
> > > +bit (19) : ETM_MODE_ATB_TRIGGER
> > > +description : Set to enable the ATBTRIGGER bit in the event control register
> > > + [EVENTCTLR1] if supported [IDR5].
> > > +
> > > +bit (20) : ETM_MODE_LPOVERRIDE
> > > +description : Set to enable the LPOVERRIDE bit in the event control register
> > > + [EVENTCTLR1], if supported [IDR5].
> > > +
> > > +bit (21) : ETM_MODE_ISTALL_EN
> > > +description : Set to enable the ISTALL bit in the stall control register
> > > + [STALLCTLR]
> > > +
> > > +bit (23) : ETM_MODE_INSTPRIO
> > > +description : Set to enable the INSTPRIORITY bit in the stall control register
> > > + [STALLCTLR] , if supported [IDR0].
> > > +
> > > +bit (24) : ETM_MODE_NOOVERFLOW
> > > +description : Set to enable the NOOVERFLOW bit in the stall control register
> > > + [STALLCTLR], if supported [IDR3].
> > > +
> > > +bit (25) : ETM_MODE_TRACE_RESET
> > > +description : Set to enable the TRCRESET bit in the viewinst control register
> > > + [VICTLR] , if supported [IDR3].
> > > +
> > > +bit (26) : ETM_MODE_TRACE_ERR
> > > +description : Set to enable the TRCCTRL bit in the viewinst control register
> > > + [VICTLR].
> > > +
> > > +bit (27) : ETM_MODE_VIEWINST_STARTSTOP
> > > +description : Set the initial state value of the ViewInst start / stop logic
> > > + in the viewinst control register [VICTLR]
> > > +
> > > +bit (30) : ETM_MODE_EXCL_KERN
> > > +description : Set default trace setup to exclude kernel mode trace (see note a)
> > > +
> > > +bit (31) : ETM_MODE_EXCL_USER
> > > +description : Set default trace setup to exclude user space trace (see note a)
> > > +
> > > +Note a) On startup the ETM is programmed to trace the complete address space
> > > +using address range comparator 0. ‘mode’ bits 30 / 31 modify this setting to
> > > +set EL exclude bits for NS state in either user space (EL0) or kernel space
> > > +(EL1) in the address range comparator. (the default setting excludes all
> > > +secure EL, and NS EL2)
> > > +
> > > +Once the reset parameter has been used, and/or custom programming has been
> > > +implemented - using these bits will result in the EL bits for address
> > > +comparator 0 being set in the same way.
> > > +
> > > +Note b) Bits 2-3, 8-10, 15-16, 18, 22, control features that only work with
> > > +data trace. As A profile data trace is architecturally prohibited in ETMv4,
> > > +these have been omitted here. Possible uses could be where a kernel has
> > > +support for control of R or M profile infrastructure as part of a heterogeneous
> > > +system.
> > > +
> > > +Bits 17, 28-29 are unused.
> > > --
> > > 2.17.1
> > >
>
>
>
> --
> Mike Leach
> Principal Engineer, ARM Ltd.
> Manchester Design Centre. UK
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/1] arm64: dts: qcom: Add Lenovo Yoga C630
From: Lee Jones @ 2019-09-04 16:12 UTC (permalink / raw)
To: Sudeep Holla
Cc: mark.rutland, devicetree, linux-arm-msm, linux-kernel, robh+dt,
bjorn.andersson, agross, linux-arm-kernel
In-Reply-To: <20190904141257.GB6144@bogus>
On Wed, 04 Sep 2019, Sudeep Holla wrote:
> On Wed, Sep 04, 2019 at 01:16:06PM +0100, Lee Jones wrote:
> > From: Bjorn Andersson <bjorn.andersson@linaro.org>
> >
> > The Lenovo Yoga C630 is built on the SDM850 from Qualcomm, but this seem
> > to be similar enough to the SDM845 that we can reuse the sdm845.dtsi.
> >
> > Supported by this patch is: keyboard, battery monitoring, UFS storage,
> > USB host and Bluetooth.
> >
>
> Just curious to know if the idea of booting using ACPI is completely
> dropped as it's extremely difficult(because the firmware is so hacked
> up and may violate spec, just my opinion) for whatever reasons.
Once [0] is applied, we can boot Mainline using ACPI.
> We just made ACPI table version checking more lenient for this platform
> and would be good to know if we continue to run ACPI on that or will
> abandon and just use DT.
Which patch are you referring to? If you mean the ACPI v5.0 vs v5.1
patch authored by Ard, then yes I know, I instigated it's existence
due to these devices.
DT will *always* be more enabled than ACPI, so it's advised that you
use DT for anything useful. ACPI booting is ideal for things like
installing distros however, since they do not tend to provide DTBs in
their installers.
[0] https://lkml.org/lkml/2019/9/3/580
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 25/36] spi: s3c24xx: use devm_platform_ioremap_resource() to simplify code
From: Mark Brown @ 2019-09-04 16:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: tmaimon77, palmer, tali.perry1, eric, ldewangan, linux-riscv,
festevam, f.fainelli, benjaminfair, shc_work, khilman, openbmc,
YueHaibing, michal.simek, jonathanh, yuenn, wens, agross,
bcm-kernel-feedback-list, linux-imx, linux-arm-msm, linux-tegra,
Andi Shyti, rjui, s.hauer, mripard,
linux-samsung-soc@vger.kernel.org, linux-mediatek,
linux-rpi-kernel, paul.walmsley, matthias.bgg, linux-amlogic,
linux-arm-kernel, baohua, sbranden, yamada.masahiro, avifishman70,
venture, linux-kernel@vger.kernel.org, linux-spi, thierry.reding,
wahrenst, kernel, kgene, shawnguo
In-Reply-To: <CAJKOXPeRtbAvmR-=8Qa8ukGXt-cCj3ud_7y1Z4LgRpX3YCeumg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1366 bytes --]
On Wed, Sep 04, 2019 at 05:09:45PM +0200, Krzysztof Kozlowski wrote:
> On Wed, 4 Sep 2019 at 16:39, Mark Brown <broonie@kernel.org> wrote:
> > I think it's reasonable, it's giving credit to the automated system
> > they've got running coccinelle (which they do mention in their commit
> > logs). It doesn't really hurt anyone and lets people see their system
> > is finding stuff.
> Running internally coccinelle is already credited with commit author.
> The credits are coming with "From:" field.
I guess if other people look at the same CI and send patches as well
then there's some use tying them all together.
> Otherwise for commits I send I could use:
> From: krzk
> ...
> Reported-by: www.krzk.eu
> Signed-off-by: krzk
> To me it is ridiculous.
Sure, on the other hand it doesn't really cost anyone anything if you do
that.
> Different thing is that Reported-by is for fixing bugs or issues.
> There is no bug here. There is no problem solved except making the
> code smaller. That's not what is Reported-by for.
That is true, this one isn't fixing any bug but then the line does get a
bit fuzzy all round with things like warnings and coccinelle output -
even just having the warning pop up is noise for people looking at the
output even if there's no concrete problem. Again I don't see it as
something that's worth getting worked up over.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox