summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-03-24dt-bindings: mmc: synopsys-dw-mshc: fix clock-freq-min-max in exampleJohan Jonker
A test with the command below does not detect all errors in combination with 'additionalProperties: false' and allOf: - $ref: "synopsys-dw-mshc-common.yaml#" allOf: - $ref: "mmc-controller.yaml#" 'additionalProperties' applies to all properties that are not accounted-for by 'properties' or 'patternProperties' in the immediate schema. First when we combine synopsys-dw-mshc.yaml, synopsys-dw-mshc-common.yaml and mmc-controller.yaml it gives this error: Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.example.dt.yaml: mmc@12200000: 'clock-freq-min-max' does not match any of the regexes: '^.*@[0-9]+$', '^clk-phase-(legacy|sd-hs|mmc-(hs|hs[24]00|ddr52)| uhs-(sdr(12|25|50|104)|ddr50))$', 'pinctrl-[0-9]+' 'clock-freq-min-max' is deprecated, so replace it by 'max-frequency'. make ARCH=arm dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20200307160556.16226-1-jbx6244@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24sdhci: tegra: Enable MMC_CAP_WAIT_WHILE_BUSY host capabilitySowjanya Komatineni
Tegra sdhci host supports HW busy detection of the device busy signaling over data0 lane. So, this patch enables host capability MMC_CAP_wAIT_WHILE_BUSY. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Link: https://lore.kernel.org/r/1583941675-9884-2-git-send-email-skomatineni@nvidia.com [Ulf: Lumped together the caps assignments] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24sdhci: tegra: Implement Tegra specific set_timeout callbackSowjanya Komatineni
Tegra host supports HW busy detection and timeouts based on the count programmed in SDHCI_TIMEOUT_CONTROL register and max busy timeout it supports is 11s in finite busy wait mode. Some operations like SLEEP_AWAKE, ERASE and flush cache through SWITCH commands take longer than 11s and Tegra host supports infinite HW busy wait mode where HW waits forever till the card is busy without HW timeout. This patch implements Tegra specific set_timeout sdhci_ops to allow switching between finite and infinite HW busy detection wait modes based on the device command expected operation time. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1583941675-9884-1-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-omap: Add Support for Suspend/ResumeFaiz Abbas
Add power management ops which save and restore the driver context and facilitate a system suspend and resume. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Link: https://lore.kernel.org/r/20200305151228.24692-1-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: renesas_sdhi: simplify execute_tuningWolfram Sang
After refactoring, 'ret' variable is superfluous. Remove it. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20200213163715.8212-1-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: renesas_sdhi: Use BITS_PER_LONG helperGeert Uytterhoeven
Use the existing BITS_PER_LONG helper definition instead of calculating this value. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20200302093534.9055-1-geert+renesas@glider.be Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: cqhci: Update cqhci memory ioresource nameVeerabhadrarao Badiganti
Update cqhci memory ioresource name from cqhci_mem to cqhci since suffix _mem is redundant. Only sdhci-msm driver is making use of this resource as of now. No other vendor's driver is using it. So this update shouldn't affect any other vendor's cqhci functionality. Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1583328320-9981-1-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-msm: Deactivate CQE during SDHC resetVeerabhadrarao Badiganti
When SDHC gets reset (E.g. in runtime suspend path), CQE also gets reset and goes to disable state. But s/w state still points it as CQE is in enabled state. Since s/w and h/w states goes out of sync, it results in s/w request timeout for subsequent CQE requests. To synchronize CQE s/w and h/w state during SDHC reset, explicitly deactivate CQE just before SDHC reset. Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1583503724-13943-3-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: cqhci: Add cqhci_deactivate()Adrian Hunter
Host controllers can reset CQHCI either directly or as a consequence of host controller reset. Add cqhci_deactivate() which puts the CQHCI driver into a state that is consistent with that. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Link: https://lore.kernel.org/r/1583503724-13943-2-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: Replace zero-length array with flexible-array memberGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200226223125.GA20630@embeddedor Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24perf cpumap: Fix snprintf overflow checkChristophe JAILLET
'snprintf' returns the number of characters which would be generated for the given input. If the returned value is *greater than* or equal to the buffer size, it means that the output has been truncated. Fix the overflow test accordingly. Fixes: 7780c25bae59f ("perf tools: Allow ability to map cpus to nodes easily") Fixes: 92a7e1278005b ("perf cpumap: Add cpu__max_present_cpu()") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Suggested-by: David Laight <David.Laight@ACULAB.COM> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Don Zickus <dzickus@redhat.com> Cc: He Zhe <zhe.he@windriver.com> Cc: Jan Stancek <jstancek@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: kernel-janitors@vger.kernel.org Link: http://lore.kernel.org/lkml/20200324070319.10901-1-christophe.jaillet@wanadoo.fr Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24perf test: Test pmu-events aliasesJohn Garry
Add creating event aliases to the pmu-events test. So currently we verify that the generated pmu-events.c is as expected for some test events. Now test that we generate aliases as expected for those events during normal operation. For that, we cycle through each HW PMU in the system, and use the test events to create aliases, and verify those against known, expected values. For core PMUs, we should create an alias for every event in test_cpu_events[]. However, for uncore PMUs, they need to be matched by the pmu_event.pmu member, so use test_uncore_events[]; so check the match beforehand with pmu_uncore_alias_match(). A sample run is as follows for my x86 machine: john@linux-3c19:~/linux> tools/perf/perf test -vv 10 10: PMU events : --- start --- ... testing PMU uncore_arb aliases: no events to match testing PMU cstate_pkg aliases: no events to match skipping testing PMU breakpoint testing aliases PMU uncore_cbox_1: matched event unc_cbo_xsnp_response.miss_eviction testing PMU uncore_cbox_1 aliases: pass testing PMU power aliases: no events to match testing aliases PMU cpu: matched event bp_l1_btb_correct testing aliases PMU cpu: matched event bp_l2_btb_correct testing aliases PMU cpu: matched event segment_reg_loads.any testing aliases PMU cpu: matched event dispatch_blocked.any testing aliases PMU cpu: matched event eist_trans testing PMU cpu aliases: pass testing PMU intel_pt aliases: no events to match skipping testing PMU software skipping testing PMU intel_bts testing PMU uncore_imc aliases: no events to match testing aliases PMU uncore_cbox_0: matched event unc_cbo_xsnp_response.miss_eviction testing PMU uncore_cbox_0 aliases: pass testing PMU cstate_core aliases: no events to match skipping testing PMU tracepoint testing PMU msr aliases: no events to match test child finished with 0 Signed-off-by: John Garry <john.garry@huawei.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: James Clark <james.clark@arm.com> Cc: Joakim Zhang <qiangqing.zhang@nxp.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Cc: linuxarm@huawei.com Link: http://lore.kernel.org/lkml/1584442939-8911-8-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24perf pmu: Make pmu_uncore_alias_match() publicJohn Garry
The perf pmu-events test will want to use pmu_uncore_alias_match(), so make it public. Signed-off-by: John Garry <john.garry@huawei.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: James Clark <james.clark@arm.com> Cc: Joakim Zhang <qiangqing.zhang@nxp.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Cc: linuxarm@huawei.com Link: http://lore.kernel.org/lkml/1584442939-8911-7-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24perf pmu: Add is_pmu_core()John Garry
Add a function to decide whether a PMU is a core PMU. Signed-off-by: John Garry <john.garry@huawei.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: James Clark <james.clark@arm.com> Cc: Joakim Zhang <qiangqing.zhang@nxp.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Cc: linuxarm@huawei.com Link: http://lore.kernel.org/lkml/1584442939-8911-6-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24perf test: Add pmu-events testJohn Garry
The initial test will verify that the test tables in generated pmu-events.c match against known, expected values. For known events added in pmu-events/arch/test, we need to add an entry in test_cpu_aliases_events[] or test_uncore_events[]. A sample run is as follows for x86: john@linux-3c19:~/linux> tools/perf/perf test -vv 10 10: PMU event aliases : --- start --- test child forked, pid 5316 testing event table bp_l1_btb_correct: pass testing event table bp_l2_btb_correct: pass testing event table segment_reg_loads.any: pass testing event table dispatch_blocked.any: pass testing event table eist_trans: pass testing event table uncore_hisi_ddrc.flux_wcmd: pass testing event table unc_cbo_xsnp_response.miss_eviction: pass test child finished with 0 ---- end ---- PMU event aliases: Ok Signed-off-by: John Garry <john.garry@huawei.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: James Clark <james.clark@arm.com> Cc: Joakim Zhang <qiangqing.zhang@nxp.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Cc: linuxarm@huawei.com [ Fixup test_cpu_events[] and test_uncore_events[] sentinels to initialize one of its members to NULL, fixing the build in older compilers ] Link: http://lore.kernel.org/lkml/1584442939-8911-5-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24perf pmu: Refactor pmu_add_cpu_aliases()John Garry
Create pmu_add_cpu_aliases_map() from pmu_add_cpu_aliases(), so the caller can pass the map; the pmu-events test would use this since there would be no CPUID matching to a mapfile there. Signed-off-by: John Garry <john.garry@huawei.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: James Clark <james.clark@arm.com> Cc: Joakim Zhang <qiangqing.zhang@nxp.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Cc: linuxarm@huawei.com Link: http://lore.kernel.org/lkml/1584442939-8911-4-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24perf jevents: Support test events folderJohn Garry
With the goal of supporting pmu-events test case, introduce support for a test events folder. These test events can be used for testing generation of pmu-event tables and alias creation for any arch. When running the pmu-events test case, these test events will be used as the platform-agnostic events, so aliases can be created per-PMU and validated against known expected values. To support the test events, add a "testcpu" entry in pmu_events_map[]. The pmu-events test will be able to lookup the events map for "testcpu", to verify the generated tables against expected values. The resultant generated pmu-events.c will now look like the following: struct pmu_event pme_ampere_emag[] = { { .name = "ldrex_spec", .event = "event=0x6c", .desc = "Exclusive operation spe...", .topic = "intrinsic", .long_desc = "Exclusive operation ...", }, ... }; struct pmu_event pme_test_cpu[] = { { .name = "uncore_hisi_ddrc.flux_wcmd", .event = "event=0x2", .desc = "DDRC write commands. Unit: hisi_sccl,ddrc ", .topic = "uncore", .long_desc = "DDRC write commands", .pmu = "hisi_sccl,ddrc", }, { .name = "unc_cbo_xsnp_response.miss_eviction", .event = "umask=0x81,event=0x22", .desc = "Unit: uncore_cbox A cross-core snoop resulted ...", .topic = "uncore", .long_desc = "A cross-core snoop resulted from L3 ...", .pmu = "uncore_cbox", }, { .name = "eist_trans", .event = "umask=0x0,period=200000,event=0x3a", .desc = "Number of Enhanced Intel SpeedStep(R) ...", .topic = "other", }, { .name = 0, }, }; struct pmu_events_map pmu_events_map[] = { ... { .cpuid = "0x00000000500f0000", .version = "v1", .type = "core", .table = pme_ampere_emag }, ... { .cpuid = "testcpu", .version = "v1", .type = "core", .table = pme_test_cpu, }, { .cpuid = 0, .version = 0, .type = 0, .table = 0, }, }; Signed-off-by: John Garry <john.garry@huawei.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: James Clark <james.clark@arm.com> Cc: Joakim Zhang <qiangqing.zhang@nxp.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Cc: linuxarm@huawei.com Link: http://lore.kernel.org/lkml/1584442939-8911-3-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24perf jevents: Add some test eventsJohn Garry
Add some test PMU events. The events are randomly chosen from x86 and arm64 JSONs. The events include CPU and uncore events. Signed-off-by: John Garry <john.garry@huawei.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: James Clark <james.clark@arm.com> Cc: Joakim Zhang <qiangqing.zhang@nxp.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Cc: linuxarm@huawei.com Link: http://lore.kernel.org/lkml/1584442939-8911-2-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24perf tools: Unify a bit the build directory outputJiri Olsa
Removing the extra 'SUBDIR' line from clean and doc build output. Because it's annoying.. ;-) Before: $ make clean ... SUBDIR Documentation CLEAN Documentation After: $ make clean ... CLEAN Documentation Before: $ make doc BUILD: Doing 'make -j8' parallel build SUBDIR Documentation ASCIIDOC perf-stat.html ... After: $ make doc BUILD: Doing 'make -j8' parallel build ASCIIDOC perf-stat.html ... Signed-off-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20200318204522.1200981-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24tools headers uapi: Update linux/in.h copyArnaldo Carvalho de Melo
To get the changes in: 267762538705 ("seg6: fix SRv6 L2 tunnels to use IANA-assigned protocol number") That ends up automatically adding the new IPPROTO_ETHERNET to the socket args beautifiers: $ tools/perf/trace/beauty/socket_ipproto.sh > before Apply this patch: $ tools/perf/trace/beauty/socket_ipproto.sh > after $ diff -u before after --- before 2020-03-19 11:48:36.876673819 -0300 +++ after 2020-03-19 11:49:00.148541377 -0300 @@ -6,6 +6,7 @@ [132] = "SCTP", [136] = "UDPLITE", [137] = "MPLS", + [143] = "ETHERNET", [17] = "UDP", [1] = "ICMP", [22] = "IDP", $ Addresses this tools/perf build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/in.h' differs from latest version at 'include/uapi/linux/in.h' diff -u tools/include/uapi/linux/in.h include/uapi/linux/in.h Cc: David S. Miller <davem@davemloft.net> Cc: Paolo Lungaroni <paolo.lungaroni@cnit.it> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24perf vendor events amd: Update Zen1 events to V2Vijay Thakkar
This patch updates the PMCs for AMD Zen1 core based processors (Family 17h; Models 0 through 2F) to be in accordance with PMCs as documented in the latest versions of the AMD Processor Programming Reference [1], [2] and [3]. Note that some events, such as FPU pipe assignment are missing in [1], and therefore [3] is included for full coverage of events. PMCs added: fpu_pipe_assignment.dual{0|1|2|3} fpu_pipe_assignment.total{0|1|2|3} ls_mab_alloc.dc_prefetcher ls_mab_alloc.stores ls_mab_alloc.loads bp_dyn_ind_pred bp_de_redirect PMC removed: ex_ret_cond_misp Cumulative counts, fpu_pipe_assignment.total and fpu_pipe_assignment.dual, existed in v1, but did expose port-level counters. ex_ret_cond_misp has been removed as it has been removed from the latest versions of the PPR, and when tested, always seems to sample zero as tested on a Ryzen 3400G system. [1]: Processor Programming Reference (PPR) for AMD Family 17h Models 01h,08h, Revision B2 Processors, 54945 Rev 3.03 - Jun 14, 2019. [2]: Processor Programming Reference (PPR) for AMD Family 17h Model 18h, Revision B1 Processors, 55570-B1 Rev 3.14 - Sep 26, 2019. [3]: OSRR for AMD Family 17h processors, Models 00h-2Fh, 56255 Rev 3.03 - July, 2018 All of the PPRs can be found at: https://bugzilla.kernel.org/show_bug.cgi?id=206537 Signed-off-by: Vijay Thakkar <vijaythakkar@me.com> Acked-by: Kim Phillips <kim.phillips@amd.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Jon Grimm <jon.grimm@amd.com> Cc: Martin Liška <mliska@suse.cz> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: vijay thakkar <vijaythakkar@me.com> Link: http://lore.kernel.org/lkml/20200318190002.307290-4-vijaythakkar@me.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24perf vendor events amd: Add Zen2 eventsVijay Thakkar
This patch adds PMU events for AMD Zen2 core based processors, namely, Matisse (model 71h), Castle Peak (model 31h) and Rome (model 2xh), as documented in the AMD Processor Programming Reference for Matisse [1]. The model number regex has been set to detect all the models under family 17 that do not match those of Zen1, as the range is larger for zen2. Zen2 adds some additional counters that are not present in Zen1 and events for them have been added in this patch. Some counters have also been removed for Zen2 thatwere previously present in Zen1 and have been confirmed to always sample zero on zen2. These added/removed counters have been omitted for brevity but can be found here: https://gist.github.com/thakkarV/5b12ca5fd7488eb2c42e451e40bdd5f3 Note that PPR for Zen2 [1] does not include some counters that were documented in the PPR for Zen1 based processors [2]. After having tested these counters, some of them that still work for zen2 systems have been preserved in the events for zen2. The counters that are omitted in [1] but are still measurable and non-zero on zen2 (tested on a Ryzen 3900X system) are the following: PMC 0x000 fpu_pipe_assignment.{total|total0|total1|total2|total3} PMC 0x004 fp_num_mov_elim_scal_op.* PMC 0x046 ls_tablewalker.* PMC 0x062 l2_latency.l2_cycles_waiting_on_fills PMC 0x063 l2_wcb_req.* PMC 0x06D l2_fill_pending.l2_fill_busy PMC 0x080 ic_fw32 PMC 0x081 ic_fw32_miss PMC 0x086 bp_snp_re_sync PMC 0x087 ic_fetch_stall.* PMC 0x08C ic_cache_inval.* PMC 0x099 bp_tlb_rel PMC 0x0C7 ex_ret_brn_resync PMC 0x28A ic_oc_mode_switch.* L3PMC 0x001 l3_request_g1.* L3PMC 0x006 l3_comb_clstr_state.* [1]: Processor Programming Reference (PPR) for AMD Family 17h Model 71h, Revision B0 Processors, 56176 Rev 3.06 - Jul 17, 2019 [2]: Processor Programming Reference (PPR) for AMD Family 17h Models 01h,08h, Revision B2 Processors, 54945 Rev 3.03 - Jun 14, 2019 All of the PPRs can be found at: https://bugzilla.kernel.org/show_bug.cgi?id=206537 Here are the results of running "fpu_pipe_assignment.total" events on my Ryzen 3900X family 17h model 71h system: Before this patch: $> perf list *fpu_pipe_assignment* List of pre-defined events (to be used in -e): After: $> perf list *fpu_pipe_assignment* floating point: fpu_pipe_assignment.total [Total number of fp uOps] fpu_pipe_assignment.total0 [Total number uOps assigned to pipe 0] fpu_pipe_assignment.total1 [Total number uOps assigned to pipe 1] fpu_pipe_assignment.total2 [Total number uOps assigned to pipe 2] fpu_pipe_assignment.total3 [Total number uOps assigned to pipe 3] Metric Groups: $> perf stat -e fpu_pipe_assignment.total sleep 1 Performance counter stats for 'sleep 1': 25,883 fpu_pipe_assignment.total 1.004145868 seconds time elapsed 0.001805000 seconds user 0.000000000 seconds sys Usage tests while running Linpackin the background: $> perf stat -I1000 -e fpu_pipe_assignment.total 1.000266796 79,313,191,516 fpu_pipe_assignment.total 2.000809630 68,091,474,430 fpu_pipe_assignment.total 3.001028115 52,925,023,174 fpu_pipe_assignment.total $> perf record -e fpu_pipe_assignment.total,fpu_pipe_assignment.total0 -a sleep 1 [ perf record: Woken up 9 times to write data ] [ perf record: Captured and wrote 4.031 MB perf.data (64764 samples) ] $> perf report --stdio --no-header | head -30 98.33% xhpl xhpl [.] dgemm_kernel 0.28% xhpl xhpl [.] dtrsm_kernel_LT 0.10% xhpl [kernel.kallsyms] [k] entry_SYSCALL_64 0.08% xhpl xhpl [.] idamax_k 0.07% baloo_file_extr liblmdb.so [.] mdb_mid2l_insert 0.06% xhpl xhpl [.] dgemm_itcopy 0.06% xhpl xhpl [.] dgemm_oncopy 0.06% xhpl [kernel.kallsyms] [k] __schedule 0.06% xhpl [kernel.kallsyms] [k] syscall_trace_enter 0.06% xhpl [kernel.kallsyms] [k] native_sched_clock 0.06% xhpl [kernel.kallsyms] [k] pick_next_task_fair 0.05% xhpl xhpl [.] blas_thread_server.llvm.15009391670273914865 0.04% xhpl [kernel.kallsyms] [k] do_syscall_64 0.04% xhpl [kernel.kallsyms] [k] yield_task_fair 0.04% xhpl libpthread-2.31.so [.] __pthread_mutex_unlock_usercnt 0.03% xhpl [kernel.kallsyms] [k] cpuacct_charge 0.03% xhpl [kernel.kallsyms] [k] syscall_return_via_sysret 0.03% xhpl libc-2.31.so [.] __sched_yield 0.03% xhpl [kernel.kallsyms] [k] __calc_delta $> perf annotate --stdio2 dgemm_kernel | egrep '^ {0,2}[0-9]+' -B2 -A2 sub $0x60,%rsp mov %rbx,(%rsp) 0.00 mov %rbp,0x8(%rsp) mov %r12,0x10(%rsp) 0.00 mov %r13,0x18(%rsp) mov %r14,0x20(%rsp) mov %r15,0x28(%rsp) -- mov %rdi,%r13 mov %rsi,0x28(%rsp) 0.00 mov %rdx,%r12 vmovsd %xmm0,0x30(%rsp) shl $0x3,%r10 mov 0x28(%rsp),%rax 0.00 xor %rdx,%rdx mov $0x18,%rdi div %rdi -- nop a0: mov %r12,%rax 0.00 shl $0x3,%rax mov %r8,%rdi lea (%r8,%rax,8),%r15 -- mov %r12,%rax nop 0.00 c0: vmovups (%rdi),%ymm1 0.09 vmovups 0x20(%rdi),%ymm2 0.02 vmovups (%r15),%ymm3 0.10 vmovups %ymm1,(%rsi) 0.07 vmovups %ymm2,0x20(%rsi) 0.07 vmovups %ymm3,0x40(%rsi) 0.06 add $0x40,%rdi add $0x40,%r15 add $0x60,%rsi 0.00 dec %rax ↑ jne c0 mov %r9,%r15 -- nop 110: lea 0x80(%rsp),%rsi 0.01 add $0x60,%rsi 0.03 mov %r12,%rax 0.00 sar $0x3,%rax cmp $0x2,%rax ↓ jl d26 prefetcht0 0x200(%rdi) 0.01 vmovups -0x60(%rsi),%ymm1 0.02 prefetcht0 0xa0(%rsi) 0.00 vbroadcastsd -0x80(%rdi),%ymm0 0.00 prefetcht0 0xe0(%rsi) 0.03 vmovups -0x40(%rsi),%ymm2 0.00 prefetcht0 0x120(%rsi) vmovups -0x20(%rsi),%ymm3 vmulpd %ymm0,%ymm1,%ymm4 0.01 prefetcht0 0x160(%rsi) vmulpd %ymm0,%ymm2,%ymm8 0.01 vmulpd %ymm0,%ymm3,%ymm12 0.02 prefetcht0 0x1a0(%rsi) 0.01 vbroadcastsd -0x78(%rdi),%ymm0 vmulpd %ymm0,%ymm1,%ymm5 0.01 vmulpd %ymm0,%ymm2,%ymm9 vmulpd %ymm0,%ymm3,%ymm13 0.01 vbroadcastsd -0x70(%rdi),%ymm0 vmulpd %ymm0,%ymm1,%ymm6 0.00 vmulpd %ymm0,%ymm2,%ymm10 0.00 add $0x60,%rsi ... snip ... nop 65e0: vmovddup -0x60(%rsi),%xmm2 0.00 vmovups -0x80(%rdi),%xmm0 vmovups -0x70(%rdi),%xmm1 0.00 vmovddup -0x58(%rsi),%xmm3 vfmadd231pd %xmm0,%xmm2,%xmm4 0.00 vfmadd231pd %xmm1,%xmm2,%xmm5 0.00 vfmadd231pd %xmm0,%xmm3,%xmm6 0.00 vfmadd231pd %xmm1,%xmm3,%xmm7 0.00 add $0x10,%rsi add $0x20,%rdi 0.00 dec %rax ↑ jne 65e0 nop nop 6620: vmovddup 0x30(%rsp),%xmm0 0.00 vmulpd %xmm0,%xmm4,%xmm4 0.00 vmulpd %xmm0,%xmm5,%xmm5 vmulpd %xmm0,%xmm6,%xmm6 vmulpd %xmm0,%xmm7,%xmm7 vaddpd (%r15),%xmm4,%xmm4 vaddpd 0x10(%r15),%xmm5,%xmm5 0.00 vaddpd (%r15,%r10,1),%xmm6,%xmm6 0.00 vaddpd 0x10(%r15,%r10,1),%xmm7,%xmm7 0.00 vmovups %xmm4,(%r15) vmovups %xmm5,0x10(%r15) 0.00 vmovups %xmm6,(%r15,%r10,1) vmovups %xmm7,0x10(%r15,%r10,1) add $0x20,%r15 -- lea (%r8,%rax,8),%r8 69d8: mov 0x20(%rsp),%r14 0.00 test $0x1,%r14 ↓ je 6d84 mov %r9,%r15 -- vbroadcastsd -0x28(%rsi),%ymm3 vfmadd231pd (%rdi),%ymm0,%ymm4 0.00 vfmadd231pd 0x20(%rdi),%ymm1,%ymm5 vfmadd231pd 0x40(%rdi),%ymm2,%ymm6 vfmadd231pd 0x60(%rdi),%ymm3,%ymm7 -- vmulpd %ymm0,%ymm4,%ymm4 vaddpd (%r15),%ymm4,%ymm4 0.00 vmovups %ymm4,(%r15) add $0x20,%r15 dec %r11 -- mov %rbx,%rsp mov (%rsp),%rbx 0.01 mov 0x8(%rsp),%rbp mov 0x10(%rsp),%r12 mov 0x18(%rsp),%r13 Signed-off-by: Vijay Thakkar <vijaythakkar@me.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Acked-by: Kim Phillips <kim.phillips@amd.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Jon Grimm <jon.grimm@amd.com> Cc: Martin Liška <mliska@suse.cz> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20200318190002.307290-3-vijaythakkar@me.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24perf vendor events amd: Restrict model detection for zen1 based processorsVijay Thakkar
This patch changes the previous blanket detection of AMD Family 17h processors to be more specific to Zen1 core based products only by replacing model detection regex pattern [[:xdigit:]]+ with ([12][0-9A-F]|[0-9A-F]), restricting to models 0 though 2f only. This change is required to allow for the addition of separate PMU events for Zen2 core based models in the following patches as those belong to family 17h but have different PMCs. Current PMU events directory has also been renamed to "amdzen1" from "amdfam17h" to reflect this specificity. Note that although this change does not break PMU counters for existing zen1 based systems, it does disable the current set of counters for zen2 based systems. Counters for zen2 have been added in the following patches in this patchset. Signed-off-by: Vijay Thakkar <vijaythakkar@me.com> Acked-by: Kim Phillips <kim.phillips@amd.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Jon Grimm <jon.grimm@amd.com> Cc: Martin Liška <mliska@suse.cz> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20200318190002.307290-2-vijaythakkar@me.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-03-24mmc: mmc_test: Pass different sg lists for non-blocking requestsVeerabhadrarao Badiganti
Supply a separate sg list for each of the request in non-blocking IO test cases where two requests will be issued at same time. Otherwise, sg memory may get unmapped when a request is done while same memory is being accessed by controller from the other request, and it leads to iommu errors with below call stack: __arm_lpae_unmap+0x2e0/0x478 arm_lpae_unmap+0x54/0x70 arm_smmu_unmap+0x64/0xa4 __iommu_unmap+0xb8/0x1f0 iommu_unmap_fast+0x38/0x48 __iommu_dma_unmap+0x88/0x108 iommu_dma_unmap_sg+0x90/0xa4 sdhci_post_req+0x5c/0x78 mmc_test_start_areq+0x10c/0x120 [mmc_test] mmc_test_area_io_seq+0x150/0x264 [mmc_test] mmc_test_rw_multiple+0x174/0x1c0 [mmc_test] mmc_test_rw_multiple_sg_len+0x44/0x6c [mmc_test] mmc_test_profile_sglen_wr_nonblock_perf+0x6c/0x94 [mmc_test] mtf_test_write+0x238/0x3cc [mmc_test] Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1582714668-17247-1-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24dt-bindings: mmc: sdhci-msm: Add CQE reg mapVeerabhadrarao Badiganti
CQE feature has been enabled on sdhci-msm. Add CQE reg map and reg names that need to be supplied for supporting CQE feature. Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1582545470-11530-1-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-sprd: Set the missing MMC_CAP_WAIT_WHILE_BUSY flagBaolin Wang
The Spreadtrum host controller supports HW busy detection for commands with R1B responses, but also for I/O operations. This means when the host gets a transfer complete event, that always indicates the busy signal is released. Let's inform the mmc core about this, via setting the corresponding MMC_CAP_WAIT_WHILE_BUSY flag, as to remove some redundant software busy polling. Signed-off-by: Baolin Wang <baolin.wang7@gmail.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/96f16647f6a6e8cb058c44e46c61b122df027059.1582535202.git.baolin.wang7@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: core: Fix indentationJérôme Pouiller
sdio_single_irq_set() was indented with a mix of tabs and spaces. Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://lore.kernel.org/r/20200221163147.608677-1-Jerome.Pouiller@silabs.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-esdhc-imx: restore pin state when resume backHaibo Chen
In some low power mode, SoC will lose the pin state, so need to restore the pin state when resume back. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Link: https://lore.kernel.org/r/1582100757-20683-8-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-esdhc-imx: clear DMA_SEL when disable DMA modeHaibo Chen
Currently, when use standard tuning, driver default disable DMA just before send tuning command. But on i.MX8 usdhc, this is not enough. Need also clear DMA_SEL. If not, once the DMA_SEL select AMDA2 before, even dma already disabled, when send tuning command, usdhc will still prefetch the ADMA script from wrong DMA address, then we will see IOMMU report some error which show lack of TLB mapping. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1582100757-20683-7-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-esdhc-imx: clear pending interrupt and halt cqhciHaibo Chen
On i.MX8MM, we are running Dual Linux OS, with 1st Linux using SD Card as rootfs storage, 2nd Linux using eMMC as rootfs storage. We let the the 1st linux configure power/clock for the 2nd Linux. When the 2nd Linux is booting into rootfs stage, we let the 1st Linux to destroy the 2nd linux, then restart the 2nd linux, we met SDHCI dump as following, after we clear the pending interrupt and halt CQCTL, issue gone. [ 1.334594] mmc2: Got command interrupt 0x00000001 even though no command operation was in progress. [ 1.334595] mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== [ 1.334599] mmc2: sdhci: Sys addr: 0xa05dcc00 | Version: 0x00000002 [ 1.345538] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000000 [ 1.345541] mmc2: sdhci: Argument: 0x00018000 | Trn mode: 0x00000033 [ 1.345543] mmc2: sdhci: Present: 0x01f88008 | Host ctl: 0x00000031 [ 1.345547] mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080 [ 1.357903] mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x0000003f [ 1.357905] mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00000000 [ 1.357908] mmc2: sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b [ 1.357911] mmc2: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000502 [ 1.370268] mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x0000b400 [ 1.370270] mmc2: sdhci: Cmd: 0x00000d1a | Max curr: 0x00ffffff [ 1.370273] mmc2: sdhci: Resp[0]: 0x00000b00 | Resp[1]: 0xffffffff [ 1.370276] mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d00f00 [ 1.382132] mmc2: sdhci: Host ctl2: 0x00000000 [ 1.382135] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xa2040208 [ 2.060932] mmc2: Unexpected interrupt 0x00004000. [ 2.065538] mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== [ 2.071720] mmc2: sdhci: Sys addr: 0x00000000 | Version: 0x00000002 [ 2.077902] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000001 [ 2.084083] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000 [ 2.090264] mmc2: sdhci: Present: 0x01f88009 | Host ctl: 0x00000011 [ 2.096446] mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080 [ 2.102627] mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x000010ff [ 2.108809] mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00004000 [ 2.114990] mmc2: sdhci: Int enab: 0x007f1003 | Sig enab: 0x007f1003 [ 2.121171] mmc2: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000502 [ 2.127353] mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x0000b400 [ 2.133534] mmc2: sdhci: Cmd: 0x0000371a | Max curr: 0x00ffffff [ 2.139715] mmc2: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff [ 2.145896] mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d00f00 [ 2.152077] mmc2: sdhci: Host ctl2: 0x00000000 [ 2.156342] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000 Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1582100757-20683-6-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-esdhc-imx: Add an new esdhc_soc_data for i.MX8MMHaibo Chen
Add new esdhc_soc_data, with compatible string "fsl,imx8mm-usdhc". Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1582100757-20683-5-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-esdhc-imx: add flag ESDHC_FLAG_BROKEN_AUTO_CMD23Haibo Chen
Since L4.15, community involve the commit 105819c8a545 ("mmc: core: use mrq->sbc when sending CMD23 for RPMB"), let the usdhc to decide whether to use ACMD23 for RPMB. This CMD23 for RPMB need to set the bit 31 to its argument, if not, the RPMB write operation will return general fail. According to the sdhci logic, SDMA mode will disable the ACMD23, and only in ADMA mode, it will chose to use ACMD23 if the host support. But according to debug, and confirm with IC, the imx6qpdl/imx6sx/imx6sl/imx7d do not support the ACMD23 feature completely. These SoCs only use the 16 bit block count of the register 0x4 (BLOCK_ATT) as the CMD23's argument in ACMD23 mode, which means it will ignore the upper 16 bit of the CMD23's argument. This will block the reliable write operation in RPMB, because RPMB reliable write need to set the bit31 of the CMD23's argument. This is the hardware limitation. So for imx6qpdl/imx6sx/imx6sl/imx7d, it need to broke the ACMD23 for eMMC, SD card do not has this limitation, because SD card do not support reliable write. For imx6ul/imx6ull/imx6sll/imx7ulp/imx8, it support the ACMD23 completely, it change to use the 0x0 register (DS_ADDR) to put the CMD23's argument in ADMA mode. This patch add a new flag ESDHC_FLAG_BROKEN_AUTO_CMD23, and add this flag to imx6q/imx6sx/imx6sl/imx7d, and due to the imx6sll share the same compatible string with imx6sx before, and imx6sll do not has this limitation, so add a new compatible string for imx6sll. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1582100757-20683-4-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-esdhc-imx: optimize the strobe dll settingHaibo Chen
After set the STROBE SLV delay target value, it need to wait some time to let the usdhc lock the REF and SLV clock. In normal case, 1~2us is enough for imx8/imx6 and imx7d, and 4~5us is enough for imx7ulp, but when do reboot stress test or do the bind/unbind stress test, sometimes need to wait about 10us to get the status lock. This patch optimize delay handle method, only print the warning message if the status is still not lock after 1ms delay. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1582100757-20683-3-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-esdhc-imx: optimize the clock settingHaibo Chen
When force clock off, check the SDOFF of register PRSSTAT to make sure the clock is gate off. Before force clock on, check the SDSTB of register PRSSTAT to make sure the clock is stable, this will eliminate the clock glitch. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1582100757-20683-2-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-esdhc-imx: add strobe-dll-delay-target supportHaibo Chen
strobe-dll-delay-target is the delay cell add on the strobe line. Strobe line the the uSDHC loopback read clock which is use in HS400 mode. Different strobe-dll-delay-target may need to set for different board/SoC. If this delay cell is not set to an appropriate value, we may see some read operation meet CRC error after HS400 mode select which already pass the tuning. This patch add the strobe-dll-delay-target setting in driver, so that user can easily config this delay cell in dts file. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1582100757-20683-1-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24doc: dt: fsl-imx-esdhc: add strobe-dll-delay-target bindingHaibo Chen
Add fsl,strobe-dll-delay-target binding. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Link: https://lore.kernel.org/r/1582100704-20601-1-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-esdhc-imx: restore the per_clk rate in PM_RUNTIMEHaibo Chen
When pm_runtime_suspend is run, a call to SCFW power off the SS (SS is a power domain, usdhc belong to this SS power domain) in which the resource resides is made. The SCFW can power off the SS if no other resource in active in that SS. If so, all state associated with all the resources within the SS that is powered off is lost, this includes the clock rates, clock state etc. When pm_runtime_resume is called, the SS associated with that resource is powered up. But the clocks are left in the default state. This patch restore clock rate in pm_runtime_resume, make sure the clock is right rather than depending on the default state setting by SCFW. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1582100563-20555-5-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-esdhci-imx: retune needed for Mega/Mix enabled SoCsHaibo Chen
For Mega/Mix enabled SoCs like MX7D and MX6SX, uSDHC will lost power in LP mode no matter whether the MMC_KEEP_POWER flag is set or not. This may cause state misalign between kernel and HW, especially for SDIO3.0 WiFi cards. e.g. SDIO WiFi driver usually will keep power during system suspend. And after resume, no card re-enumeration called. But the tuning state is lost due to Mega/Mix. Then CRC error may happen during next data transfer. So we should always fire a mmc_retune_needed() for such type SoC to tell MMC core retuning is needed for next data transfer. mmc: sdhci-esdhci-imx: retune needed for Mega/Mix enabled SoCs Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1582100563-20555-4-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci-esdhc-imx: no fail when no pinctrl availableHaibo Chen
When using jailhouse to support two Linux on i.MX8MQ EVK, we use the 1st Linux to configure pinctrl for the 2nd Linux. Then the 2nd Linux could use the mmc without pinctrl driver. So give a warning message when no pinctrl available, but no fail probe. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/1582100563-20555-3-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci: do not enable card detect interrupt for gpio cd typeHaibo Chen
Except SDHCI_QUIRK_BROKEN_CARD_DETECTION and MMC_CAP_NONREMOVABLE, we also do not need to handle controller native card detect interrupt for gpio cd type. If we wrong enabled the card detect interrupt for gpio case, it will cause a lot of unexpected card detect interrupts during data transfer which should not happen. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/1582100563-20555-2-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci_am654: Enable DLL only for some speed modesFaiz Abbas
Its recommended that DLL must only be enabled for SDR50, DDR50, DDR52, SDR104, HS200 and HS400 speed modes. Move DLL configuration to its own function and call it only in the above speed modes. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200108150920.14547-4-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: sdhci_am654: Update OTAPDLY writesFaiz Abbas
According to the latest AM65x Data Manual[1], a different output tap delay value is optimum for a given speed mode. Therefore, deprecate the ti,otap-del-sel binding and introduce a new binding for each of the possible MMC/SD speed modes. If the legacy mode is not found, fall back to old binding to maintain dts compatibility. [1] http://www.ti.com/lit/gpn/am6526 Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200108150920.14547-3-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24dt-bindings: mmc: sdhci-am654: Update Output tap delay bindingFaiz Abbas
According to latest AM65x Data Manual[1], a different output tap delay value is recommended for all speed modes. Therefore, replace the ti,otap-del-sel binding with one ti,otap-del-sel- for each MMC/SD speed mode. [1] http://www.ti.com/lit/gpn/am6526 Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Link: https://lore.kernel.org/r/20200108150920.14547-2-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: host: hsq: Add missing MODULE_LICENSE() and MODULE_DESCRIPTION()Baolin Wang
Add missing MODULE_LICENSE() and MODULE_DESCRIPTION() in hsq driver to fix below warning when compiling the hsq as a module. "WARNING: modpost: missing MODULE_LICENSE() in drivers/mmc/host/mmc_hsq.o". Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Baolin Wang <baolin.wang7@gmail.com> Link: https://lore.kernel.org/r/98ce471185f037fce57520763621590588766381.1582161803.git.baolin.wang7@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: mmci: Add support for sdmmc variant revision 2.0Ludovic Barre
This patch adds a sdmmc variant revision 2.0. This revision is backward compatible with 1.1, but adds DMA linked list support. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200128090636.13689-10-ludovic.barre@st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: mmci_sdmmc: Implement signal voltage callbacksLudovic Barre
To prepare the voltage switch procedure, the VSWITCHEN bit must be set before sending the CMD11. To confirm completion of voltage switch, the VSWEND flag must be checked. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200128090636.13689-9-ludovic.barre@st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: mmci: Add callbacks for to manage signal voltage switchLudovic Barre
A variant may need to define some actions before and after a voltage switch. This patch adds 2 callbacks to manage signal voltage switch in the struct mmci_host_ops. ->pre_sig_volt_switch() allows to prepare a signal voltage switch before sending the SD_SWITCH_VOLTAGE command (CMD11). ->post_sig_volt_switch callback allows specific actions to be executed, after the I/O signal voltage level has been changed. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200128090636.13689-8-ludovic.barre@st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: mmci_sdmmc: Add execute tuning with delay blockLudovic Barre
The hardware delay block is used to align the sampling clock on the data received by SDMMC. It is mandatory for SDMMC to support the SDR104 mode. The delay block is used to generate an output clock which is dephased from the input clock. The phase of the output clock must be programmed by the execute tuning interface. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200128090636.13689-7-ludovic.barre@st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24dt-bindings: mmc: mmci: add delay block base register for sdmmcLudovic Barre
To support the sdr104 mode, the sdmmc variant has a hardware delay block to manage the clock phase when sampling data received by the card. This patch adds a second base register (optional) for sdmmc delay block. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200128090636.13689-6-ludovic.barre@st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-24mmc: mmci: Add private pointer for variantLudovic Barre
In variant init function, some references may be allocated for variant specific usage. Add a private void* to mmci_host struct allows at variant functions to access on this references by mmci_host structure. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200128090636.13689-5-ludovic.barre@st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>