* [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
* [PATCH v2 1/2] iio: distance: srf08: add trivial DT binding
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
Add DT binding for devantech,srf08
Add vendor devantech to vendor list
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
---
Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 539874490492..86c6930c3c91 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -36,6 +36,7 @@ dallas,ds1775 Tiny Digital Thermometer and Thermostat
dallas,ds3232 Extremely Accurate I²C RTC with Integrated Crystal and SRAM
dallas,ds4510 CPU Supervisor with Nonvolatile Memory and Programmable I/O
dallas,ds75 Digital Thermometer and Thermostat
+devantech,srf08 Devantech SRF08 ultrasonic ranger
dlg,da9053 DA9053: flexible system level PMIC with multicore support
dlg,da9063 DA9063: system PMIC for quad-core application processors
epson,rx8010 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4696bb5c2198..80325e602403 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -65,6 +65,7 @@ dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
delta Delta Electronics, Inc.
denx Denx Software Engineering
+devantech Devantech, Ltd.
digi Digi International Inc.
digilent Diglent, Inc.
dlg Dialog Semiconductor
--
2.1.4
^ permalink raw reply related
* [PATCH v2 2/2] iio: distance: srf08: add IIO driver for us ranger
From: Andreas Klinger @ 2017-01-10 18:48 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 is the IIO driver for devantech srf08 ultrasonic ranger which can be
used to measure the distances to an object.
The sensor supports I2C with some registers.
Supported Features include:
- read the distance in ranging mode in centimeters
- output of the driver is directly the read value
- together with the scale the driver delivers the distance in meters
- only the first echo of the nearest object is delivered
- set max gain register; userspace enters analogue value
- set range registers; userspace enters range in millimeters in 43 mm steps
Features not supported by this driver:
- ranging mode in inches or in microseconds
- ANN mode
- change I2C address through this driver
- light sensor
The driver was added in the directory "proximity" of the iio subsystem
in absence of another directory named "distance".
There is also a new submenu "distance"
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
---
drivers/iio/proximity/Kconfig | 15 ++
drivers/iio/proximity/Makefile | 1 +
drivers/iio/proximity/srf08.c | 362 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 378 insertions(+)
create mode 100644 drivers/iio/proximity/srf08.c
diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index ef4c73db5b53..7b10a137702b 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -46,3 +46,18 @@ config SX9500
module will be called sx9500.
endmenu
+
+menu "Distance sensors"
+
+config SRF08
+ tristate "Devantech SRF08 ultrasonic ranger sensor"
+ depends on I2C
+ help
+ Say Y here to build a driver for Devantech SRF08 ultrasonic
+ ranger sensor. This driver can be used to measure the distance
+ of objects.
+
+ To compile this driver as a module, choose M here: the
+ module will be called srf08.
+
+endmenu
diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
index 9aadd9a8ee99..e914c2a5dd49 100644
--- a/drivers/iio/proximity/Makefile
+++ b/drivers/iio/proximity/Makefile
@@ -5,4 +5,5 @@
# When adding new entries keep the list in alphabetical order
obj-$(CONFIG_AS3935) += as3935.o
obj-$(CONFIG_LIDAR_LITE_V2) += pulsedlight-lidar-lite-v2.o
+obj-$(CONFIG_SRF08) += srf08.o
obj-$(CONFIG_SX9500) += sx9500.o
diff --git a/drivers/iio/proximity/srf08.c b/drivers/iio/proximity/srf08.c
new file mode 100644
index 000000000000..f38c74ed0933
--- /dev/null
+++ b/drivers/iio/proximity/srf08.c
@@ -0,0 +1,362 @@
+/*
+ * srf08.c - Support for Devantech SRF08 ultrasonic ranger
+ *
+ * Copyright (c) 2016 Andreas Klinger <ak@it-klinger.de>
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * For details about the device see:
+ * http://www.robot-electronics.co.uk/htm/srf08tech.html
+ */
+
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/bitops.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+/* registers of SRF08 device */
+#define SRF08_WRITE_COMMAND 0x00 /* Command Register */
+#define SRF08_WRITE_MAX_GAIN 0x01 /* Max Gain Register: 0 .. 31 */
+#define SRF08_WRITE_RANGE 0x02 /* Range Register: 0 .. 255 */
+#define SRF08_READ_SW_REVISION 0x00 /* Software Revision */
+#define SRF08_READ_LIGHT 0x01 /* Light Sensor during last echo */
+#define SRF08_READ_ECHO_1_HIGH 0x02 /* Range of first echo received */
+#define SRF08_READ_ECHO_1_LOW 0x03 /* Range of first echo received */
+
+#define SRF08_CMD_RANGING_CM 0x51 /* Ranging Mode - Result in cm */
+
+#define SRF08_DEFAULT_GAIN 1025 /* max. analogue value of Gain */
+#define SRF08_DEFAULT_RANGE 11008 /* max. value of Range in mm */
+
+struct srf08_data {
+ struct i2c_client *client;
+ int gain; /* Max Gain */
+ int range_mm; /* Range in mm */
+ struct mutex lock;
+};
+
+static const int srf08_gain[] = {
+ 94, 97, 100, 103, 107, 110, 114, 118,
+ 123, 128, 133, 139, 145, 152, 159, 168,
+ 177, 187, 199, 212, 227, 245, 265, 288,
+ 317, 352, 395, 450, 524, 626, 777, 1025 };
+
+static int srf08_read_ranging(struct srf08_data *data)
+{
+ struct i2c_client *client = data->client;
+ int ret, i;
+
+ mutex_lock(&data->lock);
+
+ ret = i2c_smbus_write_byte_data(data->client,
+ SRF08_WRITE_COMMAND, SRF08_CMD_RANGING_CM);
+ if (ret < 0) {
+ dev_err(&client->dev, "write command - err: %d\n", ret);
+ mutex_unlock(&data->lock);
+ return ret;
+ }
+
+ /*
+ * normally after 65 ms the device should have the read value
+ * we round it up to 100 ms
+ *
+ * we read here until a correct version number shows up as
+ * suggested by the documentation
+ */
+ for (i = 0; i < 5; i++) {
+ ret = i2c_smbus_read_byte_data(data->client,
+ SRF08_READ_SW_REVISION);
+
+ /* check if a valid version number is read */
+ if (ret < 255 && ret > 0)
+ break;
+ msleep(20);
+ }
+
+ if (ret >= 255 || ret <= 0) {
+ dev_err(&client->dev, "device not ready\n");
+ mutex_unlock(&data->lock);
+ return -EIO;
+ }
+
+ ret = i2c_smbus_read_word_swapped(data->client,
+ SRF08_READ_ECHO_1_HIGH);
+ if (ret < 0) {
+ dev_err(&client->dev, "cannot read distance: ret=%d\n", ret);
+ mutex_unlock(&data->lock);
+ return ret;
+ }
+
+ mutex_unlock(&data->lock);
+
+ return ret;
+}
+
+static int srf08_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *channel, int *val,
+ int *val2, long mask)
+{
+ struct srf08_data *data = iio_priv(indio_dev);
+ int ret;
+
+ if (channel->type != IIO_DISTANCE)
+ return -EINVAL;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = srf08_read_ranging(data);
+ if (ret < 0)
+ return ret;
+ *val = ret;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ /* 1 LSB is 1 cm */
+ *val = 0;
+ *val2 = 10000;
+ return IIO_VAL_INT_PLUS_MICRO;
+ default:
+ return -EINVAL;
+ }
+}
+
+static ssize_t srf08_show_range_mm_available(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int i, len = 0;
+
+ for (i = 0; i < 256; i++)
+ len += scnprintf(buf + len, PAGE_SIZE - len,
+ "%d ", (i + 1) * 43);
+
+ buf[len - 1] = '\n';
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(range_mm_available, S_IRUGO,
+ srf08_show_range_mm_available, NULL, 0);
+
+static ssize_t srf08_show_range_mm(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct srf08_data *data = iio_priv(indio_dev);
+
+ return sprintf(buf, "%d\n", data->range_mm);
+}
+
+/*
+ * set the range of the sensor to an even multiple of 43 mm
+ * which corresponds to 1 LSB in the register
+ *
+ * register value corresponding range
+ * 0x00 43 mm
+ * 0x01 86 mm
+ * 0x02 129 mm
+ * ...
+ * 0xFF 11008 mm
+ */
+static ssize_t srf08_write_range_mm(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct srf08_data *data = iio_priv(indio_dev);
+ struct i2c_client *client = data->client;
+ int ret;
+ unsigned int val, mod;
+ u8 regval;
+
+ ret = kstrtouint(buf, 10, &val);
+ if (ret)
+ return ret;
+
+ ret = val / 43 - 1;
+ mod = val % 43;
+
+ if (mod || (ret < 0) || (ret > 255))
+ return -EINVAL;
+
+ regval = ret;
+
+ mutex_lock(&data->lock);
+
+ ret = i2c_smbus_write_byte_data(data->client,
+ SRF08_WRITE_RANGE, regval);
+ if (ret < 0) {
+ dev_err(&client->dev, "write_range - err: %d\n", ret);
+ mutex_unlock(&data->lock);
+ return ret;
+ }
+
+ data->range_mm = val;
+
+ mutex_unlock(&data->lock);
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(range_mm, S_IRUGO | S_IWUSR,
+ srf08_show_range_mm, srf08_write_range_mm, 0);
+
+static ssize_t srf08_show_gain_available(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int i, len = 0;
+
+ for (i = 0; i < ARRAY_SIZE(srf08_gain); i++)
+ len += sprintf(buf + len, "%d ", srf08_gain[i]);
+
+ len += sprintf(buf + len, "\n");
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(gain_available, S_IRUGO,
+ srf08_show_gain_available, NULL, 0);
+
+static ssize_t srf08_show_gain(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct srf08_data *data = iio_priv(indio_dev);
+ int len;
+
+ len = sprintf(buf, "%d\n", data->gain);
+
+ return len;
+}
+
+static ssize_t srf08_write_gain(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct srf08_data *data = iio_priv(indio_dev);
+ struct i2c_client *client = data->client;
+ int ret, i;
+ unsigned int val;
+ u8 regval;
+
+ ret = kstrtouint(buf, 10, &val);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < ARRAY_SIZE(srf08_gain); i++)
+ if (val == srf08_gain[i]) {
+ regval = i;
+ break;
+ }
+
+ if (i >= ARRAY_SIZE(srf08_gain))
+ return -EINVAL;
+
+ mutex_lock(&data->lock);
+
+ ret = i2c_smbus_write_byte_data(data->client,
+ SRF08_WRITE_MAX_GAIN, regval);
+ if (ret < 0) {
+ dev_err(&client->dev, "write_gain - err: %d\n", ret);
+ mutex_unlock(&data->lock);
+ return ret;
+ }
+
+ data->gain = val;
+
+ mutex_unlock(&data->lock);
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(gain, S_IRUGO | S_IWUSR,
+ srf08_show_gain, srf08_write_gain, 0);
+
+static struct attribute *srf08_attributes[] = {
+ &iio_dev_attr_range_mm.dev_attr.attr,
+ &iio_dev_attr_range_mm_available.dev_attr.attr,
+ &iio_dev_attr_gain.dev_attr.attr,
+ &iio_dev_attr_gain_available.dev_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group srf08_attribute_group = {
+ .attrs = srf08_attributes,
+};
+
+static const struct iio_chan_spec srf08_channels[] = {
+ {
+ .type = IIO_DISTANCE,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ },
+};
+
+static const struct iio_info srf08_info = {
+ .read_raw = srf08_read_raw,
+ .attrs = &srf08_attribute_group,
+ .driver_module = THIS_MODULE,
+};
+
+static int srf08_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct iio_dev *indio_dev;
+ struct srf08_data *data;
+
+ if (!i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_READ_BYTE_DATA |
+ I2C_FUNC_SMBUS_WRITE_BYTE_DATA |
+ I2C_FUNC_SMBUS_READ_WORD_DATA))
+ return -ENODEV;
+
+ indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ data = iio_priv(indio_dev);
+ i2c_set_clientdata(client, indio_dev);
+ data->client = client;
+
+ /*
+ * set default values of device here
+ * these values are already set on the hardware after power on
+ */
+ data->gain = SRF08_DEFAULT_GAIN;
+ data->range_mm = SRF08_DEFAULT_RANGE;
+
+ indio_dev->name = dev_name(&client->dev);
+ indio_dev->dev.parent = &client->dev;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->info = &srf08_info;
+ indio_dev->channels = srf08_channels;
+ indio_dev->num_channels = ARRAY_SIZE(srf08_channels);
+
+ mutex_init(&data->lock);
+
+ return devm_iio_device_register(&client->dev, indio_dev);
+}
+
+static const struct i2c_device_id srf08_id[] = {
+ { "srf08", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, srf08_id);
+
+static struct i2c_driver srf08_driver = {
+ .driver = {
+ .name = "srf08",
+ },
+ .probe = srf08_probe,
+ .id_table = srf08_id,
+};
+module_i2c_driver(srf08_driver);
+
+MODULE_AUTHOR("Andreas Klinger <ak@it-klinger.de>");
+MODULE_DESCRIPTION("Devantech SRF08 ultrasonic ranger driver");
+MODULE_LICENSE("GPL");
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2 3/3] arm64: dts: exynos: Remove unneeded unit names in Exynos5433 nodes
From: Krzysztof Kozlowski @ 2017-01-10 18:51 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-4-git-send-email-javier@osg.samsung.com>
On Tue, Jan 10, 2017 at 02:38:32PM -0300, Javier Martinez Canillas wrote:
> 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 {
How about "usbdrd" instead of "usb-0"? It would be still quite a generic
description of a class.
> 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 {
usbhost?
Best regards,
Krzysztof
> compatible = "samsung,exynos5250-dwusb3";
> clocks = <&cmu_fsys CLK_ACLK_USBHOST30>,
> <&cmu_fsys CLK_SCLK_USBHOST30>;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH] gpio: pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2017-01-10 18:57 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Steve Longerbeam
In-Reply-To: <CAHp75VeCKPy4B51P_N9Bp03zPUbRodKzitc-n16ZRKJWcEF4fA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/03/2017 03:37 PM, Andy Shevchenko wrote:
> On Mon, Jan 2, 2017 at 11:07 PM, Steve Longerbeam <slongerbeam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Add optional reset-gpios pin control. If present, de-assert the
>> specified reset gpio pin to bring the chip out of reset.
>> --- a/drivers/gpio/gpio-pca953x.c
>> +++ b/drivers/gpio/gpio-pca953x.c
>> @@ -22,6 +22,7 @@
>> #include <linux/of_platform.h>
>> #include <linux/acpi.h>
>> #include <linux/regulator/consumer.h>
>> +#include <linux/gpio/consumer.h>
> Please, try to put it somehow alphabetically ordered (yes, I see it's
> not in general, but try to squeeze it into longest part which is
> ordered).
done.
>
>> #define PCA953X_INPUT 0
>> #define PCA953X_OUTPUT 1
>> @@ -754,8 +755,18 @@ static int pca953x_probe(struct i2c_client *client,
>> invert = pdata->invert;
>> chip->names = pdata->names;
>> } else {
>> + struct gpio_desc *reset_gpio;
>> +
>> chip->gpio_start = -1;
>> irq_base = 0;
>> +
>> + /* see if we need to de-assert a reset pin */
> see -> See
done.
Steve
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: exynos: Remove unneeded unit names in Exynos5433 nodes
From: Javier Martinez Canillas @ 2017-01-10 19:03 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, linux-samsung-soc, Rob Herring,
Catalin Marinas, Will Deacon, linux-kernel, Andi Shyti,
Chanwoo Choi, Kukjin Kim, linux-arm-kernel
In-Reply-To: <20170110185109.n3x25yxbaarzikcd@kozik-lap>
Hello Krzysztof,
On 01/10/2017 03:51 PM, Krzysztof Kozlowski wrote:
[snip]
>>
>> - usbdrd30: usb@15400000 {
>> + usbdrd30: usb-0 {
>
> How about "usbdrd" instead of "usb-0"? It would be still quite a generic
> description of a class.
>
>> 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 {
>
> usbhost?
>
Indeed, these sounds better so I'll change for them.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ 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