[RFC 3/6] drm/i915: Remove local fbdev emulation Kconfig option
DRM_I915_FBDEV config is currently used to enable/disable fbdev emulation for
the i915 kms driver.
Replace this with the top level DRM_FBDEV_EMULATION config option. Using this
config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs
in certain places.
The #ifdef in drm_i915_private struct adding/removing members intel_fbdev and
fbdev_suspend_work has been removed. This helps us use stub drm helper functions
at not much cost.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/i915/Kconfig | 15 ---
drivers/gpu/drm/i915/Makefile| 4 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/intel_display.c | 10 --
drivers/gpu/drm/i915/intel_dp_mst.c | 14 --
drivers/gpu/drm/i915/intel_drv.h | 3 +--
drivers/gpu/drm/i915/intel_fbdev.c | 7 ---
8 files changed, 16 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 74acca9..bd9ccfc 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -45,21 +45,6 @@ config DRM_I915_KMS
If in doubt, say "Y".
-config DRM_I915_FBDEV
- bool "Enable legacy fbdev support for the modesetting intel driver"
- depends on DRM_I915
- select DRM_KMS_FB_HELPER
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
- default y
- help
- Choose this option if you have a need for the legacy fbdev
- support. Note that this support also provide the linux console
- support on top of the intel modesetting driver.
-
- If in doubt, say "Y".
-
config DRM_I915_PRELIMINARY_HW_SUPPORT
bool "Enable preliminary support for prerelease Intel hardware by
default"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f019225..3b3325d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -56,8 +56,8 @@ i915-y += intel_audio.o \
intel_psr.o \
intel_sideband.o \
intel_sprite.o
-i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
-i915-$(CONFIG_DRM_I915_FBDEV) += intel_fbdev.o
+i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
+i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
# modesetting output/encoder code
i915-y += dvo_ch7017.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e8b18e5..0c8bcd7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1772,7 +1772,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
struct intel_fbdev *ifbdev = NULL;
struct intel_framebuffer *fb;
-#ifdef CONFIG_DRM_I915_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct drm_i915_private *dev_priv = dev->dev_private;
ifbdev = dev_priv->fbdev;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8727086..e511fa4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1819,11 +1819,9 @@ struct drm_i915_private {
struct drm_i915_gem_object *vlv_pctx;
-#ifdef CONFIG_DRM_I915_FBDEV
/* list of fbdev register on this device */
struct intel_fbdev *fbdev;
struct work_struct fbdev_suspend_work;
-#endif
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e730789..9cf13e6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8562,7 +8562,6 @@ static struct drm_framebuffer *
mode_fits_in_fbdev(struct drm_device *dev,
struct drm_display_mode *mode)
{
-#ifdef CONFIG_DRM_I915_FBDEV
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj;
struct drm_framebuffer *fb;
@@ -8585,9 +8584,6 @@ mode_fits_in_fbdev(struct drm_device *dev,
return NULL;
return fb;
-#else
- return NULL;
-#endif
}
bool intel_get_load_detect_pipe(struct drm_connector *connector,
@@ -12807,11 +12803,13 @@ intel_user_framebuffer_create(struct drm_device *dev,
return intel_framebuffer_create(dev, mode_cmd, obj);
}
-#ifndef CONFIG_DRM_I915_FBDEV
static inline void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (dev_priv->fbdev)
+ drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
}
-#endif
static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 9f67a37..fe69df0 100644
---
[RFC 4/6] drm/tegra: Remove local fbdev emulation Kconfig option
DRM_TEGRA_FBDEV config is currently used to enable/disable fbdev emulation for
the tegra kms driver.
Replace this with the top level DRM_FBDEV_EMULATION config option. Using this
config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs
in certain places.
The #ifdef in tegra_drm struct that adds/removes the terga_fbdev member has been
removed completely. This helps in calling stub drm fb helper functions at not
much
cost.
We could clean up fb.c a bit further to reduce the number of #ifdefs, but that's
left for later.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/tegra/Kconfig | 12
drivers/gpu/drm/tegra/drm.c | 15 ++-
drivers/gpu/drm/tegra/drm.h | 8
drivers/gpu/drm/tegra/fb.c| 25 ++---
4 files changed, 16 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 74d9d62..63ebb15 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -16,18 +16,6 @@ config DRM_TEGRA
if DRM_TEGRA
-config DRM_TEGRA_FBDEV
- bool "Enable legacy fbdev support"
- select DRM_KMS_FB_HELPER
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- default y
- help
- Choose this option if you have a need for the legacy fbdev support.
- Note that this support also provides the Linux console on top of
- the Tegra modesetting driver.
-
config DRM_TEGRA_DEBUG
bool "NVIDIA Tegra DRM debug support"
help
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 7dd328d..97ebde9 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -104,11 +104,17 @@ static int tegra_atomic_commit(struct drm_device *drm,
return 0;
}
+static inline void tegra_fb_output_poll_changed(struct drm_device *drm)
+{
+ struct tegra_drm *tegra = drm->dev_private;
+
+ if (tegra->fbdev)
+ drm_fb_helper_hotplug_event(&tegra->fbdev->base);
+}
+
static const struct drm_mode_config_funcs tegra_drm_mode_funcs = {
.fb_create = tegra_fb_create,
-#ifdef CONFIG_DRM_TEGRA_FBDEV
.output_poll_changed = tegra_fb_output_poll_changed,
-#endif
.atomic_check = drm_atomic_helper_check,
.atomic_commit = tegra_atomic_commit,
};
@@ -248,11 +254,10 @@ static void tegra_drm_context_free(struct
tegra_drm_context *context)
static void tegra_drm_lastclose(struct drm_device *drm)
{
-#ifdef CONFIG_DRM_TEGRA_FBDEV
struct tegra_drm *tegra = drm->dev_private;
- tegra_fbdev_restore_mode(tegra->fbdev);
-#endif
+ if (tegra->fbdev)
+ drm_fb_helper_restore_fbdev_mode_unlocked(&tegra->fbdev->base);
}
static struct host1x_bo *
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 8cb2dfe..3a92413 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -29,12 +29,10 @@ struct tegra_fb {
unsigned int num_planes;
};
-#ifdef CONFIG_DRM_TEGRA_FBDEV
struct tegra_fbdev {
struct drm_fb_helper base;
struct tegra_fb *fb;
};
-#endif
struct tegra_drm {
struct drm_device *drm;
@@ -45,9 +43,7 @@ struct tegra_drm {
struct mutex clients_lock;
struct list_head clients;
-#ifdef CONFIG_DRM_TEGRA_FBDEV
struct tegra_fbdev *fbdev;
-#endif
unsigned int pitch_align;
@@ -263,10 +259,6 @@ int tegra_drm_fb_prepare(struct drm_device *drm);
void tegra_drm_fb_free(struct drm_device *drm);
int tegra_drm_fb_init(struct drm_device *drm);
void tegra_drm_fb_exit(struct drm_device *drm);
-#ifdef CONFIG_DRM_TEGRA_FBDEV
-void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev);
-void tegra_fb_output_poll_changed(struct drm_device *drm);
-#endif
extern struct platform_driver tegra_dc_driver;
extern struct platform_driver tegra_dsi_driver;
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 397fb34..2eacea2 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -18,7 +18,7 @@ static inline struct tegra_fb *to_tegra_fb(struct
drm_framebuffer *fb)
return container_of(fb, struct tegra_fb, base);
}
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
static inline struct tegra_fbdev *to_tegra_fbdev(struct drm_fb_helper *helper)
{
return container_of(helper, struct tegra_fbdev, base);
@@ -181,7 +181,7 @@ unreference:
return ERR_PTR(err);
}
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
static struct fb_ops tegra_fb_ops = {
.owner = THIS_MODULE,
.fb_fillrect = sys_fillrect,
@@ -371,24 +371,11 @@ static void tegra_fbdev_exit(struct tegra_fbdev *fbdev)
tegra_fbdev_free(fbdev);
}
-void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev)
-{
- if (fbdev)
- drm_fb_helper_restore_fbdev_mode_unlocked(&fbdev->base);
-}
-
-void tegra_fb_output_
[RFC 6/6] drm/sti: Remove local fbdev emulation Kconfig option
DRM_STI_FBDEV config is currently used to enable/disable fbdev emulation for the sti kms driver. Remove this local config option and use the top level DRM_FBDEV_EMULATION config option instead where applicable. We replace the #ifdef in sti_drm_load with CONFIG_DRM_FBDEV_EMULATION. It's probably okay to get remove the #ifdef itself, but just left it here for now to be safe. It can be removed after some testing. Signed-off-by: Archit Taneja --- drivers/gpu/drm/sti/Kconfig | 6 -- drivers/gpu/drm/sti/sti_drm_drv.c | 2 +- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig index fbccc10..e3aa5af 100644 --- a/drivers/gpu/drm/sti/Kconfig +++ b/drivers/gpu/drm/sti/Kconfig @@ -9,9 +9,3 @@ config DRM_STI select FW_LOADER_USER_HELPER_FALLBACK help Choose this option to enable DRM on STM stiH41x chipset - -config DRM_STI_FBDEV - bool "DRM frame buffer device for STMicroelectronics SoC stiH41x Serie" - depends on DRM_STI - help - Choose this option to enable FBDEV on top of DRM for STM stiH41x chipset diff --git a/drivers/gpu/drm/sti/sti_drm_drv.c b/drivers/gpu/drm/sti/sti_drm_drv.c index 5239fa1..90f121d 100644 --- a/drivers/gpu/drm/sti/sti_drm_drv.c +++ b/drivers/gpu/drm/sti/sti_drm_drv.c @@ -76,7 +76,7 @@ static int sti_drm_load(struct drm_device *dev, unsigned long flags) drm_helper_disable_unused_functions(dev); -#ifdef CONFIG_DRM_STI_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION drm_fbdev_cma_init(dev, 32, dev->mode_config.num_crtc, dev->mode_config.num_connector); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
+Cc James Liao
On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
> Sascha Hauer writes:
>
> > Signed-off-by: Sascha Hauer
>
> A bit of a changelog here would be useful describing this driver, that
> it's only covering part of the device (e.g. power controller) with more
> to come, dependency on the syscon driver, etc.
>
> > +/*
> > + * The Infracfg unit has bus protection bits. We enable the bus protection
> > + * for disabled power domains so that the system does not hang when some
> > unit
> > + * accesses the bus while in power down.
> > + */
>
> Hmm, why don't you want to know if some device is accessing another
> device which is in a domain that is powered down? Seems like this is a
> good way to hide real bugs.
How I understand it the system just hangs on erroneous accesses without
these protection bits enabled, so enabling them at least makes sure we
can output something.
I must admit though that my understanding of these bits is quite limited
and the only user of this driver I have available here (audio) doesn't
make use of these protection bits, so I can't test here.
James, could you shed some light on this issue?
> > + val = readl(ctl_addr);
> > + val |= PWR_ON_BIT;
> > + writel(val, ctl_addr);
> > + val |= PWR_ON_2ND_BIT;
> > + writel(val, ctl_addr);
> > +
> > + /* wait until PWR_ACK = 1 */
> > + expired = jiffies + HZ;
> > + while (!(readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
> > + !(readl(scp->base + SPM_PWR_STATUS_2ND) &
> > data->sta_mask)) {
> > + cpu_relax();
> > + if (time_after(jiffies, expired))
> > + return -EIO;
>
> hmm, seems like you'd want a dev_warn() or simliar here if this times
> out and fails. There's a bunch of these below too.
Ok, will add.
> > + /* Clear bus protection bits */
> > + if (data->bus_prot_mask) {
> > + u32 mask = data->bus_prot_mask;
> > + struct regmap *infracfg = scp->infracfg;
> > +
> > + regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
> > +
> > + expired = jiffies + HZ;
> > +
> > + while (1) {
> > + u32 val;
> > +
> > + ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1,
> > &val);
> > + if (ret)
> > + return ret;
> > +
> > + if (!(val & mask))
> > + break;
> > +
> > + cpu_relax();
> > + if (time_after(jiffies, expired))
> > + return -EIO;
> > + }
> > + }
>
> This whole "Clear bus protection bits" part seems like it should be an
> API in the infracfg driver.
Ok, can do.
>
> > + return 0;
> > +}
> > +
> > +static int scpsys_power_off(struct generic_pm_domain *genpd)
> > +{
> > + struct scp_domain *scpd = container_of(genpd, struct scp_domain, pmd);
> > + struct scp *scp = scpd->scp;
> > + struct scp_domain_data *data = scpd->data;
> > + unsigned long expired;
> > + void __iomem *ctl_addr = scpd->scp->base + data->ctl_offs;
> > + u32 sram_pdn_ack = data->sram_pdn_ack_bits;
> > + u32 val;
> > + int ret;
> > +
> > + /* set bus protection bits */
> > + if (data->bus_prot_mask) {
> > + struct regmap *infracfg = scp->infracfg;
> > + u32 mask = data->bus_prot_mask;
> > +
> > + regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask,
> > mask);
> > +
> > + expired = jiffies + HZ;
> > +
> > + while (1) {
> > + ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1,
> > &val);
> > + if (ret)
> > + return ret;
> > +
> > + if ((val & mask) == mask)
> > + break;
> > +
> > + cpu_relax();
> > + if (time_after(jiffies, expired))
> > + return -EIO;
> > + }
> > + }
>
> As with the 'clear bus protection bits', seems like this should be a
> call into the infracfg driver.
>
> > + val = readl(ctl_addr);
> > + val |= data->sram_pdn_bits;
> > + writel(val, ctl_addr);
> > +
> > + /* wait until SRAM_PDN_ACK all 1 */
> > + expired = jiffies + HZ;
> > + while ((readl(ctl_addr) & sram_pdn_ack) != sram_pdn_ack) {
> > + cpu_relax();
> > + if (time_after(jiffies, expired))
> > + return -EIO;
> > + }
> > +
> > + val |= PWR_ISO_BIT;
> > + writel(val, ctl_addr);
> > +
> > + val &= ~PWR_RST_B_BIT;
> > + writel(val, ctl_addr);
> > +
> > + val |= PWR_CLK_DIS_BIT;
> > + writel(val, ctl_addr);
> > +
> > + val &= ~PWR_ON_BIT;
> > + writel(val, ctl_addr);
> > +
> > + val &= ~PWR_ON_2ND_BIT;
> > + writel(val, ctl_addr);
> > +
> > + /* wait until PWR_ACK = 0 */
> > + expired = jiffies + HZ;
> > + while ((readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
> > + (readl(sc
[RFC 2/6] drm/msm: Remove local fbdev emulation Kconfig option
DRM_MSM_FBDEV config is used to enable/disable fbdev emulation for the msm kms driver. Replace this with the top level DRM_FBDEV_EMULATION config option where applicable. This also prevents build breaks caused by undefined drm_fb_helper_* functions when legacy fbdev support was disabled. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/Kconfig | 14 -- drivers/gpu/drm/msm/Makefile | 2 +- drivers/gpu/drm/msm/msm_drv.c | 4 ++-- 3 files changed, 3 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index bacbbb7..d6f3a4f 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -13,20 +13,6 @@ config DRM_MSM help DRM/KMS driver for MSM/snapdragon. -config DRM_MSM_FBDEV - bool "Enable legacy fbdev support for MSM modesetting driver" - depends on DRM_MSM - select DRM_KMS_FB_HELPER - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - default y - help - Choose this option if you have a need for the legacy fbdev - support. Note that this support also provide the linux console - support on top of the MSM modesetting driver. - config DRM_MSM_REGISTER_LOGGING bool "MSM DRM register logging" depends on DRM_MSM diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile index 674a132..40726ad 100644 --- a/drivers/gpu/drm/msm/Makefile +++ b/drivers/gpu/drm/msm/Makefile @@ -48,7 +48,7 @@ msm-y := \ msm_rd.o \ msm_ringbuffer.o -msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o +msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o obj-$(CONFIG_DRM_MSM) += msm.o diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index a426911..d3e816a 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -54,7 +54,7 @@ module_param(reglog, bool, 0600); #define reglog 0 #endif -#ifdef CONFIG_DRM_MSM_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION static bool fbdev = true; MODULE_PARM_DESC(fbdev, "Enable fbdev compat layer"); module_param(fbdev, bool, 0600); @@ -305,7 +305,7 @@ static int msm_load(struct drm_device *dev, unsigned long flags) drm_mode_config_reset(dev); -#ifdef CONFIG_DRM_MSM_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION if (fbdev) priv->fbdev = msm_fbdev_init(dev); #endif -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] drm/bridge: dw-hdmi: support optional supply regulators
Hi Philipp,
Am Dienstag, 10. März 2015, 10:16:53 schrieb Philipp Zabel:
[cut the obvious stuff I need to fix]
> Am Dienstag, den 10.03.2015, 00:22 +0100 schrieb Heiko Stuebner:
> > @@ -879,6 +883,12 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
> >
> > int i, ret;
> > bool cscon = false;
> >
> > + if (hdmi->nsupplies > 0) {
> > + ret = regulator_bulk_enable(hdmi->nsupplies, hdmi->supplies);
> > + if (ret)
> > + return ret;
> > + }
> > +
>
> Are these really supplies to the PHY or is this just a convenient place
> to enable them? Looking at the i.MX6 docs, I suppose yes.
According to the TRM, the supplies are "DC supply voltage for Analog part of
HDMI", so I'd think phy supplies.
>
> > /*check csc whether needed activated in HDMI mode */
> > cscon = (is_color_space_conversion(hdmi) &&
> >
> > !hdmi->hdmi_data.video_mode.mdvi);
> >
> > @@ -1105,6 +1115,9 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> > *hdmi)
> >
> > dw_hdmi_phy_enable_tmds(hdmi, 0);
> > dw_hdmi_phy_enable_power(hdmi, 0);
> >
> > + if (hdmi->nsupplies > 0)
> > + regulator_bulk_disable(hdmi->nsupplies, hdmi->supplies);
> > +
> >
> > hdmi->phy_enabled = false;
> >
> > }
> >
> > @@ -1549,7 +1562,8 @@ static int dw_hdmi_register(struct drm_device *drm,
> > struct dw_hdmi *hdmi)>
> > int dw_hdmi_bind(struct device *dev, struct device *master,
> >
> > void *data, struct drm_encoder *encoder,
> > struct resource *iores, int irq,
> >
> > -const struct dw_hdmi_plat_data *plat_data)
> > +const struct dw_hdmi_plat_data *plat_data,
> > +struct regulator_bulk_data *supplies, int nsupplies)
>
> I'm not sure I like this function sprouting so many parameters. Is there
> a good reason not to add this to struct dw_hdmi_plat_data?
Nope, moving this to platdata sound sensible and I'll give this a try :-)
Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
> Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
> Most modesetting drivers enable provide fbdev emulation by default by
> selecting
> KMS FB helpers. A few provide a separate Kconfig option for the user to enable
> or disbale fbdev emulation.
>
> Enabling fbdev emulation is finally a distro-level decision. Having a top
> level
> Kconfig option for fbdev emulation helps by providing a uniform way to
> enable/disable fbdev emulation for any modesetting driver. It also lets us
> remove unnecessary driver specific Kconfig options that causes bloat.
>
> With a top level Kconfig in place, we can stub out the fb helper functions
> when
> not needed without breaking functionality. Having stub functions also prevents
> drivers to require wrapping fb helper function calls with #ifdefs.
>
> DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by
> default and majority of distributions expect the fbdev interface in the
> kernel.
>
> For now, this config selects both FB_SYS_* and FB_CFB_* configs as some
> modesetting drivers use the former and other the later. This needs to be taken
> care of in a better way.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/Kconfig | 18 +++
> drivers/gpu/drm/Makefile| 4 ++
> include/drm/drm_fb_helper.h | 120
>
> 3 files changed, 142 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 151a050..38f83a0 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
> help
> FBDEV helpers for KMS drivers.
>
> +config DRM_FBDEV_EMULATION
> + bool "Enable legacy fbdev support for your modesetting driver"
> + depends on DRM
> + select DRM_KMS_HELPER
> + select DRM_KMS_FB_HELPER
> + select FB_SYS_FILLRECT
> + select FB_SYS_COPYAREA
> + select FB_SYS_IMAGEBLIT
> + select FB_SYS_FOPS
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + default y
> + help
> + Choose this option if you have a need for the legacy fbdev
> + support. Note that this support also provide the linux console
> + support on top of your modesetting driver.
> +
> config DRM_LOAD_EDID_FIRMWARE
> bool "Allow to specify an EDID data set instead of probing for it"
> depends on DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2c239b9..c1d44b2 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o
> drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
> drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> +
> +ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y)
> drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
> +endif
This should work as
drm_kms_helper-$CONFIG_DRM_FBDEV_EMULATION += drm_fb_helper.o
since both -y and -m are merged together.
-Daniel
> +
> drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
>
> obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 21b944c..dbfce1a 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -103,6 +103,7 @@ struct drm_fb_helper {
> bool delayed_hotplug;
> };
>
> +#ifdef CONFIG_DRM_FBDEV_EMULATION
> void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
> *helper,
> const struct drm_fb_helper_funcs *funcs);
> int drm_fb_helper_init(struct drm_device *dev,
> @@ -139,4 +140,123 @@ drm_pick_cmdline_mode(struct drm_fb_helper_connector
> *fb_helper_conn,
> int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
> drm_connector *connector);
> int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
> struct drm_connector *connector);
> +#else
> +static inline void drm_fb_helper_prepare(struct drm_device *dev,
> + struct drm_fb_helper *helper,
> + const struct drm_fb_helper_funcs *funcs)
> +{
> +}
> +
> +static inline int drm_fb_helper_init(struct drm_device *dev,
> +struct drm_fb_helper *helper, int crtc_count,
> +int max_conn)
> +{
> + return 0;
> +}
> +
> +static inline void drm_fb_helper_fini(struct drm_fb_helper *helper)
> +{
> +}
> +
> +static inline int drm_fb_helper_blank(int blank, struct fb_info *info)
> +{
> + return 0;
> +}
> +
> +static inline int drm_fb_helper_pan_display(struct fb_var_screeninfo *var,
> + struct fb_info *info)
> +{
>
[PATCH] staging: rtl8192e: remove unused functions
removed some functions which were not being used anywhere.
build tested and also verified by git grep that there is no other
reference to these functions.
Signed-off-by: Sudip Mukherjee
---
drivers/staging/rtl8192e/rtl819x_HTProc.c | 154 --
drivers/staging/rtl8192e/rtllib.h | 3 -
2 files changed, 157 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c
b/drivers/staging/rtl8192e/rtl819x_HTProc.c
index 165975a..6157536 100644
--- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
@@ -117,160 +117,6 @@ void HTUpdateDefaultSetting(struct rtllib_device *ieee)
pHTInfo->RxReorderPendingTime = 30;
}
-void HTDebugHTCapability(u8 *CapIE, u8 *TitleString)
-{
-
- static u8 EWC11NHTCap[] = {0x00, 0x90, 0x4c, 0x33};
- struct ht_capab_ele *pCapELE;
-
- if (!memcmp(CapIE, EWC11NHTCap, sizeof(EWC11NHTCap))) {
- RTLLIB_DEBUG(RTLLIB_DL_HT, "EWC IE in %s()\n", __func__);
- pCapELE = (struct ht_capab_ele *)(&CapIE[4]);
- } else
- pCapELE = (struct ht_capab_ele *)(&CapIE[0]);
-
- RTLLIB_DEBUG(RTLLIB_DL_HT, ". Called by %s\n",
-TitleString);
-
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tSupported Channel Width = %s\n",
-(pCapELE->ChlWidth) ? "20MHz" : "20/40MHz");
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tSupport Short GI for 20M = %s\n",
-(pCapELE->ShortGI20Mhz) ? "YES" : "NO");
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tSupport Short GI for 40M = %s\n",
-(pCapELE->ShortGI40Mhz) ? "YES" : "NO");
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tSupport TX STBC = %s\n",
-(pCapELE->TxSTBC) ? "YES" : "NO");
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tMax AMSDU Size = %s\n",
-(pCapELE->MaxAMSDUSize) ? "3839" : "7935");
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tSupport CCK in 20/40 mode = %s\n",
-(pCapELE->DssCCk) ? "YES" : "NO");
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tMax AMPDU Factor = %d\n",
-pCapELE->MaxRxAMPDUFactor);
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tMPDU Density = %d\n",
-pCapELE->MPDUDensity);
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tMCS Rate Set = [%x][%x][%x][%x][%x]\n",
-pCapELE->MCS[0], pCapELE->MCS[1], pCapELE->MCS[2],
-pCapELE->MCS[3], pCapELE->MCS[4]);
- return;
-
-}
-
-void HTDebugHTInfo(u8 *InfoIE, u8 *TitleString)
-{
-
- static u8 EWC11NHTInfo[] = {0x00, 0x90, 0x4c, 0x34};
- struct ht_info_ele *pHTInfoEle;
-
- if (!memcmp(InfoIE, EWC11NHTInfo, sizeof(EWC11NHTInfo))) {
- RTLLIB_DEBUG(RTLLIB_DL_HT, "EWC IE in %s()\n", __func__);
- pHTInfoEle = (struct ht_info_ele *)(&InfoIE[4]);
- } else
- pHTInfoEle = (struct ht_info_ele *)(&InfoIE[0]);
-
-
- RTLLIB_DEBUG(RTLLIB_DL_HT, ". "
-"Called by %s\n", TitleString);
-
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tPrimary channel = %d\n",
-pHTInfoEle->ControlChl);
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tSenondary channel =");
- switch (pHTInfoEle->ExtChlOffset) {
- case 0:
- RTLLIB_DEBUG(RTLLIB_DL_HT, "Not Present\n");
- break;
- case 1:
- RTLLIB_DEBUG(RTLLIB_DL_HT, "Upper channel\n");
- break;
- case 2:
- RTLLIB_DEBUG(RTLLIB_DL_HT, "Reserved. Eooro!!!\n");
- break;
- case 3:
- RTLLIB_DEBUG(RTLLIB_DL_HT, "Lower Channel\n");
- break;
- }
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tRecommended channel width = %s\n",
-(pHTInfoEle->RecommemdedTxWidth) ? "20Mhz" : "40Mhz");
-
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tOperation mode for protection = ");
- switch (pHTInfoEle->OptMode) {
- case 0:
- RTLLIB_DEBUG(RTLLIB_DL_HT, "No Protection\n");
- break;
- case 1:
- RTLLIB_DEBUG(RTLLIB_DL_HT, "HT non-member protection mode\n");
- break;
- case 2:
- RTLLIB_DEBUG(RTLLIB_DL_HT, "Suggest to open protection\n");
- break;
- case 3:
- RTLLIB_DEBUG(RTLLIB_DL_HT, "HT mixed mode\n");
- break;
- }
-
- RTLLIB_DEBUG(RTLLIB_DL_HT, "\tBasic MCS Rate Set = [%x][%x][%x][%x]"
-"[%x]\n", pHTInfoEle->BasicMSC[0], pHTInfoEle->BasicMSC[1],
-pHTInfoEle->BasicMSC[2], pHTInfoEle->BasicMSC[3],
-pHTInfoEle->BasicMSC[4]);
-}
-
-static bool IsHTHalfNmode40Bandwidth(struct rtllib_device *ieee)
-{
- boolretValue = false;
- struct rt_hi_throughput *pHTInfo = ieee->pHTInfo;
-
- if (pHTInfo->bCurrentHTSupport == false)
- retValue = false;
- else if (pHTInfo->bRegBW40MHz == false)
- retValue = fa
Re: [PATCH] crypto: AES-NI: fix memory usage in GCM decryption
On Sun, Mar 08, 2015 at 07:49:58PM +0100, Stephan Mueller wrote: > The RFC4106 GCM decryption operation tries to overwrite cryptlen memory > in req->dst. As the destination buffer for decryption only needs to hold > the plaintext memory but cryptlen references the input buffer holding > (ciphertext || authentication tag), the assumption of the destination > buffer length in RFC4106 GCM operation leads to a too large size. > > This patch simply subtracts the authentication tag size from cryptlen. > The kernel crypto API logic requires the caller to provide the > length of (ciphertext || authentication tag) as cryptlen for the > AEAD decryption operation. Thus, the cipher implementation must > caculate the size of the plaintext output itself and cannot simply use > cryptlen. > > Note, this fixes a kernel crash that can be triggered from user space > via AF_ALG(aead) without it (simply use the libkcapi test application > from [1] and update it to use rfc4106-gcm-aes). > > [1] http://www.chronox.de/libkcapi.html > > CC: Tadeusz Struk > Signed-off-by: Stephan Mueller Good catch. However, I think the same confusion exists in the code that allocates src which may also trigger a crash. So could you fix that as well? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] drivers: base: fw: fix ret value when loading fw
When using the user mode helper to load firmwares the function _request_firmware
gets a positive return value from fw_load_from_user_helper and because of this
the firmware buffer is not assigned. This happens only when the return value
is zero. This patch fixes this problem in _request_firmware_load. When the
completion is ready the return value is set to zero.
Signed-off-by: Zahari Doychev
---
Changes from v1:
- move handling of wait_for_completion_interruptible_timeout() return value
drivers/base/firmware_class.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 6c5c9ed..4996541 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -913,6 +913,8 @@ static int _request_firmware_load(struct firmware_priv
*fw_priv,
mutex_lock(&fw_lock);
fw_load_abort(fw_priv);
mutex_unlock(&fw_lock);
+ } else if (retval > 0) {
+ retval = 0;
}
if (is_fw_load_aborted(buf))
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
> Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
> Most modesetting drivers enable provide fbdev emulation by default by
> selecting
> KMS FB helpers. A few provide a separate Kconfig option for the user to enable
> or disbale fbdev emulation.
>
> Enabling fbdev emulation is finally a distro-level decision. Having a top
> level
> Kconfig option for fbdev emulation helps by providing a uniform way to
> enable/disable fbdev emulation for any modesetting driver. It also lets us
> remove unnecessary driver specific Kconfig options that causes bloat.
>
> With a top level Kconfig in place, we can stub out the fb helper functions
> when
> not needed without breaking functionality. Having stub functions also prevents
> drivers to require wrapping fb helper function calls with #ifdefs.
>
> DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by
> default and majority of distributions expect the fbdev interface in the
> kernel.
>
> For now, this config selects both FB_SYS_* and FB_CFB_* configs as some
> modesetting drivers use the former and other the later. This needs to be taken
> care of in a better way.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/Kconfig | 18 +++
> drivers/gpu/drm/Makefile| 4 ++
> include/drm/drm_fb_helper.h | 120
>
> 3 files changed, 142 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 151a050..38f83a0 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
> help
> FBDEV helpers for KMS drivers.
>
> +config DRM_FBDEV_EMULATION
> + bool "Enable legacy fbdev support for your modesetting driver"
> + depends on DRM
> + select DRM_KMS_HELPER
> + select DRM_KMS_FB_HELPER
> + select FB_SYS_FILLRECT
> + select FB_SYS_COPYAREA
> + select FB_SYS_IMAGEBLIT
> + select FB_SYS_FOPS
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + default y
> + help
> + Choose this option if you have a need for the legacy fbdev
> + support. Note that this support also provide the linux console
> + support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
-Daniel
> +
> config DRM_LOAD_EDID_FIRMWARE
> bool "Allow to specify an EDID data set instead of probing for it"
> depends on DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2c239b9..c1d44b2 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o
> drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
> drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> +
> +ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y)
> drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
> +endif
> +
> drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
>
> obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 21b944c..dbfce1a 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -103,6 +103,7 @@ struct drm_fb_helper {
> bool delayed_hotplug;
> };
>
> +#ifdef CONFIG_DRM_FBDEV_EMULATION
> void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
> *helper,
> const struct drm_fb_helper_funcs *funcs);
> int drm_fb_helper_init(struct drm_device *dev,
> @@ -139,4 +140,123 @@ drm_pick_cmdline_mode(struct drm_fb_helper_connector
> *fb_helper_conn,
> int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
> drm_connector *connector);
> int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
> struct drm_connector *connector);
> +#else
> +static inline void drm_fb_helper_prepare(struct drm_device *dev,
> + struct drm_fb_helper *helper,
> + const struct drm_fb_helper_funcs *funcs)
> +{
> +}
> +
> +static inline int drm_fb_helper_init(struct drm_device *dev,
> +struct drm_fb_helper *helper, int crtc_count,
> +int max_conn)
> +{
> + return 0;
> +}
> +
> +static inline void drm_fb_helper_fini(struct drm_fb_helper *helper)
> +{
> +}
> +
> +static inline int drm_fb_helper_blank(int blank, struct fb_info *info)
> +{
> + return 0;
> +}
> +
> +static inline int drm_fb_helper_pan_display(struct fb_var_screeninfo *var,
> + struct fb_info *info)
> +{
> + return
Re: linux-next: build warning after merge of the trivial tree
On Tue, 10 Mar 2015, Stephen Rothwell wrote:
> Hi Jiri,
>
> After merging the trivial tree, today's linux-next build ()
> produced this warning:
>
> drivers/tty/goldfish.c: In function 'goldfish_tty_probe':
> drivers/tty/goldfish.c:232:6: warning: unused variable 'i' [-Wunused-variable]
> int i;
> ^
>
> Introduced by commit 2a2483685a9d ("goldfish: remove unreachable line
> of code").
Thanks for the report Stephen, now fixed via 0e4f93e501 in
trivial.git#for-next.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/3] Fix power domains handling on exynos542x
Hello Kukjin, On 02/05/2015 03:45 PM, Javier Martinez Canillas wrote: > Hello Andrzej, > > Thanks a lot for finally finding what was causing the HDMI issue. > > On 02/05/2015 01:35 PM, Andrzej Hajda wrote: >> Hi, >> >> Exynos chipsets since 542x have asynchronous bridges connecting different >> IPs. >> These bridges should be operational during power domain switching, ie >> associated >> clocks cannot be gated. >> This patchset adds binding to provide such clocks per power domain and adds >> code >> which enables them during domain on/off operation. >> >> This patchset fixes power domain issues with disp1 domain and HDMI (some of >> them) >> on Odroid XU3: >> - disp1 power domain can be turned off, >> - no more "imprecise external abort" faults. >> >> The patchset is based on '[PATCH v5 0/9] Enable HDMI support on Exynos >> platforms' [1]. >> > > It also depends on '[PATCH 0/2] Add HDMI support for Exynos5420 platform' [2]. > >> It was successfully tested on OdroidXU3. >> >> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/42743 > > Your patches looks good to me so please feel free to add: > > Reviewed-by: Javier Martinez Canillas > > I also tested on an Exynos5420 Peach Pit Chromebook and both the "Power > domain power-domain disable failed" message and the system crash are gone. > > Tested-by: Javier Martinez Canillas > > Best regards, > Javier > > [2]: https://lkml.org/lkml/2015/1/20/235 > Any comments about this series? It fixes system hangs on Exynos 5420/5422/5800 boards and has been in the list for a while. Please keep in mind that a v2 of patch 3/3 was posted [0]. Best regards, Javier [0]: https://lkml.org/lkml/2015/2/6/138 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] drivers/base: cacheinfo: validate device node for all the caches
Hi Greg, On 23/02/15 16:32, Sudeep Holla wrote: On architectures that depend on DT for obtaining cache hierarcy, we need to validate the device node for all the cache indices, failing to do so might result in wrong information being exposed to the userspace. This is quite possible on initial/incomplete versions of the device trees. In such cases, it's better to bail out if all the required device nodes are not present. This patch adds checks for the validation of device node for all the caches and doesn't initialise the cacheinfo if there's any error. Cc: Greg Kroah-Hartman Reported-by: Mark Rutland Acked-by: Mark Rutland Signed-off-by: Sudeep Holla --- drivers/base/cacheinfo.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) v1->v2: - Updated log information as suggested by Mark - Added Mark's ACK Hi Greg, Can you please pick this fix for the next rc ? Without this there's possibility that erroneous information is exposed to userspace on architecture depending on DT especially if DT lacks cache hierarchy information. There are many arm64 DT without cache hierarchy which exposes wrong cacheinfo to the user space. It would be good to get this included as bug fix for 4.0 Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Archit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:16 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. + config DRM_LOAD_EDID_FIRMWARE bool "Allow to specify an EDID data set instead of probing for it" depends on DRM_KMS_HELPER diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c239b9..c1d44b2 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o + +ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y) drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o +endif This should work as drm_kms_helper-$CONFIG_DRM_FBDEV_EMULATION += drm_fb_helper.o since both -y and -m are merged together. Ah right. I'll fix that. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: sm750fb: Cleanup the type of mmio750
This patch assigns the more appropriate void* type to the mmio750 variable
eliminating an unnecessary volatile qualifier in the process. Additionally it
updates parameter types as necessary where those parameters interact with
mmio750 and removes unnecessary casts.
As a consequence, this patch fixes the following sparse warning:-
drivers/staging/sm750fb/ddk750_help.c:12:17: warning: incorrect type in
assignment (different address spaces)
Signed-off-by: Lorenzo Stoakes
---
drivers/staging/sm750fb/ddk750_chip.h | 4 +++-
drivers/staging/sm750fb/ddk750_help.c | 4 ++--
drivers/staging/sm750fb/ddk750_help.h | 10 +-
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_chip.h
b/drivers/staging/sm750fb/ddk750_chip.h
index 1c78875..d067b06 100644
--- a/drivers/staging/sm750fb/ddk750_chip.h
+++ b/drivers/staging/sm750fb/ddk750_chip.h
@@ -3,6 +3,8 @@
#define DEFAULT_INPUT_CLOCK 14318181 /* Default reference clock */
#define SM750LE_REVISION_ID (char)0xfe
+#include
+
/* This is all the chips recognized by this library */
typedef enum _logical_chip_type_t
{
@@ -70,7 +72,7 @@ logical_chip_type_t getChipType(void);
unsigned int calcPllValue(unsigned int request,pll_value_t *pll);
unsigned int calcPllValue2(unsigned int,pll_value_t *);
unsigned int formatPllReg(pll_value_t *pPLL);
-void ddk750_set_mmio(volatile unsigned char *,unsigned short,char);
+void ddk750_set_mmio(void __iomem *,unsigned short,char);
unsigned int ddk750_getVMSize(void);
int ddk750_initHw(initchip_param_t *);
unsigned int getPllValue(clock_type_t clockType, pll_value_t *pPLL);
diff --git a/drivers/staging/sm750fb/ddk750_help.c
b/drivers/staging/sm750fb/ddk750_help.c
index cc00d2b..c68ff3b 100644
--- a/drivers/staging/sm750fb/ddk750_help.c
+++ b/drivers/staging/sm750fb/ddk750_help.c
@@ -2,12 +2,12 @@
//#include "ddk750_chip.h"
#include "ddk750_help.h"
-volatile unsigned char __iomem * mmio750 = NULL;
+void __iomem * mmio750 = NULL;
char revId750 = 0;
unsigned short devId750 = 0;
/* after driver mapped io registers, use this function first */
-void ddk750_set_mmio(volatile unsigned char * addr,unsigned short devId,char
revId)
+void ddk750_set_mmio(void __iomem * addr,unsigned short devId,char revId)
{
mmio750 = addr;
devId750 = devId;
diff --git a/drivers/staging/sm750fb/ddk750_help.h
b/drivers/staging/sm750fb/ddk750_help.h
index 4fc93b5..07c8264 100644
--- a/drivers/staging/sm750fb/ddk750_help.h
+++ b/drivers/staging/sm750fb/ddk750_help.h
@@ -12,14 +12,14 @@
#if 0
/* if 718 big endian turned on,be aware that don't use this driver for general
use,only for ppc big-endian */
#warning "big endian on target cpu and enable nature big endian support of 718
capability !"
-#define PEEK32(addr) __raw_readl((void __iomem
*)(mmio750)+(addr))
-#define POKE32(addr,data) __raw_writel((data),(void
__iomem*)(mmio750)+(addr))
+#define PEEK32(addr) __raw_readl(mmio750 + addr)
+#define POKE32(addr,data) __raw_writel(data, mmio750 + addr)
#else /* software control endianess */
-#define PEEK32(addr) readl((addr)+mmio750)
-#define POKE32(addr,data) writel((data),(addr)+mmio750)
+#define PEEK32(addr) readl(addr + mmio750)
+#define POKE32(addr,data) writel(data, addr + mmio750)
#endif
-extern volatile unsigned char __iomem * mmio750;
+extern void __iomem * mmio750;
extern char revId750;
extern unsigned short devId750;
#else
--
2.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 03/10] reset: berlin: convert to a platform driver
Hi Philipp, On Mon, Mar 09, 2015 at 11:16:26AM +0100, Philipp Zabel wrote: > > Am Freitag, den 06.03.2015, 16:05 +0100 schrieb Antoine Tenart: > > The Berlin reset controller was introduced without being a platform > > driver because of a needed DT rework: the node describing the reset > > controller also describes the pinctrl and clk controllers... > > > > The DT issue being solved thanks to the addition of the Berlin > > controller mfd driver, it is now possible to convert the Berlin reset > > driver to a plaftorm driver. > > > > Signed-off-by: Antoine Tenart > > Looks good to me. Do you want to merge this together with the rest of > the series, or should I queue the reset patch? I think we better wait for the simple-mfd patch to make it to ARM SoC first. Once this is done, you can queue the reset patch (unless Sebastian wants to take it alongside the series). Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] crypto: OCTEON MD5 bugfix + SHA modules
On Sun, Mar 08, 2015 at 10:07:40PM +0200, Aaro Koskinen wrote: > Hi, > > The first patch is a bug fix for OCTEON MD5 aimed for 4.0-rc cycle. Please send such bug fixes in a separate series in future. For this one in particular it does not appear to be critical enough to go in straight away so I have pushed it into cryptodev along with the rest. > The remaining patches add SHA1/SHA256/SHA512 modules. I have tested > these on the following OCTEON boards and CPUs with 4.0-rc2: > > D-Link DSR-1000N: CN5010p1.1-500-SCP > EdgeRouter Lite:CN5020p1.1-500-SCP > EdgeRouter Pro: CN6120p1.1-1000-NSP > > All selftests are passing. With tcrypt, I get the following numbers > on speed compared to the generic modules: All applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] add power-supply support to dw_hdmi
On Tue, Mar 10, 2015 at 12:21:21AM +0100, Heiko Stuebner wrote:
> At least the Rockchip variant of the dw_hdmi should control its supplying
> regulators. A cursory glance at the imx manual didn't any equivalent there,
> so I'm not sure if there are similar controllable regulators present.
>
> Patch1 is only a small fix to keep {devm_}regulator_bulk_get quiet in
> the deferring case and could go directly to the regulator tree, if ok.
>
> Patch3 is the addition of the supplies to the rk3288 boards and I would
> take it into my dts branch if patch2 gets deemed acceptable.
I have a problem with this approach.
Rather than trying to shove everything into the generic part of the driver,
what we should be doing is ensuring that the generic part stays generic,
and the specific implementation details end up in the appropriate place.
As Rockchip needs these external regulators, they should be in that part
of the driver, and controlled appropriately from the encoder callbacks.
The encoder has sufficient callbacks to be able to turn on/off regulators
both before and after the bridge has been disabled/enabled.
When we see more implementations with regulators, then we can think about
moving it into the core dw_hdmi driver code.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/6] drm/i915: Remove local fbdev emulation Kconfig option
On Tue, Mar 10, 2015 at 03:11:30PM +0530, Archit Taneja wrote:
> DRM_I915_FBDEV config is currently used to enable/disable fbdev emulation for
> the i915 kms driver.
>
> Replace this with the top level DRM_FBDEV_EMULATION config option. Using this
> config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs
> in certain places.
>
> The #ifdef in drm_i915_private struct adding/removing members intel_fbdev and
> fbdev_suspend_work has been removed. This helps us use stub drm helper
> functions
> at not much cost.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/i915/Kconfig | 15 ---
> drivers/gpu/drm/i915/Makefile| 4 ++--
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 2 --
> drivers/gpu/drm/i915/intel_display.c | 10 --
> drivers/gpu/drm/i915/intel_dp_mst.c | 14 --
> drivers/gpu/drm/i915/intel_drv.h | 3 +--
> drivers/gpu/drm/i915/intel_fbdev.c | 7 ---
> 8 files changed, 16 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 74acca9..bd9ccfc 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -45,21 +45,6 @@ config DRM_I915_KMS
>
> If in doubt, say "Y".
>
> -config DRM_I915_FBDEV
> - bool "Enable legacy fbdev support for the modesetting intel driver"
> - depends on DRM_I915
> - select DRM_KMS_FB_HELPER
> - select FB_CFB_FILLRECT
> - select FB_CFB_COPYAREA
> - select FB_CFB_IMAGEBLIT
> - default y
> - help
> - Choose this option if you have a need for the legacy fbdev
> - support. Note that this support also provide the linux console
> - support on top of the intel modesetting driver.
> -
> - If in doubt, say "Y".
> -
> config DRM_I915_PRELIMINARY_HW_SUPPORT
> bool "Enable preliminary support for prerelease Intel hardware by
> default"
> depends on DRM_I915
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index f019225..3b3325d 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -56,8 +56,8 @@ i915-y += intel_audio.o \
> intel_psr.o \
> intel_sideband.o \
> intel_sprite.o
> -i915-$(CONFIG_ACPI) += intel_acpi.o intel_opregion.o
> -i915-$(CONFIG_DRM_I915_FBDEV)+= intel_fbdev.o
> +i915-$(CONFIG_ACPI) += intel_acpi.o intel_opregion.o
> +i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
>
> # modesetting output/encoder code
> i915-y += dvo_ch7017.o \
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e8b18e5..0c8bcd7 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1772,7 +1772,7 @@ static int i915_gem_framebuffer_info(struct seq_file
> *m, void *data)
> struct intel_fbdev *ifbdev = NULL;
> struct intel_framebuffer *fb;
>
> -#ifdef CONFIG_DRM_I915_FBDEV
> +#ifdef CONFIG_DRM_FBDEV_EMULATION
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> ifbdev = dev_priv->fbdev;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8727086..e511fa4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1819,11 +1819,9 @@ struct drm_i915_private {
>
> struct drm_i915_gem_object *vlv_pctx;
>
> -#ifdef CONFIG_DRM_I915_FBDEV
> /* list of fbdev register on this device */
> struct intel_fbdev *fbdev;
> struct work_struct fbdev_suspend_work;
> -#endif
>
> struct drm_property *broadcast_rgb_property;
> struct drm_property *force_audio_property;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e730789..9cf13e6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8562,7 +8562,6 @@ static struct drm_framebuffer *
> mode_fits_in_fbdev(struct drm_device *dev,
> struct drm_display_mode *mode)
> {
> -#ifdef CONFIG_DRM_I915_FBDEV
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_i915_gem_object *obj;
> struct drm_framebuffer *fb;
> @@ -8585,9 +8584,6 @@ mode_fits_in_fbdev(struct drm_device *dev,
> return NULL;
>
> return fb;
> -#else
> - return NULL;
> -#endif
Won't this now blow up if there's no fbdev? Tbh I prefer a patch to just
replace the CONFIG_ #define and then maybe a 2nd one on top to clean
things up if you feel like. Same for the other changes in this patch.
-Daniel
> }
>
> bool intel_get_load_detect_pipe(struct drm_connector *connector,
> @@ -12807,11 +12803,13 @@ intel_user_framebuffer_create(struct drm_device
> *dev,
> return intel_framebuffer_create(dev, mode_cmd, obj);
> }
>
> -#ifndef CONFIG_DRM_I915_FBDEV
> static inline void intel
Re: [GIT PULL 00/20] perf/core improvements and fixes
So I got this error today: ┌─Warning:───┐ │The vmlinux file can't be used. │ │Kernel samples will not be resolved.│ │ │ │ │ │Press any key...│ └┘ ... and sadly perf is being passive-aggressive again: being negative but refusing to say why! :-) Is there a way to figure out why it did not like the vmlinux? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: > > > On 03/10/2015 03:17 PM, Daniel Vetter wrote: > >On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: > >>Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. > >>Most modesetting drivers enable provide fbdev emulation by default by > >>selecting > >>KMS FB helpers. A few provide a separate Kconfig option for the user to > >>enable > >>or disbale fbdev emulation. > >> > >>Enabling fbdev emulation is finally a distro-level decision. Having a top > >>level > >>Kconfig option for fbdev emulation helps by providing a uniform way to > >>enable/disable fbdev emulation for any modesetting driver. It also lets us > >>remove unnecessary driver specific Kconfig options that causes bloat. > >> > >>With a top level Kconfig in place, we can stub out the fb helper functions > >>when > >>not needed without breaking functionality. Having stub functions also > >>prevents > >>drivers to require wrapping fb helper function calls with #ifdefs. > >> > >>DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation > >>by > >>default and majority of distributions expect the fbdev interface in the > >>kernel. > >> > >>For now, this config selects both FB_SYS_* and FB_CFB_* configs as some > >>modesetting drivers use the former and other the later. This needs to be > >>taken > >>care of in a better way. > >> > >>Signed-off-by: Archit Taneja > >>--- > >> drivers/gpu/drm/Kconfig | 18 +++ > >> drivers/gpu/drm/Makefile| 4 ++ > >> include/drm/drm_fb_helper.h | 120 > >> > >> 3 files changed, 142 insertions(+) > >> > >>diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > >>index 151a050..38f83a0 100644 > >>--- a/drivers/gpu/drm/Kconfig > >>+++ b/drivers/gpu/drm/Kconfig > >>@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER > >>help > >> FBDEV helpers for KMS drivers. > >> > >>+config DRM_FBDEV_EMULATION > >>+ bool "Enable legacy fbdev support for your modesetting driver" > >>+ depends on DRM > >>+ select DRM_KMS_HELPER > >>+ select DRM_KMS_FB_HELPER > >>+ select FB_SYS_FILLRECT > >>+ select FB_SYS_COPYAREA > >>+ select FB_SYS_IMAGEBLIT > >>+ select FB_SYS_FOPS > >>+ select FB_CFB_FILLRECT > >>+ select FB_CFB_COPYAREA > >>+ select FB_CFB_IMAGEBLIT > >>+ default y > >>+ help > >>+ Choose this option if you have a need for the legacy fbdev > >>+ support. Note that this support also provide the linux console > >>+ support on top of your modesetting driver. > > > >Maybe clarify that for linux console support you also need > >CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. > > DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/urgent] x86/asm/entry/32: Fix user_mode() misuses
Commit-ID: 394838c96013ba414a24ffe7a2a593a9154daadf
Gitweb: http://git.kernel.org/tip/394838c96013ba414a24ffe7a2a593a9154daadf
Author: Andy Lutomirski
AuthorDate: Mon, 9 Mar 2015 17:42:31 -0700
Committer: Ingo Molnar
CommitDate: Tue, 10 Mar 2015 04:21:51 +0100
x86/asm/entry/32: Fix user_mode() misuses
The one in do_debug() is probably harmless, but better safe than sorry.
Signed-off-by: Andy Lutomirski
Cc:
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/d67deaa9df5458363623001f252d1aee3215d014.1425948056.git.l...@amacapital.net
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/traps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 9d2073e..4ff5d16 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -384,7 +384,7 @@ dotraplinkage void do_bounds(struct pt_regs *regs, long
error_code)
goto exit;
conditional_sti(regs);
- if (!user_mode(regs))
+ if (!user_mode_vm(regs))
die("bounds", regs, error_code);
if (!cpu_feature_enabled(X86_FEATURE_MPX)) {
@@ -637,7 +637,7 @@ dotraplinkage void do_debug(struct pt_regs *regs, long
error_code)
* then it's very likely the result of an icebp/int01 trap.
* User wants a sigtrap for that.
*/
- if (!dr6 && user_mode(regs))
+ if (!dr6 && user_mode_vm(regs))
user_icebp = 1;
/* Catch kmemcheck conditions first of all! */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/core] sched/deadline: Add rq-> clock update skip for dl task yield
Commit-ID: 44fb085bfa17628c6d2aaa6af6b292a8499e9cbd Gitweb: http://git.kernel.org/tip/44fb085bfa17628c6d2aaa6af6b292a8499e9cbd Author: Wanpeng Li AuthorDate: Tue, 10 Mar 2015 12:20:00 +0800 Committer: Ingo Molnar CommitDate: Tue, 10 Mar 2015 05:46:50 +0100 sched/deadline: Add rq->clock update skip for dl task yield This patch adds rq->clock update skip for SCHED_DEADLINE task yield, to tell update_rq_clock() that we've just updated the clock, so that we don't do a microscopic update in schedule() and double the fastpath cost. Signed-off-by: Wanpeng Li Cc: Juri Lelli Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1425961200-3809-1-git-send-email-wanpeng...@linux.intel.com Signed-off-by: Ingo Molnar --- kernel/sched/deadline.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 3fa8fa6..0a81a95 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -914,6 +914,12 @@ static void yield_task_dl(struct rq *rq) } update_rq_clock(rq); update_curr_dl(rq); + /* +* Tell update_rq_clock() that we've just updated, +* so we don't do microscopic update in schedule() +* and double the fastpath cost. +*/ + rq_clock_skip_update(rq, true); } #ifdef CONFIG_SMP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/fpu] x86/fpu: Factor out memset(xstate, 0) in fpu_finit( ) paths
Commit-ID: 1d23c4518b1f3a03c278f2149245c178d2a6
Gitweb: http://git.kernel.org/tip/1d23c4518b1f3a03c278f2149245c178d2a6
Author: Oleg Nesterov
AuthorDate: Tue, 10 Mar 2015 07:06:25 +0100
Committer: Ingo Molnar
CommitDate: Tue, 10 Mar 2015 07:14:31 +0100
x86/fpu: Factor out memset(xstate, 0) in fpu_finit() paths
fx_finit() has two users but only fpu_finit() needs to clear
xstate, alloc_bootmem_align() in setup_init_fpu_buf() returns
zero-filled memory.
And note that both memset()'s look confusing. Yes, offsetof() is
0 for ->fxsave or ->fsave, but it would be cleaner to turn
them into a single memset() which zeroes fpu->state.
Signed-off-by: Oleg Nesterov
Signed-off-by: Borislav Petkov
Acked-by: Rik van Riel
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Tavis Ormandy
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/1425967585-4725-2-git-send-email...@alien8.de
Link: http://lkml.kernel.org/r/20150302183257.gc23...@redhat.com
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/fpu-internal.h | 1 -
arch/x86/kernel/i387.c | 3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/fpu-internal.h
b/arch/x86/include/asm/fpu-internal.h
index 61609b9..5fa1be2 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -135,7 +135,6 @@ static __always_inline __pure bool use_fxsr(void)
static inline void fx_finit(struct i387_fxsave_struct *fx)
{
- memset(fx, 0, xstate_size);
fx->cwd = 0x37f;
fx->mxcsr = MXCSR_DEFAULT;
}
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 03cc0ad..0f3de66 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -224,11 +224,12 @@ void fpu_finit(struct fpu *fpu)
return;
}
+ memset(fpu->state, 0, xstate_size);
+
if (cpu_has_fxsr) {
fx_finit(&fpu->state->fxsave);
} else {
struct i387_fsave_struct *fp = &fpu->state->fsave;
- memset(fp, 0, xstate_size);
fp->cwd = 0x037fu;
fp->swd = 0xu;
fp->twd = 0xu;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/fpu] x86/fpu: Change xstateregs_get()/set() to use -> xsave.i387 rather than ->fxsave
Commit-ID: e7f180dcd8ab48f18b20d7e8a7e9b39192bdf8e0
Gitweb: http://git.kernel.org/tip/e7f180dcd8ab48f18b20d7e8a7e9b39192bdf8e0
Author: Oleg Nesterov
AuthorDate: Tue, 10 Mar 2015 07:06:24 +0100
Committer: Ingo Molnar
CommitDate: Tue, 10 Mar 2015 07:14:31 +0100
x86/fpu: Change xstateregs_get()/set() to use ->xsave.i387 rather than ->fxsave
This is a cosmetic change: xstateregs_get() and xstateregs_set()
abuse ->fxsave to access xsave->i387.sw_reserved.
This practice is correct, ->fxsave and xsave->i387 share the same memory,
but IMHO this looks confusing.
And we can make this code more readable if we add a
"struct xsave_struct *" local variable as well.
Signed-off-by: Oleg Nesterov
Signed-off-by: Borislav Petkov
Reviewed-by: Rik van Riel
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Tavis Ormandy
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/1425967585-4725-1-git-send-email...@alien8.de
Link: http://lkml.kernel.org/r/20150302183237.gb23...@redhat.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/i387.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 8416b5f..03cc0ad 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -339,6 +339,7 @@ int xstateregs_get(struct task_struct *target, const struct
user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
+ struct xsave_struct *xsave = &target->thread.fpu.state->xsave;
int ret;
if (!cpu_has_xsave)
@@ -353,14 +354,12 @@ int xstateregs_get(struct task_struct *target, const
struct user_regset *regset,
* memory layout in the thread struct, so that we can copy the entire
* xstateregs to the user using one user_regset_copyout().
*/
- memcpy(&target->thread.fpu.state->fxsave.sw_reserved,
- xstate_fx_sw_bytes, sizeof(xstate_fx_sw_bytes));
-
+ memcpy(&xsave->i387.sw_reserved,
+ xstate_fx_sw_bytes, sizeof(xstate_fx_sw_bytes));
/*
* Copy the xstate memory layout.
*/
- ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
- &target->thread.fpu.state->xsave, 0, -1);
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, xsave, 0, -1);
return ret;
}
@@ -368,8 +367,8 @@ int xstateregs_set(struct task_struct *target, const struct
user_regset *regset,
unsigned int pos, unsigned int count,
const void *kbuf, const void __user *ubuf)
{
+ struct xsave_struct *xsave = &target->thread.fpu.state->xsave;
int ret;
- struct xsave_hdr_struct *xsave_hdr;
if (!cpu_has_xsave)
return -ENODEV;
@@ -378,22 +377,16 @@ int xstateregs_set(struct task_struct *target, const
struct user_regset *regset,
if (ret)
return ret;
- ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
-&target->thread.fpu.state->xsave, 0, -1);
-
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, xsave, 0, -1);
/*
* mxcsr reserved bits must be masked to zero for security reasons.
*/
- target->thread.fpu.state->fxsave.mxcsr &= mxcsr_feature_mask;
-
- xsave_hdr = &target->thread.fpu.state->xsave.xsave_hdr;
-
- xsave_hdr->xstate_bv &= pcntxt_mask;
+ xsave->i387.mxcsr &= mxcsr_feature_mask;
+ xsave->xsave_hdr.xstate_bv &= pcntxt_mask;
/*
* These bits must be zero.
*/
- memset(xsave_hdr->reserved, 0, 48);
-
+ memset(&xsave->xsave_hdr.reserved, 0, 48);
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/9] PCI: MMCONFIG clean up
On 06.03.2015 19:53, Bjorn Helgaas wrote: On Fri, Feb 27, 2015 at 04:00:35PM +0100, Tomasz Nowicki wrote: MCFG ACPI table and PCI ECAM standard have no arch dependencies so it can be used across all architectures. Currently MMCONFIG related code resides in arch/x86 directories. This patch set is going to isolate non-architecure specific code and make it accessible for all architectures. Hi Tomasz, This doesn't apply on v4.0-rc1: $ stg import -M --sign m/tn Checking for changes in the working directory ... done Importing patch "x86-pci-clean-up-comment-about" ... done Importing patch "x86-pci-abstract-pci-config" ... done Importing patch "x86-pci-reorder-logic-of" ... done Importing patch "x86-pci-acpi-move-arch" ... error: patch failed: arch/x86/pci/mmconfig-shared.c:657 error: arch/x86/pci/mmconfig-shared.c: patch does not apply stg import: Diff does not apply cleanly Can you refresh and repost, please? Sure, sorry for inconvenience. Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/6] drm/i915: Remove local fbdev emulation Kconfig option
On 03/10/2015 03:31 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:30PM +0530, Archit Taneja wrote:
DRM_I915_FBDEV config is currently used to enable/disable fbdev emulation for
the i915 kms driver.
Replace this with the top level DRM_FBDEV_EMULATION config option. Using this
config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs
in certain places.
The #ifdef in drm_i915_private struct adding/removing members intel_fbdev and
fbdev_suspend_work has been removed. This helps us use stub drm helper functions
at not much cost.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/i915/Kconfig | 15 ---
drivers/gpu/drm/i915/Makefile| 4 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/intel_display.c | 10 --
drivers/gpu/drm/i915/intel_dp_mst.c | 14 --
drivers/gpu/drm/i915/intel_drv.h | 3 +--
drivers/gpu/drm/i915/intel_fbdev.c | 7 ---
8 files changed, 16 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 74acca9..bd9ccfc 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -45,21 +45,6 @@ config DRM_I915_KMS
If in doubt, say "Y".
-config DRM_I915_FBDEV
- bool "Enable legacy fbdev support for the modesetting intel driver"
- depends on DRM_I915
- select DRM_KMS_FB_HELPER
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
- default y
- help
- Choose this option if you have a need for the legacy fbdev
- support. Note that this support also provide the linux console
- support on top of the intel modesetting driver.
-
- If in doubt, say "Y".
-
config DRM_I915_PRELIMINARY_HW_SUPPORT
bool "Enable preliminary support for prerelease Intel hardware by
default"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f019225..3b3325d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -56,8 +56,8 @@ i915-y += intel_audio.o \
intel_psr.o \
intel_sideband.o \
intel_sprite.o
-i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
-i915-$(CONFIG_DRM_I915_FBDEV) += intel_fbdev.o
+i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
+i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
# modesetting output/encoder code
i915-y += dvo_ch7017.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e8b18e5..0c8bcd7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1772,7 +1772,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
struct intel_fbdev *ifbdev = NULL;
struct intel_framebuffer *fb;
-#ifdef CONFIG_DRM_I915_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct drm_i915_private *dev_priv = dev->dev_private;
ifbdev = dev_priv->fbdev;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8727086..e511fa4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1819,11 +1819,9 @@ struct drm_i915_private {
struct drm_i915_gem_object *vlv_pctx;
-#ifdef CONFIG_DRM_I915_FBDEV
/* list of fbdev register on this device */
struct intel_fbdev *fbdev;
struct work_struct fbdev_suspend_work;
-#endif
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e730789..9cf13e6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8562,7 +8562,6 @@ static struct drm_framebuffer *
mode_fits_in_fbdev(struct drm_device *dev,
struct drm_display_mode *mode)
{
-#ifdef CONFIG_DRM_I915_FBDEV
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj;
struct drm_framebuffer *fb;
@@ -8585,9 +8584,6 @@ mode_fits_in_fbdev(struct drm_device *dev,
return NULL;
return fb;
-#else
- return NULL;
-#endif
Won't this now blow up if there's no fbdev? Tbh I prefer a patch to just
replace the CONFIG_ #define and then maybe a 2nd one on top to clean
things up if you feel like. Same for the other changes in this patch.
There are checks for dev_priv->fbdev and dev_priv->fbdev->fb being non
NULL at the start of the function which would prevent that. But you're
right, the first patch for each device can replace the config, the later
ones can take advantage of the stub functions.
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from
Re: [PATCH v6 4/8] ARM: dts: enable IOMUX for Broadcom Cygnus
On Mon, Mar 9, 2015 at 9:44 PM, Ray Jui wrote: > This enables the IOMUX support for Broadcom Cygnus SoC > > Signed-off-by: Ray Jui > Tested-by: Dmitry Torokhov Acked-by: Linus Walleij Pls take this through some BRCM ARM SoC tree. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 5/8] pinctrl: Cygnus: define Broadcom Cygnus GPIO/PINCONF binding
On Mon, Mar 9, 2015 at 9:44 PM, Ray Jui wrote: > Document the GPIO/PINCONF device tree binding for Broadcom Cygnus SoC > > Signed-off-by: Ray Jui > Reviewed-by: Scott Branden Patch applied! > +- compatible: > +Must be "brcm,cygnus-ccm-gpio", "brcm,cygnus-asiu-gpio", or > +"brcm,cygnus-crmu-gpio" Thanks for making this change. It is very useful because it can now handle any other variant-specific quirks you may run into. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 6/8] pinctrl: cygnus: add gpio/pinconf driver
On Mon, Mar 9, 2015 at 9:45 PM, Ray Jui wrote:
> This adds the initial support of the Broadcom Cygnus GPIO/PINCONF driver
> that supports all 3 GPIO controllers on Cygnus including the ASIU GPIO
> controller, the chipCommonG GPIO controller, and the always-on GPIO
> controller. Basic PINCONF configurations such as bias pull up/down, and
> drive strength are also supported in this driver.
>
> Pins from the ASIU GPIO controller can be individually muxed to GPIO
> function, through interaction with the Cygnus IOMUX controller
>
> Signed-off-by: Ray Jui
> Reviewed-by: Scott Branden
> Tested-by: Dmitry Torokhov
Patch applied! But please look at this:
> +#include
Doesn't just #include work?
> +static int __init cygnus_gpio_init(void)
> +{
> + return platform_driver_probe(&cygnus_gpio_driver, cygnus_gpio_probe);
> +}
> +arch_initcall_sync(cygnus_gpio_init);
arch_initcall_sync() is a bit brutal.
Can you please investigate if you can have this as a normal device_initcall()
utilizing deferred probe if necessary?
Follow-up patches accepted!
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 7/8] ARM: dts: enable GPIO for Broadcom Cygnus
On Mon, Mar 9, 2015 at 9:45 PM, Ray Jui wrote: > This enables all 3 GPIO controllers including the ASIU GPIO, the > chipcommonG GPIO, and the ALWAYS-ON GPIO, for Broadcom Cygnus SoC > > Signed-off-by: Ray Jui > Reviewed-by: Scott Branden > Tested-by: Dmitry Torokhov Acked-by: Linus Walleij Pls take this through ARM SoC. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/4] scsi: ufs: inject errors to verify error handling
>> +static bool inject_cmd_hang_tr(struct ufs_hba *hba)
>> +{
>> + int tag;
>> +
>> + tag = find_first_bit(&hba->outstanding_reqs, hba->nutrs);
>> + if (tag == hba->nutrs)
>> + return 0;
>> +
>> + __clear_bit(tag, &hba->outstanding_reqs);
>> + hba->lrb[tag].cmd = NULL;
>> + __clear_bit(tag, &hba->lrb_in_use);
>
> hba->lrb_in_use is a bitmap set by test_and_set_bit_lock(). So
> this should be cleared by clear_bit_unlock().
You are correct. Thanks.
>
> And as soon as the bit corresponds to this slot in hba->lrb_in_use is
> cleared, this slot could be reused. But if the request corresponds
> to the slot is not completed yet, it could sacrifice the new request,
> too. So should we only inject into the commands which have been
> completed like this?
Please note that we only clear the bit in hba->lrb_in_use. scsi_done is
not called for this request. Therefore, the tag is not yet free in the
block layer and next calls for queuecommand will not pass down this tag to
be used in the UFS driver. So there is no danger of a new request being
sacrificed.
On a different note, we are debating internally on a few other changes so
until we consolidate those I will drop this patch with error injection.
Gilad.
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 8/8] ARM: dts: cygnus: enable GPIO based hook detection
On Mon, Mar 9, 2015 at 9:45 PM, Ray Jui wrote: > This enables GPIO based phone hook detection for Broadcom BCM911360 > phone factor board (bcm911360_entphn) > > Signed-off-by: Ray Jui Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regmap: how to support devices with 'nested' pages
On Tue, Mar 10, 2015 at 11:33:24AM +0200, Peter Ujfalusi wrote: > Do you know any other device which have similar addressing? Do you have advice > on how to handle this? Should I open code the book switching in the driver, > which means that I should not use the cache at all in regmap. I've never heard of any other devices doing anything similar, it's certainly innovative. I've no great idea how to deal with it other than try to make the page selection code cope with recursion or nest some regmaps. signature.asc Description: Digital signature
Re: [PATCH] drivers: scsi: ufs: Fix possible null derefrence
> Check for null before being dereferenced to avoid a invalid null
> dereference.
>
> Found using Coccinelle.
>
> Signed-off-by: Tapasweni Pathak
> Acked-by: Julia Lawall
> ---
> drivers/scsi/ufs/ufshcd.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 5d60a86..c54e64f 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -4268,12 +4268,15 @@ static int ufshcd_config_vreg(struct device *dev,
> struct ufs_vreg *vreg, bool on)
> {
> int ret = 0;
> - struct regulator *reg = vreg->reg;
> - const char *name = vreg->name;
> + struct regulator *reg;
> + const char *name;
> int min_uV, uA_load;
>
> BUG_ON(!vreg);
Please add to the patch fix for another instance of this in
ufshcd_config_vreg_load():
static int ufshcd_config_vreg_load(struct device *dev,
struct ufs_vreg *vreg, int ua)
{
int ret = 0;
struct regulator *reg = vreg->reg;
const char *name = vreg->name;
BUG_ON(!vreg);
Gilad.
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] OMAPDSS: Correct video ports description file path in DT binding doc
On 07/03/15 18:08, Javier Martinez Canillas wrote: > The doc refers to Documentation/devicetree/bindings/video/video-ports.txt > which does not exist. The documentation seems to be outdated and wants to > refer to Documentation/devicetree/bindings/graph.txt instead. > > Suggested-by: Tomi Valkeinen > Signed-off-by: Javier Martinez Canillas > --- > Documentation/devicetree/bindings/video/ti,omap-dss.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt > b/Documentation/devicetree/bindings/video/ti,omap-dss.txt > index d5f1a3fe3109..e1ef29569338 100644 > --- a/Documentation/devicetree/bindings/video/ti,omap-dss.txt > +++ b/Documentation/devicetree/bindings/video/ti,omap-dss.txt > @@ -25,8 +25,8 @@ Video Ports > --- > > The DSS Core and the encoders have video port outputs. The structure of the > -video ports is described in Documentation/devicetree/bindings/video/video- > -ports.txt, and the properties for the ports and endpoints for each encoder > are > +video ports is described in Documentation/devicetree/bindings/graph.txt, > +and the properties for the ports and endpoints for each encoder are > described in the SoC's DSS binding documentation. > > The video ports are used to describe the connections to external hardware, > like > Thanks, queued for 4.1. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/3] clockevents: Manage device's state separately for core
On 27 February 2015 at 17:21, Viresh Kumar wrote: > Hi Thomas/Ingo, > > This is in response to the suggestions Ingo gave [1] on the shortcomings of > clockevents core's state machine. > > This first separates out the RESUME functionality from other states as its a > special case. Then it defines a new enum to map possible states of a > clockevent > device. > > Ideally it should only be available for the core, but as bL switcher is using > it > today, it is exposed in clockchips.h. That dependency will go away after > applying the Thomas's work (Sent out be Peter) and then we can move this enum > to > somewhere in kernel/time/. > > The last patch moves the legacy check to the legacy code. > > Please see if this meets your expectation or if you have some suggestions on > it. > > Rebased of tip/master as there were some dependencies: > 575daeea39a3 Merge branch 'tools/kvm' > > This along with migration of few clockevents drivers is pushed here: > git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git > clkevt/manage-state > > -- > Viresh > > [1] https://lkml.org/lkml/2015/2/20/107 > > Viresh Kumar (3): > clockevents: Handle tick device's resume separately > clockevents: Manage device's state separately for the core > clockevents: Don't validate dev->mode against CLOCK_EVT_MODE_UNUSED > for new interface Ingo, Gentle reminder ping... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon wrote:
> +Configuration definition follows similar model as the pinctrl-single:
> +The groups of pin configuration are defined under "pinctrl-single,pins"
> +
> +&dra7_iodelay_core {
> + mmc2_iodelay_3v3_conf: mmc2_iodelay_3v3_conf {
> + pinctrl-single,pins = <
> + 0x18c (A_DELAY(0) | G_DELAY(120)) /*
> CFG_GPMC_A19_IN */
> + 0x1a4 (A_DELAY(265) | G_DELAY(360)) /*
> CFG_GPMC_A20_IN */
> + 0x1b0 (A_DELAY(0) | G_DELAY(120)) /*
> CFG_GPMC_A21_IN */
> + 0x1bc (A_DELAY(0) | G_DELAY(120)) /*
> CFG_GPMC_A22_IN */
> + 0x1c8 (A_DELAY(287) | G_DELAY(420)) /*
> CFG_GPMC_A23_IN */
> + 0x1d4 (A_DELAY(144) | G_DELAY(240)) /*
> CFG_GPMC_A24_IN */
> + 0x1e0 (A_DELAY(0) | G_DELAY(0)) /*
> CFG_GPMC_A25_IN */
> + 0x1ec (A_DELAY(120) | G_DELAY(0)) /*
> CFG_GPMC_A26_IN */
> + 0x1f8 (A_DELAY(120) | G_DELAY(180)) /*
> CFG_GPMC_A27_IN */
> + 0x360 (A_DELAY(0) | G_DELAY(0)) /*
> CFG_GPMC_CS1_IN */
> + >;
> + };
> +};
But wait.
The promise when we merged pinctrl-single was that this driver was to be used
when the system had a one-register-per-pin layout and it was easy to do device
trees based on that.
We were very reluctant to accept that even though we didn't even have the
generic pin control bindings in place, the argument being that the driver
should know the detailed register layout, it should not be described in the
device tree. We eventually caved in and accepted it as an exception.
Since this pin controller is not using pinctrl-single it does not enjoy that
privilege and you need to explain why this pin controller cannot use the
generic bindings like so many other pin controllers have since started
to do. ("It is in the same SoC" is not an acceptable argument.)
What is wrong with this:
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
We can add generic delay bindings to the list, it even seems like
a good idea to do so, as it is likely something that will come up in
other hardware and will be needed for ACPI etc going forward.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the regulator tree
On Tue, Mar 10, 2015 at 01:44:41PM +1100, Stephen Rothwell wrote: > grep is your friend ... Indeed :( > This patch should be applied to your tree as it is based off v4.0-rc1 > already. Applied, thanks. signature.asc Description: Digital signature
[PATCH 2/4] x86: entry_64.S: remove stub_iopl
stub_iopl is no longer needed: pt_regs->flags needs no fixing up after previous change. Removing it. Signed-off-by: Denys Vlasenko CC: Linus Torvalds CC: Steven Rostedt CC: Ingo Molnar CC: Borislav Petkov CC: "H. Peter Anvin" CC: Oleg Nesterov CC: Frederic Weisbecker CC: Alexei Starovoitov CC: Will Drewry CC: Kees Cook CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/kernel/entry_64.S | 13 - arch/x86/syscalls/syscall_64.tbl | 2 +- arch/x86/um/sys_call_table_64.c | 2 +- 3 files changed, 2 insertions(+), 15 deletions(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index 324200a..703ced0 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -421,22 +421,9 @@ ENTRY(stub_\func) END(stub_\func) .endm - .macro FIXED_FRAME label,func -ENTRY(\label) - CFI_STARTPROC - DEFAULT_FRAME 0, 8 /* offset 8: return address */ - FIXUP_TOP_OF_STACK %r11, 8 - call \func - RESTORE_TOP_OF_STACK %r11, 8 - ret - CFI_ENDPROC -END(\label) - .endm - FORK_LIKE clone FORK_LIKE fork FORK_LIKE vfork - FIXED_FRAME stub_iopl, sys_iopl ENTRY(stub_execve) CFI_STARTPROC diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl index 8d656fb..9ef32d5 100644 --- a/arch/x86/syscalls/syscall_64.tbl +++ b/arch/x86/syscalls/syscall_64.tbl @@ -178,7 +178,7 @@ 169common reboot sys_reboot 170common sethostname sys_sethostname 171common setdomainname sys_setdomainname -172common ioplstub_iopl +172common ioplsys_iopl 173common ioperm sys_ioperm 17464 create_module 175common init_module sys_init_module diff --git a/arch/x86/um/sys_call_table_64.c b/arch/x86/um/sys_call_table_64.c index 5cdfa9d..a75d8700 100644 --- a/arch/x86/um/sys_call_table_64.c +++ b/arch/x86/um/sys_call_table_64.c @@ -16,7 +16,7 @@ */ /* Not going to be implemented by UML, since we have no hardware. */ -#define stub_iopl sys_ni_syscall +#define sys_iopl sys_ni_syscall #define sys_ioperm sys_ni_syscall /* -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] x86: entry_64.S: remove unused thread_struct::usersp
All manipulations of PER_CPU(old_rsp) in C code are removed:
it is not used on SYSRET return, storing anything there is pointless.
This also allows to get rid of thread_struct::usersp,
which was needed only to set PER_CPU(old_rsp) for
correct return from fork/clone.
Tweak a few comments (we no longer have "partial stack frame", ever).
Signed-off-by: Denys Vlasenko
CC: Linus Torvalds
CC: Steven Rostedt
CC: Ingo Molnar
CC: Borislav Petkov
CC: "H. Peter Anvin"
CC: Oleg Nesterov
CC: Frederic Weisbecker
CC: Alexei Starovoitov
CC: Will Drewry
CC: Kees Cook
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
---
arch/x86/include/asm/processor.h | 6 --
arch/x86/kernel/entry_64.S | 4 ++--
arch/x86/kernel/process_64.c | 5 -
3 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 48a61c1..c77605d 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -478,7 +478,6 @@ struct thread_struct {
#ifdef CONFIG_X86_32
unsigned long sysenter_cs;
#else
- unsigned long usersp; /* Copy from PDA */
unsigned short es;
unsigned short ds;
unsigned short fsindex;
@@ -894,11 +893,6 @@ extern unsigned long thread_saved_pc(struct task_struct
*tsk);
#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.sp0 - 1)
extern unsigned long KSTK_ESP(struct task_struct *task);
-/*
- * User space RSP while inside the SYSCALL fast path
- */
-DECLARE_PER_CPU(unsigned long, old_rsp);
-
#endif /* CONFIG_X86_64 */
extern void start_thread(struct pt_regs *regs, unsigned long new_ip,
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index d86788c..9e37b36 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -303,7 +303,7 @@ int_ret_from_sys_call_fixup:
FIXUP_TOP_OF_STACK %r11
jmp int_ret_from_sys_call
- /* Do syscall tracing */
+ /* Do syscall entry tracing */
tracesys:
movq %rsp, %rdi
movq $AUDIT_ARCH_X86_64, %rsi
@@ -343,7 +343,7 @@ tracesys_phase2:
/*
* Syscall return path ending with IRET.
- * Has correct top of stack, but partial stack frame.
+ * Has correct iret frame.
*/
GLOBAL(int_ret_from_sys_call)
DISABLE_INTERRUPTS(CLBR_NONE)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index e8c124a..14df2be 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -161,7 +161,6 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
p->thread.sp0 = (unsigned long)task_stack_page(p) + THREAD_SIZE;
childregs = task_pt_regs(p);
p->thread.sp = (unsigned long) childregs;
- p->thread.usersp = me->thread.usersp;
set_tsk_thread_flag(p, TIF_FORK);
p->thread.io_bitmap_ptr = NULL;
@@ -235,10 +234,8 @@ start_thread_common(struct pt_regs *regs, unsigned long
new_ip,
loadsegment(es, _ds);
loadsegment(ds, _ds);
load_gs_index(0);
- current->thread.usersp = new_sp;
regs->ip= new_ip;
regs->sp= new_sp;
- this_cpu_write(old_rsp, new_sp);
regs->cs= _cs;
regs->ss= _ss;
regs->flags = X86_EFLAGS_IF;
@@ -398,8 +395,6 @@ __switch_to(struct task_struct *prev_p, struct task_struct
*next_p)
/*
* Switch the PDA and FPU contexts.
*/
- prev->usersp = this_cpu_read(old_rsp);
- this_cpu_write(old_rsp, next->usersp);
this_cpu_write(current_task, next_p);
/*
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [DRBD-user] [patch 1/2] block, drbd: fix drbd_req_new() initialization
On Sat, Mar 07, 2015 at 04:24:02PM -0800, David Rientjes wrote: > mempool_alloc() does not support __GFP_ZERO since elements may come from > memory that has already been released by mempool_free(). > > Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly > initialize it to 0. We used to have the explicit memset there, but then changed that, because I was under the impression that since 2007-07-17 d07dbea, Slab allocators: support __GFP_ZERO in all allocators it was supported? Lars Ellenberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] fbdev: ssd1307fb: Add module parameter bitsperpixel.
On 14/02/15 17:54, Maxime Ripard wrote: > On Sat, Feb 07, 2015 at 05:05:03PM +0100, Thomas Niederprüm wrote: >> Am Sat, 7 Feb 2015 12:20:43 +0100 >> schrieb Maxime Ripard : >> >>> On Fri, Feb 06, 2015 at 11:28:11PM +0100, nied...@physik.uni-kl.de >>> wrote: From: Thomas Niederprüm This patch adds a module parameter 'bitsperpixel' to adjust the colordepth of the framebuffer. All values >1 will result in memory map of the requested color depth. However only the MSB of each pixel will be sent to the device. The framebuffer identifies itself as a grayscale display with the specified depth. >>> >>> I'm not sure this is the right thing to do. >>> >>> The bits per pixel for this display is rightfully defined, used and >>> reported to the userspace, why would you want to change that? >> >> You are right of course. The display is 1bpp and it reports to be 1 >> bpp. The problem is that there is almost no userspace library that can >> handle 1 bit framebuffers correctly. So it is nice if the framebuffer >> (optionally) can expose itself as 8 bits per pixel grayscale to the >> userspace program. As an example this allows to run DirectFB on the >> framebuffer, which is not possible out of the box for 1bpp. >> >> Also note that if do not set the module parameter at load time >> the framebuffer will be 1bpp. So you have to actively set that module >> parameter to make the framebuffer pretend to be more than 1bpp. >> >> In any case I don't cling to that patch, I just thought it was a nice >> feature. > > I'd say that the right fix would be to patch DirectFB, instead of > faking that in the kernel. > > But again, that's probably Tomi's call, not mine. Right, I'm not thrilled =). I don't think it's a good idea to lie to the userspace (except when fixing regressions). Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC] lib/vsprintf.c: Even faster decimal conversion
On Thu, Mar 05 2015, Rasmus Villemoes wrote: > On Thu, Mar 05 2015, Tejun Heo wrote: > >> I'd like to see how this actually affects larger operations - sth >> along the line of top consumes D% less CPU cycles w/ N processes - if >> for nothing else, just to get the sense of scale, > > That makes sense. I'll see if I can get some reproducible numbers, but > I'm afraid the effect drowns in all the syscall overhead. Which would be > a valid argument against touching the code. I wasn't able to come up with a way to measure the absolute %cpu reliably enough (neither from top's own output or using something like watch -n1 ps -p $toppid -o %cpu) - it fluctuates too much to see any difference. But using perf I was able to get somewhat stable numbers, which suggest an improvement in the 0.5-1.0% range [1]. Measured with 1 [2] sleeping processes in an idle virtual machine (and on mostly idle host), patch on top of 3.19.0. Extracting the functions involved in the decimal conversion I get new1.txt: 2.35% top [kernel.kallsyms] [k] num_to_str new2.txt: 2.70% top [kernel.kallsyms] [k] num_to_str old1.txt: 2.25% top [kernel.kallsyms] [k] num_to_str old2.txt: 2.18% top [kernel.kallsyms] [k] num_to_str new1.txt: 0.63% top [kernel.kallsyms] [k] put_dec new2.txt: 0.71% top [kernel.kallsyms] [k] put_dec old1.txt: 0.67% top [kernel.kallsyms] [k] put_dec old2.txt: 0.59% top [kernel.kallsyms] [k] put_dec new1.txt: 0.53% top [kernel.kallsyms] [k] put_dec_full8 new2.txt: 0.55% top [kernel.kallsyms] [k] put_dec_full8 old1.txt: 1.09% top [kernel.kallsyms] [k] put_dec_full9 old2.txt: 1.15% top [kernel.kallsyms] [k] put_dec_full9 new1.txt: 1.12% top [kernel.kallsyms] [k] put_dec_trunc8 new2.txt: 1.22% top [kernel.kallsyms] [k] put_dec_trunc8 old1.txt: 1.64% top [kernel.kallsyms] [k] put_dec_trunc8 old2.txt: 1.65% top [kernel.kallsyms] [k] put_dec_trunc8 I can't explain why num_to_str apparently becomes slightly slower (the patch essentially didn't touch it), but the put_dec_ helpers in any case make up for that. If someone has a suggestion for a better way of measuring this I'm all ears. Thanks, Rasmus [1] in terms of #cycles [2] numbers for 2000 and 5000 processes are quite similar. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] fbdev: ssd1307fb: Add sysfs handles to expose contrast and dim setting to userspace.
On 09/02/15 10:52, Maxime Ripard wrote:
> On Sat, Feb 07, 2015 at 05:42:44PM +0100, Thomas Niederprüm wrote:
+static struct device_attribute device_attrs[] = {
+ __ATTR(contrast, S_IRUGO|S_IWUSR, show_contrast,
store_contrast),
+ __ATTR(dim, S_IRUGO|S_IWUSR, show_dim, store_dim),
+
+};
+
>>>
>>> I would have thought this was something accessible through the
>>> framebuffer ioctl.
>>>
>>> Apparently it's not, at least for the contrast, so maybe it should be
>>> added there, instead of doing it for a single driver?
>>
>> I think the contrast setting for an OLED display is much like the
>> backlight setting for LCD panel. Since there is also no ioctl to set
>> the backlight of an LCD I wonder if the contrast of an OLED should have
>> one.
>
> It's too much of framebuffer interface debate for me here. Tomi?
We have backlight and contrast already in backlight-class and lcd-class
(drivers/video/backlight/backlight.c and drivers/video/backlight/lcd.c).
Are those something that could be used here instead of custom sysfs files?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH V4 2/2] spmi: pmic_arb: add support for hw version 2
Ping.
On Mon, 2015-02-23 at 11:59 +0200, Ivan T. Ivanov wrote:
> Hi Gilad,
>
> On Thu, 2015-02-19 at 15:54 -0700, Gilad Avidov wrote:
> > Qualcomm PMIC Arbiter version-2 changes from version-1 are:
> >
> > - Some different register offsets.
> > - New channel register space, one per PMIC peripheral (ppid).
> > All tx traffic uses these channels.
> > - New observer register space. All rx trafic uses this space.
> > - Different command format for spmi command registers.
> >
> > Acked-by: Sagar Dharia
> > Signed-off-by: Gilad Avidov >
>
>
>
> > @@ -645,12 +796,67 @@ static int spmi_pmic_arb_probe(struct platform_device
> > *pdev)
> > pa->spmic = ctrl;
> >
> > res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core");
> > - pa->base = devm_ioremap_resource(&ctrl->dev, res);
> > - if (IS_ERR(pa->base)) {
> > - err = PTR_ERR(pa->base);
> > + core = devm_ioremap_resource(&ctrl->dev, res);
> > + if (IS_ERR(core)) {
> > + err = PTR_ERR(core);
> > goto err_put_ctrl;
> > }
> >
> > + hw_ver = readl_relaxed(core + PMIC_ARB_VERSION);
> > + is_v1 = (hw_ver < PMIC_ARB_VERSION_V2_MIN);
> > +
> > + dev_info(&ctrl->dev, "PMIC Arb Version-%d (0x%x)\n", (is_v1 ? 1 :
> > 2),
> > + hw_ver);
> > +
> > + if (is_v1) {
> > + pa->ver_ops = &pmic_arb_v1;
> > + pa->wr_base = core;
> > + pa->rd_base = core;
> > + } else {
> > + u8 chan;
> > + u16 ppid;
> > + u32 regval;
> > +
> > + pa->ver_ops = &pmic_arb_v2;
> > + devm_iounmap(&ctrl->dev, core);
> > +
> > + pa->ppid_to_chan = devm_kzalloc(&ctrl->dev,
> > + PPID_TO_CHAN_TABLE_SZ, GFP_KERNEL);
> > + if (!pa->ppid_to_chan) {
> > + err = -ENOMEM;
> > + goto err_put_ctrl;
> > + }
> > + /*
> > + * PMIC_ARB_REG_CHNL is a table in HW mapping
> > channel to ppid.
> > + * ppid_to_chan is an in-memory invert of that table.
> > + */
> > + for (chan = 0; chan < PMIC_ARB_MAX_CHNL; ++chan) {
> > + regval = readl_relaxed(pa->rd_base +
>
> rd_base is not initialized at this point.
>
> > +
> > PMIC_ARB_REG_CHNL(chan));
> > + if (!regval)
> > + continue;
> > +
> > + ppid = (regval >> 8) & 0xFFF;
> > + pa->ppid_to_chan[ppid] = chan;
> > + }
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > +
> > "obsrvr");
> > + pa->rd_base = devm_ioremap_resource(&ctrl->dev, res);
>
> and they are compile warnings:
>
> drivers/spmi/spmi-pmic-arb.c: In function ‘pmic_arb_read_cmd’:
> drivers/spmi/spmi-pmic-arb.c:310:4: warning: format ‘%d’ expects argument of
> type ‘int’, but
> argument 4 has type ‘size_t’ [-Wformat=]
> PMIC_ARB_MAX_TRANS_BYTES, len);
> ^
> drivers/spmi/spmi-pmic-arb.c: In function ‘pmic_arb_write_cmd’:
> drivers/spmi/spmi-pmic-arb.c:357:4: warning: format ‘%d’ expects argument of
> type ‘int’, but
> argument 4 has type ‘size_t’ [-Wformat=]
> PMIC_ARB_MAX_TRANS_BYTES, len);
> ^
>
> Ivan
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 5/6] drm/imx: Remove local fbdev emulation Kconfig option
Hi Archit, thanks for the cleanup! Am Dienstag, den 10.03.2015, 15:11 +0530 schrieb Archit Taneja: > DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev emulation > for > the imx kms driver. > > Remove this local config option and use the top level DRM_FBDEV_EMULATION > config > option where applicable. Using this config lets us also prevent wrapping > around > drm_fb_helper_* calls with #ifdefs in certain places. > > We replace the #ifdef in imx_drm_driver_load with CONFIG_DRM_FBDEV_EMULATION. > It's probably okay to get remove the #ifdef itself, but just left it here for > now to be safe. It can be removed after some testing. > > Signed-off-by: Archit Taneja Tested-by: Philipp Zabel (Both with and without the #ifdef CONFIG_DRM_FBDEV_EMULATION removed.) Although this is for another patch, I think the legacyfb_depth module_param should be removed altogether if CONFIG_DRM_FBDEV_EMULATION is disabled, so maybe that #ifdef should stay. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched: divide error in sg_capacity_factor
On 03/10/2015 12:29 AM, Ingo Molnar wrote: > > * Sasha Levin wrote: > >> Hi all, >> >> While fuzzing with trinity inside the latest -next kernel using trinity I've >> stumbled on: >> >> [ 936.784266] divide error: [#1] PREEMPT SMP KASAN >> [ 936.793957] RIP: find_busiest_group (kernel/sched/fair.c:6152 >> kernel/sched/fair.c:6223 kernel/sched/fair.c:6341 kernel/sched/fair.c:6603) > > Hm, these line numbers don't seem to match up very well with my > version of linux-next: > > 28855005be1d Add linux-next specific files for 20150306 > > and the Git version info included in the oops seems useless: > > 4.0.0-rc1-sasha-00044-ge21109a > > $ git log e21109a > fatal: ambiguous argument 'e21109a': unknown revision or path not in the > working tree. > > I think the kernel's SHA1 should be made at least 12 char wide, > regardless of the user's gitconfig::core.abbrev settings. > > Also, latest linux-next is -rc2 based, while your version string says > -rc1. > >> [ 936.829403] load_balance (kernel/sched/fair.c:6857) > > this does not match up either. > >> [ 936.829403] run_rebalance_domains (kernel/sched/fair.c:7494 >> kernel/sched/fair.c:7659) > > The line numbers are not even close to anything related: > run_rebalance_domains() starts at line 7666 and ends at 7680. Right, this is my fuck up. It seems that I was fuzzing 4.0-rc1 rather than -next as I thought I was. I forgot to go back to -next after I tested a few things on Linus's tree. So the line numbers should match correctly with Linus's tree as you've already guessed below. > Also, why are the offsets into the function missing from the output? > Those would allow the rough determination of the crash site, even if > debuginfo is crap. I found that offsets are useless here because of the really odd things the compiler does based on my config. There's so many things that got inlined in this case that I think offsets wouldn't mean anything to you here. For example, in this case the division by 0 happened on load_balance+0x88a/0x2399. > I also checked Linus's latest, and they do seem to match up better: > > affb8172de39 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm > > and the line number gives: > > capacity_factor = min_t(unsigned, > capacity_factor, DIV_ROUND_CLOSEST(capacity, > SCHED_CAPACITY_SCALE)); > > but that's a division with a constant? Should not trap. > > So I rebuild a kernel with debug info, pattern matched the disassembly > you provided, and that gave me this division: > > (gdb) list *0x8107d958 > 0x8107d958 is in find_busiest_group (kernel/sched/fair.c:6162). > 6157capacity = group->sgc->capacity; > 6158capacity_orig = group->sgc->capacity_orig; > 6159cpus = group->group_weight; > 6160 > 6161/* smt := ceil(cpus / capacity), assumes: 1 < smt_capacity < > 2 */ > 6162smt = DIV_ROUND_UP(SCHED_CAPACITY_SCALE * cpus, > capacity_orig); > 6163capacity_factor = cpus / smt; /* cores */ > 6164 > 6165capacity_factor = min_t(unsigned, > 6166capacity_factor, DIV_ROUND_CLOSEST(capacity, > SCHED_CAPACITY_SCALE)); This is the division I was seeing as well. > So this too seems not very plausible: 'capacity_orig' comes straight > from group->sgc->capacity_orig, which is: > > - boot time initialized > > - sometimes recalculated during CPU hot-plug: not sure how much of >that your tests are doing? I'm not forcing them, but they do happen pretty often. > - but otherwise it's fairly constant and should have crashed your >system early on if it was set up wrong > > unless I missed something that is. > >> [ 936.829403] __do_softirq (kernel/softirq.c:273 >> include/linux/jump_label.h:114 include/trace/events/irq.h:126 >> kernel/softirq.c:274) >> [ 936.829403] irq_exit (kernel/softirq.c:350 kernel/softirq.c:391) >> [ 936.829403] smp_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:918) >> [ 936.829403] apic_timer_interrupt (arch/x86/kernel/entry_64.S:958) >> [ 936.829403] >> [ 936.829403] print_context_stack (arch/x86/kernel/dumpstack.c:105) >> [ 936.829403] dump_trace (arch/x86/kernel/dumpstack_64.c:244) >> [ 936.829403] save_stack_trace (arch/x86/kernel/stacktrace.c:64) >> [ 936.829403] __set_page_owner (mm/page_owner.c:72) >> [ 936.829403] get_page_from_freelist (include/linux/page_owner.h:26 >> mm/page_alloc.c:2176) >> [ 936.829403] __alloc_pages_nodemask (mm/page_alloc.c:2844) >> [ 936.829403] alloc_pages_vma (mm/mempolicy.c:2007) >> [ 936.829403] handle_mm_fault (mm/memory.c:2156 mm/memory.c:3164 >> mm/memory.c:3269 mm/memory.c:3298) >> [ 936.829403] __do_page_fault (arch/x86/mm/fault.c:1235) >> [ 936.829403] trace_do_page_fault (arch/x86/mm/fault.c:1329) >> [ 936.829403] do_async_page_fault (arch/x86/kernel/kvm.c:280) >> [ 936.829403] async_page_fault (arch/x86/kernel/entry_64.S:1295) > > So debug info weirdnesses aside, ot
Re: [tip:locking/core] locking/rwsem: Fix lock optimistic spinning when owner is not running
On Sat, Mar 07, 2015 at 06:13:47PM +0100, Oleg Nesterov wrote:
> I think the patch is fine, but this reminds me...
>
> On 03/07, tip-bot for Jason Low wrote:
> >
> > bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct
> > *owner)
> > {
> > long count;
> >
> > rcu_read_lock();
> > - while (owner_running(sem, owner)) {
> > - /* abort spinning when need_resched */
> > - if (need_resched()) {
> > + while (sem->owner == owner) {
> > + /*
> > +* Ensure we emit the owner->on_cpu, dereference _after_
> > +* checking sem->owner still matches owner, if that fails,
> > +* owner might point to free()d memory, if it still matches,
> > +* the rcu_read_lock() ensures the memory stays valid.
>^^
>
> Yes, this is another case when we wrongly assume this.
>
> Peter, should I resend
>
> [PATCH 3/3] introduce task_rcu_dereference()
> http://marc.info/?l=linux-kernel&m=141443631413914
>
> ? or should we add another call_rcu() in finish_task_switch() (like -rt does)
> to make this true?
Yeah, I think the extra call_rcu() makes most sense.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: svm: make wbinvd faster
2015-03-09 20:28-0300, Marcelo Tosatti: > On Fri, Feb 27, 2015 at 06:19:18PM -0600, Joel Schopp wrote: > > From: David Kaplan > > No need to re-decode WBINVD since we know what it is from the intercept. > > > > Signed-off-by: David Kaplan > > [extracted from larger unlrelated patch, forward ported, tested] > > Signed-off-by: Joel Schopp > > Can't you disable the intercept if need_emulate_wbinvd(vcpu) == false? I don't think we want to: it should be faster to intercept and ignore than to invalidate all caches. The exit doesn't affect other physical cores and costs just about 10(?) L3 cache misses. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] pinctrl: Introduce TI IOdelay configuration driver
On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon wrote:
> SoC family such as DRA7 family of processors have, in addition
> to the regular muxing of pins (as done by pinctrl-single), an
> additional hardware module called IODelay which is also expected to be
> configured. This "IODelay" module has it's own register space that is
> independent of the control module.
>
> It is advocated strongly in TI's official documentation considering
> the existing design of the DRA7 family of processors during mux or
> IODelay reconfiguration, there is a potential for a significant glitch
> which may cause functional impairment to certain hardware. It is
> hence recommended to do as little of muxing as absolutely necessary
> without I/O isolation (which can only be done in initial stages of
> bootloader).
>
> NOTE: with the system wide I/O isolation scheme present in DRA7 SoC
> family, it is not reasonable to do stop all I/O operations for every
> such pad configuration scheme. So, we will let it glitch when used in
> this mode.
>
> Even with the above limitation, certain functionality such as MMC has
> mandatory need for IODelay reconfiguration requirements, depending on
> speed of transfer. In these cases, with careful examination of usecase
> involved, the expected glitch can be controlled such that it does not
> impact functionality.
>
> In short, IODelay module support as a padconf driver being introduced
> here is not expected to do SoC wide I/O Isolation and is meant for
> a limited subset of IODelay configuration requirements that need to
> be dynamic and whose glitchy behavior will not cause functionality
> failure for that interface.
>
> Signed-off-by: Nishanth Menon
> Signed-off-by: Lokesh Vutla
Pending the conclusion of my remark on the bindings that this
should use the generic pin config bindings... here are some
"normal" review comments.
> +config PINCTRL_TI_IODELAY
> + bool "TI IODelay Module pinconf driver"
> + depends on OF
> + select PINCONF
> + select GENERIC_PINCONF
> + select REGMAP_MMIO
> + help
> + Say Y here to support Texas Instruments' IODelay pinconf driver.
> + IODelay module is used for the DRA7 SoC family. This driver is in
> + addition to PINCTRL_SINGLE which controls the mux.
If the driver is "in addition to PINCTRL_SINGLE", then it
should depend on it.
> +/* Should I change this? Abuse? */
> +#define IODELAY_MUX_PINS_NAME "pinctrl-single,pins"
Yeah this is abuse and is why you should use the generic
bindings with just "pins" instead, and use the generic pinconf
parameters to set them up.
> + * struct ti_iodelay_conf_vals - Description of each configuration
> parameters.
> + * @offset:Configuration register offset
> + * @a_delay: Agnostic Delay (in ps)
> + * @g_delay: Gnostic Delay (in ps)
> + */
> +struct ti_iodelay_conf_vals {
> + u16 offset;
> + u16 a_delay;
> + u16 g_delay;
> +};
So I don't think it's a good idea to get the register offset from
the device tree. The driver should know these.
> +/**
> + * struct ti_iodelay_reg_values - Computed io_reg configuration values (see
> TRM)
> + * @coarse_ref_count: Coarse reference count
> + * @coarse_delay_count:Coarse delay count
> + * @fine_ref_count:Fine reference count
> + * @fine_delay_count: Fine Delay count
> + * @ref_clk_period:Reference Clock period
> + * @cdpe: Coarse delay parameter
> + * @fdpe: Fine delay parameter
> + */
> +struct ti_iodelay_reg_values {
> + u16 coarse_ref_count;
If you're doing reference counting, use kref.
> + u16 coarse_delay_count;
> +
> + u16 fine_ref_count;
Dito.
> + u16 fine_delay_count;
> +
> + u16 ref_clk_period;
> +
> + u32 cdpe;
> + u32 fdpe;
> +};
> +/**
> + * struct ti_iodelay_pin_name - name of the pins
> + * @name: name
> + */
> +struct ti_iodelay_pin_name {
> + char name[IODELAY_REG_NAME_LEN];
> +};
What is this? The pin control subsystem already has a struct
for naming pins. struct pinctrl_pin_desc.
Are you reimplementing core functionality?
The generic pin config reference pins by name, and since you
obviously like to encode these into you data you can just
as well use that method for this too.
Again I think this is a side effect from using the pinctrl-single
concepts, if you think of this as some other pinctrl driver
I think this will fall out nicely.
> +/**
> + * struct ti_iodelay_device - Represents information for a IOdelay instance
> + * @dev: device pointer
> + * @reg_base: Remapped virtual address
> + * @regmap: Regmap for this IOdelay instance
> + * @pctl: Pinctrl device
> + * @desc: pinctrl descriptor for pctl
> + * @pa: pinctrl pin wise description
> + * @names: names of the pins
> + * @groups: list of pinconf groups for iodelay instance
> + * @ngroups: number of groups in the list
> + * @mutex: mutex to protect group list modification
> + * @reg_data: Register definition data fo
Re: [PATCH 2/2] spi: qup: Request CS GPIO's during probe
On Tue, Mar 10, 2015 at 10:10:56AM +0200, Ivan T. Ivanov wrote: > On Mon, 2015-03-09 at 18:28 +, Mark Brown wrote: > > > About the API usage, point taken. GPIO requesting part is more important > > > in this case. pinctrl core did not request pins and wrong DT configuration > > > could lead to surprises without any warnings or errors. > > That doesn't answer my concern at all. > I am not sure that I am following you. > I can not use spi_master::cs_gpios, which is populated by > of_spi_register_master(), because spi_register_master() > populate SPI devices and they could issue setup method. I'm sorry but I can't parse the above. What does "they could issue setup method" mean and why is it a problem? > Requesting GPIO's in core framework is also not a easy > option because of arguments here[1]. We should really fix that though. signature.asc Description: Digital signature
Re: ARM: OMPA4+: is it expected dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64)); to fail?
On Fri, Mar 06, 2015 at 11:47:48PM +0200, grygorii.stras...@linaro.org wrote:
> Hi Russell,
>
> On 03/05/2015 10:17 PM, Russell King - ARM Linux wrote:
> > On Thu, Mar 05, 2015 at 08:55:07PM +0200, grygorii.stras...@linaro.org
> > wrote:
> >> The dma_coerce_mask_and_coherent() will fail in case 'Example 3' and
> >> succeed in cases 1,2.
> >> dma-mapping.c --> __dma_supported()
> >>if (sizeof(mask) != sizeof(dma_addr_t) && <== true for all OMAP4+
> >>mask > (dma_addr_t)~0 &&<== true for DMA_BIT_MASK(64)
> >>dma_to_pfn(dev, ~0) < max_pfn) { <== true only for Example 3
> >
> > Hmm, I think this may make more sense to be "< max_pfn - 1" here, as
> > that would be better suited to our intention.
> >
> > The result of dma_to_pfn(dev, ~0) is the maximum PFN which we could
> > address via DMA, but we're comparing it with the maximum PFN in the
> > system plus 1 - so we need to subtract one from it.
>
> Ok. I'll try it.
Any news on this - I think it is a real off-by-one bug which we should
fix in any case.
Thanks.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] livepatch/module: Correctly handle going modules
On Tue 2015-03-10 12:53:21, Rusty Russell wrote: > Petr Mladek writes: > > On Sat 2015-03-07 11:34:36, Rusty Russell wrote: > >> I don't think you should handle going modules at all. Rarely happens, > >> and it should happen fast. > > > > I would like to handle it correctly. It would be pity to break a system > > just because of a module removal. Also the extra overhead will be > > very small and it will happen only very rarely. > > I don't understand why you don't just stop modules. I'm happy to write > "int stop_module_changes() / void restart_module_changes()" for you. > > This is far far simpler. Stop module changes before you start patching. > Restart after it's done. Interesting idea. stop_module_changes() would need to prevent anyone from entering COMING and GOING module states. Also it would need to wait for other modules to leave these states. As you mentioned later, we would need to exclude the current module because patches are added by a module and stop_module_changes() would need to be called from mod->init() script. In fact, we would need to exclude all modules that called stop_module_changes() to prevent a deadlock. > Is your intent to apply patches to modules which are applied (long) > after the original patch? Yes, we want to apply already loaded patches to coming modules. > Or leave that problem to userspace (ie. assume you've updated the > on-disk modules)? It would make things too complicated for our use case. We allow to install any kernel build in parallel with another kernel build. It makes it easier to reboot with the old working kernel if things went wrong. Most (default) modules are distributed with the kernel, so we would need to update the kernel as well and make it special to override the patched one. Also it would create a strange mix. The kernel would be able to load modules from different builds. Therefore crashdump would be much harder to analyze. Another problem will be with the module providing the patch. It will be needed for the original kernel but it might[*] be incompatible with the fixed one. [*] There is a possibility to hardcode relocation tables. It is handy when the patch is generated automatically or when the patch need to modify a module function with an ambiguous name. > >> If you can hold the module_lock, the easiest thing to do is have us wake > >> module_wq when a module is freed, then you can just: > > > > Unfortunately, we could not use a waitqueue easily. We would need to > > release klp_mutex to do not block going modules. But we could not > > do so in the middle of a patch adding. > > > > BTW: It seems that module_wq is used for coming modules. We could not > > use it for coming modules from the same reason. In addition, waiters > > are weaken after mod->init(). But we would need to apply the patch > > before mod->init() to avoid any inconsistency. > > You grab the module mutex using stop_module_changes() before anything > else. > > Or are you using the "failed module loading" hack to apply patches? > That would imply that the current module would have to be excluded > from the stop_module_changes() check, but should still be possible. Yes, we will need to be careful to avoid deadlocks. I think that stop_module_changes/restart_module_changes feature makes sense only if it will have more users. Otherwise, the approach with the extra flag looks much easier to me. Note that there is only one boolean/bit needed with the last version of the patch. Thanks a lot for review and feedback. I could try to implement it another way if you give me hints. Best Regards, Petr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 05/21] ARM64 / ACPI: Get RSDP and ACPI boot-time tables
On Tue, Mar 10, 2015 at 04:01:16PM +0800, Hanjun Guo wrote:
> >>index 000..f052e7a
> >>--- /dev/null
> >>+++ b/arch/arm64/kernel/acpi.c
> >>@@ -0,0 +1,101 @@
> >>+/*
> >>+ * ARM64 Specific Low-Level ACPI Boot Support
> >>+ *
> >>+ * Copyright (C) 2013-2014, Linaro Ltd.
> >>+ * Author: Al Stone
> >>+ * Author: Graeme Gregory
> >>+ * Author: Hanjun Guo
> >>+ * Author: Tomasz Nowicki
> >>+ * Author: Naresh Bhat
> >>+ *
> >>+ * This program is free software; you can redistribute it and/or modify
> >>+ * it under the terms of the GNU General Public License version 2 as
> >>+ * published by the Free Software Foundation.
> >>+ */
> >>+
> >>+#define pr_fmt(fmt) "ACPI: " fmt
> >>+
> >>+#include
> >>+#include
> >>+#include
> >>+#include
> >>+#include
> >>+#include
> >>+#include
> >>+#include
> >>+
> >>+int acpi_noirq;/* skip ACPI IRQ initialization */
> >>+int acpi_disabled;
> >>+EXPORT_SYMBOL(acpi_disabled);
> >>+
> >>+int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ
> >>initialization */
> >>+EXPORT_SYMBOL(acpi_pci_disabled);
> >>+
> >>+/*
> >>+ * __acpi_map_table() will be called before page_init(), so early_ioremap()
> >>+ * or early_memremap() should be called here to for ACPI table mapping.
> >>+ */
> >>+char *__init __acpi_map_table(unsigned long phys, unsigned long size)
> >>+{
> >>+ if (!phys || !size)
> >
> >Is there a reason to rule out physical address 0x0 ?
>
> No particular reasons, unless some arch/firmware limits, I'm
> not sure if we need this check (x86 needs it), I'm CC Leif
> to confirm.
Nothing in UEFI explicitly bans using physical address 0 for anything,
and nothing in the architecture reserves it. So I don't think this
check is necessary.
/
Leif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] Allow compaction of unevictable pages
On Mon, Mar 09, 2015 at 04:48:43PM -0400, Eric B Munson wrote: > Currently, pages which are marked as unevictable are protected from > compaction, but not from other types of migration. The mlock > desctription does not promise that all page faults will be avoided, only > major ones so this protection is not necessary. This extra protection > can cause problems for applications that are using mlock to avoid > swapping pages out, but require order > 0 allocations to continue to > succeed in a fragmented environment. This patch removes the > ISOLATE_UNEVICTABLE mode and the check for it in __isolate_lru_page(). > Removing this check allows the removal of the isolate_mode argument from > isolate_migratepages_block() because it can compute the required mode > from the compact_control structure. > > To illustrate this problem I wrote a quick test program that mmaps a > large number of 1MB files filled with random data. These maps are > created locked and read only. Then every other mmap is unmapped and I > attempt to allocate huge pages to the static huge page pool. Without > this patch I am unable to allocate any huge pages after fragmenting > memory. With it, I can allocate almost all the space freed by unmapping > as huge pages. So mlock() is part of the POSIX real-time spec. For real-time purposes we very much do _NOT_ want page migration to happen. So while you might be following the letter of the spec you're very much violating the spirit of the thing. Also, there is another solution to your problem; you can compact mlock'ed pages at mlock() time. Furthermore, I would once again like to remind people of my VM_PINNED patches. The only thing that needs happening there is someone needs to deobfuscate the IB code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] arm/pmu: Reject groups spanning multiple hardware PMUs
On Mon, Mar 09, 2015 at 12:46:30PM +, Suzuki K. Poulose wrote: > From: "Suzuki K. Poulose" > > Don't allow grouping hardware events from different PMUs > (eg. CCI + CPU). Uhm, how does this work? If we have multiple hardware PMUs we'll stop scheduling events after the first failed event schedule. This can leave one of the PMUs severely under utilized. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] fbdev: ssd1307fb: Use vmalloc to allocate video memory.
On 14/02/15 16:22, Thomas Niederprüm wrote: > Am Thu, 12 Feb 2015 16:11:21 +0100 > schrieb Maxime Ripard : > >> On Sat, Feb 07, 2015 at 04:35:41PM +0100, Thomas Niederprüm wrote: >>> Am Sat, 7 Feb 2015 12:18:21 +0100 >>> schrieb Maxime Ripard : >>> Hi, On Fri, Feb 06, 2015 at 11:28:10PM +0100, nied...@physik.uni-kl.de wrote: > From: Thomas Niederprüm > > It makes sense to use vmalloc to allocate the video buffer > since it has to be page aligned memory for using it with mmap. Please wrap your commit log at 80 chars. >>> >>> I'll try to do so in future, sorry for that. >>> It looks like there's numerous fbdev drivers using this (especially since you copy pasted that code, without mentionning it). >>> >>> Yes, I should have mentioned that in the commit message. As >>> implicitly indicated in the cover letter the rvmalloc() and >>> rvfree() are copy pasted from the vfb driver. Honestly, I didn't >>> give this one too much thought. It seemed a viable solution to the >>> mmap problem. For a bit more history on that, see my comment below. >>> That should be turned into an allocator so that drivers all get this right. > Also deffered io seems buggy in combination with kmalloc'ed > memory (crash on unloading the module). And maybe that's the real issue to fix. >>> >>> The problem is solved by using vmalloc ;) >> >> Yep, but why do you need to mark the reserved pages? >> >> ... > > As far as I understood mmaped memory is marked as userspace memory in > the page table and is therefore subject to swapping. The pages are > marked reserved to make clear that this memory can not be swapped and > thus lock the pages in memory. See discussions [0,1,2]. Why is it a problem if it is swapped? Only CPU uses the memory, as far as I can see. Also, isn't doing __pa() for the memory returned by vmalloc plain wrong? What was the crash about when using kmalloc? It would be good to fix defio, as I don't see why it should not work with kmalloced memory. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 2/2] cgroups: add a pids subsystem
On 2015-03-10 04:10, Aleksa Sarai wrote: Hi Austin, Does pids limit make sense in the root cgroup? I would say it kind of does, although I would just expect it to track /proc/sys/kernel/pid_max (either as a read-only value, or as an alternative way to set it). Personally, that seems unintuitive. /proc/sys/kernel/pid_max and the pids cgroup controller are orthogonal features, why should they be able to affect each other (or even be aware of each other)? I wouldn't consider them entirely orthogonal, the sysctl value is the limiting factor for the maximal value that can be set in a given pids cgroup. Setting an unlimited value in the cgroup is functionally identical to setting it to be equal to /proc/sys/kernel/pid_max, and the root cgroup is functionally equivalent to /proc/sys/kernel/pid_max, because all tasks that aren't in another cgroup get put in the root. My only thought is that having the file that would set the limit there might make things much simpler for software that expects the entire cgroup structure to be hierarchical. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
DRAM bug exploitable on 50% machines without ECC (was Re: DRAM unreliable under specific access patern)
On Mon 2015-03-09 09:03:18, Mark Seaborn wrote: > On 6 January 2015 at 15:20, Pavel Machek wrote: > > On Mon 2015-01-05 19:23:29, One Thousand Gnomes wrote: > > Actually, I could not get my test code to run; and as code from > > > > https://github.com/mseaborn/rowhammer-test > > > > reproduces issue for me, I stopped trying. I could not get it to > > damage memory of other process than itself (but that should be > > possible), I guess that's next thing to try. > > FYI, rowhammer-induced bit flips do turn out to be exploitable. Here > are the results of my research on this: > http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html The excrement made physical contact with a hydro-electric powered oscillating air current distribution device. Thanks a lot for the report. One thing stands out: you ask for more openness from the hardware vendors, but then you mask the manufacturer names to make it easier for them to be quiet. Are corporate lawyers being nasty? Anyway, in name of full disclosure: Thinkpad x60: could not reproduce. 2009-era desktop: reproduced. BIOS Information Vendor: Intel Corp. Version: MJG4110H.86A.0006.2009.1223.1155 Release Date: 12/23/2009 Address: 0xF Runtime Size: 64 kB ROM Size: 1024 kB Characteristics: ... Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Product Name: Version: Serial Number: UUID: 56E3FDCE-66ED-11DF-87C2-001FE20E1E5F Wake-up Type: Power Switch SKU Number: Not Specified Family: Not Specified Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: Intel Corporation Product Name: DG41MJ Version: AAE54659-206 Serial Number: AZMJ02200117 Asset Tag: To be filled by O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To be filled by O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 CPU is Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz . I guess it makes sense to post to bugt...@securityfocus.com and get CVE number? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 13/21] ARM64 / ACPI: Parse MADT for SMP initialization
Hi Olof,
On 2015年03月06日 02:49, Olof Johansson wrote:
Hi,
On Wed, Feb 25, 2015 at 04:39:53PM +0800, Hanjun Guo wrote:
MADT contains the information for MPIDR which is essential for
SMP initialization, parse the GIC cpu interface structures to
get the MPIDR value and map it to cpu_logical_map(), and add
enabled cpu with valid MPIDR into cpu_possible_map.
ACPI 5.1 only has two explicit methods to boot up SMP, PSCI and
Parking protocol, but the Parking protocol is only specified for
ARMv7 now, so make PSCI as the only way for the SMP boot protocol
before some updates for the ACPI spec or the Parking protocol spec.
Parking protocol patches for SMP boot will be sent to upstream when
the new version of Parking protocol is ready.
CC: Lorenzo Pieralisi
CC: Catalin Marinas
CC: Will Deacon
CC: Mark Rutland
Tested-by: Suravee Suthikulpanit
Tested-by: Yijing Wang
Tested-by: Mark Langsdorf
Tested-by: Jon Masters
Tested-by: Timur Tabi
Tested-by: Robert Richter
Acked-by: Robert Richter
Signed-off-by: Hanjun Guo
Signed-off-by: Tomasz Nowicki
Some nits below. Up to you if you fix incrementally or respin, but I'd like to
see them fixed for consistency's sake.
Acked-by: Olof Johansson
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index 780f82c..bf22650 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -39,9 +39,10 @@ extern void show_ipi_list(struct seq_file *p, int prec);
extern void handle_IPI(int ipinr, struct pt_regs *regs);
/*
- * Setup the set of possible CPUs (via set_cpu_possible)
+ * Discover the set of possible CPUs and determine their
+ * SMP operations.
*/
-extern void smp_init_cpus(void);
+extern void of_smp_init_cpus(void);
This is inconsistent naming, we use dt some places, of elsewhere.
Do you mean dt_smp_init_cpus() here?
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index bdcc9fc..0f35d87 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -25,6 +25,10 @@
#include
#include
+#include
+#include
+#include
+
int acpi_noirq = 1; /* skip ACPI IRQ initialization */
int acpi_disabled = 1;
EXPORT_SYMBOL(acpi_disabled);
@@ -32,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
int acpi_pci_disabled = 1;/* skip ACPI PCI scan and IRQ initialization */
EXPORT_SYMBOL(acpi_pci_disabled);
[...]
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 97fa7f3..b278311 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -393,13 +393,16 @@ void __init setup_arch(char **cmdline_p)
if (acpi_disabled) {
unflatten_device_tree();
psci_dt_init();
+ cpu_read_bootcpu_ops();
+#ifdef CONFIG_SMP
+ of_smp_init_cpus();
+#endif
} else {
psci_acpi_init();
+ acpi_init_cpus();
}
- cpu_read_bootcpu_ops();
#ifdef CONFIG_SMP
- smp_init_cpus();
smp_build_mpidr_hash();
#endif
I'd rather do without another ifdef above and provide a stub for that function,
but again it might make sense to just keep a small smp_init_cpus() just as with
the psci setup.
The cpu_read_bootcpu_ops() should be pushed down to the dt implementation to
keep the paths more common between acpi and dt.
the declaration of of_smp_init_cpus() is in asm/smp.h, unfortunately
the way asm/smp.h is handled is generally a mess, it only be compiled
in SMP build:
#ifndef CONFIG_SMP
# error " included in non-SMP build"
#endif
so I think we need more cleanup before provide a stub function.
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/9] x86, pci: Abstract PCI config accessors and use AMD Fam10h workaround exclusively.
>From now on, readb()/writeb()/etc. generic calls are used as default
approach. Special MMIO accessors are registered for AMD Fam10h CPUs only.
Signed-off-by: Tomasz Nowicki
---
arch/x86/include/asm/pci_x86.h | 8 +++
arch/x86/pci/mmconfig-shared.c | 114 +
arch/x86/pci/mmconfig_32.c | 24 +
arch/x86/pci/mmconfig_64.c | 24 +
arch/x86/pci/numachip.c| 24 +
5 files changed, 128 insertions(+), 66 deletions(-)
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index d024f4d..c57c225 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -137,6 +137,11 @@ struct pci_mmcfg_region {
char name[PCI_MMCFG_RESOURCE_NAME_LEN];
};
+struct pci_mmcfg_mmio_ops {
+ u32 (*read)(int len, void __iomem *addr);
+ void (*write)(int len, void __iomem *addr, u32 value);
+};
+
extern int __init pci_mmcfg_arch_init(void);
extern void __init pci_mmcfg_arch_free(void);
extern int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
@@ -145,6 +150,9 @@ extern int pci_mmconfig_insert(struct device *dev, u16 seg,
u8 start, u8 end,
phys_addr_t addr);
extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
+extern u32 pci_mmio_read(int len, void __iomem *addr);
+extern void pci_mmio_write(int len, void __iomem *addr, u32 value);
+extern void pci_mmconfig_register_mmio(struct pci_mmcfg_mmio_ops *ops);
extern struct list_head pci_mmcfg_list;
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index dd30b7e..8b3bc4f 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -31,6 +31,118 @@ static DEFINE_MUTEX(pci_mmcfg_lock);
LIST_HEAD(pci_mmcfg_list);
+static u32
+pci_mmconfig_generic_read(int len, void __iomem *addr)
+{
+ u32 data = 0;
+
+ switch (len) {
+ case 1:
+ data = readb(addr);
+ break;
+ case 2:
+ data = readw(addr);
+ break;
+ case 4:
+ data = readl(addr);
+ break;
+ }
+
+ return data;
+}
+
+static void
+pci_mmconfig_generic_write(int len, void __iomem *addr, u32 value)
+{
+ switch (len) {
+ case 1:
+ writeb(value, addr);
+ break;
+ case 2:
+ writew(value, addr);
+ break;
+ case 4:
+ writel(value, addr);
+ break;
+ }
+}
+
+static struct pci_mmcfg_mmio_ops pci_mmcfg_mmio_default = {
+ .read = pci_mmconfig_generic_read,
+ .write = pci_mmconfig_generic_write,
+};
+
+static struct pci_mmcfg_mmio_ops *pci_mmcfg_mmio = &pci_mmcfg_mmio_default;
+
+static u32
+pci_mmconfig_amd_read(int len, void __iomem *addr)
+{
+ u32 data = 0;
+
+ switch (len) {
+ case 1:
+ data = mmio_config_readb(addr);
+ break;
+ case 2:
+ data = mmio_config_readw(addr);
+ break;
+ case 4:
+ data = mmio_config_readl(addr);
+ break;
+ }
+
+ return data;
+}
+
+static void
+pci_mmconfig_amd_write(int len, void __iomem *addr, u32 value)
+{
+ switch (len) {
+ case 1:
+ mmio_config_writeb(addr, value);
+ break;
+ case 2:
+ mmio_config_writew(addr, value);
+ break;
+ case 4:
+ mmio_config_writel(addr, value);
+ break;
+ }
+}
+
+static struct pci_mmcfg_mmio_ops pci_mmcfg_mmio_amd_fam10h = {
+ .read = pci_mmconfig_amd_read,
+ .write = pci_mmconfig_amd_write,
+};
+
+void
+pci_mmconfig_register_mmio(struct pci_mmcfg_mmio_ops *ops)
+{
+ pci_mmcfg_mmio = ops;
+}
+
+u32
+pci_mmio_read(int len, void __iomem *addr)
+{
+ if (!pci_mmcfg_mmio) {
+ pr_err("PCI config space has no accessors !");
+ return 0;
+ }
+
+ return pci_mmcfg_mmio->read(len, addr);
+}
+
+void
+pci_mmio_write(int len, void __iomem *addr, u32 value)
+{
+ if (!pci_mmcfg_mmio) {
+ pr_err("PCI config space has no accessors !");
+ return;
+ }
+
+ pci_mmcfg_mmio->write(len, addr, value);
+}
+
static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
{
if (cfg->res.parent)
@@ -231,6 +343,8 @@ static const char *__init pci_mmcfg_amd_fam10h(void)
return NULL;
}
+ pci_mmconfig_register_mmio(&pci_mmcfg_mmio_amd_fam10h);
+
return "AMD Family 10h NB";
}
diff --git a/arch/x86/pci/mmconfig_32.c b/arch/x86/pci/mmconfig_32.c
index 43984bc..4b3d025 100644
--- a/arch/x86/pci/mmconfig_32.c
+++ b/arch/x86/pci/mmconfig_32.c
@@ -71,17 +71,7 @@ err: *value = -1;
pci_exp_set_dev_base(base, bus, devfn);
- switch
[PATCH v3 0/9] PCI: MMCONFIG clean up
MCFG ACPI table and PCI ECAM standard have no arch dependencies so it can be
used across all architectures. Currently MMCONFIG related code resides in
arch/x86 directories. This patch set is going to isolate non-architecture
specific code and make it accessible for all architectures.
v2 -> v3 changes:
- rebase patch set v2 to v4.0-rc1
v1 -> v2 changes:
- use generic readb/readw etc. accessors instead of AMD Fam10h workaround
- separate ACPI and ECAM code
- improve ECAM code naming
Tomasz Nowicki (9):
x86, pci: Clean up comment about buggy MMIO config space access for
AMD Fam10h CPUs.
x86, pci: Abstract PCI config accessors and use AMD Fam10h workaround
exclusively.
x86, pci: Reorder logic of pci_mmconfig_insert() function
x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code
out of arch/x86/ directory
pci, acpi, mcfg: Provide generic implementation of MCFG code
initialization.
x86, pci: mmconfig_{32,64}.c code refactoring - remove code
duplication.
x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM
driver.
pci, acpi, mcfg: Share ACPI PCI config space accessors.
pci, ecam: Improve naming for ecam.c content and areas where it is
used.
arch/x86/Kconfig | 3 +
arch/x86/include/asm/pci_x86.h | 34 +---
arch/x86/pci/Makefile | 5 +-
arch/x86/pci/acpi.c| 3 +-
arch/x86/pci/mmconfig-shared.c | 340 +++
arch/x86/pci/mmconfig_32.c | 47 ++
arch/x86/pci/mmconfig_64.c | 153 --
arch/x86/pci/numachip.c| 27 +---
drivers/acpi/Makefile | 1 +
drivers/acpi/mcfg.c| 121 ++
drivers/pci/Kconfig| 7 +
drivers/pci/Makefile | 5 +
drivers/pci/ecam.c | 356 +
drivers/xen/pci.c | 6 +-
include/linux/ecam.h | 56 +++
15 files changed, 668 insertions(+), 496 deletions(-)
delete mode 100644 arch/x86/pci/mmconfig_64.c
create mode 100644 drivers/acpi/mcfg.c
create mode 100644 drivers/pci/ecam.c
create mode 100644 include/linux/ecam.h
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/9] x86, pci: Reorder logic of pci_mmconfig_insert() function
This patch is the first step for MMCONFIG refactoring process.
Code that uses pci_mmcfg_lock will be moved to common file and become
accessible for all architectures. pci_mmconfig_insert() cannot be moved
so easily since it is mixing generic mmconfig code with x86 specific logic
inside of mutual exclusive block guarded by pci_mmcfg_lock.
To get rid of that constraint, we reorder actions as follow:
1. mmconfig entry allocation can be done first, no need to lock
2. insertion to iomem_resource has its own lock, no need to wrap it into mutex
3. insertion to mmconfig list can be done as the final step in separate
function (candidate for further refactoring)
Signed-off-by: Tomasz Nowicki
---
arch/x86/pci/mmconfig-shared.c | 100 ++---
1 file changed, 54 insertions(+), 46 deletions(-)
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 8b3bc4f..685cd4c 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -834,6 +834,39 @@ static int __init pci_mmcfg_late_insert_resources(void)
*/
late_initcall(pci_mmcfg_late_insert_resources);
+static int pci_mmconfig_inject(struct pci_mmcfg_region *cfg)
+{
+ struct pci_mmcfg_region *cfg_conflict;
+ int err = 0;
+
+ mutex_lock(&pci_mmcfg_lock);
+ cfg_conflict = pci_mmconfig_lookup(cfg->segment, cfg->start_bus);
+ if (cfg_conflict) {
+ if (cfg_conflict->end_bus < cfg->end_bus)
+ pr_info(FW_INFO "MMCONFIG for "
+ "domain %04x [bus %02x-%02x] "
+ "only partially covers this bridge\n",
+ cfg_conflict->segment, cfg_conflict->start_bus,
+ cfg_conflict->end_bus);
+ err = -EEXIST;
+ goto out;
+ }
+
+ if (pci_mmcfg_arch_map(cfg)) {
+ pr_warn("fail to map MMCONFIG %pR.\n", &cfg->res);
+ err = -ENOMEM;
+ goto out;
+ } else {
+ list_add_sorted(cfg);
+ pr_info("MMCONFIG at %pR (base %#lx)\n",
+ &cfg->res, (unsigned long)cfg->address);
+
+ }
+out:
+ mutex_unlock(&pci_mmcfg_lock);
+ return err;
+}
+
/* Add MMCFG information for host bridges */
int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
phys_addr_t addr)
@@ -845,66 +878,41 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8
start, u8 end,
if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
return -ENODEV;
- if (start > end)
+ if (start > end || !addr)
return -EINVAL;
- mutex_lock(&pci_mmcfg_lock);
- cfg = pci_mmconfig_lookup(seg, start);
- if (cfg) {
- if (cfg->end_bus < end)
- dev_info(dev, FW_INFO
-"MMCONFIG for "
-"domain %04x [bus %02x-%02x] "
-"only partially covers this bridge\n",
- cfg->segment, cfg->start_bus, cfg->end_bus);
- mutex_unlock(&pci_mmcfg_lock);
- return -EEXIST;
- }
-
- if (!addr) {
- mutex_unlock(&pci_mmcfg_lock);
- return -EINVAL;
- }
-
rc = -EBUSY;
cfg = pci_mmconfig_alloc(seg, start, end, addr);
if (cfg == NULL) {
dev_warn(dev, "fail to add MMCONFIG (out of memory)\n");
- rc = -ENOMEM;
+ return -ENOMEM;
} else if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
dev_warn(dev, FW_BUG "MMCONFIG %pR isn't reserved\n",
&cfg->res);
- } else {
- /* Insert resource if it's not in boot stage */
- if (pci_mmcfg_running_state)
- tmp = insert_resource_conflict(&iomem_resource,
- &cfg->res);
-
- if (tmp) {
- dev_warn(dev,
-"MMCONFIG %pR conflicts with "
-"%s %pR\n",
-&cfg->res, tmp->name, tmp);
- } else if (pci_mmcfg_arch_map(cfg)) {
- dev_warn(dev, "fail to map MMCONFIG %pR.\n",
-&cfg->res);
- } else {
- list_add_sorted(cfg);
- dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
-&cfg->res, (unsigned long)addr);
- cfg = NULL;
- rc = 0;
- }
+ goto error;
}
- if (cfg) {
- if (cfg->res.parent)
- release_resource(&cfg->res);
- kfree(cfg);
+ /* Insert resource if it's not in bo
[PATCH v3 7/9] x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM driver.
Architectures which want to take advantage of ECAM generic goodness
should select CONFIG_PCI_ECAM_GENERIC. Otherwise, like x86 32bits, machines
are obligated to provide own low-level ECAM calls.
Signed-off-by: Tomasz Nowicki
---
arch/x86/Kconfig | 1 +
arch/x86/pci/Makefile | 5 +-
arch/x86/pci/mmconfig_64.c | 127 -
drivers/pci/Kconfig| 3 ++
drivers/pci/ecam.c | 113
5 files changed, 121 insertions(+), 128 deletions(-)
delete mode 100644 arch/x86/pci/mmconfig_64.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dd926f4..9f30dab 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -141,6 +141,7 @@ config X86
select ACPI_LEGACY_TABLES_LOOKUP if ACPI
select X86_FEATURE_NAMES if PROC_FS
select SRCU
+ select PCI_ECAM_GENERIC if X86_64
config INSTRUCTION_DECODER
def_bool y
diff --git a/arch/x86/pci/Makefile b/arch/x86/pci/Makefile
index 5c6fc35..35c765b 100644
--- a/arch/x86/pci/Makefile
+++ b/arch/x86/pci/Makefile
@@ -1,7 +1,10 @@
obj-y := i386.o init.o
obj-$(CONFIG_PCI_BIOS) += pcbios.o
-obj-$(CONFIG_PCI_MMCONFIG) += mmconfig_$(BITS).o direct.o mmconfig-shared.o
+obj-$(CONFIG_PCI_MMCONFIG) += direct.o mmconfig-shared.o
+ifeq ($(BITS),32)
+obj-$(CONFIG_PCI_MMCONFIG) += mmconfig_32.o
+endif
obj-$(CONFIG_PCI_DIRECT) += direct.o
obj-$(CONFIG_PCI_OLPC) += olpc.o
obj-$(CONFIG_PCI_XEN) += xen.o
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
deleted file mode 100644
index fd857ea..000
--- a/arch/x86/pci/mmconfig_64.c
+++ /dev/null
@@ -1,127 +0,0 @@
-/*
- * mmconfig.c - Low-level direct PCI config space access via MMCONFIG
- *
- * This is an 64bit optimized version that always keeps the full mmconfig
- * space mapped. This allows lockless config space operation.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#define PREFIX "PCI: "
-
-static char __iomem *pci_dev_base(unsigned int seg, unsigned int bus, unsigned
int devfn)
-{
- struct pci_mmcfg_region *cfg = pci_mmconfig_lookup(seg, bus);
-
- if (cfg && cfg->virt)
- return cfg->virt + (PCI_MMCFG_BUS_OFFSET(bus) | (devfn << 12));
- return NULL;
-}
-
-int pci_mmcfg_read(unsigned int seg, unsigned int bus,
- unsigned int devfn, int reg, int len, u32 *value)
-{
- char __iomem *addr;
-
- /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
- if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
-err: *value = -1;
- return -EINVAL;
- }
-
- rcu_read_lock();
- addr = pci_dev_base(seg, bus, devfn);
- if (!addr) {
- rcu_read_unlock();
- goto err;
- }
-
- *value = pci_mmio_read(len, addr + reg);
- rcu_read_unlock();
-
- return 0;
-}
-
-int pci_mmcfg_write(unsigned int seg, unsigned int bus,
- unsigned int devfn, int reg, int len, u32 value)
-{
- char __iomem *addr;
-
- /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
- if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
- return -EINVAL;
-
- rcu_read_lock();
- addr = pci_dev_base(seg, bus, devfn);
- if (!addr) {
- rcu_read_unlock();
- return -EINVAL;
- }
-
- pci_mmio_write(len, addr + reg, value);
- rcu_read_unlock();
-
- return 0;
-}
-
-static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
-{
- void __iomem *addr;
- u64 start, size;
- int num_buses;
-
- start = cfg->address + PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
- num_buses = cfg->end_bus - cfg->start_bus + 1;
- size = PCI_MMCFG_BUS_OFFSET(num_buses);
- addr = ioremap_nocache(start, size);
- if (addr)
- addr -= PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
- return addr;
-}
-
-int __init pci_mmcfg_arch_init(void)
-{
- struct pci_mmcfg_region *cfg;
-
- list_for_each_entry(cfg, &pci_mmcfg_list, list)
- if (pci_mmcfg_arch_map(cfg)) {
- pci_mmcfg_arch_free();
- return 0;
- }
-
- return 1;
-}
-
-void __init pci_mmcfg_arch_free(void)
-{
- struct pci_mmcfg_region *cfg;
-
- list_for_each_entry(cfg, &pci_mmcfg_list, list)
- pci_mmcfg_arch_unmap(cfg);
-}
-
-int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg)
-{
- cfg->virt = mcfg_ioremap(cfg);
- if (!cfg->virt) {
- pr_err(PREFIX "can't map MMCONFIG at %pR\n", &cfg->res);
- return -ENOMEM;
- }
-
- return 0;
-}
-
-void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg)
-{
- if (cfg && cfg->virt) {
- iounma
[PATCH v3 8/9] pci, acpi, mcfg: Share ACPI PCI config space accessors.
MCFG can be used perfectly for all architectures which support ACPI.
ACPI mandates MCFG to describe PCI config space ranges which means
we should use MMCONFIG accessors by default.
Signed-off-by: Tomasz Nowicki
---
drivers/acpi/mcfg.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index 1e646fc..e285f62 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -13,6 +13,26 @@
#definePREFIX "MCFG: "
+/*
+ * raw_pci_read/write - ACPI PCI config space accessors.
+ *
+ * ACPI spec defines MCFG table as the way we can describe access to PCI config
+ * space, so let MCFG be default (__weak).
+ *
+ * If platform needs more fancy stuff, should provides its own implementation.
+ */
+int __weak raw_pci_read(unsigned int domain, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 *val)
+{
+ return pci_mmcfg_read(domain, bus, devfn, reg, len, val);
+}
+
+int __weak raw_pci_write(unsigned int domain, unsigned int bus,
+unsigned int devfn, int reg, int len, u32 val)
+{
+ return pci_mmcfg_write(domain, bus, devfn, reg, len, val);
+}
+
static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
struct acpi_mcfg_allocation *cfg)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 9/9] pci, ecam: Improve naming for ecam.c content and areas where it is used.
This commit is consequence of making x86 MMCONFIG code available for all
architectures. Current code has old name fashion so for the sake of
making it more understandable and express where it comes from,
we are changing functions/variables/macros etc. name *mmconfig* -> *ecam*
Signed-off-by: Tomasz Nowicki
---
arch/x86/pci/acpi.c| 2 +-
arch/x86/pci/mmconfig-shared.c | 64
arch/x86/pci/mmconfig_32.c | 16 ++--
arch/x86/pci/numachip.c| 2 +-
drivers/acpi/mcfg.c| 22 +++---
drivers/pci/ecam.c | 162 -
drivers/xen/pci.c | 6 +-
include/linux/ecam.h | 42 +--
8 files changed, 158 insertions(+), 158 deletions(-)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 5dfccef..fa3ef35 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -199,7 +199,7 @@ static int setup_mcfg_map(struct pci_root_info *info, u16
seg, u8 start,
static void teardown_mcfg_map(struct pci_root_info *info)
{
if (info->mcfg_added) {
- pci_mmconfig_delete(info->segment, info->start_bus,
+ pci_ecam_delete(info->segment, info->start_bus,
info->end_bus);
info->mcfg_added = false;
}
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 6dfe614..719dccf 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -30,8 +30,8 @@ static bool pci_mmcfg_running_state;
static bool pci_mmcfg_arch_init_failed;
const struct pci_raw_ops pci_mmcfg = {
- .read = pci_mmcfg_read,
- .write =pci_mmcfg_write,
+ .read = pci_ecam_read,
+ .write =pci_ecam_write,
};
static u32
@@ -70,7 +70,7 @@ pci_mmconfig_amd_write(int len, void __iomem *addr, u32 value)
}
}
-static struct pci_mmcfg_mmio_ops pci_mmcfg_mmio_amd_fam10h = {
+static struct pci_ecam_mmio_ops pci_mmcfg_mmio_amd_fam10h = {
.read = pci_mmconfig_amd_read,
.write = pci_mmconfig_amd_write,
};
@@ -84,7 +84,7 @@ static const char *__init pci_mmcfg_e7520(void)
if (win == 0x || win == 0xf000)
return NULL;
- if (pci_mmconfig_add(0, 0, 255, win << 16) == NULL)
+ if (pci_ecam_add(0, 0, 255, win << 16) == NULL)
return NULL;
return "Intel Corporation E7520 Memory Controller Hub";
@@ -128,7 +128,7 @@ static const char *__init pci_mmcfg_intel_945(void)
if ((pciexbar & mask) >= 0xf000U)
return NULL;
- if (pci_mmconfig_add(0, 0, (len >> 20) - 1, pciexbar & mask) == NULL)
+ if (pci_ecam_add(0, 0, (len >> 20) - 1, pciexbar & mask) == NULL)
return NULL;
return "Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub";
@@ -175,13 +175,13 @@ static const char *__init pci_mmcfg_amd_fam10h(void)
end_bus = (1 << busnbits) - 1;
for (i = 0; i < (1 << segnbits); i++)
- if (pci_mmconfig_add(i, 0, end_bus,
+ if (pci_ecam_add(i, 0, end_bus,
base + (1<<28) * i) == NULL) {
- free_all_mmcfg();
+ pci_ecam_free_all();
return NULL;
}
- pci_mmconfig_register_mmio(&pci_mmcfg_mmio_amd_fam10h);
+ pci_ecam_register_mmio(&pci_mmcfg_mmio_amd_fam10h);
return "AMD Family 10h NB";
}
@@ -210,7 +210,7 @@ static const char *__init pci_mmcfg_nvidia_mcp55(void)
/*
* do check if amd fam10h already took over
*/
- if (!acpi_disabled || !list_empty(&pci_mmcfg_list) || mcp55_checked)
+ if (!acpi_disabled || !list_empty(&pci_ecam_list) || mcp55_checked)
return NULL;
mcp55_checked = true;
@@ -239,7 +239,7 @@ static const char *__init pci_mmcfg_nvidia_mcp55(void)
base <<= extcfg_base_lshift;
start = (extcfg & extcfg_start_mask) >> extcfg_start_shift;
end = start + extcfg_sizebus[size_index] - 1;
- if (pci_mmconfig_add(0, start, end, base) == NULL)
+ if (pci_ecam_add(0, start, end, base) == NULL)
continue;
mcp55_mmconf_found++;
}
@@ -273,15 +273,15 @@ static const struct pci_mmcfg_hostbridge_probe
pci_mmcfg_probes[] __initconst =
static void __init pci_mmcfg_check_end_bus_number(void)
{
- struct pci_mmcfg_region *cfg, *cfgx;
+ struct pci_ecam_region *cfg, *cfgx;
/* Fixup overlaps */
- list_for_each_entry(cfg, &pci_mmcfg_list, list) {
+ list_for_each_entry(cfg, &pci_ecam_list, list) {
if (cfg->end_bus < cfg->start_bus)
cfg->end_bus = 255;
/* Don't access the list head ! */
- if (cfg->list.next == &pci_mmcfg_list)
+ if (cfg->list.
[PATCH v3 5/9] pci, acpi, mcfg: Provide generic implementation of MCFG code initialization.
Those two functions are required by ACPI subsystem to make PCI config
space accessible. Generic code assume to do nothing for early init call but
late init call does as follow:
- parse MCFG table and add regions to ECAM resource list
- map regions
- add regions to iomem_resource
Signed-off-by: Tomasz Nowicki
---
drivers/acpi/mcfg.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index a2e2326..1e646fc 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -79,3 +79,23 @@ int __init acpi_parse_mcfg(struct acpi_table_header *header)
return 0;
}
+
+void __init __weak pci_mmcfg_early_init(void)
+{
+
+}
+
+void __init __weak pci_mmcfg_late_init(void)
+{
+ struct pci_mmcfg_region *cfg;
+
+ acpi_table_parse(ACPI_SIG_MCFG, acpi_parse_mcfg);
+
+ if (list_empty(&pci_mmcfg_list))
+ return;
+ if (!pci_mmcfg_arch_init())
+ free_all_mmcfg();
+
+ list_for_each_entry(cfg, &pci_mmcfg_list, list)
+ insert_resource(&iomem_resource, &cfg->res);
+}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/9] x86, pci: mmconfig_{32,64}.c code refactoring - remove code duplication.
mmconfig_64.c version is going to be default implementation for arch
agnostic low-level direct PCI config space accessors for ECAM dirver.
However, now it initialize raw_pci_ext_ops pointer which is x86 specific
code only. Moreover, mmconfig_32.c is doing the same thing at the same time.
Move it to mmconfig_shared.c so it becomes common for both and
mmconfig_64.c turns out to be purely arch agnostic.
Signed-off-by: Tomasz Nowicki
---
arch/x86/pci/mmconfig-shared.c | 10 --
arch/x86/pci/mmconfig_32.c | 10 ++
arch/x86/pci/mmconfig_64.c | 11 ++-
include/linux/ecam.h | 5 +
4 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 5064302..6dfe614 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -29,6 +29,11 @@
static bool pci_mmcfg_running_state;
static bool pci_mmcfg_arch_init_failed;
+const struct pci_raw_ops pci_mmcfg = {
+ .read = pci_mmcfg_read,
+ .write =pci_mmcfg_write,
+};
+
static u32
pci_mmconfig_amd_read(int len, void __iomem *addr)
{
@@ -532,9 +537,10 @@ static void __init __pci_mmcfg_init(int early)
}
}
- if (pci_mmcfg_arch_init())
+ if (pci_mmcfg_arch_init()) {
+ raw_pci_ext_ops = &pci_mmcfg;
pci_probe = (pci_probe & ~PCI_PROBE_MASK) | PCI_PROBE_MMCONF;
- else {
+ } else {
free_all_mmcfg();
pci_mmcfg_arch_init_failed = true;
}
diff --git a/arch/x86/pci/mmconfig_32.c b/arch/x86/pci/mmconfig_32.c
index 5cf6291..7a050cb 100644
--- a/arch/x86/pci/mmconfig_32.c
+++ b/arch/x86/pci/mmconfig_32.c
@@ -50,7 +50,7 @@ static void pci_exp_set_dev_base(unsigned int base, int bus,
int devfn)
}
}
-static int pci_mmcfg_read(unsigned int seg, unsigned int bus,
+int pci_mmcfg_read(unsigned int seg, unsigned int bus,
unsigned int devfn, int reg, int len, u32 *value)
{
unsigned long flags;
@@ -79,7 +79,7 @@ err: *value = -1;
return 0;
}
-static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
+int pci_mmcfg_write(unsigned int seg, unsigned int bus,
unsigned int devfn, int reg, int len, u32 value)
{
unsigned long flags;
@@ -106,15 +106,9 @@ static int pci_mmcfg_write(unsigned int seg, unsigned int
bus,
return 0;
}
-const struct pci_raw_ops pci_mmcfg = {
- .read = pci_mmcfg_read,
- .write =pci_mmcfg_write,
-};
-
int __init pci_mmcfg_arch_init(void)
{
printk(KERN_INFO "PCI: Using MMCONFIG for extended config space\n");
- raw_pci_ext_ops = &pci_mmcfg;
return 1;
}
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
index b62ff18..fd857ea 100644
--- a/arch/x86/pci/mmconfig_64.c
+++ b/arch/x86/pci/mmconfig_64.c
@@ -25,7 +25,7 @@ static char __iomem *pci_dev_base(unsigned int seg, unsigned
int bus, unsigned i
return NULL;
}
-static int pci_mmcfg_read(unsigned int seg, unsigned int bus,
+int pci_mmcfg_read(unsigned int seg, unsigned int bus,
unsigned int devfn, int reg, int len, u32 *value)
{
char __iomem *addr;
@@ -49,7 +49,7 @@ err: *value = -1;
return 0;
}
-static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
+int pci_mmcfg_write(unsigned int seg, unsigned int bus,
unsigned int devfn, int reg, int len, u32 value)
{
char __iomem *addr;
@@ -71,11 +71,6 @@ static int pci_mmcfg_write(unsigned int seg, unsigned int
bus,
return 0;
}
-const struct pci_raw_ops pci_mmcfg = {
- .read = pci_mmcfg_read,
- .write =pci_mmcfg_write,
-};
-
static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
{
void __iomem *addr;
@@ -101,8 +96,6 @@ int __init pci_mmcfg_arch_init(void)
return 0;
}
- raw_pci_ext_ops = &pci_mmcfg;
-
return 1;
}
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
index 2387df5..fba5d6b 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -47,5 +47,10 @@ extern struct list_head pci_mmcfg_list;
#define PCI_MMCFG_BUS_OFFSET(bus) ((bus) << 20)
+int pci_mmcfg_read(unsigned int seg, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 *value);
+int pci_mmcfg_write(unsigned int seg, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 value);
+
#endif /* __KERNEL__ */
#endif /* __ECAM_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/9] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory
ECAM standard and MCFG table are architecture independent and it makes
sense to share common code across all architectures. Both are going to
corresponding files - ecam.c and mcfg.c
While we are here, rename pci_parse_mcfg to acpi_parse_mcfg.
We already have acpi_parse_mcfg prototype which is used nowhere.
At the same time, we need pci_parse_mcfg been global so acpi_parse_mcfg
can be used perfectly here.
Signed-off-by: Tomasz Nowicki
---
arch/x86/Kconfig | 2 +
arch/x86/include/asm/pci_x86.h | 33 -
arch/x86/pci/acpi.c| 1 +
arch/x86/pci/mmconfig-shared.c | 296 +
arch/x86/pci/mmconfig_32.c | 1 +
arch/x86/pci/mmconfig_64.c | 1 +
arch/x86/pci/numachip.c| 1 +
drivers/acpi/Makefile | 1 +
drivers/acpi/mcfg.c| 81 +++
drivers/pci/Kconfig| 4 +
drivers/pci/Makefile | 5 +
drivers/pci/ecam.c | 243 +
include/linux/ecam.h | 51 +++
13 files changed, 394 insertions(+), 326 deletions(-)
create mode 100644 drivers/acpi/mcfg.c
create mode 100644 drivers/pci/ecam.c
create mode 100644 include/linux/ecam.h
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c2fb8a8..dd926f4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2276,6 +2276,7 @@ config PCI_DIRECT
config PCI_MMCONFIG
def_bool y
+ select PCI_ECAM
depends on X86_32 && PCI && (ACPI || SFI) && (PCI_GOMMCONFIG ||
PCI_GOANY)
config PCI_OLPC
@@ -2293,6 +2294,7 @@ config PCI_DOMAINS
config PCI_MMCONFIG
bool "Support mmconfig PCI config space access"
+ select PCI_ECAM
depends on X86_64 && PCI && ACPI
config PCI_CNB20LE_QUIRK
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index c57c225..e8a237f 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -122,41 +122,8 @@ extern int pci_legacy_init(void);
extern void pcibios_fixup_irqs(void);
/* pci-mmconfig.c */
-
-/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
-#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
-
-struct pci_mmcfg_region {
- struct list_head list;
- struct resource res;
- u64 address;
- char __iomem *virt;
- u16 segment;
- u8 start_bus;
- u8 end_bus;
- char name[PCI_MMCFG_RESOURCE_NAME_LEN];
-};
-
-struct pci_mmcfg_mmio_ops {
- u32 (*read)(int len, void __iomem *addr);
- void (*write)(int len, void __iomem *addr, u32 value);
-};
-
-extern int __init pci_mmcfg_arch_init(void);
-extern void __init pci_mmcfg_arch_free(void);
-extern int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
-extern void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
phys_addr_t addr);
-extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
-extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
-extern u32 pci_mmio_read(int len, void __iomem *addr);
-extern void pci_mmio_write(int len, void __iomem *addr, u32 value);
-extern void pci_mmconfig_register_mmio(struct pci_mmcfg_mmio_ops *ops);
-
-extern struct list_head pci_mmcfg_list;
-
-#define PCI_MMCFG_BUS_OFFSET(bus) ((bus) << 20)
/*
* AMD Fam10h CPUs are buggy, and cannot access MMIO config space
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 6ac2738..5dfccef 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 685cd4c..5064302 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -27,52 +28,6 @@
/* Indicate if the mmcfg resources have been placed into the resource table. */
static bool pci_mmcfg_running_state;
static bool pci_mmcfg_arch_init_failed;
-static DEFINE_MUTEX(pci_mmcfg_lock);
-
-LIST_HEAD(pci_mmcfg_list);
-
-static u32
-pci_mmconfig_generic_read(int len, void __iomem *addr)
-{
- u32 data = 0;
-
- switch (len) {
- case 1:
- data = readb(addr);
- break;
- case 2:
- data = readw(addr);
- break;
- case 4:
- data = readl(addr);
- break;
- }
-
- return data;
-}
-
-static void
-pci_mmconfig_generic_write(int len, void __iomem *addr, u32 value)
-{
- switch (len) {
- case 1:
- writeb(value, addr);
- break;
- case 2:
- writew(value, addr);
- break;
- case 4:
- writel(value, addr);
- break;
- }
-}
-
-static struct pci_mmcfg_mmio_ops pci_mmcfg_mmio_default = {
- .read = pci_mmcon
Re: [PATCH v9 05/21] ARM64 / ACPI: Get RSDP and ACPI boot-time tables
On 2015年03月10日 19:19, Leif Lindholm wrote:
On Tue, Mar 10, 2015 at 04:01:16PM +0800, Hanjun Guo wrote:
index 000..f052e7a
--- /dev/null
+++ b/arch/arm64/kernel/acpi.c
@@ -0,0 +1,101 @@
+/*
+ * ARM64 Specific Low-Level ACPI Boot Support
+ *
+ * Copyright (C) 2013-2014, Linaro Ltd.
+ * Author: Al Stone
+ * Author: Graeme Gregory
+ * Author: Hanjun Guo
+ * Author: Tomasz Nowicki
+ * Author: Naresh Bhat
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) "ACPI: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+int acpi_noirq;/* skip ACPI IRQ initialization */
+int acpi_disabled;
+EXPORT_SYMBOL(acpi_disabled);
+
+int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
+EXPORT_SYMBOL(acpi_pci_disabled);
+
+/*
+ * __acpi_map_table() will be called before page_init(), so early_ioremap()
+ * or early_memremap() should be called here to for ACPI table mapping.
+ */
+char *__init __acpi_map_table(unsigned long phys, unsigned long size)
+{
+ if (!phys || !size)
Is there a reason to rule out physical address 0x0 ?
No particular reasons, unless some arch/firmware limits, I'm
not sure if we need this check (x86 needs it), I'm CC Leif
to confirm.
Nothing in UEFI explicitly bans using physical address 0 for anything,
and nothing in the architecture reserves it. So I don't think this
check is necessary.
Thanks for the confirmation, will remove the !phys check.
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/9] x86, pci: Clean up comment about buggy MMIO config space access for AMD Fam10h CPUs.
- fix typo
- improve explanation
- add reference to the related document
Signed-off-by: Tomasz Nowicki
---
arch/x86/include/asm/pci_x86.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index fa1195d..d024f4d 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -152,10 +152,13 @@ extern struct list_head pci_mmcfg_list;
/*
* AMD Fam10h CPUs are buggy, and cannot access MMIO config space
- * on their northbrige except through the * %eax register. As such, you MUST
- * NOT use normal IOMEM accesses, you need to only use the magic mmio-config
+ * on their northbridge except through the * %eax register. As such, you MUST
+ * NOT use normal IOMEM accesses, you need to only use the magic mmio_config_*
* accessor functions.
- * In fact just use pci_config_*, nothing else please.
+ *
+ * Please refer to the following doc:
+ * "BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h Processors",
+ * rev. 3.48, sec 2.11.1, "MMIO Configuration Coding Requirements".
*/
static inline unsigned char mmio_config_readb(void __iomem *pos)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] x86: move cacheinfo sysfs to generic cacheinfo infrastructure
Hi, I just triggered this is on rc3 + tip/master which has your patch. This is an Intel SNB. Ideas, already fixed? Thanks. [ cut here ] WARNING: CPU: 3 PID: 1 at fs/sysfs/group.c:102 internal_create_group+0x151/0x280() sysfs: (bin_)attrs not set by subsystem for group: index3/ Modules linked in: CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc3+ #1 Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A13 05/11/2014 81cc6539 88043be73bd8 8184065b 88043be73c28 88043be73c18 8107301a 81eff038 0001 81efef60 81e1c080 Call Trace: [] dump_stack+0x4f/0x7b [] warn_slowpath_common+0x8a/0xc0 [] warn_slowpath_fmt+0x46/0x50 [] internal_create_group+0x151/0x280 [] sysfs_create_groups+0x49/0xa0 [] device_add+0x3e3/0x680 [] cpu_device_create+0xc0/0xe0 [] ? __kmalloc+0x20a/0x220 [] cache_add_dev+0x176/0x220 [] cacheinfo_sysfs_init+0x51/0x93 [] ? container_dev_init+0x2f/0x2f [] do_one_initcall+0xa0/0x200 [] kernel_init_freeable+0x1f5/0x27d [] ? rest_init+0xd0/0xd0 [] kernel_init+0xe/0xf0 [] ret_from_fork+0x53/0x80 [] ? rest_init+0xd0/0xd0 ---[ end trace 5505c77da0d6932a ]--- error populating cacheinfo..cpu0 -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sound/firewire: Fix trivial typos in comments
At Mon, 9 Mar 2015 22:13:03 +0100, Yannick Guerrini wrote: > > Change 'propper' to 'proper' > Change 'paramters' to 'parameters' > Change 'SYT_INTEVAL' to 'SYT_INTERVAL' > Change 'aligh'/'alighed' to 'align'/'aligned' > > Signed-off-by: Yannick Guerrini Applied, thanks. Takashi > --- > sound/firewire/amdtp.c | 8 > sound/firewire/fireworks/fireworks_transaction.c | 2 +- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/sound/firewire/amdtp.c b/sound/firewire/amdtp.c > index 5cc356d..e061355 100644 > --- a/sound/firewire/amdtp.c > +++ b/sound/firewire/amdtp.c > @@ -166,10 +166,10 @@ int amdtp_stream_add_pcm_hw_constraints(struct > amdtp_stream *s, >* One AMDTP packet can include some frames. In blocking mode, the >* number equals to SYT_INTERVAL. So the number is 8, 16 or 32, >* depending on its sampling rate. For accurate period interrupt, it's > - * preferrable to aligh period/buffer sizes to current SYT_INTERVAL. > + * preferrable to align period/buffer sizes to current SYT_INTERVAL. >* > - * TODO: These constraints can be improved with propper rules. > - * Currently apply LCM of SYT_INTEVALs. > + * TODO: These constraints can be improved with proper rules. > + * Currently apply LCM of SYT_INTERVALs. >*/ > err = snd_pcm_hw_constraint_step(runtime, 0, >SNDRV_PCM_HW_PARAM_PERIOD_SIZE, 32); > @@ -270,7 +270,7 @@ static void amdtp_read_s32(struct amdtp_stream *s, > * @s: the AMDTP stream to configure > * @format: the format of the ALSA PCM device > * > - * The sample format must be set after the other paramters (rate/PCM > channels/ > + * The sample format must be set after the other parameters (rate/PCM > channels/ > * MIDI) and before the stream is started, and must not be changed while the > * stream is running. > */ > diff --git a/sound/firewire/fireworks/fireworks_transaction.c > b/sound/firewire/fireworks/fireworks_transaction.c > index 2a85e42..f550808 100644 > --- a/sound/firewire/fireworks/fireworks_transaction.c > +++ b/sound/firewire/fireworks/fireworks_transaction.c > @@ -13,7 +13,7 @@ > * > * Transaction substance: > * At first, 6 data exist. Following to the data, parameters for each > command > - * exist. All of the parameters are 32 bit alighed to big endian. > + * exist. All of the parameters are 32 bit aligned to big endian. > * data[0]:Length of transaction substance > * data[1]:Transaction version > * data[2]:Sequence number. This is incremented by the device > -- > 1.9.5.msysgit.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: sm750fb: Cleanup the type of mmio750
On Tue, Mar 10, 2015 at 09:57:06AM +, Lorenzo Stoakes wrote: > This patch assigns the more appropriate void* type to the mmio750 variable > eliminating an unnecessary volatile qualifier in the process. Additionally it > updates parameter types as necessary where those parameters interact with > mmio750 and removes unnecessary casts. > > As a consequence, this patch fixes the following sparse warning:- > > drivers/staging/sm750fb/ddk750_help.c:12:17: warning: incorrect type in > assignment (different address spaces) > > Signed-off-by: Lorenzo Stoakes Looks good. Thanks for doing this. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SCSI:STORVSC Use SCSI layer to allocate memory for per-command device request data
On Mon, Dec 29, Christoph Hellwig wrote:
> +++ b/drivers/scsi/storvsc_drv.c
> static struct scsi_host_template scsi_driver = {
> .module = THIS_MODULE,
> .name = "storvsc_host_t",
> + .cmd_size = sizeof(struct storvsc_cmd_request),
> .bios_param = storvsc_get_chs,
> .queuecommand = storvsc_queuecommand,
> .eh_host_reset_handler =storvsc_host_reset_handler,
> + .proc_name ="storvsc_host",
It would be nice to change .proc_name to KBUILD_MODNAME before v4.0 is
released. We carry a patch which adds this field. Of cource we can just
change the patch, but if code gets touched upstream anyway...
Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x278/0x2a0()
On 2015.03.07 at 09:35 +, Filipe David Manana wrote: > On Tue, Mar 3, 2015 at 2:13 PM, Markus Trippelsdorf > wrote: > > On 2015.03.02 at 14:29 +0100, Markus Trippelsdorf wrote: > >> On 2015.03.02 at 12:07 +, Filipe David Manana wrote: > >> > >> [83159.038708] [ cut here ] > >> > >> [83159.038716] WARNING: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8693 > >> > >> btrfs_destroy_inode+0x278/0x2a0() > >> > >> [83159.038718] CPU: 2 PID: 32343 Comm: rm Tainted: GW > >> > >> 4.0.0-rc1-dirty #104 > >> > >> [83159.038719] Hardware name: System manufacturer System Product > >> > >> Name/M4A78T-E, BIOS 350304/13/2011 > >> > >> [83159.038720] 810f 8168d723 > >> > >> > >> > >> [83159.038722] 8106d2d2 88005756edf0 > >> > >> 880215805800 > >> > >> [83159.038723] 880169477eb8 88005756edf0 8121bab8 > >> > >> 880100675000 > >> > >> [83159.038725] Call Trace: > >> > >> [83159.038728] [] ? dump_stack+0x40/0x50 > >> > >> [83159.038731] [] ? warn_slowpath_common+0x72/0xc0 > >> > >> [83159.038732] [] ? btrfs_destroy_inode+0x278/0x2a0 > >> > >> [83159.038735] [] ? do_unlinkat+0x1a7/0x2e0 > >> > >> [83159.038737] [] ? task_work_run+0xb4/0x100 > >> > >> [83159.038740] [] ? do_notify_resume+0x69/0x80 > >> > >> [83159.038742] [] ? system_call_fastpath+0x12/0x17 > >> > >> [83159.038743] ---[ end trace 3b7c45c6e46fe8dd ]--- > >> > >> [83159.038744] [ cut here ] > >> > >> [83159.038745] WARNING: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8694 > >> > >> btrfs_destroy_inode+0x1f2/0x2a0() > >> > >> [83159.038746] CPU: 2 PID: 32343 Comm: rm Tainted: GW > >> > >> 4.0.0-rc1-dirty #104 > >> > >> [83159.038747] Hardware name: System manufacturer System Product > >> > >> Name/M4A78T-E, BIOS 350304/13/2011 > >> > >> [83159.038747] 810f 8168d723 > >> > >> > >> > >> [83159.038749] 8106d2d2 88005756edf0 > >> > >> 880215805800 > >> > >> [83159.038750] 880169477eb8 88005756edf0 8121ba32 > >> > >> 880100675000 > >> > >> [83159.038751] Call Trace: > >> > >> [83159.038753] [] ? dump_stack+0x40/0x50 > >> > >> [83159.038754] [] ? warn_slowpath_common+0x72/0xc0 > >> > >> [83159.038755] [] ? btrfs_destroy_inode+0x1f2/0x2a0 > >> > >> [83159.038757] [] ? do_unlinkat+0x1a7/0x2e0 > >> > >> [83159.038758] [] ? task_work_run+0xb4/0x100 > >> > >> [83159.038760] [] ? do_notify_resume+0x69/0x80 > >> > >> [83159.038761] [] ? system_call_fastpath+0x12/0x17 > >> > >> [83159.038762] ---[ end trace 3b7c45c6e46fe8de ]--- > >> > > > >> > > Unfortunately the issue isn't 100% reproducible, so I unfortunately > >> > > cannot bisect. > >> > > >> > You probably don't need to bisect. The warning is related to the > >> > outstanding_extents counter being != 0: > >> > > >> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/inode.c?id=refs/tags/v4.0-rc1#n8693 > >> > > >> > The only change in 4.0 that changes updates to that counter is: > >> > > >> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3e05bde8c3c2dd761da4d52944a087907955a53c > >> > > >> > So that's likely the change you would find with a bisect. > >> > >> OK, thank you. I will revert the commit and see if it fixes the issue. > > > > No. Reverting 3e05bde8c3 does _not_ fix the issue. It still happens. > > Ok, so I ran into this as well, and identified the following patch as > the source of the problem: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dcab6a3b2ae657a2017637083c28ee303b6b1b8e > > It's actually very easy to trigger. The following fio job config triggers it: > > [global] > ioengine=sync > direct=0 > bssplit=130M/100 > fallocate=none > filename=foobar > > [job1] > numjobs=1 > size=1G > rw=randwrite > > Then run these steps: > > mkfs.btrfs -f /dev/sdd > mount /dev/sdd /mnt > cd /mnt > fio fio_job.ini > cd .. > umount /mnt > (see dmesg) > > The important part is that the writes need to be larger than 128Mb. > With btrfs assertions enabled (CONFIG_BTRFS_ASSERT=y) you'll get a > BUG_ON() immediately: > > [211158.63] BTRFS: assertion failed: > BTRFS_I(inode)->outstanding_extents >= num_extents, file: > fs/btrfs/extent-tree.c, line: 4983 > [211158.557901] [ cut here ] > [211158.558666] kernel BUG at fs/btrfs/ctree.h:4013! > [211158.559660] invalid opcode: [#1] SMP DEBUG_PAGEALLOC > () > [211158.561837] Call Trace: > [211158.561837] [] drop_outstanding_extent+0x3d/0x6d > [btrfs] > [211158.561837] [] > btrfs_delalloc_release_metadata+0x53/0xfc [btrfs] > () > > Otherwise only the warnings you reported during inode eviction. > > This happens for both direct IO and buffered writes (direct=0). At > least for the direct IO case, the issue happens due to underflo
[PATCH v5 0/3] Add ioctl and debug utilities to UFS driver
Changes from V4: Dropped error injection change titled: scsi: ufs: inject errors to verify error handling Dolev Raviv (1): scsi: ufs: add ioctl interface for query request Gilad Broner (1): scsi: ufs: add trace events and dump prints for debug Lee Susman (1): scsi: ufs: add debugfs for ufs drivers/scsi/ufs/Makefile | 1 + drivers/scsi/ufs/ufs-debugfs.c | 902 ++ drivers/scsi/ufs/ufs-debugfs.h | 38 ++ drivers/scsi/ufs/ufs-qcom.c| 53 +++ drivers/scsi/ufs/ufs.h | 53 +-- drivers/scsi/ufs/ufshcd.c | 963 +++-- drivers/scsi/ufs/ufshcd.h | 110 + drivers/scsi/ufs/ufshci.h | 3 + include/trace/events/ufs.h | 227 ++ include/uapi/scsi/Kbuild | 1 + include/uapi/scsi/ufs/Kbuild | 3 + include/uapi/scsi/ufs/ioctl.h | 57 +++ include/uapi/scsi/ufs/ufs.h| 66 +++ 13 files changed, 2387 insertions(+), 90 deletions(-) create mode 100644 drivers/scsi/ufs/ufs-debugfs.c create mode 100644 drivers/scsi/ufs/ufs-debugfs.h create mode 100644 include/trace/events/ufs.h create mode 100644 include/uapi/scsi/ufs/Kbuild create mode 100644 include/uapi/scsi/ufs/ioctl.h create mode 100644 include/uapi/scsi/ufs/ufs.h -- Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/3] scsi: ufs: add debugfs for ufs
From: Lee Susman
Adding debugfs capability for ufshcd.
debugfs attributes introduced in this patch:
- View driver/controller runtime data
- Command tag statistics for performance analisis
- Dump device descriptor info
- Track recoverable errors statistics during runtime
- Change UFS power mode during runtime
entry a string in the format 'GGLLMM' where:
G - selected gear
L - number of lanes
M - power mode
(1=fast mode, 2=slow mode, 4=fast-auto mode,
5=slow-auto mode)
First letter is for RX, second is for TX.
- Get/set DME attributes
Signed-off-by: Lee Susman
Signed-off-by: Dolev Raviv
Signed-off-by: Yaniv Gardi
Signed-off-by: Raviv Shvili
Signed-off-by: Gilad Broner
---
drivers/scsi/ufs/Makefile | 1 +
drivers/scsi/ufs/ufs-debugfs.c | 902 +
drivers/scsi/ufs/ufs-debugfs.h | 38 ++
drivers/scsi/ufs/ufshcd.c | 229 ++-
drivers/scsi/ufs/ufshcd.h | 65 +++
drivers/scsi/ufs/ufshci.h | 2 +
6 files changed, 1225 insertions(+), 12 deletions(-)
create mode 100644 drivers/scsi/ufs/ufs-debugfs.c
create mode 100644 drivers/scsi/ufs/ufs-debugfs.h
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 8303bcc..0692314 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
+obj-$(CONFIG_DEBUG_FS) += ufs-debugfs.o
diff --git a/drivers/scsi/ufs/ufs-debugfs.c b/drivers/scsi/ufs/ufs-debugfs.c
new file mode 100644
index 000..27ab053
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-debugfs.c
@@ -0,0 +1,902 @@
+/* Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * UFS debugfs - add debugfs interface to the ufshcd.
+ * This is currently used for statistics collection and exporting from the
+ * UFS driver.
+ * This infrastructure can be used for debugging or direct tweaking
+ * of the driver from userspace.
+ *
+ */
+
+#include "ufs-debugfs.h"
+#include "unipro.h"
+
+enum field_width {
+ BYTE= 1,
+ WORD= 2,
+};
+
+struct desc_field_offset {
+ char *name;
+ int offset;
+ enum field_width width_byte;
+};
+
+#define UFS_ERR_STATS_PRINT(file, error_index, string, error_seen) \
+ do {\
+ if (err_stats[error_index]) { \
+ seq_printf(file, string,\
+ err_stats[error_index]);\
+ error_seen = true; \
+ } \
+ } while (0)
+#define DOORBELL_CLR_TOUT_US (1000 * 1000) /* 1 sec */
+
+#define BUFF_LINE_CAPACITY 16
+#define TAB_CHARS 8
+
+static int ufsdbg_tag_stats_show(struct seq_file *file, void *data)
+{
+ struct ufs_hba *hba = (struct ufs_hba *)file->private;
+ struct ufs_stats *ufs_stats;
+ int i, j;
+ int max_depth;
+ bool is_tag_empty = true;
+ unsigned long flags;
+ char *sep = " | * | ";
+
+ if (!hba)
+ goto exit;
+
+ ufs_stats = &hba->ufs_stats;
+
+ if (!ufs_stats->enabled) {
+ pr_debug("%s: ufs statistics are disabled\n", __func__);
+ seq_puts(file, "ufs statistics are disabled");
+ goto exit;
+ }
+
+ max_depth = hba->nutrs;
+
+ spin_lock_irqsave(hba->host->host_lock, flags);
+ /* Header */
+ seq_printf(file, " Tag Stat\t\t%s Queue Fullness\n", sep);
+ for (i = 0; i < TAB_CHARS * (TS_NUM_STATS + 4); i++) {
+ seq_puts(file, "-");
+ if (i == (TAB_CHARS * 3 - 1))
+ seq_puts(file, sep);
+ }
+ seq_printf(file,
+ "\n #\tnum uses\t%s\t #\tAll\t Read\t Write\t Flush\n",
+ sep);
+
+ /* values */
+ for (i = 0; i < max_depth; i++) {
+ if (ufs_stats->tag_stats[i][0] <= 0 &&
+ ufs_stats->tag_stats[i][1] <= 0 &&
+ ufs_stats->tag_stats[i][2] <= 0 &&
+ ufs_stats->tag_stats[i][3] <= 0)
+ continue;
+
+ is_tag_empty = false;
+ seq_p
[PATCH v5 1/3] scsi: ufs: add ioctl interface for query request
From: Dolev Raviv
This patch exposes the ioctl interface for UFS driver via SCSI device
ioctl interface. As of now UFS driver would provide the ioctl for query
interface to connected UFS device.
Signed-off-by: Dolev Raviv
Signed-off-by: Noa Rubens
Signed-off-by: Raviv Shvili
Signed-off-by: Yaniv Gardi
---
drivers/scsi/ufs/ufs.h| 53 +++---
drivers/scsi/ufs/ufshcd.c | 225 +-
include/uapi/scsi/Kbuild | 1 +
include/uapi/scsi/ufs/Kbuild | 3 +
include/uapi/scsi/ufs/ioctl.h | 57 +++
include/uapi/scsi/ufs/ufs.h | 66 +
6 files changed, 361 insertions(+), 44 deletions(-)
create mode 100644 include/uapi/scsi/ufs/Kbuild
create mode 100644 include/uapi/scsi/ufs/ioctl.h
create mode 100644 include/uapi/scsi/ufs/ufs.h
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 42c459a..1f023c4 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -38,6 +38,7 @@
#include
#include
+#include
#define MAX_CDB_SIZE 16
#define GENERAL_UPIU_REQUEST_SIZE 32
@@ -71,6 +72,16 @@ enum {
UFS_UPIU_RPMB_WLUN = 0xC4,
};
+/**
+ * ufs_is_valid_unit_desc_lun - checks if the given LUN has a unit descriptor
+ * @lun: LU number to check
+ * @return: true if the lun has a matching unit descriptor, false otherwise
+ */
+static inline bool ufs_is_valid_unit_desc_lun(u8 lun)
+{
+ return (lun == UFS_UPIU_RPMB_WLUN || (lun < UFS_UPIU_MAX_GENERAL_LUN));
+}
+
/*
* UFS Protocol Information Unit related definitions
*/
@@ -126,35 +137,6 @@ enum {
UPIU_QUERY_FUNC_STANDARD_WRITE_REQUEST = 0x81,
};
-/* Flag idn for Query Requests*/
-enum flag_idn {
- QUERY_FLAG_IDN_FDEVICEINIT = 0x01,
- QUERY_FLAG_IDN_PWR_ON_WPE = 0x03,
- QUERY_FLAG_IDN_BKOPS_EN = 0x04,
-};
-
-/* Attribute idn for Query requests */
-enum attr_idn {
- QUERY_ATTR_IDN_ACTIVE_ICC_LVL = 0x03,
- QUERY_ATTR_IDN_BKOPS_STATUS = 0x05,
- QUERY_ATTR_IDN_EE_CONTROL = 0x0D,
- QUERY_ATTR_IDN_EE_STATUS= 0x0E,
-};
-
-/* Descriptor idn for Query requests */
-enum desc_idn {
- QUERY_DESC_IDN_DEVICE = 0x0,
- QUERY_DESC_IDN_CONFIGURAION = 0x1,
- QUERY_DESC_IDN_UNIT = 0x2,
- QUERY_DESC_IDN_RFU_0= 0x3,
- QUERY_DESC_IDN_INTERCONNECT = 0x4,
- QUERY_DESC_IDN_STRING = 0x5,
- QUERY_DESC_IDN_RFU_1= 0x6,
- QUERY_DESC_IDN_GEOMETRY = 0x7,
- QUERY_DESC_IDN_POWER= 0x8,
- QUERY_DESC_IDN_MAX,
-};
-
enum desc_header_offset {
QUERY_DESC_LENGTH_OFFSET= 0x00,
QUERY_DESC_DESC_TYPE_OFFSET = 0x01,
@@ -247,19 +229,6 @@ enum bkops_status {
BKOPS_STATUS_MAX = BKOPS_STATUS_CRITICAL,
};
-/* UTP QUERY Transaction Specific Fields OpCode */
-enum query_opcode {
- UPIU_QUERY_OPCODE_NOP = 0x0,
- UPIU_QUERY_OPCODE_READ_DESC = 0x1,
- UPIU_QUERY_OPCODE_WRITE_DESC= 0x2,
- UPIU_QUERY_OPCODE_READ_ATTR = 0x3,
- UPIU_QUERY_OPCODE_WRITE_ATTR= 0x4,
- UPIU_QUERY_OPCODE_READ_FLAG = 0x5,
- UPIU_QUERY_OPCODE_SET_FLAG = 0x6,
- UPIU_QUERY_OPCODE_CLEAR_FLAG= 0x7,
- UPIU_QUERY_OPCODE_TOGGLE_FLAG = 0x8,
-};
-
/* Query response result code */
enum {
QUERY_RESULT_SUCCESS= 0x00,
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 5d60a86..cb357f8 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3,7 +3,7 @@
*
* This code is based on drivers/scsi/ufs/ufshcd.c
* Copyright (C) 2011-2013 Samsung India Software Operations
- * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
*
* Authors:
* Santosh Yaraganavi
@@ -39,6 +39,7 @@
#include
#include
+#include
#include "ufshcd.h"
#include "unipro.h"
@@ -74,6 +75,9 @@
/* Interrupt aggregation default timeout, unit: 40us */
#define INT_AGGR_DEF_TO0x02
+/* IOCTL opcode for command - ufs set device read only */
+#define UFS_IOCTL_BLKROSET BLKROSET
+
#define ufshcd_toggle_vreg(_dev, _vreg, _on) \
({ \
int _ret; \
@@ -1882,7 +1886,7 @@ static inline int ufshcd_read_unit_desc_param(struct
ufs_hba *hba,
* Unit descriptors are only available for general purpose LUs (LUN id
* from 0 to 7) and RPMB Well known LU.
*/
- if (lun != UFS_UPIU_RPMB_WLUN && (lun >= UFS_UPIU_MAX_GENERAL_LUN))
+ if (!ufs_is_valid_unit_desc_lun(lun))
return -EOPNOTSUPP;
return ufshcd_read_desc_param(hba, QUERY_DESC_IDN_UNIT, lun,
@@ -4201,6 +4205,222 @@ static void ufshcd_as
[PATCH v5 3/3] scsi: ufs: add trace events and dump prints for debug
Add trace events to driver to allow monitoring and profilig
of activities such as PM suspend/resume, hibernate enter/exit,
clock gating and clock scaling up/down.
In addition, add UFS host controller register dumps to provide
detailed information in case of errors to assist in analysis
of issues.
Signed-off-by: Dolev Raviv
Signed-off-by: Subhash Jadavani
Signed-off-by: Lee Susman
Signed-off-by: Sujit Reddy Thumma
Signed-off-by: Yaniv Gardi
---
drivers/scsi/ufs/ufs-qcom.c | 53 +
drivers/scsi/ufs/ufshcd.c | 511 +---
drivers/scsi/ufs/ufshcd.h | 49 -
drivers/scsi/ufs/ufshci.h | 1 +
include/trace/events/ufs.h | 227
5 files changed, 804 insertions(+), 37 deletions(-)
create mode 100644 include/trace/events/ufs.h
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 9217af9..9fe675d 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -30,6 +30,14 @@ static int ufs_qcom_get_bus_vote(struct ufs_qcom_host *host,
const char *speed_mode);
static int ufs_qcom_set_bus_vote(struct ufs_qcom_host *host, int vote);
+static void ufs_qcom_dump_regs(struct ufs_hba *hba, int offset, int len,
+ char *prefix)
+{
+ print_hex_dump(KERN_ERR, prefix,
+ len > 4 ? DUMP_PREFIX_OFFSET : DUMP_PREFIX_NONE,
+ 16, 4, hba->mmio_base + offset, len * 4, false);
+}
+
static int ufs_qcom_get_connected_tx_lanes(struct ufs_hba *hba, u32 *tx_lanes)
{
int err = 0;
@@ -983,6 +991,50 @@ void ufs_qcom_clk_scale_notify(struct ufs_hba *hba)
dev_req_params->hs_rate);
}
+static void ufs_qcom_print_hw_debug_reg_all(struct ufs_hba *hba)
+{
+ u32 reg;
+
+ ufs_qcom_dump_regs(hba, UFS_UFS_DBG_RD_REG_OCSC, 44,
+ "UFS_UFS_DBG_RD_REG_OCSC ");
+
+ reg = ufshcd_readl(hba, REG_UFS_CFG1);
+ reg |= UFS_BIT(17);
+ ufshcd_writel(hba, reg, REG_UFS_CFG1);
+
+ ufs_qcom_dump_regs(hba, UFS_UFS_DBG_RD_EDTL_RAM, 32,
+ "UFS_UFS_DBG_RD_EDTL_RAM ");
+ ufs_qcom_dump_regs(hba, UFS_UFS_DBG_RD_DESC_RAM, 128,
+ "UFS_UFS_DBG_RD_DESC_RAM ");
+ ufs_qcom_dump_regs(hba, UFS_UFS_DBG_RD_PRDT_RAM, 64,
+ "UFS_UFS_DBG_RD_PRDT_RAM ");
+
+ ufshcd_writel(hba, (reg & ~UFS_BIT(17)), REG_UFS_CFG1);
+
+ ufs_qcom_dump_regs(hba, UFS_DBG_RD_REG_UAWM, 4,
+ "UFS_DBG_RD_REG_UAWM ");
+ ufs_qcom_dump_regs(hba, UFS_DBG_RD_REG_UARM, 4,
+ "UFS_DBG_RD_REG_UARM ");
+ ufs_qcom_dump_regs(hba, UFS_DBG_RD_REG_TXUC, 48,
+ "UFS_DBG_RD_REG_TXUC ");
+ ufs_qcom_dump_regs(hba, UFS_DBG_RD_REG_RXUC, 27,
+ "UFS_DBG_RD_REG_RXUC ");
+ ufs_qcom_dump_regs(hba, UFS_DBG_RD_REG_DFC, 19,
+ "UFS_DBG_RD_REG_DFC ");
+ ufs_qcom_dump_regs(hba, UFS_DBG_RD_REG_TRLUT, 34,
+ "UFS_DBG_RD_REG_TRLUT ");
+ ufs_qcom_dump_regs(hba, UFS_DBG_RD_REG_TMRLUT, 9,
+ "UFS_DBG_RD_REG_TMRLUT ");
+}
+
+static void ufs_qcom_dump_dbg_regs(struct ufs_hba *hba)
+{
+ ufs_qcom_dump_regs(hba, REG_UFS_SYS1CLK_1US, 5,
+ "REG_UFS_SYS1CLK_1US ");
+
+ ufs_qcom_print_hw_debug_reg_all(hba);
+}
+
/**
* struct ufs_hba_qcom_vops - UFS QCOM specific variant operations
*
@@ -1000,5 +1052,6 @@ static const struct ufs_hba_variant_ops ufs_hba_qcom_vops
= {
.pwr_change_notify = ufs_qcom_pwr_change_notify,
.suspend= ufs_qcom_suspend,
.resume = ufs_qcom_resume,
+ .dbg_register_dump = ufs_qcom_dump_dbg_regs,
};
EXPORT_SYMBOL(ufs_hba_qcom_vops);
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 7697cc6..3ae0b3f 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -45,6 +45,9 @@
#include "unipro.h"
#include "ufs-debugfs.h"
+#define CREATE_TRACE_POINTS
+#include
+
#ifdef CONFIG_DEBUG_FS
static void ufshcd_update_error_stats(struct ufs_hba *hba, int type)
@@ -145,6 +148,8 @@ static inline ufshcd_update_error_stats(struct ufs_hba
*hba, int type)
_ret = ufshcd_disable_vreg(_dev, _vreg);\
_ret; \
})
+#define ufshcd_hex_dump(prefix_str, buf, len) \
+print_hex_dump(KERN_ERR, prefix_str, DUMP_PREFIX_OFFSET, 16, 4, buf, len,
false)
static u32 ufs_query_desc_max_size[] = {
QUERY_DESC_DEVICE_MAX_SIZE,
@@ -272,6 +277,151 @@ static inline void ufshcd_disable_irq(struct ufs_hba *hba)
}
}
+#ifdef CONFIG_TRACEPOINTS
+static void ufshcd_add_command_trace(struct ufs_hba *hba,
+ unsigned int tag, const char *str)
+{
+ sector_t lba = -1;
+ u8 opcode = 0;
+ u32 intr, doorbell;
+ struc
4.0-rc2+: PATA CF card not detected in PCMCIA slot
Hi! > It seems that pcmcia was unhappy even before, but eject definitely > oopsed it. Aha, I was confused; the oops is with 3.18, not with 4.0. For 4.0, pcmcia does not work at all: [ 617.062718] pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0 [ 622.840108] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0 pavel@duo:~$ zcat /proc/config.gz | grep PATA_PCMCIA CONFIG_PATA_PCMCIA=y Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] x86: move cacheinfo sysfs to generic cacheinfo infrastructure
Hi Boris, On 10/03/15 11:37, Borislav Petkov wrote: Hi, I just triggered this is on rc3 + tip/master which has your patch. This is an Intel SNB. Ideas, already fixed? No, not seen this before. I will test tip/master on my Intel i7 box again and get back to you. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] driver core: Make probe deferral more quiet
Currently probe deferral prints a message every time a device requests
deferral at info severity (which is displayed by default). This can have
an impact on system boot times with serial consoles and is generally quite
noisy.
Since subsystems and drivers should already be logging the specific reason
for probe deferral in order to aid users in understanding problems the
messages from the driver core should be redundant lower the severity of
the messages printed, cutting down on the volume of output on the console.
This does mean that if the drivers and subsystems aren't doing a good job
we get no output on the console by default. Ideally we'd be able to arrange
to print if nothing else printed, though that's a little fun. Even better
would be to come up with a mechanism that explicitly does dependencies so
we don't have to keep polling and erroring.
Signed-off-by: Mark Brown
---
drivers/base/dd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index cdc779cf79a3..a3abe628aa8d 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -322,7 +322,7 @@ probe_failed:
if (ret == -EPROBE_DEFER) {
/* Driver requested deferred probing */
- dev_info(dev, "Driver %s requests probe deferral\n", drv->name);
+ dev_dbg(dev, "Driver %s requests probe deferral\n", drv->name);
driver_deferred_probe_add(dev);
/* Did a trigger occur while probing? Need to re-trigger if yes
*/
if (local_trigger_count != atomic_read(&deferred_trigger_count))
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 00/12] mfd: axp20x: add AXP221 PMIC support
Hi everyone, This is v5 of the AXP221 series. I've taken over the work from Boris. This version is based on v4.0-rc1, plus "mfd: AXP20x: Add bindings documentation" which was posted a few weeks ago. I've worked on this series for some time, so the changelog might not be completely accurate. The AXP221 is a member of X-Powers' AXP PMIC family. They share the same basic functionality and structure. The series adds system poweroff, power button and regulator support for the AXP221. When Reduced Serial Bus (RSB) support is introduced, the same code can be reused (except for the probe interface) for the AXP223, which has the same core and a different external host interface. The p2wi controller dts patches have no dependency, and can go in Maxime's tree. The regulator bits depend on the mfd patches, which introduce new enums and register definitions. The regulator dts patches should also be merged _after_ the regulator bits, as the original axp20x regulator driver did not check for supported variants. Maybe Lee and Mark can work out a shared branch, or have Lee take all the driver bits? Regards ChenYu Changes since v4: - Rebased onto v4.0-rc1 and axp20x bindings v10 - Dropped regulator set registration patches - Group regmap ranges/tables by AXP variant - Fix AXP221 interrupt numbers to match datasheet - Handle AXP variants when setting DC-DC regulator work mode - Add "switch" type regulator DC1SW, which is a secondary output of DCDC1 with a separate on/off switch. - Add AXP221 to DT bindings Boris BREZILLON (4): ARM: dts: sun6i: add p2wi controller node to dtsi mfd: axp20x: add AXP22x PMIC support regulator: axp20x: prepare support for multiple AXP chip families regulator: axp20x: add support for AXP22X regulators Chen-Yu Tsai (8): ARM: dts: sun6i: hummingbird: Enable P2WI controller mfd: axp20x: update DT bindings with AXP22x compatibles ARM: dts: sun6i: hummingbird: Add AXP221 PMIC device node mfd: axp20x: Add AXP22x regulator information to DT bindings mfd: axp20x: Enable AXP22X regulators ARM: dts: sun6i: hummingbird: Add AXP221 regulator nodes ARM: dts: sun6i: Add pinmux settings for mmc1 to dtsi ARM: dts: sun6i: hummingbird: Enable the onboard WiFi module Documentation/devicetree/bindings/mfd/axp20x.txt | 34 +++- arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 91 - arch/arm/boot/dts/sun6i-a31.dtsi | 29 +++ drivers/mfd/axp20x.c | 100 ++ drivers/regulator/axp20x-regulator.c | 239 ++- include/linux/mfd/axp20x.h | 86 6 files changed, 526 insertions(+), 53 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 04/12] mfd: axp20x: update DT bindings with AXP22x compatibles
Add AXP221 to the list of supported devices. Also replace any mention of AXP20x in the document with a generic "PMIC". Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/mfd/axp20x.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt index 98685f291a72..3914a3f91ff6 100644 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt @@ -1,15 +1,16 @@ -AXP202/AXP209 device tree bindings +AXP family PMIC device tree bindings The axp20x family current members : axp202 (X-Powers) axp209 (X-Powers) +axp221 (X-Powers) Required properties: -- compatible: "x-powers,axp202" or "x-powers,axp209" +- compatible: "x-powers,axp202", "x-powers,axp209", "x-powers,axp221" - reg: The I2C slave address for the AXP chip - interrupt-parent: The parent interrupt controller - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin -- interrupt-controller: axp20x has its own internal IRQs +- interrupt-controller: The PMIC has its own internal IRQs - #interrupt-cells: Should be set to 1 Optional properties: -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 08/12] mfd: axp20x: Add AXP22x regulator information to DT bindings
Add the list of regulators for AXP22x to the DT bindings.
This includes the names and supply names.
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/mfd/axp20x.txt | 27
1 file changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 3914a3f91ff6..0fc2f1f35cef 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -49,6 +49,33 @@ LDO3 : LDO : ldo3in-supply
LDO4 : LDO : ldo24in-supply: shared supply
LDO5 : LDO : ldo5in-supply
+
+AXP221 regulators, type, and corresponding input supply names:
+
+RegulatorTypeSupply Name Notes
+---- -
+DCDC1 : DC-DC buck: vin1-supply
+DCDC2 : DC-DC buck: vin2-supply
+DCDC3 : DC-DC buck: vin3-supply
+DCDC4 : DC-DC buck: vin4-supply
+DCDC5 : DC-DC buck: vin5-supply
+DC1SW : On/Off Switch : dcdc1-supply : DCDC1 secondary output
+DC5LDO : LDO : dcdc5-supply : input from DCDC5
+ALDO1 : LDO : aldoin-supply : shared supply
+ALDO2 : LDO : aldoin-supply : shared supply
+ALDO3 : LDO : aldoin-supply : shared supply
+DLDO1 : LDO : dldoin-supply : shared supply
+DLDO2 : LDO : dldoin-supply : shared supply
+DLDO3 : LDO : dldoin-supply : shared supply
+DLDO4 : LDO : dldoin-supply : shared supply
+ELDO1 : LDO : eldoin-supply : shared supply
+ELDO2 : LDO : eldoin-supply : shared supply
+ELDO3 : LDO : eldoin-supply : shared supply
+LDO_IO0: LDO : ips-supply: GPIO 0
+LDO_IO1: LDO : ips-supply: GPIO 1
+RTC_LDO: LDO : ips-supply: always on
+
+
Example:
axp209: pmic@34 {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] arm/pmu: Reject groups spanning multiple hardware PMUs
On 10/03/15 11:27, Peter Zijlstra wrote: On Mon, Mar 09, 2015 at 12:46:30PM +, Suzuki K. Poulose wrote: From: "Suzuki K. Poulose" Don't allow grouping hardware events from different PMUs (eg. CCI + CPU). Uhm, how does this work? If we have multiple hardware PMUs we'll stop scheduling events after the first failed event schedule. This can leave one of the PMUs severely under utilized. This is done from pmu->event_init(), where we haven't scheduled an event yet. Do you think we need to solve it using a different approach ? What is the best way to handle this situation ? Is it OK to allow different PMUs in the group ? Suzuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 12/12] ARM: dts: sun6i: hummingbird: Add basic support for the WiFi module
The Hummingbird A31 has an AMPAK AP6210 WiFi+Bluetooth module. The
WiFi part is a BCM43362 IC connected to MMC1 in the A31 SoC via SDIO.
The IC also takes a power enable signal via GPIO.
The WiFi module supports out-of-band interrupt signaling via GPIO,
but this is not supported in this patch.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index d13c88c6509a..25a3ef49bb71 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -61,6 +61,11 @@
chosen {
bootargs = "earlyprintk console=ttyS0,115200";
};
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&pio 6 10 GPIO_ACTIVE_LOW>; /* PG10 */
+ };
};
&ehci0 {
@@ -127,6 +132,16 @@
allwinner,pull = ;
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins_a>, <&wifi_reset_pin_hummingbird>;
+ vmmc-supply = <&vcc_wifi>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+};
+
&ohci0 {
status = "okay";
};
@@ -138,6 +153,13 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+ wifi_reset_pin_hummingbird: wifi_reset_pin@0 {
+ allwinner,pins = "PG10";
+ allwinner,function = "gpio_out";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
};
&p2wi {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 02/12] ARM: dts: sun6i: hummingbird: Enable P2WI controller
The Hummingbird A31 has an AXP221 PMIC hooked up to the P2WI controller.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 65ddaf4c72d2..533bedc5dd95 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -140,6 +140,10 @@
};
};
+&p2wi {
+ status = "okay";
+};
+
®_usb1_vbus {
gpio = <&pio 7 24 GPIO_ACTIVE_HIGH>; /* PH24 */
status = "okay";
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 11/12] ARM: dts: sun6i: Add pinmux settings for mmc1 to dtsi
mmc1 is used to connect to the WiFi chip on the Hummingbird A31.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 92abea20b946..39d87a901b46 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -581,6 +581,14 @@
allwinner,pull = ;
};
+ mmc1_pins_a: mmc1@0 {
+ allwinner,pins = "PG0", "PG1", "PG2", "PG3",
+"PG4", "PG5";
+ allwinner,function = "mmc1";
+ allwinner,drive = <2>;
+ allwinner,pull = <0>;
+ };
+
gmac_pins_mii_a: gmac_mii@0 {
allwinner,pins = "PA0", "PA1", "PA2", "PA3",
"PA8", "PA9", "PA11",
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 12/12] ARM: dts: sun6i: hummingbird: Enable the onboard WiFi module
The Hummingbird A31 has an AMPAK AP6210 WiFi+Bluetooth module. The
WiFi part is a BCM43362 IC connected to MMC1 in the A31 SoC via SDIO.
The IC also takes a power enable signal via GPIO. This is supported
with the new power sequencing bindings.
The WiFi module supports out-of-band interrupt signaling via GPIO,
but this is buggy and not enabled yet.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index d13c88c6509a..25a3ef49bb71 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -61,6 +61,11 @@
chosen {
bootargs = "earlyprintk console=ttyS0,115200";
};
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&pio 6 10 GPIO_ACTIVE_LOW>; /* PG10 */
+ };
};
&ehci0 {
@@ -127,6 +132,16 @@
allwinner,pull = ;
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins_a>, <&wifi_reset_pin_hummingbird>;
+ vmmc-supply = <&vcc_wifi>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+};
+
&ohci0 {
status = "okay";
};
@@ -138,6 +153,13 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+ wifi_reset_pin_hummingbird: wifi_reset_pin@0 {
+ allwinner,pins = "PG10";
+ allwinner,function = "gpio_out";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
};
&p2wi {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 09/12] mfd: axp20x: Enable AXP22X regulators
Now that the axp20x-regulators driver supports different variants of the
AXP family, we can enable regulator support for AXP22X without the risk
of incorrectly configuring regulators.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/axp20x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 0ec27d5023df..8d2dbb7eb588 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -370,6 +370,8 @@ static struct mfd_cell axp22x_cells[] = {
.name = "axp20x-pek",
.num_resources = ARRAY_SIZE(axp22x_pek_resources),
.resources = axp22x_pek_resources,
+ }, {
+ .name = "axp20x-regulator",
},
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] video: mxsfb: Make sure axi clock is enabled when accessing registers
On 04/03/15 09:06, Liu Ying wrote:
> The LCDIF engines embedded in i.MX6sl and i.MX6sx SoCs need the axi clock
> as the engine's system clock. The clock should be enabled when accessing
> LCDIF registers, otherwise the kernel would hang up. We should also keep
> the clock being enabled when the engine is being active to scan out frames
The text above is a bit confusing. Maybe just "... also keep the clock
enabled when..."
> from memory. This patch makes sure the axi clock is enabled when accessing
> registers so that the kernel hang up issue can be fixed.
>
> Reported-by: Peter Chen
> Tested-by: Peter Chen
> Cc: # 3.19+
> Signed-off-by: Liu Ying
> ---
> v1->v2:
> * Add 'Tested-by: Peter Chen ' tag.
> * Add 'Cc: # 3.19+' tag.
>
> drivers/video/fbdev/mxsfb.c | 70
> -
> 1 file changed, 56 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
> index f8ac4a4..a8cf3b2 100644
> --- a/drivers/video/fbdev/mxsfb.c
> +++ b/drivers/video/fbdev/mxsfb.c
> @@ -316,6 +316,18 @@ static int mxsfb_check_var(struct fb_var_screeninfo *var,
> return 0;
> }
>
> +static inline void mxsfb_enable_axi_clk(struct mxsfb_info *host)
> +{
> + if (host->clk_axi)
> + clk_prepare_enable(host->clk_axi);
> +}
> +
> +static inline void mxsfb_disable_axi_clk(struct mxsfb_info *host)
> +{
> + if (host->clk_axi)
> + clk_disable_unprepare(host->clk_axi);
> +}
> +
> static void mxsfb_enable_controller(struct fb_info *fb_info)
> {
> struct mxsfb_info *host = to_imxfb_host(fb_info);
> @@ -333,14 +345,13 @@ static void mxsfb_enable_controller(struct fb_info
> *fb_info)
> }
> }
>
> - if (host->clk_axi)
> - clk_prepare_enable(host->clk_axi);
> -
> if (host->clk_disp_axi)
> clk_prepare_enable(host->clk_disp_axi);
> clk_prepare_enable(host->clk);
> clk_set_rate(host->clk, PICOS2KHZ(fb_info->var.pixclock) * 1000U);
>
> + mxsfb_enable_axi_clk(host);
> +
Is there some reason to move the clk enable to a different place here?
> /* if it was disabled, re-enable the mode again */
> writel(CTRL_DOTCLK_MODE, host->base + LCDC_CTRL + REG_SET);
>
> @@ -380,11 +391,11 @@ static void mxsfb_disable_controller(struct fb_info
> *fb_info)
> reg = readl(host->base + LCDC_VDCTRL4);
> writel(reg & ~VDCTRL4_SYNC_SIGNALS_ON, host->base + LCDC_VDCTRL4);
>
> + mxsfb_disable_axi_clk(host);
> +
> clk_disable_unprepare(host->clk);
> if (host->clk_disp_axi)
> clk_disable_unprepare(host->clk_disp_axi);
> - if (host->clk_axi)
> - clk_disable_unprepare(host->clk_axi);
And same here for disable.
> host->enabled = 0;
>
> @@ -421,6 +432,8 @@ static int mxsfb_set_par(struct fb_info *fb_info)
> mxsfb_disable_controller(fb_info);
> }
>
> + mxsfb_enable_axi_clk(host);
> +
> /* clear the FIFOs */
> writel(CTRL1_FIFO_CLEAR, host->base + LCDC_CTRL1 + REG_SET);
>
> @@ -438,6 +451,7 @@ static int mxsfb_set_par(struct fb_info *fb_info)
> ctrl |= CTRL_SET_WORD_LENGTH(3);
> switch (host->ld_intf_width) {
> case STMLCDIF_8BIT:
> + mxsfb_disable_axi_clk(host);
> dev_err(&host->pdev->dev,
> "Unsupported LCD bus width mapping\n");
> return -EINVAL;
> @@ -451,6 +465,7 @@ static int mxsfb_set_par(struct fb_info *fb_info)
> writel(CTRL1_SET_BYTE_PACKAGING(0x7), host->base + LCDC_CTRL1);
> break;
> default:
> + mxsfb_disable_axi_clk(host);
> dev_err(&host->pdev->dev, "Unhandled color depth of %u\n",
> fb_info->var.bits_per_pixel);
> return -EINVAL;
> @@ -504,6 +519,8 @@ static int mxsfb_set_par(struct fb_info *fb_info)
> fb_info->fix.line_length * fb_info->var.yoffset,
> host->base + host->devdata->next_buf);
>
> + mxsfb_disable_axi_clk(host);
> +
> if (reenable)
> mxsfb_enable_controller(fb_info);
>
> @@ -582,10 +599,16 @@ static int mxsfb_pan_display(struct fb_var_screeninfo
> *var,
>
> offset = fb_info->fix.line_length * var->yoffset;
>
> + if (!host->enabled)
> + mxsfb_enable_axi_clk(host);
> +
> /* update on next VSYNC */
> writel(fb_info->fix.smem_start + offset,
> host->base + host->devdata->next_buf);
>
> + if (!host->enabled)
> + mxsfb_disable_axi_clk(host);
> +
Why do you check for host->enabled here, but not elsewhere?
Tomi
signature.asc
Description: OpenPGP digital signature
[PATCH v5 01/12] ARM: dts: sun6i: add p2wi controller node to dtsi
From: Boris BREZILLON
The p2wi controller has only one possible pinmux setting. Use it by
default in the dtsi, instead of having to set it in each board's dts.
Signed-off-by: Boris BREZILLON
[w...@csie.org: reformat commit title; rename p2wi pins and use as default]
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index fa2f403ccf28..92abea20b946 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -973,6 +973,27 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+ p2wi_pins: p2wi {
+ allwinner,pins = "PL0", "PL1";
+ allwinner,function = "s_p2wi";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+ };
+
+ p2wi: i2c@01f03400 {
+ compatible = "allwinner,sun6i-a31-p2wi";
+ reg = <0x01f03400 0x400>;
+ interrupts = ;
+ clocks = <&apb0_gates 3>;
+ clock-frequency = <10>;
+ resets = <&apb0_rst 3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&p2wi_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
};
};
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 05/12] ARM: dts: sun6i: hummingbird: Add AXP221 PMIC device node
The Hummingbird A31 has an AXP221 PMIC hooked up to the
P2WI controller.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 533bedc5dd95..486ffc69ac96 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -142,6 +142,15 @@
&p2wi {
status = "okay";
+
+ axp221: pmic@68 {
+ compatible = "x-powers,axp221";
+ reg = <0x68>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
®_usb1_vbus {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 10/12] ARM: dts: sun6i: hummingbird: Add AXP221 regulator nodes
This patch adds the AXP221 regulators. Only the ones directly used
on the board are added.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 56 -
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 486ffc69ac96..d13c88c6509a 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -115,7 +115,7 @@
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_hummingbird>;
- vmmc-supply = <®_vcc3v0>;
+ vmmc-supply = <&vcc_3v0>;
bus-width = <4>;
cd-gpios = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */
cd-inverted;
@@ -150,6 +150,60 @@
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <1>;
+ dcdc1-supply = <&vcc_3v0>;
+ dcdc5-supply = <&vcc_dram>;
+
+ regulators {
+ x-powers,dcdc-freq = <3000>;
+
+ vcc_3v0: dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-3v0";
+ };
+
+ vdd_cpu: dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <132>;
+ regulator-name = "vdd-cpu";
+ };
+
+ vdd_gpu: dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <132>;
+ regulator-name = "vdd-gpu";
+ };
+
+ vdd_sys_dll: dcdc4 {
+ regulator-always-on;
+ regulator-min-microvolt = <110>;
+ regulator-max-microvolt = <110>;
+ regulator-name = "vdd-sys-dll";
+ };
+
+ vcc_dram: dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ regulator-name = "vcc-dram";
+ };
+
+ vcc_wifi: aldo1 {
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc_wifi";
+ };
+
+ avcc: aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "avcc";
+ };
+ };
};
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
