Re: [GIT PULL] pin control fixes for v5.0-rc
The pull request you sent on Wed, 6 Feb 2019 09:09:39 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git > tags/pinctrl-v5.0-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b66bc7776748c97a6dc013c8d06e10ebf1c14307 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] fuse fixes for 5.0-rc6
The pull request you sent on Wed, 6 Feb 2019 16:07:42 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git > tags/fuse-fixes-5.0-rc6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/076a3f553743cca32ff261d4bea29a4e92d936dd Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PULL] virtio: fixes
The pull request you sent on Wed, 6 Feb 2019 14:32:56 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b0314565da2b95e73feab484467ad171fcce6dff Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] tracing: Small fixes to the uprobe code
The pull request you sent on Wed, 6 Feb 2019 11:43:00 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git > trace-v5.0-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4879f11615d29d7b91cd5a4cfbff8e563ada991d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] Input: stmfts - acknowledge that setting brightness is a blocking call
Hi Dmitry,
On Tue, Feb 05, 2019 at 02:46:42PM -0800, Dmitry Torokhov wrote:
> We need to turn regulators on and off when switching brightness, and
> that may block, therefore we have to set stmfts_brightness_set() as
> LED's brightness_set_blocking() method.
>
> Fixes: 78bcac7b2ae1 ("Input: add support for the STMicroelectronics FingerTip
> touchscreen")
> Signed-off-by: Dmitry Torokhov
Acked-by: Andi Shyti
Thanks,
Re: [PATCH v2 0/3] Documentation: Explain EAS and EM
Hi Jon, > So these have been sitting in my folder waiting for acks or some other > sort of discussion, but it's been awfully quiet. Should I take them, or > do they need further work or ... ? These (well, the v1 actually) have been picked recently up by Ingo in tip/sched/core. Thanks, Quentun
Re: [PATCH v5 4/9] sun6i: dsi: Convert to generic phy handling
Hi,
On Mon, 2019-01-21 at 16:45 +0100, Maxime Ripard wrote:
> Now that we have everything in place in the PHY framework to deal in a
> generic way with MIPI D-PHY phys, let's convert our PHY driver and its
> associated DSI driver to that new API.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
> drivers/gpu/drm/sun4i/Kconfig | 11 +-
> drivers/gpu/drm/sun4i/Makefile | 6 +-
> drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 164 ++---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 31 ++---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 17 +---
> 5 files changed, 126 insertions(+), 103 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
> index c2c042287c19..2b8db82c4bab 100644
> --- a/drivers/gpu/drm/sun4i/Kconfig
> +++ b/drivers/gpu/drm/sun4i/Kconfig
> @@ -45,10 +45,19 @@ config DRM_SUN6I_DSI
> default MACH_SUN8I
> select CRC_CCITT
> select DRM_MIPI_DSI
> + select DRM_SUN6I_DPHY
> help
> Choose this option if you want have an Allwinner SoC with
> MIPI-DSI support. If M is selected the module will be called
> - sun6i-dsi
> + sun6i_mipi_dsi.
> +
> +config DRM_SUN6I_DPHY
> + tristate "Allwinner A31 MIPI D-PHY Support"
> + select GENERIC_PHY_MIPI_DPHY
> + help
> + Choose this option if you have an Allwinner SoC with
> + MIPI-DSI support. If M is selected, the module will be
> + called sun6i_mipi_dphy.
>
> config DRM_SUN8I_DW_HDMI
> tristate "Support for Allwinner version of DesignWare HDMI"
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 0eb38ac8e86e..1e2320d824b5 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -24,9 +24,6 @@ sun4i-tcon-y+= sun4i_lvds.o
> sun4i-tcon-y += sun4i_tcon.o
> sun4i-tcon-y += sun4i_rgb.o
>
> -sun6i-dsi-y += sun6i_mipi_dphy.o
> -sun6i-dsi-y += sun6i_mipi_dsi.o
> -
> obj-$(CONFIG_DRM_SUN4I) += sun4i-drm.o
> obj-$(CONFIG_DRM_SUN4I) += sun4i-tcon.o
> obj-$(CONFIG_DRM_SUN4I) += sun4i_tv.o
> @@ -37,7 +34,8 @@ ifdef CONFIG_DRM_SUN4I_BACKEND
> obj-$(CONFIG_DRM_SUN4I) += sun4i-frontend.o
> endif
> obj-$(CONFIG_DRM_SUN4I_HDMI) += sun4i-drm-hdmi.o
> -obj-$(CONFIG_DRM_SUN6I_DSI) += sun6i-dsi.o
> +obj-$(CONFIG_DRM_SUN6I_DPHY) += sun6i_mipi_dphy.o
> +obj-$(CONFIG_DRM_SUN6I_DSI) += sun6i_mipi_dsi.o
> obj-$(CONFIG_DRM_SUN8I_DW_HDMI) += sun8i-drm-hdmi.o
> obj-$(CONFIG_DRM_SUN8I_MIXER)+= sun8i-mixer.o
> obj-$(CONFIG_DRM_SUN8I_TCON_TOP) += sun8i_tcon_top.o
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
> index e4d19431fa0e..79c8af5c7c1d 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
> @@ -8,11 +8,14 @@
>
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
>
> -#include "sun6i_mipi_dsi.h"
> +#include
> +#include
>
> #define SUN6I_DPHY_GCTL_REG 0x00
> #define SUN6I_DPHY_GCTL_LANE_NUM(n) n) - 1) & 3) << 4)
> @@ -81,12 +84,46 @@
>
> #define SUN6I_DPHY_DBG5_REG 0xf4
>
> -int sun6i_dphy_init(struct sun6i_dphy *dphy, unsigned int lanes)
> +struct sun6i_dphy {
> + struct clk *bus_clk;
> + struct clk *mod_clk;
> + struct regmap *regs;
> + struct reset_control*reset;
> +
> + struct phy *phy;
> + struct phy_configure_opts_mipi_dphy config;
> +};
> +
> +static int sun6i_dphy_init(struct phy *phy)
> {
> + struct sun6i_dphy *dphy = phy_get_drvdata(phy);
> +
> reset_control_deassert(dphy->reset);
> clk_prepare_enable(dphy->mod_clk);
> clk_set_rate_exclusive(dphy->mod_clk, 15000);
>
> + return 0;
> +}
> +
> +static int sun6i_dphy_configure(struct phy *phy, union phy_configure_opts
> *opts)
> +{
> + struct sun6i_dphy *dphy = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = phy_mipi_dphy_config_validate(>mipi_dphy);
> + if (ret)
> + return ret;
> +
> + memcpy(>config, opts, sizeof(dphy->config));
> +
> + return 0;
> +}
> +
> +static int sun6i_dphy_power_on(struct phy *phy)
> +{
> + struct sun6i_dphy *dphy = phy_get_drvdata(phy);
> + u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
> +
> regmap_write(dphy->regs, SUN6I_DPHY_TX_CTL_REG,
>SUN6I_DPHY_TX_CTL_HS_TX_CLK_CONT);
>
> @@ -111,16 +148,9 @@ int sun6i_dphy_init(struct sun6i_dphy *dphy, unsigned
> int lanes)
>SUN6I_DPHY_TX_TIME4_HS_TX_ANA1(3));
>
> regmap_write(dphy->regs, SUN6I_DPHY_GCTL_REG,
> -
Re: [PATCH v4 4/9] sun6i: dsi: Convert to generic phy handling
Hi,
On Wed, 2019-01-09 at 10:33 +0100, Maxime Ripard wrote:
> Now that we have everything in place in the PHY framework to deal in a
> generic way with MIPI D-PHY phys, let's convert our PHY driver and its
> associated DSI driver to that new API.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
> drivers/gpu/drm/sun4i/Kconfig | 11 +-
> drivers/gpu/drm/sun4i/Makefile | 6 +-
> drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 164 ++---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 31 ++---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 17 +---
> 5 files changed, 126 insertions(+), 103 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
> index c2c042287c19..2b8db82c4bab 100644
> --- a/drivers/gpu/drm/sun4i/Kconfig
> +++ b/drivers/gpu/drm/sun4i/Kconfig
> @@ -45,10 +45,19 @@ config DRM_SUN6I_DSI
> default MACH_SUN8I
> select CRC_CCITT
> select DRM_MIPI_DSI
> + select DRM_SUN6I_DPHY
> help
> Choose this option if you want have an Allwinner SoC with
> MIPI-DSI support. If M is selected the module will be called
> - sun6i-dsi
> + sun6i_mipi_dsi.
> +
> +config DRM_SUN6I_DPHY
> + tristate "Allwinner A31 MIPI D-PHY Support"
> + select GENERIC_PHY_MIPI_DPHY
> + help
> + Choose this option if you have an Allwinner SoC with
> + MIPI-DSI support. If M is selected, the module will be
> + called sun6i_mipi_dphy.
>
> config DRM_SUN8I_DW_HDMI
> tristate "Support for Allwinner version of DesignWare HDMI"
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 0eb38ac8e86e..1e2320d824b5 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -24,9 +24,6 @@ sun4i-tcon-y+= sun4i_lvds.o
> sun4i-tcon-y += sun4i_tcon.o
> sun4i-tcon-y += sun4i_rgb.o
>
> -sun6i-dsi-y += sun6i_mipi_dphy.o
> -sun6i-dsi-y += sun6i_mipi_dsi.o
> -
> obj-$(CONFIG_DRM_SUN4I) += sun4i-drm.o
> obj-$(CONFIG_DRM_SUN4I) += sun4i-tcon.o
> obj-$(CONFIG_DRM_SUN4I) += sun4i_tv.o
> @@ -37,7 +34,8 @@ ifdef CONFIG_DRM_SUN4I_BACKEND
> obj-$(CONFIG_DRM_SUN4I) += sun4i-frontend.o
> endif
> obj-$(CONFIG_DRM_SUN4I_HDMI) += sun4i-drm-hdmi.o
> -obj-$(CONFIG_DRM_SUN6I_DSI) += sun6i-dsi.o
> +obj-$(CONFIG_DRM_SUN6I_DPHY) += sun6i_mipi_dphy.o
> +obj-$(CONFIG_DRM_SUN6I_DSI) += sun6i_mipi_dsi.o
> obj-$(CONFIG_DRM_SUN8I_DW_HDMI) += sun8i-drm-hdmi.o
> obj-$(CONFIG_DRM_SUN8I_MIXER)+= sun8i-mixer.o
> obj-$(CONFIG_DRM_SUN8I_TCON_TOP) += sun8i_tcon_top.o
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
> index e4d19431fa0e..79c8af5c7c1d 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
> @@ -8,11 +8,14 @@
>
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
>
> -#include "sun6i_mipi_dsi.h"
> +#include
> +#include
>
> #define SUN6I_DPHY_GCTL_REG 0x00
> #define SUN6I_DPHY_GCTL_LANE_NUM(n) n) - 1) & 3) << 4)
> @@ -81,12 +84,46 @@
>
> #define SUN6I_DPHY_DBG5_REG 0xf4
>
> -int sun6i_dphy_init(struct sun6i_dphy *dphy, unsigned int lanes)
> +struct sun6i_dphy {
> + struct clk *bus_clk;
> + struct clk *mod_clk;
> + struct regmap *regs;
> + struct reset_control*reset;
> +
> + struct phy *phy;
> + struct phy_configure_opts_mipi_dphy config;
> +};
> +
> +static int sun6i_dphy_init(struct phy *phy)
> {
> + struct sun6i_dphy *dphy = phy_get_drvdata(phy);
> +
> reset_control_deassert(dphy->reset);
> clk_prepare_enable(dphy->mod_clk);
> clk_set_rate_exclusive(dphy->mod_clk, 15000);
>
> + return 0;
> +}
> +
> +static int sun6i_dphy_configure(struct phy *phy, union phy_configure_opts
> *opts)
> +{
> + struct sun6i_dphy *dphy = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = phy_mipi_dphy_config_validate(>mipi_dphy);
> + if (ret)
> + return ret;
> +
> + memcpy(>config, opts, sizeof(dphy->config));
> +
> + return 0;
> +}
> +
> +static int sun6i_dphy_power_on(struct phy *phy)
> +{
> + struct sun6i_dphy *dphy = phy_get_drvdata(phy);
> + u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
> +
> regmap_write(dphy->regs, SUN6I_DPHY_TX_CTL_REG,
>SUN6I_DPHY_TX_CTL_HS_TX_CLK_CONT);
>
> @@ -111,16 +148,9 @@ int sun6i_dphy_init(struct sun6i_dphy *dphy, unsigned
> int lanes)
>SUN6I_DPHY_TX_TIME4_HS_TX_ANA1(3));
>
> regmap_write(dphy->regs, SUN6I_DPHY_GCTL_REG,
> -
Re: bcache on XFS: metadata I/O (dirent I/O?) not getting cached at all?
On 2019/2/7 6:11 上午, Nix wrote:
> So I just upgraded to 4.20 and revived my long-turned-off bcache now
> that the metadata corruption leading to mount failure on dirty close may
> have been identified (applying Tang Junhui's patch to do so)... and I
> spotted something a bit disturbing. It appears that XFS directory and
> metadata I/O is going more or less entirely uncached.
>
> Here's some bcache stats before and after a git status of a *huge*
> uncached tree (Chromium) on my no-writeback readaround cache. It takes
> many minutes and pounds the disk with massively seeky metadata I/O in
> the process:
>
> Before:
>
> stats_total/bypassed: 48.3G
> stats_total/cache_bypass_hits: 7942
> stats_total/cache_bypass_misses: 861045
> stats_total/cache_hit_ratio: 3
> stats_total/cache_hits: 16286
> stats_total/cache_miss_collisions: 25
> stats_total/cache_misses: 411575
> stats_total/cache_readaheads: 0
>
> After:
> stats_total/bypassed: 49.3G
> stats_total/cache_bypass_hits: 7942
> stats_total/cache_bypass_misses: 1154887
> stats_total/cache_hit_ratio: 3
> stats_total/cache_hits: 16291
> stats_total/cache_miss_collisions: 25
> stats_total/cache_misses: 411625
> stats_total/cache_readaheads: 0
>
> Huge increase in bypassed reads, essentially no new cached reads. This
> is... basically the optimum case for bcache, and it's not caching it!
>
> From my reading of xfs_dir2_leaf_readbuf(), it looks like essentially
> all directory reads in XFS appear to bcache as a single non-readahead
> followed by a pile of readahead I/O: bcache bypasses readahead bios, so
> all directory reads (or perhaps all directory reads larger than a single
> block) are going to be bypassed out of hand.
>
> This seems... suboptimal, but so does filling up the cache with
> read-ahead blocks (particularly for non-metadata) that are never used.
> Anyone got any ideas, 'cos I'm currently at a loss: XFS doesn't appear
> to let us distinguish between "read-ahead just in case but almost
> certain to be accessed" (like directory blocks) and "read ahead on the
> offchance because someone did a single-block file read and what the hell
> let's suck in a bunch more".
>
> As it is, this seems to render bcache more or less useless with XFS,
> since bcache's primary raison d'etre is precisely to cache seeky stuff
> like metadata. :(
>
Hi Nix,
Could you please to try whether the attached patch makes things better ?
Thanks in advance for your help.
--
Coly Li
From 7c27e26017f6297a6bc6a8075732f69d3edcc52e Mon Sep 17 00:00:00 2001
From: Coly Li
Date: Thu, 7 Feb 2019 15:54:24 +0800
Subject: [PATCH] bcache: use (REQ_META|REQ_PRIO) to indicate bio for metadata
In 'commit 752f66a75aba ("bcache: use REQ_PRIO to indicate bio for
metadata")' REQ_META is replaced by REQ_PRIO to indicate metadata bio.
This assumption is not always correct, e.g. XFS uses REQ_META to mark
metadata bio other than REQ_PRIO. This is why Nix reports a regression
that bcache does not cache metadata for XFS after the above commit.
Thanks to Dave Chinner, he explains the difference between REQ_META and
REQ_PRIO from view of file system developer. Here I quote part of his
explanation from mailing list,
REQ_META is used for metadata. REQ_PRIO is used to communicate to
the lower layers that the submitter considers this IO to be more
important that non REQ_PRIO IO and so dispatch should be expedited.
IOWs, if the filesystem considers metadata IO to be more important
that user data IO, then it will use REQ_PRIO | REQ_META rather than
just REQ_META.
Then it seems bios with REQ_META or REQ_PRIO should both be cached for
performance optimation, because they are all probably low I/O latency
demand by upper layer (e.g. file system).
So in this patch, when we want to check whether a bio is metadata
related, REQ_META and REQ_PRIO are both checked. Then both metadata and
high priority I/O requests will be handled properly.
Reported-by: Nix
Signed-off-by: Coly Li
Cc: Dave Chinner
Cc: Andre Noll
Cc: Christoph Hellwig
---
drivers/md/bcache/request.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index 3bf35914bb57..62bda90a38dc 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -395,7 +395,7 @@ static bool check_should_bypass(struct cached_dev *dc,
struct bio *bio)
* unless the read-ahead request is for metadata (eg, for gfs2 or xfs).
*/
if (bio->bi_opf & (REQ_RAHEAD|REQ_BACKGROUND) &&
- !(bio->bi_opf & REQ_PRIO))
+ !(bio->bi_opf & (REQ_META|REQ_PRIO)))
goto skip;
if (bio->bi_iter.bi_sector & (c->sb.block_size - 1) ||
@@ -877,7 +877,7 @@ static int cached_dev_cache_miss(struct btree *b, struct
search *s,
}
if (!(bio->bi_opf & REQ_RAHEAD) &&
- !(bio->bi_opf & REQ_PRIO) &&
+ !(bio->bi_opf & (REQ_META|REQ_PRIO)) &&
s->iop.c->gc_stats.in_use <
Re: [PATCH v5 5/9] phy: Move Allwinner A31 D-PHY driver to drivers/phy/
Hi, On Mon, 2019-01-21 at 16:45 +0100, Maxime Ripard wrote: > Now that our MIPI D-PHY driver has been converted to the phy framework, > let's move it into the drivers/phy directory. > > Signed-off-by: Maxime Ripard Reviewed-by: Paul Kocialkowski Cheers, Paul > --- > drivers/gpu/drm/sun4i/Kconfig | 10 +- > drivers/gpu/drm/sun4i/Makefile | 1 +- > drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 318 +- > drivers/phy/allwinner/Kconfig | 12 +- > drivers/phy/allwinner/Makefile | 1 +- > drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 318 +- > 6 files changed, 332 insertions(+), 328 deletions(-) > delete mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c > create mode 100644 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c > > diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig > index 2b8db82c4bab..1dbbc3a1b763 100644 > --- a/drivers/gpu/drm/sun4i/Kconfig > +++ b/drivers/gpu/drm/sun4i/Kconfig > @@ -45,20 +45,12 @@ config DRM_SUN6I_DSI > default MACH_SUN8I > select CRC_CCITT > select DRM_MIPI_DSI > - select DRM_SUN6I_DPHY > + select PHY_SUN6I_MIPI_DPHY > help > Choose this option if you want have an Allwinner SoC with > MIPI-DSI support. If M is selected the module will be called > sun6i_mipi_dsi. > > -config DRM_SUN6I_DPHY > - tristate "Allwinner A31 MIPI D-PHY Support" > - select GENERIC_PHY_MIPI_DPHY > - help > - Choose this option if you have an Allwinner SoC with > - MIPI-DSI support. If M is selected, the module will be > - called sun6i_mipi_dphy. > - > config DRM_SUN8I_DW_HDMI > tristate "Support for Allwinner version of DesignWare HDMI" > depends on DRM_SUN4I > diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile > index 1e2320d824b5..0d04f2447b01 100644 > --- a/drivers/gpu/drm/sun4i/Makefile > +++ b/drivers/gpu/drm/sun4i/Makefile > @@ -34,7 +34,6 @@ ifdef CONFIG_DRM_SUN4I_BACKEND > obj-$(CONFIG_DRM_SUN4I) += sun4i-frontend.o > endif > obj-$(CONFIG_DRM_SUN4I_HDMI) += sun4i-drm-hdmi.o > -obj-$(CONFIG_DRM_SUN6I_DPHY) += sun6i_mipi_dphy.o > obj-$(CONFIG_DRM_SUN6I_DSI) += sun6i_mipi_dsi.o > obj-$(CONFIG_DRM_SUN8I_DW_HDMI) += sun8i-drm-hdmi.o > obj-$(CONFIG_DRM_SUN8I_MIXER)+= sun8i-mixer.o > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c > b/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c > deleted file mode 100644 > index 79c8af5c7c1d.. > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c > +++ /dev/null > @@ -1,318 +0,0 @@ > -// SPDX-License-Identifier: GPL-2.0+ > -/* > - * Copyright (c) 2016 Allwinnertech Co., Ltd. > - * Copyright (C) 2017-2018 Bootlin > - * > - * Maxime Ripard > - */ > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -#include > -#include > - > -#define SUN6I_DPHY_GCTL_REG 0x00 > -#define SUN6I_DPHY_GCTL_LANE_NUM(n) n) - 1) & 3) << 4) > -#define SUN6I_DPHY_GCTL_EN BIT(0) > - > -#define SUN6I_DPHY_TX_CTL_REG0x04 > -#define SUN6I_DPHY_TX_CTL_HS_TX_CLK_CONT BIT(28) > - > -#define SUN6I_DPHY_TX_TIME0_REG 0x10 > -#define SUN6I_DPHY_TX_TIME0_HS_TRAIL(n) (((n) & 0xff) << 24) > -#define SUN6I_DPHY_TX_TIME0_HS_PREPARE(n)(((n) & 0xff) << 16) > -#define SUN6I_DPHY_TX_TIME0_LP_CLK_DIV(n)((n) & 0xff) > - > -#define SUN6I_DPHY_TX_TIME1_REG 0x14 > -#define SUN6I_DPHY_TX_TIME1_CLK_POST(n) (((n) & 0xff) << 24) > -#define SUN6I_DPHY_TX_TIME1_CLK_PRE(n) (((n) & 0xff) << 16) > -#define SUN6I_DPHY_TX_TIME1_CLK_ZERO(n) (((n) & 0xff) << 8) > -#define SUN6I_DPHY_TX_TIME1_CLK_PREPARE(n) ((n) & 0xff) > - > -#define SUN6I_DPHY_TX_TIME2_REG 0x18 > -#define SUN6I_DPHY_TX_TIME2_CLK_TRAIL(n) ((n) & 0xff) > - > -#define SUN6I_DPHY_TX_TIME3_REG 0x1c > - > -#define SUN6I_DPHY_TX_TIME4_REG 0x20 > -#define SUN6I_DPHY_TX_TIME4_HS_TX_ANA1(n)(((n) & 0xff) << 8) > -#define SUN6I_DPHY_TX_TIME4_HS_TX_ANA0(n)((n) & 0xff) > - > -#define SUN6I_DPHY_ANA0_REG 0x4c > -#define SUN6I_DPHY_ANA0_REG_PWS BIT(31) > -#define SUN6I_DPHY_ANA0_REG_DMPC BIT(28) > -#define SUN6I_DPHY_ANA0_REG_DMPD(n) (((n) & 0xf) << 24) > -#define SUN6I_DPHY_ANA0_REG_SLV(n) (((n) & 7) << 12) > -#define SUN6I_DPHY_ANA0_REG_DEN(n) (((n) & 0xf) << 8) > - > -#define SUN6I_DPHY_ANA1_REG 0x50 > -#define SUN6I_DPHY_ANA1_REG_VTTMODE BIT(31) > -#define SUN6I_DPHY_ANA1_REG_CSMPS(n) (((n) & 3) << 28) > -#define SUN6I_DPHY_ANA1_REG_SVTT(n) (((n) & 0xf) << 24) > - > -#define SUN6I_DPHY_ANA2_REG 0x54 > -#define SUN6I_DPHY_ANA2_EN_P2S_CPU(n)(((n) & 0xf) << 24) > -#define SUN6I_DPHY_ANA2_EN_P2S_CPU_MASK
Re: bcache on XFS: metadata I/O (dirent I/O?) not getting cached at all?
On 2019/2/7 11:10 上午, Dave Chinner wrote: > On Thu, Feb 07, 2019 at 10:38:58AM +0800, Coly Li wrote: >> On 2019/2/7 10:26 上午, Dave Chinner wrote: >>> On Thu, Feb 07, 2019 at 01:24:25AM +0100, Andre Noll wrote: On Thu, Feb 07, 10:43, Dave Chinner wrote > File data readahead: REQ_RAHEAD > Metadata readahead: REQ_META | REQ_RAHEAD > > drivers/md/bcache/request.c::check_should_bypass(): > > /* > * Flag for bypass if the IO is for read-ahead or background, > * unless the read-ahead request is for metadata (eg, for gfs2). > */ > if (bio->bi_opf & (REQ_RAHEAD|REQ_BACKGROUND) && > !(bio->bi_opf & REQ_PRIO)) > goto skip; > > bcache needs fixing - it thinks REQ_PRIO means metadata IO. That's > wrong - REQ_META means it's metadata IO, and so this is a bcache > bug. Do you think 752f66a75abad is bad (ha!) and should be reverted? >>> >>> Yes, that change is just broken. From include/linux/blk_types.h: >>> >>> __REQ_META, /* metadata io request */ >>> __REQ_PRIO, /* boost priority in cfq */ >>> >>> >> >> Hi Dave, >> >>> i.e. REQ_META means that it is a metadata request, REQ_PRIO means it >>> is a "high priority" request. Two completely different things, often >>> combined, but not interchangeable. >> >> I found in file system metadata IO, most of time REQ_META and REQ_PRIO >> are tagged together for bio, but XFS seems not use REQ_PRIO. > > Yes, that's correct, because we don't specifically prioritise > metadata IO over data IO. > >> Is there any basic principle for when should these tags to be used or >> not ? > > Yes. > >> e.g. If REQ_META is enough for meta data I/O, why REQ_PRIO is used >> too. > > REQ_META is used for metadata. REQ_PRIO is used to communicate to > the lower layers that the submitter considers this IO to be more > important that non REQ_PRIO IO and so dispatch should be expedited. > > IOWs, if the filesystem considers metadata IO to be more important > that user data IO, then it will use REQ_PRIO | REQ_META rather than > just REQ_META. > > Historically speaking, REQ_PRIO was a hack for CFQ to get it to > dispatch journal IO from a different thread without waiting for a > time slice to expire. In the XFs world, we just said "don't use CFQ, > it's fundametnally broken for highly concurrent applications" and > didn't bother trying to hack around the limitations of CFQ. > > These days REQ_PRIO is only used by the block layer writeback > throttle, but unlike bcache it considers both REQ_META and REQ_PRIO > to mean the same thing. > > REQ_META, OTOH, is used by BFQ and blk-cgroup to detect metadata > IO and don't look at REQ_PRIO at all. So, really, REQ_META is for > metadata, not REQ_PRIO. REQ_PRIO looks like it should just go away. > >> And if REQ_PRIO is necessary, why it is not used in fs/xfs/ code ? > > It's not necessary, it's just an /optimisation/ that some > filesystems make and some IO schedulers used to pay attention to. It > looks completely redundant now. Hi Dave, Thanks for your detailed explanation. This is great hint from view of file system developer :-) I just compose a fix, hope it makes better. -- Coly Li
Re: [PATCH] Input: tm2-touchkey - acknowledge that setting brightness is a blocking call
Hi Dmitry, On Wed, Feb 06, 2019 at 10:16:16AM -0800, Dmitry Torokhov wrote: > We need to access I2C bus when switching brightness, and that may block, > therefore we have to set stmfts_brightness_set() as LED's > brightness_set_blocking() method. > > Signed-off-by: Dmitry Torokhov same here: Acked-by: Andi Shyti Thanks, Andi
Re: [PATCH v5 2/2] pwm: sifive: Add a driver for SiFive SoC PWM
On Wed, Feb 6, 2019 at 6:14 PM Thierry Reding wrote:
>
> On Tue, Jan 29, 2019 at 05:13:19PM +0530, Yash Shah wrote:
> [...]
> > diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
> [...]
> > +static void pwm_sifive_update_clock(struct pwm_sifive_ddata *pwm,
> > + unsigned long rate)
> > +{
> > + /* (1 << (16+scale)) * 10^9/rate = real_period */
> > + unsigned long scale_pow =
> > + (pwm->approx_period * (u64)rate) / NSEC_PER_SEC;
>
> I think you need another div64_ul() for this one to fix the linker error
> that the 0-day builder was pointing out.
Yes, will fix this. Thanks for pointing it out.
>
> Thierry
Re: Regression due to "PM-runtime: Switch autosuspend over to using hrtimers"
Hi,
Thank for the quick response.
On Wed, Feb 6, 2019 at 6:59 PM Vincent Guittot
wrote:
>
> Hi Gilad,
>
> On Wed, 6 Feb 2019 at 17:40, Gilad Ben-Yossef wrote:
> >
> > Hi all,
> >
> > A regression was spotted in the ccree driver running on Arm 32 bit
> > causing a kernel panic during the crypto API self test phase (panic
> > messages included with this message) happening in the PM resume
> > callback that was not happening before.
> >
> > I've bisected the change that caused this to commit 8234f6734c5d
> > ("PM-runtime: Switch autosuspend over to using hrtimers").
> >
> > I'm still trying to figure out what is going on inside the callback,
> > but as it was not happening before, I thought I'd give you a shout out
> > to make you aware of this.
>
> Are you using autosuspend mode for this device ?
Yes.
> Also this happen in a platform specific function cc_init_hash_sram().
> I can't see anything related to pm runtime and autosuspend in it.
True. However, the function is called from the driver PM resume
callback and before that commit it did not fail.
My guess is that there is something related to the timing the callback
is called, probably some race condition the change exposed.
There is probably nothing for you do until I figure out what is
failing in the internal function.
I just wanted to give the heads up in case someone else runs into a
similar issue with another driver.
> Do you have more details about where this panic happen in the function ?
I'm looking into this right now and will update.
Thanks!
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
values of β will give rise to dom!
Re: [PATCH] reset: Don't WARN if trying to get a used reset control
On Wed, Feb 06, 2019 at 07:12:04PM +0100, Philipp Zabel wrote: > On Wed, 2019-02-06 at 17:00 +0100, Thierry Reding wrote: [...] > > That way we operate on the same reset control, but we wouldn't need to > > iterate over all existing reset controls in order to determine whether > > we can acquire or not. > > How could we decide in reset_control_assert whether the provided rstc is > allowed to change the reset line if both rstc handles point to the same > struct reset_control? The idea was that acquire/release would basically act as lock/unlock for the reset control. So consumers would always have to call acquire() before assert()/deassert()/reset() and they would be allowed to continue only if acquire() returns success. Of course that's something you can only enforce during code review, but that's pretty much the same as with any type of locking. So basically the idea is that if a consumers acquire() call succeeds, the acquired flag gets set on the reset control and that consumer becomes the only user allowed to modify the reset control. Any other consumers would call acquire() and fail because the acquired is already true. But what you proposed works for me. We can always find constructive ways to optimize this later if we need or want to. Another possibility would be to keep an additional, separate list of the temporarily exclusive resets so that only that list would have to be iterated to find the ones that are relevant. > > > if (WARN_ON(!rstc->shared || !shared)) > > > return ERR_PTR(-EBUSY); > > > > With the above I think we could just extend this list of conditions with > > > > || acquired > > > > and things should work the same. Or perhaps I'm missing something. > > > > Other than that this really looks like a very nice solution. > > Well, apart from the API function names... > devm_reset_control_get_optional_exclusive_released(dev, "id"); > would be a mouthful. Yeah, the combinations are somewhat awkward. However, I would expect the temporarily exclusive resets to be required in most cases, so that would at least make the name a little shorter. Thierry signature.asc Description: PGP signature
Re: [PATCH] xhci: Convert xhci_handshake() to use readl_poll_timeout()
On 07.02.2019 02:03, Andrey Smirnov wrote: Xhci_handshake() implements the algorithm already captured by readl_poll_timeout(). Convert the former to use the latter to avoid repetition. readl_poll_timeout() doesn't really work here as it might sleep. iopoll.h: /** * readx_poll_timeout - Periodically poll an address until a condition is met or a timeout occurs * ... * Returns 0 on success and -ETIMEDOUT upon a timeout. In either * case, the last read value at @addr is stored in @val. Must not * be called from atomic context if sleep_us or timeout_us are used. -Mathias
[GIT PULL] sound fixes for 5.0-rc6
Linus,
please pull sound fixes for v5.0-rc6 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-5.0-rc6
The topmost commit is c97617a81a7616d49bc3700959e08c6c6f447093
sound fixes for 5.0-rc6
A collection of a few small fixes. The most significant one is the
fix for the possible race at loading HD-audio drivers. This has been
present for long time and surfaced only in a rare occasion, but
finally spotted out.
The rest are usual device-specific fixes for HD-audio and USB-audio.
Charles Keepax (1):
ALSA: compress: Fix stop handling on compressed capture streams
Jeremy Soller (1):
ALSA: hda/realtek - Headset microphone support for System76 darp5
Kailang Yang (1):
ALSA: hda/realtek - Fix lose hp_pins for disable auto mute
Takashi Iwai (3):
ALSA: hda/realtek - Use a common helper for hp pin reference
ALSA: hda - Serialize codec registrations
ALSA: hda/ca0132 - Fix build error without CONFIG_PCI
Udo Eberhardt (1):
ALSA: usb-audio: Add support for new T+A USB DAC
---
include/sound/compress_driver.h | 6 +++-
include/sound/hda_codec.h | 1 +
sound/pci/hda/hda_bind.c| 3 +-
sound/pci/hda/hda_intel.c | 2 ++
sound/pci/hda/patch_ca0132.c| 4 ++-
sound/pci/hda/patch_realtek.c | 62 +++--
sound/usb/quirks.c | 1 +
7 files changed, 49 insertions(+), 30 deletions(-)
diff --git a/include/sound/compress_driver.h b/include/sound/compress_driver.h
index 0cdc3999ecfa..c5188ff724d1 100644
--- a/include/sound/compress_driver.h
+++ b/include/sound/compress_driver.h
@@ -173,7 +173,11 @@ static inline void snd_compr_drain_notify(struct
snd_compr_stream *stream)
if (snd_BUG_ON(!stream))
return;
- stream->runtime->state = SNDRV_PCM_STATE_SETUP;
+ if (stream->direction == SND_COMPRESS_PLAYBACK)
+ stream->runtime->state = SNDRV_PCM_STATE_SETUP;
+ else
+ stream->runtime->state = SNDRV_PCM_STATE_PREPARED;
+
wake_up(>runtime->sleep);
}
diff --git a/include/sound/hda_codec.h b/include/sound/hda_codec.h
index 7fa48b100936..cc7c8d42d4fd 100644
--- a/include/sound/hda_codec.h
+++ b/include/sound/hda_codec.h
@@ -68,6 +68,7 @@ struct hda_bus {
unsigned int response_reset:1; /* controller was reset */
unsigned int in_reset:1;/* during reset operation */
unsigned int no_response_fallback:1; /* don't fallback at RIRB error */
+ unsigned int bus_probing :1;/* during probing process */
int primary_dig_out_type; /* primary digital out PCM type */
unsigned int mixer_assigned;/* codec addr for mixer name */
diff --git a/sound/pci/hda/hda_bind.c b/sound/pci/hda/hda_bind.c
index 9174f1b3a987..1ec706ced75c 100644
--- a/sound/pci/hda/hda_bind.c
+++ b/sound/pci/hda/hda_bind.c
@@ -115,7 +115,8 @@ static int hda_codec_driver_probe(struct device *dev)
err = snd_hda_codec_build_controls(codec);
if (err < 0)
goto error_module;
- if (codec->card->registered) {
+ /* only register after the bus probe finished; otherwise it's racy */
+ if (!codec->bus->bus_probing && codec->card->registered) {
err = snd_card_register(codec->card);
if (err < 0)
goto error_module;
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index e784130ea4e0..e5c49003e75f 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2185,6 +2185,7 @@ static int azx_probe_continue(struct azx *chip)
int dev = chip->dev_index;
int err;
+ to_hda_bus(bus)->bus_probing = 1;
hda->probe_continued = 1;
/* bind with i915 if needed */
@@ -2269,6 +2270,7 @@ static int azx_probe_continue(struct azx *chip)
if (err < 0)
hda->init_failed = 1;
complete_all(>probe_wait);
+ to_hda_bus(bus)->bus_probing = 0;
return err;
}
diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c
index e5bdbc245682..29882bda7632 100644
--- a/sound/pci/hda/patch_ca0132.c
+++ b/sound/pci/hda/patch_ca0132.c
@@ -8451,8 +8451,10 @@ static void ca0132_free(struct hda_codec *codec)
ca0132_exit_chip(codec);
snd_hda_power_down(codec);
- if (IS_ENABLED(CONFIG_PCI) && spec->mem_base)
+#ifdef CONFIG_PCI
+ if (spec->mem_base)
pci_iounmap(codec->bus->pci, spec->mem_base);
+#endif
kfree(spec->spec_init_verbs);
kfree(codec->spec);
}
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 4139aced63f8..6df758adff84 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -515,6 +515,15 @@ static void alc_auto_init_amp(struct hda_codec *codec, int
Re: [PATCH 16/32] x86/vdso: Generate vdso{,32}-timens.lds
On 06/02/2019 01.10, Dmitry Safonov wrote: > As it has been discussed on timens RFC, adding a new conditional branch > `if (inside_time_ns)` on VDSO for all processes is undesirable. > It will add a penalty for everybody as branch predictor may mispredict > the jump. Also there are instruction cache lines wasted on cmp/jmp. > > Those effects of introducing time namespace are very much unwanted > having in mind how much work have been spent on micro-optimisation > vdso code. > > Addressing those problems, there are two versions of VDSO's .so: > for host tasks (without any penalty) and for processes inside of time > namespace with clk_to_ns() that subtracts offsets from host's time. > > Unfortunately, to allow changing VDSO VMA on a running process, > the entry points to VDSO should have the same offsets (addresses). > That's needed as i.e. application that calls setns() may have already > resolved VDSO symbols in GOT/PLT. These (14-19, if I'm reading them right) seems to add quite a lot of complexity and fragility to the build, and other architectures would probably have to add something similar to their vdso builds. I'm wondering why not make the rule be that a timens takes effect on next execve? Rasmus
Re: [GIT PULL] sound fixes for 5.0-rc6
The pull request you sent on Thu, 07 Feb 2019 09:28:22 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > tags/sound-5.0-rc6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6f64e3a4de749575e4705fa53dd49aed28f92623 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 2/3] perf/x86/intel/pt: Inject PMI for KVM guest
On 06/02/19 17:34, Peter Zijlstra wrote:
>
> How about we extend perf_guest_info_callback with an arch section and
> add:
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 5aeb4c74fb99..76ce804e72c1 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -5835,6 +5835,9 @@ struct perf_guest_info_callbacks *perf_guest_cbs;
>
> int perf_register_guest_info_callbacks(struct perf_guest_info_callbacks *cbs)
> {
> + if (WARN_ON_ONCE(perf_guest_cbs))
> + return -EBUSY;
> +
> perf_guest_cbs = cbs;
> return 0;
> }
> @@ -5842,6 +5845,9 @@ EXPORT_SYMBOL_GPL(perf_register_guest_info_callbacks);
>
> int perf_unregister_guest_info_callbacks(struct perf_guest_info_callbacks
> *cbs)
> {
> + if (WARN_ON_ONCE(perf_guest_cbs != cbs))
> + return -EINVAL;
> +
> perf_guest_cbs = NULL;
> return 0;
> }
Makes total sense.
Paolo
Re: [PATCH v5 6/9] drm/bridge: cdns: Separate DSI and D-PHY configuration
Hi,
On Mon, 2019-01-21 at 16:45 +0100, Maxime Ripard wrote:
> The current configuration of the DSI bridge and its associated D-PHY is
> intertwined. In order to ease the future conversion to the phy framework
> for the D-PHY part, let's split the configuration in two.
See below about a silly mistake when refactoring. Looks good otherwise,
so with that fixed:
Reviewed-by: Paul Kocialkowski
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/bridge/cdns-dsi.c | 101 ++-
> 1 file changed, 73 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index ce9496d13986..796874e76308 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -545,6 +545,15 @@ bridge_to_cdns_dsi_input(struct drm_bridge *bridge)
> return container_of(bridge, struct cdns_dsi_input, bridge);
> }
>
> +static unsigned int mode_to_dpi_hfp(const struct drm_display_mode *mode,
> + bool mode_valid_check)
> +{
> + if (mode_valid_check)
> + return mode->hsync_start - mode->hdisplay;
> +
> + return mode->crtc_hsync_start - mode->crtc_hdisplay;
> +}
> +
> static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
>struct cdns_dphy_cfg *cfg,
>unsigned int dpi_htotal,
> @@ -731,14 +740,12 @@ static unsigned int dpi_to_dsi_timing(unsigned int
> dpi_timing,
> static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
>const struct drm_display_mode *mode,
>struct cdns_dsi_cfg *dsi_cfg,
> - struct cdns_dphy_cfg *dphy_cfg,
>bool mode_valid_check)
> {
> - unsigned long dsi_htotal = 0, dsi_hss_hsa_hse_hbp = 0;
> struct cdns_dsi_output *output = >output;
> - unsigned int dsi_hfp_ext = 0, dpi_hfp, tmp;
> + unsigned int tmp;
> bool sync_pulse = false;
> - int bpp, nlanes, ret;
> + int bpp, nlanes;
>
> memset(dsi_cfg, 0, sizeof(*dsi_cfg));
>
> @@ -757,8 +764,6 @@ static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
> mode->crtc_hsync_end : mode->crtc_hsync_start);
>
> dsi_cfg->hbp = dpi_to_dsi_timing(tmp, bpp, DSI_HBP_FRAME_OVERHEAD);
> - dsi_htotal += dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
> - dsi_hss_hsa_hse_hbp += dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
>
> if (sync_pulse) {
> if (mode_valid_check)
> @@ -768,49 +773,91 @@ static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
>
> dsi_cfg->hsa = dpi_to_dsi_timing(tmp, bpp,
>DSI_HSA_FRAME_OVERHEAD);
> - dsi_htotal += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
> - dsi_hss_hsa_hse_hbp += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
> }
>
> dsi_cfg->hact = dpi_to_dsi_timing(mode_valid_check ?
> mode->hdisplay : mode->crtc_hdisplay,
> bpp, 0);
> - dsi_htotal += dsi_cfg->hact;
> + dsi_cfg->hfp = dpi_to_dsi_timing(mode_to_dpi_hfp(mode,
> mode_valid_check),
> + bpp, DSI_HFP_FRAME_OVERHEAD);
>
> - if (mode_valid_check)
> - dpi_hfp = mode->hsync_start - mode->hdisplay;
> - else
> - dpi_hfp = mode->crtc_hsync_start - mode->crtc_hdisplay;
> + return 0;
> +}
> +
> +static int cdns_dphy_validate(struct cdns_dsi *dsi,
> + struct cdns_dsi_cfg *dsi_cfg,
> + struct cdns_dphy_cfg *dphy_cfg,
> + const struct drm_display_mode *mode,
> + bool mode_valid_check)
> +{
> + struct cdns_dsi_output *output = >output;
> + unsigned long dsi_htotal;
> + unsigned int dsi_hfp_ext = 0;
> +
> + int ret;
> +
> + dsi_htotal = dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
> + if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + dsi_htotal += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
>
> - dsi_cfg->hfp = dpi_to_dsi_timing(dpi_hfp, bpp, DSI_HFP_FRAME_OVERHEAD);
> + dsi_htotal += dsi_cfg->hact;
> dsi_htotal += dsi_cfg->hfp + DSI_HFP_FRAME_OVERHEAD;
>
> if (mode_valid_check)
> ret = cdns_dsi_get_dphy_pll_cfg(dsi->dphy, dphy_cfg,
> - mode->htotal, bpp,
> + mode->htotal,
> mode->clock * 1000,
> - dsi_htotal, nlanes,
> +
> mipi_dsi_pixel_format_to_bpp(output->dev->format),
The bpp argument sits between htotal and clock, this puts it after
clock which looks incorrect.
Cheers,
Paul
> +
Re: [PATCH] xhci: Convert xhci_handshake() to use readl_poll_timeout()
Hi, Mathias Nyman writes: > On 07.02.2019 02:03, Andrey Smirnov wrote: >> Xhci_handshake() implements the algorithm already captured by >> readl_poll_timeout(). Convert the former to use the latter to avoid >> repetition. > > readl_poll_timeout() doesn't really work here as it might sleep. > > iopoll.h: > > /** > * readx_poll_timeout - Periodically poll an address until a condition is > met or a timeout occurs > * > ... > > * Returns 0 on success and -ETIMEDOUT upon a timeout. In either > * case, the last read value at @addr is stored in @val. Must not > * be called from atomic context if sleep_us or timeout_us are used. readl_poll_timeout_atomic()? -- balbi signature.asc Description: PGP signature
Re: [PATCH 0/5 v6] Fix virtio-blk issue with SWIOTLB
Hi Michael, On Tue, Feb 05, 2019 at 03:52:38PM -0500, Michael S. Tsirkin wrote: > On Thu, Jan 31, 2019 at 05:33:58PM +0100, Joerg Roedel wrote: > > Changes to v5 are: > > > > - Changed patch 3 to uninline dma_max_mapping_size() > > And this lead to problems reported by kbuild :( Hmm, I didn't get any kbuild emails for this series. Can you please forward it me so that I can look into it? > BTW when you repost, can I ask you to pls include > the version in all patches? Both --subject-prefix > and -v flags to git format-patch will do this for you. Will do, thanks. Regards, Joerg
Re: [PATCH 0/5 v6] Fix virtio-blk issue with SWIOTLB
On Thu, Feb 07, 2019 at 09:46:13AM +0100, Joerg Roedel wrote: > Hmm, I didn't get any kbuild emails for this series. Can you please > forward it me so that I can look into it? Nevermind, just found them in another inbox. Joerg
Re: [PATCH v2 0/4] Add max77620 charging & low battery support
On Tue, 29 Jan 2019, Mark Zhang wrote: > This patch set adds support for max77620 backup battery charging and > low battery monitoring. > > Changes in v2: > - Add devicetree binding documentation > > Mark Zhang (4): > mfd: max77620: Add backup battery charger support > mfd: max77620: add documentation for backup battery charging > mfd: max77620: Add low battery monitor support > mfd: max77620: add documentation for low battery monitoring > > .../devicetree/bindings/mfd/max77620.txt | 34 + > drivers/mfd/max77620.c| 137 +- All of this needs moving out to the correct subsystem. drivers/power/supply/max77620-battery.c looks right. > 2 files changed, 170 insertions(+), 1 deletion(-) -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: linux-next: manual merge of the tegra tree with the imx-mxs tree
On Thu, Feb 07, 2019 at 09:51:42AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tegra tree got a conflict in:
>
> arch/arm64/configs/defconfig
>
> between commit:
>
> 9bd01e74c715 ("arm64: defconfig: Add i.MX8MQ boot necessary configs")
>
> from the imx-mxs tree and commit:
>
> bc72bed682a9 ("arm64: defconfig: Enable Tegra TCU")
>
> from the tegra tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm64/configs/defconfig
> index e82bc8cf1253,ad8f3dea0a74..
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@@ -323,8 -319,7 +323,9 @@@ CONFIG_SERIAL_MESON_CONSOLE=
> CONFIG_SERIAL_SAMSUNG=y
> CONFIG_SERIAL_SAMSUNG_CONSOLE=y
> CONFIG_SERIAL_TEGRA=y
> + CONFIG_SERIAL_TEGRA_TCU=y
> +CONFIG_SERIAL_IMX=y
> +CONFIG_SERIAL_IMX_CONSOLE=y
> CONFIG_SERIAL_SH_SCI=y
> CONFIG_SERIAL_MSM=y
> CONFIG_SERIAL_MSM_CONSOLE=y
Looks good to me.
Thierry
signature.asc
Description: PGP signature
Re: [PATCH] gpu: host1x: Use direct DMA with IOMMU API usage
On Wed, Feb 06, 2019 at 02:08:33PM -0800, Guenter Roeck wrote: > On Fri, Feb 01, 2019 at 02:28:26PM +0100, Thierry Reding wrote: > > If we use the IOMMU API directly to map buffers into host1x' IOVA space, > > we must make sure that the DMA API doesn't already set up a mapping, or > > else translation will fail. > > > > The direct DMA API allows us to allocate memory that will not be mapped > > through an IOMMU automatically. > > > > Reviewed-by: Dmitry Osipenko > > Signed-off-by: Thierry Reding > > arm64:defconfig: > > ERROR: "dma_direct_free" [drivers/gpu/host1x/host1x.ko] undefined! > ERROR: "dma_direct_alloc" [drivers/gpu/host1x/host1x.ko] undefined! Hi Guenter, I sent out a fix to export dma_direct_alloc() and dma_direct_free() but Christoph preferred not to merge that, so I'm currently working on a different solution for this. I hope to have a fix for this by the end of the day, but if not I'll back out the above commit. Thanks, Thierry signature.asc Description: PGP signature
Re: [PATCH v3 1/2] media: docs-rst: Document memory-to-memory video decoder interface
On Thu, Jan 31, 2019 at 10:19 PM Hans Verkuil wrote: > > On 1/31/19 1:44 PM, Philipp Zabel wrote: > > On Thu, 2019-01-31 at 13:30 +0100, Hans Verkuil wrote: > >> On 1/31/19 11:45 AM, Hans Verkuil wrote: > >>> On 1/24/19 11:04 AM, Tomasz Figa wrote: > Due to complexity of the video decoding process, the V4L2 drivers of > stateful decoder hardware require specific sequences of V4L2 API calls > to be followed. These include capability enumeration, initialization, > decoding, seek, pause, dynamic resolution change, drain and end of > stream. > > Specifics of the above have been discussed during Media Workshops at > LinuxCon Europe 2012 in Barcelona and then later Embedded Linux > Conference Europe 2014 in Düsseldorf. The de facto Codec API that > originated at those events was later implemented by the drivers we > already > have merged in mainline, such as s5p-mfc or coda. > > The only thing missing was the real specification included as a part of > Linux Media documentation. Fix it now and document the decoder part of > the Codec API. > > Signed-off-by: Tomasz Figa > --- > Documentation/media/uapi/v4l/dev-decoder.rst | 1076 + > Documentation/media/uapi/v4l/dev-mem2mem.rst |5 + > Documentation/media/uapi/v4l/pixfmt-v4l2.rst |5 + > Documentation/media/uapi/v4l/v4l2.rst | 10 +- > .../media/uapi/v4l/vidioc-decoder-cmd.rst | 40 +- > Documentation/media/uapi/v4l/vidioc-g-fmt.rst | 14 + > 6 files changed, 1135 insertions(+), 15 deletions(-) > create mode 100644 Documentation/media/uapi/v4l/dev-decoder.rst > > >>> > >>> > >>> > +4. **This step only applies to coded formats that contain resolution > information > +in the stream.** Continue queuing/dequeuing bitstream buffers > to/from the > +``OUTPUT`` queue via :c:func:`VIDIOC_QBUF` and > :c:func:`VIDIOC_DQBUF`. The > +buffers will be processed and returned to the client in order, until > +required metadata to configure the ``CAPTURE`` queue are found. > This is > +indicated by the decoder sending a ``V4L2_EVENT_SOURCE_CHANGE`` > event with > +``V4L2_EVENT_SRC_CH_RESOLUTION`` source change type. > + > +* It is not an error if the first buffer does not contain enough > data for > + this to occur. Processing of the buffers will continue as long as > more > + data is needed. > + > +* If data in a buffer that triggers the event is required to decode > the > + first frame, it will not be returned to the client, until the > + initialization sequence completes and the frame is decoded. > + > +* If the client sets width and height of the ``OUTPUT`` format to 0, > + calling :c:func:`VIDIOC_G_FMT`, :c:func:`VIDIOC_S_FMT`, > + :c:func:`VIDIOC_TRY_FMT` or :c:func:`VIDIOC_REQBUFS` on the > ``CAPTURE`` > + queue will return the ``-EACCES`` error code, until the decoder > + configures ``CAPTURE`` format according to stream metadata. > >>> > >>> I think this should also include the G/S_SELECTION ioctls, right? > >> > >> I've started work on adding compliance tests for codecs to v4l2-compliance > >> and > >> I quickly discovered that this 'EACCES' error code is not nice at all. > >> > >> The problem is that it is really inconsistent with V4L2 behavior: the basic > >> rule is that there always is a format defined, i.e. G_FMT will always > >> return > >> a format. > >> > >> Suddenly returning an error is actually quite painful to handle because it > >> is > >> a weird exception just for the capture queue of a stateful decoder if no > >> output resolution is known. > >> > >> Just writing that sentence is painful. > >> > >> Why not just return some default driver defined format? It will > >> automatically > >> be updated once the decoder parsed the bitstream and knows the new > >> resolution. > >> > >> It really is just the same behavior as with a resolution change. > >> > >> It is also perfectly fine to request buffers for the capture queue for that > >> default format. It's pointless, but not a bug. > >> > >> Unless I am missing something I strongly recommend changing this behavior. > > > > I just wrote the same in my reply to Nicolas, the CODA driver currently > > sets the capture queue width/height to the output queue's crop rectangle > > (rounded to macroblock size) without ever having seen the SPS. > > And thinking about the initial 0x0 width/height for the output queue: > > that too is an exception, although less of a problem than the EACCES behavior. > > It should be fine for an application to set width/height to 0 when calling > S_FMT for the output queue of the decoder, but I would also prefer that it is > just replaced by the driver with some
Re: I've been waiting for your answer
I am waiting to hear from you about the message I sent you. Mr. Joseph
Re: [PATCH] irqchip/i8259: fix shutdown order by moving syscore_ops registration
[Adding the MIPS folks]
On 06/02/2019 21:26, Aaro Koskinen wrote:
> When using cpufreq on Loongson 2F MIPS platform, "poweroff"
> command gets frequently stuck in syscore_shutdown(). The reason is
> that i8259A_shutdown() gets called before cpufreq_suspend(), and if we
> have pending work then irq_work_sync() in cpufreq_dbs_governor_stop()
> gets stuck forever as we have all interrupts masked already.
>
> irq-i8259 is registering syscore_ops using device_initcall(),
> while cpufreq uses core_initcall(). Fix the shutdown order simply
> by registering the irq syscore_ops during the early IRQ init instead
> of using a separate initcall at later stage.
>
> Signed-off-by: Aaro Koskinen
> ---
> drivers/irqchip/irq-i8259.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/irqchip/irq-i8259.c b/drivers/irqchip/irq-i8259.c
> index b0d4aab1a58c..d000870d9b6b 100644
> --- a/drivers/irqchip/irq-i8259.c
> +++ b/drivers/irqchip/irq-i8259.c
> @@ -225,14 +225,6 @@ static struct syscore_ops i8259_syscore_ops = {
> .shutdown = i8259A_shutdown,
> };
>
> -static int __init i8259A_init_sysfs(void)
> -{
> - register_syscore_ops(_syscore_ops);
> - return 0;
> -}
> -
> -device_initcall(i8259A_init_sysfs);
> -
> static void init_8259A(int auto_eoi)
> {
> unsigned long flags;
> @@ -332,6 +324,7 @@ struct irq_domain * __init __init_i8259_irqs(struct
> device_node *node)
> panic("Failed to add i8259 IRQ domain");
>
> setup_irq(I8259A_IRQ_BASE + PIC_CASCADE_IR, );
> + register_syscore_ops(_syscore_ops);
> return domain;
> }
>
>
Given that this is a change of behaviour that is likely to affect other
platforms (I see at least another 6 MIPS machines using the i8259),
could someone make sure that this doesn't cause any regression? This is
unlikely to affect the SGI boxes, as they predate any notion of power
management, but something like Malta could potentially be affected.
Please let me know.
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH] cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer
Hi Sobon,
On Tue, 5 Feb 2019 22:28:44 +
"Sobon, Przemyslaw" wrote:
> > From: Boris Brezillon
> > Sent: Sunday, February 3, 2019 12:35 AM
> > > +Przemyslaw
> > >
> > > On Fri, 1 Feb 2019 07:30:39 +0800
> > > Liu Jian wrote:
> > >
> > > > In function do_write_buffer(), in the for loop, there is a case
> > > > chip_ready() returns 1 while chip_good() returns 0, so it never
> > > > break the loop.
> > > > To fix this, chip_good() is enough and it should timeout if it stay
> > > > bad for a while.
> > >
> > > Looks like Przemyslaw reported and fixed the same problem.
> > >
> > > >
> > > > Fixes: dfeae1073583(mtd: cfi_cmdset_0002: Change write buffer to
> > > > check correct value)
> > >
> > > Can you put the Fixes tag on a single, and the format is
> > >
> > > Fixes: ("message")
> > >
> > > > Signed-off-by: Yi Huaijie
> > > > Signed-off-by: Liu Jian
> > >
> > > [1]http://patchwork.ozlabs.org/patch/1025566/
> > >
> > > > ---
> > > > drivers/mtd/chips/cfi_cmdset_0002.c | 6 +++---
> > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
> > > > b/drivers/mtd/chips/cfi_cmdset_0002.c
> > > > index 72428b6..818e94b 100644
> > > > --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> > > > +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> > > > @@ -1876,14 +1876,14 @@ static int __xipram do_write_buffer(struct
> > > > map_info *map, struct flchip *chip,
> > > > continue;
> > > > }
> > > >
> > > > - if (time_after(jiffies, timeo) && !chip_ready(map, adr))
> > > > - break;
> > > > -
> > > > if (chip_good(map, adr, datum)) {
> > > > xip_enable(map, chip, adr);
> > > > goto op_done;
> > > > }
> > > >
> > > > + if (time_after(jiffies, timeo))
> > > > + break;
> > > > +
> > > > /* Latency issues. Drop the lock, wait a while and
> > > > retry */
> > > > UDELAY(map, chip, adr, 1);
> > > > }
> > >
> >
> > BTW, the patch itself looks good to me. Ikegami, can you confirm it does
> > the right thing?
> >
> > Thanks,
> >
> > Boris
> >
>
> One comment to this patch. If value is written incorrectly quickly we will be
> stuck in the loop even though nothing is going to change. For example a value
> was
> written incorrectly after 1us, the loop was set to 1ms, function will return
> after 1ms, this solution is not optimized for performance. I considered same
> when working on this change and decided to do it different way.
Seems like you're right if we assume that checking for GOOD state does
not require a delay after the READY check, but if that's not the case
and an extra delay is actually required, you might end up with a BAD
status while it could have turned GOOD at some point with the 'check
only for GOOD state until we timeout' approach.
TBH, I don't know how CFI flashes work, so I'll let you guys sort this
out.
Regards,
Boris
Re: [PATCH] firmware: tegra: Refactor BPMP driver
On Wed, Feb 06, 2019 at 02:17:11PM -0800, Guenter Roeck wrote:
> On Thu, Jan 24, 2019 at 07:03:53PM +0200, Timo Alho wrote:
> > Split BPMP driver into common and chip specific parts to facilitate
> > adding support for previous and future Tegra chips that are using BPMP
> > as co-processor.
> >
> > Signed-off-by: Timo Alho
> > Acked-by: Jon Hunter
> > Signed-off-by: Thierry Reding
>
> arm:allmodconfig in linux-next:
>
> drivers/firmware/tegra/bpmp.o:(.rodata+0x280): undefined reference to
> `tegra210_bpmp_ops'
> drivers/firmware/tegra/bpmp.o:(.rodata+0x2ac): undefined reference to
> `tegra186_bpmp_ops'
Hi Guenter,
this should be fixed by the below patch. Running build tests now.
Thierry
--- >8 ---
diff --git a/drivers/firmware/tegra/bpmp-private.h
b/drivers/firmware/tegra/bpmp-private.h
index 07c3d46abb87..cc343f4ebafb 100644
--- a/drivers/firmware/tegra/bpmp-private.h
+++ b/drivers/firmware/tegra/bpmp-private.h
@@ -23,7 +23,11 @@ struct tegra_bpmp_ops {
int (*resume)(struct tegra_bpmp *bpmp);
};
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_186_SOC)
extern const struct tegra_bpmp_ops tegra186_bpmp_ops;
+#endif
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
extern const struct tegra_bpmp_ops tegra210_bpmp_ops;
+#endif
#endif
diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 8e3f79959d48..6498c848c82c 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -813,6 +813,7 @@ static int __maybe_unused tegra_bpmp_resume(struct device
*dev)
static SIMPLE_DEV_PM_OPS(tegra_bpmp_pm_ops, NULL, tegra_bpmp_resume);
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_186_SOC)
static const struct tegra_bpmp_soc tegra186_soc = {
.channels = {
.cpu_tx = {
@@ -832,7 +833,9 @@ static const struct tegra_bpmp_soc tegra186_soc = {
.ops = _bpmp_ops,
.num_resets = 193,
};
+#endif
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
static const struct tegra_bpmp_soc tegra210_soc = {
.channels = {
.cpu_tx = {
@@ -853,10 +856,15 @@ static const struct tegra_bpmp_soc tegra210_soc = {
},
.ops = _bpmp_ops,
};
+#endif
static const struct of_device_id tegra_bpmp_match[] = {
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_186_SOC)
{ .compatible = "nvidia,tegra186-bpmp", .data = _soc },
+#endif
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
{ .compatible = "nvidia,tegra210-bpmp", .data = _soc },
+#endif
{ }
};
signature.asc
Description: PGP signature
Re: [PATCH] xhci: Use ffs() to find page size in xhci_mem_init()
On 07.02.2019 02:03, Andrey Smirnov wrote:
Get page size order using ffs() instead of open coding it with a loop.
Signed-off-by: Andrey Smirnov
Cc: Mathias Nyman
Cc: Greg Kroah-Hartman
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/usb/host/xhci-mem.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 36a3eb8849f1..44b43c3d819f 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2362,11 +2362,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
page_size = readl(>op_regs->page_size);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Supported page size register = 0x%x", page_size);
- for (i = 0; i < 16; i++) {
- if ((0x1 & page_size) != 0)
- break;
- page_size = page_size >> 1;
- }
+ i = ffs(page_size);
if (i < 16)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Supported page size of %iK", (1 << (i+12)) / 1024);
Hi
using ffs() is a welcome change, but it will give different a result than the
loop.
*old loop
valid page_size value if i < 16
*ffs()
valid page_size value if i >= 1 and i < 17
-Mathias
Re: linux-next: manual merge of the tegra tree with the imx-mxs tree
On 19-02-07 09:51:42, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tegra tree got a conflict in:
>
> arch/arm64/configs/defconfig
>
> between commit:
>
> 9bd01e74c715 ("arm64: defconfig: Add i.MX8MQ boot necessary configs")
>
> from the imx-mxs tree and commit:
>
> bc72bed682a9 ("arm64: defconfig: Enable Tegra TCU")
>
> from the tegra tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm64/configs/defconfig
> index e82bc8cf1253,ad8f3dea0a74..
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@@ -323,8 -319,7 +323,9 @@@ CONFIG_SERIAL_MESON_CONSOLE=
> CONFIG_SERIAL_SAMSUNG=y
> CONFIG_SERIAL_SAMSUNG_CONSOLE=y
> CONFIG_SERIAL_TEGRA=y
> + CONFIG_SERIAL_TEGRA_TCU=y
> +CONFIG_SERIAL_IMX=y
> +CONFIG_SERIAL_IMX_CONSOLE=y
> CONFIG_SERIAL_SH_SCI=y
> CONFIG_SERIAL_MSM=y
> CONFIG_SERIAL_MSM_CONSOLE=y
Looks fine to me.
Abel
Re: [PATCH] xhci: Use ffs() to find page size in xhci_mem_init()
Hi,
Mathias Nyman writes:
> On 07.02.2019 02:03, Andrey Smirnov wrote:
>> Get page size order using ffs() instead of open coding it with a loop.
>>
>> Signed-off-by: Andrey Smirnov
>> Cc: Mathias Nyman
>> Cc: Greg Kroah-Hartman
>> Cc: linux-...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>> drivers/usb/host/xhci-mem.c | 6 +-
>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
>> index 36a3eb8849f1..44b43c3d819f 100644
>> --- a/drivers/usb/host/xhci-mem.c
>> +++ b/drivers/usb/host/xhci-mem.c
>> @@ -2362,11 +2362,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
>> page_size = readl(>op_regs->page_size);
>> xhci_dbg_trace(xhci, trace_xhci_dbg_init,
>> "Supported page size register = 0x%x", page_size);
>> -for (i = 0; i < 16; i++) {
>> -if ((0x1 & page_size) != 0)
>> -break;
>> -page_size = page_size >> 1;
>> -}
>> +i = ffs(page_size);
>> if (i < 16)
>> xhci_dbg_trace(xhci, trace_xhci_dbg_init,
>> "Supported page size of %iK", (1 << (i+12)) / 1024);
>
> Hi
>
> using ffs() is a welcome change, but it will give different a result than the
> loop.
>
> *old loop
>valid page_size value if i < 16
> *ffs()
>valid page_size value if i >= 1 and i < 17
off-by-one, just use i = ffs() - 1. Or use __ffs().
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v3 5/5] Revert "scsi: ufs: disable vccq if it's not needed by UFS device"
Hi Marc, On 06/02/19 9:22 PM, Marc Gonzalez wrote: > On 06/02/2019 16:27, Alim Akhtar wrote: > >> On 06/02/19 8:29 PM, Marc Gonzalez wrote: >> >>> [2.405734] regulator_disable: ENTER vdd_l26 >>> [2.405958] regulator_disable: EXIT vdd_l26 >>> [2.406032] regulator_set_load: vdd_l26 = 0 uA >>> [3.930447] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr: opcode 0x04 >>> for idn 13 failed, index 0, err = -11 >>> [5.434358] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr: opcode 0x04 >>> for idn 13 failed, index 0, err = -11 >>> [6.938318] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr: opcode 0x04 >>> for idn 13 failed, index 0, err = -11 >>> [6.938414] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr_retry: query >>> attribute, idn 13, failed with error -11 after 3 retires >>> [6.946959] ufshcd-qcom 1da4000.ufshc: ufshcd_disable_auto_bkops: failed >>> to enable exception event -11 >>> [6.958523] ufshcd-qcom 1da4000.ufshc: dme-peer-get: attr-id 0x1587 >>> failed 3 retries >>> [6.967730] ufshcd-qcom 1da4000.ufshc: dme-peer-get: attr-id 0x1586 >>> failed 3 retries >>> [6.975576] ufshcd-qcom 1da4000.ufshc: ufshcd_get_max_pwr_mode: invalid >>> max pwm tx gear read = 0 >>> [6.983306] ufshcd-qcom 1da4000.ufshc: ufshcd_probe_hba: Failed getting >>> max supported power mode >>> [8.506314] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending flag >>> query for idn 3 failed, err = -11 >>> [ 10.010352] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending flag >>> query for idn 3 failed, err = -11 >>> [ 11.514313] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending flag >>> query for idn 3 failed, err = -11 >>> [ 11.514412] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag_retry: query >>> attribute, opcode 5, idn 3, failed with error -11 after 3 retires >>> [ 13.050354] ufshcd-qcom 1da4000.ufshc: __ufshcd_query_descriptor: opcode >>> 0x01 for idn 8 failed, index 0, err = -11 >>> [ 14.554313] ufshcd-qcom 1da4000.ufshc: __ufshcd_query_descriptor: opcode >>> 0x01 for idn 8 failed, index 0, err = -11 >>> [ 16.058313] ufshcd-qcom 1da4000.ufshc: __ufshcd_query_descriptor: opcode >>> 0x01 for idn 8 failed, index 0, err = -11 >>> [ 16.058421] ufshcd-qcom 1da4000.ufshc: ufshcd_read_desc_param: Failed >>> reading descriptor. desc_id 8, desc_index 0, param_offset 0, ret -11 >>> [ 16.067654] ufshcd-qcom 1da4000.ufshc: ufshcd_init_icc_levels: Failed >>> reading power descriptor.len = 98 ret = -11 >>> [ 37.074334] ufshcd-qcom 1da4000.ufshc: link startup failed 1 >> >> Can you check if your UFS device RESET_N is asserted correctly. It might >> be connected to some regulator and may be you can try keeping that >> regulator as "regulator-always-on" from your DT node. > > How do I check RESET_N? In software or hardware? > RST_N is the reset logic for UFS device core logic and it is input to the device from UFS host controller.So, in your platform please check if this line somehow connected to (pulled up) a PMIC supply. If that is the case, please keep that regulator ON and see if this issue is resolved. > Do you think it is not a good idea to revert > 60f0187031c05e04cbadffb62f557d0ff3564490 ? > Please hold on till we understand the real cause of this issue. Or we have a consensuses for reverting the said commit. Thanks! > Regards. > >
Re: [PATCH 1/6] mfd: mt6397: extract irq related code from core driver
On Wed, 30 Jan 2019, Hsin-Hsiung Wang wrote:
> In order to support different types of irq design,
> we decide to add separate irq drivers for different
> design and keep mt6397 mfd core simple and reusable
> to all generations of PMICs so far.
Why have you cut these lines so short?
In all cases:
s/irq/IRQ/
s/mfd/MFD
s/mt6397/MT6397/
> Signed-off-by: Hsin-Hsiung Wang
> ---
> drivers/mfd/Makefile| 2 +-
> drivers/mfd/mt6397-core.c | 235
> +++-
> drivers/mfd/mt6397-irq.c| 214
> include/linux/mfd/mt6397/core.h | 12 ++
> 4 files changed, 265 insertions(+), 198 deletions(-)
> create mode 100644 drivers/mfd/mt6397-irq.c
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 12980a4..088e249 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -230,7 +230,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI)+= intel_soc_pmic_chtdc_ti.o
> -obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> +obj-$(CONFIG_MFD_MT6397) += mt6397-core.o mt6397-irq.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> obj-$(CONFIG_MFD_SUN4I_GPADC)+= sun4i-gpadc.o
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 77b64bd..a72524d 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -12,23 +12,19 @@
> * GNU General Public License for more details.
> */
>
> -#include
> #include
> #include
> #include
> #include
> #include
> -#include
> #include
> -#include
> +#include
> #include
> +#include
I will ignore these unrelated changes!
> #define MT6397_RTC_BASE 0xe000
> #define MT6397_RTC_SIZE 0x3e
>
> -#define MT6323_CID_CODE 0x23
> -#define MT6391_CID_CODE 0x91
> -#define MT6397_CID_CODE 0x97
CID_CODE is a bit cryptic.
Why not use *_CHIP_ID instead?
[...]
> +static const struct chip_data mt6323_core = {
> + .cid_addr = MT6323_CID,
> +};
Does the chip ID address change from device to device?
If not, you can get rid of all of this hoop jumping.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2] powerpc/mm: move a KERN_WARNING message to pr_debug()
On 07/02/2019 05:33, Michael Ellerman wrote:
> Hi Laurent,
>
> I'm not sure I'm convinced about this one. It seems like we're just
> throwing away the warning because it's annoying.
>
> Laurent Vivier writes:
>> resize_hpt_for_hotplug() reports a warning when it cannot
>> increase the hash page table ("Unable to resize hash page
>> table to target order") but this is not blocking and
>> can make user thinks something has not worked properly.
>
> Something did not work properly, the resize didn't work properly. Right?
>
>> As we move the message to the debug area, report again the
>> ENODEV error.
>>
>> If the operation cannot be done the real error message
>> will be reported by arch_add_memory() if create_section_mapping()
>> fails.
>
> Can you explain that more. Isn't the fact that the resize failed "the
> real error message"?
In arch_add_memory(), after calling resize_hpt_for_hotplug() it calls
create_section_mapping() and if create_section_mapping() fails we will
have the error message "Unable to create mapping for hot added memory"
and the real exit (EFAULT).
>
>> Fixes: 7339390d772dd
>>powerpc/pseries: Don't give a warning when HPT resizing isn't
>> available
>
> This should all be on one line, and formatted as:
>
> Fixes: 7339390d772d ("powerpc/pseries: Don't give a warning when HPT resizing
> isn't available")
>
> See Documentation/process/submitting-patches.rst for more info and how
> to configure git to do it automatically for you.
Thank you, I didn't know the format was documented.
Thanks,
Laurent
Hey nice to meet you here.
Hey nice to meet you here and how you today?. I'm Dino,54 years widowed and operator from Maryland USA. Where you from?. I like to know you and also share something on trust with you here meanwhile, Are you a Christian, Muslim or Jewish? Dino.
Re: [PATCH v5 0/9] phy: Add configuration interface for MIPI D-PHY devices
Hi Kishon, On Wed, Feb 06, 2019 at 06:00:19PM +0530, Kishon Vijay Abraham I wrote: > On 06/02/19 5:55 PM, Maxime Ripard wrote: > > On Wed, Feb 06, 2019 at 05:43:12PM +0530, Kishon Vijay Abraham I wrote: > >> On 05/02/19 2:16 PM, Daniel Vetter wrote: > >>> On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote: > > > On 21/01/19 9:15 PM, Maxime Ripard wrote: > > Hi, > > > > Here is a set of patches to allow the phy framework consumers to test > > and > > apply runtime configurations. > > > > This is needed to support more phy classes that require tuning based on > > parameters depending on the current use case of the device, in addition > > to > > the power state management already provided by the current functions. > > > > A first test bed for that API are the MIPI D-PHY devices. There's a > > number > > of solutions that have been used so far to support these phy, most of > > the > > time being an ad-hoc driver in the consumer. > > > > That approach has a big shortcoming though, which is that this is quite > > difficult to deal with consumers integrated with multiple variants of > > phy, > > of multiple consumers integrated with the same phy. > > > > The latter case can be found in the Cadence DSI bridge, and the CSI > > transceiver and receivers. All of them are integrated with the same > > phy, or > > can be integrated with different phy, depending on the implementation. > > > > I've looked at all the MIPI DSI drivers I could find, and gathered all > > the > > parameters I could find. The interface should be complete, and most of > > the > > drivers can be converted in the future. The current set converts two of > > them: the above mentionned Cadence DSI driver so that the v4l2 drivers > > can > > use them, and the Allwinner MIPI-DSI driver. > > Can the PHY changes go independently of the consumer drivers? or else > I'll need > ACKs from the GPU MAINTAINER. > >>> > >>> Maxime is a gpu maintainer, so you're all good :-) > >> > >> cool.. I've merged all the patches except drm/bridge. > >> > >> Please see if everything looks okay once it shows up in phy -next (give a > >> day) > > > > Thanks! > > > > If possible (and if that's still an option), it would be better if the > > sun6i related patches (patches 4 and 5) would go through the DRM tree > > (with your Acked-by of course). > > > > We have a number of patches in flight that have a decent chance to > > conflict with patch 4. > > Sure. Dropped patches 4 and 5 from my tree. Thanks! I've pushed the rest into drm-misc. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH v5 6/9] drm/bridge: cdns: Separate DSI and D-PHY configuration
On Thu, Feb 07, 2019 at 09:44:46AM +0100, Paul Kocialkowski wrote: > Hi, > > On Mon, 2019-01-21 at 16:45 +0100, Maxime Ripard wrote: > > The current configuration of the DSI bridge and its associated D-PHY is > > intertwined. In order to ease the future conversion to the phy framework > > for the D-PHY part, let's split the configuration in two. > > See below about a silly mistake when refactoring. Looks good otherwise, > so with that fixed: > > Reviewed-by: Paul Kocialkowski I've fixed it while applying, thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH v4 1/3] mtd: rawnand: atmel: fix possible object reference leak
Hi Wen,
Wen Yang wrote on Thu, 7 Feb 2019
03:50:55 +:
> of_find_device_by_node() takes a reference to the struct device
> when it finds a match via get_device, there is no need to call
> get_device() twice.
> We also should make sure to drop the reference to the device
> taken by of_find_device_by_node() on driver unbind.
>
> Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
> Signed-off-by: Wen Yang
> Suggested-by: Boris Brezillon
Suggested-by means that Boris suggested you to write this patch in the
first place. If he just made a review, you should drop this tag.
> Reviewed-by: Boris Brezillon
> Reviewed-by: Miquel Raynal
None of us gave our Reviewed-by officially, so you can drop these lines.
> Acked-by: Miquel Raynal
I gave my Acked-by because I though Boris would take the patch, but
actually he will not, so you can drop the Ack.
> Cc: Tudor Ambarus
> Cc: Boris Brezillon
> Cc: Miquel Raynal
> Cc: Richard Weinberger
> Cc: David Woodhouse
> Cc: Brian Norris
> Cc: Marek Vasut
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: linux-...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
Please add people in Cc when you send the series and remove all these
Cc: lines.
> ---
> v4->v3: Avoid two times of calling grtform_get_drvdata()
> v3->v2: Change the commit message.
> v2->v1: Add missing Fixes tag
>
> drivers/mtd/nand/raw/atmel/pmecc.c | 21 +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/atmel/pmecc.c
> b/drivers/mtd/nand/raw/atmel/pmecc.c
> index 555a74e..9d39978 100644
> --- a/drivers/mtd/nand/raw/atmel/pmecc.c
> +++ b/drivers/mtd/nand/raw/atmel/pmecc.c
> @@ -876,23 +876,32 @@ static struct atmel_pmecc
> *atmel_pmecc_get_by_node(struct device *userdev,
> {
> struct platform_device *pdev;
> struct atmel_pmecc *pmecc, **ptr;
> + int ret;
>
> pdev = of_find_device_by_node(np);
> - if (!pdev || !platform_get_drvdata(pdev))
> + if (!pdev)
> return ERR_PTR(-EPROBE_DEFER);
New line missing here
> + pmecc = platform_get_drvdata(pdev);
> + if (!pmecc) {
> + ret = -EPROBE_DEFER;
> + goto err_put_device;
> + }
>
> ptr = devres_alloc(devm_atmel_pmecc_put, sizeof(*ptr), GFP_KERNEL);
> - if (!ptr)
> - return ERR_PTR(-ENOMEM);
> -
> - get_device(>dev);
> - pmecc = platform_get_drvdata(pdev);
> + if (!ptr) {
> + ret = -ENOMEM;
> + goto err_put_device;
> + }
>
> *ptr = pmecc;
>
> devres_add(userdev, ptr);
>
> return pmecc;
> +
> +err_put_device:
> + put_device(>dev);
> + return ERR_PTR(ret);
> }
>
> static const int atmel_pmecc_strengths[] = { 2, 4, 8, 12, 24, 32 };
All the comments apply to the two other patches.
Otherwise looks good.
Thanks,
Miquèl
[PATCH v3 6/7] pinctrl: at91: add slewrate support for SAM9X60
From: Claudiu Beznea
Add slew rate support for SAM9X60 pin controller.
Signed-off-by: Claudiu Beznea
Acked-by: Ludovic Desroches
---
drivers/pinctrl/pinctrl-at91.c | 48 ++
drivers/pinctrl/pinctrl-at91.h | 1 +
include/dt-bindings/pinctrl/at91.h | 4
3 files changed, 53 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 5456a2692b8c..2c6d3b61951f 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -59,6 +59,9 @@ static int gpio_banks;
#define OUTPUT (1 << 7)
#define OUTPUT_VAL_SHIFT 8
#define OUTPUT_VAL (0x1 << OUTPUT_VAL_SHIFT)
+#define SLEWRATE_SHIFT 9
+#define SLEWRATE_MASK 0x1
+#define SLEWRATE (SLEWRATE_MASK << SLEWRATE_SHIFT)
#define DEBOUNCE (1 << 16)
#define DEBOUNCE_VAL_SHIFT 17
#define DEBOUNCE_VAL (0x3fff << DEBOUNCE_VAL_SHIFT)
@@ -82,6 +85,13 @@ enum drive_strength_bit {
#define DRIVE_STRENGTH_BIT_MSK(name) (DRIVE_STRENGTH_BIT_##name << \
DRIVE_STRENGTH_SHIFT)
+enum slewrate_bit {
+ SLEWRATE_BIT_DIS,
+ SLEWRATE_BIT_ENA,
+};
+
+#define SLEWRATE_BIT_MSK(name) (SLEWRATE_BIT_##name << SLEWRATE_SHIFT)
+
/**
* struct at91_pmx_func - describes AT91 pinmux functions
* @name: the name of this specific function
@@ -171,6 +181,8 @@ struct at91_pinctrl_mux_ops {
unsigned (*get_drivestrength)(void __iomem *pio, unsigned pin);
void (*set_drivestrength)(void __iomem *pio, unsigned pin,
u32 strength);
+ unsigned (*get_slewrate)(void __iomem *pio, unsigned pin);
+ void (*set_slewrate)(void __iomem *pio, unsigned pin, u32 slewrate);
/* irq */
int (*irq_type)(struct irq_data *d, unsigned type);
};
@@ -585,6 +597,16 @@ static unsigned at91_mux_sam9x60_get_drivestrength(void
__iomem *pio,
return DRIVE_STRENGTH_BIT_LOW;
}
+static unsigned at91_mux_sam9x60_get_slewrate(void __iomem *pio, unsigned pin)
+{
+ unsigned tmp = readl_relaxed(pio + SAM9X60_PIO_SLEWR);
+
+ if ((tmp & BIT(pin)))
+ return SLEWRATE_BIT_ENA;
+
+ return SLEWRATE_BIT_DIS;
+}
+
static void set_drive_strength(void __iomem *reg, unsigned pin, u32 strength)
{
unsigned tmp = readl_relaxed(reg);
@@ -643,6 +665,24 @@ static void at91_mux_sam9x60_set_drivestrength(void
__iomem *pio, unsigned pin,
writel_relaxed(tmp, pio + SAM9X60_PIO_DRIVER1);
}
+static void at91_mux_sam9x60_set_slewrate(void __iomem *pio, unsigned pin,
+ u32 setting)
+{
+ unsigned int tmp;
+
+ if (setting < SLEWRATE_BIT_DIS || setting > SLEWRATE_BIT_ENA)
+ return;
+
+ tmp = readl_relaxed(pio + SAM9X60_PIO_SLEWR);
+
+ if (setting == SLEWRATE_BIT_DIS)
+ tmp &= ~BIT(pin);
+ else
+ tmp |= BIT(pin);
+
+ writel_relaxed(tmp, pio + SAM9X60_PIO_SLEWR);
+}
+
static struct at91_pinctrl_mux_ops at91rm9200_ops = {
.get_periph = at91_mux_get_periph,
.mux_A_periph = at91_mux_set_A_periph,
@@ -687,6 +727,8 @@ static const struct at91_pinctrl_mux_ops sam9x60_ops = {
.disable_schmitt_trig = at91_mux_pio3_disable_schmitt_trig,
.get_drivestrength = at91_mux_sam9x60_get_drivestrength,
.set_drivestrength = at91_mux_sam9x60_set_drivestrength,
+ .get_slewrate = at91_mux_sam9x60_get_slewrate,
+ .set_slewrate = at91_mux_sam9x60_set_slewrate,
.irq_type = alt_gpio_irq_type,
};
@@ -950,6 +992,8 @@ static int at91_pinconf_get(struct pinctrl_dev *pctldev,
if (info->ops->get_drivestrength)
*config |= (info->ops->get_drivestrength(pio, pin)
<< DRIVE_STRENGTH_SHIFT);
+ if (info->ops->get_slewrate)
+ *config |= (info->ops->get_slewrate(pio, pin) <<
SLEWRATE_SHIFT);
if (at91_mux_get_output(pio, pin, ))
*config |= OUTPUT | (out << OUTPUT_VAL_SHIFT);
@@ -1001,6 +1045,9 @@ static int at91_pinconf_set(struct pinctrl_dev *pctldev,
info->ops->set_drivestrength(pio, pin,
(config & DRIVE_STRENGTH)
>> DRIVE_STRENGTH_SHIFT);
+ if (info->ops->set_slewrate)
+ info->ops->set_slewrate(pio, pin,
+ (config & SLEWRATE) >> SLEWRATE_SHIFT);
} /* for each config */
@@ -1044,6 +1091,7 @@ static void at91_pinconf_dbg_show(struct pinctrl_dev
*pctldev,
DRIVE_STRENGTH_MED);
DBG_SHOW_FLAG_MASKED(DRIVE_STRENGTH, DRIVE_STRENGTH_BIT_MSK(HI),
DRIVE_STRENGTH_HI);
+ DBG_SHOW_FLAG(SLEWRATE);
DBG_SHOW_FLAG(DEBOUNCE);
if (config & DEBOUNCE) {
val = config >> DEBOUNCE_VAL_SHIFT;
diff --git
[PATCH v3 2/7] pinctrl: at91: add drive strength support for SAM9X60
From: Claudiu Beznea
Add drive strength support for SAM9X60 pin controller.
Signed-off-by: Claudiu Beznea
Acked-by: Ludovic Desroches
---
drivers/pinctrl/pinctrl-at91.c | 52 ++
drivers/pinctrl/pinctrl-at91.h | 2 ++
2 files changed, 54 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 31f06dafca2e..46443b97d811 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -574,6 +574,17 @@ static unsigned at91_mux_sam9x5_get_drivestrength(void
__iomem *pio,
return tmp;
}
+static unsigned at91_mux_sam9x60_get_drivestrength(void __iomem *pio,
+ unsigned pin)
+{
+ unsigned tmp = readl_relaxed(pio + SAM9X60_PIO_DRIVER1);
+
+ if (tmp & BIT(pin))
+ return DRIVE_STRENGTH_BIT_HI;
+
+ return DRIVE_STRENGTH_BIT_LOW;
+}
+
static void set_drive_strength(void __iomem *reg, unsigned pin, u32 strength)
{
unsigned tmp = readl_relaxed(reg);
@@ -611,6 +622,27 @@ static void at91_mux_sam9x5_set_drivestrength(void __iomem
*pio, unsigned pin,
setting);
}
+static void at91_mux_sam9x60_set_drivestrength(void __iomem *pio, unsigned pin,
+ u32 setting)
+{
+ unsigned int tmp;
+
+ if (setting <= DRIVE_STRENGTH_BIT_DEF ||
+ setting == DRIVE_STRENGTH_BIT_MED ||
+ setting > DRIVE_STRENGTH_BIT_HI)
+ return;
+
+ tmp = readl_relaxed(pio + SAM9X60_PIO_DRIVER1);
+
+ /* Strength is 0: low, 1: hi */
+ if (setting == DRIVE_STRENGTH_BIT_LOW)
+ tmp &= ~BIT(pin);
+ else
+ tmp |= BIT(pin);
+
+ writel_relaxed(tmp, pio + SAM9X60_PIO_DRIVER1);
+}
+
static struct at91_pinctrl_mux_ops at91rm9200_ops = {
.get_periph = at91_mux_get_periph,
.mux_A_periph = at91_mux_set_A_periph,
@@ -639,6 +671,26 @@ static struct at91_pinctrl_mux_ops at91sam9x5_ops = {
.irq_type = alt_gpio_irq_type,
};
+static const struct at91_pinctrl_mux_ops sam9x60_ops = {
+ .get_periph = at91_mux_pio3_get_periph,
+ .mux_A_periph = at91_mux_pio3_set_A_periph,
+ .mux_B_periph = at91_mux_pio3_set_B_periph,
+ .mux_C_periph = at91_mux_pio3_set_C_periph,
+ .mux_D_periph = at91_mux_pio3_set_D_periph,
+ .get_deglitch = at91_mux_pio3_get_deglitch,
+ .set_deglitch = at91_mux_pio3_set_deglitch,
+ .get_debounce = at91_mux_pio3_get_debounce,
+ .set_debounce = at91_mux_pio3_set_debounce,
+ .get_pulldown = at91_mux_pio3_get_pulldown,
+ .set_pulldown = at91_mux_pio3_set_pulldown,
+ .get_schmitt_trig = at91_mux_pio3_get_schmitt_trig,
+ .disable_schmitt_trig = at91_mux_pio3_disable_schmitt_trig,
+ .get_drivestrength = at91_mux_sam9x60_get_drivestrength,
+ .set_drivestrength = at91_mux_sam9x60_set_drivestrength,
+ .irq_type = alt_gpio_irq_type,
+
+};
+
static struct at91_pinctrl_mux_ops sama5d3_ops = {
.get_periph = at91_mux_pio3_get_periph,
.mux_A_periph = at91_mux_pio3_set_A_periph,
diff --git a/drivers/pinctrl/pinctrl-at91.h b/drivers/pinctrl/pinctrl-at91.h
index 79b957f1dfa2..19fc27e66bfd 100644
--- a/drivers/pinctrl/pinctrl-at91.h
+++ b/drivers/pinctrl/pinctrl-at91.h
@@ -69,4 +69,6 @@
#define AT91SAM9X5_PIO_DRIVER1 0x114 /*PIO Driver 1 register offset*/
#define AT91SAM9X5_PIO_DRIVER2 0x118 /*PIO Driver 2 register offset*/
+#define SAM9X60_PIO_DRIVER10x118 /* PIO Driver 1 register offset */
+
#endif
--
2.7.4
[PATCH v3 7/7] dt-bindings: add documentation for slew rate
From: Claudiu Beznea Add documentation for slew rate. Signed-off-by: Claudiu Beznea Acked-by: Ludovic Desroches --- Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt index c2d51ed86d47..19c255346a49 100644 --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt @@ -100,6 +100,7 @@ DRIVE_STRENGTH (3 << 5): indicate the drive strength of the pin using the 11 - High OUTPUT (1 << 7): indicate this pin need to be configured as an output. OUTPUT_VAL (1 << 8): output val (1 = high, 0 = low) +SLEWRATE (1 << 9): slew rate of the pin: 0 = disable, 1 = enable DEBOUNCE (1 << 16): indicate this pin needs debounce. DEBOUNCE_VAL (0x3fff << 17): debounce value. -- 2.7.4
[PATCH v3 1/7] pinctrl: at91: add option to use drive strength bits
From: Claudiu Beznea
SAM9X60 uses high and low drive strengths. To implement this, in
at91_pinctrl_mux_ops::set_drivestrength and
at91_pinctrl_mux_ops::get_drivestrength we need bit numbers of
drive strengths (1 for low, 2 for high), thus change the code to
allow the usage of drive strength bit numbers.
Signed-off-by: Claudiu Beznea
Acked-by: Ludovic Desroches
---
drivers/pinctrl/pinctrl-at91.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 3d49bbbcdbc7..31f06dafca2e 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -72,10 +72,15 @@ static int gpio_banks;
* DRIVE_STRENGTH_DEFAULT is just a placeholder to avoid changing the drive
* strength when there is no dt config for it.
*/
-#define DRIVE_STRENGTH_DEFAULT (0 << DRIVE_STRENGTH_SHIFT)
-#define DRIVE_STRENGTH_LOW (1 << DRIVE_STRENGTH_SHIFT)
-#define DRIVE_STRENGTH_MED (2 << DRIVE_STRENGTH_SHIFT)
-#define DRIVE_STRENGTH_HI (3 << DRIVE_STRENGTH_SHIFT)
+enum drive_strength_bit {
+ DRIVE_STRENGTH_BIT_DEF,
+ DRIVE_STRENGTH_BIT_LOW,
+ DRIVE_STRENGTH_BIT_MED,
+ DRIVE_STRENGTH_BIT_HI,
+};
+
+#define DRIVE_STRENGTH_BIT_MSK(name) (DRIVE_STRENGTH_BIT_##name << \
+DRIVE_STRENGTH_SHIFT)
/**
* struct at91_pmx_func - describes AT91 pinmux functions
@@ -551,7 +556,7 @@ static unsigned at91_mux_sama5d3_get_drivestrength(void
__iomem *pio,
/* SAMA5 strength is 1:1 with our defines,
* except 0 is equivalent to low per datasheet */
if (!tmp)
- tmp = DRIVE_STRENGTH_LOW;
+ tmp = DRIVE_STRENGTH_BIT_MSK(LOW);
return tmp;
}
@@ -564,7 +569,7 @@ static unsigned at91_mux_sam9x5_get_drivestrength(void
__iomem *pio,
/* strength is inverse in SAM9x5s hardware with the pinctrl defines
* hardware: 0 = hi, 1 = med, 2 = low, 3 = rsvd */
- tmp = DRIVE_STRENGTH_HI - tmp;
+ tmp = DRIVE_STRENGTH_BIT_MSK(HI) - tmp;
return tmp;
}
@@ -600,7 +605,7 @@ static void at91_mux_sam9x5_set_drivestrength(void __iomem
*pio, unsigned pin,
/* strength is inverse on SAM9x5s with our defines
* 0 = hi, 1 = med, 2 = low, 3 = rsvd */
- setting = DRIVE_STRENGTH_HI - setting;
+ setting = DRIVE_STRENGTH_BIT_MSK(HI) - setting;
set_drive_strength(pio + at91sam9x5_get_drive_register(pin), pin,
setting);
@@ -959,11 +964,11 @@ static int at91_pinconf_set(struct pinctrl_dev *pctldev,
} \
} while (0)
-#define DBG_SHOW_FLAG_MASKED(mask,flag) do { \
+#define DBG_SHOW_FLAG_MASKED(mask, flag, name) do { \
if ((config & mask) == flag) { \
if (num_conf) \
seq_puts(s, "|"); \
- seq_puts(s, #flag); \
+ seq_puts(s, #name); \
num_conf++; \
} \
} while (0)
@@ -981,9 +986,12 @@ static void at91_pinconf_dbg_show(struct pinctrl_dev
*pctldev,
DBG_SHOW_FLAG(PULL_DOWN);
DBG_SHOW_FLAG(DIS_SCHMIT);
DBG_SHOW_FLAG(DEGLITCH);
- DBG_SHOW_FLAG_MASKED(DRIVE_STRENGTH, DRIVE_STRENGTH_LOW);
- DBG_SHOW_FLAG_MASKED(DRIVE_STRENGTH, DRIVE_STRENGTH_MED);
- DBG_SHOW_FLAG_MASKED(DRIVE_STRENGTH, DRIVE_STRENGTH_HI);
+ DBG_SHOW_FLAG_MASKED(DRIVE_STRENGTH, DRIVE_STRENGTH_BIT_MSK(LOW),
+DRIVE_STRENGTH_LOW);
+ DBG_SHOW_FLAG_MASKED(DRIVE_STRENGTH, DRIVE_STRENGTH_BIT_MSK(MED),
+DRIVE_STRENGTH_MED);
+ DBG_SHOW_FLAG_MASKED(DRIVE_STRENGTH, DRIVE_STRENGTH_BIT_MSK(HI),
+DRIVE_STRENGTH_HI);
DBG_SHOW_FLAG(DEBOUNCE);
if (config & DEBOUNCE) {
val = config >> DEBOUNCE_VAL_SHIFT;
--
2.7.4
Re: [PATCH v2] powerpc/mm: move a KERN_WARNING message to pr_debug()
On 07/02/2019 04:03, David Gibson wrote:
> On Tue, Feb 05, 2019 at 09:21:33PM +0100, Laurent Vivier wrote:
>> resize_hpt_for_hotplug() reports a warning when it cannot
>> increase the hash page table ("Unable to resize hash page
>> table to target order") but this is not blocking and
>> can make user thinks something has not worked properly.
>> As we move the message to the debug area, report again the
>> ENODEV error.
>>
>> If the operation cannot be done the real error message
>> will be reported by arch_add_memory() if create_section_mapping()
>> fails.
>>
>> Fixes: 7339390d772dd
>>powerpc/pseries: Don't give a warning when HPT resizing isn't
>> available
>> Signed-off-by: Laurent Vivier
>
> Sorry, I'm pretty dubious about this. It's true that in the case for
> which this bug was filed this is a harmless situation which deserves a
> pr_debug() at most.
>
> But that's not necessarily true in all paths leading to this message.
> It will also trip if we fail to reshrink the HPT after genuinely
> hotunplugging a bunch of memory, in which case failing to release
> expected resources does deserve a warning.
But if there is a real problem this function should return an error and
this error should be managed by the caller.
Moreover, the function that can fail (pseries_lpar_resize_hpt()) has
already a warning for each error case:
ETIMEDOUT: "Unexpected error %d cancelling timed out HPT resize\n"
EIO: "Unexpected error %d from H_RESIZE_HPT_PREPARE\n"
"Unexpected error %d from H_RESIZE_HPT_COMMIT\n
ENOSPC:"Hash collision while resizing HPT\n"
ENODEV has no error message but is already silently ignored.
EINVAL and EPERM have no message but this happens if hcall is not used
correctly and deserve only a pr_debug() I think.
Thanks,
Laurent
[PATCH v3 5/7] dt-bindings: add bindings for SAM9X60
From: Claudiu Beznea Add device tree binding for SAM9X60 pin controller. Signed-off-by: Claudiu Beznea Acked-by: Ludovic Desroches --- Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt index 40e33dfc36fd..c2d51ed86d47 100644 --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt @@ -19,7 +19,7 @@ such as pull-up, multi drive, etc. Required properties for iomux controller: - compatible: "atmel,at91rm9200-pinctrl" or "atmel,at91sam9x5-pinctrl" - or "atmel,sama5d3-pinctrl" + or "atmel,sama5d3-pinctrl" or "microchip,sam9x60-pinctrl" - atmel,mux-mask: array of mask (periph per bank) to describe if a pin can be configured in this periph mode. All the periph and bank need to be describe. @@ -117,7 +117,8 @@ Some requirements for using atmel,at91rm9200-pinctrl binding: 4. The gpio controller must be describe in the pinctrl simple-bus. For each bank the required properties are: -- compatible: "atmel,at91sam9x5-gpio" or "atmel,at91rm9200-gpio" +- compatible: "atmel,at91sam9x5-gpio" or "atmel,at91rm9200-gpio" or + "microchip,sam9x60-gpio" - reg: physical base address and length of the controller's registers - interrupts: interrupt outputs from the controller - interrupt-controller: marks the device node as an interrupt controller -- 2.7.4
[PATCH v3 0/7] add support for SAM9X60 pin controller
From: Claudiu Beznea This series adds drive strenght and slew rate support for SAMX60's pin controller. For drive strenght we could have 2 values: low, high. For slew rate we could have 2 values: enable, disabled. Besides this I took the chance and adapt the documentation for at91 pinctrl driver. Changes in v3: - fix checkpatch.pl warning on DBG_SHOW_FLAG_MASKED() macro in patch 1/7 - add Ack-by tag Changes in v2: - s/microchip,sam9x60-pictrl/microchip,sam9x60-pinctrl in patches 3/7, 5/7 Claudiu Beznea (7): pinctrl: at91: add option to use drive strength bits pinctrl: at91: add drive strength support for SAM9X60 pinctrl: at91: add compatibles for SAM9X60 pin controller dt-bindings: add documentation for banks dt-bindings: add bindings for SAM9X60 pinctrl: at91: add slewrate support for SAM9X60 dt-bindings: add documentation for slew rate .../bindings/pinctrl/atmel,at91-pinctrl.txt| 27 - drivers/pinctrl/pinctrl-at91.c | 134 +++-- drivers/pinctrl/pinctrl-at91.h | 3 + include/dt-bindings/pinctrl/at91.h | 4 + 4 files changed, 155 insertions(+), 13 deletions(-) -- 2.7.4
[PATCH v3 3/7] pinctrl: at91: add compatibles for SAM9X60 pin controller
From: Claudiu Beznea
Add compatibles for SAM9X60 pin controller.
Signed-off-by: Claudiu Beznea
Acked-by: Ludovic Desroches
---
drivers/pinctrl/pinctrl-at91.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 46443b97d811..5456a2692b8c 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -1215,6 +1215,7 @@ static const struct of_device_id at91_pinctrl_of_match[]
= {
{ .compatible = "atmel,sama5d3-pinctrl", .data = _ops },
{ .compatible = "atmel,at91sam9x5-pinctrl", .data = _ops },
{ .compatible = "atmel,at91rm9200-pinctrl", .data = _ops },
+ { .compatible = "microchip,sam9x60-pinctrl", .data = _ops },
{ /* sentinel */ }
};
@@ -1757,6 +1758,7 @@ static const struct gpio_chip at91_gpio_template = {
static const struct of_device_id at91_gpio_of_match[] = {
{ .compatible = "atmel,at91sam9x5-gpio", .data = _ops, },
{ .compatible = "atmel,at91rm9200-gpio", .data = _ops },
+ { .compatible = "microchip,sam9x60-gpio", .data = _ops },
{ /* sentinel */ }
};
--
2.7.4
[PATCH v3 4/7] dt-bindings: add documentation for banks
From: Claudiu Beznea
Add documentation for at91 pin controller banks.
Signed-off-by: Claudiu Beznea
Acked-by: Ludovic Desroches
---
.../bindings/pinctrl/atmel,at91-pinctrl.txt| 23 ++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
index 3e23fece99da..40e33dfc36fd 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
@@ -116,6 +116,18 @@ Some requirements for using atmel,at91rm9200-pinctrl
binding:
configurations by referring to the phandle of that pin configuration node.
4. The gpio controller must be describe in the pinctrl simple-bus.
+For each bank the required properties are:
+- compatible: "atmel,at91sam9x5-gpio" or "atmel,at91rm9200-gpio"
+- reg: physical base address and length of the controller's registers
+- interrupts: interrupt outputs from the controller
+- interrupt-controller: marks the device node as an interrupt controller
+- #interrupt-cells: should be 2; refer to
../interrupt-controller/interrupts.txt
+ for more details.
+- gpio-controller
+- #gpio-cells: should be 2; the first cell is the GPIO number and the second
+ cell specifies GPIO flags as defined in .
+- clocks: bank clock
+
Examples:
pinctrl@f400 {
@@ -125,6 +137,17 @@ pinctrl@f400 {
compatible = "atmel,at91rm9200-pinctrl", "simple-bus";
reg = <0xf400 0x600>;
+ pioA: gpio@f400 {
+ compatible = "atmel,at91sam9x5-gpio";
+ reg = <0xf400 0x200>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH 1>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = < PMC_TYPE_PERIPHERAL 2>;
+ };
+
atmel,mux-mask = <
/*A B */
0x 0xffc00c3b /* pioA */
--
2.7.4
Re: [PATCH] net: stmmac: Variable "val" in function sun8i_dwmac_set_syscon() could be uninitialized
On Wed, Feb 06, 2019 at 09:53:16PM -0800, Yizhuo Zhai wrote:
>
>
> On Wed, Feb 6, 2019 at 9:52 PM Yizhuo Zhai wrote:
> >
> > Thanks, but why initialization matters here? Is performance the main
> > concern?
> >
> > On Wed, Feb 6, 2019 at 8:17 PM David Miller wrote:
> >>
> >> From: Yizhuo
> >> Date: Tue, 5 Feb 2019 14:15:59 -0800
> >>
> >> > @@ -639,9 +639,14 @@ static int sun8i_dwmac_set_syscon(struct
> >> > stmmac_priv *priv)
> >> > struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
> >> > struct device_node *node = priv->device->of_node;
> >> > int ret;
> >> > - u32 reg, val;
> >> > + u32 reg, val = 0;
> >> > +
> >> > + ret = regmap_read(gmac->regmap, SYSCON_EMAC_REG, );
> >> > + if (ret) {
> >> > + dev_err(priv->device, "Fail to read SYSCON_EMAC_REG.\n");
> >> > + return ret;
> >> > + }
> >>
> >> I agree with the other reviewer that since you check 'ret' the
> >> initialization of
> >> 'val' is no longer needed.
>
> Thanks, but why initialization matters here? Is performance the main
> concern?
Not really, but if we turn this the other way around, why should we do
something that doesn't bring anything?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: bcache on XFS: metadata I/O (dirent I/O?) not getting cached at all?
On Thu, Feb 07, 10:27, Coly Li wrote > If different file system handles metadata flags in unified ways, it is > OK to me to change the code to: !(bio->bi_opf & (REQ_META |REQ_PRIO)). Yes, that's the smallest fix that should also go into 4.19-stable. In the long run, we should try to get rid of the 45 instances of REQ_PRIO. Most users specify REQ_META | REQ_PRIO anyway, which leaves only a few other instances to look at. I think the one in submit_bh_wbc() of fs/buffer.c can just be removed while block/cfq-iosched.c does not use REQ_META at all, so the simple s/REQ_PRIO/REQ_META should be OK. drivers/staging/erofs/data.c is also easy to fix. Best Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
[PATCH][next] ASoC: codecs: jz4725b: fix spelling mistake "Deemphatize" -> "Deemphasize"
From: Colin Ian King
There is a spelling mistake in the SOC_SINGLE control name. Fix this.
Signed-off-by: Colin Ian King
---
sound/soc/codecs/jz4725b.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/jz4725b.c b/sound/soc/codecs/jz4725b.c
index e3dba92f30bd..24b1b23b99c9 100644
--- a/sound/soc/codecs/jz4725b.c
+++ b/sound/soc/codecs/jz4725b.c
@@ -161,7 +161,7 @@ static const struct snd_kcontrol_new
jz4725b_codec_controls[] = {
SOC_SINGLE("Master Playback Switch", JZ4725B_CODEC_REG_CR1,
REG_CR1_DAC_MUTE_OFFSET, 1, 1),
- SOC_SINGLE("Deemphatize Filter Playback Switch",
+ SOC_SINGLE("Deemphasize Filter Playback Switch",
JZ4725B_CODEC_REG_CR2,
REG_CR2_DAC_DEEMP_OFFSET, 1, 0),
--
2.20.1
Re: [PATCH 4/6] mfd: Add support for the MediaTek MT6358 PMIC
Thomas, et al.,
Please could you take a look at this?
I need some IRQ related guidance. TIA.
On Wed, 30 Jan 2019, Hsin-Hsiung Wang wrote:
> This adds support for the MediaTek MT6358 PMIC. This is a
> multifunction device with the following sub modules:
>
> - Regulator
> - RTC
> - Codec
> - Interrupt
>
> It is interfaced to the host controller using SPI interface
> by a proprietary hardware called PMIC wrapper or pwrap.
> MT6358 MFD is a child device of the pwrap.
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> drivers/mfd/Makefile |2 +-
> drivers/mfd/mt6358-irq.c | 236 +
> drivers/mfd/mt6397-core.c| 62 +-
> include/linux/mfd/mt6358/core.h | 158 +++
> include/linux/mfd/mt6358/registers.h | 1926
> ++
> include/linux/mfd/mt6397/core.h |3 +
> 6 files changed, 2385 insertions(+), 2 deletions(-)
> create mode 100644 drivers/mfd/mt6358-irq.c
> create mode 100644 include/linux/mfd/mt6358/core.h
> create mode 100644 include/linux/mfd/mt6358/registers.h
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 088e249..50be021 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -230,7 +230,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI)+= intel_soc_pmic_chtdc_ti.o
> -obj-$(CONFIG_MFD_MT6397) += mt6397-core.o mt6397-irq.o
> +obj-$(CONFIG_MFD_MT6397) += mt6397-core.o mt6397-irq.o mt6358-irq.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> obj-$(CONFIG_MFD_SUN4I_GPADC)+= sun4i-gpadc.o
> diff --git a/drivers/mfd/mt6358-irq.c b/drivers/mfd/mt6358-irq.c
> new file mode 100644
> index 000..b29fdc1
> --- /dev/null
> +++ b/drivers/mfd/mt6358-irq.c
> @@ -0,0 +1,236 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2019 MediaTek Inc.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct irq_top_t mt6358_ints[] = {
> + MT6358_TOP_GEN(BUCK),
> + MT6358_TOP_GEN(LDO),
> + MT6358_TOP_GEN(PSC),
> + MT6358_TOP_GEN(SCK),
> + MT6358_TOP_GEN(BM),
> + MT6358_TOP_GEN(HK),
> + MT6358_TOP_GEN(AUD),
> + MT6358_TOP_GEN(MISC),
> +};
What is a 'top' IRQ?
> +static int parsing_hwirq_to_top_group(unsigned int hwirq)
> +{
> + int top_group;
> +
> + for (top_group = 1; top_group < ARRAY_SIZE(mt6358_ints); top_group++) {
> + if (mt6358_ints[top_group].hwirq_base > hwirq) {
> + top_group--;
> + break;
> + }
> + }
> + return top_group;
> +}
This function is going to need some comments. Why do you start at LDO
instead of the top entry, BUCK?
> +static void pmic_irq_enable(struct irq_data *data)
> +{
> + unsigned int hwirq = irqd_to_hwirq(data);
> + struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
> + struct pmic_irq_data *irq_data = chip->irq_data;
> +
> + irq_data->enable_hwirq[hwirq] = 1;
> +}
I see that you're doing your own caching operations. Is that
required? I think I'm going to stop here and as for some IRQ guy's
input on this.
> +static void pmic_irq_disable(struct irq_data *data)
> +{
> + unsigned int hwirq = irqd_to_hwirq(data);
> + struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
> + struct pmic_irq_data *irq_data = chip->irq_data;
> +
> + irq_data->enable_hwirq[hwirq] = 0;
> +}
> +
> +static void pmic_irq_lock(struct irq_data *data)
> +{
> + struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
> +
> + mutex_lock(>irqlock);
> +}
> +
> +static void pmic_irq_sync_unlock(struct irq_data *data)
> +{
> + unsigned int i, top_gp, en_reg, int_regs, shift;
> + struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
> + struct pmic_irq_data *irq_data = chip->irq_data;
> +
> + for (i = 0; i < irq_data->num_pmic_irqs; i++) {
> + if (irq_data->enable_hwirq[i] ==
> + irq_data->cache_hwirq[i])
> + continue;
> +
> + top_gp = parsing_hwirq_to_top_group(i);
> + int_regs = mt6358_ints[top_gp].num_int_bits / MT6358_REG_WIDTH;
> + en_reg = mt6358_ints[top_gp].en_reg +
> + mt6358_ints[top_gp].en_reg_shift * int_regs;
> + shift = (i - mt6358_ints[top_gp].hwirq_base) % MT6358_REG_WIDTH;
> + regmap_update_bits(chip->regmap, en_reg, 0x1 << shift,
> +irq_data->enable_hwirq[i] << shift);
> + irq_data->cache_hwirq[i] = irq_data->enable_hwirq[i];
> + }
> + mutex_unlock(>irqlock);
> +}
> +
> +static int pmic_irq_set_type(struct irq_data *data, unsigned int type)
> +{
> + return 0;
>
Re: WARNING in enqueue_task_dl
On Mon, Jan 7, 2019 at 5:19 PM Daniel Bristot de Oliveira
wrote:
>
> On 11/19/18 4:32 PM, Juri Lelli wrote:
> > From 9326fd2b20269cffef7290bdc5b8173460d3c870 Mon Sep 17 00:00:00 2001
> > From: Juri Lelli
> > Date: Mon, 19 Nov 2018 16:04:42 +0100
> > Subject: [PATCH] sched/core: Fix PI boosting between RT and DEADLINE
> >
> > syzbot reported the following warning:
> >
> > WARNING: CPU: 1 PID: 6351 at kernel/sched/deadline.c:628
> > enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504
> > PM: Basic memory bitmaps freed
> > Kernel panic - not syncing: panic_on_warn set ...
> > CPU: 1 PID: 6351 Comm: syz-executor0 Not tainted 4.20.0-rc2+ #338
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> >__dump_stack lib/dump_stack.c:77 [inline]
> >dump_stack+0x244/0x39d lib/dump_stack.c:113
> >panic+0x2ad/0x55c kernel/panic.c:188
> >__warn.cold.8+0x20/0x45 kernel/panic.c:540
> >report_bug+0x254/0x2d0 lib/bug.c:186
> >fixup_bug arch/x86/kernel/traps.c:178 [inline]
> >do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
> >do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
> >invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969
> > RIP: 0010:enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504
> > Code: ff 48 8b 8d c8 fe ff ff 48 c1 e6 2a 4c 8b 9d d0 fe ff ff 8b 95 d8 fe
> > ff ff 48 8b 85 e0 fe ff ff e9 16 e4 ff ff e8 16 d0 ea ff <0f> 0b e9 17 f1
> > ff ff 48 8b bd e8 fe ff ff 4c 89 95 c8 fe ff ff 48
> > RSP: 0018:8881ba39fa18 EFLAGS: 00010002
> > RAX: RBX: 8881b9d6c000 RCX: 8881b9d6c278
> > RDX: 8881b9d6c03c RSI: 0002 RDI: 8881daf2d710
> > RBP: 8881ba39fb78 R08: 0001 R09: 8881daf0
> > R10: 001a4d4f1987 R11: 8881daf2db3b R12: 111037473f4e
> > R13: 8881b9d6c2cc R14: 8881daf2ccc0 R15: 8881daf2ccc0
> >enqueue_task+0x184/0x390 kernel/sched/core.c:730
> >__sched_setscheduler+0xe99/0x2190 kernel/sched/core.c:4336
> >sched_setattr kernel/sched/core.c:4394 [inline]
> >__do_sys_sched_setattr kernel/sched/core.c:4570 [inline]
> >__se_sys_sched_setattr kernel/sched/core.c:4549 [inline]
> >__x64_sys_sched_setattr+0x1b2/0x2f0 kernel/sched/core.c:4549
> >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> >entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > RIP: 0033:0x457569
> > Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> > ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > RSP: 002b:7f05ce0a2c78 EFLAGS: 0246 ORIG_RAX: 013a
> > RAX: ffda RBX: 0003 RCX: 00457569
> > RDX: RSI: 2000 RDI:
> > RBP: 0072bfa0 R08: R09:
> > R10: R11: 0246 R12: 7f05ce0a36d4
> > R13: 004c369f R14: 004d5730 R15:
> >
> > At deadline.c:628 we have:
> >
> > 623 static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se)
> > 624 {
> > 625 struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
> > 626 struct rq *rq = rq_of_dl_rq(dl_rq);
> > 627
> > 628 WARN_ON(dl_se->dl_boosted);
> > 629 WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline));
> > [...]
> > }
> >
> > Which means that setup_new_dl_entity() has been called on a task
> > currently boosted. This shouldn't happen though, as setup_new_
> > dl_entity() is only called when the 'dynamic' deadline of the new entity
> > is in the past w.r.t. rq_clock and boosted tasks shouldn't verify this
> > condition.
> >
> > Digging through PI code I noticed that what above might in fact happen
> > if an RT tasks blocks on an rt_mutex hold by a DEADLINE task. In the
> > first branch of boosting conditions we check only if a pi_task 'dynamic'
> > deadline is earlier than mutex holder's and in this case we set mutex
> > holder to be dl_boosted. However, since RT 'dynamic' deadlines are only
> > initialized if such tasks get boosted at some point (or if they become
> > DEADLINE of course), in general RT 'dynamic' deadlines are usually equal
> > to 0 and this verifies the aforementioned condition.
> >
> > Fix it by checking that the potential donor task is actually (even if
> > temporary because in turn boosted) running at DEADLINE priority before
> > using its 'dynamic' deadline value.
> >
> > Reported-by: syzbot+119ba87189432ead0...@syzkaller.appspotmail.com
> > Signed-off-by: Juri Lelli
>
> Reviewed-by: Daniel Bristot de Oliveira
What happened with this patch? I still don't see it in linux-next.
There is a number of reproducers that involve sched_setattr and lead
to dead machines on syzbot:
https://syzkaller.appspot.com/bug?id=0b210638616bb68109e9642158d4c0072770ae1c
[PATCH]perf:Remove P8 HW events which are not supported
This patch is to remove following hardware events
from JSON file which are not supported on POWER8
pm_co_disp_fail
pm_co_tm_sc_footprint
pm_iside_disp
pm_iside_disp_fail
pm_iside_disp_fail_other
pm_iside_mru_touch
pm_l2_castout_mod
pm_l2_castout_shr
pm_l2_dc_inv
pm_l2_disp_all_l2miss
pm_l2_grp_guess_correct
pm_l2_grp_guess_wrong
pm_l2_ic_inv
pm_l2_inst
pm_l2_inst_miss
pm_l2_ld
pm_l2_ld_disp
pm_l2_ld_hit
pm_l2_ld_miss
pm_l2_loc_guess_correct
pm_l2_loc_guess_wrong
pm_l2_rcld_disp
pm_l2_rcld_disp_fail_addr
pm_l2_rcld_disp_fail_other
pm_l2_rcst_disp
pm_l2_rcst_disp_fail_addr
pm_l2_rcst_disp_fail_other
pm_l2_rc_st_done
pm_l2_rty_ld
pm_l2_sn_m_rd_done
pm_l2_sn_m_wr_done
pm_l2_sn_sx_i_done
pm_l2_st_disp
pm_l2_st_hit
pm_l2_sys_guess_correct
pm_l2_sys_guess_wrong
pm_l2_sys_pump
pm_l3_ci_hit
pm_l3_ci_miss
pm_l3_cinj
pm_l3_co
pm_l3_co_lco
pm_l3_grp_guess_correct
pm_l3_grp_guess_wrong_high
pm_l3_grp_guess_wrong_low
pm_l3_hit
pm_l3_l2_co_hit
pm_l3_l2_co_miss
pm_l3_lat_ci_hit
pm_l3_lat_ci_miss
pm_l3_ld_hit
pm_l3_ld_miss
pm_l3_loc_guess_correct
pm_l3_loc_guess_wrong
pm_l3_miss
pm_l3_p0_co_l31
pm_l3_p0_co_mem
pm_l3_p0_co_rty
pm_l3_p0_grp_pump
pm_l3_p0_lco_data
pm_l3_p0_lco_no_data
pm_l3_p0_lco_rty
pm_l3_p0_node_pump
pm_l3_p0_pf_rty
pm_l3_p0_sn_hit
pm_l3_p0_sn_inv
pm_l3_p0_sn_miss
pm_l3_p0_sys_pump
pm_l3_p1_co_l31
pm_l3_p1_co_mem
pm_l3_p1_co_rty
pm_l3_p1_grp_pump
pm_l3_p1_lco_data
pm_l3_p1_lco_no_data
pm_l3_p1_lco_rty
pm_l3_p1_node_pump
pm_l3_p1_pf_rty
pm_l3_p1_sn_hit
pm_l3_p1_sn_inv
pm_l3_p1_sn_miss
pm_l3_p1_sys_pump
pm_l3_pf_hit_l3
pm_l3_sys_guess_correct
pm_l3_sys_guess_wrong
pm_l3_trans_pf
pm_l3_wi0_busy
pm_l3_wi_usage
pm_non_tm_rst_sc
pm_rd_clearing_sc
pm_rd_forming_sc
pm_rd_hit_pf
pm_snp_tm_hit_m
pm_snp_tm_hit_t
pm_st_caused_fail
pm_tm_cam_overflow
pm_tm_cap_overflow
pm_tm_fav_caused_fail
pm_tm_ld_caused_fail
pm_tm_ld_conf
pm_tm_rst_sc
pm_tm_sc_co
pm_tm_st_caused_fail
pm_tm_st_conf
Signed-off-by: Mamatha Inamdar
---
.../perf/pmu-events/arch/powerpc/power8/other.json | 594
1 file changed, 594 deletions(-)
diff --git a/tools/perf/pmu-events/arch/powerpc/power8/other.json
b/tools/perf/pmu-events/arch/powerpc/power8/other.json
index 704302c..9dc2f6b7 100644
--- a/tools/perf/pmu-events/arch/powerpc/power8/other.json
+++ b/tools/perf/pmu-events/arch/powerpc/power8/other.json
@@ -348,18 +348,6 @@
"PublicDescription": ""
},
{,
-"EventCode": "0x517082",
-"EventName": "PM_CO_DISP_FAIL",
-"BriefDescription": "CO dispatch failed due to all CO machines being busy",
-"PublicDescription": ""
- },
- {,
-"EventCode": "0x527084",
-"EventName": "PM_CO_TM_SC_FOOTPRINT",
-"BriefDescription": "L2 did a cleanifdirty CO to the L3 (ie created an SC
line in the L3)",
-"PublicDescription": ""
- },
- {,
"EventCode": "0x3608a",
"EventName": "PM_CO_USAGE",
"BriefDescription": "Continuous 16 cycle(2to1) window where this signals
rotates thru sampling each L2 CO machine busy. PMU uses this wave to then do 16
cyc count to sample total number of machs running",
@@ -1578,36 +1566,12 @@
"PublicDescription": ""
},
{,
-"EventCode": "0x617082",
-"EventName": "PM_ISIDE_DISP",
-"BriefDescription": "All i-side dispatch attempts",
-"PublicDescription": ""
- },
- {,
-"EventCode": "0x627084",
-"EventName": "PM_ISIDE_DISP_FAIL",
-"BriefDescription": "All i-side dispatch attempts that failed due to a
addr collision with another machine",
-"PublicDescription": ""
- },
- {,
-"EventCode": "0x627086",
-"EventName": "PM_ISIDE_DISP_FAIL_OTHER",
-"BriefDescription": "All i-side dispatch attempts that failed due to a
reason other than addrs collision",
-"PublicDescription": ""
- },
- {,
"EventCode": "0x4608e",
"EventName": "PM_ISIDE_L2MEMACC",
"BriefDescription": "valid when first beat of data comes in for an i-side
fetch where data came from mem(or L4)",
"PublicDescription": ""
},
{,
-"EventCode": "0x44608e",
-"EventName": "PM_ISIDE_MRU_TOUCH",
-"BriefDescription": "Iside L2 MRU touch",
-"PublicDescription": ""
- },
- {,
"EventCode": "0x30ac",
"EventName": "PM_ISU_REF_FX0",
"BriefDescription": "FX0 ISU reject",
@@ -1734,222 +1698,36 @@
"PublicDescription": ""
},
{,
-"EventCode": "0x417080",
-"EventName": "PM_L2_CASTOUT_MOD",
-"BriefDescription": "L2 Castouts - Modified (M, Mu, Me)",
-"PublicDescription": ""
- },
- {,
-"EventCode": "0x417082",
-"EventName": "PM_L2_CASTOUT_SHR",
-"BriefDescription": "L2 Castouts - Shared (T, Te, Si, S)",
-"PublicDescription": ""
- },
- {,
"EventCode": "0x27084",
"EventName": "PM_L2_CHIP_PUMP",
"BriefDescription": "RC requests that were local on chip pump attempts",
"PublicDescription": ""
},
{,
-"EventCode": "0x427086",
-"EventName": "PM_L2_DC_INV",
-"BriefDescription": "Dcache invalidates from L2",
-"PublicDescription": ""
- },
-
[PATCH] iio: adc: ads124s08: fix spelling mistake "converions" -> "conversions"
From: Colin Ian King
There is a spelling mistake in several dev_err messages. Fix these.
Signed-off-by: Colin Ian King
---
drivers/iio/adc/ti-ads124s08.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/ti-ads124s08.c b/drivers/iio/adc/ti-ads124s08.c
index c2cf58908fc8..53f17e4f2f23 100644
--- a/drivers/iio/adc/ti-ads124s08.c
+++ b/drivers/iio/adc/ti-ads124s08.c
@@ -232,7 +232,7 @@ static int ads124s_read_raw(struct iio_dev *indio_dev,
ret = ads124s_write_cmd(indio_dev, ADS124S08_START_CONV);
if (ret) {
- dev_err(>spi->dev, "Start converions failed\n");
+ dev_err(>spi->dev, "Start conversions failed\n");
goto out;
}
@@ -246,7 +246,7 @@ static int ads124s_read_raw(struct iio_dev *indio_dev,
ret = ads124s_write_cmd(indio_dev, ADS124S08_STOP_CONV);
if (ret) {
- dev_err(>spi->dev, "Stop converions failed\n");
+ dev_err(>spi->dev, "Stop conversions failed\n");
goto out;
}
@@ -283,12 +283,12 @@ static irqreturn_t ads124s_trigger_handler(int irq, void
*p)
ret = ads124s_write_cmd(indio_dev, ADS124S08_START_CONV);
if (ret)
- dev_err(>spi->dev, "Start ADC converions
failed\n");
+ dev_err(>spi->dev, "Start ADC conversions
failed\n");
buffer[j] = ads124s_read(indio_dev, scan_index);
ret = ads124s_write_cmd(indio_dev, ADS124S08_STOP_CONV);
if (ret)
- dev_err(>spi->dev, "Stop ADC converions
failed\n");
+ dev_err(>spi->dev, "Stop ADC conversions
failed\n");
j++;
}
--
2.20.1
Re: [PATCH 2/3] dt-bindings: phy: ti: Add dt binding documentation for SERDES in AM654x SoC
Rob,
On 21/01/19 12:18 PM, Kishon Vijay Abraham I wrote:
> AM654x has two SERDES instances. Each instance has three input clocks
> (left input, externel reference clock and right input) and two output
> clocks (left output and right output) in addition to a PLL mux clock
> which the SERDES uses for Clock Multiplier Unit (CMU refclock).
> The PLL mux clock can select from one of the three input clocks.
> The right output can select between left input and external reference
> clock while the left output can select between the right input and
> external reference clock.
>
> The left and right input reference clock of SERDES0 and SERDES1
> respectively are connected to the SoC clock. In the case of two lane
> SERDES personality card, the left input of SERDES1 is connected to
> the right output of SERDES0 in a chained fashion.
>
> See section "Reference Clock Distribution" of AM65x Sitara Processors
> TRM (SPRUID7 – April 2018) for more details.
>
> Add dt-binding documentation in order to represent all these different
> configurations in device tree.
>
> Signed-off-by: Kishon Vijay Abraham I
Can you review this patch?
Thanks
Kishon
> ---
> .../devicetree/bindings/phy/ti-phy.txt| 77 +++
> include/dt-bindings/phy/phy-am654-serdes.h| 13
> 2 files changed, 90 insertions(+)
> create mode 100644 include/dt-bindings/phy/phy-am654-serdes.h
>
> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
> b/Documentation/devicetree/bindings/phy/ti-phy.txt
> index 57dfda8a7a1d..fc2fff6b2c37 100644
> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
> @@ -132,3 +132,80 @@ sata_phy: phy@4a096000 {
> syscon-pllreset = <_conf 0x3fc>;
> #phy-cells = <0>;
> };
> +
> +
> +TI AM654 SERDES
> +
> +Required properties:
> + - compatible: Should be "ti,phy-am654-serdes"
> + - reg : Address and length of the register set for the device.
> + - reg-names: Should be "serdes" which corresponds to the register space
> + populated in "reg".
> + - #phy-cells: determine the number of cells that should be given in the
> + phandle while referencing this phy. Should be "2". The 1st cell
> + corresponds to the phy type (should be one of the types specified in
> + include/dt-bindings/phy/phy.h) and the 2nd cell should be the serdes
> + lane function.
> + If SERDES0 is referenced 2nd cell should be:
> + 0 - USB3
> + 1 - PCIe0 Lane0
> + 2 - ICSS2 SGMII Lane0
> + If SERDES1 is referenced 2nd cell should be:
> + 0 - PCIe1 Lane0
> + 1 - PCIe0 Lane1
> + 2 - ICSS2 SGMII Lane1
> + - clocks: List of clock-specifiers representing the input to the SERDES.
> + Should have 3 items representing the left input clock, external
> + reference clock and right input clock in that order.
> + - clock-output-names: List of clock names for each of the clock outputs of
> + SERDES. Should have 3 items for CMU reference clock,
> + left output clock and right output clock in that order.
> + - assigned-clocks: As defined in
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + - assigned-clock-parents: As defined in
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + - #clock-cells: Should be <1> to choose between the 3 output clocks.
> + Defined in Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> + The following macros are defined in dt-bindings/phy/phy-am654-serdes.h
> + for selecting the correct reference clock. This can be used while
> + specifying the clocks created by SERDES.
> + => AM654_SERDES_CMU_REFCLK
> + => AM654_SERDES_LO_REFCLK
> + => AM654_SERDES_RO_REFCLK
> +
> + - mux-controls: phandle to the multiplexer
> +
> +Example:
> +
> +Example for SERDES0 is given below. It has 3 clock inputs;
> +left input reference clock as indicated by <_clks 153 4>, external
> +reference clock as indicated by <_clks 153 1> and right input
> +reference clock as indicated by < AM654_SERDES_LO_REFCLK>. (The
> +right input of SERDES0 is connected to the left output of SERDES1).
> +
> +SERDES0 registers 3 clock outputs as indicated in clock-output-names. The
> +first refers to the CMU reference clock, second refers to the left output
> +reference clock and the third refers to the right output reference clock.
> +
> +The assigned-clocks and assigned-clock-parents is used here to set the
> +parent of left input reference clock to MAINHSDIV_CLKOUT4 and parent of
> +CMU reference clock to left input reference clock.
> +
> +serdes0: serdes@90 {
> + compatible = "ti,phy-am654-serdes";
> + reg = <0x0 0x90 0x0 0x2000>;
> + reg-names = "serdes";
> + #phy-cells = <2>;
> + power-domains = <_pds 153>;
> + clocks = <_clks 153 4>, <_clks 153 1>,
> + < AM654_SERDES_LO_REFCLK>;
> + clock-output-names = "serdes0_cmu_refclk",
Re: bcache on XFS: metadata I/O (dirent I/O?) not getting cached at all?
On Thu, Feb 07, 16:16, Coly Li wrote
> From: Coly Li
> Date: Thu, 7 Feb 2019 15:54:24 +0800
> Subject: [PATCH] bcache: use (REQ_META|REQ_PRIO) to indicate bio for metadata
>
> In 'commit 752f66a75aba ("bcache: use REQ_PRIO to indicate bio for
> metadata")' REQ_META is replaced by REQ_PRIO to indicate metadata bio.
> This assumption is not always correct, e.g. XFS uses REQ_META to mark
> metadata bio other than REQ_PRIO. This is why Nix reports a regression
> that bcache does not cache metadata for XFS after the above commit.
maybe s/reports a regression/noticed
> Thanks to Dave Chinner, he explains the difference between REQ_META and
> REQ_PRIO from view of file system developer. Here I quote part of his
> explanation from mailing list,
>REQ_META is used for metadata. REQ_PRIO is used to communicate to
>the lower layers that the submitter considers this IO to be more
>important that non REQ_PRIO IO and so dispatch should be expedited.
>
>IOWs, if the filesystem considers metadata IO to be more important
>that user data IO, then it will use REQ_PRIO | REQ_META rather than
>just REQ_META.
>
> Then it seems bios with REQ_META or REQ_PRIO should both be cached for
> performance optimation, because they are all probably low I/O latency
> demand by upper layer (e.g. file system).
>
> So in this patch, when we want to check whether a bio is metadata
> related, REQ_META and REQ_PRIO are both checked. Then both metadata and
> high priority I/O requests will be handled properly.
s/check whether a bio is metadata related/decide whether to bypass the cache
Apart from these two nitpicks, feel free to add my Reviewed-by.
Thanks
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/
signature.asc
Description: PGP signature
Re: [PATCH v10 1/2] drm/fourcc: Add new P010, P016 video format
Hi,
On 14/01/2019 17:36, Ayan Halder wrote:
> On Thu, Jan 10, 2019 at 03:57:09AM +0800, Randy Li wrote:
>> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
>> channel video format.
>>
>> P012 is a planar 4:2:0 YUV 12 bits per channel
>>
>> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
>> channel video format.
>>
>> V3: Added P012 and fixed cpp for P010.
>> V4: format definition refined per review.
>> V5: Format comment block for each new pixel format.
>> V6: reversed Cb/Cr order in comments.
>> v7: reversed Cb/Cr order in comments of header files, remove
>> the wrong part of commit message.
>> V8: reversed V7 changes except commit message and rebased.
>> v9: used the new properties to describe those format and
>> rebased.
>>
>> Cc: Daniel Stone
>> Cc: Ville Syrj??l??
>>
>> Signed-off-by: Randy Li
>> Signed-off-by: Clint Taylor
>> ---
>> drivers/gpu/drm/drm_fourcc.c | 9 +
>> include/uapi/drm/drm_fourcc.h | 21 +
>> 2 files changed, 30 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>> index d90ee03a84c6..ba7e19d4336c 100644
>> --- a/drivers/gpu/drm/drm_fourcc.c
>> +++ b/drivers/gpu/drm/drm_fourcc.c
>> @@ -238,6 +238,15 @@ const struct drm_format_info *__drm_format_info(u32
>> format)
>> { .format = DRM_FORMAT_X0L2,.depth = 0,
>> .num_planes = 1,
>>.char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
>> .block_h = { 2, 0, 0 },
>>.hsub = 2, .vsub = 2, .is_yuv = true },
>> +{ .format = DRM_FORMAT_P010,.depth = 0,
>> .num_planes = 2,
>> + .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
>> .block_h = { 1, 0, 0 },
>> + .hsub = 2, .vsub = 2, .is_yuv = true},
>> +{ .format = DRM_FORMAT_P012,.depth = 0,
>> .num_planes = 2,
>> + .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
>> .block_h = { 1, 0, 0 },
>> + .hsub = 2, .vsub = 2, .is_yuv = true},
>> +{ .format = DRM_FORMAT_P016,.depth = 0,
>> .num_planes = 2,
>> + .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
>> .block_h = { 1, 0, 0 },
>> + .hsub = 2, .vsub = 2, .is_yuv = true},
>> };
>>
>> unsigned int i;
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index 0b44260a5ee9..8dd1328bc8d6 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -195,6 +195,27 @@ extern "C" {
>> #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /*
>> non-subsampled Cr:Cb plane */
>> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
>> non-subsampled Cb:Cr plane */
>>
>> +/*
>> + * 2 plane YCbCr MSB aligned
>> + * index 0 = Y plane, [15:0] Y:x [10:6] little endian
>> + * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
>> + */
>> +#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /* 2x2
>> subsampled Cr:Cb plane 10 bits per channel */
>> +
>> +/*
>> + * 2 plane YCbCr MSB aligned
>> + * index 0 = Y plane, [15:0] Y:x [12:4] little endian
>> + * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
>> + */
>> +#define DRM_FORMAT_P012 fourcc_code('P', '0', '1', '2') /* 2x2
>> subsampled Cr:Cb plane 12 bits per channel */
>> +
>> +/*
>> + * 2 plane YCbCr MSB aligned
>> + * index 0 = Y plane, [15:0] Y little endian
>> + * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
>> + */
>> +#define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /* 2x2
>> subsampled Cr:Cb plane 16 bits per channel */
>> +
>
> looks good to me.
> Reviewed by:- Ayan Kumar Halder
>
> We are using P010 format for our mali display driver. Our AFBC patch
> series(https://patchwork.freedesktop.org/series/53395/) is dependent
> on this patch. So, that's why I wanted to know when you are planning to
> merge this. As far as I remember, Juha wanted to implement some igt
> tests
> (https://lists.freedesktop.org/archives/intel-gfx/2018-September/174877.html)
> , so is that done now?
>
> My apologies if I am pushing hard on this.
Looks good to me aswell,
Reviewed by: Neil Armstrong
Seems we will also need P010 to support the Amlogic Compressed modifier to
display
compressed frames from the HW decoder.
I can apply this to drm-misc-next if everyone is ok
Neil
>> /*
>> * 3 plane YCbCr
>> * index 0: Y plane, [7:0] Y
>> --
>> 2.20.1
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[PATCH 1/5] ARM: use unified assembler in macros
Use unified assembler syntax (UAL) in macros. Divided syntax is considered depricated. This will also allow to build the kernel using LLVM's integrated assembler. Signed-off-by: Stefan Agner --- arch/arm/lib/copy_from_user.S | 2 +- arch/arm/lib/copy_to_user.S | 2 +- arch/arm/lib/memcpy.S | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/lib/copy_from_user.S b/arch/arm/lib/copy_from_user.S index 0d4c189c7f4f..712ca399f559 100644 --- a/arch/arm/lib/copy_from_user.S +++ b/arch/arm/lib/copy_from_user.S @@ -91,7 +91,7 @@ .endm .macro str1b ptr reg cond=al abort - str\cond\()b \reg, [\ptr], #1 + strb\cond\() \reg, [\ptr], #1 .endm .macro enter reg1 reg2 diff --git a/arch/arm/lib/copy_to_user.S b/arch/arm/lib/copy_to_user.S index 97a6ff4b7e3c..2e402b815e13 100644 --- a/arch/arm/lib/copy_to_user.S +++ b/arch/arm/lib/copy_to_user.S @@ -49,7 +49,7 @@ .endm .macro ldr1b ptr reg cond=al abort - ldr\cond\()b \reg, [\ptr], #1 + ldrb\cond\() \reg, [\ptr], #1 .endm #ifdef CONFIG_CPU_USE_DOMAINS diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S index 64111bd4440b..1c9e625148ca 100644 --- a/arch/arm/lib/memcpy.S +++ b/arch/arm/lib/memcpy.S @@ -30,7 +30,7 @@ .endm .macro ldr1b ptr reg cond=al abort - ldr\cond\()b \reg, [\ptr], #1 + ldrb\cond\() \reg, [\ptr], #1 .endm .macro str1w ptr reg abort @@ -42,7 +42,7 @@ .endm .macro str1b ptr reg cond=al abort - str\cond\()b \reg, [\ptr], #1 + strb\cond\() \reg, [\ptr], #1 .endm .macro enter reg1 reg2 -- 2.20.1
[PATCH 2/5] ARM: use unified assembler in headers
Use unified assembler syntax (UAL) in headers. Divided syntax is
considered depricated. This will also allow to build the kernel
using LLVM's integrated assembler.
Signed-off-by: Stefan Agner
---
arch/arm/include/asm/assembler.h | 8
arch/arm/include/asm/vfpmacros.h | 8
arch/arm/lib/bitops.h| 8
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 28a48e0d4cca..60465b55683c 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -376,7 +376,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT)
.macro usraccoff, instr, reg, ptr, inc, off, cond, abort, t=TUSER()
:
.if \inc == 1
- \instr\cond\()b\()\t\().w \reg, [\ptr, #\off]
+ \instr\()b\cond\()\t\().w \reg, [\ptr, #\off]
.elseif \inc == 4
\instr\cond\()\t\().w \reg, [\ptr, #\off]
.else
@@ -417,7 +417,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT)
.rept \rept
:
.if \inc == 1
- \instr\cond\()b\()\t \reg, [\ptr], #\inc
+ \instr\()b\cond\()\t \reg, [\ptr], #\inc
.elseif \inc == 4
\instr\cond\()\t \reg, [\ptr], #\inc
.else
@@ -460,7 +460,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT)
.macro check_uaccess, addr:req, size:req, limit:req, tmp:req, bad:req
#ifndef CONFIG_CPU_USE_DOMAINS
adds\tmp, \addr, #\size - 1
- sbcccs \tmp, \tmp, \limit
+ sbcscc \tmp, \tmp, \limit
bcs \bad
#ifdef CONFIG_CPU_SPECTRE
movcs \addr, #0
@@ -474,7 +474,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT)
sub \tmp, \limit, #1
subs\tmp, \tmp, \addr @ tmp = limit - 1 - addr
addhs \tmp, \tmp, #1 @ if (tmp >= 0) {
- subhss \tmp, \tmp, \size @ tmp = limit - (addr + size) }
+ subshs \tmp, \tmp, \size @ tmp = limit - (addr + size) }
movlo \addr, #0 @ if (tmp < 0) addr = NULL
csdb
#endif
diff --git a/arch/arm/include/asm/vfpmacros.h b/arch/arm/include/asm/vfpmacros.h
index ef5dfedacd8d..628c336e8e3b 100644
--- a/arch/arm/include/asm/vfpmacros.h
+++ b/arch/arm/include/asm/vfpmacros.h
@@ -29,13 +29,13 @@
ldr \tmp, =elf_hwcap@ may not have MVFR regs
ldr \tmp, [\tmp, #0]
tst \tmp, #HWCAP_VFPD32
- ldcnel p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
+ ldclne p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
addeq \base, \base, #32*4 @ step over unused register
space
#else
VFPFMRX \tmp, MVFR0 @ Media and VFP Feature
Register 0
and \tmp, \tmp, #MVFR0_A_SIMD_MASK @ A_SIMD field
cmp \tmp, #2@ 32 x 64bit registers?
- ldceql p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
+ ldcleq p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
addne \base, \base, #32*4 @ step over unused register
space
#endif
#endif
@@ -53,13 +53,13 @@
ldr \tmp, =elf_hwcap@ may not have MVFR regs
ldr \tmp, [\tmp, #0]
tst \tmp, #HWCAP_VFPD32
- stcnel p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
+ stclne p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
addeq \base, \base, #32*4 @ step over unused register
space
#else
VFPFMRX \tmp, MVFR0 @ Media and VFP Feature
Register 0
and \tmp, \tmp, #MVFR0_A_SIMD_MASK @ A_SIMD field
cmp \tmp, #2@ 32 x 64bit registers?
- stceql p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
+ stcleq p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
addne \base, \base, #32*4 @ step over unused register
space
#endif
#endif
diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index 93cddab73072..95bd35991288 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -7,7 +7,7 @@
ENTRY( \name )
UNWIND(.fnstart)
andsip, r1, #3
- strneb r1, [ip]@ assert word-aligned
+ strbne r1, [ip]@ assert word-aligned
mov r2, #1
and r3, r0, #31 @ Get bit offset
mov r0, r0, lsr #5
@@ -32,7 +32,7 @@ ENDPROC(\name )
ENTRY( \name )
UNWIND(.fnstart)
andsip, r1, #3
- strneb r1, [ip]@ assert word-aligned
+ strbne r1, [ip]@ assert word-aligned
mov r2, #1
and r3, r0, #31 @ Get bit offset
mov r0, r0, lsr #5
[PATCH 3/5] ARM: use unified assembler in assembly files
Use unified assembler syntax (UAL) in assembly files. Divided
syntax is considered depricated. This will also allow to build
the kernel using LLVM's integrated assembler.
Signed-off-by: Stefan Agner
---
arch/arm/boot/bootp/init.S| 2 +-
arch/arm/boot/compressed/ll_char_wr.S | 4 +-
.../include/asm/hardware/entry-macro-iomd.S | 10 ++---
arch/arm/include/debug/tegra.S| 2 +-
arch/arm/kernel/debug.S | 2 +-
arch/arm/kernel/entry-armv.S | 12 +++---
arch/arm/kernel/entry-common.S| 2 +-
arch/arm/kernel/entry-header.S| 8 ++--
arch/arm/lib/clear_user.S | 2 +-
arch/arm/lib/copy_page.S | 4 +-
arch/arm/lib/copy_template.S | 4 +-
arch/arm/lib/csumpartial.S| 20 -
arch/arm/lib/csumpartialcopygeneric.S | 4 +-
arch/arm/lib/csumpartialcopyuser.S| 2 +-
arch/arm/lib/div64.S | 4 +-
arch/arm/lib/floppydma.S | 10 ++---
arch/arm/lib/io-readsb.S | 20 -
arch/arm/lib/io-readsl.S | 2 +-
arch/arm/lib/io-readsw-armv3.S| 6 +--
arch/arm/lib/io-readsw-armv4.S| 12 +++---
arch/arm/lib/io-writesb.S | 20 -
arch/arm/lib/io-writesl.S | 2 +-
arch/arm/lib/io-writesw-armv3.S | 2 +-
arch/arm/lib/io-writesw-armv4.S | 6 +--
arch/arm/lib/lib1funcs.S | 4 +-
arch/arm/lib/memmove.S| 24 +--
arch/arm/lib/memset.S | 42 +--
.../mach-ks8695/include/mach/entry-macro.S| 2 +-
arch/arm/mach-tegra/reset-handler.S | 2 +-
arch/arm/mm/cache-v6.S| 8 ++--
arch/arm/mm/proc-v7m.S| 4 +-
31 files changed, 124 insertions(+), 124 deletions(-)
diff --git a/arch/arm/boot/bootp/init.S b/arch/arm/boot/bootp/init.S
index 78b508075161..142927e5f485 100644
--- a/arch/arm/boot/bootp/init.S
+++ b/arch/arm/boot/bootp/init.S
@@ -44,7 +44,7 @@ _start: add lr, pc, #-0x8 @ lr =
current load addr
*/
movne r10, #0 @ terminator
movne r4, #2 @ Size of this entry (2 words)
- stmneia r9, {r4, r5, r10} @ Size, ATAG_CORE, terminator
+ stmiane r9, {r4, r5, r10} @ Size, ATAG_CORE, terminator
/*
* find the end of the tag list, and then add an INITRD tag on the end.
diff --git a/arch/arm/boot/compressed/ll_char_wr.S
b/arch/arm/boot/compressed/ll_char_wr.S
index 8517c8606b4a..b1dcdb9f4030 100644
--- a/arch/arm/boot/compressed/ll_char_wr.S
+++ b/arch/arm/boot/compressed/ll_char_wr.S
@@ -75,7 +75,7 @@ Lrow4bpplp:
tst r1, #7 @ avoid using r7 directly after
str r7, [r0, -r5]!
subne r1, r1, #1
- ldrneb r7, [r6, r1]
+ ldrbne r7, [r6, r1]
bne Lrow4bpplp
ldmfd sp!, {r4 - r7, pc}
@@ -103,7 +103,7 @@ Lrow8bpplp:
sub r0, r0, r5 @ avoid ip
stmia r0, {r4, ip}
subne r1, r1, #1
- ldrneb r7, [r6, r1]
+ ldrbne r7, [r6, r1]
bne Lrow8bpplp
ldmfd sp!, {r4 - r7, pc}
diff --git a/arch/arm/include/asm/hardware/entry-macro-iomd.S
b/arch/arm/include/asm/hardware/entry-macro-iomd.S
index 8c215acd9b57..f7692731e514 100644
--- a/arch/arm/include/asm/hardware/entry-macro-iomd.S
+++ b/arch/arm/include/asm/hardware/entry-macro-iomd.S
@@ -16,25 +16,25 @@
ldr \tmp, =irq_prio_h
teq \irqstat, #0
#ifdef IOMD_BASE
- ldreqb \irqstat, [\base, #IOMD_DMAREQ] @ get dma
+ ldrbeq \irqstat, [\base, #IOMD_DMAREQ] @ get dma
addeq \tmp, \tmp, #256@ irq_prio_h table size
teqeq \irqstat, #0
bne 2406f
#endif
- ldreqb \irqstat, [\base, #IOMD_IRQREQA]@ get low
priority
+ ldrbeq \irqstat, [\base, #IOMD_IRQREQA]@ get low
priority
addeq \tmp, \tmp, #256@ irq_prio_d table size
teqeq \irqstat, #0
#ifdef IOMD_IRQREQC
- ldreqb \irqstat, [\base, #IOMD_IRQREQC]
+ ldrbeq \irqstat, [\base, #IOMD_IRQREQC]
addeq \tmp, \tmp, #256@ irq_prio_l table size
teqeq \irqstat, #0
#endif
#ifdef IOMD_IRQREQD
- ldreqb \irqstat, [\base, #IOMD_IRQREQD]
+ ldrbeq \irqstat, [\base, #IOMD_IRQREQD]
addeq \tmp, \tmp, #256@ irq_prio_lc table size
teqeq \irqstat, #0
#endif
-2406: ldrneb \irqnr, [\tmp, \irqstat]@
[PATCH 5/5] ARM: warn if divided syntax assembler is used
Remove the -mno-warn-deprecated assembler flag to make sure the GNU assembler warns in case non-unified syntax is used. Signed-off-by: Stefan Agner --- arch/arm/Makefile | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index a0d08a3c9d33..811498e16673 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -112,9 +112,6 @@ ifeq ($(CONFIG_ARM_UNWIND),y) CFLAGS_ABI +=-funwind-tables endif -# Accept old syntax despite ".syntax unified" -AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W) - ifeq ($(CONFIG_THUMB2_KERNEL),y) AFLAGS_AUTOIT :=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it) CFLAGS_ISA :=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN) -- 2.20.1
[PATCH 0/5] ARM: convert to unified syntax
This patchset converts all assembly code to unified assembler
language (UAL) compatible assembly code. From what I can tell,
this mainly boils down to using conditional infixes instead of
postfixes.
Most of the conversion has been done using the following regular
expression:
find ./arch/arm/ -name "*.[hSc]" -exec sed -i -r \
"s/^((\s*[._a-zA-Z0-9]*[\:\(])?\s*)([a-z]{3})(eq|ne|cs|hs|cc|lo|mi|pl|vs|vc|hi|ls|ge|lt|gt|le|al)([a-z]{1,2})(\s)/\1\3\5\4\6/"
\
{} \;
The expression resulted in some false positives and missed some
instances where infix conditionals have been used. With this
changes applied, I compiled several kernel configurations
successfully and without a warning.
The file arch/arm/probes/kprobes/test-arm.c is still using some
divided syntax assembler.
This does not allow to use LLVM's integrated assembler just yet,
there is still some assembler which the integrated assembler does
not like (yet). But it is a big step towards that direction.
--
Stefan
Stefan Agner (5):
ARM: use unified assembler in macros
ARM: use unified assembler in headers
ARM: use unified assembler in assembly files
ARM: use unified assembler in c files
ARM: warn if divided syntax assembler is used
arch/arm/Makefile | 3 --
arch/arm/boot/bootp/init.S| 2 +-
arch/arm/boot/compressed/ll_char_wr.S | 4 +-
arch/arm/include/asm/assembler.h | 8 ++--
.../include/asm/hardware/entry-macro-iomd.S | 10 ++---
arch/arm/include/asm/vfpmacros.h | 8 ++--
arch/arm/include/debug/tegra.S| 2 +-
arch/arm/kernel/debug.S | 2 +-
arch/arm/kernel/entry-armv.S | 12 +++---
arch/arm/kernel/entry-common.S| 2 +-
arch/arm/kernel/entry-header.S| 8 ++--
arch/arm/lib/bitops.h | 8 ++--
arch/arm/lib/clear_user.S | 2 +-
arch/arm/lib/copy_from_user.S | 2 +-
arch/arm/lib/copy_page.S | 4 +-
arch/arm/lib/copy_template.S | 4 +-
arch/arm/lib/copy_to_user.S | 2 +-
arch/arm/lib/csumpartial.S| 20 -
arch/arm/lib/csumpartialcopygeneric.S | 4 +-
arch/arm/lib/csumpartialcopyuser.S| 2 +-
arch/arm/lib/div64.S | 4 +-
arch/arm/lib/floppydma.S | 10 ++---
arch/arm/lib/io-readsb.S | 20 -
arch/arm/lib/io-readsl.S | 2 +-
arch/arm/lib/io-readsw-armv3.S| 6 +--
arch/arm/lib/io-readsw-armv4.S| 12 +++---
arch/arm/lib/io-writesb.S | 20 -
arch/arm/lib/io-writesl.S | 2 +-
arch/arm/lib/io-writesw-armv3.S | 2 +-
arch/arm/lib/io-writesw-armv4.S | 6 +--
arch/arm/lib/lib1funcs.S | 4 +-
arch/arm/lib/memcpy.S | 4 +-
arch/arm/lib/memmove.S| 24 +--
arch/arm/lib/memset.S | 42 +--
.../mach-ks8695/include/mach/entry-macro.S| 2 +-
arch/arm/mach-tegra/reset-handler.S | 2 +-
arch/arm/mm/cache-v6.S| 8 ++--
arch/arm/mm/copypage-v4mc.c | 2 +-
arch/arm/mm/copypage-v4wb.c | 2 +-
arch/arm/mm/copypage-v4wt.c | 2 +-
arch/arm/mm/proc-v7m.S| 4 +-
41 files changed, 143 insertions(+), 146 deletions(-)
--
2.20.1
[PATCH 4/5] ARM: use unified assembler in c files
Use unified assembler syntax (UAL) in inline assembler. Divided
syntax is considered depricated. This will also allow to build
the kernel using LLVM's integrated assembler.
Signed-off-by: Stefan Agner
---
arch/arm/mm/copypage-v4mc.c | 2 +-
arch/arm/mm/copypage-v4wb.c | 2 +-
arch/arm/mm/copypage-v4wt.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mm/copypage-v4mc.c b/arch/arm/mm/copypage-v4mc.c
index b03202cb..b19c7ad1a6de 100644
--- a/arch/arm/mm/copypage-v4mc.c
+++ b/arch/arm/mm/copypage-v4mc.c
@@ -56,7 +56,7 @@ static void mc_copy_user_page(void *from, void *to)
ldmia %0!, {r2, r3, ip, lr} @ 4\n\
subs%2, %2, #1 @ 1\n\
stmia %1!, {r2, r3, ip, lr} @ 4\n\
- ldmneia %0!, {r2, r3, ip, lr} @ 4\n\
+ ldmiane %0!, {r2, r3, ip, lr} @ 4\n\
bne 1b @ "
: "+" (from), "+" (to), "=" (tmp)
: "2" (PAGE_SIZE / 64)
diff --git a/arch/arm/mm/copypage-v4wb.c b/arch/arm/mm/copypage-v4wb.c
index cd3e165afeed..6e3c9b69dd25 100644
--- a/arch/arm/mm/copypage-v4wb.c
+++ b/arch/arm/mm/copypage-v4wb.c
@@ -38,7 +38,7 @@ static void v4wb_copy_user_page(void *kto, const void *kfrom)
ldmia %1!, {r3, r4, ip, lr} @ 4\n\
subs%2, %2, #1 @ 1\n\
stmia %0!, {r3, r4, ip, lr} @ 4\n\
- ldmneia %1!, {r3, r4, ip, lr} @ 4\n\
+ ldmiane %1!, {r3, r4, ip, lr} @ 4\n\
bne 1b @ 1\n\
mcr p15, 0, %1, c7, c10, 4 @ 1 drain WB"
: "+" (kto), "+" (kfrom), "=" (tmp)
diff --git a/arch/arm/mm/copypage-v4wt.c b/arch/arm/mm/copypage-v4wt.c
index 8614572e1296..4a40fa1cbc2a 100644
--- a/arch/arm/mm/copypage-v4wt.c
+++ b/arch/arm/mm/copypage-v4wt.c
@@ -34,7 +34,7 @@ static void v4wt_copy_user_page(void *kto, const void *kfrom)
ldmia %1!, {r3, r4, ip, lr} @ 4\n\
subs%2, %2, #1 @ 1\n\
stmia %0!, {r3, r4, ip, lr} @ 4\n\
- ldmneia %1!, {r3, r4, ip, lr} @ 4\n\
+ ldmiane %1!, {r3, r4, ip, lr} @ 4\n\
bne 1b @ 1\n\
mcr p15, 0, %2, c7, c7, 0 @ flush ID cache"
: "+" (kto), "+" (kfrom), "=" (tmp)
--
2.20.1
[PATCH net-next v2 02/10] net: phy: Mask-out non-compatible modes when setting the max-speed
When setting a PHY's max speed using either the max-speed DT property
or ethtool, we should mask-out all non-compatible modes according to the
settings table, instead of just the 10/100BASET modes.
Signed-off-by: Maxime Chevallier
Suggested-by: Russell King
---
drivers/net/phy/phy-core.c | 45 ++
drivers/net/phy/phy_device.c | 53
include/linux/phy.h | 1 +
3 files changed, 46 insertions(+), 53 deletions(-)
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index 7d6aad287f84..8e54fe396553 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -4,6 +4,7 @@
*/
#include
#include
+#include
const char *phy_speed_to_str(int speed)
{
@@ -338,6 +339,50 @@ size_t phy_speeds(unsigned int *speeds, size_t size,
return count;
}
+static int __set_phy_supported(struct phy_device *phydev, u32 max_speed)
+{
+ const struct phy_setting *p;
+ int i;
+
+ for (i = 0, p = settings; i < ARRAY_SIZE(settings); i++, p++) {
+ if (p->speed > max_speed)
+ linkmode_clear_bit(p->bit, phydev->supported);
+ else
+ break;
+ }
+
+ return 0;
+}
+
+int phy_set_max_speed(struct phy_device *phydev, u32 max_speed)
+{
+ int err;
+
+ err = __set_phy_supported(phydev, max_speed);
+ if (err)
+ return err;
+
+ linkmode_copy(phydev->advertising, phydev->supported);
+
+ return 0;
+}
+EXPORT_SYMBOL(phy_set_max_speed);
+
+void of_set_phy_supported(struct phy_device *phydev)
+{
+ struct device_node *node = phydev->mdio.dev.of_node;
+ u32 max_speed;
+
+ if (!IS_ENABLED(CONFIG_OF_MDIO))
+ return;
+
+ if (!node)
+ return;
+
+ if (!of_property_read_u32(node, "max-speed", _speed))
+ __set_phy_supported(phydev, max_speed);
+}
+
/**
* phy_resolve_aneg_linkmode - resolve the advertisements into phy settings
* @phydev: The phy_device struct
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 18a10565efd4..a4ab16992806 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2023,44 +2023,6 @@ int genphy_loopback(struct phy_device *phydev, bool
enable)
}
EXPORT_SYMBOL(genphy_loopback);
-static int __set_phy_supported(struct phy_device *phydev, u32 max_speed)
-{
- switch (max_speed) {
- case SPEED_10:
- linkmode_clear_bit(ETHTOOL_LINK_MODE_100baseT_Half_BIT,
- phydev->supported);
- linkmode_clear_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT,
- phydev->supported);
- /* fall through */
- case SPEED_100:
- linkmode_clear_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
- phydev->supported);
- linkmode_clear_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
- phydev->supported);
- break;
- case SPEED_1000:
- break;
- default:
- return -ENOTSUPP;
- }
-
- return 0;
-}
-
-int phy_set_max_speed(struct phy_device *phydev, u32 max_speed)
-{
- int err;
-
- err = __set_phy_supported(phydev, max_speed);
- if (err)
- return err;
-
- linkmode_copy(phydev->advertising, phydev->supported);
-
- return 0;
-}
-EXPORT_SYMBOL(phy_set_max_speed);
-
/**
* phy_remove_link_mode - Remove a supported link mode
* @phydev: phy_device structure to remove link mode from
@@ -2191,21 +2153,6 @@ bool phy_validate_pause(struct phy_device *phydev,
}
EXPORT_SYMBOL(phy_validate_pause);
-static void of_set_phy_supported(struct phy_device *phydev)
-{
- struct device_node *node = phydev->mdio.dev.of_node;
- u32 max_speed;
-
- if (!IS_ENABLED(CONFIG_OF_MDIO))
- return;
-
- if (!node)
- return;
-
- if (!of_property_read_u32(node, "max-speed", _speed))
- __set_phy_supported(phydev, max_speed);
-}
-
static void of_set_phy_eee_broken(struct phy_device *phydev)
{
struct device_node *node = phydev->mdio.dev.of_node;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 237dd035858a..cfdd3de38410 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -667,6 +667,7 @@ phy_lookup_setting(int speed, int duplex, const unsigned
long *mask,
bool exact);
size_t phy_speeds(unsigned int *speeds, size_t size,
unsigned long *mask);
+void of_set_phy_supported(struct phy_device *phydev);
static inline bool __phy_is_started(struct phy_device *phydev)
{
--
2.19.2
[PATCH net-next v2 01/10] net: phy: Update PHY linkmodes after config_init
We want to be able to update a PHY's supported list in the config_init
callback, so move the Pause parameters settings from phydrv->features
after calling config_init to make sure these parameters aren't
overwritten.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/phy_device.c | 89 +++-
1 file changed, 58 insertions(+), 31 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 891e0178b97f..18a10565efd4 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1059,6 +1059,59 @@ static int phy_poll_reset(struct phy_device *phydev)
return 0;
}
+/**
+ * phy_update_linkmodes - Update and sanitize linkmodes and pause parameters
+ * @phydev: The PHY device whose parameters we want to update.
+ *
+ * Description: The list of supported and advertised linkmodes is not
+ * straightforward to maintain, since PHYs and MACs are subject to quirks and
+ * erratas. This function re-builds the list of the supported pause parameters
+ * by taking into account the parameters expressed in the driver's features
+ * list.
+ */
+static void phy_update_linkmodes(struct phy_device *phydev)
+{
+ struct device_driver *drv = phydev->mdio.dev.driver;
+ struct phy_driver *phydrv = to_phy_driver(drv);
+
+ mutex_lock(>lock);
+
+ /* The Pause Frame bits indicate that the PHY can support passing
+* pause frames. During autonegotiation, the PHYs will determine if
+* they should allow pause frames to pass. The MAC driver should then
+* use that result to determine whether to enable flow control via
+* pause frames.
+*
+* Normally, PHY drivers should not set the Pause bits, and instead
+* allow phylib to do that. However, there may be some situations
+* (e.g. hardware erratum) where the driver wants to set only one
+* of these bits.
+*/
+ if (test_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydrv->features) ||
+ test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, phydrv->features)) {
+ linkmode_clear_bit(ETHTOOL_LINK_MODE_Pause_BIT,
+ phydev->supported);
+ linkmode_clear_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
+ phydev->supported);
+ if (test_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydrv->features))
+ linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT,
+phydev->supported);
+ if (test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
+phydrv->features))
+ linkmode_set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
+phydev->supported);
+ } else {
+ linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT,
+phydev->supported);
+ linkmode_set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
+phydev->supported);
+ }
+
+ linkmode_copy(phydev->advertising, phydev->supported);
+
+ mutex_unlock(>lock);
+}
+
int phy_init_hw(struct phy_device *phydev)
{
int ret = 0;
@@ -1082,6 +1135,11 @@ int phy_init_hw(struct phy_device *phydev)
if (phydev->drv->config_init)
ret = phydev->drv->config_init(phydev);
+ /* Update and sanitize the supported and advertised linkmodes, since
+* they might have been changed in config_init
+*/
+ phy_update_linkmodes(phydev);
+
return ret;
}
EXPORT_SYMBOL(phy_init_hw);
@@ -2221,37 +2279,6 @@ static int phy_probe(struct device *dev)
*/
of_set_phy_eee_broken(phydev);
- /* The Pause Frame bits indicate that the PHY can support passing
-* pause frames. During autonegotiation, the PHYs will determine if
-* they should allow pause frames to pass. The MAC driver should then
-* use that result to determine whether to enable flow control via
-* pause frames.
-*
-* Normally, PHY drivers should not set the Pause bits, and instead
-* allow phylib to do that. However, there may be some situations
-* (e.g. hardware erratum) where the driver wants to set only one
-* of these bits.
-*/
- if (test_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydrv->features) ||
- test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, phydrv->features)) {
- linkmode_clear_bit(ETHTOOL_LINK_MODE_Pause_BIT,
- phydev->supported);
- linkmode_clear_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
- phydev->supported);
- if (test_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydrv->features))
- linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT,
-phydev->supported);
- if
[PATCH net-next v2 06/10] net: phy: Add generic support for 2.5GBaseT and 5GBaseT
The 802.3bz specification, based on previous by the NBASET alliance,
defines the 2.5GBaseT and 5GBaseT link modes for ethernet traffic on
cat5e, cat6 and cat7 cables.
These mode integrate with the already defined C45 MDIO PMA/PMD registers
set that added 10G support, by defining some previously reserved bits,
and adding a new register (2.5G/5G Extended abilities).
This commit adds the required definitions in include/uapi/linux/mdio.h
to support these modes, and detect when a link-partner advertises them.
It also adds support for these mode in the generic C45 PHY
infrastructure.
Signed-off-by: Maxime Chevallier
---
V1 -> V2: Merged in code for reading 2.5G/5G abilities.
drivers/net/phy/phy-c45.c| 37
drivers/net/phy/phy_device.c | 2 ++
include/uapi/linux/mdio.h| 16
3 files changed, 55 insertions(+)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index 32e72b170ea9..92897cb26557 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -47,6 +47,16 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
/* Assume 1000base-T */
ctrl2 |= MDIO_PMA_CTRL2_1000BT;
break;
+ case SPEED_2500:
+ ctrl1 |= MDIO_CTRL1_SPEED2_5G;
+ /* Assume 2.5Gbase-T */
+ ctrl2 |= MDIO_PMA_CTRL2_2_5GBT;
+ break;
+ case SPEED_5000:
+ ctrl1 |= MDIO_CTRL1_SPEED5G;
+ /* Assume 5Gbase-T */
+ ctrl2 |= MDIO_PMA_CTRL2_5GBT;
+ break;
case SPEED_1:
ctrl1 |= MDIO_CTRL1_SPEED10G;
/* Assume 10Gbase-T */
@@ -179,6 +189,12 @@ int genphy_c45_read_lpa(struct phy_device *phydev)
if (val < 0)
return val;
+ if (val & MDIO_AN_10GBT_STAT_LP2_5G)
+ linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+phydev->lp_advertising);
+ if (val & MDIO_AN_10GBT_STAT_LP5G)
+ linkmode_set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+phydev->lp_advertising);
if (val & MDIO_AN_10GBT_STAT_LP10G)
linkmode_set_bit(ETHTOOL_LINK_MODE_1baseT_Full_BIT,
phydev->lp_advertising);
@@ -209,6 +225,12 @@ int genphy_c45_read_pma(struct phy_device *phydev)
case MDIO_PMA_CTRL1_SPEED1000:
phydev->speed = SPEED_1000;
break;
+ case MDIO_CTRL1_SPEED2_5G:
+ phydev->speed = SPEED_2500;
+ break;
+ case MDIO_CTRL1_SPEED5G:
+ phydev->speed = SPEED_5000;
+ break;
case MDIO_CTRL1_SPEED10G:
phydev->speed = SPEED_1;
break;
@@ -324,6 +346,21 @@ int genphy_c45_pma_read_abilities(struct phy_device
*phydev)
linkmode_mod_bit(ETHTOOL_LINK_MODE_10baseT_Half_BIT,
phydev->supported,
val & MDIO_PMA_EXTABLE_10BT);
+
+ if (val & MDIO_PMA_EXTABLE_NBT) {
+ val = phy_read_mmd(phydev, MDIO_MMD_PMAPMD,
+ MDIO_PMA_NG_EXTABLE);
+ if (val < 0)
+ return val;
+
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+phydev->supported,
+val & MDIO_PMA_NG_EXTABLE_2_5GBT);
+
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+phydev->supported,
+val & MDIO_PMA_NG_EXTABLE_5GBT);
+ }
}
return 0;
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 942cfa7548c4..13ac4bdb9b69 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1085,6 +1085,8 @@ static void phy_update_linkmodes(struct phy_device
*phydev)
ETHTOOL_LINK_MODE_100baseT_Full_BIT,
ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
+ ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+ ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
ETHTOOL_LINK_MODE_1baseT_Full_BIT,
};
diff --git a/include/uapi/linux/mdio.h b/include/uapi/linux/mdio.h
index d435b00d64ad..546509898867 100644
--- a/include/uapi/linux/mdio.h
+++ b/include/uapi/linux/mdio.h
@@ -45,6 +45,7 @@
#define MDIO_AN_ADVERTISE 16 /* AN advertising (base page) */
#define MDIO_AN_LPA19 /* AN LP abilities (base page) */
#define MDIO_PCS_EEE_ABLE 20 /* EEE Capability register */
+#define MDIO_PMA_NG_EXTABLE21 /* 2.5G/5G PMA/PMD extended ability */
#define MDIO_PCS_EEE_WK_ERR22 /* EEE wake error
[PATCH net-next v2 05/10] net: phy: Extract genphy_c45_pma_read_abilities from marvell10g
Marvell 10G PHY driver has a generic way of initializing the supported
link modes by reading the PHY's C45 PMA abilities. This can be made
generic, since these registers are part of the 802.3 specifications.
This commit extracts the config_init link_mode initialization code from
marvell10g and uses it to introduce the genphy_c45_pma_read_abilities
function.
Only PMA modes are read, it's still up to the caller to set the Pause
parameters.
Signed-off-by: Maxime Chevallier
---
V1 -> V2: The Pause parameters setting stays in marvell10g. Make use of
linkmode_mod_bit. Renamed the function from
genphy_c45_read_abilities to genphy_c45_pma_read_abilities, as
advised by Andrew.
drivers/net/phy/marvell10g.c | 78
drivers/net/phy/phy-c45.c| 74 ++
include/linux/phy.h | 1 +
3 files changed, 83 insertions(+), 70 deletions(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 296a537cdfcb..07df87b81369 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -234,8 +234,7 @@ static int mv3310_resume(struct phy_device *phydev)
static int mv3310_config_init(struct phy_device *phydev)
{
- __ETHTOOL_DECLARE_LINK_MODE_MASK(supported) = { 0, };
- int val;
+ int ret, val;
/* Check that the PHY interface type is compatible */
if (phydev->interface != PHY_INTERFACE_MODE_SGMII &&
@@ -244,8 +243,8 @@ static int mv3310_config_init(struct phy_device *phydev)
phydev->interface != PHY_INTERFACE_MODE_10GKR)
return -ENODEV;
- __set_bit(ETHTOOL_LINK_MODE_Pause_BIT, supported);
- __set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, supported);
+ __set_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydev->supported);
+ __set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, phydev->supported);
if (phydev->c45_ids.devices_in_package & MDIO_DEVS_AN) {
val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_STAT1);
@@ -253,74 +252,13 @@ static int mv3310_config_init(struct phy_device *phydev)
return val;
if (val & MDIO_AN_STAT1_ABLE)
- __set_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, supported);
+ __set_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
+ phydev->supported);
}
- val = phy_read_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_STAT2);
- if (val < 0)
- return val;
-
- /* Ethtool does not support the WAN mode bits */
- if (val & (MDIO_PMA_STAT2_10GBSR | MDIO_PMA_STAT2_10GBLR |
- MDIO_PMA_STAT2_10GBER | MDIO_PMA_STAT2_10GBLX4 |
- MDIO_PMA_STAT2_10GBSW | MDIO_PMA_STAT2_10GBLW |
- MDIO_PMA_STAT2_10GBEW))
- __set_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, supported);
- if (val & MDIO_PMA_STAT2_10GBSR)
- __set_bit(ETHTOOL_LINK_MODE_1baseSR_Full_BIT, supported);
- if (val & MDIO_PMA_STAT2_10GBLR)
- __set_bit(ETHTOOL_LINK_MODE_1baseLR_Full_BIT, supported);
- if (val & MDIO_PMA_STAT2_10GBER)
- __set_bit(ETHTOOL_LINK_MODE_1baseER_Full_BIT, supported);
-
- if (val & MDIO_PMA_STAT2_EXTABLE) {
- val = phy_read_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_PMA_EXTABLE);
- if (val < 0)
- return val;
-
- if (val & (MDIO_PMA_EXTABLE_10GBT | MDIO_PMA_EXTABLE_1000BT |
- MDIO_PMA_EXTABLE_100BTX | MDIO_PMA_EXTABLE_10BT))
- __set_bit(ETHTOOL_LINK_MODE_TP_BIT, supported);
- if (val & MDIO_PMA_EXTABLE_10GBLRM)
- __set_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, supported);
- if (val & (MDIO_PMA_EXTABLE_10GBKX4 | MDIO_PMA_EXTABLE_10GBKR |
- MDIO_PMA_EXTABLE_1000BKX))
- __set_bit(ETHTOOL_LINK_MODE_Backplane_BIT, supported);
- if (val & MDIO_PMA_EXTABLE_10GBLRM)
- __set_bit(ETHTOOL_LINK_MODE_1baseLRM_Full_BIT,
- supported);
- if (val & MDIO_PMA_EXTABLE_10GBT)
- __set_bit(ETHTOOL_LINK_MODE_1baseT_Full_BIT,
- supported);
- if (val & MDIO_PMA_EXTABLE_10GBKX4)
- __set_bit(ETHTOOL_LINK_MODE_1baseKX4_Full_BIT,
- supported);
- if (val & MDIO_PMA_EXTABLE_10GBKR)
- __set_bit(ETHTOOL_LINK_MODE_1baseKR_Full_BIT,
- supported);
- if (val & MDIO_PMA_EXTABLE_1000BT)
- __set_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
- supported);
- if (val & MDIO_PMA_EXTABLE_1000BKX)
-
[PATCH net-next v2 07/10] net: phy: marvell10g: Add support for 2.5GBASET
The Marvell Alaska family of PHYs supports 2.5GBaseT and 5GBaseT modes,
as defined in the 802.3bz specification.
When the link partner requests a 2.5GBASET link, the PHY will
reconfigure it's MII interface to 2500BASEX.
At 5G, the PHY will reconfigure it's interface to 5GBASE-R, but this
mode isn't supported by any MAC for now.
This was tested with :
- The 88X3310, which is on the MacchiatoBin
- The 88E2010, an Alaska PHY that has no fiber interfaces, and is
limited to 5G maximum speed.
Signed-off-by: Maxime Chevallier
---
V1 -> V2: Use a #define for the 88X3310 PHY ID, since it's reused in
various places in the code. Rebased on Heiner Kallweit's patch
introducing the phy_modify_mmd accessor.
drivers/net/phy/marvell10g.c | 30 ++
include/linux/marvell_phy.h | 1 +
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 07df87b81369..581b4b6e31e9 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -238,6 +238,7 @@ static int mv3310_config_init(struct phy_device *phydev)
/* Check that the PHY interface type is compatible */
if (phydev->interface != PHY_INTERFACE_MODE_SGMII &&
+ phydev->interface != PHY_INTERFACE_MODE_2500BASEX &&
phydev->interface != PHY_INTERFACE_MODE_XAUI &&
phydev->interface != PHY_INTERFACE_MODE_RXAUI &&
phydev->interface != PHY_INTERFACE_MODE_10GKR)
@@ -307,8 +308,18 @@ static int mv3310_config_aneg(struct phy_device *phydev)
else
reg = 0;
+ if (linkmode_test_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+ phydev->advertising))
+ reg |= MDIO_AN_10GBT_CTRL_ADV2_5G;
+ if (linkmode_test_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ phydev->advertising))
+ reg |= MDIO_AN_10GBT_CTRL_ADV5G;
+
ret = phy_modify_mmd(phydev, MDIO_MMD_AN, MDIO_AN_10GBT_CTRL,
-MDIO_AN_10GBT_CTRL_ADV10G, reg);
+MDIO_AN_10GBT_CTRL_ADV10G |
+MDIO_AN_10GBT_CTRL_ADV5G |
+MDIO_AN_10GBT_CTRL_ADV2_5G, reg);
+
if (ret < 0)
return ret;
if (ret > 0)
@@ -337,17 +348,20 @@ static int mv3310_aneg_done(struct phy_device *phydev)
static void mv3310_update_interface(struct phy_device *phydev)
{
if ((phydev->interface == PHY_INTERFACE_MODE_SGMII ||
+phydev->interface == PHY_INTERFACE_MODE_2500BASEX ||
phydev->interface == PHY_INTERFACE_MODE_10GKR) && phydev->link) {
/* The PHY automatically switches its serdes interface (and
-* active PHYXS instance) between Cisco SGMII and 10GBase-KR
-* modes according to the speed. Florian suggests setting
-* phydev->interface to communicate this to the MAC. Only do
-* this if we are already in either SGMII or 10GBase-KR mode.
+* active PHYXS instance) between Cisco SGMII, 10GBase-KR and
+* 2500BaseX modes according to the speed. Florian suggests
+* setting phydev->interface to communicate this to the MAC.
+* Only do this if we are already in one of the above modes.
*/
if (phydev->speed == SPEED_1)
phydev->interface = PHY_INTERFACE_MODE_10GKR;
+ else if (phydev->speed == SPEED_2500)
+ phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
else if (phydev->speed >= SPEED_10 &&
-phydev->speed < SPEED_1)
+phydev->speed < SPEED_2500)
phydev->interface = PHY_INTERFACE_MODE_SGMII;
}
}
@@ -450,7 +464,7 @@ static int mv3310_read_status(struct phy_device *phydev)
static struct phy_driver mv3310_drivers[] = {
{
- .phy_id = 0x002b09aa,
+ .phy_id = MARVELL_PHY_ID_88X3310,
.phy_id_mask= MARVELL_PHY_ID_MASK,
.name = "mv88x3310",
.features = PHY_10GBIT_FEATURES,
@@ -468,7 +482,7 @@ static struct phy_driver mv3310_drivers[] = {
module_phy_driver(mv3310_drivers);
static struct mdio_device_id __maybe_unused mv3310_tbl[] = {
- { 0x002b09aa, MARVELL_PHY_ID_MASK },
+ { MARVELL_PHY_ID_88X3310, MARVELL_PHY_ID_MASK },
{ },
};
MODULE_DEVICE_TABLE(mdio, mv3310_tbl);
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index 1eb6f244588d..5851d68d828a 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -20,6 +20,7 @@
#define MARVELL_PHY_ID_88E1540 0x01410eb0
#define MARVELL_PHY_ID_88E1545 0x01410ea0
#define MARVELL_PHY_ID_88E3016 0x01410e60
+#define
[PATCH net-next v2 08/10] net: phy: marvell10g: Force reading of 2.5/5G
As per 802.3bz, if bit 14 of (1.11) "PMA Extended Abilities" indicates
whether or not we should read register (1.21) "2.52/5G PMA Extended
Abilities", which contains information on the support of 2.5GBASET and
5GBASET.
After testing on several variants of PHYS of this family, it appears
that bit 14 in (1.11) isn't always set when it should be.
PHYs 88X3310 (on MacchiatoBin) and 88E2010 do support 2.5G and 5GBASET,
but don't have 1.11.14 set. Their register 1.21 is filled with the
correct values, indicating 2.5G and 5G support.
PHYs 88E2110 do have their 1.11.14 bit set, as it should.
Signed-off-by: Maxime Chevallier
---
V1 -> V2: Use the PMA device id to identify which devices need this
quirk, based on Andrew's idea.
drivers/net/phy/marvell10g.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 581b4b6e31e9..2593db608af7 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -232,6 +232,23 @@ static int mv3310_resume(struct phy_device *phydev)
return mv3310_hwmon_config(phydev, true);
}
+/* Some PHYs in the Alaska family such as the 88X3310 and the 88E2010
+ * don't set bit 14 in PMA Extended Abilities (1.11), although they do
+ * support 2.5GBASET and 5GBASET. For these models, we can still read their
+ * 2.5G/5G extended abilities register (1.21). We detect these models based on
+ * the PMA device identifier, with a mask matching models known to have this
+ * issue
+ */
+static bool mv3310_has_pma_ngbaset_quirk(struct phy_device *phydev)
+{
+ if (!(phydev->c45_ids.devices_in_package & MDIO_DEVS_PMAPMD))
+ return false;
+
+ /* Only some revisions of the 88X3310 family PMA seem to be impacted */
+ return (phydev->c45_ids.device_ids[MDIO_MMD_PMAPMD] & 0xfffe) ==
+ (MARVELL_PHY_ID_88X3310 & 0xfffe);
+}
+
static int mv3310_config_init(struct phy_device *phydev)
{
int ret, val;
@@ -261,6 +278,20 @@ static int mv3310_config_init(struct phy_device *phydev)
if (ret)
return ret;
+ if (mv3310_has_pma_ngbaset_quirk(phydev)) {
+ val = phy_read_mmd(phydev, MDIO_MMD_PMAPMD,
+ MDIO_PMA_NG_EXTABLE);
+ if (val < 0)
+ return val;
+
+ if (val & MDIO_PMA_NG_EXTABLE_2_5GBT)
+ __set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+ phydev->supported);
+ if (val & MDIO_PMA_NG_EXTABLE_5GBT)
+ __set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ phydev->supported);
+ }
+
return 0;
}
--
2.19.2
[PATCH net-next v2 10/10] net: phy: marvell10g: add support for the 88x2110 PHY
This patch adds support for the 88x2110 PHY, which is similar to the
already supported 88x3310 PHY without the SFP interface.
It supports 10/100/1000BASET along with 2.5GBASET, 5GBASET and 10GBASET,
with the same interface modes that are used by the 3310.
This PHY don't have the same issue as the 88x3310 regarding 2.5/5G
abilities, and correctly follows the 802.3bz standard to list the
supported abilities.
Signed-off-by: Maxime Chevallier
Suggested-by: Antoine Tenart
---
V1 -> V2: Use a #define for the PHY ID, since we also do that for the
3310. Removed the mv2110_config_init implementation since we
now manually check for the PMA device id when using the quirk.
drivers/net/phy/marvell10g.c | 13 +
include/linux/marvell_phy.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 2593db608af7..fa4847662c81 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -508,12 +508,25 @@ static struct phy_driver mv3310_drivers[] = {
.aneg_done = mv3310_aneg_done,
.read_status= mv3310_read_status,
},
+ {
+ .phy_id = MARVELL_PHY_ID_88E2110,
+ .phy_id_mask= MARVELL_PHY_ID_MASK,
+ .name = "mv88x2110",
+ .features = PHY_10GBIT_FEATURES,
+ .probe = mv3310_probe,
+ .soft_reset = gen10g_no_soft_reset,
+ .config_init= mv3310_config_init,
+ .config_aneg= mv3310_config_aneg,
+ .aneg_done = mv3310_aneg_done,
+ .read_status= mv3310_read_status,
+ },
};
module_phy_driver(mv3310_drivers);
static struct mdio_device_id __maybe_unused mv3310_tbl[] = {
{ MARVELL_PHY_ID_88X3310, MARVELL_PHY_ID_MASK },
+ { MARVELL_PHY_ID_88E2110, MARVELL_PHY_ID_MASK },
{ },
};
MODULE_DEVICE_TABLE(mdio, mv3310_tbl);
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index 5851d68d828a..8596a861940e 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -21,6 +21,7 @@
#define MARVELL_PHY_ID_88E1545 0x01410ea0
#define MARVELL_PHY_ID_88E3016 0x01410e60
#define MARVELL_PHY_ID_88X3310 0x002b09aa
+#define MARVELL_PHY_ID_88E2110 0x002b09b8
/* The MV88e6390 Ethernet switch contains embedded PHYs. These PHYs do
* not have a model ID. So the switch driver traps reads to the ID2
--
2.19.2
Re: [PATCH] mfd: tps68470: drop unused MODULE_DEVICE_TABLE
On Wed, 06 Feb 2019, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > drivers/mfd/Kconfig:config MFD_TPS68470 > drivers/mfd/Kconfig:bool "TI TPS68470 Power Management / LED chips" > > ...meaning that it currently is not being built as a module by anyone. > > Hence we remove the MODULE_DEVICE_TABLE since it is a no-op for > non-modular code. > > There is no removal of here because there isn't one. > Instead, it is relying on including that implicitly from an ACPI header. > > In cleaning up the ACPI instance of module.h (which also isn't strictly > needed), then this mfd driver breaks when MODULE_DEVICE_TABLE becomes > undefined here. > > The easiest dependency solution is to simply defer the ACPI cleanup > until this change is present in mainline. > > Cc: Lee Jones > Signed-off-by: Paul Gortmaker Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH net-next v2 09/10] net: mvpp2: Add 2.5GBaseT support
The PPv2 controller is able to support 2.5G speeds, allowing to use 2.5GBASET in conjunction with PHYs that use 2500BASEX as their MII interface when using this mode. Signed-off-by: Maxime Chevallier --- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c index 5c0c26fd8363..6f36aed5bd0a 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c @@ -4410,6 +4410,7 @@ static void mvpp2_phylink_validate(struct net_device *dev, case PHY_INTERFACE_MODE_2500BASEX: phylink_set(mask, 1000baseT_Full); phylink_set(mask, 1000baseX_Full); + phylink_set(mask, 2500baseT_Full); phylink_set(mask, 2500baseX_Full); break; default: -- 2.19.2
[PATCH net-next v2 00/10] net: phy: Add support for 2.5GBASET PHYs
Hello everyone, This is the second iteration of the series introducing support for 2.5GBASET and 5GBASET to the network PHY infrastructure. These 2 modes are described in the 802.3bz specifications, and allow to use 2.5G and 5G speeds on cat5e/cat6 cables. The required infrastructure code is added for 2.5GBASET and 5GBASET, but only 2.5GBASET support is added to the Marvell10G driver. The reason is because the 5GBASER interface mode used to communicate with the MAC isn't implemented yet, and therefore this can't be tested. This series has seen some rework since last time, see the full details in the patches changelog. The main highlights are : - Patch 1 moves the Pause ans Asym_Pause parameters update after calling config_init. This allows us to change the phydev->supported modes in config_init, while still forcing some quirks taken from phydrv->features, to disable unsupported Pause modes. This was proposed by Andrew. - Patch 2 generalizes the way we mask-out modes we don't want to use when forcing the link speed through DT or ethtool, by walking through the PHY settings table, as proposed by Russell. - Patch 4 implements automatic setting of TM, FIBRE and Backplane bits from the list of supported linkmodes. - In Patch 5, we only read abilities from the PMA. Pause parameters aren't built from the genphy_c45_pma_read_abilities, as it was done in the previous iteration of the patch. We also amke use of linkmode_mod_bit to make sure we mask-out unsupported modes. - In Patch 8, we manually check for the PMA device id to see if we have to use a quirk when reading the 2.5G/5G Extended Abilities Maxime Chevallier (10): net: phy: Update PHY linkmodes after config_init net: phy: Mask-out non-compatible modes when setting the max-speed net: phy: Move of_set_phy_eee_broken to phy-core.c net: phy: Automatically fill the generic TP, FIBRE and Backplane modes net: phy: Extract genphy_c45_pma_read_abilities from marvell10g net: phy: Add generic support for 2.5GBaseT and 5GBaseT net: phy: marvell10g: Add support for 2.5GBASET net: phy: marvell10g: Force reading of 2.5/5G net: mvpp2: Add 2.5GBaseT support net: phy: marvell10g: add support for the 88x2110 PHY .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 + drivers/net/phy/marvell10g.c | 142 +-- drivers/net/phy/phy-c45.c | 111 drivers/net/phy/phy-core.c| 72 ++ drivers/net/phy/phy_device.c | 237 +- include/linux/linkmode.h | 6 + include/linux/marvell_phy.h | 2 + include/linux/phy.h | 3 + include/uapi/linux/mdio.h | 16 ++ 9 files changed, 405 insertions(+), 185 deletions(-) -- 2.19.2
[PATCH net-next v2 03/10] net: phy: Move of_set_phy_eee_broken to phy-core.c
Since of_set_phy_supported was moved to phy-core.c, we can also move
of_set_phy_eee_broken to the same location, so that we have all OF
functions in the same place.
This patch doesn't intend to introduce any change in behaviour.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/phy-core.c | 27 +++
drivers/net/phy/phy_device.c | 28
include/linux/phy.h | 1 +
3 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index 8e54fe396553..9429b473c791 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -383,6 +383,33 @@ void of_set_phy_supported(struct phy_device *phydev)
__set_phy_supported(phydev, max_speed);
}
+void of_set_phy_eee_broken(struct phy_device *phydev)
+{
+ struct device_node *node = phydev->mdio.dev.of_node;
+ u32 broken = 0;
+
+ if (!IS_ENABLED(CONFIG_OF_MDIO))
+ return;
+
+ if (!node)
+ return;
+
+ if (of_property_read_bool(node, "eee-broken-100tx"))
+ broken |= MDIO_EEE_100TX;
+ if (of_property_read_bool(node, "eee-broken-1000t"))
+ broken |= MDIO_EEE_1000T;
+ if (of_property_read_bool(node, "eee-broken-10gt"))
+ broken |= MDIO_EEE_10GT;
+ if (of_property_read_bool(node, "eee-broken-1000kx"))
+ broken |= MDIO_EEE_1000KX;
+ if (of_property_read_bool(node, "eee-broken-10gkx4"))
+ broken |= MDIO_EEE_10GKX4;
+ if (of_property_read_bool(node, "eee-broken-10gkr"))
+ broken |= MDIO_EEE_10GKR;
+
+ phydev->eee_broken_modes = broken;
+}
+
/**
* phy_resolve_aneg_linkmode - resolve the advertisements into phy settings
* @phydev: The phy_device struct
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index a4ab16992806..a4cbc5a6f09d 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -30,7 +30,6 @@
#include
#include
#include
-#include
MODULE_DESCRIPTION("PHY library");
MODULE_AUTHOR("Andy Fleming");
@@ -2153,33 +2152,6 @@ bool phy_validate_pause(struct phy_device *phydev,
}
EXPORT_SYMBOL(phy_validate_pause);
-static void of_set_phy_eee_broken(struct phy_device *phydev)
-{
- struct device_node *node = phydev->mdio.dev.of_node;
- u32 broken = 0;
-
- if (!IS_ENABLED(CONFIG_OF_MDIO))
- return;
-
- if (!node)
- return;
-
- if (of_property_read_bool(node, "eee-broken-100tx"))
- broken |= MDIO_EEE_100TX;
- if (of_property_read_bool(node, "eee-broken-1000t"))
- broken |= MDIO_EEE_1000T;
- if (of_property_read_bool(node, "eee-broken-10gt"))
- broken |= MDIO_EEE_10GT;
- if (of_property_read_bool(node, "eee-broken-1000kx"))
- broken |= MDIO_EEE_1000KX;
- if (of_property_read_bool(node, "eee-broken-10gkx4"))
- broken |= MDIO_EEE_10GKX4;
- if (of_property_read_bool(node, "eee-broken-10gkr"))
- broken |= MDIO_EEE_10GKR;
-
- phydev->eee_broken_modes = broken;
-}
-
static bool phy_drv_supports_irq(struct phy_driver *phydrv)
{
return phydrv->config_intr && phydrv->ack_interrupt;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index cfdd3de38410..017118061ecf 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -668,6 +668,7 @@ phy_lookup_setting(int speed, int duplex, const unsigned
long *mask,
size_t phy_speeds(unsigned int *speeds, size_t size,
unsigned long *mask);
void of_set_phy_supported(struct phy_device *phydev);
+void of_set_phy_eee_broken(struct phy_device *phydev);
static inline bool __phy_is_started(struct phy_device *phydev)
{
--
2.19.2
[PATCH net-next v2 04/10] net: phy: Automatically fill the generic TP, FIBRE and Backplane modes
PHY advertised and supported linkmodes contain both specific modes such
as 1000BASET Half/Full and generic ones such as TP that represent a
class of modes.
Since some modes such as Fibre, TP or Backplane match a wide range of
specific modes, we can automatically set these bits if one of the
specific modes it corresponds to is present in the list.
The 'TP' bit is set whenever there's a BaseT linkmode in
phydev->supported.
The 'FIBRE' bit is set for BaseL, BaseS and BaseE linkmodes.
Finally, the 'Backplane' is set whenever a BaseK mode is supported.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/phy_device.c | 67 +++-
include/linux/linkmode.h | 6
2 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index a4cbc5a6f09d..942cfa7548c4 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1066,15 +1066,80 @@ static int phy_poll_reset(struct phy_device *phydev)
* straightforward to maintain, since PHYs and MACs are subject to quirks and
* erratas. This function re-builds the list of the supported pause parameters
* by taking into account the parameters expressed in the driver's features
- * list.
+ * list. It also sets the generic bits indicating Twisted Pair, Fibre and
+ * Backaplane link modes support based on the detailed list that can be built
+ * from the PHY's ability list.
*/
static void phy_update_linkmodes(struct phy_device *phydev)
{
+ __ETHTOOL_DECLARE_LINK_MODE_MASK(phy_baset_features) = { 0, };
+ __ETHTOOL_DECLARE_LINK_MODE_MASK(phy_fibre_features) = { 0, };
+ __ETHTOOL_DECLARE_LINK_MODE_MASK(phy_backplane_features) = { 0, };
struct device_driver *drv = phydev->mdio.dev.driver;
struct phy_driver *phydrv = to_phy_driver(drv);
+ const int phy_baset_features_array[] = {
+ ETHTOOL_LINK_MODE_10baseT_Half_BIT,
+ ETHTOOL_LINK_MODE_10baseT_Full_BIT,
+ ETHTOOL_LINK_MODE_100baseT_Half_BIT,
+ ETHTOOL_LINK_MODE_100baseT_Full_BIT,
+ ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
+ ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
+ ETHTOOL_LINK_MODE_1baseT_Full_BIT,
+ };
+
+ const int phy_fibre_features_array[] = {
+ ETHTOOL_LINK_MODE_4baseSR4_Full_BIT,
+ ETHTOOL_LINK_MODE_4baseLR4_Full_BIT,
+ ETHTOOL_LINK_MODE_56000baseSR4_Full_BIT,
+ ETHTOOL_LINK_MODE_56000baseLR4_Full_BIT,
+ ETHTOOL_LINK_MODE_25000baseSR_Full_BIT,
+ ETHTOOL_LINK_MODE_10baseSR4_Full_BIT,
+ ETHTOOL_LINK_MODE_10baseLR4_ER4_Full_BIT,
+ ETHTOOL_LINK_MODE_5baseSR2_Full_BIT,
+ ETHTOOL_LINK_MODE_1baseSR_Full_BIT,
+ ETHTOOL_LINK_MODE_1baseLR_Full_BIT,
+ ETHTOOL_LINK_MODE_1baseLRM_Full_BIT,
+ ETHTOOL_LINK_MODE_1baseER_Full_BIT,
+ };
+
+ const int phy_backplane_features_array[] = {
+ ETHTOOL_LINK_MODE_1000baseKX_Full_BIT,
+ ETHTOOL_LINK_MODE_1baseKX4_Full_BIT,
+ ETHTOOL_LINK_MODE_1baseKR_Full_BIT,
+ ETHTOOL_LINK_MODE_2baseKR2_Full_BIT,
+ ETHTOOL_LINK_MODE_4baseKR4_Full_BIT,
+ ETHTOOL_LINK_MODE_56000baseKR4_Full_BIT,
+ ETHTOOL_LINK_MODE_25000baseKR_Full_BIT,
+ ETHTOOL_LINK_MODE_5baseKR2_Full_BIT,
+ ETHTOOL_LINK_MODE_10baseKR4_Full_BIT,
+ };
+
+ linkmode_set_bit_array(phy_baset_features_array,
+ ARRAY_SIZE(phy_baset_features_array),
+ phy_baset_features);
+
+ linkmode_set_bit_array(phy_fibre_features_array,
+ ARRAY_SIZE(phy_fibre_features_array),
+ phy_fibre_features);
+
+ linkmode_set_bit_array(phy_backplane_features_array,
+ ARRAY_SIZE(phy_backplane_features_array),
+ phy_backplane_features);
+
mutex_lock(>lock);
+ if (linkmode_intersects(phydev->supported, phy_baset_features))
+ linkmode_set_bit(ETHTOOL_LINK_MODE_TP_BIT, phydev->supported);
+
+ if (linkmode_intersects(phydev->supported, phy_fibre_features))
+ linkmode_set_bit(ETHTOOL_LINK_MODE_FIBRE_BIT,
+phydev->supported);
+
+ if (linkmode_intersects(phydev->supported, phy_backplane_features))
+ linkmode_set_bit(ETHTOOL_LINK_MODE_Backplane_BIT,
+phydev->supported);
+
/* The Pause Frame bits indicate that the PHY can support passing
* pause frames. During autonegotiation, the PHYs will determine if
* they should allow pause frames to pass. The MAC driver should then
diff --git
Re: [GIT PULL] x86/mm changes for v4.21
On Wed, Feb 06, 2019 at 04:33:54PM -0800, Dave Hansen wrote: > I wonder if the patches that you bisected to just changed the flushing > from being CR3-based (and not taking an address) to being INVPCID-based, > and taking an address that is sensitive to canonicality. That is indeed one of the things that patch series does; before this it would always flush world for ARRAY interfaces. I'll have a look at the code; I seem to remember there being test for canonical addresses, maybe they're not in the right place.
[PATCH V6 2/4] thermal: imx_sc: add i.MX system controller thermal support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and thermal sensors etc..
This patch adds i.MX system controller thermal driver support,
Linux kernel has to communicate with system controller via MU
(message unit) IPC to get each thermal sensor's temperature,
it supports multiple sensors which are passed from device tree,
please see the binding doc for details.
Signed-off-by: Anson Huang
---
ChangeLog since V5:
- instead of abusing common thermal sensor ID, add a property in each
thermal zone to pass
resource id to thermal driver.
---
drivers/thermal/Kconfig | 11 +++
drivers/thermal/Makefile | 1 +
drivers/thermal/imx_sc_thermal.c | 161 +++
3 files changed, 173 insertions(+)
create mode 100644 drivers/thermal/imx_sc_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 58bb7d7..fec0ef5 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -223,6 +223,17 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config IMX_SC_THERMAL
+ tristate "Temperature sensor driver for NXP i.MX SoCs with System
Controller"
+ depends on (ARCH_MXC && IMX_SCU) || COMPILE_TEST
+ depends on OF
+ help
+ Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
+ system controller inside, Linux kernel has to communicate with system
+ controller via MU (message unit) IPC to get temperature from thermal
+ sensor. It supports one critical trip point and one
+ passive trip point for each thermal sensor.
+
config MAX77620_THERMAL
tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
depends on MFD_MAX77620
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 486d682..4062627 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_TANGO_THERMAL)+= tango_thermal.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
diff --git a/drivers/thermal/imx_sc_thermal.c b/drivers/thermal/imx_sc_thermal.c
new file mode 100644
index 000..fc0bb7e
--- /dev/null
+++ b/drivers/thermal/imx_sc_thermal.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018-2019 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "thermal_core.h"
+
+#define IMX_SC_MISC_FUNC_GET_TEMP 13
+#define IMX_SC_C_TEMP 0
+
+static struct imx_sc_ipc *thermal_ipc_handle;
+
+struct imx_sc_sensor {
+ struct thermal_zone_device *tzd;
+ u32 resource_id;
+};
+
+struct imx_sc_thermal_data {
+ struct imx_sc_sensor *sensor;
+};
+
+struct req_get_temp {
+ u16 resource_id;
+ u8 type;
+} __packed;
+
+struct resp_get_temp {
+ u16 celsius;
+ u8 tenths;
+} __packed;
+
+struct imx_sc_msg_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ union {
+ struct req_get_temp req;
+ struct resp_get_temp resp;
+ } data;
+} __packed;
+
+static int imx_sc_thermal_get_temp(void *data, int *temp)
+{
+ struct imx_sc_msg_misc_get_temp msg;
+ struct imx_sc_rpc_msg *hdr =
+ struct imx_sc_sensor *sensor = data;
+ int ret;
+
+ msg.data.req.resource_id = sensor->resource_id;
+ msg.data.req.type = IMX_SC_C_TEMP;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
+ hdr->size = 2;
+
+ ret = imx_scu_call_rpc(thermal_ipc_handle, , true);
+ if (ret) {
+ pr_err("read temp sensor %d failed, ret %d\n",
+ sensor->resource_id, ret);
+ return ret;
+ }
+
+ *temp = msg.data.resp.celsius * 1000 + msg.data.resp.tenths * 100;
+
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
+ .get_temp = imx_sc_thermal_get_temp,
+};
+
+static int imx_sc_thermal_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *sensor_np = NULL;
+ struct imx_sc_thermal_data *data;
+ struct imx_sc_sensor *sensors;
+ u32 sensor_num;
+ int ret, i;
+
+ ret = imx_scu_get_handle(_ipc_handle);
+ if (ret)
+ return ret;
+
+ data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ ret = of_property_read_u32(np,
Re: [PATCHv5 00/10] Heterogeneuos memory node attributes
On Thu, 24 Jan 2019 16:07:14 -0700 Keith Busch wrote: > == Changes since v4 == > > All public interfaces have kernel docs. > > Renamed "class" to "access", docs and changed logs updated > accordingly. (Rafael) > > The sysfs hierarchy is altered to put initiators and targets in their > own attribute group directories (Rafael). > > The node lists are removed. This feedback is in conflict with v1 > feedback, but consensus wants to remove multi-value sysfs attributes, > which includes lists. We only have symlinks now, just like v1 provided. > > Documentation and code patches are combined such that the code > introducing new attributes and its documentation are in the same > patch. (Rafael and Dan). > > The performance attributes, bandwidth and latency, are moved into the > initiators directory. This should make it obvious for which node > access the attributes apply, which was previously ambiguous. > (Jonathan Cameron). > > The HMAT code selecting "local" initiators is substantially changed. > Only PXM's that have identical performance to the HMAT's processor PXM > in Address Range Structure are registered. This is to avoid considering > nodes identical when only one of several perf attributes are the same. > (Jonathan Cameron). > > Verbose variable naming. Examples include "initiator" and "target" > instead of "i" and "t", "mem_pxm" and "cpu_pxm" instead of "m" and > "p". (Rafael) > > Compile fixes for when HMEM_REPORTING is not set. This is not a user > selectable config option, default 'n', and will have to be selected > by other config options that require it (Greg KH and Rafael). > > == Background == > > Platforms may provide multiple types of cpu attached system memory. The > memory ranges for each type may have different characteristics that > applications may wish to know about when considering what node they want > their memory allocated from. > > It had previously been difficult to describe these setups as memory > rangers were generally lumped into the NUMA node of the CPUs. New > platform attributes have been created and in use today that describe > the more complex memory hierarchies that can be created. > > This series' objective is to provide the attributes from such systems > that are useful for applications to know about, and readily usable with > existing tools and libraries. As a general heads up, ACPI 6.3 is out and makes some changes. Discussions I've had in the past suggested there were few systems shipping with 6.2 HMAT and that many firmwares would start at 6.3. Of course, that might not be true, but there was fairly wide participation in the meeting so fingers crossed it's accurate. https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf Particular points to note: 1. Most of the Memory Proximity Domain Attributes Structure was deprecated. This includes the reservation hint which has been replaced with a new mechanism (not used in this patch set) 2. Base units for latency changed to picoseconds. There is a lot more explanatory text around how those work. 3. The measurements of latency and bandwidth no longer have an 'aggregate performance' version. Given the work load was not described this never made any sense. Better for a knowledgeable bit of software to work out it's own estimate. 4. There are now Generic Initiator Domains that have neither memory nor processors. I'll come back with proposals on handling those soon if no one beats me to it. (I think it's really easy but may be wrong ;) I've not really thought out how this series applies to GI only domains yet. Probably not useful to know you have an accelerator near to particular memory if you are deciding where to pin your host processor task ;) Jonathan > > Keith Busch (10): > acpi: Create subtable parsing infrastructure > acpi: Add HMAT to generic parsing tables > acpi/hmat: Parse and report heterogeneous memory > node: Link memory nodes to their compute nodes > acpi/hmat: Register processor domain to its memory > node: Add heterogenous memory access attributes > acpi/hmat: Register performance attributes > node: Add memory caching attributes > acpi/hmat: Register memory side cache attributes > doc/mm: New documentation for memory performance > > Documentation/ABI/stable/sysfs-devices-node | 87 - > Documentation/admin-guide/mm/numaperf.rst | 167 > arch/arm64/kernel/acpi_numa.c | 2 +- > arch/arm64/kernel/smp.c | 4 +- > arch/ia64/kernel/acpi.c | 12 +- > arch/x86/kernel/acpi/boot.c | 36 +- > drivers/acpi/Kconfig | 1 + > drivers/acpi/Makefile | 1 + > drivers/acpi/hmat/Kconfig | 9 + > drivers/acpi/hmat/Makefile| 1 + > drivers/acpi/hmat/hmat.c | 537 >
[PATCH V6 1/4] dt-bindings: fsl: scu: add thermal binding
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and thermal sensors etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get temperature from thermal sensors, this patch adds
binding doc for i.MX system controller thermal driver.
Signed-off-by: Anson Huang
Reviewed-by: Rob Herring
---
ChangeLog since V5:
- add "imx,sensor-resource-id" in each thermal zone to pass resource ID
for thermal driver.
---
.../devicetree/bindings/arm/freescale/fsl,scu.txt| 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 72d481c..4b79751 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -122,6 +122,20 @@ RTC bindings based on SCU Message Protocol
Required properties:
- compatible: should be "fsl,imx8qxp-sc-rtc";
+Thermal bindings based on SCU Message Protocol
+
+
+Required properties:
+- compatible : Must be "fsl,imx8qxp-sc-thermal";
+- tsens-num : Total number of thermal sensors supported;
+- #thermal-sensor-cells : Should be 1. See
+ Documentation/devicetree/bindings/thermal/thermal.txt
+ for a description.
+- imx,sensor-resource-id : This property should be defined in each thermal zone
+ of thermal-zones node, it passes each thermal zone's
+ resource id for thermal driver to get temperature via
+ SCU IPC.
+
Example (imx8qxp):
-
lsio_mu1: mailbox@5d1c {
@@ -168,6 +182,12 @@ firmware {
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
+
+ tsens: thermal-sensor {
+ compatible = "fsl,imx8qxp-sc-thermal";
+ tsens-num = <1>;
+ #thermal-sensor-cells = <1>;
+ };
};
};
--
2.7.4
Re: [PATCH] drivers: base: add support to skip power management in device/driver model
On Wed, 6 Feb 2019 at 16:09, Sudeep Holla wrote:
>
> All device objects in the driver model contain fields that control the
> handling of various power management activities. However, it's not
> always useful. There are few instances where pseudo devices are added
> to the model just to take advantage of many other features like
> kobjects, udev events, and so on. One such example is cpu devices and
> their caches.
>
> The sysfs for the cpu caches are managed by adding devices with cpu
> as the parent in cpu_device_create() when secondary cpu is brought
> online. Generally when the secondary CPUs are hotplugged back in as part
> of resume from suspend-to-ram, we call cpu_device_create() from the cpu
> hotplug state machine while the cpu device associated with that CPU is
> not yet ready to be resumed as the device_resume() call happens bit
> later. It's not really needed to set the flag is_prepared for cpu
> devices as they are mostly pseudo device and hotplug framework deals
> with state machine and not managed through the cpu device.
What's the point of removing and then re-adding the sysfs attributes
for the cpu caches, at each hotplug off/on sequence? To me that sounds
inefficient and unnecessary, no?
If you avoid this, would that solve this problem?
Kind regards
Uffe
>
> This often results in annoying warning when resuming:
> Enabling non-boot CPUs ...
> CPU1: Booted secondary processor
> cache: parent cpu1 should not be sleeping
> CPU1 is up
> CPU2: Booted secondary processor
> cache: parent cpu2 should not be sleeping
> CPU2 is up
> and so on.
>
> So in order to fix these kind of errors, we could just completely avoid
> doing any power management related initialisations and operations if
> they are not used by these devices.
>
> Lets add no_pm_required flags to indicate that the device doesn't
> require any sort of pm activities and all of them can be completely
> skipped. We can use the same flag to also avoid adding not used *power*
> sysfs entries for these devices.
>
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Sudeep Holla
> ---
> drivers/base/cpu.c | 2 ++
> drivers/base/power/main.c | 7 +++
> drivers/base/power/sysfs.c | 4
> include/linux/device.h | 10 ++
> include/linux/pm.h | 1 +
> 5 files changed, 24 insertions(+)
>
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index eb9443d5bae1..ccec353aa24c 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -379,6 +379,7 @@ int register_cpu(struct cpu *cpu, int num)
> cpu->dev.bus->uevent = cpu_uevent;
> #endif
> cpu->dev.groups = common_cpu_attr_groups;
> + device_set_pm_not_required(>dev);
> if (cpu->hotpluggable)
> cpu->dev.groups = hotplugable_cpu_attr_groups;
> error = device_register(>dev);
> @@ -427,6 +428,7 @@ __cpu_device_create(struct device *parent, void *drvdata,
> dev->parent = parent;
> dev->groups = groups;
> dev->release = device_create_release;
> + device_set_pm_not_required(dev);
> dev_set_drvdata(dev, drvdata);
>
> retval = kobject_set_name_vargs(>kobj, fmt, args);
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 0992e67e862b..2a29c3d4e240 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -124,6 +124,10 @@ void device_pm_unlock(void)
> */
> void device_pm_add(struct device *dev)
> {
> + /* No need to create pm sysfs if explicitly specified as not required
> */
> + if (device_pm_not_required(dev))
> + return;
> +
> pr_debug("PM: Adding info for %s:%s\n",
> dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
> device_pm_check_callbacks(dev);
> @@ -142,6 +146,9 @@ void device_pm_add(struct device *dev)
> */
> void device_pm_remove(struct device *dev)
> {
> + if (device_pm_not_required(dev))
> + return;
> +
> pr_debug("PM: Removing info for %s:%s\n",
> dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
> complete_all(>power.completion);
> diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
> index d713738ce796..6cd159b51114 100644
> --- a/drivers/base/power/sysfs.c
> +++ b/drivers/base/power/sysfs.c
> @@ -648,6 +648,10 @@ int dpm_sysfs_add(struct device *dev)
> {
> int rc;
>
> + /* No need to create pm sysfs if explicitly disabled */
> + if (device_pm_not_required(dev))
> + return 0;
> +
> rc = sysfs_create_group(>kobj, _attr_group);
> if (rc)
> return rc;
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 6cb4640b6160..739d0b62e4d4 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -1165,6 +1165,16 @@ static inline bool device_async_suspend_enabled(struct
> device *dev)
> return !!dev->power.async_suspend;
> }
>
>
[PATCH V6 4/4] arm64: dts: imx: add i.MX8QXP thermal support
Add i.MX8QXP CPU thermal zone support.
Signed-off-by: Anson Huang
---
ChangeLog since V5:
- add a property in each thermal zone to pass resource ID for thermal
driver.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 4c3dd95..88eb04b 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <>;
@@ -116,6 +117,12 @@
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
+
+ tsens: thermal-sensor {
+ compatible = "fsl,imx8qxp-sc-thermal";
+ tsens-num = <1>;
+ #thermal-sensor-cells = <1>;
+ };
};
timer {
@@ -443,4 +450,25 @@
power-domains = < IMX_SC_R_GPIO_7>;
};
};
+
+ thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = < 0>;
+ imx,sensor-resource-id = <355>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
};
--
2.7.4
[PATCH V6 3/4] defconfig: arm64: add i.MX system controller thermal support
This patch enables CONFIG_IMX_SC_THERMAL as module. Signed-off-by: Anson Huang --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 709e8f1..4c79832 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -413,6 +413,7 @@ CONFIG_SENSORS_INA2XX=m CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y +CONFIG_IMX_SC_THERMAL=m CONFIG_ROCKCHIP_THERMAL=m CONFIG_RCAR_THERMAL=y CONFIG_RCAR_GEN3_THERMAL=y -- 2.7.4
Re: [PATCH 5/5] sched/fair: Skip LLC nohz logic for asymmetric systems
On Wed, Feb 06, 2019 at 05:26:06PM +, Valentin Schneider wrote:
> Hi,
>
> On 06/02/2019 16:14, Peter Zijlstra wrote:
> [...]
> >> @@ -9545,6 +9545,17 @@ static void nohz_balancer_kick(struct rq *rq)
> >>}
> >>
> >>rcu_read_lock();
> >> +
> >> + if (static_branch_unlikely(_asym_cpucapacity))
> >> + /*
> >> + * For asymmetric systems, we do not want to nicely balance
> >> + * cache use, instead we want to embrace asymmetry and only
> >> + * ensure tasks have enough CPU capacity.
> >> + *
> >> + * Skip the LLC logic because it's not relevant in that case.
> >> + */
> >> + goto check_capacity;
> >> +
> >>sds = rcu_dereference(per_cpu(sd_llc_shared, cpu));
> >>if (sds) {
> >>/*
> >
> > Since (before this) the actual order of the various tests doesn't
> > matter, it's a logical cascade of conditions for which to KICK_MASK.
> >
>
> Ah, I assumed the order did matter somewhat with the "cheaper" LLC check
> first and the more costly loops further down in case we are still looking
> for a reason to do a kick.
I did not in fact consider that; I only looked at the logical structure
of the thing. You might want to double check :-)
> > We can easily reorder and short-circuit the cascase like so, no?
> >
> > The only concern is if sd_llc_shared < sd_asym_capacity; in which case
> > we just lost a balance opportunity. Not sure how to best retain that
> > though.
> >
>
> I'm afraid I don't follow - we don't lose a balance opportunity with the
> below change (compared to the original patch), do we?
What if each big/little cluster would have multiple cache domains? Would
we not want to spread the cache usage inside the big/little resp. ?
Re: [PATCH 4/5] sched/fair: Tune down misfit nohz kicks
On Wed, Feb 06, 2019 at 05:25:31PM +, Valentin Schneider wrote:
> Hi,
>
> On 06/02/2019 16:04, Peter Zijlstra wrote:
> [...]
> >> @@ -9561,6 +9573,14 @@ static void nohz_balancer_kick(struct rq *rq)
> >
> > sd = rcu_dereference(rq->sd);
> > if (sd) {
> > if ((rq->cfs.h_nr_running >= 1) &&
> > check_cpu_capacity(rq, sd)) {
> > flags = NOHZ_KICK_MASK;
> > goto unlock;
> >>}
> >>}
> >>
> >> + sd = rcu_dereference(per_cpu(sd_asym_cpucapacity, cpu));
> >> + if (sd) {
> >> + if (check_misfit_status(rq, sd)) {
> >> + flags = NOHZ_KICK_MASK;
> >> + goto unlock;
> >> + }
> >> + }
> >
> > So while the exact @sd to use for check_cpu_capacity() likely doesn't
> > matter; this is a 'implicit' test for actually having asym_capacity.
> >
>
> I did feel compelled to use the "right" @sd to have a coherent
> imbalance_pct being used - on big.LITTLE, the @sd above this hunk would be
> MC (117 imbalance_pct) whereas the sd_asym_cpucapacity one would be
> DIE (125 imbalance_pct).
Fair enough.
> > @@ -9606,6 +9614,10 @@ static void nohz_balancer_kick(struct rq
> >
> > sd = rcu_dereference(per_cpu(sd_asym_packing, cpu));
> > if (sd) {
> > + /*
> > +* When ASYM_PACKING; see if there's a more preferred CPU going
> > +* idle; in which case, kick the ILB to move tasks around.
> > +*/
>
> s/going idle/currently idle/, no?
Yah.. D'0h..
> > for_each_cpu_and(i, sched_domain_span(sd), nohz.idle_cpus_mask)
> > {
> > if (sched_asym_prefer(i, cpu)) {
> > flags = NOHZ_KICK_MASK;
> >
[PATCH] mtd: rawnand: call onfi_fill_data_interface() once again after nand_detect
nand_scan_ident() calls onfi_fill_data_interface() at its entry
to set up the initial timing parameters.
The timing parameters are needed not only for ->setup_data_interface(),
but also for giving the correct delay to NAND_OP_WAIT_RDY, for example.
If the driver sets the NAND_KEEP_TIMINGS flag, or does not support
->setup_data_interface() hook, those parameters will never updated.
Before nand_detect(), we never know whether the chip is ONFi or not.
So, onfi_fill_data_interface() has to assume the worst case, i.e.
non-ONFi.
After nand_detect(), if the chip turns out to be ONFi-compliant,
we can optimize tPROG_max, tBERS_max, etc.
Call onfi_fill_data_interface() once again.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/raw/nand_base.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 9b3d7ff..35e543c 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5040,6 +5040,9 @@ static int nand_scan_ident(struct nand_chip *chip,
unsigned int maxchips,
nand_deselect_target(chip);
+ /* If the chip turns out ONFi, we can optimize timing parameters. */
+ onfi_fill_data_interface(chip, NAND_SDR_IFACE, 0);
+
/* Check for a chip array */
for (i = 1; i < maxchips; i++) {
u8 id[2];
--
2.7.4
Re: [PATCH v2] zcrypt: handle AP Info notification from CHSC SEI command
On Wed, 6 Feb 2019 16:31:26 -0500 Tony Krowiak wrote: > The current AP bus implementation periodically polls the AP configuration > to detect changes. When the AP configuration is dynamically changed via the > SE or an SCLP instruction, the changes will not be reflected to sysfs until > the next time the AP configuration is polled. The CHSC architecture > provides a Store Event Information (SEI) command to make notification of an > AP configuration change. This patch introduces a handler to process > notification from the CHSC SEI command by immediately kicking off an AP bus > scan-after-event. > > Signed-off-by: Tony Krowiak > Reviewed-by: Halil Pasic > Reviewed-by: Sebastian Ott > --- > arch/s390/include/asm/ap.h | 11 +++ > drivers/s390/cio/chsc.c | 13 + > drivers/s390/crypto/ap_bus.c | 11 +++ > 3 files changed, 35 insertions(+) Reviewed-by: Cornelia Huck
Re: [PATCH 4/6] mfd: Add support for the MediaTek MT6358 PMIC
Hi Lee,
On 07/02/2019 09:34, Lee Jones wrote:
> Thomas, et al.,
>
> Please could you take a look at this?
>
> I need some IRQ related guidance. TIA.
>
> On Wed, 30 Jan 2019, Hsin-Hsiung Wang wrote:
>
>> This adds support for the MediaTek MT6358 PMIC. This is a
>> multifunction device with the following sub modules:
>>
>> - Regulator
>> - RTC
>> - Codec
>> - Interrupt
>>
>> It is interfaced to the host controller using SPI interface
>> by a proprietary hardware called PMIC wrapper or pwrap.
>> MT6358 MFD is a child device of the pwrap.
>>
>> Signed-off-by: Hsin-Hsiung Wang
>> ---
>> drivers/mfd/Makefile |2 +-
>> drivers/mfd/mt6358-irq.c | 236 +
>> drivers/mfd/mt6397-core.c| 62 +-
>> include/linux/mfd/mt6358/core.h | 158 +++
>> include/linux/mfd/mt6358/registers.h | 1926
>> ++
>> include/linux/mfd/mt6397/core.h |3 +
>> 6 files changed, 2385 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/mfd/mt6358-irq.c
>> create mode 100644 include/linux/mfd/mt6358/core.h
>> create mode 100644 include/linux/mfd/mt6358/registers.h
>>
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index 088e249..50be021 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -230,7 +230,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
>> obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
>> obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
>> obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o
>> -obj-$(CONFIG_MFD_MT6397)+= mt6397-core.o mt6397-irq.o
>> +obj-$(CONFIG_MFD_MT6397)+= mt6397-core.o mt6397-irq.o mt6358-irq.o
>>
>> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
>> obj-$(CONFIG_MFD_SUN4I_GPADC) += sun4i-gpadc.o
>> diff --git a/drivers/mfd/mt6358-irq.c b/drivers/mfd/mt6358-irq.c
>> new file mode 100644
>> index 000..b29fdc1
>> --- /dev/null
>> +++ b/drivers/mfd/mt6358-irq.c
>> @@ -0,0 +1,236 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +//
>> +// Copyright (c) 2019 MediaTek Inc.
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static struct irq_top_t mt6358_ints[] = {
>> +MT6358_TOP_GEN(BUCK),
>> +MT6358_TOP_GEN(LDO),
>> +MT6358_TOP_GEN(PSC),
>> +MT6358_TOP_GEN(SCK),
>> +MT6358_TOP_GEN(BM),
>> +MT6358_TOP_GEN(HK),
>> +MT6358_TOP_GEN(AUD),
>> +MT6358_TOP_GEN(MISC),
>> +};
>
> What is a 'top' IRQ?
>
>> +static int parsing_hwirq_to_top_group(unsigned int hwirq)
>> +{
>> +int top_group;
>> +
>> +for (top_group = 1; top_group < ARRAY_SIZE(mt6358_ints); top_group++) {
>> +if (mt6358_ints[top_group].hwirq_base > hwirq) {
>> +top_group--;
>> +break;
>> +}
>> +}
>> +return top_group;
>> +}
>
> This function is going to need some comments. Why do you start at LDO
> instead of the top entry, BUCK?
It also begs the question: why isn't that directly associated to the
irq_data structure? Something is fishy here. In general, if you have to
iterate over anything, you're likely to be doing the wrong thing.
>
>> +static void pmic_irq_enable(struct irq_data *data)
>> +{
>> +unsigned int hwirq = irqd_to_hwirq(data);
>> +struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
>> +struct pmic_irq_data *irq_data = chip->irq_data;
>> +
>> +irq_data->enable_hwirq[hwirq] = 1;
>> +}
>
> I see that you're doing your own caching operations. Is that
> required? I think I'm going to stop here and as for some IRQ guy's
> input on this.
Dunno either. I thought that's what regmap was for?
>
>> +static void pmic_irq_disable(struct irq_data *data)
>> +{
>> +unsigned int hwirq = irqd_to_hwirq(data);
>> +struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
>> +struct pmic_irq_data *irq_data = chip->irq_data;
>> +
>> +irq_data->enable_hwirq[hwirq] = 0;
>> +}
>> +
>> +static void pmic_irq_lock(struct irq_data *data)
>> +{
>> +struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
>> +
>> +mutex_lock(>irqlock);
>> +}
>> +
>> +static void pmic_irq_sync_unlock(struct irq_data *data)
>> +{
>> +unsigned int i, top_gp, en_reg, int_regs, shift;
>> +struct mt6397_chip *chip = irq_data_get_irq_chip_data(data);
>> +struct pmic_irq_data *irq_data = chip->irq_data;
I really wish you kept the symbol "irq_data" for something that is a
struct irq_data. This is making the code pointlessly obfuscated.
>> +
>> +for (i = 0; i < irq_data->num_pmic_irqs; i++) {
>> +if (irq_data->enable_hwirq[i] ==
>> +irq_data->cache_hwirq[i])
>> +continue;
Please explain what you are trying to do here. The unlock operation is
supposed to affect exactly one interrupt. Instead, you seem to deal with
a
Re: [PATCH 1/2] mtd: spi-nor: Add support for EN25Q80A
Hi Tudor,
On 03.02.19 14:33, tudor.amba...@microchip.com wrote:
> Hi, Frieder,
>
> On 01/23/2019 09:56 AM, Schrempf Frieder wrote:
>> From: Frieder Schrempf
>>
>> This adds support for the EON EN25Q80A, a 8Mb SPI NOR chip.
>
> I would suggest to specify who is using this flash and how did you test it.
> This
> way we will not end up with support for flashes that are not actually used.
Ok. The flash is used by a board that I plan to upstream. Maybe I should
just resubmit this together with the actual board support patches?
Likewise for my other patch (MX25V8035F), this is for another board I
plan to upstream soon.
>
>>
>> Signed-off-by: Frieder Schrempf
>> ---
>> drivers/mtd/spi-nor/spi-nor.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index 6e13bbd1aaa5..aa8a04293a25 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -1737,6 +1737,8 @@ static const struct flash_info spi_nor_ids[] = {
>> /* EON -- en25xxx */
>> { "en25f32",INFO(0x1c3116, 0, 64 * 1024, 64, SECT_4K) },
>> { "en25p32",INFO(0x1c2016, 0, 64 * 1024, 64, 0) },
>> +{ "en25q80a", INFO(0x1c3014, 0, 64 * 1024, 16,
>> +SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
>
> I'm reading EN25Q80A Rev. H, Issue Date: 2012/10/23
> datasheet. I don't see the bfpt table described, so probably it doesn't
> support
> it. The flash advertises SPINOR_OP_READ_1_4_4 (0xeb), but not
> SPINOR_OP_READ_1_1_4 (0x6b). In spi_nor_init_params(), when SPI_NOR_QUAD_READ
> is
> set, we assume that SNOR_HWCAPS_READ_1_1_4 is supported, so we will use 0x6b
> for
> quad reads. I can't see how the flash works with 0x6b, unless there is a bfpt
> table that indicates support for 0xebh.
>
> If it does support bfpt, set just SECT_4K | SPI_NOR_DUAL_READ, the latter will
> trigger the bfpt parsing.
Thanks for explaining this. I missed the point, that SPI_NOR_QUAD_READ
actually requires support for SPINOR_OP_READ_1_1_4.
>
> If you will resubmit, please order the entry in alphabetical order, by name.
Ok.
Thanks,
Frieder
[GIT PULL] HID fix
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus to receive fix for a bug in hid-debug that can lock up the kernel in infinite loop (CVE-2019-3819), from Vladis Dronov. Thanks. Vladis Dronov (1): HID: debug: fix the ring buffer implementation drivers/hid/hid-debug.c | 120 ++ include/linux/hid-debug.h | 9 ++-- 2 files changed, 51 insertions(+), 78 deletions(-) -- Jiri Kosina SUSE Labs
Re: [PATCH 07/22] x86/fpu: Remove fpu->initialized
On 2019-02-06 15:01:14 [+0100], Borislav Petkov wrote:
> On Tue, Feb 05, 2019 at 07:03:37PM +0100, Sebastian Andrzej Siewior wrote:
> > Well, nothing changes in regard to the logic. Earlier we had a variable
> > which helped us to distinguish between user & kernel thread. Now we have
> > a different one.
> > I'm going to add a comment to switch_fpu_prepare() about ->mm since you
> > insist but I would like to avoid it.
>
> I don't understand what that aversion is towards commenting stuff,
> especially important stuff like the meaning of the presence of ->mm for
> the FPU code. What is the downside to documenting that?
I don't like commenting the obvious things in code but I might be wrong
on what I consider here obvious. The important part is probably that we
don't save/restore FPU registers for kernel threads but this isn't new,
it was always like that (more or less implicit). The ->mm part is an
implementation detail (and is used in other places).
That said I already added this:
|@@ -525,11 +525,14 @@ static inline void fpregs_activate(struc
| *
| * - switch_fpu_finish() restores the new state as
| *necessary.
|+ *
|+ * The FPU context is only stored/restore for user task and ->mm is used to
|+ * distinguish between kernel and user threads.
| */
| static inline void
| switch_fpu_prepare(struct fpu *old_fpu, int cpu)
| {
and I *think* that this is enough. This *what* we do and not *why*. I
don't have an answer towards *why*.
> Considering that in this very thread we ourselves encountered the fact
> that stuff is not documented and we complained that it wasn't!
Yes. We had no idea why we save the FPU registers on user's stack during
signal handling. Was this an implementation detail on kernel side as
part of signal handling or is this required/ expected by the user as
part of a use case? We have now the explanation that signals may
cascade. Do we know by now if userland is supposed to use it or it
accessed the register because they were available?
The MPX code did access the MPX part of the xsave area (others do it for
"testing/debug" as per my I google research). This kind of things should
be part of the ABI document and not only a comment in the kernel.
Are the MAGIC constants only in-kernel use (to check if the user
accidentally overwrote its stack) or should be checked by the user
during signal handling to ensure that the xsave area is available.
> > We have a comment, it is just not helping.
>
> Why is it not helping?
The part you referred to was:
|- /* Update the thread's fxstate to save the fsave header. */
|- if (ia32_fxstate)
|- copy_fxregs_to_kernel(fpu);
and it is not helping because it does not explain why it is done. I can
see based on the code that the FXstate is saved in case of a 32bit
frame. It is saved into thread's state. It does not explain why it
needs to be done. That is the "not helping" part.
> > Steven said on IRC that it can be removed.
>
> Did he give an explanation why is it ok?
I can forward you the IRC pieces offlist if you like. He said I can
remove it if there are no users and I am not aware of any. He pointed
out that sched_wakeup had a "success" member which was relied on by
tools so it remained in order not to break them. So we have
__entry->success= 1; /* rudiment, kill when possible */
in the tree now. I can loop him in if this is not enough.
> Thx.
Sebastian
[PATCH] ARM: dts: at91: sama5d2: add labels to soc dtsi for derivative boards
This adds labels to commonly used device-tree nodes so that derivative
boards can avoid ahb/apb hierarchy.
Signed-off-by: Nicolas Ferre
---
arch/arm/boot/dts/sama5d2.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index d159ee42ef29..9519b9d5abca 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -688,13 +688,13 @@
ranges = <0 0xf8044000 0x1420>;
};
- rstc@f8048000 {
+ reset_controller: rstc@f8048000 {
compatible = "atmel,sama5d3-rstc";
reg = <0xf8048000 0x10>;
clocks = <>;
};
- shdwc@f8048010 {
+ shutdown_controller: shdwc@f8048010 {
compatible = "atmel,sama5d2-shdwc";
reg = <0xf8048010 0x10>;
clocks = <>;
@@ -710,7 +710,7 @@
clocks = < PMC_TYPE_CORE PMC_MCK2>;
};
- watchdog@f8048040 {
+ watchdog: watchdog@f8048040 {
compatible = "atmel,sama5d4-wdt";
reg = <0xf8048040 0x10>;
interrupts = <4 IRQ_TYPE_LEVEL_HIGH 7>;
--
2.17.1
Re: [PATCH] mtd: rawnand: call onfi_fill_data_interface() once again after nand_detect
Hi Masahiro,
Masahiro Yamada wrote on Thu, 7 Feb
2019 18:57:56 +0900:
> nand_scan_ident() calls onfi_fill_data_interface() at its entry
> to set up the initial timing parameters.
>
> The timing parameters are needed not only for ->setup_data_interface(),
> but also for giving the correct delay to NAND_OP_WAIT_RDY, for example.
>
> If the driver sets the NAND_KEEP_TIMINGS flag, or does not support
> ->setup_data_interface() hook, those parameters will never updated.
^ be
>
> Before nand_detect(), we never know whether the chip is ONFi or not.
> So, onfi_fill_data_interface() has to assume the worst case, i.e.
> non-ONFi.
s/ONFi/ONFI/?
>
> After nand_detect(), if the chip turns out to be ONFi-compliant,
> we can optimize tPROG_max, tBERS_max, etc.
>
> Call onfi_fill_data_interface() once again.
Sorry but I don't get why this is needed as there is the same call at
the top of this function. Can you be more specific on where/when the
missing call produces a failure?
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/mtd/nand/raw/nand_base.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index 9b3d7ff..35e543c 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -5040,6 +5040,9 @@ static int nand_scan_ident(struct nand_chip *chip,
> unsigned int maxchips,
>
> nand_deselect_target(chip);
>
> + /* If the chip turns out ONFi, we can optimize timing parameters. */
> + onfi_fill_data_interface(chip, NAND_SDR_IFACE, 0);
> +
> /* Check for a chip array */
> for (i = 1; i < maxchips; i++) {
> u8 id[2];
Thanks,
Miquèl
Re: [PATCH 1/2] mtd: spi-nor: Add support for EN25Q80A
Hi, Frieder, On 02/07/2019 12:06 PM, Schrempf Frieder wrote: > Hi Tudor, > > On 03.02.19 14:33, tudor.amba...@microchip.com wrote: >> Hi, Frieder, >> >> On 01/23/2019 09:56 AM, Schrempf Frieder wrote: >>> From: Frieder Schrempf >>> >>> This adds support for the EON EN25Q80A, a 8Mb SPI NOR chip. >> I would suggest to specify who is using this flash and how did you test it. >> This >> way we will not end up with support for flashes that are not actually used. > Ok. The flash is used by a board that I plan to upstream. Maybe I should > just resubmit this together with the actual board support patches? > > Likewise for my other patch (MX25V8035F), this is for another board I > plan to upstream soon. > Sounds good. Cheers, ta
Re: [PATCH v5 2/2] pwm: sifive: Add a driver for SiFive SoC PWM
Hello,
On Tue, Jan 29, 2019 at 05:13:19PM +0530, Yash Shah wrote:
> Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC.
>
> Signed-off-by: Wesley W. Terpstra
> [Atish: Various fixes and code cleanup]
> Signed-off-by: Atish Patra
> Signed-off-by: Yash Shah
> ---
> drivers/pwm/Kconfig | 11 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-sifive.c | 261
> +++
> 3 files changed, 273 insertions(+)
> create mode 100644 drivers/pwm/pwm-sifive.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index a8f47df..4a61d1a 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -380,6 +380,17 @@ config PWM_SAMSUNG
> To compile this driver as a module, choose M here: the module
> will be called pwm-samsung.
>
> +config PWM_SIFIVE
> + tristate "SiFive PWM support"
> + depends on OF
> + depends on COMMON_CLK
> + depends on RISCV || COMPILE_TEST
> + help
> + Generic PWM framework driver for SiFive SoCs.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-sifive.
> +
> config PWM_SPEAR
> tristate "STMicroelectronics SPEAr PWM support"
> depends on PLAT_SPEAR
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 9c676a0..30089ca 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o
> obj-$(CONFIG_PWM_RENESAS_TPU)+= pwm-renesas-tpu.o
> obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
> obj-$(CONFIG_PWM_SAMSUNG)+= pwm-samsung.o
> +obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o
> obj-$(CONFIG_PWM_SPEAR) += pwm-spear.o
> obj-$(CONFIG_PWM_STI)+= pwm-sti.o
> obj-$(CONFIG_PWM_STM32) += pwm-stm32.o
> diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
> new file mode 100644
> index 000..2b516f7
> --- /dev/null
> +++ b/drivers/pwm/pwm-sifive.c
> @@ -0,0 +1,261 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017-2018 SiFive
> + * For SiFive's PWM IP block documentation please refer Chapter 14 of
> + * Reference Manual : https://static.dev.sifive.com/FU540-C000-v1.0.pdf
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Register offsets */
> +#define PWM_SIFIVE_PWMCFG0x0
> +#define PWM_SIFIVE_PWMCOUNT 0x8
> +#define PWM_SIFIVE_PWMS 0x10
> +#define PWM_SIFIVE_PWMCMP0 0x20
> +
> +/* PWMCFG fields */
> +#define PWM_SIFIVE_PWMCFG_SCALE 0
> +#define PWM_SIFIVE_PWMCFG_STICKY 8
> +#define PWM_SIFIVE_PWMCFG_ZERO_CMP 9
> +#define PWM_SIFIVE_PWMCFG_DEGLITCH 10
> +#define PWM_SIFIVE_PWMCFG_EN_ALWAYS 12
> +#define PWM_SIFIVE_PWMCFG_EN_ONCE13
> +#define PWM_SIFIVE_PWMCFG_CENTER 16
> +#define PWM_SIFIVE_PWMCFG_GANG 24
> +#define PWM_SIFIVE_PWMCFG_IP 28
> +
> +/* SIZE_PWMCMP is used to calculate the offset for pwmcmpX registers */
> +#define SIZE_PWMCMP 4
> +#define CMPWIDTH 16
Please add a PWM_SIFIVE_ prefix to these two.
> +struct pwm_sifive_ddata {
> + struct pwm_chip chip;
> + struct notifier_block notifier;
> + struct clk *clk;
> + void __iomem *regs;
> + unsigned int approx_period;
> + unsigned int real_period;
> +};
> +
> +static inline struct pwm_sifive_ddata *to_pwm_sifive_chip(struct pwm_chip *c)
even though this is inlined I would like this to have use the
pwm_sifive_ prefix, too.
> +{
> + return container_of(c, struct pwm_sifive_ddata, chip);
> +}
> +
> +static void pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device
> *dev,
> + struct pwm_state *state)
> +{
> + struct pwm_sifive_ddata *pwm = to_pwm_sifive_chip(chip);
> + u32 duty;
> +
> + duty = readl(pwm->regs + PWM_SIFIVE_PWMCMP0 + dev->hwpwm * SIZE_PWMCMP);
> +
> + state->period = pwm->real_period;
> + state->duty_cycle = ((u64)duty * pwm->real_period) >> CMPWIDTH;
> + state->polarity = PWM_POLARITY_INVERSED;
> + state->enabled = duty > 0;
> +}
> +
> +static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *dev,
> + struct pwm_state *state)
> +{
> + struct pwm_sifive_ddata *pwm = to_pwm_sifive_chip(chip);
> + unsigned int duty_cycle;
> + u32 frac, val;
> +
> + if (state->polarity != PWM_POLARITY_INVERSED)
> + return -EINVAL;
> +
> + if (state->period != pwm->real_period)
> + return -EINVAL;
> +
> + duty_cycle = state->duty_cycle;
> + if (!state->enabled)
> + duty_cycle = 0;
> +
> + frac = div_u64((u64)duty_cycle * 0x, state->period);
> + frac = min(frac, 0xU);
If CMPWIDTH was only 8, we'd need 0xff here instead of 0x, right? So
better use
(1 << PWM_SIFIVE_CMPWIDTH) - 1
here, maybe
Re: [GIT PULL] x86/mm changes for v4.21
On Wed, Feb 06, 2019 at 04:17:42PM -0800, Luck, Tony wrote:
> fe0937b24ff5 ("x86/mm/cpa: Fold cpa_flush_range() and cpa_flush_array() into
> a single cpa_flush() function")
Boris pointed me at this gem:
c7486104a5ce ("x86/mce: Fix set_mce_nospec() to avoid #GP fault")
(can I just revel at the pure awesome grossness of that)
But we then see my above commit having:
@@ -1732,11 +1685,6 @@ static int change_page_attr_set_clr(unsigned long *addr,
int numpages,
*/
WARN_ON_ONCE(1);
}
- /*
-* Save address for cache flush. *addr is modified in the call
-* to __change_page_attr_set_clr() below.
-*/
- baddr = make_addr_canonical_again(*addr);
Where I clearly got distracted by that excellent comment..
So now the question is where to put it back in, I'm thinking this might
want to be in __cpa_addr().
Something like so?
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 4f8972311a77..319b767484fb 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -230,6 +230,28 @@ static bool __cpa_pfn_in_highmap(unsigned long pfn)
#endif
+/*
+ * Machine check recovery code needs to change cache mode of poisoned
+ * pages to UC to avoid speculative access logging another error. But
+ * passing the address of the 1:1 mapping to set_memory_uc() is a fine
+ * way to encourage a speculative access. So we cheat and flip the top
+ * bit of the address. This works fine for the code that updates the
+ * page tables. But at the end of the process we need to flush the cache
+ * and the non-canonical address causes a #GP fault when used by the
+ * CLFLUSH instruction.
+ *
+ * But in the common case we already have a canonical address. This code
+ * will fix the top bit if needed and is a no-op otherwise.
+ */
+static inline unsigned long make_addr_canonical_again(unsigned long addr)
+{
+#ifdef CONFIG_X86_64
+ return (long)(addr << 1) >> 1;
+#else
+ return addr;
+#endif
+}
+
static unsigned long __cpa_addr(struct cpa_data *cpa, unsigned long idx)
{
if (cpa->flags & CPA_PAGES_ARRAY) {
@@ -244,7 +266,7 @@ static unsigned long __cpa_addr(struct cpa_data *cpa,
unsigned long idx)
if (cpa->flags & CPA_ARRAY)
return cpa->vaddr[idx];
- return *cpa->vaddr + idx * PAGE_SIZE;
+ return make_addr_canonical_again(*cpa->vaddr + idx * PAGE_SIZE);
}
/*
@@ -1627,29 +1649,6 @@ static int __change_page_attr_set_clr(struct cpa_data
*cpa, int checkalias)
return ret;
}
-/*
- * Machine check recovery code needs to change cache mode of poisoned
- * pages to UC to avoid speculative access logging another error. But
- * passing the address of the 1:1 mapping to set_memory_uc() is a fine
- * way to encourage a speculative access. So we cheat and flip the top
- * bit of the address. This works fine for the code that updates the
- * page tables. But at the end of the process we need to flush the cache
- * and the non-canonical address causes a #GP fault when used by the
- * CLFLUSH instruction.
- *
- * But in the common case we already have a canonical address. This code
- * will fix the top bit if needed and is a no-op otherwise.
- */
-static inline unsigned long make_addr_canonical_again(unsigned long addr)
-{
-#ifdef CONFIG_X86_64
- return (long)(addr << 1) >> 1;
-#else
- return addr;
-#endif
-}
-
-
static int change_page_attr_set_clr(unsigned long *addr, int numpages,
pgprot_t mask_set, pgprot_t mask_clr,
int force_split, int in_flag,
Re: [PATCH v5] mfd: tqmx86: IO controller with i2c, wachdog and gpio
On Thu, 07 Feb 2019, Andrew Lunn wrote:
> The QMX86 is a PLD present on some TQ-Systems ComExpress modules. It
> provides 1 or 2 I2C bus masters, 8 GPIOs and a watchdog timer. Add an
> MFD which will instantiate the individual drivers.
>
> Signed-off-by: Andrew Lunn
> ---
> v2:
>
> Drop setting i2c bus speed, which removes the build dependencies on
> the i2c ocores patches. This can be added back later.
>
> v3
>
> Fix indentation of help
> Fix SPDX to match MODULE_LICENSE
> Remove warranty text
> Add my Copyright
> Sort include files
> Add _REG_ to register defines
> Add #defines for all resources
> Replace magic numbers with #defines
> Rename pld_clock to pld_clock_rate
> Remove wrapper around ioread8()/iowrite8()
> Scatter const keyword in a few places
> Remove enum for calls
> Implement lookup for board in tq_board_if
> Rename ioeic to io_ext_int_val to make is more readable
> Handle optional calls in a different way
> Better group code and structures
> Kill all the sysfs attributes
> Use devm_mfd_add_devices()
> Don't exist silently for unknown board ID
>
> Not addressed, waiting for answers:
> MODULE_PARM for GPIO interrupts
> Not using regmap, intel IO not supported by regmap
> Setting GPIO irq on resource structure
> Global tqmx86_pdev
> Jumping through hoops
>
> v4
>
> Remove -- to avoid broken mailer
>
> v5
>
> Remove device data since it is only used in the probe function
> Remove platform data, since it only contains well know values
> Move GPIO IRQ resource first and comment about this assumption
> Fixup platform data naming
> Use true for ignore_resource_conflicts
> Use ARRAY_SIZE for num_resources
> Replace tq_board_info with two functions using switch
> Error out for invalid GPIO IRQ configuration
> Error out if GPIO IRQ cannot be configured in the hardware
> Split registering cells into two calls
> Validate GPIO IRQ using a switch statement, and derive the HW configuration
> ---
> drivers/mfd/Kconfig | 8 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/tqmx86.c | 289 +++
> 3 files changed, 298 insertions(+)
> create mode 100644 drivers/mfd/tqmx86.c
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index f461460a2aeb..226f7eeb2093 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1677,6 +1677,14 @@ config MFD_TC6393XB
> help
> Support for Toshiba Mobile IO Controller TC6393XB
>
> +config MFD_TQMX86
> + tristate "TQ-Systems IO controller TQMX86"
> + select MFD_CORE
> + help
> + Say yes here to enable support for various functions of the
> + TQ-Systems IO controller and watchdog device, found on their
> + ComExpress CPU modules.
> +
> config MFD_VX855
> tristate "VIA VX855/VX875 integrated south bridge"
> depends on PCI
[...]
> +static int tqmx86_board_id_to_clk_rate(u8 board_id)
> +{
> + switch (board_id) {
> + case TQMX86_REG_BOARD_ID_E38M:
> + return 33000;
> + case TQMX86_REG_BOARD_ID_50UC:
> + return 24000;
> + case TQMX86_REG_BOARD_ID_E38C:
> + return 33000;
> + case TQMX86_REG_BOARD_ID_60EB:
> + return 24000;
> + case TQMX86_REG_BOARD_ID_E39M:
> + return 25000;
> + case TQMX86_REG_BOARD_ID_E39C:
> + return 25000;
> + case TQMX86_REG_BOARD_ID_E39x:
> + return 25000;
> + case TQMX86_REG_BOARD_ID_70EB:
> + return 24000;
> + case TQMX86_REG_BOARD_ID_80UC:
> + return 24000;
> + case TQMX86_REG_BOARD_ID_90UC:
> + return 24000;
Nit: What do you think of:
switch (board_id) {
case TQMX86_REG_BOARD_ID_E38M:
case TQMX86_REG_BOARD_ID_E38C:
return 33000;
case TQMX86_REG_BOARD_ID_50UC:
case TQMX86_REG_BOARD_ID_60EB:
case TQMX86_REG_BOARD_ID_70EB:
case TQMX86_REG_BOARD_ID_80UC:
case TQMX86_REG_BOARD_ID_90UC:
return 24000;
case TQMX86_REG_BOARD_ID_E39M:
case TQMX86_REG_BOARD_ID_E39C:
case TQMX86_REG_BOARD_ID_E39x:
return 25000;
> + default:
> + return 0;
> + }
> +}
> +
> +static int tqmx86_probe(struct platform_device *pdev)
> +{
> + u8 board_id, rev, i2c_det, i2c_ien, io_ext_int_val;
> + struct device *dev = >dev;
> + const char *board_name;
> + void __iomem *io_base;
> + int err;
> +
> + io_base = devm_ioport_map(dev, TQMX86_IOBASE, TQMX86_IOSIZE);
> + if (!io_base)
> + return -ENOMEM;
> +
> + board_id = ioread8(io_base + TQMX86_REG_BOARD_ID);
> + board_name = tqmx86_board_id_to_name(board_id);
> + rev = ioread8(io_base + TQMX86_REG_BOARD_REV);
> +
> + dev_info(dev,
> + "Found %s - Board ID %d, PCB Revision %d, PLD Revision %d\n",
> + board_name, board_id, rev >> 4, rev & 0xf);
> +
> + i2c_det = ioread8(io_base + TQMX86_REG_I2C_DETECT);
> + i2c_ien
