| Age | Commit message (Collapse) | Author |
|---|
|
The sh_mmcif driver is already using a 10s request timeout. Let's also
inform the mmc core about this value, as there are situations when it
needs to know about it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The sh_mmcif explicity checks for certain commands to decide when to
enable HW busy detection. Instead, it should only check the response type
as it tells if busy detection is needed.
In this way, the mmc core also gets full control whether it thinks busy
detection should be done or not. In some specific scenarios, like for
ERASE and STOP commands it may decide to fall back to use a CMD13 to poll
the card status instead.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Enable the capabilities which tells the mmc core to prevent sending SD and
SDIO commands during card initialization. In this way, we can also remove
the validation of non-supported commands in the ->request() callback.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
There are host drivers which needs to valdiate for non-supported SD
commands and returnn error code for such requests.
To improve and simplify the behaviour, let's invent MMC_CAP2_NO_SD
which these host drivers can set to tell the mmc core to skip sending SD
commands during card initialization.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
trivial fix to spelling mistake in dev_err message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
sdhci_dumpregs is used to dump registers when error happens. Thus it should
use pr_err instead of pr_debug to show more information about the hardware.
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
[Fix whitespace and checkpatch warnings]
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
In linux/mmc/host.h, mmc_card_is_removable() is already defined.
It should be maintainted more easier than now.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The "phyctrl_frqsel" is described in the Arasan datasheet [1] as "the
frequency range of DLL operation". Although the Rockchip variant of
this PHY has different ranges than the reference Arasan PHY it appears
as if the functionality is similar. We should set this phyctrl field
properly.
Note: as per Rockchip engineers, apparently the "phyctrl_frqsel" is
actually only useful in HS200 / HS400 modes even though the DLL itself
it used for some purposes in all modes. See the discussion in the
earlier change in this series: ("mmc: sdhci-of-arasan: Always power the
PHY off/on when clock changes"). In any case, it shouldn't hurt to set
this always.
Note that this change should allow boards to run at HS200 / HS400 speed
modes while running at 100 MHz or 150 MHz. In fact, running HS400 at
150 MHz (giving 300 MB/s) is the main motivation of this series, since
performance is still good but signal integrity problems are less
prevelant at 150 MHz.
[1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
There's no reason to store the return value of rockchip_emmc_phy_power()
in a variable nor to check it. Just return it.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work
with arasan,sdhci-5.1) need to know the card clock in order to function
properly. Let's add the ability to expose this clock. Any PHY that
needs to know the clock rate can add a reference and query the clock
rate.
At the moment we register a CLK_GET_RATE_NOCACHE clock that simply
allows querying the clock. This allows us to be less intrusive with
regards to the main SDHCI driver, which has complex logic for adjusting
the SD clock. Right now we always fully power cycle the PHY when the
clock changes and that gives the PHY a good chance to query our clock.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
In the the earlier change in this series ("Documentation: mmc:
sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs") we can see the
mechansim for specifying a syscon to properly set corecfg registers in
sdhci-of-arasan. Now let's use this mechanism to properly set
corecfg_baseclkfreq on rk3399.
>From [1] the corecfg_baseclkfreq is supposed to be set to:
Base Clock Frequency for SD Clock.
This is the frequency of the xin_clk.
This is a relatively easy thing to do. Note that we assume that xin_clk
is not dynamic and we can check the clock at probe time. If any real
devices have a dynamic xin_clk future patches could register for
notifiers for the clock.
At the moment, setting corecfg_baseclkfreq is only supported for rk3399
since we need a specific map for each implementation. The code is
written in a generic way that should make this easy to extend to other
SoCs. Note that a specific compatible string for rk3399 is already in
use and so we add that to the table to match rk3399.
[1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
In commit 802ac39a5566 ("mmc: sdhci-of-arasan: fix set_clock when a phy
is supported") we added code to power the PHY off and on whenever the
clock was changed but we avoided doing the power cycle code when the
clock was low speed. Let's now do it always.
Although there may be other reasons for power cycling the PHY when the
clock changes, one of the main reasons is that we need to give the DLL a
chance to re-lock with the new clock.
One of the things that the DLL is for is tuning the Receive Clock in
HS200 mode and STRB in HS400 mode. Thus it is clear that we should make
sure we power cycle the PHY (and wait for the DLL to lock) when we know
we'll be in one of these two speed modes. That's what the original code
did, though it used the clock rate rather than the speed mode. However,
even in speed modes other than HS200,/HS400 the DLL is used for
something since it can be clearly observed that the PHY doesn't function
properly if you leave the DLL off.
Although it appears less important to power cycle the PHY and wait for
the DLL to lock when not in HS200/HS400 modes (no bugs were reported),
it still seems wise to let the locking always happen nevertheless.
Note: as part of this, we make sure that we never try to turn the PHY on
when the clock is off (when the clock rate is 0). The PHY cannot work
when the clock is off since its DLL can't lock.
This change requires ("phy: rockchip-emmc: Increase lock time
allowance") and will cause problems if picked without that change.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Previous PHY code waited a fixed amount of time for the DLL to lock at
power on time. Unfortunately, the time for the DLL to lock is actually
a bit more dynamic and can be longer if the card clock is slower.
Instead of waiting a fixed 30 us, let's now dynamically wait until the
lock bit gets set. We'll wait up to 10 ms which should be OK even if
the card clock is at the super slow 100 kHz.
On its own, this change makes the PHY power on code a little more
robust. Before this change the PHY was relying on the eMMC code to make
sure the PHY was only powered on when the card clock was set to at least
50 MHz before, though this reliance wasn't documented anywhere.
This change will be even more useful in future changes where we actually
need to be able to wait for a DLL lock at slower clock speeds.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Some of the spacing was wrong (spaces instead of tabs), and due to
longer entries added later, the columns weren't aligned. Let's get
everything consistent.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The output tap delay controls helps maintain the hold requirements for
eMMC. The exact value is dependent on the SoC and other factors, though
it isn't really an exact science. But the default of 0 is not very good,
as it doesn't give the eMMC much hold time, so let's bump up to 4
(approx 90 degree phase?). If we need to configure this any further
(e.g., based on board or speed factors), we may need to consider a
device tree representation.
Suggested-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Signal integrity analysis has suggested we set these values. Do this in
power_on(), so that they get reconfigured after suspend/resume.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
According to the databook, 10.2us is the max time for dll to be ready to
work. However in testing, some chips need 20us for dll to be ready. This
patch adds some extra margin for dllrdy to be ready, fixing our
-ETIMEDOUT issues.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Add SDHCI driver for Broadcom BRCMSTB SoCs.
This driver works with all ARM based SoCs and the 7425, 7429
and 7435 MIPS based SoCs.
The driver disables all UHS speed modes by default and relies
on the Device Tree node properties to enable these modes for
SoC/Board combinations that support them.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Apparently a cut-and-paste error, 'do_data_tag' is using 'brq' for data
size even though 'brq' has not been set up. Instead use blk_rq_sectors().
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Certain Hynix eMMC 4.41 cards might get broken when HPI feature is used
and hence this patch disables the HPI feature for such buggy cards.
As some of the other features like BKOPs/Cache/Sanitize are dependent on
HPI feature, those features would also get disabled if HPI is disabled.
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
[gdavis: Forward port and cleanup]
Signed-off-by: George G. Davis <george_davis@mentor.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
mmc_select_bus_width() returns bus width (4 or 8) on success or
zero if unsupported. So only change mode if setting the bus width
is successful.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
If available, eMMC stack uses HC_ERASE_GRP_SIZE as the preferred erase
size. As some high capacity eMMC (64MB) reports this size to 512kB, the
discard operations end up taking very long time.
Improve the behaviour by instead calculating the preferred erase size
based on the eMMC size. In this way the discard operations becomes faster.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
[Ulf: Updated changelog and improved comment in code]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The sdhci-bcm2835 is no more needed since it has been replaced
by sdhci-iproc.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
To slove the issue which was found on gru board for hs400.
[ 4.616946] sdhci: Secure Digital Host Controller Interface driver
[ 4.623135] sdhci: Copyright(c) Pierre Ossman
[ 4.722575] sdhci-pltfm: SDHCI platform and OF driver helper
[ 4.730962] sdhci-arasan fe330000.sdhci: No vmmc regulator found
[ 4.737444] sdhci-arasan fe330000.sdhci: No vqmmc regulator found
[ 4.774930] mmc0: SDHCI controller on fe330000.sdhci [fe330000.sdhci] using ADMA
[ 4.980295] mmc0: switch to high-speed from hs200 failed, err:-84
[ 4.986487] mmc0: error -84 whilst initialising MMC card
We should change HS400 mode selection timing to meet JEDEC
specification. The JEDEC 5.1 said that change the frequency to <= 52MHZ
after HS_TIMING switch. Refer to section 6.6.2.3 "HS400" timing mode
selection:
Set the "Timing Interface" parameter in the HS_TIMING[185] field of the
Extended CSD register to 0x1 to switch to High Speed mode and then set
the clock frequency to a value not greater than 52MHZ.
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
with CONFIG_HZ=100, the precision of jiffies is 10ms, and the
generic_cmd6_time of some card is also 10ms. then, may be current
time is only 5ms, but already timed out caused by jiffies precision.
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Per JEDEC spec, it is not recommended to use CMD13 to get card status
after speed mode switch. below are two reason about this:
1. CMD13 cannot be guaranteed due to the asynchronous operation.
Therefore it is not recommended to use CMD13 to check busy completion
of the timing change indication.
2. After switch to HS200, CMD13 will get response of 0x800, and even the
busy signal gets de-asserted, the response of CMD13 is aslo 0x800.
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Some MMC hosts do not support MMC_CAP_WAIT_WHILE_BUSY, but implements the
->card_busy() callback. In such cases, extend __mmc_switch() to use this
method to check card status after switch command.
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
host->card_busy() was introduced for SD voltage switching which checks all
4 data lines.
Increasingly, host->card_busy is being used to poll the the busy signal
which is only data line 0 (DAT[0]).
The current logic in sdhci_card_busy() does not work in that case because
it returns false if any of the data lines is high. It also ignores
possibilities:
- data lines 1-3 are not connected and could show at any level
- data lines 1-2 can be used by SDIO for other purposes
According to the SD specification, it is OK to check any of the data lines
for voltage switching, so change to use DAT[0] only.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Sparse complains about the implicit cast. Making it explicit is indeed
better coding style.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Currently sdhci-arasan 5.1 can support enhanced strobe function,
and we now limit it just for "arasan,sdhci-5.1". Add
mmc-hs400-enhanced-strobe in DT to enable the function if we're
sure our controller can support it.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
We introduce HS400 with enhanced strobe function, so we need
to add it for debug show.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Controllers use data strobe line to latch data from devices
under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC
introduces enhanced strobe mode for latching cmd response from
emmc devices to host controllers. This new feature is optional,
so it depends both on device's cap and host's cap to decide
whether to use it or not.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
This patch introduce mmc-hs400-enhanced-strobe for platforms
which want to enable enhanced strobe function from DT if the
mmc host controller claims to support enhanced strobe.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Activating wakeup event is not enough to get a wakeup signal. The
corresponding events have to be enabled in the Interrupt Status Enable
Register too. It follows the specification and is needed at least by
sdhci-of-at91.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
In sectors alignment check, brq->data.blocks means sectors of the
previous mqrq since data.blocks for mqrq_cur hasn't been updated yet.
data.blocks will be updated later in mmc_blk_packed_hdr_wrq_prep or
mmc_blk_rw_rq_prep.
static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, ......
......
struct mmc_blk_request *brq = &mq->mqrq_cur->brq;
Signed-off-by: Yuan Juntao <juntao.yuan@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Since commit 7ce45e950624 ("mmc: sdhci: SD tuning is broken for some
controllers") sdhci_execute_tuning() no longer includes a timeout in its
loop counter(s) so remove portion of the comment regarding this.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Replace hardcoded values with meaningful names and document what we
know.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
So that callers of cros_ec_cmd_xfer() don't have to repeat boilerplate
code when checking for errors from the EC side.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Add this workaround to prevent hang when in place compression
is used.
References: HSD#2135774
Cc: stable@vger.kernel.org
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 4ba9c1f7c7b8ca8c1d77f65d408e589dc87b9a2d)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This reverts commit 041824ee25cfc535ba2d9a22c217df735ea2471e.
We have latency issues that might impact the performance: #96606.
and hangs and loading issues on resume after S4: #96526.
This is also blocking a platform milestone so let's disable
this for now while we make sure we don't have any more loading
issue, or related basic hangs and it pass BAT for real in all
platofmrs.
In case BAT is wrong let's first fix BAT before re-enable it here.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96606
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96526
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Christophe Prigent <christophe.prigent@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1468884477-30086-1-git-send-email-rodrigo.vivi@intel.com
(cherry picked from commit fe993bc9582ff23c9a81414acdfed8e55478e456)
[danvet: Drop cc: stable since this is for 4.8 only.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Setting a write-back cache policy in the MOCS entry definition also
implies snooping, which has a considerable overhead. This is
unexpected for a few reasons:
- From user-space's point of view since it didn't want a coherent
surface (it didn't set the buffer as such via the set caching IOCTL).
- There is a separate MOCS entry field for snooping (which we never
set).
- This MOCS table is about caching in (e)LLC and there is no (e)LLC on
BXT. There is a separate table for L3 cache control.
Considering the above the current behavior of snooping looks like an
unintentional side-effect of the WB setting. Changing it to be LLC-UC
gets rid of the snooping without any ill-effects. For a coherent
surface the application would use a separate MOCS entry at index 1 and
call the set caching IOCTL to setup the PTE entries for the
corresponding buffer to be snooped. In the future we could also add a
new MOCS entry for coherent surfaces.
This resulted in 70% improvement in synthetic texturing benchmarks.
Kudos to Valtteri Rantala, Eero Tamminen and Michael T Frederick and
Ville who helped to narrow the source of problem to the kernel and to
the snooping behaviour in particular.
With a follow-up change to adjust the 3rd entry value
igt/gem_mocs_settings is passing after this change.
v2:
- Rebase on v2 of patch 1/2.
v3:
- Set the entry as LLC uncached instead of PTE-passthrough. This way
we also keep snooping disabled, but we also make the cacheability/
coherency setting indepent of the PTE which is managed by the
kernel. (Chris)
CC: Rong R Yang <rong.r.yang@intel.com>
CC: Yakui Zhao <yakui.zhao@intel.com>
CC: Valtteri Rantala <valtteri.rantala@intel.com>
CC: Eero Tamminen <eero.t.tamminen@intel.com>
CC: Michael T Frederick <michael.t.frederick@intel.com>
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Zhao Yakui <yakui.zhao@intel.com>
Tested-by: Rong R Yang <rong.r.yang@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1467380406-11954-3-git-send-email-imre.deak@intel.com
(cherry picked from commit 6bee14ed1e1136d700e5290c080e1145982ce43e)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Use named struct initializers for clarity. Also fix the target cache
definition to reflect its role in GEN9 onwards. On GEN8 a TC value of 0
meant ELLC but on GEN9+ it means the TC and LRU controls are taken from
the PTE.
No functional change, igt/gem_mocs_settings still passing after this
change.
v2: (Chris)
- Add back the hexa literals for the entries.
Add note that igt/gem_mocs_settings still passes.
CC: Rong R Yang <rong.r.yang@intel.com>
CC: Yakui Zhao <yakui.zhao@intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1467380406-11954-2-git-send-email-imre.deak@intel.com
(cherry picked from commit e419899b7c19ef99e340e2b1ba585d82fd28c53b)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This patch offloads port mirroring directives to hw using the matchall TC
with action mirror. It includes both the implementation of the
ndo_setup_tc function for the spectrum driver and the spectrum hardware
offload configuration code.
The hardware offload code is basically two new functions which are capable
of adding and removing a new mirror ports pair. It is done using the MPAT,
MPAR and SBIB registers:
- A new Switch-Port Analyzer (SPAN) entry is added using MPAT to the 'to'
port.
- The 'to' port is bound to the SPAN entry using MPAR register.
- In case of egress SPAN, the 'to' port gets a new internal shared
buffer using SBIB register.
In addition, a new database was added to the mlxsw_sp struct to store all
the SPAN entries and their bound ports list. The number of supported SPAN
entries is determined by resource query.
Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The MPAR register is used to bind ports to a SPAN entry (which was
created using MPAT register) and thus mirror their traffic (ingress /
egress) to a different port.
Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The MPAT register is used to query and configure the Switch Port Analyzer
(SPAN) table. This register is used to configure a port as a mirror output
port, while after that a mirrored input port can be bound using MPAR
register.
Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The SBIB register configures per port buffer for internal use. This
register is used to configure an egress mirror buffer on the egress port
which does the mirroring.
Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add max span resources to resources query.
Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add resources query implementation. If exists, query the HW for its
builtin resources instead of having them as consts in the code.
Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The firmware in several ZTE devices (at least the MF823/831/910
modems/mifis) use OS fingerprinting to determine which type of device to
export. In addition, these devices export a REST API which can be used to
control the type of device. So far, on Linux, the devices have been seen as
RNDIS or CDC Ether.
When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the devices
(at least on all firmware revisions I have found) use the bogus MAC when
sending traffic routed from external networks. And as a final feature, the
devices sometimes export the link state incorrectly. There are also
references online to several other ZTE devices displaying this behavior,
with several different PIDs and MAC addresses.
This patch tries to improve the handling of ZTE devices by doing the
following:
* Create a new driver_info-struct that is used by ZTE devices that do not
have an explicit entry in the product table. This struct is the same as the
default cdc_ether driver info, but a new bind- and an rx_fixup-function
have been added.
* In the new bind function, we check if we have read a random MAC from the
device. If we have, then we generate a new random MAC address. This will
ensure that all devices get a unique MAC.
* The rx_fixup-function replaces the destination MAC address in the skb
with that of the device. I have not seen a revision of these devices that
behaves correctly (i.e., sets the right destination MAC), so I chose not to
do any comparison with for example the known, bogus addresses.
* The MF823/MF832/MF910 sometimes export cdc carrier on twice on connect
(the correct behavior is off then on). Work around this by manually setting
carrier to off if an on-notification is received and the NOCARRIER-bit is
not set.
This change will affect all devices, but it should take care of similar
mistakes made by other manufacturers. I tried to think of/look/test for
problems/regressions that could be introduced by this behavior, but could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.
I have tested this patch with multiple revisions of all three devices, and
they behave as expected. In other words, they all got a valid, random MAC,
the correct operational state and I can receive/sent traffic without
problems. I also tested with some other cdc_ether devices I have and did
not find any problems/regressions caused by the two general changes.
v3->v4:
* Forgot to remove unused variables, sorry about that (thanks David
Miller).
v2->v3:
* I had forgot to remove the random MAC generation from usbnet_cdc_bind()
(thanks Oliver).
* Rework logic in the ZTE bind-function a bit.
v1->v2:
* Only generate random MAC for ZTE devices (thanks Oliver Neukum).
* Set random MAC and do RX fixup for all ZTE devices that do not have a
product-entry, as the bogus MAC have been seen on devices with several
different PIDs/MAC addresses. In other words, it seems to be the default
behavior of ZTE CDC Ether devices (thanks Lars Melin).
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon updates from Guenter Roeck:
- New drivers for FTS BMC "Teutates", TI INA3221, and Sensirion SHT3x.
- Added support for Microchip MCP9808 and TI TMP461.
- Cleanup and minor fixes in various drivers.
* tag 'hwmon-for-linus-v4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (37 commits)
Documentation: dtb: xgene: Add hwmon dts binding documentation
hwmon: (ftsteutates) Remove unused including <linux/version.h>
hwmon: (adt7411) set bit 3 in CFG1 register
hwmon: Add driver for FTS BMC chip "Teutates"
hwmon: (sht3x) add humidity heater element control
hwmon: (jc42) Add support for generic JC-42.4 devicetree binding
dt/bindings: Add bindings for JC-42.4 compatible temperature sensors
hwmon: (tmp102) Convert to use regmap, and drop local cache
hwmon: (tmp102) Rework chip configuration
hwmon: (tmp102) Improve handling of initial read delay
hwmon: (lm90) Drop unnecessary else statements
hwmon: (lm90) Use bool for valid flag
hwmon: (lm90) Read limit registers only once
hwmon: (lm90) Simplify read functions
hwmon: (lm90) Use devm_hwmon_device_register_with_groups
hwmon: (lm90) Use devm_add_action for cleanup
hwmon: (lm75) Convert to use regmap
hwmon: (lm75) Add update_interval attribute
hwmon: (lm75) Drop lm75_read_value and lm75_write_value
hwmon: (lm75) Handle cleanup with devm_add_action
...
|
