* Re: [PATCH 1/5] arm: sunxi: add support for V3s SoC
From: Icenowy Zheng @ 2017-01-11 19:40 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Stephen Boyd, Linus Walleij,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
In-Reply-To: <20170110180926.ilqtygttpfgbetvu@lukather>
11.01.2017, 02:09, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> On Tue, Jan 03, 2017 at 11:16:25PM +0800, Icenowy Zheng wrote:
>> Allwinner V3s is a low-end single-core Cortex-A7 SoC, with 64MB
>> integrated DRAM, and several peripherals.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>> ---
>> Documentation/arm/sunxi/README | 4 ++++
>> arch/arm/mach-sunxi/sunxi.c | 1 +
>> 2 files changed, 5 insertions(+)
>>
>> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
>> index cd0243302bc1..91ec8f2055be 100644
>> --- a/Documentation/arm/sunxi/README
>> +++ b/Documentation/arm/sunxi/README
>> @@ -67,6 +67,10 @@ SunXi family
>> + Datasheet
>> http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
>>
>> + - Allwinner V3s (sun8i)
>> + + Datasheet
>> + https://www.goprawn.com/forum/allwinner-cams/783-allwinner-v3s-soc-datasheet
>> +
>
> Please don't put random links in there, but at least something that we
> know will be there in a couple of weeks/monthes/years
Is http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf acceptable?
>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Icenowy Zheng @ 2017-01-11 19:44 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linus Walleij,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Stephen Boyd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Chen-Yu Tsai,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <2705031484163593-/w1NKm4lK9luio3avFS2gg@public.gmane.org>
12.01.2017, 03:40, "Icenowy Zheng" <icenowy-ymACFijhrKM@public.gmane.org>:
> 11.01.2017, 02:10, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
>> On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
>>> V3s has a similar but cut-down CCU to H3.
>>>
>>> Add support for it.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>
>> It looks like there's nothing different but the clocks that you
>> register with the H3, please just use the H3 driver.
>
> Nope.
>
> It has a different PLL (PLL_ISP) at different address, and some
> different muxes.
Forgot to mention the missing of PLL_DE and related misses.
>
>> Thanks!
>> Maxime
>>
>> --
>> Maxime Ripard, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree
From: Bjorn Andersson @ 2017-01-11 19:55 UTC (permalink / raw)
To: Lee Jones
Cc: Rob Herring, Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Richard Purdie,
Jacek Anaszewski, Pavel Machek, Jingoo Han, devicetree,
linux-kernel, linux-iio, linux-leds, Bjorn Andersson
In-Reply-To: <20170109083638.GB2155@dell>
On Mon 09 Jan 00:36 PST 2017, Lee Jones wrote:
> On Fri, 06 Jan 2017, Bjorn Andersson wrote:
>
> > On Fri 06 Jan 01:53 PST 2017, Lee Jones wrote:
> >
> > > On Thu, 05 Jan 2017, Bjorn Andersson wrote:
> > >
> > > > On Wed 04 Jan 23:49 PST 2017, Lee Jones wrote:
> > > >
> > > > > On Wed, 04 Jan 2017, Bjorn Andersson wrote:
> > > > >
> > > > > > On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> > > > > >
> > > > > > > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > > > > > >
> > > > > > > > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > > > > > > >
> > > > > > > > Implement support for initialization of the lm3533 driver core and
> > > > > > > > probing child devices from Device Tree.
> > > > > > > >
> > > > > >
> > > > > > [..]
> > > > > >
> > > > > > > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > > > > > > > lm3533_device_bl_init(lm3533);
> > > > > > > > lm3533_device_led_init(lm3533);
> > > > > > > >
> > > > > > > > + if (lm3533->dev->of_node) {
> > > > > > > > + of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > > > > > > + lm3533->dev);
> > > > > > > > + }
> > > > > > >
> > > > > > > I think it's save to call of_platform_populate(), even if !of_node.
> > > > > > > It will just fail and return an error code, which you are ignoring
> > > > > > > anyway.
> > > > > > >
> > > > > >
> > > > > > I thought so too, but that's apparently how you trigger probing children
> > > > > > of the root node. So we're stuck with a conditional.
> > > > >
> > > > > Ah, so this is to protect against the case where DT is present, but a
> > > > > node for this device is not (or is disabled), so is left unprobed.
> > > > > Then the bind is initiated via I2C? Or something else?
> > > > >
> > > >
> > > > In the event that a new lm3533 is spawned from sysfs we would not have
> > > > platform_data when entering lm3533_device_init() and just bail early.
> > > >
> > > > Therefor, this issue would be limited to the odd case of lm3533 being
> > > > initiated from code (e.g. a board file) on a DT enabled system. In which
> > > > case it will create and probe new devices from the root of the DT.
> > >
> > > Eewww, do we really want to support that?
> > >
> >
> > As long as we support non-DT probing of the driver this is a possible
> > scenario. And with modern ARM being DT-centric I think that if anyone
> > uses this driver with a modern version of the Linux kernel it's likely
> > that they would have this kind of hybrid solution.
> >
> > So, although ugly, I think we should keep this conditional and hope that
> > anyone using the driver will transition to use the DT binding.
>
> Very well, but can you add a comment describing the reason for its
> existence with a view to removing it further down the line?
>
Sounds reasonable, I will prepare an updated patch with this.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Icenowy Zheng @ 2017-01-11 19:55 UTC (permalink / raw)
To: Bin Liu
Cc: devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, Kishon Vijay Abraham I,
Chen-Yu Tsai, Maxime Ripard, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170110202443.GC2479@uda0271908>
11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
>> Lichee Pi Zero features a USB OTG port.
>>
>> Add support for it.
>>
>> Note: in order to use the Host mode, the board must be powered via the
>> +5V and GND pins.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ---
>> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> index 0099affc6ce3..3d9168cbaeca 100644
>> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> @@ -71,3 +71,13 @@
>> pinctrl-names = "default";
>> status = "okay";
>> };
>> +
>> +&usb_otg {
>> + dr_mode = "otg";
>
> Why not set this default mode in dtsi instead?
>
> Regards,
> -Bin.
There's possibly boards which do not have OTG functions.
Even the official CDR design of V3s uses the USB controller to
connect a UVC webcam to make the design a dual-cam design
(V3s itself has a CSI).
>
>> + status = "okay";
>> +};
>> +
>> +&usbphy {
>> + usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
>> + status = "okay";
>> +};
>> --
>> 2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/3] Input: add optional amplifier regulator to pwm-beeper (previously "Input: add optional enable gpio to pwm-beeper")
From: David Lechner @ 2017-01-11 20:01 UTC (permalink / raw)
To: linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: David Lechner, Dmitry Torokhov, Rob Herring, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
This series adds an optional regulator to the pwm-beeper driver and device tree
bindings. The regulator acts as an amplifier that powers the beeper.
v2 changes:
* Changed from using a gpio to a regulator
* Rebased on the pwm-beeper cleanup series "Input: pwm-beeper - remove calls to
legacy pwm_request API"
David Lechner (3):
Input: pwm-beeper: suppress error message on probe defer
dt-bindings: Input: Add optional amp-supply property to pwm-beeper
Input: pwm-beeper: add optional amplifier regulator
.../devicetree/bindings/input/pwm-beeper.txt | 16 ++++++++++
drivers/input/misc/pwm-beeper.c | 36 +++++++++++++++++++---
2 files changed, 48 insertions(+), 4 deletions(-)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 1/3] Input: pwm-beeper: suppress error message on probe defer
From: David Lechner @ 2017-01-11 20:01 UTC (permalink / raw)
To: linux-input, devicetree
Cc: David Lechner, Dmitry Torokhov, Rob Herring, Mark Rutland,
linux-kernel
In-Reply-To: <1484164921-30587-1-git-send-email-david@lechnology.com>
This suppress printing an error message when pwm_get returns -EPROBE_DEFER.
Otherwise you get a bunch of noise in the kernel log.
Signed-off-by: David Lechner <david@lechnology.com>
---
drivers/input/misc/pwm-beeper.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index ce6eec4..30ac227 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -104,9 +104,10 @@ static int pwm_beeper_probe(struct platform_device *pdev)
return -ENOMEM;
beeper->pwm = devm_pwm_get(dev, NULL);
- if (IS_ERR(beeper->pwm)) {
- error = PTR_ERR(beeper->pwm);
- dev_err(dev, "Failed to request pwm device: %d\n", error);
+ error = PTR_ERR_OR_ZERO(beeper->pwm);
+ if (error) {
+ if (error != -EPROBE_DEFER)
+ dev_err(dev, "Failed to request pwm device\n");
return error;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: Input: Add optional amp-supply property to pwm-beeper
From: David Lechner @ 2017-01-11 20:02 UTC (permalink / raw)
To: linux-input, devicetree
Cc: David Lechner, Dmitry Torokhov, Rob Herring, Mark Rutland,
linux-kernel
In-Reply-To: <1484164921-30587-1-git-send-email-david@lechnology.com>
This adds an optional amp-supply property to pwm-beeper. This is a
regulator that acts as an amplifier for the beeper.
Signed-off-by: David Lechner <david@lechnology.com>
---
Documentation/devicetree/bindings/input/pwm-beeper.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..529408b 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,19 @@ Registers a PWM device as beeper.
Required properties:
- compatible: should be "pwm-beeper"
- pwms: phandle to the physical PWM device
+
+Optional properties:
+- amp-supply: phandle to a regulator that acts as an amplifier for the beeper
+
+Example:
+
+beeper_amp: amplifier {
+ compatible = "fixed-regulator";
+ gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+};
+
+beeper {
+ compatible = "pwm-beeper";
+ pwms = <&pwm0>;
+ amp-supply = <&beeper_amp>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] Input: pwm-beeper: add optional amplifier regulator
From: David Lechner @ 2017-01-11 20:02 UTC (permalink / raw)
To: linux-input, devicetree
Cc: David Lechner, Dmitry Torokhov, Rob Herring, Mark Rutland,
linux-kernel
In-Reply-To: <1484164921-30587-1-git-send-email-david@lechnology.com>
This adds an optional regulator to the pwm-beeper device. This regulator
acts as an amplifier. The amplifier is only enabled while beeping in order
to reduce power consumption.
Tested on LEGO MINDSTORMS EV3, which has a speaker connected to PWM through
an amplifier.
Signed-off-by: David Lechner <david@lechnology.com>
---
drivers/input/misc/pwm-beeper.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 30ac227..708e88e 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -14,6 +14,7 @@
*/
#include <linux/input.h>
+#include <linux/regulator/consumer.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/of.h>
@@ -25,8 +26,10 @@
struct pwm_beeper {
struct input_dev *input;
struct pwm_device *pwm;
+ struct regulator *reg;
struct work_struct work;
unsigned long period;
+ bool reg_enabled;
};
#define HZ_TO_NANOSECONDS(x) (1000000000UL/(x))
@@ -38,8 +41,20 @@ static void __pwm_beeper_set(struct pwm_beeper *beeper)
if (period) {
pwm_config(beeper->pwm, period / 2, period);
pwm_enable(beeper->pwm);
- } else
+ if (beeper->reg) {
+ int error;
+
+ error = regulator_enable(beeper->reg);
+ if (!error)
+ beeper->reg_enabled = true;
+ }
+ } else {
+ if (beeper->reg_enabled) {
+ regulator_disable(beeper->reg);
+ beeper->reg_enabled = false;
+ }
pwm_disable(beeper->pwm);
+ }
}
static void pwm_beeper_work(struct work_struct *work)
@@ -82,6 +97,10 @@ static void pwm_beeper_stop(struct pwm_beeper *beeper)
{
cancel_work_sync(&beeper->work);
+ if (beeper->reg_enabled) {
+ regulator_disable(beeper->reg);
+ beeper->reg_enabled = false;
+ }
if (beeper->period)
pwm_disable(beeper->pwm);
}
@@ -111,6 +130,14 @@ static int pwm_beeper_probe(struct platform_device *pdev)
return error;
}
+ beeper->reg = devm_regulator_get_optional(&pdev->dev, "amp");
+ error = PTR_ERR_OR_ZERO(beeper->reg);
+ if (error) {
+ if (error != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get amp regulator\n");
+ return error;
+ }
+
/*
* FIXME: pwm_apply_args() should be removed when switching to
* the atomic PWM API.
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Bin Liu @ 2017-01-11 20:08 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, Kishon Vijay Abraham I,
Chen-Yu Tsai, Maxime Ripard, linux-arm-kernel@lists.infradead.org
In-Reply-To: <2733831484164533@web1g.yandex.ru>
On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
>
>
> 11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> >> Lichee Pi Zero features a USB OTG port.
> >>
> >> Add support for it.
> >>
> >> Note: in order to use the Host mode, the board must be powered via the
> >> +5V and GND pins.
> >>
> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >> ---
> >> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> >> 1 file changed, 10 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> index 0099affc6ce3..3d9168cbaeca 100644
> >> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> @@ -71,3 +71,13 @@
> >> pinctrl-names = "default";
> >> status = "okay";
> >> };
> >> +
> >> +&usb_otg {
> >> + dr_mode = "otg";
> >
> > Why not set this default mode in dtsi instead?
> >
> > Regards,
> > -Bin.
>
> There's possibly boards which do not have OTG functions.
That is board specific.
You'd better to define the default dr_mode which the musb _controller_
supports in the dtsi, and then override it in a specific board dts if
necessary.
Regards,
-Bin.
>
> Even the official CDR design of V3s uses the USB controller to
> connect a UVC webcam to make the design a dual-cam design
> (V3s itself has a CSI).
>
> >
> >> + status = "okay";
> >> +};
> >> +
> >> +&usbphy {
> >> + usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> >> + status = "okay";
> >> +};
> >> --
> >> 2.11.0
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Icenowy Zheng @ 2017-01-11 20:13 UTC (permalink / raw)
To: Bin Liu
Cc: devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, Kishon Vijay Abraham I,
Chen-Yu Tsai, Maxime Ripard, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170111200811.GA16865@uda0271908>
12.01.2017, 04:08, "Bin Liu" <b-liu@ti.com>:
> On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
>> 11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
>> > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
>> >> Lichee Pi Zero features a USB OTG port.
>> >>
>> >> Add support for it.
>> >>
>> >> Note: in order to use the Host mode, the board must be powered via the
>> >> +5V and GND pins.
>> >>
>> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> >> ---
>> >> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
>> >> 1 file changed, 10 insertions(+)
>> >>
>> >> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> >> index 0099affc6ce3..3d9168cbaeca 100644
>> >> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> >> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> >> @@ -71,3 +71,13 @@
>> >> pinctrl-names = "default";
>> >> status = "okay";
>> >> };
>> >> +
>> >> +&usb_otg {
>> >> + dr_mode = "otg";
>> >
>> > Why not set this default mode in dtsi instead?
>> >
>> > Regards,
>> > -Bin.
>>
>> There's possibly boards which do not have OTG functions.
>
> That is board specific.
>
> You'd better to define the default dr_mode which the musb _controller_
> supports in the dtsi, and then override it in a specific board dts if
> necessary.
Is there MUSB controllers which do not support a certain mode?
(I remembered my omap3-n900 which do not work under OTG mode...)
>
> Regards,
> -Bin.
>
>> Even the official CDR design of V3s uses the USB controller to
>> connect a UVC webcam to make the design a dual-cam design
>> (V3s itself has a CSI).
>>
>> >
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&usbphy {
>> >> + usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
>> >> + status = "okay";
>> >> +};
>> >> --
>> >> 2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Bin Liu @ 2017-01-11 20:33 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, Kishon Vijay Abraham I,
Chen-Yu Tsai, Maxime Ripard, linux-arm-kernel@lists.infradead.org
In-Reply-To: <418251484165614@web21h.yandex.ru>
On Thu, Jan 12, 2017 at 04:13:34AM +0800, Icenowy Zheng wrote:
>
>
> 12.01.2017, 04:08, "Bin Liu" <b-liu@ti.com>:
> > On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> >> 11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> >> > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> >> >> Lichee Pi Zero features a USB OTG port.
> >> >>
> >> >> Add support for it.
> >> >>
> >> >> Note: in order to use the Host mode, the board must be powered via the
> >> >> +5V and GND pins.
> >> >>
> >> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >> >> ---
> >> >> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> >> >> 1 file changed, 10 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> >> index 0099affc6ce3..3d9168cbaeca 100644
> >> >> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> >> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> >> @@ -71,3 +71,13 @@
> >> >> pinctrl-names = "default";
> >> >> status = "okay";
> >> >> };
> >> >> +
> >> >> +&usb_otg {
> >> >> + dr_mode = "otg";
> >> >
> >> > Why not set this default mode in dtsi instead?
> >> >
> >> > Regards,
> >> > -Bin.
> >>
> >> There's possibly boards which do not have OTG functions.
> >
> > That is board specific.
> >
> > You'd better to define the default dr_mode which the musb _controller_
> > supports in the dtsi, and then override it in a specific board dts if
> > necessary.
>
> Is there MUSB controllers which do not support a certain mode?
I am not aware of any. That is why I recommended to set "otg" in dtsi,
then override it in board dts if a port is specically designed to
host-only or device-only mode.
>
> (I remembered my omap3-n900 which do not work under OTG mode...)
I belive it is n900 board specific. omap3 itself doesn't have such
limitation, AFAIK.
Regards,
-Bin.
>
> >
> > Regards,
> > -Bin.
> >
> >> Even the official CDR design of V3s uses the USB controller to
> >> connect a UVC webcam to make the design a dual-cam design
> >> (V3s itself has a CSI).
> >>
> >> >
> >> >> + status = "okay";
> >> >> +};
> >> >> +
> >> >> +&usbphy {
> >> >> + usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> >> >> + status = "okay";
> >> >> +};
> >> >> --
> >> >> 2.11.0
^ permalink raw reply
* Re: [PATCHv3 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Sebastian Hesselbarth @ 2017-01-11 20:55 UTC (permalink / raw)
To: Linus Walleij, Chris Packham, Gregory CLEMENT, Thomas Petazzoni
Cc: Mark Rutland, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
Kalyan Kinthada, Rob Herring, Laxman Dewangan,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACRpkdaC+USN7YhZo49LAL9sorMxbTfhQbT5NrAu5D=Q1DHnnA@mail.gmail.com>
On 01/11/2017 03:44 PM, Linus Walleij wrote:
> On Fri, Jan 6, 2017 at 5:15 AM, Chris Packham
> <chris.packham@alliedtelesis.co.nz> wrote:
>
>> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>>
>> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
>> from Marvell.
>>
>> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>
> I am waiting for an ACK or comment from the maintainers on
> this patch. Sebastian?
Sorry for the ignorance.
I don't have the patch to reply to inline, but:
- In the driver MPP_MODE2, spi0 there is a typo "csk" instead of "sck".
- MPP_MODE5 binding "dev","bootcs" and driver "dev","bootcs0" differ.
- MPP_MODE6 binding "gpio" and driver "gpo" differ.
- MPP_MODE17 binding "dev","clk" and driver "dev","clkout" differ.
- MPP_MODE19 binding mentiones "dev","rb" but driver does not.
- MPP_MODE20 binding "gpio" and driver "gpo" differ.
- MPP_MODE20 binding "dev","we" and driver "dev","we0" differ.
- MPP_MODE21 through MPP_MODE30 binding "gpio" and driver "gpo" differ.
- remove spaces before "0, 0" in mv98dx3236_mpp_gpio_ranges.
Most of it is cosmetic stuff, so if you fix it feel free to add my
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Sebastian
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Rob Clark @ 2017-01-11 20:59 UTC (permalink / raw)
To: Will Deacon
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-arm-msm, Sricharan R, Jordan Crouse, Mark Rutland,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170111093606.GA12388-5wv7dgnIgG8@public.gmane.org>
On Wed, Jan 11, 2017 at 4:36 AM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> On Tue, Jan 10, 2017 at 02:20:13PM -0500, Rob Clark wrote:
>> On Tue, Jan 10, 2017 at 12:52 PM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
>> > On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote:
>> >> Hmm, well we install the fault handler on the iommu_domain.. perhaps
>> >> maybe a combo of dts property (or deciding based on more specific
>> >> compat string), plus extra param passed in to
>> >> iommu_set_fault_hander(). The dts property or compat string to
>> >> indicate whether the iommu (and how it is wired up) can handle stalls,
>> >> and enable_stall param when fault handler is registered to indicate
>> >> whether the device itself can cope.. if either can't do stalling, then
>> >> don't set CFCFG.
>> >
>> > I thought about this some more, and I think you're right. Having
>> > iommu_set_fault_handler take a flags parameter indicating that, for example,
>> > the fault handler can deal with paging, is all we need to implement the
>> > per-master opt-in functionality for stalling faults. There's no real
>> > requirement to standardise a generic firmware property for that (but
>> > we still need *something* that says stalling is usable on the SMMU --
>> > perhaps just the compatible string is ok).
>>
>> btw, it occurred to me that maybe it should be flags param to
>> iommu_attach_device() (just in case fault handler not installed?)
>> otoh stalling without a fault handler is silly, but I guess we need it
>> to infer whether stalling can be supported by other devices on same
>> iommu.. tbh I'm on a bit shaky ground when it comes to multiple
>> devices per iommu since the SoC's I'm familiar with do it the other
>> way around. But I guess you have thought more about the multi-device
>> case, so figured I should suggest it..
>
> I don't think it works at attach time, because the stalling property belongs
> to the domain, rather than the individual devices within it. Similarly, I
> don't think we should allow this property to be toggled once devices have
> been attached.
>
hmm, I was more thinking of cases where drivers for particular devices
need some work (ie. like potentially disabling hw hang detect during
faults).. I guess we could have three levels, that all have to be true
in order to enable stall: smmu, domain (pass flags in to
iommu_domain_alloc()??), and device (iommu_attach_device())?
BR,
-R
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Maxime Ripard @ 2017-01-11 21:06 UTC (permalink / raw)
To: Bin Liu, Icenowy Zheng, Chen-Yu Tsai, Kishon Vijay Abraham I,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <20170111200811.GA16865@uda0271908>
[-- Attachment #1.1: Type: text/plain, Size: 1778 bytes --]
On Wed, Jan 11, 2017 at 02:08:11PM -0600, Bin Liu wrote:
> On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> >
> >
> > 11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> > > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> > >> Lichee Pi Zero features a USB OTG port.
> > >>
> > >> Add support for it.
> > >>
> > >> Note: in order to use the Host mode, the board must be powered via the
> > >> +5V and GND pins.
> > >>
> > >> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> > >> ---
> > >> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> > >> 1 file changed, 10 insertions(+)
> > >>
> > >> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> index 0099affc6ce3..3d9168cbaeca 100644
> > >> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> @@ -71,3 +71,13 @@
> > >> pinctrl-names = "default";
> > >> status = "okay";
> > >> };
> > >> +
> > >> +&usb_otg {
> > >> + dr_mode = "otg";
> > >
> > > Why not set this default mode in dtsi instead?
> > >
> > > Regards,
> > > -Bin.
> >
> > There's possibly boards which do not have OTG functions.
>
> That is board specific.
Exactly, and this is why it should be done in the board DT.
The controller in the Allwinner SoCs do not handle directly the ID pin
and VBUS, but rather rely on a GPIO to do so.
So boards with OTG will need setup anyway, at least to tell which
GPIOs are used. There's no point in enforcing a default if it doesn't
work by default.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Rob Herring @ 2017-01-11 21:15 UTC (permalink / raw)
To: Chanwoo Choi
Cc: kgene, krzk, javier, mark.rutland, catalin.marinas, will.deacon,
s.nawrocki, m.szyprowski, a.hajda, chanwoo, linux-kernel,
linux-samsung-soc, devicetree, linux-arm-kernel
In-Reply-To: <1484096148-17120-1-git-send-email-cw00.choi@samsung.com>
On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
> This patch replaces the small letter of base address, offset and hex value
> with the capital letter to keep the consistency on Exynos5433.
You mean the other way around, right?
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index abaf6b4d599d..d7ed1a68b6fd 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -231,7 +231,7 @@
> compatible = "arm,psci";
> method = "smc";
> cpu_off = <0x84000002>;
> - cpu_on = <0xC4000003>;
> + cpu_on = <0xc4000003>;
> };
>
> reboot: syscon-reboot {
> @@ -753,7 +753,7 @@
>
> dsi: dsi@13900000 {
> compatible = "samsung,exynos5433-mipi-dsi";
> - reg = <0x13900000 0xC0>;
> + reg = <0x13900000 0xc0>;
> interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
> phys = <&mipi_phy 1>;
> phy-names = "dsim";
> @@ -880,9 +880,9 @@
> iommus = <&sysmmu_jpeg>;
> };
>
> - mfc: codec@152E0000 {
> + mfc: codec@152e0000 {
> compatible = "samsung,exynos5433-mfc";
> - reg = <0x152E0000 0x10000>;
> + reg = <0x152e0000 0x10000>;
> interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> clock-names = "pclk", "aclk", "aclk_xiu";
> clocks = <&cmu_mfc CLK_PCLK_MFC>,
> @@ -914,7 +914,7 @@
>
> sysmmu_gscl0: sysmmu@13c80000 {
> compatible = "samsung,exynos-sysmmu";
> - reg = <0x13C80000 0x1000>;
> + reg = <0x13c80000 0x1000>;
> interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
> clock-names = "aclk", "pclk";
> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL0>,
> @@ -924,7 +924,7 @@
>
> sysmmu_gscl1: sysmmu@13c90000 {
> compatible = "samsung,exynos-sysmmu";
> - reg = <0x13C90000 0x1000>;
> + reg = <0x13c90000 0x1000>;
> interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
> clock-names = "aclk", "pclk";
> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL1>,
> @@ -934,7 +934,7 @@
>
> sysmmu_gscl2: sysmmu@13ca0000 {
> compatible = "samsung,exynos-sysmmu";
> - reg = <0x13CA0000 0x1000>;
> + reg = <0x13ca0000 0x1000>;
> interrupts = <GIC_SPI 292 IRQ_TYPE_LEVEL_HIGH>;
> clock-names = "aclk", "pclk";
> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL2>,
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH] devicetree: Add Fujitsu Ltd. vendor prefix
From: Rob Herring @ 2017-01-11 21:15 UTC (permalink / raw)
To: Marek Vasut; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170110213222.14045-1-marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Jan 10, 2017 at 10:32:22PM +0100, Marek Vasut wrote:
> The vendor prefix for Fujitsu is used in the tree, but it's
> still missing from the documentation, so add it. Fujitsu Ltd.
> is a japanese ICT company, http://www.fujitsu.com
>
> Signed-off-by: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Applied, thanks.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] serial: fsl-imx-uart.txt: Remove generic property
From: Rob Herring @ 2017-01-11 21:15 UTC (permalink / raw)
To: Fabio Estevam
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, Fabio Estevam
In-Reply-To: <1483990202-19224-1-git-send-email-festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Jan 09, 2017 at 05:30:02PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>
> 'uart-has-rtscts' is a generic serial property and it is described
> at Documentation/devicetree/bindings/serial/serial.txt, so remove it
> from the specific fsl-imx-uart binding documentation.
>
> While at it, add a note pointing to the serial.txt file, which
> contains the complete list of generic serial bindings.
>
> Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/serial/fsl-imx-uart.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Applied, thanks.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Documentation: dt: reset: Revise typos in TI syscon reset example
From: Rob Herring @ 2017-01-11 21:15 UTC (permalink / raw)
To: Suman Anna
Cc: devicetree, linux-kernel, Andrew Davis, Philipp Zabel,
Santosh Shilimkar, linux-arm-kernel
In-Reply-To: <20170109192814.26811-1-s-anna@ti.com>
On Mon, Jan 09, 2017 at 01:28:14PM -0600, Suman Anna wrote:
> Fix couple of typos in the example given in the TI syscon reset
> binding. The ti,reset-bits used for DSP0 are corrected to match
> the values that will be used in the actual DT node.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> Hi Philipp,
>
> This is the Documentation part fix that goes along with
> the ti-syscon-reset fix that you have on your next branch.
> I will be submitting the DT nodes very soon
>
> regards
> Suman
>
> Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
> index 164c7f34c451..21ba739b162e 100644
> --- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
> +++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
> @@ -63,7 +63,7 @@ Example:
> --------
> The following example demonstrates a syscon node, the reset controller node
> using the syscon node, and a consumer (a DSP device) on the TI Keystone 2
> -Edison SoC.
> +66AK2E SoC.
>
> / {
> soc {
> @@ -71,13 +71,13 @@ Edison SoC.
> compatible = "syscon", "simple-mfd";
> reg = <0x02350000 0x1000>;
>
> - pscrst: psc-reset {
> + pscrst: psc-reset-controller {
Really, this should be just 'reset-controller'.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/6] mmc: sunxi: Always set signal delay to 0 for A64
From: Maxime Ripard @ 2017-01-11 21:17 UTC (permalink / raw)
To: André Przywara
Cc: devicetree, Ulf Hansson, linux-mmc, linux-kernel, Chen-Yu Tsai,
Rob Herring, linux-arm-kernel
In-Reply-To: <96ba5fd8-d551-5993-f347-202c47efec8c@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 3474 bytes --]
On Tue, Jan 10, 2017 at 12:30:41AM +0000, André Przywara wrote:
> On 09/01/17 16:46, Maxime Ripard wrote:
> > Experience have shown that the using the autocalibration could severely
> > degrade the performances of the MMC bus.
> >
> > Allwinner is using in its BSP a delay set to 0 for all the modes but HS400.
> > Remove the calibration code for now, and add comments to document our
> > findings.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/mmc/host/sunxi-mmc.c | 50 ++++++++++++-------------------------
> > 1 file changed, 17 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> > index b1d1303389a7..ea9552a0d820 100644
> > --- a/drivers/mmc/host/sunxi-mmc.c
> > +++ b/drivers/mmc/host/sunxi-mmc.c
> > @@ -683,41 +683,19 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
> >
> > static int sunxi_mmc_calibrate(struct sunxi_mmc_host *host, int reg_off)
> > {
> > - u32 reg = readl(host->reg_base + reg_off);
> > - u32 delay;
> > - unsigned long timeout;
> > -
> > if (!host->cfg->can_calibrate)
> > return 0;
> >
> > - reg &= ~(SDXC_CAL_DL_MASK << SDXC_CAL_DL_SW_SHIFT);
> > - reg &= ~SDXC_CAL_DL_SW_EN;
> > -
> > - writel(reg | SDXC_CAL_START, host->reg_base + reg_off);
> > -
> > - dev_dbg(mmc_dev(host->mmc), "calibration started\n");
> > -
> > - timeout = jiffies + HZ * SDXC_CAL_TIMEOUT;
> > -
> > - while (!((reg = readl(host->reg_base + reg_off)) & SDXC_CAL_DONE)) {
> > - if (time_before(jiffies, timeout))
> > - cpu_relax();
> > - else {
> > - reg &= ~SDXC_CAL_START;
> > - writel(reg, host->reg_base + reg_off);
> > -
> > - return -ETIMEDOUT;
> > - }
> > - }
> > -
> > - delay = (reg >> SDXC_CAL_DL_SHIFT) & SDXC_CAL_DL_MASK;
> > -
> > - reg &= ~SDXC_CAL_START;
> > - reg |= (delay << SDXC_CAL_DL_SW_SHIFT) | SDXC_CAL_DL_SW_EN;
> > -
> > - writel(reg, host->reg_base + reg_off);
> > -
> > - dev_dbg(mmc_dev(host->mmc), "calibration ended, reg is 0x%x\n", reg);
> > + /*
> > + * FIXME:
> > + * This is not clear how the calibration is supposed to work
> > + * yet. The best rate have been obtained by simply setting the
> > + * delay to 0, as Allwinner does in its BSP.
> > + *
> > + * The only mode that doesn't have such a delay is HS400, that
> > + * is in itself a TODO.
> > + */
> > + writel(SDXC_CAL_DL_SW_EN, host->reg_base + reg_off);
> >
> > return 0;
> > }
> > @@ -806,7 +784,13 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
> > if (ret)
> > return ret;
> >
> > - /* TODO: enable calibrate on sdc2 SDXC_REG_DS_DL_REG of A64 */
> > + /*
> > + * FIXME:
> > + *
> > + * In HS400 we'll also need to calibrate the data strobe
> > + * signal. This should only happen on the MMC2 controller (at
> > + * least on the A64 and older SoCs).
>
> Which older SoCs have this calibration register and a DS signal?
> Is that supposed to mean "other" SoCs?
That was supposed to mean that newer (than A64) SoCs might have that
calibration on other controllers than MMC2. But you're right that it
actually applies only to A64 anyway, I'll remove the and older part.
> Other than that:
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Chanwoo Choi @ 2017-01-11 21:22 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Chanwoo Choi, Kukjin Kim, Javier Martinez Canillas, Rob Herring,
Mark Rutland, catalin.marinas@arm.com, will.deacon@arm.com,
Sylwester Nawrocki, Marek Szyprowski, a.hajda, linux-kernel,
linux-samsung-soc, devicetree, linux-arm-kernel
In-Reply-To: <20170111162613.lxkc7k75f6q3fsz2@kozik-lap>
2017-01-12 1:26 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
>> This patch replaces the small letter of base address, offset and hex value
>> with the capital letter to keep the consistency on Exynos5433.
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> index abaf6b4d599d..d7ed1a68b6fd 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> @@ -231,7 +231,7 @@
>> compatible = "arm,psci";
>> method = "smc";
>> cpu_off = <0x84000002>;
>> - cpu_on = <0xC4000003>;
>> + cpu_on = <0xc4000003>;
>
> There is no point of such "improvements". This is just unnecessary
> churn.
>
> Sometimes such things are accepted as part of some bigger work (vide
> recent Andrzej's sysmmu for HDMI/TV). But on its own? No sense at all.
Do you mean that this patch is not reasonable? or
The modification of cpu_on property is only not reasonable?
It is simple for the consistency to use the hex value in dts file.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: devicetree: Add document bindings for mtk-cir
From: Rob Herring @ 2017-01-11 21:27 UTC (permalink / raw)
To: Sean Wang
Cc: Mauro Carvalho Chehab, Hans de Goede, Heiner Kallweit,
Mark Rutland, Matthias Brugger, Andi Shyti, Hans Verkuil,
Sean Young, Ivaylo Dimitrov, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-mediatek,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, sean wang
In-Reply-To: <1484015754.4057.4.camel@mtkswgap22>
On Mon, Jan 9, 2017 at 8:35 PM, Sean Wang <sean.wang@mediatek.com> wrote:
> Hi Rob,
>
> thanks for your effort for reviewing. I added comments inline.
>
> On Mon, 2017-01-09 at 12:32 -0600, Rob Herring wrote:
>> On Fri, Jan 06, 2017 at 12:06:23AM +0800, sean.wang@mediatek.com wrote:
>> > From: Sean Wang <sean.wang@mediatek.com>
>> >
>> > This patch adds documentation for devicetree bindings for
>> > Mediatek IR controller.
>> >
>> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
>> > ---
>> > .../devicetree/bindings/media/mtk-cir.txt | 23 ++++++++++++++++++++++
>> > 1 file changed, 23 insertions(+)
>> > create mode 100644 linux-4.8.rc1_p0/Documentation/devicetree/bindings/media/mtk-cir.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt b/Documentation/devicetree/bindings/media/mtk-cir.txt
>> > new file mode 100644
>> > index 0000000..bbedd71
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
>> > @@ -0,0 +1,23 @@
>> > +Device-Tree bindings for Mediatek IR controller found in Mediatek SoC family
>> > +
>> > +Required properties:
>> > +- compatible : "mediatek,mt7623-ir"
>> > +- clocks : list of clock specifiers, corresponding to
>> > + entries in clock-names property;
>> > +- clock-names : should contain "clk" entries;
>> > +- interrupts : should contain IR IRQ number;
>> > +- reg : should contain IO map address for IR.
>> > +
>> > +Optional properties:
>> > +- linux,rc-map-name : Remote control map name.
>>
>> Would 'label' be appropriate here instead? If not, this needs to be
>> documented in a common location and explained better.
>>
> I checked with how the way applied in other IR drivers is and found that
> most IR driver also use the same label to identify the scan/key table
> they prefer to use such as gpio-ir-recv, ir-hix5hd2, meson-ir and
> sunxi-cir or use hard coding inside the driver. So I thought it should
> be appropriate here currently.
Maybe so, but anything with linux prefix gets extra scrutiny and I'm
not sure that happened on the previous cases. If label has the same
meaning, then we should start using that and deprecate this property.
In any case, a property used by multiple bindings needs to be
documented in a common place. The explanation of the property is bad
too. It just spells out RC with no explanation. I'm sure you just
copy-n-pasted it from the others, but that doesn't make it okay.
Rob
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Chanwoo Choi @ 2017-01-11 21:30 UTC (permalink / raw)
To: Rob Herring
Cc: Chanwoo Choi, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Mark Rutland, catalin.marinas@arm.com,
will.deacon@arm.com, Sylwester Nawrocki, Marek Szyprowski,
a.hajda, linux-kernel, linux-samsung-soc, devicetree,
linux-arm-kernel
In-Reply-To: <20170111211503.6kwqaunb5mpe6eb2@rob-hp-laptop>
2017-01-12 6:15 GMT+09:00 Rob Herring <robh@kernel.org>:
> On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
>> This patch replaces the small letter of base address, offset and hex value
>> with the capital letter to keep the consistency on Exynos5433.
>
> You mean the other way around, right?
When I posted the dts patches, I got the comment that small letter is better
for base address/offset. (It doesn’t mean that all dts file in Linux Kernel
have to use the small letter of base address and offset.)
This dts uses the both capital and small letter for each base address/offset.
Almost hex value already uses the small letter. If possible, I hope to use
the one style (small letter).
>
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> index abaf6b4d599d..d7ed1a68b6fd 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> @@ -231,7 +231,7 @@
>> compatible = "arm,psci";
>> method = "smc";
>> cpu_off = <0x84000002>;
>> - cpu_on = <0xC4000003>;
>> + cpu_on = <0xc4000003>;
>> };
>>
>> reboot: syscon-reboot {
>> @@ -753,7 +753,7 @@
>>
>> dsi: dsi@13900000 {
>> compatible = "samsung,exynos5433-mipi-dsi";
>> - reg = <0x13900000 0xC0>;
>> + reg = <0x13900000 0xc0>;
>> interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
>> phys = <&mipi_phy 1>;
>> phy-names = "dsim";
>> @@ -880,9 +880,9 @@
>> iommus = <&sysmmu_jpeg>;
>> };
>>
>> - mfc: codec@152E0000 {
>> + mfc: codec@152e0000 {
>> compatible = "samsung,exynos5433-mfc";
>> - reg = <0x152E0000 0x10000>;
>> + reg = <0x152e0000 0x10000>;
>> interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
>> clock-names = "pclk", "aclk", "aclk_xiu";
>> clocks = <&cmu_mfc CLK_PCLK_MFC>,
>> @@ -914,7 +914,7 @@
>>
>> sysmmu_gscl0: sysmmu@13c80000 {
>> compatible = "samsung,exynos-sysmmu";
>> - reg = <0x13C80000 0x1000>;
>> + reg = <0x13c80000 0x1000>;
>> interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
>> clock-names = "aclk", "pclk";
>> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL0>,
>> @@ -924,7 +924,7 @@
>>
>> sysmmu_gscl1: sysmmu@13c90000 {
>> compatible = "samsung,exynos-sysmmu";
>> - reg = <0x13C90000 0x1000>;
>> + reg = <0x13c90000 0x1000>;
>> interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
>> clock-names = "aclk", "pclk";
>> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL1>,
>> @@ -934,7 +934,7 @@
>>
>> sysmmu_gscl2: sysmmu@13ca0000 {
>> compatible = "samsung,exynos-sysmmu";
>> - reg = <0x13CA0000 0x1000>;
>> + reg = <0x13ca0000 0x1000>;
>> interrupts = <GIC_SPI 292 IRQ_TYPE_LEVEL_HIGH>;
>> clock-names = "aclk", "pclk";
>> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL2>,
>> --
>> 1.9.1
>>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2017-01-11 21:34 UTC (permalink / raw)
To: Dave Gerlach
Cc: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, Nishanth Menon, Keerthy, Russell King,
Tero Kristo, Sudeep Holla, Santosh Shilimkar, Lokesh Vutla
In-Reply-To: <7bd282d9-df6f-f4c6-1f7f-c8ed81c78af3@ti.com>
On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
> Rob,
>
> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>
>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>
>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>> will hook into the genpd framework and allow the TI SCI protocol to
>>> control device power states.
>>>
>>> Also, provide macros representing each device index as understood
>>> by TI SCI to be used in the device node power-domain references.
>>> These are identifiers for the K2G devices managed by the PMMC.
>>>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>> ---
>>> v2->v3:
>>> Update k2g_pds node docs to show it should be a child of pmmc
>>> node.
>>> In early versions a phandle was used to point to pmmc and docs
>>> still
>>> incorrectly showed this.
>>>
>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59 ++++++++++++++
>>> MAINTAINERS | 2 +
>>> include/dt-bindings/genpd/k2g.h | 90
>>> ++++++++++++++++++++++
>>> 3 files changed, 151 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> new file mode 100644
>>> index 000000000000..4c9064e512cb
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> @@ -0,0 +1,59 @@
>>> +Texas Instruments TI-SCI Generic Power Domain
>>> +---------------------------------------------
>>> +
>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>>> +responsible for controlling the state of the IPs that are present.
>>> +Communication between the host processor running an OS and the system
>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>> domain
>>> +implementation plugs into the generic pm domain framework and makes use
>>> of
>>> +the TI SCI protocol power on and off each device when needed.
>>> +
>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>> +
>>> +PM Domain Node
>>> +==============
>>> +The PM domain node represents the global PM domain managed by the PMMC,
>>> +which in this case is the single implementation as documented by the
>>> generic
>>> +PM domain bindings in
>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>> +Because this relies on the TI SCI protocol to communicate with the PMMC
>>> it
>>> +must be a child of the pmmc node.
>>> +
>>> +Required Properties:
>>> +--------------------
>>> +- compatible: should be "ti,sci-pm-domain"
>>> +- #power-domain-cells: Must be 0.
>>> +
>>> +Example (K2G):
>>> +-------------
>>> + pmmc: pmmc {
>>> + compatible = "ti,k2g-sci";
>>> + ...
>>> +
>>> + k2g_pds: k2g_pds {
>>> + compatible = "ti,sci-pm-domain";
>>> + #power-domain-cells = <0>;
>>> + };
>>> + };
>>> +
>>> +PM Domain Consumers
>>> +===================
>>> +Hardware blocks that require SCI control over their state must provide
>>> +a reference to the sci-pm-domain they are part of and a unique device
>>> +specific ID that identifies the device.
>>> +
>>> +Required Properties:
>>> +--------------------
>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>> + be used for device control.
>>
>>
>> As I've already stated before, this goes in power-domain cells. When you
>> have a single thing (i.e. node) that controls multiple things, then you
>> you need to specify the ID for each of them in phandle args. This is how
>> irqs, gpio, clocks, *everything* in DT works.
>
>
> You think the reasoning for doing it this way provided by both Ulf and
> myself on v2 [1] is not valid then?
>
> From Ulf:
>
> To me, the TI SCI ID, is similar to a "conid" for any another "device
> resource" (like clock, pinctrl, regulator etc) which we can describe
> in DT and assign to a device node. The only difference here, is that
> we don't have common API to fetch the resource (like clk_get(),
> regulator_get()), but instead we fetches the device's resource from
> SoC specific code, via genpd's device ->attach() callback.
Sorry, but that sounds like a kernel problem to me and has nothing to
do with DT bindings.
> From me:
>
> Yes, you've pretty much hit it on the head. It is not an index into a list
> of genpds but rather identifies the device *within* a single genpd. It is a
> property specific to each device that resides in a ti-sci-genpd, not a
> mapping describing which genpd the device belongs to. The generic power
> domain binding is concerned with mapping the device to a specific genpd,
> which is does fine for us, but we have a sub mapping for devices that exist
> inside a genpd which, we must describe as well, hence the ti,sci-id.
>
>
> So to summarize, the genpd framework does interpret the phandle arg as an
> index into multiple genpds, just as you've said other frameworks do, but
> this is not what I am trying to do, we have multiple devices within this
> *single* genpd, hence the need for the ti,sci-id property.
Fix the genpd framework rather than work around it in DT.
Rob
^ permalink raw reply
* Re: [PATCH] dt: bindings: Add support for CSI1 bus
From: Pavel Machek @ 2017-01-11 21:38 UTC (permalink / raw)
To: Sakari Ailus
Cc: robh+dt, devicetree, ivo.g.dimitrov.75, sre, pali.rohar,
linux-media
In-Reply-To: <20170102070010.GD3958@valkosipuli.retiisi.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]
On Mon 2017-01-02 09:00:10, Sakari Ailus wrote:
> Hi Pavel,
>
> On Wed, Dec 28, 2016 at 07:30:36PM +0100, Pavel Machek wrote:
> > From: Sakari Ailus <sakari.ailus@iki.fi>
> >
> > In the vast majority of cases the bus type is known to the driver(s)
> > since a receiver or transmitter can only support a single one. There
> > are cases however where different options are possible.
> >
> > Document the CSI1/CCP2 properties strobe_clk_inv and strobe_clock
> > properties. The former tells whether the strobe/clock signal is
> > inverted, while the latter signifies the clock or strobe mode.
> >
> > Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
> > Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> >
> > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
> > index 9cd2a36..f0523f7 100644
> > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> > @@ -76,6 +76,10 @@ Optional endpoint properties
> > mode horizontal and vertical synchronization signals are provided to the
> > slave device (data source) by the master device (data sink). In the master
> > mode the data source device is also the source of the synchronization signals.
> > +- bus-type: data bus type. Possible values are:
> > + 0 - CSI2
> > + 1 - parallel / Bt656
> > + 2 - CCP2
>
> I wonder if we should make a difference between CCP2 and CSI-1 here, as it
> may make a difference in hardware configuration. The next patch does
> recognise that difference, so it should be present here as well.
>
> Perhaps 2 - CSI1; 3 - CCP2. What do you think?
Me, think..? Nah. :-).
Well, you have way more experience here, and yes, based on future
patches, this makes sense.
Thanks, Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: dt: reset: Revise typos in TI syscon reset example
From: Suman Anna @ 2017-01-11 21:49 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-kernel, Andrew Davis, Philipp Zabel,
Santosh Shilimkar, linux-arm-kernel
In-Reply-To: <20170111211520.w3sy5pkvjydiwvcs@rob-hp-laptop>
On 01/11/2017 03:15 PM, Rob Herring wrote:
> On Mon, Jan 09, 2017 at 01:28:14PM -0600, Suman Anna wrote:
>> Fix couple of typos in the example given in the TI syscon reset
>> binding. The ti,reset-bits used for DSP0 are corrected to match
>> the values that will be used in the actual DT node.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>> Hi Philipp,
>>
>> This is the Documentation part fix that goes along with
>> the ti-syscon-reset fix that you have on your next branch.
>> I will be submitting the DT nodes very soon
>>
>> regards
>> Suman
>>
>> Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>> index 164c7f34c451..21ba739b162e 100644
>> --- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>> +++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>> @@ -63,7 +63,7 @@ Example:
>> --------
>> The following example demonstrates a syscon node, the reset controller node
>> using the syscon node, and a consumer (a DSP device) on the TI Keystone 2
>> -Edison SoC.
>> +66AK2E SoC.
>>
>> / {
>> soc {
>> @@ -71,13 +71,13 @@ Edison SoC.
>> compatible = "syscon", "simple-mfd";
>> reg = <0x02350000 0x1000>;
>>
>> - pscrst: psc-reset {
>> + pscrst: psc-reset-controller {
>
> Really, this should be just 'reset-controller'.
Thanks Rob, I will fix this patch and the DTS patches as well.
regards
Suman
^ 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