* [PATCH v2 2/5] ARM: bus: da8xx-mstpri: new driver
From: Kevin Hilman @ 2016-11-04 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-3-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Kevin Hilman @ 2016-11-04 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-2-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* Applied "ASoC: sun4i-codec: Add support for A31 Line Out playback" to the asoc tree
From: Mark Brown @ 2016-11-04 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-9-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A31 Line Out playback
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 0f909f98d7cbabc3641a45da9c6891444b929a92 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Thu, 3 Nov 2016 15:55:50 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 Line Out playback
The A31 integrated codec has a second "Line Out" output which does not
include an integrated amplifier in its path. This path does have a
separate volume control.
This patch adds support for the playback path from the DAC to the Line
Out pins.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 72a84f76aa57..a10251f4932e 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -794,11 +794,31 @@ static const struct snd_kcontrol_new sun6i_codec_hp_src[] = {
sun6i_codec_hp_src_enum),
};
+/* line out controls */
+static const char * const sun6i_codec_lineout_src_enum_text[] = {
+ "Stereo", "Mono Differential",
+};
+
+static SOC_ENUM_DOUBLE_DECL(sun6i_codec_lineout_src_enum,
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTLSRC,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTRSRC,
+ sun6i_codec_lineout_src_enum_text);
+
+static const struct snd_kcontrol_new sun6i_codec_lineout_src[] = {
+ SOC_DAPM_ENUM("Line Out Source Playback Route",
+ sun6i_codec_lineout_src_enum),
+};
+
/* volume / mute controls */
static const DECLARE_TLV_DB_SCALE(sun6i_codec_dvol_scale, -7308, 116, 0);
static const DECLARE_TLV_DB_SCALE(sun6i_codec_hp_vol_scale, -6300, 100, 1);
static const DECLARE_TLV_DB_SCALE(sun6i_codec_out_mixer_pregain_scale,
-450, 150, 0);
+static const DECLARE_TLV_DB_RANGE(sun6i_codec_lineout_vol_scale,
+ 0, 1, TLV_DB_SCALE_ITEM(TLV_DB_GAIN_MUTE, 0, 1),
+ 2, 31, TLV_DB_SCALE_ITEM(-4350, 150, 0),
+);
static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("DAC Playback Volume", SUN4I_CODEC_DAC_DPC,
@@ -808,10 +828,18 @@ static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SUN6I_CODEC_OM_DACA_CTRL,
SUN6I_CODEC_OM_DACA_CTRL_HPVOL, 0x3f, 0,
sun6i_codec_hp_vol_scale),
+ SOC_SINGLE_TLV("Line Out Playback Volume",
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTVC, 0x1f, 0,
+ sun6i_codec_lineout_vol_scale),
SOC_DOUBLE("Headphone Playback Switch",
SUN6I_CODEC_OM_DACA_CTRL,
SUN6I_CODEC_OM_DACA_CTRL_LHPPAMUTE,
SUN6I_CODEC_OM_DACA_CTRL_RHPPAMUTE, 1, 0),
+ SOC_DOUBLE("Line Out Playback Switch",
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTLEN,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTREN, 1, 0),
/* Mixer pre-gains */
SOC_SINGLE_TLV("Line In Playback Volume",
SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_LINEING,
@@ -853,6 +881,11 @@ static const struct snd_soc_dapm_widget sun6i_codec_codec_dapm_widgets[] = {
SND_SOC_DAPM_REG(snd_soc_dapm_supply, "HPCOM", SUN6I_CODEC_OM_PA_CTRL,
SUN6I_CODEC_OM_PA_CTRL_HPCOM_CTL, 0x3, 0x3, 0),
SND_SOC_DAPM_OUTPUT("HP"),
+
+ /* Line Out path */
+ SND_SOC_DAPM_MUX("Line Out Source Playback Route",
+ SND_SOC_NOPM, 0, 0, sun6i_codec_lineout_src),
+ SND_SOC_DAPM_OUTPUT("LINEOUT"),
};
static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
@@ -878,6 +911,12 @@ static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
{ "Headphone Amp", NULL, "Headphone Source Playback Route" },
{ "HP", NULL, "Headphone Amp" },
{ "HPCOM", NULL, "HPCOM Protection" },
+
+ /* Line Out Routes */
+ { "Line Out Source Playback Route", "Stereo", "Left Mixer" },
+ { "Line Out Source Playback Route", "Stereo", "Right Mixer" },
+ { "Line Out Source Playback Route", "Mono Differential", "Left Mixer" },
+ { "LINEOUT", NULL, "Line Out Source Playback Route" },
};
static struct snd_soc_codec_driver sun6i_codec_codec = {
--
2.10.1
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for A31 analog microphone inputs" to the asoc tree
From: Mark Brown @ 2016-11-04 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-10-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A31 analog microphone inputs
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From ecd5cdb4fd818b1cec55863d5de3683dad1c2f53 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Thu, 3 Nov 2016 15:55:51 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 analog microphone
inputs
The A31 internal codec has 3 microphone outputs, of which MIC2 and MIC3
are muxed internally. The resulting two microphone inputs have separate
gain controls and mixer inputs.
The codec also has 2 microphone bias pins. HBIAS is specifically for the
headphone jack, which also supports headphone detection and control
buttons. These extra functions are not supported yet. The other, MBIAS,
is for all other analog microphones.
There is also mention of digital microphone support, but documentation
is scarce, and no hardware with it is available.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 70 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index a10251f4932e..f55718fe7c5b 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -776,6 +776,14 @@ static const struct snd_kcontrol_new sun6i_codec_mixer_controls[] = {
SUN6I_CODEC_OM_DACA_CTRL,
SUN6I_CODEC_OM_DACA_CTRL_LMIX_LINEINL,
SUN6I_CODEC_OM_DACA_CTRL_RMIX_LINEINR, 1, 0),
+ SOC_DAPM_DOUBLE("Mic1 Playback Switch",
+ SUN6I_CODEC_OM_DACA_CTRL,
+ SUN6I_CODEC_OM_DACA_CTRL_LMIX_MIC1,
+ SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC1, 1, 0),
+ SOC_DAPM_DOUBLE("Mic2 Playback Switch",
+ SUN6I_CODEC_OM_DACA_CTRL,
+ SUN6I_CODEC_OM_DACA_CTRL_LMIX_MIC2,
+ SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC2, 1, 0),
};
/* headphone controls */
@@ -794,6 +802,21 @@ static const struct snd_kcontrol_new sun6i_codec_hp_src[] = {
sun6i_codec_hp_src_enum),
};
+/* microphone controls */
+static const char * const sun6i_codec_mic2_src_enum_text[] = {
+ "Mic2", "Mic3",
+};
+
+static SOC_ENUM_SINGLE_DECL(sun6i_codec_mic2_src_enum,
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC2SLT,
+ sun6i_codec_mic2_src_enum_text);
+
+static const struct snd_kcontrol_new sun6i_codec_mic2_src[] = {
+ SOC_DAPM_ENUM("Mic2 Amplifier Source Route",
+ sun6i_codec_mic2_src_enum),
+};
+
/* line out controls */
static const char * const sun6i_codec_lineout_src_enum_text[] = {
"Stereo", "Mono Differential",
@@ -819,6 +842,10 @@ static const DECLARE_TLV_DB_RANGE(sun6i_codec_lineout_vol_scale,
0, 1, TLV_DB_SCALE_ITEM(TLV_DB_GAIN_MUTE, 0, 1),
2, 31, TLV_DB_SCALE_ITEM(-4350, 150, 0),
);
+static const DECLARE_TLV_DB_RANGE(sun6i_codec_mic_gain_scale,
+ 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
+ 1, 7, TLV_DB_SCALE_ITEM(2400, 300, 0),
+);
static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("DAC Playback Volume", SUN4I_CODEC_DAC_DPC,
@@ -844,9 +871,42 @@ static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("Line In Playback Volume",
SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_LINEING,
0x7, 0, sun6i_codec_out_mixer_pregain_scale),
+ SOC_SINGLE_TLV("Mic1 Playback Volume",
+ SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_MIC1G,
+ 0x7, 0, sun6i_codec_out_mixer_pregain_scale),
+ SOC_SINGLE_TLV("Mic2 Playback Volume",
+ SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_MIC2G,
+ 0x7, 0, sun6i_codec_out_mixer_pregain_scale),
+
+ /* Microphone Amp boost gains */
+ SOC_SINGLE_TLV("Mic1 Boost Volume", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC1BOOST, 0x7, 0,
+ sun6i_codec_mic_gain_scale),
+ SOC_SINGLE_TLV("Mic2 Boost Volume", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC2BOOST, 0x7, 0,
+ sun6i_codec_mic_gain_scale),
};
static const struct snd_soc_dapm_widget sun6i_codec_codec_dapm_widgets[] = {
+ /* Microphone inputs */
+ SND_SOC_DAPM_INPUT("MIC1"),
+ SND_SOC_DAPM_INPUT("MIC2"),
+ SND_SOC_DAPM_INPUT("MIC3"),
+
+ /* Microphone Bias */
+ SND_SOC_DAPM_SUPPLY("HBIAS", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_HBIASEN, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("MBIAS", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MBIASEN, 0, NULL, 0),
+
+ /* Mic input path */
+ SND_SOC_DAPM_MUX("Mic2 Amplifier Source Route",
+ SND_SOC_NOPM, 0, 0, sun6i_codec_mic2_src),
+ SND_SOC_DAPM_PGA("Mic1 Amplifier", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC1AMPEN, 0, NULL, 0),
+ SND_SOC_DAPM_PGA("Mic2 Amplifier", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC2AMPEN, 0, NULL, 0),
+
/* Line In */
SND_SOC_DAPM_INPUT("LINEIN"),
@@ -893,15 +953,25 @@ static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
{ "Left DAC", NULL, "DAC Enable" },
{ "Right DAC", NULL, "DAC Enable" },
+ /* Microphone Routes */
+ { "Mic1 Amplifier", NULL, "MIC1"},
+ { "Mic2 Amplifier Source Route", "Mic2", "MIC2" },
+ { "Mic2 Amplifier Source Route", "Mic3", "MIC3" },
+ { "Mic2 Amplifier", NULL, "Mic2 Amplifier Source Route"},
+
/* Left Mixer Routes */
{ "Left Mixer", "DAC Playback Switch", "Left DAC" },
{ "Left Mixer", "DAC Reversed Playback Switch", "Right DAC" },
{ "Left Mixer", "Line In Playback Switch", "LINEIN" },
+ { "Left Mixer", "Mic1 Playback Switch", "Mic1 Amplifier" },
+ { "Left Mixer", "Mic2 Playback Switch", "Mic2 Amplifier" },
/* Right Mixer Routes */
{ "Right Mixer", "DAC Playback Switch", "Right DAC" },
{ "Right Mixer", "DAC Reversed Playback Switch", "Left DAC" },
{ "Right Mixer", "Line In Playback Switch", "LINEIN" },
+ { "Right Mixer", "Mic1 Playback Switch", "Mic1 Amplifier" },
+ { "Right Mixer", "Mic2 Playback Switch", "Mic2 Amplifier" },
/* Headphone Routes */
{ "Headphone Source Playback Route", "DAC", "Left DAC" },
--
2.10.1
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for A31 board level audio routing" to the asoc tree
From: Mark Brown @ 2016-11-04 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-12-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A31 board level audio routing
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 300a18d13f7eaec789e79dc45bce026e098b45da Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Thu, 3 Nov 2016 15:55:53 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 board level audio
routing
The A31 SoC's codec has various inputs, outputs and microphone bias
supplies. These can be routed on the board in different ways, such as:
- HPCOM may be connected to have the headphone DC coupled.
- Microphones all use the MBIAS main microphone supply or one mic may
use the HBIAS supply, which supports headset detection and buttons.
- Line Out may be routed to an audio jack, or an onboard speaker amp
with power controls.
Add support for specifying the audio routes in the device tree.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/sun4i-codec.txt | 33 ++++++++++++++++++++++
sound/soc/sunxi/sun4i-codec.c | 21 ++++++++++++--
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index bf480e9683a3..d91a95377f49 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -22,6 +22,31 @@ Optional properties:
Required properties for the following compatibles:
- "allwinner,sun6i-a31-codec"
- resets: phandle to the reset control for this device
+- allwinner,audio-routing: A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's
+ source. Valid names include:
+
+ Audio pins on the SoC:
+ "HP"
+ "HPCOM"
+ "LINEIN"
+ "LINEOUT"
+ "MIC1"
+ "MIC2"
+ "MIC3"
+
+ Microphone biases from the SoC:
+ "HBIAS"
+ "MBIAS"
+
+ Board connectors:
+ "Headphone"
+ "Headset Mic"
+ "Line In"
+ "Line Out"
+ "Mic"
+ "Speaker"
Example:
codec: codec at 01c22c00 {
@@ -45,4 +70,12 @@ codec: codec at 01c22c00 {
resets = <&ccu RST_APB1_CODEC>;
dmas = <&dma 15>, <&dma 15>;
dma-names = "rx", "tx";
+ allwinner,audio-routing =
+ "Headphone", "HP",
+ "Speaker", "LINEOUT",
+ "LINEIN", "Line In",
+ "MIC1", "MBIAS",
+ "MIC1", "Mic",
+ "MIC2", "HBIAS",
+ "MIC2", "Headset Mic";
};
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index f55718fe7c5b..1934db29b2b5 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1104,9 +1104,19 @@ static struct snd_soc_card *sun4i_codec_create_card(struct device *dev)
return card;
};
+static const struct snd_soc_dapm_widget sun6i_codec_card_dapm_widgets[] = {
+ SND_SOC_DAPM_HP("Headphone", NULL),
+ SND_SOC_DAPM_LINE("Line In", NULL),
+ SND_SOC_DAPM_LINE("Line Out", NULL),
+ SND_SOC_DAPM_MIC("Headset Mic", NULL),
+ SND_SOC_DAPM_MIC("Mic", NULL),
+ SND_SOC_DAPM_SPK("Speaker", sun4i_codec_spk_event),
+};
+
static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
{
struct snd_soc_card *card;
+ int ret;
card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
if (!card)
@@ -1116,8 +1126,15 @@ static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
if (!card->dai_link)
return ERR_PTR(-ENOMEM);
- card->dev = dev;
- card->name = "A31 Audio Codec";
+ card->dev = dev;
+ card->name = "A31 Audio Codec";
+ card->dapm_widgets = sun6i_codec_card_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
+ card->fully_routed = true;
+
+ ret = snd_soc_of_parse_audio_routing(card, "allwinner,audio-routing");
+ if (ret)
+ dev_warn(dev, "failed to parse audio-routing: %d\n", ret);
return card;
};
--
2.10.1
^ permalink raw reply related
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Matt Ranostay @ 2016-11-04 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104202924.GA6841@amd>
On Fri, Nov 4, 2016 at 1:29 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Fri 2016-11-04 07:58:55, Tony Lindgren wrote:
>> * Pavel Machek <pavel@ucw.cz> [161104 00:10]:
>> > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote:
>> > Do you actually have hardware with more than one bq27xxx?
>>
>> I can at least see the twl4030 battery/charger features
>> being used together with some bq device to monitor the
>> battery state. Not sure if that counts as multiple
>> instances here though :)
>
> I have that, too, but that was not what i was asking.
>
> Matt wanted support for different polling intervals on different
> bq27xxx chips. I'd like to know know if he actually has more than one
> bq27xxx in his device...
>
Actually only one bq27xxx chip but in theory we could have more.
> Best regards,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Pavel Machek @ 2016-11-04 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104145855.GH21430@atomide.com>
On Fri 2016-11-04 07:58:55, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [161104 00:10]:
> > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote:
> > Do you actually have hardware with more than one bq27xxx?
>
> I can at least see the twl4030 battery/charger features
> being used together with some bq device to monitor the
> battery state. Not sure if that counts as multiple
> instances here though :)
I have that, too, but that was not what i was asking.
Matt wanted support for different polling intervals on different
bq27xxx chips. I'd like to know know if he actually has more than one
bq27xxx in his device...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161104/37ee45ee/attachment.sig>
^ permalink raw reply
* [RFC PATCH v2 4/8] arm64: compat: Add a 32-bit vDSO
From: Catalin Marinas @ 2016-11-04 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22ae46f6-f881-63ec-388d-8a7f6cf9934d@arm.com>
On Fri, Oct 28, 2016 at 11:20:07AM +0100, Kevin Brodsky wrote:
> On 28/10/16 04:09, Jisheng Zhang wrote:
> > On Thu, 27 Oct 2016 17:30:54 +0100 Kevin Brodsky wrote:
> > > Provide the files necessary for building a compat (AArch32) vDSO in
> > > kernel/vdso32.
> > >
> > > This is mostly an adaptation of the arm vDSO. The most significant
> > > change in vgettimeofday.c is the use of the arm64 vdso_data struct,
> > > allowing the vDSO data page to be shared between the 32 and 64-bit
> > > vDSOs.
> > >
> > > In addition to the time functions, sigreturn trampolines are also
> > > provided, aiming at replacing those in the vector page. To improve
> > > debugging, CFI and unwinding directives are used, based on glibc's
> > > implementation. Symbol offsets are made available to the kernel using
> > > the same method as the 64-bit vDSO.
> > >
> > > There is unfortunately an important caveat to all this: we cannot get
> > > away with hand-coding 32-bit instructions like in kernel/kuser32.S,
> > > this time we really need a 32-bit compiler. The compat vDSO Makefile
> > > relies on CROSS_COMPILE_ARM32 to provide a 32-bit compiler,
> > > appropriate logic will be added to the arm64 Makefile later on to
> > > ensure that an attempt to build the compat vDSO is made only if this
> > > variable has been set properly.
> > >
> > > Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> > > ---
> > > arch/arm64/kernel/vdso32/Makefile | 121 +++++++++++++
> > > arch/arm64/kernel/vdso32/sigreturn.S | 86 +++++++++
> > > arch/arm64/kernel/vdso32/vdso.S | 32 ++++
> > > arch/arm64/kernel/vdso32/vdso.lds.S | 98 +++++++++++
> > > arch/arm64/kernel/vdso32/vgettimeofday.c | 294 +++++++++++++++++++++++++++++++
> > > 5 files changed, 631 insertions(+)
> > > create mode 100644 arch/arm64/kernel/vdso32/Makefile
> > > create mode 100644 arch/arm64/kernel/vdso32/sigreturn.S
> > > create mode 100644 arch/arm64/kernel/vdso32/vdso.S
> > > create mode 100644 arch/arm64/kernel/vdso32/vdso.lds.S
> > > create mode 100644 arch/arm64/kernel/vdso32/vgettimeofday.c
> > >
> > > diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> > > new file mode 100644
> > > index 000000000000..38facc870f6e
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/vdso32/Makefile
> > > @@ -0,0 +1,121 @@
> > > +#
> > > +# Building a vDSO image for AArch32.
> > > +#
> > > +# Author: Kevin Brodsky <kevin.brodsky@arm.com>
> > > +# A mix between the arm64 and arm vDSO Makefiles.
> > > +
> > > +CC_ARM32 := $(CROSS_COMPILE_ARM32)gcc
> > > +
> > > +# Same as cc-ldoption, but using CC_ARM32 instead of CC
> > > +cc32-ldoption = $(call try-run,\
> > > + $(CC_ARM32) $(1) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
> > > +
> > > +# Borrow vdsomunge.c from the arm vDSO
> > > +munge := arch/arm/vdso/vdsomunge
> > > +hostprogs-y := $(srctree)/$(munge)
> > > +
> > > +c-obj-vdso := vgettimeofday.o
> > > +asm-obj-vdso := sigreturn.o
> > > +
> > > +# Build rules
> > > +targets := $(c-obj-vdso) $(asm-obj-vdso) vdso.so vdso.so.dbg vdso.so.raw
> > > +c-obj-vdso := $(addprefix $(obj)/, $(c-obj-vdso))
> > > +asm-obj-vdso := $(addprefix $(obj)/, $(asm-obj-vdso))
> > > +obj-vdso := $(c-obj-vdso) $(asm-obj-vdso)
> > > +
> > > +ccflags-y := -fPIC -fno-common -fno-builtin -fno-stack-protector
> > > +ccflags-y += -DDISABLE_BRANCH_PROFILING
> > > +
> > > +# Force -O2 to avoid libgcc dependencies
> > > +VDSO_CFLAGS := -march=armv8-a -O2
> > For completeness, bringing 32bit compiler need to check whether the 32bit
> > toolchain support some options. IIRC, armv8-a support isn't enabled until
> > gcc 4.8, so old toolchains such gcc-4.7 will complain:
> > error: unrecognized argument in option ?-march=armv8-a?
>
> That's a fair point. I guess -march=armv8-a is not strictly necessary and
> the produced vDSO should be fine if arch/arm/vdso also compiles fine.
> However we would still need to pass -march=armv7-a. I'm not sure what to do
> between:
> * Checking that the compiler supports -march=armv8-a when inspecting
> CROSS_COMPILE_ARM32, and if it doesn't vdso32 will not be built.
> * Checking whether -march=armv8-a is available here, and if it is not fall
> back to -march=armv7-a.
Does v8 vs v7 make any difference in the generated code? If not, we
could just stick to armv7-a permanently.
--
Catalin
^ permalink raw reply
* [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Stephen Boyd @ 2016-11-04 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXOW4Ubafu=x9pCw_W-MtLGe3N974dbfHCH5TJuUAeYrQ@mail.gmail.com>
On 11/02, Geert Uytterhoeven wrote:
> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > Would the pull requests for clk also have dts changes at the base
> > of the tree? Perhaps clk side can just ack the clk patches and
>
> Yes they would: this is moving functionality from platform code to DT.
> Without the DT updates, it will break bisection (except for R-Car Gen2,
> where we have fallback code to handle old DTBs).
>
> > then have it all routed through arm-soc? The only worry I have is
> > if we need to make some sort of change in clk side that conflicts
> > with these changes. I don't usually like taking dts changes
> > through clk tree, so I'd like to avoid that if possible.
>
> Everything could go through arm-soc only with your Acked-by.
> However, there are new clock drivers pending on this series.
> Either they have to go through arm-soc, too, or this series would
> be pulled into the clk tree with these new clock drivers.
>
> > Part E could happen anytime after everything else happens, so
> > that doesn't seem like a concern.
>
> Part E can indeed by postponed.
> But if parts A-D are applied together, there's no reason to postpone part E.
>
> > Part C could also be made to
> > only call into the new reset drivers if the reset dts nodes are
> > present? If that's done then we could merge clk patches anytime
> > and remove the dead code and the node search at some later time
> > when everything has settled?
>
> That would require adding more backwards compatibility code for
> old DTBs, even for platform where we're not interested in maintaining
> that. In addition, Part C depends on the header file for the reset driver
> to compile the clock driver, even if you would add some DT detection,
> and on the reset driver to link. So I'm afraid this is not feasible.
>
TL;DR: Sounds fine, I'll be on the lookout for the PR.
Longer version: Let me step back a bit and actually think about
this longer than 2 minutes. From what I see
rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
aren't present. Great.
So clk tree could be given a pull for the clk patches, part C, on
top of part A, the reset driver. If the rcar_rst_read_mode_pins()
returns failure because the node is missing, we fall back to the
old style of doing things. Some drivers already do that anyway,
so this looks to be replacing things like
if (rcar_rst_read_mode_pins())
return;
with
if (rcar_rst_read_mode_pins() != -ENODEV)
return;
Then in arm-soc tree, the dts patches are merged. That causes us
to do some duplicate work reading the pins twice in mach-shmobile
and in the new reset driver. That's duplicate/wasteful, but it
works. Finally, everything is merged together into a tagged
release. The mach-shmobile changes can happen anytime after that
(part D). Again we're left with dead code in the clk driver (part
E) until the dependency merges, but that's ok. Once part D merges
we can get rid of the dead code in part E and any backwards
compatibility we don't want to maintain.
In summary, it's all feasible to do this and most people wouldn't
have had to know about the dependency chain but it's not fast by
any means. Instead we merge everything in one shot and get it
over with now.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Low network throughput on i.MX28
From: Stefan Wahren @ 2016-11-04 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478285097.26659.2.camel@embedded.rocks>
Hi J?rg,
> J?rg Krause <joerg.krause@embedded.rocks> hat am 4. November 2016 um 19:44
> geschrieben:
>
>
> Hi Shawn,
>
> On Wed, 2016-11-02 at 09:24 +0100, Stefan Wahren wrote:
> > Am 02.11.2016 um 09:14 schrieb J?rg Krause:
> > > On Sat, 2016-10-29 at 11:08 +0200, Stefan Wahren wrote:
> > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 29. Oktober
> > > > > 2016
> > > > > um 01:07
> > > > > geschrieben:
> > > > >
> > > > >
> > > > > You mentioned [1] an optimization in the Freescale vendor Linux
> > > > > kernel
> > > > > [2]. I would really like to see this optimization in the
> > > > > mainline
> > > > > kernel.
> > > > >
> > > > > Did you ever tried to port this code from Freescale to
> > > > > mainline?
> > > >
> > > > Yes, i tried once but i was frustrated soon because of the lot of
> > > > required
> > > > changes and resulting issues.
> > >
> > > I got the PIO mode working for the mxs-mmc driver. For this I
> > > ported
> > > the PIO code from the vendor kernel and removed the usage of the
> > > DMA
> > > engine entirely.
> >
> > Good job
> >
> > >
> > > Testing network bandwidth with iperf, I get about ~10Mbit/sec with
> > > PIO
> > > mode compared to ~6.5Mbit/sec with DMA mode for UDP and about
> > > ~6.5Mbit/sec compared to ~4.5Mbit/sec with DMA mode for TCP.
> >
> > And how about MMC / sd card performance?
>
> I noticed poor performance with the i.MX28 MMC and/or DMA driver using
> the mainline kernel compared to the vendor Freescale kernel 2.6.35.
> I've seen that hou have added the drivers to mainline some years ago.
>
> My custom i.MX28 board has a wifi chip attached to the SSP2 interface.
> Comparing the bandwith with iperf I get >20Mbits/sec on the vendor
> kernel and <5Mbits/sec on the mainline kernel.
there is one thing about the clock handling. I noticed that the Vendor Kernel
round up the clock frequency and the Mainline Kernel round down the clock
frequency [1]. So don't trust the clock ratings from DT / board code. Better
verify the register settings or check it with an osci.
[1] - http://www.spinics.net/lists/linux-mmc/msg09132.html
>
> My best guess is that there is some kind of bottleneck in the drivers.
> I already started looking at the vendor drivers as well as at the
> mainline drivers, but I need some more investigation to understand the
> complexity.
>
> Do you have any idea what the bottleneck might be?
>
> Best regards,
> J?rg Krause
^ permalink raw reply
* [PATCH v3 2/6] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Will Deacon @ 2016-11-04 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104182050.GA1651@buserror.net>
On Fri, Nov 04, 2016 at 01:20:50PM -0500, Scott Wood wrote:
> On Fri, Nov 04, 2016 at 09:06:30PM +0800, Ding Tianhong wrote:
> > The workaround for hisilicon,161601 will check the return value of the system counter
> > by different way, in order to distinguish with the fsl-a008585 workaround, introduce
> > a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
> >
> > v2: Introducing a new generic erratum handling mechanism for fsl erratum a008585.
> >
> > v3: Introducing the erratum_workaround_set_sne generic function for fsl erratum a008585
> > and make the #define __fsl_a008585_read_reg to be private to the .c file instead of
> > being globally visible. After discussion with Marc and Will, a consensus decision was
> > made to remove the commandline parameter for enabling fsl,erratum-a008585 erratum,
> > and make some generic name more specific, export timer_unstable_counter_workaround
> > for module access.
>
> The command line paramter was added at Marc's request to provide a way of
> enbaling the workaround in a KVM guest, until API is added to allow QEMU to
> discover the need to set the property in the guest device tree. Is there an
> alternative?
Yes -- generate the device-tree property to indicate that there's an issue.
Will
^ permalink raw reply
* [PATCH V3 0/6] ARM64: Uprobe support added
From: Catalin Marinas @ 2016-11-04 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104174951.vj4il3xkdy7a2ln7@localhost>
On Fri, Nov 04, 2016 at 11:49:51AM -0600, Catalin Marinas wrote:
> On Wed, Nov 02, 2016 at 02:40:40PM +0530, Pratyush Anand wrote:
> > Pratyush Anand (6):
> > arm64: kprobe: protect/rename few definitions to be reused by uprobe
> > arm64: kgdb_step_brk_fn: ignore other's exception
> > arm64: Handle TRAP_TRACE for user mode as well
> > arm64: Handle TRAP_BRKPT for user mode as well
> > arm64: introduce mm context flag to keep 32 bit task information
> > arm64: Add uprobe support
>
> I queued the patches for 4.10. I will push them into -next sometime next
> week once I do some testing (I'm currently at the LPC).
I spoke too soon. With these patches on top of 4.9-rc3, defconfig
together with FTRACE and UPROBE_EVENT enabled I get:
In file included from /work/Linux/linux-2.6-aarch64/arch/arm64/kernel/probes/decode-insn.c:20:0:
/work/Linux/linux-2.6-aarch64/arch/arm64/include/asm/kprobes.h:52:5: error: conflicting types for 'kprobe_fault_handler'
int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
^~~~~~~~~~~~~~~~~~~~
In file included from /work/Linux/linux-2.6-aarch64/arch/arm64/kernel/probes/decode-insn.c:17:0:
/work/Linux/linux-2.6-aarch64/include/linux/kprobes.h:398:90: note: previous definition of 'kprobe_fault_handler' was here
static inline int kprobe_fault_handler(struct pt_regs *regs, int trapnr)
^
/work/Linux/linux-2.6-aarch64/scripts/Makefile.build:290: recipe for target 'arch/arm64/kernel/probes/decode-insn.o' failed
--
Catalin
^ permalink raw reply
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-11-04 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ac897803-47e5-6b0b-5664-6dc165c56c23@i2se.com>
Hi Shawn,
On Wed, 2016-11-02 at 09:24 +0100, Stefan Wahren wrote:
> Am 02.11.2016 um 09:14 schrieb J?rg Krause:
> > On Sat, 2016-10-29 at 11:08 +0200, Stefan Wahren wrote:
> > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 29. Oktober
> > > > 2016
> > > > um 01:07
> > > > geschrieben:
> > > >
> > > >
> > > > You mentioned [1] an optimization in the Freescale vendor Linux
> > > > kernel
> > > > [2]. I would really like to see this optimization in the
> > > > mainline
> > > > kernel.
> > > >
> > > > Did you ever tried to port this code from Freescale to
> > > > mainline?
> > >
> > > Yes, i tried once but i was frustrated soon because of the lot of
> > > required
> > > changes and resulting issues.
> >
> > I got the PIO mode working for the mxs-mmc driver. For this I
> > ported
> > the PIO code from the vendor kernel and removed the usage of the
> > DMA
> > engine entirely.
>
> Good job
>
> >
> > Testing network bandwidth with iperf, I get about ~10Mbit/sec with
> > PIO
> > mode compared to ~6.5Mbit/sec with DMA mode for UDP and about
> > ~6.5Mbit/sec compared to ~4.5Mbit/sec with DMA mode for TCP.
>
> And how about MMC / sd card performance?
I noticed poor performance with the i.MX28 MMC and/or DMA driver using
the mainline kernel compared to the vendor Freescale kernel 2.6.35.
I've seen that hou have added the drivers to mainline some years ago.
My custom i.MX28 board has a wifi chip attached to the SSP2 interface.
Comparing the bandwith with iperf I get >20Mbits/sec on the vendor
kernel and <5Mbits/sec on the mainline kernel.
My best guess is that there is some kind of bottleneck in the drivers.
I already started looking at the vendor drivers as well as@the
mainline drivers, but I need some more investigation to understand the
complexity.
Do you have any idea what the bottleneck might be?
Best regards,
J?rg Krause
^ permalink raw reply
* [PATCH 3/3] KVM: arm/arm64: vgic: Kick VCPUs when queueing already pending IRQs
From: Marc Zyngier @ 2016-11-04 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104183638.28137-1-marc.zyngier@arm.com>
From: Shih-Wei Li <shihwei@cs.columbia.edu>
In cases like IPI, we could be queueing an interrupt for a VCPU
that is already running and is not about to exit, because the
VCPU has entered the VM with the interrupt pending and would
not trap on EOI'ing that interrupt. This could result to delays
in interrupt deliveries or even loss of interrupts.
To guarantee prompt interrupt injection, here we have to try to
kick the VCPU.
Signed-off-by: Shih-Wei Li <shihwei@cs.columbia.edu>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
index 2893d5ba523a..6440b56ec90e 100644
--- a/virt/kvm/arm/vgic/vgic.c
+++ b/virt/kvm/arm/vgic/vgic.c
@@ -273,6 +273,18 @@ bool vgic_queue_irq_unlock(struct kvm *kvm, struct vgic_irq *irq)
* no more work for us to do.
*/
spin_unlock(&irq->irq_lock);
+
+ /*
+ * We have to kick the VCPU here, because we could be
+ * queueing an edge-triggered interrupt for which we
+ * get no EOI maintenance interrupt. In that case,
+ * while the IRQ is already on the VCPU's AP list, the
+ * VCPU could have EOI'ed the original interrupt and
+ * won't see this one until it exits for some other
+ * reason.
+ */
+ if (vcpu)
+ kvm_vcpu_kick(vcpu);
return false;
}
--
2.10.1
^ permalink raw reply related
* [PATCH 2/3] KVM: arm/arm64: vgic: Prevent access to invalid SPIs
From: Marc Zyngier @ 2016-11-04 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104183638.28137-1-marc.zyngier@arm.com>
From: Andre Przywara <andre.przywara@arm.com>
In our VGIC implementation we limit the number of SPIs to a number
that the userland application told us. Accordingly we limit the
allocation of memory for virtual IRQs to that number.
However in our MMIO dispatcher we didn't check if we ever access an
IRQ beyond that limit, leading to out-of-bound accesses.
Add a test against the number of allocated SPIs in check_region().
Adjust the VGIC_ADDR_TO_INT macro to avoid an actual division, which
is not implemented on ARM(32).
[maz: cleaned-up original patch]
Cc: stable at vger.kernel.org
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-mmio.c | 41 +++++++++++++++++++++++++++--------------
virt/kvm/arm/vgic/vgic-mmio.h | 14 +++++++-------
2 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
index e18b30ddcdce..ebe1b9fa3c4d 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.c
+++ b/virt/kvm/arm/vgic/vgic-mmio.c
@@ -453,17 +453,33 @@ struct vgic_io_device *kvm_to_vgic_iodev(const struct kvm_io_device *dev)
return container_of(dev, struct vgic_io_device, dev);
}
-static bool check_region(const struct vgic_register_region *region,
+static bool check_region(const struct kvm *kvm,
+ const struct vgic_register_region *region,
gpa_t addr, int len)
{
- if ((region->access_flags & VGIC_ACCESS_8bit) && len == 1)
- return true;
- if ((region->access_flags & VGIC_ACCESS_32bit) &&
- len == sizeof(u32) && !(addr & 3))
- return true;
- if ((region->access_flags & VGIC_ACCESS_64bit) &&
- len == sizeof(u64) && !(addr & 7))
- return true;
+ int flags, nr_irqs = kvm->arch.vgic.nr_spis + VGIC_NR_PRIVATE_IRQS;
+
+ switch (len) {
+ case sizeof(u8):
+ flags = VGIC_ACCESS_8bit;
+ break;
+ case sizeof(u32):
+ flags = VGIC_ACCESS_32bit;
+ break;
+ case sizeof(u64):
+ flags = VGIC_ACCESS_64bit;
+ break;
+ default:
+ return false;
+ }
+
+ if ((region->access_flags & flags) && IS_ALIGNED(addr, len)) {
+ if (!region->bits_per_irq)
+ return true;
+
+ /* Do we access a non-allocated IRQ? */
+ return VGIC_ADDR_TO_INTID(addr, region->bits_per_irq) < nr_irqs;
+ }
return false;
}
@@ -477,7 +493,7 @@ static int dispatch_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
addr - iodev->base_addr);
- if (!region || !check_region(region, addr, len)) {
+ if (!region || !check_region(vcpu->kvm, region, addr, len)) {
memset(val, 0, len);
return 0;
}
@@ -510,10 +526,7 @@ static int dispatch_mmio_write(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
addr - iodev->base_addr);
- if (!region)
- return 0;
-
- if (!check_region(region, addr, len))
+ if (!region || !check_region(vcpu->kvm, region, addr, len))
return 0;
switch (iodev->iodev_type) {
diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
index 4c34d39d44a0..84961b4e4422 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.h
+++ b/virt/kvm/arm/vgic/vgic-mmio.h
@@ -50,15 +50,15 @@ extern struct kvm_io_device_ops kvm_io_gic_ops;
#define VGIC_ADDR_IRQ_MASK(bits) (((bits) * 1024 / 8) - 1)
/*
- * (addr & mask) gives us the byte offset for the INT ID, so we want to
- * divide this with 'bytes per irq' to get the INT ID, which is given
- * by '(bits) / 8'. But we do this with fixed-point-arithmetic and
- * take advantage of the fact that division by a fraction equals
- * multiplication with the inverted fraction, and scale up both the
- * numerator and denominator with 8 to support at most 64 bits per IRQ:
+ * (addr & mask) gives us the _byte_ offset for the INT ID.
+ * We multiply this by 8 the get the _bit_ offset, then divide this by
+ * the number of bits to learn the actual INT ID.
+ * But instead of a division (which requires a "long long div" implementation),
+ * we shift by the binary logarithm of <bits>.
+ * This assumes that <bits> is a power of two.
*/
#define VGIC_ADDR_TO_INTID(addr, bits) (((addr) & VGIC_ADDR_IRQ_MASK(bits)) * \
- 64 / (bits) / 8)
+ 8 >> ilog2(bits))
/*
* Some VGIC registers store per-IRQ information, with a different number
--
2.10.1
^ permalink raw reply related
* [PATCH 1/3] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Marc Zyngier @ 2016-11-04 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104183638.28137-1-marc.zyngier@arm.com>
Architecturally, TLBs are private to the (physical) CPU they're
associated with. But when multiple vcpus from the same VM are
being multiplexed on the same CPU, the TLBs are not private
to the vcpus (and are actually shared across the VMID).
Let's consider the following scenario:
- vcpu-0 maps PA to VA
- vcpu-1 maps PA' to VA
If run on the same physical CPU, vcpu-1 can hit TLB entries generated
by vcpu-0 accesses, and access the wrong physical page.
The solution to this is to keep a per-VM map of which vcpu ran last
on each given physical CPU, and invalidate local TLBs when switching
to a different vcpu from the same VM.
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/include/asm/kvm_asm.h | 1 +
arch/arm/include/asm/kvm_host.h | 3 +++
arch/arm/include/asm/kvm_hyp.h | 1 +
arch/arm/kvm/arm.c | 27 ++++++++++++++++++++++++++-
arch/arm/kvm/hyp/tlb.c | 15 +++++++++++++++
arch/arm64/include/asm/kvm_asm.h | 1 +
arch/arm64/include/asm/kvm_host.h | 3 +++
arch/arm64/include/asm/kvm_mmu.h | 2 +-
arch/arm64/kvm/hyp/tlb.c | 15 +++++++++++++++
9 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index d7ea6bcb29bf..8ef05381984b 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -66,6 +66,7 @@ extern char __kvm_hyp_vector[];
extern void __kvm_flush_vm_context(void);
extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
+extern void __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu);
extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 2d19e02d03fd..d5423ab15ed5 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -57,6 +57,9 @@ struct kvm_arch {
/* VTTBR value associated with below pgd and vmid */
u64 vttbr;
+ /* The last vcpu id that ran on each physical CPU */
+ int __percpu *last_vcpu_ran;
+
/* Timer */
struct arch_timer_kvm timer;
diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
index 343135ede5fa..58508900c4bb 100644
--- a/arch/arm/include/asm/kvm_hyp.h
+++ b/arch/arm/include/asm/kvm_hyp.h
@@ -71,6 +71,7 @@
#define ICIALLUIS __ACCESS_CP15(c7, 0, c1, 0)
#define ATS1CPR __ACCESS_CP15(c7, 0, c8, 0)
#define TLBIALLIS __ACCESS_CP15(c8, 0, c3, 0)
+#define TLBIALL __ACCESS_CP15(c8, 0, c7, 0)
#define TLBIALLNSNHIS __ACCESS_CP15(c8, 4, c3, 4)
#define PRRR __ACCESS_CP15(c10, 0, c2, 0)
#define NMRR __ACCESS_CP15(c10, 0, c2, 1)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 08bb84f2ad58..19b5f5c1c0ff 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -114,11 +114,18 @@ void kvm_arch_check_processor_compat(void *rtn)
*/
int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
{
- int ret = 0;
+ int ret, cpu;
if (type)
return -EINVAL;
+ kvm->arch.last_vcpu_ran = alloc_percpu(typeof(*kvm->arch.last_vcpu_ran));
+ if (!kvm->arch.last_vcpu_ran)
+ return -ENOMEM;
+
+ for_each_possible_cpu(cpu)
+ *per_cpu_ptr(kvm->arch.last_vcpu_ran, cpu) = -1;
+
ret = kvm_alloc_stage2_pgd(kvm);
if (ret)
goto out_fail_alloc;
@@ -141,6 +148,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
out_free_stage2_pgd:
kvm_free_stage2_pgd(kvm);
out_fail_alloc:
+ free_percpu(kvm->arch.last_vcpu_ran);
+ kvm->arch.last_vcpu_ran = NULL;
return ret;
}
@@ -168,6 +177,9 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
{
int i;
+ free_percpu(kvm->arch.last_vcpu_ran);
+ kvm->arch.last_vcpu_ran = NULL;
+
for (i = 0; i < KVM_MAX_VCPUS; ++i) {
if (kvm->vcpus[i]) {
kvm_arch_vcpu_free(kvm->vcpus[i]);
@@ -312,6 +324,19 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
+ int *last_ran;
+
+ last_ran = this_cpu_ptr(vcpu->kvm->arch.last_vcpu_ran);
+
+ /*
+ * We might get preempted before the vCPU actually runs, but
+ * over-invalidation doesn't affect correctness.
+ */
+ if (*last_ran != vcpu->vcpu_id) {
+ kvm_call_hyp(__kvm_tlb_flush_local_vmid, vcpu);
+ *last_ran = vcpu->vcpu_id;
+ }
+
vcpu->cpu = cpu;
vcpu->arch.host_cpu_context = this_cpu_ptr(kvm_host_cpu_state);
diff --git a/arch/arm/kvm/hyp/tlb.c b/arch/arm/kvm/hyp/tlb.c
index 729652854f90..6d810af2d9fd 100644
--- a/arch/arm/kvm/hyp/tlb.c
+++ b/arch/arm/kvm/hyp/tlb.c
@@ -55,6 +55,21 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
__kvm_tlb_flush_vmid(kvm);
}
+void __hyp_text __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu)
+{
+ struct kvm *kvm = kern_hyp_va(kern_hyp_va(vcpu)->kvm);
+
+ /* Switch to requested VMID */
+ write_sysreg(kvm->arch.vttbr, VTTBR);
+ isb();
+
+ write_sysreg(0, TLBIALL);
+ dsb(nsh);
+ isb();
+
+ write_sysreg(0, VTTBR);
+}
+
void __hyp_text __kvm_flush_vm_context(void)
{
write_sysreg(0, TLBIALLNSNHIS);
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 18f746551bf6..ec3553eb9349 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -54,6 +54,7 @@ extern char __kvm_hyp_vector[];
extern void __kvm_flush_vm_context(void);
extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
+extern void __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu);
extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index bd94e6766759..e5050388e062 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -62,6 +62,9 @@ struct kvm_arch {
/* VTTBR value associated with above pgd and vmid */
u64 vttbr;
+ /* The last vcpu id that ran on each physical CPU */
+ int __percpu *last_vcpu_ran;
+
/* The maximum number of vCPUs depends on the used GIC model */
int max_vcpus;
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index a79b969c26fc..6f72fe8b0e3e 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -128,7 +128,7 @@ static inline unsigned long __kern_hyp_va(unsigned long v)
return v;
}
-#define kern_hyp_va(v) (typeof(v))(__kern_hyp_va((unsigned long)(v)))
+#define kern_hyp_va(v) ((typeof(v))(__kern_hyp_va((unsigned long)(v))))
/*
* We currently only support a 40bit IPA.
diff --git a/arch/arm64/kvm/hyp/tlb.c b/arch/arm64/kvm/hyp/tlb.c
index 9cc0ea784ae6..88e2f2b938f0 100644
--- a/arch/arm64/kvm/hyp/tlb.c
+++ b/arch/arm64/kvm/hyp/tlb.c
@@ -64,6 +64,21 @@ void __hyp_text __kvm_tlb_flush_vmid(struct kvm *kvm)
write_sysreg(0, vttbr_el2);
}
+void __hyp_text __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu)
+{
+ struct kvm *kvm = kern_hyp_va(kern_hyp_va(vcpu)->kvm);
+
+ /* Switch to requested VMID */
+ write_sysreg(kvm->arch.vttbr, vttbr_el2);
+ isb();
+
+ asm volatile("tlbi vmalle1" : : );
+ dsb(nsh);
+ isb();
+
+ write_sysreg(0, vttbr_el2);
+}
+
void __hyp_text __kvm_flush_vm_context(void)
{
dsb(ishst);
--
2.10.1
^ permalink raw reply related
* [PULL 0/3] KVM/ARM updates for v4.9-rc4
From: Marc Zyngier @ 2016-11-04 18:36 UTC (permalink / raw)
To: linux-arm-kernel
Paolo, Radim,
Please find below the KVM/ARM updates for v4.9-rc4 (or later if we've
already missed the boat).
Thanks,
M.
The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)
are available in the git repository at:
git://git.kernel.org:/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-v4.9-rc4
for you to fetch changes up to d42c79701a3ee5c38fbbc82f98a140420bd40134:
KVM: arm/arm64: vgic: Kick VCPUs when queueing already pending IRQs (2016-11-04 17:56:56 +0000)
----------------------------------------------------------------
KVM/ARM updates for v4.9-rc4
- Kick the vcpu when a pending interrupt becomes pending again
- Prevent access to invalid interrupt registers
- Invalid TLBs when two vcpus from the same VM share a CPU
----------------------------------------------------------------
Andre Przywara (1):
KVM: arm/arm64: vgic: Prevent access to invalid SPIs
Marc Zyngier (1):
arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
Shih-Wei Li (1):
KVM: arm/arm64: vgic: Kick VCPUs when queueing already pending IRQs
arch/arm/include/asm/kvm_asm.h | 1 +
arch/arm/include/asm/kvm_host.h | 3 +++
arch/arm/include/asm/kvm_hyp.h | 1 +
arch/arm/kvm/arm.c | 27 +++++++++++++++++++++++++-
arch/arm/kvm/hyp/tlb.c | 15 ++++++++++++++
arch/arm64/include/asm/kvm_asm.h | 1 +
arch/arm64/include/asm/kvm_host.h | 3 +++
arch/arm64/include/asm/kvm_mmu.h | 2 +-
arch/arm64/kvm/hyp/tlb.c | 15 ++++++++++++++
virt/kvm/arm/vgic/vgic-mmio.c | 41 ++++++++++++++++++++++++++-------------
virt/kvm/arm/vgic/vgic-mmio.h | 14 ++++++-------
virt/kvm/arm/vgic/vgic.c | 12 ++++++++++++
12 files changed, 112 insertions(+), 23 deletions(-)
^ permalink raw reply
* [PATCH v3 2/6] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Scott Wood @ 2016-11-04 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478264794-14652-2-git-send-email-dingtianhong@huawei.com>
On Fri, Nov 04, 2016 at 09:06:30PM +0800, Ding Tianhong wrote:
> The workaround for hisilicon,161601 will check the return value of the system counter
> by different way, in order to distinguish with the fsl-a008585 workaround, introduce
> a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
>
> v2: Introducing a new generic erratum handling mechanism for fsl erratum a008585.
>
> v3: Introducing the erratum_workaround_set_sne generic function for fsl erratum a008585
> and make the #define __fsl_a008585_read_reg to be private to the .c file instead of
> being globally visible. After discussion with Marc and Will, a consensus decision was
> made to remove the commandline parameter for enabling fsl,erratum-a008585 erratum,
> and make some generic name more specific, export timer_unstable_counter_workaround
> for module access.
The command line paramter was added at Marc's request to provide a way of
enbaling the workaround in a KVM guest, until API is added to allow QEMU to
discover the need to set the property in the guest device tree. Is there an
alternative?
-Scott
^ permalink raw reply
* [PATCH] arm64: percpu: kill off final ACCESS_ONCE() uses
From: Mark Rutland @ 2016-11-04 18:17 UTC (permalink / raw)
To: linux-arm-kernel
For several reasons it is preferable to use {READ,WRITE}_ONCE() rather than
ACCESS_ONCE(). For example, these handle aggregate types, result in shorter
source code, and better document the intended access (which may be useful for
instrumentation features such as the upcoming KTSAN).
Over a number of patches, most uses of ACCESS_ONCE() in arch/arm64 have been
migrated to {READ,WRITE}_ONCE(). For consistency, and the above reasons, this
patch migrates the final remaining uses.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/percpu.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h
index 5394c84..4afb6fc 100644
--- a/arch/arm64/include/asm/percpu.h
+++ b/arch/arm64/include/asm/percpu.h
@@ -101,16 +101,16 @@ static inline unsigned long __percpu_read(void *ptr, int size)
switch (size) {
case 1:
- ret = ACCESS_ONCE(*(u8 *)ptr);
+ ret = READ_ONCE(*(u8 *)ptr);
break;
case 2:
- ret = ACCESS_ONCE(*(u16 *)ptr);
+ ret = READ_ONCE(*(u16 *)ptr);
break;
case 4:
- ret = ACCESS_ONCE(*(u32 *)ptr);
+ ret = READ_ONCE(*(u32 *)ptr);
break;
case 8:
- ret = ACCESS_ONCE(*(u64 *)ptr);
+ ret = READ_ONCE(*(u64 *)ptr);
break;
default:
BUILD_BUG();
@@ -123,16 +123,16 @@ static inline void __percpu_write(void *ptr, unsigned long val, int size)
{
switch (size) {
case 1:
- ACCESS_ONCE(*(u8 *)ptr) = (u8)val;
+ WRITE_ONCE(*(u8 *)ptr, (u8)val);
break;
case 2:
- ACCESS_ONCE(*(u16 *)ptr) = (u16)val;
+ WRITE_ONCE(*(u16 *)ptr, (u16)val);
break;
case 4:
- ACCESS_ONCE(*(u32 *)ptr) = (u32)val;
+ WRITE_ONCE(*(u32 *)ptr, (u32)val);
break;
case 8:
- ACCESS_ONCE(*(u64 *)ptr) = (u64)val;
+ WRITE_ONCE(*(u64 *)ptr, (u64)val);
break;
default:
BUILD_BUG();
--
2.7.4
^ permalink raw reply related
* [RFC PATCH v2 8/8] arm64: Wire up and expose the new compat vDSO
From: Kevin Brodsky @ 2016-11-04 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104164743.c35wxhgzs6uigv6j@localhost>
On 04/11/2016 10:47, Catalin Marinas wrote:
> On Fri, Nov 04, 2016 at 10:30:08AM -0600, Kevin Brodsky wrote:
>> On 04/11/2016 09:50, Catalin Marinas wrote:
>>> On Thu, Oct 27, 2016 at 05:30:58PM +0100, Kevin Brodsky wrote:
>>>> * The vDSO page replaces the vector page. The vDSO provides its own
>>>> sigreturn trampolines, replacing those in the vector page, but the
>>>> kuser helpers are gone. As a result enabling the compat vDSO will
>>>> break userspace programs relying on the kuser helpers.
>>> I think vDSO and vectors page should not exclude each other. If you want
>>> to disable the vectors page, let's make it an independent config option
>>> like the KUSER_HELPERS in arch/arm64/mm/Kconfig. But I would very much
>>> like to be able to have both the vDSO and the vectors page at the same
>>> time.
>> Indeed, I've had exactly the same feedback from Google yesterday (apparently
>> many Android apps with native libs still target ARMv6....). I'll add the
>> option to keep the kuser helpers.
>>
>> There's a small problem though: how to ensure that the kuser helpers +
>> sigreturn trampolines are always included if the compat vDSO is not built? I
>> can enforce CONFIG_KUSER_HELPERS if !CONFIG_VDSO32 (directly in the
>> code/Makefiles), but the dependency cannot be expressed in Kconfig.
> Or you could insert a separate "sigpage" as arm32 does. This could leave
> independently of vDSO or vectors page.
Yeah I thought about this too. It's a bit more work but probably cleaner and more
flexible, that would also allow to disable the kuser helpers independently of the
compat vDSO.
Thanks,
Kevin
^ permalink raw reply
* [PATCH V3 0/6] ARM64: Uprobe support added
From: Catalin Marinas @ 2016-11-04 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1478068479.git.panand@redhat.com>
On Wed, Nov 02, 2016 at 02:40:40PM +0530, Pratyush Anand wrote:
> Pratyush Anand (6):
> arm64: kprobe: protect/rename few definitions to be reused by uprobe
> arm64: kgdb_step_brk_fn: ignore other's exception
> arm64: Handle TRAP_TRACE for user mode as well
> arm64: Handle TRAP_BRKPT for user mode as well
> arm64: introduce mm context flag to keep 32 bit task information
> arm64: Add uprobe support
I queued the patches for 4.10. I will push them into -next sometime next
week once I do some testing (I'm currently at the LPC).
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Add support for Logic PD SOM and Baseboard
From: Adam Ford @ 2016-11-04 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160809082400.GR4678@tiger>
On Tue, Aug 9, 2016 at 3:24 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> On Wed, Jul 20, 2016 at 11:06:26AM -0500, aford173 at gmail.com wrote:
>> From: Adam Ford <adam.ford@logicpd.com>
>>
>> The system on module (SOM) specific portions are in the .dtsi
>> while the baseboard specific portions are in the .dts file.
>>
>> Signed-off-by: Adam Ford <aford173@gmail.com>
>>
>> diff --git a/arch/arm/boot/dts/imx6q-logicpd.dts b/arch/arm/boot/dts/imx6q-logicpd.dts
>> new file mode 100644
>> index 0000000..6f1663e
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/imx6q-logicpd.dts
>> @@ -0,0 +1,389 @@
>> +/*
>> + * Copyright 2016 Logic PD
>> + * This file is adapted from imx6qdl-sabresd.dts.
>> + * Copyright 2012 Freescale Semiconductor, Inc.
>> + * Copyright 2011 Linaro Ltd.
>> + *
>> + * The code contained herein is licensed under the GNU General Public
>> + * License. You may obtain a copy of the GNU General Public License
>> + * Version 2 or later at the following locations:
>> + *
>> + * http://www.opensource.org/licenses/gpl-license.html
>> + * http://www.gnu.org/copyleft/gpl.html
>> + */
>
> Please consider to use X11/GPL dual license. There are a lot of
> examples in arch/arm/boot/dts.
>
Not a problem. I found another example and I integrated it in.
>> +
>> +/dts-v1/;
>> +
>> +
>
> Drop one newline.
>
>> +#include "imx6qdl-logicpd.dtsi"
>> +
>> +/ {
>> + model = "Logic PD Acuity SOM";
>> + compatible = "fsl,imx6q";
>> +
>> + aliases {
>> + display = &lcd_display;
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>
> Have a new line between property list and sub-node.
>
>> + gen_led0 {
>> + label = "cpu0";
>> + gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
>> + linux,default-trigger = "cpu0";
>> + };
>
> Have a new line between nodes.
>
>> + gen_led1 {
>> + label = "cpu1";
>> + gpios = <&gpio3 20 GPIO_ACTIVE_HIGH>;
>> + linux,default-trigger = "cpu1";
>> + };
>> + gen_led2 {
>> + label = "heartbeat";
>> + gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
>> + linux,default-trigger = "heartbeat";
>> + };
>> + gen_led3 {
>> + label = "Always On";
>> + gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
>> + linux,default-trigger = "default-on";
>> + };
>> + };
>> +
>> + regulators {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>
> Please drop this container node and put the fixed regulator nodes
> directly under root, with following naming schema:
>
> reg_xxx: regulator-xxx {
> ...
> };
>
I renamed the regulators using your schema, however any attempts to
remove the connector and placing the regulator directly under the root
fail upon boot and the #address cells, #size-cells also seem important
and fail when removed.
>> +
>> + reg_usb_otg_vbus: regulator at 0 {
>> + compatible = "regulator-fixed";
>> + reg = <0>;
>> + regulator-name = "usb_otg_vbus";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
>> + enable-active-high;
>> + };
>> +
>> + reg_usb_h1_vbus: regulator at 1 {
>> + compatible = "regulator-fixed";
>> + reg = <1>;
>> + regulator-name = "usb_h1_vbus";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + enable-active-high;
>> + regulator-always-on;
>> + gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + reg_3v3: regulator at 2 {
>> + compatible = "regulator-fixed";
>> + reg = <2>;
>> + regulator-name = "reg_3v3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + };
>> + };
>> +
>> + gpio-keys {
>> + compatible = "gpio-keys";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_gpio_keys>;
>
> Bad indentation.
>
>> +
>> + power {
>> + label = "Power Button";
>> + gpios = <&gpio3 28 GPIO_ACTIVE_LOW>;
>> + wakeup-source;
>> + linux,code = <KEY_POWER>;
>> + };
>> +
>> + volume-up {
>> + label = "Volume Up";
>> + gpios = <&gpio3 29 GPIO_ACTIVE_LOW>;
>> + wakeup-source;
>> + linux,code = <KEY_VOLUMEUP>;
>> + };
>> +
>> + volume-down {
>> + label = "Volume Down";
>> + gpios = <&gpio3 30 GPIO_ACTIVE_LOW>;
>> + wakeup-source;
>> + linux,code = <KEY_VOLUMEDOWN>;
>> + };
>> +
>> + recovery-button {
>> + label = "Recover";
>> + gpios = <&gpio3 31 GPIO_ACTIVE_LOW>;
>> + wakeup-source;
>> + linux,code = <0x198>;
>
> No KEY_XXX code for this one?
I copy-pasted some random key stuff. Since I don't have an explicit
use for the keys, I'll just remove them from the device tree until we
have a better use. I was more using them to test when the keys were
pressed.
>> + };
>> + };
>> +
>> + backlight_lcd: backlight-lcd {
>> + compatible = "pwm-backlight";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_backlight>;
>> + enable-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
>> + pwms = <&pwm3 0 5000000>;
>> + brightness-levels = <0 4 8 16 32 64 128 255>;
>> + default-brightness-level = <6>;
>> + };
>> +
>> +
>> + lcd_display: display at di0 {
>> + compatible = "fsl,imx-parallel-display";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + interface-pix-fmt = "rgb565";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_lcd>;
>> + status = "okay";
>
> Have a newline here.
>
>> + display-timings {
>> + native-mode = <&type15_timing>;
>> + type15_timing: type_15 {
>> + clock-frequency = <9000000>;
>> + hactive = <480>;
>> + vactive = <272>;
>> + hfront-porch = <3>;
>> + hback-porch = <2>;
>> + hsync-len = <42>;
>> + vback-porch = <3>;
>> + vfront-porch = <2>;
>> + vsync-len = <11>;
>> + hsync-active = <1>;
>> + vsync-active = <1>;
>> + de-active = <1>;
>> + pixelclk-active = <0>;
>> + };
>> + };
>> +
>> + port at 0 {
>> + reg = <0>;
>> + display_in: endpoint {
>> + remote-endpoint = <&ipu1_di0_disp0>;
>> + };
>> + };
>
> Ditto
>
>> + port at 1 {
>> + reg = <1>;
>> + display_out: endpoint {
>> + remote-endpoint = <&panel_in>;
>> + };
>> + };
>> + };
>> +
>> + panel: panel {
>> + compatible = "innolux,at043tn24", "simple-panel";
>> + enable-gpios = <&gpio4 17 GPIO_ACTIVE_HIGH>;
>> + backlight = <&backlight_lcd>;
>> + port {
>> + panel_in: endpoint {
>> + remote-endpoint = <&display_out>;
>> + };
>> + };
>> + };
>> +};
>> +
>> +&ipu1_di0_disp0 {
>> + remote-endpoint = <&display_in>;
>> +};
>> +
>> +&pwm3 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_pwm3>;
>> + status = "okay";
>> +};
>> +
>> +
>> +&uart3 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_uart3>;
>> + status = "okay";
>> +};
>> +
>> +&usbh1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usbh1>;
>> + vbus-supply = <®_usb_h1_vbus>;
>> + status = "okay";
>> +};
>> +
>> +&usbh2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usbh2>;
>> + phy_type = "hsic";
>> + disable-over-current;
>> + status = "okay";
>> +};
>> +
>> +&usbotg {
>> + vbus-supply = <®_usb_otg_vbus>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usbotg>;
>> + disable-over-current;
>> + status = "okay";
>> +};
>> +
>> +&fec {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_enet>;
>> + /* TODO: Initialize Ref clock at 50MHz so the reset can work */
>> + /*phy-reset-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>; */
>
> The fec driver ignores the polarity flags of the references in
> phy-reset-gpios and assumes them to be active low unless there is a
> property phy-reset-active-high. So if the reset is truly active high,
> you should have a phy-reset-active-high property here.
>
>> + /* phy-reset-duration = <2>; */
>> + phy-mode = "rmii";
>> + status = "okay";
>> +};
>> +
>> +&usdhc2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usdhc2>;
>> + cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
>> + no-1-8-v;
>> + keep-power-in-suspend;
>> + status = "okay";
>> +};
>> +
>> +&i2c3 {
>> + touchscreen: tsc2004 at 48 {
>> + compatible = "ti,tsc2004";
>> + vio-supply = <®_3v3>;
>> + reg = <0x48>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_touchscreen>;
>> + reset-gpios = <&gpio4 10 GPIO_ACTIVE_HIGH>;
>> + interrupts-extended = <&gpio1 6 IRQ_TYPE_EDGE_RISING>;
>> +
>
> Drop this newline.
>
>> + touchscreen-fuzz-x = <4>;
>> + touchscreen-fuzz-y = <7>;
>> + touchscreen-fuzz-pressure = <2>;
>> + touchscreen-size-x = <4096>;
>> + touchscreen-size-y = <4096>;
>> + touchscreen-max-pressure = <2048>;
>> +
>
> Ditto
>
>> + ti,x-plate-ohms = <280>;
>> + ti,esd-recovery-timeout-ms = <8000>;
>> + };
>> +};
>> +
>> +&iomuxc {
>> + imx6qdl-logicpd-baseboard {
>> +
>
> Drop this container node and put the following pinctrl nodes directly
> under &iomuxc.
>
Like the regulators above, if I remove this connector, the system
won't boot. I compared both the regulator and the iomuxc containers
in this device tree with other imx6q boards, and I seem to be
consistent with what other boards are doing.
>> + pinctrl_uart3: uart3grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_EIM_D23__UART3_CTS_B 0x1b0b1
>> + MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
>> + MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
>> + MX6QDL_PAD_EIM_EB3__UART3_RTS_B 0x1b0b1
>> + >;
>> + };
>> +
>> + pinctrl_usbotg: usbotggrp {
>> + fsl,pins = <
>> + MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
>> + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x130b0 /* USB_OTG_PWR_EN */
>> + >;
>
> Bad indentation.
>
>> + };
>> +
>> + pinctrl_usbh1: usbh1grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0 /* USB_H1_PWR_EN */
>> + >;
>> + };
>> +
>> + pinctrl_usbh2: usbh2grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_RGMII_TXC__USB_H2_DATA 0x13030
>> + MX6QDL_PAD_RGMII_TX_CTL__USB_H2_STROBE 0x17030
>> + >;
>> + };
>> +
>> + pinctrl_usdhc2: usdhc2grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
>> + MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
>> + MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
>> + MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
>> + MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
>> + MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
>> + >;
>> + };
>> +
>> + pinctrl_enet: enetgrp {
>
> Please sort these pinctrl entries alphabetically in node name.
>
>> + fsl,pins = <
>> + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
>> + MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
>> + MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
>> + MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
>> + MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
>> + MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
>> + MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x1b0b0
>> + MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
>> + MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
>> + MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
>> + MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x1b0b0 /* Ethernet Reset */
>> + >;
>> + };
>> +
>> + pinctrl_gpio_leds: gpioledsgrp {
>> + fsl,pins = <
>> + MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x130b0
>> + MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x130b0
>> + MX6QDL_PAD_EIM_D21__GPIO3_IO21 0x130b0
>> + MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x130b0
>> + >;
>> + };
>> +
>> + pinctrl_gpio_keys: gpio_keysgrp {
>
> No underscore in the node name, and use hyphen instead. In this
> particular case, gpiokeysgrp should be fine.
>
>> + fsl,pins = <
>> + MX6QDL_PAD_EIM_D28__GPIO3_IO28 0x1b0b0
>> + MX6QDL_PAD_EIM_D29__GPIO3_IO29 0x1b0b0
>> + MX6QDL_PAD_EIM_D30__GPIO3_IO30 0x1b0b0
>> + MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x1b0b0
>> + >;
>> + };
>> +
>> + pinctrl_touchscreen: touchscreengrp {
>> + fsl,pins = <
>> + MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
>> + MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x1b0b0
>> + >;
>> + };
>> +
>> + pinctrl_lcd: lcdgrp {
>> + fsl,pins = <
>> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10 /* R_LCD_DCLK */
>> + MX6QDL_PAD_DI0_PIN15__GPIO4_IO17 0x100b0 /* R_LCD_PANEL_PWR */
>> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x10 /* R_LCD_HSYNC */
>> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x10 /* R_LCD_VSYNC */
>> + MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04 0x10 /* R_LCD_MDISP */
>> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x10
>> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x10
>> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x10
>> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x10
>> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x10
>> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x10
>> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x10
>> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x10
>> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x10
>> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x10
>> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x10
>> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x10
>> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x10
>> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x10
>> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x10
>> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x10
>> + >;
>> + };
>> +
>> + pinctrl_backlight: backlightgrp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x100b0 /* R_LCD_BACKLIGHT_PWR */
>> + >;
>> + };
>> +
>> + pinctrl_pwm3: pwm3grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
>> + >;
>> + };
>> + };
>> +};
>> +
>> diff --git a/arch/arm/boot/dts/imx6qdl-logicpd.dtsi b/arch/arm/boot/dts/imx6qdl-logicpd.dtsi
>> new file mode 100644
>> index 0000000..dc28925
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/imx6qdl-logicpd.dtsi
>> @@ -0,0 +1,452 @@
>> +/*
>> + * Copyright 2016 Logic PD
>> + * This file is adapted from imx6qdl-sabresd.dtsi.
>> + * Copyright 2012 Freescale Semiconductor, Inc.
>> + * Copyright 2011 Linaro Ltd.
>> + *
>> + * The code contained herein is licensed under the GNU General Public
>> + * License. You may obtain a copy of the GNU General Public License
>> + * Version 2 or later at the following locations:
>> + *
>> + * http://www.opensource.org/licenses/gpl-license.html
>> + * http://www.gnu.org/copyleft/gpl.html
>> + */
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +#include "imx6q.dtsi"
>> +
>> +/ {
>> + chosen {
>> + stdout-path = &uart1;
>> + };
>> +
>> + memory {
>> + reg = <0x10000000 0x80000000>;
>> + };
>> +
>> +
>> +};
>> +
>> +/* Reroute power feeding the CPU to come from the external PMIC */
>> +&cpu0 {
>> + arm-supply = <&sw1a_reg>;
>> + soc-supply = <&sw1c_reg>;
>> +};
>> +
>> +®_arm
>> +{
>> + vin-supply = <&sw1a_reg>;
>> +};
>> +
>> +®_soc
>> +{
>> + vin-supply = <&sw1c_reg>;
>> +};
>> +
>> +&clks {
>> + assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
>> + <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
>> + assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
>> + <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
>> +};
>> +
>> +&gpmi {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_gpmi_nand>;
>> + status = "okay";
>> +};
>> +
>> +&i2c3 {
>> + clock-frequency = <100000>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_i2c3>;
>> + status = "okay";
>> +
>> + pmic: pfuze100 at 08 {
>> + compatible = "fsl,pfuze100";
>> + reg = <0x08>;
>> +
>> + regulators {
>> +
>
> Drop this newline.
>
>> + sw1a_reg: sw1ab {
>> + regulator-min-microvolt = <725000>;
>> + regulator-max-microvolt = <1450000>;
>> + regulator-name = "vddcore";
>> + regulator-boot-on;
>> + regulator-always-on;
>> + regulator-ramp-delay = <6250>;
>> + };
>> +
>> + sw1c_reg: sw1c {
>> + regulator-min-microvolt = <725000>;
>> + regulator-max-microvolt = <1450000>;
>> + regulator-name = "vddsoc";
>> + regulator-boot-on;
>> + regulator-always-on;
>> + regulator-ramp-delay = <6250>;
>> + };
>> +
>> + sw2_reg: sw2 {
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-name = "gen_3v3";
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> + sw3a_reg: sw3a {
>> + regulator-min-microvolt = <400000>;
>> + regulator-max-microvolt = <1975000>;
>> + regulator-name = "sw3a_vddr";
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> +
>
> One newline is good enough.
>
>> + sw3b_reg: sw3b {
>> + regulator-min-microvolt = <400000>;
>> + regulator-max-microvolt = <1975000>;
>> + regulator-name = "sw3b_vddr";
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> + sw4_reg: sw4 {
>> + regulator-min-microvolt = <800000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-name = "gen_rgmii";
>> + };
>> +
>> +
>> + swbst_reg: swbst {
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5150000>;
>> + regulator-name = "gen_5v0";
>> + };
>> +
>> +
>
> Ditto
>
>> + snvs_reg: vsnvs {
>> + regulator-min-microvolt = <1000000>;
>> + regulator-max-microvolt = <3000000>;
>> + regulator-name = "gen_vsns";
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> +
>
> Ditto
>
>> + vref_reg: vrefddr {
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> + vgen1_reg: vgen1 {
>> + regulator-min-microvolt = <1500000>;
>> + regulator-max-microvolt = <1500000>;
>> + regulator-name = "gen_1v5";
>> + };
>> +
>> + vgen2_reg: vgen2 {
>> + regulator-name = "vgen2";
>> + regulator-min-microvolt = <800000>;
>> + regulator-max-microvolt = <1550000>;
>> + };
>> +
>> + vgen3_reg: vgen3 {
>> + regulator-name = "gen_vadj_0";
>> + regulator-min-microvolt = <3000000>;
>> + regulator-max-microvolt = <3000000>;
>> + };
>> +
>> + vgen4_reg: vgen4 {
>> + regulator-name = "gen_1v8";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + regulator-always-on;
>> + };
>> +
>> + vgen5_reg: vgen5 {
>> + regulator-name = "gen_adj_1";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-always-on;
>> + };
>> +
>> + vgen6_reg: vgen6 {
>> + regulator-name = "gen_2v5";
>> + regulator-min-microvolt = <2500000>;
>> + regulator-max-microvolt = <2500000>;
>> + regulator-always-on;
>> + };
>> + };
>> + };
>> +
>> + user_eeprom: at24 at 52 {
>> + compatible = "atmel,24c64";
>> + pagesize = <32>;
>> + reg = <0x52>;
>> + };
>> +
>> + mfg_eeprom: at24 at 51 {
>> + compatible = "atmel,24c64";
>> + pagesize = <32>;
>> + read-only;
>> + reg = <0x51>;
>> + };
>
> Please sort the devices on I2C bus in order of slave address.
>
>> +
>> + temp_sense0: tmp102 at 4a {
>> + compatible = "ti,tmp102";
>> + reg = <0x4a>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_tempsense>;
>> + interrupt-parent = <&gpio6>;
>> + interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
>> + #thermal-sensor-cells = <1>;
>> + };
>> +
>> + temp_sense1: tmp102 at 40 {
>> + compatible = "ti,tmp102";
>> + reg = <0x49>;
>
> 'reg' doesn't match unit-address of node name.
>
>> + interrupt-parent = <&gpio6>;
>> + interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
>> + #thermal-sensor-cells = <1>;
>> + };
>> +
>> +};
>> +
>> +&iomuxc {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_hog>;
>> +
>> + imx6qdl-acuity {
>
> Drop this container node.
>
>> + pinctrl_hog: hoggrp {
>> + fsl,pins = <
>
> The hog group should be used limitedly to pins that do not have a clear
> owner. Most of pins are used by particular client device, and should be
> set up in client device's pinctrl entry.
>
>> + MX6QDL_PAD_CSI0_MCLK__ARM_TRACE_CTL 0x1b0b0
>> + MX6QDL_PAD_CSI0_DATA_EN__ARM_TRACE_CLK 0x1b0b0
>> + MX6QDL_PAD_CSI0_VSYNC__ARM_TRACE00 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT4__ARM_TRACE01 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT5__ARM_TRACE02 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT6__ARM_TRACE03 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT7__ARM_TRACE04 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT8__ARM_TRACE05 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT9__ARM_TRACE06 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT10__ARM_TRACE07 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT11__ARM_TRACE08 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT12__ARM_TRACE09 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT13__ARM_TRACE10 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT14__ARM_TRACE11 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT15__ARM_TRACE12 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT16__ARM_TRACE13 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT17__ARM_TRACE14 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT18__ARM_TRACE15 0x1b0b0
>> + MX6QDL_PAD_CSI0_DAT19__GPIO6_IO05 0x1b0b0
>> +
>> + MX6QDL_PAD_EIM_LBA__GPIO2_IO27 0x80000000
>> + MX6QDL_PAD_EIM_OE__GPIO2_IO25 0x80000000
>> + MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x80000000
>> + MX6QDL_PAD_EIM_CS0__GPIO2_IO23 0x80000000
>> + MX6QDL_PAD_EIM_CS1__GPIO2_IO24 0x80000000
>> + MX6QDL_PAD_EIM_A16__GPIO2_IO22 0x80000000
>> + MX6QDL_PAD_EIM_A17__GPIO2_IO21 0x80000000
>> + MX6QDL_PAD_EIM_A18__GPIO2_IO20 0x80000000
>> + MX6QDL_PAD_EIM_A19__GPIO2_IO19 0x80000000
>> + MX6QDL_PAD_EIM_A20__GPIO2_IO18 0x80000000
>> + MX6QDL_PAD_EIM_A21__GPIO2_IO17 0x80000000
>> + MX6QDL_PAD_EIM_A22__GPIO2_IO16 0x80000000
>> + MX6QDL_PAD_EIM_A23__GPIO6_IO06 0x80000000
>> + MX6QDL_PAD_EIM_A24__GPIO5_IO04 0x80000000
>> + MX6QDL_PAD_EIM_A25__GPIO5_IO02 0x80000000
>> + MX6QDL_PAD_EIM_DA0__GPIO3_IO00 0x80000000
>> + MX6QDL_PAD_EIM_DA1__GPIO3_IO01 0x80000000
>> + MX6QDL_PAD_EIM_DA2__GPIO3_IO02 0x80000000
>> + MX6QDL_PAD_EIM_DA3__GPIO3_IO03 0x80000000
>> + MX6QDL_PAD_EIM_DA4__GPIO3_IO04 0x80000000
>> + MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x80000000
>> + MX6QDL_PAD_EIM_DA6__GPIO3_IO06 0x80000000
>> + MX6QDL_PAD_EIM_DA7__GPIO3_IO07 0x80000000
>> + MX6QDL_PAD_EIM_DA8__GPIO3_IO08 0x80000000
>> + MX6QDL_PAD_EIM_DA9__GPIO3_IO09 0x80000000
>> + MX6QDL_PAD_EIM_DA10__GPIO3_IO10 0x80000000
>> + MX6QDL_PAD_EIM_DA11__GPIO3_IO11 0x80000000
>> + MX6QDL_PAD_EIM_DA12__GPIO3_IO12 0x80000000
>> + MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x80000000
>> + MX6QDL_PAD_EIM_DA14__GPIO3_IO14 0x80000000
>> + MX6QDL_PAD_EIM_DA15__GPIO3_IO15 0x80000000
>> + MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x80000000
>> + MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x80000000
>> + MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x80000000
>> + MX6QDL_PAD_EIM_D21__GPIO3_IO21 0x80000000
>> + MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x80000000
>> + MX6QDL_PAD_EIM_D26__GPIO3_IO26 0x80000000
>> + MX6QDL_PAD_EIM_D27__GPIO3_IO27 0x80000000
>
> Do not rely on bootloader or reset value, and please use a proper config
> value instead.
>
>> +
>> +
>> +
>> +
>
> Drop these newlines.
>
>> + MX6QDL_PAD_EIM_EB0__GPIO2_IO28 0x80000000
>> + MX6QDL_PAD_EIM_EB1__GPIO2_IO29 0x80000000
>> + MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x80000000
>> + MX6QDL_PAD_EIM_BCLK__GPIO6_IO31 0x80000000
>> + MX6QDL_PAD_EIM_WAIT__GPIO5_IO00 0x80000000
>> +
>> +
>
> Ditto
>
>> + MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x80000000
>> + MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x80000000
>> +
>
> Ditto
>
>> + MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x80000000
>> + MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x80000000
>> + MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x80000000
>> + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x80000000
>> + MX6QDL_PAD_GPIO_18__GPIO7_IO13 0x80000000
>> + MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x80000000
>> +
>
> Ditto
>
>> + MX6QDL_PAD_KEY_COL0__GPIO4_IO06 0x80000000
>> + MX6QDL_PAD_KEY_ROW0__GPIO4_IO07 0x80000000
>> + MX6QDL_PAD_KEY_COL1__GPIO4_IO08 0x80000000
>> +
>> +
>> +
>> +
>
> Ditto
>
>> + MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x80000000
>> + MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x80000000
>> +
>
> Ditto
>
>> + MX6QDL_PAD_RGMII_TD0__GPIO6_IO20 0x80000000
>> + MX6QDL_PAD_RGMII_TD1__GPIO6_IO21 0x80000000
>> + MX6QDL_PAD_RGMII_TD2__GPIO6_IO22 0x80000000
>> + MX6QDL_PAD_RGMII_TD3__GPIO6_IO23 0x80000000
>> + MX6QDL_PAD_RGMII_RD0__GPIO6_IO25 0x80000000
>> + MX6QDL_PAD_RGMII_RD1__GPIO6_IO27 0x80000000
>> + MX6QDL_PAD_RGMII_RD2__GPIO6_IO28 0x80000000
>> + MX6QDL_PAD_RGMII_RD3__GPIO6_IO29 0x80000000
>> +
>
> Ditto
>
>> + MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0 /* WL_IRQ */
>> + MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x1f0b0 /* WLAN_EN */
>> + MX6QDL_PAD_SD3_RST__GPIO7_IO08 0x1f0b0 /* BT_EN */
>> + MX6QDL_PAD_SD4_DAT0__GPIO2_IO08 0x80000000
>> + MX6QDL_PAD_SD4_DAT3__GPIO2_IO11 0x80000000
>> + >;
>> + };
>> +
>> + pinctrl_gpmi_nand: gpminandgrp {
>> + fsl,pins = <
>> + MX6QDL_PAD_NANDF_CLE__NAND_CLE 0x0b0b1
>> + MX6QDL_PAD_NANDF_ALE__NAND_ALE 0x0b0b1
>> + MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0x0b0b1
>> + MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0x0b000
>> + MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0x0b0b1
>> + MX6QDL_PAD_SD4_CMD__NAND_RE_B 0x0b0b1
>> + MX6QDL_PAD_SD4_CLK__NAND_WE_B 0x0b0b1
>> + MX6QDL_PAD_NANDF_D0__NAND_DATA00 0x0b0b1
>> + MX6QDL_PAD_NANDF_D1__NAND_DATA01 0x0b0b1
>> + MX6QDL_PAD_NANDF_D2__NAND_DATA02 0x0b0b1
>> + MX6QDL_PAD_NANDF_D3__NAND_DATA03 0x0b0b1
>> + MX6QDL_PAD_NANDF_D4__NAND_DATA04 0x0b0b1
>> + MX6QDL_PAD_NANDF_D5__NAND_DATA05 0x0b0b1
>> + MX6QDL_PAD_NANDF_D6__NAND_DATA06 0x0b0b1
>> + MX6QDL_PAD_NANDF_D7__NAND_DATA07 0x0b0b1
>> + >;
>> + };
>> +
>> +
>> + pinctrl_i2c3: i2c3grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_EIM_D17__I2C3_SCL 0x4001b8b1
>> + MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
>> + >;
>> + };
>> +
>> + pinctrl_uart1: uart1grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD3_DAT6__UART1_RX_DATA 0x1b0b1
>> + MX6QDL_PAD_SD3_DAT7__UART1_TX_DATA 0x1b0b1
>> + >;
>> + };
>> +
>> + pinctrl_uart2: uart2grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD4_DAT4__UART2_RX_DATA 0x1b0b1
>> + MX6QDL_PAD_SD4_DAT5__UART2_RTS_B 0x1b0b1
>> + MX6QDL_PAD_SD4_DAT6__UART2_CTS_B 0x1b0b1
>> + MX6QDL_PAD_SD4_DAT7__UART2_TX_DATA 0x1b0b1
>> + >;
>> + };
>> +
>> +
>> +
>
> One newline is good enough.
>
>> + pinctrl_usdhc1: usdhc1grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071
>> + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071
>> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071
>> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071
>> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071
>> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071
>> + >;
>> + };
>> +
>> +
>> +
>
> Ditto
>
>> + pinctrl_usdhc3: usdhc3grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
>> + MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
>> + MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
>> + MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
>> + MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
>> + MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
>> + >;
>> + };
>> +
>> + pinctrl_tempsense: tempsensegrp {
>> + fsl,pins = <
>> + MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x1b0b0 /* Temp Sense Alert */
>> + >;
>> + };
>> + };
>> +};
>> +
>> +&snvs_poweroff {
>> + status = "okay";
>> +};
>> +
>> +
>
> Ditto
>
>> +&uart1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_uart1>;
>> + status = "okay";
>> +};
>> +
>> +&uart2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_uart2>;
>> + status = "okay";
>> +};
>> +
>> +&usdhc1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usdhc1>;
>> + cd-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>;
>> + keep-power-in-suspend;
>> + enable-sdio-wakeup;
>
> Property enable-sdio-wakeup is deprecated. Use wakeup-source instead.
>
>> + status = "okay";
>> +};
>> +
>> +&usdhc3 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usdhc3>;
>> + non-removable;
>> + keep-power-in-suspend;
>> + enable-sdio-wakeup;
>
> Ditto
>
>> + vmmc-supply = <&sw2_reg>;
>> + status = "okay";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>
> Have a new line between property list and child node. Also, we
> generally end the property list with property 'status'.
>
>> + wlcore: wlcore at 0 {
>> + compatible = "ti,wl1837";
>> + reg = <2>;
>
> 'reg' doesn't match the unit-address in node name.
>
> Shawn
>
Thank you for all your feedback. I'll post an update in the next few
days once I hear your feedback to my questions.
adam
>> + interrupt-parent = <&gpio7>;
>> + interrupts = <1 GPIO_ACTIVE_HIGH>;
>> + };
>> +};
>> +
>> +
>> --
>> 2.7.4
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 03/15] irq: move IRQ routing into irq.c
From: Andre Przywara @ 2016-11-04 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002e16f4-34d2-b783-90c5-4c79a427c8bc@arm.com>
Hi Jean-Philippe,
On 02/11/16 14:37, Jean-Philippe Brucker wrote:
> On 20/07/16 18:04, Andre Przywara wrote:
>> The current IRQ routing code in x86/irq.c is mostly implementing a
>> generic KVM interface which other architectures may use too.
>> Move the code to set up an MSI route into the generic irq.c file and
>> guard it with the KVM_CAP_IRQ_ROUTING capability to return an error
>> if the kernel does not support interrupt routing.
>> This also removes the dummy implementations for all other
>> architectures and only leaves the x86 specific code in x86/irq.c.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> Makefile | 4 +--
>> arm/irq.c | 9 ------
>> hw/pci-shmem.c | 2 ++
>> include/kvm/irq.h | 5 ++++
>> irq.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> mips/irq.c | 10 -------
>> powerpc/irq.c | 31 ---------------------
>> virtio/pci.c | 21 +++++++++-----
>> x86/irq.c | 45 ++++--------------------------
>> 9 files changed, 110 insertions(+), 100 deletions(-)
>> delete mode 100644 arm/irq.c
>> delete mode 100644 mips/irq.c
>> delete mode 100644 powerpc/irq.c
>>
>> diff --git a/Makefile b/Makefile
>> index e4a4002..8ca887f 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -138,7 +138,6 @@ ifeq ($(ARCH), powerpc)
>> DEFINES += -DCONFIG_PPC
>> OBJS += powerpc/boot.o
>> OBJS += powerpc/ioport.o
>> - OBJS += powerpc/irq.o
>> OBJS += powerpc/kvm.o
>> OBJS += powerpc/cpu_info.o
>> OBJS += powerpc/kvm-cpu.o
>> @@ -153,7 +152,7 @@ ifeq ($(ARCH), powerpc)
>> endif
>>
>> # ARM
>> -OBJS_ARM_COMMON := arm/fdt.o arm/gic.o arm/ioport.o arm/irq.o \
>> +OBJS_ARM_COMMON := arm/fdt.o arm/gic.o arm/ioport.o \
>> arm/kvm.o arm/kvm-cpu.o arm/pci.o arm/timer.o \
>> arm/pmu.o
>> HDRS_ARM_COMMON := arm/include
>> @@ -186,7 +185,6 @@ ifeq ($(ARCH),mips)
>> ARCH_INCLUDE := mips/include
>> OBJS += mips/kvm.o
>> OBJS += mips/kvm-cpu.o
>> - OBJS += mips/irq.o
>> endif
>> ###
>>
>> diff --git a/arm/irq.c b/arm/irq.c
>> deleted file mode 100644
>> index d8f44df..0000000
>> --- a/arm/irq.c
>> +++ /dev/null
>> @@ -1,9 +0,0 @@
>> -#include "kvm/irq.h"
>> -#include "kvm/kvm.h"
>> -#include "kvm/util.h"
>> -
>> -int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg)
>> -{
>> - die(__FUNCTION__);
>> - return 0;
>> -}
>> diff --git a/hw/pci-shmem.c b/hw/pci-shmem.c
>> index a1c5ab7..7ce98cb 100644
>> --- a/hw/pci-shmem.c
>> +++ b/hw/pci-shmem.c
>> @@ -136,6 +136,8 @@ int pci_shmem__get_local_irqfd(struct kvm *kvm)
>>
>> if (pci_shmem_pci_device.msix.ctrl & cpu_to_le16(PCI_MSIX_FLAGS_ENABLE)) {
>> gsi = irq__add_msix_route(kvm, &msix_table[0].msg);
>> + if (gsi < 0)
>> + return gsi;
>> } else {
>> gsi = pci_shmem_pci_device.irq_line;
>> }
>> diff --git a/include/kvm/irq.h b/include/kvm/irq.h
>> index 8a78e43..bb71521 100644
>> --- a/include/kvm/irq.h
>> +++ b/include/kvm/irq.h
>> @@ -10,11 +10,16 @@
>>
>> struct kvm;
>>
>> +extern struct kvm_irq_routing *irq_routing;
>> +extern int next_gsi;
>> +
>> int irq__alloc_line(void);
>> int irq__get_nr_allocated_lines(void);
>>
>> int irq__init(struct kvm *kvm);
>> int irq__exit(struct kvm *kvm);
>> +
>> +int irq__allocate_routing_entry(void);
>> int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg);
>>
>> #endif
>> diff --git a/irq.c b/irq.c
>> index 71eaa05..c4b481c 100644
>> --- a/irq.c
>> +++ b/irq.c
>> @@ -1,7 +1,19 @@
>> +#include <stdlib.h>
>> +#include <sys/ioctl.h>
>> +#include <linux/types.h>
>> +#include <linux/kvm.h>
>> +#include <errno.h>
>> +
>> +#include "kvm/kvm.h"
>> #include "kvm/irq.h"
>> #include "kvm/kvm-arch.h"
>>
>> static u8 next_line = KVM_IRQ_OFFSET;
>> +static int allocated_gsis = 0;
>> +
>> +int next_gsi;
>> +
>> +struct kvm_irq_routing *irq_routing = NULL;
>>
>> int irq__alloc_line(void)
>> {
>> @@ -12,3 +24,74 @@ int irq__get_nr_allocated_lines(void)
>> {
>> return next_line - KVM_IRQ_OFFSET;
>> }
>> +
>> +int irq__allocate_routing_entry(void)
>> +{
>> + size_t table_size = sizeof(struct kvm_irq_routing);
>> + int nr_entries = 0;
>> +
>> + if (irq_routing)
>> + nr_entries = irq_routing->nr;
>> +
>> + if (nr_entries < allocated_gsis)
>> + return 0;
>> +
>> + allocated_gsis = ALIGN(nr_entries + 1, 32);
>> + table_size += sizeof(struct kvm_irq_routing_entry) * allocated_gsis;
>> + irq_routing = realloc(irq_routing, table_size);
>> +
>> + if (irq_routing == NULL)
>> + return ENOMEM;
>
> This should be -ENOMEM. Otherwise when allocate_routing_entry fails,
> add_msix_route will return this positive value, which the caller will
> confuse with a GSI number.
Nice catch! Thanks for that.
I fixed the patch and sent out a v8 (which has one or two more fixes).
Cheers,
Andre.
>> +
>> + irq_routing->nr = nr_entries;
>> +
>> + return 0;
>> +}
>> +
>> +static bool check_for_irq_routing(struct kvm *kvm)
>> +{
>> + static int has_irq_routing = 0;
>> +
>> + if (has_irq_routing == 0) {
>> + if (kvm__supports_extension(kvm, KVM_CAP_IRQ_ROUTING))
>> + has_irq_routing = 1;
>> + else
>> + has_irq_routing = -1;
>> + }
>> +
>> + return has_irq_routing > 0;
>> +}
>> +
>> +int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg)
>> +{
>> + int r;
>> +
>> + if (!check_for_irq_routing(kvm))
>> + return -ENXIO;
>> +
>> + r = irq__allocate_routing_entry();
>> + if (r)
>> + return r;
>> +
>> + irq_routing->entries[irq_routing->nr++] =
>> + (struct kvm_irq_routing_entry) {
>> + .gsi = next_gsi,
>> + .type = KVM_IRQ_ROUTING_MSI,
>> + .u.msi.address_hi = msg->address_hi,
>> + .u.msi.address_lo = msg->address_lo,
>> + .u.msi.data = msg->data,
>> + };
>> +
>> + r = ioctl(kvm->vm_fd, KVM_SET_GSI_ROUTING, irq_routing);
>> + if (r)
>> + return r;
>> +
>> + return next_gsi++;
>> +}
>> +
>> +int __attribute__((weak)) irq__exit(struct kvm *kvm)
>> +{
>> + free(irq_routing);
>> + return 0;
>> +}
>> +dev_base_exit(irq__exit);
>> diff --git a/mips/irq.c b/mips/irq.c
>> deleted file mode 100644
>> index c1ff6bb..0000000
>> --- a/mips/irq.c
>> +++ /dev/null
>> @@ -1,10 +0,0 @@
>> -#include "kvm/irq.h"
>> -#include "kvm/kvm.h"
>> -
>> -#include <stdlib.h>
>> -
>> -int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg)
>> -{
>> - pr_warning("irq__add_msix_route");
>> - return 1;
>> -}
>> diff --git a/powerpc/irq.c b/powerpc/irq.c
>> deleted file mode 100644
>> index 03f2fe7..0000000
>> --- a/powerpc/irq.c
>> +++ /dev/null
>> @@ -1,31 +0,0 @@
>> -/*
>> - * PPC64 IRQ routines
>> - *
>> - * Copyright 2011 Matt Evans <matt@ozlabs.org>, IBM Corporation.
>> - *
>> - * 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.
>> - */
>> -
>> -#include "kvm/devices.h"
>> -#include "kvm/irq.h"
>> -#include "kvm/kvm.h"
>> -#include "kvm/util.h"
>> -
>> -#include <linux/types.h>
>> -#include <linux/rbtree.h>
>> -#include <linux/list.h>
>> -#include <linux/kvm.h>
>> -#include <sys/ioctl.h>
>> -
>> -#include <stddef.h>
>> -#include <stdlib.h>
>> -
>> -#include "kvm/pci.h"
>> -
>> -int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg)
>> -{
>> - die(__FUNCTION__);
>> - return 0;
>> -}
>> diff --git a/virtio/pci.c b/virtio/pci.c
>> index 90fcd64..072e5b7 100644
>> --- a/virtio/pci.c
>> +++ b/virtio/pci.c
>> @@ -156,7 +156,8 @@ static bool virtio_pci__specific_io_out(struct kvm *kvm, struct virtio_device *v
>> void *data, int size, int offset)
>> {
>> struct virtio_pci *vpci = vdev->virtio;
>> - u32 config_offset, gsi, vec;
>> + u32 config_offset, vec;
>> + int gsi;
>> int type = virtio__get_dev_specific_field(offset - 20, virtio_pci__msix_enabled(vpci),
>> &config_offset);
>> if (type == VIRTIO_PCI_O_MSIX) {
>> @@ -166,21 +167,27 @@ static bool virtio_pci__specific_io_out(struct kvm *kvm, struct virtio_device *v
>> if (vec == VIRTIO_MSI_NO_VECTOR)
>> break;
>>
>> - gsi = irq__add_msix_route(kvm, &vpci->msix_table[vec].msg);
>> -
>> - vpci->config_gsi = gsi;
>> + gsi = irq__add_msix_route(kvm,
>> + &vpci->msix_table[vec].msg);
>> + if (gsi >= 0)
>> + vpci->config_gsi = gsi;
>> break;
>> case VIRTIO_MSI_QUEUE_VECTOR:
>> - vec = vpci->vq_vector[vpci->queue_selector] = ioport__read16(data);
>> + vec = ioport__read16(data);
>> + vpci->vq_vector[vpci->queue_selector] = vec;
>>
>> if (vec == VIRTIO_MSI_NO_VECTOR)
>> break;
>>
>> - gsi = irq__add_msix_route(kvm, &vpci->msix_table[vec].msg);
>> + gsi = irq__add_msix_route(kvm,
>> + &vpci->msix_table[vec].msg);
>> + if (gsi < 0)
>> + break;
>> vpci->gsis[vpci->queue_selector] = gsi;
>> if (vdev->ops->notify_vq_gsi)
>> vdev->ops->notify_vq_gsi(kvm, vpci->dev,
>> - vpci->queue_selector, gsi);
>> + vpci->queue_selector,
>> + gsi);
>> break;
>> };
>>
>> diff --git a/x86/irq.c b/x86/irq.c
>> index 72177e7..db465a1 100644
>> --- a/x86/irq.c
>> +++ b/x86/irq.c
>> @@ -11,20 +11,15 @@
>> #include <stddef.h>
>> #include <stdlib.h>
>>
>> -#define IRQ_MAX_GSI 64
>> #define IRQCHIP_MASTER 0
>> #define IRQCHIP_SLAVE 1
>> #define IRQCHIP_IOAPIC 2
>>
>> -/* First 24 GSIs are routed between IRQCHIPs and IOAPICs */
>> -static u32 gsi = 24;
>> -
>> -struct kvm_irq_routing *irq_routing;
>> -
>> static int irq__add_routing(u32 gsi, u32 type, u32 irqchip, u32 pin)
>> {
>> - if (gsi >= IRQ_MAX_GSI)
>> - return -ENOSPC;
>> + int r = irq__allocate_routing_entry();
>> + if (r)
>> + return r;
>>
>> irq_routing->entries[irq_routing->nr++] =
>> (struct kvm_irq_routing_entry) {
>> @@ -41,11 +36,6 @@ int irq__init(struct kvm *kvm)
>> {
>> int i, r;
>>
>> - irq_routing = calloc(sizeof(struct kvm_irq_routing) +
>> - IRQ_MAX_GSI * sizeof(struct kvm_irq_routing_entry), 1);
>> - if (irq_routing == NULL)
>> - return -ENOMEM;
>> -
>> /* Hook first 8 GSIs to master IRQCHIP */
>> for (i = 0; i < 8; i++)
>> if (i != 2)
>> @@ -69,33 +59,8 @@ int irq__init(struct kvm *kvm)
>> return errno;
>> }
>>
>> - return 0;
>> -}
>> -dev_base_init(irq__init);
>> + next_gsi = i;
>>
>> -int irq__exit(struct kvm *kvm)
>> -{
>> - free(irq_routing);
>> return 0;
>> }
>> -dev_base_exit(irq__exit);
>> -
>> -int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg)
>> -{
>> - int r;
>> -
>> - irq_routing->entries[irq_routing->nr++] =
>> - (struct kvm_irq_routing_entry) {
>> - .gsi = gsi,
>> - .type = KVM_IRQ_ROUTING_MSI,
>> - .u.msi.address_hi = msg->address_hi,
>> - .u.msi.address_lo = msg->address_lo,
>> - .u.msi.data = msg->data,
>> - };
>> -
>> - r = ioctl(kvm->vm_fd, KVM_SET_GSI_ROUTING, irq_routing);
>> - if (r)
>> - return r;
>> -
>> - return gsi++;
>> -}
>> +dev_base_init(irq__init);
>>
>
^ permalink raw reply
* [PATCH v8 16/16] arm: add support for vGICv3 and vITS
From: Andre Przywara @ 2016-11-04 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104173203.21168-1-andre.przywara@arm.com>
From: Vladimir Murzin <vladimir.murzin@arm.com>
KVM/arm got support for vGICv3 and vITS recently, so make use of it.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arm/aarch32/arm-cpu.c | 2 +-
arm/aarch32/include/kvm/kvm-arch.h | 3 ---
arm/aarch64/include/kvm/kvm-arch.h | 3 ---
arm/include/arm-common/kvm-arch.h | 2 ++
4 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arm/aarch32/arm-cpu.c b/arm/aarch32/arm-cpu.c
index 27a8e17..16bba55 100644
--- a/arm/aarch32/arm-cpu.c
+++ b/arm/aarch32/arm-cpu.c
@@ -12,7 +12,7 @@ static void generate_fdt_nodes(void *fdt, struct kvm *kvm)
{
int timer_interrupts[4] = {13, 14, 11, 10};
- gic__generate_fdt_nodes(fdt, IRQCHIP_GICV2);
+ gic__generate_fdt_nodes(fdt, kvm->cfg.arch.irqchip);
timer__generate_fdt_nodes(fdt, kvm, timer_interrupts);
}
diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
index 1632e3c..cd31e72 100644
--- a/arm/aarch32/include/kvm/kvm-arch.h
+++ b/arm/aarch32/include/kvm/kvm-arch.h
@@ -1,9 +1,6 @@
#ifndef KVM__KVM_ARCH_H
#define KVM__KVM_ARCH_H
-#define ARM_GIC_DIST_SIZE 0x1000
-#define ARM_GIC_CPUI_SIZE 0x2000
-
#define ARM_KERN_OFFSET(...) 0x8000
#define ARM_MAX_MEMORY(...) ARM_LOMAP_MAX_MEMORY
diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
index 4925736..9de623a 100644
--- a/arm/aarch64/include/kvm/kvm-arch.h
+++ b/arm/aarch64/include/kvm/kvm-arch.h
@@ -1,9 +1,6 @@
#ifndef KVM__KVM_ARCH_H
#define KVM__KVM_ARCH_H
-#define ARM_GIC_DIST_SIZE 0x10000
-#define ARM_GIC_CPUI_SIZE 0x20000
-
#define ARM_KERN_OFFSET(kvm) ((kvm)->cfg.arch.aarch32_guest ? \
0x8000 : \
0x80000)
diff --git a/arm/include/arm-common/kvm-arch.h b/arm/include/arm-common/kvm-arch.h
index 0f5fb7f..c83c45f 100644
--- a/arm/include/arm-common/kvm-arch.h
+++ b/arm/include/arm-common/kvm-arch.h
@@ -18,6 +18,8 @@
#define ARM_GIC_DIST_BASE (ARM_AXI_AREA - ARM_GIC_DIST_SIZE)
#define ARM_GIC_CPUI_BASE (ARM_GIC_DIST_BASE - ARM_GIC_CPUI_SIZE)
#define ARM_GIC_SIZE (ARM_GIC_DIST_SIZE + ARM_GIC_CPUI_SIZE)
+#define ARM_GIC_DIST_SIZE 0x10000
+#define ARM_GIC_CPUI_SIZE 0x20000
#define ARM_IOPORT_SIZE (ARM_MMIO_AREA - ARM_IOPORT_AREA)
#define ARM_VIRTIO_MMIO_SIZE (ARM_AXI_AREA - (ARM_MMIO_AREA + ARM_GIC_SIZE))
--
2.9.0
^ permalink raw reply related
* [PATCH v8 15/16] arm64: enable GICv3-ITS emulation
From: Andre Przywara @ 2016-11-04 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104173203.21168-1-andre.przywara@arm.com>
With everything in place for the ITS emulation add a new option to the
--irqchip parameter to allow the user to specify --irqchip=gicv3-its
to enable the ITS emulation.
This will trigger creating the FDT node and an ITS register frame to
tell the kernel we want ITS emulation in the guest.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arm/gic.c | 2 ++
arm/include/arm-common/kvm-config-arch.h | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arm/gic.c b/arm/gic.c
index c422e36..cd4f518 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -43,6 +43,8 @@ int irqchip_parser(const struct option *opt, const char *arg, int unset)
*type = IRQCHIP_GICV2;
} else if (!strcmp(arg, "gicv3")) {
*type = IRQCHIP_GICV3;
+ } else if (!strcmp(arg, "gicv3-its")) {
+ *type = IRQCHIP_GICV3_ITS;
} else {
pr_err("irqchip: unknown type \"%s\"\n", arg);
return -1;
diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
index ed626b5..b48e720 100644
--- a/arm/include/arm-common/kvm-config-arch.h
+++ b/arm/include/arm-common/kvm-config-arch.h
@@ -27,7 +27,7 @@ int irqchip_parser(const struct option *opt, const char *arg, int unset);
"Force virtio devices to use PCI as their default " \
"transport"), \
OPT_CALLBACK('\0', "irqchip", &(cfg)->irqchip, \
- "[gicv2|gicv3]", \
+ "[gicv2|gicv3|gicv3-its]", \
"Type of interrupt controller to emulate in the guest", \
irqchip_parser, NULL),
--
2.9.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox