* [PATCH 4/7] arm64: marvell: dts: add crypto engine description for 7k/8k
From: Antoine Tenart @ 2017-04-18 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412105608.41501b63@free-electrons.com>
Hi Thomas,
On Wed, Apr 12, 2017 at 10:56:08AM +0200, Thomas Petazzoni wrote:
> On Wed, 29 Mar 2017 14:44:29 +0200, Antoine Tenart wrote:
>
> > + cpm_crypto: crypto at 800000 {
> > + compatible = "inside-secure,safexcel-eip197";
> > + reg = <0x800000 0x200000>;
> > + interrupts = <GIC_SPI 34 (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH)>,
>
> Now that I look into this, does it makes sense for an interrupt to be
> both an edge interrupt and a level interrupt at the same time? This
> looks odd.
I agree this looks odd. I took it from Russel's ICU mapping:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/489040.html
Also note the driver does not use it (yet?).
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170418/b8e12a4e/attachment.sig>
^ permalink raw reply
* [PATCH v6 3/6] ARM: dtsi: axp209: add battery power supply subnode
From: Quentin Schulz @ 2017-04-18 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418073421.31351-1-quentin.schulz@free-electrons.com>
The X-Powers AXP209 PMIC exposes battery supply various data such as
the battery status (charging, discharging, full, dead), current max
limit, current current, battery capacity (in percentage), voltage max
and min limits, current voltage, and battery capacity (in Ah).
This adds the battery power supply subnode for AXP20X PMIC.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
v2:
- changed DT node name from battery_power_supply to
battery-power-supply,
- removed io-channels and io-channel-names from DT (the IIO mapping is
done in the IIO ADC driver now),
arch/arm/boot/dts/axp209.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
index 9677dd5cf6b6..3c8fa26e87b7 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -64,6 +64,11 @@
#gpio-cells = <2>;
};
+ battery_power_supply: battery-power-supply {
+ compatible = "x-powers,axp209-battery-power-supply";
+ status = "disabled";
+ };
+
regulators {
/* Default work frequency for buck regulators */
x-powers,dcdc-freq = <1500>;
--
2.11.0
^ permalink raw reply related
* [PATCH v6 4/6] ARM: dtsi: axp22x: add battery power supply subnode
From: Quentin Schulz @ 2017-04-18 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418073421.31351-1-quentin.schulz@free-electrons.com>
The X-Powers AXP22X PMIC exposes battery supply various data such as
the battery status (charging, discharging, full, dead), current max
limit, current current, battery capacity (in percentage), voltage max
limit, current voltage, and battery capacity (in Ah).
This adds the battery power supply subnode for AXP22X PMIC.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
v2:
- changed DT node name from battery_power_supply to
battery-power-supply,
- removed io-channels and io-channel-names from DT (the IIO mapping is
done in the IIO ADC driver now),
arch/arm/boot/dts/axp22x.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/axp22x.dtsi b/arch/arm/boot/dts/axp22x.dtsi
index 67331c5f1714..87fb08e812ec 100644
--- a/arch/arm/boot/dts/axp22x.dtsi
+++ b/arch/arm/boot/dts/axp22x.dtsi
@@ -57,6 +57,11 @@
status = "disabled";
};
+ battery_power_supply: battery-power-supply {
+ compatible = "x-powers,axp221-battery-power-supply";
+ status = "disabled";
+ };
+
regulators {
/* Default work frequency for buck regulators */
x-powers,dcdc-freq = <3000>;
--
2.11.0
^ permalink raw reply related
* [PATCH v6 5/6] ARM: dts: sun8i: sina33: enable battery power supply subnode
From: Quentin Schulz @ 2017-04-18 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418073421.31351-1-quentin.schulz@free-electrons.com>
The Sinlinx SinA33 has an AXP223 PMIC and a battery connector, thus, we
enable the battery power supply subnode in its Device Tree.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 9b620cc1d5f1..edc68984fbc8 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -196,6 +196,10 @@
status = "okay";
};
+&battery_power_supply {
+ status = "okay";
+};
+
®_aldo1 {
regulator-always-on;
regulator-min-microvolt = <3000000>;
--
2.11.0
^ permalink raw reply related
* [PATCH v6 6/6] ARM: sun5i: chip: enable battery power supply subnode
From: Quentin Schulz @ 2017-04-18 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418073421.31351-1-quentin.schulz@free-electrons.com>
The NextThing Co. CHIP has an AXP209 PMIC with battery connector.
This enables the battery power supply subnode.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun5i-r8-chip.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts b/arch/arm/boot/dts/sun5i-r8-chip.dts
index d0785602663b..879a4b0f3bd5 100644
--- a/arch/arm/boot/dts/sun5i-r8-chip.dts
+++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
@@ -132,6 +132,10 @@
status = "okay";
};
+&battery_power_supply {
+ status = "okay";
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins_a>;
--
2.11.0
^ permalink raw reply related
* [PATCH/RFT v2] ARM: dts: silk: Enable UHS-I SDR-50
From: Simon Horman @ 2017-04-18 7:34 UTC (permalink / raw)
To: linux-arm-kernel
Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI1.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
* Compile tested only; no access to silk board
---
arch/arm/boot/dts/r8a7794-silk.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
index 4cb5278d104d..bb0c41c2f3ac 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -196,6 +196,13 @@
sdhi1_pins: sd1 {
groups = "sdhi1_data4", "sdhi1_ctrl";
function = "sdhi1";
+ power-source = <3300>;
+ };
+
+ sdhi1_pins_uhs: sd1_uhs {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <1800>;
};
qspi_pins: qspi {
@@ -343,6 +350,7 @@
vmmc-supply = <&vcc_sdhi1>;
vqmmc-supply = <&vccq_sdhi1>;
cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
+ sd-uhs-sdr50;
status = "okay";
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH] ARM: Fix rd_size declaration
From: Johannes Thumshirn @ 2017-04-18 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417231003.7178-1-bart.vanassche@sandisk.com>
On Mon, Apr 17, 2017 at 04:10:03PM -0700, Bart Van Assche wrote:
> The global variable 'rd_size' is declared as 'int' in source file
> arch/arm/kernel/atags_parse.c and as 'unsigned long' in
> drivers/block/brd.c. Fix this inconsistency.
>
> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Jens Axboe <axboe@kernel.dk>
> Cc: Jan Kara <jack@suse.cz>
> Cc: <yanaijie@huawei.com>
> Cc: <zhaohongjiang@huawei.com>
> Cc: <miaoxie@huawei.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-block at vger.kernel.org
> ---
> diff --git a/include/linux/brd.h b/include/linux/brd.h
> new file mode 100644
> index 000000000000..dbb0f92fefc8
> --- /dev/null
> +++ b/include/linux/brd.h
> @@ -0,0 +1 @@
> +extern unsigned long rd_size;
Small nit, can you add an include guard here as well?
Thanks,
Johannes
--
Johannes Thumshirn Storage
jthumshirn at suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board
From: Hoegeun Kwon @ 2017-04-18 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b9bfcdd9-5576-34c3-6c7d-556b6c81946d@samsung.com>
On 04/18/2017 03:00 PM, Andrzej Hajda wrote:
> On 17.04.2017 08:02, Hoegeun Kwon wrote:
>> This patch add the panel device tree node for s6e3hf2 display
>> controller to TM2e dts.
>>
>> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
> Maybe it would be good to remove te-gpios property - tm2/tm2e uses
> hardware trigger, so it is not necessary and generates useless interrupts.
Thanks for your review.
I agree, but I thinks remove the te-gpio property after your patch [1]
has been merged.
[1] https://patchwork.kernel.org/patch/9625383/
Best regards,
Hoegeun
>
> Beside this:
> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
> --
> Regards
> Andrzej
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
>> index 694717a..98ad094 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
>> @@ -52,6 +52,18 @@
>> assigned-clock-rates = <278000000>, <400000000>;
>> };
>>
>> +&dsi {
>> + panel at 0 {
>> + compatible = "samsung,s6e3hf2";
>> + reg = <0>;
>> + vdd3-supply = <&ldo27_reg>;
>> + vci-supply = <&ldo28_reg>;
>> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
>> + };
>> +};
>> +
>> &ldo31_reg {
>> regulator-name = "TSP_VDD_1.8V_AP";
>> regulator-min-microvolt = <1800000>;
>
>
>
^ permalink raw reply
* [PATCH] i2c: designware: do not show SDA hold time warning when not needed
From: Andy Shevchenko @ 2017-04-18 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492203192-28025-1-git-send-email-thomas.petazzoni@free-electrons.com>
On Fri, 2017-04-14 at 22:53 +0200, Thomas Petazzoni wrote:
> When the I2C controller IP block has a revision too old to be able to
> configure the SDA hold time, the driver currently displays a
> warning. However, it does so unconditionally, even if no SDA hold time
> has been configured through the Device Tree. This causes useless
> warnings when running the system, so only show the warning if a SDA
> hold time was specified.
As far as I understand the warning it would be better to keep it in
either way, though you may shift it to debug level.
Wolfram, Jarkko, thoughts?
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> ?drivers/i2c/busses/i2c-designware-core.c | 5 +++--
> ?1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-core.c
> b/drivers/i2c/busses/i2c-designware-core.c
> index 7a3faa5..7f9da6e 100644
> --- a/drivers/i2c/busses/i2c-designware-core.c
> +++ b/drivers/i2c/busses/i2c-designware-core.c
> @@ -436,8 +436,9 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
> ? dev->sda_hold_time |= 1 <<
> DW_IC_SDA_HOLD_RX_SHIFT;
> ? dw_writel(dev, dev->sda_hold_time, DW_IC_SDA_HOLD);
> ? } else {
> - dev_warn(dev->dev,
> - "Hardware too old to adjust SDA hold
> time.\n");
> + if (dev->sda_hold_time)
> + dev_warn(dev->dev,
> + ?"Hardware too old to adjust SDA hold
> time.\n");
> ? }
> ?
> ? /* Configure Tx/Rx FIFO threshold levels */
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board
From: Andrzej Hajda @ 2017-04-18 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f2acb724-ba41-175c-061a-7be765cc1939@samsung.com>
On 18.04.2017 09:44, Hoegeun Kwon wrote:
> On 04/18/2017 03:00 PM, Andrzej Hajda wrote:
>> On 17.04.2017 08:02, Hoegeun Kwon wrote:
>>> This patch add the panel device tree node for s6e3hf2 display
>>> controller to TM2e dts.
>>>
>>> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
>> Maybe it would be good to remove te-gpios property - tm2/tm2e uses
>> hardware trigger, so it is not necessary and generates useless interrupts.
> Thanks for your review.
>
> I agree, but I thinks remove the te-gpio property after your patch [1]
> has been merged.
Patch [1] has been merged about month ago :)
Regards
Andrzej
>
>
> [1] https://patchwork.kernel.org/patch/9625383/
>
> Best regards,
> Hoegeun
>
>> Beside this:
>> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
>> --
>> Regards
>> Andrzej
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 ++++++++++++
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
>>> index 694717a..98ad094 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
>>> @@ -52,6 +52,18 @@
>>> assigned-clock-rates = <278000000>, <400000000>;
>>> };
>>>
>>> +&dsi {
>>> + panel at 0 {
>>> + compatible = "samsung,s6e3hf2";
>>> + reg = <0>;
>>> + vdd3-supply = <&ldo27_reg>;
>>> + vci-supply = <&ldo28_reg>;
>>> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>>> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>>> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +};
>>> +
>>> &ldo31_reg {
>>> regulator-name = "TSP_VDD_1.8V_AP";
>>> regulator-min-microvolt = <1800000>;
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* [PATCH] i2c: designware: do not show SDA hold time warning when not needed
From: Thomas Petazzoni @ 2017-04-18 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492502087.24567.47.camel@linux.intel.com>
Hello,
On Tue, 18 Apr 2017 10:54:47 +0300, Andy Shevchenko wrote:
> On Fri, 2017-04-14 at 22:53 +0200, Thomas Petazzoni wrote:
> > When the I2C controller IP block has a revision too old to be able to
> > configure the SDA hold time, the driver currently displays a
> > warning. However, it does so unconditionally, even if no SDA hold time
> > has been configured through the Device Tree. This causes useless
> > warnings when running the system, so only show the warning if a SDA
> > hold time was specified.
>
> As far as I understand the warning it would be better to keep it in
> either way, though you may shift it to debug level.
>
> Wolfram, Jarkko, thoughts?
Why show a message when the user has not requested a custom SDA hold
time? Getting a warning about something you haven't requested seems
really odd.
I think it makes a lot more sense to keep it at the warning level
(because it's important to get this message if you configure a custom
SDA hold time), but only show it when appropriate.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 2/3] drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board
From: Inki Dae @ 2017-04-18 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5b3031ca-2847-fbc0-36f3-7e0a6cd3e0b3@samsung.com>
2017? 04? 18? 14:55? Andrzej Hajda ?(?) ? ?:
> On 17.04.2017 08:02, Hoegeun Kwon wrote:
>> This patch supports TM2e panel and the panel has 1600x2560 resolution
>> in 5.65" physical.
>>
>> This identify panel type with compatibility string, also invoke
>> display mode that matches the type. So add the check code for s6e3ha2
>> compatibility and s6e3hf2 type and select the drm_display_mode of
>> default and edge type.
>>
>> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Inki Dae <inki.dae@samsung.com>
Thanks,
Inki Dae
>
> --
> Regards
> Andrzej
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* [PATCH 2/7] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver
From: Antoine Tenart @ 2017-04-18 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5a016e1e-1443-158a-5ced-58dcb4ad63cc@arm.com>
Hi Robin,
On Wed, Apr 12, 2017 at 02:54:13PM +0100, Robin Murphy wrote:
>
> Bit of a drive-by, but since I have it in my head that crypto drivers
> are a hotspot for dodgy DMA usage (in part due to the hardware often
> being a bit esoteric with embedded RAMs and such), this caught my eye
> and I thought I'd give this a quick once-over to check for anything
> smelly. Unfortunately, I was not disappointed... ;)
:-)
> On 29/03/17 13:44, Antoine Tenart wrote:
> [...]
> > diff --git a/drivers/crypto/inside-secure/safexcel.c b/drivers/crypto/inside-secure/safexcel.c
> > new file mode 100644
> > index 000000000000..00f3f2c85d05
> > --- /dev/null
> > +++ b/drivers/crypto/inside-secure/safexcel.c
> [...]
> > +int safexcel_invalidate_cache(struct crypto_async_request *async,
> > + struct safexcel_context *ctx,
> > + struct safexcel_crypto_priv *priv,
> > + dma_addr_t ctxr_dma, int ring,
> > + struct safexcel_request *request)
> > +{
> > + struct safexcel_command_desc *cdesc;
> > + struct safexcel_result_desc *rdesc;
> > + phys_addr_t ctxr_phys;
> > + int ret = 0;
> > +
> > + ctxr_phys = dma_to_phys(priv->dev, ctxr_dma);
>
> No no no. This is a SWIOTLB-specific (or otherwise arch-private,
> depending on implementation) helper, not a DMA API function, and should
> not be called directly by drivers. There is no guarantee it will give
> the result you expect, or even compile, in all cases (if the kbuild
> robot hasn't already revealed via the COMPILE_TEST dependency).
>
> That said, AFAICS ctxr_phys ends up in a descriptor which is given to
> the device, so trying to use a physical address is wrong and it should
> still be the DMA address anyway.
I see. The cryptographic engine should always use dma addresses. I'll
update the descriptors structure members from "phys" to "dma" as well.
> [...]
> > +static int safexcel_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct resource *res;
> > + struct safexcel_crypto_priv *priv;
> > + int i, ret;
> > +
> > + priv = devm_kzalloc(dev, sizeof(struct safexcel_crypto_priv),
> > + GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->dev = dev;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + priv->base = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(priv->base)) {
> > + dev_err(dev, "failed to get resource\n");
> > + return PTR_ERR(priv->base);
> > + }
> > +
> > + priv->clk = of_clk_get(dev->of_node, 0);
> > + if (!IS_ERR(priv->clk)) {
> > + ret = clk_prepare_enable(priv->clk);
> > + if (ret) {
> > + dev_err(dev, "unable to enable clk (%d)\n", ret);
> > + return ret;
> > + }
> > + } else {
> > + /* The clock isn't mandatory */
> > + if (PTR_ERR(priv->clk) == -EPROBE_DEFER)
> > + return -EPROBE_DEFER;
> > + }
>
> You should call dma_set_mask_and_coherent() before any DMA API calls,
> both to confirm DMA really is going to work all, and also (since this IP
> apparently supports >32-bit addresses) to describe the full inherent
> addressing capability, not least to avoid wasting time/space with
> unnecessary bounce buffering otherwise.
OK, I'll add a call to this helper before using DMA API calls.
> > +
> > +err_pool:
> > + dma_pool_destroy(priv->context_pool);
>
> You used dmam_pool_create(), so not only is an explicit destroy
> unnecessary, but doing so with the non-managed version is actively
> harmful, since devres would end up double-freeing the pool after you return.
I saw this and fixed it in my local version.
> > +struct safexcel_token {
> > + u32 packet_length:17;
> > + u8 stat:2;
> > + u16 instructions:9;
> > + u8 opcode:4;
> > +} __packed;
>
> Using bitfields in hardware descriptors seems pretty risky, since you've
> no real guarantee two compilers will lay them out the same way (or that
> either would be correct WRT what the hardware expects). I'd be more
> inclined to construct all these fields with explicit masking and shifting.
Hmm, I'm not sure to follow you here. If I use bitfields in a __packed
structure, we should be safe. Why would the compiler have a different
behaviour?
> > +static int safexcel_aes_send(struct crypto_async_request *async,
> > + int ring, struct safexcel_request *request,
> > + int *commands, int *results)
> > +{
> > + struct ablkcipher_request *req = ablkcipher_request_cast(async);
> > + struct safexcel_cipher_ctx *ctx = crypto_tfm_ctx(req->base.tfm);
> > + struct safexcel_crypto_priv *priv = ctx->priv;
> > + struct safexcel_command_desc *cdesc;
> > + struct safexcel_result_desc *rdesc;
> > + struct scatterlist *sg;
> > + phys_addr_t ctxr_phys;
> > + int nr_src, nr_dst, n_cdesc = 0, n_rdesc = 0, queued = req->nbytes;
> > + int i, ret = 0;
> > +
> > + request->req = &req->base;
> > +
> > + if (req->src == req->dst) {
> > + nr_src = sg_nents_for_len(req->src, req->nbytes);
> > + nr_dst = nr_src;
> > +
> > + if (dma_map_sg(priv->dev, req->src, nr_src, DMA_BIDIRECTIONAL) <= 0)
>
> Nit: you only need to check for zero/nonzero to determine failure
> (similarly below) - dma_map_sg() cannot return negative values.
OK.
> Bigger complaint: you should not ignore the successful return value and
> rely on it being equal to nr_src - please see the description of
> dma_map_sg() in Documenatation/DMA-API.txt
OK, I'll have a look at it and fix this.
> > + /* command descriptors */
> > + for_each_sg(req->src, sg, nr_src, i) {
> > + phys_addr_t sg_phys = dma_to_phys(priv->dev, sg_dma_address(sg));
> > + int len = sg_dma_len(sg);
>
> If dma_map_sg() coalesced any entries into the same mapping such that
> count < nents, these could well give bogus values toward the end of the
> list once i >= count(if you're lucky, at least len might be 0).
OK, I'll fix this.
> > + /* Add a command descriptor for the cached data, if any */
> > + if (cache_len) {
> > + ctx->base.cache_dma = dma_map_single(priv->dev, req->cache,
>
> This is pretty dodgy, since req->cache is inside a live data structure,
> adjoining parts of which are updated whilst still mapped (the update of
> req->processed below). You just about get away without data corruption
> since we *probably* don't invalidate anything when unmapping
> DMA_TO_DEVICE, and the coherency hardware *probably* doesn't do anything
> crazy, but you've no real guarantee of that - any DMA buffer should
> really be separately kmalloced. "That's a nice dirty cache line you've
> got there, it'd be a shame if anything were to happen to it..."
OK, good to know.
> > + rdr->base = dmam_alloc_coherent(priv->dev,
> > + rdr->offset * EIP197_DEFAULT_RING_SIZE,
> > + &rdr->base_dma, GFP_KERNEL);
> > + if (!rdr->base) {
> > + dmam_free_coherent(priv->dev,
> > + cdr->offset * EIP197_DEFAULT_RING_SIZE,
> > + cdr->base, cdr->base_dma);
>
> Returning an error here will abort your probe routine, so devres will
> clean these up there and then - there's no need to do free anything
> explicitly. That's rather the point of using devm_*() to begin with.
Sure.
> > + dmam_free_coherent(priv->dev,
> > + cdr->offset * EIP197_DEFAULT_RING_SIZE,
> > + cdr->base, cdr->base_dma);
> > + dmam_free_coherent(priv->dev,
> > + rdr->offset * EIP197_DEFAULT_RING_SIZE,
> > + rdr->base, rdr->base_dma);
> > +}
>
> Again, this is only called at device teardown, so the whole function is
> redundant.
OK, I'll remove these.
Thanks for the review!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170418/2a1b30cf/attachment-0001.sig>
^ permalink raw reply
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Stefan Wahren @ 2017-04-18 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WJBTUcMPw8OgQT_jhz0H8AsH=YqWMR7LtudUKrF5-XOA@mail.gmail.com>
Am 18.04.2017 um 00:37 schrieb Doug Anderson:
> Hi,
>
> On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>> Hi,
>>
>>> Stefan Wahren <stefan.wahren@i2se.com> hat am 31. Oktober 2016 um 21:34 geschrieben:
>>>
>>>
>>> I inspired by this issue [1] i build up a slightly modified setup with a
>>> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 Prolific
>>> PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
>>> only tries to open all ttyUSB devices one after the other.
>>>
>>> Unfortunately the complete system stuck after opening the first ttyUSB device (
>>> heartbeat LED stop blinking, no reaction to debug UART). The only way to
>>> reanimate the system is to powerdown the USB hub with the USB to serial
>>> convertors.
>>>
>>> [1] - https://github.com/raspberrypi/linux/issues/1692
>>> [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa
>> since this issue still exists with 4.11 (even without or with microframe scheduler enabled), i want to ask some additional questions:
>>
>> Is this issue reproducible with other dwc2 platforms than bcm2835?
> +Edmund Szeto, who I seem to remember emailing me about similar
> questions in the past.
>
>
>> Does the soft lockup also occurs after opening the second serial convertor or later?
> I don't have serial converters easily available to me, but back in the
> day when I was stressing things out on rk3288 I never saw anything
> this bad. ...of course, on rk3288 we've got 4 A17 cores running
> really fast, so possibly just being slower is what causes your
> problems here?
The downstream kernel of the Raspberry Pi foundation with it's
out-of-tree dwc_otg driver is able to handle 8 serial converter on a RPI
B. I would be happy to get at least 2 or 3 working on mainline.
>
> I will make the following observations:
>
> 1. With dwc2 you often end up in the situation where you need to
> service an interrupt every 125 uS. If servicing that interrupt takes
> anywhere near 125 uS in the common case then you'll be in trouble.
I will try to measure this with a logic analyzer.
>
> ===
>
> 2. When I was testing on rk3288 (on kernel 3.14) I did see occasions
> where uvc_video_complete() could sometimes take > 125 uS. It's been a
> long time now, but if I remember correctly this had to do with the
> fact that the URB buffers were allocated in a way where you had to
> access them non-cached and this was super duper slow. In my
> particular case I could "fix" it by adjusting UVC_MAX_PACKETS
> (crosreview.com/321932). ...and I had some timing code in
> crosreview.com/321980.
>
> Again, it was a long time ago, but elsewhere I have written down:
>
> -----
>
> Specifically:
> * The USB "complete" functions are called with local interrupts
> disabled. Specifically see __usb_hcd_giveback_urb().
> * I see calls to uvc_video_complete() that easily take > 125us.
>
> Unfortunately the interrupts disabled while uvc_video_complete() is
> called are always the interrupts for the same CPU that's dealing with
> the normal dwc2 USB interrupts.
>
> --
>
> Ugh. This may be the memcpy() as others have found:
>
> http://www.spinics.net/lists/linux-usb/msg83581.html
>
> ...looks like the issue is that the driver is allocating memory that's
> supposed to be DMA coherent and copying from this memory is slow.
>
> -----
>
> You could probably pick my timing patch and then see if you're
> actually hitting cases like this, I guess?
>
> ===
>
> 3. Are you running CPUFreq by chance?
>
> ...back in the day we had a bug on rk3288 where we were temporarily
> running the CPU as slow as 8 MHz for a short while during a CPUFreq
> transition. If you happened to get a dwc2 interrupt while at this
> speed then you were in trouble.
There is no CPUFreq driver for bcm2835 in mainline and i hope the GPU
firmware doesn't play with the core frequency during runtime.
I also use the bcm2835_defconfig, which does have anything disabled
under kernel hacking.
Thanks
Stefan
>
>
> -Doug
^ permalink raw reply
* [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
From: Philipp Zabel @ 2017-04-18 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414203216.GA10920@amd>
Hi Pavel,
On Fri, 2017-04-14 at 22:32 +0200, Pavel Machek wrote:
> Hi!
>
> > > The MUX framework is already in linux-next. Could you use that instead of
> > > adding new driver + bindings that are not compliant with the MUX framework?
> > > I don't think it'd be much of a change in terms of code, using the MUX
> > > framework appears quite simple.
> >
> > It is not quite clear to me how to design the DT bindings for this. Just
> > splitting the video-multiplexer driver from the mux-mmio / mux-gpio
> > would make it necessary to keep the video-multiplexer node to describe
> > the of-graph bindings. But then we have two different nodes in the DT
> > that describe the same hardware:
> >
> > mux: mux {
> > compatible = "mux-gpio";
> > mux-gpios = <&gpio 0>, <&gpio 1>;
> > #mux-control-cells = <0>;
> > }
> >
> > video-multiplexer {
> > compatible = "video-multiplexer"
> > mux-controls = <&mux>;
> >
> > ports {
> > /* ... */
> > }
> > }
> >
> > It would feel more natural to have the ports in the mux node, but then
> > how would the video-multiplexer driver be instanciated, and how would it
> > get to the of-graph nodes?
>
> Device tree representation and code used to implement the muxing
> driver should be pretty independend, no? Yes, one piece of hardware
> should have one entry in the device tree,
I agree.
> so it should be something like:
>
> video-multiplexer {
> compatible = "video-multiplexer-gpio"
> mux-gpios = <&gpio 0>, <&gpio 1>;
> #mux-control-cells = <0>;
>
> mux-controls = <&mux>;
>
> ports {
> /* ... */
> }
> }
That self-referencing mux-controls property looks a bit superfluous:
mux: video-multiplexer {
mux-controls = <&mux>;
};
Other than that, I'm completely fine with splitting the compatible into
something like video-mux-gpio and video-mux-mmio and reusing the
mux-gpios property for video-mux-gpio.
> You should be able to use code in drivers/mux as a library...
This is a good idea in principle, but this requires some rework of the
mux subsystem, and that subsystem hasn't even landed yet. For now I'd
like to focus on getting the DT bindings right.
I'd honestly prefer to not add this rework as a requirement for the i.MX
media drivers to get into staging.
regards
Philipp
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board
From: Hoegeun Kwon @ 2017-04-18 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <94152d85-5fb0-f5dc-045d-e6ee6c009f42@samsung.com>
On 04/18/2017 04:56 PM, Andrzej Hajda wrote:
> On 18.04.2017 09:44, Hoegeun Kwon wrote:
>> On 04/18/2017 03:00 PM, Andrzej Hajda wrote:
>>> On 17.04.2017 08:02, Hoegeun Kwon wrote:
>>>> This patch add the panel device tree node for s6e3hf2 display
>>>> controller to TM2e dts.
>>>>
>>>> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
>>> Maybe it would be good to remove te-gpios property - tm2/tm2e uses
>>> hardware trigger, so it is not necessary and generates useless interrupts.
>> Thanks for your review.
>>
>> I agree, but I thinks remove the te-gpio property after your patch [1]
>> has been merged.
> Patch [1] has been merged about month ago :)
Ah..., My mistake.... :)
I will send ver3 patchset without te-gpio property.
Best regards,
Hoegeun
^ permalink raw reply
* [PATCH] ARM: configs: Add multi_v7_lpae.config to support ARM_LPAE
From: Alison Wang @ 2017-04-18 8:30 UTC (permalink / raw)
To: linux-arm-kernel
As some ARMv7 platforms need to enable ARM_LPAE to access memory beyond
the 4GB limit, this patch is to add multi_v7_lpae.config to support the
Large Physical Address Extension. The building will use
multi_v7_defconfig + multi_v7_lpae.config as the defconfig.
Signed-off-by: Alison Wang <alison.wang@nxp.com>
---
arch/arm/configs/multi_v7_lpae.config | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 arch/arm/configs/multi_v7_lpae.config
diff --git a/arch/arm/configs/multi_v7_lpae.config b/arch/arm/configs/multi_v7_lpae.config
new file mode 100644
index 0000000..cd13d2d
--- /dev/null
+++ b/arch/arm/configs/multi_v7_lpae.config
@@ -0,0 +1,2 @@
+# Support for the Large Physical Address Extension
+CONFIG_ARM_LPAE=y
--
2.1.0.27.g96db324
^ permalink raw reply related
* kvm/arm64: use-after-free in kvm_unmap_hva_handler/unmap_stage2_pmds
From: Mark Rutland @ 2017-04-18 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413155045.GA8387@e107814-lin.cambridge.arm.com>
Hi Suzuki,
On Thu, Apr 13, 2017 at 04:50:46PM +0100, Suzuki K. Poulose wrote:
> kvm: Hold reference to the user address space
>
> The core KVM code, uses mmgrab/mmdrop to pin the mm struct of the user
> application. mmgrab only guarantees that the mm struct is available,
> while the "real address space" (see Documentation/vm/active_mm.txt) may
> be destroyed. Since the KVM depends on the user space page tables for
> the Guest pages, we should instead do an mmget/mmput. Even though
> mmget/mmput is not encouraged for uses with unbounded time, the KVM
> is fine to do so, as we are doing it from the context of the same process.
>
> This also prevents the race condition where mmu_notifier_release() could
> be called in parallel and one instance could end up using a free'd kvm
> instance.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Paolo Bonzin <pbonzini@redhat.com>
> Cc: Radim Kr?m?? <rkrcmar@redhat.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: andreyknvl at google.com
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> virt/kvm/kvm_main.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 88257b3..555712e 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -613,7 +613,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
> return ERR_PTR(-ENOMEM);
>
> spin_lock_init(&kvm->mmu_lock);
> - mmgrab(current->mm);
> + mmget(current->mm);
> kvm->mm = current->mm;
> kvm_eventfd_init(kvm);
> mutex_init(&kvm->lock);
> @@ -685,7 +685,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
> for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++)
> kvm_free_memslots(kvm, kvm->memslots[i]);
> kvm_arch_free_vm(kvm);
> - mmdrop(current->mm);
> + mmput(current->mm);
> return ERR_PTR(r);
> }
>
> @@ -747,7 +747,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
> kvm_arch_free_vm(kvm);
> preempt_notifier_dec();
> hardware_disable_all();
> - mmdrop(mm);
> + mmput(mm);
> }
As a heads-up, I'm seeing what looks to be a KVM memory leak with this
patch applied atop of next-20170411.
I don't yet know if this is a problem with next-20170411 or this patch
in particular -- I will try to track that down. In the mean time, info
dump below.
I left syzkaller running over the weekend using this kernel on the host,
and OOM kicked in after it had been running for a short while. Almost
all of my memory is in use, but judging by top, almost none of this is
associated with processes.
It looks like this is almost all AnonPages allocations:
nanook at medister:~$ cat /proc/meminfo
MemTotal: 14258176 kB
MemFree: 106192 kB
MemAvailable: 38196 kB
Buffers: 27160 kB
Cached: 42508 kB
SwapCached: 0 kB
Active: 13442912 kB
Inactive: 7388 kB
Active(anon): 13380876 kB
Inactive(anon): 400 kB
Active(file): 62036 kB
Inactive(file): 6988 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 13380688 kB
Mapped: 7352 kB
Shmem: 620 kB
Slab: 568196 kB
SReclaimable: 21756 kB
SUnreclaim: 546440 kB
KernelStack: 2832 kB
PageTables: 49168 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 7129088 kB
Committed_AS: 41554652 kB
VmallocTotal: 100930551744 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
AnonHugePages: 12728320 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
CmaTotal: 16384 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Looking at slabtop, there are large number of vm_area_structs around:
Active / Total Objects (% used) : 531511 / 587214 (90.5%)
Active / Total Slabs (% used) : 29443 / 29443 (100.0%)
Active / Total Caches (% used) : 108 / 156 (69.2%)
Active / Total Size (% used) : 514052.23K / 536839.57K (95.8%)
Minimum / Average / Maximum Object : 0.03K / 0.91K / 8.28K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
94924 89757 94% 0.24K 2877 33 23016K vm_area_struct
72400 60687 83% 0.31K 2896 25 23168K filp
70553 70484 99% 4.25K 10079 7 322528K names_cache
70112 64605 92% 0.25K 2191 32 17528K kmalloc-128
52458 50837 96% 0.09K 1249 42 4996K anon_vma_chain
23492 22949 97% 4.25K 3356 7 107392K kmalloc-4096
20631 20631 100% 0.10K 529 39 2116K anon_vma
... so it looks like we could be leaking the mm and associated mappings.
Full OOM splat:
[395953.231838] htop invoked oom-killer: gfp_mask=0x16040d0(GFP_TEMPORARY|__GFP_COMP|__GFP_NOTRACK), nodemask=(null), order=0, oom_score_adj=0
[395953.244523] htop cpuset=/ mems_allowed=0
[395953.248556] CPU: 4 PID: 2301 Comm: htop Not tainted 4.11.0-rc6-next-20170411-dirty #7044
[395953.256727] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[395953.264374] Call trace:
[395953.266911] [<ffff20000808c358>] dump_backtrace+0x0/0x3a8
[395953.272394] [<ffff20000808c860>] show_stack+0x20/0x30
[395953.277530] [<ffff2000085a86f0>] dump_stack+0xbc/0xec
[395953.282666] [<ffff2000082d66f8>] dump_header+0xd8/0x328
[395953.287977] [<ffff200008215078>] oom_kill_process+0x400/0x6b0
[395953.293807] [<ffff200008215864>] out_of_memory+0x1ec/0x7c0
[395953.299377] [<ffff20000821d918>] __alloc_pages_nodemask+0xd88/0xe68
[395953.305728] [<ffff20000829bd8c>] alloc_pages_current+0xcc/0x218
[395953.311732] [<ffff2000082a9028>] new_slab+0x420/0x658
[395953.316868] [<ffff2000082ab360>] ___slab_alloc+0x370/0x5d8
[395953.322436] [<ffff2000082ab5ec>] __slab_alloc.isra.22+0x24/0x38
[395953.328438] [<ffff2000082abe5c>] kmem_cache_alloc+0x1bc/0x1e8
[395953.334268] [<ffff200008387eec>] proc_alloc_inode+0x24/0xa8
[395953.339924] [<ffff20000830af14>] alloc_inode+0x3c/0xf0
[395953.345146] [<ffff20000830df90>] new_inode_pseudo+0x20/0x80
[395953.350800] [<ffff20000830e014>] new_inode+0x24/0x50
[395953.355850] [<ffff20000838e860>] proc_pid_make_inode+0x28/0x118
[395953.361853] [<ffff20000838ea78>] proc_pident_instantiate+0x48/0x140
[395953.368204] [<ffff20000838ec6c>] proc_pident_lookup+0xfc/0x168
[395953.374121] [<ffff20000838ed8c>] proc_tgid_base_lookup+0x34/0x40
[395953.380210] [<ffff2000082f77ec>] path_openat+0x194c/0x1b68
[395953.385779] [<ffff2000082f96e0>] do_filp_open+0xe0/0x178
[395953.391178] [<ffff2000082d9f70>] do_sys_open+0x1e8/0x300
[395953.396575] [<ffff2000082da108>] SyS_openat+0x38/0x48
[395953.401710] [<ffff200008083730>] el0_svc_naked+0x24/0x28
[395953.408051] Mem-Info:
[395953.410423] active_anon:3354643 inactive_anon:100 isolated_anon:0
[395953.410423] active_file:16 inactive_file:0 isolated_file:0
[395953.410423] unevictable:0 dirty:0 writeback:0 unstable:0
[395953.410423] slab_reclaimable:15505 slab_unreclaimable:143437
[395953.410423] mapped:0 shmem:155 pagetables:10329 bounce:0
[395953.410423] free:21060 free_pcp:403 free_cma:0
[395953.443636] Node 0 active_anon:13418572kB inactive_anon:400kB active_file:540kB inactive_file:104kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:380kB dirty:0kB writeback:0kB shmem:620kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 12926976kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
[395953.471351] Node 0 DMA free:50620kB min:12828kB low:16884kB high:20940kB active_anon:3989600kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:4194304kB managed:4060788kB mlocked:0kB slab_reclaimable:2928kB slab_unreclaimable:10648kB kernel_stack:0kB pagetables:3600kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[395953.503543] lowmem_reserve[]: 0 9958 9958
[395953.507654] Node 0 Normal free:33004kB min:32224kB low:42420kB high:52616kB active_anon:9428972kB inactive_anon:400kB active_file:132kB inactive_file:80kB unevictable:0kB writepending:0kB present:12582912kB managed:10197388kB mlocked:0kB slab_reclaimable:59092kB slab_unreclaimable:563100kB kernel_stack:4032kB pagetables:37716kB bounce:0kB free_pcp:560kB local_pcp:0kB free_cma:0kB
[395953.541392] lowmem_reserve[]: 0 0 0
[395953.544979] Node 0 DMA: 531*4kB (UME) 210*8kB (UME) 114*16kB (UME) 34*32kB (ME) 18*64kB (UME) 34*128kB (UME) 46*256kB (UM) 14*512kB (UM) 7*1024kB (UM) 0*2048kB 3*4096kB (M) = 50620kB
[395953.561390] Node 0 Normal: 3041*4kB (UMEH) 1694*8kB (UMEH) 447*16kB (UMEH) 10*32kB (U) 2*64kB (H) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 33316kB
[395953.575702] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[395953.584229] 521 total pagecache pages
[395953.587984] 0 pages in swap cache
[395953.591392] Swap cache stats: add 0, delete 0, find 0/0
[395953.596706] Free swap = 0kB
[395953.599677] Total swap = 0kB
[395953.602638] 4194304 pages RAM
[395953.605692] 0 pages HighMem/MovableOnly
[395953.609617] 629760 pages reserved
[395953.613021] 4096 pages cma reserved
[395953.616599] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
[395953.625244] [ 1447] 0 1447 714 74 5 3 0 0 upstart-udev-br
[395953.634818] [ 1450] 0 1450 2758 187 7 3 0 -1000 systemd-udevd
[395953.644218] [ 1833] 0 1833 632 46 5 3 0 0 upstart-socket-
[395953.653790] [ 1847] 0 1847 708 63 5 3 0 0 rpcbind
[395953.662668] [ 1879] 106 1879 737 114 5 3 0 0 rpc.statd
[395953.671734] [ 1984] 0 1984 636 54 5 4 0 0 upstart-file-br
[395953.681307] [ 2000] 103 2000 1152 120 6 3 0 0 dbus-daemon
[395953.690534] [ 2006] 0 2006 720 49 6 3 0 0 rpc.idmapd
[395953.699676] [ 2008] 101 2008 56308 201 12 3 0 0 rsyslogd
[395953.708641] [ 2014] 0 2014 58414 289 16 3 0 0 ModemManager
[395953.717952] [ 2032] 0 2032 1222 87 6 3 0 0 systemd-logind
[395953.727440] [ 2050] 0 2050 61456 371 18 3 0 0 NetworkManager
[395953.736927] [ 2068] 0 2068 587 39 5 3 0 0 getty
[395953.745632] [ 2071] 0 2071 57242 173 14 3 0 0 polkitd
[395953.754510] [ 2075] 0 2075 587 40 5 3 0 0 getty
[395953.763216] [ 2078] 0 2078 587 39 5 3 0 0 getty
[395953.771922] [ 2079] 0 2079 587 38 5 3 0 0 getty
[395953.780628] [ 2081] 0 2081 587 40 5 3 0 0 getty
[395953.789334] [ 2101] 0 2101 2061 163 8 4 0 -1000 sshd
[395953.797952] [ 2102] 0 2102 793 57 6 3 0 0 cron
[395953.806583] [ 2159] 0 2159 542 38 5 3 0 0 getty
[395953.815288] [ 2161] 0 2161 587 40 5 3 0 0 getty
[395953.823992] [ 2171] 0 2171 1356 575 6 4 0 0 dhclient
[395953.832956] [ 2175] 65534 2175 845 58 5 3 0 0 dnsmasq
[395953.841834] [ 2265] 0 2265 3249 261 10 3 0 0 sshd
[395953.850451] [ 2278] 1000 2278 3249 262 9 3 0 0 sshd
[395953.859067] [ 2279] 1000 2279 920 176 5 3 0 0 bash
[395953.867686] [ 2289] 1000 2289 862 63 5 3 0 0 screen
[395953.876479] [ 2290] 1000 2290 1063 286 5 3 0 0 screen
[395953.885272] [ 2291] 1000 2291 930 186 5 3 0 0 bash
[395953.893890] [ 2301] 1000 2301 1190 550 6 3 0 0 htop
[395953.902508] [ 2302] 1000 2302 940 197 5 3 0 0 bash
[395953.911126] [ 2358] 1000 2358 447461 46148 163 5 0 0 qemu-system-aar
[395953.920699] [ 2359] 1000 2359 449502 45509 166 4 0 0 qemu-system-aar
[395953.930271] [ 2360] 1000 2360 447461 43753 160 5 0 0 qemu-system-aar
[395953.939854] [ 2361] 1000 2361 447461 46144 161 4 0 0 qemu-system-aar
[395953.949429] [ 2362] 1000 2362 447461 44522 160 5 0 0 qemu-system-aar
[395953.959001] [ 2363] 1000 2363 447461 44311 161 4 0 0 qemu-system-aar
[395953.968574] [ 4600] 1000 4600 19468 12828 42 5 0 0 syz-manager
[395953.977820] [ 4915] 1000 4915 16364 1127 28 3 0 0 qemu-system-aar
[395953.987397] [ 4917] 1000 4917 16364 1127 27 3 0 0 qemu-system-aar
[395953.996972] [ 4918] 1000 4918 16364 1127 28 3 0 0 qemu-system-aar
[395954.006546] [ 4919] 1000 4919 16364 1128 28 3 0 0 qemu-system-aar
[395954.016119] [ 4920] 1000 4920 16364 617 30 3 0 0 qemu-system-aar
[395954.025692] [ 4922] 1000 4922 14028 344 21 3 0 0 qemu-system-aar
[395954.035273] Out of memory: Kill process 2358 (qemu-system-aar) score 12 or sacrifice child
[395954.043659] Killed process 2358 (qemu-system-aar) total-vm:1789844kB, anon-rss:184592kB, file-rss:0kB, shmem-rss:0kB
[395954.055211] qemu-system-aar: page allocation failure: order:0, mode:0x14201ca(GFP_HIGHUSER_MOVABLE|__GFP_COLD), nodemask=(null)
[395954.066817] qemu-system-aar cpuset=/ mems_allowed=0
[395954.067606] oom_reaper: reaped process 2358 (qemu-system-aar), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
[395954.081761] CPU: 5 PID: 2358 Comm: qemu-system-aar Not tainted 4.11.0-rc6-next-20170411-dirty #7044
[395954.090886] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[395954.098533] Call trace:
[395954.101072] [<ffff20000808c358>] dump_backtrace+0x0/0x3a8
[395954.106555] [<ffff20000808c860>] show_stack+0x20/0x30
[395954.111692] [<ffff2000085a86f0>] dump_stack+0xbc/0xec
[395954.116830] [<ffff20000821ca4c>] warn_alloc+0x144/0x1d8
[395954.122140] [<ffff20000821d9e8>] __alloc_pages_nodemask+0xe58/0xe68
[395954.128491] [<ffff20000829bd8c>] alloc_pages_current+0xcc/0x218
[395954.134494] [<ffff20000820e770>] __page_cache_alloc+0x128/0x150
[395954.140498] [<ffff200008212648>] filemap_fault+0x768/0x940
[395954.146069] [<ffff2000083caf8c>] ext4_filemap_fault+0x4c/0x68
[395954.151898] [<ffff20000825bac4>] __do_fault+0x44/0xd0
[395954.157033] [<ffff200008264c5c>] __handle_mm_fault+0x12c4/0x1978
[395954.163122] [<ffff200008265514>] handle_mm_fault+0x204/0x388
[395954.168865] [<ffff2000080a3994>] do_page_fault+0x3fc/0x4b0
[395954.174434] [<ffff200008081444>] do_mem_abort+0xa4/0x138
[395954.179827] Exception stack(0xffff80034db07dc0 to 0xffff80034db07ef0)
[395954.186352] 7dc0: 0000000000000000 00006003f67fc000 ffffffffffffffff 00000000004109b0
[395954.194266] 7de0: 0000000060000000 0000000000000020 0000000082000007 00000000004109b0
[395954.202179] 7e00: 0000000041b58ab3 ffff20000955d370 ffff2000080813a0 0000000000000124
[395954.210093] 7e20: 0000000000000049 ffff200008f44000 ffff80034db07e40 ffff200008085f60
[395954.218006] 7e40: ffff80034db07e80 ffff20000808b5a0 0000000000000008 ffff80035dde5e80
[395954.225920] 7e60: ffff80035dde5e80 ffff80035dde64f0 ffff80034db07e80 ffff20000808b580
[395954.233833] 7e80: 0000000000000000 ffff200008083618 0000000000000000 00006003f67fc000
[395954.241746] 7ea0: ffffffffffffffff 000000000078d790 0000000060000000 00006003f6813000
[395954.249659] 7ec0: 0000ffffa685f708 0000000000000001 0000000000000001 0000000000000000
[395954.257569] 7ee0: 0000000000000002 0000000000000000
[395954.262530] [<ffff200008083388>] el0_ia+0x18/0x1c
[395954.267433] Mem-Info:
[395954.269806] active_anon:3308476 inactive_anon:100 isolated_anon:0
[395954.269806] active_file:98 inactive_file:570 isolated_file:0
[395954.269806] unevictable:0 dirty:0 writeback:0 unstable:0
[395954.269806] slab_reclaimable:15503 slab_unreclaimable:143557
[395954.269806] mapped:264 shmem:155 pagetables:10329 bounce:0
[395954.269806] free:66173 free_pcp:470 free_cma:0
[395954.303371] Node 0 active_anon:13233904kB inactive_anon:400kB active_file:392kB inactive_file:3320kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:1836kB dirty:0kB writeback:0kB shmem:620kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 12728320kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
[395954.331169] Node 0 DMA free:50620kB min:12828kB low:16884kB high:20940kB active_anon:3989600kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:4194304kB managed:4060788kB mlocked:0kB slab_reclaimable:2928kB slab_unreclaimable:10648kB kernel_stack:0kB pagetables:3600kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[395954.363335] lowmem_reserve[]: 0 9958 9958
[395954.367625] Node 0 Normal free:212516kB min:32224kB low:42420kB high:52616kB active_anon:9244644kB inactive_anon:400kB active_file:548kB inactive_file:3828kB unevictable:0kB writepending:0kB present:12582912kB managed:10197388kB mlocked:0kB slab_reclaimable:59084kB slab_unreclaimable:563912kB kernel_stack:4032kB pagetables:37716kB bounce:0kB free_pcp:1840kB local_pcp:0kB free_cma:0kB
[395954.401710] lowmem_reserve[]: 0 0 0
[395954.405298] Node 0 DMA: 531*4kB (UME) 210*8kB (UME) 114*16kB (UME) 34*32kB (ME) 18*64kB (UME) 34*128kB (UME) 46*256kB (UM) 14*512kB (UM) 7*1024kB (UM) 0*2048kB 3*4096kB (M) = 50620kB
[395954.421698] Node 0 Normal: 1840*4kB (UMEH) 1740*8kB (MEH) 496*16kB (ME) 47*32kB (UME) 25*64kB (MEH) 3*128kB (UME) 2*256kB (UE) 1*512kB (E) 2*1024kB (UE) 61*2048kB (UME) 12*4096kB (M) = 209856kB
[395954.439058] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[395954.447582] 2104 total pagecache pages
[395954.451421] 0 pages in swap cache
[395954.454817] Swap cache stats: add 0, delete 0, find 0/0
[395954.460130] Free swap = 0kB
[395954.463090] Total swap = 0kB
[395954.466057] 4194304 pages RAM
[395954.469111] 0 pages HighMem/MovableOnly
[395954.473035] 629760 pages reserved
[395954.476436] 4096 pages cma reserved
[395954.480151] qemu-system-aar invoked oom-killer: gfp_mask=0x0(), nodemask=(null), order=0, oom_score_adj=0
[395954.489898] qemu-system-aar cpuset=/ mems_allowed=0
[395954.494879] CPU: 5 PID: 2358 Comm: qemu-system-aar Not tainted 4.11.0-rc6-next-20170411-dirty #7044
[395954.504003] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[395954.511651] Call trace:
[395954.514184] [<ffff20000808c358>] dump_backtrace+0x0/0x3a8
[395954.519668] [<ffff20000808c860>] show_stack+0x20/0x30
[395954.524802] [<ffff2000085a86f0>] dump_stack+0xbc/0xec
[395954.529939] [<ffff2000082d66f8>] dump_header+0xd8/0x328
[395954.535248] [<ffff200008215078>] oom_kill_process+0x400/0x6b0
[395954.541078] [<ffff200008215864>] out_of_memory+0x1ec/0x7c0
[395954.546648] [<ffff200008215efc>] pagefault_out_of_memory+0xc4/0xd0
[395954.552911] [<ffff2000080a3a40>] do_page_fault+0x4a8/0x4b0
[395954.558478] [<ffff200008081444>] do_mem_abort+0xa4/0x138
[395954.563872] Exception stack(0xffff80034db07dc0 to 0xffff80034db07ef0)
[395954.570397] 7dc0: 0000000000000000 00006003f67fc000 ffffffffffffffff 00000000004109b0
[395954.578310] 7de0: 0000000060000000 0000000000000020 0000000082000007 00000000004109b0
[395954.586224] 7e00: 0000000041b58ab3 ffff20000955d370 ffff2000080813a0 0000000000000124
[395954.594137] 7e20: 0000000000000049 ffff200008f44000 ffff80034db07e40 ffff200008085f60
[395954.602051] 7e40: ffff80034db07e80 ffff20000808b5a0 0000000000000008 ffff80035dde5e80
[395954.609965] 7e60: ffff80035dde5e80 ffff80035dde64f0 ffff80034db07e80 ffff20000808b580
[395954.617878] 7e80: 0000000000000000 ffff200008083618 0000000000000000 00006003f67fc000
[395954.625791] 7ea0: ffffffffffffffff 000000000078d790 0000000060000000 00006003f6813000
[395954.633704] 7ec0: 0000ffffa685f708 0000000000000001 0000000000000001 0000000000000000
[395954.641614] 7ee0: 0000000000000002 0000000000000000
[395954.646575] [<ffff200008083388>] el0_ia+0x18/0x1c
[395954.651396] Mem-Info:
[395954.653772] active_anon:3308476 inactive_anon:100 isolated_anon:0
[395954.653772] active_file:98 inactive_file:2390 isolated_file:0
[395954.653772] unevictable:0 dirty:0 writeback:0 unstable:0
[395954.653772] slab_reclaimable:15503 slab_unreclaimable:143634
[395954.653772] mapped:1694 shmem:155 pagetables:10329 bounce:0
[395954.653772] free:64244 free_pcp:379 free_cma:0
[395954.687511] Node 0 active_anon:13233904kB inactive_anon:400kB active_file:392kB inactive_file:9820kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:7036kB dirty:0kB writeback:0kB shmem:620kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 12728320kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
[395954.715375] Node 0 DMA free:50620kB min:12828kB low:16884kB high:20940kB active_anon:3989600kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:4194304kB managed:4060788kB mlocked:0kB slab_reclaimable:2928kB slab_unreclaimable:10648kB kernel_stack:0kB pagetables:3600kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[395954.747565] lowmem_reserve[]: 0 9958 9958
[395954.751679] Node 0 Normal free:204900kB min:32224kB low:42420kB high:52616kB active_anon:9244220kB inactive_anon:400kB active_file:548kB inactive_file:10328kB unevictable:0kB writepending:0kB present:12582912kB managed:10197388kB mlocked:0kB slab_reclaimable:59620kB slab_unreclaimable:564176kB kernel_stack:4032kB pagetables:37716kB bounce:0kB free_pcp:1548kB local_pcp:244kB free_cma:0kB
[395954.786024] lowmem_reserve[]: 0 0 0
[395954.789615] Node 0 DMA: 531*4kB (UME) 210*8kB (UME) 114*16kB (UME) 34*32kB (ME) 18*64kB (UME) 34*128kB (UME) 46*256kB (UM) 14*512kB (UM) 7*1024kB (UM) 0*2048kB 3*4096kB (M) = 50620kB
[395954.806097] Node 0 Normal: 600*4kB (UMEH) 1772*8kB (UMEH) 496*16kB (UME) 53*32kB (UME) 25*64kB (UMH) 3*128kB (UME) 1*256kB (U) 1*512kB (U) 1*1024kB (E) 61*2048kB (UME) 12*4096kB (M) = 204064kB
[395954.823477] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[395954.832055] 3171 total pagecache pages
[395954.835933] 0 pages in swap cache
[395954.839343] Swap cache stats: add 0, delete 0, find 0/0
[395954.844670] Free swap = 0kB
[395954.847642] Total swap = 0kB
[395954.850614] 4194304 pages RAM
[395954.853671] 0 pages HighMem/MovableOnly
[395954.857603] 629760 pages reserved
[395954.861023] 4096 pages cma reserved
[395954.864611] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
[395954.873281] [ 1447] 0 1447 714 74 5 3 0 0 upstart-udev-br
[395954.882868] [ 1450] 0 1450 2758 187 7 3 0 -1000 systemd-udevd
[395954.892294] [ 1833] 0 1833 632 46 5 3 0 0 upstart-socket-
[395954.901882] [ 1847] 0 1847 708 63 5 3 0 0 rpcbind
[395954.910766] [ 1879] 106 1879 737 114 5 3 0 0 rpc.statd
[395954.919856] [ 1984] 0 1984 636 54 5 4 0 0 upstart-file-br
[395954.929462] [ 2000] 103 2000 1152 120 6 3 0 0 dbus-daemon
[395954.938701] [ 2006] 0 2006 720 49 6 3 0 0 rpc.idmapd
[395954.947858] [ 2008] 101 2008 56308 201 12 3 0 0 rsyslogd
[395954.957164] [ 2014] 0 2014 58414 289 16 3 0 0 ModemManager
[395954.966503] [ 2032] 0 2032 1222 87 6 3 0 0 systemd-logind
[395954.976004] [ 2050] 0 2050 61456 371 18 3 0 0 NetworkManager
[395954.985531] [ 2068] 0 2068 587 39 5 3 0 0 getty
[395954.994255] [ 2071] 0 2071 57242 173 14 3 0 0 polkitd
[395955.003154] [ 2075] 0 2075 587 40 5 3 0 0 getty
[395955.011878] [ 2078] 0 2078 587 39 5 3 0 0 getty
[395955.020595] [ 2079] 0 2079 587 38 5 3 0 0 getty
[395955.029322] [ 2081] 0 2081 587 40 5 3 0 0 getty
[395955.038135] [ 2101] 0 2101 2061 163 8 4 0 -1000 sshd
[395955.046800] [ 2102] 0 2102 793 57 6 3 0 0 cron
[395955.055432] [ 2159] 0 2159 542 38 5 3 0 0 getty
[395955.064149] [ 2161] 0 2161 587 40 5 3 0 0 getty
[395955.072884] [ 2171] 0 2171 1356 575 6 4 0 0 dhclient
[395955.081874] [ 2175] 65534 2175 845 58 5 3 0 0 dnsmasq
[395955.090981] [ 2265] 0 2265 3249 261 10 3 0 0 sshd
[395955.099760] [ 2278] 1000 2278 3249 262 9 3 0 0 sshd
[395955.108420] [ 2279] 1000 2279 920 176 5 3 0 0 bash
[395955.117050] [ 2289] 1000 2289 862 63 5 3 0 0 screen
[395955.125870] [ 2290] 1000 2290 1063 286 5 3 0 0 screen
[395955.134674] [ 2291] 1000 2291 930 186 5 3 0 0 bash
[395955.143321] [ 2301] 1000 2301 1190 864 6 3 0 0 htop
[395955.151951] [ 2302] 1000 2302 940 197 5 3 0 0 bash
[395955.160595] [ 2358] 1000 2358 447461 0 76 5 0 0 qemu-system-aar
[395955.170175] [ 2359] 1000 2359 449502 45509 166 4 0 0 qemu-system-aar
[395955.180310] [ 2360] 1000 2360 447461 43753 160 5 0 0 qemu-system-aar
[395955.190467] [ 2361] 1000 2361 447461 46180 161 4 0 0 qemu-system-aar
[395955.200204] [ 2362] 1000 2362 447461 44522 160 5 0 0 qemu-system-aar
[395955.209834] [ 2363] 1000 2363 447461 44311 161 4 0 0 qemu-system-aar
[395955.219818] [ 4600] 1000 4600 19468 13943 42 5 0 0 syz-manager
[395955.229412] [ 4915] 1000 4915 16364 1278 28 3 0 0 qemu-system-aar
[395955.239707] [ 4917] 1000 4917 16364 1196 27 3 0 0 qemu-system-aar
[395955.249837] [ 4918] 1000 4918 16364 1473 28 3 0 0 qemu-system-aar
[395955.260569] [ 4919] 1000 4919 16364 1692 28 3 0 0 qemu-system-aar
[395955.270871] [ 4920] 1000 4920 16364 942 30 3 0 0 qemu-system-aar
[395955.280762] [ 4922] 1000 4922 14028 751 21 3 0 0 qemu-system-aar
[395955.290372] Out of memory: Kill process 2361 (qemu-system-aar) score 13 or sacrifice child
[395955.298858] Killed process 2361 (qemu-system-aar) total-vm:1789844kB, anon-rss:184576kB, file-rss:144kB, shmem-rss:0kB
[395955.324751] oom_reaper: reaped process 2361 (qemu-system-aar), now anon-rss:0kB, file-rss:20kB, shmem-rss:0kB
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 0/3] Add support for the S6E3HF2 panel on TM2e board
From: Hoegeun Kwon @ 2017-04-18 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20170418084047epcas5p493261a4cb9204e682f60cde8d659565c@epcas5p4.samsung.com>
Hi all,
The purpose of this patch is add support for s6e3hf2 AMOLED panel on
the TM2e board. The panel has 1600x2560 resolution in 5.65" physical
panel in the TM2e device.
The s6e3hf2 panel(5.65") is simliar to the previous s6e3ha2 panel(5.7"),
but resolution and some command message are different. So it can be
distinguished as a compatiblitiy string.
Best regards,
Hoegeun
Changes for V3:
- Remove te-gpios property in dts.
- Added Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> on all patches.
- Added Reviewed-by: Inki Dae <inki.dae@samsung.com> on patch (2/3).
Changes for V2:
- Add new compatible string to "samsung,s6e3ha2.txt binding with comments.
- Fix the panel name from s6e3ha2-e to s6e3hf2
Hoegeun Kwon (3):
dt-bindings: Add support for samsung s6e3hf2 panel
drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board
arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board
.../bindings/display/panel/samsung,s6e3ha2.txt | 5 +-
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 ++++
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 64 +++++++++++++++++++---
3 files changed, 72 insertions(+), 8 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v3 1/3] dt-bindings: Add support for samsung s6e3hf2 panel
From: Hoegeun Kwon @ 2017-04-18 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492504836-19225-1-git-send-email-hoegeun.kwon@samsung.com>
The samsung s6e3hf2 panel is a 5.65" 1600x2560 AMOLED panel connected
using MIPI-DSI interfaces.
The s6e3hf2 is add to samsung,s6e3ha2.txt binding because it is a
panel similar to the s6e3ha2. So add the compatible string and
comments.
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
---
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
index 18854f4..4acea25 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -1,7 +1,10 @@
Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+Samsung S6E3HF2 5.65" 1600x2560 AMOLED panel
Required properties:
- - compatible: "samsung,s6e3ha2"
+ - compatible: should be one of:
+ "samsung,s6e3ha2",
+ "samsung,s6e3hf2".
- reg: the virtual channel number of a DSI peripheral
- vdd3-supply: I/O voltage supply
- vci-supply: voltage supply for analog circuits
--
1.9.1
^ permalink raw reply related
* [PATCH v3 2/3] drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board
From: Hoegeun Kwon @ 2017-04-18 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492504836-19225-1-git-send-email-hoegeun.kwon@samsung.com>
This patch supports TM2e panel and the panel has 1600x2560 resolution
in 5.65" physical.
This identify panel type with compatibility string, also invoke
display mode that matches the type. So add the check code for s6e3ha2
compatibility and s6e3hf2 type and select the drm_display_mode of
default and edge type.
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Inki Dae <inki.dae@samsung.com>
---
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 64 ++++++++++++++++++++++++---
1 file changed, 57 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 4cc08d7..c7b418b 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -16,6 +16,7 @@
#include <drm/drm_panel.h>
#include <linux/backlight.h>
#include <linux/gpio/consumer.h>
+#include <linux/of_device.h>
#include <linux/regulator/consumer.h>
#define S6E3HA2_MIN_BRIGHTNESS 0
@@ -218,6 +219,16 @@
0x1d, 0x1e, 0x1f, 0x20, 0x21
};
+enum s6e3ha2_type {
+ HA2_TYPE,
+ HF2_TYPE,
+};
+
+struct s6e3ha2_panel_desc {
+ const struct drm_display_mode *mode;
+ enum s6e3ha2_type type;
+};
+
struct s6e3ha2 {
struct device *dev;
struct drm_panel panel;
@@ -226,6 +237,8 @@ struct s6e3ha2 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpio;
struct gpio_desc *enable_gpio;
+
+ const struct s6e3ha2_panel_desc *desc;
};
static int s6e3ha2_dcs_write(struct s6e3ha2 *ctx, const void *data, size_t len)
@@ -283,11 +296,19 @@ static int s6e3ha2_single_dsi_set(struct s6e3ha2 *ctx)
static int s6e3ha2_freq_calibration(struct s6e3ha2 *ctx)
{
s6e3ha2_dcs_write_seq_static(ctx, 0xfd, 0x1c);
+ if (ctx->desc->type == HF2_TYPE)
+ s6e3ha2_dcs_write_seq_static(ctx, 0xf2, 0x67, 0x40, 0xc5);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20, 0x39);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0xa0);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20);
- s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62, 0x40,
- 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
+ if (ctx->desc->type == HA2_TYPE)
+ s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62,
+ 0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+ else
+ s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x14, 0x6d,
+ 0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
return 0;
}
@@ -583,7 +604,7 @@ static int s6e3ha2_enable(struct drm_panel *panel)
return 0;
}
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode s6e3ha2_mode = {
.clock = 222372,
.hdisplay = 1440,
.hsync_start = 1440 + 1,
@@ -597,16 +618,41 @@ static int s6e3ha2_enable(struct drm_panel *panel)
.flags = 0,
};
+static const struct s6e3ha2_panel_desc samsung_s6e3ha2 = {
+ .mode = &s6e3ha2_mode,
+ .type = HA2_TYPE,
+};
+
+static const struct drm_display_mode s6e3hf2_mode = {
+ .clock = 247856,
+ .hdisplay = 1600,
+ .hsync_start = 1600 + 1,
+ .hsync_end = 1600 + 1 + 1,
+ .htotal = 1600 + 1 + 1 + 1,
+ .vdisplay = 2560,
+ .vsync_start = 2560 + 1,
+ .vsync_end = 2560 + 1 + 1,
+ .vtotal = 2560 + 1 + 1 + 15,
+ .vrefresh = 60,
+ .flags = 0,
+};
+
+static const struct s6e3ha2_panel_desc samsung_s6e3hf2 = {
+ .mode = &s6e3hf2_mode,
+ .type = HF2_TYPE,
+};
+
static int s6e3ha2_get_modes(struct drm_panel *panel)
{
struct drm_connector *connector = panel->connector;
+ struct s6e3ha2 *ctx = container_of(panel, struct s6e3ha2, panel);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(panel->drm, &default_mode);
+ mode = drm_mode_duplicate(panel->drm, ctx->desc->mode);
if (!mode) {
DRM_ERROR("failed to add mode %ux%ux@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- default_mode.vrefresh);
+ ctx->desc->mode->hdisplay, ctx->desc->mode->vdisplay,
+ ctx->desc->mode->vrefresh);
return -ENOMEM;
}
@@ -642,6 +688,7 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
mipi_dsi_set_drvdata(dsi, ctx);
ctx->dev = dev;
+ ctx->desc = of_device_get_match_data(dev);
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
@@ -717,7 +764,10 @@ static int s6e3ha2_remove(struct mipi_dsi_device *dsi)
}
static const struct of_device_id s6e3ha2_of_match[] = {
- { .compatible = "samsung,s6e3ha2" },
+ { .compatible = "samsung,s6e3ha2",
+ .data = &samsung_s6e3ha2 },
+ { .compatible = "samsung,s6e3hf2",
+ .data = &samsung_s6e3hf2 },
{ }
};
MODULE_DEVICE_TABLE(of, s6e3ha2_of_match);
--
1.9.1
^ permalink raw reply related
* [PATCH v3 3/3] arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board
From: Hoegeun Kwon @ 2017-04-18 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492504836-19225-1-git-send-email-hoegeun.kwon@samsung.com>
This patch add the panel device tree node for s6e3hf2 display
controller to TM2e dts.
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 694717a..b73e123 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -52,6 +52,17 @@
assigned-clock-rates = <278000000>, <400000000>;
};
+&dsi {
+ panel at 0 {
+ compatible = "samsung,s6e3hf2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ };
+};
+
&ldo31_reg {
regulator-name = "TSP_VDD_1.8V_AP";
regulator-min-microvolt = <1800000>;
--
1.9.1
^ permalink raw reply related
* [PATCH v4 05/11] drm/sun4i: abstract a engine type
From: Maxime Ripard @ 2017-04-18 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170416120849.54542-6-icenowy@aosc.io>
Hi,
Thanks for that rework.
On Sun, Apr 16, 2017 at 08:08:43PM +0800, Icenowy Zheng wrote:
> As we are going to add support for the Allwinner DE2 engine in sun4i-drm
> driver, we will finally have two types of display engines -- the DE1
> backend and the DE2 mixer. They both do some display blending and feed
> graphics data to TCON, so I choose to call them both "engine" here.
>
> Abstract the engine type to void * and a ops struct, which contains
> functions that should be called outside the engine-specified code (in
> TCON, CRTC or TV Encoder code).
>
> A dedicated Kconfig option is also added to control whether
> sun4i-backend-specified code (sun4i_backend.c and sun4i_layer.c) should
> be built. As we removed the codes in CRTC code that directly call the
> layer code, we can now extract the layer part and combine it with the
> backend part into a new module, sun4i-backend.ko.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v4:
> - Comments to tag the color correction functions as optional.
> - Check before calling the optional functions.
> - Change layers_init to satisfy new PATCH v4 04/11.
>
> drivers/gpu/drm/sun4i/Kconfig | 10 ++++++++++
> drivers/gpu/drm/sun4i/Makefile | 6 ++++--
> drivers/gpu/drm/sun4i/sun4i_backend.c | 26 +++++++++++++++++++-------
> drivers/gpu/drm/sun4i/sun4i_backend.h | 5 -----
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 14 +++++++-------
> drivers/gpu/drm/sun4i/sun4i_crtc.h | 7 ++++---
> drivers/gpu/drm/sun4i/sun4i_drv.h | 3 ++-
> drivers/gpu/drm/sun4i/sun4i_layer.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_layer.h | 3 ++-
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_tv.c | 11 ++++++-----
> drivers/gpu/drm/sun4i/sunxi_engine.h | 35 +++++++++++++++++++++++++++++++++++
> 12 files changed, 91 insertions(+), 33 deletions(-)
> create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h
>
> diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
> index a4b357db8856..5a8227f37cc4 100644
> --- a/drivers/gpu/drm/sun4i/Kconfig
> +++ b/drivers/gpu/drm/sun4i/Kconfig
> @@ -12,3 +12,13 @@ config DRM_SUN4I
> Choose this option if you have an Allwinner SoC with a
> Display Engine. If M is selected the module will be called
> sun4i-drm.
> +
> +config DRM_SUN4I_BACKEND
> + tristate "Support for Allwinner A10 Display Engine Backend"
> + depends on DRM_SUN4I
> + default DRM_SUN4I
> + help
> + Choose this option if you have an Allwinner SoC with the
> + original Allwinner Display Engine, which has a backend to
> + do some alpha blending and feed graphics to TCON. If M is
> + selected the module will be called sun4i-backend.
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 59b757350a1f..1db1068b9be1 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -5,9 +5,11 @@ sun4i-tcon-y += sun4i_tcon.o
> sun4i-tcon-y += sun4i_rgb.o
> sun4i-tcon-y += sun4i_dotclock.o
> sun4i-tcon-y += sun4i_crtc.o
> -sun4i-tcon-y += sun4i_layer.o
> +
> +sun4i-backend-y += sun4i_layer.o
> +sun4i-backend-y += sun4i_backend.o
>
> obj-$(CONFIG_DRM_SUN4I) += sun4i-drm.o sun4i-tcon.o
> -obj-$(CONFIG_DRM_SUN4I) += sun4i_backend.o
> +obj-$(CONFIG_DRM_SUN4I_BACKEND) += sun4i-backend.o
> obj-$(CONFIG_DRM_SUN4I) += sun6i_drc.o
> obj-$(CONFIG_DRM_SUN4I) += sun4i_tv.o
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index d660741ba475..a16c96a002a4 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -23,6 +23,8 @@
>
> #include "sun4i_backend.h"
> #include "sun4i_drv.h"
> +#include "sun4i_layer.h"
> +#include "sunxi_engine.h"
>
> static const u32 sunxi_rgb2yuv_coef[12] = {
> 0x00000107, 0x00000204, 0x00000064, 0x00000108,
> @@ -30,9 +32,10 @@ static const u32 sunxi_rgb2yuv_coef[12] = {
> 0x000001c1, 0x00003e88, 0x00003fb8, 0x00000808
> };
>
> -void sun4i_backend_apply_color_correction(struct sun4i_backend *backend)
> +static void sun4i_backend_apply_color_correction(void *engine)
> {
> int i;
> + struct sun4i_backend *backend = engine;
I'm not really fond of passing an opaque pointer here, and hope that
things will work out.
I think having a common structure, holding the common thingsand a more
specific structure for that one would work better.
Something like
struct sunxi_engine {
struct regmap *regs;
};
struct sun4i_backend {
struct sunxi_engine engine;
struct clk *sat_clk;
struct reset_control *sat_reset;
};
static void sun4i_backend_apply_color_correction(struct sunxi_engine *engine)
struct sun4i_backend *backend = container_of(engine, struct sun4i_backend, engine);
...
> +static const struct sunxi_engine_ops sun4i_backend_engine_ops = {
> + .commit = sun4i_backend_commit,
> + .layers_init = sun4i_layers_init,
> + .apply_color_correction = sun4i_backend_apply_color_correction,
> + .disable_color_correction = sun4i_backend_disable_color_correction,
Please align the values with tabs, like done in the other structures
created that way in this driver.
> static void sun4i_crtc_atomic_begin(struct drm_crtc *crtc,
> @@ -56,7 +55,7 @@ static void sun4i_crtc_atomic_flush(struct drm_crtc *crtc,
>
> DRM_DEBUG_DRIVER("Committing plane changes\n");
>
> - sun4i_backend_commit(scrtc->backend);
> + scrtc->engine_ops->commit(scrtc->engine);
You rely on the backend having setup things properly, which is pretty
fragile. Ideally, you should have a function to check that engine_ops
and commit is !NULL, and call it, and the consumers would use that
function...
> @@ -362,7 +361,9 @@ static void sun4i_tv_disable(struct drm_encoder *encoder)
> regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
> SUN4I_TVE_EN_ENABLE,
> 0);
> - sun4i_backend_disable_color_correction(backend);
> +
> + if (crtc->engine_ops->disable_color_correction)
> + crtc->engine_ops->disable_color_correction(crtc->engine);
> }
... Instead of having to do it in some cases, but not always ...
> static void sun4i_tv_enable(struct drm_encoder *encoder)
> @@ -370,11 +371,11 @@ static void sun4i_tv_enable(struct drm_encoder *encoder)
> struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
> struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
> struct sun4i_tcon *tcon = crtc->tcon;
> - struct sun4i_backend *backend = crtc->backend;
>
> DRM_DEBUG_DRIVER("Enabling the TV Output\n");
>
> - sun4i_backend_apply_color_correction(backend);
> + if (crtc->engine_ops->apply_color_correction)
> + crtc->engine_ops->apply_color_correction(crtc->engine);
>
> regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
> SUN4I_TVE_EN_ENABLE,
> diff --git a/drivers/gpu/drm/sun4i/sunxi_engine.h b/drivers/gpu/drm/sun4i/sunxi_engine.h
> new file mode 100644
> index 000000000000..a9128abda66f
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sunxi_engine.h
> @@ -0,0 +1,35 @@
> +/*
> + * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> + *
> + * 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.
> + */
> +
> +#ifndef _SUNXI_ENGINE_H_
> +#define _SUNXI_ENGINE_H_
> +
> +struct sun4i_crtc;
> +
> +struct sunxi_engine_ops {
> + /* Commit the changes to the engine */
> + void (*commit)(void *engine);
> + /* Initialize layers (planes) for this engine */
> + struct drm_plane **(*layers_init)(struct drm_device *drm,
> + struct sun4i_crtc *crtc);
> +
> + /*
> + * These are optional functions for the TV Encoder. Please check
> + * their presence before calling them.
> + *
> + * The first function applies the color space correction needed
> + * for outputing correct TV signal.
> + *
> + * The second function disabled the correction.
> + */
> + void (*apply_color_correction)(void *engine);
> + void (*disable_color_correction)(void *engine);
... And have to document it.
Please also use kerneldoc for those comments.
Thanks again!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170418/751ea7b2/attachment.sig>
^ permalink raw reply
* [PATCH v3 00/32] PCI: fix config and I/O Address space memory mappings
From: Lorenzo Pieralisi @ 2017-04-18 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492044780.7236.87.camel@kernel.crashing.org>
On Thu, Apr 13, 2017 at 10:53:00AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2017-04-12 at 23:45 +0100, Russell King - ARM Linux wrote:
> > On Thu, Apr 13, 2017 at 08:30:40AM +1000, Benjamin Herrenschmidt wrote:
> > > My point with nopost() is that it's never ok to silently downgrade it.
> > > Code written with the assumption that there is no posting will be
> > > *incorrect* if posting happens. We do live with that "bug" today indeed
> > > but once we have that accessors we might start growing more code that
> > > relies on the specific attribute that things aren't posted and will be
> > > wrong on all the archs providing the default implementation.
> > >
> > > This is why I insist that pgprot_nopost() if it exists globally, should
> > > return NULL when the semantic cannot be provided.
> >
> > Now you're not talking sense.??pgprot_nopost() does _not_ return a pointer.
> > You're talking here as if you're still talking about ioremap_nopost().
> > So, I think you're confused.
>
> Nah, just "typo", I meant ioremap_nopost.
>
> > > > > Just like the proposed ioremap_nopost(), pgprot_nonposted() is given a
> > > > > default implementation that uses pgprot_noncached().? Maybe we should
> > > > > also make pci_remap_iospace() fail if pgprot_nonposted() is not defined
> > > > > by the architecture?
> > >
> > > Or we *document* that mmap of IO space can result in something that is
> > > partially non-posted.
> >
> > Oh, so we _can_ provide an interface that has weaker semantics than it
> > should provided we document it.
> >
> > It's insane to have different behaviours from these two interfaces, yet
> > you seem to have said exactly that in your reply.
> >
> > It's actually worse than that - what you've just said is that it's okay
> > for userspace to map IO space with weaker semantics than the PCI
> > specification states, but it's not okay for kernel space to do that.
>
> That is not what I'm saying. What I'm saying is that it's not ok to
> provide a generic mapping attribute that silently happens to be weaker
> than documented on some architectures.
>
> The PCI part is orthogonal. How do you handle PCI in absence of that
> attribute is a separate problem (which is probably a matter of just
> documenting things).
I can add a defined(pgprot_nonposted) to pci_remap_iospace() if that's
not too ugly (I suspect Bjorn is thrilled about it :)), that plus
the Kconfig option for ioremap_nopost() should complete this series.
int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
{
#if defined(PCI_IOBASE) && defined(CONFIG_MMU) && defined(pgprot_nonposted)
unsigned long vaddr = (unsigned long)PCI_IOBASE + res->start;
if (!(res->flags & IORESOURCE_IO))
return -EINVAL;
if (res->end > IO_SPACE_LIMIT)
return -EINVAL
return ioremap_page_range(vaddr, vaddr + resource_size(res), phys_addr,
pgprot_nonposted(PAGE_KERNEL));
#else
/* this architecture does not have memory mapped I/O space,
so this function should never be called */
WARN_ONCE(1, "This architecture does not support memory mapped I/O\n");
return -ENODEV;
#endif
}
^ permalink raw reply
* [PATCH v4 06/11] drm/sun4i: add support for Allwinner DE2 mixers
From: Maxime Ripard @ 2017-04-18 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170416120849.54542-7-icenowy@aosc.io>
On Sun, Apr 16, 2017 at 08:08:44PM +0800, Icenowy Zheng wrote:
> Allwinner have a new "Display Engine 2.0" in their new SoCs, which comes
> with mixers to do graphic processing and feed data to TCON, like the old
> backends and frontends.
>
> Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
>
> Currently a lot of functions are still missing -- more investigations
> are needed to gain enough information for them.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v4:
> - Killed some dead code according to Jernej.
>
> drivers/gpu/drm/sun4i/Kconfig | 10 +
> drivers/gpu/drm/sun4i/Makefile | 4 +
> drivers/gpu/drm/sun4i/sun8i_layer.c | 142 ++++++++++++++
> drivers/gpu/drm/sun4i/sun8i_layer.h | 36 ++++
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 381 ++++++++++++++++++++++++++++++++++++
> drivers/gpu/drm/sun4i/sun8i_mixer.h | 131 +++++++++++++
> 6 files changed, 704 insertions(+)
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
>
> diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
> index 5a8227f37cc4..15557484520d 100644
> --- a/drivers/gpu/drm/sun4i/Kconfig
> +++ b/drivers/gpu/drm/sun4i/Kconfig
> @@ -22,3 +22,13 @@ config DRM_SUN4I_BACKEND
> original Allwinner Display Engine, which has a backend to
> do some alpha blending and feed graphics to TCON. If M is
> selected the module will be called sun4i-backend.
> +
> +config DRM_SUN4I_SUN8I_MIXER
> + tristate "Support for Allwinner Display Engine 2.0 Mixer"
> + depends on DRM_SUN4I
> + default MACH_SUN8I
> + help
> + Choose this option if you have an Allwinner SoC with the
> + Allwinner Display Engine 2.0, which has a mixer to do some
> + graphics mixture and feed graphics to TCON, If M is
> + selected the module will be called sun8i-mixer.
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 1db1068b9be1..7625c2dad1bb 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -9,7 +9,11 @@ sun4i-tcon-y += sun4i_crtc.o
> sun4i-backend-y += sun4i_layer.o
> sun4i-backend-y += sun4i_backend.o
>
> +sun8i-mixer-y += sun8i_layer.o
> +sun8i-mixer-y += sun8i_mixer.o
> +
> obj-$(CONFIG_DRM_SUN4I) += sun4i-drm.o sun4i-tcon.o
> obj-$(CONFIG_DRM_SUN4I_BACKEND) += sun4i-backend.o
> +obj-$(CONFIG_DRM_SUN4I_SUN8I_MIXER) += sun8i-mixer.o
Please align the value using tabs.
> obj-$(CONFIG_DRM_SUN4I) += sun6i_drc.o
> obj-$(CONFIG_DRM_SUN4I) += sun4i_tv.o
> diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c b/drivers/gpu/drm/sun4i/sun8i_layer.c
> new file mode 100644
> index 000000000000..d70a90d963b0
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
> @@ -0,0 +1,142 @@
> +/*
> + * Copyright (C) Icenowy Zheng <icenowy@aosc.io>
> + *
> + * Based on sun4i_layer.h, which is:
> + * Copyright (C) 2015 Free Electrons
> + * Copyright (C) 2015 NextThing Co
> + *
> + * Maxime Ripard <maxime.ripard@free-electrons.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.h>
> +#include <drm/drm_plane_helper.h>
> +#include <drm/drmP.h>
> +
> +#include "sun4i_crtc.h"
> +#include "sun8i_layer.h"
> +#include "sun8i_mixer.h"
> +
> +struct sun8i_plane_desc {
> + enum drm_plane_type type;
> + const uint32_t *formats;
> + uint32_t nformats;
> +};
> +
> +static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + return 0;
> +}
> +
> +static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> +{
> + struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
> + struct sun8i_mixer *mixer = layer->mixer;
> +
> + sun8i_mixer_layer_enable(mixer, layer->id, false);
> +}
> +
> +static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> +{
> + struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
> + struct sun8i_mixer *mixer = layer->mixer;
> +
> + sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
> + sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
> + sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
> + sun8i_mixer_layer_enable(mixer, layer->id, true);
> +}
> +
> +static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = {
> + .atomic_check = sun8i_mixer_layer_atomic_check,
> + .atomic_disable = sun8i_mixer_layer_atomic_disable,
> + .atomic_update = sun8i_mixer_layer_atomic_update,
> +};
> +
> +static const struct drm_plane_funcs sun8i_mixer_layer_funcs = {
> + .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> + .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> + .destroy = drm_plane_cleanup,
> + .disable_plane = drm_atomic_helper_disable_plane,
> + .reset = drm_atomic_helper_plane_reset,
> + .update_plane = drm_atomic_helper_update_plane,
> +};
> +
> +static const uint32_t sun8i_mixer_layer_formats[] = {
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_XRGB8888,
> +};
> +
> +static const struct sun8i_plane_desc sun8i_mixer_planes[] = {
> + {
> + .type = DRM_PLANE_TYPE_PRIMARY,
> + .formats = sun8i_mixer_layer_formats,
> + .nformats = ARRAY_SIZE(sun8i_mixer_layer_formats),
> + },
> +};
> +
> +static struct sun8i_layer *sun8i_layer_init_one(struct drm_device *drm,
> + struct sun8i_mixer *mixer,
> + const struct sun8i_plane_desc *plane)
> +{
> + struct sun8i_layer *layer;
> + int ret;
> +
> + layer = devm_kzalloc(drm->dev, sizeof(*layer), GFP_KERNEL);
> + if (!layer)
> + return ERR_PTR(-ENOMEM);
> +
> + /* possible crtcs are set later */
> + ret = drm_universal_plane_init(drm, &layer->plane, 0,
> + &sun8i_mixer_layer_funcs,
> + plane->formats, plane->nformats,
> + plane->type, NULL);
> + if (ret) {
> + dev_err(drm->dev, "Couldn't initialize layer\n");
> + return ERR_PTR(ret);
> + }
> +
> + drm_plane_helper_add(&layer->plane,
> + &sun8i_mixer_layer_helper_funcs);
> + layer->mixer = mixer;
> +
> + return layer;
> +}
> +
> +struct drm_plane **sun8i_layers_init(struct drm_device *drm,
> + struct sun4i_crtc *crtc)
> +{
> + struct drm_plane **planes;
> + struct sun8i_mixer *mixer = crtc->engine;
> + int i;
> +
> + planes = devm_kcalloc(drm->dev, ARRAY_SIZE(sun8i_mixer_planes) + 1,
> + sizeof(*planes), GFP_KERNEL);
> + if (!planes)
> + return ERR_PTR(-ENOMEM);
> +
> + for (i = 0; i < ARRAY_SIZE(sun8i_mixer_planes); i++) {
> + const struct sun8i_plane_desc *plane = &sun8i_mixer_planes[i];
> + struct sun8i_layer *layer;
> +
> + layer = sun8i_layer_init_one(drm, mixer, plane);
> + if (IS_ERR(layer)) {
> + dev_err(drm->dev, "Couldn't initialize %s plane\n",
> + i ? "overlay" : "primary");
> + return ERR_CAST(layer);
> + };
> +
> + layer->id = i;
> + planes[i] = &layer->plane;
> + };
> +
> + return planes;
> +}
> diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.h b/drivers/gpu/drm/sun4i/sun8i_layer.h
> new file mode 100644
> index 000000000000..fe7e8a069d71
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun8i_layer.h
> @@ -0,0 +1,36 @@
> +/*
> + * Copyright (C) Icenowy Zheng <icenowy@aosc.io>
> + *
> + * Based on sun4i_layer.h, which is:
> + * Copyright (C) 2015 Free Electrons
> + * Copyright (C) 2015 NextThing Co
> + *
> + * Maxime Ripard <maxime.ripard@free-electrons.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.
> + */
> +
> +#ifndef _SUN8I_LAYER_H_
> +#define _SUN8I_LAYER_H_
> +
> +struct sun4i_crtc;
> +
> +struct sun8i_layer {
> + struct drm_plane plane;
> + struct sun4i_drv *drv;
> + struct sun8i_mixer *mixer;
> + int id;
> +};
> +
> +static inline struct sun8i_layer *
> +plane_to_sun8i_layer(struct drm_plane *plane)
> +{
> + return container_of(plane, struct sun8i_layer, plane);
> +}
> +
> +struct drm_plane **sun8i_layers_init(struct drm_device *drm,
> + struct sun4i_crtc *crtc);
> +#endif /* _SUN8I_LAYER_H_ */
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> new file mode 100644
> index 000000000000..5cff3f3833a7
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -0,0 +1,381 @@
> +/*
> + * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> + *
> + * Based on sun4i_backend.c, which is:
> + * Copyright (C) 2015 Free Electrons
> + * Copyright (C) 2015 NextThing Co
> + *
> + * 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/drmP.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_fb_cma_helper.h>
> +#include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_plane_helper.h>
> +
> +#include <linux/component.h>
> +#include <linux/reset.h>
> +#include <linux/of_device.h>
> +
> +#include "sun4i_drv.h"
> +#include "sun8i_mixer.h"
> +#include "sun8i_layer.h"
> +#include "sunxi_engine.h"
> +
> +void sun8i_mixer_commit(void *mixer)
> +{
> + struct sun8i_mixer *sun8i_mixer = mixer;
> +
> + DRM_DEBUG_DRIVER("Committing changes\n");
> +
> + regmap_write(sun8i_mixer->regs, SUN8I_MIXER_GLOBAL_DBUFF,
> + SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
> +}
> +
> +void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
> + int layer, bool enable)
> +{
> + u32 val;
> + /* Currently the first UI channel is used */
> + int chan = mixer->cfg->vi_num;
> +
> + DRM_DEBUG_DRIVER("Enabling layer %d in channel %d\n", layer, chan);
> +
> + if (enable)
> + val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN;
> + else
> + val = 0;
> +
> + regmap_update_bits(mixer->regs,
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
> +
> + /* Set the alpha configuration */
> + regmap_update_bits(mixer->regs,
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK,
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF);
> + regmap_update_bits(mixer->regs,
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK,
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_DEF);
> +}
> +EXPORT_SYMBOL(sun8i_mixer_layer_enable);
Why do you need to export it?
> +
> +static int sun8i_mixer_drm_format_to_layer(struct drm_plane *plane,
> + u32 format, u32 *mode)
> +{
> + switch (format) {
> + case DRM_FORMAT_XRGB8888:
> + *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_XRGB8888;
> + break;
> +
> + case DRM_FORMAT_RGB888:
> + *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_RGB888;
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +int sun8i_mixer_update_layer_coord(struct sun8i_mixer *mixer,
> + int layer, struct drm_plane *plane)
> +{
> + struct drm_plane_state *state = plane->state;
> + struct drm_framebuffer *fb = state->fb;
> + /* Currently the first UI channel is used */
> + int chan = mixer->cfg->vi_num;
> +
> + DRM_DEBUG_DRIVER("Updating layer %d\n", layer);
> +
> + if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
> + DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H: %u\n",
> + state->crtc_w, state->crtc_h);
> + regmap_write(mixer->regs, SUN8I_MIXER_GLOBAL_SIZE,
> + SUN8I_MIXER_SIZE(state->crtc_w,
> + state->crtc_h));
> + DRM_DEBUG_DRIVER("Updating blender size\n");
> + regmap_write(mixer->regs,
> + SUN8I_MIXER_BLEND_ATTR_INSIZE(0),
> + SUN8I_MIXER_SIZE(state->crtc_w,
> + state->crtc_h));
> + regmap_write(mixer->regs, SUN8I_MIXER_BLEND_OUTSIZE,
> + SUN8I_MIXER_SIZE(state->crtc_w,
> + state->crtc_h));
> + DRM_DEBUG_DRIVER("Updating channel size\n");
> + regmap_write(mixer->regs, SUN8I_MIXER_CHAN_UI_OVL_SIZE(chan),
> + SUN8I_MIXER_SIZE(state->crtc_w,
> + state->crtc_h));
> + }
> +
> + /* Set the line width */
> + DRM_DEBUG_DRIVER("Layer line width: %d bytes\n", fb->pitches[0]);
> + regmap_write(mixer->regs, SUN8I_MIXER_CHAN_UI_LAYER_PITCH(chan, layer),
> + fb->pitches[0]);
> +
> + /* Set height and width */
> + DRM_DEBUG_DRIVER("Layer size W: %u H: %u\n",
> + state->crtc_w, state->crtc_h);
> + regmap_write(mixer->regs, SUN8I_MIXER_CHAN_UI_LAYER_SIZE(chan, layer),
> + SUN8I_MIXER_SIZE(state->crtc_w, state->crtc_h));
> +
> + /* Set base coordinates */
> + DRM_DEBUG_DRIVER("Layer coordinates X: %d Y: %d\n",
> + state->crtc_x, state->crtc_y);
> + regmap_write(mixer->regs, SUN8I_MIXER_CHAN_UI_LAYER_COORD(chan, layer),
> + SUN8I_MIXER_COORD(state->crtc_x, state->crtc_y));
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(sun8i_mixer_update_layer_coord);
> +
> +int sun8i_mixer_update_layer_formats(struct sun8i_mixer *mixer,
> + int layer, struct drm_plane *plane)
> +{
> + struct drm_plane_state *state = plane->state;
> + struct drm_framebuffer *fb = state->fb;
> + bool interlaced = false;
> + u32 val;
> + /* Currently the first UI channel is used */
> + int chan = mixer->cfg->vi_num;
> + int ret;
> +
> + if (plane->state->crtc)
> + interlaced = plane->state->crtc->state->adjusted_mode.flags
> + & DRM_MODE_FLAG_INTERLACE;
> +
> + regmap_update_bits(mixer->regs, SUN8I_MIXER_BLEND_OUTCTL,
> + SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
> + interlaced ?
> + SUN8I_MIXER_BLEND_OUTCTL_INTERLACED : 0);
> +
> + DRM_DEBUG_DRIVER("Switching display mixer interlaced mode %s\n",
> + interlaced ? "on" : "off");
You're not using interlaced anywhere.
> +
> + ret = sun8i_mixer_drm_format_to_layer(plane, fb->format->format,
> + &val);
> + if (ret) {
> + DRM_DEBUG_DRIVER("Invalid format\n");
> + return ret;
> + }
> +
> + regmap_update_bits(mixer->regs,
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK, val);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(sun8i_mixer_update_layer_formats);
> +
> +int sun8i_mixer_update_layer_buffer(struct sun8i_mixer *mixer,
> + int layer, struct drm_plane *plane)
> +{
> + struct drm_plane_state *state = plane->state;
> + struct drm_framebuffer *fb = state->fb;
> + struct drm_gem_cma_object *gem;
> + dma_addr_t paddr;
> + uint32_t paddr_u32;
> + /* Currently the first UI channel is used */
> + int chan = mixer->cfg->vi_num;
> + int bpp;
> +
> + /* Get the physical address of the buffer in memory */
> + gem = drm_fb_cma_get_gem_obj(fb, 0);
> +
> + DRM_DEBUG_DRIVER("Using GEM @ %pad\n", &gem->paddr);
> +
> + /* Compute the start of the displayed memory */
> + bpp = fb->format->cpp[0];
> + paddr = gem->paddr + fb->offsets[0];
> + paddr += (state->src_x >> 16) * bpp;
> + paddr += (state->src_y >> 16) * fb->pitches[0];
> +
> + DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
> +
> + paddr_u32 = (uint32_t) paddr;
How does that work on 64-bits systems ?
> +
> + regmap_write(mixer->regs,
> + SUN8I_MIXER_CHAN_UI_LAYER_TOP_LADDR(chan, layer),
> + paddr_u32);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(sun8i_mixer_update_layer_buffer);
> +
> +static const struct sunxi_engine_ops sun8i_engine_ops = {
> + .commit = sun8i_mixer_commit,
> + .layers_init = sun8i_layers_init,
Align with tabs.
> +};
> +
> +static struct regmap_config sun8i_mixer_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = 0xbfffc, /* guessed */
> +};
> +
> +static int sun8i_mixer_bind(struct device *dev, struct device *master,
> + void *data)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct drm_device *drm = data;
> + struct sun4i_drv *drv = drm->dev_private;
> + struct sun8i_mixer *mixer;
> + struct resource *res;
> + void __iomem *regs;
> + int i, ret;
> +
> + mixer = devm_kzalloc(dev, sizeof(*mixer), GFP_KERNEL);
> + if (!mixer)
> + return -ENOMEM;
> + dev_set_drvdata(dev, mixer);
> + drv->engine = mixer;
> + drv->engine_ops = &sun8i_engine_ops;
> +
> + mixer->cfg = of_device_get_match_data(dev);
> + if (!mixer->cfg)
> + return -EINVAL;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + regs = devm_ioremap_resource(dev, res);
> + if (IS_ERR(regs))
> + return PTR_ERR(regs);
> +
> + mixer->regs = devm_regmap_init_mmio(dev, regs,
> + &sun8i_mixer_regmap_config);
> + if (IS_ERR(mixer->regs)) {
> + dev_err(dev, "Couldn't create the mixer regmap\n");
> + return PTR_ERR(mixer->regs);
> + }
> +
> + mixer->reset = devm_reset_control_get(dev, NULL);
> + if (IS_ERR(mixer->reset)) {
> + dev_err(dev, "Couldn't get our reset line\n");
> + return PTR_ERR(mixer->reset);
> + }
> +
> + ret = reset_control_deassert(mixer->reset);
> + if (ret) {
> + dev_err(dev, "Couldn't deassert our reset line\n");
> + return ret;
> + }
> +
> + mixer->bus_clk = devm_clk_get(dev, "bus");
> + if (IS_ERR(mixer->bus_clk)) {
> + dev_err(dev, "Couldn't get the mixer bus clock\n");
> + ret = PTR_ERR(mixer->bus_clk);
> + goto err_assert_reset;
> + }
> + clk_prepare_enable(mixer->bus_clk);
> +
> + mixer->mod_clk = devm_clk_get(dev, "mod");
> + if (IS_ERR(mixer->mod_clk)) {
> + dev_err(dev, "Couldn't get the mixer module clock\n");
> + ret = PTR_ERR(mixer->mod_clk);
> + goto err_disable_bus_clk;
> + }
> + clk_prepare_enable(mixer->mod_clk);
> +
> + /* Reset the registers */
> + for (i = 0x0; i < 0x20000; i += 4)
> + regmap_write(mixer->regs, i, 0);
> +
> + /* Enable the mixer */
> + regmap_write(mixer->regs, SUN8I_MIXER_GLOBAL_CTL,
> + SUN8I_MIXER_GLOBAL_CTL_RT_EN);
> +
> + /* Initialize blender */
> + regmap_write(mixer->regs, SUN8I_MIXER_BLEND_FCOLOR_CTL,
> + SUN8I_MIXER_BLEND_FCOLOR_CTL_DEF);
> + regmap_write(mixer->regs, SUN8I_MIXER_BLEND_PREMULTIPLY,
> + SUN8I_MIXER_BLEND_PREMULTIPLY_DEF);
> + regmap_write(mixer->regs, SUN8I_MIXER_BLEND_BKCOLOR,
> + SUN8I_MIXER_BLEND_BKCOLOR_DEF);
> + regmap_write(mixer->regs, SUN8I_MIXER_BLEND_MODE(0),
> + SUN8I_MIXER_BLEND_MODE_DEF);
> + regmap_write(mixer->regs, SUN8I_MIXER_BLEND_CK_CTL,
> + SUN8I_MIXER_BLEND_CK_CTL_DEF);
> +
> + regmap_write(mixer->regs,
> + SUN8I_MIXER_BLEND_ATTR_FCOLOR(0),
> + SUN8I_MIXER_BLEND_ATTR_FCOLOR_DEF);
> +
> + /* Select the first UI channel */
> + DRM_DEBUG_DRIVER("Selecting channel %d (first UI channel)\n",
> + mixer->cfg->vi_num);
> + regmap_write(mixer->regs, SUN8I_MIXER_BLEND_ROUTE,
> + mixer->cfg->vi_num);
> +
> + return 0;
> +
> + clk_disable_unprepare(mixer->mod_clk);
> +err_disable_bus_clk:
> + clk_disable_unprepare(mixer->bus_clk);
> +err_assert_reset:
> + reset_control_assert(mixer->reset);
> + return ret;
> +}
> +
> +static void sun8i_mixer_unbind(struct device *dev, struct device *master,
> + void *data)
> +{
> + struct sun8i_mixer *mixer = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(mixer->mod_clk);
> + clk_disable_unprepare(mixer->bus_clk);
> + reset_control_assert(mixer->reset);
> +}
> +
> +static const struct component_ops sun8i_mixer_ops = {
> + .bind = sun8i_mixer_bind,
> + .unbind = sun8i_mixer_unbind,
> +};
> +
> +static int sun8i_mixer_probe(struct platform_device *pdev)
> +{
> + return component_add(&pdev->dev, &sun8i_mixer_ops);
> +}
> +
> +static int sun8i_mixer_remove(struct platform_device *pdev)
> +{
> + component_del(&pdev->dev, &sun8i_mixer_ops);
> +
> + return 0;
> +}
> +
> +static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
> + .vi_num = 2,
> + .ui_num = 1,
> +};
> +
> +static const struct of_device_id sun8i_mixer_of_table[] = {
> + {
> + .compatible = "allwinner,sun8i-v3s-de2-mixer",
> + .data = &sun8i_v3s_mixer_cfg,
> + },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, sun8i_mixer_of_table);
> +
> +static struct platform_driver sun8i_mixer_platform_driver = {
> + .probe = sun8i_mixer_probe,
> + .remove = sun8i_mixer_remove,
> + .driver = {
> + .name = "sun8i-mixer",
> + .of_match_table = sun8i_mixer_of_table,
> + },
> +};
> +module_platform_driver(sun8i_mixer_platform_driver);
> +
> +MODULE_AUTHOR("Icenowy Zheng <icenowy@aosc.io>");
> +MODULE_DESCRIPTION("Allwinner DE2 Mixer driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> new file mode 100644
> index 000000000000..a4a365ae44c9
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> @@ -0,0 +1,131 @@
> +/*
> + * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> + *
> + * 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.
> + */
> +
> +#ifndef _SUN8I_MIXER_H_
> +#define _SUN8I_MIXER_H_
> +
> +#include <linux/clk.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +
> +#include "sun4i_layer.h"
> +
> +#define SUN8I_MIXER_MAX_CHAN_COUNT 4
> +
> +#define SUN8I_MIXER_SIZE(w, h) (((h) - 1) << 16 | ((w) - 1))
> +#define SUN8I_MIXER_COORD(x, y) ((y) << 16 | (x))
> +
> +#define SUN8I_MIXER_GLOBAL_CTL 0x0
> +#define SUN8I_MIXER_GLOBAL_STATUS 0x4
> +#define SUN8I_MIXER_GLOBAL_DBUFF 0x8
> +#define SUN8I_MIXER_GLOBAL_SIZE 0xc
> +
> +#define SUN8I_MIXER_GLOBAL_CTL_RT_EN 0x1
> +
> +#define SUN8I_MIXER_GLOBAL_DBUFF_ENABLE 0x1
> +
> +#define SUN8I_MIXER_BLEND_FCOLOR_CTL 0x1000
> +#define SUN8I_MIXER_BLEND_ATTR_FCOLOR(x) (0x1004 + 0x10 * (x) + 0x0)
> +#define SUN8I_MIXER_BLEND_ATTR_INSIZE(x) (0x1004 + 0x10 * (x) + 0x4)
> +#define SUN8I_MIXER_BLEND_ATTR_OFFSET(x) (0x1004 + 0x10 * (x) + 0x8)
> +#define SUN8I_MIXER_BLEND_ROUTE 0x1080
> +#define SUN8I_MIXER_BLEND_PREMULTIPLY 0x1084
> +#define SUN8I_MIXER_BLEND_BKCOLOR 0x1088
> +#define SUN8I_MIXER_BLEND_OUTSIZE 0x108c
> +#define SUN8I_MIXER_BLEND_MODE(x) (0x1090 + 0x04 * (x))
> +#define SUN8I_MIXER_BLEND_CK_CTL 0x10b0
> +#define SUN8I_MIXER_BLEND_CK_CFG 0x10b4
> +#define SUN8I_MIXER_BLEND_CK_MAX(x) (0x10c0 + 0x04 * (x))
> +#define SUN8I_MIXER_BLEND_CK_MIN(x) (0x10e0 + 0x04 * (x))
> +#define SUN8I_MIXER_BLEND_OUTCTL 0x10fc
> +
> +/* The following numbers are some still unknown magic numbers */
> +#define SUN8I_MIXER_BLEND_ATTR_FCOLOR_DEF 0xff000000
> +#define SUN8I_MIXER_BLEND_FCOLOR_CTL_DEF 0x00000101
> +#define SUN8I_MIXER_BLEND_PREMULTIPLY_DEF 0x0
> +#define SUN8I_MIXER_BLEND_BKCOLOR_DEF 0xff000000
> +#define SUN8I_MIXER_BLEND_MODE_DEF 0x03010301
> +#define SUN8I_MIXER_BLEND_CK_CTL_DEF 0x0
> +
> +#define SUN8I_MIXER_BLEND_OUTCTL_INTERLACED BIT(1)
> +
> +/*
> + * VI channels are not used now, but the support of them may be introduced in
> + * the future.
> + */
> +
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ch, layer) \
> + (0x2000 + 0x1000 * (ch) + 0x20 * (layer) + 0x0)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_SIZE(ch, layer) \
> + (0x2000 + 0x1000 * (ch) + 0x20 * (layer) + 0x4)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_COORD(ch, layer) \
> + (0x2000 + 0x1000 * (ch) + 0x20 * (layer) + 0x8)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_PITCH(ch, layer) \
> + (0x2000 + 0x1000 * (ch) + 0x20 * (layer) + 0xc)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_TOP_LADDR(ch, layer) \
> + (0x2000 + 0x1000 * (ch) + 0x20 * (layer) + 0x10)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_BOT_LADDR(ch, layer) \
> + (0x2000 + 0x1000 * (ch) + 0x20 * (layer) + 0x14)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_FCOLOR(ch, layer) \
> + (0x2000 + 0x1000 * (ch) + 0x20 * (layer) + 0x18)
> +#define SUN8I_MIXER_CHAN_UI_TOP_HADDR(ch) (0x2000 + 0x1000 * (ch) + 0x80)
> +#define SUN8I_MIXER_CHAN_UI_BOT_HADDR(ch) (0x2000 + 0x1000 * (ch) + 0x84)
> +#define SUN8I_MIXER_CHAN_UI_OVL_SIZE(ch) (0x2000 + 0x1000 * (ch) + 0x88)
> +
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN BIT(0)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK GENMASK(2, 1)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK GENMASK(11, 8)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK GENMASK(31, 24)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF (1 << 1)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_ARGB8888 (0 << 8)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_XRGB8888 (4 << 8)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_RGB888 (8 << 8)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_DEF (0xff << 24)
> +
> +/*
> + * These sub-engines are still unknown now, the EN registers are here only to
> + * be used to disable these sub-engines.
> + */
> +#define SUN8I_MIXER_VSU_EN 0x20000
> +#define SUN8I_MIXER_GSU1_EN 0x30000
> +#define SUN8I_MIXER_GSU2_EN 0x40000
> +#define SUN8I_MIXER_GSU3_EN 0x50000
> +#define SUN8I_MIXER_FCE_EN 0xa0000
> +#define SUN8I_MIXER_BWS_EN 0xa2000
> +#define SUN8I_MIXER_LTI_EN 0xa4000
> +#define SUN8I_MIXER_PEAK_EN 0xa6000
> +#define SUN8I_MIXER_ASE_EN 0xa8000
> +#define SUN8I_MIXER_FCC_EN 0xaa000
> +#define SUN8I_MIXER_DCSC_EN 0xb0000
> +
> +struct sun8i_mixer_cfg {
> + int vi_num;
> + int ui_num;
> +};
> +
> +struct sun8i_mixer {
> + struct regmap *regs;
> +
> + const struct sun8i_mixer_cfg *cfg;
> +
> + struct reset_control *reset;
> +
> + struct clk *bus_clk;
> + struct clk *mod_clk;
> +};
> +
> +void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
> + int layer, bool enable);
> +int sun8i_mixer_update_layer_coord(struct sun8i_mixer *mixer,
> + int layer, struct drm_plane *plane);
> +int sun8i_mixer_update_layer_formats(struct sun8i_mixer *mixer,
> + int layer, struct drm_plane *plane);
> +int sun8i_mixer_update_layer_buffer(struct sun8i_mixer *mixer,
> + int layer, struct drm_plane *plane);
> +#endif /* _SUN8I_MIXER_H_ */
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170418/d73d9ce6/attachment-0001.sig>
^ 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