Re: [PATCH 0/6] ARM: DTS: da850: eDMA new bindings and MMC/SPI DMA support
On Wednesday 09 December 2015 12:49 PM, Peter Ujfalusi wrote: > Sekhar, > > On 12/04/2015 03:53 PM, Peter Ujfalusi wrote: >> Hi, >> >> Switch to use the new eDMA bindings and enable DMA for MMC0, SPI1. >> Add node for MMC1. > > Can you hold on this one for a bit since the eDMA bindings might change still. Sure, no problem! Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] ARM: DTS: da850: eDMA new bindings and MMC/SPI DMA support
Sekhar, On 12/04/2015 03:53 PM, Peter Ujfalusi wrote: > Hi, > > Switch to use the new eDMA bindings and enable DMA for MMC0, SPI1. > Add node for MMC1. Can you hold on this one for a bit since the eDMA bindings might change still. > > Regards, > Peter > --- > Peter Ujfalusi (6): > ARM: DTS: da850: fix edma0 reg space > ARM: DTS: da850: Use the new DT bindings for the eDMA3 > ARM: DTS: da850: Enable eDMA1 > ARM: DTS: da850: Enable DMA use for MMC0 > ARM: DTS: da850: Add node for mmc1 > ARM: DTS: da850: Enable DMA for SPI1 > > arch/arm/boot/dts/da850-enbw-cmc.dts | 9 ++ > arch/arm/boot/dts/da850-evm.dts | 9 ++ > arch/arm/boot/dts/da850.dtsi | 59 > > 3 files changed, 71 insertions(+), 6 deletions(-) > -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/5] dt-bindings: iommu: Add binding for mediatek IOMMU
also add Mark. On Tue, 2015-12-08 at 21:33 -0600, Rob Herring wrote: > On Tue, Dec 08, 2015 at 05:49:09PM +0800, Yong Wu wrote: > > This patch add mediatek iommu dts binding document. > > > > Signed-off-by: Yong Wu > > --- > > .../devicetree/bindings/iommu/mediatek,iommu.txt | 68 + > > include/dt-bindings/memory/mt8173-larb-port.h | 111 > > + > > This should be iommu rather than memory. Hi Rob, Thanks very much for review. From the HW, all the larbs and ports are defined in the SMI. About the position of the SMI code, We also discussed before in [1]. So I put the header file in /dt-bindings/memory/. This is a smi larb-port header file, maybe we should move this header file into this patch: [2/5] dt-bindings: mediatek: Add smi dts binding is it ok if we move it into [2/5]? [1] http://lists.infradead.org/pipermail/linux-mediatek/2015-March/000121.html > > Otherwise, it looks okay to me. Thanks. > > > 2 files changed, 179 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/iommu/mediatek,iommu.txt > > create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] bus: uniphier-system-bus: add UniPhier System Bus driver
The UniPhier System Bus is an external bus that connects on-board
devices to the UniPhier SoC. Each bank (chip select) is dynamically
mapped to the CPU-viewed address base via the bus controller. The
bus controller must be configured before any access to the bus.
This driver parses the "ranges" property of the System Bus node and
initialized the bus controller. After the bus becomes ready, devices
below it are populated.
Note:
Each bank can be mapped anywhere in the supported address space;
there is nothing preventing us from assigning bank 0 on 0x4200,
0x4300, or anywhere as long as such region is not used by others.
So, the "ranges" is just one possible software configuration, which
does not seem to fit in device tree because device tree is a hardware
description language. However, of_translate_address() requires
"ranges" in every bus node between CPUs and device mapped on the CPU
address space. In other words, "ranges" properties must be statically
defined in device tree. After some discussion, I decided the dynamic
address reassignment by the driver is too bothersome. Instead, the
device tree should provide a reasonable translation setup that the OS
can rely on.
Signed-off-by: Masahiro Yamada
Acked-by: Rob Herring
Acked-by: Arnd Bergmann
---
Changes in v5:
- Fix the conflict in MAINTAINERS
Changes in v4:
- Simplify uniphier_system_bus_check_overlap() function
by not using the sort library
- Add some comments to uniphier_system_bus_check_boot_swap()
for clarification
- Add Arnd's Acked-by
Changes in v3:
- Minor fix of git-log
- Add Rob's Acked-by
Changes in v2:
- Re-design the binding, driver implementation
Switch to a single node, populate children after the bus is setup
.../bindings/bus/uniphier-system-bus.txt | 66 +
MAINTAINERS| 1 +
drivers/bus/Kconfig| 8 +
drivers/bus/Makefile | 1 +
drivers/bus/uniphier-system-bus.c | 281 +
5 files changed, 357 insertions(+)
create mode 100644
Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
create mode 100644 drivers/bus/uniphier-system-bus.c
diff --git a/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
new file mode 100644
index 000..68ef80a
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
@@ -0,0 +1,66 @@
+UniPhier System Bus
+
+The UniPhier System Bus is an external bus that connects on-board devices to
+the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and
+some control signals. It supports up to 8 banks (chip selects).
+
+Before any access to the bus, the bus controller must be configured; the bus
+controller registers provide the control for the translation from the offset
+within each bank to the CPU-viewed address. The needed setup includes the base
+address, the size of each bank. Optionally, some timing parameters can be
+optimized for faster bus access.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-bus".
+- reg: offset and length of the register set for the bus controller device.
+- #address-cells: should be 2. The first cell is the bank number (chip
select).
+ The second cell is the address offset within the bank.
+- #size-cells: should be 1.
+- ranges: should provide a proper address translation from the System Bus to
+ the parent bus.
+
+Note:
+The address region(s) that can be assigned for the System Bus is implementation
+defined. Some SoCs can use 0x-0x0fff and 0x4000-0x4fff,
+while other SoCs can only use 0x4000-0x4fff. There might be additional
+limitations depending on SoCs and the boot mode. The address translation is
+arbitrary as long as the banks are assigned in the supported address space with
+the required alignment and they do not overlap one another.
+For example, it is possible to map:
+ bank 0 to 0x4200-0x43ff, bank 5 to 0x4600-0x46ff
+It is also possible to map:
+ bank 0 to 0x4800-0x49ff, bank 5 to 0x4400-0x44ff
+There is no reason to stick to a particular translation mapping, but the
+"ranges" property should provide a "reasonable" default that is known to work.
+The software should initialize the bus controller according to it.
+
+Example:
+
+ system-bus {
+ compatible = "socionext,uniphier-system-bus";
+ reg = <0x58c0 0x400>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <1 0x 0x4200 0x0200
+ 5 0x 0x4600 0x0100>;
+
+ ethernet@1,01f0 {
+ compatible = "smsc,lan9115";
+ reg = <1 0x01f0 0x1000>;
+ interrupts = <0 48 4>
+
Re: [PATCH 1/2] usb: renesas_usbhs: add fallback compatibility string
On Wed, Dec 09, 2015 at 06:29:07AM +, Kuninori Morimoto wrote: > > Hi Simon > > > > > (As Sergei noted elsewhere, "renesas,rcar-usbhs" is consistent > > > > with what I documented elsewhere in the patch) > > > > > > "renesas,rcar-usbhs" is better, > > > but I guess you want to have "renesas,rcar-gen2-usbhs" ? > > > > > > My understanding is these > > > > > > * renesas,usbhs-r8a77xx # SoC specific > > > * renesas,rcar-usbhs # R-Car common > > > * renesas,rcar-gen2-usbhs# R-Car Gen2 common > > > * renesas,rcar-gen3-usbhs# R-Car Gen3 common > > > * renesas,usbhs # Renesas USBHS common > > > > > > > I was intentionally including gen3 as well. So I think we have two options: > > > > 1. renesas,rcar-usbhs > > 2. renesas,rcar-gen2-usbhs and renesas,rcar-gen3-usbhs > > Renesas USB always have pick feature/settings. > Thus, generic name (= "renesas,rcar-usbhs") is very risky IMO. > I think 2 is more safety. Sure, better safe than sorry. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: renesas_usbhs: add fallback compatibility string
Hi Simon > > > (As Sergei noted elsewhere, "renesas,rcar-usbhs" is consistent > > > with what I documented elsewhere in the patch) > > > > "renesas,rcar-usbhs" is better, > > but I guess you want to have "renesas,rcar-gen2-usbhs" ? > > > > My understanding is these > > > > * renesas,usbhs-r8a77xx# SoC specific > > * renesas,rcar-usbhs # R-Car common > > * renesas,rcar-gen2-usbhs # R-Car Gen2 common > > * renesas,rcar-gen3-usbhs # R-Car Gen3 common > > * renesas,usbhs# Renesas USBHS common > > > > I was intentionally including gen3 as well. So I think we have two options: > > 1. renesas,rcar-usbhs > 2. renesas,rcar-gen2-usbhs and renesas,rcar-gen3-usbhs Renesas USB always have pick feature/settings. Thus, generic name (= "renesas,rcar-usbhs") is very risky IMO. I think 2 is more safety. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi][PATCH 2/2] ARM: dts: sun4i: Add rikomagic mk802+ board
> > Are there any differences between the Rikomagic and the generic MK802? Hi Julian, In the covering letter I mention this https://groups.google.com/d/msg/linux-sunxi/Az9Dy6tPfqQ/ZMYwKWznAAAJ and also that we could always use the original mk802 dts for the differences. BR, CK > > You could just add another compatible to the original MK802 dts if there > aren't. > > Thanks, > > -- > Julian Calaby > > Email: julian.cal...@gmail.com > Profile: http://www.google.com/profiles/julian.calaby/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10.2 14/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"force-hpd" to indicate this sutiation.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Tested-by: Javier Martinez Canillas
---
Changes in v10.2:
- Add the ack from Rob Herring
- Fix the omissive "analogix,need-force-hpd" in Exynos DP document
Changes in v10.1:
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
hpd when hpd detect failed.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 4 ++-
.../bindings/display/exynos/exynos_dp.txt | 1 +
.../display/rockchip/analogix_dp-rockchip.txt | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++
6 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..4f2ba8c 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
Optional properties for dp-controller:
+ -force-hpd:
+ Indicate driver need force hpd when hpd detect failed, this
+ is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
*
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
-
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
---
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 9905081..8800164 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+ -force-hpd (optional)
-video interfaces (optional)
Deprecated properties for DisplayPort:
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index dae86c4..187a708e 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP binding
document:
- phys (required)
- phy-names (required)
- hpd-gpios (optional)
+- force-hpd (optional)
---
Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a11504b..00aee44 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
{
int timeout_loop = 0;
- while (analogix_dp_get_plug_in_status(dp) != 0) {
+ while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+ if (analogix_dp_get_plug_in_status(dp) == 0)
+ return 0;
+
timeout_loop++;
- if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "failed to get hpd plug status\n");
- return -ETIMEDOUT;
- }
usleep_range(10, 11);
}
+ /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+ if (!dp->force_hpd)
+ return -ETIMEDOUT;
+
+ /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+ dev_dbg(dp->dev, "failed to get hpd plug statu
Re: [PATCH v10.1 14/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
Hi Rob,
On 12/09/2015 12:25 PM, Rob Herring wrote:
On Wed, Dec 09, 2015 at 10:10:39AM +0800, Yakir Yang wrote:
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
Acked-by: Rob Herring
Thanks,
---
Changes in v10.1:
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
hpd when hpd detect failed.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 4 ++-
.../bindings/display/exynos/exynos_dp.txt | 1 +
.../display/rockchip/analogix_dp-rockchip.txt | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++
6 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..4f2ba8c 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
Optional properties for dp-controller:
+ -force-hpd:
+ Indicate driver need force hpd when hpd detect failed, this
+ is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
*
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
-
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
---
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 9905081..8800164 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+ -analogix,need-force-hpd (optional)
Forget about this one, will send the new version to fix this, and carry
your ack.
- Yakir
-video interfaces (optional)
Deprecated properties for DisplayPort:
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index dae86c4..187a708e 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP binding
document:
- phys (required)
- phy-names (required)
- hpd-gpios (optional)
+- force-hpd (optional)
---
Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a11504b..00aee44 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
{
int timeout_loop = 0;
- while (analogix_dp_get_plug_in_status(dp) != 0) {
+ while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+ if (analogix_dp_get_plug_in_status(dp) == 0)
+ return 0;
+
timeout_loop++;
- if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "failed to get hpd plug status\n");
- return -ETIMEDOUT;
- }
usleep_range(10, 11);
}
+ /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+ if (!dp->force_hpd)
+ return -ETIMEDOUT;
+
+ /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+
Re: [PATCH 1/2] usb: renesas_usbhs: add fallback compatibility string
On Wed, Dec 09, 2015 at 04:48:47AM +, Kuninori Morimoto wrote: > > Hi Simon > > > (As Sergei noted elsewhere, "renesas,rcar-usbhs" is consistent > > with what I documented elsewhere in the patch) > > "renesas,rcar-usbhs" is better, > but I guess you want to have "renesas,rcar-gen2-usbhs" ? > > My understanding is these > > * renesas,usbhs-r8a77xx # SoC specific > * renesas,rcar-usbhs # R-Car common > * renesas,rcar-gen2-usbhs# R-Car Gen2 common > * renesas,rcar-gen3-usbhs# R-Car Gen3 common > * renesas,usbhs # Renesas USBHS common > I was intentionally including gen3 as well. So I think we have two options: 1. renesas,rcar-usbhs 2. renesas,rcar-gen2-usbhs and renesas,rcar-gen3-usbhs Which do you prefer? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: renesas_usbhs: add fallback compatibility string
Hi Simon > (As Sergei noted elsewhere, "renesas,rcar-usbhs" is consistent > with what I documented elsewhere in the patch) "renesas,rcar-usbhs" is better, but I guess you want to have "renesas,rcar-gen2-usbhs" ? My understanding is these * renesas,usbhs-r8a77xx# SoC specific * renesas,rcar-usbhs # R-Car common * renesas,rcar-gen2-usbhs # R-Car Gen2 common * renesas,rcar-gen3-usbhs # R-Car Gen3 common * renesas,usbhs# Renesas USBHS common -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/5] PCI: designware: add memory barrier after enabling region
On Tue, Dec 8, 2015 at 2:31 PM, Stanimir Varbanov wrote: > > On 12/03/2015 03:35 PM, Stanimir Varbanov wrote: > > Add 'write memory' barrier after enable region in PCIE_ATU_CR2 > > register. The barrier is needed to ensure that the region enable > > request has been reached it's destination at time when we > > read/write to PCI configuration space. > > > > Without this barrier PCI device enumeration during kernel boot > > is not reliable, and reading configuration space for particular > > PCI device on the bus returns zero aka no device. > > Anand, Jingoo, what is your opinion? > > > > > Signed-off-by: Stanimir Varbanov > > --- > > drivers/pci/host/pcie-designware.c |5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/pci/host/pcie-designware.c > > b/drivers/pci/host/pcie-designware.c > > index 02a7452bdf23..ed4dc2e2553b 100644 > > --- a/drivers/pci/host/pcie-designware.c > > +++ b/drivers/pci/host/pcie-designware.c > > @@ -164,6 +164,11 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port > > *pp, int index, > > dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET); > > dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1); > > dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2); > > + /* > > + * ensure that the ATU enable has been happaned before accessing > > + * pci configuration/io spaces through dw_pcie_cfg_[read|write]. > > + */ > > + wmb(); > > } > > My understnading is that since writel() of dw_pcie_writel_rc() in above code and readl(), writel() of dw_pcie_cfg_[read|write]() (which will follow) goes through same device (ie PCIe host here). So, it is guaranteed that 1st writel() will be executed before later readl()/writel(). If that is true then we do not need any explicit barrier here. Arnd, Russel: whats your opinion here. ~Pratyush -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10.1 14/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
On Wed, Dec 09, 2015 at 10:10:39AM +0800, Yakir Yang wrote:
> Some edp screen do not have hpd signal, so we can't just return
> failed when hpd plug in detect failed.
>
> This is an hardware property, so we need add a devicetree property
> "analogix,need-force-hpd" to indicate this sutiation.
>
> Signed-off-by: Yakir Yang
> Tested-by: Javier Martinez Canillas
Acked-by: Rob Herring
> ---
> Changes in v10.1:
> - Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
>
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Add "analogix,need-force-hpd" to indicate whether driver need foce
> hpd when hpd detect failed.
>
> Changes in v2: None
>
> .../bindings/display/bridge/analogix_dp.txt| 4 ++-
> .../bindings/display/exynos/exynos_dp.txt | 1 +
> .../display/rockchip/analogix_dp-rockchip.txt | 1 +
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35
> ++
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++
> 6 files changed, 46 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> index 7659a7a..4f2ba8c 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> @@ -22,6 +22,9 @@ Required properties for dp-controller:
> from general PHY binding: Should be "dp".
>
> Optional properties for dp-controller:
> + -force-hpd:
> + Indicate driver need force hpd when hpd detect failed, this
> + is used for some eDP screen which don't have hpd signal.
> -hpd-gpios:
> Hotplug detect GPIO.
> Indicates which GPIO should be used for hotplug detection
> @@ -31,7 +34,6 @@ Optional properties for dp-controller:
> * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> *
> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
>
> -
> [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>
> ---
>
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 9905081..8800164 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP
> binding document:
> -phys (required)
> -phy-names (required)
> -hpd-gpios (optional)
> + -analogix,need-force-hpd (optional)
> -video interfaces (optional)
>
> Deprecated properties for DisplayPort:
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> index dae86c4..187a708e 100644
> ---
> a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> +++
> b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
> @@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP
> binding document:
> - phys (required)
> - phy-names (required)
> - hpd-gpios (optional)
> +- force-hpd (optional)
>
> ---
>
> Example:
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index a11504b..00aee44 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct
> analogix_dp_device *dp)
> {
> int timeout_loop = 0;
>
> - while (analogix_dp_get_plug_in_status(dp) != 0) {
> + while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
> + if (analogix_dp_get_plug_in_status(dp) == 0)
> + return 0;
> +
> timeout_loop++;
> - if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
> - dev_err(dp->dev, "failed to get hpd plug status\n");
> - return -ETIMEDOUT;
> - }
> usleep_range(10, 11);
> }
>
> + /*
> + * Some edp screen do not have hpd signal, so we can't just
> + * return failed when hpd plug in detect failed, DT property
> + * "need-force-hpd" would indicate whether driver need this.
> + */
> + if (!dp->force_hpd)
> + return -ETIMEDOUT;
> +
> + /*
> + * The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
> + * will n
Re: [RFC PATCH 01/15] PM / devfreq: exynos: Add generic exynos bus frequency driver
Hi Chanwoo, On 9 December 2015 at 09:41, Chanwoo Choi wrote: > Hi Anand, > > On 2015년 11월 27일 09:34, Chanwoo Choi wrote: >> Hi Anand, >> >> On 2015년 11월 27일 02:17, Anand Moon wrote: >>> Hi Chanwoo, >>> >>> On 26 November 2015 at 21:42, Chanwoo Choi wrote: On Thu, Nov 26, 2015 at 11:00 PM, MyungJoo Ham wrote: > On Thu, Nov 26, 2015 at 10:47 PM, Chanwoo Choi > wrote: >> This patch adds the generic exynos bus frequency driver for AMBA AXI bus >> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos >> SoC >> have the common architecture for bus between DRAM and sub-blocks in SoC. >> This driver can support the generic bus frequency driver for Exynos SoCs. >> >> In devicetree, Each bus block has a bus clock, regulator, operation-point >> and devfreq-event devices which measure the utilization of each bus >> block. >> >> Signed-off-by: Chanwoo Choi >> --- >> drivers/devfreq/Kconfig | 15 ++ >> drivers/devfreq/Makefile| 1 + >> drivers/devfreq/exynos/Makefile | 1 + >> drivers/devfreq/exynos/exynos-bus.c | 443 >> >> 4 files changed, 460 insertions(+) >> create mode 100644 drivers/devfreq/exynos/exynos-bus.c >> > > Are we finally getting a common Exynos bus driver with full DT support? > (can this replace both Exynos4/5 drivers and support Exynos7 series?) Yes. This patch-set would support all Exynos SoCs for bus frequency driver. To make sure the support for Exynos7 series, I need to check the TRM document of Exynos7. I think it is possible for support Exynos7. I'm going to test this driver on various Exynos-based board. Regards, Chanwoo Choi >>> >>> Please do consider Exynos 542x series as well. >> >> Sure. I'll to test it on Exynos5422-based Odroid-XU3. > > I send the v2 patchset but this patchset don't include > the support of Odroid-XU3 because of only Exynos542x has the > special addtional sequence to change the source clock > of DRAM. So, I'm going to support the bus frequency on Exynos542x. > After completing it, I'll send the separate patches. > > Thanks, > Chanwoo Choi > Not an issue. Thanks for the update. -Anand Moon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/19] PM / devfreq: Add devfreq_get_devfreq_by_phandle()
This patch adds the new devfreq_get_devfreq_by_phandle() OF helper function
which can find the instance of devfreq device by using phandle ("devfreq").
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/devfreq.c | 44
include/linux/devfreq.h | 9 +
2 files changed, 53 insertions(+)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 15e58779e4c0..78ea4cdaa82c 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "governor.h"
static struct class *devfreq_class;
@@ -686,6 +687,49 @@ struct devfreq *devm_devfreq_add_device(struct device *dev,
}
EXPORT_SYMBOL(devm_devfreq_add_device);
+#ifdef CONFIG_OF
+/*
+ * devfreq_get_devfreq_by_phandle - Get the devfreq device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of devfreq
+ *
+ * return the instance of devfreq device
+ */
+struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
+{
+ struct device_node *node;
+ struct devfreq *devfreq;
+
+ if (!dev)
+ return ERR_PTR(-EINVAL);
+
+ if (!dev->of_node)
+ return ERR_PTR(-EINVAL);
+
+ node = of_parse_phandle(dev->of_node, "devfreq", index);
+ if (!node)
+ return ERR_PTR(-ENODEV);
+
+ mutex_lock(&devfreq_list_lock);
+ list_for_each_entry(devfreq, &devfreq_list, node) {
+ if (devfreq->dev.parent
+ && devfreq->dev.parent->of_node == node) {
+ mutex_unlock(&devfreq_list_lock);
+ return devfreq;
+ }
+ }
+ mutex_unlock(&devfreq_list_lock);
+
+ return ERR_PTR(-EPROBE_DEFER);
+}
+#else
+struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif /* CONFIG_OF */
+EXPORT_SYMBOL_GPL(devfreq_get_devfreq_by_phandle);
+
/**
* devm_devfreq_remove_device() - Resource-managed devfreq_remove_device()
* @dev: the device to add devfreq feature.
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index f7a6e6bd716e..d648041145ba 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -211,6 +211,9 @@ extern int devm_devfreq_register_opp_notifier(struct device
*dev,
extern void devm_devfreq_unregister_opp_notifier(struct device *dev,
struct devfreq *devfreq);
+extern struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev,
+ int index);
+
/**
* devfreq_update_stats() - update the last_status pointer in struct devfreq
* @df:the devfreq instance whose status needs updating
@@ -324,6 +327,12 @@ static inline void
devm_devfreq_unregister_opp_notifier(struct device *dev,
{
}
+static inline struct devfreq *devfreq_get_devfreq_by_phandle(struct device
*dev,
+ int index)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline int devfreq_update_stats(struct devfreq *df)
{
return -EINVAL;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/19] PM / devfreq: exynos: Remove unused exynos4/5 busfreq driver
This patch removes the unused exynos4/5 busfreq driver. Instead,
generic exynos-bus frequency driver support the all Exynos SoCs.
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/Kconfig | 22 -
drivers/devfreq/exynos/Makefile |2 -
drivers/devfreq/exynos/exynos4_bus.c | 1055 --
drivers/devfreq/exynos/exynos4_bus.h | 110
drivers/devfreq/exynos/exynos5_bus.c | 431 --
drivers/devfreq/exynos/exynos_ppmu.c | 119
drivers/devfreq/exynos/exynos_ppmu.h | 86 ---
7 files changed, 1825 deletions(-)
delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c
delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c
delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 88f7cc4539b8..e82b1d8cd200 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -91,28 +91,6 @@ config ARM_EXYNOS_BUS_DEVFREQ
and adjusts the operating frequencies and voltages with OPP support.
This does not yet operate with optimal voltages.
-config ARM_EXYNOS4_BUS_DEVFREQ
- bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
- depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) &&
!ARCH_MULTIPLATFORM
- select DEVFREQ_GOV_SIMPLE_ONDEMAND
- select PM_OPP
- help
- This adds the DEVFREQ driver for Exynos4210 memory bus (vdd_int)
- and Exynos4212/4412 memory interface and bus (vdd_mif + vdd_int).
- It reads PPMU counters of memory controllers and adjusts
- the operating frequencies and voltages with OPP support.
- This does not yet operate with optimal voltages.
-
-config ARM_EXYNOS5_BUS_DEVFREQ
- tristate "ARM Exynos5250 Bus DEVFREQ Driver"
- depends on SOC_EXYNOS5250
- select DEVFREQ_GOV_SIMPLE_ONDEMAND
- select PM_OPP
- help
- This adds the DEVFREQ driver for Exynos5250 bus interface (vdd_int).
- It reads PPMU counters of memory controllers and adjusts the
- operating frequencies and voltages with OPP support.
-
config ARM_TEGRA_DEVFREQ
tristate "Tegra DEVFREQ Driver"
depends on ARCH_TEGRA_124_SOC
diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
index 4ec06d322996..bc695ad81c7d 100644
--- a/drivers/devfreq/exynos/Makefile
+++ b/drivers/devfreq/exynos/Makefile
@@ -1,4 +1,2 @@
# Exynos DEVFREQ Drivers
obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
-obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos_ppmu.o exynos4_bus.o
-obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos_ppmu.o exynos5_bus.o
diff --git a/drivers/devfreq/exynos/exynos4_bus.c
b/drivers/devfreq/exynos/exynos4_bus.c
deleted file mode 100644
index da9509205169..
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ /dev/null
@@ -1,1055 +0,0 @@
-/* drivers/devfreq/exynos4210_memorybus.c
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com/
- * MyungJoo Ham
- *
- * EXYNOS4 - Memory/Bus clock frequency scaling support in DEVFREQ framework
- * This version supports EXYNOS4210 only. This changes bus frequencies
- * and vddint voltages. Exynos4412/4212 should be able to be supported
- * with minor modifications.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#include "exynos_ppmu.h"
-#include "exynos4_bus.h"
-
-#define MAX_SAFEVOLT 120 /* 1.2V */
-
-enum exynos4_busf_type {
- TYPE_BUSF_EXYNOS4210,
- TYPE_BUSF_EXYNOS4x12,
-};
-
-/* Assume that the bus is saturated if the utilization is 40% */
-#define BUS_SATURATION_RATIO 40
-
-enum busclk_level_idx {
- LV_0 = 0,
- LV_1,
- LV_2,
- LV_3,
- LV_4,
- _LV_END
-};
-
-enum exynos_ppmu_idx {
- PPMU_DMC0,
- PPMU_DMC1,
- PPMU_END,
-};
-
-#define EX4210_LV_MAX LV_2
-#define EX4x12_LV_MAX LV_4
-#define EX4210_LV_NUM (LV_2 + 1)
-#define EX4x12_LV_NUM (LV_4 + 1)
-
-/**
- * struct busfreq_opp_info - opp information for bus
- * @rate: Frequency in hertz
- * @volt: Voltage in microvolts corresponding to this OPP
- */
-struct busfreq_opp_info {
- unsigned long rate;
- unsigned long volt;
-};
-
-struct busfreq_data {
- enum exynos4_busf_type type;
- struct device *dev;
- struct devfreq *devfreq;
- bool disabled;
- struct regulator *vdd_int;
- struct regulator *vdd_mif; /* Exynos4412/4212 only */
- struct busfreq_opp_info curr_oppinfo;
- struct busfreq_ppmu_data ppmu_data;
-
- struct notif
[PATCH v2 04/19] ARM: dts: Add DMC bus frequency for exynos3250-rinato/monk
This patch adds the DMC (Dynamic Memory Controller) bus frequency node
which includes the devfreq-events and regulator properties. The bus
frequency support the DVFS (Dynamic Voltage Frequency Scaling) feature
with ondemand governor.
The devfreq-events (ppmu_dmc0*) can monitor the utilization of DMC bus
on runtime and the buck1_reg (VDD_MIF power line) supplies the power to
the DMC block.
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250-monk.dts | 6 ++
arch/arm/boot/dts/exynos3250-rinato.dts | 6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index 443a35085846..d982586a6533 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -498,6 +498,12 @@
};
};
+&bus_dmc {
+ devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
+ vdd-supply = <&buck1_reg>;
+ status = "okay";
+};
+
&xusbxti {
clock-frequency = <2400>;
};
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 3e64d5dcdd60..61477943015b 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -675,6 +675,12 @@
};
};
+&bus_dmc {
+ devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
+ vdd-supply = <&buck1_reg>;
+ status = "okay";
+};
+
&xusbxti {
clock-frequency = <2400>;
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/19] ARM: dts: Add bus nodes using VDD_INT for Exynos3250
This patch adds the bus nodes using VDD_INT for Exynos3250 SoC.
Exynos3250 has following AXI buses to translate data between
DRAM and sub-blocks.
Following list specifies the detailed relation between DRAM and sub-blocks:
- ACLK400 clock for MCUISP
- ACLK266 clock for ISP
- ACLK200 clock for FSYS
- ACLK160 clock for LCD0
- ACLK100 clock for PERIL
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250.dtsi | 160 ++
1 file changed, 160 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 7214c5e42150..46dee1951ec1 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -721,6 +721,166 @@
opp-microvolt = <875000>;
};
};
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_lcd0: bus_lcd0 {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_ACLK_160>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_fsys: bus_fsys {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_ACLK_200>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_mcuisp: bus_mcuisp {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_ACLK_400_MCUISP>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_mcuisp_opp_table>;
+ status = "disabled";
+ };
+
+ bus_isp: bus_isp {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_ACLK_266>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_isp_opp_table>;
+ status = "disabled";
+ };
+
+ bus_peril: bus_peril {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_ACLK_100>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_peril_opp_table>;
+ status = "disabled";
+ };
+
+ bus_mfc: bus_mfc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_SCLK_MFC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_leftbus_opp_table: opp_table2 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <5000>;
+ opp-microvolt = <90>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <8000>;
+ opp-microvolt = <90>;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <100>;
+ };
+ opp03 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <100>;
+ };
+ opp04 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <100>;
+ };
+ };
+
+ bus_mcuisp_opp_table: opp_table3 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <5000>;
+ opp-microvolt = <90>;
+
[PATCH v2 07/19] PM / devfreq: Show the related information according to governor type
This patch modifies the following sysfs entry of DEVFREQ framework
because the devfreq device using passive governor don't need the same
information of the devfreq device using rest governor.
- polling_interval: passive gov don't use the sampling rate.
- available_governors : passive gov don't be changed on runtime in this version.
- trans_stat : passive governor don't support trans_stat in this
version.
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/devfreq.c | 31 +--
drivers/devfreq/governor.h| 7 +++
drivers/devfreq/governor_passive.c| 1 +
drivers/devfreq/governor_performance.c| 1 +
drivers/devfreq/governor_powersave.c | 1 +
drivers/devfreq/governor_simpleondemand.c | 1 +
drivers/devfreq/governor_userspace.c | 1 +
include/linux/devfreq.h | 2 ++
8 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 78ea4cdaa82c..18ad956fec93 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -597,7 +597,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
goto err_init;
}
- if (!strncmp(devfreq->governor_name, "passive", 7)) {
+ if (devfreq->governor->type == DEVFREQ_GOV_PASSIVE) {
struct devfreq *parent_devfreq =
((struct devfreq_passive_data *)data)->parent;
@@ -963,13 +963,23 @@ static ssize_t available_governors_show(struct device *d,
struct device_attribute *attr,
char *buf)
{
- struct devfreq_governor *tmp_governor;
+ struct devfreq *devfreq = to_devfreq(d);
ssize_t count = 0;
mutex_lock(&devfreq_list_lock);
- list_for_each_entry(tmp_governor, &devfreq_governor_list, node)
+ if (devfreq->governor->type == DEVFREQ_GOV_PASSIVE) {
count += scnprintf(&buf[count], (PAGE_SIZE - count - 2),
- "%s ", tmp_governor->name);
+ "%s ", devfreq->governor->name);
+ } else {
+ struct devfreq_governor *tmp_governor;
+
+ list_for_each_entry(tmp_governor, &devfreq_governor_list, node)
{
+ if (tmp_governor->type == DEVFREQ_GOV_PASSIVE)
+ continue;
+ count += scnprintf(&buf[count], (PAGE_SIZE - count - 2),
+ "%s ", tmp_governor->name);
+ }
+ }
mutex_unlock(&devfreq_list_lock);
/* Truncate the trailing space */
@@ -1006,6 +1016,11 @@ static DEVICE_ATTR_RO(target_freq);
static ssize_t polling_interval_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
+ struct devfreq *df = to_devfreq(dev);
+
+ if (df->governor->type == DEVFREQ_GOV_PASSIVE)
+ return sprintf(buf, "Not Supported.\n");
+
return sprintf(buf, "%d\n", to_devfreq(dev)->profile->polling_ms);
}
@@ -1020,6 +1035,9 @@ static ssize_t polling_interval_store(struct device *dev,
if (!df->governor)
return -EINVAL;
+ if (df->governor->type == DEVFREQ_GOV_PASSIVE)
+ return -EINVAL;
+
ret = sscanf(buf, "%u", &value);
if (ret != 1)
return -EINVAL;
@@ -1137,11 +1155,12 @@ static ssize_t trans_stat_show(struct device *dev,
int i, j;
unsigned int max_state = devfreq->profile->max_state;
+ if (max_state == 0 || devfreq->governor->type == DEVFREQ_GOV_PASSIVE)
+ return sprintf(buf, "Not Supported.\n");
+
if (!devfreq->stop_polling &&
devfreq_update_status(devfreq, devfreq->previous_freq))
return 0;
- if (max_state == 0)
- return sprintf(buf, "Not Supported.\n");
len = sprintf(buf, " From : To\n");
len += sprintf(buf + len, " :");
diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
index fad7d6321978..43513a58f5bf 100644
--- a/drivers/devfreq/governor.h
+++ b/drivers/devfreq/governor.h
@@ -18,6 +18,13 @@
#define to_devfreq(DEV)container_of((DEV), struct devfreq, dev)
+/* Devfreq governor type */
+#define DEVFREQ_GOV_ONDEMAND 0x1
+#define DEVFREQ_GOV_PERFORMANCE0x2
+#define DEVFREQ_GOV_POWERSAVE 0x3
+#define DEVFREQ_GOV_USERSPACE 0x4
+#define DEVFREQ_GOV_PASSIVE0x4
+
/* Devfreq events */
#define DEVFREQ_GOV_START 0x1
#define DEVFREQ_GOV_STOP 0x2
diff --git a/drivers/devfreq/governor_passive.c
b/drivers/devfreq/governor_passive.c
index 7443ae4b92f9..adfdee9a9cd1 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drive
[PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data between
DRAM and sub-blocks.
Following list specifies the detailed relation between DRAM and sub-blocks:
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD
: The minimum clock of ACLK160 should be over 160MHz.
When drop the clock under 160MHz, show the broken image.
- ACLK133 clock for FSYS
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4x12.dtsi | 112 ++
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 3bcf0939755e..8bc4aee156b5 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -354,6 +354,118 @@
opp-microvolt = <95>;
};
};
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_display: bus_display {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK160>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_display_opp_table>;
+ status = "disabled";
+ };
+
+ bus_fsys: bus_fsys {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK133>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_fsys_opp_table>;
+ status = "disabled";
+ };
+
+ bus_peri: bus_peri {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK100>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_peri_opp_table>;
+ status = "disabled";
+ };
+
+ bus_mfc: bus_mfc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_SCLK_MFC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_leftbus_opp_table: opp_table3 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <90>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <925000>;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 <16000>;
+ opp-microvolt = <95>;
+ };
+ opp03 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <100>;
+ };
+ };
+
+ bus_display_opp_table: opp_table4 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <16000>;
+ opp-microvolt = <95>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <100>;
+ };
+ };
+
+ bus_fsys_opp_table: opp_table5 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <90>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <925000>;
+ };
+ };
+
+ bus_peri_opp_table: opp_table6 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <5000>;
+ opp-microvolt = <90>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <925000>;
+ };
+ };
};
&combiner {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 15/19] ARM: dts: Add bus nodes using VDD_MIF for Exynos4210
This patch adds the bus nodes for Exynos4210 SoC. Exynos4210 SoC has
one power line for all buses to translate data between DRAM and sub-blocks.
Following list specifies the detailed relation between DRAM and sub-blocks:
- DMC/ACP clock for DMC (Dynamic Memory Controller)
- ACLK200 clock for LCD0
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD0/LCD1
- ACLK133 clock for FSYS/GPS
- GDL/GDR clock for LEFTBUS/RIGHTBUS
- SCLK_MFC clock for MFC
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4210.dtsi | 172 ++
1 file changed, 172 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 3e5ba665d200..658c5a1fe03c 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -257,6 +257,178 @@
power-domains = <&pd_lcd1>;
#iommu-cells = <0>;
};
+
+ bus_dmc: bus_dmc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_DMC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ status = "disabled";
+ };
+
+ bus_acp: bus_acp {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_ACP>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_acp_opp_table>;
+ status = "disabled";
+ };
+
+ bus_peri: bus_peri {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK100>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_peri_opp_table>;
+ status = "disabled";
+ };
+
+ bus_fsys: bus_fsys {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK133>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_fsys_opp_table>;
+ status = "disabled";
+ };
+
+ bus_display: bus_display {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK160>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_display_opp_table>;
+ status = "disabled";
+ };
+
+ bus_lcd0: bus_lcd0 {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK200>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_mfc: bus_mfc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_SCLK_MFC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_dmc_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <1025000>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <26700>;
+ opp-microvolt = <105>;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <115>;
+ };
+ };
+
+ bus_acp_opp_table: opp_table2 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <1025000>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <16000>;
+ opp-microvolt = <105>;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <115>;
+ };
+ };
+
+ bus_peri_opp_table: opp_table3 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <500>;
+ opp-microvolt = <1025000>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt
[PATCH v2 09/19] PM / devfreq: exynos: Update documentation for bus devices using passive governor
This patch updates the documentation for passive bus devices and adds the
detailed example of Exynos3250.
Signed-off-by: Chanwoo Choi
---
.../devicetree/bindings/devfreq/exynos-bus.txt | 244 -
1 file changed, 241 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index 54a1f9c46c88..c4fdc70f8eac 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -13,18 +13,23 @@ SoC has the different sub-blocks. So, this difference
should be specified
in devicetree file instead of each device driver. In result, this driver
is able to support the bus frequency for all Exynos SoCs.
-Required properties for bus device:
+Required properties for all bus devices:
- compatible: Should be "samsung,exynos-bus".
- clock-names : the name of clock used by the bus, "bus".
- clocks : phandles for clock specified in "clock-names" property.
- #clock-cells: should be 1.
- operating-points-v2: the OPP table including frequency/voltage information
to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+
+Required properties for only parent bus device:
- vdd-supply: the regulator to provide the buses with the voltage.
- devfreq-events: the devfreq-event device to monitor the curret utilization
of buses.
-Optional properties for bus device:
+Required properties for only passive bus device:
+- devfreq: the parent bus device.
+
+Optional properties for only parent bus device:
- exynos,saturation-ratio: the percentage value which is used to calibrate
the performance count againt total cycle count.
@@ -33,7 +38,20 @@ Example1:
power line (regulator). The MIF (Memory Interface) AXI bus is used to
transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
- - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
+ - MIF (Memory Interface) block
+ : VDD_MIF |--- DMC (Dynamic Memory Controller)
+
+ - INT (Internal) block
+ : VDD_INT |--- LEFTBUS (parent device)
+ |--- PERIL
+ |--- MFC
+ |--- G3D
+ |--- RIGHTBUS
+ |--- FSYS
+ |--- LCD0
+ |--- PERIR
+ |--- ISP
+ |--- CAM
- MIF bus's frequency/voltage table
---
@@ -46,6 +64,24 @@ Example1:
|L5| 40 |875000 |
---
+ - INT bus's frequency/voltage table
+ --
+ |Block|LEFTBUS|RIGHTBUS|MCUISP |ISP|PERIL ||VDD_INT |
+ | name| |LCD0| | | |||
+ | | |FSYS| | | |||
+ | | |MFC | | | |||
+ --
+ |Mode |*parent|passive |passive|passive|passive|||
+ --
+ |Lv |Frequency ||Voltage |
+ --
+ |L1 |5 |5 |5 |5 |5 ||90 |
+ |L2 |8 |8 |8 |8 |8 ||90 |
+ |L3 |10 |10 |10 |10 |10 ||100 |
+ |L4 |134000 |134000 |20 |20 | ||100 |
+ |L5 |20 |20 |40 |30 | ||100 |
+ --
+
Example2 :
The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
are listed below:
@@ -84,6 +120,167 @@ Example2 :
};
};
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_lcd0: bus_lcd0 {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_ACLK_160>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_fsys: bus_fsys {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_ACLK_200>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+
[PATCH v2 18/19] ARM: dts: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3
This patch expands the voltage range of buck1/3 regulator due to as following:
- MIF (Memory Interface) bus frequency needs the 9uV ~ 105uV V.
- INT (Internal) bus frequency needs 9uV ~ 100uV.
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 90800a6da14b..171dea1e3e4a 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -359,8 +359,8 @@
buck1_reg: BUCK1 {
regulator-name = "vdd_mif";
- regulator-min-microvolt = <100>;
- regulator-max-microvolt = <100>;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <105>;
regulator-always-on;
regulator-boot-on;
};
@@ -375,7 +375,7 @@
buck3_reg: BUCK3 {
regulator-name = "vdd_int";
- regulator-min-microvolt = <100>;
+ regulator-min-microvolt = <90>;
regulator-max-microvolt = <100>;
regulator-always-on;
regulator-boot-on;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 16/19] ARM: dts: Add PPMU node for exynos4412-odroidu3
This patch add dt node for PPMU_{DMC0|DMC1|LEFTBUS|RIGHTBUS} for
exynos4412-odroidu3 board. Each PPMU dt node includes one event of
'PPMU Count3'.
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 40 +
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index edf0fc8db6ff..90800a6da14b 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -504,3 +504,43 @@
&watchdog {
status = "okay";
};
+
+&ppmu_dmc0 {
+ status = "okay";
+
+ events {
+ ppmu_dmc0_3: ppmu-event3-dmc0 {
+ event-name = "ppmu-event3-dmc0";
+ };
+ };
+};
+
+&ppmu_dmc1 {
+ status = "okay";
+
+ events {
+ ppmu_dmc1_3: ppmu-event3-dmc1 {
+ event-name = "ppmu-event3-dmc1";
+ };
+ };
+};
+
+&ppmu_leftbus {
+ status = "okay";
+
+ events {
+ ppmu_leftbus_3: ppmu-event3-leftbus {
+ event-name = "ppmu-event3-leftbus";
+ };
+ };
+};
+
+&ppmu_rightbus {
+ status = "okay";
+
+ events {
+ ppmu_rightbus_3: ppmu-event3-rightbus {
+ event-name = "ppmu-event3-rightbus";
+ };
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] stmmac: socfpga: Provide dt node to config ptp clk source.
On Wed, Dec 09, 2015 at 09:41:09AM +0800, Phil Reid wrote:
> Provides an options to use the ptp clock routed from the Altera FPGA
> fabric. Instead of the defalt eosc1 clock connected to the ARM HPS core.
> This setting affects all emacs in the core as the ptp clock is common.
>
> Signed-off-by: Phil Reid
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/net/socfpga-dwmac.txt | 2 ++
> drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 9 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> index 3a9d679..72d82d6 100644
> --- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> @@ -11,6 +11,8 @@ Required properties:
> designware version numbers documented in stmmac.txt
> - altr,sysmgr-syscon : Should be the phandle to the system manager node that
> encompasses the glue register, the register offset, and the register
> shift.
> + - altr,f2h_ptp_ref_clk use f2h_ptp_ref_clk instead of default eosc1 clock
> + for ptp ref clk. This affects all emacs as the clock is common.
>
> Optional properties:
> altr,emac-splitter: Should be the phandle to the emac splitter soft IP node
> if
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> index 401383b..f0d797a 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> @@ -32,6 +32,7 @@
> #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII 0x2
> #define SYSMGR_EMACGRP_CTRL_PHYSEL_WIDTH 2
> #define SYSMGR_EMACGRP_CTRL_PHYSEL_MASK 0x0003
> +#define SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK 0x0010
>
> #define EMAC_SPLITTER_CTRL_REG 0x0
> #define EMAC_SPLITTER_CTRL_SPEED_MASK0x3
> @@ -47,6 +48,7 @@ struct socfpga_dwmac {
> struct regmap *sys_mgr_base_addr;
> struct reset_control *stmmac_rst;
> void __iomem *splitter_base;
> + bool f2h_ptp_ref_clk;
> };
>
> static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed)
> @@ -116,6 +118,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac
> *dwmac, struct device *
> return -EINVAL;
> }
>
> + dwmac->f2h_ptp_ref_clk = of_property_read_bool(np,
> "altr,f2h_ptp_ref_clk");
> +
> np_splitter = of_parse_phandle(np, "altr,emac-splitter", 0);
> if (np_splitter) {
> if (of_address_to_resource(np_splitter, 0, &res_splitter)) {
> @@ -171,6 +175,11 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac
> *dwmac)
> ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << reg_shift);
> ctrl |= val << reg_shift;
>
> + if (dwmac->f2h_ptp_ref_clk)
> + ctrl |= SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK << (reg_shift / 2);
> + else
> + ctrl &= ~(SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK << (reg_shift /
> 2));
> +
> regmap_write(sys_mgr_base_addr, reg_offset, ctrl);
> return 0;
> }
> --
> 1.8.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/19] PM / devfreq: Add new passive governor
This patch adds the new passive governor for DEVFREQ framework. The following
governors are already present and used for DVFS (Dynamic Voltage and Frequency
Scaling) drivers. The following governors are independently used for one device
driver which don't give the influence to other device drviers and also don't
receive the effect from other device drivers.
- ondemand / performance / powersave / userspace
The passive governor depends on operation of parent driver with specific
governos extremely and is not able to decide the new frequency by oneself.
According to the decided new frequency of parent driver with governor,
the passive governor uses it to decide the appropriate frequency for own
device driver. The passive governor must need the following information
from device tree:
- the source clock and OPP tables
- the instance of parent device
For exameple,
there are one more devfreq device drivers which need to change their source
clock according to their utilization on runtime. But, they share the same
power line (e.g., regulator). So, specific device driver is operated as parent
with ondemand governor and then the rest device driver with passive governor
is influenced by parent device.
Suggested-by: Myungjoo Ham
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/Kconfig| 9
drivers/devfreq/Makefile | 1 +
drivers/devfreq/devfreq.c | 47
drivers/devfreq/governor_passive.c | 108 +
include/linux/devfreq.h| 17 ++
5 files changed, 182 insertions(+)
create mode 100644 drivers/devfreq/governor_passive.c
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 55ec774f794c..d03f635a93e1 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -64,6 +64,15 @@ config DEVFREQ_GOV_USERSPACE
Otherwise, the governor does not change the frequnecy
given at the initialization.
+config DEVFREQ_GOV_PASSIVE
+ tristate "Passive"
+ help
+ Sets the frequency by other governors (simple_ondemand, performance,
+ powersave, usersapce) of a parent devfreq device. This governor
+ always has the dependency on the chosen frequency from paired
+ governor. This governor does not change the frequency by oneself
+ through sysfs entry.
+
comment "DEVFREQ Drivers"
config ARM_EXYNOS_BUS_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 375ebbb4fcfb..f81c313b4b79 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND) +=
governor_simpleondemand.o
obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE) += governor_performance.o
obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)+= governor_powersave.o
obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
+obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
# DEVFREQ Drivers
obj-$(CONFIG_ARCH_EXYNOS) += exynos/
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 984c5e9e7bdd..15e58779e4c0 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -190,6 +190,31 @@ static struct devfreq_governor
*find_devfreq_governor(const char *name)
/* Load monitoring helper functions for governors use */
+static int update_devfreq_passive(struct devfreq *devfreq, unsigned long freq)
+{
+ struct devfreq *passive;
+ unsigned long rate;
+ int ret;
+
+ list_for_each_entry(passive, &devfreq->passive_dev_list, passive_node) {
+ if (!passive->governor)
+ continue;
+ rate = freq;
+
+ ret = passive->governor->get_target_freq(passive, &rate);
+ if (ret)
+ return ret;
+
+ ret = passive->profile->target(passive->dev.parent, &rate, 0);
+ if (ret)
+ return ret;
+
+ passive->previous_freq = rate;
+ }
+
+ return 0;
+}
+
/**
* update_devfreq() - Reevaluate the device and configure frequency.
* @devfreq: the devfreq instance.
@@ -233,10 +258,18 @@ int update_devfreq(struct devfreq *devfreq)
flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
}
+ if (!list_empty(&devfreq->passive_dev_list)
+ && devfreq->previous_freq > freq)
+ update_devfreq_passive(devfreq, freq);
+
err = devfreq->profile->target(devfreq->dev.parent, &freq, flags);
if (err)
return err;
+ if (!list_empty(&devfreq->passive_dev_list)
+ && devfreq->previous_freq < freq)
+ update_devfreq_passive(devfreq, freq);
+
if (devfreq->profile->freq_table)
if (devfreq_update_status(devfreq, freq))
dev_err(&devfreq->dev,
@@ -442,6 +475,10 @@ static void _remove_devfreq(struct devfreq *devfreq)
return;
[PATCH v2 13/19] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12
This patch adds the bus noes using VDD_MIF for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data
between DRAM and DMC/ACP/C2C.
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4x12.dtsi | 72 +++
1 file changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index b77dac61ffb5..3bcf0939755e 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -282,6 +282,78 @@
clocks = <&clock CLK_SMMU_LITE1>, <&clock CLK_FIMC_LITE1>;
#iommu-cells = <0>;
};
+
+ bus_dmc: bus_dmc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_DMC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ status = "disabled";
+ };
+
+ bus_acp: bus_acp {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_ACP>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_acp_opp_table>;
+ status = "disabled";
+ };
+
+ bus_c2c: bus_c2c {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_C2C>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ status = "disabled";
+ };
+
+ bus_dmc_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <90>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <90>;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 <16000>;
+ opp-microvolt = <90>;
+ };
+ opp03 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <95>;
+ };
+ opp04 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <105>;
+ };
+ };
+
+ bus_acp_opp_table: opp_table2 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <90>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <90>;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 <16000>;
+ opp-microvolt = <90>;
+ };
+ opp03 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <95>;
+ };
+ };
};
&combiner {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 19/19] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3
THis patch adds the bus device tree nodes for both MIF (Memory) and INT
(Internal) block to enable the bus frequency.
The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
bus is parent device in INT block using VDD_INT.
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47 +
arch/arm/boot/dts/exynos4412-trats2.dts | 47 +
2 files changed, 94 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 171dea1e3e4a..12d08242a179 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -544,3 +544,50 @@
};
};
};
+
+&bus_dmc {
+ devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
+ vdd-supply = <&buck1_reg>;
+ status = "okay";
+};
+
+&bus_acp {
+ devfreq = <&bus_dmc>;
+ status = "okay";
+};
+
+&bus_c2c {
+ devfreq = <&bus_dmc>;
+ status = "okay";
+};
+
+&bus_leftbus {
+ devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
+ vdd-supply = <&buck3_reg>;
+ status = "okay";
+};
+
+&bus_rightbus {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_display {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_fsys {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_peri {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_mfc {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 40a474c4374b..aecd545803ad 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -1286,3 +1286,50 @@
vtmu-supply = <&ldo10_reg>;
status = "okay";
};
+
+&bus_dmc {
+ devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
+ vdd-supply = <&buck1_reg>;
+ status = "okay";
+};
+
+&bus_acp {
+ devfreq = <&bus_dmc>;
+ status = "okay";
+};
+
+&bus_c2c {
+ devfreq = <&bus_dmc>;
+ status = "okay";
+};
+
+&bus_leftbus {
+ devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
+ vdd-supply = <&buck3_reg>;
+ status = "okay";
+};
+
+&bus_rightbus {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_display {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_fsys {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_peri {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_mfc {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 01/15] PM / devfreq: exynos: Add generic exynos bus frequency driver
Hi Anand, On 2015년 11월 27일 09:34, Chanwoo Choi wrote: > Hi Anand, > > On 2015년 11월 27일 02:17, Anand Moon wrote: >> Hi Chanwoo, >> >> On 26 November 2015 at 21:42, Chanwoo Choi wrote: >>> On Thu, Nov 26, 2015 at 11:00 PM, MyungJoo Ham >>> wrote: On Thu, Nov 26, 2015 at 10:47 PM, Chanwoo Choi wrote: > This patch adds the generic exynos bus frequency driver for AMBA AXI bus > of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC > have the common architecture for bus between DRAM and sub-blocks in SoC. > This driver can support the generic bus frequency driver for Exynos SoCs. > > In devicetree, Each bus block has a bus clock, regulator, operation-point > and devfreq-event devices which measure the utilization of each bus block. > > Signed-off-by: Chanwoo Choi > --- > drivers/devfreq/Kconfig | 15 ++ > drivers/devfreq/Makefile| 1 + > drivers/devfreq/exynos/Makefile | 1 + > drivers/devfreq/exynos/exynos-bus.c | 443 > > 4 files changed, 460 insertions(+) > create mode 100644 drivers/devfreq/exynos/exynos-bus.c > Are we finally getting a common Exynos bus driver with full DT support? (can this replace both Exynos4/5 drivers and support Exynos7 series?) >>> >>> Yes. >>> This patch-set would support all Exynos SoCs for bus frequency driver. >>> To make sure the support for Exynos7 series, I need to check the TRM >>> document of Exynos7. I think it is possible for support Exynos7. >>> >>> I'm going to test this driver on various Exynos-based board. >>> >>> Regards, >>> Chanwoo Choi >> >> Please do consider Exynos 542x series as well. > > Sure. I'll to test it on Exynos5422-based Odroid-XU3. I send the v2 patchset but this patchset don't include the support of Odroid-XU3 because of only Exynos542x has the special addtional sequence to change the source clock of DRAM. So, I'm going to support the bus frequency on Exynos542x. After completing it, I'll send the separate patches. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] dt-binding: power: Add otg regulator binding
On Tue, Dec 08, 2015 at 04:40:16PM -0800, Tim Bird wrote: > Add a binding for the regulator which controls the OTG chargepath switch. > The OTG switch gets its power from pm8941_5vs1, and that should be > expressed as a usb-otg-in-supply property in the DT node for the > charger driver. The regulator name is "otg". > > Signed-off-by: Tim Bird > --- > Changes since v1 > - switch supply name to have dashes instead of underscores > - remove superfluous DT explanations in the otg node description > --- > .../devicetree/bindings/power_supply/qcom_smbb.txt| 19 > +++ > 1 file changed, 19 insertions(+) > > diff --git a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt > b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt > index 65b88fa..28b6da7 100644 > --- a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt > +++ b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt > @@ -105,6 +105,22 @@ PROPERTIES > regulation must be done externally to fully comply with > the JEITA safety guidelines if this flag is set. > > +- usb-otg-in-supply: > + Usage: optional > + Value type: > + Description: Reference to the regulator supplying power to the USB_OTG_IN > + pin. > + > +child nodes: > +- otg: > + Usage: optional > + Description: This node defines a regulator used to control the direction > + of VBUS voltage - specifically: whether to supply voltage > + to VBUS for host mode operation of the OTG port, or allow > + input voltage from external VBUS for charging. In the > + hardware, the supply for this regulator comes from > + usb-otg-in-supply. Doesn't this regulator need to have a name defined? Disabling this regulator (along with other setup) will enable charging? Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250
This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 SoC.
The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
SDRAM devices. The bus includes the OPP tables and the source clock for DMC
block.
Following list specifies the detailed relation between the clock and DMC block:
- The source clock of DMC block : div_dmc
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 2f30d632f1cc..7214c5e42150 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -687,6 +687,40 @@
clock-names = "ppmu";
status = "disabled";
};
+
+ bus_dmc: bus_dmc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_dmc CLK_DIV_DMC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ status = "disabled";
+ };
+
+ bus_dmc_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <5000>;
+ opp-microvolt = <80>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <80>;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <80>;
+ };
+ opp03 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <80>;
+ };
+ opp04 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <875000>;
+ };
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 17/19] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato
This patch adds the bus device-tree node of INT (internal) block
to enable the bus frequency. The following sub-blocks share
the VDD_INT power source:
- LEFTBUS (parent device)
- RIGHTBUS
- PERIL
- LCD0
- FSYS
- MCUISP / ISP
- MFC
The LEFTBUS is parent device with devfreq ondemand governor
and the rest devices has the dependency on LEFTBUS bus.
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250-rinato.dts | 41 +
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 61477943015b..3a6ca68b68c3 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -681,6 +681,47 @@
status = "okay";
};
+&bus_leftbus {
+ devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
+ vdd-supply = <&buck3_reg>;
+ status = "okay";
+};
+
+&bus_rightbus {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_lcd0 {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_fsys {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_mcuisp {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_isp {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_peril {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_mfc {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
&xusbxti {
clock-frequency = <2400>;
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
This patch-set includes the two features as following. The generic exynos bus
frequency driver is able to support almost Exynos SoCs for bus frequency
scaling. And the new passive governor is able to make the dependency on
between devices for frequency/voltage scaling. I had posted the patch-set[1]
with the similiar concept. This is is revised version for exynos bus frequency.
- Generic exynos bus frequency driver
- New passive governor of DEVFREQ framework
Depends on:
- This patch-set is based on devfreq.git[2].
[1] https://lkml.org/lkml/2015/1/7/872
: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
[2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch:
for-rafael)
Changes from v1:
(https://lkml.org/lkml/2015/11/26/260)
- Check whether the instance of regulator is NULL or not
when executing regulator_disable() because of only parent
devfreq device has the regulator instance. After fixing it,
the wake-up from suspend state is well working. (patch1)
- Fix bug which checks 'bus-clk' instead of 'bus->regulator'
after calling devm_clk_get() (on patch1)
- Update the documentation to remove the description about
DEVFREQ-EVENT subsystem (on patch2)
- Add the full name of DMC (Dynamic Memory Controller) (on patch2)
- Modify the detailed correlation of buses for Exynos3250
on documentation (patch2)
- Add the MFC bus node for Exynos3250 (on patch11, patch12)
- Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
- Add the PPMU node for exynos4412-odroidu3
- Add the support of bus frequency for exynos4412-odroidu3
Detailed descirption for patch-set:
1. Add generic exynos bus frequency driver
: This patch-set adds the generic exynos bus frequency driver for AXI bus
of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
architecture for bus between DRAM and sub-blocks in SoC.
There are the different buses according to Exynos SoC because Exynos SoC
has the differnt sub-blocks and bus speed. In spite of this difference
among Exynos SoCs, this driver is able to support almost Exynos SoC by adding
unique data of each bus in the devicetree file.
In devicetree, each bus node has a bus clock, regulator, operation-point
and devfreq-event devices which measure the utilization of each bus block.
For example,
- The bus of DMC block in exynos3250.dtsi are listed below:
bus_dmc: bus_dmc {
compatible = "samsung,exynos-bus";
clocks = <&cmu_dmc CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <&bus_dmc_opp_table>;
status = "disabled";
};
bus_dmc_opp_table: opp_table0 {
compatible = "operating-points-v2";
opp-shared;
opp00 {
opp-hz = /bits/ 64 <5000>;
opp-microvolt = <80>;
};
opp01 {
opp-hz = /bits/ 64 <1>;
opp-microvolt = <80>;
};
opp02 {
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <80>;
};
opp03 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <80>;
};
opp04 {
opp-hz = /bits/ 64 <4>;
opp-microvolt = <875000>;
};
};
- Usage case to handle the frequency and voltage of bus on runtime
in exynos3250-rinato.dts are listed below:
&bus_dmc {
devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
vdd-supply = <&buck1_reg>; /* VDD_MIF */
status = "okay";
};
2. Add new passive governor of DEVFREQ framework (patch5-patch7)
: This patch-set add the new passive governor for DEVFREQ framework.
The existing governors (ondemand, performance and so on) are used for DVFS
(Dynamic Voltage and Frequency Scaling) drivers. The existing governors
are independently used for specific device driver which don't give the
influence to other device drviers and also don't receive the effect from
other device drivers.
The passive governor depends on operation of parent driver with existing
governors(ondemand, performance and so on) extremely and is not able to
decide the new frequency by oneself. According to the decided new frequency
of parent driver with governor, the passive governor uses it to decide
the appropriate frequency for own device driver. The passive governor
must need the following information from device tree:
For exameple,
There are one more bus device drivers in Exynos3250 which need to
change their source clock according to their utilization on runtime.
But, they share the same power line (e.g., regulator). So, LEFTBUS bus
driver is operated as parent with ondemand governor and then the rest
device driver
[PATCH v2 02/19] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver
This patch adds the documentation for generic exynos bus frequency
driver.
Signed-off-by: Chanwoo Choi
---
.../devicetree/bindings/devfreq/exynos-bus.txt | 94 ++
1 file changed, 94 insertions(+)
create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
new file mode 100644
index ..54a1f9c46c88
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -0,0 +1,94 @@
+* Generic Exynos Bus frequency device
+
+The Samsung Exynos SoC have many buses for data transfer between DRAM
+and sub-blocks in SoC. Almost Exynos SoC have the common architecture
+for buses. Generally, the each bus of Exynos SoC includes the source clock
+and power line and then is able to change the clock according to the usage
+of each buses on runtime. When gathering the usage of each buses on runtime,
+thie driver uses the PPMU (Platform Performance Monitoring Unit) which
+is able to measure the current load of sub-blocks.
+
+There are a little different composition among Exynos SoC because each Exynos
+SoC has the different sub-blocks. So, this difference should be specified
+in devicetree file instead of each device driver. In result, this driver
+is able to support the bus frequency for all Exynos SoCs.
+
+Required properties for bus device:
+- compatible: Should be "samsung,exynos-bus".
+- clock-names : the name of clock used by the bus, "bus".
+- clocks : phandles for clock specified in "clock-names" property.
+- #clock-cells: should be 1.
+- operating-points-v2: the OPP table including frequency/voltage information
+ to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+- vdd-supply: the regulator to provide the buses with the voltage.
+- devfreq-events: the devfreq-event device to monitor the curret utilization
+ of buses.
+
+Optional properties for bus device:
+- exynos,saturation-ratio: the percentage value which is used to calibrate
+ the performance count againt total cycle count.
+
+Example1:
+ Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
+ power line (regulator). The MIF (Memory Interface) AXI bus is used to
+ transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
+
+ - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
+
+ - MIF bus's frequency/voltage table
+ ---
+ |Lv| Freq | Voltage |
+ ---
+ |L1| 5 |80 |
+ |L2| 10 |80 |
+ |L3| 134000 |80 |
+ |L4| 20 |80 |
+ |L5| 40 |875000 |
+ ---
+
+Example2 :
+ The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
+ are listed below:
+
+ bus_dmc: bus_dmc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_dmc CLK_DIV_DMC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ status = "disabled";
+ };
+
+ bus_dmc_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <5000>;
+ opp-microvolt = <80>;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <80>;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <80>;
+ };
+ opp03 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <80>;
+ };
+ opp04 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <875000>;
+ };
+ };
+
+ Usage case to handle the frequency and voltage of bus on runtime
+ in exynos3250-rinato.dts are listed below:
+
+ &bus_dmc {
+ devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
+ vdd-supply = <&buck1_reg>; /* VDD_MIF */
+ status = "okay";
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/19] PM / devfreq: exynos: Add the detailed correlation between sub-blocks and power line
This patch adds the detailed corrleation between sub-blocks and power line for Exynos3250, Exynos4210 and Exynos4x12. Signed-off-by: Chanwoo Choi --- .../devicetree/bindings/devfreq/exynos-bus.txt | 51 ++ 1 file changed, 51 insertions(+) diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt index c4fdc70f8eac..ed639c4f6466 100644 --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt @@ -33,6 +33,57 @@ Optional properties for only parent bus device: - exynos,saturation-ratio: the percentage value which is used to calibrate the performance count againt total cycle count. +Detailed correlation between sub-blocks and power line according to Exynos SoC: +- In case of Exynos3250, there are two power line as following: + VDD_MIF |--- DMC + + VDD_INT |--- LEFTBUS (parent device) + |--- PERIL + |--- MFC + |--- G3D + |--- RIGHTBUS + |--- PERIR + |--- FSYS + |--- LCD0 + |--- PERIR + |--- ISP + |--- CAM + +- In case of Exynos4210, there is one power line as following: + VDD_INT |--- DMC (parent device) + |--- LEFTBUS + |--- PERIL + |--- MFC(L) + |--- G3D + |--- TV + |--- LCD0 + |--- RIGHTBUS + |--- PERIR + |--- MFC(R) + |--- CAM + |--- FSYS + |--- GPS + |--- LCD0 + |--- LCD1 + +- In case of Exynos4x12, there are two power line as following: + VDD_MIF |--- DMC + + VDD_INT |--- LEFTBUS (parent device) + |--- PERIL + |--- MFC(L) + |--- G3D + |--- TV + |--- IMAGE + |--- RIGHTBUS + |--- PERIR + |--- MFC(R) + |--- CAM + |--- FSYS + |--- GPS + |--- LCD0 + |--- ISP + Example1: Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to power line (regulator). The MIF (Memory Interface) AXI bus is used to -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/19] PM / devfreq: exynos: Add support of bus frequency of sub-blocks using passive governor
This patch adds the support of bus frequency feature for sub-blocks which share
the one power line. If each bus depends on the power line, each bus is not able
to change the voltage by oneself. To optimize the power-consumption on runtime,
some buses using the same power line should change the source clock and
regulator at the same time. So, this patch uses the passive governor to support
the bus frequency for all buses which sharing the one power line.
For example,
Exynos3250 include the two power line for AXI buses as following:
: VDD_MIF : MIF (Memory Interface) provide the DMC (Dynamic Memory Controller)
with the power (regulator).
: VDD_INT : INT (Internal) provide the various sub-blocks with the power
(regulator).
Each bus is included in as follwoing block. In the case of VDD_MIF, only DMC bus
use the power line. So, there is no any depencency between buese. But, in the
case of VDD_INT, various buses share the one power line of VDD_INT. We need to
make the depenency between buses. When using passive governor, there is no
problem to support the bus frequency as DVFS for all buses. One bus should be
operated as the parent bus device which gathering the current load of INT block
and then decides the new frequency with some governors except of passive
governor. After deciding the new frequency by the parent bus device, the rest
bus devices will change the each source clock according to new frequency of the
parent bus device.
- MIF (Memory Interface) block
: VDD_MIF |--- DMC
- INT (Internal) block
: VDD_INT |--- LEFTBUS (parent)
|--- PERIL
|--- MFC
|--- G3D
|--- RIGHTBUS
|--- FSYS
|--- LCD0
|--- PERIR
|--- ISP
|--- CAM
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/Kconfig | 1 +
drivers/devfreq/exynos/exynos-bus.c | 170
2 files changed, 136 insertions(+), 35 deletions(-)
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index d03f635a93e1..88f7cc4539b8 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -79,6 +79,7 @@ config ARM_EXYNOS_BUS_DEVFREQ
bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
depends on ARCH_EXYNOS
select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ select DEVFREQ_GOV_PASSIVE
select DEVFREQ_EVENT_EXYNOS_PPMU
select PM_DEVFREQ_EVENT
select PM_OPP
diff --git a/drivers/devfreq/exynos/exynos-bus.c
b/drivers/devfreq/exynos/exynos-bus.c
index f1bc20839650..2efc2bba757e 100644
--- a/drivers/devfreq/exynos/exynos-bus.c
+++ b/drivers/devfreq/exynos/exynos-bus.c
@@ -91,7 +91,7 @@ static int exynos_bus_get_event(struct exynos_bus *bus,
}
/*
- * Must necessary function for devfreq governor
+ * Must necessary function for devfreq simple-ondemand governor
*/
static int exynos_bus_target(struct device *dev, unsigned long *freq, u32
flags)
{
@@ -205,57 +205,74 @@ static void exynos_bus_exit(struct device *dev)
dev_pm_opp_of_remove_table(dev);
}
-static int exynos_bus_parse_of(struct device_node *np,
- struct exynos_bus *bus)
+/*
+ * Must necessary function for devfreq passive governor
+ */
+static int exynos_bus_passive_target(struct device *dev, unsigned long *freq,
+ u32 flags)
{
- struct device *dev = bus->dev;
- unsigned long rate;
- int i, ret, count, size;
+ struct exynos_bus *bus = dev_get_drvdata(dev);
+ struct dev_pm_opp *new_opp;
+ unsigned long old_freq, new_freq;
+ int ret = 0;
- /* Get the clock to provide each bus with source clock */
- bus->clk = devm_clk_get(dev, "bus");
- if (IS_ERR(bus->clk)) {
- dev_err(dev, "failed to get bus clock\n");
- return PTR_ERR(bus->clk);
+ /* Get new opp-bus instance according to new bus clock */
+ rcu_read_lock();
+ new_opp = devfreq_recommended_opp(dev, freq, flags);
+ if (IS_ERR_OR_NULL(new_opp)) {
+ dev_err(dev, "failed to get recommed opp instance\n");
+ rcu_read_unlock();
+ return PTR_ERR(new_opp);
}
- ret = clk_prepare_enable(bus->clk);
- if (ret < 0) {
- dev_err(dev, "failed to get enable clock\n");
- return ret;
- }
+ new_freq = dev_pm_opp_get_freq(new_opp);
+ old_freq = dev_pm_opp_get_freq(bus->curr_opp);
+ rcu_read_unlock();
- /* Get the freq/voltage OPP table to scale the bus frequency */
- rcu_read_lock();
- ret = dev_pm_opp_of_add_table(dev);
+ if (old_freq == new_freq)
+ return 0;
+
+ /* Change the frequency according to new OPP level */
+ mutex_lock(&bus->lock);
+
+ ret = clk_set_rate(bus->clk, new_freq);
if (ret < 0) {
- dev_err(dev, "failed to get OPP table\n");
- rcu_read_unlock();
- return re
[PATCH v2 01/19] PM / devfreq: exynos: Add generic exynos bus frequency driver
This patch adds the generic exynos bus frequency driver for AMBA AXI bus
of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
have the common architecture for bus between DRAM and sub-blocks in SoC.
This driver can support the generic bus frequency driver for Exynos SoCs.
In devicetree, Each bus block has a bus clock, regulator, operation-point
and devfreq-event devices which measure the utilization of each bus block.
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/Kconfig | 15 ++
drivers/devfreq/Makefile| 1 +
drivers/devfreq/exynos/Makefile | 1 +
drivers/devfreq/exynos/exynos-bus.c | 449
4 files changed, 466 insertions(+)
create mode 100644 drivers/devfreq/exynos/exynos-bus.c
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 64281bb2f650..55ec774f794c 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -66,6 +66,21 @@ config DEVFREQ_GOV_USERSPACE
comment "DEVFREQ Drivers"
+config ARM_EXYNOS_BUS_DEVFREQ
+ bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
+ depends on ARCH_EXYNOS
+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ select DEVFREQ_EVENT_EXYNOS_PPMU
+ select PM_DEVFREQ_EVENT
+ select PM_OPP
+ help
+ This adds the common DEVFREQ driver for Exynos Memory bus. Exynos
+ Memory bus has one more group of memory bus (e.g, MIF and INT block).
+ Each memory bus group could contain many memoby bus block. It reads
+ PPMU counters of memory controllers by using DEVFREQ-event device
+ and adjusts the operating frequencies and voltages with OPP support.
+ This does not yet operate with optimal voltages.
+
config ARM_EXYNOS4_BUS_DEVFREQ
bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) &&
!ARCH_MULTIPLATFORM
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 5134f9ee983d..375ebbb4fcfb 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
# DEVFREQ Drivers
+obj-$(CONFIG_ARCH_EXYNOS) += exynos/
obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos/
obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos/
obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
index 49bc9175f923..4ec06d322996 100644
--- a/drivers/devfreq/exynos/Makefile
+++ b/drivers/devfreq/exynos/Makefile
@@ -1,3 +1,4 @@
# Exynos DEVFREQ Drivers
+obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos_ppmu.o exynos4_bus.o
obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos_ppmu.o exynos5_bus.o
diff --git a/drivers/devfreq/exynos/exynos-bus.c
b/drivers/devfreq/exynos/exynos-bus.c
new file mode 100644
index ..f1bc20839650
--- /dev/null
+++ b/drivers/devfreq/exynos/exynos-bus.c
@@ -0,0 +1,449 @@
+/*
+ * Generic Exynos Bus frequency driver with DEVFREQ Framework
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * Author : Chanwoo Choi
+ *
+ * This driver support Exynos Bus frequency feature by using
+ * DEVFREQ framework and is based on drivers/devfreq/exynos/exynos4_bus.c.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEFAULT_SATURATION_RATIO 40
+
+struct exynos_bus {
+ struct device *dev;
+
+ struct devfreq *devfreq;
+ struct devfreq_event_dev **edev;
+ unsigned int edev_count;
+ struct mutex lock;
+
+ struct dev_pm_opp *curr_opp;
+
+ struct regulator *regulator;
+ struct clk *clk;
+ int ratio;
+};
+
+/*
+ * Control the devfreq-event device to get the current state of bus
+ */
+#define exynos_bus_ops_edev(ops) \
+static int exynos_bus_##ops(struct exynos_bus *bus)\
+{ \
+ int i, ret; \
+ \
+ for (i = 0; i < bus->edev_count; i++) { \
+ if (!bus->edev[i]) \
+ continue; \
+ ret = devfreq_event_##ops(bus->edev[i]);\
+ if (ret < 0)\
+ return ret; \
+ } \
+
Re: [PATCH v3] bus: uniphier-system-bus: add UniPhier System Bus driver
Hi Arnd,
2015-12-09 1:59 GMT+09:00 Arnd Bergmann :
>
> Just a little thought about one thing I found odd:
>
>> +static int uniphier_system_bus_check_overlap(
>> + struct uniphier_system_bus_priv tmp)
>> +{
>
> Did you intentionally pass this by value?
Yes, I did not want to disturb the original one.
It is copied to a temporary storage, and sorted by the base address,
and discarded after the overlap checking.
But, you are right. It is possible (and simpler)
to check the region overlap without sorting.
> Maybe do it explicitly using a pointer
> and memcpy to a local variable, which has a similar effect. Alternatively
> just check each newly probed child node for conflicts with any of the
> previous children. That is slightly more expensive at O(n^2) instead of O(n)
> but n is always small here and you can avoid sorting first.
Good idea. I simplified this function in v4.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 10/11] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation
On Tue, Dec 08, 2015 at 02:32:03PM +, Lee Jones wrote:
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Lee Jones
Acked-by: Rob Herring
> ---
> .../devicetree/bindings/cpufreq/cpufreq-st.txt | 91
> ++
> 1 file changed, 91 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> new file mode 100644
> index 000..d91a02a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> @@ -0,0 +1,91 @@
> +Binding for ST's CPUFreq driver
> +===
> +
> +ST's CPUFreq driver attempts to read 'process' and 'version' attributes
> +from the SoC, then supplies the OPP framework with 'prop' and 'supported
> +hardware' information respectively. The framework is then able to read
> +the DT and operate in the usual way.
> +
> +For more information about the expected DT format [See: ../opp/opp.txt].
> +
> +Frequency Scaling only
> +--
> +
> +No vendor specific driver required for this.
> +
> +Located in CPU's node:
> +
> +- operating-points : [See: ../power/opp.txt]
> +
> +Example [safe]
> +--
> +
> +cpus {
> + cpu@0 {
> + /* kHz uV */
> + operating-points = <150 0
> + 120 0
> + 80 0
> + 50 0>;
> + };
> +};
> +
> +Dynamic Voltage and Frequency Scaling (DVFS)
> +
> +
> +This requires the ST CPUFreq driver to supply 'process' and 'version' info.
> +
> +Located in CPU's node:
> +
> +- operating-points-v2: [See ../power/opp.txt]
> +
> +Example [unsafe]
> +
> +
> +cpus {
> + cpu@0 {
> + operating-points-v2 = <&cpu0_opp_table>;
> + };
> +};
> +
> +cpu0_opp_table: opp_table {
> + compatible = "operating-points-v2";
> +
> + /* ### */
> + /* # WARNING: Do not attempt to copy/replicate these nodes, # */
> + /* # they are only to be supplied by the bootloader !!! # */
> + /* ### */
> + opp0 {
> + /* Major Minor Substrate */
> + /* 2 all all */
> + opp-supported-hw= <0x0004 0x 0x>;
> + opp-hz = /bits/ 64 <15>;
> + clock-latency-ns= <1000>;
> +
> + opp-microvolt-pcode0= <120>;
> + opp-microvolt-pcode1= <120>;
> + opp-microvolt-pcode2= <120>;
> + opp-microvolt-pcode3= <120>;
> + opp-microvolt-pcode4= <117>;
> + opp-microvolt-pcode5= <114>;
> + opp-microvolt-pcode6= <110>;
> + opp-microvolt-pcode7= <107>;
> + };
> +
> + opp1 {
> + /* Major Minor Substrate */
> + /* all all all */
> + opp-supported-hw= <0x 0x 0x>;
> + opp-hz = /bits/ 64 <12>;
> + clock-latency-ns= <1000>;
> +
> + opp-microvolt-pcode0= <111>;
> + opp-microvolt-pcode1= <115>;
> + opp-microvolt-pcode2= <110>;
> + opp-microvolt-pcode3= <108>;
> + opp-microvolt-pcode4= <104>;
> + opp-microvolt-pcode5= <102>;
> + opp-microvolt-pcode6= <98>;
> + opp-microvolt-pcode7= <93>;
> + };
> +};
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 net-next 3/3] bindings: ethernet: macb: Add optional caps properties
On Tue, Dec 08, 2015 at 02:52:06PM +0100, Neil Armstrong wrote:
> Add generic caps properties to the binding in order to support
> future macb/gem implementations with the generic macb compatible form.
>
> Signed-off-by: Neil Armstrong
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/net/macb.txt | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/macb.txt
> b/Documentation/devicetree/bindings/net/macb.txt
> index b5d7976..891c72e 100644
> --- a/Documentation/devicetree/bindings/net/macb.txt
> +++ b/Documentation/devicetree/bindings/net/macb.txt
> @@ -19,6 +19,16 @@ Required properties:
> Optional elements: 'tx_clk'
> - clocks: Phandles to input clocks.
>
> +Optional properties:
> +- cdns,usrio-has-clken: Boolean; The USRIO register has an clock-enable bit.
> +- cdns,usrio-default-mii: Boolean; The USRIO register defaults to MII mode.
> +- cdns,usrio-disabled: Boolean; The USRIO register is not implemented.
> +- cdns,no-gigabit-half: Boolean; The MAC does not support 1000/Half link
> mode.
> +- cdns,gem-sg-disabled: Boolean; The MAC does not support Scatter-Gather
> mode.
> +- cdns,gem-has-gigabit: Boolean; The MAC supports Gigabit Ethernet.
> +- cdns,dma-burst-length: Should countain the DMA burst length.
> +- cdns,jumbo-max-length: Should countain the maximum Jumbo frame length.
> +
> Examples:
>
> macb0: ethernet@fffc4000 {
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] dt-bindings: add Silicon Image SiI8620 bridge bindings
On Tue, Dec 08, 2015 at 02:49:05PM +0100, Andrzej Hajda wrote:
> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
> via I2C bus.
>
> Signed-off-by: Andrzej Hajda
> ---
> .../bindings/video/bridge/sil-sii8620.txt | 34
> ++
> 1 file changed, 34 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
>
> diff --git a/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
> b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
> new file mode 100644
> index 000..29f3f35
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
> @@ -0,0 +1,34 @@
> +Silicon Image SiI8620 bridge bindings
Bridging what to what?
> +
> +Required properties:
> + - compatible: "sil,sii8620"
> + - reg: i2c address of the bridge
> + - cvcc10-supply: Digital Core Supply Voltage (1.0V)
> + - iovcc18-supply: I/O Supply Voltage (1.8V)
> + - int-gpios: gpio specifier of INT pin
Assuming INT means interrupt, this should use interrupts property.
> + - reset-gpios: gpio specifier of RESET pin
> + - clocks, clock-names: specification and name of "xtal" clock
> + - video interfaces: Device node can contain video interface port
> + node for HDMI encoder according to [1].
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> + sii8620@39 {
> + reg = <0x39>;
> + compatible = "sil,sii8620";
> + cvcc10-supply = <&ldo36_reg>;
> + iovcc18-supply = <&ldo34_reg>;
> + int-gpio = <&gpf0 2 0>;
> + reset-gpio = <&gpv7 0 0>;
> + clocks = <&pmu_system_controller 0>;
> + clock-names = "xtal";
> + assigned-clocks = <&pmu_system_controller 0>;
> + assigned-clock-parents = <&xxti>;
These aren't listed in the doc.
> +
> + port {
> + mhl_to_hdmi: endpoint {
> + remote-endpoint = <&hdmi_to_mhl>;
> + };
> + };
I'd like to see this have a port to a connector node, too. Possibly
that can come later.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] bus: uniphier-system-bus: add UniPhier System Bus driver
The UniPhier System Bus is an external bus that connects on-board
devices to the UniPhier SoC. Each bank (chip select) is dynamically
mapped to the CPU-viewed address base via the bus controller. The
bus controller must be configured before any access to the bus.
This driver parses the "ranges" property of the System Bus node and
initialized the bus controller. After the bus becomes ready, devices
below it are populated.
Note:
Each bank can be mapped anywhere in the supported address space;
there is nothing preventing us from assigning bank 0 on 0x4200,
0x4300, or anywhere as long as such region is not used by others.
So, the "ranges" is just one possible software configuration, which
does not seem to fit in device tree because device tree is a hardware
description language. However, of_translate_address() requires
"ranges" in every bus node between CPUs and device mapped on the CPU
address space. In other words, "ranges" properties must be statically
defined in device tree. After some discussion, I decided the dynamic
address reassignment by the driver is too bothersome. Instead, the
device tree should provide a reasonable translation setup that the OS
can rely on.
Signed-off-by: Masahiro Yamada
Acked-by: Rob Herring
Acked-by: Arnd Bergmann
---
Changes in v4:
- Simplify uniphier_system_bus_check_overlap() function
by not using the sort library
- Add some comments to uniphier_system_bus_check_boot_swap()
for clarification
- Add Arnd's Acked-by
Changes in v3:
- Minor fix of git-log
- Add Rob's Acked-by
Changes in v2:
- Re-design the binding, driver implementation
Switch to a single node, populate children after the bus is setup
.../bindings/bus/uniphier-system-bus.txt | 66 +
MAINTAINERS| 1 +
drivers/bus/Kconfig| 8 +
drivers/bus/Makefile | 1 +
drivers/bus/uniphier-system-bus.c | 281 +
5 files changed, 357 insertions(+)
create mode 100644
Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
create mode 100644 drivers/bus/uniphier-system-bus.c
diff --git a/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
new file mode 100644
index 000..68ef80a
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
@@ -0,0 +1,66 @@
+UniPhier System Bus
+
+The UniPhier System Bus is an external bus that connects on-board devices to
+the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and
+some control signals. It supports up to 8 banks (chip selects).
+
+Before any access to the bus, the bus controller must be configured; the bus
+controller registers provide the control for the translation from the offset
+within each bank to the CPU-viewed address. The needed setup includes the base
+address, the size of each bank. Optionally, some timing parameters can be
+optimized for faster bus access.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-bus".
+- reg: offset and length of the register set for the bus controller device.
+- #address-cells: should be 2. The first cell is the bank number (chip
select).
+ The second cell is the address offset within the bank.
+- #size-cells: should be 1.
+- ranges: should provide a proper address translation from the System Bus to
+ the parent bus.
+
+Note:
+The address region(s) that can be assigned for the System Bus is implementation
+defined. Some SoCs can use 0x-0x0fff and 0x4000-0x4fff,
+while other SoCs can only use 0x4000-0x4fff. There might be additional
+limitations depending on SoCs and the boot mode. The address translation is
+arbitrary as long as the banks are assigned in the supported address space with
+the required alignment and they do not overlap one another.
+For example, it is possible to map:
+ bank 0 to 0x4200-0x43ff, bank 5 to 0x4600-0x46ff
+It is also possible to map:
+ bank 0 to 0x4800-0x49ff, bank 5 to 0x4400-0x44ff
+There is no reason to stick to a particular translation mapping, but the
+"ranges" property should provide a "reasonable" default that is known to work.
+The software should initialize the bus controller according to it.
+
+Example:
+
+ system-bus {
+ compatible = "socionext,uniphier-system-bus";
+ reg = <0x58c0 0x400>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <1 0x 0x4200 0x0200
+ 5 0x 0x4600 0x0100>;
+
+ ethernet@1,01f0 {
+ compatible = "smsc,lan9115";
+ reg = <1 0x01f0 0x1000>;
+ interrupts = <0 48 4>
+ phy-mode = "mii";
+ };
+
+
Re: [PATCH v3 2/9] Documentation: dt-bindings: Document STM32 pinctrl driver DT bindings
On Tue, Dec 08, 2015 at 01:45:04PM +0100, Maxime Coquelin wrote: > Signed-off-by: Maxime Coquelin > --- > .../bindings/pinctrl/st,stm32-pinctrl.txt | 126 > + > 1 file changed, 126 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt > > diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt > b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt > new file mode 100644 > index 000..7b4800c > --- /dev/null > +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt > @@ -0,0 +1,126 @@ > +* STM32 GPIO and Pin Mux/Config controller > + > +STMicroelectronics's STM32 MCUs intregrate a GPIO and Pin mux/config hardware > +controller. It controls the input/output settings on the available pins and > +also provides ability to multiplex and configure the output of various > on-chip > +controllers onto these pads. > + > +Pin controller node: > +Required properies: > + - compatible: value should be one of the following: > + (a) "st,stm32f429-pinctrl" > + - #address-cells: The value of this property must be 1 > + - #size-cells : The value of this property must be 1 > + - ranges: defines mapping between pin controller node (parent) to > + gpio-bank node (children). > + - pins-are-numbered: Specify the subnodes are using numbered pinmux to > + specify pins. > + > +GPIO controller/bank node: > +Required properties: > + - gpio-controller : Indicates this device is a GPIO controller > + - #gpio-cells : Should be two. > + The first cell is the pin number > + The second one is the polarity: > + - 0 for active high > + - 1 for active low > + - reg : The gpio address range, relative to the pinctrl > range > + - clocks : clock that drives this bank > + - st,bank-name: Should be a name string for this bank as specified > in > + the datasheet How do you intend to use this? We should come up with something generic or drop it. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/5] dt-bindings: mediatek: Add smi dts binding
On Tue, Dec 08, 2015 at 05:49:10PM +0800, Yong Wu wrote:
> This patch add smi binding document.
>
> Signed-off-by: Yong Wu
Acked-by: Rob Herring
> ---
> .../memory-controllers/mediatek,smi-common.txt | 24 +
> .../memory-controllers/mediatek,smi-larb.txt | 25
> ++
> 2 files changed, 49 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> create mode 100644
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
>
> diff --git
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> new file mode 100644
> index 000..06a83ce
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> @@ -0,0 +1,24 @@
> +SMI (Smart Multimedia Interface) Common
> +
> +The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
> +
> +Required properties:
> +- compatible : must be "mediatek,mt8173-smi-common"
> +- reg : the register and size of the SMI block.
> +- power-domains : a phandle to the power domain of this local arbiter.
> +- clocks : Must contain an entry for each entry in clock-names.
> +- clock-names : must contain 2 entries, as follows:
> + - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
> + the register.
> + - "smi" : It's the clock for transfer data and command.
> + They may be the same if both source clocks are the same.
> +
> +Example:
> + smi_common: smi@14022000 {
> + compatible = "mediatek,mt8173-smi-common";
> + reg = <0 0x14022000 0 0x1000>;
> + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> + clocks = <&mmsys CLK_MM_SMI_COMMON>,
> + <&mmsys CLK_MM_SMI_COMMON>;
> + clock-names = "apb", "smi";
> + };
> diff --git
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> new file mode 100644
> index 000..55ff3b7
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> @@ -0,0 +1,25 @@
> +SMI (Smart Multimedia Interface) Local Arbiter
> +
> +The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
> +
> +Required properties:
> +- compatible : must be "mediatek,mt8173-smi-larb"
> +- reg : the register and size of this local arbiter.
> +- mediatek,smi : a phandle to the smi_common node.
> +- power-domains : a phandle to the power domain of this local arbiter.
> +- clocks : Must contain an entry for each entry in clock-names.
> +- clock-names: must contain 2 entries, as follows:
> + - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
> + the register.
> + - "smi" : It's the clock for transfer data and command.
> +
> +Example:
> + larb1: larb@1601 {
> + compatible = "mediatek,mt8173-smi-larb";
> + reg = <0 0x1601 0 0x1000>;
> + mediatek,smi = <&smi_common>;
> + power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
> + clocks = <&vdecsys CLK_VDEC_CKEN>,
> + <&vdecsys CLK_VDEC_LARB_CKEN>;
> + clock-names = "apb", "smi";
> + };
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/5] dt-bindings: iommu: Add binding for mediatek IOMMU
On Tue, Dec 08, 2015 at 05:49:09PM +0800, Yong Wu wrote:
> This patch add mediatek iommu dts binding document.
>
> Signed-off-by: Yong Wu
> ---
> .../devicetree/bindings/iommu/mediatek,iommu.txt | 68 +
> include/dt-bindings/memory/mt8173-larb-port.h | 111
> +
This should be iommu rather than memory.
Otherwise, it looks okay to me.
> 2 files changed, 179 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h
>
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> new file mode 100644
> index 000..c2fb06e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> @@ -0,0 +1,68 @@
> +* Mediatek IOMMU Architecture Implementation
> +
> + Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U) which
> +uses the ARM Short-Descriptor translation table format for address
> translation.
> +
> + About the M4U Hardware Block Diagram, please check below:
> +
> + EMI (External Memory Interface)
> + |
> + m4u (Multimedia Memory Management Unit)
> + |
> + SMI Common(Smart Multimedia Interface Common)
> + |
> + ++---
> + ||
> + ||
> + SMI larb0SMI larb1 ... SoCs have several SMI local
> arbiter(larb).
> + (display) (vdec)
> + ||
> + ||
> + +-+-+ +++
> + | | | |||
> + | | |... ||| ... There are different ports in each larb.
> + | | | |||
> +OVL0 RDMA0 WDMA0 MC PP VLD
> +
> + As above, The Multimedia HW will go through SMI and M4U while it
> +access EMI. SMI is a brige between m4u and the Multimedia HW. It contain
> +smi local arbiter and smi common. It will control whether the Multimedia
> +HW should go though the m4u for translation or bypass it and talk
> +directly with EMI. And also SMI help control the power domain and clocks for
> +each local arbiter.
> + Normally we specify a local arbiter(larb) for each multimedia HW
> +like display, video decode, and camera. And there are different ports
> +in each larb. Take a example, There are many ports like MC, PP, VLD in the
> +video decode local arbiter, all these ports are according to the video HW.
> +
> +Required properties:
> +- compatible : must be "mediatek,mt8173-m4u".
> +- reg : m4u register base and size.
> +- interrupts : the interrupt of m4u.
> +- clocks : must contain one entry for each clock-names.
> +- clock-names : must be "bclk", It is the block clock of m4u.
> +- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
> + Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
> + according to the local arbiter index, like larb0, larb1, larb2...
> +- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
> + Specifies the mtk_m4u_id as defined in
> + dt-binding/memory/mt8173-larb-port.h.
> +
> +Example:
> + iommu: iommu@10205000 {
> + compatible = "mediatek,mt8173-m4u";
> + reg = <0 0x10205000 0 0x1000>;
> + interrupts = ;
> + clocks = <&infracfg CLK_INFRA_M4U>;
> + clock-names = "bclk";
> + mediatek,larbs = <&larb0 &larb1 &larb2 &larb3 &larb4 &larb5>;
> + #iommu-cells = <1>;
> + };
> +
> +Example for a client device:
> + display {
> + compatible = "mediatek,mt8173-disp";
> + iommus = <&iommu M4U_PORT_DISP_OVL0>,
> + <&iommu M4U_PORT_DISP_RDMA0>;
> + ...
> + };
> diff --git a/include/dt-bindings/memory/mt8173-larb-port.h
> b/include/dt-bindings/memory/mt8173-larb-port.h
> new file mode 100644
> index 000..50ccb93
> --- /dev/null
> +++ b/include/dt-bindings/memory/mt8173-larb-port.h
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (c) 2014-2015 MediaTek Inc.
> + * Author: Yong Wu
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#ifndef __DTS_IOMMU_PORT_MT8173_H
> +#define __DTS_IOMMU_PORT_MT8173_H
> +
> +#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
> +/* Local arbiter ID */
> +#define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0x7)
> +/* PortID within the local arbiter */
> +#define MTK_M4U_TO_PORT(id) ((id) &
Re: [PATCH 2/2] usb: renesas_usbhs: add device tree support for r8a779[23]
On Tue, Dec 08, 2015 at 02:51:51PM +0900, Simon Horman wrote: > Simply document new compatibility string. > As a previous patch adds a generic R-Car Gen2 compatibility string > there appears to be no need for a driver updates. > > Also add names for SoCs. > > Signed-off-by: Simon Horman Acked-by: Rob Herring > --- > Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt > b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt > index 8c50df8441c9..b31f036d2171 100644 > --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt > +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt > @@ -2,10 +2,12 @@ Renesas Electronics USBHS driver > > Required properties: >- compatible: "renesas,usbhs-", "renesas,rcar-usbhs" as fallback. > - - "renesas,usbhs-r8a7790" > - - "renesas,usbhs-r8a7791" > - - "renesas,usbhs-r8a7794" > - - "renesas,usbhs-r8a7795" > + - "renesas,usbhs-r8a7790" (R-Car H2) > + - "renesas,usbhs-r8a7791" (R-Car M2-W) > + - "renesas,usbhs-r8a7792" (R-Car V2H) > + - "renesas,usbhs-r8a7793" (R-Car M2-N) > + - "renesas,usbhs-r8a7794" (R-Car E2) > + - "renesas,usbhs-r8a7795" (R-Car H3) >- reg: Base address and length of the register for the USBHS >- interrupts: Interrupt specifier for the USBHS >- clocks: A list of phandle + clock specifier pairs > -- > 2.1.4 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] stmmac: socfpga: Provide dt node to config ptp clk source.
On Tue, Dec 08, 2015 at 01:13:02PM +0800, Phil Reid wrote:
> Provides an options to use the ptp clock routed from the Altera FPGA
> fabric. Instead of the defalt eosc1 clock connected to the ARM HPS core.
> This setting affects all emacs in the core as the ptp clock is common.
>
> Signed-off-by: Phil Reid
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/net/socfpga-dwmac.txt | 2 ++
> drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 9 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> index 3a9d679..72d82d6 100644
> --- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> @@ -11,6 +11,8 @@ Required properties:
> designware version numbers documented in stmmac.txt
> - altr,sysmgr-syscon : Should be the phandle to the system manager node that
> encompasses the glue register, the register offset, and the register
> shift.
> + - altr,f2h_ptp_ref_clk use f2h_ptp_ref_clk instead of default eosc1 clock
> + for ptp ref clk. This affects all emacs as the clock is common.
>
> Optional properties:
> altr,emac-splitter: Should be the phandle to the emac splitter soft IP node
> if
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> index 401383b..f0d797a 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> @@ -32,6 +32,7 @@
> #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII 0x2
> #define SYSMGR_EMACGRP_CTRL_PHYSEL_WIDTH 2
> #define SYSMGR_EMACGRP_CTRL_PHYSEL_MASK 0x0003
> +#define SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK 0x0010
>
> #define EMAC_SPLITTER_CTRL_REG 0x0
> #define EMAC_SPLITTER_CTRL_SPEED_MASK0x3
> @@ -47,6 +48,7 @@ struct socfpga_dwmac {
> struct regmap *sys_mgr_base_addr;
> struct reset_control *stmmac_rst;
> void __iomem *splitter_base;
> + bool f2h_ptp_ref_clk;
> };
>
> static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed)
> @@ -116,6 +118,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac
> *dwmac, struct device *
> return -EINVAL;
> }
>
> + dwmac->f2h_ptp_ref_clk = of_property_read_bool(np,
> "altr,f2h_ptp_ref_clk");
> +
> np_splitter = of_parse_phandle(np, "altr,emac-splitter", 0);
> if (np_splitter) {
> if (of_address_to_resource(np_splitter, 0, &res_splitter)) {
> @@ -171,6 +175,11 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac
> *dwmac)
> ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << reg_shift);
> ctrl |= val << reg_shift;
>
> + if (dwmac->f2h_ptp_ref_clk)
> + ctrl |= SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK << (reg_shift / 2);
> + else
> + ctrl &= ~(SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK << (reg_shift /
> 2));
> +
> regmap_write(sys_mgr_base_addr, reg_offset, ctrl);
> return 0;
> }
> --
> 1.8.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] doc: dt-binding: generic onboard USB HUB
On Tue, Dec 08, 2015 at 10:58:48AM +0100, Arnd Bergmann wrote: > On Tuesday 08 December 2015 10:50:49 Philipp Zabel wrote: > > Am Dienstag, den 08.12.2015, 09:37 +0800 schrieb Peter Chen: > > > Add dt-binding documentation for generic onboard USB HUB. > > > > > > Signed-off-by: Peter Chen > > > --- > > > .../bindings/usb/generic-onboard-hub.txt | 28 > > > ++ > > > 1 file changed, 28 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/usb/generic-onboard-hub.txt > > > > > > diff --git > > > a/Documentation/devicetree/bindings/usb/generic-onboard-hub.txt > > > b/Documentation/devicetree/bindings/usb/generic-onboard-hub.txt > > > new file mode 100644 > > > index 000..ea92205 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/usb/generic-onboard-hub.txt > > > @@ -0,0 +1,28 @@ > > > +Generic Onboard USB HUB > > >+ > > > +Required properties: > > > +- compatible: should be "generic-onboard-hub" > > > > This something we don't have to define ad-hoc. The hub hangs off an USB > > controller, right? The "Open Firmware recommended practice: USB" > > document already describes how to represent USB devices in a generic > > manner: > > http://www.firmware.org/1275/bindings/usb/usb-1_0.ps > > > > Is there a reason not to reuse this? > > > > The usb hub node would be a child of the usb controller node, and it > > could use > > compatible = "usb,class9"; /* bDeviceClass 9 (Hub) */ > > Good point, I had not thought of that when I looked at the patches. > > Yes, let's do this way. I don't know if we ever implemented the simple > patch to associate a USB device with a device_node, but if not, then > let's do it now for this driver. A lot of people have asked for it in > the past. Agreed. Also, some hubs have I2C buses as well, but I still think under the USB bus is the right place. However, one complication here is often (probably this case) these addtional signals need to be controlled before the device enumerates. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next 4/5] Documentation: atmel-quadspi: add binding file for Atmel QSPI driver
On Mon, Dec 07, 2015 at 03:09:13PM +0100, Cyrille Pitchen wrote:
> This patch documents the DT bindings for the driver of the Atmel QSPI
> controller embedded inside sama5d2x SoCs.
>
> Signed-off-by: Cyrille Pitchen
Acked-by: Rob Herring
> ---
> .../devicetree/bindings/mtd/atmel-quadspi.txt | 32
> ++
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> new file mode 100644
> index ..e81f20f9faf1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> @@ -0,0 +1,32 @@
> +* Atmel Quad Serial Peripheral Interface (QSPI)
> +
> +Required properties:
> +- compatible: Should be "atmel,sama5d2-qspi".
> +- reg:Should contain the locations and lengths of the base
> registers
> + and the mapped memory.
> +- reg-names: Should contain the resource reg names:
> + - qspi_base: configuration register address space
> + - qspi_mmap: memory mapped address space
> +- interrupts: Should contain the interrupt for the device.
> +- clocks: The phandle of the clock needed by the QSPI controller.
> +- #address-cells: Should be <1>.
> +- #size-cells:Should be <0>.
> +
> +Example:
> +
> +spi@f002 {
> + compatible = "atmel,sama5d2-qspi";
> + reg = <0xf002 0x100>, <0xd000 0x800>;
> + reg-names = "qpsi_base", "qspi_mmap";
> + interrupts = <52 IRQ_TYPE_LEVEL_HIGH 7>;
> + clocks = <&spi0_clk>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi0_default>;
> + status = "okay";
> +
> + m25p80@0 {
> + ...
> + };
> +};
> --
> 1.8.2.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 09/11] cpufreq: st: Provide runtime initialised driver for ST's platforms
On 09-12-15, 08:27, Viresh Kumar wrote: > Good work Lee, looks mostly okay. Few nits below. Also, it may make sense to quit early of opp-v2 isn't present in your /cpus/cpuX node. As we wouldn't be using any of this then. -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Update
Good day, hoping you read this email and respond to me in good time.I do not intend to solicit for funds but your time and energy in using my own resources to assist the less privileged becauseI am medically ill and confined at the moment hence I request your indulgence.I will give you a comprehensive brief once I hear from you. Thanks and reply. Robert Grondahl -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 09/11] cpufreq: st: Provide runtime initialised driver for ST's platforms
Good work Lee, looks mostly okay. Few nits below.
On 08-12-15, 14:32, Lee Jones wrote:
> The bootloader is charged with the responsibility to provide platform
> specific Dynamic Voltage and Frequency Scaling (DVFS) information via
> Device Tree. This driver takes the supplied configuration and
> registers it with the new generic OPP framework, to then be used with
> CPUFreq.
>
> Signed-off-by: Lee Jones
> ---
> drivers/cpufreq/Kconfig.arm | 7 +
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/sti-cpufreq.c | 296
> ++
> 3 files changed, 304 insertions(+)
> create mode 100644 drivers/cpufreq/sti-cpufreq.c
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 1582c1c..ccde41b 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -216,6 +216,13 @@ config ARM_SPEAR_CPUFREQ
> help
> This adds the CPUFreq driver support for SPEAr SOCs.
>
> +config ARM_STI_CPUFREQ
> + tristate "STi CPUFreq support"
> + depends on SOC_STIH407
> + help
> + OPP list for cpufreq-dt driver can be provided through DT or can be
> + created at runtime. Select this if you want create OPP list at
> runtime.
Really? Where are we creating the list at runtime ?
> +
> config ARM_TEGRA20_CPUFREQ
> bool "Tegra20 CPUFreq support"
> depends on ARCH_TEGRA
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index c0af1a1..9e63fb1 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -73,6 +73,7 @@ obj-$(CONFIG_ARM_SA1100_CPUFREQ)+= sa1100-cpufreq.o
> obj-$(CONFIG_ARM_SA1110_CPUFREQ) += sa1110-cpufreq.o
> obj-$(CONFIG_ARM_SCPI_CPUFREQ) += scpi-cpufreq.o
> obj-$(CONFIG_ARM_SPEAR_CPUFREQ) += spear-cpufreq.o
> +obj-$(CONFIG_ARM_STI_CPUFREQ)+= sti-cpufreq.o
> obj-$(CONFIG_ARM_TEGRA20_CPUFREQ)+= tegra20-cpufreq.o
> obj-$(CONFIG_ARM_TEGRA124_CPUFREQ) += tegra124-cpufreq.o
> obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
> diff --git a/drivers/cpufreq/sti-cpufreq.c b/drivers/cpufreq/sti-cpufreq.c
> new file mode 100644
> index 000..9f6807e
> --- /dev/null
> +++ b/drivers/cpufreq/sti-cpufreq.c
> @@ -0,0 +1,296 @@
> +/*
> + * Create CPUFreq OPP list
No, that's not what we are doing.
> + *
> + * Author: Ajit Pal Singh
> + * Lee Jones
> + *
> + * Copyright (C) 2015 STMicroelectronics (R&D) Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the version 2 of the GNU General Public License as
> + * published by the Free Software Foundation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Keeping them in alphabetical order is considered better, as that is
more human-readable. Up to you.
> +
> +#define VERSION_ELEMENTS 3
> +
> +#define VERSION_SHIFT28
> +#define HW_INFO_INDEX1
> +#define MAJOR_ID_INDEX 1
> +#define MINOR_ID_INDEX 2
> +
> +/* Only match on "suitable for ALL versions" entries */
> +#define DEFAULT_VERSION 31
i.e. 0x1F. Is that sufficient for you? I mean, why not keep this value
as 0x to be future proof ? (I know there wouldn't be that many
versions, but still its better to use the full 32 bit field). Also
this should be in Hex I believe.
> +static const struct reg_field *sti_cpufreq_match(struct platform_device
> *pdev)
> +{
> + if (of_machine_is_compatible("st,stih407") ||
> + of_machine_is_compatible("st,stih410"))
> + return sti_stih407_dvfs_regfields;
You had Kconfig dependency on STI407 only and not 410. Perhaps there
is no STI410 config option?
> +
> + return NULL;
> +}
> +
> +static int sti_cpufreq_set_opp_info(struct platform_device *pdev)
> +{
> + struct st_cpufreq_ddata *ddata = platform_get_drvdata(pdev);
> + struct device_node *cpu_np = ddata->cpu->of_node;
> + const struct reg_field *reg_fields;
> + unsigned int hw_info_offset;
> + unsigned int version[VERSION_ELEMENTS];
> + int pcode, substrate, major, minor;
> + int ret;
> + char name[7];
> +
> + reg_fields = sti_cpufreq_match(pdev);
> + if (!reg_fields) {
> + dev_warn(&pdev->dev, "Machine not supported\n");
Continuing comments from the last patch, where I suggested not to
create a platform-device for this enabler driver..
You can make this dev_dbg(), so that we don't warn unnecessarily on
other STI407 platforms.
> + return -ENODEV;
> + }
> +
> + ret = of_property_read_u32_index(cpu_np, "st,syscfg-eng",
> + HW_INFO_INDEX, &hw_info_offset);
> + if (ret) {
> + dev_warn(&pdev->dev, "Failed to read HW info offset from DT\n");
> + substrat
Re: [PATCH v4 1/4] stmmac: create of compatible mdio bus for stmacc driver
On 9/12/2015 10:15 AM, kbuild test robot wrote: url: https://github.com/0day-ci/linux/commits/Phil-Reid/stmmac-create-of-compatible-mdio-bus-for-stmacc-driver/20151209-094242 config: x86_64-randconfig-b0-12090825 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c: In function 'stmmac_mdio_register': drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c:226:17: error: 'struct stmmac_mdio_bus_data' has no member named 'reset_gpio' mdio_bus_data->reset_gpio = -1; ^ G'day Arnd, I got the above error from kbuild test robot. When changing to if (IS_ENABLED(CONFIG_OF)). This was existing code that I moved into this conditional. reset_gpio member only exists when CONFIG_OF is defined. So it looks like I need to move that code back to the #if. unless you have an alternate suggestion. -- Regards Phil Reid -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 08/11] ARM: STi: Register CPUFreq device
On 08-12-15, 14:32, Lee Jones wrote:
> +/**
> + * SMP Operations
> + */
Why do you need a documentation style comment here?
> static void write_pen_release(int val)
> {
> pen_release = val;
> @@ -161,3 +166,11 @@ struct smp_operations __initdata sti_smp_ops = {
> .smp_secondary_init = sti_secondary_init,
> .smp_boot_secondary = sti_boot_secondary,
> };
> +
> +/**
> + * CPUFreq Registration
> + */
Here too.
> +void init_cpufreq(void)
> +{
> + platform_device_register_simple("sti-cpufreq", -1, NULL, 0);
> +}
I don't think you need this, as you can do all the stuff you want from
the module_init() function in the driver. You just have to make sure
that your driver is only compilable and workable on the right STi platform.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: renesas_usbhs: add fallback compatibility string
On Tue, Dec 08, 2015 at 05:35:28PM +0300, Sergei Shtylyov wrote:
> On 12/08/2015 08:51 AM, Simon Horman wrote:
>
> >Add fallback compatibility string.
> >This is in keeping with the fallback scheme being adopted wherever
> >appropriate for drivers for Renesas SoCs.
> >
> >Signed-off-by: Simon Horman
> >---
> > Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 4 ++--
> > drivers/usb/renesas_usbhs/common.c | 4
> > 2 files changed, 6 insertions(+), 2 deletions(-)
> >
> >diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >index 7d48f63db44e..8c50df8441c9 100644
> >--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >@@ -1,7 +1,7 @@
> > Renesas Electronics USBHS driver
> >
> > Required properties:
> >- - compatible: Must contain one of the following:
> >+ - compatible: "renesas,usbhs-", "renesas,rcar-usbhs" as fallback.
> > - "renesas,usbhs-r8a7790"
> > - "renesas,usbhs-r8a7791"
> > - "renesas,usbhs-r8a7794"
> [...]
> >diff --git a/drivers/usb/renesas_usbhs/common.c
> >b/drivers/usb/renesas_usbhs/common.c
> >index d82fa36c3465..2a9d4f405f30 100644
> >--- a/drivers/usb/renesas_usbhs/common.c
> >+++ b/drivers/usb/renesas_usbhs/common.c
> >@@ -481,6 +481,10 @@ static const struct of_device_id usbhs_of_match[] = {
> > .compatible = "renesas,usbhs-r8a7795",
> > .data = (void *)USBHS_TYPE_RCAR_GEN2,
> > },
> >+{
> >+.compatible = "renesas,usbhs",
>
>You just documented "renesas,rcar-usbhs".
Thanks. I meant to use "renesas,rcar-usbhs" throughout the patch.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: renesas_usbhs: add fallback compatibility string
On Tue, Dec 08, 2015 at 08:32:49AM +, Kuninori Morimoto wrote:
>
> Hi Simon
>
> > > > Add fallback compatibility string.
> > > > This is in keeping with the fallback scheme being adopted wherever
> > > > appropriate for drivers for Renesas SoCs.
> > > >
> > > > Signed-off-by: Simon Horman
> > > > ---
> > > (snip)
> > > > + {
> > > > + .compatible = "renesas,usbhs",
> > > > + .data = (void *)USBHS_TYPE_RCAR_GEN2,
> > > > + },
> > > > { },
> > > > };
> > >
> > > I think this is too much. This driver is used not only from R-Car Gen2.
> > > It will work as normal mode if .data was 0.
> > > see usbhs_parse_dt()
> >
> > Are you suggesting that we remove USBHS_TYPE_RCAR_GEN2 from the driver?
>
> I mean this
>
> + {
> + .compatible = "renesas,usbhs",
> + },
(As Sergei noted elsewhere, "renesas,rcar-usbhs" is consistent
with what I documented elsewhere in the patch)
My understanding is that will cause the driver to operate in a different manner
to if USBHS_TYPE_RCAR_GEN2 was set. And thus meaning
of the generic and SoC-specifc compatibility strings will cause
the driver to operate differently.
Currently the only compat strings present are as follows:
* renesas,usbhs-r8a7790
* renesas,usbhs-r8a7791
* renesas,usbhs-r8a7794
* renesas,usbhs-r8a7795
And they all set USBHS_TYPE_RCAR_GEN2 (even though r8a7795 is a Gen3 SoC).
What I am aiming is either:
* A compatibility string for R-Car or;
* Two compatibility strings, one for R-Car Gen2 and one for R-Car Gen3
And for this new compatibility string or strings to operate the same
way as the current compatibility strings.
Looking over the driver its not clear to me why the
non-USBHS_TYPE_RCAR_GEN2 case is handled by the code as
there are no compatibility strings present that trigger that mode of
operation. I feel that I must be missing something.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/4] stmmac: create of compatible mdio bus for stmacc driver
From: kbuild test robot Date: Wed, 9 Dec 2015 10:15:17 +0800 > Hi Phil, > > [auto build test ERROR on net-next/master] > [also build test ERROR on v4.4-rc4 next-20151208] > > url: > https://github.com/0day-ci/linux/commits/Phil-Reid/stmmac-create-of-compatible-mdio-bus-for-stmacc-driver/20151209-094242 > config: x86_64-randconfig-b0-12090825 (attached as .config) > reproduce: > # save the attached .config to linux build tree > make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c: In function > 'stmmac_mdio_register': >>> drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c:226:17: error: 'struct >>> stmmac_mdio_bus_data' has no member named 'reset_gpio' >mdio_bus_data->reset_gpio = -1; > ^ Yeah this member is only visible when CONFIG_OF. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/4] stmmac: create of compatible mdio bus for stmacc driver
Hi Phil,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.4-rc4 next-20151208]
url:
https://github.com/0day-ci/linux/commits/Phil-Reid/stmmac-create-of-compatible-mdio-bus-for-stmacc-driver/20151209-094242
config: x86_64-randconfig-b0-12090825 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c: In function
'stmmac_mdio_register':
>> drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c:226:17: error: 'struct
>> stmmac_mdio_bus_data' has no member named 'reset_gpio'
mdio_bus_data->reset_gpio = -1;
^
vim +226 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
220 } else {
221 netdev_err(ndev, "NO MDIO subnode\n");
222 return 0;
223 }
224
225 if (priv->device->of_node)
> 226 mdio_bus_data->reset_gpio = -1;
227 }
228
229 new_bus = mdiobus_alloc();
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[PATCH v10.1 14/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v10.1:
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
hpd when hpd detect failed.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 4 ++-
.../bindings/display/exynos/exynos_dp.txt | 1 +
.../display/rockchip/analogix_dp-rockchip.txt | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++
6 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..4f2ba8c 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
Optional properties for dp-controller:
+ -force-hpd:
+ Indicate driver need force hpd when hpd detect failed, this
+ is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
*
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
-
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
---
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 9905081..8800164 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+ -analogix,need-force-hpd (optional)
-video interfaces (optional)
Deprecated properties for DisplayPort:
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index dae86c4..187a708e 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP binding
document:
- phys (required)
- phy-names (required)
- hpd-gpios (optional)
+- force-hpd (optional)
---
Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a11504b..00aee44 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
{
int timeout_loop = 0;
- while (analogix_dp_get_plug_in_status(dp) != 0) {
+ while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+ if (analogix_dp_get_plug_in_status(dp) == 0)
+ return 0;
+
timeout_loop++;
- if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "failed to get hpd plug status\n");
- return -ETIMEDOUT;
- }
usleep_range(10, 11);
}
+ /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+ if (!dp->force_hpd)
+ return -ETIMEDOUT;
+
+ /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+ dev_dbg(dp->dev, "failed to get hpd plug status, try to force hpd\n");
+
+ analogix_dp_force_hpd(dp);
+
+ if (analogix_dp_get_plug_in_status(dp) !
[PATCH v10.1 10/17] dt-bindings: add document for rockchip dp phy
Add dt binding documentation for rockchip display port PHY.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v10.1:
- Add the ack from Rob Herring
- Correct the title of this rockchip dp phy document(Rob)
Changes in v9: None
Changes in v8:
- Remove the specific address in the example node name. (Heiko)
Changes in v7:
- Simplify the commit message. (Kishon)
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
elemets in document. (Rob & Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..50c4f9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip specific extensions to the Analogix Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy {
+ compatible = "rockchip,rk3288-dp-phy";
+ rockchip,grf = <&grf>;
+ clocks = <&cru SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <0>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10.1 08/17] dt-bindings: add document for rockchip variant of analogix_dp
Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v10.1:
- Add the ack from Rob Herring
Changes in v10: None
Changes in v9:
- Document more details for 'ports' property.
Changes in v8:
- Modify the commit subject name. (Heiko)
Changes in v7: None
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../display/rockchip/analogix_dp-rockchip.txt | 91 ++
1 file changed, 91 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
new file mode 100644
index 000..dae86c4
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -0,0 +1,91 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+ Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
+- pinctrl-0: pin-control mode. should be <&edp_hpd>
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: there are 2 port nodes with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+Port 0: contained 2 endpoints, connecting to the ouput of vop.
+Port 1: contained 1 endpoint, connecting to the input of panel.
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+ dp-controller: dp@ff97 {
+ compatible = "rockchip,rk3288-dp";
+ reg = <0xff97 0x4000>;
+ interrupts = ;
+ clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+ clock-names = "dp", "pclk";
+ phys = <&dp_phy>;
+ phy-names = "dp";
+
+ rockchip,grf = <&grf>;
+ resets = <&cru 111>;
+ reset-names = "dp";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&edp_hpd>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_edp>;
+ };
+ edp_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_edp>;
+ };
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_out_panel: endpoint {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>
+ };
+ };
+ };
+ };
+
+ pinctrl {
+ edp {
+ edp_hpd: edp-hpd {
+ rockchip,pins = <7 11 RK_FUNC_2
&pcfg_pull_none>;
+ };
+ };
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10.1 05/17] dt-bindings: add document for analogix display port driver
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Tested-by: Javier Martinez Canillas
---
Changes in v10.1:
- Add the ack from Rob Herring
Changes in v10: None
Changes in v9: None
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Split all DTS changes, and provide backward compatibility. Mark old
properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
"analogix,color-space" & "analogix,color-depth" &
"analogix,link-rate" & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high" & "interlaces"
Changes in v3:
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 50 +
.../bindings/display/exynos/exynos_dp.txt | 65 --
2 files changed, 72 insertions(+), 43 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
new file mode 100644
index 000..7659a7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+ -compatible:
+ platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+ -reg:
+ physical base address of the controller and length
+ of memory mapped region.
+ -interrupts:
+ interrupt combiner values.
+ -clocks:
+ from common clock binding: handle to dp clock.
+ -clock-names:
+ from common clock binding: Shall be "dp".
+ -interrupt-parent:
+ phandle to Interrupt combiner node.
+ -phys:
+ from general PHY binding: the phandle for the PHY device.
+ -phy-names:
+ from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+ -hpd-gpios:
+ Hotplug detect GPIO.
+ Indicates which GPIO should be used for hotplug detection
+ -port@[X]: SoC specific port nodes with endpoint definitions as defined
+ in Documentation/devicetree/bindings/media/video-interfaces.txt,
+ please refer to the SoC specific binding document:
+ * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+ *
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+ dp-controller {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145b 0x1>;
+ interrupts = <10 3>;
+ interrupt-parent = <&combiner>;
+ clocks = <&clock 342>;
+ clock-names = "dp";
+
+ phys = <&dp_phy>;
+ phy-names = "dp";
+ };
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 64693f2..9905081 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -31,45 +31,31 @@ Required properties for dp-controller:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
- -samsung,color-space:
- input video data format.
- COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
- -samsung,dynamic-range:
- dynamic range for input video data.
- VESA = 0, CEA = 1
- -samsung,ycbcr-coeff:
- YCbCr co-efficients for input video.
- COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
- -samsung,color-depth:
- number of bits per colour component.
- COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
- -samsu
Re: [RESEND PATCH] modpost: don't add a trailing wildcard for OF module aliases
On 12/08/2015 11:00 PM, Javier Martinez Canillas wrote: >>> >>> I sent this patch before [0] but was never picked. MAINTAINERS doesn't >>> say who should manage patches to file2alias so maybe I didn't add the >>> right person to the cc list. >> >> z:/usr/src/git26> perl scripts/get_maintainer.pl -f scripts/mod >> Rusty Russell (commit_signer:18/27=67%) >> > > Yes, I use get_maintainer.pl but usually with the --no-git-fallback since > the --git-fallback option tends to be too noisy and people complain that > are cc'ed on random patches just because they touched a file in the past. > > IOW, there is no way to know only by looking at get_maintainer.pl output > if Rusty has only made a lot of changes to that repo or if he acts as a err.. I meant s/repo/directory Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] modpost: don't add a trailing wildcard for OF module aliases
Hello Andrew, On 12/08/2015 08:11 PM, Andrew Morton wrote: > On Tue, 8 Dec 2015 19:13:32 -0300 Javier Martinez Canillas > wrote: [snip] >> >> I sent this patch before [0] but was never picked. MAINTAINERS doesn't >> say who should manage patches to file2alias so maybe I didn't add the >> right person to the cc list. > > z:/usr/src/git26> perl scripts/get_maintainer.pl -f scripts/mod > Rusty Russell (commit_signer:18/27=67%) > Yes, I use get_maintainer.pl but usually with the --no-git-fallback since the --git-fallback option tends to be too noisy and people complain that are cc'ed on random patches just because they touched a file in the past. IOW, there is no way to know only by looking at get_maintainer.pl output if Rusty has only made a lot of changes to that repo or if he acts as a maintainer (i.e: picks patches and send pull requests). For these cases, is good to have a proper entry in MAINTAINERS. >> Documentation/development-process/5.Posting says that if there is no >> obvious maintainer, then Andrew Morton is often the patch target so >> I'm re-sending to him. > > Yep. If I don't handle the particular patch, I know who does ;) > I see that you picked the patch already, thanks a lot for your help! Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] stmmac: Correct documentation on stmmac clocks.
devm_get_clk looks in clock-name property for matching clock. the ptp_ref_clk property is ignored. Acked-by: Rob Herring Signed-off-by: Phil Reid --- Documentation/devicetree/bindings/net/stmmac.txt | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index fd5ddf8..e862a92 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -35,15 +35,14 @@ Optional properties: - reset-names: Should contain the reset signal name "stmmaceth", if a reset phandle is given - max-frame-size: See ethernet.txt file in the same directory -- clocks: If present, the first clock should be the GMAC main clock and - the second clock should be peripheral's register interface clock. Further - clocks may be specified in derived bindings. -- clock-names: One name for each entry in the clocks property, the - first one should be "stmmaceth" and the second one should be "pclk". -- clk_ptp_ref: this is the PTP reference clock; in case of the PTP is - available this clock is used for programming the Timestamp Addend Register. - If not passed then the system clock will be used and this is fine on some - platforms. +- clocks: If present, the first clock should be the GMAC main clock + The optional second clock should be peripheral's register interface clock. + The third optional clock should be the ptp reference clock. + Further clocks may be specified in derived bindings. +- clock-names: One name for each entry in the clocks property. + The first one should be "stmmaceth". + The optional second one should be "pclk". + The optional third one should be "clk_ptp_ref". - snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register. - tx-fifo-depth: See ethernet.txt file in the same directory - rx-fifo-depth: See ethernet.txt file in the same directory -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/4] stmmac: Fix calculations for ptp counters when clock input = 50Mhz.
stmmac_config_sub_second_increment set the sub second increment to 20ns.
Driver is configured to use the fine adjustment method where the sub second
register is incremented when the acculumator incremented by the addend
register wraps overflows. This accumulator is update on every ptp clk
cycle. If a ptp clk with a period of greater than 20ns was used the
sub second register would not get updated correctly.
Instead set the sub sec increment to twice the period of the ptp clk.
This result in the addend register being set mid range and overflow
the accumlator every 2 clock cycles.
Signed-off-by: Phil Reid
---
drivers/net/ethernet/stmicro/stmmac/common.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 9 ++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ---
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index f4518bc..1e19c8f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -439,7 +439,7 @@ struct stmmac_ops {
/* PTP and HW Timer helpers */
struct stmmac_hwtimestamp {
void (*config_hw_tstamping) (void __iomem *ioaddr, u32 data);
- void (*config_sub_second_increment) (void __iomem *ioaddr);
+ u32 (*config_sub_second_increment) (void __iomem *ioaddr, u32 clk_rate);
int (*init_systime) (void __iomem *ioaddr, u32 sec, u32 nsec);
int (*config_addend) (void __iomem *ioaddr, u32 addend);
int (*adjust_systime) (void __iomem *ioaddr, u32 sec, u32 nsec,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 76ad214..a77f689 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -33,22 +33,25 @@ static void stmmac_config_hw_tstamping(void __iomem
*ioaddr, u32 data)
writel(data, ioaddr + PTP_TCR);
}
-static void stmmac_config_sub_second_increment(void __iomem *ioaddr)
+static u32 stmmac_config_sub_second_increment(void __iomem *ioaddr,
+ u32 ptp_clock)
{
u32 value = readl(ioaddr + PTP_TCR);
unsigned long data;
/* Convert the ptp_clock to nano second
-* formula = (1/ptp_clock) * 10
+* formula = (2/ptp_clock) * 10
* where, ptp_clock = 50MHz.
*/
- data = (10ULL / 5000);
+ data = (20ULL / ptp_clock);
/* 0.465ns accuracy */
if (!(value & PTP_TCR_TSCTRLSSR))
data = (data * 1000) / 465;
writel(data, ioaddr + PTP_SSIR);
+
+ return data;
}
static int stmmac_init_systime(void __iomem *ioaddr, u32 sec, u32 nsec)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3c6549a..2231a01 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -53,6 +53,7 @@
#include "stmmac.h"
#include
#include
+#include "dwmac1000.h"
#define STMMAC_ALIGN(x)L1_CACHE_ALIGN(x)
@@ -185,7 +186,7 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
priv->clk_csr = STMMAC_CSR_100_150M;
else if ((clk_rate >= CSR_F_150M) && (clk_rate < CSR_F_250M))
priv->clk_csr = STMMAC_CSR_150_250M;
- else if ((clk_rate >= CSR_F_250M) && (clk_rate <= CSR_F_300M))
+ else if ((clk_rate >= CSR_F_250M) && (clk_rate < CSR_F_300M))
priv->clk_csr = STMMAC_CSR_250_300M;
}
}
@@ -435,6 +436,7 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
u32 ts_master_en = 0;
u32 ts_event_en = 0;
u32 value = 0;
+ u32 sec_inc;
if (!(priv->dma_cap.time_stamp || priv->adv_ts)) {
netdev_alert(priv->dev, "No support for HW time stamping\n");
@@ -598,24 +600,19 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
tstamp_all | ptp_v2 | ptp_over_ethernet |
ptp_over_ipv6_udp | ptp_over_ipv4_udp | ts_event_en |
ts_master_en | snap_type_sel);
-
priv->hw->ptp->config_hw_tstamping(priv->ioaddr, value);
/* program Sub Second Increment reg */
- priv->hw->ptp->config_sub_second_increment(priv->ioaddr);
+ sec_inc = priv->hw->ptp->config_sub_second_increment(
+ priv->ioaddr, priv->clk_ptp_rate);
+ temp = div_u64(10ULL, sec_inc);
/* calculate default added value:
* formula is :
* addend = (2^32)/freq_div_ratio;
-* where, freq_div_ratio = clk
[PATCH v4 0/4] stmmac: Fixed Phy & PTP fixes
Provide ability to specify a fixed phy in the device tree and retain the mdio bus if no phy is found. This is needed where a dsa is connected via a fixed phy and uses the mdio bus for config. Fixed ptp ref clock calculatins for the stmmac when ptp ref clock is running at <= 50Mhz. Also add device tree setting to config ptp clk source on socfpga platforms. Changes from V3: - Use if (IS_ENABLED(CONFIG_OF)) instead of #if. Reorder some code to reduce if statements. - of_mdiobus_register already falls back to mdiobus_register - Tested on system with CONFIG_OF Changes from V2: - Formatting, spaces & lines > 80 chars. Using checkpatch - Drop PTP register debugfs patch. Changes from V1: - Fixed mismatch doc / code for ptp_ref_clk dt node. - Remove unit address from doc example. Phil Reid (5): stmmac: create of compatible mdio bus for stmacc driver stmmac: Correct documentation on stmmac clocks. stmmac: Fix calculations for ptp counters when clock input = 50Mhz. stmmac: socfpga: Provide dt node to config ptp clk source. .../devicetree/bindings/net/socfpga-dwmac.txt | 2 ++ Documentation/devicetree/bindings/net/stmmac.txt | 25 +- drivers/net/ethernet/stmicro/stmmac/common.h | 2 +- .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 9 + .../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 9 +++-- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 +-- drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 39 ++ .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +- 8 files changed, 68 insertions(+), 39 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/4] stmmac: create of compatible mdio bus for stmacc driver
The DSA driver needs to be passed a reference to an mdio bus. Typically
the mac is configured to use a fixed link but the mdio bus still needs
to be registered so that it con configure the switch.
This patch follows the same process as the altera tse ethernet driver for
creation of the mdio bus.
Acked-by: Rob Herring
Signed-off-by: Phil Reid
---
Documentation/devicetree/bindings/net/stmmac.txt | 8 +
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 39 ++
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
3 files changed, 34 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index f34fc3c..fd5ddf8 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -47,6 +47,7 @@ Optional properties:
- snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register.
- tx-fifo-depth: See ethernet.txt file in the same directory
- rx-fifo-depth: See ethernet.txt file in the same directory
+- mdio: with compatible = "snps,dwmac-mdio", create and register mdio bus.
Examples:
@@ -65,4 +66,11 @@ Examples:
tx-fifo-depth = <16384>;
clocks = <&clock>;
clock-names = "stmmaceth";
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ phy1: ethernet-phy@0 {
+ };
+ };
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index bba670c..0fcecb2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -29,7 +29,7 @@
#include
#include
#include
-
+#include
#include
#include "stmmac.h"
@@ -200,10 +200,32 @@ int stmmac_mdio_register(struct net_device *ndev)
struct stmmac_priv *priv = netdev_priv(ndev);
struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
int addr, found;
+ struct device_node *mdio_node = NULL;
+ struct device_node *child_node = NULL;
if (!mdio_bus_data)
return 0;
+ if (IS_ENABLED(CONFIG_OF)) {
+ for_each_child_of_node(priv->device->of_node, child_node) {
+ if (of_device_is_compatible(child_node,
+ "snps,dwmac-mdio")) {
+ mdio_node = child_node;
+ break;
+ }
+ }
+
+ if (mdio_node) {
+ netdev_dbg(ndev, "FOUND MDIO subnode\n");
+ } else {
+ netdev_err(ndev, "NO MDIO subnode\n");
+ return 0;
+ }
+
+ if (priv->device->of_node)
+ mdio_bus_data->reset_gpio = -1;
+ }
+
new_bus = mdiobus_alloc();
if (new_bus == NULL)
return -ENOMEM;
@@ -216,11 +238,6 @@ int stmmac_mdio_register(struct net_device *ndev)
irqlist = priv->mii_irq;
}
-#ifdef CONFIG_OF
- if (priv->device->of_node)
- mdio_bus_data->reset_gpio = -1;
-#endif
-
new_bus->name = "stmmac";
new_bus->read = &stmmac_mdio_read;
new_bus->write = &stmmac_mdio_write;
@@ -231,7 +248,8 @@ int stmmac_mdio_register(struct net_device *ndev)
new_bus->irq = irqlist;
new_bus->phy_mask = mdio_bus_data->phy_mask;
new_bus->parent = priv->device;
- err = mdiobus_register(new_bus);
+
+ err = of_mdiobus_register(new_bus, mdio_node);
if (err != 0) {
pr_err("%s: Cannot register as MDIO bus\n", new_bus->name);
goto bus_register_fail;
@@ -284,13 +302,6 @@ int stmmac_mdio_register(struct net_device *ndev)
}
}
- if (!found) {
- pr_warn("%s: No PHY found\n", ndev->name);
- mdiobus_unregister(new_bus);
- mdiobus_free(new_bus);
- return -ENODEV;
- }
-
priv->mii = new_bus;
return 0;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index d02691b..6863420 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -146,7 +146,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
- if (plat->phy_node || plat->phy_bus_name)
+ if (plat->phy_bus_name)
plat->mdio_bus_data = NULL;
el
[PATCH v4 4/4] stmmac: socfpga: Provide dt node to config ptp clk source.
Provides an options to use the ptp clock routed from the Altera FPGA
fabric. Instead of the defalt eosc1 clock connected to the ARM HPS core.
This setting affects all emacs in the core as the ptp clock is common.
Signed-off-by: Phil Reid
---
Documentation/devicetree/bindings/net/socfpga-dwmac.txt | 2 ++
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 9 +
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
index 3a9d679..72d82d6 100644
--- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
@@ -11,6 +11,8 @@ Required properties:
designware version numbers documented in stmmac.txt
- altr,sysmgr-syscon : Should be the phandle to the system manager node that
encompasses the glue register, the register offset, and the register shift.
+ - altr,f2h_ptp_ref_clk use f2h_ptp_ref_clk instead of default eosc1 clock
+ for ptp ref clk. This affects all emacs as the clock is common.
Optional properties:
altr,emac-splitter: Should be the phandle to the emac splitter soft IP node if
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 401383b..f0d797a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -32,6 +32,7 @@
#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII 0x2
#define SYSMGR_EMACGRP_CTRL_PHYSEL_WIDTH 2
#define SYSMGR_EMACGRP_CTRL_PHYSEL_MASK 0x0003
+#define SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK 0x0010
#define EMAC_SPLITTER_CTRL_REG 0x0
#define EMAC_SPLITTER_CTRL_SPEED_MASK 0x3
@@ -47,6 +48,7 @@ struct socfpga_dwmac {
struct regmap *sys_mgr_base_addr;
struct reset_control *stmmac_rst;
void __iomem *splitter_base;
+ bool f2h_ptp_ref_clk;
};
static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed)
@@ -116,6 +118,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac
*dwmac, struct device *
return -EINVAL;
}
+ dwmac->f2h_ptp_ref_clk = of_property_read_bool(np,
"altr,f2h_ptp_ref_clk");
+
np_splitter = of_parse_phandle(np, "altr,emac-splitter", 0);
if (np_splitter) {
if (of_address_to_resource(np_splitter, 0, &res_splitter)) {
@@ -171,6 +175,11 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac)
ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << reg_shift);
ctrl |= val << reg_shift;
+ if (dwmac->f2h_ptp_ref_clk)
+ ctrl |= SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK << (reg_shift / 2);
+ else
+ ctrl &= ~(SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK << (reg_shift /
2));
+
regmap_write(sys_mgr_base_addr, reg_offset, ctrl);
return 0;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 14/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
Hi Rob,
Thanks for your respond.
On 12/08/2015 11:09 PM, Rob Herring wrote:
On Mon, Dec 07, 2015 at 02:40:42PM +0800, Yakir Yang wrote:
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
I can see this being common. Just make it "force-hpd".
Okay, I would send the v10.1 out.
- Yakir
Rob
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
hpd when hpd detect failed.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 4 ++-
.../bindings/display/exynos/exynos_dp.txt | 1 +
.../display/rockchip/analogix_dp-rockchip.txt | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 36 +++---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++
6 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..74f0e80 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
Optional properties for dp-controller:
+ -analogix,need-force-hpd:
+ Indicate driver need force hpd when hpd detect failed, this
+ is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
*
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
-
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
---
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 9905081..8800164 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+ -analogix,need-force-hpd (optional)
-video interfaces (optional)
Deprecated properties for DisplayPort:
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index dae86c4..1f1e594 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP binding
document:
- phys (required)
- phy-names (required)
- hpd-gpios (optional)
+- analogix,need-force-hpd (optional)
---
Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a11504b..94968e4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
{
int timeout_loop = 0;
- while (analogix_dp_get_plug_in_status(dp) != 0) {
+ while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+ if (analogix_dp_get_plug_in_status(dp) == 0)
+ return 0;
+
timeout_loop++;
- if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "failed to get hpd plug status\n");
- return -ETIMEDOUT;
- }
usleep_range(10, 11);
}
+ /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+ if (!dp->need_force_hpd)
+ return -ETIMEDOUT;
+
+ /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give
Re: [PATCH for-4.4 2/2] doc: dt: mtd: partitions: add compatible property to "partitions" node
On Mon, Dec 07, 2015 at 09:58:35AM -0800, Brian Norris wrote:
> On Sat, Dec 05, 2015 at 12:45:36PM +0100, Jonas Gorski wrote:
> > On Fri, Dec 4, 2015 at 3:02 AM, Brian Norris
> > wrote:
> > > // proposed
> > > partitions {
> > > compatible = "partitions";
> >
> > "partitions" sounds mode like a device_type thing than a compatible
> > name, maybe "fixed-partitions"? IMHO that would describe better what
> > these are, and doesn't invite to think using compatible =
> > "arm,arm-flash-structure", "partitions"; is a good idea.
>
> "fixed-partitions" sounds OK to me. If no objections, I'll apply these
> patches, with (approximately) a:
>
> s/"partitions"/"fixed-partitions"/
Pushed to linux-mtd.git with the above change.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 10/17] dt-bindings: add document for rockchip dp phy
Hi Rob
On 12/08/2015 11:06 PM, Rob Herring wrote:
On Mon, Dec 07, 2015 at 02:39:50PM +0800, Yakir Yang wrote:
Add dt binding documentation for rockchip display port PHY.
Signed-off-by: Yakir Yang
Reviewed-by: Heiko Stuebner
One possible typo below, otherwise:
Acked-by: Rob Herring
Thanks, it's a typo :)
---
Changes in v10: None
Changes in v9: None
Changes in v8:
- Remove the specific address in the example node name. (Heiko)
Changes in v7:
- Simplify the commit message. (Kishon)
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
elemets in document. (Rob & Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..00902cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip Soc Seroes Display Port PHY
^
Is this supposed to be SerDes?
Hmmm... it shouldn't be SerDes, i guess i may want 'series' which copy
from samsung-phy.txt.
Thanks for catch that, for now i think it should be "Rockchip specific
extensions to the Analogix Display Port PHY". I would send the v10.1 to
fix this typo :)
Thanks,
- Yakir
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy {
+ compatible = "rockchip,rk3288-dp-phy";
+ rockchip,grf = <&grf>;
+ clocks = <&cru SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <0>;
+};
--
1.9.1
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 08/17] dt-bindings: add document for rockchip variant of analogix_dp
Hi Rob,
On 12/08/2015 11:03 PM, Rob Herring wrote:
On Mon, Dec 07, 2015 at 02:39:34PM +0800, Yakir Yang wrote:
Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.
Signed-off-by: Yakir Yang
Reviewed-by: Heiko Stuebner
I already acked the previous v10 you sent.
Acked-by: Rob Herring
Ah, I remember it, sorry about the mistaken :-D
Thanks
- Yakir
---
Changes in v10: None
Changes in v9:
- Document more details for 'ports' property.
Changes in v8:
- Modify the commit subject name. (Heiko)
Changes in v7: None
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../display/rockchip/analogix_dp-rockchip.txt | 91 ++
1 file changed, 91 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
new file mode 100644
index 000..dae86c4
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -0,0 +1,91 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+ Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
+- pinctrl-0: pin-control mode. should be <&edp_hpd>
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: there are 2 port nodes with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+Port 0: contained 2 endpoints, connecting to the ouput of vop.
+Port 1: contained 1 endpoint, connecting to the input of panel.
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+ dp-controller: dp@ff97 {
+ compatible = "rockchip,rk3288-dp";
+ reg = <0xff97 0x4000>;
+ interrupts = ;
+ clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+ clock-names = "dp", "pclk";
+ phys = <&dp_phy>;
+ phy-names = "dp";
+
+ rockchip,grf = <&grf>;
+ resets = <&cru 111>;
+ reset-names = "dp";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&edp_hpd>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_edp>;
+ };
+ edp_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_edp>;
+ };
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_out_panel: endpoint {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>
+ };
+ };
+ };
+ };
+
+ pinctrl {
+ edp {
+ edp_hpd: edp-hpd {
+ rockchip,pins = <7 11 RK_FUNC_2
&pcfg_pull_none>;
+ };
+ };
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 05/17] dt-bindings: add document for analogix display port driver
Hi Rob,
Thanks
- Yakir
On 12/08/2015 11:01 PM, Rob Herring wrote:
On Mon, Dec 07, 2015 at 02:39:07PM +0800, Yakir Yang wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
Acked-by: Rob Herring
---
Changes in v10: None
Changes in v9: None
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Split all DTS changes, and provide backward compatibility. Mark old
properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
"analogix,color-space" & "analogix,color-depth" &
"analogix,link-rate" & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high" & "interlaces"
Changes in v3:
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 50 +
.../bindings/display/exynos/exynos_dp.txt | 65 --
2 files changed, 72 insertions(+), 43 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
new file mode 100644
index 000..7659a7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+ -compatible:
+ platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+ -reg:
+ physical base address of the controller and length
+ of memory mapped region.
+ -interrupts:
+ interrupt combiner values.
+ -clocks:
+ from common clock binding: handle to dp clock.
+ -clock-names:
+ from common clock binding: Shall be "dp".
+ -interrupt-parent:
+ phandle to Interrupt combiner node.
+ -phys:
+ from general PHY binding: the phandle for the PHY device.
+ -phy-names:
+ from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+ -hpd-gpios:
+ Hotplug detect GPIO.
+ Indicates which GPIO should be used for hotplug detection
+ -port@[X]: SoC specific port nodes with endpoint definitions as defined
+ in Documentation/devicetree/bindings/media/video-interfaces.txt,
+ please refer to the SoC specific binding document:
+ * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+ *
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+ dp-controller {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145b 0x1>;
+ interrupts = <10 3>;
+ interrupt-parent = <&combiner>;
+ clocks = <&clock 342>;
+ clock-names = "dp";
+
+ phys = <&dp_phy>;
+ phy-names = "dp";
+ };
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 64693f2..9905081 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -31,45 +31,31 @@ Required properties for dp-controller:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
- -samsung,color-space:
- input video data format.
- COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
- -samsung,dynamic-range:
- dynamic range for input video data.
- VESA = 0, CEA = 1
- -samsung,ycbcr-coeff:
- YCbCr co-efficients for input video.
- COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
- -samsung,color-depth:
- number of bits per colour compone
[PATCH v2 1/3] dt-binding: power: Add otg regulator binding
Add a binding for the regulator which controls the OTG chargepath switch.
The OTG switch gets its power from pm8941_5vs1, and that should be
expressed as a usb-otg-in-supply property in the DT node for the
charger driver. The regulator name is "otg".
Signed-off-by: Tim Bird
---
Changes since v1
- switch supply name to have dashes instead of underscores
- remove superfluous DT explanations in the otg node description
---
.../devicetree/bindings/power_supply/qcom_smbb.txt| 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
index 65b88fa..28b6da7 100644
--- a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
+++ b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
@@ -105,6 +105,22 @@ PROPERTIES
regulation must be done externally to fully comply with
the JEITA safety guidelines if this flag is set.
+- usb-otg-in-supply:
+ Usage: optional
+ Value type:
+ Description: Reference to the regulator supplying power to the USB_OTG_IN
+ pin.
+
+child nodes:
+- otg:
+ Usage: optional
+ Description: This node defines a regulator used to control the direction
+ of VBUS voltage - specifically: whether to supply voltage
+ to VBUS for host mode operation of the OTG port, or allow
+ input voltage from external VBUS for charging. In the
+ hardware, the supply for this regulator comes from
+ usb-otg-in-supply.
+
EXAMPLE
charger@1000 {
compatible = "qcom,pm8941-charger";
@@ -128,4 +144,7 @@ charger@1000 {
qcom,fast-charge-current-limit = <100>;
qcom,dc-charge-current-limit = <100>;
+ usb-otg-in-supply = <&pm8941_5vs1>;
+
+ otg {};
};
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] ARM: dts: qcom: add charger otg regulator
Add the otg regulator provided by the charger block.
Signed-off-by: Tim Bird
---
arch/arm/boot/dts/qcom-pm8941.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi
b/arch/arm/boot/dts/qcom-pm8941.dtsi
index b0d4439..1b80100 100644
--- a/arch/arm/boot/dts/qcom-pm8941.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
@@ -45,6 +45,10 @@
"chg-gone",
"usb-valid",
"dc-valid";
+
+ usb-otg-in-supply = <&pm8941_5vs1>;
+
+ chg_otg: otg { };
};
pm8941_gpios: gpios@c000 {
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] power: qcom_smbb: Add otg regulator for control of vbus
Add a regulator to control the OTG chargepath switch. This
is used by USB code to control VBUS direction - out for host mode
on the OTG port, and in for charging mode.
Signed-off-by: Tim Bird
---
Changes since v1:
- changed name of supply to remove underscores
---
drivers/power/qcom_smbb.c | 74 +++
1 file changed, 74 insertions(+)
diff --git a/drivers/power/qcom_smbb.c b/drivers/power/qcom_smbb.c
index 5eb1e9e..2f1394c 100644
--- a/drivers/power/qcom_smbb.c
+++ b/drivers/power/qcom_smbb.c
@@ -34,6 +34,9 @@
#include
#include
#include
+#include
+#include
+#include
#define SMBB_CHG_VMAX 0x040
#define SMBB_CHG_VSAFE 0x041
@@ -71,6 +74,8 @@
#define BTC_CTRL_HOT_EXT_N BIT(0)
#define SMBB_USB_IMAX 0x344
+#define SMBB_USB_OTG_CTL 0x348
+#define OTG_CTL_EN BIT(0)
#define SMBB_USB_ENUM_TIMER_STOP 0x34e
#define ENUM_TIMER_STOPBIT(0)
#define SMBB_USB_SEC_ACCESS0x3d0
@@ -123,6 +128,9 @@ struct smbb_charger {
struct power_supply *dc_psy;
struct power_supply *bat_psy;
struct regmap *regmap;
+
+ struct regulator_desc otg_rdesc;
+ struct regulator_dev *otg_reg;
};
static int smbb_vbat_weak_fn(unsigned int index)
@@ -778,12 +786,56 @@ static const struct power_supply_desc dc_psy_desc = {
.property_is_writeable = smbb_charger_writable_property,
};
+static int smbb_chg_otg_enable(struct regulator_dev *rdev)
+{
+ struct smbb_charger *chg = rdev_get_drvdata(rdev);
+ int rc;
+
+ rc = regmap_update_bits(chg->regmap, chg->addr + SMBB_USB_OTG_CTL,
+ OTG_CTL_EN, OTG_CTL_EN);
+ if (rc)
+ dev_err(chg->dev, "failed to update OTG_CTL\n");
+ return rc;
+}
+
+static int smbb_chg_otg_disable(struct regulator_dev *rdev)
+{
+ struct smbb_charger *chg = rdev_get_drvdata(rdev);
+ int rc;
+
+ rc = regmap_update_bits(chg->regmap, chg->addr + SMBB_USB_OTG_CTL,
+ OTG_CTL_EN, 0);
+ if (rc)
+ dev_err(chg->dev, "failed to update OTG_CTL\n");
+ return rc;
+}
+
+static int smbb_chg_otg_is_enabled(struct regulator_dev *rdev)
+{
+ struct smbb_charger *chg = rdev_get_drvdata(rdev);
+ unsigned int value = 0;
+ int rc;
+
+ rc = regmap_read(chg->regmap, chg->addr + SMBB_USB_OTG_CTL, &value);
+ if (rc)
+ dev_err(chg->dev, "failed to read OTG_CTL\n");
+
+ return !!(value & OTG_CTL_EN);
+}
+
+static struct regulator_ops smbb_chg_otg_ops = {
+ .enable = smbb_chg_otg_enable,
+ .disable = smbb_chg_otg_disable,
+ .is_enabled = smbb_chg_otg_is_enabled,
+};
+
static int smbb_charger_probe(struct platform_device *pdev)
{
struct power_supply_config bat_cfg = {};
struct power_supply_config usb_cfg = {};
struct power_supply_config dc_cfg = {};
struct smbb_charger *chg;
+ struct regulator_config config = { };
int rc, i;
chg = devm_kzalloc(&pdev->dev, sizeof(*chg), GFP_KERNEL);
@@ -884,6 +936,28 @@ static int smbb_charger_probe(struct platform_device *pdev)
}
}
+ /*
+* otg regulator is used to control VBUS voltage direction
+* when USB switches between host and gadget mode
+*/
+ chg->otg_rdesc.id = -1;
+ chg->otg_rdesc.name = "otg";
+ chg->otg_rdesc.ops = &smbb_chg_otg_ops;
+ chg->otg_rdesc.owner = THIS_MODULE;
+ chg->otg_rdesc.type = REGULATOR_VOLTAGE;
+ chg->otg_rdesc.supply_name = "usb-otg-in";
+ chg->otg_rdesc.fixed_uV = 500;
+ chg->otg_rdesc.n_voltages = 1;
+ chg->otg_rdesc.of_match = "otg";
+
+ config.dev = &pdev->dev;
+ config.driver_data = chg;
+
+ chg->otg_reg = devm_regulator_register(&pdev->dev, &chg->otg_rdesc,
+ &config);
+ if (IS_ERR(chg->otg_reg))
+ return PTR_ERR(chg->otg_reg);
+
chg->jeita_ext_temp = of_property_read_bool(pdev->dev.of_node,
"qcom,jeita-extended-temp-range");
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] misc: Introduce reboot_reason driver
On Tue, Dec 8, 2015 at 2:26 PM, Rob Herring wrote: > On Tue, Dec 8, 2015 at 3:29 PM, John Stultz wrote: >> This patch adds a basic driver to allow for commands like >> "reboot bootloader" and "reboot recovery" to communicate this >> reboot-reason to the bootloader. >> >> This is commonly done on Android devices, in order to reboot >> the device into fastboot or recovery mode. It also supports >> custom OEM specific commands, via "reboot oem-". > > What are some examples of OEM specific commands? Actually, I don't know. That bit was preserved from the 3.4 based logic in a vendor tree. I can drop it for now if you'd rather. >> This driver pulls the phys memory address from DT as well as >> the magic reason values that are written to the address for >> each mode. > > Starting with what does the h/w look like, this is typically > implemented with some sort of persistent register(s) either in the SOC > or PMIC. So I think persistent memory/registers is what we need to > describe in DT. Perhaps this could be tied into pstore (an overkill > for a single register, but useful if you already have pstore support > for persistent memory)? Hrm. Yea. I'm hesitant to tie it into pstore, but that's partly due to not wanting the bootloader to have to parse the pstore area (ideally the bootloader doesn't touch it). To me having the bootloader reserve a page of memory and having the kernel map and write that reserved page makes the most sense to me. It then being special memory mapped registers or just a reserved page can be somewhat equivalent. But maybe I'm being naive? > The 2nd part is which register to use and the > mapping of values to reboot reason. Do these vary within SOC families? > If not, then we should just hardcode them in the reboot drivers which > are already vendor specific. I'm not aware of differences between SOC families for the values, though the addresses might change. > Also, while trying to standardize the values for reboot reason > probably won't work short term, we should define something so people > will start using it. Ack. Though if the values are mostly custom/magic, is having them defined in the DT problematic? Or do you just want macros for something like something like reason,bootloader = ; ? > We also should consider any implications with > PSCI. Sorry. I'm ignorant here. What would those implications possibly be? thanks -john -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] misc: Introduce reboot_reason driver
On Tue, Dec 8, 2015 at 2:07 PM, Bjorn Andersson
wrote:
> On Tue 08 Dec 13:29 PST 2015, John Stultz wrote:
>
>> This patch adds a basic driver to allow for commands like
>> "reboot bootloader" and "reboot recovery" to communicate this
>> reboot-reason to the bootloader.
>>
>> This is commonly done on Android devices, in order to reboot
>> the device into fastboot or recovery mode. It also supports
>> custom OEM specific commands, via "reboot oem-".
>>
>> This driver pulls the phys memory address from DT as well as
>> the magic reason values that are written to the address for
>> each mode.
>>
>> For an example, this patch also adds the DT support for
>> the nexus7 device via its dts (which is not yet upstream).
>>
>> Thoughts and feedback would be appreciated!
>>
>
> Good to see some work on this, I want it too :)
>
> I do however think this is Qualcomm specific in its implementation, so
> adding Andy and linux-arm-msm.
Right. So this is based off of the qualcomm implementation. But I'm
hoping to reuse it for other hardware.
> [..]
>> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> index 5183d18..ee5dcb7 100644
>> --- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> @@ -282,6 +282,15 @@
>> };
>> };
>>
>> + reboot_reason: reboot_reason@2a03f65c {
>> + compatible = "reboot_reason";
>> + reg = <0x2A03F65C 0x4>;
>> + reason,none = <0x77665501>;
>> + reason,bootloader = <0x77665500>;
>> + reason,recovery = <0x77665502>;
>> + reason,oem = <0x6f656d00>;
>> + };
>> +
>
> This address refers to IMEM, which is shared with a number of other
> uses. So I think we should have a simple-mfd (and syscon) with this
> within.
Errr.. I'm going to have to read up there. I'm not super familiar with
any of those drivers, so I'll try to see how exactly they would map in
here.
> I like the fact that you don't hard code the magics in the
> implementation, as I've seen additions from multiple places - so perhaps
> it should be made even more flexible.
>
> OMAP seems to use strings here instead of magics, but the delivery
> mechanism looks to be the same. But I think of this as Qualcomm
> specific.
Yea. This is good feedback. EFI bootloaders have their own
implementations as well. I suspect we'll need a few different driver
"types" to handle these differences, ie: value vs string.
I'll maybe extend the compatible string to make it clear that this is
a "value" style, and we can extend it with a string type later if
folks care?
>> +static int reboot_reason(struct notifier_block *nb, unsigned long action,
>> + void *data)
>> +{
>> + char *cmd = (char *)data;
>> + long reason = reasons[NONE];
>> +
>> + if (!reboot_reason_addr)
>> + return NOTIFY_DONE;
>> +
>> + if (cmd != NULL) {
>> + if (!strncmp(cmd, "bootloader", 10))
>> + reason = reasons[BOOTLOADER];
>> + else if (!strncmp(cmd, "recovery", 8))
>> + reason = reasons[RECOVERY];
>> + else if (!strncmp(cmd, "oem-", 4)) {
>> + unsigned long code;
>> +
>> + if (!kstrtoul(cmd+4, 0, &code))
>> + reason = reasons[OEM] | (code & 0xff);
>> + }
>> + }
>
> In the case where we didn't find a match you should write the "normal"
> reason here, otherwise I think you will end up in recovery when recovery
> issues a reboot (in Android that is).
So, reason is initialized to NONE here. So that should handle this,
no? Or do you mean something more subtle?
>
>> +
>> + if (reason != -1)
>> + writel(reason, reboot_reason_addr);
>> + return NOTIFY_DONE;
>> +}
>> +
>> +static int reboot_reason_probe(struct platform_device *pdev)
>> +{
>> + struct resource *res;
>> + u32 val;
>> + int i;
>> +
>> + /* initialize the reasons */
>> + for (i = 0; i < MAX_REASONS; i++)
>> + reasons[i] = -1;
>> +
>> + /* Try to grab the reason io address */
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + reboot_reason_addr = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(reboot_reason_addr))
>> + return PTR_ERR(reboot_reason_addr);
>> +
>
> Please acquire this memory from a syscon (preferably the the parent
> simple-mfd).
Ok. Will look into this. Sorry for my unfamiliarity with these details.
>> + /* initialize specified reasons from DT */
>> + if (!of_property_read_u32(pdev->dev.of_node, "reason,none", &val))
>> + reasons[NONE] = val;
>> + if (!of_property_read_u32(pdev->dev.of_
Re: [RFC][PATCH] misc: Introduce reboot_reason driver
On Tue, Dec 8, 2015 at 1:52 PM, Arnd Bergmann wrote:
>
> On Tuesday 08 December 2015 13:29:22 John Stultz wrote:
>
> > diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> > b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> > index 5183d18..ee5dcb7 100644
> > --- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> > +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> > @@ -282,6 +282,15 @@
> > };
> > };
> >
> > + reboot_reason: reboot_reason@2a03f65c {
> > + compatible = "reboot_reason";
>
> This is not a good compatible string. There should generally be a vendor
> name associated with it (use "linux," if nothing else, and you should have
> '-' instead of '_'.
Ack.
>
>
> > + reg = <0x2A03F65C 0x4>;
>
> This may easily conflict with the device it is part of. We should have
> non-overlapping register areas in general. For the example you are
> looking at, which register block is this?
So Bjorn says its IMEM, but I was assuming it was just a reserved
magic phys addr from the bootloader.
Ideally I'm hoping to use this same driver for another device, which
plans to reserve a page from memory that the bootloader won't clear.
> > +/* Types of reasons */
> > +static enum {
> > + NONE,
> > + BOOTLOADER,
> > + RECOVERY,
> > + OEM,
> > + MAX_REASONS
> > +} __maybe_unused reason_types;
>
> The variable seems to always be unused, not just "__maybe_unused". Maybe
> remove it?
Yea. I initially just had the empty enum, but the compiler was giving
me "useless class storage specifier in empty declaration" warnings. So
I added a variable to it, but then I got unused variable warnings. So
I ended up with this. :P
Is there a better way? Are enums for array indexes out of fashion?
Just a list of #defines ?
> > +static int reboot_reason(struct notifier_block *nb, unsigned long action,
> > + void *data)
> > +{
> > + char *cmd = (char *)data;
> > + long reason = reasons[NONE];
> > +
> > + if (!reboot_reason_addr)
> > + return NOTIFY_DONE;
> > +
> > + if (cmd != NULL) {
> > + if (!strncmp(cmd, "bootloader", 10))
> > + reason = reasons[BOOTLOADER];
> > + else if (!strncmp(cmd, "recovery", 8))
> > + reason = reasons[RECOVERY];
> > + else if (!strncmp(cmd, "oem-", 4)) {
> > + unsigned long code;
> > +
> > + if (!kstrtoul(cmd+4, 0, &code))
> > + reason = reasons[OEM] | (code & 0xff);
> > + }
> > + }
> > +
> > + if (reason != -1)
> > + writel(reason, reboot_reason_addr);
> > + return NOTIFY_DONE;
> > +}
>
> Will this reboot the machine?
No. Just sets the data for the bootloader before the reboot occurs.
> > + /* Install the notifier */
> > + restart_nb.notifier_call = reboot_reason;
> > + restart_nb.priority = 256;
> > + if (register_restart_handler(&restart_nb)) {
>
> If not, you should use register_reboot_notifier() rather than
> register_restart_handler(). The former gets called to do something
> just before rebooting, while the latter attempts to actually reboot
> the machine.
Ah. Thanks.
> > +static int __init reboot_reason_init(void)
> > +{
> > + return platform_driver_register(&reboot_reason_driver);
> > +}
> > +arch_initcall(reboot_reason_init);
>
> Why this early? If it can be a normal device_initcall, you can use
> module_platform_driver().
Yea. Mostly its just from the driver I stole the init path from, but I
thought it might be useful to have early. But I'm not passionate about
it one way or the other, so module_platform_driver is fine.
Thanks so much for the review and feedback!
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] of/address: replace printk() with pr_debug() / pr_err()
On Tue, 2015-12-08 at 15:28 -0600, Rob Herring wrote:
> On Tue, Dec 8, 2015 at 11:03 AM, Joe Perches wrote:
> > On Tue, 2015-12-08 at 08:16 -0800, Joe Perches wrote:
> > > On Wed, 2015-12-09 at 01:07 +0900, Masahiro Yamada wrote:
> > > > Trivial changes suggested by checkpatch.pl.
> > > []
> > > > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > > []
> > > > @@ -23,7 +23,7 @@ static int __of_address_to_resource(struct
> > > > device_node *dev,
> > > > #ifdef DEBUG
> > > > static void of_dump_addr(const char *s, const __be32 *addr, int na)
> > > > {
> > > > - printk(KERN_DEBUG "%s", s);
> > > > + pr_debug("%s", s);
> > > > while (na--)
> > > > printk(" %08x", be32_to_cpu(*(addr++)));
> > > > printk("\n");
[]
> > static void of_dumpaddr(const char *s, const __be32 *addr, int na)
> > {
> > print_hex_dump_debug(s, DUMP_PREFIX_NONE, 16, 1,
> > addr, na * sizeof(__be32), false);
> > }
>
> Except that it doesn't do the endian swapping. Looking closer at this,
> we should just drop this hunk. So I will take v1.
Maybe endian conversions should be added to hex_dump_debug like:
(probably doesn't apply. Evolution 3.18 is horrible)
---
include/linux/printk.h | 7 +++
lib/hexdump.c | 56 +++---
2 files changed, 47 insertions(+), 16 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 9729565..4be190c 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -424,6 +424,13 @@ enum {
DUMP_PREFIX_ADDRESS,
DUMP_PREFIX_OFFSET
};
+
+enum {
+ DUMP_TYPE_CPU = 0,
+ DUMP_TYPE_LE = BIT(30),
+ DUMP_TYPE_BE = BIT(31)
+};
+
extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
int groupsize, char *linebuf, size_t linebuflen,
bool ascii);
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 992457b..49113aa 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -81,6 +81,7 @@ EXPORT_SYMBOL(bin2hex);
* @len: number of bytes in the @buf
* @rowsize: number of bytes to print per line; must be 16 or 32
* @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
+ * OR'd with DUMP_TYPE_BE or DUMP_TYPE_LE for endian conversions
* @linebuf: where to put the converted data
* @linebuflen: total size of @linebuf, including space for terminating NUL
* @ascii: include ASCII after the hex output
@@ -114,19 +115,20 @@ int hex_dump_to_buffer(const void *buf, size_t len, int
rowsize, int groupsize,
int j, lx = 0;
int ascii_column;
int ret;
+ int actual_groupsize = groupsize & ~(DUMP_TYPE_LE | DUMP_TYPE_BE);
if (rowsize != 16 && rowsize != 32)
rowsize = 16;
if (len > rowsize) /* limit to one line at a time */
len = rowsize;
- if (!is_power_of_2(groupsize) || groupsize > 8)
- groupsize = 1;
- if ((len % groupsize) != 0) /* no mixed size output */
- groupsize = 1;
+ if (!is_power_of_2(actual_groupsize) || actual_groupsize > 8)
+ actual_groupsize = 1;
+ if ((len % actual_groupsize) != 0) /* no mixed size output */
+ actual_groupsize = 1;
- ngroups = len / groupsize;
- ascii_column = rowsize * 2 + rowsize / groupsize + 1;
+ ngroups = len / actual_groupsize;
+ ascii_column = rowsize * 2 + rowsize / actual_groupsize + 1;
if (!linebuflen)
goto overflow1;
@@ -134,35 +136,56 @@ int hex_dump_to_buffer(const void *buf, size_t len, int
rowsize, int groupsize,
if (!len)
goto nil;
- if (groupsize == 8) {
+ if (actual_groupsize == 8) {
const u64 *ptr8 = buf;
for (j = 0; j < ngroups; j++) {
+ u64 val;
+
+ if (groupsize & DUMP_TYPE_LE)
+ val = get_unaligned_le64(ptr8 + j);
+ else if (groupsize & DUMP_TYPE_BE)
+ val = get_unaligned_be64(ptr8 + j);
+ else
+ val = get_unaligned(ptr8 + j);
ret = snprintf(linebuf + lx, linebuflen - lx,
- "%s%16.16llx", j ? " " : "",
- get_unaligned(ptr8 + j));
+ "%s%16.16llx", j ? " " : "", val);
if (ret >= linebuflen - lx)
goto overflow1;
lx += ret;
}
- } else if (groupsize == 4) {
+ } else if (actual_groupsize == 4) {
const u32 *ptr4 = buf;
for (j = 0; j < ngroups; j++) {
+ u32 val;
+
+ if (groupsize & DUMP_TYPE_LE)
+
[PATCH v2 2/2] ARM: dts: imx6qdl-sabreauto: enable partitions for parallel NOR
Add a 'partitions' property to the nor child of the WEIM bus so
that ofpart will allow partition creation.
Signed-off-by: Alison Chaiken
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 8263fc1..1a29fff 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -625,5 +625,9 @@
bank-width = <2>;
fsl,weim-cs-timing = <0x00620081 0x0001 0x1c022000
0xc000 0x1404a38e 0x>;
+ partitions@0 {
+ label = "pnor";
+ reg = <0x0 0x100>;
+ };
};
};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] ARM: dts: imx6qdl-sabreauto: employ GPIO init-val for p-NOR
The parallel NOR that is attached to the i.MX6-SabreAuto WEIM switch needs a GPIO asserted at boot in order to probe properly. Employ the GPIO init-val mechanism to set the GPIO. Also, add partitions subnode to NOR device-tree node to make MTD initialization work. Alison Chaiken (2): ARM: dts: imx6qdl-sabreauto: assert GPIO at boot in order to connect NOR ARM: dts: imx6qdl-sabreauto: enable partitions for parallel NOR arch/arm/boot/dts/imx6qdl-sabreauto-eim-nor.dtsi | 43 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 4 +++ 2 files changed, 47 insertions(+) create mode 100644 arch/arm/boot/dts/imx6qdl-sabreauto-eim-nor.dtsi -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] ARM: dts: imx6qdl-sabreauto: assert GPIO at boot in order to connect NOR
PAD_EIM_D18 must be pulled low at boot in order for the parallel NOR
connected to the EIM switch to probe properly. Otherwise the imx-weim
device will register properly, but cfi_qry_present() will return
"U-V-]" rather than "Q-R-Y". Employ the gpio-initval mechanism in
GPIO5 node in the SabreAuto device-tree in order to set the pin.
Signed-off-by: Alison Chaiken
---
arch/arm/boot/dts/imx6qdl-sabreauto-eim-nor.dtsi | 43
1 file changed, 43 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6qdl-sabreauto-eim-nor.dtsi
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto-eim-nor.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto-eim-nor.dtsi
new file mode 100644
index 000..66a9aa2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto-eim-nor.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ * Copyright (c) 2012-2015 Mentor Graphics Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+&weim {
+ status = "okay";
+};
+
+&gpio5 {
+ p4 {
+ /* Select NOR or I2C3 via setting of port-expander
+* steering logic.
+* Low: Attach p-NOR line D18.
+* High: Attach I2C3 line SDA.
+*/
+ gpio-initval;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "SelNORorI2C3";
+ };
+};
+
+&i2c3 {
+ status = "disabled";
+};
+
+/* the following devices have pinmux conflicts with NOR */
+&uart3 {
+ status = "disabled";
+};
+
+&ecspi1 {
+ status = "disabled";
+};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] modpost: don't add a trailing wildcard for OF module aliases
On Tue, 8 Dec 2015 19:13:32 -0300 Javier Martinez Canillas
wrote:
> Commit ac551828993ee ("modpost: i2c aliases need no trailing wildcard")
> removed the wildcard at the end of the I2C module aliases because I2C
> devices have no IDs so the aliases are just arbitrary device names.
>
> This is also true for OF modaliases since a compatible string is used
> to define a specific IP hardware block. So the modalias should match a
> specific compatible string and not attempt to match a compatible string
> whose name matches the beginning of another one.
>
> For example, the following driver module:
>
> $ modinfo cros_ec_keyb | grep alias
> alias: platform:cros-ec-keyb
> alias: of:N*T*Cgoogle,cros-ec-keyb*
>
> will be tried to be loaded for an alias of:N*T*Cgoogle,cros-ec-keyb-v2
> but there could be a different driver that supports the device for that
> compatible string so it's better to remove the trailing wildcard for OF.
>
> Also, remove the word "always" from the add_wildcard() function comment
> since that was carried from the time where a wildcard was always added
> at the end of the module alias for all the devices.
>
> Suggested-by: Brian Norris
> Signed-off-by: Javier Martinez Canillas
> Reviewed-by: Sjoerd Simons
>
> ---
> Hello,
>
> I sent this patch before [0] but was never picked. MAINTAINERS doesn't
> say who should manage patches to file2alias so maybe I didn't add the
> right person to the cc list.
z:/usr/src/git26> perl scripts/get_maintainer.pl -f scripts/mod
Rusty Russell (commit_signer:18/27=67%)
> Documentation/development-process/5.Posting says that if there is no
> obvious maintainer, then Andrew Morton is often the patch target so
> I'm re-sending to him.
Yep. If I don't handle the particular patch, I know who does ;)
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -125,7 +125,7 @@ do {
> \
> sprintf(str + strlen(str), "*");\
> } while(0)
>
> -/* Always end in a wildcard, for future extension */
> +/* End in a wildcard, for future extension */
> static inline void add_wildcard(char *str)
> {
> int len = strlen(str);
> @@ -704,7 +704,6 @@ static int do_of_entry (const char *filename, void
> *symval, char *alias)
> if (isspace (*tmp))
> *tmp = '_';
>
> - add_wildcard(alias);
> return 1;
> }
> ADD_TO_DEVTABLE("of", of_device_id, do_of_entry);
> --
> 2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi][PATCH 2/2] ARM: dts: sun4i: Add rikomagic mk802+ board
Hi Marcus,
On Wed, Dec 9, 2015 at 5:48 AM, wrote:
> From: Marcus Cooper
>
> The Rikomagic mk802+ is an Allwinner A10 based hdmi tv-stick, it features
> 1G RAM, 4G nand, a mini-hdmi female connector, USB-A receptacle, mini-usb
> receptacle (OTG), USB-wifi and an internal microphone. Like the original
> mk802, it does not use any pmic.
>
> Signed-off-by: Marcus Cooper
> ---
> arch/arm/boot/dts/Makefile| 1 +
> arch/arm/boot/dts/sun4i-a10-mk802-1gb.dts | 50
> +++
> 2 files changed, 51 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun4i-a10-mk802-1gb.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ee8a1dc..f1cb0f8 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -600,6 +600,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
> sun4i-a10-marsboard.dtb \
> sun4i-a10-mini-xplus.dtb \
> sun4i-a10-mk802.dtb \
> + sun4i-a10-mk802-1gb.dtb \
> sun4i-a10-mk802ii.dtb \
> sun4i-a10-olinuxino-lime.dtb \
> sun4i-a10-pcduino.dtb \
> diff --git a/arch/arm/boot/dts/sun4i-a10-mk802-1gb.dts
> b/arch/arm/boot/dts/sun4i-a10-mk802-1gb.dts
> new file mode 100644
> index 000..eb77633
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun4i-a10-mk802-1gb.dts
> @@ -0,0 +1,50 @@
> +/*
> + * Copyright 2015 Marcus Cooper
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun4i-a10-mk802.dtsi"
> +
> +/ {
> + model = "Rikomagic MK802+";
> + compatible = "rikomagic,mk802-1gb", "allwinner,sun4i-a10";
> +
> +};
Are there any differences between the Rikomagic and the generic MK802?
You could just add another compatible to the original MK802 dts if there aren't.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] misc: Introduce reboot_reason driver
On Tue, Dec 8, 2015 at 4:15 PM, Bjorn Andersson
wrote:
> On Tue 08 Dec 13:52 PST 2015, Arnd Bergmann wrote:
>
>> On Tuesday 08 December 2015 13:29:22 John Stultz wrote:
[...]
>> > +static int __init reboot_reason_init(void)
>> > +{
>> > + return platform_driver_register(&reboot_reason_driver);
>> > +}
>> > +arch_initcall(reboot_reason_init);
>>
>> Why this early? If it can be a normal device_initcall, you can use
>> module_platform_driver().
>>
>
> Not represented in this patch is that several Android vendors uses this
> mechanism to communicate a panic() to the boot loader; to let the system
> enter some sort of memory dump state.
They could also just parse pstore and look for a panic(). Or the
bootloader should set the reason to enter memory dump and the kernel
should clear it once it is up enough to handle resets. You have a
window of time already that a panic will hang. Only a watchdog will
help there and that would need a different solution.
Are panics in early boot really common outside of development?
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] misc: Introduce reboot_reason driver
On Tue, Dec 8, 2015 at 3:29 PM, John Stultz wrote: > This patch adds a basic driver to allow for commands like > "reboot bootloader" and "reboot recovery" to communicate this > reboot-reason to the bootloader. > > This is commonly done on Android devices, in order to reboot > the device into fastboot or recovery mode. It also supports > custom OEM specific commands, via "reboot oem-". What are some examples of OEM specific commands? > This driver pulls the phys memory address from DT as well as > the magic reason values that are written to the address for > each mode. Starting with what does the h/w look like, this is typically implemented with some sort of persistent register(s) either in the SOC or PMIC. So I think persistent memory/registers is what we need to describe in DT. Perhaps this could be tied into pstore (an overkill for a single register, but useful if you already have pstore support for persistent memory)? The 2nd part is which register to use and the mapping of values to reboot reason. Do these vary within SOC families? If not, then we should just hardcode them in the reboot drivers which are already vendor specific. Also, while trying to standardize the values for reboot reason probably won't work short term, we should define something so people will start using it. We also should consider any implications with PSCI. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] misc: Introduce reboot_reason driver
On Tue 08 Dec 13:52 PST 2015, Arnd Bergmann wrote:
> On Tuesday 08 December 2015 13:29:22 John Stultz wrote:
>
[..]
> > +static int reboot_reason(struct notifier_block *nb, unsigned long action,
> > + void *data)
> > +{
> > + char *cmd = (char *)data;
> > + long reason = reasons[NONE];
> > +
> > + if (!reboot_reason_addr)
> > + return NOTIFY_DONE;
> > +
> > + if (cmd != NULL) {
> > + if (!strncmp(cmd, "bootloader", 10))
> > + reason = reasons[BOOTLOADER];
> > + else if (!strncmp(cmd, "recovery", 8))
> > + reason = reasons[RECOVERY];
> > + else if (!strncmp(cmd, "oem-", 4)) {
> > + unsigned long code;
> > +
> > + if (!kstrtoul(cmd+4, 0, &code))
> > + reason = reasons[OEM] | (code & 0xff);
> > + }
> > + }
> > +
> > + if (reason != -1)
> > + writel(reason, reboot_reason_addr);
> > + return NOTIFY_DONE;
> > +}
>
> Will this reboot the machine?
>
It will store the magic in IMEM, that is then read by the boot loader
after the reboot to make it trigger alternative boot flows - e.g. the
recovery/update path or enter fastboot mode.
> > + /* Install the notifier */
> > + restart_nb.notifier_call = reboot_reason;
> > + restart_nb.priority = 256;
> > + if (register_restart_handler(&restart_nb)) {
>
> If not, you should use register_reboot_notifier() rather than
> register_restart_handler(). The former gets called to do something
> just before rebooting, while the latter attempts to actually reboot
> the machine.
>
It should be a reboot_notifier, sorry for missing this in my answer.
> > +static int __init reboot_reason_init(void)
> > +{
> > + return platform_driver_register(&reboot_reason_driver);
> > +}
> > +arch_initcall(reboot_reason_init);
>
> Why this early? If it can be a normal device_initcall, you can use
> module_platform_driver().
>
Not represented in this patch is that several Android vendors uses this
mechanism to communicate a panic() to the boot loader; to let the system
enter some sort of memory dump state.
Adding support for that would be convenient and mandate the early,
otherwise it's just userspace that will trigger this so module would be
fine.
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH] modpost: don't add a trailing wildcard for OF module aliases
Commit ac551828993ee ("modpost: i2c aliases need no trailing wildcard")
removed the wildcard at the end of the I2C module aliases because I2C
devices have no IDs so the aliases are just arbitrary device names.
This is also true for OF modaliases since a compatible string is used
to define a specific IP hardware block. So the modalias should match a
specific compatible string and not attempt to match a compatible string
whose name matches the beginning of another one.
For example, the following driver module:
$ modinfo cros_ec_keyb | grep alias
alias: platform:cros-ec-keyb
alias: of:N*T*Cgoogle,cros-ec-keyb*
will be tried to be loaded for an alias of:N*T*Cgoogle,cros-ec-keyb-v2
but there could be a different driver that supports the device for that
compatible string so it's better to remove the trailing wildcard for OF.
Also, remove the word "always" from the add_wildcard() function comment
since that was carried from the time where a wildcard was always added
at the end of the module alias for all the devices.
Suggested-by: Brian Norris
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Sjoerd Simons
---
Hello,
I sent this patch before [0] but was never picked. MAINTAINERS doesn't
say who should manage patches to file2alias so maybe I didn't add the
right person to the cc list.
Documentation/development-process/5.Posting says that if there is no
obvious maintainer, then Andrew Morton is often the patch target so
I'm re-sending to him.
Best regards,
Javier
scripts/mod/file2alias.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 5b96206e9aab..65eaab8b7798 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -125,7 +125,7 @@ do {
\
sprintf(str + strlen(str), "*");\
} while(0)
-/* Always end in a wildcard, for future extension */
+/* End in a wildcard, for future extension */
static inline void add_wildcard(char *str)
{
int len = strlen(str);
@@ -704,7 +704,6 @@ static int do_of_entry (const char *filename, void *symval,
char *alias)
if (isspace (*tmp))
*tmp = '_';
- add_wildcard(alias);
return 1;
}
ADD_TO_DEVTABLE("of", of_device_id, do_of_entry);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] misc: Introduce reboot_reason driver
On Tue 08 Dec 13:29 PST 2015, John Stultz wrote:
> This patch adds a basic driver to allow for commands like
> "reboot bootloader" and "reboot recovery" to communicate this
> reboot-reason to the bootloader.
>
> This is commonly done on Android devices, in order to reboot
> the device into fastboot or recovery mode. It also supports
> custom OEM specific commands, via "reboot oem-".
>
> This driver pulls the phys memory address from DT as well as
> the magic reason values that are written to the address for
> each mode.
>
> For an example, this patch also adds the DT support for
> the nexus7 device via its dts (which is not yet upstream).
>
> Thoughts and feedback would be appreciated!
>
Good to see some work on this, I want it too :)
I do however think this is Qualcomm specific in its implementation, so
adding Andy and linux-arm-msm.
[..]
> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> index 5183d18..ee5dcb7 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> @@ -282,6 +282,15 @@
> };
> };
>
> + reboot_reason: reboot_reason@2a03f65c {
> + compatible = "reboot_reason";
> + reg = <0x2A03F65C 0x4>;
> + reason,none = <0x77665501>;
> + reason,bootloader = <0x77665500>;
> + reason,recovery = <0x77665502>;
> + reason,oem = <0x6f656d00>;
> + };
> +
This address refers to IMEM, which is shared with a number of other
uses. So I think we should have a simple-mfd (and syscon) with this
within.
I like the fact that you don't hard code the magics in the
implementation, as I've seen additions from multiple places - so perhaps
it should be made even more flexible.
OMAP seems to use strings here instead of magics, but the delivery
mechanism looks to be the same. But I think of this as Qualcomm
specific.
> gpio-keys {
> compatible = "gpio-keys";
> power {
[..]
> diff --git a/drivers/misc/reboot_reason.c b/drivers/misc/reboot_reason.c
[..]
> +
> +static int reboot_reason(struct notifier_block *nb, unsigned long action,
> + void *data)
> +{
> + char *cmd = (char *)data;
> + long reason = reasons[NONE];
> +
> + if (!reboot_reason_addr)
> + return NOTIFY_DONE;
> +
> + if (cmd != NULL) {
> + if (!strncmp(cmd, "bootloader", 10))
> + reason = reasons[BOOTLOADER];
> + else if (!strncmp(cmd, "recovery", 8))
> + reason = reasons[RECOVERY];
> + else if (!strncmp(cmd, "oem-", 4)) {
> + unsigned long code;
> +
> + if (!kstrtoul(cmd+4, 0, &code))
> + reason = reasons[OEM] | (code & 0xff);
> + }
> + }
In the case where we didn't find a match you should write the "normal"
reason here, otherwise I think you will end up in recovery when recovery
issues a reboot (in Android that is).
> +
> + if (reason != -1)
> + writel(reason, reboot_reason_addr);
> + return NOTIFY_DONE;
> +}
> +
> +static int reboot_reason_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + u32 val;
> + int i;
> +
> + /* initialize the reasons */
> + for (i = 0; i < MAX_REASONS; i++)
> + reasons[i] = -1;
> +
> + /* Try to grab the reason io address */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + reboot_reason_addr = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(reboot_reason_addr))
> + return PTR_ERR(reboot_reason_addr);
> +
Please acquire this memory from a syscon (preferably the the parent
simple-mfd).
> + /* initialize specified reasons from DT */
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,none", &val))
> + reasons[NONE] = val;
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,bootloader", &val))
> + reasons[BOOTLOADER] = val;
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,recovery", &val))
> + reasons[RECOVERY] = val;
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,oem", &val))
> + reasons[OEM] = val;
I would like for this to be less hard coded.
> +
> + /* Install the notifier */
> + restart_nb.notifier_call = reboot_reason;
> + restart_nb.priority = 256;
> + if (register_restart_handler(&restart_nb)) {
> + dev_err(&pdev->dev,
> + "failed to setup restart handler.\n");
> + }
> + return 0;
> +}
> +
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
Re: [PATCH 07/14] DEVICETREE: Add bindings for PIC32 pin control and GPIO
Hi Rob,
On 11/22/2015 02:47 PM, Rob Herring wrote:
> On Fri, Nov 20, 2015 at 05:17:19PM -0700, Joshua Henderson wrote:
>> From: Andrei Pistirica
>>
>> Document the devicetree bindings for PINCTRL and GPIO found on Microchip
>> PIC32 class devices. This also adds a header defining related port and
>> peripheral pin select functionality.
>>
>> Signed-off-by: Andrei Pistirica
>> Signed-off-by: Joshua Henderson
>> ---
>> .../bindings/gpio/microchip,pic32-gpio.txt | 33 ++
>> .../bindings/pinctrl/microchip,pic32-pinctrl.txt | 100 +
>> include/dt-bindings/pinctrl/pic32mzda.h| 404
>>
>> 3 files changed, 537 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt
>> create mode 100644
>> Documentation/devicetree/bindings/pinctrl/microchip,pic32-pinctrl.txt
>> create mode 100644 include/dt-bindings/pinctrl/pic32mzda.h
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt
>> b/Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt
>> new file mode 100644
>> index 000..f6eeb2f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt
>> @@ -0,0 +1,33 @@
>> +* Microchip PIC32 GPIO devices (PIO).
>> +
>> +Required properties:
>> + - compatible: "microchip,pic32-gpio"
>
> This should have a chip specific compatible string.
>
Will change to "microchip,pic32mzda-gpio".
>> + - reg: Base address and length for the device.
>> + - interrupts: The port interrupt shared be all pins.
>> + - gpio-controller: Marks the port as GPIO controller.
>> + - #gpio-cells: Two. The first cell is the pin number and
>> + the second cell is unused.
>> + - interrupt-controller: Marks the device node as an interrupt controller.
>> + - #interrupt-cells: Two. The first cell is the GPIO number and second cell
>> + is used to specify the trigger type:
>> +PIC32_PIN_CN_RISING : low-to-high edge triggered.
>> +PIC32_PIN_CN_FALLING: high-to-low edge triggered.
>> +PIC32_PIN_CN_BOTH : low-to-high and high-to-low edges triggered.
>
> Can't you use the standard flags?
>
Yes. This will be changed.
>> +
>> +Note:
>> + - If gpio-ranges is missing, then all the pins (32) related to the gpio
>> bank
>> + are enabled.
>> +
>> +Example:
>> +pioA: gpio@1f86 {
>> +compatible = "microchip,pic32-gpio";
>> +reg = <0x1f86 0x24>;
>> +interrupts = > +DEFAULT_INT_PRI IRQ_TYPE_LEVEL_HIGH>;
>> +#gpio-cells = <2>;
>> +gpio-controller;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>> +gpio-ranges = <&pic32_pinctrl 0 0 32>;
>> +clocks = <&PBCLK4>;
>> +};
>> diff --git
>> a/Documentation/devicetree/bindings/pinctrl/microchip,pic32-pinctrl.txt
>> b/Documentation/devicetree/bindings/pinctrl/microchip,pic32-pinctrl.txt
>> new file mode 100644
>> index 000..7cf4167
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pinctrl/microchip,pic32-pinctrl.txt
>> @@ -0,0 +1,100 @@
>> +* Microchip PIC32 Pinmux device.
>> +
>> +Please refer to pinctrl-bindings.txt for details of the pinctrl properties
>> and
>> +common bindings.
>> +
>> +PIC32 'pin configuration node' is a node of a group of pins which can be
>> +used for a specific device or function. This node represents configuraions
>> of
>> +single pins or a pairs of mux and related configuration.
>> +
>> +Required properties for pic32 device:
>> + - compatible: "microchip,pic32-pinctrl", "microchip,pic32mz-pinctrl"
>
> Is this both or either one. For both, it should be most specific first.
>
This is a mistake. Will change to only "microchip,pic32mzda-pinctrl".
>
>> + - reg: Base address and length for pps:in and pps:out registers.
>> +
>> +Properties for 'pin configuration node':
>> + - pic32,pins: each entry consists of 3 intergers and represents the mux and
>> + config settings for one pin. The first integer represent the remappable
>> pin,
>> + the second represent the peripheral pin and the last the configuration.
>> + The format is pic32,pins = > + PIC32_PP_'dir'_'peripherl-pin' PIC32_PIN_CONF_'config'>. The
>> configurations
>> + are divided in 2 classes: IN and OUT and each in 4 buckets. Each entry
>> must
>> + contains items from the same class and bucket, otherwise the driver will
>> + notify an error and the initialization will fail.
>> + - pic32,single-pins: each entry consists of 3 intergers and represents a
>> pin
>> + (that is not remappable) and related configuraion. The format is
>> + pic32,single-pins = . Each port
>> has
>> + 32 pins and please refer to chip documentation for details of remappable
>> + pins.
>> +
>> +Available pin configurations (refer to dt-bindings/pinctrl/pic32.h):
>> +PIC32_PIN_CONF_NONE : no configuration (default).
>> +PIC32_PIN_CONF_OD : indicate thi
Re: [RFC][PATCH] misc: Introduce reboot_reason driver
On Tuesday 08 December 2015 13:29:22 John Stultz wrote:
> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> index 5183d18..ee5dcb7 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> @@ -282,6 +282,15 @@
> };
> };
>
> + reboot_reason: reboot_reason@2a03f65c {
> + compatible = "reboot_reason";
This is not a good compatible string. There should generally be a vendor
name associated with it (use "linux," if nothing else, and you should have
'-' instead of '_'.
> + reg = <0x2A03F65C 0x4>;
This may easily conflict with the device it is part of. We should have
non-overlapping register areas in general. For the example you are
looking at, which register block is this?
> +
> +/* Types of reasons */
> +static enum {
> + NONE,
> + BOOTLOADER,
> + RECOVERY,
> + OEM,
> + MAX_REASONS
> +} __maybe_unused reason_types;
The variable seems to always be unused, not just "__maybe_unused". Maybe remove
it?
> +static int reboot_reason(struct notifier_block *nb, unsigned long action,
> + void *data)
> +{
> + char *cmd = (char *)data;
> + long reason = reasons[NONE];
> +
> + if (!reboot_reason_addr)
> + return NOTIFY_DONE;
> +
> + if (cmd != NULL) {
> + if (!strncmp(cmd, "bootloader", 10))
> + reason = reasons[BOOTLOADER];
> + else if (!strncmp(cmd, "recovery", 8))
> + reason = reasons[RECOVERY];
> + else if (!strncmp(cmd, "oem-", 4)) {
> + unsigned long code;
> +
> + if (!kstrtoul(cmd+4, 0, &code))
> + reason = reasons[OEM] | (code & 0xff);
> + }
> + }
> +
> + if (reason != -1)
> + writel(reason, reboot_reason_addr);
> + return NOTIFY_DONE;
> +}
Will this reboot the machine?
> + /* Install the notifier */
> + restart_nb.notifier_call = reboot_reason;
> + restart_nb.priority = 256;
> + if (register_restart_handler(&restart_nb)) {
If not, you should use register_reboot_notifier() rather than
register_restart_handler(). The former gets called to do something
just before rebooting, while the latter attempts to actually reboot
the machine.
> +static int __init reboot_reason_init(void)
> +{
> + return platform_driver_register(&reboot_reason_driver);
> +}
> +arch_initcall(reboot_reason_init);
Why this early? If it can be a normal device_initcall, you can use
module_platform_driver().
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH] misc: Introduce reboot_reason driver
This patch adds a basic driver to allow for commands like
"reboot bootloader" and "reboot recovery" to communicate this
reboot-reason to the bootloader.
This is commonly done on Android devices, in order to reboot
the device into fastboot or recovery mode. It also supports
custom OEM specific commands, via "reboot oem-".
This driver pulls the phys memory address from DT as well as
the magic reason values that are written to the address for
each mode.
For an example, this patch also adds the DT support for
the nexus7 device via its dts (which is not yet upstream).
Thoughts and feedback would be appreciated!
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Vinay Simha BN
Cc: Bjorn Andersson
Cc: Haojian Zhuang
Cc: devicetree@vger.kernel.org
Cc: Android Kernel Team
Signed-off-by: John Stultz
---
arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts | 9 ++
drivers/misc/Kconfig | 8 ++
drivers/misc/Makefile | 1 +
drivers/misc/reboot_reason.c | 117 ++
4 files changed, 135 insertions(+)
create mode 100644 drivers/misc/reboot_reason.c
diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
index 5183d18..ee5dcb7 100644
--- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
@@ -282,6 +282,15 @@
};
};
+ reboot_reason: reboot_reason@2a03f65c {
+ compatible = "reboot_reason";
+ reg = <0x2A03F65C 0x4>;
+ reason,none = <0x77665501>;
+ reason,bootloader = <0x77665500>;
+ reason,recovery = <0x77665502>;
+ reason,oem = <0x6f656d00>;
+ };
+
gpio-keys {
compatible = "gpio-keys";
power {
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 22892c7..b5c141b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -525,6 +525,14 @@ config VEXPRESS_SYSCFG
bus. System Configuration interface is one of the possible means
of generating transactions on this bus.
+config REBOOT_REASON
+ bool "Pass reboot reason to bootloader"
+ default n
+ help
+ On many systems there is a desire to provide a reboot reason to
+ the bootloader, so that the bootloader can boot into a desired
+ mode on the next boot.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 537d7f3..4581e62 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
+obj-$(CONFIG_REBOOT_REASON)+= reboot_reason.o
diff --git a/drivers/misc/reboot_reason.c b/drivers/misc/reboot_reason.c
new file mode 100644
index 000..5c9b55eb
--- /dev/null
+++ b/drivers/misc/reboot_reason.c
@@ -0,0 +1,117 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Types of reasons */
+static enum {
+ NONE,
+ BOOTLOADER,
+ RECOVERY,
+ OEM,
+ MAX_REASONS
+} __maybe_unused reason_types;
+
+static u32 reasons[MAX_REASONS];
+static void __iomem*reboot_reason_addr;
+static struct notifier_block restart_nb;
+
+static int reboot_reason(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+ char *cmd = (char *)data;
+ long reason = reasons[NONE];
+
+ if (!reboot_reason_addr)
+ return NOTIFY_DONE;
+
+ if (cmd != NULL) {
+ if (!strncmp(cmd, "bootloader", 10))
+ reason = reasons[BOOTLOADER];
+ else if (!strncmp(cmd, "recovery", 8))
+ reason = reasons[RECOVERY];
+ else if (!strncmp(cmd, "oem-", 4)) {
+ unsigned long code;
+
+ if (!kstrtoul(cmd+4, 0, &code))
+ reason = reasons[OEM] | (code & 0xff);
+ }
+ }
+
+ if (reason != -1)
+ writel(reason, reboot_reason_addr);
+ return NOTIFY_DONE;
+}
+
+static int reboot_reason_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ u32 val;
+ int i;
+
+ /* initialize the reasons */
+ for (i = 0; i < MAX_REASONS; i++)
+ reasons[i] = -1;
+
+ /* Try to grab the reason io address */
+ res = platform_get_resour
Re: [PATCH v2] of/address: replace printk() with pr_debug() / pr_err()
On Tue, Dec 8, 2015 at 11:03 AM, Joe Perches wrote:
> On Tue, 2015-12-08 at 08:16 -0800, Joe Perches wrote:
>> On Wed, 2015-12-09 at 01:07 +0900, Masahiro Yamada wrote:
>> > Trivial changes suggested by checkpatch.pl.
>> []
>> > diff --git a/drivers/of/address.c b/drivers/of/address.c
>> []
>> > @@ -23,7 +23,7 @@ static int __of_address_to_resource(struct device_node
>> > *dev,
>> > #ifdef DEBUG
>> > static void of_dump_addr(const char *s, const __be32 *addr, int na)
>> > {
>> > - printk(KERN_DEBUG "%s", s);
>> > + pr_debug("%s", s);
>> > while (na--)
>> > printk(" %08x", be32_to_cpu(*(addr++)));
>> > printk("\n");
>>
>> mixing pr_debug and printk doesn't make much sense.
>>
>> It might be nicer to use
>>
>> static void of_dumpaddr(const char *s, const __be32 *addr, int na)
>> {
>> #ifdef DEBUG
>> ...
>> #endif
>> }
>>
>> to avoid the other static declaration
>
> Or more simply:
>
> static void of_dumpaddr(const char *s, const __be32 *addr, int na)
> {
> print_hex_dump_debug(s, DUMP_PREFIX_NONE, 16, 1,
> addr, na * sizeof(__be32), false);
> }
Except that it doesn't do the endian swapping. Looking closer at this,
we should just drop this hunk. So I will take v1.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support
On Mon, Dec 07, 2015 at 01:58:47PM -0600, Andrew F. Davis wrote: > As all of this driver should be taken though the MFD tree how > can this gpiolib change be handled? If we have gpio.parent it > will not build on MFD, with gpio.dev it will fail to build when > the changes are merged from the gpio subsystem. As the change > has not been merged into linux-next as far a I can tell maybe > this should be taken as is, then when the gpiolib change is > made this can be changed with all the other drivers? Do a cross tree merge in one direction or the other between MFD and GPIO. signature.asc Description: PGP signature
Re: [PATCH v2 6/6] arm64: renesas: r8a7795: Add L2 cache-controller nodes
On Tue, Dec 08, 2015 at 07:50:38PM +0100, Dirk Behme wrote:
> On 07.12.2015 20:03, Mark Rutland wrote:
> >On Mon, Dec 07, 2015 at 06:49:43PM +, Sudeep Holla wrote:
> >>
> >>On 07/12/15 18:24, Geert Uytterhoeven wrote:
> >>>+ L2_CA57: cache-controller@0 {
> >>>+ compatible = "cache";
> >>>+ arm,data-latency = <4 4 1>;
> >>>+ arm,tag-latency = <3 3 3>;
> >>
> >>Interesting, only PL2xx/3xx cache controller driver reads this from the
> >>DT and configures the controller. The integrated L2 found in
> >>A15/A7/A57/A53 needs doesn't make use of these values from the DT.
> >
> >These properties seem to be from l2cc.txt, which really only corresponds
> >to PL210/PL220/PL310 (and variants) and isn't as generic as it sounds.
> >
> >I don't see that these are necessary at all.
>
>
> What's about a documentation patch like [1], then?
I think it would be better to s/l2cc/l2x0/, and to make it clear that
the document only applies to the variants listed above.
If ePAPR doesn't cover the other cases, we should document those
separately.
> For what is the arm64 dts entry
>
> cpu@0 {
> ...
> next-level-cache = <&L2_0>;
> };
>
> L2_0: l2-cache0 {
> compatible = "cache";
> };
>
> good for at all, then?
With the other properties from ePAPR you can acquire information on the
geometry of the cache, which cannot be acquired from architected
registers.
Thanks,
Mark.
> [1]
>
> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt
> b/Documentation/devicetree/bindings/arm/l2cc.txt
> index 06c88a4..f687aed 100644
> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> @@ -1,12 +1,18 @@
> * ARM L2 Cache Controller
>
> -ARM cores often have a separate level 2 cache controller. There are
> various
> +ARM 32-bit cores often have a separate level 2 cache controller.
> There are various
> implementations of the L2 cache controller with compatible
> programming models.
> Some of the properties that are just prefixed "cache-*" are taken
> from section
> 3.7.3 of the ePAPR v1.1 specification which can be found at:
>
> https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf
>
> -The ARM L2 cache representation in the device tree should be done
> as follows:
> +ARM 64-bit cores (e.g. A15/A7/A57/A53) have an integrated level 2
> cache which
> +doesn't make use of any values from the kernel device tree. There is no
> +L2 cache configuration done in the kernel. The L2 cache is assumed to be
> +preconfigured by early secure boot code.
> +
> +The ARM L2 cache representation for 32-bit cores in the device tree
> should be done
> +as follows:
>
> Required properties:
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 12/16] Documentation: DT: bindings: Add power domain info for NVIDIA PMC
Jon Hunter writes:
> Add power-domain binding documentation for the NVIDIA PMC driver in
> order to support generic power-domains.
>
> Signed-off-by: Jon Hunter
>
> ---
>
> Please note that I have been debating whether I add this
> "nvidia,powergate-clock-disable" property or just leave the clocks
> disabled by default. Some downstream kernels leave the clocks enabled
> for the audio power-domain because the clocks required for powering up
> the power-domain are needed by all modules within the power-domain.
> However are the same time there are other power-domains that may need
> to be on, but not always clocked and so having the ability to specify if
> the clocks should be disabled seems useful. However, I can also remove
> this and just have the appropriate devices turn on the clocks as well.
> ---
> .../bindings/arm/tegra/nvidia,tegra20-pmc.txt | 61
> ++
> 1 file changed, 61 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
> b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
> index 838e1a69ec0a..8e4641db51a9 100644
> --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
> +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
> @@ -1,5 +1,7 @@
> NVIDIA Tegra Power Management Controller (PMC)
>
> +== Power Management Controller Node ==
> +
> The PMC block interacts with an external Power Management Unit. The PMC
> mostly controls the entry and exit of the system from different sleep
> modes. It provides power-gating controllers for SoC and CPU power-islands.
> @@ -69,6 +71,10 @@ Optional properties for hardware-triggered thermal reset
> (inside 'i2c-thermtrip'
> Defaults to 0. Valid values are described in section
> 12.5.2
> "Pinmux Support" of the Tegra4 Technical Reference
> Manual.
>
> +Optional nodes:
> +- pm-domains : This node contains a hierarchy of PM domain nodes, which
> should
> +match the power-domains on the Tegra SoC.
> +
> Example:
>
> / SoC dts including file
> @@ -114,3 +120,58 @@ pmc@7000f400 {
> };
> ...
> };
> +
> +
> +== PM Domain Nodes ==
> +
> +Each of the PM domain nodes represents a power-domain on the Tegra SoC
> +that can be power-gated by the PMC and should be named appropriately.
> +
> +Required properties:
> + - clocks: Must contain an entry for each clock required by the PMC for
> +controlling a power-gate. See ../clocks/clock-bindings.txt for details.
We've had this discussiona for a couple of other SoCs, so I need to
ask...
Presumably these are not device clocks that a runtime PM enabled driver
should be managing for a device, right? IOW, We want to make sure that the
PM domain isn't managing clocks for drivers that should be doing it.
I understand there are legitimate reasons for the PM domain to manage
clocks in addition to device drivers (e.g. for synchronous reset), but
just want to be sure it's not a shortcut for having a proper driver.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] ASoC: img: Add driver for Pistachio internal DAC
On Tue, Dec 08, 2015 at 05:05:24PM +, Damien Horsley wrote:
> +static int pistachio_internal_dac_set_mute(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
> + struct pistachio_internal_dac *dac = snd_soc_codec_get_drvdata(codec);
> + u32 reg;
> +
> + dac->mute = ucontrol->value.integer.value[0];
> +
> + if (dac->mute)
> + reg = PISTACHIO_INTERNAL_DAC_CTRL_MUTE_MASK;
> + else
> + reg = 0;
> +
> + regmap_update_bits(dac->regmap, PISTACHIO_INTERNAL_DAC_CTRL,
> + PISTACHIO_INTERNAL_DAC_CTRL_MUTE_MASK, reg);
> +
> + return 0;
> +}
Shouldn't this just be a standard SOC_SINGLE() now? We've got a regmap.
Otherwise this looks good.
signature.asc
Description: PGP signature
Re: [PATCH v2 1/5] power: domain: add pm_genpd_exit
Jon Hunter writes:
> On 04/12/15 17:45, Eric Anholt wrote:
>> From: Alexander Aring
>>
>> This patch adds function pm_genpd_exit for undo a pm_genpd_init. This
>> is useful for multiple power domains while probing. If the probing fails
>> after one pm_genpd_init was called we need to undo all previous
>> registrations of generic pm domains inside the gpd_list list.
>>
>> There is a check on IS_ERR_OR_NULL(genpd) which is useful to check again
>> registered power domains and not registered domains, the driver can use
>> this mechanism to have an array with registered and non-registered power
>> domains, where non-registered power domains are NULL.
>>
>> Cc: Rafael J. Wysocki
>> Cc: Kevin Hilman
>> Cc: Ulf Hansson
>> Cc: Pavel Machek
>> Cc: Len Brown
>> Cc: Greg Kroah-Hartman
>> Signed-off-by: Alexander Aring
>> Signed-off-by: Eric Anholt
>> Acked-by: Ulf Hansson
>> ---
>> drivers/base/power/domain.c | 22 ++
>> include/linux/pm_domain.h | 4
>> 2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index 167418e..e7aca27 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -1509,6 +1509,28 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
>> }
>> EXPORT_SYMBOL_GPL(pm_genpd_init);
>>
>> +/**
>> + * pm_genpd_exit - Uninitialize a generic I/O PM domain object.
>> + * @genpd: PM domain object to uninitialize.
>> + */
>> +void pm_genpd_exit(struct generic_pm_domain *genpd)
>> +{
>> +if (IS_ERR_OR_NULL(genpd))
>> +return;
>> +
>> +/* check if domain is still in registered inside the pm subsystem */
>> +WARN_ON_ONCE(!list_empty(&genpd->master_links) ||
>> + !list_empty(&genpd->slave_links) ||
>> + !list_empty(&genpd->dev_list));
>> +
>
> Why not return an error here? Seems bad to remove it, if it could still
> be referenced by other domains.
I had pointed this out as well in an earlier review.
> Also not sure if you need to lock around the above test and removing the
> domain.
>
>> +mutex_lock(&gpd_list_lock);
>> +list_del(&genpd->gpd_list_node);
>> +mutex_unlock(&gpd_list_lock);
>> +
>> +mutex_destroy(&genpd->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(pm_genpd_exit);
>> +
>
> BTW, I had just submitted a similar patch here [0]. So I would also like
> to see such an API added.
Between the two of you, maybe come up with an agreed upon patch and
re-submit.
Kevin
> Cheers
> Jon
>
> [0] http://marc.info/?l=devicetree&m=144924138932726&w=2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
