* [PATCH 06/10] ARM: dts: sun8i-a23: Add device node for internal audio codec
From: Chen-Yu Tsai @ 2016-11-12 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-1-wens@csie.org>
Now that we have a device tree binding and driver for the A23's
internal audio codec, add a device node for it.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a23.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
index 54d045dab825..4d1f929780a8 100644
--- a/arch/arm/boot/dts/sun8i-a23.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23.dtsi
@@ -48,6 +48,22 @@
memory {
reg = <0x40000000 0x40000000>;
};
+
+ soc at 01c00000 {
+ codec: codec at 01c22c00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a23-codec";
+ reg = <0x01c22c00 0x400>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
+ clock-names = "apb", "codec";
+ resets = <&ccu RST_BUS_CODEC>;
+ dmas = <&dma 15>, <&dma 15>;
+ dma-names = "rx", "tx";
+ allwinner,codec-analog-controls = <&codec_analog>;
+ status = "disabled";
+ };
+ };
};
&ccu {
--
2.10.2
^ permalink raw reply related
* [PATCH 07/10] ARM: dts: sun8i-a23: q8-tablet: Enable internal audio codec
From: Chen-Yu Tsai @ 2016-11-12 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-1-wens@csie.org>
The A23 Q8 tablets have an internal mono speaker w/ external amp
which has a shutdown control tied to a GPIO pin. Both the speaker
amp and the headphone jack are tied to the HP output pins. While
the speaker is mono, the headset jack is stereo. Unfortunately
the driver does not support automatic switching of this.
In addition, the headset is DC coupled, or "direct drive" enabled.
The headset's microphone is tied to MIC2 with HBIAS providing power.
A separate internal microphone is tied to MIC1 with MBIAS providing
power.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a23-q8-tablet.dts | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts b/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
index 956320a6cc78..3ab5c0c09d93 100644
--- a/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
+++ b/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
@@ -48,3 +48,26 @@
model = "Q8 A23 Tablet";
compatible = "allwinner,q8-a23", "allwinner,sun8i-a23";
};
+
+&codec {
+ pinctrl-0 = <&codec_pa_pin>;
+ allwinner,pa-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
+ allwinner,audio-routing =
+ "Headphone", "HP",
+ "Headphone", "HPCOM",
+ "Speaker", "HP",
+ "MIC1", "Mic",
+ "MIC2", "Headset Mic",
+ "Mic", "MBIAS",
+ "Headset Mic", "HBIAS";
+ status = "okay";
+};
+
+&pio {
+ codec_pa_pin: codec_pa_pin at 0 {
+ allwinner,pins = "PH9";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
--
2.10.2
^ permalink raw reply related
* [PATCH 08/10] ASoC: sun4i-codec: Add support for H3 codec
From: Chen-Yu Tsai @ 2016-11-12 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-1-wens@csie.org>
The codec on the H3 is similar to the one found on the A31. One key
difference is the analog path controls are routed through the PRCM
block. This is supported by the sun8i-codec-analog driver, and tied
into this codec driver with the audio card's aux_dev.
In addition, the H3 has no HP (headphone) and HBIAS support, and no
MIC3 input. The FIFO related registers are slightly rearranged.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
.../devicetree/bindings/sound/sun4i-codec.txt | 3 +
sound/soc/sunxi/sun4i-codec.c | 71 ++++++++++++++++++++++
2 files changed, 74 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index f7a548b604fc..3033bd8aab0f 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -6,6 +6,7 @@ Required properties:
- "allwinner,sun6i-a31-codec"
- "allwinner,sun7i-a20-codec"
- "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
- reg: must contain the registers location and length
- interrupts: must contain the codec interrupt
- dmas: DMA channels for tx and rx dma. See the DMA client binding,
@@ -23,6 +24,7 @@ Optional properties:
Required properties for the following compatibles:
- "allwinner,sun6i-a31-codec"
- "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-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
@@ -52,6 +54,7 @@ Required properties for the following compatibles:
Required properties for the following compatibles:
- "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
- allwinner,codec-analog-controls: A phandle to the codec analog controls
block in the PRCM.
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 3c5ef1724163..1a5acadf65d7 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -217,6 +217,13 @@
#define SUN8I_A23_CODEC_DAC_TXCNT (0x1c)
#define SUN8I_A23_CODEC_ADC_RXCNT (0x20)
+/* TX FIFO moved on H3 */
+#define SUN8I_H3_CODEC_DAC_TXDATA (0x20)
+#define SUN8I_H3_CODEC_DAC_DBG (0x48)
+#define SUN8I_H3_CODEC_ADC_DBG (0x4c)
+
+/* TODO H3 DAP (Digital Audio Processing) bits */
+
struct sun4i_codec {
struct device *dev;
struct regmap *regmap;
@@ -1293,6 +1300,44 @@ static struct snd_soc_card *sun8i_a23_codec_create_card(struct device *dev)
return card;
};
+static struct snd_soc_card *sun8i_h3_codec_create_card(struct device *dev)
+{
+ struct snd_soc_card *card;
+ int ret;
+
+ card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
+ if (!card)
+ return ERR_PTR(-ENOMEM);
+
+ aux_dev.codec_of_node = of_parse_phandle(dev->of_node,
+ "allwinner,codec-analog-controls",
+ 0);
+ if (!aux_dev.codec_of_node) {
+ dev_err(dev, "Can't find analog controls for codec.\n");
+ return ERR_PTR(-EINVAL);
+ };
+
+ card->dai_link = sun4i_codec_create_link(dev, &card->num_links);
+ if (!card->dai_link)
+ return ERR_PTR(-ENOMEM);
+
+ card->dev = dev;
+ card->name = "H3 Audio Codec";
+ card->dapm_widgets = sun6i_codec_card_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
+ card->dapm_routes = sun8i_codec_card_routes;
+ card->num_dapm_routes = ARRAY_SIZE(sun8i_codec_card_routes);
+ card->aux_dev = &aux_dev;
+ card->num_aux_devs = 1;
+ 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;
+};
+
static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
@@ -1321,6 +1366,13 @@ static const struct regmap_config sun8i_a23_codec_regmap_config = {
.max_register = SUN8I_A23_CODEC_ADC_RXCNT,
};
+static const struct regmap_config sun8i_h3_codec_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = SUN8I_H3_CODEC_ADC_DBG,
+};
+
struct sun4i_codec_quirks {
const struct regmap_config *regmap_config;
const struct snd_soc_codec_driver *codec;
@@ -1369,6 +1421,21 @@ static const struct sun4i_codec_quirks sun8i_a23_codec_quirks = {
.has_reset = true,
};
+static const struct sun4i_codec_quirks sun8i_h3_codec_quirks = {
+ .regmap_config = &sun8i_h3_codec_regmap_config,
+ /*
+ * TODO Share the codec structure with A23 for now.
+ * This should be split out when adding digital audio
+ * processing support for the H3.
+ */
+ .codec = &sun8i_a23_codec_codec,
+ .create_card = sun8i_h3_codec_create_card,
+ .reg_adc_fifoc = REG_FIELD(SUN6I_CODEC_ADC_FIFOC, 0, 31),
+ .reg_dac_txdata = SUN8I_H3_CODEC_DAC_TXDATA,
+ .reg_adc_rxdata = SUN6I_CODEC_ADC_RXDATA,
+ .has_reset = true,
+};
+
static const struct of_device_id sun4i_codec_of_match[] = {
{
.compatible = "allwinner,sun4i-a10-codec",
@@ -1386,6 +1453,10 @@ static const struct of_device_id sun4i_codec_of_match[] = {
.compatible = "allwinner,sun8i-a23-codec",
.data = &sun8i_a23_codec_quirks,
},
+ {
+ .compatible = "allwinner,sun8i-h3-codec",
+ .data = &sun8i_h3_codec_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
--
2.10.2
^ permalink raw reply related
* [PATCH 09/10] ARM: dts: sun8i-h3: Add device nodes for audio codec and its analog controls
From: Chen-Yu Tsai @ 2016-11-12 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-1-wens@csie.org>
Now that we support the audio codec found on the Allwinner H3 SoC, add
device nodes for it.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-h3.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index c38b028cac83..ceec979f57e4 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -485,6 +485,20 @@
status = "disabled";
};
+ codec: codec at 01c22c00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-h3-codec";
+ reg = <0x01c22c00 0x400>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
+ clock-names = "apb", "codec";
+ resets = <&ccu RST_BUS_CODEC>;
+ dmas = <&dma 15>, <&dma 15>;
+ dma-names = "rx", "tx";
+ allwinner,codec-analog-controls = <&codec_analog>;
+ status = "disabled";
+ };
+
uart0: serial at 01c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
@@ -600,6 +614,11 @@
#reset-cells = <1>;
};
+ codec_analog: codec-analog at 01f015c0 {
+ compatible = "allwinner,sun8i-h3-codec-analog";
+ reg = <0x01f015c0 0x4>;
+ };
+
ir: ir at 01f02000 {
compatible = "allwinner,sun5i-a13-ir";
clocks = <&apb0_gates 1>, <&ir_clk>;
--
2.10.2
^ permalink raw reply related
* [PATCH 10/10] ARM: dts: sun8i-h3: orange-pi-pc: Enable audio codec
From: Chen-Yu Tsai @ 2016-11-12 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-1-wens@csie.org>
The Orange Pi PC routes the LINEOUT pins to the audio out jack on the
board. The onboard microphone is routed to MIC1, with MBIAS providing
power.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index 3ec971285aa3..2b1e68d0f2fa 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -90,6 +90,14 @@
};
};
+&codec {
+ allwinner,audio-routing =
+ "Line Out", "LINEOUT",
+ "MIC1", "Mic",
+ "Mic", "MBIAS";
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
--
2.10.2
^ permalink raw reply related
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-12 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111221224.GB10983@amd>
Hi,
On 11-11-16 23:12, Pavel Machek wrote:
> Hi!
>
> Reason #1:
>
>>>> Hmm. So userland can read the LED state, and it can get _some_ value
>>>> back, but it can not know if it is current state or not.
That is not correct, the current behavior for eading the brightness
atrribute is to always return the current state.
>> Why a dedicated file? Are we going to mirror brightness here
>> wrt r/w (show/store) behavior ? If not userspace now needs
>> 2 open fds which is not really nice. If we are and we are
>> not going to use poll for something else on brightness itself
>> then why not just poll directly on brightness ?
>
> Reason #1 is above.
See my reply above.
> Reason #2 is "if userspace sees brightness file, it can not know if
> the notifications on change actually work or not".
If it needs to know that it can simply check the kernel version.
> Reason #3 is that you broke Tony's system. Polling does not make sense
> when trigger such as "CPU in use" is active.
Have you seen v4 of my patch? It fixes this while keeping the
polling on the brightness attribute itself, it basically goes
back (more or less) to v1 of my patch which did not have this
problem. I never wanted notification of trigger / blinking
changes because I already feared Tony's problem would happen.
> Reason #4 is that there are really two brightnesses:
>
> 1) maximum brightness trigger is going to use
>
> 2) current brightness
>
> Currently writing to "brightness" file changes 1), but reading returns
> 2) when available.
Right and Jacek has already said that we cannot change the
reading behavior on the brightness file because of ABI concerns.
So if anything we need a new blink_brightness file or such,
which when read shows the maximum brightness when blinking or
triggers are active. Note that we already have a max_brightness
file which is the actual maximum brightness the led supports.
Since the existing ABI behavior is for the existing brightness
file to return the *current* brightness, please explain to me
how polling on say the new blink_brightness file would make
sense to detect changes in the current brightness ?
> So, feel free to propose better interface. One that solves #1..#4
> above.
Proposal 1:
v4 of my patch, see the list. It solves all but #4, which
is out of scope for my patch, feel free to submit a patch to
solve #4 (with a new sysfs attr).
Proposal 2:
Add a new "user_brightness" file, which shows the last brightness
as set by the user, this would show the read behavior we really
want of brightness: show the real brightness when not blinking /
triggers are active, show the brightness used when on when
blinking / triggers are active.
And then we could add poll support on this new user_brightness
file, thus avoiding the problem with the extra cpu-load on
notifications on blinking / triggers.
Regards,
Hans
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: Add level for cpu dt node for exynos7
From: Alim Akhtar @ 2016-11-12 10:17 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds level for cpu dt node, so that these levels can be used
as a phandle whenever required. For example, adding a "interrupt-affinity"
for arm pmu node.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos7.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index e0d0d01..396ffb9 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -35,28 +35,28 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu at 0 {
+ cpu_atlas0: cpu at 0 {
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0x0>;
enable-method = "psci";
};
- cpu at 1 {
+ cpu_atlas1: cpu at 1 {
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0x1>;
enable-method = "psci";
};
- cpu at 2 {
+ cpu_atlas2: cpu at 2 {
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0x2>;
enable-method = "psci";
};
- cpu at 3 {
+ cpu_atlas3: cpu at 3 {
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0x3>;
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: Add ARM PMU node for exynos7
From: Alim Akhtar @ 2016-11-12 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478945832-1826-1-git-send-email-alim.akhtar@samsung.com>
This patch adds ARM Performance Monitor Unit dt node for exynos7.
PMU provides various statistics on the operation of the CPU and
memory system at runtime, which are very useful when debugging or
profiling code. This enables the same.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos7.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
Changes since v1:
* Added "interrupt-affinity" property as per Robin Murphy review comment.
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 396ffb9..09e7a05b 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -472,6 +472,16 @@
status = "disabled";
};
+ arm-pmu {
+ compatible = "arm,cortex-a57-pmu", "arm,armv8-pmuv3";
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu_atlas0>, <&cpu_atlas1>,
+ <&cpu_atlas2>, <&cpu_atlas3>;
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 13
--
1.7.10.4
^ permalink raw reply related
* [PATCH v6 5/9] drm/hisilicon/hibmc: Add crtc for DE
From: Rongrong Zou @ 2016-11-12 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOw6vbJCu96jcWUDS_zwqGDOa3LiF00adyCijuk7v24Nxe_ivg@mail.gmail.com>
? 2016/11/11 6:14, Sean Paul ??:
> On Fri, Oct 28, 2016 at 3:27 AM, Rongrong Zou <zourongrong@gmail.com> wrote:
>> Add crtc funcs and helper funcs for DE.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 318 ++++++++++++++++++++++++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 +
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
>> 3 files changed, 326 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
>> index 9c1a68c..9b5d0d0 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
>> @@ -23,6 +23,7 @@
>>
>> #include "hibmc_drm_drv.h"
>> #include "hibmc_drm_regs.h"
>> +#include "hibmc_drm_de.h"
>> #include "hibmc_drm_power.h"
>
> nit: alphabetize
ok, thanks.
>
>>
>> /* ---------------------------------------------------------------------- */
>
> Remove
will do, thanks.
>
>> @@ -168,3 +169,320 @@ int hibmc_plane_init(struct hibmc_drm_device *hidev)
>> drm_plane_helper_add(plane, &hibmc_plane_helper_funcs);
>> return 0;
>> }
>> +
>> +static void hibmc_crtc_enable(struct drm_crtc *crtc)
>> +{
>> + unsigned int reg;
>> + /* power mode 0 is default. */
>
> This comment seems to be in the wrong place
will remove it, thanks.
>
>> + struct hibmc_drm_device *hidev = crtc->dev->dev_private;
>> +
>> + hibmc_set_power_mode(hidev, HIBMC_PW_MODE_CTL_MODE_MODE0);
>> +
>> + /* Enable display power gate & LOCALMEM power gate*/
>> + reg = readl(hidev->mmio + HIBMC_CURRENT_GATE);
>> + reg &= ~HIBMC_CURR_GATE_LOCALMEM_MASK;
>> + reg &= ~HIBMC_CURR_GATE_DISPLAY_MASK;
>> + reg |= HIBMC_CURR_GATE_LOCALMEM(ON);
>> + reg |= HIBMC_CURR_GATE_DISPLAY(ON);
>> + hibmc_set_current_gate(hidev, reg);
>> + drm_crtc_vblank_on(crtc);
>> +}
>> +
>> +static void hibmc_crtc_disable(struct drm_crtc *crtc)
>> +{
>> + unsigned int reg;
>> + struct hibmc_drm_device *hidev = crtc->dev->dev_private;
>> +
>> + drm_crtc_vblank_off(crtc);
>> +
>> + hibmc_set_power_mode(hidev, HIBMC_PW_MODE_CTL_MODE_SLEEP);
>> +
>> + /* Enable display power gate & LOCALMEM power gate*/
>> + reg = readl(hidev->mmio + HIBMC_CURRENT_GATE);
>> + reg &= ~HIBMC_CURR_GATE_LOCALMEM_MASK;
>> + reg &= ~HIBMC_CURR_GATE_DISPLAY_MASK;
>> + reg |= HIBMC_CURR_GATE_LOCALMEM(OFF);
>> + reg |= HIBMC_CURR_GATE_DISPLAY(OFF);
>> + hibmc_set_current_gate(hidev, reg);
>> +}
>> +
>> +static int hibmc_crtc_atomic_check(struct drm_crtc *crtc,
>> + struct drm_crtc_state *state)
>> +{
>> + return 0;
>> +}
>
> Caller NULL-checks, no need for stub
thanks for pointing it out.
>
>> +
>> +static unsigned int format_pll_reg(void)
>> +{
>> + unsigned int pllreg = 0;
>> + struct panel_pll pll = {0};
>> +
>> + /* Note that all PLL's have the same format. Here,
>> + * we just use Panel PLL parameter to work out the bit
>> + * fields in the register.On returning a 32 bit number, the value can
>> + * be applied to any PLL in the calling function.
>> + */
>> + pllreg |= HIBMC_PLL_CTRL_BYPASS(OFF) & HIBMC_PLL_CTRL_BYPASS_MASK;
>> + pllreg |= HIBMC_PLL_CTRL_POWER(ON) & HIBMC_PLL_CTRL_POWER_MASK;
>> + pllreg |= HIBMC_PLL_CTRL_INPUT(OSC) & HIBMC_PLL_CTRL_INPUT_MASK;
>> + pllreg |= HIBMC_PLL_CTRL_POD(pll.POD) & HIBMC_PLL_CTRL_POD_MASK;
>> + pllreg |= HIBMC_PLL_CTRL_OD(pll.OD) & HIBMC_PLL_CTRL_OD_MASK;
>> + pllreg |= HIBMC_PLL_CTRL_N(pll.N) & HIBMC_PLL_CTRL_N_MASK;
>> + pllreg |= HIBMC_PLL_CTRL_M(pll.M) & HIBMC_PLL_CTRL_M_MASK;
>> +
>> + return pllreg;
>> +}
>> +
>> +static void set_vclock_hisilicon(struct drm_device *dev, unsigned long pll)
>> +{
>> + unsigned long tmp0, tmp1;
>> + struct hibmc_drm_device *hidev = dev->dev_private;
>> +
>> + /* 1. outer_bypass_n=0 */
>> + tmp0 = readl(hidev->mmio + CRT_PLL1_HS);
>> + tmp0 &= 0xBFFFFFFF;
>> + writel(tmp0, hidev->mmio + CRT_PLL1_HS);
>> +
>> + /* 2. pll_pd=1?inter_bypass=1 */
>> + writel(0x21000000, hidev->mmio + CRT_PLL1_HS);
>> +
>> + /* 3. config pll */
>> + writel(pll, hidev->mmio + CRT_PLL1_HS);
>> +
>> + /* 4. delay */
>> + mdelay(1);
>
> These should be usleep_range() see
> https://www.kernel.org/doc/Documentation/timers/timers-howto.txt
This looks better to me. i think a 'usleep_range(1000, 2000)' is ok.
>
>> +
>> + /* 5. pll_pd =0 */
>> + tmp1 = pll & ~0x01000000;
>> + writel(tmp1, hidev->mmio + CRT_PLL1_HS);
>> +
>> + /* 6. delay */
>> + mdelay(1);
>> +
>> + /* 7. inter_bypass=0 */
>> + tmp1 &= ~0x20000000;
>> + writel(tmp1, hidev->mmio + CRT_PLL1_HS);
>> +
>> + /* 8. delay */
>> + mdelay(1);
>> +
>> + /* 9. outer_bypass_n=1 */
>> + tmp1 |= 0x40000000;
>> + writel(tmp1, hidev->mmio + CRT_PLL1_HS);
>
> This function is a whole lot of magic. Any chance you can pull the
> values out into #defines?
will do. thanks.
>
>> +}
>> +
>> +/* This function takes care the extra registers and bit fields required to
>
> nit: multi-line comments have a leading /* line with the comment
> starting on the following line
thanks for pointing it out.
>
> applies below as well
>
>
>> + *setup a mode in board.
>
> nit: space between * and comment, ie: * setup a mode in board
understood, thanks.
>
> applies to the rest of the comment too
>
>
>> + *Explanation about Display Control register:
>> + *FPGA only supports 7 predefined pixel clocks, and clock select is
>> + *in bit 4:0 of new register 0x802a8.
>> + */
>> +static unsigned int display_ctrl_adjust(struct drm_device *dev,
>> + struct drm_display_mode *mode,
>> + unsigned int ctrl)
>> +{
>> + unsigned long x, y;
>> + unsigned long pll1; /* bit[31:0] of PLL */
>> + unsigned long pll2; /* bit[63:32] of PLL */
>> + struct hibmc_drm_device *hidev = dev->dev_private;
>> +
>> + x = mode->hdisplay;
>> + y = mode->vdisplay;
>> +
>> + /* Hisilicon has to set up a new register for PLL control
>> + *(CRT_PLL1_HS & CRT_PLL2_HS).
>> + */
>> + if (x == 800 && y == 600) {
>> + pll1 = CRT_PLL1_HS_40MHZ;
>> + pll2 = CRT_PLL2_HS_40MHZ;
>> + } else if (x == 1024 && y == 768) {
>> + pll1 = CRT_PLL1_HS_65MHZ;
>> + pll2 = CRT_PLL2_HS_65MHZ;
>> + } else if (x == 1152 && y == 864) {
>> + pll1 = CRT_PLL1_HS_80MHZ_1152;
>> + pll2 = CRT_PLL2_HS_80MHZ;
>> + } else if (x == 1280 && y == 768) {
>> + pll1 = CRT_PLL1_HS_80MHZ;
>> + pll2 = CRT_PLL2_HS_80MHZ;
>> + } else if (x == 1280 && y == 720) {
>> + pll1 = CRT_PLL1_HS_74MHZ;
>> + pll2 = CRT_PLL2_HS_74MHZ;
>> + } else if (x == 1280 && y == 960) {
>> + pll1 = CRT_PLL1_HS_108MHZ;
>> + pll2 = CRT_PLL2_HS_108MHZ;
>> + } else if (x == 1280 && y == 1024) {
>> + pll1 = CRT_PLL1_HS_108MHZ;
>> + pll2 = CRT_PLL2_HS_108MHZ;
>> + } else if (x == 1600 && y == 1200) {
>> + pll1 = CRT_PLL1_HS_162MHZ;
>> + pll2 = CRT_PLL2_HS_162MHZ;
>> + } else if (x == 1920 && y == 1080) {
>> + pll1 = CRT_PLL1_HS_148MHZ;
>> + pll2 = CRT_PLL2_HS_148MHZ;
>> + } else if (x == 1920 && y == 1200) {
>> + pll1 = CRT_PLL1_HS_193MHZ;
>> + pll2 = CRT_PLL2_HS_193MHZ;
>> + } else /* default to VGA clock */ {
>> + pll1 = CRT_PLL1_HS_25MHZ;
>> + pll2 = CRT_PLL2_HS_25MHZ;
>> + }
>
> This seems like something that should be checked in atomic_check so
> you can be sure the mode is supported.
>
> It would also be nice to pull this out into a separate function (and a
> lookup table if you're feeling adventurous)
a lookup table seems good, thanks.
>
>> +
>> + writel(pll2, hidev->mmio + CRT_PLL2_HS);
>> + set_vclock_hisilicon(dev, pll1);
>> +
>> + /* Hisilicon has to set up the top-left and bottom-right
>> + * registers as well.
>> + * Note that normal chip only use those two register for
>> + * auto-centering mode.
>> + */
>> + writel((HIBMC_CRT_AUTO_CENTERING_TL_TOP(0) &
>> + HIBMC_CRT_AUTO_CENTERING_TL_TOP_MSK) |
>> + (HIBMC_CRT_AUTO_CENTERING_TL_LEFT(0) &
>> + HIBMC_CRT_AUTO_CENTERING_TL_LEFT_MSK),
>> + hidev->mmio + HIBMC_CRT_AUTO_CENTERING_TL);
>> +
>> + writel((HIBMC_CRT_AUTO_CENTERING_BR_BOTTOM(y - 1) &
>> + HIBMC_CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
>> + (HIBMC_CRT_AUTO_CENTERING_BR_RIGHT(x - 1) &
>> + HIBMC_CRT_AUTO_CENTERING_BR_RIGHT_MASK),
>> + hidev->mmio + HIBMC_CRT_AUTO_CENTERING_BR);
>> +
>> + /* Assume common fields in ctrl have been properly set before
>> + * calling this function.
>> + * This function only sets the extra fields in ctrl.
>> + */
>> +
>> + /* Set bit 25 of display controller: Select CRT or VGA clock */
>> + ctrl &= ~HIBMC_CRT_DISP_CTL_CRTSELECT_MASK;
>> + ctrl &= ~HIBMC_CRT_DISP_CTL_CLOCK_PHASE_MASK;
>> +
>> + ctrl |= HIBMC_CRT_DISP_CTL_CRTSELECT(CRTSELECT_CRT);
>> +
>> + /*ctrl = FIELD_SET(ctrl, HIBMC_CRT_DISP_CTL, CRTSELECT, CRT);*/
>
> What's the deal with this commented code?
sorry, will clean up.
>
>> +
>> + /* Set bit 14 of display controller */
>> + /*ctrl &= FIELD_CLEAR(HIBMC_CRT_DISP_CTL, CLOCK_PHASE);*/
>> +
>> + /* clock_phase_polarity is 0 */
>> + ctrl |= HIBMC_CRT_DISP_CTL_CLOCK_PHASE(PHASE_ACTIVE_HIGH);
>> + /*ctrl = FIELD_SET(ctrl, HIBMC_CRT_DISP_CTL,*/
>> + /*CLOCK_PHASE, ACTIVE_HIGH);*/
>
> Here too...
ditto.
>
>> +
>> + writel(ctrl, hidev->mmio + HIBMC_CRT_DISP_CTL);
>> +
>> + return ctrl;
>> +}
>> +
>> +static void hibmc_crtc_mode_set_nofb(struct drm_crtc *crtc)
>> +{
>> + unsigned int val;
>> + struct drm_display_mode *mode = &crtc->state->mode;
>> + struct drm_device *dev = crtc->dev;
>> + struct hibmc_drm_device *hidev = dev->dev_private;
>> +
>> + writel(format_pll_reg(), hidev->mmio + HIBMC_CRT_PLL_CTRL);
>> + writel((HIBMC_CRT_HORZ_TOTAL_TOTAL(mode->htotal - 1) &
>> + HIBMC_CRT_HORZ_TOTAL_TOTAL_MASK) |
>> + (HIBMC_CRT_HORZ_TOTAL_DISPLAY_END(mode->hdisplay - 1) &
>> + HIBMC_CRT_HORZ_TOTAL_DISPLAY_END_MASK),
>
> You could probably macroize this code to make it more readable
#define HIBMC_FIELD(field, value) (field(value) & filed##_MASK)
writel(HIBMC_FIELD(HIBMC_CRT_HORZ_TOTAL_TOTAL, mode->htotal - 1) |
HIBMC_FIELD(HIBMC_CRT_HORZ_TOTAL_DISPLAY_END, mode->hdisplay - 1),
hidev->mmio + HIBMC_CRT_HORZ_TOTAL);
Is above ok?
>
>> + hidev->mmio + HIBMC_CRT_HORZ_TOTAL);
>> +
>> + writel((HIBMC_CRT_HORZ_SYNC_WIDTH(mode->hsync_end - mode->hsync_start)
>> + & HIBMC_CRT_HORZ_SYNC_WIDTH_MASK) |
>> + (HIBMC_CRT_HORZ_SYNC_START(mode->hsync_start - 1)
>> + & HIBMC_CRT_HORZ_SYNC_START_MASK),
>> + hidev->mmio + HIBMC_CRT_HORZ_SYNC);
>> +
>> + writel((HIBMC_CRT_VERT_TOTAL_TOTAL(mode->vtotal - 1) &
>> + HIBMC_CRT_VERT_TOTAL_TOTAL_MASK) |
>> + (HIBMC_CRT_VERT_TOTAL_DISPLAY_END(mode->vdisplay - 1) &
>> + HIBMC_CRT_VERT_TOTAL_DISPLAY_END_MASK),
>> + hidev->mmio + HIBMC_CRT_VERT_TOTAL);
>> +
>> + writel((HIBMC_CRT_VERT_SYNC_HEIGHT(mode->vsync_end - mode->vsync_start)
>> + & HIBMC_CRT_VERT_SYNC_HEIGHT_MASK) |
>> + (HIBMC_CRT_VERT_SYNC_START(mode->vsync_start - 1) &
>> + HIBMC_CRT_VERT_SYNC_START_MASK),
>> + hidev->mmio + HIBMC_CRT_VERT_SYNC);
>> +
>> + val = HIBMC_CRT_DISP_CTL_VSYNC_PHASE(0) &
>> + HIBMC_CRT_DISP_CTL_VSYNC_PHASE_MASK;
>> + val |= HIBMC_CRT_DISP_CTL_HSYNC_PHASE(0) &
>> + HIBMC_CRT_DISP_CTL_HSYNC_PHASE_MASK;
>> + val |= HIBMC_CRT_DISP_CTL_TIMING(ENABLE);
>> + val |= HIBMC_CRT_DISP_CTL_PLANE(ENABLE);
>> +
>> + display_ctrl_adjust(dev, mode, val);
>> +}
>> +
>> +static void hibmc_crtc_atomic_begin(struct drm_crtc *crtc,
>> + struct drm_crtc_state *old_state)
>> +{
>> + unsigned int reg;
>> + struct drm_device *dev = crtc->dev;
>> + struct hibmc_drm_device *hidev = dev->dev_private;
>> +
>> + hibmc_set_power_mode(hidev, HIBMC_PW_MODE_CTL_MODE_MODE0);
>> +
>> + /* Enable display power gate & LOCALMEM power gate*/
>> + reg = readl(hidev->mmio + HIBMC_CURRENT_GATE);
>> + reg &= ~HIBMC_CURR_GATE_DISPLAY_MASK;
>> + reg &= ~HIBMC_CURR_GATE_LOCALMEM_MASK;
>> + reg |= HIBMC_CURR_GATE_DISPLAY(ON);
>> + reg |= HIBMC_CURR_GATE_LOCALMEM(ON);
>> + hibmc_set_current_gate(hidev, reg);
>> +
>> + /* We can add more initialization as needed. */
>> +}
>> +
>> +static void hibmc_crtc_atomic_flush(struct drm_crtc *crtc,
>> + struct drm_crtc_state *old_state)
>> +
>> +{
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&crtc->dev->event_lock, flags);
>> + if (crtc->state->event)
>> + drm_crtc_send_vblank_event(crtc, crtc->state->event);
>> + crtc->state->event = NULL;
>> +
>> + spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
>> +}
>> +
>> +/* These provide the minimum set of functions required to handle a CRTC */
>
> nit: don't need this comment
will delete, thanks.
>
>> +static const struct drm_crtc_funcs hibmc_crtc_funcs = {
>> + .page_flip = drm_atomic_helper_page_flip,
>> + .set_config = drm_atomic_helper_set_config,
>> + .destroy = drm_crtc_cleanup,
>> + .reset = drm_atomic_helper_crtc_reset,
>> + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
>> + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
>> +};
>> +
>> +static const struct drm_crtc_helper_funcs hibmc_crtc_helper_funcs = {
>> + .enable = hibmc_crtc_enable,
>> + .disable = hibmc_crtc_disable,
>> + .mode_set_nofb = hibmc_crtc_mode_set_nofb,
>> + .atomic_check = hibmc_crtc_atomic_check,
>> + .atomic_begin = hibmc_crtc_atomic_begin,
>> + .atomic_flush = hibmc_crtc_atomic_flush,
>> +};
>> +
>> +int hibmc_crtc_init(struct hibmc_drm_device *hidev)
>> +{
>> + struct drm_device *dev = hidev->dev;
>> + struct drm_crtc *crtc = &hidev->crtc;
>> + struct drm_plane *plane = &hidev->plane;
>> + int ret;
>> +
>> + ret = drm_crtc_init_with_planes(dev, crtc, plane,
>> + NULL, &hibmc_crtc_funcs, NULL);
>> + if (ret) {
>> + DRM_ERROR("failed to init crtc.\n");
>
> print return code
agreed, thanks.
>
>> + return ret;
>> + }
>> +
>> + drm_mode_crtc_set_gamma_size(crtc, 256);
>
> check return code
agreed though none of other drivers has done this,
thanks.
>
>> + drm_crtc_helper_add(crtc, &hibmc_crtc_helper_funcs);
>> + return 0;
>> +}
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index 7d96583..303cd36 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -119,6 +119,12 @@ static int hibmc_kms_init(struct hibmc_drm_device *hidev)
>> return ret;
>> }
>>
>> + ret = hibmc_crtc_init(hidev);
>> + if (ret) {
>> + DRM_ERROR("failed to init crtc.\n");
>> + return ret;
>> + }
>
> Typically the plane is initialized internally in the crtc driver. I
> think this is a good design pattern, and you should probably use it.
>
> So how about squashing this down with the plane patch and keeping the
> plane inside hibmc_drm_de.c?
understood after i looked at intel_display.c, this file will be merged
with patch 4/9, and the tile will be: 'drm/hisilicon/hibmc: Add display
engine'.
>
>> +
>> return 0;
>> }
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 49e39d2..5731ec2 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -46,6 +46,7 @@ struct hibmc_drm_device {
>> /* drm */
>> struct drm_device *dev;
>> struct drm_plane plane;
>
> I don't think you should be keeping track of plane here. plane is only
> used in the crtc init, which should be addressed by the previous
> comment.
so allocate with devm_kzalloc(sizeof(*plane)) and remove it from
hibmc_drm_device?
>
>
>> + struct drm_crtc crtc;
>
> crtc is only used in the irq handler, so you could remove this here
> and just call drm_handle_vblank(dev, 0) in the handler.
so allocate with devm_kzalloc(sizeof(*crtc)) and remove it from
hibmc_drm_device, when driver unload drm_crtc_cleanup() will be
called and finally memory will be freed before quit.
>
>
>> bool mode_config_initialized;
>>
>> /* ttm */
>> @@ -85,6 +86,7 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
>> #define DRM_FILE_PAGE_OFFSET (0x100000000ULL >> PAGE_SHIFT)
>>
>> int hibmc_plane_init(struct hibmc_drm_device *hidev);
>> +int hibmc_crtc_init(struct hibmc_drm_device *hidev);
>> int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
>> void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>>
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> _______________________________________________
> linuxarm mailing list
> linuxarm at huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>
--
Regards, Rongrong
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Jacek Anaszewski @ 2016-11-12 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d7ddbbb0-b99c-14a3-f462-3534b5ec67e6@redhat.com>
Hi,
On 11/11/2016 08:28 PM, Hans de Goede wrote:
> Hi,
>
> On 11-11-16 18:03, Jacek Anaszewski wrote:
>> On 11/11/2016 01:01 PM, Pavel Machek wrote:
>>> On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote:
>>>> Hi,
>>>>
>>>> On 11/10/2016 09:29 PM, Pavel Machek wrote:
>>>>> On Thu 2016-11-10 10:55:37, Tony Lindgren wrote:
>>>>>> * Pavel Machek <pavel@ucw.cz> [161110 09:29]:
>>>>>>> Hi!
>>>>>>>
>>>>>>>>>>> Looks like commit 883d32ce3385 ("leds: core: Add support for
>>>>>>>>>>> poll()ing
>>>>>>>>>>> the sysfs brightness attr for changes.") breaks runtime PM
>>>>>>>>>>> for me.
>>>>>>>>>>>
>>>>>>>>>>> On my omap dm3730 based test system, idle power consumption
>>>>>>>>>>> is over 70
>>>>>>>>>>> times higher now with this patch! It goes from about 6mW for
>>>>>>>>>>> the core
>>>>>>>>>>> system to over 440mW during idle meaning there's some busy
>>>>>>>>>>> timer now
>>>>>>>>>>> active.
>>>>>>>>>>>
>>>>>>>>>>> Reverting this patch fixes the issue. Any ideas?
>>>>>>>
>>>>>>> Are you using any LED that toggles with high frequency? Like perhaps
>>>>>>> LED that is lit when CPU is active?
>>>>>>
>>>>>> Yeah one of them seems to have cpu0 as the default trigger.
>>>>>
>>>>> Aha. Its quite obvious we don't want to notify sysfs each time that
>>>>> one is toggled, right?
>>>>>
>>>>> IMO brightness should display max brightness for the trigger, as Hans
>>>>> suggested, anything else is madness for trigger such as cpu activity.
>>>>
>>>> Are you suggesting that we should revert changes introduced
>>>> by below patch?
>>>>
>>>> commit 29d76dfa29fe22583aefddccda0bc56aa81035dc
>>>> Author: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
>>>> Date: Tue Mar 18 09:47:48 2008 +0000
>>>>
>>>> leds: Add support to leds with readable status
>>>>
>>>> Some led hardware allows drivers to query the led state, and
>>>> this patch
>>>> adds a hook to let the led class take advantage of that
>>>> information when
>>>> available.
>>>>
>>>> Without this functionality, when access to the led hardware is not
>>>> exclusive (i.e. firmware or hardware might change its state
>>>> behind the
>>>> kernel's back), reality goes out of sync with the led class'
>>>> idea of
>>>> what
>>>> the led is doing, which is annoying at best.
>>>
>>> Hmm. So userland can read the LED state, and it can get _some_ value
>>> back, but it can not know if it is current state or not.
>>>
>>> I don't think that's a good interface. I see it is from 2008... is
>>> someone using it? Maybe it is too late for revert.
>>
>> I can imagine it being used in flash LED use case. E.g. one
>> could use oneshot trigger to trigger flash strobe, and then
>> he could periodically read brightness file to check, for whatever
>> reason, whether the flash is strobing.
>>
>>> But I'd certainly not extend it with poll.
>>
>> We could add a dedicated file e.g. hw_brightness_change for that
>> (maybe someone will have a better candidate for the file name).
>
> Why a dedicated file? Are we going to mirror brightness here
> wrt r/w (show/store) behavior ? If not userspace now needs
> 2 open fds which is not really nice. If we are and we are
> not going to use poll for something else on brightness itself
> then why not just poll directly on brightness ?
My main concern is that reporting only hw brightness changes
wouldn't be consistent with general brightness file purpose.
One could expect that brightness changes made by triggers
should be also reported.
I'd make it only readable, so it wouldn't mirror brightness
file behavior.
Its purpose would be clear: notify hw brightness changes
and provide the brightness value that was set by the hardware
last time. It implies that this value could be different from
the one the brightness file reports. E.g. hw could have changed
brightness, which could be later updated through brightness
file, but hw_brightness_change would still report brightness level
that was set by the hardware last time. It could be useful
e.g. in case of showing the difference between the desired
value and the currently allowed configuration (e.g. if the
firmware automatically adjusted the value set by the user).
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-12 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4c31faef-144d-289c-0e32-83e76aff6178@gmail.com>
Hi,
On 12-11-16 11:24, Jacek Anaszewski wrote:
> Hi,
>
> On 11/11/2016 08:28 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 11-11-16 18:03, Jacek Anaszewski wrote:
>>> On 11/11/2016 01:01 PM, Pavel Machek wrote:
>>>> On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote:
>>>>> Hi,
>>>>>
>>>>> On 11/10/2016 09:29 PM, Pavel Machek wrote:
>>>>>> On Thu 2016-11-10 10:55:37, Tony Lindgren wrote:
>>>>>>> * Pavel Machek <pavel@ucw.cz> [161110 09:29]:
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>>>>>> Looks like commit 883d32ce3385 ("leds: core: Add support for
>>>>>>>>>>>> poll()ing
>>>>>>>>>>>> the sysfs brightness attr for changes.") breaks runtime PM
>>>>>>>>>>>> for me.
>>>>>>>>>>>>
>>>>>>>>>>>> On my omap dm3730 based test system, idle power consumption
>>>>>>>>>>>> is over 70
>>>>>>>>>>>> times higher now with this patch! It goes from about 6mW for
>>>>>>>>>>>> the core
>>>>>>>>>>>> system to over 440mW during idle meaning there's some busy
>>>>>>>>>>>> timer now
>>>>>>>>>>>> active.
>>>>>>>>>>>>
>>>>>>>>>>>> Reverting this patch fixes the issue. Any ideas?
>>>>>>>>
>>>>>>>> Are you using any LED that toggles with high frequency? Like perhaps
>>>>>>>> LED that is lit when CPU is active?
>>>>>>>
>>>>>>> Yeah one of them seems to have cpu0 as the default trigger.
>>>>>>
>>>>>> Aha. Its quite obvious we don't want to notify sysfs each time that
>>>>>> one is toggled, right?
>>>>>>
>>>>>> IMO brightness should display max brightness for the trigger, as Hans
>>>>>> suggested, anything else is madness for trigger such as cpu activity.
>>>>>
>>>>> Are you suggesting that we should revert changes introduced
>>>>> by below patch?
>>>>>
>>>>> commit 29d76dfa29fe22583aefddccda0bc56aa81035dc
>>>>> Author: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
>>>>> Date: Tue Mar 18 09:47:48 2008 +0000
>>>>>
>>>>> leds: Add support to leds with readable status
>>>>>
>>>>> Some led hardware allows drivers to query the led state, and
>>>>> this patch
>>>>> adds a hook to let the led class take advantage of that
>>>>> information when
>>>>> available.
>>>>>
>>>>> Without this functionality, when access to the led hardware is not
>>>>> exclusive (i.e. firmware or hardware might change its state
>>>>> behind the
>>>>> kernel's back), reality goes out of sync with the led class'
>>>>> idea of
>>>>> what
>>>>> the led is doing, which is annoying at best.
>>>>
>>>> Hmm. So userland can read the LED state, and it can get _some_ value
>>>> back, but it can not know if it is current state or not.
>>>>
>>>> I don't think that's a good interface. I see it is from 2008... is
>>>> someone using it? Maybe it is too late for revert.
>>>
>>> I can imagine it being used in flash LED use case. E.g. one
>>> could use oneshot trigger to trigger flash strobe, and then
>>> he could periodically read brightness file to check, for whatever
>>> reason, whether the flash is strobing.
>>>
>>>> But I'd certainly not extend it with poll.
>>>
>>> We could add a dedicated file e.g. hw_brightness_change for that
>>> (maybe someone will have a better candidate for the file name).
>>
>> Why a dedicated file? Are we going to mirror brightness here
>> wrt r/w (show/store) behavior ? If not userspace now needs
>> 2 open fds which is not really nice. If we are and we are
>> not going to use poll for something else on brightness itself
>> then why not just poll directly on brightness ?
>
> My main concern is that reporting only hw brightness changes
> wouldn't be consistent with general brightness file purpose.
> One could expect that brightness changes made by triggers
> should be also reported.
Ok, I agree that not notifying poll() while an actual
read() would result in a different value is not really good
semantics.
I don't like to call it hw_brightness_change though, as
mentioned before I believe that if we were to start with
a clean slate we would make the brightness file's read/write
behavior more a mirror of itself.
So I would like to propose creating a new read-write
user_brightness file.
The write behavior would be 100% identical to the brightness
file (in code terms it will call the same store function).
The the read behavior otoh will be different: it will shows
the last brightness as set by the user, this would show the
read behavior we really want of brightness: show the real
brightness when not blinking / triggers are active and show
the brightness used when on when blinking / triggers are active.
We could then add poll support on this new user_brightness
file, thus avoiding the problem with the extra cpu-load on
notifications on blinking / triggers.
> I'd make it only readable, so it wouldn't mirror brightness
> file behavior.
Then userspace which wants to be able to read + write + poll
the brightness again needs to open 2 fds, as suggested
above for the new user_brightness file it will be easy
to just make it mimic the brightness file write behavior
and then userspace only needs to open one fd.
Regards,
Hans
>
> Its purpose would be clear: notify hw brightness changes
> and provide the brightness value that was set by the hardware
> last time. It implies that this value could be different from
> the one the brightness file reports. E.g. hw could have changed
> brightness, which could be later updated through brightness
> file, but hw_brightness_change would still report brightness level
> that was set by the hardware last time. It could be useful
> e.g. in case of showing the difference between the desired
> value and the currently allowed configuration (e.g. if the
> firmware automatically adjusted the value set by the user).
>
^ permalink raw reply
* [PATCH v6 6/9] drm/hisilicon/hibmc: Add encoder for VDAC
From: Rongrong Zou @ 2016-11-12 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOw6vbKZ5kRbWPOep8soyMWp+Y14eFYALYiUhyyy04yGgMjQgQ@mail.gmail.com>
? 2016/11/11 6:20, Sean Paul ??:
> On Fri, Oct 28, 2016 at 3:27 AM, Rongrong Zou <zourongrong@gmail.com> wrote:
>> Add encoder funcs and helpers for VDAC.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 ++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 89 ++++++++++++++++++++++++
>> 4 files changed, 98 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> index 72e107e..e04f114 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> @@ -1,5 +1,5 @@
>> ccflags-y := -Iinclude/drm
>> -hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_fbdev.o hibmc_drm_power.o hibmc_ttm.o
>> +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_drm_fbdev.o hibmc_drm_power.o hibmc_ttm.o
>>
>> obj-$(CONFIG_DRM_HISI_HIBMC) +=hibmc-drm.o
>> #obj-y += hibmc-drm.o
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index 303cd36..ba191e1 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -125,6 +125,12 @@ static int hibmc_kms_init(struct hibmc_drm_device *hidev)
>> return ret;
>> }
>>
>> + ret = hibmc_encoder_init(hidev);
>> + if (ret) {
>> + DRM_ERROR("failed to init encoder\n");
>> + return ret;
>> + }
>> +
>> return 0;
>> }
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 5731ec2..401cea4 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -47,6 +47,7 @@ struct hibmc_drm_device {
>> struct drm_device *dev;
>> struct drm_plane plane;
>> struct drm_crtc crtc;
>> + struct drm_encoder encoder;
>
> Same comment here, you don't need to keep track of this
ok, it can be dealt with like crtc.
>
>> bool mode_config_initialized;
>>
>> /* ttm */
>> @@ -87,6 +88,7 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
>>
>> int hibmc_plane_init(struct hibmc_drm_device *hidev);
>> int hibmc_crtc_init(struct hibmc_drm_device *hidev);
>> +int hibmc_encoder_init(struct hibmc_drm_device *hidev);
>> int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
>> void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> new file mode 100644
>> index 0000000..953f659
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> @@ -0,0 +1,89 @@
>> +/* Hisilicon Hibmc SoC drm driver
>> + *
>> + * Based on the bochs drm driver.
>> + *
>> + * Copyright (c) 2016 Huawei Limited.
>> + *
>> + * Author:
>> + * Rongrong Zou <zourongrong@huawei.com>
>> + * Rongrong Zou <zourongrong@gmail.com>
>> + * Jianhua Li <lijianhua@huawei.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + */
>> +
>> +#include <drm/drm_atomic_helper.h>
>> +#include <drm/drm_crtc_helper.h>
>> +
>> +#include "hibmc_drm_drv.h"
>> +#include "hibmc_drm_regs.h"
>> +
>> +static int defx = 800;
>> +static int defy = 600;
>> +
>> +module_param(defx, int, 0444);
>> +module_param(defy, int, 0444);
>> +MODULE_PARM_DESC(defx, "default x resolution");
>> +MODULE_PARM_DESC(defy, "default y resolution");
>
> Not used, and I'm not sure these are a good idea
it is used in following patch, i think it is put in wrong place.
>
>> +
>> +static void hibmc_encoder_disable(struct drm_encoder *encoder)
>> +{
>> +}
>> +
>> +static void hibmc_encoder_enable(struct drm_encoder *encoder)
>> +{
>> +}
>
> Null-checked, no need to stub
thanks for pointing it out.
>
>> +
>> +static void hibmc_encoder_mode_set(struct drm_encoder *encoder,
>> + struct drm_display_mode *mode,
>> + struct drm_display_mode *adj_mode)
>> +{
>> + u32 reg;
>> + struct drm_device *dev = encoder->dev;
>> + struct hibmc_drm_device *hidev = dev->dev_private;
>> +
>> + /* just open DISPLAY_CONTROL_HISILE register bit 3:0*/
>> + reg = readl(hidev->mmio + DISPLAY_CONTROL_HISILE);
>> + reg |= 0xf;
>
> Can you just pull this into a #define instead of explaining in the comment?
ok, thanks.
>
>> + writel(reg, hidev->mmio + DISPLAY_CONTROL_HISILE);
>> +}
>> +
>> +static int hibmc_encoder_atomic_check(struct drm_encoder *encoder,
>> + struct drm_crtc_state *crtc_state,
>> + struct drm_connector_state *conn_state)
>> +{
>> + return 0;
>> +}
>
> null-checked, remove stub
ok, will do.
>
>> +
>> +static const struct drm_encoder_helper_funcs hibmc_encoder_helper_funcs = {
>> + .mode_set = hibmc_encoder_mode_set,
>> + .disable = hibmc_encoder_disable,
>> + .enable = hibmc_encoder_enable,
>> + .atomic_check = hibmc_encoder_atomic_check,
>> +};
>> +
>> +static const struct drm_encoder_funcs hibmc_encoder_encoder_funcs = {
>> + .destroy = drm_encoder_cleanup,
>> +};
>> +
>> +int hibmc_encoder_init(struct hibmc_drm_device *hidev)
>> +{
>> + struct drm_device *dev = hidev->dev;
>> + struct drm_encoder *encoder = &hidev->encoder;
>> + int ret;
>> +
>> + encoder->possible_crtcs = 0x1;
>> + ret = drm_encoder_init(dev, encoder, &hibmc_encoder_encoder_funcs,
>> + DRM_MODE_ENCODER_DAC, NULL);
>> + if (ret) {
>> + DRM_ERROR("failed to init encoder\n");
>
> print ret
will do, thanks.
>
>> + return ret;
>> + }
>> +
>> + drm_encoder_helper_add(encoder, &hibmc_encoder_helper_funcs);
>> + return 0;
>> +}
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> _______________________________________________
> linuxarm mailing list
> linuxarm at huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>
--
Regards, Rongrong
^ permalink raw reply
* [PATCH] mfd: twl-core: export twl_get_regmap
From: Nicolae Rosia @ 2016-11-12 11:38 UTC (permalink / raw)
To: linux-arm-kernel
We want to get rid of global twl_i2c_{write/read}.
As a first step, allow clients to get the regmap and write directly
Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
---
drivers/mfd/twl-core.c | 3 ++-
include/linux/i2c/twl.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index c64615d..49e6a4b 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -421,7 +421,7 @@ EXPORT_SYMBOL(twl_rev);
*
* Returns the regmap pointer or NULL in case of failure.
*/
-static struct regmap *twl_get_regmap(u8 mod_no)
+struct regmap *twl_get_regmap(u8 mod_no)
{
int sid;
struct twl_client *twl;
@@ -440,6 +440,7 @@ static struct regmap *twl_get_regmap(u8 mod_no)
return twl->regmap;
}
+EXPORT_SYMBOL(twl_get_regmap);
/**
* twl_i2c_write - Writes a n bit register in TWL4030/TWL5030/TWL60X0
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 9ad7828..4c43cdb3 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -174,6 +174,8 @@ static inline int twl_class_is_ ##class(void) \
TWL_CLASS_IS(4030, TWL4030_CLASS_ID)
TWL_CLASS_IS(6030, TWL6030_CLASS_ID)
+struct regmap *twl_get_regmap(u8 mod_no);
+
/* Set the regcache bypass for the regmap associated with the nodule */
int twl_set_regcache_bypass(u8 mod_no, bool enable);
--
2.5.5
^ permalink raw reply related
* [PATCH 1/3] clk: Hi6220: enable stub clock driver for ARCH_HISI
From: Leo Yan @ 2016-11-12 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160831224049.GK12510@codeaurora.org>
Hi Stephen,
On Wed, Aug 31, 2016 at 03:40:49PM -0700, Stephen Boyd wrote:
> On 08/31, Leo Yan wrote:
> > In current kernel config 'CONFIG_STUB_CLK_HI6220' is disabled by
> > default, as result stub clock driver has not been registered and
> > CPUFreq driver cannot work.
> >
> > This patch is to enable stub clock driver in config for ARCH_HISI.
> >
> > Reported-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > ---
>
> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
We found this patch is missed mainline kernel. So could you help pick
it? Or do you need me resend this patch?
Thanks,
Leo Yan
^ permalink raw reply
* [PATCH] mfd: twl-core: make driver DT only
From: Nicolae Rosia @ 2016-11-12 12:02 UTC (permalink / raw)
To: linux-arm-kernel
All users are DT-only and it makes no sense to keep
unused code
Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
---
drivers/mfd/Kconfig | 1 +
drivers/mfd/twl-core.c | 395 ++-----------------------------------------------
2 files changed, 10 insertions(+), 386 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c6df644..c180f8b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1333,6 +1333,7 @@ config MFD_TPS80031
config TWL4030_CORE
bool "TI TWL4030/TWL5030/TWL6030/TPS659x0 Support"
depends on I2C=y
+ depends on OF
select IRQ_DOMAIN
select REGMAP_I2C
help
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index c64615d..2025326 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -13,6 +13,9 @@
* Code cleanup and modifications to IRQ handler.
* by syed khasim <x0khasim@ti.com>
*
+ * Code cleanup and modifications:
+ * Copyright (C) 2016 Nicolae Rosia <nicolae.rosia@gmail.com>
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -604,376 +607,6 @@ int twl_get_hfclk_rate(void)
}
EXPORT_SYMBOL_GPL(twl_get_hfclk_rate);
-static struct device *
-add_numbered_child(unsigned mod_no, const char *name, int num,
- void *pdata, unsigned pdata_len,
- bool can_wakeup, int irq0, int irq1)
-{
- struct platform_device *pdev;
- struct twl_client *twl;
- int status, sid;
-
- if (unlikely(mod_no >= twl_get_last_module())) {
- pr_err("%s: invalid module number %d\n", DRIVER_NAME, mod_no);
- return ERR_PTR(-EPERM);
- }
- sid = twl_priv->twl_map[mod_no].sid;
- twl = &twl_priv->twl_modules[sid];
-
- pdev = platform_device_alloc(name, num);
- if (!pdev)
- return ERR_PTR(-ENOMEM);
-
- pdev->dev.parent = &twl->client->dev;
-
- if (pdata) {
- status = platform_device_add_data(pdev, pdata, pdata_len);
- if (status < 0) {
- dev_dbg(&pdev->dev, "can't add platform_data\n");
- goto put_device;
- }
- }
-
- if (irq0) {
- struct resource r[2] = {
- { .start = irq0, .flags = IORESOURCE_IRQ, },
- { .start = irq1, .flags = IORESOURCE_IRQ, },
- };
-
- status = platform_device_add_resources(pdev, r, irq1 ? 2 : 1);
- if (status < 0) {
- dev_dbg(&pdev->dev, "can't add irqs\n");
- goto put_device;
- }
- }
-
- status = platform_device_add(pdev);
- if (status)
- goto put_device;
-
- device_init_wakeup(&pdev->dev, can_wakeup);
-
- return &pdev->dev;
-
-put_device:
- platform_device_put(pdev);
- dev_err(&twl->client->dev, "failed to add device %s\n", name);
- return ERR_PTR(status);
-}
-
-static inline struct device *add_child(unsigned mod_no, const char *name,
- void *pdata, unsigned pdata_len,
- bool can_wakeup, int irq0, int irq1)
-{
- return add_numbered_child(mod_no, name, -1, pdata, pdata_len,
- can_wakeup, irq0, irq1);
-}
-
-static struct device *
-add_regulator_linked(int num, struct regulator_init_data *pdata,
- struct regulator_consumer_supply *consumers,
- unsigned num_consumers, unsigned long features)
-{
- struct twl_regulator_driver_data drv_data;
-
- /* regulator framework demands init_data ... */
- if (!pdata)
- return NULL;
-
- if (consumers) {
- pdata->consumer_supplies = consumers;
- pdata->num_consumer_supplies = num_consumers;
- }
-
- if (pdata->driver_data) {
- /* If we have existing drv_data, just add the flags */
- struct twl_regulator_driver_data *tmp;
- tmp = pdata->driver_data;
- tmp->features |= features;
- } else {
- /* add new driver data struct, used only during init */
- drv_data.features = features;
- drv_data.set_voltage = NULL;
- drv_data.get_voltage = NULL;
- drv_data.data = NULL;
- pdata->driver_data = &drv_data;
- }
-
- /* NOTE: we currently ignore regulator IRQs, e.g. for short circuits */
- return add_numbered_child(TWL_MODULE_PM_MASTER, "twl_reg", num,
- pdata, sizeof(*pdata), false, 0, 0);
-}
-
-static struct device *
-add_regulator(int num, struct regulator_init_data *pdata,
- unsigned long features)
-{
- return add_regulator_linked(num, pdata, NULL, 0, features);
-}
-
-/*
- * NOTE: We know the first 8 IRQs after pdata->base_irq are
- * for the PIH, and the next are for the PWR_INT SIH, since
- * that's how twl_init_irq() sets things up.
- */
-
-static int
-add_children(struct twl4030_platform_data *pdata, unsigned irq_base,
- unsigned long features)
-{
- struct device *child;
-
- if (IS_ENABLED(CONFIG_GPIO_TWL4030) && pdata->gpio) {
- child = add_child(TWL4030_MODULE_GPIO, "twl4030_gpio",
- pdata->gpio, sizeof(*pdata->gpio),
- false, irq_base + GPIO_INTR_OFFSET, 0);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- if (IS_ENABLED(CONFIG_KEYBOARD_TWL4030) && pdata->keypad) {
- child = add_child(TWL4030_MODULE_KEYPAD, "twl4030_keypad",
- pdata->keypad, sizeof(*pdata->keypad),
- true, irq_base + KEYPAD_INTR_OFFSET, 0);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- if (IS_ENABLED(CONFIG_TWL4030_MADC) && pdata->madc &&
- twl_class_is_4030()) {
- child = add_child(TWL4030_MODULE_MADC, "twl4030_madc",
- pdata->madc, sizeof(*pdata->madc),
- true, irq_base + MADC_INTR_OFFSET, 0);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- if (IS_ENABLED(CONFIG_RTC_DRV_TWL4030)) {
- /*
- * REVISIT platform_data here currently might expose the
- * "msecure" line ... but for now we just expect board
- * setup to tell the chip "it's always ok to SET_TIME".
- * Eventually, Linux might become more aware of such
- * HW security concerns, and "least privilege".
- */
- child = add_child(TWL_MODULE_RTC, "twl_rtc", NULL, 0,
- true, irq_base + RTC_INTR_OFFSET, 0);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- if (IS_ENABLED(CONFIG_PWM_TWL)) {
- child = add_child(TWL_MODULE_PWM, "twl-pwm", NULL, 0,
- false, 0, 0);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- if (IS_ENABLED(CONFIG_PWM_TWL_LED)) {
- child = add_child(TWL_MODULE_LED, "twl-pwmled", NULL, 0,
- false, 0, 0);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- if (IS_ENABLED(CONFIG_TWL4030_USB) && pdata->usb &&
- twl_class_is_4030()) {
-
- static struct regulator_consumer_supply usb1v5 = {
- .supply = "usb1v5",
- };
- static struct regulator_consumer_supply usb1v8 = {
- .supply = "usb1v8",
- };
- static struct regulator_consumer_supply usb3v1 = {
- .supply = "usb3v1",
- };
-
- /* First add the regulators so that they can be used by transceiver */
- if (IS_ENABLED(CONFIG_REGULATOR_TWL4030)) {
- /* this is a template that gets copied */
- struct regulator_init_data usb_fixed = {
- .constraints.valid_modes_mask =
- REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .constraints.valid_ops_mask =
- REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- };
-
- child = add_regulator_linked(TWL4030_REG_VUSB1V5,
- &usb_fixed, &usb1v5, 1,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator_linked(TWL4030_REG_VUSB1V8,
- &usb_fixed, &usb1v8, 1,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator_linked(TWL4030_REG_VUSB3V1,
- &usb_fixed, &usb3v1, 1,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- }
-
- child = add_child(TWL_MODULE_USB, "twl4030_usb",
- pdata->usb, sizeof(*pdata->usb), true,
- /* irq0 = USB_PRES, irq1 = USB */
- irq_base + USB_PRES_INTR_OFFSET,
- irq_base + USB_INTR_OFFSET);
-
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- /* we need to connect regulators to this transceiver */
- if (IS_ENABLED(CONFIG_REGULATOR_TWL4030) && child) {
- usb1v5.dev_name = dev_name(child);
- usb1v8.dev_name = dev_name(child);
- usb3v1.dev_name = dev_name(child);
- }
- }
-
- if (IS_ENABLED(CONFIG_TWL4030_WATCHDOG) && twl_class_is_4030()) {
- child = add_child(TWL_MODULE_PM_RECEIVER, "twl4030_wdt", NULL,
- 0, false, 0, 0);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- if (IS_ENABLED(CONFIG_INPUT_TWL4030_PWRBUTTON) && twl_class_is_4030()) {
- child = add_child(TWL_MODULE_PM_MASTER, "twl4030_pwrbutton",
- NULL, 0, true, irq_base + 8 + 0, 0);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- if (IS_ENABLED(CONFIG_MFD_TWL4030_AUDIO) && pdata->audio &&
- twl_class_is_4030()) {
- child = add_child(TWL4030_MODULE_AUDIO_VOICE, "twl4030-audio",
- pdata->audio, sizeof(*pdata->audio),
- false, 0, 0);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- /* twl4030 regulators */
- if (IS_ENABLED(CONFIG_REGULATOR_TWL4030) && twl_class_is_4030()) {
- child = add_regulator(TWL4030_REG_VPLL1, pdata->vpll1,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VIO, pdata->vio,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VDD1, pdata->vdd1,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VDD2, pdata->vdd2,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VMMC1, pdata->vmmc1,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VDAC, pdata->vdac,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator((features & TWL4030_VAUX2)
- ? TWL4030_REG_VAUX2_4030
- : TWL4030_REG_VAUX2,
- pdata->vaux2, features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VINTANA1, pdata->vintana1,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VINTANA2, pdata->vintana2,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VINTDIG, pdata->vintdig,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- /* maybe add LDOs that are omitted on cost-reduced parts */
- if (IS_ENABLED(CONFIG_REGULATOR_TWL4030) && !(features & TPS_SUBSET)
- && twl_class_is_4030()) {
- child = add_regulator(TWL4030_REG_VPLL2, pdata->vpll2,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VMMC2, pdata->vmmc2,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VSIM, pdata->vsim,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VAUX1, pdata->vaux1,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VAUX3, pdata->vaux3,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VAUX4, pdata->vaux4,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- if (IS_ENABLED(CONFIG_CHARGER_TWL4030) && pdata->bci &&
- !(features & (TPS_SUBSET | TWL5031))) {
- child = add_child(TWL_MODULE_MAIN_CHARGE, "twl4030_bci",
- pdata->bci, sizeof(*pdata->bci), false,
- /* irq0 = CHG_PRES, irq1 = BCI */
- irq_base + BCI_PRES_INTR_OFFSET,
- irq_base + BCI_INTR_OFFSET);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- if (IS_ENABLED(CONFIG_TWL4030_POWER) && pdata->power) {
- child = add_child(TWL_MODULE_PM_MASTER, "twl4030_power",
- pdata->power, sizeof(*pdata->power), false,
- 0, 0);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- return 0;
-}
-
-/*----------------------------------------------------------------------*/
-
/*
* These three functions initialize the on-chip clock framework,
* letting it generate the right frequencies for USB, MADC, and
@@ -1000,8 +633,7 @@ static inline int __init unprotect_pm_master(void)
return e;
}
-static void clocks_init(struct device *dev,
- struct twl4030_clock_init_data *clock)
+static void clocks_init(struct device *dev)
{
int e = 0;
struct clk *osc;
@@ -1031,8 +663,6 @@ static void clocks_init(struct device *dev,
}
ctrl |= HIGH_PERF_SQ;
- if (clock && clock->ck32k_lowpwr_enable)
- ctrl |= CK32K_LOWPWR_EN;
e |= unprotect_pm_master();
/* effect->MADC+USB ck en */
@@ -1080,7 +710,6 @@ static struct of_dev_auxdata twl_auxdata_lookup[] = {
static int
twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
- struct twl4030_platform_data *pdata = dev_get_platdata(&client->dev);
struct device_node *node = client->dev.of_node;
struct platform_device *pdev;
const struct regmap_config *twl_regmap_config;
@@ -1088,8 +717,8 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
int status;
unsigned i, num_slaves;
- if (!node && !pdata) {
- dev_err(&client->dev, "no platform data\n");
+ if (!node) {
+ dev_err(&client->dev, "no DT info\n");
return -EINVAL;
}
@@ -1177,7 +806,7 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
twl_priv->ready = true;
/* setup clock framework */
- clocks_init(&pdev->dev, pdata ? pdata->clock : NULL);
+ clocks_init(&pdev->dev);
/* read TWL IDCODE Register */
if (twl_class_is_4030()) {
@@ -1225,14 +854,8 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
TWL4030_DCDC_GLOBAL_CFG);
}
- if (node) {
- if (pdata)
- twl_auxdata_lookup[0].platform_data = pdata->gpio;
- status = of_platform_populate(node, NULL, twl_auxdata_lookup,
- &client->dev);
- } else {
- status = add_children(pdata, irq_base, id->driver_data);
- }
+ status = of_platform_populate(node, NULL, twl_auxdata_lookup,
+ &client->dev);
fail:
if (status < 0)
--
2.5.5
^ permalink raw reply related
* [PATCH 2/3] thermal: hisilicon: fix for dependency
From: Leo Yan @ 2016-11-12 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472633417-9330-3-git-send-email-leo.yan@linaro.org>
Hi Rui, Eduardo,
On Wed, Aug 31, 2016 at 04:50:16PM +0800, Leo Yan wrote:
> The thermal driver is standalone driver which is used to enable
> thermal sensors, so it can be used with any cooling device and
> should not bind with CPU cooling device driver.
>
> This original patch is suggested by Amit Kucheria; so it's to
> polish the dependency in Kconfig, and remove the dependency with
> CPU_THERMAL.
Could you help review this patch? Or need me resend this patch? Sorry
I have not tracked this patches well before, this is one missed
patch for 96board Hikey.
Thanks,
Leo Yan
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> drivers/thermal/Kconfig | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 2d702ca..91ebab3 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -177,8 +177,10 @@ config THERMAL_EMULATION
>
> config HISI_THERMAL
> tristate "Hisilicon thermal driver"
> - depends on (ARCH_HISI && CPU_THERMAL && OF) || COMPILE_TEST
> + depends on ARCH_HISI || COMPILE_TEST
> depends on HAS_IOMEM
> + depends on OF
> + default y
> help
> Enable this to plug hisilicon's thermal sensor driver into the Linux
> thermal framework. cpufreq is used as the cooling device to throttle
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Ard Biesheuvel @ 2016-11-12 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111195607.GB4457@arm.com>
On 11 November 2016 at 20:56, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Nov 11, 2016 at 09:51:13PM +0800, Ard Biesheuvel wrote:
>> This integrates both the accelerated scalar and the NEON implementations
>> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>>
>> Relative performance compared to the respective generic C versions:
>>
>> | SHA256-scalar | SHA256-NEON* | SHA512 |
>> ------------+-----------------+--------------+----------+
>> Cortex-A53 | 1.63x | 1.63x | 2.34x |
>> Cortex-A57 | 1.43x | 1.59x | 1.95x |
>> Cortex-A73 | 1.26x | 1.56x | ? |
>>
>> The core crypto code was authored by Andy Polyakov of the OpenSSL
>> project, in collaboration with whom the upstream code was adapted so
>> that this module can be built from the same version of sha512-armv8.pl.
>>
>> The version in this patch was taken from OpenSSL commit
>>
>> 866e505e0d66 sha/asm/sha512-armv8.pl: add NEON version of SHA256.
>>
>> * The core SHA algorithm is fundamentally sequential, but there is a
>> secondary transformation involved, called the schedule update, which
>> can be performed independently. The NEON version of SHA-224/SHA-256
>> only implements this part of the algorithm using NEON instructions,
>> the sequential part is always done using scalar instructions.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>
>> This supersedes the SHA-256-NEON-only patch I sent out about 6 weeks ago.
>>
>> Will, Catalin: note that this pulls in a .pl script, and adds a build rule
>> locally in arch/arm64/crypto to generate .S files on the fly from Perl
>> scripts. I will leave it to you to decide whether you are ok with this as
>> is, or whether you prefer .S_shipped files, in which case the Perl script
>> is only included as a reference (this is how we did it for arch/arm in the
>> past, but given that it adds about 3000 lines of generated code to the patch,
>> I think we may want to simply keep it as below)
>
> I think we should include the shipped files too. 3000 lines isn't that much
> in the grand scheme of things, and there will be people who complain about
> the unconditional perl dependency.
>
OK, fair enough. I will repost with the generated files included.
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and PWM nodes
From: Martin Blumenstingl @ 2016-11-12 13:07 UTC (permalink / raw)
To: linux-arm-kernel
All boards from the Tronsmart Vega S95 series are sharing similar MMC
based hardware.
sd_emmc_a is used to connect a Broadcom based SDIO wifi card (supported
by the brcmfmac driver). The 32.768KHz LPO clock for the wifi chip is
generated by PWM_E.
sd_emmc_b is routed to the SD-card. Unlike p20x there is no GPIO
regulator, meaning it only supports 3.3V (which seems to be hard-wired).
The eMMC chip is connected to sd_emmc_c and is implemented similar to
the meson-gxbb-p20x boards (meaning that hard-wired fixed regulators
are used).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
.../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 104 +++++++++++++++++++++
1 file changed, 104 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index e93221a..e59ad30 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -65,6 +65,39 @@
enable-active-high;
};
+ vcc_3v3: regulator-vcc_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vcc_1v8: regulator-vcc_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
+ };
+
+ wifi32k: wifi32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>,
+ <&gpio GPIOX_20 GPIO_ACTIVE_LOW>;
+ clocks = <&wifi32k>;
+ clock-names = "ext_clock";
+ };
};
&uart_AO {
@@ -102,3 +135,74 @@
&usb1 {
status = "okay";
};
+
+/* Wireless SDIO Module */
+&sd_emmc_a {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins &sdio_irq_pins>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <100000000>;
+
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&sdio_pwrseq>;
+
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&vcc_1v8>;
+
+ brcmf: bcrmf at 1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ };
+};
+
+/* SD card */
+&sd_emmc_b {
+ status = "okay";
+ pinctrl-0 = <&sdcard_pins>;
+ pinctrl-names = "default";
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <100000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+
+ vmmc-supply = <&vcc_3v3>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>;
+ pinctrl-names = "default";
+
+ bus-width = <8>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vcc_3v3>;
+ vmmcq-sumpply = <&vcc_1v8>;
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins>;
+ pinctrl-names = "default";
+ clocks = <&clkc CLKID_FCLK_DIV4>;
+ clock-names = "clkin0";
+};
--
2.10.2
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: Add level for cpu dt node for exynos7
From: Javier Martinez Canillas @ 2016-11-12 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478945832-1826-1-git-send-email-alim.akhtar@samsung.com>
Hello Alim,
On 11/12/2016 07:17 AM, Alim Akhtar wrote:
> This patch adds level for cpu dt node, so that these levels can be used
Do you mean s/level/label here? I'm asking because you are using level
consistently in the subject line and commit message but I'm not sure
what it means in this context.
> as a phandle whenever required. For example, adding a "interrupt-affinity"
> for arm pmu node.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> ---
The change looks good to me though.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: Add ARM PMU node for exynos7
From: Javier Martinez Canillas @ 2016-11-12 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478945832-1826-2-git-send-email-alim.akhtar@samsung.com>
Hello Alim,
On 11/12/2016 07:17 AM, Alim Akhtar wrote:
> This patch adds ARM Performance Monitor Unit dt node for exynos7.
> PMU provides various statistics on the operation of the CPU and
> memory system at runtime, which are very useful when debugging or
> profiling code. This enables the same.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> Changes since v1:
> * Added "interrupt-affinity" property as per Robin Murphy review comment.
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index 396ffb9..09e7a05b 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -472,6 +472,16 @@
> status = "disabled";
> };
>
> + arm-pmu {
> + compatible = "arm,cortex-a57-pmu", "arm,armv8-pmuv3";
> + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&cpu_atlas0>, <&cpu_atlas1>,
> + <&cpu_atlas2>, <&cpu_atlas3>;
> + };
> +
I didn't double check if these are the correct IRQs because I don't have
an Exynos7 user manual, but the change looks good to me.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Hanjun Guo @ 2016-11-12 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <713f102418c0fffacf67acb16dbdeec2@codeaurora.org>
On 11/12/2016 11:01 AM, agustinv at codeaurora.org wrote:
> Hey Lorenzo, Hanjun,
>
> On 2016-11-11 08:33, Hanjun Guo wrote:
>> Hi Lorenzo,
>>
>> On 11/11/2016 01:58 AM, Lorenzo Pieralisi wrote:
>>> On Thu, Nov 10, 2016 at 10:02:35AM -0500, agustinv at codeaurora.org wrote:
>>>> Hey Hanjun,
>>>>
>>>> On 2016-11-09 21:36, Hanjun Guo wrote:
>>>>> Hi Marc, Rafael, Lorenzo,
>>>>>
>>>>> Since we agreed to add a probe deferral if we failed to get irq
>>>>> resources which mirroring the DT does (patch 1 in this patch set),
>>>>> I think the last blocker to make things work both for Agustin and
>>>>> me [1] is this patch, which makes the interrupt producer and consumer
>>>>> work in ACPI, we have two different solution for one thing, we'd happy
>>>>> to work together for one solution, could you give some suggestions
>>>>> please?
>>>>>
>>>>> [1]:
>>>>> https://mail-archive.com/linux-kernel at vger.kernel.org/msg1257419.html
>>>>>
>>>>> Agustin, I have some comments below.
>>>>>
>>>>> On 2016/10/29 4:48, Agustin Vega-Frias wrote:
>>>>>> This allows irqchip drivers to associate an ACPI DSDT device to
>>>>>> an IRQ domain and provides support for using the ResourceSource
>>>>>> in Extended IRQ Resources to find the domain and map the IRQs
>>>>>> specified on that domain.
>>>>>>
>>>>>> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
>>>>>> ---
>>>>>> drivers/acpi/Makefile | 1 +
>>>>>> drivers/acpi/irqdomain.c | 119
>>>>>> +++++++++++++++++++++++++++++++++++++++++++++++
>>>>>
>>>>> Could we just reuse the gsi.c and not introduce a new
>>>>> file, probably we can change the gsi.c to irqdomain.c
>>>>> or something similar, then reuse the code in gsi.c.
>>>>
>>>> I was thinking just that after we chatted off-list.
>>>
>>> Yes, that's a fair point.
>>>
>>>> I might revisit and see what I come up with given that we already have
>>>> a device argument and we could pass the IRQ source there.
>>>
>>> I agree with the approach taken by this patch, I do not like much
>>> passing around struct acpi_resource_source *source (in particular
>>> the dummy struct) I do not think it is needed, I will comment on
>>> the code.
>>
>> thanks for your time to have a look:)
>>
>>>
>>> Hopefully there is not any buggy FW out there that does use the
>>> resource source inappropriately otherwise we will notice on x86/ia64
>>> (ie you can't blame FW if it breaks the kernel) but I suspect the
>>> only way to find out is by trying, the patch has to go through Rafael's
>>> review anyway before getting there so it is fine.
>>
>> I think we can avoid that by not touching the logic that x86/ia64
>> already used, but only adding interrupt producer/consumer function.
>
> I looked at this more today and implemented a new patch that I plan to
> test over the weekend, but I wanted to let you know the approach I am
> pursuing.
>
> On the new patch use of ResourceSource when parsing ACPI Extended IRQ
> Resources is conditional on CONFIG_ACPI_GENERIC_GSI. The reason for this
> is two fold:
>
> 1. Since we wanted to reduce duplication and place the new APIs on the
> same source file as acpi_register_gsi, which is already under that
> config flag.
> 2. So the patch does not have effect on platforms not using the generic
> GSI support, including x86/ia64.
>
> If support for this is needed outside platforms using the generic GSI
> implementation, we can move these APIs out to their own source file
> and eliminate the CONFIG_ACPI_GENERIC_GSI conditionality.
I think is fine because ACPI_GENERIC_GSI is not for x86 at now, please
send out the patch then we can discuss.
Thanks
Hanjun
>
> I'll send the new patch, hopefully some time tomorrow, but please let
> me know if you have concerns with this approach.
>
> Thanks,
> Agustin
>
^ permalink raw reply
* [PATCH] ARM64: dts: bcm2837-rpi-3-b: remove incorrect pwr LED
From: Stefan Wahren @ 2016-11-12 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111173821.21491-1-eric@anholt.net>
Hi Eric,
[add Gerd to CC]
> Eric Anholt <eric@anholt.net> hat am 11. November 2016 um 18:38 geschrieben:
>
>
> From: Andrea Merello <andrea.merello@gmail.com>
>
> We are incorrectly defining the pwr LED, attaching it to a gpio line
> that is wired to the Wi-Fi SDIO module (which fails due to this).
i agree with the intention of this patch, but is the upstream kernel really
affected? I can't see any compatible for the Wifi interface.
>
> The actual power LED is connected to the GPIO expander, which we don't
> expose currently.
>
> Thanks-to: Eric Anholt <eric@anholt.net> [for clarifying we can't control the
> LED]
> Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
> Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes: 9d56c22a7861 ("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.")
Stefan
^ permalink raw reply
* [PATCH] ARM: dts: imx: Remove skeleton.dtsi
From: Fabio Estevam @ 2016-11-12 15:30 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
As explained by commit 9c0da3cc61f1233c ("ARM: dts: explicitly mark
skeleton.dtsi as deprecated"), including skeleton.dtsi is deprecated.
This fixes the following warning with W=1:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx1.dtsi | 4 +++-
arch/arm/boot/dts/imx23.dtsi | 4 +++-
arch/arm/boot/dts/imx25.dtsi | 4 +++-
arch/arm/boot/dts/imx27.dtsi | 4 +++-
arch/arm/boot/dts/imx28.dtsi | 4 +++-
arch/arm/boot/dts/imx31.dtsi | 5 +++--
arch/arm/boot/dts/imx35.dtsi | 4 +++-
arch/arm/boot/dts/imx50.dtsi | 4 +++-
arch/arm/boot/dts/imx51.dtsi | 4 +++-
arch/arm/boot/dts/imx53.dtsi | 4 +++-
arch/arm/boot/dts/imx6qdl.dtsi | 5 +++--
arch/arm/boot/dts/imx6sl.dtsi | 4 +++-
arch/arm/boot/dts/imx6sx.dtsi | 4 +++-
arch/arm/boot/dts/imx6ul.dtsi | 4 +++-
arch/arm/boot/dts/imx7s.dtsi | 4 +++-
15 files changed, 45 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/imx1.dtsi b/arch/arm/boot/dts/imx1.dtsi
index 22f5d1d..b792eee 100644
--- a/arch/arm/boot/dts/imx1.dtsi
+++ b/arch/arm/boot/dts/imx1.dtsi
@@ -9,7 +9,6 @@
* http://www.gnu.org/copyleft/gpl.html
*/
-#include "skeleton.dtsi"
#include "imx1-pinfunc.h"
#include <dt-bindings/clock/imx1-clock.h>
@@ -17,6 +16,9 @@
#include <dt-bindings/interrupt-controller/irq.h>
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
gpio0 = &gpio1;
gpio1 = &gpio2;
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 8e1543f..ac2a9da 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -9,10 +9,12 @@
* http://www.gnu.org/copyleft/gpl.html
*/
-#include "skeleton.dtsi"
#include "imx23-pinfunc.h"
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
interrupt-parent = <&icoll>;
aliases {
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index af6af87..831d09a 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -9,10 +9,12 @@
* http://www.gnu.org/copyleft/gpl.html
*/
-#include "skeleton.dtsi"
#include "imx25-pinfunc.h"
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
ethernet0 = &fec;
gpio0 = &gpio1;
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index f818ea4..9d8b596 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -9,7 +9,6 @@
* http://www.gnu.org/copyleft/gpl.html
*/
-#include "skeleton.dtsi"
#include "imx27-pinfunc.h"
#include <dt-bindings/clock/imx27-clock.h>
@@ -18,6 +17,9 @@
#include <dt-bindings/interrupt-controller/irq.h>
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
ethernet0 = &fec;
gpio0 = &gpio1;
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 0ad893b..3aabf65 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -10,10 +10,12 @@
*/
#include <dt-bindings/gpio/gpio.h>
-#include "skeleton.dtsi"
#include "imx28-pinfunc.h"
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
interrupt-parent = <&icoll>;
aliases {
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 8d4c0e3..685916e 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -9,9 +9,10 @@
* http://www.gnu.org/copyleft/gpl.html
*/
-#include "skeleton.dtsi"
-
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
serial0 = &uart1;
serial1 = &uart2;
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index f812d58..9f40e62 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -8,10 +8,12 @@
* Free Software Foundation.
*/
-#include "skeleton.dtsi"
#include "imx35-pinfunc.h"
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
ethernet0 = &fec;
gpio0 = &gpio1;
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index 92a03bc..fe0221e 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -11,11 +11,13 @@
* http://www.gnu.org/copyleft/gpl.html
*/
-#include "skeleton.dtsi"
#include "imx50-pinfunc.h"
#include <dt-bindings/clock/imx5-clock.h>
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
ethernet0 = &fec;
gpio0 = &gpio1;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index d8efdab..33526ca 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -10,7 +10,6 @@
* http://www.gnu.org/copyleft/gpl.html
*/
-#include "skeleton.dtsi"
#include "imx51-pinfunc.h"
#include <dt-bindings/clock/imx5-clock.h>
#include <dt-bindings/gpio/gpio.h>
@@ -18,6 +17,9 @@
#include <dt-bindings/interrupt-controller/irq.h>
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
ethernet0 = &fec;
gpio0 = &gpio1;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 88f9e09e..ca51dc0 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -10,7 +10,6 @@
* http://www.gnu.org/copyleft/gpl.html
*/
-#include "skeleton.dtsi"
#include "imx53-pinfunc.h"
#include <dt-bindings/clock/imx5-clock.h>
#include <dt-bindings/gpio/gpio.h>
@@ -18,6 +17,9 @@
#include <dt-bindings/interrupt-controller/irq.h>
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
ethernet0 = &fec;
gpio0 = &gpio1;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 1bbd36f..bc3e12a 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -13,9 +13,10 @@
#include <dt-bindings/clock/imx6qdl-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
-#include "skeleton.dtsi"
-
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
ethernet0 = &fec;
can0 = &can1;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 02378db..4fe5d0c 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -8,11 +8,13 @@
*/
#include <dt-bindings/interrupt-controller/irq.h>
-#include "skeleton.dtsi"
#include "imx6sl-pinfunc.h"
#include <dt-bindings/clock/imx6sl-clock.h>
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
ethernet0 = &fec;
gpio0 = &gpio1;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index bd9fe67..3926eb5 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -11,9 +11,11 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include "imx6sx-pinfunc.h"
-#include "skeleton.dtsi"
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
can0 = &flexcan1;
can1 = &flexcan2;
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index c5c05fd..39845a7 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -11,9 +11,11 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include "imx6ul-pinfunc.h"
-#include "skeleton.dtsi"
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
ethernet0 = &fec1;
ethernet1 = &fec2;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 0d7d5ac..51dfcc1 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -46,9 +46,11 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include "imx7d-pinfunc.h"
-#include "skeleton.dtsi"
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
gpio0 = &gpio1;
gpio1 = &gpio2;
--
2.7.4
^ permalink raw reply related
* [GIT PULL 1/3] Rockchip driver changes for 4.10
From: Heiko Stuebner @ 2016-11-12 15:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, Olof,
please find below and in the following two mails, Rockchip power-domain as
well as dts32 and dts64 changes for 4.10.
I don't think anything big stands out, just the usual mix of incremental
improvements, so if stuff looks ok please pull.
Thanks
Heiko
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.10-rockchip-drivers1
for you to fetch changes up to dabc0259db63338f0e64107cc92b2241f98a3284:
soc: rockchip: power-domain: Handle errors from of_genpd_add_provider_onecell (2016-11-11 02:14:59 +0100)
----------------------------------------------------------------
Changes to the power-domain driver including counter presets now being set
by firmware on the rk3399, avoiding infite loops when powering on/off a
domain and actually returning an error if power-domain addition fails.
The last part requires usage of the (new in 4.9-rc1) pm_genpd_remove
functionality as well.
----------------------------------------------------------------
Caesar Wang (1):
soc: rockchip: power-domain: avoid infinite loop
Douglas Anderson (1):
soc: rockchip: power-domain: Don't (incorrectly) set rk3399 up/down counts
Heiko Stuebner (1):
soc: rockchip: power-domain: use pm_genpd_remove in error cleanup
Tomeu Vizoso (1):
soc: rockchip: power-domain: Handle errors from of_genpd_add_provider_onecell
drivers/soc/rockchip/pm_domains.c | 81 ++++++++++++++++++++++++++++++---------
1 file changed, 63 insertions(+), 18 deletions(-)
^ permalink raw reply
* [GIT PULL 2/3] Rockchip dts32 changes for 4.10
From: Heiko Stuebner @ 2016-11-12 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1698724.ZQnZMjf8xY@phil>
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.10-rockchip-dts32-1
for you to fetch changes up to 6a8883d614c7bede1075a4850139daa9723c291e:
ARM: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max" (2016-11-09 14:46:04 +0100)
----------------------------------------------------------------
32bit devicetree changes for Rockchip including removal of skeleton.dtsi
inclusion, missing unit names for memory nodes, various frequency
optimizations allowing for better performance on rk3066, the usage of
pin constants to bridge between the two numbering schemes used (gpio
controllers using 0-31 and pins being labeled A0-A7,..., D0-D7)
and UHS/HS modes for the mmc controllers on the popmetal board.
Two new boards, the PX3-based evaluation board, with the PX3 being an
industrial variant of the rk3188 soc and the Rikomagic MK808 board
based around the rk3066 are also added.
----------------------------------------------------------------
Andy Yan (3):
ARM: dts: rockchip: add rockchip PX3 Evaluation board
include: dt-bindings: Add GPIO pin index definition for rockchip pinctrl
ARM: dts: rockchip: use pin constants to describe gpios on Popmetal-RK3288
Finley Xiao (1):
ARM: dts: rockchip: update compatible strings for Rockchip efuse
Heiko Stuebner (2):
Merge branch 'v4.10-shared/clkids' into v4.10-armsoc/dts32
Merge branch 'v4.10-shared/pinctrl' into v4.10-armsoc/dts32
Jaehoon Chung (1):
ARM: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
Javier Martinez Canillas (8):
ARM: dts: rockchip: Remove skeleton.dtsi inclusion in rk3036.dtsi
ARM: dts: rockchip: Remove skeleton.dtsi inclusion in rk322x.dtsi
ARM: dts: rockchip: Remove skeleton.dtsi inclusion in rk3288.dtsi
ARM: dts: rockchip: Remove skeleton.dtsi inclusion in rk3xxx.dtsi
ARM: dts: rockchip: Add missing unit name to memory nodes in rk3036 boards
ARM: dts: rockchip: Add missing unit name to memory nodes in rk322x boards
ARM: dts: rockchip: Add missing unit name to memory nodes in rk3288 boards
ARM: dts: rockchip: Add missing unit name to memory nodes in rk3xxx boards
Pawe? Jarosz (5):
clk: rockchip: Add binding ids for cpu and peri clocks on rk3066
ARM: dts: rockchip: initialize rk3066 PLL clock rate
devicetree: Add vendor prefix for Rikomagic
ARM: dts: rockchip: Add rk3066 MK808 board
ARM: dts: rockchip: Set sdmmc frequency at boot time for rk3066a
Shawn Lin (3):
ARM: dts: rockchip: remove always-on and boot-on from vcc_sd for px3-evb
ARM: dts: rockchip: Support UHS mode for SD card on PopMetal-RK3288 board
ARM: dts: rockchip: enable HS200/DDR52 mode for emmc on rk3288-popmetal
Documentation/devicetree/bindings/arm/rockchip.txt | 4 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/rk3036-evb.dts | 2 +-
arch/arm/boot/dts/rk3036-kylin.dts | 2 +-
arch/arm/boot/dts/rk3036.dtsi | 10 +-
arch/arm/boot/dts/rk3066a-bqcurie2.dts | 2 +-
arch/arm/boot/dts/rk3066a-marsboard.dts | 2 +-
arch/arm/boot/dts/rk3066a-mk808.dts | 195 ++++++++++++
arch/arm/boot/dts/rk3066a-rayeager.dts | 2 +-
arch/arm/boot/dts/rk3066a.dtsi | 12 +-
arch/arm/boot/dts/rk3188-px3-evb.dts | 328 +++++++++++++++++++++
arch/arm/boot/dts/rk3188-radxarock.dts | 2 +-
arch/arm/boot/dts/rk3188.dtsi | 2 +-
arch/arm/boot/dts/rk3228-evb.dts | 2 +-
arch/arm/boot/dts/rk3229-evb.dts | 2 +-
arch/arm/boot/dts/rk322x.dtsi | 6 +-
arch/arm/boot/dts/rk3288-evb.dtsi | 2 +-
arch/arm/boot/dts/rk3288-fennec.dts | 2 +-
arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 2 +-
arch/arm/boot/dts/rk3288-firefly.dtsi | 2 +-
arch/arm/boot/dts/rk3288-miqi.dts | 2 +-
arch/arm/boot/dts/rk3288-popmetal.dts | 34 ++-
arch/arm/boot/dts/rk3288-r89.dts | 2 +-
arch/arm/boot/dts/rk3288-rock2-som.dtsi | 2 +-
arch/arm/boot/dts/rk3288-veyron.dtsi | 2 +-
arch/arm/boot/dts/rk3288.dtsi | 14 +-
arch/arm/boot/dts/rk3xxx.dtsi | 4 +-
include/dt-bindings/clock/rk3188-cru-common.h | 8 +-
include/dt-bindings/pinctrl/rockchip.h | 33 +++
30 files changed, 639 insertions(+), 46 deletions(-)
create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts
create mode 100644 arch/arm/boot/dts/rk3188-px3-evb.dts
^ permalink raw reply
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