* [PATCH v2 2/7] dt-bindings: firmware: scm: re-order compatible list
From: Sibi Sankar @ 2019-08-07 7:09 UTC (permalink / raw)
To: bjorn.andersson, robh+dt, vkoul, aneela
Cc: mark.rutland, agross, linux-kernel, linux-arm-msm, devicetree,
jassisinghbrar, clew, Sibi Sankar
In-Reply-To: <20190807070957.30655-1-sibis@codeaurora.org>
re-order compatible list to maintain sort order.
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
Documentation/devicetree/bindings/firmware/qcom,scm.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index 41f133a4e2fa7..d19be836df533 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -9,13 +9,13 @@ Required properties:
- compatible: must contain one of the following:
* "qcom,scm-apq8064"
* "qcom,scm-apq8084"
+ * "qcom,scm-ipq4019"
* "qcom,scm-msm8660"
* "qcom,scm-msm8916"
* "qcom,scm-msm8960"
* "qcom,scm-msm8974"
* "qcom,scm-msm8996"
* "qcom,scm-msm8998"
- * "qcom,scm-ipq4019"
* "qcom,scm-sdm845"
and:
* "qcom,scm"
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v2 1/7] soc: qcom: smem: Update max processor count
From: Sibi Sankar @ 2019-08-07 7:09 UTC (permalink / raw)
To: bjorn.andersson, robh+dt, vkoul, aneela
Cc: mark.rutland, agross, linux-kernel, linux-arm-msm, devicetree,
jassisinghbrar, clew, Sibi Sankar
In-Reply-To: <20190807070957.30655-1-sibis@codeaurora.org>
Update max processor count to reflect the number of
co-processors on SC7180 SoCs.
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
drivers/soc/qcom/smem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index f27c00d82ae49..bef8502625f96 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -84,7 +84,7 @@
#define SMEM_GLOBAL_HOST 0xfffe
/* Max number of processors/hosts in a system */
-#define SMEM_HOST_COUNT 10
+#define SMEM_HOST_COUNT 11
/**
* struct smem_proc_comm - proc_comm communication struct (legacy)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v2 0/7] Add support for Qualcomm SM8150 and SC7180 SoCs
From: Sibi Sankar @ 2019-08-07 7:09 UTC (permalink / raw)
To: bjorn.andersson, robh+dt, vkoul, aneela
Cc: mark.rutland, agross, linux-kernel, linux-arm-msm, devicetree,
jassisinghbrar, clew, Sibi Sankar
This patch series adds SCM, APSS shared mailbox and QMP AOSS PD/clock
support on SM8150 and SC7180 SoCs.
v2:
* re-arrange the compatible lists in sort order
Sibi Sankar (7):
soc: qcom: smem: Update max processor count
dt-bindings: firmware: scm: re-order compatible list
dt-bindings: firmware: scm: Add SM8150 and SC7180 support
dt-bindings: mailbox: Add APSS shared for SM8150 and SC7180 SoCs
mailbox: qcom: Add support for Qualcomm SM8150 and SC7180 SoCs
dt-bindings: soc: qcom: aoss: Add SM8150 and SC7180 support
soc: qcom: aoss: Add AOSS QMP support
Documentation/devicetree/bindings/firmware/qcom,scm.txt | 4 +++-
.../devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt | 2 ++
Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt | 5 ++++-
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 2 ++
drivers/soc/qcom/qcom_aoss.c | 2 ++
drivers/soc/qcom/smem.c | 2 +-
6 files changed, 14 insertions(+), 3 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH RFC 6/7] pwm: rcar: Add gpio support to output duty zero
From: Uwe Kleine-König @ 2019-08-07 7:03 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: linus.walleij, geert+renesas, thierry.reding, robh+dt,
mark.rutland, linux-gpio, linux-pwm, devicetree,
linux-renesas-soc
In-Reply-To: <1562576868-8124-7-git-send-email-yoshihiro.shimoda.uh@renesas.com>
Hello,
On Mon, Jul 08, 2019 at 06:07:47PM +0900, Yoshihiro Shimoda wrote:
> The R-Car SoCs PWM Timer cannot output duty zero. So, this patch
> adds gpio support to output it.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> drivers/pwm/pwm-rcar.c | 36 ++++++++++++++++++++++++++++++++++--
> 1 file changed, 34 insertions(+), 2 deletions(-)
I'd like to see a paragraph at the top of the driver describing the
limitations of this driver similar to what pwm-sifive.c does.
Something like:
diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index 5b2b8ecc354c..b67ac84db834 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -3,6 +3,9 @@
* R-Car PWM Timer driver
*
* Copyright (C) 2015 Renesas Electronics Corporation
+ *
+ * Limitations:
+ * - The hardware cannot generate a 0% duty cycle.
*/
#include <linux/clk.h>
While at it: If there is a publicly available reference manual adding a line:
Reference Manual: https://...
would be great, too.
> diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
> index c8cd43f..1c19a8b 100644
> --- a/drivers/pwm/pwm-rcar.c
> +++ b/drivers/pwm/pwm-rcar.c
> @@ -7,6 +7,7 @@
>
> #include <linux/clk.h>
> #include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/io.h>
> #include <linux/log2.h>
> #include <linux/math64.h>
> @@ -38,6 +39,7 @@ struct rcar_pwm_chip {
> struct pwm_chip chip;
> void __iomem *base;
> struct clk *clk;
> + struct gpio_desc *gpio;
> };
>
> static inline struct rcar_pwm_chip *to_rcar_pwm_chip(struct pwm_chip *chip)
> @@ -119,8 +121,11 @@ static int rcar_pwm_set_counter(struct rcar_pwm_chip *rp, int div, int duty_ns,
> ph = tmp & RCAR_PWMCNT_PH0_MASK;
>
> /* Avoid prohibited setting */
> - if (cyc == 0 || ph == 0)
> + if (cyc == 0)
> return -EINVAL;
> + /* Try to use GPIO to output duty zero */
> + if (ph == 0)
> + return -EAGAIN;
If there is no gpio requesting cyc=0 should still yield an error.
> rcar_pwm_write(rp, cyc | ph, RCAR_PWMCNT);
>
> @@ -157,6 +162,28 @@ static void rcar_pwm_disable(struct rcar_pwm_chip *rp)
> rcar_pwm_update(rp, RCAR_PWMCR_EN0, 0, RCAR_PWMCR);
> }
>
> +static int rcar_pwm_gpiod_get(struct rcar_pwm_chip *rp)
> +{
> + if (rp->gpio)
> + return 0;
> +
> + rp->gpio = gpiod_get(rp->chip.dev, "renesas,duty-zero", GPIOD_OUT_LOW);
> + if (!IS_ERR(rp->gpio))
> + return 0;
> +
> + rp->gpio = NULL;
> + return -EINVAL;
Please use gpiod_get_optional() instead of open coding it.
Does getting the gpio automatically switch the pinmuxing?
If yes, this is IMHO a really surprising mis-feature of the gpio
subsystem. I'd prefer to "get" the gpio at probe time and only switch
the pinmuxing in .apply(). This makes .apply() quicker, ensures that all
resources necessary for pwm operation are available, handles
-EPROBE_DEFER (and maybe other errors) correctly.
Note you're introducing a bug here because switching to gpio doesn't
ensure that the currently running period is completed.
> +static void rcar_pwm_gpiod_put(struct rcar_pwm_chip *rp)
> +{
> + if (!rp->gpio)
> + return;
> +
> + gpiod_put(rp->gpio);
> + rp->gpio = NULL;
> +}
> +
> static int rcar_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> struct pwm_state *state)
> {
> @@ -171,6 +198,7 @@ static int rcar_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>
> if (!state->enabled) {
> rcar_pwm_disable(rp);
> + rcar_pwm_gpiod_put(rp);
>From the framework's POV disabling a PWM is quite similar to duty cycle
0. Assuming disabling the PWM completes the currently running period[1]
it might be better and easier to disable instead of switching to gpio.
(Further assuming that disable really yields the inactive level which is
should and is another limitation if not.)
> return 0;
> }
>
> @@ -187,8 +215,12 @@ static int rcar_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> /* The SYNC should be set to 0 even if rcar_pwm_set_counter failed */
> rcar_pwm_update(rp, RCAR_PWMCR_SYNC, 0, RCAR_PWMCR);
>
> - if (!ret)
> + if (!ret) {
> ret = rcar_pwm_enable(rp);
> + rcar_pwm_gpiod_put(rp);
> + } else if (ret == -EAGAIN) {
> + ret = rcar_pwm_gpiod_get(rp);
> + }
>
> return ret;
> }
Best regards
Uwe
[1] if not, please add "Disabling doesn't complete the currently running
period" to the list of limitations.
--
Pengutronix e.K. | Uwe Kleine-K�nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply related
* Re: [PATCH v4 2/4] RISC-V: Add riscv_isa reprensenting ISA features common across CPUs
From: Anup Patel @ 2019-08-07 6:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Atish Patra, linux-kernel@vger.kernel.org List, Mark Rutland,
devicetree, Albert Ou, Daniel Lezcano, Alan Kao,
Greg Kroah-Hartman, Anup Patel, Johan Hovold, Rob Herring,
Palmer Dabbelt, Paul Walmsley, linux-riscv, Enrico Weigelt,
Thomas Gleixner
In-Reply-To: <20190807065119.GA7825@infradead.org>
On Wed, Aug 7, 2019 at 12:21 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Fri, Aug 02, 2019 at 09:27:21PM -0700, Atish Patra wrote:
> > From: Anup Patel <anup.patel@wdc.com>
> >
> > This patch adds riscv_isa integer to represent ISA features common
> > across all CPUs. The riscv_isa is not same as elf_hwcap because
> > elf_hwcap will only have ISA features relevant for user-space apps
> > whereas riscv_isa will have ISA features relevant to both kernel
> > and user-space apps.
> >
> > One of the use case is KVM hypervisor where riscv_isa will be used
> > to do following operations:
>
> Please add this to the kvm series. Right now this is just dead code.
Sure, I will include this patch in KVM series.
Regards,
Anup
^ permalink raw reply
* Re: [PATCH v4 2/4] RISC-V: Add riscv_isa reprensenting ISA features common across CPUs
From: Christoph Hellwig @ 2019-08-07 6:51 UTC (permalink / raw)
To: Atish Patra
Cc: linux-kernel, Mark Rutland, devicetree, Albert Ou, Daniel Lezcano,
Alan Kao, Greg Kroah-Hartman, Anup Patel, Johan Hovold,
Rob Herring, Palmer Dabbelt, Paul Walmsley, linux-riscv,
Enrico Weigelt, Thomas Gleixner
In-Reply-To: <20190803042723.7163-3-atish.patra@wdc.com>
On Fri, Aug 02, 2019 at 09:27:21PM -0700, Atish Patra wrote:
> From: Anup Patel <anup.patel@wdc.com>
>
> This patch adds riscv_isa integer to represent ISA features common
> across all CPUs. The riscv_isa is not same as elf_hwcap because
> elf_hwcap will only have ISA features relevant for user-space apps
> whereas riscv_isa will have ISA features relevant to both kernel
> and user-space apps.
>
> One of the use case is KVM hypervisor where riscv_isa will be used
> to do following operations:
Please add this to the kvm series. Right now this is just dead code.
^ permalink raw reply
* Re: [PATCH RFC 5/7] pwm: rcar: remove a redundant condition in rcar_pwm_apply()
From: Uwe Kleine-König @ 2019-08-07 6:33 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: linus.walleij, geert+renesas, thierry.reding, robh+dt,
mark.rutland, linux-gpio, linux-pwm, devicetree,
linux-renesas-soc
In-Reply-To: <1562576868-8124-6-git-send-email-yoshihiro.shimoda.uh@renesas.com>
Hello,
On Mon, Jul 08, 2019 at 06:07:46PM +0900, Yoshihiro Shimoda wrote:
> Since the rcar_pwm_apply() has already check whehter state->enabled
> is not set or not, this patch removes a redundant condition.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de>
This patch (and also patch 6 of this series) doesn't seem to have made
it to the pwm list and pwm patchwork.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K�nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] riscv: dts: sifive: Add missing "clock-frequency" to cpu0/cpu1 nodes
From: Bin Meng @ 2019-08-07 6:22 UTC (permalink / raw)
To: Albert Ou, Palmer Dabbelt, Paul Walmsley, devicetree,
linux-kernel, linux-riscv
Add the missing "clock-frequency" property to the cpu0/cpu1 nodes
for consistency with other cpu nodes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
index 42b5ec2..4befc70 100644
--- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
+++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
@@ -22,6 +22,7 @@
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
+ clock-frequency = <0>;
compatible = "sifive,e51", "sifive,rocket0", "riscv";
device_type = "cpu";
i-cache-block-size = <64>;
@@ -37,6 +38,7 @@
};
};
cpu1: cpu@1 {
+ clock-frequency = <0>;
compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
d-cache-block-size = <64>;
d-cache-sets = <64>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: rockchip: Add dts for Leez RK3399 P710 SBC
From: Andy Yan @ 2019-08-07 6:14 UTC (permalink / raw)
To: Rob Herring
Cc: heiko@sntech.de, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:ARM/Rockchip SoC..., linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqJ6_J1pR-MYK5kmUN5Q+tX32UNFqLW81tmBf=pYxtAmjg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
Hi Rob:
Rob Herring <robh+dt@kernel.org> 于2019年8月6日周二 下午10:48写道：
> On Mon, Aug 5, 2019 at 6:40 AM Andy Yan <andyshrk@gmail.com> wrote:
> >
> > P710 is a RK3399 based SBC, designed by Leez [0].
> >
> > Specification
> > - Rockchip RK3399
> > - 4/2GB LPDDR4
> > - TF sd scard slot
> > - eMMC
> > - M.2 B-Key for 4G LTE
> > - AP6256 for WiFi + BT
> > - Gigabit ethernet
> > - HDMI out
> > - 40 pin header
> > - USB 2.0 x 2
> > - USB 3.0 x 1
> > - USB 3.0 Type-C x 1
> > - TYPE-C Power supply
> >
> > [0]https://leez.lenovo.com
>
> I'm not really convinced Leez is a vendor. Looks like branding to me.
> We have enough with company names changing, we don't need changing
> brands too. Use 'lenovo'.
>
>
I had checked with Leez people before V1, they said Leez will run as an
independent company, so they don't want to
give a lenovo label for this board.
Rob
>
[-- Attachment #2: Type: text/html, Size: 1668 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i: a83t: Enable HDMI output on Cubietruck Plus
From: Chen-Yu Tsai @ 2019-08-07 6:06 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: Maxime Ripard, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20190728145944.4091-1-wens@kernel.org>
On Sun, Jul 28, 2019 at 10:59 PM Chen-Yu Tsai <wens@kernel.org> wrote:
>
> From: Chen-Yu Tsai <wens@csie.org>
>
> The Cubietruck Plus has an HDMI connector tied to the HDMI output of the
> SoC.
>
> Enables display output via HDMI on the Cubietruck Plus. The connector
> device node is named "hdmi-connector" as there is also a display port
> connector, which is tied to the MIPI DSI output of the SoC through a
> MIPI-DSI-to-DP bridge. This part is not supported yet.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied for 5.4.
^ permalink raw reply
* [PATCH v5 4/4] drm/mediatek: control dpi pins dpi or gpio mode in on or off
From: Jitao Shi @ 2019-08-07 6:02 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: Jitao Shi, Thierry Reding, Ajay Kumar, Inki Dae, Rahul Sharma,
Sean Paul, Vincent Palatin, Andy Yan, Philipp Zabel, Russell King,
devicetree, linux-kernel, dri-devel, linux-arm-kernel,
linux-mediatek, srv_heupstream, Sascha Hauer, yingjoe.chen,
eddie.huang, cawa.cheng, bibby.hsieh, ck.hu
In-Reply-To: <20190807060257.57007-1-jitao.shi@mediatek.com>
Pull dpi pins low when dpi has nothing to display. Aovid leakage
current from some dpi pins (Hsync Vsync DE ... ).
Some chips have dpi pins, but there are some chip don't have pins.
So this function is controlled by device tree.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 39 +++++++++++++++++++++++++++++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 4f2700cbfdb7..83fb0d753f72 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -9,10 +9,12 @@
#include <drm/drm_of.h>
#include <linux/kernel.h>
#include <linux/component.h>
-#include <linux/platform_device.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_gpio.h>
#include <linux/of_graph.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/platform_device.h>
#include <linux/interrupt.h>
#include <linux/types.h>
#include <linux/clk.h>
@@ -71,8 +73,12 @@ struct mtk_dpi {
enum mtk_dpi_out_yc_map yc_map;
enum mtk_dpi_out_bit_num bit_num;
enum mtk_dpi_out_channel_swap channel_swap;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pins_gpio;
+ struct pinctrl_state *pins_dpi;
int refcount;
bool dual_edge;
+ bool dpi_pin_ctrl;
};
static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
@@ -384,6 +390,9 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi)
if (--dpi->refcount != 0)
return;
+ if (dpi->dpi_pin_ctrl)
+ pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
+
mtk_dpi_disable(dpi);
clk_disable_unprepare(dpi->pixel_clk);
clk_disable_unprepare(dpi->engine_clk);
@@ -408,6 +417,9 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi)
goto err_pixel;
}
+ if (dpi->dpi_pin_ctrl)
+ pinctrl_select_state(dpi->pinctrl, dpi->pins_dpi);
+
mtk_dpi_enable(dpi);
return 0;
@@ -713,6 +725,31 @@ static int mtk_dpi_probe(struct platform_device *pdev)
dpi->dev = dev;
dpi->conf = (struct mtk_dpi_conf *)of_device_get_match_data(dev);
dpi->dual_edge = of_property_read_bool(dev->of_node, "dpi_dual_edge");
+ dpi->dpi_pin_ctrl = of_property_read_bool(dev->of_node,
+ "dpi_pin_mode_swap");
+
+ if (dpi->dpi_pin_ctrl) {
+ dpi->pinctrl = devm_pinctrl_get(&pdev->dev);
+ if (IS_ERR(dpi->pinctrl)) {
+ dev_err(&pdev->dev, "Cannot find pinctrl!\n");
+ return PTR_ERR(dpi->pinctrl);
+ }
+
+ dpi->pins_gpio = pinctrl_lookup_state(dpi->pinctrl,
+ "gpiomode");
+ if (IS_ERR(dpi->pins_gpio)) {
+ dev_err(&pdev->dev, "Cannot find pinctrl gpiomode!\n");
+ return PTR_ERR(dpi->pins_gpio);
+ }
+
+ pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
+
+ dpi->pins_dpi = pinctrl_lookup_state(dpi->pinctrl, "dpimode");
+ if (IS_ERR(dpi->pins_dpi)) {
+ dev_err(&pdev->dev, "Cannot find pinctrl dpimode!\n");
+ return PTR_ERR(dpi->pins_dpi);
+ }
+ }
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dpi->regs = devm_ioremap_resource(dev, mem);
--
2.21.0
^ permalink raw reply related
* [PATCH v5 3/4] drm/mediatek: add mt8183 dpi clock factor
From: Jitao Shi @ 2019-08-07 6:02 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190807060257.57007-1-jitao.shi@mediatek.com>
The factor depends on the divider of DPI in MT8183, therefore,
we should fix this factor to the right and new one.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 743230864ba0..4f2700cbfdb7 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -672,6 +672,16 @@ static unsigned int mt2701_calculate_factor(int clock)
return 1;
}
+static unsigned int mt8183_calculate_factor(int clock)
+{
+ if (clock <= 27000)
+ return 8;
+ else if (clock <= 167000)
+ return 4;
+ else
+ return 2;
+}
+
static const struct mtk_dpi_conf mt8173_conf = {
.cal_factor = mt8173_calculate_factor,
.reg_h_fre_con = 0xe0,
@@ -683,6 +693,11 @@ static const struct mtk_dpi_conf mt2701_conf = {
.edge_sel_en = true,
};
+static const struct mtk_dpi_conf mt8183_conf = {
+ .cal_factor = mt8183_calculate_factor,
+ .reg_h_fre_con = 0xe0,
+};
+
static int mtk_dpi_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -779,6 +794,9 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
{ .compatible = "mediatek,mt8173-dpi",
.data = &mt8173_conf,
},
+ { .compatible = "mediatek,mt8183-dpi",
+ .data = &mt8183_conf,
+ },
{ },
};
--
2.21.0
^ permalink raw reply related
* [PATCH v5 2/4] drm/mediatek: dpi dual edge support
From: Jitao Shi @ 2019-08-07 6:02 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: Jitao Shi, Thierry Reding, Ajay Kumar, Inki Dae, Rahul Sharma,
Sean Paul, Vincent Palatin, Andy Yan, Philipp Zabel, Russell King,
devicetree, linux-kernel, dri-devel, linux-arm-kernel,
linux-mediatek, srv_heupstream, Sascha Hauer, yingjoe.chen,
eddie.huang, cawa.cheng, bibby.hsieh, ck.hu
In-Reply-To: <20190807060257.57007-1-jitao.shi@mediatek.com>
DPI sample the data both rising and falling edge.
It can reduce half data io pins.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index bacd989cc9aa..743230864ba0 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -72,6 +72,7 @@ struct mtk_dpi {
enum mtk_dpi_out_bit_num bit_num;
enum mtk_dpi_out_channel_swap channel_swap;
int refcount;
+ bool dual_edge;
};
static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
@@ -345,6 +346,13 @@ static void mtk_dpi_config_disable_edge(struct mtk_dpi *dpi)
mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
}
+static void mtk_dpi_enable_dual_edge(struct mtk_dpi *dpi)
+{
+ mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
+ DDR_EN | DDR_4PHASE);
+ mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, EDGE_SEL, EDGE_SEL);
+}
+
static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
enum mtk_dpi_out_color_format format)
{
@@ -436,7 +444,8 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
pll_rate = clk_get_rate(dpi->tvd_clk);
vm.pixelclock = pll_rate / factor;
- clk_set_rate(dpi->pixel_clk, vm.pixelclock);
+ clk_set_rate(dpi->pixel_clk,
+ vm.pixelclock * (dpi->dual_edge ? 2 : 1));
vm.pixelclock = clk_get_rate(dpi->pixel_clk);
dev_dbg(dpi->dev, "Got PLL %lu Hz, pixel clock %lu Hz\n",
@@ -501,6 +510,8 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
mtk_dpi_config_color_format(dpi, dpi->color_format);
mtk_dpi_config_2n_h_fre(dpi);
mtk_dpi_config_disable_edge(dpi);
+ if (dpi->dual_edge)
+ mtk_dpi_enable_dual_edge(dpi);
mtk_dpi_sw_reset(dpi, false);
return 0;
@@ -686,6 +697,7 @@ static int mtk_dpi_probe(struct platform_device *pdev)
dpi->dev = dev;
dpi->conf = (struct mtk_dpi_conf *)of_device_get_match_data(dev);
+ dpi->dual_edge = of_property_read_bool(dev->of_node, "dpi_dual_edge");
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dpi->regs = devm_ioremap_resource(dev, mem);
--
2.21.0
^ permalink raw reply related
* [PATCH v5 1/4] dt-bindings: display: mediatek: update dpi supported chips
From: Jitao Shi @ 2019-08-07 6:02 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: Jitao Shi, Thierry Reding, Ajay Kumar, Inki Dae, Rahul Sharma,
Sean Paul, Vincent Palatin, Andy Yan, Philipp Zabel, Russell King,
devicetree, linux-kernel, dri-devel, linux-arm-kernel,
linux-mediatek, srv_heupstream, Sascha Hauer, yingjoe.chen,
eddie.huang, cawa.cheng, bibby.hsieh, ck.hu
In-Reply-To: <20190807060257.57007-1-jitao.shi@mediatek.com>
Add decriptions about supported chips, including MT2701 & MT8173 &
mt8183
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
.../bindings/display/mediatek/mediatek,dpi.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
index b6a7e7397b8b..cd6a1469c8b7 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
@@ -7,6 +7,7 @@ output bus.
Required properties:
- compatible: "mediatek,<chip>-dpi"
+ the supported chips are mt2701 , mt8173 and mt8183.
- reg: Physical base address and length of the controller's registers
- interrupts: The interrupt signal from the function block.
- clocks: device clocks
@@ -16,6 +17,11 @@ Required properties:
Documentation/devicetree/bindings/graph.txt. This port should be connected
to the input port of an attached HDMI or LVDS encoder chip.
+Optional properties:
+- dpi_pin_mode_swap: Swap the pin mode between dpi mode and gpio mode.
+- pinctrl-names: Contain "gpiomode" and "dpimode".
+- dpi_dual_edge: Control the RGB 24bit data on 12 pins or 24 pins.
+
Example:
dpi0: dpi@1401d000 {
@@ -26,6 +32,11 @@ dpi0: dpi@1401d000 {
<&mmsys CLK_MM_DPI_ENGINE>,
<&apmixedsys CLK_APMIXED_TVDPLL>;
clock-names = "pixel", "engine", "pll";
+ dpi_dual_edge;
+ dpi_pin_mode_swap;
+ pinctrl-names = "gpiomode", "dpimode";
+ pinctrl-0 = <&dpi_pin_gpio>;
+ pinctrl-1 = <&dpi_pin_func>;
port {
dpi0_out: endpoint {
--
2.21.0
^ permalink raw reply related
* [PATCH v5 0/4] add mt8183 dpi driver
From: Jitao Shi @ 2019-08-07 6:02 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: Jitao Shi, Thierry Reding, Ajay Kumar, Inki Dae, Rahul Sharma,
Sean Paul, Vincent Palatin, Andy Yan, Philipp Zabel, Russell King,
devicetree, linux-kernel, dri-devel, linux-arm-kernel,
linux-mediatek, srv_heupstream, Sascha Hauer, yingjoe.chen,
eddie.huang, cawa.cheng, bibby.hsieh, ck.hu
Changes since v4:
- move pin mode control and dual edge control to deveice tree.
- update dt-bindings document for pin mode swap and dual edge control.
Changes since v3:
- add dpi pin mode control when dpi on or off.
- update dpi dual edge comment.
Changes since v2:
- update dt-bindings document for mt8183 dpi.
- separate dual edge modfication as independent patch.
Jitao Shi (4):
dt-bindings: display: mediatek: update dpi supported chips
drm/mediatek: dpi dual edge support
drm/mediatek: add mt8183 dpi clock factor
drm/mediatek: control dpi pins dpi or gpio mode in on or off
.../display/mediatek/mediatek,dpi.txt | 11 +++
drivers/gpu/drm/mediatek/mtk_dpi.c | 71 ++++++++++++++++++-
2 files changed, 80 insertions(+), 2 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [PATCH v4 2/4] RISC-V: Add riscv_isa reprensenting ISA features common across CPUs
From: Anup Patel @ 2019-08-07 4:12 UTC (permalink / raw)
To: Paul Walmsley
Cc: Mark Rutland, devicetree, Albert Ou, Alan Kao, Greg Kroah-Hartman,
Daniel Lezcano, linux-kernel@vger.kernel.org List, Johan Hovold,
Atish Patra, Anup Patel, Rob Herring, Palmer Dabbelt, linux-riscv,
Enrico Weigelt, Thomas Gleixner
In-Reply-To: <alpine.DEB.2.21.9999.1908061452570.13971@viisi.sifive.com>
On Wed, Aug 7, 2019 at 3:24 AM Paul Walmsley <paul.walmsley@sifive.com> wrote:
>
> Hi Anup, Atish,
>
> On Fri, 2 Aug 2019, Atish Patra wrote:
>
> > From: Anup Patel <anup.patel@wdc.com>
> >
> > This patch adds riscv_isa integer to represent ISA features common
> > across all CPUs. The riscv_isa is not same as elf_hwcap because
> > elf_hwcap will only have ISA features relevant for user-space apps
> > whereas riscv_isa will have ISA features relevant to both kernel
> > and user-space apps.
> >
> > One of the use case is KVM hypervisor where riscv_isa will be used
> > to do following operations:
> >
> > 1. Check whether hypervisor extension is available
> > 2. Find ISA features that need to be virtualized (e.g. floating
> > point support, vector extension, etc.)
> >
> > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
>
> Do you have any opinions on how this patch might change for the Z-prefix
> extensions? This bitfield approach probably won't scale, and with the
> EXPORT_SYMBOL(), it might be worth trying to put together a approach that
> would work over the long term?
Our plan is to use bitmap instead of bitfield and all Zxyz extensions will be
assigned bit positions "27 + i" where "i" will be based on order in-which they
are defined in RISC-V spec. In general, "i" is just a unique relative index
(starting from 0).
To summarize, the existing bitfield approach can be naturally extended
using bitmap.
We will update this patch accordingly.
Regards,
Anup
^ permalink raw reply
* [PATCH v1 1/1] i2c: iproc: Add i2c repeated start capability
From: Rayagonda Kokatanur @ 2019-08-07 4:09 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland
Cc: devicetree, Lori Hikichi, Florian Fainelli, Shivaraj Shetty,
Rayagonda Kokatanur, linux-kernel, Icarus Chau, Ray Jui,
linux-i2c, bcm-kernel-feedback-list, linux-arm-kernel
From: Lori Hikichi <lori.hikichi@broadcom.com>
Enable handling of i2c repeated start. The current code
handles a multi msg i2c transfer as separate i2c bus
transactions. This change will now handle this case
using the i2c repeated start protocol. The number of msgs
in a transfer is limited to two, and must be a write
followed by a read.
Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Signed-off-by: Icarus Chau <icarus.chau@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Shivaraj Shetty <sshetty1@broadcom.com>
---
drivers/i2c/busses/i2c-bcm-iproc.c | 70 +++++++++++++++++++++++++++++++-------
1 file changed, 57 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
index d7fd76b..15fedcf 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -81,6 +81,7 @@
#define M_CMD_PROTOCOL_MASK 0xf
#define M_CMD_PROTOCOL_BLK_WR 0x7
#define M_CMD_PROTOCOL_BLK_RD 0x8
+#define M_CMD_PROTOCOL_PROCESS 0xa
#define M_CMD_PEC_SHIFT 8
#define M_CMD_RD_CNT_SHIFT 0
#define M_CMD_RD_CNT_MASK 0xff
@@ -675,13 +676,20 @@ static int bcm_iproc_i2c_xfer_wait(struct bcm_iproc_i2c_dev *iproc_i2c,
return 0;
}
-static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
- struct i2c_msg *msg)
+/*
+ * If 'process_call' is true, then this is a multi-msg transfer that requires
+ * a repeated start between the messages.
+ * More specifically, it must be a write (reg) followed by a read (data).
+ * The i2c quirks are set to enforce this rule.
+ */
+static int bcm_iproc_i2c_xfer_internal(struct bcm_iproc_i2c_dev *iproc_i2c,
+ struct i2c_msg *msgs, bool process_call)
{
int i;
u8 addr;
u32 val, tmp, val_intr_en;
unsigned int tx_bytes;
+ struct i2c_msg *msg = &msgs[0];
/* check if bus is busy */
if (!!(iproc_i2c_rd_reg(iproc_i2c,
@@ -707,14 +715,29 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
val = msg->buf[i];
/* mark the last byte */
- if (i == msg->len - 1)
- val |= BIT(M_TX_WR_STATUS_SHIFT);
+ if (!process_call && (i == msg->len - 1))
+ val |= 1 << M_TX_WR_STATUS_SHIFT;
iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
}
iproc_i2c->tx_bytes = tx_bytes;
}
+ /* Process the read message if this is process call */
+ if (process_call) {
+ msg++;
+ iproc_i2c->msg = msg; /* point to second msg */
+
+ /*
+ * The last byte to be sent out should be a slave
+ * address with read operation
+ */
+ addr = msg->addr << 1 | 1;
+ /* mark it the last byte out */
+ val = addr | (1 << M_TX_WR_STATUS_SHIFT);
+ iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
+ }
+
/* mark as incomplete before starting the transaction */
if (iproc_i2c->irq)
reinit_completion(&iproc_i2c->done);
@@ -733,7 +756,7 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
* underrun interrupt, which will be triggerred when the TX FIFO is
* empty. When that happens we can then pump more data into the FIFO
*/
- if (!(msg->flags & I2C_M_RD) &&
+ if (!process_call && !(msg->flags & I2C_M_RD) &&
msg->len > iproc_i2c->tx_bytes)
val_intr_en |= BIT(IE_M_TX_UNDERRUN_SHIFT);
@@ -743,6 +766,8 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
*/
val = BIT(M_CMD_START_BUSY_SHIFT);
if (msg->flags & I2C_M_RD) {
+ u32 protocol;
+
iproc_i2c->rx_bytes = 0;
if (msg->len > M_RX_FIFO_MAX_THLD_VALUE)
iproc_i2c->thld_bytes = M_RX_FIFO_THLD_VALUE;
@@ -758,7 +783,10 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
/* enable the RX threshold interrupt */
val_intr_en |= BIT(IE_M_RX_THLD_SHIFT);
- val |= (M_CMD_PROTOCOL_BLK_RD << M_CMD_PROTOCOL_SHIFT) |
+ protocol = process_call ?
+ M_CMD_PROTOCOL_PROCESS : M_CMD_PROTOCOL_BLK_RD;
+
+ val |= (protocol << M_CMD_PROTOCOL_SHIFT) |
(msg->len << M_CMD_RD_CNT_SHIFT);
} else {
val |= (M_CMD_PROTOCOL_BLK_WR << M_CMD_PROTOCOL_SHIFT);
@@ -774,17 +802,31 @@ static int bcm_iproc_i2c_xfer(struct i2c_adapter *adapter,
struct i2c_msg msgs[], int num)
{
struct bcm_iproc_i2c_dev *iproc_i2c = i2c_get_adapdata(adapter);
- int ret, i;
+ bool process_call = false;
+ int ret;
- /* go through all messages */
- for (i = 0; i < num; i++) {
- ret = bcm_iproc_i2c_xfer_single_msg(iproc_i2c, &msgs[i]);
- if (ret) {
- dev_dbg(iproc_i2c->device, "xfer failed\n");
- return ret;
+ if (num > 2) {
+ dev_err(iproc_i2c->device,
+ "Only support up to 2 messages. Current msg count %d\n",
+ num);
+ return -EOPNOTSUPP;
+ }
+
+ if (num == 2) {
+ /* Repeated start, use process call */
+ process_call = true;
+ if (msgs[1].flags & I2C_M_NOSTART) {
+ dev_err(iproc_i2c->device, "Invalid repeated start\n");
+ return -EOPNOTSUPP;
}
}
+ ret = bcm_iproc_i2c_xfer_internal(iproc_i2c, msgs, process_call);
+ if (ret) {
+ dev_dbg(iproc_i2c->device, "xfer failed\n");
+ return ret;
+ }
+
return num;
}
@@ -806,6 +848,8 @@ static uint32_t bcm_iproc_i2c_functionality(struct i2c_adapter *adap)
};
static struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
+ .flags = I2C_AQ_COMB_WRITE_THEN_READ,
+ .max_comb_1st_msg_len = M_TX_RX_FIFO_SIZE,
.max_read_len = M_RX_MAX_READ_LEN,
};
--
1.9.1
^ permalink raw reply related
* [PATCH nvmem v2 2/2] dt-bindings: fsl: scu: add new compatible string for ocotp
From: fugang.duan @ 2019-08-07 4:03 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: robh, mark.rutland, s.hauer, shawnguo, fugang.duan, kernel,
gregkh, festevam, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20190807040320.1760-1-fugang.duan@nxp.com>
From: Fugang Duan <fugang.duan@nxp.com>
Add new compatible string "fsl,imx8qm-scu-ocotp" into binding
doc for i.MX8 SCU OCOTP driver.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index a575e42..c149fad 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -136,7 +136,9 @@ Required properties:
OCOTP bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
-- compatible: Should be "fsl,imx8qxp-scu-ocotp"
+- compatible: Should be one of:
+ "fsl,imx8qm-scu-ocotp",
+ "fsl,imx8qxp-scu-ocotp".
- #address-cells: Must be 1. Contains byte index
- #size-cells: Must be 1. Contains byte length
--
2.7.4
^ permalink raw reply related
* [PATCH nvmem v2 1/2] nvmem: imx: add i.MX8QM platform support
From: fugang.duan @ 2019-08-07 4:03 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: robh, mark.rutland, s.hauer, shawnguo, fugang.duan, kernel,
gregkh, festevam, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20190807040320.1760-1-fugang.duan@nxp.com>
From: Fugang Duan <fugang.duan@nxp.com>
i.MX8QM efuse table has some difference with i.MX8QXP platform,
so add i.MX8QM platform support.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
drivers/nvmem/imx-ocotp-scu.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
index be2f5f0..0d78ab4 100644
--- a/drivers/nvmem/imx-ocotp-scu.c
+++ b/drivers/nvmem/imx-ocotp-scu.c
@@ -16,6 +16,7 @@
enum ocotp_devtype {
IMX8QXP,
+ IMX8QM,
};
struct ocotp_devtype_data {
@@ -39,6 +40,11 @@ static struct ocotp_devtype_data imx8qxp_data = {
.nregs = 800,
};
+static struct ocotp_devtype_data imx8qm_data = {
+ .devtype = IMX8QM,
+ .nregs = 800,
+};
+
static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
u32 *val)
{
@@ -118,6 +124,7 @@ static struct nvmem_config imx_scu_ocotp_nvmem_config = {
static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
{ .compatible = "fsl,imx8qxp-scu-ocotp", (void *)&imx8qxp_data },
+ { .compatible = "fsl,imx8qm-scu-ocotp", (void *)&imx8qm_data },
{ },
};
MODULE_DEVICE_TABLE(of, imx_scu_ocotp_dt_ids);
--
2.7.4
^ permalink raw reply related
* [PATCH nvmem v2 0/2] nvmem: imx: add i.MX8QM platform support
From: fugang.duan @ 2019-08-07 4:03 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: robh, mark.rutland, s.hauer, shawnguo, fugang.duan, kernel,
gregkh, festevam, devicetree, linux-kernel, linux-arm-kernel
From: Fugang Duan <fugang.duan@nxp.com>
The patch set is to add i.MX8QM platform support for i.MX8 SCU
OCOTP driver due to i.MX8QM efuse table has some difference with
i.MX8QXP platform.
V2:
- Add dt-bindings for the new compatible string support.
Fugang Duan (2):
nvmem: imx: add i.MX8QM platform support
dt-bindings: fsl: scu: add new compatible string for ocotp
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 4 +++-
drivers/nvmem/imx-ocotp-scu.c | 7 +++++++
2 files changed, 10 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH v7 01/20] pinctrl: tegra: Add suspend and resume support
From: Sowjanya Komatineni @ 2019-08-07 3:40 UTC (permalink / raw)
To: Linus Walleij
Cc: thierry.reding@gmail.com, Jon Hunter, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Stefan Agner, Mark Rutland,
Peter De Schrijver, Prashant Gaikwad, Stephen Boyd, linux-clk,
open list:GPIO SUBSYSTEM, jckuo, Joseph Lo, talho, linux-tegra,
linux-kernel@vger.kernel.org, Mikko Perttunen, spatra,
Rob Herring, Dmitry
In-Reply-To: <a2fb3795-5ec1-1d03-f496-f151d1270e90@nvidia.com>
On 8/6/19 2:51 PM, Sowjanya Komatineni wrote:
>
> On 8/5/19 2:20 AM, Linus Walleij wrote:
>> On Wed, Jul 31, 2019 at 11:11 PM Sowjanya Komatineni
>> <skomatineni@nvidia.com> wrote:
>>
>>> This patch adds support for Tegra pinctrl driver suspend and resume.
>>>
>>> During suspend, context of all pinctrl registers are stored and
>>> on resume they are all restored to have all the pinmux and pad
>>> configuration for normal operation.
>>>
>>> Acked-by: Thierry Reding <treding@nvidia.com>
>>> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>> Patch applied to the pinctrl tree.
>>
>> This patch seems finished.
>>
>> Also if the rest don't get merged for v5.4 then at least this is so
>> your patch stack gets more shallow.
>>
>> I hope it's fine to merge this separately, else tell me and I'll
>> pull it out.
>>
>> Yours,
>> Linus Walleij
>
> Yes, this patch can be merged separately. But, there's latest feedback
> from Dmitry to add barrier after writes to make sure pinmux register
> writes happen.
>
> So will update this patch to add barrier in v8. So, need to wait for v8.
>
> Thanks
>
> Sowjanya
>
I see it merged. So will exclude suspend/resume patch and will add patch
for necessary write barrier fix in v8 version.
Thanks
Sowjanya
^ permalink raw reply
* RE: [PATCH RFC 5/7] pwm: rcar: remove a redundant condition in rcar_pwm_apply()
From: Yoshihiro Shimoda @ 2019-08-07 2:56 UTC (permalink / raw)
To: Uwe Kleine-König, Geert Uytterhoeven
Cc: Linus Walleij, Geert Uytterhoeven, Thierry Reding, Rob Herring,
Mark Rutland,
GPIO SUBSYSTEM <linux-gpio@vger.kernel.org>, Linux PWM List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>, Linux-Renesas
In-Reply-To: <20190806160007.mqwzixddhzejbmcb@pengutronix.de>
Hello,
> From: Uwe Kleine-König, Sent: Wednesday, August 7, 2019 1:00 AM
>
> Hello,
>
> On Tue, Aug 06, 2019 at 11:05:30AM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jul 8, 2019 at 11:08 AM Yoshihiro Shimoda
> > <yoshihiro.shimoda.uh@renesas.com> wrote:
> > > Since the rcar_pwm_apply() has already check whehter state->enabled
> > > is not set or not, this patch removes a redundant condition.
> > >
> > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> >
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > This is completely independent from the rest of the series, and can be applied
> > immediately, right?
>
> The original patch didn't make it into my mailbox. I only see a few
> replies. Is it only me?
> https://patchwork.ozlabs.org/project/linux-pwm/list/ doesn't seem to
> have it either.
I don't know why but, linux-renesas-soc ML only got the patch series.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=143129
JFYI, but I submitted another patch yesterday, and it seemed to be archived on all MLs:
https://www.spinics.net/lists/stable/msg322085.html
https://lkml.org/lkml/2019/8/6/274
https://patchwork.kernel.org/patch/11078469/
Best regards,
Yoshihiro Shimoda
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Vasily Khoruzhick @ 2019-08-07 2:39 UTC (permalink / raw)
To: Robin Murphy
Cc: Mark Rutland, devicetree, Jared D . McNeill, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Harald Geyer, arm-linux
In-Reply-To: <36e60078-7dd5-9c07-ffa1-6092d8c70fa8@arm.com>
On Tue, Aug 6, 2019 at 2:14 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2019-08-06 9:52 pm, Vasily Khoruzhick wrote:
> > On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
> >>
> >> Vasily Khoruzhick writes:
> >>> On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
> >>>>
> >>>> On 06/08/2019 15:01, Vasily Khoruzhick wrote:
> >>>>> Looks like PMU in A64 is broken, it generates no interrupts at all and
> >>>>> as result 'perf top' shows no events.
> >>>>
> >>>> Does something like 'perf stat sleep 1' at least count cycles correctly?
> >>>> It could well just be that the interrupt numbers are wrong...
> >>>
> >>> Looks like it does, at least result looks plausible:
> >>
> >> I'm using perf stat regularly (cache benchmarks) and it works fine.
> >>
> >> Unfortunately I wasn't aware that perf stat is a poor test for
> >> the interrupts part of the node, when I added it. So I'm not too
> >> surprised I got it wrong.
> >>
> >> However, it would be unfortunate if the node got removed completely,
> >> because perf stat would not work anymore. Maybe we can only remove
> >> the interrupts or just fix them even if the HW doesn't work?
> >
> > I'm not familiar with PMU driver. Is it possible to get it working
> > without interrupts?
>
> Yup - you get a grumpy message from the driver, it will refuse sampling
> events (the ones which weren't working anyway), and if you measure
> anything for long enough that a counter overflows you'll get wonky
> results. But for counting hardware events over relatively short periods
> it'll still do the job.
I tried to drop interrupts completely from the node but 'perf top' is
still broken. Though now in different way: it complains "cycles: PMU
Hardware doesn't support sampling/overflow-interrupts. Try 'perf
stat'"
Is there any way to make it working?
>
> Robin.
^ permalink raw reply
* [PATCH v3] gpio: mpc8xxx: Add new platforms GPIO DT node description
From: Hui Song @ 2019-08-07 2:12 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Mark Rutland, Linus Walleij,
Bartosz Golaszewski
Cc: linux-arm-kernel, devicetree, linux-kernel, linux-gpio, Song Hui
From: Song Hui <hui.song_1@nxp.com>
Update the NXP GPIO node dt-binding file for QorIQ and
Layerscape platforms, and add one more example with
ls1028a GPIO node.
Signed-off-by: Song Hui <hui.song_1@nxp.com>
---
Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
index 69d4616..baf95d9 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible : Should be "fsl,<soc>-gpio"
The following <soc>s are known to be supported:
mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq,
- ls1021a, ls1043a, ls2080a.
+ ls1021a, ls1043a, ls2080a, ls1028a.
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all 32 pins.
- #gpio-cells : Should be two. The first cell is the pin number and
@@ -37,3 +37,17 @@ gpio0: gpio@2300000 {
interrupt-controller;
#interrupt-cells = <2>;
};
+
+
+Example of gpio-controller node for a ls1028a SoC:
+
+gpio1: gpio@2300000 {
+ compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
+ reg = <0x0 0x2300000 0x0 0x10000>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ little-endian;
+};
--
2.9.5
^ permalink raw reply related
* Re: [RFC,v3 7/9] media: platform: Add Mediatek ISP P1 device driver
From: Jungo Lin @ 2019-08-07 2:11 UTC (permalink / raw)
To: Tomasz Figa
Cc: devicetree, Sean Cheng (鄭昇弘),
Mauro Carvalho Chehab, Rynn Wu (吳育恩),
srv_heupstream, Rob Herring, Ryan Yu (余孟修),
Frankie Chiu (邱文凱), Hans Verkuil,
Matthias Brugger, Sj Huang,
moderated list:ARM/Mediatek SoC support, Laurent Pinchart,
ddavenport, Frederic Chen (陳俊元), list
In-Reply-To: <CAAFQd5D5m=gGViSY++r5uUS1+91y9=Gpcss1dEXrin_T07H+uQ@mail.gmail.com>
Hi, Tomasz:
On Tue, 2019-08-06 at 18:47 +0900, Tomasz Figa wrote:
> Hi Jungo,
>
> On Fri, Jul 26, 2019 at 4:24 PM Jungo Lin <jungo.lin@mediatek.com> wrote:
> >
> > Hi, Tomasz:
> >
> > On Thu, 2019-07-25 at 18:23 +0900, Tomasz Figa wrote:
> > > .Hi Jungo,
> > >
> > > On Sat, Jul 20, 2019 at 6:58 PM Jungo Lin <jungo.lin@mediatek.com> wrote:
> > > >
> > > > Hi, Tomasz:
> > > >
> > > > On Wed, 2019-07-10 at 18:56 +0900, Tomasz Figa wrote:
> > > > > Hi Jungo,
> > > > >
> > > > > On Tue, Jun 11, 2019 at 11:53:42AM +0800, Jungo Lin wrote:
> [snip]
I just keep some questions to be clarified.
[snip]
> > > > > > + isp_dev->meta0_vb2_index = meta0_vb2_index;
> > > > > > + isp_dev->meta1_vb2_index = meta1_vb2_index;
> > > > > > + } else {
> > > > > > + if (irq_status & SOF_INT_ST) {
> > > > > > + isp_dev->current_frame = hw_frame_num;
> > > > > > + isp_dev->meta0_vb2_index = meta0_vb2_index;
> > > > > > + isp_dev->meta1_vb2_index = meta1_vb2_index;
> > > > > > + }
> > > > > > + irq_handle_notify_event(isp_dev, irq_status, dma_status, 1);
> > > > > > + }
> > > > >
> > > > > The if and else blocks do almost the same things just in different order. Is
> > > > > it really expected?
> > > > >
> > > >
> > > > If we receive HW_PASS1_DON_ST & SOF_INT_ST IRQ events at the same time,
> > > > the correct sequence should be handle HW_PASS1_DON_ST firstly to check
> > > > any de-queued frame and update the next frame setting later.
> > > > Normally, this is a corner case or system performance issue.
> > >
> > > So it sounds like HW_PASS1_DON_ST means that all data from current
> > > frame has been written, right? If I understand your explanation above
> > > correctly, that would mean following handling of each interrupt:
> > >
> > > HW_PASS1_DON_ST:
> > > - CQ executes with next CQ buffer to prepare for next frame. <- how
> > > is this handled? does the CQ hardware automatically receive this event
> > > from the ISP hadware?
> > > - return VB2 buffers,
> > > - complete requests.
> > >
> > > SOF_INT_ST:
> > > - send VSYNC event to userspace,
> > > - program next CQ buffer to CQ,
> > >
> > > SW_PASS1_DON_ST:
> > > - reclaim CQ buffer and enqueue next frame to composing if available
> > >
> >
> > Sorry for our implementation of HW_PASS1_DON_ST.
> > It is confusing.
> > Below is the revised version based on your conclusion.
> > So in our new implemmenation, we just handle SOF_INT_ST &
> > SW_PASS1_DON_ST events. We just add one warning message for
> > HW_PASS1_DON_ST
> >
> > HW_PASS1_DON_ST:
> > - CQ executes with next CQ buffer to prepare for next frame.
> >
> > SOF_INT_ST:
> > - send VSYNC event to userspace,
> > - program next CQ buffer to CQ,
> >
> > SW_PASS1_DON_ST:
> > - reclaim CQ buffer and enqueue next frame to composing if available
> > - return VB2 buffers,
> > - complete requests.
> >
> > For CQ HW operations, it is listed below:
> >
> > a. The CQ buffer has two kinds of information
> > - Which ISP registers needs to be updated.
> > - Where the corresponding ISP register data to be read.
> > b. The CQ buffer loading procedure is triggered by HW_PASS1_DONT_ST IRQ
> > event periodically.
> > - Normally, if the ISP HW receives the completed frame and it will
> > trigger W_PASS1_DONT_ST IRQ and perform CQ buffer loading immediately.
> > - So the CQ buffer loading is performed by ISP HW automatically.
> > c. The ISP HW will read CQ base address register(REG_CQ_THR0_BASEADDR)
> > to decide which CQ buffer is loaded.
> > - So we configure the next CQ base address in SOF.
> > d. For CQ buffer loading, CQ will read the ISP registers from CQ buffer
> > and update the ISP register values into HW.
> > - SCP composer will compose one dummy CQ buffer and assign it to
> > REG_CQ_THR0_BASEADDR of each CQ buffer.
> > - Dummy CQ buffer has no updated ISP registers comparing with other
> > CQ buffers.
> > - With this design, if there is no updated new CQ buffer by driver
> > which may be caused no en-queue frames from user space. The CQ HW will
> > load dummy CQ buffer and do nothing.
>
> Does the set of registers programmed by CQ include destination buffer
> addresses to? If yes, we would end up overwriting previous frames if
> no new buffers are provided.
>
Yes, the buffer addresses are changed per frame request. We need to
compose CQ to include these DMA destination addresses. For your concern,
we have DMA flow buffer control (FBC) in HW. If there is no FBC counter
increased due to no buffer for each DMA, the ISP HW doesn't output the
data to the corresponding DMA address.
Below is the simple descriptor of CQ buffer.
a. ISP registers in tuning buffer, including 3A registers.
b. All capture buffers informations.
- DMA buffer destination address
- FBC counter
c. Some specif ISP registers for meta DMAs, such as LCE or LMVO.
d. frame sequence number register
> > f. The CQ buffer loading is guaranteed by HW to finish before the next
> > SOF.
> >
>
> Okay, thanks a lot for the explanation. This is much more clear now.
>
> [snip]
> > > > > > +static const struct dev_pm_ops mtk_isp_pm_ops = {
> > > > > > + SET_SYSTEM_SLEEP_PM_OPS(mtk_isp_suspend, mtk_isp_resume)
> > > > > > + SET_RUNTIME_PM_OPS(mtk_isp_suspend, mtk_isp_resume, NULL)
> > > > >
> > > > > For V4L2 drivers system and runtime PM ops would normally be completely
> > > > > different. Runtime PM ops would be called when the hardware is idle already
> > > > > or is about to become active. System PM ops would be called at system power
> > > > > state change and the hardware might be both idle or active. Please also see
> > > > > my comments to mtk_isp_suspend() and mtk_isp_resume() above.
> > > > >
> > > >
> > > > Here is the new implementation. It should be clear to show the
> > > > difference between system and runtime PM ops.
> > > >
> > > > static const struct dev_pm_ops mtk_isp_pm_ops = {
> > > > SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> > > > pm_runtime_force_resume)
> > > > SET_RUNTIME_PM_OPS(mtk_isp_runtime_suspend, mtk_isp_runtime_resume,
> > > > NULL)
> > > > };
> > >
> > > That's still not correct. In runtime suspend/resume ops we already are
> > > not streaming anymore, because we call pm_runtime_get/put_*() when
> > > starting and stopping streaming. In system suspend/resume ops we might
> > > be streaming and that's when we need to stop the hardware and wait for
> > > it to finish. Please implement these ops separately.
> > >
> > > Best regards,
> > > Tomasz
> >
> >
> > Ok, got your point.
> > Below is the new implementation for your review.
> >
> > static int mtk_isp_pm_suspend(struct device *dev)
> > {
> > struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> > u32 val;
> > int ret;
> >
> > dev_dbg(dev, "- %s\n", __func__);
> >
> > /* Check ISP is streaming or not */
> > if (!p1_dev->cam_dev.streaming)
> > goto done;
>
> We would normally check here for pm_runtime_suspended(). Although they
> both should be equivalent. Still, there is no need to call
> pm_runtime_force_suspend() if the latter is true, so we could just
> return 0 instantly.
>
Ok, here is the fixed version.
static int mtk_isp_pm_suspend(struct device *dev)
{
struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
u32 val;
int ret;
dev_dbg(dev, "- %s\n", __func__);
if (pm_runtime_suspended(dev))
return 0;
/* Disable ISP's view finder and wait for TG idle */
dev_dbg(dev, "cam suspend, disable VF\n");
val = readl(p1_dev->regs + REG_TG_VF_CON);
writel(val & (~TG_VF_CON_VFDATA_EN), p1_dev->regs + REG_TG_VF_CON);
ret = readl_poll_timeout_atomic(p1_dev->regs + REG_TG_INTER_ST, val,
(val & TG_CS_MASK) == TG_IDLE_ST,
USEC_PER_MSEC, MTK_ISP_STOP_HW_TIMEOUT);
if (ret)
dev_warn(dev, "can't stop HW:%d:0x%x\n", ret, val);
/* Disable CMOS */
val = readl(p1_dev->regs + REG_TG_SEN_MODE);
writel(val & (~TG_SEN_MODE_CMOS_EN), p1_dev->regs + REG_TG_SEN_MODE);
/* Force ISP HW to idle */
ret = pm_runtime_force_suspend(dev);
if (ret)
return ret;
return 0;
}
[snip]
> > static int mtk_isp_pm_resume(struct device *dev)
> > {
> > struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> > u32 val;
> > int ret;
> >
> > dev_dbg(dev, "- %s\n", __func__);
> >
> > /* Force ISP HW to resume if needed */
> > ret = pm_runtime_force_resume(dev);
> > if (ret)
> > return ret;
>
> We should do this conditionally based on what pm_runtime_suspended()
> returns. If it's non-zero then we can just return 0 instantly.
>
Ok, here is the fixed version.
static int mtk_isp_pm_resume(struct device *dev)
{
struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
u32 val;
int ret;
dev_dbg(dev, "- %s\n", __func__);
if (pm_runtime_suspended(dev))
return 0;
/* Force ISP HW to resume */
ret = pm_runtime_force_resume(dev);
if (ret)
return ret;
/* Enable CMOS */
dev_dbg(dev, "cam resume, enable CMOS/VF\n");
val = readl(p1_dev->regs + REG_TG_SEN_MODE);
writel(val | TG_SEN_MODE_CMOS_EN, p1_dev->regs + REG_TG_SEN_MODE);
/* Enable VF */
val = readl(p1_dev->regs + REG_TG_VF_CON);
writel(val | TG_VF_CON_VFDATA_EN, p1_dev->regs + REG_TG_VF_CON);
return 0;
}
[snip]
> > static int mtk_isp_runtime_suspend(struct device *dev)
> > {
> > struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> >
> > dev_dbg(dev, "- %s\n", __func__);
> >
> > if (pm_runtime_suspended(dev))
> > return 0;
>
> Sorry, I guess I wasn't clear in my reply. It's not possible to get
> this callback called if the device is already runtime suspended.
>
Ok, got it. Need to remove pm_runtime_suspended(dev) checking and move
it into mtk_isp_pm_* functions. If I still don't get your point, could
you kindly provide one sample driver for reference? Based on current
implementation, it is similar to below drivers.
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-mdp/mtk_mdp_core.c#L255
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/exynos4-is/fimc-is-i2c.c#L113
static int mtk_isp_runtime_suspend(struct device *dev)
{
struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
dev_dbg(dev, "%s:disable clock\n", __func__);
clk_bulk_disable_unprepare(p1_dev->num_clks, p1_dev->clks);
return 0;
}
[snip]
> > static int mtk_isp_runtime_resume(struct device *dev)
> > {
> > struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> > int ret;
> >
> > dev_dbg(dev, "- %s\n", __func__);
> >
> > if (pm_runtime_suspended(dev))
> > return 0;
>
> In this case the above call would always return non-zero, so the
> behavior wouldn't be very good.
>
Same as above.
static int mtk_isp_runtime_resume(struct device *dev)
{
struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
int ret;
dev_dbg(dev, "%s:enable clock\n", __func__);
ret = clk_bulk_prepare_enable(p1_dev->num_clks, p1_dev->clks);
if (ret) {
dev_err(dev, "failed to enable clock:%d\n", ret);
return ret;
}
return 0;
}
Thanks for your further comments on these issues.
Best regards,
Jugno
> Best regards,
> Tomasz
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ 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