* Re: [PATCH 2/2] ARM: BCM5301X: Add DT for Luxul XWR-1200
From: Florian Fainelli @ 2017-01-18 1:06 UTC (permalink / raw)
To: Dan Haab, Florian Fainelli
Cc: Hauke Mehrtens, Rafał Miłecki,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Rob Herring,
Mark Rutland, Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484447368-7622-2-git-send-email-dhaab-RSK6WAzFx3QAvxtiuMwx3w@public.gmane.org>
On 01/14/2017 06:29 PM, Dan Haab wrote:
> Luxul XWR-1200 in a dual-band router based on BCM47081. It uses serial
> flash (for bootloader and NVRAM) and NAND flash (for firmware).
>
> Signed-off-by: Dan Haab <dhaab-RSK6WAzFx3QAvxtiuMwx3w@public.gmane.org>
Applied thanks
--
Florian
--
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 1/2] ARM: BCM5301X: Add DT for Luxul XAP-1410
From: Florian Fainelli @ 2017-01-18 1:06 UTC (permalink / raw)
To: Dan Haab, Florian Fainelli
Cc: Hauke Mehrtens, Rafał Miłecki,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Rob Herring,
Mark Rutland, Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484447368-7622-1-git-send-email-dhaab-RSK6WAzFx3QAvxtiuMwx3w@public.gmane.org>
On 01/14/2017 06:29 PM, Dan Haab wrote:
> Luxul XAP-1410 in a dual-band access point device based on BCM47081 with
> serial flash. It has 3 LEDs and just one (reset) button.
>
> Signed-off-by: Dan Haab <dhaab-RSK6WAzFx3QAvxtiuMwx3w@public.gmane.org>
> ---
Applied, thanks
--
Florian
--
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 1/3] Input: add STMicroelectronics FingerTip touchscreen driver
From: Andi Shyti @ 2017-01-18 1:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Dmitry Torokhov, Rob Herring, Chanwoo Choi,
Javier Martinez Canillas, linux-input, devicetree, linux-kernel,
linux-samsung-soc, Andi Shyti
In-Reply-To: <20170117184332.6ne4ercemll6qrbm@kozik-lap>
Hi Krzysztof,
> > +Optional properties:
> > +- touch-key-connected : specifies whether the touchkey feature is connected
>
> You are making it a generic property but it is specific to this device,
> so:
> st,touch-key-connected
> ?
>
> > +- ledvdd-supply : power supply to the touch key leds
>
> Is this really optional? If yes... how it gets the power when not
> provided?
yes, it is. This is required only if (st,)touch-key-connected is
added, it's not required in any other case. Anyway, even if not
present, the device works, just without leds, which is fine for
me.
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH 1/3] Input: add STMicroelectronics FingerTip touchscreen driver
From: Andi Shyti @ 2017-01-18 1:16 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Krzysztof Kozlowski, Rob Herring, Chanwoo Choi,
Javier Martinez Canillas, linux-input, devicetree, linux-kernel,
linux-samsung-soc, Andi Shyti
In-Reply-To: <20170117204711.GB6888@dtor-ws>
Hi Dmitry,
> > > +- ledvdd-supply : power supply to the touch key leds
> >
> > Is this really optional? If yes... how it gets the power when not
> > provided?
>
> Also, is this really a regulator? Given you are testing whether it is on
> or off to report LED state it feels to me it might be a GPIO pin, not
> regulator...
In this case it's a real regulator, not a GPIO. But even if it
was a GPIO, I still could use gpio-regulator[*] which handles
gpio using the regulator framework. In this case, depending on
how the leds are enabled on the DTS, in the driver I would use
only one api (regulators indeed) for both the cases.
Thanks,
Andi
[*] Documentation/devicetree/bindings/regulator/gpio-regulator.txt
^ permalink raw reply
* Re: [PATCH 2/3] Input: add support for the STMicroelectronics FingerTip touchscreen
From: Andi Shyti @ 2017-01-18 1:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Krzysztof Kozlowski, Rob Herring, Chanwoo Choi,
Javier Martinez Canillas, linux-input, devicetree, linux-kernel,
linux-samsung-soc, Andi Shyti
In-Reply-To: <20170117212128.GC6888@dtor-ws>
Hi Dmitry,
thanks for looking into the driver and the review!
I agree with almost everything, some comments below.
> > + /* optional tuning */
> > + err = stmfts_write_and_wait(sdata, STMFTS_MS_CX_TUNING);
> > + if (err)
> > + dev_warn(&sdata->client->dev, "failed to perform mutual auto tune\n");
> > +
> > + /* optional tuning */
> > + err = stmfts_write_and_wait(sdata, STMFTS_SS_CX_TUNING);
> > + if (err)
> > + dev_warn(&sdata->client->dev, "failed to perform self auto tune\n");
> > +
> > + err = stmfts_write_and_wait(sdata, STMFTS_FULL_FORCE_CALIBRATION);
> > + if (err)
> > + return err;
>
> Hmm, do you need to calibrate on boot, or maybe wait for the device to
> be opened first?
The datasheet says that I need to calibrate during boot. Anyway,
the calibration requires some time (it can be up to a couple of
seconds), therefore I wouldn't like to calibrate everytime
someone opens the device.
> > +static int stmfts_enable_key(struct stmfts_data *sdata)
> > +{
> > + int err;
> > +
> > + sdata->input_key = devm_input_allocate_device(&sdata->client->dev);
> > + if (!sdata->input_key)
> > + return -ENOMEM;
> > +
> > + sdata->input_key->name = "stmfts_key";
> > + sdata->input_key->id.bustype = BUS_I2C;
> > + sdata->input_key->open = stmfts_input_key_open;
> > + sdata->input_key->close = stmfts_input_key_close;
>
> If you want separate input device for keys I'd recommend setting ->phys
> on them. Another option is to add keys to teh touchscreen device. Do you
> expect different actors listening to these devices? Even with different
> actors you can program event masks so that if process is not interested
> in some events (like ABS_MT_* events) it is not woken up when dveice
> generates them.
Are you suggesting to drop one event interface?
The reason why I chose to generate two interfaces is indeed
because there might be be different processes completely
unrelated to each other that will interact with the device (for
example in Jaechul's driver that you just reviewed, touchscreen
and touchkey are different devices).
I chose it for coherency with the common userspace architecture.
But of course, I can do as you recommend.
I have one more question. This touchscreen has also a proximity
functionality that works exactly as a proximity sensor and I
planned to add it in the future. Would it make sense to use the
iio framework (as it behaves as a proximity sensor) or use the
current interface? For instance, I was going to use the iio.
> > + /* get the regulator for powering the leds on */
> > + sdata->ledvdd = devm_regulator_get(&sdata->client->dev, "ledvdd");
> > + if (IS_ERR(sdata->ledvdd))
> > + /* there is no LED connected to the touch key */
> > + sdata->ledvdd = NULL;
>
> As I mentioned, is it truly regulator, or just a GPIO?
As I wrote in the previous mail, this is truly a regulator. If it
was a gpio, I would still prefer to use the regulator_* functions
as those would be managed by regulator-gpio and I don't need to
change the driver for that.
Thanks a lot,
Andi
^ permalink raw reply
* Re: [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
From: Icenowy Zheng @ 2017-01-18 3:13 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: linux-kernel, Greg Kroah-Hartman,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Rob Herring,
Bin Liu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Kishon Vijay Abraham I,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Maxime Ripard,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
2017年1月18日 04:09于 Chen-Yu Tsai <wens@csie.org>写道：
>
> Hi,
>
> On Wed, Jan 18, 2017 at 4:06 AM, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > On Wed, Jan 18, 2017 at 12:57:08AM +0800, Icenowy Zheng wrote:
> >>
> >>
> >> 17.01.2017, 16:06, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> >> > On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote:
> >> >> The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
> >> >> controller.
> >> >>
> >> >> The original driver wired it to OHCI/EHCI controller; however, as the
> >> >> code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
> >> >> unusable.
> >> >>
> >> >> Rename the register (according to its function and the name in BSP
> >> >> driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
> >> >> can support both peripheral and host mode (although the host mode of
> >> >> MUSB is buggy).
> >> >
> >> > Can you elaborate on that? What's wrong with it?
> >>
> >> The configuration is at bit 0 of register 0x20 in PHY.
> >>
> >> When the PHY is reseted, it defaults as MUSB mode.
> >>
> >> However, the original author of the H3 PHY code seems to be lack of
> >> this knowledge (He named it PHY_UNK_H3), and changed the PHY to HCI
> >> mode.
> >>
> >> I just removed the code that wires it to HCI mode, thus it will work
> >> in MUSB mode, with my sun8i-h3-musb patch.
> >
> > I have no idea what you mean by MUSB mode.
> >
> > Do you mean that the previous code was only working in host mode, and
> > now it only works in peripheral?
>
> From what I understand, with the H3, Allwinner has put a mux
> in front of the MUSB controller. The mux can send the USB data
> to/from the MUSB controller, or a standard EHCI/OHCI pair.
> This register controls said mux.
>
> This means we can use a proper USB host for host mode,
> instead of the limited support in MUSB.
>
Yes you got it.
The MUSB controller can also be used in host mode, but weaker then EHCI/OHCI.
> ChenYu
>
> >
> > 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 v4 1/4] PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API
From: Viresh Kumar @ 2017-01-18 3:14 UTC (permalink / raw)
To: Dave Gerlach
Cc: Nishanth Menon, devicetree, linux-pm, Tony Lindgren,
Rafael J . Wysocki, Rob Herring, linux-omap, linux-arm-kernel
In-Reply-To: <20170117131808.29798-2-d-gerlach@ti.com>
On 17-01-17, 07:18, Dave Gerlach wrote:
> Rename _of_get_opp_desc_node to dev_pm_opp_of_get_opp_desc_node and add it
> to include/linux/pm_opp.h to allow other drivers, such as platform OPP
> and cpufreq drivers, to make use of it.
>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> v3->v4:
> Export dev_pm_opp_of_get_opp_desc_node for use in modules.
>
> drivers/base/power/opp/of.c | 9 +++++----
> include/linux/pm_opp.h | 6 ++++++
> 2 files changed, 11 insertions(+), 4 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: exynos: Add USB 3.0 controller node for Exynos7
From: pankaj.dubey @ 2017-01-18 3:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-samsung-soc, Vivek Gautam, javier, robh+dt,
kgene, sanath, linux-arm-kernel
In-Reply-To: <20170117182318.fvatrazvyuzmdsor@kozik-lap>
On Tuesday 17 January 2017 11:53 PM, Krzysztof Kozlowski wrote:
> On Tue, Jan 17, 2017 at 08:34:03PM +0530, Pankaj Dubey wrote:
>> From: Vivek Gautam <gautamvivek1987@gmail.com>
>>
>> Add USB 3.0 DRD controller device node, with its clock
>> and phy information to enable the same on Exynos7.
>>
>> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> Signed-off-by: Vivek Gautam <gautamvivek1987@gmail.com>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>
> Javier's Reviewed-by should be at the end.
>
OK, will update.
>> ---
>> arch/arm64/boot/dts/exynos/exynos7.dtsi | 34 +++++++++++++++++++++++++++++++++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> index 9080a11..a2d8d11 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> @@ -603,6 +603,40 @@
>> #include "exynos7-trip-points.dtsi"
>> };
>> };
>> +
>> + usbdrd_phy: phy@15500000 {
>> + compatible = "samsung,exynos7-usbdrd-phy";
>> + reg = <0x15500000 0x100>;
>> + clocks = <&clock_fsys0 ACLK_USBDRD300>,
>> + <&clock_fsys0 OSCCLK_PHY_CLKOUT_USB30_PHY>,
>> + <&clock_fsys0 PHYCLK_USBDRD300_UDRD30_PIPE_PCLK_USER>,
>> + <&clock_fsys0 PHYCLK_USBDRD300_UDRD30_PHYCLK_USER>,
>> + <&clock_fsys0 SCLK_USBDRD300_REFCLK>;
>> + clock-names = "phy", "ref", "phy_pipe",
>> + "phy_utmi", "itp";
>> + samsung,pmu-syscon = <&pmu_system_controller>;
>> + #phy-cells = <1>;
>> + };
>> +
>> + usbdrd3: usb@15400000 {
>> + compatible = "samsung,exynos7-dwusb3";
>> + clocks = <&clock_fsys0 ACLK_USBDRD300>,
>> + <&clock_fsys0 SCLK_USBDRD300_SUSPENDCLK>,
>> + <&clock_fsys0 ACLK_AXIUS_USBDRD30X_FSYS0X>;
>> + clock-names = "usbdrd30", "usbdrd30_susp_clk",
>> + "usbdrd30_axius_clk";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>> + dwc3 {
>
> dtc should complain here - you need:
> dwc3@15400000
No, it didn't complain. Anyway, I will update as it's already taken care
in other Exynos SoC DTSi files.
> In the same time I think the address node does not have to be put after
> parent's usb.
>
OK, will update.
Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
>
>> + compatible = "snps,dwc3";
>> + reg = <0x15400000 0x10000>;
>> + interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
>> + phys = <&usbdrd_phy 0>, <&usbdrd_phy 1>;
>> + phy-names = "usb2-phy", "usb3-phy";
>> + };
>> + };
>> };
>> };
>>
>> --
>> 2.7.4
>>
>
>
>
^ permalink raw reply
* Re: [PATCH v4 2/4] Documentation: dt: add bindings for ti-cpufreq
From: Viresh Kumar @ 2017-01-18 3:16 UTC (permalink / raw)
To: Dave Gerlach
Cc: Nishanth Menon, devicetree, linux-pm, Tony Lindgren,
Rafael J . Wysocki, Rob Herring, linux-omap, linux-arm-kernel
In-Reply-To: <20170117131808.29798-3-d-gerlach@ti.com>
On 17-01-17, 07:18, Dave Gerlach wrote:
> Add the device tree bindings document for the TI CPUFreq/OPP driver
> on AM33xx, AM43xx, DRA7xx, and AM57xx SoCs. The operating-points-v2
> binding allows us to provide an opp-supported-hw property for each OPP
> to define when it is available. This driver is responsible for reading
> and parsing registers to determine which OPPs can be selectively enabled
> based on the specific SoC in use by matching against the opp-supported-hw
> data.
>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> v3->v4:
> Update to simplify binding, only use "syscon" now to pass control
> module register space and let driver handle offsets.
>
> .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 128 +++++++++++++++++++++
> 1 file changed, 128 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH v4 3/4] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
From: Viresh Kumar @ 2017-01-18 3:17 UTC (permalink / raw)
To: Dave Gerlach
Cc: Rob Herring, Rafael J . Wysocki, linux-arm-kernel, linux-omap,
linux-pm, devicetree, Tony Lindgren, Nishanth Menon
In-Reply-To: <20170117131808.29798-4-d-gerlach@ti.com>
On 17-01-17, 07:18, Dave Gerlach wrote:
> Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families,
> have different OPPs available for the MPU depending on which specific
> variant of the SoC is in use. This can be determined through use of the
> revision and an eFuse register present in the silicon. Introduce a
> ti-cpufreq driver that can read the aformentioned values and provide
> them as version matching data to the opp framework. Through this the
> opp-supported-hw dt binding that is part of the operating-points-v2
> table can be used to indicate availability of OPPs for each device.
>
> This driver also creates the "cpufreq-dt" platform_device after passing
> the version matching data to the OPP framework so that the cpufreq-dt
> handles the actual cpufreq implementation. Even without the necessary
> data to pass the version matching data the driver will still create this
> device to maintain backwards compatibility with operating-points v1
> tables.
>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> v3->v4:
> Update to use simplified binding, only use "syscon" now to pass control
> module register space and add offsets to relevant data for each SoC.
>
> drivers/cpufreq/Kconfig.arm | 11 ++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/ti-cpufreq.c | 272 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 284 insertions(+)
> create mode 100644 drivers/cpufreq/ti-cpufreq.c
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH v4 4/4] cpufreq: dt: Don't use generic platdev driver for ti-cpufreq platforms
From: Viresh Kumar @ 2017-01-18 3:17 UTC (permalink / raw)
To: Dave Gerlach
Cc: Rob Herring, Rafael J . Wysocki,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren, Nishanth Menon
In-Reply-To: <20170117131808.29798-5-d-gerlach-l0cyMroinI0@public.gmane.org>
On 17-01-17, 07:18, Dave Gerlach wrote:
> Some TI platforms, specifically those in the am33xx, am43xx, dra7xx, and
> am57xx families of SoCs can make use of the ti-cpufreq driver to
> selectively enable OPPs based on the exact configuration in use. The
> ti-cpufreq is given the responsibility of creating the cpufreq-dt
> platform device when the driver is in use so drop am33xx and dra7xx
> from the cpufreq-dt-platdev driver so it is not created twice.
>
> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 7fcaf26e8f81..921b4a6c3d16 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -87,8 +87,6 @@ static const struct of_device_id machines[] __initconst = {
> { .compatible = "socionext,uniphier-ld11", },
> { .compatible = "socionext,uniphier-ld20", },
>
> - { .compatible = "ti,am33xx", },
> - { .compatible = "ti,dra7", },
> { .compatible = "ti,omap2", },
> { .compatible = "ti,omap3", },
> { .compatible = "ti,omap4", },
Acked-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
--
viresh
--
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 v2 2/2] arm64: dts: exynos: Add regulators for Vbus and Vbus-Boost
From: pankaj.dubey @ 2017-01-18 3:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-samsung-soc, Vivek Gautam, javier, robh+dt,
kgene, sanath, linux-arm-kernel
In-Reply-To: <20170117182826.gngf7gjkvfyg3uww@kozik-lap>
On Tuesday 17 January 2017 11:58 PM, Krzysztof Kozlowski wrote:
> On Tue, Jan 17, 2017 at 08:34:04PM +0530, Pankaj Dubey wrote:
>> From: Vivek Gautam <gautamvivek1987@gmail.com>
>>
>> Adding fixed voltage regulators for Vbus and Vbus-boost required
>> by USB 3.0 DRD controller on Exynos7-espresso board.
>>
>> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> Signed-off-by: Vivek Gautam <gautamvivek1987@gmail.com>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>
> Same as patch 1.
>
OK, will update.
>> ---
>> arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 45 +++++++++++++++++++++++++
>> 1 file changed, 45 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>> index 9cf73cf..8d5abdd 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>> @@ -13,6 +13,7 @@
>> #include "exynos7.dtsi"
>> #include <dt-bindings/interrupt-controller/irq.h>
>> #include <dt-bindings/clock/samsung,s2mps11.h>
>> +#include <dt-bindings/gpio/gpio.h>
>>
>> / {
>> model = "Samsung Exynos7 Espresso board based on EXYNOS7";
>> @@ -33,6 +34,29 @@
>> device_type = "memory";
>> reg = <0x0 0x40000000 0x0 0xC0000000>;
>> };
>> +
>> + usb30_vbus_reg: regulator-usb30 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VBUS_5V";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + gpio = <&gph1 1 GPIO_ACTIVE_HIGH>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&usb30_vbus_en>;
>> + enable-active-high;
>> + };
>> +
>> + usb3drd_boost_5v: regulator-usb3drd-boost {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VUSB_VBUS_5V";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + gpio = <&gpf4 1 GPIO_ACTIVE_HIGH>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&usb3drd_boost_en>;
>> + enable-active-high;
>> + };
>> +
>> };
>>
>> &fin_pll {
>> @@ -366,3 +390,24 @@
>> vqmmc-supply = <&ldo2_reg>;
>> disable-wp;
>> };
>> +
>> +&usbdrd_phy {
>> + vbus-supply = <&usb30_vbus_reg>;
>> + vbus-boost-supply = <&usb3drd_boost_5v>;
>> +};
>> +
>> +&pinctrl_bus1 {
>> + usb30_vbus_en: usb30-vbus-en {
>> + samsung,pins = "gph1-1";
>> + samsung,pin-function = <1>;
>
> Javier mentioned it, please use EXYNOS_PIN_FUNC_OUTPUT
>
Yes, but as it's not taken care in existing dts for other pin
definitions, so a Javier mentioned, this can be taken care as a separate
patch for all pin definitions? Or do you want me to first add patch
converting all these with macros and then on top of add this usb related
pin definitions.
Thanks,
Pankaj Dubey
>> + samsung,pin-pud = <0>;
>
> EXYNOS_PIN_PULL_NONE
>
>> + samsung,pin-drv = <0>;
>
> I think these are the same as in Exynos5422, so EXYNOS5420_PIN_DRV_LV1
>
> Best regards,
> Krzysztof
>
>
>> + };
>> +
>> + usb3drd_boost_en: usb3drd-boost-en {
>> + samsung,pins = "gpf4-1";
>> + samsung,pin-function = <1>;
>> + samsung,pin-pud = <0>;
>> + samsung,pin-drv = <0>;
>> + };
>> +};
>> --
>> 2.7.4
>>
>
>
>
^ permalink raw reply
* Re: [PATCH 1/5] ARM: OMAP2+: omap_hwmod: Add support for earlycon
From: Lokesh Vutla @ 2017-01-18 3:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linux OMAP Mailing List, Device Tree Mailing List, Rob Herring,
Tero Kristo, Sekhar Nori, Vignesh R, Nishanth Menon
In-Reply-To: <20170117232310.GX7403-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Wednesday 18 January 2017 04:53 AM, Tony Lindgren wrote:
> * Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org> [170116 20:06]:
>> Hwmod core tries to reset and idles each IP that is registered with hwmod.
>> In case of earlycon, that specific uart IP cannot be reset or keep it in
>> idle state else earlycon hangs once hwmod resets that uart IP. So add support
>> to not reset uart that is being used as earlycon only if CONFIG_SERIAL_EARLYCON
>> is enabled.
>
> Nice :)
>
> I guess this has no dependency to SERIAL_OMAP vs 8250_OMAP selection?
Unfortunately SERIAL_OMAP does not support earlycon yet. As I mentioned
in my cover letter, I verified this series only with 8250_OMAP.
Thanks and regards,
Lokesh
--
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/5] ARM: OMAP2+: Add earlycon support
From: Lokesh Vutla @ 2017-01-18 4:03 UTC (permalink / raw)
To: Tony Lindgren, Linux OMAP Mailing List
Cc: Device Tree Mailing List, Rob Herring, Mark Rutland, Tero Kristo,
Sekhar Nori, Nishanth Menon, Vignesh R, Lokesh Vutla
This series adds earlycon support for all am33xx, am43xx, am57xx, dra7xx
based TI platforms. With this series just passing "earlycon" in bootargs
is sufficient for early debug.
Tested with omap2plus_defconfig + CONFIG_SERIAL_8250_OMAP.
Changes since v1:
- Dropped searching for /chosen@0 node as pointed out by Mark.
Lokesh Vutla (5):
ARM: OMAP2+: omap_hwmod: Add support for earlycon
ARM: dts: am33xx: Add stdout-path property
ARM: dts: am43xx: Add stdout-path property
ARM: dts: am57xx: Add stdout-path property
ARM: dts: dra7xx: Add stdout-path property
arch/arm/boot/dts/am335x-evm.dts | 4 +++
arch/arm/boot/dts/am335x-evmsk.dts | 4 +++
arch/arm/boot/dts/am335x-icev2.dts | 4 +++
arch/arm/boot/dts/am437x-gp-evm.dts | 4 +++
arch/arm/boot/dts/am437x-idk-evm.dts | 4 +++
arch/arm/boot/dts/am437x-sk-evm.dts | 4 +++
arch/arm/boot/dts/am43x-epos-evm.dts | 4 +++
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 4 +++
arch/arm/boot/dts/am57xx-idk-common.dtsi | 4 +++
arch/arm/boot/dts/dra7-evm.dts | 4 +++
arch/arm/boot/dts/dra72-evm-common.dtsi | 4 +++
arch/arm/mach-omap2/omap_hwmod.c | 33 +++++++++++++++++++++++++
12 files changed, 77 insertions(+)
--
2.11.0
--
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/5] ARM: OMAP2+: omap_hwmod: Add support for earlycon
From: Lokesh Vutla @ 2017-01-18 4:03 UTC (permalink / raw)
To: Tony Lindgren, Linux OMAP Mailing List
Cc: Device Tree Mailing List, Rob Herring, Mark Rutland, Tero Kristo,
Sekhar Nori, Nishanth Menon, Vignesh R, Lokesh Vutla
In-Reply-To: <20170118040326.29259-1-lokeshvutla-l0cyMroinI0@public.gmane.org>
Hwmod core tries to reset and idles each IP that is registered with hwmod.
In case of earlycon, that specific uart IP cannot be reset or keep it in
idle state else earlycon hangs once hwmod resets that uart IP. So add support
to not reset uart that is being used as earlycon only if CONFIG_SERIAL_EARLYCON
is enabled.
Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
---
arch/arm/mach-omap2/omap_hwmod.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e8b988714a09..0da4f2ea76c4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3249,6 +3249,36 @@ int __init omap_hwmod_setup_one(const char *oh_name)
}
/**
+ * omap_hwmod_setup_earlycon_flags - set up flags for early console
+ *
+ * Enable DEBUG_OMAPUART_FLAGS for uart hwmod that is being used as
+ * early concole so that hwmod core doesn't reset and keep it in idle
+ * that specific uart.
+ */
+#ifdef CONFIG_SERIAL_EARLYCON
+static void __init omap_hwmod_setup_earlycon_flags(void)
+{
+ struct device_node *np;
+ struct omap_hwmod *oh;
+ const char *uart;
+
+ np = of_find_node_by_path("/chosen");
+ if (np) {
+ uart = of_get_property(np, "stdout-path", NULL);
+ if (uart) {
+ np = of_find_node_by_path(uart);
+ if (np) {
+ uart = of_get_property(np, "ti,hwmods", NULL);
+ oh = omap_hwmod_lookup(uart);
+ if (oh)
+ oh->flags |= DEBUG_OMAPUART_FLAGS;
+ }
+ }
+ }
+}
+#endif
+
+/**
* omap_hwmod_setup_all - set up all registered IP blocks
*
* Initialize and set up all IP blocks registered with the hwmod code.
@@ -3261,6 +3291,9 @@ static int __init omap_hwmod_setup_all(void)
_ensure_mpu_hwmod_is_setup(NULL);
omap_hwmod_for_each(_init, NULL);
+#ifdef CONFIG_SERIAL_EARLYCON
+ omap_hwmod_setup_earlycon_flags();
+#endif
omap_hwmod_for_each(_setup, NULL);
return 0;
--
2.11.0
--
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 related
* [PATCH v2 2/5] ARM: dts: am33xx: Add stdout-path property
From: Lokesh Vutla @ 2017-01-18 4:03 UTC (permalink / raw)
To: Tony Lindgren, Linux OMAP Mailing List
Cc: Device Tree Mailing List, Rob Herring, Mark Rutland, Tero Kristo,
Sekhar Nori, Nishanth Menon, Vignesh R, Lokesh Vutla
In-Reply-To: <20170118040326.29259-1-lokeshvutla-l0cyMroinI0@public.gmane.org>
Add stdout-path property in /chosen node so that earlycon can be
used by just adding earlycon in bootargs.
Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/am335x-evm.dts | 4 ++++
arch/arm/boot/dts/am335x-evmsk.dts | 4 ++++
arch/arm/boot/dts/am335x-icev2.dts | 4 ++++
3 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index c2186ec2834b..1c37a7c1ea17 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -25,6 +25,10 @@
reg = <0x80000000 0x10000000>; /* 256 MB */
};
+ chosen {
+ stdout-path = &uart0;
+ };
+
vbat: fixedregulator0 {
compatible = "regulator-fixed";
regulator-name = "vbat";
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index e2548d1ce753..9e43c443738a 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -32,6 +32,10 @@
reg = <0x80000000 0x10000000>; /* 256 MB */
};
+ chosen {
+ stdout-path = &uart0;
+ };
+
vbat: fixedregulator0 {
compatible = "regulator-fixed";
regulator-name = "vbat";
diff --git a/arch/arm/boot/dts/am335x-icev2.dts b/arch/arm/boot/dts/am335x-icev2.dts
index 1463df3b5b19..ff9417ce93c0 100644
--- a/arch/arm/boot/dts/am335x-icev2.dts
+++ b/arch/arm/boot/dts/am335x-icev2.dts
@@ -24,6 +24,10 @@
reg = <0x80000000 0x10000000>; /* 256 MB */
};
+ chosen {
+ stdout-path = &uart3;
+ };
+
vbat: fixedregulator0 {
compatible = "regulator-fixed";
regulator-name = "vbat";
--
2.11.0
--
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 related
* [PATCH v2 3/5] ARM: dts: am43xx: Add stdout-path property
From: Lokesh Vutla @ 2017-01-18 4:03 UTC (permalink / raw)
To: Tony Lindgren, Linux OMAP Mailing List
Cc: Device Tree Mailing List, Rob Herring, Mark Rutland, Tero Kristo,
Sekhar Nori, Nishanth Menon, Vignesh R, Lokesh Vutla
In-Reply-To: <20170118040326.29259-1-lokeshvutla-l0cyMroinI0@public.gmane.org>
Add stdout-path property in /chosen node so that earlycon can be
used by just adding earlycon in bootargs.
Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/am437x-gp-evm.dts | 4 ++++
arch/arm/boot/dts/am437x-idk-evm.dts | 4 ++++
arch/arm/boot/dts/am437x-sk-evm.dts | 4 ++++
arch/arm/boot/dts/am43x-epos-evm.dts | 4 ++++
4 files changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
index 957840cc7b78..a4f31739057f 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -23,6 +23,10 @@
display0 = &lcd0;
};
+ chosen {
+ stdout-path = &uart0;
+ };
+
evm_v3_3d: fixedregulator-v3_3d {
compatible = "regulator-fixed";
regulator-name = "evm_v3_3d";
diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts b/arch/arm/boot/dts/am437x-idk-evm.dts
index b76a7c0264a5..c1f7f9336e64 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -18,6 +18,10 @@
model = "TI AM437x Industrial Development Kit";
compatible = "ti,am437x-idk-evm","ti,am4372","ti,am43";
+ chosen {
+ stdout-path = &uart0;
+ };
+
v24_0d: fixed-regulator-v24_0d {
compatible = "regulator-fixed";
regulator-name = "V24_0D";
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
index 319d94205350..4dc54bee2f36 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -24,6 +24,10 @@
display0 = &lcd0;
};
+ chosen {
+ stdout-path = &uart0;
+ };
+
/* fixed 32k external oscillator clock */
clk_32k_rtc: clk_32k_rtc {
#clock-cells = <0>;
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index 9d35c3f07cad..9acd4ccdec4e 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -24,6 +24,10 @@
display0 = &lcd0;
};
+ chosen {
+ stdout-path = &uart0;
+ };
+
vmmcsd_fixed: fixedregulator-sd {
compatible = "regulator-fixed";
regulator-name = "vmmcsd_fixed";
--
2.11.0
--
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 related
* [PATCH v2 4/5] ARM: dts: am57xx: Add stdout-path property
From: Lokesh Vutla @ 2017-01-18 4:03 UTC (permalink / raw)
To: Tony Lindgren, Linux OMAP Mailing List
Cc: Device Tree Mailing List, Rob Herring, Mark Rutland, Tero Kristo,
Sekhar Nori, Nishanth Menon, Vignesh R, Lokesh Vutla
In-Reply-To: <20170118040326.29259-1-lokeshvutla-l0cyMroinI0@public.gmane.org>
Add stdout-path property in /chosen node so that earlycon can be
used by just adding earlycon in bootargs.
Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 4 ++++
arch/arm/boot/dts/am57xx-idk-common.dtsi | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 78bee26361f1..3a95db7da71f 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -22,6 +22,10 @@
display0 = &hdmi0;
};
+ chosen {
+ stdout-path = &uart3;
+ };
+
memory@0 {
device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 814a720d5c3d..0d341c545b01 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -14,6 +14,10 @@
rtc1 = &rtc;
};
+ chosen {
+ stdout-path = &uart3;
+ };
+
vmain: fixedregulator-vmain {
compatible = "regulator-fixed";
regulator-name = "VMAIN";
--
2.11.0
--
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 related
* [PATCH v2 5/5] ARM: dts: dra7xx: Add stdout-path property
From: Lokesh Vutla @ 2017-01-18 4:03 UTC (permalink / raw)
To: Tony Lindgren, Linux OMAP Mailing List
Cc: Device Tree Mailing List, Rob Herring, Mark Rutland, Tero Kristo,
Sekhar Nori, Nishanth Menon, Vignesh R, Lokesh Vutla
In-Reply-To: <20170118040326.29259-1-lokeshvutla-l0cyMroinI0@public.gmane.org>
Add stdout-path property in /chosen node so that earlycon can be
used by just adding earlycon in bootargs.
Tested-by: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/dra7-evm.dts | 4 ++++
arch/arm/boot/dts/dra72-evm-common.dtsi | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 132f2be10889..b3923c049edb 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -21,6 +21,10 @@
reg = <0x0 0x80000000 0x0 0x60000000>; /* 1536 MB */
};
+ chosen {
+ stdout-path = &uart1;
+ };
+
evm_3v3_sd: fixedregulator-sd {
compatible = "regulator-fixed";
regulator-name = "evm_3v3_sd";
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index e50fbeea96e0..45b62138cbde 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -18,6 +18,10 @@
display0 = &hdmi0;
};
+ chosen {
+ stdout-path = &uart1;
+ };
+
evm_12v0: fixedregulator-evm12v0 {
/* main supply */
compatible = "regulator-fixed";
--
2.11.0
--
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 related
* Re: [PATCH v2 1/2] arm64: dts: exynos: Add USB 3.0 controller node for Exynos7
From: Javier Martinez Canillas @ 2017-01-18 4:27 UTC (permalink / raw)
To: pankaj.dubey
Cc: Krzysztof Kozlowski,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Vivek Gautam, Javier Martinez Canillas, Rob Herring, Kukjin Kim,
sanath-Sze3O3UU22JBDgjK7y7TUQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <9f45a921-ebfb-c252-20bb-3a7adf508343-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Hello Pankaj,
On Wed, Jan 18, 2017 at 12:16 AM, pankaj.dubey <pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> On Tuesday 17 January 2017 11:53 PM, Krzysztof Kozlowski wrote:
[snip]
>>> +
>>> + dwc3 {
>>
>> dtc should complain here - you need:
>> dwc3@15400000
>
> No, it didn't complain. Anyway, I will update as it's already taken care
> in other Exynos SoC DTSi files.
>
It only complains if you run dtc with warnings enabled, i.e: make W=1
exynos7-espresso.dtb
Best regards,
Javier
--
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 v5 1/3] dt: bindings: add documentation for zx2967 family thermal sensor
From: Baoyou Xie @ 2017-01-18 4:42 UTC (permalink / raw)
To: jun.nie, rui.zhang, edubezval, robh+dt, mark.rutland
Cc: devicetree, linux-pm, xie.baoyou, linux-kernel, chen.chaokai,
wang.qiang01, baoyou.xie, shawnguo, linux-arm-kernel
This patch adds dt-binding documentation for zx2967 family thermal sensor.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Shawn Guo <shawnguo@kernel.org>
---
.../devicetree/bindings/thermal/zx2967-thermal.txt | 109 +++++++++++++++++++++
1 file changed, 109 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
new file mode 100644
index 0000000..a96c8b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
@@ -0,0 +1,109 @@
+* ZTE zx2967 family Thermal
+
+Required Properties:
+- compatible: should be one of the following.
+ * zte,zx296718-thermal
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- clocks : Pairs of phandle and specifier referencing the controller's clocks.
+- clock-names: "gate" for the topcrm clock.
+ "pclk" for the apb clock.
+- #thermal-sensor-cells: must be 0.
+
+Example for tempsensor:
+
+ tempsensor: tempsensor@148a000 {
+ compatible = "zte,zx296718-thermal";
+ reg = <0x0148a000 0x20>;
+ clocks = <&topcrm TEMPSENSOR_GATE>, <&audiocrm AUDIO_TS_PCLK>;
+ clock-names = "gate", "pclk";
+ #thermal-sensor-cells = <0>;
+ };
+
+Example for cooling device:
+
+ cooling_dev: cooling_dev {
+ cluster0_cooling_dev: cluster0-cooling-dev {
+ #cooling-cells = <2>;
+ cpumask = <0xf>;
+ capacitance = <1500>;
+ };
+
+ cluster1_cooling_dev: cluster1-cooling-dev {
+ #cooling-cells = <2>;
+ cpumask = <0x30>;
+ capacitance = <2000>;
+ };
+ };
+
+Example for thermal zones:
+
+ thermal-zones {
+ zx296718_thermal: zx296718_thermal {
+ polling-delay-passive = <500>;
+ polling-delay = <1000>;
+ sustainable-power = <6500>;
+
+ thermal-sensors = <&tempsensor 0>;
+
+ trips {
+ trip0: switch_on_temperature {
+ temperature = <90000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ trip1: desired_temperature {
+ temperature = <100000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ crit: critical_temperature {
+ temperature = <110000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&trip0>;
+ cooling-device = <&gpu 2 5>;
+ };
+
+ map1 {
+ trip = <&trip0>;
+ cooling-device = <&cluster0_cooling_dev 1 2>;
+ };
+
+ map2 {
+ trip = <&trip1>;
+ cooling-device = <&cluster0_cooling_dev 1 2>;
+ };
+
+ map3 {
+ trip = <&crit>;
+ cooling-device = <&cluster0_cooling_dev 1 2>;
+ };
+
+ map4 {
+ trip = <&trip0>;
+ cooling-device = <&cluster1_cooling_dev 1 2>;
+ contribution = <9000>;
+ };
+
+ map5 {
+ trip = <&trip1>;
+ cooling-device = <&cluster1_cooling_dev 1 2>;
+ contribution = <4096>;
+ };
+
+ map6 {
+ trip = <&crit>;
+ cooling-device = <&cluster1_cooling_dev 1 2>;
+ contribution = <4096>;
+ };
+ };
+ };
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/3] MAINTAINERS: add zx2967 thermal drivers to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-18 4:42 UTC (permalink / raw)
To: jun.nie, rui.zhang, edubezval, robh+dt, mark.rutland
Cc: devicetree, linux-pm, xie.baoyou, linux-kernel, chen.chaokai,
wang.qiang01, baoyou.xie, shawnguo, linux-arm-kernel
In-Reply-To: <1484714522-26651-1-git-send-email-baoyou.xie@linaro.org>
Add the zx2967 thermal drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5fb9b62..edfdea3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1989,10 +1989,12 @@ F: arch/arm/mach-zx/
F: drivers/clk/zte/
F: drivers/reset/reset-zx2967.c
F: drivers/soc/zte/
+F: drivers/thermal/zx*
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
F: Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
F: Documentation/devicetree/bindings/soc/zte/
+F: Documentation/devicetree/bindings/thermal/zx*
F: include/dt-bindings/soc/zx*.h
ARM/ZYNQ ARCHITECTURE
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family
From: Baoyou Xie @ 2017-01-18 4:42 UTC (permalink / raw)
To: jun.nie-QSEj5FYQhm4dnm+yROfE0A, rui.zhang-ral2JQCrhuEAvxtiuMwx3w,
edubezval-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
baoyou.xie-QSEj5FYQhm4dnm+yROfE0A,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
In-Reply-To: <1484714522-26651-1-git-send-email-baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This patch adds thermal driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/thermal/Kconfig | 8 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/zx2967_thermal.c | 256 +++++++++++++++++++++++++++++++++++++++
3 files changed, 265 insertions(+)
create mode 100644 drivers/thermal/zx2967_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 18f2de6..f64bd50 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -444,4 +444,12 @@ config BCM2835_THERMAL
help
Support for thermal sensors on Broadcom bcm2835 SoCs.
+config ZX2967_THERMAL
+ tristate "Thermal sensors on zx2967 SoC"
+ depends on ARCH_ZX || COMPILE_TEST
+ help
+ Enable the zx2967 thermal sensors driver, which supports
+ the primitive temperature sensor embedded in zx2967 SoCs.
+ This sensor generates the real time die temperature.
+
endif
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 677c6d9..c00c05e 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
+obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
diff --git a/drivers/thermal/zx2967_thermal.c b/drivers/thermal/zx2967_thermal.c
new file mode 100644
index 0000000..1f08c33
--- /dev/null
+++ b/drivers/thermal/zx2967_thermal.c
@@ -0,0 +1,256 @@
+/*
+ * ZTE's zx2967 family thermal sensor driver
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/thermal.h>
+
+/* Power Mode: 0->low 1->high */
+#define ZX2967_THERMAL_POWER_MODE 0
+
+/* DCF Control Register */
+#define ZX2967_THERMAL_DCF 0x4
+
+/* Selection Register */
+#define ZX2967_THERMAL_SEL 0x8
+
+/* Control Register */
+#define ZX2967_THERMAL_CTRL 0x10
+
+#define ZX2967_THERMAL_READY 0x1000
+#define ZX2967_THERMAL_TEMP_MASK 0xfff
+#define ZX2967_THERMAL_ID_MASK 0x18
+#define ZX2967_THERMAL_ID0 0x8
+#define ZX2967_THERMAL_ID1 0x10
+
+struct zx2967_thermal_sensor {
+ struct zx2967_thermal_priv *priv;
+ struct thermal_zone_device *tzd;
+ int id;
+};
+
+#define NUM_SENSORS 1
+
+struct zx2967_thermal_priv {
+ struct zx2967_thermal_sensor sensors[NUM_SENSORS];
+ /* Prevents reads sensor in parallel */
+ struct mutex lock;
+ struct clk *clk_gate;
+ struct clk *pclk;
+ void __iomem *regs;
+ struct device *dev;
+};
+
+static int zx2967_thermal_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+
+ if (priv && priv->pclk)
+ clk_disable_unprepare(priv->pclk);
+
+ if (priv && priv->clk_gate)
+ clk_disable_unprepare(priv->clk_gate);
+
+ return 0;
+}
+
+static int zx2967_thermal_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+ int error;
+
+ error = clk_prepare_enable(priv->clk_gate);
+ if (error)
+ return error;
+
+ error = clk_prepare_enable(priv->pclk);
+ if (error) {
+ clk_disable_unprepare(priv->clk_gate);
+ return error;
+ }
+
+ return 0;
+}
+
+static int zx2967_thermal_get_temp(void *data, int *temp)
+{
+ void __iomem *regs;
+ struct zx2967_thermal_sensor *sensor = data;
+ struct zx2967_thermal_priv *priv = sensor->priv;
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 val, sel_id;
+
+ regs = priv->regs;
+ mutex_lock(&priv->lock);
+
+ writel_relaxed(0, regs + ZX2967_THERMAL_POWER_MODE);
+ writel_relaxed(2, regs + ZX2967_THERMAL_DCF);
+
+ val = readl_relaxed(regs + ZX2967_THERMAL_SEL);
+ val &= ~ZX2967_THERMAL_ID_MASK;
+ sel_id = sensor->id ? ZX2967_THERMAL_ID0 : ZX2967_THERMAL_ID1;
+ val |= sel_id;
+ writel_relaxed(val, regs + ZX2967_THERMAL_SEL);
+
+ usleep_range(100, 300);
+ val = readl_relaxed(regs + ZX2967_THERMAL_CTRL);
+ while (!(val & ZX2967_THERMAL_READY)) {
+ if (time_after(jiffies, timeout)) {
+ dev_err(priv->dev, "Thermal sensor %d data timeout\n",
+ sensor->id);
+ mutex_unlock(&priv->lock);
+ return -ETIMEDOUT;
+ }
+ usleep_range(100, 300);
+ val = readl_relaxed(regs + ZX2967_THERMAL_CTRL);
+ }
+
+ writel_relaxed(3, regs + ZX2967_THERMAL_DCF);
+ val = readl_relaxed(regs + ZX2967_THERMAL_CTRL)
+ & ZX2967_THERMAL_TEMP_MASK;
+ writel_relaxed(1, regs + ZX2967_THERMAL_POWER_MODE);
+
+ /*
+ * Calculate temperature
+ * 922 initial value of calibration cure
+ * 1.951 slope of calibration cure
+ */
+ *temp = DIV_ROUND_CLOSEST((val - 922) * 1000, 1951);
+
+ mutex_unlock(&priv->lock);
+
+ return 0;
+}
+
+static struct thermal_zone_of_device_ops zx2967_of_thermal_ops = {
+ .get_temp = zx2967_thermal_get_temp,
+};
+
+static int zx2967_thermal_probe(struct platform_device *pdev)
+{
+ struct zx2967_thermal_priv *priv;
+ struct resource *res;
+ int ret, i;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(priv->regs))
+ return PTR_ERR(priv->regs);
+
+ priv->clk_gate = devm_clk_get(&pdev->dev, "gate");
+ if (IS_ERR(priv->clk_gate)) {
+ ret = PTR_ERR(priv->clk_gate);
+ dev_err(&pdev->dev, "failed to get clock gate: %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(priv->clk_gate);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to enable converter clock: %d\n",
+ ret);
+ return ret;
+ }
+
+ priv->pclk = devm_clk_get(&pdev->dev, "pclk");
+ if (IS_ERR(priv->pclk)) {
+ ret = PTR_ERR(priv->pclk);
+ clk_disable_unprepare(priv->clk_gate);
+ dev_err(&pdev->dev, "failed to get apb clock: %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(priv->pclk);
+ if (ret) {
+ clk_disable_unprepare(priv->clk_gate);
+ dev_err(&pdev->dev, "failed to enable converter clock: %d\n",
+ ret);
+ return ret;
+ }
+
+ mutex_init(&priv->lock);
+ for (i = 0; i < NUM_SENSORS; i++) {
+ struct zx2967_thermal_sensor *sensor = &priv->sensors[i];
+
+ sensor->priv = priv;
+ sensor->id = i;
+ sensor->tzd = thermal_zone_of_sensor_register(&pdev->dev,
+ i, sensor, &zx2967_of_thermal_ops);
+ if (IS_ERR(sensor->tzd)) {
+ ret = PTR_ERR(sensor->tzd);
+ dev_err(&pdev->dev, "failed to register sensor %d: %d\n",
+ i, ret);
+ goto remove_ts;
+ }
+ }
+ priv->dev = &pdev->dev;
+ platform_set_drvdata(pdev, priv);
+
+ return 0;
+
+remove_ts:
+ clk_disable_unprepare(priv->clk_gate);
+ clk_disable_unprepare(priv->pclk);
+ for (i--; i >= 0; i--)
+ thermal_zone_of_sensor_unregister(&pdev->dev,
+ priv->sensors[i].tzd);
+
+ return ret;
+}
+
+static int zx2967_thermal_exit(struct platform_device *pdev)
+{
+ struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+ int i;
+
+ for (i = 0; i < NUM_SENSORS; i++) {
+ struct zx2967_thermal_sensor *sensor = &priv->sensors[i];
+
+ thermal_zone_of_sensor_unregister(&pdev->dev, sensor->tzd);
+ }
+ clk_disable_unprepare(priv->pclk);
+ clk_disable_unprepare(priv->clk_gate);
+
+ return 0;
+}
+
+static const struct of_device_id zx2967_thermal_id_table[] = {
+ { .compatible = "zte,zx296718-thermal" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, zx2967_thermal_id_table);
+
+static SIMPLE_DEV_PM_OPS(zx2967_thermal_pm_ops,
+ zx2967_thermal_suspend, zx2967_thermal_resume);
+
+static struct platform_driver zx2967_thermal_driver = {
+ .probe = zx2967_thermal_probe,
+ .remove = zx2967_thermal_exit,
+ .driver = {
+ .name = "zx2967_thermal",
+ .of_match_table = zx2967_thermal_id_table,
+ .pm = &zx2967_thermal_pm_ops,
+ },
+};
+module_platform_driver(zx2967_thermal_driver);
+
+MODULE_AUTHOR("Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>");
+MODULE_DESCRIPTION("ZTE zx2967 thermal driver");
+MODULE_LICENSE("GPL v2");
--
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 related
* Re: [PATCH v2 2/2] arm64: dts: exynos: Add regulators for Vbus and Vbus-Boost
From: Krzysztof Kozlowski @ 2017-01-18 5:17 UTC (permalink / raw)
To: pankaj.dubey
Cc: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, kgene-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, sanath-Sze3O3UU22JBDgjK7y7TUQ,
Javier Martinez Canillas, Vivek Gautam
In-Reply-To: <68177964-890d-7061-dac0-f37717b1a254-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Wed, Jan 18, 2017 at 5:20 AM, pankaj.dubey <pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>
>
> On Tuesday 17 January 2017 11:58 PM, Krzysztof Kozlowski wrote:
>> On Tue, Jan 17, 2017 at 08:34:04PM +0530, Pankaj Dubey wrote:
>>> From: Vivek Gautam <gautamvivek1987-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>
>>> Adding fixed voltage regulators for Vbus and Vbus-boost required
>>> by USB 3.0 DRD controller on Exynos7-espresso board.
>>>
>>> Reviewed-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>>> Signed-off-by: Vivek Gautam <gautamvivek1987-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Signed-off-by: Pankaj Dubey <pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>
>> Same as patch 1.
>>
>
> OK, will update.
>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 45 +++++++++++++++++++++++++
>>> 1 file changed, 45 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>>> index 9cf73cf..8d5abdd 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>>> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
>>> @@ -13,6 +13,7 @@
>>> #include "exynos7.dtsi"
>>> #include <dt-bindings/interrupt-controller/irq.h>
>>> #include <dt-bindings/clock/samsung,s2mps11.h>
>>> +#include <dt-bindings/gpio/gpio.h>
>>>
>>> / {
>>> model = "Samsung Exynos7 Espresso board based on EXYNOS7";
>>> @@ -33,6 +34,29 @@
>>> device_type = "memory";
>>> reg = <0x0 0x40000000 0x0 0xC0000000>;
>>> };
>>> +
>>> + usb30_vbus_reg: regulator-usb30 {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "VBUS_5V";
>>> + regulator-min-microvolt = <5000000>;
>>> + regulator-max-microvolt = <5000000>;
>>> + gpio = <&gph1 1 GPIO_ACTIVE_HIGH>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&usb30_vbus_en>;
>>> + enable-active-high;
>>> + };
>>> +
>>> + usb3drd_boost_5v: regulator-usb3drd-boost {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "VUSB_VBUS_5V";
>>> + regulator-min-microvolt = <5000000>;
>>> + regulator-max-microvolt = <5000000>;
>>> + gpio = <&gpf4 1 GPIO_ACTIVE_HIGH>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&usb3drd_boost_en>;
>>> + enable-active-high;
>>> + };
>>> +
>>> };
>>>
>>> &fin_pll {
>>> @@ -366,3 +390,24 @@
>>> vqmmc-supply = <&ldo2_reg>;
>>> disable-wp;
>>> };
>>> +
>>> +&usbdrd_phy {
>>> + vbus-supply = <&usb30_vbus_reg>;
>>> + vbus-boost-supply = <&usb3drd_boost_5v>;
>>> +};
>>> +
>>> +&pinctrl_bus1 {
>>> + usb30_vbus_en: usb30-vbus-en {
>>> + samsung,pins = "gph1-1";
>>> + samsung,pin-function = <1>;
>>
>> Javier mentioned it, please use EXYNOS_PIN_FUNC_OUTPUT
>>
>
> Yes, but as it's not taken care in existing dts for other pin
> definitions, so a Javier mentioned, this can be taken care as a separate
> patch for all pin definitions? Or do you want me to first add patch
> converting all these with macros and then on top of add this usb related
> pin definitions.
For new code let's use the macros even if entire file is not converted
(yet). The same like mixture of values and GPIO_ACTIVE_* macros. If
you wish to convert the file to macros, feel free to go. But I see it
as separate patch.
Best regards,
Krzysztof
--
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 0/3] Use macros for pinctrl configuration on Exynos7
From: Pankaj Dubey @ 2017-01-18 5:42 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel, devicetree
Cc: krzk, kgene, robh+dt, sanath, javier, s.nawrocki, alim.akhtar,
Pankaj Dubey
In-Reply-To: <CGME20170118053944epcas1p1bed1518b3ba444434bfbe4048b6fe4bd@epcas1p1.samsung.com>
Currently Exynos7 DTSi files are using hard-coded values for pinctrl
configurations such as pin-function, pin-pud and pin-drv. These hard
coded values are difficult to understand without datasheet, lets use
macros for such configurations.
While doing this observed that Exynos7 has different drive strengths
values *ONLY* for FSYS1 blocks pins, so adding new macro definition
for the same in patch[2/3]
Also some of sd0_xxxx pin definition is using drive strength as 0x3 but
as per datasheet of Exynos7, FSYS1 block's pin does not support 0x3 value
for drive strenth so fixing the same in patch[1/3].
I have verified these patches for boot on Exynos7 based espresso board.
Pankaj Dubey (3):
arm64: dts: exynos: Fix drive strength of sd0_xxx pin definitions
pinctrl: dt-bindings: samsung: Add Exynos7 specific pinctrl macro
definitions
arm64: dts: exynos: Use macros for pinctrl configuration on Exynos7
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 4 +-
arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 302 ++++++++++++------------
include/dt-bindings/pinctrl/samsung.h | 8 +
3 files changed, 162 insertions(+), 152 deletions(-)
--
2.7.4
^ 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