* [PATCH v4 2/5] clk: imx6: add EPIT clock support
From: Rob Herring @ 2018-05-31 3:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530120327.27681-3-peron.clem@gmail.com>
On Wed, May 30, 2018 at 02:03:24PM +0200, Cl?ment P?ron wrote:
> From: Colin Didier <colin.didier@devialet.com>
>
> Add EPIT clock support to the i.MX6Q clocking infrastructure.
>
> Signed-off-by: Colin Didier <colin.didier@devialet.com>
> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> drivers/clk/imx/clk-imx6q.c | 2 ++
> include/dt-bindings/clock/imx6qdl-clock.h | 4 +++-
Acked-by: Rob Herring <robh@kernel.org>
> 2 files changed, 5 insertions(+), 1 deletion(-)
^ permalink raw reply
* [PATCH v4 3/5] Documentation: DT: add i.MX EPIT timer binding
From: Rob Herring @ 2018-05-31 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530120327.27681-4-peron.clem@gmail.com>
On Wed, May 30, 2018 at 02:03:25PM +0200, Cl?ment P?ron wrote:
> From: Cl?ment Peron <clement.peron@devialet.com>
"dt-bindings: timer: ..." is the preferred subject prefix.
>
> Add devicetree binding document for NXP's i.MX SoC specific
> EPIT timer driver.
>
> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> ---
> .../devicetree/bindings/timer/fsl,imxepit.txt | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxepit.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,imxepit.txt b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
> new file mode 100644
> index 000000000000..90112d58af10
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
> @@ -0,0 +1,24 @@
> +Binding for the i.MX EPIT timer
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
No need to state this. Listing "clocks" tells us that.
> +
> +Required properties:
> +- compatible: should be "fsl,imx31-epit"
What about imx6q listed below?
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- interrupts: Should contain EPIT controller interrupt
> +- clocks: list of clock specifiers, must contain an entry for each required
> + entry in clock-names
> +- clock-names : should include entries "ipg", "per"
> +
> +Example for i.MX6QDL:
> + epit1: epit at 20d0000 {
timer at ...
> + compatible = "fsl,imx6q-epit", "fsl,imx31-epit";
> + reg = <0x020d0000 0x4000>;
> + interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_IPG_PER>,
> + <&clks IMX6QDL_CLK_EPIT1>;
> + clock-names = "ipg", "per";
> + };
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH v3 1/8] dt-bindings: media: rcar-vin: Describe optional ep properties
From: Rob Herring @ 2018-05-31 3:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527606359-19261-2-git-send-email-jacopo+renesas@jmondi.org>
On Tue, May 29, 2018 at 05:05:52PM +0200, Jacopo Mondi wrote:
> Describe the optional endpoint properties for endpoint nodes of port at 0
> and port at 1 of the R-Car VIN driver device tree bindings documentation.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
>
> ---
> v2 -> v3:
> - Do not repeat property description, just reference video-interfaces.txt
> - Indent with spaces, not tabs as the rest of the document
> - Do not remove (yet) the 'bus-width' property from example
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 2/8] dt-bindings: media: Document data-enable-active property
From: Rob Herring @ 2018-05-31 3:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527606359-19261-3-git-send-email-jacopo+renesas@jmondi.org>
On Tue, May 29, 2018 at 05:05:53PM +0200, Jacopo Mondi wrote:
> Add 'data-enable-active' property to endpoint node properties list.
>
> The property allows to specify the polarity of the data-enable signal, which
> when in active state determinates when data lanes have to sampled for valid
> pixel data.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> v3:
> - new patch
> ---
> Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 4/8] dt-bindings: media: rcar-vin: Add 'data-enable-active'
From: Rob Herring @ 2018-05-31 3:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527606359-19261-5-git-send-email-jacopo+renesas@jmondi.org>
On Tue, May 29, 2018 at 05:05:55PM +0200, Jacopo Mondi wrote:
> Describe optional endpoint property 'data-enable-active' for R-Car VIN.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> v3:
> - new patch
> ---
>
> Documentation/devicetree/bindings/media/rcar_vin.txt | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 6/8] dt-bindings: rcar-vin: Add 'hsync-as-de' custom prop
From: Rob Herring @ 2018-05-31 3:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527606359-19261-7-git-send-email-jacopo+renesas@jmondi.org>
On Tue, May 29, 2018 at 05:05:57PM +0200, Jacopo Mondi wrote:
> Document the boolean custom property 'renesas,hsync-as-de' that indicates
> that the HSYNC signal is internally used as data-enable, when the
> CLKENB signal is not connected.
>
> As this is a VIN specificity create a custom property specific to the R-Car
> VIN driver.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> v3:
> - new patch
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 8/8] ARM: dts: rcar-gen2: Remove unused VIN properties
From: Rob Herring @ 2018-05-31 3:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527606359-19261-9-git-send-email-jacopo+renesas@jmondi.org>
On Tue, May 29, 2018 at 05:05:59PM +0200, Jacopo Mondi wrote:
> The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> driver and only confuse users. Remove them in all Gen2 SoC that use
> them.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> v3:
> - remove bus-width from dt-bindings example
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 1 -
> arch/arm/boot/dts/r8a7790-lager.dts | 3 ---
> arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> arch/arm/boot/dts/r8a7791-porter.dts | 1 -
> arch/arm/boot/dts/r8a7793-gose.dts | 3 ---
> arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> arch/arm/boot/dts/r8a7794-silk.dts | 1 -
> 7 files changed, 13 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 0/5] Add sdmmc UHS support to ROC-RK3328-CC board.
From: djw at t-chip.com.cn @ 2018-05-31 3:27 UTC (permalink / raw)
To: linux-arm-kernel
From: Levin Du <djw@t-chip.com.cn>
Hi all, this is an attemp to add sdmmc UHS support to the
ROC-RK3328-CC board.
This patch series adds a new compatible `rockchip,rk3328-gpio-mute` to
the gpio-syscon driver for the access of the GPIO_MUTE pin in rk3328.
A new gpio controller named `gpio_mute` is defined in
rk3328.dtsi and so that all rk3328 boards has access to it.
The ROC-RK3328-CC board use the new gpio <&gpio_mute 0> in
gpio-regulator to control the signal voltage of the sdmmc.
It is essential for UHS support which requires 1.8V signal voltage.
Many thanks to the Linux people!
Changes in v3:
- Change from general gpio-syscon to specific rk3328-gpio-mute
- Use dedicated "rockchip,rk3328-gpio-mute" driver
- Use <&gpio_mute 0> instead of <&gpio_mute 1> to refer to the GPIO_MUTE pin.
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in doc
- Rename gpio_syscon10 to gpio_mute in rk3328.dtsi
- Rename gpio_syscon10 to gpio_mute in rk3328-roc-cc.dts
Changes in v1:
- New: allow fetching syscon from parent node in gpio-syscon driver
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt
- Split from V0 and add to rk3328.dtsi for general use.
- Split from V0.
- Split into small patches
- Sort dts properties in sdmmc node
Heiko Stuebner (1):
gpio: syscon: allow fetching syscon from parent node
Levin Du (4):
gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
arm64: dts: rockchip: Add GPIO_MUTE pin support to rk3328
arm64: dts: rockchip: Add io-domain to roc-rk3328-cc
arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc
.../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28 ++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 34 ++++++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 7 +++++
drivers/gpio/gpio-syscon.c | 33 +++++++++++++++++++++
4 files changed, 102 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
--
2.7.4
^ permalink raw reply
* [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: djw at t-chip.com.cn @ 2018-05-31 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527737273-8387-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
mute control, can also be used for general purpose. It is manipulated by
the GRF_SOC_CON10 register.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v3:
- Change from general gpio-syscon to specific rk3328-gpio-mute
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in doc
Changes in v1:
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt
.../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28 +++++++++++++++++++
drivers/gpio/gpio-syscon.c | 31 ++++++++++++++++++++++
2 files changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
diff --git a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
new file mode 100644
index 0000000..10bc632
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
@@ -0,0 +1,28 @@
+Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE pin.
+
+In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec mute
+control, can also be used for general purpose. It is manipulated by the
+GRF_SOC_CON10 register.
+
+Required properties:
+- compatible: Should contain "rockchip,rk3328-gpio-mute".
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be 2. The first cell is the pin number and
+ the second cell is used to specify the gpio polarity:
+ 0 = Active high,
+ 1 = Active low.
+
+Example:
+
+ grf: syscon at ff100000 {
+ compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+
+ gpio_mute: gpio-mute {
+ compatible = "rockchip,rk3328-gpio-mute";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
+Note: The gpio_mute node should be declared as the child of the GRF (General
+Register File) node. The GPIO_MUTE pin is referred to as <&gpio_mute 0>.
diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
index 7325b86..49a142a 100644
--- a/drivers/gpio/gpio-syscon.c
+++ b/drivers/gpio/gpio-syscon.c
@@ -135,6 +135,33 @@ static const struct syscon_gpio_data clps711x_mctrl_gpio = {
.dat_bit_offset = 0x40 * 8 + 8,
};
+static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int val)
+{
+ struct syscon_gpio_priv *priv = gpiochip_get_data(chip);
+ unsigned int offs;
+ u8 bit;
+ u32 data;
+ int ret;
+
+ offs = priv->dreg_offset + priv->data->dat_bit_offset + offset;
+ bit = offs % SYSCON_REG_BITS;
+ data = (val ? BIT(bit) : 0) | BIT(bit + 16);
+ ret = regmap_write(priv->syscon,
+ (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE,
+ data);
+ if (ret < 0)
+ dev_err(chip->parent, "gpio write failed ret(%d)\n", ret);
+}
+
+static const struct syscon_gpio_data rockchip_rk3328_gpio_mute = {
+ /* RK3328 GPIO_MUTE is an output only pin at GRF_SOC_CON10[1] */
+ .flags = GPIO_SYSCON_FEAT_OUT,
+ .bit_count = 1,
+ .dat_bit_offset = 0x0428 * 8 + 1,
+ .set = rockchip_gpio_set,
+};
+
#define KEYSTONE_LOCK_BIT BIT(0)
static void keystone_gpio_set(struct gpio_chip *chip, unsigned offset, int val)
@@ -175,6 +202,10 @@ static const struct of_device_id syscon_gpio_ids[] = {
.compatible = "ti,keystone-dsp-gpio",
.data = &keystone_dsp_gpio,
},
+ {
+ .compatible = "rockchip,rk3328-gpio-mute",
+ .data = &rockchip_rk3328_gpio_mute,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, syscon_gpio_ids);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/5] arm64: dts: rockchip: Add GPIO_MUTE pin support to rk3328
From: djw at t-chip.com.cn @ 2018-05-31 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527737273-8387-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
Adding a new gpio controller named "gpio_mute" to rk3328, providing
access to the GPIO_MUTE pin, which is manupulated by the GRF_SOC_CON10
register.
The GPIO_MUTE pin is referred to as <&gpio_mute 0>.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v3:
- Use dedicated "rockchip,rk3328-gpio-mute" driver
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in rk3328.dtsi
Changes in v1:
- Split from V0 and add to rk3328.dtsi for general use.
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index be2bfbc..2ee0fa3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -309,6 +309,13 @@
mode-loader = <BOOT_BL_DOWNLOAD>;
};
+ /* Use <&gpio_mute 0> to refer to GPIO_MUTE pin */
+ gpio_mute: gpio-mute {
+ compatible = "rockchip,rk3328-gpio-mute";
+ gpio-controller;
+ #gpio-cells = <2>;
+ status = "disabled";
+ };
};
uart0: serial at ff110000 {
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/5] arm64: dts: rockchip: Add io-domain to roc-rk3328-cc
From: djw at t-chip.com.cn @ 2018-05-31 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527737273-8387-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
It is necessary for the io domain setting of the SoC to match
the voltage supplied by the regulators.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v3: None
Changes in v2: None
Changes in v1:
- Split from V0.
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index 246c317..b983abd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -208,6 +208,18 @@
};
};
+&io_domains {
+ status = "okay";
+
+ vccio1-supply = <&vcc_io>;
+ vccio2-supply = <&vcc18_emmc>;
+ vccio3-supply = <&vcc_io>;
+ vccio4-supply = <&vcc_18>;
+ vccio5-supply = <&vcc_io>;
+ vccio6-supply = <&vcc_io>;
+ pmuio-supply = <&vcc_io>;
+};
+
&pinctrl {
pmic {
pmic_int_l: pmic-int-l {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: soc: Add TmFifo binding for Mellanox BlueField SoC
From: Rob Herring @ 2018-05-31 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527279436-14773-3-git-send-email-lsun@mellanox.com>
On Fri, May 25, 2018 at 04:17:15PM -0400, Liming Sun wrote:
Commit msg?
> Reviewed-by: David Woods <dwoods@mellanox.com>
> Signed-off-by: Liming Sun <lsun@mellanox.com>
> ---
> .../devicetree/bindings/soc/mellanox/tmfifo.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
>
> diff --git a/Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt b/Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
> new file mode 100644
> index 0000000..0a362f5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
> @@ -0,0 +1,20 @@
> +* Mellanox BlueField SoC TmFifo
> +
> +BlueField TmFifo provides a shared FIFO between the target and the
> +external host machine, which can be accessed via USB or PCIe.
A FIFO for what? I'd like to find a better spot than bindings/soc/
> +
> +Required properties:
> +
> +- compatible: Should be "mellanox,bf-tmfifo"
> +- reg: Physical base address and length of Rx/Tx block
> +- interrupts: The interrupt number of Rx low water mark, Rx high water mark
> + Tx low water mark, Tx high water mark respectively.
> +
> +Example:
> +
> +tmfifo at 800a20 {
> + compatible = "mellanox,bf-tmfifo";
> + reg = <0x00800a20 0x00000018
> + 0x00800a40 0x00000018>;
> + interrupts = <41, 42, 43, 44>;
> +};
> --
> 1.8.3.1
>
> --
> 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 v2 5/9] PM / Domains: dt: Allow power-domain property to be a list of specifiers
From: Rob Herring @ 2018-05-31 3:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529100421.31022-6-ulf.hansson@linaro.org>
On Tue, May 29, 2018 at 12:04:17PM +0200, Ulf Hansson wrote:
> To be able to describe topologies where devices are partitioned across
> multiple power domains, let's extend the power-domain property to allow
> being a list of PM domain specifiers.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree at vger.kernel.org
> Suggested-by: Jon Hunter <jonathanh@nvidia.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
>
> Changes in v2:
> - Fixed comments from Geert. Re-worded to "PM domain specifiers" and
> clarified DT example.
>
> ---
> .../bindings/power/power_domain.txt | 19 ++++++++++++++-----
> 1 file changed, 14 insertions(+), 5 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 12/12] coresight: tmc: Add configuration support for trace buffer size
From: Rob Herring @ 2018-05-31 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527599737-28408-13-git-send-email-suzuki.poulose@arm.com>
On Tue, May 29, 2018 at 02:15:37PM +0100, Suzuki K Poulose wrote:
> Now that we can dynamically switch between contiguous memory and
> SG table depending on the trace buffer size, provide the support
> for selecting an appropriate buffer size.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> .../ABI/testing/sysfs-bus-coresight-devices-tmc | 8 ++++++
> .../devicetree/bindings/arm/coresight.txt | 3 +-
Acked-by: Rob Herring <robh@kernel.org>
> drivers/hwtracing/coresight/coresight-tmc.c | 33 ++++++++++++++++++++++
> 3 files changed, 43 insertions(+), 1 deletion(-)
^ permalink raw reply
* [PATCH v2 05/10] panel/hv070wsa-100: add DT bindings
From: Rob Herring @ 2018-05-31 4:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527682561-1386-6-git-send-email-m.purski@samsung.com>
On Wed, May 30, 2018 at 02:15:56PM +0200, Maciej Purski wrote:
> From: Andrzej Hajda <a.hajda@samsung.com>
"dt-bindings: display: ..." is preferred subject prefix.
>
> The patch adds bindings to BOE HV070-WSA WSVGA panel.
> Bindings are compatible with simple panel bindings.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> Signed-off-by: Maciej Purski <m.purski@samsung.com>
> ---
> .../devicetree/bindings/display/panel/boe,hv070wsa-100.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
> new file mode 100644
> index 0000000..bfc20ac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt
> @@ -0,0 +1,7 @@
> +BOE HV070WSA-100 7.01" WSVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "boe,hv070wsa-100"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
You have to state exactly which properties apply. Does this panel have a
backlight? 1 supply, 2 supplies, no supplies?
Rob
^ permalink raw reply
* [PATCH v2 07/10] dt-bindings: tc358754: add DT bindings
From: Rob Herring @ 2018-05-31 4:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527682561-1386-8-git-send-email-m.purski@samsung.com>
On Wed, May 30, 2018 at 02:15:58PM +0200, Maciej Purski wrote:
> From: Andrzej Hajda <a.hajda@samsung.com>
>
> The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
> Bindings describe power supplies, reset gpio and video interfaces.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> Signed-off-by: Maciej Purski <m.purski@samsung.com>
> ---
> .../bindings/display/bridge/toshiba,tc358764.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> new file mode 100644
> index 0000000..6eda14f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> @@ -0,0 +1,37 @@
> +TC358764 MIPI-DSI to LVDS panel bridge
> +
> +Required properties:
> + - compatible: "toshiba,tc358764"
> + - reg: the virtual channel number of a DSI peripheral
> + - vddc-supply: core voltage supply, 1.2V
> + - vddio-supply: I/O voltage supply, 1.8V or 3.3V
> + - vddlvds-supply: LVDS1/2 voltage supply, 3.3V
> + - reset-gpios: a GPIO spec for the reset pin
> +
> +The device node can contain zero to two 'port' child nodes, each with one
How would 0 ports be valid?
> +child 'endpoint' node, according to the bindings defined in [1].
> +The following are properties specific to those nodes.
> +
> +port:
> + - reg: (required) can be 0 for DSI port or 1 for LVDS port;
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + bridge at 0 {
> + reg = <0>;
> + compatible = "toshiba,tc358764";
> + vddc-supply = <&vcc_1v2_reg>;
> + vddio-supply = <&vcc_1v8_reg>;
> + vddlvds-supply = <&vcc_3v3_reg>;
> + reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port at 1 {
> + reg = <1>;
> + lvds_ep: endpoint {
> + remote-endpoint = <&panel_ep>;
> + };
> + };
> + };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 3/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Rob Herring @ 2018-05-31 4:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530141133.3711-4-faiz_abbas@ti.com>
On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote:
> Add clkctrl data for the m_can clocks and register it within the
> clkctrl driver
>
> CC: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
> drivers/clk/ti/clk-7xx.c | 1 +
> include/dt-bindings/clock/dra7.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
> index fb249a1637a5..71a122b2dc67 100644
> --- a/drivers/clk/ti/clk-7xx.c
> +++ b/drivers/clk/ti/clk-7xx.c
> @@ -708,6 +708,7 @@ static const struct omap_clkctrl_reg_data dra7_wkupaon_clkctrl_regs[] __initcons
> { DRA7_COUNTER_32K_CLKCTRL, NULL, 0, "wkupaon_iclk_mux" },
> { DRA7_UART10_CLKCTRL, dra7_uart10_bit_data, CLKF_SW_SUP, "wkupaon_cm:clk:0060:24" },
> { DRA7_DCAN1_CLKCTRL, dra7_dcan1_bit_data, CLKF_SW_SUP, "wkupaon_cm:clk:0068:24" },
> + { DRA7_ADC_CLKCTRL, NULL, CLKF_SW_SUP, "mcan_clk" },
> { 0 },
> };
>
> diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h
> index 5e1061b15aed..d7549c57cac3 100644
> --- a/include/dt-bindings/clock/dra7.h
> +++ b/include/dt-bindings/clock/dra7.h
> @@ -168,5 +168,6 @@
> #define DRA7_COUNTER_32K_CLKCTRL DRA7_CLKCTRL_INDEX(0x50)
> #define DRA7_UART10_CLKCTRL DRA7_CLKCTRL_INDEX(0x80)
> #define DRA7_DCAN1_CLKCTRL DRA7_CLKCTRL_INDEX(0x88)
> +#define DRA7_ADC_CLKCTRL DRA7_CLKCTRL_INDEX(0xa0)
ADC and mcan are the same thing?
>
> #endif
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Rob Herring @ 2018-05-31 4:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530141133.3711-6-faiz_abbas@ti.com>
On Wed, May 30, 2018 at 07:41:32PM +0530, Faiz Abbas wrote:
> The ti-sysc driver provides support for manipulating the idlemodes
> and interconnect level resets.
>
> Add the generic interconnect target module node for MCAN to support
> the same.
>
> CC: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
> arch/arm/boot/dts/dra76x.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
> index bfc82636999c..57b8dc0fe719 100644
> --- a/arch/arm/boot/dts/dra76x.dtsi
> +++ b/arch/arm/boot/dts/dra76x.dtsi
> @@ -11,6 +11,25 @@
> / {
> compatible = "ti,dra762", "ti,dra7";
>
> + ocp {
> +
> + target-module at 0x42c00000 {
Build your dtb with W=1 and fix warnings you add (drop '0x').
This is a CAN bus controller? If so, then use 'can' for node name.
> + compatible = "ti,sysc-dra7-mcan";
> + ranges = <0x0 0x42c00000 0x2000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x42c01900 0x4>,
> + <0x42c01904 0x4>,
> + <0x42c01908 0x4>;
> + reg-names = "rev", "sysc", "syss";
> + ti,sysc-mask = <(SYSC_OMAP4_SOFTRESET |
> + SYSC_DRA7_MCAN_ENAWAKEUP)>;
> + ti,syss-mask = <1>;
> + clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
> + clock-names = "fck";
> + };
> + };
> +
> };
>
> /* MCAN interrupts are hard-wired to irqs 67, 68 */
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH v2 4/6] bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
From: Rob Herring @ 2018-05-31 4:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530141133.3711-5-faiz_abbas@ti.com>
On Wed, May 30, 2018 at 07:41:31PM +0530, Faiz Abbas wrote:
> The dra76x MCAN generic interconnect module has a its own
> format for the bits in the control registers.
>
> Therefore add a new module type, new regbits and new capabilities
> specific to the MCAN module.
>
> CC: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
> .../devicetree/bindings/bus/ti-sysc.txt | 1 +
> drivers/bus/ti-sysc.c | 17 +++++++++++++++++
> include/dt-bindings/bus/ti-sysc.h | 2 ++
> include/linux/platform_data/ti-sysc.h | 1 +
> 4 files changed, 21 insertions(+)
For the DT bits:
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] PCI: mediatek: Add system pm support for MT2712
From: Bjorn Helgaas @ 2018-05-31 4:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527647736-19986-1-git-send-email-honghui.zhang@mediatek.com>
On Wed, May 30, 2018 at 10:35:36AM +0800, honghui.zhang at mediatek.com wrote:
> From: Honghui Zhang <honghui.zhang@mediatek.com>
>
> The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
> the internel control register will be reset after system resume. The PCIe
> link should be re-established and the related control register values should
> be re-set after system resume.
>
> Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> CC: Ryder Lee <ryder.lee@mediatek.com>
> ---
> drivers/pci/host/pcie-mediatek.c | 82 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 82 insertions(+)
>
> diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> index dabf1086..60f98d92 100644
> --- a/drivers/pci/host/pcie-mediatek.c
> +++ b/drivers/pci/host/pcie-mediatek.c
> @@ -132,12 +132,14 @@ struct mtk_pcie_port;
> /**
> * struct mtk_pcie_soc - differentiate between host generations
> * @need_fix_class_id: whether this host's class ID needed to be fixed or not
> + * @pm_support: whether the host's MTCMOS will be off when suspend
> * @ops: pointer to configuration access functions
> * @startup: pointer to controller setting functions
> * @setup_irq: pointer to initialize IRQ functions
> */
> struct mtk_pcie_soc {
> bool need_fix_class_id;
> + bool pm_support;
> struct pci_ops *ops;
> int (*startup)(struct mtk_pcie_port *port);
> int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> @@ -1179,12 +1181,91 @@ static int mtk_pcie_probe(struct platform_device *pdev)
> return err;
> }
>
> +static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
> +{
> + struct platform_device *pdev;
> + struct mtk_pcie *pcie;
> + struct mtk_pcie_port *port;
> + const struct mtk_pcie_soc *soc;
> +
> + pdev = to_platform_device(dev);
> + pcie = platform_get_drvdata(pdev);
> + soc = pcie->soc;
> + if (!soc->pm_support)
> + return 0;
> +
> + list_for_each_entry(port, &pcie->ports, list) {
> + clk_disable_unprepare(port->ahb_ck);
> + clk_disable_unprepare(port->sys_ck);
> + phy_power_off(port->phy);
> + }
> +
> + return 0;
> +}
> +
> +static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
I don't really like the __maybe_unused annotations. Looking at the
other users of SET_NOIRQ_SYSTEM_SLEEP_PM_OPS, I think a small majority
of them wrap the function definitions in #ifdef CONFIG_PM_SLEEP
instead of using __maybe_unused. That's also a bit ugly, but has the
advantage of truly omitting the definitions when they're not needed.
^ permalink raw reply
* [PATCH 0/9] clk: davinci: outstanding fixes
From: Sekhar Nori @ 2018-05-31 4:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530200947.982.19495@harbor.lan>
On Thursday 31 May 2018 01:39 AM, Michael Turquette wrote:
> Hi David,
>
> Quoting David Lechner (2018-05-25 11:11:41)
>> This is a resend of all of the outstanding DaVinci clock patches plus one new
>> patch. All of the patches (except the new one) have been reviewed and tested
>> by someone other than me.
>>
>> The new patch ("clk: davinci: Fix link errors when not all SoCs are enabled")
>> should be fairly trivial.
>>
>> I am resending them all in one series to hopefully make it easier to get them
>> picked up by having them in the correct order to avoid merge conflicts. This
>> series is based on the clk/clk-davinci-psc-da830 branch.
>
> I picked them all and pushed to clk/clk-davinci based on -rc1. There are
> some comments on the individual patches, all of which are of the "please
> revisit this and fix it up later" variety.
>
> Going forward I'm happy for you and/or Sekhar to send clk PRs to Stephen
> and myself. The same rules apply for PRs: all patches need to be posted
> to the list the old fashioned way for review. But PRs make our lives a
> bit easier, especially when dealing with chip variants from the same SoC
> family like we have with davinci.
Thanks Mike! David is listed as maintainer for drivers/clk/davinci/* and
I believe he can be generating pull requests going forward. I can work
as the backup, of course.
Regards,
Sekhar
^ permalink raw reply
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Bhupesh Sharma @ 2018-05-31 4:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_KSDZyoLNUTAM2d769gQRfbtnGRTcU=8xOrYbmj2O4fA@mail.gmail.com>
Hi Ard,
Sorry I was out for most of the day yesterday. Please see my responses inline.
On Mon, May 28, 2018 at 12:16 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 27 May 2018 at 23:03, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>> Hi ARM64 maintainers,
>>
>> I am confused about the PAGE_OFFSET value (or the start of the linear
>> map) on a KASLR enabled ARM64 kernel that I am seeing on a board which
>> supports a compatible EFI firmware (with EFI_RNG_PROTOCOL support).
>>
>> 1. 'arch/arm64/include/asm/memory.h' defines PAGE_OFFSET as:
>>
>> /*
>> * PAGE_OFFSET - the virtual address of the start of the linear map (top
>> * (VA_BITS - 1))
>> */
>> #define PAGE_OFFSET (UL(0xffffffffffffffff) - \
>> (UL(1) << (VA_BITS - 1)) + 1)
>>
>> So for example on a platform with VA_BITS=48, we have:
>> PAGE_OFFSET = 0xffff800000000000
>>
>> 2. However, for the KASLR case, we set the 'memstart_offset_seed ' to
>> use the 16-bits of the 'kaslr-seed' to randomize the linear region in
>> 'arch/arm64/kernel/kaslr.c' :
>>
>> u64 __init kaslr_early_init(u64 dt_phys)
>> {
>> <snip..>
>> /* use the top 16 bits to randomize the linear region */
>> memstart_offset_seed = seed >> 48;
>> <snip..>
>> }
>>
>> 3. Now, we use the 'memstart_offset_seed' value to randomize the
>> 'memstart_addr' value in 'arch/arm64/mm/init.c':
>>
>> void __init arm64_memblock_init(void)
>> {
>> <snip..>
>>
>> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
>> extern u16 memstart_offset_seed;
>> u64 range = linear_region_size -
>> (memblock_end_of_DRAM() - memblock_start_of_DRAM());
>>
>> /*
>> * If the size of the linear region exceeds, by a sufficient
>> * margin, the size of the region that the available physical
>> * memory spans, randomize the linear region as well.
>> */
>> if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
>> range = range / ARM64_MEMSTART_ALIGN + 1;
>> memstart_addr -= ARM64_MEMSTART_ALIGN *
>> ((range * memstart_offset_seed) >> 16);
>> }
>> }
>> <snip..>
>> }
>>
>> 4. Since 'memstart_addr' indicates the start of physical RAM, we
>> randomize the same on basis of 'memstart_offset_seed' value above.
>> Also the 'memstart_addr' value is available in '/proc/kallsyms' and
>> hence can be accessed by user-space applications to read the
>> 'memstart_addr' value.
>>
>> 5. Now since the PAGE_OFFSET value is also used by several user space
>> tools (for e.g. makedumpfile tool uses the same to determine the start
>> of linear region and hence to read PT_NOTE fields from /proc/kcore), I
>> am not sure how to read the randomized value of the same in the KASLR
>> enabled case.
>>
>> 6. Reading the code further and adding some debug prints, it seems the
>> 'memblock_start_of_DRAM()' value is more closer to the actual start of
>> linear region rather than 'memstart_addr' and 'PAGE_OFFSET" in case of
>> KASLR enabled kernel:
>>
>> [root at qualcomm-amberwing] # dmesg | grep -i "arm64_memblock_init" -A 5
>>
>> [ 0.000000] inside arm64_memblock_init, memstart_addr = ffff976a00000000,
>> linearstart_addr = ffffe89600200000, memblock_start_of_DRAM = ffffe89600200000,
>> PHYS_OFFSET = ffff976a00000000, PAGE_OFFSET = ffff800000000000,
>> KIMAGE_VADDR = ffff000008000000, kimage_vaddr = ffff20c2d7800000
>>
>> [root at qualcomm-amberwing] # dmesg | grep -i "Virtual kernel memory layout" -A 15
>> [ 0.000000] Virtual kernel memory layout:
>> [ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000
>> ( 128 MB)
>> [ 0.000000] vmalloc : 0xffff000008000000 - 0xffff7bdfffff0000
>> (126847 GB)
>> [ 0.000000] .text : 0xffff20c2d7880000 - 0xffff20c2d8040000
>> ( 7936 KB)
>> [ 0.000000] .rodata : 0xffff20c2d8040000 - 0xffff20c2d83a0000
>> ( 3456 KB)
>> [ 0.000000] .init : 0xffff20c2d83a0000 - 0xffff20c2d8750000
>> ( 3776 KB)
>> [ 0.000000] .data : 0xffff20c2d8750000 - 0xffff20c2d891b200
>> ( 1837 KB)
>> [ 0.000000] .bss : 0xffff20c2d891b200 - 0xffff20c2d90a5198
>> ( 7720 KB)
>> [ 0.000000] fixed : 0xffff7fdffe790000 - 0xffff7fdffec00000
>> ( 4544 KB)
>> [ 0.000000] PCI I/O : 0xffff7fdffee00000 - 0xffff7fdfffe00000
>> ( 16 MB)
>> [ 0.000000] vmemmap : 0xffff7fe000000000 - 0xffff800000000000
>> ( 128 GB maximum)
>> [ 0.000000] 0xffff7ffa25800800 - 0xffff7ffa2b800000
>> ( 95 MB actual)
>> [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
>> ( 98302 MB)
>>
>> As one can see above, the 'memblock_start_of_DRAM()' value of
>> 0xffffe89600200000 represents the start of linear region:
>>
>> [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
>> ( 98302 MB)
>>
>> So, my question is to access the start of linear region (which was
>> earlier determinable via PAGE_OFFSET macro), whether I should:
>>
>> - do some back-computation for the start of linear region from the
>> 'memstart_addr' in user-space, or
>> - use a new global variable in kernel which is assigned the value of
>> memblock_start_of_DRAM()' and assign it to '/proc/kallsyms', so that
>> it can be read by user-space tools, or
>> - whether we should rather look at removing the PAGE_OFFSET usage from
>> the kernel and replace it with a global variable instead which is
>> properly updated for KASLR case as well.
>>
>> Kindly share your opinions on what can be a suitable solution in this case.
>>
>> Thanks for your help.
>>
>
> Hello Bhupesh,
>
> Could you explain what the relevance is of PAGE_OFFSET to userland?
> The only thing that should matter is where the actual linear mapping
> of DRAM is, and I am not sure I understand why we care about where it
> resides relative to the base of the linear region.
Actually certain user-space tools like makedumpfile (which is used to
generate and compress the vmcore) and crash-utility (which is used to
debug the vmcore), rely on the PAGE_OFFSET value (which denotes the
base of the linear map region) to determine virtual to physical
mapping of the addresses lying in the linear region .
One specific use case that I am working on at the moment is the
makedumpfile '--mem-usage', which allows one to see the page numbers
of current system (1st kernel) in different use (please see
MAKEDUMPFILE(8) for more details).
Using this we can know how many pages are dumpable when different
dump_level is specified when invoking the makedumpfile.
Normally, makedumpfile analyses the contents of '/proc/kcore' (while
excluding the crashkernel range), and then calculates the page number
of different kind per vmcoreinfo.
For e.g. here is an output from my arm64 board (a non KASLR boot):
TYPE PAGES EXCLUDABLE DESCRIPTION
----------------------------------------------------------------------
ZERO 49524 yes Pages
filled with zero
NON_PRI_CACHE 15143 yes Cache
pages without private flag
PRI_CACHE 29147 yes Cache
pages with private flag
USER 3684 yes User process pages
FREE 1450569 yes Free pages
KERN_DATA 14243 no Dumpable kernel data
page size: 65536
Total pages on system: 1562310
Total size on system: 102387548160 Byte
This use case requires directly reading the '/proc/kcore' and the
hence the PAGE_OFFSET value is used to determine the base address of
the linear region, whose value is not static in case of KASLR boot.
Another use-case is where the crash-utility uses the PAGE_OFFSET value
to perform a virtual-to-physical conversion for the address lying in
the linear region:
ulong
arm64_VTOP(ulong addr)
{
if (machdep->flags & NEW_VMEMMAP) {
if (addr >= machdep->machspec->page_offset)
return machdep->machspec->phys_offset
+ (addr - machdep->machspec->page_offset);
<..snip..>
}
Regards,
Bhupesh
^ permalink raw reply
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Bhupesh Sharma @ 2018-05-31 4:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHM4w1nFn0T0MOF7=hnE7kxAmH4gLbbXXb_BjjKwEqyNFtqYwA@mail.gmail.com>
Hi Pratyush,
Thanks for your reply. Please see my replies inline:
On Wed, May 30, 2018 at 8:05 AM, Pratyush Anand
<pratyush.anand@gmail.com> wrote:
> Hi Bhupesh,
>
>
> On Mon, May 28, 2018 at 2:33 AM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>> Hi ARM64 maintainers,
>
> [...]
>
>>
>> 4. Since 'memstart_addr' indicates the start of physical RAM, we
>> randomize the same on basis of 'memstart_offset_seed' value above.
>> Also the 'memstart_addr' value is available in '/proc/kallsyms' and
>> hence can be accessed by user-space applications to read the
>> 'memstart_addr' value.
>
> User space can read, only when a system has either CONFIG_DEVMEM or
> CONFIG_PROC_KCORE enabled. But, we can have a system which has
> CONFIG_RANDOMIZE_BASE enabled but none of the kernel memory access
> interface (other than kdump/vmcore).
>
>>
>> 5. Now since the PAGE_OFFSET value is also used by several user space
>> tools (for e.g. makedumpfile tool uses the same to determine the start
>> of linear region and hence to read PT_NOTE fields from /proc/kcore), I
>> am not sure how to read the randomized value of the same in the KASLR
>> enabled case.
>>
>
> Do we have a use case other than makedumpfile (I mean where we do not
> have vmcore access)? For makedumpfile, we have following information
> in vmcore, and I hope, that should be sufficient to find physical
> address of any symbol from vmcore.
>
> 358 VMCOREINFO_NUMBER(VA_BITS);
> 359 /* Please note VMCOREINFO_NUMBER() uses "%d", not "%x" */
> 360 vmcoreinfo_append_str("NUMBER(kimage_voffset)=0x%llx\n",
> 361 kimage_voffset);
> 362 vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
> 363 PHYS_OFFSET);
>
Please see more details in a mail I sent as a reply to Ard (in this
thread itself), but one specific use case that I am working on at the
moment is the makedumpfile '--mem-usage' for KASLR enabled arm64
kernels.
This use case requires directly reading the '/proc/kcore' and the
hence the PAGE_OFFSET value is used to determine the base address of
the linear region, whose value is not static in case of KASLR boot.
Another use-case is where the crash-utility uses the PAGE_OFFSET value
to perform a virtual-to-physical conversion for the address lying in
the linear region:
ulong
arm64_VTOP(ulong addr)
{
if (machdep->flags & NEW_VMEMMAP) {
if (addr >= machdep->machspec->page_offset)
return machdep->machspec->phys_offset
+ (addr - machdep->machspec->page_offset);
<..snip..>
}
There might be other use-cases (which I am unaware about), but
presently I am seeing issues with the above two use-cases in case of
KASLR enabled arm64 kernels and trying to find out possible acceptable
solutions.
Regards,
Bhupesh
^ permalink raw reply
* [PATCH v9 01/15] ARM: Add Krait L2 register accessor functions
From: Sricharan R @ 2018-05-31 4:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152769571081.144038.4314499217001219157@swboyd.mtv.corp.google.com>
Hi Stephen,
On 5/30/2018 9:25 PM, Stephen Boyd wrote:
> Quoting Sricharan R (2018-05-24 22:40:11)
>> Hi Bjorn,
>>
>> On 5/24/2018 11:09 PM, Bjorn Andersson wrote:
>>> On Tue 06 Mar 06:38 PST 2018, Sricharan R wrote:
>>>
>>>> From: Stephen Boyd <sboyd@codeaurora.org>
>>>>
>>>> Krait CPUs have a handful of L2 cache controller registers that
>>>> live behind a cp15 based indirection register. First you program
>>>> the indirection register (l2cpselr) to point the L2 'window'
>>>> register (l2cpdr) at what you want to read/write. Then you
>>>> read/write the 'window' register to do what you want. The
>>>> l2cpselr register is not banked per-cpu so we must lock around
>>>> accesses to it to prevent other CPUs from re-pointing l2cpdr
>>>> underneath us.
>>>>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>>>
>>> This should have your signed-off-by here as well.
>>>
>>
>> ok.
>>
>>> Apart from that:
>>>
>>> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>
>>
>
> Will these patches come around again? I'll do a quick sweep on them
> today but I expect them to be resent.
Sure, i will have to resend them again, fixing couple of Bjorn's
minor comments. Will address your comments that you would give
as well along with that.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* [PATCH v3 5/5] arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc
From: djw at t-chip.com.cn @ 2018-05-31 5:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527737273-8387-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by
the vcc_sdio regulator, which is a mux between 1.8V and 3.3V,
controlled by a special output only gpio pin labeled
"gpiomut_pmuio_iout", corresponding bit 1 of the syscon GRF_SOC_CON10.
This special pin can now be reference as <&gpio_mute 0>, thanks
to the gpio-syscon driver, which makes writing regulator-gpio possible.
If the signal voltage changes, the io domain needs to change
correspondingly.
To use this feature, the following options are required in kernel config:
- CONFIG_GPIO_SYSCON=y
- CONFIG_POWER_AVS=y
- CONFIG_ROCKCHIP_IODOMAIN=y
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v3:
- Use <&gpio_mute 0> instead of <&gpio_mute 1> to refer to the GPIO_MUTE pin.
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in rk3328-roc-cc.dts
Changes in v1:
- Split into small patches
- Sort dts properties in sdmmc node
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index b983abd..25c1111 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -41,6 +41,19 @@
vin-supply = <&vcc_io>;
};
+ vcc_sdio: sdmmcio-regulator {
+ compatible = "regulator-gpio";
+ gpios = <&gpio_mute 0 GPIO_ACTIVE_HIGH>;
+ states = <1800000 0x1
+ 3300000 0x0>;
+ regulator-name = "vcc_sdio";
+ regulator-type = "voltage";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
compatible = "regulator-fixed";
enable-active-high;
@@ -213,7 +226,7 @@
vccio1-supply = <&vcc_io>;
vccio2-supply = <&vcc18_emmc>;
- vccio3-supply = <&vcc_io>;
+ vccio3-supply = <&vcc_sdio>;
vccio4-supply = <&vcc_18>;
vccio5-supply = <&vcc_io>;
vccio6-supply = <&vcc_io>;
@@ -242,7 +255,12 @@
max-frequency = <150000000>;
pinctrl-names = "default";
pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_dectn &sdmmc0_bus4>;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
vmmc-supply = <&vcc_sd>;
+ vqmmc-supply = <&vcc_sdio>;
status = "okay";
};
@@ -277,3 +295,7 @@
&usb_host0_ohci {
status = "okay";
};
+
+&gpio_mute {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox