* [PATCH 2/2] ARM: BCM5301X: Add DT for Luxul XWR-1200
From: Florian Fainelli @ 2017-01-18 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484447368-7622-2-git-send-email-dhaab@luxul.com>
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@luxul.com>
Applied thanks
--
Florian
^ permalink raw reply
* [PATCH 1/2] ARM: BCM5301X: Add DT for Luxul XAP-1410
From: Florian Fainelli @ 2017-01-18 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484447368-7622-1-git-send-email-dhaab@luxul.com>
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@luxul.com>
> ---
Applied, thanks
--
Florian
^ permalink raw reply
* [GIT PULL] bcm2835-dt-next-2017-01-17
From: Florian Fainelli @ 2017-01-18 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117101043.28802-1-eric@anholt.net>
On 01/17/2017 02:10 AM, Eric Anholt wrote:
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> https://github.com/anholt/linux tags/bcm2835-dt-next-2017-01-17
>
> for you to fetch changes up to 38742ca2b8b21bfc2a2cc24278b58485ff781644:
>
> ARM: bcm/dt: Enable the VEC IP on all RaspberryPi boards (2017-01-16 21:50:26 +1100)
>
> ----------------------------------------------------------------
> This pull request brings in the DT changes for VEC (TV-out) on
> Raspberry Pi.
Merged, thanks Eric!
--
Florian
^ permalink raw reply
* [GIT PULL 1/2] Broadcom devicetree changes for 4.11
From: Florian Fainelli @ 2017-01-18 1:29 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.11/devicetree
for you to fetch changes up to d72b156515f60ac1f765fc024e93777e19ef8fda:
Merge tag 'bcm2835-dt-next-2017-01-17' into devicetree/next (2017-01-17 17:10:32 -0800)
----------------------------------------------------------------
This pull request contains Broadcom ARM-based SoC Device Tree changes for 4.11,
please pull the following changes:
- Rafal enables the UART by default on all BCM5301x, BCM4708, BCM4709 since
every device found out there has it enabled by default. He also fixes the
LED definitions for the Luxul XWR-3100 device, enables USB controllers and
their respective PHY devices, specifies the correct GPIO to power on USB
HUBs, adds the additional RAM bank for somes devices, and finally sets the
correct 5Ghz frequency limits on the Netgear R8000
- Jon does a number of Norsthar Plus SoC cleanups, fixes NAND partitions unit
addresses, adds QSPI support to a bunch of boards, adds Ethernet switch ports
to the BCM958625K reference board, enables 3rd Ethernet MAC instance to
relevant DTSes, enables Ethernet on the XMC board, and finally adds SD/MMC
support to the XMC board
- Boris adds the Video Encoder nodes to the Raspberry Pi DTS include files
ands enables it on the relevant boards
- Dan adds support for two new Luxul devices: XAP-1410 and XWR-1200, both
BCM47081 based SoCs
----------------------------------------------------------------
Boris Brezillon (2):
ARM: bcm/dt: Add VEC node in bcm283x.dtsi
ARM: bcm/dt: Enable the VEC IP on all RaspberryPi boards
Dan Haab (2):
ARM: BCM5301X: Add DT for Luxul XAP-1410
ARM: BCM5301X: Add DT for Luxul XWR-1200
Florian Fainelli (1):
Merge tag 'bcm2835-dt-next-2017-01-17' into devicetree/next
Jon Mason (7):
ARM: dts: NSP: DT Clean-ups
ARM: dts: NSP: Correct NAND partition unit address
ARM: dts: NSP: Add QSPI support to missing boards
ARM: dts: NSP: Add BCM958625K switch ports
ARM: dts: NSP: Add and enable amac2
ARM: dts: NSP: Add Ethernet to NSP XMC
ARM: dts: NSP: Add SD/MMC support
Rafa? Mi?ecki (7):
ARM: BCM5301X: Enable UART by default for BCM4708(1), BCM4709(4) & BCM53012
ARM: BCM5301X: Fix LAN LED labels for Luxul XWR-3100
ARM: BCM5301X: Specify USB controllers in DT
ARM: BCM5301X: Set GPIO enabling USB power on Netgear R7000
ARM: BCM5301X: Specify all RAM by including an extra block
ARM: BCM53573: Specify USB ports of on-SoC controllers
ARM: BCM5301X: Set 5 GHz wireless frequency limits on Netgear R8000
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/bcm-nsp.dtsi | 64 +++++----
arch/arm/boot/dts/bcm2835-rpi.dtsi | 5 +
arch/arm/boot/dts/bcm283x.dtsi | 8 ++
arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts | 3 +-
arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts | 3 +-
arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 7 +-
arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts | 4 -
arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts | 4 -
arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 7 +-
arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts | 3 +-
arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 7 +-
arch/arm/boot/dts/bcm4708.dtsi | 4 +
arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts | 3 +-
arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 7 +-
arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts | 3 +-
arch/arm/boot/dts/bcm47081-luxul-xap-1410.dts | 60 ++++++++
arch/arm/boot/dts/bcm47081-luxul-xwr-1200.dts | 107 +++++++++++++++
arch/arm/boot/dts/bcm47081.dtsi | 4 +
arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 3 +-
arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts | 3 +-
arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 11 +-
arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 51 ++++++-
arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts | 4 -
arch/arm/boot/dts/bcm4709.dtsi | 1 +
arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 7 +-
arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 13 +-
arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 7 +-
arch/arm/boot/dts/bcm47094.dtsi | 1 +
arch/arm/boot/dts/bcm5301x.dtsi | 41 +++++-
arch/arm/boot/dts/bcm53573.dtsi | 22 +++
arch/arm/boot/dts/bcm94708.dts | 4 -
arch/arm/boot/dts/bcm94709.dts | 4 -
arch/arm/boot/dts/bcm953012er.dts | 4 -
arch/arm/boot/dts/bcm953012k.dts | 1 -
arch/arm/boot/dts/bcm958522er.dts | 35 ++++-
arch/arm/boot/dts/bcm958525er.dts | 35 ++++-
arch/arm/boot/dts/bcm958525xmc.dts | 68 ++++++++--
arch/arm/boot/dts/bcm958622hr.dts | 42 ++++++
arch/arm/boot/dts/bcm958623hr.dts | 58 ++++++--
arch/arm/boot/dts/bcm958625hr.dts | 72 ++++++++--
arch/arm/boot/dts/bcm958625k.dts | 151 ++++++++++++++++-----
arch/arm/boot/dts/bcm988312hr.dts | 42 ++++++
43 files changed, 813 insertions(+), 172 deletions(-)
create mode 100644 arch/arm/boot/dts/bcm47081-luxul-xap-1410.dts
create mode 100644 arch/arm/boot/dts/bcm47081-luxul-xwr-1200.dts
^ permalink raw reply
* [GIT PULL 2/2] Broadcom devicetree-arm64 changes for 4.11
From: Florian Fainelli @ 2017-01-18 1:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118012931.10964-1-f.fainelli@gmail.com>
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.11/devicetree-arm64
for you to fetch changes up to 096fe8726e5df2975ed29e1ecd881fa54c80878b:
arm64: dts: NS2: add support for XMC form factor (2017-01-03 15:23:22 -0800)
----------------------------------------------------------------
This pull request contains Broadcom ARM64-based SoC Device Tree changes for
4.11, please pull the following changes:
- Jon adds Device Tree nodes for the GICv2m and PAXB/PAXC PCIe interfaces on
the Northstar 2 SoCs, he also enables PAXC on the Northstar 2 SVK reference
board. He also updates the reserved memory entry for the Nitro firmware,
required to get the on-chip NICs to work. Finally he adds support for the
BCM958712DxXMC reference board which is a subset of existing boards.
----------------------------------------------------------------
Jon Mason (4):
arm64: dts: NS2: enable GICv2m for PAXB/PAXC interfaces
arm64: dts: NS2: enable PAXC on NS2 SVK
arm64: dts: NS2: reserve memory for Nitro firmware
arm64: dts: NS2: add support for XMC form factor
arch/arm64/boot/dts/broadcom/Makefile | 2 +-
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 4 +
arch/arm64/boot/dts/broadcom/ns2-xmc.dts | 191 +++++++++++++++++++++++++++++++
arch/arm64/boot/dts/broadcom/ns2.dtsi | 123 ++++++++++++++++----
4 files changed, 295 insertions(+), 25 deletions(-)
create mode 100644 arch/arm64/boot/dts/broadcom/ns2-xmc.dts
^ permalink raw reply
* [GIT PULL 2/2] Broadcom devicetree-arm64 changes for 4.11
From: Florian Fainelli @ 2017-01-18 1:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118012931.10964-2-f.fainelli@gmail.com>
On 01/17/2017 05:29 PM, Florian Fainelli wrote:
> The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
>
> Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
Forgot to mention that, but this is against v4.10-rc2, because v4.10-rc1
just was not building on ARM64, thanks!
>
> are available in the git repository at:
>
> http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.11/devicetree-arm64
>
> for you to fetch changes up to 096fe8726e5df2975ed29e1ecd881fa54c80878b:
>
> arm64: dts: NS2: add support for XMC form factor (2017-01-03 15:23:22 -0800)
>
> ----------------------------------------------------------------
> This pull request contains Broadcom ARM64-based SoC Device Tree changes for
> 4.11, please pull the following changes:
>
> - Jon adds Device Tree nodes for the GICv2m and PAXB/PAXC PCIe interfaces on
> the Northstar 2 SoCs, he also enables PAXC on the Northstar 2 SVK reference
> board. He also updates the reserved memory entry for the Nitro firmware,
> required to get the on-chip NICs to work. Finally he adds support for the
> BCM958712DxXMC reference board which is a subset of existing boards.
>
> ----------------------------------------------------------------
> Jon Mason (4):
> arm64: dts: NS2: enable GICv2m for PAXB/PAXC interfaces
> arm64: dts: NS2: enable PAXC on NS2 SVK
> arm64: dts: NS2: reserve memory for Nitro firmware
> arm64: dts: NS2: add support for XMC form factor
>
> arch/arm64/boot/dts/broadcom/Makefile | 2 +-
> arch/arm64/boot/dts/broadcom/ns2-svk.dts | 4 +
> arch/arm64/boot/dts/broadcom/ns2-xmc.dts | 191 +++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/broadcom/ns2.dtsi | 123 ++++++++++++++++----
> 4 files changed, 295 insertions(+), 25 deletions(-)
> create mode 100644 arch/arm64/boot/dts/broadcom/ns2-xmc.dts
>
--
Florian
^ permalink raw reply
* [PATCH V9 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Hanjun Guo @ 2017-01-18 1:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cc305557e91d2de4ae53daf1f5e8fe5a@codeaurora.org>
On 2017/1/17 23:07, Agustin Vega-Frias wrote:
> Hi Hanjun,
>
> On 2017-01-17 07:47, Hanjun Guo wrote:
>> On 2016/12/15 6:10, Agustin Vega-Frias wrote:
>>> ACPI extended IRQ resources may contain a ResourceSource to specify
>>> an alternate interrupt controller. Introduce acpi_irq_get and use it
>>> to implement ResourceSource/IRQ domain mapping.
>>>
>>> The new API is similar to of_irq_get and allows re-initialization
>>> of a platform resource from the ACPI extended IRQ resource, and
>>> provides proper behavior for probe deferral when the domain is not
>>> yet present when called.
>>>
>>> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
>>> ---
>>> drivers/acpi/Makefile | 2 +-
>>> drivers/acpi/{gsi.c => irq.c} | 182 ++++++++++++++++++++++++++++++++++++++++++
>>> drivers/base/platform.c | 9 ++-
>>> include/linux/acpi.h | 10 +++
>>> 4 files changed, 201 insertions(+), 2 deletions(-)
>>> rename drivers/acpi/{gsi.c => irq.c} (32%)
>>>
>> [...]
>>> +/**
>>> + * acpi_irq_parse_one_cb - Handle the given resource
>>> + * @ares: resource to handle
>>> + * @context: context for the walk, contains the lookup index and references
>>> + * to the flags and fwspec where the result is returned
>>> + *
>>> + * This is called by acpi_walk_resources passing each resource returned by
>>> + * the _CRS method. We only inspect IRQ resources. Since IRQ resources
>>> + * might contain multiple interrupts we check if the index is within this
>>> + * one's interrupt array, otherwise we subtract the current resource IRQ
>>> + * count from the lookup index to prepare for the next resource.
>>> + * Once a match is found we call acpi_irq_parse_one_match to populate
>>> + * the result and end the walk by returning AE_CTRL_TERMINATE.
>>> + *
>>> + * Return AE_OK if the walk should continue, AE_CTRL_TERMINATE if a matching
>>> + * IRQ resource was found.
>>> + */
>>> +static acpi_status acpi_irq_parse_one_cb(struct acpi_resource *ares,
>>> + void *context)
>>> +{
>>> + struct acpi_irq_parse_one_ctx *ctx = context;
>>> + struct acpi_resource_irq *irq;
>>> + struct acpi_resource_extended_irq *eirq;
>>> + struct fwnode_handle *fwnode;
>>> +
>>> + switch (ares->type) {
>>> + case ACPI_RESOURCE_TYPE_IRQ:
>>> + irq = &ares->data.irq;
>>> + if (ctx->index >= irq->interrupt_count) {
>>> + ctx->index -= irq->interrupt_count;
>>> + return AE_OK;
>>> + }
>>> + fwnode = acpi_gsi_domain_id;
>>> + acpi_irq_parse_one_match(fwnode, irq->interrupts[ctx->index],
>>> + irq->triggering, irq->polarity,
>>> + irq->sharable, ctx);
>>> + return AE_CTRL_TERMINATE;
>>> + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
>>> + eirq = &ares->data.extended_irq;
>>
>> If it's an interrupt producer, I think we don't need to map the interrupts in
>> any irqdomain, and return AE_CTRL_TERMINATE here.
>>
>> case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
>> eirq = &ares->data.extended_irq;
>> + if (eirq->producer_consumer == ACPI_PRODUCER)
>> + return AE_CTRL_TERMINATE;
>> if (ctx->index >= eirq->interrupt_count) {
>
> Agreed. I'll add the check. However, we need to return AE_OK, not
> AE_CTRL_TERMINATE, since that terminates the walk and there might
> be other resources to check after this one.
Yes, thanks for the correction, there might be other Interrupt()
resources under _CRS which needs to be scanned.
Thanks
Hanjun
^ permalink raw reply
* [01/26] drm/rockchip: dw-mipi-dsi: use mode from display state
From: Mark yao @ 2017-01-18 2:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587DF431.5040003@rock-chips.com>
On 2017?01?17? 18:38, Chris Zhong wrote:
>> @@ -821,8 +824,6 @@ static void dw_mipi_dsi_encoder_mode_set(struct
>> drm_encoder *encoder,
>> struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
>> int ret;
>> - dsi->mode = adjusted_mode;
>> -
> I prefer to keep the original method, although this"dsi->mode" pointer
> is same as "&dsi->connector.state->crtc->state->adjusted_mode; "
> I still think dsi->mode makes the process easier to read
"&dsi->connector.state->crtc->state->adjusted_mode;" is too long, and
dsi->connector.state->crtc can be NULL, seems not good.
agree with Chris, I think dsi->mode is better.
Bug the origin code "dsi->mode = adjusted_mode; " also has a bug,
adjusted_mode's lift time is unknown, use a pointer from adjusted_mode
is dangerous.
I think we can use like that, copy a display mode to dsi->mode:
struct dw_mipi_dsi
{
- struct drm_display_mode *mode;
+ struct drm_display_mode mode;
}
xxx_encoder_mode_set()
{
drm_mode_copy(&dsi->mode, adjusted_mode);
}
--
?ark Yao
^ permalink raw reply
* [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: 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
* [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: 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 at 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 at 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 at 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
* [PATCH v4 2/4] Documentation: dt: add bindings for ti-cpufreq
From: Viresh Kumar @ 2017-01-18 3:16 UTC (permalink / raw)
To: 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
* [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: linux-arm-kernel
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
* [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: linux-arm-kernel
In-Reply-To: <20170117131808.29798-5-d-gerlach@ti.com>
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@ti.com>
> ---
> 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@linaro.org>
--
viresh
^ permalink raw reply
* [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: 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
* [PATCH] clk: rockchip: fix the incorrect pclk_edp div width for RK3399
From: Xing Zheng @ 2017-01-18 4:20 UTC (permalink / raw)
To: linux-arm-kernel
The range of the pclk_edp_div_con is [13:8] and 6 bits, not 5.
Reported-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
---
drivers/clk/rockchip/clk-rk3399.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c
index 3490887..73121b14 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -1132,7 +1132,7 @@ static struct rockchip_clk_branch rk3399_clk_branches[] __initdata = {
RK3399_CLKGATE_CON(11), 8, GFLAGS),
COMPOSITE(PCLK_EDP, "pclk_edp", mux_pll_src_cpll_gpll_p, 0,
- RK3399_CLKSEL_CON(44), 15, 1, MFLAGS, 8, 5, DFLAGS,
+ RK3399_CLKSEL_CON(44), 15, 1, MFLAGS, 8, 6, DFLAGS,
RK3399_CLKGATE_CON(11), 11, GFLAGS),
GATE(PCLK_EDP_NOC, "pclk_edp_noc", "pclk_edp", CLK_IGNORE_UNUSED,
RK3399_CLKGATE_CON(32), 12, GFLAGS),
--
2.7.4
^ permalink raw reply related
* [PATCH] clk: rockchip: fix the incorrect pclk_edp div width for RK3399
From: hl @ 2017-01-18 4:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484713256-3005-1-git-send-email-zhengxing@rock-chips.com>
Tested-by: Lin Huang <hl@rock-chips.com>
On 2017?01?18? 12:20, Xing Zheng wrote:
> The range of the pclk_edp_div_con is [13:8] and 6 bits, not 5.
>
> Reported-by: Lin Huang <hl@rock-chips.com>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> drivers/clk/rockchip/clk-rk3399.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c
> index 3490887..73121b14 100644
> --- a/drivers/clk/rockchip/clk-rk3399.c
> +++ b/drivers/clk/rockchip/clk-rk3399.c
> @@ -1132,7 +1132,7 @@ static struct rockchip_clk_branch rk3399_clk_branches[] __initdata = {
> RK3399_CLKGATE_CON(11), 8, GFLAGS),
>
> COMPOSITE(PCLK_EDP, "pclk_edp", mux_pll_src_cpll_gpll_p, 0,
> - RK3399_CLKSEL_CON(44), 15, 1, MFLAGS, 8, 5, DFLAGS,
> + RK3399_CLKSEL_CON(44), 15, 1, MFLAGS, 8, 6, DFLAGS,
> RK3399_CLKGATE_CON(11), 11, GFLAGS),
> GATE(PCLK_EDP_NOC, "pclk_edp_noc", "pclk_edp", CLK_IGNORE_UNUSED,
> RK3399_CLKGATE_CON(32), 12, GFLAGS),
--
Lin Huang
^ permalink raw reply
* [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: linux-arm-kernel
In-Reply-To: <9f45a921-ebfb-c252-20bb-3a7adf508343@samsung.com>
Hello Pankaj,
On Wed, Jan 18, 2017 at 12:16 AM, pankaj.dubey <pankaj.dubey@samsung.com> wrote:
> On Tuesday 17 January 2017 11:53 PM, Krzysztof Kozlowski wrote:
[snip]
>>> +
>>> + dwc3 {
>>
>> dtc should complain here - you need:
>> dwc3 at 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
^ permalink raw reply
* [PATCH v19 06/15] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.
From: Fu Wei @ 2017-01-18 4:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116175025.GJ5908@leverpostej>
Hi Mark,
On 17 January 2017 at 01:50, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Dec 21, 2016 at 02:45:54PM +0800, fu.wei at linaro.org wrote:
>> From: Fu Wei <fu.wei@linaro.org>
>>
>> Currently, the counter frequency detection call(arch_timer_detect_rate)
>> combines all the ways to get counter frequency: device-tree property,
>> system coprocessor register, MMIO timer. But in the most of use cases,
>> we don't need all the ways to try:
>> For example, reading device-tree property will be needed only when
>> system boot with device-tree, getting frequency from MMIO timer register
>> will beneeded only when we init MMIO timer.
>>
>> This patch separates paths to determine frequency:
>> Separate out device-tree code, keep them in device-tree init function.
>
> Splitting these out makes sense to me.
OK , will do
>
>> Separate out the MMIO frequency and the sysreg frequency detection call,
>> and use the appropriate one for the counter.
>
>> Signed-off-by: Fu Wei <fu.wei@linaro.org>
>> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
>> ---
>> drivers/clocksource/arm_arch_timer.c | 49 +++++++++++++++++++++++-------------
>> 1 file changed, 31 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index c7b4482..9a1f138 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -488,27 +488,31 @@ static int arch_timer_starting_cpu(unsigned int cpu)
>> return 0;
>> }
>>
>> -static void
>> -arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)
>> +static void arch_timer_detect_rate(void)
>> {
>> - /* Who has more than one independent system counter? */
>> - if (arch_timer_rate)
>> - return;
>> + /*
>> + * Try to get the timer frequency from
>> + * cntfrq_el0(system coprocessor register).
>> + */
>> + if (!arch_timer_rate)
>> + arch_timer_rate = arch_timer_get_cntfrq();
>> +
>> + /* Check the timer frequency. */
>> + if (!arch_timer_rate)
>> + pr_warn("frequency not available\n");
>> +}
>>
>> +static void arch_timer_mem_detect_rate(void __iomem *cntbase)
>> +{
>> /*
>> - * Try to determine the frequency from the device tree or CNTFRQ,
>> - * if ACPI is enabled, get the frequency from CNTFRQ ONLY.
>> + * Try to determine the frequency from
>> + * CNTFRQ in memory-mapped timer.
>> */
>> - if (!acpi_disabled ||
>> - of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
>> - if (cntbase)
>> - arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
>> - else
>> - arch_timer_rate = arch_timer_get_cntfrq();
>> - }
>> + if (!arch_timer_rate)
>> + arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
>>
>> /* Check the timer frequency. */
>> - if (arch_timer_rate == 0)
>> + if (!arch_timer_rate)
I think you mean this one, this is for keeping consistency with
arch_timer_detect_rate.
>> pr_warn("frequency not available\n");
>> }
>
> There's a subtle change in behaviour here. Previously for ACPI we'd only
> ever use the sysreg CNTFRQ value for arch_timer_rate, whereas now we
> might use the MMIO timer rate. Maybe that's not a big deal, but I will
> need to think.
>
> Generally, the logic to determine the rate is fairly gnarly regardless.
>
> It would be nice if we could split the MMIO and sysreg rates entirely,
Yes, I am doing this way,
For sysreg rates,
static void arch_timer_detect_rate(void)
{
/*
* Try to get the timer frequency from
* cntfrq_el0(system coprocessor register).
*/
if (!arch_timer_rate)
arch_timer_rate = arch_timer_get_cntfrq();
/* Check the timer frequency. */
if (!arch_timer_rate)
pr_warn("frequency not available\n");
}
For MMIO timer,
static void arch_timer_mem_detect_rate(void __iomem *cntbase)
{
/*
* Try to determine the frequency from
* CNTFRQ in memory-mapped timer.
*/
if (!arch_timer_rate)
arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
/* Check the timer frequency. */
if (!arch_timer_rate)
pr_warn("frequency not available\n");
}
in arch_time_*_init, only call arch_timer_detect_rate,
in arch_timer_mem_init, only call arch_timer_mem_detect_rate.
But you are right, this is fairly gnarly regardless.
> and kill the implicit relationship between the two, or at least make one
> canonical and warn if the two differ.
So I think maybe we can do this:
static void __arch_timer_determine_rate(u32 rate)
{
/* Check the timer frequency. */
if (!arch_timer_rate)
if (rate)
arch_timer_rate = rate;
else
pr_warn("frequency not available\n");
else if (arch_timer_rate != rate)
pr_warn("got different frequency, keep original.\n");
}
static void arch_timer_detect_rate(void)
{
/*
* Try to get the timer frequency from
* cntfrq_el0(system coprocessor register).
*/
__arch_timer_determine_rate(arch_timer_get_cntfrq());
}
static void arch_timer_mem_detect_rate(void __iomem *cntbase)
{
/*
* Try to get the timer frequency from
* CNTFRQ in the MMIO timer.
*/
__arch_timer_determine_rate(readl_relaxed(cntbase + CNTFRQ));
}
any thought?
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ 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: 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 at 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: 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: linux-arm-kernel
In-Reply-To: <1484714522-26651-1-git-send-email-baoyou.xie@linaro.org>
This patch adds thermal driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.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@linaro.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@linaro.org>");
+MODULE_DESCRIPTION("ZTE zx2967 thermal driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/2] power/reset: at91-reset: add samx7 support
From: Sebastian Reichel @ 2017-01-18 4:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117230738.28257-1-alexandre.belloni@free-electrons.com>
Hi Alexandre,
On Wed, Jan 18, 2017 at 12:07:37AM +0100, Alexandre Belloni wrote:
> From: Szemz? Andr?s <sza@esh.hu>
>
> Add samx7 support. It is lacking a few bits and needs a new reset function.
>
> Signed-off-by: Szemz? Andr?s <sza@esh.hu>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> drivers/power/reset/at91-reset.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c
> index 568580cf0655..bb2588f0a4c7 100644
> --- a/drivers/power/reset/at91-reset.c
> +++ b/drivers/power/reset/at91-reset.c
> @@ -134,6 +134,15 @@ static int sama5d3_restart(struct notifier_block *this, unsigned long mode,
> return NOTIFY_DONE;
> }
>
> +static int samx7_restart(struct notifier_block *this, unsigned long mode,
> + void *cmd)
> +{
> + writel(cpu_to_le32(AT91_RSTC_KEY | AT91_RSTC_PROCRST),
> + at91_rstc_base);
> +
> + return NOTIFY_DONE;
> +}
> +
> static void __init at91_reset_status(struct platform_device *pdev)
> {
> u32 reg = readl(at91_rstc_base + AT91_RSTC_SR);
> @@ -173,6 +182,7 @@ static const struct of_device_id at91_reset_of_match[] = {
> { .compatible = "atmel,at91sam9260-rstc", .data = at91sam9260_restart },
> { .compatible = "atmel,at91sam9g45-rstc", .data = at91sam9g45_restart },
> { .compatible = "atmel,sama5d3-rstc", .data = sama5d3_restart },
> + { .compatible = "atmel,samx7-rstc", .data = samx7_restart },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, at91_reset_of_match);
Thanks, queued into power-supply's for-next branch.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170118/c0c70438/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/2] power/reset: at91-reset: remove leftover platform_device_id
From: Sebastian Reichel @ 2017-01-18 4:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117230738.28257-2-alexandre.belloni@free-electrons.com>
Hi Alexandre,
On Wed, Jan 18, 2017 at 12:07:38AM +0100, Alexandre Belloni wrote:
> commit eacd8d09db7f ("power/reset: at91-reset: remove useless
> at91_reset_platform_probe()") removed non DT probe support but forgot to
> remove the now useless id_table. Do that now.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> drivers/power/reset/at91-reset.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c
> index bb2588f0a4c7..b99769f8ab15 100644
> --- a/drivers/power/reset/at91-reset.c
> +++ b/drivers/power/reset/at91-reset.c
> @@ -248,20 +248,12 @@ static int __exit at91_reset_remove(struct platform_device *pdev)
> return 0;
> }
>
> -static const struct platform_device_id at91_reset_plat_match[] = {
> - { "at91-sam9260-reset", (unsigned long)at91sam9260_restart },
> - { "at91-sam9g45-reset", (unsigned long)at91sam9g45_restart },
> - { /* sentinel */ }
> -};
> -MODULE_DEVICE_TABLE(platform, at91_reset_plat_match);
> -
> static struct platform_driver at91_reset_driver = {
> .remove = __exit_p(at91_reset_remove),
> .driver = {
> .name = "at91-reset",
> .of_match_table = at91_reset_of_match,
> },
> - .id_table = at91_reset_plat_match,
> };
> module_platform_driver_probe(at91_reset_driver, at91_reset_probe);
Thanks, also queued into power-supply's for-next branch.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170118/baf17805/attachment.sig>
^ permalink raw reply
* odroid xu4:pinctrl and gpio mapping for usb 3.0
From: Anand Moon @ 2017-01-18 5:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi All,
I tried to find the link between pinctrl and internal gpio for usb 3.0 ports
from the schematics, but I could not find valuable input.
I tired to map the internal gpio pins to gather information on
id-gpio and vbus-gpio pins, but it was no luck.
I tried to debug the phy-exynos5-usbdrd.c and the vbus regulator
input is missing, but with no correct input on internal gpio and pinctrl
so it hard to map this correctly.
Is their some thing missing configuration.
Their are some issues into the phy-exynos5-usbdrd.c
with respect to exynos5_usbdrd_phy_exit not getting called
on the warm boot which leads to usb ports not getting reset.
Please share me some input on improve the power on usb 3.0 ports
odroid at odroidxu4n:~$ lsusb -t
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 480M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
|__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
|__ Port 2: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 2: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
root at odroidxu4n:~# lsusb -v|egrep "^Bus|MaxPower"
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
MaxPower 0mA
Bus 005 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.
MaxPower 180mA
MaxPower 180mA
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MaxPower 0mA
Bus 004 Device 003: ID 174c:5106 ASMedia Technology Inc. ASM1051 SATA
3Gb/s bridge
MaxPower 0mA
Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. hub
MaxPower 0mA
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
MaxPower 0mA
Bus 003 Device 004: ID 04b4:00f8 Cypress Semiconductor Corp.
MaxPower 500mA
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
MaxPower 100mA
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MaxPower 0mA
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MaxPower 0mA
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MaxPower 0mA
-Best Regards
Anand Moon
^ permalink raw reply
* [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: linux-arm-kernel
In-Reply-To: <68177964-890d-7061-dac0-f37717b1a254@samsung.com>
On Wed, Jan 18, 2017 at 5:20 AM, pankaj.dubey <pankaj.dubey@samsung.com> 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@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.
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
^ 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