* [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
* Re: [PATCH v2 0/3] Adding DT support for TI HECC module
From: Yegor Yefremov @ 2017-01-11 21:50 UTC (permalink / raw)
To: linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Andrey Skvortsov, hs-ynQEQJNshbs, Yegor Yefremov
In-Reply-To: <1484143521-4898-1-git-send-email-yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Wed, Jan 11, 2017 at 3:05 PM, <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> From: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>
> This is an attempt to revive DT support for TI HECC that was started in 2015.
>
> I haven't changed much because not all questions could be fully answered:
>
> * Should HECC use "am3505" as compatible?
I mean "ti,am3505-hecc"
> * What should be done to the offsets (ti,scc-ram-offset, ti,hecc-ram-offset, ti,mbx-offset)?
First submission and related comments:
http://comments.gmane.org/gmane.linux.can/8616
Yegor
--
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 0/2] usb: gadget: s3c2410: add device tree support
From: Sergio Prado @ 2017-01-11 22:02 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland, balbi, linux-usb, devicetree,
linux-kernel
Cc: Sergio Prado
This series adds support for configuring Samsung's s3c2410 and
compatible USB device controller via device tree.
Tested on FriendlyARM mini2440, based on s3c2440 SoC.
Changes since v1:
- change the USB bus clock name to "uclk" to better reflect the name
used in the datasheet
- improve samsung,vbus-gpio optional property description
- specify the active state in the GPIOs properties
Sergio Prado (2):
dt-bindings: usb: add DT binding for s3c2410 USB device controller
usb: gadget: s3c2410: allow probing from device tree
.../devicetree/bindings/usb/s3c2410-usb.txt | 28 ++++
drivers/usb/gadget/udc/s3c2410_udc.c | 144 +++++++++++++++++----
drivers/usb/gadget/udc/s3c2410_udc.h | 4 +
3 files changed, 152 insertions(+), 24 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: usb: add DT binding for s3c2410 USB device controller
From: Sergio Prado @ 2017-01-11 22:02 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
balbi-DgEjT+Ai2ygdnm+yROfE0A, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Sergio Prado
In-Reply-To: <1484172150-32075-1-git-send-email-sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
Adds the device tree bindings description for Samsung S3C2410 and
compatible USB device controller.
Signed-off-by: Sergio Prado <sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
---
.../devicetree/bindings/usb/s3c2410-usb.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
index e45b38ce2986..28353eea31fd 100644
--- a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
+++ b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
@@ -20,3 +20,31 @@ usb0: ohci@49000000 {
clocks = <&clocks UCLK>, <&clocks HCLK_USBH>;
clock-names = "usb-bus-host", "usb-host";
};
+
+Samsung S3C2410 and compatible USB device controller
+
+Required properties:
+ - compatible: Should be one of the following
+ "samsung,s3c2410-udc"
+ "samsung,s3c2440-udc"
+ - reg: address and length of the controller memory mapped region
+ - interrupts: interrupt number for the USB device controller
+ - clocks: Should reference the bus and host clocks
+ - clock-names: Should contain two strings
+ "uclk" for the USB bus clock
+ "usb-device" for the USB device clock
+
+Optional properties:
+ - samsung,vbus-gpio: specifies a gpio that allows to detect whether
+ vbus is present - USB is connected (active high, input).
+ - samsung,pullup-gpio: If present, specifies a gpio to control the
+ USB D+ pullup (active high, output).
+
+usb1: udc@52000000 {
+ compatible = "samsung,s3c2440-udc";
+ reg = <0x52000000 0x100000>;
+ interrupts = <0 0 25 3>;
+ clocks = <&clocks UCLK>, <&clocks HCLK_USBD>;
+ clock-names = "usb-bus-gadget", "usb-device";
+ samsung,pullup-gpio = <&gpc 5 GPIO_ACTIVE_HIGH>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* [PATCH v2 2/2] usb: gadget: s3c2410: allow probing from device tree
From: Sergio Prado @ 2017-01-11 22:02 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
balbi-DgEjT+Ai2ygdnm+yROfE0A, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Sergio Prado
In-Reply-To: <1484172150-32075-1-git-send-email-sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
Allows configuring Samsung's s3c2410 and compatible USB device
controller using a devicetree.
Signed-off-by: Sergio Prado <sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
---
drivers/usb/gadget/udc/s3c2410_udc.c | 144 +++++++++++++++++++++++++++++------
drivers/usb/gadget/udc/s3c2410_udc.h | 4 +
2 files changed, 124 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/gadget/udc/s3c2410_udc.c b/drivers/usb/gadget/udc/s3c2410_udc.c
index 4643a01262b4..165a510b1971 100644
--- a/drivers/usb/gadget/udc/s3c2410_udc.c
+++ b/drivers/usb/gadget/udc/s3c2410_udc.c
@@ -30,6 +30,9 @@
#include <linux/gpio.h>
#include <linux/prefetch.h>
#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
#include <linux/debugfs.h>
#include <linux/seq_file.h>
@@ -55,6 +58,18 @@
#define DRIVER_AUTHOR "Herbert Pötzl <herbert-dBHVzrDq9nF4Lj/PQRBjDg@public.gmane.org>, " \
"Arnaud Patard <arnaud.patard-dQbF7i+pzddAfugRpC6u6w@public.gmane.org>"
+struct s3c2410_udc_drv_data {
+ int ep_fifo_size;
+};
+
+static const struct s3c2410_udc_drv_data s3c2410_udc_2410_drv_data = {
+ .ep_fifo_size = EP_FIFO_SIZE,
+};
+
+static const struct s3c2410_udc_drv_data s3c2410_udc_2440_drv_data = {
+ .ep_fifo_size = S3C2440_EP_FIFO_SIZE,
+};
+
static const char gadget_name[] = "s3c2410_udc";
static const char driver_desc[] = DRIVER_DESC;
@@ -62,8 +77,6 @@
static struct clk *udc_clock;
static struct clk *usb_bus_clock;
static void __iomem *base_addr;
-static u64 rsrc_start;
-static u64 rsrc_len;
static struct dentry *s3c2410_udc_debugfs_root;
static inline u32 udc_read(u32 reg)
@@ -997,7 +1010,7 @@ static irqreturn_t s3c2410_udc_irq(int dummy, void *_dev)
}
}
- dprintk(DEBUG_VERBOSE, "irq: %d s3c2410_udc_done.\n", IRQ_USBD);
+ dprintk(DEBUG_VERBOSE, "irq: %d s3c2410_udc_done.\n", dev->irq);
/* Restore old index */
udc_write(idx, S3C2410_UDC_INDEX_REG);
@@ -1757,6 +1770,49 @@ static int s3c2410_udc_stop(struct usb_gadget *g)
};
+static int s3c2410_udc_probe_dt(struct s3c2410_udc *udc)
+{
+ const struct s3c2410_udc_drv_data *drvdata;
+ struct platform_device *pdev = udc->pdev;
+ struct s3c2410_udc_mach_info *pdata;
+ int gpio;
+
+ drvdata = of_device_get_match_data(&pdev->dev);
+
+ if (drvdata)
+ udc->ep_fifo_size = drvdata->ep_fifo_size;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ gpio = of_get_named_gpio(pdev->dev.of_node, "samsung,vbus-gpio", 0);
+ if (gpio_is_valid(gpio))
+ pdata->vbus_pin = gpio;
+
+ gpio = of_get_named_gpio(pdev->dev.of_node, "samsung,pullup-gpio", 0);
+ if (gpio_is_valid(gpio))
+ pdata->pullup_pin = gpio;
+
+ pdev->dev.platform_data = pdata;
+
+ return 0;
+}
+
+static int s3c2410_udc_probe_pdata(struct s3c2410_udc *udc)
+{
+ const struct s3c2410_udc_drv_data *drvdata;
+ struct platform_device *pdev = udc->pdev;
+
+ drvdata = (struct s3c2410_udc_drv_data *)
+ platform_get_device_id(pdev)->driver_data;
+
+ if (drvdata)
+ udc->ep_fifo_size = drvdata->ep_fifo_size;
+
+ return 0;
+}
+
/*
* probe - binds to the platform device
*/
@@ -1769,7 +1825,17 @@ static int s3c2410_udc_probe(struct platform_device *pdev)
dev_dbg(dev, "%s()\n", __func__);
- usb_bus_clock = clk_get(NULL, "usb-bus-gadget");
+ udc->pdev = pdev;
+
+ if (pdev->dev.of_node)
+ retval = s3c2410_udc_probe_dt(udc);
+ else
+ retval = s3c2410_udc_probe_pdata(udc);
+
+ if (retval)
+ return retval;
+
+ usb_bus_clock = clk_get(NULL, "uclk");
if (IS_ERR(usb_bus_clock)) {
dev_err(dev, "failed to get usb bus clock source\n");
return PTR_ERR(usb_bus_clock);
@@ -1789,24 +1855,27 @@ static int s3c2410_udc_probe(struct platform_device *pdev)
dev_dbg(dev, "got and enabled clocks\n");
- if (strncmp(pdev->name, "s3c2440", 7) == 0) {
- dev_info(dev, "S3C2440: increasing FIFO to 128 bytes\n");
- memory.ep[1].fifo_size = S3C2440_EP_FIFO_SIZE;
- memory.ep[2].fifo_size = S3C2440_EP_FIFO_SIZE;
- memory.ep[3].fifo_size = S3C2440_EP_FIFO_SIZE;
- memory.ep[4].fifo_size = S3C2440_EP_FIFO_SIZE;
+ if (udc->ep_fifo_size) {
+ dev_info(dev, "setting FIFO to %d bytes\n", udc->ep_fifo_size);
+ memory.ep[1].fifo_size = udc->ep_fifo_size;
+ memory.ep[2].fifo_size = udc->ep_fifo_size;
+ memory.ep[3].fifo_size = udc->ep_fifo_size;
+ memory.ep[4].fifo_size = udc->ep_fifo_size;
}
spin_lock_init(&udc->lock);
udc_info = dev_get_platdata(&pdev->dev);
- rsrc_start = S3C2410_PA_USBDEV;
- rsrc_len = S3C24XX_SZ_USBDEV;
+ udc->mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!udc->mem) {
+ dev_err(dev, "failed to get I/O memory region\n");
+ return -ENOENT;
+ }
- if (!request_mem_region(rsrc_start, rsrc_len, gadget_name))
+ if (!request_mem_region(udc->mem->start, resource_size(udc->mem), gadget_name))
return -EBUSY;
- base_addr = ioremap(rsrc_start, rsrc_len);
+ base_addr = ioremap(udc->mem->start, resource_size(udc->mem));
if (!base_addr) {
retval = -ENOMEM;
goto err_mem;
@@ -1818,17 +1887,24 @@ static int s3c2410_udc_probe(struct platform_device *pdev)
s3c2410_udc_disable(udc);
s3c2410_udc_reinit(udc);
+ udc->irq = platform_get_irq(pdev, 0);
+ if (udc->irq == 0) {
+ dev_err(dev, "failed to get interrupt\n");
+ retval = -EINVAL;
+ goto err_map;
+ }
+
/* irq setup after old hardware state is cleaned up */
- retval = request_irq(IRQ_USBD, s3c2410_udc_irq,
+ retval = request_irq(udc->irq, s3c2410_udc_irq,
0, gadget_name, udc);
if (retval != 0) {
- dev_err(dev, "cannot get irq %i, err %d\n", IRQ_USBD, retval);
+ dev_err(dev, "cannot get irq %i, err %d\n", udc->irq, retval);
retval = -EBUSY;
goto err_map;
}
- dev_dbg(dev, "got irq %i\n", IRQ_USBD);
+ dev_dbg(dev, "got irq %i\n", udc->irq);
if (udc_info && udc_info->vbus_pin > 0) {
retval = gpio_request(udc_info->vbus_pin, "udc vbus");
@@ -1899,11 +1975,11 @@ static int s3c2410_udc_probe(struct platform_device *pdev)
if (udc_info && udc_info->vbus_pin > 0)
gpio_free(udc_info->vbus_pin);
err_int:
- free_irq(IRQ_USBD, udc);
+ free_irq(udc->irq, udc);
err_map:
iounmap(base_addr);
err_mem:
- release_mem_region(rsrc_start, rsrc_len);
+ release_mem_region(udc->mem->start, resource_size(udc->mem));
return retval;
}
@@ -1933,10 +2009,10 @@ static int s3c2410_udc_remove(struct platform_device *pdev)
free_irq(irq, udc);
}
- free_irq(IRQ_USBD, udc);
+ free_irq(udc->irq, udc);
iounmap(base_addr);
- release_mem_region(rsrc_start, rsrc_len);
+ release_mem_region(udc->mem->start, resource_size(udc->mem));
if (!IS_ERR(udc_clock) && udc_clock != NULL) {
clk_disable_unprepare(udc_clock);
@@ -1974,16 +2050,36 @@ static int s3c2410_udc_resume(struct platform_device *pdev)
#define s3c2410_udc_resume NULL
#endif
+static const struct of_device_id s3c_udc_dt_ids[] = {
+ {
+ .compatible = "samsung,s3c2410-udc",
+ .data = &s3c2410_udc_2410_drv_data,
+ },
+ {
+ .compatible = "samsung,s3c2440-udc",
+ .data = &s3c2410_udc_2440_drv_data,
+ },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, s3c_udc_dt_ids);
+
static const struct platform_device_id s3c_udc_ids[] = {
- { "s3c2410-usbgadget", },
- { "s3c2440-usbgadget", },
- { }
+ {
+ .name = "s3c2410-usbgadget",
+ .driver_data = (kernel_ulong_t) &s3c2410_udc_2410_drv_data,
+ },
+ {
+ .name = "s3c2440-usbgadget",
+ .driver_data = (kernel_ulong_t) &s3c2410_udc_2440_drv_data,
+ },
+ { /* sentinel */},
};
MODULE_DEVICE_TABLE(platform, s3c_udc_ids);
static struct platform_driver udc_driver_24x0 = {
.driver = {
.name = "s3c24x0-usbgadget",
+ .of_match_table = s3c_udc_dt_ids,
},
.probe = s3c2410_udc_probe,
.remove = s3c2410_udc_remove,
diff --git a/drivers/usb/gadget/udc/s3c2410_udc.h b/drivers/usb/gadget/udc/s3c2410_udc.h
index 93bf225f1969..8fdbe77a804d 100644
--- a/drivers/usb/gadget/udc/s3c2410_udc.h
+++ b/drivers/usb/gadget/udc/s3c2410_udc.h
@@ -94,6 +94,10 @@ struct s3c2410_udc {
unsigned req_pending : 1;
u8 vbus;
struct dentry *regs_info;
+ struct platform_device *pdev;
+ struct resource *mem;
+ int irq;
+ unsigned int ep_fifo_size;
};
#define to_s3c2410(g) (container_of((g), struct s3c2410_udc, gadget))
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* Re: [PATCH] dt: bindings: Add support for CSI1 bus
From: Pavel Machek @ 2017-01-11 22:06 UTC (permalink / raw)
To: Sakari Ailus
Cc: Rob Herring, devicetree, ivo.g.dimitrov.75, sre, pali.rohar,
linux-media
In-Reply-To: <20170104085420.GN3958@valkosipuli.retiisi.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]
Hi!
> Thanks for the review.
>
> On Tue, Jan 03, 2017 at 02:38:54PM -0600, Rob Herring wrote:
> > 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.
> >
> > What cases specifically?
>
> The existing V4L2 OF support tries to figure out the bus type and parse the
> bus parameters based on that. This does not scale too well as there are
> multiple serial busses that share common properties.
>
> Some hardware also supports multiple types of busses on the same interfaces.
Ok, I'll include that in the changelog.
> > As in MIPI CSI2?
>
> Yeah, I guess it'd make sense to make this explicit.
Ok.
> > > should be the combined length of data-lanes and clock-lanes properties.
> > > - If the lane-polarities property is omitted, the value must be interpreted
> > > - as 0 (normal). This property is valid for serial busses only.
> >
> > Why is this removed?
>
> Must have been by mistake. :-)
Fixed.
> > > -
> > > +- clock-inv: Clock or strobe signal inversion.
> > > + Possible values: 0 -- not inverted; 1 -- inverted
> >
> > "invert" assumes I know what is normal and I do not. Define what is
> > "normal" and name the property the opposite of that. If normal is data
> > shifted on clock rising edge, then call the the property
> > "clock-shift-falling-edge" for example..
>
> The hardware documentation says this is the "strobe/clock inversion control
> signal". I'm not entirely sure whether this is just signal polarity (it's a
> differential signal) or inversion of an internal signal of the CCP2 block.
>
> It might make sense to make this a private property for the OMAP 3 ISP
> instead. If it's seen elsewhere, then think about it again. I doubt it
> would, as CCP2 is an old bus that's used on Nokia N9, N950 and N900.
>
> As strobe is included, I'd add that to the name. Say,
> "ti,clock-strobe-inv".
Hmm. N900 does not use inversion. Would it make sense to simply
hardcode it to "not-inverted" for now?
Device tree changes are PITA :-(.
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
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