* Re: [PATCH 1/2] ARM: dts: imx6: Specify 'anatop-enable-bit' where appropriate
From: Fabio Estevam @ 2017-01-10 17:28 UTC (permalink / raw)
To: Andrey Smirnov
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Russell King, linux-kernel, Rob Herring, Sascha Hauer,
Fabio Estevam, Shawn Guo, yurovsky-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20170110163015.22444-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Jan 10, 2017 at 2:30 PM, Andrey Smirnov
<andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> ENABLE_LINREG bit is implemented by 3P0, 1P1 and 2P5 regulators on
> i.MX6. This property is present in similar code in Fresscale BSP and
> made its way upstream in imx6ul.dtsi, so this patch adds this property
> to the rest of i.MX6 family for completness.
Please see:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/arch/arm/boot/dts/imx6ul.dtsi?id=27958ccdf29e9971732e02494b48be54b0691269
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/11] dmaengine: cppi41: rename platform variables
From: Sergei Shtylyov @ 2017-01-10 17:35 UTC (permalink / raw)
To: Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <20170109160656.3470-2-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hello!
On 01/09/2017 07:06 PM, Alexandre Bailon wrote:
> Currently, only the am335x is supported by the driver.
> Though the driver has a glue layer to support different platforms,
> some platform variable names are not prefixed with the platform name.
> To facilitate the addition of a new platform,
> rename some variables owned by the am335x glue.
>
> Currently, only the am335x is supported by the driver.
> Though the driver provide a glue layer that should be used to support
> another platforms. Rename variable specifics to the am335x glue.
You are repeating yourself. :-)
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 0/3] arm64: dts: exynos: Fix DTC warnings for Exynos boards
From: Javier Martinez Canillas @ 2017-01-10 17:38 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
Hello Krzysztof,
This trivial series contains fixes for DTC warnings caused by mismatches
between unit names and reg properties in device tree nodes.
The patches shouldn't cause a functional change but have been just build
tested. I compared the generated DTB though to make sure that only these
nodes changed.
Best regards,
Javier
Changes since v1:
- Fix subject line since I forgot the "exynos" prefix.
Javier Martinez Canillas (3):
arm64: dts: exynos: Add missing unit name to Exynos7 SoC node
arm64: dts: exynos: Add missing unit name to Exynos5433 SoC node
arm64: dts: exynos: Remove unneeded unit names in Exynos5433 nodes
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 8 ++++----
arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/3] arm64: dts: exynos: Add missing unit name to Exynos7 SoC node
From: Javier Martinez Canillas @ 2017-01-10 17:38 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, linux-samsung-soc, Rob Herring,
Javier Martinez Canillas, Catalin Marinas, Will Deacon,
Andi Shyti, Chanwoo Choi, Kukjin Kim, Krzysztof Kozlowski,
linux-arm-kernel
In-Reply-To: <1484069912-6534-1-git-send-email-javier@osg.samsung.com>
This patch fixes the following DTC warning about a mismatch
between a device node reg property and its unit name:
Node /soc has a reg or ranges property, but no unit name
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 80aa60e38237..0d2fedc6ac2f 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -69,7 +69,7 @@
method = "smc";
};
- soc: soc {
+ soc: soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: exynos: Add missing unit name to Exynos5433 SoC node
From: Javier Martinez Canillas @ 2017-01-10 17:38 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484069912-6534-1-git-send-email-javier@osg.samsung.com>
This patch fixes the following DTC warning about a mismatch
between a device node reg property and its unit name:
Node /soc has a reg or ranges property, but no unit name
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 68f764e5851c..3695ddaf2e04 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -241,7 +241,7 @@
mask = <0x1>;
};
- soc: soc {
+ soc: soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: exynos: Remove unneeded unit names in Exynos5433 nodes
From: Javier Martinez Canillas @ 2017-01-10 17:38 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484069912-6534-1-git-send-email-javier@osg.samsung.com>
The "samsung,exynos5433-mipi-video-phy" and "samsung,exynos5250-dwusb3"
DT bindings don't specify a reg property for these nodes, so having a
unit name leads to the following DTC warnings:
Node /soc/video-phy@105c0710 has a unit name, but no reg property
Node /soc/usb@15400000 has a unit name, but no reg property
Node /soc/usb@15a00000 has a unit name, but no reg property
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 3695ddaf2e04..17e5dafd392c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -706,7 +706,7 @@
interrupts = <GIC_PPI 9 0xf04>;
};
- mipi_phy: video-phy@105c0710 {
+ mipi_phy: video-phy {
compatible = "samsung,exynos5433-mipi-video-phy";
#phy-cells = <1>;
samsung,pmu-syscon = <&pmu_system_controller>;
@@ -1285,7 +1285,7 @@
status = "disabled";
};
- usbdrd30: usb@15400000 {
+ usbdrd30: usb-0 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <&cmu_fsys CLK_ACLK_USBDRD30>,
<&cmu_fsys CLK_SCLK_USBDRD30>;
@@ -1332,7 +1332,7 @@
status = "disabled";
};
- usbhost30: usb@15a00000 {
+ usbhost30: usb-1 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <&cmu_fsys CLK_ACLK_USBHOST30>,
<&cmu_fsys CLK_SCLK_USBHOST30>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 02/11] dmaengine: cppi41: Split out the interrupt handler
From: Sergei Shtylyov @ 2017-01-10 17:39 UTC (permalink / raw)
To: Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <20170109160656.3470-3-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hello.
On 01/09/2017 07:06 PM, Alexandre Bailon wrote:
> The current interrupt handler do some actions specifics to am335x.
> These actions should be made by the platform interrupt handler.
> Split out the interrupt handler in two:
> one for the am335x platform and a generic one.
>
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> drivers/dma/cppi41.c | 24 +++++++++++++++---------
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
> index 25ee71d..42744ed 100644
> --- a/drivers/dma/cppi41.c
> +++ b/drivers/dma/cppi41.c
> @@ -284,18 +284,11 @@ static u32 cppi41_pop_desc(struct cppi41_dd *cdd, unsigned queue_num)
> return desc;
> }
>
> -static irqreturn_t cppi41_irq(int irq, void *data)
> +static irqreturn_t cppi41_irq(struct cppi41_dd *cdd)
> {
> - struct cppi41_dd *cdd = data;
> struct cppi41_channel *c;
> - u32 status;
> int i;
>
> - status = cppi_readl(cdd->usbss_mem + USBSS_IRQ_STATUS);
> - if (!(status & USBSS_IRQ_PD_COMP))
> - return IRQ_NONE;
> - cppi_writel(status, cdd->usbss_mem + USBSS_IRQ_STATUS);
> -
I fail to understand why non-CPPI 4.1 regs are used here (and that
positioning itself as an "abstract" CPPI 4.1 driver).
[...]
> @@ -351,6 +344,19 @@ static irqreturn_t cppi41_irq(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> +static irqreturn_t am335x_cppi41_irq(int irq, void *data)
> +{
> + struct cppi41_dd *cdd = data;
> + u32 status;
> +
> + status = cppi_readl(cdd->usbss_mem + USBSS_IRQ_STATUS);
> + if (!(status & USBSS_IRQ_PD_COMP))
> + return IRQ_NONE;
> + cppi_writel(status, cdd->usbss_mem + USBSS_IRQ_STATUS);
> +
> + return cppi41_irq(cdd);
> +}
> +
IMHO this stuff just needs to move to the MUSB glue.
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface
From: Benjamin Herrenschmidt @ 2017-01-10 17:41 UTC (permalink / raw)
To: Guenter Roeck, Edward James
Cc: andrew, corbet, devicetree, eajames.ibm, jdelvare, joel,
linux-doc, linux-hwmon, linux-i2c, linux-kernel, mark.rutland,
robh+dt, wsa
In-Reply-To: <8b182766-32a0-9eb1-7917-14abf811cef5@roeck-us.net>
On Sat, 2017-01-07 at 09:15 -0800, Guenter Roeck wrote:
> > Instead of the "online" attribute, what do you think about using the
> > "bind"/"unbind" API to probe the device from user space once the system
> > is powered on? All the hwmon registration would take place in the probe
> > function, it would just occur some time after boot.
> >
>
> A more common approach would be to have a platform driver. That platform
> driver would need a means to detect if the OCC is up and running, and
> instantiate everything else once it is.
>
> A trigger from user space is problematic because there is no guarantee
> that the OCC is really up (or that it even exists).
>
> An alternative might be to have the hwmon driver poll for the OCC,
> but that would be a bit more difficult and might require a kernel thread
> or maybe asynchronous probing.
Hi Guenter !
I'm not sure I agree with you here ;-)
I'm don't know how much background you got (I missed the beginning of
the discussion) but basically this driver runs on the BMC (system
controller) of the POWER9 server, the OCC is inside the POWER9 chip
itself.
So the presence/power state of the OCC doesn't depend on the BMC
platform kernel code. The BMC userspace controls power up and down to the POWER9, and thus it's the one to know whether the remote is up.
If we were to create a "platform driver", all it would do is get input
from userspace exactly like that sysfs file :-)
So if you don't like the sysfs file that registers/de-registers, which
I sort-of understand, it's a bit of a hack (though a rather efficient
one), I think the bind/unbind approach makes sense. However, I wonder
whether the simplest and most efficient (remember this BMC has a really
slow CPU) is an "online" file sysfs file, though rather than
registering/de-registering the hwmon it would simply make it stop
accessing the HW (and return some known "offline" values).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v3 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters
From: Mark Rutland @ 2017-01-10 17:43 UTC (permalink / raw)
To: Anurup M
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
catalin.marinas-5wv7dgnIgG8, arnd-r2nGTMty4D4,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, corbet-T1hC0tSOHrs,
will.deacon-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
anurup.m-hv44wF8Li93QT0dZR+AlfA,
zhangshaokun-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaojun-hv44wF8Li93QT0dZR+AlfA, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
sanil.kumar-C8/M+/jPZTeaMJb+Lgu22Q,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
shiju.jose-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, shyju.pv-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <1483339672-23778-1-git-send-email-anurup.m-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Hi,
On Mon, Jan 02, 2017 at 01:47:52AM -0500, Anurup M wrote:
> ToDo:
> 1) The counter overflow handling is currently unsupported in this
> patch series.
>From a quick scan of the patches, I see mention of an interrupt in a
comment the driver, but there's noething in the DT binding.
Is there an overflow interrupt at all?
Or do you need to implement polling to avoid overflow?
This is a prerequisite for merging the driver.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface
From: Benjamin Herrenschmidt @ 2017-01-10 17:45 UTC (permalink / raw)
To: Andrew Jeffery, Guenter Roeck, Edward James
Cc: corbet, devicetree, eajames.ibm, jdelvare, joel, linux-doc,
linux-hwmon, linux-i2c, linux-kernel, mark.rutland, robh+dt, wsa
In-Reply-To: <1483919532.2950.1.camel@aj.id.au>
On Mon, 2017-01-09 at 10:22 +1030, Andrew Jeffery wrote:
> Alternatively, in the style of your first para, we could push the
> host
> CPU state management into the kernel and expose a boot/reboot/power-
> off
> API to userspace. That would give us a place to hook calls for
> configuring and cleaning up any host-dependent drivers on the BMC.
That's nasty. Each machine has a subtly different way of controller
host power, that would mean a different kernel driver for each of them,
which we are trying to avoid.
This is userspace policy.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v3 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
From: Mark Rutland @ 2017-01-10 17:45 UTC (permalink / raw)
To: Anurup M
Cc: Rob Herring, will.deacon-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
anurup.m-hv44wF8Li93QT0dZR+AlfA,
zhangshaokun-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaojun-hv44wF8Li93QT0dZR+AlfA, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
sanil.kumar-C8/M+/jPZTeaMJb+Lgu22Q,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
shiju.jose-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, shyju.pv-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <586DD28E.5050500-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Jan 05, 2017 at 10:28:54AM +0530, Anurup M wrote:
>
>
> On Wednesday 04 January 2017 04:26 AM, Rob Herring wrote:
> >On Mon, Jan 02, 2017 at 01:49:03AM -0500, Anurup M wrote:
> >>From: Tan Xiaojun <tanxiaojun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >>
> >>Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
> >>
> >>Signed-off-by: Tan Xiaojun <tanxiaojun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >>Signed-off-by: Anurup M <anurup.m-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >>---
> >> .../devicetree/bindings/arm/hisilicon/djtag.txt | 41 ++++++++++++++++++++++
> >> 1 file changed, 41 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> >>
> >>diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> >>new file mode 100644
> >>index 0000000..bbe8b45
> >>--- /dev/null
> >>+++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> >>@@ -0,0 +1,41 @@
> >>+The Hisilicon Djtag is an independent component which connects with some other
> >>+components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
> >>+in the chip. The djtag controls access to connecting modules of CPU and IO
> >>+dies.
> >>+The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
> >>+are accessed by djtag during real time debugging. In IO die there are connecting
> >>+components like RSA. These components appear as devices attached to djtag bus.
> >>+
> >>+Hisilicon HiP05/06/07 djtag for CPU and IO die
> >>+Required properties:
> >>+ - compatible : The value should be as follows
> >>+ (a) "hisilicon,hip05-djtag-v1" for CPU and IO die which use v1 hw in
> >>+ HiP05 chipset.
> >You don't need to distinguish the CPU and IO blocks?
>
> The CPU and IO djtag nodes will have different base address(in reg
> property).
> There is no difference in handling of CPU and IO dies in the djtag driver.
> So there is currently no need to distinguish them.
It may still make sense to distinuguish them, even if the current djtag
driver can handle them the same. Presumably clients of the djtag driver
will poke CPU and IO djtag units differently.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface
From: Guenter Roeck @ 2017-01-10 17:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Edward James, andrew, corbet, devicetree, eajames.ibm, jdelvare,
joel, linux-doc, linux-hwmon, linux-i2c, linux-kernel,
mark.rutland, robh+dt, wsa
In-Reply-To: <1484070104.21117.29.camel@kernel.crashing.org>
On Tue, Jan 10, 2017 at 11:41:44AM -0600, Benjamin Herrenschmidt wrote:
> On Sat, 2017-01-07 at 09:15 -0800, Guenter Roeck wrote:
> > > Instead of the "online" attribute, what do you think about using the
> > > "bind"/"unbind" API to probe the device from user space once the system
> > > is powered on? All the hwmon registration would take place in the probe
> > > function, it would just occur some time after boot.
> > >
> >
> > A more common approach would be to have a platform driver. That platform
> > driver would need a means to detect if the OCC is up and running, and
> > instantiate everything else once it is.
> >
> > A trigger from user space is problematic because there is no guarantee
> > that the OCC is really up (or that it even exists).
> >
> > An alternative might be to have the hwmon driver poll for the OCC,
> > but that would be a bit more difficult and might require a kernel thread
> > or maybe asynchronous probing.
>
> Hi Guenter !
>
> I'm not sure I agree with you here ;-)
>
> I'm don't know how much background you got (I missed the beginning of
> the discussion) but basically this driver runs on the BMC (system
> controller) of the POWER9 server, the OCC is inside the POWER9 chip
> itself.
>
> So the presence/power state of the OCC doesn't depend on the BMC
> platform kernel code. The BMC userspace controls power up and down to the POWER9, and thus it's the one to know whether the remote is up.
>
> If we were to create a "platform driver", all it would do is get input
> from userspace exactly like that sysfs file :-)
>
> So if you don't like the sysfs file that registers/de-registers, which
> I sort-of understand, it's a bit of a hack (though a rather efficient
> one), I think the bind/unbind approach makes sense. However, I wonder
> whether the simplest and most efficient (remember this BMC has a really
> slow CPU) is an "online" file sysfs file, though rather than
> registering/de-registering the hwmon it would simply make it stop
> accessing the HW (and return some known "offline" values).
>
I don't like that too much either; it still looks like a hack.
How about using bind/unbind then ?
Guenter
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Will Deacon @ 2017-01-10 17:52 UTC (permalink / raw)
To: Rob Clark
Cc: iommu@lists.linux-foundation.org, linux-arm-msm, Sricharan R,
Jordan Crouse, Mark Rutland, Rob Herring,
devicetree@vger.kernel.org
In-Reply-To: <CAF6AEGuUidGEONzh92SYg9V2gE812oq_0CoZt-Zv7=bzb3FN3A@mail.gmail.com>
Hi Rob,
On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote:
> On Thu, Jan 5, 2017 at 10:49 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, Jan 05, 2017 at 10:27:27AM -0500, Rob Clark wrote:
> >> I'm not sure if the better solution then would be to have two fault
> >> callbacks, one immediately from the IRQ and a later one from wq. Or
> >> let the driver handle the wq business and give it a way to tell the
> >> IOMMU when to resume.
> >>
> >> I kinda think we should punt on the worker thread for now until we are
> >> ready to resume faulting transactions, because I guess a strong chance
> >> that whatever way we do it now will be wrong ;-)
> >
> > I guess what I'm after is for you to change the interrupt handlers to be
> > threaded, like they are for SMMUv3. I *think* you can do that with a NULL
> > thread_fn for now, and just call report_iommu_fault from the handler.
> > The return value of that could, in theory, be used to queued the paging
> > request and wake the paging thread in future.
>
> If we only pass in the non-threaded irq fxn, I'm not really sure how
> that changes anything.. or maybe I'm not understanding what you mean.
>
> But yeah, I guess we could use request_threaded_irq() to get both IRQ
> context notification and a later thread context notification rather
> than doing the wq thing. Either way the iommu API has to change
> slightly.
>
> >> > I wonder if this should also be predicated on the compatible string, so
> >> > that the "arm,smmu-enable-stall" property is ignored (with a warning) if
> >> > the compatible string isn't specific enough to identify an implementation
> >> > with the required SS behaviour? On the other hand, it feels pretty
> >> > redundant and a single "stalling works" property is all we need.
> >>
> >> We could also drop the property and key the behavior on specific
> >> compat strings I guess. Having both seems a bit odd. Anyways, I'll
> >> defer to DT folks about what the cleaner approach is.
> >
> > As Robin pointed out, we do need to be able to distinguish the integration
> > of the device from the device itself. For example, MMU-9000 might be capable
> > of stalling, but if it's bolted to a PCI RC, it's not safe to do so.
>
> Hmm, well we install the fault handler on the iommu_domain.. perhaps
> maybe a combo of dts property (or deciding based on more specific
> compat string), plus extra param passed in to
> iommu_set_fault_hander(). The dts property or compat string to
> indicate whether the iommu (and how it is wired up) can handle stalls,
> and enable_stall param when fault handler is registered to indicate
> whether the device itself can cope.. if either can't do stalling, then
> don't set CFCFG.
I thought about this some more, and I think you're right. Having
iommu_set_fault_handler take a flags parameter indicating that, for example,
the fault handler can deal with paging, is all we need to implement the
per-master opt-in functionality for stalling faults. There's no real
requirement to standardise a generic firmware property for that (but
we still need *something* that says stalling is usable on the SMMU --
perhaps just the compatible string is ok).
Taking this further, there's then no need for the threaded IRQ function
in the SMMUv2 driver after all. Instead, we pass a continuation function
pointer and opaque token from the SMMU driver to the fault handler in
IRQ context (this will be in thread context for SMMUv3, but that should
be fine). The fault handler can then stash these someplace, and signal
a wakeup for its own threaded handler, which ultimately calls the SMMU
continuation function with the opaque token as a parameter when it's done
with the fault. I think that's enough to get things rolling without adding
lots of infrastructure to the SMMU driver initially. If a pattern emerges
amongst users of the interface, then we could consolidate some of the work
handling back into IOMMU core.
What do you think? It should all be pretty straightforward for what you
want to do.
Will
^ permalink raw reply
* Re: [PATCH 08/11] dmaengine: cppi41: Implement the glue for da8xx
From: Sergei Shtylyov @ 2017-01-10 17:53 UTC (permalink / raw)
To: Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <20170109160656.3470-9-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 01/09/2017 07:06 PM, Alexandre Bailon wrote:
> The da8xx has a cppi41 dma controller.
It's called CPPI 4.1. :-)
> This is add the glue layer required to make it work on da8xx,
> as well some changes in driver (e.g to manage clock).
>
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> drivers/dma/cppi41.c | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 95 insertions(+)
>
> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
> index 939398e..4318e53 100644
> --- a/drivers/dma/cppi41.c
> +++ b/drivers/dma/cppi41.c
[...]
> @@ -86,10 +87,19 @@
>
> #define USBSS_IRQ_PD_COMP (1 << 2)
>
> +/* USB DA8XX */
> +#define DA8XX_INTR_SRC_MASKED 0x38
> +#define DA8XX_END_OF_INTR 0x3c
> +
> +#define DA8XX_QMGR_PENDING_MASK (0xf << 24)
> +
> +
> +
One empty line is enough.
> /* Packet Descriptor */
> #define PD2_ZERO_LENGTH (1 << 19)
>
> #define AM335X_CPPI41 0
> +#define DA8XX_CPPI41 1
>
> struct cppi41_channel {
> struct dma_chan chan;
[...]
> @@ -366,6 +393,26 @@ static irqreturn_t am335x_cppi41_irq(int irq, void *data)
> return cppi41_irq(cdd);
> }
>
> +static irqreturn_t da8xx_cppi41_irq(int irq, void *data)
> +{
> + struct cppi41_dd *cdd = data;
> + u32 status;
> + u32 usbss_status;
> +
> + status = cppi_readl(cdd->qmgr_mem + QMGR_PEND(0));
> + if (status & DA8XX_QMGR_PENDING_MASK)
> + cppi41_irq(cdd);
> + else
> + return IRQ_NONE;
Seems correct...
> +
> + /* Re-assert IRQ if there no usb core interrupts pending */
> + usbss_status = cppi_readl(cdd->usbss_mem + DA8XX_INTR_SRC_MASKED);
> + if (!usbss_status)
> + cppi_writel(0, cdd->usbss_mem + DA8XX_END_OF_INTR);
I don't understand this...
> +
> + return IRQ_HANDLED;
> +}
> +
> static dma_cookie_t cppi41_tx_submit(struct dma_async_tx_descriptor *tx)
> {
> dma_cookie_t cookie;
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 09/11] dmaengine: cppi41: Fix a race between PM runtime and channel abort
From: Sergei Shtylyov @ 2017-01-10 17:55 UTC (permalink / raw)
To: Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <20170109160656.3470-10-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 01/09/2017 07:06 PM, Alexandre Bailon wrote:
> cppi41_dma_issue_pending() may be called while the device is runtime
> suspended. In that case, the descritpor will be push to the pending
"Descriptor" and "pushed".
> list and then be queued to hardware queue.
> But if cppi41_stop_chan() is called before the device got time to
> resume, then the descriptor will remain in the pending list and be
> queued to hardware queue after the teardown.
> During the channel stop, check if there is a pendding descriptor
Pending.
> and if so, remove it.
>
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] arm: sunxi: add support for V3s SoC
From: Maxime Ripard @ 2017-01-10 18:09 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Stephen Boyd, Linus Walleij,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170103151629.19447-2-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]
On Tue, Jan 03, 2017 at 11:16:25PM +0800, Icenowy Zheng wrote:
> Allwinner V3s is a low-end single-core Cortex-A7 SoC, with 64MB
> integrated DRAM, and several peripherals.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
> Documentation/arm/sunxi/README | 4 ++++
> arch/arm/mach-sunxi/sunxi.c | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
> index cd0243302bc1..91ec8f2055be 100644
> --- a/Documentation/arm/sunxi/README
> +++ b/Documentation/arm/sunxi/README
> @@ -67,6 +67,10 @@ SunXi family
> + Datasheet
> http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
>
> + - Allwinner V3s (sun8i)
> + + Datasheet
> + https://www.goprawn.com/forum/allwinner-cams/783-allwinner-v3s-soc-datasheet
> +
Please don't put random links in there, but at least something that we
know will be there in a couple of weeks/monthes/years
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Maxime Ripard @ 2017-01-10 18:10 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Stephen Boyd, Linus Walleij,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170103151629.19447-3-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
> V3s has a similar but cut-down CCU to H3.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
It looks like there's nothing different but the clocks that you
register with the H3, please just use the H3 driver.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 3/5] pinctrl: sunxi: add driver for V3s SoC
From: Maxime Ripard @ 2017-01-10 18:18 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Stephen Boyd, Linus Walleij,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170103151629.19447-4-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 450 bytes --]
On Tue, Jan 03, 2017 at 11:16:27PM +0800, Icenowy Zheng wrote:
> V3s SoC features only a pin controller (for the lack of CPUs part).
>
> Add a driver for this controller.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/5] ARM: dts: sunxi: add dtsi file for V3s SoC
From: Maxime Ripard @ 2017-01-10 18:21 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Stephen Boyd, Linus Walleij,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170103151629.19447-5-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 338 bytes --]
On Tue, Jan 03, 2017 at 11:16:28PM +0800, Icenowy Zheng wrote:
> + uart0_pins_a: uart0@0 {
> + pins = "PB8", "PB9";
> + function = "uart0";
> + bias-pull-up;
Why do you need a pullup here?
Looks good otherwise.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx6: Specify 'anatop-enable-bit' where appropriate
From: Andrey Smirnov @ 2017-01-10 18:24 UTC (permalink / raw)
To: Fabio Estevam
Cc: Mark Rutland, devicetree@vger.kernel.org, Russell King,
linux-kernel, Rob Herring, Sascha Hauer, Fabio Estevam, Shawn Guo,
linux-arm-kernel@lists.infradead.org, Andrey Yurovsky
In-Reply-To: <CAOMZO5CnwrPcney0qzQgex_aFXCrksmEocZ28nf54Kvcm2dq-w@mail.gmail.com>
On Tue, Jan 10, 2017 at 9:28 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Jan 10, 2017 at 2:30 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>> ENABLE_LINREG bit is implemented by 3P0, 1P1 and 2P5 regulators on
>> i.MX6. This property is present in similar code in Fresscale BSP and
>> made its way upstream in imx6ul.dtsi, so this patch adds this property
>> to the rest of i.MX6 family for completness.
>
> Please see:
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/arch/arm/boot/dts/imx6ul.dtsi?id=27958ccdf29e9971732e02494b48be54b0691269
Fabio:
I submitted a patch implementing this property to LKML as well, see
https://www.spinics.net/lists/kernel/msg2418471.html
All of these patches are a part of a broader attempt to add PCIe
support for i.MX7, and on that platform this is a part of a 1P0D
regulator which supplies PCIe PHY.
I can rebase this patch set to take your commit into account, or else
let's discuss the best way to allow setting ENABLE_LINREG.
Thanks,
Andrey Smirnov
^ permalink raw reply
* Re: [PATCH v4 2/2] dt-bindings: clk: add rockchip, grf property for RK3399
From: Doug Anderson @ 2017-01-10 18:34 UTC (permalink / raw)
To: Xing Zheng
Cc: Mark Rutland, devicetree@vger.kernel.org, Heiko Stübner,
Michael Turquette, Stephen Boyd, linux-kernel@vger.kernel.org,
open list:ARM/Rockchip SoC..., Rob Herring, linux-clk,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1484028930-20305-3-git-send-email-zhengxing@rock-chips.com>
Hi,
On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> Add support for rockchip,grf property which is used for GRF muxes
> on RK3399.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v4:
> - update the decription for rockchip,grf property
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: dts: exynos: Fix DTC warnings for Exynos boards
From: Krzysztof Kozlowski @ 2017-01-10 18:42 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Andi Shyti, Chanwoo Choi, devicetree, Kukjin Kim,
Catalin Marinas, linux-samsung-soc, Rob Herring, Will Deacon,
Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484069912-6534-1-git-send-email-javier@osg.samsung.com>
On Tue, Jan 10, 2017 at 02:38:29PM -0300, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> This trivial series contains fixes for DTC warnings caused by mismatches
> between unit names and reg properties in device tree nodes.
>
> The patches shouldn't cause a functional change but have been just build
> tested. I compared the generated DTB though to make sure that only these
> nodes changed.
>
> Best regards,
> Javier
>
> Changes since v1:
> - Fix subject line since I forgot the "exynos" prefix.
Thanks :)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Doug Anderson @ 2017-01-10 18:45 UTC (permalink / raw)
To: Xing Zheng
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Elaine Zhang, Heiko Stübner, Catalin Marinas, Shawn Lin,
Brian Norris, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC..., Rob Herring, David Wu, Jianqun Xu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Caesar Wang
In-Reply-To: <1484028930-20305-2-git-send-email-zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hi,
On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> The structure rockchip_clk_provider needs to refer the GRF regmap
> in somewhere, if the CRU node has not "rockchip,grf" property,
> calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> regmap, and the MUXGRF type clock will be not supported.
>
> Therefore, we need to add them.
>
> Signed-off-by: Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> Changes in v4:
> - separte the binding patch
>
> Changes in v3:
> - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
>
> Changes in v2:
> - referring pmugrf for PMUGRU
> - fix the typo "invaild" in COMMIT message
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
This seems fine to me, so:
Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
...but I will say that before you actually add any real "MUXGRF"
clocks on rk3399 you _might_ need to rework the code to make things
truly "optional". If it turns out that any existing clocks that
already exist today already go through one of these muxes in the GRF
and we've always been assuming one setting of the mux, we'll need to
make sure we keep assuming that setting of the mux even if the "grf"
isn't specified.
As I understand it, your motivation for this patch is to eventually be
able to model the EDP reference clock which can either be xin24 or
"edp osc". Presumably the eDP "reference clock" isn't related to any
of the pre-existing eDP clocks so that one should be safe.
-Doug
^ permalink raw reply
* [PATCH v2 0/2] iio: distance: srf08: add IIO driver for us ranger
From: Andreas Klinger @ 2017-01-10 18:47 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, linux-iio, linux-kernel, ktsai,
wsa, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
trivial, mranostay, linux-i2c, devicetree
Cc: ak
This patch series adds IIO driver support for srf08 ultrasonic ranger
devices.
The first patch add a trivial device tree binding for the device together
with a new vendor devantech.
The second patch is the IIO driver which in turn is using I2C to talk to
the device.
Documentation about the sensor can be found here:
http://www.robot-electronics.co.uk/htm/srf08tech.html
Changes in v2:
Lots of updates thanks to Peters really fast review within 30 minutes
after first submission of the driver.
* Patch 2: "iio: distance: srf08: add IIO driver for us ranger"
- alphabetic order in Makefile
- use of u8 while accessing registers
- avoid endianness problems with 16 bit values
- missing return value checks
- some explaining documentation added
Andreas Klinger (2):
iio: distance: srf08: add trivial DT binding
iio: distance: srf08: add IIO driver for us ranger
.../devicetree/bindings/i2c/trivial-devices.txt | 1 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/iio/proximity/Kconfig | 15 +
drivers/iio/proximity/Makefile | 1 +
drivers/iio/proximity/srf08.c | 362 +++++++++++++++++++++
5 files changed, 380 insertions(+)
create mode 100644 drivers/iio/proximity/srf08.c
--
2.1.4
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: exynos: Add missing unit name to Exynos7 SoC node
From: Krzysztof Kozlowski @ 2017-01-10 18:47 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Mark Rutland, devicetree, linux-samsung-soc, Rob Herring,
Catalin Marinas, Will Deacon, linux-kernel, Andi Shyti,
Chanwoo Choi, Kukjin Kim, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484069912-6534-2-git-send-email-javier@osg.samsung.com>
On Tue, Jan 10, 2017 at 02:38:30PM -0300, Javier Martinez Canillas wrote:
> This patch fixes the following DTC warning about a mismatch
> between a device node reg property and its unit name:
>
> Node /soc has a reg or ranges property, but no unit name
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index 80aa60e38237..0d2fedc6ac2f 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -69,7 +69,7 @@
> method = "smc";
> };
>
> - soc: soc {
> + soc: soc@0 {
This looks unnatural, like a fix just to silence the DTC. Mostly de do
not enumerate soc node, although there are few exceptions.
I would prefer ignore the warning... however I am happy to hear other opinions.
Best regards,
Krzysztof
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
> --
> 2.7.4
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox